Understanding Cryptographic Failures
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:00
>> Understanding cryptographic failures.
00:00
Our learning objectives are to
00:00
describe the various types of
00:00
cryptographic failures with a focus
00:00
on sensitive data exposure flaws.
00:00
Now remember, as we discussed in last lesson,
00:00
cryptographic failures are the root cause
00:00
which the symptom of that is sensitive data exposure.
00:00
We're going to demonstrate how to
00:00
test for various types of
00:00
cryptographic failures and explain
00:00
how to remediate cryptographic failures,
00:00
including sensitive data exposure vulnerabilities.
00:00
Now I apologize if my Philly accent comes
00:00
out and I say cryptographic
00:00
, you probably already heard it.
00:00
But we'll see how things go from here.
00:00
Even before we talk about data in
00:00
transit and data at rest,
00:00
let's talk about what is sensitive data.
00:00
It could be different to different people.
00:00
Of course, there are laws that dictate
00:00
what sensitive data is and how it needs to be stored.
00:00
If you think about Europe and GDPR here in the states,
00:00
California Consumer Privacy Act.
00:00
That tells you potentially or
00:00
what sensitive data could be and what the penalties are,
00:00
the fines that if you
00:00
don't store sensitive data properly or don't
00:00
delete sensitive data in a specific amount of
00:00
time so when requests their data to be deleted,
00:00
you need to do that according to GDPR.
00:00
Also, it could be your username
00:00
and password when you log into an account,
00:00
is sensitive data to you.
00:00
Let's also think about in
00:00
the context of a health care website.
00:00
Let's say we're registering for a health care website.
00:00
We're going to enter our full name.
00:00
We're going to enter our date of birth.
00:00
We're going to enter our home address
00:00
, our telephone number,
00:00
our social security number here in the States.
00:00
These are all things that could be
00:00
considered personally identifiable information,
00:00
PII, and sensitive data.
00:00
If we send it via HTTP in a web form,
00:00
if an attacker is on the same network
00:00
sniffing the traffic,
00:00
they can read that information
00:00
that's being passed from the client to
00:00
the server and from the server back to the client,
00:00
so It's very important that's why we
00:00
implement protocols that use encryption like HTTPS,
00:00
HTTP secure, using TLS,
00:00
which encrypts the packets going back and forth.
00:00
If an attacker sniffing at
00:00
traffic on the wire, it looks garbled to them,
00:00
they can't read our name and
00:00
address and social security number
00:00
because we're using HTTPS.
00:00
There are other protocols that are unencrypted,
00:00
things like FTP file transfer protocol
00:00
or things like SMTP, or e-mails.
00:00
I don't know if you knew this.
00:00
But e-mails are not encrypted in
00:00
Simple Mail Transfer Protocol is not encrypted.
00:00
We have to use implement things like S/MIME and
00:00
things like that to encrypt our e-mails,
00:00
otherwise, an attacker can
00:00
view our e-mails in the clear.
00:00
Next time you send that super secret recipe
00:00
to your aunt via your e-mail,
00:00
an attacker can read that, so you know.
00:00
Telnet, who uses that anymore?
00:00
I've actually seen this before
00:00
when Telnet has been used as in the clear.
00:00
It's been replaced by what?
00:00
Here's this question,
00:00
what is Telnet been replaced by?
00:00
If you said Secure Shell,
00:00
you're right. Secure Shell.
00:00
Actually SFTP is SSHFTPs,
00:00
SSH encrypts FTP traffic.
00:00
That's data in transit is sending
00:00
information to a server via proto in
00:00
all these different protocols and information coming
00:00
back to somebody as well
00:00
can be sniffed if it's not encrypted.
00:00
Data at rest. I have
00:00
a portable hard drive sitting right on my desk.
00:00
If someone were to come and grab
00:00
my portable hard drive and plug it into their computer,
00:00
it is all encrypted.
00:00
It can't read that data.
00:00
They'd have to guess my password.
00:00
But the data itself is encrypted.
00:00
Again, the danger being if I don't encrypt that data,
00:00
if someone grabs my portable
00:00
hard drive and they plug it in,
00:00
they now gain access to all of
00:00
my super cool videos here on Cybrary,
00:00
which I don't want them to, I want them to
00:00
have to sign up for my course.
00:00
Also, think about databases.
00:00
If I sign up for this health care website,
00:00
I create a password.
00:00
I want that to be hashed.
00:00
If an attacker gains access
00:00
to the database that stores that password,
00:00
my really super complex password of password 123.
00:00
I don't want them to be able to read that.
00:00
I want it to be hashed
00:00
so that they can't see this password 123,
00:00
of course, you should not be using password
00:00
123 as a password in the first place.
00:00
You'll see a Wireshark packet capture here on the left.
00:00
This is using FTP, file transfer protocol.
00:00
We see conversation between an FTP server and a user.
00:00
Now, when sensitive data is being passed?
00:00
Maybe read down.
00:00
If you can see a user of
00:00
kali and a password of secret, you're right.
00:00
What can the attacker do if they're sniffing traffic
00:00
across the wire and that they
00:00
see the username and password.
00:00
They can then log in and view this read
00:00
me.txt file you see at the bottom here.
00:00
The danger being that people typically re-use passwords,
00:00
and if they use secret
00:00
here they could be using secret and other places.
00:00
The other danger being if there's
00:00
sensitive data on this FTP server,
00:00
the attacker now has full access to the FTP server.
00:00
That's just an example of data in transit
00:00
we talked about before with HTTPS.
00:00
Now if an attacker can downgrade
00:00
someone from HTTPS to HTTP,
00:00
they can then read that information.
00:00
Let's say an attacker manages to downgrade somebody who's
00:00
already logged into that health care account from HTTPS,
00:00
HTPP, and they view a cookie.
00:00
Somebody's cookie that's stored in that session,
00:00
so if they gain access to the cookie,
00:00
they can then perform a cookie replay attack.
00:00
They take that cookie and they put it into
00:00
their browser and then they become you,
00:00
so they gain access to your session,
00:00
and they can view all that sensitive information
00:00
out and your health care account.
00:00
That's the danger of getting
00:00
access to usernames, passwords,
00:00
and cookies are also bad
00:00
as well if an attacker gains access to that.
00:00
What about data at rest?
00:00
We talked about encrypting hard drives.
00:00
You can also encrypt files.
00:00
If an attacker gain access to this password.txt file.
00:00
It's bad because you can see usernames and passwords.
00:00
It would be better if passwords.txt
00:00
was encrypted the file itself.
00:00
But if it was not,
00:00
we would hope that the passwords will be hashed.
00:00
I see Trish has a password of qwerty.
00:00
I like that because of Mr.
00:00
Robot fan and his goldfish's name was Qwerty.
00:00
If I have a password of qwerty and
00:00
Trish has a password of qwerty.
00:00
If it's hashed, we hope this using
00:00
a strong hashing algorithm,
00:00
things like MD5,
00:00
or SHA-1 are weak,
00:00
they can be easily cracked.
00:00
But we want to be hashing passwords that are
00:00
the robust with a strong hashing algorithm,
00:00
and also we want to use a salt.
00:00
We want to use a salt. What's a salt?
00:00
It involves basically adding random bits into the hash,
00:00
so that if Trish and I both have qwerty and it's salted,
00:00
even though we both have the password of qwerty,
00:00
the hash is different for her and
00:00
me because it's using a salt.
00:00
That makes it more difficult
00:00
for an attacker to crack passwords.
00:00
Attackers using something like a rainbow table that
00:00
has hashes already in it,
00:00
for qwerty and MD5,
00:00
it knows the hash for that already.
00:00
If it's salted, it won't be
00:00
able to crack that with a rainbow table
00:00
because it's salted and it has his random bits to it.
00:00
How do we test for this? We go back to
00:00
the web security testing guide
00:00
and there's the source at the bottom right.
00:00
We're test for weak transport layer security.
00:00
We talked about how TLS,
00:00
if you view this 4.9.1 and
00:00
the web screen test and got it tells you
00:00
to test for that.
00:00
Also testing for something called padded
00:00
oracle that deals with block encryption.
00:00
What happens is if
00:00
it doesn't have enough information in that's padding.
00:00
An attacker through error messages can
00:00
try to figure out how much would
00:00
that encryption is based on the error messages and
00:00
the padding is added for that padding oracle.
00:00
We have testing for sensitive information
00:00
sent via unencrypted channels.
00:00
We talked a lot about that.
00:00
Unencrypted protocols and also
00:00
testing for weak encryption.
00:00
The encryption itself being weak and easily cracked.
00:00
If you use things like Nmap,
00:00
I think sometimes if you use that bone script,
00:00
you'll see things like poodle attack,
00:00
which deals with weak encryption,
00:00
I believe, so it's using things like that.
00:00
How do we prevent sensitive data exposure?
00:00
Again, we need to figure out what sensitive data is.
00:00
There are legal definitions
00:00
of what sensitive data exposure is.
00:00
There could be industry definitions.
00:00
There could be compliance that
00:00
you have to follow depending on your industry,
00:00
so you need to figure out
00:00
what sensitive data is and you need to make sure it's
00:00
encrypted both at rest and in transit,
00:00
and we discussed that at length,
00:00
use the strongest possible encryption.
00:00
Again, we talked about hashing algorithms.
00:00
We also want to make sure that we're
00:00
using strong encryption when transmitting data,
00:00
and we want to hash passwords
00:00
with strong salting functions.
00:00
We talked about that with a work factor.
00:00
What's a work factor?
00:00
Work factor means that if I tried to log into my account,
00:00
it could purposefully time out if
00:00
I'm an attacker trying to log
00:00
into an account brute force,
00:00
it could time me out for
00:00
three seconds and that becomes very
00:00
annoying when trying to brute force a password.
00:00
Of course, if you're a user that's
00:00
equally as annoying as well,
00:00
so we need to think about
00:00
that from a functionality standpoint,
00:00
what the work factor is,
00:00
but it's a way of preventing brute force attacks.
00:00
In summary,
00:00
we described how to identify cryptographic failures,
00:00
leading to then sensitive data exposure,
00:00
and then ways to remediate or
00:00
prevent sensitive data exposure flaws.
00:00
In the video, we're going to walk
00:00
through Matilda for a bit and we're going to
00:00
show how to test for
00:00
sensitive data exposure flaw, so hang on for that.
Up Next
Instructed By
