Remember all the recent fuss about Salt Typhoon?
That’s a cyberattack group apparently associated with China that was tied to a long series of intrusions into US telecommunications companies.
These weren’t super-sophisticated, high-tech attacks against specialized parts of the telecommunications infrastructure itself, such as mobile phone base stations, satellite network devices, and so on.
These attacks were much more general than that, ultimately giving the criminals widespread access to the IT operations of the affected companies, apparently with the same sort of across-the-board abandon that ransomware criminals aim for in order to magnify the effect of the breach.
The family name Typhoon for a threat group is Microsoft’s nickname for “probably from China,” with various countries tagged somewhat arbitrarily with the names of various meteorological phenomena.
Different groups within any region or threat type are further tagged with apparently random given names, such as Volt, Flax, Salt, and Antique.
Two threat groups sharing a family name aren’t necessarily related in any way, other than by where they’re thought to be based.
When you first heard about Salt Typhoon, you may initially have been relieved to hear that their hacking skills weren’t of the sort that allowed them to clone mobile devices, infect them at will with spyware, or intercept calls and network messages in real time.
But the sheer breadth and diligence (if that’s an acceptable word in this context) of the intrusions nevertheless allowed the attackers to come up trumps by stealing information about calls that had already been made.
This included call logs on an enormous scale (e.g. who called whom, and where, and when), as well as saved audio recordings of many calls, including calls of sufficient significance that they had been collected and stored for later as part of court-approved wiretaps.
Data about data, such as call logs that document the calls that were made but not exactly what was said in them, is known in the jargon as metadata.
Although it’s not quite as much of an intrusion of privacy to have your metadata stolen as to have your calls eavesdropped, telephone company metadata is still incredibly valuable to criminals.
If they are trying to build up a comprehensive picture of what you do and whom you do it with, metadata can give them all the information they need in one fell swoop, without any need to stalk you, or to track you online or in person over an extended time period.
That’s why this story is an important security warning to anyone who provides web-based tools for customers.
Fortunately, in this case, which affects Verizon (one of many US companies affected by Salt Typhoon hacking activities), there’s no evidence that any criminals found this bug before it was fixed.
Also, Evan Connelly, the researcher who uncovered it and disclosed it responsibly to Verizon, went on the record to say:
I do want to credit Verizon for a quick response and fix.
While I don’t have the exact date they fixed this issue, I believe it was sooner than when I retested the issue and noted on my side that it looked to be resolved.
They were also prompt to acknowledge my report.
The bug is surprisingly easy to understand, and it involves a class of security hole with the curious-sounding name of IDOR, short for insecure direct object reference.
Simply put, Verizon’s Call Filter app allows users to retrieve and browse the list of calls they’ve received recently, and to set filtering actions for future calls based on that call history.
That’s certainly handy for blocklisting repeat troublemakers, for allowlisting important contacts, and perhaps even for collecting evidence to report illegal or unethical telesales callers or rogue support businesses.
As Connelly noted, the app downloads your call list by visiting a special URL like this:
https://clr-aqx.cequintvzwecid.com/clr/callLogRetrieval
(The text string cequint, it seems, is the name of a third-party service that handles call tracking and management, and vzwecid apparently stands for something along the lines of Verizon web-based call identification.)
The web request tells the server which phone number it’s interested in by including an HTTP header as shown below, where Ceq denotes Cequint, and MDN is probably short for mobile device number or a similar phrase:
X-Ceq-MDN: XXX-XXX-XXXX
But to stop just anyone asking for the call logs of any number, the app also needs to present what’s known as an authentication token, which is essentially a digital fingerprint provided by the server to act as a sort-of temporary identity badge that is uniquely associated with the phone number specified in the X-Ceq-MDN: header.
Simply put, although attackers can easily guess (or, for that matter, know with certainty) what your mobile phone number is, and therefore inject it into bogus call log retrieval requests, the digital fingerprint is meant to be beyond their reach.
In this case, looking at Connolly’s notes, the secret token is an elliptic curve digital signature of 64 bytes, far too long to guess correctly.
Also, the token is always encrypted inside the network traffic between the app and the server, thus making it as good as impossible to sniff out and steal in transit.
End-to-end encryption for the win!
Except for one small SNAFU that Connelly uncovered.
Although the app and the server go to all the trouble of generating an authentication token they can use to prevent account takeover, and although this authentication token seems to be verified correctly by most features of the app…
…the server forgot to check it when you retrieved your call logs.
Connelly understandably didn’t give precise details of how the bug could be exploited, but it sounds as though an attacker who could acquire an authentication token for any old account – for example by setting up the Call Filter App on a burner phone – could then change the X-Ceq-MDN: header to say anything they liked.
In other words, any authentication token associated with any phone number would act as a sort-of skeleton key for all the call logs of every account.
You can now see why this sort of bug is called an insecure direct object reference, or IDOR, shorthand for, “All you have to do is ask, and I will tell you.”
Annoyingly, perhaps, the bug wasn’t in the app, but in the backend server that acted as the gatekeeper of the call log database.
Learn more about our mobile security solution that goes beyond traditional MDM (mobile device management) software, and offers active on-device protection that’s more like the EDR (endpoint detection and response) tools you are used to on laptops, desktops and servers:
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
