Apache Range header DoS vulnerability can be a Security Gateway killer

Linux-based appliance UIs can be vulnerable to a serious Denial of Service vulnerability. I am talking here about the Apache Range header DoS vulnerability from August 2011.

This exploit works by making a series of HTTP requests with overlapping ranges in the "Range" or "Request-Range" request headers and results in memory and CPU exhaustion.

For an unpatched Apache server, in many cases a remote unauthenticated attacker could exploit this issue to make the system unresponsive - with only a few packets.

Now, usually this exploit relates to a webserver hosting a website (or multiple websites) so has a limited scope.

However, in the case where the target is the product UI of a Security Gateway, this can mean that the Gateway becomes unresponsive, and if this is a multi-protocol Gateway or Firewall UI - the attacker could potentially disrupt network connectivity (affecting a whole network, rather than a single system).

I have seen several instances recently where a Security Gateway completely freezes up after a few dozen malicious packets, and the system requires a hard-reset (power-cycle) to recover. All network traffic stopped, and the Web UI and even the console were completely unresponsive.

In each of these cases, the Web UIs were often left exposed to the internet (a simple "Google Dork" found dozens of the affected product UIs exposed to the internet).

The solution to this problem is simple, these products need to be patched, but it seems that various vendors of Security Gateways (and other appliances) are not keeping up with their patch-managment, or are unaware of the problem.

This is an example of how to test for this issue (here using Nmap):

(You need the nmap *.nse script from here if you want to test this http://nmap.org/nsedoc/scripts/http-vuln-cve2011-3192.html )

nmap -Pn -sS --script http-vuln-cve2011-3192 -p T:(port here) (ip address here) --script-args http-vuln-cve2011-3192.path=(vulnerable resource here)

Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-02-11 20:12 GMT
Nmap scan report for
Host is up (0.22s latency).
PORT    STATE SERVICE
(port)/tcp open  https
| http-vuln-cve2011-3192:
|   VULNERABLE:
|   Apache byterange filter DoS
|     State: VULNERABLE
|     IDs:  CVE:CVE-2011-3192  OSVDB:74721
|     Description:
|       The Apache web server is vulnerable to a denial of service attack when numerous
|       overlapping byte ranges are requested.
|     Disclosure date: 2011-08-19
|     References:
|       http://seclists.org/fulldisclosure/2011/Aug/175
|       http://nessus.org/plugins/index.php?view=single&id=55976
|       http://osvdb.org/74721
|_      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
Nmap done: 1 IP address (1 host up) scanned in 3.32 seconds

(It is very important to get the URL to a vulnerable resource correct, otherwise you may miss the issue, GIFs work quite well, but try a few resources)

To be absolutely sure that the vulnerability is exploitable, it can be exploited with Metasploit (make sure you do this in legal and test conditions, such as in a test lab or on a VM you own).

/pentest/exploits/framework/msfcli auxiliary/dos/http/apache_range_dos RLIMIT=50 RHOST=(ip address here) RPORT=(port here) URI=(vulnerable resource here) E

Here is some detail from Apache on how to address the problem:
http://httpd.apache.org/security/CVE-2011-3192.txt

...but if you are a customer using one of the affected appliances, you won't be able to fix this yourself,  you will need to get in contact with your respective vendor, and get them to "pull their finger out" with their patch-management - and then maybe wait a month or so before they fix it.

An update on my research into attacking Security Gateways via the Web UI – and Blackhat Europe

I haven't written much on my blog for the past few months. This is because I have been very busy with my exploit-development research.

A while back I had the idea to combine web-attacks with Security Gateways, mix things up, and see what happens. This has been very productive, and a lot of fun.

In short, over the past 4 months, I have raised 30+ PoC exploits with vendors of Security Gateways. I have looked at quite a few Gateway products, and discovered serious vulnerabilities in almost all of the ones I have investigated.

Whilst Security Gateway products provide good security features for the protocols and services they protect, if a gateway product is not secure in itself, it can be attacked directly and compromised.

If an attacker can gain control of the gateway of an organization, this is a very powerful position for further attacks; such as traffic-sniffing and powerful man-in-the-middle attacks, disabling network protections, and pivoting the attack to target other systems and users on the internal network.

We often take the security of security-software for granted, assuming that – because the software has come from a company that understands security, then the product is very likely to be secure.

This is frequently an incorrect assumption in regard to Security Gateway UIs, as usually the developers that design, code and test the UI are not “security” people, and are more focused on UI design, functionality, usability, supportability and branding, than on security.

There are a huge variety of web application attacks that have been historically used against public-facing websites and their users. Many of these attacks are transferable to web-based product UIs, and this can have a very interesting impact when applied to Security Gateway UIs.

Most of the serious issues I have found in Security Gateway products have been caused by one or more of the following:

• Lack of input-validation (leading to attacks such as XSS and Command-injection)
• Predictable URLs and parameters (and therefore CSRF)
• Excessive privileges of running services
• Direct file browsing
• Session-management issues
• Weak session-tokens
• Password Guessing
• Authentication bypass
• Verbose information disclosure
• Out-of-date 3rd party software
• Arbitrary file upload
• Standard installs with poor configurations
• Trivial Denial of Service vulnerabilities

I am currently working to complete a white-paper detailing some of the common findings, and I have recently been informed that I have been accepted to speak at Blackhat Europe on this subject. I will release the white-paper at Blackhat, so more information to come...

http://www.blackhat.com/html/bh-eu-12/bh-eu-12-briefings.html#williams

... and if you are going to Blackhat Europe, I might see you there!

Practicing scanning and basic enumeration skills with a Solaris VM

I'm pretty comfortable hacking-around with Linux, Windows and Macs, but one of the platforms I have not used much (so far) is Solaris.

I love learning new things, so this seemed like a gap worth filling, especially as I am looking to take the Check CRT certification (in which Solaris/Oracle are a small part of the syllabus).

I had a bit of a play with OpenSolaris a while back, which gave me a flavor of some of the differences between Linux an Solaris (incidentally the OpenSolaris project seems to be stalled/ending?).

Anyway, I thought I would download the Solaris/Oracle VMs from from the following location and have a play (starting with some basic scanning):

http://www.oracle.com/technetwork/server-storage/solaris/solaris-vm-405695.html

(You need to register with Oracle to download these images)


Setting up a Solaris box

Once the Solaris10_9-10_VM.zip image is downloaded, unpack it with:

unzip Solaris10_9-10_VM.zip

Start VirtualBox, and import the appliance with:

File > Import > select the *.ovf file (and follow the rest of the menu)

Once this is imported you can start the VM and you will get to the following Solaris setup menu.

(Use F2 and F4 to continue through the menus)

Work through these menus, and in around 20 minutes you will be able to login, and will have a working Solaris system:

(Mmmm... lovely; dull grey and purple)

Managing services

Solaris services are managed differently from services in Linux, by using the "svcadm" tool.
So to go ahead and setup some extra services and scan the system:

To set up an apache webserver:

cd /etc/apache2
cp httpd.conf-example httpd.conf

svcadm -v enable /network/http:apache2

.. and check it's running:

svcs -p /network/http:apache2
STATE          STIME    FMRI
online         10:51:52 svc:/network/http:apache2
               10:51:52     1991 httpd
               10:51:53     1992 httpd
               10:51:53     1993 httpd
               10:51:53     1994 httpd
               10:51:53     1995 httpd
               10:51:53     1996 httpd

Let's also start some other (unnecessary and potentially insecure) services, to expand our target a bit:

svcadm enable network/telnet
svcadm enable network/ftp
svcadm enable network/finger


Scanning with nmap

First lets try a basic scan:


nmap 192.168.1.69


Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2011-08-29 19:28 BST
Nmap scan report for 192.168.1.69
Host is up (0.00052s latency).
Not shown: 994 closed ports
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
23/tcp  open  telnet
79/tcp  open  finger
80/tcp  open  http
111/tcp open  rpcbind
MAC Address: 08:00:27:33:49:19 (Cadmus Computer Systems)


Nmap done: 1 IP address (1 host up) scanned in 27.71 seconds


So we can see the services I added there, also it looks like ssh (and rpcbind) had been enabled by default.

Now for a more thorough scan using the NSE scripts


nmap --script all 192.168.1.69


Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2011-08-29 19:23 BST
Nmap scan report for 192.168.1.69
Host is up (0.0010s latency).
Not shown: 994 closed ports
PORT    STATE SERVICE
21/tcp  open  ftp
|_ftp-bounce: no banner
22/tcp  open  ssh
|_banner: SSH-2.0-Sun_SSH_1.1.3
| ssh-hostkey: 1024 78:af:4e:c7:67:0e:18:9b:da:77:c4:6d:c0:a7:1b:7d (DSA)
|_1024 a5:92:ed:16:f5:fc:26:8b:18:d4:5e:b5:9d:0c:21:3b (RSA)
23/tcp  open  telnet
79/tcp  open  finger
80/tcp  open  http
| http-brute:   
|_  ERROR: No path was specified (see http-brute.path)
|_citrix-brute-xml: FAILED: No domain specified (use ntdomain argument)
| http-methods: Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html
|_http-trace: TRACE is enabled
|_http-date: Mon, 29 Aug 2011 18:24:32 GMT; +1s from local time.
| http-headers: 
|   Date: Mon, 29 Aug 2011 18:24:34 GMT
|   Server: Apache/2.0.63 (Unix) DAV/2
|   Content-Location: index.html.en
|   Vary: negotiate,accept-language,accept-charset
|   TCN: choice
|   Last-Modified: Sun, 21 Nov 2004 14:35:21 GMT
|   ETag: "4614-5b0-a64a7c40;462a-961-a64a7c40"
|   Accept-Ranges: bytes
|   Content-Length: 1456
|   Connection: close
|   Content-Type: text/html
|   Content-Language: en
|   
|_  (Request type: HEAD)
| http-form-brute: 
|_  ERROR: No passvar was specified (see http-form-brute.passvar)
|_http-title: Test Page for Apache Installation
|_http-wp-plugins: nothing found amongst the 100 most popular plugins, use --script-arg http-wp-plugins.search= for deeper analysis)
| http-domino-enum-passwords:   
|_  ERROR: No valid credentials were found (see domino-enum-passwords.username and domino-enum-passwords.password)
111/tcp open  rpcbind
MAC Address: 08:00:27:33:49:19 (Cadmus Computer Systems)


Host script results:
|_dns-brute: Can't guess domain of "192.168.1.69"; use dns-brute.domain script argument.
|_path-mtu: PMTU == 1500
|_ipidseq: Unknown
| qscan: 
| PORT  FAMILY  MEAN (us)  STDDEV   LOSS (%)
| 1     0       732.20     508.23   0.0%
| 21    0       1143.80    853.92   0.0%
| 22    1       1236.80    734.74   0.0%
| 23    1       1248.10    782.83   0.0%
| 79    0       1065.30    794.20   0.0%
| 80    1       1297.50    742.94   0.0%
|_111   1       1577.30    1092.91  0.0%


Nmap done: 1 IP address (1 host up) scanned in 118.38 seconds

That didn't find a great deal extra except that the TRACE option is also enabled, which means that XST (cross-site tracing, a client-side attack) is potentially possible against old browser versions (though this attack is no-longer possible against the majority of modern browsers).

The SSH banner also reveals that we have a Solaris system.

Scanning with Nikto

We can scan the webserver with Nikto using the following command:

./nikto.pl -host 192.168.1.69

- Nikto v2.1.4                                                                                                                                                                                                                    

---------------------------------------------------------------------------                                                                                                                                                      

+ Target IP:          192.168.1.69                                                                                                                                                                                                

+ Target Hostname:    192.168.1.69                                                                                                                                                                                                

+ Target Port:        80                                                                                                                                                                                                          

+ Start Time:         2011-08-30 19:59:48                                                                                                                                                                                        

---------------------------------------------------------------------------                                                                                                                                                      

+ Server: Apache/2.0.63 (Unix) DAV/2                                                                                                                                                                                              

+ Apache/2.0.63 appears to be outdated (current is at least Apache/2.2.17). Apache 1.3.42 (final release) and 2.0.64 are also current.                                                                                           

+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE                                                                                                                                                                          

+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST                                                                                                                                                

+ OSVDB-2117: /: Appears to be a default Apache install.                                                                                                                                                                          

+ OSVDB-3092: /manual/: Web server manual found.                                                                                                                                                                                  

+ OSVDB-3233: /index.html.ca: Apache default foreign language file found. All default files should be removed from the web server as they may give an attacker additional system information.

... etc ...

+ OSVDB-3233: /index.html.var: Apache default foreign language file found. All default files should be removed from the web server as they may give an attacker additional system information.

+ OSVDB-3233: /cgi-bin/printenv: Apache 2.0 default script is executable and gives server environment variables. All default scripts should be removed. It may also allow XSS types of attacks. http://www.securityfocus.com/bid/4431.

+ OSVDB-3233: /cgi-bin/test-cgi: Apache 2.0 default script is executable and reveals system information. All default scripts should be removed.

+ OSVDB-3268: /icons/: Directory indexing found.

+ OSVDB-3268: /manual/images/: Directory indexing found.

+ OSVDB-3233: /icons/README: Apache default file found.

+ 6448 items checked: 2 error(s) and 36 item(s) reported on remote host

+ End Time:           2011-08-30 20:01:05 (77 seconds)

---------------------------------------------------------------------------

+ 1 host(s) tested

As you can see, there is various default content there from my Apache install (this should all be removed in a production website, to prevent attackers from gaining extra information. Additionally we can see that we have an old version of Apache.

Scanning with Nessus

Now for a scan with Nessus to see what that can see:

In the Nessus report, there is a "High Severity" Denial of Service vulnerability for Apache.

This is a fairly recent exploit that many sites and services are currently vulnerable to. More information on this vulnerability is available at the following location:

http://archives.neohapsis.com/archives/fulldisclosure/2011-08/0203.html

Also, there are various information disclosure issues from the other running services (FTP, Telnet, Finger, SSH) which give us OS and service versions, and username information.


Finger and fingerd enumeration with a basic "for" loop

Nobody installs fingerd these days if they want to be secure (but hey, I trying to make the target bigger and practice some enumeration).

Nessus found the user root using finger, but is is also possible to find other accounts. This version of the finger daemon searches the user description in addition to the username, so you can also find users via words in the description as well.

Here is how to install the finger client on Backtrack and run a couple of different queries:

apt-get install finger


finger root@192.168.1.69
[192.168.1.69]
Login       Name               TTY         Idle    When    Where
root     Super-User            console        2 Mon 07:55  :0                  
root     Super-User            pts/3          2 Mon 08:29  :0.0                

finger user@192.168.1.69

[192.168.1.69]

Login       Name               TTY         Idle    When    Where
nobody   NFS Anonymous Access               < .  .  .  . >
noaccess No Access User                     < .  .  .  . >
nobody4  SunOS 4.x NFS Anonym               < .  .  .  . >


So, if there were other users on the system, we could try a dictionary attack to find them using finger in a "for" loop.

Given a list of names in "usernames.txt", we can use the following commandline for loop to iterate through them, and strip out anything found, dumping it to a file:

for name in $(cat usernames.txt); do finger $name@192.168.1.69 | awk 'NR!=1 && NR!=2' | grep -v ??? | cut -d " " -f1 | sort -u >> foundnames.txt; done

cat foundnames.txt | sort -u

adm

gdm

listen

lp

noaccess

nobody

nobody4

nuucp

postgres

root

smmsp

svctag

uucp

webservd

This could be a useful enumeration, which might make a dictionary attack against SSH (for example) a lot quicker.

Setting up Nessus in Backtrack 5 R1

In an earlier post I described how to setup Nessus on Backtrack 5:

http://insidetrust.blogspot.com/2011/05/easy-nessus-scan-for-beginner-with.html

For some reason, BT 5 R1 does not come with Nessus installed by default, but it's easy to download and install.

You will need to download Nessus from the following location:

http://www.tenable.com/products/nessus/select-your-operating-system

(I used the Debian 64 bit package)

Then install it with the following command:

dpkg -i Nessus-4.4.1-debian5_amd64.deb

Then you can simply follow the rest of the instructions in my original post.

Update - Of course, there is an easier way to do this ;o)

apt-get install nessus