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

IOActive: Breaking WingOS

00:00

Formal Metadata

Title
IOActive: Breaking WingOS
Alternative Title
WingOS: How to Own Millions of Devices
Title of Series
Number of Parts
322
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Extreme network's embedded WingOS (Originally created by Motorola) is an operating system used in several wireless devices such as access points and controllers. This OS is being used in Motorola devices, Zebra devices and Extreme network's devices. This research started focusing in an access point widely used in many Aircrafts by several worldwide airlines but ended up in something bigger in terms of devices affected as this embedded operating system is not only used in AP's for Aircrafts but also in Healthcare, Government, Transportation, Smart cities, small to big enterprises... and more. Based on public information, we will see how vulnerable devices are actively used (outdoors) in big cities around the world. But also in Universities, Hotels,Casinos, Big companies, Mines, Hospitals and provides the Wi-Fi access for places such as the New york City Subway. In this presentation we will show with technical details how several critical vulnerabilities were found in this embedded OS. First we will introduce some internals and details about the OS and then we will show the techniques used to reverse engineering the mipsN32 ABI code for the Cavium Octeon processor. It will be discussed how some code was emulated to detect how a dynamic password is generated with a cryptographic algorithm for a root shell backdoor. Besides, it will be shown how some protocols used by some services were reverse engineered to find unauthenticated heap and stack overflow vulnerabilities that could be exploitable trough Wireless or Ethernet connection. This OS also uses a proprietary layer 2/3 protocol called MiNT. This protocol is used for communication between WingOS devices through VLAN or IP. This protocol was also reverse engineered and remote heap/stack overflow vulnerabilities were found on services using this protocol and will be shown. As a live demonstration, 2 devices will be used to exploit a remote stack overflow chaining several vulnerabilities as the attacker could do inside an aircraft (or other scenarios) through the Wi-Fi. As there are not public shellcodes for mipsN32 ABI, the particularities of creating a Shellcode for mipsN32 ABI will be also discussed.
SurfaceKernel (computing)ArchitectureGame controllerWireless LANInformationCategory of beingExtreme programmingComputer networkWeb 2.0Vulnerability (computing)User interfaceDemo (music)Kernel (computing)Computer architectureCategory of beingLinear programmingDevice driverSocket-SchnittstelleFamilyInformationInteractive televisionGame controllerSurfacePoint (geometry)Wireless LANComputer networkPhysical systemGoodness of fitInterface (computing)WebsiteStreaming mediaWindowLevel (video gaming)Instance (computer science)Computer animation
Point (geometry)Extreme programmingComputer networkGame controllerPhysical systemType theoryDifferent (Kate Ryan album)Operator (mathematics)Combinational logicOperating systemArithmetic meanPhysical systemElectronic mailing listGame controllerPoint (geometry)CASE <Informatik>Computer networkInstance (computer science)Extreme programmingInformationComputer animation
Extreme programmingComputer networkLocal area networkZoom lensBoom (sailing)Point (geometry)Game controllerEnterprise architecturePhysical systemElectronic program guideExtreme programmingComputer networkMereologySerial portPoint (geometry)Operator (mathematics)Game controllerOperating systemComputer animation
Product (business)Web serviceDifferent (Kate Ryan album)Regulator genePoint (geometry)Physical systemProjective planeCuboidGame controllerWave packet
Point (geometry)InternetworkingInstance (computer science)Endliche ModelltheorieType theoryCuboidComputer networkGame controllerEngineering drawing
PlastikkarteBuildingEnterprise architectureComputer networkWebsiteObservational studyWeb serviceCASE <Informatik>Wireless LANComputer networkObservational studyDifferent (Kate Ryan album)CASE <Informatik>Enterprise architecturePlastikkarteWebsiteBuildingInternetworkingUniverse (mathematics)Point (geometry)Data miningGame controllerTelecommunicationWorkstation <Musikinstrument>Instance (computer science)Internet service providerNear-ringComputer animation
Web serviceWireless LANAverageCASE <Informatik>Observational studyComputer networkSurfaceUDP <Protokoll>PasswordCASE <Informatik>Universe (mathematics)Observational studyMilitary baseVulnerability (computing)SatelliteConnected spacePoint (geometry)SurfaceEndliche ModelltheorieBitArithmetic meanDifferent (Kate Ryan album)Web serviceService (economics)FreezingComputer animation
SurfaceInformation securityMIDIInternetworkingInformationRegular graphSatelliteWindowPoint (geometry)ModemSystem callNoise (electronics)TelecommunicationInformation securityConnected spaceSurfaceEndliche Modelltheorie
SurfacePoint (geometry)Linker (computing)PasswordComputer networkBuildingPoint (geometry)Office suiteEndliche ModelltheorieComputer architectureSatelliteConnected spaceSurfaceVulnerability (computing)Demo (music)WindowServer (computing)BuildingComputer animation
RootGastropod shellProcess (computing)Vulnerability (computing)Backdoor (computing)EinheitswurzelOperating systemRootPasswordProcess (computing)Vulnerability (computing)Gastropod shellInterface (computing)Service (economics)EinheitswurzelPerspective (visual)Cellular automatonInternet forumBackdoor (computing)Web serviceInformationComputer animation
Gastropod shellBackdoor (computing)RootWordMoving averageAddress spacePasswordCellular automatonType theoryInformationMedical imagingForm (programming)WindowInternet forum
EmailRootGastropod shellBackdoor (computing)Cholesky-VerfahrenDefault (computer science)Identity managementRootLevel (video gaming)Gastropod shellString (computer science)Binary codePasswordReverse engineeringValidity (statistics)System callFunctional (mathematics)Cellular automatonBlock (periodic table)Computer fileDefault (computer science)Content (media)Computer animation
RootGastropod shellBackdoor (computing)EmulatorCodeLoop (music)BefehlsprozessorContent (media)Buffer solutionSoftware frameworkResultantCodeProcess (computing)Point (geometry)Order (biology)Operator (mathematics)Reverse engineeringFlow separationComputer fileLoop (music)EmulatorInstance (computer science)outputComputer architectureComputer animation
DDR SDRAMRootGastropod shellBackdoor (computing)CodeRippingUser interfaceAsynchronous Transfer ModeBlock (periodic table)ASCIIContent (media)Computer fileBuffer solutionResultantString (computer science)HexagonCodeOperator (mathematics)EmulatorLoop (music)Arithmetic meanSource code
Session Initiation ProtocolBackdoor (computing)RootGastropod shellEncryptionString (computer science)PasswordEncryptionPasswordCASE <Informatik>Content (media)Key (cryptography)System callLogic gateCoroutineHexagonFluid staticsLoop (music)Computer fileResultantOperator (mathematics)String (computer science)Computer animation
Backdoor (computing)Gastropod shellRootEncryptionFehlererkennungscodePasswordAddress spaceNumberCodeEncryptionResultantOperator (mathematics)CoroutineLoop (music)PasswordKey (cryptography)Computer animation
Gastropod shellBackdoor (computing)RootBlock (periodic table)PasswordDifferent (Kate Ryan album)EncryptionEmulatorAddress spaceResultantPasswordRootCodeCellular automatonCASE <Informatik>Multiplication signEncryptionProcess (computing)Web serviceDynamical systemComputer fileArithmetic meanType theoryKey (cryptography)Slide ruleComputer animation
Default (computer science)Module (mathematics)Information managementProcess (computing)Interface (computing)UDP <Protokoll>Host Identity ProtocolSession Initiation ProtocolDuality (mathematics)Link (knot theory)Maxima and minimaIP addressDefault (computer science)Service (economics)Module (mathematics)Buffer overflowInformation managementRootCellular automatonInstance (computer science)CASE <Informatik>Process (computing)Reverse engineeringCodeHexagonStack (abstract data type)Sound effectSystem callWeb serviceLengthCommunications protocolBuffer solutionFunctional (mathematics)Fiber bundleSource codeSocket-SchnittstelleMereologyClient (computing)Block (periodic table)Revision controlSource code
Buffer overflowWebsiteInformationNetwork socketRevision controlFirmwareGraphics processing unitMach's principleInclusion mapRevision controlInformationFirmwareClient (computing)WebsiteDataflowGame controllerLetterpress printingFunctional (mathematics)Electric generatorBuffer overflowComputer animation
Web serviceProcess (computing)Information managementNetwork socketMessage passingCrash (computing)Process (computing)NumberRing (mathematics)CodeWeb servicePhysical systemMultiplication signOperating systemScripting languageWater vaporRow (database)Video gameComputer animation
Time domainCommunications protocolNetwork socketAddress spaceKeyboard shortcutVulnerability (computing)Socket-SchnittstelleMultiplication signSet (mathematics)Instance (computer science)Service (economics)Domain nameLocal ringReverse engineering
InternetworkingInformationVirtual LANLevel (video gaming)Communications protocolKernel (computing)Client (computing)Network socketAddress spaceReverse engineeringComputer networkConnected spaceGame controllerWireless LANService (economics)World Wide Web ConsortiumOperating systemSocket-SchnittstelleArithmetic meanGame controllerConfiguration spaceClient (computing)Point (geometry)WindowCuboidAddress spaceDomain nameVulnerability (computing)Computer configurationFirmwareLevel (video gaming)Communications protocolKernel (computing)FamilyMultiplication signInformationReverse engineeringInternetworkingRootService (economics)Standard deviationCASE <Informatik>Process (computing)Instance (computer science)Network socketPortable communications deviceComputer networkComputer animation
Network socketClient (computing)Library (computing)AreaMessage passingSocket-SchnittstelleClient (computing)Computer fileSocket-SchnittstelleOperator (mathematics)Reverse engineeringAddress spaceBuffer solutionInterpreter (computing)Network socketOperating system
Game controllerConfiguration spaceDefault (computer science)Point (geometry)Link (knot theory)TelecommunicationInstance (computer science)Flow separationGame controllerExpert systemIP addressSet (mathematics)VirtualizationAuthenticationStandard deviationBlock (periodic table)Default (computer science)Computer networkSoftware maintenance
Game controllerWeb serviceCommunications protocolLink (knot theory)Arithmetic meanGraph (mathematics)Pattern languageService (economics)Binary codeCommunications protocolCASE <Informatik>OpcodeSoftware bugStatement (computer science)Socket-SchnittstelleProcess (computing)Functional (mathematics)Latent heatComputer animation
Process (computing)Statement (computer science)Singular value decompositionMemory managementFunctional (mathematics)Statement (computer science)Game controllerCASE <Informatik>Address spaceBuffer solutionElectronic mailing listHoaxSource codeDataflowKeyboard shortcutLogarithmHost Identity ProtocolComputer animation
Message passingNetwork socketStatement (computer science)HoaxCodeBuffer overflowElectronic mailing listMemory managementAddress spaceCommunications protocolBuffer solutionDataflowBinary file
Process (computing)Crash (computing)CodeDataflowOperating systemRevision controlKeyboard shortcutMemory managementCrash (computing)Buffer overflowBuffer solutionCASE <Informatik>Source codeHost Identity ProtocolStatement (computer science)Game controllerComputer animation
Inclusion mapStack (abstract data type)Memory managementData bufferVulnerability (computing)Exploit (computer security)Cache (computing)BefehlsprozessorComputer wormLinker (computing)Buffer solutionGame controllerStack (abstract data type)Memory managementDemo (music)Buffer overflowSource codeVulnerability (computing)Cellular automatonExploit (computer security)Cache (computing)Linear programmingProcess (computing)CodeSemiconductor memoryBefehlsprozessorAddress spaceMetadataCasting (performing arts)EllipseComputer wormOcean currentCircleCASE <Informatik>DataflowHost Identity ProtocolComputer animation
Exploit (computer security)Cache (computing)Function (mathematics)System callGastropod shellCache (computing)CodeComputer configurationFunctional (mathematics)CausalityCircleBlock (periodic table)Computer animation
Exploit (computer security)Control flowFunction (mathematics)Pointer (computer programming)Parameter (computer programming)Moment (mathematics)EmailCompilerData modelFunctional (mathematics)DataflowGastropod shellCodeLibrary (computing)CircleMachine codeFlow separationInternetworkingSystem callPhysical systemStandard deviationLinear programmingReverse engineeringSpeicheradresseDifferent (Kate Ryan album)32-bitNetwork socketCellular automatonDatabaseInstance (computer science)BitAkkumulator <Informatik>Computer animation
Exploit (computer security)Demo (music)Computer networkCodeLinear programmingGastropod shellMehrfachzugriffPoint (geometry)Shared memoryLaptopInternetworkingGraph (mathematics)Connected spaceAkkumulator <Informatik>Vulnerability (computing)DiagramProgram flowchart
Address spaceMemory managementScripting languageGastropod shellLink (knot theory)Akkumulator <Informatik>Vulnerability (computing)Buffer overflowCellular automatonMultitier architectureDifferent (Kate Ryan album)RootHoaxKeyboard shortcutSoftware testingDataflowRoutingHost Identity ProtocolPoint (geometry)Electronic mailing listBuffer solutionExpert systemSource codeComputer animation
Point (geometry)Arithmetic meanPatch (Unix)Computer iconHost Identity ProtocolComputer networkWireless LANLocal area networkGame controllerExtreme programmingProcess (computing)Communications protocolInformation managementDensity of statesStructural loadLink (knot theory)Patch (Unix)Computer networkCuboidInformationClient (computing)Vulnerability (computing)Shared memoryComputer animation
Operator (mathematics)Vulnerability (computing)Information securityOperating systemWindowComputer animation
Transcript: English(auto-generated)
Good morning, everyone. So, this is Joseph. He's got a rather interesting gear here, and it's going to work, too. I know that. With that, it's Joseph. Hi, guys. So, thank you for joining to this talk. I really hope that you guys will enjoy it.
So, what I'm going to talk about is this research on how I broke this Wing OS. What I'm going to do is to discuss about some interaction about this Wing OS thing. Then, we'll discuss some scenarios and attack surface that we have with this OS and the devices.
Then, I will describe with full technical details some critical vulnerabilities. And then, I'll try to make a demo with these two devices with an exploit that I did for trying to exploit one of the vulnerabilities.
And then, after that, we will discuss some conclusions. So, what the hell is this Wing OS? So, basically, it's an embedded Linux operating system with its own proprietary stuff in the kernel.
Like, they have their own proprietary drivers. They have their own proprietary socket address family and stuff like that. So, originally, it was created by Motorola, but now it's a property of Extreme Networks. We'll discuss about it in a couple of minutes. Then, the architecture is MIPS N32. At least, the devices that I've been working with during this research were MIPS N32.
And mainly, it's used for wireless access points and wireless controllers. And as far as I know, there is no public information or previous research on reported vulnerabilities about this OS.
As far as I know, at least. So, from Extreme Networks website, we can get some high-level details about this OS. Like, for instance, here it's saying that it's for WLAN architectures and it's designed to scale efficiently from the smallest networks to large geographically dispersed deployments and stuff like that.
So, from the website, you can get more or less an idea on high-level details of this OS. So, we have a web interface, a typical web interface where we can set a lot of stuff. I mean, the web interface is huge.
And it also has vulnerabilities, but I didn't want to focus this research about web vulnerabilities. So, we won't discuss web vulnerabilities during this talk. But also, we have the typical command line interface, similar to the Cisco IOS, where you have different types of commands and combinations of commands where you can set the device.
And this command line interface is restricted, meaning that from here you can't access to the operating system, the Linux operating system that is running in the background.
So, devices using this Win OS. So, I didn't get an official list of devices affected, but based on public information, for instance, from Extreme Networks website, we can see a list of Win access points and controllers that uses this operating system. But as this is not official, this list could be even bigger in the case of Extreme Networks.
But also, we have Motorola devices and Zebra devices, because as I said, Motorola created this OS, so they have also their devices with this OS. And then, Zebra bought this part of the business from Motorola, and that's why we also have Zebra devices with this OS.
And then, at the end, Extreme Networks bought this part of the business from Zebra. So, basically, that's why we have Motorola access points, Motorola controllers, Zebra devices, and Extreme Networks devices running this operating system.
And also, we got the Contron device. So, this particular one is important because all this research started because of this. Well, Contron is a company that makes embedded devices for different industries, such as the aircraft industry and the train industry and stuff like that.
So, one of my coworkers in IACTIV, Ruben Santa Marta, said, hey guys, here is an interesting target. This is an access point that is widely used in aircrafts by many airlines around the world. So, this could be an interesting target for our research period. And then, I thought, yeah, this might be fun, and yeah, it ended up being pretty fun.
So, basically, this is a box that has some special connectors to comply with the aircraft regulations, the aircraft industry regulations. Basically, inside, we got that Motorola AP7131 access point.
So, where we can find these devices? As we can see, for instance, in this picture from the internet, from an aircraft, they are actually installing that Motorola access point at the ceiling of the aircraft. So, as I was saying, it's widely used in aircrafts by many airlines around the world.
We got some other pictures from the internet where we can see the Contron box, where inside it's that particular Motorola access point. And, yeah, it appears that they are installing these access points at the ceiling of the aircraft. But I don't know if maybe in other types of aircrafts they are installing the access point in other places. I have no idea.
So, from the Extreme Networks website and some case studies that we can find on the internet, we can see that these devices are also used in other different scenarios and industries such as smart buildings, smart cities, healthcare, government,
obviously small and big enterprises networks in a lot of different scenarios. Let's see some examples quickly. This is, for instance, a Motorola case study where we can see that the AP7161 and the 9500 controller
are used in more than 200 subway stations in the New York City subway to provide Wi-Fi to the passengers. Then also we got container ports, global electronics manufacturers such as Isola in this case and different facilities, universities such as this one.
Also, even in mines, this case study from Zira explains how these devices are used in the Westmoreland coal company in mines. Saigon City in Vietnam where they have more than 1500 access points installed to provide Wi-Fi.
Casinos, resorts, Nanjing University in China another example, hospitals, MWR facilities, case study, even apparently military bases as we can see in this case study. So, as you can see in a lot of different scenarios and industries.
So, for the attack surface and the scenarios, I divided two and this is mainly because the aircraft scenario is a little bit different and it has some particularities. And the other scenario, it's basically the rest of the scenarios that we got. So, all of this stuff is focusing the remote preauthenticated vulnerabilities that I found and the vulnerabilities that we will discuss later.
So, first we have the attack surface of the ethnic cable, meaning like if the attacker has physical access to the access point, he can just connect the cable to the device, to any port or to an administrative port.
And then he could, if he can reach the vulnerable UDP service and main services, then technically the attacker could exploit the issues. Of course, in the case of the aircraft, this is less likely because if the access point is at the ceiling, I think that's unlikely.
But I don't know, still it's a possibility. But also these vulnerabilities are technically possible to exploit over the air through the Wi-Fi connection. And also in the aircraft scenario, we got another attack surface, which is pivoting from the satellite model to the access point from the ground.
Let me explain this a little bit. So, I don't know if you guys are familiar with my co-workers, Ru and Santa Marta research. He recently spoke about this in Black Hat, the last call for SATCOM security. So basically, he was able from the internet, just using a regular internet connection, nothing special,
to hack and compromise satellite models of aircraft that are actually flying on the air. So then based on that, we saw that based on some information that we saw on the internet, that the attacker should be able to reach from the satellite model the access point which is running the Wing OS.
So this could be another attack surface. And of course, I must say that the safety of the aircraft in these attacks and stuff for the Wing OS and everything, the safety of the aircraft is not at risk. It's only the communications.
So this is one of the architectures and this is the satellite model that Ruwen compromised. And this is the access point running the Wing OS and these are connected through the SMU server, so we are pretty sure that it should be possible to reach the access point from the satellite model
and exploit the Wing OS vulnerabilities. Then the other scenarios basically are the rest, like outdoor access points or indoor access points. So again, the other attack surface is, again, if the attacker has physical access to the access point, just connect the ethernet cable and that's it.
And this is more likely in outdoor access points but also possible in indoor access points if the attacker is inside of the office or the building or whatever. But again, through the Wi-Fi, it's also technically possible, as we will see in the demo, to exploit some of these issues. And also if the attacker is somehow inside the internal network and if the attacker has connectivity to some of these devices,
then obviously he could try to exploit the issues. So let's start with the vulnerabilities. The first one is not a really critical one but it was a really important one for the research because it's a hidden root cell kind of backdoor.
So when you get a root cell, the process of the research, it makes it easier, this process, the research. But it's a kind of privileged escalation vulnerability
because you need access to this command line interface to get that root cell. So from the attacker's perspective, yeah, if the attacker somehow has access to the command line interface, it's good, he can do a lot of stuff. But if the attacker gets a root cell, then we can say that the device is completely compromised. So here we can see in this picture, in some forums, some guys asking about this service star cell command
that gets you into the native operating system. But he says that Motorola may not disclose the required password to mer customers. So I was trying to find information about this star cell command.
So all I got was like forums like that, people asking about it, but that's all I got. Even if we read the Wingo S manual, we can see that yes, we have a star cell command, which provides cell access, but that's all you get. So when you execute this command, you get this last password used, password with this MAC address
and then this password prompt asking to the user to type the password. So one of you guys might think here like, okay, so it's telling me what is the last password used, so I'm going to try password in lowercase letters, but obviously it's not going to work here.
So then since we got access to the firmware image, then we are going to start to statically reverse engineer some binaries to find out how this works. So based on the strings, we can see here the last password used string. And then here it's going to call this validate map password function.
And depending on the return value, it's going to reach this basic block where it's going to get the root cell. So let's get inside this validate map password function. Then again, it's going to call this other one, get last map password function where it's going to open this file.
It is C2IMISS password file. And the content of this file is this particular string. And this is the default value in every Win OS, this string inside that file. Then after that, with the content of that file, it's going to execute these instructions in this loop.
So to play around with Unicorn, I emulated this code. I don't know if you guys know or are familiar with Unicorn, but it's an also framework that uses Chemo in the background and allows you to emulate several architectures. But of course, in order to emulate the code, you need some previous reverse engineering job or work.
For instance, here you need to know what register points to your input, the buffer where we have the contents of that file. And also you need to know the register that points to the buffer where we will have the result of the operations.
So I was using the Python API for Unicorn and it's pretty simple. So you can emulate the instructions and provide the register values and create your buffer. And inside that buffer, we have the content of that file. And then after the execution of emulation, we are printing out here the buffer where we have the result,
which is these bytes, the result. So if we look at it carefully, we can see that this was the string that we have inside the file. So when the code is reading its ASCII character, then we got its hex byte for its ASCII character.
And after that, this is the result that we got after those operations in that loop. So we can see that these bytes are these guys here. So basically it's meaning that this is hex. Then after that, it's going to call RC4 decryption routine.
It's going to try to decrypt the content of the file, I mean the hex bytes after those operations in the loop with this static key. Hi Sabina, how are you doing? Bye. Nice key. And yeah, so in this case, after the decryption, the result is going to be the password string in lowercase letter,
which makes sense because we were in the getLastPassword and that's why it was printing out here like last password use, password in lowercase letters. Then after that, the code is going to get the MAC address of the device. And then with the MAC address, it's going to execute these other instructions in this loop
and basically it's doing some operations with the MAC, like adding some numbers to each byte of the MAC. Like here, the first byte is adding zero, then the second byte is adding one, and then two, three, four, and so on.
And then after that, what it's going to do is call another RC4 decryption routine. So it's going to decrypt password, which is the result for the last RC4 decryption. But now it's with this key, the MAC address with those operations that we were talking about. And finally, after that, it's going to execute these other instructions, which I also emulated to play around with Unicorn.
But basically these instructions are making sure that the result is only lowercase letters. So here is the emulation as you can see in my device for my MAC address. This is the valid password, which is only lowercase letters.
And then you can finally access to the root cell. Then in the code we can see that after the password is granted, it's going to open again that file, the I miss password file, and then it's going to RC4 encrypt with the same key,
the Hi Sabina hardy doing key, the password that the user typed when the password was granted. Meaning that the next time you're going to execute the service start cell command, the password is going to be different. That's why I call this kind of dynamic password, because the next time it's going to be the same and you will have to do the whole thing to calculate the password.
So here you have the overall process in case you later want to check with the slides. And yeah, finally in the code also we can see that since we got access to the root cell, then creating this file, allow root in ETC, then you can make it persistent.
And then all the time that you execute the command, it's not going to ask for any password again. Okay, so now since now we have root cell, we can start to try to see more stuff about this OS.
For instance, to check what services are running by default. And for instance, we can see that there are several ports like this 3799 UDP port, which is listening over all the IP addresses. So in this case, it's the rim process, the radio interface module.
So we are going to see a remote pre-authenticated stack overflow of this service, but this particular one only affects older versions of the firmware, but I wanted to share with you guys this one because it seems that they tried to fix it, but they made another mistake as we will see shortly. But yeah, so now from here is the typical stuff from protocol reverse engineering.
So basically we trace the sockets and we know where they call this parsing the user's buffer. So in this case, we know that the buffer length is 1000 hex, which is pretty big.
And then just reading the code and following how the code is parsing the user's buffer, we can see that there is one particular memcpy where the source and the size are completely controlled by the user and the destination is a stack buffer. So it's a typical stack buffer overflow.
So we are here. Here's where we have in this red block the rugby from, and here's where we have the call to this function where inside we have that particular vulnerable memcpy. So what we need to do right now is the typical reverse engineering stuff,
like to find out how to get from here to there. Just reading the code and build your own Python client. To reach that particular memcpy. So this is one of the Python client to reach that stack overflow. As I said, this only affects all versions of the firmware,
but based on information that I got from the Contron website, the Contron devices that are using aircrafts, apparently some of them could be vulnerable, as I saw in the website that they were running all their versions of the firmware.
So apparently they tried to fix this stack overflow. So here in newer versions of the firmware. So we can see here that they are checking the size of the memcpy, which is user control, but if it's bigger than this value, then it's not going to reach that vulnerable memcpy.
Instead it's going to execute this Azure print function that is going to generate this crash num, and then it's going to kill the process. So this is a Python code to reach that. So you can kill the process, but the process will restart immediately.
But the problem here is that there is a watchdog in this system that checks if this process is alive, because this process apparently is critical for the operating system. So if you execute this Python script like two or three times in a row, then the watchdog is going to check that the ring process is not alive, and then the whole operating system is going to be reboot. That's why I call this like global denial of service.
Then let's move on to the main vulnerabilities. I mean, there are other UDP services with issues, but we don't have time to talk about them. So let's move on to the main issues. So when I was reverse engineering some of the binaries, then I realized that they were receiving data from some particular sockets.
So when tracing these sockets, I realized that they were using non-standard values, such for instance the 32x value for the domain value, and some references such as this one like local mint address. So I wanted to know what the hell was this mint thing.
So there's not much information on the internet about this mint thing, at least about how it works internally. Of course, obviously there are information about how to set the devices to work with mint and stuff like that. But yeah, basically it's a layer two, layer three proprietary protocol
originally also created by Motorola, and they have like two levels, level one for VLAN and level two for IP. So mint is used mainly to communicate devices between them. So for instance, here we have this access point communicating between them through level one mint, or this access point to this controller through level two mint,
or these two controllers through level two mint as well. So yeah, when you trace some of the processes as well, you can see some stuff like the socket address family, which is non-standard, AF mint, the port, and then the mint address, which is the four last bytes of the MAC address.
So yeah, they created their own proprietary socket address family in their kernel, the AF mint, and in my case, at least, using datagram sockets. So the goal here is to be able to create a client so we can communicate with other devices using mint.
So we have three options here. It's like the first one, reverse engineer their kernel and try to make your own client, and make it work in your Linux box, which is technically possible. Then another option could be to try to emulate the whole operating system on the kernel,
and then make your own mint client, which is also technically possible, but could be a pain in the ass. And then the quickest one, which is the one I took, because I didn't want to spend too much time working on that. So find a way to build a client using their kernel. So basically what I'm doing is using advice
as the attacker, and running my own mint client in the operating system. But again, this is not the only option. I mean, an attacker could use the option one or option two, and use its own mint client in its Linux box or whatever.
So attack scenarios using mint. So yeah, in my case, as I'm using advice as the attacker, then if the attacker connects its device to the network, I mean, physically with a cable or through the Wi-Fi, then if he's able to reach other access points or controllers that are using mint,
then he can exploit the vulnerability. And of course, other scenario could be that the attacker remotely compromised one device, and then since he has access to the root cell, then exploit the mint issues to other devices that are connected with.
And then yes, basically attack the mint services that are running in access points and controllers. Controllers are also interesting, because they are like kind of Windows domain controller, meaning that controllers can have like hundreds of access points connected. So if the attacker compromised one controller,
then he could compromise hundreds of access points, and not only with the vulnerabilities, but also controllers has the ability to change the configuration remotely of the access points, and also even update the firmware of the access points remotely.
So the way I created the mint client in the OS, so we have here in the OS modified Python interpreter, and they have also their own libraries, such as this one for sockets, and this allows us through Python to create AF mint sockets.
So they have some Python compiled files in the operating system, and then reverse engineering those compiled files. I saw how to create my own Python client to communicate through mint. So basically here is the mint address, which is in decimal, but it's the four last bytes of the MAC address of the target,
then the port, the buffer, and then you can create the AF mint socket, and then send data through mint to the target. So one important thing about mint is that we can expect to have mint where in the scenarios where we have several access points and controllers,
because as I said, mint is used to communicate communications between devices. But also I wanted to check if standalone access points can also use mint. So yes, technically, as I saw during my test and during the research, it's possible, as we can see here, the mint in a standalone access point
is enabled by default, because you can set a standalone access points as virtual controllers, for instance. So the attacker only needs to exploit these issues is to know the IP address of the target. I mean, there is no any kind of authentication,
so this is the target, the attacker's device, this Motorola black access point. So we only need to set controller host and the IP address, and then the mint link is established. But this is not the only way to establish a mint link. As far as I know, there are other ways.
For instance, also if you connect an access point in the network, then the other access points could detect in an automatic way this new access point and establish the mint link in an automatic way. And probably there are more ways, because I'm not an expert with this mint thing. So yeah, so after that, in the attacker's device,
we can see that with the show mint neighbors, we can see that the mint link is already established. So now we can communicate through mint. So now we just need to, we have to find bugs in mint services. So there are a lot of binaries and a lot of mint services receiving data from sockets.
So this example is from the HSD process. So this particular graph is one function, which is more or less big, receiving data from a mint port, one specific mint port. And we can see the typical pattern of this that looks like we got switch cases statements
that probably are switching through an opcode or something for the protocol. So one of the first issues, pretty straightforward, is again, pre-auth heap overflow, where the user has control of the size and the source, and the destination buffer is the heap.
But the problem that we have here is that to reach that particular MCBY, we got to go to the case here in the switch cases statement. This function is going to be executed, get session by MAC. And what is going to do this function is to check
if the MAC address that you have to send in your buffer, it's in a list of authenticated MAC addresses. If it's not there, then you won't reach that particular MCBY. So luckily, there is another case in the switch case statement where we can call this session alloc function, where we can add our fake MAC address
in that particular list. So first, we just need to execute this Python code where we will add this fake MAC address, 4141 4141, to that particular list. And then after that, since our fake MAC address is already there in that list,
then we can reach that MCBY, the heap overflow MCBY, and here you can see in our buffer, we are providing the fake MAC address, and the rest is the protocol stuff to reach the MCBY. And then here we have the crash of this MCBY,
this heap overflow, which since we don't have modern exploit mitigations, and the libc version is old in this operating system, it shouldn't be too complex to get code execution from this heap overflow. Then we got more heap overflows, like this one,
pretty much the same in another switch case statement, but basically it's exactly the same, the source user control, size user control, and the destination is a heap buffer. Now, this is the vulnerability that I will try to use in the demo. So it's on Stack Overflow through Mint as well.
So it's another MCBY where the destination buffer is in the stack buffer, obviously, and the size is also user control, but the size and the source comes from the heap buffer, and it's the heap buffer that we were discussing before with the heap overflow.
So the problem that we have here is that this is the MCBY for the Stack Overflow, so if we want to reach the return address in the stack, our buffer has to be big enough to reach that. So the problem as the source comes from the heap, then we'll have to also overflow the heap buffer and also overflow the next chunk
and the next chunk's metadata. And we could have problems with the libc sanity checks because if the sanity checks triggers here, then it could crash the process and then it could ruin our exploit.
But in this case, it's not going to be a problem because in between, there are no allocations from freeze, and so it won't crash, and we will be able to reach the Stack Overflow after the heap overflow. So for the exploit, as I said, we don't have modern exploit mitigations,
so we could think, okay, we just need to jump to our set code and that's it. But no, so if you guys are familiar with MIP's explanation, there's a well-known problem, it's the cache incurrence problem. So we got a MIP CPU with two different caches, the instruction cache and the data cache.
And normally our payload, so our cell code, it could be stored in the data cache. So the problem is that when we try to jump to our cell code, in the memory, if the cell code is still in the data cache and it's not flushed, then we could end up trying to execute another instruction that are in the memory.
So what we just need to do is to fill the data cache and one possibility is to fill the data cache to flush it, but it depends on how big this cache. Another option could be to call a blocking function such as sleep using ROP, and using ROP because we could think here like,
okay, I'm gonna write a small shell code which calls sleep and that's it. But then we could have the same problem, like that mini shell code could be still at the cache and then we won't be able to reach that.
So that's why we're using ROP. And then after that, then the cache will be flushed and we can jump to our shell code. So for the ROP exploit, from the epilogue of the function where we have the stack workflow, we can know what registers we have control with. So this is very useful for the ROP, obviously.
And then this is the gadgets that I'm using to execute the sleep and then jump to the shell code and all of them are from the libc. For the shell code, I'm using a standard reverse shell code, not a big deal.
But, I mean, there are, on the internet we can find several MIPS shell codes for Linux, even Metasploit provides MIPS shell codes, but, and this particular one is from exploit database, but none of these are gonna work in this system. And as far as I know, and I tried to find shell codes that could work in this system are not going to work.
And that's why mainly because this is MIPS N32. So MIPS N32 has some particularities. For instance, it uses 64-bit registers, but uses 32-bit memory addresses. But also what it has is different syscall codes.
That's why the shell codes are not going to work. So it's not a big deal. You can just open the libc and check the syscall codes for each API that your shell code is calling. For instance, this is the socket function, and this is the syscall code for this function. And then after that, then you got your MIPS N32 shell code
that is gonna work, which by the way is big endian. So for the exploit, yeah, so remember that I'm using the black access point as the attacker, and it's going to attack the white multiple access point that I have here.
So this graph represents better the exploit so you can understand better. And I'm gonna exploit it through, I mean exploit through the Wi-Fi. So this is the attacker's laptop, which is my Mac here. So I'm gonna connect through the Wi-Fi to the target access point
because the access point is providing Wi-Fi, obviously. Then I have an ethernet cable connected to the attacker's device, and using the internet sharing of Mac OS feature, then now the attacker's device can have connectivity to the target through the Wi-Fi.
And then three basic steps. I'm gonna run the netcat listener in my laptop. Then I'm gonna execute the mint exploit, which will change three different things, as I will explain. And then through the Wi-Fi, it's gonna exploit the mint vulnerability, and then the reverse shell, it will connect back to my listener.
So let's see if it works. Fingers crossed. So I'm connected to this access point, moto test, which is the target device. And here is the AP713191FD80,
which is the attacker's device. So with this command... Oh, nice. Wait a second, please.
So mint neighbors. Now we can see with this command that the mint link is already established between the attacker's device and the target. Then I'm gonna access to the root cell.
So we have this shell script, which is gonna execute three different Python scripts. The first one is the one that adds our fake MAC address in that particular list, so we can reach the heap overflow. Then the second one is gonna trigger the heap overflow.
So we are gonna overflow the heap with our shellcode and ROP gadgets. And then finally, we are gonna execute or trigger the stack overflow, which that particular MMCBY is gonna get from the heap buffer, the shellcode and the ROP gadgets.
And also, I have here the netcal listener. So let's see if it works or not. There you go. So here we have the reverse cell as a root, as you can see.
And you can see here that this is the AP713136F3E0 device, which is the target, because the attacker was the 91FD80.
So this is the exploit for one particular mean vulnerability over the tier through the Wi-Fi.
So finally, as a conclusion, so extreme networks were really responsive to us, and they provided fixes and patches for most of the issues. Here I'm sharing with you guys the link where you can check the patches
and some other information. But at the beginning, apparently, they didn't understand the impact of the issues, because also they were saying that none of the vulnerabilities can be directly exploited over the air, which is not true, as you just saw. And some other stuff, like for the mint vulnerabilities, they were saying that the attacker must have access
to a win device that has already been compromised. That's not true. I mean, I'm using my own device, so the attacker can use his own device, but also the attacker technically could create his own mint client in his Linux box. So this is not a must.
But yeah, we recently spoke with them, and then they realized that it was wrong, and they changed all this information, and they are accepting now that the vulnerabilities can be exploited over the air, and the attacker doesn't need to compromise the device to exploit the mint issues and some other stuff.
So that's good. So yeah, finally, yes, I think there is a lot of room for improvement in this operating system, because there are more vulnerabilities in this OS. So yeah, hopefully with these lessons learned,
they will fix in an attractive way more issues, and then we will have more secure WinOS devices out there. So that's it. So thank you very much, and if you have any questions, I'll be around here.