ECE 4112 Internetwork Security
Lab 11: Web Security
Group Number: _______________
Member Names: _________________________
_________________________
Date Assigned: November 15, 2005
Date Due: November 22, 2005
Last Edited: November 9, 2005
Please read the entire lab and any extra materials carefully before starting. Be sure to
start early enough so that you will have time to complete the lab. Answer ALL questions
and be sure you turn in ALL materials listed in the Turn-in Checklist ON or BEFORE
the Date Due.
Goal: The goal of this lab is to examine various tools and techniques that can be used
to exploit weakness in web servers.
Summary:
This lab will introduce tools that can be used to see vulnerabilities on
an apache web server and to gain access to private pages.
Background and Theory:
Web server hacking refers to attackers
taking advantage of vulnerabilities inherent to the web server software itself (or one of its
add-on components). These vulnerabilities are typically publicized and are easy to detect
and attack. An attacker with the right set of tools and ready-made exploits can bring
down a vulnerable web server in minutes. For this reason, it is crucial for web
administrators to always patch their web server and related software.
Prelab Questions:
None.
Lab Scenario:
For this lab we will be accessing an Apache web server on the
Mininet whose ip address is 57.35.6.2. This is a RedHat7.2 Machine running Apache.
This emulates a web server without proper security update that you might find on the
web.
Copy the files from the Lab11 Folder on the NAS to the various machines:
On the WS 4.0 host machine:
# mkdir /root/lab11
1
# cp -rf /mnt/nas4112/Lab11/WS4/* /root/lab11
On the Windows XP virtual machine:
Create a folder called “lab11” on the desktop.
Copy the contents of the Windows directory of Lab11 on the NAS, to this folder.
Section 1: Web Security Utilities
Some of the following utilities will need SSL support so first and foremost, install
OpenSSL on the WS 4 host:
# cd /root/lab11
# tar xvfz openssl-0.9.6j.tar.gz
# cd openssl-0.9.6j
# ./config -shared --prefix=/usr/local/ssl -fPIC
# make
# make test
# make install
Now the utilities we install can use the SSL libraries.
WGET
When targeting a web server, a serious hacker would study its content thoroughly. This
might involve downloading its entire content for offline examining at his leisure. Doing
this manually would be very tedious and tiresome, so luckily there are some useful tools
readily available that would automate this process.
WGET is a free software package for retrieving files using HTTP, HTTPS, and FTP. It
can be downloaded from http://www.gnu.org/software/wget/wget.html.
To install wget: On the WS 4.0 physical machine, change to the utilities folder:
# cd /root/lab11/utilities
Now build wget:
# tar xvfz wget-1.9.1.tar.gz
# cd wget-1.9.1
# ./configure –prefix=/usr/local/wget --with-ssl
# make
# make install
To use wget to download a complete website, do the following:
# mkdir /root/lab11/downloaded
# wget -P /root/lab11/downloaded -m http://57.35.6.2
2
This transfers data to the folder /root/lab11/downloaded.
Q1.1: What data is transferred to this folder?
Q1.2: Why would this information be useful to attackers?
httpdtype and user discovery
Apache web servers, by default, are setup in a way that makes it easy for attackers to
determine the type of web server is running, what additional modules are built into
Apache, and what user accounts are present on the server.
The first simple utility we will look at is a program called “httpdtype”. It is available
from http://packetstormsecurity.nl in a package named “apscan2.tgz”. The other utilities
in this package are not useful for our purposes and will not be discussed.
On your Redhat WS 4 physical machine:
# cd /root/lab11/utilities
# tar xvfz apscan2.tgz
The other utilities are extracted as well but can be ignored.
Now, type:
# ./httpdtype 57.35.6.2
Q1.3: What is the output?
Another useful utility takes advantage of a bug in the Apache software, when run on a
Redhat machine, that makes user discovery quite easy.
If you try to access an existing users folder on an Apache server using a “~”, the server
will respond with a 403 error message, indicating “Forbidden”, since that particular user
has not set the appropriate permissions for their folder.
If you were to try to access a non-existent user in the same manor, the server would
respond with a 404 message indicating “Not Found”. Since that user doesn't exist.
Open up a web browser on your Redhat 8.0 physical machine, and type the following
URL “http://57.35.6.2/~root” and observe the results.
Now try “http://57.35.6.2/~rooty” [this lab assumes there is not a user called “rooty”]
Observe these results.
As can be seen, this is a very easy method to determine what user accounts are on a
particular server. C code included on NAS, named “arse.c”, which is short for Apache
3
and Redhat Security Exploit, will automate this process. This code can also be obtained
from http://packetstormsecurity.nl.
You have already downloaded “arse.c”, now we will compile it on the Redhat 8.0
physical machine:
# cd /root/lab11/utilities
# gcc -o arse arse.c
Now run “arse” in the following manor:
# ./arse 57.35.6.2 80 names.txt [“names.txt” contains various user names]
This will check server “57.35.6.2”, use port 80 (http), and check user names in
“names.txt”.
Q1.4: What user names were found?
Now we know what user accounts are on the server, information that is very useful to an
attacker. One very good use of this information will be shown following, where we
exploit a flaw in the basic authentication system that web servers use.
Cracking basic auth
Most web servers have information on them that is only intended for a certain user or a
certain group of users. To prevent access to this information by unauthorized individuals,
web servers can use “basic authentication”, the simplest method of authentication. For a
long time this was the most common authentication method used by all web servers on
the Internet and is still the primary form of access protection used by many.
We have setup a private folder on our web server. Attempt to browse to:
“http://57.35.6.2/private/” and see that an authentication prompt comes up.
[Note: a “/” is required after “private” above]
This page is only available to two users with passwords.
A bug exists in basic auth that sets no limits on the amount of simultaneous connections
and number of authentication attempts permitted. This makes the process of brute-forcing
your way into a secured folder or file much easier. Also, since we already know what
users exist on the system (from our “arse” output), we will only test passwords for those
particular users.
Note that the users for this directory may not necessarily match system users, which is
what we determined earlier, however, chances are very good that they usually will.
A really good brute-forcer for the Win32 environment is Brutus, available at:
http://www.hoobie.net/brutus/
4
As specified on the website:
Brutus has support for the following authentication types:
HTTP (Basic Authentication)
HTTP (HTML Form/CGI)
POP3
FTP
SMB
Telnet
Other types (must be imported)
The current release includes the following functionality :
Multi-stage authentication engine
60 simultaneous target connections
No user name, single user name and multiple user name modes
Password list, combo (user/password) list and configurable brute force modes
Highly customisable authentication sequences
Load and resume position
Import and Export custom authentication types as BAD files seamlessly
SOCKS proxy support for all authentication types
User and password list generation and manipulation functionality
HTML Form interpretation for HTML Form/CGI authentication types
Error handling and recovery capability inc. resume after crash/failure.
As you can see, Brutus can be very useful for cracking passwords with a large number of
protocols.
Install Brutus on your Windows XP Virtual Machine:
Create a new folder on the desktop called “Brutus”
Open the “lab11” folder on the desktop and double-click on the Brutus zip file. Extract all
files to the “Brutus” folder. Now, copy the “names.txt” (same file used with arse) from
the lab11 folder to the Brutus folder.
Now run “BrutusA2.exe”.
For “Target” specify: “57.35.6.2/private/”
for “Type”: HTTP (Basic Auth)
Under Authentication Options:
Check “Use Username”
For “Pass Mode”: Word List
For “User File”: names.txt
For “Pass File”: words.txt
Now click the “Start Button”
5
Q1.5: Are the passwords for the two users able to be cracked and if so, what are the
users and passwords and how long did it take?
Brutus is also very useful in the fact that it can also “brute-force” passwords. If you want
to try this, change “Pass Mode” to “Brute Force” and click “Start”.
Warning: If you don't set the “Range” settings to something close to the passwords you
are attempting to crack, you could literally be waiting for centuries.
Play around with the Brute Force Range options to get an idea about what takes the
longest.
Q1.6: What types of passwords would be easiest to crack? Which would be
hardest? Why?
Now, if you want play around with the many other features in Brutus to get a feel for
what all can be accomplished with this software.
Section 2: Vulnerability Scanning
Several tools are available to automate the process of parsing web servers for the
numerous exploits that are continuously found in the hacking community. Commonly
called “vulnerability scanners”, these types of tools will scan for dozens of well-known
vulnerabilities. Attackers can then use their time more efficiently in exploiting the
vulnerabilities found by the tools.
In this lab, we'll use one of the more popular scanners called “Nikto”. It can obtained
from: http://www.cirt.net/code/nikto.shtml.
The description on the website states:
Nikto is an Open Source (GPL) web server scanner which performs comprehensive tests
against web servers for multiple items, including over 2600 potentially dangerous
files/CGIs, versions on over 625 servers, and version specific problems on over 230
servers. Scan items and plugins are frequently updated and can be automatically updated
(if desired).
We will install and use Nikto to see what we find. Since Nikto is a Perl script, it requires
the Perl module Net::SSLeay for it to have HTTPS support. That module can be obtained
from: http://www.cpan.org/authors/id/S/SA/SAMPO/Net_SSLeay.pm-1.25.tar.gz.
We will now install Nikto and the Net::SSLeay module.
On your Redhat WS 4 physical machine:
# cd /root/lab11
6
# tar xvfz Net_SSLeay.pm-1.25.tar.gz
# cd Net_SSLeay.pm-1.25
# ./Makefile.PL
# make install
# cd ..
# tar xvfz nikto-current.tar.gz
# cd nikto-1.32
# ./nikto.pl
This will display Nikto's large variety of command-line options. For more detailed
descriptions consult the “nikto-usage.txt” file in the /docs folder.
To test the vulnerabilities on our web server type:
# ./nikto.pl -h 57.35.6.2 -p 80,443 > outfile.txt
This will scan the web server on our Redhat 7.2 Virtual Machine on port 80 (http) and
port 443 (https). The “> outfile.txt” will output to the file what would normally be
displayed to the screen.
Open “outfile.txt” in your favorite text editor to observe what is found.
Attachment 1: Attach a printout of this for Port 80 only (header shows where this
starts).
Q2.1 How can this information be used to a hacker's advantage?
If you are wondering what reflection will be made on the server in terms of logs files, etc.
we have included an access log from the server after being subjected to the same attacks.
On your WS 4 machine it is “/root/Lab11/access_log”. Open this with a text editor (it is
a large file) and look at the contents.
Q2.2 Is it apparent that a scanner (in our case, Nikto) was run and if so how can
you tell? What about Brutus?
7
Answer Sheet Lab 11
Group Number: _______________
Member Names: _________________________
_________________________
Section 1: Web Security Utilities
Q1.1: What data is transferred to this folder?
Q1.2: Why would this information be useful to attackers?
Q1.3: What is the output?
Q1.4: What user names were found?
Q1.5: Are the passwords for the two users able to be cracked and if so, what are the
users and passwords and how long did it take?
Q1.6: What types of passwords would be easiest to crack? Which would be
hardest? Why?
8
Section 2: Vulnerability Scanning
Q2.1: How can this information be used to a hacker's advantage?
Q2.2: Is it apparent that a scanner (in our case, Nikto) was run and if so how can
you tell? What about Brutus?
How long did it take you to complete this lab? Was it an appropriate length lab?
What corrections and or improvements do you suggest for this lab? You may cross
out and edit the text of the lab on previous pages to make corrections. What
corrections and or improvements do you suggest for this lab? Please be very specific
and if you add new material give the exact wording and instructions you would give
to future students in the new lab handout. You need to be very specific and provide
details. You need to actually do the suggested additions in the lab and provide
solutions to your suggested additions. Caution as usual: only extract and use the
tools you downloaded in the safe and approved environment of the network security
laboratory.
Turn-in Checklist
 Answer Sheet
 Nikto output for Port 80
9