CVE-2019-5630

Last Modified: Tue, 07 Jan 2020 19:45:39 +0000 ; Created: Tue, 07 Jan 2020 19:45:39 +0000

CVE-2019-5630

Cross-Site Request Forgery (CSRF) vulnerability was found in Rapid7 Nexpose InsightVM Security Console

Notes from a vulnerability I found and reported to Rapid7 with their product's API behavior. Using Flash (still available in Google Chrome until Dec. 2020) one could use a wateringhole attack to perform a CSRF request. Enables an attacker to gain access to the Rapid7 console.

The vendor worked with me and released a fix. Version 6.5.69

I was reading security news and found a new published technique for CSRF using Flash and the Content-Type header.
Exploiting CSRF on JSON endpoints with Flash and redirects
Jan. 30, 2018

It is possible using the latest Google Chrome (Version 74.0.3729.131 (Official Build) (64-bit)) and the built-in Flash player in Chrome to execute CSRF against a logged in user of insightVM.

The attached PoC targets a victim with global admin role and ***creates another global admin secretly*** in the background. This is possible because an HTTP 307 redirect transmitted via Flash forwards on the Content-Type of application/json. IE11, Firefox do not have this behavior.

The REST API makes the assumption that the Content-Type: application/json will be present or it fails the request. This is no longer sufficient to stop CSRF. Additionaly, the 'enctype' attribute of the FORM HTML element almost had a W3 standard added to permit setting content-type to application/json (see https://www.w3.org/TR/html-json-forms/ )

Any REST API can be called, but the PoC shows creating a global admin user.

Requirements:

  1. Victim must use Chrome
    • (other browsers on Mac or mobile could be vulnerable)
    • (only Window was tested, IE11 & Firefox were not vuln)
  2. Victim visits some site by attacker
  3. Victim Clicks to run the flash content
    • Scenario: Offer to watch some videos of cats being cute

Flash content could show actual video or anything as the attack is then run silently in the background. Flash code could also wait for victim to login to their console in another tab (watering hole attack).

Steps to Reproduce:

  1. Setup an attacker server with Python version 2 and run hack-py-redirect-server.py
    • Update the Location URL value to your console
  2. Copy csrw.swf compiled code to same directory as python script
    • I had to set JAVA_HOME=c:\jdk1.8.0_212 as placing the 32-bit JRE in the PATH was not enough for mxmlc.exe to work
    • I used flex_sdk_4.6
  3. Victim logs into their console as a global admin
  4. Victim opens another tab to go to their favorite cat site
  5. Victim foolishly Click to run on the flash and their "video" starts
  6. Attacker now has an account as global admin to their console.

Github PoC files

Remediation:

Vendor has released a patch (fixed June 26, 2019; disclosed May 7, 2019).

In general practice a REST API might want to ignore cookies used for logged in sessions from web UIs. An alternative if cookies are needed would be to use alternative names for the cookies of API calls.

Another check could be the Referer or Origin headers, but it is dependent on expected clients.

Note that Flash was the entry-way this time, but in the future other factors could permit the Content-Type: application/json submission as well. It should be assumed that checking content-type alone is not sufficient to prevent CSRF.

The flaw roots from the assumption that web browsers cannot set certain HTTP headers or values, but that should not be considered a sufficient control for CSRF prevention.