Entire web farms hacked to serve up the 7sir7 redirect
We have received reports and evidence that a number of companies that provide shared hosting web servers have had their servers exploited and all of the customer homepages modified so that visitors are attacked. In one case, a Perl script was used to modify each customers homepage with the additional IFRAME snippet that fellow handler Lorna had already reported in the diary
two days ago. The Perl script reads in the web server configuration (httpd.conf) on a compromised server, and then appends the malicious iframe code to all the index.html pages of all the virtual hosts available on this server. The same reader who managed to isolate this script has also contributed a script written by himself to clean up the affected pages. If you shout loud enough, we might include it in tomorrow's diary :-)
The page at 7sir7 is making use of several recent vulnerabilities in order to download and install malware on the PC of whoever visits the site.
- Exploits the .ANI cursor vulnerability (MS05-002)
- Exploits the HTML Help Cross Domain Vulnerability (MS05-001)
If successful, the exploits drop either of two files "mhh.exe" or "sr.exe",
both of which so far are only recognized by Kaspersky and called (not-a-virus:AdWare.ToolBar.SearchIt.h). The files have been submitted to the other AV vendors.
DNS Cache Poisoning
The second attack vector involves DNS poisoning. We are not quite sure yet how
this is being done, as the files that we've received so far "only" install the
ABX toolbar and do not seem to contain DNS/DHCP poisoning code. One submission
stated that the whole problem started when he added an ip helper-address on the
router to one of the VLANs that had infected PCs on it. The DNS server was
running W2K and Symantec Web Security, and once it was open to broadcasts from
the affected subnet, all systems that made DNS requests got redirected to 7sir7.
Dynamic DNS used to make tracking harder
When the issue was first reported (see diary of March 4), the three involved
domain names were resolving to
Until a few hours ago, the address being served up was "126.96.36.199" for all three domains. Thus, the parties behind this attack have quite skillfully "shifted" the target whenever an ISP started to block traffic or to shut down one of their servers. The involved DynDNS providers have been contacted in the meantime and were very responsive (thank you!!). Once the various DNS caches expire, 7sir7 and 123xxl should not resolve to the exploit site anymore...
...which is good, because during the last days, the exploit was hosted with a provider in Moscow, who answered to an inquiry with the following underwhelming statement: "If you want, you can send complaint to the court. We will act on the decision of the court."
Phishing through Cross Site Scripting
An interesting variant of phishing email was reported to us by a reader (thanks, Richard!). The parts identifying the culprit have been obfuscated in the excerpt below, but you get the drift.
Replace "SomeBank.com" with the domain name of a real finance institute, and
"spoofed-ebanking.biz" with the site hosting the fake e-Banking, and you end up
with a pretty realistic looking page, where everything but the center frame
(the one asking for your PIN, of course) is real.
Yet another Botnet
A reader (thanks, Seyfert!) has reported yet another variant of RBot/SDBot/Wootbot. We've submitted a sample to the AV vendors, and are trying to get the ISP to squelch the IRC channel used by the botnet.
Daniel Wesemann (with plenty of assistance by fellow handler Patrick Nolan)
EMail: echo "ebojfm/jtdAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'
Mar 13th 2005
1 decade ago