уязвимость

Предыстория

Возьмём приложение «Проверка чека» и разберемся что оно делает и зачем ваще кому-то понадобилось проверять чеки с помощью приложения.

Суть приложения «Проверка чеков»

Я не помню как это работало раньше, но с 2016-2017 годов, благодаря 54-ФЗ «О применении ККТ» появились некие ОФД с целью «...осуществления операций по приёму, обработке, хранению и передаче фискальных данных в ФНС», а всех кого только можно обязали использовать кассовое оборудование, генерирующее те самые фискальные данные и что немаловажно, обязали эти данные посредством ОФД передавать в ФНС.

Если у вас тоже немного припекает от всех этих аббревиатур, то вот вам терминальная стадия аббревиатуринга в лице названия организации которая отвечает за приложение «Проверка чека» — ФГУП ГНИИВЦ ФНС РФ.

К этому моменту — мы еще вернёмся, кстати.

Страница приложения «Проверка чеков» в App Store

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

После заказа вы получаете на почту электронный чек, это и есть те самые фискальные данные. Отправляет их в ваш адрес, однако, не сервис заказа еды, а именно ОФД, которое используется сервисом, в данном случае — Яндекс

Любой подобный чек всегда содержит несколько обязательных идентификаторов в натуральном виде и в виде QR-кода, который можно отсканировать с помощью исследуемого нами приложения «Проверка чека».

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

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

Всё изменилось две недели назад после обновления 2.15.0 в рамках которого был выкачен функционал «отображение чеков из сервиса Мои Чеки Онлайн».

История версий приложения «Проверка чека»Обновление 2.15.0

Если пройти аутентификацию в приложении «Проверка чека» указав номер телефона, который вы так же используете в популярных сервисах, например, в Яндекс.Еде, Яндекс.Такси, Самокате, Ситимобиле и других, то в разделе «Мои чеки» автомагически будут отображены все ваши чеки по всем операциям в этих сервисах за «всё время».

В моём случае, это порядка 400 чеков, каждый из которых содержит детальный набор «сколько, за что, когда и куда».

Мне сразу же стало интересно насколько хорошо подобный массив данных защищен и может ли предполагаемый злоумышленник получить несанкционированный доступ к нему.

Для исследования я поставил в разрыв между интернетом и приложением «Проверка чека» простой прокси и записывая сетевую активность приложения потыкал в кнопки.

Довольно быстро выяснилось, что эндпойнт с данными находится по адресу irkkt-mobile.nalog.ru:8888 на котором живёт простейшее приложение на NodeJS с применением фреймворка Express, а механизм аутентификации пользователя пускает тебя к данным, если ты верно указал заголовок «sessionId» значение которого представляет из себя какой-то самопальный токен генерирующийся на стороне сервера.

При этом, если нажать кнопку «Выйти» в приложении «Проверка чека», то как оказалось, инвалидации данного токена не происходит. Так же нет функционала просмотра всех своих сесссий и нет кнопки «Выйти на всех устройствах».

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

Крайне безответственно, но не фатально.

Sentry

В процессе просмотра «улова» на промежуточном прокси я обратил внимание, что в случае крэша приложения оно отправляет диагностические данные в Sentry располагающийся по адресу не связанному, ни с ФНС, ни с ФГУП ГНИИВЦ ФНС РФ, а на домен зарегистрированный на физическое лицо — sentry.studiotg.ru.

Страница входа в Sentry команды Studio TG

Рядом сразу же был обнаружен gitlab.studiotg.ru.

Страница входа в GitLab команды Studio TG

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

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

Публично доступный репозиторий ansible_conf/install_geo Содержимое архивов из репозитория ansible_conf/install_geo

Пояснение к скриншоту выше: папки содержащие подстроки «lkio», «lkip», «lkul» напрямую относятся к одноименным сервисам ФНС на домене nalog.ru.

— lkio.nalog.ru

— lkip.nalog.ru

— lkul.nalog.ru

Содержимое папки lkip-web-login, это — исходный код сервиса lkip2.nalog.ru

Для сверки, что обнаруженные исходники действительно относятся к сервисам ФНС, проведена простая проверка наличия на боевом веб-сервере файла uppod-styles.txt, который не мог там оказаться по случайному совпадению.

uppod-styles.txt на сайте lkip2.nalog.ru Содержимое файла .env судя по всему прямиком с боевых серверов В итоге

Фактический разработчик мобильного приложения «Проверка чека» некая studiotg.ru.

Вероятно есть нарушение соглашений об обработке персональных данных в силу передачи диагностических сведений со стороны ФГУП ГНИИВЦ ФНС РФ в адрес третьих лиц.

Данные ребята так же причастны к разработке сервисов lkip.nalog.ru, lkul.nalog.ru и lkio.nalog.ru.

По их вине исходный код данных сервисов находится в публичном доступе уже около года.

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

Как-то так.

Больше года назад хабравчанин keklick1337 опубликовал свой единственный пост «Самый беззащитный — это Сапсан» в котором рассказывает как он без серьёзных ухищрений получил доступ ко внутренней сети РЖД через WiFi Сапсана.

В ОАО «РЖД» прокомментировали результаты этого расследования. «Есть результаты проверки. Почему удалось взломать? Наверное, потому, что злоумышленник. Наверное, из-за этого… Ну, он из „фана“. Юный натуралист. Там уязвимостей, которые бы влияли на утечку каких-то критических данных, нет. Мультимедийный портал „Сапсанов“ функционирует как положено и не нуждается в доработке», — заявил Евгений Чаркин.
То есть вместо того, чтобы выразить благодарность за обнаруженную уязвимость, автора обозвали «злоумышленником» и «Юным натуралистом».

К сожалению, но специалисты РЖД, начиная с директора по информационным технологиям, отнеслись к статье очень пренебрежительно, проигнорировав важное указание автора:
Также оттуда в сеть РЖД есть впн. Если захотите — найдёте её там сами.
И вот, год спустя я попал в сеть РЖД даже не садясь в Сапсан.


Видимо, только этот котэ добросовестно охраняет вокзал.

Как именно я попал в сеть РЖД с пруфами, чего не сделал директор по информационным технологиям ОАО «РЖД» Чаркин Евгений Игоревич и возможные последствия — под катом.

Всё началось с гипотезы

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

Таким образом меня посетила идея проверить гипотезу: «Есть ли жизнь за прокси»?

Я запустил nmap по диапазону адресов по порту 8080. Далее из полученного результата прошёлся прокси-чеккером в поисках публичного прокси без авторизации и из положительных результатов выбрал самый близкий ко мне по пингу.

Запустил сканер через него по адресам 172.16.0.0/12 порт 8291 (mikrotik winbox). И! Я его нашёл! Без пароля!



То есть за роутером с прокси есть ещё один — Mikrotik без пароля. Гипотеза подтверждена: за прокси могут быть целые незащищённые сети.

Только на тот момент я недооценивал масштаб «незащищённости», который я случайно нашёл.

В поисках Немо владельца системы

Так как я придерживаюсь принципов Grey hat (Обо мне mysterious Russian-speaking grey-hat hacker Alexey и статья на Хабре) и «съел собаку» на безопасности Mikrotik, то я принялся искать владельца системы, чтобы связаться с ним.

Кстати, заходите в Телеграм чат «RouterOS Security» t.me/router_os

Недолго думая я поднял исходящий VPN до себя. Всё же комфортней через нормальный туннель дальше изучать сеть и искать признаки владельца системы. HTTP connect — ещё тот геморрой…

За интерфейсами ether1 и bridge ничего интересного не обнаружил. Найденные камеры были абсолютно не информативными.



А вот сканирование vpn, отмеченные красным на скрине выше, выдало более 20 000 устройств…
Причём более 1000 штук — микротики. Огромное количество устройств с заводскими паролями.

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

1. Камеры наружного наблюдения — подавляющее большинство.




Даже офисы внутри



Камер, по скромным ощущениям, не менее 10 000 штук. Производители разные: beward, axis, panasonic и т.д.

2. Ip-телефоны и FreePBX сервера также большое количество.




3. IPMI серверов:


Много узлов кластера Proxmox (по поднятым сервисам и трафиком между ними.)


6. Внутренние сервисы







Различные системы управления табло на перронах :-)


Некий терминал, но внутри модифицированный дебиан.


Кстати, аптайм у него почти год:




6. Сетевое оборудование



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

Туннели наружу подымаются легко. То есть фильтрации исходящих коннектов практически нет.
Более того огромное количество микротиков со включенным прокси, аналогично тому, при помощи которого я и попал в эту сеть… Кстати, туннели через них тоже замечательно подымаются.

Не полный кусок лога по прокси.



Такое ощущение, что интегратор, который строил сеть, специально оставил этот доступ.

И все же кто же хозяин?

Думаю, что уже все и так догадались.

Это я пробежался по верхушкам в рандомном порядке. Потратил я на это чуть больше 20 минут, чем автор статьи про Сапсан.

Это здец. Сеть просто в решето.

Причём это устройства по всей РФ.


Развёрнута профессиональная система видеонаблюдения.

Нашёл презентацию по вокзалам.


Находил Кемерово, Новосибирск, Омск и т.д. По внешнему виду вокзалы сложно определить. К тому же я поездом уже лет 5 не ездил.

Как же так получилось?

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



То есть это один из шлюзов в мир из сети РЖД. Ну и в сеть РЖД тоже…

Получилась вот такая картина:

Вероятно, что это один из офисов РЖД, который прилинкован к основой сети через l2tp. Я попадаю в сеть где межсетевые экраны отсутствуют как класс. Запускаю интенсивное сканирование хостов — у меня соединение не рвётся. Значит о системах обнаружения вторжения (IDS/IPS) РЖД тоже ничего не слышал. Микротик может замечательно интегрироваться, например Обнаружил кучу устройств без защиты. Это говорит, что службы сетевой безопасности в РЖД так же нет.Много устройств с дефолтными паролями. То есть политики паролей тоже нет.С Микротиков внутри сети я легко поднял туннели. То есть исходящий трафик не контролируется. Я вижу все интерфейсы управления в одной сети с клиентскими сервисами. Админы РЖД ничего не знают о Management VLAN
«Российские железные дороги» провели проверку после взлома мультимедийной системы поезда «Сапсан» одним из пассажиров, критических уязвимостей не обнаружено.
Так дайте ответ, Евгений Игоревич, какой «Юный натуралист» проводил расследование и не заметил гнездо со слонами?



У меня лично есть всего три варианта ответа на этот вопрос:

1. У Вас исходно плохая команда.

Проверку проводил тот же отдел, который и проектировал/обслуживает систему. Отрицая проблему, они или сохраняют свою работу, или преследуют иные цели.



2. Вы доверились не тому специалисту. Аудит проводил некомпетентный сотрудник.



3. Вы и так знаете о проблеме, но по каким-то неведомым причинам не можете ее публично признать и решить.

Стоимость уязвимости

«Что есть защищенная система? Защищенная система — это та система, взлом которой стоит дороже, чем ценность информации, которая там есть. Вот и все», — подытожил директор по информационным технологиям ОАО «РЖД».
Предлагаю применить Вашу систему оценки в теории на примере системы видеонаблюдения РЖД.

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

Рандомно выбранная из списка установленных модель стоит ~13к рублей.



А закупки по 44-ФЗ отличаются, как непредсказуемой конечной стоимостью, так и временем проведения самой процедуры и получения продукта. Я потратил 8 часов для сбора информации для этой статьи. Найдено ~10к камер. Производителей камер, которые установлены, немного — максимум штук 10.

Гипотетическому злоумышленнику потребуется:

Модифицировать прошивки, заблокировав сетевой порт на 10 прошивках. Думаю, что на это у специалиста уйдёт три рабочих дня;Написать сканер, который будет анализировать устройство и заливать соответствующую прошивку. Заложим ещё 2 дня;Запустить этот сканер-прошивальщик, чтобы не смогли найти источник и заблокировать — часа два.
Таким образом за неделю работы специалиста по взлому РЖД потеряет минимум 130 миллионов рублей. Отсюда стоимость одного часа работы злоумышленника будет равна ~2,5 млн. рублей.

Двигаемся дальше.

Быстро заменить камеры на работающие РЖД не сможет. В резерве столько нет. Купить новые из-за обязанности объявления торгов так же не получится. Таким образом вся железная дорога будет без видеонаблюдения не меньше месяца.

А вот это уже опасность террористической угрозы. Чтобы её хоть как-то снизить потребуется на 10 тысячах объектов существенно усилить охрану. То есть даже на маленькую ж.д. станцию потребуется дополнительно 6 человек охраны…

Кажется счёт уже уходит за миллиарды…

Что нужно изменить, чтобы снизить вероятность возможных последствий?
Далее чисто мой взгляд на решение данной ситуации. Он ничего общего не имеет с мировыми best practices.

Так же, сразу оговорюсь, что проблема касается только обнаруженной мною сети видеонаблюдения. В других сегментах сети РЖД, очень надеюсь, всё намного лучше.

1. Нанять сетевых аудиторов, которые помогут найти и закрыть самые «зияющие» дыры.

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

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

2.2. разработать новую полноценную инфраструктуру, отвечающую всем требованиям безопасности и план поэтапной миграции.

3. Нанять подрядчика, который будет реализовывать в жизни данные проекты и передавать на эксплуатацию сетевикам РЖД.

4. После сдачи проектов провести аудит безопасности инфраструктуры.

5. По окончанию пентестов своими силами объявить Bug Bounty

Чтобы мотивировать аудиторов и внутренних специалистов работать качественно, надо объявить лимит на количество и серьёзность уязвимостей, которые могу найти участники программы Bug Bounty. Если внешние специалисты найдут багов меньше лимита, то свои аудиторы получают премии. Если багов будет больше лимита, то штрафовать.

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

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

Заключение
Я не единственный кто нашёл данные уязвимости. Очень много признаков, что в этой сети кто-то «живёт».

Например, вот эти линки я уже встречал не раз на роутерах, никак не относящихся к РЖД.



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

В случае с Сапасаном, чтобы через полученный VPN доступ можно было увидеть только один сервис — с которым взаимодействует пользователь системы, а не всю сеть РЖД…

Я старался достаточно жирно намекнуть на узкие места не раскрывая деталей и надеюсь, что специалисты РЖД их всё же увидят.

Связаться со мной можно через телеграм t.me/monoceros
Обсудить данную статью приглашаю в профильный чат по Микротикам в Телеграм «RouterOS Security»: t.me/router_os

Кстати, Евгений Игоревич, с повышением!



Источник