ElcomSoft blog

13 Years of GPU Acceleration

Thu, 22 Oct 2020 06:59:12 GMT

Today, we have an important date. It’s been 13 years since we invented a technique that reshaped the landscape of modern password recovery. 13 years ago, we introduced GPU acceleration in our then-current password recovery tool, enabling the use of consumer-grade gaming video cards for breaking passwords orders of magnitude faster.

With today’s proliferation of everything AI relying on GPU units our 13-year-old achievement seems obvious in retrospect. Back then, it was not only far from the obvious, but took us years to design and to implement. It was so innovative that TheInquirer wrote an article about our tool. The original is no longer available, but we saved a quote:

PESKY RUSSIANS have come up with a novel way of using Nvidia’s graphics hardware – cracking passwords.
INQ readers will long be familiar with the concept of the GPGPU, and the green team’s latest CUDA development kit. Folks batting for the greens have been lauding the processing power of the 8800 when it comes to complex oil, gas and financial simulations.
But those crazy Ruskis have come up with a use that is rather more nefarious. Elcomsoft, based in Moscow, has created a password cracking technique that uses the same parallel processing concepts to speed up dictionary and brute force attacks on things like Windows Vista password logins. The firm says that the 8800 is up to 25 times faster than a CPU, normally used for such tasks.

Why would anyone want to use a video card to break passwords? It’s a matter of fact that modern software (at least in most cases, with several notable exceptions) uses strong encryption to protect the data. Hundreds of thousands rounds of hashing are common to derive the encryption key from the password, making such passwords extremely difficult and time-consuming to break. The resources of the internal CPU are quickly exhausted when attacking passwords. This is expected behavior, as manufacturers try timing the strength of their security settings such that it only takes a split (but noticeable) second on an “average” computer to unlock the encrypted file, document, database or disk volume.

These “split seconds” accumulate quickly, making the CPU choke with trillions of instructions. While there is only so much time the user is willing to wait for a password-protected document to open or an encrypted volume to mount, the delay of about 0.3 seconds is generally viewed as acceptable. It is important to note that that every OEM makes use of the computer’s CPU exclusively when it comes to verifying the password. Moreover, they are aiming at an “average” system, that has usually an old and almost never a high-end CPU. On experts’ computers, which are modern and utilize high-end hardware, It is not uncommon to see a high-end CPU crunching passwords at the speed of around 10 to 15 passwords per second. This was the case 13 years ago with the software used back then, and this is the case today with modern software. Obviously, these kind of speeds are far from acceptable.

This is where we needed a new technology to break passwords faster. When it comes to the choice of hardware that can be utilized to speed up the recovery, there aren’t really a lot of options available. Supercomputers are great, but they are more of a theoretical possibility for a humble law enforcement expert. FPGA-based solutions (e.g. Tableau) are better. Specifically tailored to these tasks, they demonstrated commendable performance with high reliability and low power consumption. The problem? Lots of them. Non-standard software APIs, highly custom everything and the high price point made these dedicated adapters pale in comparison to… Video cards.

Yes, your regular gaming video cards.

Video cards can break passwords

The speed of a single CPU (or multiple CPUs if that matters) is not nearly enough to break today’s passwords. The hundreds of thousands or even millions hash iterations slow down the recovery to the crawl. In the end, the CPU becomes a bottleneck. 13 years ago, we saw the need for additional computation power. Lots of it.

At the time, video cards were mostly used for gaming. The then-current video cards such as the NVIDIA GeForce 8500GT were only usable for gaming.

Then, also in 2007, NVIDIA created CUDA.

CUDA is a hardware-accelerated parallel computing platform that offers the developers an API, which, in turn, enables the use of GPU cores for general-purpose computing.

GPUs had evolved into highly parallel multi-core systems, allowing very efficient manipulation of large blocks of data. This design is more effective than general-purpose central processing unit (CPUs) for algorithms in situations where processing large blocks of data is done in parallel. (Source)

Processing large blocks of data is exactly what we needed. This is where we started thinking about using (at the time, only NVIDIA) video cards to accelerate password recovery. With GPU acceleration offloading the most computational-intensive calculations onto the highly scalable video cards, we hoped to achieve at least 10x the performance of a CPU. The reality far exceeded our expectations. The hundreds of GPU cores, used in parallel, were able to deliver the speed exceeding the metrics of a high-end CPU by the factor of 100x to 250x depending on the format.

Rest assured, the journey was neither easy nor straightforward. The most difficult thing to do was to break down the job into tiny pieces, then correctly parallelizing each piece on the hundreds of individual computational units. There are thousands of processors in a single video card, and one must selecting the number of threads depending on the specific processor in the correct manner.

If the GPU is vastly outperforming the CPU, the latter becomes a bottleneck. If the given algorithm for a certain format is too fast for the CPU to handle, then the potential passwords must be generated directly on the GPU itself. If that is not done, the CPU chokes, while the GPU idles. This was one of the most difficult things to do. Making the GPU calculate a hash value is one thing; making it do the various rules, mutations and perform other complex rules on which the next password in the pipeline will be based is quite another.

AMD, Intel and OpenCL

Then came AMD support. Back then, the technology was still owned by the company named ATI (now part of AMD). We were the first on the market to support AMD boards, first via their native API.

Then things began standardizing. In 2015, NVIDIA added OpenCL support to their range of CUDA-capable video cards. This trend was backed by other players including AMD and Intel. OpenCL is an open standard. Its cross-platform framework covers heterogeneous code execution on multiple CPU and GPU units, as well as some DSP and FPGA hardware that could be previously addressed exclusively via their own private APIc. For us, OpenCL became a standard, cross-platform interface for parallel computing using AMD, NVIDIA and Intel cards.

We implemented OpenCL for AMD boards and never looked back. Then we added support for Intel integrated GPU units one can find in most Intel processors. These GPUs are not very powerful, but they do speed up calculations about 2 to 2.5 times compared to not using the internal graphics.

After the initial excitement was over, we compared the performance of our OpenCL implementation on NVIDIA boards to what we had with CUDA, and found that CUDA-based acceleration gave us the performance benefit compared to OpenCL in the low tens of percentage points. This, thanks to the tight cooperation with NVIDIA engineers who had helped us throughout these years to optimize our code on their cards. So we went back to CUDA for NVIDIA boards, and are using OpenCL for everything else.

Utilizing old video cards

What if you have an existing video card installed, but want to upgrade to a newer and higher performing one? The constant upgrade cycle must come to an end. Five years ago, back in 2015, we released a solution for mixing different video cards: Breaking the Vicious Cycle of Hardware Upgrades.

What is this all about? Our new invention allows using multiple video cards together if they are running at different clock speeds, and even if they are different video cards altogether. With asynchronous computing, the password recovery tool can break jobs into smaller pieces, and feed every piece to a given video card. The asynchronous scheduler does not have to wait for a given part of the job to complete before feeding the next piece in line once one of the video cards finishes its slice.

In layman terms, this technology allows using multiple video cards of different makes and models, effectively utilizing existing hardware and squeezing the last bit of performance out of every supported component.

Our tools can utilize all GPU cores in mix-and-match scenarios if the video cards are made by different manufacturers. Whether you have a mix of AMD and NVIDIA boards or just want to make use of your computer’s built-in Intel HD Graphics cores, all of these can be used together to speed up the recovery.

How much of a benefit would an old video card provide? It depends on how old it is. Let us see the following two benchmarks:

As you can see, a 7-year-old GeForce GTX 750Ti offers the performance of some 2000 RAR5 passwords per second. By directly comparing it to the previous-generation flagship GeForce GTX 1080 we can see a 16-fold improvement with the new card’s 32,700 passwords per second. This season’s RTX 2070 with its 50,400 passwords per second is 25 times faster. Interestingly, the then top of the line Intel Xeon E5 2603 CPU (116 passwords/s) is only 4 times slower than the current consumer-grade Intel Core i7-9700K (481 password/s).

Think about it for a moment. 7 years of progress in CPU made the recovery speed 4 times better. The same 7 years in the GPU land brought us a 25-fold speed increase. Conclusion: always invest in a GPU, not CPU.

GPU in the cloud

The parallel use of multiple video cards is great if you have a data center equipped with up to date hardware. New users can experience a sticker shock when building a new system stocked with the maximum number of high-end video cards. If you rarely break passwords, you may want to consider offloading the job to the cloud. Recently, cloud service providers started equipping their virtual instances with GPU accelerators. For example, with Amazon P2, you can spec up to 8 GPUs per instance. Our tools make it easy to deploy in the cloud; read Breaking Passwords in the Cloud: Using Amazon P2 Instances for details.

Other uses for GPU acceleration

GPU acceleration is not exclusive to password recovery; far from it. Today, GPU acceleration is used for many vastly different purposes. The incomplete list of some of the most interesting non-traditional uses for GPUs is below.

Mining cryptocurrencies. As controversial as it is, miners of various cryptocurrencies are among the most active users of gaming video cards.
Computational photography. Image stacking, ultra-high resolution imaging, HDR processing, shake reduction and even zooming are made possible by offloading parts of the processing onto GPU units.
AI-based still image and movie superscaling. Old, low-resolution images and some types of movies can be superscaled to UHD resolution using highly convincing AI-based processing.
Accelerated rendering of 3D graphics, face recognition and SfM (Structure from Motion) processing.
Accelerated encryption, decryption and compression. We are yet to see a general-use archiver that would use GPU acceleration for faster compression, but the technology is there.
Scientific purposes. These include bioinformatics, molecular dynamics, SETI@home, medical analysis and physical simulations, and a lot more.

iOS Extraction Without a Jailbreak: Finally, Zero-Gap Coverage for iOS 9 through iOS 13. ...

Wed, 21 Oct 2020 06:55:08 GMT

We have plugged the last gap in the range of iOS builds supported on the iPhone 5s and 6. The full file system extraction and keychain decryption is now possible on these devices regardless of the version of iOS they are running – at least if that’s iOS 9 or newer. For all other iOS devices up to and including the iPhone 11 Pro Max, we can extract them without a jailbreak if they are running iOS 9 through 13.5 without exceptions. Read how we made this possible.

The iOS 12 conundrum

iOS 12 is somewhat unusual. It’s the last version of iOS available for some devices such as the iPhone 5s, 6, and 6 Plus. At the same time, it was available on newer devices as well, starting with the iPhone 6s all the way up to the iPhone 11 Pro Max.

Once iOS 13 was made available for supported devices (in this case, it was the iPhone 6s and newer), Apple stopped updating iOS 12 for these devices. In the end, the last version of iOS available for the iPhone 6 through iPhone 11 range was iOS 12.4.1.

On the other hand, the iPhone 5s and 6 range was not upgraded to iOS 13, so Apple continued maintaining iOS 12 on these devices for some time longer. As a result, we’ve seen releases in the range of 12.4.2 through 12.4.8 made exclusively for the iPhone 5s, 6, and 6 Plus range, iOS 12.4.8 being the current and actively signed system version for these devices.

There is another thing interesting about iOS 12. The iOS 12.0 – 12.2 range had a vulnerability that was exploited by jailbreakers. Apple patched the vulnerability in iOS 12.3, but in an unprecedented move unpatched it in iOS 12.4, then patched it back in iOS 12.4.1.

All this conundrum made experts struggled to extract these devices. As the jailbreaking community moved on and concentrated their efforts on newer devices and iOS 13, the newly discovered universal exploit for all versions of iOS 12 all devices was never utilized on older devices (the exploit itself had never worked reliably to start with).

Then another universal exploit had appeared, this time covering the whole range of systems from iOS 9 through 13.4.1. This exploit, however, could not be used to obtain root access. Instead, injected code was executed under the user “mobile”. This user had the right to access the file system (which we did when we implemented support for it), but not the keychain. We ended up with a halfway solution: for some versions of iOS we could extract the file system and decrypt the keychain; for others, it was just the file system. All this was utterly confusing for our customers; we even had to create (and update, and update again and again) the complex infographics to show which way it was for a given OS.

As new exploits kept creeping up, we finally caught one for iOS 12.3 to 12.4.8. Implementing this exploit was neither easy nor direct, as Apple used a vastly different memory architecture in the iPhone 6s onwards.

Long story short, we implemented the exploit in our extraction agent. Today, we are proud to announce two major achievements.

Starting today, users of iOS Forensic Toolkit 6.52 and newer will be able to perform the complete extraction (file system and keychain) of the iPhone 5s, 6 and 6 Plus devices running all versions of iOS starting with iOS 9.0 up to the currently signed version 12.4.8.

In addition, you’ll be able to extract the file system and decrypt the keychain from all other iOS devices in the iPhone 6s through iPhone 11 Pro Max range running all versions of iOS 9.0 through 13.5 with no gaps or exceptions.

Complex infographics is no longer required, so here we are with the simple one:

Steps to extract the file system and decrypt the keychain

To extract the file system and decrypt the keychain from an iOS device without a jailbreak, follow these steps.

Launch iOS Forensic Toolkit 6.52 or newer.
Press 1 to sideload the agent onto the device
Press 2 to extract and decrypt the keychain
Press 3 or 4 to extract the file system image
Press 5 to remove the extraction agent from the device

The Rise of the Virtual Machines

Tue, 20 Oct 2020 06:55:24 GMT

Criminals are among the most advanced users of modern technology. They learned how to hide information in their smartphones and how to encrypt their laptops. They communicate via secure channels. Their passwords never leak, and they do their best to leave no traces. Forensic investigators encounter new challenges every other day. In this article, we will discuss yet another tool used by the criminals to cover their traces: the encrypted virtual machine.

Introduction to virtual machines

Virtual machines use a portable, hardware-independent environment to perform essentially the same tasks as the actual computer. User activities performed inside a virtual machine remain leave trails mostly in the VM image files and not on the host computer, limiting the number and severity of traces in a natural way. Virtual machine analysis becomes an important factor when performing digital investigations.

Some of the most popular virtual machines include VirtualBox, Parallels, and VMWare. While Microsoft offers Hyper-V, the tool to create virtual machines on Windows 10, Hyper-V offers limited encryption options, requiring Windows Server as a host OS. For this and other reasons, Hyper-V is rarely picked by the criminals.

Virtual machine as a criminal tool

Many types of virtual machines used in the criminal world can be securely encrypted. Using an encrypted VM gives criminals an opportunity to cover their activities under a virtual umbrella, reducing the risks of an accidental leak of incriminating evidence.

Virtual machines in general offer multiple benefits, and the main one is the complete isolation from the normal working environment. This stands true even though several attacks exist, e.g. Virtual machine escape. From the other side, a virtual machine delivers the complete desktop experience, completely tuned for whatever specific purposes the VM is used for. Most of those are legitimate uses, including forensics:

When investigating the suspect’s computer, forensic specialists may not simply image the hard disk but make a fully featured virtual machine for further forensically sound live investigation, emulating the work of the real computer. This gives a lot more possibilities, such as extracting the data and passwords from the memory, booting a forensic image on a virtual machine.

But of course, this is a double-edged sword. The criminals use virtual machines too, today more often than ever. It sounds like a neat idea: collect all the instruments required for their purposes, ready to launch a malware distribution or DDoS attack, compromise remote systems, etc. All of that is no longer a fire-and-forget endeavor. A lot of software, scripts and data is required. Would a malicious person bring that with them, especially when crossing the border? Not really.

Instead, they prepare everything they need, pack it as a virtual machine, upload the image to a fast and reliable hosting, and carry a laptop with just the bare system. Once arrived at the final location, they can quickly download the image, run it, and then delete it from the local drive.

Here is a good story about it: Maze ransomware criminals go virtual to evade detection.

In the description above, I deliberately omitted a critical step. Like most of the data, virtual machine images can be password-protected. We were involved in about a dozen investigations where the suspect used multiple virtual machines protected with a password. In our work, we’ve been recovering the password manually by extracting the password hashes, then recovering them using our tools. Today, we decided to add this feature to Distributed Password Recovery.

Further analysis

Once the virtual machine is unlocked, there is quite a lot of work ahead, see Computer Forensics: Forensic Issues With Virtual Systems. [Case Study] Computer Forensics: How To Forensically Extract Evidence Data From A Virtual Machine is another good source.

If the virtual machine has a password over a password (e.g. there is a Windows account password and/or BitLocker protection), use Elcomsoft System Recovery. And once you are in, the first thing I recommend to run will be Elcomsoft Internet Password Breaker to collect all passwords saved in the Web browsers. If you encounter more encrypted files, remember: we have a tool for that!

Ruling Out the Encryption

Tue, 20 Oct 2020 06:54:54 GMT

We all have habits. Morning coffee (no sugar, just some milk), two eggs (sunny side up), reading mail wile you are not completely awaken, and a lot more. We all follow some kind of rules we have set for ourselves. We all have some favorites: names, cities and even numbers; maybe an important date or place. Can we exploit people’s habits to break their passwords effectively instead of using brute force? We can, and here’s the how-to.

Once upon a time we’ve been asked for assistance in a serious case, examining the criminal’s hard drive. There was no encryption and no system password, so the criminal’s Windows laptop was easily accessible. We extracted tons of passwords from the Chrome browser; there was nothing interesting except a single bank account, protected with 2fa, but that’s another story. We then broke several Office documents (one with a personal diary, again useless), then discovered a VPN password, then a few other passwords, but no incriminating evidence. We almost gave up, but at the end of the second day, we have found a hidden TrueCrypt volume.

Breaking TrueCrypt (or VeraCrypt nowadays) is a real headache. First, TrueCrypt volumes are not always easy to identify as they have no standard header. Second, TrueCrypt offers the choice of several different algorithms for both hashing and encryption, and no information on them is provided in the container’s header. Third, the recovery speed is extremely low even on high-end hardware, so brute-force is not an option. Even the dictionary attack is almost useless, unless you have a very small “focused” dictionary of words and combinations the owner uses regularly.

Back to our case, we collected everything about the owner, and tried a dictionary attack with maximum mutations. The maximal level of mutations modifies all the words one way or another. Another two weeks had passed, and no results.

As a last resort, we got all of that criminal’s passwords we discovered so far, printed them on a piece of paper, turned off our number-crunching GPU workstation and started thinking. We literally just looked at these passwords. Many of them were completely random, obviously generated by some tool. We have not found any password managers though. The rest of the passwords were very simple and were present in most wordlists, including the one we already tried. Finally we noticed several passwords that followed a specific “pattern”, so to day. The pattern was surprisingly simple: a female name followed by two special characters, then three or four digits, sometimes followed by an underscore.

At that time, we did not have a specific attack that could help with such case. We only had (you bet!) the brute-force attack, the dictionary attack with lots of possible mutations, and attack with custom masks (relatively simple at the time). So we had to write a simple code specifically for that case to generate a very custom dictionary containing passwords that were similar to the ones we have already found. That was a quick and dirty solution, yet it allowed to break the password for that TrueCrypt container in less than half an hour.

Today, you can do much better than that, and in a much easier way. No, EDPR will still not crack “similar” passwords automatically. The main and most effective tool is still your brain. You will first need to understand what the password could be, and establish the rules. But once you did, the rest is much easier: just use the new “Rules editor”.

The Rules

One of the features of Elcomsoft Distributed Password Recovery, which is little known and largely underutilized (more on that later), is the ability to create highly efficient and precisely targeted “hybrid” attacks. This technique allows to dynamically generate passwords based on words from one or two dictionaries and dynamic, scriptable modifications based on a large set of rules. Hybrid attacks can be used for something as simple as generating words “Password1” through maybe “Password1234$” to extremely complex combinations such as “Pa$$w0rd10”, all completely automatically.

So if these hybrid attacks are so powerful, why are their little known and underutilized? Because before this day, the rules (following the John the Ripper syntax) required editing text files with zero feedback, and restarting the EDPR server every time you modified them. Every time you created a rule, you had almost zero indication of what was going on and how the resulting passwords would look like.

This had come to an end with EDPR’s brand new, fully visual Rules editor. The same familiar John the Ripper syntax can be now used easily, in WYSIWYG (“What You See Is What You Get”) manner. Just enter the test core word (e.g. “password”) and start adding the rules. You’ll see immediately not only how the generated potential passwords will look like, but the number of such passwords per dictionary entry – which is extremely important when estimating the time it takes for the attack to complete.

One of the simplest pre-defined rules checks for all possible cases of the dictionary entry:

Another rule adds a character to the end of the word. The following pre-defined attack adds a date (four digits representing the possible years) to the end of the entry.

There are countless possibilities for using hybrid attacks. The only limit is your imagination and the list of existing passwords.

Let us see what kind of real-world passwords the hybrid attack can break. Have a look at the following list of passwords extracted from the suspect’s computer:

We know some of user’s passwords:

Pl@net
Nev@d@
L@ptop
Glob@l
G@ry
c@roline

As you can see, the user makes their passwords by replacing the letter “a” with a similar-looking symbol “@”. It’s easier to remember, but harder to brute-force. To solve this task, you would add a simple substitution rule that looks as follows:

sa@
csa@

Done! All entries from a given dictionary files will have their a’s replaced with @’s.

Conclusion

Using the familiar John the Ripper syntax in a WYSIWYG environment combines the best of the two worlds. We are confident in that the feature will get used in a much wider scope than ever before, helping investigators solve more cases in less time.

Breaking Encrypted Virtual Machines: Recovering VMWare, Parallels, and VirtualBox Passwords

Tue, 20 Oct 2020 06:53:10 GMT

Virtual machines use a portable, hardware-independent environment to perform essentially the same role as an actual computer. Activities performed under the virtual umbrella leave trails mostly in the VM image files and not on the host computer. The ability to analyze virtual machines becomes essential when performing digital investigations.

Many types of virtual machines used in the criminal world feature secure encryption. Evidence stored in encrypted VM images can be only accessed if one can produce the original encryption password. We built a tool to enable experts run hardware-accelerated distributed attacks on passwords protecting encrypted VM images created by VMWare, Parallels, and VirtualBox.

Virtual machine encryption

The most common virtual machines that can encrypt the entire image are Parallels, VMWare, and VirtualBox. However, the encryption strength and the resulting password recovery speeds are vastly different between these VMs. Let us have a look at what the developers of the three VMs do to protect their content.

Parallels: the broken implementation

Parallels has the weakest protection of the trio. While Parallels uses the AES-128 CBC algorithm to encrypt the data, the encryption key is derived with a measly two iterations of a dated MD5 hash function. As a result, Parallels is the fastest to attack. We’ve been able to reach the speed of some 19 million passwords per second on a single Intel i7 CPU. With this kind of speed, the recovery of reasonably complex passwords is possible even without GPU acceleration. This speed is fast enough to discover simple passwords using plain old brute force, while the more complex ones will still require the use of dictionaries and mutations.

VMware: just about average

VMvare uses the same AES-128 encryption algorithm. However, its real-world protection is a night and day difference to Parallels. VMware uses 10,000 rounds of stronger PBKDF-SHA1 hash to derive the encryption key from the password. A CPU-only attack results in around 10,000 passwords a second, making the supported GPU-assisted recovery strongly recommended. The use of a single NVIDIA GeForce 2070 RTX board boosts the recovery speed to 1,6 million passwords per second. This allows finding the reasonably complex passwords. Still, using a targeted dictionary with reasonable mutation settings is recommended.

VirtualBox: the toughest protection

Finally, Oracle VirtualBox delivers the strongest protection with the most secure encryption. The encryption algorithm can be either AES-XTS128-PLAIN64 or AES-XTS256-PLAIN64, while the SHA-256 hash function is used to derive the encryption key from the password. The number of hash iterations depends on the length of the AES encryption key, and reaches an astonishing value of up to 1.2 million hash iterations. It’s no wonder that CPU-only attacks are miserably slow, yielding the recovery speed of only 15 passwords per second. GPU-assisted attacks are significantly faster, delivering the speed of up to 2700 passwords a second on a single NVIDIA GeForce 2070 RTX board. In addition to a good GPU, we strongly recommend a targeted dictionary and reasonable mutation settings.

Steps to break VM encryption

We’ll use Elcomsoft Distributed Password Recovery to open the encrypted virtual machine and set up an attack on its password.

Pre requisites: You will need Elcomsoft Distributed Password Recovery 4.30 or newer to attack VM passwords. In order to launch the attack, you won’t need opening the entire container, which may be extremely large. Instead, we’ll be using small files from the VM folder. For Parallels, we’ll need the config.pvs file. For VirtualBox, the corresponding .vbox file. For VMware, the .vmx. These files are very small (several KB), and are all that you need to launch the attack.

Launch Elcomsoft Distributed Password Recovery 4.30 or newer.
Open the virtual machine as shown on the screen shots below. Use the corresponding files for each type of the virtual machine.
1. For Virtualbox, open the .vbox file:
2. For VMware, open the .vmx file:
3. For Parallels, open the config.pvs file from the folder containing the VM.
Configure and launch the attack using the dictionaries, mutations and/or the new Rules tab to set up a hybrid attack using the John the Ripper syntax. You can read more about the hybrid attack in this blog article.

Once you launch the attack, you can observe the recovery speed. Parallels would be the quickest to attack even with a single CPU:

Conclusion

The use of virtual machines in the criminal world is on the rise. The ease of use and the level of protection provided by common VMs enable criminals to sneak their traces under a virtual umbrella, reducing the risks of an accidental leak of incriminating evidence. We made our step, building a tool to help law enforcement gain access to evidence stored in encrypted VMs by doing our best in breaking the encryption password in as little time as possible.

Everything You Wanted to Ask About Cracking Passwords

Thu, 15 Oct 2020 11:34:54 GMT

Making tools for breaking passwords, I am frequently asked whether it’s legal, or how it works, or what one can do to protect their password from being cracked. There are people who have “nothing to hide”. There are those wearing tin foil hats, but there are a lot more people who can make a reasonable effort to secure their lives without going overboard. This article is for them.

Is password cracking legal?

The short answer is “it depends”. There are a lot of vastly regulations in different countries; some even make it illegal to hide the password from the authorities if they ask – like in France, the country of Liberté. In general, passwords are used to restrict access to the data (and it is also important whose data it is, and who’s asking). Obviously, nobody can stop you from breaking your own password that you forgot; however, if this password protect access to your data stored in some online service, it does not actually matter that the account is yours – you cannot legally break it. In other words, cracking passwords is perfectly legal if you work with local data and the data is yours, or if you have the permission from the legal owner, or if you represent the law and follow the local regulations. Cracking someone else’s data might be a criminal offence, but there is a huge gray area.

How long does it take to crack the password?

It looks like another “it depends”. There are two common cases:

You don’t need to actually break the password. Access to the data can be obtained regardless password length and complexity.
“Success rate” (if we can ever use this term) directly depends on the password length and complexity.

The devil is in the detail. For example, if the entire protection method (which includes the encryption algorithm, the key derivation function and certain other things such as the use of salt) is strong and a properly strong password is selected, there may still be a chance that the same password is either re-used somewhere the protection is weaker, or that said password is stored somewhere, e.g. saved in your browser for faster access, and so can be easily obtained without the need to crack it.

Is there such a thing as secure password?

It depends (I know, I know). Remember the “entire protection method” I mentioned in the previous chapter? If the vendor’s implementation has a single weak link (like, for example, using a strong encryption algorithm but only employing a single hash iteration to derive the encryption key from the user’s password), you may forget about secure passwords. Security does not depend entirely on the password length and complexity.

If there are no obvious faults in the vendor’s implementation (and you never know if there really aren’t), a 7 or 8-character password would be generally secure if it is a genuinely random mix of letters, numbers and special characters. Choosing passwords based on dictionary words? I have bad news for you.

If you aren’t sure about your vendor’s implementation, the password should be at least 12 characters long. How do you know if you can trust the vendor? First and most important, do not trust the vendor’s claims; their favorite claim “military-grade encryption” means nothing at all. You can look for more information and find something like “we use pbkdf2(sha512) with 100,000 iterations”, but I doubt that tells you a lot (unless you are work in cyber security). Even then, there could be too many other factors affecting the password strength. Finally, the password strength is not the only factor that affects security.

For online services, everything is far more complex. Most systems restrict the number of failed attempts for a given account, blocking access after several (very few) incorrect passwords in a row. This, however, does not remove the possibility of a reverse brute force attack. The system security depends on many other factors, and your account might be cracked in a different way, using vulnerabilities in the system or its network software.

Smartphones are yet another unique case. There are even more factors to consider, including the hardware model, the vendor’s implementation, OS version, security patches, system and software settings, cloud access, and a lot more. Some smartphones are more secure than others in general, but still vulnerable if used incorrectly.

How does password cracking work?

There are many methods of password cracking.

As I had already mentioned, sometimes it you don’t need to crack the password as there are other, faster and simpler ways to access the data. For example, many legacy systems and applications do not encrypt the data. Even without a classic backdoor, one can build a new one to simply ignore the authentication system and grab the data directly.

Even if the password protection implementation is genuinely secure, there are different attacks. Watch our blog, I’ll tell you more about them. The attacks look way different from what you see in Hollywood movies (where every single character of the password or security code is being cracked separately, and it takes split seconds to break one), but they are not rocket science either.

Can hackers break my password?

If you are asking, it’s likely that they can. They are well educated. They have the tools. They know how to use them. They don’t need your permission, and they don’t care about the law. They are good social engineers. They know the value of your data (better than you do). They’ve been doing this for years. Should you be concerned? Absolutely. Your data has a price tag, and it’s up to them to decide whether it’s worth their effort.

Can the police crack my password?

Sure they can, but the chance of them cracking your password is lower than the hackers’ simply because of the legal restrictions. While they use the same tools as the hackers, they have other ways to access your data that aren’t available to criminals.

The law enforcement officials may be able to legally request your data without breaking your password (e.g. from Apple, Microsoft, Google, Facebook etc.), and they may have the authority to go through the physical hard drive of your computer, pulling passwords straight from your Web browser.

How can I secure my data?

There is no short or simple answer. You’ll have to learn, and you’ll have to understand how things work in order to protect your data. Just one example: writing your passwords down on a piece of physical paper might be the better strategy against hackers than storing them on your computer, being a bad strategy if you’re planning to defend your data from the police. There are multiple things to consider; we collected some of them in the recent article Playing devil’s advocate: iPhone anti-forensics. If you are interested in protecting your Windows system, have a look at our article series related to BitLocker.

Security is not a tool, software or methodology. Instead, it is a process. You cannot configure your system once and stay safe for good. You always have to learn.

Why password protection is so popular, and isn’t it safer to use biometrics?

Password protection is fast and simple to implement, and it’s really convenient to use. Other authentication methods exist. I like Face ID in particular (probably even more convenient than password protection), but it does not increase the overall security of your iPhone. It’s just a weaker but more convenient way of authenticating Apple used to convince users into using some sort of secure lock screen. Back in the days, people would not bother PIN-locking their phones, so that’s a huge step if you think of it. All existing biometric authentication methods have a high false positive rate. Some are not secure and can be easily fooled. While the latter is not the case with Apple Face ID, many Android-based copycats including big brand names offer severely flawed and completely insecure implementations of face unlock. No one seems to care.

Is there a light at the end of the tunnel?

The answer is disappointingly negative.

If you are an ordinary user, the risks are escalating. The more data, more gadgets, more everything is around, the more difficult it becomes to protect or even keep under control.

If you work for the law enforcement, you get more challenges every day. Point to point encryption, secure cloud storages, advanced encryption software and tightening privacy regulations don’t make your work any easier.

If you are a hacker… This article is not for you, as you already know everything I wanted to tell.

Stick It To The Man

Fri, 09 Oct 2020 18:25:40 GMT

The year was 2008, and I had been staying at a hotel in Bogota. This trip was just one of many to Columbia that year. Before my trip, I’d had my former girlfriend, Darci, stop by and help me swap out the hard drive in my MacBook Pro laptop. Remember, this is 2008, and at the time, replacing a drive in a MacBook Pro wasn’t nearly as easy as replacing hard drives these days. Darci swapped out my original hard drive with a brand-new drive, which I then formatted and installed macOS. I had her swap the drive out for security reasons. I didn’t want to cross the border into a foreign country with all of my client data. Especially not after what happened to me in Atlanta! But we’ll get to that later.

It’s worth mentioning that the hotel I had chosen wasn’t some seedy motel in the questionable part of town. No, it was a very reputable hotel in which even the Bogota military officials regularly stayed. Looking back, perhaps that is where I went wrong.

My then-girlfriend and I had gone out for dinner, and my MacBook Pro was stored safely (or so I thought) in the hotel room. Upon returning to the hotel room, I found that my keycard wasn’t working to unlock the door. I’d swipe the card, and a yellow light would appear. Not red, not green, but yellow. Strange.

I didn’t think much of it at the time; I just thought it was a faulty card. We made our way down to the lobby and requested a new card. I swiped the new card, and to my dismay, it still didn’t work. Back at the lobby desk, I explained my frustrations. They apologized and gave me another card—the same issue. At this point, I’m not thinking anything suspicious is happening; I’m just annoyed. They had provided me three new cards, all of which didn’t work before they finally agreed to send someone up.

The hotel employee came up to the room, swiped their card, a green light appeared, and we were able to enter the room finally.

Again, I wasn’t thinking that anything nefarious had been going on. I simply attributed the situation to a faulty door lock.

When I returned home, I had Darci come back over to swap out the MacBook Pro drive again. She questioned me as to why I had opened up the MacBook Pro myself. Puzzled, I told her that I hadn’t. She was adamant that the device was opened. She intentionally barely tightened the screws holding in the hard drive but now they were screwed in very tight.

And that is when it hit me; someone had been in my hotel room in Bogota and probably imaged my hard drive.

This incident was a wake-up call for me, but it wasn’t the first time my privacy was intruded upon while traveling.

The year before, on another trip to Columbia, I was detained at the Atlanta airport on my way back home. The airport officials couldn’t tell me why I was being detained, but they made sure to go through all of my items. I had several laptops and plenty of other computer-related equipment that I had used for speaking engagements. At the same time, I received a call from my then-girlfriend. She said to me that Columbian police called her and ask for permission to search a package I was mailing back to the U.S. The package contained an encrypted hard drive I was shipping back to the states. Police in Bogota claimed they were looking for cocaine inside the small laptop hard drive. Of course, they ultimately found no evidence of cocaine. Obviously, it was a ruse to take my hard drive which was encrypted with PGP’s Whole Disk Encryption back in the day. Back in Atlanta, Customs and ICE cleared me of any wrongdoing and sent me on my way.

These two incidents made me realize that I need to be extremely careful with my data when I’m traveling abroad. Although I’m not doing anything illegal, I have plenty of confidential information from penetration tests I’ve performed for my clients. This data would be detrimental if it fell into the wrong hands such as foreign governments, and it could also lead to lawsuits against myself for breach of non-disclosure agreements.

As such, here are the steps I take when traveling internationally.

First, I create an encrypted backup of my hard drive. Next, I put the backup in an encrypted container using a tool such as VeraCrypt. I’ll then ship an external hard drive with my data to the hotel where I’ll be staying. My reason for doing this is that if I’m required to hand over my laptop at the border or entering a country where they can force travelers to provide their password, I don’t have to worry about any confidential data being seen or ending up in the wrong hands. Before I leave, I’ll wipe all confidential data and hacking tools from my computer. Once I arrive at the hotel, I’ll restore my data from the encrypted drive I had shipped to the hotel prior. Since I’m past the border, there is no legitimate authorization to search my computing devices.

For mobile devices, such as my iPhone, the process is similar.

First, I make a full encrypted backup of my phone and store that backup in an encrypted container. Since a phone typically has much less data than a computer hard drive, I can upload the encrypted image of the phone to AWS or Azure. Once at my destination, I can download and restore the full backup to my phone. It’s important to keep in mind that some items, such as saved Signal messages, will be lost. Aa small price to pay to protect one’s privacy.

Unfortunately, this doesn’t stop someone from going into your room and imaging your drive like my Bogota experience. My advice to avoid that type of situation is always to keep your devices with you at all times. Don’t leave your laptop or mobile devices unattended. Take them with you, even if you are just going to dinner. In certain countries, you may want to actually take your devices into the bathroom as you take a shower!

These processes may seem like overkill, and they are undoubtedly time-consuming, but they are the necessary steps to protect legitimate confidential business information when crossing international borders.

About the author: Kevin Mitnick is an American computer security consultant (running Mitnick Security), author, and convicted hacker. In 1995, he’s been arrested and spent five years in prison for various computer crimes. Mitnick’s arrest and the series of consequent events were all highly controversial. Kevin is a personal friend of Vladimir Katalov. Kevin and Vladimir regularly meet in Moscow and exchange opinions on things they find important or entertaining. On the photo: one of the first meetings with Kevin, trying to break his iPhone.

Apple Mobile Devices Cheat Sheet

Tue, 06 Oct 2020 06:55:08 GMT

When investigating iOS devices, you may have seen references to the SoC generation. Security researchers and developers of various iOS jailbreaks and exploits often list a few iPhone models followed by a note that mentions “compatible iPad models”. This is especially common when discussing iOS forensics, particularly referring to the checkra1n jailbreak. What do those references mean, and how are the iPhone and iPad models related? Can we count the iPod Touch and Apple TV, too? Let’s have a look.

How to identify your model

This is the first step. Apple has detailed instructions:

The Apple Watch is missing here, though there is an article on them, too; the problem is that Apple Watch acquisition is very limited.

Usually it is as simple as that: check the back cover of the device (the iPhone, iPad or iPod Touch) and check the model number in the Axxxx format. The ‘xxxx’ are the four digits. Once you are done, search across the above-mentioned pages. Just note that some iPhone and iPod models may share the same external design, and sometimes the back cover is replaced with the one from a different model. The only reliable method is opening the [Settings] | [About] and checking the model.

SoC (Silicon on Chip)

The heart of every Apple device is the SoC, or System on a chip. Apple uses ARM processors of its own design; the current one for now is A14, which appears in the iPad Air (2020). How does that affect the compatibility of available acquisition methods? Is that the only factor or there is something else except iOS version?

Let’s start with the SoC (CPU). We have collected information from public sources and compiled this information for you:

Noted the different colors? Here is the explanation.

Green: you can do almost everything, including passcode cracking, and even perform BFU extractions (may be limited if the password is not known)
Blue: devices vulnerable co checkm8 exploit. BFU (Before First Unlock) is possible regardless of iOS version, but the devil is in the detail (see below)
Red: you cannot do anything with locked devices

BootROM exploit

The checkm8 exploit is the thing you might’ve already heard about. The exploit’s compatibility is difficult to grasp. The developers state that it is compatible with the iPhone 4s through iPhone X range of devices, but in fact the compatibility matrix is a bit more complex:

Currently available SoC support: s5l8947x, s5l8950x, s5l8955x, s5l8960x, t8002, t8004, t8010, t8011, t8015
Planned SoC support: s5l8940x, s5l8942x, s5l8945x, s5l8747x, t7000, t7001, s7002, s8000, s8001, s8003, t8012

Confused? No wonder. These IDs are actually bootrom versions. For example, the T8010 is the one used in the iPad 6^th and 7^th gen, iPhone 7 and 7 Plus, and iPod Touch 7^th gen.

If you look at the checkra1n jailbreak, you might be confused even more. The release notes for the latest version read:

However, with the recently published blackbird vulnerability, we are able to get control of the Secure Enclave on A10 and A10X and disable this mitigation. Support for A10 and A10X devices is being worked on and is expected to be ready in the coming weeks.

The compatibility is described as follows:

iPhone 6s, 6s Plus, and SE
iPad 5th generation
iPad Air 2
iPad mini 4
iPad Pro 1st generation
Apple TV 4 and 4K

The list is weird. For example, the iPad mini 4 has the A8X SoC, which corresponds to that is used in the iPhone 6 and 6 Plus; however, the iPhone 6 cannot run iOS 14 (and even iOS 13), while the iPad mini 4 can.

Acquisition

At the time of extracting the data, you may not care about device models, chipsets and iOS versions. You just need to get the job done, and if you are working as a forensic expert, all you need to know is the availability of various acquisition methods. This is the current availability matrix:

The matrix is in fact not complete. First, it misses some older devices such as the iPhone 4, 4s, 5 and 5c. Second, it does not include iOS 14 compatibility, which is now limited to iPhone 6s, iPhone SE, Apple TV and “compatible iPad models”, see above.

Summary:

iPhone 4, iPhone 4s, iPhone 5, iPhone 5s: you can do virtually everything, even for locked iPhones
iPhone 6s to iPhone X: full file system and keychain acquisition for iOS up to 13; partial acquisition (BFU) if the passcode is not known
iPhone 6s and SE: the above is applicable for iOS 14 as well
iPhone Xr/Xs and iPhone 11: file system and keychain acquisition for iOS 13.5 and below, but only if the passcode is known

Use Elcomsoft iOS Forensic Toolkit as this is the only tool you need to perform the full file system and keychain acquisition for jailbroken or compatible non-jailbroken devices.

The above screen shot is for BFU acquisition (i.e. from the device with unknown passcode), by the way.

Other options

iCloud acquisition is a life saver. No matter which model iPhone you are extracting and what version of iOS it runs, if you have the user’s authentication credentials, you can download device backups, files from the iCloud Drive and quite a lot of synced data including account information, the usual categories like contacts, notes and iCloud Photos, as well as “end to end encrypted” data like iCloud keychain, messages (iMessage and SMS), Health and much more. The tools? Elcomsoft Phone Breaker, the only product on the market that can download all of that data.

Mobile Forensics: Are You Ready for iOS 14?

Mon, 05 Oct 2020 06:55:33 GMT

The number of iOS 14 users is on the raise, and we will see it running on most Apple devices pretty soon. Apple had already stopped signing the last version of iOS 13 on all but legacy hardware. Soon, we will only see it running on the iPhone 5s and iPhone 6 which didn’t get the update, and on a small fraction of newer devices. If you are working in the forensic field, what do you need to do to make yourself ready for iOS 14? Our software may help.

Speaking of iOS 14 itself, it does not bring much new that could be useful for forensic investigators. We’ve covered some of the changes in iOS 14 Forensics: What Has Changed Since iOS 13.7? The first step is always data acquisition, followed by the analysis. Let’s review what you can do with iOS 14 using the updated Elcomsoft iOS Forensic Toolkit released today.

Extended logical acquisition

Right when the first beta of iOS 14 had appeared, we tried all supported acquisition options that include:

Extended device information, including the list of installed apps and their properties
iTunes-style backups
Media files (pictures, videos and metadata)
Crash & diagnostics logs
Shared app data

Everything worked. But in the final release (or in the late betas), iOS backups stopped working in our tool. We discovered that the backup protocol (which, as you know, is implemented in the iOS itself) was slightly changed, but the fix was easy. So the new version of iOS Forensic Toolkit extracts everything listed above, including backups. Backup acquisition is sometimes harder than it sounds (considering all the password-related issues), read The Most Unusual Things about iPhone Backups for details.

Full file system & keychain acquisition

Speaking of the revolutionary, forensically sound agent-based acquisition method that does not require jailbreaking – it’s not yet ready for prime time. The agent-based extraction method remains compatible with iOS 9 through iOS 13.5, leaving iOS 13.6 and 13.7 out for the time being. As new exploits become available, we will add support for the new versions. For now you are limited only to devices supported by the checkra1n jailbreak. At this time, supported devices include the iPhone 6, iPhone 6 Plus and iPhone SE (first gen) only. The compatible iPad models are also supported, but we have yet to explain what “compatible” devices mean as there are 19 different iPad models. iPhone 7 and iPhone 7 Plus support will be available soon, while iPhone 8 and iPhone X support is questionable; it looks like Apple had found an effective way to protect these models from the checkm8 exploit using Secure Enclave.

What can you do with checkra1n on the iPhone 6s/SE running iOS 14? If the passcode is known, all the data including keychain can be acquired, and it is a lot more than just backups: lots of system databases, third-party application data, temporary and WAL files, etc. If the passcode is not known, you can still perform BFU (Before First Unlock) acquisition even of locked and disabled devices. The scope of the data that can be extracted in BFU mode is modest, but something is still available, and it is much better than nothing.

The following versions of iOS are supported: iOS 14.0, iOS 14.0.1 and iOS 14.2 (beta 1 and beta 2). The latest checkra1n also supports several iPad models including the 5^th gen, Mini 4, Air 2 and 1^st gen iPad Pro, as well as Apple TV 4 and 4K. Note that some of these models are based on the SoC that is different from the one used in iPhone 6s/SE (A9). No Apple Watch support yet (theoretically it might be possible).

Cloud acquisition

Cloud acquisition is a life-server in many situations, especially when the device is missing, broken or otherwise unavailable. Cloud extraction may return lots of data that is not available on the iPhone itself, including deleted data or data originated from another device. iOS Forensic Toolkit will not help you here, but use Elcomsoft Phone Breaker instead, which is the most comprehensive product of this kind on the market. Supporting all iOS versions (including the now-current iOS 14.2 beta 2), it supports iCloud backups, about 20 categories of synced data (including “end to end encrypted” such as the keychain, messages, Health, Apple Maps and so on), and all files stored on iCloud Drive, including third-party data which is otherwise not available.

Other updates

Extracting a jailbroken device? You have probably noticed the two prompts appearing at the time iOS Forensic Toolkit starts and before it establishes a connection to the iPhone:

SSH port number
root password

We have now decided to eliminate them. The root password is ‘alpine’ by default, and it never changes if you install the jailbreak yourself for acquisition purposes. In rare cases where you must provide a different root password, you can change it by modifying the SSHPASS value in the script.

The other option (port number) need an explanation. For all modern jailbreaks, an SSH connection established by OpenSSH or DropBear SSH is made over the standard port 22. There is currently only one exception: checkra1n in BFU mode, when OpenSSH is not installed, and the jailbreak uses the built-in DropBear SSH client. In this situation, the port number is 44.

Since this release, the port number 22 becomes the default in our toolkit. However, if you perform BFU acquisition via checkra1n, change the IPORT setting in the script source and restart the toolkit.

Old but worth mentioning

iOS Forensic Toolkit is a powerful and flexible tool, but sometimes it requires a bit of fine-tuning. Just to remind you a few things (honestly, sometimes I forget about some of them myself):

macOS: do not forget to clean ‘quarantine’ flag from the DMG file you’ve downloaded
macOS: do not run the toolkit right straight the mounted DMG, but copy the contents to the local disk first
Windows: run the toolkit with Administrator privileges
If you are using agent-based acquisition frequently, you can set Apple Developer Account credentials in AGENT_ID, AGENT_PASSWORD and AGENT_TEAMID to avoid extra prompts
macOS: in agent acquisition, use the regular (not app-specific) password for both developer and non-developer accounts, then go through 2FA
Windows: always use an app-specific password
with non-developer accounts, do not forget to restrict Internet connections

The future

What does the future hold for iOS forensics?

Extended logical acquisition: will most likely stay in its current shape in all future iPhone models and iOS versions, unless Apple removes the Lightning port completely. Even then, it will probably allow to acquire the data over the air; this is extremely hard to predict at this point.

Agent acquisition: depends on the availability of exploits. We cannot make promises, but it looks like we will be able to add support for iOS 13.6 and 13.7 soon. As for iOS 14, there is no ETA, but some rumors on new exploits are already coming.

Jailbreaking: for system-level jailbreaks, the situation is like above. With new exploits, we will get both new jailbreaks and (probably after some time) support for agent acquisition. Speaking of checkra1n, support of iPhone 7 and iPhone 7 Plus running iOS 14 is coming.

Cloud acquisition: the most difficult question. We are doing everything we can to keep things running, but Apple have the technical ability to block our software from working, at least from accessing iCloud backups. Contrary to the acquisition of physical devices, a solid part of iCloud engine is beyond our control.

Playing devil’s advocate: iPhone anti-forensics

Wed, 30 Sep 2020 15:43:14 GMT

Everyone’s iPhones contain overwhelming amounts of highly sensitive personal information. Even if some of that data is not stored on the device, the iPhone itself or the data inside can work as a key to other many things from bank accounts to private family life. While there are many possible vectors of attack, the attacker will always try exploiting the weakest link. Learn to think like one, find the weakest link and eliminate the potential vulnerabilities before they are exploited. This guide comes from the forensic guys making tools for the law enforcement, helping the good guys break into the bad guys’ iPhones.

The hardware

Not every model is equally secure. iPhone models up to and including the iPhone X are vulnerable to the checkm8 exploit, allowing partial file system and keychain acquisition even in the passcode is not known. Since this exploit targets a hardware vulnerability in BootROM, it cannot be fixed in iOS updates. If you want a secure phone, one of the devices based on the A12 or newer SoC, here is the list:

iPhone Xr
iPhone Xs
iPhone Xs Max
iPhone 11
iPhone 11 Pro
iPhone 11 Pro Max
iPhone SE (2020)
iPhone 12

The point is, you are not safe if you are using older hardware. No matter what you do, older devices are vulnerable to checkm8 exploit.

The software

Keeping iOS up to date is extremely important. At the time of this writing, iOS 14.0.1 is the latest version (with 14.2 beta being actively tested). Using any older version of iOS puts you at risk.

Make sure to set a long and complex backup password. Do it whether you are planning to make local backups or not, as someone may do it instead of you. The password must be complex enough: use at least 8 characters, mixing small and capital letters, digits and special characters. This password also needs to be unique, and should not consist of dictionary words.

Finally, set the Screen Time passcode – again, whether you use the Screen Time feature on not. That will prevent your backup password from being easily reset if someone gains control over your iPhone. The Screen Time passcode should be different from the device passcode, and should not be easy to crack – please do not set it to your year of birth, the current year, or 0571 (if you know what I mean), or any other year up to date. For more information and some technical details:

Basic protection

By default, iOS suggests using a 6-digit only (it used to be just 4 digits before). This is convenient, but definitely not secure with existing passcode cracking solutions (which are supposedly exclusive to the law enforcement). We recommend passcodes of 8 digits at least, or a complex alphanumeric passcode if you are concerned about security.

Be aware that using Touch ID or Face ID does not improve the absolute security of your device; instead, these biometric authentication methods may give someone an opportunity to unlock your iPhone without the passcode. Biometric authentication is a compromise, adding convenience at expense of security.

Connections

If you connect your iPhone to any computer, you are at risk if you had established a trusted connection there. More information in The Issue of Trust: Untrusting Connected Devices from Your iPhone.

What can you do? The recommendations are quite simple:

Use only original cables or certified cables obtained from a trusted source. The ones that “look like the real thing” (but may steal your data) exist, like MG Cable or USB Ninja.
Use only original chargers (or ones obtained from a trusted source). Very “special” ones exist, too.
If you desperately need to use a third-party cable or charger, do not establish the “trust relationship” if prompted. If this prompt ever shows up on your device when you are attempting to charge it, be alert. Remember: charging your iPhone does NOT require “trusting” the charger!
Do not establish “trust relationship” with computers you don’t really trust. If you are not sure you’ve never trusted a non-trustworthy computer, clear your pairing records ASAP.
Physically protect access to your own computers.

The last one is extremely important. Your hard drive contains data that may help to unlock your iPhone. Use BitLocker on Windows, or FileFault2 on macOS – and of course, use unique and hard-to-break passwords for everything.

SOS!

You should learn how to activate the emergency “S.O.S.” mode on your iPhone. This mode, once invoked, will some encryption keys stored in the device memory, making biometric unlock impossible. In addition, it disables the Lightning port immediately, making the data acquisition much harder, if not impossible. Here is how: The True Meaning of iOS Recovery, DFU and SOS Modes for Mobile Forensics. That’s a life saver, really!

iCloud

Securing the iCloud account is worth a separate article. Just some things to note:

Make sure you know exactly what data is stored in your iCloud account. Do not assume anything! You might be surprised in both ways.
Use a strong and unique iCloud password.
Enable the Find My [Phone]
Use two-factor authentication.

Note that Apple has access to most of your data stored in iCloud, and may provide it to the law enforcement if served a legal request; see Law Enforcement Support Program for details. All they need is your Apple ID (email), or your phone number, or the device IMEI, or its serial number. You may be able to obtain a copy of your data from Apple, delete all or some data.

Software, part two

How secure are the apps you are using? Every app from messengers to document management tools can pose a security threat. Most modern messages are secure (we personally recommend Signal), but still vulnerable via exploits or malicious software that might be installed silently on your iPhone or your contact’s phone. Also, some messengers store their data in their vendors’ clouds, or create chat backups in Apple iCloud (that applies to any other software, too).

Screen lock

Make sure that your phone locks itself automatically even if you forget to push the Lock/Sleep button. This is easy to do by checking the Display & Brightness | Auto-Lock setting, which could be anything from 30 seconds to 5 minutes. Never use the “Never” setting.

Once your screen is locked, make sure that nothing you don’t want everyone to see can accidentally pop up. In [Touch/Face ID & Passcode] | [Allow access when locked] disable at least the following:

Notification Centre
Control Centre
USB Accessories

The reason for this is privacy. Notifications may and do contain sensitive information from one-time verification codes to personal messages. The Control Center allows activating the Airplane mode, which is frequently done in place of powering the phone down to preserve the encryption keys in your phone’s volatile memory. The last setting allows USB restricted mode.

One more thing: make sure that the [Require passcode] setting is set to “Immediately”.

IoT

Are you an Apple Watch wearer? IoT devices might pose an additional risk. As an example, your Apple Watch could be used to unlock your Mac (if configured). While this adds a bit of extra convenience, do mind the risks. You can read more about the data available in Apple Watch in Apple TV and Apple Watch Forensics 01: Acquisition and Apple Watch Forensics 02: Analysis. To secure your Apple Watch, make sure that you have enabled a passcode, and that the passcode is different from the one on your iPhone.

If you have an Apple TV in your household, you can do literally nothing to secure the data: there is no passcode on Apple TV, and there is no way to set one. The analysis of an Apple TV is available in Apple TV Forensics 03: Analysis.

Other considerations

There are a few other things to consider.

Sideloaded apps

Unlike Android, iOS does not allow sideloading apps (easily). While tracking and spying is as common in iOS apps as it is on Android, iOS 14 is about to deal with it by introducing the new prompt asking the user for tracking permission. (TikTok anyone?)

Jailbreaking

Don’t. A jailbreak exploits vulnerabilities in the device or the operating system. Jailbroken devices are inherently less secure than non-jailbroken ones.

MDM

MDM is a powerful way to add extra security restrictions such as enforcing certain passcode quality or requiring certain automatic screen lock settings. Among other settings, MDM could be used to restrict pairing with new devices, effectively blocking one of the threats.

MDM has an ugly side, too. If a threat-actor gains access to the MDM console, he/she can change settings or track your device.

The cloud

iCloud is the largest risk in the entire ecosystem. Even if you take every step possible to protect your account, Apple is still bound to turn your data over to the law enforcement if served with a proper legal request. The data is more detailed and more comprehensive than one can imagine, and may even include footage from surveillance cameras installed in Apple Stores. While Apple provides some information on what data is stored (and may be revealed), the list in fact it far from comprehensive.

Randomized MAC address

It’s there. Just a small but useful extra. Why does that matter? Use private Wi-Fi addresses in iOS 14, iPadOS 14, and watchOS 7 explains in detail how using a different MAC address with each Wi-Fi network helps further protect your privacy.

Google and Facebook

If you are using Google apps or Google services on your iPhone, be aware about Google’s data collection, processing, retention and disclosure practices.

Even if you don’t have a Facebook account or the Facebook app installed, chances are that most of the many apps you have installed on your iPhone include Facebook’s tracking SDK. Be aware. You can read more about unconsented Facebook tracking within apps. Apple is about to put an end to this practice in further iOS 14 updates sometime in 2021.

Mobile providers

Mobile service providers will turn over a lot of data when requested, including the list Web sites that you visited (DNS queries).

The creepy things

Even if you power down your iPhone but still have the battery connected, your phone might be used as a remote mic.

Conclusion

As secure as it may seem, the Apple ecosystem is not without its flaws. While I tried to list everything I could remember, no single guide is complete: there can be other risks and other mitigations. Making yourself aware of the risks is just the first step in the direction of securing your personal information.

The Issue of Trust: Untrusting Connected Devices from Your iPhone

Tue, 29 Sep 2020 06:54:28 GMT

When connecting an iPhone to a computer for the first time, you’ll see the prompt asking you whether to trust the computer. Trusting a computer enables your phone and computer to exchange information. However, should the trusted computer fall into the wrong hands, the pairing record from that computer could be used to pull information from your iPhone. Learn about the risks associated with pairing records and how to block unwanted connections by untrusting connected computers from your iPhone.

Since iOS 12, your screen lock passcode is required to trust the computer. The system will prompt for your passcode after you confirm the “trust” prompt. This protects the data in your iPhone against unauthorized access even if someone gains control of your iPhone with its screen unlocked.

If you opt not to trust a computer, then all access to your device’s content by that computer is blocked. In this state, no information will be exchanged between your phone and your computer. This is the state you want when connecting to any computer except your personal one.

If you trust a computer, it will remain trusted for a long time. Dormant trusted connections can live for up to six months, after which the pairing expires, and you’ll be prompted to trust the computer again when connecting the iPhone. The trust timer will reset every time you connect the iPhone to the computer. until you change which computers you trust or erase your device.

Once you trust a computer, iOS generates a pair of cryptographic keys. One of the keys is stored as a file on the computer you’re trusting, while the other is kept on the iPhone. These keys are unique for every pairing; the communication will be established if the keys on the iPhone and on your computer match. Removing any one of those keys breaks the trusted relationship, requiring to establish a new pairing to exchange information. Simply put, if you want to “untrust” a computer, you must remove at least one of the keys (preferably the one on the iPhone itself).

The problem lies in the way iOS handles these trust records (otherwise known as “pairing records” or “lockdown records”). There is no mention of trusted devices anywhere in iOS settings. There is no easy way to see on your iPhone which computers are trusted, and there is no easy way to break such trusted relationships. There is also no way to break only some pairings (e.g. those you made during a trip) while leaving your personal computer trusted.

Why leaving a pairing record behind is a bad idea

We have a comprehensive article on what is accessible on your iPhone with a valid lockdown record: What can be extracted from locked iPhones with new iOS Forensic Toolkit. In this article, we discussed the various states the iPhone can be in, and the types of data that can be extracted from the phone if one has access to a pairing record stored on the user’s computer. An old but still useful article named Acquisition of a Locked iPhone with a Lockdown Record explains how to do the extraction. In a word, the following can be extracted from your iPhone if one has access to both the phone and a pairing record (but without a passcode):

Local backup
Your entire media library (photos and videos)
Some system logs
Some shared files

More on the available types of data in Demystifying Advanced Logical Acquisition. Generally speaking, you don’t want any of that information to fall into the wrong hands. For this reason, we strongly recommend not trusting any computer that does not belong to you. If you did, we recommend untrusting such devices by removing the encryption keys from your iPhone.

Apple has a trick to protect users against lockdown records that were left behind. If your iPhone has not connected to a trusted computer or accessory for a certain period of time, it will start blocking the data port immediately after the screen is locked. Once this mode (known as the “USB restricted mode”) is activated, neither jailbreaking (except with checkra1n) nor logical acquisition are possible.

Untrusting connected devices

In iOS, untrusting connected devices is an all or nothing affair. You can either remove all pairing records from your iPhone or leave everything intact. In About the ‘Trust This Computer’ alert on your iPhone, iPad, or iPod touch, Apple notes: “If you don’t want to trust a computer or other device anymore, change the privacy settings on your iPhone, iPad, or iPod touch. Go to Settings > General > Reset > Reset Location & Privacy. Now when you connect to formerly trusted computers, the Trust alert will ask you whether you trust that computer.”

To untrust all connected devices, do the following.

On your iPhone, open the “Settings” app and tap “General”
Tap “Reset” -> “Reset Location & Privacy.”
Confirm the prompt by typing your screen lock passcode.
Once you reset Location & Privacy, you will need to re-enable location services for apps that you want to allow accessing your location data.

Consequences of resetting Location & Privacy

In About privacy and Location Services in iOS and iPadOS, Apple talks about the available privacy and location settings in iOS. According to Apple, resetting Location & Privacy will do the following: “If you would like to reset all of your location settings to the factory default, go to Settings > General > Reset and tap Reset Location & Privacy. When your location and privacy settings are reset, apps will stop using your location until you grant them permission.”

While Apple does not mention any other privacy settings affected by this option, we know that established pairing relationships are also removed. Unfortunately, there is no description as to what other things are affected by resetting Location & Privacy anywhere in the Knowledge Base.

Using Screen Time Password to Protect iPhone Local Backups

Mon, 28 Sep 2020 14:37:49 GMT

The iOS backup system is truly unrivalled. The highly comprehensive, versatile and secure backups can be created with Apple iTunes. For the user, local backups are a convenient and easy way to transfer data to a new device or restore an existing one after a factory reset. For forensic experts, iOS backups are an equally convenient, versatile and easy way to obtain a copy of the user’s data without attempting to break into the device. In malicious hands, the backup becomes a dangerous weapon. Logins and passwords from the Keychain allow hackers accessing the user’s social accounts, messages, and financial information. A backup password can be set to protect local backups, but it can be removed just as easily shall the hacker have access to the physical iPhone and know its passcode. In this article, we’ll discuss how the Screen Time password can be used to further strengthen the protection of local backups.

iTunes backups

In Apple’s land, backups are handled by the iTunes app installed on the user’s computer. The backups contain a lot of important information: a lot of app data, logins with passwords, Apple Watch backups, browsing history, and a lot more. This highly sensitive information can be protected with a password, which is then used to encrypt data before it even leaves the iPhone. The receiving end (the iTunes app, a forensic tool or a hacker’s utility) will only receive a stream of encrypted data that cannot be decrypted without the right password.

The encryption of local backups in iOS is extremely strong. Even the use of hardware acceleration delivers brute-force rates of just a few passwords per second. Accordingly, the brute-force attack is useless even if the user sets a simple 6-character password. However, even if you have a very strong password protecting your backup, photos and media can still be extracted if the iPhone can be unlocked.

Prior to iOS 11, a long and complex backup password was enough to securely protect data. There was no way to delete or change the password without entering the old one. This has changed in iOS 11.

Resetting backup passwords

iOS 11 brought the ability to reset iTunes backup passwords on the iPhone without entering or knowing the old password. If an attacker knows the screen lock password, they can use it to simply reset the backup password. After the reset, one can connect the iPhone to the computer and access the data, including passwords. Apple provides detailed instructions on how to reset your backup password:

With iOS 11 or later or iPadOS, you can make a new encrypted backup of your device by resetting the password. Here’s what to do:

On your device, go to Settings > General > Reset.
Tap Reset All Settings and enter your device passcode.
Follow the steps to reset your settings. This won’t affect your user data or passwords, but it will reset settings like display brightness, Home screen layout, and wallpaper. It also removes your encrypted backup password.
Connect your device to the Finder or iTunes again and create a new encrypted backup using the steps above.

You won’t be able to use previous encrypted backups, but you can use the Finder or iTunes to back up your current data and set a new backup password.

If you have a device with iOS 10 or earlier, you can’t reset the password.

Protecting backup passwords

As you can see, resetting the backup password is too easy. However, you can add an extra protection layer by setting the Screen Time password.

You can restrict the ability to reset the backup password by simply enabling the Screen Time password. While Screen Time passwords are in fact 4-digit PIN codes, they are still effective against on-device attacks. Since the Screen Time password is rarely used and differs from the device passcode, it is very unlikely that somebody watching from behind your back can pick it up. You will only need the Screen Time password on very rare occasions. You can even set a random code and write it down on a piece of paper.

What happens when you try to reset your backup password with the Screen Time password enabled? iOS will first prompt you for the device passcode, followed by the prompt for your 4-digit Screen Time password. This security measure is quite capable of not only deterring the curious, but also protecting the iPhone from targeted hacking attempts.

Revealing the Screen Time password

The Screen Time password is stored on the device. It is impossible to brute-force it on the iPhone as there will be progressively increasing delays between attempts. After several unsuccessful attempts, the system will limit the rate at which Screen Time passwords are searched by introducing delays of 1, 5, 15, and 60 minutes. After 10 unsuccessful attempts, each subsequent attempt can be made no earlier than in one hour; rebooting the device will not speed up the process. Thus, the 10,000 combinations can be tried in 416 days.

However, you may be able to extract the Screen Time password from the device if you can jailbreak it (and know the device passcode) or if you have an old backup to which you happen to know the password. The point is moot though, as in both cases you may be able to access the user’s data without breaking the Screen Time password.

Method 1: from a backup

In iOS 12, the Screen Time password was stored in the Keychain, which had it in plain text. The Screen Time password had the lowest protection class possible; it was not tied to the device so that restoring a new iPhone from the backup would re-enable the same Screen Time password. To extract the Screen Time password from an iOS 12 device, you will need:

Password-protected local backup (password must be known)

Since iOS 13, the Screen Time password no longer appears in local backups. The only way to obtain the password would be using a jailbreak to analyze the content of the device. In iOS 14, the Screen Time is not part of a local backup either. However, one may be able to extract the Screen Time password from iCloud; more information in How to Extract Screen Time Passcodes and Voice Memos from iCloud.

Method 2: via jailbreak

Obviously, the first method will only work if the backup does not have a password of if you know that password, making the whole point moot. However, if you can jailbreak the device, you may be able to extract that password easily. One would need to extract, decrypt and analyze the Keychain in order to discover the password. However, if the Keychain can be extracted and decrypted, there is really no point in accessing the Screen Time password as the data can be extracted via the jailbreak. In addition, the backup password itself can be also extracted from the Keychain: the backup password is also stored in plain text.

Method 3: via extraction agent

An extraction method offered in Elcomsoft iOS Forensic Toolkit does not use a jailbreak. Instead, this extraction method is based on direct access to the file system via an agent app. Using agent-based extraction, one can can perform the full file system extraction and decrypt the keychain without the risks associated with third-party jailbreaks.

One more thing

The Screen Time password is also stored in iCloud, but only if both two-factor authentication and the Screen Time “Share across devices” option are enabled. The password can be retrieved from iCloud with Elcomsoft Phone Breaker. To do this, you need all of the following:

The user’s Apple ID and password
Second authentication factor
Device passcode

Read more about extracting Screen Time passwords in How To Access Screen Time Password and Recover iOS Restrictions Password.

Conclusion

The Screen Time password is an effective way of protecting your backup password. If you set that password, your iPhone will receive an extra layer of protection against a factory reset. Anyone who wants to reset your iPhone or change your iCloud password will have to provide the Screen Lock password first – that’s in addition to your iPhone passcode. For some devices (the iPhone 8, 8 Plus and iPhone X and older models) have a BootROM vulnerability making them relatively easy targets. On newer devices, a combination of a 6-digit passcode, 4-digit Screen Time password and a strong backup password will deliver sufficient security if you keep your system up to date.

iOS 14 Forensics: What Has Changed Since iOS 13.7?

Thu, 24 Sep 2020 09:51:10 GMT

iOS 14 is officially out. It’s a big release from the privacy protection standpoint, but little had changed for the forensic expert. In this article, we’ll review what has changed in iOS 14 in the ways relevant for the forensic crowd.

iOS 14: supported devices

iOS and iPadOS 14 are updated for the same devices that could run iOS 13. This generally means iPhone and iPad devices equipped with Apple A7 through A13 Bionic SoC (iPhone 6s, SE, 7, 8, X, XR, XS, and iPhone 11 generation devices) with two notable exception. iOS 14 is also available for the iPad Air 2 (based on Apple A8x) and iPad mini 4 based on the Apple A8 CPU also found in the iPhone 6 and 6 Plus, which are not supported by iOS 14.

For older 64-bit devices (the iPhone 5s and iPhone 6 range) the latest version is iOS 12.4.8 released in June 2020. 32-bit devices such as the iPhone 5c are stuck with iOS 10.3.3.

Support for checkm8 and checkra1n

Some Apple devices have a hardware vulnerability in the BootROM that cannot be patched by Apple. By exploiting the vulnerability, experts have been able to extract data from unlocked devices.

Apple had made some changes attempting to mitigate SEPOS on devices based on the A10 and newer chips (except on Apple TVs and iBridge). According to checkra1n developers, “if the device was booted from DFU mode and the Secure Enclave receives a request to decrypt user data, it will panic the device. Since checkm8 does not give us control over the Secure Enclave, this is not trivial to workaround. However, with the recently published blackbird vulnerability, we are able to get control of the Secure Enclave on A10 and A10X and disable this mitigation. Support for A10 and A10X devices is being worked on and is expected to be ready in the coming weeks.”

At this time, the developers are not yet positive about whether they can do the same for devices with the A11 chip. As a result, a separate announcement will be made regarding the iPhone 8, 8 Plus, and iPhone X range of devices.

However, Apple had not been able to fully patch the vulnerability in the BootROM. The checkra1n developers have announced immediate availability of the jailbreak for the following devices:

iPhone 6s, 6s Plus, and SE
iPad 5th generation
iPad Air 2
iPad mini 4
iPad Pro 1st generation
Apple TV 4 and 4K
iBridge T2

Devices that are likely to receive support in the coming weeks:

iPhone 7 and 7 Plus
iPad 6th and 7th generation
iPod touch 7
iPad Pro 2nd generation

Finally, there following devices will be addressed in a future statement:

iPhone 8, 8 Plus, and X

The checkra1n jailbreak for iOS 14 can be downloaded from this link.

iOS 14 local backups

iTunes backups are commonly used during logical acquisition. Very little had changed in regards to local backups in iOS 14. If you are using Windows, you’ll need the latest version of iTunes (or forensic software updated to support iOS 14) in order to make local backups. It’s been reported that older versions of iTunes to not see devices updated to iOS 14.

We’ve seen some small changes to the backup format, which will require us to update Elcomsoft Phone Breaker and Elcomsoft Phone Viewer to fully support the new OS. Other than that, the encryption mechanism seems unchanged. The data available in local backups is very similar to that of iOS 13.7, meaning you can expect finding the familiar artifacts stored in the familiar places.

As in iOS 13.7, certain types of data are available if the backup encryption password is set. These include:

Keychain
Health data
Call logs
Safari history
Safari open tabs

We have not detected any notable changes to the content of local backups. We are working on an update to Elcomsoft Phone Breaker and Elcomsoft Phone Viewer to accommodate for the small changes in the format.

iCloud backups and sync

We have obtained iCloud backups made from the same device running iOS 13.7 and 14.0. Minor differences in communication protocols aside, there were no immediate changes to the content of cloud backups. We’re still in the process of doing the thorough comparison though. You will need using the current version of Elcomsoft Phone Breaker in order to download iCloud backups. We’ll still need to update Elcomsoft Phone Viewer to let you view them.

As to the iCloud sync, it seems the changes are minor, if there are any. In particular, we’ve been able to successfully sync Significant Locations. You can read more about iOS Significant Locations in our article Significant Locations, iOS 14 and iCloud.

File system images

We’ve been able to use the new checkra1n jailbreak to extract the file system from a test device before and after the update. While we’ll have to spend some more time analyzing the differences, it seems that all the major artifacts are there, and the file paths to the usual suspects have not changed. We are currently working comparing the file system images extracted from the same device running iOS 13.7 and updated to iOS 14.0.

Full file system extraction and keychain decryption for iOS 14 devices are possible with Elcomsoft iOS Forensic Toolkit thanks to checkra1n.

We’ve been able to perform both AFU and BFU extractions using the test device (iPhone 6s). We’re waiting for the availability of checkra1n for the latest generation of affected devices (the iPhone 7 and 7 Plus, iPhone 8, 8 Plus and X range) to verify AFU/BFU extraction.

When analyzing the file system images, we found some changes in Apple Maps data (altered paths and seemingly more data available). In addition, some extra data is available for threaded messages. Finally, we’ve seen the additional app permissions, which may be important when investigating incidents.

TL;DR: iOS 14 acquisition

So what are your options to acquire information from devices running iOS 14?

First, remember that extended logical acquisition always works for all models (from the original iPhone to the upcoming iPhone 12), regardless of the iOS versions. That includes not only backups, but also media files (including full metadata), shared application files and diagnostics logs. And it may work even for locked devices, if you have a valid pairing record and the USB restricted mode has not been activated.

iPhone 6s and iPhone SE: the checkra1n jailbreak is available, so it is easy to perform the full file system and keychain acquisition. For locked devices, partial acquisition is possible.
iPhone 7: checkra1n will be updated soon to support this model.
iPhone 8 and iPhone X: the situation is not clear. There is a small chance that checkra1n will support it too, but no ETA (and no warranty of any kind).
iPhone Xr, iPhone Xs, iPhone 11, iPhone 12: for now, only extended logical acquisition (see above); however, the chances that our agent acquisition method will support some of these devices are high. Stay tuned! For now, we support iPhone Xr/Xs/11 running iOS 13 only (from iOS 13.0 to 13.5).
Missing iPhone 6, iPhone 5s, iPhone 5 and older models? They simply cannot run iOS 14 (and iOS 13, actually).

Finally, you can perform a cloud acquisition. Just like the first method (extended logical), it works for all models and iOS versions. From the one side, you need the iCloud credentials; from the other side, you can acquire the data even without access to the device itself, and access the data that belongs to other devices connected to the same account, including the most secure categories such as iCloud keychain, Health data, encrypted iMessage conversations and more. Quite often this method returns more information than all other methods combined, including deleted data. Just use proper tools like Elcomsoft Phone Breaker.

More information

You may be interested in the findings published in the D20 Forensics blog:

In addition, Smarter Forensics had published the article Rotten to the core? Nah, iOS14 is mostly sweet, which is also worth checking out.

iOS 14 adds a bunch of privacy-oriented features. The two articles we recommend checking out are:

Conclusion

The work on iOS 14 forensics is still in progress. Unlike in previous iOS releases that had a number of apparent changes, we haven’t witnessed anything major in iOS 14 that could affect the work of forensic experts. We are still doing the in-depth analysis of file system images and backups obtained from the same devices prior to and immediately after an update. If we discover anything worth mentioning, we’ll post in our blog.

It’s Hashed, Not Encrypted

Wed, 09 Sep 2020 14:27:01 GMT

How many times have you seen the phrase: “Your password is securely encrypted”? More often than not, taking it at face value has little sense. Encryption means the data (such as the password) can be decrypted if you have the right key. Most passwords, however, cannot be decrypted since they weren’t encrypted in the first place. Instead, one might be able to recover them by running a lengthy attack. Let’s talk about the differences between encryption and hashing and discuss why some passwords are so much tougher to break.

Encryption and Hashing

Passwords are used to protect access to documents, databases, compressed archives, online accounts, and many other things one can think of. With few exceptions (such as the passwords stored in Web browsers, keychain, or IMAP/POP3 accounts), passwords are almost never stored, encrypted or not. Instead, passwords are “hashed”, or transformed with a one-way function. The result of the transformation, if one is performed correctly, cannot be reversed, and the original password cannot be “decrypted” from the result of a hash function. If you are interested in how password hashing works, check out this article: Hashing Passwords: One-Way Road to Security.

Figure 1: Encryption is a lossless, reversible, two-way transformation

What’s hashing all about? Hashing is a deliberately one-way algorithm that transforms data of any size to a string of a fixed size.

Figure 2: Hashing is a lossy, irreversible, one-way transformation

Cryptographic hash algorithms have several interesting properties. There must be no collisions. Flipping just one single bit in the original data set produces a completely new hash that does not even resemble the original. Have a look at these two hashes:

Original text: 000000000000
SHA-1: C2311E92660DE47B456E721B0DABC9F857AB48F0

Original text: 000000000001
SHA-1: F6A8135A89118200A9CC55D456C4D9A2D319FA29

As you can see, there is literally nothing in common between the two hash strings. You can play with hash values by using the simple online SHA-1 hash generator.

While the good hashing algorithms ensure that the checksum changes dramatically even with the flip of single bit, not everyone uses good hash functions. In a recent publication Tally ERP 9 Vault: How to Not Implement Password Protection I wrote about a hash function that was quite amusing. The developers of Tally Vault decided to give existing hash functions a pass, implementing their very own hash algorithm. They did an amazingly bad job in designing a hash function that only demonstrated slight modifications of the hash value with similarly slight alteration of the user’s password. This suggests a horribly weak implementation of key derivation in Tally Vault, making it an easy target for brute-force attack (which was confirmed later on). Considering that numerous cryptographically strong hash functions exist for a very long time, this result is truly amazing (as in “amazingly bad”).

Hashing must be implemented properly to provide secure password protection.

Today, we frequently use hash functions such as SHA-256 and SHA-512. The older SHA-1 is being slowly phased out after the purely theoretic discovery of the first collision back in 2017 made collision attacks practical.

Source: Google security blog

The choice of a hashing algorithm is crucial for password security.

More exotic hash functions such as Whirlpool also exist. Regardless of the name, hash functions must be quick to calculate, making it easy to both create and verify hashes. At the same time, it must be impossible to re-create the original data based on its hash function.

Impossible? Yes, when it comes to hashing large sets of data (e.g. the entire content of a document), re-creating the original document based on its hash alone is out of the question. However, passwords are usually made of a limited number of characters. The very limited length of most passwords makes it possible to hash all possible combinations of letters, numbers and special characters up to a certain length with the hope of eventually guessing correctly. This would be a brute-force attack, and this is how most passwords are broken.

Hashing and Hashing

While most passwords are hashed, some are notoriously slower to recover than others. The differences are caused by several reasons.

First, not all hash functions are created equal. SHA-1 is faster than SHA-256, which is faster than SHA-512, which is still faster than Whirlpool. Depending on the choice of a hash function, the attack may run faster or slower. This can be illustrated with the following screen shot showing the time (in milliseconds) required to verify a single password protected with 500,000 rounds of certain hash functions.

The choice of a hash function determines the password’s strength. Standard hash functions (SHA-256, SHA-512) are more than good enough.

The number of rounds (or the number of hash iterations) greatly affects the speed of verifying the password. Calculating a single hash value of a short string that is the password takes split milliseconds on modern hardware. If resources would be protected with a single hash iteration, we’d be getting attacks working at speeds in the range of tens of millions passwords per second. This is not a purely theoretical exercise; single-iteration attacks were possible in iOS 10.0 at around 6 million passwords per second on a five year old midrange Intel CPU. The more recent development enabled ultra-fast attacks on Tally Vault passwords with some 11 million passwords per second on a single i7 CPU.

Putting things into perspective, modern versions of Microsoft Office employ some 100,000 iterations for protecting documents and workbooks; a CPU-only attack produces the speed of about 10 passwords per second. Apple had bumped the number of hash iterations in iOS backups (since iOS 10.2) to 1,000,000; CPU-only attacks can now only try a handful of passwords per minute. VeraCrypt, a disk encryption tool, uses 500,000 iterations by default.

Increasing the number of hash iterations strengthens the password and slows down brute force attacks.

Hashing and Salting

There is one more thing about hashing passwords that comes to mind. What if someone wanted to take a shortcut, calculating a massive number of hashes corresponding to some 10 million most common passwords? Wouldn’t it be easier to simply look up the hash string in such a list? Or how about stealing a list of hashes and looking for some of the most common passwords in that list by their hash values? To mitigate these threats, we salt our hashes by adding unique random data to each password before calculating its hash value. The end result of this transformation is a salted password hash. To verify a salted hash, one needs the password itself and the salt value. The salt is usually stored along with the hash. Salt values stored in a separate database (or on a separate physical server) are called “pepper”.

In most circumstances, salt is absolutely required to secure your password.

All major manufacturers use salt when encrypting stuff or protecting online accounts. Exceptions are rare, but still occur.

Extracting iPhone File System and Keychain Without an Apple Developer Account

Thu, 03 Sep 2020 05:56:32 GMT

Last year, we have developed an innovative way to extract iPhone data without a jailbreak. The method’s numerous advantages were outweighed with a major drawback: an Apple ID enrolled in the paid Apple’s Developer program was required to sign the extraction binary. This is no longer an issue on Mac computers with the improved sideloading technique.

What’s this all about

When extracting an iOS device (pulling the file system and decrypting the keychain), one needs low-level access to the device. Traditionally, we’ve been using public jailbreaks for privilege escalation, yet recently we switched to a new method that does not require a jailbreak. Jailbreak-free extraction utilizes an Elcomsoft-developed extraction agent. Agent-based extraction provides tangible benefits over the traditional extraction method based on jailbreaking the device, being a safer, faster, and more robust alternative. Until today, agent-based extraction had a major drawback: in order to have the extraction binary signed, it required an Apple account registered in the Apple Developer program. We’ve circumvented this restriction in the latest release of iOS Forensic Toolkit for Mac. Users of the Windows edition still need the Developer account to perform the extraction.

A bit of history

Apple has a tight grip on the iOS ecosystem. In Apple dreams, everyone must pay for accessing the app ecosystem. Developers must purchase Apple hardware and Apple development tools; they must also purchase membership in the paid Apple Developer program. There is a separate recurring fee for publishing apps in the App Store, but even that fee does not guarantee the acceptance.

Users who wanted to install a non-approved app from a channel other than the official App Store had several choices. They could jailbreak the device and use one of the alternative app stores. They could pay Apple for the privilege by registering as a Developer. Finally, they could install a limited number of apps to their device and keep them for as long as 7 days without paying a dime. This process is called “sideloading”, and this is the same process that was used by forensic experts to install extraction software for imaging devices.

Historically, iOS users and forensic experts had been able to sideload third-party apps by using an ordinary, often throwaway Apple ID for signing the binaries. Cydia Impactor is a free tool often used for the purpose, but alternatives also exist. In November 2019, Apple made an abrupt change to their provisioning service, effectively blocking the sideloading mechanism for all but the users of a paid Apple Developer accounts. Saurik, the developer of Cydia Impactor, twitted about the issue. Since then, nothing but a paid Apple Developer account could be used to sign the binaries. Officially, this is still the case today. Unofficially, around the same time last year many users started having problems registering a personal Apple Developer account.

Developer or throwaway Apple ID for iPhone extraction?

A subscription to become a registered developer is affordable; it’s a tiny fraction of the cost of tools one needs to extract the iPhone. Using a developer account for sideloading the extraction software has tangible benefits over using a regular or anonymous (throwaway) Apple ID. We created a blog article explaining the benefits of the developer account compared to a throwaway Apple ID for the purpose of iOS extraction. In a word, utilizing an Apple account registered in the Developer program allows signing and sideloading apps, and bypassing the on-device certificate verification, which would otherwise require an Internet connection on the device with all the risks of exposing the device to remote lock/erase.

However, a large number of experts working for the law enforcement were and remain hesitant to obtain such accounts for various non-financial reasons. Registering for a personal Developer Account with Apple had become particularly challenging in the recent months, with Apple rejecting numerous applications with no explanation and no resolution through their support service. If you are seeing the “Your enrollment could not be completed” message, check out this thread for suggestions.

As a result, we’ve felt the urge to develop a working solution allowing experts to use regular or anonymous (throwaway) Apple IDs for signing the extraction software and performing the imaging.

Our work

We have discovered a way to enable the use of regular and disposable Apple ID’s for the purpose of agent-based data extraction. All you need is the latest build of iOS Forensic Toolkit, a Mac computer, and a cable to connect the iPhone to the Mac. In this guide, we’ll demonstrate how to image an iOS device with a disposable Apple ID.

Compatibility, pre-requisites and restrictions

In order to launch the attack, you will need all of the following.

A compatible iPhone model running a supported version of iOS. The list of supported devices is available below. At this time, agent-based extraction is supported for all models ranging from the iPhone 5s through 11 Pro Max with iOS 9.0 through 13.5.
A desktop or laptop computer with macOS 10.12 (Sierra) through 10.15 (Catalina).
A Lightning cable.
Apple ID (personal or disposable) with or without two-factor authentication.
iOS Forensic Toolkit 6.50 or newer.

Compared to using a Developer account, signing the extraction agent with a regular or throwaway Apple ID has the following restrictions.

The signing certificate is only valid for 7 days. This is normally not an issue as extractions should performed on the same day as sideloading the agent.
A non-developer Apple ID can be only used to sign a handful of devices (it was 3 devices when we last checked). This is why many experts prefer creating throwaway Apple IDs for device extractions.
You will need to pass two-factor authentication when signing in. The 2FA code will be pushed onto a trusted device (no SMS delivery), so you’ll need to have one ready. Note that you will not be prompted for the code if the Mac is already trusted (e.g. it is tied to the Apple ID you are about to use). We have not tested the tool with non-2FA accounts.
You will need to approve (Trust) the signing certificate on the iOS device. This is only possible when the device is connected to the Internet, so you’ll have to break the “Airplane mode only” rule to avoid the possible remote lock or erase command.

Steps to extract

Important: if you are performing a forensic extraction (as opposed to extracting your own iPhone), set up a restricted Internet connection first, as described in the following article: Setting Up Restricted Internet Connection.

Download Elcomsoft iOS Forensic Toolkit.
Install the toolkit by following the instructions in How to Install and Run iOS Forensic Toolkit on a Mac.
Launch iOS Forensic Toolkit.
Press 1 to sideload the agent onto the device. Note that you will have to pass two-factor authentication by entering the original Apple ID password (not an app-specific password as you previously would), and then one-time code (will be pushed to a trusted device).
Verify the extraction agent on the device. This will be using Internet connection. Once you verify the extraction agent, launch it by tapping its app icon.
Press 2 to extract and decrypt the keychain
Press 3 to extract the file system image
Press 4 to remove the extraction agent from the device

We strongly recommend extracting both the keychain and the file system as the content of the keychain could be used to decrypt certain app data (e.g. WhatsApp cloud backups, Signal and so on). The file system image can be analyzed in in Elcomsoft Phone Viewer or another forensic product.

Conclusion

Since November last year sideloading apps onto iOS devices had become more challenging. Apple made changes to its provisioning service, effectively breaking sideloading for all but the users of a paid Apple Developer account. We have discovered a way to enable the use of regular and disposable Apple ID’s for the purpose of agent-based data extraction. All you need is the latest build of iOS Forensic Toolkit, a Mac computer, and a cable to connect the iPhone to the Mac. In this guide, we’ll demonstrate how to image an iOS device with a disposable Apple ID.

iOS Forensic Toolkit for Mac circumvents the provisioning restriction that obliges users to use an Apple Developer account for imaging iOS devices. The Mac edition once again allows experts to use regular or throwaway Apple IDs for extracting the file system and decrypting the keychain from compatible iPhone and iPad devices. However, if one already has an Apple Developer account, we recommend continuing using that account to sideload the extraction binary due to the tangible benefits of this approach.

Setting Up Restricted Internet Connection for iPhone Extraction

Thu, 03 Sep 2020 05:50:24 GMT

Regular or disposable Apple IDs can now be used to extract data from compatible iOS devices if you have a Mac. The use of a non-developer Apple ID carries certain risks and restrictions. In particular, one must “verify” the extraction agent on the target iPhone, which requires an active Internet connection. Learn how to verify the extraction agent signed with a regular or disposable Apple ID without the risk of receiving an accidental remote lock or remote erase command.

What’s this all about

Elcomsoft iOS Forensic Toolkit utilizes a special technique for extracting the file system and decrypting the keychain from iOS devices without a jailbreak. This technique uses an in-house app that serves as an extraction agent. While agent-based acquisition provides numerous benefits over jailbreak-based acquisition, it requires the use of an Apple account to sign the extraction agent. Using a regular (non-developer) Apple ID to sideload the agent requires the expert to “trust” the signing certificate by “verifying” the extraction app. This, in turn, requires allowing the device to connect to an Apple server.

Allowing the device being investigated connecting to the internet is risky due to potential sync issues and the probability of receiving a remove lock or remote wipe command from the Find My iPhone service. Mitigating this risk is possible by restricting on-device connectivity to a single subdomain of apple.com that is required to verify the signing certificate.

Mitigating the risks

The easiest way to avoid the risks is eliminating the need for the iPhone to check the signing certificate. If the extraction agent is signed with an Apple ID enrolled in Apple’s Developer Program, the iPhone may remain offline when you sideload the extraction agent.

The troubles arise when you don’t have a Developer Account to hand, and still need to fulfil a device extraction. Note that you can only use a non-developer Apple ID to sign the extraction agent if you are using a Mac. Windows users must use an Apple ID enrolled in the Developer Program as there is no workaround available for that platform.

To reduce the risks of exposing the iPhone device being remotely tampered with, we’ll need to restrict it’s online connectivity. Ideally, the iPhone should be only able to connect to a single certificate validation server – with all other communications being terminated.

Apple Certificate Validation Server: ppq.apple.com (17.173.66.213), port 443.

There are several ways one can achieve the goal. For some, the easier method would be configuring a dedicated Wi-Fi network and setting up a router whitelist. Others will prefer to leave the device’s radios disabled, using a pre-configured wired connection instead (with Lightning to Ethernet adapter like this one, or a cheaper alternative, or a combination of the Lightning to USB Adapter and the USB Ethernet Adapter).

However, once you have a Mac, there is no requirement for any extra hardware, and you’ll be able to share the Internet connection from it to the iPhone, limiting access an easier way.

Step 1. Connect any iPhone (jut not the one being extracted!) to the Mac. Open [Settings] | [Shared] and make sure that Internet Sharing in “To computers using:” contains the “iPhone USB” item.

If there is no such item, temporarily enable Personal Hotspot (USB only). The item should appear. After that, you can disconnect the iPhone and disable the personal hotspot.

Step 2. Make sure that no iPhone is connected to the Mac, and activate firewall (for this specific interface only, i.e. iPhone USB), allowing access to ppq.apple.com only. That can be easily done by running our script as a root user, e.g.:

sudo ./install_firewall.sh

The content of the script is quite simple:

#!/bin/bash
cp /etc/pf.conf /etc/pf.conf.backup
echo "table <allowed-hosts> { ppq.apple.com, 192.168.2.0/24 }" >> /etc/pf.conf
echo "block drop in quick on bridge100 proto tcp from any to !<allowed-hosts>" >> /etc/pf.conf
pfctl -f /etc/pf.conf

Step 3. Connect the iPhone being investigated. The agent should be already installed (if it not installed yet, you can do it at this point), and enable Internet Sharing to iPhone USB.

Step 4. Approve/verify the certificate (issued to the Apple ID you used for sideloading the agent).

Step 5. Do the extraction with EIFT.

Step 6. You can uninstall the firewall now (and restore the original configuration, as it has been backed up at the second step) by running the second script, again as a root user:

sudo ./install_firewall.sh

This script is actually even simpler:

#!/bin/bash
cp /etc/pf.conf.backup /etc/pf.conf
pfctl -f /etc/pf.conf

You can also keep the current setup for further extractions (if you ever need to install the agent onto other iPhones). From now on, any iPhone connected to this Mac (after the firewall setup) will only have access to the particular Apple server required for certificate approval; it will not sync (neither the system nor any applications) or have access to any remote lock/wipe commands.

That’s it, you can now acquire the data from the device, including the full file system and keychain; more details here: Extracting iPhone File System and Keychain Without an Apple Developer Account.

Speed > Security – Apple’s Approach To iOS Data Security

Mon, 31 Aug 2020 08:52:02 GMT

Today I’m going to be discussing my understanding of a few security concepts Apple have implemented in iOS – including how these concepts influence the user experience and the inevitable outcome for your personal data security. This article is focusing specifically on the encryption-state handling mechanisms within iOS (which handle in what situations data stored on your iOS device is stored in an encrypted or decrypted state).

I find this subject especially interesting due to the consumer’s common perception that an iOS device has all user media data encrypted – contrary to my research which proves otherwise. It’s worth noting that not all of this is ‘unfound’. There are plenty of private agencies and individuals researching too! – I like to make my research public and develop open source solutions wherever ethically and legally possible!

Let’s begin to understand the encryption states relevant to iOS

Above, you’ll see a little table I’ve created that describes a few key features of both encryption states, specifically relevant to iPhone.

Firstly, let’s discuss the BFU state, which stands for Before First Unlock. It’s the state your iPhone will be in if you reboot and do not enter a passcode. In this state, consumers generally believe (rightly so) that all of their data is ‘fully encrypted’ and irrecoverable without the device passcode. We’ll talk more about the truth behind this later in the article.

Lastly, we have the AFU state. AFU stands for After First Unlock and describes a state where either the user passcode is known to the investigator, the device is post-unlock, or in situations where the device is locked but meets a variety of specific conditions.

In the AFU state, the SEP will allow for decryption of user media.

Sounds pretty fool-proof, right?

The SEP processor handling the data encryption process, there’s segregation between the user data and system volume, and various situations that will place the device from AFU to the BFU state.

Let’s think about the iOS user experience.

The iPhone unlocks incredibly fast upon boot which is great for the user experience, and looks amazing in the adverts! There’s also the fact that you’ll still retrieve notifications for your favourite applications in the BFU state.

Sounds great, right?

There’s a massive sacrifice in relation to device security happening in the background…

How is your iPhone unlocking so quickly if everything is encrypted, and how is your iPhone pulling application notifications prior to the first unlock? The user will have the same access level as the iPhone (if booted while exploited using checkm8).

If there’s no passcode entry for SEP to unlock the user media volume, how could this be possible? Is there an exploit for SEP? Some sort of magical ‘bypass’?

Well, the values in question were never encrypted to begin with. The iPhone holds various databases, caches and logs in a completely decrypted form.

Some could argue that it’s necessary for some values to be decrypted prior to the first unlock, such as the signed-in Apple ID, and potentially a thumbnail for installed wallet passes (prior to passcode entry the pass data would not be displayed).

While it’s true that some data is necessary for the basic functioning of a device in BFU, it’s important for us to focus on the sheer amount of data left in a decrypted state, and the extent that this fundamental platform insecurity can be exploited, and the data which can, in turn, be recovered with no knowledge of the user passcode.

We can begin to discover, parse, process and visualise data from a locked iPhone

How is your iPhone unlocking so quickly if everything is encrypted? How is your iPhone pulling these notifications for your apps prior to the first unlock? The iPhone will have the same access level as the user.

In a moment we’ll discover that anybody can dump the contents of their iPhone. The contents you’ll find, however, will depend on your ability to sift through data. Luckily for us, there are some steps we can take to automate both the discovery and presentation process! We’ll come back to that soon – anyway, back to the article…

If there’s no passcode entry in order for SEP to unlock the user media volume, how could data extractions be possible?

Well, the truth is that the values in question were never encrypted in the first place.

The iPhone holds various databases, caches and logs in a completely decrypted form. This means anyone with enough time (and a device compatible with the checkm8 exploit in order to start the SSH Daemon on device) could parse, process and visualise a partial data extraction from the device without a valid passcode.

Technology to facilitate/automate this process is largely private and undisclosed to the public. I felt that there should be an Open Source solution for such a task.

Although this presents a major ethical question due to potential misuse, I believe that a free Open Source solution will raise public understanding of such processes and be able to drive further interest and research in the field.

What can an attacker learn about me using my locked iPhone?

It’s a scary question, and unfortunately comes with a scary answer too…

The amount of data that can be accessed using various techniques in the BFU state, but is not limited to:

Email Accounts on-device
Social Account User IDs – SnapChat Logged In account name, for example.
Conversation & Unique Contact IDs for some third party applications – including SnapChat and WhatsApp
WiFi Access Points (Historical)
Historical Location Data
Partial User-Media Access
Installed Applications & Basic Usage Data
Much, much more! – this is just scratching the surface

I wonder how this looks in code?…

Above you’ll find an example of an ‘Artifact’ for ZPET in the form of a C ‘Struct’.

Artifacts are used widely across the forensic industry as a method of defining how a specific data-point can be identified/found in the filesystem. Artifacts can come in the form of a plethora of formats, including SQL Queries, commands and sometimes entire scripts if the particular data-point requires extensive parsing to reveal.

We talk about artifacts and how we can find them in a little more detail in my new book iOS Research & Exploration Volume I – where pre-order pricing is still available for a few more days.

From the artifact pictured above in the ZPET Module Extract, we can deduce that the file we’ll be parsing is com.apple.batterydata.cyclecount.plist. This target file contains hundreds of values which we’ll need to automate sifting through.

To demonstrate this, here’s an extract of the com.apple.batterydata.cyclecount.plist PLIST printed (it should appear below this text)

As an investigator, checking out each file in the filesystem will allow us to find what we need – eventually… but realistically, we only want to output the ‘specific value’ we’re looking for.

In the case of ZPET, we can specify the ‘sval’ meaning specific value. This is also known as the ‘Key’ when talking about the PLIST structure. Observing the plist structure, we can identify that our ‘Key’ will be Serial.

If you haven’t guessed, it’ll pull your battery serial number. Here’s an example of how that specific artifact will display in the ZPET Web Output:

If you’re interested in discovering new artifacts, I recommend that you check out my research automation project SPIDER, which is designed specifically to allow beginners to discover data within an iOS Filesystem Dump (you can acquire this dump from your own jailbroken device (or a device vulnerable to checkm8) using a free tool such as iPhone-rootFS-Tool on my GitHub).

I also encourage you to dump the filesystem in both BFU and AFU states, and compare your results! It’ll be a great learning experience and aid your understanding of ‘BFU vs AFU’.

I’ll be posting similar articles to this soon, which will go into more technical depth and work with iOS forensics on a deeper level.

A little conclusion & where to go from here

Thanks for reading! I try to keep my articles short and concise – today’s was a little longer than usual; I hope it was easy to follow! For extra reading, I recommend you dump your own iDevice using a tool of your choosing, take a look at the ZPET source code, and start creating your own ZPET modules.

Remember to make a pull request and let me know so I can share it via Twitter, too!

As always, take care and feel free to drop me a message on Twitter anytime at @J_Duffy01

—James

Behind the iPhone 5 and 5c Passcode Cracking

Tue, 25 Aug 2020 06:59:14 GMT

Smartphones are used for everything from placing calls and taking photos to navigating, tracking health and making payments. Smartphones contain massive amounts of sensitive information which becomes essential evidence. Accessing this evidence can be problematic or expensive, as was clearly demonstrated during the FBI-Apple encryption dispute, which was about the iPhone 5c used by the San Bernardino shooter in December 2015. With modern technological advances, iPhone 5c unlocks are no longer an issue.

The (in)famous iPhone 5c

Apple released the iPhone 5 in September 2012. The phone shipped with iOS 6.0; the latest version of iOS available for this device is currently iOS: 10.3.4.

In September 2013, Apple released not one but two iPhones: the highly innovative (and expensive) iPhone 5s that was, for the first time, equipped with a hardware security co-processor (Secure Enclave) and a fingerprint reader, and the iPhone 5c, a stripped-down phone based on last-year hardware.

With the release of the iPhone 5c, Apple made a controversial attempt to enter the budget phone market. Its colorful back made of gloss plastic met lukewarm response. However, due to its affordable price and wide mobile carrier acceptance, this 2013 model had become one of the most popular budget phones sold by the US carriers.

The iPhone 5c became the last 32-bit iPhone made by Apple. The iPhone 5c was originally released with iOS 7.0 on board; the latest version of iOS available for this phone today is iOS 10.3.3.

The iPhone 5c became famous after the terrorist shooting in San Bernardino in December 2015, which turned into a heated FBI–Apple encryption dispute. In this dispute, the Federal Bureau of Investigation wanted Apple to create and electronically sign software that would enable the FBI to unlock a work-issued iPhone 5C it recovered from one of the shooters. The iPhone 5c was recovered intact but was locked with a four-digit password and was set to erase the data after ten failed password attempts (a common anti-theft measure on Apple smartphones). Apple declined to create the software, and a hearing was scheduled for March 22. However, a day before the hearing was supposed to happen, the government obtained a delay, saying they had found a third party able to assist in unlocking the iPhone and, on March 28, it announced that the FBI had unlocked the iPhone and withdrew its request. It was eventually found that the phone revealed nothing about the plot.

How exactly the FBI received the correct passcode, who was the contractor that did it, and how much exactly the contractor was paid for the service remains officially unknown. Some news outlets, citing anonymous sources, identified the third party as Israeli company Cellebrite. However, The Washington Post reported that, according to anonymous “people familiar with the matter”, the FBI had instead paid “professional hackers” who used a zero-day vulnerability in the iPhone’s software to bypass its ten-try limitation, and did not need Cellebrite’s assistance. According to FBI Director James Comey, the tool (or service) cost more than $1.3 million. Since neither Cellebrite nor the unnamed “professional hackers” can openly comment on the matter, it still remains unknown who did it. Based on vaguely formulated comments, one might be inclined to believe that Cellebrite were the original contractors. Whether this was or wasn’t the case, the “other third party” would be unable to publicly confirm or deny. No confirmed sources exist.

Today, we released a software-only solution that costs just slightly more than 0,1% of the price allegedly paid by the FBI for the tool that was used for breaking that iPhone. Elcomsoft iOS Forensic Toolkit can brute force the iPhone 5/5c lock screen password, enabling investigators to unlock iPhone devices protected with unknown passcodes.

When speaking of passcode recovery, we must mention the work of Sergei Skorobogatov. In his research project: Security Analysis of Apple iPhone 5c (based on his full research paper titled “The bumpy road towards iPhone 5c NAND mirroring”), Sergei demonstrated a proof-of-concept attack allowing to exploit the iPhone 5c and run an attack on its passcode. Sergei’s work requires disassembling the phone, and is subject to a 5 second delay between passcode attempts. In his work, Sergei claims that breaking a 4-digit passcode is possible in about a day, while 6-digit PIN recovery would take unreasonable time.

Finally, the IP-BOX solution and its many clones were available for iOS versions up to and including iOS 8.1. These boxes are not compatible with any newer versions of iOS, and their speed is similar to Sergei’s solution (around 6 seconds per passcode attempt, or about 17 hours to break a 4-digit PIN).

Compared to both of these, our solution does not require additional hardware (you’ll need a Mac though), does not require disassembling the phone, and runs about 80 times faster.

How does the passcode recovery work, and why is it so important in the world of iOS Forensics? Read along to find out.

Passcode as a hallmark of iOS security

The passcode is the most important part of the iPhone security model. Since iOS 8, the user data including the passwords stored in the keychain is encrypted with a key derived from the user’s passcode. Without breaking the passcode, one would be unable to access essential information in BFU (Before First Unlock) devices. Speaking of such devices, bypassing the screen lock passcode makes little sense as the data will remain securely encrypted.

iOS passcode protection is well-documented. The following excerpt from the extremely comprehensive Apple Platform Security documentation explains the role of the passcode in the iOS ecosystem

By setting up a device passcode, the user automatically enables Data Protection. iOS and iPadOS support six-digit, four-digit, and arbitrary-length alphanumeric passcodes. In addition to unlocking the device, a passcode provides entropy for certain encryption keys. This means an attacker in possession of a device can’t get access to data in specific protection classes without the passcode.

The passcode is entangled with the device’s UID, so brute-force attempts must be performed on the device under attack. A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds.

Touch ID and Face ID can be used to enhance this equation by enabling the user to establish a much stronger passcode than would otherwise be practical. This increases the effective amount of entropy protecting the encryption keys used for Data Protection, without adversely affecting the user experience of unlocking an iOS or iPadOS device multiple times throughout the day.

To further discourage brute-force passcode attacks, there are escalating time delays after the entry of an invalid passcode at the Lock screen. On devices with Secure Enclave, the delays are enforced by the Secure Enclave coprocessor. If the device is restarted during a timed delay, the delay is still enforced, with the timer starting over for the current period.

Source: Apple Platform Security

Speaking of legacy iPhones, the iPhone 5 and iPhone 5c in particular, we have measured the time delay between passcode attempts. The result was exactly 13.6 passcodes per second, or 73.5ms per attempt. This is very close to Apple’s target of 80ms. Since there is no Secure Enclave in these iPhone models, the escalating time delays are enforced in software by the operating system as opposed to being enforced by the Secure Enclave coprocessor. This in turn means that one can theoretically (and practically) disable the delay provided that one has access to certain system files.

Last but not least, the iPhone 5 and iPhone 5c are not equipped with biometric identification hardware. The passcode is the only mean to secure the device. Remember the “Touch ID and Face ID can be used to enhance this equation by enabling the user to establish a much stronger passcode than would otherwise be practical” part? Since there are no alternative means for securely unlocking these iPhone models, users are very likely to choose short, simple PIN codes instead of the longer alphanumerical passcodes to avoid “adversely affecting the user experience of unlocking an iOS device multiple times throughout the day”.

Which passcodes are the most common?

The types of passcodes most frequently selected by the users depend on several factors: the default setting in iOS, and the factor of convenience, which takes into account the presence or lack of the Touch ID/Face ID and the speed and convenience of typing a certain passcode.

The defaults

iOS 6 had a single setting named Simple passcode, which was enabled by default. The resulting passcode, by default, would then consist of only 4 digits. If the user disabled the setting, they could use an alphanumeric passcode of any length. However, if the user had entered any number of digits other than four, the lock screen would display a digit-only keyboard (and a variable size text field). Therefore, our unofficial classification of the types of passcodes available in iOS 6 has the following options:

4-Digit Numeric Code
Custom Numeric Code (other than 4-Digit Numeric Codes)
Custom Alphanumeric Code

In iOS 9 (as well as iOS 10) the following four options were available:

4-Digit Numeric Code
6-Digit Numeric Code
Custom Numeric Code
Custom Alphanumeric Code

According to multiple sources, ever since iOS 9 Apple shifted to six-digit passcodes, making them the default option. We could not verify this claim for the two iPhone models in question. Our internal tests of setting up iPhone 5 and iPhone 5c devices after a factory reset resulted in iOS consistently offering to set a 4-digit numeric code. Even more interesting is the observation that, once you attempt to change your 6-digit passcode, iOS will still offer setting a 4-digit PIN. We believe this to be part of the “convenience factor”, as a 6-digit passcode would be undoubtedly “adversely affecting the user experience of unlocking an iOS device multiple times throughout the day” as noted in the Apple Platform Security documentation.

The convenience factors

What kind of passcodes are users likely to have on their pre-Touch ID devices? In May, 2020, Philipp Markert, Daniel V. Bailey, Maximilian Golla, Markus Dürmuth, and Adam J. Aviv performed a study of user-chosen 4- and 6-digit PINs collected on smartphones for device unlocking. In their study, the researchers combined multiple datasets originating from various leaks and testing some 1220 participants. The study helped determine the most commonly used 4-digit and 6-digit PINs.

The researchers have made the following findings, which may seem rather controversial. In their study, the researchers found there was little benefit to longer 6-digit PINs as compared to 4-digit PINs. The study’s participants tended to select more-easily guessed 6-digit PINs when considering the first 40 guesses of an attacker. Moreover, their results show that currently employed PIN blacklists are ineffective. Through quantitative and qualitative feedback, the researchers found that participants perceive that blacklisting will improve their PINs without impacting usability. (source)

Commonly used passcodes

We strongly recommend reading the entire research to get a better understanding on how users choose their screen lock passcodes. What really matters though is the list of the most commonly used (thus insecure) 6-digit PINs. There are only 2910 entries in this list, and it only takes about 4 minutes to test them all. Examples on this list include the world hit 123456, repeated digits, as well as the digital passcodes representing certain combinations (e.g. 131313 or 287287). Following this list are the 6-digit PINs based on the user’s date of birth; there are around 74K possible combinations that take about 1.5 hours to try. Only after these options are exhausted do we start the full brute-force attack that lasts around 21 hours.

Conclusion

The iPhone 5 and 5c are now almost 7 years old, yet many of them are still stored in forensic labs, waiting to be extracted. In some parts of the world, these inexpensive iPhones are still in active circulation. It took years for the first exploit to appear at an outrageous price, and even more time for reasonably priced solutions. Today, we are bringing the cost of high-speed iPhone 5 and 5c unlocks down, offering a software-only solution that requires no soldering, no disassembling and no extra hardware. See iPhone 5 and 5c Passcode Unlock with iOS Forensic Toolkit for details.

iPhone 5 and 5c Passcode Unlock with iOS Forensic Toolkit

Tue, 25 Aug 2020 06:56:23 GMT

We have discovered a way to unlock encrypted iPhones protected with an unknown screen lock passcode. Our method supports two legacy iPhone models, the iPhone 5 and 5c, and requires a Mac to run the attack. Our solution is decidedly software-only; it does not require soldering, disassembling, or buying extra hardware. All you need is iOS Forensic Toolkit (new version), a Mac computer, and a USB-A to Lightning cable. In this guide, we’ll demonstrate how to unlock and image the iPhone 5 and 5c devices.

Passcode attacks: know your options

Apple implements strong protection to defend its devices against brute force attacks. While newer devices (the iPhone 5s and subsequent models) rely on Secure Enclave to slow down attacks to a crawl, 32-bit devices such as the iPhone 5 and 5c are not equipped with a hardware security coprocessor. As a result, both the escalating time delays after the entry of an invalid passcode at the Lock screen and the optional setting to wipe the device after 10 unsuccessful attempts are enforced in software by iOS. Disabling these mechanisms removes the risk of losing the data and turns off the escalating time delay, enabling the attack to work at a full speed of exactly 13.6 passcodes per second, which is very close to Apple’s target of 80ms between passcode attempts.

Breaking 4-digit and 6-digit PINs

Considering the speed of 13.6 passcodes per second, it only takes 12 minutes to try all possible combinations of 4-digit PINs. The enumeration of all 6-digit PINs, however, will take up to 21 hours. For this reason, we’ll try the most popular passcodes first. There are 2910 commonly used 6-digit PINs, and it only takes about 4 minutes to test them all. Following this list are the 6-digit PINs based on the user’s date of birth; there are around 74K possible combinations that take about 1.5 hours to try. Only after these options are exhausted do we start the full brute-force attack that lasts around 21 hours.

Alphanumeric passcodes

At the given speed, the recovery of an alphanumeric passcode becomes extremely iffy unless you have targeted dictionary of the user’s other passwords. For the time being, iOS Forensic Toolkit does not support alphanumeric passwords. If an alphanumeric passcode is detected, you’ll see the “unsupported” message, and the attack will stop. We will probably add support for alphanumeric passwords in the next version.

Compatibility and pre-requisites

In order to launch the attack, you will need all of the following.

A compatible iPhone model. Supported devices include the iPhone 5 (A1428, A1429, A1442) and iPhone 5c (A1456, A1507, A1516, A1526, A1529, A1532) models.
A desktop or laptop computer with macOS 10.12 (Sierra) through 10.15 (Catalina).
A Lightning cable. Please use USB-A to Lightning due to known incompatibilities in Apple’s and most third-party USB-C to Lightning cables. You can use the optional USB-C to USB-A adapter if needed.
iOS Forensic Toolkit 6.40 or newer.

Steps to unlock the iPhone 5c

First, install iOS Forensic Toolkit and make yourself familiar with the checkra1n jailbreak by following these preliminary steps:

Download Elcomsoft iOS Forensic Toolkit. Insert the USB dongle.
Install the toolkit by following the instructions in How to Install and Run iOS Forensic Toolkit on a Mac. Note that there is an extra mandatory step on macOS Catalina.
Check out checkra1n Installation Tips & Tricks, in particular:
1. No hubs!
2. Use USB-A to Lightning cable only (no USB-C to Lightning);
3. Make sure the phone is charged to at least 20%.

Once you have installed, configured and launched Elcomsoft iOS Forensic Toolkit, enter ‘P’ in the main window to access the passcode cracking functionality.

The following options will be available:

[1] Put device in DFU mode
[2] Exploit device
[3] Break 4-digit passwords
[4] Break 6-digit passwords
[5] Reboot device

Since the passcode recovery functionality is based on the checkm8 exploit, you will need to switch the device into DFU mode. This can be only done manually on the device. However, selecting the [1] option in the Toolkit will guide you through the process.

More than one method of switching the phone into DFU mode may exist for the device (more on that here). We found the following one to be easier than the others. Follow these instructions:

Make sure the device is not connected to the computer and turned off.
Press the Home button, insert the lightning cable, keeping the Home button pressed until the device reads “Connect to iTunes” on the display; release the Home button.
Press and hold the Home and Sleep/Power (top) buttons together for 8 seconds (Apple logo will appear for some time, then the screen turns black).
Release the Sleep/Power button but keep the Home button pressed for 8 more seconds.
Release the Sleep/Power button. If you did everything right, the screen should remain blank, and the phone should appear in iTunes or Finder (depending on your macOS version) as an iPhone in recovery mode. Now it is ready for further steps.

Once the device is in DFU mode, select the second option to exploit by making it boot a special custom firmware. This process is safe for the phone data. It does not change anything on the device since the exploit works entirely in the device volatile memory. There will be no traces left on the device.

If the exploit fails for any reason, repeat the process from the beginning. Note that you will have to reboot the device by pressing Home and Power buttons simultaneously for 8 seconds, and re-enter the DFU mode. Also note that, from the point of view of installing the exploit, going straight to DFU works in most cases. However, if you have errors when attempting to exploit the device, we’ve seen reports where going through the Recovery mode fixes the issues. The developers of the checkra1n jailbreak also recommend using the Recovery mode first. You may try it either way; if the exploit does not work when going straight the DFU, try to get through Recovery mode. This is how the error message may look like:

Another common error is Failed to upload iBSS. This is generally nothing to worry about. Your device is still compatible with the checkm8 exploit and our method in general, you just need another try. Sometimes it takes up to 5 attempts, and there is nothing we can do about that: this is more about the hardware and the driver quality, the issues that cannot be fixed in our software.

Once the device is successfully exploited and the user partition is mounted, you can run the recovery of 4-digit or 6-digit passcodes.

Breaking a 4-digit PIN normally takes 12 minutes or less, while the complete enumeration of all possible 6-digit passcodes may take up to 21 hours. Alphanumeric passwords are not supported at this time.

After the passcode is discovered, reboot the iPhone by selecting the last menu item. Now when you have access to the device, the data extraction will be another thing. We will soon add keychain decryption and full file system extraction for these devices.

Conclusion

Breaking LUKS Encryption

Tue, 18 Aug 2020 06:55:15 GMT

LUKS encryption is widely used in various Linux distributions to protect disks and create encrypted containers. Being a platform-independent, open-source specification, LUKS can be viewed as an exemplary implementation of disk encryption. Offering the choice of multiple encryption algorithms, several modes of encryption and several hash functions to choose from, LUKS is one of the tougher disk encryption systems to break. Learn how to deal with LUKS encryption in Windows and how to break in with distributed password attacks.

Disk Encryption Basics

All disk encryption tools rely on symmetric cryptography to encrypt data. More often than not, major disk encryption tools rely on the hardware-accelerated AES encryption with a 256-bit key, although Microsoft BitLocker defaults to using 128-bit AES keys. Some disk encryption tools offer the choice of encryption algorithms, the champion being VeraCrypt with some 15 options for symmetric encryption.

The symmetric encryption keys are derived from the user’s password (or other data) by using a Key Derivation Function (KDF). The KDF employs one-way transformations (hash functions) of the user’s input to produce the binary encryption key (or an to unwrap an intermediary key that decrypts the actual symmetric encryption key). Different hash functions and with numerous hash iterations are used to slow down the speed of potential brute force attacks.

When attacking an encrypted container, you must either know the exact combination of the encryption algorithm, the hash function, and the number of hash iterations. Making the wrong choice effectively voids your chance of successful recovery even if you stumble upon the correct password.

LUKS Disk Encryption

LUKS is a platform-independent disk encryption specification originally developed for the Linux OS. LUKS is a de-facto standard for disk encryption in Linux, facilitating compatibility among various Linux distributions and providing secure management of multiple user passwords. Today, LUKS is widely used in nearly every Linux distribution on desktop and laptop computers. It is also a popular encryption format in Network Attached Storage (NAS) devices, particularly those manufactured by QNAP.

In addition to full-disk encryption, LUKS can be used to create and run encrypted containers in a manner similar to other crypto containers such as VeraCrypt. Encrypted containers feature the same level of protection as LUKS full-disk encryption.

LUKS offers users the choice of various encryption algorithms, hash functions and encryption modes, thus providing some 45 possible combinations.

LUKS encryption algorithms

LUKS supports multiple combinations of encryption algorithms, encryption modes, and hash functions including:

AES
Serpent
Twofish
CAST-128
CAST-256.

Being the only hardware-accelerated encryption algorithm, AES is by far the most common of the three, especially when used in enterprise environments and network attached storage (NAS) devices. AES encryption offers that highest stream cipher performance when used on chip sets featuring AES encryption acceleration (e.g. the AES-NI instruction set in Intel CPUs). Serpent and Twofish can be manually specified by the user at the time of creating the encrypted volume. In our tools, AES, Serpent, and Twofish algorithms are supported.

LUKS encryption modes

LUKS supports the following encryption modes:

ECB
CBC-PLAIN64
CBC-ESSIV:hash
XTS-PLAIN64

Various Linux distributions may use different default settings when setting up an encrypted volume. For example, Red Hat Linux employs cbc-essiv:sha256 with a 256-bit AES key, which is the default combination for many popular Linux distributions. Our tools support CBC-PLAIN64, CBC-ESSIV:SHA256, and XTS-PLAIN64 encryption modes.

LUKS hash functions

In disk encryption, hash functions are used as part of the Key Derivation Function (KDF). KDF are used to derive the binary encryption key out of the user-provided input (typically, a text-based passphrase). The following hash functions are supported in the LUKS specification:

SHA-1
SHA-256
SHA-512
RIPEMD160
WHIRLPOOL *

* The support for WHIRLPOOL is not part of the specification, yet our tools support this hash function along with the four “official” ones. By default, most Linux distros use SHA-256 as a hash function.

LUKS Default encryption settings

While the maintainers of each Linux distro and hardware manufacturers with embedded Linux are free to choose their very own default encryption settings, aes-cbc-essiv:sha256 with 256-bit symmetric encryption keys is the most common default encryption setting. This is what it stands for:

AES – the encryption algorithm is AES (by default, 256-bit keys are used)
CBC – Cipher Block Chaining encryption mode
ESSIV – Encrypted Salt-Sector Initialization Vector. This IV should be used for ciphers in CBC mode.
SHA-256 – Secure Hash Algorithm computed with 32-bit words. This is the default hash function for ciphers in CBC mode.

Non-default encryption settings

Decryption settings other than the defaults can be specified by the user at the time they encrypt the disk. Unlike TrueCrypt/VeraCrypt, LUKS does store the information about the selected encryption settings in the encryption metadata, making it possible to detect the encryption settings prior to launching the attack. Elcomsoft Distributed Password Recovery automatically detects LUKS encryption settings by analyzing the encryption metadata, which must be extracted with Elcomsoft Forensic Disk Decryptor prior to launching the attack.

Multiple encryption keys

A single LUKS volume may be protected with more than one key. The specification allows multiple user keys to decrypt the master key that is used for encryption. As a result, a LUKS-encrypted device may contain multiple key slots, which are used to store backup keys/passphrases and to allow multiple users unlock LUKS volumes each with their own password.

Each key slot is protected with a unique salt, making the reverse brute force attack (matching the same KDF of a password against the different slots) unfeasible. A KDF must be calculated separately for each key slot during the attack. As a result, recovering password to protecting a LUKS device requires selecting a key slot to attack. This selection is performed with Elcomsoft Distributed Password Recovery when setting up the attack.

Breaking LUKS Encryption Step 1: Extracting Encryption Metadata

To secure access to the data stored in the encrypted device, you must first recover the original, plain-text password. There are several steps involved requiring the use of several different tools.

Extract the encryption metadata from the encrypted device or disk image using Elcomsoft Forensic Disk Decryptor or Elcomsoft System Recovery.
Use the extracted metadata (a small file) to launch an attack on the password with Elcomsoft Distributed Password Recovery.
Once the password is found, mount the disk volume or decrypt the data.

We have two different tools for extracting LUKS encryption metadata. The choice of the right tool depends on whether you are working in the field or in a lab. If you are analyzing the suspect’s computer, Elcomsoft System Recovery can be used to boot the system from a USB flash drive and extract the encryption metadata from the storage devices connected to the computer.

Note: LUKS encryption is supported in Elcomsoft System Recovery 7.06 and newer. If you are using an older version of the tool, please update to the latest version to obtain LUKS support.

Download Elcomsoft System Recovery, launch the installer and create a bootable USB drive.
Use the USB drive to boot the target system into the Windows PE environment.
Elcomsoft System Recovery will be launched automatically.v
Review the attached disks.
Select LUKS-encrypted partitions and click “Dump” to extract the encryption metadata.
Transfer the encryption metadata on your computer and use it with Elcomsoft Distributed Password Recovery to launch an attack on the LUKS encryption password.

If you are working in a lab and processing disks or disk images, you’ll be using Elcomsoft Forensic Disk Decryptor. Extracting encryption metadata with Elcomsoft Forensic Disk Decryptor is simple.

Note: LUKS encryption is supported in Elcomsoft Forensic Disk Decryptor 2.13 and newer versions. If you are using an older version of the tool, please update to the latest version to obtain LUKS support.

Launch Elcomsoft Forensic Disk Decryptor.
Select operation mode “Extract/prepare data for further password recovery”.
Open the physical device or disk image containing LUKS volume(s). In the example below, we’re dealing with a physical device.
EFDD will display the list of encrypted volumes. Select the volume you are about to extract encryption metadata from.
Click Next to extract the encryption metadata and save it into a file.

Breaking LUKS Encryption Step 2: Attacking the Password

While LUKS offers strong protection against brute force attacks by using thousands of iterations of a hash function during key derivation, we have significant advances in password recovery attacks compared to what we had in the past. Brute-forcing a password today becomes significantly faster due to the use of GPU acceleration, distributed and cloud computing. Up to 10,000 computers and on-demand cloud instances can be used to attack a single password with Elcomsoft Distributed Password Recovery.

In order to set up the attack, do the following.

Launch Elcomsoft Distributed Password Recovery.
Open the file containing the encryption metadata that you obtained with Elcomsoft Forensic Disk Decryptor during the previous step.
The available key slots along with the number of hash iterations will be displayed. Specify the key slot to attack.
Configure and launch the attack.

Brute force attacks became not just faster, but much smarter as well. The user’s existing passwords are an excellent starting point. These passwords can be pulled from the user’s Google Account, macOS, iOS or iCloud keychain, Microsoft Account, or simply extracted from the user’s computer. The user’s existing passwords give a hint at what character groups are likely used:

Elcomsoft Distributed Password Recovery offers a number of options to automatically try the most common variations of your password (such as the Password1, password1967 or pa$$w0rd):

Masks can be used to try passwords matching established common patterns:

Advanced techniques allow composing passwords with up to two dictionaries and scriptable rules:

How Long Will It Take to Break the Password?

Even if you know exactly how many passwords per second the attack will yield, there are many things affecting the time it will take to recover the LUKS password. The length of the password and its entropy, as well as the things you know about the password or the way the user makes up their passwords, will have drastic effect on the time it will take to break a particular LUKS volume.

What about the recovery speed? The speed is also not a constant, and there are a lot of things affecting the speed of the attack that aren’t immediately obvious. The number of passwords per second you can try depends on several things, the most important being the following:

The hardware. The more/higher end video cards you have, the higher the raw speed you will get. Same goes for the number of computers doing the attack; the more computers are crunching the password, the faster the speed will be.

The hash function. Some hash functions are slower than others. In the case of LUKS, the user has the choice of five hash functions including RIPEMD160, SHA-1, SHA-256, SHA-512, and WHIRLPOOL, RIPEMD160 being the fastest and WHIRLPOOL the slowest of the pool. Depending on the choice of the hash function made at the time of setting up the encryption, your attacks may go faster or slower.

The encryption algorithm and encryption mode. Once again, these settings are selected at the time the user sets up the encryption. The choice affects the speed of the attack, but to a significantly minor degree compared to the choice of a hash function.

The number of hash iterations and, indirectly, the speed of the user’s computer. Unlike other disk encryption tools such as BitLocker or VeraCrypt, LUKS varies the number of hash iterations used to protect the master encryption key. When creating an encrypted disk with a given combination of encryption settings, LUKS benchmarks the user’s system. The data is used to select the number of hash iterations protecting the master encryption key. Effectively, LUKS-encrypted disks or containers created on a lower-end computer will feature weaker protection compared to similar disks or containers created on higher-end hardware. The number of hash iterations does not change if the disk or container is moved to a new, more powerful computer.

What’s even more interesting is that the number of hash iterations varies depending on the choice of other encryption settings. A larger number of hash iterations is selected if a weaker (faster) hash function is used, and vice versa. Theoretically, the variable number of hash iterations would make the speed of attacking LUKS volumes or containers created on similar hardware the same regardless of the chosen hash function and encryption settings. This is not the case; there are still differences in attack speeds between the different algorithms and hash functions as shown in the following benchmark.

Notably, the number of hash iterations is stored with other encryption metadata (which is not the case for TrueCrypt/VeraCrypt containers making the number of hash iterations yet another user-provided secret).

Conclusion

LUKS is not only a popular and widespread encryption specification, it’s also a very interesting one to work with. The support of multiple key slots, the choice of hash functions, encryption algorithms and encryption modes, and the benchmark-based algorithm for automatically selecting the number of hash iterations when setting up encryption based on the performance of the user’s computer make LUKS an exemplary implementation of disk encryption.