A long time ago, in a galaxy far, far way, someone said... > Hi gang, > > Like all good (or at least passably competent) systems administrators, I > use logcheck to mail me anything out of the ordinary that turns up in my > logs each night. Last night, I found something that I can only guess is > a buffer overflow attempt. Here is the relevant part of the log (note > that the plusses come from mutt's wrapping of the line): > > Aug 26 19:28:01 callisto > Aug 26 19:28:01 callisto syslogd: Cannot glue message parts together > Aug 26 19:28:01 callisto 173>Aug 26 19:28:01 /sbin/rpc.statd[282]: > gethostbyname > +error for > +^X???^X???^Y???^Y???^Z???^Z???^[???^[???%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x > +%n%10x%n%192x%n???????????????????????????????????????????????????????????????? > +??????????????????????????????????????????????????????????????????????????????? > +??????????????????????????????????????????????????????????????????????????????? > +??????????????????????????????????????????????????????????????????????????????? > +??????????????????????????????????????????????????????????????????????????????? > +??????????????????????????????????????????????????????????????????????????????? > +??????????????????????????????????????????????????????????????????????????????? > +??????????????????????????????????????????????????????????????????????????????? > +???????????????????????????????????????????????????????????????????????????????+??????????????????????????????????????????????????????????????????????????????? > +??????????????????????????????????????????????????????????????????????????????? > +?????1??|Y?A^P?A^H???A^D?????^A?f???^B?Y^L?A^N??A^H^P?I^D?A^D^L?^A?f???^D?f???^ > +E0??A^D?f? > Aug 26 19:28:01 callisto > ?^F/bin?F^D/shA0??F^G?v^L?V^P?N^L???^K???^A???^???? > Aug 26 19:28:03 callisto > > This happened twice last night, and also a few days previously. > > Is this likely to be an attack attempt or is something just > misconfigured somewhere? Snort didn't pick up anything, but it might be > something that is newer than my snort rules. The fact that there is a > /bin/sh in amongst the garbage suggests to me that it's an attempted > buffer overflow.
This is likely a buffer overflow attempt - there are known vulnerabilities in rpc.statd that are actively being exploited. You know it's a problem when CERT issues an advisory even though the fix has been available for a while :) I think it goes without saying that if you have a server open to the 'net following bugtraq/ntbugtraq is a must. > (FWIW, I do use NFS on this machine, but somehow the `ipchains -P input > DENY' was absent from my firewall script, so I didn't have a default > DENY rule covering all the non-blocked priveleged ports. This is now > fixed.) > > I'm assuming that the machine was not compromised, because this is still > in the logs, all the relevant debsums check out, and I'm running the > latest potato, for which hopefully there is no known major security > holes. However, this may be a niave assumption on my part... If you've done a 'apt-get update; apt-get upgrade' since the middle of July or so you're safe - that's when the fix was issued for Debian potato. The fix is definitely on the "Official" potato CDs I have laying around here. > What I'm wondering is if there is any way to find out where this attempt > (if that's what it was) came from. Do you keep extensive firewall logs? They're a royal pain in the @$$ if you need to look through them (grep is your friend) but are invaluable if you need them. > There are a bunch of numbers that look like an IP at the start of the > garbage, might that be it? imo not likely - it's more likely part of the buffer overflow attack > I'm also running ippl (which I just tested, which goes nuts when I do a > stealth scan with nmap) and portsentry, and there has been no indication > recently of a portscan or anything like that. Nothing to indicate anyone > has been paying unusual attention to my network or system (this machine > is also the gateway to the network). portsentry/ippl won't necessarily catch something unless you've told them to look at the ports serviced by rpc.statd. Besides that, it's as simple as 'nmap -sS -p <portnumber> <ipnumber>' to find out if something's listening there - you don't need a full portscan you just need to look for a very small number of ports. If you happen to need a web server running, for example, port sentry really can't check for any "portscans" on that particular port. > cheers, > > damon (who hopes that his computer forensics is up to scratch and/or > that he's not just being too paranoid!) -- ---------------------------------------------------------------------- Phil Brutsche [EMAIL PROTECTED] "There are two things that are infinite; Human stupidity and the universe. And I'm not sure about the universe." - Albert Einstien
