Archive for the ‘Hardware’ Category

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!

New version of EPPB: Recovering Master Passwords for BlackBerry Password Keeper and BlackBerry Wallet

Tuesday, August 30th, 2011

Conferences are good. When attending Mobile Forensics Conference this year (and demoing our iOS Forensic Toolkit), we received a lot of requests for tools aimed at BlackBerry forensics. Sorry guys, we can’t offer the solution for physical acquisition of BlackBerries (yet), but there is something new we can offer right now.

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. (more…)

iOS Forensic Toolkit: Keychain Decryption, Logical Acquisition, iOS 4.3.4, and Other Goodies

Monday, July 25th, 2011
 
You might have heard about our new product – iOS Forensic Toolkit. In fact, if you are involved in mobile phone and smartphone forensics, you almost certainly have. In case our previous announcements haven’t reached you, iOS Forensic Toolkit is a set of tools designed to perform physical acquisition of iPhone/iPad/iPod Touch devices and decrypt the resulting images. This decryption capability is unique and allows one to obtain a fully usable image of the device’s file system with the contents of each and every file decrypted and available for analysis. And the fact is, with today’s update, iOS Forensic Toolkit is much more than just that.
 
(more…)

Extracting the File System from iPhone/iPad/iPod Touch Devices

Monday, May 23rd, 2011

In our previous blog post we have described how we broke the encryption in iOS devices. One important thing was left out of that article for the sake of readability, and that is how we actually acquire the image of the file system of the device. Indeed, in order to decrypt the file system, we need to extract it from the device first.

(more…)

BlackBerry password cracking: multi-threaded, with hardware-accelerated AES

Thursday, December 9th, 2010

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).

(more…)

Canon cannot or mustn’t provide image validation feature?

Tuesday, November 30th, 2010

A true security system cannot be so fragile: Canon Original Data Security broken…

Find 3 differences from original Now if your partner gets a compromising anonymous image where you are enjoying yourself with nice blond with blue eyes or charming young man, don’t panic and don’t get upset, you can easily prove it is just a fake (even if it’s not 😉 ).  Seriously, how can we trust photographic evidence in the era of Photoshop and other designer tools? The genuineness of a digital image can only be proven by special digital tools…like OSK-E3?

Unfortunately or maybe fortunately, it turned out that OSK-E3 (Canon Original Data Security Kit) cannot guarantee image authenticity, because now it can recognize even fake images as true and genuine. However, the problem is not in OSK-E3, it is in Canon Original Data Security system implemented in most modern Canon DSLR (Digital Single-Lens Reflex) cameras.

Now it’s possible (well, Dmitry did it recently and who knows if somebody could do it earlier 😉 ) to dump camera’s memory, extract secret keys from the camera, and calculate ODD (= Original Decision Data) which answer for any changes done to the image. And thus name the modified image as original one.

What Canon can do? It seems like Canon can nothing do with their models right now, because the fundamental problem lies not in the software. Changing the software could possibly solve the question, until someone again finds its vulnerability. But adding cryptoprocessors that won’t expose the secret key and thus will prevent from any penetrations from outside would close the loophole.

Have a look at some of our fake images that pass verification test by OSK-E3: http://www.elcomsoft.com/canon.html

So, can you now trust Canon’s OSK decision if an image is original or not?

iPhone 4 Performance

Wednesday, September 15th, 2010

Finally, we’ve got our first iPhone 4 in office. And what was the first thing we did with it? Yes, test its performance to complete table in my previous post.

This brand-new iPhone 4 is capable of doing 1.4 millions MD5 iterations per second, about 35% more than iPhone 3GS.

I haven’t found any information on iPhone 4CPU clock frequency, but if we assume that it uses same chip as iPad (which seems to be the case), then exhibited performance corresponds to roughly 775 MHz.

Measuring iPhone Performance

Thursday, August 5th, 2010

I’ve had plans to create some kind of performance measurement app for iPhone/iPod/iPad for quite a bit time of already, and after reading recent reports that iOS 4 is very slow on iPhone 3G I thought that time had finally come.

So I’ve quickly coded an app which computed performance in MD5 hash computations per second, and here are the results:

Device CPU Frequency Thousands MD5 per second
iPhone 3G 412 MHz 350
iPhone 3GS 600 MHz

1050

iPad 1 GHz 1800

The performance scales almost linearly (with respect to CPU frequency) for iPhone 3GS and iPad.

For iPhone 3G this is, however, not the case. Although CPU clock is only 1.5 times slower when compared to iPhone 3GS, overall performance is three times slower.

Puzzled, I did some research and found out that iPhone 3G and iPhone 3GS are using very different CPU cores indeed (link). The key difference is that iPhone 3GS uses dual-issue superscalar CPU which allows executing two instruction per clock. iPhone 3G utilized single-issue scalar core, and is thus limited to executing single instruction per clock. This perfectly explains missing factor of two in performance vs. clock rate difference between iPhone 3G and 3GS.

ATI is at it. Again.

Wednesday, May 12th, 2010

Two months ago I wrote a blog post "ATI and NVIDIA: Making Friends out of Enemies" where (among other things) I wrote:

Developing software for ATI cards is (okay — was) a nightmare. In 2009 ATI quietly introduced two changes in their drivers which made previously perfectly functional and compatible applications to crash (if you are curious: with Catalyst 9.2 or 9.3 they’ve changed names of supporting DLLs bundled with drivers; with Catalyst 9.9 or 9.10 they’ve probably changed format of underlying binary so that anything compiled and linked in with earlier versions caused a driver to crash).

Well, with the release of Catalyst 10.4 drivers ATI is again at it. This time problem only affects users who have display adapters from different vendors in their computer. Applications utilizing ATI Stream will work on such configurations just fine with Catalyst 10.3, but once you upgrade to 10.4, applications will crash with faulting module being aticaldd.dll, a part of ATI Display driver. Kinda embarrassing, I would say. Regression testing is really something one with millions of users should consider.

Users of our software relying on ATI hardware accelerations (as well as any other ATI Stream enabled applications) should not update to 10.4 if ATI Readeon is not the only card in their computer.