|
Author
|
Topic: Tomcat security issues?
|
Jimbo
1 dr3w j00 4 p1ggy!
|
posted 08-28-2001 18:25
   
Best I could find on short notice:Date Reported: 7/19/00
Vulnerability: tomcat-error-path-reveal
Platforms Affected: Jakarta Tomcat
Risk Factor: Low
Attack Type: Network/Host Based Jakarta Tomcat reveals sensitive path information. Jakarta Tomcat is a Java
application server used with Apache web servers to support Java Servlet Pages
(JSP) and Java servlets. When a user requests the URL of a filename that is not
found, the program returns an error message that provides the physical path to
the web directory that was contained in the request. An attacker could use this
to gain information about the file structure of the web server that would be
helpful in an attack. Reference:
BugTraq Mailing List, Wed, 19 Jul 2000 06:45:13: "[LoWNOISE] Tomcat 3.1 Path
Revealing Problem." at: http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist%3D1%26date%3D2000-07-15%26msg%3DPine.SUN.3.96.1000719184401.17782A-100000@grex.cyberspace.org Top of Page | | Back to Alert List
____
Date Reported: 7/19/00
Vulnerability: tomcat-snoop-info
Platforms Affected: Jakarta Tomcat
Risk Factor: Low
Attack Type: Network/Host Based
Jakarta Tomcat snoop servlet reveals sensitive information about the web
server. Jakarta Tomcat is a Java application server used with Apache web
servers to support Java Servlet Pages (JSP) and Java servlets. When a user
requests the snoop servlet, the program returns detailed information about the
web server, including the physical path to the web directory and the web server
operating system and software version. An attacker could use this to gain
information about the web server that would be helpful in an attack. Reference:
BugTraq Mailing List, Wed Jul 19 2000 11:56:21: "[LoWNOISE] Snoop Servlet
(Tomcat 3.1 and 3.0)" at: http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist%3D1%26date%3D2000-07-15%26msg%3DPine.SUN.3.96.1000719235404.24004A-100000@grex.cyberspace.org Top of Page | | Back to Alert List Not exactly "backdoors", but it could be revealing information needed to hack to a more specific goal...? Really, it would help if we knew more about the problem. Why do you think you've been compromised? Why with a backdoor? Why do you think it's in Tomcat? What are the symptoms? IP: Logged |
Jimbo
1 dr3w j00 4 p1ggy!
|
posted 08-28-2001 18:32
Okay, this is an any-OS problem with Tomcat that's apparently been corrected in later releases than your 3.1:
http://www.qualys.com/demo/fo_2.9/news_display-9.htm It appears to be a read-only type of exploit though - lets you steal Java source code, but I'm not sure what good that would do you to get r00t...? IP: Logged |
Jimbo
1 dr3w j00 4 p1ggy!
|
posted 08-28-2001 18:35
Ooooh... quote:
Description: A cross-site scripting vulnerability has been reported in the Tomcat Java server that allows remote users create specially crafted URLs that will cause Javascript to be executed by other users.
http://www.securitytracker.com/alerts/2001/Jul/1001906.html (hey Fen, I'm starting to think that Tomcat really SUCKS.  ) IP: Logged |
Jimbo
1 dr3w j00 4 p1ggy!
|
posted 08-28-2001 18:41
quote:
The Tomcat package, from the Apache Software Foundation, contains a vulnerability that could cause the disclosure of information that could lead to the compromise of the machine running Tomcat. By default, Tomcat contains a mounted context, /admin, that contains servlets that can be used to add and delete contexts, or view context information on the Tomcat server. By adding the root directory (/) as a context, it is possible to view files readable by the account Tomcat is running as. If Tomcat is running as root, all files on the filesystem may be accessed. This can in turn lead to the retrieval of vital information that may be used to gain access to the machine. There is no access control present to prevent unauthorized access to the /admin context. As such, any remote user can potentially exploit this vulnerability.
(got r00t?) IP: Logged |
Jimbo
1 dr3w j00 4 p1ggy!
|
posted 08-28-2001 18:42
More: (finally found a fairly comprehensive list of potential security vulnerabilities in one place)[edit] dammit, it's entirely active and dependent on data passed using GET instead of POST ==> no linkie. Go to www.securityfocus.com, click on "Vulnerabilities", and search on vendor "Apache Group." [This message has been edited by Jimbo (edited 08-28-2001).] IP: Logged |
fenomas
argument nazi
|
posted 08-28-2001 18:53
Jimbo, you're on the ball as always.Unfortunately (i tried not to give too much info on the front page because in case someone I work with reads it) the implication is that this backdoor would be something put in by the guy who did the original tomcat/jsp development for the site in question. Of course, he was root at the time, so he could have done virtually anything... But I'll start with your links. Thanks.. IP: Logged |
fenomas
argument nazi
|
posted 08-28-2001 20:43
hurm. None of these sploits seems to work on the server in question. The most likely one seems to be the one about /admin contexts, but I'll need to study tomcat more before I understand it.
Any way I could log the command history of root without someone else noticing?IP: Logged |
Jimbo
1 dr3w j00 4 p1ggy!
|
posted 08-28-2001 21:03
Oh oh oh, that kinda backdoor... I get it. Jeeze... that's a whole 'nother kettle of fish entirely!Check the password files, and definitely definitely definitely check that admin context vulnerability. Unless you've redefined or removed those admin contexts, you ARE vulnerable to that exploit. As far as logging all root command history... um, over my head man. I'm an NT geek. IP: Logged |
fenomas
argument nazi
|
posted 08-28-2001 22:35
Jesus, why is there no web page that lists standard checksums for default installs of various *ix distro/versions??Wouldn't that make sense? Rather than a million sites advising to make a db of checksums before I suspect a compromise? fen IP: Logged |
marcel
Member with a member bigger than the member with a member
|
posted 08-29-2001 06:25
quote:
Originally posted by fenomas:
Any way I could log the command history of root without someone else noticing?
quick and dirty for ksh: Set HISTORY in root's .login or .kshrc. OR set it in /etc/profile.
copy $HOME/.sh_history to remote location
and create a skulker for command audit. IP: Logged |
Maid Marion
unregistered
|
posted 08-29-2001 09:31
Hey guys-DevShed has a new tutorial on security tuning your Tomcat installation.... Helped me lock down my server... http://www.devshed.com/jsp/tomcat/articles.php?art=179 Hope that helps. MM IP: Logged |
marcel
Member with a member bigger than the member with a member
|
posted 08-29-2001 09:37
Don't click on the above link.
Same asshole.IP: Logged |
Jimbo
1 dr3w j00 4 p1ggy!
|
posted 08-29-2001 19:46
Marcel, man... I think you're the only one here that doesn't reflexively check links from unknowns already. We're onto it, man. ::chuckles::Honestly, you'd think these fuckedcompany trolls thought they found the fucking Martha Stewart forum or something. Kiddies, can't you come up with anything better than goatse.cx and broken links to shit at rotten.com? Please. Show some fucking originality. K THX BBL! IP: Logged |
kor is my middle name
Neophyte Pen
|
posted 08-29-2001 20:36
Tomcat is a great platform to develop with, but for production it isn't going to cut it.First, it is just plain slow. Second is that its memory usage is just wacked -- there are weird memory spikes. IP: Logged |
weis
bonzi buddy
|
posted 08-30-2001 00:39
Tomcat's cool! And it's a young app. Anyway, Fen, did you say this was Redhat 6.1 or 6.2 right? So, vulnerable to BIND? If you think you may already be breached, is dropping and reinstalling an option? Probly not if the server's in development. Can you place a date on the suspect activity, and if so, do you have backups? Can you guarantee the other boxes on the network aren't fuxxored too? A couple of nonspecific ideas: you might check out tripwire to help with this sort of thing in the future. You might get in the habit of checking the network activity (from a different box, I mean) and grepping for whatever seems relevant for a few days. You might scan for files that are increasing in size at a steady rate: if the box is compromised but nothing untoward has happened, the r00t0r is probably logging network traffic somewhere. If said hacker has a good rootkit, you can expect to find nothing in the logs and to not see his presence on "who" and similar commands. You can also expect trojans in common commands (ls, su, etc). Basically, the better the rootkit the more the pain in the ass, which is why I suggest dropping the box if that's feasible. If not, you're more likely to find the evildoer by watching the firewall for a succession connections from different hacked AOL accounts or something, than you are by investigating the box. If it's really rooted well you may have to write it off.------------------
With proper thrust, pigs fly just fine.
--RFC 1925 IP: Logged |
fenomas
argument nazi
|
posted 08-30-2001 02:31
Well, ya know I didn't choose this tomcat business. Javascript, I code. Java, I'm effin lost.Anyway, weis:
I was thinking rootkits too, but I found md5 checksums for bin/ls, bin/ps and a few more somewhere for RH 6.2, and they matched. So I don't think it's kitted. (on the other hand, rpm showed a lot of modules where the 5 flag (the checksum) was tripped, but I don't know enough about the rpm command to know if that's normal for a server in use for some time. It's a complicated story that I hope to tell when I sort it out, but if the box is really comp'd, then it would have been done ages ago, by the guy who was deving the jsp stuff. He also set up the servers, from installing RH onwards, so there's not much limit to what he could have done.
However, there's another possibility that the person who said this vulnerability existed may have been talking out his ass to put pressure on us. We'll find out. Probably one of the two guys (the guy who said it, or the guy who did it) is gonna get a reaming.
So I thought he might have simply left a tomcat vulnerability open, but the /Admin vulnerability doc'ed above seems to be closed. So the only possibility left is that he wrote a backdoor into the code of the jsp apps themselves. I don't really know enough about how they work (and there's a load of them) to look for this one, so I'm kind of stuck probably. He was a developer, but security minded enough to know about kits and so on. On the other hand, some boxes were compromised some months ago by that Chinese Honkers Union (hee hee), so we should prolly be doing more with tripwire or samhain or something. I spose. I took kind of a crash course in this yesterday. Whaddya think? btw, this is a live web server for our biggest client, in use for about two years. fen IP: Logged |
marcel
Member with a member bigger than the member with a member
|
posted 08-30-2001 03:56
quote:
Originally posted by Jimbo:
Marcel, man... I think you're the only one here that doesn't reflexively check links from unknowns already. We're onto it, man. ::chuckles::
Yep. 'Tis true.
Standard viewing procedures have been changed accordingly. IP: Logged |
UBBFriend: Email This Page to Someone!
PenIs Forum
