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.