Server side iframe injections via Apache Modules and SSHD backdoor

There are many ways to inject a malicious payload on a compromised site. The attacker can modify any of the web files (index.php for example), the .htaccess file or php.ini (if the site is using PHP). There are other ways, but those are the most common methods, specially on shared hosts.

However, for the last year, we started to see a new way to inject malware on compromised servers via a malicious Apache module. We posted about it before and it has been covered on many other locations. However, after a few months tracking those and working on multiple servers that had this issue, we want to share a bit of what we learned.

Identifying the injection

First, a good way to identify if an infection is coming via the Apache module compromise is by looking at how the iframe is being inserted. They seem to always follow this pattern:

<style<.t1nhuhjv { position:absolute; left:-1619px; top:-1270px} </style> <div class=”t1nhuhjv”><iframe
src="httx://qotive. changeip.name/random/" width=”534″ height=”556″> </iframe></div>

or

<style>.q6umct6stl { position:absolute; left:-1284px; top:-1774px} </style> <div class="q6umct6stl”><iframe
src="httx://nujifa. longmusic.com/kdqjagzxwbakl/cdce48ffcf125f41206a9ed88675b56b/" width="367" height="411"></iframe></div>

However, the domain name changes very often (IP often was 62.75.235.48), as does the div class name and the iframe sizes. Those are some of the domains we have tracked:

http://mailboxworkssli.com/?a=YWZmaWQ9MDE3ODg=

http://versusboxmask.info/?a=YWZmaWQ9MDE3ODg=

http://magicsstolens.info/?a=YWZmaWQ9MDE3ODg=

http://servershosstfrienduns.net/?a=YWZmaWQ9MDE3ODg=

http://computershosstbrouns.com/?a=YWZmaWQ9MDE3ODg=

http://namesstillsleags.net/?a=YWZmaWQ9MDE3ODg=

http://sitesstillsleags.net/?a=YWZmaWQ9MDE3ODg=

http://carssubjectchoicechips.net/?a=YWZmaWQ9MDE3ODg=

http://sitesellingsappfourd.net/?a=YWZmaWQ9MDE3ODg=

http://orlandoslimbigs.net/?a=YWZmaWQ9MDE3ODg=

http://spellingtells.net/?a=YWZmaWQ9MDE3ODg=

http://domainsrandomsswopp.net/?a=YWZmaWQ9MDE3ODg=

http://adeptsponsorlin.info/?a=YWZmaWQ9MDE3ODg=

http://domainssinglsnetss.info/?a=YWZmaWQ9MDE3ODg=

or

http://rulanife.longmusic.com/tc0kvqzxw8tplc/afee21e0c3a4cf80bc3255202a0739a7/ (62.75.235.48)
http://nujifa.longmusic.com/kdqjagzxwbakl/cdce48ffcf125f41206a9ed88675b56b/ (62.75.235.48)
http://zoreqa.changeip.name/koqfazzxwr2w245zl/afee21e0c3a4cf80bc3255202a0739a7/ (62.75.235.48)
http://wewezo.changeip.name/gg8nq3zxwzyacky/affe21e0c3a4cf80bc3255202a0739a7 (62.75.235.48)
http://powotu.longmusic.com/4ojldhzxwkfzrkb/e935dcd5a72531f51b5ee69f465ce860/ (62.75.235.48)
http://bisobobuk.longmusic.com/pvnx9jzxw4pe3wzn/e935dcd5a72531f51b5ee69f465ce860/ (62.75.235.48)
http://lagefoze.changeip.name/edubhlzxwjlxlfcw/e935dcd5a72531f51b5ee69f465ce860/ (62.75.235.48)
http://zepuyetit.changeip.name/cxrv6hzxwecblwb8/e935dcd5a72531f51b5ee69f465ce860/ (62.75.235.48)
http://cacowoj.changeip.name/efvch6zxwyuhu/b289156cca80d8546795dbf2bda7dbab/ (62.75.235.48)
http://vunovolev.changeip.name/ogwtmkzxwfumd/e935dcd5a72531f51b5ee69f465ce860/ (62.75.235.48)
http://dohana.changeip.name/iwnjvpzxwh7elk/e935dcd5a72531f51b5ee69f465ce860/ (62.75.235.48)
http://bibepi.changeip.name/yslz6zxwkents/e935dcd5a72531f51b5ee69f465ce860/ (62.75.235.48)

As you can see, early on they were using .net’s and .info’s domains and recently switched to using domains from Change IP (changeip.name, longmusic.com and others). Another interesting point is that since .co.cc got disabled, we are seeing many attacks using Change IP: http://labs.sucuri.net/?note=2012-12-10.

Apache Module

The attackers modify the httpd.conf (or any configuration file inside /etc/httpd/conf.d) and insert a line to inject their own modules:

LoadModule pool_mem_module /lib64/libwutfa.so.2

or

LoadModule bench_proxy_module /lib64/libhdast.so.1

or

LoadModule string_log_module /usr/lib/libcehf.so.7

The module names and location are pretty random and their md5 checksums also seems to change often:

6b704ca7d3454830d212c88ffd6250c0
61051d0d1c7bdc109aa27732b94c94c0
82b0da95b511cdd02b377072b4fcada7

However, once loaded, they inject an iframe at the top of the site once per day per IP address and only to certain user agents. That makes discovering and tracking the malware much more difficult.

Dennis (from Unmask) was able to find the source code for those modules, and posted on his blog: Malicious Apache Module Injects Iframes, so we won’t go into much more details here, since he covered it very well.

A good way to identify if you have any non standard module is by running the rpm command and checking the integrity of the files:

# rpm -qf /lib64/*
# rpm -qf /usr/lib/*
# rpm -qf /etc/httpd/modules/*

If you find any module that is not part of any package (not owned by anyone), it is a good red flag that this module was added by the attackers.

SSHD binary

Another part of the compromise that we didn’t see mentioned any where else was how the attackers kept access to the owned servers. We noticed that they modified all SSH binaries and inserted a version that gave them full access back to the server.

A good way to identify those is to run the rpm -Va command to see all file changes. If SSHD has been modified, you would see this error:

S.5…… /usr/bin/scp
S.5…… /usr/bin/sftp
S.5…… /usr/bin/ssh
S.5…… /usr/bin/sshd
S.5…… /usr/bin/ssh-add
S.5…… /usr/bin/ssh-keyscan
S.5…… /usr/bin/ssh-keygen

We ran the sshd binary through virus total and 0 (none) out of 46 anti virus engines flagged it: https://www.virustotal.com/file/ebfd9354ed83635ed38bd117b375903f9984a18780ef86dbf7a642fc6584271c/analysis/1357925310/

We were not able to fully inspect the modified SSH binaries yet, but it seems to do 2 things:

  • Every time some one logins to the server, it sends the host/user/pass to openssh.info or linuxrepository.org.
  • Every time someone uses the ssh binary, it also sends the host/user/pass to openssh.info.

Allowing them to maintain their access and spread to other servers that are accessed from the compromised box.

Conclusion

We are still tracking and monitoring this type of infection, so expect more updates soon. If you have any details to share, please let us know.

Read more: Server side iframe injections via Apache Modules and SSHD backdoor

Story added 23. January 2013, content source with full text you can find at link above.