You can trust a platform certificate, right? Generally speaking, yes. But, as many Android OEMs recently learned, there can always be a risk of compromise. And then you are left scrambling to defend the trust or your applications. Ultimately, you are better off controlling that risk by using machine identities that you own and manage rather than platform or default certificates.
Indeed, Android OEM device vendors were probably shocked to learn that platform certificates they were using to digitally sign core system applications had also been used by threat actors to sign Android apps containing malware.
This abusive use of platform keys was discovered by Łukasz Siewierski, a Reverse Engineer on Google's Android Security team, and is now shared in a report on the Android Partner Vulnerability Initiative (AVPI) issue tracker.
According to Bleeping Computer, “If apps, even malicious ones, are signed with the same platform certificate and assigned the highly privileged 'android.uid.system' user id, these apps will also gain system-level access to the Android device.” Why is this particularly frightening? “These privileges provide access to sensitive permissions not normally granted to apps, such as managing ongoing calls, installing or deleting packages, gathering information about the device, and other highly sensitive actions.”
“This is a great example that showcases the lack of proper security controls over code signing certificates, in particular the signing keys for the Android platform,” notes Ivan Wallis, Global Architect at Venafi. “In this case, Android platform certificates made it into the wild, allowing for the opportunity for misuse and the potential to sign malicious android applications masquerading as certain “vendors”, similar to Solarwinds. Bad actors can essentially gain the same permissions as of the core service.”
At least ten malware samples have been discovered that are signed with platform keys. They are listed as follows:
- com.russian.signato.renewis
- com.sledsdffsjkh.Search
- com.android.power
- com.management.propaganda
- com.sec.android.musicplayer
- com.houla.quicken
- com.attd.da
- com.arlo.fappx
- com.metasploit.stage
- com.vantage.ectronic.cornmuni
Google advises atha all affected parties should rotate the platform certificate by replacing it with a new set of public and private keys. Additionally, they should conduct an internal investigation to find the root cause of the problem and take steps to prevent the incident from happening in the future.
"We also strongly recommend minimizing the number of applications signed with the platform certificate, as it will significantly lower the cost of rotating platform keys should a similar incident occur in the future."
“If the keys fall into the hands of an attacker it can lead to catastrophic breaches,” warns Tony Hadfield, Sr. Director of Solutions Architects at Venafi. “The only way to prevent this kind of problem is to have an auditable, ‘who/what/where’ solution that allows you to monitor and validate how you control signing keys, where are they stored, who has access to them, and which kind of code gets signed? You need this information to protect your keys and also respond quickly to a breach by rotating your public and private keys.”
The leaked platform certificates are just another reminder of why it’s important to take control of your machine identities. You never want to put yourself in a position where cyber criminals are signing code with the same machine identities that you are. At that point, who can tell your legitimate offering from malicious malware?
“The lack of the who/what/where/when around code signing makes it difficult to know the impact of a breach, because that private key could be anywhere. At this point it must be considered a full compromise of the code signing environment and key/certificate rotation must happen immediately.” Ivan Wallis, Global Architect at Venafi.
Related posts
