Connect to UCLA's wifi so that strangers can send you malware for free

Here’s the TL;DR (you can also check out the FAQ):

If you’re a UCLA student, faculty, or staff member, or are visiting UCLA, you are exposing yourself to a tremendous level of risk by connecting a device to eduroam or ethernet¹. If possible, you should connect to UCLA_WIFI or UCLA_WEB instead.

“Vulnerability scanners, on my IP range?” It’s more likely than you think.

I transferred to UCLA’s PhD program in Electrical and Computer Engineering about a month ago. My first week on campus, I noticed that UCLA’s eduroam network was assigning my laptop a rather unusual IP address:

@kernelmethod ➜ ~  ip addr show dev wlp0s20f3 | grep inet
inet 131.179.58.220/23 brd 131.179.58.255 scope global dynamic wlp0s20f3
inet 131.179.59.35/23 brd 131.179.58.255 scope global secondary dynamic noprefixroute wlp0s20f3

Dust off your table of reserved IP addresses and you might notice that 131.179.58.220 and 131.179.59.35 aren’t IP addresses reserved for LANs. In fact, 131.179.0.0/16 is actually an IP range belonging to UCLA.

I also noticed that my firewall was suddenly dropping a lot of traffic, from a bunch of random IP addresses. Lots of machines trying to hit lots of ports on my laptop, most of which definitely were not on my LAN.

Under the hood

It seems² that UCLA’s eduroam and ethernet assign IP addresses to people’s devices from the following IPv4 subnets:

• 128.97.0.0/16
• 131.179.0.0/16
• 149.142.0.0/16
• 164.67.0.0/16
• 169.232.0.0/16

The normal way to assign IP addresses to devices would be to use a reserved range like 10.0.0.0/8 or 192.168.0.0/16 and then use NAT to translate between internal IP addresses and the outside world. In contrast, UCLA gives each device that connects to its network a unique address from the ranges that it owns.

This feels like a somewhat strange way to set up a network, but what do I know? I’m not an network admin for an organization with tens of thousands of devices that also happens to own several Class B networks. What UCLA is doing is a bit odd, but not necessarily problematic.

The bigger issue is that there’s absolutely no firewall between devices on UCLA’s network and the outside world.

Let’s pay Shodan a visit

Type in org:"University of California Los Angeles" into Shodan and you’ll immediately pull somewhere around 15,000 - 20,000 IP addresses from devices at UCLA, most of which are on the five aforementioned IP ranges:

Not! Great!

There’s plenty to dig into here. As one might expect (if you’ve ever browsed Shodan’s horror stories before), there are dozens of internet-connected cameras, smart lightbulbs, and similar devices that are exposed. Among those results there are also thousands of personal devices. For instance, as I write this, a search for org:"University of California Los Angeles" macbook pro reveals ~1,000 Macbooks on campus (usually through an open AirPlay port). The query org:"University of California Los Angeles" port:62078 turns up over 6,000 iPhones and iPads³.

Between Shodan queries and some of my own tests, it appears that all traffic from the outside world is permitted into UCLA’s networks. This is a significant security risk to students, faculty, and staff connecting to eduroam or ethernet. A lot of devices that have a security vulnerability in some shape or fashion aren’t easily exploitable only because they’re protected from the outside world by some combination of firewalls and NAT. UCLA completely removes this layer of protection.

It’s hard to measure the downstream impacts of this exposure. In most cases, it’s going to be really difficult to figure out whether a device was hacked by being exploited remotely while exposed on UCLA’s network, or if it was hacked for a different reason. To give one data point, though, when I started this investigation I found two exposed and unauthenticated Elasticsearch instances on UCLA’s networks. Both had been ransomed, with their indices apparently backed up to a third-party server, deleted, and then replaced with the following ransom note.

Privacy risks

Beyond the security implications I’ve listed, there are also privacy issues at stake. Every single device that connects to eduroam is given a publicly routable IP address with no traffic filtering, which makes it trivial to see what kinds of devices people are connecting at UCLA.

In a lot of cases, these are devices that are most likely hooked up to the wifi in UCLA housing. For instance, try the following Shodan queries:

• org:"University of California Los Angeles" os:playstation
• org:"University of California Los Angeles" "bedroom"
• org:"University of California Los Angeles" "apple tv"

It’s also pretty easy to find the IP addresses of lots of students’ personal machines. Depending on what data sources you have access to, it’d be pretty trivial to do things like figure out what sites students are browsing to and even where they physically are throughout the day.

Some speculation

UCLA should be filtering traffic coming from the outside world.

That’s easier said than done, though, and I can guess at a few different reasons why a firewall hasn’t been set up yet. For one, UCLA’s network is really old – to give you a sense, the first message sent over ARPANET was between Stanford and UCLA. From a technical perspective, there are probably some significant challenges in performing any major architectural changes.

However, I think there are more compelling social reasons that explain why eduroam is such a mess. There are probably quite a few people (mostly faculty and staff) who benefit from the network being wide open. It is incredibly easy to set up a webserver with a reserved and mostly-static IP address on eduroam. Browsing through Shodan, I found a few dozen labs and research projects clearly benefitting from this by running servers off of UCLA’s network (although a good portion of these haven’t been updated in several years), and there are likely many more servers providing access to computing resources, shared datasets, and so on. Some of these machines are undoubtedly running critical services – for all I know, a firewall would cut off access to a website run by a nearly-retired physics professor that somehow underpins the entire UCLA course registration system (*glares at Lou’s List*)⁴.

And I can sympathize. I’m hoping to help set up a compute server for my lab sometime this year, and UCLA’s network architecture makes it much easier to expose those resources to members who are off-campus and even to people at other institutions. On the other hand, a public network used by tens of thousands of students, faculty, and staff probably isn’t the best place to run an experiment in figuring out how much malware people would receive in a world where NAT wasn’t invented. And many of the issues I’ve mentioned in this post would be at least partially alleviated by a firewall with a relatively generous allowlist.

While we’re on the topic of social mechanisms hampering UCLA’s security, there’s one other cultural issue worth mentioning here.

Stop Blaming Users for Your Bad Security Challenge 2023 (Difficulty: Impossible)

UCLA’s policy directory has several IT security policies on file. Here’s a direct quote from one of them, UCLA Policy 401 : Minimum Security Standards for Network Devices:

B. Responsibilities for Compliance and Enforcement

System Administrators

System Administrators shall ensure that every Device for which they are responsible is in compliance with the Minimum Security Standards.

A System Administrator may be an IT staff member whose responsibilities include ongoing maintenance for all Devices in a department or computer lab. A faculty member functions as a System Administrator when his or her personally owned computer at home connects to the Campus Network (e.g., via the UCLA wireless or through the UCLA Virtual Private Network (VPN)).

“What do the Minimum Security Standards entail?”, you might ask. Well, among other things:

3. Host-based firewall software

System Administrators are responsible for ensuring that computers with native host-based firewall software included in the operating system have the firewall activated and properly configured.

Exceptions may be made for firewall software that compromises the usability of critical applications.

Hmmm. HMMMMM. Why the hell would you expect users to implement security measures that even your own security team won’t deploy?

Looking at this and other policies, it’s pretty clear that the University of California’s administration has chosen to deploy victim-blaming as a core tenet of its security posture. None of these policies, for instance, mandate the deployment of defensive measures for the protection of students or faculty, except to the extent that university assets contain confidential information (e.g. student medical and financial info) that has to be protected in compliance with federal and California law. The policies do, however, require that every “workforce member” (broadly defined to include anybody volunteering for UC or on UC’s payroll in any capacity⁵) is personally responsible for installing anti-malware, administrating a host-based firewall, backup and recovery, encryption, and eight other security requirements for any device they connect to a UC network⁶.

So the implication seems to be that if your device gets pwned on UCLA’s network, then it’s your fault, rather than an organizational failure. In their defense, UC is hardly the only organization to treat security like an individual burden rather than a communal responsibility; on the other hand, most other orgs don’t have hundreds of thousands of IP addresses on hand to run a network like it’s the Wild West.

The UCLA security team’s response

I reached out to UCLA’s security team several weeks ago to get their perspective on the problems I’ve mentioned here and to alert them to the ransomed servers. I was initially hesitant to discuss their response in this post as

• I don’t think they’re really at fault here; rather, they’re stuck between several competing interests.
• I don’t want to antagonize the security team of the institution that I work for. 🙃

I think that omitting this piece would leave out a valuable perspective, however. So for the sake of completeness (and in the spirit of transparency) I’ll briefly discuss the questions I sent and the response I received.

On January 23rd I sent a message to the Office of the CISO with the following questions. My general hope was to get a better understanding of UC’s (perceived) threat profile, its assessment of the risk that devices connected to eduroam face, and what preventative measures were being taken.

(a) Is the Office for the CISO aware of the level of exposure that devices on the eduroam network are facing to the rest of the internet?

(b) Is the Office for the CISO aware that there are devices currently on these networks that are actively being exploited?

(c) Is the Office and/or UCLA IT actively tracking this issue, and planning on deploying a firewall, NAT, and/or other mitigations for this issue for devices connecting to the eduroam network in the near future?

(d) If so, when is a fix for this issue likely to be deployed?

The Office of the CISO responded:

(a) - We are aware of the “exposure” that devices of any type sitting on publicly-routable IP address space present. Please do keep in mind that there are many different types of usage of the campus wireless networks by a variety of populations on campus. The ability to host an accessible resource is viewed as a benefit and convenience by many.

(b) - All Internet attached devices are at risk of exploitation. Our office has extensive threat detection and identification tools built to detect adversary behavior and take the appropriate steps to contain and remediate threats to campus. This includes campus-wide network threat detection and monitoring. You can read a little more about our efforts at https://ociso.ucla.edu/service/threat-detection-and-identification.

(c) - We constantly strive to improve the campus security posture through enhancements in not only technological baselines, but improved user awareness and training. We are on the precipice of launching a few key initiatives throughout the UCLA community, including our Bruin Secure program (https://it.ucla.edu/it-ucla/key-initiatives), which will focus on tailored training and awareness for all members of the UCLA community. Additional mitigations such as those you mentioned including firewalls and NATs will be reviewed as part of a larger network review discussion attached to the IT Transformation effort currently underway for campus (https://it.ucla.edu/it-ucla/about-it-services/key-initiatives/it-assessment).

(d) - Timelines will be developed as the projects kick-off later in 2023.

This response doesn’t actually deny the fact that the “accessible” nature of UCLA’s network is a major security risk that is vastly more dangerous to the median user than it is helpful. In general, it seems like the threat is being written off because (a) there are various stakeholders who would complain if the campus network was closed off, and (b) any networked device can, hypothetically, be exploited. I’m sympathetic to (if unconvinced by) the first excuse, but not the second. It suggests a very binary view of security that is largely ignorant to attackers’ points of friction.

As for the various initiatives that are described, I can’t speak to many of them as there simply isn’t a lot of public information about what they look like in practice. This FAQ (which reads more like a press release) was the most information I could find on the Trellix⁷ TDI appliances. There isn’t any information, for example, about whether these devices scan the public IP ranges (in any case, I’m skeptical that they provide any value to devices not owned by the university). There’s even less information about Bruin Secure, although the program seems to be in line with UC’s stance that you are exclusively responsible for your own security. UCLA wants to teach its community how to avoid stepping on mines when it could just as easily remove the minefield.

I pretend you ask me questions and I answer them

Uh, I don’t know. Probably not though.

That’ll depend on your threat model, but on balance I’d say that you probably shouldn’t be in full-blown panic mode. That being said, if you visit UCLA on a regular basis (and especially if you live on university property), you may want to consider taking some basic protective measures.

Unfortunately, UCLA’s current stance on network security is to leave every student and staff member to fend for themselves. Until that changes, you’re the only person who’ll be able to protect your devices.

The most practical recommendation I can give is this:

Don’t connect your devices to eduroam or ethernet at UCLA.

I would be especially cautious about connecting random IoT (“Internet of Things”) devices like cameras and printers to eduroam. There are two other networks on campus, UCLA_WEB and UCLA_WIFI, that you should connect to instead.

If you’re confident in your technical skills, you can also try setting up a host-based firewall on your laptop or PC. This is essentially a firewall that runs on your computer, rather than on a router or dedicated hardware. Ironically, it seems that UCLA doesn’t offer help on setting up firewalls (despite the fact that, in theory, faculty and staff are expected to set them up for devices they attach to UCLA’s network). Firewall guidance is beyond the scope of this post, but here are some resources you can use to get started:

• Windows
• macOS
• Linux⁸

In the worst case, somebody might be able to exploit a vulnerable program running on your machine, getting full remote access to your device and everything on it. While this is certainly something that could happen even if UCLA had a firewall in place, the lack of traffic filtering makes this relatively trivial for someone to exploit (if such a vulnerability exists on your machine).

The good news is that if you install software updates regularly, the risk of this happening (for most people, on most of their devices) is pretty low. Regardless of whether or not you install patches, however, it’s pretty much impossible to avoid the privacy issues I mentioned earlier.

No problem!

Sorry.

Stuff that I didn’t think was worth putting in the main body of this post

What’s a firewall?

(You can skip this part if you’re familiar with how firewalls work.)

There’s a good chance that you’ve heard the term “firewall” somewhere before (as in “the hackers have breached the firewall!”). But if you don’t come from a networking or security background, you might not be familiar with what a firewall actually does.

For some background: at any given time, your phone or computer is running a bunch of different programs on it, and some of those may need to wait for a connection from another device on your network. A good example of this is a printer. Printers spend most of their time sitting idle, and while they’re waiting they listen for computers trying to connect to them.

Most of the time, attackers can’t access random printers on the internet for one of two reasons. The first is that your printer may not be publicly accessible. Most of the time, when you connect a device to a network, your router will use NAT (Network Address Translation) to assign your device an IP address. The end result is that your printer doesn’t have a public IP address that the outside world can use to communicate with it.

The second reason is that those printers are behind a firewall. In this context, a firewall is a system that limits what traffic can enter or exit a network. You could have a firewall rule, for instance, that blocks any connections to your printer from machines outside of the network.

Despite the existence of these mechanisms, there are still a ton of printers and such that are publicly exposed on the internet. If you’ve ever tried standing up a server, you’ll know just how much crap a publicly accessible machine receives from various botnets and scanners (malicious or not). It’s pretty easy for a system to get auto-pwned by Joe Ransomware Operator in a matter of minutes if it isn’t properly secured.

In UCLA’s case, it doesn’t use either NAT or a firewall. The former it can likely do without – NAT isn’t really intended to be a security mechanism, and for orgs like UCLA that own a large swath of IP space it might not be particularly desirable. On the other hand, firewalls are a pretty common and useful security measure. But for one reason or another, UCLA doesn’t seem to have any firewall between students’ devices and the outside world.

Edited 2023-02-13: I added a section on the UCLA security team’s response to my questions about eduroam.