Skip to content
Tech News
← Back to articles

Gaining control of every projector and camera on campus

read original get Wireless HDMI Transmitter → more articles
Why This Matters

This article highlights how campus networks' DNS configurations can potentially be exploited to identify and control connected devices, raising concerns about network security and privacy. It underscores the importance for institutions to safeguard their DNS infrastructure against unauthorized access and manipulation, which could impact both security and user privacy.

Key Takeaways

While starting my first year at the Colorado School of Mines, I came across a rather interesting fact: the local DNS servers will assign a subdomain to each device that connects to the network. This means that a device called “meow” will be visible as “meow.mines.edu” on any campus wifi, though the network still blocks any traffic. This got me thinking in the back of my mind about what I could do with this, and especially if I could use this to trace back devices on the network.

The main problem is accessing the underlying DNS records that point a specific subdomain to a specific IP (it’s a bit more complicated than this, but you get the gist), which can be addressed in a few ways:

Zone Transfer

While this would be the simplest option, I doubt IT would simply zone transfer to me (and they really should not zone transfer to just anyone). My list also wouldn’t update as new devices are added or removed from the network. Plus, where would be the fun in that?

Certificates

Many subdomains register certifications to ensure your data is coming from the right place (TLS, HTTPS certificates). These certificates are added to append only ledgers or logs, like letsencrypts CT logs. While these are useful and necessary for websites, I don’t see why my college would register TLS certificates for every device connected to its wifi, especially since they aren’t even accessible from the internet.

Brute force

The last approach I see, and the one this blog is all about, is brute force. There’s a few ways to do this, including searching every possible domain, or using a dictionary of common hostnames to reduce the number of lookups. I personally don’t like the dictionary approach for this project. Even though it’s more practical in the real world, I became particularly interested in writing a program that was fast enough to brute force every combination. This gets exponentially harder, as the number of domains possible is 37^n, where n is the character length of the subdomains.

After settling on permuting through brute force (possibly the worst option), I got to work. The first program was just something I wrote in python, getting me to wrap my head around the problem. I used the itertools permutation function to find every combination of letters and numbers to make the subdomain (spoiler alert, this was a bottleneck). I knew it needed to be async because otherwise I would be blocking in order to wait for each DNS response. It was fine as a program, and had a decent minimal TUI, but was way too slow despite being async. Still enough to enumerate 3 characters in a decent amount of time.

This was about when I started moving over to rust. I know a lot of cool projects in rust, yet I never saw the need to build something in it. Python had always been fast enough for what I was doing, until now. I also started playing around with Helix, a modal editor, and realized how much I like it. While I rarely use any editor that goes beyond syntax highlighting for python, language servers also become a necessity in rust.

... continue reading