Tuesday 14 May 2013

Coordinated ATM Heists, and a rant...

Been a while since I posted, have been a bit flat out with lots of multiple projects on different continents.

This story is a great one for those of us in the payments security field.
http://krebsonsecurity.com/2013/02/crooks-net-millions-in-coordinated-atm-heists/
http://www.theverge.com/2013/5/13/4326336/cyber-caper-behind-the-scenes-of-the-45-million-atm-heist
http://www.reuters.com/article/2013/05/13/us-usa-crime-cybercrime-electracard-idUSBRE94C0K220130513

This is an interesting story in that it was not the card-holder data that was attacked, but the balance and withdrawal limits data that was breached. There is a chance that the payment processors were PCI compliant as these standards are concerned with the protection of card-holder data, not with balances on accounts or withdrawal limits.

This is a good lesson to all payment processors that PCI compliance alone is not sufficient security. You must continually assess and test your payment environment for security vulnerabilities.

Also, countries not using chip-card/EMV should hurry up and join the rest of the world.


Magstripe is a broken technology, it contributed to the above attack (the pre-paid cards were cloned allowing an exponential increase in the losses occured).
EMV/Chip Cards cannot be economically cloned, which reduces the economic impact of attacks like the one above.


Why is a product like this: https://squareup.com/stand even feasible in 2013? Almost all payment terminals produced now support Chip/EMV transactions.
$299 for a product that is not PCI compliant, already obsolete and insecure; sounds like the Windows 3.1 of payment terminals...

Wednesday 13 March 2013

Nice write-up on issues in TLS/SSL

Haven't blogged in a while due to studying for the CISSP certification and working on other fun projects. Amazon EC2 instances are enormous fun to play with, and free to get started with, wish i had this type of stuff when i was in uni.

Came across this great story on RC4 and TLS:
Attack of the week: RC4 is kind of broken in TLS
Cipher suites in the TLS/SSL implementations have been an interesting area of late with a number of attacks being published in the last few months.
A fun thing to do is to scan a website using the TLSSLED shell script and see what cipher suites it supports.
Here's the output for google.com:

         Accepted  SSLv3  256 bits  ECDHE-RSA-AES256-SHA
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  168 bits  ECDHE-RSA-DES-CBC3-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Accepted  SSLv3  128 bits  ECDHE-RSA-AES128-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  128 bits  ECDHE-RSA-RC4-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  SSLv3  128 bits  RC4-MD5
    Accepted  TLSv1  256 bits  ECDHE-RSA-AES256-SHA
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  168 bits  ECDHE-RSA-DES-CBC3-SHA
    Accepted  TLSv1  168 bits  DES-CBC3-SHA
    Accepted  TLSv1  128 bits  ECDHE-RSA-AES128-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  128 bits  ECDHE-RSA-RC4-SHA
    Accepted  TLSv1  128 bits  RC4-SHA
    Accepted  TLSv1  128 bits  RC4-MD5

The interesting listing in this case is "RC4-MD5", considering the MD5 is considered broken and should have been retired by now. 

Compared this to api.square.com:443:

    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  168 bits  DES-CBC3-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  128 bits  RC4-SHA
Which is in line with FIPS 140-2 Annex A.





Monday 11 February 2013

Nice attack on an bad implementation of using the Atmel SAM7XC Crypto Co-Processor

http://oamajormal.blogspot.co.uk/2013/02/atmel-sam7xc-crypto-co-processor-key.html

This is why hardware key management is so important. In this case the processor contains hardware cryptographic engines yet no dedicated key storage or tamper protection. This means that keys have to be stored in internal Flash or RAM which opens up vulnerabilities allowing keys to be extracted.

A proper secure processor implements dedicated key storage memory combined with active tamper detection. If a tamper event is detected by the processors security sub-system; then the key storage area will be actively cleared preventing key extraction. Examples of these processors include the Maxim USIP, Freescale i.MX258 or the Broadcom BCM5982.

The analysis performed here validates how much implementation matters when designing a secure system.



Monday 4 February 2013

iOS 6.x Untethered Jailbreak out

Available at: http://evasi0n.com/

I recommend checking the SHA-1 hash of the release you downloaded against the provided list (a habit I should get into as well). This can be performed by using OpenSSL:
openssl sha1 <filename>

Interesting that the jailbreak steps are different from the "redsn0w" utility, not having to get the device into DFU mode is great as I muck it up every time and have to reboot.
The installer places a "Jailbreak" icon onto the SpringBoard as part of the process which has to be clicked, i'm interested to know what role this performs in the jailbreak process.

Make sure if you've jailbroken your device to change the your default root password to something you've chosen! we don't want this happening again.

ssh root@<ip of your device>
iPhone:~ root# passwd

Changing password for root.
New password:

and heres a great writeup of what the jailbreak does:
http://blog.accuvantlabs.com/blog/bthomas/evasi0n-jailbreaks-userland-component

Friday 1 February 2013

Hooking objective-c internals using the Captain Hook framework.

One of the fun things to do with a Jailbroken iPhone is to install custom themes using the "WinterBoard" application.
This allows you to install themes such as: Auxo which customises the application switcher bar or Boss.ios which alters the whole look of the interface.

How does "Winterboard" work?

The "WinterBoard" application works by "hooking" the existing internal classes using the Objective-C Runtime Library. This library is loaded by all Objective-C applications to support the dynamic features of the language which means that we can utlilise is to perform our own alterations to the OS and applications.
This allows for the alteration of icons, sounds and textures without having to touch the originals supplied with the device. This means that you can alter the device without the risk of breaking the device.

The CaptainHook framework

This is a header file created by Ryan Petrich(http://rpetri.ch/) to assist with the creation of hooking libraries using the Objective-C runtime. This provides a functions to assist in the setting up of custom hooking code. Documentation is a little scant so hopefully this blog can help you begin to create your own hooks.

Getting started

I've altered the sample code provided at the Github as the function used has been depreciated by Apple
hook source code and a makefile
#import <CaptainHook/CaptainHook.h>
CHDeclareClass(NSString); //set up the Captain Hook Library

//function called when hook is encountered
CHMethod(4, void, NSString, writeToFile, NSString *, path,  
         atomically, BOOL, useAuxiliaryFile, encoding,  
         NSStringEncoding, end, error, NSError **, error) 
{
  NSLog(@"Writing string to %@: %@", path, self);
  //send received arguments to the original class
  CHSuper(4, NSString, writeToFile, path, atomically,
  useAuxiliaryFile, encoding, end, error, error);
}

//create the hook
CHConstructor
{
  CHLoadClass(NSString); //setup the class
  //hook the chosen method
  CHHook(4, NSString, writeToFile, atomically, encoding, 
  error);
}

Heres a sample program you can test it with:
link to test program and makefile
#import <Foundation/Foundation.h>
#import <Foundation/NSString.h>

int main(void) {
  NSAutoreleasePool *pool = \
    [[NSAutoreleasePool alloc] init];
  NSString *testString = @"Hello, I am the test string";
  [testString 
    writeToFile:@"test.txt" 
    atomically:YES 
    encoding:NSASCIIStringEncoding 
    error:NULL];
  [pool release];
  return 0;
}

Compiling

Compiling works on OS X with xCode 4.x and iOS SDK version 6.0 in the default library locations.
Copy the compiled "testhook" and "stringHook.dylib" to your device. SSH in, export DYLD_INSERT_LIBRARIES and then execute "testhook" e.g:
  desktop$ scp ./hooktest ./stringHook.dylib \
root@<device ip>:/var/root/
  desktop$ ssh root@<device ip>
  device # export \
DYLD_INSERT_LIBRARIES="/var/root/stringHook.dylib"
  device # /var/root/hooktest

And you should see:
  2013-02-01 21:40:58.710 hooktest[562:707] Writing string to   
  test.txt: Hello, I am the test string
Which only works for command line apps as export DYLD... does not get performed by SpringBoard


A bit of explanation

The CHMethod function declaration is:
  CHMethod(number of inputs, return type, class name, name1, type1, 
  arg1, name2, type2, arg2 ...(number of inputs));

An easy way to fill this method is to take the method definition, and fill it in left to right e.g.
  [NSString writeToFile: atomically: encoding: error:]
  -(BOOL)writeToFile:(NSString *)path atomically:   
  (BOOL)useAuxiliaryFile encoding:(NSStringEncoding)enc error   
  (NSError **)error
translates to:
  CHMethod(4, void, NSString, writeToFile, NSString *, path,    
  atomically, BOOL, useAuxiliaryFile, encoding, NSStringEncoding, 
end, error, NSError **, error)
We set the return type to void as for the example we don't return anything

The function declaration of CHSuper and CHHook are:
CHSuper(number of inputs, class name, name1, arg1, name2,
arg2 ...(number of inputs)

CHHook(number of inputs, class name,name1,name2,
...(num of inputs)



Other ways of inserting the injection library

Using launchctl seems to be a great way.
launchctl setenv DYLD_INSERT_LIBRARIES "/path/to/dylib"
which can be used for individual SpringBoard apps
or you can insert this plist key into one of the plists in "/System/Library/LaunchDaemons/"
although be careful! i screwed up my SpringBoard.plist editing it which caused the SpringBoard to stop loading(i.e no icons), so make a backup of the file just to be sure.
<key>EnvironmentVariables</key>
<dict>
<key>DYLD_FORCE_FLAT_NAMESPACE</key>
<string>1</string>
<key>DYLD_INSERT_LIBRARIES</key>
<string>/path/to/dylib</string>
</dict>

reload the plist using
launchctl unload <chosen plist>
then reload
launchctl load <chosen plist>

Another easy method is to install MobileSubstrate and copy the dylib to "/Library/MobileSubstrate/DynamicLibraries" and reload the SpringBoard. MobileSubstrate loads all the dylibs in this folder automatically.

Heres another piece of sample hooking code i created playing this stuff: https://github.com/peterfillmore/touchHook
This changes the status bar each time a touch is detected.

A great use of this hooking in security testing has been recently released by Jeremy Allen which uses it to disable certificate verification. http://intrepidusgroup.com/insight/2013/01/scorched-earth-how-to-really-disable-certificate-verification-on-ios/
So play around with it and see what fun you can have.




Sunday 20 January 2013

removePIE - a tool for disabling ASLR on iOS applications

I've put together this small tool which removes ASLR from iOS applications.
https://github.com/peterfillmore/removePIE

This works by flipping the MH_PIE bit used in the MACH-O header of the application.
Since iOS 6.0 this bit is enabled by default in xcode when compiling applications.

**Update**
Still works for the iOS 6.1 update, doesn't require resigning of the binary if using the evasi0n jailbreak as i believe signature checking of apps is patched out.

Tuesday 8 January 2013

Disabling ASLR on individual iOS applications when using iOS 6.0.1



How to disable ASLR on iOS application for decryption and analysis.

I recently encountered issues decrypting applications for security analysis using iOS 6.0.1. Previously this was trivial using the previous version (5.1.1), yet when performing the same procedure on 6.0.1 i was encountering decrypted binaries which were full of zeros.
After a while I discovered these issues were related to ASLR being used in applications compiled for later versions of iOS.

In this blog I will show the process of disabling ASLR on the free "Facebook" app available off the app store. This application has ASLR enabled which complicates decryption of the application using automated tools.

Tools required

otool
ldid for OS X
GDB for iOS
change_mach_o_flags.py
a jailbroken iphone and a copy of facebook off the app store

Details


Running the command

Desktop# otool -l Facebook |grep -A4 "LC_ENCRYPTION_INFO"

outputs:

cmd LC_ENCRYPTION_INFO
    cmdsize 20
    cryptoff  8192
    cryptsize 10027008
    cryptid   1
 
Indicating that the app is encrypted and when decrypted it is located in virtual memory from 0x3000(0x1000 + 0x2000) to 0x993000. However when we start the app, attach GDB and try to access the start address we find it throws an error:

(gdb) x/20x 0x3000
0x3000: Cannot access memory at address 0x3000

listing the memory that is mapped by the application:
(gdb) info mach-region 0x3000
Region from 0x94000 to 0xa26000 (r-x, max r-x; copy, private, not-reserved) (2 sub-regions)

This shows the executable is not located in memory where it should be indicating that ASLR is used.

ASLR is enabled for individual applications using the MH_PIE flag located in the applications MACH-O header. By flipping this flag we turn off ASLR.

Copy the Facebook binary from the device to your desktop from the device directory

iPhone#/private/var/mobile/Application/[UUID]/Facebook.app

where [UUID] is the unique number of the directory for the app on the device.

Extract the entitlement xml file of the app:

Desktop# ldid -e Facebook > entitlements.xml

Disable the MH_PIE bit using the change_mach_o_flags.py

Desktop# python change_mach_o_flags.py --no-pie Facebook

Re-sign the app

Desktop# ldid -Sentitlements.xml Facebook

backup the old copy on the device

iPhone# cp Facebook Facebook.bak

Copy the altered binary back to the device

now we reattach gdb and inspect the application memory again:
(gdb) x/20x 0x3000
0x3000: 0x00000000 0x00000000 0x00000000 0x00000000
0x3010: 0x00000000 0x00000000 0x00000000 0x00000000
0x3020: 0x00000000 0x00000000 0x00000000 0x00000000
0x3030: 0x00000000 0x00000000 0x00000000 0x00000000
0x3040: 0xe59d0000 0xe28d1004 0xe2804001 0xe0812104

(gdb) info mach-region 0x3000
Region from 0x3000 to 0x993000 (r-x, max r-x; copy, private, not-reserved)

Which confirms that ASLR is now disabled and we can now decrypt the application for further analysis.