Slashdot Mirror
First Shellshock Botnet Attacking Akamai, US DoD Networks
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."
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.
It depends largely on weak web-facing CGI pages that don't sanitise inputs before passing them as arguments to a shell script.
I'm confused about how you can scan for vulnerable systems.
You and everyone else.
The attack surface is "anywhere you can influence the values of environment variables prior to bash being run." Where exactly is that? Well...
The easiest example of that are CGI scripts, where the web server will set environment variables to values that are taken directly from HTTP headers. If the CGI script is a bash script (why would you do that?) or ever happens to fork out to a bash script in any way (that's more understandable), it's vulnerable.
But that's just one example. Any place a remote value gets stuck straight into an environment variable and a bash script gets run is vulnerable. And people are almost certainly going to slowly find more and more places where that's the case.
If you just want to know if you're vulnerable, there are one-liners that will determine if you're still vulnerable, but since the first fix didn't, chances are, you very well could be.
You are in a maze of twisty little relative jumps, all alike.
inputs getting into environment variables which wind up eventually inside of bash.
So we agree. Good-o.
Well...
As a software engineer they expect me to be a sysadmin.
Seriously!
Shell scripts have been known to be basically insecure for a long time. Why would you expose one to a web or network interface?
Of course, that just leaves ssh, but at least some authentication SHOULD be required there.
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.
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?
We knew 15 years ago, that using shell-scripts as CGI-scripts was a security problem.There's just so many ways for a not perfectly quoted variable to become a script injection.
And for those who system() - if you are doing that without validating user input - and those header environment variables ARE user input - you just failed security 101.
So, can anyone explain to me how to use this bug, without using an existing vulnerability to get to it?
I see two groups of people, one group exclaiming that this is a serious vulnerability, without being able to explain how it's a vulnerability, and the other (including myself) saying that it's not a vulnerability, because you need to already have a vulnerability to get to it.
Only if you let the web server call bash directly.
Yeah, we did that 15 years ago. And we knew back then it was a security hole. I hope we have learned to take security a bit more seriously than 15 years ago.
I'm still waiting for an example of how to get to this so-called vulnerability, without using a different security hole to get to it. Either some moron letting the web server call bash directly, or someone not sanitizing his inputs.