HaCk CaT

Big GG Next!

Bug report writing tips for you guys !

Bug Hunting Tipတွေလဲတင်တာနည်းနည်းများနေပြီဆိုတော့ ဒီနေ့မှာ -
"Bug Report တစ်ခုကို အလွယ်တကူနဲ့ ထိထိရောက်ရောက်ဘယ်လိုရေးသင့်လဲ။ Reportတစ်ခုမှာ အရေးကြီးတဲ့အချက်တွေက ဘာတွေလဲ၊
ဘာကြောင့်လဲ?"
-ဆိုတဲ့ အကြောင်းအရာနဲ့ပတ်သက်ပြီး Beginnerနားလည်မယ့်ပုံစံမျိုးနဲ့ ရှင်းပြပေးပါမယ်
👨‍💻👨‍💻
ပထမဆုံးအနေနဲ့ Bug Reportတင်တဲ့အခါမှာ အဓိကပါ၀င်တဲ့အချက်တွေ ဘယ်နခုရှိမလဲဆိုတာအရင်ကြည့်ရအောင် -
1. Title
(ခေါင်းစဥ်)
2. Vulnerable URL Or Endpoint
(ယိုပေါက်ရှိနေတဲ့ url or endpoint)
3. Steps To Reproduce
(အဆင့်တစ်ခုစီ ရှင်းပြခြင်း)
4. Proof Of Concept[PoC]
(သက်သေပြခြင်း)
5. Affected payloads
(ထိုးဖောက်လို့ရစေတဲ့ code)
6. Impact Rating
(ယိုပေါက်ရဲ့ထိခိုက်နိုင်ခြေ)
7. Impact Detail
(ဘယ်လိုထိခိုက်မှုရှိနိုင်လဲ)
8. Mediation
(ကာကွယ်ရန် အကြံပေးခြင်း)
9. Kindly regards
(လေးစားစွာဖြင့် reportတင်ခြင်း)
10. Attach Poc Video or Screenshots
(သက်သေပြဖို့အထောက်အထားများထည့်ခြင်း)
-
အထက်မှာပြောပြခဲ့တဲ့ အချက် ၁၀ချက်ကတော့ Bug reportတစ်ခုမှာ မပါမဖြစ်ပါ၀င်တဲ့ အရေးကြီးတဲ့အချက်တွေဖြစ်ပါတယ်👨‍💻
ဒီအချက် ၁၀ချက်ကို အကျယ်တ၀င့် ရှင်းပြပေးပြီး reportရေးတဲ့အခါ ဘယ်လိုရေးသင့်ကြောင်းတွေကိူပါ
​သိသလောက်ပြောပြပေးပါမယ်
ဆိုတော့ ပထမ အချက်ကို Bug reportမှာ စပြီးမရေးခင်မှာ အရေးကြီးတဲ့ အဆင့်တစ်ဆင့် ရှိပါတယ် -
အဲ့တာကတော့ ကိုယ်ရထားတဲ့ Bugတစ်ခုက တကယ့်
bugဆိုတာ ဟုတ်ရဲ့လား? မဟုတ်ဘူးလား? ဆိုတဲ့ Confirmation အဆင့်တစ်ခုပဲဖြစ်ပါတယ်။
ဒီအဆင့်က အခုမှစလုပ်တဲ့ Hunterတွေမှားလေ့ရှိတဲ့အဆင့်တစ်ခုပါ။
( ဥပမာ- javascript source codeထဲကနေ api_key ဆိုတဲ့ နောက်က valueတစ်ခုကိုတွေ့တိုင်း api key leakageဆိုပြီး ထင်နေတာမျိုးတွေပေါ့)
ဒီ confirmationအဆင့်ကို သိရှိဖို့ ကိုယ်ရထားတဲ့ bugကို ၃ကြိမ် ၃ခါလောက် ကိုယ်တိုင် manual testပြန်လုပ်ကြည့်ပါ။
ဒီလိုလုပ်ကြည့်တဲ့အခါမှာ စဥ်းစားရမယ့်အချက်တွေက-
1. ကိုယ်ရထားတဲ့ bugက owasp top 10မှာ ဘယ်အမျိုးအစားထဲမှာပါလဲ။
2. တကယ်ပဲ user or server sideအတွက် ထိခိုက်မှုရောရှိရဲ့လား၊ ကိုယ်တစ်ယောက်ထဲပဲ(self) သက်ရောက်မှုရှိနေတဲ့ bugတခုလား။
3. ဒီBugအမျိုးအစားကprogram ruleရဲ့ out of scope bugအမျိုးအစားထဲမှာပါနေလား။
ဒီအချက်၃ချက်ကို သေသေချာချာစစ်ပြီးလို့ ထိခိုက်နိုင်bugဆိုတာမသေချာရင်တော့ မတင်သင့်ပါဘူး N/A နဲ့တင် ပွဲသိမ်းခံရနိုင်ပြီး၊ ဒီထက်ပိုဆိုးရင် pointပါ အလျှော့ခံရနိုင်ပါတယ်။
တကယ် bugအစစ်ဖြစ်တယ်ဆိုတာ သေချာပြီဆိုရင်တော့ စလိုက်ကြရအောင် 👨‍💻-

No.1 : Title (ခေါင်းစဥ်) 🧠🧠
ဒီ Titleဆိုတဲ့အဆင့်ကတော့ Bugတစ်ခုတွေတဲ့အခါမှာ
အဲ့ဒီ Bugရဲ့ အမျိုးအစား(type)၊ ထိခိုက်နိုင်ခြေ(impact detail)၊ နည်းလမ်း(technique)၊ ယိုပေါက်တည်ရှိတဲ့နေရာ(vulnerable point) စတဲ့ အချက်အလက်တွေကို တစ်ကြောင်းထဲနဲ့ unique ဖြစ်အောင် ရေးဖို့ စဥ်းစားရပါမယ်။ ဥပမာ - ကိုယ်က log in form တစ်ခုမှာ reflected xssတစ်ခုရထားပြီး၊ အဲ့ဒီxssကနေတဆင့်
keyloggerတစ်ခုပြုလုပ်ပြီး userတွေရဲ့ username/passwordတွေကို ခိုးယူနိုင်တယ်ဆိုပါတော့ Titleမှာ -
Reflected XSS in login form can perform account takeover(ATO)
(translate : loging formမှာရှိတဲ့ rxssက atoလုပ်လို့ရနေတယ်)
ဒီလိုမျိုးပေါ့ - ကိုယ့်ရဲ့ယိုပေါက်တစ်ခုလုံးကို ခြုံပြီးတော့
တစ်ကြောင်းထဲနဲ့ uniqueဖြစ်ဖြစ်ရေးဖို့ပါ။
ဒီနေရာမှာ ရှင်းလဲရှင်းရမယ်၊ နားလည်လဲလွယ်ရမယ်၊ မှန်လဲမှန်ကန်ရမယ်။
ဒီအချက် ၃ခုက အဓိကပါ။

No.2 : Vulnerable Url or Endpoint ❗️❗️
ဒီအဆင့်ကတော့ ယိုပေါက်တည်ရှိနေတဲ့(ဖြစ်နေတဲ့)
url ဒါမှမဟုတ် apiဆိုရင် endpoint ကို copyကူးပြီး
ထည့်။ ကောင်းတာကတော့ url parameterမှာ ယိုပေါက်ရှိနေတာဆိုရင် vulnerableဖြစ်နေတဲ့ parameterရဲ့ value နေရာမှာ [] square bracketလေးထည့်ပြီး [vulnerable] or [vulnerable_area] ဆိုပြီးရေးရင် ပိုကောင်းတယ်။
အထက်က xss caseအတိုင်းပြောမယ်ဆိုရင် -
https://exam.com/login.html?text=[vulnerable]
အထက်ပါ ပုံစံအတိုင်းပေါ့။

No.3 : Steps To Reproduce 👨‍🏫👨‍🏫
ဒီအဆင့်ကတော့ အတော်လေး အရေးကြီးပါတယ်။ ဒီအဆင့်ကို ကြည့်ပြီး programရဲ့ developer teamတွေ bugcrowd ရဲ့validator (ယိုပေါက်စစ်ဆေးပေးသူ) တွေက စစ်ဆေးပြီး Bugဟုတ်မဟုတ်ဆိုတာကို စစ်ဆေးပေးတာကြောင့်မလို့ပါ။
ဒီအဆင့်မှာက English skillကောင်းစရာမလိုပါဘူး
စကားလုံးနည်းနည်းလေးနဲ့ ထိထိရောက်ရောက် သူတို့နားလည်အောင် ရှင်းပြပေးနိုင်ရင် ရပါပြီ။ သူတို့သေသေချာချာနားလည်သွားမှ ကိုယ့်အနေနဲ့ Bountyရဖို့သေချာမှာပါ။ မဟုတ်ရင် informational ဆိုတဲ့ statusနဲ့ reportကို closedသွားပါလိမ့်မယ်။
ဘယ်လိုရေးရမလဲဆိုတာကို အထက်ပါ XSS reportအနေနဲ့ပြောရမယ်ဆိုရင် -
Step To Reproduce
step1. Navigate to this url : https://exam.com/login.html?text=user_login
(အဆင့်၁ - ဒီ urlကို ၀င်ပါပေါ့)
step2. Then add the xss payload in the 'text' parameter's value
(အဆင့်၂ - xss payloadကို textဆိုတဲ့ parameterထဲမှာထည့်ပါ)
step3. then enter to that url, you will see the result of xss payload
(အဆင့်၃ - enterလိုက်ရင် xss payloadရဲ့resultကိုမြင်နေရပါလိမ့်မယ်ပေါ့)
အထက်ပါ အတိုင်း အလွယ်တကူနဲ့ရှင်းရှင်းလင်းလင်းရေးနိုင်ပါတယ်။

No.4 : Proof of Concept [PoC] 📠📠
ဒီအဆင့်ကတော့ အထက်က အဆင့်နဲ့အတူတူအရေးကြီးပါတယ်။ ရေးသားတဲ့ပုံစံကတော့ အထက်ကSteps to reproduceအဆင့်နဲ့ တူတယ်လို့ ထင်ရပေမယ့် တကယ်တမ်းဆို မတူပါဘူး။
Steps to reproduceဆိုတဲ့ အဆင့်က သူတို့ကို နားလည်အောင်ရှင်းပြရင်း ဘယ်လိုထည့်ပါ၊ ဘယ်လိုလုပ်ပါ၊ ဘယ်လိုလုပ်ရင် ဒီယိုပေါက်ကိုတွေ့နိုင်ပါတယ် ဆိုတာ​ကို
သူတို့ကို confirmခိုင်းတဲ့အဆင့်ပါ။
ဒါပေမယ့် PoC အဆင့်ကတော့ ကိုယ်ကိုယ်တိုင်က ဘယ်လိုမျိုး exploitလုပ်ထားပါတယ်ဆိုတာကို သက်သေပြရမယ့်နေရာပါ။ ဒီနေရာမှာလဲ english skillအရမ်းရှိစရာမလိုလဲ ဖြစ်ပါတယ်။
လွယ်လွယ်ကူကူစကားလုံးတွေနဲ့ ရှင်းရှင်းလင်းလင်းဖြစ်အောင်ရေးပါ။
အထက်ပါ XSS reportကိုပဲ ဥပမာအနေနဲ့ pocနေရာကိုရေးပြပါမယ်။
Proof Of Concept(PoC)
step1. When i logged in my account, i found a login page url containing 'text' parameter.
(ငါ့အကောင့်ကို login၀င်ခဲ့တုန်းက login pageမှာ textဆိုတဲ့ parameterကိုတွေ့ခဲ့တယ်)
step2. Then, i changed the 'text' parameter value
"user_login" to "x
"
(အဲ့ဒီနောက်မှာ ငါ text valueကို user_loginဆိုတာကနေ xss payloadကို ပြောင်းလဲလိုက်တယ်)
step3. then, i got a prompt called 'xss'
(အဲ့နောက်မှာ xssလို့ခေါ်တဲ့ promptတစ်ခုကို ငါရခဲ့တယ်)
အထက်ပါ ပုံစံ ရှင်းရှင်းလင်းလင်းလေး ရေးနိုင်ပါတယ်။ PoC နဲ့ Step To Reproduceရဲ့ရေးသားပုံကို ပြန်ယှဥ်ကြည့်ပါ။ Step to reproduceက ခိုင်းတဲ့သဘောနဲ့ ရေးထားတာဖြစ်ပြီး၊ PoCကတော့ ကိုယ်တိုင်လုပ်ခဲ့တာကို ရေးထားတာဆိုတာ သိသာစေပါတယ်။

No.5 : Affected Payload 💉💉
ဒီအဆင့်ကတော့ Reporterတော်တော်များများက သီးသန့်ခွဲပြီးရေးမနေပဲနဲ့ PoC stepတွေမှာပဲ payloadတွေကို တန်းထည့်ပြီးရေးတတ်ကြပါတယ်။ အဲ့လိုထည့်ရေးလဲရပါတယ်။ ဒါပေမယ့် ကျွန်တော်ကိုယ်တိုင်က Affected payloadဆိုပြီး Titleတစ်ခုနဲ့ခွဲရေးရတာကို ပိုသဘောကျပါတယ်။
ဥပမာ - XSSတစ်ခုကို excuteလုပ်တဲ့အခါမှာ web serverက waf( web app firewall ) ခံထားတယ်ဆိုပါတော့၊ အဲ့ဒီလို wafတွေကို bypassပြီးpayloadထည့်တဲ့
အခါမှာ ဘယ်payloadကတော့ ထည့်လို့ရပြီး၊ ဘယ်payloadကတော့ wafရဲ့ blockတာ ခံရတယ်ဆိုတာမျိုးကို သီးသန့်ပြောပြချင်လို့ပါ။
ဥပမာ- အထက်က XSS caseမှာဆို
Affected Payloads -
alert(1) (blocked by waf)
(blocked by waf)
(bypassed)

အထက်ပါအတိုင်း Wafရဲ့ blockတာခံရတဲ့ payloadတွေနဲ့ သုံးလို့ရတဲ့payloadကို ခွဲခြားပြီး ရေးလို့ရတာကြောင့်မလို့ Affected payloadကို သီးသန့်ခွဲပြီးရေးရတာကို သဘောကျတာ ဖြစ်ပါတယ်။

No.6 : Impact Rating ⭕️⭕️
ဒီအဆင့်ကတော့ ကိုယ်တွေ့တဲ့ ယိုပေါက်ရဲ့
ထိခိုက်နိုင်ချေအတိုင်းအတာကိုရေးရမှာဖြစ်ပါတယ်။
ဒီအဆင့်ကိုရေးဖို့အတွက် ကိုယ့်ရဲ့ bugက ဘယ်လောက်အဆင့်ထိ ထိခိုက်စေနိုင်လဲ၊ user sideကိုပဲထိခိုက်စေတာလား၊ server sideကိုထိခိုက်စေတာလား စတဲ့ အချက်တွေကတဆင့် စဥ်းစားရပါတယ်။
ဥပမာ - IDORကနေ user accountတွေအကုန်လုံးကို useridတွေသိတာနဲ့ DELETEလုပ်လို့ရနေတယ်ဆိုပါတော့။ useridက 1,2,3,4 ဆိုပြီး အလွယ်တကူ bruteforceတိုက်လို့ရနေတဲ့ idလား?? ဒါမှမဟုတ်ရင်
hashနဲ့ရေးထားတဲ့ userid လား?? ဆိုတဲ့အပေါ်မှာ မူတည်ပြီး - bruteforceတိုက်လို့ရနေတဲ့ useridရှိနေတယ်ဆိုရင်တော့ ဒီ IDOR bugက critical or highဖြစ်နိုင်ပြီးတော့၊ bruteforceတိုက်လို့မရပဲ uniqueဖြစ်နေတဲ့ useridဆိုရင်တော့ low or mediumနဲ့ပဲ တင်လို့ရပါလိမ်မယ်။
ဒီimpact ratingအဆင့်က အချို့ platformတွေမှာဆိုရင် သူတို့ရဲ့ standardထားထားတဲ့ cvss scoreတွေ နဲ့အခြား rating systemတွေနဲ့ ဆုံးဖြတ်ပေးထားတယ်ဆိုပေမယ့်။ ကိုယ်ရဲ့Bugရဲ့ impactကတော့ ကိုယ်ကိုယ်တိုင် သေသေချာချာ confirmလုပ်ပြီး reportမှာ ထည့်ပြီး ရေးတာက ပိုကောင်းပါတယ်။

No.7 : Impact Detail 💾💾
ဒီအဆင့်မှာတော့ ထိခိုက်နိုင်ခြေအကြောင်းကို သေသေချာချာ detailကျကျရေးရပါမယ်။ ဥပမာ - ခုနကxssမှာဆို javascript codeနေရာမှာ prompt() ဆိုတာကို မသုံးပဲ Login formနေရာမှာရတဲ့ xssဖြစ်တဲ့အတွက်ကြောင့် Key logger scriptတစ်ခုခုကိုသာ ထည့်ပြီး executeလုပ်လိုက်မယ်ဆိုရင် victim userရဲ့ username တွေ passwordတွေကို attackerက ရရှိနိုင်ကြောင်းကို ရေးသင့်ပါတယ်။ Command injection bugရခဲ့တယ်ဆိုရင်လဲ ဒီအဆင့်ကနေ Network pivottingတွေ အဆင့်ထိ ဘယ်လိုသွားလို့ရတယ်ဆိုတာတွေပါ ထည့်ရေးရင်ပိုကောင်းပါတယ်။

No.8 : Mediation 🛡️🛡️
ဒီအဆင့်ကတော့ ကိုယ်bugတင်တဲ့ programရဲ့
Dev Teamကို ဒီBugကို ဘယ်လိုမျိုး fixလုပ်သင့်တယ် ဆိုတဲ့အကြောင်းကိုရှင်းပြရမယ့် အဆင့်ပါ။
ဥပမာ - ခုနက XSS reportအရဆို
Mediation
- add a strong server side validation in 'text' parameter's value
အထက်ပါပုံစံအတိုင်း text parameterမှာ ခိုင်ခံ့တဲ့ server sideစစ်ထုတ်ခြင်း ကို တပ်ဆင်သင့်ကြောင်း ပြောပြနိုင်ပါတယ်။
ဒီအဆင့်လေးပါရင် Programတွေက ပိုပြီးသဘောကျတာကြောင့်မလို့ မေ့မနေပဲ ထည့်ရေးသင့်ပါတယ်။

No.9 : Kindly Regards 🙇‍♂️🙇‍♂️
ဒီအဆင့်ကတော့ Reportတစ်ခုရဲ့ အထက်ပါအဆင့်တွေ အကုန်ရေးပြီးသွားတဲ့အခါမှာ endingအနေနဲ့ လေးစားစွာနဲ့ reportတင်လိုက်ပါတယ်ဆိုပြီး ပြောတဲ့အနေနဲ့ reportရဲ့အဆုံးမှာ -
Kindly regards,
[Nickname]
ဆိုပြီး Nicknameနေရာမှာ ကိုယ့်ရဲ့ nicknameကိုထည့်ပြီး Reportရေးတာကို အဆုံးသတ်နိုင်ပါတယ်။

No.10 : Attach PoC video or screenshots 📸🎥
Reportရေးပြီးသွားပြီဆိုရင် ကိုယ်Exploitလုပ်တုန်းက ဘယ်လိုexploitလုပ်ထားတယ်
ဆိုတာကို Program ရဲ့ teamတွေကို သက်သေပြဖို့အတွက် recordယူထားတဲ့ PoC videoဖြစ်စေ၊ PoC screenshotလေးတွေဖြစ်စေ PoC attachments
အနေနဲ့ Uploadတင်ပြီးမှ Reportကို တင်လိုက်ပါ။
အချို့ Programတွေက PoC screenshotတွေ PoC videoတွေ တစ်ခုခုမပါဘူးဆိုရင် အရမ်းအငြင်းသန်တာကြောင့်မလို့ပါ။
-
| အထက်က အဆင့်10ဆင့်ကို အစဥ်လိုက်သေသေချာချာရေးပြီး Reportတစ်ခုကိုကောင်းကောင်းတင်နိုင်ပါတယ်|
-
အထက်ပါ အဆင့်10ဆင့်ကတော့ Beginnerတွေအနေနဲ့ Bug report တစ်ခုကို ရေးတဲ့အခါမှာ သိထားသင့်တဲ့ Tipတွေ Trickတွေကို အဆင့်အလိုက် သေသေချာချာရှင်းပြပေးခဲ့တာဖြစ်ပါတယ်။
ဒီအဆင့် ၁၀ဆင့်ကို သေသေချာချာ နားလည်ရင်ပဲ Localပဲလာလာ Globalပဲလာလာ Bug reportရေးပြီးတင်နိုင်မှာပဲဖြစ်ပါတယ်🧞‍♂️

Thanks for reading & have a great bug hunting !

YouTube video available for 720p 60
Facebook doesn't allow 720p

How to make live stream server with nginx + RTMP

FYI for local company & pentester !

အားလုံးကို ဒီနေ့မှာ အသိပေးချင်တာရှိပါတယ် !
ကျွန်တော် Localမှာအကောင်ထည်ဖော်ချင်နေတဲ့ Programလေးတစ်ခုအကြောင်းကို
local security fieldမှာရှိတဲ့ အထူးသဖြင့်-
Jr. Pentesterတွေကို ပြောပြချင်တာလေးရှိပါတယ်။
အဲ့ဒါကတော့ Localမှာ Securityလိုအပ်နေတဲ့ Companyလေးတွေစုပေးပြီးတော့ Global လောက်အကြီးကြီးမဟုတ်ပဲ တတ်နိုင်သလောက်နဲ့
Local Bug Bounty Platformသဘောမျိုး Host လုပ်ပေးချင်ပါတယ်။ ဒါကတော့ ရှင်းရှင်းလေးနဲ့ နားလည်အောင်ပြောပြတာပါ။
တကယ့် Purpose ကို အချက်၂ချက်နဲ့အောက်မှာ ခွဲပြီး ရှင်းပြပါမယ် -
(1) Company Sideကို ဖတ်ချင်တယ်ဆို No1ကိုဖတ်
(2) Local Pentesterတစ်ယောက်ဆို No2ကိုဖတ်ပါ။

ဒီတော့ ဆက်ပြီး ဖတ်ကြည့်ပေးပါအုန်း -

CyberSecurity Servicesတွေမငှားနိုင်တဲ့ Local Companyလေးတွေရဲ့အခက်အခဲ
ကျွန်တော် Localမှာ Bug Reportတွေတင်တဲ့အတွေ့ကြုံအရ Local companyလေးတွေမှာ အခြားသော Business Team, Hr Team, Dev Teamဘာညာ ရှိနေတတ်ပေမယ့် Security Teamဆိုတဲ့ ကွက်လပ်တစ်ခုကတော့ လစ်ဟာနေတာများပါတယ်။ ဒါက သူတို့ ကိုယ်တိုင်ပဲ Security Knowledgeမရှိလို့လား၊ ရှိရက်နဲ့ Budget wasteဖြစ်မှာဆိုးလို့ မထားတာလားဆိုတာကတော့ သူတို့ပဲသိပါလိမ့်မယ်။ အခြား security sideကနေ မပြောတော့ပဲ လိုရင်းပဲပြောရမယ်ဆို - ဒီလို တသီးတသန့်ကြီး security teamရယ်လို့ မထားနိုင်တဲ့၊ မထားချင်တဲ့ companyလေးတွေရှိရင် လိုက်စုပြီး
ကျွန်တော့်ရဲ့ ဒီProgramနဲ့ပူးပေါင်းနိုင်ပြီး ၊ အဲ့ဒီအစား Programမှာရှာဖွေရင်း
Security issueတွေတွေ့ရှိတဲ့ Public Bug Hunterတွေကို Reward amountအနည်းငယ်ပေးရုံနဲ့ ဒီcompanyရဲ့problemက အဆင်ပြေသွားနိုင်ပါတယ်။
နောက်တစ်ခုက companyအသေးလေးတွေမှာ Securityအသိရှိရက်နဲ့ Pentest serviceတွေ Security Solution Companyတွေကို မငှားနိုင်တဲ့အခါမှာ
Budgetအရအဆင်ပြေချင်တယ်ဆိုရင် ဒီprogramကို joinနိုင်ပါတယ်။ Security Solution Companyတွေလောက် Perfect ဖြစ်လောက်အောင် coverဖြစ်ချင်မှ ဖြစ်ပါလိမ့်မယ်။ ဒါပေမယ့် ဒါက 0%ပဲရှိနေတဲ့ securityကို 50% လောက် အများဆုံး 70%လောက်အထိ
တိုးမြှင့်ပြီး coverဖြစ်နိုင်ရင်ကို အကျိုးရှိမယ်လို့ထင်ပါတယ်။
×
နောက်တစ်ခုက -
Localက Security သမားတွေ၊ အထူးသဖြင့် Local Pe*******on Testerတွေရဲ့ အခက်အခဲ
အဓိကက ဘာလဲဆိုတော့ -
Localမှာ Digital Securityနဲ့ပတ်သက်ပြီး အလုပ်ခေါ်စာ တစ်ခုတွေ့တယ်ဆိုပါတော့ မြေကြီးလက်နဲ့ထိတာကမှ
လွဲချင်လွဲလိမ့်မယ် သေချာပေါက် Blue Teamနဲ့ဆိုင်တဲ့ Job Roleတစ်ခုပဲ။ 100% အလုပ်ခေါ်စာတွေမှာ အများအားဖြင့် 80%လောက်က Security Analysis, Soc
အစရှိတဲ့ roleတွေကိုပဲ localမှာ အများအားဖြင့် ခေါ်နေတာတွေ့ရတယ်။ ဒီတော့ Red Teamသမားတွေ - အထူးသဖြင့် Pe*******on Testerတွေက Localမှာ နေရာပျောက်သလိုဖြစ်လာတယ်။ အလုပ်မရခင်အချိန်အတွင်းမှာ စာတွေ့တွေ့ခဲ့ရတဲ့အတွေ့ကြုံတွေကို သူတို့ ဘယ်မှာ အသုံးချရတယ်ထင်လဲ ? -
google dorkခေါက်ပြီး sqlပေါက်တဲ့ webတွေ၊ Xssပေါက်တဲ့ webတွေ စတဲ့ Real World Webတွေမှာ စပြီး လုပ်ရင်းလုပ်ရင်းကနေ နောက်ပိုင်း Real worldအရသာတွေ့ပြီး black hatဘက်ကို ရောက်သွားတာမျိုးတွေ တွေ့ရတယ်။ (ဒီနေရာမှာ အတွေ့ကြုံလိုချင်ရင် Global Bug Bountyသွားရှာချေလေ လို့တွေးမယ့်သူတွေ ရှိလိမ့်မယ်။ Globalမှာက Experienceတစ်ခုမှ မရှိရင် တိုးလို့ရမယ့်နေရာမဟုတ်ဘူးဆိုတာကို နားလည်ကြမယ်ထင်ပါတယ်။ Googleလို
Programတွေမပြောသေးဘူး programသေးသေးလေးတွေတောင်မှ အခြား Publicက Bug Hunterတွေနဲ့ တိုးရတာ Junior Pentesterတစ်ယောက်အတွက်အရမ်းကို ခက်ခဲနိုင်တာအသေချာပါပဲ)
ဒီတော့ အတွေ့ကြုံလိုအပ်နေတဲ့ Localက Pe*******on Testerတွေကို localမှာပဲ အတွေ့ကြုံတွေပေးချင်တယ်။ အတွေ့ကြုံလဲရမယ်၊ Reward amountအနည်းငယ်လဲရမယ် ဆိုပါတော့။ Globalမှာ Bug မ Huntနိုင်ခင်မှာ တက်သင့်တဲ့ stepတစ်ခုအနေနဲ့ ဒီprogramလေးကို ဖြစ်လာစေချင်တယ်။
Rewardကတော့ ရှင်းရှင်းလေးပဲပြောမယ် Globalလို အကြီးကြီးတွေ မပေးမှာတော့ အသေချာပဲ။
ပိုက်ဆံလိုချင်လို့ လာHuntမယ်ဆိုရင်တော့ တစ်သက်လုံးလာမhuntပါနဲ့ စွဂရုမစိုက်ပါဘူး :3။ ပိုက်ဆံလိုချင် Globalမှာရအောင်တိုးပါ။
"Experienceရချင်တယ်၊ Rewardလဲရဖူးချင်တယ် ၊
Local companyကအသိမှတ်ပြုတဲ့ Acknowledgementတစ်ခုခုရချင်တယ်" ဆိုရင် သေချာပေါက်ကို လာJoinသင့်တဲ့ programလို့
ကိုယ့်programကို promoteလုပ်ပါတယ်💁‍♂️💁‍♂️
လောလောဆယ်အနေနဲ့ Teamတခုအနေနဲ့ senior တွေနဲ့အတူ ဖွဲ့ပြီးပါပြီ။ Program Nameတွေ၊ Structureတွေမစခင်မှာ အားလုံးကို စိတ်၀င်စားမယ်ထင်လို့ အသိပေးထားတာပါ။
2025 နှစ်အစလောက်မှာ စပြီး runဖို့စဥ်းစားထားပါတယ်။

- Program Flowကတော့ ပုံမှန် Bug Bounty Programတွေလိုပဲ သွားပါမယ်။
Companyတွေက Testingလုပ်စေချင်တဲ့ scope areaကို သတ်မှတ်မယ်
Web,Api,Network,Cloud,Androidဘာညာအထိပေါ့။
ဒါကို Hackerတွေက Bug (Security Vuln)တွေရှာမယ်
ပြီးရင် Companyတွေကို Reportတင်မယ်။
ဒီလိုတင်တဲ့နေရာမှာ Companyမှာက Security သမားမရှိတဲ့ အခါမှာ hackerတွေနဲ့ interactလုပ်တဲ့အခါမှာ အခက်ခဲ့ရှိနိုင်တဲ့အတွက်၊ ကျွန်တော်တို့ Validation Teamတစ်ခုအနေနဲ့ Hackerတွေတင်တဲ့ Reportတွေကို ဟုတ်မဟုတ် စစ်ဆေးမယ်။
ဟုတ်တယ်ဆိုရင် Companyဆီကို ပြန်တင်ပြပြီး မဟုတ်ဘူးဆိုရင် Rejectမယ်ပေါ့။

လောလောဆယ်အနေနဲ့က Telegram Channelတစ်ခုမှာ Programတွေရော Hackerတွေရောကို စုထားချင်ပါတယ်။
စိတ်၀င်စားတယ်ဆိုရင် တချက် Join ထားပေးကြပါအုန်းဗျ -
https://t.me/p3nt3stlik3apro

Bug Bountyအကြောင်းကိုမသိသေးရင်တော့ ဒီလင့်ခ်ကနေ ၀င်ရောက်လေ့လာကြည့်ပါ -
https://www.facebook.com/share/v/1GqKAHdRCc/