Protecting public clouds from common vulnerabilities

[harlan4096]

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.
...

Continue Reading