When developing the iOS 5 compatible version of iOS Forensic Toolkit, we found the freshened encryption to be only tweaked up a bit, with the exception of keychain encryption. The encryption algorithm protecting keychain items such as Web site and email passwords has been changed completely. In addition, escrow keybag now becomes useless to a forensic specialist. Without knowing the original device passcode, escrow keys remain inaccessible even if they are physically available.

What does enhanced security mean for the user? With iOS 5, they are getting a bit more security. Their keychain items such as Web site, email and certain application passwords will remain secure even if their phone falls into the hands of a forensic specialist. That, of course, will only last till the moment investigators obtain the original device passcode, which is only a matter of time if a tool such as iOS Forensic Toolkit is used to recover one.

What does this mean for the forensics? Bad news first: without knowing or recovering the original device passcode, some of the keychain items will not be decryptable. These items include Web site passwords stored in Safari browser, email passwords, and some application passwords.

Now the good news: iOS Forensic Toolkit can still recover the original plain-text device passcode, and it is still possible to obtain escrow keys from any iTunes equipped computer the iOS device in question has been ever synced or connected to. Once the passcode is recovered, iOS Forensic Toolkit will decrypt everything from the keychain. If there’s no time to recover the passcode or escrow keys, the Toolkit will still do its best and decrypt some of the keychain items.

Faster Operation

Besides adding support for the latest iOS 5, Elcomsoft iOS Forensic Toolkit becomes 2 to 2.5 times faster to acquire iOS devices. When it required 40 to 60 minutes before, the new version will take only 20 minutes. For example, the updated iOS Forensic Toolkit can acquire a 16-Gb iPhone 4 in about 20 minutes, or a 32-Gb version in 40 minutes.

Today we are releasing a new version of Phone Password Breaker, this time adding the ability to recover security passwords protecting BlackBerry handsets. Yes, that is the very password used to lock and unlock the device. And yes, no one has done that before (well, at least not publicly).

Before you get too excited, there is a catch. The new feature requires Media Card encryption to be switched on and set to either “Security Password” or “Device Password” mode. If this condition is met, EPPB will be able to run password recovery against device security password. What is also important and rather exciting is that you don’t need the BlackBerry device itself. All that is needed is a media card that was used in that device. Actually, we only need one specific file from that media card, so yes, the recovery can be off-loaded and the password can be recovered offline.

So how does this feature work? It’s pretty straightforward: launch Elcomsoft Phone Password Breaker, click Open and specify that you want to recover a BlackBerry security password. After that, you’ll need to navigate to the info.mkf file from the encrypted media card. It is located in BlackBerry/system directory on the media card, and is marked as hidden. Once you open the file (and only if the file comes from the card encrypted using the “Security Password” or “Device Password” option) you will be able to start the recovery as usual. The good news is that recovery rate is amazingly fast by today’s standards: it tries several million passwords per second on a modern multi-core CPU equipped with AES-NI instructions. With Intel i7-970, I am getting 1.8 million passwords per second in wordlist mode, and about 5.9 million passwords per second in bruteforce mode. Compare that to iPhone passcode recovery rate of less than six passcodes per second for iPhone 4, and try to think hard about BlackBerry having better security.

Among other changes in this version is preliminary support for iOS 5 backups. As Apple readies its newest and most advanced mobile OS yet, we have updated EPPB to make it compatible with backups produced by the latest beta of iOS 5. All the usual features (password recovery, backup decryption, and Keychain explorer) are available for iOS 5 backups.

Speaking of iOS backup decryption, we added another option demanded by our customers. EPPB can now recover original file names when decrypting a backup. That means you will get a directory structure and meaningful file names, making it easier to explore and analyze backup contents.

I really hope you will enjoy the new features.

RIM BlackBerry smartphones have been deemed the most secure smartphones on the market for a long, long time. They indeed are quite secure devices, especially when it comes to extracting information from the device you have physical access to (i.e. mobile phone forensics). It is unfortunate, however, that a great deal of that acclaimed security is achieved by “security through obscurity”, i.e. by not disclosing in-depth technical information on security mechanisms and/or their implementation. The idea is to make it more difficult for third parties to analyze. Some of us here at Elcomsoft are BlackBerry owners ourselves, and we are not quite comfortable with unsubstantiated statements about our devices’ security and blurry “technical” documentation provided by RIM. So we dig.

Our first two targets are the apps providing secure storage of sensitive data: BlackBerry Password Keeper and BlackBerry Wallet. These applications are provided by RIM for free; Password Keeper is even included with each installation of BlackBerry OS. The two apps are the recommended way to store login credentials and other sensitive data such as credit card numbers. The data stored in those two apps could also be a wealth of information for investigators. According to RIM, all data is securely encrypted with AES-256. The encryption key is derived from user-specified master password, which can be different from device password. Password Keeper and Wallet master passwords can also be different.

Another notable fact is that Password Keeper and Wallet databases are included in the backup produced by BlackBerry Desktop Software. This means that, as a mobile forensics investigator, you can access those databases (containing encrypted data at this point) by either connecting suspects’ handset and running Desktop Software (if there is no password protection on the device) or by looking for stored device backups on suspects’ computer(s). And even if the backup you’ve been able to get a hold of is encrypted, our Elcomsoft Phone Password Breaker can recover the password for it .

Once you’ve got the (unencrypted) backup, Password Keeper and Wallet databases are accessible. The problem is that their data are still encrypted. And this is exactly what today’s EPPB release is about: recovering master passwords for Password Keeper and Wallet databases. Now you can load a BlackBerry device backup into EPPB and run password recovery against Password Keeper and Wallet databases. And what’s really good about this is that password recovery rate is great – hundreds of thousands and up to several millions passwords per second on modern CPU, depending on BlackBerry OS version. To the best of our knowledge, there were no tools capable of doing this until now, so we're proud to be the world’s first again, offering our customers unique functionality that’s not available in other vendors’ products.

So, you were able to discover the master password, what's next? Right now you have two options:

• Use BlackBerry Simulator, restore the backup to it, and use the recovered master password(s) to enter Password Keeper and/or Wallet. Access stored data as usual.
• Use Elcomsoft BlackBerry Backup Explorer, which can now show Password Keeper and Wallet data (as of version 9.61 being released today).

The third option to view Password Keeper and Wallet data within EPPB itself will be probably added with the next update. Speaking of updates, I'd like to tell you that this BlackBerry-related addition is really small compared to what's in the queue. If things go well, we hope to release "the next big thing" within 1-1.5 months from now. You're going to love it, I promise .

P.S. For those technically inclined out there, here’s a brief summary:

BlackBerry Password Keeper database format and protection is the same for OS 5, OS 6, and OS7. Per-item encryption key is derived by computing 3 (three) iterations of PBKDF2-SHA1 with master password and per-item salt.

Wallet database format and protection differs between OS 5 and OS 6/7.

For Wallet in OS 5, per-item encryption key is derived by computing 3 (three) iterations of PBKDF2-SHA1 with SHA-256 hash of master password and per-item salt.

For Wallet in OS 6 and OS 7, per-item encryption key is derived by computing a random number of iterations (between 50 and 100) of PBKDF2-SHA1 with SHA-512 hash of master password and per-item salt.

Encryption in all above formats is AES-256 in ECB (!) mode, SHA-1 hash of the data is appended before encrypting; data is padded as per PKCS #5.

In my opinion, should RIM have opted to be more open about their security mechanisms, someone (maybe even someone from their own team) could possibly point out that the level of protection against password recovery attacks is not sufficient for 2011.

In its next part about iTunes Backups Kiel touches upon Elcomsoft Phone Password Breaker which virtually crunches backup passwords at speed of 35000 passwords per second (with AMD Radeon HD 5970) using both brute force and dictionary attacks, here are some benchmarks.

It seems the paper does not miss out on any nuance about iOS 4 and provides practical advice to either avoid or prevent from the depressing outcomes, such as loss of data. Closer to the end of the paper you will also find several sagacious tips for using the devices within organizations, including passcode management, a so called “first line of defense” which according Kiel’s view “can be matched to existing password policies”, however he inclines to use passwords instead of 4 digit passcodes.

And in conclusion the author discovers that smartphone and tablet security measurements resemble the ones of laptops, because they all belong to mobile devices.  Find out more details in the source itself: http://www.sans.org/reading_room/whitepapers/pda/security-implications-ios_33724
 

• “I don't have Outlook, so I can't do it [synchronization] automatically, but I really need you guys' help.”
• “Unfortunately I had to wipe out the device completely after applying the latest OS update which screwed up my contacts and calendar.”
• “The latest verson of the software (bundle 1656) INSTANTLY caused my contacts on my BB to be wiped out and replaced with 657 blank entries.”
• “Is there any way I can export my address book to oulook or windows contacts or whatever so i can put them on my friends iphone?”
• “How can I get my 20,000+ contacts from my Curve 8530 to a CSV or exported somewhere online? It seems like there is no way without syncing software crashing because of the time a transfer takes…”

It looks like currently the main problem with BB’s usability is absence of proper synchronization.  Well, to tell the truth it WAS a problem, which is now at least partly solved. With our new tool (EBBE) you can export all contacts saved in BB backup into the single CSV file, as the most universal format supported by all email clients (including web-based email services), and then do whatever you need – import these contacts into your favorite client (regardless an operating system – Windows, Mac OS, Lunix etc), merge with the contacts stored in the other smartphone, open in Excel etc. How that? Just using Elcomsoft Blackberry Backup Explorer.  With this simple though nice and effective utility you can extract, display, print or export BlackBerry backup information. A whole array of all sorts of data can be at hand in a matter of minutes: pictures, messages, URLs, contacts, certificates, call logs, etc.  – literally everything is at your disposal anytime and in any convenient format, be it PDF, HTML, DOC, RTF (which btw include a hyperlinked Table of Contents)or other preferable file formats like CHM, HLP, TXT, MDB, XLS, TIFF, DCX, VCF (vCard), VCS (vCalendar) and even more.   I’m sure most of business people using BlackBerry might have encountered an urgent necessity to restore some correspondence to read it on PC/Mac, print it out, or forward to a partner, I suppose it’s a frequent situation. Now, you don’t have to be bound by Outlook to process your BB emails. It becomes a 3 step procedure with Elcomsoft Blackberry Backup Explorer. First, you start on the tool and open your BB backup. Second, you choose “messages” and filter them by contact (using familiar fields To and From), subject, date (see, you can sort them just as you like) and even manage their sequence. And finally – drum roll – save the correspondence in any convenient file format. That’s it. In fact, Elcomsoft Blackberry Backup Explorer is a perfect tool for forensics experts to get BlackBerry backup content in a perfectly structured and readable form. As said “no more secrets, no more lies, see right through your alibis…”, © Papa Roach. And even though experts may require a password to the encrypted backup, it’s not a problem when you have Elcomsoft Phone Password Breaker, unless you know the password some other way

In short, standard key-derivation function, PBKDF2, is used in a very strange way, to say the least. Where Apple has used 2’000 iterations in iOS 3.x, and 10’000 iterations in iOS 4.x, BlackBerry uses only one.

So password verification is (was) so fast/simple that we did not care about implementing it on the GPU — modern CPU is able to crack almost 8 million passwords per second (thanks to multi-threading and AES-NI). We would not call that the vulnerability, but still the weak link.

But new versions of BlackBerry Desktop Software have been released reсently (6.0 for Windows and 2.0 for Mac). And as always, there are bad news and there are good news.

Bad news (for those who forgot his own password): there are 20,000 PBKDF2 iterations now (yes, two times more than in iOS 4! ). That means that even 6-core Intel CPU can crack not more than 2,000 passwords per second only.

Good news (for the same audience): new version of Elcomsoft Phone Password Breaker not only supports the BlackBerry files with new/improved encryption, but supports GPU acceleration as well (previously, it was available for iTunes backups only). With it, we can get about 7,000 passwords per second on NVIDIA GeForce GTX 580, and about 20,000 p/s on ATI Radeon HD 5970. Also, AMD Radeon HD 6970 is now supported (though we have not tested our code on this card, sorry).

Password recovery is one of most CPU-intensive tasks, and it fits best into multi-processor architecture. Every CPU (or CPU core) get its own portion of passwords to try (i.e. to check their validness), and they all work in parallel. As simple as that.

So what we’re doing in our software is running multiple threads – as many as the number of CPUs (or cores) available. And the rest is being done by the operating system, that assigns the threads to cores (well, in most cases we don’t care what particular core is going to execute a particular thread, because they are all equal; the only exception is when one or more of the cores is doing something already, I mean something CPU-intensive as well).

There is also such technology as Hyper-threading. With it, CPU exposes two virtual cores for each physical one it has, allowing operating system to run more threads simultaneously thus better utilizing CPU resources.

Now how it looks in practice. We have built the system based on one of the top Intel desktop CPUs – Intel Core i7-970. It has as many as 6 (yes, six!) cores running at 3.2 GHz, plus hyper-threading, so the number of virtual processors is twelve. This CPU is produced using (relatively new) 32 nm process, so power consumption is surprisingly not very high (130 W), but well designed cooling is still strictly recommended (even if you’re not playing the overclocker’s game).

Obviously, there is no reason to run more than 12 compute-intensive threads on this CPU, while the minimum number of threads is just one (you bet! ); we have not tried ALL variations from 1 to 12, but just some. What we were doing on this number-crunching twelve-heads monster is cracking the Blackberry backup file (using Elcomsoft Phone Password Breaker, of course). Here are the results:

The numbers are thousands passwords per second – so yes, the maximum performance we have got is well over 7 million (passwords per second). That means if the password is 7 chars long and contains small and capital letters, it will be cracked in a day and a half. Or if small (or capital) letters plus digits – less than 3 hours. And as you can see, the speed increases absolutely linearly up to 6 threads (according to the number of physical, not virtual cores). But when we double the number of threads (up to 12), the speed increases from 6,44 million passwords per second to 7,44 million per second only. So just 15% performance increase – but I wanted to remind you that the number of ALUs (arithmetic logic units) is still six. So hyper-threading does not double the speed, but still helps.

But 12 (virtual) cores is not the only strong side of this CPU. Also, it has the Westmere microarchitecture. That means (above many other things) that it features the new instruction set called Intel Advanced Encryption Standard Instruction Set (AES-NI), which is intended for hardware acceleration of AES. And as far as password verification for Blackberry backups uses AES, we do have hardware acceleration in EPPB with AES-NI (when it is supported by the hardware) as well. The results are (for one and twelve threads):

The first bar shows the speed with “old style” code (SSE2, in fact), and the second one with AES-NI. So the speed improvement is about 1.5 times – may be it sounds not so impressive as GPU acceleration, but it is just a free “bonus”! If, of course, you have an appropriate processor, in particular one of these:

• Gulftown (Core i7-9xx, Xeon 36xx, Xeon 56xx)
• Clarkdale (except Core i3, so just Core i5-6xx, and some Xeons)
• Arrandale (except Core i3 and Core i5-4xxM)

So, to make it simpler: most Core i5 processors have AES-NI supported, as well as six-core Intel Core i7 (9xx). If you have one of those, you can now break Blackberry backups about 1.5 times faster than you thought .

There is one [minor] problem, though. If the time needed to verify the password is comparable to the time needed to generate the [next] password, the performance start to drop. With the brute-force attack, it starts with 8 million passwords per second; with the dictionary attack much earlier – even with 12 threads, the resulting speed is about 2 million passwords per second only. The reason is pretty simple: we are not able to generate passwords that fast, especially when we perform all those nice mutations of wordlists passwords (changing the letter case, adding or replacing symbols etc). CPU verifies the password faster than we provide it with the new one .

Keychain Explorer

This feature allows to view contents of keychain included with encrypted device backup.

Mac users are probably familiar with concept of keychain — it is a centralized, system-wide storage where application can store information they consider sensitive. Typically, such information includes passwords, encryption keys and certificates, but in principle it can be anything. Data in keychain is cryptographically protected by OS and user password is required to access it. The closest Windows equivalent for keychain is probably Data Protection API.

iOS-based devices also have a keychain, but instead of user password, embedded cryptographic key is used to protect its contents. This key is unique to each device and so far there are no way to reliably extract it from the device.

Apple recommends iOS application developers to use keychain for storing passwords and other sensitive information, and one reason for this is that it never leaves device unencrypted. Here’s an excerpt from Keychain Service Programming Guide:

In iOS, an application always has access to its own keychain items and does not have access to any other application’s items. The system generates its own password for the keychain, and stores the key on the device in such a way that it is not accessible to any application. When a user backs up iPhone data, the keychain data is backed up but the secrets in the keychain remain encrypted in the backup. The keychain password is not included in the backup. Therefore, passwords and other secrets stored in the keychain on the iPhone cannot be used by someone who gains access to an iPhone backup. For this reason, it is important to use the keychain on iPhone to store passwords and other data (such as cookies) that can be used to log into secure web sites.

Prior to iOS 4 keychain was also included in the backup ‘”as is”, i.e. all data inside was encrypted using unique device key. This meant that it was not possible to restore keychain onto another device — it will try to decrypt data with key which is different from one used to encrypt data. Naturally, this will fail and all data in keychain will be lost.

To address this issue, Apple changed the way keychain backup works in iOS 4. Now, if you’re creating encrypted backup (i.e. you’ve set up a password to protect backup) then keychain data will be re-encrypted using encryption key derived from backup password and thus ca be restored on another device (provided backup password, of course). If you haven’t set backup password, then everything works like before iOS 4 — keychain encrypted on device key is included in the backup.

Elcomsoft iPhone Password Breaker now allows you to view contents of keychain from encrypted backup of devices running iOS 4. You will need to provide password, of course. Here’s screenshot of Keychain Explorer showing (some) contents of my iPhone’s keychain:

There are passwords for all Wi-Fi hotspots I have ever joined (and haven’t pushed “Forget this Network” button), for my email, Twitter, and WordPress accounts, as well as Safari saved passwords and even my Lufthansa frequent flyer number and password! And I don’t use Facebook/LinkedIn/anything else on my phone — otherwise I guess credentials for those will be also included in the keychain.

Keychain Explorer will work only against backup which is encrypted. If you happen to have an iOS 4 device and want to get password from it — set a backup password in iTunes, backup device, use Keychain Explorer to view and/or export keychain passwords, and, finally, remove backup password in iTunes.

Password Cache

This feature is far less exciting than Keychain Explorer, but we believe it should improve user experience with Elcomsoft iPhone Password Breaker.

The idea is simple: all passwords which are found by EPPB or which are used to open backup in Keychain Explorer are stored in password cache. When you later try to open backup in Keychain Explorer or recover a backup password, program first checks password cache for correct password.

Passwords in cache are stored using secure encryption.

Also, there is a new EPPB FAQ online. Worth reading if you’re thinking of purchasing EPPB or want to learn more about it.

There is at least one really big update for EPPB coming in September or October, so stay tuned!

A low-cost service for penetration testers that checks the security of wireless networks by running passwords against a 135-million-word dictionary has been recently unveiled. The so-called WPA Cracker is a cloud-based service that accesses a 400-CPU cluster. For $34, it can run a password against all 135 million entries in about 20 minutes. Want to pay less, do it for $17 and wait 40 minutes to see the results.

Another notable feature is the use of the dictionary that has been set up specifically for cracking Wi-Fi Protected Access passwords. While Windows, UNIX and other systems allow short passwords, WPA pass codes must contain a minimum of eight characters. Its entries use a variety of words, common phrases and "elite speak" that have been compiled with WPA networks in mind.

WPA Cracker is used by capturing a wireless network's handshake locally and then uploading it, along with the network name. The service then compares the PBKDF2, or Password-Based Key Derivation Function, against the dictionary. The approach makes sense, considering each handshake is salted using the network's ESSID, a technique that makes rainbow tables only so useful.

Everything seems to be perfect, but for the fact that there exists another alternative to crack WPA passwords which allows to reach the same speed. Just instead of installing a 400-CPU cluster, it’s possible to set 4 top Radeons or about two Teslas and try Elcomsoft Wireless Security Auditor.