Researchers Hack Gmail With 92 Percent Success Rate 87
A reader sends this report from CNET:
Researchers at the University of California Riverside Bourns College of Engineering and the University of Michigan have identified a weakness they believe to exist across Android, Windows, and iOS operating systems that could allow malicious apps to obtain personal information. Although it was tested only on an Android phone, the team believes that the method could be used across all three operating systems because all three share a similar feature: all apps can access a mobile device's shared memory. "The assumption has always been that these apps can't interfere with each other easily," said Zhiyun Qian, an associate professor at UC Riverside. "We show that assumption is not correct and one app can in fact significantly impact another and result in harmful consequences for the user." To demonstrate the method of attack, first a user must download an app that appears benign, such as a wallpaper, but actually contains malicious code. Once installed, the researchers can use it to access the shared memory statistics of any process (PDF), which doesn't require any special privileges.
Yawn. (Score:3, Insightful)
So if I install malicious software, I can be hacked? Stop the presses!
Re: (Score:1)
"A user must download an app that appears benign". Unfortunately for me, I only download software that appears benign. I'm in trouble.
Re: Yawn. (Score:4, Funny)
Fortunaly Google dosen't accept mallware onto the market, so you should be pretty safe.
Re:Yawn. (Score:5, Funny)
We can't! They've been hacked!
Re:Yawn. (Score:5, Interesting)
There's an important detail which, for me at least, is surprising. From the paper:
"In this paper, we report that on the Android system (and likely other OSes), a weaker form of GUI confidentiality can be breached in the form of UI state (not the pixels) by a background app without requiring any permissions."
No permissions required, OUCH. The permission system was already considered useless, because all apps abuse permissions, but this really puts a nail in its coffin.
You download a simple Wallpaper app, or whatever, that requires no permissions to check your call data and other bullshit. What harm can it do, right? WRONG. If the flaw is in the window manager implementation, I wonder if this will be even fixed! And other OSes might be vulnerable.
Window Manager (Score:3)
And other OSes might be vulnerable.
Other OSes use other windows manager.
Android is the only one using "flinger".
Wayland for exemple is used by the Meago/Tizen/Sailfish OS family.
Same vulnerability won't expose other OSes, but on the other hand, other window manager could also be broken in a different way and be exploited by a different malicious app.
they all use memory. If app can check available me (Score:5, Informative)
If an app can see how much memory is available, it can use this technique. All operating systems use memory when they create a new window and when the create gui widgets such as input fields and buttons.
On their own machine , the malware author monitors free memory vs used memory. The click "buy now" in the eBay app. That open a "log in to PayPal " window. The malware author notes that opening the login window caused memory usage to increase by 23752 bytes.
The malware author creates an app that monitors how much memory is used. When memory usage jumps by exactly 23752 bytes, that means the PayPal login window is probably being opened. The malicious app pops up it's own window that looks like the PayPal login window. Since the user was expecting a PayPal login window at that moment, they enter their credentials. 5. Profit!
Note there's nothing unique to any operating system here. On any systwm, an application can find out how much memory and disk space is available, and therefore infer whether or not the PayPal login window is being opened, based on the precise amount of memory that window uses as it opens.
Re: (Score:1, Informative)
But on iOS another application cannot bring itself to the foreground over another app.
Putting it in practice = Difficult (Score:2)
This is hard to make working for several reasons.
First, as mentioned by others, not all OSes allow popup windows. WebOS for example, instead pops-up alerts in the lower status bar. The user is the only one who can switch around windows (cards, in webOS). The only exception is, when one application spawn another one, there is a distinct animation making a new card appear.
The second reason, is variability. Your example would require a single task system. In real life, even phone OSes are moving toward even mo
Re: (Score:2)
In The Netherlands most banks that use SMS do this. It's not hard to implement when your IT is already reasonably capable.
some good points (Score:2)
This wouldn't be a good assignment for Programming 101.
On the hand, it's trivial for the attacker to check the attributes of the new version of the PayPal app and post an updated signature file for his app to retrieve. The ability to draw on the screen or pop up a window / card / activity while in the background is key. One way to do that on all almost all operating systems is for the trojan to operate as a launcher. The "desktop" is actually the trojan, which launches the PayPal app for you and has s
Re: (Score:2)
Okay then, I guess we all might as well give up on security. After all, if we can just blame the user for downloading something malicious, then that's it, solved.
Alternatively though... we can make sure that one process can't get information from another one. How's about that?
mobile computers, bah (Score:4, Funny)
I'll stick to my snes.
Oh sure (Score:3, Informative)
Just because Android is flawed doesn't mean that iOS and Windows are flawed too.
Re:Oh sure (Score:5, Insightful)
The article that shows no proof that other OSes are vulnerable but asserts that these people "believe" those OSes might be? Yeah, sounds like rock-hard evidence there.
You need to RTFA (Score:3)
If you had you'd realize (a) it's not reading memory from another app, and (b) it's attacking by presenting a dialog box while another app is open, something that you cannot do in an iOS app store ap.
Blast from the past (Score:4, Interesting)
Blocking access to the memory space of other processes has been a solved problem since timesharing in the '60s and '70s, right?
I assume they aren't running in a flat address space with no MMU, so maybe the problem is that the apps all operate under the same user ID, which bypasses the usual multi-user protections. Perhaps "run each app with a unique user ID" will be something we'll see a lot of in the next few years, like the no-execute bit and ASLR were in the 2Ks?
Re:Blast from the past (Score:5, Informative)
Blocking access to the memory space of other processes has been a solved problem since timesharing in the '60s and '70s, right?
Sure it was. That isn't what is happening though.
Its not accessing the apps memory itself. Its accessing the shared memory *statistics* of a process.
Then its using pre-calculated patterns of the shared memory usage (presumably allocation order, sizes allocated, NOT the actual memory contents etc) to guess what the user is doing in the other app. Then, when it detects a pattern that corresponds with "I'm about to log in" it pre-empts the app with its own phishing login screen skinned to look like the original. The user is -expecting- a login screen to popup, and one that looks right does... so they enter their credentials.
I assume they...
All your assumptions and proposed solutions were completely wrong.
The solutions are:
a) to remove untrusted apps ability to monitor memory USAGE statstics
b) to remove untrusted apps ability to pre-empt the screen.
c) better permissions controls and better CURATION limiting
d) it may also help to let apps enter 'critical sections' that cannot be preempted by other apps (?)
Re:Blast from the past (Score:5, Interesting)
Corect me if i'm wrong.
In desktop and server os'the memory allocation is controlled by the os. So couldn't a solution be having the OS control direct memory acces and just present the ap with a table in order to mimic current practices and backwards compatability? Or would that be too much overhead for these devices?
Or am i way off base here?
Re:Blast from the past (Score:4)
Memory allocation is still controlled by the OS. (At least insofar as apps request memory from the OS, and release it back to the OS).
Normally, an app would have no need to know what another app was doing with memory. However, the instrumentation for another app to track the memory usage of another app exists and is not restricted to elevated / trusted apps.
Clearly it should be.
I can't honestly imagine what a regular app would need this for anyway. Its very much a 'task manager' or 'debugging tool' class of information - and only developers and system level apps need this information.
That along with the fact that apps should not be able to pre-empt eachother and go into the foreground on their own. (iOS apps for example, apparently can't pre-empt; unless they have exceptional permissions (e.g. sideloaded by developers or enterprises or if the device is rooted/jailbroken) so on ios even if the app can determine the app activity, it won't be able to prempt it with its phishing screen.
Re: (Score:3)
Re: (Score:1)
Re:Blast from the past (Score:5, Insightful)
Really? Android allows one app to take control of the screen and become foreground without explicit user interaction? There's the security flaw right there. The shared memory stuff is noise by comparison.
Re: (Score:2)
Hence my point:
"b) to remove untrusted apps ability to pre-empt the screen"
Its silly that this is possible, and hopefully we see patches real soon.
meta data (Score:2)
Re: (Score:2)
user_id+process_id
problem solved.
Re: (Score:2)
you still can't read the shared data of another process but the "signatures" can provide you with some idea of what the top-most activity is on the screen, something you cannot know otherwise unless you are the top-most activity or th
not reading memory, just see HOW MUCH shared memor (Score:5, Informative)
Android DOES run each app as a separate user, and one app cannot read another app's memory.
Processes have private memory and shared memory. Shared memory is used for communicating with other processes, such as the window manager.
An app can tell HOW MUCH shared memory another app is using. You see this in task manager, it'll tell you that your browser is using 12 MB of shared RAM or however much.
So the attack goes like this:
On their own device, the attacker monitors how much shared memory is being used by the Paypal app and the eBay app.
The they "pay now". The eBay app opens a "login to PayPal " window.
To display the window, the eBay app must communicate with the OS or window manager.
The attacker notes that when the app displays the login window, the amount of shared memory used increases by 26KB.
The attacker builds an app the monitors the amount of shared memory in use.
If the amount of memory in use jumps by exactly 26KB, that's probably because the "login to PayPal " window in being displayed.
The malicious app pops up it's own login window on screen, which looks just like the PayPal login window.
The user was expecting a PayPal login window, they see what looks-like a PayPal login window.
The user enters their PayPal credentials.
This is all based on knowing HOW MUCH memory is used vs available. From that, you can infer whwn another app opens a new window (activity).
Re: (Score:2)
tl;dr (Score:5, Informative)
Despite what the summary implies none of this is about actually reading memory in use by friendly apps. i.e. until the user gives the hostile app his account information the app knows nothing. All in all not a particularly powerful attack vector.
Re:tl;dr (Score:5, Interesting)
An immediate work-around would be to randomly place the log-in screen within a pre-determined area such that the hostile app would be unable to immediately overlap it. The double image will tell the user something is wrong.
The double image will tell the user something is wrong.
How is that a work around?
Its a phone. The login 'window' is going into a 3" to 5" space and is full screen in nearly every implementation. The 'popup' that the hostile app preempts simply covers the whole screen.
All in all not a particularly powerful attack vector.
Quite the opposite. Its a very powerful attack vector; and given the surprisingly good ability to time the pre-emption a very dangerous one.
Re: (Score:1)
Because they couldn't possibly spoof the dialog to enter the second authentication token? Riiiiiight.
Re:tl;dr (Score:4, Informative)
Its a very powerful attack vector
Yes and no.
I'd like to point out that the authors have only used the attack on Galaxy S3 devices running Android 4.2, for a very specific set of apps.
"We run all experiments on Samsung Galaxy S3 devices with Android 4.2. We do not make use of any device-specific features and expect our findings to apply to other Android phones."
Basically, they use the following (world-readable) elements to generate signatures of certain Activities (parts of apps) starting up.:
- CPU usage pattern
- Network usage pattern
- Increase and decrease of the shared memory (where the graphics buffer of the window compositor resides)
(they use more elements, but these are their most important ones: "Thus, the CPU utilization time, the network event and the transition model are the threemost important contributors to the final accuracy. Note that though the Content Provider and input method features have lower contributions, we find that the top 2 and top 3 candidates’ accuracies benefit more from them. This is because they are more stable features, and greatly reduce the cases with extremely poor results due to the high variance in the CPU utilization time and the network features.")
For the apps mentioned, they collect this data for a large number of the same Activities starting up. They average the results (model it using a normal distribution) and use that data as input for an offline machine learning step in which a model is generated.
On the 'hacked' device itself, they can then use the live data in their classifier and predict which Activity is starting up. When a specific target Activity is started up, they immediately start up their own mockup Activity and destroy it after the data has been entered, returning the user to the previous Activity with a misleading 'Server error' dialog in between. This method is what allows the injection to work without requiring the 'draw over other apps'-permission.
Now, anyone who has experience with machine learning can see how these results may not generalise very well, given that they used only a specific set of apps on a specific device. Choosing between 100 alternative Activities is a lot easier than choosing between the millions of Activities out there. How many signature collisions (false positives) would that lead to? A lot.
That is exacerbated by the fact that different users run different sets of apps in the background, which obviously greatly influences the CPU usage signatures and network signatures.
Besides that, the signatures are device and probably Android version specific, leading a model for many devices to become prohibitively large to be distributed in a single app. Of course, this can be mitigated by just targeting one specific very popular device (such as one of the Samsung flagship models).
Their injection of the activity is also something to look at again. Consider this:
"Note that the challenge here is that this introduces a race condition where the injected phishing Activity might enter the foreground too early or too late, causing visual disruption (e.g., broken animation). With carefully designed timing, we prepare the injection at the perfect time without any human-observable glitches during the transition (see video demos [6])."
Everybody knows that 'carefully designed timing' and generalisable match very poorly. Targeting one specific device may indeed work here, but I think some testing in more varied scenarios is required before we all shit our pants.
Re: (Score:2)
Everybody knows that 'carefully designed timing' and generalisable match very poorly.
Agreed -- however, a visible glitch or hiccup would that really set the majority of android users on guard? I'm skeptical.
Honestly, the entire timing element is almost superfluous; for a large number of users simply throwing up a fishing screen while they are IN another app would garner high success rates.
Launch gmail app... Popup "connection to server failed", "please enter username password". It would be horrifying to see
Re: (Score:2)
Granted the sophistication of a finely tuned and well crafted attack would mean even I'd fall for it without being any wiser
Although I agree with you in general, the thing is that you need to think of what the effects of a false positive are. Imagine starting up your game of solitaire and then seeing a Gmail-like login window. Because that is what could very well happen and would set off alarm bells in a fairly large set of users.
I suppose you could try to mitigate that by using a generic enough login window and only firing the phishing attack when the model is almost 100% confident that a login window is appropriate. After all,
Re: (Score:2)
Although I agree with you in general, the thing is that you need to think of what the effects of a false positive are. Imagine starting up your game of solitaire and then seeing a Gmail-like login window.
I'm not an android dev.. but on platforms I do write for, any app can determine the name of the foreground process/task.
So the worst that happens, is an oddly timed credentials box for the app you WERE using. That's going to set off far fewer alarm bells than you would think.
Re: (Score:2)
This is true and my pants are now definitely starting to change to a brownish hue. Knowing the currently running app greatly simplifies the task for the classifier.
This possibility and security risk is going to disappear in the next version of Android, but is very present in all current versions:
http://stackoverflow.com/quest... [stackoverflow.com]
'malicious apps' make me smile (Score:2)
Re: (Score:2)
Sounds more like a Nexus 6 out to get you.
summary (Score:5, Informative)
basically, a well-timed phishing attack.
1. in android, you can detect when the UI state changes (a new activity, or screen is brought to the foreground) by looking into a shared memory channel. this tells you nothing else other than that the UI state has changed.
2. you can build a "fingerprint" of a particular UI state change based on CPU utilization, network activity, process list, or possibly other things when the state change occurs. you can use this, plus #1 to know when *specific* UI state changes are occurring.
3. if you have managed to get a malicious app installed, and you know when a specific UI state change is occurring, the malicious app can impersonate the real UI state change, fooling the user into entering sensitive information.
No, hackers hacked Android apps via malware (Score:3)
They hacked Chase, Amazon, and a few other apps as well.
This has very little do to with GMail and more to do with a novel way to attack GUI based apps on the Android platform. By chance GMail had one of the highest success rates.
This would be like getting keylogging malware installed on your computer and then getting your your slashdot password compromised by reading keystrokes...and then saying Slashdot got hacked. No you computer go hacked, not Slashdot.
It also seems as GMail app gets updated it's rate might vary since this has to do with "guessing" what an app is doing by looking at system metrics.
Re: (Score:2)
You're saying that /. posted an inflammatory and inaccurate headline & summary? THAT HAS NEVER HAPPENED BEFORE.
did they... (Score:2)
did they try it on an account that has TFA?
Re: (Score:3)
It likely would depending on the second factor.
This is basically a phishing attack. It only uses the meta data of the memory to prompt a fake logon screen around the time you would expect one. So lets say your second factor is your home wireless network ssid and if you are not on it, it asks for a second passphrase. If they can time a popup asking for it right after the fish your normal log on, you basically give it to them unless you notice it.
"But we didn't test it on other platforms" (Score:3)
So I call "bullshit" on those claims. It shouldn't be that hard to test on iOS, and if you can find a Windows Phone, it should be easy to test there, too.
Not on iOS (Score:5, Informative)
Apps on iOS can't inject a dialog over top of another app, or even bring their own app to the foreground programatically, so this is not even possible on iOS. Maybe the app could monitor for actions, but it can't do anything with that info.
Re: (Score:1)
The restriction is very sensible actually. Programs should never replace the current activity or force focus on themselves. That is a flaw in other OSs, not a feature. If a background app wants to notify the user of something it can post a notification. It never needs to forcibly steal focus
Re: (Score:1)
Why this restriction in iOS, seems a pretty useless restriction to me. Agreed it works out well in this case, somewhat like builidng only one door in a house so it's safer.
Windows stealing focus from me has been a continual annoyance for years. I never liked half my sentence ending up in another window that decided to pop up. I hope IOS never changes this. On unix/linux I set the window managers so they don't steal focus. I like to be in control of the GUI, not the other way around.
I'll stick with my 3-button Jitterbug phone (Score:2)
Now get off my lawn.
Install Malware Get Hacked (Score:2)
So, installing malicious software means your information can be accessed? SHOCKING.
Re: (Score:2)
Re: (Score:1)
the hard way (Score:3)
TFA article isn't much more than an academic exercise. practically what they are doing makes little sense. if you want to know the foreground process, you don't have to look at shared memory and fingerprints. do this,
ActivityManager am = (ActivityManager) AppService.this.getSystemService(ACTIVITY_SERVICE); .topActivity.getPackageName(); ...
RunningTaskInfo foregroundTaskInfo = am.getRunningTasks(1).get(0);
String foregroundTaskPackageName = foregroundTaskInfo
PackageManager pm = AppService.this.getPackageManager();
PackageInfo foregroundAppPackageInfo = pm.getPackageInfo(foregroundTaskPackageName, 0);
that's it. start a service that queries this every 500ms or whatever. or, use this in conjunction w/ the shared memory "UI state change" trigger TFA article discusses. you now know the foreground app, activity, it's name, it's unique identifier, it's icon, everything.
this requires the android.permission.GET_TASKS but someone that's going to fall for a phishing attack isn't going to be aware enough to note that permission either.
Re: (Score:2)
The attack is more precise. Need to know precisely when to pop up the input form of interest. Sure this information could allow them to disambiguate the context so that a random memory change in a random app doesn't trigger a false positive. Of course the whole point was also to demonstrate how well they could do without any remotely suspicious permissions.
Re: (Score:1)
what they are doing makes little sense
Clue tip: If something appears to make little sense, you probably missed something. Your immediate response to that should be, "what am I missing?", not "okay, these professional scientists must be idiots who don't understand the topic they have Ph.D.s in as well as I do". Appeal to authority is bad, of course, but if you find yourself at odds with an expert, it should at least prompt a bit of self-critical examination to double-check where you might have missed something that, if you hadn't, would have m
Re: (Score:2)
Clue tip. just because someone has or is working towards a Phd, is head of a company, and so on, don't assume they are clever or smart. judge by the content. in the real world, simpler is better. i assume that applies to the world of digital attacks as well.
the article discusses a very convoluted and complicated way to perform a phishing attack. the point is you don't need to know anything more than the foreground process. e.g., run the "bank of whatever" app. when the login screen comes up, run your app an
Windows is vulnerable! (Score:2)
Mitigation... (Score:2)
So in the OS side, at the very least it seems that an obvious indication of application focus change would go a long way toward making this seem not right.
On the application side, I think applications that are likely to get sensitive information should always display a consistent randomized watermark in their application. Let's say they make an 'always at the top' bar with two randomized words. With that, the sensitive input forms that try to be phished will look incorrect because the watermark suddenly c