Автомобиль и ИБ

Содержание статьи

• Security ∩ Safety
• Компьютеры и сети везде
• Вектора атак
• Беспроводные технологии
• Система развлечений
• Автоматическое вождение — будущее уже рядом
• Вместо прощания

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

Security ∩ Safety

Для автопроизводителей безопасность была важным моментом всегда. Но только для них безопасность — это «safety», а мы говорим про безопасность как «security». Эти множества вопросов имеют пересечения и общие темы, но это не одно и то же. Главный же интерес для нас эта тема представляет потому, что автомобили становятся все более «компьютеризированными» и мир IT и мир автопрома сближаются. Естественно, это увеличивает количество возможных угроз, поверхность для атак и вообще довольно сильно меняет парадигму безопасности автомобиля.

Знаешь, в мире ИБ принято пугать: мол, если вы не подумаете об ИБ сейчас, то вашу систему взломают и вы будете страдать потом. В контексте автопрома этот подход работает великолепно. Например, о безопасности SCADA и АСУ ТП говорили давно, однако это мало кого интересовало, но стоило Stuxnet выйти в паблик, как тема безопасности АСУ ТП стала активно популяризироваться и развиваться. То же самое, только без «публичных инцидентов», происходит и в мире автопрома. Хакеры со всего мира начинают все пристальнее смотреть в эту сторону, включая последнее исследование (правда, очевидное по результатам) от небезызвестных Чарли Миллера и Криса Валасека. Кроме того, посмотри на инициативу Tesla, которая обещала выплатить 10 тысяч долларов тому, кто сможет взломать их автомобиль. Интерес есть, люди есть, работа идет. Давай посмотрим, почему это так интересно и важно.

Компьютеры и сети везде

Практически в любом современном автомобиле присутствует компьютер. Многие вещи автоматизированы и управляются с его помощью. Это ведь так удобно и логично: в автомобиле множество сенсоров/контроллеров — ECU. Фактически это такая АСУ ТП на колесах. Есть контроллеры (ECU): контроллер/датчик давления в шинах, электрозамков, стеклоподъемников, датчики температуры двигателя и множество других, — и все это связано в единую сеть специальной шиной (например, одна из самых популярных — CAN) и управляется ОС в реальном времени, например QNX. Ну и понятно, что каждый современный ECU сам по себе процессор и софт.

Сама архитектура этой сети уже поднимает множество вопросов безопасности, даже если мы не говорим о человеческом факторе. Например, что будет, если выстрелить в автомобиль из EMP-пушки? В теории это может вызвать «ложное срабатывание» контроллеров на одном из ABS и машину развернет и выкинет в стену. Крутая шутка? Нереальная? К сожалению, реальная — у каждого автопроизводителя есть специальная команда, которая тестирует и проверяет все электроэлементы будущего автомобиля на «защиту» от наводок, и это неслучайно.

Например, у тойоты в 2009 году было зафиксировано около 2000 инцидентов произвольного самоускорения и 16 таких случаев привели к смерти. Одной из причин были как раз «внешние наводки». Кстати, поэтому же в самолетах просят выключать телефоны. Да, авиаконструкторы занимаются тестированием и защитой от наводок, так что мобильники не должны повлиять, ну скажем, на выпуск закрылок, но вот почему-то любят в этой сфере «перестраховаться».

Но вернемся к компьютерам и автомобилям. Одна из проблем ИБ в целом — у каждого автопроизводителя «своя» реализация. Поэтому мы имеем разные сетевые архитектуры по сути похожих систем. В нашем понимании эта архитектура также в идеале должна учитывать вопросы ИБ. Например, у некоторых машин CPU/OС, отвечающая за ABS, замки и прочее, — это один компонент, а CPU/ОС, отвечающая за MP3-проигрыватель и фильмы, — совершенно другой. В теории такая изоляция безопаснее, но вот у некоторых производителей это один общий компонент или они подключены напрямую в CAN (без сегментации). Разумеется? при таком подходе к архитектуре получается, что при компрометации системы развлечений, например через MP3 (как внешний источник), мы даем контроль не только над самой «развлекательной системой», но и над всей ABS, двигателем и прочим. Все это усугубляется самим протоколом шины CAN: разумеется, тут нет шифрования, более того, шина работает в режиме широковещательных запросов, соответственно, если посылается пакет в шину, далее он идет по шине и ECU смотрит, «его ли это пакет».

Помимо CAN, есть множество других популярных у производителей протоколов, вроде MOST или FlexRay, кроме того, есть и старый добрый Ethernet! Так что ты понимаешь, что автомобильная сеть довольная забавная и разнообразная штука. При этом технологии развиваются — нас ждет, возможно, и IP ;).

Вектора атак

Как видишь, такая архитектура довольно «уязвима» в случае прямого доступа к CAN. Любому, кто работает или связан с технологиями в автопроме, в принципе, все это и так известно, но изменить что-либо трудно. Я уже говорил об исследовании Чарли Миллера и Криса Валасека, ребята вживую продемонстрировали недостатки такого подхода: подрубились напрямую к CAN разных тачек и стали спуфить сообщения в шину, манипулируя ECU. Советую ознакомиться. Кроме того, «взлом тачек» — это еще и классика: взламывание автозамков, смена прошивок ECU и прочий fun-and-profit. Тема просто огромная и широкая, поэтому в рамках моей скромной колонки мы поговорим лишь об удаленных угрозах и попытаемся сформировать поверхность для атаки, учитывая все вышесказанное про архитектуру внутренней сети.

Беспроводные технологии

Начнем c банальных и многократно озвученных вещей — беспроводных протоколов коммуникации в нашем авто. Bluetooth, Wi-Fi — доверенная сеть с пользователем для работы с системой развлечений.

• Bluetooth — довольно очевидный вектор атаки, и говорить тут особо нечего — можно искать ошибки имплементации протокола, можно просто делать pair на наушники :).
• Wi-Fi — старый добрый Wi-Fi, как правило, используется для доступа в инет с различными целями — обновить карты, получить инфу о пробках, обновить ленту твиттера, наконец! Вектора атаки опять же разнообразны — можно искать уязвимости реализации стека, а можно делать MITM / Fake AP. Как и с BT, вектора могут быть интереснее в зависимости от того, какое «приложение» автомобиля работает и что оно делает. Например, если оно качает новую версию МP3-плеера по инету, а ты митм, то выводы очевидны… В любом случае, это уже атаки на программный стек «системы развлечений», и он может очень разнообразным. Кроме того, нельзя не отметить связь car2car, технологии «будущего», позволяющей машинам быть в единой сети для оптимизации трафика в экстренных ситуациях.
• GPS — спуфинг координат, потеря ориентации. Опять же атаки на реализацию.
• GSM/3G/4G — уже сейчас в некоторые автомобили можно вставлять сим-карту и пользоваться услугами твоего оператора сотовой связи, у некоторых есть возможность подключить такой доступ через внешний USB-порт. В первом случае у нас опять возможность baseband-атак, как и везде. В общем, опять одни и те же технологии — одни и те же атаки.

Кроме привычного стека беспроводных технологий, в авто присутствует и свой неповторимы шарм:

• Radio/RDS — кто знает, что, кроме аудиосигнала, в радио передается и «текстовая» информация. Обычно это может быть название радиостанции, название текущей музыкальной композиции, но этот же канал очень часто используется для передачи сообщений о пробках и прочих проблемах на дорогах. Эта информация парсится и передается в навигационное оборудование, которая на основе этих данных может поменять тебе маршрут. Атаки очевидны — так как информация передается в открытом виде, никто не мешает ее проспуфить, тем самым заставить навигационное оборудование думать, что на этой улице у нас пробка, а та улица закрыта. так что не будет никакого выбора, кроме как ехать по третьей улице. Такая атака вполне реализуема и была продемонстрирована еще в 2007 году, но воз и ныне там (а что сделать?) [http://phrack.org/issues/64/5.html#article]. Ну и как классика — всегда можно найти дыры в парсере этой инфы, если повезет (и да, не забываем про car2car).
• Замки — как ты знаешь, многие замки как бы «беспроводные». Радиосигнал и криптография. Вектор атаки очевиден — открывание дверей всеми хацкерами с SDR не самая приятная штука, но если реализация и криптография хорошая, то не так просто это и сделать. Тем не менее вектор есть вектор, кроме того, да, опять же можно запывнить сам ECU.
• Immobiliser — по сути, еще одна беспроводная защита от угона, может быть RFID, суть та же, что и замок, только на «двигатель». Нет иммобилайзера — машина не поедет.
• Беспроводные TPMS — ECU, контролирующий давление в шинах… И так как провода к такому ECU проводить тяжело, разумно сделать их беспроводными. Таким образом, пацаны с SDR могут играться с твоим давлением. Вектор крайне опасный и неприятный.

Система развлечений

Система развлечений уже полноценный «комп», люди хотят парсить свою ленту в твиттере прямо из машины, а не только слушать музыку. Отсюда порождается множество векторов атаки в зависимости от используемого ПО. Говорить про это в отрыве от реального примера довольно тяжело, но что будет, если загружаемый MP3-файл вызовет BoF в CPU HeadUnit машины? Правильно, компрометация системы и доступ к CAN… (я взял худший случай). Ну и подумай сам — браузер из машины + clienе side атаки, короче, тема широкая и довольно реальная.

Навигация

Отдельным пунктом можно выделить атаки на навигацию авто. Про спуфинг GPS и RDS мы говорили, но есть еще пучок возможных атак, который зависит от используемой системы и ее возможностей. Например, обновление карт через интернет или получение информации о пробках и роутинге через тот же интернет.

Connected Car

Как можно заметить из предыдущих двух пунктов, угрозы плавно множатся с появлением идеи connected car. Теперь уже машина в интернете, и ты пользуешься своим андроид-девайсом, чтобы получать инфу с авто или управлять ее элементами. Добавим к этому облака и персонализацию пользователя в интернете, и выходит, что поверхность атаки переросла из «просто на машину и ее компоненты» в «машину, ее компоненты, мобильные устройства и автомобильные сервисы в сети Интернет». То есть теперь, чтобы атаковать автомобиль, можно пывнить серваки в инете. Например, пользователь имеет аккаунт в облачном картографическом сервисе, где у него сохранены маршруты следования и прочие данные, через банальную и скучную SQLi мы попадаем в его аккаунт в этом сервисе и меняем стандартный маршрут или получаем информацию о его текущем маршруте. Зависит от сервиса и архитектуры и функций, но в целом идея понятна. Но давай глянем на скорое будущее, что нам обещает Mercedes-Benz в 2015 году: открывание дверей удаленно через iPhone, а кроме того, контроль — координаты, состояние и так далее. Смартфон становится частью автомобиля. Ну и да, очевидно, что тема ПДн и личной информации выходит чуть выше, чем раньше, так как добавляются угрозы раскрытия нашего местоположения, наших путей и связей.

eHorizont — система контроля и оповещения. Вкусная цель для хакера?

Хакер #191. Анализ безопасности паркоматов

• Содержание выпуска
• Подписка на «Хакер»

Автоматическое вождение — будущее уже рядом

Google Car на слуху у всех. Автопилот на дороге. Само по себе ездит, объезжает пешеходов и следит за ситуацией на дороге в 360 градусов обзора. Кроме раcпиаренного Google, такие же проекты есть и у Mercedes-Benz, Audi, BMW, Volvo, да и у других автопроизводителей. Теперь прикинем вектора атак с манипуляцией маршрута из предыдущих пунктов, и получается, что хакеры смогут, в некой теории, просто управлять удаленно машинами. Ну кроме шуток, ФБР уже предупредило, что такая технология открывает, например, новые возможности для терроризма, причем ФБР сделало это предположение на полном серьезе — управляемое дистанционное оружие. Я же хотел бы поднять этот вопрос с другой стороны — вектора атак. Кроме очевидного — взлом CPU/ECU, у нас есть возможность манипулировать навигационной системой и таким образом просто спуфить координаты GPS или, манипулируя информацией о трафике, можно заставить машину свернуть на нужную нам дорогу. Это первое, а второе — например, тот же Google Car использует Lidar для построения «реальной карты» на ближайшие десятки метров, а что будет, если засветить эту камеру лазером или накинуть грязную тряпку? Поведение машины должно быть предсказуемо. Например, Mercedes не имеет Lidar, а использует заранее сделанные карты 3D от HERE/Nokia, но тогда вопрос: что будет, если дорога в реальном положении дел будет не соответствовать тому, что есть на картах? Разумеется, инженеры предусмотрели эти вопросы, так как это Safety, а там у них все строго. Тем не менее возникает еще вопрос: вот банальная атака, гопник со знаком STOP в руках выходит на дорогу, машина распознает знак и останавливается? Я уже вижу, что мир будет меняться, так как такие знаки уже не будут работать как надо, возможно, сделают радиознаки или интернет-контроль с сертификацией дорог для «автоматического вождения». Вариантов много, но рисков меньше не становится, пока количество угроз только растет.

Mercedes-Benz — грузовик, который ездит сам. Практичненько и удобно (угонять груз, не выходя из дома?)

Вместо прощания

Надеюсь, тема была интересной, я же для себя определенно чувствую огромный потенциал в этом направлении. Работая в компании, которая непосредственно занимается проектами по Connected Car, навигации и задачам автоматического вождения, я вижу и такие вектора атак, которые не озвучил тут по понятным причинам :). Тем не менее есть еще много путей «влияния» на автомобиль, и мы не можем обойти вниманием эту отрасль в нашем журнале. Так что, я думаю, мы наверняка вернемся к этой теме, но уже более детально. Да пребудет с вами Сила и безопасная езда на дорогах!

Алексей Синцов

Известный white hat, докладчик на security-конференциях, соорганизатор ZeroNights и просто отличный парень. В данный момент занимает должность Principal Security Engineer в компании Nokia, где отвечает за безопасность сервисов платформы HERE

Роль надежности и безопасности в автомобиле будущего

Повышенная функциональность

Современные системы помощи водителю или автономного движения состоят из датчиков, сенсоров, активаторов, радарных и лидарных систем (англ. термин от Light Identification, Lidar — лазерный дальномер). Все они объединяются в единое целое через внутренние и внешние компьютерные сети и управляются микроконтроллерами, поэтому такой автомобиль можно назвать «Интернетом на колесах» (англ. Internet on Wheels). Кроме того, машины могут обмениваться данными между собой, по технологии V to V, а также с инфраструктурой (V to I) — светофорами, дорожными знаками и навигационными спутниковыми системами, например уже привычной системой глобального позиционирования, или GPS.

Для реализации этого комплекса возможностей, естественно, нужно программное обеспечение (ПО), т. е. более 100 миллионов линий кода. Сюда входят коды для различных приложений, операционные системы (ОС) и ПО для организации сетевых коммуникаций и интерфейсов с датчиками и сенсорами, приводами и водительскими экранами.

Повышенная уязвимость

По мере усложнения электронных систем транспортных средств (ТС) все острее становится вопрос их надежности и безопасности. Из-за обмена данными по каналу V to X (от машины к некоему объекту Х) автомобили более подвержены внешним атакам. Уже бывали случаи, когда третья сторона получала контроль над, например, машиной производства компании Jeep и управляла им вместо водителя. Еще одна уязвимость добавляется со стороны владельца автомобиля. Все производители машин для мониторинга много­численных параметров двигателя и поиска неисправностей используют бортовую диагностику (англ. On Board Diagnostics, OBD). Спецификация нтерфейса соединителя OBD II сейчас общедоступна, и, если вы наберете в строке поиска Google «OBD II», он выдаст вам массу устройств с подключением по Bluetooth, которые позволяют контролировать и отслеживать состояние двигателя с помощью смартфона. Это также делает систему управления двигателем открытой для недоброжелателей. В недавней статье исследователей Мичиганского университета было описано использование прямого подключения ноутбука к OBD для перехвата управления большим грузовиком и школьным автобусом.

Кроме того, из-за огромного размера программного кода его надежность тоже является критическим параметром. К примеру, случай с непреднамеренным ускорением, произошедший с автомобилем Toyota, показал, что используемый сейчас код содержит модули, написанные очень давно и не соответствующие современным стандартам качества. Поэтому при создании кода необходимо ориентироваться на стандарты, предъявляющие более высокие требования.

Вопросы стандартизации

В 2011 г. был издан специальный стандарт безопасности для автомобилей — ISO 26262 [1], являющийся адаптацией функционального стандарта безопасности IEC 61508 [3, 4]. Новый стандарт фокусируется на требованиях к электрическим и электронным системам, которые используются в серийном производстве легковых автомобилей, и применяется ко всем процессам, происходящим в этих системах безопасности на протяжении всего срока службы. Он также включает требования к качеству ПО.

Чтобы обеспечить анализ и определение рисков, связанных с подсистемами, этот стандарт использует подход, основанный на уровнях полноты безопасности автомобиля (англ. Automotive Safety Integrity Level, ASIL). Все подсистемы делятся на уровни от A до D, где A — наименьший уровень эксплуатационной безопасности, а D — наивысший, который содержит самые жесткие требования. Эти уровни дополняет класс управления качеством (англ. Quality Management, QM), указывающий на отсутствие требования соблюдать ISO 26262, т. е. на то, что ответственность за гарантию качества лежит на разработчике.

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

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

Тому, как правильно разработать ПО, чтобы написать достаточно надежный код для работы в системе, соответствующей уровню ASIL, посвящена шестая часть стандарта ISO 26262 [7].

Существует еще один стандарт для машин — J3016 [9], разработанный Сообществом автомобильных инженеров, известным как SAE (англ. The Society of Automotive Engineers). В нем автоматизация управления автомобилем разделена на шесть классов, от ТС «без автоматизации» до «полной автоматизации» (таблица). Автоматизированные системы управления, отнесенные к третьему классу и выше, используют ПО, которое для того, чтобы смоделировать окружающую обстановку, собирает данные с датчиков и затем, в зависимости от задачи, решает, как помочь водителю или как управлять ТС. У этого ПО есть и другие важные задачи, такие как определение того, правильно ли функционируют датчики, когда выдавать водителю предупреждения и в каких случаях необходимо передавать управление человеку.

Законодательство

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

Национальное управление безопасностью движения на трассах министерства транспорта США (National Highway Traffic Safety Administration) предложило официальную систему классификации, которая определяет пять уровней автоматизации управления. Начиная с уровня, когда водитель полностью контролирует ТС во все время движения, и заканчивая уровнем, когда ТС осуществляет управление критически важными функциями на протяжении всей поездки, не нуждаясь во вмешательстве водителя.

Кроме того, у каждого штата США свой подход к этому вопросу. Так, Невада еще в 2011 г. стала первым штатом, разрешившим эксплуатацию автономных ТС и проведение испытаний технологий автономного вождения на дорогах общего пользования. За ней последовали Калифорния, Флорида, Мичиган, Северная Дакота, Теннесси и округ Колумбия (Washington DC).

Что касается ЕС, в январе 2014 г. стартовал европейский исследовательский проект AdaptIVe (Automated Driving Applications & Technologies for Intelligent Vehicles — «Автоматизированные приложения и технологии вождения для интеллектуальных транспортных средств»). В его рамках разрабатываются различные функции автоматического вождения для ежедневного использования, которые динамически адаптируют уровень автоматизации в соответствии с дорожной ситуацией и состоянием водителя. Проект также затрагивает ряд правовых вопросов, которые могут повлиять на успешный вывод на рынок данных технологий.

Для решения этой задачи при поддержке Евросоюза было организовано движение «Автоматизация транспортных средств и дорог» (англ. Vehicle & Road Automation, VRA), которое призвано создать сообщество экспертов и других заинтересованных сторон для развития автоматизированных ТС и сопутствующей инфраструктуры в Европе.

В этом направлении работают и некоторые компании. Так, Volkswagen принимает активное участие в формировании европейского законодательства, включая разработку прогрессивной поправки к Правилам 79 ЕЭК (ЕЭК — Европейская экономическая комиссия ООН) в отношении рулевого оборудования.

Правительство Японии тоже ведет подготовку законов, регулирующих использование автомобилей без водителя. Специалисты уже создали классификацию автоматизированного вождения: она делится на четыре класса, один из которых — это полностью автономное вождение.

В Китае компания Baidu также работает над созданием автономного автомобиля в сотрудничестве с компанией BMW. Китайское законодательство достаточно гибкое, что позволяет правительству быстро вносить необходимые изменения. Однако сложность поставленных перед ними задач не будет отличаться от других стран.

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

Подходы к разработке

С учетом всего вышесказанного можно выделить одну из основных проблем в этой области — как же создать код ПО, который был бы и безопасным, и надежным? Как уже упоминалось, стандарт ISO 26262 запускает процесс разработки такого кода, который включает в себя стандарты кодирования и инструменты проверки кода.

Обеспечение безопасности системы начинается с разработки таких функций, как:

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

Поскольку основная часть ПО в этой отрасли пишется на языке С, хорошей отправной точкой для безопасного и надежного кода является стандарт разработки ПО на языке С в рамках стандарта MISRA C:2012 ( MISRA 3). Он обеспечивает набор правил для написания программ на языке C, которые, наряду с отсутствием неопределенности поведения, включают в себя правила, улучшающие обслуживание, проверяемость, компактность и читабельность исходного кода. Также правила MISRA во многом совпадают с таблицами соответствия ISO 26262-6.

Недавно MISRA опубликовала изменение 1 к MISRA 3. Оно содержит 14 новых правил, которые позволят еще шире использовать MISRA в сфере разработки безопасных систем.

В соответствии со стандартом ISO 26262 неотъемлемой частью разработки являются и соответствующие инструменты. Так, программы статического анализа кода являются важной составляющей управления качеством кода, обеспечивая как контроль качества кода, так и его соответствие стандартам кодирования, таким как MISRA. Программы тестирования дают дополнительную уверенность в качестве ПО, а программы проверки измеряют, насколько хорошо ПО выполняет свои функции.

Таким образом, мы видим, что уже сейчас можно создавать и безопасные ТС, и надежное ПО. При этом организации, которые уже перестроили свои процессы разработки в соответствии с требованиями ISO 26262, обнаружили, что даже на начальном этапе внедрения и обучения они начинают выигрывать в части эффективности и получают от этого дополнительную прибыль.

Источник http://xakep.ru/2014/12/24/sintcov-191/
Источник Источник http://controlengrussia.com/innovatsii/internet-on-wheels/