Thursday, January 23, 2014

..And another "detonating" method of CookieBomb 2.0 - Part 1

Note: 日本語版の調査方法を別途書いたのでアクセスはこちらーー＞「BLOG.0DAY.JP」
Note: For the step by step easy decoding using wireshark & browser (w/many screenshots, ps: different victim site) go to Japanese writing here (use Google Translation pls)ーー＞「BLOG.0DAY.JP」
Note: CookieBomb 2.0 is using double cookie cushions, this post we decoded 1st cushion and quick decoding to "trigger" the redir URL only, the second cushion decoding notes and analysis report is in here -->>[Part 2]

Spoiler: The tweet of the front obfuscation design of CookieBomb 2.0:

Background

My college in local security community visited and dare me to check on an obfuscation he can not judge what malicious category the case is. Since I am in the health treatment for a recovery and he is so nice to visit, so I accepted the challenge and helping him out with it, under condition to share this knowledge to the world :-)

The case is a local school's web site that is suffering by a malicious code injection. It looks like a CookieBomb case, and it has been a while that I didn't crack one of the recent codes and this one looks different. The case is interesting, you can fetch the sample before we clean it up by the below simple wget (read: do not use your browser) method: 

$ wget h00p://www.nose-highschool.ed.jp/
--2014-01-23 12:10:54--  h00p://www.nose-highschool.ed.jp/
Resolving www.nose-highschool.ed.jp (www.nose-highschool.ed.jp)... 210.152.144.19
Connecting to www.nose-highschool.ed.jp (www.nose-highschool.ed.jp)|210.152.144.19|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html'
    [ <=> ] 20,017      --.-K/s   in 0.07s
2014-01-23 12:10:54 (276 KB/s) - 'index.html' saved [20017]

CookieBomb v2: First Cushion Injected Code

The index.html on this site is obviously injected by the code below, right in the middle of the home page itself:

By the traces of the format used I can guess automation injection tool was used.

Decoding

It was not difficult to decode the garbled codes above (by using your favorite javascript deobfuscating flavor) to get the below redirection based on cookie-as-trigger concept (read: CookieBomb). Let's see the result below. I actually expect an IFRAME injection or similar redirection, instead we are seeing a full HTML page code of an injection (see the red color), with the link to 91.239.15.61/google.js (see another red color).

You will see two parts of JS function (yellow color parts) which was meant to be used to read a cookie (if exists), or to make you have the cookie as a "ticket" to detonate "something bad" that will follow all these.

I just release a decoding flow for this first cushion script of CookieBomb in the pastebin so you can see its step by step works, the access is here-->>[PASTEBIN]. I wrote it as novice as possible, hopefully the IR fols can follow and understand it. It is important NOT to depend 100% in automation for the threat like this since there are many evading method that can be used in javascript layer to fool the scanner.

Next. Let's snip into the google.js. My tip for handling cookie bomb cases is, do not get too hasty on decoding, just see where the things are flowing first. Accordingly I just fetch the url written in the code, which having some ideas in my head, so let's see which idea is correct: 

// fetching the h00p://91.239.15.61/google.js
--2014-01-23 12:26:34--  h00p://91.239.15.61/google.js
Connecting to 91.239.15.61:80... connected.
 :
GET /google.js HTTP/1.1
Host: 91.239.15.61
HTTP request sent, awaiting response...
 :
HTTP/1.1 200 OK
Date: Thu, 23 Jan 2014 03:26:34 GMT
Server: Apache/2.2.22 (Ubuntu)
Last-Modified: Sat, 04 Jan 2014 20:39:44 GMT
ETag: "60ffc-8da-4ef2b06d38400"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 728
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/javascript
  :
200 OK
Length: 728 [application/javascript]
Saving to: 'google.js'
100%[=========================>] 728         --.-K/s   in 0s
2014-01-23 12:26:34 (13.4 MB/s) - 'google.js' saved [728/728]
Yes, I saved the file, and it contains another mistery as per snipped code below:

CookieBomb v2: Snippet of Second Cushion

I don't like the dirty code, so let's beautify it here -->>[PASTEBIN]
Following I will make explanation how to easy decoding this by using a notepad :-))

Quick "Detonating" Second Cushion Code (Not Decoding)

As per title in this section, this is a quicky, for the impatient friends who soon want to know where the next cushion is. So I will share you "a quicky" trick.
First, see the obfuscation data part is (as per below), all you must do is leave it as per it is, don't merge it, don't change anything, because instead of cracking the code your changes might destroy the obfuscation chain, and we really don't need to touch this part to solve this obfuscation:

You'll see also the three functions of getCookie, setCookie and checkCookie. The moronz behind this injection tools is making a useless effort by putting these functions to make us (read: good guys) wasting our time, so just ignore these functions too and let them be.

For the quick crack, the part that you should pay attention is this part only:

The red and orange marked parts are explaining a condition that should be passed (read: bypassed.) to detonate the decoding generator in line 174, well, to be specific the red part is obfuscating related condition and the orange one is a condition IF you have the desired cookie in your browser. So, by understanding this, you can detonate to figure the destination of forwarded URL of this new CookieBomb by eliminating those two silly functions and go straight to the value generated by deobfuscation generator logic, as the I coded below, just run it :-)

The URL that is being used to redirect the victim that is having a "ticket" (read: Cookie) for infection is marked in the red color.

Confirming the "Detonating" Result

Let's see IF the deobfuscation is correct, by accessing the URL.. 

--2014-01-23 13:02:31--  h00p://91.239.15.61/g.php
Connecting to 91.239.15.61:80... connected.
  :
GET /g.php HTTP/1.1
Referer: h00p://www.nose-highschool.ed.jp/
Host: 91.239.15.61
HTTP request sent, awaiting response...
  :
HTTP/1.1 302 Found
Location: h00p://goo.gl/Yun4bN
Date: Thu, 23 Jan 2014 04:02:32 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.4.9-4ubuntu2.4
Vary: Accept-Encoding
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Yep, the PHP is there alright. And..(why not?) try to trigger the "bomb" of this lame site w/the MMD's lame cookies ;-)) 
* About to connect() to 91.239.15.61 port 80 (#0)
*   Trying 91.239.15.61...
* Adding handle: conn: 0x28894100
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x28894100) send_pipe: 1, recv_pipe: 0
* Connected to 91.239.15.61 (91.239.15.61) port 80 (#0)
> GET /g.php HTTP/1.1
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
> Host: 91.239.15.61
> Accept: */*
> Referer: h00p://www.nose-highschool.ed.jp/
> Cookie: visited_uq=55;expires=Thu, 23 Jan 2014 14:40:07 GMT; path=/
>
< HTTP/1.1 302 Found
< Date: Thu, 23 Jan 2014 06:56:30 GMT
* Server Apache/2.2.22 (Ubuntu) is not blacklisted
< Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.4.9-4ubuntu2.4
< Location: http://goo.gl/Yun4bN
< Vary: Accept-Encoding
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
Yes, both efforts above were 302 redirected to some sites that is having some possibilities of redirection (read: TDS), with noted the short url used.
Meaning the CookieBomb PHP script (the server side tool) is in there and serving. If anyone can grab the data please let me know, I bet there is a new model of ESD.PHP used.

Infection Sources

The story is not end here, friends, you must feed the cookie request to this PHP file with the right parameter , use my previous writing here -->>[MMD Blog] and here -->>[MMD Blog] as guide to figure where this infection is heading :D - believe me, is not that difficult!
And that is for you to dig further, since I have to rest, so good luck! :-)

The injected code is having redirection to this IP (which is being utilized for CookieBomb PHP scripts): 

91.239.15.61
And the below URL are definitely bad: 
91.239.15.61/g.php
91.239.15.61/google.js
And you can guess the location of this IP :-)
The above information is the subject to clean up.

Next Post: Decoding of the Second Cushion Code

The full analysis of the second cushion of cookie cushion used in the google.js can be read here-->>[Part 2]
I am in purpose in separating the first cushion (this post) and second cushion in two series since the checking logic are actually very different, the connection is only at the infection traffic passed from the first to the second cushion. The second cushion will not reply on one script in the google.js but will use the TDS script that can be implemented in the same server as google.js itself OR other host < VERY important point. SO, this means that CookieBomb can be used to make infection chain jump around to one host into another in chains before really hit into "real stuff".

How to search CookieBomb v2

#MalwareMustDie!

Posted by unixfreaxjp at