How did they do this?

[Rick Garland]

Hi all:

Got RH 7.2 on Dell PE 1650 systems.
Running as a web server.

Just a short time ago I found evidence of unauthorized use. Another user acct had been created with UID=0, all of the log files had been deleted or null'ed, the wtmp file was null'ed, etc.

I had spent some time doing what I can to provide a minimum level of security. Some of the stuff I did - 1)enabled the use of the wheel group with the /etc/pam.d/su file, only members of wheel can become root 2)have the securetty setup for root logins only on console 3)the only ports open were 22 (ssh), 80 (http), 115 (sftp), & 443 (shttp), all other services were disabled from xinetd, 4)in the sshd_config file had the PermitRootLogin set to "no" 5)had the firewall config set to medium with only SSH and HTTP allowed.

With all of the above being setup and tested, how did somebody get in and create a UID=0 acct and start wreaking havoc?

Any ideas?

[Rick Garland]

One other item - I had 3 accts that were strictly sftp accts. These accts was setup and configured to use a chroot directory.

[Mark Grant]

Rick,

I can't see how this was done. The only area I would be suspicious of is the webserver itself if it runs as root, unless it was a local user. If it was a local user then there are a million ways it can be done. The best way, if you are a local user, obviously is to get root password. The majority of real attacks that mean anything in large organizations come from inside and use low tech methods to get in.

However, I would say that there is always going to be a risk, no matter what you do.

[Jerome Henry]

Is it possible that they had a physical access to the server ? If so, peace of cake (won't explain here how to...) :]
Otherwie, let's think...
J

[Jerome Henry · Accepted solution]

BTW, you serach for UID 0 connection, but it's much likely allowed connection and privilege escalation... What is your kernel, httpd and ssh version ? Several flaws allowed privilege escalations in kernel 2.49 (original rh 7.2), and quite recent ssh...

J

[Rick Garland]

Some version info:

ssh is 1.3
chroot has the 3.6.1 patch applied
httpd is 1.3
kernel is 2.4.7

[Jerome Henry]

Ok,

They (he ?) could have sniffed your root passwd using this :
http://www.secunia.com/advisories/8823/
This to exploit ssh :
http://www.ciac.org/ciac/bulletins/m-017.shtml
This on your kernel :
http://www.securityfocus.com/bid/3447
The list would be too long to put them all...

A good way round would be to update all strategic packages to a recent version. You did great job on security, but this can't prevent structural packages flaw...

J

[Steven E. Protter]

Take a look for backdoors.

Copies of the shell where it does not belong with suid set. That lets someone use root, merely by executing the shell.

Consultants commonly put such back doors in and they can be discovered.

Get tripwire working so that changes in the log files are tracked immediately.

You probably should run Bastille against the box, because it scans for vulnerabilities.

SEP

[Stuart Browne]

We had someone exploit one of our RH72 boxes about a year ago, using https.

It's now an up-to-date RH8 box, so.. ;)

Beware of some binary replacements.

At this point 'rpm -Va' is your friend.

Also be aware of the command 'lsattr', and the +i flag on files (immutable - nothing can be done until flag is removed).

These are common tricks (one of which I use myself :P).

[U.SivaKumar_2]

Hi ,

Use good forensic analysis tools like coroner's toolkit to analyse the compromised system . Use chkrootkit tool to check your system for commonly known rootkits.

Tripwire can be used to as a file integrity checker. But for this you must have taken tripwire checksum snapshot of your system , very earlier to compare with the present stae of the system. ( after complete fresh installation ).

I suggest you to port scan this compromised host checking the suspicious lisening ports.

If it is a remote exploit ( which is lanuched against a network service ) then the shellcode is almost sure to leave a backdoor port listening for the hacker to get in to system without efforts ;-).

You should not narrow your incident analysis only on network based attacks. A authentic unpriveleged user ( malicious ofcourse ) can launch local exploits , which can give him root shell easily.

There are other services other than daemons invoked by xinetd , like rpcd , nfsd etc which are very vulnerable. These services should stopped.

regards,

U.SivaKumar

[Gordon Morrison_1]

Just because you have disabled (direct) root logins doesn't prevent someone from logging in, then using su to gain root permissions.

I would suspect an inside job, then start looking at the logs from other hosts from which they could have logged into this one from. (I presume you know approximately when this happened?)

They wiped their fingerprints from the house they burgled, but did they wipe their footprints from the path outside?

[Rick Garland]

Hi Gordon:

I did have the PAM setup to only allow root logins to members of the wheel group. If this was an inside job, then this would have been done by a wheel group member.

Even if I gave out the root passwd to the world, if you are not a member of the wheel group you can not access the root account unless you are sitting at the console in a secure data center.

As to looking for outside footprints, there is no other access from other systems. Exception, members of the wheel group have access to the system from their local desktops but firewalls prevent access from any other server within the data center. Access to the system was gained from the outside via VPN, else you hit the URL in your web browser.

[Paul Cross_1]

check all suid files, not just shells. suid vi is common. vi /etc/passwd is very simple...

[Don_89]

I would run nessus against the box to point out vulnerabilities. Also, setup syslog to log to a different server so if it happens again, you'll at least have an IP address to track down..


Also, someone posted that the passwords were possibly sniffed. This isn't true if your using SSH..

[Rick Garland]

Hi all:

Its been over a year since this incident. I have upgraded all packages. No further incidents have occurred.

Many thanks to all the ideas. I am keeping track of each and every one of these ideas as my baseline for setting up new systems.

I must close this thread now.

Again, thanks

[Rick Garland]

Thanks to all!