With some 80 items on my research list from the past two Defcons, I thought it would be a great idea to have a go at one of them in whatever spare time I had. The first one on this list was using the EFFs software, crochunter, for a war-drive around the city for rogue cell towers, and to get a better grasp of cellular communications as a point of curiosity. Julian Claxton, another consultant and Technical surveillance countermeasures specialist subject matter expert tagged in.
The why
Of the talks released at Defcon this year was an outline of EFFs crochunter. You can read more about it at the projects GitHub https://github.com/EFForg/crocodilehunter. My previous forays into this space had been using RTL-SDRs to scan across all frequencies which ended up being a little tedious especially when we knew where cell towers were already. I’d also been keen to explore cellular communications outside of another slide deck on what 4/5G is, or another unqualified statement that 5G is somehow responsible for corona virus.
Crochunter has a very specific purpose, namely the identification of suspicious eNodeBs (think base station) by listening broadcast messages from all of the 4G stations in the area, inferring their location, and looking for unusual activity (source, GitHub). It achieves this by identifying eNodeBs within range, collating data and also doing a comparison with existing data. The premise is the presence of a previously unidentified system would imply an anomaly.
The threat
An interesting discussion point came out during the conversation I had with Julian during our drive; the Australian Government does not realistically need to employ stingrays, or if they do, the capability would have limited employment & as we do not employ dragnet surveillance, and as such we hypothesised we’d see any of these. On top of this, Government employs other technologies or mechanisms for law, and so we do not face the same problem as overseas citizens.
So what is our threat in Australia? A few ideas we’d brainstormed included (in order of likelihood):
- Technology researchers having a bit of fun.
- Members of the public firing up a base station for their own use (funnily enough, we had this happen in an office of ours where one of the facility owners needed better mobile phone coverage … allegedly).
- Anyone trying to collect intelligence opportunistically, although realistically theres easier options.
- Foreign Intelligence, however unlikely given the ramifications if caught, and the ease of other mechanisms these organisations employ.
Additional background on attacks can be found here:
https://www.eff.org/wp/gotta-catch-em-all-understanding-how-imsi-catchers-exploit-cell-networks
The setup
My testing prior to the drive has included a mix of Raspberry PI4s, my blade RF, GPS dongles or my laptop. Theres been a lot of hit and miss, and fun times compiling and identifying an odd error or two which I’ve mentioned below.
My final setup was a BladeRFx40, GPS dongle, Ubuntu 20.04 with the requisite software on a VM.
The drive
so, as happens during any practical demonstration, our GPS decided not to work after extensive testing at home. I hypothesise that this was due to a USB issue, and will continue to troubleshoot.
Unlike cyber thought leaders who have to pack it in when Nessus stops working, Julian & I opted to continue on and simply record manually where we were, and capture data for analysis later on. There were also issues with determining if a cell tower was valid or not, so I parked this for manual analysis later.
What we saw
During our drive and a subsequent drive 2 nights later, we identified 715 unique records between Circular Quay and Sydney University. One of these stuck out.
On the western side of Wentworth path, we identified a cell that was providing a Mobile Country Code (MCC) of 567, which is unusual given that all cells within Australia should be providing an MCC of 505; MCC 567 doesn’t actually exist. the Mobile Network Code (MNC) of 23 also didn’t make sense as it is limited to a bespoke provider.
A simple bit of googling of MCC 567 suggests that the code is associated with a test environment, however this could not be qualified at this stage.
There’d also be the occasional MCC of 0, however this would only occur at start up, and I deduct this is just a bug.
Post analysis
Several days later I dumped the database and analyse the collection in greater detail. I queried existing records of LACs & CIDs to see if a record had not been previously observed for which there was one.
In one location, Tracking Area Code (TAC) of 19241 was identified with Cell ID 20033137 and MCC/MNC 505–2 (Optus). The TAC is inconsistent with the area, which had TACs of 52009 and 52010. The Cell ID does appear to have a legitimate enodeb_id of 78254. Additionally, the power and signal to noise ratio is consistent with similar Optus devices operating at the same frequency (783 Mhz) as well.
If a phone needs to connect to an alternate TAC, there’ll be a need to update location, connect to the new TAC, reveal the International Mobile Subscriber Identity (IMSI) and may lead to follow on activities. That being said, this could also be a simple misconfiguration… the reality is we cannot qualify that fact at this stage.
I’m looking forward to going for a few more war drives over the coming months & will keep you posted.
If you’ve enjoyed reading this, please donate to the EFF who have put crochunter together- https://supporters.eff.org/donate/30for30–S
Edward Farrell
