IDOR เข้าครอบครองบัญชี

May 06 2023

สรุป สวัสดีชาว! เมื่อการรับรอง OSCP ของฉันเสร็จสิ้นและต้องการที่จะดำดิ่งสู่ปัญหาบั๊กอีกครั้ง ฉันตัดสินใจว่าบางทีฉันควรจะเขียนบล็อกโดยอ้างอิงจากการค้นพบครั้งก่อนด้วยความหวังว่าบางคนอาจจะพบว่ามีประโยชน์หรือเรียนรู้จากมัน บทความนี้เกี่ยวข้องกับการค้นหาช่องโหว่ IDOR สองรายการและใช้ประโยชน์จากช่องโหว่เหล่านี้เพื่อรั่วไหลของ PII ส่งผลให้เกิดการครอบครองบัญชี

สรุป

สวัสดีทุกคน! เมื่อการรับรอง OSCP ของฉันเสร็จสิ้นและต้องการที่จะดำดิ่งสู่ปัญหาบั๊กอีกครั้ง ฉันตัดสินใจว่าบางทีฉันควรจะเขียนบล็อกโดยอ้างอิงจากการค้นพบครั้งก่อนด้วยความหวังว่าบางคนอาจจะพบว่ามีประโยชน์หรือเรียนรู้จากมัน

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

IDOR นี้ที่ฉันพูดถึงคืออะไร

Insecure Direct Object Referenceส่วนใหญ่มักเรียกโดยย่อว่า “IDOR” เป็นช่องโหว่ประเภทหนึ่งที่สามารถจัดประเภทได้ภายaccess controlใต้ IDORsเกิดขึ้นภายในแอปพลิเคชันเมื่อแอพใช้อินพุตที่ผู้ใช้ให้มาเพื่อเข้าถึงวัตถุโดยตรงโดยไม่ต้องทำการตรวจสอบใดๆ เพื่อดูว่าผู้ใช้มีสิทธิ์การอนุญาตที่ถูกต้องหรือไม่ ส่วนใหญ่มักเกี่ยวข้องกับการเพิ่มระดับสิทธิ์ในแนวนอนIDORsซึ่งอาจส่งผลเสียต่อแอปพลิเคชันและฐานผู้ใช้

ตัวอย่างที่สำคัญของพารามิเตอร์ทั่วไปที่มักจะเสี่ยงต่อ IDOR ได้แก่id= | userID= | messageId=: การทำความเข้าใจโฟลว์ของแอปพลิเคชันจะช่วยให้ระบุปัญหาประเภทนี้ได้ง่ายขึ้น

ภาพด้านบนแสดงสองสถานการณ์ Scenario Aทางด้านซ้ายแสดงถึงแอปพลิเคชันที่มีความปลอดภัยมากขึ้น ซึ่งusers 2 and 3พยายามเข้าถึงบันทึกที่ละเอียดอ่อนซึ่งไม่ใช่ของพวกเขา อย่างไรก็ตาม ผลลัพธ์ที่ได้ก็เป็นไปaccess denied errorตามที่ควรจะเป็น

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

หากคุณต้องการอ่านเพิ่มเติมเกี่ยวกับIDORs Vickie Liมีบล็อกโพสต์ที่ยอดเยี่ยมที่อธิบายถึงพื้นฐานของช่องโหว่ประเภทนี้ คุณสามารถตรวจสอบได้ที่นี่

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

ตอนนี้เราทราบแล้วว่าสิ่งIDORsเหล่านั้นคืออะไร สามารถพบได้ที่ใดรวมถึงผลกระทบ เรามาเจาะลึกข้อค้นพบแรกเริ่มของฉันกัน! :)

การลาดตระเวน

แม้ว่าปัญหาจะได้รับการแก้ไขแล้ว แต่ฉันไม่ได้รับอนุญาตให้เปิดเผยต่อสาธารณะอย่างสมบูรณ์ ดังนั้นเป้าหมายจะถูกเรียกว่าexample.com: เช่นเดียวกับเป้าหมายอื่นๆscopeการแจงนับโดเมนย่อยเป็นกุญแจสำคัญในการขยายขอบเขตการโจมตี อย่างไรก็ตาม การแจงนับโดเมนย่อยไม่ใช่วิธีเดียวที่จะขยายพื้นผิวของการโจมตี เนื่องจากเรายังสามารถวิเคราะห์JavaScriptไฟล์สำหรับข้อมูลที่ละเอียดอ่อนได้ ด้วย ในกรณีนี้ ฉันตัดสินใจที่จะเริ่มต้นด้วยการใช้ Quick Google Dorkเพื่อดูว่าฉันสามารถค้นหาโดเมนย่อยที่น่าสนใจได้หรือไม่ ก่อนที่จะใช้เครื่องมืออัตโนมัติเพื่อให้ได้ผลลัพธ์ที่มากขึ้น

Google Dork:site:*.example.com

Example.comมีโดเมนย่อยประมาณ 36 โดเมน ดังนั้นจึงมีโดเมนย่อยจำนวนมากพอสมควรที่จะใช้งานด้วย!
เมื่อดูทีละโดเมน ฉันจดโดเมนย่อยสองโดเมนซึ่งมีฟังก์ชันมากมาย ฉันใช้เวลาประมาณหนึ่งหรือสองวันเพื่อนำทางไปรอบๆ โดเมนย่อยเหล่านี้และทดสอบคุณสมบัติต่างๆ ในขณะที่จดบันทึกคุณสมบัติที่น่าสนใจบางอย่างที่มีเฉพาะในแอปพลิเคชันนั้น ตัวอย่างเช่น แอปพลิเคชันมีคุณลักษณะที่คุณสามารถสร้างตั๋วเพื่อรับการสนับสนุนจากเจ้าหน้าที่ตามหมวดหมู่ต่างๆ เช่น "ปัญหาการชำระเงิน"

ข้อผิดพลาดเริ่มต้น

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

ผู้ใช้ลงทะเบียนผ่านอีเมล
ผู้ใช้จะถูกขอให้ตั้งค่า a PIN No.และ a security questionก่อนที่กระบวนการสร้างบัญชีจะเสร็จสิ้น สามารถตั้งค่าได้เพียงครั้งเดียวและไม่สามารถเปลี่ยนแปลงได้
ระบบขอให้ผู้ใช้ยืนยันอีเมลก่อนจึงจะลงชื่อเข้าใช้ได้

เมื่อใช้account AฉันBurpsuiteเริ่มทดสอบคุณสมบัติการจองตั๋ว และสร้างบัญชีทดสอบสองบัญชี ตามด้วยการสร้างตั๋วสองสามรายการภายใต้หมวดหมู่การสนับสนุนที่แตกต่างกันเพื่อวัตถุประสงค์ในการทดสอบ เมื่อมองไปที่HTTP Historyข้างในBurpsuiteมีการโทรที่น่าสนใจ

ต่อไปนี้POST requestเกิดขึ้นเมื่อตอบกลับพนักงานในตั๋วที่เกี่ยวข้องกับการเรียกร้องรางวัล:

POST /account/prizes/view/{123456} HTTP/1.1
Host: subdomainX.example.com

grant=w&prizeClaim_id={123456}&action=add_comment&comment_body=Hello+admin+...

ดังนั้นเพื่อสรุปผลการวิจัย:

เมื่อลงทะเบียนผู้ใช้ทุกคนจะต้องสร้างPIN No.และsecurity question
เว็บไซต์อนุญาตให้ผู้ใช้สร้างตั๋วสนับสนุนเพื่อขอความช่วยเหลือ
ในการได้รับการสนับสนุน ผู้ใช้จำเป็นต้องตอบสนองในPIN No.เรื่องsecurity question answerที่ละเอียดอ่อน เช่น การกู้คืนบัญชี การเรียกร้องรางวัล และปัญหาการชำระเงิน
IDORช่องโหว่ที่ค้นพบในระบบการออกตั๋วช่วยให้ฝ่ายตรงข้ามแสดงความคิดเห็นภายในตั๋วสนับสนุนโดยไม่ต้องเป็นเจ้าของตั๋วหรือพนักงาน

ดังนั้น ถ้าฉันสามารถแสดงความคิดเห็นบนตั๋วใดๆ โดยไม่ต้องเป็นเจ้าของหรือมีสิทธิพิเศษสำหรับพนักงาน... แน่นอนว่านี่หมายความว่าฉันสามารถอ่านตั๋วใดๆ ก็ได้ใช่ไหม?

ฉันบันทึกคำขอ GET ต่อไปนี้เพื่อพยายามดูตั๋วที่เป็นของaccount Avia account Bซึ่งนำไปสู่403ข้อผิดพลาดที่ผิดกฎหมาย! ดังนั้นฉันสามารถเขียนถึงตั๋วสนับสนุนที่กำหนด แต่ไม่สามารถอ่านเนื้อหาของตั๋วได้ ณ จุดนี้ ฉันต้องการหาวิธีที่เป็นไปได้ในการก้าวต่อไป

รับปลายทางเพื่ออ่านตั๋วบนเว็บแอปพลิเคชัน

GET /management/ticket?id=343433 HTTP/1.1
Host: subdomainX.example.com
Upgrade-Insecure-Requests: 1
Connection: close

ในขณะที่พยายามใช้ประโยชน์จากคุณสมบัติการจองตั๋ว ฉันสะดุดกับคำขอดังต่อไปนี้

GET /go.php?du=example.com/ HTTP/1.1
Host: subdomainX.example.com
Connection: close
Upgrade-Insecure-Requests: 1
Cookie:

เนื้อหาตั๋วรั่วไหลผ่าน API ในแอพ IOS

ในระหว่างการลาดตระเวนครั้งแรก ฉันสังเกตเห็นว่าAPIคำขอบางอย่างถูกส่งไปเมื่อดึงข้อมูลโปรไฟล์ นอกจากนี้ เป้าหมายยังมีmobile appขอบเขต อีกด้วย มีความเป็นไปได้สูงที่แม้ว่าจะไม่สามารถอ่าน Ticket ของผู้ใช้รายอื่นบนเว็บแอปพลิเคชันได้ แต่อาจทำได้ผ่านแอปพลิเคชันมือถือ เนื่องจากอาจใช้แอปพลิเคชันที่แตกต่างจากเว็บแอปพลิเคAPI version/endpointชัน

เริ่มทำงานBurpsuiteและนำทางไปยังเซสชันตั๋วภายในแอปพลิเคชัน IOS ฉันมาถึงจุดสิ้นสุดต่อไปนี้:

GET /api/v3/tickets/123456/posts HTTP/1.1
Host: x-api.example.com

ตอนนี้ฉันพบจุดบกพร่องสองจุดแล้ว นั่นคือเป็นไปได้ที่จะเขียนไปยังตั๋วใดก็ได้และดูเนื้อหาของตั๋วที่เป็นของผู้ใช้รายอื่น

การเพิ่มตั๋วอ่าน IDOR > การครอบครองบัญชี

ณ จุดนี้ ฉันมีองค์ประกอบทั้งหมดที่จำเป็นในการครอบครองบัญชี เนื่องจากสามารถอ่านตั๋วใด ๆ ได้ การครอบครองบัญชีผู้ใช้สามารถทำได้ผ่านขั้นตอนต่อไปนี้:

เยี่ยมชม/api/v1/support-tickets/234567/postsจุดสิ้นสุดและส่งไปที่intruderในBurpsuiteเพื่อระบุตั๋วให้ได้มากที่สุด
Grepสำหรับคำหลักเช่นPin NumberหรือSecurity Questionจากการตอบกลับ
สร้างบัญชีใหม่บนเว็บไซต์และเปิดตั๋วภายใต้account recovery
พนักงานที่ได้รับจัดสรรจะขอชื่อผู้ใช้ของบัญชีที่คุณต้องการกู้คืนพร้อมกับ และsecurity question answerซึ่งPIN No.ทั้งหมดอาจรั่วไหลผ่าน IDOR ที่สองที่พบ จึงส่งผลให้เกิดการครอบครองบัญชี

แม้ว่าการครอบครองบัญชีจะประสบความสำเร็จแล้ว IDOR ที่เขียนตั๋วก็สามารถใช้ประโยชน์จากได้เช่นกัน ชื่อผู้ใช้ของพนักงานนำหน้าด้วยชื่อบริษัทexample-Johnเช่น ศัตรูสามารถ;