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

Hacking 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 API that allowed me to access their file system, the latter was escalated to gain access to 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:

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

Came across 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).….//….//….//….//….//….//….//etc//passwd

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

Yahoo! Escalated Remote File Inclusion Vulnerability.

Yahoo! Escalated Remote File Inclusion Vulnerability.


Hello Everyone 🙂

Today’s article will be explained in 2 main phases.

1- How i found the Yahoo LFD/RFI (Local File Disclosure/Remote File Inclusion) Vulnerability

2- Exploitation Techniques

#Important Note: Yahoo! asked to remove the domain name and some other parts from this write-up before it is being published. also the video POC has been removed to not disclose the affected hostname.

Screen Shot 2016-12-03 at 4.29.55 PM

1- How i found the Yahoo LFD/RFI (Local File Disclosure/Remote File Inclusion) Vulnerability

As you know, it all starts with information gathering. after collecting some Yahoo sub-domains, i started working on:

with some file/dir names brute-forcing, below page were found:


By viewing the page source code, below page got my attention:


as you can see, images are loaded from remote url using the parameter named as “img_url”.

By tampering with the parameter “img_url”, i figured-out that i can include remote files and not only image files!

2- Exploitation Techniques

NOTE: kindly note that all the payloads has been tested on “” which is a redundant/secondary server and not on the main site, just to avoid being detected and to avoid causing any issues to a Yahoo production environment during the test.

After finding the remote file inclusion vulnerability, i tried multiple techniques to gain shell access to the server such as including “”. I also tried gaining shell access by LFI such as injecting log files and the famous /proc/self/environ trick (References: Ref1, Ref2) with no luck at all.

It seems the server php.ini configuration file is well configured, or maybe it is all about how the backend code handles the requested URL’s?

 Time for LFD (Local File Disclosure) instead of RFI:

first thing that comes in mind when thinking of LFI/LFD is php wrappers:

Screen Shot 2016-11-11 at 11.27.47 PM

Although that php Wrappers php://input, php://output, data://, ftp:// etc didn’t work for me, Fortunately 2 techniques worked. first is using php wrapper called file:// and second is using normal http:// protocol to access internal hosts.


#file:// is a php wrapper used to access local filesystem


By reading the /etc/hosts file, i now know that the internally used subnet is


As you can see from the above screenshot, the database server is hosted on, which were confirmed by a simple SSRF (Server Side Request Forgery) #to not be confused with Cross Site Port Scanning (XSPS) as this wasn’t a port scanning but SSRF.

#3306/TCP is the default port used by Mysql Database server.


Now let’s scan the internal subnet for live hosts, i wrote a simple python script to initiate requests to each IP, if a valid response is returned, then the host is up and running a webserver (it was done on different ports as well).


Brute-Forcing filenames/dirs on an internally hosted server:


As a final step i did read the apache configuration file to find the configured path were the application is hosted:

Screen Shot 2016-11-13 at 10.08.25 AM

Next  step were to read some source code:



Screen Shot 2016-12-01 at 2.29.09 AM

Although that i was able to initiate requests to intranet, Yahoo still consider as out of scope.
Yahoo rewarded this critical finding with 250$ !!







Magento Remote Code Execution Vulnerability!

Magento Remote Code Execution Vulnerability!


Salam, Hello, Nekhaw, Selamat Datang, Komastaka, Aregato, Ciao, Merhaba, Swadi Kup, Namaste, Kak Gatokha Bratokha 😀

Wherever you are from, Welcome to this blog post about a Remote Code Execution Vulnerability that affects the most popular shopping application on the internet –> #Magento

The case started when i found below sub-domain for website:

As you can see it is a development server, after some crawling i found below directory: ( The “GitHub/” directory is the folder where they are installing Magento, And the “Setup/”  is the application installation directory )

Screen Shot 2014-11-06 at 8.19.50 AM


It was the installation folder for Magento application, However, After clicking Next, Next:

Screen Shot 2014-11-06 at 8.20.19 AM




Important Note: in the installation process, Magento allows you to name your admin login page as you like, you can name it admin or cpanel or whatever!

Anyway, I reached below URL which is used to configure a database for Magento to use:

So, I submitted any bogus data as a database credentials, and i got below error:

Screenshot from 2015-10-29 17:05:04


As you can see, the database triggered error because it can’t connect to the bogus IP i provided in the previous step, But wait!  also the credentials i provided is reflected inside the page!

So here is the scenario to trigger the RCE:

1- I will provide a bogus ip so the database will through an error, and that error will be reflected in the “Admin” page i created.

2- Because i can rename the admin panel to whatever, so i will rename it to “zigoo.php”, now the error will be inserted into “zigoo.php” page.

3- Since the data i provided in the db username and password inputs are reflected in the “.php” page, i will inject a PHP code inside the username & password fields.

That said, i will add php code “<?phpinfo();?>” in the username & password field,  rename the admin panel to be “zigoo.php” and add bogus ip in the “Database Server Host” field as below:

Now let’s try a small test first, i will rename the admin panel to be “zigoo1.php” to see if it works or not:



Works fine as expected, now i will inject the php codes inside the other inputs as below:

Screen Shot


And Pingo! RCE triggered and the php code “<?phpinfo();?>” worked like a charm!



To fix this vulnerability in your website, just make sure that the installation files/drectory are DELETED or at least renamed.

Vulnerability Timeline:

This vulnerability has been reported to Magento team on: 09/Nov/2014



That time, Paypal and Magento were still the same BBP, However, I got the first response from Magento on: 11/11/2014





Emails going back and forth until i received an Email from the team on: Jul 2, 2015 at 9:52 AM (after 9 months) that the bug is not yet fixed as Highlighted below:




After that time, i sent an Email in the same month and another and so on, i didn’t receive any response for over 3 months:





Untill i fedup with this! so i decided to search for Magento security Employees on linkedIn to message them about the issue!!!!!

However, I found someone from Magento team, after i explained the issue to him, he escelated the issue, and finally on 24/10/2015 i got a response that they will handle this issue and the rest of bounty will be sent next week.

Finally i received the payment on October 27, 2015 10:27:54 PM (After around 1 Year of the report)



I Emailed the team back to know why this issue took 1 year to be fixed?!

Their response were:

1- The issue were fixed on 30 June 2015 (arround 8 months)

2- The reason of no responses and delay in sending the bounty is:


As a conclusion for this long blog post:

1- This bug has been fixed now, but if you are using older version of Magento, don’t forget to remove the installation files/directory.

2- Emergency leaves happens to all of us all the time, but someone should be following up/Delegated on the P1(Priority one)  reports!!!

3- The reward for this vulnerability were the “Second Tier” Application RCE reward.

4- Thanks “Mark Brinton” for your prompt help to escelate this issue 🙂


Remote Reset Password in one of Yahoo Applications.

Remote Reset Password in one of Yahoo Applications.


Hello from Egypt 🙂

Today I will blog about a Remote Password Reset that I’ve found in one of Yahoo domains/applications.

Vulnerable Domain:  #Now this domain is down for ever.

The case started when I were browsing one of Yahoo advertising pages, and found a “Example” page explaining how to create an advertising account, reset your password etc.

That all were explained using images, one of the images contained a token to reset the user password, it was a test user!

So, I tried OCR on that image to get access to that token.

What is OCR:

Optical character recognition, usually abbreviated to OCR, is the mechanical or electronic conversion of scanned or photographed images of typewritten or printed text into machine-encoded/computer-readable text.
In a Simple words, OCR technology helps you(as example) to extract text written inside images #Simple enough?!

However, after the OCR part and getting the token, I tried to test it and it was a valid token 😀


So, some Googling of the vulnerable file, I found another token cached in Google time machine, and guess what?
It was a valid one also!

Using that token I was able to reset the password of the user that token related to, without being logged-in and without access to that user account.

Just to make it clear, the bug occurs because the user token should be valid only to the same user who have it and not anyone else, but in this writeup you may noticed that I’ve got access to 2 different access tokens and it works!

Below is a video as a Proof of Concept for the vulnerability:

Yahoo has fixed the issue in a short time slot,

عشان منبقاش زي سوريا والعراق 😀

 Follow me



Yahoo Full Application Source Code Disclosure Vulnerability

Yahoo Full Application Source Code Disclosure Vulnerability


Hello Friends,

Today I will be talking about a “Full Application Source Code Disclosure” Vulnerability in one of Yahoo domains.

Domain name:

Vulnerability Type: SVN Repository Disclosure Vulnerability

What is SVN ?:

SVN is a system to keep track of changes to project files. It’s usually used for any kind of project, being PHP or not, and many concurrent users to allow them to change files without overwriting each others’ changes.

Quoted from: “”

In the Exploitation scenario, SVN Directory got a file named as “entries”

This file contains the files names and directories names of the project/application.

.e.g “

As it’s clear from the above description, this SVN directory should be located only out side the web directory.

But what if that directory is located in the web directory? let’s explain the Yahoo vulnerability to understand it.

While Searching in the above mentioned domain name I found below directory on the web directory, and I’ve added “Entries” to it:

Screenshot from 2014-07-11 15:24:45


Now I can see each file and directory of the web application, so What?!

  • If the Yahoo server admin has compressed some files in .zip file, in normal scenario i will not be able to see it! but now I can see and download it 🙂
  • If the developer made a copy of the files such as config.php.bak, in normal scenario I wont see it, but now I can!
  • If the admin panel is hidden and I cant find it with any directory bruteforcing tool, Now I can easiely find it!

And many other Exploitation scenarios that could be conducted if the SVN directory is located on the web directory.

While searching the directories fetched from the Entries file, I found some directories that contain a HTML files named with the same name as the PHP files, and guess what? It has the source code of the PHP files!


Now that I knew it, I can’t visit every directory and then visit every HTML file inside the directory to see the source code!

So, I’ve wrote a Python POC file that will visit every dir and then fetch every page inside that directory to get a good POC.

The above vulnerability also helped me to gain UnAuthorized Admin access to a dir in that domain name:


I’ve reported to Yahoo both vulnerabilities:

  • Source Code Disclosure
  • Unauthorized Admin Access

Yahoo has decided to gather both vulnz in one report, and has rewarded me with, take a guess?

Yahoo has rewarded me a 250$ for this report! ya it’s 250$ you see it right 😀

This is one of the consequences of Yahoo minimized the minimum reward to be 50$!

However, Thanks Yahoo team for releasing a fast fix for this vulnerability.

Follow me on Twitter:

Yahoo! RCE Detector WebPwn3r Released.

Yahoo! RCE Detector WebPwn3r Released.




Hello Everyone,

Today blog post is about WebPwn3r 🙂

For those who never heared about WebPwn3r, let me introduce it to you.

WebPwn3r is a Web Applications Security Scanner coded in Python to help Security Researchers to scan Multiple links in the same time against Remote Code/Command Execution & XSS Vulnerabilities.

You can extract the URL’s from Burp Suite and save it in list.txt then pass it to WebPwn3r.

You can also use your own crowler to gather URL’s for a certain domain or a random domains, and save it in list.txt then pass it to WebPwn3r.

In it’s Public Demo version, WebPwn3r got below Features:

1- Scan a URL or List of URL’s
2- Detect and Exploit Remote Code  Injection Vulnerabilities.
3- ~ ~ ~ Remote Command  Execution Vulnerabilities.
4- ~ ~ ~ Typical XSS Vulnerabilities.
5- Detect WebKnight WAF.
6- Improved Payloads to bypass Security Filters/WAF’s.
7- Finger-Print the backend Technologies.

The tool is under a heavy development 🙂

Demo Video for the tool:

Success Stories:


To download the Tool:

Yahoo! Remote Command Execution Vulnerability.

Yahoo! Remote Command Execution Vulnerability.

Hello Everyone,

This is my first writeup for the blog, which I choose to be about “Yahoo Remote Code Execution” Vulnerability.

The case started with a “Remote PHP Code Injection” vulnerability that later escalated to “Remote Command Execution”.

Vulnerability Link:$Vulnerability




The server got many other Yahoo! sub-domains!

What is “Remote PHP Code Injection” ?

Simply, PHPCI occurs when user-supplied(GET/POST) values of the parameters are reflected inside eval() function, that vulnerability  allows attackers to execute PHP code such as system(“id”) or any other php function/code.


That said, I was able to inject PHP code by manuplating the value of the parameter “sid”.

In the beginning I tried to check the directories and files by “dir” using the SYSTEM function:${@print(system(“dir”))}


Indeed I need a better view!, so I tried with system(“ls -la”) But!?
It didn’t work! it does not accept any spaces in the url!!

what Actually I need a good proof of concept to explain to Yahoo! Security Team how dangerous is this vulnerability, despite the number of Yahoo! sub-domains hosted on the same server.
So I tried to bypass that issue by some tricks including URL ENCODING the space with %20 but it didn’t work. Same result with double URL encoding!


I also tried to go arround by using the function file_get_contents(“”) but this one dosen’t work because of the folder permissions, did you say do it in /tmp ?!

I thought of:

1- uploading “” which is a bind connection script, into /tmp directory

2- Execute it to make a bind connection with the server


3- Receive the connection from the server on Netcat and now I will be free to run whatever Commands 😀

But actually Netcat is a Hacking tool! it also could be detected by any simple AV/IDS on the system! this could corrupt the whole thing!
I’ve to go for another solution.

Thanks to Ahmed Abul-Ela and Ibrahim Mosaad I was able to execute commands using system($_POST[‘x2’])


<form method=”POST” action=”${@print(system($_POST[‘x2’]))}“>
<input type=”text” name=”x2″>
<input type=”submit”></form>

Also by using  system($_SERVER[‘HTTP_USER_AGENT’]) and then inject my commands inside the userAgent.

Yea I know there have been other good tricks such as using readfile(“/etc/passwd”) and many more, despite the adrenaline I had, but as you know those ideas never come to mind when you need it 😀

Sample POC for the Vulnerability [Allowed by Yahoo! to be public]:


Jan 20, 2014 at 6:39 PM – Intial Report to Yahoo! Security Team.

Jan 20, 2014 at 6:56 PM – Update 1 sent to Yahoo! that server kernel was old one with a well known “Local Privilage Esclation” vulnerability which means an attacker with such vulnerability can gain ROOT ACCESS to the server!!!!

Jan 21, 2014 at 6:44 PM – Yahoo! Acknowledged the vulnerability and pushed a Fix for it.


Thanks to Yahoo! Security team for the fast fix release.

BTW No news about the bounty yet!

Follow me: