Tag Archives: forensic

The world of Computer Forensics

I have recently attended a SANS Forensic course in London. It was the best training course I have ever been to, not only the content was really interesting and very well delivered but all the extra activities surrounding the training course were outstanding (presentations, challenges, social events, etc).

Forensic was new to me and I found the techniques taught as very good eye openers in two different ways:

– Forensic techniques can be applied to other area of IT security than just forensic investigations, such as malware analysis and DLP. The latter was a bit of a surprise to me, but by understanding some of the forensic techniques you can also understand how part of a DLP engine would work when searching for specific files on filesystems (at rest) and recognised/tagged when on the network (on the move). I will find it interesting to see if my new knowledge of forensic can come handy with any DLP work I do.

– It is impressive how much information can be salvaged from any devices you use. My key takeaway was about how secure delete applications may not prevent access to the deleted data as much as first thought. It indeed depends of the data lifecycle, if it was cached at some point, if the OS fragmentation management moved/duplicated some of it allocated data blocks, etc.

Although I am not specifically working on Forensic at the moment, this is an area of new interest which I hope to keep practicing and integrate with some of the work I do.

Below is a nice general overview on computer forensics:
Techrepublic
And a very good Open Source website on that topic:
http://www2.opensourceforensics.org/home

New iOS Security attack, this time it looks bad!

Another attack on the iOS security has been published today and there are two recurring themes to the attacks I described in previous posts, namely: weaknesses with the Keychain and iOS encryption implementation.

But this time they have been used differently and seem to provide an attacker access to any passwords stored on an iOS device, even if it is passcode protected.
One main difference in this attack, is that the attacker would only requires the iOS devices and nothing else (as opposed to the relevant synced PC with previous attacks).

It also seems to prove Zdiarski’s concerns over the iOS encryption controls to be true.
The attack used some jailbreaking techniques to access the iOS device boot/ram, bypassing the passcode and using the OS to run a script to access the local keychain and all the passwords it may contain (email, VPN, web apps, etc)
It seems that the encrypted data is not linked to the user passcode, which means that if someone can bypass the passcode, even if the data is in theory still encrypted, the attacker uses the iOS device itself to decrypt the data for him!

When I said it was “bad, but not that bad”. Now, it may be THAT bad! ;)

All the details, video and whitepaper, are available here:
Fraunhofer Institute

Follow-up on Apple iOS Full Disk Encryption

Regarding my previous post I wanted to mitigate some of the risks I was describing.
In a nutshell, it is bad, but not that bad! :)

Escrow keybag
There is indeed a forensic issue with the escrow keybag feature, but because it requires the attacker to have both the targeted mobile device and the computer used to sync it with, That attacker would first need to break the computer’s security to access its filesystem.

Because that computer is used to sync the mobile device, most of the information it contains is likely to be on the computer as well.
For example, email accounts are likely to have been setup both on the computer and the mobile device, office files are likely to have been created on the computer, etc.

Therefore gaining access to the computer’s filesystem is likely to already give you access to most of the mobile device’s data.
Having said that, there is no garantee it will always be the case and some information such as call history, text messages, internet history, etc would only be available on the mobile device (and its hopefully encrypted backup).

The point is that although the Escrow Keybag can indeed be used to bypass a mobile device protection and is therefore a security risk, it should be put into context with the security risks related to successfully gaining access to it in the first place.
In other words, it is bad, but not that bad!

Full Disk Encryption
The statement that I reproduced about the level of security offered by the iOS full disk encryption control should also be put into a wider context.
Jonathan Zdiarski claims it was inadequate because it automatically decrypts data once requested for it, the way I undertand it is that its level of security is therefore dependant of the strengh of the passcode used and of the device’s OS security (sandbox, access control, etc).

But this is also true for any full disk encryption control, on any plateform.
If you gain knowledge or access to the passcode you can then access the data.
And if you get a malware running on your full disk encrypted device, it would not be prevented to access any data associated with your credentials.

I therefore do not believe this is an Apple specific security risk.
In other words, it is bad, but not that bad!

Apple and their elusive Full Disk Encryption solution

I have been researching how Apple has been implementing their full disk encryption control over the weekend and what I found puzzled me:

Although technically Apple provides a hardware full disk encryption solution, from a traditional security sense of the term, there is no full disk encryption available on the iPhone/Ipad currently! It sounds like a paradox? let me explain…

The closest analogy I can think of, would be if someone was selling you a house and claiming that the full house was protected with alarms in each room. The only problem, is that the alarm would only work when nobody was in the house… meaning the only protection your house effectively had was a simple front door key.

The following information can be found in the following article:
iPhone full disk encryption seems to have been implemented with one purpose in mind: fast/instantaneous remote wipe as it just erase the 256-bits encryption key.
Jonathan Zdiarski found that “the iPhone OS automatically decrypts data when a request for data is made, effectively making the encryption worthless for protecting data”
This is where the new iOs4.x “data protection” security feature comes into play, it allows for an app to derive a key from the user’s passcode/password and encrypt the app’s data. But so far it is only done by the built-in email app. APIs are available but each apps needs to use them if they want their data encrypted.
From the article referenced at the beginning of this post, I found the following two characteristics of that API the most interesting::
- Positive: There is a protection against brute force attack as an attacker can only guess about 20 passwords per second due to how keys are generated (which compares well to other software such as encrypted PGP files where 900 passwords can be guessed per second.)
- Negative: There is however a security weakness called the “Escrow Keybag, which is a collection of keys necessary to decrypt every file on the device without requiring the user’s password. This was done to allow computers to sync with the iPhone without asking the user for the password”. A company called ELCOMSOFT may be using this weakness in their iphone password recovery solution
The last point is of forensic significance. If both the iOS device and the computer used to sync it with are either seized or stolen then it is possible to find the plist/lockdown files on the computer and bypass the passcode used on the iOS device and dump all its data for analysis, unencrypted.
This is true for the latest iphones (3GS and 4G) with the latest firmware. For older model/versions there are other easier techniques to obtain the data.
Windows 7 is not better though:
Their might be some lights for Android based phone with the Motorola enterprise offering: http://www.networkworld.com/news/2010/100710-droid-pro-enterprise.html
The link below needs to be read with a warning as I don’t really agree with the author’s message that sounds as if all those phones are very secure and enterprise ready. They can be, but companies need to be aware of the limitations of the security controls that have been implemented. He still provides a good overview of each type of mobile phone capabilities (page 3) hence why I am providing the link:
Finally, those guys have a nice white paper on iphone forensics which was updated recently in November 2010:
VIAFORENSICS

Full Disk Encryption Attacks

Although 3 years old, this is a good article and a link to a paper about coldboot attack against full disk encryption technology.

In a nutshell, it is related to data not being encrypted when stored in RAM and although it is volatile: “from 2.5 to 35 seconds to reach a Null State” when switched off, it can be recovered with a few techniques such as dropping the RAM temperature to slow down that “null state” or booting up the device through a very small kernel OS so only a small portion of the RAM is over written through a USB device for example.

What makes this attack even more powerful is that a lot of information “derived from the encryption keys” are stored in RAM, usually to speedup calculations.
The author then warn those attacks would be very difficult to prevent without a radical change in hardware architecture or “overhaul of the encryption process itself”.

Arstechnica ARTICLE