PowerDNS Recursor HTML/Script Injection Vulnerability – A Walkthrough

PowerDNS Recursor is a high-end, high-performance resolving name server that powers the DNS resolution of at least a hundred million subscribers. The “Recursor” is one of two name server products whose primary goal is to act as resolving DNS server.

On Aug. 7, 2017, I reported an XSS (cross-site scripting) vulnerability to PowerDNS and its Security Team. They assigned it the identifier CVE-2017-15092.

In this report I will explain how I was able to identify and trigger the vulnerability.

Identifying the Attack Vector

As part of FortiGuard Labs’ regular zero-day research efforts, I decided to start with a Black-box approach to see if I could identify any potential vulnerabilities in PowerDNS Recursor before moving to source-code analysis and other vulnerability identification techniques.

During the initial attack surface inspection, I realized that the product features a Built-in webserver that exposes a JSON/REST API that simplifies the way users can interact with the service in. That seemed like a good starting point to look around and I chose to research it a bit more.

I found several ways to interact with the API, but the one that caught my attention was the web interface which displayed data such as domain information, DNS query record type, and others. Interestingly, all of these information came from regular DNS queries, which I took to mean that any data contained within a DNS request should also be displayed on the screen.

To confirm my assumption, I made a normal DNS query by entering the following command from a machine located on the same network: 

In the following screen you can see that the web interface shows the results from the executed DNS request (A – record type) to google.com, which directs the query to the PowerDNS DNS.

Figure 1.0 – PowerDNS recursor – google.com DNS request information

As you can see, the requested domain was displayed, which meant that I could move ahead to prepare an attack.  

Testing the Vulnerability

First, I assumed that the proper configuration was made to the PowerDNS testing instance. For more information about service configuration you can refer to the following URL: https://doc.powerdns.com/recursor/http-api/.

Next, I prepared the attack scenario to test and confirm the suspected vulnerability. I used two machines, one acting as an “attacker” and the other as a “server” (192.168.0.151) and “victim”, which would be a user with a valid password who should be able to gain access to the web interface of the Recursor.The attacker, on the other hand, would be in charge of executing the DNS request containing the XSS payload.

1. On the Server Machine, I made sure that both services (DNS and Webserver) were running on the machine.

Figure 1.1 – PowerDNS Recursor DNS & webserver running properly

2. The victim user then opened the Web interface by browsing: http://192.168.0.151:8082/ and provided his/her password. So far, the display only showed the google.com request generated in the previous test (Refer to Figure 1.0).
3. On the Attacker’s Machine I then created a DNS (A – record type) request using a regular XSS injection payload and then directed it to the PowerDNS server on the Server machine (192.168.0.151) by using the dig tool as follows: 

As can be seen in the following picture, there was no sending the DNS request.

Figure 1.2 – Sending the XSS payload to the DNS server

4. Upon returning to the Victim’s Browser there was an alert window being constantly displayed that confirmed the vulnerability.

Figure 1.3 – JavaScript alert window displayed on screen

Vulnerability Analysis – Dynamic

In order to identify what the calling component is, I used a Proxy tool that provides information about the called resource (jsonstat) and its related parameters. This information is useful for mapping the findings discovered in this phase, as well as for comparison when performing other activities such as source code analysis.

Figure 1.4 – GET request generated by the web page

The response clearly showed that the JSON object also included the XSS payload generated from the attacker machine.

Figure 1.5 – JSON Response containing the XSS payload

Vulnerability Analysis – Static

The main component affected by this vulnerability is a file named “local.js”. This file, among other tasks, is in charge of handling parameters (such as the api-key password) as well as displaying data (the data coming from DNS queries) to the web interface.

All of the code impacted by this vulnerability resides inside the “updateRingBuffers()” function.

By taking a quick look at the vulnerable code, I was able to see in line #69 that it iterates through all the data contained in the received JSON object (Figure 1.5). This is then handled by the line #{78,79,80,81}, and finally on line #82 it proceeds with the direct display of data on the screen.

Figure 1.6 – JavaScript showing vulnerable code

To find detailed information for *all* the code fixes applied to the local.js file, a patch file was generated by PowerDNS and can be viewed at the following URL: https://downloads.powerdns.com/patches/2017-05/CVE-2017-15092-4.0.6.patch

Solution

While PowerDNS released a patch on Nov. 27, 2017, their preferred recommendation is for users to upgrade to a non-vulnerable version of the software package.

FortiGuard Labs also immediately created and released the following FortiGate IPS signature which covers this specific vulnerability:

PowerDNS.Recursor.Script.Injection

We would like to thank PowerDNS Security Team for their cooperation during the entire responsible vulnerability disclosure process.

Sign up for our weekly FortiGuard Labs intel briefs or to be a part of our open beta of Fortinet’s FortiGuard Threat Intelligence Service.