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

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

By James Duffy at 2020-08-31 11:52:02 Source ElcomSoft blog:

New Yubico for Free Speech Program Arms Nonprofits with Strong Authentication | Yubico

2020 continues to be a challenging year in many ways for all of us, but today, we’re proud to share some hopeful news — Yubico is introducing the Yubico for Free Speech Program, an initiative designed to defend digital privacy, online security, and free speech for at-risk individuals and nonprofit organizations. 

As of July 1, 2020, Yubico has committed to donate one YubiKey for every 20 YubiKeys purchased on yubico.com. Using these keys, we will equip nonprofit organizations, and the populations they serve, with the power of hardware-backed security — free of cost. Our goal is to enable these organizations to safely continue their important work of serving, empowering, and protecting vulnerable populations most at risk of targeted cyber attacks. 

Enabling YubiKey protection for at-risk individuals

For years, Yubico has worked with nonprofit organizations like Freedom of the Press, ISC Project, Electronic Frontier Foundation, Defending Digital Campaigns, and the Human Rights Foundation. With the Yubico for Free Speech Program and Yubico’s new donation initiative, we have formalized this work to reach a wider range of organizations that align with our shared desire of upholding and protecting free speech, including: 

• Non-profit organizations that protect journalists, freelancers, and writers from doxing and other targeted attacks in an effort to uphold transparent, fair, and ethical reporting.
  
• Human rights organizations and activist groups focused on ending racism, sexism, LGBTQ violence, domestic abuse, and other social justice issues around the world. 
• Bi-partisan networks that fight to preserve democratic integrity by securing political campaigns, political candidates, and election processes.

Why free speech matters to Yubico 

Free speech is an important human right, and one that aligns closely with Yubico’s greater mission: to make the internet safer for everyone. We believe that free speech and free press play a critical role in exposing injustice and inequality, and we also know that free speech is under attack in many ways and for many groups of people. Coercive force, disinformation, doxxing, and cyber attacks are used across the globe each and every day to silence voices that matter. 

We believe that freedom of speech must not only be protected, but also exercised — at home, at work, in the streets, and online. This is the path to educating ourselves and others, while evolving as a society.

Join the cause 

If you are with a nonprofit organization that values free speech and defending human rights and you are interested in protecting yourself or others online, apply to join our Yubico for Free Speech Program here. 

Please also join us in helping this program grow! Here’s what you can do: 

• Purchase any of our products from yubico.com to contribute to the amount of YubiKeys we are able to donate, or
• Share your favorite nonprofits with us if you believe they could benefit from strong authentication and would be a fit for this program. 

We thank you for your support!

By Ronnie Manning at 2020-08-25 19:00:19 Source Yubico:

Behind the iPhone 5 and 5c Passcode Cracking

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.

By Vladimir Katalov at 2020-08-25 09:59:14 Source ElcomSoft blog:

iPhone 5 and 5c Passcode Unlock with iOS Forensic Toolkit

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.

1. A compatible iPhone model. Supported devices include the iPhone 5 (A1428, A1429, A1442) and iPhone 5c (A1456, A1507, A1516, A1526, A1529, A1532) models.
2. A desktop or laptop computer with macOS 10.12 (Sierra) through 10.15 (Catalina).
3. 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.
4. 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:

1. Download Elcomsoft iOS Forensic Toolkit. Insert the USB dongle.
2. 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.
3. 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

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.

By Oleg Afonin at 2020-08-25 09:56:23 Source ElcomSoft blog:

Breaking LUKS Encryption

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.

1. Extract the encryption metadata from the encrypted device or disk image using Elcomsoft Forensic Disk Decryptor or Elcomsoft System Recovery.
2. Use the extracted metadata (a small file) to launch an attack on the password with Elcomsoft Distributed Password Recovery.
3. 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.

1. Download Elcomsoft System Recovery, launch the installer and create a bootable USB drive.
2. Use the USB drive to boot the target system into the Windows PE environment.
3. Elcomsoft System Recovery will be launched automatically.v
4. Review the attached disks.
5. Select LUKS-encrypted partitions and click “Dump” to extract the encryption metadata.
6. 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.

1. Launch Elcomsoft Forensic Disk Decryptor.
2. Select operation mode “Extract/prepare data for further password recovery”.
3. Open the physical device or disk image containing LUKS volume(s). In the example below, we’re dealing with a physical device.
4. EFDD will display the list of encrypted volumes. Select the volume you are about to extract encryption metadata from.
5. 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.

1. Launch Elcomsoft Distributed Password Recovery.
2. Open the file containing the encryption metadata that you obtained with Elcomsoft Forensic Disk Decryptor during the previous step.
3. The available key slots along with the number of hash iterations will be displayed. Specify the key slot to attack.
4. 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.

By Oleg Afonin at 2020-08-18 09:55:15 Source ElcomSoft blog:

Exploring clientDataJSON in WebAuthn

Calling all developers! Today, we’re kicking off our first-ever post in our new technical blog series specifically designed for our developer community. Each month, we will be selecting a new technical topic to cover in more depth.

To start our series, we dive into the clientDataJSON object as part of the Web Authentication or WebAuthn specification. WebAuthn is an exciting standard that has garnered a lot of interest, but it can often feel complicated to get started. 

WebAuthn defines a client/server ceremony API performing user registration and authentication. For registration, the user, via a client (web browser or mobile app), requests to register a hardware authenticator with a server. For authentication, that user, via a client app, attempts to login to a server with that previously registered authenticator. During these two ceremonies, there’s data passed back and forth between the client and the server. 

The clientDataJSON object is key to the WebAuthn API data exchange. If you are building a desktop or mobile application, the building and encoding of the clientDataJSON object needs to be done using a library or SDK.

First, let’s go over the high-level aspects of WebAuthn and then we can dive into details about what the clientDataJSON object is, its purpose and its attributes, and finally explain encoding and decoding of this object.

What is WebAuthn?

Web Authentication, or WebAuthn, is a W3C-recommended specification that defines an API for enabling the creation and use of public key-based credentials, for the purpose of strongly authenticating users. See the W3C Specification for more information.

The idea behind WebAuthn is to rid the world of password authentication (something you know) by replacing it with public key authentication (something you have). 

For password authentication, a user generates a password which is passed to the server, where it is stored in a database. During user authentication, the user-generated password is sent to the server for validation against the stored password. If the password matches, the user is authenticated and can access the service offerings or features.

For WebAuthn public key authentication, strong hardware-backed public/private-key credentials are created and stored by an authenticator, such as a YubiKey, during registration. The private key is securely stored on the authenticator and is never shared, while the server stores the public key portion in the database.

During user authentication, the server sends pseudo randomly generated challenges to the client for the authenticator to sign. The signature, which takes a hash of the clientDataJSON along with the authenticatorData, is signed over by the private key. This signature proves possession of the private key and assurance that the challenge, relying party (RP) ID, and origin were not tampered with, all without ever sharing the private key or requiring the user to provide a static password. Replay attacks are prevented by the pseudo-randomness of the challenge.  Phishing attacks are prevented by this signing of the challenge with the private key that is scoped to the RP ID (domain). In addition to measures to counter replay and phishing attacks, the web authentication API also prevents compromised credentials (username + password) in that a password is never passed to or stored by the RP, hence the term “passwordless”.

What is clientDataJSON?

At a high level, the WebAuthn specification is really just an exchange of challenges and responses performed during two types of ceremonies; registration and authentication. The clientDataJSON object, always populated by the client (browser or app), is sent in response to the RP server during registration and authentication. 

The object, populated by the client, has three required properties: a type, a challenge, and an origin. The type can be either “webauthn.create” for a registration response or “webauthn.get” for an authentication response. The challenge value is the actual challenge that was sent by the RP during the create or get ceremony. The origin contains the effective domain name of the endpoint to which the client is connecting during the WebAuthn registration or authentication. 

Now that we know about the properties, let’s find out the purpose of each property and how these are integrated to control the Web Authentication flow.

clientDataJSON Use Cases 

The clientDataJSON is used to determine the current state or flow of the WebAuthn ceremony. The type attribute tells the RP whether this client data is a registration or authentication response to a server challenge. 

The most important responsibility of the clientDataJSON is storing the effective domain of the connected client. In the WebAuthn API spec, the client browser or application is responsible for capturing the effective domain of the connected endpoint and storing it in the origin attribute during the registration (create) and authentication (get) ceremony. The public keypair generated by the authenticator is considered to be “origin-based”, which means the keypair can only be used to authenticate a user when the client is connected to the same domain (origin) endpoint to which it was originally connected (or matches a subset of the server domain) at the time when the keypair was generated. I’ll go into this in more detail later.

The last responsibility of the clientDataJSON is to capture the cryptographic challenge sent by the RP during registration or authentication. The challenge is randomly generated by the RP and sent to the client during a challenge. The client captures the challenge in the challenge attribute and passes this back to the server.

clientDataJSON Properties

The clientDataJSON object (after decoding) has the following properties:

Property	Definition	Required/Optional
type	Contains a string with one of two values: Required Value(s): “webauthn.create” or “webauthn.get“ “webauthn.create” → A new credential is being created during REGISTRATION. “webauthn.get” → An existing credential is retrieved during AUTHENTICATION	Required
challenge	The base64url encoded version of the cryptographic challenge sent from the relying party’s server (RP). The original challenge value is passed via the relying party (RP) through PublicKeyCredentialRequestOptions.challenge or PublicKeyCredentialCreationOptions.challenge.	Required
origin	The effective domain of the requester given by the client/browser to the authenticator.	Required

Encoding and Decoding clientDataJSON Properties

With only three main attributes, the clientDataJSON object is pretty straightforward; however, according to the W3C spec, the JSON string is converted into an ArrayBuffer before being transported back to the RP and then back to a string on the server side before validation. The ArrayBuffer is being used for efficiency and optimal performance when speaking binary to the authenticators.

The conversion to and from an ArrayBuffer is the most confusing for developers. The good news is, for most WebAuthn solutions, developers can rely on a Web Authentication API supporting web browser as the client to handle the interaction with the external authenticator. Those browsers have already implemented the client API requirements using the FIDO2 Client to Authenticator Protocol (CTAP) specification. CTAP is an application layer protocol used for communication between a client (browser) or a platform (operating system) with an external authenticator such as the YubiKey. 

If you are building a mobile, desktop, or IoT application without the use of a browser, you will need to implement the CTAP Authenticator API using a library, or a mobile SDK for iOS or Android.

On the server side, the RP receives the object as an ArrayBuffer and must be decoded and parsed. 

Here’s what the hashed clientDataJSON object within the client response looks like when received by the relying party during registration:

 

Here’s what the parsed clientDataJSON object looks as a JSON string:

 

In the examples below, the server converts the ByteArray to a JSON object and then parses and validates the data.

Here’s a Java example of how the Yubico Java Server demo handles the clientDataJSON:

 

Here’s a JavaScript example from the Firefox developer guide:

 

Relying Party Validation of WebAuthn clientDataJSON 

Once the RP receives the registration or authentication response from the client and converts the ByteArray to a JSON object, it’s ready to parse and validate the three attributes. At this point, the server can validate any of the attributes in any order. 

The origin value is the most important validation. The client browser or app determined the endpoint/domain during the request for authentication to the server. The server must then validate that the “origin” string matches at least a subset of the valid domain string of the RP as part of the Relying Party Identifier (RP ID). 

Conclusion

The clientDataJSON consists of only three required attributes but plays a critical role in the Web Authentication flow between the client and server. In this post we learned that this object is populated by the client during the registration and authentication flows in order to determine the type of ceremony (registration or authentication), the origin of the connected client, and the current challenge from the server. The data is transported as an ArrayBuffer by the client and then decoded and parsed by the server. The RP can reject any authentication attempts if the client object is not encoded properly, contains an incorrect challenge, or the client origin does not match the domain (RP identifier) associated with the JSON string.

Building and encoding the clientDataJSON object is the client responsibility, but that work is typically handled for you by a web browser that supports Web Authentication. However, if you are building a desktop or mobile application, that work will need to be done using a library or SDK of your choice following the Web Authentication API structure as defined by the W3C spec.

Resources

Yubico WebAuthn Developer Guide
W3C WebAuthn Spec
Mozilla MDN Web Docs
Yubico iOS SDK – WebAuthn Client
Github WebAuthn API wrapper – WebAuthn API wrapper that translates to/from pure JSON using base64url 
Yubico WebAuthn Server (Java)

By Dennis Hills at 2020-08-11 19:00:12 Source Yubico: