Friday, July 1, 2016

Bug hunting story - Cloudflare CDN - SSRF/XSPA

Three years ago I loved reading This is very decent website with
infosec news on various topics. Not that techy, but still a good resource to know what's up in the viral part of infosec world. I used their service quite a lot so decided to give something back - brief security audit to ensure they won't get hacked because of some dumb low hanging fruit.

The website was fine, if I remind correctly I haven't found anything cool except of a SSRF, which turned out to be a vulnerability in 3rd party plugin - CloudFlare(CF) Rocket Loader.
There was also a reflected XSS in newsletter signup form, but that was 3rd party vendor either which I tried to contact without any luck so forget about it. XSS was in different origin and would trigger only after redirect, so too low(if any) risk for THN to actually bother with pushing random vendor do get that fixed - there are tons of XSS out there and it's quite not my business to save all shitty apps on the planet.
Eitherway - CloudFlare is a hero of this story.

Long story short - using vulnerability in CloudFlare's CDN I was able to forge CloudFlare's server requests using endpoint used by their plugin and read the host response through a website which used CF's Rocket Loader.
For example by making request to[]=scheme:host:port, CF's CDN would make a request from their network to the host, then provide the output to THN domain which would serve it from THN origin as a legitimate file with content-type: multipart/bag and because a browser doesn't know how to present such content it would show file download prompt.
Example exploitations:
- using CF's server(so their network IP) you could enumerate resources on targeted server(including other CF's servers)
- abuse trust relationship with THN/CloudFlare/other service using CF's CDN to trigger RFD on victim's computer and use it in drive-by download attack(Windows + trusted filenames without UAC, anyone?)

For those who'd love to read the full story:

CDN = Content Delivery Network
SSRF = Server Side Request Forgery <- this is what you actually do, kinda bug category
blind SSRF = bug variant in which you can't see output of your operation
XSPA/S = Cross Site Port Attack/Scanning <- malicious operation you can perform, example exploitation
RFD = Reflected File Download
LFI = Local File Inclusion

SSRF severity depends on specific implementation. Sometimes you can only make blind http requests to other services on the Internet/Intranet - still can be useful in some ways, e.g. if you want to execute a payload for which you don't need to know a response - but it happens that you can do much greater things, especially when you're able to obtain server response with SSRF output, which was the case in Rocket Loader's SSRF.
Some services employ public IP whitelisting, some allow hosts within a datacenter to call other internal services without authorization - let it be a database application or other crazy service you use internally without auth. So in those cases, being able to make request to that service from trusted host is a big thing.
Sometimes you can also pull out local files content just like in LFI vuln, using file protocol e.g. file:///etc/passwd.
It happens that SSRF can be really powerful, when you can load local files. poke other services on the network using other protocols - this is cool stuff. All depends on specific SSRF, network architecture and your creativity.
If you want to know more about SSRF then this doc from ONsec should give you good basics to start with.

I'm going to drop here a PoC video I sent to THN which quite well demonstrates the vuln, but a bit of clarification is needed as the video solely doesn't tell the entire story.
The assumption written at the beginning of the video turned out to be slightly wrong. When I found the SSRF on THN I reached out to Pierluigi(owner of; lead writer at THN back in the old days) which I knew because a couple months back I reported him SQLi in a company he's a CISO at, so I knew he's a cool guy. He was in travel so for quicker resolution he redirected me to THN's Founder - Mohit, who replied that there is no such path or a file on their webserver. But they were using CloudFlare so I may want to ping CloudFlare with the bug report, because there is nothing special about THN's configuration.
Fair enough, that was cool - I learnt that I need to go deeper.

I started digging into this and found out that it was actually a Rocket Loader plugin shipped by CloudFlare that was vulnerable. That wasn't a good info though, Rocket Loader was quite popular tool at that time(AFAIK it actually still is) and all websites that had that plugin were vulnerable.

That CDN was supposed to do an easy thing - cache JS resources and support page load by providing static resources faster. It should allow to load predefined files to CloudFlare CDN basing on what had been chosen by particular website.
It's a CDN feature so while it's perfectly fine to download static web resources for caching, it was definitely not expected to allow requesting different protocols and enumerating other ports.
There was no extension white/black listing so you could also download .exe or .bat files from external servers.
In general, parsing user's input got messed up, because it was not exploitable with regular parameter r. <- this wouldn't work
I had to change it to r[]= to bypass all protections, like this:[]=http://xx.yy.244.221:81&r[]=http://zz.ccc.244.221:22

Yes - It was possible to chain multiple parameters within one request. Sending it as an array argument, server parsed them one by one and the output file contained all responses.

Source IP during an attack would come from CloudFlare's network, but you still were able to use THN website as a vector and resulting file download would come from hosting origin, which was not the coolest thing to have on your website as it can be abused in drive-by download attacks. So this was impacting not only CloudFlare, but Rocket Loader consumers trustworthiness.

I know that Reflected File Download is not the best argument, as for example Google doesn't care much about RFD and say that if you're able to convince someone to run random file downloaded from the Internet, then domain trust relationship doesn't really matter. While their argumentation makes sense and I wouldn't pay for it either, RFD is definitely a one more toy in social engineer/pentester's pocket.
Anyone remind that trick with Windows =<8 when if the file name was like install.exe, update.exe(worked with other extensions, like .bat either) and couple other similar names, Windows wouldn't show UAC even for untrusted resources. So once user downloaded a file and clicked on it, he wouldn't get Windows prompt asking for confirmation before execution.

Promised PoC - kinda lengthy so x2 speed recommended. Messed only with XSPA, I didn't want to go further with exploitation without permission.

The fix was to allow fetching only prfetched JS resources from CDN, with a request like:{uuid}/cloudflare/something.js
No protocol or ports allowed.

My experience with CloudFlare support?
15 September 2013 - reported
26 September 2013 - received info from CloudFlare that within days after my report they started rolling out a fix to all of the sites on CloudFlare. "We're initially rolling out slowly to ensure it's working properly."

After that I tried to reach out to CloudFlare without any luck. Late December I received response that "the final fix was put into production on or around the 21st December 2013"
No direct contact with Security Team, lazy and shitty responses along the way - it sucked, but initial patch went live after ~a week so it wasn't that bad. World saved but definitely without much sympathy to CloudFlare for their public relations.

No comments:

Post a Comment