Does anyone know if openssh 4.3p2-72.el5_6.3 has any know exploits? I had an intrusion on two servers today and it appears they used an ssh exploit

What kind of intrusion? What are the symptoms?

Well I logged in to server 2 and noticed a strange folder in root home directory. It was created literally minutes before I logged in. I looked inside and it was basically a bunch of scripts used for scanning the network. I noticed a pass_file and another file full of IPs from my servers' network. I checked the process list and noticed not only two active processes of the ss commmand running but also another user logged on as root to tty0 ( I was on tty1). I then checked the security logs and it shows numerous attempts from several IPs to access this server via ssh probably a brute force attack as they were using a long list of usernames. Finally I saw a successful login from an IP that had failed several times before the intrusion. Once I killed the processes and his terminal, he logged back in and deleted the scripts before I could save them off. I check the server for modified files and they edited not only my yum.conf to exclude updates for openssh but also tampered with my iptables. They also installed several rpms:

Jun 16 18:11:35 Installed: keyutils-libs-devel-1.2-1.el5.i386
Jun 16 18:11:36 Installed: e2fsprogs-devel-1.39-23.el5_5.1.i386
Jun 16 18:11:36 Installed: libsepol-devel-1.15.2-3.el5.i386
Jun 16 18:11:36 Installed: libselinux-devel-1.33.4-5.7.el5.i386
Jun 16 18:11:36 Installed: pam-devel-0.99.6.2-6.el5_5.2.i386
Jun 16 18:11:37 Installed: krb5-devel-1.6.1-55.el5_6.1.i386
Jun 16 18:12:30 Installed: openssl-devel-0.9.8e-12.el5_5.7.i386

I also noticed in the .mysql_history they logged into mysql to check for any useful info there.

They did some similar rpm installs on the first server they logged into and I assume got access to the second one because the two are linked together. Im not really sure at this point if it was an exploit or more of just a brute force attack. I had a medium 8 character password with numbers and letters so I am not sure how it was cracked but anything is possible.

I have already reported the offending IP to ISP owner and they have already suspended the account so they say. I really just wanted to warn everyone to be careful as I said they were scanning for other hosts on the network to possibly attack.

Use ssh keys not passwords, passwords are inherently less secure.

Another way to reduce attack attempts is to rate limit new ssh connections via iptables.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

Also, make sure to revert your yum config and upgrade. It would also be good to not use port 22 for ssh. People will target 22 first since it's the default for ssh.

It may also be a good idea to create a script to pull out suspucious stuff from your logs (namely audit, ssh, lastlog, web server, and any other software accessible from the outside or that might be good targets if they get in) and put it into a file (or group of files) hidden in your filesystem with 000 permissions. You can run it via cron and if something strange happens, you can easily kill their connection, remove them from the authorized keys, and delete any user they create (after grabbing stuff they used and putting it in an unprivileged user). After, you can grant read permissions on the logs to an unprivileged user and check them over. This isn't necessary since you can easily check the logs individually, but it would make it easier to check them over quickly.

Also since you were rooted best bet is to rebuild the server, you don't know what they could have done, preserve your log files for analysis though (however they could have been modified).

Try installing something like aide on a read only disk image and use it to scan for changed files in the future

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

BAH, that's non-sense. Use ssh keys and don't allow password authentication (as previously suggested) and stop using weak passwords, especially for your root account. Yes, an 8 character "medium" password is weak.

I don't know why people always recommend using keys and not passwords for SSH. With a proper configuration, and strong enough passwords, there's no risk at all in using them.

Choose a code of at least 8-10 characters with numbers, letters and symbols, change your SSH port and configure your server to limit the number of requests or, even better, use an intrusion prevention system that bans a client after a number of failed login attempts. This can be used also for other servers, such as FTP, POP/IMAP, etc.

Imagine that your server bann IP addresses after 5 attempts for 5 minutes. With a proper password of 8 characters (let's suppose we use numbers, uppercase and lowercase characters), there are (26 + 26 + 10)^8 possible passwords, this is:

218340105584896

On average, the bad guy will need to try half the number of possible combinations, this is 62^8/2. If the limit is 5 attempts per 5 minutes, it will take one minute per each. So 62^8/2 minutes are required, ON AVERAGE, to crack your password. Now, this is about 62^8/2880 days, or more or less 62^8/1051200 years, which is 207705580 years. And yes, 200 million years ago, there were dinosaurs on the Earth and you could walk from "Tokyo" to "New York"

I do run backups so I was able to restore from backup. I also restricted ssh access to only certain IP's with a rate limit. I also setup keys rather than using passwords. They really didnt get much done as they were logged on right when I was and I booted them off. Funny because they created an ssh key (which would allow them to logon in the future) among other things but they intrusion was so easy to detect with the trail of clues they left. Lesson learned and I would say a good experience in beefing up security.

There is risk involved in everything. The risk is magnitudes smaller for keys than it is for passwords (even strong passwords, which most are not).



People still use FTP?

People recommend keys because you don't have to send passwords across a network, so there's less of a chance of spying the password. Plus, if you have multiple ssh accounts, you can use the same key on each server instead of having to remember different passwords -- writing down passwords is a security risk in case someone finds it (if they see who dropped it or it includes a user name, that makes it easier to figure out), and having the same password on each machine is also a security risk (if they figure out one password, they've figured them all out). There's no guarantee that they will take 60+ million years to guess the password, they could get a lucky break and figure it out in a few tries using an automated program.

Changing the port is always a good idea, though not as important with keys. If someone finds an exploit to ssh to circumvent the keys, they can get in.

People still use ftp, e.g. the mirror hosted by GNU supports both HTTP and FTP, as do most other F\OSS mirrors.

If they knew your IP address, and they knew your username (and it isn't root), and they got your password in a few tries, my first guess would be that you've probably logged in from a compromised machine...

_________________

/* TODO: need to add signature to posts */

The major beef is with non-anonymous (that is, authenticated) FTP. If you're logging in with credentials that can't write to anything, you can't do too much damage with FTP.

Although, nowadays, I wonder how many people knowingly use FTP to access mirrors... HTTP kinda usurped anonymous FTP's role awhile back.

_________________

/* TODO: need to add signature to posts */

Can they break the encryption used by SSH?



The proper way of creating passwords is not writing them into a TXT file and saving it in "My documents". It's quite easy to generate them "on the fly"



Yes, and I could win the lottery 1000 times in a year.

It's more probable that someone breaks into your home and steals your computer where your have your key installed than guessing the password using a brute force attack.

Your implied point of SSH passwords only being sent within the encrypted stream is true, and while that largely negates the possibility of sniffing or traditional network "spying" being a risk, for someone in control of the network or with the ability to redirect the connection (say by cracking DNS or influencing a router/host along the path) passwords can still be an exposure.

While it's unlikely the stream could be decrypted, to someone with the right access, SSH streams are still susceptible to a MITM attack, at which point the receiver is going to see the password in the clear since it is terminating the SSH session.

-- David