Due to “popular demand” and given Marc couldn’t join us at the IPv6 Security Summit (as flights into FRA were canceled that day due to snow) we decided to invite him and Antonios Atlasis another time, to present their knowledge, skills & voodoo in two workshops held in Heidelberg, in late June. More details can be found here.

See you all potentially at the Heise IPv6 Kongress, take care

Enno

Hi,

on the [ipv6-ops] mailing list currently there’s some discussion about RA guard support on switches from different vendors.

Stefan, one of our students (btw: working on a topic similar to this session), quickly put together a preliminary list, based on publicly available information (read: the WWW ). Some of you may find this useful; it can be found here. Furthermore on the list this link was mentioned which seems to provide some info as well (albeit potentially not very up-to-date).

If anyone of you has better/more information pls feel free to share by leaving a comment. The IPv6 security comment will thank you for that

Best

Enno

Hi,

just to let you know that all presentations from this year’s TelcoSecDay are published in the interim. (Harald [Welte] couldn’t participate as in the morning of that day FRA airport was closed on short notice).

Next year’s TSD will happen on 03/18/2014.

Take care,

Enno

After being on the market for a few months now, Microsoft started quite a large advertising campaign in Germany for its new Surface RT . We had a comprehensive look at the new tablet PC and here are a few thoughts and impressions:

Running a slightly reduced ARM version of Windows 8, I heard somebody calling it “Windows 8 Home”, which in comparison to older versions hits the spot, Microsoft offers an easily usable interface. Software is reduced to market apps (the minimal run level on a plain Windows is 0, any, and 8, Microsoft, on Windows RT), so you can’t just install your favourite app, or can you?


A first, simple to use jailbreak was published in January [1], lowering the minimal run level, so you can run what you want, as long as it’s compiled for ARM systems. This does at least let you run various Open Source applications, even though you need to jailbreak after every reboot (simply run a batch file, give it admin, press volume down). But at what price? Microsoft says the jailbreak does not have a significant security impact, as it needs administrative privileges to run.
The whole security concept is based on the fact, that the Surface will only run apps from the market store, which are checked and then signed by MS. If it’s malicious software, it won’t be offered in the store. But if it does? Let’s just assume MS to have security measures in place, just as Apple and Google have in their app stores.

Knowing this, any app that can run on the Surface is trustworthy, so why not give it admin? Surely, this would be a rather targeted attack, but still possible. So the easy solution: Don’t run any software, except for market software!

The Surface offers on-board encryption using “drive encryption”, which actually is a light version of BitLocker and can use the on-board TPM 2.0. Now usually one would have written “TPM 2.0 chip” but in this case it’s kind of an emulated TPM chip, running in Kal-El’s (NVIDIA’s codename for the used Tegra 3 chip) secure “TrustZone”. Ongoing research will show if the emulated solution was a good idea or not.
Looking at the BitLocker section in the Control Panel reveals a little surprise: there’re no options for enabling or disabling any encryption. Giving it some time and resetting the device several times (which took about 30minutes for each reset) brought some further insight.

• one local user, having admin rights -> no encryption

• one local user(admin) and one user using a MS account (no admin) -> no encryption

• one user using a MS account (admin) -> encryption

• one local user and one user using a MS account (admin) -> encryption

When having two users, the users where created in the listed order.
So if you want/need encryption in place, you ought to use a MS account, which needs to have administrative privileges.
Having a deeper look at this, some more findings appeared:

• If you add your MS Account to the device it will autocratically backup your drive’s key into your Skydrive. (You can actually delete it from there afterwards, but keep a copy in a safe place)

• If it’s your first device on the MS Account, it will be added to your trusted devices (ie can be used to recover your account’s password).

• You might get a confirmation eMail and/or Text/SMS prompting you to confirm the the new device. The text I received, just said “confirm device”, my eMail said “confirm adding the device to trusted devices”.

• When you remove your MS Account from the device, the key remains in your Skydrive (you might want to keep this one in mind).

So BitLocker, or rather “Device Encryption”, which only encrypts your main disk and no USB Sticks or inserted SD cards, works out of the box! Just remember to use a MS account, with administrative privileges.

By the way, I’ll just add one random fact: To enable logging in with your MS Account when the Surface is offline, the account’s password is stored in the local SAM.
Which results in an interesting attack scenario:
Let’s assume you find a Surface with a local account (including administrative privileges) and a MS account without having admin privs. Given that, the device does not have crypto and the MS account’s password is in the local SAM! This would result in an offline attack (like a “simple” bruteforce) against the used MS account. And well, when the device is also trusted….
One nice new feature is the so called “picture password”. Choose a picture, draw three gestures (klick, straight line, circle) and save these. When you want to log in, you’ll see the picture and can start “drawing” your gestures in the correct order. The algorithm behind it does actually seem to be rather fussy, so you will need to be quite accurate.

So for now, the Surface seems to be quite a nice device, if used just as carefully as any other mobile device… When you’ll get yours, best invest the time necessary to do a complete reset, use your MS account when setting it up  and be careful on who to give administrative privileges…

stay tuned for more!

So long,
Brian

[1]  http://forum.xda-developers.com/showthread.php?t=2092158

Just a quick update here: Ivan (who gave the magnificent Virtual Firewalls talk at Troopers recently) blogged about this and some guy added some feedback from an environment with Cisco FEX and “one of the server guys start[ing] a Citrix Netscaler” . See the second comment to his post.

This shows, once more, that the dependencies of various technologies (and what they are used for) must be well understood in cloud/virtualized environments. Complexity … but who do we tell. Y’ all know that, right?

best

Enno

This is a short summary of some selected talks from the second day of this year’s Hack in the Box conference in Amsterdam.

 
Rethinking the Front Lines by Bob Lord

Bob Lord is currently the Director of Information Security at Twitter. He has worked at numerous companies in the area of security and software engineering.

In his keynote for the second day of HITB13AMS he tackled a topic that has raised a lot of discussions in the past months. His talk was a summary of what twitter does internally to ensure the security of the company and a plea to implement so called security awareness trainings for employees in a sustainable way.

Bob points out that the security folks seem to loose focus on elementary problems such as password policies. Security professionals should focus more on humans than tools. Having said that he concludes that a sustainable security awareness can only be achieved by considering habits of people and the culture of an organization. Twitter’s approach is not to just only teach employees on how to comply with internal standards, they also introduced sensitization measures that get constantly monitored. He states that training alone cannot do the job, security must be in the philosophy or the culture of the employees.

By presenting multiple statistics that are based on measurements that start when a new employee comes to twitter, he substantiates his assumptions that it is not the training alone that matters, but how that training integrates into the organization’s culture and that this culture must include security as a high priority. He introduces the term “auto-pilot mode”, in which humans do not think about what they are doing. Bob believes that this is what a good security training must achieve: To not only create awareness but sort of patch the auto-pilot mode of the employees.

Twitter tries to achieve this with initial trainings for new employees. These trainings include for example the correct usage of password vaults to eliminate some of the risks associated with passwords. They even implement phishing tests, where an internal phishing attack is conducted to sensitize employees. Bob says that gamification might be an additional way to improve the compliance with the internal security standards.

The results of these measures are fed back into the process, so that a constant improvement of the measures is achieved.

The numbers Bob presented seem to substantiate the assumption that security awareness trainings have an effect and that these trainings don’t necessarily mean that we are going in a wrong direction here.

As twitter is a company with a very strong culture, these measures might work better than in companies that do not have this kind of philosophy. It would be nice to have some numbers from organizations that do not pursue such a strong philosophy. It seems that we need more data to identify what really works and why.

 
How I Met Your Modem by Peter Geissler and Steven Ketelaar

In this talk, Peter (better known as blasty) and Steven presented their research on exploiting and backdooring a ZyXEL DSL modem. They first described a really trivial command injection vulnerability (“; whoami”) in the local management web interface (The 90′s called, they want their bugs back!) and used the resulting shell access to completely compromise the modem OS. Unfortunately, this vulnerability requires valid credentials and the web interface is only reachable via LAN, so they started searching for vulnerabilities that can be exploited remotely from the Internet.

The tested ZyXEL device includes support for remote management functionality (TR-069) and has a HTTP daemon listening on Port 7676 on all interfaces. Most of the aformentioned management functionality is protected by a device-dependent HTTP digest authentification, but by analyzing the httpd binary they discovered several unprotected URLs that correspond to test functionality of the underlying HTTP server library (librompager). These test pages contain a trivial stack based buffer overflow that can be exploited to gain code execution on the device.

Steven and Peter described how they first built a MIPS debugging environment using the buildroot toolkit (http://buildroot.uclibc.org/) and used this to develop a stable stack overflow exploit against the ZyXEL device. While overwriting the instruction pointer was trivial, the targetted MIPS system has a separate instruction and data cache, which means that a direct jump to shellcode stored on the stack is not possible. Instead, they used a really clever ROP chain to call sleep() to sync the CPU cache, before jumping to the injected shellcode. They responsibly disclosed the bug to KPN a big dutch internet provider and they even sent some people to gift a “I hacked KPN and all I got was this lousy tshirt” to both of them.

Afterwards, Peter and Steven finished their presentation with a cool live demo showing a VOIP sniffer running on the modem. In my opinion this talk was one of the best of the conference and the demo was quite cool. The embedded HTTP server rompager would probably be a nice target for further research, especially because it seems to be widely used by many different devices.

 
To Watch or Be Watched: Turning Your Surveillance Camera Against You by Sergey Sheykan and Artem Harutyunyan

The researchers Sergey Sheykan and Artem Harutyunyan (@sshekyan, @hartem) both developers at Qualsys, presented their work about low cost WebCam surveillance cameras. They showed how to turn your security camera against you by exploiting a flaw in the Security Web Cam (FOSCAM F18910W) that runs an ucLinux Kernel. This camera is a cheap (70 €) surveillance tool that is relatively wide spread. They searched for these cameras in the wild using the ShodanHQ search engine and found that 2 out of 10 cameras were accessible with the default admin credentials. They also identified a firmware version that is vulnerable to path traversal which allows an attacker to bypass authentication.

During their research the developers managed to dump the camera´s memory by accessing a special URL like http://cameraurl//proc/kcore. The memorydump found there also contains valid credentials along with other valuable information like connected network devices communicating via UPnP (great for “passive” recon). In their demo the researches altered several things on the camera. First they created a backdoor and added a user on the camera for permanent access. It is also possible to send a CSRF-Token to a victim, adding an administrative account to the camera. Furthermore they were able to use the camera as a Proxy for surfing the internet.

Additionally attackers can dump, edit and push the cameras firmware leaving them with a lot of surface for advanced manipulation that might be used for botnets. Another interesting fact is that the camera vendors are offering a DynDNS service to access the cameras. So if one is looking for a target he only has to choose one of the 140.000 from *.foscam.org or many more from other vendors. There is also a DoS condition if the camera is accessed by 80 concurrent connections that could be mitigated using a software like fail2ban.

The researches created a toolkit for educational purposes which can be downloaded at http://openipcam.com. They made some recommendations regarding the cam including not to expose the camera to the internet, if you have to, you better have some good Firewall and/or IPS rules in place respectively isolate it from the rest of your network.

It was an interesting talk that once more showed how careless users setup new hardware without changing the default credentials and exposing it to the internet. So next time you setup a WebCam better think twice who can access it!

This is a short summary of some selected talks from the first day of this year’s Hack in the Box conference in Amsterdam.

 
Abusing Twitter’s API and OAuth Implementation by Nicolas Seriot

Nicolas Seriot (https://twitter.com/nst021) is an iOS Cocoa developer with an interest in privacy and security. He is currently a mobile applications developer and project manager in Switzerland. Nicolas focused his talk on the extraction of consumer tokens that are needed for OAuth to authenticate a consumer to a service provider. These tokens can then be used by rogue applications to gain access to a victims twitter account.

During his talk he extracted the consumer tokens from popular twitter clients under OSX by using classic binary analysis methods. He started off by dumping hardcoded tokens contained in the binary by using “strings”. After that he demonstrated dynamic approaches by using a debugger and finding the consumer tokens in different places of the binary. His approach included dumping the return values of functions, dumping deallocated pointers, dumping the whole process memory and even searching for valid consumer keys on google. Nicolas then presented a tool that can use valid consumer tokens to impersonate any official twitter application using OAuth.

He concluded his talk by pointing out the implications of bringing OAuth from the web to the desktop. Among the biggest problems seems to be the possibility to attack users by impersonating legit consumer applications during the authentication process. It is possible to trick a user into thinking he is authorizing a legit twitter app. Because of the possibility to supply an arbitrary callback URL, the access tokens to authenticate the consumer are redirected to a server under the attacker’s control. These access tokens can then be used to make requests on behalf of the user.

The talk did not include any attacks on the OAuth protocol used by twitter. It rather pointed out the importance to keep consumer tokens private and that usage outside of the web will raise the attack surface when using OAuth.

 
Orchestrating a Fire Sale: Bringing Dutch Alarm Systems to Their Knees by Wilco Baan Hofman

Wilco Baan Hofman, reverse engineer who is working for Nikhef (http://www.nikhef.nl/), talked about the signaling message security of dutch alarming systems. He mainly focused on SIA-HS (or SIA “highly secure”), a proprietary protocol by Alphatronics which is, according to the product catalog,  impossible to decipher. After a short summary of ridiculous assumptions made by Alphatronics and some basic alarm dialer information, Wilco moved directly to the encryption of SIA-HS. It turns out that the “impossible to decipher”-cipher is just a XOR with a 1-Byte key. This key also can’t vary in a wide range because it’s stored in a lookup table within the firmware. Not as much magic as one might expect, as the protocol itself contains a lot of zero-bytes according to some screen shots presented at the talk.

Wilco implemented full SIA-HS and Vebon SecIP functionality of an Alarm Receiving Center (ARC) which can be downloaded from github (https://github.com/bitlair/siahsd). SIA-HS provides nearly no security feature that would be mandatory for a secure protocol. There is no identity- or session-authentication which makes it easy for an attacker to disturb the whole system by e.g. spamming the ARC with false alarms. Because the source IP of the UDP packets is easy to spoof, one could send alarms for every of the ARC’s customers. Wilco also talked about the Vebon SecIP protocol, which uses 1024 bit RSA crypto to exchange a 128 bit AES session key. Even though this sounds pretty nice, this protocol also doesn’t any kind of identity  verifications.

Responsible disclosure attempts failed in the first, but then Vebon and Chrion (two providers of dutch alarming systems) started to act and support Wilco. Chrion even offered a properly configured ARC to aid testing, which is really awesome. Alphatronics only reaction was to ask Wilco to take down the publication. Countermeasures to mitigate the risks are very limited, so customers have to just wait for firmware updates and providers should isolate customers on insecure protocols.

 
Exploiting Hardcore Pool Corruptions in Microsoft Windows Kernel – Nikita Tarakanow

Nikita aka “The Crazy Wild Russian” (https://twitter.com/NTarakanov) started his talk with a recap of the rising importance of local kernel vulnerabilities in the Windows kernel. Due to sandbox implementations in many popular client applications and their low attack surface, kernel exploits are the next logical step to fully compromise a system.

Most vulnerabilities in the Windows kernel are memory corruptions and almost all of them affect the kernel pool, which is analogous to the user-mode heap. Nikita highlighted important research in exploiting pool corruption vulnerabilities, as well as counter measures implemented in recent Windows versions. Most importantly, many of the techniques presented by Tarjei Mandt ((https://twitter.com/kernelpool) in the last years were fixed by Microsoft in Windows 8 and the remaining approaches require a high amount of control about the pool layout, as well as the corruption itself.

In order to allow exploitation of limited pool corruptions (for example overflows with a constant value) Nikita started looking at attack vectors not directly involving pool allocator metadata. His approach, called “Direct Kernel Object Header Manipulation” overwrites the single byte TypeIndex field inside a kernel object header.

The TypeIndex field is used as an array index to find the address of a type initializer procedure which can be triggered using the NtQuerySecurityObject syscall. Interestingly, the used array includes several indexes with a value of 0, as well as an entry with the hardcoded constant 0xbad0b0b0. As Nikita discovered, the referenced index is called during several syscalls including tQuerySecurityObject. This means that by corrupting the TypeEntry field of a kernel object and calling the NtQuerySecurityObject syscall using this object as an argument, the kernel can be manipulated to execute code mapped at 0×00000000 or 0xbad0b0b0.

By default, Windows 7 allows user mode to map code at the NULL address which makes exploitation trivial, but Windows 8 fixed this and MS13-31 (link) backported this feature back to Windows 7 systems. However, if we can write the right “magic” offset into TypeEntry 0xbad0b0b0 is dereferenced, which can be exploited in multiple ways depending whether we are on a x64 or x86 system.

Nikita finished his talk with the recommendation that Microsoft includes cookie values in the object header to make overwrite exploits harder and the prediction that SMAP (http://lwn.net/Articles/517475/) could be used to make the presented technique obsolete on x64 systems.

Overall, the talk was really impressive and the presented technique can allow successful exploitation of limited pool corruption bugs. Unfortunately, no demo exploit was presented which was a bit of a bummer.

 
Defeating the Intercepting Web Proxy – A Glimpse into the Next Generation of Web Security Tools by Petko D. Petkov

Information security researcher Petko D Petkov aka “PDP” (twitter: @pdp) founder of GNUCITIZEN talked about new developments in the HTTP proxy world. After 7 years of planning and development and even more experience gathering he introduced his newly developed Web testing Suite: Web Securify (http://www.websecurify.com/) and indicated how testing of Web Applications is evolving. Complexity of Web Applications is increasing due to different technologies like HTML 5 and JavaScript Engines utilized to their fullest extent. For example there are already fully fledged Graphic engines for games like first person shooters running in the browser along with a huge variety of other multi language Web Applications requiring a new techniques for effective testing.

Traditional Web Proxies operate on a standalone basis – they use sockets to intercept messages and are based on additional software that you have to install. Web Securify is integrated straight into the browser without using any intercepting proxies or any other standard tools.

Petkov addressed how many lines of code are needed to develop a browser, are increasing (4 Million LoC) compared to an operating system´s (Linux-Kernel 14 Million LoC). Because of this fact he said, it really makes sense not to put an additional layer of tools between the browser and the operating system.

WebSecurify is all about putting an Attack Proxy like Burp into the browser by extending Browsers functionality (Firefox, Chrome) using the browsers API, so that messages are directly inspected without the need to be buffered by the proxy. Buffering slows down the testing and thus adds the need for pipelining to speed things up.

In his live demo Petkov demonstrated the passive scan of the PayPal website showing some flaws in applications on PayPal’s subdomains. Web Securify is capable of detecting common vulnerabilities by passively testing websites.

It was a good talk showing where WebTesting is heading. Although WebSecurify is still under development, it is already showing his full potential in regard of performance. The always annoying and time wasting loading of burp files is also history. Web Securify can load Burp State Files in no time. Petkov´s goal was to exploit various web technologies using nothing but web browsers and he is definitely heading in the right way. During the Live Demo there was only a Text field to enter the target URL but it was not possible to define a certain scope, which we think could be a problem for scoped tests. But the Suite is still under development and our expectations are that such features will come.

 
Virtually Secure – a journey from analysis to remote root 0day on an industry leading SSL-VPN Appliance (Firepass F5) by Tal Zeltzer

The goal was to have command execution from remote on a Firepass F5 SSL-VPN Appliance. Therefore an analysis of both virtual and physical appliances was done. From a blackbox point of view the attack surface was not very suggestively: Three opened ports (http, https, ssh) and a mostly http based communication. Mounting the system on another OS revealed some more information: an unencrypted boot partition, the rest of the hdd is encrypted, things like losetup and gpg run on the appliance but with these information we are still unable to mount the encrypted drivers. To be able to decrypt the hdd the losetup command in the bootloader was replaced with a busybox shell so the machine booted with a shell. With the command “/lib/losetup -e …” it was possible to decrypt the rest of the hdd. As the next step a backdoor was compiled and added to the init.d.

Then, from a whitebox point of view the attack surface changed a lot: A lot of outdated software was identified: A very old linux distribution (slackware release from 2000), apache and openssl versions from 2004 and many more… As there are known vulnerabilities in that old software it is still hard to write memory corruption exploits without a testbox so some more information had to be found out: There are some unknown apache modules running, the ssh on the system was modified and it was possible to download some of the php scripts, which looked like binary because they are encrypted with “Ioncube php”. Ioncube pre-compiles and encrypts the php code. In old versions this can be circumvented by xDebug/VLD but as it is very hard to compile this approach was dropped.

Next approach: have a look at the mysql log and the unknown apache modules. By watching the modules “virtual directory” was found and by playing with the parameters an sql injection was identified. By using “aaa%20aaa” as an injection payload it turned out that there is a format string vulnerability because url parameters don’t get url-decoded on serverside and a proof of concept could be done by injecting %08x–%08x–%08x to get some memory offsets. Because there was already one logical flaw found (SQLi) no further information gathering on this format string vuln was done. Instead the SQLi was used to paste some php shell code in a file to be able to execute commands. This was done by circumventing the “no-white-spaces-can-be-used” problem with the old comment trick (example payload: hello’/**/union/**/select…). As there was an old mysql version (3.23) no unions were supported, so the writing into a file had to be done by the “FIELDS SEPERATED BY” query that allows to write arbitrary data into a file. The final query looked like this:
“hello‘/**/or/**/(‘1’=‘1’)/**/into/**/outfile/**/’/tmp/test’/**/fields/**/seperated/**/by/**/0x603c3f706870…3f3e/**/–%20d”. With this the shell was created and was used in combination with “sudo” to execute commands as root.

I just had an interesting discussion with Jim Small (who gives the “IPv6 Attacks and Countermeasures” talk at the North American IPv6 Summit next week) about the feasibility of the “undetermined-transport” keyword in PACLs on Cisco 3560 switches (here running  IOS 15.0(2)SE). Actually there’s some kind-of funny behavior as for it on that platform (and there’s even some Cisco documentation stating it’s not supported). Let’s have a look, and start with a quick refresher.

Rogue router advertisements pose a significant security and network stability risk in IPv6 networks. That’s why there’s a security feature implemented on certain switches which is called “RA Guard” (see also here). Unfortunately (at least Cisco’s current implementation of) RA Guard can easily be circumvented, e.g. by using the following command from the THC IPV6 attack toolkit:

fake_router26 -E D eth0

This is a known problem (see Fernando‘s IETF draft on RA Guard implementation advice) and the common way addressing this in Cisco space is by replacing RA Guard with a PACL containing “undetermined-transport” (as, for example, described/discussed here and here). Unfortunately, it seems that “undetermined-transport” is not supported on some 3560 platforms/images and an attempt to bind an ACL containing it to a port gives a parsing error, like:

Switch>sh access-list
IPv6 access list Stop_RA_Attacks
deny icmp any any router-advertisement log-input sequence 10
deny ipv6 any any log-input undetermined-transport sequence 11
permit ipv6 any any sequence 20;

Switch(config)#int g0/3
Switch(config-if)# ipv6 traffic-filter Stop_RA_Attacks in
% This ACL contains following unsupported entries.
% Remove those entries and try again. deny ipv6 any any log-input undetermined-transport sequence 11
% This ACL can not be attached to the interface.
Switch(config-if)#
*Mar 1 00:59:05.298: %PARSE_RC-4-PRC_NON_COMPLIANCE: ` ipv6 traffic-filter Stop_RA_Attacks in'

However, if one adds the ACL entry containing “undetermined-transport” after binding the ACL to the port, it is accepted and, more importantly, it works like a charm (we tested this in several settings). This could look like this:

Switch(config)#ipv6 access-list Stop_RA_Attacks
Switch(config-ipv6-acl)#no deny ipv6 any any log-input undetermined-transport $
Switch(config-ipv6-acl)#exi
Switch(config)#int g0/3
Switch(config-if)# ipv6 traffic-filter Stop_RA_Attacks in
Switch(config-if)#exi


and then

Switch(config)#ipv6 access-list Stop_RA_Attacks
Switch(config-ipv6-acl)#deny ipv6 any any log-input undetermined-transport sequence 11
Switch(config-ipv6-acl)#exi

Overall, the relevant parts of the config then look like:

Switch(config)#do sh run | b 0/3
interface GigabitEthernet0/3
switchport access vlan 20
switchport mode access
ipv6 traffic-filter Stop_RA_Attacks in
Switch(config)#do sh access-list

IPv6 access list Stop_RA_Attacks
deny icmp any any router-advertisement log-input sequence 10
deny ipv6 any any log-input undetermined-transport sequence 11
permit ipv6 any any sequence 20
Switch(config)#

========

So, in short, going with PACLs with “undetermined-transport” provides much better protection against rogue RAs than “RA Guard” currently. And it can be used on some platforms (at least on 3560s running 15.0(2)SE) if applied the right way.

Have a great weekend everybody

Enno

The gritsforbreakfast blog post making the rounds on the Liberation Tech mailing list about security of Apple’s iMessaging service is gaining quite some attention. The post refers to a CNET article on how the iMessage service “stymied attempts by federal drug enforcement agents to eavesdrop” conversations due its end-to-end encryption and commends Apple for protecting the user’s privacy while pointing out that Gmail and Facebook Messaging don’t. However, I disagree on some points of the blog post and therefore want to discuss them here.

Before we get to the iMessage service I want to comment on the criticism on Gmail. It’s like comparing apples and oranges. iMessage is a proprietary technology and  corresponding servers are in control of one company. In contrast Gmail is just a generic e-mail service. Well known encryption methods like PGP are freely available for content encryption of e-mails. Blaming Google for not securing network transmission is just questionable due to well-known technical limitations of “e-mail”.

Coming back to iMessage, I would like to start the discussion on storage encryption. One big issue, besides eavesdropping, is that devices get easily lost, stolen or even can be confiscated by law enforcement agencies. Apple iOS implements two mechanisms for local storage security. One is hardware supported data at rest encryption which is often misunderstood. Its main purpose is to allow for fast and reliable remote wipes of storage cleaning the encryption keys instead of overwriting all data. The encryption key is embedded in hardware and as soon you turn on your iDevice the whole storage is decrypted using this key – no matter how long/strong your unlock PIN is.
The other one is Data Protection[pdf] which is only activated when you set a PIN or password . It only secures your data while the device is locked (which also depends on the protection class developers choose).

Data Protection – key derivation and encryption

It is an additional layer of encryption which uses a key derived from your PIN/PW and the hardware embedded key. Bruteforcing the PIN must be performed on the actual device due to the fact that the hardware encryption key can’t be extracted from the device. In addition, access frequency to the hardware key is artificially slowed down which obviously slows down the whole bruteforce process significantly.  As a consequence it will take you up to 20 minutes for a 4 digits PIN on an iPhone4. For an alphanumeric password with a length of 6 it already takes up to 196 years for a successful attack. The downside of Data Protection is that particular Apps have to use it for data they store. On a stock iOS device only the Mail App and Keychain make use of DP. In addition only a couple of Apps in the AppStore implement DP.

Assuming your device has set a secure alphanumeric password which doesn’t allow bruteforcing it in a reasonable amount of time, there still is an easy way on getting the rest of your data (including your SMS and iMessages). iPhones older than the 4S model as well as the first generation iPad have a bootloader vulnerability which allows to boot unsigned firmware. Elcomsoft sells a password recovery tool to law enforcement agencies which makes use of this vulnerability. Meanwhile there is a publicly available bruteforce and recovery tool for 4 digits PINs as proof of concept. It’s achieved through booting the device with a custom RAM disk without touching the actual iPhone Operating System.
While there’re only rumors on Apple supporting law enforcement agencies in decryption of confiscated iDevices, Dmitry Sklyarov (former employee at Elcomsoft) confirmed during his last talk at TROOPERS , that Apple sings the Firmware of particular 3-Letter-Agencies. This enables them to run custom RAM disks not only on older vulnerable devices but on all iDevices available on the market as well as on those developed and manufactured in the future. DP is rarely used either due to usability reasons or – what I see as the more significant reason – because it’s just little known among developers. When you’re sure a particular App carrying your sensitive data uses DP, the security of data heavily relies on the quality of the password you set. So let’s look at iMessage security.

“Apple didn’t have to build iMessage with end-to-end encryption”

This is basic protection against eavesdropping in local area networks, on the way to Apple servers and to your communication partner. While there are no criticisms at that it should be pointed out that this is rudimentary protection, even when many consumer cloud services do not implement transmission encryption (sadly).

iMessage is a proprietary protocol. The service as well as the corresponding infrastructure is owned by Apple. It’s based on the APNS (Apple Push Notification Server).  Having a look at Apple’s documentation gives an idea on how the transmission encryption is implemented and brings up the second point you should keep in mind when using iDevices with particular cloud services. As Mathew Green already pointed out in the original article, Apple might take advantage of its position as cloud service provider and decrypt the transmitted traffic as well as forward your messages to law enforcement agencies.

Last but not least you should be aware of the fact that your backups made with iCloud are stored on servers in the USA. Therefore Apple, like all the other cloud service providers, has to provide law enforcement agencies with a warranty of accessing all your data they store (including your Messages (-; ).

I still don’t see why the DEA complains about a service whose introduction is two years past and why they don’t use the same procedure like other agencies do, sometimes even without a warrant.

Remember, as soon as you are using a proprietary platform and its backend services, its owner is in control of all data you provide. Apple improved their security a lot during the last years. But that doesn’t matter too much. As soon as a 3-Letter-Agency knocks the door and calls for their warrant the service provider will deliver your data, simply because he has to. This is not about Apple being evil (or not), it’s about US law. Hopefully I could give you enough technical reasons to not have a false sense of security.

cheers
Sergej

Last week Rapid7 posted an interesting analysis of the Amazon S3 storage system: Apparently roughly one out of six S3 buckets (a bucket is, simply said, a kind of folder) is accessible without any authentication mechanism. Accessing those files, the Rapid7 guys were able to download a wide range of data, also comprising confidential information such as source code or employee information, comparable to past research for other platforms (see also this presentation I gave on some of the biggest Cloud #Fails)

While I have a similar opinion like Gartner’s Kyle Hilgendorf and think this is clearly not Amazon’s fault as all buckets/files are per default non-public (there were quite some sources blaming Amazon for poor “security”), there are relevant lessons to be learned (once again):

• Most probably your organization is already using “the Cloud” — in one way or another. We have meetings/workshops where the question “Do you use any Cloud services?” is raised on a regular base. Typically most people answer in a way like “No, not yet. But we think about it.” until someone raises his hand and admits “well, for this or this particular system absolutely not processing sensitive data we use $CLOUD_SERVICE”.
• As you (or your departments , aka “the business”) are using it anyways, prepare for it: If you have to deal with it, deal with it in a structured and well-governed way instead of suddenly realizing that your data is “referenced to” in reports like the one mentioned above.

I don’t think that additional tools like this or this solve “Cloud security” problems. They can provide some support, but they can never replace the development of your own Cloud strategy and governance. I admittedly wrote often that this Cloud strategy (e.g. here & here) must challenge old security models and take architectural Cloud changes into account, but never laid out how these models and changes look like — so there will be a longer post on this in the (near) future

Stay tuned & take care,

Matthias