Archive for the Mobile Category

iPhone just snapshotted your credit card number

Posted in Exploits, Mobile, Valnurability with tags , on December 28, 2014 by keizer

Having a page where users insert their credit card numbers? a page containing sensitive data such as personal or business information? you should be aware of the fact that when the user presses the iphone’s home button, and your application performs backgrounding, iOS takes a snapshot of the current page and stores it insecurely on the device. Why? to create an “animation” when the application shrinks into the background and when selected, expands back to your screen. If the last page contained sensitive information, this information could be stolen. Violation of the user’s privacy and business information leakage are just two of the security impacts it may cause.

This is how its done:
1. The user launches your app, and goes to a page containing sensitive information.
2. The user receives a call, or decided himself to press the home button, and send your app into the background.
3. iOS takes a snapshot of the last pages, for animation… this is how it looks:

stage1 stage2 stage3

Now, lets take a look at the application folder on the device. We’ll go to:
{YOUR_APP_UUID}/Library/Caches/Snapshots/ and there we can see the file:
UIApplicationAutomaticSnapshotDefault-Portrait@2x.png. Opening it, will reveal all the data that appeared on the last page visited in our app, before going into background.

What can we do about it?

Well… I’m glad you asked! There are a few ways to deal with this issue. Here,I will explain four of them:

1. Creating an iOS 7 blur effect

iOS 7 gives every UIView methods to provide Capturing a View Snapshot.

The method drawViewHierarchyInRect:afterScreenUpdates: provides nearly the same as it’s CALayer predecessor renderInContext:, but this one captures the actual onscreen content.

// Snapshot scene into a UIImage.
[self drawViewHierarchyInRect:snapshotBounds afterScreenUpdates:YES];
UIImage *snapshotImage = UIGraphicsGetImageFromCurrentImageContext();

* You can specify a smaller bounding rectangle for the snapshot to gain performance. A blurred image actually don’t have to be at full resolution, since users can hardly perceive the difference.

Apply blur to an image can be done several ways, like using CIFilter, or some iOS Stack blur implementation. Here I will demonstrate using an  API called GPUImageiOSBlurFilter.

Now, all we have to do is:

// Create filter.
self.blurFilter = [GPUImageiOSBlurFilter new];
// Apply filter.
UIImage *blurredSnapshotImage = [self.blurFilter imageByFilteringImage:snapshotImage];

The following image, is a PoC of a blurred snapshot:


2. Mark sensitive fields as hidden

The iOS Application Programming Guide states “When your applicationDidEnterBackground: method returns, the system takes a picture of your app’s user interface and uses the resulting image for transition animations. If any views in your interface contain sensitive information, you should hide or modify those views before theapplicationDidEnterBackground: method returns.”

Simple as it sounds, just mark the sensitive fields as hidden in the delegate:

- (void)applicationDidEnterBackground:(UIApplication *)application {
viewController.accountNumber.hidden = YES;
viewController.username.hidden = YES;
viewController.SSN.hidden = YES;
viewController.password.hidden = YES;

Adding this code to the delegate results in the screenshot being taken without the sensitive parameters (e.g. the credit card number field):


hidden fields

3. Use an overlay image

Overlay an image as the application enters the background state. The overlaid image will “mask” the current screen, thus covering any sensitive information which may be on screen. Below is sample code:

@property (UIImageView *)backgroundImage;
- (void)applicationDidEnterBackground:(UIApplication *)application {
UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
self.backgroundImage = myBanner;
[self.window addSubview:myBanner];

Choose a background that will be saved on top of the original snapshot. You can use the general theme of your application. For example:

4. Prevent Backgrounding

You can also prevent backgrounding completely, instead of trying to hide the sensitive data. To do so, set the “Application does not run in background” property in the application’s Info.plist file. This will add theUIApplicationExitsOnSuspend key to the plist. After setting this property, every time the application tries to go into backgrouding, the inapplicationWillTerminate: is being called and prevents the screenshot from being taken at all.





Sensitive data, such as Personal Information, Financial or business data, and more can be saved when an app moves to the background without the user’s knowledge.  If a malicious application is installed on the same device, or if someone gets a hold of the device, even just for few minutes, This sensitive information could be easily stolen. This snapshot will remain there until a new snapshot of the same application will be taken! This is a series security issue and it needs to be mitigated by the developers. I’ve seen different apps using different solutions… just pick one of the methods I stated above and protect your users.



Rooting SIM cards

Posted in Encryption, Mobile, Network Security, Valnurability with tags , , on July 23, 2013 by keizer

SIM cards are the de facto trust anchor of mobile devices worldwide. The cards protect the mobile identity of subscribers, associate devices with phone numbers, and increasingly store payment credentials, for example in NFC-enabled phones with mobile wallets.

With over seven billion cards in active use, SIMs may well be the most widely used security token in the world. Through over-the-air (OTA) updates deployed via SMS, the cards are even extensible through custom Java software. While this extensibility is rarely used so far, its existence already poses a critical hacking risk.

Cracking SIM update keys. OTA commands, such as software updates, are cryptographically-secured SMS messages, which are delivered directly to the SIM. While the option exists to use state-of-the-art AES or the somewhat outdated 3DES algorithm for OTA, many (if not most) SIM cards still rely on the 70s-era DES cipher. DES keys were shown to be crackable within days using FPGA clusters, but they can also be recovered much faster by leveraging rainbow tables similar to those that made GSM’s A5/1 cipher breakable by anyone.

To derive a DES OTA key, an attacker starts by sending a binary SMS to a target device. The SIM does not execute the improperly signed OTA command, but does in many cases respond to the attacker with an error code carrying a cryptographic signature, once again sent over binary SMS. A rainbow table resolves this plaintext-signature tuple to a 56-bit DES key within two minutes on a standard computer.

Deploying SIM malware. The cracked DES key enables an attacker to send properly signed binary SMS, which download Java applets onto the SIM. Applets are allowed to send SMS, change voicemail numbers, and query the phone location, among many other predefined functions. These capabilities alone provide plenty of potential for abuse.

In principle, the Java virtual machine should assure that each Java applet only accesses the predefined interfaces. The Java sandbox implementations of at least two major SIM card vendors, however, are not secure: A Java applet can break out of its realm and access the rest of the card. This allows for remote cloning of possibly millions of SIM cards including their mobile identity (IMSI, Ki) as well as payment credentials stored on the card.

Defenses. The risk of remote SIM exploitation can be mitigated on three layers:

  1. Better SIM cards. Cards need to use state-of-art cryptography with sufficiently long keys, should not disclose signed plaintexts to attackers, and must implement secure Java virtual machines. While some cards already come close to this objective, the years needed to replace vulnerable legacy cards warrant supplementary defenses.
  2. Handset SMS firewall. One additional protection layer could be anchored in handsets: Each user should be allowed to decide which sources of binary SMS to trust and which others to discard. An SMS firewall on the phone would also address other abuse scenarios including “silent SMS.”
  3. In-network SMS filtering. Remote attackers rely on mobile networks to deliver binary SMS to and from victim phones. Such SMS should only be allowed from a few known sources, but most networks have not implemented such filtering yet. “Home routing” is furthermore needed to increase the protection coverage to customers when roaming. This would also provide long-requested protection from remote tracking.

Thanks to: Security Research Labs who published this!

This research will be presented at BlackHat on Jul 31st and at the OHM hacking camp on Aug 3rd 2013

Uncovering Android Master Key – 99% of devices are vulnerable!

Posted in Encryption, Malware, Mobile, Valnurability with tags , , , on July 4, 2013 by keizer

The Bluebox Security research team –  recently discovered a vulnerability in Android’s security model that allows a hacker to modify APK code without breaking an application’s cryptographic signature, to turn any legitimate application into a malicious Trojan, completely unnoticed by the app store, the phone, or the end user. The implications are huge! This vulnerability, around at least since the release of Android 1.6 (codename: “Donut” ), could affect any Android phone released in the last 4 years1 – or nearly 900 million devices2– and depending on the type of application, a hacker can exploit the vulnerability for anything from data theft to creation of a mobile botnet.

While the risk to the individual and the enterprise is great (a malicious app can access individual data, or gain entry into an enterprise), this risk is compounded when you consider applications developed by the device manufacturers (e.g. HTC, Samsung, Motorola, LG) or third-parties that work in cooperation with the device manufacturer (e.g. Cisco with AnyConnect VPN) – that are granted special elevated privileges within Android – specifically System UID access.

Installation of a Trojan application from the device manufacturer can grant the application full access to Android system and all applications (and their data) currently installed. The application then not only has the ability to read arbitrary application data on the device (email, SMS messages, documents, etc.), retrieve all stored account & service passwords, it can essentially take over the normal functioning of the phone and control any function thereof (make arbitrary phone calls, send arbitrary SMS messages, turn on the camera, and record calls). Finally, and most unsettling, is the potential for a hacker to take advantage of the always-on, always-connected, and always-moving (therefore hard-to-detect) nature of these “zombie” mobile devices to create a botnet.

How it works:

The vulnerability involves discrepancies in how Android applications are cryptographically verified & installed, allowing for APK code modification without breaking the cryptographic signature.

All Android applications contain cryptographic signatures, which Android uses to determine if the app is legitimate and to verify that the app hasn’t been tampered with or modified. This vulnerability makes it possible to change an application’s code without affecting the cryptographic signature of the application – essentially allowing a malicious author to trick Android into believing the app is unchanged even if it has been.

Details of Android security bug 8219321 were responsibly disclosed through Bluebox Security’s close relationship with Google in February 2013. It’s up to device manufacturers to produce and release firmware updates for mobile devices (and furthermore for users to install these updates). The availability of these updates will widely vary depending upon the manufacturer and model in question.

The screenshot below demonstrates that Bluebox Security has been able to modify an Android device manufacturer’s application to the level that we now have access to any (and all) permissions on the device. In this case, we have modified the system-level software information about this device to include the name “Bluebox” in the Baseband Version string (a value normally controlled & configured by the system firmware).

Screenshot of HTC Phone After Exploit



  • Device owners should be extra cautious in identifying the publisher of the app they want to download.
  • Enterprises with BYOD implementations should use this news to prompt all users to update their devices, and to highlight the importance of keeping their devices updated.
  • IT should see this vulnerability as another driver to move beyond just device management to focus on deep device integrity checking and securing corporate data.

Thanks Bluebox Security

Pool Party!

Posted in Application, Mobile with tags , , , on January 29, 2013 by keizer

Pool Party

A new social pool game by nitako – pool party was recently released to the mobiles (iphone and android)- letting you play pool against Facebook users, using turns.

It is actually a pretty cool game, I played it (normally) for about 2 weeks… getting better and better. I must say, once you get how it works, its pretty easy to score the balls. As you earn more and more coins, you want play on larger pots. And that’s what I did… Now, you probably know the saying “Don’t put all your eggs in one basket”, so I did :\ – playing with all my coins against one dude, which turned out to be better then then I expected, which led me to lose all my coins!

This is when I lost my temper… after all the time & effort I put in this game, I left with nothing! It’s time to use my profession skills for something truly important! let’s try and get more coins… and fast!

So I started digging in the application’s traffic… changing the amount of coins, pots, cash… every variable that held an amount of coins, I changed it… but nothing!

Until I found a way… which,  to my disappointment, includes taking others’ coins 😦 oh well… its not real money 🙂

and this is how it works:

Play a game, until you win (it doesn’t matter on what amount you’re playing on)  and the game ends – catch the requests. One of them will look like this (notice the tableData=) :


Copy the part from the tableData= to the end of the request – which should say: result=EightSank – and paste it into a notepad or any other text editor.  Next time you’re playing with someone, just after hitting the ball – intercept the requests (using any proxy application), and when you see the requests that holds the tableData – replace it with the text you saved, which represents the insertion of the 8 ball, which indicates that you have won. 

Now, let’s see it in action:

1. I have 12,250 coins:


2. Oh, it’s my turn,  so I’ll just turn the requests interception ON :


3. After hitting the ball (it doesn’t matter what actually happens in the game), I find the request we discussed earlier and replaced the tableData part. Which in this case saying result=TurnOver (guess not…:))

tamper24. With the EightSank tableData – I saved from one of my (many) victories:


5. Its magic! most of the balls are still on the table, but it says clearlyYou Cleared the table ! the game ends with a pot of $200 :


6. Voilà! I now have 12,350 coins (Of course, I invested 100 myself, so the actual profit is, in this case, 100$)…


If you liked that post, and you want me to find you fast& easy ways to earn coins – comment with the name of the iphone game you want, and I’ll do my best.


Say “Hi” to Boxer – a new SMS based Trojan for Android

Posted in Malware, Mobile with tags , , , on December 5, 2012 by keizer

Your Android smartphone could be producing profit for criminals, and here is how: using piece of malware calledAndroid/TrojanSMS.Boxer.AA, a malicious program for Google’s Android mobile Operating System that targets 63 different countries, reading the MCC (Mobile Country Code) and MNC (Mobile Network Code) codes from the infected device. In December 2011 twenty-two malicious applications were discovered in the Android Market (Now Google Play) that were able to reach users all of these countries.

(In addition to this article, we have prepared a whitepaper that you can download: Boxer SMS Trojan (PDF). We have also provided a more general article on the SMS Trojan premium rate call threat.)

SMS Trojans are the most common threats that we find for mobile devices these days: the most common form they take is subscribing users to premium-rate numbers and charging them varying amounts of dollars per message. These kinds of activity and techniques are not new but nevertheless they´ve proven quite effective and profitable for cybercriminals and as the take-up of mobile devices has accelerated, we have also been seeing malware for these platforms increasing in popularity and sophistication. We have seen attack methodologies that include injecting malicious code into known applications, sending and hiding the response messages, Pay Per Install (PPI) methodologies and so on. Usually these threats target one or a few specific countries, but Boxer has a global reach.

One of the malware-enabled applications found in our research is “Urban Fatburner” (md5: 962078fba0bca8cda4fe39c516d21ffc). When a victim installed this application a number of permissions were requested including the ability to send and receive SMS, access to the Internet, and the ability to make phone calls. The application installed by users is an installer: once the users accept the terms, it will send between one and three SMS messages to premium-rate numbers and allow the user to download the full app. Nevertheless, even when the newly-downloaded application is fully installed, more text messages may be sent to premium-rate numbers every time the app is executed. As our first approach to understanding what this malware can do we used apktool to decompile the APK file, to get to the resources, read the information in AndroidManifest.xml and raw resources, including configuration files for countries and SMS.

During the analysis of this threat, the mechanism used by Boxer demonstrated how a customized code for fake installers is able to target a wide range of countries in a single malicious app. This structure is easy to detect, and reads information directly from the mobile phone once the application is initiated. Once the Main class is called, the method onCreate() is executed when application starts and uses the TelephonyManager class to call get getNetworkOperator(). This function retrieves a string with the MCC and MNC concatenated so as to identify the country. This information will be used further by the application to set the proper configuration such as number and activation code for the mobile carrier according to the country.

At the end of the onCreate() method, initActivationSchemes() is called. This function will match the MCC to the proper identifier and the mobile number to which the SMS will be sent. For this purpose there is a class called ActivationScheme that holds the number of SMS messages that will be sent and the information set by initActivationSchemes(). 

All this information will be used later (after the user accepts the user license agreement) by the activate() method. This will register a BroadcastReceiver() that will be triggered after an SMS is sent. With this action the malware will update the configuration files and be aware when to stop sending messages:

Boxer works as a fake installer, and once those users agree to download the application and it has sent the SMS it will download a modified application that may continue to send messages to premium numbers. This kind of functionality allows attackers to define a wide range of countries even when the user is in a different country. The distribution of the targeted countries by region can be seen in the following graph:

As time goes by, smartphones are getting more and more accessible to and popular with users who, in many occasions, are unaware of the threats they may face if they do not adopt the necessary preventive and security measures. Although there are SMS Trojans for other platforms such as Symbian and for mobile devices compatible with Java Micro Edition, during 2012 it was possible to observe a rise of this kind of threats exclusively designed for Android, as is the case of Boxer.

In general, SMS Trojans affect a very limited number of countries. There are also other cases in which they are capable of working in several nations belonging to a particular continent, as in Europe. However, Boxer is able to transcend regional barriers by including within its malicious routine 63 countries across America, Asia, Africa, Europe and Oceania. Out of these 63 countries, nine are Latin American. Consequently – and taking into account the fact that this threat was found in several malicious applications through Google Play – Boxer is considered to be among the most important SMS Trojans of the last year, and is the first one that has tried to target so many countries at the same time.

Our observation of this family of malware confirms that cybercriminals are not only focusing their resources on the creation of increasingly complex malware for mobile devices, but that they are also starting to concentrate on how to expand the reach of their threats worldwide. It is likely that in the near future more malicious code targeting Android will be detected and that, at the same time, more of them will be constructed so as to affect users in as many regions as possible.

Pablo Ramos
Security Researcher
ESET Latinoamérica