Archive for the ‘Cryptography’ Category
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.
Most modern CPUs are multi-core – it is not easy to find even a laptop with less than two cores these days. And for desktops, 4 cores are usual now.
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).
Today we have released Elcomsoft iPhone Password Breaker 1.20 which introduces two new features and fixes few minor issues.
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.
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!
It’s a well-know fact that WPA-PSK networks are vulnerable to dictionary attacks, though one cannot but admit that running a respectable-sized dictionary over a WPA network handshake can take days or weeks.
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.
One of our customers sent me two Excel XLA add-ins. When I tried to open that file in the VBA Editor — the "Project is locked" message appeared. Add-in has been already unlocked by our VBA password recovery tool. According to Microsoft article this message may appear in two cases: when the macro is protected by password or when it is digitally signed. I analysed the macro password record and found that the password is empty. MS Excel also showed me that macro have no any digital signatures. Then I looked into protection record with more attention and for example found that:
"[Host Extender Info]" string is replaced to "[Host Extender 1nfo]".
There were some additional similar changes and finally I found that the macro has damaged digital signature record. It’s ignored when macro is running but when we try to open the macro to view — Excel shows the error.
Microsoft has very weak VBA macro protection. That’s why developers are searching for non-standard protection methods. It’s not simple to reconstruct a damaged macro and it may require a lot of time.
If your macro cannot be opened by our password recovery programs — the most probable reason is custom protection that damages some technical records. I cannot say that it’s a good protection. New versions of MS Office may not work correctly with damaged files.
We are waiting for release of new Microsoft office suite – Office 2010. Right now Microsoft has only technical preview of new Office; this preview has been leaked from Microsoft and everyone can download it with the help of torrent trackers. We’ve got a copy of Office 2010 and analysed its (new) password protection.
Starting from Office 2007, Microsoft used password protection system called ECMA-376, developed by ECMA International. This standard is open and everyone can write ECMA-376 based protection which will be accepted by Microsoft Office. The standard allows to select hash and encryption algorithms as well as the number of hash rounds (up to 10 millions is allowed).
In Office 2007, ECMA-376 with SHA-1 hash and AES-128 encryption is implemented. The number of hash rounds is 50000 that makes password recovery really difficult and slow. Office 2010 also uses SHA-1 and AES-128, but the number of hash rounds is now 100000. Therefore password recovery for new Office files will be two times slower.
Here is a diagram of password recovery speed for Office 2007:
To get a speed for Office 2010, simply divide these values to 2. We’ll get about 175 pps on Core2 6600 and about 8750 pps on Tesla S1070.
Why don’t increase the number of hash rounds to 10 millions ? Security is really important but it always affects usability. The hash is calculating to verify a password and when each document block is decrypted. If we add hash rounds – the document decryption time is increased. If a document is opening in MS Office during one hour – its unacceptable despite of high security.
Anyway – Office 2010 documents will be more secure than Office 2007 ones. And the new encryption has backward compatibility – all Office 2010 documents can be opened in Office 2007.
Time for shoulder surfing is gone, today we have more sophisticated ways to track what you are typing on your keyboard. A series of appearing keyboard attacks yet again prove its incapability of keeping secretes. Let’s see what we have…
About a month ago annual Eurocrypt conference took place in Cologne, Germany. This is rather academic event (as most if not all events held by IACR) so it is not always easy to read its proceedings filled with formulas and theorems. Nonetheless there are usually couple of very interesting works presented at each such event. Let me tell you a little bit about this year’s highlights.
Hardware acceleration of password recovery has been a hot topic for quite some time already. We were the first to adopt widely available graphic cards for this purpose and we’re proud of this. Today I’d like to share some thoughts on hardware acceleration for password recovery, its past, present, and future. I will also cover the most frequently asked questions regarding GPUs.