And right now, we have Moritz Averill, and he will be giving a talk on Microsoft Teams.
Let's hear it out. Come on.
All right. Hi, DEF CON.
.
Do we have the presentation on the screen?
.
.
.
.
.
.
.
All right. So, hi, DEF CON again.
Hope you're all doing well and have a great conference.
I want to thank the DEF CON team for their work and making such a fantastic conference each year.
I'm so excited for being here today and talking about my research, Freaking 2.0, Abusing Microsoft Teams Direct Routing.
First of all, a few words about myself.
My name is Moritz Averill.
I'm a senior IT security consultant and penetration tester for a German company called Sys.
I'm interested and have several years of professional experiences in security analysis of common enterprises IT stuff, including hard and software, especially communication systems and infrastructures.
In the next couple of minutes, I will show you how Microsoft Teams Direct Routing can be abused for toll fraud attacks from the perspective of Microsoft Teams Direct Routing.
In addition, I will tell you the story about the vulnerability disclosure and the failure of the manufacturer to provide an appropriate fix.
I guess everyone knows Microsoft Teams.
In a nutshell, Microsoft Teams is a communication platform hosted by Microsoft, including typical unified communication features, such as audio and video conferencing, chat, file sharing, and so on.
Microsoft Teams also offers the ability to extend it from making and receiving external phone calls, which is a nice feature in many business cases.
For example, if you want to provide your employees with a cross-platform soft phone.
And for enabling this, you have two options in the most cases.
The first one is to insert some coins to Microsoft and using Microsoft as a telephone carrier.
This scenario is called calling plans.
However, if you want to use your existing telephone, you can do this.
If you want to use your phone as a telephone carrier, you have to choose the second scenario, which is called Direct Routing.
Direct Routing requires the operation of a dedicated session border controller, and this session border controller must be reachable from the Internet.
This also enables the integration of your existing infrastructure, like a PBX, legacy devices such as fax, or a contact center.
The communication between the Microsoft Teams client and the backend is done with HTTPS.
The communication between the Microsoft Teams proxies and the SBC is done with the Session Initiation Protocol, which is also the most commonly used protocol by telephone providers.
In this talk, we focus on the communication between the Microsoft Teams SIP proxies and the SBC.
So, let's take a brief look at what SIP actually is.
SIP is similar to HTTP, so it's a text-based protocol with a header and a back-end.
It's a request line, including a request method, as well as headers with values and parameters.
All right, so how are we going to start?
Well, on the Teams side, you mainly have to configure the full qualified domain name of the SBC, which must be already registered to your tenant.
There are a handful of other configuration options, however, they are not relevant for this talk.
So, we are mainly done on the Microsoft Teams side.
As already mentioned, Microsoft Teams Direct Routing requires a SBC, and this SBC must be tested and certified by Microsoft.
And a list of such devices can be seen in the Microsoft documentation.
And the very first ones, and in my experience, the more common session border controllers are devices from audio codes.
All right, so let's configure it.
But to not reinvent the wheel and to follow the recommendations,
we go to the audio codes website and search for a suitable configuration file.
And by selecting Microsoft Teams as the application, we get a list of configuration guidelines, including some carrier-specific guides, as well as a general configuration note.
In addition, there is a nice configuration result where you can click together all your requirements and finally get a suitable configuration.
By the way, this is a very simple configuration.
This is exactly what one of our customers did.
He ordered a session border controller from one of the biggest carriers in Germany.
And they said, we configured it according to the configuration guidelines, together with audio codes.
So, what could possibly go wrong?
Well, let's take a closer look to the applied configuration.
Here we can see the topology overview of our applied configuration, including two sections, so-called IP groups.
Here we can see the topology overview of our applied configuration, including two sections, so-called IP groups.
One for the Microsoft Teams direction, and one for our telephone carrier.
One for the Microsoft Teams direction, and one for our telephone carrier.
And if a call comes in, it goes roughly this way, from an Ethernet interface to the applied IP group, which includes a media handler and a SIP interface.
And if a call comes in, it goes roughly this way, from an Ethernet interface to the applied IP group, which includes a media handler and a SIP interface.
And if a call comes in, it goes roughly this way, from an Ethernet interface to the applied IP group, which includes a media handler and a SIP interface.
And if a call comes in, it goes roughly this way, from an Ethernet interface to the applied IP group, which includes a media handler and a SIP interface.
service. So, one of the first steps during a security analysis is taking a closer look
to the rule set of the IP to IP routing. And there I saw this rule which means everything
that comes in from the Microsoft side goes to the telephone carrier. For example, if
you're making a call from your Microsoft Teams client, it goes this way. But before a SIP
message is handled by the routing engine, it needs to be classified by the SBC. So, this rule
tells us that the host name of the SBC must be set as destination host inside the SIP message
received from Microsoft. Moreover, other things are required which are defined in the
Teams contact rule. This rule tells us that the static string must be included inside a SIP
message at a specific SIP header. In detail this means that the static string pierced and
in hub.microsoft.com must be set at the host part
of the contact header inside the zip message
received from Microsoft.
And after reviewing the rest of the configuration,
no further conditions or authentications are required
for correct classification for incoming requests
from Microsoft.
So, at this point, I ask myself,
is it possible to include the SPC's host name
inside the zip message, send it to the SPC
and get correctly classified?
Or, in other words, we pretend to be Microsoft Teams
and trying to initiate an external phone call
through the victim's telephone account.
But, for a successful attack, we need to know
the full qualified domain name of the SPC.
But, yeah, this is a simple task.
On the one hand, we can find out the SPC's
full qualified domain name, if a valid DNS pointer entry
exists, and on the other hand, the common name
or subject name.
And alternative name values in the X.509 certificate
of the exposed zip TLS service can be extracted.
So, we have the host name, and now we have to define
the zip call flow for our attack.
And the idea is to send a zip invite message to the SPC,
and if the destination accepts our call,
we will receive a 200 okay response.
After that, we terminate the call by sending a zip by message.
So, now we need a tool for handling this specific
call scenario, including all the required information.
And a tool which can be used for that is ZIPP.
ZIPP is one of my favorite tools when it comes to zip pen testing.
It's actually not a hacking tool, it's a zip testing tool
to handle specific call scenarios and testing your phone systems.
And these scenarios are defined in XML templates
and are highly flexible.
Thus, we can write our own XML templates, and we can also write our own XML templates.
Including our call flow for the attack
and all the required information.
And I've already done this, and the most interesting part
of this XML template is the zip invite message.
Here we define a new key named host name
to set the SPC's host name.
Next, the static string psdinhub.microsoft.com
is set as the host part of the contact header.
The service, the caller key will be our
presented caller information.
For example, the CO's phone number of our target.
And finally, the service key will be our
destination phone number, which we want to call.
All right, so, here we can see how we can launch
our proof of concept script.
But because we talked to the ZIPP TLS service,
and ZIPP then requires a X.509 client certificate,
we have to generate the self-signed certificate.
Actually, it's not required.
It's not required or requested by the SPC.
It's just to make ZIPP happy.
So, now it's time for a short demonstration.
So, on the right side, we can see our destination phone,
which we want to call, and mainly on the left side,
our proof of concept script, which is executed.
And after about, yeah, a few moments,
we successfully initiated a X on the phone call
through the victim's telephone account.
Oh,
all right, during the attack,
I trace the ZIPP traffic on the SPC.
So, here we can see the zip card flow of, you know, the key caused by ZIPP.
during the attack and as already seen in the demonstration,
everything works fine and we were able to act as Microsoft
to initiate an external phone call
through the victim's telephone account.
So, now you may ask yourself,
what's the impact of this issue?
Well, there are two major problems here.
First, we are not able to act as the victim
to perform CEO fraud or other social engineering attacks.
And second, the more worst and common attack is toll fraud.
Hereby, the attacker uses this security issue
to perform calls through the victim's telephone account
with the destination of a premium phone number.
And this premium phone number is under the attacker's
control and therefore, he gets the money.
We had customers who were affected by such kind of attacks
which results in an explosive telephone bill
within 10,000s of dollars.
So, as a next step, I reported
the vulnerabilities to the manufacturer
and after a few days, I got the response
that the configuration guidelines are patched.
But, when I checked the differences
in the configuration guides, I noticed this.
The manufacturer added this source IP filter
to allow incoming traffic only from this source IP range.
But, when I saw this, I was a little bit surprised
about the big range and therefore,
check if this is indeed exclusively assigned to Microsoft.
Long story short, it is not.
Here we can see a short abstract
of the IP address assignments within this range.
And yeah, the smart tech of you already noticed
an interesting assignment.
It's AWS, where we can set up an EC2 instance
or other cloud services,
and maybe using an IP address of this range.
So, for our luck, AWS has this public exposed JSON file
where you can check all IP address assignments in AWS.
So, you know what comes next.
I logged into my AWS account,
selecting one of the correct AWS locations,
and tried to get such an IP address.
And after about 20 tries,
I finally got an IP address of the widest IP range.
So, afterwards, I assigned this IP address
to an EC2 instance,
and again was able to exploit this issue.
So, I reported my new insights to the manufacturer,
and after a few days, I got a response,
and now the manufacturer refers to the use of mutual TLS.
So, let's take a brief look at X.509 certificate verification
in TLS and mutual TLS.
I think most of you have deep knowledge
about certificate verification and TLS.
However, here are some basics.
If you communicate to a TLS-secured service like HTTPS,
your browser verifies if the requested host name
matches the common name or subject alternative name,
verifies if the certificate is signed
by a trusted certificate authority,
and checks whether the certificate is valid or not.
So, the server includes the certificate
inside the TLS handshake, and the client can check it.
You can verify all those things.
If mutual TLS is enabled, the server requests
the client certificate, and the client sends it back.
But, due to communication is initiated by the client,
the server does only know the incoming client IP address,
and therefore, the server is not able to validate
the common name or subject alternative name
against this value.
So, if we move this behavior to our Microsoft Teams
Direct Routing installation, it means that the SPC,
does not validate the common name or subject alternative name
for incoming requests from Microsoft.
So, I checked the details about mutual TLS
in the Microsoft documentation, and there,
this node advises to trust these two root certificates.
However, both of them are widely used.
I cross-checked this also in the Microsoft,
in the audio code documentation, and there is also
pointed out to trust the Baltimore root certificate.
But, as already mentioned, both of them are widely used.
For example, this is the signing tree
of the Baltimore root certificate.
So, getting a correctly signed certificate
by one of these two root certificate authorities
cannot be that hard, right?
Well, taking a closer look to the signing tree,
I saw this one, and after some Google work,
I found this service provider where you can buy
a certificate, ultimately signed by the Baltimore
root certificate, for about $150.
Plus.
So, we can set up an arbitrary host name
for our attacker EC2 instance,
getting a correctly signed certificate,
and we are again able to exploit this issue,
even if mutual TLS is enforced.
So, I reported my new insights to the manufacturer again,
and after a few days, I got the response,
within the following statement.
The audio code's configuration guides are focused
on interworking, and only describe the basic security rules.
Nevertheless, further measures and fixes were provided.
Follow the SPC security and handling guideline.
Filter the incoming calling party number,
and implement separate firewall rules.
All right, so, let's have a closer look
at these recommendations.
First of all, the security guideline provided
by SPC manufacturer includes good and proven
security recommendation and configurations.
However, if we follow this guide,
Microsoft Teams Direct Routing will no longer work.
So, we can skip this.
Next, the manufacturer recommends to filter
the incoming calling party number,
but, yeah, we have control over this value,
and finding out the victim's phone number is not that hard.
A quick Google search returns the needed information
in the most cases.
So, let's check the last recommendation.
The manufacturer recommends, or the manufacturer
implemented the additional section,
configure firewall settings.
But, keep in mind, it's optional.
And these firewall settings allowing incoming TCP traffic only from the documented market.
Microsoft Teams ZIP proxies, which indeed,
will prevent this attack, but isn't IP filter
as authentication state of the art?
And it should also be noted that these firewall settings
are also not applied if the configuration result is used.
So, at this point, I ask myself,
what's going on at the only code side?
Why they don't just implement appropriate authentication
mechanism for Microsoft Teams Direct Routing?
And this brings us to the great news.
The question, is this all only codes, or the SBC's fault?
And, the short answer is no.
This is just the story about the manufacturer
who tries to secure this by the limited hardening measures
provided by Microsoft.
In general, the described problems are affecting
to all Microsoft Teams Direct Routing installations,
and the only codes SBC is just an example in this case.
So, I asked Microsoft for implementing
proper authentication mechanism,
such as the application-specific ZIP Digest authentication.
This would allow to define a long password
on both sides for authentication.
And, in addition, signing the Microsoft Teams ZIP proxies
with a dedicated and exclusively used certificate authority
would secure the mutual TLS authentication.
But, until now, the case is still open.
So, to give you a few recommendations to secure the mutual TLS authentication,
and to secure your existing Microsoft Teams Direct Routing installation,
you can do implement strict IP filters,
which is currently the only effective way
to prevent this attack.
Next, you can configure static subject alternative
name filtering, but it should be noted
that this is a SBC-specific configuration,
and it is also neither recommended nor tested
by Microsoft or all your codes,
and it's not possible in every use case.
So, moreover, limiting the call duration,
deny premium phone numbers, and logging and monitoring
are recommended in general.
So, I come to my final thoughts.
Current Direct Routing installations
may be vulnerable to toll for the techs.
I also want to remind you to think outside the box
and keep your hacker mindset.
This talk is the result and the story of a security analysis
that is widespread in use for many years.
Be not afraid of big names like Microsoft,
and even if the manufacturer provides a fix,
ask yourself, how effective is this fix?
Can I bypass it, or is it exploitable in another way?
And finally, freak the planet.
Thanks.