コーダーがセキュリティインフラストラクチャを征服するコードシリーズ:無効化されたセキュリティ機能

Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.

There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.

So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.

Let's get started.

There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.

Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.

Let me pose a challenge before we dive in:

Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).

How did you do? If you still have some work to do, read on:

Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.

Why disabled security features are so dangerous

Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.

Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.

Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.

As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.

Lets compare some real-world code; check out these CloudFormation snippets:

Vulnerable:

CorporateBucket:
   Type: AWS::S3::Bucket
   Properties:
     PublicAccessBlockConfiguration:
       BlockPublicAcls: false
       BlockPublicPolicy: false
       IgnorePublicAcls: false
       RestrictPublicBuckets: false
     VersioningConfiguration:
       Status: Enabled
     BucketEncryption:
       ServerSideEncryptionConfiguration:
         - ServerSideEncryptionByDefault:
             SSEAlgorithm: "AES256"

Secure:

CorporateBucket:
   Type: AWS::S3::Bucket
   Properties:
     PublicAccessBlockConfiguration:
       BlockPublicAcls: true
       BlockPublicPolicy: true
       IgnorePublicAcls: true
       RestrictPublicBuckets: true
     VersioningConfiguration:
       Status: Enabled
     BucketEncryption:
       ServerSideEncryptionConfiguration:
         - ServerSideEncryptionByDefault:
             SSEAlgorithm: "AES256"

Preventing disabled security features

Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.

If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.

Learn more, challenge yourself:

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws and vulnerabilities.

Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.

This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!