0:04
Hi, everyone. Ed Amoruso here.
And I want to talk to you about
an internet protocol attack that kind of doesn't work anymore,
but it illustrates some properties of
TCAPIP that I think are useful to exercising our mind.
Now, a lot of this came from the 1990s,
very fertile time for Internet Protocol attacks.
And there was actually a hacker who is kind of notorious,
interesting guy at the time named "Kevin Mitnick" who launched
an attack that a lot of us studied, and was kind of interesting.
I am not sure that he invented it,
but he sure certainly made it famous.
It's called "The Sequence Number Attack."
Here's the way it works, and here's what it's predicated on.
Back at the time, certainly in the '80s,
when I first started doing internet work,
there was this concept you're going to think this is crazy,
but you would actually keep track of computers that you'd have
a trust relationship with.The internet was a lot smaller then.
And you're perfectly willing to say I trust that machine,
essentially trusting their source IP address.
You can see, probably not the greatest idea,
but you would have a name in him.
Again, it might be a domain.
But the main thing is you would have a trust relationship.
So, that if, for example, if you're Alice and you want to connect to Bob.
You know Bob is not going to let you connect,
but you know Bob has a trust relationship with Bill.
Then if you could somehow convince Bob that you are Bill,
then you'd be able to set-up
a connection and lob a command like, hey, you know, give me a root shell of something.
So, you get the idea? I'm Alice.
I want to connect to Bob.
Bob has this trust relationship.
So, if I can get a session setup where
Bob thinks he's connected to Bill, then that's great.
Now, there's one other problem here that
existed years ago that this attack would take advantage of.
And that's that SYN sequence numbers and SYN/ACK sequence numbers were not always random.
Like sometimes the protocols stack would go,
"Hey, I'm a thousand."
2000. 3000. 4000. This is the sequence numbers.
And if the assumption was that there's so much traffic and a lot of things going on,
people connecting all the time.
It's essentially random because I'm just incrementing some number.
It was just an easy convenient way to implement.
Now, if you had a very quiet system and you were connecting,
then there wouldn't be a lot of sequence numbers for a lot of different users.
You'd be the only user.
So, what Kevin Mitnick did was,
he was attacking the San Diego Supercomputer Center server.
But he did it here in the United States on a holiday.
And it was Christmas Eve.
So, the ideas was there's not going to be a lot of traffic into the server.
And he knew that the server had a trust relationship with the particular machine.
Let's call it "Bill," and we'll call Kevin Mitnick "Alice."
So, what he would do is, as Alice,
throw a SYN packet over and watch the SYN/ACK come back.
Now, keep in mind, TCP does not do security when it sees a SYN packet.
Now, maybe there will be a firewall in between.
At that time there wasn't.
You throw a SYN, it's throwing you a SYN/ACK.
Once you establish a session it might say,
"I need a password," all this other stuff.
But to just get a packet- A packet responding to basically anybody.
So, Alice, Mitnick would go,
"Here's a SYN. Watch the SYN/ACK.
And let's say it's a hundred.
Then here's a SYN, SYN/ACK 200.
Again, Christmas Eve. There's not thousands of others doing this.
You're the only one.
Then here's a SYN.
Watch the SYN/ACK 300. You get the idea?
100. 200. 300. 400. Let's say you did that to a thousand.
You did it 10 times.
You're pretty convinced you know what's coming back.
Now, what you do is you send the packet as Bill source IP.
You sent it, but the SYN/ACK goes to Bill,
but it doesn't matter because you know the SYN/ACK sent 1,100.
So, you now ACK with 1,100.
And you've got a session set-up.
Isn't that clever?
It's a sequence attack.
Now, yeah, it doesn't work anyway.
It will have trust relationships.
Protocol stack developers don't do things randomly anymore.
There are better software. There's firewalls in between you and most servers.
But it's a very illustrative attack to think about simply because it
gives the idea that when you make a mistake you do a bad implementation,
some hackers somewhere is going to notice.
They're going to take advantage of that.
They're going to come up with something clever,
and you're going to be stuck with a situation where you can
hardly believe that someone was able to take
advantage of a situation that you created that resulted in a security compromise.
I hope this is a useful little example for you.
Think these things through.
Try and think through as you ponder your understanding of TCAPIP,
what sorts of things you would attack,
and what sorts of protocol weaknesses exist in a lot of
the interaction that we have not just in computing,
but also in your personal live.
So, I hope you enjoyed it. We'll see you in the next video.
Dr. Edward G. AmorosoResearch Professor, NYU and CEO, TAG Cyber LLC
