top | item 28336109

Zoom RCE from Pwn2Own 2021

262 points| xnyhps | 4 years ago |sector7.computest.nl

122 comments

order

sriram_sun|4 years ago

FTA: "Using a combination of proxies, modified DNS records, sslsplit and a new CA certificate installed in Windows, we were able to inspect all traffic, including HTTP and XMPP, in our test environment."

I have setup wireshark for troubleshooting. That's about it. What's the role of proxies, modified DNS records etc. in this setup? How can I duplicate this?

Thanks.

e12e|4 years ago

In addition to what others have mentioned - you could probably find the session keys in ram - but for a system without debug knobs, injecting your own certificate authority is probably easier.

For stuff using nss(Firefox)/openssl/gnutls - you can usually just ask nicely for a copy:

> The key log file is a text file generated by applications such as Firefox, Chrome and curl when the SSLKEYLOGFILE environment variable is set. To be precise, their underlying library (NSS, OpenSSL or boringssl) writes the required per-session secrets to a file. This file can subsequently be configured in Wireshark

https://wiki.wireshark.org/TLS#TLS_Decryption

https://gnutls.org/manual/html_node/Debugging-and-auditing.h...

1vuio0pswjnm7|4 years ago

With DNS one can avoid having to use the firewall for redirection

sslsplit documentation actually suggests DNS as an alternative to using firewall

Theres a number of easy-to-use UNIX firewalls. Not sure about Windows

Proxies allow easy inspection of HTTP traffic, among other things. Arguably sslsplit is itself a proxy, specifically a forward proxy

There are many ways to monitor HTTP traffic. More than one way to do it

Why doesnt Zoom use certificate pinning

(I avoid using sites/apps that force use of third-party controlled pinned certificates. What are they trying to hide from the user)

xnyhps|4 years ago

The HTTP and XMPP traffic is encrypted using TLS. The proxies were used to decrypt, log and re-encrypt this traffic in real-time.

TobTobXX|4 years ago

Not entirely sure if this I'm understanding this correctly (since it doesn't really make sense to me), but this is what they wrote almost at the end:

> Anything we did differently could influence the heap layout. For example, we noticed that adding network interception could have some effect on how network requests were allocated, changing the heap layout.

mvanaltvorst|4 years ago

It blows my mind that there are people who manage to find exploit chains like these, amazing job!

PeterisP|4 years ago

The article goes into detail on how much trial and error effort it goes into making such an exploit chain - approximately two months work each for two people. Even for other people who have the required skills, making such a time investment - with no certainty of succes or reward - is a big barrier. Perhaps the math works out differently for blackhats as the payoff is larger and perhaps more certain if they do get to a working exploit.

junon|4 years ago

This is generally through the use of (often custom) analyzers. I would wager, though I have little empirical evidence, that most non-trivial zero days of large software like this are not strictly manually discovered.

skybrian|4 years ago

This presumably doesn't apply to the web app, which is the only way I've used Zoom.

johnchristopher|4 years ago

Are there any cases or instances of secrets leaking from a zoom meeting through hacking ? Specifically from audio and video, not chat ?

titzer|4 years ago

> This meant that by sending a ResponseKey message with an AES-encrypted <encoded> element of more than 1024 bytes, it was possible to overflow a heap buffer.

This is what I was looking for. Fundamental bug was an overflow of statically-allocated buffer leading to heap corruption.

We gotta get off memory-unsafe languages.

dvt|4 years ago

> We gotta get off memory-unsafe languages.

You read this whole post and that's what you got? Just the fact that this includes a heap grooming step should be pretty telling that it's not very reliable and that it can easily be broken (it probably won't work if you try it after the next Win10 update).

I mean, yeah, sure, buffer overflows are bad, but this is an extremely sophisticated attack that relies on like a zillion moving pieces, of which "memory-unsafe languages" are basically a footnote. Props to the dedication and expertise of the security researchers.

Popegaf|4 years ago

That's going to take a while. But at least the linux kernel is starting to integrate Rust. It's doubtful they'll rewrite the whole thing in Rust, but getting it in there is a start.

I know the Chromium team was considering switching to Rust too, but who knows if that's ever going to happen. IIRC Chromium has more LOC than the linux kernel.

UncleMeat|4 years ago

Yup. I wouldn't hate it if it were illegal to write new applications that processed untrusted input in memory-unsafe languages, at least in the not too distant future. The fact that the industry doesn't see this as an urgent need is just embarrassing.

makeworld|4 years ago

This is why I only run Zoom in Firejail.

travoc|4 years ago

I just decline Zoom meetings while politely saying “our cyber security division does not allow us to use Zoom.” Then send an alternative invitation. So far it seems to work just fine.

underscore_ku|4 years ago

i run the snap Zoom on Ubuntu

beermonster|4 years ago

Although they don’t make it easy to find the link, you can use Zoom in a browser which is the best way of limiting the damage it can cause if you have to use it in the first place.

avnigo|4 years ago

Anyone know what logging/printing library exploit.py is using in that first embedded video?

swiley|4 years ago

No one should be installing native apps for this now that we have WebRTC.

skrebbel|4 years ago

To be frank, if Zoom was a web only app (or maybe web plus web-in-a-electron like eg Slack and WhatsApp) there'd be a vocal HN crowd complaining that there was no proper native app.

Wowfunhappy|4 years ago

All of the apps that use WebRTC seem to have worse quality and latency than Zoom. Including the semi-hidden web version of Zoom.

This could just be a coincidence, but I suspect it's not. For all of its faults, Zoom calls are just much better than all of the other mainstream solutions I've tried, particularly with large groups.

wichert|4 years ago

WebRTC still requires you to implement your own signalling layer, which is where most of these problems occur. Using XMPP for signalling in combination with WebRTC is very common.

lima|4 years ago

Unfortunately, Zoom deliberately cripples their web app to the point of being unusable. If your employer uses Zoom, there's no way to avoid the native app.

fancy_pantser|4 years ago

There's a YC company that tries to make starting and scaling WebRTC super easy, which is far from trivial for a variety of clients/browsers or with 5+ participants simultaneously: https://www.daily.co

dijit|4 years ago

One company has piss poor security; but there have been hundreds of native apps doing teleconferencing before, which were native.

Nothing to do with native or not; and pushing everything to a web-browser makes a really complicated bit of software with weird quirks and potential hidden bugs. Yes it’s more tested, but when your code paths are literally infinite- “more eyes” isn’t going to help.

shp0ngle|4 years ago

Zoom is much faster, especially on older PCs, than Teams or (especially) Google Meet, because it’s native

pick your poison

cle|4 years ago

So browser sandboxing? Is that fundamentally different from native sandboxes like snap, flatpak, et al?

StreamBright|4 years ago

>> for this

What is exactly “for this”?