shellshock - detect in Apache?

[Gary Stainburn]

Is there any way to detect an attack within Apache and block it?

I'm thinking of a rule or something to check the user-agent or equiv before 
calling the CGI or PHP etc.

I'm looking to protect some old servers where BASH updates won't be 
forthcoming

(I know the answer is to upgrade the servers, but these aren't my servers and 
it ain't my call)

[Michael D. Setzer II]

On 26 Sep 2014 at 15:37, Gary Stainburn wrote:

From:           	Gary Stainburn <gary.stainburn(a)ringways.co.uk&gt;
Organization:   	Ringways Garages Ltd
To:             	users(a)lists.fedoraproject.org
Subject:        	Re: shellshock - detect in Apache?
Date sent:      	Fri, 26 Sep 2014 15:37:35 +0100
Send reply to:  	Community support for Fedora users 
<users(a)lists.fedoraproject.org&gt;
	
>  On Friday 26 September 2014 15:21:27 Michael D. Setzer II wrote:
>  > Problem is you are still running the old bash bash -c should be ./bash -c
>  >
>  > The only issue that I see is that the make install isn't replacing the
>  > /bin/bash, but is putting the new bash in
>  > /usr/local/bin/bash
>  >
>  > Tried to copy bash to the /bin, but it seems to be in use?
>  > But after the make install, it did work.
>  > On one system, I needed to restart to get it to take affect, but have only
>  > check a two systems with older versions of Fedora.
>  >
>  
>  Doh :-)
>  
>  It now works as expected.  I have copied the file to /usr/bin/bash - the 
>  existing / old version of bash is /bin/bash
>  
>  I have updated the shell field in /etc/passed for a test user and then logged 
>  in as that user. All looks okay. Next step is to replace the old bash and 
>  cross my fingers.
>  
>  If this works, I'll roll it out to the live servers too.
>  
>  Thanks again 
Just as a test, I created a script to download and create the update bash

Note the strip option. The build creates an about 3m file, but after strip the 
code is reduced to about 1m. 

mkdir bash
cd bash
ncftpget ftp://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz .
tar -zxvf bash-4.3.tar.gz
cd bash-4.3
ncftpget ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/* .
for a in bash43-??? ; do 
  patch -p0 <$a ;
done
./configure
make
strip bash
#make install

Left the last step commented so far just to make sure it all worked with no 
compile errors. The issue that if someone ran /bin/bash to run the old script. 
Don't know if there is a trick to change the /bin/bash directly. The rpm update 
seems to do it, so there must be something to it.


>  -- 
>  users mailing list
>  users(a)lists.fedoraproject.org
>  To unsubscribe or change subscription options:
>  https://admin.fedoraproject.org/mailman/listinfo/users
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>  Have a question? Ask away: http://ask.fedoraproject.org 

+----------------------------------------------------------+
  Michael D. Setzer II -  Computer Science Instructor      
  Guam Community College  Computer Center                  
  mailto:[e-mail]                            
  mailto:[e-mail]
  http://www.guam.net/home/mikes
  Guam - Where America's Day Begins                        
  G4L Disk Imaging Project maintainer 
  http://sourceforge.net/projects/g4l/
+----------------------------------------------------------+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned:  19,471
Processing time:  32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

BOINC@HOME CREDITS
ROSETTA     19981840.971965   |   SETI        33950436.647387
ABC         16613838.513356   |   EINSTEIN    34233765.925899

[Chris Adams]

Once upon a time, Fulko Hew <fulko.hew(a)gmail.com&gt; said:
>  that can be executed to determine whether an apache/cgi
> 'environment'
>  can be attacked?  or do each of my CGI (perl) apps need checking...
>  
>  It seems to me to be an apache/cgi environment issue, and not
>  a CGI app issue. 
You can't really "test" for it, because it will be code-specific (and
call-path specific, since most CGIs do different things depending on how
you call them).  It is specifically a CGI app issue, because it depends
on what the CGI code does with the environment it is given and how the
code actually works.  It isn't an Apache issue; passing certain client
data in the environment is how CGI is defined to work.

For example, lots of CGI authors don't know the difference between:

    open (my $foo, '|mail -s subject alice(a)example.com&#39;);

and

    open (my $foo, "|-", qw(mail -s subject alice(a)example.com));

There is a big difference in how perl handles those; the first calls out
to the shell to interpret the arguments, while the second does not.  The
first is the "easier" way, so is the most-used way.  Code with the first
type of call would be vulnerable to a bad version of bash, while the
second would not.

If a perl script is run in "taint" mode (which is highly recommended for
things like CGIs but not commonly used), the incoming environment
variables are tainted and you can't execute anything without resetting
the environment, which (in most cases) would clear any "bad" variables.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Fulko Hew]

On Fri, Sep 26, 2014 at 10:40 AM, Gary Stainburn <
gary.stainburn(a)ringways.co.uk&gt; wrote:

>  On Friday 26 September 2014 15:32:15 Fulko Hew wrote:
>  > On Fri, Sep 26, 2014 at 8:28 AM, Matthew Miller <
>  mattdm(a)fedoraproject.org&gt;
>  >
>  > wrote:
>  > > On Fri, Sep 26, 2014 at 01:19:29PM +0100, Gary Stainburn wrote:
>  > > > Is there any way to detect an attack within Apache and block it?
>  > > > I'm thinking of a rule or something to check the user-agent or equiv
>  > >
>  > > before
>  > >
>  > > > calling the CGI or PHP etc.
>  > > > I'm looking to protect some old servers where BASH updates won't
> be
>  > > > forthcoming
>  > >
>  > > You should be able to do this with mod_rewrite -- at least if you can
>  be
>  > > sure that none of the CGI variables should ever legitimately start with
>  > > "(".
>  > > Use the RewriteCond and test for every one of those variables that come
>  > > from
>  > > the user.
>  > > http://httpd.apache.org/docs/current/mod/mod_rewrite.html
>  > >
>  > > There may be a better way, but that's what comes to mind.
>  >
>  > Is there a simple test (similar to the 'basic bash' test';  posted
>  > everywhere)
>  > that can be executed to determine whether an apache/cgi 'environment'
>  > can be attacked?  or do each of my CGI (perl) apps need checking...
>  >
>  > It seems to me to be an apache/cgi environment issue, and not
>  > a CGI app issue.
>
>  I've found the following page:
>
>
>
> http://www.zdnet.com/shellshock-how-to-protect-your-unix-linux-and-mac-se...
>
>  which includes some rewrite rules. As I've never done rewrite rules before,
>  where would I put them?
>  
Yes, I saw that from a few emails ago.
That's a potential technique for mitigation, but I'm wondering
about a technique for detecting apache/cgi based vulnerability.

Ie.  Do I have to worry about _my_ web server?

[Gary Stainburn]

On Friday 26 September 2014 15:32:15 Fulko Hew wrote:
>  On Fri, Sep 26, 2014 at 8:28 AM, Matthew Miller
> <mattdm(a)fedoraproject.org&gt;
>
>  wrote:
>  > On Fri, Sep 26, 2014 at 01:19:29PM +0100, Gary Stainburn wrote:
>  > > Is there any way to detect an attack within Apache and block it?
>  > > I'm thinking of a rule or something to check the user-agent or equiv
>  >
>  > before
>  >
>  > > calling the CGI or PHP etc.
>  > > I'm looking to protect some old servers where BASH updates won't be
>  > > forthcoming
>  >
>  > You should be able to do this with mod_rewrite -- at least if you can be
>  > sure that none of the CGI variables should ever legitimately start with
>  > "(".
>  > Use the RewriteCond and test for every one of those variables that come
>  > from
>  > the user.
>  > http://httpd.apache.org/docs/current/mod/mod_rewrite.html
>  >
>  > There may be a better way, but that's what comes to mind.
>
>  Is there a simple test (similar to the 'basic bash' test';  posted
>  everywhere)
>  that can be executed to determine whether an apache/cgi 'environment'
>  can be attacked?  or do each of my CGI (perl) apps need checking...
>
>  It seems to me to be an apache/cgi environment issue, and not
>  a CGI app issue. 
I've found the following page:

http://www.zdnet.com/shellshock-how-to-protect-your-unix-linux-and-mac-se...

which includes some rewrite rules. As I've never done rewrite rules before, 
where would I put them?


-- 
Gary Stainburn
Group I.T. Manager
Ringways Garages
http://www.ringways.co.uk

[Gary Stainburn]

On Friday 26 September 2014 15:21:27 Michael D. Setzer II wrote:
>  Problem is you are still running the old bash bash -c should be
> ./bash -c
>
>  The only issue that I see is that the make install isn't replacing the
>  /bin/bash, but is putting the new bash in
>  /usr/local/bin/bash
>
>  Tried to copy bash to the /bin, but it seems to be in use?
>  But after the make install, it did work.
>  On one system, I needed to restart to get it to take affect, but have only
>  check a two systems with older versions of Fedora.
>  
Doh :-)

It now works as expected.  I have copied the file to /usr/bin/bash - the 
existing / old version of bash is /bin/bash

I have updated the shell field in /etc/passed for a test user and then logged 
in as that user. All looks okay. Next step is to replace the old bash and 
cross my fingers.

If this works, I'll roll it out to the live servers too.

Thanks again

[Fulko Hew]

On Fri, Sep 26, 2014 at 8:28 AM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
wrote:

>  On Fri, Sep 26, 2014 at 01:19:29PM +0100, Gary Stainburn wrote:
>  > Is there any way to detect an attack within Apache and block it?
>  > I'm thinking of a rule or something to check the user-agent or equiv
>  before
>  > calling the CGI or PHP etc.
>  > I'm looking to protect some old servers where BASH updates won't be
>  > forthcoming
>
>
>  You should be able to do this with mod_rewrite -- at least if you can be
>  sure that none of the CGI variables should ever legitimately start with
>  "(".
>  Use the RewriteCond and test for every one of those variables that come
>  from
>  the user.
>  http://httpd.apache.org/docs/current/mod/mod_rewrite.html
>
>  There may be a better way, but that's what comes to mind.
>  
Is there a simple test (similar to the 'basic bash' test';  posted
everywhere)
that can be executed to determine whether an apache/cgi 'environment'
can be attacked?  or do each of my CGI (perl) apps need checking...

It seems to me to be an apache/cgi environment issue, and not
a CGI app issue.

[Gary Stainburn]

On Friday 26 September 2014 14:05:01 Michael D. Setzer II wrote:
>  I download the
>  ftp://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
>  and the patches in
>  ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/
>
>  Installed the 25 patches and then build the code.
>  Running the test on that version of bash passes the test.
>
>  Don't know if there would be any issues with then replacing the older bash
>  on a system with the newly build one, but that didn't take much time to
>  build. 
Tried this and it appears that this version of BASH is still vulnerable

[root@test bash-4.3]# ./bash
[root@test bash-4.3]# echo $BASH_VERSION
4.3.25(1)-release
[root@test bash-4.3]# env x='() { :;}; echo vulnerable' bash -c "echo this is

a test"
vulnerable
this is a test
[root@test bash-4.3]#

[Gary Stainburn]

>  Another option would be to build the latest version of bash.
>  ftp://ftp.gnu.org/gnu  has serveral versions of bash a number of them have
>  patch directories with Sep 24th date.
>
>  I download the
>  ftp://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
>  and the patches in
>  ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/
>
>  Installed the 25 patches and then build the code.
>  Running the test on that version of bash passes the test.
>
>  Don't know if there would be any issues with then replacing the older bash
>  on a system with the newly build one, but that didn't take much time to
>  build. 
Thanks for this Michael.

I'll attempt this. As someone who hasn't built from source code in decades, 
how do I apply the patches to the source tree before building?

Gary

[Michael D. Setzer II]

On 26 Sep 2014 at 13:19, Gary Stainburn wrote:

From:           	Gary Stainburn <gary.stainburn(a)ringways.co.uk&gt;
Organization:   	Ringways Garages Ltd
To:             	Community support for Fedora users 
<users(a)lists.fedoraproject.org&gt;
Subject:        	shellshock - detect in Apache?
Date sent:      	Fri, 26 Sep 2014 13:19:29 +0100
Send reply to:  	Community support for Fedora users 
<users(a)lists.fedoraproject.org&gt;

>  Is there any way to detect an attack within Apache and block it?
>  
>  I'm thinking of a rule or something to check the user-agent or equiv before 
>  calling the CGI or PHP etc.
>  
>  I'm looking to protect some old servers where BASH updates won't be 
>  forthcoming
>  
>  (I know the answer is to upgrade the servers, but these aren't my servers and 
>  it ain't my call) 

Another option would be to build the latest version of bash.
ftp://ftp.gnu.org/gnu  has serveral versions of bash a number of them have 
patch directories with Sep 24th date.

I download the 
ftp://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
and the patches in 
ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/

Installed the 25 patches and then build the code.
Running the test on that version of bash passes the test.

Don't know if there would be any issues with then replacing the older bash on 
a system with the newly build one, but that didn't take much time to build.



>  -- 
>  users mailing list
>  users(a)lists.fedoraproject.org
>  To unsubscribe or change subscription options:
>  https://admin.fedoraproject.org/mailman/listinfo/users
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>  Have a question? Ask away: http://ask.fedoraproject.org 

+----------------------------------------------------------+
  Michael D. Setzer II -  Computer Science Instructor      
  Guam Community College  Computer Center                  
  mailto:[e-mail]                            
  mailto:[e-mail]
  http://www.guam.net/home/mikes
  Guam - Where America's Day Begins                        
  G4L Disk Imaging Project maintainer 
  http://sourceforge.net/projects/g4l/
+----------------------------------------------------------+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned:  19,471
Processing time:  32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

BOINC@HOME CREDITS
ROSETTA     19981840.971965   |   SETI        33950436.647387
ABC         16613838.513356   |   EINSTEIN    34233765.925899

[Todor Petkov]

On 26/09/2014 03:19 PM, Gary Stainburn wrote:
>  Is there any way to detect an attack within Apache and block it?
>  
>  I'm thinking of a rule or something to check the user-agent or equiv 
>  before
>  calling the CGI or PHP etc.
>  
>  I'm looking to protect some old servers where BASH updates won't be
>  forthcoming
>  
>  (I know the answer is to upgrade the servers, but these aren't my 
>  servers and
>  it ain't my call) 
Hi,

you can try mod_security, for example check this:

http://www.zdnet.com/shellshock-how-to-protect-your-unix-linux-and-mac-se...

There are also other links in Google as well.


Regards,

[Matthew Miller]

On Fri, Sep 26, 2014 at 01:19:29PM +0100, Gary Stainburn wrote:
>  Is there any way to detect an attack within Apache and block it?
>  I'm thinking of a rule or something to check the user-agent or equiv before 
>  calling the CGI or PHP etc.
>  I'm looking to protect some old servers where BASH updates won't be 
>  forthcoming 

You should be able to do this with mod_rewrite — at least if you can be
sure that none of the CGI variables should ever legitimately start with "(".
Use the RewriteCond and test for every one of those variables that come from
the user.
http://httpd.apache.org/docs/current/mod/mod_rewrite.html

There may be a better way, but that's what comes to mind.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Michael D. Setzer II]

On 26 Sep 2014 at 15:06, Gary Stainburn wrote:

From:           	Gary Stainburn <gary.stainburn(a)ringways.co.uk&gt;
Organization:   	Ringways Garages Ltd
To:             	users(a)lists.fedoraproject.org
Subject:        	Re: shellshock - detect in Apache?
Date sent:      	Fri, 26 Sep 2014 15:06:23 +0100
Send reply to:  	Community support for Fedora users 
<users(a)lists.fedoraproject.org&gt;
	
>  On Friday 26 September 2014 14:05:01 Michael D. Setzer II wrote:
>  > I download the
>  > ftp://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
>  > and the patches in
>  > ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/
>  >
>  > Installed the 25 patches and then build the code.
>  > Running the test on that version of bash passes the test.
>  >
>  > Don't know if there would be any issues with then replacing the older bash
>  > on a system with the newly build one, but that didn't take much time to
>  > build.
>  
>  Tried this and it appears that this version of BASH is still vulnerable
>  
>  [root@test bash-4.3]# ./bash
>  [root@test bash-4.3]# echo $BASH_VERSION
>  4.3.25(1)-release
>  [root@test bash-4.3]# env x='() { :;}; echo vulnerable' bash -c "echo this
> is 
>  a test"
>  vulnerable
>  this is a test
>  [root@test bash-4.3]#  
Problem is you are still running the old bash bash -c should be ./bash -c

The only issue that I see is that the make install isn't replacing the /bin/bash, 
but is putting the new bash in
/usr/local/bin/bash

Tried to copy bash to the /bin, but it seems to be in use? 
But after the make install, it did work. 
On one system, I needed to restart to get it to take affect, but have only 
check a two systems with older versions of Fedora.








>  -- 
>  users mailing list
>  users(a)lists.fedoraproject.org
>  To unsubscribe or change subscription options:
>  https://admin.fedoraproject.org/mailman/listinfo/users
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>  Have a question? Ask away: http://ask.fedoraproject.org 

+----------------------------------------------------------+
  Michael D. Setzer II -  Computer Science Instructor      
  Guam Community College  Computer Center                  
  mailto:[e-mail]                            
  mailto:[e-mail]
  http://www.guam.net/home/mikes
  Guam - Where America's Day Begins                        
  G4L Disk Imaging Project maintainer 
  http://sourceforge.net/projects/g4l/
+----------------------------------------------------------+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned:  19,471
Processing time:  32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

BOINC@HOME CREDITS
ROSETTA     19981840.971965   |   SETI        33950436.647387
ABC         16613838.513356   |   EINSTEIN    34233765.925899