Cross-Site Scripting (XSS), HTML Injection, and CSRF are vulnerabilities associated with web applications. So what does it have to do with Software-Defined Networking (SDN)? Well, many SDN controllers have some sort of web UI which helps network admins manage the network. Earlier this year I decided to take a look at the security of the web UI on two controllers, which ended up yielding some interesting results . This article will look at vulnerabilities discovered in Floodlight and ONOS, and how they can be exploited using sdnpwn.  All vulnerabilities discussed in this article have been patched.

The Vulnerability

An SDN controller’s web UI will usually contain information about connected switches, network statistics, hosts, and sometimes more. Often the UI can be used to manage things like applications or security controls too. Figure 1 and 2 show the web UIs from Floodlight 1.2 and ONOS 1.9.0 respectively. The key thing shown in both of these images is that the UI shows detailed information about the connected switch, like the manufacturer description.

Figure 1: Floodlight Web UI

Figure 2: ONOS Web UI

This information is sent by the switch to the controller during the OpenFlow handshake. When a switch connects to a controller, the controller will send a number of STAT_REQUEST messages[1]. One of these messages will request information about the switch description. The switch description information includes manufacturer, hardware, and software descriptions, along with a serial number and a human readable datapath ID. The entry in the OpenFlow specification for this message is as follows:

The descriptions sent in this message are strings, and these strings end up being displayed on the web UI. This information is not expected to change, or to be user defined. Both Floodlight and ONOS trusted this switch input and displayed these strings in the web UI without any sanitization.

Delivering an Exploit

The sdnpwn switch module will connect to a controller and maintain that connection. This module will take a configuration file as a parameter which specifies the switch information to send to the controller.

The above switch configuration can be used by saving it to a file (e.g. ‘~/sdnpwn/confs/of-switch.conf’) and running the sdnpwn switch like so:

By modifying the descriptions the vulnerability can be exploited.  On a vulnerable controller, changing the manufacturer description to “<h1 color=red>HTML Injection</h1>” and connecting the switch will result in “HTML Injection” being displayed in big red letters. Both Floodlight and ONOS were vulnerable to simple HTML Injection, but XSS is the real goal here.


Floodlight’s web UI is built using jQuery and standard vanilla JS. This made deploying an XSS exploit pretty straight forward. Setting the manufacturer description in the sdnpwn switch config file to the following is enough to demonstrate this:

There is much cooler exploit to be found here though. Floodlight allows the firewall to be switched on and off from the web UI. When a button is pressed, a call is made to Floodlight’s REST API to switch the firewall state to on or off. We can build an XSS exploit to make use of jQuery’s Ajax functionality and make a REST API call to disable the firewall! Using the following string as the manufacturer description will work:

The above exploit is available in one of sdnpwn’s pre-made switch configuration files. Even if basic HTTP authentication is set up, the REST API call will be made by the web UI user on our behalf, so they’ll already be authenticated. The following videos demonstrations this on Floodlight versions 1.1 and 1.2:


The ONOS versions vulnerable to this attack were 1.8.0 to 1.10.0. The web UI for these versions is built using AngulaJS, which made exploiting XSS a little bit trickier. AngularJS uses “expression sandboxing”, which basically means that a traditional XSS payload doesn’t really work. However, it’s still possible to perform XSS by exploiting a vulnerability in AngujarJS itself [2]. Different versions of AngularJS will generally have different vulnerabilities associated with escaping the expression sandbox. Some sites, such as [3], are very useful when trying to build an XSS exploit against an AngularJS webapp. ONOS version 1.9.0 uses AngularJS version 1.3.5. This particular version had a few exploits associated with it. One such vulnerability is related to the ‘usemap’ attribute of the img tag not being blacklisted. Now, this exploit does require the user to click on the img element to actually trigger the XSS, but this clicking can almost be guaranteed by simply making the size of the img element the size of the entire web page. A user who tried to click anything on the page would then trigger the XSS payload. The following exploit is available in a pre-made switch configuration file for the sdnpwn of-switch module:

<img style=’position:fixed;padding:0;margin:0;top:0;left:0;width:100%;height:100%;’ src=#foo usemap=#foo width=100%/><map name=’foo’><area href=\”javascript:alert(‘Clickjacking used to execute XSS’);\” shape=default></area>

The following video demonstrates the above exploit in action. A feature in ONOS, which makes the impact of this vulnerability worse, is that switch details are persistent. As presented in the video, the exploit works as expected, even after the switch has disconnected.

Showing an alert dialogue proves that the vulnerability exists and that it can be exploited. But, as with Floodlight, we want to show that this is actually a real problem that goes further than just having an alert box show up.

One method to use the exploit further is to use it to activate applications.  This can be done with CSRF rather than XSS. A simple way to do this is to include an iframe in the “manufacturer’s description” part of the switch config, and having the iframe src set to a HTML page on the attacker’s machine. On this HTML page is a form with the action set to post to a URL for activating a certain application. The form can be submitted automatically using JavaScript on the HTML page. The following video demonstrates this:

Another PoC was put together to use the vulnerability to perform a simple (but believable) Phishing attack, and using the information gained to upload an application and get a reverse shell on the controller. Basically, the process of this attack is to display a clone of the ONOS login page in an iframe after the switch has been clicked on.When an ONOS web UI session times out the login screen will be shown after the user tries to navigate to another page, so the display of the login page isn’t really unexpected behaviour. Once the user submits their credentials, they are redirected back to the actual web UI while their credentials are used to upload an application via the REST API. This application then provides a reverse shell back to the attacker. This attack is presented in the following video:

This particular vulnerability has CVE-2017-13762 associated with it. It seems that some researchers from Fraunhofer AISEC in Germany were actually doing similar research around the same time I was. CVE-2017-1000078, which refers to XSS in ONOS via device information being added through the REST API, popped up around the time I was allocated my CVE ID. Both CVE ID refer to vulnerabilities with the same outcome, but different attack vectors.

Mitigation and Testing Other Controllers

The main reason these XSS vulnerabilities existed was due to the input from the switch configuration being trusted.  Moreover, the web UI on both Floodlight and ONOS had no sanitation for data being displayed. While sanitizing at the web UI does solve the problem to an extent, outside applications that receive the switch data through the REST API may still be vulnerable. For these reasons I would recommend that some sanitation be performed on any data coming into the controller from an external device.

Testing other controller’s for HTML Injection and XSS can be done using the sdnpwn of-switch module and the “xss_test_switch.conf” pre-made configuration file. This will test for basic XSS using script elements and alert dialogues.  If HTML Injection is possible but XSS is not, it’s worth taking a closer look at the source code for the web UI to see if AngularJS or something similar is used. Sometimes an extra step might be required to get a working exploit.





When AppSec Meets NetSec: Attacking the SDN Controller Web UI
Tagged on: