Enabling Two-Factor Authentication (2FA) for Apple ID and DropBox

In light of the recent compromises, you’re probably wondering what could have been done to prevent such attacks. According to some unverified articles it would appear that flaws in Apple’s services allowed an attacker to brute force passwords without any rate limiting or account lockout. While its not publicly known if the attacks were accomplished via brute force password guessing, there has been a lot of talk about enabling Two-Factor Authentication (2FA) across services that offer it. The two most popular services being discussed are iCloud and DropBox. While setting up 2FA on these services is not as easy as it should be, this guide will step you through enabling 2FA on Google, Apple ID and DropBox accounts. It’s a free way of adding an extra layer of security on top of these services which handle potentially sensitive information.

What is Two-Factor Authentication?

Username and password authentication uses a single factor to verify identity: something the user knows. Two-Factor authentication adds an extra layer of security on top of a username and password. Normally, the second factor is something only the real user has. This is typically a temporary passcode generated by a piece of hardware such as an RSA token, a passcode sent as an SMS to the user’s cell phone, or a mobile application that accomplishes the same function.

With two-factor authentication, stealing a username and password won’t be enough to log in — the second factor is also required. This multi-factor authentication means an attacker will be required to compromise a user above and beyond password guessing or stealing a credentials database. An attacker would have to gain access to the source of the extra, unique and usually temporary information that makes up the 2FA.

Most services provide 2FA tokens through multiple means (SMS, mobile application or separate hardware token), however setting up 2FA on these services can sometimes be tricky. 2FA is still not enabled by default and users are not forced to use it.


An explanatory video from Google about their version of 2FA (you should use this too)

Use a unique password for all of your accounts on top of 2FA. Attackers may have access to lists of passwords and usernames from other websites that have been compromised. These lists may contain your username and password as well. With 2FA enabled, they’ll be missing that last piece of the puzzle for account authentication.

Apple ID

Apple allows you to setup both an SMS and Mobile Push 2FA. Mobile Push means the 2FA code will be delivered to your phone using Apple’s Push messaging system.

While Apple has implemented 2FA for some services it has not been rolled out completely, most notably iCloud. Apple has been seen testing 2FA on iCloud but has not launched support yet. Once Apple rolls out 2FA support for iCloud you’ll most likely be prompted for the 2FA code automatically. There should be no enrollment process for iCloud separate from the rest of the Apple 2FA enrollment process below.

For the purposes of this tutorial, we’ll be setting up SMS only, as that will be the most compatible and cover 2FA setup process for all phones, not just iPhones.

1. Sign into your Apple ID at https://appleid.apple.com and click “Password and Security” from the menu on the right:

1_edit

You will be asked to answer your personal security questions to proceed.

2. At the very top you’ll see a paragraph explaining Two-Step Verification. Click “Get Started” to enroll.

2_edit

3. Apple will ask you to read a few notices before you begin Step 1 of the enrollment process. Read each screen and click continue until you get to the first step. Each screen is shown below:

3_edit

4_edit

5_edit

4. Apple will now ask you to provide your mobile phone number. This will be used to send you a Two-Factor Authentication token as an SMS to verify the phone number you entered is yours and in your physical possession.

6_edit

7_edit

After entering your cell phone number, an SMS will arrive with a 4 digit code.

9_edit

The Apple website will ask you to enter this code.

8_edit

Once you’ve entered it your phone number will be “verified”.

10_edit

Press “Continue” to proceed.

5. Apple will now provide you with a “Recovery Key” in case you lose possession of your phone or phone number. This is a secret code that will allow you to recover your account in the event something goes wrong with your Two-Factor Authentication procedure. It is very important you keep this code secure and private! With this code, an attacker may be able to compromise your account. Don’t store this code electronically on your computer. Print it and put it in a safe place.

Without it, you could become locked out of your Apple account without any recourse.

11_edit

6. Apple will now ask you to re-enter your “Recovery Key”. This ensures that you have copied it down and it is now your responsibility to store it securely.

12_edit

7. You’re almost there! Read the conditions presented to you and click the “I understand the conditions above.” checkbox.

Then take a deep breath and click “Enable two-step Verification”

13_edit

Congratulations! You’ve now enabled Two-Factor Authentication on your Apple ID account. Logout and log back in to try it out.

14_edit

DropBox

DropBox allows you to setup 2FA using SMS or a mobile application. For the purposes of this guide we’ll step through setting up 2FA using SMS only to be compatible with the most configurations of mobile phones.

1. Login to your DropBox account and click your name in the top righthand corner of the screen. Select “Settings” from the drop down menu.

1_edit

2. Click the “Security” tab in the top left hand portion of the page.

02_edit

3. Under “Two-Step verification” click “Enable”

03_edit

4. DropBox will display some information about their two-step verification process. Click “Get Started” to continue.

04_edit

5. DropBox will ask you to enter your password to continue the two-step verification process.

05_edit

6. For the purposes of this tutorial we’ll select the “Use text messages” option. This will send 2FA codes to your phone as an SMS.

06_edit

7. DropBox will ask for your mobile phone number.

08_edit

After your click “Next” an SMS will be sent to your phone with a “security code”.

2facode

DropBox will ask for the code and verify your phone number.

09_edit

8. DropBox will ask if you wish to provide a backup mobile phone number. This is an optional step, if you choose to provide a backup number you will be required to repeat the process above for enrolling another mobile phone number.

10_edit

9. Similar to Apple ID, DropBox will provide you with a “recovery key” or as they call it an “emergency backup code” to disable two-step verification in the event you lose possession of your phone or lose control of your mobile phone number.

Write it down and keep it safe, DropBox does not ask you to re-enter this code so make sure you keep a copy of it somewhere.

10_new_edit

10. Finally, click “Enable two-step verification” and you’re finished!

Other Services

Many services other than Google, Apple and DropBox provide some form of 2FA. You may have to search around your account settings to locate the option to enroll. Not all services allow 2FA over SMS and may require the use of a mobile phone app such as Duo, Authy or another 2FA software vendor. Use twofactorauth.org to discover which services you use support 2FA:

twofactorauth.org keeps track of which services support 2FA

twofactorauth.org keeps track of which services support 2FA

Conclusion

Unfortunately, on today’s Internet you are responsible for your own security, even if you use web services from respectable Internet companies. Two-factor authentication significantly increases the security of your accounts by making stolen passwords harder to abuse. Enabling two-factor authentication is not without extra responsibility. You must be sure to setup 2FA on devices you control and protect any “recovery keys” in case you lose control of your device or mobile phone number. 2FA is not foolproof, but using it where you can will put you a head above the rest.

Update – Sep 16th, 2014

Apple has finally enabled two-factor authentication on iCloud.com. It now asks you to verify yourself via the 2FA method you signed up for using the above instructions.

2fa_icloud

Testing this with Elcomsoft’s iCloud forensics tool shows that 2FA is preventing the tool from logging in successfully even with a valid password.

elcom_failElcomsoft may update the tool to support 2FA tokens, however it would still require an attacker to obtain access to the device or method in which you receive your 2FA tokens and utilize them before they expire. This is still much better than simply requiring just your username and password. It is raising the bar for the attacker to compromise your account.

ReMASTering Applications by Obfuscating during Compilation

In this post, we discuss the creation of a novel software obfuscation toolkit, MAST, implemented in the LLVM compiler and suitable for denying program understanding to even the most well-resourced adversary. Our implementation is inspired by effective obfuscation techniques used by nation-state malware and techniques discussed in academic literature. MAST enables software developers to protect applications with technology developed for offense.

MAST is a product of Cyber Fast Track, and we would like to thank Mudge and DARPA for funding our work. This project would not have been possible without their support. MAST is now a commercial product offering of Trail of Bits and companies interested in licensing it for their own use should contact info@trailofbits.com.

Background

There are a lot of risks in releasing software these days. Once upon a time, reverse engineering software presented a challenge best solved by experienced and skilled reverse engineers at great expense. It was worthwhile for reasonably well-funded groups to reverse engineer and recreate proprietary technology or for clever but bored people to generate party tricks. Despite the latter type of people causing all kinds of mild internet havoc, reverse engineering wasn’t widely considered a serious threat until relatively recently.

Over time, however, the stakes have risen; criminal entities, corporations, even nation-states have become extremely interested in software vulnerabilities. These entities seek to either defend their own network, applications, users, or to attack someone else’s. Historically, software obfuscation was a concern of the “good guys”, who were interested in protecting their intellectual property. It wasn’t long before malicious entities began obfuscating their own tools to protect captured tools from analysis.

A recent example of successful obfuscation is that used by the authors of the Gauss malware; several days after discovering the malware, Kaspersky Lab, a respected malware analysis lab and antivirus company, posted a public plea for assistance in decrypting a portion of the code. That even a company of professionals had trouble enough to ask for outside help is telling: obfuscation can be very effective. Professional researchers have been unable to deobfuscate Gauss to this day.

Motivation

With all of this in mind, we were inspired by Gauss to create a software protection system that leapfrogs available analysis technology. Could we repurpose techniques from software exploitation and malware obfuscation into a state-of-the-art software protection system? Our team is quite familiar with publicly available tools for assisting in reverse engineering tasks and considered how to significantly reduce their efficacy, if not deny it altogether.

Software developers seek to protect varying classes of information within a program. Our system must account for each with equal levels of protection to satisfy these potential use cases:

  • Algorithms: adversary knowledge of proprietary technology
  • Data: knowledge of proprietary data (the company’s or the user’s)
  • Vulnerabilities: knowledge of vulnerabilities within the program

In order for the software protection system to be useful to developers, it must be:

  • Easy to use: the obfuscation should be transparent to our development process, not alter or interfere with it. No annotations should be necessary, though we may want them in certain cases.
  • Cross-platform: the obfuscation should apply uniformly to all applications and frameworks that we use, including mobile or embedded devices that may run on different processor architectures.
  • Protect against state-of-the-art analysis: our obfuscation should leapfrog available static analysis tools and techniques and require novel research advances to see through.

Finally, we assume an attacker will have access to the static program image; many software applications are going to be directly accessible to a dedicated attacker. For example, an attacker interested in a mobile application, anti-virus signatures, or software patches will have the static program image to study.

Our Approach

We decided to focus primarily on preventing static analysis; in this day and age there are a lot of tools that can be run statically over application binaries to gain information with less work and time required by attackers, and many attackers are proficient in generating their own situation-specific tools. Static tools can often very quickly be run over large amounts of code, without necessitating the attacker having an environment in which to execute the target binary.

We decided on a group of techniques that compose together, comprising opaque predicate insertion, code diffusion, and – because our original scope was iOS applications – mangling of Objective-C symbols. These make the protected application impossible to understand without environmental data, impossible to analyze with current static analysis tools due to alias analysis limitations, and deny the effectiveness of breakpoints, method name retrieval scripts, and other common reversing techniques. In combination, these techniques attack a reverse engineer’s workflow and tools from all sides.

Further, we did all of our obfuscation work inside of a compiler (LLVM) because we wanted our technology to be thoroughly baked into the entire program. LLVM can use knowledge of the program to generate realistic opaque predicates or hide diffused code inside of false paths not taken, forcing a reverse engineer to consult the program’s environment (which might not be available) to resolve which instruction sequences are the correct ones. Obfuscating at the compiler level is more reliable than operating on an existing binary: there is no confusion about code vs. data or missing critical application behavior. Additionally, compiler-level obfuscation is transparent to current and future development tools based on LLVM. For instance, MAST could obfuscate Swift on the day of release — directly from the Xcode IDE.

Symbol Mangling

The first and simplest technique was to hinder quick Objective-C method name retrieval scripts; this is certainly the least interesting of the transforms, but would remove a large amount of human-readable information from an iOS application. Without method or other symbol names present for the proprietary code, it’s more difficult to make sense of the program at a glance.

Opaque Predicate Insertion

The second technique we applied, opaque predicate insertion, is not a new technique. It’s been done before in numerous ways, and capable analysts have developed ways around many of the common implementations. We created a stronger version of predicate insertion by inserting predicates with opaque conditions and alternate branches that look realistic to a script or person skimming the code. Realistic predicates significantly slow down a human analyst, and will also slow down tools that operate on program control flow graphs (CFGs) by ballooning the graph to be much larger than the original. Increased CFG size impacts the size of the program and the execution speed but our testing indicates the impact is smaller or consistent with similar tools.

Code Diffusion

The third technique, code diffusion, is by far the most interesting. We took the ideas of Return-Oriented Programming (ROP) and applied them in a defensive manner.

In a straightforward situation, an attacker exploits a vulnerability in an application and supplies their own code for the target to execute (shellcode). However, since the introduction of non-executable data mitigations like DEP and NX, attackers have had to find ways to execute malicious code without the introduction of anything new. ROP is a technique that makes use of code that is already present in the application. Usually, an attacker would compile a set of short “gadgets” in the existing program text that each perform a simple task, and then link those together, jumping from one to the other, to build up the functionality they require for their exploit — effectively creating a new program by jumping around in the existing program.

We transform application code such that it jumps around in a ROP-like way, scrambling the program’s control flow graph into disparate units. However, unlike ROP, where attackers are limited by the gadgets they can find and their ability to predict their location at runtime, we precisely control the placement of gadgets during compilation. For example, we can store gadgets in the bogus programs inserted during the opaque predicate obfuscation. After applying this technique, reverse engineers will immediately notice that the handy graph is gone from tools like IDA. Further, this transformation will make it impossible to use state-of-the-art static analysis tools, like BAP, and impedes dynamic analysis techniques that rely on concrete execution with a debugger. Code diffusion destroys the semantic value of breakpoints, because a single code snippet may be re-used by many different functions and not used by other instances of the same function.

graph view is useful

Native code before obfuscation with MAST

graph view is useless

Native code after obfuscation with MAST

The figures above demonstrate a very simple function before and after the code diffusion transform, using screenshots from IDA. In the first figure, there is a complete control flow graph; in the second, however, the first basic block no longer jumps directly to either of the following blocks; instead, it must refer at runtime to a data section elsewhere in the application before it knows where to jump in either case. Running this code diffusion transform over an entire application reduces the entire program from a set of connected-graph functions to a much larger set of single-basic-block “functions.”

Code diffusion has a noticeable performance impact on whole-program obfuscation. In our testing, we compared the speed of bzip2 before and after our return-oriented transformation and slowdown was approximately 55% (on x86).

Environmental Keying

MAST does one more thing to make reverse engineering even more difficult — it ties the execution of the code to a specific device, such as a user’s mobile phone. While using device-specific characteristics to bind a binary to a device is not new (it is extensively used in DRM and some malware, such as Gauss), MAST is able to integrate device-checking into each obfuscation layer as it is woven through the application. The intertwining of environmental keying and obfuscation renders the program far more resistant to reverse-engineering than some of the more common approaches to device-binding.

Rather than acquiring any copy of the application, an attacker must also acquire and analyze the execution environment of the target computer as well. The whole environment is typically far more challenging to get ahold of, and has a much larger quantity of code to analyze. Even if the environment is captured and time is taken to reverse engineer application details, the results will not be useful against the same application as running on other hosts because every host runs its own keyed version of the binary.

Conclusions

In summary, MAST is a suite of compile-time transformations that provide easy-to-use, cross-platform, state-of-the-art software obfuscation. It can be used for a number of purposes, such as preventing attackers from reverse engineering security-related software patches; protecting your proprietary technology; protecting data within an application; and protecting your application from vulnerability hunters. While originally scoped for iOS applications, the technologies are applicable to any software that can be compiled with LLVM.

iVerify is now available on Github

Today we’re excited to release an open-source version of iVerify!

iPhone users now have an easy way to ensure their phones are free of malware.

iVerify validates the integrity of supported iOS devices and detects modifications that malware or jailbreaking would make, without the use of signatures. It runs at boot-time and thoroughly inspects the device, identifying any changes and collecting relevant artifacts for offline analysis.

In order to use iVerify, grab the code from GitHub, put your phone in DFU mode and run the iverify utility. Prompts on screen will indicate whether surreptitious modifications have been made. Visit the GitHub repository for more information about iVerify.

iOS 4 Security Evaluation

This year’s BlackHat USA was the 12th year in a row that I’ve attended and the 6th year in a row that I’ve participated in as a presenter, trainer, and/or co-organizer/host of the Pwnie Awards. And I made this year my busiest yet by delivering four days of training, a presentation, the Pwnie Awards, and participating on a panel. Not only does that mean that I slip into a coma after BlackHat, it also means that I win at conference bingo.

Reading my excuses for the delay in posting my slides and whitepaper, however, is not why you are reading this blog post. It is to find the link to download said slides and whitepaper:

Hacking at Mach 2!

At BayThreat last month, I gave an updated (and more much sober) version of my “Hacking at Mach Speed” presentation from SummerC0n.  Now, since the 0day Mach RPC privilege de-escalation vulnerability has been fixed, I can include full details on it.  The presentation is meant to give a walkthrough on how to identify and enumerate Mach RPC interfaces in bootstrap servers on Mac OS X.  Why would you want to do this?  Hint: there are other uses for these types of vulnerabilities besides gaining increased privileges on single-user Mac desktops.  Enjoy!

  • “Hacking at Mach 2!” (PDF)

KARMA Demo on the CBS Early Show

Although I haven’t done any development on KARMA for a little over 5 years at this point, many of the weaknesses that it demonstrates are still very present, especially with the proliferation of open 802.11 Hotspots in public places. A few weeks ago, I was invited to help prepare a demo of KARMA for CBS News and the segment actually aired a few weeks ago. If you’re like me and don’t have one of those old-fashioned tele-ma-vision boxes, you can check out the segment here.

Unfortunately, they weren’t able to use the full demo that I prepared. The full demo used a KARMA promiscuous access point to lure clients onto my rogue wireless network with a rogue network’s gateway routed outbound HTTP traffic through a transparent proxy that injected IFRAMEs in each HTML page. The IFRAMEs loaded my own custom “Aurora” exploit, which injected Metasploit’s Meterpreter into the running web browser. From there, I could use the Meterpreter to sniff keystrokes as they logged into their SSL-protected bank/e-mail/whatever. The point was that even if a victim only uses the open Wi-Fi network to log into the captive portal webpage, that’s enough for a nearby attacker to exploit their web browser and maintain control over their system going forward. Perhaps that was a little too complicated for a news segment that the average American watches over breakfast.

As it has been quite a while since I have talked about KARMA, here are a few updates on the weaknesses that it demonstrated:

  • Windows XP SP2 systems with 802.11b-only wireless cards would “park” the cards when the user is not associated to a wireless network by assigning them a 32-character random desired SSID. Even if the user had no networks in their Preferred Networks List, the laptop would associate to a KARMA Promiscuous Access Point and activate the network stack while the GUI would still show the user as not currently associated to any network. This issue was an artifact of 802.11b-only card firmwares (PrismII and Orinoco were affected) and is not present on most 802.11g cards, which is what everyone has these days anyway.
  • Even with a newer card, Windows XP SP2 will broadcast the contents of its Preferred Networks List in Probe Request frames every 60 seconds until it joins a network. Revealing the contents of the PNL allows an attacker to create a network with that name or use a promiscuous access point to lure the client onto their rogue network. Windows Vista and XP SP3 fixed this behavior.
  • Mac OS X had the same two behaviors, except that Apple’s AirPort driver would enable WEP on the wireless card when it had “parked” it. However, the WEP key was a static 40-bit key (0x0102030405 if I recall). Apple issued a security update in July 2005 and credited me for reporting the issue.
  • On 10/17/2006, Microsoft released a hotfix to fix both of the previous issues on Windows XP SP2 systems that Shane Macaulay and I had discovered and presented at various security conferences over the previous two years.
  • Newer versions of Windows (XP SP3, Vista, 7) are only affected if the user manually selects to join the rogue wireless network or the rogue network beacons an SSID in the user’s Preferred Networks List.

Although the leading desktop operating systems found on most laptops have addressed the issue, most mobile phones now support 802.11 Wi-Fi, which may give KARMA a chance to live again!

Advanced Mac OS X Rootkits

At BlackHat USA 2009, I presented “Advanced Mac OS X Rootkits” covering a number of Mach-based rootkit techniques and some tools that I have developed to demonstrate them.  While the majority of Mac OS X rootkits employ known and traditional Unix-based rootkit techniques, these Mach-based techniques show what else is possible using the powerful Mach abstractions in Mac OS X.  My presentation covered a number of Mach-based rootkit tools and techniques including user-mode Mach-O bundle injection, Mach RPC proxying, in-kernel RPC server injection/modification, and kernel rootkit detection.

User-mode DLL injection is quite common on Windows-based operating systems and is facilitated by the CreateRemoteThread API function.  The Mach thread and task calls support creating threads in other tasks, however, they are much more low-level.  The inject-bundle tool demonstrates the steps necessary to use injected memory and threads to load a Mach-O bundle into another task.  A number of injectable bundles are included to demonstrate the API (test), capture an image using the iSight camera (iSight), log instant messages from within iChat (iChatSpy), and log SSL traffic sent through the Apple Secure Transport API (SSLSpy).

The majority of Mach kernel services (task and thread system calls, for example) are implemented as RPC services.  The Mach message format was designed to be host-independent, which facilitates transferring them across the network.  Machiavelli demonstrates using Mach RPC proxying in order to transparently perform Mach RPC to a remote host. Machiavellian versions of ps and inject-bundle are included in order to demonstrate how this technique may be used for remote host control by rootkits.

Most of the public kernel rootkits for Mac OS X load as kernel extensions and remove their entries from the kernel’s kmod list in order to hide themselves from kextstat and prevent themselves from being unloaded. The uncloak tool examines the kernel memory regions looking for loaded Mach-O objects.  If any of these objects do not correspond to a known kernel extension, they may be dumped to disk using kernel-macho-dump.

Mach IPC messages to the in-kernel Mach RPC servers are dispatched through the mig_buckets table.  This table stores function pointers to the kernel RPC server routines and is analogous to the Unix systent system call table.  A kernel rootkit may directly modify this table in order to inject new kernel RPC servers or interpose on in-kernel RPC server routines.  The KRPC kernel extension shows how a kernel rootkit may directly modify this table in order to dynamically inject a new in-kernel RPC subsystem.

These tools are deliberately released as ‘non-hostile’
proof-of-concept tools that meant to demonstrate techniques and are
not suitable for use in actual rootkits or attack tools.  The IM and
SSL logging bundles log to the local system’s disk in an obvious
fashion and Machiavelli opens up the controlling host to some obvious
attacks.  The non-Machiavelli version of inject-bundle, however, is
fully functional and useful for a variety of system-level tasks.
Using the other tools outside of a closed network or test virtual
machine is not recommended.

These tools are deliberately released as ‘non-hostile’ proof-of-concept tools that meant to demonstrate techniques and are not suitable for use in actual rootkits or attack tools.  The IM and SSL logging bundles log to the local system’s disk in an obvious fashion and Machiavelli opens up the controlling host to some obvious attacks.  The non-Machiavelli version of inject-bundle, however, is fully functional and useful for a variety of system-level tasks.  Using the other tools outside of a closed network or test virtual machine is not recommended.

Here are the goods:

The Mac Hacker’s Handbook is out!

The Mac Hacker’s Handbook by Charlie Miller and myself has just been published and is now shipping from Amazon.  I have even spotted it in several bookstores where you can usually find it in the Mac section.  The book is all about Mac OS X-specific vulnerability discovery, reverse-engineering, exploitation, and post-exploitation.

For me, this book is a culmination of over 8 years of personal Mac OS X security research.  I had bought and restored a NeXTSTATION Turbo Color in college and fell in love with the NeXTSTEP and OpenStep operating systems.  When I got a check for my first pen-test, I bought a brand-new iBook 500 Mhz to run OS X 10.0 on and I have used OS X as my primary operating system ever since.

Of course, I started hacking on it immediately.  I wrote a monitor-mode wireless packet capture driver for AirPort (Viha) back when the only documentation on IOKit was the Darwin source code and a series of emails on the darwin mailing lists from an Apple kernel developer.  And that was just the first part of my WEP cracking project for my Crypto class.  I was so stubborn about using my iBook for it that I wrote my own driver, stumbler, and WEP weak RC4 key cracker for it.

There was also very little documentation on shellcode for PowerPC around then.  Palante and LSD had both released PowerPC shellcode for Linux and AIX respectively.  But there was nothing for OS X.  I wrote this in a hotel room in Washington, D.C. a few days after DEFCON 9.  As far as I know I was the first one to publish PowerPC shellcode that filled in the unused bits in the ‘sc’ instruction instead of dynamically overwriting them because self-modifying code is pretty tricky on PowerPC.  That shellcode is what appears encoded in the hex bytes on the cover of the book.

Alright, enough self-indulgent trips down memory lane.  I just presented “Mac OS Xploitation” at SOURCE Boston last week and I’ll be doing a bigger presentation called “Hacking Macs for Fun and Profit” next week at CanSecWest with Charlie Miller.  Stay tuned here for some more Mac tool releases.

ARM versus x86

At Hack in the Box in Kuala Lumpur this year, I was interviewed by Sumner Lemon of IDG about various Mac and iPhone-related security topics.  One of the topics was the relative security of ARM versus x86 processors and my comments on this seem to have bounced around the internets a bit.  There seems to have been some confusion over what I meant in my statements, so I thought I’d provide some clarification here on the technical and economic rationale behind this statement.

First, the technical rationale: The classic x86 architecture (pre NX-bit) is an exploit developer’s dream.  Almost every other architecture has complications that x86 almost coincidentally does not.  For example, SPARC has register windows, PowerPCs can have separate data and instruction caches, any RISC architecture has alignment requirements, most architectures support non-executable memory, and all of these make writing exploits on these platforms more difficult.  The x86 had none of these speedbumps and only started supporting truly non-executable memory somewhat recently.  Finally, the x86 instruction set is incredibly flexible, allowing all sorts of ingenious techniques for self-modifying code to evade character filters and intrusion detection systems.  Of course, this was all possible on other architectures as well (see ADMutate‘s SPARC support), but x86 makes it way easier and more powerful.  I have a hard time imagining what could be changed in x86 to make a better target for exploit developers.

Since cybercrime and malware has become a significantly sized industry, it makes a lot of sense to analyze the risk presented by it through economics (and game theory).  Attackers have a lot of infrastructure already built that is x86-specific.  Besides exploit development experience, this also includes payload encoders and hand-written assembly exploit payloads.  Rewriting these takes time and effort.  Macs (and iPhones, as postulated in the article) using x86 processors allow attackers to carry over their experience and existing infrastructure, slightly lowering the barrier to entry to begin attacking a new platform.  If a new platform with marketshare X% starts attracting malware authors’ attention, a new platform with a familiar processor may attract malware authors’ attention at (X – Y)% marketshare (where Y is probably less than 10).  In the end, however, this earlier attention most likely matters less to the product vendor than the deep discount or performance improvements they can get by going with a dominant CPU architecture and manufacturer.

In summary, just about any commodity non-x86 CPU-based system is harder to write exploits for than an x86-based system assuming the same operating system is running on both.  But it does not matter because these differences are just speed bumps and a good exploit developer will be able to work around them.  Vendors should focus on the generic security defenses that they can build into their operating systems and application runtime environments as well as focus on eliminating software vulnerabilities before and after their software is shipped rather than caring what processor architecture they use and whatever impact it may have on attacks against their platform.

Finally, I would also like to make a retraction.  In the same interview, I said that I considered the iPhone OS to be “significantly less secure” than the desktop Mac OS X.  While I would still consider the iPhone OS 1.x to be less secure than Leopard, the iPhone OS 2.2 is quite the opposite.  A number of improvements, including a smaller attack surface, application sandboxes, a non-executable heap, and mandatory code signing for every executable launched (not just applications, even low-level binaries) make compromising the special-purpose iPhone more difficult than the general-purpose desktop Mac OS X.  For more details on the security improvements in the latest iPhone OS, see Charlie Miller’s HiTBSecConf presentation.  Of course, this primarily applies to unjailbroken iPhones since a jailbroken iPhone allows execution of unsigned binaries and it seems that most jailbroken phones still have an SSH server running with the default root account password anyway.  Qualitative comparisons of security are very difficult to whittle down into a one sentence summary, but that’s why organizations (hopefully) have security analysts around and don’t make all of their decisions based on what they read on the Internet.

ARDAgent.app Vulnerability Analysis

Apple recently released Mac OS X 10.5.4 with accompanying security updates for 25 vulnerabilities.  Notably absent, however, is a fix for the recently brouhaha’d ARDAgent.app local privilege escalation vulnerability.  The exploit is extremely simple and unfortunately, it seems that the fix is not; otherwise Apple would have fixed it in this batch.  For more information on the exploit including temporary fixes and workarounds to protect yourself until Apple fixes this vulnerability, see the full write-up at MacShadows.com.

In the interest of fully understanding Mac OS X security issues, let’s dive in and see how this vulnerability works.  As a reminder, the vulnerability is that ARDAgent.app, a set-user-id root executable, responds to the “do shell script” Apple Event, effectively running arbitrary commands as root.

Applications must announce that they can receive Apple Events before they may be scripted.  In Cocoa applications, this is done by setting the NSAppleScriptEnabled property to “YES” in the application bundle’s Info.plist file.  In Carbon applications, an application is made scriptable by simply calling the AEInstallEventHandler() function.  AEInstallEventHandler() lets the application define which Apple Events it can handle and supply the handler functions for them.

ARDAgent.app did not do anything special in order to respond to the “do shell script” Apple Event, this event is defined in the StandardAdditions Scripting Addition in /System/Library/ScriptingAdditions.  Scripting Additions are dynamic libraries (dylibs) that will be loaded automatically by the Apple Event handler if the application receives an Apple Event that is defined in them.  There are several Scripting Additions in /System/Library/ScriptingAdditions, but they may also potentially be found in /Library/Scripting/Additions or ~/Library/ScriptingAdditions.

Interestingly, ARDAgent.app calls AESetInteractionAllowed() with kAEInteractWithSelf after installing its own Apple Event handlers which is supposed to restrict the processing of Apple Events to only those sent by the process itself.  It obviously does not seem to have its intended effect in this case.

This is a pretty isolated vulnerability not a massive security hole in AppleScript.  Set-user-id executables should not be scriptable and ARDAgent.app appears to be the only application that violates this.

UPDATE @ 20080704: As mentioned in the MacShadows security forums from the link in the comments below, SecurityAgent is also susceptible to this, but only when SecurityAgent is running with increased privileges (after a sudo, unlock of System Keychain, etc). But this is not because SecurityAgent is setuid, it is because it still receives Apple Events when it runs with increased privileges. It doesn’t, however, appear to call any Apple Events functions. So I am not sure why it is processing Apple Events (handled in a base framework?). If anyone knows why, let me know.

UPDATE @ 20080705: I have poked around at this a bit more this weekend, and it turns out that an application does not need to call any Apple Events APIs in order to receive and process Apple Events.  While Cocoa applications must set the NSAppleScriptEnabled property, any Carbon application automatically handles Apple Events.  At the lowest level, Apple Events are sent over Mach ports looked up from the bootstrap server, so you need port send rights in order to send it Apple Events.  This means that a client will not be able to send events to an application running as a different user unless it is setuid/setgid (ARDAgent) or is run with increased privileges, but still checks its ports in with the bootstrap server (SecurityAgent, which is launched by securityd with gid=0 on Tiger in certain situations).

Follow

Get every new post delivered to your Inbox.

Join 3,631 other followers