Intercepting Zoom's encrypted data with BPF | Hacker News Reader

Intercepting Zoom's encrypted data with BPF

confused.ai

265 pointsaaron-santos65 comments

But how do we find the offsets? What values do we give to ssl_read_offset and ssl_write_offset?
[ REDACTED ]

I had a nice little section on how to find the offsets here. When I first wrote it I was convinced that publishing two addresses couldn't possibly get me sued for reverse engineering. Some of the people who read the draft of this post changed my mind about it though, and it is 2020 after all so it is not a good time to be optimistic.

So, how would you find these offsets? Anyone know?

It's probably the most interesting part of the post.

There's a "hypothetical" paragraph afterwards, but if anyone wants to actually do this with Zoom and post the results, you'd probably earn lots of cred.

In particular, the exact arguments to the objdump command would help.

It is sad they felt the need to do this. This step is not hard, but censuring it because of hypothetical legal issues speaks a lot about the state of affairs on computing.

I miss the good old times where knowledge were freely published without fear.

Do note that this is generally not something that would be a legal issue.

> Some of the people who read the draft of this post changed my mind about it though

Details? Reverse engineering isn't even illegal.

Since the Zoom TOS explicitly forbid reverse engineering, sadly it isn't so easy.

TOS can't substitute to the law. Reverse engineering is legal by law depending on the jurisdiction.

But if you’re using Zoom for work, they can still ban your account and/or company.

Then use Jitsi, or something.

Sure, but if your 1000 person company uses Zoom and Zoom only bans your account I don’t think you can convince a company to switch clients. That said I find that specific scenario unlikely.

It's no problem. The company can contact zoom support and get your account unlocked.

Random companies can't make new law. If you violate their TOS the most they can do is refuse you service.

Or sue you, which is likely with shady companies such as Zoom.

No idea why you're being downvoted but this is 100% factually correct in the US: you'll get sued by a company that has a very salaried legal team.

Even if Zoom is in the wrong/has no case, all it takes to "win" in the US is enough of a bankroll to troll someone via the legal system. It's pay-to-play here and Zoom likely has the budget to run an independent researcher into the ground financially with legal defense fees alone.

I get that HN wants to have it's "hacker" ideals and all, but, I would expect to cause myself legal troubles for publishing security details on such a service (unless done anonymously with reasonable opsec).

Thank you I can't believe this had to be said explicitly.

I might misunderstand the fundamental point, but zoom doesn’t seem to be making new laws. Existing contract law is perfectly capable of handling two adults agreeing to a mutually beneficial set of restrictions.

Lots of things that are legal we’ll be restricted in contract agreements - free speech is a fundamental right, but mutual non-disclosure agreements still exist and can result in (civil) legal action if reneged on to one party’s detriment.

What's the point of giving people rights when companies can just force you to relinquish them via contracts? That obviously leads to these "you can't exercise your rights" clauses becoming standard in every contract.

People should be able to do things that hurt a company's business interests, especially reverse engineering. They do not deserve any protection. Actually, it should be encouraged since it leads to better products for consumers.

When you sign a contract, very often you are waiving some of your rights. There are rights which cannot be waived by you—I’m not sure the right to reverse engineer is one of them

You never have to sign any TOS when reverse engineering, ergo no contract.

you probably sign TOS as part of the installation of the binaries

clicking a button != signing your name

> Existing contract law is perfectly capable of handling two adults agreeing to a mutually beneficial set of restrictions.

I think you'll find that most people - and a number of leading law experts - don't consider click through EULAs for valid binding contracts and clicking next is not the same as signing.

You'll also find that many (most? I stopped reading EULAs years ago) contains something about "the following might not be applicable in your jurisdiction".

Besides, just think of it: can a click on a button, placed in a way that makes it easy to click through for someone who accepts the defaults, can such a click really be considered a meeting of minds?

And do we really think people can be expected to read a number of pages of dense legalese? I remember one EULA filling 13 A4 pages with text in a small font after I gave up and printed it two decades ago when I was young and still believed they were valid.

Besides: Expecting non lawyers to read and understand legalese is as crazy as expecting non programmers to read basic Java or Python: within reach for many after basic self study, but still not something I'd bet much money on random people being able to do on the fly.

> I think you'll find that most people - and a number of leading law experts - don't consider click through EULAs for valid binding contracts and clicking next is not the same as signing.

If you feel like you're potentially a target of a lawsuit, the only opinion that should matter to you are your lawyer's and the the court's. Some EULA restrictions are not enforceable, but some definitely are. No US court has ruled on whether EULAs are binding, or not - so there is no precedence.

There is a certain asymmetry in it, but you can also sue and have shit like that declared illegal. Thing is it would threaten most bizniz-models of the bullshit economy, so it doesn't happen that much.

I'm expecting that this finally changes for the better, at least in some parts of the world, where the parts which don't adapt to that change spiral further down.

Rightly so!

These days that could actually be a significant problem, depending on your work.

ToS aren't important if they're not enforceable, which is the case with a prohibition on reverse engineering. That said, if I published something like this I'd do it under a pseudonym under a domain and a vps that I paid for using an untraceable currency. Companies are evil and even if you'll eventually win, they'll make your life miserable. Why take the chance?

We know the exact version of openssl they’re using, so we can just build the same version ourselves, get the address of the functions, and look for the same pattern of instructions in the Zoom binary. Not sure if LTO could break this or not though.

That seems pretty unreliable. The specific version of the compiler used, as well as flags passed to the compiler, could easily change the instructions used, no?

That was just the quick and naive way I went for because I didn't want to download new tools, but there's many other options.

The easiest way if you have a capable debugger is probably to look for SSL strings/error codes in rodata and see where they're referenced.

Or IDA can even output C code that is very close to the original.

Based on how the OP described finding the offsets, it sounds like this is exactly what they did, perhaps there are some obvious sentinels that make it easy. I’m not a C expert, but I think a function call w/ args has a pretty standard way of being executed and if you know the types of the arguments it’s possibly even easier?

ABI compatability baby. Those signatures gotta match up for sure. Once you have that, the underlying guts of the code wont matter so much.

If this was 32 vs 64bit or some such you'd be pretty hosed at where everything was I imagine.

Boom. ABI that’s the word I was thinking of. Thanks!

It's pretty reliable in reality, C compilers are actually quite predictible. The only meaningful changes compilation flags do is add/remove basic blocks.

That's also mainly how malware reverse manages to "hunt" APT families, by finding meaningful little patterns in the instructions and look for code reuse in other binaries :D

Generally it's a little bit more manual than "pass flags to objdump"–I'd look for strings and such used by the function in the open-source release and then cross-reference that.

I was surprised to see hooking code like this being written in Rust. I've come to expect C sample code for purposes like these, so it's nice to see that there are actually alternatives when it comes to intercepting function calls and extracting data from a process.

Other options include bpftrace[1] or C, Python or Lua via BCC[2]

1: https://github.com/iovisor/bpftrace

2: https://github.com/iovisor/bcc

Lua is the most common language I had never heard about before dealing with BPF. It gets embedded in a surprising array of technologies.

That's most of what lua's purpose is: to be a reasonably pleasant and featureful language that is dead easy to embed in larger systems that want some kind of scripting or macros.

I think what makes redbpf stands out is that the other libraries allow you to write the user-space code in Python or Lua etc, but then the kernel code must still be written in C and gets compiled with clang.

In redbpf we let you write the kernel code in Rust as well, and then we have our own LLVM based toolchain to compile that to BPF bytecode.

bpftrace is similar to redbpf in approach, in that it lets you use a DSL instead of C.

When you get past the layers of old and dead documentation around it, the eBPF subsystem is fairly easy to target as long as you can call C, topologically at least.

The people from Cilium (the k8s service mesh) launched this website[0] recently that lists a few tools from the landscape, and I also had the same pleasant surprise to find these things out this week

I thought we were still tied to `bcc` and that python frontend thingy, but I'm glad the ecosystem has evolved significantly while I was not paying attention! It's kinda like finding a $20 in your back pocket that you didn't know was there when you put your pants on...

[0] https://ebpf.io/

I have done exactly the same thing for Desktop/Android apps using Frida (modified from https://github.com/google/ssl_logger). There are modules out there that dump SSLKEYLOG too (that can be used in Wireshark)

With IOS I’ve used the keylog strategy and it is very effective. IOS uses boringssl and the library calls a function to log the secret but this function never does anything normally. However, you can either trampoline this function to log the secret or modify the ssl context to add your own logger function. This is all public knowledge and you can find Frida scripts that will dump the TLS secrets.

And this can be used to defeat certificate pinning?

I just realized you would just be sniffing the data unencrypted rather than setting up any proxy or root cert, so this question doesn't make sense.

This is very cool. I've always wanted to do something like this. I hope to use snuffy in the future. Thanks for the great walk through!

Glad you liked it!

Awesome post Alessandro! Well written and in tutorial format. Much respect! I know what I'll be playing around with this weekend.

I will be looking forward to more blog posts of yours in the future.

Thank you! Mind I only tested on latest ubuntu and fedora so feel free to DM me on twitter if you run into issues.

Something like this needs to be included in tcpdump or Wirshark. (tcpdump would be fitting; since it was the genesis for cBPF)

I remember patching Netty https://github.com/netty/netty/pull/8653 just to get the master key in order to decrypt sessions.

Having the ability to decrypt TLS sessions like this is way simpler.

tl;dr; would love to see something like this for tshark / tcpdump

Wireshark does support TLS decryption if you provide a "key log file": https://wiki.wireshark.org/TLS#TLS_Decryption

Perhaps OP's technique could be used to generate such a file.

EDIT: I see you have already investigated such methods after looking at your github link.

I am not sure how much of this technique can be used elsewhere for legitimate purposes.

In this example, except for an administrator spying on other users on a shared machine, which is kind of already an admitted risk by users on a shared machine anyway.

> I am not sure how much of this technique can be used elsewhere for legitimate purposes

...as a Linux systems engineer, you are many times faced with debugging a black box problem wrapped in SSL on both ends which you need to peek into to understand what's going wrong; there is nothing suspect about this technique in this environment, it's what you're paid to do (solve problems). It's basically like having the ability to elevate your NIC port to promiscuous mode to debug an issue (tcpdump, e.g.) - it's a tool with no opinion, the human operating it is the one to be worried about.

Looks like nextgen ad blocking to me. If you can instrument TLS connections on the client, you can identify ad content and substitute blank video frames or just 404s.

Writing a toy ad blocker is actually on my todo list :)

There's just so many things you can so. The original goal of the post was to tamper with zoom's attention tracking for example (which was a field in one of their protobuf payloads).

Proxomitron had that capability years ago - MITM proxy to filter pages and block ads, among other things. I still use it, it's very useful and continues to run fine on the newest Windows.

It's useful to a security researcher or privacy advocate looking into what an application like zoom is actually sending around.

It may be also helpful when reverse engineering "proprietary" protocols, e.g. to create compatible clients.

It may be even easier to just "mitm" the traffic like this in applications you develop yourself to find out what going on deeply buried in some third party library. Easier than modifying the code or attaching a normal debugger.

There are plenty of legitimate uses.

This is very much a research technique and not an operational kind of thing.

> This is very much a research technique and not an operational kind of thing.

It's very much an operational kind of thing if you are trying to troubleshoot a thorny issue with your app in production.

Looking at the data our machines are sending over the network is perfectly legitimate activity. Companies should not be able to protect their software from us. We need to be able to see everything they are doing.

I would phrase that: Companies should not be able to hide from us what they are instructing our hardware to do, especially with our data.

Well, they especially shouldn't be able to do that, but no, companies should not be able to hide anything at all. (If there's anything that shouldn't be public (eg security camera footage, billing records), the company as a whole shouldn't have access to it in the first place. Ideally them shouldn't be allowed to collect it at all, but there are obvious practical issues with applying that universally.)

Right, just like there's no legitimate use for gdb or ghidra, which only exist to crack software for piracy. /s

Funnily "ghidra" reads like غدرة in Arabic which means "treachery".

Do you mean eBPF in general or the packet inspection parts specifically?

An administrator spying on other users on a shared machine is not a legitimate purpose (though, yes, it is a fairly obvious risk which no one should be surprised by).

Reply on news.ycombinator.com