“If everything seems under control, you’re not going fast enough.”

With the recent rise in cloud-native technologies, everything is going faster than ever. Development cycles are shorter than before, and teams are deploying to production continuously. Business demands and time-to-market are the main drivers in the need for speed, and as development teams try to keep up, the risks are much higher since a simple change can reach your entire customer base within minutes.

One of those cloud-native technologies is Infrastructure-as-Code (IaC) which automates the entire process of provisioning and deploying your infrastructure at the speed of DevOps. Beside the known benefits, this presents major risks to your applications and underlying infrastructure. It means that a single change in your IaC will reach production in a matter of minutes and can expose you to new attack vectors as well.

Based on recent research, which was done by analyzing vast number of KICS scans, here are the top IaC misconfigurations you should be aware of.

Top 5 Misconfigurations

1. Open ports – open TCP/UDP ports remain the top misconfiguration to date. Those include HTTP ports, SSH ports, ELB ports, or any other unnecessary ports. The best example to give here is SSH (port 22), which is usually used for remote debugging and is notoriously known for being left open for no good reason. Probing through open ports is probably the first step of every attacker’s TTPs. We also know that attackers use bots to scan for open ports, and once they find an open one, they simply brute force the password and often gain access to servers and other devices. Make sure you leave unnecessary ports closed, or have a good reason for why they may be open.
2. Excessive permissions – as previously written in this blog, providing a cloud resource with the wrong permissions can create the attack surface attackers are hoping for. Configuring your S3 bucket with read permissions, attackers can probe into the bucket looking for unprotected content and gain access to private information. Make sure you understand what least-privilege permissions your cloud resources need, and don’t leave anything to chance.
3. Lack of proper definitions – this affects observability (e.g., lack of proper logging), encryption (e.g., S3 objects without server-side encryption), or anything in between. Make sure you understand which resource requires which property, and make sure they are configured correctly in all cases.
4. Hard-coded secrets (in your IaC) – while not limited to IaC only, this remains a top challenge for all code (application source code as well). Once exposed, attackers can leverage the keys to obtain sensitive information, shut down services, or create whatever resources they need.
5. IaC security drift – we have all been there, we work perfectly through the process, our pipelines are all green, then something happens in production, and we must make a “small” change. Those small changes can have a huge risk on your environment, and you should not make those directly but through code. Using drift detection tools (e.g., Terrarfomer or Driffty), you can get a static file which represents your current production environment, then scan it with KICS to make sure you didn’t introduce any new risk.

Leveraging Infrastructure-as-Code is a critical part of achieving true infrastructure agility, but you should be aware of all the risks. Running fast is important, but don’t become blind to what may surface from errors and omissions. Be aware of the potential misconfigurations listed above and make sure you tackle them from the very beginning.

If you want to automate your IaC security scanning – you can easily integrate KICS into your pipeline and make sure you are appropriately managing your IaC risks.

More about KICS

KICS finds security vulnerabilities, compliance issues, and infrastructure misconfigurations in popular IaC solutions and OpenAPI 3.0 specifications. KICS is open source and always will be. Both the scanning engine and the security queries are clear and open to the software development community. With 2000+ fully customizable and adjustable heuristic rules, or queries, KICS can be easily edited, extended, and added to. What’s more, our robust but simple architecture allows for support of new IaC solutions.

Almost 500,000 people are already taking advantage of KICS. Download KICS for free here and start securing your IaC today!

According to their website, “The Center for Internet Security, Inc. (CIS®) makes the connected world a safer place for people, businesses, and governments through our core competencies of collaboration and innovation.  We are a community-driven nonprofit, responsible for the CIS Controls® and CIS Benchmarks, globally recognized best practices for securing IT systems and data.”

In our connected world, the need for collaboration, innovation, and best practices are vastly needed. In fact, CIS has four world-renowned, best practices and expert communities.

Going a little deeper into one particular area of interest, “CIS SecureSuite Membership provides integrated cybersecurity tools and resources to organizations of every size. Security IT teams can automate configuration assessments, conduct remote scans, implement security best practices, and more.”

Why is CIS Important to Checkmarx and the Developer Community?

KICS is an open-source project backed by Checkmarx that is purposely designed to scan infrastructure as code (IaC). KICS has had an incredibly successful launch with over 450K downloads as of date!

More importantly, Checkmarx is a CIS SecureSuite® Product Vendor Member, and our KICS solution has recently been awarded the following certifications from CIS:

KICS 1.4.4 (version)

• CIS Amazon Web Services Foundations Benchmark v1.4.0, Level 1
• CIS Amazon Web Services Foundations Benchmark v1.4.0, Level 2

We are extremely proud to have been awarded these certifications, and achieving Level 2 certification is a very notable achievement. Level 2 means that a technology provides “measurable defense in depth” protection.

From a static tool perspective, KICS performed exceptionally well in all evaluation criteria. Although some may say that not being a dynamic solution (testing code while running) is a limitation, KICS scans code much earlier than any dynamic testing solution ever could. KICS gets results and solves issues in IaC way earlier in the pipeline – from the first line of code written – long before the first docker, first container, or first asset were even provisioned. This is a huge differentiator in comparison to dynamic testing solutions.

According to Ori Bendet, Head of Product Management at Checkmarx, who helped spearhead the KICS project, “KICS supports the philosophy of shifting left by testing and securing code as early in the cycle as possible. Developers carry so much responsibility these days—from source code to integrating open source libraries, to containers and Infrastructure-as-Code. Each of these tasks possess its own security risks. From the first line of code developers write, Checkmarx delivers SAST, SCA, and KICS to shore up security on static code, open source code, and infrastructure as code. Combing these solutions, and using them early and often, organizations can feel confident that the code they deploy is secure.”

“As of yet, KICS is the only, completely open source project that has achieved any CIS Certification”, says Erez Yalon, Head of Security Research at Checkmarx. “This serves as a testament to what the open source community is capable of achieving. Checkmarx is very happy to have initiated the project, then opening it up to the community for their contribution. Our list of contributors should receive many thanks for what they have accomplished.”

Want to Know More About KICS?

Just like SAST that scans application source code, finding vulnerabilities and security issues within, KICS scans infrastructure code to finds issues that may lead to potential vulnerabilities as well. Since KICS is open source, you don’t need any licenses to use it. You can just go to the repository or download it from Docker Hub, and you can have it up and running in as little as a few minutes, to start scanning your infrastructure code. Also, KICS integrates into a wide variety of CI/CD solutions.

KICS finds security vulnerabilities, compliance issues, and infrastructure misconfigurations in popular IaC solutions and OpenAPI 3.0 specifications. KICS is open source and always will be. Both the scanning engine and the security queries are clear and open to the software development community. With 2000+ fully customizable and adjustable heuristic rules, or queries, KICS can be easily edited, extended, and added to. What’s more, our robust but simple architecture allows for support of new IaC solutions.

Download KICS for free here and start securing your IaC today!

What is the Issue?

The Checkmarx Security Research Team identified a document object model-based cross-site scripting (DOM XSS for short) vulnerability in Drupal Core. This type of XSS attack is achievable if a web application enters data to the DOM without being appropriately sanitized. In this case, an attacker can manipulate their input data to include XSS content on the web page, for example, malicious JavaScript code, which in-turn would be consumed by Drupal Core itself.

What is the Risk?

An attacker abusing this vulnerability can take over the administrator role of a Drupal-based website and get full control that allows changing of content, creating malicious links, stealing sensitive or financial data, or whatever else comes to mind.

Drupal Assigns CVE-2020-13663

Drupal labeled the Security Risk of this vulnerability our team discovered as follows:

• Risk: Critical
• Access Complexity: Complex
• Authentication: All/Anonymous Users
• Confidentiality Impact: Certain Non-Public Data is Released
• Integrity Impact: Some Data Can be Modified
• Exploit (Zero-day Impact): Theoretical or White-hat (no public exploit code or documentation on development exists)
• Target Distribution: All Module Configurations are Exploitable

Summary of Disclosure and Events

When the vulnerability was first discovered, the Checkmarx Security Research Team responsibly notified Drupal of its findings. Our team was asked to advise Drupal’s team after our disclosure, which we willingly did.
After we disclosed the vulnerability, the Drupal team’s sense of urgency and professionalism was quite notable, and a fix was made available within a week of our disclosure.
In accordance with Drupal’s disclosure guidelines and to give its users adequate time to update their software, Checkmarx will refrain from publishing a more technical report showing an in-depth walkthrough and proof-of-concept of exploiting this vulnerability for 60 days. In the meantime, we strongly encourage Drupal users to take action on recommended updates.

Recommendation

At this time, Checkmarx highly recommends that anyone using Drupal update the version in use immediately to the latest release, which contains a fix for this vulnerability.
Checkmarx customers using Checkmarx Software Composition Analysis (CxSCA) have already been automatically notified to update Drupal while running a scan of their code base.

Final Words

This type of research activity is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among all organizations in an effort to improve security for everyone. Checkmarx is committed to analyzing the most prominent open source packages to help development teams ship more secure software and improve their software security risk posture. Our database of open source libraries and vulnerabilities is cultivated by the Checkmarx Security Research Team, empowering CxSCA with risk details, remediation guidance, and exclusive vulnerabilities that go beyond the NVD.
For more information or to speak to an expert about how to detect, prioritize, and remediate open source risks in your code, contact us.