If you can’t hack the user, you may be able to hack the cryptography. In this video, you’ll learn about some common cryptographic attacks.
<< Previous Video: Wireless Disassociation Attacks Next: Threat Actors >>
So you’ve taken some data and you’ve encrypted it. You’ve effectively put it into a safe and you’ve shipped that safe off to someone else. You’re hoping, of course, that the information inside that safe is really secure, but how do you really know?
The bad guy obviously doesn’t have the combination to the safe. The bad guys are going to find a way to get into the safe. They’re going to try every possible combination. Maybe they know that this particular safe was built in a way that allows access if you use the right kind of tools against it. Those are the ways the bad guys are using to break our cryptography. Sometimes it’s a cryptographic shortcoming or sometimes it’s just the way that we’ve implemented the cryptography in what we’re using.
One attack against a number of different cryptographic methods is called the Known Plaintext Attack, or KPA. This is when the attacker has, obviously, the encrypted information but they also might have a little bit of the plaintext– something that they were able to discern perhaps in some other way. If you have a little bit of the plaintext, you may be able to start breaking down the cryptography. This known plaintext is often called the crib. It helps you determine what the rest of the plaintext happens to be.
This is the situation we had in World War II when we were trying to break the cryptography used with the enigma cipher. It was easier to break this cipher if you had a little bit of the plaintext to work with. You could often find weather report information. You would look for the words “Wetter,” because that’s the German word for “weather.” Sometimes numbers would be commonly put inside of the messages. The Royal Air Force would often try to see these messages by putting mines in certain harbors and then they would wait for an encrypted message that had that harbor name somewhere inside. And by using that crib, they could then decipher the rest of the message.
We use cryptography quite a bit when we’re storing passwords on our devices because we often store these passwords as hashes. A hash is a one-way communication. You can’t determine what the password is once you have the hash. The only way to try to determine what that password is is to try hashing every other possible combination and see if you can get the two hashes to match each other.
One way to optimize this would be to create an enormous table that took every possible password option and already had pre-calculated and stored this data. We call these rainbow tables, so instead of having to perform the hash for every possible scenario, you’ve already done it and stored that hash information. This means all you need to do now is perform a simple search, and in a matter of seconds, you can match up hashes and determine what these passwords might be.
One of the challenges, though, is that different methods of storing passwords store the hash in different ways. So the hash for Windows is going to be different than a hash for MySQL. That means you’ll need to build a separate set of rainbow tables for each one of these unique situations.
This is also why it’s recommended that you salt any passwords that are going to be stored. A salt is an extra bit of random information that’s added to the password, so even if somebody was storing exactly the same password with two different usernames, those two hashes would be completely different and would be impossible to be able to discern using a rainbow table.
If you are trying to reverse-engineer someone’s password, one of the best ways to do this is with a dictionary attack. People tend to use common words as their passwords, and if you could get the most common words and try those first, you’ve got a better chance of finding those passwords very quickly. You can find many lists on the internet that have the most common passwords that people abuse– words like password and ninja and football tend to be in the top 5 or top 10 of passwords that people will use.
You’ll find those word lists customized by language. Sometimes there’s line of work. And if you’re someone who’s trying to audit your own passwords, you may want to have a look at some of those lists and try a brute force yourself. This will catch people that are using common words. It will catch the people that aren’t putting a lot of thought into their password. But you’ll still need to use other types of password attacks if you plan on catching people who are very secure with their passwords.
With a brute force attack, you don’t use a dictionary. Instead, you’re using every possible combination of letters, special characters, and numbers to try to determine what someone’s password might be. If you’re trying to use a brute force attack online, it can be very difficult. It’s a slow process and most systems detect when somebody is using the wrong password over and over and they either slow down or completely disable an account.
Instead, it’s much easier if you can gain access to that file that contains the hash passwords. That way, you can take it offline and run it through an automated process where you don’t have the slowdowns or any type of disabling of account that you have to deal with. You can calculate a hash, compare it to what’s stored, and see if you can determine what those passwords might be. This may take a lot of computing power to calculate all of these hashes but at least you know you’re going through every possible combination and you will be able to determine what that password is.
If you have a classroom of 23 students, what is the possibility that two of those students share exactly the same birthday? It may surprise you to know that it’s about 50%. If you increase the number of students to 30, there’s almost 70% chance that two of those students are going to share exactly the same birthday.
In the digital world, we call this a hash collision. That’s when you have the same hash value even though you might have different plaintext that’s being calculated for that hash. That’s not something you’d like to see in your hashing algorithms. With a hash collision, the attacker would be able to use their own plaintext to match a hash value that you’re using for validation. One thing you can do is to use larger and larger hash sizes in an attempt to avoid any type of collision.
This is a fundamental rule in hashing. Every type of plaintext should have a completely unique hash associated with it. There should never be a situation where the hash is identical.
Cryptographers found a hash collision in the MD 5 Algorithm. That’s the Message Digest Algorithm 5 that was published in April, 1992. And they found this first collision in 1996. By 2008, researchers were able to create a certificate authority that appeared to be legitimate because the hash was correct, but in reality, it was a certificate that they created themselves and in fact was not signed by a trusted certificate authority.
This is an example of an MD 5 collision. We have some plaintext at the top and plaintext at the bottom. These are almost identical but there are a number of items as part of the plaintext that are different and those are marked in red with the bold. Those are supposed to give you two completely different hashes, but as you can see here, the MD 5 hash for both of these is identical and that’s a hash collision.
There are a number of cryptographic algorithms that we’ve used through the years that we no longer take advantage of. Instead, we’ve moved to algorithms that are better and stronger. But there are situations with a downgrade attack where you may be forced into using some of these older and weaker security mechanisms.
An example of a downgrade attack that was used with web servers was identified in 1995. This was the FREAK attack and it took advantage of a vulnerability on web servers to be able to use some very weak encryption keys. This went back to some restrictions that were put in place in the 1990s where only certain sized keys were able to be used for cryptography. These keys were limited to 512 bits or less.
Well, with this downgrade attack, instead of you using the latest and strongest key pairs, this attack would force you to use these weaker keys. And because you were using weaker keys, now it was much easier to brute force and decrypt the information that might have gone back and forth between you and that web server.
We’ve certainly run into our fair share of weak encryption algorithms through the years. One that we often mention is 802.11 WEP. This was the Wireless Encryption Protocol that was very easy to decrypt. In fact, we were able to decrypt a WEP key in this series in less than a second. So obviously that’s not an encryption mechanism you would want to use on your wireless network.
Another older type of encryption that can now be very easily decrypted is the Data Encryption Standard, or DES. This used very small keys relative to what we’re using today– only 56 bits. Modern systems can brute force through 56 bits very quickly so that’s not an encryption standard you’d want to use on your network.
Another cryptographic attack you’d like to avoid is a replay attack. There are a number of encryption methods that will prevent a replay from occurring. If your encryption method is hashing without any type of salt or there’s no session ID tracking, you want to be very careful that a replay attack’s not something that can happen to you.
Sometimes an encryption method can be built to automatically mitigate a replay attack. Kerberos is a very good example of this because Kerberos puts a time stamp in the encryption method itself. Even if somebody did capture that information and try to replay it later, it would not be accepted because the time stamp would be after the actual time of day.