Author Archives: dschuetz
Verizon 2012 DBIR Challenge
Every year, Verizon Business publishes the Data Breach Investigations Report (DBIR). This year’s report analyzes of a cross-section of “855 incidents, 174 million compromised records” that have occurred over the past year. This was actually the eighth year they’ve produced the report, and it’s well worth the read.
For me, it was especially worth the read this year. Every year since 2009, they’ve had a little cryptography puzzle embedded in the document. In 2009, it was a very simple cipher, hidden as a string of 1s and 0s in the background of the cover. The 2010 puzzle was quite a bit different, and significantly harder. Then, last year, the cover challenge got much more complicated (and, I think, quite a bit more interesting).
I really like solving crypto puzzles like these. I missed the first one, was soundly beaten by the second, and didn’t have a chance to play the third. So when this year’s report hit the streets, I was ready. And, after a couple days’ casual effort and a nearly-every-waking-moment weekend, I solved the puzzle. Not only that, but I was first, and won the prize (an iPad!).
I won’t spoil the puzzle here, but will mention a few interesting bits that I seem to re-learn every single time I complete one of these challenges:
1. Not everything is not always as it seems.
2. There are a lot of different modern ciphers.
3. If something looks “odd,” it probably is, and should be carefully investigated.
4. Coincidences are important.
And, finally, something I’ve been thinking about for a while:
5. I really need to watch The Big Lebowski.
If you’d like to see a full-on account of how I solved this one, as well as some of the blind alleys I spent hours in, check out the full writeup here.
Quick Look at Apple Configurator
Shortly after the iPad event on Wednesday, Apple released the free Apple Configurator application. It’s billed as a way to “set up new devices, and install enterprise apps,” but my main interest was in learning how it might interact with Mobile Device Management. So I upgraded my iTunes to 10.6, installed the application, and started poking around.
Essentially, Configurator allows you to maintain a fleet of identical iOS devices. With it, you can re-baseline up to 30 devices simultaneously, pre-installing applications and configuration profiles at the same time as wiping it clean and updating the OS version. The application allows you to create configuration profiles directly, or you may import profiles created in the iPhone Configuration Utility (IPCU). [Aside -- the IPCU was also updated on Wednesday, and both that and Configurator support some new features, including the ability to disable Siri when the device is locked. Interestingly, Configurator also includes the ability to enable a "Siri Profanity Filter" and to disable Location Services, neither of which I've been able to find in the new IPCU.] The Configurator doesn’t include the capability to create an MDM enrollment profile, but you can import one from IPCU and it works just fine.
When used in this mode, Configurator can easily streamline the setup of large numbers of devices for corporate deployment. I haven’t found a way to pre-set all the “Welcome to iOS” responses (selecting a language, assigning an Apple ID, etc.), but even with those last few manual steps, this can make rapid deployment of large numbers of devices in an enterprise much, much easier. The device is wiped, then the latest version of the iOS installed, along with applications and profiles. At this point, the device can be set aside into a pool, ready to be used. You can even load pre-purchased App Store applications (for very small deployments, you can pre-set the AppleID used to purchase the apps you’re installing, otherwise you’d need to use the Volume Purchase Program to load redemption codes for each device).
But that’s not all! When baselining (or “preparing”) a device, the user has a chance to configure it as a “Supervised” device. When issuing the device to end users, you can just hand it to them, or have the system formally “check out” the device. By doing the check out, the device can be customized with the user’s name, photo, and pre-installed user-specific documents. When the user is done with the device, they return it, and the check-in process then backs up the user’s data, and wipes and re-baselines the device for the next user.
All of that would be interesting enough, but my focus is more on security than ease of deployment — what does Configurator do to enhance or replace MDM? Firstly, the profile that marks the device as supervised can not be removed by the end user. In fact, as far as I can tell, it can’t even be removed by the machine which prepared the device. The only way to “un-supervise” a device is to wipe it clean and start from scratch. It also locks the device to the system used to prepare it — trying to connect to iTunes or IPCU on another system results in an error. In fact, even using IPCU on the Configurator machine won’t work — it won’t let you install or remove profiles at all. However, I was able to manually install an MDM profile, as a user, by tapping on a link in Safari, so the end user might still be able to make changes that way even if IPCU is locked out. Also, even when the MDM enrollment profile is installed as part of the device preparation and baseline process, the user may still remove the enrollment.
One final interesting point — the use of the “supervised” term caught my eye. When researching the changes that iOS 5.0 brought to the MDM system, I found several mentions of supervised devices near other MDM-related strings in the iOS binaries. I also found several references to a “Chaperone” system. These included things like “PermissionSlip,” “AllowSleepOver,” and even “ReadyForKeyMaster” (though no mention of Zuul). Ever since seeing that, I’ve wondered if some form of parental-oriented device management and monitoring might be in the works. Well, this system seems to make use of Chaperone-related profiles, so perhaps we’re seeing the first elements of this beginning to enter production.
In summary, the new Apple Configurator application looks like it will be very useful for anyone maintaining a small fleet of devices (such as loaner devices, or in support of a class), and will also greatly streamline the large-scale preparation and deployment of devices within the enterprise. For further reading, here’s a link to the Configurator Documentation from Apple.
iOS MDM: Preventing Disassociation DOS and Potemkin Devices
I was thinking a couple of weeks ago about additional vulnerabilities in iOS Mobile Device Management, and noticed a couple of problems that I had not considered before.
It may be possible for a malicious individual, whether an outside attacker or inside troublemaker, to forge fake responses to the MDM server. They could, it seems:
- Send the server fake TokenUpdate commands
- Send the server fake responses to real commands
In both cases, the attacker would need to know the UDID of the device they’re trying to impersonate.
The first case, a fake TokenUpdate command, could be used to sever the link between the server and the targeted device. By sending the command with a bogus DeviceToken, the MDM server would no longer be associated with the device, as the Push Notification system wouldn’t know where to send messages. Thus, the device whose UDID was used in the attack would no longer be managed by MDM.
An attacker who manages to collect UDIDs for multiple devices could thus mount a denial-of-service attack against the organization’s MDM server. Each and every targeted device would have to be manually re-enrolled with the server in order to resume management. For a large number of devices, this could be a costly effort, especially if the attack is repeated multiple times.
The second case is a bit more sneaky. If a user reconfigures their managed device to point to an MDM server of their own, they could essentially proxy the MDM protocol and send fake responses to the real server. By doing this, they could essentially create a “Potemkin Device” that would appear, to the corporate MDM server, to be properly in compliance with all policies, when in fact the device would simply ignore all MDM commands.
This seemed a little extreme to me. There must, I reasoned, be some way to prevent this from happening. So I dug a little deeper, and remembered the “Sign Messages” flag in the MDM enrollment payload. I’d experimented with this before, but discovered it had no effect on whether the client trusted the commands from the server.
As it turns out, I had it backwards — this flag isn’t for the server to sign messages to the client, but for the client, the remote device, to sign its messages back to the server. Exactly what I was looking for.
The exact mechanics are pretty simple:
- The client includes an “Mdm-Signature:” header in the HTTP PUT messages it sends to the server
- This signature is a base-64 encoded, .DER format, SMIME signature
- The content which is signed is not included in the signature, but is instead the content of the PUT itself — the message being sent to the MDM server
- Finally, it’s signed using the private Identity key that was sent to the device at MDM enrollment
So to prevent both these attacks, you must:
- Ensure the “Sign Messages” flag is set by the MDM server when enrolling device, and
- Ensure the server itself actually checks the validity of the signed messages, and rejects them if the signature is invalid
Note that it may be possible to extract the identity certificate and key from a device and set up the fake MDM proxy even with message signature validation enabled at the server — but I haven’t investigated this yet.
I’ve updated my test server with code that performs this check. You can find it on Github.
david.
Changes to Apple MDM for iOS 5.x
Last Saturday (January 28), I presented an updated talk on Apple’s iOS MDM system at ShmooCon 8. I had a great time, and really enjoyed all the questions and nice comments I received afterwards. I thought I’d mention a couple of the changes that iOS 5 provide.
First, the devices support some additional restrictions and controls. These controls should be available in most commercial MDM solutions, and can also be found in the iPhone Configuration Utility (IPCU). Among these new controls are the ability to:
- Disable Siri
- Selectively disable iCloud features: Backup, Document Sync, Photo Stream
- Reject SSL sites with untrusted certificates
- Prevent moving messages out of an email account into another
- Prevent use of an email account from 3rd party applications
Additions to the MDM service as a whole include:
- Ability to ask a device to “Check Out” when removed from MDM
- Installing and removing applications (custom and App Store apps)
- Listing managed applications
- Configuration of some settings (Voice and Data Roaming)
- Applying iTunes redemption codes to installation of apps (for Volume Purchase Plan)
I’ve updated my experimental MDM server to support most of these features. I’ve also added some better documentation for the server code, and scripts to help create the necessary server and CA certificates.
Slides from the presentation, as well as the code and the Black Hat white paper and slides, are all available at Github. Enjoy!
Finding Which Root CAs You Actually Use
With all the recent talk about fake SSL certs issued by root-level Certificate Authorities at Comodo and DigiNotar and so forth, I thought it’d be interesting to run a little experiment. One thing that these compromises have highlighted is the huge number of root certificate authorities in modern operating systems and browsers. But how many of those are actually in use? How many sites that I visit are certified by each of the roots?
On my OS X Lion install, the Keychain app tells me that I have 175 different roots installed. Some of them are pretty obvious (Verisign, etc.) but some are..well…probably NEVER going to be used by me, ever. Some have suggested that people simply delete root certs for various foreign entities (like CNNIC). But blindly deleting roots could mean that many sites you regularly visit suddenly stop validating.
So I wrote a simple python script. (I briefly considered writing it in perl, just to annoy an office troll, but sanity prevailed).
What this does is go though my Google Chrome “History” file. That’s a SQLite3 file, located in ~/Library/Application\ Support/Google/Chrome/Default/. It finds all URLs which start with “https://”, and calls the command-line OpenSSL utility to show the certificate chain retrieved when contacting that site. Then it sorts them all and outputs them grouped by CA.
Here’s a snippet of the output, run against my history:
Root CAs Used by Hosts in Cache File
/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority
tools.usps.com
www.facebook.com
www.icloud.com
donotcall.gov
complaints.donotcall.gov
/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
docs.google.com
accounts.youtube.com
plus.google.com
picasaweb.google.com
encrypted.google.com
chrome.google.com
adwords.google.com
bitbucket.org
gitorious.org
sites.google.com
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
discussions.apple.com
www.usps.com
help.apple.com
login.yahoo.com
fbcdn-sphotos-a.akamaihd.net
It’s pretty simple. And the script itself is a pretty ugly hack. But the output of the script, coupled with some simple grepping and wcing, tells me that out of 93 different SSL sites I’ve visted in the past (howeverlong Chrome keeps history for), they were represented by only 20 different root CAs. Another consultant reported 24 CAs over 292 different domains. I also ran the list against the first 250 reachable hosts in Alexa’s “Top Internet Sites” list, and found only 25 different root CAs in use.
Using the script is simple:
python findroots.py [options]
Options:
--chrome <filename>
--firefox <filename>
--list <filename>
Use –chrome to read a History file from Google Chrome, –firefox to read a places.sqlite file from Mozilla Firefox, and –list to read a plain text file listing of hosts, one host per line.
Click here to download the script: [download id="274"]
Strengths and Weaknesses in Apple’s MDM System
Yesterday, for the first time, I headlined a talk at a major security conference. It was quite the experience, and not nearly as nerve-wracking as I might’ve expected. Actually, it was pretty easy — I took the approach that “this is some cool stuff I found, let me tell you about it” and kept a conversational mindset. Don’t know if that’s what experienced presenters do, but it worked for me, and I think I pulled it off. Achievement: UNLOCKED.
For those who couldn’t make it to Black Hat, I wanted to post a short summary of my talk here, as well as links to the slides and white paper. So here we go!
When iOS 4.0 was released, Apple included some new features for remote management of iOS devices. This Mobile Device Management (MDM) is aimed at enterprises, and provides them with the ability to remotely configure and control all the devices within their organization. MDM includes three key features:
- Configuration: Install and remove configuration and provisioning profiles
- Query: Retrieve specific information from devices such as software versions, application lists, etc.
- Control: Remotely lock, unlock, and wipe devices
When the MDM system was first announced, developers expected documentation to be released — but it never came. Certainly, the protocol was shared with those commercial vendors selling MDM implementations, but it was never publicly released, not even exclusively within the developer program.
It’s certainly Apple’s prerogative to keep these APIs private, but doing so makes it difficult for people in the security firm to answer the simple question: “How secure is it?” And, as consultants supporting the deployment of iOS devices across large enterprises, we get asked that question. It’d be nice to be able to answer it, so we did some poking, prodding, and a whole lot of educated guessing, and now have a (reasonably) complete picture of the MDM protocol.
The attached white paper documents the protocol, as much as is possible. It describes how the server wakes up clients via Push Notification messages, what the device says to the server when it connects, how commands are sent to the devices, and finally, how the responses make their way back to the server. In short, enough information is presented that you can actually create your own MDM server. In fact, it even includes source code to a very simple MDM server you can use for your own research. (But don’t even think of using it as a substitute for a real MDM system — it’s just there to demonstrate the protocol).
So, to answer the first question, “How secure is Apple’s MDM?”, I’d have to say, it’s not too bad. The protocol itself is fairly straightforward and, with one exception, doesn’t appear to have any real security flaws. Unfortunately, the implementation on the iOS devices I tested (4.2.x and 4.3.x on iPhone 3Gs and iPad 1 and 2) has some implementation flaws and/or deficiencies that could lead to denial of service or disclosure of data. I’ll discuss both of these briefly here, but for full details see the attached slides.
The only real protocol problem that I believe exists is that the EraseDevice command (used to remotely wipe a device) doesn’t require any authentication from the server. As long as the device has received the EraseDevice command via the MDM connection, it will honor it. If an attacker is able to get a device to communicate with a rogue MDM server using traditional Man-in-the-Middle (MITM) techniques, then they could cause that device to erase itself the next time it checks in with MDM. It might be nice if this command required, for example, the UnlockToken used to clear the device’s passcode, as evidence that the MDM server issuing the Wipe command is, in fact, authorized to do so. I’d actually been so convinced this would be a requirement, that when I was able to wipe a device without additional authentication it left me stunned for several minutes.
On the other hand, it’s possible that Apple deliberately chose the less strict form of this command. When an organization determines that a device needs to be wiped, it’s likely because it’s been stolen or lost, and the erasure of the data on that device is of paramount importance. So the risk of accidental erasure, or malicious erasure by 3rd parties, might be acceptable given the requirement that in an emergency, nothing stand in the way of wiping the device. And besides, you’re supposed to be backing these things up regularly anyway.
The implementation flaws I discovered center mostly around weak authentication, both for communication with the MDM server itself, and with regards to authentication of server commands. In the former case, it appears that the client on the device will accept any valid certificate. That is, as long as the server it’s speaking with has a certificate which has been signed by an appropriate authority (or signed by a certificate authority which is recognized by the device), the connection will be permitted. This obviously opens the door to MITM attacks against MDM-managed devices.
The other key issue is that the device doesn’t appear to authenticate the commands themselves. A checkbox when creating an MDM enrollment profile offers to “sign messages,” but even when checked, the device happily accepted plain, unsigned commands. Forcing the server to sign commands, and adhering to a strict policy for validating those signatures, would make MITM attacks that get past the transport-layer protections significantly more difficult.
A final interesting issue I uncovered, by chance, was an Evil Maid attack. Briefly, the “traditional” Evil Maid attack describes how an attacker, with physical access to a device secured with full disk encryption (FDE), could boot that device from external media to install malware, such as a key logger, into the boot partition. This malware would enable the attacker to recover the user’s password to unlock the FDE on the device, which would be exploited by the attacker on subsequent accesses to the hardware.
Apparently, sending a copy of the original MDM enrollment profile to an enrolled device will cause that device to re-enroll in MDM. This re-enrollment also causes the device to create a new UnlockToken, and send that to the server. If the attacker has a rogue server set up using MITM, then that token would go to the attacker, and they’d then be able to clear the device’s passcode and access protected information on the device.
This attack is certainly not easy, and relies on some pretty specific boot exploits using DFU mode and tethered access to the locked filesystem. To date, I do not believe this mode is available on iPad 2, so those devices should be protected (at least, from the specific variant of the attack that I’ve experimented with).
Fortunately, this attack can be eliminated with the stronger session- and command-level authentication steps suggested above, along with protection (or elimination) of some key data on the device. Full details, again, are in the slides.
What’s the bottom line, then? Do these weaknesses make MDM a significant risk for enterprises? In my opinion, certainly not. The benefits of MDM far exceed the risks introduced by these vulnerabilities. If, however your organization stores sensitive information on iOS devices, then care should be taken whenever those devices are left unattended, whether in a hotel or even within the office environment. But then, the same care should be applied to any device with sensitive information — mobile, desktop, or laptop.
So in the end, I hope that our work can help you better understand how MDM works, and properly evaluate its risks and benefits to your organization. For those of you who made it to my talk, thanks for coming and I hope you enjoyed it! For those who didn’t, I hope the attached material will prove an acceptable substitute (and, no, I don’t believe that Black Hat makes videos available to the general public). If anyone has any questions about this research, please feel free to contact me.
david.
[Update -- slides, whitepaper, and code are now available on Github: github.com/intrepidusgroup/imdmtools.]
Inside Apple’s MDM Black Box — Black Hat USA 2011
Since joining Intrepidus Group, I’ve spent a good deal of time helping to assess risk and craft security guidelines for iOS devices in large enterprises. A major factor in securing iStuff in the enterprise relies upon the use of Mobile Device Management technology (MDM). MDM has been around for a while, especially for some of the older, more corporately-established mobile devices (like BlackBerry or Windows Mobile). Last summer, though, Apple jumped into the arena, adding support for their devices as part of iOS 4.0.
Unfortunately, the way that MDM works for iOS hasn’t been very well described, publicly. Which makes it difficult when you’re trying to demonstrate to a customer that it will make their enviroment more secure.
So I set about doing everything I could to understand, at a deep, technical level, exactly how the technology worked. We were already pretty satisifed, abstractly, with the features and capabilities of Apple’s MDM, but we felt it necessary to go that extra step to truly know what it’s doing. The end result of this is that we now have a mostly-complete understanding of how the protocol works.
If you’re coming to Black Hat next week, you’ll have a chance to see me talk about all of this in person. I start with how iOS settings work, move into additional features available through the iPhone Configuration Utility, and then start talking about MDM. The talk shows in detail how MDM uses the Apple Push Notification Service, and describes the message format used to make that notification. It’ll also document the interaction between device and server, from authentication and enrollment to receiving commands and providing responses. Enough detail is provided to enable you to write your own experimental MDM server (or, you could simply use the one I’ll be releasing at the talk).
Finally, I’ll talk about some limitations and weaknesses I’ve uncovered, and their potential security ramifications. There might even be a surprise for those hardy enough to sit through the whole talk.
There will even be live demos. 
This is going to be quite the experience for me. If your work involves securing iOS devices, especially at the enterprise level, please drop by and give a listen. If you can’t make it, check back here after the conference — I hope to write up some of the more interesting bits of the talk for a standalone post, and we should also have the slides, white paper, and source code available for download at some point.
See you in Vegas!
-david.
Is the iOS 4 location tracking privacy issue overblown?
Earlier today, a story broke about a database on the iPhone that appeared to track the user’s location. The implication was that anyone could discover where, and when, the device’s owner had been.
As far as I can see, this is only partially true. I looked at the database on my own phone, and could see places I’ve been, including my home and office. However, contrary to what the current buzz seems to be, it’s not a long-term breadcrumb trail of my activities.
Instead, the database seems to be used for geolocation services, in the event that a live location update is unavailable. In the database on my phone, I found 127,793 entries in the WifiLocation table. Each entry included a MAC address, latitude and longitude, and a timestamp (among other data). How many unique MAC addresses were there? Exactly 127,793. The CellLocation table had similar results — 11,418 entries, each with a unique combination of (MCC, MNC, LAC, and CI) (which should uniquely identify a cell tower).
If my device can’t get a current location from GPS or a cell tower, but it sees a WiFi point that’s in the DB, then it’ll still be able to guess pretty much were I am.
So though this can tell me where I’ve been, it can’t tell me how often I’ve been there. It only seems to record a single visit to each location. At this time, I’m not sure whether it’s the last visit, or the last time anything significant changed. But it’s certainly not going to be able to follow me around town.
Are there privacy implications? Certainly. If the association between a user and a given location should be kept confidential, then this database could reveal that assocation. But I don’t think the concerns are earth-shattering. Frequent users of Google Maps likely disclose far more information to Google than is contained in this file. Even beyond Google maps, mobile users already have location aware google searching in their mobile browser. (though you can opt-out of that)
Bottom line: How can you protect this data on your own device? Simply follow the same steps you take to secure any data on any iOS device: Use a passcode to lock it, and require a password to back it up. These will prevent anyone from simply grabbing your locked phone off a bar and stealing your data. Note, however, that the file does not appear to be encrypted, so if an attacker can jailbreak the phone without unlocking it, they will be able to read the data, no matter the other protections.
UPDATE – 25 April
I’ve spent some time this weekend looking at the data from three iOS devices (with very limited data from a fourth), and my conclusions haven’t changed. This is simply a database to help applications use location-based services faster, and more accurately. This also fits with what many other folks have been saying all along.
The details are probably too boring for this venue, so I’ve posted them here, on my personal blog. It’s a bit wordy, but hopefully it’ll be useful to folks who really want to dig.
Also, I’ve hacked together a simple python script that’ll extract the data from consolidated.db and put it into a nice little KML file. Here it is: [download id="270" format="2"] (but be warned — it’s pretty bare-bones, and if you’ve got a lot of data, it can really slow Google Earth down. )
-David Schuetz
Quantifying the Unknown: Measuring a Theoretical SecurID Attack
It’s been a few days since the attack on RSA / SecurID was made public. Last Friday, I considered potential risks the compromise may pose to RSA’s customers. Since then, the security world has been buzzing with analysis of risks, worst-case scenarios, and second-guessing of the offical RSA press releases.
Late yesterday, RSA released additional information via their SecureCare system. However, as this is only available to RSA customers, I haven’t been able to directly review it. Rich Mogull, at Securosis, has posted his take in an update last night, and includes some very good, specific recommended actions. I’d like to take a moment to present some back-of-the-envelope numbers relating to a theoretical attack scenario, especially in light of what (little) was just revealed by RSA.
Briefly, we still don’t know what was compromised in the breach, nor do we have any real way to quantify the risk that may present to users of RSA tokens. The just-released note included the following:
“To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful attack, someone would need to have possession of all this information.”
This still doesn’t tell us much. Which information is “controlled only by the customer”? The user’s password and PIN, certainly, but what else? The token’s serial number? It’s seed value? Beyond those items, what else is left to have been compromised at RSA?
Again, my fear remains that seeds, in some form, were compromised. If that is the case, then is there any way to estimate how easy it could be to attack one or more accounts using compromised seed information? Though there’s quite a bit we don’t know, it is still possible to make a rough estimate at the effort required, with a few simple (and I believe, easily defensible) assumptions.
A quick disclaimer: I do not have knowledge of the algorithms, aside from what I’ve been able to glean from others’ attempts at reverse-engineering them, and most of that dates to the older version of the system. So it’s quite possible that some of these assumptions will be wrong. But based on what I’ve been able to learn, I’m confident that I’m at least on the right track. It is my hope that this thought exercise will help RSA customers with a more concrete understanding of the system to accurately guage their own levels of risk.
First, let’s remember that any attacker will need to have more than just a list of seeds. They’ll need to identify the specific seed in use by their target. And they’ll need the target’s PIN and possibly a password as well. A key reason for using this kind of authentication is that you presume the PIN and password can be collected using other means, such as phishing, or man-in-the-middle attacks.
RSA supports many different kinds of tokens — and further research indicates that some of these have slightly different features. Tokens can create 6- or 8-digit tokencodes, for example. Soft tokens may be configured to incorporate the user’s PIN directly into the resultant tokencode, while hardware tokens keep it separate. It’s even possible that different models of hardware tokens use slightly different algorithms, with the differences all tracked in the authentication server. Of course, none of these algorithms have been publicly released by RSA. Determining which token types are in use at the target’s organizaton might be possible through network based attacks, or even simple visual observation of token fobs hanging from lanyards.
As has been described before, current tokens use a 128-bit seed value for their cryptographic algorithm, which is far too large to brute force. But a compromise that reveals, for example, all seeds which have ever been issued, could reduce that significantly. However, at least some soft tokens can create seeds dynamically, in a secure exchange with private authentication servers. These seeds need never be sent to RSA (though it’s possible they are, again, that’s not entirely clear).
Finally, because the algorithms are unpublished, we still do not know whether tokens use actual clock time, or some internal ticker that’s simply synchronized with the server. Because this can have a significant impact on the speed needed for the attack, we’ll consider both possibilities.
So, the attacker has the algorithm, a list of seeds, and one or many userids, PINs, and associated valid tokencodes. How do they identify the seed used by a given person, and thus, gain the ability to replicate their token and impersonate that user at will?
Let’s assume they have a single seed, and they’re 99% sure it’s for a given user. But they want to double-check. Take the tokencode they’ve already acquired, and look at the timestamp from when it was used. Put that timestamp, and the potential seed, into the algorithm, and see if the result matches the tokencode you have. If it does, bingo. If it doesn’t, maybe back the timestamp up 30 seconds, and also 30 seconds the other way, just to account for clock skew.
Total effort: 3 calls of the algorithm.
How long would this take? It’s impossible to tell without understanding how the algorithm works. If the system performs many successive encryption operations, then it could be very slow. However, since hardware tokens are constantly computing new tokencodes, it’s likely this would produce too much of a drain on the battery.
According to Wikipedia, a single AES-128 encryption of a 25-byte payload should take about 1 microsecond (for certain modes of AES). That’s probably on the high-end for the payload size, but since this is just a back-of-the-envelope calculation, we’ll go with it.
So, to verify a single seed, against a single observed tokencode, with a known absolute time for the tokencode, should take 3 microseconds.
Now, what if the token doesn’t use absolute clock time, but instead uses a counter unique to each token? A single year contains (approximately) 525,000 minutes. A token which changes every 30 seconds, therefore, goes through 1.05 million tokencodes in a year. If a token has a useful lifetime of 5 years, that’s just over 5 million values. In practice, tokens proably only last about 3 years or so, but this is probably a good upper limit.
To verify, then, a tokencode using an internal counter, the attacker would need to have two consecutive token codes (not difficult, given assumption #1), and would need to run through all 5 million potential time values. If the algorithm can compute a million tokencodes per second, that’s 5 seconds to test. (Actually, marginally more, as whenever a ‘hit’ is encountered, the 2nd tokencode will need to be computed to verify it wasn’t a coincidental result.)
This is all assuming the attacker has a pretty good idea of the target’s seed, which is pretty unlikely. How long, then, would it take to run the above tests against 40,000,000 compromised seeds? Simply take the two figures (3 microseconds and 5 seconds) and multiply by the size of the seed list.
| # Seeds | Absolute time (clock-based) | Relative time (token-based timer) |
| 1 | 3 microseconds | 5 seconds |
| 40 mil | 2 minutes | 6.3 years |
As you can see, if the tokens use a real, clock-based time, then an attack could complete in just a few minutes. If each token has its own clock (synchronized with the server at activation), then an attack across 40 million seeds takes much longer. However, this assumes a single CPU. In an 8-core system, it could conceivably take 1/8 as long, or 289 days. Put together a rack with a dozen such systems, and now the attack is only 24 days. Even if we double the guess, that’s well within the time defined by a typical password aging policy, and certainly worth the effort to a well-funded attacker.
Once again, the bottom line is that the lack of specific details from RSA, and the obscurity of their underlying algorithms, makes it nearly impossible to know what the true risk is. I’ve made a few assumptions here, but I don’t think they’re far off. If, as many are growing to suspect, some large number of token seeds have been compromised, then I believe the risk is real, and could be significant for some customers.
The Securosis analysis properly identifies high-value targets such as corporate executives or defense contractors, as having the highest risk to this sort of (hopefully still theoretical) attack. If it is the case that seeds have been compromised, then these organizations should probably be evaluating options. Moving high-profile users to soft tokens with newly-generated seeds would be a good short-term solution until new, uncompromised tokens can be acquired.
Finally, all organzations should review the first, key assumption: that an attacker already has (or can readily acquire) a valid userid, PIN, and tokencode combination. Reminding users of ways to verify secure communications (to reduce the chances of a man-in-the-middle attack) is a good first step. Additional traning to recognize the inevitable phishing attacks should probably also be seriously considered. Changing passwords and/or PINs more frequently, at least until the compromise has been better described and risks better assessed, may also be wise.
The RSA/SecurID Compromise: What is my risk?
So yesterday, RSA, a security division within EMC and the folks responsible for SecurID, one of the most popular forms of two-factor authentication, announced that they’d been hacked.
What does this mean? Well, we don’t have many details, but the most troubling bit is that apparently the attackers acquired information “specifically related to RSA’s SecurID two-factor authentication products.” In particular, that “this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.”
This is quite troubling. SecurID is used by over 25,000 customers, with an estimated 40 million physical tokens in circulation (in addition to 250 million software-based tokens). Many of these are used for secure authentication to corporate websites and email, and they’ve seen increasing use in online banking. A “reduction in effectiveness” could have very serious, and wide-ranging, consequences.
So what exactly could the attackers have gotten away with? First, a quick review of how SecurID tokens work.
At its core, SecurID is a cryptographic algorithm that produces random numbers in a pre-determined sequence. This sequence is known to an authentication server, and used to validate that the person logging in has the token in their possession. To keep the tokens unique, each is pre-loaded with a seed that initializes the sequence for each token. The resulting 6-digit numbers, or “tokencodes,” are therefore produced in a sequence specific and unique to each token.
This seed is typically 128-bits in length, so there are approximately 500 gagillion (a really really big number) potential sequences that any individual token could produce. Far too many for an attacker to have any practical chance at a brute-force attack.
Where the attack gets scary is if the seeds have been revealed to a third party. While there are many good reasons why RSA should not keep copies of tokens’ initial seeds, there are also some reasons why they might. Ultimately, I believe we’re facing four attack scenarios:
- Attackers get a list of seeds and token serial numbers. Then if they are able to acquire the serial number from a target’s token, they can replicate the token in software and use that to impersonate the target.
- Attackers get a list of seeds, and the corporations to which they’ve been assigned. This makes the attack a little tougher, but having only several thousand seeds to test is enormously better than having a 128-bit seed to test.
- Attackers get a list of all seeds issued thus far. Instead of having several thousand potential seeds to test, they have a few hundred million. Still much better than searching a 128-bit keyspace.
- Attackers find some weakness in the method used to generate seeds in the first place. Perhaps it uses a weak random number algorithm. Or maybe there’s a “master seed” that generates new seeds in sequence, just like the tokens itself.
(There’s actually a fifth scenario — internal documentation revealing a known weakness in the algorithm that allows an attacker to derive the key simply by observing multiple tokencodes. Without knowing how their tokencode algorithm works, we can’t know if this is even possible, but it seems exceedingly remote. At least we hope so.)
In all scenarios, the attacker will also need to observe at least one, probably two, tokencodes from the target in order to synchronize their sequence with the target’s token. They’ll need to observe a login anyway, just to get the target’s PIN (which is usually prepended to the tokencode at login).
So what’s the risk to your enterprise? Until we know more, there’s no way to say. If any of the first three scenarios come into play, then the risk for some high-value targets may be reasonably high. Any attacker who can monitor login attempts, perhaps through something as simple as a fake login page, will be able in short order to duplicate the target’s token and authenticate as them. The only way to mitigate that would be to replace all the tokens in circulation.
If the fourth (or worse, fifth) scenario is true, then there’s a much more significant risk to the RSA/SecurID system as a whole. It would compromise not only issued tokens, but every replacement token in stock. It breaks the system, until the seed-generation process, or even the token algorithm itself, can be changed, and new tokens produced.
Ideally, though, RSA won’t have any seeds stored, nor will there be any weakness in the methods used to generate those seeds. If that’s the case, then the worst that could happen is that the token algorithm itself may be leaked. Perhaps study of the algorithm could reveal weaknesses….but that’s a much longer term concern.
There is, however, one last, very likely scenario: Just as with any big-news item, this compromise could open the doors for any of several phishing scenarios. Attackers could certainly capitalize on the uncertainty of what’s happened to trick users into revealing information that would enable a reset of their credentials, regardless of whether they’re even using the SecurID system in the first place. In the long run, this attack could affect far more than just RSA’s customers.
