می خوای از wifi من استفاده کنی؟

این پست در مورد خطرات حمله man-in-the-middle به مرورگرهاست، مخصوصا زمانی که داریم از شبکه های عمومی استفاده می کنیم. پیش فرض های این پست:

بیرون از خانه ایم
نوتبوک یا گوشی هوشمندمون همراهمونه
اینترنت نداریم
یه وایفای عمومی وجود داره که می تونیم استفاده کنیم
می خوایم اخبار رو چک کنیم
احتمالا ایمیلمون رو هم چک می کنیم (مسلما با اتصال SSL)
مرورگر و افزونه هاش به روزه و کسی نمی تونه با استفاده از ضعف های امنیتی جدید ما رو هک کنه
جاوا اسکریپت مرورگرمون فعاله (معمولا اینجوریه)

خب بیایم ببینیم چه اتفاقایی می تونه برامون بیافته.

Sniffing

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

گرفتن شل جاوا اسکریپت

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

می بینید که کدی با اسم socket.io به مرورگر ما تزریق شده. نمونه ای از اون کد خرابکار می تونه تصویر زیر باشه.

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

خوندن کوکی ها

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

کوکی می تونه فقط برای یک دامنه خاص معتبر باشه. یعنی کوکی های گوگل در سایت یاهو بدون استفاده است.
آدرس سایت باید درست باشه. مثلا یک کوکی می تونه در بخشی از سایت که آدرس /protected_stuff/ داره ممنوع باشه.
سرور می تونه کوکی رو نشان گذاری کنه یعنی در زمان ذخیره کردن بگه این کوکی Secure است و بنابراین مرورگر این اطلاعات رو فقط از طریق اتصال امن (مثلا TLS) منتقل می کنه و هکر به اونها دسترسی نداره. هرچند اینکه یک سایت از کانکشن امن استفاده می کنه معنیش این نیست که کوکی ها رو Secure نشان گذاری کرده.

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

اینجوری می شه کوکی غیرامن هر سایتی رو دزدید. نمونه ای از سایت هایی که با این روش می شه کوکیشون و اطلاعات مرتبط رو به دست آورد:

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

دزدی پسورد

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

سرویس های ایمیل مثل web.de و GMX از فرم لاگین HTTP استفاده می کنند که اطلاعات رو به یک آدرس HTTPS ارسال می کنه. این راه در مقابل sniff امنه اما در برابر این روش حمله، آسیب پذیره. سایت wordpress.com هم این مشکل رو داره.
نمونه دیگه می تونه پسورد روتر باشه. هکر با این حمله می تونه پسورد ادمین روتر ما رو به دست بیاره.

مسموم کردن کش (Cache Poisoning)

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

مسموم کردن دانلود (Download poisoning)

فرض کنیم کاربر ویندوزیم و چندوقت یه بار با استفاده از مرورگر نرم افزاری رو دانلود و نصب می کنیم، برای مثال از sourceforge. اگر نگاهی به سورس صفحه دانلود این سایت بندازیم می بینیم که همیشه از این کد استفاده می کنه:

http://www.google-analytics.com/ga.js

1	http://www.google-analytics.com/ga.js

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

مسموم کردن دستور (Commandline snippet poisoning)

احتمالا با دیدن بخش بالا به خودمون گفتیم: “هه! من که کاربر لینوکسم و نرم افزار دانلود نمی کنم. از مخازن استفاده می کنم”. زیاد خوشحال نباشیم. بذارید یه سناریوی حمله دیگه رو ببینیم. احتمالا بارها پیش اومده که مشکلی توی سیستممون داشتیم و مشکل رو گوگل کردیم و یا توی سایت هایی مثل “انجمن اوبونتو” دنبال راه حل بودیم. به یک روش برخوردیم که با اجرای یک تیکه کد می تونیم مشکل رو حل کنیم. بعد هم با کپی کردن کدی که به نظر سالم بوده، اون رو در ترمینال اجرا کردیم. کافیه هکر یک کد جاوا تزریق بکنه به صفحه هایی که احتمالا بازدید خواهیم کرد و تیکه های کد (snippet) رو مسموم بکنه. این لینک شامل نمونه ای عملی از تکه کدیه که ظاهرش یه چیزه و نتیجه کپی کردن، چیز دیگه است.

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

راه حل

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

منبع

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

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

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

تزریق کد و تزریق دستور دو نمونه از روش های هک برنامه های تحت وبه که خیلی شبیه به هم اند و از چک نشدن ورودی ها استفاده می کنن. پیش از این در مورد چک نشدن صحیح ورودی ها گفتم. یه ضرب المثل در امنیت 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 وارد سیستم بشم و راحت تر هر کاری رو بخوام روش انجام بدم.

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

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

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

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

Session Fixation

احتمالا تا حالا واژه Session به گوشتون خورده. اگر برنامه نویس وب باشید که می دونید چیه ولی کاربرها باهاش درگیر نیستند و پیش هم نمیاد که لازم بشه در موردش بدونند.

بذارید یه مثال بزنم که بدونید سشن به چه کار میاد. تا حالا دیدید می رید توی یه سایت و اون خبر داره که قبلا اونجا بودید؟ جایی لاگین کردید و گزینه “مرا به خاطر بسپار” رو انتخاب کرده باشید؟ یا اصلا فکر کردید چطور می شه که شما توی صفحه login.php وارد می شید ولی دیگه هر صفحه از سایت رو باز کنید، نیازی نیست دوباره نام کاربری و پسورد وارد کنید؟ این کارها با سشن انجام می شه. ینی برنامه اون سایت از شما مشخصات رو می گیره و درصورتیکه درست بود براتون یه شماره شناسه در نظر می گیره و کافیه اون شماره شناسه رو تو صفحه های مختلف به همراه داشته باشید تا دیگه نیازی به وارد کردن مجدد پسورد نباشه. یا مثلا سایت اون شناسه رو فعال نگه داره و دو روز دیگه که وارد سایت شدید، وب اپلیکیشن اون شناسه رو از حافظه مرورگرتون بخونه و شما رو شناسایی کنه.

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

در این پست در مورد Session Fixation در وب اپلیکیشن های مبتنی بر PHP خواهم گفت و یه سری راه رو هم برای جلوگیری از اون معرفی می کنم. تصمیم داشتم در این پست یک نمونه آنلاین از ضعف برنامه نویسی رو براتون بذارم که در واقع نتیجه رو ببینید ولی با توجه به تنظیمات سرور و PHP.ini این امکان وجود نداشت. برای تست می تونید از WebGoat استفاده کنید که یک پروژه است در قالب OWASP که یک نمونه از یک سایت آسیب پذیر رو در کامپیوتر شما ایجاد می کنه و می تونید روش این موارد رو امتحان کنید.

در یک حمله “تعیین سشن”، هکر کاربر یک سایت (ترجیحا ادمین) رو فریب می ده که یک لینک رو کلیک کنه:

<a href="http://target/index.php?PHPSESSID=1234"> 
Click here 
</a>

Click here

</a>

و یا با یک کد، کاربر رو به لینک دلخواه هدایت می کنه:

<?php 
header('Location: http://target/index.php?PHPSESSID=1234'); 
?>

<?php

header('Location: http://target/index.php?PHPSESSID=1234');

ببینیم چه اتفاقی می افته در عمل:

ارسال لینک در قالب یک پیام درون سایت

اگر به لینک دقت کنید می بینید که با ارسال متغیر SID به صورت GET در URL، هکر اقدام به تعیین شماره شناسه ای می کنه که خودش ازش خبر داره. در صورتیکه کاربر کلیک کنه:

صفحه ورود سایت

کاربر بدون اینکه شک کنه، نام کاربری و پسورد رو وارد می کنه و لاگین می کنه. حالا سایت یه سشن براش ایجاد می کنه ولی به جای اینکه شناسه سشن توسط سایت تعیین بشه، عدد ۱۲۳۴ براش به کار می ره.

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

از این زمان به بعد، هکر می تونه با استفاده از SID یا شناسه سشنی برابر با ۱۲۳۴ وارد سایت بشه و سطح دسترسی کاربر هدف رو داشته باشه.

به طور خلاصه، اتفاقی که در بالا افتاد رو می تونید در تصویر زیر ببینید:

یک نمونه از کد دارای ضعف امنیتی می تونه مشابه این باشه:

<?php 
session_start(); 

if (!isset($_SESSION['count'])) 
{ 
   $_SESSION['count'] = 0; 
} 
else 
{ 
   $_SESSION['count']++; 
} 

echo $_SESSION['count']; 
?>

<?php

session_start();

if (!isset($_SESSION['count']))

{

$_SESSION['count'] = 0;

}

else

{

$_SESSION['count']++;

}

echo $_SESSION['count'];

این کد تعداد دفعات بازدید شما از یک صفحه رو می شماره. اگر SID رو توی URL براش مشخص کنید و بعد با همون SID در یک مرورگر دیگه صفحه رو باز کنید، به جای اینکه در مرورگر دوم شمارش از صفر شروع بشه، ادامه شمارش مرورگر اول رو نشون می ده.

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

<?php 
session_start(); 

if (!isset($_SESSION['initiated'])) 
{ 
   session_regenerate_id(); 
   $_SESSION['initiated'] = true; 
} 
?>

<?php

session_start();

if (!isset($_SESSION['initiated']))

{

session_regenerate_id();

$_SESSION['initiated'] = true;

}

واقع در این کد چک می کنیم که اگر متغیر initiated قبلا ست نشده باشه (که به معنی ورود برای بار اوله) شناسه رو بازتولید می کنیم. البته این کد هم یک ضعف داره که با حمله ای پیچیده تر قابل دور زدن است. در این روش هکر در دو مرحله، ابتدا کاربر رو فریب می ده و initiated ست بشه به مقدار True و سپس حمله عادی رو انجام می ده و SID رو تعیین می کنه.

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

session_regenerate_id(); 
$_SESSION['logged_in'] = true;

1 2	session_regenerate_id(); $_SESSION['logged_in'] = true;

یکی دیگه از موارد برای بالا بردن امنیت اینه که زمان منقضی شدن سشن رو محدود کنیم.

روش دیگه برای جلوگیری از این حمله، خارج از بحث برنامه نویسی و با تعیین تنظیمات PHP سروره. کافیه که متغیر session.use_trans_sid رو برابر با ۰ قرار بدیم. این مورد باعث می شه که PHP نه شناسه رو توی URL قرار بده و نه از اونجا بخوندش.

منبع و منبع

Scriptics

Tag Archives: هک

می خوای از wifi من استفاده کنی؟

Sniffing

گرفتن شل جاوا اسکریپت

خوندن کوکی ها

دزدی پسورد

مسموم کردن کش (Cache Poisoning)

مسموم کردن دانلود (Download poisoning)

مسموم کردن دستور (Commandline snippet poisoning)

راه حل

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

Session Fixation