back to article Bored hackers flick Shellshock button to OFF as payloads shrink

Malicious and benign attacks against systems vulnerable to Shellshock had halved by Sunday after peaking three days following the bug's disclosure, Akamai researchers say. The variety of payloads targeting vulnerable sites increased dramatically over the same period before tapering off, in a possible sign that hackers were …

  1. Anonymous Coward
    Anonymous Coward

    OK, I can't follow this one.

    On the one hand, we're told attacks are already tapering off. That has IMHO nothing to do with "boredom" (malicious hacking is about making money, not being bored), but suggests that the payoff is less than expected. Every time someone tries to hack a system, it flags them as a malicious entity so you don't waste the times you stick your head above the parapet (at least, I wouldn't if I was maliciously and criminally inclined) - a lack of result is a good argument to find something else to do.

    On the other hand, we get these messages that it's far from over and doom may yet descend. I don't buy that. There is no quantitative data that outlines exactly why this wave is over, I can only venture that this was a vulnerability that was a lot easier to fix than Heartbleed, and that many people have reacted to the urgency and have availed themselves of the ability of Open Source based platforms to put an interim fix in before the official patches came through.

    After all, the patches were not exactly rocket science, and most of the people who are exposed to any version of Unix have a passing familiarity with checking code signatures and compiling - even in OSX it costs nothing to add those resources in the form of Xcode.

    As I said, this is but an as yet unconfirmed theory and I only have the feedback of colleagues and my own experience to back this up with, but it strikes me as a more plausible reason than "boredom". That's just plain weak.

    1. No, I will not fix your computer

      Re: OK, I can't follow this one.

      I suspect it's just because there's very little pay off, even on vulnerable systems, the potentially most vulnerable say a website cgi would need to be running bash, and it's not a very common thing these days, if there's cgi it's more likely to be a language designed for cgi.

      And of course, the more obscure (e.g. F5 admin interface) the less likely that it will be visible to all on the 'net.

      The down side is that the big systems (like RHEL) will be patched up quickly and everybody will stop panicking, and the more obscure systems will be left unpatched and become part of more complex multi-stage attacks (e.g. packet fragmentation vulnerability through a firewall, subsequently attacking a router admin interface via shellshock which creates echo ports etc.).

      1. Ben Tasker

        Re: OK, I can't follow this one.

        >I suspect it's just because there's very little pay off, even on vulnerable systems, the potentially most vulnerable say a website cgi would need to be running bash,

        The CGI doesn't need to be running BASH, but BASH does need to be called at some point. If the malicious data is added to the environment (perhaps because you're chucking request headers into environment variables) then that's more than sufficient.

        Lots of Webhosts offer servers with CPanel - which included 2 vulnerable (and accessible without authentication) perl scripts, so it's not even the 'admin' who needs to have fucked up. One request = reverse shell and the rest is down to the skill of the attacker on any CPanel box that hasn't been updated (or those scripts disabled)

        Even with that, there's very little payoff now - it was pretty high profile and most have patched.

    2. Flocke Kroes Silver badge

      Number of _unique_ payloads ...

      There is some evidence of boredom: the number of unique payloads peaked on the 27ᵗʰ. Before that, people were creating and debugging new exploits. After that, the only new people trying to join the party were script kiddies.

      One of the fun things about this flaw was it only required basic knowledge of bash scripting, CGI and Google fu to play with on your own network. You could get results in under a minute. Having enough knowledge to route the attack through the neighbour's open wifi and Tor (or not caring about being on the NSA's shit list) cut the numbers down to about 10,000 (assuming most of them got the code right by the second attempt).

      Heart bleed would have required understanding cryptography, reading the source code, developing some complex software in a compiled language and using lots of network bandwidth. Like most security flaws, it wasn't something I could play with in my tea break. Now that everyone with a clue has patched, I might have to spend all day next door to the library's wifi to find a machine vulnerable to shellshock. Only people set up to profit from a botnet are going too bother.

      If there is a next round, it will involve machines that are tricky to patch. That would point at embedded systems if most of them weren't too small for bash. Apparently some NAS boxes are vulnerable, but people dumb enough to put unencrypted SAMBA or NFS on the internet store their selfies in the cloud with easy to guess forgotten password recovery questions.

      1. eulampios

        Re: Number of _unique_ payloads ...

        >> Now that everyone with a clue has patched, I might have to spend all day next door to the library's wifi to find a machine vulnerable to shellshock.

        You'd have to spend many days or even months even before that, otherwise you had hacked that wifi router already. Please don't take the sensationalists literally: for a regular Linux desktop user the dhclient-script was the single possible vector. For Mac OS X, *BSD and the rest there were none! As for those who have gone against the clear warning to abstain from using a shell for cgi while taking input from the outside world, they are not regular cgi users, they are just dumb server admins and you won't find them connected to your library wifi router.

      2. akeane

        Re: Number of _unique_ payloads ...

        >Heart bleed would have required understanding cryptography, reading the source code, developing some complex software in a compiled language

        My God!!! Understanding a compiled langage && linking a library && a server side boundary error, only the `le3Tist hacker could master such a complex task!

        To be fair to the hackers though, I would be bored at this point. (CD tray funny though ;-)

        && to be far to the original poster, software engineering (to the point where you are writing generic libaries) is a very niche (hence an already expensive proposition, now include security experts into the mix (good ones) is even more)) so the beancounters start moaning about the beans...

        TL:DR Exploiting "Heart bleed" requires nothing than writing a small C program; beancounters know the cost of everything and the valueof (! much else)

        Achtung!

  2. WonkoTheSane Silver badge
    Linux

    Outcome as expected

    This is why patches should be issued ASAP, instead of waiting for the first Tuesday of next month.

    1. PCS

      Re: Outcome as expected

      That's Microsoft. Nothing to do with bash.

      Numpty.

      1. Anonymous Coward
        Anonymous Coward

        Re: Outcome as expected

        That's Microsoft.

        No no... I think he was trying to say: "The relatively good outcome of shellshock proves that security patches need to be released ASAP, unlike MS"

        I'll add that in the time it's taken for the attack attempts to fade away, we'd still be waiting for MS to release some type of fix (perhaps at the most PR friendly timing). That's assuming they'd even announce the flaw.

        We've waited months for security fixes from MS, that were currently being exploited.

        1. WonkoTheSane Silver badge

          Re: Outcome as expected

          You understood me perfectly. PCS, not so much!

  3. Anonymous Coward
    Linux

    "Akamai found eight percent of payloads were attempts by internet idiots to exploit Shellshock to open CD trays, play audio files, and dump nonsensical payloads."

    Haha - that made me laugh.

    BTW, keep an eye on the bash patches directory over at gnu.org - another patch released yesterday - up to bash-0029 now for 4.3

    1. Anonymous Coward
      Devil

      likewise

      But the most important piece of the pie was the <1% that were exploit-and-patch. Which raises the question, were they modifying iptables rules, /etc/[passwd|shadow] or the login binary at the same time?

      That would be a trick, hack the system to give yourself acess and then patch it...this would do two things: 1) give the admins a very false sense of security and 2) keep the hacked hosts to themselves.

      1. phil dude
        Linux

        Re: likewise

        thanks i'll check that ;-) none of my machines face the internet, but I like the logical paranoia...

        I believe modern linuxs check for that sort of things (AppArmor)... I also use rkhunter and it complains about the odd change that I was not expecting (e.g. new user created).

        But many tools are now installing themselves with a new user and /bin/false or /bin/nologin to lessen exploits.

        Any good exploits found in the wild?

        P.

        1. Brian Miller

          Re: likewise

          Yes, exactly, have any exploits been found in the wild?

          I want to see who has actually been pwned by this, and how badly they misconfigured their system in order for the exploit to occur. There are a lot of exploits that happen simply due to poor configuration, like not scrubbing inputs, and using Bash (instead of sh or Dash) with too many privileges, and many other things. I don't want to see honeypots or theoretical vulnerabilities from security researchers, I want a real case of a system getting hacked by this.

          1. AlbertH

            Re: likewise

            I can answer that - practically zero.

          2. Anonymous Coward
            Anonymous Coward

            Re: likewise

            > I want to see who has actually been pwned by this, and how badly they misconfigured their system in order for the exploit to occur.

            Reasonably straight forward, as long as you can find yourself a privilege escalation hole. I've demo'd exploits that allowed me to root boxes, using shellshock as the entry point. There was no misconfiguration on the systems, just other bugs which became exploitable once you were able to run code on the box

            1. Chemist

              Re: likewise

              "Reasonably straight forward, as long as you can find yourself a privilege escalation hole. I've demo'd exploits that allowed me to root boxes, using shellshock as the entry point. There was no misconfiguration on the systems, just other bugs which became exploitable once you were able to run code on the box"

              Ooh, let's all believe the AC - no evidence given - trust him after all he's an AC

              These were your own boxes I hope or are you going to turn yourself in ? Perhaps that's why you are AC.

              If they were your boxes, or indeed any others, how do we know they were correctly configured ? Or is it all the wishful FUDing of an AC ?

              1. Anonymous Coward
                Anonymous Coward

                Re: likewise

                > These were your own boxes I hope or are you going to turn yourself in ?

                Not my boxes, but had permission.

                > If they were your boxes, or indeed any others, how do we know they were correctly configured ? Or is it all the wishful FUDing of an AC ?

                Rather than simply saying it's FUD, why not give it a try yourself. As long as you've a bit of aptitude you should find it reasonably straight forward.

                As for correctly configured, there were two profiles of system - vanilla install and a 'production' configuration. Different methods of privilege escalation, but both achievable.

                Posting as AC because I'm at work - never expected my post to be taken as gospel, but a question was asked so I answered. If you think it's FUD to point out that bad things can happen when a simple to exploit vulnerability can get you a remote shell, then I simply hope you're not in charge of anything more important than your own accounts.

                1. Chemist

                  Re: likewise

                  "f you think it's FUD to point out that bad things can happen when a simple to exploit vulnerability can get you a remote shell"

                  I don't think that's FUD. But as you gave no evidence about method it's your claim to be able to do it that is the FUD

          3. Brian Miller

            Bash is a DISASTER

            We gots exploits!

            http://www.futuresouth.us/yahoo_hacked.html

            Yahoo! and WinZip both got nailed. If you take a look at John Hall's request text, the parts that were "malformed" were the User-Agent, Cookie, and Referer. Not only that, but it is Bash itself that's calling back to let someone know that the server is vulnerable! That "/dev/tcp" is part of Bash, for your comfort and convenience.

            The messed-up thing about this is that to check whether a system is vulnerable, you have to break computer laws to do it. This isn't just port scanning, the fellow got entry, poked around, and killed the botnet client.

      2. Anonymous Coward
        Anonymous Coward

        Re: likewise

        Arh but - remember if somebody was running a bash/sh script through CGI, it would only run as httpd user... and surely, surely that wouldn't be able to do much to the rest of the file system other than the httpd files? Dropping botnet stuff etc. could only be done as the httpd user....

        1. Anonymous Coward
          Anonymous Coward

          Re: likewise

          and if you've any sense the httpd user can't even update the majority of files in the directory structure....

      3. Voland's right hand Silver badge

        Re: likewise

        Exxploit and patch is a standard practice in malware delivery.

        You immediately close the hole which has allowed you to infect the system to ensure that nobody can break in and use your new zombie.

  4. Ben Bonsall

    love the image file name of the first graph:

    fffffferferfffffferferf.jpg

    :)

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon