hack lesson?

[R Scott Belford]

I was running apache on 80, ssh on 22, smtp 0n 25, pop on 110, and pop3s 
and https on their ports.  I am not 100% sure that I was hacked.  
Nothing in my maillog that indicates that they took advantage of 
sendmail or my pop server.  No indication from my secure log that any 
unauthorized attempts were made to my sshd.  Nothing really unusual 
about my apache logs.  The "hacked" machine is my firewall.  I was using 
ipchains to block my other ports.  I nmap myself often and look okay.

I ran portsentry some lately, but freaked out when I nmapped myself and 
saw that all kinds of wicked ports were open.  Some reading at 
chkrootkit.org led me to believe that this was part of how it worked.  I 
still disabled it until I could research it more.  Any insights here?  
Perhaps I unpacked a sinister tarball a few weeks ago.

I recently installed perl ssl leay or something like that.  It enabled 
me to run webmin in a secure apache session, you know, https.  This was 
done to keep my airport sessions encrypted.  I have asked Jamie if he 
thinks this could be an issue.  I definitely have a perl directory 
(cgi-bin) in my var/www directory.  I knew perl commands could be 
executed through apache, but I did not think that this was a 
vulnerability.  "I did not think" may come back to haunt me.

scott

On Saturday, January 12, 2002, at 12:09  AM, Dustin Cross wrote:

> 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 leave-
>>>> luau-1689D at list.luau.hi.net
>>>>
>>>
>>> ---
>>> 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')
>>
>
> ---
> You are currently subscribed to luau as: sctinc at mac.com
> To unsubscribe send a blank email to $subst('Email.Unsub')