Pi Sniffer’s Travels
Travels into Several Populated Locations of the US. In Four Parts.
Part I: A Voyage to PHL
The author gives account of himself and the Pi Sniffer. His first inducements to travel. He finds AXIS cameras and maps them. An email is observed.
Back when leaving your house was still a thing, I had the good fortune to present some of my work at BSides Tampa (Feb. 28), BSides NoVA (March 5), and BSides San Diego (March 6). With me on my travels, I brought my Pi Sniffer.
This Lilliputian sits in my pocket and snarfs up all the WiFi it can. Due to it’s inconspicuous nature, the Pi Sniffer is able to venture into areas where conventional WiFi sniffing might not be possible. Sit back and allow me to share some of the interesting things we saw on our travels.
The first part of our journey took us to the magical land of PHL where Cisco gear provides free WiFi to the masses. The free WiFi is provided by access points advertising the SSID attwifi and Free PHL Airport WiFi. In truth, these are the same physical devices, just using different antennas. This is easy enough to prove because the AP are configured to advertise the device’s name.
When doing post-analysis of Pi Sniffer’s pcaps, this naming scheme ensures that we always know exactly where we are in the airport. In the above image, you see the name AP0130-B-G2–11- which means Pi Sniffer was in Concourse B near Gate 2. In fact, the airport is canvassed by hundreds of these access points: from the concourses to the ticket counters to baggage claim.
Maintaining a GPS signal indoors can be problematic. Doubly so for the small, cheap GPS that work best for a project like Pi Sniffer. So, when we want to track down interesting networks during post analysis, we need to use our context clues. Take for example, the AXIS cameras in Concourse A that I found broadcasting WiFi networks. Their default SSID is axis-<MAC>.
Here we see, right before the axis-ACCC8E5F9F5A beacon, probe responses for attwifi and Free PHL Airport WiFi. Digging down into those responses we see both contain the device name AP0032-AW-G17–4 meaning Concourse A-West Gate 17. So we can actually map out where we see some of these AXIS cameras.
It’s a little surprising these cameras have WiFi enabled, let alone broadcasting the default SSID. To get an idea if the cameras are actually in use, I referred to the BSSID/client count CSV that the Pi Sniffer generates. This CSV simply informs how many clients each BSSID was observed to have.
Here we can see two of the cameras had five or more clients. Are these clients connected via WiFi?
Digging into the pcap it appears all of the network traffic is broadcast traffic being transmitted by the camera itself. Which means all observed clients are likely not connected to the WiFi. I’d guess, the WiFi was left on unintentionally.
Another interesting network where the Cisco device names came in handy was called x_m4rd_$mn1.
Between two probes of x_m4rd_$mn1 we find a beacon from attwifi. Digging down into the Cisco tags we find the attwifi device is named AP0055-AW-CON-5 meaning Concourse A West… but no gate is provided. So it’s likely that the area x_m4rd_$mn1 is found is here:
This is a fairly interesting part of the airport… But we’ll wait to talk more about this network in TPA.
In the biz, we call that a teaser.
The other reason we are interested in location information is because, for whatever reason, Cisco tells us how many clients are connected as well.
Here we see seven clients connected to the Free PHL Airport WiFi device at Concourse C Gate 24. The Free PHL Airport WiFi network is unencrypted so it’s a good opportunity to hang out and listen in to these clients. Although, some will say you won’t find anything interesting.
While Mr. Thorsheim makes a variety of good points in his thread, I only need offer this as a simple counter point:
Why, yes, that is a (redacted to protect the foolish) email being sent without any type of encryption over an unencrypted WiFi connection. It’s kind of hard to believe in 2020, but sometimes just listening is enough.
Part II: A Voyage to Tampa
A familiar network is encountered. The author travels to BSides Tampa. pwnagotchi’s are observed in the wild.
In TPA, I found myself enjoying a quiet breakfast at The Café in Concourse F while the Pi Sniffer enjoyed sucking up data from yet another x_m4rd_$mn1. Looking at the map below, note the proximity of The Café (T3) to the security area.
Given the location of x_m4rd_$mn1 in PHL, I think it’s safe to say that this network is associated with the security area. That is bolstered by the EAPOL packets the Pi Sniffer observed pulling down a DHS certificate.
Given the general sensitivity of government networks, especially DHS, this discovery surprised me. Two security areas broadcasting the same SSID. Presumably this network isn’t sensitive or it would be hardwired. But still interesting… what type of devices are on this network?
Just because a network is encrypted doesn’t mean we can’t get an idea of the devices associated with it. In the image above, I’ve filtered the PCAP to show me devices transmitting data over x_m4rd_$mn1. Looking at the device’s OUI, the first three bytes of the mac address, we can get a feel for what is going on in the network. Pictured we see VMWare, Riverbed, Cisco, Dell, HP (Palo Alto?), and Apple devices on the network.
Un/Fortunately, voyeurism only gets us so far. That’s all I know about x_m4rd_$mn1, but this gives me something to look out for next time I cruise through airport security.
Of course, I didn’t spend all of my time in Tampa at the airport. BSides Tampa kindly hosted my talk Is That a WiFi Sniffer in Your Pocket? at the University of South Florida. And it wouldn’t be an infosec get together if I didn’t capture a bunch of these beacons flying through the air.
Pictured is the beacon frame of a Pwnagotchi named cakesniffer. If you aren’t familiar with these cute little devils, they are devices of various configurations that collect WPA key materials for cracking with hashcat (yes, that’s a gross oversimplification, don’t @ me bro). Did I mention they’re cute as shit?
Unfortunately, besides cakesniffer and XfinityX, the other Pwnagotchi I saw in the wild all used the default name of pwnagotchi. Give your little dude a name, people! And turn off bonding if you don’t want to be caught deauthing at will :P
Part III: A Voyage to Dulles
The author sets out on his third voyage. Observes a surprising amount of wePresent. Indulges in shameless self-promotion.
At BSides NoVA, I got to talk about MikroTik routers (yet again!) and share a new technique to get root on the routers. After the talk, I rushed to Dulles to catch another flight. In Dulles, I was delighted to see a very familiar SSID: wePresent-xxx. With no authentication/encryption even!
Last year, I found a bunch of vulnerabilities in these wePresent devices (and various OEMs). I wrote about it on our Medium blog: Eight Devices, One Exploit. Conveniently, one of those vulnerabilities was a very simple unauthenticated remote command injection.
Since these devices don’t support automatic updates, what are the odds that they’ve been patched in the last year? Really, it seems pretty dangerous to have these things with open WiFi. But maybe they’re just standalone devices that aren’t networked to anything? Let’s peek into the data.
Here I’ve filtered the PCAP for packets that use one of these devices as a base station. We can see multiple systems are on the same network as the wePresent device, and we can even see some Netbios and HSRP traffic.
Of course, again, no GPS in the middle of an airport. So we have no idea where the devices are physically located.
Just kidding, Dulles also has a whole bunch of Cisco AP that broadcast names that are easily mapped to physical locations. Below is one of the FR-IAD SSID broadcasting the device name I-COND-D15–01. Which happens to be Concourse D Gate D15.
Repeating the mapping exercise, we can find wePresent devices broadcasting open WiFi in a number of different locations around Concourse C and D.
Part IV: A Voyage to San Diego
The author discovers Apple Wireless Direct Link. Encounters a password broadcasted in a beacon? Unbelievably, more shameless self promotion.
Throughout my travels I found a lot of mDNS traffic being sent on the BSSID 00:25:00:ff:94:73. But there were never any other non-mdns packets associated with that BSSID. In SAN, the data looked like this:
Turns out that this traffic is all Apple Wireless Direct Link (AWDL), an Apple feature that I was totally unfamiliar with! Although it hasn’t escaped the attention of other security researchers: A Billion Open Interfaces for Eve and Mallory: MitM, DoS, and Tracking Attacks on iOS and macOS Through Apple Wireless Direct Link.
Essentially, these devices are advertising their device name and enabled services (e.g. airdrop) via unencrypted mDNS messages broadcast to anyone listening. Most surprising is the sheer volume of devices broadcasting this information. On my travels, I saw hundreds of devices using AWDL.
Another interesting thing I encountered was an SSID called AJ_SoftAPSsid_B8827EB2B1D09.
In the image above, you’ll see I’ve highlighted one of the vendor specific tags that the device uses in beacons. Note towards the end of the highlighted region that we encountered the string “p@ssw0rd”. Now let me call to your attention Microsoft’s documentation for configuring Windows Device Portal for IoT Core.
A very suspicious coincidence if you ask me.
Finally, I was excited to see some Grandstream near BSides San Diego!
I’ve already released a few exploits from my Grandstream research, but there are many more to come. Always fun to find your targets being used in the wild.
Thus concludes the first edition of Pi Sniffer’s Travels! Remember, if you want to build a Pi Sniffer and do your own WiFi sniffing then you can find a parts list and a Raspberry Pi image on our GitHub repository.
