full-disclosure - Re: sshd logins without a source

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]

Message-ID: <CALCvwp6fSFnrSG5X5BGGbjntY5-T2F1qqdodQKL4Kvd3V3aZ4Q@mail.gmail.com>
Date: Sat, 24 Sep 2011 07:43:00 +1000
From: GloW - XD <doomxd@...il.com>
To: BH <lists@...ckhat.bz>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: sshd logins without a source

You realise there is an advanced rootkit wich 'makes' its own logs ;)

from the makers own readme:

Vihrogon Advanced SSH RootKit by Solar Eclipse
. Rootkit Requirements . ..   .
First of all, we need a magic password. When the attacker uses this
password, she should be granted access to any account. Any login
restrictions, for example restricted root logins should be turned off.
All ssh logging should also be disabled.

Unfortunately sshd logs an informational message when a connection is
received, even before the authentication begins.

Jul 30 02:52:46 hostname sshd2[1082]: connection from "3112"
Jul 30 02:52:46 hostname sshd2[1082]: DNS lookup failed for
"174.42.35.77".

If we disable all logging after the magic password is received, this
message will look very suspicious in the logs. The solution is to log
a fake disconnect message.

Jul 30 02:52:53 hostname sshd2[1082]: Local disconnected: Connection
closed by remote host.
Jul 30 02:52:53 hostname sshd2[1082]: connection lost: 'Connection closed
by remote host.'

That's good, but not good enough. If the attacker accesses the machine her
IP address will still be logged. How can we identify the attacker even
before the user authentication? Each TCP connection is identified by four
numbers: the source IP address, the destination IP address, the source port
and the destination port. The source port can be specified by the client or
it can be randomly chosen by the operation system. Let the attacker use a
predefined magic source port and the sshd daemon will be able to identify
the connection.

very clever indeed, but if taken a few steps further (this paper/rkit is now
oldish) ,
this could be used still with modifications, is one possibility... a
modified rootkit wich is making its own log . just a wild guess.
cheers
xd

On 23 September 2011 13:45, BH <lists@...ckhat.bz> wrote:

> Hi,
>
> I am taking a look at a few different servers that have been rooted at
> around the same time. At the time of the compromise I can see in each
> servers sshd logs an entry like the following:
>
> Sep 22 12:57:14 test-vm sshd[25002]: pam_unix(sshd:session): session
> opened for user root by (uid=0)
> Sep 22 12:57:32 test-vm sshd[25002]: pam_unix(sshd:session): session
> closed for user root
>
> Each of the servers has the same sort of entry in the log that match
> with the time that extra processes were being executed. Having a look at
> all other available logs (that were logged remotely) I can't see
> anything else that relates to the same event. To me it seems odd that
> there is no IP address corresponding with the login, I can't seem to
> reproduce that on my test servers. I also can't see the authentication
> method used as that isn't logged. Has anyone seen this before and know
> how this is done?
>
> Thanks
>
> _______________________________________________
> 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/