امنیت

گزارش شفافیت توییتر – دولت‌ها از حریم خصوصی ما چه می‌خواهند؟

توییتر هر شش ماه گزارشی از درخواست‌های دولتی و غیردولتی برای در اختیار گذاستن اطلاعات کاربران رو منتشر می‌کنه و به گفته خودش برای حفظ حریم خصوصی افراد، فقط بخشی از اطلاعات درخواستی رو در اختیار می‌گذاره. بد ندیدم که نگاهی به گزارش شش ماهه دوم سال ۲۰۱۵ توییتر بندازیم.

گزارش شفافیت و حریم خصوصی

در اولین نگاه متوجه روند رو به افزایش درخواست‌ها می‌شیم. دولت‌ها روز به روز علاقه بیشتری به کنترل اکانت‌های توییتر پیدا کردند و تعداد درخواست‌ها از ۸۴۹ تا در نیمه نخست ۲۰۱۲ به ۵۵۶۰ تا در نیمه دوم سال ۲۰۱۵ رسیده. از شروع گزارش‌های شفافیت توییتر از سال ۲۰۱۲ تا کنون ۷۰ کشور درخواست اطلاعا فرستادند که ایران جزوشون نبوده. کشورهای جدیدی که در شش ماهه دوم سال ۲۰۱۵ درخواست فرستادند که حتی کشورری مثل فنلاند هم توشون بوده.

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

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

ترکیه

و مقایسه کنید با تاریخچه درخواست‌های عربستان. نکته‌ای که ذهن من رو مشغول کرده اینه که همه و قاعدتا مدیران توییتر از سیستم قضایی عربستان خبر داریم و می‌دونیم که چه تبعات خطرناکی داره این نقض حریم خصوصی اما باز هم بیشترین نسبت پاسخ رو داشته.

عربستان سعودی

از نکته‌های جالب توجه دیگه اینکه حدودا نیمی از درخواست‌های شش ماهه دوم، یعنی ۲۶۷۳ مورد، از طرف آمریکا بوده که ۷۹ درصد اطلاعات مورد نظرش رو گرفته. فقط در بخشی از این درخواست‌ها به خود کاربر اطلاع داده شده که مورد تقتیش دولتی قرار گرفته.

حریم خصوصی در ایران

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

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

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

رعایت حریم خصوصی افراد، با خودش آزادی، امنیت و نوآوری میاره.

Standard
امنیت

ضعف امنیتی خطرناک از نوع xss در سایت من‌و‌تو

برای سال‌های متمادی، خطرناک‌ترین ضعف امنیتی که در تعداد بسیار زیادی از سایت‌ها دیده می‌شد، تزریق کد اس‌کیوال یا SQL Injection بود اما به نظر می‌رسه این روزها، رتبه‌بندی تغییر کرده و xss داره جای خودش رو در صدر جدول به دست میاره. به صورت خلاصه اگر بخوام بگم، xss مشکلیه که به هکر اجازه می‌ده تا کدهای جاوا اسکریپت ناخواسته رو در مرورگر مراجعه‌کننده‌های سایت اجرا کنه. نتیجه اجرای این کدهای ناخواسته می‌تونه از دزدیدن دسترسی کاربر به سایت باشه تا توزیع بدافزار و هک کاربرهایی که به اون سایت خاص اطمینان دارند. این شیوه هک، به صورت غیر مستقیم می‌تونه منجر به نفوذ هکر به سایت هم بشه چون نباید فراموش کنیم که ادمین سایت هم مراجعه‌کننده با سایته اما با دسترسی بالاتر.

 xss vulnerability in manoto website

با شروع مسابقه خوانندگی شیکه من‌و‌تو و امکان ثبت رای از طریق وب‌سایت، انتظار می‌ره که بازدید این وب‌سایت رشد زیادی داشته باشه. نکته‌ای که می‌تونه هکرها رو به خودش جلب کنه. با یک نگاه گذرا به سایت manototv.com متوجه شدم که بخش جستحوی این سایت به خوبی بررسی نمی‌شه و امکان تزریق کد جاوا اسکریپت وجود داره. در تست نفوذهای اخیرم، تقریبا نیمی از سایت‌ها این نقص امنیتی رو داشتند و بسیاریشون، مشکل رو در فیلد جستحو داشتند. نمی‌دونم چرا اما به نظر می‌رسه که توسعه‌دهنده‌ها اهمیت چندانی برای این بخش قائل نیستند.

متاسفانه تجریه خوبی در گزارش ضعف امنیتی xss به مدیر سایت‌های پیشین نداشتم و اونها مشکل رو مربوط به کاربران می‌دونستند و فکر می‌کردند چون مستقیم باعث هک سایت نمی‌شه پس مهم نیست. در مورد سایت من‌و‌تو اینجوری نبود. من در تاریخ ۴ فوریه ۲۰۱۶ متوجه مشکل شدم و به مدیر سایت اطلاع اولیه رو دادم. ۵ فوریه فیلم نمونه سو استفاده رو فرستادم و تا ۶ فوریه مشکل برطرف شد.

در مورد فیلم شبیه‌سازی، گفتن دو نکته ضروریه:

۱. این فیلم اثبات، یک xss کلاسیک نیست بلکه من با استفاده از امکان تزریق کد، یک iframe رو به فیلد جستجو تزریق کردم و عملا تبدیلش کردم به یک حمله ترکیبی فیشینگ. iframe یک بازسازی از فرم لاگین به وب‌سایت من‌و‌تو بود با این فرق که اطلاعات وارد شده رو به سرور من می‌فرستاد. به این ترتیب من نام کاربری و پسورد هر کسی که فریب می‌خورد رو می‌تونستم به‌دست بیارم. این فیشینگ به این دلیل که در دامنه اصلی سایت و با حفظ https انجام می‌شه، امکان موفقیت هکر رو بسیار بالا می‌بره.

۲. شبیه‌سازی در مدت زمانی حدود ۱۰ دقیقه انجام شده و مسلما با وقت بیشتر، می‌تونست کیفیت بهتری داشته باشه اما از آنجاییکه هدف واقعا فریب کسی نبود و فقط قصد نشون دادن میزان خطر رو داشتم، وقت بیشتری صرفش نکردم.

جلوگیری از xss

سمت سایت:

  • اصل اول در جلوگیری از تزریق کد و دستور، اعتبارسنجی و پاک‌سازی اطلاعات وارد شده است. برای مثال در بخش جستجو، نیازی به کاراکترهای < و یا > نیست معمولا.
  • همه ورودی‌ها مهمند، حتی referrer و یا متغیر انتخاب زیان سایت.
  • به فریمورک‌ها اطمینان کامل نداشته یاشید. مستندات فریمورک رو بخونید و ببینید کدام بخش از نکات امنیتی رو بر عهده توسعه‌دهنده گذاشته.
  • امنیت کاربر به اندازه امنیت سایت مهمه. نیابد بین ضعفی مثل xss با نمونه‌هایی مانند SQL Injection و یا Code Injection که مستقیما باعث هک سایت می‌شن، فرق بگذارید.

سمت کاربر:

  •  از مرورگرهای امن‌تر مانند firefox و یا google chrome استفاده کنید. مرورگرها رو به‌روز نگه دارید.
  • استفاده از افزونه‌هایی که کار ذخیره و وارد کردن پسورد رو انجام می‌دن، می‌تونه در این زمان‌ها مفید باشه. lastpass می‌تونه گزینه خوبی باشه.
  • در زمان ارسال اطلاعات کاربری، به ظاهر سایت اکتفا نکنید و آدرس فرم رو چک کنید. هرچند در نمونه‌ای که فیلمش رو گذاشتم، این بررسی راه به جایی نمی‌بره اما همه‌جا اینجور نیست.
  • استفاده از افزونه‌ای مثل noscript می‌تونه مفید باشه، هرچند گاهی کاربری سایت رو سخت می‌کنه.
  • ضدویروس و ضد بدافزار نصب کنید و همیشه به‌روز نگهش دارید. یک کد جاوا اسکریپت مخرب، می‌تونه حتی از طریق سایت‌های معتبر نیز توزیع بشه و عواقب گاها جبران‌ناپذیری داشته باشه.

پی‌نوشت

Standard
امنیت

جنگ رمزها: استفاده از رمزنگاری در گروه‌های تروریستی

سال گذشته مقاله‌ای نوشتم در مورد استفاده از رمزنگاری در القاعده. ترس روزافزون از حملات تروریستی در کشورهای اروپایی و آمریکایی سبب شده که دولت‌ها به بهانه جلوگیری از این حملات در پی ممنوعیت استفاده از رمزنگاری و یا تضعیفش باشند. فیلم تبلیغی داعش و تهدید کشورهایی که از “کفر” حمایت می‌کنند، بهانه‌ای شد که مجددا به این موضوع بپردازم.

در بخشی از ویدئوی گروه داعش، تصویری از یک ایمیل رمزنگاری شده می‌بینیم.

ایمیل رمزنگاری شده

متن کامل این پیام:

اگر با pgpdump این متن رو چک کنیم ID کلید عمومی رو خواهیم دید:

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

ایمیل رمزگشایی شده

اسنودن معتقده که این ایمیل تقلبیه و به درستی به عدم هماهنگی تاریخ ها اشاره می‌کنه:

snowden

همونطور که می‌بینید تاریخ ارسال ایمیل بعد از تاریخ انجام حمله است. همچنین فرمت main key ID صحیح نیست. اما می‌شه به دستکاری اطلاعات دیگه استناد کرد (مثل ناخوانا کردن user و پسورد) و گفت این بخش از اطلاعات هم دستکاری شده تا از شناسایی جلوگیری کنند.

بحث واقعی یا غیرواقعی بودن این ایمیل ممکنه نهایتا به جایی نرسه اما تاکید داعش در پایان همین ویدئو بر ارسال ایمیل رمزنگاری شده‌ی دیگه‌ای که محل حمله‌های بعدی رو مشخص کرده، می تونه به موج مقاومت دولتی‌ها و سازمان‌های جاسوسی در برابر رمزنگاری، دامن بزنه. فراموش نکنیم که “رمزنگاری” یا به طور خاص رمزنگاری end to end که سبب می شه کسی غیر از طرفین ارسال‌کننده و دریافت‌کننده پیام، توانایی خوندن اون رو نداشته باشه، تکنولوژی عجیبی نیست و خوشبختانه داره استفاده روزمره پیدا می‌کنه. نمونه اون رو در secret chat اپلیکیشن تلگرام می‌بینیم و نمونه موفق‌ترش رو در نرم‌افزارهایی مثل سیگنال و chatsecure می‌بینیم. نکته اینجاست که اگر “آدم‌های بد” می‌تونن از ابزار خوب استفاده کنن، چرا مردم عادی نتونن؟ و اگر استفاده نمی‌کنن هم که صورت مساله پاک می‌شه و دلیلی برای محدودیتش نیست. یادمون نره که با وجود همه این پول‌های خرج شده برای نظارت بر اطلاعات عمومی و خصوصی مردم، مهاجمان پاریس از تلفن‌های عادی استفاده کرده و با sms در مورد حمله صحبت کرده بودند و هیچ سازمانی متوجه نشد.

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

در پست دیگری، از رمزنگاری و سطح امنیتی اپلیکیشن‌های استفاده شده در گروه هایی مثل داعش خواهم نوشت.

پی‌نوشت:

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

https://advox.globalvoices.org/2016/01/25/is-isis-trying-to-manipulate-the-crypto-debate-tech-experts-debunk-encrypted-email-video/

Standard