Comments 44
при загрузке с которого пользователь сразу получит возможность подписи документов в браузере на неизвлекаемых ключах в доверенной среде
А что защищает «доверенную среду» от автоматического исполнения недоверенных программ с НЖМД?
Правильная конфигурация ОС
Я не вижу каких-то модификаций по этой части в инструкции. Что конкретно нужно сделать, чтобы отключить возможность автоматического запуска программ на НЖМД в процессе загрузки Ubuntu?
При загрузке Ubuntu жесткий диск не подмонтирован. Это решение проблемы?
После завершения загрузки файловые системы на НЖМД действительно не подключены. Но это не значит, что они не были подключены и отключены ранее – в процессе загрузки. Вы не задавали себе вопрос, как Ubuntu определяет, с какого носителя нужно брать SquashFS? Ведь GRUB и syslinux не передают ядру адрес загрузочного устройства (такое происходит только при загрузке установленного дистрибутива, но никак не в случае с Live CD/USB), а значит этот адрес нужно получить как-то иначе.
И не получится сделать «доверенную среду» путем простой модификации Ubuntu, без существенного изменения процесса ее загрузки.
И не получится сделать «доверенную среду» путем простой модификации Ubuntu, без существенного изменения процесса ее загрузки.
И ядро в процессе поиска SquashFS подключает все доступные устройства и запускает с них недоверенные программы?
И ядро в процессе поиска SquashFS подключает все доступные устройства
Да (но не ядро, а «early userspace»).
и запускает с них недоверенные программы
Да, но нужно придать им нужную форму. Поскольку Ubuntu поддерживает загрузку с файловых систем FAT и NTFS, то это вполне может сделать и «вирус» в «винде».
Да, но нужно придать им требуемую форму
Fixed.
Вы не могли бы привести рабочий пример когда загружающийся с USB Линукс самопроизвольно запускает программы с винта?
Просто я тоже был свято уверен что никакой самодеятельности здесь быть не может.
Просто я тоже был свято уверен что никакой самодеятельности здесь быть не может.
Для grml 2009.10 в режиме Live CD:
1. образ для записи на НЖМД – http://digitalcorpora.org/corp/aor/drives/2009-aor-test_grml200910.iso (это PoC);
2. скриншот для этого образа – http://forensicswiki.org/images/4/4c/Grml.png.
Следует отметить, что в live-initramfs (Debian) уже давно (с 2009 года) приоритет при поиске корневой файловой системы отдается съемным накопителям (а в Tails, если мне не изменяет память, загрузка вообще возможна лишь со съемных накопителей, что есть выстрел в ногу многим пользователям, ведь существуют накопители USB Flash и внешние НЖМД, которые udev не идентифицирует как съемные, а значит запуск Tails с них невозможен), в то же время в casper (Ubuntu) ничего особо не менялось в данном плане.
1. образ для записи на НЖМД – http://digitalcorpora.org/corp/aor/drives/2009-aor-test_grml200910.iso (это PoC);
2. скриншот для этого образа – http://forensicswiki.org/images/4/4c/Grml.png.
Следует отметить, что в live-initramfs (Debian) уже давно (с 2009 года) приоритет при поиске корневой файловой системы отдается съемным накопителям (а в Tails, если мне не изменяет память, загрузка вообще возможна лишь со съемных накопителей, что есть выстрел в ногу многим пользователям, ведь существуют накопители USB Flash и внешние НЖМД, которые udev не идентифицирует как съемные, а значит запуск Tails с них невозможен), в то же время в casper (Ubuntu) ничего особо не менялось в данном плане.
Использование Tails — это разумный подход с точки зрения безопасности.
Но нужно смотреть, что у него с usability.
В целом, данная статья — это демонстрация подхода на базе обновленной аппаратной платформы Рутокен ЭЦП Flash с применением ПО Рутокен. Выбор дистрибутива и его уровень его кастомизации — вопрос дискуссионный.
Но нужно смотреть, что у него с usability.
В целом, данная статья — это демонстрация подхода на базе обновленной аппаратной платформы Рутокен ЭЦП Flash с применением ПО Рутокен. Выбор дистрибутива и его уровень его кастомизации — вопрос дискуссионный.
Использование Tails — это разумный подход с точки зрения безопасности.
Все-таки Tails, если в его последних релизах что-то существенно не меняли, не защитит от подмены корневой файловой системы с применением USB-накопителя (например, когда работник не отключает «плохую флешку» перед загрузкой в «доверенную среду»).
Выбор дистрибутива и его уровень его кастомизации — вопрос дискуссионный.
Поэтому нужно четко представлять возможные угрозы. Например, если заменить syslinux на GRUB, то появляется возможность подменить ядро операционной системы на то, которое разместили на другом накопителе. А применение спецификации мультизагрузки позволяет подменить и конфигурационный файл GRUB.
Все-таки Tails, если в его последних релизах что-то существенно не меняли, не защитит от подмены корневой файловой системы с применением USB-накопителя (например, когда работник не отключает «плохую флешку» перед загрузкой в «доверенную среду»).
Опять же вопрос.
Почему Ubuntu начнет использовать файловую систему именно с «плохой» флешки?
Всегда считал, что initramfs запускает первую программу с «финальной» файловой системы, то бишь в данном хранившуюся на флеше
В Ubuntu, если не включать постоянное хранилище данных и не использовать диск с обновлениями драйверов, можно лишь подменить корневую файловую систему на свою (а из нее уже запустить свою программу и переключиться в настоящую корневую файловую систему для продолжения загрузки). Но, например, в KNOPPIX можно подсунуть собственные модули ядра (в ряде случаев они будут автоматически загружены в память) и обновления операционной системы (последние будут без какого-либо участия пользователя распакованы в корень с заменой существующих файлов).
Вредоносный софт модифицирует файловую систему винды, и она «прикинется» корневой для Ubuntu?
Или злоумышленник подключит заранее настроенный HDD, который «обманет» Ubuntu, и она подмонтирует с него корневую файловую систему и запустит с нее приложение?
Такая модель угроз?
Или злоумышленник подключит заранее настроенный HDD, который «обманет» Ubuntu, и она подмонтирует с него корневую файловую систему и запустит с нее приложение?
Такая модель угроз?
Да.
А откуда уверенность, что Ubuntu из, например, двух предложенных корневых систем выберет именно ложную?
Она же по понимает, что в случае наличия корневой системы на HDD и на bootable флешке (что является штатной ситуацией) использовать нужно именно файловую систему с флешки.
Она же по понимает, что в случае наличия корневой системы на HDD и на bootable флешке (что является штатной ситуацией) использовать нужно именно файловую систему с флешки.
А откуда уверенность, что Ubuntu из, например, двух предложенных корневых систем выберет именно ложную?
Перебор файловых систем происходит в алфавитном порядке следования имен их блочных устройств: /dev/sda1 будет протестирован до /dev/sdb1. НЖМД определяется системой раньше, а значит его разделы будут следовать первыми.
Она же по понимает, что в случае наличия корневой системы на HDD и на bootable флешке (что является штатной ситуацией) использовать нужно именно файловую систему с флешки.
Процесс загрузки унифицирован и для CD, и для USB Flash, и для USB HDD, т. е. за все отвечает один и тот же код, который «не знает» про конкретный способ загрузки в данной ситуации, а значит не может игнорировать какие-то накопители. Более того, этот же код должен работать и в ситуации, когда загрузочное устройство заведомо не содержит корневую файловую систему (это редкая, но штатная ситуация для Live CD/USB).
Согласно вашей логике в случае наличия у меня на HDD корневого раздела файловой системы Ubuntu всегда будет использовать именно его файловую систему для работы.
Вы возьметесь продемонстировать атаку по подмене файловой системы?
Вы возьметесь продемонстировать атаку по подмене файловой системы?
В ней нет SquashFS (или иного образа с корневой файловой системой, который ищет код из initramfs в Live CD/USB), а значит Ubuntu проверит и пропустит данную файловую систему. Безоговорочный (без поиска характерных файлов и директорий) выбор файловой системы в качестве корневой происходит в Ubuntu лишь при одновременном соблюдении двух условий:
— на накопителе нет таблицы разделов, файловая система записана прямо в первый и последующий секторы;
— накопитель не идентифицируется программным обеспечением udev как имеющий дисковый тип (т. е. накопитель должен быть каким-то экзотическим).
— на накопителе нет таблицы разделов, файловая система записана прямо в первый и последующий секторы;
— накопитель не идентифицируется программным обеспечением udev как имеющий дисковый тип (т. е. накопитель должен быть каким-то экзотическим).
Вы возьметесь продемонстировать атаку по подмене файловой системы?
Я ее уже демонстрировал, на одной конференции в том числе. Если очень хотите, могу показать еще раз, на примере с Ubuntu 14.04.
Было бы неплохо.
Подготовка SquashFS (делать прямо из Live CD/USB):
Подготовка раздела и файловой системы:
Запись необходимых данных в файловую систему:
Ребут и запуск того же дистрибутива с параметром «nosplash».
mkdir squashfs
cd squashfs/
mkdir sbin bin dev etc usr tmp var
cp /bin/busybox bin/
echo -e '#!/bin/busybox sh\nwhile true; do\necho pwned\ndone' > sbin/init
chmod +x sbin/init
sudo apt-get install squashfs-tools
mksquashfs . ../a.squashfs
cd ..
Подготовка раздела и файловой системы:
sudo fdisk /dev/sda # тут нужно создать один раздел
sudo mkfs.ntfs -f /dev/sda1
Запись необходимых данных в файловую систему:
sudo mount /dev/sda1 /mnt/
cp -R /cdrom/.disk /mnt/
mkdir /mnt/casper
mv a.squashfs /mnt/casper/
sudo umount /mnt/
Ребут и запуск того же дистрибутива с параметром «nosplash».
Кстати говоря, если интересно, то посмотрите, как в ALT Linux Rescue сделана защита от подмены корневой файловой системы.
<мимо>
А какой подход к рискам загрузки доверенной среды внутрь виртуальной машины? Атаки типа Blue Pill.
Полагаю, их можно избежать, например, каждый раз используя загрузку через Boot menu. Но вдруг кто-то bios или UEFI пропатчит? :)
Полагаю, их можно избежать, например, каждый раз используя загрузку через Boot menu. Но вдруг кто-то bios или UEFI пропатчит? :)
Ну как бы да, откуда здесь возьмется гипервизор?
Например злоумышленник установит загрузчик на встроенный накопитель(HDD, SD Card, etc). И будет грузить доверенную среду в гипервизор. Или это уже не рассматривается в качестве риска?
С чего бы вдруг Ubuntu станет грузиться в гипервизор? Загрузчик у нас тоже доверенный и хранится на флеше.
Атака не на ваш девайс, а на компьютер, в котором его загружают. Например: настроили загрузку с USB Flash по умолчанию. Пользователь вставляет флешку и работает. Позже, злоумышленник, которому получил физический доступ к компьютеру, перенастраивает на загрузку с альтернативного HDD, в который установил свой загрузчик и гипервизор. Пользователь не замечает далее загрузку доверенной среды.
Ну про этот случай вы сами верно написали выше. Либо обязать пользователя каждый раз загружаться через boot-меню, либо таки защищать BIOS от несанкционированной модификации.
Насколько я знаю, на рынке есть решения, которые позволяют использовать тот же Рутокен ЭЦП для аутентификации в UEFI.
Сначала аутентифицируетесь в UEFI с помощью Рутокен ЭЦП Flash, потом загружаетесь с него же, потом им же аутентифицируетесь на web-сайте и им же подписываете документы.
Я думаю, что подобный комплексный подход осложнит жизнь злоумышленнику.
Насколько я знаю, на рынке есть решения, которые позволяют использовать тот же Рутокен ЭЦП для аутентификации в UEFI.
Сначала аутентифицируетесь в UEFI с помощью Рутокен ЭЦП Flash, потом загружаетесь с него же, потом им же аутентифицируетесь на web-сайте и им же подписываете документы.
Я думаю, что подобный комплексный подход осложнит жизнь злоумышленнику.
А для рутокена существет-ли ubuntu репозитарий для более удобной загрузки броузерного плагина?
Просто руками что-то куда-то копировать… при этом головой отслеживать зависимости
А если-бы репозитарии с контрольными суммами, подключаемые через ppa
Просто руками что-то куда-то копировать… при этом головой отслеживать зависимости
А если-бы репозитарии с контрольными суммами, подключаемые через ppa
Пока нет репозитария.
Печаль :-(
Но это скорее беда всего отечественного крипто-софта — ни каких исходников, никакого удобства использования не-windows пользователей.
Но это скорее беда всего отечественного крипто-софта — ни каких исходников, никакого удобства использования не-windows пользователей.
Я бы сказал, что в данном контексте Рутокен Плагин — меньшее из зол :)
Просто сталкивался с токенами от Гос.Услуг — там тоже заявлено что работать будет из под linux-а, но .deb пакет собран настолько криво что пользоваться не возможно. А исходников что-бы собрать прямо и под i386 и под amd64 — нету :-(
Касаемо Рутокена — .deb пакет который частично ставится в /opt и отсутствие зависимостей навивает тоску.
Касаемо Рутокена — .deb пакет который частично ставится в /opt и отсутствие зависимостей навивает тоску.
О каком .deb пакете идет речь?
ifd-rutokens_1.0.4_amd64.deb
Взятому с www.rutoken.ru/support/download/drivers-for-nix/
Взятому с www.rutoken.ru/support/download/drivers-for-nix/
Софт внутри токена считается идеальным, не содержащим ошибок и уязвимостей?
Sign up to leave a comment.
Электронная подпись в доверенной среде на базe загрузочной Ubuntu 14.04 LTS и Рутокен ЭЦП Flash