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:50, Jay Bennie wrote:

On 26 Sep 2014, at 09:39, Gordon Henderson <gordon+lug@xxxxxxxxxx> wrote:

On Fri, 26 Sep 2014, Tom wrote:

No - you cant blame a dodgy door latch because people cant be bothered to use the 
safe they have!

If only it were as simple as that.

So on the surface home PCs, etc. are fine - no need to wory about them for now.

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 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.


I thought this was the reason the apache account is run with a shell of /bin/false   
- so you can't get a user type shell under the running apache user.

and invoked as  su - c  /bin/...path to apached startup script  to ensure there are 
no environment variables except the ones set in the startup.



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"

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 
attempts to fetch/download a trojan program and run it.

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?

Gordon

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


The main problem (apart from trashing web servers) is for people to attack the web db* - which is really easily secured by only allowing the web connection to run stored procedures. I'm practically the only person that seems to do this but its been possible to do that since year .. Not the window latches fault. * this is assuming your web server is nicely set up so that effing with the various CGI strings doesnt gain you access to something else - if it does its not the window latches fault.
Tom te tom te tom
TO

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