Full Disclosure mailing list archives

Previous By Date Next
Previous By Thread Next

Re: linux rootkit in combination with nginx

From: Jeffrey Walton <noloader () gmail com>
Date: Tue, 27 Nov 2012 12:50:50 -0500
On Tue, Nov 27, 2012 at 10:41 AM, Gregor S. <rc46fi () googlemail com> wrote:

More interesting than the rootkit itself is how it found it's way into the
box.

Chances are that Squeeze has a non-disclosed 0day, and that's worring me a
bit...

Its based on Linux, so there are probably a lot of non-disclosed 0-days.

Folks like Dan Rosenberg have made a career out of finding Comp Sci
101 bugs because some of the developers are too l33t to use tools and
analysis to find their mistakes. The OS's namesake is too arrogant for
his own good (cf., "GCC is crap",
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-11/msg08325.html).

Jeff


On Mon, Nov 26, 2012 at 11:04 AM, dxp <dxp2532 () gmail com> wrote:


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 () gmail 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?


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

Current thread: