|
chkrootkit concern
I just ran chkrootkit on my Debian/2.6 kernel machine and this is what it comes up with:
# chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found 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 found Checking `gpm'... not found Checking `grep'... not infected Checking `hdparm'... not found Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not tested Checking `inetdconf'... not infected Checking `identd'... not found Checking `init'... not infected Checking `killall'... not infected Checking `ldsopreload'... not infected Checking `login'... not infected Checking `ls'... not infected Checking `lsof'... not found Checking `mail'... not infected Checking `mingetty'... not found Checking `netstat'... not infected Checking `named'... not found 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 found Checking `rshd'... not found 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 `tcpdump'... not infected Checking `top'... not infected Checking `telnetd'... not found Checking `timed'... not found Checking `traceroute'... not found Checking `vdir'... not infected Checking `w'... 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 HiDrootkit's default dir... 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... /lib/modules/2.6.0-1-k7/build/.config 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 Sadmind/IIS Worm... nothing found Searching for MonKit... nothing found Searching for Showtee... nothing found Searching for OpticKit... nothing found Searching for T.R.K... nothing found Searching for Mithra... nothing found Searching for OBSD rk v1... nothing found Searching for LOC rootkit ... nothing found Searching for Romanian rootkit ... nothing found Searching for Suckit rootkit ... nothing found Searching for Volc rootkit ... nothing found Searching for Gold2 rootkit ... nothing found Searching for TC2 Worm default files and dirs... nothing found Searching for Anonoying rootkit default files and dirs... nothing found Searching for ZK rootkit default files and dirs... nothing found Searching for ShKit rootkit default files and dirs... nothing found Searching for AjaKit rootkit default files and dirs... nothing found Searching for zaRwT rootkit default files and dirs... nothing found Searching for anomalies in shell history files... nothing found Checking `asp'... not infected Checking `bindshell'... not infected Checking `lkm'... You have 2 process hidden for readdir command You have 2 process hidden for ps command Warning: Possible LKM Trojan installed Checking `rexedcs'... not found Checking `sniffer'... lo: not promisc and no packet sniffer sockets eth0: PACKET SNIFFER(/sbin/dhclient[859]) eth1: not promisc and no packet sniffer sockets eth2: not promisc and no packet sniffer sockets Checking `w55808'... not infected Checking `wted'... nothing deleted Checking `scalper'... not infected Checking `slapper'... not infected Checking `z2'... nothing deleted # What is this "LKM Trojan" that "might" be there? What does it mean by dhclient being a packet sniffer? Do I need to worry about this, and if so, what do I need to do to my system? Thanks... |
computergeek...i too received this "same" kind of chkrootkit error (LKM Trojan) on a RH Linux (7.3) system.
Output from: ./chkrootkit -x lkm [root@machineX chkrootkit-0.43]# ./chkrootkit -x lkm ROOTDIR is `/' ### ### Output of: ./chkproc -v -v ### PID 889: not in ps output CWD 889: / EXE 889: /usr/bin/divine PID 891: not in ps output CWD 891: / EXE 891: /lib/defs/loco/dsniff You have 2 process hidden for ps command Does anyone have a clue where these lkm messages could be linked to? False positives perhaps? zepplin611 |
zepplin611,
That is probably not a false alarm. There are a couple of pieces of software named divine, one is a debian package for automatic IP configuration and the others are part of Linux exploits. Dsniff is a really powerfull network sniffer used to capture traffic including passwords. Plus look at the path of the sniffer, (lib/defs/loco/dsniff. That looks really suspicious. You might want to check the output of lsmod and cat /proc/modules, but that might not be very revealing. First and foremost, turn off that box and remove the networking cable,do not turn it back on while it's connected to the network untill you are sure it's clean. The best way to take a look at the logs is to boot that box with a CD-ROM based distro like knoppix or FIRE (if you don't have either of these, then download and burn one on a different computer), then mount the supected systems hard-drive read-only (don't boot the compromised kernel). Once you've got it mounted, go over the system logs looking for anything suspicious (take a look at the time stamps of /usr/bin/divine and /lib/defs/loco/dsniff and use those as a rough indicator of when the compromised files were installed). You might want to dig around in /lib/defs/ as that's a fairly non-standard directory for that filesystem and could be a a stash for the root-kits files. If you find stuff like that, then it's pretty evident that you got cracked. You can check out any of the rootkit stuff if you want to, but what will really be more important is figuring out how the person got in. Look in your logs for weird activity or application errors/segfaults that might tip you off as to how they got in. As much as this sucks, if you have been compromised, you'll need wipe the drive and do a full re-install from trusted media (don't use a potentially compromised backup either). Simply deleting the rootkit files won't do the trick and tracking down the LKM isn't always straight forward; there may or may not be stuff hidden all over the file system, so re-installing is really the only way to go. If you have important files, don't transfer any of them untill you have visually inspected them and are sure they're clean (if it's a binary file, then forget it). |
computergeek84,
Chkrootkit is prone to falsealarms, especially with the LKM check. Problem is that chkrootkit looks at what processes are in /proc and then compares that to the output of ps, so a short-lived process can terminate in between those two checks, thus giving a false LKM alarm. To verify, run it just like zepplin611 did, in expert mode: ./chkrootkit -x lkm and see what that gives you. You can tell if it's a false alarm, if A)The missing processes error goes away or B)If it's still there, but turns out to be something benign. The dhclient part is also a common false alarm. Dhclient is your boxes DHCP client which listens on a network socket for DHCP messages from the network. I'm not familiar with the Deb package handler, so I can't give you step by step instructions, but you'll want to verify the dhclient files are the proper size and have the proper md5sum. |
Thanks Capt_Caveman...
Here is the result of chkrootkit -x lkm: # chkrootkit -x lkm ROOTDIR is `/' ### ### Output of: ./chkproc -v -v ### PID 491: not in readdir output PID 491: not in ps output CWD 491: /var/lib/mysql EXE 491: /usr/sbin/mysqld PID 492: not in readdir output PID 492: not in ps output CWD 492: /var/lib/mysql EXE 492: /usr/sbin/mysqld You have 2 process hidden for readdir command You have 2 process hidden for ps command # It just looks like it's mysql running (but hidden to ps). Should it really be like this, or is it a compromised mysql process? Thanks... |
Can you think of a reason why you'd have mySQL daemon processes running?
|
Not at the moment...I have used MySQL in the past to power things like phpBB, but I am not using it at the moment. I just stopped the MySQL daemon from /etc/init.d/ and now chkrootkit -x lkm returns nothing. So, was it a false alarm, or do I have a corrupted version of MySQL?
Thanks... |
It's probably a good idea to check the mySQL binaries and make sure they're alright, just to be on the safe side. Might want to see if you can figure out why it was running in the first place and keep an eye open to see if it pops up again. You should probably go through your system logs and see if you see anything out of the ordinary (application segfaults, strange logins, new users in etc/passwd or anyone but root with a UID of 0), but I don't think you have any reason to take it off line just yet. If you had something like tripwire or samhain installed previously, it would really have helped you figure out if anything had been altered. There's also a couple of tools for identifying LKMs in 2.4 series kernels at this link that you can use to check your syscall table.
|
thanks caveman...your advice is sound and b/c of it, i will need to rebuild the machine, ASAP!
I checked the dirs you mentioned and things looked very odd...i.e. files that should not be there, files with a slew of unrecognizable ip addresses, and other dirs that should not be there. This machine runs apache, can you point me to a tutorial on apache, to help me with building it on the newly updated machine? I have never used this webserver software before...thanks again. zepplin |
ajoshay9 = zepplin611 ?
Apache is pretty secure with the default configuration. Your time will probably be better spent working on setting up a good firewall (a noticed you had a post about sendmail and iptables not too long ago) and in hardening the box in general. Things like turning off un-needed services, making sure you have updated patches (if your running redhat or fedora, then yum is a necessity). Install a file integrity scanner like tripwire, aide or samhain. Read through the Security references thread towards the top of the forum, unSpawn put together a really comprehensive set of links including ones on general security hardening. I noticed you found some rootkit dirs and stuff, but any luck on figuring out how they got in? Anything in the logs the might be informative? It's probably a good thing to figure out, just so you can tighten that hole in the future (the saying "those who don't learn from the past are doomed to repeat it" comes to mind). Also make sure to change all of your passwords, as you have to assume any that you have used on or near that machine are compromised as well. |
yes caveman i had an old LQ login that i have since changed...thanks for replying so quickly.
Re: How they got in: Well...this machine is also an ftp server, that we receive daily data from, pushed to us by another company...pushed via "regular" ftp. I know this is unsafe, and will cause extra work for me now, but its a system that has been in place long before i got to this job...and one i have pressed the powers that be, to fix. No luck, so far. Thanks for the tips on apache...i have found several places on the RH website that are useful. So the question is, how do i make this "ftp-server" as secure as possible. Would you suggest: pro-ftp, vsftp, or lftp? None of these? I know that with each of these, things can be done to lock down the machine and infact I have tried to push the users on this machine to use "anonymous" only logins, but the politics to do this appears insurmountable (or as i see it, people are just lazy). I will look at the unSpawn posts and study the iptables sections. It is possible to configure iptables to allow ftp through (on a specified port) right? Thanks again... zepplin |
So the question is, how do i make this "ftp-server" as secure as possible. Would you suggest: pro-ftp, vsftp, or lftp?None of these?
I'm only famliar with the first two and I don't think one is exceptionally better than the other. In general though, I'm not a big fan of publically accessible FTP servers. I think there are more secure ways of transfering data from one locale to another. Probably one of the best would be to set up and encrpyted ssh or ssl tunnel and then pipe some other protocol through it. What that protocol is depends on what your client can set up, but you could use the current FTP method if you wanted. If having a static link isn't going to work (like if they need more flexible access or whatever) then you may just have to use FTP. In that case, you should definitely configure it to run as chroot and I would avoid anonymous logins with write privileges on, that's a recipe for disaster. I know that with each of these, things can be done to lock down the machine and infact I have tried to push the users on this machine to use "anonymous" only logins, but the politics to do this appears insurmountable (or as i see it, people are just lazy). Lazy and dumb is usually the norm. Again I don't see why you want them to use anonymous logins as that may be a bad thing in of itself. What kind of setup do they use (windows machines, *nix, mixed)? Do they need individual accounts or can you just give them one login and have them dump files to one place? Depending on their needs, you might be able to set up a number of things that can be as seamless yet more secure. I will look at the unSpawn posts and study the iptables sections. It is possible to configure iptables to allow ftp through (on a specified port) right? Yes. Iptables is very configurable and you can allow incoming ftp on whatever port you want. I would recommend the frozen tux tutorial that's available at www.netfilter.org . There's also a number of sites that will build one for you, but I don't have any of those links offhand. Let me know if you need one and I can dig it up for you. There's also a couple of GUI front-ends for managing iptables, firestarter and guarddog come to mind and our fearless leader Jeremy has an article in this months Linux Magazine (Feb 2004) that talks about fwbuilder <shameless plug>. |
Caveman,
you mentioned tripwire (yes, i'm up and running with a newly installed os and apache webserver...still working on the ftp server...seeing if we can do a work around with a more secure means of access) was one possibility for IDS...the rpm for it was downloaded and I followed these directions on the redhat website: "After installing this package, run /etc/tripwire/twinstall.sh to generate cryptographic keys and run tripwire --init to initialize the database." i ran twinstall.sh and no problems. I ran: tripwire --init and a series of errors similar to: ### Warning: File system error. ### Filename: /root/.gnome-desktop ### No such file or directory ### Continuing... ### Warning: File system error. ### Filename: /root/.ICEauthority ### No such file or directory ### Continuing... ### Warning: File system error. ### Filename: /root/.Xauthority ### No such file or directory ### Continuing... Wrote database file: /var/lib/tripwire/machine.domain.net.twd The database was successfully generated. It said the database was created successfully and there is indeed a file in /var/lib/tripwire ---> so the question is: what next? What is the executable that i run "regularly" and to what do i compare this too on consecutive runnings of this? I really want this machine "locked" down as much as possible. I am also working on learning iptables to strengthen firewall security. Thanks again for the help... zepplin |
caveman,
I figured out the trip-wire issues...its now installed and thanks to you i am a bit more secure these days! Re: Update to the crack which initiated me into this thread: I booted knoppix on the comprimised machine and mounted the disk (read-only) and then did some investigative work. I have discovered that: "adore" was installed on my machine. From just a little bit of googling, i was able to track down several "rootkits" for this heinous "adore". Question...some of the readme files list "adore" as "Honey-pot" software...what a load of garbarge. It very well may be "honey-pot" software, but its also cracking software. Can i report the website that contains these "rootkits" to anyone in the security field? Perhaps this person(s) ISP and get it shut down? From what i gathered new directories/files were installed ALL over my machine. particularly in: /dev/.../.src <--- this not so obvious way of making a directory "..." is very cute....and like most cute things, very deadly! also additions were made to: /etc/rc.d and the files: rc0.d, rc1.d, etc. I looked in the logs but since this crack happened so long ago (my guess is early september b/c there was a major crack on the department machines around labor day and several of the time-stamps reflect this...though they easily could have been changed), much of the info was rotated out of the /var/log logs. Thanks again caveman...i see all the posts that you make...you must never sleep. zepplin611 |
I figured out the trip-wire issues...its now installed and thanks to you i am a bit more secure these days!
Good deal! I meant to get back to you on your post but got a bit swamped :( Question...some of the readme files list "adore" as "Honey-pot" software...what a load of garbarge. It very well may be "honey-pot" software, but its also cracking software. Can i report the website that contains these "rootkits" to anyone in the security field? Perhaps this person(s) ISP and get it shut down? That's pretty standard. Most rootkit authors describe their work as "remote administration tools". Unfortunately it's usually someone else doing the "administering". Falls under the same logic as the legality of assault rifles...technically they could be used for hunting, but how often do you see someone shoot a deer with an Uzi? Not much you can really do about it. Some of the most notorious backdoors have managed to maintain a presence by claiming that they can't control what people do with their product. /dev/.../.src <--- this not so obvious way of making a directory "..." is very cute....and like most cute things, very deadly! Pretty common as well. Crackers like to believe that people can't tell the difference between ... and .. . Anytime you see that, alarms should go off in your head. I looked in the logs but since this crack happened so long ago (my guess is early september b/c there was a major crack on the department machines around labor day and several of the time-stamps reflect this...though they easily could have been changed), much of the info was rotated out of the /var/log logs. That's part of the reason why I often suggest people setup some kind of remote logging that saves backups longer than syslog keeps them around. Also you should rigorously examine other machines on your network and notify others whose machines may have been put at risk (if appropriate). Consider any passwords that have been used on that machine compromised as well. Thanks again caveman...i see all the posts that you make...you must never sleep. Lol. I'm in grad school as well, so sleep has been optional for the last couple of years anyway. Also explains my sig. |
| All times are GMT -5. The time now is 03:00 PM. |