A new piece of research from security providers Stratsec has inferred that some cloud providers are unable to block malicious attacks, which could lead to cyber hackers being able to infiltrate systems in a botnet-styled attack.
As a result, according to the research at the Stratsec Winter School, there was an alarming number of reasons why attacking cloud systems was a good idea, such as being relatively easy to set up, costing less, and taking significantly less time to build.
Instead of a traditional botnet setup whereby an attacker would need to know various programming languages in order to hack into a system, in order to set up a botCloud – defined by Stratsec as a group of cloud instances controlled by malicious entities to initiate cyber-security attacks – the attacker only needs to know the cloud provider’s API and requisite sysadmin knowledge.
Worryingly, the researchers stated that based on their experiment, $7 and the ‘minimum hardware specification’ was all that was needed to set up a working botCloud.
The research focused on five “common” cloud providers and involved attacking target hosts, set up in a controlled network environment and given standard public network services, such as Web, FTP and SMTP, through the basic methods in which security companies check systems.
These included malware traffic, denial of service attacks, brute force hacks on passwords, web app attacks such as SQL injection and cross-site scripting, and malformed traffic.
There were four separate experiments carried out by the researchers. One set out to prove how a cloud provider would respond to outbound malicious traffic coming from its network, with another testing if the provider would detect an attack sent over its own internal network.
Another experiment was essentially a repeat of the first, but increasing the duration of the test case execution, checking whether a provider would respond differently if the parameters were increased.
The results showed that none of the cloud providers generated warning emails, phone calls or alerts, and that only one blocked by default inbound and outbound traffic on FTP, SMTP and SSH – but it was only a temporary fix, as running the tests again on a non-default port bypassed the block.
Similarly, there was no connection reset or connection termination against outbound or inbound network traffic, or the internal malicious traffic, nor was there any traffic throttled or rate limited.
So what should companies moving to the cloud do?
Stratsec issued a series of quick tips for companies looking to move to the cloud:
- Look for security features like high-end firewalls and IDS when choosing a cloud provider
- Ensure the provider undertakes regular, independent, security testing – consider how their security model fits in with your enterprise security architecture
- The traffic from public cloud providers is not always safe, so be aware of a botCloud attack
- Remember the services you wish to host and consider that in your choice of provider – “do not get tempted with ease of use and cheap cost”
This isn’t the best news for the cloud, but is it a case of simply performing due diligence before choosing a cloud provider to avoid situations like this?