Dominic White

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.

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.

 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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.