full-disclosure - Re: one of my servers has been compromized

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: Tue, 6 Dec 2011 01:42:24 -0800
From: Gage Bystrom <themadichib0d@...il.com>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: one of my servers has been compromized

Ahh I see. Then yeah I would advise using iptables to deny as much outgoing
traffic as possible and set up the chain so that all attempted traffic
statistics get logged. Back that up with denying as much incoming traffic
as possible. Then monitor for any spawning services with netstat.

Assuming no rootkit was involved(and I explained how unlikely that'd be),
then any incoming connection to seize back the box via a backdoor would
rely on a process spawning a daemon which will be caught. Any connect back
backdoor will not only be stopped immediately but since you can hone in via
the logged statistics you can know what remote port its looking for. Then
you simply watch netstat for outgoing connections to said port and you got
em.

The 'tricky' part is if they have some sort of ssh based access. Contrary
to some previous suggestions locking down bash and logging users is neigh
useless if the attacker has remotely browsed the man pages for the
client(here's a hint, you don't need to 'login' to get a shell as long as
you don't mind not having a tty). Instead the remedy is fairly simple.
Reinstall ssh(preferably from source) and then change every user password.
If the daemon was changed, its now safe. If a password was compromised its
now useless.

No matter how you look at it, if no kernel rootkit was in place then any
backdoor becomes fudged. From there its a simple matter of wiping /tmp of
any code scripts and then dealing with the matter of the vulnerable web
pages.

Cause yes, even unusual side channels relying on icmp or dns queries become
useless. Iptables will still record the unusual jump in stats for those and
they've just handed you and potential authorities either their home box(if
they're morons), or revealed another compromised server. Which means its a
win win even if they tried a 'clever' trick like that.

Set the right options, plug the holes, and relish in the fact they weren't
serious about your box and you will be just find.
On Dec 6, 2011 1:18 AM, "Lucio Crusca" <lucio@...web.org> wrote:

> Gage Bystrom wrote:
> > I would suggest iptables but the OP stated he doesn't own the
> > server and has no root access.
>
> If I ever stated that, it means I misused my poor english for sure... I DO
> have root access and I DO own the server, where the server means the
> *guest*
> OpenVZ instance. I DID configure iptables yesterday in order to block
> outgoing connections. What I can't do is upgrading the kernel because
> OpenVZ
> is a limited "paravirtualization" system where the guest kernel it's more
> like a stub on top of the only shared host kernel. I have no control over
> the host kernel, so I can't upgrade it.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

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/