“Shift left” is a simple term for a challenging task. The idea is that you move application quality and security considerations closer to the developer (that is, to the “left” of the delivery chain) so that potential issues are avoided or resolved sooner, even before code is committed.
The advent of the cloud has no doubt, contributed to code efficiency. In fact, with frameworks, such as Amazon Web Services (AWS) Lambda or Microsoft Azure Functions, are invoked as a cloud service by applications running on the same cloud, in a different cloud or in an on-premises environment.
Subsequently, cloud computing frameworks shrink the amount of code that needs to be protected within an application. Most cloud computing Regardless of the cloud computing framework invoked.
However, the paradox that cloud computing frameworks creates from a cybersecurity perspective is that they “shift” the size of the overall attack surface that needs to be defended over to the combinatorial connections now added to the application that need to be secured.
Hence, on one hand, Cloud computing frameworks can reduce sharply the amount of code that needs to secure within any application. Instead of writing a lot of extra code to address seldom-needed requirements, developers can write a function to invoke a feature running on an external Cloud computing framework. Conversely, this same framework requires cybersecurity teams to extend their workflows to address a framework most of them aren’t familiar with in terms of how this environment operates.
For example, application programming interface (API) calls made over HTTP APIs, message queues, cloud storage and communications involving the internet of things (IoT) devices all need to be secured.
Although Cloud service providers will make sure the serverless computing frameworks they provide are secure. However, it’s the responsibility of the IT organizations that invoke those services to make sure the code being deployed is secure. That “shared responsibility” approach to cloud security is not necessarily a new idea. However, because cloud functions involve small amounts of code written by the developer, it’s easy for them to overlook the cybersecurity implications of relying on a serverless computing framework.
Of course, if an IT organization decides to deploy its own private cloud computing framework, then the responsibility for securing that framework and the infrastructure it runs on naturally falls to the internal cybersecurity team.
Cloud Computing Exposures
Organizations continue to adopt cloud computing at a rapid pace to benefit from the promise of increased efficiency, better scalability, and improved agility. While cloud service providers like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) continue to expand security services to protect their evolving cloud platforms, it is ultimately the customers’ responsibility to secure their data within these cloud environments.
The 2019 Cloud Security Report (Cybersecurity Insiders, the 400,000 members responding to the evolving security threats in the cloud) highlights what is and what is not working for security operations teams in securing their cloud data, systems, and services in this shared responsibility model. The results are a continuation of past challenges:
Insecure interfaces and APIs take the number one spot in this year’s survey as the single biggest perceived vulnerability to cloud security (57%). This is followed by misconfiguration of the cloud platform (48%), and unauthorized access through misuse of employee credentials and improper access controls (46%). With honorable mentions of External Sharing (34%), Hijacking (32%), Malicious Insiders (31%), and Denial of Service attacks (28%).
Much of these are probably no real surprise, for they already exist in the top 10 list for Enterprise Security. However, there is one that is almost exclusive to the Cloud Architecture, Misconfigurations. Remember the aforementioned statement that,
“framework requires cybersecurity teams to extend their workflows to address a framework most of them aren’t familiar with in terms of how this environment operates.”
MISCONFIGURATIONS:
Just like any other IT service, the most likely way any cloud computing framework is likely to be compromised is because settings have been misconfigured in a way that makes the framework easily accessible.
DON’T TAKE OUR WORD FOR IT...
The sensitive nature of the data made the security breach more damaging because the data could be used for exploitation or more destructive attacks. The breach was the result of a misconfiguration for an Amazon AWS S3 storage bucket that was configured to be public and anonymously accessible.
A FedEx breach that exposed 119,000 scanned documents due to FedEx’s failure to audit the cloud assets of a company it acquired. Thousands of FedEx (NYSE:FDX) customers’ private information was exposed after the company left scanned passports, driver’s licenses and other personal documentation on a publicly accessible server.
The incident was first discovered by researchers at a German-based security center called Kromtech earlier this month. According to the security firm, the server belonged to Bongo International, a company that helped customers with shipping calculations and currency translations. FedEx purchased Bongo in 2014 but renamed the company FedEx Cross-Border International a year later before discontinuing the service in April 2017. More than 119,000 scanned documents dated from 2009 to 2012 were on the Amazon S3 server, Kromtech said it had discovered. Kromtech said it was unclear if FedEx was aware of the server’s existence when it purchased the company four years ago.
Deep Root Analytics left a cloud storage server unsecure, exposing the information of 198 million US voter. Anyone with an internet connection was able to access a huge database of personal information on US voters ahead of 2016 elections, a security firm says. The database helped the Republican Party's presidential campaign.
Chris Vickery, a researcher at the consultancy Upguard, discovered a misconfigured database containing information on almost every registered US voter compiled by data analytics company Deep Root Analytics.
The information was used by the Republican National Committee to help win the 2016 presidential race. The database contained "names, dates of birth, home addresses, phone numbers, and voter registration details," as well as data described as predicted data about voter behavior on policy preferences and likelihood of choosing a particular candidate.
Upguard said the database "lacked any protection against access" and was available to "anyone with an internet connection.
It described it as "a treasure trove of political data and modeled preferences used by the Trump campaign." It said the information was used to help influence potential voters and accurately predict their behavior.
An unsecured AWS S3 bucket at Patient Home Monitoring Corporation left 150,000 patient records unprotected.
Kromtech Security researchers have discovered yet another unsecured Amazon S3 bucket. This time, the cloud server in question was linked to HIPAA-covered entity, Patient Home Monitoring, a vendor that provides U.S. patients with disease management services and in-home monitoring.
The misconfigured server contained the lab results and other patient files of about 150,000 patients. The files were stored on a publicly accessible bucket that was left unprotected by a password, according to researchers.
In total, the breach contained 47.5 GBs of data comprised of about 316,000 PDF files, which contained patient names, addresses, phone numbers, diagnoses and test results. The files also contained physician names, case management notes and other patient information.
“Anyone with an internet connection could access these confidential records,” said Alex Kernishniuk, vice president of Strategic Alliances for Kromtech, in a statement.
Kromtech researchers first discovered the breach on Sept. 29, and PHM was notified on Oct. 5. The company secured the server on the same day. However, the company did not respond to Kromtech’s inquiries.
“It is unclear how they will notify their clients and inform them that their confidential data has been leaked online,” the researchers wrote. “Dealing with any form of medical data is risky and it is required by law to notify affected patients of a data breach.”
“This is yet another wake-up call for companies who try to bridge the gap between healthcare and technology to make sure cybersecurity is also a part of their business model,” said Kernishniuk. “Even the most basic security measures would have prevented this data breach.”
Kernishniuk said he believes this won’t be the last AWS breach. In fact, this latest breach is the second major AWS server breach announced this week. Accenture left four of its AWS buckets unprotected due to a misconfiguration error, exposing hundreds of gigabytes of data.
SO HOW PRONOUNCED IS THIS ISSUE?
So, assuming that the concern for misconfigurations is warranted? How does this manifest? First, if the cloud has any crucible building block, it’s containers, I.e., docker, Kubernetes. Subsequently, we shouldn’t be surprised that these items are a major avenue to breaches in the cloud. Even CIS agrees, for the usually brief guidelines, the CIS benchmarks for containers is a very LONG LIST.
Now with that said, it should be no surprise that fancy exploits, although great for headlines, aren’t the predominate issue with cloud security, it’s the aforementioned misconfigurations.
We as a security conscious professional are used to taking strong measures to protect user data, but are severely wanting in the area of protecting our S3 buckets.
An Amazon S3 bucket is a public cloud storage resource available in Amazon Web Services' (AWS) Simple Storage Service (S3), an object storage offering. Amazon S3 buckets, which are similar to file folders, store objects, which consist of data and its descriptive metadata
So, who wants to hack S3 buckets? The answer, EVERYONE! There are even hackers publicly
The Tesla’s AWS Hack:
Monero miners infiltrated a Kubernetes console which wasn’t password protected. Within one Kubernetes pod, access credentials were exposed to Tesla’s AWS environment. This contained an Amazon S3 bucket that had sensitive data such as telemetry. Fortunately, the hackers were not interested in anything but Monero.
Monero Mining: In the previous example, suppose Carl sends $100 to Ava via bank transfer. In this scenario, it is the bank’s job to make sure that Carl has enough balance to make the $100 payment to Ava. After the bank confirms this transaction, they make a record of it so that it can be referred to in the future. Now, if Carl were to send the $100 to Ava using Monero, then who would validate and record this transaction? The answer is: Monero miners! This removes the need for banks to confirm transactions.
The hackers hid their IP address behind CloudFlare and their mining software was configured to listen on a non-standard port. Additionally, they configured their mining software to keep their CPU usage low to not draw attention.
Lesson Learned:
- Secure your Kubernetes with passwords
- Update and Secure Configurations (defaults aren’t enough)
- Monitor Network traffic (Kubernetes can be a gateway to your S3!) traffic policies can be enforced with tools like istio which is an open source centralized traffic monitoring and enforcement tool.
One thing that seems to be symptomatic from Silicon Valley is that – they wait for things to become
mainstream before they instill security. Specifically, products are delivered with defaults that have no protection,
 |
| From the Kubernetes Guide to "Securing a Cluster" |
The kubelet is the primary “node agent” that runs on each node. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy.
Unauthenticated API requests. So, anyone can interject from other entities, and kublet will think it’s coming from the Kubernetes API server (get the exposure here?).
This was identified to Kubernetes – asking whether there is a CVE for this. However, Kubernetes said, “This is as a misconfiguration not a CVE”. This is why this issue has been around since 2015!!!!! no one knows about it!!!
OPEN SHODAN-AME!
Another ridiculous example of default mishap - is the use of something as simple as Shodan, a search engine for devices and services can easily request something like Kubernetes Masters and it will show all the info needed to begin Kubernetes exploits!
What is really concerning about the practice of default complacency is the look up of etcd which shows 2417 etcd servers exposed to the internet!!!
So, what is the big deal? Simply put:
2379/TCP Etcd Port
The HTTP service on 2379/TCP is the default etcd service for your Kubernetes instance. The API interface is accessible and not secured by default!!!!
It’ll leak internal passwords, AWS keys, certificates, private keys, encryption keys and more...
___________________________________________
We would like to thank our sponsors, for without them - our fine content wouldn't be deliverable!
- https://www.business2community.com/cybersecurity/10-cybersecurity-trends-in-2020-you-need-to-keep-an-eye-on-02275883
- https://cdn2.hubspot.net/hubfs/4846674/A%20Comprehensive%20Guide%20to%20Preventing%20Cloud%20Misconfiguration%20%5BeBook%5D.pdf
- https://www.cwps.com/blog/cloud-computing-security-issues
- https://go.netskope.com/rs/665-KFP-612/images/2019-Cloud-Security-Report.pdf
- https://www.bitdegree.org/tutorials/monero-mining/
- https://istio.io/docs/concepts/what-is-istio/
- https://www.quora.com/What-is-Kubelet-in-Kubernetes
- https://www.shodan.io/search?query=etcd
So “Once more unto the breach, dear friends, once more;”
____________________________________________________________
About Rick Ricker
An IT professional with over 23 years experience in Information Security, wireless broadband, network and Infrastructure design, development, and support.
For more information, contact Rick at rwricker@gmail.com
For more information, contact Rick at rwricker@gmail.com
No comments:
Post a Comment
Thanks for your input, your ideas, critiques, suggestions are always welcome...
- Wasabi Roll Staff