Tuesday 30 July 2013

VMWare Fusion 5 DHCP Assigned Static IP...

In order to have DHCP assigned Static IP addresses on a Fusion 5 Virtual machine you need to modify the following file:

/Library/Preferences/VMware\ Fusion/vmnet8/dhcpd.conf

The contents of the file should look like this:




To add a reserved IP you will need the hostname and mac address of your host.

Under the section "DO NOT MODIFY SECTION" add the following:

host <YOURHOSTNAME> {
hardware ethernet <YOUR MAC ADDRESS>;
fixed-address <THE IP TO ASSIGN>;
}

It should look something like this:


My hostname is kingpin.
My MAC Address is 00:0C:29:70:0D:4B.
The IP I want to assign is 172.16.137.100

Worth noting, when choosing an IP to assign it must be from the subnet specified further up in the file and not be from the range.

For example, in my config file in the "DO NOT MODIFY SECTION" I have:

subnet 172.16.137.0 netmask 255.255.255.0 {
 range 172.16.137.128 172.16.137.254;
option broadcast-address 172.16.137.255;
option domain-name-servers 172.16.137.2;
option domain-name localdomain;
default-lease-time 1800;                # default is 30 minutes
max-lease-time 7200;                    # default is 2 hours
option netbios-name-servers 172.16.137.2;
option routers 172.16.137.2;
}

I have to choose an IP that is within the 172.16.137.0/24 range and is not being used in the current DHCP scope.

172.16.137.1 and 172.137.137.2 are used by VMWare and the IP's from 172.16.137.128 - 172.16.137.254 are reserved in the DHCP scope.

That leaves me with any IP from 172.16.137.3 - 172.16.137.127.

I chose 172.16.137.100 as it is easy to remember and I can start counting up from there.

Simples!

Friday 19 July 2013

Bumpin' Swipe Locks...

An iOS application I use a fair bit has a simple swipe code authentication. The basic idea is you log in every 24 hours with your username and password, then for the next 24hrs you can use a swipe code rather than have to re-type your password each time you want to view the contents of the app. If you get the swipe code wrong more than twice, you also have to enter your password again.

I decided to take a look at how this worked and see if you could fudge the app so that you never had to enter your password (after initial setup) so it wouldn't time out after 24hrs and if I got the swipe wrong (I've not long had my new hands) I could have more than 2 attempts.

First of all I used clutch (lazy way) to decrypt the binary and then class-dump-z to dump out the classes and methods, I'm not going to go into any detail here on these two tools. There is plenty out there if you google it!

Looking through the class-dump-z output I could see a couple of class's that looked interesting one was called XXXSecurity and the other was called XXXSecurityKeys... hmm.

After a little bit of tinkering with theos (a new favourite tool) I was able to get some additional debug on both of these classes as they were being called. If you use logify as below, it will will create you the output to go into your tweak file.

$ /opt/theos/bin/logify.pl yourclass.h > Tweak.xm

Once the tweak is installed onto the device it will log all the output into syslog. It logs the class and method as they are called and the values returned, pretty handy.

I started to use the application and could see in syslog that as I swiped across the tiles the application would login and call the following method:


 -[<XXXSecurity: 0x1d8d18d0> canLoginWithSwipe] = 1

Which was then closely followed by:

-[<XXXSecurity: 0x59405c0> loadPasswordWithSwipeCode:147A]

After trying a few more swipes it soon became obvious the swipe pad was laid out as below:


So if I could get [XXXSecurity canLoginWithSwipeCode] to always return true (1) I would be rockin' the dance floor. This was pretty simple and is a lot like the removing simple jailbreak detection post I did perviously. I created the tweak below and installed:


Once compiled and installed this worked a treat I could keep trying my swipe code.

After looking at the syslog output for a while I began to wonder what would happen if I used cycript to call the various methods, would the app just pop open? If I could do this I could then attempt to brute force the swipe code by passing values to cycript to try? Swipe codes are pretty simple, theres not much entropy.

I started to play around with cycript and wasn't really getting anywhere, so I began to google as this is a fairly common technique for hacking apps, Jailbreak tweakers do this a lot. After a short time googling I stumbled across this blog and also this blog from Prateek Gianchandani, it was really useful but I wasn't getting anywhere so I dropped Prateek a mail. Prateek responded and was able to point me in the right direction. My Objective C isn't great, I am at best a n00b (but learning fast). He explained that it looked like the method that was being called (see below) was an instance method and I needed to find the reference to the instance.

-[<XXXSecurity: 0x59405c0> loadPasswordWithSwipeCode:147A]

A few more emails backwards and forwards, and a bit of digging in cycript, I eventually found that by calling the following the app would return the logged in users password...

cy# [[XXXSecurity sharedInstance]loadPasswordWithSwipeCode:@"147A"]
@"password123"

If I supplied the wrong swipe code I got null back

cy# [[XXXSecurity sharedInstance]loadPasswordWithSwipeCode:@"1234"]
null

So all I had to do was create a little bash script that would loop round a wordlist of swipe codes and when != null was returned I would have my password... simples!

I knocked up the bash script below to brute force the swipe code and it returned the password quite quickly.  Most swipe codes aren't that long so creating an effective wordlist isn't too hard.



The beauty of this attack via cycript is that even though the app has a password attempt limit of 10 attempts set, it's totally ignored when you use cycript to inject code into the runtime. The other methods aren't called so the app doesn't even know it has been abused or how many times the password has been tried.

I decided to reset the swipe code and check that the bash script worked when I tried against a different swipe code, just incase there were any errors.

As I did this I noticed a method being called that looked quite interesting, it looked like there was a specific method for for setting a new swipe code:

-[<XXXSecurity: 0x59405c0> setSwipeCode:0369AB]

If I could call this and set my own swipe code without any verification of the old swipe code or users current passcode, I could then call the method "loadPasswordWithSwipeCode" with the new swipe code I had set and return the logged in users passcode... whoop whoop no more bruteforce required!!

The following worked a charm and I had the users password:

cy# [[XXXSecurity sharedInstance]setSwipeCode:@"0000"]
cy# [[XXXSecurity sharedInstance]loadPasswordWithSwipeCode:@"0000"]
@"password123"

I decided that I should probably disable the swipe code and only use a password from now on, but doing this didn't work. I could still set any swipe code and return the password. In fact this was probably worse as you even wouldn't know the swipe code had been changed.

The only saving grace for this attack is that you need a Jailbreak for it to work else you cannot install cycript, ssh etc. Having said that I'm pretty sure there is probably some jailbreak 0day out there in the wild that hasn't been patched by Apple.

Thursday 11 July 2013

Remember to removePIE...

A couple of weeks back I was reversing an app and trying to work out what it was doing. I had removed the encryption (the short hand way) using clutch and had the class-dump-z output, but this wasn't quite enough. I needed to go a bit deeper  as I wanted to know a bit more about what was going on.

I already had GDB installed on the device so I decided to spark the application up and attach to the running process. This all went well, I then set my self a couple of breakpoints which seem to be excepted. I hit C and continued to debug the app. Each time the app got to the point I was expecting it to stop it would just keep going. Hmmm odd, maybe GDB isn't working quite right, I'lll try LLDB.

I configured LLDB to work remotely and started a session on my laptop, once again configuring the break points I wanted. Again the app just continued to run no problems, wtf. This was getting frustrating, had the developer configured some anti debug tactics. I had a look around and I wasn't seeing any "Segmentation fault: 11" errors on attach so I assumed they hadn't. Both GDB and LLDB were just not stopping on any of the breakpoints I had set.

After much searching, I came across another blogpost that simply said "Can you debug iOS applications if ALSR is set". A £2 coin hit the floor, boom. I had forgotten disable the ALSR protection. I downloaded removePIE from here https://github.com/peterfillmore/removePIE, copied it to my device and ran against the app.

Bingo, my breakpoints were being hit and working perfectly on both GDB and LLDB. I won't forget this again...

If you want to know more about disabling ALSR and how it works check out the right up here http://www.securitylearn.net/2013/05/23/disable-aslr-on-ios-applications/.


Tuesday 2 July 2013

BYOD - Build Your Own Device...

Recently I have changed a few screens on iPhones, iPods and iPads, I have even got the wife doing them for friends and family. The idea was to look at starting this up as an additional service that the business could provide as well as just consultancy. Part of my research has required finding good parts at cheap prices, after a little bit of googling I quickly came across www.alibaba.com. The best way I can think of to describe the Ali Ba Ba website is "Amazon for Chinese manufacturers". There is literally tons of stuff up there that is all manufactured in China and sold at cheap prices, you can buy everything from Light bulbs to ride on electric cars for kids! My only recommendation is don't make out your interested in anything unless you really (really, really, really) want it. I get 2-3 mails a week offering me LED light bulbs from a girl called "Lucy Wu" that will not give up, her emails do provide a bit of light humor as she often tells some round the houses funny story about what she has been up to that week before asking if I want to buy "the best light bulbs in the world".

After a bit of searching around on "Ali Ba Ba" I found nearly all the standard parts you would expect, the typical ones you can find on ebay and amazon such as replacement screens, cameras, batteries, dock connectors etc. 

Then I found these, an iPhone 4 logic board:

I dismissed it at first and thought that will never work, they will be fakes. Having ordered a few lcd screens and striking up a bit of a relationship with a supplier I decided to ask if they did the logic boards for devices and were they genuine, would they actually work? After a Skype chat the supplier assured me they would work and they were genuine and unlocked. The price of the boards vary but for a iPhone 4 16GB I was lookign at approx £150. Not a good price, but curiosity got the better of me and I decided to look for all the parts I would need to build a device from the ground up.

Quick trip over to iFixit to find a teardown, sure enough an exploded list of iPhone 4 components and parts as below:


I dropped a message to the supplier I had been using and asked them if they could supply 1 x all of the 23 items listed. Sure, they would go away and find out what was required. 24hrs later they came back with a list and a price for all the items, "how many did I want?". I have to stress, I just wanted to do this as an experiment, this wasn't designed to make me any money, in fact it made me a loss, I could buy a 2nd hand iPhone from ebay a lot cheaper. I wanted to know if I could find all the parts, could I actually build my own iPhone, thats what we used to do with PCs right?!?!

I ordered the items I needed and 4-5 days later a courrier dropped the package to my door with all the items.

Now this wasn't exactly the unboxing experience you get when you purchase a nice new phone, I should have probably made a video of it and posted that up but I only took some pictures, here is what I got.

A dirty old cardboard box with bits in...



Here are the main parts, Front screen, back glass, Logic Board, and Main frame. Attached to the main frame was the volume buttons, mute switch, front camera, back camera, ear speaker, loud speaker, dock / charging point. These were already wired up for me, I hadn't asked for this as I wanted to do it myself but it seems they had tried to be extra helpful. :( 


Also included was a bag of screws, of which I had a rough idea what went where but a lot of this was going to be guess work. 




I had a quick look at a video from Direct Fix on how to change an LCD screen on the iPhone 4 to give me an idea of what would go where. After about an 1hr I had everything in place and it was the moment of truth... boot up.




I was amazed to see the apple logo, I didn't expect this... after 30 seconds the lock screen appeared... but it was all in Chinese. I managed to guess my way round the menu with another iPhone to hand and did a factory reset, sure enough it took me to the usual start up screen and I was able to choose my language as per a factory reset. I grabbed a SIM I had an put it in, I then attached to the WiFi network and the device registered as expected without any problems. I could attach to the mobile network and use as per a normal phone. Couple of tests to check the vibrate button, volume buttons and charging all worked ok. No problems there, just make a few calls and check that was all good... 

This is where I hit problems, I could make a call and receive a call ok but didn't hear anything out of the ear speaker, and the mic didn't seem to work. Maybe I had missed something so stripped the device down and the reassembled again, same outcome no sound and no mic. I had a spare iPhone 4 so I took the logic board out of it and swapped them over, with an original Apple logic board the new parts all worked no problem. I put the new logic board back into the new device and booted up again, but this time the LCD wasn't displaying... arrgghh!! 

After much "faffing" around stripping and assembling the two devices I came to the conclusion that the new logic board was in fact faulty so sent it back to the supplier in China. I'm guessing they may have acquired them because they are faulty or not quite up to scratch, who knows.

Once the supplier received the board back they sent to there QA team to test and check if it was faulty. I was kind of expecting the response I got back "Yeah it's all fine, no problems. Want us to send it back?" I was 100% sure it was faulty so asked them to send me a video of the part being tested and working, which they couldn't do. I have now requested a refund and after 4 weeks of hassling them everyday it looks like I might get the money back.

I was hoping that if I got a replacement logic board back that worked I could check what it was talking to by firing it via burp proxy. It doesn't look like I'm going to get one back so this is canceled. 

My conclusion from all of this is Apple make money because they are good at this and they make great devices (IMO)! The amount of engineering that goes into getting so many small parts into a device is amazing, maximum respect to the people who do this for a living (including Samsung, BlackBerry et al).

It is possible to assemble a device from parts imported from a shady Chinese supplier but it's really not worth the time, effort and chances are they will be 2nd rate parts. If you are struggling to find the money to buy one, check ebay for a damaged device and replace the bits that are damaged.

Now I have a few spare devices I would love to try and do some "chip off" type forensics... I am expecting a lot of collateral damage doing that and at the moment have no idea where to start!