Aquaboutic | Focus Security Research | Vulnerability Exploit | POC

 Home

thinking of browser vulnerability mining

Posted by muschett at 2020-04-08
all

In web security, the server has always played a very important role. However, the problem of browser should not be underestimated, it will also lead to information disclosure and other such problems. However, many people have not realized the importance of browser for security. In this lecture (article), we will bring readers the idea of mining browser vulnerabilities.

Thinking of exploiting loopholes

Set goals

Let's take a look at the general structure of the browser:

How can we choose attack target from many functions? At this time, we can start with:

Check for new features

The newly released features are often not studied by too many people, so they are more likely to have potential risks. Therefore, we can try to exploit vulnerabilities in the following products:

When updating, we'd better pay attention to their release diary or developer's blog. In this way, we can know the new features in the shortest time.

Firefox provides link preload in this version, which seems very interesting! At this time, white hats can use this function as a basis for security detection, or think about whether they can use it to expand the supply side.

This is a platform for us to get first-hand information:

Check the old function of the cold door

These functions are often overlooked:

In the same way, we can explore these functions through distribution records or from existing research reports.

For example:

When I use dialogarguments / returnValue, I find that data can be transferred to any window. Is there any SOP bypass vulnerability here?

When using dailog, users cannot operate other windows. Is this likely to cause UI related problems?

Enumerations - extend existing vulnerabilities

We can find the following common mechanism problems:

Studies that have been classified as high-risk also work:

By enumerating, we can better focus on the effective target. For example:

Here, we can know that IE can run scripts in CSS. Does this mean that we can use it for XSS or filter bypass?

Exploit vulnerability from commit history

We can find interesting features through git history, such as:

So, how can we find something worthy of attention:

Let's take another example. This is a commit record of chrome: https://goo.gl/xo6mmv

Before commit, chrome didn't do a good job of processing internationalized characters. The a of the following picture is actually U + 0430 (not A0 in English) of Cyrillic character set:

And: U + 0589, / U + 2215

I reported this problem, but Google's solution is to simply and roughly disable international domain names.

This commit record adds two potential attack points:

When a function of a browser has the following characteristics, it often means that the function has problems:

If you know the specific target to attack, you can check:

Looking for character set vulnerabilities

Through the improper handling of character set by browser, we can mine many problems.

Support for character set by browser:

For example, cve-2013-5612, when you do not specify a character set in the post request, it will use the last specified character set by default. We can take advantage of the differences in support to bypass XSS auditor

Looking for vulnerabilities in third-party libraries

In pwn2own, researchers from Changting technology successfully used SQLite's memory corruption to break safari. Similarly, we can look for vulnerabilities in the following lib:

Other attack areas

Browser parsing special protocols (such as about) can also cause problems. When we type about: neterror? E = nssbadcert & D = Hello% 20guys! In Firefox, there are:

Don't forget to learn from previous experience

While we are looking for loopholes, we should not forget to learn from our predecessors' ideas. We should think about these questions more: what kind of loopholes are? How did they find the leak? Why does this loophole appear? We can learn how to find vulnerabilities through security advisor (Mozilla, chrome) and private blogs.

In depth research objectives

To explore a goal in depth, we need to understand the following features:

So, what means should we use to dig in depth?

Take the fetch API:

fetch('http://api.example.jp/path',{ //我在这里能代入哪些地址？ method:'POST', //我还能添加哪些方法? headers: { 'Content-Type':'text/plain' //这里是否能插入其它header或者MIME类型? }, body:'Hello World!' //body能插入哪些文字? }).then(function(res){ console.log(res.headers.get('Content-Type')); //我能读取哪些header的值? }).catch(function(err){ console.error(err); //抛出的错误时候包含了敏感信息? });

An example of finding a vulnerability through reverse:

A DLL of edge contains the regular expression of XSS filter. We may find the bypass payload through reverse derivation.

Explore interesting behaviors

When we find some abnormal behaviors, we need to continue to pay attention, because this often means deeper loopholes:

For example, for cve-2012-3695, when we input https://aaa% http://[email protected]/,% 2F will be decoded and https://aaa/ @ http://example.com/ will be returned. AAA% 2F, which was originally used as authentication, has been converted into a domain name, which is likely to lead to phishing.

What are the skills to exploit such loopholes? We can check the following functions:

For example:

In cve-2017-7789, if Firefox receives multiple HSTs headers in the response, HSTs will not be enabled. At this time, as long as the attacker includes several HSTs headers in the normal HTTP response, he / she can bypass the HSTs mechanism.

In cve-2015-4483, we can bypass content mixed blocker by adding URL after 'feed:'

Loophole utilization

When you find a vulnerability, how do you take advantage of it:

Let's take a look at a strange behavior of Firefox plug-in. Although we can use this vulnerability to inject HTML into the title of the page (the title of the tab), we can't trigger XSS due to CSP.

When we carefully observe the order of% Title%,% content%, we will find a template injection vulnerability:

In this way, as long as we insert the form element to% Title%, even if we can't XSS, we can bring% content% to the attacker.

In the actual situation, many websites insert user input into the page title. Take Google for example:

However, it seems to be useless to get other people's search results. Can we get more sensitive information?

Gmail seems to be a good target. We can send a malicious email to the target. When he / she expands the email, the page title will be replaced with the email Title:

When the user clicks click me, the mailbox information will be sent to the attacker

At this point, we have successfully turned this vulnerability into a treasure.

By Masato Kinugawa

Two way foil Security College: mainly focusing on the field of web security, the team has exported security capabilities for Google, apple, Microsoft, W3C, adobe, Tencent, Ali, etc. It is committed to promoting the innovation and dissemination of knowledge in cyberspace security field, and providing the most cutting-edge security skills for the majority of Xin'an technical personnel.

Twosecurity.cn

WeChat public No. two: twosecurity, the latest course information, discount activities and free dry cargo official account.

© 2023