full-disclosure - Re: linux rootkit in combination with nginx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 26 Nov 2012 11:04:25 +0100
From: dxp <dxp2532@...il.com>
To: stack trace <stacktrace44@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: linux rootkit in combination with nginx

Looks like a new rootkit according to Kaspersky [1] and some analysis
released by CrowdStrike [2].

[1]
https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections
[2]
http://blog.crowdstrike.com/2012/11/http-iframe-injecting-linux-rootkit.html

PS: Interesting to know if others found this on their servers or is this an
isolated incident !?


On Tue, Nov 13, 2012 at 10:19 AM, stack trace <stacktrace44@...il.com>wrote:

> Hi there,
>
> We've discovered something which looks to us like a rootkit working
> together with proxy software like nginx. Our OS is debian squeeze and nginx
> 1.2.3.
>
> Here is what happened:
>
> We are running a web service and we got notified by some customers of us
> that they are getting redirected to some malicious sites. Somehow a hacker
> managed to inject an iframe into our http responses.
>
> I tried to do a telnet test on our nginx proxy and saw that even the "bad
> request" response which gets served directly from nginx contained the
> malicious iframe code.
>
> server {
>     listen          80 default backlog=2048;
>     listen          443 default backlog=2048 ssl;
>     server_name     _;
>     access_log      off;
>     (...)
>     location / {
>         return  400;
>     }
> }
>
> Doing a bad request nginx doesn't go to cache in this case - the "return
> 400" makes nginx reply with a predefined response (a string in memory).
>
> Even this response contained an iframe like this:
> HTTP/1.1 400 Bad Request
> Server: nginx/1.2.3
> Date: Wed, 07 Nov 2012 00:01:24 GMT
> Content-Type: text/html
> Content-Length: 353
> Connection: close
>
> <html>
> <head><title>400 Bad Request</title></head>
> <body bgcolor="white"><style><iframe src="http://malware-site/index.php
> "></iframe></div>
> <center><h1>400 Bad Request</h1></center>
> <hr><center>nginx/1.2.3</center>
>
> We've done an strace on the running nginx process and discovered that the
> reply of the process actually didn't contain the malicious iframe.
>
> writev(3, [{"HTTP/1.1 400 Bad Request\r\nServer"..., 151},
> {"<html>\r\n<head><title>400 Bad Req"..., 120},
> {"<hr><center>nginx/1.2.4</center>"..., 52}], 3) = 323
>
> After a bit deeper digging we've found some kernel rootkit I've attached
> to this email and also some hidden processes were running on our proxy
> machine with names like write_startup_c and get_http_inj_fr (which sounds
> like what happened to us).
>
> Is this a known attack / rootkit etc or did we discover something new?
>
> Cheers,
> -stacktrace
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



-- 
dxp

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/