All posts by Oleg Afonin

Modern encryption tools employ strong encryption with multiple hash iterations, making passwords extremely difficult to break. The November article “What is password recovery and how it is different from password cracking” explains the differences between instantly accessing protected information and attempting to break the original plain-text password. In that article, I briefly mentioned GPU acceleration and distributed attacks as methods to speed up the recovery. In this article, I’ll discuss the two acceleration techniques in more detail.

Why do we need GPU acceleration?

Literally, we need GPU acceleration to break passwords faster. How much faster, exactly, depends on several things: the type of the video card (more on that later), the number of video cards installed, and the algorithm that was used to convert the password into a binary 128-bit or 256-bit encryption key.

If you have not yet read the “What is password recovery and how it is different from password cracking” article, you may want to review it for the basic theory of password cracking. Most types of data protection today implement encryption. The encryption algorithm protects data with a 128-bit or 256-bit Media Encryption Key (MEK, sometimes also referred as a Data Encryption Key, or DEK), which is long enough to make brute-force attacks out of the question.

With the binary media encryption key out of the reach of today’s brute force algorithms, one must target something else instead. The media encryption key itself is either directly produced from the user’s text-based password or encrypted with the user’s text-based password. The majority of plain text passwords have significantly lower entropy compared to 256-bit or even 128-bit media encryption leys.

Recovering the original password is often the only way to access the data. While makers of password recovery tools are trying to break password as fast as possible by trying increasing numbers of password combinations per second, makers of data encryption tools are doing exactly the opposite in order to slow down attacks. This is often achieved by increasing the number of rounds (recursive calculations of a hash function) that is used when processing the user’s input and turning it into an encryption key.

However, there is light at the end of the tunnel. Manufacturers of data protection tools cannot increase the protection indefinitely; there is only so much time the user is willing to wait for a password-protected document to open or an encrypted volume to mount. As a result, manufacturers profile their data protection algorithms so that the data can be accessed in about 0.3 to 1 second on an average (or below-average) system. Particularly important is the fact that all common data protection algorithms only use the system’s central processor (CPU) when it comes to verifying the password. Which brings us to the next point.

What is GPU acceleration and how does it work?

As demonstrated earlier, the speed of a single CPU is not enough to break many types of passwords. With hundreds of thousands or even millions hash iterations used to slow down the recovery, attacks running on a CPU alone can only break the simplest passwords. Additional computation power is urgently needed to break passwords in reasonable time.

At the same time, today’s power-hungry video cards ship hundreds of dedicated high-performance cores working in parallel. High-end and mid-range video cards manufactured by NVIDIA and AMD can render complex 3D scenes in real time; something that a bare CPU would struggle with.

This is how we arrived to the idea of using video cards to accelerate the recovery. GPU acceleration offloads computational-intensive calculations from the computer’s CPU onto the highly scalable video cards. Featuring several hundred GPU cores, a single video card can deliver the speed far exceeding the metrics of a high-end CPU. Depending on which video card is installed and what type of encryption we are dealing with, one can expect the recovery speed to raise some 50 to 250 times faster compared to CPU-only benchmarks.

Asynchronous GPU acceleration

If you have more than one video card installed, Elcomsoft Distributed Password Recovery can use up to 32 dedicated video cards at the same time.

What if those video cards running at different frequencies? Or what if they are different video cards altogether? This is where asynchronous GPU acceleration comes into play. With asynchronous acceleration, the password recovery tool can break jobs into smaller pieces, and feed every piece to a given video card. The asynchronous scheduler does not have to wait for a given part of the job to complete before feeding the next piece in line once one of the video cards finishes its slice.

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

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

How fast is GPU acceleration?

The “how fast…” is a million dollar question. GPU acceleration is only as fast as the video card (or video cards) installed in the computer. However, a video card that is fastest in 3D games or one offering real-time ray tracing is not necessarily the best for password recovery.

Long story short, there are no password recovery algorithms that would utilize the ray tracing acceleration units found in NVIDIA’s RTX series video cards. As a result, a NVIDIA GeForce GTX 1660 Super will break passwords at almost the same rate as a GeForce RTX 2060 Super with nearly double the price.

So how fast is GPU acceleration, exactly? These are the bare numbers:

 

What do the number mean, and how strong a password can you break with a single GTX 1660? We’ll use a password calculator to estimate the time required to break some types of passwords.

Attacking an encrypted Microsoft Office 2013 document with a single video card results in approximately 2900 passwords per second, or about a million (1044000) password combinations an hour.

A very simple (I would even say, unrealistically simple) password composed of only 5 characters (lower case letters and numbers only) has 60,466,176 possible combinations. Brute-forcing such a simple password with a GPU would only take about 58 hours. This very same password would take about 1.5 years of brute-force attacks using a CPU alone.

A weak password containing 6 characters including lower and upper case letters and numbers (but no special characters) has 56,800,235,584 possible combinations. This password would take 6.3 years to break on a single GPU.

An average password of 7 characters of the same group would take 385 years of brute-force attacks to break.

Distributed computing

385 years sound like an awful lot for a single-GPU attack. In other words, this is not a feasible attack to run. Granted, smart attacks including dictionaries, double dictionaries, prefixes, postfixes, mutations, scripted rules and whatnot do a great job when it comes to breaking passwords of ordinary Joe and Jane. They won’t do such a great job when attacking passwords of a seasoned hacker. In other words, we need more speed.

I already talked about multi-GPU acceleration; let’s do that and build a 4U rack server with as many as 8 GPUs. Great; this server will only take 48 years to break that password instead of 385! The next logical step is adding more of the same servers to the rackmount. If you use Elcomsoft Distributed Password Recovery, you can use up to 10,000 servers to your distributed network.

Cloud attacks

The linear scalability approach works great if you already have a data center equipped with up to date hardware. If, however, you were to build a dedicated data center from scratch, you may be shocked with the final bill. Hardware and maintenance costs, electricity and air-conditioning bills (you’ll have to pay for, and dissipate, some 1500W per computer) will add up quickly.

For those who require the fastest recovery speed without the hassle of building and maintaining a dedicated data center, we recommend considering offloading parts of the load the cloud. Using a cloud service means you’re getting a high-performance distributed network without having to build your own data center.

Using a cloud services (currently, Elcomsoft Distributed Password Recovery supports Amazon and Microsoft Azure clouds) offers a number of benefits over a static infrastructure. You can quickly add computing power on demand by renting additional instances, and quickly scale back once the job is done. With up to 16 GPUs per instance, you can build a network as fast as you need while keeping the costs under control.

Building a distributed cloud network is easier than you might think. Read Breaking Passwords in the Cloud: Using Amazon P2 Instances for details.

Conclusion

Even the fastest distributed network of 10,000 8xGPU computers will choke when trying to brute-force a .docx file protected with a 12-character password such as “JoeSmith1956”. However, this very same password can be broken easily with a simple hybrid attack in less than 2 minutes. This, however, is a very different topic.

Password managers or password reuse? This is the question faced by most consumers. Reusing a password or its minor variations for different accounts has never been a good idea, yet in today’s world of online everything the rate of password reuse reaches astonishing values. Using a password manager helps reduce password reuse, supposedly offering increased security. In this article, we’ll perform forensic analysis of some of the most common password managers.

Reusing Passwords is a Bad Idea

Major hacks and security breaches happen all the time. Occurring quickly one after another, there is little doubt the hackers are using databases of previously harvested passwords in order to try exploiting a variety of online resources. Password reuse is a major contributor to these hacks. After harvesting a single password database, hackers are quick to try stolen account credentials on other resources. Implemented via a botnet, these attacks may not trigger a security warning even if the account is compromised.

Old researches suggest the password reuse rate among user accounts on different services was at least 31 percent just a few years back. Today, the number of online accounts used by an average consumer had grown significantly, which led to severe increase of reused passwords. Recent reports suggest that some 59% of consumers reuse password across a number of different online services. This number can be significantly higher if we count the use of similar passwords.

What do these numbers mean in practice? For every 20 online accounts, an average consumer employs only 7 different passwords. Of these 7 passwords, only 3 are unique. The “different” passwords looks obviously similar. One of the most common behavioral patterns we observed was appending the number of digits and special characters required by a given Web site or resource to the end of the password. As a result, the list of “different” passwords may include simple variations such as password1, password123, Password1$, and so on. These patterns may be easy to detect and exploit during an investigation.

Password Reuse and Computer Forensics

While password reuse is bad for security, allowing hackers quickly attacking a number of services, it can be a blessing for computer forensics. By obtaining the list of passwords, experts may be able to determine a common pattern. This pattern, in turn, enables them building a so-called mask-based attack. Mask-based attacks reduce the number of passwords to try by allowing to specify something that all or most of the user’s password have in common.

As an example, Elcomsoft Distributed Password Recovery that we have updated a few days ago had significantly improved one of the most popular masks. Before we get to that, let us see what some of these passwords have in common:

password
Password$
password1
Password12
Password5678
Password123$

As you can see, all of these passwords are based on a single key word “password” that may or may not start with a capital “P”. The key word may or may not be followed by a number containing up to 4 digits, that may or may not be followed by a special character. This is a very realistic scenario; the user tries using as simple a password as they can get away with. However, if a security policy enforces the use of a certain number of capital letters, numbers and special characters, the user simply adds them to the end of the password.

In EDPR 4.20, you can use a simple mask like this:

?0assword?1(0-4)?2(0-1)

character group ?0: Pp
character group ?1: digits
character group ?2: special symbols

Now, what do the following passwords have in common?

andy1980
apple1$
mary1968
hopeful1
wardrobe
monitor$

All of these passwords are based on a single dictionary word that start with a small letter, that may or may not be followed by a number containing up to 4 digits, that may or may not be followed by a special character. If you were using an older version of Distributed Password Recovery, you’d have to build a very complex hybrid attack to account for all of these password variations. EDPR 4.20 makes it as simple as this:

?w[mydic.udic]?0(0-4)?1(0-1)

character group ?0: digits
character group ?1: special symbols

Now, what if the user had a slightly more complex set of passwords like this:

Andy1980
Apple1$
mary1968
hopeful1
wardrobe
monitor$

These passwords are similar to the previous case in being based on a single dictionary word that may or may not be followed by a number containing up to 4 digits, that may or may not be followed by a special character. However, this time around the dictionary word may or may not start with a capital. Do we have a mask for that? Learn by taking a 3-day training course on breaking passwords!

Password Managers

1Password, Dashlane, KeePass and LastPass are the four most popular password managers. Password managers store, manage and (optionally) sync user passwords as well as other sensitive data. Password managers were explicitly designed to mitigate the issue of password reuse, offering the ability to generate, store and use passwords that are truly unique and non-reusable.

A typical password manager keeps all passwords in a database. The database is secured (encrypted) with a master password, and stored either locally or in the cloud. Password managers support both desktop and mobile devices, employing strong encryption to secure access to the password databases.

Notably, the entire password database is usually protected by a single master password. That single master password decrypts and opens all stored passwords.

Since most customers use their mobile devices to access accounts and open documents, password managers are also available on mobile platforms. Touch screens are no physical keyboard, and “motor learning” cannot be used to type complicated passwords; this results in simpler master passwords selected by users who frequently unlock their password vaults on mobile devices. Touch ID or Face ID do help avoid typing in the master password, but authentication with a master password is still required from time to time.

1Password is developed by AgileBits since 2006. This password manager supports Windows, macOS, iOS and Android platforms. The database can be stored locally, in Dropbox or in iCloud. The database is included with iTunes backups and iCloud backups.

LastPass was introduced by Marvasol Inc (acquired by LogMeIn) in 2008. LastPass also supports Windows, macOS, iOS and Android platforms. In addition, LastPass can be installed as a browser extension in many popular browsers. Passwords are synchronized through the LastPass server. In addition to desktop versions, the password database can be also acquired from browser extensions and Android devices.

Dashlane was developed by Dashlane in 2012; it also supports Windows, macOS, iOS and Android. Passwords are synchronized through Dashlane server. The password database can be only acquired from the computer or mobile device via file system extraction.

KeePass is an open-source application with native builds available for Windows only. There are numerous third-party ports for all major desktop and mobile platforms. KeePass offers no backup or synchronization options; the database can be acquired from the local PC or via file system extraction of a mobile device.

As I have already mentioned, password managers store passwords in local databases. These databases can be (and most probably are) encrypted with a single master password. Due to the sensitive nature of the information, the protection is typically very strong to sustain high-performance brute-force attacks. However, many password managers employ different protection settings for the different databases across their apps and plugins. A Windows desktop app would typically carry the strongest protection, while an Android app would use the weakest protection. Some password managers use adaptive protection strength that depends on the measured performance of the particular device.

Either way, using GPU-assisted attacks is a must when attacking password manager databases. The latest version of Elcomsoft Distributed Password Recovery can utilize GPU acceleration to speed up attacks on 1Password, Dashlane, KeePass and LastPass databases encrypted with a master password. The following benchmark demonstrate the performance of the attack on local databases extracted from the corresponding Windows desktop apps of 1Password, Dashlane, KeePass and LastPass:

If you’re confused with benchmark values for the different password managers, this is because they are confusing. Password managers do employ different protection settings in different environments. For example, if we take 1Password, the recovery speed depends on the hashing algorithm (SHA-1, SHA-256, or SHA-512) and the number of iterations. The desktop Windows app supports SHA-512 with a seemingly random number of hash rounds, which is calculated individually based on the performance and some other characteristics of the particular computer; this is to ensure that the password database is opened without a delay. Correspondingly, the speed of the attack falls as the the number of iterations increases. For this reason, the benchmarks for 1Password may look very confusing.

A Word of Caution: a Unique Password Is Not Enough

Even if one used a unique, random password for every online account, this may not be enough to secure online presence. A compromised ‘generic’ email account such as Yahoo! Mail not only enables the attacker to access historic email messages stored in that account, but to request password reset for other accounts registered with that email address. Which accounts exactly? That would be easy to guess by analyzing the user’s email history. A compromised Google Account opens access to the user’s entire digital life from comprehensive location history to – you guessed it! – stored passwords. Compromised Apple and Microsoft accounts lead to similar consequences. As a result, we cannot stress enough the importance of two-factor authentication. We believe no Apple ID, Google Account, Facebook or Microsoft Account should be ever used without two-factor authentication.

 

Tally ERP 9 is a “new-age business management software for new-age businesses” that is “tailor-made to delight”. With more than two million users, Tally is one of the most popular tools of its kind in India. The product includes the company’s implementation of secure storage named Tally Vault. How secure is Tally Vault, and what does one need to break in? In this article, we’ve provided some insights on how ElcomSoft researchers work when adding support for a new file format.

Support for Tally Vault is available since Elcomsoft Distributed Password Recovery 4.20.

Breaking Tally Vault

Tally Vault can be protected with a password. The password can be configured at the time one adds a new company; it is also possible to assign a password at a later time.

Once the password is set, ERP 9 creates a new protected vault. The old one (if any) can be deleted. If both encrypted and unencrypted versions of the company profile exist, one can select the right profile.

 

The new versions of Tally ERP 9 store the data in the following folder:

c:\Users\Public\Tally.ERP9\Data\(1nnnn)

If a password is specified for Tally Vault, the product encrypts all files with the .900 extensions that are over 512 bytes in size. However, the majority of the data is stored in a single file named Company.900. This file also stores information about the users if the “Use security control” option is enabled.

Unencrypted data is represented in the following way:

Once encrypted, the data looks as follows:

The file is comprised of 512-byte blocks. Each block starts with a 4-byte (32-bit) CRC checksum. When verifying the block, the tool calculates a CRC of the rest of the data (512 bytes less the 4-byte CRC) and compares the result with the checksum.

Now to the encryption. Tally uses an encryption algorithm derived from DES with a 64-bit encryption key. The DES algorithm used to be an industry standard originally introduced in 1977; in 2001, DES was superseded by AES, which is still used today. The 64-bit encryption key is derived straight from the user’s password (the concept of separate Media Encryption and Key Encryption keys is never heard of). Moreover, a slight modification of the user’s password leads to a similarly slight modification of the encryption key, which suggests a horribly weak implementation of key derivation. Considering that cryptographically strong hash functions (e.g. SHA-512) exist for a very long time, this result is truly amazing (as in “amazingly bad”). The encryption deals with 8-byte blocks.

Verifying the password is implemented by calculating the encryption key, decrypting the encrypted page and calculating the CRC of the decrypted data. The CRC is then compared with the check sum stored at the beginning of the page. Theoretically, decrypting the page and verifying the password would require decrypting some 64 blocks of 8 bytes each.

Reality is different. Each page includes a few bytes of fixed metadata. For example, immediately following the CRC there are four bytes containing the fixed value of 0x00000001. This is what’s considered a “known plain text”. As a result, the attacker does not have to decrypt the entire 512-byte page or calculate its checksum. Instead, decrypting the 4 bytes and comparing them with a known value of 0x00000001 is enough to try a password. Of course, collisions are unavoidable; for this reason, once the fixed four bytes are successfully decrypted, the attacker must verify the rest of the content by following the original algorithm (e.g. decrypting the entire page and calculating its CRC).

This value is not the only fixed metadata stored in encrypted pages. The offset 12 apparently stores the page number (unless it’s the last page), so even if Tally fixes this issue, other possibilities for fast attacks would remain.

So how does the speed of the known plaintext attack compare to the speed of the more straightforward attack that requires decrypting the whole page?

Whole page decryption, passwords per second Known plain text attack as used in EDPR, passwords per second
Intel Core i7 6700 170 000 5 400 000
Intel Core i7 9700K 345 000 11 400 000

 

Conclusion

The “tailor-made to delight” software for “new-age businesses” delivers the worst implementation of data protection we’ve seen in the last 20 years. It’s so bad we don’t know where to start from; there is no single aspect that’s done right. The encryption key is directly derived from the user’s password instead of using separate media encryption and key encryption keys. The homegrown algorithm deriving the encryption key from the user’s password is weak beyond imaginable; we couldn’t write as bad a hash function even if we tried. The DES-like encryption algorithm is outdated, while the 64-bit encryption key is way too short considering the outdated encryption algorithm. The known plain text metadata embedded in every encrypted page is icing on the cake. We just hope that new-age businesses will remain delighted if their encrypted data falls into the wrong hands.

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

VeraCrypt Encryption

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

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

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

VeraCrypt symmetric encryption algorithms

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

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

VeraCrypt hash functions

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

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

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

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

Using Elcomsoft Distributed Password Recovery to break VeraCrypt passwords

While VeraCrypt does protect its encrypted containers against brute-forcing the password, we have significant advances in password recovery attacks compared to what we had some ten years back. Brute-forcing a password today becomes significantly faster due to the use of GPU acceleration, distributed and cloud computing. Up to 10,000 computers and on-demand cloud instances can be used to attack a single password with Elcomsoft Distributed Password Recovery.

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

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

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

 

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

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

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

How fast, exactly?

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

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

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

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

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

Alternative attacks

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

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

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

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

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

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

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

Abstract and Summary

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

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

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

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

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

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

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

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

Test Bench

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

ASUSTOR NAS: eCryptfs Folder-Based Encryption

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

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

Encrypting

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

Creating an encrypted share

This is how an encrypted share is created.

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

The encryption password may contain 8 to 64 characters.

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

The usual access permissions are configured.

Once created, the encrypted folder is mounted automatically.

Exporting the encryption key

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

Mounting encrypted shares

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

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

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

Unmounting encrypted shares

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

Permanent decryption

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

Changing the password: impossible

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

Automatically Mounting Encrypted Folders

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

Manually Decrypting Encrypted Shares

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

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

/volume1/.@encdir/Test

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

Encrypted share “Test” mounted:

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

Encrypted share unmounted:

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

The encrypted folder was mounted with the following parameters:

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

To mount the encrypted share, execute the following commands.

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

ecryptfs-add-passphrase –fnek

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

mkdir /volume1/Test

Mount the encrypted folder in interactive mode:

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

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

What Risks Are Covered by ASUSTOR Security Model

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

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

Conclusion: ASUSTOR Folder Encryption

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

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

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

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

Pre-Requisites

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

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

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

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

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

The Attacks

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

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

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

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

Try Phone Numbers First

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

All-Digit Passwords

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

Targeting the Human Factor

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

Leaked passwords

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

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

Dictionaries

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

Mutations

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

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

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

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

Case mutation: different variations of uppercase and lowercase characters.

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

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

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

Masks

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

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

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

Combination and Hybrid attacks

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

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

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

Suggested Wi-Fi Password Auditing Workflow

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

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

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

Sideloading IPA Packages onto iOS Devices

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

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

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

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

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

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

Signed with a regular Apple ID

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

Signed with an Enterprise account

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

Signed with a Developer account

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

What Has Changed

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

Something had changed in November, 2019.

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

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

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

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

Developer Account Limitations

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

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

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

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

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

Workarounds

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

A Word On checkra1n & checkm8

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

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

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

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

And one of the responses:

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

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

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

Conclusion

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

Elcomsoft iOS Forensic Toolkit can perform full file system acquisition and decrypt the keychain from non-jailbroken iPhone and iPad devices. The caveat: the device must be running iOS 11 or 12 (except iOS 12.3, 12.3.1 and 12.4.1), and you must use an Apple ID registered in Apple’s Developer Program. In this article, I’ll explain the pros and contras of the new extraction method compared to traditional acquisition based on the jailbreak.

Why jailbreak?

Before I start talking about the new extraction method that does not require a jailbreak, let me cover the jailbreak first. In many cases, jailbreaking the device is the only way to obtain the file system and decrypt the keychain from iOS devices. Jailbreaking the device provides the required low-level access to the files and security keys inside the device, which is what we need to perform the extraction.

Jailbreaks have their negative points; lots of them in fact. Jailbreaking may be dangerous if not done properly. Jailbreaking the device can modify the file system (especially if you don’t pay close attention during the installation). A jailbreak installs lots of unnecessary stuff, which will be difficult to remove once you are done with extraction. Finally, jailbreaks are obtained from third-party sources; obtaining a jailbreak from the wrong source may expose the device to malware. For these and other reasons, jailbreaking may not be an option for some experts.

This is exactly what the new acquisition method is designed to overcome.

Agent-based extraction

The new extraction method is based on direct access to the file system, and does not require jailbreaking the device. Using agent-based extraction, you can can perform the full file system extraction and decrypt the keychain without the risks and footprint associated with third-party jailbreaks.

Agent-based extraction is new. In previous versions, iOS Forensic Toolkit offered the choice of advanced logical extraction (all devices) and full file system extraction with keychain decryption (jailbroken devices only). The second acquisition method required installing a jailbreak.

EIFT 5.30 introduced the third extraction method based on direct access to the file system. The new acquisition method utilizes an extraction agent we developed in-house. Once installed, the agent will talk to your computer, delivering significantly better speed and reliability compared to jailbreak-based extraction. In addition, agent-based extraction is completely safe as it neither modifies the system partition nor remounts the file system while performing automatic on-the-fly hashing of information being extracted. Agent-based extraction does not make any changes to user data, offering forensically sound extraction. Both the file system image and all keychain records are extracted and decrypted. Once you are done, you can remove the agent with a single command.

Compatibility of agent-based extraction

Jailbreak-free extraction is only available for a limited range of iOS devices. Supported devices range from the iPhone 5s all the way up to the iPhone Xr, Xs and Xs Max if they run any version of iOS from iOS 11 through iOS 12.4 (except iOS 12.3 and 12.3.1). Apple iPad devices running on the corresponding SoC are also supported. Here’s where agent-based extraction stands compared to other acquisition methods:

 

The differences between the four acquisition methods are as follows.

  1. Logical acquisition: works on all devices and versions of iOS and. Extracts backups, a few logs, can decrypt keychain items (not all of them). Extracts media files and app shared data.
  2. Extraction with a jailbreak: full file system extraction and keychain decryption. Only possible if a jailbreak is available for a given combination of iOS version and hardware.
  3. Extraction with checkra1n/checkm8: full file system extraction and keychain decryption. Utilizes a hardware exploit. Works on iOS 12.3-13.3.1. Compatibility is limited to A7..A11 devices (up to and including the iPhone X). Limited BFU extraction available if passcode unknown.
  4. Agent-based extraction: full file system extraction and keychain decryption. Does not require jailbreaking. Only possible for a limited range of iOS versions (iOS 11-12 except 12.3.1, 12.3.2, 12.4.1).

Prerequisites

Before you begin, you must have an Apple ID enrolled in Apple’s Developer Program in order to install the agent onto the iOS device being acquired. The Apple ID connected to that account must have two-factor authentication enabled. In addition, you will need to set up an Application-specific password in your Apple account, and use that app-specific password instead of the regular Apple ID password during the Agent installation.

Important: you can use your Developer Account for up to 100 devices of every type (e.g. 100 iPhones and 100 iPads). You can remove previously enrolled devices to make room for additional devices.

Using agent-based extraction

Once you have your Apple ID enrolled in Apple’s Developer Program, and have an app-specific password created, you can start with the agent.

 

  1. Connect the iOS device being acquired to your computer. Approve pairing request (you may have to enter the passcode on the device to do that).
  2. Launch Elcomsoft iOS Forensic Toolkit 5.30 or newer. The main menu will appear.
  3. We strongly recommend performing logical acquisition first (by creating the backup, extracting media files etc.)
  4. For agent-based extraction, you’ll be using numeric commands.
  5. Install the agent by using the ‘1’ (Install agent) command. You will have to enter your credentials (Apple ID and the app-specific password you’ve generated). Then type the ‘Team ID’ related to your developer account. Note that a non-developer Apple ID account is not sufficient to install the Agent. After the installation, start the Agent on the device and go back to the desktop to continue.
  6. Acquisition steps are similar to jailbreak-based acquisition, except that there is no need to use the ‘D’ (Disable lock) command. Leave the Agent (the iOS app) working in the foreground.
  7. Obtain the keychain by entering the ‘2’ command. A copy of the keychain will be saved.
  8. Extract the file system with the ‘3’ command. A file system image in the TAR format will be created.
  9. After you have finished the extraction, use the ‘4’ command to remove the agent from the device.

To analyse the file system image, use Elcomsoft Phone Viewer or an alternative forensic tool that supports .tar images. For analysing the keychain, use Elcomsoft Phone Breaker. For manual analysis, mount or unpack the image (we recommend using a UNIX or macOS system).

Conclusion

If you have unprocessed Apple devices with iOS 11 – 12.2 or 12.4, and if you cannot jailbreak for one or another reason, give the new extraction mode a try. iOS Forensic Toolkit 5.30 can pull the file system and decrypt the keychain, leaves no apparent traces, does not remount and does not modify the file system while offering safe, fast and reliable extraction.

We have updated Elcomsoft Cloud Explorer, our Google Account extraction tool, with Google Fit support. Google Fit is a relatively little known Google service aimed at tracking the user’s health and physical activities. In line with pretty much every other Google service, Google Fit synchronizes massive amounts of data with the user’s Google Account, storing activity-related information collected by all of the user’s devices in a single place. When extracting these data, we discovered massive amounts of location points stored alongside with information related to the user’s physical activities. Learn what is stored in Google Fit and how to extract it from the cloud!

What’s it all about

Google Fit extraction is about the massive amounts of data related to the user’s health and physical activities stored in the Google’s cloud. The detailed, high-frequency location data collected by Google’s fitness app accompanied with information about the user’s physical condition can be truly invaluable during an investigation.

Google Fit is not the only type of information collected by Google. The search giant collects massive amounts of information. The types of data range from many years worth of the user’s location history to all of the user’s password saved in the Chrome browser or used with Android apps. Google Photos, Gmail, contacts and calendars, search requests and Web history, voice snippets, call logs and text messages and a lot more can make for some invaluable evidence. While Google readily returns most of that data when serving legal requests, Elcomsoft Cloud Explorer offers a much easier and near-instant extraction solution that requires far less paperwork. Considering the number of fully encrypted Android smartphones that may or may not be physically unlocked, Elcomsoft Cloud Explorer becomes truly irreplaceable, discovering more evidence than ever by revealing the hidden data one would never imagine existed, browsing deep inside into the user’s online activities going many years back. Elcomsoft Cloud Explorer does what Google itself does not do, offering a single point for downloading, discovering and analyzing evidence collected by Google.

How Google Fit collects information

Google Fit is both an app and a service. The Google Fit app is available for Android and iOS platforms; it can be used on both Android phones and Apple iPhones. The Google Fit service processes and stores information collected from all supported devices where it’s installed in the user’s Google Account.

While many users associate Google Fit with WearOS smartwatches, in reality the app does not require a smartwatch or a fitness tracker. A connected activity tracking device can provide information such as the number of steps walked, the number of stairs climbed, the user’s hear rate or periodic location points obtained from the tracker’s GPS sensor. When used without a compatible fitness tracker, the Google Fit app can source activity data from a smart combination of the phone’s built-in low-energy sensors, frequently obtained location points and a lot of artificial intelligence.

Google Fit data extracted from the user’s Google Account returns massive amounts of precise location points, allowing to pinpoint the user’s location with ultimate precision and granularity. Access to comprehensive location history and other critical real-time evidence can be vital for investigating crime.

Obtaining Google Account credentials

In order to sign in to the user’s Google Account, one requires the full set of Google credentials. The login and password can be often extracted from the user’s computer (with Elcomsoft Internet Password Breaker), from the cloud (with Elcomsoft Phone Breaker) or iOS keychain (with Elcomsoft iOS Forensic Toolkit).

In addition, some data from the Google Account (Google Fit being a notable exception) can be accessed with a token. The token is literally a cookie in Chrome, and can be extracted from the user’s computer. Elcomsoft Cloud Explorer includes a utility that automatically locates and extracts the authentication token from the Chrome browser installed on the user’s Mac or Windows PC. Using the extracted token, Elcomsoft Cloud Explorer authenticates into the user’s Google Account and displays the list of categories available for extraction.

Accessing Google Fit data

In order to extract Google Fit data from the user’s Google Account, you will need Elcomsoft Cloud Explorer 2.30 or newer.

  1. Launch Elcomsoft Cloud Explorer and create a new snapshot. Authenticate with the user’s login and password (Google Account). If required, pass two-factor authentication.
  2. Select the “Google Fit” check box.
  3. The data will be downloaded in several seconds to several minutes.
  4. After the processing, you can access Google Fit data from the main window.

Analyzing Google Fit data

You will be able to sort or group activities. The “Sessions” tab displays activity sessions detected by the Google Fit app. Activity sessions may include sleeping, walking, jogging and other types of activities.

Note that the sessions are detected automatically by the various apps and devices. Have a look at the “Package name” tab to discover which package has detected which session.

“Steps” can be either raw data from the connected smartwatch or fitness tracker, or information generated by the Google Fit app based on a combination of the smartphone’s step counter, the user’s height, and a lot of location data. If no external smartwatch or activity tracker is connected, the Google Fit app uses artificial intelligence to calculate the number of steps based on the abovementioned data. The app only polls the smartphone’s built-in step sensor at large intervals, relying more on location data than on the step counter.

Walking and running activities are automatically detected by the app based on the user’s heart rate, step count and location data.

One of the most interesting reports is “Locations”. By design, Google Fit collects massive amounts or location data. The test account reports 13,788 location points in 9 month. Considering that our test device was used on few rare occasions, the number of location reports is truly excessive. Clicking on a location point opens Google Maps.

Conclusion

Google Fit data may contain detailed information about the user’s location and physical conditions including the number of steps, types of activity, heart rate, elevation, and a lot more. Additional information provided by compatible health tracking devices may include blood pressure, elevation, precise step count, and additional location data collected from the GPS sensor built into the smartwatch or tracker. Analyzing the massive amounts of Google Fit data can become invaluable help when searching for evidence and investigating crime. The detailed, high-frequency location data collected by Google’s fitness app accompanied with information about the user’s physical condition can shed light on the user’s activities in a given timeframe.

How can you make your system and documents secure? Today, 256-bit AES encryption is offered by everyone and their dog. However, AES encryption does not mean much (or anything at all) when it comes to the real security of your data. Implementing encryption at the right time and in the right spot is no less important than choosing strong encryption credentials and managing the encryption keys.

While the previous part may sound a bit complicated, it all comes down to much simpler things than choosing the strongest encryption algorithm or selecting the length of the encryption key. If you are a Windows user, it all comes down to choosing the optimal data protection strategy for your particular usage scenario; protecting your storage media and the data you keep on them.

Defining your goals

Before you start considering encrypting your hard drives and files, make sure to define your objectives. What information would you like to protect? What threats do you consider important, less important and quite improbable?

Full-disk encryption part I: protecting your boot device

A reliable system protection is impossible without protecting your boot device. An unencrypted boot device (disk C: on most systems) allows for way too many vectors of attack ranging from hibernation and page file analysis to instant extraction of stored passwords from your Web browser vault. In other words, securing your boot device with BitLocker is an absolutely mandatory preliminary step and the most important security layer.

  • Availability: Windows 10 Professional and higher with TPM2.0, Intel PTT or Group Policy edit; all Windows editions for device encryption in thin and light devices meeting minimum requirements.
    • Note: although Windows 10 Home cannot natively create new BitLocker volumes, it can unlock BitLocker encrypted drives with full read-write access
  • Physical access, hard drive only: strong protection
  • Physical access, entire computer: it’s complicated
  • Other users on the same computer: not applicable
  • Malware/ransomware: not applicable
  • Online attacks: not applicable
  • Usage cases: protect data against theft of computer or hard drive; protect data if hard drives are sold or RMA’d; protect data against physical extraction.

If your computer meets the requirements (namely, the presence of a hardware TPM2.0 module or software-based Intel Platform Trust Technology), enabling BitLocker on your computer can be as easy as opening the Control Panel and launching the BitLocker Drive Encryption applet. Note that not all editions of Windows 10 can use BitLocker protection.

We have a comprehensive article on BitLocker protection in our blog, which is highly recommended. Introduction to BitLocker: Protecting Your System Disk

What caveats are there when it comes to securing data against physical extraction? The thing is, while BitLocker is nearly a 100% effective solution for protecting the bare drive, it might not be as secure if the intruder has access to the entire computer with the hard drive installed. Even if your computer is equipped with a TPM2.0/Intel PTT module, Windows will still unlock the encrypted hard drive if Secure Boot conditions are met. This in turn opens numerous vectors of attack that may allow the intruder to intercept the on-the-fly BitLocker encryption key and decrypt the hard drive. These vectors of attack include:

  1. Making a RAM image of a running computer with BitLocker volume(s) mounted. This can be done via a Thunderbolt attack (Windows, by default, does not disable Thunderbolt DMA access when locked) or a cold boot attack.
  2. Breaking or extracting your Windows logon password (e.g. extracting from your Google account, your smartphone, or from another computer you have logged in and synced your data to).
  3. Obtaining your BitLocker Recovery Key from your Microsoft Account or Active Directory.

Advanced users and system administrators can read the following guide to secure their BitLocker volumes: BitLocker recovery guide

Full-disk encryption part II: protecting external storage devices

BitLocker is good not only for protecting your boot device, but for encrypting data on other volumes, built-in and removable. BitLocker protects external storage devices with BitLocker To Go, an encryption algorithm based on a password. In addition to passwords, external drives encrypted with BitLocker To Go have an option to unlock with a smart card on another computer by using BitLocker Drive Encryption in Control Panel. Finally, users can opt to make their encrypted external devices automatically unlock when connected to their (trusted) computer.

  • Availability:
    • Encrypt external devices: Windows 10 Professional and Enterprise
    • Access BitLocker encrypted devices: although Windows 10 Home cannot natively encrypt drives with BitLocker, it can access BitLocker encrypted drives with full read-write access
  • Physical access, device only: protection as strong as your password
  • Physical access, entire computer: it’s complicated (see previous chapter)
    • Note: if you enabled the option “Unlock automatically on this PC”, then effectively no protection
  • Other users on the same computer: strong protection if offline/not mounted
  • Malware/ransomware: strong protection if offline/not mounted
  • Online attacks: strong protection if offline/not mounted
  • Usage cases: protect data stored on external storage devices such as external drive enclosures, USB flash drives etc.

Unlike system drive encryption, BitLocker To Go does not support multifactor authentication. This means you cannot use TPM protection as an additional form of authentication. You can, however, make BitLocker To Go devices unlock automatically when they are inserted in your (trusted) computer, which carries obvious security implications.

Full-disk encryption part III: using third-party crypto containers

I put it here just for the sake of completeness. If you are considering using a crypto-container such as VeraCrypt or PGP, you probably know what it is good for and how to use it. I’ll just add several things that aren’t immediately obvious when you set up encryption. In fact, the two things are so non-obvious that many coach experts have it backwards. (The right way: Choosing the right hashing algorithm – it’s all about slowness).

  • Availability: VeraCrypt is available on most relevant platforms
  • Physical access, hard drive only: very strong protection unless misconfigured
    • Misconfiguration examples: volume stays mounted when computer sleeps or hibernates; volume stays mounted when computer is locked (matter of security vs. convenience); volume unlocked with security key (e.g. USB flash drive) and no password (if USB flash drive is discovered)
  • Physical access, entire computer:
    • volume not mounted at time of analysis: very strong protection
    • volume mounted: very little protection
  • Other users on the same computer
    • volume not mounted at time of analysis: very strong protection
    • volume mounted: very little protection
  • Malware/ransomware: same as above
  • Online attacks: same as above
  • Usage cases: protect data against theft of computer or hard drive; protect data if hard drives are sold or RMA’d; protect data against physical extraction.

The choice of encryption algorithm (spoiler: use AES)

Crypto containers such as VeraCrypt offer the choice of several (actually, multiple) encryption algorithms that range from the industry-standard AES to some quite exotic algorithms such as Serpent or Kuznyechik. For the paranoiacs among us, VeraCrypt offers stacked encryption (e.g. the Serpent(AES) option). The thing is, the choice of an encryption algorithm does not affect the security of your data (unless you pick an algorithm with known or suspected vulnerabilities; finger pointed to Kuznyechik).

The choice of encryption algorithm does not affect the security of your data. A single round AES-256 encryption will be exactly as secure as Serpent(AES) or Serpent(Twofish(AES)). Moreover, the choice of encryption does not even affect the recovery speed (the speed of brute-force attacks on your password)!

Considering that AES is the only hardware-accelerated encryption algorithm in all reasonably modern processors, choosing any encryption algorithm other than AES-256 will unnecessarily slow down your reads and writes (expect a difference of 2 to 3 orders of magnitude in theoretical RAM-to-RAM encryption speeds) without providing any additional security benefit.

If choosing an encryption algorithm other than AES does not affect security, then what does?

The choice of hashing algorithm

When VeraCrypt encrypts (or decrypts) your data, it is using a binary encryption key to perform symmetric cryptographic operations. This media encryption key (MEK) is stored along with the encrypted data. The Media Encryption Key (MEK) is encrypted with a Key Encryption Key (KEK), which, in turn, is the result of multiple (hundreds of thousands) iterative hash operations performed on the user’s password.

In other words, when you type a password, the crypto container will perform a calculation of a certain hash function, and repeat that a 100,000 times or more (in order to deliberately slow down brute-force attacks).

If you want to make your encrypted volume more secure, you can change one of the two things:

  1. Increase the number of hash iterations
  2. Don’t use defaults
  3. Choose a slower hash function

VeraCrypt allows modifying the number of hash iterations by adjusting the PIM (Personal Iterations Multiplier); here is the how-to. The PIM value controls the number of iterations that is used to derive the encryption key from the password that you type. This value can be specified through the password dialog or in the command line. If you don’t manually specify the PIM value, VeraCrypt will use the default number of iterations, which is bad because (2). For SHA-512 or Whirlpool (the two recommended choices), VeraCrypt defaults to Iterations = 15000 + (PIM x 1000).

Why would you want to change the number of hash iterations? Because an attacker will first try to break your password using the defaults. Most tools used by the attackers to brute-force your password will first run the attack using all-defaults: the default encryption algorithm (AES), hash function (SHA-512) and PIM. Changing the PIM value is an easy way to substantially increase security without making your password more complex. Changing the hashing algorithm from default (SHA-512) to Whirlpool also makes sense in this context.

Which brings us to the choice of a hashing algorithm. VeraCrypt offers the choice of SHA-512 (slow, good choice), Whirlpool (slower, even better choice), SHA-256 (slow, but not as slow as SHA-512, use other hash instead), and Streebog (untested). Choosing the right hashing algorithm – it’s all about slowness has some benchmarks and some good explanations; highly recommended. Selecting Whirlpool makes a lot of sense because a) it is slower than SHA-512 (thus will be significantly slower to attack), and b) it is a non-default selection, which significantly increases the complexity of the attack.

File system encryption: when and how to use EFS

If you read the Wikipedia article about Microsoft Encrypting File System (EFS), you’ll get that EFS has been introduced in NTFS 3.0 in order to provides file system level encryption. The article reads: “The technology enables files to be transparently encrypted to protect confidential data from attackers with physical access to the computer.”

While all of that is interesting, neither statement explains who and, most importantly, why should be using EFS, and what exactly the encrypting file system protects against.

  • Availability: all versions and all editions of Windows 10 (and most older versions of Windows)
  • Physical access, hard drive only: as strong as your Windows account password
  • Physical access, entire computer: same as above
  • Other users on the same computer: effective protection
  • Malware/ransomware: not applicable
  • Online attacks: not applicable
  • Usage cases: protect your documents from other users of your computer; an extra layer of security on BitLocker-protected drives; reasonably strong, very easy and fully transparent document encryption on computers where BitLocker is not supported.

What does EFS protect against, and who should be using it?

The purpose of Encrypting File System is protecting your data from users who share your computer. If you have a PC with several users, and each user has their own Windows login (as opposed to sharing a single Windows account), activating EFS encryption is the easiest way to protect your files from being accessed by those other users.

What is the relation between EFS and BitLocker, and which one should you use?

BitLocker protects your entire system volume. Any user who can log in to your computer will unlock the system volume. If a user has administrative privileges (or can escalate a non-admin account by using an exploit), he or she will also gain access to files and documents stored in other users’ accounts on that computer.

Encrypting File System, on the other hand, only protects selected folders. It won’t, for example, protect your instant messenger databases or encrypt your browsing history. It’s mostly just for documents, pictures and videos you keep in your account. However, EFS will effectively protect those files against other users who can log on to your computer, even if they have administrative privileges.

If an attacker got physical access to the computer, BitLocker is the first line of defence. Relying solely on EFS to secure the PC against attacks with physical access is not the best idea.

How does it all work? It’s actually quite simple. Right-click on a file or folder you’d like to encrypt, select Properties and click the Advanced button in the General tab. In the Advanced Attributes dialog select Encrypt contents to secure data and click OK.

This is it. Windows will now encrypt the selected file or folder with your Windows logon credentials. There are no passwords to type and no encryption keys to save.

There is a certain drawback to using EFS encryption. If you ever forget your Windows password and have to reset it from a separate Administrator account (or your domain administrator resets the password for you), the EFS encryption keys will be lost, and you will be unable to decrypt your data without going through the data recovery process with Elcomsoft Advanced EFS Data Recovery. Note that you must recover your Windows password in order to decrypt the files. However, if you simply change your Windows password by following the normal procedure (typing your old password followed by entering the new one), you will be fine.

Document encryption

Encrypting individual documents is an important part of multi-layer security. Microsoft Office apps can use passwords to encrypt the documents’ content. No one without a password should be able to decrypt the document.

  • Availability: all versions of Microsoft Office
  • Security: depends on the version of Microsoft Office, the file format you’re using to save the files and the strength of your password.
  • Physical access, hard drive only: strong protection (with caveats)
  • Physical access, entire computer: strong protection (with caveats)
  • Other users on the same computer: strong protection (with caveats)
  • Other users on your Local Area Network: strong protection (with caveats)
  • Malware/ransomware: content protection. Malware won’t be able to decrypt your files and read your data. However, malware/ransomware can still encrypt your files, effectively locking you out.
  • Online attacks: content protection. Strong protection against unauthorized data access; no protection against unauthorized deletion
  • Usage cases: protect the content of your documents against anyone who does not know the encryption password.
  • How to: Protect a document with a password

A million dollar question: if you are on a local area network, should you use EFS or document encryption to protect documents against other users on the same LAN? In this case, it’s better to use both. EFS will make it impossible to gain access to encrypted files and folders without knowing your Windows account/domain credentials. Password protection of individual documents will make documents difficult to break even if the attacker knows your logon credentials.

The caveats of document encryption

So what exactly does “strong protection (with caveats)” mean? The thing is, your documents are just as secure as the password you use to protect them. If you re-use a password you already stored in your browser cache or in the keychain, extracting that password and decrypting the documents will be a matter of minutes in many types of attacks.

What if you use a cryptographically strong and truly unique password to encrypt documents? Are these documents secure? The thing is, they will be just as secure as the office app permits them to be. In Microsoft Office encryption evolution: from Office 97 to Office 2019 I discussed the encryption algorithms and protection strength of Microsoft Office apps from the early days to the most current release.

Generally speaking, everything before Office 2000 was insecure (no protection). Office 2000, XP and Office 2003 had very weak encryption that can be usually broken in under a day.

Since Office 2007, Microsoft started taking encryption seriously. Office 2010, 2013, 2016, 2019 brought security to the new level, making encrypted documents very secure.

Okay, so you are using the latest Office and selected a strong password; are we secure now? The thing is, you’ll be just as secure as the document format allows. If you are using the newer DOCX/XLSX format (files with .docx / .xlsx extensions), you’re good. If, however, you are saving your documents in “compatibility” mode, you are sacrificing encryption and make your documents as vulnerable as if they were saved by an Office 2003 app.

Best practices:

  1. Use the latest version of Microsoft Office to save documents. If the latest version is not available, use at least Office 2013 (the newer the better).
  2. Never save documents in “compatibility” mode. Make sure that the files are DOCX/XLSX as opposed to DOC/XLS.
  3. Use a unique, cryptographically strong password to encrypt documents. Remember: if the password is broken once (e.g. pulled from your Google account or recovered from a document you accidentally saved in the “compatible” format), it will be used to break everything else, including documents with strong encryption.
  4. If you email an encrypted document, do use a unique, one-time password for that document, and never send both the document and the password in the same email. In fact, you should never send the password by email since that would allow an attacker who gained access to your email account to decrypt the document. Send the document and the password via separate communication channels (e.g. email / text message, chat or phone call).

Protecting backups and archives

Making regular backups is a common wisdom. Protecting those backups is a wisdom much less common. Once you make a backup, make sure to give it as strong a protection as your boot drive.

  1. Store backups on BitLocker-protected media. Even if your backup tool (e.g. the one built into Windows) does not support encryption, at very least your storage media is protected with full-disk encryption. Note: Windows 10 does support the recovery from BitLocker-protected disks. Just create a bootable install image from Microsoft Web site (use “Create Windows 10 installation media”).
  2. If your backup tool supports encryption, it may be a good idea to encrypt your backups (AND store them on a BitLocker-protected media). Note, however, that a backup tool will probably cache (store) your backup password on your computer to automatically encrypt new and incremental backups. For this reason, make sure to have a truly unique, never reused password for encrypting backups.

Individual folders are frequently backed up using common archive tools such as WinZip, 7Zip or WinRar. All of these tools offer the ability to encrypt archives with a password. While the encryption strength is different among the three formats (ZIP, 7Z and RAR), an up to date version of each tool provides adequate protection if you choose a reasonably complex password (e.g. 8 characters or more, combining small and capital letters with numbers and special characters). To achieve the best level of protection, do keep those archives on BitLocker-protected media.

Note that password recovery tools work significantly faster on ZIP/7Z/RAR compared to attacking BitLocker encryption or Office 2013 (and newer) documents. For this reason, never reuse your password, and make sure that your BitLocker media, your documents and your backups/archives use very different passwords (ideally, not based on the same pattern).

More information:

Cloud security: OneDrive Personal Vault

Microsoft started offering an extra layer of security to all users of its cloud storage service in the form of a Personal Vault. OneDrive Personal Vault helps secure your files both on your computer and in the cloud in the event that someone gains access to your account or your device.

Unlike ransomware protection, Personal Vault is available to all users of Microsoft OneDrive and not just to Office 365 subscribers. Technically speaking, Personal Vault is an area in the OneDrive folder on your computer and in the OneDrive cloud storage that features additional protection. You can only access this protected area after passing a strong authentication. If your Microsoft Account is protected with two-factor authentication, you will have to pass the second step of identity verification in addition to typing your Microsoft Account password.

Once configured, Personal Vault must be manually unlocked every time you need access to secured data. To unlock, you must type in your Microsoft Account password and pass the second authentication step if your account has two-factor authentication. Once you’ve finished accessing the data, Personal Vault will automatically relock after a short period of inactivity. Once locked, any files you were using will also lock and require re-authentication to access.

Setting up Personal Vault only takes a few clicks as outlined in Protect your OneDrive files in Personal Vault.

OneDrive Personal Vault is still new; no independent security analysis has been performed until today. In our view, Personal Vault is worth consideration as an extra security layer for some of the most private but rarely accessed types of data. Examples of such data may include BitLocker escrow keys and binary encryption keys, or the list of passwords some users store in encrypted Excel spreadsheets. I personally keep my two-factor authentication secrets (scanned QR codes to initialize the Authenticator app) in the Vault as well.

  • Physical access: unknown (not yet analyzed)
  • Other users on the same computer: strong protection
  • Malware/ransomware: strong protection (unless Personal Vault is unlocked at the time malware is running)
  • Online attacks: as strong as your Microsoft Account security
  • Usage cases: activate to add an extra layer of security for a handful of personal documents, encryption keys, 2fa secrets etc.

 

Ransomware protection

One of the most important threats not covered by any encryption is the type of malware called ransomware. Ransomware is a type of malware that threatens to either publish the data stolen from the victim or perpetually block access to the victim’s files by encrypting them with a key that is only known to the attacker. The term ‘ransomware’ has emerged from the fact that, on many cases, attackers demand a ransom payment to decrypt data.

Protecting your data against ransomware is a complex topic in itself. However, computer users can choose one or both of the following two defences when it comes to ransomware protection.

Ransomware protection is effective against the following threats.

  • Physical access: no protection
  • Other users on the same computer: no protection
  • Malware/ransomware: effective protection
  • Online attacks: as strong as your cloud account security
  • Usage cases: available automatically to Office 365 subscribers. Available to paid Dropbox users. Automatically protects files stored in OneDrive/Dropbox. Automatic alerts (OneDrive only). Automatic restore (OneDrive only); manual restore (Dropbox).

Use cloud storage with automatic ransomware protection

If you are using Windows 10, most likely you already have a Microsoft Account. The Microsoft Account gives you access to OneDrive, Microsoft’s cloud storage solution. The free tier includes 5 to 15 GB of online storage, while Office 365 subscribers receive the whole terabyte of cloud storage.

Microsoft actively promotes OneDrive Ransomware Protection. OneDrive automatically detects when the files are mass-deleted or mass-edited (such as when ransomware encrypts the entire Documents folder), alerts the user and prompts to restore the known-good snapshot. The File Restore feature is only available to Office 365 subscribers (Home and Personal levels are enough to receive protection).

More information at Ransomware detection and recovering your files.

If you prefer Dropbox to Microsoft OneDrive, Dropbox gets you covered against ransomware attacks, but mostly for higher-level paid tiers. Users of the free Basic tier as well as Plus subscribers can roll back individual encrypted files during the first 30 days after the attack (there will be no warning of mass-deletion of mass-encryption of files coming from the Dropbox app). If you want to roll back the entire Documents folder with Dropbox Rewind, you’ll need to be a paid Plus or Professional tier subscriber.

More information:

Make backup snapshots. Keep backup media offline

Once ransomware is installed on your computer, it will try to encrypt every document that is accessible. The obvious solution is making documents inaccessible by physically disconnecting backup media (such as using 2.5” portable USB drives to back up). In this scenario, you would only connect backup media to your computer when you actually want to make the backup, disconnecting the disk after the backup tool finishes its job. With this approach, even if your computer is attacked by ransomware, your offline backups will not be affected (unless you connected the external drive to the computer at the time the ransomware was installed).

In addition, configure your backup tool to keep snapshots of your data going back as long as permitted by available storage. In our office, an affordable 4TB USB hard drive can keep approximately 30 to 40 full snapshots of the Documents folder; this number becomes significantly larger if you enable incremental backups, with each snapshot saving only

More information: