امنیت, برنامه‌نویسی

دور زدن کپچا

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

با اعلام سایت bugcrowd برای اهدای جایزه به کسانی که باگ های سایت رو معرفی کنند، Pwndizzle یه بررسی انجام می ده و متوجه می شه که در بخش ثبت نام، تغییر پسورد و یا پس از وارد کردن پسورد اشتباه، کاربران با یک کپچا روبه رو می شن که خیلی پیچیده نیست. به این فکر می افته که کدی برای دور زدن کپچا بنویسه و بتونه به صورت انبوه در سایت ثبت نام کنه. کد به زبان پایتون نوشته شده و از نرم افزارهای جانبی هم استفاده شده.

signup

دور زدن کپچا

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

ما می خوایم خودمون یه برنامه بنویسیم پس می ریم سراغ OCR. برای تشخیص کاراکترهای تصویری برنامه های مختلفی وجود داره که با آنالیز تصویر، لیست کاراکترهای احتمالی رو بهمون می دن. Pwndizzle از Tesseract استفاده کرده چونکه خروجی های بهتری داره.

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

پروسه ثبت نام دو مرحله داره:

  • بازکردن صفحه ثبت نام و دریافت فرم که شامل تصویر کپچا و کد جلوگیری از CSRF است
  • ارسال اطلاعات ثبت نام (نام کربری، پسورد و غیره) و نوشته تشخیص داده شده در تصویر

برای اینکه اسکریپت کار کنه باید ابتدا صفحه ثبت نام رو دانلود کنه، توکن (نشانه) کپچا و جلوگیری از CSRF رو پیدا کنه، تصویر کپچا رو دانلود کنه، بزرگش کنه و بده به Tesseract.

نمونه ای از پارامترهای دریافتی در صفحه ثبت نام رو در تصویر زیر می بینید:

parameters

کدی که برای مراحل بالا گفته شد با پایتون نسخه ۳.۳ نوشته شد:

در اجرای آزمایشی، کپچای زیر نشان داده شد:

captcha

و خروجی اسکریپت هم به صورت زیر شد:

outputمی بینیم که کد با موفقیت اجرا شد. حالا می تونیم با قرار دادن مراحل گفته شد در یک دور، به هر تعداد که بخواهیم کاربر در سایت ایجاد کنیم. این روش محدودیت هایی داره. برای مثال:

  • Tesseract در عمل تنها ۳۰ درصد موارد کپچا رو درست تشخیص می داده
  • سایت های دیگه ممکنه از کپچاهای پیچیده تری استفاده بکنند که درصد موفقیت رو پایین بیاره
  • محدودیت ثبت نام روزانه برای هر IP نیز می تونه وجود داشته باشه

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

Standard
امنیت

ضعف امنیتی جعل درخواست

ضعف امنیتی جعل درخواست یا Cross-Site Request Forgery (CSRF) ناشی از عدم بررسی صحیح ارسال کننده درخواست و اجرای درخواست های بدون اعتباره.

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

روش های زیادی برای جلوگیری از این ضعف پیشنهاد می شه که بعضی هاش عملا کاربردی نداره. برای مثال گفته می شه درخواست ها رو در قالب شیوه POST ارسال کنید. این روش به راحتی قابل دور زدنه. کافیه که هکر قربانی رو فریب بده که یه فرم رو submit کنه و یا حتی کافیه که جاوا اسکریپت روی مرورگر قربانی فعال باشه و بدون اینکه حتی متوجه بشه یه فرم hidden در سایت هکر، با کمک جاوا اسکریپت ارسال بشه.

شمایی از یک حمله CSRF

شمایی از یک حمله CSRF

برای نمونه می تونیم نمونه زیر رو ببینیم. این مشکل ۶ ماه پیش کشف شده به مدیران سایت گذارش شده، اما بعد از گذشت مدت زیادی، ضعف رو برطرف کردند.

یک کارشناس امنیتی نشون داده سایت Namecheap که یکی از ثبت کننده های معروف دامنه است، در بخش تعیین DNS ضعف CSRF رو داشته.

اثبات:

کد بالا در واقع یک فرم HTML است که یک سری درخواست رو با روش POST به آدرس زیر ارسال می کنه:

در متغیرهای ارسالی، targetdomain.org آدرس سایتی است که قراره هک بشه و ns1.evildns.org و ns2.evildns.org آدرس DNS سروری است که در اختیار هکره.

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

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

در این لینک می تونید روش های کاربردی جلوگیری از CSRF رو ببینید. باید دقت کنیم که هر کدوم از این روش ها نقطه های ضعف و قوت خودشون رو دارند.

برای مثال اجبار کاربر به پر کردن کپچا در هر درخواست می تونه اذیت کننده باشه و تجربه کاربری ناخوشایند و در نتیجه کم شدن استفاده رو در پی داشته باشه. یا چک کردن سایت ارجاع دهنده در صورتیکه هک ترکیبی از CSRF و XSS باشه عملا از کار می افته.

همچنین پیشنهادهایی برای کاربرها و مخصوصا ادمین ها وجود داره:

  • هنگام خروج از محیط کاربری سایت، Loq Out کنید.
  • اجازه ذخیره شدن نام کاربری و پسورد رو به مرورگر ندید و از گزینه “یادآوری” در زمان ورود به سایت استفاده نکنید.
  • از مرورگرهای جداگانه برای ورود به سایت های حساس و وبگردی استفاده کنید.
  • با استفاده از افزونه های مثل No-Script اجرای کدهای جاوا اسکریپت رو روی مرورگرتون محدود کنید.
  • در مرورگری که برای کارهای حساس استفاده می کنید ایمیل ها رو به صورت “متن ساده” بخوانید و html رو غیرفعال کنید.
Standard
امنیت

امنیت در خرید تلفنی و گواهینامه SSL

اکثر گوشی های هوشمند جدید در مرورگر اینترنتی خود امکان تایید SSL را دارند و در صورتیکه مشکلی در گواهینامه امنیتی وجود داشته باشه، به کاربر اخطار می دهند. برای مثال مرورگر های اندروید در بررسی SSL بسیار سختگیرند.

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

amazon

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

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

با مرورگر، اتصال یا امنه و یا نیست و توسعه دهنده کار زیادی نباید انجام بده. کافیه که مطمئن بشه گواهینامه معتبر در مسیر درستی در سرور قرار گرفته. وقتی بحث اتصال امن مطرح می شه، هرچه “creative license” کمتری برای توسعه دهنده درنظر گرفته بشه، بهتره.

تنها راهی که من میتونم مطمئن بشم اپلیکیشن از SSL استفاده می کنه اینه که اون رو با واسطه پروکسی فعال کنم، چیزی شبیه  MITM Proxy و آدرس هایی که اطلاعات بهشون ارسال می شه رو به دست بیارم و در نهایت با openssl این آدرس رو چک کنم تا گواهینامه رو نشون بده و اعتبار سنجی کنه.

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

ترجمه آزادی از تریپ‌وایر

Standard