CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Server-Side XSS Attack Detection with ModSecurity and PhantomJS

Client-Side JS Overriding Limitations

In a previous blog post, I outlined how you could use ModSecurity to inject defensive JS into the HTML response page sent to the client web browser. The goal of this technique was to override many common JS elements that are often used by security researchers/attackers when conducting reconnaissance testing for XSS flaws. While this was an interesting PoC for using ModSecurity in combination with defensive JS, it had one fatal design flaw: the detection logic was exposed to the attacker. By sending our defensive JS code to the client, we are tipping our hand to the attacker as to our intention and methods. This allows attackers to then play around with various evasion methods.

Ideally, we need to keep this type of detection logic server-side, away from the prying eyes of attackers. But how then do we detect Browser/DOM events server-side? This blog post will8723_36c9f684-1cc6-4373-862c-f9bb07549d76 demonstrate another PoC that uses ModSecurity's Lua API to execute PhantomJS to evaluate HTML data sent to end users and thus gain insight into XSS payloads that actually execute in the web browser.

What is PhantomJS?

PhantomJS describes itself as:

PhantomJS is a headless WebKit with JavaScript API. It has fast and native support for various web standards: DOM handling, CSS selector, JSON, Canvas, and SVG.
PhantomJS is created by Ariya Hidayat.

It is useful for:

  • Headless Web Testing
  • Screen Captures
  • Automation Tesing
  • Network Monitoring

The key browser functionality at play with PhantomJS is that it uses the WebKit browser engine that is found within Safari and Google Chrome. For our purposes, the fact that it is "headless" is key as we want to use it for server-side inspection of HTML data to help identify XSS attacks.

Using PhantomJS for Server-Side XSS Detection

Due to the fact that PhantomJS can utilize WebKit's full browser environment, we can detect successful reflected XSS attacks much more accurately than a server-side app/WAF regular expression filter. The main advantages are:

  • De-obfuscation - many XSS (and malware/exploit) payloads utilize various encoding and obfuscation tricks to hide their true intention. Consider techniques such as using partial non-alphanumeric obfuscation. For example, if an inbound filter was looking for "alert" you could easily use the following non-alpha code to byass it:

10179_7cd2b54e-a81f-405a-b597-6a687cdf8182

By using PhantomJS, we can do our analysis at execution time within the Browser DOM after deobfuscation.

  • Execution Detection - there is a distict difference between identifying an attack payload vs. one that executed successfully. Just because an attacker sent an XSS payload to the web application does not necessarily mean that it will execute properly within the target's web browser. The application may in fact apply proper contextual output encoding to the payload and thus neutralize it when it sends it to the browser. Rather than having a WAF playing the "Boy Who Cried Wolf" everytime some HTML/JS data comes into the application, it would be more useful to only signal an alert if certain data successfully executes within the browser.

In order to use PhantomJS to detect successful XSS attacks, we need to be able to pass it real data from live HTTP transactions.

Server-Side JS Overriding

Have I mentioned how completely awesome the Lua API is in ModSecurity? Well, it is. It allows you to hook in any external program you want which creates an endless number of integrations. With Lua, we can use ModSecurity to extract the required HTTP data and pass it off to PhantomJS for inspection. Here is an example rule that launches our js-overrides.lua script:

SecRule RESPONSE_HEADERS:Content-Type "@contains html" "chain,id:'85',phase:5,log,pass"
SecRule &ARGS "@gt 0" "chain"
SecRuleScript /usr/local/apache/conf/crs/lua/js-overrides.lua

This script will run at the end of the current transaction (phase:5 in ModSecurity) after the response has already been sent to the client. This is done to limit latency impacts on clients so the response is not held while PhantomJS tests are being run. If you want to do active response blocking, you could move this rule to phase:4. The rule will check the response content-type to verify it contains html data and then checks to see if there was any parameter data being sent to the web application (as we would see in a reflected XSS attack). If these conditions are met, it will then fire off the js-overrides.lua script:

7987_1158ff6b-b05e-4afd-8942-76f96064bb68

The Lua script exports the RESPONSE_BODY content obtained by ModSecurity and dumps it into a temporary OS file. It then executes the highlighted PhantomJS command with two arguments:

  1. xss.js - this is the PhantomJS script file with our detection logic.
  2. tmp_response_body - is the temporary OS file that holds the HTML data.

Let's now take a look at the xss.js file contents:

7850_0b3a1511-2495-46af-9206-38865e44ba49

The script creates a new PhantomJS WebPage object and populates it's contents with the data in the highlighted line. This line essentially mimicks our previous PoC example where we manipulated the outbound HTML response going to the real client and prepended our JS overrides code (in the js-overrides.js file) to the top. Here are the contents of the js-overrides.js file:

12340_e61f4e1e-f5c9-435f-a8dd-593b802faf25

The script then calls up the wp.evaluate command to have PhantomJS/WebKit evaluate the contents of our web page.

Example Testing

In order to test this setup, we can take examples from the xssed.com archive such as this one that has been fixed:

12881_fdc50a68-7b11-4578-99e0-fbe6a0898369

The highlighted parameter data would then be reflected into the response body content like this:

12767_f7df496f-cde3-493b-bce5-0350023cc814
And this would execute in the web browser and issue the JS Alert pop-up box:

8210_1c974e61-0a3b-49e5-a1bf-be59896f3517
After the PhantomJS script evaluates the web page data, the JS overrides code would identify the JS alert code execution and it would generate the following ModSecurity event:

12119_da6474cd-3f37-46d1-af96-31978cf72948
As you can see, we now are able to accurately identify when actual JS code executes in a client-side context thanks to PhantomJS/WebKit without having to expose our detections to the end user!

Access Attempts for document.cookie DOM Object

In addition to our JS Override proxy code, we can also gain alert data generated by WebKit if client-side code attempts to violate security policies. One such can is when JS attempts to access the document.cookie data. Here is another example taken from xssed.com for an old flaw in the zdnet.com site that is fixed:

8021_1360c0d7-4640-42d2-a136-3480b4af54a8
When this successfully executes, PhantomJS/WebKit will generate the following ModSecurity alert indicating a DOM Security violation:

12274_e2df6dcf-2013-4dd4-9d26-8c8f11d955bf

Up to this point, we have only been using PhantomJS to evaluate the HTML response body and looking for certain events. There is another key piece of XSS protection that is available within WebKit that we can take advantage of: XSSAuditor.

Leveraging WebKit's XSSAuditor

The WebKit engine contains reflected XSS protection code called XSSAuditor (an excellent whitepaper by the developers is here). The XSSAuditor filter is located in between the HTML Parser and JS engines which helps with its accuracy.

9625_63ea72ff-26dc-4053-9a5f-bc1e7d9c8b0f

XSSAuditor will analyze inbound client data with the outbound, parsed HTML data to see if there is any executable code found from the client within the response. If there is, then XSSAuditor would generate a console alert similar to the following:

8526_2df22fff-0f27-4190-b34e-28b22ad6455c

Request Mimicking with PhantomJS

In order to use WebKit's XSSAuditor component, you must initiate an actual HTTP request. We do not want to replay the captured request data on the live web application as that could have negative impacts to the current users application flow. Fortunately, PhatomJS comes equipped with its own embedded web server! We can therefore use it to send/receive data captured by ModSecurity from the live transaction. Let's take a look at the updated ModSecurity rule as it is executing a new Lua script called xssdetect.lua:

SecRule RESPONSE_HEADERS:Content-Type "@contains html" "chain,id:'85',phase:5,log,pass"
SecRule &ARGS "@gt 0" "chain"
SecRuleScript /usr/local/apache/conf/crs/lua/xssdetect.lua

Here is the updated xssdetect.lua script contents:

8515_2d5e0bf5-5aff-46e5-b9f3-f84ef1cadaf4
Notice the new bolded/highlighted sections as we now also need to gather the inbound request URI data (including QUERY_STRING contents). We then execute PhantomJS again but we pass it a new file called xssdetect.js and two more arguments holding the names of the temp OS files holding the request/response data. Here is the contents of the xssdetect.js file:

8092_1764f116-bdf7-4384-983f-902f5f453caa
9918_7235c87e-a9a0-4277-978a-413ac67cbd43

The xssdetect.js script does the following:

  1. Initiates its own embedded web server module (based on Mongoose) listening on the loopback interface on a random 4-digit port.
  2. Sets XSSAuditingEnabled = true.
  3. Initiates a new HTTP request using the REQUEST_URI data exported from ModSecurity.
  4. The PhantomJS web server responds with the HTML response data exported from ModSecurity.
  5. PhantomJS/WebKit then evaluates the HTML page.
  6. Alerts are generated in two different scenarios - if the XSSAuditor triggers or if one of the JS events of interest execute.

XSSAuditor Alerts with PhantomJS

If this same request from the previous ZDnet XSS screenshot was sent through our server-side implementation, we would received the following alert indicating that WebKit's XSSAuditor blocked execution of reflected XSS code:

9553_5fa8fdc2-e8ce-4125-bb48-b5acaec3c65d

Future Testing

While I must admit that I am pretty excited about the possibilities for server-side XSS detection with this proof of concept, there are some considerations that must be addressed if you want to field this setup in a production environment.

  1. When to use it - As you can see from my example SecRules, I am only initiating this script under certain circumstances. You may only have very specific conditions or locations within your web application that you want to activate this analysis.
  2. Asynchronous Mode - in the current setup, we are actually waiting for the command line PhantomJS program to return results. This leads to an obvious latency/performance impact. One option for dealing with this would be to set the PhantomJS execution as a background process and then have the PhantomJS code actually initiate its own request back to the web server sort of like a RESTful API. When sending back this beacon request, it would be wise to pass the UNIQUE_ID variable data that was assigned to the original transaction. This would allow you to then tie the beacon alert with the actual data.
  3. PhantomJS N-tier Architecture - ideally you could setup and entire platform of PhantomJS nodes where you can pass job requests to them. There are other web automation frameworks that could be utilized here such as NodeJS, Selenium, WebDriver, etc...

Acknowledgments

There are many security researchers who have in part inspired this work and/or who directly helped me with developing this proof of concept:

Latest SpiderLabs Blogs

EDR – The Multi-Tool of Security Defenses

This is Part 8 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

The Invisible Battleground: Essentials of EASM

Know your enemy – inside and out. External Attack Surface Management tools are an effective way to understand externally facing threats and help plan cyber defenses accordingly. Let’s discuss what...

Read More

Fake Dialog Boxes to Make Malware More Convincing

Let’s explore how SpiderLabs created and incorporated user prompts, specifically Windows dialog boxes into its malware loader to make it more convincing to phishing targets during a Red Team...

Read More