เด็กชายวัย 15 ปีพบแบ็กดอร์บั๊ก 1 จุดใน Zendesk และทำเงินได้ 50,000 ดอลลาร์

 (gist.github.com/hackermondev)
13 คะแนน โดย GN⁺ 2024-10-13 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เด็กชายวัย 15 ปีที่ชอบล่าบั๊กในเวลาว่าง พบช่องโหว่เกี่ยวกับการยืนยันอีเมลใน Zendesk ซึ่งเป็นบริการที่บริษัทระดับ Fortune 500 ใช้งาน
  • เขานำเรื่องนี้ไปแจ้งหลายบริษัทและได้เงินรางวัลรวมมากกว่า 50,000 ดอลลาร์ แต่ Zendesk แม้จะแพตช์ปัญหาแล้วก็ไม่ได้จ่ายค่าตอบแทนใด ๆ ให้ผู้รายงาน โดยบทความนี้เล่ากระบวนการทั้งหมด

แนะนำ Zendesk

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

โซ่ที่อ่อนแอที่สุด

  • ดังคำกล่าวที่ว่า “ระบบจะแข็งแรงได้เท่ากับจุดที่อ่อนแอที่สุด” Zendesk มักถูกมองว่าเป็นเพียงเครื่องมือทิกเก็ตง่าย ๆ จึงถูกใช้งานโดยไม่ตั้งค่าอย่างรอบคอบ
  • หากใช้โดเมน @company.com กับระบบ single sign-on (SSO) และเชื่อมเข้ากับ Zendesk อาจก่อให้เกิดช่องโหว่ด้านความปลอดภัย
  • เพราะ Zendesk เป็นผู้ประมวลผลอีเมลของโดเมน หากระบบ SSO ตรวจสอบที่อยู่อีเมลไม่ถูกต้อง ผู้ที่เข้าถึง Zendesk ได้อาจนำไปใช้โจมตีระบบภายในได้

การปลอมแปลงอีเมล

  • พบช่องโหว่ร้ายแรงใน Zendesk ซึ่งทำให้ผู้โจมตีสามารถอ่านทิกเก็ตซัพพอร์ตของบริษัทที่ใช้ Zendesk ได้
  • Zendesk ไม่มีมาตรการป้องกันการปลอมแปลงอีเมลที่มีประสิทธิภาพ
  • หากผู้โจมตีรู้ที่อยู่อีเมลซัพพอร์ตและหมายเลขทิกเก็ต ก็สามารถใช้การปลอมแปลงอีเมลเพื่อสวมรอยเป็นผู้ส่งเดิมและเข้าถึงทิกเก็ตได้
  • ผู้เขียนรายงานบั๊กนี้ แต่ในช่วงแรก Zendesk ไม่ได้ให้ความสนใจ
    • มีการตอบกลับมาว่าปัญหาการปลอมแปลงอีเมล (ประเด็น SPF, DKIM, DMARC) อยู่นอกขอบเขตการรับรายงาน
  • รายงานถูกดำเนินการผ่านบริการ HackerOne และเมื่อขอให้รายงานตรงกับทีม Zendesk ก็ถูกปฏิเสธ

ขยายประเด็นนี้ไปสู่การยึดครอง Slack

  • ผู้เขียนอาจเลือกรายงานบั๊กปลอมแปลงอีเมลให้แต่ละบริษัทเป็นราย ๆ ได้ แต่ต้องการสร้างผลกระทบในวงกว้างมากกว่า
  • ก่อนหน้านี้มีนักวิจัยอีกคนเคยเจาะ Slack ของบริษัทหลายร้อยแห่งผ่าน Zendesk มาแล้ว (TICKETTRICK)
  • ผู้เขียนพยายามทำซ้ำด้วยบั๊กของตนเอง แต่เจออุปสรรคบางอย่าง
  • Slack เปลี่ยนไปใช้วิธีตรวจสอบด้วยการเพิ่มโทเคนแบบสุ่มลงในที่อยู่อีเมล
  • อย่างไรก็ตาม เมื่อใช้ OAuth เพื่อล็อกอินด้วย Apple ID ระบบจะไม่ใช้โทเคนนี้ จึงสามารถหลบเลี่ยงได้

ขั้นตอนการทำซ้ำ: Apple → Zendesk → Slack

  1. สร้าง Apple ID ด้วย support@company.com แล้วขอรหัสยืนยัน จะมีการสร้างทิกเก็ตใน Zendesk
  2. สร้างทิกเก็ตด้วยอีเมลของตนเองในพอร์ทัลซัพพอร์ตของ company.com เพื่อติดตามช่วงของหมายเลข ID
  3. ใช้บั๊กปลอมแปลงอีเมลเพื่อพยายามเพิ่มตัวเองเข้าไปในทุกทิกเก็ตภายในช่วง ID นั้น
  4. ล็อกอินเข้าสู่พอร์ทัลซัพพอร์ตของบริษัทนั้นด้วยบัญชี daniel@wearehackerone.com และตรวจดูทิกเก็ตที่ถูก CC มา
  5. กรอกรหัสยืนยันลงใน Apple ID
  6. ใช้ฟังก์ชัน “Sign in with Apple” ของ Slack เพื่อล็อกอินด้วย Apple ID ที่ผูกกับอีเมล @company.com แล้ว ล็อกอินเข้า Slack ได้สำเร็จ
    ผู้เขียนนำ 6 ขั้นตอนนี้ไปใช้กับ Zendesk และ Slack หลายร้อยอินสแตนซ์

ผลกระทบหลังเหตุการณ์

  • ตลอดหนึ่งสัปดาห์ ผู้เขียนแจ้งช่องโหว่ให้บริษัทต่าง ๆ เป็นรายแห่ง บางแห่งแก้ไขทันที แต่บางแห่งยืนยันว่าเป็นปัญหาของ Zendesk
  • เมื่อมีบางบริษัทติดต่อ Zendesk ในที่สุด Zendesk ก็ขอให้เก็บรายงานนี้เป็นความลับ และขอขั้นตอนการทำซ้ำสำหรับช่องโหว่ที่ยึดครอง Slack ได้
  • หลังได้รับ PoC การยึดครอง Slack แล้ว Zendesk ยืนยันปัญหา แต่ใช้เวลาอีก 2 เดือนกว่าจะจัดการเสร็จ
  • หลายบริษัทปิดฟีเจอร์การทำงานร่วมกันผ่านอีเมลเพื่อป้องกันอินสแตนซ์ของตน
  • ผู้เขียนได้รับเงินรางวัลจากการแจ้งบั๊กนี้มากกว่า 50,000 ดอลลาร์ จากบริษัทแต่ละแห่งผ่าน HackerOne และแพลตฟอร์มอื่น ๆ
  • บางบริษัทถึงกับยกเลิกสัญญากับ Zendesk

การแก้ไขของ Zendesk และค่าบั๊กบาวน์ตี 0 ดอลลาร์ของฉัน

  • หลังจาก 2 เดือน Zendesk ยืนยันว่าได้แก้ปัญหาแล้ว
  • Zendesk ใช้ตัวกรองสแปม Cloudmark และ Rspamd EAP แต่ไม่ได้ใช้คะแนนจาก Rspamd ทำให้อีเมลจำนวนมากไม่ถูกกักไว้
  • ตอนแรกแก้โดยสลับไปใช้ Rspamd อัตโนมัติภายใต้เงื่อนไขบางอย่าง
  • ต่อมาจึงเพิ่มตัวกรองเพื่อกักอีเมลยืนยันตัวตนจาก Apple และ Google โดยอัตโนมัติ
  • แม้จะแก้ปัญหาแล้ว สุดท้าย Zendesk ก็ตัดสินใจไม่จ่ายเงินรางวัลสำหรับการรายงานบั๊กครั้งนี้
    • เพราะผู้เขียนนำช่องโหว่ไปแบ่งปันกับบริษัทที่ได้รับผลกระทบ ซึ่งถือว่าละเมิดแนวทางการเปิดเผยข้อมูลของ HackerOne

บทสรุป

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

ความเห็นจาก GN⁺

  • กรณีของ Zendesk แสดงให้เห็นถึงความเสี่ยงของการนำโซลูชันจากบุคคลที่สามมาใช้โดยไม่พิจารณาอย่างวิพากษ์ ไม่ว่าผลิตภัณฑ์จะมาจากบริษัทที่มีชื่อเสียงเพียงใด การตรวจสอบด้านความปลอดภัยก็ยังจำเป็น
  • การยึดครองระบบภายในของบริษัทใหญ่สามารถสร้างความเสียหายมหาศาลได้ ดังนั้นการตอบสนองล่าช้าของ Zendesk จึงขาดความรับผิดชอบอย่างมาก และการปฏิเสธจ่ายบาวน์ตีก็ไม่เป็นผลดีต่อแรงจูงใจของนักวิจัยด้านความปลอดภัย
  • บริษัทควรเลือกโดเมน SSO อย่างรอบคอบ และเสริมความเข้มแข็งให้กระบวนการยืนยันอีเมล ควรใช้เทคโนโลยียืนยันอีเมลอย่าง DMARC, SPF, DKIM ให้มากขึ้น
  • แนวทางการเปิดเผยข้อมูลของ HackerOne นั้นเข้มงวดเกินไปจากมุมมองของนักวิจัย ช่องโหว่ร้ายแรงควรถูกแชร์อย่างรวดเร็ว จึงควรมีการประยุกต์ใช้อย่างยืดหยุ่นตามสถานการณ์
  • การล่าบั๊กควรเป็น win-win ทั้งสำหรับบริษัทและนักวิจัย หวังว่าจะเกิดวัฒนธรรมที่เคารพเจตนาดีและความพยายามของนักวิจัย พร้อมตอบแทนอย่างเหมาะสม

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

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

 
aer0700 2024-10-13

พอเห็นประเด็นแบบนี้แล้ว ดูเหมือนว่าพวกโซลูชันด้านความปลอดภัย ถ้าจะเอามาใช้งานเลย สู้ดึงผู้เชี่ยวชาญด้านความปลอดภัยเข้ามาและปั้นทีมเองน่าจะดีกว่ามากเลยครับ ฮือๆ
 
GN⁺ 2024-10-13
ความเห็นจาก Hacker News

  • ผู้ใช้รายหนึ่งกล่าวว่าเขาได้รายงานบั๊กเดียวกันนี้กับ Zendesk, Apple และ Slack ไปเมื่อเดือนมิถุนายน 2024 และเหตุผลที่พวกเขาไม่จ่ายค่ารางวัลบั๊กก็น่าจะเป็นเพราะเขาไม่ใช่คนแรกที่พบ

    • ตัวเลือก SSO แบบไม่ใช้ directory อย่าง Sign in with Apple (SIWA) ถูกนำไปใช้งานอย่างผิดพลาด และแม้แต่บริษัทใหญ่ ๆ อย่าง Slack ก็เป็นแบบเดียวกัน
    • SSO แบบไม่ใช้ directory ไม่อาจได้รับความไว้วางใจในระดับเดียวกับ directory SSO และผู้ให้บริการ SSO ก็ไม่สามารถใช้แทนกันได้แม้จะใช้อีเมลเดียวกันก็ตาม

  • ผู้ใช้อีกรายอ้างว่า Zendesk สร้างวงดนตรีปลอมชื่อ "Zendesk Alternative" เพื่อปนเปื้อนผลการค้นหาบน Google

    • เขาระบุว่านี่อาจไม่ผิดกฎหมาย แต่เป็นพฤติกรรมเชิงชักจูงที่สะท้อนวิธีคิดของพวกเขา

  • ผู้ใช้คนหนึ่งบอกว่ารู้สึกผิดหวังที่ Zendesk ปฏิเสธการจ่ายรางวัลสำหรับบั๊กนี้ และบอกว่านี่คือวิธีที่ทำให้คนไม่อยากเข้าร่วมโปรแกรมรางวัลขนาดใหญ่

    • พร้อมเสริมว่าประสบการณ์สัมภาษณ์งานกับ Zendesk แย่มาก

  • ผู้ใช้อีกรายกล่าวว่าโปรแกรม bug bounty ที่ไม่มีประสิทธิภาพส่งผลเสียต่อบริการซอฟต์แวร์

    • เขายืนยันว่า Zendesk ควรจ่ายรางวัล ขอโทษ และปรับปรุงโปรแกรมเสียใหม่

  • ผู้ใช้คนหนึ่งวิจารณ์ว่า Zendesk มีรายได้ถึง 1.3 พันล้านดอลลาร์ แต่กลับไม่ยอมจ่ายรางวัล ซึ่งเป็นมุมมองระยะสั้น

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

  • ผู้ใช้อีกรายอธิบายว่า Zendesk อาจเพิกเฉยเพราะไม่เข้าใจผลกระทบของบั๊กนี้อย่างถูกต้อง

    • เขาระบุว่าหากไม่เห็นผลกระทบอย่างชัดเจน ช่องโหว่จำนวนมากก็อาจดูเป็นแค่บั๊กธรรมดา

  • ผู้ใช้คนหนึ่งชี้ว่า Zendesk แก้แค่ปัญหาอีเมลยืนยันบัญชี Apple แต่ไม่ได้แก้ปัญหาที่ต้นเหตุ

    • เขาระบุว่าด้วยค่าตั้งต้น หากรู้เพียงอีเมลกับ ticket ID ก็อาจเป็นไปได้ที่ใครก็ตามจะยึด ticket support ของผู้อื่นได้

  • มีการอธิบายว่ามีช่องโหว่แยกกันอยู่สองจุด

    • เดิมที Zendesk อนุญาตให้ส่งคำตอบกลับจากอีเมลของผู้ร้องขอเดิมพร้อมเพิ่ม CC ได้
    • ส่วน Slack อนุญาตให้ล็อกอินทั้งโดเมนผ่าน Sign in with Apple ได้โดยไม่มีการยืนยันเพิ่มเติม

  • มีการวิจารณ์ว่า Zendesk เพิกเฉยต่อปัญหาและพยายามเก็บเรื่องนี้ไว้เป็นการภายใน

    • โดยระบุว่านี่เป็นท่าทีที่ไม่เป็นมืออาชีพ และอาจเป็นเหตุผลที่พวกเขาไม่ยอมจ่ายรางวัล

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