Chinese (probably not only they) snoops try tracking VPN users with fiendish JSONP trickery

[lsat 23]

Chinese snoops try tracking VPN users with fiendish JSONP trickery

 

 

VPN users are more at risk than Tor browser users because of restrictions in handling JavaScript by the latter, as pointed out by the Tor Project, and reflected in an update to AlienVaultult’s blog post.

 

 

Even users who run VPN connections to access websites that are blocked by China’s censorship technology, often called the Great Firewall (GFW), are potentially being tracked.

The attacks exploits vulnerabilities in the top Chinese websites, including those run by Baidu and Alibaba, and use cross-site request forgery to expose users accessing restricted sites. These restricted sites have been hacked and bobby-trapped with malicious code in order to make the attack work.

The whole multi-stage attack relies on a JavaScript-related vulnerability, known as JSONP, first publicised in 2013. Privacy is compromised when surfers browse sensitive websites while logged into another mainstream website, even in a different tab or window.

The upshot is that Chinese surfers who visit Baidu, for example, at the same time as visiting targeted non-government organisation, Uyghur and Islamic websites are exposing their surfing habits even if they are using a VPN.

The snooping has been going on since at least October 2013, with the most recent attack discovered only a few days ago, reports security tools firm AlienVault.

The sophisticated attack uses a novel multi-stage technique:

• The attackers compromise several Chinese-language websites associated with NGOs, Uyghur communities and Islamic associations

• The attackers modify the content of the website and include a JavaScript file from a malicious server

• The JavaScript file exploits JSONP hijacking vulnerabilities in more than 15 different major Chinese websites, including the top five portals used in China

• Using JSONP requests, the attackers are able to bypass cross-domain policies and collect a user’s private information if the user is logged into one of the affected services

• The JavaScript code then sends the user’s private data collected to an attacker-controlled server

The trickery allows what looks like state-sponsored hackers to vacuum up private information, including user ID and (in some cases) real names before uploading this information to an attacker-controlled server.

[Staff 10017]

Thank you lsat.

 

Kind regards

[lsat 23]

It may be interesting for you:

 

Even with a VPN, open Wi-Fi exposes users

[zhang888 1066]

 

 

It may be interesting for you:

 

Even with a VPN, open Wi-Fi exposes users

 

This article looks like a hidden commercial.

Network Lock, in case you use the Eddie client prevents exactly that, without too much marketing around it.

[zhang888 1066]

 

It may be interesting for you:

 

Even with a VPN, open Wi-Fi exposes users

 

 

 

This article looks like a hidden commercial.

Network Lock, in case you use the Eddie client prevents exactly that, without too much marketing around it.

[lsat 23]

Network Lock, in case you use the Eddie client prevents exactly that, without too much marketing around it.

I think there should be addtitional testing. You're too relax

I have a bunch of materials around open Wi-Fi and I'm not that positive as you are.

[zhang888 1066]

Share it

I actually took some time before to look into the way it was implemented, back then I didn't see anything wrong in that.

Assuming you aren't compromized by 3d party malware that will render any software solution on your machine useless.

[lsat 23]

Moreover as far as I know there is no mobile version in AirVPN which has network lock option. But it's primary a mobile users who suffer the most from open WiFi vulnurabilities.

[zhang888 1066]

I agree, and it's not that the Eddie client is bullet-proof either.

For example, even with the Network Lock on, the attacker can still drop the connections to Air's auth server,

the one that responds with the current servers list, making the user "giving up" on the OpenVPN connection

for this session. But that will require a more targeted attack against Air's client and thus a less likely scenario.

 

The mobile users security is totally in the hands of the application developers they prefer to use. For example,

WhatsApp will leak your phone number and IMEI even with invalid certificate in case of a MITM attack.

Many other apps are leaking as well, sometimes intentionally

[Staff 10017]

I agree, and it's not that the Eddie client is bullet-proof either.

For example, even with the Network Lock on, the attacker can still drop the connections to Air's auth server,

the one that responds with the current servers list, making the user "giving up" on the OpenVPN connection

for this session. But that will require a more targeted attack against Air's client and thus a less likely scenario.

 

Hi,

 

but in this case (we write especially for the casual reader, since this is obvious to you) Network Lock remains active. Even if the attacker manages an exploit to make Mono, .NET or the client "crash", the firewall rules stand. Eddie relies on a different software (pf, iptables or Windows Firewall) for Network Lock, and that's important.

 

Kind regards

[zhang888 1066]

Yes I was trying to elaborate a possible attack scenario on the Network Lock here, that will exploit a human social vector.

What will a common user will do in case the Network Lock is active, but an attacker prevents the client from connecting,

by making the auth server (http://54.93.175.114) unavailable?

I believe they will disable network lock at the best case, and in the worst case will continue using insecure Wi-Fi without VPN.

 

Btw, there is another vector here that I didn't test further but it can be possible as well.

A response from the auth server contains a list of all entry servers, and those are permitted in the firewall rule of the lock.

It might be possible to reverse engineer the response, and poison it to add more servers as fake Air's nodes, thus making

the lock extend it's rules to 3d party servers, for example ones that the attacker can use to leak info.

But again, this is also very theoretical and will require a tailored attack against an Air user over physical Wi-Fi.

[lsat 23]

 Network Lock remains active.

What about developing app for mobile devices with such feature? I'm more interested in this issue now.

Without field testing on real laptops with listening all network traffic it's useless to discuss Eddie reliability in open wi-fi anyway.

[Staff 10017]

Yes I was trying to elaborate a possible attack scenario on the Network Lock here, that will exploit a human social vector.

What will a common user will do in case the Network Lock is active, but an attacker prevents the client from connecting,

by making the auth server (http://54.93.175.114) unavailable?

 

 

Hello!

 

Understood. Some additional info: the attacker should make many more servers unavailable, not only the auth server. Additionally, Eddie will connect happily (provided that it connected at least once in the past and that the user did not erase the data files) even if the attacker finds and blocks to the client all the possible auth servers. Eddie will use the latest available information to find VPN servers. Once it connects to a VPN server, it tries to update all the data from inside the VPN.

 

Kind regards

[Staff 10017]

Btw, there is another vector here that I didn't test further but it can be possible as well.

A response from the auth server contains a list of all entry servers, and those are permitted in the firewall rule of the lock.

It might be possible to reverse engineer the response, and poison it to add more servers as fake Air's nodes,

 

Hello!

 

To succeed with that reverse engineering, the attacker must have something more. Note from the source code how Eddie communicates to retrieve manifest - or try snooping http traffic from/to Eddie: you should find immediately the missing element which makes this attack impossible as long as the attacker can't break in the backend servers (which are unknown even to Eddie).

 

See also https://airvpn.org/topic/11545-airvpn-client-eddie-beta-testing-phase/?do=findComment&comment=17709

 

Kind regards

[Staff 10017]

 

 Network Lock remains active.

What about developing app for mobile devices with such feature? I'm more interested in this issue now.

Without field testing on real laptops with listening all network traffic it's useless to discuss Eddie reliability in open wi-fi anyway.

 

Hello,

 

see here:

https://airvpn.org/topic/14231-ipv6-leakage-and-dns-hijacking/?do=findComment&comment=27633

 

It's the first scientific paper which focuses on some specific attacks, particularly possible in open WiFi (AirVPN has been tested as well) which our service is now immune to (the paper is outdated) but it's interesting anyway.

 

About the other theorized attacks in this thread, in our previous messages we wrote why they can't (should not) work. We'll be waiting for additional attacks the community can devise, they can be invaluable source of data to improve Eddie.

 

Kind regards