Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Botnet Security

First Shellshock Botnet Attacking Akamai, US DoD Networks 236

Bismillah writes The Bash "Shellshock" bug is being used to spread malware to create a botnet, that's active and attacking Akamai and Department of Defense networks. "The 'wopbot' botnet is active and scanning the internet for vulnerable systems, including at the United States Department of Defence, chief executive of Italian security consultancy Tiger Security, Emanuele Gentili, told iTnews. 'We have found a botnet that runs on Linux servers, named “wopbot", that uses the Bash Shellshock bug to auto-infect other servers,' Gentili said."
This discussion has been archived. No new comments can be posted.

First Shellshock Botnet Attacking Akamai, US DoD Networks

Comments Filter:
  • Confused. (Score:5, Funny)

    by msauve ( 701917 ) on Thursday September 25, 2014 @07:49PM (#47998767)

    Italian security consultancy Tiger Security, Emanuele Gentili, told iTnews. 'We have found a botnet that runs on Linux servers, named "wopbot"

    Italian? wopbot?

    I'm at a loss for words - other than that seems offensive, even for non-politically-correct me.

  • its on ! (Score:4, Interesting)

    by johnjones ( 14274 ) on Thursday September 25, 2014 @07:53PM (#47998793) Homepage Journal

    no venerability should be without a logo :

      https://twitter.com/johnjonesname [twitter.com]

  • by Anonymous Coward on Thursday September 25, 2014 @08:03PM (#47998847)

    priceless excerpt: |The US DoD network in question is the 215.0.0.0/8 range, with approximately 16.7 addresses."

  • ... how many [wikipedia.org] Linux servers are there?

  • From TFA:

    The US DoD network in question is the 215.0.0.0/8 range, with approximately 16.7 addresses.

    Bold is mine.

  • by dskoll ( 99328 ) on Thursday September 25, 2014 @08:25PM (#47998995) Homepage

    The screenshot in that article shows the shell prompt as "root@debian". But in reality, most Debian systems use "/bin/dash" as the default system shell instead of /bin/bash, which means most Debian systems are extremely hard to compromise; a CGI or system() call would have to go out of its way to invoke bash instead of dash.

    • You assume that you can only get to root through the path that login and su take. Running a program as root, like your dhcp client, then having it launch a shell script that has "#!/bin/bash" is sufficient to get there. and no step along the way were you in the dash environment.

      • by dskoll ( 99328 )

        Didn't I just say that? You'd have to explicitly invoke #!/bin/bash. I know of very few scripts that do that; most use #!/bin/sh.

        • by AlterEager ( 1803124 ) on Friday September 26, 2014 @08:33AM (#48001553)

          Didn't I just say that? You'd have to explicitly invoke #!/bin/bash. I know of very few scripts that do that; most use #!/bin/sh.

          Well, on my Debian unstable machine:


          # find / -mount -type f | while read x ; do if [ "`head -1 $x | grep '^#\!/bin/bash'`" ]; then echo $x; fi; done 2>/dev/null
          /bin/zdiff
          /bin/fgrep
          /bin/zgrep
          /bin/zless
          /bin/zfgrep
          /bin/uncompress
          /bin/zcmp
          /bin/gzexe
          /bin/gunzip
          /bin/zegrep
          /bin/zforce
          /bin/zmore
          /bin/zcat
          /bin/egrep
          /bin/znew
          /etc/bash_completion.d/pulseaudio-bash-completion.sh
          /etc/auto.net
          /etc/auto.smb
          /etc/init.d/minissdpd
          /etc/init.d/nfs-common
          /var/lib/dpkg/info/bash-completion.postinst
          /var/lib/dpkg/info/grub-pc.preinst
          /var/lib/dpkg/info/grub-pc.postrm
          /var/lib/dpkg/info/ca-certificates-java.postinst
          /var/lib/dpkg/info/gdm3.prerm
          /var/lib/dpkg/info/desktop-base.postinst
          /var/lib/dpkg/info/grub-pc.postinst
          /var/lib/dpkg/info/bash-completion.postrm
          /var/lib/dpkg/info/grub-pc.prerm
          /var/lib/dpkg/info/dash.preinst

          Ugly.

  • Only the beginning (Score:5, Informative)

    by Solozerk ( 1003785 ) on Thursday September 25, 2014 @08:33PM (#47999045)
    It's not the only botnet being constructed, see my comment here [slashdot.org] - already 653 exploited servers there right now.
    This is quite bad - as long as a bash CGI script is found by probing, exploiting only require putting a bash command in a header such as "Cookie:" for it to be executed. And this is only through HTTP - there are also aready other proof of concepts exploiting this through other bash-using services (DHCP servers [trustedsec.com] for example).
    You can check if you've been scanned for exploitable CGIs using something like (adjust apache logs path accordingly):

    grep cgi /var/log/apache2/access*|egrep "};|}\s*;"

    And you can check if your bash is vulnerable using:

    env x='() { :;}; echo vulnerable' bash -c 'echo Testing...'

    If 'vulnerable' appears, it is.
    • by Imagix ( 695350 )
      That's DHCP clients, not DHCP servers.
    • I saw scans today starting just after noon Pacific Time.

    • by geckoFeet ( 139137 ) <gecko@dustyfeet.com> on Thursday September 25, 2014 @10:25PM (#47999635)

      Yay! I have been scanned - but my little webserver doesn't run any cgi scripts, so they got 404'd. They were looking specifically for defaultwebpage.cgi:

      root@stinky:/home/gecko# grep cgi /var/log/apache2/access*|egrep "};|}\s*;" /var/log/apache2/access.log:89.207.135.125 - - [25/Sep/2014:02:28:52 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 319 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

      • My company servers were scanned within seconds of each other by the same IP as you, log extract below:
        /var/log/httpd/access_log:89.207.135.125 - - [25/Sep/2014:08:07:05 +0100] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 224 "*/*" "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
    • ...You can check if you've been scanned for exploitable CGIs using something like (adjust apache logs path accordingly):

      grep cgi /var/log/apache2/access*|egrep "};|}\s*;"

      And you can check if your bash is vulnerable using:

      env x='() { :;}; echo vulnerable' bash -c 'echo Testing...'

      If 'vulnerable' appears, it is.

      Thank you for the grep. When I ran it on my little web site I found I had been probed. The log line looked like this:

      89.207.135.125 - - [25/Sep/2014:01:53:59 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 224 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

      I wonder what would happen if we all starting pinging that last IP address.

  • by m.dillon ( 147925 ) on Thursday September 25, 2014 @09:07PM (#47999281) Homepage

    It's that simple. Even with the patches, bash is still running the contents of environment variables through its general command parser in order to parse the procedure. That's ridiculously dangerous... the command parser was never designed to be secure in that fashion. The parsing of env variables through the command parser to pass sh procedures OR FOR ANY OTHER REASON should be removed from bash outright. Period. End of story. Light a fire under the authors someone. It was stupid to use env variables for exec-crossing parameters in the first place. No other shell does it that I know of.

    This is a major attack vector against linux. BSD systems tend to use bash only as an add-on, but even BSD systems could wind up being vulnerable due to third party internet-facing utilities / packages which hard-code the use of bash.

    -Matt

    • You're a developer so you should know more ;) I mostly use zsh myself, but I'm curious as to what benefit or convenience feature this behavior gives to bash? Also are "normal" uses vulnerable or just web servers?
  • Amazing... (Score:2, Interesting)

    by Anonymous Coward

    ... how the indignation at a major vulnerability like this (2nd in a few months) is so muted when the OS in question doesn't come from Microsoft.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      It's muted because despite this being a major security flaw that's been around since almost the dawn of the internet, it was patched and fixed in less than 24 hours once found.

      The indignation is deservedly loud and strong when the a major security flaw is found and it sits on the world's computers to be exploited until the patch Tuesday, several months from now, and only after shaming vendors to acknowledge it.

      There's nothing amazing about it.

      • Re:Amazing... (Score:5, Interesting)

        by ray-auch ( 454705 ) on Friday September 26, 2014 @07:28AM (#48001301)

        1. the first fixes, within 24 hours of announcement, didn't actually fix it fully - in fact I suspect it will still be exploitable in some way or other until the "feature" of treating environment variables as code is removed completely
        2. providing an incomplete fix may be worse than taking a bit longer to properly QA the fix - a lot of admins may believe they have patched this based on the first announced vulnerability tests and the first set of patches, but in fact they are still vulnerable with a trivial change in the malicious bash code
        3. it was less than 24 hours after first being made public - this may be entirely unrelated to when it was first found

        We have no idea who found it first or for how long it may have been used covertly (did NSA etc. know of heartbleed before public knowledge ?)
        We don't know what prompted someone to be looking for problems in code that hasn't changed for 20+ yrs.
        It is so trivial to get remote code run with this bug (no unexpected new process or login or errors) that I doubt it will trip any intrusion detection systems.
        If you can use an http header that isn't logged, then you could run code on the server and extract information and it may be completely undetectable.

        Something else we don't know is how the FBI really got the Silk Road server to cough its real IP address. The FBI claim they put "miscellaneous characters" into the login form and it just happened to send the address back. You can believe that if you want. It may or may not be related (I have no idea about the silk road server setup), but a handful of days after the FBI put their story out someone is looking for security holes / bugs in very old bash code. Maybe there was no trigger and they just happened to get bored one day and decide that looking for bugs in bash would be fun. Or maybe there is more behind this than we know.

    • Re: (Score:2, Interesting)

      by Spy Handler ( 822350 )

      Windows users generally don't have a chip on their shoulder.

      Linux users generally hate Windows a lot more than Windows users hate Linux.

      • by sjames ( 1099 )

        That's because Windows users don't tend to get Linux foisted upon them or have some device or another they want say "sorry, Linux only".

        Windows users don't have problems with Linux systems refusing to interoperate.

        • That's because Windows users don't tend to get Linux foisted upon them or have some device or another they want say "sorry, Linux only".

          Mine do.

          Bwahahaha!

    • Re:Amazing... (Score:4, Informative)

      by DrugCheese ( 266151 ) on Friday September 26, 2014 @03:54AM (#48000771)

      Bash is an OS? You can uninstall bash and have everything run just as smooth with a replacement shell. Unlike a certain OS where you can't even remove a web browser and expect it to boot up ...

  • by itamblyn ( 867415 ) on Friday September 26, 2014 @12:28AM (#48000093) Homepage
    If shellshock lets remote users execute arbitrary shell commands, should we just run a scan of the whole internet (https://github.com/robertdavidgraham/masscan), and issue apt-get update & apt-get upgrade? Use the bug to patch the bug?
  • by jones_supa ( 887896 ) on Friday September 26, 2014 @01:22AM (#48000333)
    Just the other day I commented [slashdot.org] in a SystemD discussion how scripts break easily and are slow to execute. One of the replies I got was "Scripts don't break themselves. They do exactly what you tell them to do." Heh, indeed they do. Didn't we just hear about one Shellshock-related attack where a malicious DHCP server can command a dhclient script do nasty things. Scripting is a problem and binary modules would provide more robust interfaces. It is a thing worth giving a thought.
  • by ThePhilips ( 752041 ) on Friday September 26, 2014 @06:36AM (#48001205) Homepage Journal

    If the systems really had the /bin/bash exposed, then they were insecure from the day one. It is just that nobody had realized that before.

    Otherwise I wonder whether the Debian's /bin/sh being the dash somehow mitigated the problem for the Debian system?

As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie

Working...