JAnttila
07-08-2009, 04:22 PM
Alert!
There has been recent posting on various security message boards in regards to a remote SSH exploit that allows attackers to gain full access to hosts where other tools can then be used to gain 'root' level access. The information related to the exploit at this time is very limited and from what we have gathered that all versions of OpenSSH older then 5.2 are susceptible to this attack.
We are still investigating the details to locate the source code of the exploit and to find out all exploitable versions. Once we have full details a hotfix or details on how to work around the exploit will be released.
This will only affect hosts using OpenSSH and appears to be at this time related to hosts using OpenSSH on Linux. I have not see any reports of this affecting hosts running Solaris or *BSD.
At this time we are recommending that you upgrade any version of OpenSSH that is running on virtual machines that are publicly accessible. This includes all Linux VDS type appliances or any other Linux based appliance vm that is connected to the outside internet with a 'IN' type gateway and allows 'ssh / port 22 tcp' traffic through it.
Details of the exploit:
http://isc.sans.org/diary.html?storyid=6742
http://www.securityaegis.com/?p=445
http://romeo.copyandpaste.info/txt/nowayout.txt
Possible work around:
OpenSSH: 'authorized users':
1. Open the file /etc/sshd_config in your favorite Terminal text editor vi /etc/sshd_config .
2. Add the following line to the end of this file:
AllowUsers username1 username2
Replace username1 and username2 with the short usernames of those users who will be able to log in via ssh. You can add as many as you want, separated by spaces.
3. Restart the ssh daemon (or, as I did, the computer).
OpenSSH: iptables firewall rules:
Add a rule similar to the following and then 'iptables-save' to save the changes.
iptables -A INPUT -p tcp --dport 22 --source IP.AD.DR.ESS -j ACCEPT
to allow for localhost
iptables -A INPUT -p tcp --dport 22 --source 127.0.0.0/8 -j ACCEPT
or for a remote IP range:
iptables -A INPUT -p tcp --dport 22 --source 192.168.0.0/24 -j ACCEPT
OpenSSH: tcp wrappers:
Review the following pages and keep in mind that most any tcp service that is running on the host will also need to be listed in the hosts.allow so that remote hosts will be able access the host.
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-tcpwrappers-access.html
OpenSSH: disable root logins and password based logins.
Disable Direct Root Login
Allowing the root user to login directly is a major security issue, we'll show you how to disable it so you can still login as root but just not directly, reducing the security issue.
This will force a hacker to have to guess 2 separate passwords to gain root access.
(you do have 2 seperate passwords for admin and root right?)
What happens is you'll first need to login as your admin user in SSH, then switch to the super user with the su command to get root.
We also will be forcing the use of SSH protocol 2, which is a newer, more secure SSH protocol
Just a couple more ways to help your server stay safe from the bad guys. If you're using cPanel make sure you add your admin user to the 'wheel' group so that you will be able to 'su -' to root, otherwise you may lock yourself out of root.
1: SSH into your server as root for the last time or as a non-root user and gain root access by su
2: Copy and paste this line to edit the file for SSH logins
vi /etc/ssh/sshd_config
3: Find the line
Protocol 2, 1
4: Un-comment it and change it to look like
Protocol 2
5: Next, find the line
PermitRootLogin yes
6: Un-comment it and make it look like
PermitRootLogin no
8: Consider adding a set of 'AllowUsers' as mentioned above'
9: Save the file 'esc then :wq'
10. Now you can restart SSH
/etc/rc.d/init.d/sshd restart
or
service sshd restart
11: Test your logins now!. i
Now, no one will be able to login to root with out first loggin in as admin and 'su -' to root, and you will be forcing the use of a more secure protocol. Just make sure you remember both passwords!
# End of possible work around.
We will post more details as they become available and any hotfixes or upgrade processes if needed.
Thanks,
Jeremy
There has been recent posting on various security message boards in regards to a remote SSH exploit that allows attackers to gain full access to hosts where other tools can then be used to gain 'root' level access. The information related to the exploit at this time is very limited and from what we have gathered that all versions of OpenSSH older then 5.2 are susceptible to this attack.
We are still investigating the details to locate the source code of the exploit and to find out all exploitable versions. Once we have full details a hotfix or details on how to work around the exploit will be released.
This will only affect hosts using OpenSSH and appears to be at this time related to hosts using OpenSSH on Linux. I have not see any reports of this affecting hosts running Solaris or *BSD.
At this time we are recommending that you upgrade any version of OpenSSH that is running on virtual machines that are publicly accessible. This includes all Linux VDS type appliances or any other Linux based appliance vm that is connected to the outside internet with a 'IN' type gateway and allows 'ssh / port 22 tcp' traffic through it.
Details of the exploit:
http://isc.sans.org/diary.html?storyid=6742
http://www.securityaegis.com/?p=445
http://romeo.copyandpaste.info/txt/nowayout.txt
Possible work around:
OpenSSH: 'authorized users':
1. Open the file /etc/sshd_config in your favorite Terminal text editor vi /etc/sshd_config .
2. Add the following line to the end of this file:
AllowUsers username1 username2
Replace username1 and username2 with the short usernames of those users who will be able to log in via ssh. You can add as many as you want, separated by spaces.
3. Restart the ssh daemon (or, as I did, the computer).
OpenSSH: iptables firewall rules:
Add a rule similar to the following and then 'iptables-save' to save the changes.
iptables -A INPUT -p tcp --dport 22 --source IP.AD.DR.ESS -j ACCEPT
to allow for localhost
iptables -A INPUT -p tcp --dport 22 --source 127.0.0.0/8 -j ACCEPT
or for a remote IP range:
iptables -A INPUT -p tcp --dport 22 --source 192.168.0.0/24 -j ACCEPT
OpenSSH: tcp wrappers:
Review the following pages and keep in mind that most any tcp service that is running on the host will also need to be listed in the hosts.allow so that remote hosts will be able access the host.
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-tcpwrappers-access.html
OpenSSH: disable root logins and password based logins.
Disable Direct Root Login
Allowing the root user to login directly is a major security issue, we'll show you how to disable it so you can still login as root but just not directly, reducing the security issue.
This will force a hacker to have to guess 2 separate passwords to gain root access.
(you do have 2 seperate passwords for admin and root right?)
What happens is you'll first need to login as your admin user in SSH, then switch to the super user with the su command to get root.
We also will be forcing the use of SSH protocol 2, which is a newer, more secure SSH protocol
Just a couple more ways to help your server stay safe from the bad guys. If you're using cPanel make sure you add your admin user to the 'wheel' group so that you will be able to 'su -' to root, otherwise you may lock yourself out of root.
1: SSH into your server as root for the last time or as a non-root user and gain root access by su
2: Copy and paste this line to edit the file for SSH logins
vi /etc/ssh/sshd_config
3: Find the line
Protocol 2, 1
4: Un-comment it and change it to look like
Protocol 2
5: Next, find the line
PermitRootLogin yes
6: Un-comment it and make it look like
PermitRootLogin no
8: Consider adding a set of 'AllowUsers' as mentioned above'
9: Save the file 'esc then :wq'
10. Now you can restart SSH
/etc/rc.d/init.d/sshd restart
or
service sshd restart
11: Test your logins now!. i
Now, no one will be able to login to root with out first loggin in as admin and 'su -' to root, and you will be forcing the use of a more secure protocol. Just make sure you remember both passwords!
# End of possible work around.
We will post more details as they become available and any hotfixes or upgrade processes if needed.
Thanks,
Jeremy