ช่องโหว่ความปลอดภัย ASP.NET ใหม่นี้ร้ายแรงเพียงใดและฉันจะแก้ไขได้อย่างไร

ฉันเพิ่งอ่านเกี่ยวกับช่องโหว่ความปลอดภัยที่ค้นพบใหม่ใน ASP.NET คุณสามารถอ่านรายละเอียดได้ที่นี่

ปัญหาอยู่ในลักษณะที่ ASP.NET ใช้อัลกอริทึมการเข้ารหัส AES เพื่อปกป้องความสมบูรณ์ของคุกกี้ที่แอปพลิเคชันเหล่านี้สร้างขึ้นเพื่อเก็บข้อมูลระหว่างเซสชันผู้ใช้

มันค่อนข้างคลุมเครือ แต่นี่เป็นส่วนที่น่ากลัวกว่า:

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

โดยรวมแล้วฉันไม่คุ้นเคยกับเรื่องความปลอดภัย / การเข้ารหัสลับที่จะรู้ว่านี่เป็นเรื่องที่ร้ายแรงหรือไม่

ดังนั้นนักพัฒนา ASP.NET ทุกคนควรกลัวเทคนิคนี้ที่สามารถเป็นเจ้าของเว็บไซต์ ASP.NET ใด ๆ ในไม่กี่วินาทีหรืออะไร

ปัญหานี้ส่งผลกระทบต่อนักพัฒนา ASP.NET โดยเฉลี่ยอย่างไร มันส่งผลกระทบต่อพวกเราหรือไม่? ในชีวิตจริงสิ่งที่เป็นผลมาจากช่องโหว่นี้คืออะไร? และในที่สุด: มีวิธีแก้ไขบางอย่างที่ป้องกันช่องโหว่นี้หรือไม่?

ขอบคุณสำหรับคำตอบ!

แก้ไข: ฉันขอสรุปคำตอบที่ฉันได้รับ

ดังนั้นนี่คือการโจมตีแบบ "ช่องว่างภายใน" @Sriให้คำอธิบายที่ดีเกี่ยวกับการโจมตีประเภทนี้หมายความว่าอย่างไร นี่คือวิดีโอที่น่าตกใจเกี่ยวกับปัญหานี้!

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

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

นี่เป็นแนวทางปฏิบัติที่ดีที่ฉันได้รับซึ่งไม่ได้แก้ปัญหา แต่ช่วยปรับปรุงความปลอดภัยทั่วไปของเว็บแอปพลิเคชัน

• คุณสามารถเข้ารหัสข้อมูลที่สำคัญได้ด้วย Protected Configuration
• ใช้คุกกี้ HTTP เท่านั้น
• ป้องกันการโจมตี DoS

ทีนี้เรามาดูเรื่องนี้กันดีกว่า

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

การแก้ไขปัญหา

• เปิดใช้งาน customErrors และสร้างหน้าข้อผิดพลาดเดียวซึ่งมีการเปลี่ยนเส้นทางข้อผิดพลาดทั้งหมด ใช่404 แม้กระทั่ง (ScottGu กล่าวว่าความแตกต่างระหว่าง 404 และ 500 มีความจำเป็นสำหรับการโจมตีนี้.) นอกจากนี้ยังลงของคุณApplication_ErrorหรือError.aspxใส่รหัสบางอย่างที่ทำให้ล่าช้าสุ่ม (สร้างตัวเลขสุ่มและใช้ Thread.Sleep เพื่อหลับนานขนาดนั้น) สิ่งนี้จะทำให้ผู้โจมตีไม่สามารถตัดสินใจได้ว่าเกิดอะไรขึ้นบนเซิร์ฟเวอร์ของคุณ
• บางคนแนะนำให้เปลี่ยนกลับเป็น 3DES ในทางทฤษฎีหากคุณไม่ใช้ AES คุณจะไม่พบจุดอ่อนด้านความปลอดภัยในการใช้งาน AES ตามที่ปรากฏออกมาสิ่งนี้ไม่แนะนำเลย

ความคิดอื่น ๆ

• ดูเหมือนว่าทุกคนไม่ คิดว่าวิธีแก้ปัญหานั้นดีพอ

ขอบคุณทุกคนที่ตอบคำถามของฉัน ฉันได้เรียนรู้มากมายเกี่ยวกับปัญหานี้ไม่เพียง แต่ความปลอดภัยของเว็บโดยทั่วไป ฉันทำเครื่องหมายคำตอบของ @ Mikael ว่ายอมรับแล้ว แต่คำตอบอื่น ๆ ก็มีประโยชน์มาก

ฉันควรทำอย่างไรเพื่อป้องกันตัวเอง

[อัพเดท 2010-09-29]

กระดานข่าวความปลอดภัยของ Microsoft

บทความ KB ที่มีการอ้างอิงถึงการแก้ไข

ScottGuมีลิงค์สำหรับดาวน์โหลด

[อัพเดท 2010-09-25]

ในขณะที่เรากำลังรอการแก้ไขเมื่อวานนี้ ScottGu จะโพสต์อัปเดตเกี่ยวกับวิธีเพิ่มขั้นตอนพิเศษเพื่อปกป้องไซต์ของคุณด้วยกฎ URLScan ที่กำหนดเอง

นอกจากนี้เพิ่มการสุ่มเวลาพักในหน้าข้อผิดพลาดเพื่อป้องกันไม่ให้ผู้โจมตีจากการกำหนดเวลาการตอบสนองสำหรับข้อมูลการโจมตีที่เพิ่มขึ้น

ใน web.config

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

การดำเนินการนี้จะเปลี่ยนเส้นทางข้อผิดพลาดไปยังหน้าเว็บที่กำหนดเองที่ส่งคืนพร้อมรหัสสถานะ 200 วิธีนี้ผู้โจมตีไม่สามารถดูรหัสข้อผิดพลาดหรือข้อมูลข้อผิดพลาดสำหรับข้อมูลที่จำเป็นสำหรับการโจมตีเพิ่มเติม

นอกจากนี้ยังปลอดภัยในการตั้งค่าcustomErrors mode="RemoteOnly"เนื่องจากจะเป็นการเปลี่ยนเส้นทางลูกค้า "ของจริง" การเรียกดูจาก localhost เท่านั้นที่จะแสดงข้อผิดพลาด. Net ภายใน

ส่วนที่สำคัญคือการตรวจสอบให้แน่ใจว่าข้อผิดพลาดทั้งหมดได้รับการกำหนดค่าให้ส่งคืนหน้าข้อผิดพลาดเดียวกัน สิ่งนี้ต้องการให้คุณตั้งค่าdefaultRedirectแอตทริบิวต์อย่างชัดเจนใน<customErrors>ส่วนและตรวจสอบให้แน่ใจว่าไม่มีการตั้งรหัสต่อสถานะ

อะไรคือความเสี่ยง

หากผู้โจมตีจัดการเพื่อใช้ประโยชน์ดังกล่าวเขา / เธอสามารถดาวน์โหลดไฟล์ภายในจากภายในเว็บแอปพลิเคชันของคุณ โดยทั่วไป web.config เป็นเป้าหมายและอาจมีข้อมูลที่ละเอียดอ่อนเช่นข้อมูลการเข้าสู่ระบบในสตริงการเชื่อมต่อฐานข้อมูลหรือแม้กระทั่งลิงก์ไปยังฐานข้อมูล sql-express อัตโนมัติซึ่งคุณไม่ต้องการให้ใครมาจับ แต่หากคุณปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดคุณจะใช้Protected Configurationเพื่อเข้ารหัสข้อมูลที่สำคัญทั้งหมดใน web.config ของคุณ

ลิงก์ไปยังการอ้างอิง

อ่านความคิดเห็นอย่างเป็นทางการของไมโครซอฟท์เกี่ยวกับช่องโหว่ที่http://www.microsoft.com/technet/security/advisory/2416728.mspx โดยเฉพาะส่วน "การแก้ปัญหา" สำหรับรายละเอียดการใช้งานเกี่ยวกับปัญหานี้

ข้อมูลบางอย่างในบล็อกของ ScottGuรวมถึงสคริปต์เพื่อค้นหาแอป ASP.Net ที่มีช่องโหว่บนเว็บเซิร์ฟเวอร์ของคุณ

สำหรับคำอธิบายเกี่ยวกับ "การทำความเข้าใจการโจมตี Padding ออราเคิล" อ่าน@ คำตอบของศรี

ความคิดเห็นต่อบทความ:

การโจมตีที่ Rizzo และ Duong ได้นำมาใช้กับแอพ ASP.NET ต้องการให้ crypto implement บนเว็บไซต์มี oracle ที่เมื่อส่ง ciphertext จะไม่เพียงถอดรหัสข้อความเท่านั้น แต่ให้ผู้ส่งข้อความว่า padding ใน ciphertext นั้น ถูกต้อง

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

เพื่อให้การโจมตีเพื่อทำงานต่อไปนี้ต้องเป็นจริง:

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

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

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

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

มันจะน่าสนใจที่จะเห็นสิ่งที่นำเสนอจริงในการประชุม Ekoparty แต่ตอนนี้ฉันไม่กังวลเกี่ยวกับช่องโหว่นี้

ทำความเข้าใจกับ Padding การโจมตีของออราเคิล

ให้สมมติว่าแอปพลิเคชันของคุณยอมรับสตริงที่เข้ารหัสเป็นพารามิเตอร์ - ไม่ว่าพารามิเตอร์จะเป็นคุกกี้, พารามิเตอร์ url หรืออย่างอื่นนั้นไม่มีสาระสำคัญ เมื่อแอปพลิเคชันพยายามที่จะถอดรหัสมันมี 3 ผลลัพธ์ที่เป็นไปได้ -

1. ผลลัพธ์ 1 : สตริงที่เข้ารหัสถอดรหัสอย่างถูกต้องและแอปพลิเคชันก็สามารถเข้าใจได้ ความหมายถ้าสตริงที่เข้ารหัสเป็นหมายเลขบัญชี 10 หลักหลังจากถอดรหัสแอปพลิเคชันพบบางอย่างเช่น "1234567890" และไม่ใช่ "abcd1213ef"

2. ผลลัพธ์ที่ 2 : ช่องว่างภายในถูกต้อง แต่หลังจากถอดรหัสสตริงที่ได้รับนั้นไม่มีความหมายว่าแอพไม่เข้าใจ ตัวอย่างเช่นสตริงถอดรหัสเป็น "abcd1213ef" แต่แอปคาดว่าจะมีเพียงตัวเลขเท่านั้น แอพส่วนใหญ่จะแสดงข้อความเช่น "หมายเลขบัญชีไม่ถูกต้อง"

3. ผลลัพธ์ที่ 3 : ช่องว่างภายในไม่ถูกต้องและแอปพลิเคชันเกิดข้อผิดพลาดบางอย่าง แอพส่วนใหญ่จะแสดงข้อความทั่วไปเช่น "เกิดข้อผิดพลาดบางอย่าง"

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

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

สิ่งที่สามารถทำได้เพื่อป้องกันมัน?

1. สิ่งที่ง่ายที่สุด - สิ่งที่ละเอียดอ่อนไม่ควรถูกส่งไปยังลูกค้าเข้ารหัสหรือไม่เข้ารหัส เก็บไว้บนเซิร์ฟเวอร์

2. ตรวจสอบให้แน่ใจว่าผลลัพธ์ที่ 2 และผลลัพธ์ที่ 3 ในรายการด้านบนปรากฏอย่างเดียวกันกับผู้โจมตี ไม่ควรมีวิธีการคิดออกจากที่อื่น นี่ไม่ใช่เรื่องง่ายนัก - ผู้โจมตีสามารถแยกแยะได้โดยใช้การโจมตีแบบจับเวลา

3. เพื่อเป็นการป้องกันบรรทัดสุดท้ายให้ใช้ Web Application Firewall การโจมตีของช่องว่างภายในจำเป็นต้องส่งคำขอหลายคำขอที่มีลักษณะใกล้เคียงกัน (เปลี่ยนทีละหนึ่งบิต) ดังนั้นจึงเป็นไปได้ที่ WAF จะสามารถจับและบล็อกคำขอดังกล่าวได้

ป.ล. คำอธิบายที่ดีของ Padding การโจมตี Oracle สามารถพบได้ในโพสต์บล็อกนี้ คำเตือน: มันไม่ใช่บล็อกของฉัน

จากสิ่งที่ฉันอ่านจนถึงตอนนี้ ...

การโจมตีอนุญาตให้ใครบางคนถอดรหัสคุกกี้ที่ดมกลิ่นซึ่งอาจมีข้อมูลที่มีค่าเช่นยอดคงเหลือในธนาคาร

พวกเขาต้องการคุกกี้เข้ารหัสของผู้ใช้ที่ได้เข้าสู่ระบบแล้วในบัญชีใด ๆ พวกเขายังต้องการค้นหาข้อมูลในคุกกี้ - ฉันหวังว่านักพัฒนาจะไม่เก็บข้อมูลสำคัญในคุกกี้ :) และมีวิธีที่ฉันมีด้านล่างไม่ให้เก็บข้อมูล asp.net ในคุกกี้การเข้าสู่ระบบ

ใครบางคนจะได้รับคุกกี้ของผู้ใช้ที่ออนไลน์ถ้าเขาไม่ได้รับข้อมูลเบราว์เซอร์? หรือสูดดมแพ็คเก็ต IP

วิธีหนึ่งในการป้องกันที่ไม่อนุญาตให้คุกกี้ขนส่งโดยไม่มีการเข้ารหัส ssl

<httpCookies httpOnlyCookies="true" requireSSL="true" />

อีกมาตรการหนึ่งคือการป้องกันการเก็บบทบาทในคุกกี้

<roleManager enabled="true" cacheRolesInCookie="false">

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

การอ้างอิง:
แฮกเกอร์บางคนสามารถขโมยคุกกี้จากผู้ใช้และเข้าสู่ระบบด้วยชื่อนั้นบนเว็บไซต์ได้หรือไม่?

วิธีการตรวจสอบจากที่การโจมตีมาและไม่ให้ข้อมูลกลับ ฉันเขียนที่นี่วิธีง่ายๆในการป้องกันการขยายไม่ถูกต้องและการเข้าสู่ระบบในเวลาเดียวกันเพื่อติดตามผู้โจมตี: CryptographicException: การขยายไม่ถูกต้องและไม่สามารถลบออกได้และการตรวจสอบความถูกต้องของ viewstate MAC ล้มเหลว

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

อัปเดต 1

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

หากมีคนพยายามใช้เครื่องมือนี้หรือวิธีนี้รหัสด้านบนสามารถติดตามพวกเขาลงและคุณสามารถบล็อกพวกเขาออกจากหน้าของคุณด้วยรหัสง่าย ๆ เช่นนี้"ป้องกันการปฏิเสธการบริการ (DOS)"หรือชอบรหัสนี้เพื่อป้องกันการปฏิเสธ ในการให้บริการ

อัปเดต 2

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

วิดีโอที่น่าสนใจมากในเรื่องนี้

ดังนั้นสิ่งที่กล่าวมาทั้งหมดข้างต้นเป็นมาตรการเพิ่มเติมสำหรับการป้องกันเพิ่มเติม แต่ไม่จำเป็น 100% สำหรับปัญหาเฉพาะนี้ ตัวอย่างเช่นการใช้คุกกี้ SSL คือการแก้ปัญหา snif การไม่แคชบทบาทในคุกกี้เป็นการดีที่จะไม่ส่งและรับคุกกี้ขนาดใหญ่กลับมาและเพื่อหลีกเลี่ยงคุกกี้ที่มีรหัสพร้อมสำหรับการถอดรหัส คุกกี้ของเขา

วิวสเตทติดตามการวัดมากกว่าหนึ่งเพื่อหาการโจมตี

นี่คือการตอบสนองของ MS ทุกอย่างลงไปที่ "ใช้หน้าข้อผิดพลาดที่กำหนดเอง" และคุณจะไม่แจกเบาะแส

แก้ไข
นี่คือข้อมูลรายละเอียดเพิ่มเติมจาก scottgu

การเพิ่มการตอบสนองของ ScottGu จากการสนทนาที่http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

IHttpModule แบบกำหนดเองแทนที่จะได้รับผลกระทบจาก customErrors หรือไม่

ถาม: ฉันไม่ได้ประกาศองค์ประกอบไว้ใน web.config ฉันมี IHttpModule แทนในส่วน โมดูลนี้บันทึกข้อผิดพลาดและเปลี่ยนเส้นทางไปยังหน้าการค้นหา (สำหรับ 404) หรือหน้าข้อผิดพลาด (สำหรับ 500) ฉันกำลังเสี่ยงไหม

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

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

ฉันสามารถใช้ข้อผิดพลาดต่าง ๆ สำหรับข้อผิดพลาด 404 และ 500 ต่อไปได้หรือไม่

ถาม: ฉันรับไปแล้วเรายังคงสามารถกำหนดหน้าเว็บ 404 ที่กำหนดเองนอกเหนือจากการเปลี่ยนเส้นทางเริ่มต้นเมื่อเกิดข้อผิดพลาดโดยไม่ละเมิดหลักการที่อธิบายไว้ข้างต้น

ตอบ: ไม่ - จนกว่าเราจะปล่อยโปรแกรมแก้ไขสำหรับการแก้ไขจริงเราขอแนะนำวิธีแก้ปัญหาข้างต้นซึ่งทำให้ข้อผิดพลาดทั้งหมดสอดคล้องกัน อีกวิธีหนึ่งในการโจมตีนี้คือการค้นหาความแตกต่างระหว่างข้อผิดพลาด 404 และ 500 การส่งคืนรหัส HTTP เดียวกันเสมอและส่งไปยังสถานที่เดียวกันเป็นวิธีหนึ่งในการช่วยบล็อก

โปรดทราบว่าเมื่อโปรแกรมแก้ไขออกมาเพื่อแก้ไขปัญหานี้คุณไม่จำเป็นต้องทำสิ่งนี้ (และสามารถเปลี่ยนกลับเป็นพฤติกรรมเดิมได้) แต่สำหรับตอนนี้คุณไม่ควรแยกความแตกต่างระหว่าง 404 และ 500 กับลูกค้า

สิ่งนี้จะช่วยให้การเปิดรับของเว็บ config

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

ตอบ: การโจมตีที่ปรากฏในที่สาธารณะนั้นขึ้นอยู่กับฟีเจอร์ใน ASP.NET ที่อนุญาตให้ดาวน์โหลดไฟล์ (โดยทั่วไปคือ javascript และ css) และมีการรักษาความปลอดภัยด้วยรหัสที่ส่งมาเป็นส่วนหนึ่งของคำขอ น่าเสียดายถ้าคุณสามารถสร้างรหัสคุณสามารถใช้คุณสมบัตินี้เพื่อดาวน์โหลดไฟล์ web.config ของแอปพลิเคชัน (แต่ไม่ใช่ไฟล์ที่อยู่นอกแอปพลิเคชัน) เห็นได้ชัดว่าเราจะปล่อยแพทช์สำหรับเรื่องนี้ - จนกว่าจะถึงวิธีแก้ปัญหาข้างต้นปิดเวกเตอร์การโจมตี

แก้ไข: คำถามที่พบบ่อยเพิ่มเติมมีอยู่ในบล็อกที่สองที่http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-abest-the-asp-net-security-vulnerability.aspx

IMO ไม่มีการป้องกันทั่วกระดานสำหรับเรื่องนี้จำเป็นต้องได้รับการจัดการเป็นกรณี ๆ ไป:

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

ลิงค์สำคัญสองสามข้อ:

• MS 'Security Advisory 2416728 (นี่คือข้อมูลอย่างเป็นทางการ)
• ข้อมูลเพิ่มเติมจาก MS 'Security Research & Defense ทีม
  • "การทำความเข้าใจช่องโหว่ ASP.NET" (2010-09-17)
  • "ข้อมูลเพิ่มเติมเกี่ยวกับช่องโหว่ ASP.NET" (2010-09-20)
• Scott Gu: "สำคัญ: ช่องโหว่ความปลอดภัยของ ASP.NET" (2010-09-18)

[เพื่อตอบคำถามที่จริงจังนี้ (สิ่งที่ได้รับการเผยแพร่และคำตอบอื่น ๆ ได้รับการคุ้มครอง)]

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

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

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

แน่นอนว่าเป็นคีย์ที่สร้างขึ้นใหม่ฉันใช้ PowerShell ต่อไปนี้เพื่อเข้าถึงตัวสร้างตัวเลขแบบเข้ารหัสของ Windows:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(ใช้ความยาวของอาร์เรย์ 20 สำหรับการตรวจสอบและ 16 สำหรับคีย์ถอดรหัส)

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

[แก้ไข 2010-09-21: เพิ่มลิงค์ไปด้านบน]

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

แค่ต้องการให้ข้อเท็จจริงตรงๆ:

1. การโจมตีไม่อนุญาตให้คุณรับรหัสเครื่องโดยตรง ที่กล่าวว่ามันค่อนข้างคล้ายกับมันเพราะช่วยให้ถอดรหัสข้อความและแก้ไขใหม่ / เข้ารหัสใหม่
2. วิธีที่จะได้รับคีย์ที่แท้จริงคือการใช้ความสามารถในการแก้ไขใหม่ / เข้ารหัสเช่นเดียวกับใน 1 และรับ web.config น่าเสียดายที่มีเหตุผลว่าทำไมบางคนใส่คีย์เหล่านี้ใน web.config ที่ระดับเว็บไซต์ (การสนทนาที่แตกต่างกัน) และในวิดีโอตัวอย่างพวกเขาได้รับประโยชน์จากการเป็นค่าเริ่มต้นของ DotnetNuke
3. เพื่อให้ web.config ชี้ให้เห็นว่าพวกเขาใช้ webresources.axd และ / หรือ scriptresources.axd ฉันคิดว่าสิ่งเหล่านี้ทำงานได้เฉพาะกับทรัพยากรที่ฝังตัว แต่ดูเหมือนว่าไม่ใช่กรณี
4. หากแอปเป็น asp.net MVC เราไม่จำเป็นต้องใช้ webresources.axd และ / หรือ scriptresources.axd จริงๆดังนั้นจึงสามารถปิดได้ นอกจากนี้เรายังไม่ใช้มุมมอง ที่กล่าวว่ามันไม่ชัดเจนสำหรับฉันถ้ามีคุณสมบัติ asp.net อื่น ๆ ให้ข้อมูลที่แตกต่างกับวิธีแก้ปัญหาในสถานที่เช่นฉันไม่รู้ว่าการแพ็ดดิ้งให้ผลลัพธ์ที่ไม่ถูกต้องในข้อผิดพลาดในขณะที่ padding หากเป็นกรณีนี้หรือไม่) ... การวิเคราะห์เดียวกันควรนำไปใช้กับคุกกี้เซสชัน
5. บทบาท 'แคช' ของผู้ให้บริการสมาชิก asp.net ในคุกกี้ให้ปิดใช้งาน

ประมาณ 1, afaik ข้อความที่เข้ารหัสไม่สามารถ 100% โดยพลการต้องยอมให้ขยะชิ้นเล็ก ๆ ในข้อความเพราะมี 1 บล็อกในข้อความที่ถอดรหัสค่าที่ไม่สามารถควบคุมได้

ในที่สุดฉันอยากจะบอกว่าปัญหานี้เป็นผลมาจาก ms ไม่ปฏิบัติตามคำแนะนำของตัวเองในกรณีนี้: คุณสมบัติอาศัยสิ่งที่ส่งไปยังลูกค้าเพื่อพิสูจน์การงัดแงะ

เพิ่มเติมเกี่ยวกับ:

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

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

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

โปรแกรมแก้ไขสำหรับข้อบกพร่องนี้เผยแพร่ใน Windows Update: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Asp.Net MVC ได้รับผลกระทบจากปัญหานี้เช่นเดียวกับ Sharepoint, ...

ฉันได้ครอบคลุมการแก้ไขสำหรับ MVC ที่นี่: ASP.NET MVC มีความเสี่ยงต่อการโจมตีของ Oracle หรือไม่?