Archive for March, 2020

VeraCrypt is a de-facto successor to TrueCrypt, one of the most popular cryptographic tools for full-disk encryption of internal and external storage devices. Compared to TrueCrypt, which it effectively replaced, VeraCrypt employs a newer and more secure format for encrypted containers, and significantly expands the number of supported encryption algorithms and hash functions. Learn how to break VeraCrypt containers with distributed password attacks.

VeraCrypt Encryption

Full-disk encryption tools rely on symmetric cryptography to encrypt data, and employ one-way transformations (hash functions) to protect the binary data encryption key with the user’s password. When attacking an encrypted container, the expert must either know the exact combination of the cipher and hash function, or try all of their possible combinations. If the expert makes the wrong choice of a hash function or cipher, the data will not be decrypted even if the correct password is known.

During the times TrueCrypt ruled the world of third-party full-disk encryption tools, users were presented with the choice of three individual encryption algorithms (AES, Serpent, and Twofish). In addition, five combinations of cascaded algorithms (AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES and Twofish-Serpent) were available, making the total of eight possible combinations. Passwords could be protected with one of the three supported hash functions (RIPEMD-160, SHA-512, or Whirlpool).

VeraCrypt offers the choice of some fifteen combinations of individual encryption algorithms and their cascaded combinations. Five different hash functions are supported, making it 15×5=75 possible combinations of symmetric ciphers and one-way hash functions to try. If you don’t know exactly which cipher and which hash function has been used to encrypt the container, you’ll have to try all of the 75 combinations during the attack.

VeraCrypt symmetric encryption algorithms

While Microsoft BitLocker and Apple FileVault 2 rely exclusively on AES encryption, it is common for third-party crypto containers to support more than one cipher. VeraCrypt in particular offers the choice of a number of symmetric encryption algorithms including AES, Serpent, Twofish, Camellia, and Kuznyechik. Additionally, ten different combinations of cascaded algorithms are available: AES–Twofish, AES–Twofish–Serpent, Camellia–Kuznyechik, Camellia–Serpent, Kuznyechik–AES, Kuznyechik–Serpent–Camellia, Kuznyechik–Twofish, Serpent–AES, Serpent–Twofish–AES, and Twofish–Serpent. Stacked encryption options are often considered the “safe side” of the matter.

In reality, neither the alternative ciphers nor stacked encryption offer tangible benefits over AES-256 encryption other than “not being the default”. If a container is encrypted with a cipher different from the default AES encryption, you’ll have to guess the correct encryption algorithm in addition to finding the password. Elcomsoft Distributed Password Recovery allows specifying the encryption algorithm(s) when setting up an attack.

VeraCrypt hash functions

When VeraCrypt encrypts or decrypts the data, it is using a perfectly random, high-entropy encryption key to perform symmetric cryptographic operations. This key is called a Media Encryption Key (MEK) or Data Encryption Key (DEK). The MEK is exactly the key one may be able to extract from the computer’s RAM dumps, hibernation and page files. If you are able to extract the MEK, you can fast forward to decrypting the data without running attacks on the user’s password. More about extracting media encryption keys and instantly decrypting VeraCrypt containers in our blog:

If the binary Media Encryption Key is not available, you’ll have to recover that key in order to decrypt the data. VeraCrypt stores the MEK alongside with the encrypted data. The Media Encryption Key is encrypted with a Key Encryption Key (KEK), which, in turn, is the result of multiple (hundreds of thousands) iterative one-way hashing operations performed on the user’s password. By default, VeraCrypt uses 500,000 rounds of hashing to ‘wrap’ the KEK. VeraCrypt supports four hash functions including SHA-512, Whirlpool, SHA-256 and Streebog.

In other words, when the user types their password, VeraCrypt performs 500,000 rounds of hashing with one of the four supported hash functions to calculate the KEK. The number of rounds is set to a deliberately high value in order to slow down brute-force attacks. A single Intel i7-9700K CPU delivers the following performance:

When running an attack on the user’s password, calculating the correct Key Encryption Key would not be possible without knowing which hash function exactly was used to produce the key. VeraCrypt offers the choice of SHA-512 (default), Whirlpool, SHA-256 and Streebog hash functions.

Using Elcomsoft Distributed Password Recovery to break VeraCrypt passwords

While VeraCrypt does protect its encrypted containers against brute-forcing the password, we have significant advances in password recovery attacks compared to what we had some ten years back. 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.

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:

If a non-standard hash function was selected, the attack will be slowed down significantly even with GPU acceleration. A single video card (e.g. NVIDIA GTX 1080) can process about 170 passwords per second with VeraCrypt default settings (AES encryption, SHA-512):

However, a non-standard combination of symmetric cipher and hash function (e.g. AES + Whirlpool, or Serpent + SHA-256) requires trying all possible combination of ciphers and hash functions. This will be significantly slower; about one password per second on the same computer equipped with a single video card:

How fast, exactly?

VeraCrypt is well-prepared to withstand brute-force attacks. By default, some 500,000 rounds of user-selected hash function are performed to calculate the KEK (Key Encryption Key). Some hash functions are faster than others, and some are extremely slow. The choice of the hash function greatly affects the speed of the attack. However, there is one thing that affects the speed even more than the choice of a hash function: it’s whether you know exactly which combination of encryption and hashing was used.

Remember, VeraCrypt offers the choice of 15 encryption methods (single encryption algorithms and cascaded encryption) and 4 hash functions. If you don’t know exactly which combination of hash+encryption was used to protect the encrypted container, you will have several strategies:

  • Try the default AES+SHA-512 attack
  • Try guessing the right combination (it rarely works), or
  • Try all possible combinations (slow but comprehensive)

With the majority of users taking the default route, it may be worth it to first try an attack with the default settings (AES encryption, SHA-512 hash). If that attack fails, it would make sense trying all possible combinations of encryption and hashing. Note, however, that trying all possible combinations is about 175 times slower compared to attacking a single combination of AES+SHA-512.

One thing that does not affect the speed of the attack is the user’s choice of encryption. Whether they choose to encrypt with AES, Serpent, Twofish or any other single algorithm, the speed of the attack will remain the same. Attacks on cascaded encryption with two algorithms (e.g. AES(Twofish)) work at half the speed, while cascading three algorithms slows them down to around 1/3 the speed.

Alternative attacks

Combining the use of multiple computers and cloud instances equipped with multiple GPU units may increase the recovery speeds significantly. Yet, even these higher speeds may not be enough when attacking containers protected with long, complex and non-reusable passwords. In such cases, alternative attacks may deliver better results.

The most commonly used alternative targets the on-the-fly encryption key (OTFE), or Media Encryption Key. This is the binary, symmetrical key VeraCrypt uses to encrypt and decrypt data it writes to or reads from the encrypted volume. Gaining access to the OTFE key allows decrypting the data directly without knowing or needing the password.

There is more than one way to access OTFE keys. While the encrypted volume is mounted, the encryption key is available in all of the following locations:

  1. The computer’s volatile memory (RAM). VeraCrypt needs the OTFE key in order to read and write data stored in the encrypted volume, so the encryption key is always stored in the RAM.
  2. Page file(s). While the OTFE key may or may not land in the page file, scanning the page file(s) takes minutes or several hours of time (compared to days and weeks of brute-forcing the password).
  3. Hibernation file. Windows uses a hibernation file to dump parts of the computer’s RAM onto the hard disk when the computer sleeps (if Hybrid sleep is enabled, which it is by default); when the computer hibernates (which is disabled by default); and when the computer shuts down (when Fast startup is enabled, which is enabled by default). The hibernation file can be only scanned if the boot volume is not encrypted or can be unlocked.

This is how the extraction works with Elcomsoft Forensic Disk Decryptor:

The time required to locate the OTFE keys depends largely on the amount of RAM installed in the user’s computer, and the speed of the expert’s PC. It also depends on the encryption settings. Selecting a non-standard combination of an encryption algorithm and hash function (e.g. AES+SHA-256 or AES+Whirlpool) will require trying all possible combinations instead of using the single default setting (AES+SHA-512), which takes extra time. In our experience, scanning a 16 GB memory dump can take 15 to 30 minutes with default settings and up to several hours with a non-standard combination of encryption and hash.

ASUSTOR advertises secure AES encryption with a 256-bit key. According to the manufacturer, AES-256 encryption is made available through the entire range of its current NAS devices. Unlike other manufacturers, ASUSTOR is very upfront regarding the type of encryption employed by its NAS devices: “ASUSTOR NAS offers folder based military grade AES 256-bit encryption”. As a result, we’re once again dealing with folder-based encryption running on top of the open-source encrypting file system eCryptfs. We’ve already seen eCryptfs-based encryption in attached storage devices made by Synology and TerraMaster. Does ASUSTOR have any surprises, or will its implementation of folder-based encryption suffer from the many restrictions and limitations? Let’s find out.

Abstract and Summary

ASUSTOR was established as a subsidiary of ASUS, a Taiwanese manufacturer of electronics and computer peripherals. The ASUSTOR name is a combination of “ASUS” and “Storage”. As the name suggests, ASUSTOR manufactures a range of attached storage devices based on ARM64 and Intel processors. ASUSTOR devices run ADM, which in turn is based on the Linux OS.

ASUSTOR implements folder-based AES encryption with a 256-bit key length. The encryption key is produced based on the user-provided password. Users cannot change the encryption key. They are not allowed to change or revoke compromised passwords either. An encryption key file is produced and saved while setting up an encrypted folder. Users can unlock encrypted volumes by either typing the original plain-text password or by uploading the exported encryption key through the ADM user interface. There is no reference to SED (Self Encrypting Drive) support anywhere in the ADM GUI or the official documentation; as a result, we have to conclude that no SED support is available in ASUSTOR consumer NAS models.

ASUSTOR offers sufficient documentation that details the limitations and restrictions of folder-based encryption, and provides several relevant user guides. The company does not attempt to hide or obscure the relevant technical details.

Encrypting existing data: supported. Users can encrypt existing shares containing data.

Decrypting encrypted folders: supported. Users can decrypt encrypted shares.

Revoking compromised keys or changing leaked passwords: not supported. If an encryption key is compromised, users must take the quest of decrypting and re-encrypting the data, which may take many hours or even days.

Encryption key: plain-text password or key file (must be manually exported while the encrypted share is mounted and unlocked).

The original password is used as a Media Encryption Key. The concept of Key Encryption Keys is never utilized here; as a result, users cannot change their encryption password (aside of fully decrypting and re-encrypting the share).

Test Bench

We analyzed an ASUSTOR AS6302T device equipped with an Intel Celeron J3355 Dual-Core CPU and 2GB of RAM. A pair of non-SED WD Red HDD have used to set up the NAS perform the analysis. The NAS was running on the latest version of ADM available at the time of testing.

ASUSTOR NAS: eCryptfs Folder-Based Encryption

ASUSTOR utilizes folder-based encryption based on eCryptfs, an open-source stacked cryptographic file system. Detailed information on eCryptfs is available here. This is the same encryption scheme as used in consumer Synology NAS devices; as a result, ASUSTOR NAS devices have many of the same limitations as Synology devices. Namely, the length of encrypted file names is restricted to 143 Latin characters; storing files with longer file names is not permitted. Using Asian characters makes the possible file names even shorter. Once the encrypted share is created, users cannot change the encryption passphrase.

One limitation that ASUSTOR devices do not have compared to Synology NAS is the ability to use NFS mount for encrypted folders. While Synology explicitly rules out NFS support for encrypted shares, ASUSTOR only has this information in the Knowledge Base: “The encrypted share folder can not be mounted by NFS ( ADM 2.4 or later). The encrypted shared folder used by ADM 2.4 (or later) is eCryptfs, so the NFS mount will not support for encrypted share folder.”

Encrypting

Users can encrypt newly created shares as well as existing shares that already contain data. Folder-based encryption allows users creating multiple shares, each with its own unique password. If there are multiple users, each user can encrypt their home folder with their own password. However, the inability to change the encryption password or to revoke compromised encryption keys makes this approach dubious in the grand scheme of things.

Creating an encrypted share

This is how an encrypted share is created.

Once the user ticks the “Encrypt this shared folder” box, ADM displays a warning message that lists the limitations and restrictions of encrypted shares.

The encryption password may contain 8 to 64 characters.

Users can optionally mount the encrypted folder during startup; this setting can be changed at a later date (which is not a given on some other NAS devices we have tested). If this setting is selected, the encryption key will be stored on the device, which automatically renders any and all protection null and void.

The usual access permissions are configured.

Once created, the encrypted folder is mounted automatically.

Exporting the encryption key

The 32-byte (256-bit) encryption key is automatically exported into a .key file once the user encrypts the folder.

Mounting encrypted shares

The encrypted volumes can be mounted manually or automatically. The “Auto-mount at system startup” setting can be changed at any time by editing the encryption settings.

Mounting encrypted shares through the user interface supports the following two options.

  1. Mounting with the original plain-text password.
  2. Mounting with the exported key file.

Unmounting encrypted shares

Encrypted shares are unmounted automatically once the NAS is powered off or rebooted. Manually unmounting the encrypted share requires accessing the Web UI:

Permanent decryption

ASUSTOR does not utilize the concept of separate Media Encryption and Key Encryption keys. As a result, users cannot change the password or revoke compromised encryption key. In order to do that, users must physically decrypt the entire set of data and re-encrypt it with another password. At very least, ASUSTOR does support the decryption of encrypted shares:

Changing the password: impossible

Decades ago, manufacturers came up with a brilliant idea of separating the binary encryption keys that are used to encrypt and decrypt the data, and secrets that are used to unlock the encryption keys. This wonderful concept allows many things such as using any one of the several different passwords (or multiple types of authentication credentials, such as a smart card or a password) to unlock encrypted volumes. Sadly, this concept is rarely used by NAS manufacturers. ASUSTOR is no exception; users cannot change the password because the password itself is the Media Encryption Key.

Automatically Mounting Encrypted Folders

If the user had specified that the encrypted volumes are to be mounted automatically, they will be decrypted when the NAS starts up. You may reset the root password in /etc/shadow to gain access to the content of the NAS.

Manually Decrypting Encrypted Shares

Since ASUSTOR utilizes eCryptfs, accessing encrypted folders from another computer is easily available. Please refer to our Synology and TerraMaster guides for detailed instructions and the list of commands.

ADM keeps encrypted files in folders using the following naming convention:

/volume1/.@encdir/Test

“Test” would be the name of the encrypted share. The encrypted share is mounted as /share/Test

Encrypted share “Test” mounted:

root@Asustor:/volume1/.@encdir/Test # df -h
Filesystem              Size  Used Avail Use% Mounted on
rootfs                  874M   56M  819M   7% /
tmpfs                   914M   20K  914M   1% /tmp
/dev/md0                2.0G  384M  1.5G  21% /volume0
/dev/loop0              951K  9.0K  922K   1% /share
/dev/md1                5.5T  495M  5.5T   1% /volume1
/volume1/.@encdir/Test  5.5T  495M  5.5T   1% /share/Test

Encrypted share unmounted:

root@Asustor:/volume1/.@encdir/Test # df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          874M   56M  819M   7% /
tmpfs           914M   20K  914M   1% /tmp
/dev/md0        2.0G  384M  1.5G  21% /volume0
/dev/loop0      951K  8.0K  923K   1% /share
/dev/md1        5.5T  495M  5.5T   1% /volume1

The encrypted folder was mounted with the following parameters:

/volume1/.@encdir/Test on /volume1/Test type ecryptfs (rw,relatime,ecryptfs_fnek_sig=704b798b4658aa6a,ecryptfs_sig=704b798b4658aa6a,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)
/volume1/.@encdir/Test on /share/Test type ecryptfs (rw,relatime,ecryptfs_fnek_sig=704b798b4658aa6a,ecryptfs_sig=704b798b4658aa6a,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)

To mount the encrypted share, execute the following commands.

Insert the passphrase into the keyring (you will need to provide the encryption passphrase):

ecryptfs-add-passphrase –fnek

Create a folder where you’ll be mounting the encrypted file system to:

mkdir /volume1/Test

Mount the encrypted folder in interactive mode:

mount.ecryptfs /volume1/.@encdir/Test /volume1/Test

While mounting, specify cipher: “aes”, key bytes: “32”, plaintext passthrough: n, filename encryption: y. Confirm filename encryption key by pressing “Enter”.

What Risks Are Covered by ASUSTOR Security Model

Similar to other implementations of NAS encryption, the security model employed by the ASUSTOR is stripped down to the bare essentials. I have the following remarks about the ADM security model.

  1. The possibility to store the encryption key on-device if the user enables the automatic mount option completely negates the protection of folder-based encryption. The lack of SED or full volume encryption makes gaining access to the NAS easy.
  2. This encryption model does not properly protect the data if one needs to send it out for repair/replacement or simply wants to sell the disk. The encryption metadata is duplicated in every file in the encrypted folder. As a result, the attacker can obtain a single file and run a (fast) attack on the encryption key.
  3. Unlike volume encryption schemes, folder-based encryption with encryption metadata duplicated in every file. “eCryptfs stores cryptographic metadata in the header of each file, so that encrypted files can be copied between hosts; the file will be decrypted with the proper key in the Linux kernel keyring.” (source) This makes secure erase of encrypted data impossible. To securely erase data encrypted with eCryptfs, one must either wipe (overwrite) encryption metadata in each and every encrypted file; wipe the full content of every file; or wipe the entire disk.
  4. Neither the encryption nor the password can be changed. Enough said.

Conclusion: ASUSTOR Folder Encryption

When it comes to attached storage encryption, we are still in the Stone Age. The lack of basic features, many of which we accept as a given, makes ASUSTOR encryption barely acceptable by modern standards. The functional restrictions and encryption metadata duplicated in every file makes this type of encryption hardly useful. ADM does not separate Media Encryption Keys and Key Encryption Keys, which makes password changes impossible. Security wise, the data would be impossible to decrypt without knowing (or breaking) the user’s encryption password (or, alternatively, without access to the exported encryption key).

Compared to Synology, ADM offers fewer options for storing and protecting the encryption keys. While Synology offers the ability to store the auto-mount encryption key on the device itself or on a USB drive (the latter using a separate passphrase to protect the key), ADM only offers the first way without any sort of additional protection.

At the same time, ADM encryption implementation is straightforward enough to appeal to some users. However, those same users may be put off by the need of re-entering their encryption password in the Web interface every time they power on or reboot the NAS. Should they opt to automatically mount encrypted shares on startup, they immediately sacrifice the protection.

We recently introduced a new acquisition method for iPhone and iPad devices. The fast, simple and safe extraction agent requires no jailbreak, and delivers the full file system image and the keychain. The latest release of Elcomsoft iOS Forensic Toolkit expanded this method to iOS 13 and filled the gaps in some versions of iOS 12 that were missing support (such as iOS 12.3 and 12.4.1). Finally, we now officially support the latest generation of iPhone devices including the iPhone 11, iPhone 11 and iPhone 11 Pro. The new compatibility matrix becomes significantly more diverse with this release, so bear with us to learn which iOS devices can be extracted without a jailbreak.

Compatibility

The extraction agent is supported on the following models and iOS versions:

  • iPhone 6s to iPhone X, iPad 5th and 6th gen, iPad Pro 1st and 2nd gen: iOS/iPadOS 11.0 – 13.3
  • iPhone Xr, Xs, Xs Max, iPad Mini 5, iPad Air 3rd gen, iPad Pro 3rd gen, iPod Touch 7th gen: iOS/iPadOS 12.0 – 13.3
  • iPhone 11, 11 Pro, 11 Pro Max: iOS 13.0 – 13.3

For some older models, compatibility remains unchanged. The following models are supported if running iOS 11-12.2 and iOS 12.4:

  • iPhone 5s, 6, 6 Plus
  • iPad Mini 2 and 3
  • iPad Air (1st gen)

There are two ‘iffy’ models: the iPad Mini 4 and iPad Air 2. While the agent-based extraction method will sure work on these models running iOS 11 through 12.2, we have not tested them with iOS 12.3, 12.4.1 or any version of iOS 13.

Requirements

Make sure that your device model and OS version are compatible, and register an Apple Developer account (here is why). Of course, you will need the latest version of iOS Forensic Toolkit, too. The software is really simple to use, but we still recommend to attend our trainings.

General advantages

The main advantage of this method is its wide compatibility with multiple iPhone and iPad models. In the future, we may add support for older iOS versions (to avoid all the troubles with jailbreaking, see below), and of course will do our best to add compatibility with newer versions (iOS 13.3.1 and up).

Next, the extraction agent is safe and reliable. Nothing wrong may happen; the worst is just a reboot of the device, or our method may simply not work on your device. See the Trobleshooting section below for some tips; sometimes it takes several tries (though usually it works from the first try).

Forensically sound? It depends on what you mean by that. Here is a good definition:

Digital evidence is said to be forensically sound if it was collected, analyzed, handled and stored in a manner that is acceptable by the law, and there is reasonable evidence to prove so. Forensic soundness gives reasonable assurance that digital evidence was not corrupted or destroyed during investigative processes whether on purpose or by accident.

(another good source: When is Digital Evidence Forensically Sound?)

For 64-bit iPhones (starting with the iPhone 5s), there is NO method of data acquisition that does not make ANY changes to the system, despite what other vendors say. Some traces are always left, like records in some system logs.

Next, the extraction speed. Instead of re-using ssh, we transfer the data directly over the USB. This method is more reliable and significantly faster; on modern iPhone models, the speed is about 2.5 GB/min.

Finally, the simplicity. No, it is still far from the proverbial “one button” solution, which simply does not exist in the area. Still, we did our best to make acquisition as simple and straightforward as possible, and we are still improving it. Just follow the software manual carefully, and make sure you read the articles published in our blog.

Last but not least. The agent extracts not only the full file system but also the complete keychain. While you can also extract the keychain from iTunes-style-backups, it won’t be complete as a lot of records cannot be decrypted. Use Elcomsoft Phone Breaker to view all the keychain records:

Advantages over jailbreaking

One can also perform full file system acquisition even for latest iPhone models with iOS 13 through jailbreaking. But there are some things you should know.

Jailbreaking is not completely safe. It may brick the device or put it into a boot loop, and it also makes multiple changes to the device file system, even with the rootless jailbreak.

Are there any disadvantages of agent-based extraction? Not a single one, at least for iOS 11.0 to 13.3. Except checkra1n (see below).

One more thing. With iOS 13, some files and folders have improved security attributes and are not accessible by tar over ssh. There is no such problem with agent-based acquisition.

We even made our method compatible with intermediate beta versions of iOS (in the 11-13.3 range) where jailbreaks do not work at all.

Advantages over checkm8 extraction

checkm8-based acquisition is pretty nice, but the devil is in the detail.

First, checkm8 is compatible with a limited number of devices and iOS versions: iPhone 5s to iPhone X, and iOS from 12.3. So forget about the iPhone Xr, Xs, 11 and 11 Pro (as well as many iPads); they are not vulnerable to this exploit. Also, despite the fact that the exploit is hardware-based, the checkra1n jailbreak (and all current checkm8-based acquisition processes) are NOT compatible with iOS 12.2 and below.

Second, the checkra1n jailbreak is not 100% reliable. There are so many compatible devices it does not work on, and the same about direct checkm8 implementation. If there is an error, you’re stuck with it; moreover, you can even ‘brick’ the device with it (it really happened to couple of our test devices). How about the speed? Amazingly low, thanks to ssh and some other things. Some extractions cannot complete in a week, we have no idea why.

The only two real advantages of checkra1n/checkm8 are: they do not require an Apple Developer account, and they allow BFU (Before First Unlock) extractions for devices with an unknown passcode. Also, checkra1n supports iOS 13.3.1 (the latest version at the time of writing this article, though 13.4 is expected very soon). You can use still checkra1n with our iOS Forensic Toolkit to get partial file system and keychain extraction of locked and even desiabled devices.

Usage & troubleshooting

Make sure you have read the iOS Forensic Toolkit manual first, as well as the following two articles:

We described all the steps at iPhone Acquisition Without a Jailbreak (iOS 11 and 12):

  • Put the device into airplane mode (this is mandatory!) and connect it to the computer with EIFT. Make sure that Wi-Fi and Bluetooth are disabled from iOS settings (and not from from the Control Centre)
  • Establish trust relationship (otherwise you will get the “ERROR: Could not connect to lockdownd, error code -2” message in the EIFT)
  • Install the extraction agent though EIFT. You will need to enter Apple ID and app-specific password of the developer’s account, followed by the TeamID; please note that signing the agent requires an internet connection on your computer (but NOT on the iOS device, which should remain offline at all times).
  • Once the agent is installed, it is recommended to disable all Internet connections on the computer you perform the acquisition on.
  • Tun the Agent on the device and leave it running in the foreground.
  • Acquire the keychain and capture the file system; during keychain acquisition, you will have to enter the passcode on the device (sometimes twice), or unlock using Touch ID or Face ID (for devices with Face ID, you will first receive the prompt whether you allow Agent to use it for keychain access)
  • Uninstall the agent.

If something goes wrong when you run the extraction agent on the device (e.g. “Can’t connect to device on specified port” message in EIFT), you may need to reboot the device; make sure to wait for at least one minute after rebooting before starting an agent.


Quick tip: if you do not want to enter Apple ID, password and Team ID when installing the Agent on every new device, you can set them up right in the EIFT script (Windows: Toolkit.cmd, lines 20-22; macOS: macosx/Toolkit.sh, lines 42-44):

AGENT_ID=john.doe@gmail.com
AGENT_PASSWORD=abcd-efgh-ijkl-mnop
AGENT_TEAMID=XXXXXXXXXX

Where AGENT_ID is the Apple ID enrolled into Apple Developer Program; AGENT_PASSWORD is app-specific password you should generate on your account, and AGENT_TEAMID is the Team ID (you can easily find it by logging in to Apple’s Developer Center, under Membership Information in Account | Membership).

Modern wireless networks are securely protected with WPA/WPA2. The most frequently used method of securing access to a wireless network is pre-shared passphrase, or, simply put, a text password. The WPA standard enforces the minimum length of 8 characters for all Wi-Fi passwords. Considering the relatively low performance of WPA/WPA2 password attacks, brute force attacks are rarely effective even when performed with a network of GPU-accelerated computers. In this article, I will show how to attack wireless passwords for the purpose of security audit.

Pre-Requisites

First and foremost, you’ll need a WPA/WPA2 handshake dump. This dump is essentially a file you’ll be using in the password recovery app when attacking Wi-Fi passwords. In order to capture the WPA/WPA2 handshake, use the built-in Wi-Fi sniffer in Elcomsoft Wireless Security Auditor.

The traditional approach to capturing a WPA/WPA2 handshake was using a dedicated AirPCap wireless adapter and specialized software. Elcomsoft Wireless Security Auditor takes AirPCap out of the equation, delivering a software-based Wi-Fi sniffing solution that works on regular Wi-Fi adapters. The custom NDIS driver for 32-bit and 64-bit Windows systems is digitally signed by Microsoft, and can be installed on all compatible versions of Windows including the latest builds of Windows 10. With this tool, you can automatically intercept Wi-Fi traffic and launch an attack on selected Wi-Fi networks.

Note: you must install a WinPCap driver to enable Wi-Fi sniffing. A compatible WinPCap driver is provided with Elcomsoft Wireless Security Auditor.

Please refer to Elcomsoft Wireless Security Auditor manual for information on installing WinPCap and NDIS drivers and capturing a WPA/WPA2 handshake.

You can attack passwords within Elcomsoft Wireless Security Auditor for GPU-accelerated recovery, or Elcomsoft Distributed Password Recovery, which can use multiple computers and multiple GPU units to accelerate attacks.

The Attacks

The WPA/WPA2 always consists of at least 8 characters. Even if the password is exactly 8 characters long, can you break it using a brute-force attack? Let’s calculate!

An 8-character password that contains characters from the extended character set (small and capital letters, number and special characters) has 6,634,204,312,890,625 possible combinations. A single NVIDIA Tesla V100 can try as many as about 650,000 WPA/WPA2 passwords per second.

As a result, you’ll need an estimated 323 years to break that password using a single Tesla V100 board. Granted, you can cut this number by utilizing a thousand computers, each with eight V100 boards, and get a much more reasonable estimate, but why would anyone spend that much effort breaking a Wi-Fi network protected with just an 8-character password?

A smarter attack won’t cost you anything, but may result in significantly higher success rate in significantly less time.

Try Phone Numbers First

If you are not auditing a Pentagon network, a good starting point will be the list of local phone numbers. While passwords like these are relatively uncommon, we’ve still seen them in 1 to 3% of the cases. Considering the very short duration of this attack, the list of local phone numbers is totally worth checking.

All-Digit Passwords

A good number of Wi-Fi access points are protected with passwords consisting of exactly 8 digits. While this attack takes longer than trying the list of local phone numbers, it may be worth running depending on your computational resources. A single video card will crunch through these all-digit passwords in under three minutes, making it worth a try.

Targeting the Human Factor

Wi-Fi passwords are meant to be shared and used by a number of people. More often than not, these passwords are made to be easy to memorize and easy to type, especially on mobile devices. As a result, many passwords are based on combinations of one to three dictionary words, some numbers, and very few special characters. In other words, we recommend using automatically adjusted dictionary attacks when auditing Wi-Fi passwords. If a wireless network can withstand a GPU-assisted dictionary attack with mutations during a given timeframe, one can consider the network to be secure.

Leaked passwords

Every year, millions of user accounts are compromised, and millions of passwords are leaked. We strongly recommend obtaining the list of the most commonly used passwords such as the Top 10,000 passwords or Top 10 million passwords, and run a simple, straightforward attack through the dictionary of leaked passwords.

The dictionaries of the most common passwords can be obtained from GitHub.

Dictionaries

Wi-Fi passwords frequently contain one or more words in natural language. You can often recover such passwords by running a dictionary attack. A dictionary attack against a Wi-Fi password requires one or several dictionaries; a dictionary of English words is a good starting point, but dictionaries of local languages should not be forgotten.

Mutations

Users frequently attempt to “secure” a password using a well-known word and applying some modifications. Sometimes, the among of modifications is just enough to pass the enforced security policy. For example: JohnSmith1, J0hnSm1th, Eva-1980, Peter1$ and so on.

To help attacks target passwords selected by average users, we developed an automated mutations engine. The mutations engine automatically alters dictionary words to mimic common patterns. You can easily apply mutations to dictionary words. More time is required when more mutations or higher mutation level are selected.

Elcomsoft Wireless Security Auditor offers a dozen different mutations. Enabling all of these mutations at the same time enormously expands the number of passwords to try, making it difficult or impossible to reach the end of the list in reasonable time. For this reason, we strongly recommend using a reasonable number of mutations and choosing only those mutations that are likely to be used in a given case.

In real life, we’ve witnessed the following three mutations being the most popular:

Case mutation: different variations of uppercase and lowercase characters.

Digit mutation: one or more digits added to the beginning or at the end of the password.

Year mutation: a four-digit year appended to the end of the password.

You can read more about mutations in the Attack Settings and Dictionary Mutations sections of the manual.

Masks

Some organizations have strict password security policies requiring the use of a certain number of small characters, capital letters, numbers and special characters. If you know the rules, the mask attack helps you use such policies to your advantage by only checking for passwords that match the known structure.

Note: while the Mutations attack expands the number of passwords to try, Masks do the opposite by skipping checks on passwords that don’t match the set mask.

You can read more about the masks in the Attack Settings.

Combination and Hybrid attacks

In real life, encountering passwords made of a single dictionary word is rare. More often than not, passwords consist of two or three words combined with some numbers and special characters. The Combination and Hybrid attacks target this kind of passwords by allowing you to try passwords made of two words, each of them taken from the dictionary. You can use the same or different dictionaries for the first and second words. We recommend enabling the check for upper-case and lower-case combination, word delimiters and extra mutations.

With the first option, the program will try to capitalize the first letter of each word, i.e. testing all four combinations. The second option (Use word delimiters) allows to set the different characters (like dash and underline, though you can set any other ones as well) to be used between words. Finally, you can apply extra mutations to all resulting passwords (Dictionary mutations options will be used). The program tries to estimate the total number of passwords instantly, but mutations will not be counted.

Hybrid attacks are even more complex, allowing to specify scriptable rules desribing the passwords. Combination and Hybrid attacks are documented in the Attack Settings section of the manual.

Suggested Wi-Fi Password Auditing Workflow

Our suggested workflow for auditing Wi-Fi passwords consists of the following steps.

  1. Prepare the list of local phone numbers and save it as a text-based dictionary file. Run a plain, straightforward, zero-mutation attack through that dictionary.
  2. Try all-digit passwords. Depending on the available computational resources, you may be able to try passwords containing 8 to 10 digits in a matter of minutes. From the technical standpoint, this is considered a brute-force attack configured as follows: minimal password length = 8; maximum password length = 10; character set: 0123456789
  3. Run an attack through the Top 10,000 and Top 10 million password lists. Again, no mutations, just straightforward dictionary attacks.
  4. Run a dictionary attack with mutations (single dictionary).
  5. Optional: run a dictionary attack with masks.
  6. Run a hybrid attack with two dictionaries and mutations (note: the two dictionaries may be the same or different to help you try combinations of two words).

In our recent article iPhone Acquisition Without a Jailbreak I mentioned that agent-based extraction requires the use of an Apple ID that has been registered in Apple’s Developer Program. Participation is not free and comes with a number of limitations. Why do you need to become a “developer”, what are the limitations, and is there a workaround? Read along to find out.

Sideloading IPA Packages onto iOS Devices

Elcomsoft iOS Forensic Toolkit now supporting agent-based extraction without a jailbreak also brings a new requirement. Agent-based extraction is a newer, forensically sound alternative to traditional acquisition methods requiring a jailbreak. Based on direct access to the file system, agent-based extraction does not require jailbreaking the device. Using agent-based extraction, you can can image the full file system and decrypt the keychain without the risks and footprint associated with third-party jailbreaks.

The new acquisition method utilizes an extraction agent, which in turn is an app we’ve developed for the iOS platform. Once installed, the agent will talk to your computer, delivering significantly better speed and reliability compared to jailbreak-based extraction. In addition, agent-based extraction is safe as it neither modifies the system partition nor remounts the file system while performing automatic on-the-fly hashing of information being extracted. Agent-based extraction does not make any changes to user data, offering performance that is as close to forensically sound extraction as at all possible (only a few log entries are left behind after the agent is removed).

Interestingly, most jailbreaks (with the exception of checkra1n, which uses a bootrom exploit) also require a developer account in order to be installed. Before you begin using agent-based extraction (or install a jailbreak), you must have your Apple ID enrolled in Apple’s Developer Program. This is required in order to sideload the agent onto the iOS device being acquired. You can enroll at developer.apple.com/programs/enroll/; the process is fast and easy if you do it as a private person.

Why this requirement? Before I go into technical details, let me briefly explain what happens when you command iOS Forensic Toolkit to install an agent.

The extraction agent is deployed on iOS devices in the form of an IPA package. An IPA (iOS App Store Package) file is an iOS application archive file which stores an iOS app. Technically speaking, an IPA file is a ZIP archive that contains a binary for the ARM architecture that can be installed on an iOS device.

Each IPA file must be signed before you can install it onto an iOS device. While any Android phone can install any APK signed with a valid certificate, Apple makes sideloading apps significantly more difficult. An IPA package can be signed in one of the following ways.

Signed with a regular Apple ID

The digital signature is tied to each iOS device. An IPA signed with a certain Apple ID for a certain device can only be installed on that particular device; it cannot be distributed. If an IPA package was signed with a regular Apple ID, iOS will need to validate the digital signature by connecting to an Apple server, which means that the device you’re pushing the app to must go online in order to install the IPA. For the purposes of mobile forensics, we don’t want the device to go online to mitigate the risks of receiving a remote lock, remote erase or Find My commands, as well as syncing the device with the iCloud (many 3rd party applications may also sync, of course, as well as the system itself).

Signed with an Enterprise account

Apple enables companies distribute in-house apps to their employees bypassing Apple checks for compliance with App Store policies. These apps can be signed with a so-called enterprise certificate. Enterprise certificates must be also validated by the iOS device; the device must go online and connect to Apple servers in order to validate the certificate. These certificates are meant to be used by each company to distribute apps among its own employees. If a company attempts using their enterprise certificate to sign apps and distribute them globally, Apple revokes their certificate. However, unless revoked, enterprise certificates do not limit the number of devices that can install a signed IPA package. For this reason, leaked enterprise certificates are frequently used by third-party app stores and Web stores such as ignition.fun to sideload IPA packages.

Signed with a Developer account

Developer accounts are unique in that verification occurs on Apple servers and not on the iOS device. In order to use a developer certificate to sign an IPA package, developers must first register the iOS device (iPhone, iPad etc.) in their Apple Developer Account by adding it to the Developer Profile. Once this is done, one can sign the IPA package with their developer certificate and sideload the IPA onto the iOS device. Importantly, the iOS device will not need to go online in order to validate the certificate as its UUID is already provisioned. For this reason, developer certificates are (and have always been) the most forensically sound method of pushing jailbreaks (and now the extraction agent) onto iOS devices.

What Has Changed

For years, Cydia Impactor and similar tools have been able to sideload packages onto iOS devices using disposable Apple ID’s. Apple imposed several limitations to discourage users from treating sideloading as a replacement for Apple’s own App Store. Sideloaded apps signed with a non-developer Apple ID would expire after a mere 7 days, requiring to re-sideload and re-sign the app. Since iOS 10, one could not have more than 3 sideloaded apps on the device, and you couldn’t use the same Apple ID to sideload more than 10 apps per week. There were also other limitations in place, but at very least users could temporarily install apps that were not approved by Apple.

Something had changed in November, 2019.

About two weeks ago, Apple made a change to their provisioning service to require a different authentication scheme for “free” Apple accounts (they return an error that mentions upgrading to “Xcode 7.3”); this broke Cydia Impactor for users without a paid Apple Developer account.

https://twitter.com/saurik/status/1196888477830221824

Elcomsoft iOS Forensic Toolkit uses a similar IPA sideloading mechanism, meaning that, for the time being, the users are forced to use a paid Apple Developer account to sideload the extraction agent IPA.

We are currently working on a solution allowing our users to sideload the extraction agent using disposable (free) Apple accounts for Mac users. Windows users will likely have to wait longer.

Developer Account Limitations

Apple would not be Apple if it didn’t have some roadblocks in place.

The first roadblock has to do with two-factor authentication. An Apple ID enrolled in Apple’s Developer Program must have two-factor authentication enabled. Elcomsoft iOS Forensic Toolkit requires a login and password. As a result, you’ll have to take an extra step in setting up an Application-specific password in your Apple account. You’ll have to use that app-specific password instead of your regular Apple ID password when installing the extraction agent in iOS Forensic Toolkit.

The second limitation is about the number of devices that can be enrolled. As an Apple developer, you can only add up to 100 devices of each kind (e.g. 100 iPhones, 100 iPads etc.) per year. The number of available registration slots will only reset once a year even if you delete the device afterwards.

It is also worth noting that once you add a new device to your Developer Profile, the provisioning profile that is used to sign the extraction agent will list all previously registered device ID’s (UDID) unless you manually remove them from the Developer Profile prior to extraction (which, again, won’t reset the limit). The good news is that you won’t have to manually add the device to the developer profile if you use Elcomsoft iOS Forensic Toolkit; all you need is just command it to install an agent, and type in your developer Apple ID and that application-specific password we’ve talked about earlier.

Enrolling your Apple ID into the Developer Program can be especially tricky for corporate developers. For this reason, we recommend registering as a private person for $99 a year.

Workarounds

There are multiple apps and services positioning themselves as “App Store alternatives”. AltServer, AppStore.io, AppEven, ignition.fun, Tutuapp, Pandahelper, App Valley, Desde tu iPhone, Tweakbox and numerous other “alternative app stores” utilize a mix of paid and stolen developer accounts and leaked enterprise certificates to sign and sideload apps onto the iPhone. Some of these stores are known to overwhelmingly modify the content of the devices they sideload apps to, so neither of them can be recommended for the purpose of mobile forensics.

A Word On checkra1n & checkm8

This is slightly outside the scope of this article, but you may ask why you even need that acquisition method if there are such things as checkm8 exploit and checkra1n jailbreak that do not require a developer account to install unlike most other jailbreaks.

First, the compatibility. We have about fifty test devices (iPhones and iPads) in our lab, and most of them are checkm8-compatible, at least theoretically. If checkra1n installs, then we can make full file system acquisition and keychain extraction without an agent, minor issues with iOS 13 aside (iOS Device Acquisition with checkra1n Jailbreak). This jailbreak makes it possible to perform a limited BFU (“before first unlock”) extraction for devices with an unknown passcode, even if they are disabled or locked. But checkra1n is only compatible with iOS 12.3 and up. And of course, the hardware support is limited to the iPhone 5s through 8/8 Plus/iPhone X, so forget about iPhone Xr, Xs and 11 extraction.

Second, the reliability and speed. Not just the checkra1n itself, but even some implementations of checkm8-based extraction leave much to be desired. checkra1n fails to install on many devices for no obvious reason. In our experience, as many as 30% of devices may be problematic. The situation is even worse for direct implementations of checkm8 based extraction. Just one example; I will not name the vendor for ethical reasons:

We are currently doing our office’s first Checkm8 extraction on an iPhone 8 plus 64GB w/13.3. It’s been running two days now and the estimated time to completion keeps going up, from 8 days yesterday to now 15 days today. At first things looked pretty normal but the estimated time just keeps going up. Any ideas on what could be the problem? Another odd thing is it says 8GB of 88 GB extracted, which of course makes no sense being a 64GB device.

And one of the responses:

I also encountered a lot of iPhone devices that extracted “full file system” with no success, lasting for weeks.

Finally, the “forensically sound” issue. There is no agreement among the forensic vendor about the meaning of this term. Moreover, speaking of the iPhone extraction, it is not possible to prove that the device content has not been modified during the extraction, regardless of the method you use (whether it’s good old logical acquisition, checkm8 or agent-based extraction). All extraction methods leave some traces, making some changes to the device data.

Is agent-based solution we have implemented a silver bullet? Of course not. It also has limited compatibility with device models and iOS versions (we are working hard on that, an Elcomsoft iOS Forensic Toolkit update is coming with support for iOS 13.0-13.3 on all devices), and it also has some reliability issues. The acquisition speed is always higher; we’ve been able to get up to 40 MB/s. There are many hardware/iOS combinations that only the agent works for. You just need the Developer Account, that’s it.

Conclusion

The $99 a year for Developer Account is a great, cost-efficient investment because it’s the only type of accounts offering safe, forensic-friendly extraction. Developer accounts are the only type of accounts whose provisioning profiles do not require the device being acquired connecting to Apple servers. The entire sideloading and extraction process can be performed safely while the device is in the Airplane mode.