Archive for March, 2012

Mobile password keepers don’t keep the word

Friday, March 16th, 2012

We’ve analyzed 17 popular password management apps available for Apple iOS and BlackBerry platforms, including free and commercially available tools, and discovered that no single password keeper app provides a claimed level of protection. None of the password keepers except one are utilizing iOS or BlackBerry existing security model, relying on their own implementation of data encryption. ElcomSoft research shows that those implementations fail to provide an adequate level of protection, allowing an attacker to recover encrypted information in less than a day if user-selectable Master Password is 10 to 14 digits long.

The Research

Both platforms being analyzed, BlackBerry and Apple iOS, feature comprehensive data security mechanisms built-in. Exact level of security varies depending on which version of Apple iOS is used or how BlackBerry users treat memory card encryption. However, in general, the level of protection provided by each respective platform is adequate if users follow general precautions.

The same cannot be said about most password management apps ElcomSoft analyzed. Only one password management app for the iOS platform, DataVault Password Manager, stores passwords in secure iOS-encrypted keychain. This level of protection is good enough by itself; however, that app provides little extra protection above iOS default levels. Skipping the complex math (which is available in the original whitepaper), information stored in 10 out of 17 password keepers can be recovered in a day – guaranteed if user-selectable master password is 10 to 14 digits long, depending on application. What about the other seven keepers? Passwords stored in them can be recovered instantly because passwords are either stored unencrypted, are encrypted with a fixed password, or are simply misusing cryptography.

Interestingly, BlackBerry Password Keeper and Wallet 1.0 and 1.2 offer very little protection on top of BlackBerry device password. Once the device password is known, master password(s) for Wallet and/or Password Keeper can be recovered with relative ease.

In the research we used both Elcomsoft Phone Password Breaker and Elcomsoft iOS Forensic Toolkit.

Recommendations

Many password management apps offered on the market do not provide adequate level of security. ElcomSoft strongly encourages users not to rely on their advertised security, but rather use iOS or BlackBerry built-in security features.

In order to keep their data safe, Apple users should set up a passcode and a really complex backup password. The unlocked device should not be plugged to non-trusted computers to prevent creation of pairing. Unencrypted backups should not be created.

BlackBerry users should set up a device password and make sure media card encryption is off or set to “Encrypt using Device Key” or “Encrypt using Device Key and Device Password” in order to prevent attackers from recovering device password based on what’s stored on the media card. Unencrypted device backups should not be created.

The full whitepaper is available at http://www.elcomsoft.com/WP/BH-EU-2012-WP.pdf

Updated iOS Forensic Toolkit Ready for iOS 5.1, Tries Top 100 Common Passcodes First

Monday, March 12th, 2012

Today, we released an updated version of iOS Forensic Toolkit. It’s not as much of an update to make big news shout, but the number of improvements here and there warrants a blog post, and is definitely worth upgrading to if you’re dealing with multiple iPhones on a daily basis.

The newly updated Elcomsoft iOS Forensic Toolkit now supports iOS 5.1 and adds a number of small and not-so-small enhancements to the already sound package. The ability to try top 100 most common passcodes gives a chance to recover a passcode in a matter of minutes. There’s one more thing new with the updated iOS Forensic Toolkit: an iPhone booted with iOS Forensic Toolkit now displays a small ElcomSoft logo instead of the default one.

Top 100 Passcodes

We’ve seen lots of iPhones. Most are locked with simple, easy to remember passcodes. We were able to compile a list of most commonly used passcodes. There are the obvious ones like 1111, 2222, 1234, 5555, vertical raw 2580, and there are many ‘convenience’ passcodes that are just easier to remember or enter on the iPhone’s screen. There’s a whole range of passcodes representing possible dates significant to iPhone owners; these passcodes range from early 1930 to 2020. The updated iOS Forensic Toolkit will now try these passcodes before launching a brute-force attack.

How good are the chances? A recent study demonstrated that as many as 15% of all passcode sets are represented by only 10 different passcodes (out of 10,000 possible combinations). That’s 1 in 7 iPhones unlocked within minutes or even seconds.

New Logo

iPhones booted by iOS Forensic Toolkit will now display ElcomSoft logo when loading. Not a big deal, but a nice and pleasant for us visual effect :)

We also added a few other improvements and enhancements here and there, making the new version a recommended update.

Breaking Wi-Fi Passwords: Exploiting the Human Factor

Thursday, March 8th, 2012

Attacking Wi-Fi passwords is near hopeless if a wireless hotspot is properly secured. Today’s wireless security algorithms such as WPA are using cryptographically sound encryption with long passwords. The standard enforces the use of passwords that are at least 8 characters long. Encryption used to protect wireless communications is tough and very slow to break. Brute-forcing WPA/WPA2 PSK passwords remains a hopeless enterprise even if a horde of GPU’s is employed. Which is, in general, good for security – but may as well inspire a false sense of security if a weak, easy to guess password is selected.

Elcomsoft Wireless Security Auditor is one tool to test how strong the company’s Wi-Fi passwords are. After checking the obvious vulnerabilities such as open wireless access points and the use of obsolete WEP encryption, system administrators  will use Wireless Security Auditor that tries to ‘guess’ passwords protecting the company’s wireless traffic. In previous versions, the guessing was limited to certain dictionary attacks with permutations. The new version gets smarter, employing most of the same guessing techniques that are likely to be used by an intruder.

Humans are the weakest link in wireless security. Selecting a weak, easy to guess password easily overcomes all the benefits provided by extensive security measures implemented in WPA/WPA2 protection. In many companies, employees are likely to choose simple, easy to remember passwords, thus compromising their entire corporate network.

The New Attacks
The new attacks help Elcomsoft Wireless Security Auditor recover weak passwords, revealing existing weaknesses and vulnerabilities in companies’ wireless network infrastructure.

Word Attack
If it’s known that a password consists of a certain word, the Word attack will attempt to recover that password by trying heavily modified versions of that word. This attack only has two options: you can set the source word and you can disable all permutations except changing the letter case. In addition, we can apply permutations to the source word first, forming a small dictionary; then perform a full dictionary attack, applying various permutations to all words from the newly formed list.

Mask Attack
Certain passwords or password ranges may be known. The mask attack allows creating a flexible mask, brute-forcing the resulting limited combination of passwords very quickly. The masks can be very flexible. One can specify placeholders for static characters, letter case, as well as full or limited range of special characters, digits or letters. Think of the Mask attack as an easy (and very flexible) way to check all obvious passwords from Password000 to Password999.

Combination Attack
You have two dictionaries. We combine each word from one dictionary with every word from another. By default, the words are combined as is, but you can increase the number of possible combinations by allowing delimiters (such as space, underscore and other signs), checking upper/lower case combinations or using extra mutations.

Hybrid Attack
This is one of the more interesting attacks out there. In a sense, Hybrid attacks come very close to how real human intruders think. The Hybrid attacks integrates ElcomSoft’s experience in dealing with password recovery. We’ve seen many (think thousands) weak passwords, and were able to generalize ways people are making them. Dates, names, dictionary words, phrases and simple character substitutions are the most common things folks do to make their passwords ‘hard to guess’. The new Hybrid attack will handle the ‘hard’ part.

Technically, the Hybrid attack uses one or more dictionaries with common words, and one or more .rul files specifying mutation rules. We’re supplying a few files with the most commonly used mutation rules:

Common.rul – integrates the most commonly used mutations. In a word, we’ve seen those types of passwords a lot, so we were able to generalize and derive these rules.
Dates.rul – pretty much what it says. Combines dictionary words with dates in various formats. This is a pretty common way to construct weak passwords.
L33t.rul – the “leet” lingo. Uses various combinations of ASCII characters to replace Latin letters. C001 hackers make super-strong passwords with these… It takes minutes to try them all.
Numbers.rul – mixes dictionary words with various number combinations.

ElcomSoft Half-Switches to OpenCL

Thursday, March 8th, 2012

OpenCL_Artwork

ElcomSoft has recently announced the switch to OpenCL, an open cross-platform architecture offering universal, future-proof accessibility to a wide range of acceleration hardware. We’re actively using GPU acceleration for breaking passwords faster. No issues with NVIDIA hardware, but working with AMD devices has always been a trouble.

So we jumped in, embedding OpenCL support into Elcomsoft Phone Password Breaker and Wireless Security Auditor. As an immediate benefit, we were able to add long-awaited support for AMD’s latest generation of graphic accelerators, the AMD Radeon™ HD 7000 Series currently including AMD Radeon™ HD 7750, 7770, 7950, and 7970 models. Headache-free support for future generations of acceleration hardware is icing on the cake.

OpenCL_Benchmark

After switching to OpenCL, we further optimized acceleration code for AMD hardware, squeezing up to 50% more speed out of the same boards. This isn’t something to sniff at, as even a few per cents of performance can save hours when breaking long, complex passwords.

OpenCL vs. CUDA

AMD goes OpenCL. What about NVIDIA? Technically, we could have handled NVIDIA accelerators the same way, via OpenCL (it’s a cross-platform architecture, remember?) In that case, we would be getting a simpler, easier to maintain product line with a single acceleration technology to support.

However, we’re not making a full commitment just yet. While some of us love open-source, publicly maintained cross-platform solutions, these are not always the best thing to do in commercial apps. And for a moment here, we’re not talking about licensing issues. Instead, we’re talking sheer speed. While OpenCL is a great platform, offering future-proof, headache-free support of future acceleration hardware, it’s still an extra abstraction layer sitting between the hardware and our code. It’s great when we’re talking AMD, a company known for a rather inconsistent developer support for its latest hardware; there’s simply no alternative. If we wanted access to their latest state-of-the-art graphic accelerators such as AMD Radeon™ HD 7000 Series boards, it was OpenCL or nothing.

We didn’t have such issues with AMD’s main competitor, NVIDIA. NVIDIA was the first player on this arena, being the first to release graphical accelerators capable of fixed-point calculations. It was also the first to offer non-gaming developers access to sheer computational power of its GPU units by releasing CUDA, an application programming interface enabling developers use its hardware in non-graphical applications. From the very beginning and up to this day, CUDA maintains universal compatibility among the many generations of NVIDIA graphical accelerators. The same simply that can’t be said about AMD.

So is it the “if it ain’t broke, don’t fix it” approach? Partly, but that’s just one side of the coin. CUDA simply offers better performance than OpenCL. The speed benefit is slight, but it is there, and it’s significant enough to get noticed. We want to squeeze every last bit of performance out of our products and computers’ hardware, and that’s the real reason we’ll be staying with CUDA for as long as it’s supported – or until OpenCL offers performance that can match that of CUDA.

Did we make the switch half-heartedly? Nope. We’re enthusiastic about the future of OpenCL, looking forward to run our software on new acceleration platforms. But we don’t want to abandon our heritage code – especially if it performs better than its replacement!