We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Hacking the Brain: Customize Evil Protocol to Pwn an SDN Controller

00:00

Formale Metadaten

Titel
Hacking the Brain: Customize Evil Protocol to Pwn an SDN Controller
Serientitel
Anzahl der Teile
322
Autor
Lizenz
CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Software-Defined Networking (SDN) is now widely deployed in production environments with an ever-growing community. Though SDN's software-based architecture enables network programmability, it also introduces dangerous code vulnerabilities into SDN controllers. However, the decoupled SDN control plane and data plane only communicate with each other with pre-defined protocol interactions, which largely increases the difficulty of exploiting such security weaknesses from the data plane. In this talk, we extend the attack surface and introduce Custom Attack, a novel attack against SDN controllers that leverages legitimate SDN protocol messages (i.e., the custom protocol field) to facilitate Java code vulnerability exploitation. Our research shows that it was possible for a weak adversary to execute arbitrary command or manipulate data in the SDN controller without accessing the SDN controller or any applications, but only controlling a host or a switch. To the best of our knowledge, Custom Attack is the first attack that can remotely compromise SDN software stack to simultaneously cause multiple kinds of attack effects in SDN controllers. Till now we have tested 5 most popular SDN controllers and their applications and found all of them are vulnerable to Custom Attack in some degree. 14 serious vulnerabilities are discovered, all of which can be exploited remotely to launch advanced attacks against controllers (e.g., executing arbitrary commands, exfiltrating confidential files, crashing SDN service, etc.). This presentation will include: an overview of SDN security research and practices. a new attack methodology for SDN that is capable of compromising the entire network. our research process that leads to these discoveries, including technical specifics of exploits. showcases of interesting Custom Attack chains in real-world SDN projects.
HackerProtokoll <Datenverarbeitungssystem>GamecontrollerWort <Informatik>Coxeter-Gruppet-TestDatennetzSoftware
Funktion <Mathematik>Architektur <Informatik>ICC-GruppeOpen SourceGamecontrollerUnternehmensarchitekturRechnernetzDienst <Informatik>SchlussregelKonfigurationsraumInformationElement <Gruppentheorie>EbeneNetzwerktopologieAggregatzustandVerschlingungDatennetzApp <Programm>SoftwareComputerarchitekturExpertensystemMathematische LogikEntscheidungstheorieDatennetzNetzwerktopologieSelbst organisierendes SystemFunktionalZahlenbereichObjekt <Kategorie>DifferenteDienst <Informatik>Kategorie <Mathematik>FokalpunktProgrammierumgebungKartesische KoordinatenProtokoll <Datenverarbeitungssystem>Produkt <Mathematik>Physikalischer EffektService providerProjektive EbeneOpen SourceBenutzerbeteiligungHackerÜbertragungsfunktionZentrische StreckungOffene MengeNatürliche ZahlGruppenoperationQuick-SortEbeneUnrundheitAutomatische HandlungsplanungWort <Informatik>ForcingVerkehrsinformationSummierbarkeitTabelleGoogolMathematikHypermediaBitrateVerschlingungComputeranimation
SoftwareDatennetzEbeneHackerGamecontrollerAuswahlaxiomAutomatische HandlungsplanungSpeicherabzugWasserdampftafelComputerarchitekturPhysikalisches SystemEbeneHackerRegelungMathematische LogikInteraktives FernsehenKomponente <Software>SoftwareFokalpunktDienst <Informatik>Protokoll <Datenverarbeitungssystem>CodeSoftwareschwachstelle
GamecontrollerDatenfeldProtokoll <Datenverarbeitungssystem>EbeneHackerKomponente <Software>App <Programm>Dienst <Informatik>SoftwareKomponente <Software>RuhmasseDienst <Informatik>Protokoll <Datenverarbeitungssystem>Automatische HandlungsplanungDatenfeldMessage-PassingUmwandlungsenthalpie
Dienst <Informatik>Funktion <Mathematik>DatennetzGraphische BenutzeroberflächeDatenmodellHackerGamecontrollerRechnernetzFormation <Mathematik>TLSKreisflächeEbeneSoftwareChiffrierungDatenbankAutomatische HandlungsplanungDienst <Informatik>HackerKomponente <Software>Metropolitan area networkMagnetbandlaufwerkDatenfeldDemoszene <Programmierung>ComputersicherheitRuhmasseProtokoll <Datenverarbeitungssystem>Interaktives FernsehenDreiecksfreier GraphNetzwerkverwaltungMessage-PassingInjektivitätRegelungKartesische KoordinatenSoftwareschwachstelleTabelleObjekt <Kategorie>Endliche ModelltheorieExploit
GamecontrollerKontextbezogenes SystemDatenfeldKomponente <Software>SoundverarbeitungKontextbezogenes SystemDatenfeldKomponente <Software>SoftwareEinsUnrundheitGrenzschichtablösungTeilbarkeitResultanteExploit
GamecontrollerMultiplikationMAPApp <Programm>DatenfeldRechnernetzSLAM-VerfahrenData MiningDatenfeldProtokoll <Datenverarbeitungssystem>DatennetzSoftwareschwachstelleAutomatische HandlungsplanungREST <Informatik>Open SourceKomponente <Software>Reelle ZahlZahlenbereichMereologieInteraktives FernsehenSoftwareWurm <Informatik>ExploitSoundverarbeitungSharewareMultiplikationsoperatorMAPWurzel <Mathematik>Virtuelle MaschineMinkowski-MetrikSchnittmengeOrdnung <Mathematik>Produkt <Mathematik>Endliche ModelltheorieDiagrammFlussdiagramm
Smith-DiagrammKomponente <Software>BenutzerbeteiligungBestimmtheitsmaßVirtuelle MaschineComputeranimation
Virtuelle MaschineWurm <Informatik>App <Programm>RegelungFramework <Informatik>Physikalisches SystemXMLJSON
Familie <Mathematik>VerschlingungSkriptspracheNabel <Mathematik>FehlermeldungVererbungshierarchieWurm <Informatik>App <Programm>DateisystemOpen SourceLoopExploitMarkov-ProzessMAPFunktionalProgramm/QuellcodeJSON
Reelle ZahlMarkov-ProzessSkriptspracheElektronische PublikationWurm <Informatik>FunktionalDateiverwaltungXML
Reelle ZahlSkriptspracheSoftwareschwachstelleKomponente <Software>KonfigurationsraumPolygonzugFunktionalAutorisierungNP-hartes ProblemElektronische PublikationDatenfeldBenutzerbeteiligungGrenzschichtablösungToken-RingMAPSoftwareREST <Informatik>AuthentifikationGraphVollständigkeitProgrammfehlerInhalt <Mathematik>IndexberechnungBenutzerfreundlichkeitRemote AccessAutomatische HandlungsplanungNeuroinformatikInformationsspeicherungResultanteForcingOrdnung <Mathematik>Disjunktion <Logik>
LeistungsbewertungProdukt <Mathematik>Funktion <Mathematik>SystemidentifikationSystemaufrufKette <Mathematik>Protokoll <Datenverarbeitungssystem>Open SourceSoftwaretestAggregatzustandKartesische KoordinatenExplosion <Stochastik>MAPRegelungTotal <Mathematik>Kette <Mathematik>Computeranimation
AnalysisPhysikalisches SystemNabel <Mathematik>SystemzusammenbruchDienst <Informatik>BenutzerprofilProjektive EbeneSoftwareschwachstelleKomponente <Software>ZahlenbereichTabelleSoundverarbeitungSommerzeitKette <Mathematik>ProgrammfehlerOffene MengeSystemaufrufKontrast <Statistik>ComputeranimationTabelle
E-MailHomepageTwitter <Softwareplattform>
Transkript: Englisch(automatisch erzeugt)
So with that, Feng Shao. Hi everyone, thanks for coming. I'm Feng Shao, zero year PhD student at the Pennsylvania State University. And there's 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 a new attack. The attack is about, 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. 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 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,
Onners, and companies like Huawei, Cisco also release their commercial products 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, we people are considered to hack it.
The, the attack, and 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 he will probably target 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 denying of service, data leakage, and network manipulations. And in these tables, some objectives have been achieved by previous researchers, and some, some are not.
And we discovered that these existing attacks, for example, just like the topology poison attacks, our focus, focus on the service logic of controller, which means 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 wrong 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 amongst 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 to 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, this 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. 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 custom field is subscribed by a specific controller components. For example, if 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 custom field works. So, I'm sorry, my hands are a little bit tired,
so maybe Jianwei, I will put you on the table. All right, let's move on. So, there is a semantic gap built by the custom field. Since the custom field can be totally controlled by the control, by the data plane, by the hacker,
so any proper 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 it first, does not. So, the collecting service may store the message in the database without any security considerations. If a hacker injects a malicious cycle into the custom field, the database will endanger, and this is the start of custom attack,
and this is only the start. All right, and with the custom attack, we can exploit serious vulnerabilities in SDN controller to bring several advanced objectives. For example, we can issue arbitrary SDN commands
by calling the exposed network management API, or we can read some confidential data via cycle injection or other things. And this is the threat model of the custom attack. First, the hackers don't have to directly access the network of the controller,
which is sometimes separated from the data plane, the network devices, and he will not need to access any applications 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. However, after attacking a vulnerable component,
handling the malicious customer failed, 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 an independent threat.
So, the failure of a single component will not affect the availabilities of others. And second, the critical components are usually specially protected. As a result, it is difficult to abusing 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, 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. 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 using the SDM protocols like the OpenFlow or other things.
So, we need several stages. The first stage is the Toho 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 only control a small number of ASETs in the component. To harvest more control plane ASETs, we need a harvest stage.
We will need to exploit more vulnerabilities in other components with previous controlled ASET. For example, we may be able to launch HTTP request in the first stage. So, in the second stage, we can leverage this ASET to do more things. We may access the REST API to issue some commands.
So, after we controlling a large number of ASET, we try to chain them together to achieve our advanced attack goal. And as you can see, instead of merely attacking the components
that handling 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 a open source controller.
It is maybe the most popular one, the honors. And the attack effect is we get a remote show from the controller. Okay, and the honors controller is on a remote machine, the one, one, one. And our compromise switch is this machine, the 108.
So, and this is the web component of the honors. We can see that there is 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. Now, this is our devices connected. Well, as you can see, we successfully get the system show. Yes, so this is a exploit chain
with multistage exploitation that works. So, how it actually works? Last, next, I will give you more details about the DRC chain. As shown in 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 basic authentication.
We need authentication token for this rest API. Let's check out what asset we can actually control in our first stage. Well, we found access as in the web components, as you can see. This vulnerability can be explored by a customer field.
So, now, we can control the access that expose to the accesses, 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 is our access E. It can be explored by a customer field that we control. As a result, we can read the token to solve the auth problem.
Now, we can try to control the script asset with the fifth zero day we found in on us. It is a path traversal bug in the unzip function. This function is to handle the zip files uploaded from the web component. Remember that in the first stage, we discover access as vulnerability in the web component.
Now, we can leverage this accesses 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 chain.
We use five previously unknown vulnerabilities in three different stages to construct this remote command execution chain. I'm sorry. So, how about the impact of the customer field?
We analyzed five popular SDN controllers and there are 54 applications. In total, we identify 18 vulnerabilities and construct 24 exploit chains. And all these exploit chains
involved in two or three stages. This is the impact of these exploit chains. We, all these exploit chains we construct can 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 more than one attack effect. And we found that On Earth has the largest number of vulnerabilities. And I think this is because On Earth is very easy to use.
We can install any components we want with a simple click. By contrast, hacking the open daylight is very difficult. To install or debug a component, we need to spend the whole afternoon and usually we found nothing. So we can only find three bugs in the open daylight.
So maybe making your project hard to use can be a great defense. Yes, that's what are important findings in our research. Okay, that's all. Thanks for listening.
Okay, I forgot him.