Hacking First.org private keys for fun and profit, or maybe not! | Security Down!

Hacking First.org private keys for fun and profit, or maybe not!

Hacking First.org private keys for fun and profit, or maybe not!

Hello everyone, finally the blog is back 😀

TL;DR, Today’s blog post is about a LFD/directory traversal vulnerability in First.org API that allowed me to access their file system, the latter was escalated to gain access to First.org SSL keys.

This blog is based on my personal research in my free time and doesn’t represent my employer.

FIRST is an international confederation of trusted computer incident response teams who cooperatively handle computer security incidents and promote incident prevention programs. If by any chance you worked for any CERT organization, you of course know these guys very well.

So, FIRST started their bug bounty program few months ago: https://www.first.org/about/bugs

Decided to participate, and as usual collected enough sub-domains and started to hack my way in.

Came across api.first.org which seemed interesting application with lots of customized stuff (try Wappalyzer plugin to know why) … When a sub-domain looks interesting to me, I start some of my scripts that pick-up the easy stuff, known as easy hanging fruits. Things such as, XSS & Directory traversal in the URL itself, Ruby file access vulnerability, HHA, HPP, Virtual Names manipulation and so on.

The script found a Local file disclosure vulnerability that also allows for directory traversal (reading files outside the current directory).


Nice start! let’s make it look more juicy so I can get a good bounty here …. The LFI to RCE tricks such as injecting log files and the famous /proc/self/environ etc etc (References: Ref1, Ref2) didn’t work, which is expected.

Ok, Local File Disclosure (LFD) now what?

If you have a Linux OS, try browsing through file:///etc/ or ls -lah /etc/ and you will notice most of the juicy files that you would be interested to read. Usually I’m interested in:

  1. /etc/passwd -> To get the list of system/services users, paths and so on.
  2. /proc/self/environ -> well, environment variable are pretty useful for many reasons.
  3. /etc/hosts -> to get a good overview of the internal network and network ranges in use (not always the case though)
  4. Web server configuration file -> allows to have access to all the virtual environments configured, applications paths so you can read the application source code, ACL’s (remember the Yahoo LFI?) and so on.
  5. /proc/1/cgroup -> to figure-out if I’m into a container or not (i.e. docker, LXC), If docker for instance, then I try to read /.dockerenv
  6. /etc/crontab -> to get a list of all the configured scheduled tasks, jobs or call it whatever you like 😀
  7. /etc/resolve.conf, /etc/snmp/snmp.conf and the list goes bigger.

By reading /etc/crontab, found an interesting scheduled task that runs every 80 days

What I wanted you to see from the above screenshot is 2 things:

  1. The path to the SSL private key was there.
  2. The second thing explains why it is here and why this scheduled task. As my readers already know the well known “lets-encrypt” initiative that aims at allowing every website to use SSL/HTTPS for free. However, the issued certificates are only valid for 90 days and will then expire. That is why you must renew it before it gets expired and that is why that scheduled task were here. to automatically renew it.

That said, going back to the LFD vulnerability, providing the path to the private key file, and Pingooo 😀

That was enough to report the vulnerability to FIRST team, they were super fast and fixed it in 2 hours!

The bounty for this finding were 50$,  you indeed read it right 😀

Lessons learned

There are 3 lessons learned here:

  1. Of course “Never trust a user input” role always comes first 😀
  2. If you gonna use LetsEncrypt service, make sure you give the right permissions to the private key file. For instance, if the file was allowed read access for root only, would have never been able to read it.
  3. FIRST guys were nice and explained that 50$ is indeed a low reward, they just started their BBP and didn’t know what to do at that time (back in 2017). My advice is, before starting a BBP you need to make sure that hackers are always encouraged to help you fix your vulnerabilities, make them happy and read on how things works first.

Thanks for reading …. written in Goa during #NullCon with <3


  1. Mokhtar Ebrahim - March 2, 2018

    Good luck Ebrahim and welcome back.
    Regarding these kinds of vulnerabilities, is it enough to use ModSecurity and CSF firewall? or there some other free alternatives I can rely on?


    • zigoo - March 2, 2018

      Thanks Mokhtar. I would say that indeed a good configured ModSecurity/AppArmor will do the job of blocking these vulnerabilities. Good question (Y)

  2. Saeed - November 5, 2018

    Nice! The scheduled task is running “cat” as root without an absolute path! that could’ve been an easy privilege escalation if you somehow managed to get an unprivileged RCE on the server! :”D

  3. T54R - June 28, 2019

    One of my favorite posts in this blog, I keep reading it again and again, time to time. It really describes the human intelligence.
    I noticed that the site was down for a day or few daysand then you got it back.
    Keep going bro

Leave a reply