UI Interference Attack

The method relies on exploiting the shared memory, meaning the memory almost all programs use to store the nuts and bolts of their work, which enables various processes running on the operating system to share data between them.

In this case, graphical user interface (GUI) frameworks that can be used to determine every UI state change , which can be accessed without special permissions.

Knowing this state change the attacker, can know when sensitive data are being photographed or typed or used in general, enabling the attacker to transmit them to the receiver application. Of course this method needs the injection of a spy application in the targeted OS and as researchers claim this attack can work on almost all current OSes. such GUI confidentiality breach is indeed possible, leading to serious security consequences.

So let’s look into the android exploit that is already published. The fundamental reason for such confidentiality breach is in the Android GUI framework design, where every UI state change can be unexpectedly observed through publicly accessible side channels. Specifically, the major enabling factor is a newly-discovered shared memory side channel , which can be used to detect window events in the target application. This side channel exists because shared memory is commonly adopted by window managers to efficiently receive window changes or updates from running applications.

Window manager is a system software that interacts with applications to draw the final pixels from all application windows to the frame buffer, which is then displayed on screen. After evolving for decades, the most recent design is called compositing window manager , which is used virtually in all modern OSes. Unlike its predecessors, which allow individual applications to draw to the frame buffer directly, a compositing window manager requires applications to draw the window content to offscreen buffers first, and use a dedicated window compositor process to combine them into a final image, which is then drawn to the frame buffer.

In Android, the UI state our attack infers is called Activity. An Activity provides a user interface (UI) for user in off-screen. Client refers to the application, and server refers to the window compositor.

Due to security concerns, by default apps cannot know which Activity is currently shown in the foreground unless they are the owners or the central Activity manager.

An Activity may display different content depending on the app state. For instance, a dictionary app may have a single “definition” Activity showing different texts for each word lookup. We call these distinct displays View States. Denoting the state of the user experience.

Activity transition

In Android, multiple Activities typically work together and transition from one to another to support the functionality of an app as a whole. An example during a typical transition, the current foreground Activity pauses and a new one is created. A Back Stack  storing the current and past Activities is maintained by Android. To prevent excessive memory usage, at any point in time, only the top Activity has its window buffer allocated. Whenever an Activity transition occurs, the off-screen buffer allocation for the new Activity window and the deallocation for the existing Activity window take place.

Activity transitions can occur in two ways: a new Activity is created (create transition), or an existing one resumes when the BACK key is pressed (resume transition), corresponding to push and pop  actions in the Back Stack.

Knowing these fundamentals we will try to explain this novel attack on our beloved smartphones and maybe all new OSes we use.

LoginActivity Attack Overview

The spy app uses Activity hijacking to determine when the state its looking for will come to focus. Let’s use a typical login screen such as facebook or maybe a PayPal login.

LoginActivity, is about to enter the foreground, the attack app simultaneously injects a pre-prepared phishing LoginActivity into the foreground. Just at the right moment so not to make a visual disruption. Thus, enabling the spy app to steal the login data but still log the user in the appropriate application so there will be no trace of the disruption.

Camera Peeking Attack Overview

Due to privacy concerns, many apps store photo images shot by the camera only in memory and never make them publicly accessible, for example by writing them to external storage. This applies to many apps such as banking apps (e.g. Chase), shopping apps (e.g. Amazon), and search apps (e.g. Google Goggles).

Such photo images contain highly-sensitive information such as the user’s life events, shopping interests, home address and signature (on the check). With Activity tracking such sensitive and well-protected camera photo images can be successfully stolen by a background spy app. Targeting at the camera photo shot by the user, instead of random ones of the environment.

This attack uses the OpenGL library many new phones and tablets use , which has very high frame rate and does not need the sound turned off cause it does not use the shutter sound.

Even though Android disallows the taking of photographs in the background that does not mean that it does not stack the camera usage requests while the camera is in use. So when the user photographs something of importance the activity tracker tells the spy app to take another photo just when the camera is released and the user returns to the application he was using.

The camera has a very low release time about 500ms,so the spy app can shoot another shot or the sensitive data milliseconds after the original which makes it very likely the user is still pointing at the document.

There will be information about defending ourselves against these attacks soon.

Image by Benjamin F. Clay CC BY-SA 3.0

Read More

Smartphones, Tablets and Fraud

Consumers rely on their mobile devices on an ever-growing basis to keep them connected. Smartphones and tablets provide them with access to each other through email, messaging, and social media while also putting financial services and shopping in the palm of their hands. And each and every one of these activities holds value for criminals in search of account credentials and PII to sell or misuse. Unfortunately, for all of the potential that mobile devices represent, the apathy of every mobile stakeholder is undermining the security of mobile devices and the accounts of their users. Protecting Android, iOS, and Windows mobile device users from fraud will require a concerted effort by all stakeholders to eliminate vulnerabilities, encourage security-minded behaviors, and to leverage all the security benefits that mobile devices have to offer.

The study, conducted by Javelin Strategy & Research and sponsored by online authentication solutions firm Nok Nok Labs, polled more than 5.600 U.S. adults in 2013 to determine their mobile habits on Android, iOS and Windows devices.

Key Findings

Android, iOS, and Windows mobile users are undermining their security by reusing passwords more often than the average consumer. These mobile users are about 25% more likely than all consumers to use the same password to access more than one online account. This motivates criminals to target them and their devices to secure credentials with the expectation that they will facilitate access to a variety of the victim’s valuable accounts and services.

Heavy reliance on one-time passwords is placing Android users’ financial accounts at risk. 41% of Android users take advantage of one‐time passwords (OTPs) with their financial accounts. The prevalence of mobile malware for Android capable of intercepting OTPs sent by text (i.e., Short Message Service or SMS) is contributing to the rate of fraud these users experience. Mobile users prefer fingerprint authentication, which bodes well for Apple and Samsung. Fingerprint scanning is preferred by Android, iOS, and Windows mobile users among the prevailing biometric modalities. Recent moves by Apple and Samsung to expand fingerprint-based authentication is likely to be well received and will subsequently bolster the preference for this modality. One in five or fewer Android, iOS, or Windows mobile device users are truly protecting their data from a physical intrusion. While using a password, or better yet a fingerprint, to protect the lock screen can effectively deter some attempts to physically access a mobile device, more safeguards are needed to dissuade professional criminals. Unfortunately the use rates of remote wipe software and disk

Mobile users desperately want to protect their devices from vulnerabilities in outdated OSs, but updates are not always convenient or available. Updating the OS can be hampered by limited availability from carriers and manufacturers in the case of Android or because of how an update has the potential to undermine performance after installation in the case of iOS.

Android and iOS users face a significantly higher rate of fraud than the average consumer, but the reasons differ. Users in both camps display similarly poor password and security habits, which are contributing to their risk of being victimized. More specifically, it is mobile malware that is spurring the fraud experienced by Android users, while the attractiveness of iOS users’ income has placed them in the crosshairs of fraudsters.

Passwords are the typical first line of defense for online accounts, and in some cases they are the only means by which an account is secured from unauthorized access. Given the= breadth of available apps and services that mobile users have at their fingertips that require a password, it is unsurprising that convenience has taken a back seat to security. Mobile users have fallen into the “password trap,” reusing the same passwords for multiple sites and services. As a result, they are exposing their online accounts to a greater risk of compromise and eventual misuse.

Ultimately, the multitude of threats facing mobile devices and the habits of their users are conspiring to create an environment where fraud can flourish. Not every device owner experiences fraud at similar rates, though:

• Among Windows mobile device users, 4.8% experienced identity fraud in 2013, which is 10% below the rate at which all consumers were victimized (5.4%).13 This can partially be attributed to the smaller share of the mobile device market they represent, which makes them less attractive targets, but could also be the result of other factors such as the use of non-SMS-based two-factor authentication common to Microsoft services, such as Outlook.
• Android users face the most serious threat from malware and are placing their financial accounts at risk when relying on SMS-based OTPs for authentication, both of which contribute to a rate of identity fraud that is 31% higher than what all consumers experienced last year (7.1% vs. 5.4%, respectively).
• Despite owning devices far less prone to malware infection than Android, 7.3% of iOS users experience identity fraud that is 36% higher than average (5.4%). This is because of their substantial market share, which makes them higher profile targets, the use of Apple services, which rely heavily on a single set of credentials, and users that have higher-than-average incomes, which make them more attractive to fraudsters.

For more details read the full Javelin report titled SMARTPHONES, TABLETS, AND FRAUD: When Apathy Meets Security

Read More

eConference on Mobile Security

SC Magazine UK  is running a Mobile Security eConference on 25th November 2014. Best of all it's FREE! As a cherry on top, if you are a CISSP or SSCP you can get some CPE credits.

Attackers follow the money – or in infosec terms, the data. And that makes mobile an attractive target, as data increasingly goes mobile, with mobile banking, social networking, web surfing and the blurring of work and business use – as well as being a tracking device with a microphone and camera.  So what are the issues?  First comes policy - whether it’s BOYD, COYD, BOYE, or any of the new acronyms to have sprung up, and how do we tackle the issues. Then there is the device, the operating system, the apps that run on it, and how to integrate them into our overall security approach and risk appetite. What do we do to prevent data leakage, whether accidental or deliberate, and how do we secure data beyond the perimeter. And finally – what are we going to do about Google Glass and other wearable technology?

Registration is quick, simple and - did I mention it - free. After you register, you will be able to log in to the event starting at 07:00 AM EST on Nov 25, 2014.

Read More

Seek and Destroy: Operation WireLurker

WireLurker is a malware that infects computers running Mac OS X or Windows and subsequently spreads via USB connected to iOS devices. In order to be able to do so, the virus installs an enterprise provisioning profile on iOS connected devices. Under Windows, the virus only works if the iOS device is jail-broken. The threat is detected (and presumably restricted) to China until now.

If jail-broken please follow the second set of instructions.

At this time Apple has placed in appropriate security measures, but, there is a alight chance that you conceived the malware a while back before Apple took any action. And if you believe that you’re infected, follow these steps:

1. Go to Settings > General > Profile.
2. Check for any unknown profile listed here, if you find one delete it.
3. Check installed apps for any type of strange behavior, and delete all  suspicious apps that you find installed.

It is highly recommended that you do a complete restore of your iOS device from iTunes till a more effective and sure fire solution comes up.

If you’re jail-broken and have suspicions that you are affected by WireLurker, then follow the steps outlined below. If you find the process difficult, then simply do a clean restore of your Apple device using iTunes on the latest currently available public iOS release.

1. Install iFile (from Cydia), or any other way to SSH into your iOS device to access system directories.
2. Navigate to: Library > MobileSubstrate > DynamicLibraries.
3. Look for a file named sfbase.dylib, and if found, you know your device is infected.

Deleting this file does not remove the threat of WireLurker, again it is recommended that you do a complete restore of your device from iTunes.

Read More

Android Lollipop Security Features

Google is reportedly offering data encryption in its upcoming Android platform – Android L(ollipop), by default. Though Google has been providing data encryption capability since past three years, it had been kept optional. The company assures users that keys/passcodes are not stored online or anywhere off your device, so Google has no way to share them. It is, however, widely accepted that majority of the users were unaware of this option. Hence, now users don’t even have to bother about turning it on, with default settings in place. The new security strategy comes hot on the heels of Apple announcing that users' data on iOS 8 is protected by passwords that even Apple cannot access. Expanded deployment of encryption by Google and Apple, however, will have the most direct impact on law enforcement officials, who  have long warned that restrictions on their access to electronic devices make it much harder for them to prevent and solve crimes. Google does not have the ability to deliver its updated operating system, called the “L-release,” quickly to most users. Several different manufacturers make smartphones and tablets that use the Android operating system, and those devices are sold by many cellular carriers worldwide. This results in what experts call “fragmentation” – meaning there are hundreds of different versions of Android worldwide, many several years old, making it difficult to keep them current with the latest security features. The newest Android devices will likely ship with default encryption in a few days, but it will take many months and probably years before most Android devices have encryption by default.


The latest version of the mobile OS has amped up its deployment of Security Enhanced Linux (SE Android) in order to bring security policy enforcement to the kernel level, and has also switched device encryption on by default.
“You can authorize apps with high-level permissions and deep down they’re being granted a lot more access than necessary. With SE Android, Google is expanding and getting more fine-grained controls and containment,” said Zach Lanier, senior security researcher with Duo Labs, the research division of Duo Security. With SE Android, you’re much closer to having a real sandbox.

SE Linux has been in Android since version 4.4, but now all application enforcement is being pulled into the OS kernel. Google lead security engineer for Android Adrian Ludwig said this makes security auditing and monitoring easier on the device.
“With Android 5.0, SELinux Enforcing mode is required for all applications on all devices,” Ludwig said. “Multiple vulnerabilities have been prevented since we first introduced SELinux last year; by strengthening it even more, Android becomes a top choice for enterprise customers that have really strict security standards, such as the government.”

There are also rumors about multiple accounts per device, that would allow users to separate business form personal functions. The new Android for Work solution (which incorporates Samsung KNOX features) will address these issues by creating an encrypted storage and a virtual environment, basically, a smartphone inside a smartphone. After launching Android for Work, a user will see a “business home screen” with company-approved apps and can perform his/her duties using encrypted data and an encrypted Internet connection. One click ― and his/her personal home screen and apps are back. Private and work-related apps and data are fully isolated, e.g. the company email app cannot read users’ personal address book or photo library, and vice versa.

Google developers briefly mentioned something called Universal Data Controls, a centralized tool helping a user identify items like which apps, what kind of his/her personal data and what should be blocked for an individual’s smartphone. Unfortunately, there are few details on the subject. We will have to wait a few more days to take a closer look at this function.

If you're buying a Nexus 6 or Nexus 9, you can get Android Lollipop from November 3rd (if you're in the UK, you'll be able to pre-order in November and receive your phablet or tablet within a few weeks). But if you already have a Nexus 5, 7 or 10 you should get it in a free over-the-air update in the "coming weeks" according to Google's blog. 

Read More

iOS 8.0.1 #fail

On September 23rd according to Crittercism, iOS 8's crash rate was 3.3%, between September 17th and September 22nd, or about 65% higher than iOS 7 at the same point in its post-launch timeline.

Hopefully for Apple, released its first update for the new OS on Wednesday afternoon, just one week after the launch of iOS 8. It was meant to fix issues like "unexpected cellular data usage" when receiving text messages. Instead, after updating, users begun to report that iOS 8.0.1 has interfered with their cell signal and other features like Touch ID.  Most of the victims where proud owners of the new iPhone 6. Apple has published an official statement on the issue and withdraw the update.

"We apologize for the great inconvenience experienced by users, and are working around the clock to prepare iOS 8.0.2 with a fix for the issue, and will release it as soon as it is ready in the next few days."

Until then use the following steps to restore your phone.

Follow these steps to re-install iOS 8.0.

1. Make sure that you're using the latest version of iTunes.
2. Connect your iPhone to iTunes.
3. Back up your iPhone in iTunes on your Mac or PC. iCloud backups won't restore to earlier versions, including iOS 8.0.
4. Download the file below that corresponds to your device:
1. iPhone 6
2. iPhone 6 Plus
5. Select the file you just downloaded by doing one of these in iTunes:
1. Mac: Press the Option key and click Check for Update.
2. Windows: Press the Shift key and click Check for Update.
6. Press Update to install iOS 8 on your iPhone.

The Health app won't work in iOS 8 after these steps. It will be fixed in our upcoming iOS 8.0.2 software update.

Read More

iPhone 6 Security Features

The first devices to support Apple Pay will be the iPhone 6 and iPhone 6 Plus that come with built-in NFC support and Touch ID fingerprint sensor, as well as the Apple Watch (in early 2015), at which point Apple Pay will also work on older iPhones that are compatible with the wearable device, including the iPhone 5, iPhone 5c and iPhone 5s.

James Anderson, Group Head of Mobile and Emerging Payments at MasterCard, says EMV technology is at the heart of each Apple Pay transaction. Apple Pay – the mobile payment system that will work on the company’s iPhone 6 and iPhone 6 Plus models – will enable users to store credit card information on their phone. “The number itself is bound to the device,” explains McCarthy, “so we know the token should be used by the device only.” In short, if someone hacks into the phone and successfully retrieves your 16-digit token, the hacker won’t be able to use that number to make purchases if they don’t have the phone itself. The other benefit of tokenization is that if you lose your iPhone, you don’t need to get a new credit card – you can simply turn off that token through the “Find My iPhone” tool, says Anderson. When an Apple Pay user taps their iPhone on the terminal, the phone generates a unique string of numbers called a cryptogram. Token Technology Visa’s Jim McCarthy, whose team led the development of the Apple Pay technology, says Apple Pay actually takes EMV one step further thanks to its “tokenization” technology.

How it works? In supporting stores, users will be able to wirelessly pay for goods by approaching their iPhone 6 model or Apple Watch to the payment terminal that supports NFC connectivity, at which point the default credit card will appear on the screen, though the user will be able to choose a different one if needed.

Furthermore, during transactions, instead of the device transmitting card numbers to the receiving terminal, it’ll only send over a Device Account Number for each card and a “transaction-specific dynamic security code.” Moreover, Apple will not store purchases history on any devices or in the cloud, and only provide the user with a recent transactions list for convenience purposes.

On the Apple Watch, a PIN number has to be entered every time the device is removed from the user’s hand – continuous skin contact means the device doesn’t have to be authorized a second time by the user via a PIN security code.

The iPhone and Apple Watch payment solution seems awfully easy to use, with Apple also focusing on shopping privacy and financial security in addition to stupid-simple functionality.

Read More