Cloud Clustering Vulnerable to Attacks

The authors thank John Fokker and Marcelo CaroVargas for their contributions and insights.

In our upcoming talk at the Cloud Security Alliance Summit at the RSA Conference, we will focus our attention on the insecurity of cloud deployments. We are interested in whether attackers can use compromised cloud infrastructure as viable backup resources as well as for cryptocurrency mining and other illegitimate uses. The use of containers has increased rapidly, especially when it comes to managing the deployment of applications. Our latest market survey found that 83% of organizations worldwide are actively testing or using containers in production. Applications need authentication for load balancing, managing the network between containers, auto-scaling, etc. One solution (called a cluster manager) for the automated installation and orchestration of containers is Kubernetes.

Some key components in the Kubernetes architecture appear below:

High-level Kubernetes architecture.

  • Kubernetes master server: The managing machine oversees one or more nodes
  • Node: A client that runs tasks as delegated by the user and Kubernetes master server
  • Pod: An application (or part of an application) that runs on a node. The smallest unit that can be scheduled to be deployed. Not intended to live long.

For our article, we need to highlight the etcd storage on the master server. This database stores the configuration data of the cluster and represents the overall state of the cluster at a given time. Kubernetes saves these secrets in Base64 strings; before Version 2.1 there was no authentication in etcd.

With that knowledge, security researcher Giovanni Collazo from Puerto Rico started to query the Shodan database for etcd databases connected to the Internet. He discovered many and by executing a query, some of these databases started to reveal a lot of credentials. Beyond leaking credentials from databases and other accounts, what other scenarios are possible?

Leaking Credentials

There are several ways that we can acquire credentials for cloud services without hacking into panels or services. By “creatively” searching public sites and repositories, we can find plenty of them. For example, when we searched on GitHub, we found more than 380,000 results for certain credentials. Let’s assume that half of them are useful: We would have 190,000 potentially valid credentials. As Collazo did for etcd, one can also use the Shodan search engine to query for other databases. By creating the right query for Django databases, for example, we were able to identify more cloud credentials. Amazon’s security team proactively scans GitHub for AWS credentials and informs their customers if they find credentials.

Regarding Kubernetes: Leaked credentials, complete configurations of the DNS, load balancers, and service accounts offer several possible scenarios. These include exfiltrating data, rerouting traffic, or even creating malicious containers in different nodes (if the service accounts have enough privileges to execute changes in the master server).

Creating malicious containers.

One of the biggest risks concerning leaked credentials is the abuse of your cloud resources for cryptomining. The adversaries can order multiple servers under your account to start cryptomining, enriching their bank accounts while you pay for the computing power “you” ordered.

Open Buckets

We have heard a lot about incidents in which companies have not secured their Amazon S3 buckets. A number of tools can scan for “open” buckets and download the content. Attackers would be most interested in write-enabled rights on a bucket. For our Cloud Security Alliance keynote address at RSA, we created a list of Fortune 1000 companies and looked for readable buckets. We discovered quite a few. That is no surprise, but if you combine the read-only buckets information with the ease of harvesting credentials, the story changes. With open and writable buckets, the adversaries have plenty of opportunities: storing and injecting malware, exfiltrating and manipulating data, etc.

McAfee cloud researchers offer an audit tool that, among other things, verifies the rights of buckets. As we write this post, more than 1,200 writable buckets belonging to a multitude of companies, are accessible to the public. One of the largest ad networks in the world had a publicly writable bucket. If adversaries could access that network, they could easily inject malicious code into advertisements. (As part of our responsible disclosure process, we reported the issue, which was fixed within hours.) You can read an extensive post on McAfee cloud research and how the analysts exposed possible man-in-the-middle attacks leveraging writable buckets.

Clustering the Techniques

To combat ransomware, many organizations use the cloud to back up and protect their data. In our talk we will approach the cloud as an attack vector for spreading ransomware. With the leaked credentials we discovered from various sources, the open and writable buckets created a groundwork for storing and spreading our ransomware. With attackers having a multitude of credentials and storage places such as buckets, databases, and containers, defenders would have difficulty keeping up. We all need to pay attention to where we store our credentials and how well we monitor and secure our cloud environments.

The post Cloud Clustering Vulnerable to Attacks appeared first on McAfee Blogs.

Breaking 512-bit RSA with Amazon EC2 is a cinch. So why all the weak keys?

(credit: martinak15)

The cost and time required to break 512-bit RSA encryption keys has plummeted to an all-time low of just $75 and four hours using a recently published recipe that even computing novices can follow. But despite the ease and low cost, reliance on the weak keys to secure e-mails, secure-shell transactions, and other sensitive communications remains alarmingly high.

The technique, which uses Amazon's EC2 cloud computing service, is described in a paper published last week titled Factoring as a Service. It's the latest in a 16-year progression of attacks that have grown ever faster and cheaper. When 512-bit RSA keys were first factored in 1999, it took a supercomputer and hundreds of other computers seven months to carry out. Thanks to the edicts of Moore's Law – which holds that computing power doubles every 18 months or so – the factorization attack required just seven hours and $100 in March, when "FREAK," a then newly disclosed attack on HTTPS-protected websites with 512-bit keys, came to light.

In the seven months since FREAK's debut, websites have largely jettisoned the 1990s era cipher suite that made them susceptible to the factorization attack. And that was a good thing, since the factorization attack made it easy to obtain the secret key needed to cryptographically impersonate the webserver or to decipher encrypted traffic passing between the server and end users. But e-mail servers, by contrast, remain woefully less protected. According to the authors of last week's paper, the RSA_EXPORT cipher suite is used by an estimated 30.8 percent of e-mail services using the SMTP protocol, 13 percent of POP3S servers. and 12.6 percent of IMAP-based e-mail services.

Read 6 remaining paragraphs | Comments

Serious bug causes “quite a few” HTTPS sites to reveal their private keys

According to a security researcher for Linux distributer Red Hat, network hardware sold by several manufacturers failed to properly implement a widely used cryptographic standard, a data-leaking shortcoming that can allow adversaries to impersonate HTTPS-protected websites using the faulty equipment.

A nine-month scan that queried billions of HTTPS sessions from millions of IP addresses was able to obtain leaked data for 272 keys, reports Red Hat security researcher Florian Weimer in a research paper published this week. Because the scan surveyed only a very small percentage of the overall number of transport layer security protocol handshakes, many more keys and manufacturers are likely to be affected by the leakage. Vulnerable hardware includes load balancers from Citrix as well as devices from Hillstone Networks, Alteon/Nortel, Viprinet, QNO, ZyXEL, BEJY, and Fortinet.

The results of Weimer's nine-month scan.
Florian Weimer

Enter Chinese Remainder Theorem

The leakage is the result of insecure implementations of the RSA public key cryptosystem, which is one of several that HTTPS-protected websites can use to exchange keys with visitors. A 1996 research paper by researcher Arjen Lenstra warned that an optimization known as the Chinese Remainder Theorem sometimes causes faults to occur during the computation of an RSA signature. The errors cause HTTPS websites that use the perfect forward secrecy protocol to leak data that can be used to recover the site's private key using what's known as a side-channel attack.

Read 6 remaining paragraphs | Comments

Smartphone app for RSA security conference puts users at risk, researchers say

A screenshot showing redacted contents of a database included with the smartphone app for attendees of this week's RSA security conference in San Francisco.

After learning about a smartphone app dedicated solely to this week's RSA security conference in San Francisco, I publicly questioned why anyone would install it. After all, RSA's recently discovered history of either deliberately or unknowingly seeding its trusted products with dangerous code developed by the National Security Agency has left many people suspicious.

A day later, researchers have uncovered two vulnerabilities in the app that make it hard for me to resist the urge to say "I told you so." One of them discloses the name, surname, title, employer, and nationality of people who have installed the app, according to Gunter Ollmann, a researcher at security firm IOActive. For reasons unknown, the information resides in an SQLite database file that's bundled with the app. Opening it and reading the contents are trivial.

"I have no idea why the app developers chose to do that, but I'm pretty sure that the folks who downloaded and installed the application are unlikely to have thought that their details [were] being made public and published in this way," he wrote in a blog post published Wednesday morning. "Marketers love this kind of information though!"

Read 5 remaining paragraphs | Comments