Release by US-CERT. Another protocol downgrade attack. Similar to the OpenSSH downgrade attack from years ago. Of course, OpenSSL is the culprit again, as was with Heartbleed. What's the point of providing broken security for "legacy" reasons? It's broken.

Link with details of the issue: https://www.us-cert.gov/ncas/alerts/TA14-290A

Yet another exploit for one of the "everything and the kitchen sink" CMS. It really goes to show how wonderful dynamically typed languages are for security, especially PHP which is basically stochastically typed.

Another thing which has no effect on me, since I wrote this from scratch and I'm not stupid enough to construct objects directly from user input and pass them into an SQL generation function that sets the column names.

The best part is the description of what the exploit targets from Drupal's official site:

"Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks."

How's that working out for you? Prepared queries, careful programming and flattening objects before passing them directly into the field list would have prevented all of this.

Details of the issue here: https://www.drupal.org/SA-CORE-2014-005

Not affected because of suhosin + nginx + OpenBSD, chroot, extremely restrictive firewall and /dev/null as shell for nginx/php-fpm/pgsql user. Go layered security.

This whole thing seems blown out of proportion. If you're vulnerable to this you've been vulnerable to many other things for a while. This is simply easier as a mass-scan-and-exploit approach.

iptables is a little awkward if you're not used to it. The way that it works is that it attempts to match events against an ordered list of rules, and if none match then the default policy is used for that chain. iptables stops processing the list once there's a match, so if you have a very general rule at the top it will frustrate you when everything is allowed/blocked for seemingly no reason.

Here's a script to allow traffic from a physical interface (wlan0 or eth0) to just one IP (which could be a VPN IP).

#!/bin/bash

# Set your LAN subnet here
LANIP='192.168.1.0/24'

# Set the allowed destination IP (or IP range), port and protocol
DSTIP='8.8.8.8/32'
DSTPORT='1194'
DSTPROT='udp'

# flush all previous rules (reset iptables)
iptables -F

# drop INPUT and FORWARD if not matched (-P stands for policy, we're setting the default policy to DROP the packet if nothing below is matched)
iptables -P INPUT DROP 
iptables -P FORWARD DROP

# allow established sessions and localhost traffic (many programs rely on localhost connections)
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT

# allow LAN traffic and traffic going to the VPN
iptables -A OUTPUT -d $LANIP -j ACCEPT
iptables -A OUTPUT -d $DSTIP -p $DSTPROT -m $DSTPROT --dport $DSTPORT -j ACCEPT

# drop everything else (on the real devices)
iptables -A OUTPUT -o wlan0 -j DROP
iptables -A OUTPUT -o eth0 -j DROP

Basically, the above says that anything to/from localhost, or anything that has either a LAN IP or the DST IP as its destination in the packet header will be allowed. Everything else going out of the wlan0 and eth0 devices is caught by the last two rules, and is dropped. Be careful about the order that you write these rules in, if I had put the last two rules at the top (after the -F rule), then ALL traffic would get instantly dropped, because those are two very general rules and they will match every single packet that leaves either interface. Once a rule is matched, later rules are not processed, and along with the two INPUT and FORWARD DROP policies at the top, I'd have isolated the OS from the network completely.

-A in the rules means append, so append to the chain OUTPUT or INPUT (this puts the rule at the bottom, as opposed to -I which stands for insert, and places the rule at the top, to be evaluated before any other rule). The line -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT is important otherwise we cannot get input responses from connections we open to the LAN, since the default INPUT policy is to drop. In the rest, -s stands for source (the source IP in the packet header), -d stands for destination (again, destination IP in the packet header), -p specifies the protocol (UDP or TCP, most of the time), and -j specifies the action to be taken if the rule matches, either ACCEPT (allow the packet) or DROP it. In the last two lines, -o signifies the output interface, the interface that the packets are being sent from, just as -i in the line for localhost means input interface. --dport is of course just destination port.

Why do all packet capture tools do things you never ask them to do? It took me a while to figure out how to get clean streams using just tshark from pcap files. Here's the script:

#!/bin/bash

if [ "$#" -lt 1 ]; then
        echo "Usage: tshark_strams.sh <pcap file> [filter rules]"
        exit
fi

if [ ! -z "$2" ]; then
        STREAMS=$(tshark -r "$1" -R "$2" -T fields -e tcp.stream | sort -n | uniq)
else
        STREAMS=$(tshark -r "$1" -T fields -e tcp.stream | sort -n | uniq)
fi


for i in $STREAMS
do 
        INDEX=`printf '%.5d' $i`

        echo "Processing stream $INDEX ..."

        tshark -r "$1" -T fields -e data -qz follow,tcp,raw,$i | tail -n +7 | tr -d '=\r\n\t' | xxd -r -p > "$1"_stream-$INDEX.bin
        tshark -r "$1" -qz follow,tcp,ascii,$i > "$1"_stream-$INDEX.txt
done

This takes a pcap file generated from wireshark, tshark, tcpdump (or anything that outputs libpcap files) and creates two files for each socket stream. First, a .txt file that contains an ASCII representation of the packet, so that non-printable characters are substituted -- unfortunately it also seems to like mixing in packet byte size numbers prefix by a tab before each packet, and it seems this is impossible to disable, so I've also fixed it to generate a .bin file that stores just the raw stream and nothing else. Don't dump the .bin files to the console if you've captured binary data, use xxd, hexdump, hexedit, or even something like vim.

There is also an optional argument which is the filter, so if you run it as ./tshark_streams.sh capture.pcap "http" it dumps only HTTP streams. See Capture Filter Examples for what you can use.

Here's an example run on wget packet capture for this blog, along with a cat for each generated file:

$ ./tshark_streams.sh example.pcap "http"
Processing stream 00000 ...

$ cat example.pcap_stream-00000.txt

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 10.9.0.26:40667
Node 1: 174.136.97.90:80
94
GET / HTTP/1.1
User-Agent: wget
Accept: */*
Host: heapspray.net
Connection: Keep-Alive


        1324
HTTP/1.1 200 OK
Server: Anonymous
Date: Mon, 19 May 2014 06:41:40 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
[...]

$ cat example.pcap_stream-00000.bin | head -n 20
GET / HTTP/1.1
User-Agent: wget
Accept: */*
Host: heapspray.net
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: Anonymous
Date: Mon, 19 May 2014 06:41:40 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding

3fa0

As can be seen, the .txt has a header and random packet size numbers mixed in throughout, whereas the .bin file is purely the raw stream. Since wget uses HTTP 1.1 by default the server responds in with chunked mode transfer encoding, so the hexadecimal numbers are the chunk headers and sizes, but the offset decimal numbers (i.e., the "94" and " 1324" in the first file) represent the sizes of the received TCP packets. Useful for debugging your networking applications, but they get in the way if you're just trying to analyze the raw stream, so I've had it generate the raw .bin file as well.

For completeness, the command I used to capture the wget request was:

$ tshark -i tun0 -w example.pcap
Capturing on tun0
53 ^C

Simply CTRL+C when you are finished capturing, tshark ends the session gracefully. The -i option specifies the interface. On most systems it will be either eth0 if you use a wired, ethernet connection, or wlan0 if you use a wireless connection. Use ifconfig to check. I use a VPN so therefore my device is tun0, for network TUNnel.