hack - installing "bi" in /tmp ??
Hi, I found a programm "bi" in /tmp - owner wwwrun, goup nobody. Nothing in the logs. 2.4.10-4GB Looks like a hack via apache. Do you know anything similar? strings bi gets the following output: /lib/ld-linux.so.2 __gmon_start__ libc.so.6 strcpy waitpid ioctl printf stdout execve memcpy perror __cxa_finalize dup2 socket select fflush bzero setpgid accept write kill bind __deregister_frame_info chdir memchr signal read htonl listen fork sprintf htons exit _IO_stdin_used __libc_start_main strlen open vhangup setsid __register_frame_info close GLIBC_2.1.3 GLIBC_2.0 äðPTRhð QVhd åSPè ]üÉà Éuê¸ }¸¾) eø^_]à Pè:ý Pèöü 0èWû åWVS EÈPè fÇEÈ u´è³ú öèKú uäèwú uäè9ù Eè-à Pètú u°è_ú E¤Pèlû ½Øwþ Pèrø u°èK÷ u°èM÷ u è!÷ u¤è¹ø u°èûö u´èíö u¤èï÷ u¤èß÷ u¤èÏ÷ u¤èeö E Áè E°Áè E ;E°~ µ¤wþ E Áè u è]÷ ½Ðwþ µÐwþ E°Áè u°èÑö ½Ðwþ µÐwþ Pè!õ ½Ôwþ ½´wþ µ´wþ µÔwþ ½´wþ u èSõ u è`ó ½´wþ µ´wþ µÐwþ µÌwþ u èùò u°èñò u´èãò u èÕò u¨è£ó u°è¥ò eô[^_]à U¡ì¦ uôX[]ÃU åSRè ]üÉà pqrstuvwxyzabcde 0123456789abcdef /dev/ptmx /dev/pty /dev/tty socket bind listen Daemon is starting... OK, pid = %d /dev/null /tmp HOME=%s Can't fork pty, bye! /bin/sh Regards, Dirk
Dirk Kutsche wrote:
Hi,
I found a programm "bi" in /tmp - owner wwwrun, goup nobody. Nothing in the logs. 2.4.10-4GB
Looks like a hack via apache. Do you know anything similar?
strings bi gets the following output:
looks like a backdoor. Check if any port is open on your box who souldn't be there. Whats about Apache? up-to-date? php? OpenSSL? all those where exploitable in the last month and your kernel looks like an default kernel from 7.3, if you update it, you should have at least 2.4.16-4GB. Also try chkrootkit -> www.chkrootkit.org if it will found something susperious, remove the box from the network and trust non of the data you've on it. regards
Hi Sven, Sven 'Darkman' Michels schrieb:
looks like a backdoor. Check if any port is open on your box who souldn't be there.
The standard security-check mailed me: * Changes (+: new entries, -: removed entries): + bi wwwrun TCP *:4000 (LISTEN) + bi wwwrun TCP *:443 (LISTEN) + bi wwwrun TCP *:80 (LISTEN) It looks like a second process is listening at 443/80 -- because apache incl. ssl worked fine.
Whats about Apache? up-to-date? php? OpenSSL? all those where exploitable in the last month and your kernel looks like an default kernel from 7.3, if you update it, you should have at least 2.4.16-4GB. Also try chkrootkit -> www.chkrootkit.org if it will found something susperious, remove the box from the network and trust non of the data you've on it.
I'm working on that -- I thought, maybe there are detailed informations out in the field about the type of backdoor and the way he got in. Thanks for help. Regards, Dirk
Am Mit, 2002-12-25 um 09.57 schrieb Dirk Kutsche:
Hi Sven,
Sven 'Darkman' Michels schrieb:
looks like a backdoor. Check if any port is open on your box who souldn't be there.
The standard security-check mailed me: * Changes (+: new entries, -: removed entries): + bi wwwrun TCP *:4000 (LISTEN) + bi wwwrun TCP *:443 (LISTEN) + bi wwwrun TCP *:80 (LISTEN)
It looks like a second process is listening at 443/80 -- because apache incl. ssl worked fine.
Huh? Since when can a port be used twice? I'd say "bi" is a tronjaned version of apache and the original apache isn't running at all. -- Matthias Hentges Cologne / Germany [www.hentges.net] -> PGP welcome, HTML tolerated ICQ: 97 26 97 4 -> No files, no URL's My OS: Debian Woody: Geek by Nature, Linux by Choice
On Wednesday 25 December 2002 10.36, Matthias Hentges wrote:
Am Mit, 2002-12-25 um 09.57 schrieb Dirk Kutsche:
Hi Sven,
Sven 'Darkman' Michels schrieb:
looks like a backdoor. Check if any port is open on your box who souldn't be there.
The standard security-check mailed me: * Changes (+: new entries, -: removed entries): + bi wwwrun TCP *:4000 (LISTEN) + bi wwwrun TCP *:443 (LISTEN) + bi wwwrun TCP *:80 (LISTEN)
It looks like a second process is listening at 443/80 -- because apache incl. ssl worked fine.
Huh? Since when can a port be used twice? I'd say "bi" is a tronjaned version of apache and the original apache isn't running at all.
I wonder why his using port 4000..? That used to be the old ICQ protocol if i'm not mistaken... Can it be a password sniffer? Posing as Apache, and logging(?) all passwords sent thru http, hhtps and ICQ.... Just a thought... -- /Rikard ------------------------------------------------------------------------------------ Rikard Johnels email : rjhn@linux.nu Web : http://www.rikjoh.com Mob : +46 70 464 99 39 ------------------------ Public PGP fingerprint ---------------------------- < 15 28 DF 78 67 98 B2 16 1F D3 FD C5 59 D4 B6 78 46 1C EE 56 >
On Wed, Dec 25, 2002 at 10:36:33AM +0100, Matthias Hentges wrote:
It looks like a second process is listening at 443/80 -- because apache incl. ssl worked fine.
Huh? Since when can a port be used twice?
If the process was forked by apache, it inherits the open file descriptor for ports 80 and 443. Olaf -- Olaf Kirch | Anyone who has had to work with X.509 has probably okir@suse.de | experienced what can best be described as ---------------+ ISO water torture. -- Peter Gutmann
Hi Matthias,
Huh? Since when can a port be used twice? I'd say "bi" is a tronjaned version of apache and the original apache isn't running at all.
That is what I was wondering too -- but: I killed the prozess "bi", I didn't started anything else - and http and https still working. And: the suse-check showed the added processes - but no removed prozesses. Maybe it's a trojan "trough" apache? And: the port 4000 isn't accessable from the outside -- because there is a separate fw in front of. I have tcpdump-files -- but it's a hard work to check/filter these megabytes to get the right part out of it. Takes some time. Regards, Dirk
Dirk Kutsche wrote:
Hi Sven,
Sven 'Darkman' Michels schrieb:
looks like a backdoor. Check if any port is open on your box who souldn't be there.
The standard security-check mailed me: * Changes (+: new entries, -: removed entries): + bi wwwrun TCP *:4000 (LISTEN) + bi wwwrun TCP *:443 (LISTEN) + bi wwwrun TCP *:80 (LISTEN)
It looks like a second process is listening at 443/80 -- because apache incl. ssl worked fine.
hum, thats bad ... is apache running on a specific ip?
I'm working on that -- I thought, maybe there are detailed informations out in the field about the type of backdoor and the way he got in.
hopefully, you also can mail me the bi binary, maybe i'll find something... regards, Sven
participants (5)
-
Dirk Kutsche -
Matthias Hentges -
Olaf Kirch -
Rikard Johnels -
Sven 'Darkman' Michels