hack lesson?

[Dustin Cross]

Perl isn't a service and therefor can not be a remote exploit.  It is a programming 
language.  For a remote exploit you have to have an a service bound to a port and 
open to the world (ie not firewalled).  Only things like http bound to port 80, or 
smtp bound to port 25 can be used as remote exploits.  Or the programs different 
services rely on like login that can be used by telnet, ftp, or ssh.  Perl scripts 
can be exploited if they are accessable like a cgi in your webserver or something.  
Perl might have some local root exploits that would upgrade an account on the box 
to root.  So I dought very seriously if Perl was your problem.  

What services where you running on this box?
Have you recently upgraded Perl or anything else that could have been infected?
Do you see anything odd in your logs?
Are you 100% sure your system was hacked?
Is the system behind a firewall or is this your firewall?

Look at who was loged in at the time the processes started and work from there.

Dusty


R Scott Belford (sctinc at mac.com) wrote: 
>
>Dusty, thanks for the link and the tip.  Definitely heading for a
>reinstall once the detective work is over.  You know, I am not sure that
>this has anything to do with webmin.  Jamie Cameron did not think so and
>has not had any similar reports.  He wrote webmin.  I was using the
>current version with all updated modules, and I had it bound to my local
>eth only.
>
>I am sure that I am a bit of a nut.  My debian box was not hacked.  I
>can log in.  When I am in a fit of foolishness I perceive successful
>logins as unsuccessful logins, blame it on a hack and turn off the box.
>Don't ask why.
>
>My redhat box, the one that is connected to my wan and was routing all
>my traffic, has had something happen to it.   It looks like, from my
>messages log, that my xserver had some trouble even before I noticed the
>intensive /usr/lib/perl activity.  My X log indicates a failure with my
>default font that keeps it from starting.  I can disable my xdm and get
>a login prompt.  I would say that perhaps I just had an x failure and
>freaked out.  It wouldn't be the first time.
>
>But, there is the fact that root was doing something with /usr/bin/perl
>for about 5 hours today and used alot of processor cycles doing it.  PS
>-ax revealed some confusing programs that were running, but I was too
>hasty to write their names down.  I just wanted to restart and take
>control.  Does that sound comically contradictory to you?  Me too.  What
>I do know is the result of a chkrootkit.  It is as follows:
>
>Checking `amd'... not infected
>Checking `basename'... not infected
>Checking `biff'... not infected
>Checking `chfn'... not infected
>Checking `chsh'... not infected
>Checking `cron'... not infected
>Checking `date'... not infected
>Checking `du'... not infected
>Checking `dirname'... not infected
>Checking `echo'... not infected
>Checking `egrep'... not infected
>Checking `env'... not infected
>Checking `find'... not infected
>Checking `fingerd'... not infected
>Checking `gpm'... not infected
>Checking `grep'... not infected
>Checking `hdparm'... not infected
>Checking `su'... not infected
>Checking `ifconfig'... not infected
>Checking `inetd'... not infected
>Checking `inetdconf'... not found
>Checking `identd'... not infected
>Checking `killall'... not infected
>Checking `login'... not infected
>Checking `ls'... not infected
>Checking `mail'... not infected
>Checking `mingetty'... not infected
>Checking `netstat'... not infected
>Checking `named'... not infected
>Checking `passwd'... not infected
>Checking `pidof'... not infected
>Checking `pop2'... not found
>Checking `pop3'... not found
>Checking `ps'... not infected
>Checking `pstree'... not infected
>Checking `rpcinfo'... not infected
>Checking `rlogind'... not infected
>Checking `rshd'... not infected
>Checking `slogin'... not infected
>Checking `sendmail'... not infected
>Checking `sshd'... not infected
>Checking `syslogd'... not infected
>Checking `tar'... not infected
>Checking `tcpd'... not infected
>Checking `top'... not infected
>Checking `telnetd'... not infected
>Checking `timed'... not found
>Checking `traceroute'... not infected
>Checking `write'... not infected
>Checking `aliens'... no suspect files
>Searching for sniffer's logs, it may take a while... nothing found
>Searching for t0rn's default files and dirs... nothing found
>Searching for t0rn's v8 defaults... nothing found
>Searching for Lion Worm default files and dirs... nothing found
>Searching for RSHA's default files and dir... nothing found
>Searching for RH-Sharpe's default files... nothing found
>Searching for Ambient's rootkit (ark) default files and dirs... nothing
>found
>Searching for suspicious files and dirs, it may take a while...
>/usr/lib/perl5/5.6.0/i386-linux/.packlist
>/usr/lib/perl5/5.6.0/i386-linux/auto/Gnome/.packlist
>/usr/lib/perl5/5.6.0/i386-linux/auto/Gnome/Applet/.packlist
>/usr/lib/perl5/5.6.0/i386-linux/auto/Gnome/Print/.packlist
>/usr/lib/perl5/5.6.0/i386-linux/auto/Gtk/Gdk/ImlibImage/.packlist
>/usr/lib/perl5/5.6.0/i386-linux/auto/Gtk/Gdk/Pixbuf/.packlist
>/usr/lib/perl5/5.6.0/i386-linux/auto/Gtk/GladeXML/.packlist
>/usr/lib/perl5/5.6.0/i386-linux/auto/Gtk/XmHTML/.packlist
>/usr/lib/perl5/5.6.0/i386-linux/auto/Gtk/base/.packlist
>/usr/lib/perl5/5.6.0/i386-linux/auto/Gimp/.packlist
>/usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/Digest/MD5/.packlist
>/usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/Image/Magick/.packlist
>/usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/DBD/Pg/.packlist
>/usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/Msql-Mysql-
>modules/.packlist
>/usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/Net/SSLeay/.packlist
>/usr/lib/mozilla/plugins/java2/bin/.java_wrapper
>/usr/lib/office52/share/kde/applnk/.directory /lib/..
>
>Searching for LPD Worm files and dirs... nothing found
>Searching for Ramen Worm files and dirs... nothing found
>Searching for Maniac files and dirs... nothing found
>Searching for RK17 files and dirs... nothing found
>Searching for Ducoci rootkit... nothing found
>Searching for Adore Worm... nothing found
>Searching for ShitC Worm... nothing found
>Searching for Omega Worm... nothing found
>Searching for anomalies in shell history files... nothing found
>Checking `asp'... not infected
>Checking `bindshell'... INFECTED (PORTS:  1524 31337)
>Checking `lkm'... nothing detected
>Checking `rexedcs'... not found
>Checking `sniffer'...
>eth0 is not promisc
>eth1 is not promisc
>Checking `wted'... nothing deleted
>Checking `z2'...
>nothing deleted
>
>It appears that a corrupt perl directory has been installed.  How did
>they get in?  Some buffer overflow of perl that gave them root access to
>install the rootkit?  Beats me, but I am checking with those who may
>know.  It's very possible that I made a mistake some time last year that
>someone is just now spanking me for.
>
>A friend suggested that I look at my rc.local file where I found "touch
>/var/lock/subsys/local."  Having no virgin rc.local to look at, I don't
>know if it's legit.
>
>It is dangerous to suggest that someone in a mailing list is responsible
>for a hack.  Talk about introducing FUD.  I recognize this and would
>hesitate to think that the active participants would stoop to such an
>act.  The coincidence is unbearable, though.  I was clearly flaunting my
>confidence in webmin, and what better way to given someone a lesson in
>humility than to exploit their confidence.  It would not surprise me if
>someone took this upon his/her self to do so.  No harm was done, no
>defacing or data corruption occurred.  I'll be back up and I'll be
>running webmin.  Keep a look out for me.  Come and get it.
>
>scott
>
>
>
>the On Friday, January 11, 2002, at 09:49  PM, Dustin Cross wrote:
>
>> I don't know what version of webmin you are running but there is only
>> one known
>> vulnerability (that I know of anyway) in the current version (0.91).
>> It is a
>> directory traversal exploit using ../../ read about it at
>> http://xforce.iss.net/static/7711.php.  I definately wouldn't open
>> webmin up to the
>> world, but it is safer than using telnet which millions still do!
>>
>> Dusty
>>
>> P.S. - You can't clean up after being hacked!  You never know what was
>> done, so
>> make sure you format and reinstall!
>>
>>
>>
>> R Scott Belford (sctinc at mac.com) wrote:
>>>
>>> I guess that I was asking for this, if such a thing is possible.  Some
>>> of you will laugh and some may be interested.  It's a good story.  This
>>> morning, a little after  I posted a response about rpm's and webmin,
>>> someone entered my machine.  It was right as I was being responded to
>>> and warned about the explicit dangers perl creates.  I obviously should
>>> have realized this as someone was determined to teach me a lesson by
>>> damage rather than words.
>>>
>>> I noticed around 2:30 this afternoon, when running top, that several
>>> pid's owned by root had been consuming a lot of processor cycles for
>>> about 5.25 hours.  They were running /usr/bin/perl.  When I looked at
>>> my
>>> gui process manager, several programs with unfamiliar names were
>>> running.  I was unable to terminate these by kill -9 pid.  I elected to
>>> restart my machine.  Typical windoze fix, but I was hoping to stop the
>>> processes.  Upon restarting, I am unable to get a terminal on the
>>> redhat
>>> box.  It keeps flashing for a second, this disappears.  Someone has put
>>> the x server in some kind of loop that keeps me from the prompt.  I'd
>>> log in from my Debian box, but they went in there too.  I log in to it,
>>> enter a password, and am returned to the login prompt.  At least I
>>> get a
>>> prompt on it.  Unkind but funny.  I ssh in from my windoze box and ps
>>> -ax shows a  complicated x command running that seems to be causing my
>>> redhat login difficulties.  Attempts to kill this pid fail as its pid
>>> number keeps changing.  These are teasing hacks, I know, but I just
>>> can't fix them (yet.)
>>>
>>> So, obviously there is some kind of vulnerability that perl has created
>>> for me which I was warned about then exploited through.  No harm
>>> done, I
>>> keep backups of my worthless data.  My time is not so valuable that I
>>> care about reinstalling.  Someone can pat their self on the back for
>>> it.  What is a shame, though, is that I clearly upset someone reading
>>> this mailing list earlier who decided to show me how smart they were.
>>> The coincidence is too uncanny.  Rather than share their knowledge to
>>> the better of all, they have abused my poor little box.  I guess that
>>> shows me how much smarter real sysadmins are than newbies.
>>>
>>> I have an appetite for humble pie, though, and will only grow wiser
>>> from
>>> this experience.  If this perl vulnerability is in anyway related to
>>> webmin, then let me be the first to say to be wary of it.  I have no
>>> certainty of this, though, and would be more wary about spreading fud.
>>> When I learn what is of value from this hack, I'll let any of you know
>>> who are interested.  If you have any insights in to what tricks have
>>> been played here, perhaps you will share them.  I'd love to make
>>> something good out of this.
>>>
>>> scott
>>>
>>>
>>> ---
>>> You are currently subscribed to luau as: dusty at sandust.com
>>> To unsubscribe send a blank email to $subst('Email.Unsub')
>>>
>>
>> ---
>> You are currently subscribed to luau as: sctinc at mac.com
>> To unsubscribe send a blank email to $subst('Email.Unsub')
>
>
>---
>You are currently subscribed to luau as: dusty at sandust.com
>To unsubscribe send a blank email to $subst('Email.Unsub')
>