حمله به 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

  • CVE-2019-11539 – Post-auth(admin) Command Injection
  • CVE-2019-11538 – خواندن فایل دلخواه پس از تأیید (کاربر) از طریق NFS-201-1965 – نوشتن فایل دلخواه پس از تأیید (کاربر) از طریق NFS
  • CVE-2019-11540 – گنجاندن اسکریپت متقاطع پس از تأیید
  • CVE-2019-11507 – نسخه پس از تأیید[29] اسکریپت متقابل سایت[19]690f
    • 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]> 
    
    

    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 را مشخص کنیم. رشته کوئری برای دور زدن اعتبارسنجی و ایجاد request->filepath به هر فایلی که می خواهید دانلود کنید! ]/dana/html5acc/guacamole/ دوباره در میانه راه. در غیر این صورت، فقط می‌توانید پسوندهای فایل محدودی مانند json.، xml. یا . درخواست‌ها

    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

    اکنون پیام خطا به یک اسکریپت پرل معتبر تبدیل می شود. چرا؟ خوب، بیایید اکنون یک درس Perl 101 داشته باشیم!

    همانطور که می بینید، Perl از برچسب GOTO پشتیبانی می کند، بنابراین tcpdump: در Perl یک برچسب معتبر می شود. سپس بقیه را با هشتگ کامنت می گذاریم. با این ترفند خلاقانه، اکنون می‌توانیم هر پرل معتبری را تولید کنیم!

    در نهایت، از یک نماد ورودی/خروجی ناقص < برای فریب دادن DSSAFE.pm استفاده می‌کنیم و تجزیه‌کننده فرمان را تغییر مسیر می‌دهیم. STDERR به دایرکتوری کش! این اکسپلویت نهایی است:

    -r$x="ls /",system$x# 2>/data/runtime/tmp/tt/setcookie.thtml.ttc <
    

    دستور الحاقی به این صورت است:

    /usr/sbin/tcpdump -d 
     -r'$x="ls /",system$x#'
     2>/data/runtime/tmp/tt/setcookie.thtml.ttc <
     >/dev/null
     2>&1
    

    و setcookie.thtml.ttc تولید شده به نظر می‌رسد:

     tcpdump: $x=[1965917] 19659126]$x#: چنین فایل یا فهرستی وجود ندارد
    

    هنگامی که این کار را انجام دادیم، می‌توانیم صفحه مربوطه را برای اجرای دستور خود واکشی کنیم:

    $ curl https://sslvpn/dana-na/auth/setcookie.cgi
     boot bin home lib64 mnt opt ​​proc sys usr var
     داده ها و غیره lib گم شده + یافت شده ماژول های pkg sbin tmp
     ...
    

    تا کنون، کل بخش فنی این تزریق فرمان به پایان رسیده است. با این حال، ما فکر می‌کنیم که ممکن است راه خلاقانه دیگری برای بهره‌برداری از این وجود داشته باشد، اگر یکی را پیدا کردید، لطفاً به من بگویید! ما به نظارت بر اینترنت ادامه دادیم تا زمان پاسخگویی هر شرکت بزرگ را اندازه گیری کنیم. توییتر یکی از آنهاست. آنها به خاطر برنامه پاداش باگ و خوب برای هکرها شناخته شده اند. با این حال، سوء استفاده از یک روز بلافاصله پس از انتشار پچ نامناسب است. بنابراین ما 30 روز صبر می کنیم تا توییتر SSL VPN خود را ارتقا دهد. اولین کاری که هر روز صبح انجام دادیم این بود که بررسی کنیم آیا توییتر SSL VPN خود را ارتقا می دهد یا خیر! زمان فراموش نشدنی برای ما بود 😛

    ما در 28 مه 2019 شروع به هک کردن توییتر کردیم. در طول این عملیات با موانع متعددی مواجه می شویم. اولین مورد این است که اگرچه می‌توانیم رمز عبور متن ساده کارکنان توییتر را بدست آوریم، اما هنوز نمی‌توانیم به دلیل احراز هویت دو عاملی وارد SSL VPN آنها شویم. در اینجا دو راه برای دور زدن آن پیشنهاد می کنیم. اولین مورد این است که ما مشاهده کردیم توییتر از راه حل Duo استفاده می کند. در این راهنما آمده است:

    امنیت برنامه Duo شما به امنیت کلید مخفی شما (کلید) مرتبط است. آن را مانند هر اعتبار حساسی ایمن کنید. آن را با افراد غیرمجاز به اشتراک نگذارید و تحت هیچ شرایطی آن را برای کسی ایمیل نکنید!

    بنابراین اگر بتوانیم کلید مخفی را از سیستم استخراج کنیم، می‌توانیم از Duo API برای دور زدن 2FA استفاده کنیم. با این حال، ما یک راه سریعتر برای دور زدن آن پیدا کردیم. توییتر ویژگی Roaming Session را فعال کرد که برای افزایش تحرک استفاده می‌شود و اجازه می‌دهد یک جلسه از چندین مکان IP انجام شود. برای ورود به سیستم آنها!

    تا کنون، ما می‌توانیم به اینترانت توییتر دسترسی داشته باشیم. با این وجود، هدف ما دستیابی به اجرای کد است! به نظر مهم تر از دسترسی به اینترانت است. بنابراین ما می‌خواهیم اشکال تزریق فرمان (CVE-2019-11539) را با هم زنجیره کنیم. خوب، در اینجا، ما با مانع دیگری روبرو شدیم. این رابط مدیریت محدود است!

    همانطور که قبلاً ذکر کردیم، اشکال ما در رابط مدیریت است. اما برای ملاحظات امنیتی، اکثر شرکت‌ها این رابط را در حالت عمومی غیرفعال می‌کنند، بنابراین ما به راه دیگری برای دسترسی به صفحه مدیریت نیاز داریم. اگر مقاله قبلی ما را به دقت خوانده باشید، ممکن است ویژگی “WebVPN” را به خاطر بیاورید! WebVPN یک پروکسی است که به اتصال به هر جایی کمک می کند. بنابراین، بیایید به خودش وصل شویم.

    بله، این SSRF است!

    در اینجا ما از یک ترفند کوچک برای دور زدن حفاظت های SSRF استفاده می کنیم.

    آها! از طریق SSRF ما، اکنون می توانیم رابط را لمس کنیم! سپس، آخرین مانع ظاهر شد. ما هیچ رمز عبور متنی ساده ای از مدیران نداشتیم. وقتی پرل می خواهد داده ها را با رویه های بومی مبادله کند، مانند پسوند Perl در C++ یا وب سرور، از کش برای ذخیره داده ها استفاده می کند. مشکل این است که Pulse Secure فراموش می کند که داده های حساس را پس از تبادل پاک کند، به همین دلیل است که می توانیم رمزهای عبور متن ساده را در حافظه پنهان به دست آوریم. اما عملاً اکثر مدیران فقط برای اولین بار وارد سیستم خود می شوند، بنابراین دریافت رمز عبور متن ساده مدیر دشوار است. تنها چیزی که به دست آوردیم، هش رمز عبور در قالب sha256(md5_crypt(salt,…)) است…

    اگر در شکستن هش تجربه داشته باشید، می‌دانید که چقدر سخت است. بنابراین…

    ما یک AWS 72 هسته‌ای را برای شکستن آن راه‌اندازی کردیم.

    ما هش را شکستیم و RCE را با موفقیت دریافت کردیم! من فکر می کنم ما خوش شانس هستیم زیرا از نظر ما، یک سیاست رمز عبور بسیار قوی در کارکنان توییتر وجود دارد. اما به نظر می رسد این سیاست در مورد مدیر اعمال نمی شود. طول رمز عبور مدیر تنها ده است و اولین کاراکتر B است. این در مراحل اولیه صف کرک ما است تا بتوانیم هش را در عرض 3 ساعت بشکنیم.

    ما همه یافته‌های خود را به توییتر گزارش کردیم و بالاترین جایزه را از آن‌ها دریافت کردیم. اگرچه ما نمی توانیم آن را ثابت کنیم، اما به نظر می رسد این اولین اجرای کد از راه دور در توییتر است! اگر به گزارش کامل علاقه مند هستید، می توانید لینک HackerOne را برای جزئیات بیشتر بررسی کنید.

    چگونه چنین حملاتی را کاهش دهیم؟ در اینجا ما چندین توصیه را ارائه می کنیم.

    اولین مورد گواهی سمت مشتری است. همچنین موثرترین روش است. بدون گواهی معتبر، اتصال مخرب در طول مذاکره SSL حذف خواهد شد! دومی، احراز هویت چند عاملی است. اگرچه ما این بار توییتر 2FA را شکستیم، اما با یک تنظیم مناسب، MFA همچنان می تواند سطح حملات متعدد را کاهش دهد. سپس، حسابرسی گزارش کامل را فعال کنید و به یاد داشته باشید که آن را به یک سرور گزارش خارج از مرز ارسال کنید.

    همچنین، فهرست دارایی شرکت خود را به طور منظم انجام دهید و در مشاوره امنیتی فروشنده مشترک شوید. مهمتر از همه، همیشه سیستم خود را به روز نگه دارید!

    شرکت ما، DEVCORE، حرفه ای ترین خدمات تیم قرمز را در آسیا ارائه می دهد. در این بخش جایزه، بیایید در مورد چگونگی بیشتر کردن تیم قرمز قرمز صحبت کنیم!

    ما همیشه می دانیم که در عملیات تیم قرمز، رایانه شخصی ارزشمندتر است! چندین روش قدیمی برای به خطر انداختن کلاینت‌های VPN از طریق SSL VPN وجود دارد، مانند حمله water-hole و جایگزینی عامل VPN. این ویژگی «logon script» است. تقریباً در هر VPN SSL مانند OpenVPN، Fortinet، Pulse Secure و غیره ظاهر می شود. می‌تواند اسکریپت‌های مربوطه را برای نصب فایل-سیستم شبکه یا تغییر جدول مسیریابی پس از برقراری اتصال VPN اجرا کند. می تواند از این ویژگی برای آلوده کردن تمام مشتریان VPN استفاده کند! در اینجا ما از Pulse Secure به عنوان مثال استفاده می‌کنیم و نشان می‌دهیم که چگونه نه تنها SSL VPN را به خطر بیندازیم، بلکه همه کلاینت‌های متصل خود را نیز در اختیار بگیریم:

    خوب، اینجا پایان این سری حمله به SSL VPN است! از یافته‌های ما، SSL VPN یک سطح حمله بزرگ است که تعداد کمی از محققان امنیتی در آن جستجو می‌کنند. ظاهراً سزاوار توجه بیشتری است. ما امیدواریم که این نوع سریال بتواند سایر محققان را تشویق کند تا در این زمینه مشارکت کنند و امنیت شرکت ها را افزایش دهند! ما تحقیقات ابتکاری بیشتری را در آینده منتشر خواهیم کرد 🙂

    .

    حمله به 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

  • CVE-2019-11539 – Post-auth(admin) Command Injection
  • CVE-2019-11538 – خواندن فایل دلخواه پس از تأیید (کاربر) از طریق NFS-201-1965 – نوشتن فایل دلخواه پس از تأیید (کاربر) از طریق NFS
  • CVE-2019-11540 – گنجاندن اسکریپت متقاطع پس از تأیید
  • CVE-2019-11507 – نسخه پس از تأیید[29] اسکریپت متقابل سایت[19]690f
    • 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]> 
    
    

    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 را مشخص کنیم. رشته کوئری برای دور زدن اعتبارسنجی و ایجاد request->filepath به هر فایلی که می خواهید دانلود کنید! ]/dana/html5acc/guacamole/ دوباره در میانه راه. در غیر این صورت، فقط می‌توانید پسوندهای فایل محدودی مانند json.، xml. یا . درخواست‌ها

    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

    اکنون پیام خطا به یک اسکریپت پرل معتبر تبدیل می شود. چرا؟ خوب، بیایید اکنون یک درس Perl 101 داشته باشیم!

    همانطور که می بینید، Perl از برچسب GOTO پشتیبانی می کند، بنابراین tcpdump: در Perl یک برچسب معتبر می شود. سپس بقیه را با هشتگ کامنت می گذاریم. با این ترفند خلاقانه، اکنون می‌توانیم هر پرل معتبری را تولید کنیم!

    در نهایت، از یک نماد ورودی/خروجی ناقص < برای فریب دادن DSSAFE.pm استفاده می‌کنیم و تجزیه‌کننده فرمان را تغییر مسیر می‌دهیم. STDERR به دایرکتوری کش! این اکسپلویت نهایی است:

    -r$x="ls /",system$x# 2>/data/runtime/tmp/tt/setcookie.thtml.ttc <
    

    دستور الحاقی به این صورت است:

    /usr/sbin/tcpdump -d 
     -r'$x="ls /",system$x#'
     2>/data/runtime/tmp/tt/setcookie.thtml.ttc <
     >/dev/null
     2>&1
    

    و setcookie.thtml.ttc تولید شده به نظر می‌رسد:

     tcpdump: $x=[1965917] 19659126]$x#: چنین فایل یا فهرستی وجود ندارد
    

    هنگامی که این کار را انجام دادیم، می‌توانیم صفحه مربوطه را برای اجرای دستور خود واکشی کنیم:

    $ curl https://sslvpn/dana-na/auth/setcookie.cgi
     boot bin home lib64 mnt opt ​​proc sys usr var
     داده ها و غیره lib گم شده + یافت شده ماژول های pkg sbin tmp
     ...
    

    تا کنون، کل بخش فنی این تزریق فرمان به پایان رسیده است. با این حال، ما فکر می‌کنیم که ممکن است راه خلاقانه دیگری برای بهره‌برداری از این وجود داشته باشد، اگر یکی را پیدا کردید، لطفاً به من بگویید! ما به نظارت بر اینترنت ادامه دادیم تا زمان پاسخگویی هر شرکت بزرگ را اندازه گیری کنیم. توییتر یکی از آنهاست. آنها به خاطر برنامه پاداش باگ و خوب برای هکرها شناخته شده اند. با این حال، سوء استفاده از یک روز بلافاصله پس از انتشار پچ نامناسب است. بنابراین ما 30 روز صبر می کنیم تا توییتر SSL VPN خود را ارتقا دهد. اولین کاری که هر روز صبح انجام دادیم این بود که بررسی کنیم آیا توییتر SSL VPN خود را ارتقا می دهد یا خیر! زمان فراموش نشدنی برای ما بود 😛

    ما در 28 مه 2019 شروع به هک کردن توییتر کردیم. در طول این عملیات با موانع متعددی مواجه می شویم. اولین مورد این است که اگرچه می‌توانیم رمز عبور متن ساده کارکنان توییتر را بدست آوریم، اما هنوز نمی‌توانیم به دلیل احراز هویت دو عاملی وارد SSL VPN آنها شویم. در اینجا دو راه برای دور زدن آن پیشنهاد می کنیم. اولین مورد این است که ما مشاهده کردیم توییتر از راه حل Duo استفاده می کند. در این راهنما آمده است:

    امنیت برنامه Duo شما به امنیت کلید مخفی شما (کلید) مرتبط است. آن را مانند هر اعتبار حساسی ایمن کنید. آن را با افراد غیرمجاز به اشتراک نگذارید و تحت هیچ شرایطی آن را برای کسی ایمیل نکنید!

    بنابراین اگر بتوانیم کلید مخفی را از سیستم استخراج کنیم، می‌توانیم از Duo API برای دور زدن 2FA استفاده کنیم. با این حال، ما یک راه سریعتر برای دور زدن آن پیدا کردیم. توییتر ویژگی Roaming Session را فعال کرد که برای افزایش تحرک استفاده می‌شود و اجازه می‌دهد یک جلسه از چندین مکان IP انجام شود. برای ورود به سیستم آنها!

    تا کنون، ما می‌توانیم به اینترانت توییتر دسترسی داشته باشیم. با این وجود، هدف ما دستیابی به اجرای کد است! به نظر مهم تر از دسترسی به اینترانت است. بنابراین ما می‌خواهیم اشکال تزریق فرمان (CVE-2019-11539) را با هم زنجیره کنیم. خوب، در اینجا، ما با مانع دیگری روبرو شدیم. این رابط مدیریت محدود است!

    همانطور که قبلاً ذکر کردیم، اشکال ما در رابط مدیریت است. اما برای ملاحظات امنیتی، اکثر شرکت‌ها این رابط را در حالت عمومی غیرفعال می‌کنند، بنابراین ما به راه دیگری برای دسترسی به صفحه مدیریت نیاز داریم. اگر مقاله قبلی ما را به دقت خوانده باشید، ممکن است ویژگی “WebVPN” را به خاطر بیاورید! WebVPN یک پروکسی است که به اتصال به هر جایی کمک می کند. بنابراین، بیایید به خودش وصل شویم.

    بله، این SSRF است!

    در اینجا ما از یک ترفند کوچک برای دور زدن حفاظت های SSRF استفاده می کنیم.

    آها! از طریق SSRF ما، اکنون می توانیم رابط را لمس کنیم! سپس، آخرین مانع ظاهر شد. ما هیچ رمز عبور متنی ساده ای از مدیران نداشتیم. وقتی پرل می خواهد داده ها را با رویه های بومی مبادله کند، مانند پسوند Perl در C++ یا وب سرور، از کش برای ذخیره داده ها استفاده می کند. مشکل این است که Pulse Secure فراموش می کند که داده های حساس را پس از تبادل پاک کند، به همین دلیل است که می توانیم رمزهای عبور متن ساده را در حافظه پنهان به دست آوریم. اما عملاً اکثر مدیران فقط برای اولین بار وارد سیستم خود می شوند، بنابراین دریافت رمز عبور متن ساده مدیر دشوار است. تنها چیزی که به دست آوردیم، هش رمز عبور در قالب sha256(md5_crypt(salt,…)) است…

    اگر در شکستن هش تجربه داشته باشید، می‌دانید که چقدر سخت است. بنابراین…

    ما یک AWS 72 هسته‌ای را برای شکستن آن راه‌اندازی کردیم.

    ما هش را شکستیم و RCE را با موفقیت دریافت کردیم! من فکر می کنم ما خوش شانس هستیم زیرا از نظر ما، یک سیاست رمز عبور بسیار قوی در کارکنان توییتر وجود دارد. اما به نظر می رسد این سیاست در مورد مدیر اعمال نمی شود. طول رمز عبور مدیر تنها ده است و اولین کاراکتر B است. این در مراحل اولیه صف کرک ما است تا بتوانیم هش را در عرض 3 ساعت بشکنیم.

    ما همه یافته‌های خود را به توییتر گزارش کردیم و بالاترین جایزه را از آن‌ها دریافت کردیم. اگرچه ما نمی توانیم آن را ثابت کنیم، اما به نظر می رسد این اولین اجرای کد از راه دور در توییتر است! اگر به گزارش کامل علاقه مند هستید، می توانید لینک HackerOne را برای جزئیات بیشتر بررسی کنید.

    چگونه چنین حملاتی را کاهش دهیم؟ در اینجا ما چندین توصیه را ارائه می کنیم.

    اولین مورد گواهی سمت مشتری است. همچنین موثرترین روش است. بدون گواهی معتبر، اتصال مخرب در طول مذاکره SSL حذف خواهد شد! دومی، احراز هویت چند عاملی است. اگرچه ما این بار توییتر 2FA را شکستیم، اما با یک تنظیم مناسب، MFA همچنان می تواند سطح حملات متعدد را کاهش دهد. سپس، حسابرسی گزارش کامل را فعال کنید و به یاد داشته باشید که آن را به یک سرور گزارش خارج از مرز ارسال کنید.

    همچنین، فهرست دارایی شرکت خود را به طور منظم انجام دهید و در مشاوره امنیتی فروشنده مشترک شوید. مهمتر از همه، همیشه سیستم خود را به روز نگه دارید!

    شرکت ما، DEVCORE، حرفه ای ترین خدمات تیم قرمز را در آسیا ارائه می دهد. در این بخش جایزه، بیایید در مورد چگونگی بیشتر کردن تیم قرمز قرمز صحبت کنیم!

    ما همیشه می دانیم که در عملیات تیم قرمز، رایانه شخصی ارزشمندتر است! چندین روش قدیمی برای به خطر انداختن کلاینت‌های VPN از طریق SSL VPN وجود دارد، مانند حمله water-hole و جایگزینی عامل VPN. این ویژگی «logon script» است. تقریباً در هر VPN SSL مانند OpenVPN، Fortinet، Pulse Secure و غیره ظاهر می شود. می‌تواند اسکریپت‌های مربوطه را برای نصب فایل-سیستم شبکه یا تغییر جدول مسیریابی پس از برقراری اتصال VPN اجرا کند. می تواند از این ویژگی برای آلوده کردن تمام مشتریان VPN استفاده کند! در اینجا ما از Pulse Secure به عنوان مثال استفاده می‌کنیم و نشان می‌دهیم که چگونه نه تنها SSL VPN را به خطر بیندازیم، بلکه همه کلاینت‌های متصل خود را نیز در اختیار بگیریم:

    خوب، اینجا پایان این سری حمله به SSL VPN است! از یافته‌های ما، SSL VPN یک سطح حمله بزرگ است که تعداد کمی از محققان امنیتی در آن جستجو می‌کنند. ظاهراً سزاوار توجه بیشتری است. ما امیدواریم که این نوع سریال بتواند سایر محققان را تشویق کند تا در این زمینه مشارکت کنند و امنیت شرکت ها را افزایش دهند! ما تحقیقات ابتکاری بیشتری را در آینده منتشر خواهیم کرد 🙂

    .

    حمله به 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

  • CVE-2019-11539 – Post-auth(admin) Command Injection
  • CVE-2019-11538 – خواندن فایل دلخواه پس از تأیید (کاربر) از طریق NFS-201-1965 – نوشتن فایل دلخواه پس از تأیید (کاربر) از طریق NFS
  • CVE-2019-11540 – گنجاندن اسکریپت متقاطع پس از تأیید
  • CVE-2019-11507 – نسخه پس از تأیید[29] اسکریپت متقابل سایت[19]690f
    • 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]> 
    
    

    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 را مشخص کنیم. رشته کوئری برای دور زدن اعتبارسنجی و ایجاد request->filepath به هر فایلی که می خواهید دانلود کنید! ]/dana/html5acc/guacamole/ دوباره در میانه راه. در غیر این صورت، فقط می‌توانید پسوندهای فایل محدودی مانند json.، xml. یا . درخواست‌ها

    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

    اکنون پیام خطا به یک اسکریپت پرل معتبر تبدیل می شود. چرا؟ خوب، بیایید اکنون یک درس Perl 101 داشته باشیم!

    همانطور که می بینید، Perl از برچسب GOTO پشتیبانی می کند، بنابراین tcpdump: در Perl یک برچسب معتبر می شود. سپس بقیه را با هشتگ کامنت می گذاریم. با این ترفند خلاقانه، اکنون می‌توانیم هر پرل معتبری را تولید کنیم!

    در نهایت، از یک نماد ورودی/خروجی ناقص < برای فریب دادن DSSAFE.pm استفاده می‌کنیم و تجزیه‌کننده فرمان را تغییر مسیر می‌دهیم. STDERR به دایرکتوری کش! این اکسپلویت نهایی است:

    -r$x="ls /",system$x# 2>/data/runtime/tmp/tt/setcookie.thtml.ttc <
    

    دستور الحاقی به این صورت است:

    /usr/sbin/tcpdump -d 
     -r'$x="ls /",system$x#'
     2>/data/runtime/tmp/tt/setcookie.thtml.ttc <
     >/dev/null
     2>&1
    

    و setcookie.thtml.ttc تولید شده به نظر می‌رسد:

     tcpdump: $x=[1965917] 19659126]$x#: چنین فایل یا فهرستی وجود ندارد
    

    هنگامی که این کار را انجام دادیم، می‌توانیم صفحه مربوطه را برای اجرای دستور خود واکشی کنیم:

    $ curl https://sslvpn/dana-na/auth/setcookie.cgi
     boot bin home lib64 mnt opt ​​proc sys usr var
     داده ها و غیره lib گم شده + یافت شده ماژول های pkg sbin tmp
     ...
    

    تا کنون، کل بخش فنی این تزریق فرمان به پایان رسیده است. با این حال، ما فکر می‌کنیم که ممکن است راه خلاقانه دیگری برای بهره‌برداری از این وجود داشته باشد، اگر یکی را پیدا کردید، لطفاً به من بگویید! ما به نظارت بر اینترنت ادامه دادیم تا زمان پاسخگویی هر شرکت بزرگ را اندازه گیری کنیم. توییتر یکی از آنهاست. آنها به خاطر برنامه پاداش باگ و خوب برای هکرها شناخته شده اند. با این حال، سوء استفاده از یک روز بلافاصله پس از انتشار پچ نامناسب است. بنابراین ما 30 روز صبر می کنیم تا توییتر SSL VPN خود را ارتقا دهد. اولین کاری که هر روز صبح انجام دادیم این بود که بررسی کنیم آیا توییتر SSL VPN خود را ارتقا می دهد یا خیر! زمان فراموش نشدنی برای ما بود 😛

    ما در 28 مه 2019 شروع به هک کردن توییتر کردیم. در طول این عملیات با موانع متعددی مواجه می شویم. اولین مورد این است که اگرچه می‌توانیم رمز عبور متن ساده کارکنان توییتر را بدست آوریم، اما هنوز نمی‌توانیم به دلیل احراز هویت دو عاملی وارد SSL VPN آنها شویم. در اینجا دو راه برای دور زدن آن پیشنهاد می کنیم. اولین مورد این است که ما مشاهده کردیم توییتر از راه حل Duo استفاده می کند. در این راهنما آمده است:

    امنیت برنامه Duo شما به امنیت کلید مخفی شما (کلید) مرتبط است. آن را مانند هر اعتبار حساسی ایمن کنید. آن را با افراد غیرمجاز به اشتراک نگذارید و تحت هیچ شرایطی آن را برای کسی ایمیل نکنید!

    بنابراین اگر بتوانیم کلید مخفی را از سیستم استخراج کنیم، می‌توانیم از Duo API برای دور زدن 2FA استفاده کنیم. با این حال، ما یک راه سریعتر برای دور زدن آن پیدا کردیم. توییتر ویژگی Roaming Session را فعال کرد که برای افزایش تحرک استفاده می‌شود و اجازه می‌دهد یک جلسه از چندین مکان IP انجام شود. برای ورود به سیستم آنها!

    تا کنون، ما می‌توانیم به اینترانت توییتر دسترسی داشته باشیم. با این وجود، هدف ما دستیابی به اجرای کد است! به نظر مهم تر از دسترسی به اینترانت است. بنابراین ما می‌خواهیم اشکال تزریق فرمان (CVE-2019-11539) را با هم زنجیره کنیم. خوب، در اینجا، ما با مانع دیگری روبرو شدیم. این رابط مدیریت محدود است!

    همانطور که قبلاً ذکر کردیم، اشکال ما در رابط مدیریت است. اما برای ملاحظات امنیتی، اکثر شرکت‌ها این رابط را در حالت عمومی غیرفعال می‌کنند، بنابراین ما به راه دیگری برای دسترسی به صفحه مدیریت نیاز داریم. اگر مقاله قبلی ما را به دقت خوانده باشید، ممکن است ویژگی “WebVPN” را به خاطر بیاورید! WebVPN یک پروکسی است که به اتصال به هر جایی کمک می کند. بنابراین، بیایید به خودش وصل شویم.

    بله، این SSRF است!

    در اینجا ما از یک ترفند کوچک برای دور زدن حفاظت های SSRF استفاده می کنیم.

    آها! از طریق SSRF ما، اکنون می توانیم رابط را لمس کنیم! سپس، آخرین مانع ظاهر شد. ما هیچ رمز عبور متنی ساده ای از مدیران نداشتیم. وقتی پرل می خواهد داده ها را با رویه های بومی مبادله کند، مانند پسوند Perl در C++ یا وب سرور، از کش برای ذخیره داده ها استفاده می کند. مشکل این است که Pulse Secure فراموش می کند که داده های حساس را پس از تبادل پاک کند، به همین دلیل است که می توانیم رمزهای عبور متن ساده را در حافظه پنهان به دست آوریم. اما عملاً اکثر مدیران فقط برای اولین بار وارد سیستم خود می شوند، بنابراین دریافت رمز عبور متن ساده مدیر دشوار است. تنها چیزی که به دست آوردیم، هش رمز عبور در قالب sha256(md5_crypt(salt,…)) است…

    اگر در شکستن هش تجربه داشته باشید، می‌دانید که چقدر سخت است. بنابراین…

    ما یک AWS 72 هسته‌ای را برای شکستن آن راه‌اندازی کردیم.

    ما هش را شکستیم و RCE را با موفقیت دریافت کردیم! من فکر می کنم ما خوش شانس هستیم زیرا از نظر ما، یک سیاست رمز عبور بسیار قوی در کارکنان توییتر وجود دارد. اما به نظر می رسد این سیاست در مورد مدیر اعمال نمی شود. طول رمز عبور مدیر تنها ده است و اولین کاراکتر B است. این در مراحل اولیه صف کرک ما است تا بتوانیم هش را در عرض 3 ساعت بشکنیم.

    ما همه یافته‌های خود را به توییتر گزارش کردیم و بالاترین جایزه را از آن‌ها دریافت کردیم. اگرچه ما نمی توانیم آن را ثابت کنیم، اما به نظر می رسد این اولین اجرای کد از راه دور در توییتر است! اگر به گزارش کامل علاقه مند هستید، می توانید لینک HackerOne را برای جزئیات بیشتر بررسی کنید.

    چگونه چنین حملاتی را کاهش دهیم؟ در اینجا ما چندین توصیه را ارائه می کنیم.

    اولین مورد گواهی سمت مشتری است. همچنین موثرترین روش است. بدون گواهی معتبر، اتصال مخرب در طول مذاکره SSL حذف خواهد شد! دومی، احراز هویت چند عاملی است. اگرچه ما این بار توییتر 2FA را شکستیم، اما با یک تنظیم مناسب، MFA همچنان می تواند سطح حملات متعدد را کاهش دهد. سپس، حسابرسی گزارش کامل را فعال کنید و به یاد داشته باشید که آن را به یک سرور گزارش خارج از مرز ارسال کنید.

    همچنین، فهرست دارایی شرکت خود را به طور منظم انجام دهید و در مشاوره امنیتی فروشنده مشترک شوید. مهمتر از همه، همیشه سیستم خود را به روز نگه دارید!

    شرکت ما، DEVCORE، حرفه ای ترین خدمات تیم قرمز را در آسیا ارائه می دهد. در این بخش جایزه، بیایید در مورد چگونگی بیشتر کردن تیم قرمز قرمز صحبت کنیم!

    ما همیشه می دانیم که در عملیات تیم قرمز، رایانه شخصی ارزشمندتر است! چندین روش قدیمی برای به خطر انداختن کلاینت‌های VPN از طریق SSL VPN وجود دارد، مانند حمله water-hole و جایگزینی عامل VPN. این ویژگی «logon script» است. تقریباً در هر VPN SSL مانند OpenVPN، Fortinet، Pulse Secure و غیره ظاهر می شود. می‌تواند اسکریپت‌های مربوطه را برای نصب فایل-سیستم شبکه یا تغییر جدول مسیریابی پس از برقراری اتصال VPN اجرا کند. می تواند از این ویژگی برای آلوده کردن تمام مشتریان VPN استفاده کند! در اینجا ما از Pulse Secure به عنوان مثال استفاده می‌کنیم و نشان می‌دهیم که چگونه نه تنها SSL VPN را به خطر بیندازیم، بلکه همه کلاینت‌های متصل خود را نیز در اختیار بگیریم:

    خوب، اینجا پایان این سری حمله به SSL VPN است! از یافته‌های ما، SSL VPN یک سطح حمله بزرگ است که تعداد کمی از محققان امنیتی در آن جستجو می‌کنند. ظاهراً سزاوار توجه بیشتری است. ما امیدواریم که این نوع سریال بتواند سایر محققان را تشویق کند تا در این زمینه مشارکت کنند و امنیت شرکت ها را افزایش دهند! ما تحقیقات ابتکاری بیشتری را در آینده منتشر خواهیم کرد 🙂

    .

    6 بهترین سایت تورنت موسیقی در سال 2021

    RARBG یکی دیگر از سایت های تورنت موسیقی جالب است. این سایت در سال 2008 تأسیس شد. از آن زمان، طبق فهرست سالانه TorrentFreak، TorrentFreak همیشه آن را به عنوان یکی از پربازدیدترین وب سایت های تورنت معرفی کرده است.

    در ژوئن 2021، زمانی که رتبه بندی سال منتشر شد، در جایگاه پنجم قرار گرفت. . مانند سایر سایت‌های تورنت، با به اشتراک‌گذاری فایل p2p از طریق پروتکل BitTorrent کار می‌کند.

    اما این سایت از آپلود تورنت‌های کاربران جلوگیری می‌کند تا میزان بدافزار موجود را کاهش دهد. این مجموعه گسترده ای از تورنت ها و همچنین جامعه ای قوی از کاربران دارد. جستجوی تک‌آهنگ‌ها و آلبوم‌های مورد علاقه‌تان را می‌توان بر اساس نام، تاریخ آپلود، دانه‌ها و زالو مرتب کرد. RARBG نسبتاً ایمن است. با این حال، به نفع شماست که سایت را با استفاده از VPN مرور کنید.

    به دلایل قانونی، RARBG در بسیاری از کشورهای جهان مسدود شده است، مانند عربستان سعودی و بریتانیا، که در سال 2014 آن را مسدود کردند. امارات متحده عربی ، فنلاند و بلژیک همه آن را در سال 2018 ممنوع کردند.

    DEVCORE 2022 實習生計畫

    برنامه کارآموزی DEVCORE 2022 | DEVCORE دیو کول

    DEVCORE از زمان تأسیس خود در سال 2012 وارد دهمین سال خود شده است. ما به امنیت اطلاعات تایوان اهمیت زیادی می دهیم و بر شناسایی جدی ترین نقاط ضعف برای محافظت از جهان تمرکز می کنیم. اگرچه مقیاس شرکت به سرعت در حال گسترش نیست، در حالی که به تدریج جای پای محکمی به دست می‌آوریم، اما همچنان به هدف اصلی خود وفادار می‌مانیم: از سال 2020، بورسیه‌های امنیت اطلاعات را در دانشگاه فوژو و دانشگاه ملی علم و فناوری تایوان ایجاد خواهیم کرد. تا پایان سال 2021، جذب استعدادها را گسترش خواهیم داد و با همین فلسفه می خواهیم استعدادیابی کنیم، مبارزه کنیم؛ و اکنون به امید شکوفایی استعدادها و ارتقای مهارت های امنیت اطلاعات، شروع به برگزاری برنامه کارآموزی کرده ایم. از نسل جدید اگر به این برنامه علاقه دارید لطفا برای ثبت نام پیام دهید!

    محتوای کارآموزی

    این کارآموزی به دو گروه تقسیم می شود: باینری و وب. محتویات اصلی به شرح زیر است:

    • باینری
      تمرکز اصلی بر روی تحقیق است. مهندسی معکوس یا بررسی کد. ذهن خود را از طریق این فرآیند برای شناسایی سطوح حمله احتمالی و نقاط ضعف بالقوه آموزش دهید. علاوه بر این، به همه این امکان را می دهد که سعی کنند از آسیب پذیری های گذشته سوء استفاده کنند و آنها را به سلاح تبدیل کنند و تجربه کنند که چگونه از آسیب پذیری ها در دنیای واقعی سوء استفاده می شود.
      • استخراج و تحقیق آسیب‌پذیری 70 %
      • توسعه یک روزه (استثمار) و تسلیح‌سازی (تسلیح‌سازی) 30 درصد
    • وب
      محتوای اصلی مطالعه آسیب‌پذیری‌های اخیر در سال‌های اخیر و توسعه جدید رایج است. راهنمایی و کمک مربیان آسیب‌پذیری‌ها و روش‌های حمله را تایپ کنید، لازم است یک نمایش اسلاید برای معرفی نتایج و ساخت یک محیط آزمایش شبیه‌سازی (Lab) ایجاد کنید که بتواند آسیب‌پذیری را برای دیگران بازتولید کند، همچنین ممکن است نیاز به نوشتن یا اصلاح یک قابل بهره‌برداری باشد. برنامه حمله برای تأیید آسیب پذیری.
      • تحقیق در مورد آسیب‌پذیری‌ها و روش‌های حمله 70%
      • Build Lab 30%

    مکان شرکت

    طبقه 13، شماره 32، بخش 3، جاده باده، شهر سونگ‌شانیپ، منطقه Songshan 5، Tai [01959003،19659003]. 19659013] آوریل 2022 از ابتدای ماه تا پایان جولای، جمعاً 4 ماه.

  • دو روز در هفته، 10:00 تا 18:00
    • یک روز در هفته، 14:00 تا 18:00 بعد از ظهر، باید به شرکت بروید تا در مورد پیشرفت صحبت کنید
    • بقیه زمان کار از راه دور است
  • هدف استخدام

    کالج ها و دانشگاه ها ( فراگیر) فوق دارای مدرک معینی هستند دانشجویان با پیشینه امنیت اطلاعات

    تعداد تخمینی مکان هایی که باید استخدام شوند

    • گروه باینری: 2 نفر
    • گروه وب: 2 ~ 3 نفر

    درمان حقوق و دستمزد [196509003دلار] در هر ماه

    شرایط استخدام و فرآیند صلاحیت

    الزامات کارآموزی

    باینری

    • مهندسی معکوس اولیه و قابلیت های اشکال زدایی
      • می تواند زبان ترکیبی را بخواند و مهارت های اساسی Debugger را درک کند
    • توانایی بهره برداری از آسیب پذیری اولیه
      • شما باید مهارت های مربوطه مانند ROP، Heap Exploitation و غیره را بدانید.
    • توانایی توسعه زبان برنامه نویسی پایه
    • توانایی تجزیه و تحلیل پروژه های بزرگ منبع باز
    • دانش اولیه سیستم عامل را داشته باشد
      • برای مثال، مفهوم آدرس مجازی و آدرس فیزیکی را بدانید
    • حسابرسی کد
      • دانستن نحوه نوشتن کد مشکل خواهد داشت
        • سرریز بافر
        • استفاده پس از آزاد
        • شرایط مسابقه
    • دارای شور و شوق تحقیق هستند و به درک ماهیت فناوری عادت دارند
    • امتیازات پاداش اما نه شرایط ضروری
      • تجربه بازی CTF
      • pwnable.tw نتایج
      • دارای وبلاگ/اسلاید عمومی یا Write-ups فناوری عمومی
      • مسلط به IDA Pro یا Ghidra
      • برنامه 1-695006 را دنبال کنید. تجربه
        • Kernel Exploit
        • Windows Exploit
        • Browser Exploit
        • Bug Bounty

    Web

    • آشنا با 10 OWASP Web Top.
    • همه موضوعات امنیتی را در آکادمی امنیت وب PortSwigger درک کنید یا تمام آزمایشگاه ها را تکمیل کرده باشید.
      • لینک مرجع: https://portswigger.net/web-security/all-materials
    • مفاهیم اساسی شبکه های کامپیوتری را درک کنید.
    • با عملیات خط فرمان، از جمله ابزارهای دستوری رایج یا داخلی برای سیستم عامل های یونیکس و ویندوز آشنا است.
    • آشنا به هر زبان برنامه نویسی وب (مانند: PHP، ASP.NET، JSP)، با قابلیت ساخت یک وب سرویس کامل.
    • با هر زبان اسکریپتی (مانند شل اسکریپت، پایتون، روبی) آشنا است و می تواند از اسکریپت برای تکمیل تحقیقات استفاده کند.
    • با قابلیت های اشکال زدایی، می تواند از Debugger برای ردیابی جریان برنامه، بازتولید و همگرایی مشکلات به خوبی استفاده کند.
    • دارای توانایی ساخت و پیکربندی وب سرورهای رایج (به عنوان مثال: Nginx، Apache) و سیستم عامل ها (به عنوان مثال: لینوکس).
    • دارای روحیه بررسی علت اصلی است.
    • امتیاز جایزه اما شرایط لازم نیست
      • به طور مستقل آسیب پذیری های 0 روزه را استخراج کرده است.
      • به طور مستقل آسیب پذیری های شناخته شده را تجزیه و تحلیل کرد و توانست اکسپلویت های 1 روزه را بنویسد.
      • زمانی به عنوان سوال ساز در رقابت CTF خدمت کرد و سوال را ایجاد کرد.
      • دارای مجوز OSCP یا معادل آن.

    فرآیند درخواست

    این انتخاب به سه مرحله تقسیم می شود:

    مرحله اول: بررسی کتبی

    مرحله اول یک بررسی کتبی است و دو مورد زیر نیاز به بررسی دارند

    • کتبی بررسی [19659014] آزمون پاسخ کوتاه (2 سوال، لطفاً به روش ثبت نام زیر مراجعه کنید)

    ما با توجه به رزومه خود و محتوای سوالات پاسخ کوتاه تصمیم خواهیم گرفت که آیا مرحله اول را پشت سر گذاشته اید یا خیر، و در عرض پاسخ خواهیم داد. هفت روز کاری مرحله اول را گذرانده باشد و سوالات مرحله دوم را حسب مورد پیوست کرده باشد.

    مرحله دوم: تست توانایی

    • باینری
      • در مرحله دوم، شما تصمیم خواهید گرفت که آیا نیاز به انجام سوالات اضافی بر اساس رزومه خود دارید یا هر اطلاعاتی که می تواند ثابت کند مهارت های مربوط به باینری اکسپلویت را دارید یا خیر. آماده می شود.در اصل این مرحله حدودا دو هفته زمان می برد تا شما مشکل را حل کنید.لطفاً بعد از راه حل فرآیند حل مسئله (Write-up) را یادداشت کنید.پس از دریافت فرآیند حل مسئله ما تصمیم خواهد گرفت که آیا می توانید با توجه به شرایط خود وارد مرحله سوم شوید.
    • وب

    مرحله سوم: مصاحبه

    این مرحله یک مصاحبه 1 تا 2 ساعته است و 2 تا 3 شریک ارشد شرکت خواهند کرد تا ارزیابی کنند که آیا شما توانایی فنی و ویژگی های شخصیتی مورد نیاز برای این کارآموزی را دارید یا خیر.

    روش ثبت نام

    • لطفاً یک فایل PDF از رزومه و سوالات پاسخ کوتاه خود را تهیه و به [email protected] ارسال کنید.
      • لطفاً برای فرمت رزومه (DOCX، PAGES، PDF) به مثال مراجعه کنید و آن را به PDF تبدیل کنید. اگر اعتماد به نفس دارید، می توانید از رزومه خود استفاده کنید که به بهترین وجه توانایی های شما را نشان می دهد.
      • لطفاً آن را قبل از 2022/02/11 ارسال کنید (اگر تعداد مکان ها پر باشد، بنا به موقعیت زودتر بسته می شود)
    • قالب عنوان نامه: [應徵] نام موقعیت شما (مثال: [應徵] کارآموز وانگ شیائومی از گروه وب)
    • لطفاً رزومه خود را در دو صفحه نگه دارید و حداقل شامل موارد زیر باشد:
      • اطلاعات پایه
      • آموزش
      • تجربه کارآموزی
      • تجربه فعالیت در جامعه
      • اقدامات ویژه
      • تحقیقات گذشته در مورد امنیت اطلاعات
      • 09 مگابایت آزمون بین‌المللی شغلی [09TI6] وب سایت)
    • سوالات پاسخ کوتاه به شرح زیر است، لطفا بر اساس گروهی که می خواهید برای آن درخواست دهید پاسخ دهید، تعداد صفحات پاسخ محدودیتی ندارد، می توانید آزادانه بازی کنید.
      • باینری
        • فرض کنید می‌خواهید امروز یک وب سرور نوشته شده با C/C++ را تجزیه و تحلیل کنید، در حین اجرای برنامه، فکر می‌کنید در کجا ممکن است مشکلاتی پیش بیاید و باعث هک شدن جریان برنامه شود؟ چرا؟
        • در یک ماشین لینوکس، زمانی که ما در حال تجزیه و تحلیل CGI هستیم، از آنجایی که CGI توسط آپاچی فراخوانی می شود و ورودی را ارسال می کند، و بلافاصله پس از اجرا به پایان می رسد، چگونه این نوع برنامه را اشکال زدایی می کنید؟
      • وب
        • وقتی رشته ای از URL ها (به عنوان مثال: http://site.fake.devco.re/index.php?foo=bar) را در نوار آدرس مرورگر وب خود وارد می کنید، سپس Enter را فشار دهید تا صفحه وب ظاهر شود، وسط چه اتفاقی افتاد؟ لطفا با توجه به سوابق علمی خود تا حد امکان به صورت کلمات توضیح دهید.
        • با توجه به پاسخ به سؤالات فوق، می توان هر موقعیتی را به میل خود تصور کرد و مسائل امنیتی یا حمله به اهداف یا جنبه های حمله ای را که ممکن است در هر پیوند از موقعیت رخ دهد، به زبان توضیح داد.

    اگر در مورد برنامه سؤالی دارید، لطفاً از ایمیل برای تماس با ما استفاده کنید. برای هر گونه ناراحتی ایجاد شده پوزش می‌طلبیم. ما از نامه شما تشکر می‌کنیم و مشتاقانه منتظر پیوستن شما هستیم!

    .