 Uh so with that uh Feng Xiao. Good bye. Hi everyone thanks for coming. I'm Feng Xiao. Uh zero year Ph.D. student at Pennsylvania State University. And they are supposed to be another speaker but he can't come due to some visa problems. So I just put his picture here and my stand. So we can together to give the presentation to you all. Thank you. Alright so today we are going to talk about the new attack. The attack is about uh with this attack a weak adversary is able to hack the brain of the software defined networks. The SDN controller. Well here is the difference between the legacy networks and the software defined networks. Uh the legacy network is always vendor dependent. It means the network's devices always work independently with predefined functions and we cannot change it anymore. But in SDN the whole network is treated as two planes. The control plane, the upper layer and the data plane. So uh all network functions are now being placed into the brain of the network, the controller and the host and switch. This forwarding device are now placed into the data plane. Alright. So this is the difference between the two networks. So and this new architecture now is widely deployed in production environments with growing communities. On the one hand the open source organizations like Linux foundations are supporting a large number of SDN projects like the Open Daylight, Floodlight, Honors and companies like Huawei, Cisco also release their commercial products uh uh and their applications. And on the other hand the growing community accelerates the replacement of the network infrastructure. For example the world leading web scale providers such as Google, Microsoft, Deploying SDN in their data centers. So this is how SDN are used today. So when some people are using it, weird people are considered to hack it. The attack and the when the attacker can successfully break into a software defined network just like we connect to the Wi-Fi here if it is a software defined network architecture. So uh he will probably talk it at the controller cause it is the brain of the network. In this talk we concluded three categories of common attack objectives for attacks on the control planes. The design of service, data leakage and network manipulations. And in these tables some objectives have been achieved by previous researchers and some are not. And we discovered that these existing attacks for example just like the topology poison attacks are all focused on the service logic of controller. Which means uh these attacks for example the topology attack attack. He will attack the topology discover service in the controller to report face to to report force links and let let the controller make run decisions. So uh to discover these vulnerabilities you should be a hacker and an SDN expert. You should know the details of the SDN protocol interactions, the relationship among the service logic. But I think most of us are not SDN expert and we even not so familiar with SDN. But it is widely used so how? Um so I'm consider if whether I can find a method to hack the software defined network without learning so much about SDN. And my attack should be powerful. In the best case it it should achieve all the object attack objectives in this table all of them. No matter it is a existing one or a new one. So how do you hack the SDN like a hacker? Well the controllers are software systems and we both know that the software systems are inherently vulnerable. So it is possible that the controller components contains our vulnerabilities. This is cool. Of course we are hackers and we know how to find these code vulnerabilities, right? However the data plane and the control plane as I mentioned, they are decoupled. Which means they only communicate with each other with predefined protocol interactions. So these architecture make us hard to exploit these code vulnerabilities from the data plane where we are always in. So in this talk we introduce the custom attack which breaks the border built by the decoupled planes. Uh unlike previous attacks that focus on the attacking the controller service logic, custom attack can be used to attack all kinds of code vulnerabilities in the controller. So how to do it? So let's see how to conquer the difficulty built by the decoupled two planes. The SDN protocols provide some fields to let the switch and network device to custom themselves. Usually the customer fields is subscribed by a specific control specific controller components. Uh for example if a switch um a switch may send a fault notification message to the control plane. And this message will be first collected by a service. We can call it a collecting service maybe. And the service will send the message to the subscriber. Maybe a network monitor component. So this is how the customer field works. So I'm sorry I'm like my hands are a little bit tired so maybe Jianwei I will put you on the table. Alright. Let's move on. So this is a semantic gap built by the customer field. Since the customer field can be totally controlled by the control by the data plane um by the hacker. So any improper treatment may break the security border of the decoupled control plane and the data plane. Let's revisit the notification example. The monitor components does know how to parse the notification message. However the collecting service who collected first then does not. So the collecting service may store the message in the database without any security considerations. If a hacker inject a malicious cycle into the customer field the database will endanger. And this is the start of customer attack. And this is only the start. Alright. And with the customer attack we can exploit serious vulnerabilities in SDN controller to bring several advanced objectives. For example we can issue obituary SDN commands by calling the exposed network management API. Or we can read some confidential data via a cycle injection or other things. And this is the threat model of the customer attack. First uh the hackers don't have to directly access the network of the controller with which is sometimes separated from the data plane the network devices. And he can he will not need to access any obligations in the controllers. Also the hacker don't need to hack into the encrypt protocol channels between the control planes and the data planes. What the hacker needs is to only to perform legitimate protocol interactions with the control plane. So a malicious host or switch is enough. Just like we can use a mobile phone you know. Um however after attacking a vulnerable components handling the malicious customer field we can only introduce limited effect to the network. There are several reasons. First every single component in the controller runs in separate context. For example just like uh independent threat. So the failure of a single component will not affect the availability of others. And second the control the critical components are usually specially protect. As a result is it is difficult to abuse these important ones if we cannot attack them directly. Attack them with these customer fields. So as a result if we want to do something big. Want we need a more complex attack. A multi-stage exploitation to control more resources in the controller. This is the workflow. The lower part is the data plane. Where the network hosts and switches. Normally they cannot directly access the controller because the two networks are always separated. But they will always be able to interact with the controller with using the SDM protocols like the open flow or other things. So uh we need several stages. The first stage is the toe hole stage. This is where we attack the components with customer field. In this step we will inject our craft payload into the customer field and send them to the control plane via legitimate protocol interactions. After the first exploitations we can now control a small number of, we can only control a small number of ASAT in the component. To harvest more control plane ASAT we need a harvest stage. We will need to exploit more vulnerabilities in other components with previous controlled ASAT. For example we can, we may able to launch HTTP request in the first stage. So in the second stage we can leverage this ASAT to do more things. We may access the REST API to issue some commands. So after we controlling a large number of ASAT we try to chain them together to achieve our advanced attack code. And as you can see, instead of merely attacking the components that handle the customer fields, with this attack model we can now able to exploit all kinds of vulnerabilities to hack more components. Okay, now it's time for us to hack something real. First I will show you a radio demo. In this demo we attack an open source controller. It is a popular, maybe the most popular one, the honors. And we, the attack effect is we get a remote show from the controller. Okay, and the honors controller is on a remote machine, the 111. And our compromised switch is this machine, the 108. So, and this is the web component of the honors. We can see that there's no devices in the controller yet. Okay. And we can load our framework to attack the honors controllers and get a system show from the controllers. This is our devices connected. Well, as you can see, we successfully get the system show. Yes. So, this is a exploit chain with multi-stage exploitation that works. So how it actually works? Next, I will give you more details about the DRCE chain. As showing the picture, our target is the get diagnostic function, which read and execute a script from the file system. So, to abuse this function, we need to control two assets, to harvest two assets. The first is the script itself. To execute arbitrary commands, we need to inject payloads into the script. However, controlling the script is not enough. We also need to access the REST API that calls the diagnostic function. As I have mentioned, important components are usually specially protected. So, the REST API is protected by a basic authentication. We need an authentication token for this REST API. Let's check out what asset we can actually control in our first stage. Well, we found access in the web components as you can see. This vulnerability can be explored by a customer field. So now, we can control the assets that expose to the XSS, such as some network configurations. However, we cannot still directly attack our target function. So, let's move on the second stage, the harvest stage. First, let's try to handle the basic authentication issues. We found that the authentication token is stored as plain text at a config file. So, as long as we can control and read this file, we can get the token. This means that we need to find a new vulnerability that can read some contents. After several days' hard work, we find our first zero days in on us. It's an XSE. It can be explored by a customer field that we control. As a result, we can read the token to solve the OAS problem. Now, we can try to control the script asset with the fifth zero day we found in on us. It is a past traversal bug in the on zip function. This function is to handle the zip files uploaded from the web component. Remember that in the first stage, we discover access vulnerability in the web component. Now, we can leverage this access to upload a craft zip file and then overwrite arbitrary files with any content we want. So, finally, we control the script. This is the complete attack graph for the exploit chamber. We use five previously unknown vulnerabilities in three different stages to construct this remote command execution chamber. I'm sorry. So, how about the impact of the customer field? We analyzed five popular SDN controllers and they are fifty four applications. In total, we identify 18 vulnerabilities and construct 24 exploit chains. And all these exploit chains are involved in two or three stages. This is the impact of these exploit chains. We, all these exploit chains we construct can come introduce a serious attack effect to the controller. And this table shows all the zero day we found. We can, as we can see from the last column, every vulnerability can be used to introduce the more than one attack effect. And we found that others has the largest number of vulnerabilities. And I think this is because others is very easy to use. We can install any components we want with a simple click. By contrast, hacking the open day light is very difficult. To install or debug a component, we need to spend the whole afternoon. And usually we find nothing. So, we can only find three bugs in the open day light. So, maybe making your project hard to use can be a great defense. Yes, that's, that's what I found, important findings in our research. Okay, that's all. Thanks for listening. Okay, I forgot him.