In Search of 6667 Infringer

BigWil

Verified User
Joined
Aug 5, 2004
Messages
296
I just figure I would throw this out there and see if anyone has any ideas. I have an AUP infringing script or program trying to use outbound port 6667 to blast somebody or something. When I allow it through I notice a substantial performance loss so I would guess it is an IRC Bot infection.

The problem is that I can't find it to shut it up and it floods my firewall logs. I have done everything from grepping the machine for the obvious to tailing most of the logs in hopes for something. No installs of PHPNuke on this machine and I have never seen anything get installed that to my knowledge would do this. Tripwire and the DDoS toys detect nothing.

Big Wil
 
Try lsof... it is your best friend in cases like this. RH/Centos have rpms.
Code:
lsof -i TCP:6667
should give you the name of the command, the user, etc. that is using the port.
 
Yah I wanted to try that one. Not available for FreeBSD though.

Big Wil
 
lsof is available as a port

cd /usr/ports/sysutils/lsof
make install clean

however you can also try sockstat | grep :6667
 
Yah. Lots of useful information. However, it doesn't tell me where the offending script is or what it is. I am installing the lsof from the ports collection. When it starts trying to phone home again hopefully that will give me the info I need to actually remove it from the machine.

Thanks gentlemen.

Big Wil
 
Well both the sockstat and lsof don't seem to give up any useful information to the case. The firewall is blocking the outgoing connections as per my directives so it stops just as quick as it starts since it is failing.

The culprit seems to be related to and apache process somehow and it runs as (psynch). Does that ring any bells to anyone.

Here is a clip from the ipmon logging.

Jun 21 13:36:47 hera ipmon[86]: 13:36:46.007570 bge0 @0:1 b 1.2.3.152,2746 -> 202.134.0.199,6667 PR tcp len 20 60 -S OUT
Jun 21 13:36:47 hera ipmon[86]: 13:36:46.007650 bge0 @0:1 b 1.2.3.152,2746 -> 202.134.0.199,6667 PR tcp len 20 52 -F OUT

BigWil
 
Correction that was psybnc. Strangely I just noticed that the PID is a very low number when the current PIDs are more like 54K. Spooky.

803 apache 2 0 2632K 820K select 0 1:23 0.00% 0.00% psybnc

I see there is a distribution called psybnc but I haven't found that it is installed on the machine. Though I also see that it can be installed with Mod_Perl. Could Mod_Perl be infected? If so can it initialize even if I have Mod_Perl commented out in the httpd.conf?

Such a bizzare case.

Big Wil
 
Yep. And the reason why I am focusing on it. If there is the slight hint of paranoia in my voice it is because of where the calls are going out to ... Indonesia. Aside from Nigeria it is tops for E-Commerce fraud and coincidently or now we happen to be a very well known e-commerce hosting provider. Unfortunately I don't really believe in coincidence.

It seems that psybnc can open up vulnerabilities. Here is some reading.

http://www.securitytracker.com/alerts/2002/Apr/1004128.html
http://p.ulh.as/xploitsdb/Other/5306.html
http://www.packetfu.org/hpa.html

All the more reason not to have it installed and we didn't intentionally. However it looks like mod_perl has it compiled in.

hera# locate psybnc
/usr/local/directadmin/customapache/mod_perl-1.29/t/logs/.bxr/log/psybnc.log
/usr/local/directadmin/customapache/mod_perl-1.29/t/logs/.bxr/log/psybnc.log.old
/usr/local/directadmin/customapache/mod_perl-1.29/t/logs/.bxr/psybnc
/usr/local/directadmin/customapache/mod_perl-1.29/t/logs/.bxr/psybnc.conf
/usr/local/directadmin/customapache/mod_perl-1.29/t/logs/.bxr/psybnc.pid

I think someone should look into how to NOT compile mod_perl with this option. Am I the only one to notice this? Isn't anyone else seeing the psybnc and :6667 activity?

Big Wil
 
Well I think I found it:

hera# pwd
/usr/local/directadmin/customapache/mod_perl-1.29/t
hera# ls
README TEST.PL TestDirectives docs internal modules report
TEST TEST.win32 conf httpd.conf logs net report.PL
hera# ls logs
.bxr psy.tar.gz


This distribution doesn't exist on any of the other machines. And the contents of the .bxr directory:

hera# ls logs/.bxr/
config f*ck log psybnc run ssstt.dir y2kupdate
config.h help motd psybnc.conf scripts ssstt.old
cron.d lang proc psybnc.pid ssstt xh

Looking into it further but usually the professional types don't name their directories such things. What really concerns me is that this verion of Mod_Perl was installed by the DA install script.

Now on to the disection.

Big Wil
 
Tried that one first. Wouldn't give me the whole page so I copied it over piece by piece. Made about as much sense to me as well.... German. ;-)

Big Wil
 
I don't think this was installed or included by mod-perl... I think it was just a convenient directory that your attacker had write access to. In my DA folder, the "t/logs" folder has world-write permissions...

Who owns the .bxr folder and the psy.tar.gz file? If it's apache, I'd guess that someone exploited a web script to download the tar file which contains the binaries, etc.

I'd suggest you do (at least) a complete security audit and figure out how the server was exploited, how the script is being called (either a web script or apache's crontab?) and if the attacker managed to escalate their privileges.
 
Some points to help you.

1 - lsof and sockstat will only show you active connections so if the bnc wasnt online when you checked it wont show and then if it does you will only get the daemon name and not the path.

2 - if it is a low pid then it was likely started shortly after bootup time, possibly automatically started.

3 - On any servers that you want irc forbidden on I suggest you utilise a firewall, I reccomend ipfw to block all outgoing connections to 6660-6669,7000.
 
Correct on all counts. Ipfirewall has been blocking the infection for quite along time now. My complaint was the firewall rules violations in the logs. Always trying to go out on 6667. Good to know and I will now block 6660-6669 and 7000.

The above is most likely correct. Some time back I recall a ddos tool made it to the /tmp directory on this machine. I knew about it just a few minutes later as it was detected by find_dos and I was informed of it. Chop and it was gone. Probably came through a PHP script no doubt. I suspect that the psybnc was installed by that script but who will ever know. Chop chop and now they are both toast.

I will be adding ssstt to my hourly scan list now that I know what to search for. Thanks again guys.

Big Wil
 
Back
Top