Thank you everyone for tuning in.
I'm super honored to be speaking here today at DEF CON.
This is my first DEF CON talk.
I'm super honored to be here today.
And I wish that we can all have a normal DEF CON
and we'd be able to meet everyone in person,
but hopefully next year when life gets back to normal.
Yeah, let's start.
So who am I?
I'm Mazen Ahmed.
I'm a cyber security engineer
and I specialize in offensive security and APSEC.
I also founded Fullhunt.
If you haven't heard about Fullhunt,
it's the next generation assets discovery
slash monitoring, slash scanning,
slash a lot of cool things
that are happening in the background.
If you haven't tried it or checked it out,
you should definitely do.
It will be one of the coolest things
in security one day soon.
Before that, I worked in the security engineering
of ProtonMail.
I was also, I'm also a bounty participant
where I reported security vulnerabilities to Facebook,
to the Department of Defense, to Twitter, and many others.
I'm interested in web, infra, mobile,
and cloud security, life evasions, security automation,
and DevSecOps, and many other cool things in security.
And you can read more at mazenahmed.net
and you can find my contact details there.
And yeah, let's start.
So the agenda for today,
of course, we're talking about hacking Zoom.
Before that, we need to have a quick intro about Zoom,
just in case.
And then we're gonna have a background, findings,
a retrospective on the Zoom's last minute VDP,
recommendations, final thoughts,
and then we would have a room for Q&A.
Zoom, everyone knows it today.
Everyone is using it.
It's literally in everywhere in the world.
Every company, almost every company is using it.
Governments use it too.
We saw last week the hearing of the Twitter hack
where the hearing was done via Zoom
and that hack happened at the hearing live.
It was quite bad, but yeah.
So this proves that everyone is using it.
In May, 2020, the market valuation for Zoom
is 50 billion USD.
I'd like to bring this chart here.
This is a comparison between the market capital of Zoom
against the top seven airlines in the world,
including United and Delta.
So combining the top seven airlines' market capital,
they are either equal or have a higher market capital.
This is crazy just to think about it,
how Zoom became today.
And the rise of Zoom started with the global pandemic.
Everyone knows about that.
So from a stock performance,
almost all of the companies were in the same range
as we can see here.
And then it jumped, it actually skyrocketed by May
with all what was happening.
And meanwhile, all of these top airlines
were quickly falling down, as we can see.
For me, I just find this really interesting
to imagine how Zoom became today.
Yeah, and because how important is Zoom?
This is where my research started.
So in March, March 2020,
Patrick Walder gave a talk at Opcode
about the Zoom security and the state of security at Zoom.
And he disclosed a number of security vulnerabilities
in the Mac OS client of Zoom.
And this brings a lot of attention
to the media and to me personally.
And from that, I got more interested
and started my research from there.
So what was tested before?
The Zoom Mac OS app, it was tested.
We can read about it in the media
and we can read about it in researches
done by Patrick Walder and many others.
It was hacked, it was really bad,
it was reusing really bad practices.
There was a lot of Zoom privacy concerns
and the way that Zoom is sharing data to Facebook
and a lot of things we can also see.
But what was not tested before?
Of course, many things.
This is, I can just share two,
but many things has not been tested before.
For me, I'm trying to take into a couple of things
and that I will be showing now.
One thing that was not tested was the Zoom Linux app.
Nothing, I have tried to search about any research
or disclosure for any vulnerability in the Zoom Linux client.
I haven't seen anything.
This is one thing that I wanted to see
or to focus on.
The Zoom external attack surface, Zoom became huge
and there was no focus on the external attack surface
of Zoom.
The Zoom cloud infrastructure, how it's being set up
and different things related to the infra.
And of course, the Zoom's new end-to-end
encryption implementation.
We have seen it to the media.
Did anyone test it?
We can talk about that later.
And of course, many.
There are a lot of things, I only focused on these.
Definitely, there is a lot of room for research
in this area.
So the findings agenda, I'm not gonna go
to each one of them now.
We will talk about them later.
It's just here for people who are curious
to see what we're gonna talk about.
A quick disclaimer, the entire research is non-funded.
This is a non-funded research.
I have done everything here in my spare time,
just to confirm that or state that.
The research background, the first finding
that I identified was in April, 2020.
And my expectations did not match what I was seeing
in the media.
We will know how later.
The first conclusive response for my finding
that I reported in April, 2020, I got it in July.
This wasn't a very pleasing experience.
And this after a lot of follow-ups, of course, from my side.
And after submitting the CFP to Defcon,
the second round of research started.
At that time, I identified additional
six new different vulnerabilities
and security-related issues.
And of course, everything was reported to Zoom.
And the reward was zero dollars.
Yeah, I just want to say that.
So the first step for doing any type
of offensive research is the reconnaissance.
Understanding the attack surface.
And that's where I started with.
I used full-hunt.io to get the Zoom details.
API returned around 13 domains.
And this is the list of domains that was discovered.
I took a portion of them and analyzed them.
The remaining are there.
If anyone would like to have a test drive, feel free.
And let's go to the findings.
One thing that I noticed that there was two servers
that are having a Kerberos service running.
And when I saw that,
I got interested to see what's happening there.
Apparently, there was two exposed Kerberos servers
that was exposed unintentionally to the internet
and no one knew about them.
So this one had also a web service running on port 80
and it was FreeIPA.
If you don't know what's FreeIPA,
it's an identity management solution
that was developed by Red Hat.
It's open source, you can check it out.
And I started by testing the web interface.
As you can see, this screenshot,
when you are providing an invalid username,
you can see that there is a Kerberos error
that is telling you that.
And one thing that I did not mention here,
that whenever you see a Kerberos server running,
by itself, it's not huge,
but once you compromise it
or you have a single credential that is valid,
then this would open a crazy large amount
of attack surface for you to attack.
And that's what I was doing.
I want to get initial foothold there
and then go from there.
So I started doing user enumeration there.
And you can see here,
the previous one was showing that there was an error.
This user is not found by the client.
And here it's saying that the authentication failed
or the pre-authentication failed,
which means that we are able to identify
valid usernames.
And then I started building word list
based on different things to identify more usernames
so that I can brute force them.
I compiled the word list from the pattern that I have seen.
So the pattern that I have seen for the Zoom emails
are firstname.lastname at zoom.us.
Also the common usernames that I was able to find to get
and employee names, of course.
I compiled them all and I did that for user enumeration.
The only users that I found was admin at idm.mezoom.us.
I then ran a number of brute force sessions on them.
Nothing interesting happened.
Then I saw that I'm hitting a rabbit hole
and it's a dead end.
So I just moved to another more interesting thing
that I can find.
And yeah, it was a good choice.
So the discovery of a memory leak
on our Zoom production server.
Zoom allows uploading profile pictures on accounts,
which is the typical thing.
The process for that is first,
the user uploads a profile image.
And the profile image is either JPEG, GIF, or PNG.
And this is the tricky one.
If the image is PNG or GIF, it's converted to JPEG.
And if the image is JPEG,
the image conversion is not triggered.
And there is another thing here
that if the image contains an invalid image header,
the updating profile API aborts the process.
So there is a good check in that image header.
And it's using, of course, magic bytes,
by checking the magic bytes.
I like to test image conversion or processing softwares.
Or whenever I see an API that is utilizing that
or using that, I know for a fact that there is a large
potential of having something bad happening.
And the reason is because image conversion
is not a vital functionality in an infrastructure
of a company or even a web startup.
So what happens is it often gets forgotten
and there's no security updates
that are being applied there.
As far as it's working, then it's fine.
This is something that I have seen as a pattern.
And that's why I started testing that or focused on that.
So one cool exploit here or security vulnerability
that was released in 2016,
it was known as the ImageTragic exploit or vulnerability.
And this vulnerability allowed having remote code execution
into the instance that is running the image processing
when providing certain payloads.
You can read more about the CVE offline.
So I have tested this one
and they seem to have this one patched.
So I moved to the next one, it did not work.
So I moved to the next one.
There is a vulnerability in ImageMagick
that was reported in 2017.
And it works by having,
whenever the palette is uninitialized
or not presented in the GIF file, basically,
ImageMagick leaks portions of the memory
to the generated or the rendered image.
And this is the fix for the vulnerability
that was issued at that time around July, 2017.
I generated a payload that renders this way
in a normal browser or normal software that is patched.
But when I upload the payload to Zoom,
it renders this way.
But if you are reading the report for that CVE,
this is the typical behavior
of having the exploit being successful.
And if you download this image
and try to obtain the strings from it,
you will find that it's taking some portions of the memory.
Then I thought that maybe this is an,
let's say, image processing software fault
or best effort just to render the image that is corrupted.
Or there is a problem that is happening
because of rendering a black image.
So I generated a new one that is not the,
like the payload, it's not the one that,
this one has initialized palettes.
And when I report it, it renders normally.
Okay, this sounds really interesting.
We have a memory leak on Zoom production.
Typical thing is to automate the exploitation for that.
And the flow for that would be
to generate a new unique payload,
then to upload it to Zoom,
wait for the rendering to happen,
download the rendered file,
extract the data from the corrupted file
that was rendered by Zoom,
repeat and store leaked memory portions.
So this proof of concept does that.
So I'm going to have a demo time, which is cool.
Here it generated the image and uploaded it to Zoom.
I'm downloading the image now.
And here, recovering the dump.
So here, a memory leak on Zoom production
was not the end for that.
I remember that in 2018,
Travis Romande released a research on Ghostscript,
which was used by ImageMagick.
And his research revealed a number of critical vulnerabilities
in Ghostscript.
And the proof of concept that he shared in the research
when doing image conversion
can lead to a remote code execution.
And it was really cool to see this.
And what I did is I used the proof of concept
that Travis wrote.
And I will show you this thing first.
So we know for a fact that the 2016 v7.1.4,
the image Tragic is patched.
But we kind of think that the ImageMagick memory leak
is presented based on the proof of exploitation we had here.
And that one was patched and released,
the patch was released in May 2016.
And the patch for the memory leak was released in July 2017.
And it's not patched.
Based on that, we can safely say that
the Ghostscript ROC is not patched, right?
So I wrote, like I brought the proof of concept
from the research that Travis Sormandy wrote.
And I replicated it locally with the same environment
I assume Zoom have it on their setup
with the same range of versions that Zoom is using mostly.
And yeah, it's working.
Unfortunately for, or fortunately,
I'm not sure which one would suit that,
that Zoom API slash p slash upload checks for magic bytes.
Otherwise a full exploitation would have been possible.
But still, this does not mean that like Zoom is safe.
If there is any particular API
that is utilizing the same functionality
and it's not checking the magic bytes,
this would lead to a full remote code execution.
This doesn't sound nice.
This doesn't sound good by any means.
And I don't know how to say this,
but the RCE vulnerability is probably still there
on Zoom production.
Another thing we have here is the shadow IT and Zoom.
I have noticed that there is a number of instances
or cases where Zoom have shadow IT servers
running in different host names
and are not properly configured.
And they may be a good target
for conducting a successful attack.
I have seen this in multiple occasions.
This example here is showing an instance
that did not have any patches since,
let me check, September 10th, 2019.
I took this picture in July 4th, 2020,
around 10 or nine months of timeframe.
There was no patches on that server or all new builds.
And we all know that there was plenty of security vulnerabilities
that was reported to them.
And yeah, you can imagine.
Another cool thing here is the same host
had nine active connections, including me.
Makes it an excellent fit for doing any type of testing
without triggering alerts, which is cool,
so that you can test it and be safe in the part
that won't be as detected or detectable
as in testing zoom.us, the main website, or yeah.
Enough about all this,
and let's start to talk about the Zoom app for Linux.
One cool finding here, Zoom Linux client,
so the TLS is broken by design on Linux,
and you're gonna see how that is happening.
I don't see this as the best practice,
especially for the Zoom, but we can talk about that.
So whenever there is any traffic that is intercepted
with a custom TLS certificate, Zoom prompts this message.
While it looks normal, everything is fine here.
And whenever you click Trust Anyway,
then you would have the traffic going with that,
like with this accepted certificate,
which is the unlisted one.
But what happens here is that this certificate,
like the fingerprint for this certificate
is saved locally with the same permissions of the user.
And you can simply just plug in,
like if you have a malware that is able to have access
to your machine, this malware can safely or easily
just plug in to the fingerprint of the certificate,
and then all of the traffic that is going to Zoom
can be intercepted, even if it's using SSL or TLS,
because the certificate will be accepted
without having to have this type of prompts,
because it was added to the local database
on the background.
So I wrote a simple proof of concept
as a sample of what a malware would look like
as just in a way or another as a concept.
And this particular part of the malware
or the proof concept would get the fingerprints
for all of the forged certificates that we have.
And then it would add it to the Zoom database,
local database, and once it's added,
these certificates can be provided to Zoom
and all the traffic would be passing
without having any error like this.
And yeah, all of the encrypted traffic
could be intercepted when having a malware
running on the same user access as this one.
Well, I have to say, this is not a really bad vulnerability.
It's just a little bit not the best practice to do that.
But as we are going now,
we're gonna see something that is really bad
and we're gonna see it now.
So I would start with this question.
What's a bad design for an application launcher?
Good question.
And we're gonna know the answer.
So userbin slash zoom is a summary of OPT
slash Zoom slash Zoom launcher.
And whenever Zoom is called,
Zoom is printing the following logging
logging data on the SCD out.
And there is a part where you can see
Zoom path is OPT Zoom
and then Zoom not exist at current directory.
Okay, this looks interesting already.
What's happening in the background?
Zoom checks for files within PWD.
And if there is an executable called Zoom, literally,
on PWD, it executes it as a chat process
for userbin Zoom.
I was mind blown when I saw that.
Why would this be there?
This is a proof concept.
I created a file called Zoom
and then Zoom checks on the PWD
if there is a file called Zoom, literally,
and executes it.
Of course, it has to be with an executable for permission,
but this is not a thing.
So imagine this, you have application-wide listing.
There are a lot of points that I can make here,
to be honest.
I can make a lot of things that would show
how this old design is there for.
And if there's anything related to application-wide listing
and your wide listing Zoom,
this would literally break that
because this is executed as a child process
of a trusted application, Zoom.
And yeah, it's bad practice and bad design
by all means.
Like why would this be implemented this way?
So that's my answer.
If it was a bad design for an application launcher,
I would be Zoom application launcher for Linux.
Another bad thing happening here.
So the Zoom local database implementation,
you'll see now.
So in the configuration files
of the configuration directory of Zoom,
there is this file,
the local database is zoomus.db.
This is the default database
and a lot of other files that are there for Zoom.
The most important file is the zoomus
because it has the access tokens,
it has all of the PII for the user and everything.
And as we can see here in the screen,
the file permission is 644.
I'll show you this.
644.
This gives to the user a write and read access.
Okay, sounds reasonable.
Nothing bad on that.
Group access to give it read access.
Why?
I really like, really?
Are you sure about that?
But everyone to have read access
into the Zoom local database
of the Zoom user.
Why?
Literally, that's what I had in mind.
Any code on the user machine that have access to the,
like any code that have access to the user machine
can read and exfiltrate Zoom local database
and configurations and more, of course.
Because the permission or the file permission
for the Zoom local database is set to be read by everyone.
And, okay, another thing that is quite cool.
Zoom is end-to-end encrypted.
Is it?
We can see later, but my answer is not fully.
One awesome product by Zoom is Zoom chat.
And it's advertised in the website
and that we can see here
as a platform that is,
that makes work and collaboration much easier
in mobile and desktop
and with a really clean design and UI
that looks kind of similar to what Slack is having.
This is not the point,
but it looks good as a product, right?
And as we go back here is, yeah.
There are so many cool things to read,
but I would focus on the security part.
As we can see in the security and archiving and in I-Code,
Zoom encrypts data at all times.
Again here,
encryption of data in transit and at rest
and then encryption for data and mobile devices.
Your messages in this chat are secured.
Another one.
So there are a lot of advertisement
that is going with how secure Zoom chat is happening.
And by security, they don't really
or necessarily talk about application security,
level of security,
but they are talking about how all of the data
that are being passing here is encrypted
both at rest and in transit,
which is in transit, I assume they're saying
that it goes in SSL.
It's cool.
But at rest, this means that they have full
end-to-end encryption happening, right?
And yeah, repeating again the same sentences.
And let's pause this.
I'm not sure.
This way is fine.
But on the right screen, we have Zoom chat running
and I have my group chat that is clear with no messages.
And then I'm sending some sort of an encrypted message
that is here because Zoom is E2E by now,
E2E encrypted by now.
As advertised.
And then on the left side, we can see the local database,
a custom one that is made by Zoom
that we can see that they have it.
And I can just read what's happening there
and what they are storing on your local device.
So here I sent a message
and it's saying that this is secret.
Oh, well, just one second.
I have to repeat that.
The message is being stored locally at rest in clear text.
And here, anyone who is able to have access
to the user machine is able to pull a full archive
of all messages that are being sent
that were or are supposed to be end-to-end encrypted
and it's saved in plain text.
And yeah, this does not sound good.
And it's not the one that you can have a record
or a backup for your messages.
It's just a debugging feature that they left open
in production for the Linux build.
I'm not sure if this is applicable in macOS or in Windows,
but you can see if that's being applicable here in Linux.
By the way, the fact that the same database
that for messages is having the 644,
where is it?
The 644 user permission,
which means that any code that is running
despite what type of user permission is running
is able to access this end-to-end encrypted chat archive.
Doesn't sound good.
Yeah, so of course I could have gone more and tested more,
but at the end, this is just a time
that I have spending just to fuzz around with Zoom.
I did this for curiosity purposes mainly,
but definitely I could have spent more time.
But then, yeah, I jumped to the responsible disclosure now,
and I started the experiment in around April.
April 15, reported that in April 18,
I contacted Lotus Security in Twitter,
followed up with the vulnerability disclosure again on 26,
couple of messages on the background.
And May 5th of 2020,
I received request closed to memory leak at Zoom.us.
Yeah, here.
So yeah, I wasn't happy.
So what's next?
Tweeted about that.
And then I was asked to send it via HackerOne,
turn on communication running to run my automated exploit
for the memory leak.
Then when nothing seems to be happening,
I informed Zoom that I'm planning to present
my ongoing research here at DEF CON.
And then Zoom told me that they cannot assess the issue
as there was no sensitive data seen
despite the predictability of the vulnerability
on the provided exploit.
Then it was closed as not applicable.
Sure.
Then I sent on July 11th,
my new research results,
reporting new seven different security vulnerabilities,
six to seven new vulnerabilities.
I got an acknowledgement about receiving my report.
By the way, this is the first conclusive response
regarding the memory leak issue.
By conclusive, I mean that they did a full analysis
of what was happening.
On the previous ones on HackerOne,
they triggered it as valid,
and then they were trying to run my exploit,
and that's all.
But this one, they researched more and analyzed more
about how this is happening
and what was the cause of the issue.
And it was in like literally three months
after I reported it.
Then further explanation from Zoom
regarding the vulnerability or the findings in general.
Okay, now with what was happening
and then from their explanation,
and then my response regarding each analysis
that they provided.
So for the public authentication,
yeah, you can see what's happening here,
what they wrote.
And well, yeah, for me, yeah.
Well, again, this may be a forgotten server
that was mistakenly exposed.
I haven't seen any references of 2FA being implemented,
but in all cases, it's down now, so it's great.
Oh, wait, I think I messed up with the messages here.
Anyway, so this is the same slide from the last one.
So we did check that ImageMagick
is not used for image conversions here,
but wait, the same vulnerability is being reproduced.
It's maybe a fork of ImageMagick
or an image processing software
that is vulnerable to the same CVE
of not being able to parse GIF images
that have an initialized palettes.
This sounds reasonable.
In all cases, it's clear that something is wrong, right?
Shadow IT and Zoom.
So these are non-sensitive information disclosure
from a shared environment.
Information hygiene is important to us
and we appreciate you reporting this finding.
So that's great.
So Full Hunt can help here,
probably the best product out there
for mitigating shadow IT risks.
Oh, I think part of the discussion
regarding the image conversion
is not placed on the slide,
but please check my blog after that
to have the full list of discussion.
So for what was happening for the Linux app findings,
yeah, they fixed it or patched it in 5.2.0
that was released in August 3rd, I think.
They were supposed to patch or release it on August 2nd,
but it was released on August 3rd.
In all cases, I have read the change log.
There was no mention whatsoever for any security patches.
So clearly it was a silent fix,
which it wasn't a nice thing.
At least users should have some transparency
of the state of security for the company
that they use or trust.
Yeah, the patches.
I just told you about the patches
for what happened for the Zoom Linux app.
For what was happening with the image conversion,
they decided to not patch it
because they are not seeing sensitive data
and then that are being exposed.
Then what happened is they asked,
they stated that they are not using image magic,
but still the same behavior of the vulnerability
is being reproduced as a result of the image conversion.
So clearly something bad is happening,
but I'm not a part of Zoom
or I don't have a say on Zoom to have them fix that.
So my responsibility is just to,
as part of the research that I'm conducting,
is to just let them know.
And that's all.
What else?
The findings, the shadow IT,
I'm not sure if they started reviewing
all of their shadow IT instances.
That's something that they are supposed to do.
For the Kerberos server, they took it down,
which is good, which is awesome.
And yeah, they told us,
they told me that they are patching
all of the vulnerabilities for the Linux app
on the release of August 2nd or August 3rd.
It was released with no mention
for any security fixes or updates.
Yeah, for me, it was a difficult experience
to be able to report these vulnerabilities to them.
In the beginning, there was a lack of communication,
despite all of what was happening
or that I was hearing in the media.
Every now and then, I see that Zoom has patched
a critical or severe vulnerability
that was even attacking things that are less riskier
than what I have found,
but it was generating a lot of media PR
that is bad for or negative to Zoom.
And I assume that was the reason
why they are patching it that quickly,
comparing to my experience to Zoom VDP.
And yeah, of course, I did not release anything
that I found before this talk.
To other parties or unauthorized parties.
And yeah, so it was not mentioned in the media before.
I did not share it with anyone in the media.
That's probably one reason it wasn't that fixed
or my experience wasn't as the same
as the vulnerabilities that was shared in the media.
And that's one thing.
I'm not sure, but I would be surprised
if I'm the only researcher in the world
that had this experience with Zoom security.
I would be really surprised about that.
Another part is the massive growth versus security.
Zoom has massively grown in 2020
in a way that no one could have imagined.
Zoom has been here forever.
And what the growth that they got during 2020
was something that for me,
it was like no one would have expected this to happen.
And this reflected a lot on the security.
A lot of people have a clear focus on the security of Zoom
since it became a part of our lives.
Everyone is using it.
I use it, my company use it,
everyone that I know use Zoom.
And that's why security is extremely important now for Zoom.
And the thing is having security means
that you have to have a full security program running.
It's not that easy to have a full security program.
And there are a lot of things to consider when doing that.
For me, when I build security programs in companies,
I take a lot of time to do that.
And this is a typical thing.
Even if we have the highest budget,
similar to what Zoom is having,
it does not come to how much budget is allocated to Zoom,
to Zoom security.
It's about different processes
that should have been already done before the pandemic.
And having a last-minute security program
or a last-minute VDP,
Probability Disclosure Program,
is not easy and can cause a lot of errors
and mistakes happening.
Lack of communications and focus.
These type of patterns that I have seen with Zoom
is something that are possibly happening
to all of the researchers
that have been reporting to Zoom responsibly.
I'm just saying that there is a lot of work
for the security program at Zoom to be done.
The reward?
Yeah, that's another thing.
One thing that I also seen that Zoom accounts
like have as advertised a bug bounty program
and then have the reward for all of the research
that they have conducted as zero USD.
This is not a...