Posts by: zigoo

An interesting Google vulnerability that got me 3133.7 reward.

An interesting Google vulnerability that got me 3133.7 reward.

Note: This blog post doesn’t represent my employer by any meaning and was performed during my free time.

Hi All 🙂

Before we start, 3133.7 stands for Elite. It is a leet/1337 way of Google to reward researchers 😀

While doing security researching on Google. Decided to focus on “” as it sounds interesting with lots of features.

During my testing, saw the following very interesting request in the Burp Proxy going to:

Note: Page original response is “Not found” within a JSON format. Not that important to include here.

Immediately 2 things got my attention. First, the GET request within the POST request body along with the request headers as well. Second is being able to control the content-type via the value in the URL of the main request. Later on, noticed that there is a KEY being sent within the POST request body.

My expectation: 

The server of “” is relaying the GET request via the POST request body to an intermediary server (reverse proxy / load balancer) that would parse it somehow and process it or pass it over to a third-server. The intermediary server doesn’t care about the headers of the original POST request, but only parses the GET request headers that are being sent within the POST request body.

Well, few things to conclude this is:

1) I’m able to control the headers that the intermediary server will process;

2) It is possible to control the response type via the value below marked in red:

3) There is a key and authorization header values in the request.

To get directly to the point, number 2 and 3 led to nothing. But the good point is, it was not being validated. lets keep a note of that.

Now to the interesting part, which is manipulating the HTTP request headers itself. My approach was to perform the following test cases against the GET request in the POST body:

1) Play around the HOST header “Virtual Hostname Enumeration”. Like setting the host header to dev, localhost, portal, and so on. So that the webserver is tricked into disclosing locally configured virtual hostnames. Thus, allowing access to internal environments. (Didn’t work)

2) Spoofing my IP address by the following headers. Trying to induce the backend server that receives the request to treat it in a different way. (Didn’t work)

  • X-Forwarded-For:
  • X-Client-IP:
  • Client-IP:

3) Forcing the backend server to through some errors. Have tried this by sending large input of AAAAA’s, changing the HTTP protocol version instead of 1.1 to something else, adding some random headers or manipulate the existing once, manipulating the content-type and so on (Didn’t work)

4) Blind XSS/SQLI in the userAgent value, it might get processed at some point! (Didn’t work)

5) Have also tried to manipulate the origin header to hopefully find a misconfigured CORS implementation, but the origin was well validated.

Was out of options, till I thought of why don’t I directly “talk” to the backend server the way it understands?! A web server spoken language is basically headers! It sees header, it parse it, then process it, Simple!

One of the interesting headers that allows you to “talk” to the web server is “X-HTTP-Method-Override“. This header basically allows some magic stuff. For example, you can send GET request to the server, but the server would treat it as PUT, POST, DELETE or whatever the method you declared! yes, although it is originaly a GET request 😀

An example is:

GET /test.php HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
X-HTTP-Method-Override: PUT
Accept-Encoding: gzip, deflate
Connection: close

When the web server receives the above GET request and parse it, it will find the XHMO header in there and would say

“Oh! this is a GET request but the user wants me to treat it as PUT, consider it done, Sir!” and treat it as PUT instead 😀

The reason of why this behavior is needed, some intermediary servers (reverse proxy/load balancers, WAF’s) are limited in the HTTP methods it supports (i.e. Only GET and POST is supported). However, the developers might still want to send a “PATCH, DELETE, PUT” methods. Here is where the XHMO comes to play.

Oh, and did i mention that I have once triggered RCE via the HTTP PUT method and webdav was enabled, while there was F5 WAF watching all the traffic?

My burp repeater —-> Hey Web server, I want you to create a file via PUT method —-> F5 says: You have to pass through me first, and I only support GET/POST! —-> FAIL!

My burp repeater —-> Hey F5, I know that the backend server supports PUT, so here is your GET request with XHMO set to PUT. Please pass it to the backend server —-> F5 says: sure, seems legit! —-> Backend webserver: yea, another PUT request to handle. HYG, your file is created because I do support PUT and I understood your call. —-> Bingo!

With all details being said, have added the XHMO header to the request with HTTP method PUT hoping that webdav is enabled on the backend webserver so that I could somehow get RCE. And no, it didn’t work, Buuuuut!

The middle webserver couldn’t understand what to do with that header! so it decided to through a very much detailed error message that discloses:

  • HTTPOnly and Secure cookies!
  • All communication details of the connection between the intermediary server and the backend server. Including SSL hello message, IP’s, ports and so on;
  • Also the authorization headers and few more interesting messages too.

Note: the screenshot is being in bad quality on purpose.

Remember when I said that nothing in the request was being validated? based on that, have created a CSRF POC that would trigger the same exact response for other Google users. And it is possible to steal these information using a reflected XSS!

In theory, HTTPOnly cookies are well secure against XSS attacks. But using this vulnerability, it is possible to steal the HTTPOnly cookies from Google users who are tricked into clicking the malicious link.

And that only happened when adding the XHMO header. The page originally returns a ‘not found’ response.

Have reported the vulnerability to Google, the team have set the priority to P1. They were fast in responses and handled the vulnerability professionally. Later on, received below Email from Google:

Hope you enjoyed reading  🙂


Ebrahem Hegazy – @Zigoo0


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$ !!



 Remote Command Execution! Remote Command Execution!


Salam from Egypt 😀

Welcome to this blog post about a Remote Command Execution Vulnerability that affected!

It all started when i found below Domain:  ( umfragen = suggestions in Deutsch language)

Screen Shot 2015-10-25 at 9.03.47 PM

The index page of the domain gives nothing! also i tried some google dorks to find pages on that domain but couldn’t find anything useful.

Now it is the time for some Brute-Forcing attacks!

I’ve used a file brute forcing application i wrote in python time ago, and I found below page: upload.php

Screen Shot 2015-10-25 at 9.05.30 PM


As you can see, the page has nothing useful at all! i tried to mimic a normal file upload functionality with some common parameters but nothing worked!

Now it is the time for Pemburu 😀

What is Pemburu?

Pemburu (The Hunter in Bahasa Melayu Language) is an application I wrote in python, the main idea behind Pemburu is Gold-Digging

lets say you have the same scenario like in my case here, where i have this page:  But can do nothing!

You just give that link to Pemburu and it will perform below actions:

1- Will try to add common files extensions to the file name to search for a backup for that file such as:

upload.php~ (~ is a default ext for a backup file which will be generated when the system admin tries “nano upload.php”)

Screen Shot 2015-11-11 at 10.58.38 PM

2- Will try to manipulate the domain name itself searching for another copy of the file located else where such as(notice the Blue color):,,

Screen Shot 2015-11-11 at 11.07.41 PM

That said,

I started the Pemburu, passed the URL to the tool, and got below url as a result:

Screen Shot 2015-11-14 at 1.46.59 AM

Pingo!  i found below page:

When browsing the above found page, it contained below source code:

Screen Shot 2015-11-14 at 1.49.03 AM


This is simply a mis-configuration at the server side, it doesn’t understand that this is a php file unless you begin your code with:


if you started your code with “<?” it will not understand it and will render it as a normal text!

That said, now i’ve the source code of the page!, after going through the source code, i found below vulnerable function:

Screen Shot 2015-11-14 at 2.14.38 AM


This function is vulnerable because it takes the user input from a POST parameter without any sensitization, concatenate it with other strings & user inputs, and then pass it to php system() function, system function is usually used for command execution and should be used with cautious!

This is a clear Remote Command Execution, as a result i started testing the POST parameters and below is the final POST request that triggered the RCE:

POST /upload.php HTTP/1.1
A=x&B=xx&ACCOUNT_PWD=";uname -a;"&LANG=en&ACTION=results


Screen Shot 2015-11-14 at 2.32.23 AM

Screen Shot 2015-10-25 at 8.10.32 PM

The bug were fixed within 2 days by Duestch Telecom CERT.


You can try the “Pemburu” tool on Github:

Your feedback is highly appreciated 🙂



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 🙂


Paypal critical vulnerability to steal all your Paypal funds!

Paypal critical vulnerability to steal all your Paypal funds!



Hello Readers 🙂

This is Zigoo0 again, and today i will talk about a Stored XSS Vulnerability in “” that could be used by attackers to steal Paypal users credit card and login credentials and more!

Vulnerability Title: Paypal Critical Vulnerability to steal Users Credit Cards in ClearText format

Vulnerable Page:

Vulnerable Parameter: template

Vulnerability Details:

Paypal SecurePayments domain is used by paypal users to do secure payments when purchasing from any shopping site,

This secure payments page require Paypal users to fill some forms that include their Credit Card number, CVV2, Expiry date and more to finalize the payment and purchase the products via their Paypal account,

The submitted data is processed through encrypted channel(HTTPS) so attackers wont be able to sniff/steal such data.

I’ve found a Stored XSS vulnerability that affects the SecurePayment page directly which allowed me to alter the page HTML and rewrite the page content, An attacker can provide his own HTML forms to the user to fullfill and send the users data back to attacker’s server in clear text format, and then use this information to purchase anything in behave of users or even transfere the users fund to his own account!

Screenshot from 2015-08-26 20:07:14

Vulnerability Consequences:

The worst attacking scenario that could be conducted using this vulnerability is:

1- Attacker setup shopping site or Hack into any shopping site, alter the “CheckOut” button with the Paypal Vulnerability,

2- Paypal user browse the malformed shopping site, choose some products, click on “CheckOut” button to Pay with his Paypal account,

3- User get’s redirected to to fill the required Credit Card information to complete the purchasing order, In the same page, the products price that will be paid is included inside the same page, and as we know the attacker now control this page!

4- Now when you (Paypal user) click on Submit Payment button, instead of paying let’s say “100$” YOU WILL PAY TO THE ATTACKER WHATEVER AMOUNT THE ATTACKER’S DECIDE!!

Screenshot from 2015-08-26 20:50:32

Demo: Now that you’ve reviewed the vulnerability details, it’s the Demo time 😀

In below demo video i’ve showed how an attacker with this vulnerability could steal your Credit Card and login Credentials information!


As an Ethical Hacker, this vulnerability was reported to Paypal and is now FIXED, Welcome back SECURED SecurePayments 🙂

Below is a TimeLine of the vulnerability:

Time Line:

Vulnerability Discovery: 19/Jun/15 2:27 AM

Vulnerability Reported: 19/Jun/15 7:10 AM

Remediation Notification: Aug 24, 2015 at 7:04 PM


Thanks Paypal Security team for the good coordination the fast responses for Emails.

You can follow me on Twitter for the latest vulnerabilities/news/updates -> @Zigoo0 🙂

Yahoo SQL Injection to Remote Code Exection to Root Privilege.

Yahoo SQL Injection to Remote Code Exection to Root Privilege.


Hello from Egypt 😀

Today I will blog about a SQL Injection vulnerability that were escalated to Remote Code Execution, Escalated to Root Privilege on one of Yahoo servers.

The story started while searching in below domain:

while intercepting the POST requests, I found below request that graped my attention with the possibility of SQL Injection.

I started some manual checks and it seems a SQL Injection is flying over there!
Shooting it with SQLMap, I got below POC as a confirmation of a Vulnerability!
f_id=-9631′ OR (2777=2777)#

Available Databases:
[*] information_schema
[*] innovation******* #Hiding dbnames for Yahoo privacy.
[*] web****

Good, now I’ve a SQL Injection and I can read data as well,

Now, How about finding the admin panel, extracting the administrator Username and Password, login to the administrator panel, trying to find a RCE!

1- Admin panel found on:

2- I found the Administrator Password stored in the database and it was encoded as Base64 😀


Good, I’ve decoded the Administrator Password, Logged in to the Admin panel.

Hey Admin Panel! Say Hello to my readers 🙂


Now the next step is to find a place to upload files so I can trigger a Remote Code Execution!

That said, I’ve found a upload page, but after uploading a file with “phpinfo();” function as a content,
I found that my uploaded file was named as: page_d03b042780c5071521366edc01e52d3d.xrds+xml

instead of being page_d03b042780c5071521366edc01e52d3d.php ?!

hmmmm, I then tried to intercept the uploading request to find out the problem, and I found below info:

Screenshot from 2014-09-05 05:59:33Yea, now the reason is clear! it’s due to the “Content-Type” Header!

I tried the same request again, but this time I’ve alternatively renamed the “Content-Type” Header to be “application/php” instead, and Here we Go 😀



Now I’ve triggered the SQLI and the RCE, the last part remains is the Root access on the server,

However, the server kernel were latest updated on 2012! and I had the opportunity to root it with a Local root exploit vulnerability in that non-patched kernel!



2014-09-05 Initial report to Yahoo

2014-09-06 Yahoo confirmed the vulnerability

2014-09-07 Yahoo Fixed the Vulnerability

2014-09-19 Yahoo announced me that this vulnerability is not eligible for a reward!!!

Note: I find it very strange that Yahoo did not pay a bounty for such Critical bug even if it fall outside the scope, Yahoo pays for Critical vulnerabilities in Out of Scope domains, if a SQLI to RCE to Root Privilege is not a Critical bug, then what could be?!


You can follow me @


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:

One RCE Vulnerability to Hack Yahoo, Microsoft, Orange.

One RCE Vulnerability to Hack Yahoo, Microsoft, Orange.

Hello Everyone 🙂

Today I will be talking about a “Unauthorized Admin Access” that led to “Remote Code Injection” on many domains of “Yahoo“, “Microsoft MSN“, And “Orange“.

Excited? Good, Now let’s dive into the details.

During my researches in #Yahoo Bug Bounty Program, I found myself in a domain:
I tried to find the admin panel for that domain name, so I found myself in below page:

The thing is, it dosent ask me for any login credentials!

Yes I just found myself in the admin panel without asking for a login credentials, this what is called “Unauthorized Admin Access due to Insecure Direct Object Reference“.


So, You see that list of files on the left side? I had an option to create a new “ASPX” file. I tried to intercept the POST request sent when trying to create a new file, So, here is what I got.

As you see, it’s a POST request to the below URL with below POST data:
POST: FileName=zigoo.aspx&FileContent=zigoo

Yes, You’ve only to provide the new created file name and whatever content you want to add!!

So, I did create a file named “zigoo.aspx” with my name as a content “zigoo”:

RCEOfcourse I could have created that file with a code to give me Remote Command Execution Privilege, but I saw it was a good/enough POC.

Now what?
I tried to check if there is any other Yahoo domains that were affcted by the same vulnerability?
I searched for the same sites hosted on the same server and I found below sites on the same server:


#Microsoft MSN:


So, what was the shocking issue here?
The shocking thing here is that I don’t have to upload/create my page on every domain to make a good POC!

Because once I created that page on one of the Yahoo domains mentioned above, I found that my page has been created on ALL SITES hosted on the same server, Yahoo, MSN, Orange and others!

Imagine a Black-Hat with this vulnerability, creating his “Iframed” aspx page with it’s malicious content on such highly ranked/trusted domains of and more!!

How did it happen?
I tried to contact Microsoft regarding this question, they said “We will investigate it”

Till they investigate it, below is my expectation:
It’s A CDN(Content Delivery Network) Service for astrology that caches the same content to render it for the sub domains of that mentioned vulnerable domains, So all files on one domain will be shown on all other domains on the server.

Below video shows the POC file that was created on all the above mentioned domains.

What happened after the report?

#Yahoo_Case, Thanks to R.Martinz for speeding up the fix release,
Yahoo does not pay bounties for vulnerabilities found in, but they decided to reward me for this vulnerability since it’s a Critical Vulnerability that Affects 6 Yahoo domains.

#MSN_Case, I tried to get any reward from Microsoft for reporting such Critical Vulnerability that affects 4 MSN domains, but as you all know how Microsoft Acts like!! Ofcourse you all could expect what happened here 😀

#Orange_Case, It was hard as hell to get in touch with Orange! till I gave up!, But fortunately, the fix that was released by Microsoft has fixed the issue on all the server domains including Orange.

To stay tuned to my latest findings, Keep an eye on my Twitter account, @Zigoo0

1 of 2