The increasing availability and falling costs of high bandwidth connections have posed a question to the continuing relevance of the Linux distribution industry. In 1995 only the very determined would have downloaded the Linux operating system over a 28.8K connection rather than pay for a CD, but equiped with a cable or DSL connection, the CD becomes much more optional.

Mandrake compounded this scenario by some commercially curious behaviour, making freely downloadable images of each new release available over the internet well before their CD editions were available. Mandrake's approach was popular but seemed to actively encourage people to download the new releases rather than buy CDs. More opportunistic companies have been able to sell CDs of new Mandrake releases for weeks before Mandrake's own boxed sets became available.

Sun launched its Identity Server this week, which is positioned as the first component of the Liberty Alliance single sign-on scheme for web site authentication. When the Liberty Alliance was first announced, it seemed that its position was hopeless, as Microsoft Passport and AOL SNS already had their systems implemented and deployed. However, Passport and SNS have not by any means become pervasive, with this months survey finding fewer than 100 unique sites using these systems and Liberty now seems to have a plausible chance to compete with the established systems. 

This month is the first time that a Windows 2000 site has appeared in the  50 top sites which have the longest period of time since last reboot. www.byteandswitch.com has been running continuously since November 2000. When we first started graphing web servers uptime in the summer of 2000, many people were skeptical that a Windows machine would ever make the top 50. Perceptions change, and although two years is exceptional, several Windows 2000 sites have run for more than a year without a reboot. In the hosting industry, Microsoft partners Interliant and Devine each have sites that have not been rebooted in over a year, while Microsoft has also run several of its own sites for over a year between reboots. 

www.intel.com is one of a very small number of well known sites running both Windows 2000 and Windows 2003 in a load balanced pool, and has become a tempting target for people to use as a straw in the wind towards the relative performance of the two operating systems. One person mailed us saying he thought that the Intel site's response time had slowed since Intel started using Windows 2003, and asked for confirmation and explanation.

The performance of www.intel.com shows a saw tooth formation, with some responses consistently longer than others. Matching up the response times with the corresponding server signatures actually does confirm that the responses served by Microsoft-IIS/6.0 are consistently longer than those served by Microsoft-IIS/5.0.

Analysing the response time graph more carefully shows that the connection time and time to serve the first byte are consistent across the two sets of servers, but the time to serve the complete request is significantly higher on the Microsoft-IIS/6.0 servers.

It is important to appreciate that the difference need not be directly caused by the system software. Other plausible reasons could include;

• The hardware specification of the Microsoft-IIS/5.0 machines may be faster than those running Microsoft-IIS/6.0
• The configuration of the systems is likely to be different
• From looking at the tcp/ip characteristics, we think it is likely that the www.intel.com front page is served dynamically, and  the migration of the application that generates the dynamic content may have introduced a performance penalty
• The configuration of the local network at  Intel may have disadvantaged the Microsoft-IIS/6.0 machines in some way.

• Traffic & Pricing
  Netcraft.com currently generates about 2.25 million 468*60 and skyscraper banner impressions per month [about 4.5 million in total], and will accept orders of $1500 [$15CPM] and up, with discounts on larger buys.



• Advertisers
  Current or recent advertisers include EV1Servers, Google, Hostway, Interland, Microsoft, Sun Microsystems and Verisign.



• Geographical Analysis
  Accesses to the site are cosmopolitan, with the following geographical distribution;

  Percent	Country
  56	USA
  6	UK
  4	Germany, Canada
  2	Japan, Holland, France, Sweden, Italy
  2	unknown
  1	Switzerland, Australia, Korea, India
  12	The rest

  Banners can be targeted to a particular country or group of countries by ip address.




• Audience
  The site is a good vehicle for corporate visibility to technology companies. Accesses from microsoft.com & ibm.com account for about 1% of total requests. The site is regularly monitored by technology journalists and has featured in many publications including the BBC, the Wall St. Journal, New York Times, Business Week, the Economist, the Financial Times, news.com and Slashdot.
  
  Over 15,000 people currently subscribe to receive articles by electronic mail. This list is very cosmopolitan, and is primarily made up of people running web sites but also contains several stock market analysts, well known analysts at market research companies, leading journalists, nearly all the Apache core team, and several of the W3 standards group.
  
  An RSS feed has recently been launched and is being taken by around 50 news aggregation systems.
  
  The survey is usually cited or featured in several technology articles or press releases each month;

  GoogleNews

  http://news.com.com/2100-1001-975630.html

  http://news.com.com/2100-1001-874235.html

  http://news.com.com/2100-1001-872266.html

  http://news.bbc.co.uk/hi/english/sci/tech/newsid_1738000/1738496.stm

  Netcraft was recently included in PC Magazine’s Top 100 Classic Web Sites. PC Magazine is one of the world's leading computer publications with a readership of 6 million people.

  A key feature is the Survey's ability to sustain the respect of both the free software and commercial communities over a long period of time.




• Demographics
  Of the last 1500 people to register for the Web Server Survey announcement mail, these were the most common job titles [job title is not compulsory on registration].

  People	Job Title
  78	Director/cto
  77	Technical consultant
  69	Webmaster
  50	Student
  49	Web Developer
  46	System Administrator
  46	Software Engineer
  37	President
  35	Project Manager
  29	CEO
  23	Vice President
  20	Network Administrator




• Reporting Information
  Statistics are available via weekly mailed reports [csv or xls format] or in real-time via a web interface.



• Contact Information
  banners@netcraft.com
  Phone +44-1225-447500
  Fax +44 1225 448600
  Netcraft, 2 Belmont, Bath BA1 5DZ England
  

Netcraft Ltd 2 Belmont Bath BA1 5DZ Phone: +44(0)1225 587500 Fax: +44(0)1225 448600 Email: info@netcraft.com

Maps

Netcraft is located at the bottom of Lansdown Road in Bath (Google Maps)

Netcraft is a 15 minute walk - or a short taxi ride - from Bath Spa railway station.

Netcraft has created this privacy statement covering its web sites in order to demonstrate our commitment to privacy. This Privacy Policy explains the information gathering and dissemination practices for our Web sites in the netcraft.com, netcraft.co.uk, and netcraft.net domains, and for people using the Netcraft Toolbar and how this information is used. If you have any queries or requests concerning your personal information, please contact us at webmaster@netcraft.com.

• Information Automatically Logged

  We use your IP address to help diagnose problems with our server and to administer our Web site. Your IP address may also used to display regional advertising banners.

• Advertisers

  Sometimes advertisers may use third party banner servers to display banners on our site. These servers are not under Netcraft's control.

• Cookies

  Netcraft uses cookies in areas of the site requiring authentication, and as part of its banner serving system. Cookies may also be used with some fill-in forms, to retain default values between visits.

• Registration Forms

  Forms exist on our site that require users to submit contact information (an email address). This information is used to send Netcraft articles and promotional information to interested visitors. Users may unsubscribe from receiving automated mail as a result of submitting this information.

• Enquiry and Order Forms

  Our site use enquiry and order forms for customers to request details of, and purchase, services. We collect contact information (such as invoice and mail addresses) and financial information (a credit card number). This information is used for contacting customers and for billing.

• External Links

  This site contains links to many other Web sites. Netcraft is not responsible for the privacy practices or the content of these sites.

• Security

  This site has security measures in place to protect the loss, misuse, and alteration of the information under our control.

• The Netcraft Toolbar

  The Toolbar collects the following information:
  

  • A unique identification reference is generated for each Toolbar installation. This is sent back to us when the Toolbar attempts to download updated versions of its software and is used for planning and licensing purposes. This is not sent as part of the Toolbar's normal operation when browsing the web.
  • Web sites (not URLs) visited when browsing the web. These are used to identify URLs that should be blocked within the site being visited and to provide contextual reports and popularity ranking information.
  • Very old versions of the toolbar also collected MD5 hashes of URLs visited. This has been discontinued in recent versions.
  • The Toolbar does not collect any personal information except that described above. In particular, we do not collect personal information which can identify the browsing habits of individual users.

• Use of Personal Information

  We process personal information collected through the web site and the Toolbar for the purposes of:
  

  • Dealing with your enquiries, requests and reports of phishing URLs.
  • Providing you with information about updates and enhancements to our products and services.
  • Please contact us at webmaster@netcraft.com if, at any time, you do not wish to receive information about our products or services.

• Disclosures

  We will not sell or disclose personal information to any third parties except successors in title to our business and, if required, government bodies and law enforcement agencies.

• Access Rights

  You have a right to access the personal information held about you. To obtain a copy of the personal information we hold about you, please mail us at webmaster@netcraft.com.

• Contacting the Web Site

  If you have any questions about this privacy statement, contact webmaster@netcraft.com.

Overview

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.

Details

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.

Recommendations

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.

Disclaimer

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.

Netcraft

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.

Overview

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.

Details

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 = 192.168.0.1
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 = 192.168.0.1
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.

Consequences

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).

Recommendations

• 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

ATG

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.

IBM

"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.

Disclaimer

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.

Netcraft

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