Wednesday, February 15, 2017

[Oracle] pwned by 2 RCE

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.

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: The next step is gonna be - searching via Google Dork:
inurl:/cgi-bin/ site:*
inurl:/cgi/ site:*
filetype:cgi site:*
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.

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


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:
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’.
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
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
substituted with IFS variable + URL Encoded:
Reading more sensitive data:
cat /etc/passwd → cat%24IFS%2fetc%2fpasswd

Always believe in yourself and good luck.

Thanks for your attention.

Tuesday, November 1, 2016

[Yahoo] Disclosure phpinfo.php file at one of Yahoo's subdomain

Hi there,

This article is about more trivial finding, but nonetheless, misconfiguration was previously missed by other researchers. So, I decided to share it with a public as well.
As I wrote in my previous topic, all my research starts from reconnaissance of a target, and Yahoo was not an exception. When all my 'first round' custom scripts were finished, there were found ~4k subdomains for Yahoo domain, sure thing that not all of them were alive, but still too much... Now the time had come for the 'second round' of custom scripts, one of them is looking for common default files that have incorrect access permissions (e.g. phpinfo.php).

In couple of hours my script detected accessible phpinfo.php file at one of subdomains. My first thought was: "it's probably false-positive detection". But no, indeed, file was accessible at following URL: ''

Frankly speaking, I was quite surprised by this finding, and due to the fact that I'm reading a lot of blogs written by another researchers. I remembered a finding by Patrik Fehrenbach at his blog post. The vulnerability is totally the same, target is the same, plus scanning whole Yahoo's NetRange for accessible file. My question was "How was the file missed?". In couple seconds I realized that such a huge corporation should probably have another Networks..
The quick ping of '' putted everything into its place.

As you have noticed, subdomain found by me is in another Network than has been scanned by Patrik (CIDR: 
Now I need to find out IP range for a Network which contains following IP I did it via whois service, and retrieved following info:
NetRange: -
NetName:        INKTOMI-BLK-6
NetHandle:      NET-74-6-0-0-1
Parent:         NET74 (NET-74-0-0-0-0)

I have dared to 'borrow' Patrik's script and follow by his example - scan all 65,025 IPs. The script executed ~2.5days, but that's fine, because of my non-stop server at DigitalOcean. :) And btw, on a commercial right, I would like to recommend you to use DigitalOcean platform for your remote pentesting server, use my referral link and get 10$ to your account.

Fortunately or unfortunately - I didn't find anything else at that IP range.


Always believe in yourself and good luck.

Thanks for your attention.

Friday, October 14, 2016

[ADOBE] Importance of up-to-date application usage plus complex password OR from directory traversal to admin panel takeover.

Hi all, well, today I would like to start my blog, and hope I will be able to update it from time to time. Unfortunately, I am not quite eloquent, and my posts may seem a bit plain, but I'm going to improve this skill. Finally I found interesting topic to share with a public, at least from my perspective ☺ Hope this article will be motivating and of course useful ;)

In scope of bugbounty hunting, I perform Web application penetration testing for many of companies. A couple month ago my eye fell at Adobe program, but I got quick response from my subconscious: ‘Come on… It’s such a famous company, hundreds of hunters have already tested them, no sense to spend time on it. Forget.’ A month later, leafing through the companies list my eye fell once again, but now I asked myself: ‘Why not?’

Probably would be correctly to start from my approach to pentesting... In my daily work / hunting I always using PTES methodology. In nutshell about PTES: The penetration testing execution standard consists of seven (7) main sections. These cover everything related to a penetration test - from the initial communication and reasoning behind a pentest, through the intelligence gathering and threat modeling phases where testers are working behind the scenes in order to get a better understanding of the tested organization, through vulnerability research, exploitation and post exploitation, where the technical security expertise of the testers come to play and combine with the business understanding of the engagement, and finally to the reporting, which captures the entire process, in a manner that makes sense to the customer and provides the most value to it.

Why do I need it or why it’s useful? Imagine that you are shooting at a target from a distance of 50m, it will be hard to get - right? But if somebody  bring its closer up to 25m – I suppose to hit the target will be much easier. Same here, when you have multiple subdomains to test – much easier to find some interesting stuff.

So, first thing that I did is reconnaissance of the target. For this purposes I used multiple DNS enumeration tools, here are couple of them: subbrute, theharvester, etc. Well, let’s move further. During ‘Information Gathering’ PTES phase I have found that ‘’ host on 8500 port was vulnerable to Directory listing

As you can see, the latest changes at this host were done at 04/04/11, seems Adobe forgot about this site at all.. So, there a chance to find running outdated services. After some time of investigation - I have found admin panel login page, and yes, application was running at ‘’ outdated (latest version of ColdFusion at the time of writing is 13):

First thing that came to my mind – check exploits online for ColdFusion 9. As turned out – there are plenty of them, ColdFusion 9 is vulnerable to the following security vulnerabilities: DoS, Information Disclosing, XSS, CSRF, Administrative login Bypass, Directory Traversal, etc. That is interesting… Sure thing that my first try was to find exploit for ‘Administrative login Bypass’, it was easy to find plus as turned out, metasploit already has embedded module for it: exploit/multi/http/coldfusion_rds. Unfortunately I was failed to exploit this particular metasploit module… Time to re-read description of exploit ☺
Adobe ColdFusion 9.0, 9.0.1, 9.0.2, and 10 allows remote attackers to bypass authentication using the RDS component. Its password can by default or by misconfiguration be set to an empty value. This allows you to create a session via the RDS login that can be carried over to the admin web interface even though the passwords might be different. Therefore bypassing authentication on the admin web interface which then could lead to arbitrary code execution.
So, seems administrator disable RDS at ColdFusion and I’m not able to use this exploit. Ok, move further, application is still vulnerable to plenty of vulnerabilities.  There is one more stuff, Directory Traversal, how can I exploit it, and is there any exploits online? Yes, here is one more exploit: Run it against of our target, and, vuala – we got hash value of our password: 50A826CED903EFF995651D65C21B5A6F67D9616A

According to the size and length of the hash - seems password is encrypted via SHA-1. For decrypt purpose I will use Wow, password was successfully decrypted: slapstick.

Being as an Ethical Hacker – here my work is over, I will not harm the server – I just notified Abode security team regarding this breach. It was the fastest ever report triggering (~1.5 min)

About fix, I can say nothing much, because Adobe just turned off the application runned at 8500 port.

Two ridiculous things that I  found here:
- The Adobe, who are the owners of ColdFusion Application Server have runned out-of-dated version;
- Complexity of the password was suck, as for such a company.

In 3 days of penetration testing against Adobe, I was able to find:
- Admin panel takeover;
- 4 Stored XSS;
- 6 Directory Listings;
- 1 sensitive world-accessible config file;
- E-Mail Content Spoofing;
- 4 other minor server misconfiguration.

I suppose there could be found more interesting things, but to my big disappointment – Adobe doesn’t have any monetary rewards.. But still that is great start for me, since now you can find my name on their acknowledgement web-page


Unfortunately, I found this presentation after whole my research, but I guess it will be useful to leave it here:

Always believe in yourself and try yourself, even against such a huge and famous companies.

Good luck! :)

Thanks for your attention.