יום שישי, אוגוסט 01, 2014

חשבתם ש BADBIOS זה סיוט הנה הגיע BADUSB

לפני זמן מה יצא לי לקרוא על BADBIOS  - מדובר על נוזקה  שמדביקה את UEFI ו BIOS ומספר חוקרים טענו שבעוד שהנוזקה אפשרית (טכנית) הם מפקפקים בדיווח ,

אתמול ידידי שלח לי קישור מעניין על  BADUSB שבסופו של יום מדובר על שיטה להחזיק נוזקות על התקני USB ולמשתמש הפשוט (בנינו רוב המשתמשים) אין ממש שום דרך להתגונן כנגד זה.


ואז נזכרתי שגם בהפצה שלי אין הרבה מה לעשות פרט למניעה פיזית של הדבר הזה , כלומר נכון שיש את polkit ואת sudo אבל כל זה חסר משמעות אם מתקבלת גישה זהה למשתמש הנוכחי.

בגלל שיש לי די הרבה מקרים שנדבקים בכל מני נוזקות (רשת תאגידית מסוימת שידועה בהדבקות שם) ,חשבתי לכל הפחות להתגונן קצת.

חשבתי לאסור על מודלים מסוימים לעלות לקרנל מה שחשבתי עליו הוא (שזה אמור לחסום כמעט הכל יעזור רק אם לא תתבצע טעינה משנית (ההארה של צפריר) :

blacklist rndis_host
blacklist rndis_wlan
blacklist cdc_ether
blacklist ohci_hcd
blacklist ehci_hcd
blacklist ehci_pci
blacklist gspca_main
blacklist cdc_phonet
blacklist cdc_acm
blacklist cdc_ether
blacklist usbfs
blacklist usbnet
blacklist usbhid
blacklist usbcore



עריכה -

1. צפריר אומר שזה לא יפתור את הבעיה של מניעת עליית מודולים (ראו תגובה מצורפת)

2. קולגה נוסף מסר שההתקפה זו איננה חדשה  (Netragard ביצעו זאת בעבר) ומניעת עליית מודולים תקפה רק עבור התקפות ברמת מערכת הפעלה, זה לא יפתור התקפות שעובדות מתחת למערכת ההפעלה (הסבר שלי דוגמה כמו בהתקפות DMA או הגנה מפני גניבה )



ולשנות חוקי udev שימנעו העלאה של תהליכים אחרים.

ב wired דיווחו כי כביכול אחת הדוברת אמרה בהקשר של הפיטצר המדובר :
Liz Nardozza responded in a statement. “Consumers should always ensure their devices are from a trusted source and that only trusted sources interact with their devices,”

2 comments:

  1. הרבה יותר פשוט - אל תעבוד עם sudo.
    מקבלים גישה זהה למשתמש הנוכחי, אם הגישה שלו לא מאפשרת sudo, הם יכולים לפגוע במשתמש, אבל לא בשאר המערכת.

    השבמחק
  2. הודעה שמעביר דרך מייל

    Blacklisting a module does not prevent it from loading. It merely
    prevents it from being loaded as an alias on a bus. For instance, on my
    system:

    $ lspci -knn | tail -n3
    0c:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme
    BCM5761 Gigabit Ethernet PCIe [14e4:1681] (rev 10)
    Subsystem: Dell Device [1028:053d]
    Kernel driver in use: tg3

    $ /sbin/modinfo tg3 | grep 1681
    alias: pci:v000014E4d00001681sv*sd*bc*sc*i*

    That is, the driver claims to attempt to handle PCI devices with vendor
    ID 14E4 and device ID 1681 (and with and sub-vendor ID, sub-device ID,
    and I'm not sure what bc, sc and i are, but at least some of them should
    be related to device class).

    OTOH, when this module loads, it pulls some other modules with it:

    $ /sbin/modinfo tg3 | grep depends:
    depends: libphy

    If you blacklist tg3, an attempt to modprobe
    'pci:v000014E4d00001681sv*sd*bc*sc*i*' will do nothing. But a direct
    modprobe of tg3 will load it. If you blacklist libphy it would have no
    effect as tg3 depends on it by a direct name and not on any alias of it.

    If you want to prevent a module from loading, use something along the
    lines of:

    # or should it be 'false' instead?
    install libphy /bin/true

    Note that modprobe.d(5) claims that this option is deprecated. .

    השבמחק