روزی روزگاری، یا چگونه با کمک یک اورولوژیست و Roskomnadzor همه چیز را بشکنیم

این مقاله بر اساس یک آزمون بسیار موفق نوشته شده است که متخصصان Group-IB چند سال پیش انجام دادند: داستانی اتفاق افتاد که می‌توان آن را برای فیلم در بالیوود اقتباس کرد. حالا احتمالاً واکنش خواننده به دنبال خواهد بود: "اوه، یک مقاله روابط عمومی دیگر، دوباره اینها به تصویر کشیده می شوند، چقدر خوب هستند، فراموش نکنید که یک پنت بخرید." خوب، از یک طرف، این است. با این حال، دلایل دیگری وجود دارد که چرا این مقاله ظاهر شد. من می‌خواستم نشان دهم که pentesters دقیقاً چه کاری انجام می‌دهند، این کار چقدر می‌تواند جالب و بی‌اهمیت باشد، چه شرایط خنده‌داری می‌تواند در پروژه‌ها ایجاد شود، و مهمتر از همه، نمایش مطالب زنده با مثال‌های واقعی.

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

برای مشتری در این مقاله، همه چیز به طور کلی عالی بود، حداقل بهتر از 95٪ از بازار در فدراسیون روسیه، طبق احساسات ما، اما تعدادی تفاوت های ظریف وجود داشت که زنجیره طولانی از رویدادها را تشکیل می داد، که ابتدا منجر به گزارشی طولانی از کار و سپس به این مقاله شد.

پس بیایید پاپ کورن تهیه کنیم و به داستان کارآگاهی خوش آمدید. کلمه - پاول سوپرونیوک، مدیر فنی بخش "حسابرسی و مشاوره" Group-IB.

قسمت 1. دکتر پوچکین

2018 یک مشتری وجود دارد - یک شرکت فناوری اطلاعات پیشرفته که خود به مشتریان زیادی خدمات می دهد. می خواهد به این سوال پاسخ دهد: آیا می توان بدون هیچ دانش و دسترسی اولیه، با کار از طریق اینترنت، حقوق مدیر دامنه اکتیو دایرکتوری را به دست آورد؟ من علاقه ای به مهندسی اجتماعی ندارم (اوه، اما بیهوده)، آنها قصد ندارند عمداً در کار دخالت کنند، اما ممکن است به طور تصادفی - به عنوان مثال، یک سرور عجیب و غریب را بارگیری مجدد کنند. هدف اضافی شناسایی هر چه بیشتر بردارهای حمله دیگر در برابر محیط بیرونی است. این شرکت به طور مرتب چنین آزمایشاتی را انجام می دهد و اکنون مهلت آزمایش جدید فرا رسیده است. شرایط تقریباً معمولی، کافی، قابل درک است. بیا شروع کنیم.

یک نام مشتری وجود دارد - بگذارید "شرکت" با وب سایت اصلی باشد www.company.ru. البته نام مشتری متفاوت است، اما در این مقاله همه چیز غیرشخصی خواهد بود.
من شناسایی شبکه را انجام می دهم - دریابید که کدام آدرس ها و دامنه ها با مشتری ثبت شده اند، یک نمودار شبکه ترسیم کنید، چگونه خدمات به این آدرس ها توزیع می شود. من نتیجه را دریافت می کنم: بیش از 4000 آدرس IP زنده. من به دامنه‌های این شبکه‌ها نگاه می‌کنم: خوشبختانه، اکثریت قریب به اتفاق شبکه‌هایی هستند که برای مشتریان مشتری در نظر گرفته شده‌اند و ما به طور رسمی به آنها علاقه‌ای نداریم. مشتری هم همین فکر را می کند.

یک شبکه با 256 آدرس باقی مانده است، که در حال حاضر درک درستی از توزیع دامنه ها و زیر دامنه ها توسط آدرس های IP وجود دارد، اطلاعاتی در مورد پورت های اسکن شده وجود دارد، به این معنی که می توانید به سرویس ها برای موارد جالب نگاه کنید. به موازات آن، انواع اسکنرها بر روی آدرس های IP موجود و به طور جداگانه در وب سایت ها راه اندازی می شوند.

خدمات زیادی وجود دارد. معمولاً این شادی برای پنتستر و انتظار یک پیروزی سریع است، زیرا هر چه تعداد سرویس‌ها بیشتر باشد، میدان حمله بزرگ‌تر است و یافتن یک مصنوع آسان‌تر است. نگاهی گذرا به وب سایت ها نشان داد که بیشتر آنها رابط های وب محصولات شناخته شده شرکت های بزرگ جهانی هستند که به هر حال به شما می گوید که از آنها استقبال نمی شود. آنها یک نام کاربری و رمز عبور می‌خواهند، میدان را برای وارد کردن فاکتور دوم تکان می‌دهند، گواهی مشتری TLS را می‌خواهند، یا آن را به Microsoft ADFS ارسال می‌کنند. برخی از آنها به سادگی از طریق اینترنت قابل دسترسی نیستند. برای برخی، بدیهی است که شما باید یک مشتری ویژه با پرداخت سه حقوق داشته باشید یا URL دقیق را برای وارد کردن بدانید. بیایید یک هفته دیگر از ناامیدی تدریجی در روند تلاش برای شکستن نسخه‌های نرم‌افزار برای آسیب‌پذیری‌های شناخته‌شده، جستجوی محتوای پنهان در مسیرهای وب و حساب‌های لو رفته از سرویس‌های شخص ثالث مانند LinkedIn، تلاش برای حدس زدن رمزهای عبور با استفاده از آنها بگذریم. به عنوان حفاری آسیب‌پذیری‌ها در وب‌سایت‌های خودنویس - به هر حال، طبق آمار، این امیدوارکننده‌ترین بردار حمله خارجی امروز است. من فوراً به اسلحه فیلمی که متعاقباً شلیک شد توجه خواهم کرد.

بنابراین، ما دو سایت پیدا کردیم که از صدها سرویس متمایز بودند. این سایت‌ها یک چیز مشترک داشتند: اگر درگیر شناسایی دقیق شبکه بر اساس دامنه نباشید، اما به دنبال پورت‌های باز باشید یا یک اسکنر آسیب‌پذیری را با استفاده از یک محدوده IP شناخته‌شده هدف قرار دهید، این سایت‌ها از اسکن فرار می‌کنند و به سادگی نمی‌شوند. بدون دانستن نام DNS قابل مشاهده است. شاید حداقل آنها زودتر از دست رفته باشند و ابزارهای خودکار ما هیچ مشکلی با آنها پیدا نکردند، حتی اگر مستقیماً به منبع ارسال شوند.

به هر حال، در مورد آنچه که اسکنرهای قبلاً راه اندازی شده به طور کلی پیدا کردند. اجازه دهید یادآوری کنم: برای برخی افراد، "pentest" معادل "اسکن خودکار" است. اما اسکنرهای این پروژه چیزی نگفتند. خوب، حداکثر با آسیب‌پذیری‌های متوسط ​​(3 از 5 از نظر شدت) نشان داده شد: در برخی از سرویس‌ها یک گواهی TLS بد یا الگوریتم‌های رمزگذاری قدیمی، و در بیشتر سایت‌ها Clickjacking. اما این شما را به هدفتان نمی رساند. شاید اسکنرها در اینجا مفیدتر باشند، اما اجازه دهید به شما یادآوری کنم: خود مشتری می تواند چنین برنامه هایی را خریداری کند و خود را با آنها آزمایش کند، و با قضاوت بر اساس نتایج ناگوار، قبلاً بررسی کرده است.

بیایید به سایت های "ناهنجار" برگردیم. اولین مورد چیزی شبیه یک ویکی محلی در یک آدرس غیر استاندارد است، اما در این مقاله اجازه دهید wiki.company[.]ru باشد. او همچنین بلافاصله درخواست ورود و رمز عبور کرد، اما از طریق NTLM در مرورگر. برای کاربر، این مانند یک پنجره مرتاض به نظر می رسد که از شما می خواهد نام کاربری و رمز عبور را وارد کنید. و این عمل بدی است.

یک یادداشت کوچک NTLM در وب سایت های پیرامونی به دلایلی بد است. دلیل اول فاش شدن نام دامنه Active Directory است. در مثال ما نیز معلوم شد که company.ru است، درست مانند نام DNS "خارجی". با دانستن این موضوع، می‌توانید با دقت چیزهای مخربی را آماده کنید تا فقط در ماشین دامنه سازمان اجرا شود و نه در جعبه شنی. ثانیاً، احراز هویت مستقیماً از طریق کنترل‌کننده دامنه از طریق NTLM انجام می‌شود (تعجب، درست است؟)، با تمام ویژگی‌های سیاست‌های شبکه «داخلی»، از جمله مسدود کردن حساب‌ها از بیش از تعداد تلاش‌های وارد کردن رمز عبور. اگر یک مهاجم متوجه ورود به سیستم شود، رمز عبور را برای آنها امتحان می کند. اگر به گونه ای پیکربندی شده باشید که حساب ها را از وارد کردن رمزهای عبور نادرست مسدود کنید، کار می کند و حساب مسدود می شود. سوم، اضافه کردن عامل دوم به چنین احراز هویت غیرممکن است. اگر یکی از خوانندگان هنوز می داند چگونه، لطفا به من اطلاع دهید، واقعا جالب است. چهارم، آسیب پذیری در برابر حملات پاس هش. ADFS از جمله برای محافظت در برابر همه این موارد اختراع شد.

یک ویژگی بد محصولات مایکروسافت وجود دارد: حتی اگر به طور خاص چنین NTLM را منتشر نکرده باشید، حداقل به طور پیش فرض در OWA و Lync نصب می شود.

به هر حال، نویسنده این مقاله یک بار به طور تصادفی تقریباً 1000 حساب کارمند یک بانک بزرگ را تنها در یک ساعت با همین روش مسدود کرد و سپس تا حدودی رنگ پریده به نظر رسید. خدمات فناوری اطلاعات بانک نیز کم رنگ بود، اما همه چیز به خوبی و به اندازه کافی به پایان رسید، ما حتی به دلیل اینکه اولین نفری بودیم که این مشکل را پیدا کردیم و یک راه حل سریع و قاطع را تحریک کردیم، تحسین شدیم.

سایت دوم آدرس "بدیهی است که نوعی نام خانوادگی.company.ru" بود. آن را از طریق گوگل پیدا کردم، چیزی شبیه به این در صفحه 10. طرح مربوط به اوایل و اواسط دهه XNUMX بود و یک شخص محترم از صفحه اصلی به آن نگاه می کرد، چیزی شبیه به این:

در اینجا من عکسی از "قلب سگ" گرفتم، اما باور کنید، به طور مبهم شبیه بود، حتی طرح رنگ ها نیز در تناژهای مشابه بود. اجازه دهید سایت نامیده شود preobrazhensky.company.ru.

این یک وب سایت شخصی بود ... برای یک متخصص اورولوژی. من تعجب کردم که وب سایت یک متخصص اورولوژی در زیر دامنه یک شرکت با فناوری پیشرفته چه می کند. جستجوی سریع در گوگل نشان داد که این پزشک یکی از بنیانگذاران یکی از اشخاص حقوقی مشتری ما بوده و حتی حدود 1000 روبل در سرمایه مجاز کمک کرده است. این سایت احتمالا سال ها پیش ایجاد شده است و از منابع سرور مشتری به عنوان میزبان استفاده می شود. این سایت مدتهاست ارتباط خود را از دست داده است ، اما به دلایلی برای مدت طولانی کار می کند.

از نظر آسیب پذیری، خود وب سایت امن بود. با نگاهی به آینده، می گویم که این مجموعه ای از اطلاعات ثابت بود - صفحات html ساده با تصاویر درج شده به شکل کلیه ها و مثانه ها. "شکستن" چنین سایتی بی فایده است.

اما وب سرور زیر آن جالب تر بود. با توجه به هدر سرور HTTP، دارای IIS 6.0 بود، به این معنی که از ویندوز 2003 به عنوان سیستم عامل استفاده می کرد. اسکنر قبلاً تشخیص داده بود که این وب سایت اورولوژیست خاص، بر خلاف سایر میزبان های مجازی روی همان وب سرور، به فرمان PROPFIND پاسخ می دهد، به این معنی که WebDAV را اجرا می کند. به هر حال، اسکنر این اطلاعات را با علامت Info برگرداند (به زبان گزارش های اسکنر، این کمترین خطر است) - معمولاً چنین مواردی به سادگی نادیده گرفته می شوند. در ترکیب، این یک اثر جالب بود که تنها پس از بررسی دیگری در Google آشکار شد: یک آسیب‌پذیری نادر سرریز بافر مرتبط با مجموعه Shadow Brokers، یعنی CVE-2017-7269، که قبلاً یک سوء استفاده آماده داشت. به عبارت دیگر، اگر ویندوز 2003 دارید و WebDAV روی IIS اجرا می شود، مشکل ایجاد می شود. اگرچه اجرای ویندوز 2003 در حال تولید در سال 2018 به خودی خود یک مشکل است.

این اکسپلویت به Metasploit ختم شد و بلافاصله با یک بار آزمایش شد که یک درخواست DNS را به یک سرویس کنترل شده ارسال می کرد - Burp Collaborator به طور سنتی برای گرفتن درخواست های DNS استفاده می شود. در کمال تعجب، اولین بار کار کرد: یک حذف DNS دریافت شد. در مرحله بعد، تلاشی برای ایجاد یک اتصال پشتیبان از طریق پورت 80 (یعنی اتصال شبکه از سرور به مهاجم، با دسترسی به cmd.exe در میزبان قربانی) انجام شد، اما پس از آن یک شکست اتفاق افتاد. این ارتباط برقرار نشد و پس از سومین تلاش برای استفاده از سایت به همراه تمام تصاویر جالب برای همیشه ناپدید شد.

معمولاً به دنبال آن نامه ای به سبک "مشتری، بیدار شو، ما همه چیز را رها کردیم" دنبال می شود. اما به ما گفته شد که سایت هیچ ربطی به فرآیندهای تجاری ندارد و بدون هیچ دلیلی مانند کل سرور در آنجا کار می کند و ما می توانیم هر طور که می خواهیم از این منبع استفاده کنیم.
حدود یک روز بعد سایت به طور ناگهانی شروع به کار کرد. با ساختن یک بنچ از WebDAV در IIS 6.0، متوجه شدم که تنظیمات پیش فرض این است که فرآیندهای کارگر IIS را هر 30 ساعت یکبار راه اندازی مجدد کنند. یعنی وقتی کنترل از shellcode خارج شد، فرآیند کارگر IIS به پایان رسید، سپس چند بار خود را مجدداً راه اندازی کرد و سپس به مدت 30 ساعت استراحت کرد.

از آنجایی که بار اول اتصال به tcp از کار افتاد، من این مشکل را به یک پورت بسته نسبت دادم. یعنی وجود نوعی فایروال را فرض کرد که به اتصالات خروجی اجازه عبور از بیرون را نمی داد. من شروع به اجرای کدهای پوسته کردم که در بسیاری از پورت های tcp و udp جستجو کردند، هیچ تاثیری نداشت. بارهای اتصال معکوس از طریق http(s) از Metasploit کار نکرد - meterpreter/reverse_http(s). ناگهان یک اتصال به همان پورت 80 برقرار شد، اما بلافاصله قطع شد. من این را به عملکرد IPS تخیلی نسبت دادم که ترافیک مترفتر را دوست نداشت. با توجه به این واقعیت که یک اتصال tcp خالص به پورت 80 انجام نشد، اما یک اتصال http انجام شد، به این نتیجه رسیدم که یک پروکسی http به نوعی در سیستم پیکربندی شده است.

من حتی مترپرتر را از طریق DNS امتحان کردم (با تشکر d00kie برای تلاش‌های شما، پروژه‌های زیادی را ذخیره کرد)، با یادآوری اولین موفقیت، اما حتی روی پایه هم کار نکرد - کد پوسته برای این آسیب‌پذیری بسیار حجیم بود.

در واقعیت، به نظر می رسید: 3-4 تلاش برای حمله در عرض 5 دقیقه، سپس 30 ساعت منتظر می ماند. و به همین ترتیب برای سه هفته متوالی. حتی یک یادآوری هم گذاشتم که وقت را تلف نکنم. علاوه بر این، تفاوتی در رفتار محیط آزمایش و تولید وجود داشت: برای این آسیب‌پذیری دو اکسپلویت مشابه وجود داشت، یکی از Metasploit، دومی از اینترنت، که از نسخه Shadow Brokers تبدیل شده بود. بنابراین، فقط متاسپلویت در مبارزه آزمایش شد، و تنها دومی روی نیمکت آزمایش شد، که اشکال زدایی را حتی دشوارتر کرد و مغز را متلاشی کرد.

در پایان، یک کد پوسته ای که یک فایل exe را از یک سرور معین از طریق http دانلود می کرد و آن را روی سیستم هدف راه اندازی می کرد، موثر بود. کد پوسته به اندازه کافی کوچک بود که جا بیفتد، اما حداقل کار می کرد. از آنجایی که سرور به هیچ وجه از ترافیک TCP خوشش نمی‌آمد و http(ها) از نظر وجود مترپرتر بررسی می‌شد، تصمیم گرفتم که سریع‌ترین راه این باشد که یک فایل exe که حاوی DNS-meterpreter است را از طریق این پوسته دانلود کنم.

در اینجا دوباره یک مشکل ایجاد شد: هنگام بارگیری یک فایل exe و همانطور که تلاش ها نشان داد، مهم نیست که کدام یک، دانلود قطع شد. باز هم، برخی از دستگاه های امنیتی بین سرور من و متخصص اورولوژی از ترافیک http با یک exe در داخل خوششان نمی آید. به نظر می‌رسد راه‌حل «سریع» تغییر کد پوسته است تا ترافیک http را در لحظه مبهم کند، به طوری که داده‌های باینری انتزاعی به جای exe منتقل شوند. در نهایت، حمله با موفقیت انجام شد، کنترل از طریق کانال نازک DNS دریافت شد:

بلافاصله مشخص شد که من ابتدایی ترین حقوق گردش کار IIS را دارم که به من اجازه نمی دهد هیچ کاری انجام دهم. این چیزی است که در کنسول Metasploit به نظر می رسید:

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

با فرض اینکه این سرور ویندوز 2003 برای آسیب‌پذیری معروف MS17-010 تعمیر نشده است، من ترافیک را به پورت 445/TCP از طریق تونل DNS مترپرتر به لوکال هاست تونل می‌کنم (بله، این نیز امکان‌پذیر است) و سعی می‌کنم exe را که قبلا دانلود شده است اجرا کنم. آسیب پذیری حمله کار می کند، من یک اتصال دوم دریافت می کنم، اما با حقوق SYSTEM.

جالب است که آنها همچنان سعی کردند از سرور در برابر MS17-010 محافظت کنند - سرویس های شبکه آسیب پذیر در رابط خارجی غیرفعال شده بود. این امر در برابر حملات از طریق شبکه محافظت می کند، اما حمله از داخل به لوکال هاست جواب داد، زیرا نمی توانید به سرعت SMB را در لوکال هاست خاموش کنید.

در مرحله بعد، جزئیات جالب جدید فاش می شود:

1. با داشتن حقوق SYSTEM، می توانید به راحتی یک اتصال پشتیبان از طریق TCP برقرار کنید. بدیهی است که غیرفعال کردن مستقیم TCP برای کاربران محدود IIS یک مشکل است. اسپویلر: ترافیک کاربر IIS به نحوی در پروکسی ISA محلی در هر دو جهت پیچیده شده بود. دقیقا چگونه کار می کند، من تکثیر نکرده ام.
2. من در یک "DMZ" خاص هستم (و این یک دامنه Active Directory نیست، بلکه یک WORKGROUP است) - منطقی به نظر می رسد. اما به جای آدرس IP خصوصی (خاکستری) مورد انتظار، من یک آدرس IP کاملاً سفید دارم، دقیقاً همان آدرسی که قبلاً به آن حمله کردم. این بدان معناست که این شرکت در دنیای آدرس‌دهی IPv4 آنقدر قدیمی است که می‌تواند طبق این طرح، همانطور که در کتابچه‌های راهنمای سیسکو در سال 128 نشان داده شده است، یک منطقه DMZ برای 2005 آدرس "سفید" بدون NAT حفظ کند.

از آنجایی که سرور قدیمی است، Mimikatz تضمین می شود که مستقیماً از حافظه کار کند:

رمز عبور مدیر محلی را دریافت می کنم، ترافیک RDP را از طریق TCP تونل می کنم و وارد یک دسکتاپ دنج می شوم. از آنجایی که می‌توانستم هر کاری که می‌خواهم با سرور انجام دهم، آنتی ویروس را حذف کردم و متوجه شدم که سرور فقط از طریق پورت TCP 80 و 443 از اینترنت قابل دسترسی است و 443 مشغول نیست. من یک سرور OpenVPN روی 443 راه اندازی کردم، توابع NAT را برای ترافیک VPN خود اضافه کردم و از طریق OpenVPN خود به صورت نامحدود به شبکه DMZ دسترسی مستقیم دارم. قابل توجه است که ISA با داشتن برخی از عملکردهای غیرفعال IPS، ترافیک من را با اسکن پورت مسدود کرد که برای آن باید با یک RRAS ساده تر و سازگارتر جایگزین می شد. بنابراین، مداخله‌گران گاهی اوقات هنوز مجبورند انواع چیزها را مدیریت کنند.

یک خواننده با دقت می پرسد: "در مورد سایت دوم - ویکی با احراز هویت NTLM، که در مورد آن بسیار نوشته شده است، چطور؟" بیشتر در این مورد بعدا.

قسمت 2. هنوز رمزگذاری نمی کنید؟ سپس ما در حال حاضر در اینجا به شما می آییم

بنابراین، دسترسی به بخش شبکه DMZ وجود دارد. شما باید به مدیر دامنه بروید. اولین چیزی که به ذهن می رسد بررسی خودکار امنیت سرویس ها در بخش DMZ است، به خصوص که بسیاری از آنها اکنون برای تحقیق باز هستند. یک تصویر معمولی در طول تست نفوذ: محیط خارجی بهتر از سرویس های داخلی محافظت می شود، و هنگام دستیابی به هر گونه دسترسی در یک زیرساخت بزرگ، به دست آوردن حقوق توسعه یافته در یک دامنه بسیار آسان تر است تنها به این دلیل که این دامنه شروع به تبدیل شدن می کند. دسترسی به ابزارها و ثانیاً، در زیرساختی با چندین هزار میزبان، همیشه چند مشکل حیاتی وجود خواهد داشت.

من اسکنرها را از طریق DMZ از طریق یک تونل OpenVPN شارژ می کنم و منتظر می مانم. گزارش را باز می کنم - باز هم چیز جدی نیست، ظاهراً کسی قبل از من همان روش را طی کرده است. مرحله بعدی بررسی نحوه ارتباط میزبان ها در شبکه DMZ است. برای انجام این کار، ابتدا Wireshark معمولی را راه اندازی کنید و به درخواست های پخش، در درجه اول ARP گوش دهید. بسته های ARP در تمام طول روز جمع آوری شد. به نظر می رسد که چندین دروازه در این بخش استفاده می شود. این بعداً مفید خواهد بود. با ترکیب داده‌های مربوط به درخواست‌ها و پاسخ‌های ARP و داده‌های اسکن پورت، نقاط خروجی ترافیک کاربر را از داخل شبکه محلی علاوه بر سرویس‌هایی که قبلاً شناخته شده بودند، مانند وب و پست، پیدا کردم.

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

Cain&Abel روی سرور اورولوژیست راه اندازی شد. با در نظر گرفتن جریان‌های ترافیک شناسایی‌شده، امیدوارکننده‌ترین جفت‌ها برای حمله Man-in-the-Middle انتخاب شدند و سپس مقداری ترافیک شبکه با راه‌اندازی کوتاه‌مدت به مدت 5-10 دقیقه، با تایمر برای راه‌اندازی مجدد سرور دریافت شد. در صورت یخ زدگی همانطور که در لطیفه دو خبر بود:

1. خوب: تعداد زیادی اعتبار جمع آوری شد و حمله به طور کلی کار کرد.
2. بد: تمام اعتبارنامه ها از مشتریان خود مشتری بود. در حین ارائه خدمات پشتیبانی، متخصصان مشتری به خدمات مشتریانی متصل می‌شوند که همیشه رمزگذاری ترافیک را پیکربندی نکرده‌اند.

در نتیجه، من اعتبارنامه های زیادی را به دست آوردم که در چارچوب پروژه بی فایده بودند، اما قطعاً برای نشان دادن خطر حمله جالب بودند. مسیریاب‌های مرزی شرکت‌های بزرگ با telnet، پورت‌های اشکال‌زدایی http به CRM داخلی با تمام داده‌ها، دسترسی مستقیم به RDP از ویندوز XP در شبکه محلی و سایر موارد تاریک. اینجوری معلوم شد سازش زنجیره تامین طبق ماتریس MITER.

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

این یک یادآوری دیگر برای رمزگذاری همه خدمات است. معلوم نیست چه کسی و چه زمانی داده های شما را به طور خاص می خواند و استفاده می کند - ارائه دهنده، مدیر سیستم یک شرکت دیگر یا چنین پنتیستر. من در مورد این واقعیت سکوت می کنم که بسیاری از مردم می توانند به سادگی ترافیک رمزگذاری نشده را رهگیری کنند.

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

پس از بررسی مجدد خدمات، ایده جالبی به ذهنم خطور کرد. چنین ابزاری به نام Responder وجود دارد (به راحتی می توان نمونه هایی از استفاده با این نام را پیدا کرد)، که با "مسموم سازی" درخواست های پخش، اتصالات را از طریق انواع پروتکل ها مانند SMB، HTTP، LDAP و غیره تحریک می کند. به روش های مختلف، سپس از همه کسانی که برای احراز هویت وصل می شوند می پرسد و آن را تنظیم می کند تا احراز هویت از طریق NTLM و در حالتی شفاف برای قربانی انجام شود. اغلب، مهاجم به این روش دست دادن NetNTLMv2 را جمع آوری می کند و با استفاده از یک فرهنگ لغت، رمزهای دامنه کاربر را به سرعت بازیابی می کند. در اینجا من چیزی مشابه می خواستم، اما کاربران "پشت یک دیوار" می نشستند، یا بهتر است بگوییم، آنها توسط یک فایروال از هم جدا شده بودند و از طریق خوشه پروکسی Blue Coat به وب دسترسی داشتند.

به یاد داشته باشید ، من مشخص کردم که نام دامنه Active Directory با دامنه "خارجی" مطابقت دارد ، یعنی company.ru بود؟ بنابراین، ویندوز، به‌طور دقیق‌تر اینترنت اکسپلورر (و اج و کروم)، به کاربر اجازه می‌دهد تا اگر فکر می‌کند که سایت در «منطقه اینترانت» قرار دارد، به‌طور شفاف در HTTP از طریق NTLM احراز هویت کند. یکی از نشانه های "اینترانت" دسترسی به آدرس IP "خاکستری" یا نام کوتاه DNS است، یعنی بدون نقطه. از آنجایی که آنها یک سرور با IP و نام DNS "سفید" داشتند preobrazhensky.company.ru، و ماشین های دامنه معمولا پسوند دامنه Active Directory را از طریق DHCP برای ورود ساده شده دریافت می کنند، آنها فقط باید URL را در نوار آدرس بنویسند. پرئوبراژنسکی، به طوری که آنها مسیر درست را برای سرور اورولوژیست آسیب دیده پیدا کنند، فراموش نکنید که اکنون به آن "اینترانت" می گویند. یعنی همزمان بدون اطلاع کاربر به من دست دادن NTLM را می دهد. تنها چیزی که باقی می ماند این است که مرورگرهای سرویس گیرنده را مجبور کنیم که در مورد نیاز فوری برای تماس با این سرور فکر کنند.

ابزار فوق العاده Intercepter-NG به کمک آمد (با تشکر رهگیر). این به شما اجازه می‌دهد تا ترافیک را به سرعت تغییر دهید و در ویندوز 2003 عالی کار می‌کند. حتی عملکرد جداگانه‌ای برای تغییر تنها فایل‌های جاوا اسکریپت در جریان ترافیک داشت. یک نوع اسکریپت بین سایتی عظیم برنامه ریزی شده بود.

پراکسی های کت آبی، که از طریق آن کاربران به وب جهانی دسترسی پیدا می کردند، به صورت دوره ای محتوای ثابت را در حافظه پنهان ذخیره می کردند. با رهگیری ترافیک، واضح بود که آنها به صورت شبانه روزی کار می کردند و بی وقفه درخواست استاتیک پرکاربرد برای سرعت بخشیدن به نمایش محتوا در ساعات اوج مصرف داشتند. علاوه بر این، BlueCoat یک User-Agent خاص داشت که به وضوح آن را از یک کاربر واقعی متمایز می کرد.

جاوا اسکریپت آماده شد که با استفاده از Intercepter-NG به مدت یک ساعت در شب برای هر پاسخ با فایل های JS برای Blue Coat پیاده سازی شد. اسکریپت کارهای زیر را انجام داد:

• مرورگر فعلی توسط User-Agent تعیین شد. اگر اینترنت اکسپلورر، اج یا کروم بود، به کار خود ادامه می داد.
• صبر کردم تا DOM صفحه تشکیل شود.
• یک تصویر نامرئی را با ویژگی src فرم در DOM درج کرد پرئوبراژنسکی:8080/NNNNNN.png، که در آن NNN اعداد دلخواه هستند تا BlueCoat آن را کش نمی‌کند.
• یک متغیر پرچم جهانی تنظیم کنید تا نشان دهد که تزریق کامل شده است و دیگر نیازی به درج تصاویر نیست.

مرورگر سعی کرد این تصویر را بارگیری کند؛ در پورت 8080 سرور در معرض خطر، یک تونل TCP منتظر آن به لپ تاپ من بود، جایی که همان Responder در حال اجرا بود و مرورگر را ملزم به ورود از طریق NTLM می کرد.

با قضاوت بر اساس گزارش های Responder، مردم صبح سر کار آمدند، ایستگاه های کاری خود را روشن کردند، سپس به طور انبوه و بدون توجه شروع به بازدید از سرور اورولوژیست کردند و فراموش نکردند که دست دادن های NTLM را تخلیه کنند. دست دادن ها در تمام طول روز بارید و به وضوح مطالبی را برای یک حمله موفقیت آمیز برای بازیابی رمزهای عبور جمع آوری کرد. گزارش های Responder به این صورت بود:

بازدیدهای مخفیانه دسته جمعی از سرور اورولوژیست توسط کاربران

احتمالاً قبلاً متوجه شده اید که کل این داستان بر اساس این اصل ساخته شده است: "همه چیز خوب بود، اما پس از آن یک بدبختی رخ داد، سپس یک غلبه وجود داشت، و سپس همه چیز به موفقیت رسید." بنابراین، اینجا یک افتضاح بود. از پنجاه دست دادن منحصر به فرد، حتی یک مورد هم فاش نشد. و این واقعیت را در نظر می گیرد که حتی در یک لپ تاپ با پردازنده مرده، این دست دادن های NTLMv2 با سرعت چند صد میلیون بار در ثانیه پردازش می شوند.

مجبور شدم خودم را با تکنیک های جهش رمز عبور، یک کارت گرافیک، یک فرهنگ لغت ضخیم تر مسلح کنم و منتظر بمانم. پس از مدت ها، چندین حساب کاربری با رمزهای عبور به فرم "Q11111111....1111111q" فاش شد که نشان می دهد زمانی همه کاربران مجبور به ایجاد رمز عبور بسیار طولانی با حروف مختلف بودند که همچنین قرار بود پیچیده باشد اما شما نمی توانید یک کاربر باتجربه را فریب دهید، و به این ترتیب او به خاطر سپردن آن برای خودش آسان تر می کند. در مجموع، حدود 5 حساب در معرض خطر قرار گرفت و تنها یکی از آنها دارای حقوق ارزشمندی در مورد خدمات بود.

قسمت 3. Roskomnadzor ضربه می زند

بنابراین، اولین حساب های دامنه دریافت شد. اگر پس از مطالعه طولانی تا این لحظه خوابتان نبرد، احتمالاً به یاد خواهید آورد که من به سرویسی اشاره کردم که به فاکتور دوم تأیید اعتبار نیاز نداشت: این یک ویکی با تأیید اعتبار NTLM است. البته اولین کاری که باید انجام داد ورود به آنجا بود. کاوش در پایگاه دانش داخلی به سرعت نتایج زیر را به همراه داشت:

• این شرکت دارای یک شبکه WiFi با احراز هویت با استفاده از حساب های دامنه با دسترسی به شبکه محلی است. با مجموعه داده‌های فعلی، این در حال حاضر یک بردار حمله فعال است، اما باید با پاهای خود به دفتر بروید و در جایی در قلمرو دفتر مشتری قرار بگیرید.
• دستورالعملی پیدا کردم که طبق آن سرویسی وجود داشت که به... اجازه می داد اگر کاربر در داخل یک شبکه محلی است و با اطمینان نام دامنه و رمز عبور خود را به خاطر می آورد، به طور مستقل یک دستگاه احراز هویت "عامل دوم" را ثبت کند. در این مورد، "درون" و "خارج" با دسترسی به پورت این سرویس برای کاربر تعیین شد. پورت از طریق اینترنت قابل دسترسی نبود، اما از طریق DMZ کاملاً قابل دسترسی بود.

البته بلافاصله یک "عامل دوم" در قالب یک برنامه در تلفن من به حساب در معرض خطر اضافه شد. برنامه‌ای وجود داشت که می‌توانست با صدای بلند درخواست فشار را با دکمه‌های «تأیید»/ «نپذیرفتن» برای عمل به تلفن ارسال کند، یا به‌طور بی‌صدا کد OTP را برای ورود مستقل بیشتر روی صفحه نمایش دهد. علاوه بر این، اولین روش طبق دستورالعمل ها قرار بود تنها روش صحیح باشد، اما برخلاف روش OTP کار نکرد.

با شکسته شدن "فاکتور دوم"، من توانستم به ایمیل Outlook Web Access و دسترسی از راه دور در دروازه Citrix Netscaler دسترسی داشته باشم. یک سورپرایز در ایمیل در Outlook وجود داشت:

در این عکس نادر می توانید ببینید که Roskomnadzor چگونه به نفوذگران کمک می کند

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

هر کسی که با Citrix Netscaler آشنا باشد تصور می کند که معمولاً به گونه ای پیاده سازی می شود که فقط یک رابط تصویر می تواند به کاربر منتقل شود و سعی می کند ابزاری برای راه اندازی برنامه های شخص ثالث و انتقال داده ها در اختیار او قرار ندهد و از هر نظر اقدامات را محدود کند. از طریق پوسته های کنترل استاندارد. "قربانی" من به دلیل شغلش فقط 1C گرفت:

پس از کمی قدم زدن در رابط 1C، متوجه شدم که ماژول های پردازش خارجی در آنجا وجود دارد. آنها را می توان از رابط بارگذاری کرد، و بسته به حقوق و تنظیمات، روی کلاینت یا سرور اجرا می شوند.

من از دوستان برنامه نویس 1C خود خواستم پردازشی ایجاد کنند که یک رشته را بپذیرد و آن را اجرا کند. در زبان 1C، شروع یک فرآیند چیزی شبیه به این است (برگرفته از اینترنت). آیا موافقید که نحو زبان 1C مردم روسی زبان را با خودانگیختگی خود شگفت زده می کند؟

پردازش کاملاً انجام شد؛ معلوم شد که نفوذگران آن را "پوسته" می نامند - Internet Explorer از طریق آن راه اندازی شد.

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

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

AppLocker در سرور برنامه‌ای که Citrix را اجرا می‌کرد فعال شد، اما دور زد. همان Meterpreter از طریق DNS بارگیری و راه اندازی شد، زیرا نسخه های http (ها) نمی خواستند وصل شوند و من در آن زمان آدرس پروکسی داخلی را نمی دانستم. به هر حال، از این لحظه به بعد، پنت خارجی اساساً به طور کامل به درونی تبدیل شد.

قسمت 4. حقوق ادمین برای کاربران بد است، خوب است؟

اولین وظیفه پنتستر هنگام به دست آوردن کنترل جلسه کاربر دامنه، جمع آوری تمام اطلاعات مربوط به حقوق در دامنه است. یک ابزار BloodHound وجود دارد که به طور خودکار به شما امکان می دهد اطلاعات مربوط به کاربران، رایانه ها، گروه های امنیتی را از طریق پروتکل LDAP از یک کنترل کننده دامنه و از طریق SMB دانلود کنید - اطلاعاتی در مورد اینکه کدام کاربر اخیراً در کجا و چه کسی مدیر محلی است.

یک تکنیک معمولی برای تصرف حقوق سرپرست دامنه به عنوان چرخه ای از اقدامات یکنواخت ساده به نظر می رسد:

• ما به رایانه‌های دامنه می‌رویم که در آن حقوق سرپرست محلی وجود دارد، بر اساس حساب‌های دامنه قبلاً ضبط شده.
• ما Mimikatz را راه‌اندازی می‌کنیم و رمزهای عبور ذخیره‌شده، بلیط‌های Kerberos و هش‌های NTLM حساب‌های دامنه را که اخیراً به این سیستم وارد شده‌اند، دریافت می‌کنیم. یا تصویر حافظه فرآیند lsass.exe را حذف می کنیم و همین کار را در سمت خود انجام می دهیم. این به خوبی با ویندوزهای جوانتر از 2012R2/Windows 8.1 با تنظیمات پیش فرض کار می کند.
• ما تعیین می کنیم که حساب های در معرض خطر کجا دارای حقوق سرپرست محلی هستند. نکته اول را تکرار می کنیم. در برخی از مراحل ما حقوق مدیر کل دامنه را به دست می آوریم.

همانطور که برنامه نویسان 1C در اینجا می نویسند "پایان چرخه؛".

بنابراین، معلوم شد که کاربر ما یک مدیر محلی فقط در یک هاست با ویندوز 7 است که نام آن شامل کلمه "VDI" یا "زیرساخت دسکتاپ مجازی"، ماشین های مجازی شخصی است. احتمالاً منظور طراح سرویس VDI این بوده است که از آنجایی که VDI سیستم عامل شخصی کاربر است، حتی اگر کاربر محیط نرم افزار را مطابق میل خود تغییر دهد، میزبان همچنان می تواند "بارگذاری مجدد" شود. من هم فکر کردم که در کل ایده خوبی بود، به این میزبان شخصی VDI رفتم و یک لانه درست کردم:

• من یک کلاینت OpenVPN را در آنجا نصب کردم که یک تونل از طریق اینترنت به سرور من ایجاد کرد. مشتری باید مجبور می شد تا از همان Blue Coat با احراز هویت دامنه عبور کند، اما OpenVPN آن را، همانطور که می گویند، "بیرون از جعبه" انجام داد.
• OpenSSH روی VDI نصب شده است. خوب، واقعاً، ویندوز 7 بدون SSH چیست؟

این همان چیزی است که به صورت زنده به نظر می رسید. بگذارید به شما یادآوری کنم که همه اینها باید از طریق Citrix و 1C انجام شود:

یکی از تکنیک‌های ارتقای دسترسی به رایانه‌های همسایه، بررسی گذرواژه‌های مدیر محلی برای مطابقت است. در اینجا شانس بلافاصله منتظر بود: هش NTLM مدیر محلی پیش‌فرض (که ناگهان Administrator نامیده شد) از طریق یک حمله هش به میزبان‌های VDI همسایه، که چند صد نفر از آنها وجود داشت، نزدیک شد. البته حمله بلافاصله به آنها اصابت کرد.

اینجا جایی است که مدیران VDI دو بار به پای خود شلیک کردند:

• اولین بار زمانی بود که ماشین‌های VDI تحت LAPS قرار نگرفتند، و اساساً همان رمز عبور مدیر محلی را از تصویری که به طور گسترده در VDI مستقر شده بود، حفظ کردند.
• مدیر پیش فرض تنها حساب محلی است که در برابر حملات هش آسیب پذیر است. حتی با یک رمز عبور مشابه، با ایجاد یک حساب کاربری مدیر محلی دوم با یک رمز عبور تصادفی پیچیده و مسدود کردن رمز عبور پیش فرض، می توان از سازش انبوه جلوگیری کرد.

چرا سرویس SSH در آن ویندوز؟ بسیار ساده: اکنون سرور OpenSSH نه تنها یک پوسته فرمان تعاملی مناسب را بدون تداخل در کار کاربر ارائه می دهد، بلکه یک پروکسی socks5 در VDI نیز ارائه می دهد. از طریق این جوراب، من از طریق SMB متصل شدم و حساب‌های کش شده را از تمام این صدها دستگاه VDI جمع‌آوری کردم، سپس مسیر مدیریت دامنه را با استفاده از آنها در نمودارهای BloodHound جستجو کردم. با صدها میزبانی که در اختیار داشتم، خیلی سریع این راه را پیدا کردم. حقوق مدیر دامنه به دست آمده است.

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

به هر حال، شرایط را از شروع پروژه به خاطر بسپارید - "از مهندسی اجتماعی استفاده نکنید". بنابراین، من پیشنهاد می کنم به این فکر کنیم که اگر هنوز امکان استفاده از فیشینگ پیش پا افتاده وجود داشت، چقدر این همه بالیوود با جلوه های ویژه قطع می شد. اما شخصاً انجام همه این کارها برای من بسیار جالب بود. امیدوارم از خواندن این مطلب لذت برده باشید. البته، هر پروژه ای چندان جذاب به نظر نمی رسد، اما کار به طور کلی بسیار چالش برانگیز است و اجازه نمی دهد که آن راکد بماند.

احتمالاً کسی سؤالی دارد: چگونه از خود محافظت کنیم؟ حتی این مقاله تکنیک‌های زیادی را توضیح می‌دهد که بسیاری از آنها مدیران ویندوز حتی درباره آن‌ها نمی‌دانند. با این حال، من پیشنهاد می‌کنم از منظر اصول هک‌شده و اقدامات امنیت اطلاعات به آنها نگاه کنیم:

• از نرم افزارهای قدیمی استفاده نکنید (ویندوز 2003 را در ابتدا به خاطر دارید؟)
• سیستم های غیر ضروری را روشن نگه ندارید (چرا وب سایت اورولوژیست وجود داشت؟)
• رمزهای عبور کاربر را برای قدرت بررسی کنید (در غیر این صورت سربازان ... نفوذگران این کار را انجام می دهند)
• گذرواژه‌های یکسانی برای حساب‌های مختلف نداشته باشید (VDI به خطر افتاده)
• و دیگر

البته اجرای این کار بسیار دشوار است، اما در مقاله بعدی در عمل نشان خواهیم داد که کاملاً امکان پذیر است.

منبع: www.habr.com