So, when I was writing my episode discussion post on Cyberchase Season 1 Episode 1 "Lost My Marbles", I mentioned that I might make another post about the security breach that allowed The Hacker to infect Motherboard with the virus. What did The Hacker do to set this up? How did the kids accidentally open the breach? And other questions like that. I have a bit of background in software engineering. I will try to keep things as simple as possible. Much of this is head-canon built on top of what we see in the episode. Of course, the show plays it fast and loose with computer terminology. Don't try to hack things in real life. You will go to prison. So, here's an MSPaint diagram of a tiny piece of Motherboard's setup. Keep in mind that she is the god of the Internet, and her Internet may even stretch beyond Earth into other galaxies. So, there are three separate network segments here. We have the library's internal network, which has the big board on it. We have Control Central's internal network, which has Motherboard on it. And then we have a Database Server internal network, which has a Database Server running on it. The Database Server is something that I invented here. Remember that this whole diagram is head-canon. However, it's not too far-fetched to think that Motherboard must reach across Cyberspace to a separate Database Server, maybe at the Cybrary. Now, we know that Motherboard is not directly reachable, even with her Firewall down. Otherwise, The Hacker wouldn't have needed a separate security breach to get to her. He would have just pushed the virus once she took down her firewall for maintenance. However, Motherboard has a Virtual Private Network (VPN) tunnel to the Database Server. If The Hacker can compromise the Database Server and get his virus in there, it might be able to ride the tunnel into Control Central. The purpose of any Firewall is to apply a set of rules to any network traffic going into or out of a network, device or application. A good Firewall configuration allows on the traffic that is needed and denies everything else. Motherboard's firewall between herself and the Database Server is currently down. The Database Server itself has connection points to the larger Internet without using a VPN tunnel. However, the Database Server's own Firewall for that access point is UP. If The Hacker tried to throw his virus at that access point, it wouldn't work. However, there is another connection point into the Database Server. This is another VPN tunnel from the library network. Let's say that the board retrieves the data on the locations of different objects on the map and the icons for those objects by reading one of the Databases. Maybe the board also writes data to the Database to log what directions people requested. The point here is that some traffic from the Board is authorized to pass through the Firewall on that VPN tunnel. Now, is there a way for The Hacker to get the Board to send authorized traffic over the VPN tunnel to tell the Database Server to open a breach in the Firewall for that public access point? Maybe. It is an Internet-of-Things (ioT) device. Alot of people get these devices, and then they either leave passwords set to their defaults or they forget to keep the sofware patches up to date. There is a public access point to the Board with a poorly-configured firewall. Maybe there's a way for him to get inside. It may be possible for him to dump the virus code into the board, but there's no guarantee that it would be able to go any further, since the Firewall between the Board and the Database Server is working. So, let's think about the Board as its own thing. Suppose that we have two user accounts associated with the board. There is a Principle of Least Privilege that states that a given user account or system process should only be given the minimum amount of permissions required to perform its tasking. That way, if the user account or system process attempts to do something out of line with its permissions, it won't be allowed to perform the operation. However, if you leave other unnecessary permissions open, and the user account or system process attempts to do something outside of its original intended operations, then the operation may succeed and have unintended consequences. This also links up with the software development concept of the Minimum Viable Product. You build your software to perform only the exact tasking that it needs it perform. You don't put any additional, undocumented functions in there. Otherwise, those functions could activate and have unexpected consequences. The board's purpose it to display the different locations. It allows for users to input two points, and it will draw a line between them to assist in navigation. We also established earlier that it reads its information from the Database and writes other information out to the Database. However, suppose there was some undocumented functionality here. Suppose the developers had a special feature installed in the board that ran a cleanup command against the Database if you pressed three buttons in quick succession. Suppose that the cleanup command in question could be any arbitrary command. Therefore, the developers put the command into a configuration file to be read and executed by the software at runtime. However, the developers knew that if some kids turned up and started poking the map, they could accidentally kick off the Database Cleanup command. They removed the Database Cleanup command from the configuration file. That way, if someone did poke three buttons in quick succession, the software would check the configuration file, see that there was no command defined, and then do nothing. The trouble is that they left the part of the software that read the configuration file and ran the arbitrary command in place. So, if the command was somehow added back to that part of the configuration file, then there would be a command for the software to run. Then, if someone else pushed the three buttons, that command would be run. So, yeah, someone could put a command in there to write a bunch of junk into the Database until it filled up and crashed. Again, these are commands being sent to the Database from the Board. The Firewall would let them through just fine. That's pretty bad, but that only lets them modify the Database, right? It's not like they can just tell the Database to open the Firewall on the server that it is sitting on, right? Well, what if one of the things that the Database could do, upon request, was to open a command shell on the server and run a command. And what if, that command shell was able to run commands that impacted things on the server beyond the Database itself. What if we called it "xp_cmdshell" and called the Database Server "Microsoft SQL Server 2000". Windows XP and Microsoft SQL Server 2000 would have been around at the time of "Lost My Marbles" after all. Those were also the key players in the real-world Heartland Payment Systems data breach of 2008, which inspired this post. But hey, just because the Database could open a command shell on the Database Server doesn't mean that The Hacker could use it to bust the Database Server's external Firewall, right? He still needs a way to execute "xp_cmdshell". So, he needs an account with the correct permissions to tell the Database to execute "xp_cmdshell", and he needs the Database itself to have high-enough permissions to run a command via "xp_cmdshell" that can bust the Database Server's external firewall and open a path to Motherboard. Thankfully, the Database only run the "xp_cmdshell" for the top-level Database Administrator account. This is where we get back to the Principle of Least Privilege. The Board should connect to the Database with a fairly low-power account. It only needs to read-from and write-to a few Database tables after all. Likewise, the Database itself should have been started on the Database Server by a fairly low-power account, as it only needs to handle reading and writing its own set of tables. But then some moron decided to hook up the Board to the Database Server on the top-level Database Administrator Account. So, if the Board was configured to send an "xp_cmdshell" command, the Database would run it. Oh, and another moron decided to have the Database Server start the Database with the "root" account for that server. So, if the Board was configured to send in an "xp_cmdshell" command to nuke the external Firewall, then the Database would be able to nuke the external Firewall. There is a principle called Defense-in-Depth, where you build multiple layers of defense around your critical item. That way, if a layer fails, you may be okay. We're running out of layers. We only have one or two layers left. We know that the Board doesn't run "xp_cmdshell" for its regular operations today. Sure it has an undocumented debug mode that allows someone to execute any command in its configuration file (including "xp_cmdshell") against the Database. But someone would need to get to that file. The board's main account doesn't give you a filesystem to play with, as they wouldn't want kids running up, poking things, and deleting the filesystem. No, you only get the interfaces that you get. You can pick two items and see a path between them. Or you can pick three items and see the undocumented debug mode run whatever command is in the configuration file. But what if there was some sort of maintenance account accessible through the Internet that didn't enable someone to send commands to the Database, but would enable someone to get into the filesystem and mess around with it? And what if that maintenance account was still using a weak or default password because people just don't check that for IoT devices? So, he's in the Board's filesystem now. That's concerning. And wouldn't you know it, yet another moron left that critical configuration file in a state where the maintenance account can make changes to it. So, of course, he found the empty configuration item for the cleanup command. Remember, this was setup to run any arbitrary command. Of course, he put in an "xp_cmdshell" command that tells the Database to nuke the external firewall on its own server. While The Hacker was able to put the command in place, the maintenance account doesn't have the power to send commands to the Database on its own. That power is only enabled for the system account tied to the Board's user interface. So, he still has to rely on someone in the real world to push three buttons in quick succession. Well...shit. That's not good. That's not good at all. Seriously though, don't try this at home. I suppose we can speculate on the nature of the virus. We know from Season 1 Episode 14 "Cool It" that Motherboard goes through more cryoxide than normal due to the virus. There are actual computer viruses out there that were designed to turn off heat safety warnings on CPUs and then cause them to run hotter. Some CPUs would eventually melt and ruin the computer. The original infection destroyed the Encryptor Chip, and it is stated that only a replacement Encryptor Chip could cure the virus. The name suggests that it deals with data encryption, but perhaps it is also a virus cleanup tool. Perhaps it worked to weaken the existing virus until it was eventually overwhelmed and destroyed. Perhaps the virus exhausted most of its strength destroying the Encryptor Chip first. In any case, curing the virus permanently would end the show.
