Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to achieve remote code execution in the Mozilla AWS environment through WebPageTest service 0day vulnerabilities. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

When analyzing the attack surface of the Mozilla AWS cloud service network environment, the Assetnote CS security team found that there was a 0day vulnerability in the network performance testing tool WebPageTest deployed in it, which was finally used to realize remote code execution (RCE) to the Mozilla AWS server.

WebPageTest introduction

WebPageTest is an open source Web front-end performance analysis tool, available in both online and local versions, provides free performance evaluation for specific sites, supports IE and Chrome browsers, and simulates the use of real browsers (IE and Chrome) connection speed to run free website speed tests from multiple locations around the world. You can run simple tests or perform advanced tests, including multi-step transactions, video capture, content blocking, and so on. A wealth of diagnostic information will also be provided based on the test results, including resource loading waterfalls, page speed optimization checks and suggestions for improvement, with a final rating for each item. Enterprises or organizations can download the open source version to build an internal test site to test and analyze the performance of the internal website.

In the WebPageTest service deployed in the intranet, some basic user name and password authentication can be enabled by modifying the settings.ini file, so it is recommended to configure this to prevent some anonymous users from logging in.

In many intranet WebPageTest services evaluated by the Assetnote CS security team, there is a lack of basic user authentication measures, so the possible result is that attackers can use a series of performance testing tools of WebPageTest to launch SSRF (server request forgery) attacks to access the target private network resources.

Overview of vulnerabilities

In November 2017, the Assetnote CS security team discovered the following two network assets during a test of Mozilla's AWS (Amazon Cloud Service) environment:

Wpt-vpn.stage.mozaws.net

Wpt1.dev.mozaws.net

These two network assets belong to the WebPageTest service test examples in the Mozilla AWS environment, and the WebPageTest services deployed in the Mozilla AWS environment do not have any basic user name and password verification measures. in cooperation with White Hat Mathias, we analyze the source code of the WebPageTest services deployed there. after several hours of testing, we find an attack chain that can lead to remote code execution (RCE).

Since this was a 0day vulnerability at the time, we communicated and negotiated with Mozilla and the WebPageTest team in time to fix the vulnerability. You can see the submitted commit information in the fix version of January 17, 2018.

Vulnerability discovery and utilization

In the source code of WebPageTest, the first thing we notice is that the / www/work/workdone.php script has the ability to upload and extract any zip file, which contains access source logic beyond the restriction of 127.0.0.1. The code is as follows (line 110):

! strcmp ($_ SERVER ['REMOTE_ADDR'], "127.0.0.1").

Also in this php file, we found another danger, which is the logic to upload any zip file and extract it to a known location, as follows (lines 133-136):

If (isset ($_ FILES ['file'] [' tmp_name'])) {ExtractZipFile ($_ FILES ['file'] [' tmp_name'], $testPath); CompressTextFiles ($testPath);}

Based on the above code logic, if we can disguise IP as 127.0.0.1, can we use them to implement server-side code execution? However, the fact is not as simple as we thought. At line 321 in / www/work/workdone.php, there is also a method function:

SecureDir ($testPath)

The code for the SecureDir method function is defined on lines 2322-2347 of the / www/common_lib.inc file:

/ * Make sure there are no risky files in the given directory and make everything no-execute** @ param mixed $path*/function SecureDir ($path) {$files = scandir ($path); foreach ($files as $file) {$filepath = "$path/$file"; if (is_file ($filepath)) {$parts = pathinfo ($file); $ext = strtolower ($parts ['extension']) If (strpos ($ext, 'php') = false & & strpos ($ext,' pl') = false & & strpos ($ext, 'py') = = false & & strpos ($ext,' cgi') = = false & & strpos ($ext, 'asp') = = false & strpos ($ext) 'js') = = false & & strpos ($ext,' rb') = false & & strpos ($ext, 'htaccess') = = false & & strpos ($ext,' jar') = false) {@ chmod ($filepath, 0666) } else {@ chmod ($filepath, 0666); / / just in case the unlink fails for some reason unlink ($filepath);}} elseif ($file! ='.'& & $file! ='..'& & is_dir ($filepath)) {SecureDir ($filepath);}

It checks and filters out some dangerous files and ensures that no files are executed, and because it appears later in the subsequent code stream, there is an available race condition (Race Condition) in which PHP files extracted to the web server can be accessed briefly before being filtered and deleted.

In the attack chain we constructed, the prerequisite is very simple, because in the WebPageTest service of the target asset wpt-vpn.stage.mozaws.net, after executing the Traceroute command, we can get a valid test ID generated by WebPageTest, which is easier to do with this ID number. For example, we execute the Traceroute command to https://google.com:

After that, the WebPageTest service jumps to a performance test results URL page containing test ID:

Http://wpt-vpn.stage.mozaws.net/result/171124_GW_9/

Here, 171124_GW_9 is test ID.

At this point, we are still short of 127.0.0.1 IP forgery, if this step is successful, we can effectively access the workdone.php file and initiate command execution.

After analysis, we found the following code logic in line 70 of the / www/common.inc file:

If (isset ($_ SERVER ["HTTP_FASTLY_CLIENT_IP"]))

$_ SERVER ["REMOTE_ADDR"] = $_ SERVER ["HTTP_FASTLY_CLIENT_IP"]

From this code snippet, we can set the FASTLY-CLIENT-IP request header to 127.0.0.1 by sending a request, thus arbitrarily changing the IP address of $_ SERVER ["REMOTE_ADDR"] as a remote user.

To sum up, we can set up two Burp Intruder attack extensions to achieve the final server code execution. One of the Burp Intruder is used to upload a malicious zip file, and the other Burp Intruder is used to access the extracted php file that exists on the target system. To take advantage of the above competitive conditions, the maximum number of Burp Intruder threads is 200.

But fortunately, with the help of the high-speed request plug-in Turbo Intruder, our exploit chain is more stable. Finally, we successfully implemented the server-side code execution in the Mozilla AWS network environment. As follows, we implemented the call reading of phpinfo () in wpt-vpn.stage.mozaws.net:

On how to achieve remote code execution in the Mozilla AWS environment through WebPageTest service 0day vulnerabilities is shared here. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.