 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 thingies. 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 lighting 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 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 and 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 is 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 and 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 these 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 can, I mean you have like different type 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 it's running in the background. So devices using this Windows. 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 wing 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 network devices running this operating system. And also we got the control device. So this particular one is important because all these researches started because of this. This, well control 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 IAACTIV, Ruen Santa Marta say, 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 a 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 it has some special connectors to comply with the aircraft regulations, the aircraft industry regulations. But 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 the Motorola, 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 control 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 using 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 AP 7161 and this 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 Zebra 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, non-Indian 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 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 pre-authenticated 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 min 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 points are 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 who are in Santa Marta research he recently spoke about this in Black Hat the last call for outcome security so basically he was able from the internet just using a regular internet connection nothing special to hack and compromise satellite models of aircrafts that are running 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 this 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 Ruben compromised and this is the access point running the wing OS and these are connected through the SMU server so we're 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 internet 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 can he could try to exploit these 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 a backdoor so and yeah when you get a root cell the process of the research it makes easier than this process I mean the research. So but it's a kind of for it's a kind of privilege 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 some in some forum some guys asking about this services star cell command that gets you into the native operating system but he says that Motorola made not disclose the required password to mere 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 like 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 lower case letters but obviously it's not going to work here. So then since we got access to the finger 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 the string and then here is going to call this validate map password function and depending on the return value it's going to reach this basic bug 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. Etc2 I miss password file and the content of this file is this particular string and this is the default value in every wing 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 OS of 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 the 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 had inside the file. So when the code is reading each ASCII character then we got each hex byte for each 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 that file. I mean the hex bytes after those operations in the loop with this static key, hi Sabina, how are you doing? Nice key. And yeah, so in this case after the decryption the result is going to be the password string in lower case letter which makes sense because we were in the last password and that's why it was printing out here like last password use, password in lower case 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 but 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 yeah, 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 lower case letters. So here is the emulation as you can see and in my device for my MAC address this is the valid password which is only lower case 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 high savvy and hard of 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 star cell command the password is going to be different. That's why I call this like a 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 a low root in ETC then you can make it persistent. And then all the time that you execute the command is not going to ask for any password again. Okay so now since now we have a 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 all their 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 socket and we know where the code is parsing the user's buffer. So in this case in this break before we know that the buffer length is 1,000 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 MIMC BY 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 break before. And here's where we have the call off to this function where inside we have that particular vulnerable MIMC BY. 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 MIMC BY. So this is one of the Python client to reach that stack overflow. So as I said this only affects all versions of the firmware but based on information that I got from the control website, the control 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 MIMC BY which is user control. But if it's bigger than this value then it's not going to reach that vulnerable MIMC BY. Instead it's going to execute this as a print function that is going to generate this crash dam and then it's going to kill the process. So yeah, this is a Python code to reach that. So yeah, you can kill the process but the process it will restart immediately. But the problem here is that there is a WhatsApp 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 WhatsApp 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 MIMC vulnerabilities. I mean, there are other EDP services with issues but we don't have time to talk about them so let's move on to the MIMC 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 no 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 these access points 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 use 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 I was 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 so I'm 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 with I mean physically with the 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 a 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's the mint address which is in decimal but it's the four last bytes of the other of the target. Then the board, the buffer and then you can create the mint socket and then send that 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 minting and standalone access point is enabled by default because you can set standard access points as virtual controllers for instance. So the attacker what only needs to exploit these issues is to know the IP address of the target. I mean there's not any kind of authentication so this is the target, the attacker's device, this Motorola black access point. So we only need to like 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 yet 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 like switch case statements that probably are switching through an opcode or something for the protocol. So one of the first issues pretty straightforward is again pre-off keyboard flow 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 mincby we got to go to the case here in the switch case 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 mincby. So luckily there's 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 41, 41, 41, 41 to that particular list. And then after that since our fake MAC address is already there in that list then we can reach that mincby, the heap or flow mincby. 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 mincby. And then here we have the crash of this mincby, this heap or flow, which since we don't have modern exploit mitigations and the libc version is holding this operating system it shouldn't be too complex to get code execution from this heap or flow. Then we got more heap or flow like this one, pretty much the same in another switch case statement but basically it's exactly the same that 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 an stack over flow through mincby as well. So it's another mcby where the destination buffer is an 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 or flow. So the problem that we have here is that this is the mcby for the stack over flow. 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 on freeze and so it won't crash and we will be able to reach the stack over flow after the heap buffer flow. 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 circle and that's it. But no. So if you guys are familiar with MIPS exploration, there's a well-known problem. It's the cache occurrence problem. So we got in MIPS CPU with two different cache, the instruction cache and the data cache. And normally our payload, so our circle, it could be stored in the data cache. So the problem is that when we tried to jump to our circle in the memory, if the circle is still in the data cache and it's not flushed, then we could end up trying to execute another instructions 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 it is, this cache. Another option could be to call a blocking function such as slip using rub and using rub because we could think here, okay, I'm going to write a small shell code which calls slip and that's it. But yeah, 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 rub. And then after that, then the cache will be flushed and we can jump to our cell code. So for the rub exploit, from the epilogue of the function where we have the stagger flow, we can know what registers we have control with. So this is very useful for the rub, obviously. And then this is the gadgets that I'm using to execute the slip 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 Metasploic provides MIPS shell codes. And this particular one is from exploit database. But none of these are going to work in this system. As far as I know, I tried to find shell codes that could work in this system are not going to work. 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 CIS code 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 CIS code codes for each API that your shell code is calling. For instance, this is the socket function. And this is the CIS code code for this function. And then after that, then you got your MIPS N32 shell code that is going to 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 mutual access point that I have here. So this graph represents better the exploit so you can understand better. And I'm going to exploit it through, I mean, the exploit through the Wi-Fi. So this is the attacker's laptop which is my Mac here. So I'm going to connect through the Wi-Fi to the target access point because the access point is provided in Wi-Fi, obviously. Then I have an Ethernet cable connected to the attacker's device and using the Internet sharing of Mac OS filter, then now the attacker's device can connect to the target through the Wi-Fi. And then three basic steps. I'm going to run the netcode listener in my laptop. Then I'm going to execute the mint exploit which will chain three different things as I will explain. And then through the Wi-Fi, it's going to exploit the mint vulnerability and then the reverse shell will connect back to my listener. So let's see if it works. Fingers crossed. So I'm connected to this access point, MotoTest, which is the target device. And here is the AP713191FD80, which is the attacker's device. So with this command, nice, quite a second, please. So I'm going to do this. So mint neighbors. Now we can see with this command that the mint link is already established between the target device and the target. Then I'm going to access to the root cell. So we have this shell script which is going to 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 or flow. Then the second one is going to trigger the heap or flow. So we are going to overflow the heap with our shell code and rub gadgets. And then finally we're going to execute or trigger the stack overflow which that particular MNCBY is going to get from the heap buffer, the shell code and the rub gadgets. And also I have here the netcode 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 911FD80. 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 mean vulnerabilities they were saying that the attacker must have access to a Wi-Fi device that has already been compromised. That's not true. I mean, I'm using my own device so the attacker can use its own device but also the attacker technically could create his own mean 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 mean 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 a proactive way more issues and then we will have more secure Windows devices out there. So that's it. So thank you very much. And if you have any questions, I'll be around.