Recently dealed with a SSH attack and want to share the experience with you.
The problem was reported to me by one of my customers, as they have seen a high traffic from one of their EBS R12 servers to their firewall , causing CPU saturation on the Firewall machine itself.
One of the interesting thing was, this EBS environment was fully open to the world, so all of its ports including ssh was publically available to the world :) Besides, the root password was a very simple one. In other words; the situation was an expected one :)
Anyways; when I logged into the EBS server, I directly saw that it was hacked, as the standard commands such as ps , lsof and netstat was not working, and also there were weird processes and files scattered on the system.
It seemed like the server is hacked from SSH using a brute force. The attacker should have been crack the root password then logged into system using the root account and deployed his/or her malwares to the filesystem(probably using scp). We actually approved this theory by seeing the nmap port scans and the ssh login attempts using the network monitor tools.
The name of the malware was dpkgd and it replaced the ss,ps,netstat and lsof binaries with his own copies , cleared the syslogd and directed the auth.log, audit.log and utx.laslogin to /dev/null) So it tried to leave no traces behind.
Actually, altough I didn't check this on my own, the malwares were used to create an RCP tunnel between the attacker and the system to make the system be under control and obey the attackers commands. Thus, the malwares could be used to do DOS attacks against the various servers which are available on internet. The attacker also reset the root password couple of times.
Not: the same attack and the affected files were also recorded in the blog post below; "https://blog.smarthoneypot.
The things that I ve did to clear and secure the system were,
The problem was reported to me by one of my customers, as they have seen a high traffic from one of their EBS R12 servers to their firewall , causing CPU saturation on the Firewall machine itself.
One of the interesting thing was, this EBS environment was fully open to the world, so all of its ports including ssh was publically available to the world :) Besides, the root password was a very simple one. In other words; the situation was an expected one :)
Anyways; when I logged into the EBS server, I directly saw that it was hacked, as the standard commands such as ps , lsof and netstat was not working, and also there were weird processes and files scattered on the system.
It seemed like the server is hacked from SSH using a brute force. The attacker should have been crack the root password then logged into system using the root account and deployed his/or her malwares to the filesystem(probably using scp). We actually approved this theory by seeing the nmap port scans and the ssh login attempts using the network monitor tools.
The name of the malware was dpkgd and it replaced the ss,ps,netstat and lsof binaries with his own copies , cleared the syslogd and directed the auth.log, audit.log and utx.laslogin to /dev/null) So it tried to leave no traces behind.
Actually, altough I didn't check this on my own, the malwares were used to create an RCP tunnel between the attacker and the system to make the system be under control and obey the attackers commands. Thus, the malwares could be used to do DOS attacks against the various servers which are available on internet. The attacker also reset the root password couple of times.
Not: the same attack and the affected files were also recorded in the blog post below; "https://blog.smarthoneypot.
The things that I ve did to clear and secure the system were,
- changed the root password
- found and deleted all the malware files
- cleared the malicious crontab entries
- deleted the log files which were directed to /dev/null and recreated them
- Recreated the affected standard programs like lsof,ps,ss and netstat by copying them from another unaffected system (from another machine, which have the same OS and arch (32 bit/64 bit) with the affected node)
- reinstalled the rsyslog
- rebooted the server and saw that eveything was come back to normal
- Requested the Network team to close all the port in the firewall, except the Oracle's HTTP listener active port, which was ssl. (also disabled the non-ssl port for the http server by implementing: "Enabling TLS in Oracle E-Business Suite Release 12.1 (Doc ID 376700.1)" - Section 6.2 Disabling the HTTP Port)
What should be do for the future? (In case, the SSH port will need to be opened )
- More secure passwords should be used.
- SSH should be configured to be serving from a non-default port.
- SSH should only accept specific Ip addresses which are included in a whitelist.
- User pass authentication, a more secure authentication mechanism should be used.
Recommend you to read this blog post, as well:
No comments :
Post a Comment
If you will ask a question, please don't comment here..
For your questions, please create an issue into my forum.
Forum Link: http://ermanarslan.blogspot.com.tr/p/forum.html
Register and create an issue in the related category.
I will support you from there.