Hello there,
Finally, after a long time (3 month) of communication with Oracle Security Team - majority of reported by me vulnerabilities were fixed. Now I’m able to share interesting findings with a public. On this topic I’m gonna write about 2 different RCE vectors that I was able to exploit against of Oracle’ sites.
Let’s take a brief look at how CGI ShellShock works.
Here is crafted HTTP request to execute Unix uname -a command:
As a result - server returned me all the information about system. Quite easy, right? Let’s retrieve more interesting information from the server:
The command was executed successfully as I expected. Now I was able to perform a lot of actions against this particular server in order to compromise it (e.g. open a port for reverse shell).
Conclusions:
While the exploration of Shellshock here postulates a vulnerable CGI script, the vulnerability can be exploited even without CGI being involved. That said, if you have any CGI script that executes bash explicitly or even implicitly on any code path, the above attacks apply to you.
In this particular case the result on the command execution will be returned inside of HTTP Response in Location header. The object function from a parameter will be substituted with a result of command. The problem that I have faced here is how to make a request that contains ‘space’ (e.g. cat /etc/passwd). Even with uname -a command and different types of encoding doesn’t work here all the time I got ‘403 Forbidden - Invalid hash parameter’.
Boom, now I was able to execute any command without any limitation! Despite that there was another small tricky situation - you are able to retrieve data only line by line. :) To automate the whole process you can write your own script or use Burp Suite Repeater if you are not going to retrieve a lot of information.
Since I’m able to read only 1st object - I need to craft a request that will allow me to retrieve other information. The request for reading 2nd object of current directory looks following: ls|head -2|tail -1
Reading more sensitive data:
head%24IFS%2d2%24IFS%2fetc%2fpasswd%7ctail%24IFS%2d1
Finally, after a long time (3 month) of communication with Oracle Security Team - majority of reported by me vulnerabilities were fixed. Now I’m able to share interesting findings with a public. On this topic I’m gonna write about 2 different RCE vectors that I was able to exploit against of Oracle’ sites.
Finding #1 (The ShellShock via CGI entry-point)
Well, I suppose that all of you (or majority) already know about vulnerability inside of BASH that were found in 2014, but just in case I will leave this link here: CVE-2014-6271. In a nutshell, Shellshock, also known as Bashdoor, is a family of security bugs in the widely used Unix Bash shell. Many Internet-facing services, such as some web server deployments, use Bash to process certain requests, allowing an attacker to cause vulnerable versions of Bash to execute arbitrary commands. As I see it widely occurred ShellShock is coming through HTTP_USER_AGENT header, CGI-based, but there are several more (e.g. OpenSSH, DHCP, etc). Back to CGI-based one, when a web server uses the Common Gateway Interface (CGI) to handle a document request, it passes various details of the request to a handler program in the environment variable list. For example, the variable HTTP_USER_AGENT has a value that, in usual usage, identifies the program sending the request.
A bit about flow of discovering. I hope everyone knows about Google Dorking and there is no need to write much, but just in case here you can find more information. Usually CGI scripts are located in /cgi/, /cgi-bin/ or /cgi-sys/ directories (i.e. /usr/local/apache/htdocs/cgi-bin) so basically URL will be following: https://example.com/cgi-bin/. The next step is gonna be - searching via Google Dork:
inurl:/cgi-bin/ site:*.example.cominurl:/cgi/ site:*.example.comfiletype:cgi site:*.example.cometc...
But needless to say, the response on this dork request won’t return all existing files inside the /cgi-bin/ directory. As you know Google Dork will return only the cached files / directories by Google search engine. To perform such an activity I preferred using brute force directories and files names tool called Dirbuster. This tool is embedded by default into Kali distribution. The tool is really simple in use - so, just open it and you will understand everything by yourself. Via Dirbuster tool I was able to find following file: /cgi-bin/test-cgi with a 200 Status Code. Fast navigation at this endpoint returned me following stuff..
Let’s take a brief look at how CGI ShellShock works.
So, the syntax is pretty trivial of vulnerability in Bourne Again Shell (BASH), aka “Shellshock”, () { :; }; echo; is the key to the exploit. Then we have the payload of /bin/bash which allows for an arbitrary script.
Conclusions:
While the exploration of Shellshock here postulates a vulnerable CGI script, the vulnerability can be exploited even without CGI being involved. That said, if you have any CGI script that executes bash explicitly or even implicitly on any code path, the above attacks apply to you.
Finding #2 (Running Outdated version of GitWeb)
Each time that I find a new vulnerability at such giants companies I’m surprising less and less. This time I have found running out-dated GitWeb version at one of Oracle’s subdomains. One of my scripts have detected old version of running application. It’s an obvious step - verify for already written exploits online. Without any difficulty I found assigned CVEs: CVE-2008-5516 and CVE-2008-5517 that is causing arbitrary code execution. Vulnerability is 9 years old and still has a place for the use… But as I mentioned above I’m not surprised.
In a nutshell about vulnerability: Vulnerable functions in gitweb.cgi: git_snapshot(), git_search(), git_object() leads remote attackers to execute arbitrary commands
The initial request looks like following:
Here is vulnerable gitweb.cgi endpoint with a different parameters, but we are interested in ‘a’ and ‘h’ parameters. Where ‘a’ parameter calls one of vulnerable function and via ‘h’ parameter remote attacker is able to inject arbitrary code, like this:
Thanks to my co-worker and just nice guy @crashbrz, he advised me to check out IFS (eventually it helps).
What is $IFS?
IFS stands for Internal Field Separator - it's a character that separates fields. This variable determines how Bash recognizes fields, or word boundaries, when it interprets character strings. $IFS defaults to whitespace (space, tab, and newline), but may be changed, for example, to parse a comma-separated data file
substituted with IFS variable + URL Encoded:
ls%7chead%24IFS%2d2%7ctail%24IFS%2d1
cat /etc/passwd → cat%24IFS%2fetc%2fpasswd
RESULTS:
Always believe in yourself and good luck.
Thanks for your attention.
Stas
| Bounty |  |
| Swag | |
| HoF |  |
Always believe in yourself and good luck.
Thanks for your attention.
Stas
