بررسی یک نمونه از آسیب‌پذیری‌های Microsoft Exchange و نتایج آن

بسیاری از سرور‌های Microsoft Exchange نسبت به آسیب‌پذیری معروف با نام‌های ProxyOracle, ProxyLogon, ProxyShell و ProxyToken آسیب‌پذیر هستند و با وجود این که وصله‌های امنیتی منتشر شده است، سرورهای آسیب‌پذیر بسیاری وجود دارند. همچنین با بررسی Microsoft Exchange توسط متخصصین هشت آسیب‌پذیری متفاوت پیدا و از حاصل ترکیب این هشت آسیب‌پذیری سه اکسپلویت معروف با نام‌های زیر معرفی شد:

• ProxyLogon:

معروف‌ترین اکسپلویت که به مهاجم امکان اجرای حمله RCE را می‌دهد.

• ProxyOracle:

این حمله هرگونه رمزعبور را می‌تواند به شکل plaintext برای مهاجم بازیابی کند.

• ProxyShell:

ترکیب زنجیره‌ای آسیب‌پذیری‌ها منجر به ایجاد این روش اکسپلویت شده است که منجر به اجرای حمله RCE روی سرورهای Microsoft Exchange میشود. همچنین آسیب‌پذیری دیگری با عنوان ProxyToken، ضعف خطرناکی در سرور Microsoft Exchange است که به مهاجم ناشناس امکان دسترسی به MailBox قربانی را می‌دهد. در این مقاله به بررسی یک نمونه از این آسیب‌پذیری‌ها(ProxyOracle) می‌پردازیم.

معماری Microsoft Exchange:

بر اساس معماری CAS در Front-end مشخصات کاربر Serialize و به String تبدیل می‌شود و در هدر HTTP کاربر با نام X-CommonAccessToken قرار می‌گیرد و سپس به Back-end ارسال می شود. در ادامه سمت Back-end این سرآیند Deserialize می‌شود. در بخش Outlook Web Access (OWA) از یک رابط گرافیکی برای اجرای فرایند احرازهویت استفاده می‌شود که با نام Form-Based Authentication (FBA) شناخته می‌شود. FBA یکی از ماژول‌های ویژه IIS است که ویژگی ProxyModule را به ارث برده است و مسئول انتقال اطلاعات محرمانه و کوکی، قبل از وارد کردن Proxy Logic است.

مکانیزم FBA:

ریکوئست HTTP پروتکل stateless است و برای اینکه کاربر login بماند، FBA نام‌کاربری و رمزعبور را ذخیره می‌کند. هر بار که کاربر به OWA مراجعه می‌کند، Exchange کوکی را پارس و اطلاعات محرمانه را دریافت و log می‌کند. Exchange اطلاعات هویتی کاربر را serialize و داخل یک string قرار می‌دهد و سپس این اطلاعات در هدر با نام X-CommonAccessToken قرار داده و به back-end ارسال می‌شود. تمام کوکی‌ها رمزنگاری می‌شوند و امکان مشاهده اطلاعات محرمانه به شکل plaintext را ندارد. در FBA پنج مرحله برای رمزنگاری و رمزگشایی وجود دارد:

1. cadata – The encrypted username and password
2. cadataTTL – The Time-To-Live timestamp
3. cadataKey – The KEY for encryption
4. cadataIV – The IV for encryption
5. cadataSig – The signature to prevent tampering

در مرحله اول دو string تصادفی با طول ۱۶ بایت برای نشست در IV و KEY ایجاد می‌شود. سپس نام‌کاربری و رمزعبور با استفاده از Base64 کد گذاری و در ادامه با AES باردیگر رمزنگاری می‌شوند. بعد از این مرحله، کوکی برای کلاینت ارسال و همزمان IV و KEY برای کاربر فرستاده می‌شود. برای‌ جلوگیری از رمزگشایی اطلاعات محرمانه سمت client با اطلاعات از IV و KEY، از الگوریتم RSA برای رمزنگاری دوباره IV و KEY استفاده می‌شود و از طریق اعتبارنامه خصوصی SSL ارسال می‌شود. کد رمزنگاری Pseudo در زیر آورده شده است.

• @key = GetServerSSLCert().GetPrivateKey()
• cadataSig = RSA(@key).Encrypt(“Fba Rocks!”)
• cadataIV = RSA(@key).Encrypt(GetRandomBytes(16))
• cadataKey = RSA(@key).Encrypt(GetRandomBytes(16))
• @timestamp = GetCurrentTimestamp()
• cadataTTL = AES_CBC(cadataKey, cadataIV).Encrypt(@timestamp)
• @blob = “Basic ” + ToBase64String(UserName + “:” + Password)
• cadata = AES_CBC(cadataKey, cadataIV).Encrypt(@blob)

در Exchange از CBC مد padding استفاده می‌شود. اگر با رمزنگاری آشنا باشید باید بدانید که در اینجا آسیب‌پذیری Padding Oracle Attack وجود دارد.

آسیب پذیری ProxyOracle در Microsoft Exchange:

زمانی که بخشی از FBA خطا رخ می‌دهد، Exchange پیام خطا را از طریق ریکوئست redirect به صفحه لاگین هدایت می‌کند. در رمزگشایی کوکی، Exchange از یک حالت استثناء برای گرفتن Padding Error استفاده می‌کند و به دلیل وجود این استثناء برنامه سریعاً کد ۰ به معنای None را برمی‌گرداند:

Location: /OWA/logon.aspx?url=…&reason=0

ولی با وجود Padding Error و رمزگشایی مناسب، Exchange فرایند احرازهویت را ادامه می‌دهد و کاربر را با نام‌کاربری و رمزعبور تغییر یافته login می‌کند. در این حالت کد خطای ۲ برگردانده می‌شود و به معنای InvalidCredentials است. با این تفاوت که از Oracle برای تشخیص رمزگشایی موفق یا ناموفق استفاده می‌شود:

Location: /OWA/logon.aspx?url=…&reason=2

بهتر است بدانیم که IV با SSL رمزنگاری شده است و امکان بازگردانی اولین بلاک متن رمزشده از طریق XOR وجود ندارد. ولی این موضوع مشکلی ایجاد نمی‌کند به این دلیل که سی شارپ در فرایند‌های داخلی stringها را UTF-16 در نظر می‌گیرد. در نتیجه ۱۲ بایت اول باید به شکل زیر باشد:

B\x00a\x00s\x00i\x00c\x00 \x00

با اضافه کردن Base64 اضافه تنها  1.5بایت در فیلد نام‌کاربری از دست می‌رود.

(۱۶-۱۶*۲)/۲*(۳/۴)=۱.۵

این آسیب‌پذیری با شناسه CVE-2021-31196 اجازه رمزگشایی کوکی کاربر را می‌دهد ولی مسأله بعدی پیدا کردن کوکی کاربر است که با استفاده از آسیب‌پذیر XSS با شناسه CVE-2021-31195 در CAS Frontend امکان بدست آوردن کوکی کاربر فراهم می‌شود. کد اکسپلویت به شکل زیر است:

https:// exchange/owa/auth/frowny .aspx

?app=people

&et=ServerError

&esrc=MasterPage

&te=\

&refurl=}}};alert(document.domain)//