Sunday, November 26, 2017

Exposing Your "Privates!"

Introduction
The following tweet popped up in my feed recently and for some reason it piqued my interest. Hey don't judge me :)

Tweet Behind This Post
The article basically provides a guide to sexting securely. If you are so inclined then you should check it out. The article suggests several apps for this type of activity including Privates! which is the focus of this post. Up until this article I had not heard of this app and so I decided to check it out. Note I didn't spend a lot of time of on it. I had some spare time and decided to give it a quick look. I really should be working on finishing up the AMFI series, but I digress. Let's get on with it then....

Environment
My environment was as follows:
- Jailbroken iPhone 5S running iOS 9.3.3
- IDA Pro
- BurpSuite
- Frida

Jailbreak Detection
I installed the app and launched it on my jailbroken device at which point I was presented with the following screen:

Jailbreak Detection
I guess that's that then....review done, right? Far from it. I first tried bypassing the detection using the usual suspects like tsProtector 8+ and xCon, both of which failed. I don't usually use these tweaks by the way I just decided to give them a quick run. The next step then was to obtain the binary, and as discussed in the "BLIND" Reversing - A Look At The Blind iOS  post I use dumpdecrypted for this:
Obtaining The Binary via Dumpdecrypted
With binary in hand I fired up IDA Pro to see what was up. The first thing I searched for was occurrences of the strings shown in the jailbreak detection notification. When that came up short I looked for references to common jailbreak artifacts like "Cydia", "/usr/bin/ssh","/usr/bin/sshd" etc. This led to the -[BMDevice files] method:

Jailbreak artefacts
And this method was referenced by the -[BMDevice isValid]  method as shown:

isValid Snippet
The method also checks for things like whether or not the call to fork was successful - this call should fail on a non-jailbroken device. So essentially this detection is your typical run of the mill routine. I only went into this level of detail to explain the approach and give you some tips on what to look for.

Jailbreak Bypass
Bypassing the check is trivial. The function returns a boolean value - bool __cdecl -[BMDevice isValid](BMDevice *self, SEL) - so whatever it returns we just need to flip it. For this we turn to Frida. The next step is to determine the app identifier and for that you issue frida-ps -Uai

Process List via Frida
We then hook the -[BMDevice isValid] method and check it's return value:

Determining Return Value
Where the private.js script is defined as:

 if(ObjC.available){  
   var auth = ObjC.classes.BMDevice["- isValid"];  
     Interceptor.attach(auth.implementation, {  
       onLeave: function onLeave(retval) {  
       console.log("\t[-] Type of return value: " + typeof retval);  
       console.log("\t[-] Original Return Value: " + retval);  
      }  
   });  
 }  

The bypass then is simply to flip the return value from 0 to 1:

 if(ObjC.available){  
   var auth = ObjC.classes.BMDevice["- isValid"];  
     Interceptor.attach(auth.implementation, {  
       onLeave: function onLeave(retval) {  
       console.log("\t[-] Type of return value: " + typeof retval);  
       console.log("\t[-] Original Return Value: " + retval);  
       newretval = ptr("0x1")  
       retval.replace(newretval)  
       console.log("\t[-] New Return Value: " + newretval)  
      }  
   });  
 }  

And with that the jailbreak detection is bypassed.

Authorization
With the jailbreak detection bypassed the next step was to examine the traffic. The app presents the following login screen:

Login
And upon successful login, sends requests similar to the following:

Sample Requests
Now this is where things get interesting. Let's take a look at the request to the retrieve messages endpoint - /messages:


Basic Authorization
You are indeed seeing correctly, Privates! is using Basic Authorization. For those that may not be aware this is just a base64 encoded value usually consisting of a username:password pair. In the case of Privates! the value is the user's phonenumber:password. Generally this approach is not recommended.

This brings up an interesting observation, apart from redirecting you to the login screen, the logout functionality shown below really doesn't do much, does it?

Logout
Confirmation Bypass
Another interesting thing was that if the app didn't recognize the device you were logging in from you would be sent a confirmation a code. Fair enough. Now let's say I somehow captured someone's credentials and attempted to log in from my own device. The victim would receive an SMS message with the code and since I as the attacker don't have access to their device, the victim would simply ignore it and carry on, because after all whoever is trying to access their account doesn't have the 6 digit pin.

Confirm Flow
An incorrect confirmation attempt results in a 400 Bad Request response from the server:
Server Response Incorrect Code
Can you see where this is going yet? All the attacker has to do is forge a successful response from the server and they have bypassed the confirmation check. Figuring out a successful response is easy. Simply copy the response from a successful request to the /login endpoint.

Forged Success

Connected Device Bypass
Another feature of Privates! is that it doesn't allow you to view messages if the device is connected(read connected via usb). If the device is connected, trying to read a message results in the following message:

Device Connected Error
Incidentally, take note of the Viewing Period as we will get back to it. Ok, so to track this down I again searched for the displayed message and found it in the -[BMMessageConnectionViewController updateWithUSBMessage] method.

updateWithUSBMessage Responsible For Displaying Message
I then searched for occurrences of updateWithUSBMessage which led to the [BMMessageConnectionViewController handleConnectionChange] method:

handleConnectionChange Method
This method then called the isDeviceDiconnected(yes without the s, I guess as an anti-debugging feature right....) method at offset 0x00000001000C3E40. As it turns out this method returns a boolean value. If you are wondering how it determines if the device is connected it simply checks the battery state(using UIDevice) after all if the device is connected the battery will be charging right:

Checking Battery State
Bypassing this check is therefore similar to the jailbreak detection bypass in that we determine the original return value and then flip it. We end up with the following:

 var device = ObjC.classes.BMMessageConnectionViewController["isDeviceDiconnected"];  
     Interceptor.attach(device.implementation, {  
       onLeave: function onLeave(retval) {  
       console.log("\t[-] DeviceConnected Type of return value: " + typeof retval);  
       console.log("\t[-] DeviceConnected Original Return Value: " + retval);  
       newretval = ptr("0x1")  
       retval.replace(newretval)  
       console.log("\t[-] DeviceConnected New Return Value: " + newretval)  
      }  
   });  

And with that the check is bypassed and we can carry on. One thing to note here is that the isDeviceDiconnected method is a class method(+ class method, - instance method).

Viewing Timer Bypass
So I hinted at this earlier. The sender of the message has the option of specifying the Viewing Period of the message:
Setting Viewing Period
From the above settings you only get a maximum of 30s. In fact there are three settings you can choose from mild, wild and insane with Viewing Periods being 30, 15 and 10 seconds respectively. But let's suppose I want to errrrrmmmmm how do I say this....."enjoy the image" a bit longer. Well the astute reader would have noticed that communication between the app and the server have the following Content-Type: application/json. Do you see where this going? No way what I am about to do should work right? Well, when you retrieve a message one of the parameters included in the response is duration - highlighted in red:

Setting Viewing Duration
To bypass the check just change this to a value of your choosing and enjoy those images...Here I changed it to 60 seconds:
Extended Viewing
Security Options Bypass
Even more interesting is that the sender can specify the actions the recipient has to take before being able to view the message. These actions are defined as Security Options - security_options": ["touch", "motion", "camera"]. Camera means a picture is taken, motion means you have to hold the device a particular way and touch is exactly that - you have to tap the screen. Again you can edit this list and remove the actions you don't want to perform and the sender would be none the wiser.

Unhandled Exceptions
In some instances, the app returned some rather, dare I say "helpful" error messages:

Verbose Errors
This is kind of information is often useful to attackers as it can be used to plan further attacks. At the very least, it shows that some "conditions" were not being properly handled. Let me hasten to point out that I didn't hack the server. The above error message was generated when I attempted to retrieve a message that had been recalled by the sender.

Conclusion
In the end you use these apps at your own risk. The app definitely has areas that it needs to improve on. I didn't even bother getting into the crypto because this was just some weekend fun(the real reason is crypto is hard). I am sure there are other areas to look at - as I said earlier this was by no means an in-depth review - and if you are so inclined this post should have provided enough information for you to go further. At the very least it should have provided some food for thought.

Until next time....Happy Hacking!!!

Disclaimer: This blog is intended for educational purposes only. Any actions and or activities related to the material contained within this Website is solely your responsibility.The misuse of the information in this website can result in criminal charges brought against the persons in question. This author will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.

Sunday, October 29, 2017

"BLIND" Reversing - A Look At The Blind iOS App


Intro
"Blind is an anonymous community app for the workplace". In other words, if you as an employee have ever wanted to "speak freely" aka bash your employer/coworkers anonymously - because let's face it that's really what it comes down to - then BLIND is maybe the app you are looking for. This looked like a rather interesting app to "poke" at as I wanted to know just exactly what was happening under the hood.

Scope and Environment
My focus was on the app itself. And I registered with linkedin as opposed to my work email. This had some limitations chief among which was restricted access to the members area. I also did not look at all the functionality. Instead I chose to look at what I considered to be the core components. And even then I did not cover everything.

My environment was as follows:
- Jailbroken iPhone 5S running iOS 9.3.3
- jtool
- IDA Pro
- Hopper
- BurpSuite Pro
- Frida

Jailbreak Detection
The first thing I noticed is that the app did not have any jailbreak detection routine. Now before you go crazy and be like "well that's not a security issue.." I tend to agree with you. I don't think lack of these type checks is a security issue per se. I think more in terms of it being a part of a broader defense in depth approach.

Certificate Pinning
The second observation is that the app did not check the authenticity of the remote endpoint by verifying its SSL certificate(Certificate Pinning); therefore its feasible to perform Man-in-the-Middle (MiTM) attacks to eavesdrop on and tamper with data. Let me hasten to say however that this is not as bad as it sounds because first the attacker would have to trick the user into installing a malicious certificate on the device and second - as you will see later on - the app encrypts the data it sends to the back end.

On a side note the argument that the attacker needs to first trick the user into installing a rogue CA is a common one. And yet while I agree there, there are tools that aim to simplify the process. This blog post from Sensepost is one such example.

One final thing to note here regarding Certificate Pinning, is that the app provides two options for logging in: work email and LinkedIn Verification(see below). As I mentioned before I opted for the latter. A side effect of this choice was that because there was no pinning an attacker could capture the linkedin credentials. Provided of course you installed the malicious cert.

Login options
Obtaining The Binary
Ok so with those "issues" out of the way let's obtain the binary and start reversing. I use the dumpdecrypted dylib. So I simply ssh'd into the device and ran the following:

 root@Jekyl (/var/root)# su mobile  
 mobile@Jekyl (/var/mobile/Documents)# DYLD_INSERT_LIBRARIES=/var/root/dumpdecrypted.dylib /private/var/containers/Bundle/Application/3C411AB3-6018-4604-97D2-DC2A546EAB85/teamblind.app/teamblind  
 mach-o decryption dumper  
 DISCLAIMER: This tool is only meant for security research purposes, not for application crackers.  
 [+] detected 64bit ARM binary in memory.  
 [+] offset to cryptid found: @0x1000d4f28(from 0x1000d4000) = f28  
 [+] Found encrypted data at address 00004000 of length 7995392 bytes - type 1.  
 [+] Opening /private/var/containers/Bundle/Application/3C411AB3-6018-4604-97D2-DC2A546EAB85/teamblind.app/teamblind for reading.  
 [+] Reading header  
 [+] Detecting header type  
 [+] Executable is a plain MACH-O image  
 [+] Opening teamblind.decrypted for writing.  
 [+] Copying the not encrypted start of the file  
 [+] Dumping the decrypted data into the file  
 [+] Copying the not encrypted remainder of the file  
 [+] Setting the LC_ENCRYPTION_INFO->cryptid to 0 at offset f28  
 [+] Closing original file  
 [+] Closing dump file  

Note that on iOS 9.3.3 running DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib from root results in the process you are injecting into being killed:

 root@Jekyl (/var/root)# DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /private/var/containers/Bundle/Application/3C411AB3-6018-4604-97D2-DC2A546EAB85/teamblind.app/teamblind  
 zsh: killed   DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib   
 root@Jekyl (/var/root)#   

The workaround is to first switch to mobile and then cd into /var/mobile/Documents as shown above. Note also that we are able to inject our own dylib because the BLIND app does not have the __RESTRICT Segment.

 LC_SEGMENT_64     Mem: 0x100008000-0x100008000     __RESTRICT  
      Mem: 0x100008000-0x100008000          __RESTRICT.__restrict  

This is a null segment (size 0) which serves to notify DLYD not to trust any DLYD* environment variables.

Identifying Endpoints
One of the things I usually do when looking at a binary is to dump the strings and search for URL endpoints. I then use that list to corroborate Burpsuite traffic.

 macho-reverser:BLIND macho-reverser$ jtool -d __TEXT.__cstring teamblind.decrypted | grep "http"  
 Address : 0x1006dcfd0 = Offset 0x6dcfd0  
 0x1006df366: https://api.linkedin.com/v1/people/~:(id,email-address,first-name,last-name,headline,num-connections,industry,summary,specialties,positions:(id,title,summary,start-date,end-date,is-current,company:(id,name,universal-name,type,size,industry,ticker,email-domains)),educations:(id,school-name,field-of-study,start-date,end-date,degree,activities,notes),associations,interests,num-recommenders,date-of-birth,publications:(id,title,publisher:(name),authors:(id,name),date,url,summary),patents:(id,title,summary,number,status:(id,name),office:(name),inventors:(id,name),date,url),languages:(id,language:(name),proficiency:(level,name)),skills:(id,skill:(name)),certifications:(id,name,authority:(name),number,start-date,end-date),courses:(id,name,number),recommendations-received:(id,recommendation-type,recommendation-text,recommender),honors-awards,three-current-positions,three-past-positions,volunteer)?format=json  
 0x1006df80e: http://us.teamblind.com  
 0x1006e19ad: https://api.linkedin.com/v1/people/~:(id,email-address)?format=json  
 0x1006e75df: https://m.facebook.com/settings/email  
 0x1006e760c: https://www.linkedin.com/m/settings/email  
 0x1006ea5ec: https://docs.google.com/forms/d/e/1FAIpQLSc_J26TtkDL7HXcLeFXC2jy6lb1PmJSPnh51_ng7fr1638p_Q/viewform  
 0x1006ee9c3: https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=%@&scope=%@&state=%@&redirect_uri=%@  
 0x1006f4865: https://krapi.teamblind.com  
 0x1006f4881: https://usapi.teamblind.com  
 0x1006f489d: http://kr.stage.teamblind.com:8080  
 0x1006f48c0: http://us.stage.teamblind.com:8080  
 0x1006f48e3: http://dev.teamblind.com:8080  
 0x1006f4901: http://us.dev.teamblind.com:8080  
 0x1006f4922: https://kr.teamblind.com  
 0x1006f493b: https://us.teamblind.com  
 0x1006f4954: https://krnotifier.teamblind.com  
 0x1006f4975: https://usnotifier.teamblind.com  
 ----

You can also use it to get a list of other potential targets as well. That leads us to Burpsuite. Let's fire it up and examine the traffic. Recall earlier I said that the BLIND app did not implement Certificate Pinning and that it wasn't all that of an issue because the app encrypted the data it sent to the backend. This is what a request looks like.

Sample request
The only thing we can confirm are some of the url's we identified earlier. So we are in fact BLIND. But if this data is in fact encrypted, then how and where is/are the encryption key(s) stored/generated? And can we see the plaintext data the app is sending to the server?

Extracting Classes 
To answer those questions, let's first dump the classes and see if anything looks interesting. We start by listing the segments and there we see references to Objective-C:

 macho-reverser:BLIND macho-reverser$ jtool -l teamblind.decrypted   
 LC 00: LC_SEGMENT_64     Mem: 0x000000000-0x100000000     __PAGEZERO  
 LC 01: LC_SEGMENT_64     Mem: 0x100000000-0x1007a4000     __TEXT  
      Mem: 0x100007a90-0x100663f18          __TEXT.__text     (Normal)  
      Mem: 0x100663f18-0x10066723c          __TEXT.__stubs     (Symbol Stubs)  
      Mem: 0x10066723c-0x10066a560          __TEXT.__stub_helper     (Normal)  
      Mem: 0x10066a560-0x100671ec0          __TEXT.__const       
      Mem: 0x100671ec0-0x1006dcfc9          __TEXT.__objc_methname     (C-String Literals)  
      Mem: 0x1006dcfd0-0x10074ca58          __TEXT.__cstring     (C-String Literals)  
      Mem: 0x10074ca58-0x100754bb2          __TEXT.__objc_classname     (C-String Literals)  
      Mem: 0x100754bb2-0x100767daa          __TEXT.__objc_methtype     (C-String Literals)  
      Mem: 0x100767daa-0x100768e18          __TEXT.__ustring       
      Mem: 0x100768e18-0x100788c4c          __TEXT.__gcc_except_tab       
      Mem: 0x100788c50-0x10078b967          __TEXT.__swift3_typeref       
      Mem: 0x10078b968-0x10078c6a0          __TEXT.__swift3_capture       
      Mem: 0x10078c6a0-0x10078d720          __TEXT.__swift3_fieldmd       
      Mem: 0x10078d720-0x10078e67d          __TEXT.__swift3_reflstr       
      Mem: 0x10078e680-0x10078edc8          __TEXT.__swift3_assocty       
      Mem: 0x10078edc8-0x10078f3c8          __TEXT.__swift2_proto       
      Mem: 0x10078f3c8-0x10078f478          __TEXT.__swift2_types       
      Mem: 0x10078f478-0x10078f4dc          __TEXT.__swift3_builtin       
      Mem: 0x10078f4dc-0x1007a3d20          __TEXT.__unwind_info       
      Mem: 0x1007a3d20-0x1007a4000          __TEXT.__eh_frame       
 LC 02: LC_SEGMENT_64     Mem: 0x1007a4000-0x100980000     __DATA  
      Mem: 0x1007a4000-0x1007a4ba8          __DATA.__got     (Non-Lazy Symbol Ptrs)  
      Mem: 0x1007a4ba8-0x1007a6dc0          __DATA.__la_symbol_ptr     (Lazy Symbol Ptrs)  
      Mem: 0x1007a6dc0-0x1007a6e00          __DATA.__mod_init_func     (Module Init Function Ptrs)  
      Mem: 0x1007a6e00-0x1007cfd20          __DATA.__const       
      Mem: 0x1007cfd20-0x10080f300          __DATA.__cfstring       
      Mem: 0x10080f300-0x100811498          __DATA.__objc_classlist     (Normal)  
      Mem: 0x100811498-0x1008114d0          __DATA.__objc_nlclslist     (Normal)  
      Mem: 0x1008114d0-0x100811890          __DATA.__objc_catlist     (Normal)  
      Mem: 0x100811890-0x1008118e8          __DATA.__objc_nlcatlist     (Normal)  
      Mem: 0x1008118e8-0x1008123b0          __DATA.__objc_protolist       
      Mem: 0x1008123b0-0x1008123b8          __DATA.__objc_imageinfo       
      Mem: 0x1008123b8-0x10092bf38          __DATA.__objc_const       
      Mem: 0x10092bf38-0x100944b20          __DATA.__objc_selrefs     (Literal Pointers)  
      Mem: 0x100944b20-0x100944c88          __DATA.__objc_protorefs       
      Mem: 0x100944c88-0x100946ee0          __DATA.__objc_classrefs     (Normal)  
      Mem: 0x100946ee0-0x100948918          __DATA.__objc_superrefs     (Normal)  
      Mem: 0x100948918-0x10094ee80          __DATA.__objc_ivar       
      Mem: 0x10094ee80-0x100965188          __DATA.__objc_data  
 ------

We can therefore dump the classes and their methods using the objc option of jtool - JCOLOR=1 jtool -v -d objc teamblind.decrypted:


Extract class information with jtool
Note that while I used IDA for this post there is nothing stopping you from using jtool for your disassembly needs. For example if you wanted to zero in on a particular class you could use jtool  like so jtool -d UserControl:getSecretUserDefaultString: teamblind.decrypted

Disassembling class info
Deciphering Encrypted Values
Ok so at this point we can intercept traffic, but alas, it's encrypted. And that's a bummer. Let's proceed with figuring out how the encryption is implemented. As you saw earlier, BLIND allows you to sign up using either your work email or linkedin. Past that screen that, you are presented with the Create Account option:
Sign Up
The settings for the app can be found in com.teamblind.blind.plist and is located at /private/var/mobile/Containers/Data/Application/<app_id>/Library/Preferences/com.teamblind.blind.plist. If you check the file at this point you will notice that it contains the plaintext email - and associated company - you signed up with. You can use the plutil utility to read the file.

plist snippet
Once you select your password and username and hit GET STARTED things change.


Now your email is no longer stored in plaintext but is encrypted(?), and your password, along with several other values get added. Keep in mind it's never a good idea to store passwords or anything sensitive for that matter in plist files.  The astute reader would have noticed that I did not black out the password_enc value. The name of the key suggests the value might be encrypted since it ends with _enc, but is it? One other thing I want to point out is that this value is integral to the encryption process. But we will get to that later. For now let's dig into this value some more.

As it turns out the "encrypted" password is nothing more than an md5 hash, and you can see this in the requestPassword method of the AuthCompleteViewController class.

Create password hash
At 0x000000010004EB50 we get the user supplied value and then calculate the md5 hash at 0x000000010004EB8C. To verify this, we fire up python where you see it is the same value from earlier(plist). Now you know my super secret password.

 >>> import hashlib  
 >>> m = hashlib.md5()  
 >>> m.update("password#1")  
 >>> print m.hexdigest()  
 5486b4af453c7830dcea12f347137b07  
 >>>   


Identifying ViewControllers
If you are wondering how I determined what class to check, I first navigated to the Create Account page and then using cycript determined the ViewController like so:

 root@Jekyl (/var/root)# ps aux | grep blind  
 mobile  4136  0.1 5.8  815696 59532  ?? Ss  4:10PM  0:06.85 /var/containers/Bundle/Application/3C411AB3-6018-4604-97D2-DC2A546EAB85/teamblind.app/teamblind  
 root   4139  0.0 0.0  657104  212 s000 R+  4:11PM  0:00.01 grep blind  
 root@Jekyl (/var/root)# cycript -p 4136  
 cy# [[[UIWindow keyWindow] rootViewController] _printHierarchy].toString()  
 "<UINavigationController 0x15615d000>, state: appeared, view: <UILayoutContainerView 0x157415a30>\n  | <RootViewController 0x1570db260>, state: disappeared, view: <UIView 0x157337ab0> not in the window\n  | <AuthCompleteViewController 0x155f587c0>, state: appeared, view: <UIView 0x155da07a0>"  
 cy#   

Recall as well that your was email encrypted. The encryption routine is also in the requestPassword method. Your email is first retrieved from the plist(NSUserDefaults) and then passed to the encryptHES256 method of NSString ([NSString encryptHES256:])

Get user email
The encryptHES256 method then generates an encryption key with a simple XOR of your password and some "random" value before handing off to the AES256EncryptWithKey method where the actual encryption takes place - technically this method calls another function but you get the picture. Can you spot the "randomness"?
Encrypt user email
Frida
With a little help from Frida we can see this in action. If you are not yet familiar with Frida I HIGHLY recommend that you familiarize yourself with it and add it to your arsenal. I cannot say enough about this tool. I also recommend checking out Frida CodeShare for ready to go scripts. Of course it goes without saying that you should review any code before running it.

Using Frida and the ObjC method observer script from CodeShare we can observe the AES256EncryptWithKey method in action:

 macho-reverser:BLIND macho-reverser$ frida -U --codeshare mrmacete/objc-method-observer -f com.teamblind.blind  
    ____  
   / _ |  Frida 10.6.15 - A world-class dynamic instrumentation framework  
   | (_| |  
   > _ |  Commands:  
   /_/ |_|    help   -> Displays the help system  
   . . . .    object?  -> Display information about 'object'  
   . . . .    exit/quit -> Exit  
   . . . .  
   . . . .  More info at http://www.frida.re/docs/home/  
 Spawned `com.teamblind.blind`. Use %resume to let the main thread start executing!  
 [iPhone::com.teamblind.blind]-> %resume  
 [iPhone::com.teamblind.blind]-> observeSomething('*[* *AES256EncryptWithKey:*]');  
 (0x125fcdca0) -[NSData AES256EncryptWithKey:]  
 AES256EncryptWithKey: password#1^0123456789abcdefghijk  
 0x1001b25cc teamblind!0x11e5cc  
 0x1000e2c7c teamblind!0x4ec7c  
 ----  

Ok so we know how our password and email are encrypted. And by the way figuring out the other encrypted values is basically repeating the above steps. Let's now move to the actual traffic.

As we saw earlier - while monitoring the traffic sent from the device - all requests included a payloadI searched IDA for this string, and after going through the results, found that most of the request parameters were set in the -[NetworkControl encRequestWithParams:showAlert:completionBlock:failBlock:] method.

Payload string search
encRequestWithParams
The method first tries to retrieve a previously generated encryption key and initialization vector (iv), and if that fails it calls out to the makeKeyAndIvForEnc (-[EncriptControl makeKeyAndIvForEnc]) method of the EncriptControl class, and yes that is Encript with i. Security through obscurity maybe..... :)

Generating the encrypted payload
makeKeyAndIvForEnc
This is where things get somewhat interesting, as it appears the encryption key is generated using a combination of the users password and some hardcoded value. Remember the encrypted password(password_enc) from earlier? The method will first try to retrieve it:

Retrieve encrypted password(password_enc)
The method will then generate another md5 hash based on a hardcoded value:

Generate some static value
If their was an issue retrieving the user password, another hash is generated:

Generate second md5 hash
Finally the key is set and this ends up being either a combo of hash1+hash2 or hash1+password_enc

Generate the actual key
So in our case the encryption key should be md5("QkdEhdk") + md5("password#1"), which gives us "c07bcdc2 3522ed81 fb76db0c 0c4387cf 5486b4af 453c7830 dcea12f3 47137b07".

The remainder of the method just sets the initialization vector (iv):

Generate IV
Giving Sight To The Blind
The encRequestWithParams method of the NetworkControl class calls makeKeyAndIvForEnc of the EncriptControl class to setup encryption. Once that is done the encRequestWithParams method goes on to call makePayloadDataWithJsonString of the EncriptControl class. This method then calls aesEncrypt from CocoaSecurity - using the encryption keys and IV from earlier - and returns the base64 encoded cipher-text which is what you see in Burp.
Encrypt the payload
Go back to the jtool -d objc dump for a second, and take note of the instances variables for the EncriptControl class:

Encript instance variables
We now have all the pieces of the puzzle and can therefore craft a Frida script to give us the instance variables i.e. encryption keys etc as well as the plaintext data and corresponding ciphertext:

 if(ObjC.available){  
   var makeKandIv = ObjC.classes.EncriptControl["- makePayloadDataWithJsonString:"];  
     Interceptor.attach(makeKandIv.implementation, {  
      onEnter: function(args) {  
        /* Get Class/Params */  
        var obj = ObjC.Object(args[0]);  
        var params = ObjC.Object(args[2]);  
        /* Get ivars */  
        var ivar = obj.$ivars;  
        // Print ivars values   
        console.log("-----------------------------------------------------------\n");  
        console.log("_encKey: " + ivar["_encKey"] + "\n");  
        console.log("_encIv: " + ivar["_encIv"] + "\n");  
        console.log("_encIvStr: " + ivar["_encIvStr"] + "\n");   
        console.log("_encKeyForDM: " + ivar["_encKeyForDM"] + "\n");   
        console.log("_encKeyForDM: " + ivar["_encIvForDM"] + "\n");   
        console.log("-----------------------------------------------------------\n");   
        console.log("PARAMS: " + params);  
       },  
      onLeave: function onLeave(retval) {  
         console.log("Encrypted Payload: " + new ObjC.Object(retval).toString() + "\n");  
      }  
   });  
 }  

And so our once encrypted burp traffic:
Encrypted burpsuite traffic
Now becomes:
Plaintext data w/ encryption keys

Additionally, hooking the convertDictionaryEncWithResultStr: method of the EncriptControl class prints the plaintext server response. At this point you could consider using the Brida Burpsuite plugin for other options.

Conclusion
Well that's all I had for today. As I pointed out earlier I didn't register a BLIND account and so I didn't have access to the member's only section or other member only functionality. I didn't care to, either, I was just interested in the blob of data I saw going across the wires in the Burp. Given the nature and claims of the app I wanted to know more about what was happening under the hood. As such no malicious traffic was sent to the BLIND servers.

Happy hacking!!!

Disclaimer: This blog is intended for educational purposes only. Any actions and or activities related to the material contained within this Website is solely your responsibility.The misuse of the information in this website can result in criminal charges brought against the persons in question. This author will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.

Friday, October 20, 2017

Reversing AppleMobileFileIntegrity (AMFI) Part 2

Recap
Let's start with a quick recap of part 1 :
  • We introduced MACF(Mandatory Access Control Framework)
  • Learned a little about KEXTs and how they relate to MACF
  • Got introduced to Policies in the context of MACF
  • Learned to identify policies on both macOS and iOS
  • Saw that AppleMobileFileIntegrity.KEXT is a policy module
  • Delved a little into policy registration to extract and identify callback functions

Ad-hoc Binaries
As discussed in part 1, AAPL has full control of all system binaries and added the hashes of these binaries in the KEXT. These binaries as we saw are referred to as being ad-hoc signed and their validation involves a simple lookup of the hash in the KEXT's TrustCache. 


The TrustCache is located in the __TEXT.__const  section of the KEXT. So if we extract the hash of the amfid binary we should be able to find it in the TrustCache. This is demonstrated below where we first extract the signature:

 macho-reverser:iOS10.3 macho-reverser$ jtool --sig amfid | grep CDHash  
           CDHash:        758a25a4549569ac0d36d3b69a92c937180a18e2 (computed)  
 macho-reverser:iOS10.3 macho-reverser$   

And then locate it in the TrustCache:

 macho-reverser:AMFI macho-reverser$ jtool -d __TEXT.__const com.apple.driver.AppleMobileFileIntegrity.kext  

You will have to search through the output as the CDHash is buried deep into the Cache.
amfid CDHash located in __TEXT.__const section
Now there was a bug here - and we will discuss it next - as for a while you could trick hijack amfid and take over it's operations. AAPL fixed this in iOS 9 and now the KEXT verifies the hash before proceeding - as seen at offset 0xFFFFFFF00644F018.

Verifying amfid CDHash in KEXT 
As a side note to help with symbolication I use joker with the -j option to generate a companion file.

Inter-Process Communication(IPC) 101
*OS is built on the XNU kernel. And at the core of XNU is Mach. This microkernel handles among other things Interprocess communications and messaging. Mach's IPC services rely on the notion of "ports" which serve as communication endpoints. Servers and clients alike can allocate ports, however servers require either some type of locator service to allow clients to find them or otherwise need to be well-known. This is where the bootstrap server comes in. It's accessible to all processes on the system which may communicate with it via the bootstrap_port. Clients can request over this port, that the server look up a given service by its name and match them with its port. Here the name is a fully qualified name like "com.apple.MobileFileIntegrity" for example.

launchd
It used to be that mach_init took on the role of bootstrap_server, however launchd has since taken over this role and claims the port(bootstrap_port) during its startup. launchd is the first user-space program to be started by the kernel and therefore has a pid of 1. It's mission is simple - launch jobs(processes) with a specified criteria. Because all processes are it's spawns they inherit access to the bootstrap_port. And so if a service wishes to register - pre-launchd it would have been via the now deprecated api's bootstrap_create_server and bootstrap_create_service - with launchd it can do so in the server's plist and call bootstrap_check_in which will result in launchd handing over the port when it is ready to service requests:

 kern_return_t bootstrap_check_in(mach_port_t bp, // bootstrap_port   
                                  const name_t service_name, // name of service  
                                  mach_port_t *sp); // out: server port  

Note also that launchd pre-registers the port in the server plist. This server port is usually ephemeral but may also be well known if the key HostSpecialPort is added. Finally on launchd, it runs both systems services(daemons) and per-user services(agents).

The server(daemon's) plists can be found in /System/Library/LaunchDaemons:


 macho-reverser:LaunchDaemons macho-reverser$ ls -l  
 total 48  
 -rw-r--r-- 1 root wheel  678 Jun 15 17:37 bootps.plist  
 -rw-r--r-- 1 root wheel  909 Apr 4 2017 com.apple.AirPlayXPCHelper.plist  
 -rw-r--r-- 1 root wheel  811 Jul 31 21:21 com.apple.AppleFileServer.plist  
 -rw-r--r-- 1 root wheel  729 Jan 26 2017 com.apple.AssetCache.builtin.plist  
 -rw-r--r-- 1 root wheel  433 Mar 1 2017 com.apple.AssetCacheActivatorService.plist  
 -rw-r--r-- 1 root wheel  448 Mar 1 2017 com.apple.AssetCacheLocatorService.plist  
 -rw-r--r-- 1 root wheel  437 Mar 1 2017 com.apple.AssetCacheTetheratorService.plist  
 --  

Ok, that was a lot of theory just now and you may be wondering how it all ties in. Well, if you look at amfid's server plist i.e. com.apple.MobileFileIntegrity.plist you will notice that the service will be registered using  HOST_SPECIAL_PORT(18):


amfid plist w/ host_special_port 
So what this means is that when the KEXT makes the up call to amfid it does so over this special port with a call to _host_get_special_port at offset 0xFFFFFFF00644EEE8. You can see the port being set at offset 0xFFFFFFF00644EEE0:
AMFI.kext up call to amfid
Stealing SPECIAL_PORTS
As we alluded to earlier, prior to iOS 9 amfid's special port could be usurped. This ccould be accomplished with a call to the host_set_amfid_port macro in <mach/host_special_ports.h>.

 #define host_set_amfid_port(host, port)     \  
      (host_set_special_port((host), HOST_AMFID_PORT, (port)))  

Let's look at an example of how we might be able to achieve this. Before proceeding however, let's first look at amfid's(225.50.12.0.0) normal initialization routine. So going back to jtool, we first list the segments:

 macho-reverser:iOS10.3 macho-reverser$ jtool -l amfid   
 LC 00: LC_SEGMENT_64     Mem: 0x000000000-0x100000000     __PAGEZERO  
 LC 01: LC_SEGMENT_64     Mem: 0x100000000-0x100004000     __TEXT  
      Mem: 0x100002bd8-0x100003778          __TEXT.__text     (Normal)  
      Mem: 0x100003778-0x1000039c4          __TEXT.__stubs     (Symbol Stubs)  
      Mem: 0x1000039c4-0x100003c28          __TEXT.__stub_helper     (Normal)  
      Mem: 0x100003c28-0x100003d48          __TEXT.__const       
      Mem: 0x100003d48-0x100003da6          __TEXT.__oslogstring     (C-String Literals)  
      Mem: 0x100003da6-0x100003fb8          __TEXT.__cstring     (C-String Literals)  
      Mem: 0x100003fb8-0x100004000          __TEXT.__unwind_info       
 LC 02: LC_SEGMENT_64     Mem: 0x100004000-0x100008000     __DATA  
      Mem: 0x100004000-0x100004090          __DATA.__got     (Non-Lazy Symbol Ptrs)  
      Mem: 0x100004090-0x100004218          __DATA.__la_symbol_ptr     (Lazy Symbol Ptrs)  
      Mem: 0x100004218-0x100004328          __DATA.__const       
      Mem: 0x100004328-0x100004348          __DATA.__cfstring       
      Mem: 0x100004348-0x100004350          __DATA.__data       
 LC 03: LC_SEGMENT_64     Mem: 0x100008000-0x100008000     __RESTRICT  
      Mem: 0x100008000-0x100008000          __RESTRICT.__restrict       
 LC 04: LC_SEGMENT_64     Mem: 0x100008000-0x10000c000     __LINKEDIT  
 LC 05: LC_DYLD_INFO       
 LC 06: LC_SYMTAB         
      Symbol table is at offset 0x8780 (34688), 69 entries  
      String table is at offset 0x8da0 (36256), 1464 bytes  
 LC 07: LC_DYSYMTAB        
        1 local symbols at index   0  
        1 external symbols at index 1  
        67 undefined symbols at index 2  
        No TOC  
        No modtab  
       116 Indirect symbols at offset 0x8bd0  
 LC 08: LC_LOAD_DYLINKER        /usr/lib/dyld  
 LC 09: LC_UUID             UUID: A3B3B122-E61E-3D39-B082-BEBE3FAA86CC  
 LC 10: LC_VERSION_MIN_IPHONEOS     Minimum iOS version:  10.3.0  
 LC 11: LC_SOURCE_VERSION        Source Version:     225.50.12.0.0  
 LC 12: LC_MAIN             Entry Point:       0x3134 (Mem: 0x100003134)  
 LC 13: LC_LOAD_DYLIB          /usr/lib/libmis.dylib  
 LC 14: LC_LOAD_DYLIB          /usr/lib/libMobileGestalt.dylib  
 LC 15: LC_LOAD_DYLIB          /System/Library/PrivateFrameworks/MobileKeyBag.framework/MobileKeyBag  
 LC 16: LC_LOAD_DYLIB          /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation  
 LC 17: LC_LOAD_DYLIB          /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit  
 LC 18: LC_LOAD_DYLIB          /usr/lib/libSystem.B.dylib  
 LC 19: LC_FUNCTION_STARTS       Offset: 34664, Size: 24 (0x8768-0x8780)   
 LC 20: LC_DATA_IN_CODE         Offset: 34688, Size: 0 (0x8780-0x8780)   
 LC 21: LC_CODE_SIGNATURE        Offset: 37728, Size: 384 (0x9360-0x94e0)   

And then we disassemble main (LC_MAIN) filtering on function calls. This will give us an idea of the general flow:

 macho-reverser:iOS10.3 macho-reverser$ jtool -d 0x100003134 amfid | grep BL  
 Disassembling from file offset 0x3134, Address 0x100003134 to next function, mmapped 0x11a561000  
   10000316c     BL   libSystem.B.dylib::_getopt     ; 0x100003928  
   10000319c     BL   libSystem.B.dylib::_os_log_create     ; 0x100003964  
   1000031dc     BL   libSystem.B.dylib::_openlog     ; 0x100003958  
   1000031e4     BL   libSystem.B.dylib::_setlogmask     ; 0x10000397c  
   1000031f4     BL   libSystem.B.dylib::_syslog     ; 0x1000039a0  
   100003210     BL   libSystem.B.dylib::_bootstrap_check_in     ; 0x1000038bc  
   100003218     BL   libSystem.B.dylib::___error     ; 0x100003898  
   100003220     BL   libSystem.B.dylib::_strerror     ; 0x100003988  
   100003234     BL   libSystem.B.dylib::_syslog     ; 0x1000039a0  
   100003270     BL   libSystem.B.dylib::_fprintf     ; 0x10000391c  
   100003278     BL   libSystem.B.dylib::_exit     ; 0x100003910  
   100003290     BL   libSystem.B.dylib::_dispatch_source_create     ; 0x1000038f8  
   1000032a8     BL   libSystem.B.dylib::_syslog     ; 0x1000039a0  
   1000032b0     BL   libSystem.B.dylib::_exit     ; 0x100003910  
   1000032b8     BL   libSystem.B.dylib::_dispatch_set_context     ; 0x1000038ec  
   1000032c8     BL   libSystem.B.dylib::_dispatch_source_set_event_handler_f     ; 0x100003904  
   1000032d0     BL   libSystem.B.dylib::_dispatch_resume     ; 0x1000038e0  
   1000032d4     BL   libSystem.B.dylib::_dispatch_main     ; 0x1000038c8  
   100003304     BL   libSystem.B.dylib::_syslog     ; 0x1000039a0  
   100003308     BL   libSystem.B.dylib::_xpc_transaction_begin     ; 0x1000039ac  
   10000331c     BL   libSystem.B.dylib::_dispatch_mig_server     ; 0x1000038d4  
   100003324     BL   libSystem.B.dylib::_xpc_transaction_end     ; 0x1000039b8  
   10000333c     BL   libSystem.B.dylib::_syslog     ; 0x1000039a0  
   100003350     BL   libSystem.B.dylib::_syslog     ; 0x1000039a0  
   100003418     BL   libSystem.B.dylib::_memchr     ; 0x100003934  
   1000034f8     BL   0x100002bd8  
   100003520     BL   libSystem.B.dylib::_strlen     ; 0x100003994  
   10000356c     BL   libSystem.B.dylib::___stack_chk_fail     ; 0x1000038a4  
   100003600     BL   0x100002f5c  
   1000036c0     BL   0x1000030ec  
   100003748     BLR   X8                      ; 0x100000cfeedfacf  

Note the call to _bootstrap_check_in that we discussed earlier. ARM'ed with this information, if we remove the calls we don't particularly care about like the logging routines etc,  we end up with the following PoC:

// Code inspired by Jonathan Levin 
#include <mach/mach.h>  
 #include <mach/mach_port.h>  
 #include <mach/mach_host.h>  
 #include <mach/host_priv.h>  
 #include <mach/host_special_ports.h>  
 #include <dispatch/dispatch.h>  
 #include <stdio.h>  
 #include <stdlib.h>  
 
#define CHECK_MACH_ERROR(a) do {kern_return_t rr = (a); if ((rr) != KERN_SUCCESS) \  
 { printf("Mach error %x (%s) on line %d of file %s\n", (rr), mach_error_string((rr)), __LINE__, __FILE__); abort(); } } while (0)  
void handler_f (void *arg)  
 {  
   // Just a skeleton....  
   printf("Handle yo biznizz!! \n");  
 }  
 int main(int argc, char **argv)  
 {  
      char *service_name = "com.apple.MobileFileIntegrity";  
      mach_port_t myhost = mach_host_self();  
      mach_port_t jackedAmfi = MACH_PORT_NULL;  
      host_priv_t host_priv;  
      kern_return_t err;  

      err = host_get_host_priv_port(myhost, &host_priv);  
      CHECK_MACH_ERROR(err);  

      err = mach_port_allocate(mach_task_self(), // task acquiring the port right,  
                               MACH_PORT_RIGHT_RECEIVE, // type of right,  
                               &jackedAmfi); // task's name for the port right;  
      
      // insert a send right: we will now have combined receive/send rights  
      err = mach_port_insert_right(mach_task_self(), jackedAmfi, jackedAmfi, MACH_MSG_TYPE_MAKE_SEND);  
      CHECK_MACH_ERROR(err); 
 
      // Bait and switch  
      err = host_set_amfid_port(host_priv, jackedAmfi);  
      CHECK_MACH_ERROR(err); 
 
      // GCD housekeeping  
      dispatch_source_t ms = dispatch_source_create(&_dispatch_source_type_mach_recv,   
         jackedAmfi,   
         0,          
         &_dispatch_main_q);  
      if (!ms) { printf("Error creating mig source"); exit(1); }  
      dispatch_set_context(ms, &ms);   
      dispatch_source_set_event_handler_f (ms, handler_f);  
      dispatch_resume (ms);  
      dispatch_main();  
 }  

It should be noted that the above PoC is incomplete as the handler logic needs to be added. But fear not, we get into this handler later on in the series.

Wrap Up
We have come to the end of part 2 in the series. To recap:
  • We got a HIGH level introduction to Mach IPC
  • Learned a bit about about launchd
  • Introduced the concept of special_ports
  • Determined how the KEXT communicated with it's daemon
  • Saw how special_ports can be usurped
That's all for now. Hope you enjoyed it! And as always if you notice anything that is not correct please don't hesitate to add a comment below...

References:
1. Mac OS X and iOS Internals: To the Apple's Core - For IPC & launchd section
2. MacOS and iOS Internals, Volume III: Security & Insecurity
3. Mac OS X Internals: A Systems Approach
4. *OS Internals - The Forum