reddit hackernews mail facebook facebook linkedin

The Bug Bounty program that changed my life

This is a real story or not, that occured in mid 2017 or not, about a private program or not, on Hackerone or not, believe me or not, but it changed my life. I would like to thanks all the people from this company I talked with. They were very nice with me, very fast to fix the bugs and I always got the rewards in less than 7 days, frequently the day of the report, even for the smallest bugs. Thanks to them, I wish we could find more program like this one.

The money was not the only good thing I earned during this period, my reputation on Hackerone also grew up very fast. From here I received many private invitations, sometimes 3 or 4, up to 5 a week, and we all know that private programs are very important for hunters. I also learned alot because it was the very first time that I was able to play with such issues, I mean in real life, not on a training platform, so it was really really formative.

Some people were mad on me because I didn’t want to share my findings in this program. Come on guys… Following each others on Twitter doesn’t mean I want/can disclose the details of the issues I found in a private program, specially if you’re also working on…
It would be like cutting the branch of the tree I’m sitting on. I hope you understand that.
Kisses :)


Had a hard a time to contact the company, the kool @Geekboy helped me to enter in the game, thanks to him.

So I joined with 1 subdomain takeover on Cloudfront and 2 SQL injection on a minor subdomain, not bad at all, promising.

First hit, well, “official” hit…

A big scan with Dirb on another subdomain revealed a .git directory. Using the program gitpillage, I got some interesting files:
Private program git listing

That could be enough to write a report but since it was PHP code and since I can read PHP, I jumped in the source (PHP guru will recognize the very old Zend Studio 5.5 here xD). Private program git code

I quickly found some calls to exec(), that allow a developper to execute system commands. By tracking the creation of the command string, I had notice that a POST parameter was used without any sanitization. Simplified, the code looked like this:

    $image->upload( $_FILES['img']['tmp_name'], $_POST );

    class image {
        public function upload( $file, $args ) {
            $this->create_base_name( $args );
            $full_path = $this->upload_dir.$this->base_name;
            $command = sprintf( 'chmod 777 %s', $full_path );
            exec( $command );
        private function create_base_name( $args ) {
            $this->base_name = sprintf( '%s%s%s', $this->user_id, $args['p'], $this->suffix );

What would you try then? RCE natürlich! The PoC: Private program rce

W00t w00t bounty time :)


Some weeks later, and some others issues later (CORS/CSRF/source code disclosure/rate limit), another SQL injection popped on the main domain.
Private program sqli

Since I said to the company to take care about the vulnerable module where I found the RCE, 1 month later I came back in the same place and tried to reproduce the bug. Was fixed, the vulnerable parameter wasn’t anymore. But what about all others and what about the other scripts in the repository?

KA-CHING! Got 3 more RCE.

One of them required 3 parameters in his input:

  • path
  • filename
  • contents

This script wrote the content contents in the file filename created in the directory path. The perfect backdoor. Congrats captain Obvious!

Private program rce

Bouncing from a RCE to another RCE

Is that fair or not? Well I don’t know but while I was “connected” to the server of the company, and since I knew that they have a functionality to handle images, I checked the version of the library ImageMagick. Private program imagetragick

If you’re hunter you probably already heard about the famous ImageTragick, version prior to 6.9.3-9 are prone to multiple vulnerabilities including RCE. Here is the PoC: Private program imagetragick

The company was nice enough to reward those two RCE the same day.

My favorite

After I had seen the LevelUP 2017 video from the awesome @zseano, kudos to him, where he explains how to find bugs by extracting datas from Javascript files, I decided to write my own program to extract endpoints and other juicy infos from source code. Once done, I downloaded all JS files I found from my target, and ran my script. Needless to say that hundreds of new endpoints popped. One of them catched my eyes: /[REDACTED].php?[REDACTED]=[REDACTED]&template=[REDACTED].tpl

When you’re a web developper, you know that the extension .tpl is commonly used for HTML code rendered by template engines. Could it be a filename as a parameter??? I immediately tried the value /etc/passwd:

Private program local file disclosure

Ok, this is a valid bug. At first, I though it was a Local File Inclusion so I tried to upgrade to RCE with some tools like fimap, dotdotpwn or Kadimus and then manually but nope… Since I didn’t know the path of the application on the server, I was not able to include any PHP file.

When I find a serious bug like this, I always send the report the same day. First because I want to avoid a stupid duplicate, second because the company has to be aware of it and fix ASAP!

The day after, the bug was still here. Hmmm, well well well… Ding Dang! My brain had a flash, why to not try to include the PHP endpoint itself?! Something like: /the_vulnerable_script.php?[REDACTED]=[REDACTED]&template=the_vulnerable_script.php Guess what? I got the whole source code and it was not interpreted, so actually this was a Local File Disclosure.

Private program local file disclosure

Jumping from include to include, I got some config files with database credentials, API keys of 3rd party services and so on… After digging for a while, I finally got the Graal aka the hard coded autoload file. Basically it’s an array with the classname as the keys and the filepath as the values, here is a basic example:

$t_autoload = [
	'Auth' => '/var/www/project/lib/User/Auth.php',
	'User' => '/var/www/project/lib/User/User.php',
	'Article' => '/var/www/project/lib/Article/Article.php',
	'Comment' => '/var/www/project/lib/Article/Comment.php'

In a nutshell (Yaworsk favorite 3 words), I could access to the whole source of the application. Not a RCE but still a nice catch :) Some minutes later I got a script running and grabbing the files:

Private program local file disclosure

Private program local file disclosure

Game over!

I stayed in touch with the company all along the exploitation of this bug. I stopped my script after a few minutes, I though that would not be fair/polite and legal to download everything.

The last but not the least

Using my previous findings, I had some more endpoints in my hands. From here I found 1 more SQL injection, 4 XSS, and another nice one: account takeover.

In this request, changing my email by the email of any other user will immediately update his password by the one provided. No confirmation needed, I didn’t even need to be authenticated.

Private program account takeover


“I got the swag and it’s pumping out my ovaries.”

Great thanks to @Hacker0x01 and every bug bounty platforms to make this possible.

External resources