Apple's Crypto Battle

On the 16th of February 2016, Apple published a letter to its customers by their CEO Tim Cook. In the much publicised letter, Apple stated that it had taken the decision to oppose an "order" to produce an alternative 'law enforcement' version of the iPhone iOS software which can be used to circumnavigate encryption in the iPhone or facilitate the cracking of encryption within the iPhone (this remains unclear).

This 'order' or possibly a court writ (this is unclear) has stemmed from an investigation by the Federal Bureau of Investigation into the the San Bernardino terrorist attack of the 2nd of December 2015. In this attack 14 people were murdered and 22 seriously injured from a mass shooting and attempted bombing at a local government training event/Christmas party at a San Bernardino conference centre.

Since the release of the first iPhone, Apple has included to varying degrees, some form of encryption in its devices. Since the launch of the A7 processor (iPhone 5s) the iPhone has featured a co-processor known as the "secure enclave". This co-processor is a hardware implementation of various cryptographic functions that the iPhone uses to secure a significant amount (if not all) the user data on the device.

The secure enclave features a dedicated hardware implemented AES 256bit crypto engine with a dedicated path to the NAND mass storage. Each iPhone has a Unique ID (UID) which is "fused" into the co-processor at the time of manufacture. The UID is an AES 256-bit key that is not linked to any other identifier on the device. Apple states that it, nor any third party, stores the UID. Apple also states that it is impossible to retrieve the UID from the co-processor (however it is unclear exactly how this is the case).

The UID is used within the secure enclave to encrypt and decrypt the entire file system of the iPhone on the fly. Implementing this key in hardware means that if the NAND chips are stripped from the logic board it would be impossible to crack the file system encryption (due to the necessity of the co-processor to decrypt it, and its UID). Meaning all decryption must be done on the original device itself.

The actual act of encryption and decryption is achieved through the use of a passcode created on the device. In iOS 9, when the device is first activated, a 6 digit passcode must be created by the user to progress through the set up and to use the device.
The passcode is used in conjunction with the UID and put through a PBKDF2-AES function in the secure enclave which produces a passcode key. This passcode/UID key is actually what is passed when unlocking (decrypting) the device. Also, a time limitation is implemented in the co-processor to prevent rapid brute forcing of the passcode (a user can also activate an option for the file system keys to be wiped if the passcode it entered incorrectly 10 times, making the encrypted data irretrievable).

There appears to be at least 3 points of potential failure trust in relation to Apple's implementation of encryption in iOS devices:

• Trusting Apple and Samsung (the manufacturer) that they are not recording the UIDs of the processors.

• Trusting Apple to adequately verify and sign the firmware of its devices.

• Trusting Apple to produce firmware which does not provide a method of exfiltrating the UID from the co-processor or in some way circumnavigating the passcode/UID key or facilitate brute forcing of the passcode.

Clearly the FBI is pursuing the last of these points to gain access to the iPhone in question. It would appear that either Apple is being 'ordered' to produce firmware which they adequately sign and will run on the co-processor which could reveal the UID of the device (they have stated this is impossible) or in some way could remove the requirement to provide a passcode to decrypt the device (which seems unlikely due to the blending of the passcode and the UID). Therefore it would seem (at least to me) that the only logical option is that the FBI wants Apple to produce firmware which enables brute forcing the passcode (fairly trivial 10^6 maximum possibilities) in a reasonable amount of time.

This should be of concern to every user of an iOS device. The FBI needs Apple to produce this firmware due to the signing of the firmware and co-processor verification of that signature at boot. Apple's argument appears to be that it does not trust the FBI (probably more accurately the American Government and its intelligence services as a whole) with this capability if it were to produce it, as this hypothetical firmware, or a close derivative of it, would likely work on many iOS devices (if not all).

I believe that Apple's resistance to this "order" is not without merit. It is easy to imagine that the FBI could quickly hand over this firmware to other intelligence services.
This could cause many concerns for Apple, one of which could be that multiple governments from around the world could demand similar capability, possibly even some disagreeable governments, with less than a clean track record when it comes to the protection of Human Rights and the freedom of the press.

The result of this on-going dispute will have implications for many iPhone and iOS device users, not to mention the debate over the use of encryption as a whole.


Sources and Further Reading:

David Schuetz, "A (not so) quick primer on iOS encryption". darthnull.org: http://www.darthnull.org/2014/10/06/ios-encryption

Andrey Belenko, Dmitry Sklyarov, "Evolution of iOS Data Protection and iPhone Forensics". BlackHat Abu Dhabi 2011 presentation: 
https://media.blackhat.com/bh-ad-11/Belenko/bh-ad-11-Belenko-iOS_Data_Protection.pdf

Matthew Green, "Why can't Apple decrypt your iPhone?". blog.cryptographyengineering.com:
http://blog.cryptographyengineering.com/2014/10/why-cant-apple-decrypt-your-iphone.html

Apple, "iOS Security". apple.com: 
https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Apple, "A Message to Our Customers". apple.com: 
https://www.apple.com/customer-letter/

Write Up: PRIMER 1.0.1 (chp. 8, 9 + 10)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!

------------------------------------------------------------------------------------------------------

PART 3/CHAPTER 8, 9 + 10: [TERM]

The final part of this VM (as the title suggests) consists of a simulated terminal in the browser. The use of a simulated terminal is actually more of a story telling device rather than a technical challenge. As a result, I will not be explaining how I completed these chapters, instead I'll briefly discuss the story line and what these chapters entail.

Through out this VM the story line has been a central element, this comes to a head and is mostly resolved in these chapters, and its done in what I can only describe as a wonderful way. This resulted in it feeling more like the final act of a movie than a vulnerable VM (complete with end credits)!

The simulated terminal features a few limited *nix commands that are used to cat some log files and see running processes in order to 'gain access' to each "server/AI" (as the story portrays). It requires some lateral thinking, a dash of detective work, a little bit of googling and tests your hacker movie/book knowledge.

To say any more would serve little purpose other than to spoil the experience of anyone that may wish to complete this VM. Which I recommend you do!

Although I am more interested in the technical, it must be said that this VM was great fun and a great experience, such a unique way of telling a story and a great method of involving the audience. The challenges themselves are fairly simple and will not be taxing for any one with a basic skill level. None the less, regardless of skill, I believe most people would enjoy completing this VM.

Many thanks to Arne Rick for making such a wonderful VM and clearly putting in a ton of effort. I look forward to the next instalment!

On to the next VM..

Write Up: PRIMER 1.0.1 (chp. 6 + 7)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!

------------------------------------------------------------------------------------------------------

CHAPTER 6: [++Q++++++]

Chapter 6, much like chapter 5 begins with a javascript window prompt. Immediately I looked at the debugger to analyse the JS.

No hints to be found in the title of the JS prompt. The code, however was more revealing. It was clear that the JS had been obfuscated in some way, however there was some clear text.

"Someone didn't bother reading my carefully prepared memo on commonly-used passwords. Now, then, as I so meticulously pointed out, the four most-used passwords are: love, sex, secret, and... - The Plague"

A reference to the timeless and ever accurate movie "Hackers". The four most common passwords (according to the movie) are love, sex, secret.. " Don't forget god, system operators love to use god, it's that whole male ego thing" as cereal killer says.

Well what a hint! I enter god then GOD and Im through. However thats not much fun. So I had a look at that more interesting obfuscated JS.

So I began by going to jsbeautifier.org to make use of their unpacking and deobfuscating tools. From scan reading the code, I noticed some escaped hex character codes which jsbeautifier can also take care of.

Suddenly all nice and at least readable. Theres still a large amount of obfuscated code, but none the less, allot to work with. The first var is an array of strings. At this point I guessed that the strings in this array are being used throughout the obfuscated code in some way, due to their nature; "location", "addEventListener" "DOMContentLoaded" etc.

I then read through the code, almost 500 lines, but fortunately I could gloss over most of it due to it being mostly garbage. However, at the end I discovered the function Im looking for, the window prompt function.

It appears that this is using the array thats declared on line 1 ( _0x5cf4) is key in this function.

The user input string is hashed using MD5 (on line 474) and then compared to the 9th element of _0x5cf4. If true, the window prompt is removed. 

I then went back to line 1 of the code and looked through the array for the 9th element. There I found the string "0d28cba0bd4f26e16d766000d27e49fa". This looked like an MD5 hash.

From reading the window prompt function, its clear that an un-hashed version of this string needs to be entered for it then to be hashed and compared against the relevant element in the array.

In order to reverse the hash, I navigated to hashkiller.co.uk to make use of their MD5 cracking tool. I entered the hash and got a result:

0d28cba0bd4f26e16d766000d27e49fa MD5 : GOD

This corresponds to the earlier "Hackers" hint, so it must be correct! I entered it into the window prompt and I was through.

CHAPTER 7: [KS(x)<=|(x)+4]

The story continues, the text on this page had some revealing hints. 

"There was a pattern in the path she had taken through the network. An artificial pattern, la[i]d out by someone or something. There was no hint, no obvious step. Finding the next node would be the challenge, or maybe more like a test."

This appeared to me to be hinting at the pattern of the URLs. I looked at the previous URLS, they all appeared to be MD5 hashes as well.

I again navigated to hashkiller.co.uk to crack the hashes. I entered them in the order that I had solved them. The following results were returned;

c81e728d9d4c2f636f067f89cc14862c MD5 : 2
eccbc87e4b5ce2fe28308fd9f2a7baf3 MD5 : 3
e4da3b7fbbce2345d7772b0674a318d5 MD5 : 5
8f14e45fceea167a5a36dedd4bea2543 MD5 : 7
6512bd43d9caa6e02c990b0a82652dca MD5 : 11
c51ce410c124a10e0db5e4b97fc2af39 MD5 : 13
70efdf2ec9b086079795c442636b55fb MD5 : 17

2, 3, 5, 7, 11, 13, 17.

I could immediately disregard the first number as the story also stated "It had been there since the second node".

I began to form a pattern, it quickly became apparent that there was a pattern of offsets between the numbers;

3  (+ 2)  5  (+ 2)  7  (+ 4)  11  (+ 2)  13  (+ 4)  17

2, 2, 4, 2, 4... ?2, 2, 4, 2, 4...?

:- 17 + 2 = 19

The next step was to hash the result.

I then prepended 8_ to the hash to adhere to the URL scheme and entered it into the browser. Success! On to Part 3, the final chapter!...

Write Up: PRIMER 1.0.1 (chp. 4 + 5)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!

------------------------------------------------------------------------------------------------------

CHAPTER 4: [:()[:|:&};:]

In chapter 4 I was met by a continuation of the story, and a link to Chapter 5 (the start of Part 2). EOF.

PART 2/CHAPTER 5: [0xC00007B]

Following the link landed me on a page with a javascript window prompt. No continuation of the story here!

 

So I opened up the browser debugger to inspect the javascript. In doing so I actually saw the hidden HTML on the page which revealed the URL for chapter 6. I ignored it and decided to complete this little JS challenge anyway.

As can be seen from the JS, 

var X is a  user inserted string, var L is some arbitrary string. 

The if conditions are true if the string is null or if a substring (X.substr) of var X is equal to 

var L. 

Considering the 1st if condition (from testing) is not the desired result, it is the 2nd if condition that needs satisfying.

The parameters of X.substr show that the substring is made using the chars from the second char through to, and ending on seven chars along from the second char of the user inputed string var X.

This means that the var X must contain var L "Ikdf076" prepended with two other arbitrary chars. Such as "00Ikdf076". 

The string was submitted and the second if condition was satisfied. The window prompt was then removed and revealed the underlying HTML.

Another URL to chapter 6.. Until the next post.

Write Up: PRIMER 1.0.1 (chp. 3)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!

------------------------------------------------------------------------------------------------------

CHAPTER 3: ["[^"\r\n]*"]

This chapter has probably taught me the biggest lesson so far.. don't get carried away. I have spent hours on this chapter, when in fact, its probably the easiest and most simple chapter yet. Instead of hiding my mistake, there might be some comedy valuable learning opportunities in sharing it.

So from the beginning.. I was greeted again by the now expected block of text and little else. This section of the story seemed to offer some hints to the solution. I fell for it hook line and sinker!

As I read the text, the following line stuck out to me ".. slowly d[i]sintegrating with lightspeed, a thousand years each nano second". This sentence appeared to be the only real candidate for a hint in the text, so I went with it...

I looked at the headers. I noticed that (unlike previous chapters) there were "If-Modified-Since" and "Etag" fields in these headers. Aha! this most be what that sentence was hinting at.. time.. "thousand years" etc.

So I jumped into curl to spoof the "If-Modified-Since" field to generate a response from the server. Sure enough, changing the date of the field to "Sun, 25 oct 2015 12:59:55 GMT" produced a 304 Not modified response, However nothing else, no extra field in the header or anything to indicate I had solved the chapter. I must have been missing something.

So I decided to read up more on properties of the "If-Modified-Since" and "Etag" fields. I began by reading rfc2616 section 14 "Header Field Definitions" for any further information. Although very illuminating, I wasn't any closer to solving the chapter. I did some more searching, read some more papers, I spent the best part of 2 hours trying to prise a hint of a way of exploiting this specific feature of HTTP headers, I came out empty handed.

So out of frustration, I thought I would see what happened if I spoofed a header where the "If-Modified-Since" field was in date; that is to say, a fresh copy of the page would be sent as it had been modified since the date I had fabricated in the request header. Sure enough, I got the HTML back, wait.. what does that say?!..

"<meta http-equiv="hint" content="Think, but don't act like a robot."/>"

Why had I not noticed this earlier?! It cant be! seriously? not robots.txt.. it cant be that straight forward?!

Yes it was that straight forward...

The moral of the story, Don't get carried away. I should have simply read the HTML first, like I had in the previous chapters. But what a valuable lesson to learn! Also, I now know quite allot about ETags and If-Modified-Since header fields!

On to chapter 4, a little bit wiser...

Write Up: PRIMER 1.0.1 (chp. 2)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!

------------------------------------------------------------------------------------------------------

CHAPTER 2: [(α=β)<=>(α<=>β)]

I am progressing through this VM somewhat faster than I originally anticipated, also the chapters are shorter than I imagined, none the less I will continue as intended and post one chapter at a time.

Lets continue.

This chapter, much like the first, features a block of text which continues the vague story littered with small clues.

The most telling of these clues are as follows..

"..needed to penetrate the next circle, blocked of[f] to unauthorized access".

"But she felt a presence of something left behind. Like breadcrums, not intentional, but something forgotten by an incomplete piece of code to handle access".

At this point, my mind first went to cookies... breadcrumbs!

However, more haste, less speed. I first checked the HTML to see if there were any further clues, unfortunately, none to be found there. I then thought to have a quick look at the css and there we have another comment!

This comment confirmed my suspicions. "Clean sessions terminate without leaving things behind..", "Sometimes, an exploit is as simple as changing a simple value in a local file". Yep, definitely cookies!

I then looked at the GET request headers to see what parameters are being passed. There we have it! 

"activeSession=false"

I wonder if it is as simple as changing the active session value to true? Is that all the server is checking for an active session? The clues seem to suggest it.. so I fired up a plugin to edit the cookie and gave it a try.

I found the relevant cookie, altered the value from false to true, saved the now manipulated cookie and reloaded the page.

Sure enough! 302 found, redirect! On to Chapter 3..

Write Up: PRIMER 1.0.1 (chp. 1)

PRIMER is a vulnerable VM developed by Arne Rick featured on Vulnhub. It can be found here.

What follows is a write up of the first of 7 chapters in this VM. I intend to write about each chapter as I complete them. 

So far this VM is thoroughly enjoyable with a wonderful and unique style of story telling. If you intend to complete this VM yourself then this write up will spoil it for you. So I say in bold and caps - SPOILERS!

------------------------------------------------------------------------------------------------------

CHAPTER 1: [__init__]

Once the VM was installed, up and running, I did a quick nmap -sn 192.168.1.*. The -sn flag to skip port scanning, simply to identify which IP the VM had grabbed. This revealed 192.168.127.

Another quick nmap -sV showed ports 22 and 80 running OpenSSH and Apache respectively.

Now I knew a web server was running, I opened up a browser and typed in the IP. A web page dutifully rendered.

 A block of text and a login form. From reading the text, it appears to be a stylistically unusual story. The way it is written is quite vague and loosely tied together. None the less, its enjoyable to read and appears to contain some hints.
The last paragraph appeared to be most relevant..

"There was one spot that attracted her naturally, a point w[h]ere the traces accumulated and forward a connection, a terminal accepting input from the us3rland, a f0rm. This one was of a family very well known to her, easily exploited to grand you access to another level, and that was she needed for now. Reaching in she began to twist the stream, adjust the flow and after a few practiced moves, she felt it, access, the meta, finally moving on."

This is clearly hinting at the login form, requiring some SQL injection. The story itself indicates that this may not be too difficult -".. a few practiced moves..".

To check for any further hints, I inspected the HTML which revealed some hidden text.

This revealed; "Some f0rms are easier than others. This one was just a means to get to the next level so there was no need for her to apply her full set of skills or fake credentials. Manufacturing a boole4n response would probably be en[o]ugh to let her pass."

This reaffirmed my suspicions that this required a simple SQL injection. Clearly just a boolean response was required for this function.

I began with some well established code which would evaluate to TRUE. I only used the Username field, leaving password empty. It was clear from the first attempt that all errors from the SQL server were being caught, there were no prompts or notifications for failed attempts. This meant there was nothing else to go on other than what was provided in the story, effectively educated guesses. I continued and tried a multitude of variations, such as ' OR '1'='1' , ' OR 1=1 -- , 1" OR 1=1 -- etc. Eventually, after a significant amount of attempts ' OR '1'='1' -- was successful. The first ' closes out the single apostrophe encapsulating the variable, OR provides the ability to negate the first statement requirement to evaluate to TRUE. '1'='1' clearly computes to TRUE and the -- (with an important space after it!) then comments out the rest of the query, therefore making the password field redundant.

Once login was pressed, I arrived at the next page. This again included a block of text.

This portion of the story continued the vagueness from the first page. However there were a few notable parts; "..specific string all users transmit.." , "Drifting around the 7th circle of security layers.." , "..this little script just checked for an identifier, a hash, no credentials or secrets..". These hinted at the User Agent Identifier. I then checked the HTML source code for any further hints.

I found a comment! This one reads:

"This bot was looking for a Sosu User Agent Identifier she had cracked weeks ago, easy sauce, just a simple md5 hash of the first 7 digits of pi. It was basically common knowledge to the entities moving in these areas but obscurity does create a, albeit virtual, layer of security".

This clearly indicates that I need to spoof the User Agent Identifier to solve this page. First of all, I need to make the MD5 Hash of 3.141592. md5sum in the terminal produced the required hash:

d483d00d07fcc80319d170ccf07fb5be.

Next I installed a User Agent Switcher ad-on in firefox. I then created a new User Agent profile and input the hash in the user agent field.

I then switched to the new User Agent Profile and reloaded the page - Redirect. It worked! on to the next chapter! ..Coming soon.