Introduction to the browser fuzz framework

Introduction to the browser fuzz framework

This article briefly introduces the principles and advantages and disadvantages of the three popular browser dynamic Fuzz tools cross_fuzz, grinder, and X-Fuzzer, it also provides a browser fuzz method that combines Dynamic and Static features to ensure reproducibility, versatility, efficiency, and automation.

0x00 Introduction

Fuzz (Fuzzy testing) is a method that focuses on discovering software security vulnerabilities. Typically, the fuzzy testing process uses automatic or semi-automatic methods to repeatedly drive the operation of the target software and provide it with "carefully" constructed input data, while monitoring the exceptions of software running, then, you can search for Software Security Vulnerabilities Based on the exception results and input data. With the development of Smart Fuzz, RCE (reverse code engineering) needs to increase, and its features are more in line with a gray-box test. The brief flowchart is as follows:

Web browsers are one of the most widely used software in network applications. Internet Explorer, FireFox, Chrome, and other mainstream browsers occupy most of the Web browser market share, its own security has received much attention and wide impact. The browser fuzz introduced in this article is based on the above three browsers as the main goal of fuzz, and uses random html pages of content (css, html, and js) as the input of the tested browser, it also monitors abnormal operations of the browser and finds its security vulnerabilities.

The browser fuzz is a common and effective method for finding browser vulnerabilities. The public dynamic browser fuzz tools include cross_fuzz, grinder, and X-Fuzzer, these tools use javascript scripts to perform fuzz operations. At the same time, they dynamically record fuzz operation logs through hook functions, localStorage, and other technical means. After exceptions are caught, they are restored Based on the logs.

The existing browser fuzz tool dynamically records logs, which may affect the execution environment of the tested browser, and sometimes cannot reproduce exceptions. Besides, it is universal in the logging method (such as the ActiveXObject of IE) and poor stability (grinder hook function.

Many browser fuzz tools restart the browser to be tested every time they run a test case, because the restart of the browser takes a large amount of time to run a test case, resulting in low fuzz efficiency.

Some browsers fuzz tools (such as the classic cross_fuzz) will stop fuzz in case of crash, and the degree of automation is insufficient.

This article summarizes the advantages and disadvantages of the existing dynamic browser fuzz tool, the New Browser fuzz (New Browser Fuzz) provides a combination of dynamic and static features to ensure reproducibility, versatility, efficiency, and automation ).

0x01 corss_fuzz Introduction

Cross_fuzz was developed by google's security researcher Michal zarewski. It supports multiple browsers fuzz and is specially optimized for IE browsers. This tool and the derived browser fuzz tool found a large number of browser security vulnerabilities. Its design philosophy has a profound impact on browser vulnerability mining.

Cross_fuzz mainly describes the design concept of browser fuzz. It is only a demonstration function module and is not a complete browser automation fuzz tool, for example, key operation logs and exception monitoring must be implemented by the user.

Interface

Flowchart

0x02 X-Fuzzer Introduction

X-Fuzzer is a lightweight dynamic browser fuzz tool developed by Vinay Katoch, a security researcher. Its logging adopts common localStorage local storage and document in mainstream browsers. cookie, logs can be saved even if the browser crashes unexpectedly. The dom element fuzz operation and log record of this tool are simple and need to be improved on its own. Moreover, this tool does not have an exception monitoring module and cannot implement automated fuzz.

Interface

Function module diagram

0x03 introduction to grinder

Grinder is an automated browser fuzz framework. The client node is mainly written in ruby.

Its log records inject grinder_logger.dll to the tested browser process, and hook the javascript function parseFloat in jscript9.dll and javasjs. dll and other implementation functions in the script engine. To record logs, you only need to call the parseFloat function. The logging function is completed by the corresponding hook callback function in grinder_logger.dll. You must note that the hook operation can be completed only after the corresponding dll symbol file is downloaded, and the latest version of Firefox does not include javasjs. dll, which causes the hook function to fail. This logging method is stable and versatile.

The monitoring module (dbghelp. dll and symsrv. dll) is responsible for starting and monitoring the tested browser, recording its exception information, and completing fuzz automation.

The reproduction module (testcase. rb) reconstructs the POC Based on logs.

The specific fuzz operation must be completed by the user.

Interface

0x04 NBFuzz

Summary of NBFuzz logging methods

ActiveXObject only applies to IE. The localStorage of cookie and html5 is suitable for mainstream browsers such as IE, Firefox, and Chrome, but the storage size is limited (cookie 4 K and localStorage 5 M). You need to set the browser to support cookies and record history. IE does not support localStorage when opening html files locally. Html5 local database indexDB and SQLite are not universally available (IE is not supported or partially supported) and are complicated to use. XMLHttpRequest has good versatility, but each fuzz operation requires real-time recording. The total communication time is long, which affects the fuzz efficiency. XMLHttpRequest improvement: fuzz operates localStorage for local real-time storage. When each test case starts, localStorage sets an exception flag. No exception marks are left blank when the test case ends; the next test case uploads abnormal fuzz records to the server through XMLHttpRequest. This solves the communication bottleneck for C/S to record fuzz operation logs in real time and the localStorage size can meet the requirements. Discard fuzz operation logs: dynamically recorded logs may affect reproduction (such as indexDB and localStorage), and poor universality and stability (such as grinder hook function). NBFuzz directly generates test cases, fuzz operation logs are not recorded, and the generated test cases do not have random operations. This ensures reproducibility and versatility. NBFuzz module diagram

Generate a large number of fuzz test cases in the specified browser through the test case Generation Program, and place the generated test cases and scheduling pages on the web server. The monitoring module opens the browser to be tested to access the scheduling page, the scheduling page calls test cases sequentially through the embedded iframe page. The monitoring module records the abnormal or timed-out browser processes to restart the browser to ensure the automation of the browser's fuzz; finally, analyze the exception information recorded by the monitoring module to find out the suspicious crash and find the file whose modification time matches the modification time in the log file of the web server, obtain the name of the test case that causes exceptions from the scheduling page, and then reproduce the crash to further determine the availability of the vulnerability.

Test Case Generation

Interface

Generate a large number of test cases containing different properties, functions, and garbage collection mechanisms based on the selected browser type, because the ActiveXObject unique to IE is used for local file operations, you must use IE to run this program and use js to write test cases containing js.

Flowchart

Test Case loading (scheduling module)

To solve the large proportion of browser startup time in each browser restart test case, the NBFuzz scheduling module opens the test case through embedded iframe, after a test case is completed, the reload operation on the scheduling page executes the next test case. To prevent the page from responding to exceptions, the monitoring module restarts the browser to be tested after timeout; meanwhile, in order to prevent the web server from adding an inaccurate exception judgment mechanism to record too many log files, the exception flag cannot be set to false due to timeout and restart, leading to false alarms, however, this will greatly reduce the log size.

The scheduling module flowchart is as follows:

0x05 browser Fuzz Summary

As browser security mechanisms (such as delayed release of IE and isolation heap) continue to strengthen, the security vulnerability blowout trend has been curbed; flash, which is still widely used, has gradually become a hot topic in security research due to its imperfect security mechanism, and security vulnerabilities are also exposed. It is foreseeable that, in the near future, if flash is still fixed, it is bound to follow the footsteps of java and gradually be "abandoned" by users ".

You only need to make some changes to the flash fuzz framework based on the NBFuzz framework. For example, you need to add the as3 test case compilation process to swf.