-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
503 lines (294 loc) · 17.1 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
<!DOCTYPE HTML>
<html>
<head>
<meta charset="utf-8">
<title>OAuth.jp</title>
<meta name="author" content="Nov Matake">
<meta name="description" content="Author: Nov Matake Date: Oct 28th, 2020 いままで Mix-up Attack は Client が AS 毎に redirect_uri を使い分けていれば防げると信じられてきましたが、それじゃ防げないケースもあるよってのが OAuth ML …">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
<link href="/atom.xml" rel="alternate" title="OAuth.jp" type="application/atom+xml">
<link rel="canonical" href="">
<link href="/favicon.ico" rel="shortcut icon">
<link href="/stylesheets/screen.css" media="screen, projection" rel="stylesheet" type="text/css">
<link href='https://fonts.googleapis.com/css?family=Slackey' rel='stylesheet' type='text/css'>
<link href='https://fonts.googleapis.com/css?family=Fjalla+One' rel='stylesheet' type='text/css'>
<link href='https://fonts.googleapis.com/css?family=Amethysta' rel='stylesheet' type='text/css'>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>
<!--[if lt IE 9]><script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
<script type="text/javascript" src="/javascripts/jquery-tapir.js"></script>
<!-- remove or comment it to disable ajaxification -->
<!-- <script src="/javascripts/ajaxify.js"></script> -->
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-55348-17', 'auto');
ga('send', 'pageview');
</script>
</head>
<body>
<div id="wrapper">
<header id="header" class="inner"><!-- for more effects see _animate.scss -->
<h1 class="animated bounceInDown">
<a href='/'>
<div id="headerbg">
OAuth.jp
</div>
</a>
</h1>
<br>
<ul id="social-links" style="text-align:center">
<!-- Facebook -->
<li>
<a href="https://www.facebook.com/oauth.jp" class="facebook" title="Facebook"></a>
</li>
<!-- Twitter -->
<li>
<a href="https://www.twitter.com/oauthjp" class="twitter" title="Twitter"></a>
</li>
<!-- GitHub -->
<li>
<a href="https://github.com/nov" class="github" title="Github"></a>
</li>
</ul>
<!-- use full url including 'index.html' for navigation bar if you are using ajax -->
<ul id="nav">
</ul>
</header>
<div id="toload">
<!-- begin toload -->
<div id="content" class="inner">
<article class="post">
<h2 class="title">
<a href="/blog/2020/10/28/mix-up-cant-be-mitigated-by-per-as-redirect-uri/">
Mix-up Attack は Per-AS Redirect_uri では防げない</a>
</h2>
<div class="entry-content">
<div class="meta">
<div class="author">
Author: <a href="https://matake.jp">Nov Matake</a>
</div>
<div class="date">Date:
<time datetime="2020-10-28T23:05:00+09:00" pubdate data-updated="true">Oct 28<span>th</span>, 2020</time></div>
</div>
<p>いままで Mix-up Attack は Client が AS 毎に redirect_uri を使い分けていれば防げると信じられてきましたが、それじゃ防げないケースもあるよってのが <a href="https://mailarchive.ietf.org/arch/msg/oauth/RjbSwFRmLsk0EgAY2Ter-nw66EY/">OAuth ML に投稿</a>されました。</p>
<p>細かい解説は英語読んでもらうとして、シーケンスにするとこういうことです。</p>
<p><img src="/images/posts/oauth-idp-mixup-rev2.png" alt="OAuth IdP Mix-Up Attack rev.2" /></p>
<p>Attacker AS が (Display Name やロゴ等を通じて) 一見 Honest Client に見えるような Client (Attacker Client) を Honest AS に登録しておく必要があります。</p>
<p>User が Attacker AS 選んでるのに Honest AS に飛んで Approve してしまってる部分も、<a href="/blog/2016/01/12/oauth-idp-mix-up-attack/">Attacker Proxy</a> が利用可能な状況 (e.g., Client が HTTP なエンドポイントで Honest AS のログインボタン等を表示している) であればもっと違和感のないフローになるでしょう。</p>
<p>で、解決策として AuthZ Response に “iss” を含めることが提案されているのですが、「<a href="/blog/2016/01/12/oauth-idp-mix-up-attack/">悪意のある可能性があるIdPを採用しない</a>」ってのが一番の解決策であることに代わりはありません。</p>
</div>
<div class="meta">
</div>
</article>
<article class="post">
<h2 class="title">
<a href="/blog/2020/09/30/docomo-kouza-kyc/">
ドコモ口座問題</a>
</h2>
<div class="entry-content">
<div class="meta">
<div class="author">
Author: <a href="https://matake.jp">Nov Matake</a>
</div>
<div class="date">Date:
<time datetime="2020-09-30T11:40:00+09:00" pubdate data-updated="true">Sep 30<span>th</span>, 2020</time></div>
</div>
<p>忘れそうなので一旦メモ。</p>
<p>ドコモ口座の問題って、こういうことでしょ？</p>
<ol>
<li>銀行側のAALが1を満たさないので銀行側が銀行口座を保護できない</li>
<li>銀行側のAALが1を満たさないので「銀行にKYCを依拠する」というサービスのLoAが1を満たさずサービスとして成り立っていない
<ul>
<li>結果としてドコモ口座のIALは1 (= dアカウント登録直後と同等) のまま</li>
</ul>
</li>
<li>「銀行口座名義とドコモ口座名義の一致確認」と「銀行にKYCを依拠」が同時に発生してしまっている結果「銀行口座名義とドコモ口座名義の一致確認」が実質なされていない
<ul>
<li>参考) <a href="https://gist.github.com/nov/b8be7b50db48862784b470c1ae6c1718">https://gist.github.com/nov/b8be7b50db48862784b470c1ae6c1718</a></li>
</ul>
</li>
<li>口座の一致確認が行われていないためドコモも銀行口座を保護できない
<ul>
<li>ドコモ口座側のAALは1を満たすのでドコモがドコモ口座を保護することは可能</li>
</ul>
</li>
<li>結果として銀行口座は保護されない</li>
</ol>
<p>そして、責任分界点はこのあたりで、</p>
<ul>
<li>銀行預金に対する金銭被害の責任は銀行に帰し</li>
<li>その預金が反社に渡る責任はドコモに帰する</li>
</ul>
<p>eKYC文脈ではこのあたりが論点で、</p>
<ul>
<li>上記2をサービスとして成り立たせるためのAAL, FAL要件に関する合意</li>
<li>上記2がサービスとして成り立ったとしても上記3が実質なされていないことには代わりがないので、それを良しとするのかどうか</li>
</ul>
<p>金融文脈ではこの辺りが論点になるのかなと。</p>
<ul>
<li>銀行側のAALが1を満たさない場合でも規約上の免責事項に該当することを良しとするか</li>
<li>銀行側のAALが1を満たさない場合でも「送金先による口座名義確認とセットでは結果として銀行口座が保護される」ことを良しとするか</li>
</ul>
</div>
<div class="meta">
</div>
</article>
<article class="post">
<h2 class="title">
<a href="/blog/2020/06/02/zero-day-in-sign-in-with-apple-deep-dive/">
Zero-day in Sign in With Apple Deep-dive</a>
</h2>
<div class="entry-content">
<div class="meta">
<div class="author">
Author: <a href="https://matake.jp">Nov Matake</a>
</div>
<div class="date">Date:
<time datetime="2020-06-02T12:22:00+09:00" pubdate data-updated="true">Jun 2<span>nd</span>, 2020</time></div>
</div>
<p>先週末に <a href="https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-apple/">Zero-day in Sign in with Apple</a> とかいう記事が出ていました。</p>
<p>この記事ではいまいち詳細がわからないんで、ちょっと実際 Apple IdP の挙動調べてみたら、当該 Endpoint 発見しました。</p>
<h3>実際にどこが脆弱だったのか</h3>
<ol>
<li>非 Safari ブラウザで、適当な RP にアクセス
<ul>
<li>e.g.,) <a href="http://signin-with-apple.herokuapp.com/">http://signin-with-apple.herokuapp.com/</a> (Nov SIWA RP)</li>
<li>Safari だと OS の Native UI が出てきてブラウザ遷移しないので注意</li>
<li>既に連携済の RP の場合は一度連携解除しておくこと</li>
</ul>
</li>
<li>Sign in with Apple のボタンをクリックして Apple AuthZ Endpoint に遷移
<ul>
<li>AuthZ EP: <a href="https://appleid.apple.com/auth/authorize">https://appleid.apple.com/auth/authorize</a></li>
</ul>
</li>
<li>ログイン後、初回連携時にのみ出てくる同意画面 (メアド選択するところ) に到達
<ul>
<li><img src="/images/posts/apple/siwa-consent.png" width="500" alt="Sign in with Apple Consent Screen" /></li>
</ul>
</li>
<li>ここで「続ける」を押すと内部的に Ajax Call が実行される
<ul>
<li>Ajax API EP: <a href="https://appleid.apple.com/appleauth/auth/oauth/authorize">https://appleid.apple.com/appleauth/auth/oauth/authorize</a></li>
<li>選択されたメアドやその他の AuthZ Req Params が一通り JSON で POST される</li>
<li>レスポンスとしては <code>id_token</code> とか <code>code</code> なんかが含まれた JSON が返ってくる</li>
<li><img src="/images/posts/apple/siwa-consent-ajax-submit.png" width="500" alt="Sign in with Apple Consent Ajax Submit" /></li>
</ul>
</li>
</ol>
<p>で、問題は Step.4 で Submit されるメールアドレスが、実際当該 Apple ID に紐づいてないものでも OK だったということですね。</p>
<a href="/blog/2020/06/02/zero-day-in-sign-in-with-apple-deep-dive/" class="more-link">Read on →</a>
</div>
<div class="meta">
</div>
</article>
<article class="post">
<h2 class="title">
<a href="/blog/2020/05/19/nonce-pkce-sidestep-attack/">
Nonce/PKCE Sidestep Attack</a>
</h2>
<div class="entry-content">
<div class="meta">
<div class="author">
Author: <a href="https://matake.jp">Nov Matake</a>
</div>
<div class="date">Date:
<time datetime="2020-05-19T13:06:00+09:00" pubdate data-updated="true">May 19<span>th</span>, 2020</time></div>
</div>
<p>OAuth 2.1 で PKCE 必須にするしない議論が盛り上がっておりますが、今日そのスレで新しい攻撃パターンが議題に上がりました。<br/>
<a href="https://mailarchive.ietf.org/arch/msg/oauth/HZt851AobQlJMBVd6_p8iWSyRS8/">https://mailarchive.ietf.org/arch/msg/oauth/HZt851AobQlJMBVd6_p8iWSyRS8/</a></p>
<p>今のところ “Nonce/PKCE Sidestep Attack (仮” と名付けられたこの攻撃は、以下のようなシナリオで成立します。</p>
<h3>Nonce/PKCE Sidestep Attack (仮</h3>
<h4>[前提条件]</h4>
<p>ある Client に、アプリケーションコンテキストによって PKCE を使うコンテキストと Nonce を使うコンテキストが共存している。</p>
<h4>[攻撃シナリオ]</h4>
<p>以下、<a href="https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkce-sidestep-attack">原文</a> を要約。</p>
<ol>
<li>攻撃者は何らかの手段により Nonce に紐づいた (= PKCE code_challenge とは紐づいていない) 被害者の Code を詐取する。</li>
<li>攻撃者は PKCE を使うコンテキストにおいて自らのブラウザで Client に Authorization Request を実行させ、code_challenge だけを抜き去ったものを Authorization Server に送る。</li>
<li>攻撃者は受け取った Authorization Response 中の Code を Step.1 で取得した Code と差し替え Client に提示する。</li>
<li>Client は受け取った Code を Step.2 で生成した code_challenge に紐づいた code_verifier を付与して Token Request を実行する。</li>
<li>Authorization Server は code_challenge と紐づいていない Code を受け取ったので code_verifier は無視して Token Response を返す。</li>
<li>Client は Nonce を使うコンテキストでもないので Nonce のチェックも行わず、code_verifier が無視されたことも検知できないので成功裏に Token Response を受け取ってしまう。</li>
</ol>
<p>以上により Code 置換攻撃が成立する。</p>
<a href="/blog/2020/05/19/nonce-pkce-sidestep-attack/" class="more-link">Read on →</a>
</div>
<div class="meta">
</div>
</article>
<article class="post">
<h2 class="title">
<a href="/blog/2020/04/28/account-takeover-vulnerability-in-microsoft-teams/">
Account Takeover Vulnerability in Microsoft Teams</a>
</h2>
<div class="entry-content">
<div class="meta">
<div class="author">
Author: <a href="https://matake.jp">Nov Matake</a>
</div>
<div class="date">Date:
<time datetime="2020-04-28T15:44:00+09:00" pubdate data-updated="true">Apr 28<span>th</span>, 2020</time></div>
</div>
<p>約一年ぶりの記事ですね。<br/>
みなさん、三密避けて OAuth の勉強に勤しんでおられますでしょうか？<br/>
さて、今朝こんな記事が上がってました。</p>
<p><a href="https://www.itmedia.co.jp/enterprise/articles/2004/28/news056.html">「Microsoft Teams」にアカウント乗っ取りの脆弱性、画像表示だけで不正侵入 – ITmedia エンタープライズ</a></p>
<blockquote><p>今回の脆弱性は Teams のデスクトップ版と Web ブラウザ版の両方に影響する。攻撃者は狙った相手に GIF などの画像を送り付けて表示させ、画像が Web ブラウザに読み込まれる過程で認証トークンを盗み出す。被害者の画面には画像が表示されるだけなので、自分が攻撃されたことに気付かない。</p>
<p>攻撃者がこのユーザーになりすまして組織内の他の従業員に不正なGIFを送信すれば、ワームのような形で侵入を広げ、組織全体の Teams アカウントを乗っ取る可能性もある。そうなれば、社外秘情報や会議、カレンダー、パスワードといった重要情報が流出しかねない。</p></blockquote>
<p>GIF 画像貼り付けるだけで Teams アカウント乗っ取れるとか、こんなの読んだら恐ろしくて Teams なんて使えないですね。</p>
<p>この脆弱性が報告されたのが2020年3月20日ということなんですが、Teams の中の人はどんな気持ちで以下の記事を読んでいたのでしょうか。</p>
<p><a href="https://japan.zdnet.com/article/35152041/">マイクロソフト、「Teams」のセキュリティをアピール—「Zoom」に批判集まる中 – ZDNet Japan</a></p>
<p>で、ここから本題、今回の Teams の脆弱性の詳細についてです。英語ですが、こちらの記事に詳細が載ってます。</p>
<p><a href="https://www.cyberark.com/threat-research-blog/beware-of-the-gif-account-takeover-vulnerability-in-microsoft-teams/">Beware of the GIF: Account Takeover Vulnerability in Microsoft Teams | CyberArk</a></p>
<a href="/blog/2020/04/28/account-takeover-vulnerability-in-microsoft-teams/" class="more-link">Read on →</a>
</div>
<div class="meta">
</div>
</article>
<nav id="pagenavi">
<a href="/blog/page/2/" class="next">Next</a>
<div class="center"><a href="/blog/archives">Blog Archives</a></div>
</nav>
</div>
<footer id="footer">
<div style="display:inline">
<p>
Copyright © 2020
<a href="https://matake.jp">Nov Matake</a> - 技術的な相談等、お仕事依頼は <a href="https://yauth.jp">YAuth.jp</a> まで.
</p>
<p>
Powered by <a href="http://octopress.org">Octopress</a>.
Theme <a href="https://github.com/panks/fabric">fabric</a> by <a href="http://panks.me">Pankaj Kumar</a>
</p>
</div>
</footer>
<script src="/javascripts/fabric.js"></script>
<script src="/javascripts/jquery.fancybox.pack.js"></script>
<script type="text/javascript">
(function($){
$('.fancybox').fancybox();
})(jQuery);
</script> <!-- Delete or comment this line to disable Fancybox -->
<script type="text/javascript">
var disqus_shortname = 'oauthjp';
var disqus_script = 'count.js';
(function () {
var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
dsq.src = 'https://' + disqus_shortname + '.disqus.com/' + disqus_script;
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
}());
</script>
<!-- end toload -->
</div>
</div>
<script src="/javascripts/jquery.ui.totop.js" type="text/javascript"></script>
<script type="text/javascript">
/*<![CDATA[*/
;(function($){$().UItoTop({easingType:'easeOutCirc'});})(jQuery);
/*]]>*/
</script><!-- remove it to remove the scroll to top button -->
</body>
</html>