Mestercoputer

وقتی سرور خودش جواب سؤال هکر را می‌دهد؛ بررسی واقعی Padding Oracle در ASP.NET

گاهی یک آسیب‌پذیری لازم نیست RCE بدهد، shell باز کند یا صفحه‌ی whoami را روی سرور چاپ کند تا خطرناک باشد.
بعضی وقت‌ها خود سرور تبدیل می‌شود به یک «راهنما» برای مهاجم.
هر بار مهاجم یک ciphertext دستکاری‌شده می‌فرستد، سرور با نوع پاسخ، خطا یا رفتار متفاوتش یک تکه اطلاعات به او می‌دهد.
بعد مهاجم همین کار را بارها و بارها تکرار می‌کند.
و کم‌کم چیزی که قرار بود «رمزنگاری‌شده و غیرقابل خواندن» باشد، دیگر آن‌قدر هم غیرقابل خواندن نیست.

بعضی وقت‌ها خود سرور تبدیل می‌شود به یک «راهنما» برای مهاجم.

هر بار مهاجم یک ciphertext دستکاری‌شده می‌فرستد، سرور با نوع پاسخ، خطا یا رفتار متفاوتش یک تکه اطلاعات به او می‌دهد.

بعد مهاجم همین کار را بارها و بارها تکرار می‌کند.

و کم‌کم چیزی که قرار بود «رمزنگاری‌شده و غیرقابل خواندن» باشد، دیگر آن‌قدر هم غیرقابل خواندن نیست.

اسم این تکنیک:

Padding Oracle Attack

و در این مقاله می‌ریم سراغ یکی از نمونه‌های معروفش:

CVE-2010-3332 — ASP.NET Padding Oracle

این CVE سال‌هاست شناخته شده، اما هنوز هم برای فهمیدن یک اصل خیلی مهم در امنیت وب عالیه:

رمزنگاری قوی به‌تنهایی کافی نیست؛ نحوه‌ی استفاده از رمزنگاری هم باید درست باشد.

بیا ادامه مطلب 

اول از همه: Padding Oracle اصلاً یعنی چی؟

بذار خیلی کتابی توضیحش ندیم.

فرض کن سرور یک داده را رمزنگاری کرده و یک ciphertext در اختیار مرورگر قرار گرفته.

حالا مهاجم ciphertext را کمی تغییر می‌دهد و دوباره برای سرور می‌فرستد.

اگر سرور در جواب تفاوتی بین حالت‌های مختلف ایجاد کند، مثلاً:

یک خطای خاص

یک status code متفاوت

یک صفحه‌ی خطای متفاوت

یا حتی تفاوت قابل اندازه‌گیری در زمان پاسخ

همین تفاوت کوچک می‌تواند تبدیل به یک Oracle شود.

Oracle یعنی چیزی که به سؤال‌های مهاجم جواب می‌دهد.

مهاجم سؤال را مستقیم نمی‌پرسد:

«این plaintext چیست؟»

چون سرور احتمالاً همچین جوابی نمی‌دهد.

در عوض سؤال را غیرمستقیم می‌پرسد:

«اگر این ciphertext را این‌طوری تغییر بدهم، padding معتبر می‌شود یا نه؟»

و سرور، بدون اینکه بفهمد چه بلایی سر خودش آورده، جواب می‌دهد.

یک جورایی سرور تبدیل می‌شود به همان دوستی که قرار بود رازت را نگه دارد ولی با حالت صورتش لو می‌دهد قضیه چیست :))

CVE-2010-3332 دقیقاً چه بود؟

در CVE-2010-3332، مشکل در ASP.NET به نحوه‌ی پردازش و گزارش خطا هنگام بررسی padding مربوط بود.

Microsoft توضیح داده که مهاجم می‌توانست با ارسال ciphertextهای دستکاری‌شده و بررسی پاسخ‌های متفاوت سرور، اطلاعاتی درباره‌ی فرآیند decrypt به دست بیاورد.

این موضوع می‌توانست برای خواندن داده‌های رمزنگاری‌شده و همچنین دستکاری آن‌ها استفاده شود. در .NET Framework 3.5 SP1 و نسخه‌های بعدی، Microsoft همچنین توضیح داده که این تکنیک می‌توانست برای بازیابی محتوای فایل‌های داخل ASP.NET application، از جمله web.config، مورد استفاده قرار بگیرد.

یک نکته مهم:

این آسیب‌پذیری به‌صورت مستقیم:

RCE نیست.

و به‌صورت مستقیم:

Privilege Escalation نیست.

خود Microsoft هم صراحتاً همین را گفته است.

اما اطلاعاتی که از این مرحله به دست می‌آید می‌تواند برای compromise مرحله‌های بعدی استفاده شود.

پس اگر کسی گفت:

«Padding Oracle یعنی مستقیم shell می‌گیری»

نه.

این‌قدر هم فیلم هکری نیست :))

مسیر واقعی معمولاً این شکلی است:

Oracle → Decryption → Information Disclosure → احتمالاً Credential/Configuration Disclosure → احتمالاً حمله‌ی بعدی

مرحله‌های بعدی کاملاً به معماری و تنظیمات همان برنامه بستگی دارند.

داستان تست ما روی سامانه دانشگاه

این تست روی سامانه دانشگاه سناباد گلبهار انجام دادیم و طبق مجوزی که در اختیار دارم، تست با اجازه‌ی پشتیبانی و آموزش دانشگاه انجام شده است.

هدف تست هم قرار نبود «بریم سایت رو بترکونیم».

هدف این بود که ببینیم آیا رفتار ASP.NET روی سامانه واقعاً نشانه‌های یک Padding Oracle را دارد یا نه.

یعنی اول:

Detection

بعد:

Validation

و در نهایت:

Responsible Disclosure / Fix

این دقیقاً همان چیزی است که در تست نفوذ حرفه‌ای اهمیت دارد.

مرحله اول؛ پیدا کردن نشانه‌ی Oracle

چیزی که برای ما جالب شد، وجود داده‌های رمزنگاری‌شده‌ای بود که توسط ASP.NET پردازش می‌شدند.

در چنین سناریویی مهاجم دنبال یک ciphertext قابل کنترل می‌گردد.

مثلاً یک مقدار رمزنگاری‌شده که در URL یا پارامتر درخواست دیده می‌شود.

نکته اینجاست که مهاجم لازم نیست بداند داخل ciphertext چیست.

اصلاً قرار نیست از اول بداند.

اتفاقاً کل ایده‌ی Padding Oracle همین است.

او ciphertext را تغییر می‌دهد و پاسخ‌ها را مقایسه می‌کند.

اگر پاسخ‌های معتبر و نامعتبر از نظر status، body، error یا رفتار سرور قابل تشخیص باشند، Oracle شکل می‌گیرد.

OWASP هم Padding Oracle را دقیقاً بر اساس همین نشتی رفتاری توضیح می‌دهد: برنامه در هنگام پردازش ciphertext دستکاری‌شده اطلاعاتی درباره‌ی معتبر بودن padding در اختیار مهاجم قرار می‌دهد.

چرا AES را نمی‌شود فقط مقصر دانست؟
اینجا یک اشتباه رایج وجود دارد.
یکی می‌گوید:
«خب AES که شکسته نشده؟»
نه.
اصلاً مسئله این نیست.
در این حمله، مهاجم قرار نیست AES را brute-force کند.
قرار نیست کلید را حدس بزند.
قرار نیست بنشیند تا بالاخره:
AES_KEY = 123456
در بیاید :))
مشکل از جایی شروع می‌شود که سیستم رمزنگاری‌شده، اطلاعات جانبی در اختیار مهاجم قرار می‌دهد.
Microsoft هم توضیح داده که Padding Oracle می‌تواند بدون دانستن encryption key، امکان decrypt کردن داده را فراهم کند.
یعنی:
Encryption ≠ Authentication
اگر ciphertext فقط encrypted باشد ولی integrity آن به شکل درست بررسی نشود، مهاجم ممکن است بتواند آن را دستکاری کند و از رفتار decryptor اطلاعات استخراج کند.

حمله از دید یک هکر چطور جلو می‌رود؟

فرض کنیم مهاجم یک ciphertext دارد:

C1 | C2 | C3

در CBC mode، plaintext هر بلوک به ciphertext قبلی وابسته است.

به شکل ساده:

P2 = D(C2) XOR C1

حالا اگر مهاجم C1 را دستکاری کند، نتیجه‌ی plaintext مربوط به C2 هم تغییر می‌کند.

مهاجم نمی‌داند D(C2) چیست.

ولی می‌تواند ciphertext قبلی را تغییر بدهد.

بعد درخواست را برای سرور ارسال کند.

اگر سرور با رفتار متفاوتی بگوید:

padding valid

یا:

padding invalid

مهاجم یک بیت اطلاعات به دست آورده.

یک بیت شاید چیز خاصی نباشد.

ولی وقتی این کار بارها تکرار شود، همین بیت‌ها کنار هم قرار می‌گیرند.

و اینجاست که هکر لبخند میزنه و انگشت بزرگشو بهت نشون میده 🧐

Microsoft توضیح می‌دهد که با درخواست‌های متعدد می‌توان اطلاعات کافی برای decrypt کردن ciphertext به دست آورد و سپس plaintext را نیز تغییر داد.

PoC آزمایشگاهی با PadBuster

در یک محیط آزمایشگاهی که (یک دوره قبلا به ورت خصوی یاد داده بودم چجری بسازید و هزینشم کلا ۵۰ هزار تمن بود) یا برای تست آن مجوز دارید، ابزارهایی مثل PadBuster می‌توانند فرآیند Padding Oracle را automate کنند.

ساختار کلی تست:

padbuster "https://LAB-TARGET.example/resource" \
"<CIPHERTEXT>" \
1 \
-encoding 3 \
--error=500

اینجا:

LAB-TARGET

هدف این مرحله پیدا کردن پاسخ متفاوت برای ciphertextهای دستکاری‌شده است.

اگر ابزار بتواند رفتار Oracle را شناسایی کند، وارد مرحله بعد می‌شویم.

مرحله بعد: بررسی قابلیت decrypt

بعد از شناسایی Oracle، PadBuster می‌تواند ciphertext را به شکل سیستماتیک بررسی کند.

در یک آزمایشگاه، نتیجه ممکن است چیزی شبیه این باشد:

Identified Error Response
Identified Block Size
Starting Decryption
...

مهم‌ترین نکته این است که اینجا دیگر بحث «حدس زدن کلید» مطرح نیست.

Oracle دارد اطلاعات لازم برای بازسازی plaintext را فراهم می‌کند.

OWASP هم اشاره می‌کند که در CBC، تغییر ciphertext یک بلوک می‌تواند روی plaintext بلوک بعدی اثر بگذارد و همین ویژگی پایه‌ی حمله است.

برای درک بهتر مطالب یک ویدیو ببینیم 

حالا بخش خطرناک ماجرا

اگر plaintext چیزی بی‌اهمیت باشد، شاید اثر حمله محدود بماند.

مثلاً:

language=fa

theme=dark

page=2

ولی اگر برنامه اطلاعات حساس را داخل داده‌ی رمزنگاری‌شده قرار داده باشد، داستان فرق می‌کند.

مثلاً:

userId

role

session information

internal identifiers

application state

یا در بعضی طراحی‌های قدیمی‌تر:

connection strings

application secrets

machine configuration

البته اینجا یک نکته مهم وجود دارد:

اینکه چنین داده‌ای وجود داشته باشد کاملاً وابسته به برنامه است.

Padding Oracle خودش به‌صورت جادویی credential تولید نمی‌کند.

اگر secret داخل ciphertext یا فایل قابل بازیابی نباشد، چیزی هم برای استخراج وجود ندارد.

چرا web.config مهم!؟ 

در ASP.NET قدیمی، web.config می‌تواند اطلاعات بسیار مهمی درباره‌ی application داشته باشد.

مثلاً بسته به تنظیمات:

connectionStrings
authentication settings
machineKey
application configuration
custom secrets

Microsoft برای CVE-2010-3332 مشخصاً گفته که در .NET Framework 3.5 SP1 و بالاتر، مهاجم می‌توانسته از این آسیب‌پذیری برای بازیابی فایل‌های داخل ASP.NET application، از جمله web.config، استفاده کند.

و اینجا دقیقاً همان جایی است که یک آسیب‌پذیری «Information Disclosure» ممکن است تبدیل به نقطه شروع یک زنجیره‌ی حمله شود.

و این یکی از مهم‌ترین نکته‌های این مقاله است.

CVE-2010-3332 خودش:

RCE = No

Direct Privilege Escalation = No

طبق توضیح Microsoft، این آسیب‌پذیری مستقیماً امکان اجرای کد یا افزایش سطح دسترسی کاربر را ایجاد نمی‌کرد

اما ممکن است اطلاعاتی بدهد که حمله‌ی دیگری را ممکن کند.

مثلاً به‌صورت مفهومی:

Padding Oracle
      ↓
Read encrypted application data
      ↓
Recover sensitive configuratioبرای اثبات کامل impact باید مشخص شود چه plaintextای واقعاً recover شده و چه داده‌ای در معرض disclosure قرار گرفته است.n
      ↓
Discover credentials / secrets
      ↓
Test those credentials against authorized services
      ↓
Potential secondary compromise

مرحله‌ی آخر دیگر خود CVE نیست.

آن یک attack chain جدید است.

پس Privilege Escalation کجاست؟
اینجا باید خیلی دقیق حرف بزنیم.
اگر از web.config مثلاً یک credential به دست بیاید و همان credential در یک سرویس دیگر با دسترسی بالاتر استفاده شده باشد، مهاجم ممکن است بتواند در مرحله‌ی دیگری دسترسی بیشتری بگیرد.
ولی این به معنی:

«Padding Oracle = Privilege Escalation»
نیست.
بلکه:
«Padding Oracle ممکن است اطلاعات لازم برای یک حمله‌ی بعدی را افشا کند.»

اتفاقاً همین تفاوت‌هاست که گزارش امنیتی را از یک متن «هکری‌بازی» جدا می‌کند.

چیزی که در تست دانشگاه برای ما مهم بود

در مستند تست، مسیر آزمایش تا مرحله‌ای پیش رفت که مقدار ciphertext جدید توسط سرور پردازش شد و در پاسخ HTTP دیده شد. نمونه‌ی ثبت‌شده نشان می‌داد مقدار تولیدشده در action یک فرم قرار گرفته است.

این نوع شواهد برای نشان دادن اینکه ciphertext قابل دستکاری و پردازش توسط application است مفید است.

 Padding Oracle سازگار بوده و امکان پردازش ciphertext دستکاری‌شده مشاهده شده است.

برای اثبات کامل impact باید مشخص شود چه plaintextای واقعاً recover شده و چه داده‌ای در معرض disclosure قرار گرفته است.

در گزارش‌های مربوط به CVE-2010-3332، امتیاز CVSS v2 با بردار:

AV:N/AC:L/Au:N/C:P/I:P/A:N

ثبت شده است. NVD این بردار را در سوابق تغییر CVE نشان می‌دهد.

در مستند تست ما هم امتیاز 5.0/10 به عنوان Medium ذکر شده است.

ولی اینجا یک نکته جالب وجود دارد:

CVSS پایین‌تر از چیزی که از اسم «رمزگشایی اطلاعات» انتظار دارید به نظر می‌رسد.

دلیلش این است که CVSS درباره‌ی impact مشخص‌شده در خود آسیب‌پذیری صحبت می‌کند، نه اینکه بگوید مهاجم در تمام معماری‌های ممکن نهایتاً تا کجا می‌تواند پیش برود.

 

پس اگر من مهاجم باشم، دنبال چی می‌گردم؟

در یک تست مجاز، بعد از پیدا کردن Oracle، سوال‌های مهم این‌ها هستند:

آیا ciphertext حاوی اطلاعات حساس است؟

آیا ViewState شامل داده‌ی حساس است؟

آیا application فایل‌هایی دارد که process بتواند بخواند؟

آیا web.config حاوی configuration حساس است؟

آیا secret یا credential در configuration وجود دارد؟

آیا secret در سرویس دیگری reuse شده؟

آیا application با سطح دسترسی بالایی اجرا می‌شود؟

آیا account مورد استفاده application به منابع داخلی دیگری دسترسی دارد؟

اما جواب هیچ‌کدام را نباید از خود CVE حدس زد.

یک نکته خیلی مهم درباره «کلید رمزنگاری»

این را عمداً جدا می‌نویسم چون در خیلی از آموزش‌های اینترنتی اشتباه بیان می‌شود.

Padding Oracle به این معنی نیست که:

Attacker

   ↓

Steals AES key

   ↓

Decrypts everything

نه.

سناریوی کلاسیک بیشتر شبیه این است:

Ciphertext

   ↓

Manipulation

   ↓

Server decrypts

   ↓

Oracle leaks padding validity

   ↓

Repeated queries

   ↓

Plaintext recovery

Microsoft هم می‌گوید این آسیب‌پذیری امکان decrypt و tamper کردن داده‌های رمزنگاری‌شده را بدون اینکه مهاجم الزاماً کلید را در اختیار داشته باشد فراهم می‌کرد.

چرا یک Error Message ساده این‌قدر مهم است؟

چون امنیت همیشه درباره‌ی چیزی که سیستم می‌گوید نیست.

گاهی درباره‌ی چیزی است که سیستم نباید می‌گفت.

مثلاً:

Padding invalid

برای developer شاید فقط یک exception باشد.

برای مهاجم:

YES / NO

است.

و وقتی بتوانی یک سرویس را تبدیل به دستگاه YES/NO کنی، می‌توانی تعداد زیادی سؤال از آن بپرسی.

اینجاست که:

Error Message

تبدیل می‌شود به:

Information Oracle

و همین موضوع یکی از دلایل مهمی است که OWASP توصیه می‌کند خطاهای مربوط به padding یا decrypt به شکل قابل تشخیص برای مهاجم نشت نکنند.

موفق و پیروز باشید 

منابع و رفرنس‌های فنی

Microsoft — MS10-070: ASP.NET Padding Oracle Vulnerability / CVE-2010-3332

مستند اصلی Microsoft درباره آسیب‌پذیری، impact، workaround و نحوه‌ی رفع آن.

Microsoft Security Research & Defense — Understanding the ASP.NET Vulnerability

توضیح فنی Microsoft درباره Oracle، نحوه‌ی استخراج اطلاعات از طریق درخواست‌های متعدد و امکان بازیابی فایل‌های application.

Microsoft — CBC-mode cryptographic vulnerabilities

توضیح مدرن‌تر Microsoft درباره Padding Oracle، CBC، integrity و اهمیت authenticated encryption.

OWASP Web Security Testing Guide — Padding Oracle

راهنمای تست امنیتی OWASP درباره تشخیص و درک Padding Oracle و رفتار CBC.

NVD — CVE-2010-3332

اطلاعات CVE و سابقه‌ی امتیازدهی/بردار CVSS.

گزارش تست مجاز سامانه دانشگاه سناباد

در این تست، طبق مستند ارائه‌شده، بررسی روی سامانه دانشگاه با اجازه‌ی پشتیبانی و آموزش انجام شده و شواهد مربوط به پردازش ciphertext دستکاری‌شده ثبت شده است.