Protecting public clouds from common vulnerabilities
Credit to Author: Andrey Pozhogin| Date: Wed, 09 Oct 2019 20:04:50 +0000
Many businesses already utilize a cloud environment that consists of on-premises private cloud and public cloud resources — a hybrid cloud. However, when it comes to cybersecurity, companies tend to focus more on protection of physical or virtualized environments, paying much less attention to the part of their infrastructure that resides in public clouds. Some of them are sure that cloud providers should be responsible for the protection; some think that public clouds are secure by design, and so not requiring any additional protection. But both those hypothesis are erroneous: public clouds are as much prone to software vulnerability exploitation, update repo poisoning, network connection exploitation, and account information compromise as the rest of your infrastructure. And here is why.
Vulnerabilities of RDP and SSH
RDP is on by default on Amazon instances, and it does not support second factor authentication by design. RDP has become the target for many different tools for bruteforce attacks. Some of them concentrate on several most common default usernames (like “Administrator”) and makes thousands of guess attempts. Others try to guess unique login name of the administrator by using most common surnames and common passwords. Brute-forcing algorithms can limit and randomize the number of attempts, with a time-out between sets of attempts, to avoid automated detection. Another method of attack is to brute-force the password for the SSM-User login that is often programmed into AWS instances.
Similar brute-force attempts target SSH services all the time, and though SSH does offer greater protection than RDP (e.g., second-factor authentication), a carelessly configured service can readily provide access to a persistent malicious actor. Brute-force attacks on SSH and RDP made up 12% of all attacks on Kaspersky’s IoT honeypots during the first half of 2019.
Vulnerabilities in third-party software
Public clouds can and do expose you to vulnerabilities. Here are a few examples of how a vulnerability in third-party software offers an attacker the chance to execute code on the instance itself.
On June 3, 2019, a vulnerability was discovered in Exim, a popular e-mail server commonly deployed in public clouds. The vulnerability allowed for remote-code execution. If the server was run as root, as is most commonly the case, malignant code introduced onto the server would then be executed with root privileges. Another Exim vulnerability, identified in July of 2019, also allowed remote-code execution as root.
Another example is the 2016 hack of the official Linux Mint website, which resulted in distros being altered to include malware incorporating an IRC backdoor with DDOS functionality. The malware could also be used to drop malicious payloads onto infected machines. Other reported cases involved malicious node.js modules, infected containers in the Docker Hub, and more.
How to reduce risk
Cybercriminals can be very inventive when it comes to finding entry points into infrastructures, especially where there are many such infrastructures, all very similar and with similar issues, and all conveniently believed to be highly secure by design. To reduce and manage the risk much more effectively, protect operating systems on your cloud instances and virtual machines. Basic antivirus and antimalware protection are clearly not enough. Industry best practices dictate that every operating system in an infrastructure needs comprehensive, multilayered protection, and public cloud providers make similar recommendations.
That is where a security solution such as Kaspersky Hybrid Cloud Security comes in. Our solution protects the various types of workloads running on different platforms, using multiple layers of security technologies including system hardening, exploit prevention, file-integrity monitoring, a network attack blocker, static and behavioral antimalware, and more. You can learn more about our solution here.