Can attest, having searched through literally thousands of pages of documentation in an attempt to attribute the payment processing switch vendor when analysing the ATM jackpotting malware ‘fast cash for Linux’[1]. The best I could do was determine the currency used for the fraudulent transactions, which may imply the country of the target financial institution.
Would be curious if anyone else has further insights.
> Not to downplay it but at least this requires users to download the Onavo app, which isn’t so common.
10 million installs on Android, according to AndroidRank[1]. What we don't know (yet) is what % of those installs had the FB competitor traffic MITM'd.
> This wasn’t simply Facebook hijacking random people’s traffic because they accepted the ToS or used the Facebook app
Do you have further insights or references on what was the "trigger condition"? This is a new case, separate to the previous litigation related to the VPN app.
> from what I can tell FB paid SC users to participate in “market research” and install the proxy.
The app was available on both the Google Play and Apple App stores for anyone to download.
> The way most of the writeups make it sound is that it’s some sort of hack, but this doesn’t seem to be the case.
It could be that you are confused with a previous case. From the blog post:
> The wiretapping claim is new and perhaps not to be confused with the prior controversy and litigation: In 2023, two subsidiaries of Facebook was ordered to pay a total of $20M by the Australian Federal Court for "engaging in conduct liable to mislead in breach of the Australian Consumer Law", according to the ACCC ... Facebook had shutdown Onavo in 2019 after an investigation revealed they had been paying teenagers to use the app to track them. Also that year, Apple went as far as to revoke Facebook's developer program certificates, sending a clear message.
> If this is wiretapping, is it also wiretapping for me to use a local SSL proxy to decrypt and analyze traffic to a service’s API
If by "local" on your own network/machine with your own traffic then obviously no.
Recommend taking a read of CrowdStrike's write up on this [1].
The threat actor maintains a presence on the roaming exchange through compromising "at least 13 telecommunication companies".
> If it's the former, then it seems very un-stealthy
In this article there is one example where the outbound connectivity to the Internet was via a "SGSN emulator in a loop, attempting to connect to a set of nine pairs of International Mobile Subscriber Identity (IMSI) and Mobile Subscriber Integrated Services Digital Network (MSISDN) numbers."
In this example, the transit traffic before egress to the Internet would appear to be legitimate subscriber traffic - user payload encapsulated in a PDP context / GTP tunnel to another telco's GGSN / packet gateway.
> Which, maybe they don't care, but it seems like they're risking blacklisting.
By compromising so many telcos, there are many points of redundancy for persistence on the roaming exchange. This threat actor has remained on telco networks for many years undetected - their techniques are apparently are quite effective.
Hey OP here - I mostly agree with your points in respect to AMap. It's a legitimate mapping service and location SDK.
> Why not mention it's AMap in the tl;dr summary?
The GPS data is being sent to two different companies - the battery monitor developer and AMap. I could make this clearer in the tl;dr.
The cell phone tower data (MNC,MCC,LAC,Cell ID) and Wifi BSSID collection is AMap only.
That said, none of the AMap behavior is disclosed by the application developer. Literally apps that use the AMap SDK in this way turns the user's handset into a continuous scanner. This impacts user experience - just check all the complaints on the 1.75k reviews on the Play store [1].
I doubt many devs are aware of this - It took me countless hours to figure the AMap side of things due to obfuscation techniques in the AMAp code. (See part 2 on the blog post series).
The primary issue is that all this data is collected, sent to multiple 3rd parties (AMap being one of them) and none of this was disclosed to consumers when they download the applications.
Hi HN, this is my efforts in reverse engineering a BLE car battery monitor where it's app has over 100,000 downloads on the Google Play store alone.
It turns out it's sending GPS, cell phone tower cell IDs and Wifi beacon data to servers in Hong Kong and mainland China on a continued basis. Google and Apple app store pages say no personal data is collected or sent to 3rd parties.
Hopefully readers pick up a few tips on reversing apps for their connected devices.
Would be curious if anyone else has further insights.
[1] https://haxrob.net/fastcash-for-linux/