mrktmind My big question is if Google builds their own chips now, couldn't they just build in a hardware or hardwareish solution to keep doing what they do without Google Play Services (et al)?
Because such backdoors would be noticed and publicly known if they were to exist and because they are some of the least favourable methods of performing data collection. Reasons to disclose or expose such behaviours outweigh reasons to keep them covered up immensely. The amount of people who would task against a supposed hardware backdoor would also completely outnumber the people involved in maintaining it's secrecy.
If company X had a backdoor in a product, then most of the time it is just company X and possibly the security agencies of the nation state (and allies) where the company is based would be able to cover up the existence of it. Now, compare that to the groups of academic researchers, competitors of company X, companies hostile to company X, rogue employees of any party tasked with keeping it's secrecy, foreign intelligence hostile to the company and the country they are based in, forensics companies, mercenary spyware companies, hackers, nonprofit orgs, paranoid individuals etc. who would want to find out that there could be one.
Google or other organisations with such capabilities to make and design their own hardware wouldn't employ such a tactic because "hardware backdoors" lack any major advantage beyond having persistence on the device. There is little advantage in data collection because the operating system they created could collect just as much valuable information. Here are some other reasons:
- Malicious firmware embedded in hardware need an interface within the running software of the device to send information back to whoever is performing the surveillance and monitoring. Many cases of malicious firmware have a stage that involves using injecting malware in the operating system and making connections to a server to perform the command and control stage of a cyber attack. This connection would be needed so the C2 could recieve instructions, or for the target device to send information about itself properly. These connections can and do be monitored and those are indicators of compromise that cybersecurity threat intelligence organisations use to discover malicious firmware.
Take an example of CosmicStrand, MoonBounce, and MosaicRegressor - three examples of malicious UEFI firmware rootkits (also known as bootkits), these bootkits all share the same characteristics:
- The bootkit injects malicious software or exploits into the operating system on bootup,
- This malware makes a constant connection to a Command and Control server over the Internet, and
- The only purpose of the firmware in the attack chain is to enforce persistence (a consistent compromise of the target) during the attack.
The firmware have no direct idea on what operating system the device they are connected to is running, they have no ability to check the instructions that they are performing are actually working. What if you just ran an OS where this is just unable to run properly? What if you block the executables it generates? What if you block the C2 servers they connect to? They need an internet connection, the hardware device alone can't do that. They depend on the software and the network it's connected with to allow it, which means there are many ways to prevent such abilities.
- It is infeasible to try and perform such capabilities on millions reliably. The OS monitoring approach is more far-reaching and capable because you wouldn't only be stuck on every device that had hardware with the malicious firmware embedded. With the OS they can support any device that runs it, regardless of hardware.
Since these depend on a software to interface with, it becomes a liability. How can you update and improve your operating system in a way that keeps the supposed backdoor functional for a long period of time, without breaking it when removing legacy code that may have unnecessary security vulnerabilities? It would become a mess for the firmware developers and operating system developers to maintain.
- Malicious firmware is better for active operations, not passive data collection.
Organisations like Google collect data passively, they collect user activities automatically and what they do with such data is done with automatic systems like ads and search suggestions. In the examples linked, types of cases with malicious firmware only had a very small amount of victims because these types of setups are used by groups who were directly targeting the individuals which the threat actor wanted to monitor. Malicious firmware is a bad choice for the type of data collection Google would want to perform. They are for direct operations, similar to what intelligence agencies and agents involved in espionage may attempt to do.
In an example of intelligence agencies, they acquire and apply information aggregated from a variety of sources (quite literally defining the word intelligence), and in cases where they need to acquire information themselves where their current systems do not provide enough, an active operation like a cyberattack is where they would be useful. Malicious firmware would not even be their first choice, they would try to perform an attack on the target's device through exploitation of the software and operating system they use. They are more efficient, take less work, and end up having a far reaching impact of success.
The majority of the offensive tools uncovered in global surveillance disclosure affairs were tools meant to exploit operating systems and software (Vault 7 and The Shadow Brokers leaks are examples), malicious firmware is extremely capable, but not efficient in delivering to a target, they can't be mass deployed.
For what they may have in their arsenal in comparison, they are a extremely high-risk, but high-reward capability and requires taking extreme measures such as interdiction of a package with the target's device, performing a covert operation where they may need to sneak into their property undetected to get physical device access, or among other things.
- The reputational damage of being discovered adding backdoors in hardware firmware (which would be very easily) is too large to attempt having one
All the parties mentioned in the beginning would love to know there was such a thing in a smartphone. Foreign governments would have a field trip telling all their citizens how bad it is, or worse, they would take advantage of the security hole of Google leaving a backdoor in the operating system. The money it would take to successfully cover up would be damaging to a business. Governments or multinational orgs would likely start litigation, and so many more things.
mrktmind It was just revealed a couple of weeks ago that Apple had a hardware backdoor.
That was a trivial vulnerability caused by an undocumented feature. There is no evidence of foul play. A well-versed engineer who works on Apple products has a good explanation for how these vulnerabilities happen, and how it would be fixed: https://social.treehouse.systems/@marcan/111655847458820583
Kaspersky, who disclosed the operation involved, also made no accusations of a backdoor in any of their articles:
https://securelist.com/operation-triangulation-the-last-hardware-mystery/111669/
https://www.kaspersky.com/about/press-releases/2023_connecting-the-dots-kaspersky-reveals-in-depth-insights-into-operation-triangulation
https://www.kaspersky.com/about/press-releases/2023_kaspersky-discloses-iphone-hardware-feature-vital-in-operation-triangulation-case
mrktmind . If they did do this is there anyway to tell? We have Wireshark for wi fi - is there such a solution for cell signal?
It wouldn't be feasible for the cellular radio alone to perform data collection as it would need a software interface to know what data about the target to transmit.
Wi-Fi network traffic can be monitored by the access point of the network or even on the device itself with less scope, if it did not appear on Wireshark, it would show up on the access point providing the access point had monitoring.
Cellular networks may not be able to be administered by you as easily, but they are still networks implemented over radio communication. Anyone with radio hardware could in practice monitor the existence of cellular network activity in their nearby device, even if what they are doing cannot be read. A compromise of the operating system would also be able to tell if such a thing was happening because of the need for software.