Improve check for BASH HTTP modules

[jvazquez-r7]

@wchen-r7 pointed which when targeting a #!/bin/bash cgi, something like:

#!/bin/bash

echo "Content-type: text/html";
echo ""
echo "hello"

Even when it should be vulnerable, the check on both modules/auxiliary/scanner/http/apache_mod_cgi_bash_env.rb and modules/exploits/multi/http/apache_mod_cgi_bash_env_exec.rb isn't reporting it. It's because the injection trashes the output generated by the CGI which makes Apache to fail and return an 500 error code:

[Fri Sep 26 15:54:18 2014] [error] [client 172.16.158.1] malformed header from script. Bad header=xziRzrHuWZFEc1MVfLYQxziRzrHuWZ: first.sh

This pull request tries to improve check method. If the original check fails, but the answer is a 500 result, it makes a second legit request, and compares res.code, returning Appears if the http code is different.

Feedback is welcome. I won't be hurt if the additional complexity to the check method doesn't worth and is discarded. I think is an interesting case, so here it's the proposed code :)

After this pull request, with the example CGI:

tmsf auxiliary(apache_mod_cgi_bash_env) > set targeturi /cgi-bin/first.sh
targeturi => /cgi-bin/first.sh
msf auxiliary(apache_mod_cgi_bash_env) > check
[*] 172.16.158.144:80 - The target appears to be vulnerable.
[*] Checked 1 of 1 hosts (100% complete)
msf auxiliary(apache_mod_cgi_bash_env) > exit -y

[kernelsmith]

Isn't bash in a weird location on BSD or some such, like /usr/bin/bash or something? I haven't been following the bash stuff all that closely, and this might not be the place to bring this up, I just wanted to throw it out there

On Sep 26, 2014, at 16:02, Juan Vazquez notifications@github.com wrote:

@wchen-r7 pointed which when targeting a #!/bin/bash cgi, something like:

#!/bin/bash

echo "Content-type: text/html";
echo ""
echo "hello"

Even when it should be vulnerable, the check on both modules/auxiliary/scanner/http/apache_mod_cgi_bash_env.rb and modules/exploits/multi/http/apache_mod_cgi_bash_env_exec.rb isn't reporting it. It's because the injection trashes the output generated by the CGI which makes Apache to fail and return an 500 error code:

[Fri Sep 26 15:54:18 2014] [error] [client 172.16.158.1] malformed header from script. Bad header=xziRzrHuWZFEc1MVfLYQxziRzrHuWZ: first.sh
This pull request tries to improve check method. If the original check fails, but the answer is a 500 result, it makes a second legit request, and compares res.code, returning Appears if the http code is different.

Feedback is welcome. I won't be hurt if the additional complexity to the check method doesn't worth and is discarded. I think is an interesting case, so here it's the proposed code :)

After this pull request, with the example CGI:

tmsf auxiliary(apache_mod_cgi_bash_env) > set targeturi /cgi-bin/first.sh
targeturi => /cgi-bin/first.sh
msf auxiliary(apache_mod_cgi_bash_env) > check
[] 172.16.158.144:80 - The target appears to be vulnerable.
[] Checked 1 of 1 hosts (100% complete)
msf auxiliary(apache_mod_cgi_bash_env) > exit -y
You can merge this Pull Request by running

git pull https://github.com/jvazquez-r7/metasploit-framework fix_bash_cgi_check
Or view, comment on, or merge it at:

#3897

Commit Summary

Try to make a better check
Make it better
File Changes

M modules/auxiliary/scanner/http/apache_mod_cgi_bash_env.rb (15)
M modules/exploits/multi/http/apache_mod_cgi_bash_env_exec.rb (19)
Patch Links:

https://github.com/rapid7/metasploit-framework/pull/3897.patch
https://github.com/rapid7/metasploit-framework/pull/3897.diff
—
Reply to this email directly or view it on GitHub.

[wchen-r7]

Nice fix.

[wchen-r7]

Works for me:

msf exploit(apache_mod_cgi_bash_env_exec) > check
[*] 192.168.1.114:80 - The target appears to be vulnerable.
msf exploit(apache_mod_cgi_bash_env_exec) > run

[*] Started reverse handler on 192.168.1.64:4444 
[*] Command Stager progress - 100.49% done (1032/1027 bytes)
[*] Command shell session 1 opened (192.168.1.64:4444 -> 192.168.1.114:59864) at 2014-09-26 17:03:47 -0500