有缺陷的重設密碼機制如何演變成帳號奪取漏洞？以 Matters 為例

重設密碼是幾乎所有網站都有的機制，最常見的是透過 email 寄送一個重設密碼的連結，點進去連結以後就可以幫這個帳號設定新的密碼。這個機制雖然常見，卻有一些關於安全性的小細節要注意。

這次要來寫的，是我在今年六月底的時候回報的由重設密碼功能引起的帳號奪取（account takeover）漏洞。

Matters News 是一個去中心化而且應用加密貨幣相關技術的寫作社群平台，我以前曾經寫過一篇《防止 XSS 可能比想像中困難》分享我怎麼找到他們的 XSS 漏洞。

在談這次的漏洞之前，我們先來看看一般重設密碼的功能是如何設計的。

話說，如果你好奇為什麼密碼只能重設，而不是「找回密碼」，可以先參考這一篇：為什麼忘記密碼時只能重設，不把舊密碼告訴我？

# 典型的重設密碼功能

基本上忘記密碼的流程都大同小異，不外乎就是：

  1. 使用者填入當初註冊帳號時的 email
  2. 系統寄送重設密碼的連結到第一步的 email
  3. 使用者點擊信中的連結，前往重設密碼頁面
  4. 使用者輸入新的密碼，送出表單
  5. 密碼重設成功，使用者可以利用新的密碼登入

這個流程如果要是安全的，就必須確保：

  1. 系統寄送信件的目的地，真的是使用者本人的 email
  2. 重設密碼的連結無法被猜出來

先來談談第一點，有些人會想說：「這不是很基本嗎？我填入 user@example.com，當然是把信件寄送給 user@example.com 啊！」

不不不，這可不一定，有些系統在接收 email 這個參數時，居然可以是一個陣列，所以你可以填入：["victim@example.com", "attacker@example.com"]，然後 attacker 就會收到 victim 的重設密碼信件！

聽起來很不可思議，但確實發生過：

  1. Ability to reset password for account
  2. Full account takeover of any user through reset password

再來談談第二點，如果重設密碼的連結可以被猜出來，就代表攻擊者可以代替 user 重設密碼。

或更精確地說，重設密碼的 token 不能被猜出來。

舉例來說，如果重設密碼的連結長得像這樣：https://example.com/reset-password?token=user@example.com，那我就可以幫任何人重設密碼了，顯然很不安全。

所以一般來說，token 都會產生一組 unique id，例如說 UUID v4，長得像這樣：2c59d26a-f99a-425e-bb69-91e7c6ffe54d，有 128 個 bit，也就是 2^128 種組合，要猜中的可能性微乎其微。

若是產生的 token 強度不夠的話，就會提高暴力破解成功的機率。

不過要特別注意的是儘管如此，有些系統的漏洞在其他地方，例如說寄送 email 時，重設密碼的網址或是 host 是可以控制的！像是只要在 request header 裡面加上 X-Forwarded-Host: abc.com，重設密碼的連結就會變成：https://abc.com/reset-password?token=...，使用者收到信以後如果不小心點了連結，這個 token 就會發到攻擊者的伺服器去，他一樣可以利用這個 token 來重設密碼，進行帳號奪取。

這也是有發生過實際案例的：

  1. Password Reset link hijacking via Host Header Poisoning
  2. Email link poisoning / Host header attack

除了這些以外，其實還有許多小細節要注意，例如說：

  1. 重設密碼的 token 應該只能使用一次
  2. 重設密碼的 token 應該要有過期時間
  3. 如果使用者產生了新的重設密碼 token，舊的應該要廢棄

之所以會有這些限制，也是為了降低暴力破解的可行性。

假設時間無限的話，理論上暴力破解絕對可以猜出 token，因此防止暴力破解的重點有兩個，一個是盡量增加破解所需的時間，讓這個時間大到超過一千年或更久，第二個重點是限制時間，而實際的方法有幾種，例如說：

  1. 把基數加大，例如說六碼數字的可能性只有一百萬種，但若是換成六碼英文加數字就有 20 億種，要猜測的數量多了 2000 倍，就需要花更多時間
  2. 把可猜測的時間降低，例如說 300 秒後 token 就會過期，假設可能性有 1 億種，那每秒必須要猜 30 萬種才能保證猜中

接著，我們就來看一下 Matters 的重設密碼機制出了什麼事情。

# Matters 的重設密碼機制

下圖是 Matters 重設密碼的畫面，一樣是填入 email，然後寄一個連結到信箱：

重設密碼的 request 長這樣：

{
   "operationName":"SendVerificationCode",
   "variables":{
      "input":{
         "email":"user@example.com",
         "type":"password_reset",
         "redirectUrl":"https://matters.news/forget?email=user%40example.com"
      }
   }
}

這是我收到的連結：https://matters.news/forget?email=user%40example.com&code=UYBQ912rhd_9s3TfywZnk1kQl6PCaDjPlXuNX3Df&type=password_reset

從這邊其實我們就可以發現第一個問題，就是看起來收到的連結的前半段是由 redirectUrl 所控制的。如果我們攔截 request 以後修改 redirectUrl 參數，修改成 https://cymetrics.io，會發現信箱內收到的連結確實變成由 https://cymetrics.io 開頭！

如此一來，就有了前面所說的漏洞，如果使用者點了信中的連結，那我們的 server 就會收到 token，就可以幫使用者重設密碼。

接著我們看一下有沒有暴力破解的問題，token 本身看起來複雜度滿高的，長度是 40 個字，由大小寫英文字母、數字以及底線所組成。

雖然看起來應該不會有問題，但 Matters 是開源的，所以我們可以直接去看一下 SendVerificationCode 是如何實作的，程式碼在這邊：https://github.com/thematters/matters-server/blob/v3.19.0/src/mutations/user/sendVerificationCode.ts

我們關注的是產生 code 的地方，主要是這一段：

// insert record
const { code } = await userService.createVerificationCode({
  userId: viewer.id,
  email,
  type,
  strong: !!redirectUrl, // strong random code for link
})

而這個 userService.createVerificationCode 的程式碼則是在這裡：https://github.com/thematters/matters-server/blob/v3.19.0/src/connectors/userService.ts#L1500

createVerificationCode = ({
  userId,
  email,
  type,
  strong,
  expiredAt,
}: {
  userId?: string | null
  email: string
  type: string
  strong?: boolean
  expiredAt?: Date
}) => {
  const code = strong ? nanoid(40) : _.random(100000, 999999)

  return this.baseCreate(
    {
      uuid: v4(),
      userId,
      email,
      type,
      code,
      expiredAt:
        expiredAt || new Date(Date.now() + VERIFICATION_CODE_EXIPRED_AFTER),
    },
    'verification_code'
  )
}

從這邊我們看到一個重點，就是在系統內 code 的產生分兩種類型，strong 的是 nanoid(40)，不 strong 的則是 100000~999999 的六碼數字，而這個 strong 的參數是由有沒有傳入 redirectUrl 而決定的。

也就是說，如果我們在建立 reset password 的驗證碼時把 redirectUrl 參數拿掉，code 就會從原本的 40 個字，瞬間降低成六位數的數字！

而驗證碼的過期時間 VERIFICATION_CODE_EXIPRED_AFTER 是五分鐘，也就是 300 秒，900000/300 = 3000，只要我們一秒能發送 3000 個 request 到 server，就能暴力破解 reset password 的 token，進而奪取使用者帳號。

但其實這樣的說法不太精確，因為我們可以發 3000 個，不代表 server 就可以處理 3000 個，所以還要看 server 能接受的 request 數量，而且在這之前，還有另一個限制要繞過。

# Rate limiting

增加暴力破解難度的方法之一就是 rate limiting，許多網站或是 WAF 都有這個功能，能夠阻止短時間內大量的 request。

而 Matters 的 rate limit 是用 nginx 來處理，程式碼在這裡：https://github.com/thematters/matters-server/blob/v3.19.0/.ebextensions/rate-limit-connections.config

limit_req_zone $http_x_forwarded_for zone=application:16m rate=5r/s;

limit_req zone=application burst=20 nodelay;

limit_req_status 429;

limit_conn_status 429;


# pass real IP from client to NGINX


real_ip_header X-Forwarded-For;

set_real_ip_from 0.0.0.0/0;


server {

# set error page for HTTP code 429

error_page 429 @ratelimit;

location @ratelimit {

return 429 '["Connection Limit Exceeded"]\n';

}


listen 80;

# 底下省略



}

nginx 的 rate limit 基本上都是以 IP 為主，如果真的想繞過的話可以嘗試看看 IP rotate，一個簡單的方式是去 AWS 上開很多 API gateway 當 proxy，然後你就有了一堆不同的 IP 可以輪流使用。

但這邊還用不上這個技巧，因為在設定中可以看到它使用了 $http_x_forwarded_for 這個參數，如果沒有管理好的話，可以自己傳入 X-Forwarded-For 來偽造任意 IP，藉此繞過 rate limit 的限制。

而 Matters 在這邊顯然沒有設置好，因此 rate limit 算是虛設。

做到這邊，只要我們能夠一秒發送 3000 個 request 就能做出 POC，證明攻擊確實可行，但還有沒有其他的方法，能讓這個數字再小一點呢？

# 同時存在的驗證碼

在開頭的時候有提過重設密碼有一些小細節要注意，像是：

  1. 重設密碼的 token 應該只能使用一次
  2. 重設密碼的 token 應該要有過期時間
  3. 如果使用者產生了新的重設密碼 token，舊的應該要廢棄

而 Matters 前兩點都做了，就是唯獨第三點沒有做好。從程式碼中我們可以看出當新的驗證碼建立時，舊的並不會刪除或是標記為廢棄。

這會有什麼影響呢？我們來算個簡單的數學吧！

驗證碼的組合總共有 900,000 種，我們有 300 秒的時間可以攻擊，如果可以在這段時間內發送 900,000 個 request 而且 server 也有處理，就一定可以猜到重設密碼的驗證碼。

若是我們改成先不要猜，而是先發送 1000 次的重設密碼請求，因為舊的驗證碼依然有效，所以這時我們猜一次，猜中任何一組的機率就是 1000/900000 = 1/900，變成原本的 1000 倍。

猜 1000 次的話，猜中的機率就是「1 - 每次都猜不中的機率」，大約是 1 - (899/900)^1000 = 67%，如果猜到 5000 次的話，猜中的機率就是 1 - (899/900)^5000 = 99.6%。

也就是說，我們只要發送 1000 個重設密碼的請求外加 5000 個確認驗證碼的請求，總共 6000 個請求，就有 99.6% 的機率可以正確猜到至少一組驗證碼！

可以寫個簡單的小程式來驗證我們的機率計算：

const _ = require('lodash')

const rounds = 100000 // 跑十萬輪取平均 
const guessRounds = 5000 // 猜 5000 次
const tokenCount = 1000 // 1000 個合法驗證碼
let winCount = 0 

for(let r=0; r<rounds; r++) {
  let ans = {}
  for(let i=0; i<tokenCount; i++) {
    ans[_.random(100000, 999999)] = true
  }
  let isWin = false
  for(let i=0; i<guessRounds; i++) {
    const guessNumber = _.random(100000, 999999)
    if (ans[guessNumber] === true) {
      isWin = true
      break
    }
  }
  if (isWin) winCount++
}

console.log(winCount*100 / rounds)
// 輸出：99.626，我們算出的機率差不多

原本要發 900,001 個 request 才能有 100% 的機率可以猜中，現在只要犧牲一點點正確性，變成 99.6% 的機率猜中，就可以把 request 數量降低到 6000 次，低了 150 倍！

原本我們在五分鐘內一秒要發 3000 個 request，現在一秒只要 20 個 request 就好（其實這邊也只是大略計算，因為是有順序性的，必須要等 1000 個發送驗證碼的 request 結束後才能開始猜，而這 1000 個可能又會花個幾秒，但這邊為了方便計算先忽略不計，對整體的影響不大）

就因為這個重設密碼的小缺陷，沒有把上一組驗證碼淘汰掉，導致我們可以產生多組驗證碼，大幅降低暴力破解的難度。只要能在五分鐘內發送 6000 個 request，就有 99.6% 的機率可以更改一組帳號的密碼。

由於這是重設密碼功能，所以改完密碼之後你就可以直接用他的身份登入系統，達成帳號奪取，把其他人的帳號都變成是你的。如果想要擴大影響性的話，可以奪取管理員的帳號，就有機會進入管理後台進行更多操作。

# 建議修補方式

第一個要修的地方是重設密碼的小缺陷，在使用者產生新的驗證碼時，舊的應該要被淘汰掉，保證永遠只有最新的一組可以通過驗證，這樣攻擊者猜中的機率就永遠是 1/n，而不會像上面的範例那樣，可以把機率提高 1000 倍或更多倍。

第二個則是驗證碼的產生不該由 redirectUrl 參數來決定，而是應該由驗證碼的 type 來決定，如果是 reset password，就一定要是 strong，這樣子就會用 nanoid(40) 來產生，猜中的機率就變得微乎其微，大幅降低暴力破解的可行性。

第三個是 redirectUrl 不應該從前端傳入，而是直接把網址寫在後端。如果真的要從前端傳入，那後端要做好完善的檢查，確保 redirectUrl 傳入的是合法的路徑，而不是讓攻擊者可以傳入任意網址（不過如果攻擊者能結合 open redirect，又是另外一回事了）

最後一個則是 nginx 的 rate limit 限制不應該用 X-Forwarded-For 來決定，就算真的要用這個，也要確保它的值無法由攻擊者自行傳入。

# 總結

重設密碼機制看似簡單，但其實一不小心還是有可能做出有漏洞的機制，導致攻擊者有機可趁，在 HackTricks 上有個頁面專門在講 reset password 可能會有的問題：Reset/Forgotten Password Bypass，除了這篇提到的以外還有更多的問題，整理得很詳細，很值得參考看看。

如果你以為只有一般的網站會有這種問題，那你就錯了。一名資安研究員 Laxman Muthiyah 發現可以用 concurrent 的方式繞過 Instagram 的 rate limiting，成功發送 200 個 request，並且用 1000 台機器產生出 20 萬個 request，就有 20% 的機率攻擊成功。

只要有 5000 台機器，就能拿下任何帳號。5000 台聽起來很多，成本應該很高對吧？但如果善用 cloud service 的話，他估算可能只需要 150 美金左右即可達成一次攻擊（因為算小時收費，只要開一兩個小時即可）

而他也在去年七月用同樣的手法繞過微軟的 rate limiting，並且拿到 5 萬美金的獎金。

像這種漏洞如果能成功被利用，就能夠直接奪取他人的帳號，影響很大，需要多加注意相關的安全性。看到這裡，大家不妨也檢查一下自家的重設密碼機制是否安全。

最後，這次找到漏洞以後一樣有回報給 Matters，底下是完整時間軸：

2021-06-24 回報漏洞給 Matters
2021-06-25 收到 Matters 回覆，確認漏洞存在
2021-08-20 Matters 修復部分功能，產生新的驗證碼時會淘汰舊的
2021-08-26 Matters 確認漏洞評級為 High，獎金為 150 USD
2021-10-28 關心後續修復狀況，確認是否修補完畢
2021-11-30 Matters 增強 non-strong 的驗證碼基數
2021-12-02 文章初稿完成，與 Matters 確認是否可發布
2021-12-21 Matters 確認問題已修復完畢以及可發布文章

ShareShare this post

Tag

#Security

Recommendation

  1. 中小企業做不好資安的5大關鍵因素
  2. 來談談後端快取策略
  3. SQL injection 實戰：在限制底下提升速度
  4. 資安科普番外篇（二）-如何有效率選擇風險進行修復 feat.風險和法規息息相關？！
  5. 來談談 AOP (Aspect-Oriented Programming) 的精神與各種主流實現模式的差異
huli
Author
huli
Act as a bridge between Front-end and Security world

Discussion(login required)