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

نسخه اولیه اش رو می تونید در لینک زیر ببینید:

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

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

در کنار تغییرات تکنیکال، سعی کردم چهره مناسبی هم به فرم بدم. استایل استفاده شده هم یه نمونه رایگان در اینترنت بود که با کمی تغییرات برای این فرم مناسب شد.

از آدرس زیر می تونید به مخزن گیتهاب این پروژه دسترسی داشته باشید.

اسکریپت رو با مجوز Creative Commons نسخه ۳ منتشر می کنم پس کپی کردن، تغییر و حتی  فروشش آزاده به شرطی که محدودیت های مجوز رو رعایت کنید.

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

به روز رسانی: پس از کامنت مرتضی که در یک سرور، ایمیل ارسال نمی شد و پس از چک کردن موضوع متوجه شدم مشکلی در فانکشن mail در PHP وجود نداره. مشکل از ارسال متن ایمیل در Header بود. متن ایمیل رو به روش base64 رمز می کردم و به ایمیل اتچ می کردم که گویا این سرور نمی پذیرفت این مورد رو. بنابراین اسکریپت رو تغییر دادم که متن به صورت ساده ارسال بشه. می تونید از مخزن گیتهاب، نسخه جدید رو دریافت کنید.

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

ایمیل اسپم

همونطور که در تصویر می بینید ارسال کننده service@informaticsfairview.com گفته شده و از طریق سرور server2.synermaxx.net. در قدم اول گوگل همچین ایمیل هایی رو با نگاه منفی بررسی می کنه چرا که ایمیل از سرور a ارسال شده ولی توی Header داره ادعا می کنه که از آدرسی در سرور b اومده.

اسپمر می تونست اون اعلام “via blah blah” رو که در تصویر می بینید با روش هایی حل بکنه ولی گویا طرف خیلی کاربلد نبوده.

متن ایمیل می گه شما یک پیام صوتی در واتزاپ دارید. یه دکمه گذاشته که کلیک کنیم تا پخش بشه. ببینیم پشت این کلید چه کدی قرار گرفته.

قیافه لینکی که کاربر بهش منتقل می شه به نظر عادی میاد. از کلمات voice و message استفاده شده و یه سری متغیر ارسالی. ولی چرا این لینک در سایت ferlosa.com قرارداره و نه سایتی مرتبط با واتزاپ؟

قبل از اینکه کد رو باز کنیم، می تونیم با استفاده از سرویس safe Browsing این سایت رو چک کنیم و ببینیم بدافزار یا تروجان روی خودش داره یا نه.

می بینیم که سایت تمیزه. لینک بالا رو در یه مرورگر جدا که در محیط ایزوله است باز می کنم. نتیجه نشون می ده که صفحه voice.php از روی سرور پاک شده. احتمالا ادمین سایت متوجه شده.

حدس بعدی که می زنم اینه که سایت هک شده و یه اسکریپت PHP روش قرار گرفته برای منتقل کردن قربانی ها به سایت مخرب. با یه نگاه گذرا متوجه شدم که سایت ضعف امنیتی داره و با تزریق SQL می شه به دیتابیس دست پیدا کرد. با ادمین سایت تماس گرفتم تا نسخه ای از voice.php و یا لاگ سرور رو برای من بفرسته  که بتونم مسیر رو دنبال کنم. با توجه به اینکه پاسخی دریافت نکردم مجبور شدم خودم سایت رو هک کنم تا بتونم با ورود به محیط مدیریت سایت به اطلاعاتی که می خوام برسم.

این اطلاعات جدول کاربرهاست که از طریق SQL Injection به دست آوردم (البته به جای پسورد ادمین ستاره استفاده کردم که لو نره) :

و این هم صفحه ورود به پنل مدیریت

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

درپایان:

این پست یه کار دم دستی بود و تمام جوانب رو پوشش نداد. در صورتیکه به سرور هک شده دسترسی داشته باشم می تونم اطلاعات بیشتری رو راجع به هکر که به دست بیارم.

ضعف برنامه نویسی در ارتباط با دیتابس حتما به این معنی نیست که هکر بتونه در خروجی صفحه نتیجه تزریق رو ببینه و در نتیجه با نشون ندادن خروجی ها از هک جلوگیری کرد. این اشتباهیه که در برخی برنامه ها دیدم. مثلا برنامه نویس گفته هر وقت مشکلی در تماس با دیتابیس بود صفحه رو نشون نده یا برو صفحه اول سایت رو نشون بده.
تزریق SQL می تونه با یه “گزاره منطقی” باشه و یا یک دستور که در لود شدن صفحه تاخیر ایجاد کنه. بهترین روش جلوگیری از SQL Injection بررسی ورودی ها و نیز استفاده از کلاس های PHP (و یا سایر زبان های برنامه نویسی) است که کار ارتباط با پایگاه داده رو به صورت تخصصی انجام می دن.

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

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

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

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

در نظر بگیرید که با داشتن سرتیفیکیت ها و کلید های خصوصی، سازمان های نظارتی می تونن علیه کاربران لاوابیت حمله MiTM * رو صورت بدن.

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

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

لویسون دیگه نمی تونست مقاومت کنه و این شد که دو روز تحویل اطلاعات رو به تاخیر انداخت و ۱۰ هزار دلار جریمه شد تا وقت داشته باشه و سرویس رو تعطیل کنه که جلوی MiTM رو بگیره.

* MiTM مخفف اصطلاح Man in The Middle است که به روشی گفته می شه که کسی (غیر از سرویس دهنده اصلی) ترافیک ارسالی کاربران رو می گیره، بررسی می کنه و به طرف دوم می فرسته و مجددا ترافیک برگشتی از طرف دوم رو می گیره، رمز گشایی می کنه، می خونه و دوباره رمز گذاری می کنه و به کاربر اول می فرسته. عکس زیر رو ببینید:

منبع