This afternoon, the MSRC posted a security advisory describing a newly-disclosed vulnerability in the IIS FTP service that could potentially grant remote code execution to untrusted users. You can find the advisory here.
Vulnerability summary
The vulnerability is a stack overflow in the FTP service when listing a long, specially-crafted directory name. To be vulnerable, an FTP server would need to grant untrusted users access to log into and create that long, specially-drafted directory. If an attacker were able to successfully exploit this vulnerability, they could execute code in the context of LocalSystem, the service under which the FTP service runs.
Configurations at risk
The vulnerable code is in IIS 5.0 (Windows 2000), IIS 5.1 (Windows XP) and IIS 6.0 (Windows Server 2003). IIS 7.0 (Windows Vista, Windows Server 2008) is not vulnerable. IIS 6 is at reduced risk because it was built with /GS which help protect the service from exploits by deliberately terminating itself when the overflow is detected before attacker’s code runs. We have not seen exploit code for this vulnerability that is able to bypass the /GS protection.
Also, remember that only servers that allow untrusted users to log on and create arbitrary directories are vulnerable.
Protecting your servers
The advisory lists several options to protect your servers from this vulnerability until a fully-tested security update is available. The end result of the workarounds is to prevent untrusted users from having write access to the FTP service. The options presented in the advisory include:
- Turn off the FTP service if you do not need it
- Prevent creation of new directories using NTFS ACLs
- Prevent anonymous users from writing via IIS settings
The IIS Manager setting to prevent Write access can be found on the following dialog in IIS 5.
The IIS team’s best practices FTP guidance can be found at http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/7b4bdad5-9a0a-4bf6-8b00-41084b783e20.mspx?mfr=true
Detecting attacks
We expect several of our MAPP partners with network-based detection and protection to be able to identify and potentially prevent attacks. For example, you can find snort rules available already at http://www.snort.org/vrt/docs/ruleset_changelogs/changes-2009-09-01.html.
You can also detect attacks yourself by examining logfiles. The exploit issues several commands followed by very long strings. The FTP service, by default, logs commands issued. For example, here is a sample log entry from pointing the proof-of-concept code at an internal server:
#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 1111-01-01 22:45:13
#Fields: time c-ip cs-method cs-uri-stem sc-status
22:45:13 169.254.117.152 [1]USER anonymous 331
22:45:13 169.254.117.152 [1]PASS password 230
22:45:13 169.254.117.152 [1]MKD JUNK@ÿàC~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñúEEEE›±ôw~ñúHHHHIIII~ñúJKKKécþÿÿNNNN 257
You can find these log files, by default, in c:\winnt\system32\logfiles\MSFTPSVC1. If you currently store logfiles on the same machine as the vulnerable service, you may want to reconfigure the service to store them elsewhere to prevent an attacker from cleaning up the logfiles.
We’d like to thanks Wade Hilmo and Nazim Lala from the IIS team for providing information for this blog post. Brian Cavenah from the MSRC Engineering team also was very helpful in this investigation. Thanks guys!
- Bruce Dang and Jonathan Ness, MSRC Engineering team
*Posting is provided “AS IS” with no warranties, and confers no rights.*