การโจมตีเดารหัสแบบ brute force หมายเลขโทรศัพท์ของผู้ใช้ Google คนใดก็ได้

 (brutecat.com)
1 คะแนน โดย GN⁺ 2025-06-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สามารถยืนยันได้ว่ามีหมายเลขโทรศัพท์ที่เชื่อมโยงกับชื่อผู้ใช้เป้าหมายหรือไม่ โดยอาศัยการหลบเลี่ยงฟอร์ม ค้นหาบัญชี Google
  • แม้ในสภาพแวดล้อมที่ ปิดการทำงานของ JavaScript ก็ยังสามารถแทรกโทเค็น BotGuard โดยเจตนา เพื่อสร้างรูปแบบการโจมตีที่หลบเลี่ยงข้อจำกัดตาม IP ได้
  • ในบางประเทศ เช่น เนเธอร์แลนด์ ด้วยลักษณะของรูปแบบหมายเลขโทรศัพท์ ทำให้มีจำนวนชุดค่าต่ำกว่า 1 ล้านชุด จึงสามารถทำ brute force ขนาดใหญ่ได้จริงผ่านการหมุนเวียน พร็อกซีและ IPv6
  • สามารถเปิดเผย ชื่อที่แสดงของบัญชี Google ได้ง่ายผ่าน Looker Studio โดยที่เหยื่อไม่ต้องทำอะไรเลย
  • ช่องโหว่นี้ ได้ถูกรายงานไปยัง Google และแพตช์แล้ว และสายโซ่การโจมตีจริงสามารถยืนยันหมายเลขโทรศัพท์ได้ภายในเวลาอันสั้นมากด้วยระบบอัตโนมัติ

ภาพรวม

บทความนี้เป็นกรณีศึกษาจริงที่อธิบายอย่างละเอียดถึงวิธีเดาหมายเลขโทรศัพท์ของบัญชี Google ด้วยการโจมตีแบบ brute force ขั้นตอนของมัน และการตอบสนองฝั่งป้องกัน โดยทั่วไปฟอร์มค้นหา/กู้คืนบัญชีจะอาศัยสภาพแวดล้อม JavaScript และระบบป้องกันบอตเพื่อปิดกั้นการนำไปใช้ในทางที่ผิด อย่างไรก็ตาม บทความนี้พิสูจน์ว่า เมื่อปิด JS และใช้รูปแบบบางอย่าง ก็สามารถหลบเลี่ยงระบบดังกล่าวได้

ที่มาของการตรวจสอบและวิธีการ

  • พบว่าฟอร์มของ Google สำหรับค้นหาชื่อผู้ใช้บัญชี ทำงานได้โดยไม่ต้องใช้ JavaScript
  • ฟอร์มสามารถตรวจสอบการมีอยู่ของ หมายเลขโทรศัพท์ที่เชื่อมโยงกับชื่อหนึ่ง ๆ (Display Name) ได้ผ่าน HTTP request 2 ครั้ง
    • คำขอครั้งที่ 1: รับค่า ess (session token) โดยอิงจากหมายเลขโทรศัพท์
    • คำขอครั้งที่ 2: ใช้ ess และพารามิเตอร์ชื่อ (GivenName/FamilyName) เพื่อตรวจสอบการมีอยู่ของบัญชี
  • หากมีบัญชีอยู่ จะตอบกลับด้วยการรีไดเรกต์ไปที่ usernamerecovery/challenge และหากไม่มีจะรีไดเรกต์ไปที่ noaccountsfound

การหลบเลี่ยงข้อจำกัดตาม IP (ใช้พร็อกซี, IPv6)

  • ในช่วงแรกยังไม่สามารถทำ brute force ได้ เพราะมี rate limit ตาม IP และ CAPTCHA
  • สำหรับหมายเลขมือถือในเนเธอร์แลนด์ มีชุดค่าประมาณ 1 ล้านชุด (เพราะเลขนำหน้าถูกกำหนดไว้แล้ว) จึงเป็นสิ่งที่ทำได้จริงเมื่อใช้พร็อกซี
  • สามารถใช้ บล็อก IPv6 แบบ /64 จากคลาวด์อย่าง AWS/Vultr เพื่อหมุนเวียนที่อยู่ใหม่ในทุกคำขอ และเซิร์ฟเวอร์ก็รองรับ IPv6

การหลบเลี่ยงโทเค็น BotGuard

  • ฟอร์มแบบ JS ต้องใช้ โทเค็น BotGuard
  • หากในฟอร์ม No-JS ใส่โทเค็นที่เก็บมาจากฟอร์ม JS แทนพารามิเตอร์ bgresponse=js_disabled ก็จะสามารถ ส่งคำขอได้แบบไม่จำกัด
  • มีการสร้างเครื่องมือแบบมัลติเธรด เพื่อป้อนหมายเลขโทรศัพท์จำนวนมากและตรวจจับ บัญชีที่มีอยู่จริง ได้อย่างรวดเร็ว

การกรองผลบวกลวง

  • ด้วยเงื่อนไขที่ใช้ชื่อเดียวกันและเลขท้ายหมายเลข 2 หลัก อาจมีหลายคนที่ตรงเงื่อนไขได้
  • จึงเพิ่มตรรกะสำหรับกรองผลบวกลวงโดยอัตโนมัติ ด้วยการใส่นามสกุลแบบสุ่มแล้วทดสอบซ้ำ

รูปแบบหมายเลขโทรศัพท์รายประเทศและการเก็บข้อมูลชื่อ

  • ฟอร์มกู้คืนให้ข้อมูลเพียงบางส่วนในรูปของ ฟอร์แมตการ mask หมายเลขโทรศัพท์
  • สามารถตรวจสอบแพตเทิร์นหมายเลขโทรศัพท์ของแต่ละประเทศ (national format) ได้จากข้อมูลของ libphonenumbers ของ Google
  • ชื่อที่แสดงของเหยื่อ สามารถตรวจสอบได้โดยไม่ต้องอาศัยการกระทำจากผู้ใช้ ผ่านการนำฟังก์ชันเปลี่ยนความเป็นเจ้าของใน Looker Studio ไปใช้ในทางที่ผิด

การเพิ่มประสิทธิภาพและระบบอัตโนมัติ

  • ใช้ libphonenumbers สร้างดิกชันนารีของกฎ Prefix/ความยาว/การตรวจสอบความถูกต้องในแต่ละประเทศ
  • สร้าง API สำหรับออกโทเค็น BotGuard แบบอัตโนมัติด้วย chromedp บน Go เพื่อให้ทำงานอัตโนมัติได้ในการโจมตีจริง

ขั้นตอนการโจมตีจริง

  1. ดึง ชื่อของเหยื่อ (Display Name) ผ่านการโอนความเป็นเจ้าของใน Looker Studio
  2. เก็บ ข้อมูลที่ mask ไว้บางส่วนของหมายเลขโทรศัพท์ ของอีเมลดังกล่าวจากขั้นตอน “ลืมรหัสผ่าน”
  3. ใช้ เครื่องมือ gpb เพื่อทำ brute force โดยอิงจากชื่อ ข้อมูลที่ mask และรหัสประเทศ

เวลาและประสิทธิภาพ

  • บนเซิร์ฟเวอร์ 16 vcpu, 3000 เธรด สามารถตรวจสอบได้ราว 40,000 ครั้งต่อวินาที
  • ขึ้นอยู่กับจำนวนชุดหมายเลขและความยาวของคำใบ้ในแต่ละประเทศ โดยสหรัฐฯ ใช้เวลา 20 นาที, สหราชอาณาจักร 4 นาที, เนเธอร์แลนด์ 15 วินาที, สิงคโปร์ 5 วินาทีก็เพียงพอ
  • หากบริการอื่นให้คำใบ้แบบเต็มเพิ่มเติม (เช่น PayPal) เวลาจะยิ่งสั้นลง

ไทม์ไลน์ของ Google และแพตช์

  • 2025.4.14: รายงานให้ Google, 4.25 ได้รับคำขอบคุณจากพาเนล
  • ช่วงกลาง 2025.5: ได้รับ bug bounty $5,000
  • 2025.5: เริ่มยุติการใช้งานฟอร์ม No-JS แบบค่อยเป็นค่อยไป และใช้มาตรการตอบสนอง
  • 2025.6.9: เปิดเผยช่องโหว่อย่างเป็นทางการ

บทสรุป

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

สามารถติดต่อได้ผ่าน Signal/อีเมล (อ้างอิงต้นฉบับ)

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

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

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

  • จุดที่น่าสนใจในบทความนี้คือ แม้ว่าผู้ให้บริการโฮสติ้งหรือ ISP ส่วนใหญ่จะให้บล็อก IPv6 อย่างน้อยหนึ่ง /64 แต่การจำกัดอัตราหรือการบล็อก IP ส่วนใหญ่ก็ยังคงใช้กับ IP เดี่ยวอยู่ดี ในสภาพแวดล้อม IPv6 ผมคิดว่าควรจำกัดอัตราหรือบล็อกโดยอิงทั้งบล็อก /64

    • แม้แต่บริษัทที่มีหน้าที่ต้องจัดการปัญหานี้หรือหาเงินจากมันก็ยังมักรับมือกับ IPv6 แบบผิดๆ อยู่บ่อยครั้ง บริษัทที่ผมทำงานอยู่ใช้บริการ CDN ชื่อดัง แต่บางครั้งแม้จะเชื่อมต่อจากภายในบล็อก /64 เดียวกัน ก็ยังได้รับการแจ้งเตือนความปลอดภัยเหลวไหลทำนองว่า "มีการเข้าสู่ระบบจาก IP แปลก"

    • ผมคิดว่าวิธีบล็อก IP แบบเดิมแทบใช้ไม่ได้ผลไปมากแล้วตั้งแต่มี IPv6 ผู้ใช้อินเทอร์เน็ตตามบ้านทั่วไปก็ยังสามารถรับบล็อก /56 หรือ /48 ได้อัตโนมัติผ่าน DHCPv6 Prefix Delegation ตัวอย่างเช่น ผมได้ /56 จาก Comcast ซึ่งสามารถแบ่งย่อยเป็นบล็อก /64 ได้มากสุด 65536 บล็อก ถ้าจะทำ IP filtering ให้มีประสิทธิภาพใน IPv6 การเอาแนวคิดแบบเดิมที่อิง IP เดี่ยวมาแทนด้วย /64 แบบตรงๆ ยังไม่เพียงพอ

    • ต่อให้จำกัดอัตราที่ระดับบล็อก /64 ก็อาจยังไม่พอ เพราะการได้บล็อก /48 นั้นง่ายเกินไป เพื่อการควบคุมที่เหมาะสมที่สุด จำเป็นต้องพิจารณาการจัดกลุ่มตาม ASN และดูต่อด้วยว่าแต่ละผู้ให้บริการกระจาย IP อย่างไร เพื่อปรับระดับความละเอียดให้เหมาะสม

    • การจำกัดอัตราแบบ /64 ใน IPv6 เป็นเรื่องที่รู้กันดีในอุตสาหกรรมอยู่แล้ว และ Google ก็ใช้กับบริการอื่นอยู่ด้วย ผมมองว่านี่คือผลจากการที่นโยบายเดิมไม่ได้รับการอัปเดตอย่างถูกต้องตอนนำ IPv6 มาใช้

    • ผู้ให้บริการโฮสติ้งราคาถูกอย่าง BuyVM ก็ยังให้ที่อยู่ระดับ /48 กับแพ็กเกจที่ถูกที่สุด ($2/เดือน ตอนนี้มีของเหลือแค่ $7/เดือน) เลยมีแนวโน้มว่าจะเป็นที่นิยมในหมู่โอเปอเรเตอร์น่าสงสัย

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

    • รูปโปรไฟล์ Google หรือแอป Google ก็มีช่องโหว่คล้ายกัน เช่น ถ้าในรีวิว Google Maps ขึ้นชื่อว่า John Smith ก็สามารถลองเพิ่มอีเมลหลายรูปแบบ เช่น johnsmith@gmail.com, smithjohn@gmail.com ฯลฯ เข้าไปใน Hangouts แล้วดูรูปโปรไฟล์เพื่อตามหาว่าเป็นคนเดียวกันหรือไม่

    • ด้วยเหตุนี้ผมจึงไม่เคยใส่เบอร์โทรจริงของตัวเองเลย เพราะมันไม่ได้จำเป็นต่อการให้บริการขนาดนั้นด้วย

  • น่าทึ่งตรงที่มีคนคนหนึ่งสามารถยิงคำขอ 40,000 รายการต่อวินาทีใส่เซิร์ฟเวอร์เป็นเวลานานได้ โดยที่ทรัพยากรไม่ได้พุ่งสูงหรือมีสัญญาณเตือนดังขึ้นอย่างมีนัยสำคัญ

    • เป็นไปได้ว่าอาจมีสัญญาณเตือนเกิดขึ้นจริง แต่พฤติกรรมหยุดลงเร็วหรือสถานการณ์ฟื้นตัวเร็วมาก จนตอนที่วิศวกรเปิดแดชบอร์ดทุกอย่างอาจกลับสู่ปกติแล้วก็ได้ 40,000 QPS อาจไม่ได้โดดเด่นมากนักในระดับทราฟฟิกของ Focus หรือ Google API และถ้ากระจายผ่าน IP หลายตัวกับบล็อก IPv6 /64 หลายบล็อก ก็อาจผ่านไปแบบไม่สะดุด ประเด็นหลักของกรณีนี้ไม่ใช่การมอนิเตอร์ แต่คือไม่มีการจำกัดอัตราเลยใน flow แบบปิด JS (โดยใช้โทเค็นที่ยืมมาจาก flow แบบเปิด JS ก่อนหน้า)

    • ผมก็แอบคิดว่าอาจใช้บอตเน็ตหรือเปล่า แต่ก็ดูเหมือนจะเปลี่ยน IP ทุกคำขอด้วย

  • บั๊กบาวน์ตีประเภทนี้มักให้รางวัลน้อยจนน่าเหลือเชื่อ น่าเสียดาย

    • ถ้ายังลดเงินรางวัลลงเรื่อยๆ สุดท้ายก็เหมือนทำร้ายตัวเอง

    • การจ่ายต่ำกว่า 100,000 ดอลลาร์สำหรับปัญหาความปลอดภัยแบบนี้มันน่าสมเพชจริงๆ

  • ผมมักรู้สึกว่าการคงไว้และดูแลเว็บเพจแบบเลกาซีเป็นภาระมหาศาล มีหลายเว็บไซต์ที่ต้องแบกโค้ดและหน้าเพจอายุหลายสิบปีไว้ต่อไป และการทดสอบทุกชุดผสมก็แทบเป็นไปไม่ได้จริงๆ ถ้าคุณขุดลึกเข้าไปในหน้า settings ของ Gmail ก็ยังเห็นป๊อปอัปเก่าสไตล์ปี 2004 โผล่มาได้อยู่เลย

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

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

    • ผมสงสัยมาตลอดว่าใครกันที่รับผิดชอบฟีเจอร์อย่าง “poke” ของ Facebook

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

    • ไม่นานมานี้ผมเองก็เพิ่งเจอหน้าของ Google ที่ยังใช้โลโก้ Catull แบบเก่า (~2013)

  • มีการพูดถึงข้อความว่า “2025-05-15 – คณะกรรมการจ่าย $1,337 + ของสมนาคุณ เหตุผล: ความเป็นไปได้ในการ exploit ต่ำ (lol)” แต่ผมคิดว่าความเป็นไปได้ในการนำไปใช้โจมตีจริงนั้นสูงมาก อาจมีเจ้าของหมายเลขโทรศัพท์ที่ถูกเปิดเผยจริงไม่มากนัก แต่ถ้ามีความต้องการ ผมมั่นใจว่านักสืบเอกชน อาชญากร ผู้สืบสวน และคนอื่นๆ ก็จะใช้ช่องโหว่นี้จริง

  • ครั้งนี้ทำให้ผมเพิ่งตระหนักว่า การให้ hint เป็นหมายเลขโทรศัพท์บางส่วนใน flow การกู้รหัสผ่านนั้นแท้จริงแล้วเป็นความเสี่ยงด้านความปลอดภัย ถ้าหลายบริการต่างให้ hint หมายเลขโทรศัพท์/อีเมลที่ถูกปิดบังไว้ในลำดับที่ต่างกัน ความเสี่ยงก็จะยิ่งเพิ่มขึ้น

    • ไม่รู้จะช่วยให้สบายใจขึ้นไหม แต่ด้วยเหตุผลอย่าง 2FA และอย่างอื่นอีกมากมาย มีบริการหลายร้อยหรือหลายพันแห่งเก็บเบอร์โทรของผมไปแล้ว และหลายแห่งก็รั่วไหลไปแล้วไม่ว่าผมจะยินยอมหรือไม่ก็ตาม ชุดข้อมูลชื่อจริง-อีเมล-เบอร์โทรแทบจะหลุดอยู่ในข้อมูลสาธารณะอย่างแน่นอน

    • ยังมีบอต Telegram ที่ช่วยค้นหาข้อมูลแบบนี้ด้วย ดูเหมือนว่าเมื่อช่องโหว่แบบ brute-force ลักษณะนี้ถูกเปิดเผย แม้แต่ผู้ใช้ที่เคยใช้เครื่องมืออัตโนมัติก็ยังรู้สึกไม่สบายใจเหมือนกัน (เช่นบอต EoG)

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

    • ในอดีตก็เคยมีกรณี social engineering ที่โทรไปถามฝ่ายบริการลูกค้าของบริษัทหนึ่งเพื่อขอเลข 4 หลักท้ายของบัตร แล้วเอาไปใช้ปลดการยืนยันตัวตนกับอีกบริษัทหนึ่ง

    • ผมเองก็จำได้ว่าเมื่อตอนเรียนมหาวิทยาลัยเคยฟังนักวิจัยด้านความปลอดภัยนำเสนอว่าแม้แต่ข้อมูลบัตรเครดิตก็สามารถได้มาด้วยวิธีแบบนี้

  • ในปี 2025, 2023 และ 2021 ก็ยังมีบทความแนว “ไม่มีทางป้องกันได้” และเหตุข้อมูลรั่วไหลครั้งใหญ่เกิดซ้ำอยู่เรื่อยๆ เวอร์ชันปี 2025, เวอร์ชันปี 2023, เวอร์ชันปี 2021 ถูกวนซ้ำอยู่ตลอด ผมยังคิดอยู่เลยว่าเวอร์ชันไหนขำกว่ากัน

  • ผมคิดว่ากรณีนี้สร้างสรรค์และเจ๋งมาก Brutecat ทำได้อีกแล้ว

  • ตอนนี้ Google ให้ความรู้สึกเหมือนเรือผีจริงๆ เงินบั๊กบาวน์ตี $5,000 ถือว่าเป็นการดูถูก และการเริ่มต้นด้วยจำนวนเงินแค่นี้ก็ดูเป็นหลักฐานชัดเจนว่า Google ไม่ได้จริงจังกับการปกป้องข้อมูลผู้ใช้

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