Cryptographic Attacks – CompTIA Security+ SY0-501 – 1.2


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.

Add a Comment

Your email address will not be published. Required fields are marked *