22

Odds are that you're already aware of the newly discovered Bash bug. It can be tested using env x='() { :;}; echo vulnerable' bash -c "echo this is a test".

What yet I haven't understand is, what are the real attack scenarios of this vulnerability. I have read that most likely it's going to be HTTP requests, but how?

Improve this question
0

1 Answer 1

Reset to default
14

The easiest way to test a web server via HTTP request is to inject the bash command through the user agent. Example:

$ wget -U '() { :;}; /bin/bash -c "echo vulnerable"' http://example.com/some-cgi-script

If a 5XX server error is generated, it means that the server is probably vulnerable to an exploit. For possible attack scenarios, please refer to this answer

Please test this on your own servers - trying this on other people's servers may get you in trouble.

Improve this answer
8
  • 1
    On OSX without wget, try curl -A '() { :;}; /bin/bash -c "echo vulnerable"' http://example.com/some-cgi-script
    – user193130
    Sep 25, 2014 at 15:27
  • 1
    I get a 301 server error. I probably don't understand the above code, but does example.com/some-cgi-script point to a code on the victim's server or on the attacker's server (and contains malicious code) ?
    – Matt Parkins
    Sep 26, 2014 at 11:17
  • 1
    Thanks - so how does the attacker get the cgi script onto the victim's web server - I think that's what I'm not understanding.
    – Matt Parkins
    Sep 26, 2014 at 13:39
  • 1
    @MattParkins, no, the CGI script is hosted by the victim, not inserted by the attacker.
    – Question Overflow
    Sep 27, 2014 at 7:39
  • 1
    Ah, ok, I see my mixup. I was thinking example.com/some-cgi-script was a malicious script and didn't know how an attacker could get it on a victim's server, but actually it doesn't matter what CGI script is called. Does it matter if the CGI script is actually there?
    – Matt Parkins
    Sep 29, 2014 at 9:50