This looks terrible.. anyone have any ideas? Mar 30 20:45:00 rox /USR/SBIN/CRON[16114]: (root) CMD ( test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons ) Mar 30 20:46:14 rox ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P Mar 30 20:46:55 rox named[380]: Cleaned cache of 57 RRsets I've got sendmail, web, named, and identd open to the world.. and pop3, ftp, ssh open to accepted ip ranges (via IPCHAINS) Please help..this sucks. Chrissy
On Fri, 31 Mar 2000, Chrissy wrote:
This looks terrible.. anyone have any ideas?
Mar 30 20:45:00 rox /USR/SBIN/CRON[16114]: (root) CMD ( test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons ) Mar 30 20:46:14 rox ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P <snip> Mar 30 20:46:55 rox named[380]: Cleaned cache of 57 RRsets
I've got sendmail, web, named, and identd open to the world.. and pop3, ftp, ssh open to accepted ip ranges (via IPCHAINS)
Please help..this sucks.
Looks like a named buffer overflow exploit. What version of named are you using? -- Bob F EMail FBob@wt.net A Truly Wise Man Never Plays Leapfrog With A Unicorn...
chrissy@rox:~ > /usr/sbin/named -v named 8.2.2-P3 Sun Nov 14 20:46:41 GMT 1999 root@snell:/usr/src/packages/BUILD/bind8-8.2.2/bin/named chrissy@rox:~ > rpm -qa |grep bind bindutil-8.2.2-8 bind8-8.2.2-8 I opened exec (512) to test X-Win32 ..so that was open too...but behind ipchains. While doing a portscan..i noticed a weird port.. 687 ..any clues? an rpm -Va showed nothing odd... Thanks much, Chrissy
Looks like a named buffer overflow exploit. What version of named are you using? -- Bob F
EMail FBob@wt.net
On Fri, 31 Mar 2000, Chrissy wrote:
chrissy@rox:~ > /usr/sbin/named -v named 8.2.2-P3 Sun Nov 14 20:46:41 GMT 1999 root@snell:/usr/src/packages/BUILD/bind8-8.2.2/bin/named
chrissy@rox:~ > rpm -qa |grep bind bindutil-8.2.2-8 bind8-8.2.2-8
I opened exec (512) to test X-Win32 ..so that was open too...but behind ipchains.
While doing a portscan..i noticed a weird port.. 687 ..any clues?
an rpm -Va showed nothing odd...
Thanks much, Chrissy
Looks like a named buffer overflow exploit. What version of named are you using? -- Bob F I am not up on this particular exploit. I would investigate the bugtraq thread I sent you off list. From what I have read I think 8.2.2-P3 is OK but I would check further- I may have missed something. Port 687 does not ring any bells but does sound suspicious. I would operate under the assumption that the box has been compromised until you can prove otherwise (just my opinion)
Good Luck! -- Bob F EMail FBob@wt.net A Truly Wise Man Never Plays Leapfrog With A Unicorn...
On Fri, Mar 31, 2000 at 16:22 -0800, Chrissy wrote:
chrissy@rox:~ > /usr/sbin/named -v named 8.2.2-P3 Sun Nov 14 20:46:41 GMT 1999
IIRC "-P5" is out, you might find the appropriate discussions on securityfocus.com and freebsd.org. But since I don't run any _public_ DNS servers I really didn't care any further.
While doing a portscan..i noticed a weird port.. 687 ..any clues?
When /etc/services doesn't reveal anything, you might want to look at nmap's services file which is more comprehensive. You can check out the links below. http://www.robertgraham.com/pubs/firewall-seen.html http://advice.networkice.com/advice/Exploits/Ports/ And always do something like "fuser -v -n tcp 687". You could run login daemons on port 80 or mail servers on port 53 -- nobody said a service had to "conform" to an /etc/services entry, these are just hints or symbolic names for pure comfort.
an rpm -Va showed nothing odd...
I'm not sure at the moment whether this would show any _added_ files. I guess it only checks for manipulation of initially installed files (entered into the rpm database). And did you check all the modifications not only for reasonability but for their _full_ change against the initial state? You can expect to have /etc/inittab look different from the installation time, but did you look _what_ is the difference? And while we're at this: which database did you check against? There's no point in believing in ls(1), lsmod(8) or rpm(1) on a broken system. Grab an unmodified version to check with (rescue system from CD, frozen rpm database right after installation, etc). Setup an IDS like tripwire which comes with most distros these days. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
* Gerhard Sittig wrote on Sat, Apr 01, 2000 at 11:42 +0200:
On Fri, Mar 31, 2000 at 16:22 -0800, Chrissy wrote:
While doing a portscan..i noticed a weird port.. 687 ..any clues?
When /etc/services doesn't reveal anything, you might want to look at nmap's services file which is more comprehensive.
In my services.nmap isn't an entry for 687.
And always do something like "fuser -v -n tcp 687".
Yepp, then you could strace -f -p <the pid>, and do a telnet localhost 687 and see what this process is doing.
You could run login daemons on port 80 or mail servers on port 53
Or a bash directly attached without login functions...
I'm not sure at the moment whether this would show any _added_ files.
Well, I think this wouldn't be possible, or the filelist from every installed rpm had to be compared with the filelist taken from the system.
And while we're at this: which database did you check against? There's no point in believing in ls(1), lsmod(8) or rpm(1) on a broken system.
Or even the kernel. To go for sure you have to *boot* from a CD or so, to get a "clean" system. Maybe rpm, tripwire and hashtools (i.e.: md5sum) are exchanged by the possible attack.
Setup an IDS like tripwire which comes with most distros these days.
Yepp, and don't forget to keep the database on a different locacation (i.e. floppy disk/zip/cd). But maybe your system wasn't compromized at any time, who knows. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (4)
-
BobF -
Chrissy -
Gerhard Sittig -
Steffen Dettmer