[HN Gopher] Exploiting Android Messengers with WebRTC
___________________________________________________________________
Exploiting Android Messengers with WebRTC
Author : alicewonderland
Score : 91 points
Date : 2020-08-07 16:42 UTC (6 hours ago)
(HTM) web link (googleprojectzero.blogspot.com)
(TXT) w3m dump (googleprojectzero.blogspot.com)
| oyebenny wrote:
| For pentesting purposes, can someone give me a guide on how to
| test this exploit?
| cjbprime wrote:
| You'd have to completely reproduce the research in the blog
| post.
| nickphx wrote:
| Article contains link to CVE with POC(s)..
| cameronbrown wrote:
| Desktop version:
| https://googleprojectzero.blogspot.com/2020/08/exploiting-an...
| ardy42 wrote:
| Title is misleading. The actual article headline is "Exploiting
| Android Messengers with WebRTC: Part 3"
|
| Also, this exploit didn't just affect Signal (it affected Google
| Duo too, for instance), and it appears this has already been
| patched in Signal:
|
| > This exploit was performed on Signal 4.53.6 which was released
| on January 13, 2020, as Bug 376 had already been patched in
| Signal by the time I finished the exploit. CVE-2020-6514 was also
| fixed in later versions, and ASCONF has also been disabled in
| usrsctp, so the code that caused Bug 376 is no longer reachable.
| Signal has also recently implemented a feature that requires user
| interaction for the WebRTC connection to be started when the
| caller is not in the callee's contacts. Signal has also stopped
| using SCTP in their beta version, and plans to add this change to
| the release client once it is tested. The source for this exploit
| is available here.
| upofadown wrote:
| From the article:
|
| >WebRTC does not pose a substantially different risk than other
| video conferencing solutions, but the decision to include video
| conferencing in an application introduces a large remote attack
| surface that wouldn't be there otherwise.
|
| Adding features pretty much always takes away from security. This
| seems to be a pretty good example of the principle.
| Sean-Der wrote:
| One thing to note is that this is an issue in Google's
| implementation of WebRTC. I wish the marketing gimmicks would
| stop and they would acknowledge outside efforts. Stuff like this
| hurts the perception of WebRTC which is a shame.
|
| We are seeing more and more memory safe implementations of
| WebRTC. So I really think there is light at the end of the
| tunnel!
|
| * https://github.com/pion/webrtc
|
| * https://github.com/shinyoshiaki/werift-webrtc
|
| Chromium itself sees constant CVEs so I don't think this is a
| WebRTC specific issue. Documents like
| https://www.chromium.org/Home/chromium-security/memory-safet...
| give me hope.
| bawolff wrote:
| What marketing gimicks do you mean?
| tptacek wrote:
| One question this whole saga raises with me is why WebRTC bothers
| using SCTP for this corner case of the protocol suite at all. It
| seems like _a lot_ of complexity to add, for marginal benefit.
| Sean-Der wrote:
| DataChannels themselves are hugely important. Projects like Tor
| Snowflake and WebTorrent really inspire me.
|
| I don't think there was really an alternative at the time if
| you wanted feature rich DataChannels. Maybe we could stuck with
| the simpler RTP Datachannel. All that conversation was before I
| was aware of WebRTC though.
|
| I personally don't find SCTP that complex. You can implement a
| basic version pretty easily. Implementing the full spec is
| overwhelming for sure. I feel pretty confident saying any
| alternative protocol that is feature rich written in C/C++ will
| have issues as well.
| tptacek wrote:
| Can you say more about how DataChannels are "hugely
| important" to the common-case use of WebRTC? Adding a whole
| additional (complicated!) transport protocol just to get
| WebTorrent seems like the definition of "marginal returns".
| Sean-Der wrote:
| In 2018 Google claimed they were seeing 3 Petabytes weekly
| from DataChannel usage. This is from the 2018 KrankyGeek
| talk.
|
| For me personally I use DataChannels pretty extensively for
| Teleoperation work. Also project like
| https://github.com/nurdism/neko and
| https://github.com/giongto35/cloud-game are pretty
| compelling.
|
| 3 out of 8 'official use cases' depend on it.
| https://www.w3.org/TR/webrtc-nv-use-cases/ as well.
|
| Oh I also think great for E2E security. It is better to
| exchange metadata and keys via a DataChannel. If you push
| that stuff through signaling there is a good amount of
| information leaking.
| tptacek wrote:
| The question isn't why WebRTC has a DataChannel feature.
| It's why the DataChannel feature is as complicated as it
| is. Why not just use UDP? What's the return on all the
| complexity the protocol suite is spending?
| Sean-Der wrote:
| Ah, sorry missed the question :(
|
| I think just so users don't have to solve the same
| problem themselves. SCTP gets you multiple streams and
| they can be ordered/reliable if you want.
|
| The congestion control is pretty impressive. You can jump
| the TSN forward if you send a bunch of data but lose one
| Datagram in the middle. Cool stuff like that.
| tptacek wrote:
| That's why literally every feature exists. The question
| is what the return on that feature is. If most
| applications don't get any value from the additional
| complexity of SCTP, and SCTP itself causes implementation
| flaws that harm users, the feature is not benign.
| strbean wrote:
| Having an unreliable transport option is essentially for
| real time networked multiplayer games.
|
| But really, why the hell did it have to take almost a
| decade to get data channels, when you could jump through a
| bunch of hoops and essentially build a software dial up
| modem and transmit data over audio streams? Reminds me of
| the "minutes vs. texts vs. data" billing nonsense with cell
| phones. You trying to tell me audio and video aren't data?
| tptacek wrote:
| Sure, which is why games tend to use UDP for this. UDP is
| much simpler than SCTP, and, more importantly, it's
| already built into the stack.
| cjbprime wrote:
| Yeah, I think it's actually the reverse: the SCTP is
| being tunneled inside UDP anyway, and adding in SCTP
| allows for a _reliable_ channel to be built on top of the
| unreliable primitive. i.e. SCTP is used by DataChannels
| to add the option of reliable transport (and congestion
| and flow control) to them.
| tptacek wrote:
| SCTP doesn't simply add reliability; you can get
| reliability from UDP trivially.
| Sean-Der wrote:
| I really don't think it is that trivial!
|
| * SCTP allows multiple independent streams
|
| * Each streams have different rules on
| reliability/ordering
|
| * SCTP does congestion control and reports back to the
| user your estimated bandwidth so your application can
| change what it is doing.
| tptacek wrote:
| Yes, those are all features beyond reliability. If all
| you need is reliable transport of some sort, you don't
| need these.
|
| If all we can do is list reasons why SCTP is an
| interesting and useful protocol, we're at an impasse,
| because I like SCTP. I just don't know that it belonged
| in this design, where most applications that want WebRTC
| for simple use cases are paying a complexity and security
| cost to make it simpler (not even "feasible", just
| "easier") to build things like WebTorrent.
| Sean-Der wrote:
| Ah ok. So the question is more 'does WebRTC need the
| complexity'. I think so, reliable transport is pretty
| useless without backpressure.
|
| So here are the recent projects I have worked with that
| need the complexity.
|
| * Teleoperation - Robot control went over reliable
| stream. Metadata goes over lossless stream, we don't care
| about sensor readings 3 seconds ago.
|
| * File Transfer - If you send too fast you will cause
| complete loss. You also need to measure constantly since
| link quality will fluctuate.
|
| * Large Image Transfer - SCTP also handles breaking up
| messages to fit MTU. If you just send UDP Datagram you
| need to probe how big of packers you can actually send.
|
| * Unreliable Large Image Transfer - If you don't care if
| an image arrives and you lose packet 1 you shouldn't send
| the rest of the Datagram. This was big for a project,
| saved a lot of bandwidth making sure we didn't complete
| corrupted messages.
| tptacek wrote:
| These are all extreme niche cases for WebRTC, aren't
| they? Niche, here, relative to _actual usage_ , not
| "number of apps".
|
| If the overwhelming majority of daily invocations of
| WebRTC protocols is due to simple videoconferencing
| applications, and all those invocations have to pay a
| complexity and security tax in order to potentially
| enable someone else's "teleoperation", that's a
| misallocation, isn't it?
| strbean wrote:
| But we didn't have _any_ option to use UDP from the web
| stack prior to Data Channels.
|
| I guess worries about security trump "make the web stack
| do everything" though.
| tptacek wrote:
| I'm not debating whether Data Channels are useful. I'm
| debating whether they should be backed by SCTP.
| cjbprime wrote:
| It's especially odd since WebRTC DataChannels actually use
| SCTP-tunneled-inside-UDP, rather than router-level SCTP
| datagrams.
| Sean-Der wrote:
| I think the big piece is DTLS here.
|
| * OpenSSL was already in all the browsers, so you have a DTLS
| client.
|
| * Extracting the keys for SRTP gives you PFS, which is really
| great! This came up a lot during the SDES conversations.
|
| * I have heard that most gateways only support UDP/TCP, and
| other protocols aren't going to happen. That is the argument
| for running QUIC over UDP (vs a layer lower)
| rjsw wrote:
| The comments in the Firefox WebRTC code state that this is
| because firewalls can't do NAT of SCTP connections. I'm part
| way through adding this to the firewall that I use.
|
| On FreeBSD, WebRTC implementations could use the kernel stack
| as it implements SCTP-in-UDP (RFC6951).
| Sean-Der wrote:
| For WebRTC SCTP is over DTLS (which is over UDP) so I don't
| think that would work.
|
| Never done 'native SCTP' before so I don't know for sure!
| aneutron wrote:
| > Facebook Messenger downloads these libraries dynamically as
| opposed to including them in the APK, so it is difficult to
| identify the version I examined, but it was downloaded on June
| 22, 2020.
|
| This right here, is something that scares me. I wonder if this
| would fly on Apple's AppStore for example. Because there's
| virtually no way to attest to the application's binaries (for
| example for forensic purposes), and it can easily be used to
| backdoor the app on the fly.
| arusahni wrote:
| B-b-but Project Zero only targets non-Google properties!
| Dunedan wrote:
| According to the blog post not only Signal, but multiple
| messengers were affected. Therefore the official title is more
| accurate: "Exploiting Android Messengers with WebRTC"
| tpush wrote:
| Yeah, the title should be changed.
| dang wrote:
| Fixed. Thanks!
|
| (Submitted title was 'Project Zero Released a Zero-Click
| Exploit for Signal')
| cptroot wrote:
| Worth noting that several of the bugs this exploit depends on
| were fixed earlier this year.
| est31 wrote:
| They were but fixes didn't make it downstream.
|
| > This research showed that many applications fall behind with
| regard to applying security updates to WebRTC. Bug 376 was
| fixed in September of 2019, yet only two of the 14 applications
| analyzed had patched it.
___________________________________________________________________
(page generated 2020-08-07 23:00 UTC)