Cloudflare ได้นำการเข้ารหัสแบบ End-to-End (E2EE) มาใช้กับแอปประชุมผ่านวิดีโอ Orange Meets และเปิดโอเพ่นซอร์สโซลูชันนี้เพื่อความโปร่งใส

แอปพลิเคชันนี้เปิดให้ใช้งานมาตั้งแต่ปีที่แล้ว โดยเปิดตัวในฐานะ demo สำหรับ Cloudflare Calls (ปัจจุบันคือ Realtime)

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

การออกแบบการเข้ารหัสแบบ E2EE

Orange Meets นำการเข้ารหัสแบบ End-to-End มาใช้งานโดยใช้ Messaging Layer Security (MLS) ซึ่งเป็นโปรโตคอลแลกเปลี่ยน group key ที่ได้รับมาตรฐาน IETF

การใช้งาน MLS บน Orange Meets พัฒนาโดยใช้ภาษา Rust ทำให้สามารถดำเนินการแลกเปลี่ยน group key ได้อย่างต่อเนื่อง ซึ่งรองรับการแลกเปลี่ยน group key อย่างปลอดภัย, การรักษาความลับในการ forward secrecy, ความปลอดภัยหลังถูกโจมตี และการรองรับการขยายตัวของกลุ่มผู้ใช้

การเข้ารหัสทั้งหมดดำเนินการบนฝั่งไคลเอนต์โดยใช้ WebRTC ดังนั้น Cloudflare หรือ Selective Forwarding Unit (SFU) จึงทำหน้าที่เป็นตัวกลางในการส่งต่อที่ไม่มีสิทธิ์เข้าถึงข้อมูลการสื่อสารที่มีความสำคัญ

Cloudflare ยังได้แนะนำ "Designated Committer Algorithm" ซึ่งเป็นอัลกอริทึมที่ช่วยจัดการการเปลี่ยนแปลงสมาชิกในกลุ่ม (ผู้ใช้เข้าร่วม/ออกจากการสนทนาวิดีโอคอล) อย่างปลอดภัย

ระบบนี้จะทำหน้าที่กำหนดสมาชิกคนหนึ่งในกลุ่ม ให้เป็นผู้ที่รับผิดชอบในการจัดการอัปเดต MLS ในฝั่งไคลเอนต์ทั้งหมด โดยจะเลือกผู้กำหนดใหม่โดยอัตโนมัติตามสถานะของกลุ่ม

สุดท้ายแล้ว ในแต่ละเซสชันวิดีโอคอลจะมีการแสดง "หมายเลขความปลอดภัย" ซึ่งแสดงถึงสถานะการเข้ารหัสของกลุ่ม ซึ่งผู้เข้าร่วมควรตรวจสอบภายนอกแพลตฟอร์ม

ซึ่งจะป้องกันการโจมตีแบบ "Monster-in-the-Middle" (MitM) ซึ่งเซิร์ฟเวอร์ที่เป็นอันตรายจะเข้ามาแทนที่ข้อมูลสำคัญ

Cloudflare ได้สร้างแบบจำลอง Designated Committer Algorithm อย่างเป็นทางการใน TLA+ ซึ่งเป็นภาษาเฉพาะที่ใช้สำหรับการตรวจสอบทางคณิตศาสตร์ว่าโปรโตคอลทำงานได้อย่างถูกต้องภายใต้เงื่อนไขที่เป็นไปได้ทั้งหมดหรือไม่ จึงสามารถตรวจจับข้อผิดพลาดได้ในระดับที่ละเอียดอ่อน

จากที่กล่าวมาทั้งหมดนี้ สิ่งสำคัญที่ต้องเน้นย้ำคือ Orange Meets เป็นเพียงตัวอย่างเชิงเทคนิค และต้นแบบแบบ open-source มากกว่าจะเป็นผลิตภัณฑ์สำหรับผู้บริโภคที่พัฒนาอย่างสมบูรณ์แบบ

Orange Meets ยังไม่ใช่แอปที่มีคุณสมบัติครบครัน หรือใช้งานง่ายเทียบเท่ากับ Zoom, Google Meet, Signal หรือ Microsoft Teams และยังไม่ได้ผ่านการตรวจสอบการใช้งานจริงอย่างละเอียดถี่ถ้วน

เครื่องมือของ Cloudflare มุ่งเน้นไปที่นักพัฒนาที่สนใจการรวม MLS และการเข้ารหัส รวมถึงผู้ที่ชื่นชอบความเป็นส่วนตัว ผู้ใช้งานที่อยากทดลองใช้ระบบวิดีโอคอลแบบเข้ารหัสจากต้นทางถึงปลายทาง (E2EE) ที่เป็น open-source เครื่องมือนี้ยังเหมาะสำหรับนักวิจัย หรือวิศวกรที่กำลังประเมินการใช้งาน MLS

Orange Meets ไม่จำเป็นต้องติดตั้งเพื่อทดสอบ หรือใช้งาน เพราะมีการสาธิตแบบ live demo ให้ใช้งานออนไลน์

อีกทางเลือกหนึ่งคือ ผู้ใช้สามารถตั้งค่าระบบใช้งานเองได้โดยใช้โค้ดต้นฉบับที่มีอยู่ใน GitHub repository

ที่มา : bleepingcomputer

Cloudflare เปิดเผยว่าได้ป้องกันการโจมตีแบบ DDoS ที่สร้างสถิติใหม่ในเดือนพฤษภาคม 2025 ด้วยปริมาณที่พุ่งสูงถึง 7.3 Tbps โดยมุ่งเป้าไปยังผู้ให้บริการ Hosting

การโจมตีแบบ DDoS คือการส่ง traffic จำนวนมหาศาลไปยังเป้าหมาย โดยมีจุดประสงค์เดียวคือทำให้เซิร์ฟเวอร์ทำงานอย่างหนัก และทำให้เกิดความล่าช้าในการให้บริการ จนถึงขั้นระบบหยุดชะงัก หรืออาจทำให้ระบบขัดข้องไปเลย

การโจมตีครั้งใหม่นี้มีขนาดใหญ่กว่าสถิติเดิมถึง 12% โดยมีการส่งข้อมูลมหาศาลถึง 37.4 TB ภายในเวลาเพียง 45 วินาที ถ้าเทียบเท่ากับการสตรีมมิ่งวิดีโอความละเอียดสูงระดับ HD ก็จะประมาณ 7,500 ชั่วโมง หรือถ้าเป็นรูปภาพ JPEG ก็จะประมาณ 12,500,000 รูป

Cloudflare เป็นบริษัทยักษ์ใหญ่ด้านโครงสร้างพื้นฐานเว็บไซต์ และความปลอดภัยทางไซเบอร์ที่เชี่ยวชาญด้านการป้องกันการโจมตีแบบ DDoS โดยให้บริการป้องกันในระดับเครือข่ายที่เรียกว่า 'Magic Transit' แก่ลูกค้าที่ตกเป็นเป้าหมายของการโจมตีในครั้งนี้

การโจมตีครั้งนี้มาจาก IP Address ต้นทางจำนวน 122,145 แห่ง ที่กระจายอยู่ใน 161 ประเทศ โดยส่วนใหญ่มาจากบราซิล, เวียดนาม, ไต้หวัน, จีน, อินโดนีเซีย และยูเครน

แพ็กเกจข้อมูลขยะ ถูกส่งไปยังพอร์ตปลายทางหลายพอร์ตบนระบบของเหยื่อ โดยเฉลี่ยอยู่ที่ 21,925 พอร์ตต่อวินาที และสูงสุดถึง 34,517 พอร์ตต่อวินาที

กลยุทธ์ในการกระจาย traffic ในลักษณะนี้ มีเป้าหมายเพื่อทำให้ firewall หรือระบบตรวจจับการบุกรุก (IDS) ทำงานหนักจนถึงขั้นขัดข้องในที่สุด อย่างไรก็ตาม Cloudflare ระบุว่า สามารถป้องกันการโจมตีได้สำเร็จโดยไม่ต้องอาศัยการแทรกแซงใด ๆ จากมนุษย์

เครือข่าย anycast ของ Cloudflare ได้ช่วยกระจาย traffic จากการโจมตีไปยังศูนย์ข้อมูล 477 แห่ง ใน 293 แห่งทั่วโลก โดยอาศัยเทคโนโลยีหลักต่าง ๆ เช่น การตรวจสอบ fingerprint แบบเรียลไทม์ (real-time fingerprinting) และการแลกเปลี่ยนข้อมูลภายในศูนย์ข้อมูล (intra-data center gossiping) เพื่อแบ่งปันข้อมูลภัยคุกคามแบบ real-time และสร้าง Rules เพื่อป้องกันโดยอัตโนมัติ

แม้ว่าปริมาณการโจมตีเกือบทั้งหมดจะมาจากเทคนิค UDP floods ซึ่งคิดเป็น 99.996% ของ traffic ทั้งหมด แต่ก็มีการโจมตีในรูปแบบอื่น ๆ อีกหลายรูปแบบเข้ามาเกี่ยวข้องด้วย ได้แก่ :

QOTD reflection – การโจมตีแบบ reflection โดยใช้โปรโตคอล QOTD (Quote of the Day)
Echo reflection – การโจมตีแบบ reflection โดยใช้โปรโตคอล Echo เพื่อสร้าง traffic จำนวนมาก
NTP amplification – การโจมตีแบบ amplification โดยใช้โปรโตคอล NTP (Network Time Protocol) เพื่อเพิ่มปริมาณข้อมูล
Mirai botnet UDP flood – การโจมตีแบบ UDP flood โดยใช้ Mirai botnet
Portmap flood – การโจมตีแบบ Portmap flood โดยส่งข้อมูลจำนวนมากผ่านพอร์ตที่ใช้บริการ Portmap เพื่อทำให้ระบบล่ม
RIPv1 amplification – การโจมตีแบบ amplification โดยใช้โปรโตคอล RIPv1 (Routing Information Protocol version 1) เพื่อสร้างปริมาณ traffic ที่มากผิดปกติ

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

Cloudflare ระบุว่า Indicators of Compromise (IoCs) ที่ได้จากการโจมตีในครั้งนี้ได้ถูกนำมาใส่ในบริการ DDoS Botnet Threat Feed ของบริษัทแล้ว ซึ่งเป็นบริการฟรีที่ช่วยให้องค์กรต่าง ๆ สามารถบล็อก IP Address ที่เป็นอันตรายได้ล่วงหน้า

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

 

ที่มา : bleepingcomputer.

Cloudflare ออกมายืนยันว่าเหตุการณ์ระบบล่มครั้งใหญ่เมื่อวันที่ 12 มิถุนายน 2025 ไม่ได้เกิดจากเหตุการณ์ด้านความปลอดภัย และไม่มีข้อมูลสูญหาย

ปัญหานี้ได้รับการแก้ไขในระดับหนึ่งแล้ว โดยเหตุการณ์เริ่มต้นเมื่อเวลา 17:52 UTC ของวันที่ 12 มิถุนายน 2025 เมื่อระบบ Workers KV (Key-Value) หยุดทำงาน ส่งผลให้บริการจำนวนมากที่เกี่ยวข้องกับ Edge Computing และ AI Services ทั่วโลกไม่สามารถใช้งานได้

โดย Workers KV เป็นระบบฐานข้อมูลแบบ Key-Value ที่กระจายตัวไปทั่วโลก และมีการทำงานแบบ Consistent ซึ่งถูกใช้งานโดย Cloudflare Workers ซึ่งเป็นแพลตฟอร์มการประมวลผลแบบ Serverless ของ Cloudflare โดย Workers KV เป็นระบบหลักของบริการหลายส่วนใน Cloudflare และหากเกิดการหยุดทำงานจะส่งผลกระทบไปยังหลายระบบที่เกี่ยวข้อง

เหตุขัดข้องครั้งนี้ดังกล่าวยังส่งผลกระทบต่อบริการอื่น ๆ ที่ใช้งานโดยผู้ใช้งานนับล้าน โดยเฉพาะอย่างยิ่งใน Google Cloud Platform

ในรายงานสรุปเหตุการณ์ ทาง Cloudflare อธิบายว่า เหตุการณ์ระบบล่มครั้งนี้กินเวลานานเกือบ 2.5 ชั่วโมง และสาเหตุหลักเกิดจาก การหยุดทำงานในโครงสร้างพื้นฐานของระบบจัดเก็บข้อมูลของ Workers KV ซึ่งเป็นผลมาจาก เหตุขัดข้องของผู้ให้บริการคลาวด์ภายนอก (Third-party Cloud Provider)

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

โครงสร้างพื้นฐานบางส่วนนี้ทำงานบนระบบคลาวด์ของผู้ให้บริการภายนอก ซึ่งเกิดเหตุระบบล่ม และส่งผลกระทบโดยตรงต่อความพร้อมใช้งานของ KV service

Cloudflare ได้พิจารณาผลกระทบของเหตุการณ์ที่เกิดขึ้นต่อแต่ละบริการ

Workers KV เกิดการหยุดทำงานถึง 90.22% เนื่องจากไม่สามารถเข้าถึงที่เก็บข้อมูลในเบื้องหลังได้ ส่งผลกระทบต่อการอ่าน และเขียนข้อมูลที่ไม่ถูกแคชทั้งหมด
Access, WARP, Gateway ประสบปัญหาการหยุดทำงานในการยืนยันตัวตน, การจัดการเซสชัน และการบังคับใช้นโยบาย เนื่องจากต้องทำงานร่วมกับ Workers KV ทำให้ WARP ไม่สามารถลงทะเบียนอุปกรณ์ใหม่ได้ และเกิดความขัดข้องในการทำงานของ Gateway ทั้งการทำ Proxy และการทำ DoH query
Dashboard, Turnstile, Challenges เกิดความล้มเหลวในการเข้าสู่ระบบ และการตรวจสอบ CAPTCHA โดยมีความเสี่ยงของการใช้ token reuse เนื่องจากมีการเปิดใช้ kill switch บน Turnstile
Browser Isolation & Browser Rendering ไม่สามารถ initiate หรือ maintain เซสชันที่ใช้ link-based และการแสดงผลเบราว์เซอร์ได้ เนื่องจากการหยุดทำงานในส่วนของ Access และ Gateway
Stream, Images, Pages เกิดการหยุดทำงานในส่วนของ Stream playback, live streaming, การอัปโหลดภาพสำเร็จ 0%, และการสร้าง/ให้บริการ Pages มีอัตราความล้มเหลวสูงถึงประมาณเกือบ 100%
Workers AI & AutoRAG ไม่สามารถใช้งานได้ เนื่องจากต้องอาศัย KV ในการกำหนดค่าโมเดล การกำหนดเส้นทาง และฟังก์ชันการจัดทำ indexing
Durable Objects, D1, Queues บริการที่สร้างขึ้นบนเลเยอร์การจัดเก็บข้อมูลเดียวกันกับ KV มีอัตรา errors สูงถึง 22% หรือไม่สามารถใช้งาน message queuing และการจัดการข้อมูลได้อย่างสมบูรณ์
Realtime & AI Gateway ประสบปัญหาการหยุดให้บริการเกือบทั้งหมด เนื่องจากไม่สามารถดึงการตั้งค่าจาก Workers KV ได้ โดย Realtime TURN/SFU requests และ AI Gateway requests ได้รับผลกระทบอย่างหนัก
Zaraz & Workers Assets ตรวจพบการหยุดทำงานทั้งหมด โดยมีบางส่วนเป็นการโหลด หรืออัปเดตการตั้งค่า และไฟล์แบบ static assets ซึ่งส่งผลกระทบต่อผู้ใช้งานในขอบเขตที่จำกัด
CDN, Workers for Platforms, Workers Builds ตรวจพบความหน่วงเพิ่มขึ้น และความผิดพลาดในบาง regional พร้อมกับการสร้าง Workers ใหม่ล้มเหลว 100% ในช่วงเหตุการณ์

เพื่อตอบสนองต่อเหตุการณ์หยุดทำงานครั้งนี้ Cloudflare ระบุว่า จะเร่งดำเนินการปรับปรุงหลายรายการเน้นด้านความยืดหยุ่นเป็นหลัก โดยเฉพาะการยกเลิกการพึ่งพาผู้ให้บริการคลาวด์รายเดียวสำหรับ Workers KV backend storage

โดยจะมีการย้าย central store ของ KV ไปยังระบบ R2 object storage ของ Cloudflare เอง เพื่อลดการพึ่งพาผู้ให้บริการภายนอก

Cloudflare ยังวางแผนที่จะติดตั้งมาตรการ cross-service safeguards และพัฒนาเครื่องมือใหม่ ๆ เพื่อช่วยฟื้นฟูการหยุดทำงานของระบบจัดเก็บข้อมูล พร้อมทั้งป้องกันการเพิ่มขึ้นของปริมาณการรับส่งข้อมูลที่อาจสูงขึ้นบนระบบที่กำลังกู้คืน และทำให้เกิดการหยุดทำงานครั้งที่สอง

ที่มา : bleepingcomputer.

บริษัทด้านการรักษาความปลอดภัยทางไซเบอร์ Cloudflare ออกคำเตือนอย่างชัดเจนเกี่ยวกับภัยคุกคามที่ทวีความรุนแรงขึ้นที่องค์กรสื่ออิสระทั่วโลกต้องเผชิญ โดยเปิดเผยว่านักข่าว และสำนักข่าวต่าง ๆ ได้กลายเป็นเป้าหมายหลักของการโจมตีแบบ Distributed Denial-of-Service (DDoS) ที่มีความซับซ้อน (more…)

Cloudflare ผู้ให้บริการอินเทอร์เน็ตยักษ์ใหญ่ เปิดเผยว่าสามารถป้องกันการโจมตี DDoS ได้มากเป็นประวัติการณ์ในปี 2025 โดยสามารถป้องกันได้เพิ่มขึ้นอย่างมากถึง 358% เมื่อเทียบกับปีก่อนหน้า และเพิ่มขึ้น 198% เมื่อเทียบกับไตรมาสต่อไตรมาส

(more…)

Cloudflare ประกาศว่าได้ปิดการเชื่อมต่อ HTTP ทั้งหมด และตอนนี้จะรับเฉพาะการเชื่อมต่อที่ปลอดภัยผ่าน HTTPS สำหรับ api.

การพยายามบล็อก URL ฟิชชิ่งในแพลตฟอร์ม R2 object storage ของ Cloudflare เมื่อวานนี้ (6 กุมภาพันธ์ 2025) กลับเกิดข้อผิดพลาด ทำให้เกิดการหยุดการทำงานอย่างกว้างขวาง ซึ่งทำให้บริการหลาย ๆ รายการล่มไปเกือบหนึ่งชั่วโมง

Cloudflare R2 เป็นบริการจัดเก็บข้อมูลแบบอ็อบเจกต์ที่คล้ายกับ Amazon S3 ซึ่งออกแบบมาเพื่อการจัดเก็บข้อมูลที่สามารถขยายขนาดได้, มีความทนทาน และมีค่าใช้จ่ายต่ำ โดยนำเสนอการดึงข้อมูลฟรี ไม่มีค่าใช้จ่าย, ความ compatibility กับ S3, data replication ในหลายสถานที่ และการ integration กับบริการอื่น ๆ ของ Cloudflare

การหยุดการทำงานเกิดขึ้นเมื่อวานนี้ เมื่อเจ้าหน้าที่ของ Cloudflare ตอบสนองต่อรายงานการละเมิดเกี่ยวกับ URL ฟิชชิ่งในแพลตฟอร์ม R2 ของ Cloudflare อย่างไรก็ตาม แทนที่จะบล็อก specific endpoint เจ้าหน้าที่ของ Cloudflare กลับปิดบริการ R2 Gateway ทั้งหมดโดยไม่ตั้งใจ

Cloudflare อธิบายในรายงานหลังเหตุการณ์ "ในระหว่างการแก้ไขการละเมิดตามปกติ ได้มีการดำเนินการตามการร้องเรียนที่ทำให้บริการ R2 Gateway ถูกปิดโดยไม่ได้ตั้งใจ แทนที่จะปิดเฉพาะ specific ndpoint/bucket ที่เกี่ยวข้องกับรายงานนั้น"

“นี่เป็นความล้มเหลวของ system level controls และการฝึกอบรมผู้ปฏิบัติงาน"

เหตุการณ์นี้ใช้เวลานาน 59 นาที ระหว่างเวลา 08:10 ถึง 09:09 UTC และนอกจากการหยุดทำงานของ R2 Object Storage แล้ว ยังส่งผลกระทบต่อบริการอื่น ๆ เช่น

Stream – การอัปโหลดวิดีโอ และการส่งสตรีมมิ่ง ล้มเหลว 100%
Images – การอัปโหลด/ดาวน์โหลดภาพล้มเหลว 100%
Cache Reserve – การดำเนินการล้มเหลว 100% ทำให้มีการ request จากต้นทางเพิ่มขึ้น
Vectorize – ล้มเหลว 75% ในการ queries, ล้มเหลว 100% ในการ insert, upsert และ delete
Log Delivery – ความล่าช้า และการสูญหายของข้อมูล: การสูญหายของข้อมูลสูงสุด 13.6% สำหรับ Logs ที่เกี่ยวข้องกับ R2, การสูญหายของข้อมูลถึง 4.5% สำหรับ delivery jobs ที่ไม่ใช่ R2
Key Transparency Auditor – signature publishing และ read operations ล้มเหลว 100%

นอกจากนี้ยังมีบริการที่ได้รับผลกระทบทางอ้อม ซึ่งประสบปัญหากับการใช้งานบางส่วน เช่น Durable Objects ที่มีอัตราการเกิดข้อผิดพลาดเพิ่มขึ้น 0.09% เนื่องจากการเชื่อมต่อใหม่หลังการกู้คืน, Cache Purge ที่มีข้อผิดพลาดเพิ่มขึ้น 1.8% (HTTP 5xx) และการหน่วงเวลาเพิ่มขึ้น 10 เท่า, และ Workers & Pages ที่มีข้อผิดพลาดในการ deployment 0.002% ซึ่งส่งผลกระทบเฉพาะโปรเจกต์ที่มีการเชื่อมต่อกับ R2 เท่านั้น

Cloudflare ระบุว่าทั้ง human error และการขาดกลไกป้องกัน เช่น การตรวจสอบความถูกต้องสำหรับการดำเนินการที่ส่งผลกระทบร้ายแรง เป็นปัจจัยสำคัญที่ทำให้เกิดเหตุการณ์นี้

Cloudflare ได้ดำเนินการแก้ไขเบื้องต้นแล้ว เช่น การนำความสามารถในการปิดระบบออกจากอินเทอร์เฟซตรวจสอบการละเมิด และเพิ่มข้อจำกัดใน Admin API เพื่อป้องกันการปิดบริการโดยไม่ได้ตั้งใจ

มาตรการเพิ่มเติมที่จะนำมาใช้ในอนาคต ได้แก่ การปรับปรุงกระบวนการสร้างบัญชี, การควบคุมสิทธิ์การเข้าถึงที่เข้มงวดขึ้น และกระบวนการ two-party approval สำหรับการดำเนินการที่มีความเสี่ยงสูง

ในเดือนพฤศจิกายน 2024 Cloudflare ประสบกับเหตุการณ์หยุดทำงานครั้งสำคัญอีกครั้งเป็นเวลานาน 3.5 ชั่วโมง ส่งผลให้ Logs ในบริการสูญหายอย่างถาวรถึง 55%

เหตุการณ์ดังกล่าวเกิดจากความล้มเหลวต่อเนื่อง (cascading failures) ในระบบลดผลกระทบอัตโนมัติของ Cloudflare ซึ่งถูกทริกเกอร์โดยการตั้งค่าที่ไม่ถูกต้องไปยังส่วนประกอบสำคัญในระบบ Logging pipeline ของบริษัท

 

ที่มา : bleepingcomputer.

Cloudflare ได้เปิดเผยเมื่อวันอังคารที่ผ่านมาว่า ได้ตรวจพบและป้องกันการโจมตีแบบ Distributed Denial-of-Service (DDoS) ด้วยความเร็วสูงถึง 5.6 เทราบิตต่อวินาที (Tbps) ซึ่งเป็นการโจมตีที่ใหญ่ที่สุดเท่าที่เคยมีการรายงานมา

การโจมตีดังกล่าวใช้โปรโตคอล UDP เกิดขึ้นเมื่อวันที่ 29 ตุลาคม 2024 ที่ผ่านมา โดยมีเป้าหมายโจมตีลูกค้ารายหนึ่งของบริษัท ซึ่งเป็นผู้ให้บริการอินเทอร์เน็ต (ISP) ที่ไม่เปิดเผยชื่อจากเอเชียตะวันออก ซึ่งการโจมตีในครั้งนี้มีต้นตอมาจาก Mirai-variant botnet

Omer Yoachimik และ Jorge Pacheco จาก Cloudflare ระบุว่า "การโจมตีครั้งนี้เกิดขึ้นเพียง 80 วินาที และมาจากอุปกรณ์ IoT มากกว่า 13,000 เครื่อง"

ทั้งนี้ จำนวนเฉลี่ยของ Source IP จากต้นทางที่มีการตรวจพบ เฉลี่ยต่อวินาทีอยู่ที่ 5,500 IP โดยแต่ละ IP มีปริมาณการโจมตีโดยเฉลี่ยประมาณ 1 Gbps ต่อวินาที

สถิติเดิมของการโจมตีแบบ DDoS ที่มีปริมาณข้อมูลสูงสุดเท่าที่เคยถูกบันทึกโดย Cloudflare ในเดือนตุลาคม 2024 ที่ผ่านมา โดยมีความเร็วสูงสุดอยู่ที่ 3.8 Tbps

Cloudflare ยังเปิดเผยอีกว่าในปี 2024 บริษัทได้ป้องกันการโจมตีแบบ DDoS ได้ประมาณ 21.3 ล้านครั้ง ซึ่งเพิ่มขึ้น 53% เมื่อเทียบกับปี 2023 และจำนวนการโจมตีที่มีปริมาณข้อมูลเกิน 1 Tbps เพิ่มขึ้นถึง 1,885% เมื่อเทียบกับไตรมาสก่อนหน้านี้ โดยเฉพาะในไตรมาสที่ 4 ของปี 2024 มีการป้องกันการโจมตีแบบ DDoS มากถึง 6.9 ล้านครั้ง

สถิติที่น่าสนใจอื่น ๆ ที่พบในไตรมาสที่ 4 ของปี 2024 มีดังต่อไปนี้ :

DDoS botnets ที่เป็นที่รู้จักมีส่วนเกี่ยวข้องกับการโจมตีแบบ HTTP DDoS ถึง 72.6% ของการโจมตีทั้งหมด
รูปแบบการโจมตีที่พบบ่อยมากที่สุด 3 อันดับแรกในระดับ Layer 3 และ Layer 4 ได้แก่ การโจมตีแบบ SYN floods (38%), การโจมตีแบบ DNS flood (16%), และการโจมตีแบบ UDP floods (14%)
การโจมตีแบบ Memcached DDoS, การโจมตีแบบ BitTorrent DDoS, และการโจมตีแบบ ransom DDoS มีอัตราเพิ่มขึ้น 314%, 304%, และ 78% ตามลำดับเมื่อเทียบกับไตรมาสก่อน
ประมาณ 72% ของการโจมตีแบบ HTTP DDoS และ 91% ของการโจมตีแบบ DDoS ใน network layer จบลงภายในเวลาไม่เกิน 10 นาที
อินโดนีเซีย, ฮ่องกง, สิงคโปร์, ยูเครน และอาร์เจนตินา เป็นแหล่งที่มาของการโจมตีแบบ DDoS ที่ใหญ่ที่สุด
จีน, ฟิลิปปินส์, ไต้หวัน, ฮ่องกง และเยอรมนี เป็นประเทศที่ถูกโจมตีมากที่สุด
ภาคส่วนที่ถูกโจมตีมากที่สุด ได้แก่ โทรคมนาคม, อินเทอร์เน็ต, การตลาด, เทคโนโลยีสารสนเทศ และการพนัน

ในขณะเดียวกันที่บริษัทด้านความปลอดภัยทางไซเบอร์อย่าง Qualys และ Trend Micro เปิดเผยว่าได้ตรวจพบมัลแวร์สายพันธุ์ย่อยของ Mirai botnet ที่กำลังโจมตีอุปกรณ์ Internet of Things (IoT) โดยใช้ช่องโหว่ด้านความปลอดภัยที่เป็นที่รู้จักและข้อมูล Credentials เพื่อใช้เป็นช่องทางในการโจมตีแบบ DDoS อีกด้วย

ที่มา : thehackernews.

Cloudflare บริษัทด้านความปลอดภัยบนอินเทอร์เน็ต ได้เผยแพร่เหตุการณ์ข้อมูล Log ที่ส่งถึงลูกค้าสูญหายถึง 55% ภายในช่วงเวลา 3.5 ชั่วโมง เนื่องมาจากข้อผิดพลาดใน log collection service เมื่อวันที่ 14 พฤศจิกายน 2024 ที่ผ่านมา

Cloudflare มีบริการ logging service อย่างครอบคลุมสำหรับลูกค้า ซึ่งช่วยให้ลูกค้าสามารถตรวจสอบการใช้งาน traffic บนระบบ และสามารถ filter การใช้งานดังกล่าวตามเงื่อนไขต่าง ๆ ซึ่ง log เหล่านี้ช่วยให้ลูกค้าสามารถวิเคราะห์ปริมาณการรับส่งข้อมูลไปยังโฮสต์ของตน เพื่อตรวจสอบเหตุการณ์ด้านความปลอดภัย, แก้ไขปัญหา, การโจมตีแบบ DDoS, รูปแบบปริมาณการรับส่งข้อมูล หรือเพื่อดำเนินการเพิ่มประสิทธิภาพของระบบ (more…)

แพลตฟอร์มส่งข้อความ WhatsApp ได้เปิดตัว Identity Proof Linked Storage (IPLS) ซึ่งเป็นระบบจัดเก็บข้อมูลเข้ารหัสที่รักษาความเป็นส่วนตัวรูปแบบใหม่ ที่ได้รับการออกแบบมาสำหรับการจัดการรายชื่อผู้ติดต่อ

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

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

ระบบเข้ารหัสที่ปลอดภัย

IPLS รักษาความปลอดภัยด้วยการผสมผสานการเข้ารหัส, ความโปร่งใสของคีย์ และการใช้โมดูลรักษาความปลอดภัยฮาร์ดแวร์ (HSM) และเมื่อเพิ่มผู้ติดต่อใหม่ ชื่อจะถูกเข้ารหัสโดยใช้คีย์เข้ารหัสแบบ symmetric ที่สร้างขึ้นบนอุปกรณ์ของผู้ใช้ และจัดเก็บไว้ใน Key Vault ป้องกันการเข้าถึงที่ใช้ HSM ของ WhatsApp

เมื่อผู้ใช้เข้าสู่ระบบในอุปกรณ์ใหม่ เซสชันที่ปลอดภัยโดยใช้ Key Vault ที่ใช้ HSM จะถูกสร้างขึ้นเพื่อดึงข้อมูลผู้ติดต่อใหม่โดยดำเนินการตรวจสอบสิทธิ์โดยใช้ keypair เข้ารหัสที่เชื่อมโยงกับบัญชีผู้ใช้ (สร้างขึ้นเมื่อลงทะเบียน)

IPLS รับประกันว่าข้อมูลผู้ติดต่อทั้งหมดได้รับการเข้ารหัสแบบ end-to-end ซึ่งหมายความว่าข้อมูลผู้ติดต่อได้รับการเข้ารหัสบนอุปกรณ์ของผู้ใช้ และยังคงได้รับการเข้ารหัสในขณะที่ข้อมูลเคลื่อนผ่านระบบของ WhatsApp ซึ่งป้องกันการดักจับระหว่างการส่ง หรือการเข้าถึงจากพนักงาน Meta ที่ไม่ปลอดภัย

WhatsApp ยังจับมือเป็นพันธมิตรกับ Cloudflare ในการตรวจสอบการดำเนินการเข้ารหัสโดย third-party ได้อย่างอิสระ โดยเฉพาะอย่างยิ่งเพื่อทำหน้าที่เป็นผู้รับประกันการอัปเดตใน Auditable Key Directory (AKD) โดย signing ในแต่ละแบบ และตรวจสอบว่าข้อมูลนั้นไม่ได้ถูกดัดแปลงใด ๆ

WhatsApp เผยแพร่หลักฐานความสอดคล้องที่ตรวจสอบได้สำหรับการอัปเดตไดเร็กทอรีหลัก ไปยังอินสแตนซ์ Amazon S3 ที่สามารถเข้าถึงได้จากสาธารณะ ช่วยให้ผู้ใช้งาน, นักวิจัย และผู้ตรวจสอบสามารถตรวจสอบความสมบูรณ์ของ AKD ได้อย่างอิสระ

ก่อนที่ IPLS และกลไกพื้นฐานจะถูกนำเสนอต่อสาธารณะ WhatsApp ได้ทำสัญญากับ NCC Group เพื่อทำการตรวจสอบความปลอดภัยในระบบใหม่

การค้นพบที่สำคัญที่สุดของการตรวจสอบดังกล่าวคือช่องโหว่ที่ทำให้สามารถปลอมแปลง HSM ของ Marvell และถอดรหัสข้อมูล secret key ของผู้ใช้ได้ ซึ่งอาจทำให้ข้อมูลเมตาของผู้ติดต่อส่วนตัวถูกเปิดเผย

WhatsApp แก้ไขปัญหานี้พร้อมกับช่องโหว่ 12 รายการที่ได้รับการประเมินว่ามีระดับความรุนแรงระดับต่ำจนถึงปานกลางในเดือนกันยายน 2024 ดังนั้นจึงไม่มีอยู่ในรุ่นสุดท้ายของ IPLS

ที่มา : bleepingcomputer.