Разработка → Расследование утечек информации из корпоративной базы данных перевозчика

bogatrev 13 сентября в 10:27 13,2k
К нам обратился крупный российский перевозчик, владеющий внушительным автопарком. Его клиентами являются десятки логистических компаний и предприятий. Зона его деятельности простирается далеко за пределы стран СНГ. Каждый автомобиль оснащен системой мониторинга, оправляющей в диспетчерский центр данные о координатах, расходе топлива и множестве других показателей.

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



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

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



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

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

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

Ознакомившись со структурой базы, мы поняли, что информация о координатах того или иного транспортного средства может быть получена либо из таблицы базы, либо из представления (View). Мы выбрали один из грузовиков компании, который находился в рейсе, попросили администраторов базы данных диспетчерского центра включить трассировку обращений к таблице и представлениях, содержащих данные о координатах грузовика. В течение трех последующих часов мы сделали 10 запросов на мошенническом сайте и по каждому запросу получили GPS-координаты. Данные по каждому запросу к нам приходили с задержкой не более секунды. За эти три часа набралось около 70 мегабайт текстовых журналов. Анализировать их мы отправились в свой офис, где были подходящие инструменты, оставив в покое администраторов базы.

В ходе анализа мы поняли, что данные в ответ на наши запросы приходят в режиме онлайн, и версии об утечках из резервных копий, или об обработке запросов в ручном режиме были отметены. Мы надеялись, что в течение секунды после нашего запроса в трассировке появятся данные о внешнем клиенте, который «сливает» информацию. Результаты анализа были неутешительными — в трассировке, сделанной стандартными средствами СУБД, была информация по обращениям к таблице и представлениям, но отсутствовала информация о конкретных запросах к данным по нашему грузовику. Оказалось, что в секунду обращений к таблице и представлениям более двух сотен, и выделить среди них обращения, сделанные в ответ на наши запросы, не представляется возможным.

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

Хорошо, что такой инструмент нам удалось быстро найти и договориться о его временном использовании. Данное решение (InfoSphere Guardium) может анализировать запросы от хранимых процедур с помощью программного агента непосредственно на сервере БД. Проводя анализ запросов «на лету», система позволяет получить все необходимые нам данные. После ночных работ по установке и настройке, мы снова провели серию из 10 запросов данных по нашему грузовику на «левом» ресурсе. В этот раз, благодаря встроенным методам фильтрации нашей аналитической системы, мы получили список из 12 аккаунтов, к которым «улетали» данные по координатам нашего грузовика в течение секунды после каждого нашего запроса. За любым из таких аккаунтов стоит АСУ одного из клиентов перевозчика. Встала задача определить, какая конкретно АСУ клиента передает данные на сторону, для чего мы воспользовались методом установки индивидуальных «меток».

Совместно с администраторами БД мы немного модифицировали те хранимые процедуры, с использованием которых выявленные нами 12 аккаунтов забирают данные из базы. Модификация преследовала одну цель — в зависимости от аккаунта вносить индивидуальные корректировки в координаты грузовика. Для каждой из 12 АСУ были сформированы индивидуальные координаты, отличающиеся двумя последними цифрами, все отправленные нами значения тщательно сохранялись в специальном журнале. Получив «помеченные» координаты с криминального сайта, мы, обратившись к журналу выдачи меток, смогли выявить ту АСУ, которая сливает данные.

Теперь настал довольно деликатный момент — для дальнейшего расследования нужны были данные с АСУ клиента. Это означало, что клиент должен быть хотя бы частично посвящен в суть дела. Более того, если данные сливает администратор этой АСУ, он может успеть замести все следы. Необходимо было действовать очень осторожно. Обстоятельства сложились удачно, т.к. была достигнута договоренность о взаимодействии на уровне служб безопасности перевозчика и этого клиента — крупного логистического оператора. Служба безопасности клиента согласилась предоставить нам журналы сервера АСУ. Анализ журналов дал нам единственный аккаунт, получавший данные с метками. Аккаунт принадлежал одному из сотрудников логистической компании. Что было с ним дальше история умалчивает. Главное, что цель была достигнута — продажа украденных данных остановилась.
Проголосовать:
+32
Сохранить: