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