6 Cryptographic Attacks You Should Know
| certifications | security - Matt McClure

6 Cryptographic Attacks You Should Know

Sometimes to rob a casino you need to plan a complex, Ocean’s Eleven-level heist, complete with a Boeski, a Jim Brown, etc. Or sometimes, you just grab a lockbox and run. That’s kind of like the difference between a lot of complex pentesting techniques and the most common cryptographic attack: the brute force. Instead of a carefully crafted payload or custom-written buffer overflow, you just throw passwords until one works.

There are actually five cryptographic attacks you need to know about, all involving circumventing a system’s authentication to gain access. Let’s look closer at the brute force attack and its five crypto cousins.

1. Brute Force

A brute force attack is just what it sounds like: applying as much muscle as possible to guess a login. This usually comes in the form of a wordlist, like those in the infamous SecLists repo (NSFW language in some of these, BTW) and a tool in Kali like Hydra. Put them together and you’ve got a strong weapon against any number of protocols requiring authentication — from FTP to SSH to VNC to SMB and different types of HTTP authentication methods, like basic authentication and form data. Given a known user name, the tool automates login attempts against a host with each password on the list until it is either successful or runs out of passwords.

The brute force attack works on one basic idea: your password isn’t very original. And we’re not talking as simple as “password” or “123456.” Some of these wordlists are massive, with tens of millions of passwords.

A brute force isn’t perfect however, it usually requires a good amount of time and luck. No tool can throw logins against a server as quickly as possible, you’d essentially DoS the host and all your connections would start to drop. Also a competent dev should automatically block an IP spamming their server with bogus login requests. There are more elegant attacks however.

2. Rainbow Tables

To understand rainbow tables, first we need a quick review on hashes. Rarely would an application store user passwords in plain text, they are usually stored as hashes. A hash is the result of running a password through a one-way algorithm like MD5 or SHA-1, and producing a string of random characters. The algorithm being one-way is key here. If the hashes are compromised, the hacker cannot simply reverse the hashing process to output a password, even if they know which algorithm was used.

When you login to an application, the app hashes your password and compares the hash to what is stored in the user database. Since the algorithm will always output an identical hash given the same password, it’s a safe way to authenticate a user without the system storing the actual password.

Safe, that is, until a hacker steals databases containing the hashes (the norm for many of the data breaches in the news). The problems really start when you realize that the hash for a given password is always the same. What if you simply run a wordlist through a hashing algorithm, store every generated hash, then compare stolen hashes to this file? This file is a rainbow table, — there are entire websites devoted to hosting and searching them for your hashes. Heck, sometimes you’ll get lucky just Googling a hash.

Most modern apps now use algorithms that add salting, which introduces some randomness to the generated hash. There are still lots of legacy apps and OSes out there using old school algorithms with no salting though.

3. Offline Hash Cracking

Brute force attacks are known as online attacks. You have to be online and able to connect to the service you are trying to compromise in order to make any progress. Without sending and receiving a response across the network, you’ll get nowhere fast. If your IP is blocked, your attack stops.

If you get a hold of some hashes though, and your rainbow tables turn up empty, you can work on an offline crack. We’ll make it even harder: the hashes are salted, so there’s no way to expect to ever find them in any rainbow table. One option is to take a tool like Hashcat, feed it your hashes and a word list, and it will essentially generate rainbow tables on the fly. The real power though comes from configuring Hashcat to use your GPUs to jam through all the hashing calculations — much like Bitcoin mining. With a decent GPU, it’s not hard to go through tens of millions of hashes a second.

4. Collisions

Also related to hashes, collision attacks on passwords are more of a happy accident than an intentional hacking tool. Computed hashes are always a fixed length regardless of the length of the input. For example, the MD5 hash of a single letter and an MD5 hash of the Declaration of Independence are both going to be 32 bytes long. So given an infinite number of possible strings, eventually you will find two strings that generate the same hash.

In a theoretical situation, if the passwords “mypass” and “sUpERC0mpl3xP@ssw0rd!” produce the same hash, both will grant access to your account since the system is only looking for the hash to match what’s stored in the user database. Given a brute force attack with the most basic wordlist, your complex password is rendered not so complex.

In the real world though this is almost statistically impossible, and more modern hashing methods have proven to be much more collision-resistant. The older MD5 hash, for example, is no longer considered secure as intentionally generating collisions; using it is trivial. The more recent SHA-1, while more complex, is also generally regarded now as not collision-resistant. The current standard, SHA-2, has not yet been shown to be vulnerable in this regard.

A more practical use of collisions though is in file verification. Hashes are commonly used to verify that a file you downloaded is the actual file promised. Look for example at this page from Apache OpenOffice. For any language and OS, they provide the ASC, MD5, and SHA256 checksums for the installer files. You download the file yourself, hash it, and compare your hash to the checksum to verify the file integrity.

Another common use of checksums is automatic downloads like computer and phone OS updates. Imagine what could happen if your OS installed an update not realizing that the original file was replaced with a malicious binary by some bad actor? We’re talking about automated widespread installation of malware across millions of devices!

Take it one step further with collision attacks. If a malicious file produces the same hash as the legit one, we’re in big trouble. This is exactly what researchers at Google did in 2017. They were able to create distinct PDF files that generated the same SHA-1 hashes. It took an enormous amount of computing power, but they proved that it is possible and that, while already depreciated, SHA-1 needs to be buried and dead ASAP.

5. Birthday Attacks

These are a subset of collision attacks. Instead of looking at the low chance of matching two passwords that generate the same hash, you are looking at the disproportionately greater probability that, given a large set of hashes, any two of them will result in a collision. It’s a really heavy concept involving statistics and probability theory without as much real world hacking value. If you really want to dig in though be our guest.

6. Replay Attacks

These are pretty straightforward: a bad guy intercepts a valid data transmission then turns around and resends it. It can be a password that you capture unencrypted on the wire then use to login as the user. It can apply to physical attacks, like capturing and retransmitting the radio signal on a wireless car key fob. But one of the most fun attacks is on Windows domains using a technique called pass-the-hash.

One way to run this attack starts with a Metasploit module that runs an SMB server on your machine. Then social engineer a user to open a share on your “file server.” Windows tries to connect, transmitting their domain username and password hash in an attempt to authenticate against your share. Metasploit captures the login request, then the attacker uses that hash to authenticate onto different parts of the network. Maybe an RDP login, maybe onto other legit SMB shares, maybe that sysadmin you duped just gave you domain admin keys to the entire network.

It’s not always this cut and dry. Microsoft has done a lot to patch out vulnerabilities both in capturing user hashes and replaying them, but when it works it can be quite effective. Loads of material has been written about how best to pull it off, what works and what doesn’t, and what MS updates have made it harder. This is an excellent in depth article if you want to learn more.

Wrapping Up

There are so many more ways to bypass authentication, these only represent some of the most common. As security measures improve, the bad guys keep upping their game as well, finding new techniques and refining old ones. Keep your systems patched, keep your passwords long and secure, and ultimately keep your fingers crossed that you stay off of the radar of a hacker well-versed in these and other crypto attacks.



Ultimate Security Cert Guide

A 62-page guide to every Palo Alto, Offensive Security, (ISC)2, Check Point, CompTIA, and Cisco certification, and how they fit into your career.

I have read and understood the privacy policy, and am able to consent to it.