ElcomSoft blog

End-to-End Encryption in Apple iCloud, Google and Microsoft Accounts

Thu, 21 Jan 2021 15:31:37 GMT

The proliferation of always connected, increasingly smart devices had led to a dramatic increase in the amount of highly sensitive information stored in manufacturers’ cloud accounts. Apple, Google, and Microsoft are the three major cloud providers who also develop their own hardware and OS ecosystems. In this report, we’ll see how these companies protect their users’ highly sensitive information compared to each other.

Storage encryption

First and foremost, everything stored in the cloud is always encrypted, whether you are using an Apple, Google or Microsoft ecosystem. Information stored in the cloud is broken into chunks, and each chunk is securely encrypted. The encryption key are never stored on the same physical device as the data. Similar encryption techniques are employed by Google and Microsoft.

For example, in the case of Apple iCloud, the data chunks are stored on servers controlled by third-party service providers such as Amazon, Microsoft, AT&T, or the Chinese government. However, the encryption keys are physically stored on Apple’s own servers in Cupertino, making the data impossible to decrypt for anyone who gains physical access to any such server. This is what Apple has to say about storage encryption:

iCloud secures your information by encrypting it when it’s in transit, storing it in iCloud in an encrypted format, and using secure tokens for authentication. […] In some cases, your iCloud data may be stored using third-party partners’ servers—such as Amazon Web Services or Google Cloud Platform—but these partners don’t have the keys to decrypt your data stored on their servers.

The important thing is that, at least for some data, both the data and the encryption keys are under the cloud vendor’s control, making it possible for vendors to serve government requests. In addition, any user can access the data by signing in with the login and password (and, in most cases, passing two-factor authentication). We make tools for that: Elcomsoft Phone Breaker (Apple iCloud and Microsoft Accounts) and Elcomsoft Cloud Explorer (Google Accounts).

Storage encryption summary: user data in cloud services is encrypted, which protects against unauthorized physical access to underlying hardware. Vendors have the encryption key, and they also have full access to user data. Government requests are served.

End-to-end encryption

End to end encryption is used as an additional protection layer to safeguard some of the most sensitive information against unauthorized access even if the intruder knows the login and password to the user’s cloud account. Data protected with end-to-end encryption requires an additional secret to unlock the encryption key. In today’s implementations of end-to-end encryption used by Apple and Google that additional secret is the user’s user’s screen lock passcode, the very PIN code that one types to unlock their device. For Apple, which tightly controls its entire ecosystem, it could also be the password to a Mac computer. This is how Apple defines end-to-end encryption in iCloud Security Overview:

For certain sensitive information, Apple uses end-to-end encryption. This means that only you can access your information, and only on devices where you’re signed into iCloud. No one else, not even Apple, can access end-to-end encrypted information.

The important difference between storage encryption and end-to-end encryption is that no one, not even the cloud vendor, can access end-to-end encrypted data without knowing the secret. As a result, when serving legal requests, vendors could only return encrypted data without means to decrypt.

End-to-end encryption summary: user data is encrypted with storage encryption; on top of that, an extra layer of encryption is applied. Vendors do not have the encryption key, and they don’t have access to any end-to-end encrypted data. Government requests result in encrypted, useless data that cannot be decrypted.

How Apple, Google and Microsoft use end-to-end encryption

There are stark differences in how Apple, Google and Microsoft handle end-to-end encryption of user data.

Apple uses end-to-end encryption to protect the following:

iCloud keychain (stored passwords for Web sites, apps, social networks, accounts and instant messengers; keys, tokens, certificates etc.)
Cloud messages (SMS and iMessage)**
Health data
Home data
Screen Time*
Significant locations*
Voice memos
Apple Maps (searches, routes,
Safari browsing history (since iOS 14)

What about the types of data marked with a *? Interestingly, some categories (at least Screen Time and Significant Locations) appear to be synchronized via a different mechanism, and are, in a sense, the only “truly end-to-end encrypted” types of data. We were unable to decrypt these categories even with the screen lock passcode.

For Messages specifically, Apple put the following note:

Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn’t stored by Apple.

We were unable to verify this claim. However, if what Apple says is correct, one could technically access at least the Messages category even without access to the trusted circle and/or passcode.

So if there are “truly end-to-end encrypted” types of data, what about the rest? Those other types of data (except those marked with a *) can be accessed from any authorized device that is part of the “trusted circle”. In order to enroll the device into the trusted circle, one must provide a screen lock passcode or system password from any device that’s already in the circle. Effectively, this makes the encryption key unlockable with a passcode to any device in the trusted circle, and not just the one device that originated the data.

Technically speaking, these “other” categories are, in fact, protected only by Apple’s goodwill and their promise not to attempt decrypting the data. Since the encryption keys are based on the user’s screen lock passcode (whose typical length is merely 6 digits), should Apple decide to break in, in most cases it would be able to do so in a matter of minutes. This is precisely why we fail to recognize Apple’s “end-to-end encryption” as true end-to-end encryption.

Apple mentions several additional categories using end-to-end encryption. These are:

Apple Card transactions (requires iOS 12.4 or later)
Memoji (requires iOS 12.1 or later)
Payment information
QuickType Keyboard learned vocabulary (requires iOS 11 or later)
Siri information
W1 and H1 Bluetooth keys (requires iOS 13 or later)

So far, we’ve been unable to access any of these categories, with or without a passcode.

Interestingly, Apple is NOT using end-to-end encryption to protect FileVault 2 recovery keys, which potentially allows to access encrypted partitions on Mac computers.

No end-to-end encryption: FileVault 2 recovery keys

Google, on the other hand, applies end-to-end encryption differently. Since the release of Android 9 in August 2018, Google has been encrypting cloud backups produced by Android phones running Android 9 or newer. The backups are encrypted with a key derived from the user’s screen lock passcode.

This is what Google has to say about end-to-end encryption of Android backups:

Easily restore your data or switch phones at any time. Your backup includes apps, app data, call history, contacts, device settings (including Wi-Fi passwords and permissions), and SMS.

Your backups are uploaded to Google and encrypted using your Google Account password. For some data, your device’s screen lock PIN, pattern, or password is also used for encryption.

App data can be any data that an app has saved (based on developer settings), including data such as contacts, messages, and photos.

In Android, backups contain certain types of data that are synchronized by other companies (e.g. Apple). By default, only the following categories are protected with end-to-end encryption:

Android backups (requires Android 9 or newer)
Text messages (SMS only) since these are not synced but stored in Android backups
Call logs (again, since these are not synced but stored in Android backups)

In addition, users can set up end-to-end encryption to protect their Chrome passwords by choosing to encrypt the password database with a password instead of account credentials.

Optional: Chrome passwords

The following information is NOT protected by end-to-end encryption, and is fully accessible to Google proper, law enforcement officials and just about anyone with valid authentication credentials:

Chrome passwords (in default configuration)
Health data (Google Fit)
Screen Time (Digital Wellbeing)
Location data (lots of it)
Searches and Chrome browsing history
All other information in the user account

Microsoft is not currently using end-to-end encryption to protect data. As a result, the following sensitive information may be exposed if an intruder gains access to the user’s authentication credentials:

Messages (Skype conversations)
Passwords (Edge Legacy, Edge Chromium)
BitLocker recovery keys

More than just encryption

While storage encryption and end-to-end encryption of user accessible data are well documented, there are some types of data that never make it to the end user. Examples of such data include FaceTime logs, iCloud connection logs, Apple Store visits and a few more bits and pieces. These data are not made available to the end user. Law enforcement agencies can obtain the data by serving a government request. Neither of these data appear to be end-to-end encrypted.

Conclusion

As one can see, the three major cloud vendors approach end-to-end encryption in discretely different ways. While Apple appears to be moving more and more data under the end-to-end encryption umbrella, Google only allows end-to-end encryption for Android 9 and later device backups and, optionally, for Chrome passwords. Microsoft currently does not support end-to-end encryption at all, not even for passwords.

Secure Instant Messengers

Tue, 19 Jan 2021 13:54:25 GMT

In today’s world of everyone wanting a slice of one’s personal information, users become more and more concerned about the privacy. The WhatsApp/Facebook integration raised an additional concern, considering that Facebook-owned Messenger requests the largest number of invasive permissions among all commonly used messengers. Data privacy and security concerns are mounting like a snowball. 2020 brought multiple data breach incidents from popular blogging resources from LiveJournal whose users’ data was breached and leaked to the darknet to financial institutions like Postbank with 12M exposed credit cards, hospitality giants as Mariott with 383 million records compromised or even Microsoft customers who also suffered from privacy-related issues.

A few days ago, we conducted a twitter poll asking which instant messenger is trusted the most. We launched the poll after Facebook published a new privacy policy for WhatsApp. According to the new policy, the app was free to share user data with third parties. Almost 800 people took part in the survey, which clearly demonstrates the concern about privacy in communication apps.

Respondents’ answers split in the following way:

Signal – 46.6%
Telegram – 30.1%
WhatsApp – 15%
Other – 8.3%

During the two days of the survey, two major messengers fought for leadership, making it obvious that the majority are inclined to entrust their private correspondence to either Signal or Telegram. WhatsApp, which was one of the world’s most popular messengers in 2020 with its two billion monthly active users, lags far behind both.

Telegram and Signal are on the front line of privacy protection when it comes to data collection. Telegram only collects basic information such as the user’s contacts and their phone numbers, while Signal accesses only contact info which is not linked directly to you. Other messengers may collect a gazillion of irrelevant (but very tempting for the advertiser) data types, as many as an average social network.

Some respondents provided additional insight in the comments, suggesting alternative messengers that, in their opinion, ensure the elevated level of privacy. Most often recommended were Threema, Wire, Session, Wickr, Olvid, BiP, and Element. All of these tools advertise secure and private messaging.

We in Elcomsoft look at data privacy and security from a different angle. We evaluate instant messengers in terms of the possibility to gain access to the user’s personal data, and extract available information, regardless of what’s written in the vendor’s privacy policy. We have already completed the research and published the Forensic Guide to iMessage, WhatsApp, Telegram, Signal and Skype data acquisition.

The number of communication tools grows fast, especially at the time of working from home. New platforms emerge offering a different view on privacy and security or entertainment features. Some monetize by showing targeted ads or collecting and reselling personal information. Others are less fun to use, but offer greater privacy and anonymity. Today, privacy is a tradeoff between secrecy and monetization efforts. The choice is always yours.

DFU Mode Cheat Sheet

Thu, 14 Jan 2021 17:47:26 GMT

The Device Firmware Upgrade mode, or simply DFU, just got a second breath. The ability to image the file system, decrypt the keychain and even do passcode unlocks on some older iPhone models has been made possible thanks to the checkm8 exploit and the checkra1n jailbreak, both of which require switching the phone into DFU. The procedure is undocumented, and the steps are different for the various devices.

Why DFU?

Literally, you need DFU when performing checkm8 or checkra1n extraction of an iPhone 5 through iPhone X, or using limera1n for the same purpose on older devices. You also need DFU when performing passcode unlocks (currently, we support the iPhone 4, 5 and 5c only). You can also use DFU for “Before First Unlock” (BFU) extractions. Finally, DFU can be used to reset a locked phone (although you’ll be facing iCloud lock when setting it up, and all the data will be irreversibly gone).

Before you begin

Before you begin, there is one thing to consider. For a long time, we’ve seen reports of experts using a trick to increase their success rate of installing the exploit. For the purpose of exploiting the bootloader vulnerability, many experts have a greater success rate if they switched the device to recovery mode first, followed by switching to DFU. This is applicable to most models, including phones as old as the iPhone 5 and as new as the iPhone 8. Interestingly, we could not confirm this on the latest iPhone 12.

To sum it up: if you are pursuing checkm8 or checkra1n extraction, consider switching the phone into recovery and only then to DFU mode.

Switching to recovery mode

Unlike DFU, the recovery mode is well documented in “If you can’t update or restore your iPhone, iPad, or iPod touch”. Steps for entering the Recovery mode are different between iOS devices. Devices with a physical Home button, capacitive Home button and without the Home button employ different steps to enter Recovery mode.

For devices with physical Home buttons, follow these steps:

Turn off the device.
Press and hold the home button.
Connect the device to computer with iTunes.
Wait until you see the iTunes logo and the cable on the iPhone.

Apple recommends the following steps for entering Recovery mode:

If iTunes is already open, close it. Connect your device to your computer and open iTunes.
While your device is connected, force restart it with these steps, but don’t release the buttons when you see the Apple logo, wait until the connect to iTunes screen appears:
- On iPhone 8 and later: Press and quickly release the Volume Up button. Press and quickly release the Volume Down button. Then, press and hold the Side button until you see the connect to iTunes screen.
- On an iPhone 7 or iPhone 7 Plus: Press and hold the Side and Volume Down buttons at the same time. Keep holding them until you see connect to iTunes screen.
- On an iPhone 6s and earlier, iPad, or iPod touch: Press and hold both the Home and the Top (or Side) buttons at the same time. Keep holding them until you see the connect to iTunes screen.

How to exit recovery mode

The procedure for leaving the recovery mode is different for different devices. In general, you’ll use the following steps:

Unplug the USB cable.
Hold down the sleep/wake button or side button depending on device model until the device turns off.
Either keep holding the button combination or release and hold it down again until the Apple logo appears.
Let go of the buttons and let the device start up.

This is the Apple-recommended procedure for exiting the recovery mode:

iPhone 6s and earlier, Touch ID equipped iPads: hold the Home button and the Lock button until the device reboots.
iPhone 7 and iPhone 7 Plus: hold down the Side button and Volume Down button until the device reboots.
iPhone 8 and newer: click the Volume Up button, then click the Volume Down button, then hold down the Side button until the device reboots.

The DFU mode

The undocumented DFU stands for “Device Firmware Upgrade”. Unlike the recovery mode, which is designed with an ordinary user in mind, the DFU mode was never intended for the public. There is no documentation about DFU anywhere in Apple Knowledge Base. Entering the DFU more involves a complicated sequence of pressing, holding and releasing buttons with precise timings. Wrong timings during any of the multiple steps would reboot the device instead of switching it to DFU. Finally, there is no on-screen indication of DFU mode. If the device is successfully switched to DFU, the display remains black. Entering DFU mode can be difficult even for experts.

DFU is part of the bootrom, which is burned into the hardware. On A7 through A11 devices, a vulnerability has been discovered allowing to bypass SecureROM protection and jailbreak the device via DFU mode. More in our blog: BFU Extraction: Forensic Analysis of Locked and Disabled iPhones.

Entering DFU mode

Steps for entering DFU mode differ between devices. Some devices have several different methods to invoke DFU, making it even more confusing. The differences in procedures may be severe between device generations. Since no official instructions are available, one has to rely on third-party sources for information.

Sources:

Additional information:

Note: the device screen will be completely black while in DFU mode. The iPhone Wiki explains steps required to enter the DFU mode in a dedicated article. According to the article, this is how you enter DFU mode on the different device models.

Apple TV

Plug the device into your computer using a USB cable.
Force the device to reboot by holding down the “Menu” and “Down” buttons simultaneously for 6-7 seconds.
Press “Menu” and “Play” simultaneously right after reboot, until a message pops up in iTunes, saying that it has detected an Apple TV in Recovery Mode.

A9 and older devices (iPad other than the ones listed below, iPhone 6s and below, iPhone SE and iPod touch 6 and below)

Connect the device to a computer using a USB cable.
Hold down both the Home button and Lock button.
After 8 seconds, release the Lock button while continuing to hold down the Home button.
- If the Apple logo appears, the Lock button was held down for too long.
Nothing will be displayed on the screen when the device is in DFU mode. If open, iTunes will alert you that a device was detected in recovery mode.
- If your device shows a screen telling you to connect the device to iTunes, retry these steps.

Alternative method 1:

Hold the Lock Button for 3 seconds
Continue holding the Lock button and also hold the Home button (15 seconds)
Release the Lock button while continuing to hold the Home button (10 seconds)
Your device should enter DFU mode

Alternative method 2:

Connect the device to your computer and launch iTunes. Turn the device off.
Hold down the Lock button and Home button together for exactly 10 seconds, then release the Lock button.
Continue holding the Home button until iTunes on your computer displays a message that a device in recovery mode has been detected. The device screen will remain completely black.

A10 devices (iPhone 7 and iPhone 7 Plus, iPad 2018, iPod touch 7)

Connect the device to a computer using a USB cable.
Hold down both the Side button and Volume Down button.
After 8 seconds, release the Side button while continuing to hold down the Volume Down button.
- If the Apple logo appears, the Side button was held down for too long.
Nothing will be displayed on the screen when the device is in DFU mode. If open, iTunes will alert you that a device was detected in recovery mode.
- If your device shows a screen telling you to connect the device to iTunes, retry these steps.

A11 and newer devices (iPhone 8 and above, iPad Pro 2018, iPad Air 2019, iPad Mini 2019)

Note: for these devices, higher success rate has been reported when using the recovery mode first.

Connect the device to a computer using a USB cable.
Quick-press the Volume Up button
Quick-press the Volume Down button
Hold down the Side button until the screen goes black, then hold down both the Side button and Volume Down button.
After 5 seconds, release the Side button while continuing to hold down the Volume Down button.
- If the Apple logo appears, the Side button was held down for too long.
Nothing will be displayed on the screen when the device is in DFU mode. If open, iTunes will alert you that a device was detected in recovery mode.
- If your device shows a screen telling you to connect the device to iTunes, retry these steps.

If your device shows a screen telling you to connect the device to iTunes, retry these steps.

A12, A13 and A14 Bionic devices (iPhone Xr and Xs range, iPhone 11 and iPhone 12 range)

While you can switch these devices into DFU, there is little point in doing so. The checkm8 exploit is not applicable to any of these models, so there is a very little practical benefit of the DFU mode from the forensic standpoint.

How to exit DFU mode

The process of exiting DFU mode is also different across devices.

For devices with a physical Home button (up to and including iPhone 6s and iPhone SE): hold the Home button and the Lock button until the device reboots.

For iPhone 7 and iPhone 7 Plus: hold down the Side button and Volume Down button until the device reboots.

For iPhone 8 and iPhone 8 Plus, iPhone X: click the Volume Up button, then click the Volume Down button, then hold down the Side button until the device reboots.

Apple, FBI and iPhone Backup Encryption: Everything You Wanted to Know

Thu, 07 Jan 2021 07:09:43 GMT

Shame on us, we somehow missed the whole issue about Apple dropping plan for encrypting backups after FBI complained, even mentioned in The Cybersecurity Stories We Were Jealous of in 2020 (and many reprints). In the meantime, the article is full of rumors, guesses, and unverified and technically dubious information. “Fake news”, so to say. Is there truth to the rumors, and what does Apple do and does not do when it comes to encrypting your personal information?

iCloud Security

We know a lot about iCloud encryption, as we were the first third party who independently reverse engineered it over 8 years ago. I personally made several dozen presentations on iCloud security in various conferences all over the world. iCloud is a very complex ‘ecosystem’, and let me outline the main points on how it handles and protects the data.

The data stored in iCloud includes:

Device backups (iOS, iPadOS)
Data synced across devices (such as contacts, notes, etc.)
iCloud Drive (both the regular storage and third-party app data)
Some extras (such as logs, purchase history, etc.)

Some information on the encryption is provided in iCloud security overview in Apple Knowledge Base, and we have a deeper explanation in our own article iCloud Backups, Synced Data and End-to-End Encryption. In a nutshell:

All data is stored on servers that are hosted by other companies (but not by Apple)
All data is encrypted
The encryption keys are stored at Apple’ own servers
Some data is so-called “end-to-end” encrypted

As we explained before, there is no real end-to-end encryption in iCloud (apart from some data that is being synced directly between devices, such as certain location data and Screen Time stats). What Apple says (“Your data is protected with a key derived from information unique to your device, combined with your device passcode, which only you know. No one else can access or read this data”) is not the whole truth. Having only the iCloud credentials (incl. the second factor) and the passcode of one of the trusted devices (just the passcode, not the device itself and definitely not anything “unique to your device“), a third party can access this data – using Elcomsoft Phone Breaker.

iCloud Backups

In Apple ecosystem, the backups do not have any kind of additional protection or encryption with the user’s password. While still protected with storage encryption (with encryption keys kept on Apple servers), there is nothing that could check as “end-to-end encrypted”. Despite that, iCloud backups are very difficult to obtain if you are not restoring a genuine Apple device running a compatible version of iOS. There are generally two ways for accessing iCloud backups:

Legal request: obtained directly from Apple, through the company’s Law Enforcement Support Program
Download with our software

Government requests are served according to Apple’s legal process guidelines. We covered this topic before:

In fact, Apple returns encrypted data (from third-party servers) accompanied with the encryption keys from their own servers. This data is very “raw”; it is not structured as standard iTunes-style backups (unlike with our software; which, by the way, delivers more iCloud-synced data than Apple returns when serving LEA requests). If you’re using our software to download backups, you will need the following:

Apple ID
Password to that Apple ID
Second authentication factor (trusted device or SIM card)

There are two major problems with iCloud backups (whatever method is used). First, with every major iOS version, Apple reduces the amount of data that goes into iCloud backups as opposed to being synchronized across devices via a different mechanism. As of iOS 14 (14.4 beta at the time of this writing), the following data is (or may be) missing in cloud backups:

Health records
Call logs
Safari browsing history
Media files (pictures and videos), if synced
Messages (iMessage and SMS), if synced
Keychain

The keychain is something very special. It is included in iCloud backups, but with an extra protection layer. The records are encrypted with a hardware-specific key, so that the keychain can only be restored onto the same physical device it was backed up from. If you restore an iCloud backup to any other device, everything but keychain data is restored. You can use iCloud keychain, but this is a different story.

The Article

Let’s go back to the article; I want to quote and comment a few lines.

…six sources familiar with the matter told Reuters

As many as six sources, really? Good luck getting any information on Apple internal plans at all, even from a single source. Most Apple employees and LEA officials are under strict NDA. But anyway, let’s take a note of this number: 6.

The tech giant’s reversal, about two years ago, has not previously been reported. It shows how much Apple has been willing to help U.S. law enforcement and intelligence agencies.

I will not comment on the “has not been previously reported” (assuming that all six sources decided to share confidential information with a Reuters reporter at the same time), but do you understand the second part? I do not. “Apple has been willing”, but then changed its mind (and now does not), or what? Apple does help Law Enforcement, and it does comply with the laws. And not just in the U.S. but worldwide.

U.S. President Donald Trump piled on, accusing Apple on Twitter of refusing to unlock phones used by “killers, drug dealers and other violent criminal elements.”

So what? No relationship to iCloud [backups].

More than two years ago, Apple told the FBI that it planned to offer users end-to-end encryption when storing their phone data on iCloud, according to one current and three former FBI officials and one current and one former Apple employee.

Now we have not six but five “insiders”: four from the FBI (three of them are ex), and one from Apple (also an ex). Not only the numbers do not much, but the entire statement is hard to believe.

Under that plan, primarily designed to thwart hackers, Apple would no longer have a key to unlock the encrypted data, meaning it would not be able to turn material over to authorities in a readable form even under court order.

First, nobody knows the actual reason behind this plan, if it ever existed. Second, Apple never provided iCloud backups “in a readable form” (it is really troublesome to decrypt and analyze iCloud backup data returned by Apple).

Reuters could not determine why exactly Apple dropped the plan.

So Reuters know (told by 5 or 6 sources, or just guessing?) that the plan was to “thwart hackers”, but have no idea why it was dropped? Let’s keep reading.

Two of the former FBI officials, who were not present in talks with Apple, told Reuters it appeared that the FBI’s arguments that the backups provided vital evidence in thousands of cases had prevailed.

New numbers: two of the (former) three. And if they never talked to Apple, how do they know?

However, a former Apple employee said it was possible the encryption project was dropped for other reasons, such as concern that more customers would find themselves locked out of their data more often.

I think this is the actual reason. But I like the “it was possible”, so the former Apple employee was not sure either.

Once the decision was made, the 10 or so experts on the Apple encryption project – variously code-named Plesio and KeyDrop – were told to stop working on the effort, three people familiar with the matter told Reuters.

Okay, now we have ten more experts, and three more “people familiar with the matter”. I am totally confused with the numbers now.

But I am even more confused with Plesio and KeyDrop “projects”. What the hell is the “project” in terms of backup encryption? Was it to implement the same scheme as in the local, iTunes-style backups (that is indeed very strong)? And why two?

Apple’s decision not to proceed with end-to-end encryption of iCloud backups made the FBI’s job easier.

Instead of protecting all of iCloud with end-to-end encryption, Apple has shifted to focus on protecting some of the most sensitive user information, such as saved passwords and health data.

Passwords were always encrypted, from the very first version where iCloud backups were implemented (iOS 5 if I remember correctly). As for the Health data, it was not “end-to-end encrypted” in iOS 11, but only since iOS 12. To be honest, Health records rarely contain critical evidence; there are several significantly more critical categories. Also, if Apple still decided to protect some sensitive information, how does it make the FBI job easier?

But backed-up contact information and texts from iMessage, WhatsApp and other encrypted services remain available to Apple employees and authorities.

Not exactly. iMessage and text messages are not always included in iCloud backups. WhatsApp chats can be opted-out easily (by the user). And most other “encrypted services” (like Telegram and Signal) never store the chats in backups (even local ones), see Forensic guide to iMessage, WhatsApp, Telegram, Signal and Skype data acquisition.

Conclusion

Never blindly trust media reports. Do your own fact check, and exercise due diligence. If you want to read a serious report, I recommend Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions – an excellent piece of work covering both physical devices and iCloud security; or Mass Extraction: The Widespread Power of U.S. Law Enforcement to Search Mobile Phones for less technical info. And you have saved the address of our blog, right?

Apple Scraps End-to-End Encryption of iCloud Backups

Wed, 06 Jan 2021 16:02:31 GMT

Reportedly, Apple dropped plan for encrypting backups after FBI complained. Apple’s decision will undoubtedly cause turmoil and will have a number of consequences. In this article, I want to talk about the technical reasons for encrypting or not encrypting cloud backup, and compare Apple’s approach with the data encryption strategies used by Google, who have been encrypting Android backups for several years.

iCloud encryption

Apple encrypts everything stored in iCloud down to the last bit. All information that the user or their iPhone store in iCloud is securely encrypted in transit and in storage. On a physical layer, the data is cut into multiple small chunks. The chunks are distributed (randomly or redundantly) across various servers that belong to companies such as Amazon, Microsoft, AT&T, or controlled by the Chinese government if the user resides in Mainland China. Neither of these companies (nor the Chinese government) have access to the actual data since it is fully encrypted. The encryption keys are stored on Apple’s own servers in Cupertino. Without these encryption keys, no one can decrypt anything.

The thing is, the encryption keys are readily accessible if one has access to the user’s Apple ID account (as in knowing the login and password and being able to pass two-factor authentication). If a third party gains control over the user’s Apple ID/iCloud account, they can download and decrypt information.

More importantly, governments and the law enforcement can request information from Apple. Since Apple has full control over the encryption keys, the company will serve government requests by providing a copy of the user’s iCloud data along with the encryption keys. This is the status quo, and this is exactly what the FBI wants to protect.

This is how Apple encrypts your iCloud photo library. This is also the way your iCloud backups are currently protected, and it is not this type of encryption that Apple is about to scrap.

End to end encryption

There is another layer of encryption Apple uses to protect some of the information is considers the most sensitive. The company employs a protection method it calls “end-to-end encryption”. End-to-end encryption additionally encrypts certain types of data with a password only known to the end user. Without that password, no one, not even Apple, can decrypt the data.

What kind of a password? It’s the user’s screen lock passcode, the PIN code you type to unlock your iPhone or iPad, or the system password you use to sign in to your macOS computer. Technically speaking, a typical iPhone passcode consists of only 6 digits. If Apple wanted, it could brute-force “end-to-end encryption” in a matter of minutes (if not seconds). However, the company officially refuses to do so.

It is important to note that, while governments and the law enforcement can still request information that is end-to-end encrypted from Apple, they will get nothing but random-looking encrypted data in return. With Apple refusing to break the encryption and not supplying the governments with the right tools, certain types of data remain out of the reach of the law enforcement – unless they know the user’s screen lock passcode and use Elcomsoft Phone Breaker, that is. Nevertheless, end-to-end encryption adds an obstacle to the general procedure of government requests.

What kinds of data are currently protected with end-to-end encryption? Most importantly, the iCloud Keychain containing all of the user’s stored passwords to various Web sites, apps, social networks, accounts and instant messengers.

End-to-end encryption also protects Messages (SMS and iMessage), Health data, Screen Time, Home data, Voice memos, Apple Maps (searches, routes, frequent locations) and, since iOS 14, Safari browsing history.

What Apple had planned to do

Without a source in the company, we can only speculate on what exactly Apple planned to do for encrypting iCloud backups. Our educated guess is that the company was planning to use the already familiar end-to-end encryption scheme, additionally encrypting iCloud backups with a key derived from the user’s screen lock passcode.

This wouldn’t change much for the end user. When restoring from a cloud backup, they would only need to type in their old screen lock passcode (not even that if they reused their old passcode on their new device). Since Apple made passcodes nearly impossible to forget (users have to unlock their devices with a passcode to reenable Touch ID/Face ID every 72 hours at least), the fear of more users being “locked out” of their data is unsubstantiated except for a few marginal cases.

The use of end-to-end encryption would make it more difficult for the governments and the law enforcement to request data. Currently, Apple does not provide end-to-end encrypted data when serving government requests. Adding iCloud backups to the list of unavailable data sources was probably the last straw that made the FBI complain.

What about Google?

Since the release of Android 9 in August 2018, Google has been encrypting cloud backups produced by Android phones running Android 9 or newer. The backups are encrypted with a key derived from the user’s screen lock passcode, and nobody complained. Why the FBI does not seem to care about Android backups, and puts that much stress on to Apple? The content is the answer.

Android backups only contain marginal amount of information. According to Google’s Data backup overview, “Backup data is stored in Android Backup Service and limited to 5MB per app. Google treats this data as personal information in accordance with Google’s Privacy Policy. Backup data is stored in the user’s Google Drive limited to 25MB per app.” It is only the 5MB part that is encrypted with the user’s screen lock passcode. The other 25MB of data the apps are allowed to store in the user’s Google Drive are not encrypted with the user’s passcode (storage encryption still applies), and will be passed on when serving government requests.

What about “sensitive” data such as passwords, health, or location history? While Google collects massive amounts of data (significantly more than Apple), that data is protected… not. Governments and the law enforcement can request and receive the user’s passwords, location data, health information (Google Fit), browsing history and the history of search requests on a whim. The small and unimportant Android backup can be encrypted all Google wants.

In contrast, Apple devices produce large, comprehensive cloud backups that can be used to fully restore a new device. iCloud backups can be multiple gigabytes in size, and contain just about everything.

Conclusion

We regret Apple’s decision to scrap end-to-end encryption of iCloud backups, even if the new feature would make us spend countless hours circumventing the encryption.

Understanding BitLocker TPM Protection

Tue, 05 Jan 2021 10:36:05 GMT

Investigating a BitLocker-encrypted hard drive can be challenging, especially if the encryption keys are protected by the computer’s hardware protection, the TPM. In this article, we’ll talk about the protection that TPM chips provide to BitLocker volumes, and discuss vulnerabilities found in today’s TPM modules.

What is TPM

Trusted Platform Module (TPM) is a standard for a secure cryptoprocessor, a dedicated microcontroller designed to secure hardware through integrated cryptographic keys. On a physical level, the TPM might be implemented as a built-in chip, an additional module one can install into a slot on the desktop motherboard, or as a virtual emulator (the Intel PTT technology).

Infineon Optiga TPM chips:

Standalone TPM module for Asus motherboards:

The platform consists of a secure cryptoprocessor and a small amount of built-in memory. The main functions of TPM are the generation, storage and secure management of cryptographic keys; in particular, the BitLocker keys. The operating system must provide APIs for developers for accessing the TPM, and uses TPM to manage encryption keys.

In this article, I will talk about the role of TPM in BitLocker encryption.

When Windows developers were designing the disk encryption scheme, they attempted to counter the following threats:

Signing in to the user’s account without valid authentication credentials
Moving the hard drive to a different system for analysis
Altering the computer’s configuration for gaining access to the data
Running an alternate OS for gaining access to the data

The top priority, however, was that the protection was as transparent and as unobtrusive to the user as possible. Ideally, the user would never notice the encryption; this goal has been achieved. For those who need extra protection against additional threats, the developers allowed specifying a pre-boot PIN code or adding other types of protectors (e.g. a physical smartcard or USB drive).

How BitLocker works

BitLocker makes use of symmetric encryption. By default, AES-128 is used to encrypt data in either XTS (new) or CBC (legacy) mode. The data is encrypted with VMK (Volume Master Key), which in turn can be obtained in one of the following ways:

Decrypted with the user’s encryption password, if this protector is enabled for a given volume.
Decrypted with a Recovery Key. The Recovery Key is generated automatically once the encryption is enabled for the first time. The key is then either stored to a file, uploaded to the user’s Microsoft Account of saved in Active Directory.
(You are here) Extracted from the TPM module when certain conditions are met.

This is how Bitlocker communicates with TPM:

The basic principle of TPM is very similar to blockchain. During the boot, the system builds chain of trust, which is stored in PCR (Platform Configuration Register) registers.

This is what happens when the computer boots:

Power on. SRTM (Static root of trust for measures) is the first trusted module is loaded. This module is stored in the computer’s ROM, and cannot be altered. A vulnerability in this module breaks the entire protection scheme, which was clearly demonstrated by the developers of the checkm8 exploit for iOS devices. SRTM inserts the first record into the chain of trust by calculating the hash value of the computer’s BIOS. The hash is stored in a PCR register.
UEFI BIOS loads. The BIOS analyzes the computer’s configuration including the hard drive partitioning, the MBR (Master Boot Record), bootloader and many other parameters including firmware checksums of certain components (e.g. fingerprint readers or smartcard readers). Notably, the value of the previous PCR register is used to calculate new hash values, which means that any modification of a single PCR register breaks the entire chain.
After filling out several PCR registers, BIOS loads the bootloader from the MBR. The bootloader inserts a few more records.
Finally, the OS kernel starts. The kernel keeps adding to the chain of trust.

As you can see, once the OS is finally loaded, the PCR registers contain the entire chain of trust. Note that the TPM module does not allow modifying PCR registers; one cannot alter existing records, only add new ones.

This is how it all looks:

BitLocker encryption

Once the user enables BitLocker on a disk volume, Windows generates a random volume master key (VMK) as well as a recovery key. The master key is then stored in the TOM module; it is also encrypted with the recovery key. The encrypted VMK is then saved in the disk header. Once the computer is rebooted, the following happens:

All PCR registers are zeroed out.
The system follows steps 1 through 4 described earlier.
The OS kernel attempts unlocking the encrypted volume and requests the VMK from the TPM module. The TOM module in turn analyzes the chain of trust by checking PCR registers. If the chain of trust is corrupted, the VMK is not released; the OS kernel than displays a message requesting the user to unlock the volume with a Recovery Key.

As you can see, if the computer is powered off, the only way to obtain the VMK is by launching the original OS in its original configuration. Altering a single component will trigger the prompt for Recovery Key.

Bypassing TPM

Most often than not, you are analyzing a ‘cold’ system. If this is the case, make sure to capture the disk image before everything else. You can use Elcomsoft System Recovery to do that. Before taking the image, you’ll be able to see the list of disk partitions along with their encryption settings. If the tool reports that the disk is encrypted with BitLocker but the password hash cannot be extracted, you’ll have to either use the Recovery Key or attempt to extract the VMK from TPM.

Extracting Volume Master Key from RAM

If you are able to sign in to the computer, you may attempt capturing its memory image. By analyzing the RAM image with Elcomsoft Forensic Disk Decryptor you may be able to discover the master key and decrypt the volume without any other attacks. This, however, will not be possible if the user specified a pre-boot protector such as an extra PIN code (TPM+PIN). If you attempt to brute-force the PIN, the TPM will panic and lock access to the encryption key either permanently or for a period of time.

While you may prefer live system analysis to capturing the encryption key and decrypting the disk image, offline analysis is significantly more forensically sound even if labor-intensive.

Cold boot and FireWire/Thunderbolt attacks

The fact that TPM releases the VMK at an early stage allows for a quite unique attack often called the ‘cold boot attack. This attack is based on the fact that the computer’s memory chips retain their content for several seconds after being powered off. However, if cooled to sub-zero temperatures, the modules will retain data for much longer. During the cold boot attack, you would start the computer and wait while the system boots up. By the time the computer presents the login prompt, the BitLocker volume would be already mounted, and the VMK decrypted and stored in the computer’s RAM. You would then cool the RAM modules with a commercially available refrigerant spray, immediately remove the modules, install them into the test computer and boot it into a Linux image with LiME kernel extension. You can then dump the memory image and scan it with Elcomsoft Forensic Disk Decryptor for BitLocker encryption keys.

A similar attack is available for older systems running Windows 7 and Windows 8 if they are equipped with a FireWire or Thunderbolt port or a PC Card slot. If this is the case, you can attempt capturing the memory dump with the infamous Inception tool (yes, it’s “that Python tool”). A memory dump made with Inception can be loaded into Elcomsoft Forensic Disk Decryptor and scanned for the master key. The VMK be then used to either completely decrypt the disk image or mount it for faster analysis.

Unfortunately, this method is only available on older systems running Windows 7 or Windows 8. Windows 8.1 already fixes the vulnerability by disabling DMA via Thunderbolt when the computer is sleeping or locked.

The Sleep Mode attack

In 2018, researchers Seunghun Han, Wook Shin, Jun-Hyeok Park, and HyoungChun Kim from National Security Research Institute published a paper named A Bad Dream: Subverting Trusted Platform
Module While You Are Sleeping (PDF). When the computer enters the energy-saving sleep state, the TPM saves its PCR registers in NVRAM, and restores them when the computer wakes up. The researchers discovered that, at this brief moment, the PCR registers can be manipulated, thus reading the chain of trust or modifying its content. The researchers notified major motherboard manufacturers such as Intel, Lenovo, Gigabyte, Dell, and hp, who in turn patched the vulnerability in BIOS updates. However, since few users install BIOS updates, there are many computers still vulnerable to this exploit.

Seunghun Han released two tools: Napper for TPM and Bitleaker. The first tool can be used to test the computer’s TPM chip for the “Bad Dream” vulnerability, while the second tool is the actual exploit one can run if the TPM module has the unpatched vulnerability.

The second tool requires manually creating a Live CD with Ubuntu, compiling and installing Bitleaker according to the manual. You will need to disable Secure Boot to run the tool. The alternative way would be signing the modified bootloader and kernel with your signature and adding the public key to BIOS; this, however, defies the purpose as it alters the content of PCR registers.

Intercepting TPM signals

TPM modules are connected to the computer via the LPC (Low Pin Count) bus. This bus is used to carry data between “slow” devices, such as the serial ports. It operates at the frequency of 33 MHz. Denis Andzakovic claims that, by default, Microsoft BitLocker protected OS drives can be accessed by sniffing the LPC bus, retrieving the volume master key when it’s returned by the TPM, and using the retrieved VMK to decrypt the protected drive.

For TPM 1.2, he used the DSLogic Plus logic analyzer with USB interface. However, he found it to be far from perfect for sniffing TPM traffic as he had to solve synchronization problems and even patch the firmware. However, he was able to successfully extract the VMK from the TPM module.

Sniffing TPM 2.0 was way easier with a cheap FPGA Lattice ICEStick and a specal firmware designed for sniffing TPM modules.

All he needed to do was soldering the pins, enabling the sniffer and obtaining the master key. More on that in Denis’ original article. Note that desktop motherboards with add-on TPM chips are even easier to sniff with no soldering required.

This method works in BitLocker’s default configuration. If the user enables pre-boot authentication with a PIN code, the PIN code will be required to make TPM release the VMK. This method will not work for Intel PTT as there is no physical access to the module’s interface.

FPGA Lattice iCEStick:

Connecting to the TPM chip:

Conclusion

Combined with TPM, BitLocker enables secure protection against unauthorized access. Despite the fact that the TPM chip itself does not do encryption, gaining access to the encryption key is not an easy task. I described a number of methods that can be used to extract the encryption keys from the TPM module. Even if you never use any of them, they are certainly worth being part of your arsenal.

2020 in Review: What Was New in Desktop and Mobile Forensics

Mon, 28 Dec 2020 08:54:36 GMT

This year is different from many before. The Corona pandemic, the lack of travel and canceled events had changed the business landscape for many forensic companies. Yet, even this year, we made a number of achievements we’d love to share.

iOS Acquisition

Our major achievement this year is about the iPhone extraction. For the first time, we’ve been able to achieve a jailbreak-free extraction of a 64-bit iPhone. We started slow, only supporting devices running iOS iOS 11-13.3. Throughout the year, we continued adding support for all the other versions of iOS. Fast forward today, we support jailbreak-free iOS Extraction for iOS 9 through iOS 13.7 on all devices that can run these versions of iOS (up to and including the iPhone 11 Pro Max).

Jailbreak-free file system extraction and keychain decryption

How did we do the extraction without the need to jailbreak the phone? We developed an app that you have to sideload onto the phone or tablet being extracted. When launched, the app automatically detects the presence of known vulnerabilities in iOS, runs the exploit and obtains root-level access. Once this is done, the app establishes a communication channel with the computer that has iOS Forensic Toolkit running.

With root privileges, the app can access the file system in the low level, enabling iOS Forensic Toolkit to image the full content of the device. In addition, the app extracts the encryption keys protecting keychain records, and decrypts the entire content of the keychain including records protected with the highest protection class.

Since the extraction app does not have to do things that users expect of a jailbreak (such as running unsigned apps or featuring a third-party app store), the app is extremely small and unobtrusive. It does not remount the file system or modifies the system partition and uninstalls cleanly. The only traces left on the device after using the extraction agent are a few log entries in the system log files.

Last but not least, we made it possible for macOS users to sideload the extraction agent without using a developer’s Apple ID account.

iPhone 5 and 5c passcode unlock

Back in 2016, the FBI paid more than $1.3 million to an unnamed contractor for unlocking the iPhone 5c that was used by the terrorist after the shooting in San Bernardino in December 2015. In August 2020, we released a tool to help experts with iPhone 5 and 5c unlocks at a fraction of the cost.

iOS Forensic Toolkit runs a brute-force attack against the screen lock password, trying 13.6 passcodes per second on the device. With this speed, 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. We have several tricks to cut this time; read the original article to learn more: iPhone 5 and 5c Passcode Unlock with iOS Forensic Toolkit.

iCloud Acquisition

Our logical and cloud acquisition tool, Elcomsoft Phone Breaker, also received its share of updates, gaining iOS 14 support for local and cloud backups as well as iCloud synced data. Elcomsoft Phone Breaker remains the only tool on the market that can deal with Apple’s point-to-point encryption protecting the user’s passwords in iCloud Keychain and encrypting Health, Messages, Safari history and similarly sensitive data.

Elcomsoft Phone Viewer can now display Telegram secret chats.

The tools mentioned above are parts of Elcomsoft Mobile Forensic Bundle, which remains our top selling product for extracting and analyzing data from a wide range of mobile devices and cloud services. Integrating everything we make in the area of mobile forensics, Mobile Forensic Bundle offers a hefty discount compared to the purchase of individual tools. If you still haven’t, check out the Bundle and see if you can save by upgrading your individual licenses to the bundle deal.

Breaking Passwords

ElcomSoft breaks passwords. While password recovery news is not the most exciting reading, we are still proud of our achievements. GPU acceleration, asynchronous and hybrid hardware acceleration, distributed and cloud computing are just a few technologies pioneered by our company.

Thirteen years ago, we were the first to accelerate password attacks with consumer-grade video cards. “PESKY RUSSIANS have come up with a novel way of using Nvidia’s graphics hardware – cracking passwords”, wrote The Inquirer at the time. The GPU-based hardware acceleration technology had matured over the years. In 2020, we’ve added support for the newest and fastest graphic processing units based on the latest NVIDIA Ampere architecture. The RTX 3000 series boards deliver unprecedented performance, which nearly doubles the speed of password attacks compared to the previous generation of NVIDIA boards.

This year also brought Hancom Office and iWork 2020 v10 support, the ability to break LUKS encryption, and constructor-style support for John the Ripper syntax. John the Ripper interactive rule syntax allows making extremely flexible attacks that can combine words from up to two dictionaries with numerous modifications to any parts of the password. These rules can be used to design attacks based on existing passwords retrieved from the user’s computer or cloud service.

The most exciting part, however, was the discovery of flawed data protection in Tally ERP 9 Vault and the ability to break encryption in VMWare, Parallels, and VirtualBox virtual machines. We learned that the three vendors, all advertising industry-standard AES encryption, are worlds apart when it comes to the real security of encrypted information. The recovery speed of some 19 million passwords per second we achieved when attacking Parallels VMs is unprecedented and unheard of in 2020. The speed of 15 passwords per second sounds much better and offers, literally, a million times greater protection if you go with VirtualBox instead.

Cold System Analysis Streamlined

During the year, we worked hard to streamline cold system analysis. In cold system analysis, one can boot the target computer from a USB flash drive, and do things that can save many hours of work. What kind of things? Extract encryption metadata from various encrypted disks. Find encrypted virtual machines and extract encryption metadata to run a subsequent attack. Create forensic disk images without taking the disks out. Reset SYSKEY passwords. Or simply reset Windows account passwords to gain access to the system and continue with live system analysis.

Elcomsoft Distributed Password Recovery, Elcomsoft System Recovery, Advanced Office Password Recovery and many other tools are included in Elcomsoft Desktop Forensic Bundle. The Bundle delivers all password recovery tools in a single value pack, allowing to unlock documents, decrypt archives, break into encrypted containers, perform forensically sound cold system analysis and access Windows accounts by booting with a flash drive.

Our Research

We are active researchers. Our publications range from walkthroughs and guides to research articles discussing the vulnerabilities in data protection we’ve discovered. We wrote a guide on protecting iMessage communications and another article about iPhone anti-forensics. We discovered vulnerabilities in Synology NAS systems and Tally ERP Vault. We wrote many more articles in our blog, contributing to the forensic society and educating consumers about the best practices in IT security and personal data protection.

NAS Forensics: QNAP Encryption Analysis

Wed, 23 Dec 2020 11:37:22 GMT

A year ago, we analyzed the encryption used in Synology NAS devices. We were somewhat disappointed by the company’s choice to rely on a single encryption layer with multiple functional restrictions and security reservations. Today we are publishing the results of our analysis of data encryption used in QNAP devices. Spoiler: it’s very, very different.

Home users and small offices today are served by two major manufacturers of network attached storage devices: QNAP and Synology. Both companies advertise support for hardware-accelerated AES encryption, yet the implementation is very different between the two brand. While Synology, in its home and small office models at least, relies exclusively on per-share, file-based encryption via eCryptFS, QNAP tends to favor volume-based encryption. Yet, things aren’t all black and white, as QNAP also offers folder-based and SED encryption in many (but not all) models. In this research, we’ll be discussing the types of encryption used in QNAP NAS devices.

Supported Encryption Types and Applicable Hardware

The majority of current QNAP NAS devices support at least one type of encryption, while certain types of devices support layered protection with several types of encryption. These encryption layers include:

Self-encrypting drive (SED). SED encryption support is available in select QNAP models, providing hardware-based encryption for hard drives with encryption support. SED encryption can be used on individual drives as well as on multiple drive storage pools, enabling the creation of fully encrypted storage pools. SED encryption is the lowest encryption layer. In QNAP devices, SED works on the Storage Pool level. The use of SED encryption does not affect performance, yet its scope of protection is limited.
Volume encryption. This type of encryption is available in most QNAP models. Volume encryption is software based; it works on the level of individual volumes. Volume encryption can protect single-disk and static volumes as well as volumes located on multi-disk storage pools. Volume encryption does affect the performance, albeit the effect is relatively minor.
Folder-based encryption. This is the same kind of encryption we’ve seen in Synology, and analyzed in Forensic Analysis of Synology NAS Devices. The implementation of folder-based encryption in QNAP is somewhat less comprehensive compared to Synology’s; we’ll cover the differences in the corresponding chapter.

SED Encryption

A self-encrypting drive (SED) is a drive with encryption hardware built into the drive controller. Select QNAP models support self-encrypting drives, allowing to set up a SED secure storage pool that only contains SED hard drives with hardware encryption enabled. SED is the perfect first layer of encryption. Unfortunately, we could not test SED encryption with the QNAP TS-453Be due to the lack of a spare self-encrypting drive.

Note that SED encryption applies on the Storage Pool level (such as single disk/RAID/JBOD etc.) Logical volumes created on regular or SED volumes can feature additional software encryption.

According to QNAP documentation, the system allows saving the SED encryption key, which enables the system to automatically unlock and mount the SED pool when the NAS starts up. If the encryption key is not saved, the user must specify the encryption password every time the NAS restarts. QNAP warns users that “Saving the encryption key can result in unauthorized data access if unauthorized personnel are able to physically access the NAS.”

Volume Encryption

Volume encryption is the default encryption type available in most QNAP NAS devices equipped with either Intel or ARM processors. Volume encryption locks the entire volume, which in turn may be located on a single disk or multiple-disk storage pool, including a SED secure storage pool as a second encryption layer.

Volume encryption: executive summary

QNAP implements volume-based AES encryption with a 256-bit key length. The encryption provider is standard Linux cryptsetup (LUKS); however, QTS wraps user-provided passphrases to turn them into LUKS keys with a tool named storage_util that likely does not have a Linux equivalent. The encryption key is produced based on the user-provided passphrase. Users can change the encryption passphrase at any time. A 256-byte encryption key file can be produced and downloaded while setting up encryption or at any time later (the user will be prompted for the passphrase). Users can unlock encrypted volumes by either typing the original plain-text password or by uploading the exported key file through the QTS user interface. QNAP provides means for storing encryption keys on the NAS in a “secret location” (presumably, on the built-in DOM storage). We have not searched for stored encryption keys, although this could be possible by analyzing the content of the DOM storage.

Implementation: cryptsetup (LUKS); proprietary tool (storage_util) for wrapping the passphrase (must be run on a QNAP device, not necessarily the one used to create an encrypted volume).

Encrypting existing data: not supported. Users can encrypt new volumes only.

Decrypting encrypted volumes: not supported. Volume must be re-created from scratch.

Revoking compromised keys or changing leaked passwords: supported. If an encryption key is compromised, users can simply change it from the user interface. In our tests, the change of an encryption key requires unmounting and re-mounting the volume, which took around 5 minutes on our test system.

Encryption key: plain-text passphrase (wrapped with a QNAP proprietary tool) or 256-byte key file (must be manually exported).

Potential vulnerabilities: encryption key can be stored on the NAS device for automatically mounting volumes on startup. If this is the case, the encryption key may be extracted from the NAS device and used to access the data. Note that, unlike Synology, QNAP does not offer the ability to store the encryption key on an external USB device. The usual warning “Saving the encryption key can result in unauthorized data access if unauthorized personnel are able to physically access the NAS.” applies.

Locking the encrypted volume is possible from the user interface. Surprisingly, locking an encrypted system volume in our tests was never instant. Instead, the locking process always took several minutes (!) to complete. A percentage bar is displayed during this procedure to allow users to monitor the process. This could do with the encrypted volume being the only volume in the system, hosting the many Qnap system apps and services.

The encryption key can be downloaded and saved into a file with the .key extension. The file size is 256 bytes. This file can be used to unlock the volume should the user forget their password. We verified that the content of the key file is different after the user changes the encryption password. However, since the content of the key file is different even if the user saves it twice without changing the password, it is difficult to judge whether the system uses the same or different encryption keys after the password is changed.

Unlocking the volume is possible by providing either the original password or uploading the encryption key.

Unlocking the encrypted volume is also far from being instant. The process, once initiated, takes several minutes (about 5 minutes on our QNAP TS-453Be). Being as slow as it is, locking and unlocking volumes is obviously not considered part of the users’ everyday routine (or it might be the case of poor optimization). Either way, it’s slow. Very slow.

Changing the encryption password is possible via the user interface, albeit it is just as slow as everything else about encryption. While changing the password, users have an option to save the encryption key onto the NAS device (allegedly the built-in DOM storage). By saving the encryption key, the NAS can automatically unlock the volume on startup without prompting the user for the encryption key.

On our test system, it took approximately 4 minutes of “Applying, please wait” until the password was actually changed. It appears that, in the background, the NAS was locking the volume (which takes around 5 minutes), then changing the password. After the password change operation, the volume would be in the locked state. Unlocking the volume takes another 5 minutes, so based on this performance the users are unlikely to change their passwords often.

Volume encryption: technical details

QNAP relies on the tried and proven LUKS standard and uses AES-256 encryption. A step by step guide is available for Mounting QNAP encrypted volumes if the password is known.

It is important to note that QNAP encodes (wraps) user-provided passwords before they can be used with cryptsetup. This in turn means that you will need access to a QNAP NAS device (not necessarily the same device that was used to encrypt the volume) in order to encode (wrap) the passphrase. The following command is used to encode the passphrase (must be executed via SSH on a QNAP NAS device):

/sbin/storage_util --encrypt_pwd pwd=YOUR_PASSWORD

The system will return the encoded version of the password:

Encrypted passwd is: …………………………………..

You can then use the resulting encoded string as the passphrase for cryptsetup luksOpen, which can be executed on a QNAP NAS or on a Linux computer.

cryptsetup luksOpen /dev/mapper/cachedev1 myencrypteddisk

Alternatively, you can encode the password into a key file:

/sbin/storage_util --encrypt_pwd pwd=YOUR_PASSWORD > /tmp/keyfile.key

You can then use the key file to mount the encrypted volume with cryptsetup luksOpen.

cryptsetup -v luksOpen /dev/mapper/cachedev1 ce_cachedev1 --key-file=/keylocation/keyfile.key --key-slot 0

There are multiple discussions on the QNAP Community Forum with additional hints and instructions:

Folder Encryption

In addition to volume encryption, QNAP NAS models based on an Intel processor additionally support per-share file-based encryption. The implementation is very similar to that used by Synology and Asustor.

Encrypted folders can be created on regular volumes as well as on encrypted volumes, delivering an additional layer of protection. QNAP allows encrypting existing folders, as well as permanently decrypting encrypted ones.

Folder encryption: executive summary

QNAP 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 can be produced and downloaded while setting up an encrypted folder or at any time later (the user will be prompted for a password). Users can unlock encrypted volumes by either typing the original plain-text password or by uploading the exported key file through the QTS user interface. QNAP provides means for storing encryption keys on the NAS in a “secret location” (presumably, on the built-in DOM storage). We have not searched for stored encryption keys, although this could be possible by analyzing the content of the DOM storage.

Note 1: only Intel-based QNAP devices support folder-based encryption.

Note 2: the ability to encrypt shares located on encrypted volumes is relatively new to QNAP. QTS 4.3.5 release notes mention that “Shared folders on an encrypted volume cannot be encrypted. For details, see Volumes.” This is no longer the case, and shared folder on an encrypted volume can be encrypted, which we will demonstrate.

Implementation: eCryptFS.

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 not utilized in this implementation; as a result, users cannot change their encryption password (aside of fully decrypting and re-encrypting the share).

Potential vulnerabilities: encryption key can be stored on the NAS device for automatically mounting encrypted folders on startup. If this is the case, the encryption key may be extracted from the NAS device and used to access the data. Note that, unlike Synology, QNAP does not offer the ability to store the encryption key on an external USB device. The usual warning “Saving the encryption key can result in unauthorized data access if unauthorized personnel are able to physically access the NAS.” applies.

Folder encryption can be activated when creating a folder or at a later time.

Users can download the binary encryption key for backup purposes. The encryption key file is saved as “foldername_keyfile” without an extension, and contains 256 bytes of data. Saving another copy of the encryption file produces a file with different content.

Users have an option to mount encrypted folders automatically on startup; the feature is available under the “Save” tab. Note that the corresponding check box is selected by default, which means that newly created encrypted folders will have their encryption keys stored somewhere on the NAS device by default.

If the user unticks the check box, the next time they open the “Save” tab, the system will prompt for the password in order to save the encryption key.

Users can manually lock and manually unlock encrypted folders, which is near instant. Once locked, unlocking the encrypted folder is possible by either providing the encryption password or uploading the encryption key file.

QNAP folder encryption uses the familiar encrypting file system eCryptFS, which is also utilized for similar tasks in Synology and Asustor NAS devices. QNAP’s implementation therefore has similar restrictions, some of which are displayed in the warning message when users encrypt share folders.

What is not mentioned, however, is the typical eCryptFS restriction on the length of file names. Compare that to Synology’s warning message:

We tested file names of different lengths, and discovered that the same naming restrictions apply. You cannot use file names longer than 143 Latin characters or 47 CJK characters.

Instructions on mounting eCryptFS shares are available in our Synology and Asustor articles, as well as on QNAP user forums.

Multi-Layer Encryption Performance

As mentioned above, Intel-based QNAP NAS devices enable layered protection by allowing t0 encrypt shared folders on encrypted volumes, which may in turn be stored on a SED-encrypted storage pool. We tested the ability to access an encrypted share on a locked volume by attempting to unlock the share. This worked as expected (or, rather, it did not work, just as we expected). An attempt to access a folder on a locked volume failed even though the correct password (for the encrypted folder) has been specified.

This proves that QNAP NAS devices do indeed have effective layered protection.

How does this two-layer encryption affect performance? We tested read and write performance using a single gigabit connection.

Writing a single large file to an encrypted share on an encrypted volume resulted in the performance of about 95 MB/s, peaking at 100 MB/s. Read performance was roughly 94 MB/s, peaking at 96 MB/s.

Writing to an unencrypted folder on the same encrypted share resulted in 107 MB/s writes and 95 MB/s reads.

Finally, writing to an unencrypted folder on an unencrypted volume resulted in 115 MB/s writes and the same 96 MB/s reads.

Conclusion

QNAP implements layered protection, allowing to protect against various threats by selectively activating the required encryption layers. Self-encrypting disk (SED) encryption effectively protects data in an event a hard drive needs warranty service, and enables instant secure destruction of the data. Volume encryption achieves a similar purpose in multiple-disk configurations and/or when SED is not available on given hardware. The final layer, folder-based encryption, protects data on per-share or per-user basis, enabling administrators to produce encrypted backups of encrypted folders without passing (or even knowing) the user’s encryption passphrase.

iPhone Backups: Top 5 Default Passwords

Tue, 22 Dec 2020 07:09:58 GMT

The iPhone backup is one of the hottest topics in iOS forensics. iTunes-style backups are the core of logical acquisition used by forensic specialists, containing overwhelming amounts of evidence that is is unrivaled on other platforms. The backups, as simple as they seem, have many “ifs” and “buts”, especially when it comes to password protection. We wrote a thousand and one articles about iOS backup passwords, but there is always something fresh that comes out. Today we have some new tips for you.

The “iTunes” Backups

Although there are several methods for extracting data from an iPhone, iOS backups remain the main source of evidence. Pulling a backup from the device is nearly always possible regardless the iPhone model and iOS version, but only if the device is unlocked or you can unlock it. We published several dozen articles on iTunes backups, and if you are not familiar with this topic, I recommend you to start with The Most Unusual Things about iPhone Backups; I bet you are going to learnt something new.

We put the term “iTunes” in quotes simply because there is no iTunes in macOS anymore starting with macOS Catalina (same for macOS Big Sur). In these new versions of macOS, backups are created via Finder. There is no difference in the data acquired from the device regardless of whether you use Finder or the old iTunes app.

Most forensic packages avoid using the term “backup”. Instead, they prefer to call it “logical acquisition” or “logical extraction”, sometimes “advanced” or “extended”, and sometimes even “method N”. In contrast to Android logical extraction, everything is much simpler with iPhones. The logical advanced/extended acquisition/extraction (whatever they call it) may include the following data:

General device information (model, name, and some other parameters)
The backup (iTunes-style)
Media files (photos, videos, and music, including some metadata)
Shared files
Diagnostics logs

And that’s about it. The backup is usually the major source of evidence that includes most of the data from the device.

The Backup Password

As we have already explained, backups are often protected with passwords. There are two separate issues there:

If a backup password has been configured by the device owner and you do not know it, this is a problem.
If a backup password is not set, you will need to set it yourself.

Both issues need an explanation. But let’s review the changes made by Apple regarding the backup passwords first:

iOS prior to and including iOS 9.x: the password can be effectively attacked
iOS 10.0: weak backup password, implementation flaw, very fast attacks
iOS 10.1: vulnerability fixed, back to iOS 9 level of protection
iOS 10.2: very strong password encryption, extremely slow attacks
iOS 11: made it possible to reset backup passwords in Settings (with some consequences)
iOS 13: changing the backup password requires the passcode

The problem is that password-protected backups contain more data than ones without password. Speaking of the keychain, even if the keychain records are always there, we can decrypt them from a backup only if the password is set and known.

Long story short: if no other extraction options are available and you can only pull a backup, you need the backup password to be set (and known).

The Backup Password II

Back in 2016, we realized that if a backup password is not set, we just need to set it ourselves, pull the data, and remove the temporary password in the end. See our historical iOS Logical Acquisition: The Last Hope For Passcode-Locked Devices? article, in particular:

We know how to deal with encrypted data. If no backup password is set, the keychain will remain securely encrypted with an unbreakable hardware key. For this reason, we’ll automatically set a temporary password (“123”) when acquiring devices without a backup password. (We’ll reset it back after extraction.) This allows decrypting keychain data that would otherwise remain inaccessible.

Secure Enclave introduced in 64-bit devices (iPhone 5s, 6/6s/Plus) effectively locked us out, blocking access to the hardware key regardless of jailbreak status. As a result, the physical acquisition process can extract but cannot decrypt the keychain, while keychain data backed up without a password remains similarly inaccessible.

We addressed this issue by making iOS Forensic Toolkit set a temporary password (“123”) when performing logical acquisition. After the extraction, the password is reset to its original state. Since password-protected iOS backups allow access to keychain, you can successfully decrypt keychain data by using that password.

There is actually more than that – in every new iOS version, Apple puts more data into password-protected backups only (such as Safari browsing history, Health records etc).

Backups in macOS Big Sur

We try to track every change in the backup engine, mostly on iOS devices but not on the host system (Windows or macOS). In macOS Big Sur, backup encryption options are really confusing:

If you switch to the local backup, you now get the following:

Use iOS Forensic Toolkit instead (if you are doing backup extraction), and we will take care of the backup password on our end to make sure you get most of the data available.

Default Backup Passwords

Following our example, other mobile forensic vendors started to set temporary backup passwords. And that’s a good move.

Here are the default backup passwords set by various forensic packages (including ours):

Elcomsoft iOS Forensic Toolkit: 123
Cellebrite UFED: 1234
MSAB XRY: 1234
Belkasoft Evidence Center: 12345
Oxygen Forensic Detective: oxygen
Magnet AXIOM: mag123

If you are analyzing a password-protected backup acquired with so-called “logical acquisition” and have no idea what the password is, try one from the list first. If it does not work, you can also try the device passcode (you should know it) or the password to Apple ID (surprisingly, it often works).

Recovering Backup Passwords

What if the backup password is not the default one, and it has been set by the device owner? We have a comprehensive guide The Four Ways to Deal with iPhone Backup Passwords. If you have no choice but try to break it, we’ve got good news for you: now you can do it much faster with NVIDIA RTX 3080 or 3090. Still, for iOS versions 10.2 and newer, the maximum backup password cracking speed we were able to achieve is only 350 passwords per second. Compare that with more than 220 thousand passwords per second for older iOS versions! It is much better than just a few passwords per minute on an Intel CPU, and allows to crack at least short and simple passwords in a reasonable time: 7 digits, or 6 letters in a single case, or 5 mixed-case letters and numbers.

New Privacy Features: iOS 14.0 through 14.3

Fri, 18 Dec 2020 10:17:59 GMT

Apple has long provided its users the tools to control how apps and Web sites use their personal data. The release of iOS 14 brought a number of new privacy features, while iOS 14.3 adds an important extra. At the same time, one of the most interesting privacy features is facing tough opposition from a group of digital advertising associations, making Apple postpone its implementation.

Approximate Location

This feature enables users to share only their approximate location rather than their exact location with those apps that don’t require precise location data. According to Apple, this feature is targeted to apps such as like local news or weather; however, it is more likely to restrict apps that are using embedded tracking SDKs to collect information about the users.

How approximate is the approximate location? Apple had told that the location data is provided within 10 square miles, which falls into a circle with a radius of about 3 kilometers.

Enabling Approximate Location

Users can change their opinion about sharing location data at any time, retroactively enabling or disabling approximate location for individual apps through the Settings app. To do so, open the Settings app and Privacy – Location Services. Make sure that Location Services are turned on, then scroll down the list of apps. Tap on the app you want to configure, then check out the Precise Location switch. If you want to limit the app to only access your approximate location, make sure that switch is in the Off position.

Make sure to choose apps that can access location data wisely. Google Maps require precise location, as well as any navigation app. Local news, weather, and social apps can work perfectly with an approximate location only. Many casual games, calculators, photo editing apps and so on don’t have a valid cause for requesting the location permission at all, and should be denied such requests if prompted.

Controlled Access to Media Files

iOS 14 users can now control which media files are accessible to specific apps. This new privacy feature enables users to limit the number of photos the app has access to, instead of the binary switch allowing or disallowing access to the entire media library.

Apps that may need access to the entire media library may include cloud synchronization apps such as Dropbox, Google Photos or OneDrive. Many social networks and a random AI-powered emoji editor might be restricted to the one photo you want to upload or turn into emoji.

Interestingly, while Apple restricts local access to photos on the device, the company scans photos uploaded to iCloud for abusive images. “Apple chief privacy officer Jane Horvath, speaking at the Consumer Electronics Show in Las Vegas this week, said that this is the way that it’s helping to fight child exploitation, as opposed to breaking encryption.” [Naked Security]

Other companies do it as well. Microsoft, Google, Verizon, Twitter, Facebook and Yahoo scan their users’ uploads for illegal materials. Facebook’s November 2020 transparency report indicates that “the volume of content restrictions based on local law increased globally 40%”, which may indicate subsequent growth of such content scanning practices in near future.

The Clipboard Fix

Since the release of iOS 14, users have been wondering about the new pop-up notification appearing on top of the display about apps accessing the iOS clipboard. This new prompt warns the user that the app had accessed the clipboard. The warnings are the result of the recent discovery made by Talal Haj Bakry and Tommy Mysk and described in Precise Location Information Leaking Through System Pasteboard. The researchers claim that some 53 App Store apps, including the controversial TikTok app, are constantly monitoring the content of the system clipboard for no apparent reason.

The scope of the problem is increased by the fact that nearby devices sharing the same Apple ID, including macOS computers, may be exchanging data through Universal Clipboard.

The clipboard may contain a lot of different types of data such as text, URLs, pictures (complete with EXIF metadata and location tags, as pinpointed in the abovementioned research), two-factor authentication codes, and other information that the user would not be willingly sharing with dubious apps.

Apple publicly denied the problem, claiming that this behavior is expected. However, in iOS 14, the company had introduced a new API allowing developers to check the type of data stored in the clipboard without accessing the data itself. If developers use this new API, the warning will not show up.

In our view, this implementation is a good tradeoff between convenience and security. On the one hand, the company took action. On the other, the company made it difficult for the users to ignore the problem: the prompts are just annoying enough to make the user pay attention and take an action.

Camera and Mic Activity Indicators

The new feature enables users to see when the phone’s camera or microphone are in use. A recording indicator appears at the top of the screen when the camera or microphone are used. Users can review applications that used the camera and mic in the Control Center.

A green dot indicates that the camera is activated; an amber dot shows that the microphone is in use. About the orange and green indicators in your iPhone status bar – Apple Support:

There is one important exception to this rule. When Siri is configured to work in background, waiting for the activation word, the orange dot does not appear even when the microphone is. However, the orange dot will be lit if another app will start using the mic. This is expected behavior as constantly displaying the orange dot while Siri is listening for an activation word would defy the purpose of the indicator.

The trend to prominently show the status of the camera and microphone is nothing new. All recent Macbooks have a feature that disconnects the microphone when the lid is closed (Apple’s 2018 MacBooks come a chip that protects against eavesdropping). Many smart devices such as Google Nest Hub Max or the new Facebook Portal feature physical disconnection switches as opposed to software buttons allowing to disable the possibility for eavesdropping. Ideally, we’d love to see this feature implemented as a dedicated LED indicator.

Upgrade to Sign in with Apple

“Sign in with Apple” is yet another take in the crowded space of single sign-on services. Alternatives include Google, Facebook and Microsoft accounts as well as countless wannabees from all over the world. Apple’s implementation has both advantages and disadvantages that are outside the scope of this article. The company pushes the increased level of security and confidentiality compared to providing a real email address and possibly reusing the same password over multiple online accounts.

Access to Local Networks

Some apps require local network access the first time you launch them. This access may be required to locate and identify Bluetooth devices or scan the local network for available shares. In many cases, however, this access is not required for the app’s main functionality, and is abused for the sole purpose of profiling. iOS 14 adds a prompt saying that the app would like to find and connect to devices on your local network.

Enable Encrypted DNS

A reddit.com user u/kukivu discovered the following new privacy feature in iOS 14, which was announced at 9.50 in the following video: Enable encrypted DNS – WWDC 2020 – Videos – Apple Developer

According to the user, iOS 14 will detect that some DNS queries are blocked in your network and your Wi-Fi network will be tagged with a Privacy warning (that your network is monitored by a third party).

More about the new warning at IOS 14 Privacy features – If you filter DNS queries, your network may be tagged because of pfSense

Local Contact Autofill

When filling in certain fields such as the name, address and email, iOS 14 users will no longer need to “share” a contact. Instead, users can simply pull the contact name from the local address book, and the system will automatically fill in the rest of the fields. The autocomplete function works locally on the device.

Local Voice Recognition

Voice recognition when dictating using the built-in keyboard now occurs locally on the device. Compared to English-only offline dictation feature found in iOS 13, iOS 14 brings support for a number of additional languages; however, the new functionality requires an iPhone Xs or newer.

Support for APFS Encrypted Volumes

The Files app introduced in iOS 11 can now access external drives protected with APFS encryption. Users will be able to unlock encrypted drives with a password. The new feature is mainly targeted to iPad Pro models equipped with a USB Type-C port, but the functionality is available through the entire range of iOS devices.

Safari: Privacy Report

Safari users can now check how Web sites track their behavior. One can view information both for an individual website and for each specific tracker. This kind of analysis was previously available on certain platforms in third-party ad blockers.

We highly welcome this feature as it allows users to see the extent to which they are being tracked.

Safari: Unsafe Password Detection

Similar to competition, Safari offers users the ability to store authentication credentials. While using a strong and unique password for every online account is a well-known and highly recommended practice, few users follow it to the letter. Studies show that some 67% of consumers reuse passwords across multiple accounts, with little incentive of changing unsafe passwords.

The new feature in iOS 14 will periodically check stored passwords for unsafe entries. Unsafe entries are defined as duplicate (or even similar) passwords; passwords that are too simple and easy to guess; and leaked passwords. The check for leaked passwords is compared on the hash level (the real password is never leaving the device).

The new feature is on by default. You will receive periodic notifications if any of your passwords are found unsafe. You can check the status of the new feature by opening the Settings app and tapping Passwords – Security Recommendations and checking out for duplicate passwords or passwords that are too easy to guess. The separate Detect Compromised Passwords toggle enables checks of your password hashes against a database that contains hashes of leaked passwords.

iOS 14.3: App Store Privacy Labels

With the release of iOS 14.3 on December 14, 2020, Apple has finally introduced the App Store privacy labelling feature that was announced early with the original release of iOS 14 but was postponed to a later date. The new feature required app developers to submit information about what data an app collects and how that data is being used in its App Store listing.

Announced at Worldwide Developers Conference 2020 back in June, the App Store privacy labeling feature enables users to see what types of data will be collected by the app and how the developers are going to treat that data. Whether it’s location data, access to contacts or access to the device’s unique identifier, developers must disclose that information in the App Store listing.

App Tracking Privacy Controls

The feature would require publishers to display a prominent prompt asking the users if they agree to be subjected to tracking. Technically speaking, this prompt would authorize the release of the device’s unique advertising identifier. The use of a unique identifier enables the developers of advertising SDKs such as Facebook or Google to track the user across various apps and Web pages.

Jason Atin from Inc.com in Why Facebook Is Very Worried About Apple’s iOS 14 believes that Facebooks fears are not just about the potential short-term loss of revenue. The advertiser’s main fear is that users, if given a chance, will block the ability for Facebook to track their activity.

After facing tough opposition from advertisers, Apple decided to Delay iOS Change Roiling Mobile Ad Market. According to The Information, “Apple plans to delay the enforcement of a controversial change to its next mobile operating system that would upend how ads are targeted on iPhones and iPads, according to people familiar with the matter”. In How We’re Preparing Businesses for the Impact of iOS 14, Facebook wrote:

We expect these changes will disproportionately affect Audience Network given its heavy dependence on app advertising. Like all ad networks on iOS 14, advertiser ability to accurately target and measure their campaigns on Audience Network will be impacted, and as a result publishers should expect their ability to effectively monetize on Audience Network to decrease. Ultimately, despite our best efforts, Apple’s updates may render Audience Network so ineffective on iOS 14 that it may not make sense to offer it on iOS 14.

EU advertisers joined Facebook in criticizing new app tracking privacy controls in iOS 14. “According to the report, the group of European marketing firms said the pop-up warning and the limited ability to customize it still carries “a high risk of user refusal””, says Tim Hardwick [MacRumors].

The backlash made Apple postpone app tracking privacy controls. “Apple has told developers that it plans to delay enforcement of a controversial change in iOS 14 that would upend how ads are targeted on its devices”, twitted Alex Heath, The Information reporter. At this time, the new feature is expected to appear in some form in the beginning of 2021.

Even before the new controls are implemented, Mozilla already praises Apple anti-tracking privacy features in iOS 14. “Apple’s planned implementation of anti-tracking features is a huge win for consumers, many of whom might not even be aware that they can be tracked across apps on their phone,” Mozilla wrote of the feature according to Apple Insider. “Now, with the option to opt-out of tracking at the point-of-use, consumers won’t have to sift through their phone’s settings to protect their privacy.” Mozilla, in its campaign, said that consumers and companies need to ensure that Apple implements the feature and doesn’t “kick the can down the road.” [Apple Insider]

Conclusion

The new version of iOS introduced a number of privacy controls. Some of these controls are particularly useful, while some are postponed to a later date. Early next year we’ll see if Apple implements app tracking privacy controls as it originally intended.

Breaking Passwords with NVIDIA RTX 3080 and 3090

Thu, 17 Dec 2020 06:55:15 GMT

Today we have an important date. Advanced Office Password Recovery turned 16. What started as an instant recovery tool for legacy versions of Microsoft Word had now become a GPU-accelerated toolkit for breaking the many Microsoft formats. Today we’re releasing a major update, giving Advanced Office Password Recovery and Distributed Password Recovery tools the ability to crunch passwords faster with the newest and latest NVIDIA 3000-series graphic boards. Powered by Ampere, the new generation of GPUs delivers unprecedented performance in modern video games. How do the new cards fare when it comes to accelerating the password recovery, and is an upgrade worth it for the forensic experts? Let’s find out.

The 3000 series of GeForce RTX graphics processors are based on the second-generation RTX architecture NVIDIA calls “Ampere”. The new adapters require CUDA 11 to enable access to the powerful RT and Tensor computing units and streaming multiprocessors.

The release of the 3000 series suggests that NVIDIA believes in modern games relying heavily on integer math. With the new architecture, we still have the 64 FP32 cores, but another 64 cores are now designated as “FP32 and INT32”, making half the cores capable of doing either floating-point or integer calculations. Since password recovery relies on integer math, we can effectively utilize half the Ampere cores. You can read a tech article about the new Ampere architecture at Engadget.

What does the new architecture mean for the forensic crowd? Effectively, it’s double the speed compared to the first-generation RTX. Elcomsoft Distributed Password Recovery was updated to support CUDA 11 and the new generation of NVIDIA boards, so we finally a few first-hand benchmarks to share. We also added support for Ampere-based cards to Elcomsoft Advanced Office Recovery, which was released exactly 16 years ago.

First, the Microsoft Office format. Here we try breaking a password to a Word 2019 document.

The NVIDIA GeForce RTX 3090 demonstrated the speed of some 25700 passwords per second; the GeForce RTX 3080 is only slightly behind at 22600 passwords per second, which is around 90% of the speed of the RTX 3090. The first-generation GeForce RTX 2070 is practically half the speed at 12000 passwords per second. Our long-time favorite NVIDIA GeForce GTX 1080 is 8370 passwords per second.

Other formats demonstrate similar results. Attacking a BitLocker volume becomes twice as fast:

The speed of breaking a 7ZIP archive is doubled compared to the 2000-series and nearly tripled compared to the GTX 1080:

Recovering password to an encrypted RAR archive follows the suite. 1x (“single speed”) the 1080, 1.5x on the 2070, and 3x (“triple speed”) for the 3090:

Performance per dollar

So we figured that the NVIDIA GeForce RTX 3090 delivers three times the performance of a GTX 1080 when it comes to breaking passwords, and nearly double the performance of an RTX 2070. Should you fetch the wallet and upgrade your cards? Naturally, it depends on your budget. Let us see how the new cards perform relative to their current prices.

The NVIDIA GeForce GTX 1080 is several years old. The price has fallen to around $749.

First-generation RTX boards such as the RTX 2070 can be bought for about $899.

The RTX 3090 is still new, so expect to pay a premium. Currently listed for $2199. The only slightly slower RTX 3080 is “only” $1199.

And the winner is… NVIDIA GeForce RTX 3080! Its performance blows the old GTX 1080 out of the water, while its price is comparable to the first-generation RTX board, the RTX 2070, with nearly double the performance. The RTX 3090 is about 10 to 13% faster than the RTX 3080 at nearly double the price.

If you cannot afford a 3080, the RTX 2070 is still a decent choice, yet no longer the fastest or even cost-efficient. The long-lasting champion, the GTX 1080, can no longer compete. Even if you can order it (which is becoming more difficult as they are no longer stocked by major retailers), you are likely to pay a premium for an old video card.

Performance per watt

The GTX 1080 TDP is 180W. The RTX 2070 has a board power rating of 215W. The RTX 3080 is rated 320W, and the RTX 3090 is 350W. Here, the RTX 3090 is the most efficient, while the RTX 3080 is only slightly behind. The older boards are consuming more power (and dissipating more heat) to perform calculations.

Our take

The RTX 3080, while not being an absolute speed champion, wins as an overall package. This board offers the best performance per dollar when crunching passwords, and dissipates less heat overall compared to the older cards.

We’d like to thank HOSTKEY B.V. for the test equipment. HOSTKEY offers its clients dedicated and virtual server rental services in TIERIII class data centers in the Netherlands (Serverius), Russia (DataPro) and NY1 (USA).

Recovering Screen Time Passwords

Tue, 15 Dec 2020 11:55:34 GMT

The Screen Time password has been long recommended as an extra security layer. By setting a Screen Time password without any additional restrictions, Apple users could easily dodge attempts of changing or removing the screen lock passcode, resetting the iTunes backup password, or removing the activation lock. For a long time, removing the Screen Time password was not possible without either providing the original password or erasing the device. However, Apple had changed the way it works, making it possible to reset the Screen Time password with an iCloud/Apple ID password.

Why Screen Time is important for forensics

Screen Time is a really nice feature that allows keeping track of application usage, limiting the time spent in specific apps and app categories, and doing a lot more, see Use Screen Time on your iPhone, iPad, or iPod touch. At the same time, Screen Time is extremely important for investigations. It’s not just about the app usage analysis that may unveil important evidence. Whether or not Screen Time is enabled, device activities are logged, and can be extracted and analyzed using proper forensic software. It’s the Screen Time password, if one is set and not known, prevents the device settings from being reset.

Why would a forensic specialist need to reset the settings? There are at least two reasons to do that. The first reason is removing the device screen lock passcode, which, in turn, may be required in order to install the checkra1n jailbreak on the iPhone 8, iPhone 8 Plus and iPhone X models with iOS 14, or to perform the direct checkm8-based acquisition available in some forensic products for the same range of devices. We covered this problem (from both sides) in the following articles:

Sometimes, the device passcode cannot be reset due to Apple Pay or third-party configuration settings. If this is the case, the most common solution is to Reset All Settings (which also removes the screen lock passcode), as we described in How to Remove The iPhone Passcode You Cannot Remove.

Another reason to circumvent Screen Time protection is the ability to reset the iTunes backup password. If the Screen Time password is set, accessing the “Reset All Settings” command (the same that is used to remove the screen lock passcode) is blocked until the correct Screen Time password is provided. We described the issue in Using Screen Time Password to Protect iPhone Local Backups. In the course of performing logical acquisition of an iOS device, a password-protected backup may be unbreakable within the required time limits.

Screen Time password recovery

So, what you can do if you desperately need to access the “Reset All Settings” command, but the Screen Time password prevents you from doing so? Several solutions exist, but they do not always work:

There is one option we missed in the above articles simply because it was introduced in iOS at a later time. Specifically, the new option had appeared in iOS 13.4 released in March 2020. Starting with iOS 13.4, you can now reset the Screen Time password through iCloud: If you forgot your Screen Time passcode.

Does it really work? Yes, even better than expected.

Once you set up the Screen Time password (which is optional), you can additionally set up the recovery option via iCloud (also optional).

Why did I say “better than expected”? While we fully expected the feature to work as described if one configured the use of the Apple ID to reset the Screen Time password, we were surprised to learn that you can actually skip that step and get by without entering the iCloud credentials, and… the Screen Time recovery procedure still works. You can test it by enabling the Screen Time passcode and skipping the prompt. Let’s see what happens.

Now open Screen Time and try to change the password, or use any feature that requires the Screen Time password to be entered, but place the device into Airplane mode first. Tap the “Forgot passcode?” link, and… the counter of incorrect attempts will immediately increase:

This is funny; I have not entered anything at all?

OK, let’s connect the device to the Internet and do another try:

Enter the Apple ID and password, and the Screen Time passcode will be reset whether or not you had enabled the recovery option. This means that a Screen Time recovery token, so to speak, is always saved in iCloud. We have seen that before. Apple does save much more data in iCloud than one may believe.

When testing this feature, I once received the following error: “Failed to Provide Apple ID”. I don’t get it. Failed what? And when? What did I do wrong, and how can I make it right?

In conclusion, we finally do have a Screen Time recovery option directly from Apple. And it does work. It does require the user’s iCloud credentials, and that could be a problem if you are doing a forensic investigation: even if you know the user’s Apple ID password, you will need to take the risk of connecting the device to the Internet.

Elcomsoft vs. Hashcat Part 4: Case Studies

Wed, 09 Dec 2020 19:05:01 GMT

This is the final part of the series of articles comparing Elcomsoft Distributed Password Recovery with Hashcat. We’ve already compared the features, the price and performance of the two tools. In this study, we tried breaking passwords to several common formats, including Word document, an encrypted ZIP archive, and a VeraCrypt container. We summarized our experiences below.

Case study 1: breaking an Office 97/2003 document

So you have successfully installed Hashcat, git and Python. Assuming that the Python installer had the required modules, you’re good to go and ready to launch an attack.

In the first case study, we’ll try to break a document in the Office 97/2003 format (the “.doc” extension; the file might have been saved in “Compatibility mode” by a newer version of Microsoft Office). The file is protected with a 40-bit RC4 key.

Hashcat. After processing the document with office2hashcat.py, we’ve got the hash. Hashcat started the attack on the password; considering the (high) speed of the attack, we estimated the attack to complete in about 1 to 1.5 years.

Elcomsoft Distributed Password Recovery correctly recognized the file format and offered an option to brute-force the 40-bit encryption keys. The estimated recovery time was 48 hours using a CPU alone. Note that the same document can be recovered in a matter of minutes if you use the Thunder Tables attack in Advanced Office Password Breaker.

Case study 2: breaking ZIP password

The second case study deals with a ZIP archive protected with AES-256 encryption.

Hashcat requires the use of a third-party tool to extract hashes from the target. This time around, you’ll need zip2john, which is a part of the John the Ripper package.

When attacking ZIP encryption, a single small hash file is not enough. The last step of the attack calculates hash sum of the entire encrypted file. The resulting hash file extracted with zip2john is about 2MB. However, we could not make Hashcat to open the file. The tool had crashed with the following error:

Counted lines in c:\hashcat-6.1.1\z2.hash… Oversized line detected! Truncated 402236 bytes

We tried finding a solution (here and here), but the only kind of solution we found was this:

hashcat supports a data length of about 8 KB (compressed of course) for -m 13600 = Winzip

…

Unfortunately, for -m 13600 you need the whole data_buf (encrypted and compressed data) to verify if the password is correct.

(github)

We’ve been unable to launch the attack on the ZIP file with Hashcat.

Elcomsoft Distributed Password Recovery was able to open that ZIP archive and run the attack in a matter of seconds.

Case study 3: breaking VeraCrypt

In the third case study, we’ll try breaking the password to a VeraCrypt container.

On paper, Hashcat had been offering support for VeraCrypt containers long before we did it in Elcomsoft Distributed Password Recovery, so we expect a well-ironed solution. We didn’t have much trouble running the attack on the hash file extracted from the VeraCrypt container. In this regard, Hashcat is a fast and mature solution for breaking encrypted containers. What we did have a problem with was producing the required hash file to launch the attack.

If you are attacking an encrypted container (the file), all you need are the first 512 bytes of the file. In the case of full-disk encryption, you will also need to extract the 512 bytes; however, the extraction process is somewhat more complicated. The Hashcat Wiki has the following explanation:

for a TrueCrypt boot volume (i.e. the computer starts with the TrueCrypt Boot Loader) you need to extract 512 bytes starting with offset 31744 (62 * 512 bytes). This is true for TrueCrypt 7.0 or later. For TrueCrypt versions before 7.0 there might be different offsets.Explanation for this is that the volume header (which stores the hash info) is located at the last sector of the first track of the system drive. Since a track is usually 63 sectors long (1 sector is 512 bytes), the volume header is at sector 63 – 1 (62).
if TrueCrypt uses a hidden partition, you need to skip the first 64K bytes (65536) and extract the next 512 bytes.

dd if=hashcat_ripemd160_AES_hidden.raw of=hashcat_ripemd160_AES_hidden.tc bs=1 skip=65536 count=512

in all other cases (files, non-booting partitions) you need the first 512 Bytes of the file or partition.

…

The same procedure should also work for VeraCrypt volumes (but you need to adapt the hash mode to -m 137XY – see the –help output for all the supported hash modes for VeraCrypt and the correct values for X and Y).

Additional troubles arise when you try to extract hashes from VeraCrypt volumes stored inside a forensic disk image. If this is the case, you may have to mount the disk image, calculate the address of the last sector of the first track on the disk, then extract the required binary data. We understand the theory but decided to skip this exercise due to lack of motivation.

It is exactly this kind of exercise we wanted to skip when developing Elcomsoft Distributed Password Recovery. In order to extract encryption metadata from one or several encrypted disks, you will need to open the physical device or forensic disk image in the included Elcomsoft Forensic Disk Decryptor (or boot the computer with Elcomsoft System Recovery). Simply ticking the required disk(s) in the GUI will do the trick.

Conclusion

This was the last part of the series comparing Elcomsoft Distributed Password Recovery with Hashcat. As we already stated in the beginning, Hashcat is a great tool and a strong competitor. Many of the differences are in the areas of usability and things actually working, let alone working out of the box. Where Elcomsoft Distributed Password Recovery just works the way you expect it to, you may have to spend a bit of time to make Hashcat work. These bits of time quickly accumulate, turning into multiple man-hours spent on setting up and configuring the distributed network, updating agents, distributing dictionaries across remote agents, finding and using hash extraction tools and overcoming the various obstacles, some of which we have described in this article.

How to Remove The iPhone Passcode You Cannot Remove

Tue, 08 Dec 2020 13:44:36 GMT

From time to time, we stumble upon a weird issue that interferes with the ability to install a jailbreak. One of such problems appearing literally out of the blue is the issue of being unable to remove the screen lock password on some iPhone devices. What could be the reason and how to work around the issue? Read along to find out!

The problem

Why would you even need to remove the passcode that you know? There could be many reasons, but if you are working in the forensics, the most common one is the file system and keychain acquisition.

Note: we do not recommend removing the passcode unless you cannot do without it. This operation has several irreversible consequences that will affect your acquisition result. Still, sometimes removing the passcode is the only way to gain access to the full set of data. Either way, we strongly recommend performing extended logical acquisition first. Pull a backup, even if encrypted; acquire media files via the AFC protocol, and collect diagnostic logs.

If the device is running iOS 9.0 through 13.7, the simplest, fastest and safest way to get the complete file system image is using the agent-based acquisition technique in Elcomsoft iOS Forensic Toolkit. You cannot use this method (yet) with iOS 14. The only way to gain access to the data is jailbreaking with checkra1n or using the direct checkm8-based acquisition available in some forensic packages.

The problem is that certain models (the iPhone 8, iPhone 8 Plus, and iPhone X range) checkra1n/checkm8 only work if the passcode is not set. Hence, you need to remove it first. There are several factors that may prevent you from doing so, and the most common one is MDM (Mobile Device Management), see Passcode MDM payload settings for Apple devices.

However, even if the device is not managed, you might not be able to remove the passcode. When the device is in Airplane mode, the Turn Passcode Off command simply refuses to work in the current version of iOS. If you put the device online (which is also strongly discouraged as the device may be remotely locked or wiped), it simply prompts you for the Apple ID password that is often not known.

One solution may be changing the Apple ID password (it is often possible without the original password, depending on iCloud settings), but it is far from perfect. Alternatives do exist, though, at least in some cases.

The solution

One of the possible reasons of such behavior is Apple Pay. As you may know, Apple Pay requires a passcode to be set, and the removal of the passcode will also remove all payment cards and clear transaction history. We have absolutely no idea why one must sign in to iCloud to reset the passcode when the cards have been set up. Quite possibly there might be some other system components (or may be even third-party iCloud-enabled apps) that prevent the passcode from being removed.

In some cases, however, there are no cards in the Wallet, but the passcode still cannot be removed. What you can try is using the Reset All Settings command. In our tests, it worked just fine in Airplane mode (even without removing the payment cards in advance, as well as in the situations when there are no cards but turning the passcode off does not work).

Note that Reset All Settings not only removes the passcode, but also clears the backup encryption password and all saved passwords to Wi-Fi access points. Also, if the Screen Time password is set, it has too be entered to reset all settings, but that’s another story (see How To Access Screen Time Password and Recover iOS Restrictions Password for possible solutions).

The Evolution of iOS Acquisition: Jailbreaks, Exploits and Extraction Agent

Thu, 03 Dec 2020 06:59:33 GMT

The past two years have become a turning point in iOS acquisition. The release of a bootrom-based exploit and the corresponding jailbreak made BFU acquisition possible on multiple devices regardless of security patches. Another exploit covers the entire iOS 13 range on all devices regardless of their hardware revision. ElcomSoft developed a jailbreak-free extraction method for the entire iOS 9.0-13.7 range. Let’s see what low-level acquisition options are available today, and when to use what.

The bootrom exploit

checkm8 (“checkmate”) is a permanent, unpatchable bootrom exploit for a wide range of Apple hardware installed in millions (if not hundreds of millions) of devices. Affected devices include the iPhone 5s, 6, 6S, SE, 7, 8, the iPhone X, as well as the “Plus” versions of the phones above. In addition, checkm8 is available for other devices based on the same platform. If you are not sure about the meaning of “similar platform”, check out Apple Mobile Devices Cheat Sheet.

checkm8 takes advantage of a vulnerability in the bootrom code on iOS devices, allowing users to gain root access to their iOS device. However, the exploit itself cannot be used easily by the public since it’s missing core components that are commonly included in public jailbreaks. Based on this exploit, the jailbreaking community had developed an all-in-one jailbreak, the checkra1n.

The checkra1n jailbreak has properties never seen in a jailbreak before. First, it’s (mostly) unpatchable: since the bootrom code is hardcoded, it cannot be modified by Apple, and the exploit cannot be fixed with the exception of the iPhone 8/8 Plus/X range running iOS 14.

Use the checkra1n jailbreak in the following cases:

BFU extraction if the device is locked and the passcode is unknown
iOS 14 on iPhone 6s, SE, 7, 8, and iPhone X; note that you’ll have to remove the passcode on the iPhone 8/X devices (passcode must be known)

The Odyssey jailbreak

Odyssey is an open-source jailbreak covering all iOS versions from iOS 13.0-13.7, including A12 & A13 devices (the iPhone Xr, Xs, Xs Max, iPhone SE 2, 11, 11 Pro and 11 Pro Max range). The installation may take several tries with reboots between them; the same applies to the extraction agent due to the nature of the underlying exploit.

We don’t recommend using Odyssey in the forensic extraction workflow. iOS Forensic Toolkit offers agent-based extraction, which delivers identical results with significantly smaller footprint and without the risks associated with jailbreaking.

Use Odyssey in the following cases:

Not recommended
Use agent-based extraction in iOS Forensic Toolkit 6.60 and newer

Other jailbreaks

Other jailbreaks (e.g. unc0ver) also exist, covering almost the entire range of iOS versions. We are expecting unc0ver to be updated with iOS 13.7 support. Does it make sense using any of the “other” jailbreaks? We don’t recommend using jailbreaks for iOS extraction if you want your workflow to remain forensically sound, but you may have no other choice. Agent-based extraction delivers identical results with zero risk and significantly smaller footprint.

Installing jailbreaks typically requires the use of a Developer account or one of the following:

Online installation signed with a leaked enterprise certificate
Via AltDeploy
Via nullximpactor
Via Xcode + iOS App Signer

Use other jailbreaks in the following cases:

Use for iOS versions older than 9.0 (e.g. the iPhone 5s running iOS 7 and 8, iPhone 6 running iOS 8)
Use agent-based extraction in iOS Forensic Toolkit 6.60 and newer for iOS 9.0 through 13.7

The Agent

When it comes to file system extraction and keychain decryption, we used to rely solely on publicly available jailbreaks. We were never happy with this approach as using jailbreaks is far from being forensically sound, while correctly installing some jailbreak requires significant efforts.

Therefore, in the beginning of 2020, we started developing a different method for low-level acquisition. In March 2020, the new method was officially released. This all-in-one extraction method utilizes an extraction agent of our own development. The extraction agent integrates known exploits to escalate privileges, gain access to the file and the encryption keys required to decrypt the content of the keychain. Agent-based extraction provides numerous benefits over jailbreak-based acquisition, being a lot safer, a lot faster, and a lot more robust.

Today, the extraction agent supports the entire range of iOS releases from iOS 9.0 all the way through iOS 13.7 with no gaps or exclusions, for all generations of Apple hardware capable of running these versions of iOS.

The extraction agent requires using an Apple Developer account (why?), yet macOS users can use a regular Apple ID.

We recommend using the iOS Forensic Toolkit extraction agent for all extractions if the device runs a compatible version of iOS and you know the screen lock password.

Use iOS Forensic Toolkit extraction agent in the following cases:

For all devices running iOS 9.0 through 13.7
Apple Developer Account required (Windows) / recommended (macOS)
Screen lock password must be known or empty

Here’s the updated chart of supported platforms:

We have successfully tested the new version of the extraction agent on all of the following devices:

iPhone 7: iOS 13.5.1, iOS 13.6, 13.7
iPhone X, iOS 13.7
iPhone Xr, iOS 13.6.1
iPad Pro 3rd gen, iOS 13.7

iOS Extraction Without a Jailbreak: iOS 9 through iOS 13.7 on All Devices

Thu, 03 Dec 2020 06:50:31 GMT

After adding jailbreak-free extraction for iOS 13.5.1 through 13.7, we now support every Apple device running any version of iOS from 9.0 through 13.7 with no gaps or exclusions. For the first time, full file system extraction and keychain decryption are possible on all devices running these iOS versions.

Full iOS 13 support without a jailbreak

When extracting an iOS device, one needs low-level access to the device. Years ago, we developed a workflow to allow experts imaging the device’s file system and decrypting the keychain. That workflow largely relied upon publicly available jailbreaks. While decidedly not forensically sound, this process was the only chance of accessing the full content of the device including all keychain records, private chats and application data not included in backups.

We were never completely satisfied with the workflow, and so we developed a different method for accessing the data that does not require a jailbreak. This all-in-one extraction method utilizes an extraction agent of our own development. Once installed, the agent automatically escapes sandbox, escalates privileges and establishes a communication channel with the computer. Agent-based extraction provides numerous benefits over jailbreak-based acquisition, being a lot safer, a lot faster, and a lot more robust.

We are continuously working on extending the agent’s compatibility. Starting today, users of iOS Forensic Toolkit 6.60 and subsequent releases will be able to perform the complete extraction (file system and keychain) of Apple devices running all versions of iOS starting with iOS 9.0 through iOS 13.7 (up from the previously supported iOS 13.5). This covers devices ranging from the iPhone 5s through iPhone 11 Pro Max if they run one of the versions of iOS mentioned above.

Steps to extract the file system and decrypt the keychain

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

Install iOS Forensic Toolkit 6.60 or newer. On macOS, the Toolkit is now distributed as password-protected DMG file (in older versions, the DMG was not protected with a password, but packed into RAR archive with a password). Do not forget to clear the ‘quarantine’ flag from DMG file on Catalina and Big Sur before mounting it (see Installing and using iOS Forensic Toolkit on macOS 10.15 Catalina).

Connect the device in the powered-on state with a Lightning cable and establish trust relationship if needed. If requested, you will have to unlock the device and enter the passcode for pairing.

Launch the Toolkit (Toolkit.cmd on Windows or Toolkit.command on macOS). On macOS, do not run the script directly from the mounted image, but copy the Toolkit files onto a local disk into a folder such as “EIFT” first. All the features your need are grouped under the Acquisition agent. We recommend keeping the device in Airplane mode.

Install the Agent. Press [1] to sideload the agent module to the device. The device should be unlocked and paired; the local antivirus software should should be temporarily disabled. You will be prompted for an Apple ID first. In Windows, you can only use an Apple ID registered in the Apple Developer Program; on macOS, you can use any Apple ID including throwaway accounts. This Apple ID is not related to the Apple ID used on the device you are investigating.

You will be prompted for a password for that Apple ID. In Windows, use an app-specific password generated in advance in My Apple ID; in macOS, use the regular password, but you will have to pass two-factor authentication by entering the code delivered to a trusted device.

If the given account is connected to more the one developer program (Windows) or at least one (macOS), you will be prompted to choose one.

The Toolkit signs the main agent module for the connected device and sideloads it there:The Agent icon (the app name is Acquisition) now appears on the iPhone screen:

Tap on the app icon to launch, and keep it running in the foreground. If you used a non-developer account to sign the app, an extra step is required: you’ll need to approve the certificate; see Extracting iPhone File System and Keychain Without an Apple Developer Account for more details.

Now you can extract the keychain, capture the file system image or extract user files.

Extract the keychain. Press [2] to start keychain extraction. The Agent obtains root privileges, which is safe for the device and the data, but may cause a reboot of the device. If that happens, reconnect the device (pairing might be required again), close the Agent, launch it again, and try again. In the worst case it may take up to 3 or 4 attempts until the exploit works. On success, you should see the Exploited successfully message first. Exploiting may take up to 30 seconds, depending on the device model and iOS version.

Note that extracting the keychain requires you to give the permission to use Face ID or Touch ID, and then using biometrics or entering the device passcode (note the Acquisition app name); this is mandatory for the correct operation of the Agent app in order to get the full keychain contents, including records with the highest protection class:

Extract the file system. Press [3] to extract the full file system image, or [4] to save the user’s files excluding the system partition:

Once the imaging is complete (the speed is usually 30 to 35 MB/s), the Toolkit outputs the hash sum (SHA-1) of the extracted image/archive. Please note that the progress reporting may differ between the Agent and in Toolkit user interface.

For the test device we used an iPhone Xr running iOS 13.6.1. The file system image was 15.6 GB, copied in 8 minutes. The user partition was 7.4 GB only, copied in 3.5 minutes. Imaging a 512 GB model full of data may take about 4 hours.

Remove the agent. Press [5] to uninstall the agent from the device. Note that some traces of using the Agent are left on the device (e.g. in the log files).

Further analysis. The keychain can be analyzed using Elcomsoft Phone Breaker:

To browse and analyze the content of the extracted file system image, use the quick and lightweight Elcomsoft Phone Viewer or a fully-featured forensic package such as Oxygen Forensic Detective.

Elcomsoft vs. Hashcat Part 3: Attacks, Costs, Performance and Extra Features

Wed, 02 Dec 2020 16:11:14 GMT

Elcomsoft Distributed Password Recovery and Hashcat support a number of different attacks ranging from brute-force all the way to scriptable, dictionary-based attacks. The costs and performance are extremely important factors. We charge several hundred dollars for what, in the end, can be done with a free tool. Which tool has better performance, and are the extra features worth the price premium? Let’s check it out.

The attacks

When recovering a tough password, almost everything depends on the quality of the wordlist and the type and configuration of the attack. Let us see how the two tools compare.

Brute force and mask attacks

Plain brute force attacks almost never succeed on anything but the simplest passwords, yet they still might be effective against shorter passwords and uncomplicated protection.

In Hashcat and hashtopolis, you specify the attack through the command line or list the attacks in a text file. In Hashcat, brute force attacks are a subset of the mask attack. As an example, if you want to try all passwords that consist of small Latin letters and are 1 to 5 characters long, you can specify the following attack:

?l
?l?l
?l?l?l
?l?l?l?l
?l?l?l?l?l

If you are using hashtopolis, you’ll need to enter these five strings into the corresponding text field.

Elcomsoft Distributed Password Recovery supports a similar concept, but allows specifying the minimum and maximum password length as well as the character set either globally (for the whole password) or in groups or characters, allowing to quickly build an attack that takes into consideration the human factor. Brute-force and masks attacks are configured in the GUI.

Dictionary attack

The two tools implement dictionary attacks differently. Hashcat accepts the dictionary as a wordlist, trying each entry the way it is stored in the dictionary. There are no pre-defined mutations and no ability to add a mask when running a dictionary attack (these are parts of the rule-based attack). No automatic distribution of the dictionary file is available if you are running hashtopolis; agents will only use the dictionaries that are already installed.

Elcomsoft Distributed Password Recovery provides automatic dictionary distribution to all connected agents including those working in the virtual instances. Dictionary attacks support a large number of pre-defined mutations, allowing to try the most common combinations of dictionary words such as Password, password1, Pa$$w0rd, password1965 and a lot more. We recommend our users trying a small dictionary with certain mutations first, as this often finds frequently used passwords. We also include the dictionary of the top 10,000 most popular passwords from several major leaks, which may help breaking up to 30% of cases in English-speaking countries.

Combinator attack

This is a simple combination of two dictionary words from two dictionaries (same or different files). Both Hashcat and Elcomsoft Distributed Password Recovery support this attack.

Hybrid attack

While both tools support hybrid attacks, the term is used in different meanings.

Hashcat-style hybrid attacks combine one dictionary word (from a single dictionary) with one mask. This would be considered a particular case of a mask attack in Elcomsoft Distributed Password Recovery. In our tool, one can use multiple dictionaries, where any part of the mask can be a dictionary word. We believe that our solution has an edge over Hashcat here.

What Elcomsoft Distributed Password Recovery calls a “hybrid attack” is classified as a “rule-based attack” in Hashcat.

Rule-based attack

The “rule-based attack” in Hashcat is called “hybrid attack” in Elcomsoft Distributed Password Recovery. Otherwise, the implementations are very similar; we would even call them identical, as booth tools are following the same syntax as John The Ripper, the tool that originated this attack. Elcomsoft’s makes using John The Ripper style attacks much easier than Hashcat thanks to the use of the newly developed visual Rule editor. The Rule editor brings John the Ripper’s syntax directly to the user interface, eliminating the need for manually editing text files.

Attacks: conclusion

Booth tools support a wide range of attacks. Dare we say, setting up attacks in Elcomsoft Distributed Password Recovery is simpler and more straightforward compared to Hashcat. Everything is configured from the graphical user interface. A live preview of sample passwords is displayed for every mask or mutation enabled.

To its credit, Hashcat has the ability to run a set of several consecutive attacks, a feature that Elcomsoft Distributed Password Recovery lacks. One can, however, create multiple individual attacks on the password, and run them in the regular job queue.

Benchmarks

If you read to this point, you must be interested which tool is faster. While we could make and post numerous benchmarks, the truth is that both tools are highly optimized, and both can exploit the available hardware resources to the maximum. Trying over a hundred formats, we’ve seen performance fluctuations of around 10 per cent. For many formats, Elcomsoft Distributed Password Recovery offers a (very) slight edge over Hashcat thanks to the additional utilization of available CPU cores (Hashcat, as you remember, is GPU-only). Whichever tool you choose, you’ll be happy with its raw performance – or, at least, it doesn’t get much better if you jump ship.

The costs

If you are an open-source fan, you’re going to like this chapter; less so of you are a (paid) customer.

Hashcat is free. Hashcat, hashtopolis, most hash extraction scripts and the host OS (Linux) are absolutely free to use, modify, recompile, or make a custom version just for you, on one condition: you do it yourself or you pay someone to do it for you. Using Hashcat requires skills and experience. Setting up Hashcat on a single computer requires deeper skills, more experience and quite some time. Preparing the tool to run on a distributed network requires skills and experience in Linux administration, a lot of time and a bit of trial and error. Writing attack scripts takes time, and even adding an agent to hashtopolis when you expand your distributed network takes time. It takes time processing disk images of encrypted disk, and it takes time to obtain hash extraction scripts for the occasional new file format.

Elcomsoft Distributed Password Recovery is as much plug-and-play as a forensic grade distributed computing tool can be. Installing the tool on a single computer is no different from installing any other Windows program, while deploying agents to network computers is similar to deploying any other package in your Windows domain. Prepackaged agents make cloud instances straightforward to set up and to use. The attacks are as fast or slightly faster than Hashcat, while being significantly easier to set up.

That level of user-friendliness and simplicity comes at a cost. We charge $599 for a license covering the parallel use of 5 agents. If you are expanding into the cloud, you will notice the differences in cost between Linux and Windows-powered VMs. It is also

The cost of hardware should be the same for both products. The more and the faster video cards you install, the faster the attacks.

Technical support

If you have a problem, Hashcat has a wide community of users and an active forum where you can search for or post questions about issues. What you may not like is the answers. While we had no problem finding the answers to our issues (e.g. attacking a large ZIP archive), finding that what you want is simply not an option can be a little… discouraging.

Elcomsoft Distributed Password Recovery is supported by us via the standard ticket system. We stand behind our product, quickly resolving the issues once they are reported.

The extra features

There are a few features that can greatly improve usability of Elcomsoft Distributed Password Recovery over Hashcat.

Password cache

If we find a password to one job, we add that password into a custom dictionary. Once the next job is started, we’ll try passwords from that dictionary first. This helps save time if the same password is reused across multiple files or data formats.

Non-ASCII characters and Unicode support

Hashcat supports non-ASCII and Unicode characters, but adding those to the attack requires a concise effort. If you want to add certain non-ASCII characters, you’ll have to use the –hex-charset option and add the extra characters as HEX codes. If you want to use a dictionary with non-ASCII words, you’ll have to do the same.

Elcomsoft Distributed Password Recovery is Unicode throughout.

Running as a service

Elcomsoft Distributed Password Recovery agents do not require an authenticated user session to work. Agents can run as a system service, starting along with the system.

Hashcat can do the same in Linux. However, the Windows version requires an authenticated session to run hashtopolis Python scripts.

Distributed updates

When you update Elcomsoft Distributed Password Recovery, all components of the distributed network are updated automatically including all connected agents.

Hashtopolis makes updates a journey. While Hashcat and hashtopolis can be updated automatically, updating the agents requires an effort. You’ll have to manually stop each agent, obtain the updated version from the server, and manually install it on each computer.

Forensically Sound Cold System Analysis

Tue, 01 Dec 2020 15:08:43 GMT

As opposed to live system analysis, experts performing the cold analysis are not dealing with authenticated user sessions. Instead, cold analysis can be viewed as an intermediary measure with live system analysis on the one end and the examination of a forensic disk image on another. Why and when would you use cold system analysis, what can you do and what benefits does it bring compared to the traditional approach? Read along to find out.

What is cold system analysis?

Cold system analysis is frequently used in the field, yet the term itself is not quite as common as “live system analysis”, so it needs a bit of an explanation. The term was born after the “cold boot attack”, which in turn defines a very specific kind of attack allowing to extract secrets (such as encryption keys) from the system’s volatile memory. In order to perform a cold boot attack, an expert boots the computer from a portable media (typically a USB flash drive). This is exactly what is used during the cold system analysis: the examiner boots the computer from a USB drive and attempts to gain access to the system and/or extract evidence from the computer.

What is “live system analysis” then? In live system analysis, the examiner attempts to gain control over an authenticated user session. This is only possible if the computer being investigated is turned on, and at least one user has an active session. The cold system analysis presumes that the initial state of the computer is powered off or hibernated, and no authenticated user session is available.

The opposite of live system analysis is the examination of forensic disk images, which are bit to bit captures of the user’s physical storage devices. Even if something happens to the data stored in the disk image during investigation, it is always possible to go back to the original file.

The risks of cold system analysis

Live system analysis is the riskiest of the three methods. An authenticated user session may be full of surprises. There may be unknown (and potentially dangerous) background processes running, and any available evidence can potentially self-destruct at any time. If the computer is connected to the network, much worse can happen, while breaking the network connection may trigger unknown, potentially dangerous tasks. Live system analysis is never forensically sound, and should be only performed after carefully weighing the risks.

Working with forensic disk images is the safest method, which at the same time is the most labor-intensive and time-consuming. This is the most forensically sound method.

Cold system analysis sits in between. By booting the user’s computer from a known good portable media, experts have access to a clean system with familiar forensic tools. However, it’s still the suspect’s computer, and user mistakes make room for irreversible accidental modifications. One of the most common mistakes, by the way, would be hasting to resetting the user’s Windows account password, which instantly and permanently locks the ability to access EFS encrypted files and any passwords stored in Web browsers such as Google Chrome or Microsoft Edge. However, when used carefully, cold system analysis can deliver significant benefits over the analysis of forensic disk images without most of the risks associated with live system analysis. Results obtained with cold system analysis may or may not be forensically sound depending on the tools and techniques you used.

Cold system analysis step by step

We made forensically sound cold system analysis easy with Elcomsoft System Recovery (ESR). Unlike competing tools, most of which are Linux-based, Elcomsoft System Recovery is based on the familiar Windows environment, thus being an ideal tool for investigating Windows computers.

Once you prepare a bootable USB drive by running the Elcomsoft System Recovery installer, you will be able to perform a wide range of tasks depending on whether or not the system partition is encrypted.

Remove BitLocker protection

If the system partition is encrypted with BitLocker, there is very little you can do before unlocking the volume. In this scenario, you can boot into Elcomsoft System Recovery, capture the volume’s encryption metadata, bring the data to the lab and attempt to recover the original BitLocker password by running Elcomsoft Distributed Password Recovery.

Depending on the configuration of protectors used on the particular BitLocker volume (which mostly depends on whether or not the system has a TPM module), you may or may not be able to unlock the volume. More in Unlocking BitLocker: Can You Break That Password?

If you have a password or BitLocker recovery key to the system volume, ESR can unlock and mount the volume using the built-in BitLocker functionality of Windows PE. Once this is done, you can continue analyzing the disk, which is a huge time saver compared to the traditional imaging and decrypting workflow.

Collect existing passwords

Once you boot into Elcomsoft System Recovery, the tool will probe existing Windows account for common passwords. If a password is discovered, it will be displayed to allow further analysis.

Break Windows account passwords

What if the passwords are unknown? If this is the case, you will need to run an attack to recover the original passwords. To do that, you’ll need to extract encryption metadata (hashes), and use that data in Elcomsoft Distributed Password Recovery to launch the attack.

Unlock disk encryption

If the computer had not been shut down but was discovered in a state of hybrid sleep or hibernation, you may be able to find on-the-fly encryption keys (OTFE keys) to disk encryption tools such as BitLocker, TrueCrypt, VeraCrypt or PGP. These keys may be found in hibernation or page files. During cold system analysis, you can extract these files and save them on external media for further analysis with Elcomsoft Forensic Disk Decryptor.

Search for encrypted disks

Speaking of disk encryption, cold system analysis with ESR allows finding encrypted disks by running a thorough automated search.

Search for encrypted virtual machines

Along with disk encryption tools, encrypted virtual machines are among the most common cover-up tools. You can look for encrypted virtual machines in ESR, which, again, is an automated process. Once the tool finds an encrypted VM, it automatically saves the encryption metadata that you can use in Elcomsoft Distributed Password Recovery for breaking the original password.

Create forensic disk images

There is only so much you can do at the cold system analysis stage, and making disk images is one last shortcut you can take to speed up the investigation. Traditionally, experts would disassemble the computer, take the disks out and make their images with a specialized write blocking disk imaging device. ESR offers a shortcut, allowing to make forensic disk images without taking the drives out.

The quick and dirty of cold system analysis

Cold system analysis is as forensically sound as you make it. In certain cases, you may afford losing the “forensically sound” part for the sake of efficiency. A good example is emergency unlock of ex-employees’ Windows accounts, re-assigning administrative privileges or simply restoring the computer’s functionality by removing maliciously or accidentally set Syskey protection.

Unlock Windows accounts

The need for unlocking accounts of Windows users is common in organizations with under-administered networks. ESR makes this extremely easy to do; changing a password of any Windows user is literally a matter of several clicks. Note, however, that this is far from being forensically sound: if you reset a user’s password, any data encrypted with Windows DPAPI (e.g. encrypted file system, stored passwords etc.) will be permanently lost. This may still be acceptable in many cases, so here is the how-to article: How to Unlock Windows Systems with a Bootable Flash Drive

Assign administrative privileges

Assigning administrative privileges to a certain Windows account may be needed to restore full access to the system if the administrative password is lost or unknown. ESR makes this possible in a few clicks.

Remove Syskey protection

If you haven’t heard about Windows Syskey protection, you are not alone. This feature does not provide any real security, but has the potential if becoming a great hassle if someone who knows about the feature accidentally or maliciously sets a Syskey password. We have an article on Syskey passwords: How to Reset or Recover Windows SYSKEY Passwords.

The ABC’s of Password Cracking: The True Meaning of Speed

Mon, 30 Nov 2020 10:38:06 GMT

When adding a new encryption format or comparing the performance of different password recovery tools, we routinely quote the recovery speed expressed in the number of passwords per second. But what is the true meaning of password recovery speeds? Do the speeds depend solely, or at all, on the encryption algorithm? What’s “military grade” encryption, and does it guarantee the security of your data? And why on Earth breaking AES-256 encryption takes so vastly different effort in different file formats? Read along to find out.

If you aren’t familiar with password cracking, I recommend reading What is Password Recovery and How It Is Different from Password Cracking first. Before we start discussing the differences in encryption, let us first talk about what you need to launch the attack.

More often than not, in order to break an encryption password you’ll need access to the entire file or document. In many cases, the encryption metadata (which includes the password hash, salt value, and sometimes additional encryption parameters) is stored in the beginning of the document in the file header. As a result, for most file formats you can extract the encryption metadata (sometimes referred as simply “hashes”, although there is more than just hash values stored in the encryption metadata). However, there are several exceptions to this rule.

One notable exception would be the RAR3 and RAR4 formats. To crack passwords, you’ll need almost the entire content of the archive and not just a tiny hash from the file header. There are other formats where you’ll need to decrypt and validate a certain block of data in order to verify the password. Even if both the encryption algorithm and the hash function are the same, such formats will always be much slower to break due to additional computations required to validate the password.

The password verification method is not the only thing affecting the speed of the password recovery attack. There are formats allowing several million password combinations per second, and there are formats where you are limited to single-digit speeds.

The numbers don’t tell the whole story

Almost everyone makes use of AES-256 for encryption, yet some formats are multiple orders of magnitude slower to break than others. Why are the speeds so different? The differences are caused by the different hashing and encryption algorithms as well as the vastly different numbers of hash iterations required to verify the password. In Microsoft Office encryption evolution: from Office 97 to Office 2019 we demonstrated it using the different generations of encryption used in Microsoft Office tools over the years.

Does it get any slower than that?

The longer it takes to break a password, the more secure your data is. Is there a theoretical limit on how secure your data can be? Most manufacturers assume that the user expects the encrypted document to open or the locked device to unlock in approximately 0.3 seconds. However, this time is measured on what they consider to be average hardware for the use case, meaning that newer and faster computers will unlock the document much faster than that.

Most manufacturers use a single CPU core and inefficient coding to verify the password. By utilizing all available CPU cores and thoroughly optimizing the code, we’ve been able to increase the speed of attacks by the factor of 10 to 25 compared to the time it takes the original manufacturer to validate the password. The use of a dedicated GPU accelerator further increases the recovery speed by the factor of 20 to 250 depending on the format.

Manufacturers know about the issue, and attempt using several countermeasures. For some formats, the number of hash iterations (what’s that?) can adapt to the speed of the current hardware. For example, Apple employs a different number of hash rounds to encrypt macOS user passwords. VeraCrypt allows users manually specifying the number of hash iterations, while some password managers do this automatically on the user’s behalf.

How many passwords can I try before being locked out?

Speaking of file encryption, the number of passwords you can try is unlimited. Our tools routinely crunch through hundreds of billions password combinations before finding the only one that works. If, however, you are attempting to unlock and iPhone or attacking an online service, you may be locked out much sooner after a handful of attempts.

Is there two-factor authentication for data encryption?

Encryption with two-factor authentication (where the second authentication factor is provided by a remote service) is commonly used in DRM to protect books, music and videos from copying. We’ve almost never seen encryption 2FA in common data formats. While theoretically possible, the implementation would require the ability to interact with a remote party just to gain access to your data, which is not everyone’s cup of tea. One example of 2FA-based protection is OneDrive Personal Vault, which, on the other hand, is not encryption.

Some algorithms are faster than others

You might be wondering about which formats are slower and which are faster to break. In What is Password Recovery and How It Is Different from Password Cracking, we are discussing this very thing. Microsoft Office before Office 2007, the legacy ZIP and PDF encryption are examples of extremely weak encryption. Today, Tally ERP 9 Vault is a good example of almost non-existing protection.

Much stronger encryption is used in many modern products. Microsoft Office 2013 and 2016, RAR archives, TrueCrypt, BitLocker and VeraCrypt are good implementations of strong encryption.

Interestingly, not every manufacturer is interested in strong protection even within a certain class of products. In Breaking Encrypted Virtual Machines: Recovering VMWare, Parallels, and VirtualBox Passwords, we made a point that some encrypted virtual machines might be broken much faster than the rest of the pack. We’ve seen the recovery speed of some 19 million passwords per second for Parallels VMs.

The true meaning of speed

So 19 million passwords a second is “a lot”, and 10 passwords a second is “very slow”. I get that. Well, not really. How much time, exactly, will you need to break this password? Or that one? Or let me as it this way: how long a password can you break in a day? A week? Two weeks perhaps?

You’re not going to like the answer: “It depends”. The deciding factor is the number of password combinations we’ll have to try before finding the right one, and the number of passwords per second we can try on a given system. In May the [Brute] Force Be with You! , we discuss these exact issues in detail.

Salt anyone?

In It’s Hashed, Not Encrypted, we discussed the value of salt. What if someone wanted to take a shortcut, calculating a massive number of hashes corresponding to some 10 million most common passwords? Or maybe a billion passwords that had ever leaked? Wouldn’t it be easier to simply look up the hash string in such a list? Or how about stealing a list of hashes and looking for some of the most common passwords in that list by their hash values?

Fortunately, none of these attacks work in real life. To mitigate these threats, hashed passwords are “salted” by appending a string of some unique random data to each password. The result of this transformation is a salted hash of the password. To verify a salted hash, one needs the password itself and the corresponding salt value. The salt is not a secret, and usually stored along with the hash. Salt values stored in a separate database (or on a separate physical server) are called “pepper”. With rare exceptions, all major manufacturers use salt when encrypting stuff or protecting online accounts.

Pure brute force vs. smart attacks

The speeds above are only valid for pure brute force attacks. For the attacker, incrementing the next password to try is the simplest math resulting in the fastest recovery speeds. Brute force is one of the best optimized attacks when it comes to using GPU acceleration with a large number of parallel computing cores.

On the other hand, pure brute force attacks are rarely effective. They only allow recovering very simple passwords (or average-length passwords for some of the weaker formats). We discussed the limitations of pure brute force attacks in May the [Brute] Force Be with You!

Many types of passwords (such as simple dictionary-based passwords or passwords combining one or several common words with typical alterations) can be broken much faster by using other types of attacks using dictionaries, mutations or scriptable rules. All of these smart activities don’t require additional CPU cycles; the smarter the attack, the more additional CPU cycles it takes compared to pure brute force. As a result, a smart attack based on complex scriptable rules may work several times slower compared to a pure brute force – yet still delivering the result much faster.

The iPhone backup password

I simply love iPhone backups because they are great in a very unique way. In The Most Unusual Things about iPhone Backups, I talked about how Apple made iPhone backups extremely slow to attack. Even hardware-accelerated attacks deliver the speeds of just about 10 passwords per second. A single-core, CPU-only algorithm requires approximately 15 seconds to try a single (!) password to an encrypted iTunes backup.

What about the iTunes app? The app can check the password in less than a second. Is it a trick? It’s exactly the one: iTunes verifies the backup password on the connected iPhone instead of using your computer’s resources, and the iPhone has access to a different verification algorithm not available from outside the device.

Elcomsoft System Recovery: a Swiss Army Knife of Desktop Forensics

Thu, 26 Nov 2020 06:59:27 GMT

Accessing a locked system is always a challenge. Encrypted disks and encrypted virtual machines, encrypted files and passwords are just a few things to mention. In this article we are proposing a straightforward workflow for investigating computers in the field.

Note: you may be able to perform live system analysis if the computer being investigated is turned on. Our scenario assumes that the computer is initially powered off, or powered on and locked/inaccessible.

Pre-requisites

The computer you are about to analyze is powered off. At least one available USB port. You must be able to access the computer’s BIOS/UEFI setup to enable booting from USB media.

The workflow

Using Elcomsoft System Recovery, you will be able to perform a wide range of tasks. We recommend the following workflow on computers without BitLocker protection:

Prepare ESR bootable USB drive.
Configure target computer to boot from a USB device.
Boot target computer to ESR.
ESR will attempt to collect existing passwords.
ESR will run a quick recovery attack on the system’s Windows accounts.
Extract hashes to Windows accounts of interest (if password not discovered in previous step) for subsequent attacks.
Extract page and hibernation files.
Search for encrypted disks. If discovered, extract encryption metadata (you will be able to scan page/hibernation files for on the fly encryption keys).
Search for encrypted virtual machines. If discovered, extract encryption metadata for subsequent password attacks.
Create forensic disk images for further in-lab analysis.
Optional: after a risk assessment, perform live analysis by resetting selected account password, booting into the main system and signing in with the newly set password.

Let’s have a closer look at this workflow.

Prepare ESR bootable flash drive

If you don’t have a bootable flash drive, create one by launching Elcomsoft System Recovery setup on your computer (not the computer being investigated) and click through the wizard. You’ll need a reasonably large and reasonably fast flash drive (32GB or larger).

Once the bootable flash drive is created, insert it to the available USB port of the computer you are about to analyze.

Prepare the target computer for booting from the USB drive

Power on the computer being investigated, immediately entering BIOS setup. To enter BIOS, you will typically need to hit the Del key early during the boot stage. On some systems, you may be using the F10, F11, or F12 keys. We’ve also seen the F2 combination open the list of bootable devices; however, this combination is also system-specific.

Enable USB boot

For security reasons, most computers are configured to only boot from internal media. In order to boot from the ESR flash drive, you will need to allow the computer booting from a USB device. In order to do that, locate the appropriate setting in the computer’s BIOS (typically named as “Boot order”), add “USB” to the list of devices the computer is allowed to scan during the boot sequence, and bring that entry to the top of the list (typically using Page Up/Page Down keys).

Boot from the USB device

Save settings and exit BIOS. The computer should start booting from the USB device containing Elcomsoft System Recovery. On some systems, you may be able to select the boot device by hitting the F2 key repeatedly.

Windows account passwords: collect the low hanging fruit

Once Elcomsoft System Recovery is launched, the tool automatically scans the system for available passwords, and runs a fast pre-configured attack that may reveal weak account passwords.

Windows account passwords: extract hashes

If the tool is unable to discover passwords to all user accounts, you can extract encryption metadata (hashes) for subsequent password recovery with Elcomsoft Distributed Password Recovery.

Hibernation and page files

The hibernation and page files may contain on-the-fly encryption keys used by various disk encryption tools such as VeraCrypt, TrueCrypt, PGP or BitLocker. Extract these files and save them on external media for further analysis with Elcomsoft Forensic Disk Decryptor.

Search for encrypted disks

Disk encryption is commonly used in the criminal world. ESR can search for encrypted disks, identity protection methods and extract encryption metadata. In many cases, the encryption metadata can be used to launch a password recover attack on the encrypted disk.

If the encrypted disk was mounted immediately before the analysis, the binary on-the-fly encryption keys might be available in page or hibernation files. Use Elcomsoft Forensic Disk Decryptor to scan these files for disk encryption keys.

Search for encrypted virtual machines

Along with disk encryption tools, encrypted virtual machines are among the most common cover-up tools. Manually locating such virtual machines can be an involving and time-consuming process. ESR simplifies this task by finding many types of encrypted virtual machines automatically. Once an encrypted VM is discovered, ESR automatically saves the encryption metadata. You can use that data to launch a password recovery attack on VM encryption in Elcomsoft Distributed Password Recovery. We have an article on the subject: Breaking Encrypted Virtual Machines: Recovering VMWare, Parallels, and VirtualBox Passwords

Create forensic disk images

When investigating incidents, you are more likely to analyze a disk image rather than a physical hard drive. Use Elcomsoft System Recovery to capture the disk image and start the analysis without the need for opening the computer and taking the disks out.

Note: you will need an appropriately sized external storage media to store the disk images.

The extra step: live system analysis

In certain cases, you may need to perform the analysis of an authenticated user session. If ESR was able to recover the original password to one of the user accounts, you may use that password to sign in. Alternatively, you can use ESR to reset the password of a Windows account. Before you do, make sure that you fully realize the consequences and perform the risk assessment.

Consequences of resetting a Windows account password

If you choose to reset the password to a certain user, you will lose access to information protected with DPAPI (Windows Data Protection API). This information includes:

EFS (Encrypted File System) access. Any NTFS-encrypted files will be rendered useless after resetting the account password. You absolutely need the original password to decrypt those files.
Items stored in the Protected Storage including but not limited to: Microsoft Edge Legacy passwords; access to Google Chrome and Edge Chromium password database; passwords to network shares; passwords to email accounts.

In order to access any of that data, you will require the user’s original account password.