Friday, August 2, 2013

MMD-0004-2013 - "You hacked.. we cracked" - "WP Super Cache" & Glazunov EK

"I dedicated this post to our members on visit to BlackHat & Def Con 2013, who's helping to present our group in the security community, with deeply regret that I could not make it to go there, no matter how bad I would like to.
Thank you to @hugbomb, @set_abimone and @kafeine for the help in the spotting redirection, EK confirmation and flushing samples, to @hFireF0X and other Kernel Mode members for helping figuring & quick mitigating the new version of Zero Access spotted in this threat!"

Background

I was mentioned about an infection by our team's @hugbomb: I cleaned the site within 24hrs, after releasing my neck of the woods.. :-)
I made domestic report in here -->>[0day.jp], and this is the post about how the malicious redirection was made.

The nature of the infection is, only IE browser with java plugin access is affected, a non direct access. Some parts of the a kind of ACL used in this redirector us still on decoding process, so maybe we can report more feature they use upon 100% finished. If you meet the accepted condition, you will be redirected to Glazukov Exploit Kit to infect you with Zero Access/Sireref malware. I had hard time in confirming this site, so I had to ask many friends to confirm the case and its condition by some tests. The good thing is the site's admin is very supportive and asked me to make investigation properly and allowing this post to be publicly published to prevent more infection.

First, we have to be sure WHICH CODES and WHERE had been injected:

Is that it?? Nope.. The diff result shows more, during the injection session, the header was added with these stuff too:

1,9d0
＜ HTTP/1.1 200 OK
＜ Date: Mon, 29 Jul 2013 10:24:55 GMT
＜ Server: Apache
＜ X-Pingback: h00p://VICTIM.SITE/xmlrpc.php
＜ "Set-Cookie: stats=446501053769c06c565094b26d26e8ef; 
               expires=Mon, 29-Jul-2013 13:24:56 GMT"
＜ Connection: close
＜ Content-Type: text/html; charset=UTF-8
＜ Content-Length: 61451
＜
↑Noted this: the header was added with the setting of cookie with stats variable and an expiry date which doesn't exist during the normal mode.
OK, let's move on and see carefully how the breakdown of the injected code goes:

Explanation:

We see the javascript tagged codes, usage of specific cookie, user will be firstly forced to call the landing page of Glazunov Exploit Kit at upper URL, then the checking interface of browser components using PluginDetect (noted: version 0.8.1) will be performed, the condition in Java Exploitation will depend on detected Java version.

If the Java version is ver 7 the JNLP base infection via "buj58i7kc3.jnlp" will be perform, or else the direct Jar class "weptblklaadp.nfpmuqaplgapmsrrmnranye.class" of "8.zip" a CVE-2013-1493 JAR Exploit. In my previous report here -->>[kernelmode.info] I know the payload is a new type of ZeroAccess/ MaxPlus / Sireref payload trojan.

Pictures of the infector components and CVE method used in the Jar(ZIP) infector

Spotting the infection source

So how this code can be injected? This is the point of this post.
Please see the picture above in the marked red below part. It stated: 

＜!-- WP Super Cache is installed but broken. 
The path to wp-cache-phase1.php 
in wp-content/advanced-cache.php must be fixed! --＞
Confirming this to the site owner and found that error wasn't suppose to be happened.

I executed the first stage on checks by run into .htaccess, php.ini, default.php etc, wasn't finding anything suspicious, and went deeper to find the apache module is in place, so does the web server daemon used.
Went back to .htaccess and found myself staring into this line : 

RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html" [L]

OK, this is the Wordpress Super Cache plugin is running, intrigued by the error caused by the same plugin made me dive into the plugin directories: 

  :
2013/07/23  00:00     514 advanced-cache.php
2013/07/23  00:00   1,259 wp-cache-base.php
2013/07/23  00:00   2,988 wp-cache-config-sample.php
2013/07/23  00:00  25,524 wp-cache-phase1.php
2013/07/23  00:00  60,553 wp-cache-phase2.php
2013/07/23  00:00 180,031 wp-cache.php
2013/07/23  00:00  52,772 wp-super-cache.pot
  :
This is just perfectly strange, since everything was installed on 2012/07/23 at exactly midnight :-)) lame..
Just to be sure I made detail comparison to the original plugin:
To find the size changes, but no differences in codes after I "diff"-ed them.. weird.. Making me think the attacker was storing stuff to normal after injection stored?

Let's see what we got now, WP cache plugin error, strange plugin files dates, and an injected code.

Went back to the injected code, found that the obfuscation built by Zend, and using this as grep "significant" character to find the list of the injection code's file sources:

Noted: the yellow color is the files and their path, all of them was injected in the first lines, and the green color is the similarity found in Zend framework builder used.

below is the list of these injectors: 

wp-content\advanced-cache.php
wp-content\wp-cache-config.php
victim.site\wp-content\advanced-cache.php
victim.site\wp-content\wp-cache-config.php
And now we know why the error in the top page occured! :-)

The attacker also injected codes in the current WordPress Theme used by the victim, again I pasted the "atahualpa" theme files injected by the malware code: 

victim.site\wp-content\themes\atahualpa\comments-paged.php
victim.site\wp-content\themes\atahualpa\comments.php
victim.site\wp-content\themes\atahualpa\footer.php
victim.site\wp-content\themes\atahualpa\functions.php
victim.site\wp-content\themes\atahualpa\index.php
victim.site\wp-content\themes\atahualpa\legacy.comments.php
victim.site\wp-content\themes\atahualpa\searchform.php
Seeing closely into each file we can guess WHEN the attacker was replacing these files:

Understanding how the malicious code works..

Well, the code used to inject pages is as per pasted "safe" code here-->>[PASTEBIN]
The first level of obfuscation process extracted from the code is-->>[PASTEBIN]
With noted(AGAIN): The code is only for view and can't be executed, a.k.a. I "hexed" the codes.

Following the decoded one, in the below line number you'll see this codes:

It shows the regex operation to grab and replace the original contents, and insert the injection code after assembled with the tags ＜BODY and ＜/HTML (marked in purple color), to be noted all of these are possible by the abuse of Wordpress plugin mentioned.

I tried to manually further decode to find two similar pattern obfuscation blocks, each block contains these parts with the below logic:

Obfuscation block...

Decoder..

Parser of the decoded codes..

Well the above codes are a rough copy-paste of my notepads, all you have to do next is grab the blob of data, modified a bit as per those moronz wanted, decode it using the logic seen in the decoder parts, and parse it out.

I tried to follow the flow of codes manually, use only one text editor, but it looks like things went off the rails somewhere.. So it looks like I get stuck in the final decode status here -->>[PASTEBIN]

During to the decoding the blob manually, some of the interesting result shown:

Exclusion of the user agents... 

$user_agents = array ("Google",
                      "Slurp",
                      "MSNBot",
                      "ia_archiver",
                      "Yandex",
                      "Rambler
Passing ot the user-agent to the Exploit Kit url... 
if((preg_match("/".
   implode("|", $user_agents)."/i", 
      $_SEVER['HTTP_USER_AGENT'])) or
         ( isset($_COOKIE['stats'])))
At this point I realize that more effort in de-obfuscation will take more time and energy (I have to do it from beginning all over again), which I don't have thise right now, not in the weekdays. So I reproduced the injection source script in the PHP with WP server test environment to get the injection code as per pasted here, bit by bit in text -->>[PASTEBIN]
Noted that the path of the exploit kit and the name of zip/Jar file name has changed. The code is hexed also.

I look further to finish decoding this weekend, hope this writing helps people who got hit by the same threat. Be free to ask me question via comment part of this post.

Additional:

Our members found the trace of similar obfuscation, assumed the previous attacks. So is in the wild..

Moral of the Story

This threat is harmful, as harmful and nasty as a Rogue Apache modules or a Rogue Web Server; Wordpress Super Cache is providing every tools to make the redirection, to control the access, to grab HTTP request and change & parse it into a malicious one in a snap.. And better yet, is easy to be implemented by hacker.. I mean, all they do is making sure you have the old version of WP Super Cache (which can be found out by remote/HTTP checks), brute (or buy) your (stolen) FTP account (somehow) and things like I posted here will happen. The attacker doesn't even need to hack your Apache module, and no need to have root permission to replace the web server related system, thus not leaving many traces (i.e. no .htaccess, no ptp.ini , no default.php, no strange conf to touch..), and a successfully attacker can camouflage their codes like putting a needle in a haystack. And with noted, this is a real IR case friend.. a PoC to what we should aware more of this threat.

I hope all of the WP users to aware of the security risk on using useful plugins they use, as much as they aware its usefulness. Stay update your versions of CMS and its plugins, change your FTP server password regularly (I don't say oftenly) and your risk to have a hacked server like this will be minimized.

Stay safe friends!

#MalwareMustDie!!

Posted by unixfreaxjp at