ช่องโหว่ทำอีเมลผู้ใช้ YouTube รั่ว ได้รับรางวัล $10,000

 (brutecat.com)
1 คะแนน โดย GN⁺ 2025-02-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • obfuscated Gaia ID ซึ่งเป็นตัวระบุบัญชี Google ภายในของช่อง YouTube ถูกเปิดเผย และสามารถนำไปเชื่อมกับที่อยู่อีเมลผ่าน API แชร์ของ Pixel Recorder ได้ จึงกลายเป็นปัญหาความเป็นส่วนตัวของบัญชี Google
  • คำขอ Innertube ของเมนูบล็อกในไลฟ์แชตส่งคืนพารามิเตอร์ moderateLiveChatEndpoint ที่มี Gaia ID ของช่องเป้าหมาย แม้จะยังไม่ได้บล็อกจริง
  • เมื่อเปลี่ยน channel ID ในพารามิเตอร์คำขอ ขอบเขตเป้าหมายขยายไปถึง Topic Channel ที่ไม่มีข้อความไลฟ์แชต แสดงว่าไม่ใช่ปัญหาที่จำกัดเฉพาะผู้เข้าร่วมบางราย
  • WriteShareList ของ Pixel Recorder รับ obfuscated Gaia ID ของผู้รับแชร์เป็นอินพุต และในคำตอบมี ที่อยู่อีเมล รวมอยู่ด้วย อีกทั้งยังสามารถป้องกันไม่ให้ส่งอีเมลแจ้งเตือนได้ด้วยชื่อรายการบันทึกเสียงยาว 2.5 ล้านตัวอักษร
  • หลังได้รับรายงานเมื่อวันที่ 15 กันยายน 2024 Google ยืนยันว่าแก้ไขช่องโหว่ทั้งสองจุดแล้วเมื่อวันที่ 9 กุมภาพันธ์ 2025 และจ่ายรางวัลรวม $10,633

Gaia ID ที่ปรากฏจากฟีเจอร์บล็อกของ YouTube

  • พบจากเอกสาร discovery ของ Internal People API staging ของ Google ว่าอ็อบเจกต์ BlockedTarget ใช้ obfuscated Gaia ID และ fallbackName
    • profileId คือ obfuscated Gaia ID ของผู้ใช้ที่ถูกบล็อก
    • fallbackName คือชื่อที่แสดงของผู้ใช้ที่ถูกบล็อก
  • เอกสารช่วยเหลือของบัญชี Google ระบุว่าสามารถบล็อกบัญชีบน YouTube ได้ และเมื่อบล็อกผู้ใช้จริงในไลฟ์สตรีม YouTube ผู้ใช้นั้นจะปรากฏใน myaccount.google.com/blocklist
  • ในรายการบล็อก ชื่อช่อง Mega Prime แสดงเป็น fallbackName และ 107183641464576740691 แสดงเป็น profile ID
  • ภายใต้สมมติฐานว่าช่อง YouTube ไม่ควรเปิดเผยบัญชี Google ที่อยู่เบื้องหลัง และเนื่องจากในอดีตเคยมีบั๊กที่แปลง Gaia ID เป็นที่อยู่อีเมลได้ จึงเริ่มค้นหาเส้นทางเพิ่มเติม

ขยายจากเมนูไลฟ์แชตไปยังทั้งช่อง

  • เพียงเปิดเมนูจุดสามจุดในไลฟ์แชต YouTube ก็จะเกิดคำขอ /youtubei/v1/live_chat/get_item_context_menu
  • ในคำตอบมี moderateLiveChatEndpoint ที่นำไปยัง /youtubei/v1/live_chat/moderate และค่า params
  • params ดังกล่าวเป็น protobuf ที่เข้ารหัส base64 ซึ่ง Google ใช้กันทั่วไป และเมื่อถอดรหัสจะพบ Gaia ID ของผู้ใช้เป้าหมายที่จะถูกบล็อก
    • ตัวอย่างคำตอบมี 113907466537670370590 และตัวระบุที่เกี่ยวข้องกับช่อง
    • สามารถได้ Gaia ID ของเป้าหมายโดยไม่ต้องบล็อกจริง
  • เมื่อถอดรหัสพารามิเตอร์ของคำขอ get_item_context_menu พบว่ามี channel ID ของช่องที่จะบล็อก, ID วิดีโอไลฟ์สตรีม และ ID ผู้สร้างไลฟ์สตรีม
  • จากการทดสอบโดยเปลี่ยน channel ID ในพารามิเตอร์คำขอเป็นค่าอื่น พบว่ายังสามารถได้ Gaia ID 103261974221829892167 ของ Topic Channel ที่ YouTube สร้างอัตโนมัติได้ด้วย

Pixel Recorder กลายเป็นเส้นทางแปลงเป็นอีเมล

  • ระหว่างค้นหาบั๊กหรือข้อบกพร่องทางลอจิกในผลิตภัณฑ์ Google รุ่นเก่าที่อาจแปลง Gaia ID เป็นอีเมลได้ ได้ร่วมกับ nathan ตรวจสอบ Pixel Recorder
  • สร้างรายการบันทึกเสียงทดสอบบนโทรศัพท์ Pixel แล้วซิงก์กับบัญชี Google จากนั้นใช้เอนด์พอยต์ recorder.google.com บนเว็บ
  • เมื่อแชร์รายการบันทึกเสียงไปยังอีเมลทดสอบ คำขอ WriteShareList มี obfuscated Gaia ID อยู่ในรายชื่อผู้รับแชร์
  • คำตอบจาก PlaybackService/WriteShareList ของ pixelrecorder-pa.clients6.google.com ส่งคืนที่อยู่อีเมลของผู้รับแชร์รายนั้น
    • คำตอบทดสอบมี vrptest2@gmail.com
    • เมื่อใส่ Gaia ID 107183641464576740691 ที่ได้จากการทดลองบล็อกบน YouTube ก็ส่งคืน redacted@gmail.com เช่นกัน
  • ด้วยเหตุนี้จึงเกิด attack chain ที่นำ Gaia ID ที่ได้จาก YouTube ไปใส่ใน API แชร์ของ Pixel Recorder เพื่อค้นหาที่อยู่อีเมลได้

ชื่อรายการบันทึกเสียง 2.5 ล้านตัวอักษรที่หยุดอีเมลแจ้งเตือน

  • เมื่อแชร์รายการบันทึกเสียงใน Pixel Recorder กับเหยื่อ จะมีอีเมลแจ้งเตือนส่งไปยังเหยื่อ ซึ่งอาจทำให้ผลกระทบของการโจมตีลดลง
  • ในป๊อปอัปแชร์ไม่มีตัวเลือกปิดการแจ้งเตือน และแม้วิเคราะห์ protobuf ของคำขอด้วย req2proto ก็ไม่พบฟิลด์สำหรับปิดการแจ้งเตือน
  • โครงสร้าง WriteShareListRequest มีฟิลด์ต่อไปนี้
    • recording_id
    • delete_obfuscated_gaia_ids
    • update_shared_users
    • sharing_message
  • แม้จะเพิ่มและลบผู้ใช้พร้อมกัน อีเมลก็ยังถูกส่งอยู่
  • จากข้อสังเกตว่าหัวเรื่องอีเมลแจ้งเตือนมีชื่อรายการบันทึกเสียงรวมอยู่ด้วย จึงประเมินว่าหากทำให้ชื่อรายการบันทึกเสียงยาวมาก อาจทำให้การส่งอีเมลล้มเหลวได้
  • เขียนสคริปต์ Python เพื่อทดสอบการเปลี่ยนชื่อรายการบันทึกเสียงเป็น 2.5 ล้านตัวอักษร ผ่านเอนด์พอยต์ UpdateRecordingTitle และพบว่าไม่มีการจำกัดความยาวชื่อฝั่งเซิร์ฟเวอร์
  • หลังตั้งชื่อเป็น 2.5 ล้านตัวอักษรแล้วแชร์ให้ผู้ใช้ทดสอบรายอื่น พบว่าอีเมลแจ้งเตือนไม่ถูกส่ง

PoC สุดท้ายและกำหนดการดำเนินการ

  • attack chain ที่เสร็จสมบูรณ์ประกอบด้วยสามขั้นตอน
    • รับ obfuscated Gaia ID ของช่องเป้าหมายจากเอนด์พอยต์ YouTube Innertube /get_item_context_menu
    • แชร์รายการบันทึกเสียง Pixel Recorder ที่มีชื่อยาวมากกับเป้าหมาย เพื่อแปลง Gaia ID เป็นที่อยู่อีเมล
    • ลบผู้ใช้นั้นออกจากผู้รับแชร์ของรายการบันทึกเสียง Pixel Recorder เพื่อเก็บกวาด
  • วิดีโอ PoC มีให้ดูใน วิดีโอ YouTube

รางวัลจาก Google และไทม์ไลน์การแก้ไข

  • 2024-09-15: ส่งรายงานให้ผู้ให้บริการ
  • 2024-09-16: ผู้ให้บริการ triage รายงาน และได้รับคำตอบว่า Nice catch!
  • 2024-10-03: คณะกรรมการทำเครื่องหมายว่าเป็นรายงานซ้ำของบั๊กที่ติดตามอยู่เดิม และทำแพตช์ที่ยังไม่สมบูรณ์สำหรับการเปิดเผย YouTube obfuscated Gaia ID ในช่วงแรก
  • 2024-10-03: อธิบายกับผู้ให้บริการอีกครั้งว่า Pixel Recorder เองก็เป็นช่องโหว่ด้วย
    • obfuscated Gaia ID สามารถถูกเปิดเผยได้จากผู้รีวิวใน Google Maps และ Google Play เช่นกัน
    • ยังให้วิธีบายพาสที่ทำให้ obfuscated Gaia ID ของช่อง YouTube รั่วอีกครั้งด้วย
  • 2024-11-05: คณะกรรมการจ่ายรางวัล $3,133
    • เหตุผลคือมีความเป็นไปได้ในการใช้โจมตีระดับปานกลาง
    • จัดอยู่ในหมวด abuse-related methodology ที่มีผลกระทบสูง
  • 2024-12-03: ทีมผลิตภัณฑ์ส่งรายงานกลับไปยังคณะกรรมการเพื่อพิจารณารางวัลเพิ่มเติม และประสานกำหนดเผยแพร่ในวันที่ 2025-02-03
  • 2024-12-12: คณะกรรมการจ่ายรางวัลเพิ่มเติม $7,500
    • เหตุผลคือมีความเป็นไปได้ในการใช้โจมตีสูง
    • จัดอยู่ในหมวด abuse-related methodology ที่มีผลกระทบสูง
    • เนื่องจากความซับซ้อนของ attack chain จึงถูกปรับลดลง 1 ระดับจากจำนวนเงินพื้นฐาน
  • 2025-01-29: ผู้ให้บริการขอเลื่อนกำหนดเผยแพร่เป็น 2025-02-02
  • 2025-02-09: ยืนยันว่าทั้งสองส่วนของ attack chain ได้รับการแก้ไขแล้ว
    • เป็นเวลา 147 วัน หลังจากรายงานครั้งแรก
  • 2025-02-12: รายงานถูกเผยแพร่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-02-13
ความเห็นจาก Hacker News

  • ชื่อเรื่องทำให้งง สำหรับคนที่ไม่ได้อ่านจนจบจะสรุปให้ว่า ไม่ใช่ว่าอีเมลที่รั่วทำให้ต้องเสียเงิน แต่เขาใช้เวลาและไหวพริบแล้วได้รับ เงินรางวัลบั๊กบาวน์ตี 10,000 ดอลลาร์

    • ตอนแรกนึกว่าหมายถึงให้บริการเปิดเผยอีเมลผู้ใช้ในราคา 10,000 ดอลลาร์ต่อผู้ใช้หนึ่งราย
    • ฉันก็นึกเหมือนกันว่าหมายถึงเป็นบริการราคา 10,000 ดอลลาร์
    • อาจเป็นพาดหัวที่ตั้งมาเพื่อเรียกคลิก
    • ตอนแรกนึกว่าจะเป็นเรื่องทำนอง ต้นทุนการประมวลผล สำหรับ brute-force hash บางอย่าง

  • มีแต่เสียงพูดถึงการเปิดเผยอย่างรับผิดชอบ แรงจูงใจ และรางวัล แต่กลับไม่ค่อยมีคนพูดว่านี่คืออีกหนึ่งเหตุผลที่คัดค้าน ตัวตนถาวรแบบรวมศูนย์
    ทุกครั้งที่มีคนอ้างว่าบริการบางอย่างทำงานได้ดีที่สุดเมื่อผูกกับ Real Identity™ เพียงหนึ่งเดียว ก็ทำให้นึกว่าบริษัทต่าง ๆ สนใจปกป้องผู้ใช้แค่ในเชิงนามธรรม และยังเป็นแบบนั้นแค่บางครั้งบางคราวเท่านั้น
    ถ้าลองจินตนาการว่าทุกคนที่มีปฏิสัมพันธ์บน YouTube อาจเข้าใกล้การถูกขุดคุ้ยตัวตนส่วนตัวขึ้นทันทีอีกสามสี่ขั้น ผลกระทบที่แท้จริงของบั๊กนี้ก็น่าจะประมาณนั้น ดีแล้วที่ถูกแก้ไข แต่บั๊กประเภทนี้คงไม่หายไปในเร็ว ๆ นี้ ต้องเกิดอะไรขึ้นกันแน่ บริษัทกับองค์กรขนาดใหญ่ถึงจะตระหนักได้ว่าการออกแบบแบบนี้คือทุ่งกับระเบิดที่พร้อมระเบิดได้ทุกเมื่อ

    • โดยหลักการแล้วเห็นด้วย บัญชีแบบนี้ควรยอมให้มี ความไม่เปิดเผยตัวตนและการทิ้งได้ ในระดับหนึ่ง เพราะสุดท้ายมันก็เป็นแค่หนึ่งแถวในฐานข้อมูลที่ไหนสักแห่ง
      แต่หลายคนก็ทำธุรกรรมกับบริษัทพวกนี้ด้วยเงินจริง เช่น สมาชิก YouTube Premium หรือครีเอเตอร์ ในทางปฏิบัติแล้วต้องมีตัวระบุอัตลักษณ์ในโลกจริงถูกเก็บไว้ที่ไหนสักแห่งของบัญชีที่ทิ้งได้นั้น ด้วยความเสี่ยงเรื่องการฉ้อโกงและข้อเท็จจริงของระบบธนาคาร ผู้ใช้จึงต้องส่งมอบตัวตนจริงและที่อยู่ให้บริษัท และบริษัทก็ต้องเก็บมันไว้
      ฉันจะไม่ให้ข้อมูลที่ใช้ระบุตัวคนกับแอปหรือเว็บไซต์สุ่ม ๆ แต่คู่ค้าที่ฉันทำธุรกรรมด้วยย่อมต้องรู้ว่าฉันเป็นใครในโลกจริง และในทางทฤษฎีนั่นก็กลายเป็นจุดที่ข้อมูลอาจรั่วไหลได้
    • เพราะไม่มีผลทางกฎหมายไงถึงไม่สนใจ
      ลองให้ผู้ให้บริการด้านสุขภาพทำ ข้อมูลทางการแพทย์ รั่วสิ แล้วจะพังยับเลย

  • “นี่คือ POC ของ exploit ที่ใช้งานได้: วิดีโอนี้ถูกลบเนื่องจากละเมิดข้อกำหนดการให้บริการของ YouTube” ฟังดูตลกดี

    • ผู้เขียนต้นฉบับเปิดเผยที่อยู่อีเมลของผู้ใช้ที่มีตัวตนอยู่จริงเพื่อเป็น proof of concept ในวิดีโอที่อัปโหลดใหม่ ที่อยู่อีเมลถูกเบลอไว้
    • ตอนแรกฉันก็เห็นแบบนั้นเหมือนกัน แต่พอเปิดบทความอีกครั้ง ดูเหมือนว่าวิดีโอจะมองเห็นได้แล้ว ไม่แน่ใจว่าเพิ่งถูกกู้คืนเมื่อกี้หรือเปล่า

  • เพราะทุก ๆ คอมเมนต์ที่สามในเธรดนี้พูดว่า Google จ่ายให้บั๊กนี้น้อยเกินไป เลยขอพูดเรื่องพื้นฐานของ การประเมินมูลค่าช่องโหว่ ไว้ประมาณนี้
    ช่องโหว่ฝั่งเซิร์ฟเวอร์มีมูลค่าต่ำกว่า เพราะบริษัทต่าง ๆ ไม่ได้แข่งขันกันซื้อ แทบไม่มีตลาดสีเทาสำหรับช่องโหว่ฝั่งเซิร์ฟเวอร์เลย Google ปิดมันได้ทันที อายุใช้งานหลังถูกค้นพบก็แทบไม่มี และบั๊กที่พอถูกใช้โจมตีก็จะเกิด telemetry ระยะไกลที่เชื่อถือได้จากเป้าหมายแบบนี้ บุคคลที่สามจึงตีราคาได้ยาก
    ตรงกันข้าม บั๊กอย่าง full-chain ของ Android/Chrome ขายกันได้หลายแสนดอลลาร์ เพราะ Google ต้องแข่งขันกับตลาดสีเทาที่ก่อตัวชัดเจนแล้ว ผู้ขายรายหนึ่งอาจเอาบั๊กนั้นไปขายต่อให้หลายหน่วยงานในประเทศยุโรปประเทศหนึ่งได้ อาจถึง 6 แห่ง
    ถึงอย่างนั้น bounty กับตลาดสีเทาก็เทียบกันเหมือนเอาแอปเปิลไปเทียบส้ม Google ไม่ต้องการ exploit ที่เชื่อถือได้สูง แค่หลักฐานว่ามันเขียนได้ก็พอ และไม่ต้องรับภาระค่าบำรุงรักษา จึงจ่ายน้อยกว่าตลาดสีเทามาก มูลค่ารวมในตลาดอีกฝั่งยังถูกแบ่งออกเป็นหลายชั้นและมีเงื่อนไขความเสี่ยงกำกับ แต่ Google ยังสามารถเสนอเงินก้อนครั้งเดียวที่น่าสนใจได้แม้จะมีส่วนลด
    ผู้โจมตีจะซื้อช่องโหว่ที่เข้ากับกระบวนการธุรกิจที่มีอยู่แล้ว โดยทั่วไปพวกเขาไม่ได้จินตนาการแบบคาดเดาล้วน ๆ ว่าช่องโหว่ใหม่อันหนึ่งจะทำอะไรเจ๋ง ๆ ได้บ้างหรือทำเงินอย่างไร การเก็บข้อมูลการชำระเงิน การยึดเครื่องหลายพันเครื่องไปทำ botnet นั้นเป็นกระบวนการธุรกิจที่มีอยู่แล้ว การเปิดเผยชื่อจริงของเจ้าของบัญชี Google จะทำเป็นธุรกิจได้ไหม? อาจได้ แล้วมีอยู่แล้วไหม? น่าจะยังไม่มี
    โดยปกติจำนวนเงิน bounty ไม่ใช่การโหวตจากมหาชนว่าบั๊กนี้ฉลาดหรือชวนสนใจแค่ไหน แต่กรณีนี้ก็เป็นแบบนั้นอยู่นิดหน่อย เพราะ 10,000 ดอลลาร์ สำหรับบั๊กเว็บฝั่งเซิร์ฟเวอร์ถือว่าสูงผิดปกติพอสมควร
    สำหรับคนที่หาเลี้ยงชีพด้วยการหาบั๊กแบบนี้ กลยุทธ์ทางธุรกิจคือทำให้เก่งในการหาให้ได้จำนวนมาก มันต่างจากการพัฒนา iOS exploit ที่เชื่อถือได้ตัวเดียวซึ่งอาจต้องทุ่มเวลาเป็นเดือน
    งานวิจัยช่องโหว่ที่ผมทำในช่วงหลังของอาชีพก็ใกล้กับด้านนี้มากกว่างานอีกหลายแบบ เลยค่อนข้างมั่นใจ แต่ใน HN ก็น่าจะมีคนที่ทำงาน bounty แบบนี้เต็มเวลาอยู่ด้วย ถ้ามีใครแบบนั้นมาแก้ไขก็ยินดีมาก

    • งานสาขาอื่นส่วนใหญ่ไม่ได้รับค่าตอบแทนโดยอิงจาก มูลค่าในตลาดมืด ของสิ่งที่สร้างขึ้น
      ถ้าเอาการวิเคราะห์แบบนี้ไปใช้กับอย่างอื่น เพดานราคาของเครื่องเสียงรถยนต์หรือจักรยานคันใหม่ก็คงอยู่ราว 100 ดอลลาร์ และสินค้าที่มีลิขสิทธิ์ทั้งหมดก็ควรมีราคาไม่เกินต้นทุนในการส่งผ่านเครือข่าย
      ผมว่าการเอาเงินที่ Google จ่ายไปหารด้วยเวลาที่ใช้ทำงานนี้ รวมถึงเวลาที่เสียไปกับความพยายาม exploit ที่ล้มเหลวทั้งหมดนับตั้งแต่ bounty ครั้งก่อน จะมีประโยชน์กว่า
      คนส่วนใหญ่ในวงการนี้น่าจะมีรายได้ต่อแรงงานต่ำกว่าค่าแรงขั้นต่ำของสหรัฐ และกำลังแบกรับค่าเสียโอกาสระดับหกหลักต่อปี
      ตัวเลขนั้นสะท้อนอย่างแม่นยำว่า Google ให้คุณค่ากับความปลอดภัยและความเป็นส่วนตัวของผู้ใช้ปลายทางมากแค่ไหน มันต่ำกว่าตัวเลขที่พวกเขาจ่ายให้วิศวกรคนอื่นเพื่อขโมยข้อมูลส่วนตัวของคนกลุ่มเดียวกันอยู่หลายหลัก
    • ผมไม่ชอบที่เธรด HN นี้ส่วนใหญ่คุยกันเรื่องจำนวนเงิน bounty แต่ก็เป็นเรื่องธรรมชาติ คนที่คอมเมนต์ที่นี่ส่วนมากทำงานในอุตสาหกรรมซอฟต์แวร์ และอยากให้ bounty ที่สูงมาก กลายเป็นเรื่องปกติ
      เพราะมันเป็นแหล่งรายได้เสริมสำหรับพวกเขา พวกเขาอยากให้ bug bounty สูงขึ้นแบบเดียวกับที่วิศวกรซอฟต์แวร์อยากให้อาชีพของตัวเองเป็นงานที่ค่าตอบแทนสูง เป็นธรรมดาที่แรงงานจะเรียกร้องค่าจ้างในอาชีพของตัวเองให้มากขึ้น และคำอธิบายเชิงเหตุผลแบบไหนก็ไม่เปลี่ยนสัญชาตญาณนั้น
    • บอกว่า “ผู้โจมตีซื้อช่องโหว่ที่เข้ากับกระบวนการธุรกิจที่มีอยู่” แต่สิ่งนี้ก็มีตลาดไม่ใช่หรือ? อย่างเช่น “มาหาว่าคนที่อยู่เบื้องหลังบัญชีที่วิจารณ์บริษัท/รัฐบาลอันน่าสงสัยของเราคือใคร แล้วทำให้เขาหมดอำนาจ”
      ยังมีแรงจูงใจอื่นที่แยกจากมูลค่าในตลาดของผู้โจมตีด้วย คนรุนแรงที่สะกดรอยคนดังบนออนไลน์อาจไม่ใช่ลูกค้าที่ทำกำไรได้ในตลาด zero-day exploit แบบนี้ แต่ถ้าบริษัทประมาทจนเปิดเผยตัวตนของเป้าหมายให้ stalker ที่มีแนวโน้มใช้ความรุนแรงได้ ช่องโหว่นั้นก็ยังคงเป็น ความเสี่ยงด้านความรับผิดและจริยธรรม
      โดยส่วนตัว ผมคิดว่าถ้าคุณยอมจ่ายเงินมหาศาลให้กับพวกนักโชว์ผลงาน LeetCode ที่เขียนโค้ดออกมาปริมาณมหาศาลโดยใส่ใจความปลอดภัยอย่างไม่สมบูรณ์ คุณก็ควรจ่ายดี ๆ ให้กับคนที่ช่วยหาความผิดพลาดมากมายของพวกเขาและแก้ไขมันก่อนจะเกิดเรื่องแย่ ๆ ด้วย
    • การที่หน่วยงานบังคับใช้กฎหมายจะใช้บั๊กฝั่งเซิร์ฟเวอร์โจมตีอาจอยู่ในพื้นที่สีเทามากกว่า หรืออาจผิดกฎหมายจริงด้วยซ้ำ ขณะที่กระบวนการมาตรฐานในการขอคำสั่งศาลเพื่อโจมตีอุปกรณ์ของเป้าหมายโดยเฉพาะ เช่น โทรศัพท์หรือแล็ปท็อปนั้น มีอยู่แล้วสำหรับหน่วยงานบังคับใช้กฎหมายหรือหน่วยข่าวกรอง

  • ที่บอกว่า “ปรับลดจากจำนวนเงินพื้นฐานลงหนึ่งขั้น เพราะความซับซ้อนของ attack chain ที่ต้องใช้” แบบนี้พบได้บ่อยไหม?
    ผมเคยเข้าร่วมโปรแกรมช่องโหว่มาไม่กี่แห่ง แต่ส่วนใหญ่ถ้าเป็น ข้อบกพร่องที่เรียบง่ายจนน่าเหลือเชื่อแต่ร้ายแรง อย่างเช่นมีอีเมลผู้ใช้โผล่ใน source ของหน้าเว็บ กลับยิ่งจ่ายน้อยกว่า

    • ผมเข้าใจว่าเขาหักคะแนนเพราะสำหรับช่องโหว่เว็บแล้ว อันนี้ค่อนข้างซับซ้อนกว่าปกติ
    • อันนี้ดูเหมือนกลับด้านนะ เท่ากับว่าจริง ๆ แล้วเจอบั๊ก 2 ตัว ก็น่าจะเพิ่มจากเงินพื้นฐานมากกว่า

  • ที่บอกว่า “เมื่อไม่นานมานี้ตอนกำลังหาพื้นที่วิจัยใน Google ผมกำลังขุดดูเอกสาร discovery ของ Internal People API (Staging)” นี่มันควรเปิดสาธารณะไว้เฉย ๆ ได้จริงหรือ: https://staging-people-pa.sandbox.googleapis.com/$discovery/...

    • มันเป็นแค่ ไฟล์สคีมา ที่ถูกแปลงอัตโนมัติมาจากนิยาม .proto ภายใน Google พึ่งพา cryptography จริง ไม่ใช่ security through obscurity
      อีกอย่าง endpoint สำหรับ discovery ก็มีเอกสารสาธารณะอยู่แล้ว[0] และถูกสร้างมาเพื่อผู้ใช้ภายนอก คนภายในคงไม่มาอ่าน endpoint ของ discovery แต่จะเปิดดูไฟล์ .proto ตรง ๆ ผ่าน code search มากกว่า
      จากประสบการณ์ที่เคยทำงานที่ Google ถ้าจะเปิด API แบบสาธารณะได้ต้องสู้กับระบบราชการกันเป็นสัปดาห์ ๆ มันไม่ใช่กรณีแบบ AWS S3 bucket ที่หลุดมาเปิดโดยบังเอิญ ทีมงานรู้อยู่แล้วว่านี่เป็นของสาธารณะ และน่าจะฝ่าระบบราชการมาเพื่อเปิดมัน
      [0]: https://developers.google.com/discovery/v1/getting_started

  • ถ้าดูตามไทม์ไลน์ของบทความ จะเห็นว่ารายงานให้บริษัททราบเมื่อ 2024-09-15, บริษัทขอขยายเวลาการเปิดเผยไปถึง 2025-02-12 เมื่อ 2025-01-29, ยืนยันได้ว่าช่องโหว่ทั้งสองฝั่งถูกแก้แล้วเมื่อ 2025-02-09 และเปิดเผยเมื่อ 2025-02-12
    ถ้าอย่างนั้นก็แปลว่าไม่ได้แก้อยู่ 136 วัน และ Google เป็นฝ่ายขอขยายเวลาไม่ใช่หรือ แก้เสร็จใน 147 วัน และเปิดเผยใน 150 วัน
    เมื่อเทียบกับกำหนดเวลาเปิดเผยก่อนแพตช์ที่ Google Project Zero ใช้กับบริษัทอื่น เขาระบุว่า “บั๊กนี้อยู่ภายใต้กำหนดเปิดเผย 90 วัน หากมีการส่งมอบแพตช์ให้ผู้ใช้ก่อนครบ 90 วัน รายงานบั๊กนี้จะถูกเปิดเผย 30 วันหลังจากส่งมอบแพตช์ มิฉะนั้นจะเปิดเผยเมื่อครบกำหนด”
    “หากคาดว่าแพตช์จะออกภายใน 14 วันหลังครบกำหนด Project Zero อาจให้ขยายเวลาได้… อย่างไรก็ตาม ระยะผ่อนผัน 14 วันนี้ทับซ้อนกับช่วงการนำแพตช์ไปใช้ 30 วัน ดังนั้นแม้ช่องโหว่จะถูกแก้ภายในช่วงผ่อนผัน ก็ยังจะถูกเปิดเผยไม่เกินวันที่ 120 นับจากกำหนดเดิม 90 วัน”
    “หากเห็นว่าไม่น่าจะมีแพตช์พร้อมภายใน 14 วัน จะใช้กำหนดเดิม 90 วันเป็นวันเปิดเผย กล่าวคือ จะให้ขยายเวลา 14 วันเฉพาะเมื่อผู้พัฒนารับปากว่าจะปล่อยแพตช์ภายในช่วงผ่อนผัน 14 วันเท่านั้น”
    https://googleprojectzero.blogspot.com/p/vulnerability-discl...

    • ไม่คิดว่าการเทียบแบบนี้จะมีประโยชน์ นี่เป็นบั๊กของ Google ในซอฟต์แวร์ของ Google เอง ขณะที่สิ่งที่ Project Zero หาเจอมักเป็นบั๊กในซอฟต์แวร์ที่คนจำนวนมากใช้ จึงเข้าใจได้ว่าความเร่งด่วนในการแก้จะสูงกว่า

  • ที่บอกว่า “params พวกนั้นก็เป็นแค่ protobuf ที่เข้ารหัสด้วย base64 ซึ่งเป็นรูปแบบการเข้ารหัสที่ใช้กันทั่วไปทั่ว Google” นี่ ต้องขอชนแก้วให้กับนักพัฒนา Google ผู้รับหน้าที่ยัดรูปแบบข้อความไบนารีอันหรูหราให้กลายเป็น base64 encoding แล้วฝังลงไปในก้อน JSON จริง ๆ
    ถ้าอยากเห็นภาพอนาคต ก็ให้จินตนาการถึงรองเท้าบูตที่มีคำว่า “worse is better” สลักอยู่ใต้พื้น กำลังกระทืบหน้าวิศวกรไปตลอดกาล

    • ของแบบนี้มีอยู่ทุกที่และแย่มาก บางทีก็คิดว่า ปริมาณ protobuf bytes ที่แสดงเป็น base64 อยู่ใน JSON อาจมากกว่าปริมาณ protobuf bytes จริงที่วิ่งอยู่บนสายอินเทอร์เน็ตด้วยซ้ำ แล้วก็ต้องชนแก้วให้ตัวเอง
    • ภายในก็คงเป็น base64 protobuf ซ้อนอยู่ในฟิลด์ protobuf อีกที
      ส่วน JSON น่าจะเป็นการแปลงอัตโนมัติ
    • สตริง JSON ที่เป็น protocol buffer เข้ารหัสด้วย base64 นี่นะ ถึงจะไม่รู้ว่าบริษัทไหนทำ แต่ก็พอเดาออกว่าบริษัทไหนทำ

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

    • นี่อาจเป็นอีกเหตุผลที่ Google ยกเลิกผลิตภัณฑ์จำนวนมากที่แม้จะประสบความสำเร็จ แต่ก็ไม่มากพอจะคุ้มกับการดูแลให้ใช้งานต่อและปลอดภัยภายในระบบทั้งหมดของ Google
    • น่าเสียดายที่เมื่อคิดถึงจำนวนผู้ใช้ของ Google การยกเลิกอะไรก็ตามย่อมเรียกเสียงโวยวายและแรงต้านแบบ “ฉันพึ่งมันไว้ใช้กด spacebar อุ่นคอมพิวเตอร์” อยู่ดี ดูได้ที่ https://killedbygoogle.com/
    • อยากให้ยกตัวอย่างที่ทำให้ ความปลอดภัย ดู “เป็นของจริง” และอธิบายว่ามันช่วยอย่างไร
      ผลิตภัณฑ์ซอฟต์แวร์ส่วนใหญ่พึ่งพา software stack ที่ซับซ้อนมาก และถ้าคิดว่าสามารถเชื่อถือไลบรารีทุกตัวรวมถึงระบบปฏิบัติการทั้งหมดได้ 100% ก็ถือว่าเป็นทัศนคติที่ผิด แม้แต่โปรเซสเซอร์เองก็ยังเคยมีบั๊กอย่าง Meltdown ความปลอดภัยเป็นการต่อสู้ที่ไม่มีวันจบ และเราไม่มีวันรู้จริง ๆ ว่าชนะเมื่อไร จะรู้แค่บางครั้งตอนแพ้
    • โดยพื้นฐานแล้วนี่คือการเสนออะไรสักอย่างที่คล้าย สมการ Drake[1] สำหรับคำนวณจำนวนช่องโหว่ด้านความปลอดภัยจากจำนวนบรรทัดโค้ด แล้วในสมการนี้ควรมีปัจจัยอะไรเพิ่มอีกบ้าง?
      [1] https://en.wikipedia.org/wiki/Drake_equation
    • ประเด็นสำคัญคือความปลอดภัยเป็นสิ่งลวงตา ไม่มีแอปไหนปลอดภัยอย่างแท้จริง ต่อให้ทุ่มเงินหลายล้านดอลลาร์กับความปลอดภัยของแอป ก็ยังอาจถูกเจาะได้จากความผิดพลาดเพียงครั้งเดียวของผู้ใช้จริงคนหนึ่ง

  • ตอนแรกฉันก็เข้าใจชื่อเรื่องผิดเหมือนกัน คิดว่าเป็นประมาณ ค่าใช้จ่ายการประมวลผล GPU 10,000 ดอลลาร์ พอเห็นว่าแค่หยิบผลิตภัณฑ์ Google เก่า ๆ มาชิ้นหนึ่งก็เจอช่องโหว่ได้ทันที ก็ดูเหมือนว่ายังน่าจะมีบั๊กแบบนี้อีกหลายสิบหรือหลายร้อยจุด

    • มันไม่ได้ทำงานแบบ “หยิบผลิตภัณฑ์ Google เก่า ๆ มาชิ้นหนึ่งแล้วเจอรูรั่วทันที” หรอก ผู้เขียนน่าจะขุดหลายผลิตภัณฑ์อยู่หลายสัปดาห์หรือหลายเดือนก่อนจะเจอสิ่งที่มีมูลค่าจริง ๆ
    • ตอนแรกฉันก็เข้าใจผิดเหมือนกัน คิดว่าเป็นการขายอีเมลของ YouTuber ในราคา 10,000 ดอลลาร์