Google's Project Zero team investigated WhatsApp's and Facetime's video conferencing last year:
"Overall, WhatsApp signalling seemed like a promising attack surface, but we did not find any vulnerabilities in it. There were two areas where we were able to extend the attack surface beyond what is used in the basic call flow. First, it was possible to send signalling messages that should only be sent after a call is answered before the call is answered, and they were processed by the receiving device. Second, it was possible for a peer to send voip_options JSON to another device. WhatsApp could reduce the attack surface of signalling by removing these capabilities."
"Using this setup, I was able to fuzz FaceTime calls and reproduce the crashes. I reported three CVEs in FaceTime based on this work."
In both cases, the close source nature of the applications stymied their efforts.
Why do you say that? In the WhatsApp case, they were able to repeatedly modify the code and also yank it out and run it in their own controlled environment, etc.
Yeah, there's a cottage industry of security firms who sell exploits to the U.S. government directly or indirectly through big defense contractors. Many, and I personally have assumed _most_ (but without checking), are American firms.
And, frankly, the Israeli industry has much to gain by advertising their prowess in order to bolster their IT security bone fides internationally. American firms are probably more discrete, so tabulating widely published exploits by country of origin wouldn't be a great metric to determine which country is doing the most work crafting exploits.
Wow! I had no idea there was a whole industry selling spyware to dictatorships. Surveillance equipment, yes, but not actual hacking tools. Really sickening. Must be why governments in Europe are so afraid of Huawei building 5G networks - they will only run Chinese spyware.
Huawei's equipment will almost assuredly run anyone's spyware. Huawei uses a medley of ancient, highly vulnerable OpenSSL libraries sprinkled through their basestation code, and apparently they've forgone any kind of version control to ensure an optimally confusing work environment for their development teams: https://hmgstrategy.com/resource-center/articles/2019/04/04/...
Frankly, these products are likely unmaintainable long term without a total refactoring of the codebase, nevermind the abject lack of security.
The trick with these vendors is the codebase will never see serious improvement, as these basestations aren't going to be sold for the next decade, so Huawei will do the bare minimum and shelve support in short order.
It's not that much different from mercenary outfits like The Company Formerly Known As Blackwater. They offer services to all sorts of unsavory regimes. Hackers for hire are just another iteration on the idea.
It wouldn't even matter if Huawei doesn’t and has never used their position in infrastructure to conduct spying or surveillance. The very fact that they’re entirely reliant on the Chinese government makes them (and any of their employees on an individual level) vulnerable to Chinese policy needs, now or in the future.
I don't quite understand the Huawei analogy. NSO isn't partnering with Israeli companies to preinstall malware on their stuff. So I don't see how this is an indication that a Chinese version of NSO will partner with Huawei to preinstall malware on Huawei stuff. If NSO can hack American software, then Chinese NSO can hack American software too.
The Israeli military-industrial ELINT industry and C4I people sell stuff to all sorts of authoritarian regimes. Even the ones that the US and UK won't touch.
I guess these types of vulnerabilities could be placed intentionally. It would allow certain agencies to again access via "exploit" and all the while claim they support user privacy. These companies are under pressure from governments (like the recent Australian government law to requiring access to encrypted messages). Seems like a decent solution for company and governments.
The industry calls this a "bug-door" and yes, plausible deniability is key. Most of this has been hypothetical possibility. This case does not fit that bill though as the vendor discovered it was being used by another country, prevented the exploit against a user, fixed it, and alerted the authorities. Would be more peculiar if it was a US-based company selling the spyware.
There's also the curiously peculiar, and consistent, wording from companies that deny their involvement in programs such as PRISM [1]. As people seem to have forgotten about PRISM, NSA slides not meant for public consumption stated it enabled "extensive, in-depth surveillance on live communications and stored information" with examples including email, video and voice chat, videos, photos, voice-over-IP chats (such as Skype), file transfers, and social networking details.
But here's the fun part. Here are the corporate denials:
- Google: "We have not joined any program that would give the U.S. government direct access to our servers."
- Apple: "We do not provide any government agency with direct access to our servers."
- Facebook: "We do not provide any government organization with direct access to Facebook servers."
And so on. An exploit with plausible deniability enables these companies to make these comments completely truthfully, and at least mostly truthfully if they claim they are not providing a backdoor. But more to the point, there is absolutely no reason these companies would all say "direct access" as that's very specifically a subset of "access." If you do not facilitate direct or indirect access, why would you not simply say access? If this were a one-off thing, that'd be one thing since on occasion some PR is... odd. But literally all the companies were saying the exact same very peculiar thing. That's not a coincidence.
It seems to me that if this is possible an OS software upgrade of some sort is urgently required, in addition to possible updates of WhatsApp. How come there isn’t coverage of this as Android and iOS vulnerabilities?
Gaining control of WhatsApp gains access to any API accessible to WhatsApp. Incompetent reporting may be at fault.
On Android, WhatsApp seeks a wide array of permission-controlled APIs. It does so on iOS as well. Once granted, the app has access to any data available through access-allowed APIs.
App code goes through an audit process to ensure that the app isn’t using accessible APIs inappropriately, and doesn’t permit unapproved code execution.
This vulnerability allows an attacker to execute unapproved code in the WhatsApp context. Any API that iOS or Android offer WhatsApp under normal circumstances is now attacker-controlled.
The two questions unanswered by the press to date are simple. On iOS and on Android, can the attacker’s code be terminated by force-quitting and uninstalling WhatsApp?
Either the attack is persistent only because it sets up shop inside the app, which may have OS-granted background and/or screen-off execution rights, and thus can be terminated simply by quitting and removing the app — or, the attack gains persistence beyond the confines of the app.
Media reports are unclear on this point. If the OS offers apps endpoints that an app executing attacker-controlled code can use to infect the OS with persistent attack code that executes outside the app’s boundaries and remains after app uninstallation, then that’s absolutely a flaw in the design of the OS. As you say, “Android and iOS vulnerabilities”.
Very interested to know what this means in practice, particularly for iOS.
AFAIK, there's no permissions which allow you to read SMS messages, take screenshots (unless jailbroken), access photos in the background, access the camera in the background etc etc
Does this just spy on the users Whatsapp activity, or spy on the user in a broader way?
How could the API's whatsapp does have access to be abused?
CVE-2019-3568 suggests this was a buffer overflow. I'd like to understand why this was implemented in native code - Android seems to have an `android.net.rtp` package?
Is this simply for performance, or to enable code-sharing across Android and iOS? Is there anything about WhatsApp's use-case that would prevent an implementation using managed code?
Also, what exploitation mitigations are broken on Android/iOS such that a buffer overflow is reliably exploitable? Are their implementations of ASLR useless? Is it trivially bypassed? Is mandatory code-signing not enabled/enforced?
All very good questions, hopefully we can get some more information as time progresses (maybe a PoC, or at least a technical write-up on the specifics)
Readit News
Google's Project Zero team investigated WhatsApp's and Facetime's video conferencing last year:
"Overall, WhatsApp signalling seemed like a promising attack surface, but we did not find any vulnerabilities in it. There were two areas where we were able to extend the attack surface beyond what is used in the basic call flow. First, it was possible to send signalling messages that should only be sent after a call is answered before the call is answered, and they were processed by the receiving device. Second, it was possible for a peer to send voip_options JSON to another device. WhatsApp could reduce the attack surface of signalling by removing these capabilities."
"Using this setup, I was able to fuzz FaceTime calls and reproduce the crashes. I reported three CVEs in FaceTime based on this work."
WhatsApp: https://googleprojectzero.blogspot.com/2018/12/adventures-in...
Facetime: https://googleprojectzero.blogspot.com/2018/12/adventures-in...
In both cases, the close source nature of the applications stymied their efforts. Looks like NSO was willing to spend more time and resources!
Why do you say that? In the WhatsApp case, they were able to repeatedly modify the code and also yank it out and run it in their own controlled environment, etc.
That's probably what they're referring to.
https://en.wikipedia.org/wiki/Hacking_Team
FinFisher: https://en.wikipedia.org/wiki/FinFisher
MiniPanzer: https://en.wikipedia.org/wiki/MiniPanzer_and_MegaPanzer
And, frankly, the Israeli industry has much to gain by advertising their prowess in order to bolster their IT security bone fides internationally. American firms are probably more discrete, so tabulating widely published exploits by country of origin wouldn't be a great metric to determine which country is doing the most work crafting exploits.
Absolutely. The Israeli Cybersecurity brand is built partially on such (sometimes unsubstantial) PR.
The bubble is doing well though! almost 500 startups, > 1Billion$ VC funding in 2018 alone. Devs are happy.
Frankly, these products are likely unmaintainable long term without a total refactoring of the codebase, nevermind the abject lack of security.
The trick with these vendors is the codebase will never see serious improvement, as these basestations aren't going to be sold for the next decade, so Huawei will do the bare minimum and shelve support in short order.
But here's the fun part. Here are the corporate denials:
- Google: "We have not joined any program that would give the U.S. government direct access to our servers."
- Apple: "We do not provide any government agency with direct access to our servers."
- Facebook: "We do not provide any government organization with direct access to Facebook servers."
And so on. An exploit with plausible deniability enables these companies to make these comments completely truthfully, and at least mostly truthfully if they claim they are not providing a backdoor. But more to the point, there is absolutely no reason these companies would all say "direct access" as that's very specifically a subset of "access." If you do not facilitate direct or indirect access, why would you not simply say access? If this were a one-off thing, that'd be one thing since on occasion some PR is... odd. But literally all the companies were saying the exact same very peculiar thing. That's not a coincidence.
[1] - https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%...
On Android, WhatsApp seeks a wide array of permission-controlled APIs. It does so on iOS as well. Once granted, the app has access to any data available through access-allowed APIs.
App code goes through an audit process to ensure that the app isn’t using accessible APIs inappropriately, and doesn’t permit unapproved code execution.
This vulnerability allows an attacker to execute unapproved code in the WhatsApp context. Any API that iOS or Android offer WhatsApp under normal circumstances is now attacker-controlled.
The two questions unanswered by the press to date are simple. On iOS and on Android, can the attacker’s code be terminated by force-quitting and uninstalling WhatsApp?
Either the attack is persistent only because it sets up shop inside the app, which may have OS-granted background and/or screen-off execution rights, and thus can be terminated simply by quitting and removing the app — or, the attack gains persistence beyond the confines of the app.
Media reports are unclear on this point. If the OS offers apps endpoints that an app executing attacker-controlled code can use to infect the OS with persistent attack code that executes outside the app’s boundaries and remains after app uninstallation, then that’s absolutely a flaw in the design of the OS. As you say, “Android and iOS vulnerabilities”.
Is this the case?
AFAIK, there's no permissions which allow you to read SMS messages, take screenshots (unless jailbroken), access photos in the background, access the camera in the background etc etc
Does this just spy on the users Whatsapp activity, or spy on the user in a broader way?
How could the API's whatsapp does have access to be abused?
Is this simply for performance, or to enable code-sharing across Android and iOS? Is there anything about WhatsApp's use-case that would prevent an implementation using managed code?
However, two API levels of compat. seems like a good trade to me in order to avoid an RCE.
Besides, I think if it was from any other developer, probably it would be removed from the AppStore and force delete from user devices.