วิธีแฮ็กเซิร์ฟเวอร์ Exchange ที่ไม่ได้แพตช์ด้วยรหัส PowerShell อันธพาล

ไม่ถึงสองเดือนที่ผ่านมา มีข่าวบั๊กที่น่ากังวลเกิดขึ้น: มีการประกาศช่องโหว่แบบ Zero-day คู่หนึ่งใน Microsoft Exchange

ในขณะที่เรา แนะนำในเวลานั้นช่องโหว่เหล่านี้กำหนดอย่างเป็นทางการ CVE-2022-41040 และ CVE-2022-41082:

[เป็น] Zero-day สองวันที่ [สามารถ] ถูกล่ามโซ่เข้าด้วยกัน โดยบั๊กตัวแรกใช้จากระยะไกลเพื่อเปิดช่องโหว่มากพอที่จะทริกเกอร์บั๊กที่สอง ซึ่งอาจอนุญาตให้มีการเรียกใช้โค้ดจากระยะไกล (RCE) บนเซิร์ฟเวอร์ Exchange เอง

ช่องโหว่แรกนั้นชวนให้นึกถึงปัญหาและถูกทำร้ายอย่างกว้างขวาง ช่องโหว่ด้านความปลอดภัย ProxyShell ย้อนกลับไปในเดือนสิงหาคม 2021 เนื่องจากใช้พฤติกรรมที่เป็นอันตรายในฟีเจอร์ Autodiscover ของ Exchange อธิบายโดย Microsoft เป็นโปรโตคอลนั่นคือ “ใช้โดยไคลเอนต์ Outlook และ EAS [Exchange ActiveSync] เพื่อค้นหาและเชื่อมต่อกับกล่องจดหมายใน Exchange”.

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

น่าเสียดายที่แพตช์ ProxyShell ทำงานได้ไม่เพียงพอที่จะปิดการโจมตีผู้ใช้ที่ได้รับการรับรองความถูกต้อง ซึ่งนำไปสู่ ​​CVE-2022-40140 zero-day ใหม่ ซึ่งในไม่ช้าก็พูดสั้นๆ หากทำให้เข้าใจผิด ขนานนามว่า พร็อกซีNotShell.

ไม่อันตรายเท่า แต่ก็อันตรายอยู่ดี

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

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

ในฐานะผู้เชี่ยวชาญของ Sophos Chester Wisniewski วางไว้ ในเวลา:

มันคือ “ช่องโหว่กลางการตรวจสอบความถูกต้อง” ถ้าคุณต้องการเรียกมันว่า นั่นคือพรที่ผสมผสานกัน หมายความว่าสคริปต์ Python อัตโนมัติไม่สามารถเพียงแค่สแกนอินเทอร์เน็ตทั้งหมดและอาจใช้ประโยชน์จากเซิร์ฟเวอร์ Exchange ทุกเครื่องในโลกในเวลาไม่กี่นาทีหรือชั่วโมง อย่างที่เราเห็นเกิดขึ้นกับ ProxyLogon และ ProxyShell ในปี 2021 […]

คุณต้องมีรหัสผ่าน แต่การค้นหาที่อยู่อีเมลและรหัสผ่านชุดเดียวที่ถูกต้องสำหรับเซิร์ฟเวอร์ Exchange ใด ๆ นั้นอาจไม่ใช่เรื่องยากเกินไป และคุณอาจไม่เคยถูกเอาเปรียบมาก่อน เพราะการจะเข้าสู่ระบบ Outlook Web Access [OWA] ให้สำเร็จนั้นต้องใช้โทเค็น FIDO หรือตัวตรวจสอบความถูกต้อง หรือปัจจัยที่สองใดก็ตามที่คุณอาจใช้อยู่

แต่การโจมตีนี้ไม่ต้องการปัจจัยที่สอง […] แค่ได้รับชื่อผู้ใช้และรหัสผ่านก็เป็นอุปสรรคที่ค่อนข้างต่ำ

อย่างที่คุณคงจำได้ พวกเราหลายคนสันนิษฐาน (หรืออย่างน้อยก็หวังไว้) ว่า Microsoft จะรีบดำเนินการแก้ไขช่องโหว่ ProxyNotShell เนื่องจากยังมีเวลาอีกสองสัปดาห์จนถึง Patch Tuesday ในเดือนตุลาคม

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

แม้แต่ Patch Tuesday ของเดือนพฤศจิกายนก็ไม่ได้ให้การแก้ไขที่จำเป็นโดยตรง แม้ว่าจะเป็นแพทช์ก็ตาม อย่างไรก็ตามออกมา ในวันเดียวกันโดยเป็นส่วนหนึ่งของการอัปเดตความปลอดภัยเฉพาะของ Exchange ที่สามารถดึงข้อมูลและติดตั้งแยกกันได้:

เปิดเผยหลักฐานของแนวคิด

ตอนนี้ฝุ่นได้สงบลงแล้วและทุกคนก็มีเวลาแก้ไขเซิร์ฟเวอร์ Exchange ของตน (อย่างน้อยก็ไม่ลืม) นักวิจัยจาก Zero Day Initiative (ZDI) ซึ่งเดิมทีช่องโหว่เหล่านี้ได้รับการเปิดเผยอย่างรับผิดชอบเพื่อส่งไปยัง ไมโครซอฟท์, ได้อธิบาย วิธีใช้ประโยชน์จากจุดบกพร่อง

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

แน่นอนว่าข่าวดีก็คือ:

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

วิธีการทำงาน

ZDI คำอธิบาย ของช่องโหว่นี้ทำให้เกิดเรื่องราวที่น่าสนใจเกี่ยวกับความซับซ้อนที่สามารถเชื่อมโยงชิ้นส่วนทั้งหมดที่คุณต้องการเพื่อเปลี่ยนช่องโหว่ให้กลายเป็นช่องโหว่ที่ใช้งานได้

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

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

ด้วยความหวังว่าจะช่วยให้คุณติดตามรายละเอียดระดับสูงได้ง่ายขึ้นหากคุณตัดสินใจอ่านรายงาน ZDI ต่อไปนี้เป็นบทสรุปที่หวังว่าจะไม่ง่ายเกินไปพร้อมขั้นตอนที่แสดงในรายการแบบย้อนกลับ...

…คุณจะได้รู้ล่วงหน้าว่าทำไมเรื่องราวถึงเป็นไปตามทิศทางของมัน:

• ขั้นตอนที่ 4 หลอก Exchange จากระยะไกลให้สร้างอินสแตนซ์วัตถุ .NET ที่คุณเลือกด้วยพารามิเตอร์การเริ่มต้นที่คุณเลือก

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

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

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

โดยปกติแล้ว คุณต้องส่งพารามิเตอร์อย่างน้อยหนึ่งพารามิเตอร์เป็นอาร์กิวเมนต์ไปยังคอนสตรัคเตอร์ เพื่อระบุว่าคุณต้องการให้กำหนดค่าออบเจกต์อย่างไรเมื่อเริ่มใช้งาน

พูดง่ายๆ ถ้าคุณยกตัวอย่าง เช่น ก TextString วัตถุ (เรากำลังสร้างชื่อเหล่านี้ แต่คุณเข้าใจแล้ว) โดยใช้พารามิเตอร์ที่เป็นสตริงข้อความเช่น example.com:8888...

…คุณอาจจะลงเอยด้วยหน่วยความจำบัฟเฟอร์ที่จัดสรรเพื่อเก็บข้อความของคุณ เริ่มต้นเพื่อให้มันเก็บค่าเดียวกับที่คุณป้อน นั่นคือข้อความดิบ example.com:8888.

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

แต่ถ้าจะให้ยกตัวอย่างก็ว่าก ConnectedTCPClient วัตถุโดยใช้พารามิเตอร์สตริงข้อความเดียวกันของ example.com:8888คุณอาจจบลงด้วยบัฟเฟอร์หน่วยความจำที่พร้อมจะเก็บข้อมูลชั่วคราว พร้อมด้วยซ็อกเก็ตเครือข่ายที่จัดสรรโดยระบบปฏิบัติการที่พร้อมจะแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์ example.com ผ่านพอร์ต TCP 8888.

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

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

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

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

ตามทฤษฎีแล้ว เฉพาะวัตถุที่ปลอดภัยหรือมีความเสี่ยงต่ำเท่านั้นที่สามารถสร้างจากระยะไกลผ่าน PowerShell เพื่อจำลองจินตนาการของเรา TextString ข้างต้น หรือ ก SimpleIntegerValueอาจถือว่ายอมรับได้ ในขณะที่ ก ConnectedTCPClient หรือ RunCmdAndReadOutput คงจะไม่ใช่แน่ๆ

แต่นักวิจัยของ ZDI สังเกตเห็นว่าก่อนที่จะทริกเกอร์ขั้นตอนสุดท้าย พวกเขาสามารถทำสิ่งนี้ได้:

• ขั้นตอนที่ 3 หลอก Exchange จากระยะไกลให้คิดว่าวัตถุที่มีความเสี่ยงต่ำซึ่งผ่านการทดสอบความปลอดภัยแล้ว จริงๆ แล้วเป็นวัตถุอื่นๆ ที่คุณเลือก

ถึงกระนั้น คุณอาจคาดหวังให้ Exchange ป้องกันการสร้างจากระยะไกลแม้กระทั่งวัตถุที่มีความเสี่ยงต่ำ เพื่อลดภัยคุกคามให้น้อยที่สุด

แต่นักวิจัยพบว่าพวกเขาสามารถ:

• ขั้นตอนที่ 2 หลอก Exchange ให้ใช้งานจากระยะไกล PowerShell Remoting คุณสมบัติในการสร้างวัตถุตามพารามิเตอร์เริ่มต้นที่ควบคุมจากภายนอก

และนั่นเป็นไปได้เนื่องจากรูที่เหมือน ProxyShell ซึ่งมีการปะติดปะต่อเพียงกึ่งเดียว:

• ขั้นตอนที่ 1. หลอก Exchange จากระยะไกลให้ยอมรับและประมวลผลคำขอเว็บด้วยรหัสโดยการบรรจุที่ถูกต้อง username:password ลงในคำขอด้วย

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

พูดหลวม ๆ ใด ๆ ที่ถูกต้อง username:password ชุดค่าผสมจะทำ เนื่องจากจำเป็นต้องมี "การรับรองความถูกต้อง" เพื่อป้องกันไม่ให้ Exchange ปฏิเสธคำขอ HTTP ล่วงหน้า

จะทำอย่างไร?

โปรดทราบว่าการโจมตีนี้ใช้งานได้เฉพาะ:

• หากคุณมีเซิร์ฟเวอร์ Exchange ภายในองค์กร Microsoft อ้างว่าได้ล็อคบริการคลาวด์ของตัวเองอย่างรวดเร็ว ดังนั้น Exchange Online จะไม่ได้รับผลกระทบ ตรวจสอบให้แน่ใจว่าคุณ รู้ว่าเซิร์ฟเวอร์ Exchange ของคุณอยู่ที่ไหน. แม้ว่าตอนนี้คุณใช้ Exchange Online คุณอาจยังมีเซิร์ฟเวอร์ในองค์กรทำงานอยู่ ซึ่งอาจหลงเหลือจากกระบวนการย้ายข้อมูลโดยไม่ได้ตั้งใจ
• หากเซิร์ฟเวอร์ของคุณไม่ได้แพตช์ ให้แน่ใจว่าคุณมี ใช้การอัปเดตซอฟต์แวร์ Exchange ของ 2022-11-08 ไปยัง ปิดช่องโหว่ ที่ผู้แสวงประโยชน์ต้องการ
• หากเซิร์ฟเวอร์ของคุณยังคงยอมรับการรับรองความถูกต้องพื้นฐาน หรือที่เรียกว่าการรับรองความถูกต้องแบบเดิม ให้แน่ใจว่าคุณมี บล็อกทุกแง่มุมของการรับรองความถูกต้องแบบดั้งเดิม ดังนั้นเซิร์ฟเวอร์ของคุณจะไม่ยอมรับ username:password ส่วนหัวที่กล่าวถึงข้างต้น และจะไม่ยอมรับคำขอโปรโตคอล Autodiscover ที่มีความเสี่ยงตั้งแต่แรก นี้ หยุดการโจมตี หลอกให้เซิร์ฟเวอร์ยอมรับกลอุบายการสร้างอินสแตนซ์ออบเจกต์ที่ติดกับดัก แม้ว่าเซิร์ฟเวอร์นั้นจะไม่ได้รับการติดตั้งแพตช์ก็ตาม

คุณสามารถ ติดตาม จากคำแนะนำในการป้องกัน การแก้ไข และการตอบสนองอย่างเป็นทางการของเรา และลูกค้าของ Sophos สามารถติดตามชื่อการตรวจจับภัยคุกคามที่ใช้โดยผลิตภัณฑ์ของเราได้ผ่านทางฟีด Twitter ของ Sophos X-Ops (@SphosXOps).

มีการเผยแพร่ข้อมูลใหม่เกี่ยวกับ CVE-2022-41040 และ CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) November 21, 2022

---

เรียนรู้เพิ่มเติมเกี่ยวกับการตรวจสอบการแลกเปลี่ยนและ OAUTH2

กับ Paul Ducklin และ Chester Wisniewski
เพลงอินโทรและเอาท์โดย อีดิธ มัดจ์.

---