ข้อมูลผู้ใช้ของ Uber, Fitbit, Ok Cupid, 1Password และบริษัทชั้นนำมีความเสี่ยงร่วมกันเป็นเวลาหลายสัปดาห์เนื่องจากช่องโหว่ CloudFlare ที่สำคัญ 'Cloudbleed Bug' เกิดขึ้นเนื่องจากเซิร์ฟเวอร์ทำงานผ่านบัฟเฟอร์และส่งคืนหน่วยความจำที่มีข้อมูลส่วนตัว พบสิ่งที่คล้ายกันในข้อผิดพลาด heartbleed ที่รายงานในปี 2014 เช่นกัน ช่องโหว่นี้รายงานโดย Tavis Ormandy นักวิจัยด้านความปลอดภัยของ Google Graham-Cumming, CTO ของ CloudFlare กล่าวว่าหากยากที่จะชี้ให้เห็นว่าเว็บไซต์ 6 ล้านแห่งใดได้รับผลกระทบ ผู้เชี่ยวชาญด้านความปลอดภัยจำนวนหนึ่งเชื่อว่า Cloudbleed มีผลกระทบมากกว่าที่ CloudFlare กำลังอ้างสิทธิ์
ผลที่ตามมาของช่องโหว่ Cloudflare
บริการต่างๆ ของ CloudFlare อาศัยการแยกวิเคราะห์ HTML และแก้ไขได้ทันที Cloudflare ใช้ parser ที่เขียนด้วย ragel และปีที่แล้วตัดสินใจเขียน parser ของตัวเอง ทั้ง ragel และ parser ใหม่ที่ปรับใช้เป็นโมดูล nginx ในขณะที่บั๊กที่ก่อให้เกิดช่องโหว่มีอยู่ใน ragel parser เสมอ เมื่อมีการแนะนำ parser ใหม่ วิธีที่ parsers โต้ตอบกับเซิร์ฟเวอร์เปลี่ยนไป สิ่งนี้ทำให้เกิดหน่วยความจำล้นและด้วยเหตุนี้ช่องโหว่จึงปรากฏขึ้น การวิเคราะห์เชิงลึกของสาเหตุสามารถพบได้ที่นี่ ผลที่ตามมาโดยตรงของ Cloudbleed คือ:
- เสิร์ชเอ็นจิ้นแคชข้อมูลรั่วไหลจำนวนมากและแสดงข้อมูลดังกล่าวในผลการค้นหา
- การรั่วไหลของแชทส่วนตัวบนเว็บไซต์โซเชียล/การออกเดท
- ข้อมูลประจำตัวผู้ใช้รั่วไหล
- ข้อมูลคุกกี้/IP
ขั้นตอนข้อควรระวังในทันที
- เปลี่ยนรหัสผ่านของคุณ จาก FTP, cpanel, admin panel หรืออื่นๆ ทั้งหมด
- บังคับเปลี่ยนรหัสผ่านให้กับผู้ใช้ของคุณ
- หากเป็นไปได้ ให้ใช้การตรวจสอบสิทธิ์แบบสองปัจจัย
- ล้างแคชเว็บไซต์ของคุณ ล้างแคชเก่า
คำถามที่เกิดขึ้น
คุณทรอย ฮันต์ ผู้เผยแพร่ศาสนาด้านความปลอดภัยทางไซเบอร์กล่าวในบล็อกของเขาว่า:
นับตั้งแต่พบช่องโหว่นี้ จุดยืนของ CloudFlare ก็มั่นคงและตรงไปตรงมามาก ทั้ง CEO และ CTO ของ CloudFlare ได้แถลงต่อสาธารณะและรับผิดชอบสถานการณ์ดังกล่าว อย่างไรก็ตาม เหตุการณ์ทั้งหมดนี้ทำให้เกิดคำถามเกี่ยวกับโซลูชันพร็อกซีย้อนกลับโดยคาดหวังให้คุณกำหนดเส้นทางการเข้าชมเว็บของคุณผ่านพวกเขา ผลที่ตามมาที่ใหญ่ที่สุดของการแก้ปัญหาดังกล่าวคือ หากเซิร์ฟเวอร์ถูกแฮ็ก เว็บไซต์ทั้งหมดก็จะล่ม เท่าที่เห็นใน CloudFlare มีเว็บไซต์นับล้านที่มีความเสี่ยงเพียงหนึ่งจุดบกพร่อง
เราโต้ตอบกับ Rafay Baloch นักวิจัยและนักเขียนด้านความปลอดภัยที่มีชื่อเสียงเพื่อรับฟังความคิดเห็นของเขาในเรื่องนี้ นี่คือสิ่งที่ Rafay ได้กล่าวไว้:
จุดที่น่าสนใจมากโดย Rafay แน่นอน บริษัทรักษาความปลอดภัยไม่ควรเพิกเฉยต่อพลังของนักวิจัยด้านความปลอดภัยและความสามารถในการหลีกเลี่ยง WAF ที่ดีที่สุดในโลก ในไม่ช้า เราจะเขียนเพิ่มเติมเกี่ยวกับวิธีที่โซลูชันการรักษาความปลอดภัยที่สมบูรณ์ควรมีองค์ประกอบ "การเปิดเผยอย่างมีความรับผิดชอบ"
ขณะสร้าง Astra เหตุผลหลักประการหนึ่งที่เราไม่ได้ใช้งาน reverse proxy คือการหลีกเลี่ยงสถานการณ์เช่นนี้ที่ผู้ใช้ทั้งหมดของเราตกอยู่ในความเสี่ยงเนื่องจากช่องโหว่เดียวในโครงสร้างพื้นฐานของเรา
