Утечки

Искать утечки и уязвимости в своих продуктах не только интересно и полезно, но и необходимо. Еще полезнее подключать к таким поискам внешних специалистов и энтузиастов, у которых не настолько замылен глаз, как у сотрудников. Поэтому в свое время мы в QIWI запустили программу bug bounty исследователи писали нам об уязвимостях и получали вознаграждение, а мы закрывали эти уязвимости.

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

• разработчик писал тестовый пример кода для себя, используя конфигурации боевого сервиса не тестовую среду;

• админ выкладывал скрипты автоматизации и миграции базы данных потенциально чувствительной информации;

• стажер неосознанно размещал код в своем публичном репозитории, считая, что это не несет рисков.

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

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

И в целом безопасность компаний не абсолютна: хорошо защищая свой периметр и информационные системы с помощью с помощью Firewall, SOC, IDS/IPS и сканеров безопасности, компании все равно подвержены многим источникам утечек от внешней разработки и аудиторов до вендорских решений. Конечно, невозможно отвечать за безопасность других компаний, но мониторить случаи утечки вашей информации с их стороны можно и нужно.

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

Так появился QIWI Leak-Search сервис, который ищет утечки вашего кода на Github и не только.

Как мы его делали и что он умеет читайте в посте.

Предыстория

Сначала мы пошли в рынок и посмотрели, как там дела с такими продуктами: вдруг можно купить что-то работающее, проблема-то, прямо скажем, не только у нас такая. Рынок уверенного ответа не дал, и мы поняли надо делать самим.

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

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

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

Вот несколько примеров, которые мы нашли с помощью Leak-Search. Крупная российская компания из сферы ритейла дает доступ к ERP-системам для управления деталями заказов кто хотел бы бесплатно перенаправлять себе чужие заказы на технику и одежду? Один из международных ИТ-гигантов предоставляет исходники операционной системы для IoT-устройств почему бы не поискать уязвимости, обладая максимальными правами доступа? Неназванное западное управление по исследованию космоса без проблем открывает информацию о потенциально опасных астероидах отличная возможность получить доказательства для создателей пугающего контента. Детали и названия этих компаний по понятным причинам мы не разглашаем.

Что и как ищет QIWI Leak-Search

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

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

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

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

Поэтому в Leak-Search мы ищем все, что может относиться к чувствительным данным. Например:

набор определенных ключевых слов smtp, Dockerfile, proxypass, Authorization;

названия пакетов com.qiwi.processing.common;

адреса серверов int.qiwi.com, 10.4.3.255;

названия переменных, характерных именно для внутренней разработки компании QIWISECRET_KEY, qiwiToken.

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

Особенности поиска системы

Репозиториев существует великое множество. А еще много как просто похожих репозиториев, так и форков. У нас тоже много вещей отдано в Open Source: мы поддерживаем это движение и рады делиться с ИТ-сообществом ценными наработками. Пользователи из наших исходных кодов уже успели сделать больше сотни разных форков.

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

Масла в огонь подольет еще и StackOverflow один разработчик придет на портал с вопросом, разместив часть кода, которую он не понял. Второй ответит в комментариях и даст другой отрывок кода в качестве ответа. Третий через пару месяцев найдет эту ветку обсуждения, потому что тоже не понял код, и заберет пример из комментария к себе на Github. И скорее всего, найдет ветку и возьмет код не он один.

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

Что можно найти таким методом сравнения, если очистить и кластеризовать поиск? Если вы ищете следы возможной уязвимости, вы найдете репозитории, в которых она была переиспользована. То же случится, если вы захотите посмотреть, где именно используют ваши идеи.

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

Разработка и поддержка

Возможно, вы замечали, что после достаточно активного использования open source, в таких сервисах, как Github, система безопасности сервиса могла вас заблокировать за превышение лимитов запросов. Поэтому нам пришлось постараться, чтобы Leak-Search имитировал человеческий поиск.

При этом мы активно добавляем публичные платформы для хранения исходных кодов в список источников, по которым осуществляется поиск. Начали мы с Github но теперь Leak-Search ищет утечки уже и в Gist. В бета-тесте у нас Pastebin и Gitlab, и еще планируем добавить BitBucket. А под каждый источник мы учитываем его специфику поиска и работы с API.

В рамках алгоритма, конечно, бывают и ложные срабатывания как false positive, так и false negative. Пока мы решаем это добавлением новых правил для фильтров, чтобы те работали все точнее.

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

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

Этическая сторона вопроса

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

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

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

Если вам интересно что-то еще, о чем мы не упомянули в посте, спрашивайте, ответим.

Предыстория

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

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

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

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

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

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

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

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

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

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

Обновление 2.15.0

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

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

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

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

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

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

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

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

Sentry

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

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

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

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

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

lkio.nalog.ru

lkip.nalog.ru

lkul.nalog.ru

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

В итоге

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

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

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

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

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