Re: Breakin Attempt? Tracking source
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 pbrutsch@tux.creighton.edu
"There are two things that are infinite; Human stupidity and the
universe. And I'm not sure about the universe." - Albert Einstien
Reply to: