/dev/shm/r?

[Johann Spies]

I am a bit worried that my computer have been compromised.

Rkhunter reported:

[10:35:47] Warning: Suspicious file types found in /dev:
[10:35:47]          /dev/shm/r: ASCII text
[10:35:48]   Checking for hidden files and directories       [ Warning
]
[10:35:48] Warning: Hidden directory found: /etc/.java
[10:35:48] Warning: Hidden directory found: /dev/.udev
[10:35:48] Warning: Hidden directory found: /dev/.initramfs


I think the last three lines are not problematic but in /dev/shm/r I found:

spawn /bin/bash
interact

Do I have reason to be worried?

Regards
Johann
--
Johann Spies          Telefoon: 021-808 4599
Informasietegnologie, Universiteit van Stellenbosch

     "Thou wilt show me the path of life: in thy presence
      is fulness of joy; at thy right hand there are  
      pleasures for evermore."         Psalms 16:11


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Vladislav Kurz]

On Monday 01 of June 2009, Johann Spies wrote:

> I am a bit worried that my computer have been compromised.
>
> Rkhunter reported:
>
> [10:35:47] Warning: Suspicious file types found in /dev:
> [10:35:47]          /dev/shm/r: ASCII text
> [10:35:48]   Checking for hidden files and directories       [ Warning
> ]
> [10:35:48] Warning: Hidden directory found: /etc/.java
> [10:35:48] Warning: Hidden directory found: /dev/.udev
> [10:35:48] Warning: Hidden directory found: /dev/.initramfs
>
> I think the last three lines are not problematic but in /dev/shm/r I found:
>
> spawn /bin/bash
> interact
>
> Do I have reason to be worried?

Well, this really looks suspicious. Look for unexpected processes running,
open ports, etc. Directory /dev/shm/ is world-writable like /tmp, so chances
are that the attacker did not gain root yet. But he might have shell
listening on some port and trying hard to get root using some local exploit.

--
Regards
        Vladislav Kurz


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Stone-2]

On Mon, Jun 01, 2009 at 10:46:54AM +0200, Johann Spies wrote:
>I am a bit worried that my computer have been compromised.
...
>I think the last three lines are not problematic but in /dev/shm/r I found:
>
>spawn /bin/bash
>interact
>
>Do I have reason to be worried?

Yes, that's a typical location for intruders to drop files. Easiest
thing to do is reinstall after thinking about how the compromise may
have occurred. (Did you update regularly, including kernel updates? Did
all accounts have strong passwords? Do you have web applications not
managed by the system that weren't being updated? etc.)

Mike Stone


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Marcin Owsiany]

On Mon, Jun 01, 2009 at 12:26:49PM +0200, Vladislav Kurz wrote:
> On Monday 01 of June 2009, Johann Spies wrote:
> > spawn /bin/bash
> > interact

Note that this seems to be a simple "expect(1)" script which runs a
shell. Not necessarily an indication of anything apart from a possible
attacker trying to exploit something using expect.

--
Marcin Owsiany <porridge@...>             http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Stone-2]

On Mon, Jun 01, 2009 at 12:31:04PM +0100, Marcin Owsiany wrote:
>Note that this seems to be a simple "expect(1)" script which runs a
>shell. Not necessarily an indication of anything apart from a possible
>attacker trying to exploit something using expect.

It's also an indication that the attacker could write to the
filesystem...

Mike Stone


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Izak Burger]

On Mon, Jun 1, 2009 at 12:26 PM, Vladislav Kurz
<vladislav.kurz@...> wrote:
> Well, this really looks suspicious. Look for unexpected processes running,
> open ports, etc. Directory /dev/shm/ is world-writable like /tmp, so chances
> are that the attacker did not gain root yet. But he might have shell
> listening on some port and trying hard to get root using some local exploit.

I agree, chances are the box hasn't been exploited just yet, but I
would be worried about just how he got that file there in the first
place. We know that directory is world writable, so it could have been
written by anything, but what? Sometimes the ownership of the file
will give it away, for example, if the file is owned by www-data, you
know some exploit in apache (usually php!) was used to gain file
system access.


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Guntram Trebs]

Izak Burger schrieb:

> On Mon, Jun 1, 2009 at 12:26 PM, Vladislav Kurz
>  
> I agree, chances are the box hasn't been exploited just yet, but I
> would be worried about just how he got that file there in the first
> place. We know that directory is world writable, so it could have been
> written by anything, but what? Sometimes the ownership of the file
> will give it away, for example, if the file is owned by www-data, you
> know some exploit in apache (usually php!) was used to gain file
> system access.
>  

Yes, chances are, that it's just some unsecure script in a webspace. Not
good, but if you are a webservice provider, you always have some special
customer.
I even know companies which buy a cms and don't think of who cares for
it over the time as long as it's running ...

On the other hand, you should keep in mind, that it could be someone who
has gained root provileges and hides some of his activities. If he is
root, then there has to be some other traces left of him.

So you should collect other information:
 - lsof and /proc, if you find suspicious processes
 - intrusion detection software
 - logfile scanning software and manual examining log files including
firewall logs

Good point is, when you can trace times of activity. But always keep in
mind, that the information could be wrong.

--
Guntram Trebs
freier Programmierer und Administrator

gt@...
[phone]
[phone]



--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Johann Spies]

On Mon, Jun 01, 2009 at 07:23:27AM -0400, Michael Stone wrote:

> Yes, that's a typical location for intruders to drop files. Easiest  
> thing to do is reinstall after thinking about how the compromise may  
> have occurred. (Did you update regularly, including kernel updates? Did  
> all accounts have strong passwords? Do you have web applications not  
> managed by the system that weren't being updated? etc.)

We had a serious situation on this computer and several others. Ssh
and sshd were replaced by the cracker's own version and in once case
nearly all the pam-related stuff were replaced also.  Through this
customised versions of ssh the cracker harvested every password that
was used during ssh logins and ssh sessions.

We are winning the battle and will in the next few weeks try do the
analysis of what went wrong.

Regards
Johann
--
Johann Spies          Telefoon: 021-808 4599
Informasietegnologie, Universiteit van Stellenbosch

     "Thou wilt show me the path of life: in thy presence
      is fulness of joy; at thy right hand there are  
      pleasures for evermore."         Psalms 16:11


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Wade Richards]

Although it's worse if an attacker has root, don't think that just because
the attacker doesn't have root, it's no big deal.  If an attacker can run
(even as an ordinary user) unauthorized software on your machine, then
your machine may be part of a botnet.  And having unauthorized user access
to a machine leaves the door open for trojan horse type programs which may
give the user root access.  Finally, depending on the user account which
is compromised, the attacker may already have access to sensitive data.

Don't obsess on root access.  Any unauthorized use is a problem.

     --- Wade

On Tue, June 2, 2009 00:35, Guntram Trebs wrote:

> Izak Burger schrieb:
>> On Mon, Jun 1, 2009 at 12:26 PM, Vladislav Kurz
>>
>> I agree, chances are the box hasn't been exploited just yet, but I
>> would be worried about just how he got that file there in the first
>> place. We know that directory is world writable, so it could have been
>> written by anything, but what? Sometimes the ownership of the file
>> will give it away, for example, if the file is owned by www-data, you
>> know some exploit in apache (usually php!) was used to gain file
>> system access.
>>
> Yes, chances are, that it's just some unsecure script in a webspace. Not
> good, but if you are a webservice provider, you always have some special
> customer.
> I even know companies which buy a cms and don't think of who cares for
> it over the time as long as it's running ...
>
> On the other hand, you should keep in mind, that it could be someone who
> has gained root provileges and hides some of his activities. If he is
> root, then there has to be some other traces left of him.
>
> So you should collect other information:
>  - lsof and /proc, if you find suspicious processes
>  - intrusion detection software
>  - logfile scanning software and manual examining log files including
> firewall logs
>
> Good point is, when you can trace times of activity. But always keep in
> mind, that the information could be wrong.
>
> --
> Guntram Trebs
> freier Programmierer und Administrator
>
> gt@...
> [phone]
> [phone]
>
>
>
> --
> To UNSUBSCRIBE, email to debian-security-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@...
>
>
>

--
Wade Richards  (wade@...)



--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Izak Burger]

On Tue, Jun 2, 2009 at 6:42 PM, Wade Richards <wade@...> wrote:
> Don't obsess on root access.  Any unauthorized use is a problem.

You are right of course. Right after I sent my message saying that
"perhaps the machine hasn't been exploited yet" I realised how wrong
such a view is. Someone gained access to an area they should not have
access to, it has been exploited already.

I have been fortunate enough to only be in this situation twice in the
last ten years. The first time was due to a weak password, and luckily
our attacker only installed an irc bouncer (renamed to "bash" so it
wouldn't stand out in a process listing). We could literally get away
with not reinstalling the entire machine, because the damage was
limited to one user account (yes, we did check for replaced binaries
:-) ).

The second time was caused by a php hosting control panel, which gave
the attackers (Turkish crackers unhappy with that Danish cartoon) the
ability to create ftp accounts and deface websites. Once again, the
damage was limited and we got away without a full reinstall. It was in
this sense that I hoped Johann (a former colleague of mine) might be
lucky enough to get away with limited damage.

Wait, there was a third time. On a CentOS box, I found a core file in
/etc/cron.d. I immediately realised what it was as I had an argument
about which kernel versions is affected with someone just the previous
week (thread here:
http://lists.clug.org.za/pipermail/clug-tech/2006-July/032952.html).
In this case, we eventually found that a former employee of the
organisation tried several exploits on the machine and left some
tell-tale signs behind. In this instance, though it seemed none of the
exploits succeeded, we decided to trash the CentOS install and move to
Debian :-)

In any case, enough about me. Good luck Johann, and I look forward to
more information on exactly what happened here.

regards,
Izak


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Guntram Trebs]

Hello,

there are few chances of replacing sshd without being root. In your
place i would install every server new.

I think, he spied out passwords and maybe got root-Passwords in this
way. Possibly he has even accessed servers where you didn't find him and
left backdoors there. (manipulation of ~/.ssh/authorized_keys, another
user with userid 0, replaced software, replaced suid-accesses, added
software, ...)

When you reinstall your servers think of not using Login+Password but
public-private key for user authentication.
You can even forward such a combination. But be aware, that if key
forwarding is enabled it can be used by attackers too.
You should then protect the private key by password and use it only from
trusted machines.
Avoid keyforwarding unless you need it, for instance when copying files
from one server to the other it could be useful.
Lock your trusted working computer always when leaving it and think of
encrypting the filesystem. (Be aware that a local attacker can install a
password sniffer even if you encrypted your system partition)

good luck and think of not accessing the new installed computers from
old ones ...
Regards,
Guntram

Johann Spies schrieb:

> On Mon, Jun 01, 2009 at 07:23:27AM -0400, Michael Stone wrote:
>
>  
>> Yes, that's a typical location for intruders to drop files. Easiest  
>> thing to do is reinstall after thinking about how the compromise may  
>> have occurred. (Did you update regularly, including kernel updates? Did  
>> all accounts have strong passwords? Do you have web applications not  
>> managed by the system that weren't being updated? etc.)
>>    
>
> We had a serious situation on this computer and several others. Ssh
> and sshd were replaced by the cracker's own version and in once case
> nearly all the pam-related stuff were replaced also.  Through this
> customised versions of ssh the cracker harvested every password that
> was used during ssh logins and ssh sessions.
>
> We are winning the battle and will in the next few weeks try do the
> analysis of what went wrong.
>
> Regards
> Johann
>  

--
Guntram Trebs
freier Programmierer und Administrator

gt@...
[phone]
[phone]



--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josh Lauricha-2]

I'm surprised more people aren't running tripwire or other IDS.

On Tue, Jun 2, 2009 at 1:37 PM, Guntram Trebs <gt@...> wrote:

> Hello,
>
> there are few chances of replacing sshd without being root. In your place i
> would install every server new.
>
> I think, he spied out passwords and maybe got root-Passwords in this way.
> Possibly he has even accessed servers where you didn't find him and left
> backdoors there. (manipulation of ~/.ssh/authorized_keys, another user with
> userid 0, replaced software, replaced suid-accesses, added software, ...)
>
> When you reinstall your servers think of not using Login+Password but
> public-private key for user authentication.
> You can even forward such a combination. But be aware, that if key
> forwarding is enabled it can be used by attackers too.
> You should then protect the private key by password and use it only from
> trusted machines.
> Avoid keyforwarding unless you need it, for instance when copying files from
> one server to the other it could be useful.
> Lock your trusted working computer always when leaving it and think of
> encrypting the filesystem. (Be aware that a local attacker can install a
> password sniffer even if you encrypted your system partition)
>
> good luck and think of not accessing the new installed computers from old
> ones ...
> Regards,
> Guntram
>
> Johann Spies schrieb:
>>
>> On Mon, Jun 01, 2009 at 07:23:27AM -0400, Michael Stone wrote:
>>
>>
>>>
>>> Yes, that's a typical location for intruders to drop files. Easiest
>>>  thing to do is reinstall after thinking about how the compromise may  have
>>> occurred. (Did you update regularly, including kernel updates? Did  all
>>> accounts have strong passwords? Do you have web applications not  managed by
>>> the system that weren't being updated? etc.)
>>>
>>
>> We had a serious situation on this computer and several others. Ssh
>> and sshd were replaced by the cracker's own version and in once case
>> nearly all the pam-related stuff were replaced also.  Through this
>> customised versions of ssh the cracker harvested every password that
>> was used during ssh logins and ssh sessions.
>>
>> We are winning the battle and will in the next few weeks try do the
>> analysis of what went wrong.
>>
>> Regards
>> Johann
>>
>
>
> --
> Guntram Trebs
> freier Programmierer und Administrator
>
> gt@...
> [phone]
> [phone]
>
>
> --
> To UNSUBSCRIBE, email to debian-security-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@...
>
>

--
Josh Lauricha


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...