..And another "detonating" method (or effort) of today's CookieBomb

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. 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]

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.

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.

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:

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 :-))

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.

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 this 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.

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) is there and serving.

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.

#MalwareMustDie!