Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Researchers Hack Gmail With 92 Percent Success Rate

Soulskill posted about a month ago | from the good-enough-for-an-A dept.

Android 87

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.

cancel ×

87 comments

Sorry! There are no comments related to the filter you selected.

Yawn. (3, Insightful)

Anonymous Coward | about a month ago | (#47732827)

So if I install malicious software, I can be hacked? Stop the presses!

Re:Yawn. (1)

Anonymous Coward | about a month ago | (#47732987)

"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. (0)

Anonymous Coward | about a month ago | (#47735309)

"A user must download an app that appears benign". Unfortunately for me, I only download software that appears benign. I'm in trouble.

You need to quit that and start downloading apps that look like trouble!! It's the only way to be safe! :P

Re: Yawn. (3, Funny)

Lussarn (105276) | about a month ago | (#47735349)

Fortunaly Google dosen't accept mallware onto the market, so you should be pretty safe.

Re:Yawn. (4, Funny)

ArcadeMan (2766669) | about a month ago | (#47732997)

Stop the presses!

We can't! They've been hacked!

Re:Yawn. (5, Interesting)

SansEverything (3785255) | about a month ago | (#47733083)

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.

Re:Yawn. (-1)

Anonymous Coward | about a month ago | (#47733163)

Oh no! I also heard today that hackers can turn your computer into a bomb!!! [homelandsecureit.com]

Window Manager (2)

DrYak (748999) | about a month ago | (#47733539)

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 (5, Informative)

raymorris (2726007) | about a month ago | (#47733765)

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:they all use memory. If app can check available (1, Informative)

Anonymous Coward | about a month ago | (#47733917)

But on iOS another application cannot bring itself to the foreground over another app.

Putting it in practice = Difficult (1)

DrYak (748999) | about three weeks ago | (#47735521)

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$.

Re:Putting it in practice = Difficult (0)

Anonymous Coward | about three weeks ago | (#47735567)

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$.


Where do banks do that? All the out of band confirmations I've seen from banks have the template "your security code is xxxx". There is no information on the transaction being done (or the amount) because you are presumably not doing concurrent transactions to control which one is which. It's only after the fact that you may receive a "xxx$ cash has been withdrawn", but you typically have to set that up manually.

Re: Putting it in practice = Difficult (0)

Anonymous Coward | about three weeks ago | (#47735973)

My bank, DBS, sends me an SMS with all the transaction details, including vendor and charge amount. The limits are configurable, for example over SG$500. Very useful.

Re:Putting it in practice = Difficult (1)

St.Creed (853824) | about three weeks ago | (#47736631)

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 (1)

raymorris (2726007) | about three weeks ago | (#47736213)

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.

Re:Yawn. (0)

Anonymous Coward | about a month ago | (#47734805)

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.

No permissions? They mention system alerts and overlays which require the android.permission.SYSTEM_ALERT and android.permission.SYSTEM_OVERLAY permissions respectively.

How are they popping up things on top of other apps without these permissions (which would be pretty suspicious in most apps)?

I think the warning that popups up for apps requesting these permissions specifically mentions that they may be used for phishing attacks.

Re:Yawn. (0)

Anonymous Coward | about a month ago | (#47733261)

Holy shit. This is really the only comment that needs to be said. Everything else is redundant.

Re:Yawn. (1)

beelsebob (529313) | about a month ago | (#47733413)

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?

toad (1)

For a Free Internet (1594621) | about a month ago | (#47732829)

Reality is in a state of fluxe, so is Don Quixote himself. Toads are the only ideal, unchanging form. Meditiate on that, "researchers," if you dare, you thing with thing in the helmet of a thing barber toad thinrfe.

What's coming up next... (0)

Anonymous Coward | about a month ago | (#47732839)

Dumb phone it is. Screw this "smart"phone BS.

mobile computers, bah (4, Funny)

Anonymous Coward | about a month ago | (#47732847)

I'll stick to my snes.

Oh sure (3, Informative)

Anonymous Coward | about a month ago | (#47732871)

Just because Android is flawed doesn't mean that iOS and Windows are flawed too.

Re:Oh sure (0, Flamebait)

Noah Haders (3621429) | about a month ago | (#47732893)

Agreed. In ios it's sandboxes by design so no app can access any other app's memory. Android sound more and more like windows Xp.

Re:Oh sure (0)

Anonymous Coward | about a month ago | (#47733017)

accessing memory and accessing metadata about the memory are different things. you sound more and more like an idiot. RTFA, fanboi.

Re:Oh sure (5, Insightful)

Anonymous Coward | about a month ago | (#47733173)

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.

Re:Oh sure (0)

Anonymous Coward | about a month ago | (#47733893)

it is certainly rock-hard evidence that they believe it, no?

you're an idiot.

Re:Oh sure (0)

Anonymous Coward | about a month ago | (#47733931)

They can believe all they want. Doesn't make it so.

You need to RTFA (2)

SuperKendall (25149) | about a month ago | (#47734151)

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.

Re:You need to RTFA (0)

Anonymous Coward | about a month ago | (#47735335)

Here's a closer look at this issue...

http://www.itproportal.com/2014/08/23/a-closer-look-at-the-gmail-smartphone-app-hack-and-its-wider-implications/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+itproportal%2Frss+%28Latest+ITProPortal+News%29

Re: Oh sure (0)

Anonymous Coward | about a month ago | (#47734593)

Just because they did it on android doesn't mean iOS and Windows are safe. In fact, iOS and Windows are NOT safe. NO OPERATING SYSTEM IS. Anyone who claims their OS can't be hacked is just begging for hackers to prove them wrong.

Blast from the past (3, Interesting)

Megane (129182) | about a month ago | (#47732899)

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 (5, Informative)

vux984 (928602) | about a month ago | (#47732993)

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 (4, Interesting)

sumdumass (711423) | about a month ago | (#47733075)

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 (3)

vux984 (928602) | about a month ago | (#47733231)

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.

Need to Know Basis (0)

Anonymous Coward | about a month ago | (#47735019)

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.

Re:Blast from the past (2)

Cley Faye (1123605) | about a month ago | (#47733671)

Can't tell if you way off, because what you described is roughly what is already happening. Each app have it's own virtual memory space. Part of the "issue" described here is accessing memory *usage statistics*, not access to memory itself, which would be pretty bad if it could happen without any kind of escalation/debugging tools.

Re:Blast from the past (1)

x181 (2677887) | about a month ago | (#47733199)

the main thing is that the virtual memory statistics are relatively clean. it seems only memmapping, shared libraries and graphics buffers for compositing produce obvious changes in virtual memory statistics, with compositing taking up almost all of the obvious changes. introducing randomized noise into the virtual memory usage at the kernel level would drastically cut down on this attach vector. it would tie the security of the kernel's randomization to the virtual memory usage.

Re:Blast from the past (4, Insightful)

dgatwood (11270) | about a month ago | (#47733347)

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.

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:Blast from the past (1)

vux984 (928602) | about a month ago | (#47733561)

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 (1)

theshowmecanuck (703852) | about a month ago | (#47733827)

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

Re:Blast from the past (1)

ArcadeMan (2766669) | about a month ago | (#47733013)

user_id+process_id

problem solved.

Re:Blast from the past (2)

x181 (2677887) | about a month ago | (#47733079)

yeah that is private memory. the article is about an attack vector based on changes in shared memory usage ("signatures") for when the OS does its UI compositing. shared memory is used to avoid copying graphical data when a client-based window manager does its compositing.

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 the system-level ActivityManager. if you know the top-most activity, you may have a better idea of what type of attack to launch.

not reading memory, just see HOW MUCH shared memor (5, Informative)

raymorris (2726007) | about a month ago | (#47733157)

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:not reading memory, just see HOW MUCH shared me (1)

TemporalBeing (803363) | about three weeks ago | (#47749693)

No reason why that same kind of attack would not work on Windows or iOS either.

tl;dr (4, Informative)

Iamthecheese (1264298) | about a month ago | (#47732933)

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.

Re:tl;dr (4, Interesting)

vux984 (928602) | about a month ago | (#47733097)

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:tl;dr (0)

Anonymous Coward | about a month ago | (#47733203)

Now they can work on getting logged in on another device. Oops, they can't - I use Google's (and Yahoo's and Microsoft's) two factor auth. Looks like just knowing my password did not get them where they thought they were going...

Re:tl;dr (1)

Anonymous Coward | about a month ago | (#47733229)

Because they couldn't possibly spoof the dialog to enter the second authentication token? Riiiiiight.

Re:tl;dr (3, Informative)

dinfinity (2300094) | about a month ago | (#47733309)

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:tl;dr (1)

vux984 (928602) | about a month ago | (#47733527)

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 how high a success percentage that gets you."

This attack is impressive in that it generates 98% success rate at detecting and invisibly injecting its phishing screen 'just so'. But honestly -- they'd probably snatch a shocking high portion of credentials simply timing the popup to coincide with 1-2 seconds after a given app starts for a large number of apps.

Granted the sophistication of a finely tuned and well crafted attack would mean even I'd fall for it without being any wiser, and it enables them to go after some more complicated apps, in more complicate scenarios. And yes, a finely tuned profile using knowledge about the particular model of phone, and particular application set etc are required for to pull it off.

But the reality remains that the low hanging fruit (dumb users + easily predictable apps) is going to be very easily harvested.

Re:tl;dr (1)

dinfinity (2300094) | about a month ago | (#47733699)

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, if you can have your app run in the background for several months (or longer), you can afford having it bide its time and wait for the perfect opportunity.

The question then becomes how confident the model can really be. Various methods would probably have to be included to boost the confidence. Checking which apps are installed and only attacking devices that have a pretty default set of FacebookGmailWhatsappCandyCrush apps installed would mitigate the issue of having to deal with colliding signatures of unmodeled apps.

The attack app could even retrieve collect a list of processes ran on the device and/or installed apps, the device type, Android version etc., and then request a classifier from a server, if one exists for that combo. Perhaps different versions of apps could still pose a problem, though.
In addition to the classifier, the app could also retrieve the tuning parameters for that specific device/Android version from a server.

Hmm. It seems a turtle head actually is starting to poke out.

Re:tl;dr (1)

vux984 (928602) | about a month ago | (#47733761)

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:tl;dr (1)

dinfinity (2300094) | about a month ago | (#47733853)

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 (1)

turkeydance (1266624) | about a month ago | (#47732947)

that phrase sounds like a Star Wars villain from planet Samsung5.

Re:'malicious apps' make me smile (1)

ArcadeMan (2766669) | about a month ago | (#47733025)

Sounds more like a Nexus 6 out to get you.

summary (4, Informative)

farble1670 (803356) | about a month ago | (#47733001)

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.

Re:summary (0)

Anonymous Coward | about a month ago | (#47734757)

So basically android is designed to be faulty. Why can an android app "take over" the screen without an interaction from the user?

No, hackers hacked Android apps via malware (2)

Twillerror (536681) | about a month ago | (#47733005)

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:No, hackers hacked Android apps via malware (-1)

Anonymous Coward | about a month ago | (#47733129)

tl;dr: Android is for faggot fucks and they're getting it in the ass again.

Re:No, hackers hacked Android apps via malware (0)

Anonymous Coward | about a month ago | (#47733201)

And for some reason they've recently wanted to be buttfucked by Google even more than iOS users love getting fucked by Apple.

Re:No, hackers hacked Android apps via malware (0)

Anonymous Coward | about a month ago | (#47734929)

Time to switch to FirefoxOS

Re:No, hackers hacked Android apps via malware (1)

Nimey (114278) | about a month ago | (#47733443)

You're saying that /. posted an inflammatory and inaccurate headline & summary? THAT HAS NEVER HAPPENED BEFORE.

did they... (1)

MoFoQ (584566) | about a month ago | (#47733023)

did they try it on an account that has TFA?

Re:did they... (2)

sumdumass (711423) | about a month ago | (#47733123)

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.

Re:did they... (0)

Anonymous Coward | about a month ago | (#47734471)

an account that has TFA.

You mean a CNET account? That's where TFA is hosted according to the Slashdot summary, but it's against Slashdot culture to RTFA before commenting, so I can't be sure it isn't just a link to another site with the real article.

Pro-tip: Try writing in English next time, instead of cute 3 letter acronyms that might mean different things to others.

"But we didn't test it on other platforms" (2)

david.emery (127135) | about a month ago | (#47733073)

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 (4, Informative)

pherthyl (445706) | about a month ago | (#47733093)

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:Not on iOS (0)

Anonymous Coward | about three weeks ago | (#47735819)

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.

Re: Not on iOS (0)

Anonymous Coward | about three weeks ago | (#47735987)

I used to use Android. I use iOS now, and I understand the differences. I like the way iOS protects me and my family. This is what I want from and operating system. I wouldn't mind if Apple locked down OS X to "force" Mac developers to follow the rules. Hopefully it happens soon.

Re:Not on iOS (1)

Anonymous Coward | about three weeks ago | (#47736239)

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:Not on iOS (1)

Anonymous Coward | about three weeks ago | (#47737981)

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.

Meh... (0)

Anonymous Coward | about a month ago | (#47733145)

I don't download anything from the playstore and I don't even use an email app for my emails on mobile.

Re:Meh... (0)

Anonymous Coward | about a month ago | (#47733277)

Do you also not have a TV and shake your fist at clouds?

"Gosh, dern whippersnappers!"

I'll stick with my 3-button Jitterbug phone (1)

BenJeremy (181303) | about a month ago | (#47733149)

Now get off my lawn.

Install Malware Get Hacked (1)

Hemos (2) | about a month ago | (#47733195)

So, installing malicious software means your information can be accessed? SHOCKING.

Re:Install Malware Get Hacked (0)

Anonymous Coward | about a month ago | (#47733287)

Epic single-digit comment.

We're not worthy!!! WE'RE NOT WORTHY!!!!!

Re:Install Malware Get Hacked (0)

Anonymous Coward | about a month ago | (#47733837)

You're not worthy, you fag - the rest of us are fine...

Re:Install Malware Get Hacked (1)

gnupun (752725) | about a month ago | (#47735075)

Yes, shocking. Smartphones are supposed to have a stricter security than desktops/laptops in preventing snooping, viruses etc. So-called malicious software can't do much damage to the OS or other apps. (at least it's not supposed to if they strengthen it further).

Re:Install Malware Get Hacked (1)

dacaldar (614951) | about three weeks ago | (#47739753)

I'm guessing BlackBerry is immune to this?

the hard way (2)

farble1670 (803356) | about a month ago | (#47733937)

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);
RunningTaskInfo foregroundTaskInfo = am.getRunningTasks(1).get(0);
String foregroundTaskPackageName = foregroundTaskInfo .topActivity.getPackageName();
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:the hard way (1)

Junta (36770) | about three weeks ago | (#47735861)

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:the hard way (1)

osu-neko (2604) | about three weeks ago | (#47738143)

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 made it all make sense. Like here, where the point of what they're doing is to determine a heck of a lot more than simply what the foreground process is, but rather, what the foreground process is doing.

Re:the hard way (1)

farble1670 (803356) | about three weeks ago | (#47757289)

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 and see that the activity is "com.bank.LoginActivity". now your phishing app watches for that, and inserts it's fake login screen on top of that. simple and effective. doesn't rely on spurious metrics from the device that are going to vary based on the device, other processes, and so on.

  the article takes something simple and makes it needlessly complex. i guess that's fine for thesis. the point of which isn't necessarily practicality but doing something in a novel way.

Oh noes (0)

Anonymous Coward | about a month ago | (#47734185)

The fact that the anyone from Riverside where able to hack into an account should make anyone scared.

Windows is vulnerable! (1)

Horshu (2754893) | about a month ago | (#47734713)

If I install a debugger on it, I can read passwords!!!!!

noobs news (0)

Anonymous Coward | about a month ago | (#47735269)

this is not science... advertisment attack...

Mitigation... (1)

Junta (36770) | about three weeks ago | (#47735799)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>