ผม “Hack NASA” ยังไงให้ถูกกฎหมาย? จาก Bugcrowd สู่ Letter of Recognition จาก NASA [Guest Post]

บทความโดย: Itthidej Aramsri

 

หลายคนพอเห็นคำว่า “Hack NASA” อาจนึกถึงภาพแฮกเกอร์ที่เจาะเข้าไปในระบบลับขององค์กรอวกาศระดับโลก แต่สิ่งที่ผมทำในครั้งนี้ตรงกันข้ามกับภาพนั้นอย่างสิ้นเชิง เพราะทั้งหมดเกิดขึ้นภายใต้ Vulnerability Disclosure Program หรือ VDP ซึ่งเปิดพื้นที่ให้นักวิจัยด้านความปลอดภัยช่วยค้นหาและรายงานช่องโหว่อย่างถูกกฎหมาย

เป้าหมายไม่ใช่แค่ “หา Bug ให้เจอ” แต่ต้องทำทุกอย่างให้อยู่ใน Scope, พิสูจน์ผลกระทบเท่าที่จำเป็น, ไม่ทำให้ระบบเสียหาย และเขียนรายงานให้ทีมงานสามารถนำไปแก้ไขได้จริง

ผลลัพธ์ของงานครั้งนี้คือช่องโหว่ที่ผมรายงานได้รับการตรวจสอบและแก้ไข โดยมีทั้งรายการความรุนแรงระดับ P1 (Critical) และ P3 (Medium) และในท้ายที่สุดผมได้รับ Letter of Recognition หรือ LOR จาก NASA เพื่อรับรองการมีส่วนร่วมด้าน Security Research

 

NASA VDP คืออะไร และ Bugcrowd เกี่ยวข้องอย่างไร?

NASA มี Vulnerability Disclosure Policy เพื่อกำหนดขอบเขตและกติกาสำหรับนักวิจัยที่พบช่องโหว่บนระบบที่เปิดให้ทดสอบ โดย NASA ระบุให้ Bugcrowd เป็นช่องทางอย่างเป็นทางการสำหรับการส่งรายงานช่องโหว่

จุดสำคัญของ VDP คือเราต้อง ทดสอบเฉพาะระบบที่อยู่ใน Scope, หลีกเลี่ยงผลกระทบต่อ Production, ไม่ดึงข้อมูลเกินความจำเป็น และหยุดทันทีเมื่อพบ Sensitive Data หรือเมื่อพิสูจน์ช่องโหว่ได้เพียงพอแล้ว

อีกเรื่องที่หลายคนอาจเข้าใจผิดคือ NASA VDP ไม่ใช่ Bug Bounty ที่รับประกันเงินรางวัล โดย Policy ปัจจุบันระบุว่าไม่มีค่าตอบแทน แต่รายงานที่ผ่านเกณฑ์สามารถได้รับ Letter of Recognition ซึ่ง NASA ระบุว่าใช้กับรายงานระดับ P1-P4 ที่ผ่านการ Validated, Accepted, เป็นช่องโหว่ที่ NASA ไม่ได้ทราบอยู่แล้ว หรือ Duplicated, และ NASA จะออก LOR ให้หลังจากยืนยันแล้วว่าช่องโหว่ได้รับการแก้ไขแล้ว

Reference:

• Vulnerability Disclosure: National Aeronautics and Space Administration (NASA) – Vulnerability Disclosure Program – Bugcrowd
• Vulnerability Disclosure Policy – NASA

 

จุดเริ่มต้น: ผมเริ่มจากการอ่าน Scope

เวลาหา Bug เป้าหมายใหญ่ๆ สิ่งที่ผมพยายามไม่ทำคือเปิด Scanner แล้วหวังว่าจะมีอะไรเด้งขึ้นมา ผมเริ่มจากอ่าน Scope และ Policy ให้ละเอียดก่อน เพราะสำหรับ VDP ขนาดใหญ่ ความสามารถในการแยก “สิ่งที่ทดสอบได้” กับ “สิ่งที่ไม่ควรแตะ” สำคัญไม่แพ้ Technical Skill

จากนั้นผมจึงค่อยทำ Reconnaissance เพื่อทำความเข้าใจพื้นผิวของระบบ เช่นการหา Subdomain, Web Application, API, เทคโนโลยีที่ใช้งาน (Tech Stack) และ Flow ของฟังก์ชันต่าง ๆ เป้าหมายคือมองหาจุดที่ข้อมูลจากผู้ใช้เดินทางเข้าสู่ Backend หรือ Browser แล้วตั้งคำถามว่า “ข้อมูลนี้ถูก Trust มากเกินไปหรือเปล่า?”

 

วิธีคิดที่ใช้ตอน Research คือการมองหา Trust Boundary

แทนที่จะไล่ Payload แบบสุ่ม ผมพยายามตาม Data Flow ของฟังก์ชันที่น่าสนใจ ตั้งแต่ Request ที่ Browser ส่งออกไป จนถึงการประมวลผลฝั่ง Server และผลลัพธ์ที่กลับมาแสดงบนหน้าเว็บ วิธีนี้ช่วยให้เห็น “Trust Boundary” ว่าจุดไหนที่ระบบกำลังเชื่อข้อมูลจากผู้ใช้มากกว่าที่ควร

ในรอบนี้ผมพบช่องโหว่หลายประเภท โดยมีทั้ง Server-side Injection ที่มีผลกระทบระดับ Critical และ DOM-based Cross-Site Scripting ที่อยู่ระดับ Medium รายละเอียดเชิง Payload, Endpoint และข้อมูลระบบบางส่วนผมตั้งใจไม่ใส่ในบทความนี้ เพราะเป้าหมายคือเล่ากระบวนการเรียนรู้ ไม่ใช่แจกวิธีโจมตีระบบที่เคยมีช่องโหว่

 

Methodology ที่ผมใช้ ไม่ได้เป็นอะไรที่ซับซ้อน

ถ้าสรุปให้สั้นที่สุด ช่องโหว่ระดับ P1 (Critical) ที่ผมพบนี้ไม่ได้เกิดจากการที่ผมเปิดเครื่องมือแล้วเจอ SQL Injection ทันที แต่เกิดจากการไล่เล่นฟังก์ชันของ Web Application แบบ Manual และสังเกตความผิดปกติของ Request/Response ทีละจุด

1) Reconnaissance หา Attack Surface ก่อนหา Vulnerability

ผมเริ่มจากการทำ Subdomain Enumeration เพื่อดูว่าภายใต้โดเมน nasa.gov มีระบบอะไรที่เปิดให้เข้าถึงจากอินเทอร์เน็ตบ้าง จากนั้นใช้ Google Search Operator อย่าง ‘site:*.nasa.gov’ เพื่อช่วยค้นหา Web Application, หน้าเว็บ หรือระบบย่อยที่ Search Engine เคยทำ indexing ไว้ แล้วค่อยคัดเฉพาะระบบที่อยู่ภายใต้ Scope ของ VDP มาสำรวจต่อ

Google Dorking คืออะไร? ในบริบทนี้หมายถึงการใช้ Search Operator ของ Google เพื่อค้นหาข้อมูลที่ถูกจัดทำ indexing อยู่แล้ว เช่น จำกัดผลลัพธ์ให้อยู่ภายใต้โดเมนที่กำหนด ตัว Search Operator เองไม่ใช่การเจาะระบบ แต่ก่อนทดสอบเชิง Security ต้องตรวจสอบ Scope และ Policy ของโปรแกรมเสมอ

2) Manual Exploration เล่น Function ผ่าน Burp Suite

เมื่อเจอ Web Application ที่น่าสนใจ ผมไม่ได้รีบยิง Payload แต่เริ่มจากใช้งานระบบเหมือนผู้ใช้ปกติ กดเมนู, กรอกฟอร์ม, ส่งข้อมูล และสังเกตว่าแต่ละ Action สร้าง HTTP Request อะไรออกไป จากนั้นจึงใช้ Burp Suite เพื่อดูและปรับ Request ทีละส่วน

Burp Suite คืออะไร? Burp Suite เป็นชุดเครื่องมือสำหรับทดสอบความปลอดภัย Web Application โดย Burp Proxy ทำหน้าที่เป็น HTTP proxy อยู่ระหว่าง Browser กับ Web Server เพื่อให้ผู้ทดสอบเห็น Request/Response ที่วิ่งผ่าน

3) ตอนแรกผมกำลังลอง Mass Assignment

หนึ่งในฟังก์ชันที่ผมกำลังทดสอบรับข้อมูลแบบ POST หลาย field ผมจึงลองแนวคิด Mass Assignment ด้วยการเพิ่ม parameter ที่ทั้งมีอยู่และ ไม่ได้อยู่ในฟอร์มปกติ เพื่อดูว่า Backend จะรับ field เพิ่มเติมและผูกเข้ากับ object หรือ database model โดยอัตโนมัติไหม

Mass Assignment คืออะไร? Mass Assignment คือปัญหาที่เกิดเมื่อ Framework หรือ Backend นำ field จาก request ไปผูกกับ property ของ object/model แบบอัตโนมัติ หากไม่มี allowlist ผู้ใช้บางครั้งอาจส่ง field ที่ไม่ควรแก้ไขได้ เช่น role, status หรือ property ภายในอื่นๆ สำหรับเคสนี้ Mass Assignment เป็นเพียงสมมติฐานเริ่มต้น สิ่งที่พบจริงกลับเป็นคนละช่องโหว่

4) Parameter ที่เพิ่มเข้าไป Trigger SQL Syntax Error

ผลที่เกิดขึ้นกลับไม่ใช่การเพิ่ม Field สำเร็จ แต่ Response แสดง SQL Syntax Error เมื่อผมเปลี่ยน “ชื่อ” ของ Parameter บางรูปแบบ ตรงนี้เป็นสัญญาณสำคัญ เพราะถ้า Application ใช้เฉพาะค่าของ Parameter เป็นข้อมูลธรรมดา ชื่อ Parameter ไม่ควรส่งผลต่อโครงสร้าง SQL มากขนาดนี้

ผมจึงตั้งสมมติฐานใหม่ว่า Backend อาจนำ Parameter Name ไปใช้สร้างรายการชื่อ Column ของคำสั่ง SQL ‘INSERT’ แบบ Dynamic แทนที่จะกำหนด Column ที่ยอมรับไว้ตายตัว หากสมมติฐานนี้ถูกต้อง Input ที่ควรเป็นเพียงชื่อ Parameter จะกลายเป็นส่วนหนึ่งของโครงสร้าง SQL โดยตรง

ทำไม Parameter Name ถึงสำคัญ? สมมติ Request เป็น ‘name=boeing’ – ‘name’ คือ Parameter Name ส่วน ‘boeing’ คือ Parameter Value โดย SQL Injection ทั่วไปมักถูกพบจากฝั่ง Value แต่ในเคสนี้จุดที่ควบคุมได้กลับอยู่ที่ Parameter Name หากชื่อนั้นถูกนำไปสร้าง SQL Identifier หรือ Query Structure โดยตรง Prepared Statement ที่ป้องกันเฉพาะ Value ก็ไม่เพียงพอ จึงต้องกำหนดชื่อ Field แบบ Static หรือใช้ Allowlist เพิ่มเติม

5) ยืนยันสมมติฐาน Unauthenticated XPATH Error-Based SQL Injection

หลังจากยืนยันได้ว่าการเปลี่ยน parameter name ส่งผลต่อ SQL structure ผมจึงทดสอบต่อแบบ controlled เพื่อแยกให้ออกว่าเป็นเพียง malformed query หรือสามารถทำให้ฐานข้อมูลประเมิน SQL expression ที่ผู้ทดสอบควบคุมได้จริง ผลคือสามารถยืนยัน SQL execution ได้โดยไม่ต้องมี authentication

SQL Injection คืออะไร? SQL Injection (SQLi) คือช่องโหว่ที่ input จากผู้ใช้ส่งผลต่อ คำสั่ง SQL ในลักษณะที่ทำให้โครงสร้างหรือความหมายของ query เปลี่ยนไป ผลกระทบขึ้นอยู่กับสิทธิ์ของ database account และบริบทของ query ตั้งแต่การอ่านข้อมูล ไปจนถึงการแก้ไขข้อมูลในบางกรณี

6) XPATH Error-Based SQL Injection คืออะไร?

Error-Based SQL Injection เป็นเทคนิคที่ตั้งใจทำให้ Database เกิด Error ในจังหวะที่กำลังประมวลผล SQL Expression หาก Application ส่ง Error Message ของฐานข้อมูลกลับมายังผู้ใช้ ค่าบางส่วนจาก Query อาจปรากฏอยู่ในข้อความ Error ทำให้ Error Message กลายเป็นช่องทางเล็ก ๆ สำหรับสะท้อนผลลัพธ์ของ SQL Expression หรือ Database Metadata กลับมายังผู้ทดสอบ

คำว่า XPath ในชื่อช่องโหว่นี้มาจากการอาศัยพฤติกรรม Error ของฟังก์ชัน XML/XPath ในฐานข้อมูล เมื่อ XPath Expression ที่ถูกประมวลผลไม่ถูกต้อง Database จะคืนข้อความลักษณะ ‘XPATH syntax error’ และในกรณีที่ผู้ทดสอบควบคุม Expression ได้ ข้อมูลที่ต้องการยืนยันอาจถูกฝังอยู่ใน Error Message นั้น แนวคิดนี้จึงใช้เป็นหลักฐานว่า Injected SQL Expression ถูกประมวลผลจริง ไม่ใช่เพียงทำให้ Query พังเฉยๆ

UPDATEXML() ถูกใช้เป็น Error-Based Exfiltration Channel ได้ยังไง?

ประเด็นสำคัญคือ ช่องโหว่นี้ไม่ใช่ XPath Injection โดยตรง แต่เป็น SQL Injection ที่อาศัย Error Message จากฟังก์ชัน XML/XPath เป็นช่องทางสะท้อนผลลัพธ์ของ SQL Expression กลับมายังผู้ทดสอบ

หลังจากยืนยันได้ว่า HTTP Parameter Name สามารถเข้าไปมีผลต่อโครงสร้างของคำสั่ง SQL ได้ ขั้นตอนถัดมาคือการพิสูจน์ว่า Database สามารถประมวลผล SQL Expression ที่ควบคุมจาก Request ได้จริง

ในกรณีนี้ผมใช้พฤติกรรมของฟังก์ชัน ‘UPDATEXML()’ ของ MySQL/MariaDB เป็นช่องทางสำหรับ Error-Based SQL Injection

โดยทั่วไป ‘UPDATEXML()’ เป็นฟังก์ชันสำหรับจัดการข้อมูล XML และรับ XPath Expression เพื่อระบุตำแหน่งของข้อมูลที่ต้องการแก้ไข รูปแบบแนวคิดคือ

‘UPDATEXML(XML_document, XPath_expression, new_value)’

จุดที่สามารถนำมาใช้ในการยืนยัน SQL Injection ได้คือ หากค่าใน ‘XPath_expression’ ไม่ใช่ XPath ที่ถูกต้อง Database จะสร้าง Error Message ลักษณะ

‘XPATH syntax error: ‘…’‘

ผมจึงนำผลลัพธ์ของ SQL Expression ที่ต้องการพิสูจน์ เช่น Database Version ไปประกอบเป็นส่วนหนึ่งของ XPath Expression ที่ตั้งใจให้ไม่ถูกต้อง

ใน PoC แนวคิดหลักคือ

‘CONCAT(marker, SUBSTRING(VERSION(), …), marker)’

โดย ‘VERSION()’ ใช้ดึง Version ของ Database และ ‘CONCAT()’ ใช้ใส่ Marker ครอบค่าที่ต้องการดู เพื่อให้ง่ายต่อการแยกผลลัพธ์ออกจาก Error Message

เมื่อค่าดังกล่าวถูกส่งเข้าไปเป็น XPath Expression ของ ‘UPDATEXML()’ Database จะพยายามประมวลผล XPath แต่เนื่องจาก Expression ถูกสร้างให้ไม่ถูกต้อง จึงเกิด Error และสะท้อนข้อความกลับมาทาง HTTP Response

จากหลักฐานใน PoC สามารถเห็น Database Version ใน Response:

‘XPATH syntax error: ‘~10.x.xx-REDACTED~’‘

ดังนั้น Error Message ในกรณีนี้จึงทำหน้าที่เสมือนช่องทาง Exfiltration ขนาดเล็ก ทำให้ผมสามารถยืนยันได้ว่าช่องโหว่นี้ไม่ได้เป็นเพียงการทำให้ SQL Query เกิด Syntax Error เท่านั้น แต่สามารถทำให้ Database ประมวลผล SQL Expression ที่ผู้ทดสอบสามารถควบคุมได้

อย่างไรก็ตาม ในการทดสอบภายใต้ Responsible Disclosure ผมจำกัด PoC ไว้เพียงการดึง Database Metadata ที่ไม่ใช่ข้อมูลของผู้ใช้งาน เพื่อพิสูจน์ผลกระทบของช่องโหว่ และหยุดการทดสอบเมื่อมีหลักฐานเพียงพอ

ถ้ามองย้อนกลับไป ช่องโหว่นี้เริ่มจาก Observation เล็กๆ เพียงอย่างเดียว คือ ผมเพิ่ม Parameter เข้าไปเพื่อทดสอบ Mass Assignment แต่ Server กลับตอบ SQL Syntax Error จากตรงนั้นจึงเกิดสมมติฐานว่า Parameter Name อาจถูกนำไปสร้าง SQL Query โดยตรง และเมื่อทดสอบต่ออย่างจำกัดด้วย Error-Based Technique ก็สามารถยืนยันได้ว่า Database ประมวลผล SQL Expression ที่ควบคุมจาก Request ได้จริงๆ

Reference:

• Unauthenticated Error-Based SQL Injection via POST Parameter Name in /api/experiment/answer/new/ – CrowdStream – Bugcrowd
• XPATH Error Based SQL Injection. ✋Hi, I’m Gaurav (webcipher101), an… | by webcipher101 | Medium

 

ส่วนที่ยากกว่าการเจอ Bug คือทำให้คนอื่น Reproduce ได้

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

Report ที่ผมพยายามส่งให้ครบจะประกอบด้วย:

• Summary – ช่องโหว่คืออะไร และเกิดตรงส่วนไหน affected path คือ path อะไร
• Impact – ถ้าถูกโจมตีสำเร็จ ผู้โจมตีทำอะไรได้ ส่งผลกับ Security หรือ Business ยังไง
• Preconditions – ต้องล็อกอินหรือไม่ ต้องมีสิทธิ์ระดับไหน
• Reproduction Steps – ขั้นตอนที่ทำซ้ำได้ตั้งแต่ต้นจนเห็นผล
• Evidence – Request/Response, Screenshot หรือค่าที่แสดงให้เห็นผลกระทบ
• PoC – อาจจะเขียนเป็น Script เพื่อยืนยันช่องโหว่ หรือ อาจจะอัดเป็นวีดีโอเพื่อให้เห็นภาพ
• Remediation – ถ้าพอระบุ Root Cause ได้ ก็ควรช่วยชี้แนวทางแก้ไข

สิ่งที่ผมเรียนรู้ชัดเจนคือ “Report Quality” มีผลต่อรายงานมากจริงๆ รายงานที่อ่านง่าย ชี้ Root Cause ได้ และมี Evidence ที่ตรวจสอบได้ จะช่วยให้ทีม Triage เข้าใจประเด็นเร็วขึ้นและทำให้การสื่อสารระหว่าง Researcher กับองค์กรราบรื่นขึ้น

 

จาก Submitted → Validated → Accepted → Unresolved →Resolved เป็นช่วงที่ต้องใช้ความอดทน

บางครั้ง Severity อาจถูกประเมินต่างจากที่เราคิด และบางครั้งทีม Engineering ต้องใช้เวลาเพื่อแก้ไขให้ปลอดภัยโดยไม่กระทบระบบอื่น

ในเคสนี้ผมติดตามสถานะและให้ข้อมูลเพิ่มเติมเมื่อจำเป็น จนรายการที่เกี่ยวข้องถูกดำเนินการแก้ไขเรียบร้อย ตรงนี้เป็นช่วงที่ทำให้เห็นว่าการทำ Responsible Disclosure เป็นงานร่วมกันจริงๆ ฝั่ง Researcher ช่วยค้นหาและอธิบายปัญหา ขณะที่ฝั่งองค์กรต้อง Validate, Prioritize และ Remediate ภายใต้ข้อจำกัดของระบบจริง

 

วันที่ได้รับ Letter of Recognition

หลังช่องโหว่ผ่านกระบวนการไป จนถึงวันที่ช่องโหว่ได้รับการยืนยันว่าแก้ไขแล้ว สิ่งที่ผมได้รับคือ Letter of Recognition จาก NASA ซึ่งสำหรับผมมีความหมายมากกว่าเอกสารหนึ่งใบ เพราะมันเป็นหลักฐานว่า Research ที่ทำในเวลาว่างสามารถสร้างผลกระทบเชิงบวกให้ระบบขององค์กรระดับโลกได้

 

5 บทเรียนที่ผมได้จากการทำ NASA VDP

1. อ่าน Scope ให้ละเอียดก่อนแตะ Target, Technical skill ไม่มีประโยชน์ถ้าทดสอบผิดไปจาก Scope
2. คิดเป็น Data Flow มากกว่า Payload ต้องเข้าใจว่าข้อมูลเดินทางอย่างไร แล้วค่อยเลือก Test Case ที่เหมาะสม
3. พิสูจน์ Impact เท่าที่จำเป็น เป้าหมายคือช่วยป้องกัน ไม่ใช่พิสูจน์ว่าเราไปได้ไกลแค่ไหน
4. เขียน Report ให้เหมือนคนที่ไม่เคยเห็นระบบมาก่อนต้องอ่าน
5. อย่ายึดติดกับ Severity ให้โฟกัสที่ Root Cause, Evidence และการช่วยให้องค์กรแก้ไขปัญหาได้จริง

 

ถ้าอยากเริ่ม Bug Bounty / VDP ควรเริ่มยังไง?

สำหรับคนที่อยากลองทำ Security Research ผมคิดว่าไม่จำเป็นต้องเริ่มจาก Target ใหญ่ระดับ NASA สิ่งที่สำคัญกว่าคือสร้างพื้นฐานให้แข็งแรง แล้วฝึกกระบวนการคิดแบบเป็นระบบ

• เลือก Program ที่มี Scope และ Policy ชัดเจน
• ฝึก Web/API Fundamentals: HTTP, Authentication, Session, Browser Security และ Backend Logic
• อ่าน Write up เพื่อเรียนรู้วิธีคิด และลองสร้าง Test Case ของตัวเอง
• จด Note ระหว่าง Research เพื่อให้เขียน Report ได้ง่าย
• ฝึกเขียนรายงานภาษาอังกฤษให้กระชับ ได้ใจความ
• เคารพ Responsible Disclosure ทุกครั้ง โดยเฉพาะเมื่อพบข้อมูลที่ Sensitive

ถ้าเริ่มจาก Mindset แบบนี้ ต่อให้วันแรกยังไม่เจอช่องโหว่ ก็ยังได้ทักษะที่ใช้กับงาน Pentest, Red Team, Application Security และ Security Engineering ต่อได้ทั้งหมด

 

สิ่งที่ผมอยากฝากไว้

สิ่งสำคัญคือการเป็น Researcher ที่มีความอยากรู้ มีวินัย เข้าใจขอบเขต และรับผิดชอบต่อสิ่งที่ตัวเองค้นพบ

สำหรับผม Letter of Recognition จาก NASA เป็นหมุดหมายหนึ่ง แต่ไม่ใช่เส้นชัย เพราะยังมีระบบ และช่องโหว่อีกมากให้เรียนรู้ต่อไป และนั่นน่าจะเป็นส่วนที่สนุกที่สุดของสาย Cybersecurity