How to crack Ubuntu encryption and passwords

During Positive Hack Days V, I made a fast track presentation about eCryptfs and password cracking. The idea came to me after using one feature of Ubuntu which consists in encrypting the home folder directory. This option can be selected during installation or activated later.
UbuntuEncryptSetup
If you select this option, nothing changes for the user except that data in his home folder is encrypted. I was interested to know how this process works since the passphrase for decryption is never requested. I discovered that eCryptfs is included in the GNU/Linux kernel and tools called ecryptfs-utils are used to setup the home folder encryption by the Ubuntu distribution.

After reading the code, I discovered how the encryption is performed. First a 16-byte random passphrase is generated. This passphrase will be used with AES-128 to encrypt and decrypt the data in the folder. This passphrase is stored encrypted in the file

/home/.ecrpytfs/$USER/.ecrpytfs/wrapped-passphrase

The process of encrypting the passphrase is called key wrapping. To generate a wrapping key used to wrap the passphrase, an 8-byte salt and a password are concatenated and given as input to SHA-512. The result is hashed again 65535 times. As shown by the following figure:wrappingkey
The 16 first bytes of the result are the wrapping key. The intermediate result is hashed one more time and the 8 first bytes of this operation represent the signature of the wrapping key. The passphrase is encrypted with the wrapping key using AES-128 and stored with the signature in the wrapped-passphrase file as shown here:

wrappedpassphrasev1

To unwrap the key the process is similar, the salt and the password are hashed 65536 times.

unwrappingkey

The result is hashed one more time. If the 8-byte signature obtained matches the one stored in the file then eCryptfs detects that the correct wrapping key has been generated. Thus it can unwrap the passphrase for file decryption.

From an adversary’s point of view, to recover the passphrase, the naive approach would be to brute-force the passphrase with encrypted data. However since it is randomly generated over 16-bytes the brute-force approach is not practical. The adversary can also try to brute-force the password used during the key wrapping and thus he would be able to generate the wrapping key and recover the passphrase. He could use precomputed dictionaries or rainbow tables over the signature to recover the password but as a salt is used in the wrapping process this makes such attacks much more difficult.

At this point, I noticed that, for Ubuntu systems, the password used in the wrapping process is directly the login password. This explains why no further information is asked when performing home folder decryption. It means that an adversary who is able to crack the wrapping password will not only obtain the passphrase but also the user password. Next I looked how the salt is generated since it is not stored anywhere in the wrapped-passphrase file. I finally found in the code that ecryptfs-utils is looking for a salt in the configuration file

$HOME/.ecryptfsrc

If the file does not exist, a default value of 0x0011223344556677 is used. This behavior had already been noted previously.

For a system using eCryptfs, as the configuration file is stored in the (now encrypted) home folder it cannot be found and so the default salt value is used to decrpyt the home folder.

In practical terms this means that, for a system to use this version of eCryptfs the salt value used must be the default value. If not, the initial encryption, using a salt from ~/.ecryptfsrc would never be decrypted correctly as, now unable to find the config file, eCryptfs would apply the default salt at the moment of decryption.
dictionnaryattackCleary a precomputed dictionary attack or a rainbow table attack can be mounted against such a system in order to crack the user passwords. To set-up such an attack, I looked at my favorite cracking tool: John the ripper (JTR) and I discovered that the algorithm was already implemented in the 1.8.0-jumbo version. The format is

$ecryptfs$0$1$0011223344556677$21ff10301b5457e1

where the pink value is obviously the salt and the green value is the signature corresponding to the password you want to crack.

I also noticed a Python script ecryptfs2john.py in JTR which directly read the wrapped-passphrase file and convert it to the correct format. The algorithm is also implemented in hashcat. As a proof of concept, I computed a dictionary of 14 million signatures based on the famous rock you dictionary. It took me about one month on my personal computer. But with this dictionary it is now possible to reverse a signature with a single look up assuming the password was in the rock you list of password. This dictionnary is available at https://github.com/kudelskisecurity/ecryptfs-dictionary-v1.

Of course we notified the ecryptfs-utils developers about the problem with Ubuntu distributions, a CVE was opened and quickly corrected. They issued a new file format for the wrapped-passphrase file. It now starts with 0x3a02. The salt is generated from /dev/urandom/ and stored in the same file by default. The old version files are automatically converted after the update and a logoff. To ensure the correction was successfully applied to your system you should check the wrapped-passphrase file. The new file contents should look like this:

wrappedpassphrasev2

Even with the correction the user password is still exposed to bruteforce attack with a randomly generated salt. However the standard Linux password hashing is 5000 iterations of SHA-512 which is easier to crack compared to the 65536 iterations of eCryptfs. As such, and due to the dual use of this password the eCryptfs implementation is a less interesting target for a password cracker. In the future it could be interesting if Argon2, the winner of the Password Hashing Competition, could be used eCryptfs.

My PHDays slides are available here.

Creative Commons License

Defcon 2015 CTF finals

Following the Blackhat conference, I participated to Defcon CTF finals as part of the 0daysober team which qualified in 10th position last June. This event is organized by Legit BS  for the last 2 years.

Principle

In order to participate to the finals you have to either win a qualifying event (PlaidCTF, Boston Key Party, GitS, …) or finish in the top 10 teams during Defcon CTF qualifier, which was 0daysober case this year. Unlike the official qualifier which is in jeopardy style with challenges in categories such as pwnables, reverse, misc, babys-first and coding, the finals are in the true Capture The Flag mode with only pwnables.

Each team is given access to the similar set of hosts running challenges opened gradually through the 3 days of the CTF. Those hosts are only accessible during the day (10am – 7pm) , meaning that teams have to continue to work on the challenges offline at night (after a beer-break :)). This last point can however be more complicated when challenges require connectivity to a server, like irkd or hackermud this year.

As this is a CTF teams have to find vulnerabilities in the services to both attack other teams and also patch them to prevent its flags to be stolen by others. Teams can score points on services every 5 minutes by submitting stolen flags to the organisers system. For each flag per service per team successfully exploited a team wins points. Scoring is also impacted when a team is successfully attacked or when its services are not available. As such, it is not possible to “patch” services by preventing connections.

Every 15 minutes the organisers were releasing the network traffic that was directed at each team network in the form of PCAP files.

Challenges

Traditionally Defcon CTF finals challenges were 32-bit binaries running on FreeBSD. This has since evolved and services are now running on multiple architectures and OSes. The first one that was available was running on Linux x64 which is quite standard. Then came Linux services on MIPS (running on a Ci20 board) and AArch64. After joking on releasing a challenge running on Sparc, the organisers finally opened a challenge on Windows…IoT. That was quite a surprise and although we were more or less prepared to handle Windows challenges, the ARM one was not at all expected. Also, this challenge required a RaspberryPie2 if you wanted to debug your exploit on the side.

Each services had various types of vulnerabilities (buffer overflow, integer overflow, string format bug, …) and sometimes required to exploit other vulnerabilities like memory leak or off-by-one to be fully exploited and bypass protections such as ASLR and DEP. Some challenges also required to first reverse engineer the encrypted protocol it was using in order to understand how to reach the vulnerable code.

One of the challenge was quite different as it was limited to the first 4 teams that solved the AArch64 one and was in a sudden-death mode (only first player to solve it gets the points). As we were part of those 4, one of our team member participated in a livectf which consisted in exploiting another AArch64 binary but requiring a ROP exploit this time. Although quite close, PPP went for the win and gained 1000 points. This special event was filmed and should be soon available online on Youtube/Twitch.

Team

During these Defcon finals we were 8 on-site, each focussing on a specific task such as reverse engineering, exploit writing, binaries patching, monitoring and PCAP analysis to reverse other teams exploits. We were also helped by remote elite reverser/pwner during those 3 days.

For me it was a first at Defcon CTF but some team members already played the finals last year under the w3stormz name.

0daysober

0daysober

Conclusion

For a first experience at the Defcon finals it was quite a success since we ended-up at the third place, right behind PPP (second) and DEFKOR (first). The winning team, DEFKOR, is really ahead in the game and looked untouchable during the event, as well as during other CTF during this year.

Having created challenges for CTF events before, I can imagine the work that Legit BS had to do so everything went smoothly during these finals. Big thanks to them for organising it!

Knock knock. Who’s there? Not me.

tl;dr; Port scanning the entire IPv4 address space daily for months at a time generates a lot of very juicy data — and more than a few administrative complains. However, the results of such an exercise are well worth the burden … read more to find out …

While port-scanning a few hosts here and there with nmap can be fun and usually quite easy, doing the same cannot be said when scanning the entire IPv4 address space. Operations of that scale tend to be much more challenging:

  • You need to be fast if you want daily results; things like your bandwidth and choice of scanning tools start becoming essential considerations.
  • You have to be fair with others.
  • You have to be as stealthy as possible if you want to avoid (too much) administrative burden, such as having to handle abuse letters.

So what do you actually need to port scan IPv4 continuously? Continue reading

Black Hat USA 2015

Last week I attended Blackhat USA as part of a trip to Las Vegas to participate in DEFCON CTF finals with the 0daysober team. Here is a summary of the talks I was able to attend.

“Why security data science matter and how it’s different: pitfalls and promises of data science based breach detection and threat intelligence”

Having followed this field during the past year, I was quite interested in the content of this presentation. The speaker reminded us of the core principles on which data science is based: data acquisition and storage, machine learning and visualization. I unfortunately did not attend the second session which focused more on real examples.

Continue reading

OpenSSH jump-host and file-transfer

This article was inspired by a previous post on my personal blog: https://www.freeture.ch/?p=815

Intro

OpenSSH is a great tool, everybody knows that (even Microsoft). It’s commonly used to securely take control or copy a bunch of files to or from remote machines. Another common scenario is to have a machine between two networks that acts as a gateway or “jump-host” between those networks; you connect to this machine and from there you open another connection to the other network. Something annoying is when you want to transfer files between the two networks, you’ll have to copy the files two times, once from the source to the gateway and then from the gateway to the destination. So if your files are huge, it means having disk space available on the jump-host and if you do so frequently it’s a headache; and everybody knows that sysadmins are lazy guys.

This tutorial will explain how to copy files from the source to the target directly and vice-versa.

Big-picture

In my example, target server (srv2) is behind a firewalled + NATed connection at home2 and we have no access to the router, so we can’t configure port-forwarding. Outbound connection is not filtered though, so we will initiate a reverse-tunnel to join the jump-host (srv1.com) so connection can then be initiated from srv1.com to srv2 through that persistent tunnel. Then we will configure the client machine located at home1 to access srv2 through srv1.com reverse-tunnel. We will finish with a bunch of example on how to transfer files between the client and srv2. The whole setup will use public key authentication instead of static passwords.

bigpicture

config

Step 1: Let’s start srv2 and srv1.com reverse-tunnel configuration:

Continue reading

Positive Hack Days V

P1040717
I recently attended the Positive Hack Days V forum which took place in Moscow over two days. Interesting and diverse presentations were given there together with some interesting contests.

The first contest started online one week before the forum itself. It was the Hash runner challenge which consisted of cracking password hashes. The algorithms to crack were NTLM, SHA-1, MD5, LM, SHA-256, and the Russian standard GOST R 34.11. The Hashcat team won this contest.

During the other contests, each team represented a group of hackers from the virtual state: the United States of Soviet Union. These groups were asked to compromise fictional companies such as a railway company (Choo Choo Pwn), or a mobile operator (MiTM Mobile). In addition, this year, an industrial system challenge was set up about a power plant (Digital Substation Takeover).P1040718 A PHD Stock Market was also implemented to allow teams to sell their exploits and gain more points or even to be compromised themselves. Videos reporting news of the challenge advances were projected during the forum. More Smoked Leet Chicken won the contest. Last but not least the (in)famous 2drink2hack contest. The goal was to hack a Web Application Firewall while drinking a shot of tequila at each stage of the contest!!

Meanwhile, very interesting talks were given in parallel. I first attended the fast track session where results about de-anonymizing Tor users were presented by a team from Kaspersky Lab. They gave the example of the creator of Silk Road who was arrested despite many of the details about the techniques used by the FBI on Tor remain unknown. They explained how to track users with fingerprinting in Tor with JavaScript and gave a proof of concept to illustrate their claims.

Continue reading

Lazy Crypto Reloaded

simplicity.jpg

After figuring out how to design secure ciphers, cryptographers tried to find how to make secure ciphers as simple as possible. Permutation-based cryptography is the latest trend in symmetric cryptography. For example, the SHA-3 winner Keccak is based on a simple construction that iterates XORs of message chunks with the internal state with permutations of the said state. The Keccak team extended this simplistic construction to other crypto functionalities such as pseudorandom generation and authenticated encryption. With permutation-based ciphers, you get rid of key schedules, for example. Overall, it’s less stuff to design, less stuff to code, to debug, and thus hopefully fewer design flaws and fewer bugs. This approach has been successful so far with Keccak, and in SipHash and NORX.

Continue reading