راه های هک و محافظت از جلسه شما در برابر سرقت

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

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

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

جلسه سایت

PHP احتمالاً رایج ترین زبان برنامه نویسی سمت سرور برای وب سایت ها است. در PHP، یک جلسه سایت با استفاده از دستور session_start() شروع می شود. قبل از شروع، می توانید مشخص کنید گزینه های اضافی. این جلسه معمولاً اطلاعات شخصی مهمی را در مورد کاربر ذخیره می کند: ورود، نام، رمز عبور، ...

ربودن جلسه

2 راه برای ذخیره شناسه جلسه وجود دارد: در کوکی ها و در نوار آدرس. گزینه اول قابل اعتمادتر از گزینه دوم است، اما هر دو تا یک درجه قابل هک هستند. این نوعهک کردن جلسه ربودن نامیده می شود.

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

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

هک جلسات

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

محافظت در برابر هک داده های جلسه

• جلسه را در کوکی ها ذخیره کنید. برداشتن آن سخت تر است.
• جلسه را به آدرس IP رایانه متصل کنید. هنگام ورود از یک IP دیگر، بسته به تنظیمات اسکریپت یک جلسه جدید ایجاد می شود.
• جلسه را به عامل کاربر مرورگر متصل کنید. هنگام ورود از مرورگر دیگری، جلسه بازنشانی می شود.
• رمزگذاری پارامترهای ارسال شده به جلسه اگر مهاجم فایل جلسه را دریافت کند، قادر به خواندن آن نخواهد بود. اگر چه، اگر مهارت های خاصی دارید، رمزگشایی جلسه نیز امکان پذیر است.
• شناسه های جلسه را در یک پوشه جداگانه ذخیره کنید. در php دستوری برای این وجود دارد: session_save_path($path_to_dir). همین تنظیمات را می توان در فایل php.ini مشخص کرد. پارامتر session.save_path نامیده می شود.
• از session_set_save_handler() در php برای نادیده گرفتن نحوه ذخیره شدن جلسه استفاده کنید. و با شروع از PHP 5.4، می توانید یک شی از نوع SessionHandlerInterface را به session_set_save_handler() منتقل کنید.

بسیاری از کاربران متوجه نیستند که با پر کردن یک نام کاربری و رمز عبور هنگام ثبت نام یا مجوز در یک منبع اینترنتی بسته و فشار دادن ENTER، این داده ها به راحتی قابل رهگیری هستند. اغلب آنها از طریق شبکه به شکل ناامن منتقل می شوند. بنابراین، اگر سایتی که قصد ورود به آن را دارید از پروتکل HTTP استفاده می کند، پس گرفتن این ترافیک، تجزیه و تحلیل آن با استفاده از Wireshark و سپس استفاده از فیلترها و برنامه های ویژه برای یافتن و رمزگشایی رمز عبور بسیار آسان است.

بهترین مکان برای رهگیری رمزهای عبور، هسته شبکه است، جایی که ترافیک همه کاربران هنگام ثبت نام در منابع خارجی به منابع بسته (مثلاً پست) یا جلوی روتر برای دسترسی به اینترنت می رود. ما یک آینه راه اندازی کردیم و آماده ایم که احساس کنیم یک هکر هستیم.

مرحله 1. Wireshark را نصب و راه اندازی کنید تا ترافیک را ضبط کنید

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

ضبط ترافیک آغاز شده است.

مرحله 2. فیلتر کردن ترافیک POST ضبط شده

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

یک فیلتر ویژه در پنجره وارد می کنیم تا بسته های ضبط شده را نمایش دهد: http.درخواست.روش ==”پست"

و می بینیم که به جای هزاران بسته، فقط یک بسته با داده هایی که به دنبال آن هستیم.

مرحله 3. ورود به سیستم و رمز عبور کاربر را پیدا کنید

کلیک سریع دکمه سمت راستماوس را انتخاب کنید و مورد را از منو انتخاب کنید TCP Steam را دنبال کنید

پس از این، متنی در پنجره جدیدی ظاهر می شود که محتوای صفحه را به صورت کد بازیابی می کند. بیایید فیلدهای "رمز عبور" و "کاربر" را پیدا کنیم که مربوط به رمز عبور و نام کاربری است. در برخی موارد، هر دو فیلد به راحتی قابل خواندن هستند و حتی رمزگذاری نمی شوند، اما اگر در هنگام دسترسی به منابع بسیار شناخته شده مانند Mail.ru، Facebook، VKontakte و غیره سعی در جذب ترافیک داشته باشیم، رمز عبور رمزگذاری می شود:

HTTP/1.1 302 پیدا شد

سرور: Apache/2.2.15 (CentOS)

X-Powered-By: PHP/5.3.3

P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Set-Cookie: password= ; انقضا=پنجشنبه، 07-نوامبر-2024 23:52:21 GMT; مسیر=/

مکان: loggedin.php

طول محتوا: 0

اتصال: بستن

نوع محتوا: text/html; charset=UTF-8

بنابراین، در مورد ما:

نام کاربری: networkguru

کلمه عبور:

مرحله 4. نوع رمزگذاری را برای رمزگشایی رمز عبور تعیین کنید

برای مثال به وب سایت http://www.onlinehashcrack.com/hash-identification.php#res بروید و رمز عبور خود را در پنجره شناسایی وارد کنید. لیستی از پروتکل های رمزگذاری به ترتیب اولویت به من داده شد:

مرحله 5. رمزگشایی رمز عبور کاربر

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

~# hashcat -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt

در خروجی یک رمز عبور رمزگشایی شده دریافت کردیم: simplepassword

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

• پروتکل و فیلتر POP به این صورت است: pop.request.command == "USER" || pop.request.command == "گذر"
• پروتکل و فیلتر IMAP به صورت زیر خواهد بود: imap.request حاوی "ورود" است
• پروتکل SMTP است و باید فیلتر زیر را وارد کنید: smtp.req.command == "AUTH"

و ابزارهای جدی تر برای رمزگشایی پروتکل رمزگذاری.

مرحله 6: اگر ترافیک رمزگذاری شده باشد و از HTTPS استفاده کند چه؟

چندین گزینه برای پاسخ به این سوال وجود دارد.

گزینه 1. هنگامی که اتصال بین کاربر و سرور قطع شد وصل شوید و ترافیک را در لحظه برقراری ارتباط بگیرید (SSL Handshake). هنگامی که یک اتصال برقرار می شود، کلید جلسه می تواند رهگیری شود.

گزینه 2: می‌توانید ترافیک HTTPS را با استفاده از فایل گزارش کلید جلسه ضبط شده توسط فایرفاکس یا کروم رمزگشایی کنید. برای انجام این کار، مرورگر باید طوری پیکربندی شود که این کلیدهای رمزگذاری را در یک فایل لاگ بنویسد (مثال مبتنی بر فایرفاکس) و شما باید آن فایل لاگ را دریافت کنید. در اصل، شما باید فایل کلید جلسه را از آن بدزدید هارد دیسککاربر دیگری (که غیرقانونی است). خوب، سپس ترافیک را ضبط کنید و از کلید حاصل برای رمزگشایی آن استفاده کنید.

شفاف سازی.ما در مورد مرورگر وب شخصی صحبت می کنیم که می خواهند رمز عبور او را بدزدند. اگر منظور ما رمزگشایی ترافیک HTTPS خودمان است و می‌خواهیم تمرین کنیم، این استراتژی جواب می‌دهد. اگر می‌خواهید ترافیک HTTPS سایر کاربران را بدون دسترسی به رایانه‌هایشان رمزگشایی کنید، این کار نمی‌کند - این هم رمزگذاری و هم حریم خصوصی است.

پس از دریافت کلیدها مطابق با گزینه 1 یا 2، باید آنها را در WireShark ثبت کنید:

1. به منوی Edit - Preferences - Protocols - SSL بروید.
2. پرچم "مجموعه مجدد رکوردهای SSL که چندین بخش TCP را در بر می گیرند" را تنظیم کنید.
3. "لیست کلیدهای RSA" و روی ویرایش کلیک کنید.
4. داده ها را در تمام فیلدها وارد کنید و با کلید مسیر را در فایل بنویسید

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

با توجه به اهمیت این موضوع، به عنوان بخشی از مجموعه ای از انتشارات، این سایت مروری بر امنیت پشته پروتکل TLS/SSL ارائه می دهد و همزمان استراتژی های منسجم و سیستماتیک برای تضعیف این پروتکل ها توسط آژانس های اطلاعاتی را بررسی می کند.

یک سوم ترافیک امن دنیا تولید می شود با ابزار رمزنگاریبا یک PRNG آشکارا ضعیف؟

از کانال حذف شد

به عنوان نقطه شروع، اجازه دهید به مثال روسیه بپردازیم - آخرین جلسه دادگاه در این پرونده مالک سابق سیستم پرداخت Chronopay Pavel Vrublevsky متهم به حمله DDoS علیه Aeroflot.

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

"FSB CIB، مطابق با قانون "فعالیت های عملیاتی-تحقیقی"، به طور مستقل اطلاعات را از کانال های ارتباطی افراد مشخص شده جمع آوری کرد و آن را در یک DVD ضبط کرد.

در واقع، دفاع متعاقباً توانست تأیید کند که مکاتبات شخصی لازم برخلاف میل فیس بوک "به طور کامل و حجمی از شبکه حذف شده است". در عین حال خود متهمان این پرونده ارائه گذرواژه و مکاتبات خودسرانه خود را به تحقیقات منکر شدند. در RuNet می توانید عناوین خبری پر زرق و برق مانند "FSB روسیه سرورهای فیس بوک هک شده" را بیابید، اما نباید در نتیجه گیری خود خیلی دور شوید.

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

آنها این سؤالات مستقیم را که در دادگاه از نمایندگان FSB پرسیده شد نادیده گرفتند. واضح‌ترین نسخه پاسخ خود را نشان می‌دهد: ترافیک HTTPS با این مکاتبات از قبل توسط FSB ضبط/ذخیره شده و به نوعی متعاقباً هک شده است.

جالب است که یک مورد تقریبا مشابه قبلاً در مواد همان پرونده ثبت شده بود. FSB CIB، با استناد به پروتکل تحقیقات، "با ذخیره و تجزیه و تحلیل ترافیک اتصال اینترنتی یکی از متهمان، ورود و رمز عبور را از کنترل پنل بات نت بازیابی کرد" (که به صورت فیزیکی در یک سرور در ایالات متحده قرار دارد) و سپس از راه دور توقیف شد. کنترل این بات نت بنابراین، دسترسی به همان پانل وب توسط متهم، مجدداً منحصراً از طریق یک اتصال HTTPS رمزگذاری شده، با رعایت اقدامات احتیاطی (به عنوان مثال، بدون ذخیره رمزهای عبور در رایانه محلی خود) انجام شد.

بنابراین، با ذکر موارد قابل توجه غلبه بر «محافظت» TLS/SSL توسط سرویس‌های اطلاعاتی روسیه، وجود مشکلاتی در امنیت HTTPS وجود دارد.

شیوه عمل

برای هک کردن یک جلسه HTTPS رمزگذاری شده، باید دو مشکل اصلی را حل کنید: توانایی گوش دادن (رهگیری) ترافیک، و همچنین قادر به رمزگشایی داده های محصور شده در چنین بسته محافظت شده ای.

از آنجایی که سرویس های ویژه تقریباً به هر کانالی دسترسی فیزیکی دارند، ما در مورد اولین نکته با جزئیات صحبت نخواهیم کرد. کسانی که آخرین اخبار SORMostroeniya را دنبال می کنند، از قبل می دانند که طبق قانون جدید، از 1 ژوئیه 2014، همه ارائه دهندگان روسی موظف هستند تجهیزات ویژه ای را در شبکه های خود نصب کنند تا ترافیک اینترنت ترانزیت خود را به طور کامل برای مدتی ضبط و ذخیره کنند. حداقل 12 ساعت علاوه بر این، نیروهای امنیتی به تمام مجموعه داده های ذخیره شده و انتقالی دسترسی مستقیم خواهند داشت.

جیمیل به من می نویسد: "حساب یا رایانه شما ممکن است توسط هکرهای تحت حمایت دولت در معرض خطر قرار گرفته باشد."

— رومن دوبرخوتوف (@Dobrokhotov) 9 سپتامبر 2014

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

خبر بد این است که فیس‌بوک، و همچنین سایر پورتال‌های اینترنتی بزرگ، از محرمانه‌سازی فوروارد استفاده نمی‌کنند، زیرا بار جدی دیگری بر روی شبکه‌های اجتماعی که قبلاً بیش از حد بار شده است، ایجاد می‌کند. علاوه بر این، استفاده از چنین الگوریتم های پیشرفته DH ممکن است بر سازگاری با برخی از مرورگرهای محبوب تأثیر منفی بگذارد. اکنون به راحتی می توان درک کرد که چرا، طبق آمار Netcraft تا تابستان 2013، تقریباً 70-99٪ از اتصالات SSL مشاهده شده در این نظارت اصلاً از FS استفاده نمی کنند.

یعنی در اکثریت قریب به اتفاق موارد، مهاجم می‌تواند با خیال راحت ترافیک HTTPS شما را برای هک کردن و هک کردن بعدی ذخیره کند (مثلاً وقتی کلید سرور خصوصی مشخص می‌شود).

در بالا اندازه گیری کاهش عملکرد در یک پردازنده وب سرور 6 هسته ای با حالت DHE فعال و غیرفعال شده است. DHE به عنوان محبوب ترین و مثال زدنی ترین نمونه اجرای Perfect Forward Secrecy انتخاب شده است. به عنوان مثال، گوگل، که خدماتش تقریباً از تمام نوآوری‌های رمزنگاری و ابزارهای محافظت از کاربرانش پشتیبانی می‌کند (این یک استثنای قابل توجه در رویه عمومی اینترنت است)، کلیدهای نشست کوتاه مدت PFS («فوق‌پایه») را بر اساس ECDHE_RSA پیاده‌سازی می‌کند. و این یک لذت بسیار بسیار گران است، باور کنید!

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

به نظر می رسد که الگوریتم کلی در این مورد چیزی شبیه به این خواهد بود: هنگامی که ترافیک مورد علاقه جلسه HTTPS توسط سرویس های اطلاعاتی فرضی رهگیری می شود، آنها سیستم اطلاعاتدرخواستی برای جستجوی کلید سرور مربوطه به پایگاه داده خود دریافت می کند. اگر چنین کلیدی پیدا نشد، برای محاسبه بیشتر (ترک) در صف قرار می گیرد. با در نظر گرفتن اظهار نظر در مورد در دسترس نبودن واقعی گزینه FS، همیشه منطقی است که ترافیک مورد علاقه را بی سر و صدا جمع آوری کنید (ثبت کنید)، بدون اینکه منتظر بمانید تا سیستم نسبت به آمادگی / در دسترس بودن کلید برای رمزگشایی در زمان واقعی واکنش نشان دهد.

در خصوص پایگاه مذکور از کلیدهای سرور، سپس در تابستان 2013، Cnet اطلاعات و یک سند نمونه از درخواست NSA را به یک شرکت اینترنتی بزرگ منتشر کرد که مایل بود ناشناس بماند. به گفته این منبع، مشخص شد که سایر پلتفرم های اینترنتی بزرگ (گوگل، مایکروسافت، اپل، یاهو، AOL، Verizon، AT&T و غیره) همین درخواست ها را دریافت کرده اند. Cnet رسما با این سازمان ها تماس گرفت تا در مورد این واقعیت اظهار نظر کند درخواست مشابه، اما در اکثریت قریب به اتفاق موارد، شرکت ها از تایید یا رد این گونه تعاملات با NSA خودداری کردند.

«یک بار دیگر پایم را بر این افسانه پاک می‌کنم که منبع باز راهی به سوی قابلیت اطمینان است. این باگ در Debian OpenSSL تقریباً دو سال از عمر آن می گذشت."

در واقع، این آسیب پذیری تنها پس از سر و صدایی در مطبوعات بسته شد. خود پروژه دبیان وضعیت یک باگ طولانی مدت در مخزن OpenSSL خود را «داستانی نسبتاً عجیب» نامید.

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

NSA قصد دارد به عنوان بخشی از عملیات دسترسی سفارشی خود، میلیون ها رایانه را با بدافزار آلوده کند.

وقتی فعال شد تمام ترافیک (رمزگذاری شده و بدون رمز)یا فقط رمزگذاری شدهاین نماینده از فناوری جعل گواهی SSL برای اطمینان از رهگیری داده های منتقل شده در جلسات وب امن استفاده می کند. هنگام برقراری ارتباط ایمن با یک سرور، عامل گواهی سرور اصلی را با گواهینامه ای به همین نام، اما توسط گواهی ریشه عامل، جایگزین می کند. این سیستم به شما این امکان را می دهد که از یک گواهی از پیش نصب شده و یک گواهی ایجاد شده توسط کاربر با مجوز امضا به عنوان گواهی ریشه استفاده کنید.

این سیستم به شما امکان می دهد تا با پیوند دادن گواهی به سرور، گواهی های خاصی را برای جایگزینی هنگام رهگیری جلسات سرورهای مربوطه (سایت ها، برنامه ها) به صورت دستی نصب کنید.

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

برای پیکربندی رهگیری ترافیک SSL:

1. در پنجره تب نمایه تنظیمات نمایندهدر قسمت ویرایش پروفایلبرگه را انتخاب کنید کنترل ترافیک شبکه.
2. روی دکمه کلیک کنید گزینه های رهگیری SSLو توصیه های مندرج در پاراگراف فعلی را دنبال کنید.

انتخاب حالت جایگزینی گواهی SSL

در پنجره تنظیمات، یک حالت رهگیری قابل قبول را انتخاب کنید:

• برای تولید خودکارعامل گواهی root SSL در حین نصببه رایانه کاربر، گزینه را انتخاب کنید حالت خودکار . گواهی ریشه ایجاد شده در پایگاه داده صادرکننده گواهی مورد اعتماد قرار می گیرد و به طور خودکار توسط نماینده برای صدور گواهینامه های فرزند که به طور پیش فرض با نام صادر کننده برج امن Falcongaze امضا شده اند، استفاده می شود.

برای تغییر نام صادرکننده گواهی که در اطلاعات امنیتی اتصال ظاهر می شود، نام مورد نظر را در فیلد وارد کنید نام در گواهی SSL .

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

در پنجره باز شده روی دکمه کلیک کنید یک گواهی اضافه کنیدو فایل های گواهی و کلید را به یکی از روش های زیر مشخص کنید:

1. برای ایجاد یک گواهی جدید، روی دکمه کلیک کنید تولید گواهی. در پنجره ای که باز می شود، نام گواهی جدید، مدت اعتبار آن را وارد کرده و مسیرهایی را که فایل های گواهی (*.cer) و کلید خصوصی (*.pvk) ایجاد شده جدید ذخیره می شوند را مشخص کنید. روی دکمه Generate کلیک کنید.

1. اگر می خواهید گواهینامه ای را که قبلاً در قالب PFX تولید شده است اضافه کنید، روی دکمه کلیک کنید تبدیل از گواهی در قالب PFX. مسیر و رمز عبور فایل گواهی را با فرمت PFX و همچنین مسیر فایل های گواهی (*.cer) و کلید خصوصی (*.pvk) را که می خواهید به آن تبدیل کنید، مشخص کنید. فایل اصلی. برای تکمیل تبدیل، روی دکمه تبدیل کلیک کنید.

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

روی Finish کلیک کنید برای تکمیل فرآیند. گواهی به پایگاه داده گواهی کاربر سیستم SecureTower اضافه می شود. کلیکخوب برای تکمیل اضافه کردنسفارشی اضافه شدگواهی به طور خودکار توسط نماینده در پایگاه داده سازندگان مورد اعتماد قرار می گیرد (اگر قبلاً توسط مدیر شبکه این کار انجام نشده باشد) و سپس برای صدور گواهی های فرزند استفاده می شود.

توجه داشته باشید.

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

پیوند دادن یک گواهی SSL به سرور

برای تعیین تطابق سرور و گواهی، روی دکمه کلیک کنید اتصالات گواهیو توصیه های زیر را دنبال کنید:

• برای اتصال به یک گواهی ریشه سرور خاص در برگه گواهی های ریشه، دکمه را فشار دهید یک گواهی برای سایت اضافه کنید. نام میزبان را وارد کنید ( نام دامنه، در قسمت نام میزبان (آدرس IP) به آن گواهی فرزند صادر می شود و گواهی ریشه به آن متصل می شود. یکی از گواهی های ریشه از پیش نصب شده را از لیست کشویی فیلد انتخاب کنید گواهی ریشهیا روی دکمه کلیک کنید گواهی های کاربربرای افزودن و تعیین فایل های گواهی و کلید خصوصی در رایانه کاربر.
• برای اتصال یک گواهی موجود به یک سرور خاص، برگه را انتخاب کنید گواهی های کاربر. نماینده گواهینامه های فرزند جدیدی را برای سرورهای مشخص شده در این برگه ایجاد نمی کند، اما از گواهی های مشخص شده توسط کاربر برای رویه های جایگزینی استفاده می کند. در پنجره باز شده در قسمت Host name (IP address) نام میزبان (نام دامنه) که گواهینامه به آن متصل می شود را وارد کنید. یکی از گواهی ها را در لیست کشویی فیلد Certificate: انتخاب کنید (اگر گواهی ها قبلاً اضافه شده اند) یا روی دکمه کلیک کنید گواهی های کاربربرای انتخاب گواهی های کاربر از یک لیست یا افزودن و تعیین فایل های گواهی و کلید خصوصی در رایانه کاربر.

توجه داشته باشید.

برای پر کردن فیلد نام میزبان (آدرس IP)استفاده از آدرس IP هاست مجاز است اما فقط در مواردی که نام هاست در حین اتصال مشخص نشده باشد و فقط آدرس IP مشخص باشد.

مستثنی کردن سرورها از رهگیری ترافیک رمزگذاری شده

برای کار با استثناهای فرآیند جایگزینی گواهی، روی دکمه کلیک کنیداستثناهای سرور SSL.

پنجره مدیر استثنا لیستی از سرورها (میزبان) را نشان می دهد که به طور پیش فرض از فرآیند جایگزینی حذف شده اند. برای اضافه کردن یک استثنا جدید، روی دکمه کلیک کنید یک مورد استثنا اضافه کن.

در فیلد ورودی کادر محاوره‌ای که باز می‌شود، نام سرور (میزبان) (مثلا accounts.google.com) را با حروف حساس وارد کنید و روی دکمه افزودن کلیک کنید. این سیستم به شما امکان می‌دهد نام‌ها را با استفاده از یک ماسک وارد کنید (نمادهای ? و * مجاز هستند، برای مثال، با استفاده از *.microsoft.* از تکرار منابع مایکروسافت در لیست محرومیت جلوگیری می‌کند) تا منابع همان خانواده را حذف کنید. نامی که وارد کرده اید در لیست حذف ظاهر می شود.

در مرحله بعد باید حالت حذف را انتخاب کنید: گواهی ها را فقط برای سرورهای SSL لیست شده در بالا جایگزین کنید، یا گواهینامه های SSL را در همه سرورها به جز موارد ذکر شده در بالا جایگزین کنید. در حالت اول، سیستم فقط گواهی‌های سرورهای فهرست شده در لیست حذف را جایگزین می‌کند (و بنابراین می‌تواند ترافیک مربوطه را رهگیری کند). برای بقیه، گواهی ها جایگزین نمی شوند و رهگیری ترافیک رمزگذاری شده مربوطه غیرممکن خواهد بود. در حالت دوم، سیستم گواهی ها را برای همه سرورها به جز مواردی که در لیست استثناها مشخص شده است جایگزین می کند.

برای انجام سایر عملیات با استثناء، توصیه های مناسب در پاراگراف را دنبال کنید

من نشان خواهم داد و به شما خواهم گفت که چگونه از ابزار sslstrip برای رهگیری داده هایی که از طریق یک اتصال SSL امن منتقل می شوند استفاده کنید.
ابزار sslstrip در مثال من (پس از انجام یک حمله جعل ARP بر روی قربانی) درخواست سرویس گیرنده وب قربانی برای ایجاد یک اتصال SSL امن را رهگیری می کند و آن را مجبور به استفاده از پروتکل HTTP ناامن می کند. در مرحله بعد، من فقط به آنچه قربانی انجام می دهد نگاه می کنم، بدون توجه به این واقعیت که او نامه را نه از طریق HTTPS، بلکه از طریق HTTP می خواند.

خواهید دید که سازماندهی حملات چقدر آسان است نوع MITMدر SSL با استفاده از تکنیک arp-spoof و برنامه sslstrip.

در مثال من قربانی یک ماشین مجازی با IP 10.10.11.163 (یک ماشین معمولی با ویندوز) است، رایانه ای که من از آن حمله می کنم 10.10.11.85 با سیستم عامل Kali نصب شده و با sslstrip است (این ابزار از قبل در پنتست نصب شده است. توزیع‌های لینوکس Kali\BackTrack). بین ما یک دروازه با IP 10.10.11.1 وجود دارد.

1. وقتی قربانی به gmail.com می رود به آدرس https://gmail.com فرستاده می شود و این طبیعی است. طبیعتا رمز عبور و لاگین ایمیل قربانی را به صورت متن واضح نمی بینیم.

2. مسیریابی ترافیک را در رایانه شخصی از Kali فعال کنید:

echo "1" > /proc/sys/net/ipv4/ip_forward

و iptables را طوری پیکربندی کنید که تمام ترافیک http به پورت 81 هدایت شود:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 81

arpspoof -i eth0 -t 10.10.11.163 10.10.11.1

اکنون ترافیک قربانی از ماشین من می گذرد و (طبق قانون iptables من) به پورت 81 فوروارد می شود.

3. sslstrip را راه اندازی کنید

sslstrip -a -l 81 -w /root/Desktop/ssllog.txt

این یک فایل گزارش را مستقیماً روی دسکتاپ ایجاد می کند و شروع به نوشتن ترافیک http رهگیری شده در آن می کند (در واقع HTTPS رهگیری می شود، اما حذف می شود). خب، به طور کلی، من شروع به تماشای این فایل در کنسول می کنم:

tail -f /root/Desktop/ssllog.txt

4. قربانی به اداره پست خود می رود

برای خواندن نامه، قربانی، مانند همیشه، به MS Explorer (hehe) می رود و gmail.com را در آنجا وارد می کند. اما به دلایلی مرورگر قربانی را به https (در نوار آدرس http) هدایت نمی کند! تصویر زیر نشان می دهد که قربانی در آخرین لحظه قبل از اینکه رمز عبور و ورود او را پیدا کنم چه چیزی را خواهد دید.

قربانی روی "ورود" کلیک می کند ... و در پنجره من که ترافیک رهگیری شده نمایش داده می شود موارد زیر را می بینم:

همانطور که می بینید رمز عبور 1q2w3e4r5t6y...

برای جلوگیری از تهدیدات مرتبط با رهگیری شروع اتصال SSL، باید:
- از ابزارها در شبکه های نامعتبر استفاده نکنید، حتی اگر بسیار ضروری باشد (یک شرور می تواند MITM را با احتمال بسیار بالاتر، مثلاً در فرودگاه با نصب یک نقطه دسترسی بی سیم سرکش نسبت به هک کردن، ترتیب دهد. شبکه شرکتیسازمان شما)؛
- رمزگذاری نامه ها با پروتکل های رمزگذاری متقارن (من در حال نوشتن و فکر کردن در مورد PGP هستم).
- یک حقوق معمولی به ادمین بپردازید تا او تمایلی به جاسوسی از کارمندان شما در این راه نداشته باشد.
- نظارت بر جدول ARP و استفاده از تجهیزات/نرم افزاری که چنین حملاتی را نظارت می کند.
- به طور منظم نرم افزار را از منابع قانونی معتبر به روز کنید.

لطفاً به یاد داشته باشید که این مقاله مواردی را که توسط قانون ممنوع است نشان می دهد و مثال های موجود در آن برای نشان دادن سهولت سازماندهی حملات به SSL فقط برای اهداف آموزشی ارائه شده است.