 So, you might be asking yourself why school software now, and just like many other industries, every year there's a new breaking record of publicly disclosed cyber security instances, and the K-12 school districts was no exception to that, so we noticed that there was a big uptick in that, and then kind of also tying into now kids are going to start learning over the network and starting to use maybe more software in their day-to-day learning habits, we decided to take a look. So, that's kind of when we began to look for software that is widely distributed. It has like one of the largest user bases. We try to think like being an offensive security researcher, we try to think like the hackers, and this is kind of what they would do, you know, get the moves bang for their buck, if you will. So, this is when we stumbled upon NetUp. NetUp Vision Pro is the software that's used in the school districts. They have around six million teachers and students using their platform in over 9,000 school districts all across the globe, and the NetUp is actually the parent company that has like around 100 million users. So, let me explain a little bit more about how the software is designed to be used and how COVID has actually made this more vulnerable to attacks. NetUp Vision Pro is primarily designed to actually be used in like computer labs or on-premise classrooms, things like that. It's not necessarily actually designed to communicate over the internet. It's primarily designed to be like a local network piece of software. However, with COVID-19, we noticed that there was an uptick in hybrid and e-learning, and this is where we kind of started to put these two together and how due to a lot of these students needing to borrow PCs or maybe a district requires them to use a certain software set might be letting these students bring home these computers, and I'm sure they didn't have time to go through and, you know, disable local-only software, like NetUp Vision Pro here. So, we kind of identified a new attack vector here where software that has traditionally be confined into like the walled garden of the school district network can now be a little bit more exposed if these students are bringing these home. So, let me explain a little bit more about how the software works and kind of what it's designed to accomplish. NetUp Vision Pro is actually like a student management software. The teacher kind of has like this overarching control and view of all of the students on that's connected to their classroom at the time, and the teacher can you blink the screen, remote control this computer's block web access, run applications even, and then like log in or even shut down the computer. And this is all to kind of facilitate the learning of these students and keep them on track. When it's installed, it's installed as a system service and it is automatically started at boot, so the students can't really disable it or anything. It's kind of tamper-resistant in that way. So, kind of now that we got the groundwork lay that let's put our hat and shoes on and dive into some of the technical details. Like I said before, we like to think like the attackers and these are kind of the four goals that we set out to accomplish and this is what we think that would also be what an attacker looking at the software would want to achieve. So, since there's no internet access, we wanted local network attack. We wanted to see if we can get remote code execution on the machine. We wanted to see if the software is leaky and can potentially leak Windows account credentials and then we wanted to maybe try to see if we could improve our position on the compromised machine by privilege escalation. So, the first thing we did was after we identified this as our target from the user base, we just went to the website and they actually offered a 30-day free trial which to a hacker is indefinitely free trial. So, we really like free trials. It's a good way to instantly get in there and start reverse engineering and kind of see how the software works and we don't have to pay for it. But I don't want companies to take that as a negative. So, keep offering free trials. And then after that, we kind of set up a test environment where we created a handful of VMs, made one the teacher and the rest the students and we kind of at this stage wanted to identify the most common install. So, there's nothing worse than once if you find a vulnerability and you realize you didn't check security or something during the install process. So, at this stage, we were trying to make sure that our test environment here made the most sense and would be what we saw in the wild. And this installer was actually pretty simple. There was not much to change there. So, we set up this little local network with a handful of students in the teacher. And then we began just poking around at the software. A lot of people think all hacking is in your basement with a hoodie on. But a lot of it is actually just understanding the software to kind of identify where vulnerabilities lie. And this is a large part of our job is just trying to figure out how each of these function. So, the teacher, like I mentioned before, has quite a few actions that they can perform. And we kind of wanted to narrow our scope here and see which ones would be the most interesting. And then lastly, we just, right before diving into the reverse engineering and debugging and whatnot, we wanted to identify the differences between the two installs, the student and the teacher install, and kind of identify if there was any overlap if we found a vulnerability in one. Could it affect the other? And they were actually quite different. So, the student runs most of those plugins, I mean, most of those actions that I showed in the previous slide with separate binaries. So, when the teacher wants to, for instance, open application, it will use a plugin with it. It has a different EXE. And the teacher kind of just uses just the one. One thing I want to point out is that all of the student installs actually run as system. So, I think that's to probably prevent students from tampering or disabling the running applications. And the teacher just actually runs as the normal teacher. So, now that we have kind of the setup going, let's go back into our goals and start going through them one by one. So, the first thing that we wanted to do is just kind of look at the network and see how the teacher and the student communicate. And that's pretty quickly we identified that all of the traffic was unencrypted. Even things that we considered sensitive. Like, right here, this is on the top here. This is the action where the teacher is trying to log in remotely to the student PC and they can type in Windows username and password. They actually block it from here. So, they blocked the password from being viewed, but not in the wire shark capture. So, in the wire shark capture, all of the credentials were just passed in plain text. Any eavesdropper on the network could have captured that. And it's not only the credentials were passed in plain text. For instance, when the teacher was going to run an application on the student computer, that was also passed in plain text. As well as, soon as the students are connected to a classroom, they instantly begin sharing their screenshots like these. And those were also passed in unencrypted, not in plain text necessarily. But using a piece of software like DriftNet, it can pull these JPEG images out over the wire and kind of display them in a semi-real-time view of the students. All just kind of being a passive listener on the network. So, just to kind of fill in the system architecture now, we can add the network traffic and the green unencrypted because none of the traffic that we identified was actually encrypted. And this was our first finding and our first CVE that we we filed against them of clear text transmission of sensitive data. Not only the Windows credentials, but also commands can be seen as well as the screenshots. And to kind of just highlight on how simple this is for an attacker, all they would need to do is have access to the local network where the students are, have a Wi-Fi card or a network card that has promiscuous mode and just a simple free network sniffer that can capture that traffic. So, if we look back at our goals, we didn't actually get a local network attack since we haven't attacked anything. We kind of just passively listening, but we were able to actually compromise Windows accounts. So, just seeing that if the teacher used that login function, we would be able to capture those. So, the next we wanted to do is try to see if we can get remote code execution on the student, seeing that the network traffic is unencrypted. And we wanted to do that. First, we wanted to see if we can actually just emulate a teacher seeing that a lot of the actions a teacher can perform on a student remotely is already a great step in the right direction. Being able to run applications, for instance, that to an attacker is a wonderful thing. So, we wanted to see if we could now just emulate this unencrypted traffic ourselves and kind of become a teacher. And these are, there's a few of the things that a teacher can get or an attacker could get from emulating a teacher. The students always trust the teachers. They can't deny teacher requests or actions at all. It doesn't matter if it's school time or not. If a teacher says to run this application that there's no way the student can disable that. And then they also just start sharing screenshots like I mentioned before. So, how would the teacher or how would we as an attacker try to find these students on the network? It's actually quite simple. The student client actually starts beaconing out their presence on the local network every few seconds, actually. And you can see here, we got in this Wireshark capture, the student computer name, their MAC address, and their IP address all just kind of being broadcast out every few seconds. And it's kind of everything an attacker needs to kind of create a list of these targets on the network and kind of enumerate through each of them to perform this emulation attack, if you will. But first, we had to see how the student and the teacher actually make the connection together and how they begin to send commands or whatever. And that's when we started to look at the handshake between the teacher and the student. And I want to point out that there is these two UDP messages before. So, the teacher actually sends a UDP message to the student and then the student responds with the UDP message. But the first connection is actually the student talking to the teacher. So, the teacher is actually the listening socket. The student is the one that initiates the connection. Kind of after this, these first UDP packets of the teacher kind of telling the student to connect. So, the student makes the connection. And it's around 11 packets in a handshake from just diffing multiple handshakes. We actually only identified three unique elements within that handshake across different students, computers, and different teachers. So, most of it was actually just a static replay for when we wanted to actually emulate it. But first, we had to identify how these three unique elements were being created. And to identify those, we kind of dove into some more packet captures and some reverse engineering. And we identified that the first unique element was just a teacher ID. So, each teacher has a static unique ID. And then the second one was the same, but for our student. And the third one actually was quite a mystery from the majority of our research. We kind of just left it as token three like in this Python output here from one of our scripts. However, after being in Windybug for so long, that address, already this token three started to look a little bit more familiar. And if we actually ran the address command on it, it was this student was actually broadcasting out their heap address for some reason. I don't know why I really was hoping to use that in some kind of like ASLR bypass or a heap exploit or something, but never got around to using it. But I just thought that was a very interesting way of sending a, I don't know, a unique ID over the network. So, now that we kind of understand how the handshake is completed and how to find these students on the network, we started to just write some Python scripts to actually do the emulation. We use Scapey. So, these are some Scapey layers over here. And I want to just kind of point out that not all of the fields we did identify, some of them are still UKW unknowns. So, we identified as much as we could, but they were static. So, we actually didn't really need to know what they were in the end. And then this is kind of just a simple script showing how we can emulate running a command on remote code on the student PC. And you can see that all were really changing here is the target IP and then those tokens every once in a while. And then lastly, the command. So, most of it was just a straight replay, actually. And I'll kind of show a demo here of this. So, these three Windows PCs are actually just the student PCs. And this is our tax script. And so, all it did was right there. It happened really quick, but it scanned on the network for five seconds, actually found all of these computers, beacons, and then just ran PowerShell. And we're doing it again right here. So, scanning for five seconds. And this time we're going to run calculator. So, it creates a list, goes through each of them, and then just replays that handshake with the dynamic fields updated. And we just replaced the command with what we want. So, we kind of used that as our code execution. And that was our second finding, actually. Incorrect authorization. Since there was no way that the student actually can identify if that teacher is their teacher or if it's a Python script like it is here, that's a problem. So, we filed this one against them. And so, we now have a local network attack now and we can do some code execution on the student. But we still haven't increased our privileges. So, in the last example where we're running calculator, for instance, that is actually being executed as the student. So, it is correctly dropping the privileges from the main executable that is running a system to that of the student. So, even though all of the plugins and the service files are all running as system on the machine, they actually have code in place to identify the logged in user and drop the privileges to that. So, we wanted to see if there was any way to bypass that or since we have access to unencrypted network traffic, if there was a field or whatnot that we could pass that could bypass that. That's kind of when we started to dive into, well, we've been doing some of this reverse and sharing this whole time. But this was the first time that we kind of started to look at how the privileges were getting dropped. And as you can see on the left here, this is just all wrapper code for identifying which user is logged in and then calling shell execute way down here with the application that the teacher wanted to execute. And there was a path just going straight to shell execute. You can see right here that all it's doing is it's skipping all of the wrapper code to find which user it is and essentially just running as system. However, there was no way to actually change the variable that was setting us onto this path. It was like read from registry at boot. And nothing over the network could really get us to change that. So, that was a failed attempt of just finding something in the network that we could modify to get system execution. But it kind of got us thinking if all of the code or all of the shell executes are wrapped in this code to drop privileges. And that's kind of when we started diving in to all of the binaries. Not just the main one. And that's kind of where we identified that there were a few that weren't actually. So, you can see right here there's a shell execute down here that doesn't have any of that wrapper code. And these were all unfortunately local privilege escalations. So, none of these shell executes actually were, they never digested user input. So, we couldn't run arbitrary commands. And they also were all needed a mouse. So, a mouse space exploit. And this is just the first one I'll kind of highlight on is, for instance, this one was if you right click on the icon and click help, it will bring up a window with their support web page in it pre-filled. And so, it starts Internet Explorer as system. And then there's ways that you can just right click on save ads and things like that. And if you click on CMD or whatever, you can usually execute that. So, that was our third finding and our third CVE that we filed for incorrect privilege assignment. But this is still not what we wanted. We still wanted to be able to do this kind of privilege escalation over the network. And so, that's kind of when we started to dive into some of the other plugins and how they were handling it. And it kind of brought our attention back to when we were downloading the free trial when we saw this change log here where it said, we fixed an issue where the teacher sends a file to the student and the student clicks on it, it launches as the system context. That was important in two ways. For one, this chat client can send files, which is always good to have a primitive to drop files on a remote system. And it clearly has had problems in the past with privilege assignment. So, you can see, like I mentioned before, all of the plugins are still running as system. So, that's probably how it inherited that system context. So, we kind of at this point diverted our attention to this chat feature. And we wanted to see how the file operations worked. And that's when we actually identified that this chat function was way more feature complete than we thought. I thought it was just going to be a simple instant messenger. But it actually has primitive or it's not primitive, but the ability for the teacher to actually kind of view the remote file system of like the students, which is kind of interesting. So, this is a teacher view. This is how the teacher would see it. And if they click on the student, it will actually like show you their file system. And you can actually go into traverse these paths. But the only thing that you can't do is like there's no like the dot, dot directory or whatnot to go back up. So, we're kind of confined to my documents folder here. But we can still from there view, copy, delete files. So, that was pretty great finding right there for us. But next we wanted to kind of figure out if these file operations were wrapped in that wrapper code to drop privileges, for instance, or if these file operations were also running as a system like the plug-in is. And that's kind of when we dove back into IDA and found out that they were actually doing all of the file operations as system. And then only at the very end kind of just CH modding 777, the file just setting the access to everyone. So, they just that was their easy solution to make sure that the student can can view these files, I guess. And so, this was actually our fourth finding and actually our highest CVSS score because we now have a remote primitive of system level file system access remotely on these students based on this. So, to kind of highlight on the impacts here, we definitely wanted to figure out if we could traverse back up to maybe the C drive, for instance. And that's kind of when we dove into this convoluted path and actually found a way that the teachers do control this remote path of the student. So, you can see right down here at the very end you can just type in whatever you want. So, being trying to get a system level execution on the computer, we decided to just change this to the C drive, navigate to the folder where the other NetApp Vision plug-ins exist, over delete one and drop in some malware, I'll just call it, where then we know that that software will eventually be executed with the system context and we can just use our emulation script to kind of automate all of that. So, and that's exactly what we did. And I'll show some of the Python code here of how we got system level access or system level code execution remotely on these students. So, the first step we did is we, all we need to do is find those students on the network. Like I said, just scan for the network for five seconds and we can usually make a list of them. Then we enumerate through the list and we start a chat thread in the background, just like how the student connects to the teacher. The teacher is the listening socket, the same with this chat feature. The student connects to that. So, we started listening chat thread. Then we send the UDP broadcast message telling the student to connect to us. We grabbed those three unique tokens from the handshake and then we finished the handshake with those tokens in there. And then in this stage, in the background, the MChat thread here will change the root directory to the NetOvision Pro install directory, delete one of the plugins, drop in our malware and then just exit. And then right here, we're calling, we overwrote the screenshot viewer, for instance. So, this is a screenshot viewer plugin. So, in this call is now just emulating us being the teacher of starting that screenshot viewer plugin. And then we just drop out into kind of show all of that happening in real time and kind of showing how fast it is. I'll play this little video, this demo here. Same thing. So, all the teachers are, I mean, all the students are around the top and then this is the attacker. In this, I'm just kind of showing that they're all just normal users with real time protection and whatnot kind of on. Like a standard install, I'm sure maybe a school district would probably have more running but this is kind of what we decided would be normal. And so right there, I was just showing that none of the students are connected to anything. And so we'll start our emulation script again and this time we've added just a dash s for system and then our binary of choosing. And so it scanned for five seconds, found the three vulnerable computers and then we'll enumerate through each of them and then begin starting this reverse shell for each of them. So they will all eventually get compromised here. And one thing I want to point out is since we are emulating the teacher pretty much stock, these client, these disconnect warnings do pop up but as soon as we're done, we can disconnect. So you can see right there that it just says disconnected. So could raise suspicion, I guess, but it was the best we could do. And now from the attacker screen, if we run like PowerShell, we can do a who am I and we are actually running as system all remotely. And just to kind of give a visual, I'll start calculator there. And since we're running out of time, I'll skip over the other two, just open calculator two, so not miss it much. But kind of highlight on some of the impacts of the systemable privilege remote code execution is that this could technically be a wormable infection where if a well designed malware, for instance, was just laid dormant waiting for these other beacons from other software that was vulnerable to this, the other NetOption Pro clients, it could eventually kind of further the spread. And like I mentioned before, since these students are kind of taking these devices off of the district network, it's always running in the background. It's starting a boot. The students can't disable it. It doesn't matter which network it's connected to, it's still listening. So if they brought their computer to a public cafe or a library and an attacker saw them there and was able to run this kind of attack on them, and then like dormant, and if they bring it back to the school network, the school network could be compromised. Lastly, so we disclosed this to NetUp on 12.11.2020. And we followed our 90 days disclosure period. They were really responsive and actually got it patched before the 90 days. And so the patch version is 9.7.2. And we publicly released on 3.21.21. Thank you again for tuning into the talk. And I'll be in the Q&A session a little bit later. I hope to answer some of your questions. Thank you.