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:
- DOM parsing (HTML, XML, SVG, MathML, XUL)
- Script processing (JavaScript, VBScript, ASM. JS, webassembly)
- Protocol support (HTTP, FTP, websocket, http / 2, quic, DNS, mDNS, webrtc)
- Media streaming support (jpg, GIF, PNG, WebM, Ogg, AAC, MP3, MP4, FLAC)
- Middleware included (skia, ffmpeg, ICU, NSS, openvr, libpng, SQLite)
- Various APIs (fetch API, push API, extension API, fullscreen API, web speech API)
- UI building (location bar, history, bookmark, context menu)
- Safety function (SOP, XSS filter, CSP, Sri, TLS, mixed content, HSTs, hpkp, CT)
- Convenience features (Chrome extension, reading view, secret mode)
- Other
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:
- Firefox Nightly
- Chrome Dev, Canary
- Safari Technology Preview
- The latest version of edge
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:
- Non standardized functions
- Cold door function
- Regular plug-ins
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:
- HTTP communication mechanism of JavaScript (sendbeacon, fetch, worker)
- Alert, confirm, getusermedia
- MIME type (text / JavaScript, image / SVG + XML, application / octet stream...)
Studies that have been classified as high-risk also work:
- Windows objects
- HTTP leakage
- HTML5 Security Cheatsheet
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:
- Support for mobile systems (3D touch, spotlight, universal links)
- Features under development (web app manifest, geckoview)
So, how can we find something worthy of attention:
- Features that have been identified as high-risk by developers
- Implement complex third-party libraries (SQLite, alamofire)
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:
- Does storing data with SQLite mean there is SQL injection?
- Will inserting variables into the page result in XSS?
When a function of a browser has the following characteristics, it often means that the function has problems:
- Give the URL to the API and it will return a specific flag
- Abnormal operation of CSP
- You can send any header to a target
If you know the specific target to attack, you can check:
- Value returned by location
- Behavior of functions
- Is CSP implemented correctly?
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:
- What is this function used for
- How to use it
- What are inputs and outputs
- Is there any filtering
- Can we use it to bypass security
- Can we use it to attack security sites
So, what means should we use to dig in depth?
- Use it yourself
- Audit code
- Audit executable (disassembly)
- View software log
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:
- After jump, the address bar is not updated (URL spoof)
- An input causes the browser to crash or pause the response
- HTML tag is not working properly
- Literal code
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:
- URL scheme (http:, https:, ftp:, data:, resource:, about:, chrome-extension:)
- Request method (GET, POST, HEAD, OPTIONS, TRACE)
- How to output related information (iframe, object / embedded tag, SVG foreign object, reading view)
- How to get resources from browser (IMG tag, video / audio tag, worker's importscripts)
- Method to open a new URL (location header, meta refresh, window.open, browser return key)
- Unconventional input (too long string, HPP, null, too large number, negative)
- Enumerate various other elements to quickly discover possible pitfalls.
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:
- Imagine how to use it in existing web applications
- Because of this vulnerability, we can attack the original secure web page
- This vulnerability will cause the browser security mechanism to fail
- Even if you can't use it in some scenes, you should also consider the ideal environment to use it
- If this website is implemented in this way, how can we (attack)
- If this assumption is relatively reliable, the vulnerability may work in a specific environment
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.