Из единого центра информация о координатах груза расходится к заказчикам. Все работает в автоматизированном режиме. Для удобства контроля доставки, в стоимость услуг включен сервис по информированию клиентов о местонахождении их грузов.
Причиной обращения к нам стала деятельность нескольких интернет-ресурсов, которые продавали информацию о грузах перевозчика. Едва ли логистическая компания или другой клиент нашего перевозчика будет рад узнать, что данные о его грузах может приобрести кто угодно, в том числе и конкуренты.
С технической точки зрения информацию о своем грузе можно получить двумя путями.
Первый — на сайте перевозчика, второй, более сложный — подключив свою логистическую информационную систему (АСУ клиентов) непосредственно к базе перевозчика. Все запросы АСУ клиентов к базе данных (БД) перевозчика реализованы посредством набора Хранимых Процедур. Для управления доступом каждому клиенту выделяется его собственный аккаунт с набором необходимых ему полномочий и прав.
Специалисты перевозчика понимали, что кроме данных о местоположении груза, из их базы может утекать и другая информация. Кто и с какой целью их будет использовать неизвестно, но настораживает. Предположительно клиентами таких сайтов могут быть не только конкуренты, но и сами клиенты перевозчика, пожелавшие иметь альтернативный канал контроля. Также информация по грузовикам может быть интересна тем, кто сумел неофициально «пристроить» свой груз в кузове, например, договорившись с водителем. Налицо явная утечка информации, и нашей задачей было выяснить метод ее организации.
Для начала мы провели анализ информации, которую предоставляют эти продавцы краденого. Оказалось, что спектр их услуг достаточно широк. За вполне разумные деньги, которые может себе позволить даже частное лицо, можно получить информацию о местонахождении конкретного грузовика или груза в данный момент. Можно оформить подписку на отслеживание груза или транспортного средства, тогда вам на почту или по SMS будут приходить данные с той периодичностью, на которую вам хватит денег.
Для продолжения расследования мы выбрали метод «контрольной закупки». Мы зарегистрировались на одном из таких криминальных ресурсов и заплатили за несколько десятков запросов о координатах грузовика. Мы планировали при оформлении каждого запроса отслеживать источники обращений к центральной базе данных перевозчика.
Ознакомившись со структурой базы, мы поняли, что информация о координатах того или иного транспортного средства может быть получена либо из таблицы базы, либо из представления (View). Мы выбрали один из грузовиков компании, который находился в рейсе, попросили администраторов базы данных диспетчерского центра включить трассировку обращений к таблице и представлениях, содержащих данные о координатах грузовика. В течение трех последующих часов мы сделали 10 запросов на мошенническом сайте и по каждому запросу получили GPS-координаты. Данные по каждому запросу к нам приходили с задержкой не более секунды. За эти три часа набралось около 70 мегабайт текстовых журналов. Анализировать их мы отправились в свой офис, где были подходящие инструменты, оставив в покое администраторов базы.
В ходе анализа мы поняли, что данные в ответ на наши запросы приходят в режиме онлайн, и версии об утечках из резервных копий, или об обработке запросов в ручном режиме были отметены. Мы надеялись, что в течение секунды после нашего запроса в трассировке появятся данные о внешнем клиенте, который «сливает» информацию. Результаты анализа были неутешительными — в трассировке, сделанной стандартными средствами СУБД, была информация по обращениям к таблице и представлениям, но отсутствовала информация о конкретных запросах к данным по нашему грузовику. Оказалось, что в секунду обращений к таблице и представлениям более двух сотен, и выделить среди них обращения, сделанные в ответ на наши запросы, не представляется возможным.
Назрела необходимость в дополнительном инструментарии, который даст нам содержимое каждого конкретного обращения к таблице или представлению. Множество инструментов могут анализировать SQL-запросы и им подобные в трафике, но в нашем случае необходимо было ПО, которое не только сможет перехватывать запросы от хранимых процедур к базе на том же сервере, но и «разбирать» их содержимое.
Хорошо, что такой инструмент нам удалось быстро найти и договориться о его временном использовании. Данное решение (InfoSphere Guardium) может анализировать запросы от хранимых процедур с помощью программного агента непосредственно на сервере БД. Проводя анализ запросов «на лету», система позволяет получить все необходимые нам данные. После ночных работ по установке и настройке, мы снова провели серию из 10 запросов данных по нашему грузовику на «левом» ресурсе. В этот раз, благодаря встроенным методам фильтрации нашей аналитической системы, мы получили список из 12 аккаунтов, к которым «улетали» данные по координатам нашего грузовика в течение секунды после каждого нашего запроса. За любым из таких аккаунтов стоит АСУ одного из клиентов перевозчика. Встала задача определить, какая конкретно АСУ клиента передает данные на сторону, для чего мы воспользовались методом установки индивидуальных «меток».
Совместно с администраторами БД мы немного модифицировали те хранимые процедуры, с использованием которых выявленные нами 12 аккаунтов забирают данные из базы. Модификация преследовала одну цель — в зависимости от аккаунта вносить индивидуальные корректировки в координаты грузовика. Для каждой из 12 АСУ были сформированы индивидуальные координаты, отличающиеся двумя последними цифрами, все отправленные нами значения тщательно сохранялись в специальном журнале. Получив «помеченные» координаты с криминального сайта, мы, обратившись к журналу выдачи меток, смогли выявить ту АСУ, которая сливает данные.
Теперь настал довольно деликатный момент — для дальнейшего расследования нужны были данные с АСУ клиента. Это означало, что клиент должен быть хотя бы частично посвящен в суть дела. Более того, если данные сливает администратор этой АСУ, он может успеть замести все следы. Необходимо было действовать очень осторожно. Обстоятельства сложились удачно, т.к. была достигнута договоренность о взаимодействии на уровне служб безопасности перевозчика и этого клиента — крупного логистического оператора. Служба безопасности клиента согласилась предоставить нам журналы сервера АСУ. Анализ журналов дал нам единственный аккаунт, получавший данные с метками. Аккаунт принадлежал одному из сотрудников логистической компании. Что было с ним дальше история умалчивает. Главное, что цель была достигнута — продажа украденных данных остановилась.
Комментарии (44)
dimkss
13.09.2017 12:10+10В этот раз, благодаря встроенным методам фильтрации нашей аналитической системы, мы получили список из 12 аккаунтов, к которым «улетали» данные по координатам нашего грузовика в течение секунды после каждого нашего запроса. За любым из таких аккаунтов стоит АСУ одного из клиентов перевозчика.
АСУ каждого клиента имеет доступ ко всем-всем перевозкам?
bogatrev Автор
13.09.2017 13:13+1Конечно нет, просто структура базы такова, что координаты всех грузовиков пишутся в одну таблицу в течение дня и обращения всех АСУ затрагивают эту таблицу.
perfectdaemon
13.09.2017 12:29+5К нам обратился крупный российский перевозчик, владеющий внушительным автопарком. Его клиентами являются десятки логистических компаний и предприятий.
Аккаунт принадлежал одному из сотрудников логистической компании
То есть сотрудник логистической компании (а не перевозчика и владельца БД) имел доступ не только к данным своей компании, но и к чужим? При условии что:
Все запросы АСУ клиентов к базе данных (БД) перевозчика реализованы посредством набора Хранимых Процедур. Для управления доступом каждому клиенту выделяется его собственный аккаунт с набором необходимых ему полномочий и прав.
bogatrev Автор
13.09.2017 13:26+7Здесь был один организационный нюанс: упомянутая логистическая компания входила в один холдинг с перевозчиком, поэтому считалась доверенной, и ей был предоставлен расширенный доступ к данным.
pnetmon
13.09.2017 12:49Не хотелось быть первым комментатором, что бросилось при первом прочтении
Что-то непонятно.
- Каждый автомобиль оснащен системой мониторинга, оправляющей в диспетчерский центр данные о координатах, расходе топлива и множестве других показателей.
- которые продавали информацию о грузах перевозчика.
С технической точки зрения информацию о своем грузе можно получить двумя путями… Для управления доступом каждому клиенту выделяется его собственный аккаунт с набором необходимых ему полномочий и прав.
То есть продавалась информация о расположении ТС, а не характеристики самого груза, а то упор на которые продавали информацию о грузах перевозчика.? Или все таки и о грузе тоже?
- этого клиента — крупного логистического оператора
Аккаунт принадлежал одному из сотрудников логистической компании
Доступ клиентов осуществляется ко всей базе, или только к определенным ТС… а то какая защита от злоумышленников которые не будут так палиться
- В этот раз, благодаря встроенным методам фильтрации нашей аналитической системы, мы получили список из 12 аккаунтов, к которым «улетали» данные по координатам нашего грузовика в течение секунды после каждого нашего запроса.
А почему другие 11 создавали эти запросы?
pnetmon
13.09.2017 13:18+1Хотя
12 аккаунтов, к которым «улетали» данные по координатам нашего грузовика в течение секунды после каждого нашего запросы?
А почему к ним улетали данные по вашим запросам? И почему к выявленному злоумышленнику улетали по вашему запросу?
pnetmon
13.09.2017 13:31Хотя понял
В этот раз, благодаря встроенным методам фильтрации нашей аналитической системы, мы получили список из 12 аккаунтов, к которым «улетали» данные по координатам нашего грузовика в течение секунды после каждого нашего запроса.
Упущено "на криминальном ресурсе"
bogatrev Автор
13.09.2017 14:17+1Да, Вы верно поняли, в течение секунды к данным по нашему грузовику было несколько запросов от разных типов аккаунтов. Среди них были не только клиенты перевозчика, но и аккаунты самого перевозчика.
bogatrev Автор
13.09.2017 14:47+1Последовательность была следующая: мы делаем запрос с «левого» ресурса, и через секунду получаем данные. Данные, которые мы получили, были переданы одним из аккаунтов, имеющих доступ к БД. Кроме этого аккаунта в течение секунды к данным по этому грузовику обращались информационные системы самого перевозчика и АСУ клиентов. Всего таких обращений было 12.
algotrader2013
13.09.2017 23:51выходит, что если бы продавцы были чуть умнее, и давали бы данные со случайной задержкой (скажем, от секунды до часа, причем, случайная задержка как на запрос, так и на отдачу покупателю), то детектив был бы в разы интереснее?
bogatrev Автор
13.09.2017 15:03+1Кроме информации о координатах, была еще и информация о грузе. Та логистическая компания, сотрудник которой «сливал» данные, входила в один холдинг с перевозчиком, входила в число «доверенных лиц» и поэтому имела расширенный доступ к данным. О том, что доступ был слабо ограничен мы выяснили по результатам расследования и дополнительного анализа настроек доступа. Кроме них доступ к данным имел ряд собственных систем и сотрудников перевозчика.
pnetmon
13.09.2017 20:07А Вы можете раскрыть как "сотрудник" сливал? А то получается запросы от левых сайтов обращались на "компьютер сотрудника", преобразовывались в запрос в базу логистической компании, или сразу в базу транспортной компании, получался ответ и отсылал на левый сайт. И это как пишите занимало секунды, то есть работало в автоматическом режиме… и притом кажется должно работать 24 часа в сутки....
Также информация по грузовикам может быть интересна тем, кто сумел неофициально «пристроить» свой груз в кузове, например, договорившись с водителем.
Такие спокойно получают информацию от водителя...
Интересно — выдача по своему искаженных координат для каждого пользователя осталась или нет :)
x_sourer
14.09.2017 00:20Похоже у «сотрудника» была своя автоматизация…
Не совсем понятно так же, для чего было 11 легитимных обращений в ту же самую секунду по выбранному грузовику, еще и с разных аккаунтов.
bogatrev Автор
14.09.2017 09:43Сотрудник перенаправлял запросы с "левого" ресурса на свой сервер АСУ, а с него шёл запрос в БД
dekdegiv
13.09.2017 14:31Простите за, возможно, глупый вопрос, но почему некая логистическая компания должна иметь полный доступ на отслеживание всех А/М перевозчика, в которой она обслуживается. По идее, клиенту достаточно знать только где находятся те машины и тот груз, который ему принадлежит. Либо, в случае логистической компании, груз, за который она отвечает.
Если я прав, то при реализации такого разделения прав доступа, ни один клиент бы не смог предоставлять такие данные и утечку, если бы она вообще была, достаточно было бы искать внутри своей компании.
По сути перевозчик просто открыл клиентам свою полную базу данных и удивился, что кто-то что-то сливает, даже не предусмотрев заранее способ отследить, куда какие данные уходят и в каком объёме.bogatrev Автор
13.09.2017 14:38Кроме клиентов перевозчика доступ к данным получают как сотрудники перевозчика, так и несколько его информационных систем. При работе с крупными партнерами перевозчику трудно ограничить доступ каким-то набором грузовиков, ибо грузы нескольких клиентов зачастую перевозятся в одном кузове, поэтому разграничение доступа было достаточно сложным вопросом для перевозчика. Кроме того были и «доверенные» компании, которым по разным причинам предоставлялся расширенный доступ.
ogors2005
13.09.2017 14:47То есть система настолько дырявая, что любая «логистическая компания» может получить данные о всех перевозках, в том числе и тех, что делаются не в ее интересах?
По-моему, при таким раскладе искать «источник утечек» поздно. Источником является сама система, которая отдает всё всем.bogatrev Автор
13.09.2017 14:51Не любая «логистическая компания» может получить данные. Данные о всех перевозках доступны ограниченному набору информационных систем самого перевозчика и ограниченному набору сотрудников. Также некоторыми «расширенными» правами обладали компании, входящие с перевозчиком в один холдинг.
vitaliykuznetsov
13.09.2017 14:51как-то получается, будто любой клиент может узнать о любом грузе, даже о том, с которым он совершенно не связан. Это и правда так? Мне кажется так или иначе — такие вещи должны под коммерческую тайну каждого клиента попадать, а следовательно доступ к данным груза должен быть только у представителей (или сервисов) клиента, которому он доставляется.
bogatrev Автор
13.09.2017 14:55Это не совсем так. Любой клиент может получить доступ к информации о своем грузе. Но ряд внутренних систем самого перевозчика имела полный доступ к данным, как и ряд сотрудников перевозчика. Кроме того, за долгие годы взаимодействия с некоторыми крупными клиентами по мере роста доверия к ним, расширялись и их права. Если резюмировать, то коммарческая тайна в основном была защищена, за редким исключением.
haldagan
13.09.2017 15:34Как-то прозаичненько все обернулось.
Сотрудник (возможно просто хацкер, стянувший данные учетки) вдруг обнаруживает, что имеет доступ к информации, к которой по-хорошему доступа иметь не должен и решает на этом нагреть лапки.
Одно мне непонятно (какими бы теплыми ни были отношения двух компаний): почему логистическая компания (ЛК) имела доступ к данным по грузам всех клиентов перевозчика(П)?
Если, как вы говорите «Его клиентами являются десятки логистических компаний и предприятий», то все выглядит немного пикантней:
П «по-дружески» сливала информацию по конкурентам в ЛК из своего холдинга, причем другим своим клиентам — нет.
Прошу пояснить если я где-то ошибся или что-то не так понял.haldagan
13.09.2017 16:14Перечитал комментарии, увидел, что выше уже есть идентичный (и ответ к нему).
Правда ответ в духе «им было гемморно придумывать что-то с правами, поэтому решили дать все, но только проверенным» все равно звучит довольно плохо — именно из-за этого утечка и произошла.
И то, что вы нашли одного сливатора вовсе не значит, что не существует других, более скромных (которые сливают только проверенным и «из рук в руки»).bogatrev Автор
13.09.2017 17:23Других потенциальных «свитаторов» выявили на следующем этапе, но уже другими методами. Пришлось провести немало месяцев за анализом и перестройкой системы разграничения доступа.
hungry_ewok
13.09.2017 21:14+2>Одно мне непонятно (какими бы теплыми ни были отношения двух компаний): почему логистическая компания (ЛК) имела доступ к данным по грузам всех клиентов перевозчика(П)?
/усмехаясь/
Потому что когда-то однажды Высокое Лицо в компании сказало «им надо дать доступ». Подавляющее большинство интересных историй про утечки начинаются именно так.
bogatrev Автор
14.09.2017 09:46Скорее всего расширенный доступ дали при внедрении и отладке системы, потом так и оставили
amaksr
13.09.2017 20:45Оказалось, что в секунду обращений к таблице и представлениям более двух сотен, и выделить среди них обращения, сделанные в ответ на наши запросы, не представляется возможным.
А можно ли было проанализировать лог запросов только в течение коротких периодов прямо перед получением координат? Тогда нескольких «контрольных закупок» могло бы хватить чтобы понять, кто именно генерирует запросы синхронно с заказами на мошенническом сайте.bogatrev Автор
14.09.2017 09:49В трассировка нет самого запроса, только сам факт обращения к таблице. Чтобы получить подробности, пришлось ставить дополнительную систему
zenkz
14.09.2017 01:00На лицо проблема с правами доступа к системе.
Клиент, пусть даже самый доверенный, должен иметь доступ только к своей информации. Т.е. даже если груз идёт по каналам других перевозчиков, то он должен видеть только свой груз. В этом случае было бы намного легче найти утечку, а фактически всю головную боль вы бы переложили на клиента, т.к. слив шёл бы только данных этой компании. И я не поверю что такие ошибки можео объяснить чем-либо кроме плохой архитектуры системы или попустительством в области безопасности.
По поводу метода поиска утечки. Нужно было бы сделать 10 запросов с интервалом по времени к 10 разным грузовикам, но с одного аккаунта. Это бы позволило точно вычислить утечку.bogatrev Автор
15.09.2017 13:19Дело в том, что мы не знали, какой из аккаунтов запрашивает данные из БД для «левого» ресурса. Делая запрос на этом ресурсе мы могли только смотреть, что происходит в хранилище данных.
anitspam
14.09.2017 04:31+1Статья, видимо, о том, что в реальном мире очень мало хорошо спроектированных отлаженных долгоживущих систем, где поиск злоумышленника заключается в «давайте ещё больше увеличим картинку с камеры видеонаблюдения и увидим отражение преступника в солнечных очках жертвы».
Вот и получается, что при разборе полётов оказалось, что когда-то кто-то кому-то дал «лишний» доступ, потому что не было ресурсов (времени, денег, специалистов), чтобы настроить всё нормально.
А переделывать всю систему слишком дорого, долго и с непонятно каким результатом.
В общем, молодцы, что разобрались и не сошли с ума, ковыряясь в чужом коде и настройках :)
Dessloch
14.09.2017 08:45+3Всё как обычно. Сначала создаём проблему, раздавая доступ и права кому попало, потом дружно её решаем.
amarao
14.09.2017 09:53Доступ конагентов посредством хранимых процедур в базе. Звучит как успех.
/сарказм
/сарказм
/сраказм
cyberorg
14.09.2017 10:00А зачем в начале поста картинка из Euro Truck Simulator'a?
Это как в любом сюжете про хакеров на Вести24 показывают серверные стойки.
TimsTims
14.09.2017 11:01+11) Получается, этот сотрудник поднял кучу демонов на своём компе, принимал деньги на криминальном сайте, и организовал ответ-в-ту-же-секунду, но он такой глупый, что использовал СВОЮ учётную запись?
2) Рассматривали ли вы вариант, что есть другие криминальные сайты, которые всё-еще сливают данные, но не палятся так широко, как предыдущий?
3) Рассматриваете ли вы вариант, что взломщик — другой человек, и он после блокировки теперь заляжет на дно, а проснётся позднее? Или это больше дело безопасников, а вам нужно только найти крота?bogatrev Автор
14.09.2017 14:34+11) Сотрудник только сотрудничал с организаторами ресурса, скорее всего ему передали готовую утилиту, но это мы не проверяли.
2) Другие сайты именно по этому перевозчику найдены не были, но подобных им, продающих ворованные данные, много. У каждого свои каналы. Некоторые не работают в режиме онлайн, скорее всего им данные поставляют под заказ или с ежедневными бэкапами.
3) Мы понимали, что организаторы прибыльного бизнеса будут искать возможность организовать новый канал, поэтому вместе с админами перевозчика "перетряхнули" все настройки доступа и внедрили мониторинг запросов к БД
dmitry_dvm
Люблю такие детективы. В такой ситуации мог бы помочь файрвол для БД?
bogatrev Автор
Файрволл не помог бы, т.к. все запросы абсолютно лигитимные с согласованных адресов. С помощью файрволла можно отключить запросы со стороны найденного нарушителя, но это же можно сделать и средствами управления аккаунтами.
SurfCalavera
нет конечно. доступ-то абсолютно легальный был через авторизованого клиента.