Slashdot Mirror
Researchers Hack Gmail With 92 Percent Success Rate
SternisheFan 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.
So if I install malicious software, I can be hacked? Stop the presses!
Dumb phone it is. Screw this "smart"phone BS.
I'll stick to my snes.
Just because Android is flawed doesn't mean that iOS and Windows are flawed too.
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?
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
The article indicates that popups can probably be presented (by the hostile app) at appropriate times that allow it to steal passwords and user names. That is the full extent of the vulnerability. Most of it discusses clever side-channel attacks to learn when to present the popup. (what the user is probably doing at the time) 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.
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.
If video games influenced behavior the Pac Man generation would be eating pills and running away from their problems.
that phrase sounds like a Star Wars villain from planet Samsung5.
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.
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.
did they try it on an account that has TFA?
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.
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.
I don't download anything from the playstore and I don't even use an email app for my emails on mobile.
Now get off my lawn.
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).
So, installing malicious software means your information can be accessed? SHOCKING.
Yeah, I'm that guy.
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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.
I thought the NSA said the use of meta data was not too intrusive. That's sarcasm... of course it can be, most on Slashdot knows that. But maybe this is a good wake up for the average person on what accessing meta data can do. The problem would be explaining what shared memory is. :)
-- I ignore anonymous replies to my comments and postings.
But on iOS another application cannot bring itself to the foreground over another app.
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.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The fact that the anyone from Riverside where able to hack into an account should make anyone scared.
If I install a debugger on it, I can read passwords!!!!!
OSs are not written with the mindset of programs being written that should function on a need to know basis. Doing so really is making yourself a prisoner to malware writers would can always find a way to eek out little bits of info and for which you'll make the system horrible trying to combat the problem. And given the whole scenario presumes you installed malware and are trying to somehow jail it...you really should focus more on removing the program and less on trying to keeping it running while jailing it.
Now as for the part about one app pre-empting the UI of another, yes, that's just bad design. Anything that pops over, pops under, pops around, or pops in any other way and steals focus is obviously a hindrance to the user's experience--and honestly the OS itself (*cough*balloons*cough*)can't be necessarily trusted to do a good job of it, so it's not merely a matter of per-se "trusting" the program. This falls into the same scope as properly labeling windows to avoid confusion/fraud upon the user--and this includes, honestly, naming your program "web browser" in the titlebar.
Of course, it's turtles all the way down, so at some level you need for a certain level of "trusted" programs to deal with all this UI business while hiding their own names or pre-empting things on the user's request. So, yea, Android has a long way to go on this front. Especially when it comes to their system of one-time approving a swath of permissions and no real mechanism to revoke permissions system wide on 99% of apps or generally manage permissions. But, then, that's a problem that seems to exist in every UI I've seen when it comes down to it.
this is not science... advertisment attack...
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 more multi-tasking. The 23752 bytes you mention will be lost in a sea of other memory change. Maybe the malicious application, between probes, would register an increase of memory consumption of about 67849 bytes, because not only paypal's page was opened, but also between the memory check the user received an message and the messaging application started automatically downloading the attached picture. (And that's just taking into acount application with direct memory management. Now, if you add in the mix languages that use deffered garbage collection, memory consumption gets even weirder).
Third reason is also availablity. You example require the paypal page to always have the exact same size down to the byte in order to be easily recognisable. Saddly, in real life, developers are constantly tuning their code. It might be 23752 today, it could be 34756 tomorrow. And that's just the size it-self. You've probably noticed, but nowadays every single company feels compelled to re-invent their interface, Facebook is far from having the monopolly on completely changing its interface whenever somebody sneezes. That means that the bogus paypal page displayed by the attacked software might look like an older version instead of looking like all other current instances. (Now, that's not a guarantee that the user will notice that something is fishy. Less attentive users will probably dismiss it as "Meh, another of these almost-weekly UI re-invention"). Still, these kind of change will make it terribly difficult to use the free memory tracking that you propose.
Last reason: banks. Some banks ask the user to confirm the transaction out-of-band (mine does make confirm credit-card transaction). A user thinking to buy an In-App extra 10$ with paypal would be surprised to receive an SMS asking confirmation for a credit-card transaction of 10'000$.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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 changes.
XML is like violence. If it doesn't solve the problem, use more.
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 some degree of control over it's children. Remember Windows Active Desktop, where the desktop could host web widgets because it was rendered by IE4 and could be scripted eith VBScript? I certainly never took advantage of that.
No reason why that same kind of attack would not work on Windows or iOS either.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)