Archive for the Exploits 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.


Google Chromecast – released yesterday, hacked today

Posted in Exploits with tags , , on July 29, 2013 by keizer


On Wednesday, July 24th Google launched the Chromecast. As soon as the source code hit GTV Hacker began their audit. Within a short period of time they had multiple items to look at for when their devices arrived. Then they received their Chromecasts the following day and were able to confirm that one of the bugs existed in the build Chromecast shipped with. From that point on they began building what you are now seeing as our public release package.

Exploit Package:

GTV Hacker Chromecast exploit package will modify the system to spawn a root shell on port 23. This will allow researchers to better investigate the environment as well as give developers a chance to build and test software on their Chromecasts. For the normal user this release will probably be of no use, for the rest of the community this is just the first step in opening up what has just been a mysterious stick up to this point. GTV Hacker hope that following this release the community will have the tools they need to improve on the shortfalls of this device and make better use of the hardware.

File:Chromecast dirty side1.jpgIs it really ChromeOS?

No, it’s not. GTV Hacker had a lot of internal discussion on this, and have concluded that it’s more Android than ChromeOS. To be specific, it’s actually a modified Google TV release, but with all of the Bionic / Dalvik stripped out and replaced with a single binary for Chromecast. Since the Marvell DE3005 SOC running this is a single core variant of the 88DE3100, most of the Google TV code was reused. So, although it’s not going to let you install an APK or anything, its origins: the bootloader, kernel, init scripts, binaries, are all from the Google TV.


How does the exploit work?

Lucky for GTV Hacker, Google was kind enough to GPL the bootloader source code for the device. So they could identify the exact flaw that allows us to boot the unsigned kernel. By holding down the single button, while powering the device, the Chromecast boots into USB boot mode. USB boot mode looks for a signed image at 0×1000 on the USB drive. When found, the image is passed to the internal crypto hardware to be verified, but after this process the return code is never checked! Therefore, they could execute any code at will.

ret = VerifyImage((unsigned int)k_buff, cpu_img_siz, (unsigned int)k_buff);

The example above shows the call made to verify the image, the value stored in ret is never actually verified to ensure that the call to “VerifyImage” succeeded. From that, they were able to execute our own kernel. Hilariously, this was harder to do than our initial analysis of exploitation suggested. This was due to the USB booted kernel needing extra modifications to allow us to modify /system as well as a few other tweaks. GTV Hacker then built a custom ramdisk which, when started, began the process of modifying the system by performing the following steps:

  • Mount the USB drive plugged in to the chromecast.
  • Erase the /system partition (mtd3).
  • Write the new custom system image.
  • Reboot.

Note: /system is squashfs as opposed to normally seen EXT4/YAFFS2.

The system image installed from our package is a copy of the original with a modified /bin/clear_crash_counter binary. This binary was modified to perform its original action as well as spawn a telnet server as root.

After the above process, the only modification to the device is done to spawn a root shell. No update mitigations are performed which means that theoretically, an update could be pushed at any moment patching our exploit. Even with that knowledge, having an internal look at the device is priceless and they hope that the community will be able to leverage this bug in time.

Downloads and instructions for exploitation can be found on their wiki at: GTVHacker Wiki: Google Chromecast