การตรวจสอบความปลอดภัยของแพลตฟอร์มคลาวด์ MCS

สกายชิปพลบค่ำ โดย SeerLight

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

บทความนี้เกี่ยวกับมุมมองที่ตรงไปตรงมาที่สุดของผู้เชี่ยวชาญภายนอกที่ช่วยทีม Mail.ru Cloud Solutions (MCS) ทดสอบบริการคลาวด์ และเกี่ยวกับสิ่งที่พวกเขาพบ ในฐานะ “พลังภายนอก” MCS เลือกบริษัทรักษาความปลอดภัยดิจิทัล ซึ่งเป็นที่รู้จักในด้านความเชี่ยวชาญสูงในแวดวงความปลอดภัยของข้อมูล และในบทความนี้ เราจะวิเคราะห์ช่องโหว่ที่น่าสนใจซึ่งพบในการตรวจสอบภายนอก เพื่อให้คุณหลีกเลี่ยงปัญหาเดียวกันนี้เมื่อคุณสร้างบริการคลาวด์ของคุณเอง

Описаниепродукта

โซลูชันคลาวด์ Mail.ru (MCS) เป็นแพลตฟอร์มสำหรับสร้างโครงสร้างพื้นฐานเสมือนจริงในระบบคลาวด์ ประกอบด้วย IaaS, PaaS และตลาดอิมเมจแอปพลิเคชันสำเร็จรูปสำหรับนักพัฒนา โดยคำนึงถึงสถาปัตยกรรม MCS จึงจำเป็นต้องตรวจสอบความปลอดภัยของผลิตภัณฑ์ในด้านต่อไปนี้:

• การปกป้องโครงสร้างพื้นฐานของสภาพแวดล้อมการจำลองเสมือน: ไฮเปอร์ไวเซอร์, การกำหนดเส้นทาง, ไฟร์วอลล์;
• การปกป้องโครงสร้างพื้นฐานเสมือนของลูกค้า: การแยกจากกัน รวมถึงเครือข่าย เครือข่ายส่วนตัวใน SDN
• OpenStack และส่วนประกอบแบบเปิด
• S3 ของการออกแบบของเราเอง
• IAM: โครงการที่มีผู้เช่าหลายรายพร้อมแบบอย่าง
• วิสัยทัศน์ (การมองเห็นคอมพิวเตอร์): API และช่องโหว่เมื่อทำงานกับรูปภาพ
• เว็บอินเตอร์เฟสและการโจมตีเว็บแบบคลาสสิก
• ช่องโหว่ของส่วนประกอบ PaaS
• API ของส่วนประกอบทั้งหมด

บางทีนั่นอาจเป็นทั้งหมดที่จำเป็นสำหรับประวัติศาสตร์ต่อไป

มีการดำเนินงานประเภทใดและเหตุใดจึงจำเป็น?

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

ในระหว่างการทำงานซึ่งกินเวลาโดยเฉลี่ย 1-2 เดือน ผู้ตรวจสอบจะทำซ้ำการกระทำของผู้โจมตีที่อาจเกิดขึ้นและค้นหาช่องโหว่ในส่วนของไคลเอนต์และเซิร์ฟเวอร์ของบริการที่เลือก ในบริบทของการตรวจสอบแพลตฟอร์มคลาวด์ MCS เป้าหมายต่อไปนี้ได้รับการระบุ:

1. การวิเคราะห์การรับรองความถูกต้องในบริการ ช่องโหว่ในส่วนนี้จะช่วยในการเข้าถึงบัญชีของผู้อื่นได้ทันที
2. ศึกษาตัวอย่างและการควบคุมการเข้าถึงระหว่างบัญชีต่างๆ สำหรับผู้โจมตี ความสามารถในการเข้าถึงเครื่องเสมือนของผู้อื่นถือเป็นเป้าหมายที่ต้องการ
3. ช่องโหว่ฝั่งไคลเอ็นต์ XSS/CSRF/CRLF/ฯลฯ เป็นไปได้ไหมที่จะโจมตีผู้ใช้รายอื่นผ่านลิงก์ที่เป็นอันตราย?
4. ช่องโหว่ฝั่งเซิร์ฟเวอร์: RCE และการฉีดทุกชนิด (SQL/XXE/SSRF และอื่นๆ) โดยทั่วไปช่องโหว่ของเซิร์ฟเวอร์มักพบได้ยากกว่า แต่นำไปสู่การประนีประนอมของผู้ใช้จำนวนมากในคราวเดียว
5. การวิเคราะห์การแยกส่วนผู้ใช้ในระดับเครือข่าย สำหรับผู้โจมตี การขาดการแยกส่วนจะเพิ่มพื้นที่การโจมตีต่อผู้ใช้รายอื่นอย่างมาก
6. การวิเคราะห์ตรรกะทางธุรกิจ เป็นไปได้ไหมที่จะหลอกลวงธุรกิจและสร้างเครื่องเสมือนฟรี?

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

พบช่องโหว่

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

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

ไอดอร์

ช่องโหว่ IDOR (Insecure Direct Object Reference) เป็นหนึ่งในช่องโหว่ที่พบบ่อยที่สุดในตรรกะทางธุรกิจ ซึ่งช่วยให้ฝ่ายใดฝ่ายหนึ่งสามารถเข้าถึงออบเจ็กต์ที่ไม่ได้รับอนุญาตให้เข้าถึงได้จริง ช่องโหว่ IDOR สร้างความเป็นไปได้ในการรับข้อมูลเกี่ยวกับผู้ใช้ที่มีระดับวิกฤตที่แตกต่างกัน

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

ในกรณีของ MCS ผู้ตรวจสอบบัญชีเพิ่งค้นพบช่องโหว่ IDOR ที่เกี่ยวข้องกับตัวระบุที่ไม่ปลอดภัย ในบัญชีส่วนตัวของผู้ใช้ ตัวระบุ UUID ถูกใช้เพื่อเข้าถึงวัตถุใดๆ ซึ่งตามที่ผู้เชี่ยวชาญด้านความปลอดภัยกล่าวว่าไม่ปลอดภัยอย่างน่าประทับใจ (นั่นคือ ได้รับการปกป้องจากการโจมตีแบบเดรัจฉาน) แต่สำหรับบางเอนทิตีพบว่ามีการใช้ตัวเลขที่คาดเดาได้ตามปกติเพื่อรับข้อมูลเกี่ยวกับผู้ใช้แอปพลิเคชัน ฉันคิดว่าคุณสามารถเดาได้ว่าเป็นไปได้ที่จะเปลี่ยน ID ผู้ใช้ทีละรายการ ส่งคำขออีกครั้ง และรับข้อมูลโดยข้าม ACL (รายการควบคุมการเข้าถึง กฎการเข้าถึงข้อมูลสำหรับกระบวนการและผู้ใช้)

การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ (SSRF)

ข้อดีของผลิตภัณฑ์ OpenSource คือมีฟอรัมจำนวนมากพร้อมคำอธิบายทางเทคนิคโดยละเอียดของปัญหาที่เกิดขึ้น และหากคุณโชคดีก็จะมีคำอธิบายวิธีแก้ไขด้วย แต่เหรียญนี้มีด้านพลิก: มีการอธิบายช่องโหว่ที่ทราบโดยละเอียดด้วย ตัวอย่างเช่น มีคำอธิบายที่ยอดเยี่ยมเกี่ยวกับช่องโหว่ในฟอรัม OpenStack [เอ็กซ์เอสเอส] и [สสส.]ซึ่งด้วยเหตุผลบางอย่างจึงไม่มีใครรีบแก้ไข

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

ช่องโหว่ SSRF สามารถพัฒนาการโจมตีได้อย่างมาก ผู้โจมตีสามารถรับ:

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

ช่องโหว่ SSRF เป็นที่รู้จักมานานแล้วใน OpenStack ซึ่งมีลักษณะ "ตาบอด": เมื่อคุณติดต่อกับเซิร์ฟเวอร์ คุณจะไม่ได้รับการตอบกลับ แต่คุณจะได้รับข้อผิดพลาด/ความล่าช้าประเภทต่างๆ ขึ้นอยู่กับผลลัพธ์ของคำขอ . จากข้อมูลนี้ คุณสามารถทำการสแกนพอร์ตบนโฮสต์บนเครือข่ายภายใน พร้อมผลที่ตามมาทั้งหมดที่ไม่ควรมองข้าม ตัวอย่างเช่น ผลิตภัณฑ์อาจมี API แบ็คออฟฟิศที่สามารถเข้าถึงได้จากเครือข่ายองค์กรเท่านั้น ด้วยเอกสารประกอบ (อย่าลืมเกี่ยวกับบุคคลภายใน) ผู้โจมตีสามารถใช้ SSRF เพื่อเข้าถึงวิธีการภายในได้ ตัวอย่างเช่น หากคุณสามารถรับรายการ URL ที่มีประโยชน์โดยประมาณได้ คุณสามารถใช้ SSRF และดำเนินการตามคำขอได้ เช่น โอนเงินจากบัญชีหนึ่งไปยังอีกบัญชีหนึ่งหรือเปลี่ยนขีดจำกัด

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

และใน นี้ รายงานที่เปิดเผยต่อสาธารณะจากบริการ HackerOne (h1) การใช้ประโยชน์จาก SSRF ที่ไม่ปกปิดอีกต่อไปด้วยความสามารถในการอ่านข้อมูลเมตาของอินสแตนซ์นำไปสู่การเข้าถึงรูทไปยังโครงสร้างพื้นฐาน Shopify ทั้งหมด

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

XSS แทนที่จะโหลดกระสุน

แม้ว่าจะมีงานวิจัยหลายร้อยชิ้นที่เขียนขึ้น แต่ปีแล้วปีเล่าการโจมตี XSS (cross-site scripting) ยังคงเป็นการโจมตีที่ยิ่งใหญ่ที่สุด เจอบ่อย ช่องโหว่ของเว็บ (หรือ โจมตี?)

การอัปโหลดไฟล์เป็นสถานที่ยอดนิยมสำหรับนักวิจัยด้านความปลอดภัย บ่อยครั้งปรากฎว่าคุณสามารถโหลดสคริปต์ที่กำหนดเอง (asp/jsp/php) และดำเนินการคำสั่ง OS ตามคำศัพท์เฉพาะของ pentesters - "load shell" แต่ความนิยมของช่องโหว่ดังกล่าวได้ผลในทั้งสองทิศทาง: พวกมันจะถูกจดจำและมีการพัฒนาวิธีแก้ไข ดังนั้นเมื่อเร็ว ๆ นี้ความน่าจะเป็นที่จะ "บรรจุกระสุน" มีแนวโน้มเป็นศูนย์

ทีมโจมตี (แสดงโดย Digital Security) โชคดี ตกลง ใน MCS ทางฝั่งเซิร์ฟเวอร์ เนื้อหาของไฟล์ที่ดาวน์โหลดได้รับการตรวจสอบ อนุญาตเฉพาะรูปภาพเท่านั้น แต่ SVG ก็เป็นรูปภาพเช่นกัน รูปภาพ SVG เป็นอันตรายได้อย่างไร เพราะคุณสามารถฝังโค้ด JavaScript ลงไปได้!

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

ตัวอย่างการโจมตี XSS ในแบบฟอร์มเข้าสู่ระบบฟิชชิ่ง

ตัวอย่างของการแสวงหาประโยชน์จากการโจมตี XSS:

• เหตุใดจึงพยายามขโมยเซสชัน (โดยเฉพาะอย่างยิ่งเมื่อขณะนี้คุกกี้ HTTP-Only มีอยู่ทุกหนทุกแห่ง ได้รับการป้องกันการโจรกรรมโดยใช้สคริปต์ js) หากสคริปต์ที่โหลดสามารถเข้าถึง API ทรัพยากรได้ทันที ในกรณีนี้ เพย์โหลดสามารถใช้คำขอ XHR เพื่อเปลี่ยนการกำหนดค่าเซิร์ฟเวอร์ เช่น เพิ่มคีย์ SSH สาธารณะของผู้โจมตี และรับสิทธิ์เข้าถึง SSH ไปยังเซิร์ฟเวอร์
• หากนโยบาย CSP (นโยบายการป้องกันเนื้อหา) ห้ามไม่ให้มีการแทรก JavaScript ผู้โจมตีสามารถผ่านไปได้โดยไม่ต้องใช้มัน ใช้ HTML ล้วนๆ สร้างแบบฟอร์มเข้าสู่ระบบปลอมสำหรับไซต์และขโมยรหัสผ่านของผู้ดูแลระบบผ่านฟิชชิ่งขั้นสูง: หน้าฟิชชิ่งสำหรับผู้ใช้จะจบลงที่ URL เดียวกัน และเป็นการยากที่ผู้ใช้จะตรวจพบได้
• ในที่สุดผู้โจมตีก็สามารถจัดการได้ DoS ของลูกค้า — ตั้งค่าคุกกี้ให้มีขนาดใหญ่กว่า 4 KB ผู้ใช้จำเป็นต้องเปิดลิงก์เพียงครั้งเดียว และไม่สามารถเข้าถึงทั้งไซต์ได้จนกว่าผู้ใช้จะคิดทำความสะอาดเบราว์เซอร์โดยเฉพาะ: ในกรณีส่วนใหญ่ เว็บเซิร์ฟเวอร์จะปฏิเสธที่จะยอมรับไคลเอ็นต์ดังกล่าว

เรามาดูตัวอย่างของ XSS อีกตัวที่ตรวจพบ คราวนี้มีช่องโหว่ที่ฉลาดกว่า บริการ MCS ช่วยให้คุณสามารถรวมการตั้งค่าไฟร์วอลล์เป็นกลุ่มได้ ชื่อกลุ่มคือตำแหน่งที่ตรวจพบ XSS ลักษณะเฉพาะของมันคือเวกเตอร์ไม่ได้ถูกกระตุ้นทันที ไม่ใช่เมื่อดูรายการกฎ แต่เมื่อลบกลุ่ม:

นั่นคือสถานการณ์กลายเป็นดังต่อไปนี้: ผู้โจมตีสร้างกฎไฟร์วอลล์ที่มีชื่อ "โหลด" ผู้ดูแลระบบจะสังเกตเห็นหลังจากนั้นไม่นานและเริ่มกระบวนการลบ และนี่คือจุดที่ JS ที่เป็นอันตรายทำงาน

สำหรับนักพัฒนา MCS เพื่อป้องกัน XSS ในภาพ SVG ที่ดาวน์โหลด (หากไม่สามารถละทิ้งได้) ทีม Digital Security แนะนำให้:

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

นอกจากนี้ ปัจจุบันมีหลายวิธีสำหรับนักพัฒนาในการลดความเสี่ยงของการแสวงหาผลประโยชน์จาก XSS:

• การใช้การตั้งค่าสถานะ "HTTP เท่านั้น" จะทำให้ส่วนหัว "คุกกี้" ของเซสชันไม่สามารถเข้าถึง JavaScript ที่เป็นอันตรายได้
• ปฏิบัติตามนโยบาย CSP อย่างถูกต้อง จะทำให้ผู้โจมตีใช้ประโยชน์จาก XSS ได้ยากขึ้นมาก
• เอ็นจิ้นเทมเพลตสมัยใหม่ เช่น Angular หรือ React จะล้างข้อมูลผู้ใช้โดยอัตโนมัติก่อนที่จะส่งออกไปยังเบราว์เซอร์ของผู้ใช้

ช่องโหว่การรับรองความถูกต้องด้วยสองปัจจัย

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

แต่การใช้ปัจจัยการรับรองความถูกต้องที่สองจะรับประกันความปลอดภัยของบัญชีเสมอไปหรือไม่ มีปัญหาด้านความปลอดภัยต่อไปนี้ในการใช้งาน 2FA:

• การค้นหารหัส OTP แบบดุร้าย (รหัสครั้งเดียว) แม้จะมีความเรียบง่ายในการใช้งาน แต่ข้อผิดพลาด เช่น การขาดการป้องกัน OTP กำลังดุร้าย ก็พบได้ในบริษัทขนาดใหญ่เช่นกัน: กรณีหย่อน, กรณีเฟสบุ๊ค.
• อัลกอริธึมการสร้างจุดอ่อน เช่น ความสามารถในการทำนายโค้ดถัดไป
• ข้อผิดพลาดเชิงตรรกะ เช่น ความสามารถในการขอ OTP ของผู้อื่นบนโทรศัพท์ของคุณเช่นนี้ มันเป็น จาก Shopify

ในกรณีของ MCS จะมีการปรับใช้ 2FA โดยใช้ Google Authenticator และ Duo- โปรโตคอลนั้นได้รับการทดสอบตามเวลาแล้ว แต่การใช้งานการตรวจสอบรหัสในฝั่งแอปพลิเคชันก็คุ้มค่าที่จะตรวจสอบ

MCS 2FA ถูกใช้ในหลายแห่ง:

• เมื่อตรวจสอบสิทธิ์ผู้ใช้ มีการป้องกันการใช้กำลังดุร้าย: ผู้ใช้พยายามป้อนรหัสผ่านเพียงครั้งเดียวเพียงไม่กี่ครั้ง จากนั้นข้อมูลจะถูกบล็อกชั่วขณะหนึ่ง สิ่งนี้จะบล็อกความเป็นไปได้ในการเลือก OTP แบบเดรัจฉาน
• เมื่อสร้างรหัสสำรองออฟไลน์เพื่อดำเนินการ 2FA รวมถึงปิดการใช้งาน ที่นี่ ไม่มีการใช้การป้องกันแบบ bruteforce ซึ่งทำให้ถ้าคุณมีรหัสผ่านสำหรับบัญชีและเซสชันที่ใช้งานอยู่ สามารถสร้างรหัสสำรองใหม่หรือปิดการใช้งาน 2FA ได้อย่างสมบูรณ์

เมื่อพิจารณาว่ารหัสสำรองอยู่ในช่วงของค่าสตริงเดียวกันกับที่สร้างโดยแอปพลิเคชัน OTP โอกาสในการค้นหารหัสในเวลาอันสั้นจึงสูงกว่ามาก

กระบวนการเลือก OTP เพื่อปิดการใช้งาน 2FA โดยใช้เครื่องมือ “Burp: Intruder”

ผล

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

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

ขณะนี้ช่องโหว่ที่กล่าวมาทั้งหมดใน MCS ได้รับการแก้ไขแล้ว และเพื่อรักษาจำนวนรายการใหม่ให้น้อยที่สุดและลดอายุการใช้งาน ทีมงานแพลตฟอร์มยังคงดำเนินการดังนี้:

• ดำเนินการตรวจสอบโดยบริษัทภายนอกอย่างสม่ำเสมอ
• สนับสนุนและพัฒนาการมีส่วนร่วม ในโปรแกรม Mail.ru Group Bug Bounty;
• มีส่วนร่วมในการรักษาความปลอดภัย

ที่มา: will.com