Sunday, November 7, 2010
Wednesday, June 16, 2010
So, at this point I assume everyone knows about the iPad Breach.
Originally AT&T stated that the disclosure of emails was the only issue from the information breach. Chris Paget soon reasoned out that this wasn't the case since American GSM vendors actually construct their Integrated Circuit Card identifier(ICC-ID)s to correspond to their International Mobile Subscriber Identifier(IMSI)s.
Thanks to a little bit of work between Ian Langworth and myself we now have a tool that takes advantage of this ICC-ID to IMSI correspondence. It also spits out a little bit of information about the ICC-ID as well. The tool can be found here but is likely to move. So if the link is dead, I'm probably moving it to new hosting. I'll make sure to update this post with the new address.
In Chris' post he describes the scary things you can do with an IMSI and links to a paper that explains how AT&T and T-Mobile ICC-IDs can be converted to IMSIs. There's just one catch, the paper is incomplete. Their method for AT&T / Cingular doesn't work. This bothered me, even more so after watching many people quote the paper on Slashdot and other sites. In addition to not trying the algorithm there was some confusion as to whether or not the ICC-IDs could correspond to the IMSIs, so I built the tool just to show definitively in this case it works.
So how do you convert an ICC-ID into an IMSI?
Basically the way you decode an AT&T or T-Mobile ICC-ID is like this.
- Read off the first 2 digits as the system code (all the ones we care about start with 89 for GSM)
- Read the ITU dialing prefix out of the next few digits this will be the next 2 - 3 digits. Make sure to match the longest prefix first.
- After parsing out the ITU prefix, parse the next three digits as the Mobile Network Code(MNC)
- Match the MNC with the ITU prefix country to find the Mobile Country Code (MCC).
- So at this point we have the MCC, the MNC, and are only missing the subscriber number to form an IMSI getting the subscriber number out of an ICC-ID is vendor specific so it's different between AT&T and T-Mobile
- To get an AT&T subscriber number simply take the next 9 digits after the MNC
- To get a T-Mobile subscriber number you need the take the two digits before the double 00 and concatenate them with the seven digits following the zero
Honestly this is pretty lame technically but it proves the point that ICC-ID disclosure is equivalent to an IMSI disclosure for AT&T and T-Mobile. In case anyone is wondering, yes we've checked the derrived IMSI values against the true IMSI values with OpenBootTS, and the USRP.
Tuesday, March 23, 2010
Honestly, I'm a little disappointed in myself for the presentation. I think it went well but I didn't really have time to make the talk as accessible as I would have liked, also this was my first time presenting at a conference so usual jitters apply, hopefully I'll get the chance to do it again.
A little explanation: The goal of this project was to determine how to protect a virtual machine monitor from a malicious System Management Mode Interrupt handler.
When I started working for Crucial Security my main focus was on building a hypervisor that was able to isolate a process from a malicious OS, the idea being that we wanted to ensure that even if an attacker got access to a server they'd still have to exploit the specific service to gain access to its data. During development we kept discovering new avenues of attacking the VMM, one of the most damaging ways was to use a malicious SMI handler as was done in Rafal Wojtczuk and Joanna Rutkowska's presentation on Attacking Intel's TXT.
The defense against their attack that Intel responded with was that the VMM developer should run the SMI handler inside of a virtual machine. Joanna's counter point was that, no one has good documentation on how to do that. Since I was developing a tiny VMM for security, I took that challenge and on the AMD-V platform developed a hypervisor that could run a limited SMI handler inside of a virtual machine as a PoC.
Unfortunately almost all of my time was spent developing and debugging the PoC, with less attention than I would have liked going to the actual presentation. Anyway I still need to get the source off of back ups since my corporate laptop died. However it should be up by the end of May. Comments and feed back are greatly appreciated.
My hope is that this helps VMM developers get a better idea in what's involved with isolating an SMI handler and in rare cases where that level of paranoia is needed, that my work can help other people find the information they need more quickly.
Wednesday, March 10, 2010
The nice part about this is that I can follow through on my promises since I never put a date on them. Anyway my personal goal is to start blogging again as it's both cathartic and a good means of keeping notes for research.
One of the most important things in a professionals career is their sense of what is and isn't possible. The caveat here is that this is often colored by your perception of what is and isn't easy to do, in other words your experience. In a recent conversation with Russell, this topic came up in the conext of information security professionals. As the conversation progressed two points stuck out in my mind, 1. that I came to security from a development background, 2. that it may not be as common as I thought.
Before I'd ever thought about networks, security or anything else related to information security, I'd learned C, and pascal in high school. I'd been doing basic bat scripting since my grandfather bought my family their first computer in 1993. Until I went to Northeastern University and majored in computer science my interest in the computer was primarily in figuring out how the box worked at the computer architechture level which I dabbled with on again and off again.
So how'd I actually get into this field? It was the summer of 2001, it was a hard summer for finding co-op assignments. For those of you not familiar with co-ops, it's basically a stint where you work in your field sort of like an internship. I'd already done some minor contract work with the chemistry department to write a visual basic program (eww in hindsight) to do some post processing of mass spectrometer results. I'd landed a job working as a JSP developer building a web based college advising system and things started to go wrong when a fellow student (Jon) walks in and says I've hacked your database.
Before I get into recounting how we were completely owned and what I did about it. Let me give you some background on the system. I was roughly the sixth developer, had never touched apache, tomcat, MS-SQL or JSP before this. It was a good learning experience. Though the project was doomed from the start. Too many developers had worked on it and then left and then in the middle of working on the project the professor and his two graduate students (who basically only spoke chinese which I can not speak) left. Leaving me with a collection of JSP pages and db tables that had each made sense to one of the previous devs.
Jon had found numerous SQL injeciton bugs which since we were using MS-SQL gives him shell access. What's worse is that this was a college advising database that of course contained student id numbers and contact informaiton. Like most universities Northeastern used social security numbers for student ids, game over. I spent the better part of a week building a really simplistic filtering library, going back and forth with Jon until he was unable to compromise the box via SQL injection. Looking back I'm sure there was XSS and enough other vectors to make everyone involved cringe in horror.
As expected, the web app never really got off the ground and it left me rather disappointed. The experience of potentially losing 400+ students social security numbers was too much for me, it made me realize that if I'd wanted to continue in development I'd need to learn about security and I've been doing that ever since.
So how does this relate to my original point? I like to build things, I was a developer. Therefore I look to build things when possible. It colors the decisions you're likely to make.
So how'd you get into information security?
Note: The table values are taken from Daniel Wesemann's ISC post
- Make sure firebug is enabled
- Load the test page in Firefox
- Now set breakpoints where you want and single step
Since I copied the pros and cons from the ISC list I figure I'd better contribute my own row for the firebug method.
For example if I have a sample file:
I can simply add a breakpoint before the alert call by adding the statement
This drops me into firebug at the debugger line. I can now single step my way through the code and inspect the DOM in the GUI.
For more information on using Firebug check out this video here