A Little History
Before there was gumblar.cn or martuz.cn, there was 220.127.116.11 and 18.104.22.168 which we have classified as Malicious since 2009-03-08 and 2009-04-02 respectively. These IPs were (and still are) involved in a mass compromise attack pointing to IP/jquery.js which peaked on 2009-04-25 at approx 17,000 compromised sites.
Screenshot of 22.214.171.124/news/?id=100:
Screenshot of Injected Code:
Screenshot of Deobfuscated Injected Code:
The Destination Page
The destination page that you are redirected to serves up different versions of the malicious content. It's not clear if this just happened to be because the malicious users are constantly changing the pages, or if they have a randomizer built into their server-side code to intentionally serve it randomly each and every time. There are three main parts to the page:
- Large Array named 'a' with numeric values
- An eval(unescape().replace()) piece of code
- A function named 'ttt()' which just returns a large string
Screenshot of Array gumblar.cn/rss/?id=568820:
The above screenshot is of the beginning of the source code for one of the pages served by gumblar.cn. You can see that it's very similar to the source of the 126.96.36.199 page shown earlier. These numeric values range from single digit values up to three digit values in the 100s. This is where the page stores its obfuscated contents.
Screenshot of eval(unescape().replace()) piece of code from gumblar.cn/rss/?id=568820:
Deobfuscated and formatted output of above before eval:
Screenshot of partial deobfuscated and formatted page:
The function 'ttt()' only gets called if an object can be created for either "ADODB.Stream" or "Scripting.FileSystemObject". Furthermore, when it's called it is done so as 'var d = b6(ttt());'. The 'b6()' function is shown in the deobfuscated screenshot above, and anyone familiar with Base64 encoding/decoding can recognize the code right away. So that means 'ttt()' returns a Base64 string which gets decoded by function 'b6()'.
Deeper Look at 'b6()' and 'ttt()'
When looking at the 'b6()' function and its code, something jumps out: the Base64 key is scrambled. Usually the key looks like 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=' but in the case of 'b6()' they scrambled it. I ported the code in 'b6()' to Perl and ran it on the same contents that were on the page. I then wrote the Base64 decoded output to a file. I have included the Perl code here (rename to gumblar.pl) and you need to supply command line arguments for the location of a file that contains the Base64 contents of 'ttt()' and the key to use. Example: ./gumblar.pl gumblar.txt DkexZd6UAw7j2PWB3LJKm8vQtbENY/XfusSG9VITCi1FRoa=ygM4pq5hl+rz0OcnH.
Output of running the *nix file command on the file:
So 'ttt()' stores a full piece of malware Base64 encoded - although this is not the first time we have seen malicious pages do that, it's definitely not common. By doing this the malicious authors can hide their binary as text when it's travelling across the wire, and then have it decoded at the client's browser.
Chart of Older Injection and Matches:
Chart of Gumblar Injection and Matches:
Chart of Gumblar vs Older Injection and Matches:
As you can see from the charts above, the number of compromised sites is very high and also growing at an alarming rate. It seems that the attackers behind this attack planned the injection very well so they could maximize the number of infected sites in a short amount of time. It has been mentioned by ScanSafe that the injections are mostly a result of FTP credential sniffing by Malware, but server-side exploits must have been used as well. As we continue to monitor this attack, we will publish any interesting findings.Security Researcher: Ali Mesdaq