GitHub Bug Bounty: เจาะลึกเส้นทางแฮกเกอร์สายคุณภาพ @r31n

เพื่อร่วมฉลองเดือนแห่งการตระหนักรู้ด้านความปลอดภัยไซเบอร์ ทีม GitHub Bug Bounty ภูมิใจนำเสนอนักวิจัยระดับแนวหน้าจากโครงการของเรานั่นคือ @r31n!

ในฐานะบ้านของเหล่านักพัฒนาทั่วโลก GitHub ให้ความสำคัญกับความปลอดภัยและความน่าเชื่อถือของโค้ดในโครงการนับล้าน โครงการ Bug Bounty ของเรา จึงเป็นรากฐานสำคัญที่สร้างความร่วมมือกับนักวิจัยภายนอกเพื่อระบุและแก้ไขช่องโหว่ต่างๆ ทำให้แพลตฟอร์มปลอดภัยยิ่งขึ้นสำหรับทุกคน

ปัจจุบันเทคโนโลยี AI ได้เข้ามาลดอุปสรรคและช่วยทวีความสามารถในการทำงานวิจัยด้านความปลอดภัย ซึ่งทาง GitHub ยินดีต้อนรับนักวิจัยที่ใช้ AI อย่างไรก็ตาม หัวใจสำคัญของการวิจัยที่ยอดเยี่ยมยังคงอยู่ที่การตรวจสอบความถูกต้อง (validation) และการสร้าง proof of concept ที่ใช้งานได้จริง เพื่อแสดงผลกระทบด้านความปลอดภัยที่ชัดเจนมากกว่าแค่ทฤษฎี

นักวิจัยที่รักษามาตรฐานการทำงานในระดับนี้อย่างสม่ำเสมอ จะได้รับคำเชิญเข้าสู่โครงการ VIP ซึ่งมอบผลตอบแทนสูงกว่า มีระยะเวลาตอบสนองที่เร็วกว่า และเข้าถึงฟีเจอร์เบต้าได้ก่อนใคร ผู้ที่สนใจสามารถศึกษารายละเอียดเพิ่มเติมได้ที่ เว็บไซต์ bounty สาธารณะ

สำหรับการสัมภาษณ์ @r31n ในครั้งนี้ เราจะเจาะลึกผลงานใน GitHub Enterprise Server ซึ่งเขาได้ค้นพบประเด็นสำคัญซ้ำแล้วซ้ำเล่า โดยเฉพาะรายงานที่มีขั้นตอนการทำซ้ำชัดเจน ซึ่งช่วยให้ทีมวิศวกรของเราแก้ไขปัญหาได้อย่างรวดเร็ว

---

คุณเริ่มต้นเข้าสู่เส้นทางความปลอดภัยและ bug bounty ได้อย่างไร และอะไรที่ทำให้คุณกลับมาที่ GitHub อยู่เสมอ?

ผมต้องการพัฒนาทักษะความปลอดภัยนอกเหนือจากงานประจำครับ bug bounty ทำให้ผมได้สัมผัสเทคโนโลยีและสถาปัตยกรรมที่หลากหลาย GitHub เป็นโครงการที่ผมชอบมากเพราะมีพื้นที่สำหรับการโจมตี (surface area) กว้างและซับซ้อน มีฟีเจอร์ใหม่ๆ ตลอดเวลา ทำให้ไม่รู้สึกว่าเป้าหมายนี้เสร็จสมบูรณ์แล้ว นอกจากนี้ทีมงานยังดูแลนักวิจัยดีมาก มีโครงสร้างเงินรางวัลที่คุ้มค่า และของที่ระลึก (swag) ที่น่าสะสมครับ

ประเภทของบั๊ก (bug classes) ที่คุณชอบวิจัยมากที่สุดคืออะไร?

ผมสนใจเรื่อง exploit chains มากกว่าประเภทบั๊กเฉพาะเจาะจงครับ โดยเฉพาะการนำบั๊กเล็กๆ ที่ดูไม่เป็นอันตรายมารวมกันจนสร้างผลกระทบรุนแรงได้ เช่น การใช้ open redirect ร่วมกับ SSRF ในโดเมนที่ได้รับอนุญาต (allowlisted-domain) จนกลายเป็นห่วงโซ่การโจมตีที่ใหญ่ขึ้น การหาความเชื่อมโยงเหล่านี้ต้องใช้ทั้งความรู้ทางเทคนิคและความคิดสร้างสรรค์สูงมาก

คุณรักษาทักษะและติดตามเทรนด์ช่องโหว่ใหม่ๆ อย่างไร?

ผมติดตามทั้งบล็อก บทความเจาะลึก (write-ups) และงานสัมมนาครับ แต่ความรู้จะติดตัวได้ดีที่สุดเมื่อได้ลองลงมือทำเอง (hands-on) การทำซ้ำเทคนิคเหล่านั้นด้วยตัวเองจนเข้าใจว่าทำไมมันถึงพัง จะทำให้เราจดจำรูปแบบได้แม่นยำเมื่อเจอสถานการณ์จริงในเป้าหมายอื่น

เครื่องมือหรือกระบวนการทำงานใดที่เป็นตัวเปลี่ยนเกมสำหรับการวิจัยของคุณ?

ผมชอบการตรวจสอบด้วยตัวเอง (manual investigation) และเขียนสคริปต์ขนาดเล็กขึ้นมาใช้เฉพาะงานมากกว่าการใช้เครื่องมืออัตโนมัติชุดใหญ่ครับ แต่สิ่งที่ส่งผลกระทบต่อวิธีทำงานของผมมากที่สุดในช่วงหลังคือ AI

อย่างไรก็ตาม ทัศนคติสำคัญกว่าเครื่องมือครับ บางครั้งการพึ่งพาเครื่องมือมากเกินไปจะทำให้วิธีคิดเราแคบลงและพลาดบั๊กที่น่าสนใจ ความอยากรู้อยากเห็นและความพยายามคือสิ่งที่จะอยู่ได้นานกว่าเทคนิคที่เปลี่ยนไปตามยุคสมัย

แนวปฏิบัติทั่วไปในการเลือกพื้นที่เป้าหมายและการยืนยันผลการค้นพบของคุณเป็นอย่างไร?

ผมเริ่มจากการวางผังแอปพลิเคชันเพื่อทำความเข้าใจความเชื่อมโยงของส่วนประกอบต่างๆ โดยเฉพาะส่วนที่ซับซ้อนหรือขอบเขตความเชื่อถือ (trust boundaries) ผมจะมองในแง่ของ sources (จุดที่รับข้อมูลจากผู้โจมตี) และ sinks (จุดที่ข้อมูลถูกนำไปใช้งานที่สำคัญ)

การแกะรอยเส้นทางข้อมูลระหว่างสองจุดนี้ช่วยให้เห็นช่องโหว่โดยไม่ต้องยึดติดกับประเภทบั๊กที่กำหนดไว้ล่วงหน้า ผมจะถือว่าการค้นพบได้รับการยืนยันเมื่อผมเข้าใจเส้นทางการโจมตีทั้งหมด และสามารถสร้าง PoC ที่อธิบายผลกระทบได้ชัดเจนครับ

คุณใช้ AI ในการวิจัยอย่างไร และมีข้อจำกัดตรงไหน?

ผมใช้ AI เป็นตัวเร่งความเร็วครับ เช่น ช่วยอ่านโค้ดที่ไม่คุ้นเคย แกะรอยข้อมูลในฐานโค้ด หรือช่วยเขียนสคริปต์ PoC แต่ AI จะมีประโยชน์มากที่สุดเมื่อเราถามคำถามที่เฉพาะเจาะจงและให้บริบทที่ถูกต้อง

ข้อควรระวังคืออาการหลอน (hallucinations) และผลบวกปลอม (false positives) ผมไม่เคยเชื่อข้อสรุปของ AI ทันที ทุกอย่างต้องผ่านการตรวจสอบด้วยมือ AI ไม่สามารถแทนที่สัญชาตญาณหรือความเข้าใจในแอปพลิเคชันอย่างลึกซึ้งได้

คำแนะนำเกี่ยวกับการใช้ AI อย่างรับผิดชอบในโครงการ bug bounty คืออะไร?

จงใช้ AI เพื่อยกระดับงานวิจัย ไม่ใช่เพื่อโยนความรับผิดชอบครับ หาก AI บอกว่าเจอบั๊ก คุณยังต้องทำซ้ำและพิสูจน์ให้ได้ด้วยตัวเอง คุณควรมีความเข้าใจลึกซึ้งพอที่จะเขียนรายงานได้โดยไม่ต้องพึ่ง AI เพื่อให้ทีมความปลอดภัยเข้าใจปัญหาได้จริงๆ การใช้ AI ควรทำให้คุณภาพงานดีขึ้น ไม่ใช่แค่ทำให้มีจำนวนรายงานมากขึ้น

การทดสอบฟีเจอร์ AI ต้องใช้ทัศนคติที่แตกต่างจากบั๊กเว็บดั้งเดิมหรือไม่?

ใช่ครับ แต่ขอบเขตความปลอดภัยแบบเดิมก็ยังสำคัญ แม้ผู้โจมตีจะพยายามแทรกแซงการตัดสินใจของโมเดล แต่คำถามสำคัญคือผลลัพธ์นั้นทำให้เขาเข้าถึงสิทธิ์ที่ไม่มีได้หรือไม่ ดังนั้นการควบคุมที่แน่นอน (deterministic controls) รอบตัวโมเดล เช่น การแยกส่วน (isolation) และการตรวจสอบความถูกต้องของข้อมูล (validation) จึงยังจำเป็น เพราะผลลัพธ์จาก AI ก็คืออินพุตที่ไม่น่าเชื่อถือประเภทหนึ่งที่อาจนำไปสู่ XSS หรือ SQL injection ได้เช่นกัน

อะไรคือสิ่งที่คุณหวังว่าน่าจะรู้ตั้งแต่ตอนเริ่มต้น?

เรียนรู้เรื่อง "ระบบ" ไม่ใช่แค่ "เช็คลิสต์" ครับ เมื่อก่อนผมมักจะไล่ทำตามรายการ payloads หรือเทคนิคต่างๆ แต่การเข้าใจตรรกะภายในและกระแสข้อมูลมีค่ามากกว่ามาก การวิจัยที่น่าสนใจมักเริ่มจากคำถามง่ายๆ ว่า "ทำไมสิ่งนี้ถึงทำงานแบบนี้?" แทนที่จะเป็น "ควรลอง payload ไหนต่อไปดี?"

คำแนะนำสำหรับนักวิจัยที่ต้องการส่งรายงานฉบับแรกให้สำเร็จ?

ฝึกพื้นฐานให้แน่นและเลือกอยู่กับเป้าหมายเดียวให้นานพอที่จะสร้างโมเดลทางความคิด (mental model) ที่ถูกต้องครับ อย่ารีบเปลี่ยนเป้าหมายไปมา การอ่านเอกสารและเฝ้าสังเกตพฤติกรรม API จะช่วยให้เราเห็นจุดที่บั๊กซ่อนอยู่ และเมื่อเจอแล้ว ให้ใช้เวลาตรวจสอบให้รอบคอบก่อนส่งรายงานเสมอ

คุณสนุกกับการทำอะไรเมื่อไม่ได้แฮก?

ผมชอบปั่นจักรยานทางเรียบขึ้นเขาครับ มันท้าทายทางกายภาพและช่วยให้ห่างจากหน้าจอ การปีนเขามีความคล้ายกับการวิจัยช่องโหว่ตรงที่เราต้องลงแรงไปมหาศาลโดยไม่เห็นผลลัพธ์ในทันที แต่เมื่อถึงจุดหนึ่งมันจะคุ้มค่ามากครับ

มีโปรไฟล์โซเชียลมีเดียที่อยากแชร์ไหม?

สามารถติดตามผมได้ที่ HackerOne ครับ

---

ขอขอบคุณ @r31n ที่มาร่วมแบ่งปันประสบการณ์! ทุกรายงานที่ส่งเข้ามาช่วยให้ GitHub และลูกค้าของเราปลอดภัยยิ่งขึ้น หากคุณได้รับแรงบันดาลใจ สามารถร่วมรายงานผลการค้นพบได้ทาง HackerOne