iOS Solid State NAND Storage

There is not much literature available on how does NAND storage of Apple’s iDevices is like. While reading “Hacking and Securing iOS Applications” by Jonathan Zdziarski, I came across how does the NAND storage looks like until iOS 5. As a note on caution, it is very possible that this structure has been changed in the subsequent iOS versions.

Knowing the structure of storage is an important step in order to understand how encryption works in iOS. The text below is verbatim from the book.
The NAND is divided into six separate slices:

  • BOOT: Block zero is referred to as the BOOT block of the NAND, and contains a copy of Apple’s low level boot loader.
  • PLOG: Block 1 is referred to as effaceable storage, and is designed as a storage locker for encryption keys and other data that needs to be quickly wiped or updated. The PLOG is where three very important keys are stored, which you’ll learn about in this chapter: the BAGI, Dkey, and EMF! keys. This is also where a security epoch is stored, which caused iOS 4 firmware to seemingly brick devices if the owner
    attempted a downgrade of the firmware.
  • NVM: Blocks 2–7 are used to store the NVRAM parameters set for the device.
  • FIRM: Blocks 8–15 store the device’s firmware, including iBoot (Apple’s second stage boot loader), the device tree, and logos.
  • FSYS: Blocks 16–4084 (and higher, depending on the capacity of the device) are used for the filesystem itself. This is the filesystem portion of NAND, where the operating system and data are stored. The filesystem for both partitions is stored here.
  • RSRV: The last 15 blocks of the NAND are reserved.

If there is any recent material on this topic, please let me know by commenting below.

Keep Hacking 😀

RC4 must die

Rivest Cipher 4 (RC4) is one of the most popular stream cipher and as per ICSI Certificate Notary project statistics, RC4 encrypted communication comprises of about 30 percent of SSL/TLS communication. In past few months, couple of attacks, or enhancement of previous known attacks against this widely used algorithm have been proposed and thus making future use of RC4 perilous and hopefully bringing curtains to 28 years of successful existence.

Before getting into the details of the attacks, firstly let us revisit what SSL/TLS is. Secure Socket Layer (SSL, a.k.a Transport Layer Security (TLS)), is the most widely used secure communication protocol on the Internet today. SSL/TLS is presently used for protecting various application level traffic, like in HTTPS to encrypt web browsing traffic, in IMAP and SMTP to cryptographically protect email traffic, to name a few. It is also extensively used with embedded systems, mobile devices, in point of sale payment devices etc. To learn more about SSL/TLS, please read my previous post.

An SSL session, to explain briefly, consists of two phases: SSL Handshaking Protocol and Record Protocol. The former consists of a client authenticating itself to the server and both establishing a cryptographic session keys, which will be used for protecting further communication. While, the latter phase comprises of using the established session key and symmetric key cryptography to build a secure channel of communication for application-layer data. The symmetric key cryptography algorithms come in two flavors based on their underlying design:

– Block Ciphers (CBC mode of operation, e.g: AES)
– Stream ciphers (e.g: RC4)

In the recent past, SSL/TLS has been in the limelight for various security flaws of varying severity  and discussed over here. Broadly, the flaws were either algorithmic weakness or implementation weakness. Heartbleed and OpenSSL CCS occurred because of improper implementation in OpenSSL library, a widely used SSL/TLS library. In contrast, POODLE involved algorithmic weakness. Implementation based security vulnerabilities are relatively easy to fix, as it involves patching the vulnerable part of the code, but vulnerabilities arising because of shortcomings in algorithm design requires change of components which are  vulnerable.

The two attacks are based on the inherent design flaws of RC4 and discussed below.

The first attack [1] is based on the fact that some of the pseudo-random bytes in RC4 used to encode messages are predictable. In 2013 researchers demonstrated that this lack of randomness can be exploited by seeing more than 17 billion (234) separate encryptions of the same data. At the time, this was considered to be impractical attack. Now researchers have further refined the attack and claim that now it takes a tad more than 67 million (226) encryptions of same data to recover the underlying plaintext with 50 percent success rate. It is successfully demonstrated that the enhanced attack can extract security tokens from both basic access authentication over HTTPS and IMAP protocol, used for retrieving and storing e-mail.

The second attack [2], dubbed “bar-mitzvah” attack, given the age of “invariance weakness” on which the attack is based. The attack is devised by researchers at Imperva, a security firm and was presented at Black Hat security conference in Singapore. “Invariance weakness” in RC4 was responsible for fatal exploits against Wired Equivalent Privacy (WEP) technology used to encrypt Wi-Fi networks in 2001. “Bar-mitzvah” attack requires sampling of one billion RC4 encryption to decrypt credit card number, password, or authentication cookie key. Though this attack has a very limited scope, as it is restricted to first 100 bytes of ciphertext generated by RC4. In spite of the limitation, it is significantly faster than performing exhaustive attack that guesses passwords, credit card numbers etc and thus should be considered a practical threat.

Historically, block ciphers also did not have a good past. AES-CBC has seen significant cryptanalysis attacks like BEAST, Lucky 13, POODLE to name a few. These attacks were based on design shortcomings of the algorithm. After series of attacks against block ciphers, RC4 (stream ciphers) was proposed as the recommended work around the attacks. Which also justifies the presence of huge chunk of RC4 encrypted traffic on the Internet. And now two new proposed attacks on RC4, pushes it towards the cliff.

Many argue that the above attacks against RC4 may not be easy to execute practically, but if anything is to be learned from BEAST, Lucky 13 and POODLE, is that – attacks only get better. FREAK vulnerability is a perfect example of implications of using old and archaic standards beyond a certain threshold may come back and bite us really hard. To further strengthen the case against the use RC4, as per RFC 7456 [4], use of RC4 with any TLS version is prohibited.

Various browser vendors are working on doing away with support of RC4 in their browsers  [7]. Mozilla Firefox [5] will stop supporting RC4 in Firefox 44 (expected in Jan 2016), while Google’s Chrome [6] and Microsoft’s Edge [8] browser will stop support by Feb 2016.

REFERENCES:
[1] http://www.isg.rhul.ac.uk/tls/RC4passwords.pdf
[2] https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-attack-breaking-ssl-with-13-year-old-rc4-weakness
[3] http://arstechnica.com/security/2015/03/noose-around-internets-tls-system-tightens-with-2-new-decryption-attacks/
[4] https://tools.ietf.org/html/rfc7465
[5] https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/
[6] https://googleonlinesecurity.blogspot.in/2015/09/disabling-sslv3-and-rc4.html
[7] http://www.infoworld.com/article/2979527/security/google-mozilla-microsoft-browsers-dump-rc4-encryption.html
[8] https://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11/

Detecting Microsoft HTTP.sys vulnerability

On April 14th, 2015 patch Tuesday, Microsoft released a patch for a remote code execution vulnerability in HTTP.sys module of Windows. The vulnerability affected all versions of windows, ranging from Windows 7 to Windows servers. Microsoft’s bulletin MS15-034 talked about the vulnerability only in brief and left the details to be revealed only by reverse engg the patch. It was a race against time for people to patch their servers and for attackers to reverse engineer the patch to zero-down on the exact vulnerability. The vulnerability was assigned CVE-2015-1635. In this blog we will see what is HTTP.sys is and how to detect the vulnerability. Understandably the fix was to apply Microsoft’s patch.

What is HTTP.sys?

HTTP.sys is a kernel-module which is a HTTP listener. Prior to HTTP.sys, windows used Windows Socket API (Winsock), a user-mode component, to receive HTTP requests. Having HTTP listener in kernel have following advantages [1]:

  • Kernel-mode caching: Requests for cached responses are served without switching to user mode.
  • Kernel-mode request queuing: Requests cause less overhead in context switching because the kernel forwards requests directly to the correct worker process. If no worker process is available to accept a request, the kernel-mode request queue holds the request until a worker process picks it up.

For more details on working and advantages of HTTP.sys, visit [2].

Vulnerability

The vulnerability exists in the parsing of the Range Header [3] of the HTTP request sent to the server. By sending Range header’s value as bytes=0-18446744073709551615, triggers a buffer overflow and this can be used as a test to detect HTTP.sys vulnerability on a server.

Following curl command can be used for testing:

$ curl -v www.example.com -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615"

If response is “HTTP Error 400. The request has an invalid header name.”, then the server is patched, any other response apart from this indicate the server is still vulnerable.

Sending following request will cause Blue Screen of Death (BSoD) and thus causing Denial-of-Service.

$ curl -v www.example.com/iis-85.png -H "Host: irrelevant" -H "Range: bytes=20-18446744073709551615"

As per comments on Hacker News [4], the vulnerability affects only those server on which “Output Cache” or “Enable Kernal Caching” is checked.

There is ready to use tool available on Github for testing your server for HTTP.sys vulnerability.

This attack is similar to Range-attack on Apache servers, causing Denial of service [5].

Keep Hacking :D.

REFERENCES:
[1] https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a2a45c42-38bc-464c-a097-d7a202092a54.mspx?mfr=true
[2] http://www.codeproject.com/Articles/437733/Demystify-http-sys-with-HttpSysManager
[3] https://tools.ietf.org/html/rfc7233#section-3.1
[4] https://news.ycombinator.com/item?id=9380889
[5] http://seclists.org/fulldisclosure/2011/Aug/175
[6] https://security.stackexchange.com/questions/86201/does-http-sys-vulnerability-affect-windows-not-running-any-webservers
[7] https://isc.sans.edu/forums/diary/MS15034+HTTPsys+IIS+DoS+And+Possible+Remote+Code+Execution+PATCH+NOW/19583/
[8] https://www.reddit.com/r/netsec/comments/32n3m2/cve20151635_rce_in_windows_httpsys/
[9] https://stackoverflow.com/questions/22598350/how-exactly-does-http-sys-work

How Cuckoo Filter Can Improve Existing Approximate Matching Techniques

If you have used VirusTotal, in additional information tab you will find a field for ssdeep. It is intriguing what this field represents among hashing functions SHA1, SHA256 and MD5. ssdeep is a approximate matching algorithm (AMA). NIST define approximate matching algorithms as ” Approximate matching is a technique for identifying similarities between or among digital objects, such as files, storage media, or network streams, which do not match exactly”. In simple words, given two files, having certain degree of similarity, for example, two word files with second file being copy of first except a paragraph. Traditional hash functions can only tell about the exact similarity, but cannot provide degree or a confidence score out of 100 of how similar the files are.

AMA are used extensively in forensics investigation as they provide easy way to compare a hard disk against whitelisted or blacklisted corpus of files. Over past few years many AMA have been proposed. ssdeep was the first, followed by sdhash and mrsh-v2. In between, some other algorithms were also proposed, but they suffered with one shortcoming or other. All of the above algorithms use Bloom filters as their basic building block. In short, Bloom filter is a probabilistic data structure for performing set membership query efficiently. In this post I will not go into details of internal working of  AMA nor of Bloom filter, but talk about an alternative of Bloom filter, namely Cuckoo filter.  Cuckoo filter is modification of Cuckoo hashing approach to construct a data structure suitable for set membership determination. Cuckoo filter excel over Bloom filter on following parameters:

  • Cuckoo filter has better lookup performance
  • Cuckoo filter has better space efficiency than Bloom filter, when false positive rate desired is < 3%.
  • Unlike Bloom filter, Cuckoo filter supports deleting stored items dynamically.

In one of my recent works, I have used Cuckoo filter instead of Bloom filter in mrsh-v2 and was able to achieve significant performance gain. The final results can be summarized as:

  • In simple runtime performance, there is a gain of 37%.
  • Size of final fingerprints generated is halved.
  • Memory usage is 8th of approach with Bloom filter.

This work was presented at ICDF2C-2015, which took place on 6th October in Seoul, South Korea, titled How Cuckoo Filter Can Improve Existing Approximate Matching Techniques (pdf). The work was adjudged with best paper award by the committee.

In next coming posts I will try to cover what are approximate matching algorithms in detail and probably also look into each of these algorithms.

Keep hacking!!