بایگانی برچسب: s

یک ارائه درباره توسعه امن برنامه های کاربردی وب

یکی از ارائه های کنفرانس SecAppDev 2018 در خصوص بعضی مکانیزم های امنیتی برنامه های کاربردی وب هست که می تواند برای توسعه دهندگان این برنامه ها مفید باشد. آسیب پذیری هایی مثل Clickjacking، URL Redressing، XSS و نحوه مقابله با آنها بحث شده است. قابلیت هایی که در مرورگرهای مختلف برای پیشگیری از آسیب پذیری هایی از این دست قرار داده شده، در این ارائه توضیح داده شده است. راه حلهایی از جمله استفاده از option های مختلفی که در مرورگرها پیش بینی شده، محدود کردن محتوای فریم ها، محدود کردن ارتباط بین context های مختلف در یک صفحه و غیره پیشنهاد شده که نمونه هایی از Same Origin Policy و Content Security Policy هستند.

فایل ارائه

اشتراک گذاری

فریب سیستم قفل مرکزی اتوموبیل با استفاده از دستگاه رله

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

اشتراک گذاری

نکاتی درباره آسیب پذیری WPA2

همانطور که قبلاً گفتم امروز جزئیات حمله ای موسوم به KRACK که مخفف Key Reinstallation Attack هست، علیه پر استفاده ترین و (تا امروز) امن ترین پروتکل امنیتی شبکه بی سیم یعنی WPA2 توسط گروهی از پژوهشگران دانشگاه Leuven بلژیک و Alabama ایالات متحده (از جمله یکی از فارغ التحصیلان مهندسی کامپیوتر دانشگاه تهران) و چند پژوهشگر دیگر منتشر شد که در کنفرانس Balckhat 2017 اروپا ارائه خواهد شد و بازتاب های بسیار گسترده ای داشت. (لینک مقاله)

KRACK شامل ده آسیب پذیری کشف شده در WPA2 است. WPA2 بهترین و توصیه شده ترین پروتکل در دسترس جهت ایمن سازی شبکه بی سیم در کاربردهای خانگی، سازمانی و غیره است. نفوذگر با سوء استفاده از این آسیب پذیری‌ها، می تواند بدون در اختیار داشتن پسورد یا کلید اتصال به شبکه بی سیم، ترافیک شبکه را شنود و ارسال مجدد (Replay) کند و در حالت های خاصی امکان جعل بسته ها را هم خواهد داشت.
مبنای آسیب پذیری، در نوع طراحی و پیاده سازی Handshake اجرا شده بین کلاینت و Access Point در WPA2 (هنگام اتصال کلاینت به شبکه) و همچنین پارامترهای جانبی استفاده شده در WPA2 تحت حمله، نهفته است. به همین خاطر، این آسیب پذیری ربطی به محصول یا برند خاصی ندارد و تمام پیاده سازی های WPA2 را شامل می شود. لیست برندهای آسیب پذیر، که اکثر آنها الان اصلاحیه (Patch) مورد نیاز را منتشر کرده اند، در اینجا موجود است. برخی برندها مثل ویندوز و iOS به دلیل اینکه در پیاده سازی این Handshake به طور کامل از استاندارد IEEE 802.11i تبعیت نکرده اند، نسبت به برخی از این چند آسیب پذیری (نه همه آنها) مصون هستند!
ویدئویی از نحوه انجام حمله در اینجا ارائه شده است. حمله نیازمند ایجاد یک Access Point جعلی، با همان SSID و آدرس MAC متعلق به Access Point واقعی است. این یکی از نکاتی است که می تواند از نظر عملی، اجرای حمله را مشکل کند، اگر چه در مقاله ارائه شده، تمام این نکات جانبی به خوبی بررسی و حل شده است.

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

“However, the proofs do not model key installation. Put differently, they do not state when the key is installed for use by the data confidentiality protocol. In practice, this means the same key can be installed multiple times, thereby resetting associated nonces and/or replay counters used by the data-confidentiality protocol.”
این پژوهش بر ضرورت عدم ابهام و توصیف صریح پروتکل هایی مثل IEEE 802.11i برای پیشگیری از تفسیرهای متفاوت در زمان پیاده سازی تأکید می کند. در اینجا، از ابهامی که در مقادیر مجاز شمارنده بسته Replay شده در زمان Handshake  سوء استفاده شده است. همچنین، همانطور که همیشه در روش های صوری توصیف و اثبات تأکید می شود، باید به تفاوت بین اثبات امنیت پروتکل، با پیاده سازی امن آن توجه کرد. در اینجا، اثبات فرمال امنیت Handshake پروتکل، در نظر نمی گیرد که طرفین چه زمانی مجاز به نصب کلید توافق شده نشست هستند. در نتیجه، یک کلید می تواند چندین بار نصب شود. این نقیصه فقط با بررسی کد پیاده سازی شده قابل کشف است، نه با خواندن اثبات ارائه شده برای توصیف سطح بالای پروتکل. در حالی که اثبات مورد بحث مربوط به سال ۲۰۰۵ است، آسیب پذیری ها در پیاده سازی پروتکل، از آن زمان تا کنون کشف نشده بودند.

به روز رسانی در ۹۶/۸/۱۲: اسلایدهای ارائه شده در کنفرانس ACM CCS 2017

به روز رسانی در ۹۶/۸/۲۲: مجموعه اسکریپت های تست آسیب پذیری

اشتراک گذاری

انتشار جزئیات آسیب پذیری WPA2 تا ساعاتی دیگر

جزئیات یک آسیب پذیری در سطح طراحی مهم ترین پروتکل امنیتی شبکه های بی سیم محلی یعنی WPA2 که  یکی از ارائه های کنفرانس Blackhat اروپا خواهد بود، امروز منتشر خواهد شد. حمله مورد نظر، Key Reinstallation Attack نام دارد.

اشتراک گذاری

استاندارد سازی و تنظیم مقررات امنیت در اینترنت اشیاء *

اینترنت اشیاء شبکه‌ای از تجهیزات، ابزارها، ماشین‌ها، ساختمان‌ها و دیگر عناصر به اصطلاح هوشمند است که مجهز به سنسورها، نرم‌افزار و اتصالات شبکه هستند واین به آنها امکان جمع‌آوری، پردازش و تبادل اطلاعات می‌دهد. این شبکه امکان اتصال و کنترل این وسایل را از راه دور و به سهولت فراهم می‌کند. پیش‌بینی‌ سیسکو حاکی از افزایش تعداد اشیاء متصل، به ۵۰ میلیارد تا سال ۲۰۲۰ است. در پارادیم اینترنت اشیاء، همه چیز به کامپیوتر تبدیل می‌شود. مایکروویو کامپیوتری است که غذاها را گرم می‌کند. فریزر کامپیوتری است که مواد غذایی را منجمد می‌کند. اتوموبیل، تلویزیون، چراغ راهنمایی، شبکه سراسری برق، تجهیزات پزشکی و غیره همگی کامپیوتر یا شبکه‌ای از کامپیوترها هستند.
واضح است که امنیت در اینترنت اشیاء فراتر از آن است که تا به حال در شبکه‌های کامپیوتری به دنبال برقراری آن بوده‌ایم. اگر تا به حال از میان سه هدف محرمانگی، صحت و دسترس‌پذیری، غالباً اهمیت بیشتری به محرمانگی داده می‌شد، در اینترنت اشیاء باید به صحت و دستر‌پذیری بیشتر توجه کنیم. شبی را تصور کنید که درب ورودی خانه شما قفل شده و هیچ راهی به درون خانه ندارید، در حالی که یک باج افزار از شما مبلغ ۱ میلیون تومان می‌خواهد تا بتوانید درب را باز کنید. فرض کنید یک نفوذگر بتواند کنترل اتوموبیل در حال حرکت شما را به دست آورد، در عملکرد دستگاه‌های درمانی مثل تزریق کننده انسولین یا تنظیم کننده ضربان قلب اختلال ایجاد کند و شبکه سراسری برق را به کنترل خود درآورد. تمام مثال‌های بالا توسط محققان امنیتی شبیه‌سازی شده یا حوادث واقعی آنها اتفاق افتاده و در امکانپذیر بودن آنها با استفاده از تجهیزات و شبکه‌های فعلی، شکی وجود ندارد. تصور اینکه در آینده اتوموبیل ما در حالی که در سفر هستیم به باج‌افزار آلوده شود، سیستم گرمایش خانه از کنترلمان خارج شود، دوربین‌های تحت وب ما برای حمله به زیرساخت‌های حیاتی شهر استفاده شوند و وسایل بازی کودک بتواند به ابزاری خطرناک برای کودک تبدیل شود، بخشی از کابوس زندگی در دنیای تحت سیطره اینترنت اشیاء است.
امنیت ما در اینترنت اشیاء مستقیماً به امنیت میلیون‌ها ابزار متصل به یکدیگر وابسته است. ابزارهایی که بسیاری از آنها محصول شرکت‌هایی هستند که ممکن است تا به حال نام آنها را نشنیده باشیم، و توسط کاربرانی استفاده می‌شوند که هیچ اهمیتی به امنیت ما نمی‌دهند. میلیون‌ها دوربین‌ و روتر خانگی که عضو بات‌نت‌هایی از قبیل Mirai هستند را می‌توان از این قبیل تجهیزات دانست. اتفاقی که Mirai چند ماه قبل رقم زد و توانست سایت‌هایی از قبیل توئیتر و PayPal را در ساعات قابل توجهی از روز از دسترس خارج کند، نشان داد که اینترنت اشیاء چه پتانسیلی برای آسیب زدن به کسب و کارها برای نفوذگران ایجاد می‌کند. بسیاری از این اشیاء، متشکل از اجزایی ارزان قیمت هستند که توسط تیم‌های نه چندان حرفه‌ای در حوزه امنیت، بسته بندی و فروخته شده‌اند. این اشیاء بر خلاف کامپیوترهای گرانقیمت سنتی، وصله‌های امنیتی دریافت نمی‌کنند و برخی از آنها هیچ راهی برای به روز رسانی ندارند.
آنچه تجهیزات متصل را در اینترنت اشیاء به سلاح‌هایی مخرب بدل می‌کند، بیش از آنکه نقاط ضعف فنی باشد، ناکارآمدی قوانین و سیاست‌ها است. امروز با انبوهی از تجهیزات متصل روبرو هستیم که حاوی حفره‌های امنیتی هستند، یا احتمالاً در آینده نقاط ضعفی در آنها شناخته خواهد شد، اما امکان و انگیزه رفع این نقطه ضعف‌ها وجود ندارد. اغلب تولید کنندگان تمایلی به وارد شدن به پروسه پیچیده و گران به روزرسانی محصولات فروخته شده ندارند. بسیاری از تولید کنندگان حداکثر اقدام به انتشار نسخه‌های جدید میان‌افزار و برنامه‌های کاربردی خود می‌کنند، در حالی که نه تنها تضمینی برای عملیاتی شدن این نسخه‌های جدید وجود ندارد، بلکه روند حوادث اخیر نشان می‌دهد که رفع این آسیب پذیری‌ها چالش جدی اینترنت اشیاء است.
به روز رسانی از طریق وصله‌های نرم‌افزاری، روش استانداردی است که تولید کنندگان بزرگ صنعت کامپیوتر برای رفع آسیب‌پذیری‌های کشف شده در محصولات خود انتخاب کرده‌اند. شرکت‌هایی مثل مایکروسافت، گوگل، اپل و غیره برنامه‌ای جامع و منظم برای انتشار وصله‌ها اجرا می‌کنند که مشتمل بر تولید سریع، تست و انتشار به موقع این وصله‌ها است. به روز رسانی خودکار، هم در طرف کاربر به عنوان یک اقدام ضروری همواره توصیه شده است و هم تولید کننده به عنوان بخشی از فرآیند نگهداری محصول بر عهده گرفته است. هرچند این پروسه به روزرسانی دارای اشکالات عمده‌ای است که بسیاری از ما در زندگی شخصی و کاری با آن آشنا هستیم، اما حداقل به عنوان یک روش استاندارد و بهترین گزینه موجود، پذیرفته شده است. اما این در اینترنت اشیاء صادق نیست. یک هدفون هوشمند، تلویزیون، فریزر یا اتوموبیل هوشمند را در نظر بگیرید. در بسیاری از این محصولات با تولیدکننده‌ای سروکار داریم که حتی تیمی برای تست امنیتی محصول خود ندارند. در بعضی از این تجهیزات اصلاً نمی‌توان انتظار پشتیبانی پس از فروش را داشت. بعضی دیگر از این دستگاه‌ها اساساً قابل وصله کردن نیستند. حتی تضمینی نیست که وصله ایجاد شده را بتوان با سلامت و بدون از دست رفتن اصل محصول، پیاده‌سازی نمود. این می‌تواند ناشی از نوع طراحی محصول، کیفیت شبکه مورد اتصال یا محل استفاده از آن باشد.
دوره عمر بسیاری از تجهیزات متصل در اینترنت اشیاء طولانی‌تر از کامپیوترهای عادی است. اگر بتوان تصور کرد که بسیاری از افراد هر دو یا سه سال یک‌بار گوشی هوشمند یا لپ‌تاپ خود را تعویض کنند، این مدت برای وسایلی مثل فریزر، درب ساختمان، سیستم گرمایش و اتوموبیل می‌تواند چندین سال بیشتر باشد. وسایلی مثل اتوموبیل حتی ممکن است تا ده سال و بیشتر، دست به دست شده و استفاده شوند. حال تصور کنید که شرکت تولید کننده چنین وسایلی ورشکست شود، یا تصمیم بگیرد که از محصولات قدیمی خود پشتیبانی نکند. درست مانند عدم پشتیبانی مایکروسافت از ویندوز XP، هرچند مایکروسافت در حادثه اخیر مربوط به بدافزار WannaCry، وصله مربوط به ویندوز XP را نیز در اختیار کاربران قرار داد. حال اگر در سال ۲۰۱۷ یک برنامه نویس قطعه کدی برای سیستم کنترل هوشمند یک اتوموبیل می‌نویسد، چه کسی قرار است آن را در صورت نیاز، در سال ۲۰۳۰ یا ۲۰۴۰ وصله کند؟
بنابراین بازار اینترنت اشیاء دارای دو ویژگی چالش برانگیز در حوزه امنیت است:
۱- نگهداری امنیتی اشیاء متصل، به دلیل ماهیت آنها مشکل است.
۲- نه تولیدکنندگان و نه مصرف کنندگان در این بازار، اولویت لازم را برای امنیت اشیاء متصل قائل نیستند.
به همین دلیل، باید در حوزه قوانین و سیاست‌ها به دنبال راه حل باشیم. حاکمیت باید حداقلی از نیازمندی‌های امنیتی را برای محصولاتی که به حوزه IoT وارد می‌شوند الزام کند. همچنین باید هزینه سوء استفاده از آسیب پذیری‌های این محصولات را برای تولید کنندگان بالا ببرد. هرچند استفاده از اهرم حاکمیتی ممکن است به طور کلی راه حل ایده آل نباشد، اما چاره‌ای نیست. این راهی است که کشورهای دیگر نیز در حال قدم گذاشتن در آن هستند. کما اینکه امروز در ایالات متحده و اتحادیه اروپا، این حرکت آغاز شده است. ویژگی‌های بازار اینترنت اشیاء، حاکمیت را ناگزیر از ورود به این حوزه و تنظیم مقررات خواهد کرد. نقش حاکمیت در اینجا پیش از هر چیز، تدوین و برقرار کردن استانداردها و سیاست‌ها و اطمینان از تطبیق شرکت‌ها و سازمان‌ها با این الزامات حاکمیتی است، به نحوی که امکان سوء استفاده از این شبکه برای آسیب رساندن به شهروندان و سازمان‌ها به حداقل برسد. هدف نهایی این استانداردسازی، باید حفظ ایمنی جامعه در برابر تهدیدهای سایبری و سایبرـ‌فیزیکی اینترنت اشیاء و جلوگیری از رخدادهایی شبیه حملات بات‌نت Mirai باشد. استانداردسازی و تنظیم مقررات نه فقط از جانب حاکمیت، بلکه توسط خود بازیگران این عرصه هم باید اتفاق بیافتد. به عنوان مثال، خدمات دهندگان اینترنت باید اطمینان حاصل کنند که روترهای خانگی مشتریان، تجهیزات اینترنت بی‌سیم عمومی، دوربین‌های تحت شبکه و غیره پیش از نصب، حداقلی از تنظیمات امنیتی را تضمین می‌کنند. صنعت بیمه هم می‌تواند عهده دار بخشی از مسئولیت کاهش آسیب‌های ناشی از حملات مبتنی بر اینترنت اشیاء باشد. تنظیم مقررات اینترنت اشیاء فراتر از امنیت سایبری نیازمند توجه به ایمنی (Safety) است. همانطور که در صنایع حمل و نقل هوایی، تجهیزات بیمارستانی و دارو مقررات ایمنی وضع و اجرا می‌شود، باید در حوزه اینترنت اشیاء نیز این اتفاق رخ دهد. همچنین آزمایشگاه‌هایی باید برای اعتباربخشی و تأیید امنیتی وسایل هوشمند خانگی و دیگر تجهیزات IoT تحت حمایت حاکمیت تأسیس شوند.

* نسخه ای از این یادداشت، پیش تر در ماهنامه بانکداری الکترونیک منتشر شده است.

اشتراک گذاری

پشت صحنه امنیت iOS

اسلایدها و ویدئوی ارائه ای از کنفرانس Blackhat 2016 در مورد معماری امنیتی iOS که جزئیاتی از مکانیزم های رمزنگاری و امنیت سیستم فایل در اون ذکر شده.

اشتراک گذاری

آیا واناکرای یک باج افزار است؟

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

اشتراک گذاری

مدیریت لاگ و مرکز عملیات امنیت (۴)

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

سطح انتزاع (Abstraction) لاگ برنامه کاربردی در مفید بودن اون جهت مانیتورینگ امنیت نقش کلیدی ایفا می کنه. به عنوان مثال، در یک برنامه کاربردی وب، اینکه شما برای تحلیل یک حادثه به لاگ درخواست های HTTP دسترسی داشته باشید و داشبوردها و گزارش های متنوع رو از این لاگ در اختیار داشته باشید، در جای خودش مفید و لازم هست. اما در سطح انتزاع بالاتر، خیلی مهمه که لاگ مربوط به منطق کسب و کار اون برنامه رو در اختیار داشته باشید. اینکه کاربری در ساعت غیر اداری به برنامه لاگین کرده، یک سند ایجاد کرده، یک فاکتور رو برگشت زده، دسترسی کاربر دیگری رو به یک ماژول ایجاد کرده و غیره. هر یک از این رخدادها (که ممکن هست شامل چندین درخواست HTTP باشند) میتونن از لحاظ امنیتی اهمیت داشته باشن، به خصوص اگر در کنار هم و با داشتن اطلاعات دیگه ای مثل نوع و نقش کاربر، زمان، آدرس IP مبدأ و … مانیتور بشن. بسیاری از حمله ها و حتی تقلب ها رو میشه با پایش این رخدادهای حساس کشف کرد. اینکه کدام رخدادهای برنامه کاربردی از نظر امنیتی حساس هستند، کاملاً وابسته به کسب و کار هست.

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

یک راهنمای خوب در همین زمینه:

OWASP Logging Cheat Sheet

اشتراک گذاری

مدیریت لاگ و مرکز عملیات امنیت (۳)

همانطور که در دو یادداشت قبلی گفته شد، انتخاب درست منابع لاگ نقش بسیار مهمی در مفید بودن خروجی های تحلیلی سیستم مدیریت لاگ دارد. علاوه بر این، در هر یک منابع لاگ هم، باید آن بخش از لاگ ها که ارزشمندتر بوده و مستقلاً یا در کنار لاگ های دیگر، اطلاعات مفیدتری در بر دارند را جمع آوری کرد. مفید بودن لاگ ها بسته به اینکه کسب و کار مربوطه چیست و چه خط مشی هایی نیاز به پایش دارند، مشخص می شود. با این حال، الگوهایی وجود دارد که در قریب به اتفاق کسب و کارها، به پایش آنها نیاز داریم، در نتیجه باید لاگ های مناسبی که بتوان از تحلیل آنها به این الگوها دست یافت را جمع آوری کنیم. یکی از منابع جامع در این زمینه، سند SANS با عنوان Six Categories of Critical Log Information است. این شش رده را می شود به عنوان یک دسته بندی عمومی حداقلی برای تمام سازمان ها، فارغ از ماهیت کسب و کار، دانست. در هر لایه ای اعم از شبکه و برنامه های کاربردی، نیاز داریم که این نوع لاگ ها را جمع آوری کنیم تا از خروجی تحلیل آنها به حمله ها یا سوء استفاده های احتمالی برسیم.

شش رده گزارشی که باید لاگ مربوط به آنها در دسترس باشد عبارتند از:

  1. Authentication and Authorization Reports
  2. Systems and Data Change Reports
  3. Network Activity Reports
  4. Resource Access Reports
  5. Malware Activity Reports
  6. Failure and Critical Error Reports

هر کدام از این شش رده، در سطح تجهیزات شبکه و برنامه های کاربردی اهمیت خاص خود را دارند. به عنوان مثال، گزارش تغییرات در سیستم ها و داده ها (مورد ۲) برای کنترل عملکرد راهبران سیستم عامل ها، سرورها و تجهیزات شبکه کاربرد دارد. در یک شبکه بزرگ با صدها یا هزاران تجهیز، انجام این کنترل برای عیب یابی و ریشه یابی رخدادهای غیرمنتظره الزامی است. یا مثلاً تعداد لاگین های ناموفق به سیستم ها و تجهیزات، می تواند بیانگر حملات Brute Force علیه آنها باشد. فرض کنید با یک نمودار، تعداد لاگین های ناموفق در ۲۴ ساعت گذشته روی یک تجهیز یا سرور نمایش داده شود. اگر این تعداد به چند صد یا چند هزار برسد، به خصوص در صورت ثابت بودن IP مبدأ، با احتمال بالایی حمله Brute Force اتفاق افتاده است. از این طریق حتی ممکن است به یک یا چند IP مبدأ برسیم که خود این IP ها هم Compromise شده اند و صاحب IP از این موضوع اطلاع ندارد.

اشتراک گذاری

ابزاری جدید برای بازیابی حساب کاربری

رویداد Enigma 2017، از سری کنفرانس های انجمن Usenix، در حال برگزاریست و نگاهی به برنامه و سخنران ها نشان از جذابیت این کنفرانس دارد. فیسبوک در این رویداد از یک پروتکل جدید به نام Delegated Recovery برای حساب های کاربری رونمایی کرد. هدف این پروتکل، ارائه روشی امن و ساده برای بازیابی حساب کاربری به جای روش سنتی استفاده از ایمیل یا تلفن همراه است. به بیان ساده، با داشتن یک حساب فیسبوک و یک حساب گیت هاب (Github)، می توانیم از یک حساب به عنوان ابزار بازیابی حساب دیگر استفاده کنیم. روش کار به این شکل هست که یک توکن با حساب گیت هاب می سازیم که بعداً در حساب فیسبوک ما ذخیره می شود. وقتی پسورد گیت هاب رو فراموش کردیم، با ورود به حساب فیسبوک و استفاده از این توکن، گیت هاب صاحب حساب از دست رفته رو شناسایی می کنه. البته فیسبوک توضیح داده که هویت صاحب واقعی حساب در سایت مبدأ، برای سایت مقصد پنهان باقی خواهد ماند. این ابزار به صورت متن باز ارائه شده و جزئی از برنامه باگ باونتی فیسبوک هم هست.

اشتراک گذاری