Security Hole in Windows Web Servers
Wednesday, July 1, 1998 by Dave Winer.
There's a serious security hole in Windows as a web server platform.
If you run a Netscape or O'Reilly web server your LAN might be open to easy hacking. This was first reported on Saturday on News.com. And yesterday it was revealed that Java running on Windows has the same problem.
http://www.news.com/News/Item/0,4,23747,00.html?st.ne.fd.mdh
The vendors are moving too slowly. The Sun spokesperson blamed Microsoft, and also (wrongly!) pointed the finger at their users, saying it's bad practice to put passwords in scripts. But where are they *supposed* to put them? And even if it's bad style according to Sun, they're there and the customers are at risk, and why aren't moving more quickly?
Are you at risk? 
Your network is at risk if:
- You're running a web server on a Windows machine. (This problem isn't there on the Mac OS or Unix, as far as I know.)
- You have .asp pages, or other kinds of scripts, on your site, in the directory that your website is served from.
- Those scripts contain passwords that open protected resources, like databases that contain credit card information, medical records or nuclear secrets.
The trick
Here's the trick a hacker would use.
Let's say the URL of a dynamic page on your site is:
www.myCompany.com/logon.asp
The hacker would enter this URL:
www.myCompany.com/logon.asp.
Note the extra period at the end of the URL. This is enough to convince the web server that it's not an active server page.
But you'd think the server would return a 404 Not Found error (it should) because the file with the trailing period doesn't exist. But the "problem servers" depend on the Windows file system to behave in a more sensible way (it doesn't). Windows strips off the trailing period, and returns the source code of the script, and the server sends the code out over the Internet. Ouch!
By the way, it's not just .asp files that are vulnerable, the loophole can expose the source code of Perl scripts or server-side Java code, basically any script code that's stored in a file in the web server doctree.
Shaky ground
The source of the problem is so low-level that any Windows web server that doesn't work around the problem is open to the security hole.
O'Reilly and Sun are on shaky ground when they give the blame to Microsoft. One of the things web server software is supposed to offer is reasonably clear and understandable access controls to the system manager. There are two failures here, one belongs to Windows, for sure. And the other belongs to the server vendor.
Anyway, no matter who's to blame, the hacker gets your passwords, and may be able to use them to gain access to other resources. Assume the worst! It could be pretty bad.
If I were Microsoft
If I were Microsoft, I'd issue a broad public statement right now, warning Windows web server admin people to shut down their systems and review the contents of their site to be sure that they aren't broadcasting passwords to the outside world.
If I were a server vendor like Sun or O'Reilly, both of whom have publicly pointed the finger at Microsoft, I'd withdraw those statements, forget about blame, protect your customers, and get a fix out, right now, this morning. And let all your users know that if this ever happens again, the response will ship within hours not days.
This is serious stuff and it requires a serious response.
A question for Microsoft
The problem doesn't effect Microsoft's IIS web server because they closed the hole in February 1997. Now here's the question.
Was there adequate notice to the other server vendors when this hole was detected and closed in Microsoft's server?
If not, remember that people who use other servers on Windows are also Microsoft customers and (another question) they deserve better, don't they?
By the way, some people feel the fix should come in Windows, but I don't agree. Windows existed before web servers were popular and is used for lots of things that don't involve URL resolution. Who knows why Windows has this strange behavior? Maybe if they closed the hole it would break other software? Probably so.
Some situations, like this one, transcend competition. It's in every vendor's interest to side with the customers here, put competitive issues aside, and work together to solve this problem quickly.
Dave Winer