การกำหนดค่าผิดพลาดของ SendBird ที่บอกเล่า
จากการทำงานร่วมกันในการล่าแมลงแบบสุ่มกับทีมของฉัน ( thaivu , lamscun , thefool45 , fergustr4n ) เราได้ชนเข้ากับเป้าหมายส่วนตัวแบบสุ่มตามปกติ ระหว่างทางที่โจมตีเป้าหมาย ฉันพบว่าเป้าหมายของเราใช้ฟีเจอร์แชทโดยใช้บริการจากแพลตฟอร์มของบุคคลที่สาม หลังจากทำ google dork ฉันพบว่าคุณลักษณะการแชทของเป้าหมายของเราเป็นผลิตภัณฑ์ของSendBird— “แพลตฟอร์ม API การโต้ตอบชั้นนำที่ได้รับความไว้วางใจจากแอปดิจิทัลสมัยใหม่ เช่น Paypal, Yahoo, Reddit, Delivery Hero และ Hinge เพื่อฝังการแชทแบบเรียลไทม์ เสียง และวิดีโอลงในแอปได้อย่างง่ายดาย” มันดึงดูดความสนใจของฉันและฉันตัดสินใจที่จะค้นคว้าเพิ่มเติมเกี่ยวกับวิธีการทำงานเพื่อดูว่าจะมีการกระทำที่ซ่อนอยู่ที่ฉันสามารถทำได้หรือการกำหนดค่าที่ซ่อนอยู่ซึ่งนักพัฒนาซอฟต์แวร์อาจพลาดไป...
ขั้นที่ 1 — เรียนรู้ผลิตภัณฑ์และเอกสารของบุคคลที่สาม
ฉันตรงไปที่ไซต์หลักของ SendBird เพื่อดูว่าฉันต้องเจอกับอะไร พอร์ทัลนักพัฒนา SendBird มีเอกสารที่ชัดเจนและมีประโยชน์สำหรับนักพัฒนาสำหรับผลิตภัณฑ์แต่ละประเภท (คู่มือการใช้งาน, ตัวอย่าง API, หมายเหตุ, คำแนะนำ, …)
มีบันทึกที่น่าสนใจสองสามข้อในขณะที่ฉันเริ่มค้นคว้า ( บางข้ออาจล้าสมัยเมื่อคุณอ่านบล็อกนี้ ):
- โฮสต์ของแอปพลิเคชัน SendBird ของลูกค้าจะอยู่ในรูปแบบ “https://api-{application_id}.sendbird.com”
- Sendbird มีตัวเลือกการควบคุมการเข้าถึง ที่หลากหลาย และบางส่วนจะเปิดใช้ตามค่าเริ่มต้นเพื่อหลีกเลี่ยงข้อผิดพลาดที่ไม่คาดคิดเมื่อสร้างแอปตัวอย่าง
- ลูกค้าไม่สามารถเปลี่ยนการตั้งค่า Access Control List ได้ด้วยตัวเอง การเปลี่ยนการตั้งค่า ACL สามารถทำได้โดยสมาชิกของทีมวิศวกรรมโซลูชันของ Sendbirdเท่านั้น
- ตามค่าเริ่มต้น การตั้งค่าความปลอดภัยของแอปพลิเคชัน SendBird สำหรับ “ ผู้ใช้ที่ไม่มีโทเค็นการเข้าถึง ” คือ “อ่านและเขียน” — แชท และ “โทร & รับสาย” — โทร
หลังจากดูภาพรวมเกี่ยวกับวิธีการทำงานของ SendBird แล้ว ฉันก็กลับไปที่เป้าหมายเพื่อใช้งาน ลองเล่นฟังก์ชันต่างๆ เพื่อยืนยันกับสิ่งที่ฉันอ่านด้านบน ฉันยืนยันว่ามี API ที่มีโฮสต์เป็นรูปแบบเดียวกับ “api-{application_id}.sendbird.com” และมีเส้นทางเหมือนกับที่ฉันเห็นในเอกสาร จากนั้น ฉันใช้เซสชัน API ปัจจุบันอย่างรวดเร็วเพื่อลองใช้ API ต่างๆ ในเอกสาร API ฉันสุ่มเลือก API ที่แสดงรายชื่อผู้ใช้ในแอปพลิเคชัน SendBird “GET /v3/users/” และที่น่าประหลาดใจคือเซิร์ฟเวอร์ตอบกลับพร้อมรายชื่อผู้ใช้ทั้งหมด !!! กระโดดด้วยความดีใจ ฉันบอกให้เพื่อนร่วมทีมทุกคนตรวจสอบดู
เราพยายามและรู้ว่าเซสชันของผู้ใช้ของเราสามารถเรียก API ต่างๆ และดำเนินการกับผู้ใช้ ช่องทาง ข้อความ … ภายในแอปพลิเคชัน SendBird ของเป้าหมายของเราได้มากมาย มันเป็นการควบคุมการเข้าถึงที่เสียหายอย่างมากเนื่องจากการกำหนดค่า ACL ผิดพลาด !!!
อย่างไรก็ตาม มีสิ่งหนึ่งที่เราไม่สามารถเข้าใจได้ว่า “Session-Key” มาจากไหนและสร้างขึ้นอย่างไร เนื่องจากเราไม่สามารถเห็นค่า “Session-Key” ในการตอบกลับใดๆ
กลับไปที่เอกสาร SendBird เพื่ออ่านเพิ่มเติมและทำมากขึ้น เรารู้บางสิ่งเพิ่มเติม:
- “ตามค่าเริ่มต้น เซิร์ฟเวอร์ Sendbird สามารถตรวจสอบผู้ใช้ได้ด้วยID ผู้ใช้ที่ไม่ซ้ำใคร”
- “หากไม่พบ ID ผู้ใช้ที่ตรงกัน เซิร์ฟเวอร์จะสร้างบัญชีผู้ใช้ใหม่ด้วย ID ผู้ใช้”
- “การพิสูจน์ตัวตนผู้ใช้สามารถทำได้ด้วย ID ผู้ใช้ของตนเอง แต่จะใช้โทเค็นการเข้าถึงหรือโทเค็นเซสชันก็ได้”
- เป้าหมายของเราในฐานะ ClientApp สามารถรับรองความถูกต้องกับเซิร์ฟเวอร์ SendBird ผ่าน WebSocket ด้วยรูปแบบอัปเกรด URL WebSocket เป็น: “ wss://ws-{application_id}.sendbird.com/?user_id={user_id}&ai={application_id}&access_token={access_token }”
- ไคลเอนต์ SendBird ของเป้าหมายของเราได้รับการรับรองความถูกต้องไปยังเซิร์ฟเวอร์ SendBird ผ่าน WebSocket
- “Session-Key” จะถูกส่งไปยังไคลเอ็นต์ผ่าน WebSocket Message หลังจากที่ไคลเอ็นต์เรียกอัปเกรด URL ของ WebSocket ตามด้านบน
- ไคลเอนต์ SendBird ของเป้าหมายของเราสามารถตรวจสอบได้โดยใช้ ID ผู้ใช้เท่านั้นที่มี “ access_token=null”
- นอกจากนี้ เรายังพบ API ที่ซ่อนอยู่เพื่อตรวจสอบสิทธิ์ผ่าน USER ID ในแบบ WebSocket ในไฟล์ JS เท่านั้น: " POST https://api-{application_id}.sendbird.com/v3/users/{user_id}/login — body: {" app_id”:”<application_id>”} ”
อันดับ 3 — วิธีการตรวจสอบช่องโหว่ขนาดใหญ่บน SendBird Intances อื่นๆ ในเป้าหมายที่แตกต่างกัน
- เราต้องยืนยันว่าเป้าหมายของเราใช้ SendBird ในแอปพลิเคชันโดยการรวบรวมข้อมูล ดำเนินการค้นหาเนื้อหาในเป้าหมายและ grep สำหรับคำว่า “sendbird” และ regex ของ ID แอปพลิเคชันของ SendBird “ [0–9A-F]{8}-[0– 9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{12} ”
- หลังจากยืนยันเป้าหมายที่ใช้ SendBird และได้รับ ID แอปพลิเคชัน SendBird แล้ว เราจะตรวจสอบว่าการตั้งค่าความปลอดภัยของแอปพลิเคชัน SendBird สำหรับ “ผู้ใช้ที่ไม่มีโทเค็นการเข้าถึง” มีการกำหนดค่าผิดหรือไม่โดยทำการเข้าสู่ระบบ/สร้างผู้ใช้โดยไม่ระบุชื่อด้วยวิธีต่อไปนี้:
- wss://ws-{application_id}.sendbird.com/?user_id={user_id}&ai={application_id}&access_token={access_token}
- โพ สต์ https://api-{application_id}.sendbird.com/v3/users/{user_id}/login — เนื้อหา: {“app_id”:”<application_id>”}
- https://www.postman.com/sendbird/workspace/sendbird-platform-api/overview
- https://sendbird.com/docs
- รั่วไหลข้อมูลที่ละเอียดอ่อนของผู้ใช้
- สร้างช่องแชท (โดยไม่ต้องสร้างลีกใหม่)
- จัดการช่องแชท
- อัปเดตโปรไฟล์การแชทของผู้ใช้
- อัปเดตการกำหนดค่าแชนเนลกลุ่ม
- สนทนากับผู้ใช้ใด ๆ
- ผู้โจมตีสามารถแก้ไข/ลบข้อความของผู้ใช้ใดๆ ในขณะที่เป็นผู้ดำเนินการของช่องทางที่สร้างขึ้นเอง
- ผู้โจมตีสามารถอัปเดตรายละเอียด การกำหนดค่าของช่องในขณะที่เป็นสมาชิกของช่องใดก็ได้
- ตามที่บันทึกไว้ ผู้ใช้ SendBird หนึ่งรายสามารถเข้าร่วมแชนเนลกลุ่มได้สูงสุด 2,000 แชนเนล ผู้โจมตีสามารถสร้างแชนเนลกลุ่มได้ 2,000 แชนแนล และเพิ่มผู้ใช้ทั้งหมดในแอปพลิเคชัน SendBird ไปยังแชนเนลเหล่านั้น เป็นผลให้ผู้ใช้ทั้งหมดไม่สามารถเข้าร่วมช่อง SendBird ได้หลังจากนั้น ซึ่งอาจทำให้ถูกปฏิเสธการให้บริการ
- …
- SendBird มีเอกสารเพิ่มเติมเกี่ยวกับคำแนะนำด้านความปลอดภัย โดยเฉพาะเกี่ยวกับ ACL
- ขณะนี้ SendBird อนุญาตให้ลูกค้าเปลี่ยน ACL ได้ด้วยตัวเอง
4. หากขั้นตอนที่ 2 ไม่สำเร็จ เราจะดำเนินการตามฟังก์ชันต่างๆ ในเป้าหมายด้วยตนเอง รับเซสชันผู้ใช้ SDK ด้วยวิธีปกติที่เป้าหมายทำ และตรวจสอบการกำหนดค่า ACL ที่ไม่ถูกต้องเหมือนขั้นตอนที่ 3
5. ระบบอัตโนมัติทั้งหมด !
การอ้างอิงสำหรับ SendBird API เพื่อตรวจสอบ:
หลังจากตรวจสอบช่องโหว่บนแอปพลิเคชัน SendBird ต่างๆ แล้ว ส่วนใหญ่มีความเสี่ยงต่อการกำหนดค่า ACL ที่ไม่ถูกต้อง อย่างไรก็ตาม ขึ้นอยู่กับการใช้งานที่แตกต่างกันซึ่งมีข้อกำหนดและผลกระทบทางธุรกิจที่แตกต่างกัน ความรุนแรงจะต้องได้รับการพิจารณาที่แตกต่างกันเช่นกัน (จากปานกลาง — วิกฤต)
ผลกระทบมีหลากหลาย:
ความร่วมมือที่ยอดเยี่ยมกับthaivu , lamscun , thefool45 , fergustr4n $$$$
### อัปเดตจาก SendBird