بایگانی ماهیانه: دی ۱۳۹۵

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

مدیریت لاگ پیش نیاز و پایه مانیتورینگ امنیت و یکی از بدیهی ترین قدم هایی هست که باید در یک سازمان برای ورود به حیطه مانیتورینگ امنیت برداشته شود. همانطور که قبلاً اشاره کردم، اگر مدیریت لاگ سازمان به بلوغ کافی نرسیده باشه، صحبت از مرکز عملیات امنیت (SOC)، به معنای استفاده از SIEM، بیهوده خواهد بود. البته برخی علاقه دارند که همین پیش نیاز رو هم بخشی از مرکز عملیات امنیت در نظر بگیرند. دلیل این امر معمولاً این هست که مرکز عملیات امنیت مثل بسیاری از اصطلاحات دیگر در حیطه امنیت، به عنوان یک نانجی و راه حل همه مشکلات معرفی شده و مدیران اجرایی دراینگونه سازمان ها به شدت روی این اسم تأکید دارند. طبعاً برای بدنه فنی سازمان ها هم، موضوع SOC و خرید SIEM به اندازه کافی جذاب هست. فروشندگان هم که طبعاً ترجیح می دهند یک راه حل چند صد میلیون تومانی (در بهترین حالت) یا یک راه حل در مرتبه میلیارد تومانی رو بفروشند، تا اینکه شاهد تقلیل این معامله جذاب، به یک پروژه ارزان قیمت مدیریت لاگ باشند.
قبلاً در مورد اینکه یک سازمان به طور معمول چه مراحلی رو در موضوع مدیریت لاگ طی می کنه و به اصطلاح به تکامل می رسه، نوشته بودم . نکات متنوعی در موضوع مدیریت لاگ به طور عام، و مدیریت لاگ از دیدگاه امنیت، وجود داره که در اینجا و یادداشت های بعدی به چند موردش اشاره می کنم.
انتخاب درست منابع لاگ
در یک سازمان بزرگ، شما حداقل با چند صد تجهیز شبکه، ده ها یا صدها سرور با سیستم عامل های مختلف و ده ها برنامه کاربردی عمومی و داخلی مواجه هستید. هر کدام از این سیستم ها، از نظر ماهیت کاربران، اهمیت سیستم در کسب و کار، نقش سیستم در اجرای خط مشی های امنیتی سازمان و غیره با هم تفاوت دارند. طبعاً نمی شود و نباید در قدم های اول راه اندازی مدیریت لاگ، بسیاری از سیستم ها رو به عنوان منبع لاگ، وارد بازی کرد. پس برای اینکه بیشترین بهره و مفید ترین خروجی از مدیریت لاگ به دست بیاد باید منابع لاگ مناسب رو به ترتیب به این سیستم اضافه کرد. تجهیزات امنیتی از جمله فایروال، UTM ، سیستم AAA (مثل Cisco ACS یا Cisco ISE) و سنسورهای تشخیص نفوذ (IDS) از جمله منابعی هستند که در ابتدا باید به سراغ مدیریت لاگ های اونها رفت. ممکن است بعضی برنامه های کاربردی هم وجود داشته باشند که امنیت اونها از اهمیت فوق العاده برخوردار است و به نوعی هسته کسب و کار سازمان در این برنامه ها پیاده سازی شده باشه. این برنامه ها هم، در صورتی که لاگ مناسبی تولید کنند، جزو اولین گزینه ها برای مدیریت لاگ هستند. ممکنه در اضافه کردن بعضی از منابع مهمی که اشاره کردیم به سیستم مدیریت لاگ، چالش هایی وجود داشته باشه از جمله مناسب نبودن مکانیزم جمع آوری لاگ در اون منبع خاص یا مناسب نبود فرمت و سطح لاگ تولید شده، که در جای خودش به اونها اشاره خواهیم کرد.

اشتراک گذاری

درباره برداشت وجه بدون کارت از خودپرداز

تراکنش های بدون کارت با استفاده از خودپرداز، از جمله برداشت و انتقال وجه بدون کارت، سرویسی نسبتاً جدید است که به مشتری اجازه می دهد با استفاده از تلفن همراه و بدون نیاز به کارت، امکان برداشت از حساب را برای خود یا شخص دیگری فراهم کند. صاحب حساب، یک حواله الکترونیکی ایجاد کرده و بانک آن را برای گیرنده ارسال می کند. معمولاً یک رمز هم در این فرآیند تولید و به صاحب حساب داده می شود تا شخصاً برای گیرنده ارسال نماید. گیرنده حواله می تواند با مراجعه به خودپرداز بانک حساب مبدأ و وارد کردن کد حواله مربوطه به اضافه رمز تولید شده در فوق، مبلغ مورد نظر را دریافت کند. طبق این گزارش که در اردیبهشت ۹۵ تهیه شده، بانک های مسکن، اقتصاد نوین، ملت، صادرات و رفاه این خدمت را ارائه می کنند.
آنگونه که در گزارش فوق اشاره شده، در برخی از بانک ها می توان بدون مراجعه به خودپرداز و صرفاً از طریق ورود به یکی از کانال های غیرحضوری مثل بانکداری اینترنتی، این حواله را برای شخص گیرنده صادر کرد. بنابراین یک نفوذگر با دسترسی به حساب اینترنتی قربانی، می تواند امکان برداشت پول نقد از خودپرداز را برای خود یا همدستش فراهم کند. این سناریو دقیقاً برای یک مشتری بانک Chase اتفاق افتاده و Brian Krebs در این گزارش به آن اشاره کرده است. در این سناریو، مشتری تلاش کرده در کشور مکزیک با استفاده از برنامه همراه بانک به حساب خود وارد شود اما موفق نشده و بعد از بازگشت به آمریکا متوجه برداشت نزدیک به ۳۰۰۰ دلار در یک تراکنش از حساب خود شده است. مشخص است که ایرادات مختلفی در نحوه ارائه این خدمت توسط بانک Chase وجود داشته، از جمله بالا بودن سقف حواله مجاز (۳۰۰۰ دلار) و عدم اطلاع رسانی به صاحب حساب، وقتی نفوذگر شماره تلفن همراه جدیدی را به حساب متصل کرده و وقتی آدرس ایمیل متصل به حساب را تغییر داده است. هر چند در بانک های داخلی که این خدمت را ارائه می دهند، موارد مختلفی از جمله سقف تراکنش و … رعایت شده است، با این حال به نظر می رسد آنهایی که صدور حواله برداشت بدون کارت را منوط به مراجعه فیزیکی صاحب حساب به خودپرداز نموده اند، یک قدم از لحاظ امنیتی پیش تر از بقیه عمل کرده اند.

اشتراک گذاری

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

یک بدافزار جدید با نام Trojan.AndroidOS.Switcher از طریق آلوده کردن سیستم عامل اندروید، تلاش می کنه شبکه Wi-Fi سرویس دهنده به دستگاه آلوده رو هک کنه. این کار از طریق نفوذ به روتر بی سیم یا Wi-Fi با استفاده از حمله Brute force انجام می شه. بنابراین اگر پسورد پیش فرض روتر بی سیم عوض نشده باشه یا پسورد اون ضعیف باشه، بدافزار با لاگین کردن به روتر، تنظیمات DNS دستگاه رو عوض می کنه. این در واقع یک حمله سرقت DNS یا DNS Hijacking هست. در نتیجه، درخواست های DNS ارسالی از کلاینت های متصل به شبکه Wi-Fi ، به سرورهای مدنظر نفوذگر ارسال خواهد شد.
بر اساس اعلام کسپرسکی، این بدافزار به دوشکل ظاهر می شه، یکی به عنوان کلاینت موبایل موتور جستجوی چینی بایدو (Baidu) و دیگری به شکل یک برنامه موبایل پرطرفدار چینی که برای اشتراک گذاری اطلاعات مربوط به شبکه های Wi-Fi عمومی استفاده می شه. وقتی بدافزار به طور خودکار به روتر یا نقطه دسترسی بی سیم لاگین کرد و تنظیمات DNS رو عوض کرد، به تدریج تمام درخواست های DNS از اون شبکه بی سیم به سمت سرورهای مدنظر نفوذگر خواهد رفت. از اینجا به بعد انواع حملات از فیشینگ گرفته تا آلوده سازی شبکه با بدافزارهای دیگر قابل اجرا هست.
اگر ترافیک DNS به مقصد آدرس های IP زیر در شبکه مشاهده کردید، حتماً دستگاهی آلوده به این بدافزار در شبکه وجود داره:

۱۰۱٫۲۰۰٫۱۴۷٫۱۵۳
۱۱۲٫۳۳٫۱۳٫۱۱
۱۲۰٫۷۶٫۲۴۹٫۵۹
مانیتور کردن درخواست های خروجی DNS بسیار مهم هست و مثال بالا یکی از دلایل این اهمیت هست. این کار رو می شه با استفاده از سنسور IDS (تشخیص نفوذ) در داخل شبکه یا روی Gateway انجام داد. همچنین تعویض پسورد پیش فرض تجهیزات شبکه وایرلس و استفاده از پسوردی که به راحتی قابل Brute force نباشه از دیگر تمهیدات مقابله با این بدافزار هست.

اشتراک گذاری

سیستم عامل اینترنت اشیاء گوگل: Android Things

گوگل سیستم عامل مخصوص اینترنت اشیاء رو مبتنی بر Brillo (سیستم اندرویدی که سال قبل معرفی شده بود) معرفی کرده. این سیستم عامل، Andriod Things نام داره. هدف اینه که همه توسعه دهندگان به سرعت و به راحتی امکان ساخت اشیاء رو داشته باشند. این کار با کمک تولید کننده های مختلف بوردهای سخت افزاری موسوم به SoM انجام می شه. اونها با تولید بوردهای سازگار با اندروید، انواع سخت افزارها با قیمت مناسب و امکانات و اینترفیس های متنوع رو در اختیار توسعه دهندگان سیستم ها قرار می دن.

اشتراک گذاری

باگ باونتی و حواشی آن: مصائب هکرهای قانونمند!

برنامه باگ باونتی (Bug Bounty) به طرحی گفته می شه که در اون یک سازمان که میتونه شرکتی خصوصی یا نهادی دولتی باشه طبق شرایطی مشخص، از هکرها و محققین امنیت درخواست می کنه تا آسیب پذیری های امنیتی سیستم های سازمان رو در ازای دریافت پاداش، به اون گزارش کنن. از این طریق، هکرهای قانونمند به اون سازمان کمک می کنن که باگ های امنیتی خودش رو که از اونها بی اطلاع هست، کشف کنه و قبل از اینکه به هر طریقی مورد سوء استفاده قرار بگیره، اونها رو رفع کنه. این کار اولین بار توسط شرکت Netscape در دهه ۹۰ انجام شده و الان شرکت های بزرگ مثل مایکروسافت، فیسبوک، گوگل و حتی پنتاگون به طور معمول این برنامه رو اجرا می کنن. مثلاً برنامه باگ باونتی مایکروسافت برای محصولات مختلفش در اینجا اعلام شده و گفته شده که تاریخ شروع و پایان هر برنامه و حداکثر میزان پاداش برای گزارش باگ از محصولات مختلف چقدر هست. همچنین در برنامه VRP از مجموعه برنامه های موسوم به Security Reward گوگل، به طور دقیق مشخص شده که چه آسیب پذیری هایی مورد پذیرش هست، کدام سایت ها و اپلیکیشن ها مستثنا هستند و به خصوص، چه گزارش هایی از دید گوگل ارزش شرکت در این رقابت رو ندارن.
در ایران اما وضعیت به کلی متفاوت هست. همونطور که جادی در این یادداشت اشاره کرده، موارد زیادی از گزارش آسیب پذیری ها به سازمان ها مورد توجه خاصی قرار نمی گیره. نه تنها برنامه هایی که بشه به اونها باگ باونتی گفت وجود نداره (خب گوگل و مایکروسافت هم در ایران نداریم!)، اساساً در خیلی از سازمان ها برنامه مشخصی برای مواجهه با یک گزارش آسیب پذیری وجود نداره. اینکه اگر کسی ادعای وجود یک آسیب پذیری رو داشت، چه برخوردی در اون سازمان میشه و اساساً به چه کسی باید گزارش داد، اصلاً مشخص و قابل پیش بینی نیست. همین موضوع باعث می شه که برخورد با این گزارش ها کاملاً موردی و وابسته به سلیقه مدیران مربوطه باشه. باید توجه داشته باشیم که اگر سازمانی برنامه باگ باونتی اعلام نکرده باشه، و شما هم قرارداد تست نفوذ با اون سازمان نداشته باشید، اونوقت شما طبق ماده ۱ قانون جرائم رایانه ای مجرم هستید. البته نظر شخصی من این نیست، اما قانون به نظر شخصی من و شما یا اونچه که احتمالاً در بعضی کشورهای دنیا به عنوان عرف پذیرفته شده، کاری نداره!
البته تمام تقصیر رو هم بهتره به گردن سازمان ها نندازیم. بعضی از سازمان ها تجربه جذابی از مواجهه با افرادی که باگ گزارش می دن، ندارن. با این حال، تعداد افرادی که به صورت متمدنانه و قانونمند می تونن به سازمان ها کمک کنن، کم نیست و بهتره که فرهنگ باگ باونتی، یا چیزی شبیه به اون، زودتر در سازمان ها جا بیافته. حالا اگر هم برنامه ای رسمی برای جایزه دادن به هکرهای قانونمند اعلام نمی کنن، حداقل بتونن گزارش های معتبر و خیرخواهانه رو از بقیه گزارش ها تشخیص داده و برخورد مناسبی با گزارش دهنده داشته باشن.

اشتراک گذاری