This lesson looks at network attack. It's not encyclopedic, i.e. it does not begin to attempt to explore all the different ways attacks might occur. However, it does discuss the kinds of attacks you'll be carrying out in your network attack lab. The basic scenario we're considering is that you, the attacker, are outside the network you want to attack. More precisely, the hosts you can execute commands on are outside your target's network. We will focus on attacks on the infrastructure, not the people, that comprise your target. Attacks on the people on your target's network — which often involves the use of tricks like phishing or malicious websites to install malware — will be covered in its own lesson. Of course there's also the possibility of physical attacks on both infrastructure and people, and of "social engineering", which involves manipulating or tricking people, like a con man would do. These are important for security, but outside the scope of this course, which focuses on the technical foundations of cyber security. To sum up, we'll talk about breaking in, but it's good to keep in mind that it's often easier to trick people into simply letting you in.

Attacking availability: Denial of Service and Distributed Denial of Service Attacks

Suppose you're an attacker and your goal is to bring down a particular service provided by your target system. Clearly, availability is the IA pillar you intend to violate. An attack that accomplishes this is called a Denial of Service (DoS) attack. Typically a denial of service attack involves either trying to crash the server that provides the service, or to keep it so busy doing spurious work for you, the attacker, that it has no time (or memory space) left to do its real work.

A DoS attack does not need to involve network services. For example, if there is a host that several people work on, and we (as attackers) have an account on the host, we could make the host essentially unavailable to the other users in the following way. There is a limit on the number of processes (executing instances of programs) a host can have running at the same time (in the thousands). Once that limit is reached, no new processes can be created until existing processes start terminating. You can write a program called a fork bomb that does nothing but spawn new processes, which spawn new processes, etc. Eventually the host's process limit is reached and no new processes can be created. This stops other users from doing almost anything.

Normally, however, a DoS attack targets a network service. If there's a bug in the server software, i.e. a bug in the program that receives and processes the network traffic that constitutes requests for the service, the attacker might find a way to crash the server by sending some badly formatted request that exploits that bug. However, even if the server program is bug-free, an attacker can still keep it too busy with spurious work to do real work. For example, there's a limit on the number of TCP connections a host can have at any given moment. So you might target a web-server by sending a whole bunch of netcat (nc) requests to connect to that webserver that never actually send their HTTP GET requests, but instead just sit there. The server then has all these pointless connections that leave it unavailable for legitimate connection requests.

DoS attacks that simply flood servers with spurious requests in order to keep them too busy to handle real requests are more effective when, instead of one host sending spurious requests, there are many hosts sending spurious requests. This is called a Distributed Denial of Service (DDoS) attack. We could pull this off pretty easily on rona, for example. Recall that the URL 

http://rona.cs.usna.edu/~si110/lec/l13/ex0.jsx?
runs a server-side script that produces a page with 1000 "GO NAVY"s and sends the page back to the browser. Now imagine all 500+ SI110 students entered this in their browser URL bars and started clicking refresh over and over. Rona would be so busy dealing with this, that none of the faculty could access the website. That would be a DDoS attack. Worse still would be a script that you all could run, that issued that same request over and over again. Then you wouldn't be limited by your patience for clicking "refresh".

A DoS attack is a pretty blunt instrument. Everyone knows it's happening, it doesn't really help with infiltrating a network, i.e. it doesn't really help us get in to accomplish other evil goals.

Infiltration

We're going to assume the same scenario that we discussed in the "Phases of a Cyber Attack" lecture: namely that we (as attackers) have as an evil goal to steal a file secret.txt in the account of user timvic on a target host within a network outside of our own network. There is an "other host" within the target network that is a webserver. The network has a firewall that only lets in port 80 traffic. Both hosts have ssh servers running on them. The diagram to the right illustrates this scenario.

We can't accomplish our goal directly, because firewalls and password authentication stand in our way, so infiltration will have to proceed in several steps.

  1. Our only way to gain a foothold into this network is by sending port 80 traffic to the "other" host. We'd like to exploit some vulnerability in the webserver to open up a shell on the "other" host. How such an exploit might be possible is discussed in section Remote code execution: Buffer overflow attacks.
  2. Once we have a shell on the "other" host, we'd like to use it to initiate an ssh connection to the target host — since ssh from the "other" host is allowed because the traffic is already inside the network. Of course this requires either exploiting a vulnerability in the target host's ssh server, or finding/guessing a valid username and password to login with. How we might come up with valid usernames and passwords is discussed in section Getting a Username and Password.
  3. At this point, we have a shell on the target system. However, we can only access the file secret.txt if we are logged on as user timvic (the file's owner) or the system administrator. In other words, we need "privileged" access. So, the last thing we need to do is escalate privileges so that we can access the file. How we might be able to accomplish that is discussed in section Escalating privileges.

The diagram above illustrates the three steps. A dot at a location in the diagram represents being able to execute commands "at" the location.

Remote code execution: Buffer overflow attacks

This section is devoted to how vulnerabilities in a webserver might be exploited to allow an outside attacker to gain access to (i.e. execute code on) the webserver host. The real goal is to execute code that ends up giving the attacker a shell on the webserver host. Although we're concentrating on the scenario of a webserver, the same idea applies to other kinds of servers that listen to ports and respond to data delivered to those ports.

If you peruse http://httpd.apache.org/security/vulnerabilities_22.html you'll find descriptions of the kinds of bugs that have been uncovered in the Apache webserver. If you scroll down the page looking for bugs marked important, you'll see that bugs have been uncovered that attackers can exploit to make the apache webserver user excessive amounts of memory (denial of service attack), crash the webserver (another denial of service attack), or execute arbitrary code on the webserver.
We saw in the Javascript Programs portion of the course that it is difficult to write a program that is prepared to deal with badly formed input. There are simply too many ways input could stray from what the programmer expects. The bugs that arise from this problem can sometimes be exploited to do bad things, especially when those bugs are in programs that provide network services — like a webserver. If network recon tells us exactly what webserver is being used, down to the version number, we can grab our own version of that software and start looking for bugs! The most notorious of these kinds of attacks are buffer overflow attacks. The details of how these work are beyond the scope of this course. However, the idea behind the simplest kind of buffer overflow attack is relatively easy to understand. A client connected to a webserver sends a sequence of bytes to the webserver as an HTTP request. The webserver copies those bytes into the computer's memory and, when it's received the last byte of the request, processes those bytes. If the webserver isn't careful, and the client sends lots of bytes, eventually the bytes the server is copying will start to overwrite bytes in memory that contain important data. Worse, you might start to overwrite data that controls what the program does next. If you set things up right, you'll overwrite what the program was going to do next with what you want it to do next: like open up a shell that you can enter commands into! Then you, the attacker, are connected not to a webserver on the remote host, but to a shell running on the remote host.

This kind of attack is called a Buffer Overflow Attack, because server copies the stream of bytes into a fixed size region of memory called a "buffer", and the stream of bytes literally overflowed that region. Regular programs (as opposed to those running as network services) may also be susceptible to buffer overflow attacks, as we'll discuss a bit later.

Later in the course, we'll talk about malware, which provides another way to execute code on a remote host — essentially by tricking users into executing it for you!

Getting a Username and Password

If, as an attacker, you have the opportunity to simply login to a system — as is the case in Step 2 of our attack scenario — it's useful to know some usernames and passwords! In this section we take a look at how we might get that information. In particular, we're considering a scenario in which you do not have access to the file containing the password hashes.

Escalating privileges

Simply gaining access to a host is not necessarily enough for an attacker to accomplish his goal. As in Step 3 above, the attacker may have to escalate privileges to those of another user. The example we're considering is that we (as attackers) want to access a file that belongs to another user (timvic) and which has permissions set so that only that user is allowed to access it. Other examples of access an attacker might want to take that require higher privileges are killing processes they don't own or opening network connections on "low-numbered" ports, like port 80, that have special meanings.

In our case, to access a file owned by user timvic, we could try to get authenticated as as timvic, or we could try to get authenticated as the system administrator (user root on unix machines). The two ways we'll look at doing that are to try stronger attacks on users' passwords, and to hijack a process running at the privilege level we want.

  1. Stronger password attacks — Now that we're actually on the target host, we have more attacks we can make on passwords. In particular, if we are able to get the file containing the password hashes, we can then search for a string whose hash matches what's in the file and so identify a correct password without ever having to try logging in. This is important because login attempts are slow (so we can't try many guesses in a reasonable period of time) and login attempts are logged (so that an observant sysadmin will realize that something's up when they find 10,000 unsuccessful login attempts in one day!). With the password file — i.e. the file containing the hashes of passwords — we have usernames, salt values (if salt is used) and password hashes. So we can crack passwords by
    1. brute force attack, which means generating and checking all possible passwords,
    2. dictionary attack, which means starting with a list of potential passwords and hashing and comparing them (and perhaps variations of them) against what's in the password file, and
    3. rainbow table attack, which means looking up the hashes you've found in a large table of precomputed hash values (note that the use of salt essentially defeats this attack).
    There are tools out there (including freely available tools) for cracking passwords. One such tool is John-the-Ripper, which can perform brute force attacks and dictionary attacks.
  2. Hijacking a process running with higher privileges — We already discussed how a buffer overflow attack against a server, like a webserver, could trick the server process into executing a command for us — essentially hijacking that server process. The same kind of thing can be done with programs that are not providing network services. If we can highjack a process that is running with administrator privileges we can access any file or service on the host. Some programs that we run ourselves, ping for example, run with administrator privileges, even if we start up the program as a regular old user. Other processes, like device drivers, a host's DHCP client, or the program that actually logs a user on, are not initiated by us as regular users, but are there running on the system. If we as attackers can exploit a vulnerability in such a program to execute code — especially code that gives us a shell! — that code is executed as the administrator, which means it has privileges to access anything. What's really changed once we are actually on the target host, is that we have access to many more processes, not just the ones listening to open ports. Perhaps we can find a process that runs as root and carry out a buffer overflow attack on it. Or perhaps we can trick it into executing code for us in some other way.

Passwords Stolen from Formspring


In July 2012, attackers stole approximately 420,000 password hashes from formspring, a social media site. (Securityweek article) One interesting aspect of the story is that formspring's explanation of what happened includes some details into how the attack was carried out. As they explain, the attackers managed to gain access to one of formspring's "development servers", and then were able to exploit that access to trick that "database server" into showing the password hashes. This exactly the kind of process we discribed earlier in the notes. In fact, we get a diagram like this:

Other things along the way

One of the important takeaways from the discussion of this scenario is that an attack may hop from host to host until it gets to the host and resource it's really interested in. In our example, this was by necessity, since there is no access to the target host from outside its own network. Since, in this example, our first step is to gain access to the webserver, it's worth noting that we had an opportunity to do some more damage, for example defacing the target's website, as happened to PBS at the end of May, 2011: PC Magazine article. Breaking into the webserver host, as we did, gives us an opportunity to do this. It's worth noting, however, that injection attacks, like you carried out on the message board in class, provides another way to deface webpages.

Infrastructure accessible via the Internet
Check out this CNN Money article about "Shodan", a website that allows you to search for Internet accessible devices and infrastructure. The scary thing is how many of them still have their default admin accounts and passwords!
As we mentioned above, infrastructure like routers and wireless base stations often have administration accounts that come with default passwords, which can be easily looked up on the internet if you know the make and/or model involved. So in addition to attacking regular hosts, infrastructure components are targets as well.