Head Unit — как цель для хакера

    В последнее время все чаще и чаще поднимается тема хакерской угрозы в автомобильном мире. Причем тема эта волнует всех — производителей авто, OEM, консультантов по ИБ, и, конечно, власти ЕвроСоюза и США интересуются этой темой (даже выделяют гранты на исследования и тд). Так как в индустрии ИБ очень часто все движухи это попытка «напугать», то хотелось бы разобраться в ситуации «сейчас» и потенциальной ситуации в «будущем» без лишнего пафоса и паранойи, хотя в нашем деле лучше «перебдеть», чем «недобдеть». В ходе своей работы я занимаюсь безопасностью систем ConnectedCar, в том числе и Embedded продуктов для Автомобильных систем. И в свете всего вышесказанного я бы хотел поговорить про недалекое будущее и новые риски связанные с IoT, автомобилями и хакерами. Конкретно в этой части я поговорю про потенциальные вектора атак на Head Unit авто и его окружение.





    Head Unit — сладкая цель?



    Почему я сконцентрировался именно на Head Unit? Да, конечно, в Автомобильной сети есть множество вкусных целей, и гораздо более критичных с точки зрения контроля. Все — таки HU (здесь и далее — Head Unit, даже точнее говорить IVI — in-vehicle infotainment, если про логический компонент) это развлекательная система, навигация, управление некритичными, по задумке вещами, такими как кондиционер и освещение салона. В нормальном автомобиле HU не имеет прямого соединения с критичными ECU (ECU — контроллер управляющий неким узлом — подсистемой двигателя, питанием, ABS и тд). Тем не менее, в виду «компьютеризации» управления получаются интересные вещи — открытие дверных замков, стеклоподъемник или багажник управляется с HU, что уже более «критично». Так что не все так просто. Второе — нет «прямого сетевого соединения» через CAN, но еще не значит что нет логического соединения с критичными ECU. Например, есть такие схемы, где HU подсоединен к некому шлюзу CAN, а с шлюза уже есть доступ к более интересным вещам. Тут бы я привел аналогию с «внутренним тестом на проникновение», то есть уже имея доступ к HU, ты взламываешь промежуточное звено — шлюз, а уже с этого шлюза идешь и атакуешь какой-нибудь важный ECU. Я не буду углубляться в проблемы безопасности CAN и доступа к ECU, все это уже давно известно, а Чарли Миллер и Крис Валасик (кстати, я с ним пиво пил на CONFidence 2011, к делу это отношения не имеет и вряд ли он меня даже помнит, но все равно похвастаться охота, так что упомяну это тут) даже провели обзор этих проблем, включая проблемы аутентификации и брутфорс для ECU по CAN шине, так что кто еще не успел ознакомится, тот может это сделать тут. Короче, как ни крути, но HU это очень хорошая точка входа. Для меня это самая удобная цель, и я могу объяснить почему:

    1) Пользовательская инфа
    Именно на HU у нас работает ОС, которая имеет доступ к данным самого пользователя. Ведь атака на авто может быть частью атаки за пользователем — шпионаж, например. К слову надо бы сказать, что в HU концентрируется почти весь так называемый User Expiernce, например такая фича как автоматическая оплата парковки, или топлива, а значит и более интересные данные.

    2) Удобное место для закрепления в системе — место для BackDoor.
    На HU обычно все монтируется в ReadOnly — но есть и варианты как закрепиться в системе, то есть сделать BackDoor и иметь постоянный доступ к сети. Да, технически тут могут быть сложности по преодолению защиты вендора, но в конечном счете это самое удобное место для закрепления в системе с последующим стабильным доступом. Добавим, что ОС HU это может быть QNX, Linux и даже, Windows CE!

    3) Развитие атаки
    Также следует из пункта 2. Именно с HU удобно атаковать ECU (Gateway) для повышения привилегий и прочего зла. Надо добавить, что именно HU самые мощные с точки зрения производительности компьютеры на авто, там могут быть разные CPU и объем RAM и разные ОС у разных производителей авто, но в целом (так как там нужно рендерить какой-то GUI, работать с сетевым трафиком, проигрывать музыку и все это делать параллельно) очевидно, что там используются довольно мощные, с точки зрения Embeded, железки. Как правило ARM Cortex 6, например Tegra 2 или 3. Всякое может быть.

    4) Удобное место для удаленной атаки
    В навороченных тачках HU имеет множество приложений, множество сетевых соединений с Инетом, не говоря уже про USB, BT и Wi Fi. То есть, атаковать это немного легче, чем, скажем, Wirless TPMS, так как в первом случае есть множество различных векторов, в том числе и из сети Интернет.


    Безопасность автомобиля — это почти то же самое, что и безопасность АСУ ТП, только с PLC контроллеры у нас подключены к смартфону, который подключен к интернету =)

    Суммируя всю эту «аналитику» я для себя вывел, что HU — самая вкусная и желанная цель, хотя, несомненно, есть множество других целей и возможностей — baseband GSM модем, Wirless TMPS, прямой доступ к CAN(локальная атака), атака на сенсоры и радары и т.д. Другими словами, безопасность автомобиля — это не безопасность IoT, вернее не только.

    А зачем?



    Прежде чем продолжать, я бы хотел задаться хорошим вопросом — а собственно зачем кому-либо может интересно взламывать несчастную тачку? В общем, вариантов несколько:

    1) Шпионаж
    Целевая атака на конкретного человека. Например, следить за его передвижениями без «физического жучка». Верно, зачем дублировать функционал авто. В современном авто все уже есть: GPS, GSM, Wi-Fi и BT. Необходимо только «софтверно» все закрепить, причем если это можно сделать удаленно, без физического вмешательства, то тем лучше. Цена атаки, на мой вкус, пока что высока для такой цели, но не будем гадать и играть в аналитиков — архитектурная возможность есть. К тому же есть варианты атаковать ConnectedCar в интернете, без взаимодействия с самим авто, но об этом позже. В принципе, чтобы не плодить пунктов, сюда же можно вписать возможность получить доступ к платежным функциям, про которые я уже упоминал.

    2) Разрушительные действия
    В общем цель довольно сомнительная, но опять же — выведенный из строя в нужный момент ABS довольно опасная вещь. Таким образом, ЭМ пушка вполне может вывести всю электронику авто в нужный момент, на нужной скорости, в нужном месте (на крутом повороте) — это может быть очень опасно. Такие факты уже были в истории автопрома, правда атаки были случайными (ЭМ наводки от базовых сотовых станций). Соответственно, если ECU можно вывести «программно», то в потенциале мы можем получить такой же эффект. Но все же это вариант для фильма, скорее.

    3) Неавторизированный физический доступ
    Можно сказать про угон, довольно «натуральный» вектор, правда скорее связанный с локальными физическими атаками и уязвимостями «локальной сети». Тем не менее, уже был продемонстрирован на практике вариант с MiTM и как результат — «открытие дверей авто».

    Далее поговорим про менее очевидные вектора:

    4) Манипуляция маршрутом
    Пока еще автомобили на автопилоте только в стадии тестирования и доработки, но тем не менее, даже без этой убер фичи мы имеем возможность манипулировать маршрутом — при условии, если водитель доверяет тому, что ему говорит навигатор. И вот если навигатор говорит, что дорога закрыта, там пробка и ехать надо по-другому, то есть далеко не нулевая вероятность, что водитель согласится.

    5) «Локер»
    Чисто для юмора, когда мы обсуждали эти проблемы на 21ой встрече DefconRussia, была предложена идея монетизации — «локер». Садишься ты в машину, заводишь, а на экране красная пелена и адовым шрифтом требование выслать денег на следующий номер, что бы разлочить HU. Забавно, что в данном контексте «локер» еще может действительно «блокировать» двери, окна и что-нибудь еще 8) В случае какой-либо массовой уязвимости или нечистоплотного ТО центра, вполне рабочий вариант.

    Для начала достаточно. Думаю, можно придумать еще, чем и предлагаю заняться в комментариях…

    Вектора атак на HU



    В этой части поговорим про возможности атак. Скажу сразу, я буду говорить чисто теоретически, но тем не менее, многое из сказанного — это опыт реальных практических атак на реальные системы. По понятным причинам, я не буду говорить про ту часть своей работы о NDA, но выжимку, в виде выводов о существовании таких векторов я сделаю, чтобы можно было представить о том, какие атаки возможны в теории. Сначала немного про устройство HU. Как правило, это коробка с выходами на различные панели, дисплеи, сенсоры, GSM/3G модем, card/USB вход, блютус девайс и т.д. Внутри же этой коробки память, ПЗУ и, конечно, ЦПУ, как правило, на ARM чипе. Там же у нас и основная развлекательная ОС со всеми прибабахами: навигация, контроль каких-то элементов салона (ага, дверные замки, например, или стеклоподъемник), видео/mp3 плеер, иногда даже и веб-браузер… Хочу оговориться и сказать, что HU очень разные и у разных производителей и у разных поколений продуктов. Где-то несколько CPU и ОС, где есть даже гипервизор и ОС со всем пользовательским добром вообще виртуализирована. Могу уверено сказать, что немецкий авторпром идет по пути «изоляции пользователя от автомобиля», хотя все же путь этот тернист. В самом простом случае в этой коробке будет общая ОС, но все равно — сам HU «изолирован» на сетевом уровне, про что я так же упомянул.



    ОС бывают разные, и я уже писал про QNX, Linux и тд. В IVI не обязательно иметь RealTime ОС если нет соотвествующих задач (а там редко такие бывают, что вот прям нужна RealTime), но QNX там используется некоторыми производителями (HARMAN, самый яркий пример). Если говорить про Linux, то здесь GENVI и Tizen яркие представители.

    Про изоляцию на сетевом уровне: HU так или иначе подключен к ODB коннектору, который, в свою очередь, подключен к коммутатору. Кроме того, обычно еще есть доступ к аудио системе, телефонии (обычно тут используется MOST шина), и да, бывают и прямые CAN соединения с некоторыми ECU. Где же атакующий может приложить свои усилия, чтобы проникнуть и закрепиться в HU?

    Локальные интерфейсы


    Начнем с самого простого — локальные интерфейсы позволяют взаимодействовать с ОС её сервисами и приложениями. Вектор кажется довольно сомнительным, ведь атакующий должен к этим интерфейсам как-то приблизиться, но тем не менее, надо понимать и еще одну вещь — многие «секреты» спрятаны именно на клиентском «девайсе», то есть сертификатики и пароли, которые (уже было доказано, и не раз) являются расшаренными и универсальными для всего класса систем. Да, да, подход — «никто не должен знать, и тогда все в поряде» (Security Through Obscurity) — довольно распространённая фишка в автопроме 8) Кроме этой цели есть еще гибридные атаки на локальные интерфейсы, то есть фактически, источник атаки может быть удаленный, но механизм проникновения локальный: например, вы скачали Mp3 файл, который имеет теги и метки (допустим там BoF сплойт), залили на HU, запустили плеер и вуаля — BoF в парсере тегов, сплойт в файлике — машинка забекдорена (вот — даже было, хоть и не детально). Таких вот тем может быть довольно много: апдейт карт, POI, фейковое обновление… Кроме непосредственно «атаки через ошибки парсинга формата файлов» есть и неожиданные варианты эксплуатации ошибок в логике обновления, например, карт навигационной системы. Ну и локальные интерфейсы — это не только файлики и импорт: это и BlueTooth, и WiFI хотспот (да, есть и такие фичи!) и USB. Например, оказалось довольно популярным решением делать EthrenetOverUSB. То есть, USB является вполне себе Ethernet входом в локальную сеть HU. Далее подрубаемся по SSH, логинимся как root (вспоминаем, что один пароль на все машины...) и все, песенка спета. А еще то же самое через Wi-Fi хотспот — типа HU открывает такой хотспот и выставляет свою SSH наружу. Еще раз скажу — это не просто догадки, любой из вас может проверить такие банальные вещи (например, фанаты Тойоты и Мазды уже находили такой прикол c USB — http://www.mazda3hacks.com/doku.php?id=notes:sshnotesЯ тоже видел такое и у других вендоров. Так что жду когда хацкеры найдут больше добра, а они найдут!).

    Атака через приложения во имя IoT


    Самый вкусный вектор — через Интернет, и тут открывается масса возможностей, причем эти возможности только растут. Тут можно начинать с классики client-side атак, того же самого браузера и его плагинов. Да, уже давно модно иметь в машине браузер, который может и ПДФки читать и Ворд! Это может быть некая сборка WebKit, ну или Chrome, поэтому классические проблемы и сложности на лицо. Не лишним будет сказать, что бывает и так, что браузер вполне может работать от root'а. Но это все более менее очевидно и понятно (кроме браузера от root'а, это понимать я отказываюсь). Кроме браузера есть куча приложений использующая Интернет и сервисы, от Навигации до Фейсбука.

    Немного хочу сказать про HTML5 безопасность и WEB технологии — по каким-то причинам, эти вещи становятся «встроенными» и на них держится вся логика ConnectedCar. Теперь просто представим, к чему могут привести SSRF/CSRF или XSS? Так если, допустим, HU интерфейс и вся фигня, включая приложения — это HTML5+JS, то имея XSS, мы получаем доступ к внутреннему API — координаты автомобиля, VIN, запас топлива, текущая скорость и другое, что обычно оборачивается в API от сенсоров. А если говорить про CSRF/SSRF, то мы можем взаимодействовать с внутренним API — и манипулировать чем-то внутри авто (если не ECU, то логикой навигации, профайлами, приложениями или развить атаку еще). Это особенно неприятно, учитывая ConnectedCar сервисы — привязку авто к сервису и удаленная манипуляция или доступ к данным.

    В качестве примера, недавний инцидент со взломом BMW. Проблема была в том, что важный трафик шифровался симметричным ключем, который можно вытащить с помощью методов, как сейчас модно говорят, «обратной разработки». C этим ключем шифровались данные для всех автомобилей, так что вытащив такой ключик с одной машины, можно смело его использовать для всех остальных. Сами же данные и команды передавались по HTTP, никакого SSL. Собственно все это позволяло спуфить и эмулировать команду «открыть двери», проводить MiTM — это если образно, детали смотрите по ссылке.


    Вообще векторов разных много

    RDS Spoofing


    Не совсем HU проблема, но с другой стороны парсинг RDS/TMC проходит частенько в навигационном софте, который работает именно там где нам надо. Самая известная проблема — банальный спуфинг. Дело в том, что TMC данные не шифруются, и передаются как есть (это проблема решена только для «частного» и «цифрового» радио, где используются приватные ключи). Таким образом, любой хакер с HackRF может «спуфить» в радиоэфир ложные данные о пробках и ситуации на дорогах. Но кроме этого вектора, можно и пофаззить RDS на наличие уязвимостей в обработке формата, хотя в TMC особо фаззить нечего, но в Radio Text, например, вероятность BoF или типа того может быть не нулевая.

    v2v


    Отдельно отмечу технологию сети v2v. Очень мне нравится идея червя, который будет прыгать с тачки на тачку — подумайте сами, например одним из решений предлагают Wi-Fi (IEEE 802.11p). Надеюсь, к этому времени научат не выкатывать сетевые интерфейсы на 0.0.0.0 и открывать SSH, иначе будет очень интересный экземпляр червя 8)


    Мечта вирмейкера скорого будущего…

    Гибридные черви


    Продолжая тему червей, для авто, на той же DefconRussia были раскрыты забавные вектора, включая эксплуатацию сервисного ПО в севрис-центрах. Приезжает машина, техник делает диагностику, машина заражает рабочую станцию техника через уязвимости в софте. Приезжает следующий клиент, в тот же сервис-центр, и уже техник заражает машину. Отдельно хочу сказать, что очень часто можно встретить ситуацию, когда IVI/HU одного семейства и поколения, но установлены на автомобилях разных марок, что упрощает задачу гипотетическому червячку.
    Ну и говоря про Интернет сервисы — все тоже очень интересно. Подумайте, если запывнить Интернет прокси ConnectedCar или API бекенд, что в Инете, то трафик машин (апдейты, регистрация, какие-то фичи ConnectedCar) будет у тебя под контролем. Опять же, очень много схожего тут с мобильной безопасностью и проблемы у ConnectedCar и HU те же самые.


    Червячки, пока только в теории…

    Будущее рядом — автомобили без водителя


    Что бы не совсем скучно было немного про то, что раньше было фантастикой — роботозированые автомобили. Мир ожидает, что в 2040 году эта технология станет успешно внедренной, а это значит, что то, что мы делаем сейчас станет площадкой для инженеров будущего и вопросы безопасности тут не на последнем месте. Ведь тогда и вектора атак и профит от них будет уже совсем другой. Каким будет HU в 2040 сказать сложно, но можно догадаться — что вся логика навигации и принятия решения будет где-то рядом, поэтому хотелось что бы то, о чем я пишу сейчас и то что показывают хакеры на конференциях, в 2040 стало бы «очевидным» и защищенным как нечто обыденное и элементарное(пообщавшись с специалистами ИБ, которые работают на автопром, хотя бы конкретно Германский, могу сказать что они в курсе всего этого и на верном пути, что радует).


    Я вижу будущее именно так 8)

    Все ли так плохо? Защищайтесь сударь!



    Отдельно хочу написать про то, как HU и автосеть защищена (у каждого по-своему, но так сказать, основные подходы). Подходы эти довольно разные, кто видит одни риски, кто-то другие, но в целом прогресс есть и он будет только расти.

    Например, в текущей обстановке нужно и важно иметь механизм обновления (на клиентском HU). Если найдут багу, или что случится — надо быстро доставить апдейт, обновить всю прошивку или компонент (иначе на отзыве машин можно попасть в копеечку). Причем такой процесс должен быть довольно защищен. Подпись, сертификат — все дела. Вообщем в этом деле есть прогресс и это хорошо.

    По поводу защиты самого HU, то тут дела у всех очень по-разному, но видна общая тенденция движения к изоляции ОС как можно дальше от основной сети и процессов. Например, изолируют не только на уровне сетевой сегментации, но и вплоть до полной виртуализации ОС. Но в целом проблема есть и будет — если ОС нужно иметь доступ к ECU замков, то он будет, так же и к круиз контролю или OBD-II, а значит будет путь к управлению замками, влияние на режим езды и доступ к данным о состоянии авто. Но пока виртуализация не так плотно вошла в нашу жизнь, мы имеем довольно общие проблемы: отсутствие ASLR, не верные права доступа к локальным файлам и тд. Далеко не у всех есть keychain, а многим приложениям надо хранить пользовательские секреты на HU, так что наличие безопасного хранилища так же востребовано в IVI, как и на смартфонах. Про SELinux не говорю, я понимаю что может быть тяжеловато, но все же. А тот же SSH — он же вообще не нужен на HU в продакшене, по какой причине он там — не понятно (кстати, хочу для честности добавить, что ситуация меняется, и сейчас встретить SSH стало сложнее — его включают только на релизах для разработки). Вообще проблема hardening у вендоров на лицо: простите меня, на браузер от root'а (кстати, к чести сказать, это тоже сейчас становится редкой проблемой, разработчики не дураки и то же все понимают и исправляют).

    Отдельно стоит интересная задача по соблюдению целостности. С моей точки зрения, даже если кто-то смог выполнить код на HU, у него не должно быть возможности закрепится в системе, даже если он root. Но на практике кто-то забивает на эти проблемы и ФС можно перемонтировать с rw правами, а у кого-то HU уйдет в ребут при малейшей попытке изменить хоть что-то в конфигурации.

    Виртуализация


    И немного об вирутализации, как о решении всех проблем. Одним из основных стратегий защиты ОС с «развлекательными» приложениями, как уже писалось выше, является её вирутализация. Думаю через N лет, так или иначе это будет реализовано у всех многих производителей. Плюсы тут, конечно, очевидны: такая ОС изолирована от основной авто-системы, в том числе и на сетевом уровне. Это, несомненно так, но даже если будет скомпрометирована такая ОС атакующий может получит уже нечто ценное. Во-первых данные пользователя, которые обрабатываются в данном слое изоляции, а это уже достаточно для того, что бы считать «взлом» успешным — данные с сенсоров, координаты, точку назначения, данные приложения… токен доступа FaceBook наконец, ради этого стоило ломать HU! Во-вторых, некие API и сервисы будут «прокинуты» в вирутализированую среду, включая так или иначе UI дисплея, что позволяет в любом случае развить атаку, в том числе «вниз». В конечном счете, зависит от многих факторов и каждую систему нужно рассматривать отдельно, однако в целом такой подход, мне кажется верным, так как усложняет задачу атакующему так или иначе…



    Вместо выводов



    Я написал достаточно много, но вроде ничего конкретного. Тем не менее, я хотел обратить внимание на одини из ключевых объектов — Head Unit и IVI, какие риски там ждут, почему и что с этим делают разработчики/вендоры. Сейчас достаточно информации про проблемы CAN сетей: общий доступ, некоторые ECU можно досить и брутить, и тем более можно снимать данные и тд. Но все эти атаки и примеры оторваны от конкретного практического применения в контексте «удаленной атаки на автомобиль из Инета». Я хотел показать, как мне кажется, основную цель и лишь некоторые её проблемы (особенно учитывая Connected Car фичи) и текущую ситуацию в индустрии (по моему скромному мнению). Никого пугать или обнадеживать я не хотел, поэтому сия заметка не претендует ни на рекламу вендоров, ни на «вау, хакеры могут все сломать, как страшно жить». Но, сломать конечно могут, и уже этим летом, на Black Hat в Лас Вегасе, все те же парни Крис и Чарли продемонстрируют удалённый вектор атаки на реальный автомобиль по полной программе — удаленное проникновение, получение доступа к CAN, влияние на критичные ECU. Не знаю, будет ли затронут HU как точка входа или повышения привилегий и вообще, что это будет за атака, но шоу уж точно выйдет хорошим, а главное, демонстрирующим реальные возможности 8) Всем безопасной езды!
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 5

      +3
      Какого-нибуть реального примерчика не хватает, но всё равно интересно. И за ссылочки спасибо, почитаемс.
        +3
        Спасибо за коммент. Да, с этим проблемы… Я постарался показать все наглядные примеры, которые доступны в паблике: с SSH, с ConectedCar BMW и даже с BoF в MP3. + уже этим летом Крис и Чарли покажут действительно реальный пример с удаленным вектором.

        Те же примеры, атаки и PoC, что есть у меня являются внутрерабочими вещами, которые уже зафиксены (и признаемся честно, в этой индустрии не любят гласности) и мой работодатель не оценит такого юмора.
          +2
          Немного брутальный взлом, но всё-же:



          1. Злоумышленник бьёт стекло для физического доступа.
          2. Подключается к ODB2
          3. Вставляет «чистый» ключ.
          3. Копирует ключ иммобилайзера авто на новый ключ
          4. Заводит и уезжает.

          В этом видео авто утолкали что-бы не шуметь, завели за углом и уехали.

          Да, ничего не взламывали (кроме стекла). Это-то и пугает.

          Парень хозяйки данного авто провёл свой ресерч, говорит цена девайса для копирования ключей — £8000
          0
          Вспомнилось старое видео

            0
            Выход — использование открытого программного обеспечения, открытого железа (PCB), и по возможности, открытых блоков дизайна микропроцессоров. Я приводил конкретный пример со ссылками на код удалённой «диагностики» изображения на экранах одного устройства из Тайваня (WP9900) пару лет назад в песочнице. Код так же позволял запускать некоторые команды на устройстве — то есть, по сути, был обычным трояном.

            Only users with full accounts can post comments. Log in, please.