Last Modified: Tue, 07 Jan 2020 19:45:39 +0000 ; Created: Tue, 07 Jan 2020 19:45:39 +0000
CVE-2019-5630Cross-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.
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.
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:
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.