※ 引述《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/
--
: ※ 引述《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/
--
All Comments