 But we have a fun talk this afternoon. I don't know about you all, but I love a good Rick Roll. And our next speaker, Rick Roll, is entire high school, which is pretty awesome. So please welcome Mindenk for his first time up here at DEF CON speaking, telling us about how he Rick rolled his whole high school. Thank you. Hi, everyone. Thanks for coming to my talk. My name is Min. I'm 19 years old. And I'm starting my second year as an undergraduate at the University of Illinois at Urbana-Champaign next week. This is my first time at DEF CON, and my second time ever attending a security conference. So it's extremely humbling to be up here on stage as a noob. Before we proceed, first on the disclaimers, if you came to this talk expecting anything other than a scripted story, then you didn't read the abstract carefully. This presentation is for educational purposes only. I do not condone hijacking and Rick rolling other high schools. Also, please don't hack my own high school district. They are very cool people, and they don't deserve that. So let's start from the beginning. Here's a picture of my high school, which has about 2,000 students and is part of a larger school district in suburban Chicago, which has six high schools in total. My school offers some IC classes. They essentially had a career pathway that you can follow from freshman to senior year. Obviously, I was going into computers, so of course I signed up in my freshman year. Those classes were held in this room. It's pretty amazing. It's where I developed my cybersecurity skills thanks to my awesome teacher, Mr. Drenth. He's got a computer lab and has shelves full of computer parts, cables, monitors, switches, everything a high school hacker could ever dream of. Now, one of the coolest things about this room was this closet. Inside this closet were two desktop PCs that were each running Windows 7. I inherited this space from the upperclassmen, and it was here that I really started developing my script kitty face. I never owned my own computer before, so this was the next best thing since I basically had both these computers to myself. And like any hacker want to be, I started running scans against my school network. I was quite ambitious and decided to scan the entire 10 dot subnet. I had some help from my upperclassmen friends, and we took turns running Angry IP scanner, and we had to split the scans into parts because if we tried to open one big scan, it would crash notepad. We learned quite a bit from the scans. The first being that our school district has its own metropolitan area network. So all the high schools are connected to the same network, and they each have their own subnets. We also found a ton of different things. Printers, voice over IP phones, switches. One of the coolest things we found was the security cameras. The top left is me when I first found them, and the bottom right is my friend giving me the middle finger after I showed him. Now, one of the most important things we found in the network that forms the basis for this entire talk is the IPTV system. The system is manufactured by Xterity and consists of three main products. The first is the video player, which are receivers attached to projectors. They send serial commands to the projector to control its current state and also what content is displayed. Here is the web interface for the video player. You can change the input source and volume, and you can also change the current channel to a specific RTP or UDP stream. Next up is the Vadia stream, which is attached to the device that displays video output. The encoder then takes that video output and broadcasts it as a network stream, which receivers can connect to and display. Here is an example of the Carousel live stream for my high school, which is displayed on all the hallway TVs. The stream is broadcasted by the encoder to the Vadia players. It's just a slideshow showing special events to time, weather, et cetera, but it was also used to show morning announcements. And finally, we have the Vadia server, which provides an easy to use interface to manage all the devices at once. Here is the projector control from the Vadia server, where we can drag and drop receivers onto the control buttons at the top, like PowerOn and HDMI. Now, each of the six schools has its own Vadia server, which controls the Xterity devices in a respective subnet. And in this case, I am viewing the projectors for my specific high school. So that was pretty much the bulk of my freshman year. I was just scanning the district network, finding random devices to screw around with and figuring out how things worked. All right, we're gonna skip a few years to my senior year. And the time skip is because nothing notable happened in my sophomore year. And my junior year is when the COVID-19 pandemic hit. And the first semester of my senior year was hybrid learning, so not much happened then either. Then the district decided in March of my senior year that everyone would be required to come back in person in April. It's at this point that I remember, oh hey, I still have access to all those devices from freshman year, and I should probably tell the district about it. And then I think, oh hey, I need to do senior prank. And finally, I conclude, oh hey, I should recall my high school district. So I asked a few friends for help. So I asked a few friends for help and we officially began working on Operation Big Rick. One of the first things we needed to do was establish access to the district network from home. Now, I already had a working solution for this because I installed Chrome RDP on every PC in the classroom dimension earlier. On the screen right now is a list of all those PCs. They're grayed out because they reform at the machines every year, so I can't access them anymore. Now, while we did have network access through those PCs, it's not going to be very hard for district tech to pinpoint me if any scan or exploitation traffic is coming from those machines. So, we need a way to pivot to different machines that are not associated with us so we don't get found out. So now, I will introduce Land School. Who here knows what Land School is? Okay, not a lot. For those who don't know, Land School is a program that gives teacher control over the devices in their classroom. There are two applications. One is Land School Student, which is installed as a background process on all the student devices. And the other application is Land School Teacher, which a teacher uses on their computer to control all the student devices. So, what can you do with Land School Teacher? You can freeze a student computer to make it unusable. This is the one that every student hates. You can remotely view and control a student. You can upload arbitrary files. You can execute arbitrary files. And you can view keystroke history, which I think is absolutely insane because it opens up a massive door for abuse. Imagine what would happen if a threat actor got access to all this control. Turns out it's pretty easy to obtain a copy of Land School Teacher if you know where to look. And if you're an IT guide provisioning hundreds of student computers, well, you're not exactly going to prioritize adding passwords to the classrooms. And here I'm viewing a student's keystroke history. It looks like they're doing some 3D modeling based on district history. Now, it also turns out Land School Student was not only installed on the student computers, but also on some staff computers as well. Here's a desktop of one of the security guards. So, using our district network access and Land School Teacher, we were able to pivot to a different high school. So that way, when we'd run our scans from there, the district wouldn't be able to track us. I now had a better knowledge of what to scan for, so we found a few new things. It turns out all exterior devices run SSH. And they let you open a shell, like direct user access to this system. This makes things way easier, though, because instead of sending a bunch of web requests to control each of the receivers, we can create a payload that runs the serial commands locally on device. Now, this payload is really just a batch script that makes requests to the web interface locally, but it's pretty simple and it boils down to this logic. The first thing we do is set the receiver to play the Ripple Stream. So it's at address 2025, 2525, 255000. The next thing we do is set the input to HDMI, since this is the input where the video stream is playing. Then we disable infrared capabilities. This way, the teacher cannot use her remote to turn off the receiver. Although, they still can technically power off the projector off manually by pressing the power button, but we'll get on to how to fix that later. And the final step in our initial process is to actually turn it on. Then we enter the first loop for three minutes. It's during this loop that the countdown is displayed, not the actual rickroll yet. The loop basically sets the volume to the max and then ascends the power on command every 10 seconds. And this fixes the issue I mentioned earlier where the teacher could just manually turn off the projector, but that doesn't work because it just turns on again. Close to the end of the countdown, we switch the input back to HDMI to make sure that the projector is still showing a rickroll. Then we run the main loop a second time, but this time for nine minutes, and this covers the entire rickroll stream, and also allows people to read the final message as displayed after the rickroll. Finally, we restore the channel that the receiver was broadcasting previously using a backup we made, and then re-enable the infrared remote so everything goes back to normal. At old times, we maintained a pivot of at least three Avedia players before connecting to the Avedia server. This way, the district would not be able to trace us back even to the land school computers without significant effort. And then our plan was to slowly distribute the script from the Avedia server to all of the Avedia players that we identified. In my research, I also found a privilege escalation in the Avedia player and the Avedia stream. Here's a shell where I'm logging in as root. The way that the exploit works is that you can export a backup of the device configuration to an FTP server, which will be the attacker machine. The backup also includes a shadow file, so you can just change the root hash to something you know, import that backup back onto the device, and then login as root via SSH. The Avedia server had an even easier privilege escalation, pseudo access was just given to the system control binary, which is a classic get the fuck out binary. So you can just create a service file that executes a command as root and call system control on it. Do the root hashes by the way, in case anyone's interested in tracking them. I haven't tried anything beyond rocky.txt at all, so don't shame me if you do manage to get it. All right, let's go time now. We picked a date April 30th because that was a Friday before AP exam started. We've had plenty of times to test and get things working. We're ready. But at the last minute, we found something new. First, let me introduce the Epic system. Epic stands for education, paging, and intercom communications. It's exactly what it sounds like. It consists of speakers, which can be installed on the ceilings of hallways and classrooms. Similar to the IPTV system, these speakers also have a central server called the Epic server. Here's an example of one of the projectors I mentioned earlier. You use the Epic server to control various alarms, and you can create and manage bell schedules for when class starts and when class is dismissed. And more importantly, you can upload custom money over bells. So April 27th, it's exactly three days before the Big Rick. When we discovered the IP ranges for network speakers, the reason we didn't find them in my freshman year is because the Epic system was installed in my junior year. This looks exciting for us. If we can get access, then we can change the bells to use a Rick roll. Unfortunately, the default passwords don't work. Today's pass, it's one pass midnight on April 29th. One of my partner's shapes is sad because he was the one trying to push us into getting the Epic system. Five minutes later, he finds the password. So it turns out that the district did change the default password, but they used the example password from the manual. When we checked the settings, we found the IP address of the server that I was bound to, which brought us to this login page when we connected. We found out that this was a login page for the Epic server. So we quickly found the default credentials in the manual, which weren't changed. And boom, we now have control of the bell system for one of the schools. However, there's a slight problem. The Epic system at the other schools had their default password changed. We can't log in, but all hope is not lost. In the settings, I found an SMB server that was configured for backups with the same default credentials. And then I thought one of the backup servers for the other school still have default credentials. I was right. He already extracted contents of one of the backup archives for another Epic server, which we did not have initial access to. And in each archive is a SQL dump of the entire configuration, including user entries. Now, most of these entries were just teacher accounts connected to LDAP, so no password hashes there. But there are a few local manufacturer-created accounts, which you can see in the top left corner. So it makes sense that I would try to correct the password for one of these accounts, right? The problem is that the hashes for these accounts were different across each school. And unfortunately, it didn't work for any of them. However, I discovered something strange. It was a local account with the username district. And what stood out was that this account is at the bottom of the table. It was also created in 2017, which matches the date of the other local accounts, which means that this is an account created by the manufacturer, not one installed by the district. I couldn't find any information online about this account, and it doesn't show up in the user's list on the actual webinar face. So I concluded it's a backdoor account. And even better, the password was password. So now, using the backdoor control account, we control the bell systems for all the schools in the district. And that's how we epically pwned all the Epic servers. All done in less than a day and a day before the Big Rick. And now we upload the Rickroll audio file as a bell. Can you guess which one is a Rickroll? I'll give you a hint. One of the lowercase L's in musical scale is a capital I. Also, it's the one that's streaming as long. Then the final step is to modify the schedule to replace the bell with our newly added bell. And we're done. The final task is to set up our stream with the countdown timer here and when it hits zero, the Rickroll begins. It was a massive success and both the IPTV systems and bell system Rickrolls worked. Here are some gifts across the district showing the result. This is one of my favorite ones. It's a student experiencing the Rickroll from their Zoom meeting and the teacher is showing it to them. And this is the final message that I just played when the Rickrolls finished. I was very tame and careful about the wording because I did not want to provoke teachers more than I already did. So you might be wondering what happened afterwards. Well, we compiled all the things we did into a 26 penetration test report, 26 page, sorry. And then we sent that to all the technical supervisors in the district after the Rickrolls were done. And of course we did this anonymously. A few days later, we got a response. It was from the director of technology for the district. And because of our documentation and ethics, he said that the administration would not be pursuing discipline and actually asked us to hold a debrief. So you can imagine our reaction. It was a pretty big relief for all of us. I'm sure many of you have heard stories where students report vulnerabilities through school and it does not end well for them. So we were extremely fortunate that the district was studying with us and in fact, listening to our advice. Here's a screenshot from the debrief we had over Zoom. I was the only one who revealed my full identity since my other peers thought it was a sting operation. It clearly wasn't or I wouldn't be here. In our debrief presentation, we referenced each other as a caller. So we thought it would be funny to identify as crewmates from the hate game among us. Overall, the meeting went in streaming well and we managed to resolve the issues in the district. So lessons I learned from the big Rick always maintain a pivot since doing that threw off district tech and they could not figure out who did the big Rick until I came forward. Check your scans carefully or you might miss a server that controls all the speakers and waste two out of three days before the deadline for an attack. Try to keep things as tame as possible so you don't end up in too much trouble. I could have been a horrible person and displayed anything else that would have not been school appropriate. Document everything to protect yourself at least if what you're doing is ethical. It really helped me in this case at least. I'd like to thank my accomplices, Shapes, Jimmy and Green because I wouldn't have been able to do this without you guys. I also want to give a shout out to Mr. Drenth for being the best IT teacher ever. I'd also like to thank Sigpony and friends for encouraging and helping me prepare for this talk. And finally, I want to thank my school district for letting me graduate and not pressing charges. Here's my website, follow me on Twitter and thank you for coming to my talk.