Apache/2.0.45 released to counter Denial of Service vulnerability

The Apache Project have announced that versions of Apache/2.0 up to and including Apache/2.0.44 are vulnerable to a denial of service attack. To fix the problem, the project has released Apache/2.0.45 which is available for download.

People running Apache servers should note that the vulnerability only applies to Apache/2.0 and not Apache/1.3. In this respect the bug is not a big threat to the stability of the web - it is a denial of service rather than a remote compromise and the number of sites running Apache/2.0 is relatively small. Almost 99% of Apache sites are on Apache/1.3 or earlier.

Windows 2000 Exploits Published and Generalised

Further to our article on the widespread availability of WebDAV on Microsoft-IIS/5.0 sites, Roman Medina and Rafael Nunez have each published the sources to programs written to exploit the vulnerability.

Additionally, David Litchfield has produced a paper emphasizing that the problem is a core DLL in Windows 2000 that is possible to exploit without recourse to the published Microsoft-IIS WebDAV vulnerability.

Expert opinion is that no unpatched Windows 2000 machines are safe.

Netcraft's network exploration services may be useful for people managing large networks of Windows 2000 servers. In particular, we can report machines not yet rebooted since the availability of Microsoft's patch and determine availability of WebDAV functionality on those machines.

Please mail us if interested.

Three quarters of Microsoft-IIS sites have WebDAV enabled


On 17th March Microsoft issued a security alert regarding a buffer overflow vulnerability which allows attackers to execute arbitrary code on Windows 2000 machines. The vulnerability is triggered by the Microsoft-IIS/5.0 implementation of the World Wide Web Distributed Authoring and Versioning (WebDAV) protocol and is specific to Microsoft-IIS/5.0 - WebDAV was not supported in Microsoft-IIS/4.0, and Microsoft-IIS/6.0 is reported to be unaffected.

Microsoft-IIS/5.0 runs about 9 million web sites on just over 1 million ip addresses, making it the most widely deployed web server that has WebDAV enabled by default. Many sites disable WebDAV: best practice dictates that features that are not used should be disabled, and the IIS Lockdown tool recommended by Microsoft can disable WebDAV. However, although the number of sites that have disabled WebDAV is significant, our own data indicates that around three quarters of Microsoft-IIS/5.0 servers have WebDAV enabled, implying that at the time of announcement there were over 6 million vulnerable web sites.

The actual vulnerability occurs in a system DLL called by the WebDAV component, not in the WebDAV support itself. There may be ways to exploit this vulnerability via other components, or even other products. There is believed to be an exploit already in the wild for this vulnerability, and Windows 2000 administrators should apply the patch as soon as possible. CERT have issued an advisory (CA-2003-09), and Microsoft have issued a patch (see bulletin MS03-007).

The patch requires a reboot to become effective, and we have noticed that over half of the Microsoft-IIS/5.0 servers on the internet were rebooted during a two day period after the annoucement. The number of sites rebooting sets a lower bound on the uptake of the patch [a reboot is necessary as part of the patch installation] but will overstate the number of patched systems, as some sites will have rebooted for other reasons.

Apache on Windows Struggling?


One of the goals of Apache/2.0 was to better support operating systems other than Unix. While the Windows version of Apache/1.3 was advertised as experimental, it was hoped that in Apache/2.0 it would become much more widely established. However, since the first general release of Apache/2.0 there have been a string of security problems in the Windows (and other non-Unix) versions that may undermine confidence in the suitability of Apache for these platforms.

Windows Apache entries listed at mitre.org's common vulnerabilities database include directory traversal using dot-dot paths, revealing script source by appending invalid characters, and DOS device names causing a denial-of-service. The striking thing is that these are sterotypical vulnerabilities that over the years many other products have suffered from, and fixed. Apache developers will be disappointed that they were not able to learn from other people's mistakes sufficiently well to pre-empt the same vulnerabilities appearing in their own server.

In the current month's survey we find over 16,000 Apache Win32 sites on the 'Web which may be vulnerable to one of these problems.

Notwithstanding the security problems, the support for threading in Apache/2.0 is a major performance breakthrough for the Windows version and consquently sites using Apache on Windows have a bigger incentive to upgrade to version 2 than sites on Unix. This is reflected in the relative uptake of Apache/2.0: a little over 1% of all Apache sites are running version 2, but amongst Windows servers the proportion is over 7%.

Security Advisory 2001-11.1 – JRun SSI Request Body Parsing

Vulnerable Products:

JRun Java application server from Allaire. All current versions (with latest security patches as of November 2001) are believed to be affected, including 2.3.3, 3.0, and 3.1.


Revealing of source code to Java Server Pages, and other protected files inside the web root.


Web sites using vulnerable products as stated above

Revision history:

Vendor notified: 22nd October, 2001
Initial security bulletin created: 23rd October, 2001
Vendor workaround released: 27th November, 2001
Security bulletin published: 28th November, 2001


JRun supports a number of different technologies for dynamically generated content, most importantly Java Server Pages. One lesser-used feature is the support for Server Side Includes (SSI); this is a much simpler language than JSP, which is primarily for including the text of other files on the server (for instance adding standard headers or footers to otherwise static pages), and also supports invoking servlets. By default, the file extension .shtml is assigned to the SSI handler.

Unfortunately, a flaw in the server side component that processes requests for SSI pages means that user supplied data can be included in the SSI processing. A remote user can submit requests containing data which will be processed by the SSI filter; as a result the user can cause the server to execute arbitrary SSI code.


When a request for an SSI page is submitted to the server, and the page does not exist, the SSI handler "falls back" on the body of the HTTP request itself. Usually an HTTP request does not contain a body, but a malicious user can easily construct a request with a body containing SSI commands. These can be used to include the source to other files on the server. For example, a request such as:

GET /nosuch.shtml HTTP/1.0
Content Length: 38
<!--#include virtual="/index.jsp"-->

would return the source of the index.jsp page (subject to SSI processing - so servlet tags may be replaced, but most JSP source would be passed through unmodified). It should be noted that the include directive does not go through the usual URL processing - for example includes of .jsp files are not done by the JSP handler, hence the source code to .jsp's can be obtained. It also bypasses any access controls enforced by the web server (so files in protected directories such as the /WEB-INF/ directory can be accessed). However, it was not possible to access files outside of the web root in the cases that Netcraft tested.

Netcraft also verified that it was possible to execute Java servlets on the server using this vulnerability. As it is common to expose these via the /servlet/ URL mapping, this does not give the attacker any new advantage in the normal setup but could be considered a problem by sites that have disabled the /servlet/ mapping.


As a workaround, sites using JRun can disable the SSI support on the web server, as this is not required for any other features of the server including Java Server Pages, so few sites actually require this functionality. This involves both disabling the .shtml extension mapping to SSI handling, and the /servlet/ method of invoking the servlet which does SSI processing (the latter can be done by either disabling the /servlet/ mapping if it is not used, or by blocking access to the particular servlet affected - allaire.jrun.ssi.SSIFilter for JRun 3.x, com.livesoftware.jrun.plugins.ssi.SSIFilter on JRun 2.3.x). See the security bulletin from Allaire for detailed information on making this configuration change.

Vendor Patches and Comments

Allaire have responded promptly to Netcraft's initial report of this problem. They have confirmed that this is a security problem in the JRun versions listed. A patch is expected to be included in the next rollup patch for JRun. In the meantime they have released a security bulletin to notify customers of this problem, and advise a workaround by disabling SSI.


This information is provided on an AS IS basis in the hope that it is useful in securing vulnerable computer systems; however Netcraft cannot guarantee its accuracy or accept responsibility for any damage resulting from the release of this advisory.


This is one of many vulnerabilities tested by Netcraft's security testing services. Please see http://news.netcraft.com/archives/security.html for more information.

Security Advisory 2001-01.1 – Predictable Session IDs

Vulnerable Products:

Java Application Servers based on Sun's reference implementation of the Java Servlet Developers Kit (JSDK 2.0), without enhancements to the session management code, may be vulnerable.

The following products are affected:

Other products may be vulnerable - vendors of such products should check their session management handling, based on the information given below or by contacting Netcraft for further information.

Not Vulnerable:

Products based on JSDK V2.1 (onward), which uses a different algorithm, or products that conform to the 2.x Java Servlet API but use custom session management code.


Hijacking of user sessions


Websites using vulnerable products as stated above

Revision history:

Released to Vendors: 6th November 2000
Public Release: 16th January 2001


Many websites support the idea of user sessions - each user connecting to the site is issued with a unique session ID, which is then used to identify all subsequent requests made by that user, either encoded in the URLs, or as a cookie. The server can then store data for each user session, for instance the state of a web shopping cart. Session IDs are also often used to control access to sites requiring a login; instead of sending the username/password with every request, the site issues a session ID after the user logs on, which identifies the user for the rest of the session.

With some server session management systems, it is possible for a user who can connect to the server and get a session ID, to guess other users' session IDs. If successful, the attacker can then view any page, take any action, post to any form etc, that the real user of that session could.

This attack requires no IP spoofing or session snooping. It works against sites using SSL. Netcraft has successfully proven this attack against machines using cookie-based and URL rewriting-based session management.


From a security point of view, the important properties of a session ID should be that it is unique, and it is not possible for one user to guess another user's session ID.

One way to ensure uniqueness is to include a session counter or timestamp in the session ID. In particular, for the sites we found to be vulnerable, the session ID included:

  • A session counter
  • The IP address of the server
  • A value made by combining the date, session counter, and current system time in milliseconds (we'll call this the timestamp)

This certainly appears sufficient to ensure uniqueness. However, if one user can get this information out of his session ID, he can clearly use it to guess other users' session IDs.

Encoding of Session IDs

For servers Netcraft has identified as vulnerable, the session ID is encoded using a simple rule. 5 bits at a time are taken from the binary session ID; these 5 bits form a number between 0 and 31. Numbers 0-25 are encoded with the corresponding letters A-Z; numbers 26-31 are encoded by the digits 0-5 respectively. It's a kind of "base32" encoding - which can be decoded trivially.

Here's a typical session ID being decoded:

$ echo -n "FGAZOWQAAAK2RQFIAAAU45Q" | ./base32.pl -d
29 81 97 5a 00 00 15 c8 c0 a8 00 01 4f 7e

This breaks up as: (all integers are in network byte order)

  • Bytes 0-3: Timestamp
  • Bytes 4-7: Session count
  • Bytes 8-11: IP address of the server issuing the session ID
  • Bytes 12-13: Random number (or zero, see below)

The Attack

We now know everything we need to try to hijack another user's session. The timestamp is always increasing, the session count simply increments, and the internal server IP address is constant. If we make two requests to the server, and the session count of the second request is more than 1 higher than the session count of the first, then we know that another session has started in between. We know also that the timestamp of that session will be between our two timestamps.

The two "random bytes" might have been a stumbling block, but:

  • The random bytes are not used by all servers, in which case they are zero.
  • For many servers tried, the random bytes are only generated when the server is started; they are the same for all user sessions.

For example, a couple of consecutive session IDs from a website might be something like this:

$ perl -e 'print "HEAD / HTTP/1.0\n\n"' | \
nc www.example.com 80 | grep sessionid
Set-cookie: sessionid=FGAZOWQAAAK2RQFIAAAU45Q;path=/
$ ./decode-sessionid.pl -s FGAZOWQAAAK2RQFIAAAU45Q
SessionID gives: Thu Oct 12 12:34:06 2000,
session count = 5576, IP Address =
Extra = 4f (79) 7e (126)
$ perl -e 'print "HEAD / HTTP/1.0\n\n"' | \
nc www.example.com 80 | grep sessionid
Set-cookie: sessionid=FGFLIHYAAALJVQFIAAAU45Q;path=/
$ ./decode-sessionid.pl -s FGFLIHYAAALJVQFIAAAU45Q
SessionID gives: Thu Oct 12 12:38:44 2000,
session count = 5786, IP Address =
Extra = 4f (79) 7e (126)

Note that all session IDs in this report were obtained from real servers, but have been modified to avoid naming those servers. The name of the session ID is usually, but not always, "sessionid", "sesessionid", "JSESSIONID" or "jwssessionid".

The random extra bytes don't seem to be very random, but you do need to watch out for load-balanced servers, as each will have different counts and random elements.


Once an attacker has guessed another user's session ID, they have full access to that user's session (assuming the session ID is the sole identifier for session management and security purposes, which it is on many sites). If the service provides a means of "logging out", then the session ID is only useful until the real user logs out. Until then you can (typically) view any page, take any action, post to any form etc, that the real user can on the site. And the real user will be unaware of this (until some action you take has a visible result to the real user). Basically, it's very bad news.

Of course, the fact that the session IDs leak your internal IP addresses and, perhaps more importantly from the business point of view, the server's session count (easy way to track the popularity of competitors' sites) is in itself a cause for concern.

Testing Vulnerability

There are a large number of servers on the Internet using session ID cookies or URL re-writing encoded in this fashion. The easiest way to identify such sites is to find a page on the site which generates a session ID (often this is either the home page, or the page which processes logins), then make a few requests to this page, and compare the session IDs, looking for the incrementing session count.

Netcraft is reluctant to give a more exact test here, because it could lead to a false sense of security for administrators whose sites don't display the behaviour described above. Netcraft has seen some variations on the basic theme (e.g. some servers have longer session IDs than those described here, but the extra data appears constant).


  • There should be some real random input to the session IDs if they are to be used as the sole means of session tracking and management.
  • Any meaningful data being used in session IDs should be one-way encrypted. You shouldn't be trusting users to play fair with this information.

Recent versions of Sun's Java servlet code (from version 2.1) use a new session ID system, which includes a large random component. However, developers building application servers should enhance the code to make the session count inaccessible.

The Apache Tomcat project, starting with Tomcat version 3.2, uses a secure random number generator, and maintains uniqueness of session IDs without leaking the session count.

Vendor Patches and Comments


Bug numbers:

Dynamo 5.1, Dynamo 5.0 Patch 2 - Bug #29826
Dynamo 4.5.1 Patch 5 - Bug #25925
Dynamo 4.1.0 Patch 9 - Bug #31956
Dynamo 4.0.1 Patch 4 - Bug #31957
Dynamo 3.5.1 Patch 8 - Bug #32277

Versions affected:

Dynamo 3.5.1, Dynamo 3.5.1 Patch 1 through 7
Dynamo 4.0.1, Dynamo 4.0.1 Patch 1 through 3
Dynamo 4.1.0, Dynamo 4.1.0 Patch 1 through 8
Dynamo 4.5.0, Dynamo 4.5.0 Patch 1 through 5
Dynamo 4.5.1, Dynamo 4.5.1 Patch 1 through 4
Dynamo 5.0, Dynamo 5.0 Patch 1

Versions not affected:

Dynamo 5.1, Dynamo 5.0 Patch 2 and all future releases
Dynamo 4.5.1 Patch 5 and all future releases
Dynamo 4.1.0 Patch 9 and all future releases
Dynamo 4.0.1 Patch 4 and all future releases
Dynamo 3.5.1 Patch 8 and all future releases

Patch location:

Available to registered users in the support area on atg.com, under "Dynamo Patches".

Dynamo 5.1, Dynamo 5.0 Patch 2, Dynamo 4.5.1 Patch 5 are available as of 20th December, 2000.

Dynamo 3.5.1 through 4.1.0 patches should be available in mid-January 2001.


"With V2.x, we have always had hooks in the HttpSession support to allow applications to associate authentication information with a session and prevent access to that session if the right credentials are not provided. For customer applications who could not do this, we earlier this year provided a V2.x patch which further 'randomizes' the session ID, using a triple DES encryption ID generation algorithm.

With V3.x, we feel we have always prevented this issue - There is built in coupling between the HttpSession and WebSphere security, where authentication is automatically associated with the session and thus is used to prevent all unauthenticated access. One can review the WebSphere documentation to review all the various means available for securely maintaining this authorization."

E-fix PQ47663 is now available for version 3.02 and 3.5.x of WebSphere. For version 2, ask WebSphere support for the "version 2 HttpSession ID randomization change".

Sun Microsystems

For Java Web Server 1.1.1 or 1.1.2, first upgrade the Java Web Server and than install the appropriate patch:

Version 2.0 Patch 4

Version 1.1.3 Patch 4

Patches available from http://www.sun.com/software/jwebserver/upgrade/index.html.


This information is provided on an AS IS basis in the hope that it is useful in securing vulnerable computer systems; however Netcraft cannot guarantee its accuracy or accept responsibility for any damage resulting from the release of this advisory.


For more information on Netcraft security services, please see http://news.netcraft.com/archives/security.html