In this video, we're going to talk about
where to look for vulnerabilities.
So, in general, where would you look?
Well, the slide shows you several possibilities.
The important one here is where
privileges or rights are changed,
change in protection domains.
Now, a network server even if it runs with no privileges.
So, it's just like an ordinary user
that's highly confined.
If I'm connecting remotely that is giving me a privilege.
The privilege or the right of being on
your system connected to the server.
That's why network and local service are included here.
The other place to look is for shared resources,
especially those that both
privileged and unprivileged users use.
This may include clients and servers,
the idea here is that this is for availability.
If the resources are shared,
I can interfere with someone else's use
of those resources.
It also may be a matter of
confidentiality or of integrity.
If I can change something and then you rely on that,
I can probably manipulate you in a number
of ways you do not want to be manipulated.
So, if it's not shared,
then I can manipulate it all I want.
The only one I'm hurting is myself.
Again, this next slide talks about network servers.
I mentioned the access to the system.
Network servers should run as a user with no privileges,
like nobody on Linux.
In fact, sometimes they run with some privileges
such as the mail group or the mail user,
or in a couple of cases even as root.
In that case,
you have to check the assumptions the server
makes about what information it's
getting and is it handling it properly.
Also, servers, unless you're using cryptography,
servers generally authenticate through
the use of an IP address.
They look at the connection coming in,
get the IP address and say,
"Okay, that's where the person is coming from."
The smarter ones will get that address,
go to the DNS and look up the host name,
then take that host name and look
up its set of IP addresses,
and see if the original IP address
is in any part of that list.
If it is, then they'll say, "Okay that's fine."
If it isn't, then they'll reject
the connection or they deem the connection untrusted.
This is quite weak,
but on the other hand it's a
lot better than doing nothing.
Next slide talks about local servers,
and notice pretty much everything is the same.
The one difference is in
the authentication of the client.
Since it's a local server,
it just has to check that the client is local.
However, since it's a local server,
it starts up on your local system.
Which means it inherits
an environment from whatever started it.
That environment may be configured dangerously.
So, the best servers when they start
up will wipe out the environment and install their own,
and that way they know what's there,
and it's perfectly fair to
delete an existing environment.
Now, these programs I mentioned
before essentially a Setuid or
Setgid program resides in a file owned by some user.
When a different user goes to execute the program,
normally programs would execute with the user's
id and the users rights.
But if it's Setuid,
then it executes with the rights of
the owner of the file containing the program.
So for example, if a program owned by root is Setuid,
then if I, the ordinary user run it,
it will take its actions with root privileges.
So, that's an example of Setuid.
Setgid is the same thing but
with groups rather than users.
Now, couple of important things about this.
When that program runs,
it runs in my environment
unless it cleans out the environment,
and we'll talk about how to do that later
on in another course.
But the thing is, I can manipulate my environment so
that program had done well better
not trust the environment.
It may also make bogus assumptions.
One of the classics, which again we'll
talk about in another course,
is determining the person
who's running the file or who made
a request by ancillary information
such as who owns the requesting file.
Some cases that works,
in other cases it doesn't.
Any assumptions like that have
to be thoroughly validated.
This is odd but most people feel
that if you do checking at the client,
the server doesn't have to worry about it.
The problem with that is I can write my own client,
and if the server doesn't do the checking,
then my client can do whatever it wants with the server.
Clients also need to be written well.
They need to check their input thoroughly,
and by input I just don't mean the user,
what the user tells it to do,
I mean also what the server tells it to do.
For example, your web browser.
That may pass back environmental information.
Environment variables possibly but
it will also pass back cookies,
it'll pass back details of
which browser you're using and so forth.
To give you a better browsing experience,
I believe the correct term is.
But the point is all that information going back enables
the server to identify exactly what's
going on at your end and possibly manipulate it,
and the client has to be alert to that.
Now, let me give you a very good example of ambiguity.
This is called the land attack
and it was real big when it was found.
Now, this relates to the starting of a TCP connection.
A TCP connection starts with a 3-way handshake.
It's his first part is you
send over a packet called a SYN
packet with a source
and destination addresses and port numbers.
If you go to the next slide,
it shows the exchange.
The destination then replies with a SYN,
and also an ACK.
The ACK is a number which is one more than
the number that was sent over
with the sources' SYN packet.
When the source gets that,
it checks that the ACK number
is one more than the SYN number it sent out.
If not it takes some particular action.
If it is the same, then it just sends back an ACK with
one more than the SYN that the destination sent over.
Then the destination does the checking and if
everything checks, they're talking.
But if you go back to the previous slide,
what happens if the source and
destination ports and addresses are all the same.
The problem if you look at that drawing on
the next slide is
that when the destination
generates its number to send back with the SYN,
the ACK is going to be one more than that.
So, the SYN and the ACK from the source won't match.
So as a result, there's an error.
Now, how do you handle this?
Well, the RFCs for the internet
are essentially the standards,
and everybody who wants to connect to
the internet has to follow these standards.
The RFC for the TCP is ambiguous.
If you go to page 36,
what it tells the source to do is immediately send
an RST packet that
terminates the connection you had done.
But if you look at page 69,
it says reply with an empty packet having
the current sequence number and the ACK number.
So, when source does that to destination,
it's replying to itself.
It sees the correct sequence number,
the current sequence number is correct
but the ACK sequence number is wrong.
So, it repeats, and basically it locks up.
The steps on the next slide show this in detail.
Normally, what you expect
is the source sequence number is
s and it expects s plus one back.
The destination sequence number is
t and it expects t plus one back,
and if everything goes right, everything works.
The land attack, the source and
destination sequence numbers are s,
and the source expects an ACK of s plus one.
When that arrives, the destination,
which is the same as the source,
generates a new number.
So, now the source sequence and the destination
sequence numbers are t and it expects t plus one back.
But it gets the s plus one back
because that ACK was already constructed.
Then you attempt to recover from that error,
and that's where you either send back the RST and drop
the connection or iterate.
Now, let's close this particular video with a puzzle.
There's a cryptographic voting system
that enables ballots to be posted to
a website in such a way that a voter can
verify his or her vote was recorded correctly,
and no one can leak the posted data with a voter.
Let's for this exercise or
this puzzle assume that all that works.
There are in fact voting systems proposed like this.
We're going to assume the software also
correctly implements the voting system.
What assumptions are being made by this?
What assumptions is it trying to protect against?
I'll give you a minute to think about that one.
The first assumption it's making is that
the website and the votage browser
can't be compromised because
you're voting over your browser.
If I can get the browser
to send the wrong vote over or to
do the cryptography that will generate the wrong vote,
then the voting system will work
properly but it'll be recording the vote I didn't intend.
The other assumption that this is
making is that it's
okay to put about a unique identifier on the ballot.
In this case it's going to be
some sort of a cryptographic code.
It's tied to the voter.
Ideally, you won't be able to
figure out which voter it's tied to,
but it is tied to a voter.
Is that okay? It depends on the laws.