Penetration test report - your comments please?

[Curt Wilson <netw3 () netw3 com>]

Enclosed is a text report on a pen test I did recently. I was given three
hours to attempt penetration from remote without touching any other hosts,
using brute force, relying on DOS, social engineering or physical attacks.
I'm curious if I missed anything obvious, and would be thankful for any
comments or suggestions from other penetration testers, especially if you
are one of the people who authored one of the messages included from
various security mailing lists. Thanks for any input folks. 


Initial Audit and Penetration test: <company name>.
Submitted by Curt Wilson, Netw3 Consulting

The www.<sitename.com> system is currently running at <ISP> and does not
have any type of firewall or other access control mechanism in place that I
am aware of. Therefore, this audit is only reflective of the current state
of the system. Network and host remote vulnerability conditions were tested
for, with the exclusion of Denial of Service (DOS) and brute-force attacks.
I was unable to penetrate into the operating system or database within the
allotted time, therefore it is likely that <sitename.com> is fairly secure
from all but the most determined attackers or those with pre-existing access.

Basic recommendations: Disable any unnecessary services and web modules.
Apply all necessary patches on a timely basis. Restrict access on a IP
address level through TCP wrappers, router access control lists, firewall
filters, or newer features in the Linux 2.4 kernel. Enable encryption for
all exposed services when possible, and protect any systems used for
administration or any systems that may store login credentials or
certificates. Choose strong passwords, and review all logs on a timely
basis. A hardening tool such as Bastille Linux could be helpful.
Additionally, ensure that all data pathways to target system from ISP and
internal company network are secure.

Enumeration and penetration attempts: The nmap tool was used to scan all
listening TCP ports and attempt to identify the Operating System. Results
were obtained for TCP, but some mechanism is in place that blocked my nmap
UDP scan and revealed that all UDP ports were listening (which is obviously
not the case; this result is often caused by a firewall. An attempt to scan
UDP from windows was also met with unreliable results).

[root@premis netw3]# nmap -sS -P0 -n <IP address> -O

Starting nmap V. 2.54BETA5 ( www.insecure.org/nmap/ )
Interesting ports on  (<IP address>):
(The 1527 ports scanned but not shown below are in state: closed)
Port       State       Service
22/tcp     open        ssh                     
80/tcp     open        http                    
111/tcp    open        sunrpc                  
443/tcp    open        https                   
5432/tcp   open        postgres                
8007/tcp   open        jserv                   
8080/tcp   open        http-proxy              

TCP Sequence Prediction: Class=random positive increments
                         Difficulty=3308963 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.16

The TCP portscan can be made less attractive by the use of TCP wrappers
plus a tool such as portsentry to block access from IP addresses that
generate a number of connection attempts that exceed a set threshold. Care
must be taken to ensure that a Denial of Service (DOS) condition does not
result from an attacker sending spoofed or decoy IP addresses that belong
to the systems upstream routers or other important clients or Internet
access points. Such a condition could be easily fixed, however.

TCP sequence prediction indicates that the spoofing of TCP connections
based on sequence numbers would be a nearly impossible task. The basic
Linux kernel has been resistant to TCP sequence number prediction attacks
for some time.

The remote operating system guess can be circumvented through kernel
modifications, if this is considered important.  Attackers use this
information during a reconnaissance phase to determine attack methodologies.


Recommendations by port:

TCP port 22: SSH: SSH-1.99-OpenSSH_2.3.0p1

Protocol version 1.99, software version 2.3.0p1

OpenSSH is known to be generally secure, having affiliation with the
OpenBSD operating system, which is known for it's good security. However, a
known vulnerability exists in the SSH version 1 protocol which allows a
(very difficult) insertion attack to take place. The chance of such an
attack is very slim. Solution: Upgrade to OpenSSH 2.5.2 which supports SSH V2.

Reference: http://www.core-sdi.com/soft/ssh/ssh-advisory.txt

SSH protocol V1 is vulnerable to a man-in-the-middle attack through the use
of an exploit tool called sshmitm, which is part of the dsniff package.
Certain restrictive conditions must exist for this attack to be feasible,
namely, the SSH connection must be routed through the Internet, or through
some other network where a man-in-the-middle attack can take place through
a variety of methods. If SSH is used on an internal network, or is used
sparingly from the Internet (with IP address access control in all cases),
the chance of this vulnerability being exploited is very slim. 

Reference: http://www.monkey.org/~dugsong/dsniff
Reference: http://sysadmin.oreilly.com/news/silverman_1200.html

Another recently discovered vulnerability reveals that the exact length of
a users password can be determined through the passive monitoring of an
SSHv1 sssion. Fix: upgrade to the most recent version of SSH available and
apply any vendor security patches.

Reference: http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt

As long as strong passwords are used, a successful attack through the
normal SSH authentication mechanism is unlikely. Upgrade to the latest
version of SSH and ensure that proper logging is taking place and that logs
are monitored on a regular basis.

4/11/01: 11:20PM Attempted SSHv1 CRC compensation attack exploit using the
xpl exploit; unsuccessful, wrong version of SSH.

I have no means to implement a sniffing attack since the scope of this
penetration test was related to the target system <sitename.com> and not
related machines or network infrastructure. Note than a dedicated attacker
will have no such scruples.

TCP port 80: HTTP

Web header: Apache/1.3.14 (Red-Hat/Linux) tomcat/1.0 modssl/2.7.1
OpenSSL/0.9.5a DAV/1.0.2 PHP/4.0.4pl1 modperl/1.24 on Red Hat Linux

Apache/1.3.14: This version of apache is vulnerable to an information
leakage bug that would allow an attacker to retrieve a directory listing
and obtain pathnames. This information could be leveraged for other
attacks, but is considered a low-risk vulnerability. I was unable to find
any actual exploit or the details on how to leverage this vulnerability
manually. Fix: Upgrade to version 1.3.19 is suggested for maximum security.

Reference: http://www.securityfocus.com/bid/2503

The Apache web server allows a PUT request to the root directory, but an
attempt to actually place a file using this method failed. 

http://www.<sitename.com>/admin/

The Tomcat Administration tools directory /admin should be restricted to
Internet access. The administration tools are protected by password
authorization, so as long as strong passwords are used, the risk is
minimal. For best results, apply access control mechanisms to prevent
directory access of /admin in the first place. An attacker could still
attempt to run a brute force attack on passwords. Ensure that logging is
enabled, and strong passwords have been used. Restrict or remove the admin
directory if it's not being used.

Reference: http://www.securityfocus.com/archive/1/71116

DAV/1.0.2: No known vulnerabilities for this version of DAV on Apache. An
attempt to connect using Dreamweaver 4 as a DAV client failed, either due
to a disallowed connection or bad credentials. If DAV is used over port 80,
authentication information may be passed in clear-text and intercepted
through a sniffing based attack. Ensure that strong passwords are required
for WebDAV access and limit connections as much as possible by restricting
DAV access only to web page directories (along with the other
aforementioned access control methods).

Reference: http://www.webdav.org/mod_dav/ - security

PHP/4.0.4pl1: This is a recent patch to the PHP package and should be
secure against known vulnerabilities. 

Reference: http://www.securityfocus.com/bid/2206

Modperl/1.24: No specific remote vulnerability information has been
discovered.

TCP port 111: Sun Remote Procedure Call portmapper. Close this port or
apply access control mechanisms to prevent future Sun RPC portmapper based
attacks and information gathering tools from automated scans. An rpcinfo
request to <sitename.com> only shows the portmapper itself listening, so
perhaps the other RPC ports have either been disabled, or the portmapper
has been configured to not give out this information. Many scanning and
cracking tools work through TCP and UDP port 111 and this port is one of
the most commonly  attacked on the Internet today. The specific risk
appears to be low, unless other RPC services ARE actually running on their
default ports. Various tests to exploit statd and other RPC services failed.

[root@premis netw3]# rpcinfo -p www.<sitename.com>
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp   111  portmapper

4/11/01: 11:15 PM Attempted to access rpc.mountd with ADMmountd exploit;
unsuccessful. Perhaps RPC port is not listening. 

4/11/01: 11:35 PM Attempted rpc.statdx exploit, attempted to exploit RedHat
6.0-6.2 to no avail. Either statd is not listening or is listening on a
different RPC port. At this point, the average attacker would most likely
give up and stop probing non-replying RPC services.

TCP port 443: SSL. Modssl/2.7.1: Unable to find any specific security
issues. Note that the SSL 2.0 protocol is vulnerable to a man-in-the-middle
attack with the sslmitm tool of the dsniff package previously discussed in
the SSH section of this report. The likelihood of such an attack is very
slim and requires existing access. If an attacker were able to obtain such
access, they could possibly eavesdrop on the authentication credentials.
For best results, only use SSL 3.0.

OpenSSL/0.9.5a: Unable to find any remote security issues. See note above

TCP port 5432: Postgres: Basic research does not indicate any known
vulnerabilities by leaving this port open since there are a variety of
authentication schemes already taking place by default. An extensive search
revealed no public vulnerabilities for the Postgres TCP server. Of course,
this port should be restricted to the systems that need to access it.

On the local side, Postgres passwords are stored in cleartext, but in a
file only accessible to the postgres admin login, and root. A local
vulnerability only, unless an intruder can obtain remote root access, and
if they have obtained root then there are many other problems to deal with. 

Reference:  http://www.securityfocus.com/bid/1139
Reference: http://www.phpbuilder.com/columns/kevin20010314.php3?page=3

TCP port 8007: Tomcat protocol port. Restrict access to desired hosts. If I
recall correctly from our discussion, Tomcat only needs to communicate with
Apache, and not with the world, therefore restriction should be placed on
IP address. No known attacks exist for this service that I was able to locate.

TCP port 8080: Tomcat Web Server

Header reveals: : Servlet-Engine: Tomcat Web Server/3.2 (final) (JSP 1.1;
Servlet 2.2; Java 1.3.0;  Linux 2.2.16-22enterprise x86; java.vendor=IBM
Corporation)

Tomcat system is not vulnerable to .jsp source code display, since tomcat
runs with Apache and not as it's own web server. Issue reported on
SecurityFocus Bugtraq Tues, April 3, 2001.

Reference: http://www.securityfocus.com/bid/2527

Close port 8080, or disable the service if it's not needed, since crackers
scanning for proxy servers will find this port, drawing unnecessary
attention to your site. The Tomcat Web server on port 8080 includes various
examples of servlet and jsp code that allows parameters to be passed. In
general, it is a good idea to restrict access to sample or demonstration
code. At the moment, no known security vulnerabilities or denial of service
conditions exist in the demonstration code. Restrict access to port 8080,
only allowing access from those systems that must communicate in this
manner.   

Leaving port 8080 open to the global Internet allows a potential attacker
to retrieve various data about the servers operating environment that could
be useful in the implementation of other types of exploits or possible
cookie/session state attacks. This is an informational gathering attack
only and does not itself allow for intrusion.

Reference:  http://www.securityfocus.com/bid/1532

Operating system data was obtained from <sitename.com> by requesting a
non-existing SNP file with the following URL:

http://www.<sitename.com>:8080/examples/jsp/snp/blotto.snp   

Servlet init parameters:

Context init parameters:

Context attributes:
   javax.servlet.context.tempdir = /opt/tomcat/work/localhost_8080%2Fexamples
   sun.servlet.workdir = /opt/tomcat/work/localhost_8080%2Fexamples

Request attributes:

Servlet Name: snoop
Protocol: HTTP/1.1

Scheme: http
Server Name: www.<sitename.com>
Server Port: 8080
Server Info: Tomcat Web Server/3.2 (final) (JSP 1.1; Servlet 2.2; Java
1.3.0; Linux 2.2.16-22enterprise x86; java.vendor=IBM Corporation)
Remote Addr: <pen test IP addr>
Remote Host: <pen test IP addr>
Character Encoding: null
Content Length: -1
Content Type: null
Locale: en_US
Default Response Buffer: 8192

Parameter names in this request:

Headers in this request:
   User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
   Cookie: JSESSIONID=j7vygwbsa1
   Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*
   Host: www.<sitename.com>:8080
   Accept-Encoding: gzip, deflate
   Accept-Language: en-us
   Connection: Keep-Alive

Cookies in this request:
   JSESSIONID = j7vygwbsa1

Request Is Secure: false
Auth Type: null
HTTP Method: GET
Remote User: null
Request URI: /examples/jsp/snp/blotto.snp
Context Path: /examples
Servlet Path: /jsp/snp/blotto.snp
Path Info: null
Path Trans: null
Query String: null

Requested Session Id: j7vygwbsa1
Current Session Id: j7vygwbsa1
Session Created Time: 986245076263
Session Last Accessed Time: 986245144366
Session Max Inactive Interval Seconds: 1800

Session values: 
   tomcat.auth.originalLocation = /examples/jsp/security/protected/index.jsp


If possible, don't run Tomcat as root, in the event that the Tomcat server
would be attacked through a buffer overflow, format string, or other type
of exploit. To run as "nobody" one method is:

If your UNIX-style box has an "rc.d"-style boot directory (Solaris,
RedHat, etc.), then the simplest way is to create a file in the appropriate
boot directory which looks something like this: 

#!/bin/sh
CLASSPATH=/your/classpath/here
export CLASSPATH
su - nobody -c "/tomcat/bin/tomcat.sh $@" 

You can then invoke this as /etc/rc.d/init.d/tomcat (start | stop) from
your boot sequence in the same way that you start Apache (for instance). 

TCP, IGMP, ICMP, and UDP protocols are allowed through at the current time.
TCP is necessary. UDP may not be, since I don't believe there is any
service that relies upon UDP at <sitename.com> (but I don't know this for a
fact). Certain components of ICMP are necessary, but others should be
blocked. See the ipchains reference which includes  ICMP information at
http://www.sans.org/infosecFAQ/firewall/blocking_ipchains.htm for more
information. IGMP does not pose a large risk on a Linux system, but is
probably not necessary and may most likely be removed without any harm in
functionality.

[root@premis netw3]# nmap -sO www.<sitename.com>
Starting nmap V. 2.54BETA5 ( www.insecure.org/nmap/ 
Interesting protocols on <sitename.com> (<IP address>):
(The 250 protocols scanned but not shown below are in state: closed)
Protocol   State       Name
1          open        icmp
2          open        igmp
6          open        tcp
17         open        udp                     

Misc Information that may or may not be useful:

Date:    Fri, 6 Apr 2001 08:52:28 -0600
From:    rudi carell <rudicarell () HOTMAIL COM>
Subject: Servlets and the NULL-BYTE
MIME-Version: 1.0
Content-Type: text/plain; format=flowed

I am not sure if this is common knowledge

but ..did anybody of you ever notice, that the
NULL-BYTE (\000) can be used for java-servlets
and jsp s the same way as it can be used in perl-
scripts?

every unchecked http-parameter passed to a File, RandomAccessFile or similar
Java-Class makes it possible for an Attacker to cut off program-supplied
file-extensions or do a traversal-exploit.

is this behavior conformable to java/Unicode specs???

My attempts at implementing this null-byte exploit were met with failure,
perhaps due to the limited time allocated to this phase of the project, or
due to the possibility that the site is not vulnerable. The only thing I
could do was to return a blank page instead of the logout or login page for
the main case search servlet as such:

http://www.<sitename.com>/<path>/<path>/<servletname>?page='\000\'

Ensure that the java code is written in a manner to restrict use of the
null-byte exploit technique.  

Java code checklist:
http://java.sun.com/security/seccodeguide.html
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&doc=secbull/201&typ
e=0&nav=sec.sbl&ttl=sec.sbl
Java security bulletin Feb 2001.




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Curt R. Wilson   *   Netw3 Consulting  *   www.netw3.com    |
|    Internet Security, Networking, PC tech,  WWW hosting     |
| Netw3 Security Reading Room : www.netw3.com/documents.html  |
|  Serving Southern Illinois locally and the world virtually  |  
|            netw3 () netw3 com     618-303-NET3                 |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=