LINUX.ORG.RU

Правило udev для защиты от вредоносной USB-клавиатуры

 , , ,


1

0

Дайте пожалуйсиа правило для защиты от автоматически подключаемого udev'ом USB устройства как клавиатуры, если одна клава уже подключена.

Для тех кто не вкурсе, есть дыра, благодаря которой любая флеха может сработать как клавиатура после подключения.

Сам я правила для udev писать не умею, так бы сам сделал.

★★★★★
Ответ на: комментарий от intelfx

я надеялся, что кто-то уже писал такое правило...

teod0r ★★★★★
() автор топика

Для тех кто не вкурсе, есть дыра

Интересно также узнать, где находится и как используется ПК, на котором пользователь использует Linux, админит его самостоятельно и опасается такой изощрённой атаки. Почему бы злоумышленнику просто не вытащить HDD/SDD, если он имеет непосредственный доступ к системнику?

Alve ★★★★★
()

Ещё есть забавные устройства в виде флэшки, которые подают на порт двести вольт от встроенного преобразователя . Поможет удев тебе?

anonymous
()

Если ты точно знаешь Vendor ID и прочее своей клавы, то надёжнее будет захардкодить подключение клавы только с определёнными вводными, иначе девайс клавой не считать.

Но если у тебя клава накроется, то тут сразу глубокая задница.

Сам щаз правило не напишу, но если документацию пару часов покурить, то ты и сам напишешь.

r3lgar ★★★★★
()
Ответ на: комментарий от r3lgar

Если ты точно знаешь Vendor ID

а если у вредоносного устройства вдруг окажется такой же Vendor ID?

teod0r ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Да, но тут однозначно нужен эксперимент! :)

anonymous
()
Ответ на: комментарий от anonymous

может просто копеечку в юсб запихать?

anonymous
()
Ответ на: комментарий от anonymous

Его могут майнтейнеры вкомпилять статически в ядро, тк у большинства есть usb клавомышь.

anonymous
()
Ответ на: комментарий от anonymous

вкомпилять статически в ядро

это происки АНБ!

anonymous
()

есть дыра, благодаря которой любая флеха может сработать как клавиатура после подключения.

Как только увидишь что флеха начала вести себя как клавиатура — сразу вынимай её :-D

Гениально , да? :-)

user_id_68054 ★★★★★
()
Ответ на: комментарий от Deleted

да это не то чтоб дыра. Просто если клаву вставить в юсб, то с нее можно набирать буковки. Вот злой хацкер флешку хитрую вставляет, а она олько по виду вся такая флешка, а в нутрях то она клавиатура и при подаче питания эта клавиатура такая набирает rm -f / ...

anonymous
()
Ответ на: комментарий от anonymous

так нечего в дырки непонятные предметы вставлять

anonymous
()
Ответ на: комментарий от teod0r

с чего ты взял что у злоумышленника есть непосредственный доступ?

ну ты ж писал про воткнуть флешку в комп, стало быть человек должен находится рядом, я так понял. Или ты про другой сценарий какой-то пишешь?

Alve ★★★★★
()

Если есть физический доступ к машине, то уже ничего не поможет.
usbguard , судя по всему может помочь частично.

anonymous_sama ★★★★★
()
ACTION=="add|change", SUBSUSTEM=="usb", KERNEL=="input[0-9]*", ATTRS{idVendor}=="dead", ATTRS{idProduct}=="beef", GOTO="persistent_kbd_end"
ACTION="add|change", SUBSUSTEM="usb", KERNEL=="input[0-9]*", RUN+="disable_device.sh %k"
LABEL="persistent_kbd_end"

Ну, как-то так, если не напутал чего. Правда, не знаю, как заставить контроллер снять питание с порта, и периодически снова его подавать, иначе порт до перезагрузки будет обесточен.

yars068 ★★★★
()
Последнее исправление: yars068 (всего исправлений: 2)
Ответ на: комментарий от Alve

Зачем спрашивать, если человек явно не в адеквате?

Вопроса же не было 'Имеет ли это смысл или я больной параноик?'. Ну хочет и хочет.

anonymous
()
Ответ на: комментарий от Alve

ну ты ж писал про воткнуть флешку в комп, стало быть человек должен находится рядом, я так понял.

Ну в общем есть подобный сценарий, применяемый на практике.

В атакуемую организацию подкидывают 'случайно забытых' флешек с полезной начинкой. Ну ты понял.

Хотя ественно, что сабжевый ЯуМамыЛокалхостовыйЛинуксоидКакир никому с подобным сценарием не интересен.

anonymous
()
Ответ на: комментарий от yars068

можешь объяснить про:

"dead"
"beef"
"persistent_kbd_end"
"disable_device.sh %k"
LABEL="persistent_kbd_end"

и как и в каких ситуациях данное правило работает?

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

Ты прям все знакомые тебе слова оттуда перечислил.

anonymous
()
Ответ на: комментарий от anonymous

Надо ещё терминал открыть, а это может делаться совершенно по-разному. Такое говно сработает разве что в винде, и это использовалось некоторыми производителями мышей для запуска установки драйверов задолго до появления этих вредоносных устройств.

anonymous
()
Ответ на: комментарий от teod0r

dead
beef

Оно работает на сферическом в вакууме линуксе. Я ж не знаю, что там у ОП за флешкоклавомышь, VID:PID надо знать. Работать должно так: если это устройство ввода с данными VID:PID, ничего не делаем, иначе выполняем скрипт. man udev в помощь.

yars068 ★★★★
()
Последнее исправление: yars068 (всего исправлений: 2)
Ответ на: комментарий от frozen_twilight

Создаю файл /etc/udev/rules.d/usb-block с содержимым

ACTION=="add", ATTR{bIntarfaceClass}=="03" RUN+="/bin/sh -c 'echo 0 >/sys$DEVPATH/../authorized'"

Делаю ссылку:
ln -s /tmp/usb-block /etc/udev/rules.d/10-usb-block.rules

В скрипте инициализации после монтирования /tmp добавляю:
cp /etc/udev/rules.d/usb-block /tmp/
/sbin/udevadm control --reload

Правило не работает. Проверяю так: ребучу комп с отсоединённой клавиатурой. После того как система загрузилась втыкаю клаву и она работает! Может это потому что переменная DEVPATH не задана? Что-то должно быть в этой переменной?

teod0r ★★★★★
() автор топика
Ответ на: комментарий от yars068

если это устройство ввода с данными VID:PID, ничего не делаем

то есть даже в /dev не будут ссылки на флешки появляться?

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

Наоборот, если ты воткнешь, скажем, флешку, VID:PID которой прописаны в правиле, то она будет работать как обычно (выполнится переход на метку «persistent_kbd_end»), все прочее будет подпадать под вторую строку правила.

yars068 ★★★★
()
Ответ на: комментарий от teod0r

Как-то так:

ACTION=="add", ATTR{bIntarfaceClass}=="03", RUN+="/bin/sh -c 'echo 0 > env{DEVPATH}/../authorized'"
Но не уверен, что это корректная запись.

yars068 ★★★★
()
Ответ на: комментарий от teod0r

Не окажется. Если это внешне флэшка, то она будет прикидываться флэшкой и по вендору и по модели.

r3lgar ★★★★★
()
Ответ на: комментарий от yars068

$env{DEVPATH} тоже не работает

teod0r ★★★★★
() автор топика
Ответ на: комментарий от yars068

я попробовал заместо echo 0 > env{DEVPATH}/../authorized прописать echo $devpath >/11. так файл /11 вообще не создаётся

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

оказалось надо было ATTRS, а не ATTR

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

{bIntarfaceClass}==«03»

С чего ты взял, что все usb устройства ввода — HID?!
Например: втыкаю web-камеру (на ней кнопка), появляется /dev/input/event13 и новое устройство в xinput. В /sys/bus/hid/devices — ничего, в udevadm info -a /dev/input/event13 про bIntarfaceClass — ничего.

Может тогда уж SUBSYSTEM=="input" или просто в xorg.conf прописать клаву и мышь и выключить добавление новых устройств — Option "AutoAddDevices" "false"

arson ★★★★★
()

строго, параноидально говоря, USB - сама по себе большая дыра

anonymous
()
Ответ на: комментарий от arson

Может тогда уж SUBSYSTEM==«input»

Не это слишком общее, лучше привязаться к конкретному порту usb. Кто первый дырку занял, тот и клава.

arson ★★★★★
()
Ответ на: комментарий от arson

тот и клава

ну дак что после RUN писать?

teod0r ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.