On Sun, Jan 1, 2012 at 5:01 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Sun, Jan 1, 2012 at 4:23 PM, Bennett Haselton bennett@peacefire.org wrote:
So, following people's suggestions, the machine is disconnected and
hooked
up to a KVM so I can still examine the files. I've found this file: -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl which appears to be a copy of this exploit script: http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html Note the last-mod date of October 21.
Did you do an rpm -Va to see if any installed files were modified besides your own changes? Even better if you have an old backup that you can restore somewhere and run an rsync -avn against the old/new instances.
rpm -Va gives:
....L... c /etc/pam.d/system-auth S.5....T c /etc/httpd/conf.d/ssl.conf SM5...GT c /etc/squid/squid.conf S.5....T c /etc/login.defs S.5....T c /etc/ssh/sshd_config S.5....T c /etc/httpd/conf.d/welcome.conf S.5....T c /etc/httpd/conf/httpd.conf S.5..... c /etc/ldap.conf S.5..... c /etc/openldap/ldap.conf ....L... c /etc/pam.d/system-auth .......T c /etc/audit/auditd.conf S.5....T c /etc/printcap S.5....T c /etc/yum/yum-updatesd.conf S.5..... c /etc/ldap.conf S.5..... c /etc/openldap/ldap.conf
According to http://www.rpm.org/max-rpm/s1-rpm-verify-output.html many config files do not verify successfully (and I recognize some of them from modifying them manually, and others presumably could have been modified by the hosting company).
I don't have a backup since there is no data stored only on the machine, so if anything is lost on the machine I just ask the host to re-format it and then re-upload everything.
Anywhere else that the logs would contain useful data?
/root/.bash_history might be interesting. Obviously this would be after the fact, but maybe they are trying to repeat the exploit with this machine as a base.
Good idea but it only shows the commands that I've run since logging in to try and find out what happened. Perhaps the attacker wiped /root/.bash_history after getting in.