 And right now, we have more, it's April and he will be giving a talk on Microsoft Teams. Let's hear it out, come on! All right, hi DevCon. Oh, do we have the presentation on the screen? In this HDMI cable. Ah, okay. Oh, you got that. You have it in presenter mode. Perfect. All right, so hi DevCon again. Hope you're all doing well and have a great conference. I want to thank the DevCon 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 Apre. 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 staff, 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 talk fraud attacks from the perspective of an unauthenticated external attacker. 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. 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 software. 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 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 back end is done with HTTPS, secure web sockets, and web RTC. The communication between the Microsoft Team SIP proxies and the SPC 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 Team SIP proxies and the SPC. 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 body part, 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 team side, you mainly have to configure the full-qualified domain name of the SPC, 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 Team side, but as already mentioned, Microsoft Teams Direct Routing requires a SPC, and this SPC 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 experiences, 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 of the certification process by Microsoft, 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 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, 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 then to the routing engine named IP to IP routing. Based on the configured rules inside this routing engine, it goes likely the same way out to the destination SIP 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 a 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 psnhub.microsoft.com must be set at the host part of the contact header inside a SIP message received from Microsoft. And after reviewing the rest of the configuration, no further conditions or indications are required for correct classification for incoming requests from Microsoft. So at this point, I asked myself, is it possible to include the SBC's host name inside a SIP message, send it to the SBC, and get correctly classified? Or in other words, we pretend to be Microsoft Teams and trying to initiate an external phone call to victim's telephone account. But for the successful attack, we need to know the full qualified domain name of the SBC. But yeah, this is a simple task. On the one hand, we can find out the SBC's full qualified domain name if a valid DNS pointer entry exists. And on the other hand, the common name or subject alternative name values in the X.509 certificate of the exposed SIP TLS service can be extracted. So we have the host name, and now we have to define the SIP call flow for our attack. And the idea is to send the SIP invite message to the SBC, and if the destination accepts our call, we will receive a 200-OK response. After that, we terminate the call by sending a SIP buy message. So now we need a tool for handling this specific cost scenario, including all the required information. And a tool which can be used for that is SIP P. SIP P is one of my favorite tools when it comes to SIP pen testing. It's actually not a hacking tool. It's a testing tool to handle specific cost 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 template, 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 SIP invite message. Here, we define a new key named hostname to set the SBC's hostname. Next, the static string psnhop.microsoft.com is set as the host part of the contact header. The caller key will be our presented caller information, for example, the COS 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 SIP TLS service and SIP P then requires a x.509 client certificate, we have to generate a self-signed certificate. Actually, it's not required or regressed by the SBC, it's just to make SIP P happy. So now it's time for 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 an external phone call through the victim's telephone account. All right, during the attack, I traced the SIP traffic on the SBC, so here we can see the SIP call flow during the attack. And as already seen in the demonstration, everything works fine and we were able to act as Microsoft to initiate the 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 the off-road or other social engineering attacks. And second, the more worst and common attack is off-road. 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,000. So as a next step, I reported the vulnerability 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 wanted to 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 hack 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 wireless 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 the 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 in TLS. However, here are some basics. If we 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 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 Team Style Grouting 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 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 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. 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 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 hardening 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. 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 Microsoft TeamSIP proxies, which indeed will prevent this attack, but it's an 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 oliquid side? Why they don't just implement appropriate authentication mechanism for Microsoft TeamS Direct Routing? And this brings us to the question, is this all olicodes or the SPC's fault? And the short answer is no. And 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 olicodes SPC is just an example in this case. So I ask at Microsoft for implementing proper authentication mechanism, such as the application-specific SIP digest authentication. This would allow to define a long password on both sides for authentication. And in addition, signing the Microsoft TeamSIP proxies with 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 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 SPC-specific configuration and it is also neither recommended nor tested by Microsoft or olicodes. 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 text. I also want to remind you to think outside the box and keep your hacker mindset. This talk is the result in the story of a security analysis of a product 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.