Phreaking 2.0 - Abusing Microsoft Teams Direct Routing
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 85 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/62233 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
DEF CON 301 / 85
24
28
29
47
51
53
59
60
62
70
72
75
80
84
85
00:00
Coxeter-GruppeATMRechter WinkelComputeranimation
00:51
Gerichtete MengeAnalysisComputersicherheitSoftwareNP-hartes ProblemVideokonferenzChatten <Kommunikation>TelekommunikationSystemplattformSystemaufrufFreier LadungsträgerRoutingGamecontrollerSISPSIP <Kommunikationsprotokoll>UDP <Protokoll>InformationKonfiguration <Informatik>Message-PassingDatentypInhalt <Mathematik>DickeEinplatinen-ComputerProdukt <Mathematik>StrömungswiderstandQuellcodeRechnernetzHypermediaInterface <Schaltung>GruppenkeimKonditionszahlIndexberechnungE-MailProxy ServerTLSDigitales ZertifikatDirekte numerische SimulationClientGebäude <Mathematik>BeweistheorieDienst <Informatik>KnotenmengeAlgorithmusAnalysisInformationPerspektiveSoftwareTelekommunikationTopologieZeichenketteCodierungEDV-BeratungSISPKommunikationssystemHydrostatikIntegralSoftwaretestTaskGrenzschichtablösungBeweistheorieGarbentheorieGruppenoperationMereologiePhysikalisches SystemPortabilitätSpeicherabzugZahlenbereichE-MailDatenflussSystemaufrufKonfigurationsraumExogene VariableInternetworkingNichtlinearer OperatorParametersystemHypermediaCASE <Informatik>Prozess <Informatik>BAYESPerfekte GruppeTemplateRoutingComputersicherheitÄußere Algebra eines ModulsPunktAuthentifikationProtokoll <Datenverarbeitungssystem>Wort <Informatik>Kartesische KoordinatenRichtungUmwandlungsenthalpieService providerMailing-ListeSkriptspracheVorzeichen <Mathematik>Elektronische PublikationClientDomain-NameWeb SiteKonditionszahlSchlüsselverwaltungSystemplattformEnterprise-Resource-PlanningFront-End <Software>Filesharing-SystemTLSMultiplikationsoperatorSchlussregelSoftwareschwachstelleFreier LadungsträgerMessage-PassingSocket-SchnittstelleDigitales ZertifikatDienst <Informatik>BenutzerbeteiligungInterface <Schaltung>GamecontrollerValiditätVideokonferenzKonfiguration <Informatik>ResultanteZeiger <Informatik>Direkte numerische SimulationProxy ServerComputeranimation
10:17
Demo <Programm>Dichte <Stochastik>VideokonferenzHypermediaSichtenkonzeptTeraelektronenvoltbereichBeweistheorieMomentenproblemSystemaufrufSkriptspracheComputeranimation
10:51
HypermediaDemo <Programm>Vorzeichen <Mathematik>Elektronische PublikationSichtenkonzeptDichte <Stochastik>Wort <Informatik>Umsetzung <Informatik>MathematikBildschirmmaskeEinplatinen-ComputerMenütechnikOffene MengeTabelleKonfigurationsraumParametersystemGruppenkeimDatentypGruppenoperationSISPQuellcodeInterface <Schaltung>Message-PassingHackerCOMSelbst organisierendes SystemMereologieRechenwerkViewerSynchronisierungImplementierungAuthentifikationUmwandlungsenthalpieMechanismus-Design-TheorieCASE <Informatik>SISPAnalysisCodeImplementierungInformationTelekommunikationTopologieCodierungHackerProdukt <Mathematik>HydrostatikProgrammverifikationGrenzschichtablösungAggregatzustandGarbentheorieProgrammdokumentationResultanteZahlenbereichDatenflussSystemaufrufKonfigurationsraumEinflussgrößeServerExogene VariableSpannweite <Stochastik>ComputervirusCASE <Informatik>Wurzel <Mathematik>InstantiierungComputersicherheitPay-TVÄußere Algebra eines ModulsAdditionStrömungsrichtungNetzadresseSchnittmengeEigentliche AbbildungAuthentifikationKartesische KoordinatenFirewallInstallation <Informatik>RichtungUmwandlungsenthalpieService providerBrowserGoogolSoundverarbeitungQuellcodeVorzeichen <Mathematik>Explosion <Stochastik>Elektronische PublikationClientPasswortDifferenteAutorisierungWechselseitige InformationElektronischer ProgrammführerTLSSchlussregelSoftwareschwachstelleURLDigitales ZertifikatDienst <Informatik>Social Engineering <Sicherheit>GamecontrollerCloud ComputingComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:00
And right now, we have Moritz Averill, and he will be giving a talk on Microsoft Teams. Let's hear it out, come on! Alright, hi DevCon!
00:22
Oh, do we have the presentation on the screen?
00:42
In this HDMI cable, right here. And give it in presenter mode. Perfect. Alright, so, hi DevCon again!
01:00
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 Crowding. First of all, a few words about myself. My name is Moritz Averill, I'm a senior IT security consultant and penetration tester
01:25
for a German company called SUS. I'm interested and have several years of professional experiences in security analysis of common enterprise IT stuff, including hard-end software, especially communication systems and infrastructures.
01:43
In the next couple of minutes, I will show you how Microsoft Teams Direct Crowding can be abused for tough road 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.
02:03
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 for making and receiving external phone calls,
02:23
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.
02:41
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 Crowding. Direct Crowding requires the operation of a dedicated session border controller, and this session border controller must be reachable from the internet.
03:01
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, secure web sockets, and WebRTC. The communication between the Microsoft Teams SIP proxies and the SPC
03:23
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 SPC. So, let's take a brief look at what SIP actually is.
03:40
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. Alright, so how are we going to start? Well, on the Teams side, you mainly have to configure the full qualified domain name of the SPC,
04:02
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, but as already mentioned, Microsoft Teams direct routing requires a SPC, and this SPC must be tested and certified by Microsoft,
04:24
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. Alright, so let's configure it.
04:42
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.
05:06
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 carrier in Germany,
05:22
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,
05:42
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,
06:02
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.
06:24
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,
06:42
it needs to be classified by the SPC. So, this rule tells us that the host name of the SPC 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.
07:01
This rule tells us that the static string must be included inside the SIP message at the specific SIP header. In detail, this means that the static string pstnhub.microsoft.com must be set at the host part of the contact header inside the SIP message received from Microsoft.
07:20
And after reviewing the rest of the configuration, no further conditions or authentication are required for a 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 SIP message, send it to the SPC and get correctly classified?
07:43
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 the successful attack, we need to know the full qualified domain name of the SPC. But, yeah, this is a simple task.
08:01
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 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.
08:25
And the idea is to send the SIP invite message to the SPC 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.
08:40
So, now we need a tool to handle this specific call scenario, including all the required information. And, a tool which can be used for that is SIPp. SIPp is one of my favorite tools when it comes to SIP pen testing. It's actually not a hacking tool, it's a SIP testing tool to handle specific call scenarios and testing your phone systems.
09:02
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
09:20
is the SIP invite message. Here we define a new key named hostname to set the SPC's hostname. Next, the static string pstinhub.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.
09:43
And finally, the service key will be our destination phone number which we want to call. Alright, 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,
10:03
we have to generate a self-signed certificate. Actually, it's not required or requested by the SPC, it's just to make SIP-P happy. So, now it's time for a short demonstration.
10:26
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 a few moments, we successfully initiated an external phone call through the victim's telephone account.
11:01
Alright, during the attack I traced the SIP traffic on the SPC, 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 an external phone call through the victim's telephone account. So, now you may ask yourself, what's the impact of this issue?
11:24
Well, there are two major problems here. First, we are now able to act as the victim to perform CO 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
11:45
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 thousands of dollars.
12:04
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.
12:21
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.
12:42
Here we can see a short abstract of the IP address assignments within this range. And, yeah, the smart hacker few 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.
13:01
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.
13:20
And, after about 20 tries, I finally got an IP address of the whitelisted IP range. So, afterwards, I assigned this IP address to an EC2 instance and, again, was able to exploit this issue.
13:42
So, I reported my new insights to the manufacturer and, after a few days, I got a response.