Leveraging Nuclei Templates to Identify Risks and Threats in Critical Cloud Applications

The cloud has significantly changed how we approach data storage, web application design, deployment, and management. With services from platforms like AWS, Azure, and Google Cloud, both businesses and individual developers can benefit from the cloud’s adaptability and scale to enhance their digital solutions.

However, alongside the benefits, the cloud introduces unique security challenges. Web applications, APIs and more, especially those hosted in cloud environments, are constantly at risk of vulnerabilities, ranging from misconfigurations in cloud settings to more intrinsic application-level vulnerabilities. Within this landscape, I set out to build two scenarios for application vulnerability testing, aiming to showcase the importance and efficiency of vulnerability detection techniques in a cloud-driven world.

While we would want to tackle vulnerabilities before they are being deployed to production and externally exposed, sometimes the defense strategies on these areas could be missing the real world implications of tying several functionalities together. That’s where the external testing comes into place.

In this article, I’ll discuss how I built these scenarios and how we can detect their vulnerabilities.
To help us detect these vulnerabilities, we utilized Nuclei, an open-source scanning tool that streamlines the identification of web application vulnerabilities through a series of predefined templates. We also used AI to help us create templates quickly and easily. These templates are crucial as they target specific vulnerabilities, misconfigurations and issues we’re on the lookout for.

The following scenarios are meant to be vulnerable and publicly exposed, to showcase how an external attacker would attempt to detect and exploit them – with no prior knowledge of the organization. 

Building the vulnerable scenarios

For our security exploration, I focused on two distinct, yet equally instructive scenarios. I set up two vulnerable servers, one of them with a Server-side request forgery (SSRF) vulnerability caused by improper validation and sanitization of header values which might be hard to detect, and the other with a known vulnerability which could be detected internally based on the package version.

Scenario 1: Web application vulnerability

1. Setup: The application was hosted on Azure Blob Storage. It sends RESTful API requests to the backend through Azure’s Application Gateway.
2. Vulnerability Exploration: Through RESTful APIs integrated into the site, I simulated an SSRF vulnerability. This allowed to demonstrate unauthorized request sending capabilities to the backend, exploiting the instance’s metadata service.

Scenario 2: CI/CD server vulnerability

1. Setup: I configured a TeamCity CI/CD server, intending to replicate a real-world continuous integration environment.
2. Vulnerability Focus: The primary objective was to simulate a newly discovered Authentication Bypass vulnerability within TeamCity – CVE-2024-27198. 

These scenarios are designed to mirror real-world vulnerabilities, highlighting their potential for easy detection and exploitation in insufficiently secured environments. This approach emphasizes the critical need for vigilant security practices and robust protection measures.

Automated vulnerability detection using Nuclei templates

Nuclei utilizes templates, which are essentially predefined HTTP requests crafted to identify specific security issues or misconfigurations in web applications and APIs. These templates contain detailed instructions on what requests to send and how to interpret the responses to detect vulnerabilities such as SSRF, XSS, CVEs and more. By systematically running these templates against target endpoints, it automates the process of security assessment, enabling easy identification of potential weaknesses in assets. 

It’s also important to note that since Nuclei is an open-source tool it can be used by security professionals as well as attackers for finding exploitable vulnerabilities. For this reason it is important to be able to detect and defend against these types of vulnerabilities and security issues by using external scanning as well.

1. Using AI to create templates: AI tools expedite vulnerability detection and make the creation of detection templates faster and easier by processing given requests, thereby reducing manual effort and enhancing the precision of spotting issues like SSRF. The following screenshot from the Nuclei website provides a clear illustration of how we input text to formulate a YAML template, streamlining the vulnerability detection process.
   
   
2. Crafting custom templates: Custom templates, created by security experts, utilize predefined patterns to identify and guard against known vulnerabilities by looking for specific signatures or indicators of compromise. The projectdiscovery repository, among others, hosts a wide array of these templates, offering a diverse range of pre-built options that address many security needs and vulnerabilities.

Scenario 1: SSRF vulnerability on Azure-hosted web application

SSRF (Server-Side Request Forgery) is a vulnerability that allows attackers to make requests to internal resources, often bypassing firewalls, by tricking the server into making those requests on their behalf. 

Architecture and workflow

This website was set up as a static site hosted within an Azure storage bucket. This site showcases a fictional company’s webpage and is designed to send API requests through Azure’s Application Gateway, performing client analytics and forwarding the traffic to the backend systems for processing. Here, the X-Forwarded-Host header in API requests presents a potential security concern, because it can be exploited if not properly validated and managed.

The X-Forwarded-Host header is commonly used in web applications as a method for identifying the original host requested by the client in the Host HTTP request header. When traffic is routed through proxies or load balancers, like Azure’s Application Gateway, this header is automatically appended to the HTTP request, without the user even realizing. For a more detailed understanding, this article provides a comprehensive look into how the Azure Application Gateway functions.

In our context, when a client initiates a request to our website, the Application Gateway receives it and forwards the request to the backend server.

Potential SSRF vulnerability exploitation

If not properly validated and managed, our scenario could allow an attacker to perform the following actions:

• Bypassing Firewalls: Since the malicious requests come from the trusted server, they might bypass firewall restrictions, offering a path to access or exploit internal systems.
• Header Manipulation: Attackers could tamper with the automatically-added X-Forwarded-Host header (and other automatically-added, unseen headers), using it to guide backend requests to unintended destinations.
• Interacting with Internal Resources and Cloud Services: Exploiting SSRF, attackers might reroute requests to internal resources or interact with cloud services, potentially accessing sensitive data, manipulating resources, or retrieving cloud metadata within the Azure network.

Attack flow of an SSRF exploitation

The default behavior in which the automatic header is designed to maintain navigational consistency by preserving crucial data through the X-Forwarded-Host header, could inadvertently create a potentially exploitable route if not securely configured. This could then serve as a potential attack vector for SSRF vulnerabilities, which would allow attackers to have the backend server make requests for them, possibly accessing cloud metadata, internal systems, or external malicious platforms, presenting a significant security risk.

Exposing sensitive data: A practical exploration

In this specific exploration of an SSRF vulnerability within the Azure-hosted website, I focused on exploiting the X-Forwarded-Host header, recognizing a risky scenario when backend servers trust this automatically added header. I altered the X-Forwarded-Host header to target a known Azure instance metadata API endpoint: **<http://169.254.169.254/metadata/instance?api-version=2021-02-01**>, thereby gaining access to sensitive instance metadata. 

This method could potentially allow attackers to retrieve crucial data, such as virtual machine custom data or service tokens, which could then be used to gain unauthorized access or manipulate Azure services and resources, leading to a variety of security incidents, including data breaches or unauthorized data access and modification.

This practical breach highlights the essential need for enforcing strong security measures and regular testing of API endpoints. This includes thorough validation and sanitation of user inputs and headers in API communications, particularly when interacting with cloud environments that hold sensitive and crucial data.

SSRF vulnerability detection using a template

To exploit this vulnerability with a template, we would need the following: 

• Exploiting Known Headers: Create a template that systematically sends requests with altered headers, specifically incorporating a list of commonly known exploited headers like X-Forwarded-Host and others, attempting to retrieve information from unauthorized paths or induce unexpected behavior.

This methodology, utilizing a template encompassing a broad array of headers known for their exploitability, aims to proactively detect and subsequently shield against potential SSRF vulnerabilities, thereby enhancing the cybersecurity posture of the website hosted in Azure.

The following simple template was created using Nuclei AI platform by writing a specific prompt to manipulate the “X-Forwarded-Host” and “X-Forwarded-For” header and attempt to access Azure instance metadata service:

id: ssrf-azure-metadata

info:
  name: SSRF Vulnerability Detection in Azure Instance Metadata
  author: pdteam
  severity: high

http:
  - method: GET
    path:
      - "{{BaseURL}}"

    headers:
      X-Forwarded-For: "http://169.254.169.254/metadata/instance?api-version=2021-02-01"
      Metadata: true
    matchers:
      - type: word
        part: body
        words:
          - compute
          - azEnvironment
          - resourceGroupName
        condition: or

  - method: GET
    path:
      - "{{BaseURL}}"

    headers:
      X-Forwarded-Host: "http://169.254.169.254/metadata/instance?api-version=2021-02-01"
      Metadata: true
    matchers:
      - type: word
        part: body
        words:
          - compute
          - azEnvironment
          - resourceGroupName
        condition: or

Scenario 2: TeamCity Authentication Bypass vulnerability

Architecture and Workflow

This scenario involved a vulnerable TeamCity CI/CD server, specifically a version prior to 2023.11.4, set up on an EC2 instance in AWS to simulate a real-world software development environment. TeamCity, by default, exposes its web server over HTTP on port 8111. In this setup, the server is configured to handle code commits, automate builds, and manage deployments. However, this streamlined pipeline can become a liability if an Authentication Bypass vulnerability is present, as it may allow unauthorized access to critical development workflows.

Authentication Bypass Vulnerability Exploitation

The attack flow of this vulnerability is as follows:

• Crafting malicious URLs: Attackers can send a crafted request for a non-existent resource (e.g., /hax), with a query parameter named jsp targeting an authenticated endpoint (e.g., ?jsp=/app/rest/server), and ensure the request ends with .jsp (e.g., ;.jsp). This manipulates the server into processing requests as if they were authenticated.
• Gaining unauthorized access and persistence: By bypassing the login mechanism of the TeamCity server, an attacker can directly access administrative features and create a new user for persistent unauthorized access.
• Full control over internal resources: A remote, unauthenticated attacker exploiting this vulnerability could potentially take over the TeamCity server, leading to severe implications, including codebase tampering or pipeline disruption.

Exposing sensitive data: A practical exploration

In demonstrating the exploitation of the TeamCity Authentication Bypass Vulnerability, the key was sending a crafted HTTP request to the TeamCity server. The request targeted a non-existent resource, inducing a 404 error, but it was the subsequent manipulation that exploited the vulnerability. By appending a special query parameter ?jsp=/app/rest/users.jsp to the request, it manipulated the server’s response to treat my request as authenticated.

I sent a request to create a new administrative user on the TeamCity server:

This POST request exploited the vulnerability to interact with the /app/rest/users endpoint without authentication, creating a user named “hacker” with system administrator privileges. 

Successful execution of these steps not only allowed us to create a new administrator but also demonstrated the severe implications of the vulnerability. It provided us with an unauthorized gateway to manipulate the CI/CD pipeline, access sensitive data, and potentially introduce malicious code.

This highlights the critical importance of vigilance in securing CI/CD environments. The need for strict validation of all user inputs and URLs, ensuring that authentication mechanisms cannot be bypassed and that servers are kept up-to-date with the latest security patches to prevent exploitation.

TeamCity Authentication Bypass vulnerability detection using a template

To exploit this vulnerability with a template, we would need the following:

• Exploiting known versions: Create a template targeting the TeamCity login endpoint to detect the vulnerability by checking for specific version information. This template should craft requests to access the TeamCity server’s login page, then parse the response for version details that indicate an unpatched, vulnerable state.
• Sending crafted requests: Create a template to probe for unauthorized endpoint access on the TeamCity server using the crafted URL technique previously outlined. This template should send requests aimed at reaching protected areas of the TeamCity server by utilizing the crafted URL that bypasses authentication mechanisms. The success of this exploit is determined by analyzing the server’s response to these requests (verifying status code 200 for example). 

The following template was developed using Nuclei AI, specifically tailored to identify instances of the TeamCity Authentication Bypass vulnerability by examining server responses for version information indicative of an unpatched state. This utilization of Nuclei AI showcases its strength in creating focused templates to efficiently identify and address security vulnerabilities.

id: CVE-2024-27198
info:
  name: TeamCity Authentication Bypass Vulnerability
  author: pdteam
  severity: high

http:
  - method: GET
    path:
      - "{{BaseURL}}/login.html"

    matchers:
      - type: regex
        part: body
        regex:
          - '<span class="greyNote version"><span class="vWord">Version</span> (20[0-2][0-3]\.(0[1-9]|10|11\.[1-3])|(200[0-9]|201[0-9]|202[0-2]).*).*<\/span>'
        condition: and

Findings and Conclusions

Through delving into two specific vulnerability scenarios — we learn that testing web applications and APIs is crucial for an organization’s protection. The traditional approach involves identifying vulnerabilities before deployment to production, when they are merely code. However, the presence of internet-facing applications requires testing them through the perspective of an attacker as well. 

This approach is essential because, as demonstrated, such vulnerabilities could have devastating consequences for an organization. By employing both AI-driven methods and manual template creation for effective and easy detection, we showcased the importance of securing and rigorously testing HTTP requests and API endpoints:

• Practical exploitations: Our hands-on manipulations of HTTP requests revealed pathways to internal and cloud metadata, spotlighting SSRF risks and known vulnerability exploitation in varied cloud environments.
• Harnessing templates for detection: The deployment of both AI-enhanced and manually crafted Nuclei templates allowed for precise identification of vulnerabilities, showcasing the efficacy of methodical endpoint probing in uncovering security flaws across different environments.
• Automated defense integration in Orca: The Orca Platform now incorporates automated scanning and alerts, ensuring that both AI-powered and manually crafted templates not only shield against recognized vulnerabilities but also fortify our defenses against emerging threats by continuously analyzing and adapting to new patterns of attack. This dual-approach integrates the precision of manual expertise with the adaptive, scalable nature of AI, fortifying our security posture against a spectrum of different vulnerabilities and security issues.

This exploration underlines that securing digital infrastructures, from web applications to CI/CD pipelines, is crucial. Embracing automated vulnerability detection tools, powered by AI and supplemented by expert input, is essential for maintaining the integrity and security in today’s digital age.

How the Orca Cloud Security Platform Can Help

Orca Security harnesses the power of Nuclei templates to perform extensive scanning of organizational networks, focusing on external exposure. This approach uncovers vulnerabilities in production systems, within CI/CD pipelines like TeamCity, web applications and API endpoints. 

By generating a comprehensive cloud asset inventory, Orca offers clear visibility into the deployed software versions, their network exposure, and associated security vulnerabilities. This granular insight enables the identification of both common and obscure vulnerabilities, ensuring a robust defense mechanism is in place.

In this alert, Orca shows the TeamCity vulnerability detected externally using a Nuclei template

The scanning process employed by Orca is designed to not only discover vulnerabilities but also to evaluate the risk level of each finding. By analyzing factors such as network exposure, usage of privileged identities, and access to sensitive data, Orca prioritizes vulnerabilities based on their potential impact. 

This prioritization allows for the efficient allocation of resources to mitigate the most critical risks first, especially those that are actively being exploited. Through this strategic use of Nuclei templates and comprehensive scanning, Orca empowers organizations to proactively protect their environments against emerging threats.
If you would like to learn more about the Orca Platform, schedule a 1:1 demo with one of our experts to see how we can help you uplevel your cloud security.