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 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 🙂



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 @


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 Unvalidated Redirection Vulnerability. Unvalidated Redirection Vulnerability.


Would you trust a link from your security vendor? Absolutely Yes! But imagine your security vendor is asking you to download a malware!

During my researches on I found “Unvalidated Redirection Vulnerability ” that could be used by attackers to trick users into visitng Malicious web-sites!

To demonstrate the impact of such vulnerabilities I made a video to simulate a black-hat method to use this vulnerability to spread a Malware.

Video POC:

The consequences of unfixing of such vulnerability are critical
  • Wide infection – since the redirection is coming from a trusted source especially if the attacker registered a domain name similar to
  • Very bad reputation for Kaspersky company.
  • Your most trusted resource “Your Antivirus” will be your worst enemy! Would you trust anything else!
And many other consequences. The vulnerability was reported to Kaspersky web-team and is now fixed. Unrestricted File Upload Vulnerability. Unrestricted File Upload Vulnerability.

Critical vulnerability in Twitter allows attacker to upload Unrestricted Files

Twitter Acknowledged me on their Hall of Fame for finding and reporting Two Vulnerabilities in their web site.

Those two vulnerabilities are:

1- Unrestricted File Upload Vulnerability.


The POC:

When an application does not validate or improperly validates file types before uploading files to the system, called Unrestricted File upload vulnerability.
Such flaws allow an attacker to upload and execute arbitrary code on the target system which could result in execution of arbitrary HTML and script code or system compromise.

2- Unvalidated Redirection Vulnerabilit

This vulnerability could be used by Attackers to conduct Phishing and malware spreading attacks against Twitter users.

Link to Twitter Hall Of Fame: