Безопасность как искусство
92,45
рейтинг
11 декабря 2013 в 16:25

Разработка → Где моя повозка, сударь? Безопасность GPS-трекинга

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



Что такое GPS-трекер?

GPS-трекер — достаточно компактное устройство, позволяющее с большой точностью определить текущее местоположение объекта, к которому оно прикреплено, например автомобиля.
Под GPS-трекерами будем в том числе понимать устройства, работающие с родным для нас Глонассом.

Где применяется

Данный вид устройств имеет широчайшее распространение в нашей жизни и используется широкими слоями населения: родители, желающие знать, где в данный момент находится их озорник-ребенок; славные полиционеры, контролирующие, не покинул ли пределы города освобожденный под подписку о невыезде за воровство картошки дед Василий; «креативный класс», ожидающий подачи ближайшего к нему такси; суровые работники служб безопасности, контролирующие передвижение грузов, инкассаторских автомобилей и просто фур и желающие знать, не сливают ли втихаря водители этих самых фур топливо, не халтурят ли по вечерам и не превышают ли скоростной режим. В общем, везде, где есть необходимость узнать текущее положение объекта и ряд его свойств, мы, несомненно, наткнемся на GPS-трекер.



Как работает

В работе GPS-трекера нет никакого волшебства. Устройство представляет собой плату с GPS/Глонасс-модулем, а также модулем GSM. Первый используется для получения текущих координат объекта, последний для их отправки на удаленный сервер с помощью GPRS, например. С сервера эти данные получается оператором уже в приятном интерфейсе Web 2.0 с рюшечками и треком объекта на карте.

В итоге мы имеем вот такую схему работы устройства:


Заканчиваем с нудятиной, переходим к атакам

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

Без внимания у нас остались ПО самой железяки и серверная часть, вот туда-то и глянем.
Начнем с последнего.
В сети существует множество ресурсов, готовых продать вам как сам трекер, так и предоставить сервер, чтобы агрегировать данные с трекера. Все, что требуется конечному пользователю — это установить трекер и сконфигурировать его на отправку данных на какой-то определенный сервер, например на бесплатный gps-trace.com/?page=home
Конечно, этим вариантом пользуются, как правило, частные лица. Большие организации, например логистические предприятия, разворачивают нечто подобное на своих серверах.

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

Тут и разглашение информации:


и межсайтовый скриптинг:


и SQL инъекции:


А еще все это работает на серверах с кучей открытых портов. Простор для атакующего.

Уже на этом этапе атакующий получит все, что ему нужно: трек, параметры объекта (например, скорость, открыты ли двери, количество бензина), текущее местоположение, информацию о трекере (номер SIM-карты, IMEI, производитель).
Однако мы не будем останавливаться на достигнутом, ведь наша цель — не только посмотреть, где находиться чей-то ребенок, но и попробовать сделать так, чтобы этот ребенок «оказался» вдруг на курортах Сомалийского края, например. А для этого нам нужно подделать данные, передаваемые от трекера на сервер, т. е. быть посередине.

Для этого посмотрим в сторону самого трекера. Как же он конфигурируется? Разработчики современных трекеров предлагают огромное количество способов сконфигурировать трекер.
А именно:

1) RS-232
2) SMS
3) GPRS
Вообще, еще можно позвонить на трекер и, если к нему был заранее подключен микрофон, услышать нервные вздохи какого-нибудь дальнобойщика.
Для удаленной конфигурации используются последние два способа: СМС и GPRS.
Итак, поговорим предметно, а именно о трекере Teltonika FM-4200. Трекеры данной фирмы очень распространены, потому и были выбраны для исследования.



Для того чтобы отправить SMS на трекер, необходимо знать его номер телефона. Где же его взять? Эта задача может решаться множеством способов. Например, можно использовать уязвимые серверные приложения, о которых было рассказано выше, или погуглить конфиги/логи трекеров. Люди любят выкладывать их на форумах, обсуждая проблемы устройств.

Итак, формат конфигурационной СМС для Teltonika выглядит следующим образом:

setparam <номер параметра> <значение>

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



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

В Teltonika за IP-адрес сервера отвечает параметр 3245, а за номер порта - параметр 3246. Таким образом, для того чтобы пустить весь трафик трекера через свой сниффер, нам достаточно отправить всего 2 SMS следующего содержания:

<пробел><пробел>setparam 3245 <пробел><пробел>setparam 3246

Просто слушать трафик неинтересно, хочется его еще и модифицировать, а для этого необходимо знать протокол, по которому Teltonika общается с сервером. Где бы его взять? Google it!
Например, по запросу "Teltonika Confidential document":

Среди множество ссылок на интересные pdf-ки мы наткнемся на документ под названием "FM4XXX DATA PROTOCOL", в котором подробно описан формат отправляемых трекером пакетов.
Не буду его описывать, он достаточно прост.
Сообщения выглядят примерно таким образом:

00000000000000b708060000013aff36d4170а120cc98023c1c400000200000800000000000000000000013aff36857f00120cс1а023c1c200000000000900010000000000000000013aff36372200120cc56023c1c180000000000900010000000000000000013aff35e88a00d20cc6e023c1c240000100000900010000000000000000013aff3599f400120cc8e023c1c400000500000900000000000000000000013aff354b5a00120cc8c023c1c500000f0000090000000000000000060000570e


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

Имея описание протокола, мы быстро пишем утилиту, которая будет парсить сообщения, изменять их, например увеличивая скорость, и отправлять дальше.
Код такой утилиты можно увидеть вот тут: pastebin.com/VfWLnGPA

Утилита может рандомизировать скорость объекта в заданных пределах, а также менять значения координат.

Вот пример того, как мы заставили автомобиль двигаться со скоростью ~600 км/ч по траектории, очень напоминающей пентаграмму.



Кроме этого, в утилите реализован простенький фаззер.

На этом этапе уже можно было бы остановиться, однако наличие в мире устройств, к которым мы не можем получить доступ из-за ограничения паролем, как-то расстраивает.
Попробуем что-нибудь придумать. Мы совсем забыли о том, что у каждого устройства есть прошивка, трекеры не исключение. А как владелец трекера может поменять прошивку на своем трекере, если он установлен в недрах камаза где-нибудь в Сибири? Правильно! По СМС.

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

Для Телтоники такая СМС-команда выглядит следующим образом:

BOOT <ip:port>

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

Вот тут-то у нас и возникли трудности. Доступные прошивки для нашего устройства зашифрованы. Было принято решение сдампить код прошивки через JTag (что это такое, можно прочитать вот тут: habrahabr.ru/post/190012)
И подпитываемые надеждой, что разработчики не озаботились безопасностью своего продукта и тут, мы запаслись китайским программатором, поддерживающим наш чип и приступили к дальнейшим изысканиям.
Но куда и как подключаться для получения заветного доступа к микроконтроллеру? Взглянув на плату трекера, можно заметить несколько потенциально интересных для нас мест, мест куда теоретически мог бы быть разведен искомый интерфейс.


Прозвонить путь от контактных площадок до выводов, значащихся в даташитах на контроллер как JTag, не представлялось возможным из-за форм-фактора процессора. Более всего заинтересовал необычный двухсторонний разъем на краю платы, очевидно, созданный для подключения неким сервисным кабелем, распиновка которого - негуглящаяся тайна. И было решено следовать методом грубой силы: пробрутфорсить все доступные контактные группы для определения распиновки. Для этого мы подпаялись к контактным группам и использовали arduino-подобную плату teensy для перебора возможных комбинаций TDI, TDO, TCK и TMS. В этом помогли наработки известного арт-хакера Nathan Andrew Fain, а именно проект Jtagenum.


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

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

Как вы могли заметить, ресеч не закончен, так что если кто-то любит копаться во внутренностях железяк, то велком в Digital Security, у нас весело.

PS: Помимо меня с трекерами веселился JRun, за что ему большое спасибо.
Автор: @chipik
Digital Security
рейтинг 92,45
Безопасность как искусство

Комментарии (32)

  • +24
    Хабр торт
  • +1
    Дух захватывает!

    Делая подобную штуку, тоже хотел защититься от перехвата и изменения пакетов данных. Но судя по тому, что прошивку можно слить и реверснуть алгоритм «шифрования», то выход похоже только один — индивидуальные ключи каждому устройству.
    • –2
      Выход есть и попроще: Open Source, где силами сообщества и заинтересованных компаний фиксятся уязвимости.
      • +1
        Почему если ОпенСорс, то значит безопасней продукт? Просто другая модель разработки…
        • +2
          Вопрос в том кому вы больше доверяете: мутной конторе с ужасным кодом или открытой разработке, где спокойно можете адаптировать под себя все что угодно? Нужна аутентификация — добавил, нужно асинхронное шифрование — кто мешает?

          Проблему вижу в другом — дебильная сертификация ПО со сложной криптографией! Методика прохождение сертификации взята словно из позапрошлого века. На каждую версию не важно с какими изменениями необходимо проходить повторную сертификацию ПО. В итоге о каком своевременном обновление и фиксе уязвимостейможет идти речь?
          • 0
            Вообще не ответили на мой вопрос. Почему код и архитектура ОпенСорсных приложение безопасней? Ваш ответ: Потому что там НЕТ аутентификации и шифрование, и я могу это привинтить сам (разумеется без ошибок и багов, я то знаю как это делать, а они все нет!) Это не ответ на мой вопрос)

            Сертификация чего? СКЗИ в РФ? Или чего — модуля ПО для PA DSS?
            • +1
              Вроде бы самоочевидные вещи: OpenSource безопаснее за счет того, что всегда можно посмотреть исходный код и повлиять на ход разработки: можно либо форкнуть, либо отправить коммиты. В случае закрытой разработки нет рычагов влияния и примерами завалено полхабра, где различные компании по полгода и более закрывают критические уязвимости в своих продуктах. Программы по баг хантингу не панацея — тут напрямую зависит от того кто и как из сотрудников компаний курирует это программу.
              • 0
                Ну что программы по баг-хантингу не панацея, я согласен с Вами полностью.
                По поводу пол-года — ну ведь эти сроки связанны с QA, множество веток продукта, которые ВСЕ надо проверить и сделать фикс — на это нужно время. Я Вас понимаю, тот факт что исходные код можно «просмотреть» — это бонус. Но никто не делает доскональный аудит системы в любом случае и те же уязвимости появляются с ТАКОЙ ЖЕ регулярностью, как и в не-опенсорсном продукте софте. Ваша вера — этого еще не достаточная причина, для таких утверждений.

                Пример 1. ОпенСорсный Struts2 фиксил критичную багу с удаленным выполнением кода 2.5 месяца после репорта в _паблике_ (Пруф линк -http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote.html)

                По этому примеру — Стратсу (только который недавно был, этим летом) хочу напомнить, что например после выхода в паблик инфы о сплойте, Китайцам понадобился 1 день, что бы состряпать бота и запустить по инетам, и уже через пару дней developers.apple.com был похекан. Лично МНЕ, тот факт, что Стратс2 это опен-сорсная тема, НЕ ПОМОГ, мне легче было зафильтровтаь патерн URL запроса в конфигах или настроить мод_сек, чем фиксить КОД жуткого Стратса на продакшене.

                Пример 2 MySQL remote Heap Overflow — фиксили 1 год полсе репорта (http://www.zerodayinitiative.com/advisories/ZDI-13-251/). Но тут реальность применимости сплойта довольно мала, поэтому понять лично могу.

                Пример 3 Firefox — почти 4 месяца на фикс. www.zerodayinitiative.com/advisories/ZDI-13-039/ (если в паблике бага просочилась, то тогда они фиксят 1 месяц.)

                И что нам говорят все эти примеры? А вывода три:

                1) Скорость фикса зависит от вендора, как в случае опен-сорца, так и в любом другом случае, а время базируется на критичности баги (реальной, а не той, что пишут в адвайзорах ресерчеры), публичности информации об этой проблеме (см Мозиллу) и оценке рисков в целом, кроме того большая доля делая зависит и от размера проекта (сколько веток, сколько кода), сложности патча (архитектурные проблемы будут фиксить от «долго» до «никогда»).
                2) Когда начнет клевать петух, НИКТО не будет фиксить код САМ на продакшн серверах — есть методы вирутал-патчинга, фильтрации трафика, отключения уязвимого функционала — как воркэраунд солюшн. Затем все будут ждать патча от вендора. Если есть умные ребята из опен-сорца, они пишут патч и шлют его куда надо, там его тестят… и… те же 3 месяца и выходят.
                3) Базируясь на выводах 1 и 2 получаем финальный вывод — разницы нет.
                • 0
                  Но если разницы нет, то зачем платить больше?
                  • 0
                    У каждого свои причины. Кто-то платит за поддержку и «все-включено», например… кто-то за качество, удобство и/или функционал =) Зависит от цели и задач.
                    • 0
                      Я не говорю. что у Open Source нет проблем, просто эта идеология более понятна и близка.
          • 0
            Производство фирмвари куда более другой процесс, нежели просто софт. Например, смена разводки платы после того как нашли более энергоэффективный (стабильный/температурнонадежный/фичастый или ещё какой) компонент. Это влечет за собой смену прошивки (банально на уровне дефайнов переопределяются пины). Это происходит нечасто, но раз в год точно бывает. Или появление новых элементов на плате (ADC, CAN, ...) тоже влечет за собой смену прошивки и она должна знать об этом. Ещё ряд моментов:
            — на плате не всегда распаяны все компоненты, ибо не всегда нужны — существуют разные версии девайсов по разной цене для разных целей. Например, есть версия с голосовой связью и без неё.
            — иногда делаются кастомные версии платы (и/или распайка элементов) под конкретные большие заказы
            — иногда отзывается партия под замену и перепрошивку, т.к. нашли критический баг на плате или в прошивке

            Это только то, что я вспомнил навскидку. Вы представляете себе количество версий фирмвари, которые должны существовать и это кто всё будет форкать и поддерживать? А гарантийные обязательства (как производитель железа) как Вы собираетесь соблюдать, учитывая, что «глючить» девайс может начать как по результату отламывания ножки микрухи так и по форкнутой фирмвари? А имидж компании-производителя и прямые материальные затраты в виде падения спроса из-за глючащих по причине «форкнутой» прошивки кто будет компенсировать? Да и зачем эти риски вообще?

            Как Вы будете тестировать свой форк на других версиях платы?

            Клиенту (пользователю) неинтересно то, что внутри девайса, он покупает даже не девайс, а решение своей задачи — мониторинг. Циферки в отчетах. Он не будет форкать. Более того, у него нет своих программеров, которые будут сидеть и дописывать «асинхронное шифрование» (это кстати что такое? подозреваю что все таки «асиметричное»). Далеко не всегда у дилеров-то наших есть программеры, которые могут написать нужные отчеты, а вы говорите о настолько квалифицированной работе как написание фирмвари. Это значительно более сложная задача.
  • +2
    код утилиты ужасен.
    • +7
      Соглашусь.

      Увы, я не программист.
      • +1
        def lst_print(lst): ##print all packet
            all=[]
        


        >>> all <built-in function all>

            all.append(lst[0])
            all.append(lst[1])
            all.append(lst[2])
            all.append(lst[3])
        


        зачем так длинно, если можно

        all.extend( lst[:4] ) 
        


            for x in lst[4]:
                all.append(x[0])
                all.append(x[1])
                all.append(x[2])
                all.append(x[3])
                all.append(x[4])
                all.append(x[5])
                all.append(x[6])
                all.append(x[7])
        

        аналогично.

            for z in all:
                str=str+z
            return str
        

        можно просто

        return ''.join( all )
        

        это быстрее и короче.
        • +5
          Чипик не девелопер, причем ни разу). Он хакер. (с)
  • 0
    1) не во всех девайсах подобного рода есть возможность считать прошивку по JTag
    2) некоторые девайсы умеют SSL до сервера.
    3) и как правило защиту нескольких уровней как от изменения конфигурации так и для доступа к ней.
    • 0
      1) на это и наткнулись :(
      2) SSL хорошо, но опять же все зависит от конкретной реализации. От пассивного прослушивания он спасет, а с активным MiTM-ом уже возможны варианты.
      3) как правило она ограничивается белыми списками номеров, которые вполне могут обходиться СМС с подделкой номера
      • +1
        3) как правило, но далеко не всегда. Говоря про несколько уровней я имел ввиду пароли.
        • +2
          Не могли бы вы привести пример такого трекера, чтоб SSL, JTag прикрытый и несколько паролей. Попробуем глянуть.
          • +5
            Ну например наши :) АвтоГРАФ. Если напишете в личку город — скорее всего мы попросим нашего дилера в Вашем городе предоставить экземпляр.
            • +7
              Ох, ну и угораздило вас назвать свое изделие — по названию прибора найти официальный сайт удалось только попав сначала на страницу Экслера с обзором, где на фото трекера можно было рассмотреть название фирмы-производителя.

              При этом на странице описания (местами даже излишне богатой подробностями вроде «GSM 900/1800» в текстовой части, а не только в таблице характеристик) про SSL и защиту от слива прошивки ничего нет. Зачем скрывать конкурентные преимущества изделия и лишать покупателя возможности найти устройство поиском?
          • 0
            Да много девайсов, например Locarus. На самом деле, те что в России собирают и давно как правило такие огрехи не касаются, да и прошивка в них зашифрованная.
  • +7
    Жду не дождусь интернета вещей. Миллионы багованных, нешифрованных, глючных устройств вокруг нас. Раздолье и цубепунк.
  • 0
    А почему компании не поставить свой, внутренний сервер для сбора статистики, если число машин достаточно велико? Побезопаснее будет, как минимум.
    • 0
      Делают так. И Телтоника, в том числе, поставляет ПО для сервера.
    • 0
      Очень много производителей делает как железо, так и софт.
  • 0
    Очень интересно! Когда в ход идёт и хардварный хакинг — это всегда завораживает.
  • –2
    Сегодня же не первое апреля? Это не бумажная газета? Точно?

    Друзья, ну что за воды вы тут налили? Зачем уж так сгущать краски то? :)

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

    Отсутствие пароля по умолчанию или простой пароль — все это сделано для удобства пользователя, который с хитрой штукой с первого раза не справится почти наверняка. И ему еще и пароль надо вводить. Поэтому делают простой пароль, но в инструкции пишут — давайте, смените! и еще и жирным отмечают, наверняка. Фирме, производящие трекеры пофигу, какой пароль лить в него при конфигурировании при сборке, согласны?

    Теперь о железках. Ага. Видите, когда дело коснулось не чтения протоколов (думаю вам бы их выдали в компании, если бы вы попросили), которые, ищутся через google, а не крадутся с серверов компании :) у вас ничего не получилось. Потому-что биты защиты итд итп. Ну скачаете вы прошивку (забудет программер бит поставить — тогда — повезет), получите мегабайт ассемблера. Удачи с разбором и компиляцией.

    Друзья, ну какой биткоин майнер на таком железе? какой DDOS по GPRS?

    Тут же вокруг программисты, инженеры… Зачем такое тут писать? Это текст, что выше — для рекламного буклета, чтобы продавать свои услуги :)

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

    Ай-ай-ай. Нехорошо! в угол!

    p.s.
    Да-да. про фейковую базовую станцию — оценил :)) А че не написать, что можно было бы использовать инсайдеров средит директората сотовых компаниях, но че их беспокоить по ерунде, если и так все на поверхности лежит.
    • 0
      Да
  • 0
    .
  • 0
    Отвечая на финальный вопрос: какой вывод можно сделать из этой статьи?
    Вывод такой: «на каждую хитрую задницу найдется свой инструмент»

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка