Southwest Sky-Fi Shenanigans

Trapped

Most would say January 6th, 2022 was a beautiful day on the small island of Kauai. The sun was shining. The ocean water was sparkling. The breeze was perfect.

But for me, January 6th, 2022 was an involunatary slow cook under the Hawaiian sun. Due to a malfunction at the tail end of my Southwest Boeing 737 MAX, my flight was stalled without any ETA. To make matters worse, the entire plane had to be turned off for repairs. There was no salvation. I was trapped in an aircraft surrounded by the tropical atmosphere of Hawaii, the bodyheat of over a hundred passengers, and no air conditioning.

With nothing to do, I gazed out the window of my cramped enclosure aboard a plane-themed oven, praying that at any moment, the aircraft would be fixed and air conditioning would turn back on.

An observation

Perhaps a desperate attempt to distract myself from the stuffy atmosphere, I began to tinker with the networking configuration of the airline's wifi. Last semester, I enrolled in a networking course, in which I learned a great amount of how data from one end of the world arrives at another. As a no-life computer science student, I somehow thought the downtime of the flight would be a great opportunity to employ some of what I had learned.

Since the airplane did not take off yet, I initially worked from my phone. I did not want to take out my laptop because the aircraft could be fixed at any moment (i.e. I would have to inconveniently stow away everything). At the time, I wasn't actually committed to tampering with the networking configuration because I did not actually think I would get anywhere. In addition, the networking features on an iPhone 7 were quite limited, so my options of altering my own network information was mostly limited to assigning static IPs and switching up the DNS servers.

From the image above, the IP address given to my iPhone was 10.206.121.194. The subnet mask of the "SouthwestWiFi" network was 255.255.255.0. With the CIDR prefix being /24, I began a sequential test of assigning static IPs to my phone, starting from 10.206.121.1. The address 10.206.121.1 was the gateway of the network, and unsurprisingly, setting my static IP to the same as the gateway would not allow me to connect to the network at all.

Without further ado, I moved onto the next IP address, 10.206.121.2. This IP happened to be the DNS server. As the DNS server is a core part of the network like the gateway, I expected the network to behave the same way as before: unreachable. Strangely enough, that was not the case. To my astonishment, not only could I connect to the Southwest Airlines landing page using the 10.206.121.2 static IP which presumably belonged to another in-use interface, but a verifying checkmark also appeared next to the paid internet button, indicating I had already paid for the internet.

Did I stumble upon a huge error in Southwest's network setup? Unfortunately, despite a symbol stating that the internet was active, I could not connect to any websites other than those allowed by default in the "SouthwestWiFi" network. However, this was progress! I tested a few other static IPs and found that the internet was not active on those IPs, leading me to conclude that the network configuration was using IPs as a way to determine whether or not a device should have open access to the internet.

A deeper dive

After an hour and a half of sweating (because everything on the plane apparently had to be turned off for repairs...), the aircraft finally made its way to the runway and took flight. Finally up in the skies, I decided to pursue the peculiarity I had discovered earlier using my laptop.

One explanation I had conjectured before we had taken off was that the traffic was not being routed to me. After all, the IP 10.206.121.2 was likely still mapped to the DNS server interface's MAC address in the switch tables, so traffic would just get routed to the DNS server instead. To find the MAC address associated with the IP, I took a look at my ARP table using arp -a after pinging the IP.

I was intrigued to find several MAC addresses already in my ARP table, but most of them did not concern me. The corresponding MAC address for the 10.206.121.2 IP was 00:20:0c:7c:46:4c and I attempted to spoof my MAC address so that it was the same as the DNS server's. I thought that by making my laptop look like the DNS server, maybe some of my packets would get routed to me. But alas, my network changes did not work—I ended up with no connection at all.

Another connected device

At this point, I felt like giving up. As a student who only took a single networking course out of mild interest, my skills were not even at a hobbyist level. The techniques I applied were all those I had learned in my introductory networking course.

In a last ditch attempt, I attempted to find another IP address that may have had access to the internet. My rationale was that my issues were related spoofing the DNS server, one of the central pieces of the networking infrastructure. If I could find another device, maybe a consumer device, and spoof it, my logic would work. From here, I figured that if a device needed to connect to the internet, it would have to talk to the DNS server at some point. I opened up a Wireshark window and saw a few ARP broadcasts directly requesting for information about the DNS server with the destination as my MAC address.

In particular, I began trying the static IPs that made direct ARP requests to my laptop's wifi interface. I first set my static IP to 10.206.121.74 to see if it was connected to the internet, and most shockingly, it was! I surmised that maybe all the IPs that requested me directly were already connected to the internet, but this was not the case. It turns out, of all the IPs that contacted my interface, only 10.206.121.74 had access to the internet. It seems like several of the other devices were from people who didn't bother purchasing Southwest's wifi package.

I also noticed that this interface was already stored within the ARP table that I was using earlier. Like before, I spoofed my MAC address to the MAC address owned by the static IP I had set. The only difference this time was that the IP 10.206.121.74 did not belong to the DNS server.

Success...?

It took about 30 seconds for my laptop to reconnect, but after my browser automatically refreshed, I was greeted with the familiar Google logo at google.com.

I tried several other sites: messenger.com, instagram.com, and reddit.com and they all worked perfectly! I will admit I was quite satisfied and smug with myself.

Sadly, my connection persisted perfectly for over an hour, until it anomalously stopped. I reattempted the my spoof attack on the network, but I was unable to reconnect for the rest of the flight.

Afterword

It's hard to say what caused my network to stop working. During my flight, I was actually not aware that duplicate MAC addresses on the same network could have some inconsistent behavior (though in hindsight, that seems pretty obvious considering MAC addresses are supposed to be unique within a network).

To be honest, I wasn't really planning to use the internet anyway. I planned to spend most of the flight snoozing and performing a low reward hack was really cutting into my naptime...

Of course I was a bit dismayed, but ultimately it did not bother me too much. I had already achieved my goal: to access the internet during my flight! Maybe in the future if I fly Southwest again, I'll prepare a few experiments to see if I can replicate this vulnerability. In the meantime, I'll continue to hone my networking capabilities as much as possible. As a treat for making it this far, you can have this virtual POG juice I drank in Hawaii.

Thanks for reading and 'til next time! :)