|
Scan 31
Write-Up By: Ryan C. Barnett This month's challenge is to analyze web server
log files looking for signs of abuse. The Honeypots: Monitoring and
Forensics Project deployed an Apache web server that was configured as an
Open Proxy. Your job is to analyze the log files and identify/classify the
different attacks (trust me, there are a surprising number of them :). All
entries are due Friday, 30 April. Results will be released Friday, 7 May.
Find the rules and suggestions for submissions at the SotM Home Page. Skill Level: Intermediate |
|||||||||||
|
The Challenge: a. Honeynet Web Server Proxy IP sanitized to: 192.168.1.103 Download the Image (25 MB) 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
3. Gunzip and untar the archive
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
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.
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.
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.
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.
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.
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.
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.
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:
|