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!
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.
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.
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.
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.
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).
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.
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