Re: debian wheezy i386 nginx iframe rootkit
I am glad some one asked if the browser is running on the server; I had
that thought too. The problem could be something in between the actual
client and the server. Additionally, this could be done without using
any "malicious software", like a rootkit. Legitimate software could be
configured to create this issue. Perhaps your client or server has a
IPTables rule that is manipulating the flow of traffic.
You need to look into this from different perspectives. Capture some
network traffic, preferably from a tap/span. Then repeat the browsing as
you did before. You should also do a full portscan of both systems. You
may find an extra, unwanted service running that is not shown in
lsof/netstat, etc...
Try to rule out the network and client.
Perhaps boot a laptop from a live CD, and have it connected to the
server via crossover cable, (start TCPDump on the laptop) and repeat the
browsing just as before.
You have a legitimate issue, you just need to continuously eliminate
various possibilities.
Also, how did you uninstall the other nginx? Doesn't apt/dpkg leave
various files around that were install by a package when removing that
package? Like data/conf files? For instance, when they have been
modified from what was provided in the .deb? Do you have the other
nginx .deb still on disk?
On Thu, 2013-09-12 at 09:57 -0700, E Frank Ball III wrote:
> On Thu, Sep 12, 2013 at 07:15:57PM +0900, Joel Rees wrote:
> >
> > > The lynx webrowser shows this as the first line of the webpages:
> >
> > Local on the machine in question or external?
>
> 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.
>
> External. I figure firefox and chrome discard the new line, since it's
> not appropriate before the doctype.
>
>
> > > It only appears on IPv4, not IPv6.
> >
> > Again, are the browsers local to the machine in question or accessing
> > from the network?
>
> External.
>
>
> > 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.
>
> Yes. The same as the rootkit in 64-bit squeeze last year.
>
>
> > 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 Reese
>
>
> This is a KVM virtual machine in a datacenter. No BIOS. I can wait a
> few days to rebuild. It's off right now, I'm not going to trust it for
> anything.
>
>
> E Frank Ball frankb@efball.com
>
>
Reply to: