Skip to main content

One Cloud-based Local File Inclusion = Many Companies affected


Hi everyone, Today, I'm going to share how I found a Local File Inclusion that affected companies like Facebook, Linkedin, Dropbox and many others.




The LFI was located at the cloud system of Oracle Responsys. For those who do not know Responsys is an enterprise-scale cloud-based business to consumer (B2C). Responsys gives every Business their own "private IP" to use the system in a private way. Business are not sharing IP with other companies.)

How did I found this bug?

Well as usual I was looking for bugs and I note that Facebook was sending me developer emails from the subdomain em.facebookmail.com. For example on my inbox, I had emails from fbdev@em.facebookmail.com

This got me interested on the subdomain em.facebookmail.com and after a quick DIG I note that this subdomain was connected to "Responsys" which I had previously seen in other Pentests



Responsys is providing em.facebookmail.com with the email services as you can see above. The original link I found in my inbox was something like this:

http://em.facebookmail.com/pub/cc?_ri_=X0Gzc2X%3DWQpglLjHJlYQGkSIGbc52zaRY0i6zgzdzc6jpzcASTGzdzeRfAzbzgJyH0zfzbLVXtpKX%3DSRTRYRSY&_ei_=EolaGGF4SNMvxFF7KucKuWNhjeSKbKRsHLVV55xSq7EoplYQTaISpeSzfMJxPAX8oMMhFTpOYUvvmgn-WhyT6yBDeImov65NsCKxmYwyOL0.

I note that the parameter "_ri_=" is required in order to generate a valid request. And after a bit of testing around, I found that the system was not correctly handling double URL Encoding and using a correct value at the parameter "_ri_"  I could inject "%252fetc%252fpasswd" into the URL path.

This was not properly sanitized and was allowing directory traversal characters to be injected and with this retrieve internal files from the affected server.

An example of the Vulnerable URL:

http://em.facebookmail.com/pub/sf/%252fetc%252fpasswd?_ri_=X0Gzc2X%3DYQpglLjHJlYQGrzdLoyD13pHoGgHNjCWGRBIk4d6Uw74cgmmfaDIiK4za7bf4aUdgSVXMtX%3DYQpglLjHJlYQGnnlO8Rp71zfzabzewzgLczg7Ulwbazahw8uszbNYzeazdMjhDzcmJizdNFCXgn&_ei_=Ep0e16vSBKEscHnsTNRZT2jxEz5WyG1Wpm_OvAU-aJZRZ_wzYDw97ETX_iSmseE


Soon as I saw the vulnerability I knew that this LFI was not only affecting Facebook but also many other companies. All of them using different Private IPs provided by Responsys.

A quick Google Search show me other affected companies with this same bug.



Copying a valid value from the parameter _ri_ to the target company I could retrieve internal information using the same technique.




The impacts of exploiting a Local File Inclusion (LFI) vary from information disclosure to complete compromise of the systems. In this case the impact it worst because one vulnerability affected multiple companies data.

I report this bug to Oracle and the bug got fixed within a week.



Popular posts from this blog

Dangerous Persistent XSS at Here.com [FIX]

 Here.com, is a Nokia business unit that brings together Nokia's mapping and location assets under one brand. The technology of Here is based on a cloud-computing model, in which location data and services are stored on remote servers so that users have access to it regardless of which device they use.  HERE Map Creator is a service launched by Nokia in November 2012 to allow users to map their neighborhood. With this bug I could SAVE a Road name with a payload on the map. Any user that try on re-edit the street name will get this XSS. I report a similar bug to Waza.com a few months ago .  Nokia Reponse:   Thanks to Nokia for starting this bug bounty program .

Stored XSS at Google firebase via Google Cloud IAM

Google Firebase demo console platform was allowing an attacker to store an XSS under the project name. This vulnerability was created on the main page of the select project.  - "The Firebase demo project is a standard Firebase project with fully functioning Analytics, Crash Reporting, Test Lab, Notifications, Google Tag Manager and Remote Config features. Any Google user can access it. It’s a great way to look at real app data and explore the Firebase feature set."  https://support.google.c om/firebase/answer/7157552 - Using Google IAM ( console.cloud.google.com ) was possible to create a payload and share it to the victim. Once the victim accepts the invitation at console.firebase.google.com the payload was rendered on the main project page. Impact: The attacker could share a project from " console.cloud.google.com " and store an XSS payload under   console.firebase.google.com . This stored payload was been rendered every time the victim