How students are compromising their school’s internal networks. Part 2

This article explores the vulnerabilities in school networks, focusing on how students compromise them. We discuss Active Directory, bypassing content filters, and Chromebooks. We explain how students escalate their privileges allowing them to access restricted resources, and even leak school data using dual-booting. Moreover, security flaws such as default credentials that lead to data breaches are explained. This article is meant to raise awareness and help better protect our education’s critical infrastructure. Read Part 1 here: https://medium.com/thedeephub/how-students-are-compromising-their-schools-internal-networks-5e8603bf1ae1

Chapter 4: Chromebook vulnerabilities

Now, in my humble opinion, Chromebooks reduce the attack surface of the education sector significantly. I’ve never seen such a tight operating system that seriously values access control and global policies. Not only was the OS built on a strong, secure codebase, but the vulnerabilities discovered are taken seriously and patched as soon as they’re discovered (Google is known to do this with many products it’s quite impressive).

Now, due to the way Chromebooks operate, the vulnerabilities and bypasses are significantly different. I’ll begin by explaining the easiest low-hanging fruits to the more complex ones.

Chromebooks have an option that allows you to boot into developer mode, from there you can run commands to unmount the drive, wipe all policies, and reset the hardware. From there, you can download a fresh installation of ChromeOS without the school’s restrictions. However, this is very simple to patch through simple configurations and this is 9/10 times not going to be possible anyway.

The next method I saw during my time in infosec research was I came across a YouTube video that showed a kid taking apart his Chromebook, finding the policy chip, and physically scraping it off. This chip is designed to reload the organization’s policies every time it detects it’s been tampered with, over-written, or erased (this way even if developer mode is enabled and you re-install the operating system the chip will re-install it anyways leaving your efforts futile). Therefore, in theory, destroying the physical chip on the hardware layer allows you to bypass this access developer mode and simply reset the laptop. However, this design flaw has been quickly changed by Google and the policy chip’s location is now unknown and very likely to be embedded within another chip in the PCB. Moreover, the policy administrators of the schools can see when a device in unenrolled, therefore, this can lead to further investigation (kudos to Google!)

Network Vulnerabilities are the most effective for Chromebooks, and are incredibly difficult to learn. There are many group chats, discord servers, and hidden channels that disclose these techniques, and due to how difficult they were to discover they’re quite paranoid about anyone new joining (took me months). Upon entering these chats there were loads of files, tutorials, videos, and more. One of the most effective, quick bypasses was using a custom DNS server. Because ChromeOS filters out content using a DNS server, it’s possible to swap the DNS server on the laptop with one of your own. This allows restricted content, games, etc to be accessed. This could be done via the network settings and was incredibly simple. The difficult part was hosting a DNS server, maintaining it, and load-balancing all the traffic. Yes, there’s now a policy and patch for this as well.

Lastly, restrictions can be placed on the extension level as well. LightSpeed Filter Agent has a Google Chrome extension that is loaded by default by the school’s policies and cannot be removed. However, due to ChromeOS’s design, it was possible to abuse their private system API via javascript bookmark and disable these extensions allowing for a full bypass of GoGuardian (for student monitoring) and LightSpeed (for content blocking). Thankfully, this did not allow for black-listed extensions to be loaded.

Loading this bookmark will pop an alert, this can allow for JS execution if the school has disabled Inspect Element, Developer Tools, or running javascript in the URL directly.

Lastly, the most common (and well-known) method of bypassing restrictions is to use domains that have not been black-listed by WAFS or filter agents and then slapping a proxy search engine on top of it (such as TitaniumNetwork which is open source on Github).

The list can go on for days, there are too many techniques students use to get past these, and unfortunately, the security pitfalls can lead to system-level access and even escalation to network permissions.

Chapter 5: Default or Predictable Credentials

Many schools have default accounts for testing, guests, etc that are sometimes over-privileged. Moreover, many schools have passwords designed off of the student ID (which can be searched by anyone in the mailing system) such as this:
last 4 digits+initials+DOB year

This is incredibly insecure and dangerous and to make matters worse elementary schoolers at the time I went were actively abusing this to bully, troll, and annoy their peers — I myself fell victim to this.

Let’s say the password for this student “Fake Name” with a DOB of 8/12/05 was 5789FN05. See, it’s predictable.

Chapter 6: Remediation and Defenses

Many of the techniques described above have existed for years and can be prevented through basic implementations.

1. Let’s start with the dual-booting, this can be prevented by disabling safe mode, or by password protecting it (like the BIOS).
2. The app-blocking policy bypass can be fixed via a custom policy, encompassing all drives and ANY application.
3. The hard drive’s contents can still be physically removed from the laptop, and read in an external reader, so to defend against this a TPM with encryption should be applied for the data-at-rest.
4. A firewall should be placed on the network level. Moreover, the proxy should be routing data to a school proxy designed specifically for these personal laptops. Not only does this allow more efficient monitoring of student activities, but allows for patches to be pushed easily through a central server.
5. Integrity checks at the hardware level (TPM) or even software level (via files and hashes) should ALWAYS be implemented and if these hashes do not match then simply fail to continue and alert administrators.
6. Regular updates, patching, and monitoring
7. Zero-trust network design
8. MFA, secure SSO vendors (preferably Microsoft), passwords with entropy.
9. Do not ever store passwords at rest (including wifi), use encryption, integrity, and monitoring of sensitive files being accessed.