Анализ информационной безопасности современного автомобиля. Часть 2

1  2  3

---

2. МАТЕРИАЛЫ И МЕТОДЫ ИССЛЕДОВАНИЯ

 

В качестве основного метода исследования использовали собственно собранный испытательный стенд (рисунок 12), состоящий из

• устройства Vector VC121-12 ECU, предназначенного для прототипирования и мелкосерийного производства спортивных автомобилей и сельскохозяйственных машин. Оснащен интерфейсом Flex Ray, 6 CAN, 2 LIN и 1 Ethernet Broad-Reach. Более подробную информацию об этом можно найти в техническом описании [60];
• устройства Vector VN5 610A – для связи сетевого интерфейса в ПК.

Этот ECU использует физический уровень 100Base-T1 (как отмечалось ранее, он также известен как Broad-Reach). Для связи с персональным компьютером (ПК) необходим сетевой интерфейс для взаимодействия между двумя различными физическими уровнями 100Base-T1 блока ECU и 100Base-TX.

 

Зеленая линия на рисунке 12 представляет автомобильное Ethernet-соединение от ECU, а синяя линия представляет стандартный Ethernet-порт 100Ba se, который подключается к конвертеру Ethernet-USB через USB-порт. На компьютере установлен виртуальный компьютер Mac с операционной системой Kali Linux [59]. Кали была выбрана по нескольким причинам. Во-первых: OS специально разработан для тестирования на проникновение, отсюда и множество необходимых инструментов. Вследствие строгой регламентации корпоративных программ, утвержденных отделом обработки данных, они могут быть установлены в Windows. В виртуальной машине, с другой стороны, единственное правило заключается в том, чтобы хранить его и отключать доступ к файлам компании. Следовательно, виртуальная машина Kali была идеальным выбором. Виртуальная машина Ethernet Адаптер настроен для работы в режиме моста с физическим преобразователем USB-Ethernet, эффективно выступающим в качестве концентратора между Windows, Linux и ECU.

Так как инструменты Vector и другие инструменты программирования разрабатываются для Windows, настройка и настройка (т. Е. Компиляция, перепрошивка и отладка) выполняются непосредственно с ПК. Однако сетевые инструменты, интегрированные в Kali, превосходят возможности тестирования Windows. По этой причине тестирование в основном производится с виртуальной машины Kali. Основным элементом на диаграмме является встроенный в кристалл анализатор iC5000 iSY STEM AG (см. Раздел 3.4.2 .3), являющийся отладчиком, имеющим прямое соединение JT AG с ЭБУ. Это соединение JTAG делает возможным мигание и отладку ЭБУ.

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

 

2.1 Расчеты RAV

 

OSSTMM определяет RAV как скалярную метрику для измерения поверхности атаки. Преимущество наличия метрики для безопасности заключается в том, что она применима ко всем системам. Еще одним преимуществом оценок RAV является то, что они могут быть легко пересчитаны при изменении системы или оценке влияния дополнительного контроля. Рисунок 13 показывает как RAV-оценки могут быть использованы для отслеживания безопасности системы за определенное время. RAV выражаются через логарифмическое уравнение по основанию 10. Балл RAV, равный 100, представляет собой идеальный баланс между операциями, средствами управления и ограничениями, а реби — идеальной безопасностью. Хотя это обычно интерпретируется в процентах, на самом деле это логарифмическая шкала, значения которой могут превышать 100. Значения больше 100 указывают на избыточные контроли. Это может показаться желательным, но может быть проблематичным, так как дополнительные средства управления увеличивают сложность и в некоторых случаях добавляют взаимодействия.

Как гласит методологическая статья, тот факт, что шкала является логарифмической, помогает «понять общую картину» [6]. По этой причине термин «фактическая безопасность» был введен раньше. Этот принцип применим ко всем каналам и передает одну и ту же информацию. В руководстве приведен пример компьютерной системы 1000 и 10 компьютерной системы, в которой один и тот же показатель RAV сопоставим. Руководство идет дальше, сравнивая компьютерные сети со зданиями, и показывает, что даже в этом случае RAV-результаты сравнимы.

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

Электронная таблица калькулятора RAV, предоставленная ISECOM, будет использоваться для расчета баллов RAV. Эта электронная таблица доступна на [70].

Баллы RAV являются основным средством оценки безопасности системы. Они дают общий балл за безопасность системы, и легко увидеть последствия любых изменений в системе. Для оценки этой работы автор решил рассчитать несколько баллов RAV для разных конфигураций системы, чтобы их можно было сравнить. Различные системы были определены следующим образом:

1. a) Базовая оценка RAV, которая представляет реализацию стека Vector TCP / IP без каких-либо специальных настроек, связанных с безопасностью.
2. b) Оценка RAV для стандартной реализации стека TCP / IP со всеми уязвимыми протоколами, которые не были реализованы в стеке Vector TCP / IP.
3. c) Несколько оценок RAV для различных связанных с безопасностью конфигураций, которые стек Vector TCP / IP реализовал во время написания этой диссертации (статический кэш ARP, отключенные ICMP-эхо-запросы и подписи встроенного программного обеспечения).
4. d) Оценка RAV, в которой все связанные с безопасностью конфигурации объединены в одной системе.
5. e) Оценка RAV с возможными будущими реализациями для повышения безопасности (например, шифрование, подписи и т. д.).

Ожидается, что оценка RAV системы (b) будет иметь более низкую оценку RAV, чем базовая система (a), поскольку она имеет больше операций при сохранении того же числа элементов управления. Ожидается, что оставшиеся системы будут иметь более высокие оценки RAV, поскольку все они реализуют средства управления, которые отсутствуют в системе (a), или избавляются от избыточных операций, которые присутствуют в системе (a).

 

3. РЕЗУЛЬТАТЫ ИССЛЕДОВАНИЙ

3.1 Определение качества сети

 

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

Пакеты программ отправлялись туда и обратно между виртуальной машиной и ECU. Запросы по разным протоколам отправлялись в ЭБУ. Измеряли время отклика и скорость передачи пакета данных. Протестированными протоколами являются ICMP (эхо-запросы), TCP (инициализация соединения TCP с отправкой пакета с установленным флагом SYN) и UDP (используется в сообщениях запроса идентификации транспортного средства DoIP). Все пакеты отправлялись сто раз, а минимальное, среднее и максимальное время ответа сохранено.

Минимальное, среднее и максимальное время отклика приведены в таблице 1.

Таблица 1 – Результаты, по определению качества сети

 

Для сетевого протокола ICMP были отправлены эхо-запросы и собраны соответствующие эхо-ответы. Время между моментом отправки запроса и моментом получения соответствующего ответа измеряется как время ответа.

В случае тестов TCP был отправлен сегмент TCP с флагом SYN, а соответствующий сегмент TCP с установленными флагами SYN и ACK был перехвачен. Время между исходящим и входящим сегментом было принято за время ответа.

Метод измерения был немного другим для случая UDP. Поскольку UDP является протоколом без установления соединения, и не существует такой вещи, как пинг UDP, пришлось использовать альтернативные средства. Когда дейтаграмма отправляется на открытый порт UDP, она просто использует ее, и ответ не отправляется, если не запрашивается ни один. С другой стороны, когда закрытый порт принимает дейтаграмму UDP, RFC 792 заявляет, что: «… хост назначения может отправить сообщение о недоступности пункта назначения хосту источника». [71]. Однако, поскольку недоступным местом назначения является сообщение ICMP типа 3, которое не реализовано в стеке Vector, оно не будет отправлено. Это означает, что без отправки законного запроса на известный открытый порт невозможно выполнить какие-либо измерения. Поэтому пакет DoIP на основе UDP был создан и отправлен в ECU. Отправленный запрос является сообщением запроса идентификации транспортного средства, как указано в ISO13400 [74]. Поскольку запрос требует некоторого времени обработки в ЭБУ, время ответа намного больше, чем в случае двух других протоколов.

 

3.2 Подбитые кадры Ethernet

 

Как известно, кадры локальной сети Ethernet должны иметь минимальную длину 64 байта. Из этих 64 байтов в отформатированном кадре Ethernet II, 22 байта принадлежат данным со статической длиной, таким как адреса источника и назначения, тег VLAN и проверка циклическим избыточным кодом. Преамбула и начало разделителя кадров не учитываются в 64 байтах, поскольку они обрабатываются на физическом уровне и всегда одинаковы. Оставшиеся 44 байта должны быть либо полезными данными, либо заполнением, если они слишком короткие.

RFC 894 [76] определяет, что заполнение должно состоять из октетов (байтов) нулей. Однако было отмечено, что многие производители не выполняют заполнение, как того требует RFC, а используют части памяти, иногда память ядра для заполнения кадров. В ошибочной реализации злоумышленник может просто отправить несколько эхо-запросов ICMP и в ответ получить потенциально ценную информацию о памяти. Таким образом наша цель состояла в том, чтобы убедиться, что конфиденциальные данные не передаются через заполнение кадров Ethernet.

Эхо-запросы с протокола ICMP отправляются с виртуальной машины Kali и фактической машины с ОС Windows 7. Кроме того, проверяется заполнение других пакетов.

Результаты исследований показали, что через заполнение не просачиваются конфиденциальные данные. Пакеты ответа на эхо-запросы реализуются в соответствии с RFC 792 [71], что означает, что ответ будет иметь ту же полезную нагрузку, что и запрос. Запросы от Windows и Kali с их соответствующими ответами от ECU можно увидеть на рисунке 14. Невозможно было генерировать более короткие сообщения ICMP из Windows или из Linux, потому что сетевая карта автоматически добавляет заполнение. Автору не удалось найти способ отключить автоматическое заполнение. Из-за этого были также исследованы ответы на запросы TCP и UDP. В этих ответах ECU пришлось добавить отступы, потому что данные были слишком короткими. Было установлено, что заполнение соответствует RFC 894 [76], поэтому уязвимости нет.

 

3.3. Демонстрация сервисных (Do S) атак

 

Цель DoS и распределенных DoS-атак состоит в том, чтобы перегружать каналы связи не релевантными данными, чтобы действительные запросы не могли быть обработаны. Существует множество вариантов таких взломов, и от них довольно сложно защитить себя. Обычные DoS-атаки можно предотвратить с помощью фильтров и брандмауэров. IP-адрес, с которого начинается атака, может быть полностью заблокирован, или информация, полученная с него, может быть отфильтрована. Когда это делается в сочетании с DoS-атакой, существует опасность блокирования легитимного хоста сети. Механизм, обеспечивающий непризнание, поможет в фильтрации от законного общения.

Цель теста: затруднить процесс перепрограммирования с помощью DoS-атаки по протоколу TCP.

Сцена: последнее ложе, как показано на рисунке 12 Сеанс прошивки работающей прошивки занял место между ECU и vFlash, работающими на ПК. Виртуальная машина Кали выполняет атаку.

Процесс: Процесс перепрошивки выполняется через DoIP. Поскольку большие файлы отправляются, связь DoIP проходит по TCP. Tcpkill, часть dsniff, — это программа, созданная для тестирования сети. Он прослушивает текущие соединения TC P на выбранных хостах и ​​прерывает их, вставляя пакеты с флагом RST в канал связи. Это приводит к разрыву соединения педа.

Результат: Рисунок 15 показывает, как выглядит нормальный процесс прошивки с vFlash. В дальнейшем можно увидеть захват Wi-reshark связи T CP между vFlash и ECU.

Рисунок 15 показывает, что происходит, если tcp kill запускается до запуска процесса перепрошивки.

Появляется сообщение об ошибке «Связь не удалась» и RST помечает TCP

Сегменты можно увидеть в окне Windows. Это про одну из уязвимые возможности самого протокола TCP. Как защитить себя от атак такого типа?

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

 

3.4 S OME/IP

 

Подделка

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

Цель теста: доказать, что в некоторых случаях возможна подделка и подделка SOME / IP.

Сцена: испытательный стенд, как показано на рисунке 12. На ЭБУ запущено прикладное программное обеспечение с текущими сообщениями SOME / I P.

Процесс: ЭБУ обменивается НЕКОТОРЫМИ / IP-данными с ПК. Данные графически представлены в виде непрерывной функции, похожей на цепную пилу, из нескольких треугольников (как показано на рисунке 17). На Kali запускается сценарий, который отправляет специально созданные пакеты с разными данными.

Результат: как только скрипт запускается, линии на графике становятся неправильными, как показано на рисунке 17. Это доказывает, что подделка возможна. В данном примере последствия представляют собой просто некорректный график. Однако то же самое можно было бы сделать с потоком с камеры, который подается в систему управления оперативным движением, которая отвечает за поддержание заданного расстояния от автомобиля впереди. Последствия такой атаки пугающие. SOME / IP все еще является относительно новым протоколом, над которым ведется работа. Рассматриваются некоторые опции безопасности, такие как Secure Onboard Commication (SecOP) и d(TLS) [77]. Другим решением было бы использование безопасного протокола передачи данных в реальном времени (SRTP) [78], который обеспечивает шифрование, целостность и аутентификацию сообщений в сочетании с мультимедийным интернет-ключом (MIKEY) [79], который ключевое решение для управления, которое предоставляет сеансовые ключи для SR TP.

 

3.5 Отравление ARP Cache

 

При отравлении кэша ARP подделанный ответ ARP или запросы отсылаются злоумышленником для того, чтобы скомпрометировать (отравить) кэш ARP атакующего хоста. Таким образом, используется действительный IP-адрес, чтобы атакующий узел связывал MAC-адрес злоумышленника с действительным IP-адресом. После этого злоумышленник получает все данные, предназначенные для законного хоста. Он может фильтровать данные и пересылать некоторые данные на законный хост или контролировать весь обмен данными без пересылки чего-либо на законный хост. Отравление кэша ARP обычно делается для большинства атакующих людей. Это может быть даже полезно для атаки TCP Hijacking.

Цель теста: продемонстрировать отравление кэша ARP и доказать, что это возможно сделать с нестатическими таблицами ARP.

Область применения: испытательный стенд, как показано на рисунке 12. Пример прикладного программного обеспечения работает на ЭБУ. Построитель пакетов Ethernet был добавлен в настройку для генерации и отправки поддельных пакетов.

Процесс: сформирован пакет запроса ECHO и два пакета запроса / ответа ARP с соответствующими MAC-адресами AA: AA: AA: AA: AA: AA и CC: CC: CC: CC: CC: CC. Обмен пакетами происходил следующим образом:

1. Пакет запроса ECHO с 168.254.11.17 (случайный IP-адрес) был отправлен на 168.254.11.35 (ECU)
2. За пакетом запроса ECHO непосредственно следует ответ ARP с созданным MAC-адресом AA: AA: AA: AA: AA: AA (показано на рисунке 19 а).
3. После того, как ответ ARP получен от ECU и его кэш обновлен, ответ ECHO выходит, как ожидается, AA: AA: AA: AA: AA: AA: (показано на рисунке 19 б)
4. Еще один ответ ARP отправляется, только на этот раз, когда CC: CC: CC: CC: CC: CC является MAC-адресом (показано на рисунке 20 а).
5. Снова следует запрос ECHO
6. На этот раз ECU отправляет ответ ECHO в CC: CC: CC: CC: CC: CC (показано на рисунке 20 б).

Результат: тот факт, что ECU ответил на один и тот же запрос ECHO на два разных MAC-адреса после получения соответствующих ответов ARP, показывает, что возможно отравление кэша ARP. Это можно легко предотвратить, включив опцию «Статические таблицы ARP» в DaVinci Configurator, но тогда все устройства в сети необходимо будет ввести в таблицу ARP, и будет невозможно добавить устройства на лету, пока система работает. эксплуатации. Каждое добавление устройства потребовало бы перепрограммирования прошивки ЭБУ. Тем не менее, в статичной среде, как автомобиль, это не такой уж плохой вариант, учитывая все преимущества, которые он несет с собой. Многим людям, находящимся в середине атаки, было бы труднее или даже невозможно сделать, если кэш ARP не может быть отравлен.

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

 

3.6 TCP угон

 

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

Цель теста: перехватить соединение прошивки DoIP-прошивки

Область применения: испытательный стенд, как показано на рисунке 12. ПК выполняет vFlash для процесса перепрошивки, а виртуальная машина Kali запускает скрипт Python, который анализирует пакеты и десинхронизирует соединение при необходимости.

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

На рисунке 21 показано сообщение об ошибке «Ошибка доступа к безопасности …», которое генерирует vFlash после десинхронизации сеанса.

Важные пакеты помечаются следующим образом:

1. Внедренный TCP-пакет с поддельным порядковым номером для угона
2. Попытка vFlash отправить законный пакет, который распознается как повторная передача TCP из-за повторяющегося порядкового номера
3. Содержимое созданного пакета с полезной нагрузкой с надписью «Hijacked»

Результат: процесс угона был успешным. Обычные инструменты угона не могут быть использованы из-за того, что они требуют определения портов источника и назначения. vFlash, в соответствии с ISO13400, не запускает каждый сеанс на одном и том же порте источника. В связи с этим был написан скрипт на python с использованием scapy для прослушивания всех пакетов и определения пакета, который успешно прошел аутентификацию после обмена начальным ключом. Сессия была десинхронизирована. vFlash немедленно сообщает об ошибке и отправляет пакет для закрытия соединения. Это можно предотвратить несколькими способами. Кэш ARP может быть отравлен, и если человек находится в середине атаки, эти пакеты могут быть отфильтрованы. Другой вариант будет подделывать пакеты для vFlash, чтобы он не замечал что связь была ансинхронизирована. В качестве альтернативы, его можно просто отключить, но это потребует точного времени.

Эта атака возможна, если злоумышленник может обнаружить незашифрованную связь. В случае этого испытательного стенда главным фактором было то, что практически вся связь видна любому. Если бы это было не так, было бы намного сложнее угадать числа последовательностей. Сначала реализуем TCP-протокол, используемый для увеличения начальных порядковых номеров после определенного периода времени. Конечно, он был очень слабым, так как можно было легко установить соединение с хозяином, посмотреть, какую последовательность он получит, и, попробовав число вокруг него, он получит высокую вероятность угона другого. текущая сессия. Это не тот случай, в настоящее время и в этой реализации, где числа кажутся очень случайными.

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

Следует отметить, что в случае, если микропрограмма имеет криптографическую подпись, по-прежнему невозможно установить обычную микропрограмму. С помощью подписи и открытого ключа ЭБУ может проверить достоверность данных и их достоверность.

Таким образом, определить, насколько безопасна система, можно оценить, рассчитав баллы RAV для каждой системы. Кроме того, можно рассчитать, как различные варианты и дополнения повлияют на этот показатель RAV.

После того, как баллы RAV рассчитаны и предложены контрмеры для ограничений и пористостей, эти результаты будут обсуждаться.

Благодаря тому, что RAV является скалярной метрикой, можно легко сравнивать различные системы и конфигурации. В Таблице 1 описаны различные системы. Таблица 2 показывает влияние отдельных изменений конфигурации существующего стека Vector. Он хранится отдельно из-за простоты просмотра и сравнения эффектов конфигурации. Коды, используемые для представления операций, элементов управления и ограничений в этих таблицах, можно найти в таблицах 3, 4 и 5 соответственно.

Таблица 1 – Сравнение уровней безопасности различных стеков и конфигураций

 

Таблица 2 – Сравнение уровней безопасности различных стеков и конфигураций

 

Таблица 3 – Отображение операций на коды

 

Таблица 4 – Карта управления кодами

 

Таблица 5 – Отображение ограничений на коды

 

Контрмеры пористости и ограничения перечислены в Таблице 6. Некоторые из них более подробно обсуждаются в главе 3. Все контрмеры можно сгруппировать по следующим трем категориям:

1. Использование существующих параметров конфигурации (например, статических таблиц ARP и отключенных эхо-ответов ICMP)
2. Дальнейшее развитие реализации стека и добавление функций, таких как шифрование и подписи с кэшами, для всех коммуникаций.
3. Изменение существующей реализации стека, чтобы она не соответствовала спецификациям протокола для большей пользы. Примером здесь является отправка помеченных RST TCP-пакетов, когда помеченные SYN-пакеты принимаются на закрытых TCP-портах. Это не будет иметь больших последствий для функциональности системы, но устранит одно воздействие.

Таблица 6 – Контрмеры

 

Обобщая вышесказанное можно сделать вывод, что фактическая безопасность может быть увеличена на 1,5 RAV, просто изменив конфигурации существующей реализации стека без дальнейшей разработки. При дальнейшем развитии возможно увеличение на 8 RAV. Есть две вещи, которые нужно иметь в виду:

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

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

---

1  2  3