D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] bash vulnerability

 

On 26/09/14 09:39, Gordon Henderson wrote:

> But servers... There are now so many attack vectors it's hard to keep
> track. The obvious one (in this case) is a CGI program written in BASH.
> The not so obvious ones are ones written in PHP/C/PERL/Python, etc.
> where you think you're OK, but if you call system(), popen(), use the
> 'backticks' operators, or even functions in languages that let you pipe

Most people don't even realise how many of these use some sort of shell.

> to a program (e.g. fd = fpopen ("|/usr/bin/sendmail -t") sort of thing),
> then there is a good chance you're vulnerable as BASH is typically used
> there and each process inherits the environment variables and BASH will
> parse those variables and if they contain a function tail, it will
> execute it.

Is an actual "attack" fairly generic or does it require tailoring to how
the shell is being called?

Debian charged the default /bin/sh to being /bin/dash a while back.
Possibly there are distributions where something other than bash is the
default shell for www-data.

> 
> I'm seeing e.g. this in server log-files:
> 
> 89.207.135.125 - - [25/Sep/2014:07:06:28 +0100] "GET
> /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 292 "-" "() { :;}; /bin/ping
> -c 1 198.101.206.138"

A lookup on 89.207.135.125 is interesting in that it looks to be
intended to just show the domain.
> 
> That's actually a test probe being run by someone trying to go the right
> thing to test servers, but I've also seen attempts to run the eject
> command as well as atempts to fetch/download a trojan program and run it.

I'm wondering why "eject". Since this isn't AFAIK usually setuid root.
> 
> Note where the payload is - for hose not familiar with apache log files,
> that's the Useragent string. It's passed into CGI's as an environment
> variable and if that CGI ever touches BASH, then BASH will execute it.
> 
> So as for not using the "safe"... If your CGI is bash then its too late
> as the environment variables have already been seen (and executed) by it
> before your script actually starts, as for other languages, how many
> people parse and validate all environment variables as a matter of
> course when their CGI starts up?

Probably very few even look for environment variables which arn't of
specific interest. Accessing a CGI as https adds a whole pile of
environment variables over using http.


Attachment: signature.asc
Description: OpenPGP digital signature

-- 
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq