کدهای مخرب در سرورهای گوگل

یکی از استفاده هایی که از گوگل درایو می شه کرد، انتشار یک سایت استاتیکه. برای این کار باید کل فایل های مورد نیاز (html, javascript, css, etc) رو در فولدرهای مرتبط آپلود کنیم.

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

تصویری از کد مخرب

پیش از اینکه کد مخرب رو بررسی کنیم بذارید نگاهی به سایت قربانی بندازیم. در تصویر زیر می بینید که کد جاوا اسکریپتی که سورس آن در https://googledrive.com/host/{uniqueID} قرار دارد به سایت تزریق شده.

سایت قربانی

با چک کردن فایل جاوا اسکریت در سایت ویروس توتال می بینیم که از ۴۷ تست مختلف، ۱۷ تا که اکثر آنتی ویروس های معروف رو شامل می شه، کد رو مخرب تشخیص می دهند.

آنالیز کد جاوا اسکریپت

کدهای مخرب معمولا برای جلوگیری از شناسایی از شیوه های متفاوتی برای obfuscate یا مبهم کردن استفاده می کنند. برای بررسی کد از ابزار Revelo (ابزاری است برای آنالیز کدهای جاوا اسکریپت) استفاده می کنیم و می تونیم پی ببریم که این کد کاربران رو به آدرس زیر منتقل می کنه:

http://kupimaykifour[dot]tk/redi/go.php?sid=6

1	http://kupimaykifour[dot]tk/redi/go.php?sid=6

وقتی این دامنه رو با سرویس مرورگر امن گوگل چک کنیم می بینیم که در آخرین بررسی ها ۱۲۱ اکسپلویت داشته و ۵۴ تروجان.

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

استفاده از ابزار فیدلر برای دنبال کردن مسیر هک

می بینید که با بازدید از صفحه www.{removed}/forum.php و فراخوانی کد جاوا اسکریپت، قربانی ابتدا به سایت توزیع کننده منتقل می شه و سپس به صفحه هایی که شامل کدهای اصلی برای هک کاربرهاست.

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

در بررسی های بیشتر کشف شد که هکر در اقدامات بعدی با استفاده از شیوه های obfuscate یا مبهم کردن، همون تزریق کد جاوای اولیه رو غیرقابل خوندن کرده. می تونید تصویر زیر رو با تصویر دوم همین پست مقایسه کنید

تزریق کد به شیوه متفاوت

که با برگردوندش به کاراکترهای اصلی، به کد زیر می رسیم.

کد مخرب جدید

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

https://googledrive[dot]com/host/0B8xeWwe9pXL-N2JVdk93V2NoNjA/
https://googledrive[dot]com/host/0B8xeWwe9pXL-cnp5NXVJemNOUHM/ 
https://googledrive[dot]com/host/0B8xeWwe9pXL-YjlwVGFrODN5Nnc/
https://googledrive[dot]com/host/0B8xeWwe9pXL-RUY1Z2xPLWp1OVE/
https://googledrive[dot]com/host/0B8xeWwe9pXL-OUw3eDExNDQtZkE/

https://googledrive[dot]com/host/0B8xeWwe9pXL-N2JVdk93V2NoNjA/

https://googledrive[dot]com/host/0B8xeWwe9pXL-cnp5NXVJemNOUHM/

https://googledrive[dot]com/host/0B8xeWwe9pXL-YjlwVGFrODN5Nnc/

https://googledrive[dot]com/host/0B8xeWwe9pXL-RUY1Z2xPLWp1OVE/

https://googledrive[dot]com/host/0B8xeWwe9pXL-OUw3eDExNDQtZkE/

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

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

این شیوه حمله از اعتماد وبمسترها به گوگل استفاده می کنه. به خاطر به کاربردن سرویس های گوگل مثل Analytics و AdSense در بسیاری از سایت ها، کمتر امکان داره که کسی به حضور کدی با آدرس گوگل در صفحه شک کنه.

منبع

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

تزریق دستور و کد

این پست در مورد یکی دیگه از اشتباهات برنامه نویسیه که می تونه نتایج مهلکی داشته باشه.

تزریق کد و تزریق دستور دو نمونه از روش های هک برنامه های تحت وبه که خیلی شبیه به هم اند و از چک نشدن ورودی ها استفاده می کنن. پیش از این در مورد چک نشدن صحیح ورودی ها گفتم. یه ضرب المثل در امنیت Web Application هست که می گه “اطلاعات ورودی کاربر غیرقابل اعتماده”.

بذارید یه سری نمونه از تزریق کد رو با هم ببینیم. فرض کنیم قراره در یک کد PHP با دریافت متغیر arg در url یه عملی روش انجام بدیم و یه خروجی برای کاربر داشته باشه.

$myvar = "varname";
$x = $_GET['arg'];
eval("\$myvar = \$x;");

$myvar = "varname";

$x = $_GET['arg'];

eval("\$myvar = \$x;");

همونطور که در کد بالا می بینید هیچگونه بررسی روی متغیر انجام نمی شه و مقدارش رو توی x می ریزه. نمونه ای از حمله می تونه شبیه زیر باشه

/index.php?arg=1; system('ls')

1	/index.php?arg=1; system('ls')

دستور سیستم در PHP یک کامند رو در سطح سیستم عامل اجرا می کنه. اینجا هکر می تونه با اجرای ls (با فرض لینوکسی بودن سرور) لیستی از فایل ها و فولدرهای فولدری که index.php قرار داره رو به دست بیاره.

بیاید دستورات PHP که می تونن در کنار “عدم بررسی ورودی” ترکیب خطرناکی رو به وجود بیارند با هم مرور کنیم.

اونهایی که کامندها رو اجرا می کنند:

exec           - Returns last line of commands output
passthru       - Passes commands output directly to the browser
system         - Passes commands output directly to the browser and returns last line
shell_exec     - Returns commands output
`` (backticks) - Same as shell_exec()
popen          - Opens read or write pipe to process of a command
proc_open      - Similar to popen() but greater degree of control
pcntl_exec     - Executes a program

exec - Returns last line of commands output

passthru - Passes commands output directly to the browser

system - Passes commands output directly to the browser and returns last line

shell_exec - Returns commands output

`` (backticks) - Same as shell_exec()

popen - Opens read or write pipe to process of a command

proc_open - Similar to popen() but greater degree of control

pcntl_exec - Executes a program

و اونهایی که کدهای PHP رو اجرا می کنند:

eval()
assert()  - identical to eval()
preg_replace('/.*/e',...) - /e does an eval() on the match
create_function()
include()
include_once()
require()
require_once()
$_GET['func_name']($_GET['argument']);
$func = new ReflectionFunction($_GET['func_name']); $func->invoke(); or $func->invokeArgs(array());

eval()

assert() - identical to eval()

preg_replace('/.*/e',...) - /e does an eval() on the match

create_function()

include()

include_once()

require()

require_once()

$_GET['func_name']($_GET['argument']);

$func = new ReflectionFunction($_GET['func_name']); $func->invoke(); or $func->invokeArgs(array());

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

یه نمونه واقعی می تونه کد زیر باشه. می بینید که این پروژه در گیتهاب همچین ضعفی رو داره

حالا روی لوکال هاست این پروژه رو بالا میاریم و نتیجه حمله رو چک می کنیم:

کافیه یه جستجو در گیتهاب بکنیم و ببینیم چند کد مشابه پیدا می کنیم.

و در آخر هم برای اینکه بدونید یک هکر با استفاده ازاین اشتباه برنامه نویسی می تونه تا کجا پیش بره تصویر زیر رو ببینید که همین یکی دو روز اخیر گرفتم. می بینید که موفق شدم یک PHP Shell Script روی سرور آپلود کنم و از این به بعد به کل فایل های سرور دسترسی داشته باشم و کل دیتابیس رو به دست بیارم. می تونم با توجه به ویندوزی بودن سرور سعی کنم پسورد هش شده ادمین رو به دست بیارم و در صورت باز بودن پورت، باRemote Desktop Connection وارد سیستم بشم و راحت تر هر کاری رو بخوام روش انجام بدم.

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

در منابعی که لینکشون رو می ذارم می تونید اطلاعات بیشتر و نمونه های مشابه رو ببینید.

منبع / منبع / منبع / منبع

امنیت

مشکل امنیتی اندروید ۴.۴

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

این ضعف امنیتی تا نسخه ۴.۳ با اندروید بود و ۹۹ درصد دستگاههای اندرویدی رو در بر می گرفت. گوگل اما در نسخه ۴.۴ این ضعف رو برطرف کرد.

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

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

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

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

منبع