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 — (previous 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
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
web server 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
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
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+ SY110 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.
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
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 web server. 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.
The diagram above illustrates the three steps. A dot at a
location in the diagram represents being able to execute
commands "at" the location with the associated permissions (privileged [elevated], non-privileged [normal user]).
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 web server
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.
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.
At this point, we have a shell on the target system.
However, we can only access the file
if we are logged on as user
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.
Remote code execution: Buffer overflow attacks
This section is devoted to how vulnerabilities in a web server
might be exploited to allow an outside attacker to gain access
to (i.e. execute code on) the web server host.
The real goal is to execute code that ends up giving the
attacker a shell on the web server host.
concentrating on the scenario of a web server, the same idea
applies to other kinds of servers that listen to ports and
respond to data delivered to those ports.
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 web server.
If reconnaissance tells us exactly what web server 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 web server sends a sequence of bytes to
the web server as an HTTP request.
The web server copies those bytes into the computer's memory and, when it's received the
last byte of the request, processes those bytes.
If the web server 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 web server on the remote host, but to a shell running on the remote host.
If you peruse
you'll find descriptions of the kinds of bugs that have been
uncovered in the Apache web server. 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 web server user excessive amounts of memory
(denial of service attack), crash the web server (another
denial of service attack), or execute arbitrary code on the
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.
Explore this simple Buffer Overflow Demo.
After innocuously exploring the demo, enter in
rm -r / preceded by any 10 characters.
The first ten characters will fill up the buffer allocated for the
buffer variable, and the
rm -r / will overwrite what is stored in the
comm (command) variable.
We already learned 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
websites — If your target organization has
a website, that's a good place to start.
The website may identify individuals and e-mail addresses.
E-mail addresses often start with the username, and personal
information on the page may provide you with good ideas for
guessing passwords. With names of individuals in hand, you
can use other publicly available information, social media
sites, etc, to gather more information that may help for
guessing passwords or setting up some of the other attacks
on this list.
- violence and threats —
Violence or other kinds of non-cyber threats. This kind of
speaks for itself. "Gimme you password or I'll break your kneecaps!"
- trickery — Phishing attacks or other kinds
of misdirection to try and trick users into giving away
Since people often reuse passwords, stealing passwords for
other accounts may be useful.
- unchanged defaults —
Some accounts, like the administrator account for the
wireless base stations in our wireless lab, have
a default password. If the owners of those
accounts neglect to change the password, breaking in is easy,
because the values of the default passwords are usually
well-known, i.e. can be discovered by a simple internet search.
Your instructor broke into your base stations this way in
the wireless lab. Routers, base stations, administrator
accounts for web servers are all examples of places where
unchanged default passwords offer a way in.
predictable passwords —
There are some passwords,
are commonly used. For systems that don't enforce more
stringent requirements on their users, these are good guesses.
passwords sent in clear —
When passwords are sent over networks without encryption
(sent "in the clear"),
anyone able to snoop the network traffic can simply read
them. Some older tools, like
ftp clients (as
sftp) sent passwords in the clear
and, sadly, those tools have not completely disappeared.
Up until quite recently, professors at the Academy were
allowed to manage their web pages using
Now, fortunately, our web server does not allow ftp
connections. Websites that you log into but which use http
instead of https are probably sending your password in the
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 (
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
timvic, we could try to get authenticated 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.
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 is 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
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.
- brute force attack, which means generating and
checking all possible passwords,
- 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
- 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).
Hijacking a process running with higher privileges —
We already discussed how a buffer overflow attack against a
server, like a web server, 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 hijack 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.
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 it, 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 described 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
web server, 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:
Breaking into the web server 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 web pages.
Infrastructure accessible via the Internet
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.
Check out this
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!