1
00:00:00,055 --> 00:00:02,760
- And right now we have Moritz Abrell

2
00:00:02,760 --> 00:00:05,160
and he will be giving a
talk on Microsoft teams.

3
00:00:06,140 --> 00:00:07,590
Lets hear it up, come on.

4
00:00:07,590 --> 00:00:11,423
(crowd cheering and clapping)

5
00:00:19,609 --> 00:00:20,442
- All right.

6
00:00:20,442 --> 00:00:21,275
Hi, DEFCON.

7
00:00:25,680 --> 00:00:29,943
Oh, do we have the
presentation on the screen?

8
00:00:41,340 --> 00:00:43,196
- Plug in this HDMI cable?

9
00:00:43,196 --> 00:00:44,098
- Ah, okay.

10
00:00:44,098 --> 00:00:45,515
- Oh, I got that.

11
00:00:50,301 --> 00:00:51,630
And you have it in presenter mode.

12
00:00:51,630 --> 00:00:52,463
Perfect.

13
00:00:53,503 --> 00:00:56,503
(audience clapping)

14
00:00:57,540 --> 00:01:01,380
- All right, So hi DEFCON
again, hope you all doing well

15
00:01:01,380 --> 00:01:03,660
and have a great conference.

16
00:01:03,660 --> 00:01:05,880
I want to thanks the
DEFCON team for their work

17
00:01:05,880 --> 00:01:09,030
and making such a fantastic
conference each year.

18
00:01:09,030 --> 00:01:11,550
I'm so excited for being
here today and talking

19
00:01:11,550 --> 00:01:15,097
about my research, Phreaking
2.0 abusing Microsoft teams

20
00:01:15,097 --> 00:01:16,383
Direct Routing.

21
00:01:17,520 --> 00:01:19,710
First of all, a few words about myself.

22
00:01:19,710 --> 00:01:21,060
My name is Moritz Abrell.

23
00:01:21,060 --> 00:01:24,990
I'm a senior IT security
consultant and penetration tester

24
00:01:24,990 --> 00:01:27,750
for a German company called SySS GmbH.

25
00:01:27,750 --> 00:01:29,970
I am interested and have several years

26
00:01:29,970 --> 00:01:33,120
of professional experiences
in security analysis

27
00:01:33,120 --> 00:01:34,320
of common enterprises.

28
00:01:34,320 --> 00:01:37,830
IT stuff, including hard
and software, especially

29
00:01:37,830 --> 00:01:40,143
communication systems and infrastructures.

30
00:01:43,050 --> 00:01:45,030
In the next couple of
minutes, I will show you how

31
00:01:45,030 --> 00:01:47,250
Microsoft teams direct
routing can be abused

32
00:01:47,250 --> 00:01:49,440
for top fraud attacks from the perspective

33
00:01:49,440 --> 00:01:52,353
of an unauthenticated external attacker.

34
00:01:53,430 --> 00:01:55,020
In addition, I will tell you the story

35
00:01:55,020 --> 00:01:57,360
about the vulnerability
disclosure and the failure

36
00:01:57,360 --> 00:02:00,693
of the manufacturer to
provide an appropriate fix.

37
00:02:03,060 --> 00:02:05,010
I guess everyone knows Microsoft teams

38
00:02:05,010 --> 00:02:07,410
in a nutshell Microsoft
teams is a communication

39
00:02:07,410 --> 00:02:10,650
platform hosted by Microsoft,
including typical unified

40
00:02:10,650 --> 00:02:14,430
communication features such as
audio and video conferencing

41
00:02:14,430 --> 00:02:16,563
chat, file sharing and so on.

42
00:02:17,520 --> 00:02:20,310
Microsoft teams also offers
the ability to extend it

43
00:02:20,310 --> 00:02:23,250
from making and receiving
external phone calls

44
00:02:23,250 --> 00:02:25,650
which is a nice feature
in many business cases.

45
00:02:25,650 --> 00:02:28,110
For example, if you want
to provide your employees

46
00:02:28,110 --> 00:02:29,860
with a cross platform software

47
00:02:31,410 --> 00:02:33,780
And for enabling this,
you have two options.

48
00:02:33,780 --> 00:02:36,900
In the most cases, the first
one is to insert some coins

49
00:02:36,900 --> 00:02:40,143
to Microsoft and using Microsoft
as a telephone carrier.

50
00:02:41,070 --> 00:02:42,963
This scenario is called Calling plan.

51
00:02:43,920 --> 00:02:47,190
However if you want to use
your existing telephone carrier

52
00:02:47,190 --> 00:02:48,870
you have to choose the second scenario

53
00:02:48,870 --> 00:02:50,733
which is called Direct routing.

54
00:02:51,660 --> 00:02:53,490
Direct routing requires the operation

55
00:02:53,490 --> 00:02:56,010
of a dedicated session border controller.

56
00:02:56,010 --> 00:02:58,320
and this session border
controller must be reachable

57
00:02:58,320 --> 00:02:59,223
from the internet.

58
00:03:00,720 --> 00:03:02,250
This also enables the integration

59
00:03:02,250 --> 00:03:06,420
of your existing infrastructure,
like a PBX legacy devices

60
00:03:06,420 --> 00:03:08,853
such as fax or a contact center.

61
00:03:11,130 --> 00:03:13,350
The Communication between
the Microsoft teams client

62
00:03:13,350 --> 00:03:15,390
and the backend is done with HTTPS,

63
00:03:15,390 --> 00:03:17,643
secure web sockets and web RTC.

64
00:03:19,110 --> 00:03:21,930
The communication between the
Microsoft teams SIP proxies

65
00:03:21,930 --> 00:03:25,530
and the SBC is done with the
session initiation protocol

66
00:03:25,530 --> 00:03:27,660
which is also the most
commonly used protocol

67
00:03:27,660 --> 00:03:28,923
by telephone providers.

68
00:03:30,630 --> 00:03:32,640
In this talk, we focus
on the communication

69
00:03:32,640 --> 00:03:35,407
between the Microsoft team
SIP proxies and the SBC.

70
00:03:36,480 --> 00:03:39,423
So let's take a brief look
at what SIP actually is.

71
00:03:40,380 --> 00:03:41,880
SIP is similar to HTTP.

72
00:03:41,880 --> 00:03:44,459
So it's a text based
protocol with a header

73
00:03:44,459 --> 00:03:48,660
and a body part rigorous line,
including a rigorous method

74
00:03:48,660 --> 00:03:51,483
as well as headers with
values and parameters.

75
00:03:53,520 --> 00:03:54,353
All right.

76
00:03:54,353 --> 00:03:55,503
So how are we gonna start?

77
00:03:56,970 --> 00:03:58,200
Well, on the teams side

78
00:03:58,200 --> 00:04:00,780
you mainly have to configure
the full qualified domain name

79
00:04:00,780 --> 00:04:04,203
of the SBC, which must be already
registered to your tenant.

80
00:04:05,790 --> 00:04:09,060
There are a handful of other
configuration options, however

81
00:04:09,060 --> 00:04:10,860
they are not relevant for this talk.

82
00:04:11,730 --> 00:04:12,900
So we are mainly done

83
00:04:12,900 --> 00:04:15,990
on the Microsoft team side,
but as already mentioned

84
00:04:15,990 --> 00:04:19,350
Microsoft teams direct
routing requires SBC.

85
00:04:19,350 --> 00:04:22,590
And this SBC must be tested and certified

86
00:04:22,590 --> 00:04:26,550
by Microsoft and a list of
such devices can be seen

87
00:04:26,550 --> 00:04:31,550
in the Microsoft documentation
and the very first ones,

88
00:04:31,800 --> 00:04:35,160
and in my experiences, the
more common session border

89
00:04:35,160 --> 00:04:37,953
controllers are devices
from all your codes.

90
00:04:39,093 --> 00:04:43,080
All right, So let's
configure it, but to not

91
00:04:43,080 --> 00:04:45,390
reinvent the wheel and to
follow the recommendations

92
00:04:45,390 --> 00:04:48,060
of the certification process by Microsoft

93
00:04:48,060 --> 00:04:49,080
we go to the audio codes

94
00:04:49,080 --> 00:04:51,873
website and search for
suitable configuration file.

95
00:04:53,400 --> 00:04:56,250
And by selecting Microsoft
teams as the application

96
00:04:56,250 --> 00:04:58,620
we get the list of
configuration guidelines

97
00:04:58,620 --> 00:05:00,255
including some carrier specific items

98
00:05:00,255 --> 00:05:02,913
as well as a general configuration node.

99
00:05:05,820 --> 00:05:08,280
In addition, there is a nice
configuration with that bay.

100
00:05:08,280 --> 00:05:10,410
You can click together
all your requirements

101
00:05:10,410 --> 00:05:14,970
and finally get suitable
configuration. By the way

102
00:05:14,970 --> 00:05:17,610
this is exactly what one
of our customers did.

103
00:05:17,610 --> 00:05:19,440
He ordered a session border controller

104
00:05:19,440 --> 00:05:22,377
from one of the biggest carrier in Germany

105
00:05:22,377 --> 00:05:25,770
and they said we
configured it to according

106
00:05:25,770 --> 00:05:29,520
to the configuration guidelines
together with audio codes.

107
00:05:29,520 --> 00:05:31,923
So what could possibly go wrong?

108
00:05:33,240 --> 00:05:36,280
Well let's take a closer look
to the applied configuration

109
00:05:37,803 --> 00:05:40,410
Here we can see the topology overview

110
00:05:40,410 --> 00:05:43,590
of our applied configuration,
including two sections

111
00:05:43,590 --> 00:05:48,030
so called IP groups, one for
the Microsoft teams direction

112
00:05:48,030 --> 00:05:49,743
and one for our telephone carrier.

113
00:05:51,174 --> 00:05:54,660
And if a call comes in,
it goes roughly this way

114
00:05:54,660 --> 00:05:58,140
from an ethernet interface
to the applied IP group

115
00:05:58,140 --> 00:06:01,890
which includes the media
handler and the SIP interface.

116
00:06:01,890 --> 00:06:06,630
And then to the routing engine
named IP to IP routing based

117
00:06:06,630 --> 00:06:09,000
on the configured rules
inside this routing engine

118
00:06:09,000 --> 00:06:10,140
it goes likely the same way

119
00:06:10,140 --> 00:06:12,393
out to the destination SIP service.

120
00:06:14,340 --> 00:06:16,170
So one of the first steps

121
00:06:16,170 --> 00:06:19,170
during a security analysis
is taking a closer look

122
00:06:19,170 --> 00:06:21,693
to the rule set of the IP to IP routing.

123
00:06:23,910 --> 00:06:27,960
And there I saw this rule, which
means everything that comes

124
00:06:27,960 --> 00:06:30,963
in from the Microsoft side
goes to the telephone carrier.

125
00:06:32,580 --> 00:06:34,410
For example, if you're making a call

126
00:06:34,410 --> 00:06:36,910
from your Microsoft teams
client, it goes this way

127
00:06:39,150 --> 00:06:42,450
but before a SIP message is
handled by the routing engine

128
00:06:42,450 --> 00:06:45,000
it needs to be classified by the SBC.

129
00:06:45,000 --> 00:06:48,120
So this rule tells us that the host name

130
00:06:48,120 --> 00:06:50,880
of the SBC must be set as destination host

131
00:06:50,880 --> 00:06:53,613
inside the SIP message
received from Microsoft.

132
00:06:55,050 --> 00:06:56,880
Moreover, other things are required

133
00:06:56,880 --> 00:06:59,130
which are defined in
the team's contact rule.

134
00:07:00,715 --> 00:07:04,230
This rule tells us that the
static string must be included

135
00:07:04,230 --> 00:07:06,843
inside a SIP message at
the specific SIP header.

136
00:07:08,070 --> 00:07:10,020
In detail this means
that the static string

137
00:07:10,020 --> 00:07:12,785
'pstnhub.microsoft.com' must be set

138
00:07:12,785 --> 00:07:15,960
at the host part of the contact header

139
00:07:15,960 --> 00:07:18,363
inside the SIP message
received from Microsoft.

140
00:07:20,190 --> 00:07:22,980
And after reviewing the
rest of the configuration

141
00:07:22,980 --> 00:07:25,650
no further conditions or
authentications are required

142
00:07:25,650 --> 00:07:27,299
for a correct classification

143
00:07:27,299 --> 00:07:30,480
for incoming request from Microsoft.

144
00:07:30,480 --> 00:07:35,480
So, at this point I ask
myself, is it possible to

145
00:07:35,670 --> 00:07:38,460
include the SBCs host
name inside a SIP message

146
00:07:38,460 --> 00:07:41,493
send it to the SBC and
get correctly classified.

147
00:07:42,780 --> 00:07:46,470
Or in other words, we
pretend to be Microsoft teams

148
00:07:46,470 --> 00:07:48,780
and trying to initiate
an external phone call

149
00:07:48,780 --> 00:07:50,680
through the victim's telephone account

150
00:07:52,530 --> 00:07:54,540
but for the successful attack

151
00:07:54,540 --> 00:07:57,663
we need to know the full
qualified domain name of the SBC.

152
00:07:58,620 --> 00:08:00,750
But yeah, this is a simple task.

153
00:08:00,750 --> 00:08:01,920
On the one hand, we can find

154
00:08:01,920 --> 00:08:04,290
out the SBCs full qualified domain name.

155
00:08:04,290 --> 00:08:06,540
If a valid then is pointer entry exists

156
00:08:06,540 --> 00:08:09,150
on and on the other hand, the common name

157
00:08:09,150 --> 00:08:13,433
or subject alternative name
values in the X.509 certificate

158
00:08:13,433 --> 00:08:16,503
of the exposed SIP-TLS
service can be extracted.

159
00:08:18,510 --> 00:08:20,430
So we have the host name

160
00:08:20,430 --> 00:08:23,793
and now we have to define the
SIP core flow for our tech.

161
00:08:25,290 --> 00:08:28,800
And the idea is to send the
SIP invite message to the SBC.

162
00:08:28,800 --> 00:08:31,440
And if the destination accepts our call

163
00:08:31,440 --> 00:08:34,113
we will receive a 200-OK, response.

164
00:08:35,760 --> 00:08:37,290
After that, we terminate the call

165
00:08:37,290 --> 00:08:38,793
by sending a SIP BYE message.

166
00:08:40,140 --> 00:08:42,000
So now we need the tool

167
00:08:42,000 --> 00:08:43,860
for handle this specific cost scenario

168
00:08:43,860 --> 00:08:45,760
including all the required information

169
00:08:46,890 --> 00:08:49,190
and a tool which can be
used for that is SIPp.

170
00:08:50,414 --> 00:08:52,230
SIPp is one of my favorite tools.

171
00:08:52,230 --> 00:08:54,570
When it comes to SIP pen testing

172
00:08:54,570 --> 00:08:56,280
it's actually not a hacking tool.

173
00:08:56,280 --> 00:09:00,180
It's a SIP testing tool to
handle specific call scenarios

174
00:09:00,180 --> 00:09:01,803
and testing your phone systems.

175
00:09:02,670 --> 00:09:05,640
And these scenarios are
defined XML templates

176
00:09:05,640 --> 00:09:07,173
and are highly flexible.

177
00:09:08,160 --> 00:09:10,500
Thus, we can write our own XML template

178
00:09:10,500 --> 00:09:11,700
including our core flow

179
00:09:11,700 --> 00:09:14,133
for the attack and all
required information.

180
00:09:15,870 --> 00:09:17,550
And I've already done this.

181
00:09:17,550 --> 00:09:18,713
And the most interesting part

182
00:09:18,713 --> 00:09:21,483
of this XML template is
the SIP invite message.

183
00:09:22,380 --> 00:09:24,330
Here we define a new key named hostname to

184
00:09:24,330 --> 00:09:28,398
set the SBCs hostname
next, the static string

185
00:09:28,398 --> 00:09:30,624
pstn.microsoft.com is set

186
00:09:30,624 --> 00:09:35,061
as the host part of the
contact header, the service

187
00:09:35,061 --> 00:09:38,550
the caller key will be our
presented caller information.

188
00:09:38,550 --> 00:09:41,433
For example, the CEO's
phone number of our target.

189
00:09:42,870 --> 00:09:45,690
And finally the service key
will be our destination phone

190
00:09:45,690 --> 00:09:47,583
number which we want to call.

191
00:09:50,430 --> 00:09:54,000
All right, so here we
can see how we can launch

192
00:09:54,000 --> 00:09:56,040
our proof of concept script

193
00:09:56,040 --> 00:09:58,800
but because we talk to the SIP TLS service

194
00:09:58,800 --> 00:10:03,570
and SIPp then requires
X.509 client certificate

195
00:10:03,570 --> 00:10:05,870
we have to generate the
safe sign certificate.

196
00:10:06,960 --> 00:10:09,960
Actually it's not required
or requested by the SBC.

197
00:10:09,960 --> 00:10:11,553
It's just to make SIPp happy.

198
00:10:13,860 --> 00:10:17,103
So now it's time for short demonstration.

199
00:10:25,860 --> 00:10:27,390
So, on the right side

200
00:10:27,390 --> 00:10:31,260
we can see our destination
phone, which we want to call.

201
00:10:31,260 --> 00:10:34,680
And mainly on the left side,
our proof of concept script

202
00:10:34,680 --> 00:10:39,680
which is executed and after
about yeah, a few moments

203
00:10:41,790 --> 00:10:44,490
we successfully initiated
external phone call

204
00:10:44,490 --> 00:10:46,440
through the victim's telephone account.

205
00:10:54,270 --> 00:10:57,333
Oh, (audience clapping)

206
00:11:01,710 --> 00:11:03,660
All right, during the
attack, I traced the SIP

207
00:11:03,660 --> 00:11:05,010
traffic on the SBC.

208
00:11:05,010 --> 00:11:07,440
So here we can see the SIP call flow

209
00:11:07,440 --> 00:11:10,530
of during the attack and as already seen

210
00:11:10,530 --> 00:11:12,690
in the demonstration,
everything works fine.

211
00:11:12,690 --> 00:11:14,850
And we were able to act this Microsoft to

212
00:11:14,850 --> 00:11:16,470
initiate the external phone call

213
00:11:16,470 --> 00:11:18,420
through the victim's telephone account.

214
00:11:19,500 --> 00:11:23,223
So now you may ask yourself
what's the impact of this issue?

215
00:11:24,270 --> 00:11:27,663
Well, there are two major problems here.

216
00:11:28,710 --> 00:11:30,960
First, we are now able
to act as the victim to

217
00:11:30,960 --> 00:11:34,650
perform CEO fraud or other
social engineering attacks.

218
00:11:34,650 --> 00:11:36,840
And second, the more worst

219
00:11:36,840 --> 00:11:39,420
and common attack is Toll fraud.

220
00:11:39,420 --> 00:11:42,660
Hereby the attacker uses this
security issue to perform

221
00:11:42,660 --> 00:11:45,070
calls through the
victim's telephone account

222
00:11:45,070 --> 00:11:48,330
with the destination of
a premium phone number

223
00:11:48,330 --> 00:11:50,610
and this premium phone
number is under the attackers

224
00:11:50,610 --> 00:11:53,283
control and therefore he gets the money.

225
00:11:54,930 --> 00:11:57,720
We had customers who were
affected by such kind of attacks

226
00:11:57,720 --> 00:12:00,210
which results in an
explosive telephone bill

227
00:12:00,210 --> 00:12:02,133
within ten thousands of dollars.

228
00:12:04,110 --> 00:12:05,790
So as the next step

229
00:12:05,790 --> 00:12:08,520
I reported the vulnerability
to the manufacturer.

230
00:12:08,520 --> 00:12:11,070
And after a few days, I got the response

231
00:12:11,070 --> 00:12:13,563
that the configuration
guidelines are patched.

232
00:12:14,910 --> 00:12:16,680
But when I checked the differences

233
00:12:16,680 --> 00:12:19,360
in the configuration
guides, I noticed this

234
00:12:21,270 --> 00:12:24,619
The manufacturer added
this source IP filter to

235
00:12:24,619 --> 00:12:28,830
allow incoming traffic only
from this source IP range.

236
00:12:28,830 --> 00:12:31,590
But when I saw this, I
was a little bit surprised

237
00:12:31,590 --> 00:12:33,855
about the big range and
therefore wanted to check

238
00:12:33,855 --> 00:12:36,330
if this is indeed exclusively assigned

239
00:12:36,330 --> 00:12:40,323
to Microsoft, long story short, it is not.

240
00:12:42,150 --> 00:12:43,620
Here we can see a short abstract

241
00:12:43,620 --> 00:12:46,473
of the IP address assignments
within this range.

242
00:12:47,850 --> 00:12:49,890
And yeah, the smart hack

243
00:12:49,890 --> 00:12:52,410
of you already noticed an
interesting assignment.

244
00:12:52,410 --> 00:12:54,960
It's AWS, where we can set up an EC two

245
00:12:54,960 --> 00:12:57,540
instance or other cloud services

246
00:12:57,540 --> 00:12:59,740
and maybe using an IP
address of this range.

247
00:13:01,440 --> 00:13:03,266
So for our luck

248
00:13:03,266 --> 00:13:06,450
AWS has this public
exposed trace file where

249
00:13:06,450 --> 00:13:09,333
you can check all IP
address assignments in AWS.

250
00:13:10,350 --> 00:13:12,660
So, you know what comes next?

251
00:13:12,660 --> 00:13:15,480
I logged into my AWS account selecting one

252
00:13:15,480 --> 00:13:17,550
of the correct AWS locations

253
00:13:17,550 --> 00:13:20,280
and tried to get such an IP address.

254
00:13:20,280 --> 00:13:22,480
And after about 20 tries

255
00:13:23,580 --> 00:13:26,433
I finally got an IP address
of the white list IP range.

256
00:13:28,083 --> 00:13:31,083
(Audience clapping)

257
00:13:34,590 --> 00:13:38,790
So afterwards I assigned this
IP address to EC two instance

258
00:13:38,790 --> 00:13:41,073
and again was able to exploit this issue.

259
00:13:42,150 --> 00:13:45,690
So I reported my new
insights to the manufacturer.

260
00:13:45,690 --> 00:13:48,000
And after a few days I got a response

261
00:13:48,000 --> 00:13:51,693
and now the manufacturer refers
to the use of mutual TLS.

262
00:13:53,130 --> 00:13:54,510
So let's take a brief look

263
00:13:54,510 --> 00:13:59,510
at X.509 certificate
verification NTLS and mutual TLS.

264
00:13:59,880 --> 00:14:01,410
I think most of you have deep knowledge

265
00:14:01,410 --> 00:14:04,530
about the certificate
verification and TLS.

266
00:14:04,530 --> 00:14:07,050
However, here are some basics.

267
00:14:07,050 --> 00:14:10,650
If you communicate to a TLS
secured service like HTTPS

268
00:14:10,650 --> 00:14:13,170
your browsers verifies if
the requested host name

269
00:14:13,170 --> 00:14:16,100
match the common name or subject
alternative name verifies

270
00:14:16,100 --> 00:14:19,770
if the certificate is signed
by a trusted certificate

271
00:14:19,770 --> 00:14:21,600
authority and checks whether

272
00:14:21,600 --> 00:14:23,200
the certificate is valid or not.

273
00:14:24,840 --> 00:14:27,030
So the server includes the certificate

274
00:14:27,030 --> 00:14:28,500
inside the TLS centric

275
00:14:28,500 --> 00:14:30,663
and the client can
verify all these things.

276
00:14:32,100 --> 00:14:35,280
If Mutual TLS is enabled
the server requests

277
00:14:35,280 --> 00:14:38,610
the client certificate and
the client sends it back.

278
00:14:38,610 --> 00:14:42,270
But due the communication
is initiated by the client.

279
00:14:42,270 --> 00:14:45,240
The server does only know the
incoming client IP address

280
00:14:45,240 --> 00:14:47,880
and therefore the server is not able to

281
00:14:47,880 --> 00:14:49,230
validate the common name

282
00:14:49,230 --> 00:14:51,993
or subject the alternative
name against this value.

283
00:14:52,920 --> 00:14:54,900
So if we move this behavior

284
00:14:54,900 --> 00:14:58,390
to our Microsoft teams style
crowding installation, it means

285
00:14:59,558 --> 00:15:01,110
that the SBC does not
validate the common name

286
00:15:01,110 --> 00:15:02,970
or subject alternative name

287
00:15:02,970 --> 00:15:04,953
for incoming request from Microsoft.

288
00:15:06,780 --> 00:15:09,300
So I checked the details about mutual TLS

289
00:15:09,300 --> 00:15:11,640
in the Microsoft documentation, and there

290
00:15:11,640 --> 00:15:15,550
this node advises to trust
these tools, root certificates

291
00:15:16,470 --> 00:15:18,543
However both of them are widely used.

292
00:15:19,590 --> 00:15:21,750
I cross check this also in the Microsoft,

293
00:15:21,750 --> 00:15:23,490
in the audio code documentation.

294
00:15:23,490 --> 00:15:26,460
And there is also pointed out to trust the

295
00:15:26,460 --> 00:15:27,813
Baltimore Root certificate,

296
00:15:29,100 --> 00:15:30,810
but as already mentioned, both

297
00:15:30,810 --> 00:15:32,310
of them are widely used.

298
00:15:32,310 --> 00:15:34,290
For example, this is the signing tree

299
00:15:34,290 --> 00:15:35,990
of the Baltimore Root certificate.

300
00:15:37,080 --> 00:15:40,380
So a getting correctly
signed a certificate by one

301
00:15:40,380 --> 00:15:43,260
of these two root certificate
authorities cannot

302
00:15:43,260 --> 00:15:44,403
be that hard, right?

303
00:15:45,900 --> 00:15:48,240
Well, taking a closer
look to the signing tree.

304
00:15:48,240 --> 00:15:50,804
I saw this one and after some Google work

305
00:15:50,804 --> 00:15:53,880
I found this service
provider where you can buy a

306
00:15:53,880 --> 00:15:56,130
certificate automatically signed it by the

307
00:15:56,130 --> 00:15:59,613
Baltimore root certificate for about $150.

308
00:16:01,590 --> 00:16:04,680
So we can set up an
arbitrary host name for our

309
00:16:04,680 --> 00:16:06,840
tech EC two instance, getting a correctly

310
00:16:06,840 --> 00:16:07,980
signed certificate.

311
00:16:07,980 --> 00:16:10,560
And we are again, able to
exploit this issue even

312
00:16:10,560 --> 00:16:12,633
if mutual TLS is enforced.

313
00:16:14,994 --> 00:16:17,994
(Audience clapping)

314
00:16:20,610 --> 00:16:24,203
So I reported my new insights
to the manufacturer again

315
00:16:24,203 --> 00:16:26,460
(audience laughing)

316
00:16:26,460 --> 00:16:29,880
and after a few days, I
got the response within

317
00:16:29,880 --> 00:16:31,323
the following statements.

318
00:16:32,430 --> 00:16:34,770
The audio codes configuration
guides are focused on

319
00:16:34,770 --> 00:16:38,280
interworking and only described
the basic security rules.

320
00:16:38,280 --> 00:16:40,710
(audience laughing slowly)

321
00:16:40,710 --> 00:16:43,683
Nevertheless, further measures
and fixes were provided.

322
00:16:44,580 --> 00:16:47,110
Follow the SBC security
and harming guideline

323
00:16:48,600 --> 00:16:51,000
Filter the incoming calling party number

324
00:16:51,000 --> 00:16:53,613
and implement separate firewall rules.

325
00:16:54,810 --> 00:16:55,643
All right

326
00:16:55,643 --> 00:16:57,873
so let's have a closer look
at these recommendations.

327
00:16:59,640 --> 00:17:01,620
First of all, the security
guideline provided

328
00:17:01,620 --> 00:17:05,490
by SBC manufacturer includes
good and proven security

329
00:17:05,490 --> 00:17:09,180
recommendation and configurations.

330
00:17:09,180 --> 00:17:11,040
However, if we follow this guide

331
00:17:11,040 --> 00:17:14,400
Microsoft teams direct
routing will no longer work

332
00:17:14,400 --> 00:17:17,553
so we can skip this.

333
00:17:20,010 --> 00:17:23,340
Next the manufacturer recommends
to filter the incoming

334
00:17:23,340 --> 00:17:25,980
calling party number, but yeah

335
00:17:25,980 --> 00:17:28,860
we have control over
this value and finding

336
00:17:28,860 --> 00:17:31,590
out the victim's phone
number is not that hard,

337
00:17:31,590 --> 00:17:33,720
a quick google search returns
the needed information

338
00:17:33,720 --> 00:17:34,743
in the most cases.

339
00:17:36,840 --> 00:17:39,010
So let's check the last recommendation

340
00:17:40,080 --> 00:17:41,945
the manufacturer recommends

341
00:17:41,945 --> 00:17:45,630
or the manufacturer implemented
the additional section

342
00:17:45,630 --> 00:17:50,193
configure firewall settings,
but keep in mind it's optional.

343
00:17:52,320 --> 00:17:55,829
And these virus settings allowing
incoming TCP traffic only

344
00:17:55,829 --> 00:17:59,040
from the documented
Microsoft teams SIP proxies

345
00:17:59,040 --> 00:18:01,860
which indeed will prevent this attack

346
00:18:01,860 --> 00:18:05,313
but is an IP filter as
authentication state of the art?

347
00:18:06,180 --> 00:18:07,980
And it should also be noted

348
00:18:07,980 --> 00:18:10,410
that these firewall settings
are also not applied

349
00:18:10,410 --> 00:18:12,333
if the configuration result is used.

350
00:18:14,040 --> 00:18:16,400
So at this point, I ask
myself, what's going

351
00:18:16,400 --> 00:18:19,890
on at the audio code
side, why they don't just

352
00:18:19,890 --> 00:18:22,552
implement appropriate
authentication mission

353
00:18:22,552 --> 00:18:24,873
for Microsoft teams direct routing?

354
00:18:26,070 --> 00:18:27,870
And this brings us to the question

355
00:18:27,870 --> 00:18:30,273
is this all audio codes or SBCs fault?

356
00:18:31,661 --> 00:18:33,363
And the short answer is no.

357
00:18:34,410 --> 00:18:36,540
And this is just the story

358
00:18:36,540 --> 00:18:38,970
about the manufacturer
who tries to secure this

359
00:18:38,970 --> 00:18:41,040
by the limited hardening measures provided

360
00:18:41,040 --> 00:18:44,430
by Microsoft. In general,
the describe problems

361
00:18:44,430 --> 00:18:46,140
are affecting to all Microsoft teams,

362
00:18:46,140 --> 00:18:47,820
direct routing installations.

363
00:18:47,820 --> 00:18:51,990
and the audio quotes SBC is
just an example in this case.

364
00:18:51,990 --> 00:18:54,750
So I ask at Microsoft

365
00:18:54,750 --> 00:18:57,050
for implementing proper
authentication mission

366
00:18:58,110 --> 00:19:02,250
such as the application specific
SIP Digest authentication.

367
00:19:02,250 --> 00:19:04,230
This will allow to define a long password

368
00:19:04,230 --> 00:19:06,540
on both sides for authentication.

369
00:19:06,540 --> 00:19:10,380
And in addition, signing the
Microsoft team SIP proxies

370
00:19:10,380 --> 00:19:13,650
with dedicated and
exclusively used certificate

371
00:19:13,650 --> 00:19:16,623
authority will secure the
mutual TlS authentication.

372
00:19:17,580 --> 00:19:20,343
But until now the case is still open.

373
00:19:22,290 --> 00:19:25,560
So to give you a few
recommendations to secure

374
00:19:25,560 --> 00:19:29,160
your existing Microsoft teams,
direct routing installation

375
00:19:29,160 --> 00:19:33,060
you can do implement
strict IP filters, which is

376
00:19:33,060 --> 00:19:36,063
currently the only effective
way to prevent this attack.

377
00:19:37,020 --> 00:19:40,800
Next, you can configure
static subject alternative

378
00:19:40,800 --> 00:19:43,470
name filtering but it should be noted

379
00:19:43,470 --> 00:19:45,930
that this is a SBC specific configuration

380
00:19:45,930 --> 00:19:48,390
and it is also native recommended

381
00:19:48,390 --> 00:19:51,210
nor tested by Microsoft or audio codes.

382
00:19:51,210 --> 00:19:54,360
And it's not possible in every use case.

383
00:19:54,360 --> 00:19:57,930
So moreover limiting the call duration,

384
00:19:57,930 --> 00:20:00,120
deny premium phone numbers and logging

385
00:20:00,120 --> 00:20:02,220
and monitoring are recommended in general.

386
00:20:04,200 --> 00:20:06,273
So I come to my final thoughts.

387
00:20:07,909 --> 00:20:11,610
Current Direct Routing
installations may be vulnerable

388
00:20:11,610 --> 00:20:13,800
to fraud threats.

389
00:20:13,800 --> 00:20:15,540
I also want to remind you to think

390
00:20:15,540 --> 00:20:18,420
outside the box and keep
your hacker mindset.

391
00:20:18,420 --> 00:20:19,650
This target is the result

392
00:20:19,650 --> 00:20:22,620
and the story of offer security analysis

393
00:20:22,620 --> 00:20:25,660
of a product that is widespread
in use for many years

394
00:20:26,610 --> 00:20:28,950
be not afraid of big names like Microsoft.

395
00:20:28,950 --> 00:20:32,280
And even if the manufacturer
provides effects

396
00:20:32,280 --> 00:20:34,890
ask yourself how effective is this fix?

397
00:20:34,890 --> 00:20:38,283
Can I bypass it or is it
exploitable in another way?

398
00:20:39,120 --> 00:20:41,820
And finally Phreak the planet.

399
00:20:41,820 --> 00:20:42,680
Thanks.

400
00:20:42,680 --> 00:20:45,847
(Audience applauding)