shikata ga nai

Private? There is no such things.

Account takeover by OTP bypassを訳してみた

Hello there, ('ω')ノ

 

OTPバイパスによるアカウントの乗っ取りを。

 

脆弱性:

 OTPバイパス

 

記事:

 https://medium.com/@bhavarth33/how-i-was-able-to-takeover-any-account-by-otp-bypass-bba698a725f

 

認証をバイパスする方法がたくさんあるのは興味深いことで。

今回は、静的コード分析によって認証をバイパスする実験したので。

静的コード分析によって認証をバイパスすることができた方法について説明を。

ターゲットは、人気があり魅力的な観光地のオンライン予約サイトで。

redacted.comと呼ぶことに。

 

お気に入りの脆弱性は認証バイパスで。

このカテゴリでは、OTPバイパスが最もお気に入りなので。

OTPバイパスのグレーな領域を探すための個人的なチェックリストがあって。

redacted.comでバイパスを見つけるプロセス中に試したチェックリストから。

2つのポイントをカバーして。

 

最初の応答の傍受について説明することに。

Burp Suiteで、要求と応答をインターセプトするように構成して。

この方法では、ハッカーは通常、サーバの応答で誤ったOTPをチェックしてから。

応答をシミュレートして正しいOTPを検出しようとするので。

無効なOTPを試して、その要求をリピーターに送信して応答を確認すると。

無効なOTPに対してサーバから下記の応答を受け取っていて。

 {"status":true,"data":{"valid":false}}

f:id:ThisIsOne:20211025103729p:plain

 

次の試みでは、下記のように応答を変更してリクエストを転送すると。

 {"status":true,"data":{"valid":true}}


応答を傍受して転送することで、認証をバイパスできず。

その後、OTPのリクエストを再度傍受して。

今回は正しいOTPを使用して、正しいOTPの場合にサーバの応答を確認することに。

正しいOTPを入力し、リクエストをキャプチャして。

リピーターにリクエストを送信し、正しいOTPの応答を確認すると。

応答は次のようになって。

 

{
   "status":true,
   "data":{
      "valid":true,
      "token":"*******************",
      "name":"username"
   }
}

 

応答を見て、最初に頭に浮かんだのは、これがトークンベースの要求であって。

各要求で検証されるということで。

そのため、OTPをバイパスするために、アプリケーションのトークンベースの弱点を。

把握する必要があるため、テストの範囲が広がるものの。

OTPの脆弱性を回避するための自分のチェックリストには。

静的分析というもう1つのポイントがあって。

基本的にHTML、JSファイルのマイニングを開始して。

認証のコーディングの弱点があるかどうかを確認すると。

OTPを検証するための潜在的な実装である下記の1つの関数を見つけて。

 

f:id:ThisIsOne:20211025104132p:plain

 

このコードを分析すると、この関数はリクエスト内のトークンと名前の長さのみを。

検証していて完全なトークンを検証しておらず。

 if(token.length>0 && name.length>0)

 

2回目の試行では、間違ったOTPを入力し、リクエストをキャプチャして。

リクエストを転送し、レスポンスをキャプチャして。

レスポンスを下記のように変更してみると。

 {"status":true,"data":{"valid":false}}

 ⇩

 {"status":true,"data":{"valid":true,"token":"test","name":"username"}}


ログインに成功できて。


結論:

常にさまざまな攻撃ベクトルを探すようにして。

1つの方法で失敗した場合でも、別の方法を探して。

個人的なチェックリストを作成してバグを見つけ、日々改善するように。

 

Best regards, (^^ゞ

ひとりひとりの自覚をもった行動で、医療従事者と保健所職員を助けよう。

f:id:ThisIsOne:20200404115457p:plain