January 11, 2019

Vulnerability in Microsoft Edge could allowed to steal local files

Security Research, Writeup Tags:

It’s happened.
While I was researching on Facebook I discovered a critical bug that an endpoint could allowed to download web pages automatically . Seems many of the fb pages have a user session containing full privileges user access_tokens etc which leads to Account Takeover.
So, If we can create iframe with "https://example.com/?download=1" It will not through any CORS errors and most of the web browsers auto-download feature is enabled by default. That mean we can remotely download user session.
I immediately reported it to the Facebook. Initial response was “I do not understand what the security issue is here?”
I replied them, ability to remotely downloaded user session and those are placed in public directory. Session files can be steal by attacker from public directory.
For example,
What is a difference between “Secured Cookie Location” and Public “Downloads” directory?
Android devices, "/data/data/com.example.foo" and "file:///sdcard/Downloads"?
In Android most of the apps have access to Download folder, not even need to bother with any other kind of permissions.
I also asked them, what if Bank Website behavior could serves same? Including Plain Text Passwords, Transaction PIN etc? Reply was, “While your attack does not require massive user interaction after that interaction the Attacker does not have the information to take over the account.”

Facebook wanted to full chain of “proof of concept” about stealing local files from the victim machine and send back to the attacker server. (Lesson I learnt that, In any bug bounty program we have to provide full chain of POC including all step details what you can demonstrate and make it impactful)
So, I quickly setup local html files with JavaScript XHR Request.
Except “Chromium Engine”, Mozilla Firefox and Microsoft Edge allowed access to the local files over local html files.
As well as, recently someone reported to the Microsoft "file:///" scheme vulnerability in Edge and it was patched.
In Mozilla, Allowed only files from current and child directory but not from parent directory and that was enough for me. Provided more details. Every time in response person was failing to re-produced about “CORS” error on "file:///"
After lot of conversation Facebook closed report as “Not Applicable”.
“Your Attack requires the attacker to have access to the victims device or that device be vulnerable to other security issues.”

For POC I change browser to MS Edge and check again to re-produce. "file:///" scheme was patched but I was not needed to call from any other directory. I Just defined “credentials.txt” and http.status was 200. I thought, give it a shot to check path traversal "../../Desktop/credentials.txt". Again response was OK. It’s clear! That’s a bypassed to the previous bug in "file://" scheme. I open another ticket to the MSRC and they “Triaged” within 2 days.

Proof of concept code

<html>
<head>
<script>
var http = new XMLHttpRequest();
http.onreadystatechange = function() {
if (http.readyState == 4 && http.status == 200) {
alert(http.responseText);
}
};
http.open(‘GET’, "../Desktop/credentials.txt", true);
http.send();
</script>
</head>
</html>

After few days MSRC Replied,
Our engineering team(s) determined that a fix for this issue does not meet the criteria for immediate security servicing.
At this time, we will not be providing ongoing updates of the status of the fix for this issue, and we have closed this case.
Additionally, you are able to blog about/discuss this case and/or present your findings publicly about the current version. We’d love to hear if you plan post anything.

Regards,
MSRC

A Coin Tossed: Both vendors rejected same issue when impact is critical.
1. Head: Facebook
2. Tail: Microsoft

Final Thought,
This is 2019, In which way do you protects user data? (Fast, Secured, Battery Saver, Privacy)

Timeline:

  • 30 Dec, 2018: Initial Report Sent to the Microsoft
  • 1 Jan, 2019: Acknowledgment of Report.
  • 3 Jan, 2019: Status Update by MSRC.
  • 10 Jan, 2019: Status Update and Closed.