Java Web Server Scanner An Applet-based Web Server Vulnerability Scanner

Zhu Bo and Woon Irene School of Computing, National University of Singapore Abstract: Vulnerability scanners are very useful tools. They help administrators in pointing out weaknesses of computer systems. There are a lot of vulnerability scanners currently available [1], but they concentrate on the vulnerabilities of the whole system with some of the popular ones containing some checks on web servers. Even for those that are specifically for scanning web servers, none of them focus on the vulnerabilities resulting from improper settings of web server. Till now, the usual method of preventing this kind of error is to follow a checklist (if there is a complete one) and do it all manually. A major difference between Java and other languages, such as C, is that security is an important issue in the development of Java. The great improvement of security model in Java 2 SDK makes the implementation of applets more flexible and safe ([2] [3] [4]). The idea in this project is to import the advantages of applets and the java security model into the field of web server vulnerability scanning. 1. Background of JWSS (Java Web Server Scanner) JWSS is a part of the Web Server Security Assessment System project [5]. The whole project consists of three parts: 1) Web Server Security Policy: There are a lot of web server or web site security policies on the Internet. However, most of them are lower level guidelines, or even checklists. In this project, a high level, platform-independent web server security policy is designed, which is based on British Standard (BS7799) [6]. The international version of BS7799 has been published as an international standard - ISO/IEC 17799:2000 [7]. 2) Web Server Security Checklist The web server security checklists are designed following the web server security policy in the first part. In contrast to the security policy, the checklists are low level and platform-dependent. 3) JWSS Checks of JWSS are derived from web server security checklists. 2. The Design of JWSS 2.1 The Structure of JWSS JWSS includes the following components: 1) Servlet: It is the component that communicates between the database and client users. Check files (.class) are packed into JAR files for downloading at this part. 2) Applet: It is the component that interacts with the client user and displays information e.g. help and results of scanning.

3) Vulnerability Plug-in Database: It is the core of the scanner, which includes all the checks for vulnerabilities of Web Server. 4) Scanning Module Database: It provides some standard scanning modules for different kinds of Web Servers and different level requirement on Web Server security and some specialized module, such as top 10 vulnerabilities of web server or the latest 10 vulnerabilities of web server. 5) Help Database: This provides description of vulnerability and guide to fix it. This can be downloaded into local system. The structure of JWSS is showed in figure 1. Vulnerability Plug-in Database (.class)
Help Database (description of vulnerability and guide to fix it)

Scanning Module Database request module files

return request module plug-in files files

return request plug-in help files files (.class)

return help files

Servlet
select the module of scanning return the plug-in files (.jar) request help files return help files

Client: GUI Interface

Figure 1: The Structure of JWSS

2.2 Checks Provided in JWSS Checks provided by JWSS can be divided into: 1. Checks that are provided by current vulnerability scanners JWSS would support all the checks provided by current vulnerability scanners, except those checks on weaknesses of unnecessary services for web servers, such as finger. One principle of securing web servers is to minimize services provided by the host of web server, and checks of this kind are unnecessary - JWSS does provide checks on whether unnecessary services are running. 2. Checks that are not provided by current vulnerability scanners In JWSS, checks on settings of remote web server have been provided. It is the first time that these kinds of checks are provided in vulnerability scanners. These checks can be classified as:

a) Checks on configuration files of web server For example, there are three configuration files for Apache: httpd.conf, srm.conf, and access.conf. After carefully looking over the settings of directives and options in these files, a lot of information could be collected which could help administrators to find out weaknesses of Apache. For example, during the creation and maintenance of a site, all sorts of detritus may accumulate in the document root: test files, scripts, text editor, autosave files, notes, handy links, and outdated pages. If the Indexes option is allowed for document root, it is possible for the casual user to browse through this information, learning more about web server. This could be prevented either by putting a welcome file in each directory (usually named index.html) or by entirely disabling Indexes option (the Indexes option of document root is open in the default setting of Apache). b) Checks on Access Control Lists (ACL) of important directories and files Through examining the ACLs of important directories and files, a clear picture is given to show whether different group of users have been assigned privileges properly. For example, for IIS, make sure the ACLs on the IISgenerated log files (%systemroot%\system32\LogFiles) are: Administrators (Full Control)** System (Full Control) Everyone (RWC) This is to prevent malicious users from deleting files to cover their tracks. c) Checks on Windows registry Not all the settings in Windows registry could be detected through remote scanning, but JWSS can check keys and values of all the registry entries. For example, in order to remove the shutdown button from the logon dialog, set the following value in the Registry: Hive HKEY_LOCAL_MACHINE\SOFTWARE Key \Microsoft\Windows NT\Current Version\Winlogon Name ShutdownWithoutLogon Type REG_SZ Value 0 This would prevent damage from internal malicious users. d) Other checks There are also some other checks that cannot be performed by existing vulnerability scanners, such as a check on whether file system of the host of web server has been converted into NTFS. NTFS is required to perform ACLs under Windows platform. 3. Advantages of JWSS Some advantages of JWSS are: 1) Web Server security scanner is based on web server policy. Web server security policy and web server vulnerability scanner are not designed separately. A well-designed security policy will provide benefits to the design of ___________________________________________________________________________
** R Read, W Write C Change, X Execute, D Delete, P Change Permission, O Take Ownership, Full Control RWXDPO

vulnerability scanners in two ways

a. Assure the proper controls to be implemented b. Achieve consistent and complete security 2) Audit and control what vulnerability scanners can do When using existing vulnerability scanners, administrators are not able to tell what the vulnerability scanners are actually doing on their systems. Even for those open source software, backdoors or weaknesses could be found only after the source codes have been examined. However, with JWSS, it is the first time that system administrators can audit what a vulnerability scanner is actually doing on their system. In addition, administrators are given the rights to control the privileges are granted to vulnerability scanners. This due to a sandbox mechanism that controls what a Java program, such as an applet, is permitted to do. It is welcomed from security aspect, but it also limits the usage of Java applets. However, the new security model of Java 2 SDK make this limitation much more flexible than before, without compromising the security provided in former Java security models. The new security architecture developed in Java 2 allows fine-grained access control. It gives the ability to grant specific permissions to a particular piece of code about accessing specific resources of the client (say read and write permission on file x, but only read permissions on file y and no permission on file z) depending on the signers of the code and/or the URL location from which the code was loaded [4]. 3) Check vulnerabilities resulting from improper settings of web server Based on new security model of Java 2 SDK, JWSS can access remote sources, such as configuration files of web server and ACLs of important directories and files, etc., and then check whether remote web servers are configured properly. Thus, using JWSS, system administrators could check their configurations on web server automatically. 4) Platform independent Though all the popular vulnerability scanners could scan both UNIX/LINUX-like and Windows (including windows 9x, Windows NT 4, and Windows 2000) OS, most of them could not be installed on all these kind of OS, or there are different version provided for different platform. An applet has true platform independence. So applet developers dont need to make any changes in their code for different platforms, and client users also dont need to concern about whether the scanner is suitable for the platform on which their PCs run. 5) No installation and update issue Installation and updates of JWSS are automatic every time the user loads the Web page that contains applets, so updates occur silently and automatically. 4. Discussion Speed is one important reason that hinders the application of applets. There are a few methods that could be used to improve the speed of applet-based scanner: 1) The use of JARS [2] It is important to remember that the reason for the long loading time of applets is not the size of the class files they are quite small. Rather it is because of the considerable overhead involved in establishing a connection to the web server. Using

JAR format, Java applets and their requisite components (class files, images, sounds, etc.) could be downloaded to a browser in a single HTTP transaction. This greatly improves the speed with which an applet can be loaded onto a web page and begin functioning. 2) Manipulating the cache setting [8] Another approach is to improving the downloading speed is to use the Java Plug-in mechanism for making applets sticky i.e. using the CACHE_OPTION, CACHE_ARCHIVE, and CACHE_VERSION keys. If CACHE_OPTION is set to Plugin, applets will stay on the disk in a secondary cache which the browser cannot overwrite. The only time "sticky" applets get downloaded after that is when they are updated on their server. Otherwise the applets are always available for quick loading. It would decrease time of loading applets greatly, if applets were very big. REFERENCES 1. Forristal, Jeff AND Shipley, Greg. January 8, 2001. Vulnerability Assessment Scanners. 2. Horstmann, Cay S. Gary Cornell. December 18, 1999. Core Java 2, Volume 1: Fundamentals 3. Horstmann, Cay S. Gary Cornell, December 27, 1999, Core Java 2, Volume 2: Advanced Features 4. Pistoia, Marco AND Reller, Duane F. AND Gupta, Deepak AND Nagnur, Milind AND Ramani, Ashok. August 4, 1999. Java 2 Network Security 5. Bo, Zhu and I. Woon, Securing Web Servers, paper submitted to the Eighth ACM Conference on Computers and Communications Security, November 6-8, 2000. 6. British Standards Institution (BSI). 1999. British Standard (BS) 7799-1:1999.2 7. Symantec Enterprise Solutions. Oct 10, 2000. Up to Standard: BS7799 and Your Enterprise.

8. Apache HTTP Server Project. Apache Caching in Java Plug-in. Retrieved Apr 30 2001 at http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html.