Archive for iPhone

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.
UIGraphicsBeginImageContext(snapshotBounds.size);
[self drawViewHierarchyInRect:snapshotBounds afterScreenUpdates:YES];
UIImage *snapshotImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

* 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:

blurr

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.

plist-demo

 

 

Summary

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.

Cheers!
Tal

Advertisements

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

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

org_req

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:

before

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

ur_turn

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:

tamper3

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 :

cleared

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

after

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.

Cheers!