Author: Zenomorph
admin@cgisecurity.com
"Fingerprinting Port 80 Attacks:
A look into web server, and web application attack signatures: Part Two."
I. Introduction
II. More Common Fingerprints
III. More Advanced Fingerprints
IV. Cross Site Scripting examples
V. Modified Headers
VI. More Encoding
VII. Web Server Codes and Logging
VIII. Conclusion
IX. References
I. Introduction:
Port 80 is the standard port for websites, and it can have a lot of different security issues.
These holes can allow an attacker to gain either administrative access to the website, or even
the web server itself. This second paper was written to help the average administrator and
developer to have a better understanding of the types of threats that exist, along with how to
detect them.
II. More Common Fingerprints:
This section has examples of more common fingerprints used in exploitation of both web applications,
and web servers. This section is not supposed to show you every possible fingerprint, but instead
show you more ways an attacker can possibly get into your system, along with how an attackers presence
could be masked. These signatures should pick up most of the remaining methods not spoken about in
the first paper. This section also describes what each signature is used for, along with examples
of it being used in an attack.
" * " Requests
The asterisk is often used by attackers as an argument to a system command.
Below is an example
* http://host/index.asp?something=..\..\..\..\WINNT\system32\cmd.exe?/c+DIR+e:\WINNT\*.txt
This request is asking for all text files within the directory of e:\WINNT to be listed.
Requests like these can often be used to gather a list of log files, along with other
important files. Not a lot of web applications use this character in a valid request so
this makes an asterisk stand out in logs.
* http://host/blah.pl?somethingelse=ls%20*.pl
This request is asking for a directory listing on a Unix system of all perl scripts that end
in .pl.
" ~ " Requests
The ~ character is sometimes used by attackers to determine who is a valid user on your system.
Below is an example
* http://host/~joe
This request is looking for a user named "joe" on the remote system. Often times users will have
web space and if the attacker manages to visit a web page, or get a 403 error(Denied error) then a
user exists. Once an attacker has a valid username, they may try guessing passwords, or brute forcing
until they get a valid password. There are other ways of finding out who is a valid user but this is a
port80 request so I figured I'd mention it. (This is a well known method) It can easily be misidentified
as a valid request in IDS logs depending on if the system has user pages in this format.
" ' " Requests
If this particular character shows up in your logs then there is a possibility someone is
trying a SQL injection attack against your software. Often times programs may be written poorly and
may allow an attacker to insert SQL commands into the script. If it is possible to execute system
commands then it may be possible for an attacker to gain administrative access to your system.
(Sometimes administrators run SQL as root on Unix, and if you run MS-SQL it already runs
with administrative privileges)
Below is an example.
* http://host/cgi-bin/lame.asp?name=john`;EXEC master.dbo.xp_cmdshell'cmd.exe dir c:'--
This request is executing the cmd.exe shell on a windows NT machine. From here an attacker
has free reign on the remote machine with access to add users, upload trojans, and steal
the sam password file.
For more information on SQL attacks visit www.cgisecurity.com/lib and check out a few papers
we've collected from various sites on the subject. Also check out www.owasp.org for further
examples of SQL Injection.
" #, {} , ^ , and [] " Requests
These particular characters may show up in your logs if an attacker is echoing some source code
into a file of a perl or c program. Once a file is created and compiled/interpreted the attacker
could bind a shell to a port giving themselves easy access.
I won't show a complete example of this because in order to do so I'd have to paste a bindshell program.
This paper wasn't written to give people easy to follow example on how to use trojans. For this
reason I have decided not to include an example. [ and ] may also be used as a command argument
in Unix for commands like ls -al [a-f]*. This would list all the files starting with characters
between a and f. # may show up if an attacker is uploading a perl script backdoor
(Ex: #!/usr/bin/perl at the top of the file).
Below is an example using #
* http://host/dont.pl?ask=/bin/echo%20"#!/usr/bin/perl%20stuff-that-binds-a-backdoor"%20>/tmp/back.pl;/usr/bin
/perl%20/tmp/back.pl%20-p1099
" ( and ) " Requests
This value is often used in cross site scripting attacks. Cross Site Scripting
has gotten a lot of attention lately, and a lot of large sites still suffer
from this type of attack.
Below is an example.
* http://host/index.php?stupid=
This example above will be sent to the index.php. From here an output page
will be displayed with the following javascript. Next your browser will execute
this javascript and display a popup window. Cross site scripting is considered
a low to medium threat. It does have the ability to allow an attacker to steal
cookies from you. An obvious way to prevent this would be to make sure the output
doesn't contain < or > in them. This way the javascript will not be executed.
" + " Request
Sometimes the + is used as a blank space similar to "%20" as mentioned in my
previous paper. This value (when used in an attack) is often used with cmd.exe
backdoored hosts. Often times an attacker or worm will copy cmd.exe to a file inside
the webroot. Once this file is copied an attacker has full control over your windows
machine. He will use the + character to help pass arguments to the script. If this
character comes up in your logs don't freak. This character is widely used with
web applications and it can be easily misidentified. If it manages to pop up in your
logs you may want to double check them but there is no reason to panic.
Below is an example.
* http://site/scripts/root.exe?/c+dir+c:\
This particular example is showing a request to a backdoor called root.exe. This backdoor
is installed by sadmind/IIS worm, Code Red, and Nimda after a host is compromised. The +
character is often used in windows backdoors that involve cmd.exe copies.
Additional Worm Information
http://www.cert.org/incident_notes/IN-2001-09.html
III. More Advanced Fingerprints
This section focuses more on the files an attacker or worm may request, along with
a few other signatures that stand out. This isn't a complete list of requests
or files an attacker may request, but it will give you a good idea of what is being
attempted against your system.
Lots of "/" Requests
If you check your logs and see A LOT of "/" characters then there is a good chance an attacker
is attempting to exploit a well known apache bug. This bug which effects every version of apache
before 1.3.20 and allows directory listings. If you see this in your logs someone is attempting
to exploit you. (This fills up logs FAST)
Below is an example.
*http://host////////////////////////////////////////////////////////////////////////////////////////
The way this exploit works is the attacker runs a script that keeps adding a slash one at a time.
Eventually on an affected system the attacker will be able to gather file listings, among other things.
* Common files and directories an attacker will request.
"autoexec.bat"
This file is started by certain versions of windows every time at boot up.
Often times after an attacker has done what he wants with a box, he/she will install tools
to remove logs and any reference to an intrusion taking place. An attacker may modify this
file and insert commands into this file. Next time the machine is rebooted logs/traces can
be wiped and the attacker is home free. People running a web server on windows 95 and 98
will be affected by this problem. You should only be running a public web server on
NT/2000 with NTFS for security purposes if you plan on using a windows product.
"root.exe"
This is the backdoor left by Sadmin/IIS, Code Red, and Nimda worms. This backdoor is a
copy of cmd.exe renamed to root.exe and put inside the webroot. If an attacker or worm
has access to this file, you can bet your in trouble. Common directories this file
resides in are "/scripts/" and "/MSADC/".
"nobody.cgi 1.0 A free Perl script from VerySimple "
This is a cgi program, which was originally written to help provide admins with
a shell backdoor. It also has a hefty warning by the programmer explaining the dangers
of improperly using this program. This is now a popular backdoor used by attackers
to execute commands with the permission of the webserver. You really would be
surprised how often I see this popping up. Hanging in chat rooms I've seen 3
different occasions where people (unaware of each other) have used this script.
Oh and no I won't give you the link to this product.
"[drive-letter]:\WINNT\system32\LogFiles\"
This is the directory that contains the IIS server logs. An attacker may
attempt to view your logs via a web application hole. If you see a reference
to system32/LogFiles there is a good chance your system is already taken over.
"[drive-letter]:\WINNT\system32\repair\"
This is the directory that contains the backup password file on NT systems.
The file will either be named "sam._"(NT4) or "sam"(Win2k). If an attacker manages
to get a hold of this file then you're in for some real trouble.
Novell File systems
"[server-name]:SYSTEM:PUBLIC"
This is an example Novell file system. It may be possible an advanced attacker with
deep knowledge of Novell may try to view files remotely. Getting information such
as the intranet server name may not be too easy on the other hand.
IV. Cross Site Scripting Examples
Cross site scripting attacks are often used by an attacker to make the user
think that certain information is actually coming from another site. These attacks
are often used in scams, or when an attacker is trying to fool people into thinking
certain things about companies in order to lower the price of the stocks, product prices,
etc.. One problem with this attack type is that the attacker must have the user
click on a link he provides in order to view this information. Sometimes an attacker will
use other existing holes to make this process more believable. These attacks are very common
and a lot of major sites are affected by this attack type in some way or another.
Below are a few examples of requests an attacker will use when trying to fool
a user.
Example 1: The IMG tag
* http://host/search/search.cgi?query=
Depending on the website setup and if the search engine doesn't filter requests
for html tags, this generates html with the image from host2 and feeds it to the user
when they click on this link. Depending on the original web page layout it may be possible
to fool a user into thinking this is a valid article. One problem is the url above
is very obvious and anyone with half a brain would notice something was wrong. This request
could be encoded on the other hand so that when a user clicks on this link they do not get
suspicious. I posted an example in relation to perl.com a few months ago and even managed
to fool a staff member at O'Reilly with this. (Only for like an hour though :)
Example 2:
* http://host/something.php?q=
If a user clicks on this link a JavaScript popup box displaying the sites domain name will
appear. While this example isn't harmful, an attacker could create a falsified form or, perhaps
create something that grabs information from the user. The request above is easily questionable
to a standard user but with hex, unicode, or %u windows encoding a user could be fooled into
thinking this is a valid site link.
Example 3:
* http://host/
This particular request is very common example. About once a month I'll
see a new script that is affected by this. If you see something like this
in your logs, there is a good chance someone is testing your scripts out.
V. Modified Headers:
I recently wrote a paper on web statistical software and the types of exploitation
that can happen via http header modification. I will use a few excerpts of this
paper below to show you the types of fingerprints that exist for it.
This paper can be found here
* Http://www.cgisecurity.com/papers/header-based-exploitation.txt
Below is a review of some things to look for in your logs.
x.x.x.x - - [10/Dec/2001:09:03:39 -0500] "GET / HTTP/1.1" 200 10453 "http://www.cgisecurity.com" "Mozilla/4.0
(compatible; MSIE 5.5; Windows NT 5.0; T312461)"
We are going to look at the 11th and 12th field in this log.
11th "http://www.cgisecurity.com" Referrer Field
12th "Mozilla/4.0" User Agent Field
These fields are filled in by your browser automatically. If I had a link on
www.hosta.com that pointed to my site and clicked on it, then my browser would save this information
and forward it to my website. This information is known as the referrer field. The referrer field is
filled in by your browser automatically, which means this information is provided by the client, and
not the server. This means this information is "user input". Since this information is user input this
means we can change it to whatever we want.
The threat in this is that certain types of software gather the values from your logs
and display them out. (Example Web Stats Software) Some software doesn't do stripping
of metacharacters very well and because of this code insertion is possible.
Example 1:
su-2.05# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
Referer: (Yes Referrer is spelt wrong)
User-Agent:
"In this example the attacker is inserting SSI tags into the "Referrer" and User-Agent
fields. Depending on whether the software outputs this information as text or in image form,
this could lead to possible file includes, or command execution. (Of course these examples
could be interchangeable) If the logs are shown as text and displayed in a shtml file, and
the referrer, or user agent fields are shown (Most of the time they are), then these two
requests will be included in the file. Now next time a visitor views these logs, the SSI tags
will be executed by the web server, and should display the results of the "id" command, and
the contents of "somefile.log".(Once again depending on server configuration)"
- * Http://www.cgisecurity.com/papers/header-based-exploitation.txt
If for any reason you find a request like this in your logs, then it may
be possible someone is trying to exploit you.
Below is another example from my previous paper.
Example 2:
su-2.05# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
Referer:
User-Agent: