This is the last section of the “attacks” chapter and covers cryptography-related attacks. You know the drill by now: broad but shallow coverage of a bunch of different topics. Let’s get going.
This is a continuation of my blog post series on the CompTIA Security+ exam, where I share my studying and connect it to real-world events.
Cryptographic Attacks
Birthday
This is named after the “birthday paradox,” which describes the high (50%) probability that two individuals (in a group of 23 or more) will share a birthday. This same mathematical probability applies in other situations, too, including the likelihood of shared passwords and hashes (collision).
Known Plaintext/Ciphertext
Here, we get a throwback to the German Engima. If an attacker has access to both plaintext and ciphertext copies of a message, they can (probably?) reverse engineer the encryption and decrypt other messages, too.
Password Attacks and Poor Password Choices
Hanon’s razor states that one should not “attribute to malice that which is adequately explained by stupidity.” Username and password authentication is ubiquitous. Because people have so many credentials to remember, they try to make it easier on themselves. They might reuse passwords, or use easily findable information (pet names, etc.) to create passwords. Or, they might use a common password (“abc123”, etc). This is, of course, bad, and makes things easier for attackers.
Rainbow Tables
Rainbow tables are precomputed lookup tables of hash values for a given password. CompTIA has some questions about the “fastest” way to crack a password. The answer (at least for the options provided) is rainbow tables, as the hashes are already generated.
You can mitigate against this using salting, which adds a random set of characters to make the hash harder to guess/compute.
Dictionary
Dictionary attacks are like rainbow tables, but you have to do a bit more assembly. A dictionary will have a lot of possible passwords, which then might be combined or altered (“secret” => “s3cr3t”) to generate passwords to try. Kali’s “RockYou” dictionary is a good example, but there are plenty more (like CrackStation) and can be used in conjunction with tools like fcrackzip.
Brute Force
Rainbow tables and dictionaries are meant to put you in the ballpark of the correct password. If those aren’t working, you could try, well, everything. Brute force attacks try all possible password combinations. If you’re trying this “online” (connected to the victim), then it’s more likely that you’ll get caught due to excessive traffic. If you do it “offline” (meaning you’ve stolen a copy of what you’re trying to crack), detection and bandwidth is less of an issue. Of course, unauthorized attacks are illegal either way.
The book also mentions “hybrid attacks,” which are some combination of the preceding methods.
Collision
Collision attacks take advantage of mathematical issues in cryptographic methods (hashing, etc.). You want the output of a hash to have a unique value per unique input. Some hashing methods have been found to have duplicate outputs for two unique values. This is, of course, bad. It can narrow the scope of potential hashes to try (meaning your likelihood of finding the correct hash, even without the correct original input, goes up). It also means that a file can be changed and have an identical output hash to a different document.
Note: I also have a blog post about a MD5 collision-themed CTF challenge, and a quick SHA primer.
Downgrade
Generally speaking, as researchers find vulnerabilities, they’re fixed, and old software is improved. We move into the future slightly more secure and… oh wait, what? I’m hearing that we can’t actually get everyone to upgrade and need backwards compatibility. Sometimes this inability to upgrade is legitimate, sometimes it isn’t. Either way, backwards compatibility can open the door to attackers exploiting poor security in previous versions, etc.
Replay
I think this is the third mention of replay attacks in this chapter. As before, we can record a serious of packets or communication, and then replay those messages to gain authentication.
Weak Implementations
Lastly, weak implementations. The book discusses past vulnerabilities in the abstract. It doesn’t directly mention (but probably should) developers who try to create their own cryptographic methods, or who poorly implement other, existing methods. I admire the DIY spirit of the software community, but this is one thing to leave to the professionals. Side note: I’m surprised that the book didn’t use the phrase “roll your own” (as it used “pass the hash” earlier).
