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?
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
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
sriram_sun|4 years ago
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
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
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
TobTobXX|4 years ago
> 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.
unknown|4 years ago
[deleted]
mvanaltvorst|4 years ago
PeterisP|4 years ago
junon|4 years ago
skybrian|4 years ago
johnchristopher|4 years ago
titzer|4 years ago
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
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
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
makeworld|4 years ago
travoc|4 years ago
rvp-x|4 years ago
underscore_ku|4 years ago
beermonster|4 years ago
avnigo|4 years ago
xnyhps|4 years ago
MoreenDichele|4 years ago
[deleted]
swiley|4 years ago
skrebbel|4 years ago
hdjjhhvvhga|4 years ago
[0] https://support.zoom.us/hc/en-us/articles/360027397692-Deskt...
Wowfunhappy|4 years ago
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.
wilde|4 years ago
wichert|4 years ago
lima|4 years ago
fancy_pantser|4 years ago
dijit|4 years ago
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
pick your poison
cle|4 years ago
unknown|4 years ago
[deleted]
StreamBright|4 years ago
What is exactly “for this”?