همونطور که در خبرها اومده بود، کمپانی 3CX ، اخیرا هدف یه حمله زنجیره تامین قرار گرفته بود. یکی از نکات این حمله استفاده مهاجمین از دو فایل DLL مخرب بود که پیلودهای بعدی رو دانلود و اجرا میکردن.
یکی از این DLLها ، d3dcompiler_47.dll بود که یه DLL قانونی هستش با امضای مایکروسافت اما مهاجمین یسری کد مخرب به انتهای اون اضافه کرده بودن اما ویندوز اونو بعنوان یه فایل امضاء شده توسط مایکروسافت نشون میداد.
در کل وقتی یه فایل اجرایی مثله dll یا exe دارای امضاء باشه یعنی اون فایل معتبره و حاوی کدهای دستکاری شده یا مخرب نیست و کاربران میتونن با اطمینان اجراش کنن.
اگه یه فایل اجرایی که امضاء هم داره، دستکاری بشه، ویندوز یه پیامی بصورت digital signature of the object did not verify. میده و این امضاء رو تایید نمیکنه. اما در خصوص حمله 3cx ، با اینکه این DLL دستکاری شده، اما شاهد چنین پیامی نیستیم.
Will Dormann تحلیلگر امنیتی در ANALYGENCE در خصوص این امر گفته که مهاجمین از آسیب پذیری CVE-2013-3900 استفاده کردن.
این آسیب پذیری که با نام WinVerifyTrust Signature Validation هم شناخته میشه ، برای اولین بار در 10 دسامبر 2013 ، 19 آذر 92 ، گزارش شده .البته بهش تکنیک Authenticode padding هم میگن.
آسیب پذیری امکان اجرای کد رو میده و روی تابع WinVerifyTrust در هنگام بررسی امضای Windows Authenticode در فایلهای PE رخ میده. مهاجم میتونه یه فایل امضاء شده رو دستکاری کنه و کد مخرب به انتهای اون اضافه کنه و اونو از طریق ایمیل یا وب و … در اختیار قربانی قرار بده و قربانی با اجرای اون آلوده بشه. نکته مهم اینکه این فایل تحت امتیاز کاربر اجرا کننده ، اجرا میشه و اگه کاربر، امتیاز بالا داشته باشه ، میتونه خطرناکتر باشه.
در کل Authenticode یه فرمت امضای دیجیتال هستش که برای مشخص کردن منشاء و یکپارچگی نرم افزار(دستکاری نشدن برنامه بعد از عمومی شدن برنامه) استفاده میشه. Authenticode براساس استانداردهای رمزنگاری کلید عمومی (PKCS) #7 هستش و از گواهینامه X.509 v3 برای شناسایی ناشر برنامه یه فایل امضاء شده با Authenticode استفاده میکنه.
یکی از کاربردهای مهم Authenticode ، امضای دیجیتالی فایلهای PE مانند exe ، dll ، sys هستش و این امضاها در ساختاری بنام PKCS #7 SignedData ذخیره میشه. امضاها هم دو تا نکته رو نشون میدن: یکی اینکه ناشر برنامه رو مشخص میکنن و دیگری اینکه نشون میده فایل بعد از امضای اون تغییری نکرده .
ساختار PKCS #7 SignedData حاوی مقدار هش فایل PE، امضای ایجاد شده توسط کلید خصوصی ناشر نرم افزار و گواهینامه های X.509 v3 که کلید امضای ناشر نرم افزار رو به یه نهاد قانونی مرتبط میکنه، هستش.
ساختار PKCS #7 SignedData میتونه حاوی موارد اختیاری زیر هم باشه :
- توضیحاتی در خصوص ناشر نرم افزار
- آدرس اینترنتی ناشر نرم افزار
- یه timestamp برای Authenticode
این timestamp توسط یه timestamping authority (TSA) ایجاد میشه
امضای Authenticode رو میشه در یه فایل PE در قسمت Certificate Table که در قسمت Data Directories در هدر Optional Header تحت عنوان Security Directory هست، مشاهده کرد.
شکل زیر هم نشون دهنده Security Directory هستش :
وقتی از امضای Authenticode برای امضای یه فایل PE استفاده میکنیم الگوریتمی که مقدار هش فایل PE رو محاسبه میکنه برخی از فیلدهای اونو در نظر نمیگیره (در شکل زیر با رنگ خاکستری مشخص شدن) بنابراین اگه این مقادیر تغییر کنن ، منجر به تغییری در هش فایل نداره. شکل زیر یه فایل PE نشون میده که از امضای Authenticode برای امضاش استفاده شده:
PKCS #7 v1.5 ساختار ASN.1 زیر رو برای SignedData بصورت زیر تعریف کرده :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
SignedData ::= SEQUENCE { version Version, digestAlgorithms DigestAlgorithmIdentifiers, contentInfo ContentInfo, certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL, Crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, signerInfos SignerInfos } DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } ContentType ::= OBJECT IDENTIFIER SignerInfos ::= SET OF SignerInfo |
SignedData برای Authenticode مقادیر زیر رو میگیره :
- version باید مقدار 1 رو بگیره .
- digestAlgorithms : این فیلد حاوی object identifiers (OIDs) های digest algorithms هستش که برای امضای contents در ContentInfo type استفاده میشه. با توجه به اینکه Authenticode از یه امضاء کننده پشتیبانی میکنه بنابراین مقدار digestAlgorithms فقط میتونه یه ساختار digestAlgorithmIdentifier رو داشته باشه و ساختار باید با مقدار فیلد digestAlgorithm در ساختار SignerInfo مطابقت داشته باشه. در غیر اینصورت امضاء دستکاری شده هستش.
- contentInfo : این فیلد خودش شامل دو فیلده :
- contentType : باید روی SPC_INDIRECT_DATA_OBJID (1.3.6.1.4.1.311.2.1.4) تنظیم بشه.
- content: باید روی یه ساختار SpcIndirectDataContent تنظیم بشه.
- certificates : این فیلد حاوی مجموعه ای از گواهینامه ها هستش.
- crls : این فیلد استفاده نمیشه.
- signerInfos : این فیلد حاوی یسری ساختار SignerInfo هستش. همونطور که بالا گفته شد Authenticode فقط از signer پشتیبانی میکنه بنابراین این فیلد فقط یه ساختار SignerInfo شامل میشه.
امضاهای Authenticode در ساختاری بنام WIN_CERTIFICATE که در Wintrust.h هستش، تعریف میشه . این ساختار رو بالا در شکل مربوط به ساختار security directory قابل مشاهده هستش.
|
1 2 3 4 5 6 7 |
typedef struct _WIN_CERTIFICATE { DWORD dwLength; WORD wRevision; WORD wCertificateType; BYTE bCertificate[ANYSIZE_ARRAY]; } WIN_CERTIFICATE, *LPWIN_CERTIFICATE; |
- dwLength : سایز bCertificate رو میگیره.
- wRevision : شماره نسخه WIN_CERTIFICATE رو میگیره. WIN_CERT_REVISION_1_0 که نسخه یک هستش و با مقدار 0x0100 مشخص میشه برای نسخه قدیمی هستش و WIN_CERT_REVISION_2_0 که نسخه دو هستش و با مقدار 0x0200 مشخص میشه برای نسخه فعلی هستش.
- wCertificateType : مقدار این فیلد برای امضاهای Authenticode برابر 2 هستش. یعنی از این طریق مشخص میشه که این یه امضای Authenticode هستش. این مقدار در قسمت WIN_CERT_TYPE_PKCS_SIGNED_DATA در Wintrust.h تعریف شده.
- bCertificate: یه آرایه باینری با طول متغیر هستش که حاوی Authenticode PKCS #7 signedData ، در بالا توضیح داده شد، هستش.
رایجترین روش برای تایید اعتبار Authenticode استفاده از تابع WinVerifyTrust با مقدار WINTRUST_ACTION_GENERIC_VERIFY_V2 برای فیلد pgActionID هستش.
|
1 2 3 4 5 |
LONG WinVerifyTrust( [in] HWND hwnd, [in] GUID *pgActionID, [in] LPVOID pWVTData ); |
نکته جالبی که در خصوص آسیب پذیری CVE-2013-3900 وجود داره اینه که ، مایکروسافت این آسیب پذیری رو اصلاح نکرد بلکه یسری تنظیمات در رجیستری معرفی کرد که هر کی خواست اعمال کنه. البته اعمال کردنش هم مشکلاتی رو روی برخی برنامه ها میتونست داشته باشه.
آقای Will Dormann در یه رشته توییتی در خصوص این موضوع صحبت کرده، ایشون دو تا فایل با عنوان اینستالر مرورگر کروم داره و هر دو امضای Authenticode یکسانی دارن :
اما اگه دو فایل رو با هم مقایسه کنیم ، یکی نیستن و دستکاری شده هستن :
همونطور که بالا گفتیم ، مایکروسافت یسری کلید رجیستری معرفی کرد که هر کی خواست اعمال کنه. اگه این کلیدهای رجیستری رو اعمال کنید ، دیگه در ساختار WIN_CERTIFICATE امکان قرار گرفتن داده های اضافی وجود نداره و در نتیجه ویندوز چنین فایلهایی رو امضاء شده در نظر نمیگیره.
برای اعمال این ویژگی میتونید از کلید های رجیستری زیر استفاده کنید :
ویندوزهای 64 بیتی :
|
1 2 3 4 5 6 |
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"="1" [HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"="1" |
ویندوزهای 32 بیتی :
|
1 2 3 |
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"="1" |
برای غیر فعال کردن این ویژگی :
ویندوزهای 64 بیتی :
|
1 2 3 4 5 6 |
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"=- [HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"=- |
ویندوزهای 32 بیتی :
|
1 2 3 |
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"=- |
اگه در حمله 3cx ، قربانی ها این تنظیمات رجیستری رو اعمال میکردن، فایل امضاء شده محسوب نمیشد و در نتیجه امکان اینکه توسط محصولات امنیتی شناسایی بشه، بالا میرفت.
یه نکته هم این که اگه این کلیدها رو اعمال کنید و ویندوز رو به ویندوز 11 ارتقاء بدید، این تنظیمات پاک میشن و باید دوباره اعمال کنید. این آسیب پذیری علاوه بر حملات اخیر 3cx در کمپین های توزیع بدافزار Zloader که در ژانویه انجام شده بود هم مورد استفاده قرار گرفته.
در خصوص اینکه این تنظیمات اعمال کنیم یا نه ، گفته شده که بعد اعمال بدون دردسر اجرا شده و مشکلی پیش نیومده. اما در برخی برنامه ها مثله اینستالر گوگل کروم و … مشکلاتی بوده ، اما امنیت خیلی بهتر از این مشکلات هستش.
منابع :
Windows Authenticode Portable Executable Signature Format