Next message: Curt Wilson: "Re: Penetration test report - your comments please?"
hola,
considering only three hours time this report is more than complete :-)
given a bit more time .. i would add a report on found web-forms, server-
and web-applications (cgis,applets,jsps aso..) and "possible"
techniques to exploit these ..
also i would do a quick subnet scan even if i was told to check a specific
host. it is (often)very likely to find routers and servers in the same
subnet vulnerable to manny attacks and trusted by our main-target :-)
nice day,
rudicarellat_private
http://www.freefly.com/security/
>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.>/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.>: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 <rudicarellat_private>
>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.>/<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 |
>| netw3at_private 618-303-NET3 |
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
This archive was generated by hypermail 2b30
: Thu May 31 2001 - 13:38:52 PDT