nCipher and Verisign today launched the world’s first hardware SSL certificates. An SSL certificate stored in dedicated cryptographic hardware initially seems superfluous, but there are some bona fide advantages.Continue reading
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.
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.
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.
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%.
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
Vendor notified: 22nd October, 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
/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
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,
/servlet/ method of invoking the servlet which does SSI
(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
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.