[HN Gopher] Zoom RCE from Pwn2Own 2021
___________________________________________________________________
Zoom RCE from Pwn2Own 2021
Author : xnyhps
Score : 158 points
Date : 2021-08-28 06:43 UTC (16 hours ago)
(HTM) web link (sector7.computest.nl)
(TXT) w3m dump (sector7.computest.nl)
| sriram_sun wrote:
| 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.
| 1vuio0pswjnm7 wrote:
| 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)
| Wowfunhappy wrote:
| Certificate pinning makes it impossible to examine what the
| software on my own machine is sending over my network! Please
| don't do that.
| fn-mote wrote:
| Isn't certificate pinning what keeps my employer from
| MITM'ing my personal email session on their network?
| 1vuio0pswjnm7 wrote:
| As an employer I would prefer employees not to use the
| corporate network for personal email. The network exists
| for business use.
|
| As an employee I prefer not to use the corporate network
| for truly personal email.
|
| If I am the employer that responsibly monitors the
| traffic to and from our network, including TLS traffic,
| an employee that uses our network for personal use with a
| surveillance "tech" company service such as Google Mail,
| Facebook, etc. is putting her own privacy at risk.
| Because I can extract her cookies from the traffic, all
| she has to do is forget to log out once and I now have a
| "bearer token", i.e., a cookie^1, with no expiration,
| that lets me access her account at any time in the
| future.
|
| 1 The type of cookie that lets users stay "logged in"
| indefinitely. A non-"tech" company with sufficient
| legitimate sources of revenue besides online ads may not
| use such cookies. For example, if an employee logs in to
| her personal bank account using the corporate network but
| forgets to log out, the bank website will log her out
| automatically, the cookies will expire.
| EvanAnderson wrote:
| No. Your employer can't MITM your personal email session
| if you don't trust their MITM proxy's CA.
| PeterisP wrote:
| Basic TLS is sufficient to stop your employer from
| MITM'ing your personal email session as long as you
| control what certificates your machine trust.
|
| Certificate pinning is what protects the main sites (who
| use pinning) from an advanced attacker or a rogue
| government who are able get a proper CA to issue fake
| certificates.
| Silhouette wrote:
| _Basic TLS is sufficient to stop your employer from MITM
| 'ing your personal email session as long as you control
| what certificates your machine trust._
|
| Which, on almost any employer-issued device on a large
| corporate network today, you won't.
|
| Personal stuff goes on personal devices with personal
| connectivity and uses personal accounts with personal
| security. Work stuff goes on work devices with work
| connectivity and uses work accounts with work security.
| Contaminating either with the other is just a recipe for
| bad things happening, often for both the employer and the
| employee.
| e12e wrote:
| 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...
| xnyhps wrote:
| The HTTP and XMPP traffic is encrypted using TLS. The proxies
| were used to decrypt, log and re-encrypt this traffic in real-
| time.
| jraph wrote:
| And the new certificate and DNS records are to make the proxy
| look legit to the Zoom client, which would otherwise not
| accept TLS connections. Especially if there are DNS records
| which specify which CA is used for the certificate.
| tialaramex wrote:
| > Especially if there are DNS records which specify which
| CA is used for the certificate.
|
| If you're thinking of CAA, those records are _not_ for
| anybody except the CAs. They 're an indication to the CA
| "You may/ may not issue for these names" and explicitly
| _never_ an instruction to clients about what 's
| trustworthy.
|
| It's unusual but completely sound to have CAA set to forbid
| all CAs, switch it to allow just one CA, get a certificate
| issued, then put it back to blocking them all again for a
| week or months. I'm not recommending that procedure, but
| it's sound and if any software can't handle that the
| software is broken.
|
| The idea here is that all the public CAs are _trustworthy_
| but their procedures may not be a good match to your
| particular way of doing things. For example if a CA does
| ACME http-01 proof-of-control (like Let 's Encrypt) and you
| let customers run arbitrary stuff on port 80 on your
| machines that's a bad combination, probably you should get
| your certificates from a CA which doesn't use ACME http-01
| and restrict CAA.
| [deleted]
| skybrian wrote:
| This presumably doesn't apply to the web app, which is the only
| way I've used Zoom.
| johnchristopher wrote:
| Are there any cases or instances of secrets leaking from a zoom
| meeting through hacking ? Specifically from audio and video, not
| chat ?
| swiley wrote:
| No one should be installing native apps for this now that we have
| WebRTC.
| hdjjhhvvhga wrote:
| Define "this". The web app has less features[0] and you might
| be forced by your employer to use a feature that doesn't exist
| in the web version.
|
| [0] https://support.zoom.us/hc/en-
| us/articles/360027397692-Deskt...
| wichert wrote:
| 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.
| Wowfunhappy wrote:
| 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.
| skrebbel wrote:
| 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.
| thayne wrote:
| In my personal opinion, open source native app > web app >
| closed source native app
| koolba wrote:
| Last I checked you didn't have to install anything. I'm not
| sure about more advanced usage like screen sharing or how
| many timing options their are, but for generic "see me, see
| you" it works fine in the browser.
| brundolf wrote:
| It does have a web app, but they make it incredibly hard to
| find. I'm not surprised that some don't even know about it
| koolba wrote:
| Indeed, IIRC, you need to click "download", reject the
| download, and then an " _Open in your browser_ " dialog
| appears.
| OJFord wrote:
| IME, my video always shows as either blank white, or
| psychedelic light show.
|
| Android app works.
| edoceo wrote:
| There was a setting they had, so the Bowser option is
| shown right away (well, after the xdg-open prompt)
| wilde wrote:
| WebRTC has had plenty of implementation issues.
| https://googleprojectzero.blogspot.com/2020/08/exploiting-an...
| supervisual wrote:
| There's a difference between Android native bugs and forgoing
| protection provided by browser on desktop instead of relying
| on Native apps.
| wilde wrote:
| The browser is also a native app.
| https://googleprojectzero.blogspot.com/2018/12/adventures-
| in...
| cle wrote:
| So browser sandboxing? Is that fundamentally different from
| native sandboxes like snap, flatpak, et al?
| watermelon0 wrote:
| Browser sandboxing is more battle tested, and probably a lot
| more researched, and with more fuzzing performed on it.
|
| I know that at least X11 is not sandboxed with
| snap/flatpak/etc., and there is no sandbox for macOS/Windows
| Zoom client, so using web client is infinitely more isolated.
| fancy_pantser wrote:
| 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
| lima wrote:
| 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.
| wereHamster wrote:
| lol we use Zoom for most of our meetings and I always used
| the web app, without any issues.
| meibo wrote:
| Sitting in a meeting and saying a few words is like 10% of
| what Zoom can do - there's webinars, breakout rooms, Q&A,
| polls, moderation, and a lot of other smaller features
| which are incomplete or unavailable on the web client.
| brundolf wrote:
| That's why I keep it quarantined to my work computer. If
| friends/family want to use it, I use it on there.
| [deleted]
| dijit wrote:
| 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.
| StreamBright wrote:
| >> for this
|
| What is exactly "for this"?
| jchw wrote:
| I'd assume teleconferencing. And tbh, I'm not sure I
| disagree. WebRTC has some issues and certainly isn't the
| greatest, but it feels like every teleconferencing solution
| goes through basically the same problems over and over again.
| I know some swear up and down that Zoom is better than any
| WebRTC solution and I am going to have to hard disagree, it
| has a larger featureset than say, Google Meet, but I don't
| know anyone in my current org that isn't disappointed in
| Zoom's reliability or security issues. In my case the
| security issues I've personally heard of are less serious
| (mostly random people somehow getting into meetings -- never
| witnessed that with Meet or anything else for that matter)
| but to be honest, I have zero trust in Zoom. If I could run
| it with _less_ privileges than a browser tab I would.
|
| I'd really prefer a world where people don't _have_ to deeply
| distrust software, but still adhere to principle of least
| privilege where it is reasonable to do so. I feel like if I
| have to install software natively, it better be software with
| a decent track record from a trustworthy team. However we're
| really at a worst of both worlds situation with Zoom. I don't
| trust it at all, and it gets a ton of privileges that are
| only checked in the sense that there might be some scrutiny
| from researchers.
|
| Not saying I never had issues with the WebRTC solutions, but
| honestly, at worst I just found myself refreshing the tab and
| going on my way. Meanwhile I've been warned against even
| trying Zoom for Linux as apparently it makes the old Skype
| for Linux look like a solid product.
| mvanaltvorst wrote:
| It blows my mind that there are people who manage to find exploit
| chains like these, amazing job!
| makeworld wrote:
| This is why I only run Zoom in Firejail.
| rvp-x wrote:
| FWIW it's possible to run Zoom in a web browser, but they make
| it annoying. https://techcrunch.com/2020/03/20/psa-yes-you-can-
| join-a-zoo...
| underscore_ku wrote:
| i run the snap Zoom on Ubuntu
| dmurray wrote:
| Is that more secure? Snaps seem to be shit for performance,
| so I avoid them by default, but maybe I should be favouring
| them when I have security concerns.
| danielheath wrote:
| By default (without ---classic) on install) they run in a
| chroot. Makes saving files sent to you a hassle as it can't
| write to your downloads directory.
| travoc wrote:
| 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.
| puszczyk wrote:
| What do you recommend to use instead?
| thayne wrote:
| Doesn't work so well when your security team are the ones
| mandating you use zoom.
| titzer wrote:
| > 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.
| UncleMeat wrote:
| Yup. I wouldn't hate it if it were _illegal_ to write new
| applications that processed untrusted code 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.
___________________________________________________________________
(page generated 2021-08-28 23:00 UTC)