You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Tom H <to...@limepepper.co.uk> on 2012/04/12 04:40:45 UTC

tomcat manager with weak password compromised. Any idea about the payload?

Hi,

An instance running tomcat 6.0.24 as root in our developer network was 
compromised today by a scanning bot which deployed a war file and then 
deleted the on disk file, before scanning for new hosts until the IDS 
detected it.

Obviously this is not a flaw in tomcat, but I was hoping someone could 
give me some pointers to where I might read a write-up of the payload, 
as I would be interested to know to what extent the bot took advantage 
of its root power.

The proc with all the connections was actually perl, and runnings 
strings on a core  dump of that process reveals many perl stuff. (and 
also the very weak password list)

However googling these facts does not seem to be helping that much, any 
suggestions?

Thanks
Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: tomcat manager with weak password compromised. Any idea about the payload?

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom,

On 4/11/12 10:40 PM, Tom H wrote:
> An instance running tomcat 6.0.24 as root

Obviously, you won't make that mistake again.

Was the manager app available to non-localhost clients?

> in our developer network was compromised today by a scanning bot 
> which deployed a war file and then deleted the on disk file,
> before scanning for new hosts until the IDS detected it.

:(

> Obviously this is not a flaw in tomcat, but I was hoping someone
> could give me some pointers to where I might read a write-up of the
> payload, as I would be interested to know to what extent the bot
> took advantage of its root power.

Are you looking for a copy of the uploaded WAR file? If it was
deleted, then your only option is to track-down the deleted inode and
snoop the bits on the disk. I don't believe the manager performs any
auditing of the uploaded WAR files.

> The proc with all the connections was actually perl, and runnings 
> strings on a core  dump of that process reveals many perl stuff.
> (and also the very weak password list)
> 
> However googling these facts does not seem to be helping that much,
> any suggestions?

So you have the Perl script itself? Or, it's still running but not
available on the disk? Perl compiles scripts as it runs them, so you
may not be able to get the full-text of the script without some kind
of Perl-oriented forensic decompilation tool.

Sorry you got pwned. If you discover anything about the bot, let us
know. Maybe there's something we can do to help thwart future attacks
(though not running as root and not allowing non-localhost connections
are certainly reasonable things that can already be done).

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk+HAnkACgkQ9CaO5/Lv0PABfwCY4Uy7uvQn/oxV6VUAxaUmZS7a
DwCgjJg5Q/UbEqbRD9+V3GcwNQu6znc=
=183q
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org