Bounty 初體驗 - 資安

※ 引述《CMJ0121 (不要偷 Q)》之銘言：
: ※ 引述《CMJ0121 (不要偷 Q)》之銘言：
> bounty 系列文最終章
bounty 系列文終於到最終章了

這三篇剛好滿足三種 bounty 可能遇到的狀況 1) 給錢 2) 錢給的不甘願 3) 沒有錢

接下來 bounty 相關文章就會交給其他有心人發文了 :)


一樣附上時間軸：

2021-04-10 參加聚會時 跟社團友人一同發現問題
問題為官網某服務的 Blind SQL Injection
2021-04-11 放棄更深入的檢測
寄信回報到 [email protected][1] ->
2021-04-14 再次寄信到 [email protected] ->
2021-04-15 使用官網上提問 form 確認對方是否有收到信 ->
用詞為：發現一個潛在安全性問題、尚未收到回覆
2021-04-15 <- 對方使用公司個人信箱回覆
表示沒收到報告
2021-04-15 透過公司信箱確認為公司員工 (透過 LinkedIn) ->
回覆報告到對方個人信箱
2021-04-16 寄信詢問對方是否收到回覆 ->
並詢問是否有 bounty / acknowledgement
2021-04-16 <- 對方表示收到報告
目前沒有 bounty
研究如何提供 acknowledgement
2021-06-04 -> 放在官方某致謝 Link 中 <- 現在

有跟對方承諾會在 6/16 之後公布細節 不過檢查問題已經修復

怕忘記內容 所以把公司資訊盡可能隱藏 到時候看是否記得 再補上相關資訊



這次主要是在某公司的某項服務中發現一個 Blind SQL Injetion[2]

一開始只是在介紹某公司的營運項目 使用到某服務時 友人表示可以試一下 '

結果服務就出現 500 Internal Server Error 結果在場的人都興奮了 :)

之後就是各種嘗試 以下是沒按照順序的各種嘗試

使用 sqlmap[3] 嘗試 -> 失敗
使用手動 SQL injection
' OR SELECT 1, 2, 3, 4 '-- 系列 算欄位 -> 失敗
' UNION (SELECT ...) 系列 -> 失敗
' or (SELECT 1 ) = 1' -> 成功

透過手工 沒有找到註解掉後續 SQL command 的方式

僅限 blind SQL injection 判斷 ( SELECT ... ) = ... ' 結果是否成立

可以用這種方式 一個字元一個字元、二分搜尋 找到想要的內容

像是 database 版本號、table name、user name、user password 等

最難測試的部分 對方服務只要打 API 太多次後會維持在 500 Internal Server Error 一段時間

這樣誤判會太多 猜測這也是 sqlmap 失敗的原因



## 檢討 I ##
其實在聽到的案例中 找到安全漏洞之後大多數都是沒有錢的

新聞上看到拿到大筆金額的 都是幸存者偏差後的結果

如果真的想找有金錢 bounty 的 就需要用白名單直接找


## 檢討 II ##
公司方一定要提供一種穩定的聯絡管道

像我第一次寄信的聯絡信箱 維持一段時間都沒有任何 feedback

這次的案例中 其實用個人公司信箱回覆不是很理想

尤其一開始沒有適當的自我介紹 (我不知道你是誰啊...) 也不知道是否代表公司


## 檢討 III ##
從公司方的回復速度來看 大概能夠了解是否有沒有在意安全性問題

已一個會主動回報安全性問題給公司的提報者 看重的東西不外是錢 or 名

公司只要滿足其中一點 提報者通常會安靜 (不宣傳) 且乖巧 (不亂打)

但是提報者其實最怕的就是公司默默把問題修好 然後發無聲卡

一直沒有任何 feedback 的情況下 提報者其實容易想太多 :)


[1] 對方官網上唯一的聯絡信箱
[2] https://owasp.org/www-community/attacks/Blind_SQL_Injection
[3] https://sqlmap.org/

--