Here's the thing about hackers that nobody really talks about.
There is an actual personality trait
about hackers that makes them so effective in taking down
organizations.
Do you know what that personality trait is?
Patience.
They will sit and wait for a vulnerability to pop up.
And one of those vulnerabilities is plain text protocols.
You see, they'll wait for the perfect opportunity
to get into your network, and then they'll wait again.
They'll wait and listen for traffic
as it moves throughout the environment,
and they're going to be waiting for some traffic that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and they're going to be waiting for some traffic that
is unencrypted.
These plain text protocols, like HTTP or Telnet,
that's what they're really looking for.
And at some point, somebody will slip up and use them.
And that's when the attacker will
grab the info they need and take their exploit even further.
So in this particular Nugget, we're
going to talk a little bit more about these plaintext protocols
and what we can do to secure ourselves against them.
Let's get going.
So the thing about plain text protocols
is they can be the corporate killer.
This is the way they get in, because we're not
encrypting any of our traffic.
And as long as the hacker is patient and waits and listens, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as long as the hacker is patient and waits and listens,
they will end up grabbing this password.
So what we're going to do, I've got EVE NG, my little EVE NG
topology spun up here, and I'm going to initiate a Telnet
session from my local computer into R5 right here,
and I'm going to use Telnet.
That way we can capture the traffic
and see where the plaintext protocol comes up.
So what I'm going to do here, so I'm
going to start my Wireshark capture by clicking on Capture,
and I'm going to choose Capture on my E0/0 interface.
So here comes the Wireshark capture.
We'll say this is an ethernet capture-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll say this is an ethernet capture--
and I'm just going to see a lot going on here.
So I'm going to let it run while I bring up my little terminal
here.
We're going to start a new session into this device.
Now, this is the device right here.
If I give it a show IP interface brief,
you can see the IP address is 10.10.21.153.
So when I Telnet into this device,
my Wireshark capture should grab all that traffic.
And we should be able to see the actual password that I used.
So I'll start a new session.
We're going to choose Telnet, which
is an unencrypted, plaintext protocol used in order WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is an unencrypted, plaintext protocol used in order
to access network devices.
So I specify my IP address of the device, 10.10.21.153.
This is port 23 that Telnet operates on.
And I'll click Next.
And I'll click Finish.
So now from within SecureCRT, all I have to do
is double click on the device.
It asks me for my user name, which is Cisco.
My password is Cisco.
And that's it.
We're hosed.
That's it.
That's all it took.
So now if I jump back here, I'm going to click Stop.
And we can now filter out my traffic based on Telnet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we can now filter out my traffic based on Telnet.
Here is my Telnet traffic.
This is my IP address right here, 10.10.21.29.
And this was my destination device.
This was the device replying to me as the packets came in.
So watch this.
From the very top of the very first packet that I received
here, what I can choose is right click
and then follow and then TCP stream.
Look at that.
Just like that.
This is-- the red denotes my packets
and the blue denotes the response packets. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the blue denotes the response packets.
Do you see what happens here?
I type C, it responded with C. I typed I, it responded with I.
And this is my user name right there, Cisco,
and there's the password that I typed right there.
See, this is it.
That's all a hacker takes.
There's nothing-- there was no encryption of this traffic
going back and forth.
So the hacker was able to simply just capture each packet
as it flowed across the wire, and then
using this tool like Wireshark, reassemble the stream
of packets, and there we go.
They now see our user name and they see our password WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They now see our user name and they see our password
right there.
The exact same thing could be thought of when
using the HTTP protocol.
Let's take my very own website for a second,
http://knoxhutchinson.com.
I got to move the address bar down a little bit.
You see this here?
This is not secure right there, because I typed in http://.
Here's my video running.
Let me pause that.
And I didn't write this application.
I didn't write this website to automatically redirect
to the secure, encrypted, HTTPS. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to the secure, encrypted, HTTPS.
This is just an application design failure.
The real kicker, when you find out
how simple it is to stop these types of attacks--
this is why it's almost shameful when
you see these types of things coming up.
Because this website is hosted in the Azure cloud,
on Azure's app service product.
And redirecting HTTP traffic to HTTPS is just a checkbox.
All I have to do is just tell it when an HTTP request comes in,
just send it to the HTTPS end point. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just send it to the HTTPS end point.
And for the most part, on most application developers
or web developer servers, that redirect
is nothing more than a checkbox.
You just tell it, I just want traffic
to go to secure HTTPS instead.
That also removes your own liability
of exposing someone's content or traffic
because you're using an unencrypted protocol
like an HTTP.
So again, keeping in mind that vulnerabilities
don't just come in on network devices or servers.
They come in through application in code, too. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They come in through application in code, too.
And in this case, we've explored a vulnerability
by using HTTP instead of HTTPS.
And the same thing goes back with these network access
protocols.
It doesn't just stop with Telnet, where
we should use SSH instead.
We should block access coming in on Telnet.
This is also the difference between SNMP and SNMP V3.
Or instead of even using SNMP V3 in the first place,
you could use a network automation protocol
like NETCONF, which operates over SSH, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
like NETCONF, which operates over SSH,
or RESTCONF, which operates over HTTPS.
It's really important that you analyze
all of the protocols that are actually being operated
within your environment because, again, we go back
to not just our network devices, but also IoT devices
or things like our UPS's, battery backups, that
may be operating SNMP version 1 on those as well.
I once worked for an organization-- one
of the largest organizations I worked
for had UPS's all over the place, and not only were they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for had UPS's all over the place, and not only were they
operating with just SNMP V1, but they also
had the default login and password
set when you tried to access them over HTTP.
I mean, this is a triple whammy here.
We're using the weakest version of SNMP,
we're not using encryption on HTTP,
and it had the default username and password.
I don't remember what it is anymore.
Let's just say it was admin admin.
It was wildly vulnerable.
And we, obviously, as soon as we took over that client,
we took these steps to address those problems
and fix them right up front. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and fix them right up front.
So that's been understanding protocol weaknesses
and vulnerabilities and how you can mitigate those issues.
I hope this has been informative for you
and I'd like to thank you for--