This post describes a scenario-based security incident that can have significant financial impact on a business operating a cloud environment, and portrays the development practices that could enable such an incident to occur with considerations for how to reduce the risks of this type of incident by appropriately applying secure development practices and security practices around the use of cloud services and web-based tools.
The Developer (Attack Victim)
You, as a developer, have credentials, an access key, given to you for systems access or to connect services with authenticated sessions in your Amazon AWS environment.
In the interest of time, and due to a lack of capabilities offered to encrypt or manage the credentials in your code, you hard code the access key into your application or service.
Next, one of two things happens. You either commit your code to your own GitHub account repository, failing to realize that you have committed to a public repo, or your Github account has been compromised with a breached-password exploit.
An attacker uses breached credentials to access your Github account, or leverages bots and scripts to perform GitHub Dorking to identify and scrape passwords and access keys from public GitHub repositories - searching for embedded credentials, just like the ones you posted, and discovers your Amazon AWS access key.
The attacker leverages the key to access AWS, and determines the extent of privileges provided by the access key and discovers she has administrative privileged access to the Amazon AWS account. The attacker spins up massive amounts of infrastructure, consuming large amounts of compute resources to support spamming efforts, distributed denial of service (DDOS) campaigns, and to perform bitcoin mining. The attacker also has the ability to access all information within your AWS environment with these privileges, including intellectual property and client sensitive data.
Amazon bills their customers on the compute and bandwidth resources consumed, and alerts on consumption spikes only if the environment is configured to do so (which is not set by default).
AWS is designed to be scalable, and scales according to the attacker’s provisioned resources. Unless alerting has been configured according to the standard practices of the support team, the business can remain unaware of the changes until the bill arrives.
The drastic resource consumption caused by the attacker has caused Amazon to bill the business well over $100,000 for a bill that is usually under $3,000.
Credential Protection and Information Flow Failure
The use of a public repository is caused, in this incident, by an engineer or developer mistakenly posting credentials to a public repository. Lack of business oversight for cloud services like GitHub, with consideration for the controls to protect sensitive data like credentials, has allowed hard-coded credentials (a poor practice anyway) to be committed to a non-private repo.
Engineers and developers should ensure that all application services like GitHub are authorized, approved for use and managed by their support team. Businesses should ensure cloud services are configured appropriately to prevent inadvertent exposure of sensitive data - credentials, intellectual property, client sensitive data. Establish policies, procedures, and technical controls to restrict and manage the use of public code repositories.
Use and Provisioning of Excessive Privileges
Use of excessive privileges for the account discovered in this scenario allowed the attacker to take control as an admin level privileged user of the Amazon AWS environment. The attacker had access and ability to modify existing infrastructure, add new infrastructure, scale the environment, and also access data sets within the environment.
Principles of least privilege should be applied to ensure specific access rights are defined and provided for appropriate user and service account access provisioning. Similarly, to user accounts, keys or tokens for non-user service accounts should be configured to the least amount of access possible, permitting only those privileges necessary for the account to perform its intended function. In this scenario, excessive privileges were granted to connect non-user interactive services.
Poor Development Practices
Code sanitization and secure code review procedures were not available as an aspect of code review and/or quality assurance processes. There was no process or capability to identify sensitive data, such as hard-coded credentials, and other sensitive production data, prior to committing that data to cloud repositories – especially those repositories that are public.
Expand code review and quality assurance processes beyond functional testing to include code sanitization, sensitive data removal, and review for security flaws.
Monitoring and Alerting Control Gaps
Inadequate resource usage alerting and monitoring allowed for usage changes within an AWS environment to go unnoticed until that usage is billed. This lack of visibility allowed unauthorized changes and access to go undetected until well after the modifications and malicious access occur.
Ensure controls like threshold alerting are applied when establishing cloud infrastructure and services. Establish processes and standards to configure alerting and monitoring thresholds and control mechanisms as part of a standard template-ized approach for cloud infrastructure and services deployment.
Use of Hard Coded Credentials
There are significant risks associated with software and solutions containing hard-coded credentials, such as a password or cryptographic key, which can be used for inbound authentication, outbound communication to external components, or encryption of internal data. Hard-coded credentials can create significant exposure that allows an attacker to bypass the authentication controls that are designed to keep unauthorized users out of a controlled computing environment.
Establish policy and guidelines for developers to restrict the use of hard-code credentials as a practice. Guidance should assist developers in determining appropriate mechanisms and platform features to utilize in order to apply alternatives to hard-coding credentials. Develop solutions and practices during code review and quality assurance processes to ensure use of hard-coded credentials is identified and sanitized to reduce the risk of exposing them in public code repositories.
Poor security practices during development in combination with decisions made by development and support staff who have not been trained in security concepts can expose an organizations computing environment or sensitive data sets and has the potential lead to hefty cloud resource charges or even a breach that could impact an organizations ability to operate. As the trend continues toward the use of cloud computing, organizations need to strongly consider the security implications and understand that moving to the cloud does not eliminate a business’s responsibility to operate securely. Organizations need to take careful consideration of the shared security responsibilities of operating in the cloud, and maintain ownership of those areas that fall outside the purview of cloud service providers.
To learn what should be done for your organization’s security, click below to assess with experienced and innovative CyberSheath security professionals.