VPN Encryption Vulnerability On Android

An anonymous reader writes "Cyber security labs at Ben Gurion University have uncovered a network vulnerability on Android devices which has serious implications for users of VPNs. This vulnerability enables malicious apps to bypass active VPN configuration (no root permissions required) and redirect secure data communications to a different network address. These communications are captured in clear text (no encryption), leaving the information completely exposed. This redirection can take place while leaving the user completely oblivious, believing the data is encrypted and secure."

Comments

black listing all androids in 5..4..3..2..1

[Anonymous Coward]

I am going to need to update our companies VPN black list to include all android devices. End of story. Problem solution.

Re:black listing all androids in 5..4..3..2..1

[nurb432]

Better blacklist windows, apple, blackberry, desktops, laptops.... Everything is vulnerable. Even your users. Its how you mitigate the ongoing risk that separates the men from the boys.

If you are competent enough to use MDM on your mobile devices then your end users wouldn't be installing non-approved apps anyway so they would be at minimal risk of exposure to this. If you are not, then you are just a clueless blow-hard moron and don't deserve to be in your position..

Re: black listing all androids in 5..4..3..2..1

[Anonymous Coward]

Or, just don't depend on the embedded Android VPN and move to a MicroVPN that does not use the Native VPN client. Citrix Netscaler and other SSL VPN venders offer this and it has much better battery life and device performance in general since you are not using a fat client app.

Re: black listing all androids in 5..4..3..2..1

[JasonTeplitz]

Or, just don't depend on the embedded Android VPN and move to a MicroVPN that does not use the Native VPN client. Citrix Netscaler and other SSL VPN venders offer this and it has much better battery life and device performance in general since you are not using a fat client app.

Re:black listing all androids in 5..4..3..2..1

[DJRumpy]

Although a bit flippant, the parent does have a point. Most older Android devices will never see a security update or fix for this issue. It is what it is, and unless that changes, a valid response it to require a minimum level of OS on the device. This is one area where Apple excels and Android does not.

Re:black listing all androids in 5..4..3..2..1

[DarkOx]

If you are competent enough to use MDM on your mobile devices then your end users wouldn't be installing non-approved apps anyway

Bullshit Apple at least has gone out of their way to make this nearly impossible. Anything you can do to remove access to the App store with any of the MDMs while the device is on the carrier network is either trivially by passed by end users, or also make doing things like installing updates for approved apps completely broken.

At best you can deny micro VPN connections and sandboxed services when unapproved apps are detected, while possibly acceptable from a security standpoint its kind of closing the barn door after the horses are out for a user perspective. They just paid $5 for their app because they "forgot company policy about not installing other apps," and now your telling them they can't use it? Does not fly well.

Then there is the little matter of the fact you can't micro VPN just anything on IOS, unless its an in house app or the app vendor is willing to make ipks available, you are SOL. Which leaves you going back to things like AnyConnect or the builtin IPSec VPN; followed shortly by the users crying about how hard it is to type their password when they need to connect, so you say will okay we can use certificate only authentication but now we need a strong password on the device, and reasonable lock screen timeout, so we know its you and not the guy who grabbed it after you left in on the seat of the bus. When you do that they really pitch a fit.

IOS devices are a disaster in terms of DLP and asset management.

Things are a tad bit better on the Android side of the house with regard to MDM, yes. I am not so sure its much better on the over all security. There seems to be lots more malware in the wild.

As far as I know from a little testing with MDM demos provided by vendors and my contacts most of them fail utterly to actually detect rooted devices. They typically look for pirate ( as in radio, not warez) app stores and root tools. They often can't tell the kernel has been modified, boot loader is unlocked, etc if minor efforts to conceal the usual tools are under taken. As Corporate MDM becomes more common the rooting community is going to start making kits that are evasive and is almost sure to succeed given the current state of MDM. To say nothing of the true malware authors out there are probably already doing.

Re:black listing all androids in 5..4..3..2..1

[citizenr]

If you are competent enough to use MDM on your mobile devices then your end users wouldn't be installing non-approved apps anyway

Bullshit Apple at least has gone out of their way to make this nearly impossible.

Last time I checked ishit will connect over unsecured connection while VPN tunnel is being established instead of waiting for secure path.

Re:black listing all androids in 5..4..3..2..1

[badzilla]

I believe we need a new Godwin's law that kicks in the first time someone expresses their opinion by calling someone else a moron or an idiot. I sometimes run OpenVPN on my Android handset; The phone is my property, I am not an end user, and the reason I use OpenVPN is nothing to do with work. So no I do not have "MDM" and am also NOT A MORON.

Re:black listing all androids in 5..4..3..2..1

[0123456]

I am going to need to update our companies VPN black list to include all android devices. End of story. Problem solution.

Why would you let them on your corporate network in the first place? Who knows what random fluffy kitty screensaver apps users have installed that are happily stealing all your stuff and sending it to the Chinese government or Russian mafia?

Re:black listing all androids in 5..4..3..2..1

[nurb432]

The problem here is that i was responding to a post that was clearly related to a business environment and not in a 'consumer' environment. That you are not in that situation means your comments don't apply here, and you are taking mine out of context.

And just for the record, you are incorrect as you are an end user by definition ( which everyone is to some degree or another ), and you are also obviously a moron, with low reading comprehension skills.

Have a nice day.

Re:black listing all androids in 5..4..3..2..1

[Anonymous Coward]

Do you have to be so insulting, derogative, condescending and patronizing? It dilutes whatever point you are trying to make. Instead of coming across as an intelligent person worthy of discussion. Instead you lower yourself to a standard which I'm sure is beneath you. Being polite is what separates the men from the boys. It reminds me of this, http://www.penny-arcade.com/comic/2004/03/19

Re:black listing all androids in 5..4..3..2..1

[Anonymous Coward]

Just because you don't understand something doesn't make it "nearly impossible" for anyone else. If all you can do is spread FUD and demonstrate your ignorance about iOS in an Android story then your time is better spent elsewhere.

Re:black listing all androids in 5..4..3..2..1

[nurb432]

Do you have to be so insulting, derogative, condescending and patronizing?

Yes.

Re:black listing all androids in 5..4..3..2..1

[AmiMoJo]

It's not a security flaw, and even if it was Google could issue an update via Play to fix it for older devices. They have done just that in the past to close real holes.

Re:black listing all androids in 5..4..3..2..1

[Anonymous Coward]

If you are competent enough to use MDM on your mobile devices then your end users wouldn't be installing non-approved apps anyway

Bullshit Apple at least has gone out of their way to make this nearly impossible.

Last time I checked ishit will connect over unsecured connection while VPN tunnel is being established instead of waiting for secure path.

You may think it's cool to think up cute names, but by doing so you weaken your position to the point of I assume it's false instead of going out and researching to see if it's a valid complaint or not.

Re:black listing all androids in 5..4..3..2..1

[PNutts]

If you aren't an end user when you use the phone what are you?

Re: black listing all androids in 5..4..3..2..1

[Anonymous Coward]

You seriously don't see an issue with an app with user level access being able to redirect ALL net traffic on the phone?

Re: black listing all androids in 5..4..3..2..1

[Anonymous Coward]

Where did you get that it redirects all network traffic? My understanding is the venerabilty in question is about apps being able to ignore the VPN when communicateing on the public internet.

Re: black listing all androids in 5..4..3..2..1

[Anonymous Coward]

Nonsense. Spreading FUD is the bread and butter of Slashdot posters.

Re: black listing all androids in 5..4..3..2..1

[y5t3m]

The article demonstrates that it redirected unencrypted SMTP traffic out of the VPN. It's in point 4 of the steps.

Re:black listing all androids in 5..4..3..2..1

[HappyPsycho]

Just taking a look at http://en.wikipedia.org/wiki/List_of_iOS_devices I am seeing that the oldest phone supporting the current IOS version is the 4s.

From what little I know of the apple ecosystem if such a bug was found on a iPhone 3 the effective response would be the same (you are on your own, we don't support that any more).

I agree Apple is better at this but not for any reason other than they have a much smaller list of devices to deal with.

Re: black listing all androids in 5..4..3..2..1

[Anonymous Coward]

Or, just don't depend on the embedded Android VPN and move to a MicroVPN that does not use the Native VPN client. Citrix Netscaler and other SSL VPN venders offer this and it has much better battery life and device performance in general since you are not using a fat client app.

I felt compelled to correct myself - the SSL encryption and CPU usage offer are very similar to a standard SSL VPN with remote IP per release notes I have re-read..

Re:black listing all androids in 5..4..3..2..1

[DJRumpy]

You are making the false assumption that when Apple releases a new OS, they stop supporting the old. That is not the case. They continue to path them.

Re:black listing all androids in 5..4..3..2..1

[Anonymous Coward]

Although a bit flippant, the parent does have a point. Most older Android devices will never see a security update or fix for this issue. It is what it is, and unless that changes, a valid response it to require a minimum level of OS on the device. This is one area where Apple excels and Android does not.

older as in, how old?

Re:black listing all androids in 5..4..3..2..1

[Anonymous Coward]

Posting anonymously for obvious reasons but it should be obvious that no MDM vendor can reliably detect rooted devices if the device owner doesn't want that state to be detected - rooting has given them complete control of the device after all. Unfortunately after one vendor starts crowing about how they can detect rooted devices, everyone has to say they do, to keep the suits who actually decide which MDM solution to purchase happy. The MDM / Mobile security field is absolutely packed full of cowboys, including at least one well known vendor who've been known to show off features that they "have in beta" during demos that rely on APIs that Apple haven't actually started writing at the time of the demo.

Re:black listing all androids in 5..4..3..2..1

[Anonymous Coward]

You are making the false assumption that when Apple releases a new OS, they stop supporting the old. That is not the case. They continue to path them.

My iOS device can't receive updates. Apple has abandoned it. I can't even update apps any more because almost all updates (even for security issues) require the newer OS.

Re: black listing all androids in 5..4..3..2..1

[Anonymous Coward]

Sounds like your developer doesn't support your apps.

Re:black listing all androids in 5..4..3..2..1

[haruchai]

I found that the stock VPN on our Samsung Galaxy S4s didn't work very well with our Cisco IPsec VPN so no one bothered.
A trial version of VPNcilla I tested last week did work just fine but I guess we'll wait to see if this gets fixed first.

Re:black listing all androids in 5..4..3..2..1

[Anonymous Coward]

People with that level of insecurity arent interested in helping or educating other people thus removing the need to be polite. IRL such people are severely introverted and the anonymity and lack of real confrontation on the internet is their escape.

Re:black listing all androids in 5..4..3..2..1

[exomondo]

Just taking a look at http://en.wikipedia.org/wiki/List_of_iOS_devices I am seeing that the oldest phone supporting the current IOS version is the 4s.

From that page it looks like the 4 is the oldest, supporting the current iOS 7.0.4.

Re:black listing all androids in 5..4..3..2..1

[tlhIngan]

From what little I know of the apple ecosystem if such a bug was found on a iPhone 3 the effective response would be the same (you are on your own, we don't support that any more).

Well, the iPhone 3G is 6 years old at this point - around the era of the HTC G1 (Dream) as the first released Android device out there. So losing support for it isn't completely unexpected.

Actively run the exploit...

[Kwyj1b0]

TFA says that you need to run a malicious app that intentionally exploits that system. They tested multiple android devices (and I'm assuming different versions of the OS). Also, does this work with every VPN service (like Cisco AnyConnect), or only the native system?

Would it be possible to test if any existing Play store app accidentally/intentionally triggers this exploit? I (like many Android users) don't pirate apps (even though my phone is rooted), but if the popular Play store apps are compromised, that would be a big deal for me.

Re:Actively run the exploit...

[Anonymous Coward]

Flexible network redirection is there to help those apps that don't normally connect to secure servers to bypass those pesky secure connections when sending your personal data. It's not a bug, it's a feature.

Re:Actively run the exploit...

[amorsen]

A VPN client app works by redirecting traffic away from its normal destination and towards a VPN server. It is obvious that if you allow two VPN apps to run at the same time, they get to fight over who gets to redirect the traffic -- and one of them could be nasty and redirect it to a malicious VPN server, with or without encryption.

You could restrict it so that only one VPN client app is allowed to run at a time, but it is not clear to me that it would improve security significantly. A malicious app with VPN permissions is going to be able to do really nasty things anyway. Do not install untrusted apps with VPN permissions.

apply for your 'ordinary citizen' profile status

[Anonymous Coward]

using POT (Personal Open Terminal) should not skew the results?

Not a vulnerability

[AmiMoJo]

This isn't a vulnerability at all. Apps can choose to ignore the default routing. Same on many operating systems. Windows and Linux, for example.

Re:Not a vulnerability

[wbr1]

I also don't see the huge issue here. Perhaps this is the fabled clickbait?

If an app is malicious and running on a machine, of course it can reroute, or look at data in RAM pre-encryption, or a number of other things.

If you want to be more secure, then only do secure comms on a trusted network, where any VPN routing is done outside of your potentially compromised device, and other routes are blocked.

Re:Not a vulnerability

[naughtynaughty]

In this case the assertion is that a malicious app that doesn't have root privileges can re-route traffic. Apps without root can't reroute traffic, or look at RAM, controlled by other apps. If you know of a way for an unprivileged app on a Linux or Windows box to intercept and re-route a VPN connection, let us all know how it is done.

Re:Not a vulnerability

[satcomjimmy]

But in most other operating systems you can discern the routes rather easily. You can even change them easily. It is a vulnerability in my eyes. I expect turning on VPN to an alternate destination will encrypt and route ALL of my traffic to that endpoint.

Re:Not a vulnerability

[DarkOx]

I was going to say this too. I have done a bit of sockets programing on Windows, Linux and AIX and I don't know of anyway to change the next hop for route for any traffic, especially traffic not from my application that does not require elevated privileges.

More broadly speaking though all these platforms have gotten so large and complex any security at all is at this point I think largely and illusion. As long as security is based around people deploying quick prophylactics like "I'll use VPN and just encrypt all the traffic" we are going to continue to get burned every time someone discovers a little used API that turns on source routing or similar. The same is largely true for "run it in a vm" or "add a sandbox".

Probably until someone develops an entirely new platform with the realities of modern networks in mind every step of they we will continue to get pwnd.

Re: Not a vulnerability

[Anonymous Coward]

Google will never provide a VPN which cannot be bypassed by apps. Otherwise one could make a VPN which is really just a proxy that filters away all ads and other spy junk connections.

Re:Linux=good, NSA=bad

[Anonymous Coward]

Did I get it right???

That all depends on who you ask ... or if your statement gets to its intended recipient unaltered.

Whew

[oodaloop]

Good thing I don't use a VPN on my android phone! I might have been exposing my data!

google reply ?

[tleaf100]

and have google known about this for very long ?

"trivially by passed by end users"

[nurb432]

And is grounds for termination on the spot. Circumvention of corporate resources is frowned upon.

Sure MDM isn't *perfect* ( same as "everything is vulnerable"... ) but it goes a long way to prevent people from doing wrong things, and goes even further to help catch them doing it.

Now, that out of the way, some vendor's MDM is far better than others, sounds like you have been involved with the 'not as better' group.

Re:"trivially by passed by end users"

[Anonymous Coward]

That depends on a number of things:
1) A well defined corporate policy.
2) Who owns the device.
3) Who pays the bill for the device.

This whole area is a major headache for any real security consultant. As companies tend not to want to spend $600 per user just for a corporate phone, unless the cost can be justified. They also can't justify the cost of paying the bills for said devices. If they are not handling both of these then the device in question is a personal device, not a company device, and the user is free to do what ever they want with it despite company policy.

Now if the company is doing both things then it falls to company policy, and you have to pray that this policy is both a good one and well enforced. In general companies tend not to give more than slap on the wrist to individuals who are important enough to receive said company devices. A new hire who violates policy may be fired immediately, while a CEO will amend policy or add an exemption to make what he did acceptable. This is where the nightmare begins. A new hire is not likely to be trusted with company hardware to take home, while a CEO may insist on it. This makes, the people who have access to the most sensitive data are the biggest security risk. Now you try telling your boss he can't install that lovely new and addictive game in 'his' phone. DarkOx has a much more realistic perspective on this.

Re:"trivially by passed by end users"

[Anonymous Coward]

the device in question is a personal device, not a company device, and the user is free to do what ever they want with it despite company policy.

You can at the risk of being fired in my state. This whole "it's mine so I can do anything I want" is tedious, particularly when you've agreed to a company policy or signed an agreement.

Re:"trivially by passed by end users"

[DarkOx]

if the company is doing both things then it falls to company policy, and you have to pray that this policy is both a good one and well enforced. In general companies tend not to give more than slap on the wrist to individuals who are important enough to receive said company devices.

^^^This

Every company I have ever worked at or contracted with has an IT AUP that spells out some rules and says violation can be grounds for immediate termination. I have never see it used that way except once; when two employees one male and one female were caught watching porn together in his office. I am pretty sure even in that case while the AUP violation was cited for the offical reason for the firings (provided the legal out) HR was probably more worried about the future sexual harassment lawsuits the behavior of these two likely would put the company in jeopardy of in the future.

Otherwise what usually happens is some middle level IT manager as a "response" to the incident report drafts off an carefully worded e-mail to the effect of "you know that isn't allowed and please stop," It never goes further than unless the offender is really unimportant in which case its possible his or her manager might be CC'ed on such e-mail and that person will do something if and only if they are looking to create fear among their other reports or they have some other personal problem with the offender. This is the case even if the offending behavior does not actually stop.

There is franckly no way anyone at the pay scale (which isn't even very high) to be issued an iPhone on the companies dime is going to face retribution for installing un-approved apps. Its far more likely they will convince their manager to make up some garbage for IT about how he has to have Angry Birds to do his job entertaining clients or something.

Re:"trivially by passed by end users"

[Anonymous Coward]

... This whole "it's mine so I can do anything I want" is tedious, particularly when you've agreed to a company policy or signed an agreement.

So if I hire you, I get to tell you how to use all of computing devices you own? Sweet. Want a job?

Re:"trivially by passed by end users"

[Anonymous Coward]

So if I hire you, I get to tell you how to use all of computing devices you own?

no he didn't say or imply that at all.

Misleading Title

[Freeman-Jo]

This doesn't sound like vulnerability on the encryption at all but rather Android allow modification of routing table instead. This means any existing encryption stay in tact, just rather the data is going to be re-routed out of the VPN tunnel.

Re:Misleading Title

[naughtynaughty]

The article states that not only can the traffic be re-routed but it can be re-routed unencrypted. From the summary: "These communications are captured in clear text (no encryption)" The vulnerability bypasses the encryption and the routing.

Re: Misleading Title

[Anonymous Coward]

Routing the traffic through the VPN tunnel is what provides the encryption in this case, so the exploit is only indirectly bypassing the encryption. It's bypassing the entire tunnel and the encryption that goes along with it. Any traffic that's already encrypted before being sent though the tunnel will still be encrypted with this exploit.

Can update

[Anonymous Coward]

Many devices can update to Cyanogenmod. Mine has Android 4.2.2 as Cyanogenmod 11,without Google apps, so maybe NSA & Google access to mine is minimal.

Re:Can update

[viperidaenz]

Mine has Android 2.3, because CM7 is the latest version for my device.

Re:Can update

[Anonymous Coward]

Those who aren't virgins don't spend their days messing with custom ROMs though.. We just want our phone to bloody work and be secure.

Re: Can update

[glem.dot]

'To just work AND be secure.' Seriously? Sometimes I'd like to live in your fantasy world. It would be simpler. Far simpler. Your kind is needed though. Having more thinking people could upset the balance between those who command and those who mindlessly obey. Wait, lemme rephrase that: Between those who command and those who use things 'that just work and THINK are secure'. And aren't virgins, of course. That's important.

Re:Can update

[fluffy99]

Many devices can update to Cyanogenmod. Mine has Android 4.2.2 as Cyanogenmod 11,without Google apps, so maybe NSA & Google access to mine is minimal.

The list of Cyanogenmod supported devices is small compared to the wide variety of devices out there. The point about support of older devices still stands as even Cyanogen is dropping support for moderately old devices because they'd prefer to focus on supporting emerging devices.

Re:Can update

[L4t3r4lu5]

XDA Developers can help you with that. Unofficial CM releases, ports from other devices... Your device definitely has at least ICS available.

My Desire HD has Jelly Bean, despite CM only supporting 2.3.

Re:Can update

[viperidaenz]

I think you need to fix the character encoding in your signature. slashdot uses uft-8
  looks fine if you encode it right. £

Re:Can update

[L4t3r4lu5]

££££
And yet this is the only website where this happens. Tell me again how I've somehow messed up the character encoding :)

The ironic thing is that the sig's are parsed correctly; I had to add the à characters manually to illustrate the issue.

After preview, it turns out that the comment parser messed up that character too, and now has a tilde instead of a circumflex.

Disclosure on Friday afternoon

[amorsen]

I am a fan of full disclosure and all that, but does it have to be done on a Friday afternoon? Could you not sit on the bug for just one weekend and disclose it on Monday morning, so there is a chance that the right engineers to fix it are available?

Re:Disclosure on Friday afternoon

[tqk]

Where's the fun in that? Sheesh.

Re:Disclosure on Friday afternoon

[Anonymous Coward]

They did not publish the actual bug.

Re:Disclosure on Friday afternoon

[tlhIngan]

I am a fan of full disclosure and all that, but does it have to be done on a Friday afternoon? Could you not sit on the bug for just one weekend and disclose it on Monday morning, so there is a chance that the right engineers to fix it are available?

Does it really matter? I mean, if Google fixes it in 4.4 on Monday, that still leaves almost every Android phone vulnerable as they won't get the patch, ever. The Nexus line doesn't form a huge part of the Android market.

I don't think it's something that can be fixed without an OS update - unless Google Services Framework can hitch even deeper into the OS.

Re:Disclosure on Friday afternoon

[thetoadwarrior]

There's no point in waiting. Android updates are hopeless.

But isn't that normal?

[MichaelSmith]

Your VPN is one network interface going this way but you still have other interfaces on different IP addresses going that way and applications are free to choose which they use.

Re:But isn't that normal?

[flyingfsck]

Totally. This is not a security problem with Linux/Android. This is what happens when you install malware on a computer.

Network vulnerability on Android devices?

[DTentilhao]

"Now the user runs the malicious app and clicks on the Exploit button which takes advantage of the vulnerability in the phone’s system"

All I see is, if you run an app on your own device then you can capture your own network traffic. If this ` malicious app ' can't get onto the device without user action then this isn't a vulnerability in Android.

Re:Sysadmins don't get to set smartphone policy.

[Anonymous Coward]

You sound like a self-important little shit.

someone

[Anonymous Coward]

This means that the solution Samsung offered for the first vulnerability found in KNOX (reminder: the solution was use VPN) does not solve the problem.

Works as intended

[thetoadwarrior]

Sounds like something they'd do for their buddies in the NSA.