How does Veracode look for the presence of frameworks in Java code? Because our customers upload the application packages that they deploy or distribute (as EARs, WARs, or JARs), we can observe the presence of framework classes, configuration files, and other artifacts in the application. We record the prevalence of the framework so that we can mine the anonymized data later. We resample the data every few months to get an idea of relative framework prevalence and to see if any trends can be observed.

Below is our most current Top 10 list for Java frameworks. This list is based on a sample of over 5400 customer applications and was sampled on December 7, 2011. Note that we have decomposed one of the larger framework families, Spring, into its component frameworks to get a better idea of the usage of its individual parts. The percentages reflect the number of Java applications (not individual scans) in which the framework was observed, so an application that was scanned multiple times only counts once in the rankings.

1. Spring MVC (23%)
2. Struts 1.x (15%)
3. Apache Axis (15%)
4. Apache Xerces (14%)
5. Hibernate (12%)
6. JDOM (12%)
7. Java Applet (8.1%)
8. Apache Velocity (7.9%)
9. Apache ORO (7.0%)
10. JAX-WS (6.5%)

A couple of interesting findings here. First, the relative prevalence of Spring MVC and Struts is unsurprising, but the fact that Struts 1.x is #2 on the list and Struts 2 is not even in the Top 10 is a little surprising. (It came in 24th in the overall rankings, in fact, showing up in just 1.8% of the Java applications scanned).

Second, it’s interesting to note that there are multiple frameworks for web services in the top ten, and that Axis appears to have an edge on popularity over JAX-WS.

Third, the relatively high number of applications scanned that contained Java applets was interesting. It’s hard to imagine that 8% of all Java applications have a customer facing applet. One is tempted to speculate that in many cases these applets are administrative interfaces to framework or server code that are left in the application distribution inadvertently or unknowingly, and thus that these represent potentially forgotten attack surfaces for the application.

We’re just starting to mine the data that we’re seeing regarding frameworks. I think that this data should be interesting to development teams looking to choose frameworks that are more widely used. From a security perspective, too, this is a useful reminder that applications rely on third party frameworks, and that some of these may come with their own attack surface (e.g. applets) that shouldn’t be forgotten when planning secure deployments.

The recurring theme in her manifesto is the notion that certain software suppliers are “too big to test”. It’s fine for the little guys, but not the 800-pound gorillas. Instead, software purchasers should blindly trust companies with security teams and assurance processes to produce secure code. If only it were that simple. In fact, according to our semi-annual State of Software Security Report, there’s negligible variation in security quality across software suppliers regardless of company size.

We’re both flattered and amused that Ms. Davidson believes our company alone “created a market” for testing the software supply chain. On the contrary, the market has created itself. Take a look through the noteworthy breaches from the past 12-24 months; software vulnerabilities have been the culprit in nearly every case. CISOs are waking up to the stark realization that all software — internally or externally produced — introduces risk into their organizations. In this day and age, wise companies harbor a healthy suspicion of their software vendors. Oracle can choose to do security testing in-house, but a company that’s “running their entire business” on Oracle’s software has a right to request unbiased evidence that the testing process is working.

That being said, Oracle is hardly the poster child for security process. Within the security community, they are notorious for shipping insecure products. Their laughable “Unbreakable” marketing campaign was famously debunked by security expert David Litchfield, who uncovered several critical (and easily avoidable) vulnerabilities within a matter of weeks. They’ve also earned a reputation for glacial response times and sloppy patches. No company can be expected to build perfectly secure software, but it’s pretty obvious why external validation is needed to complement in-house process — one need look no further than ZDI for evidence. Even Ms. Davidson’s own example illustrates how an outsourced service provider “HuiMaika’i” detected multiple vulnerabilities that weren’t discovered by Oracle’s internal team.

Perhaps the most shocking admission about Oracle’s security program is their interpretation of the “need to know” principle. Ms. Davidson asserts that she doesn’t need access to bug databases. This is a classic liability avoidance move and one that we’ve witnessed in other organizations as well. Creating barriers to vulnerability information facilitates a culture in which the executive has plausible deniability of critical bugs and can simply look the other way if a ship deadline is looming or if the auditors pay a visit. CISOs should be clamoring for as much data as they can get their hands on, not eschewing it.

Finally, Ms. Davidson seemed offended that a tenured university professor would suggest licensing software developers to create a system of accountability. Ironically, only a few years ago, she sent a letter to top universities pressuring them to incorporate secure coding guidelines such as the SANS coding certification into their curriculums. She told them, “We will start making our purchasing decisions, if you will, based on that.” Apparently, it’s OK for Oracle to flex their muscle when “buying” (i.e. hiring) from universities, but it’s not OK for Oracle’s customers to hold them to similar standards? It certainly sounds like Oracle has been feeling the pressure lately.

There are third-party tests and assessments for perhaps every important purchase in business or in our personal lives. Companies hire law firms and specialists when they make acquisitions. People look to safety and quality tests from trusted sources before they buy everything from baby strollers to cars. You wouldn’t think of buying a home without a home inspection. In each case, the cost of the independent test must be commensurate with the purchase price and the risk. Look at the typical due dilligence around home purchase. It doesn’t always make sense to pay an engineering firm thousands of dollars for a structural analysis, but it does make sense to hire a home inspector for a few hundred dollars, who in a few hours can uncover termites or a leaking roof. These are problems that must be fixed, and because the testing cost is so low it would be negligent not to do it. Most of the major software vendors have participated in third-party testing either as part of their SDLC, to vet code they were acquiring or licensing, or as part of one of their customers’ procurement process.

Veracode has never claimed that binary SAST provides complete software assurance. From the beginning, we have recommended multiple testing methods to detect vulnerabilities that static automation can’t. In fact, it’s impossible to receive our top ratings without a clean bill of health from a manual penetration test. Each layer of testing, while imperfect on its own, uncovers problems that must be corrected.

Outsourcing is not a dirty word. Many companies outsource development for entire products or components of them. Companies also outsource testing and training. The multi-billion dollar IV&V market grew out of this need — it’s simply good business. The goal is shipping secure code, not making a feel-good proclamation that your team can handle a modern development challenge with no outside help. While Oracle can be proud that they have tamed a source code tool and lived to tell the tale, other companies are securing their code faster and cheaper with the help of outsourcing. Even Veracode customers haven’t fully outsourced security; many of them have in-house security expertise and are just employing a service to make their security processes more robust. They are still full participants in the process, making decisions around how/when to remediate, how much to invest, etc. Veracode acts as an application security partner, providing customers valuable intelligence gleaned from the software ecosystem. Just as Google gets smarter with every search that it does, Veracode gets smarter with every scan we do.

At least we can rest easy knowing that Oracle would never hire lobbyists to promote an agenda. That’s a relief!

Veracode Security Solutions

Security Alternatives

Security Threat Guides

The blog post we made earlier this week entitled, Mobile Apps Invading Your Privacy, gives detail around the information being requested by the advertisement libraries embedded inside a popular online radio application. There have been a number of great posts and comments that got us thinking more about the issues and the types of data being requested.

First off we want to thank some people who commented about the Pandora application not having permission to actually access the GPS on the device. Below are the Manifest permissions for the version of Pandora currently in the Google Application Marketplace:

• Full Internet Access
• Create Bluetooth Connections
• Read Contact Data
• Add or Modify Calendar Data and Send Emails to Guests
• Read Phone State and Identity
• Modify Global System Settings
• Prevent Device from Sleeping
• Bluetooth Administration
• Change Wifi State
• Change Network Connectivity

As you can see, GPS access is NOT included in that list. There was an error in the original post we made stating that some of the library code was requesting permissions from the Google system for GPS access, and as the commenter pointed out, that is incorrect. The code snippet we posted is only checking whether the parent application, Pandora in this case, has permission to access the GPS. If the parent does not have permission, the accessing of GPS data can’t occur.

However, the overarching theme of the original post is still valid. If Pandora had required GPS access for a legitimate reason, the embedded advertisement library would have been able to request the GPS data and send it off device. As we mentioned in the original post, there is a chance that Pandora has no idea what the embedded advertising library actually does, simply taking it from the advertising partner and embedding it into their application.

To further illustrate this point, we downloaded a few more applications that use some of the same advertising libraries. In particular, we found AdMob (the code snippets we outlined on the previous post) embedded into the free CBS News Android application and the TVDotCom application. Both of these applications have GPS coarse and fine permissions allowed within their application manifest. They don’t have some of the other permissions required to send certain data, but in these cases the advertising code will fail silently. Essentially, the advertising libraries use the parent application as an enabler, taking advantage of whichever permissions happen to be available. It also seems revelant to note that AdMob was acquired by Google in May 2010.

The current model where permissions are granted to applications combined with the way 3rd party libraries such as mobile ad network libraries request many different types of information sets up a situation where the ad network will get the information if the application needs it to operate.

Veracode Security Solutions

Security Threat Guides

Background

An article in the Wall Street Journal, dated April 5, 2011, disclosed that Federal prosecutors in New Jersey are investigating numerous smart phone application manufacturers for allegedly, illegally obtaining and distributing personal private information to third party advertisement groups. The allegations state that mobile applications are gathering data such as GPS location, device identifiers, gender, and even user age without proper notice or authorization from the end user. The Journal tested 101 applications and found that 56 of them transmitted the device unique identifier off the device, while 47 transmitted the phone’s location. Five of the tested applications leaked personal information such as user gender and age.

Analysis

The folks at the Veracode research team decided to spend a bit of our time today breaking apart one of the accused applications to see what could be found within the code. Given what was written in the Journal article, we thought it would be most interesting to take an in-depth look through the Pandora application for the Android platform. A quote from the article states the following about the Pandora application:

In Pandora’s case, both the Android and iPhone versions of its app transmitted information about a user’s age, gender, and location, as well as unique identifiers for the phone, to various advertising networks. Pandora gathers the age and gender information when a user registers for the service.

Our first step was to analyze the application using the Veracode platform. We followed up the automated static analysis with a manual analysis of the compiled dex code. The results were fairly interesting. The Pandora for Android application appears to be integrated with a number of advertising libraries. Specifically we found FIVE (yes that’s FIVE!) advertisement libraries compiled into the application: AdMarvel, AdMob, comScore (SecureStudies), Google.Ads, and Medialets. Looking even closer, we analyzed each of the modules to determine the type of data they access.

The first library we decided to break apart was the AdMarvel and AdMob libraries. The AdMarvel library references the AdMob library fairly significantly. AdMob in particular accesses the GPS location, application package name, and application version information. Additionally there were variable references within the ad library that appear to transmit the user’s birthday, gender, and postal code information. The code snippets below are taken from a decompilation of the AdMob library where GPS locations are being gathered. As you can see in the code, the library requests permissions for both COARSE_LOCATION, and FINE_LOCATION data:

public static Location getCoordinates(Context unknown)
{
.... SNIP ....
        String str1 = "android.permission.ACCESS_COARSE_LOCATION";
        int m = unknown.checkCallingOrSelfPermission(str1);
.... SNIP ....
        String str2 = "android.permission.ACCESS_FINE_LOCATION";
        int n = unknown.checkCallingOrSelfPermission(str2);

We can also see where the library actually attempts to capture GPS location information on a continuous looping mechanism:

        int i4 = Log.d("AdMobSDK", "Trying to get locations from GPS.");
        localObject2 = (LocationManager)unknown.getSystemService("location");
        if (localObject2 == null) break label428;
        Criteria localCriteria = new Criteria();
        localCriteria.setAccuracy(1);
        localCriteria.setCostAllowed(0);
        localObject3 = ((LocationManager)localObject2).getBestProvider(localCriteria, 1);
.... SNIP ....
        int i5 = Log.d("AdMobSDK", "Cannot access user's location.  Permissions are not set.");
.... SNIP ....
        int i6 = Log.d("AdMobSDK", "No location providers are available.  Ads will not be geotargeted.");
.... SNIP ....
        if (Log.isLoggable("AdMobSDK", 3)) int i7 = Log.d("AdMobSDK", "Location provider setup successfully.");
        AdManager.1 local1 = new AdManager.1((LocationManager)localObject2);
        Looper localLooper = unknown.getMainLooper();
        ((LocationManager)localObject2).requestLocationUpdates((String)localObject3, 0L, 0.0F, local1, localLooper);

We also saw references to the user’s gender:

        Object localObject = k; Gender localGender1 = Gender.MALE;
        if (localObject == localGender1)
       {
            localObject = "m";
       } while (true) {
      return localObject;

      Gender localGender2 = k;
      Gender localGender3 = Gender.FEMALE;
      if (localGender2 == localGender3) { localObject = "f"; continue; }
      localObject = null;

And of course, access of the infamous Android ID value (android_id):

      if (f == null) { Object localObject1 = unknown.getContentResolver();
      localObject2 = localObject1;
      localObject1 = Settings.Secure.getString((ContentResolver)localObject2, "android_id");

The analysis into the remaining libraries resulted in even more of the same. The SecureStudies library accesses the android_id and directly sends a hash of the data to http://b.scorecardresearch.com while the Medialets library accesses the device’s GPS location, bearing, altitude, android_id, connection status, network information, device brand, model, release revision, and current IP address.

Conclusion

So what does this mean to the end user? It means your personal information is being transmitted to advertising agencies in mass quantities. As more and more “free” applications attempt to monetize their offerings, we will likely see more of your personal information being shuttled out to marketing and advertising data aggregation firms. The application developers may not even be aware of the privacy violations they are introducing by using third party advertising libraries. They may merely think they are getting $x per ad impression, not that the ad library is leaking significant information about the user.

In isolation some of this data is uninteresting, but when compiled into a single unifying picture, it can provide significant insight into a persons life. Consider for a moment that your current location is being tracked while you are at your home, office, or significant other’s house. Couple that with your gender and age and then with your geolocated IP address. When all that is placed into a single basket, it’s pretty easy to determine who someone is, what they do for a living, who they associate with, and any number of other traits about them. I don’t know about you, but that feels a little Orwellian to me.

Veracode Security Solutions

Security Threat Guides

When a debugger or reverse engineer tries to get aggressive and hook calls to anti-debugging related APIs we can move lower than the API and directly access the process and thread information to detect the attached debugger. By side stepping the operating system provided methods for querying process and thread information, we can effectively bypass some API based hooking techniques used in anti-anti-debugging efforts.

For example, in part II of this anti-debugging series I demonstrated how to make a call to IsDebuggerPresent() to detect if the debugger present process flag is set.

Prototype: BOOL WINAPI IsDebuggerPresent(void); 

if (IsDebuggerPresent()) {
    //Debugger Detected - Do Something Here
} else {
    //No Debugger Detected - Continue
}

If we analyzed what this API call actually does we would notice that it reads a flag from the PEB which indicates the presence of a debugger. Instead of directly calling the API, it is possible to emulate what the IsDebuggerPresent() function does and directly query the PEB ourselves.

The first step in analyzing data within the PEB structure is to locate the PEB structure in memory. To do this we can use a number of different methods, some more direct and low level that others. The method that is easiest to grasp is to call the function NtQueryInformationProcess with a second parameter of ProcessBasicInformation. This returns a pointer to the process information block (PIB) for the requested process. Once we have access to this PIB structure we look at the PebBaseAddress member to determine the base address of the PEB. Finally, we look at the boolean member BeingDebugged to return the same result that would be returned had we called the function IsDebuggerPresent().

The following code demonstrates our example:

hmod = LoadLibrary(L"Ntdll.dll");
_NtQueryInformationProcess = GetProcAddress(hmod, "NtQueryInformationProcess");

hnd = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, GetCurrentProcessId());
status = (_NtQueryInformationProcess) (hnd, ProcessBasicInformation, &pPIB, sizeof(PROCESS_BASIC_INFORMATION), &bytesWritten);

if (status == 0 ) {
  if (pPIB.PebBaseAddress->BeingDebugged == 1) {
    MessageBox(NULL, L"Debugger Detected Using PEB!IsDebugged", L"Debugger Detected", MB_OK);
  } else {
    MessageBox(NULL, L"No Debugger Detected", L"No Debugger Detected", MB_OK);
  }
}

There are a number of different ways that we can query the PEB and TIB blocks to detect the presence of a debugger. Let’s divert from the straight forward and instead look at a novel and interesting method of detecting a debugger specifically designed to operate under Windows Vista. In Vista, when a process is started without a debugger present, the main thread environment block contains a pointer to a Unicode string referencing a system DLL such as kernel32.dll. If the process is started under a debugger, that system DLL name is replaced with the Unicode string “HookSwitchHookEnabledEvent”. Thus if we know that the process we are trying to protect is running within a Windows Vista environment, we can use this technique to determine if the processes was launched from within a debugging environment.

To use this technique, the anti-debugging function should first check that it is running on the Windows Vista operating system. After confirming the operating system revision, the technique should locate the TIB. The TIB can be accessed as an offset of segment register FS as in the following code:

void* getTib()
{
  void *pTib;
  __asm {
    mov EAX, FS:[18h] //FS:[18h] is the location of the TIB
    mov [pTib], EAX
  }
  return pTib;
}

Once the location of the TIB is found, the offset 0xBFC from the start of the TIB is read and the pointer checked. If this value is 0x00000C00 we then read the string at offset 0xC00 and compare this value to the Unicode string “HookSwitchHookEnabledEvent”. We check the pointer to ensure that we have a string located in the pointed to address and as a second level of assurance for the accuracy of this method. If we pass this final test we can be sure that our process running under Windows Vista was started from within a debugger.

wchar_t *hookStr = _TEXT("HookSwitchHookEnabledEvent");
strPtr = TIB+0xBFC;

delta = (int)(*strPtr) - (int)strPtr;
if (delta == 0x04) {
   if (wcscmp(*strPtr, hookStr)==0) {
      MessageBox(NULL, L"Debugger Detected Via Vista TEB System DLL PTR", L"Debugger Detected", MB_OK);
    } else {
      MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
    }
} else {
   MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
}

In the four parts of this series we have discussed classes of anti-debugging methods, a few basic API based anti-debugging techniques, some slightly more advanced API techniques, and finally two methods that directly access process and thread information to detect the presence of a debugger.

Instead of continuing this series in blog format, I’ve decided to release a paper outlining the details of nearly 35 different anti-debugging methods. I’ll be presenting the paper (and associated slides) at the SOURCE Boston 2009 security conference which starts March 11th, 2009 and finishes up March 13, 2009. The paper and presentation are geared towards developers and software engineers who may not understand the assembly dump of some anti-debugging code but can understand what I’ve presented to you thus far.

The pre-registration rates for SOURCE Boston end on February 28, 2009. So get your ticket at a discount while you still can! It’s going to be a fantastic conference with some of the best information security topics and presenters in the industry.

Additionally, as a speaker, I’ve been given one ticket at half price to do with as I choose. As of yet I haven’t given it away. If anyone would like a half off ticket to SOURCE Boston and can attend please let me know. I’ll get the discount code over to you ASAP. I look forward to seeing you all at the conference, please come up and say hello!

Veracode Security Solutions

Security Threat Guides

Advanced API Based Anti-Debugging

There are a number of functions and API calls within the Windows operating system that are considered internal to the operating system and thus not documented well for the average developer. Many of these functions have undergone extensive research and reverse engineering to be able to understand how they operate and what can be achieved using them. One such poorly documented API function is the NtQueryInformationProcess function which is used to retrieve information about a target process. The function prototype looks like the following:

NTSTATUS WINAPI NtQueryInformationProcess(
    __in HANDLE ProcessHandle,
    __in PROCESSINFOCLASS ProcessInformationClass,
    __out PVOID ProcessInformation,
    __in ULONG ProcessInformationLength,
    __out_opt PULONG ReturnLength
);

This function resides within the Ntdll.dll file and is not an exported function. Because of this, we must use run-time dynamic linking to gain access to the functionality. Run-time dynamic linking is the dynamic loading of a library and mapping of functions within the library to a function pointer allowing it to be called and executed. To load our function, “NtQueryInformationProcess”, we first call LoadLibrary(“ntdll.dll”) and then execute GetProcAddress(HMODULE, “NtQueryInformationProcess”) to receive a pointer to our required function.

HMODULE hmod;
FARPROC _NtQueryInformationProcess;
hmod = LoadLibrary(L"ntdll.dll");
_NtQueryInformationProcess = GetProcAddress(hmod, "NtQueryInformationProcess");

Note: The dynamic linking method is slightly different when using C++ due to declaration differences.

Once we have a function pointer to the NtQueryInformationProcess function, we can call the API. The function call takes five parameters, the first two of which are the most interesting to our anti-debugging efforts. The first parameter is a HANDLE to the target process that we wish to interrogate. Since we are trying to determine information about our own process, we will use a HANDLE that points to ourselves. By default, a HANDLE value of -1 will instruct the function to use the current process as the target. The second parameter is a value indicating what type of information is being requested from the target process. In the Microsoft MSDN documentation there are four documented values for this parameter ProcessBasicInformation (0), ProcessDebugPort (7), ProcessWow64Information (26), and ProcessImageFileName (27). There are other undocumented values that can be passed in, some of which allow for interesting anti-debugging techniques, however we will focus on the ProcessDebugPort (7) value. This value, when used as the second parameter in the NtQueryInformationProcess function will return a DWORD, returned in the address of the third parameter, indicating the DebugPort that is currently available for the process. If a non-zero value is returned, indicating that a DebugPort exists, we can be sure that a debugger is attached and act accordingly.

status = (_NtQueryInformationProcess) (-1, 0x07, &retVal, 4, NULL);

if (retVal != 0) {
    //Debugger Detected - Do Something Here
} else {
   //No Debugger Detected - Continue
}

The second anti-debugging method we will look at today also uses run-time dynamic linking of the Ntdll.dll library along with GetProcAddress() to gain access to the NtSetInformationThread function. This function’s primary purpose is to modify thread specific data for a targeted thread.

NTSTATUS NTAPI NtSetInformationThread(
    __in HANDLE ThreadHandle,
    __ in THREAD_INFORMATION_CLASS ThreadInformationClass,
    __in PVOID ThreadInformation
    __in ULONG ThreadInformationLength
)

For the anti-debugging use of this function we are again only interested in two particular parameters. The first parameter is an identifier to the thread we wish to target and the second parameter is the particular information we wish to modify on the target thread. To get a pointer to our current thread we will use a call to GetCurrentThread(). We will submit that as the first parameter and the enum value for ThreadHideFromDebugger, 0x11, as the second parameter. If a debugger is attached and we pass in 0x11 to NtSetInformationProcess, our process will immediately detach any attached debugger and terminate the process.

lib = LoadLibrary(L"ntdll.dll");
_NtSetInformationThread = GetProcAddress(lib, "NtSetInformationThread");

(_NtSetInformationThread) (GetCurrentThread(), 0x11, 0, 0);

MessageBox(NULL, L"Debugger Detached", L"Debugger Detached", MB_OK);

Many of the Microsoft API calls are intentionally not well documented to discourage their use/abuse. In this case we can make calls to two non-exported functions within the Ntdll.dll library to achieve our goals of detecting or detaching a debugger from our process. There are a number of other methods of API based anti-debugging, feel free to comment about them below.

Stay tuned for our next installment as we touch on process and thread block anti-debugging.

• API Based Anti-Debugging
• Exception Based Anti-Debugging
• Process and Thread Block Anti-Debugging
• Modified Code Anti-Debugging
• Hardware and Register Based Anti-Debugging
• Timing and Latency Anti-Debugging

Basic API Anti-Debugging

We’ll continue this series of posts by going into a bit more depth on the easiest of API based anti-debugging techniques. An application programming interface (API) is used to support requests made from other applications for resources or functionality within a target service or library. In our case we will be primarily focused on the Microsoft Windows operating system API. There are a number of calls built directly into the operating system API that make detection of a debugger possible. Minor differences in thread and process meta-data is present when processes are run within a debugger. These calls typically facilitate a process or thread examination technique in order to determine if the target thread has a debugger attached.

When learning about anti-debugging, a developer will typically first be introduced to the IsDebuggerPresent() function. This function analyzes the process block of a target process to determine if the processes is running under the context of a debugging session. We’ll save the details of how this actually works for a later article, however suffice it to say that the target process has a flag that will contain a non-zero value if the process is being debugged. This flag is queried and returned when IsDebuggerPresent() is called. A very basic debugging detection routine would be to call this function and execute different code paths based on the response.

Prototype: BOOL WINAPI IsDebuggerPresent(void); 

if (IsDebuggerPresent()) {
    //Debugger Detected - Do Something Here
} else {
    //No Debugger Detected - Continue
}

We could also use the API function CheckRemoteDebuggerPresent(). Contrary to first thought, this function does not target a process on a remote machine, nor does it even require that it target a process remote to itself. The call can use a parameter pointing to itself to determine if it is running inside of a debugger. In the example below we pass in a handle to our current process by calling the GetCurrentProcess() function along with a variable to hold the return value from the CheckRemoteDebuggerPresent() call.

Prototype: BOOL WINAPI CheckRemoteDebuggerPresent(__in HANDLE hProcess,
           __inout PBOOL pbDebuggerPresent);

BOOL pbIsPresent = FALSE;
CheckRemoteDebuggerPresent(GetCurrentProcess(), &pbIsPresent);
if (pbIsPresent) {
    //Debugger Detected - Do Something Here
} else {
    //No Debugger Detected - Continue
}

While these two methods are probably the easiest and most straightforward methods of anti-debugging, they are also the most likely to be understood by a person wishing to bypass them. We can mix it up a bit and use a call to OutputDebugString() instead. OutputDebugString() is typically used to output a string value to the debugging data stream. This string is then displayed in the debugger. Due to this fact, the function OutputDebugString() acts differently based on the existence of a debugger on the running process. If a debugger is attached to the process, the function will execute normally and no error state will be registered; however if there is no debugger attached, LastError will be set by the process letting us know that we are debugger free. To execute this method we set LastError to an arbitrary value of our choosing and then call OutputDebugString(). We then check GetLastError() and if our error code remains, we know we are debugger free.

Prototype: void WINAPI OutputDebugString(__in_opt  LPCTSTR lpOutputString);

DWORD Val = 123;
SetLastError(Val);
OutputDebugString(L"random");
if(GetLastError() == Val) {
    //Debugger Detected - Do Something Here
} else {
    //No Debugger Detected - Continue
}

These three methods are the basic starting point for a developer wishing to implement anti-debugging into their code base. The methods are so simple they could even be implemented as macros making a call quick and easy. Numerous other API based detection methods exist with a vast array of complexity. In the next post in this series we will discuss slightly more advanced API anti-debugging techniques that will make reverse engineering and debugging even more difficult.

Veracode Security Solutions

Security Threat Guides

Before we delve into the intricacies of individual methods of anti-debugging let’s use this post to define the classes of anti-debugging that we will be discussing. While other classes may exist, the definition of these classes is an attempt to include the majority of anti-debugging methods in use today. There is some overlap between classifications and we may have left out some methods due to limited exposure or effectiveness.

API Based Anti-Debugging
API based anti-debugging is the most straightforward and possibly the easiest to understand for a typical developer. Using both documented and undocumented API calls, these methods query process and system information to determine the existence or operation of a debugger. From single line calls such as IsDebuggerPresent() and CheckRemoteDebugger() to slightly more complex methods including debugger detaching and CloseHandle() checks. These methods are generally trivial to add to an existing code base and many can even be implemented in as few as two or three lines.

Exception Based Anti-Debugging
Exception based anti-debugging is slightly different than your basic API based techniques. Many times when a debugger is attached to a process, exceptions are trapped and handled by the debugger without regard to passing the exception back to the application for continued execution. Occasionally these exceptions can even crash or terminate a process when run under a debugger and be handled gracefully when running clean. It is these discrepancies that makes exception based anti-debugging techniques possible.

Process and Thread Block Anti-Debugging
Some of the API based anti-debugging methods use published functions to query information from within the process and thread blocks for our running code. Many API based detections can be subverted within a debugger by hooking the API call and returning values that indicate a clean process. One way around this subversion is to directly query the process and thread blocks, bypassing the API calls. Direct analysis of the process and thread blocks, while more complex, can lead to a more accurate and high assurance result.

Modified Code Anti-Debugging
One of the methods that a debugger uses to signal a breakpoint is to insert a break byte into the running code at the location that it wishes to stop execution. The process execution breaks when this value is seen, giving control to the debugger. When the program is resumed, the breakpoint value is removed and replaced with the original byte, the execution backed up one byte, and the program is resumed. Detection of software based breakpoints can be achieved by analyzing the process for modifications from the expected norm.

Hardware and Register Based Anti-Debugging
A second way that a debugger can break the execution of a process is by using a hardware breakpoint. A hardware breakpoint relies upon CPU registers to store the pertinent information and to detect when the target break addresses are seen on the bus. A break interrupt is triggered at the appropriate time based on these register values. Reading or modifying the hardware can allow for the detection of a debugger.

Timing and Latency Anti-Debugging
Finally timing and latency can be used as an effective anti-debugging method. When executing a program within a debugger, specifically when single stepping, a much larger latency occurs between execution of instructions. This latency can be detected and compared against a reasonable threshold to detect the existence of a debugger attached to our process.

Each of the classes of anti-debugging outlined above has merit when used individually to protect a process. While none of them can be assured to ever protect a program from a determined reverse engineer or debugger, implementation of these techniques (or many of them if appropriate) can sufficiently slow down the debugging process and hopefully make the attacker spend his time on other, easier, ventures. In the remainder of this series on anti-debugging we will review in depth some of the more interesting methods of each of the above classes. So bring along your debugger and your development environment and let the games begin.

My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned (here is a more accurate report). It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex‘s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

The event was held at Die Insel, on a tiny island a few kilometers outside of Berlin’s city center, near Treptower Park. The venue is mostly used for live music so basically it feels like a dark, somewhat dingy club (certainly the bathrooms are reminiscent of a club). The presentations were on the 3rd floor in a room that probably held about 60 people in close quarters; to handle overflow, a closed-circuit feed was being simulcast on the 4th floor, which was a bit less crowded and, more importantly, opened out onto a rooftop deck which meant better ventilation. The bottom floor led out to a Biergarten with tables, beach chairs, and a stage which was used for DJing. The layout was actually pretty efficient for allowing around 200 people to mill about and socialize/network while not having to stray too far from where the talks were presented.

As far as the event itself, when I said “laid back” earlier, don’t interpret that to mean disorganized or watered down in any way. It was run with stereotypical German efficiency, from badging to presentations to the after-hours parties. The presentations were just as technical and relevant as any of the more “corporate” conferences. Unfortunately for me, I don’t know that many people in European security circles, and most of the ones I do know weren’t in attendance. Those I did meet, however, were impressively smart and well-versed. Nobody was trying to conduct business transactions or slip away for meetings, which is inevitably what happens when only technical folks are present!

For me, a few talks stood out. Fukami and BeF’s talk on SWF and the Malware Tragedy discussed methods for automated static detection of malware in Flash movies. Much of it centered on heuristics related to inconsistencies in the file format or tag structure, abnormal concentrations of strings in the constant pool, or the existence of various obfuscation techniques. Ultimately, there are false positive issues to be addressed but that is just a fact of life with static analysis, and it will be an iterative process to refine those heuristics as the attack vectors evolve. I thought this talk was particularly timely given the increasing prevalence of Flash as a conduit for exploits/malware, such as the most recent Flash 0day that made the news (granted, this was an exploit against Flash itself, not just using Flash as a delivery mechanism, but close enough).

I also enjoyed pierre’s talk on counterintelligence, basically a mélange of wiretapping and other bugging devices discovered in the wild. War stories are always interesting, particularly when it comes to the realm of physical security. One of the x-ray images he showed of a bugged pen was identical to a pen that I own (minus the bugging device of course… I hope). The feel of the talk reminded me a bit of James Atkinson’s talk at SOURCE, “Telephone Defenses Against the Dark Arts” (video: Part 1 and Part 2), which also got rave reviews.

Mike Eddington’s presentation on the Peach 2 fuzzing framework was also quite interesting. Peach 2 was released several months back but I haven’t really been paying much attention to it or any other fuzzing tool for some time. In fact the last time I really had to implement a protocol fuzzer, I was using SPIKE 2.9, so that gives you some indication of how long it’s been. Peach 2 includes some powerful built-in capabilities such as node relationships (e.g. field 1 represents the length of field 2; field 10 is a CRC-32 of fields 1 through 9), data transforms (those with battle scars from ASN.1 will be happy), state machines (packets 1 and 2 have to be normal in order to fuzz packet 3), monitoring agents (detecting when a crash happens and under what conditions), and much more. I am itching to go fuzz something now just so I can tinker with Peach.

All in all, it was a good trip and I enjoyed the opportunity to see how things are done across the pond, and to do a little sightseeing in a historic and beautiful city.