Что мы узнали: вчера в 3 ночи был сформирован файл с, предположительно, дампом данных покупок автобусов, сделанных через наш сайт tutu.ru, там 2,5 миллиона строк технических неочищенных данных (в том числе с повторами). Там номера заказов, имена пассажиров и почты. Платёжных данных и данных о маршрутах в дампе нет.
Похоже, это действительно часть данных наших заказов. Там нет пунктов прибытия-отправления, дат заказа, но есть фамилия и имя плательщика (но не всех пассажиров), телефон и почта для отправки чека.
Произошло следующее: с 24 февраля мы вошли в списки целей для атак в хакерских и краудхакерских группах. Сначала нас банально дидосили, потом небанально дидосили, после чего хакерам удалось на короткий промежуток времени уронить сайт РЖД (фронты, но не АСУ Экспресс), и мы стали целью №1, потому что продолжали выписывать билеты. Положить нас тогда так и не удалось. С тех пор продолжаются и волны DDoS, и атаки на почту и другие типы направленных атак.
Основные версии утечки:
- Сопоставление данных пользователей с утечками крупных сервисов вроде Яндекса, Деливери, Пикабу и взломов почт. Похоже, что нет, в таблице есть технические учётные записи.
- Один из внешних технических контрагентов, связанных с эквайрингом.
- Собственные разработчики или члены инфраструктурной команды. Эту версию нельзя исключать никогда ни на каком проекте ни при каких условиях.
- Направленная атака на неизвестный нам баг.
Теперь детали про расследование.
Что утекло
На текущий момент в анонсе хакеров три таблицы. В них, предположительно, данные на разные виды транспорта. Судя по анализу той таблицы, к которой мы получили доступ, это части заказов за последние два месяца по одному продукту (автобусам), плюс точечно — за пределами этого срока. UPD: продолжаем анализировать, вероятно, база включает данные больше двух месяцев.
Ещё раз: платёжные данные не утекли. Маршруты (конечные-начальные пункты) не утекли.
Это далеко не полная база, объём — менее процента от общего объёма заказов.
Что мы делаем сейчас
Первое — если не сработали, скажем так, мониториговые части контура, нужно на низком уровне найти поток данных, который мог привести к утечке. Инфраструктурная команда сразу же начала разбирать все потоки за последние месяцы, чтобы увидеть передачу похожих массивов по трафику. Естественно, тут мы не можем раскрывать детали реализации, но очень коротко — найдём, что это было, но не прямо сегодня.
Второй задачей было получить доступ к таблице с дампом. Его мы получили спустя полчаса после анонсов хакеров.
Третья часть — отработать основные версии.
Как я уже говорил, их четыре, и первую, с сопоставлением данных других утечек с нашими клиентами (либо использование утекших авторизационных данных почт при масштабных взломах почтовых провайдеров прошлых лет) мы отбросили почти сразу. Кто-то получил доступ к одному из технических потоков.
Вторая версия — это внешний поставщик, разрабатывавший одно из решений в сфере эквайринга. Платежные данные не утекли, решение проходит ежегодную сертификацию по стандартам PCI DSS высшего из возможных классов (Service Provider Level 1), поэтому такая версия маловероятна, но тем не менее мы её тоже тщательно прорабатываем.
Третья версия — сотрудник компании. Такое нельзя исключать. Хочется верить, что это окажется только версией, а не реальностью.
Четвёртая версия — возможная эксплуатация бага, о котором мы не знаем. Для этого тоже нужен анализ потоков данных на низком уровне.
Это пока всё, что известно на текущий момент. Скорее всего, будут апдейты в следующие дни, но если тут стоит национально-политический вопрос, то, скорее всего, я до какого-то момента смогу делиться только частью технических данных, чтобы сохранять тайну следствия.
UPD: 5 июля хакеры объявили о фейковой утечке — по факту это компиляция уже известных почт с ранее скомпрометированными паролями из других баз. Почты из таблицы с нашими заказами сопоставили с утечками других интернет-ресурсов. Если пароль от почты был скомпрометирован ранее, его могут попробовать для личного кабинета у нас. Мы получили доступ к компиляции и сейчас занимаемся сбросом паролей пользователей, которых сопоставили с другими утечками.
Комментарии (56)
amarao
02.07.2022 16:47+24То что сообщили и признали - респект. В списке возможных причин почему-то не хватает банальных:
простые пароли
забытая монга (или что у вас там) голой задницей в сеть.
случайный disclose секрета для доступа к (whatever)
Первые две часто объединяют в "ошибка конфигурации", а второе в accidental disclose (как это по-русски? Случайное разглашение?)
И ещё, когда вы делаете утверждения в условиях тумана войны, надо быть точнее и менее резкими. Например, "Ещё раз: платёжные данные не утекли" правильно должно звучать как "мы не располагаем доказательствами или обоснованными предположениями об утечке платёжных данных".
Подписался на блог, чтобы послушать постмортем. Надеюсь, публичный и с подрбностями.
Cerberuser
02.07.2022 16:50-3В каком-то смысле это всё тоже можно замести в категорию "неизвестный баг" (если сделано по недомыслию) или "сотрудник" (если умышленный бэкдор). Не буквально, конечно, но по сути отличия не сильно велики, имхо.
amarao
02.07.2022 16:53+1Коммит пароля в гит нельзя считать "багом", потому что нет того кода, в котором баг.
И монга голой задницей или слабый пароль на почему-то публично доступном инстансе БД (бэкапа?) - это тоже не "баг".
eyudkin
02.07.2022 17:17+2Давайте назовём это не багом, а технической недоработкой ¯\_(ツ)_/¯
amarao
02.07.2022 19:41+3Совершенно нормально классифицировать это как ошибки конфигурации.
И это запросто может быть не "в продакшене", а в стейджинге, например. Одна ошибка - и база вылита не туда при recovery. Повторная recovery восстановила "туда", а потереть с стейжинга забыли. Через N времени стейджинг поломали (и всем почти пофигу), а там продакшен-база. оп.
fougasse
02.07.2022 19:36+1Это не bug, да. Это issue.Или, если больше нравится, defect. Конфигурирования. Не всё ограничивается кодом и проблемами в нём.
Cerberuser
02.07.2022 21:55Я о том, что общая суть реакции здесь близкая к описанным случаям: "найти и исправить проблему в компьютерной системе" и/или "найти и привлечь к ответственности сотрудника-вредителя". Возможно, конечно, что-то упускаю.
amarao
02.07.2022 22:50+1Тогда это другая классификация:
Ошибка сотрудника
Ошибка не сотрудника (а рандомного парня из Невады, который leftpad писал)
Вредительство сотрудника
Действия со стороны партнёра.
spacediver
05.07.2022 13:01А вот я думаю, в век конфигурации-как-кода такое стоит считать багом. Есть код — есть и баг ;) Есть даже коммит, в котором он был introduced.
amarao
05.07.2022 13:10+1Есть код, есть баг. При этом запощенный в plaintext в гите пароль не является ни кодом, ни багом.
security не может быть описано в виде функциональных требований, так что натягивать на секьюрити баги - это странно. Баг может иметь последствия в безопасности, но security issue запросто может быть не багом ни с какой точки зрения.
funca
02.07.2022 17:53+4правильно должно звучать как "мы не располагаем
Нет, не правильно). Сертификация PCI DSS (Payment Card Industry Data Security Standard) как раз и нужна для того, чтобы в случае инцидента была возможность отвечать на такой вопрос с крайне высокой степенью достоверности, а не как вы предлагаете.
В сфере персональных данных (PII) я не видел чего-то подбного - только нормативные документы. Поэтому здесь все может быть сложно.
amarao
02.07.2022 19:39+2Вообще говоря, никакой PCI DSS вам не поможет, если у вас lateral movement на технологии, которую вы не видите (хотя думаете, что видите всё). Недавняя малваря с патчем pcap-фильтра для скрытия своего трафика - отличный пример.
funca
02.07.2022 20:56Это вопрос вероятностей. Если из сертифицированной системы можно незаметно слить данные, то данный факт сам по себе уже тянет на настоящую сенсацию (встав на одну ступеньку с известными ограблениями банков).
amarao
02.07.2022 20:58+2Зависит от объёма, но в целом, если она не air-gapped, то существует много интересных побочных техник слива. Начиная с банального SSL с доверенным доменом (если у вас разрешён трафик до GH или условного hub'а, откуда вы знаете, это слив или апдейт качали?) и заканчивая редкостной стеганографией, типа влияния на счётчики скачивания с публичных сайтов. (вполне себе бит информации).
funca
02.07.2022 21:50Мне нравится ход ваших мыслей. Но если говорить конкретно про данные, подпадающие под PCI DSS, то идея со счётчиками кажется не сильно правдоподобной. Если только крякеры не получили в свое распоряжение бекдор для доступа к самому счётчику или оборудованию, что уже тянет на теории заговора совсем другого порядка.
amarao
02.07.2022 22:47+3Почему? Берёте редкие объекты, и каждый из них - бит информации. Вероятность просмотра видео с 15 просмотрами за 3 года на ютубе стремится к нулю. Если там случилось +3 просмотра, то это уже вполне себе бит информации. То же касается редких пакетов на pipy, crates, npm и т.д.
Плюс коррекция ошибок. Я, конечно, утрирую, и проще через публичный же сайт заслать в условные комменты, но если сервер не air-gapped, то я не верю в возможность определить что именно спёрли с сервера (и с какого из). Обнаружить потом малварю или следы движений - да. А процесс тырения - нет. Потому что если это неавторизованный доступ, то первым делом смотрят куда сервер раньше ходил, потом отключают аудит и любую другую паранойю, и спокойно сливают по тем же маршрутам. Весь трафик давно шифрованный, так что понять слив нескольких сотен мегабайт почти невозможно.
В волшебном мире security-фей там полный закрытый периметр с побайтовым просеиванием проходящего, но IRL там будет херачить k8s/доркер, качающий гигазы с хабов, аптовые/rpm'ные апдейты, телеметрия с ping back библиотек, бегающий "налево" certbot за апдейтом, и ещё чёрт в ступе, а ещё миллионы exec'ов от условного ансибла.
gecube
03.07.2022 01:18+1В волшебном мире security-фей там полный закрытый периметр с побайтовым просеиванием проходящего, но IRL там будет херачить k8s/доркер, качающий гигазы с хабов, аптовые/rpm'ные апдейты, телеметрия с ping back библиотек, бегающий "налево" certbot за апдейтом, и ещё чёрт в ступе, а ещё миллионы exec'ов от условного ансибла.
ни черта. В нормальном мире делается так, что там кубер-докер, со своим внутренним докерхабом без возможности скачать всякую дичь снаружи, апт/rpm - тоже зеркалим к себе (это не спасает от дичи на 100%, но мы получаем внятные контроли) и все такое. cert-bot - да, ну, строим свой внутренний УЦ, а внешним клиентам отдаем периметр, в DMZ... со своими правилами работы, все логично и красиво, и даже не дохнет на куче трафика
amarao
03.07.2022 11:04-2И это работает, если у вас не было существенного lateral movement. Потому что, вопрос, что случится в тот момент, когда у вас будет малварь на хосте с кубом и на хосте с (условным) aptly? Правильно, они себе обеспечат транспорт.
И чем больше у вас всяких репликаторов, кеширующих серверов для pipy, мирроров и т.д., тем больше у вас периметр для атаки на "интернет-able" сервера.
Понятно, что если речь про одиночный инцидент это всё хорошо работает. Но если люди хотят утырить что-то, то они, очевидно, ищут пути.
Я не говорю, что так делать не надо (надо!), но утверждение, что мол, если PCI DSS L1 - то можно с уверенностью утверждать о том, утекли платёжные данные или нет, мягко говоря, не правда.
Мы сертифицированы по PCI DSS Level 1 и мы уверены в том, что все наши программы останавливаются после конечного числа шагов.
gecube
03.07.2022 12:53Я не говорю, что так делать не надо (надо!), но утверждение, что мол, если PCI DSS L1 - то можно с уверенностьюутверждать о том, утекли платёжные данные или нет, мягко говоря, не правда.
Я, кстати, не говорил, что если pci dss, то карточные данные нельзя утащить…
Можно, но это сделать сильно сложнее, чем если бы инфраструктура и процессы не были сертифицированы
gecube
03.07.2022 01:15Начиная с банального SSL с доверенным доменом (если у вас разрешён трафик до GH или условного hub'а, откуда вы знаете, это слив или апдейт качали?)
для этого на выход трафика делают прокси с полным логированием всех доступов (ну, ок, может только url записывают, без пейлоадов), а в мире k8s security - пишут фильтры на L7 (типа GET запросы разрешаем, хотя и через них пропихнуть можно данные, а POST, а тем более PATCH/UPDATE и прочие ни-ни - при чем с грануляцией по эндпойнтам)
amarao
03.07.2022 11:11+3Во-первых прокси - ещё более вкусная цель, чем одинокая нода куба.
Во-вторых, вы не можете в общем случае заставить весь софт снять с себя SSL. Если кто-то хочет SSL и имеет пиненый сертификат, то софт надо пересобирать, и это если сырцы доступны и программисты понимают где и что.
Вообще, на самом деле, спор сводится к тому, обладает ли команда знанием о софте, который запущен. Моё наблюдение говорит, что с каждым годом - всё меньшим и меньшим. Потому что строк кода всё больше, а человеков - меньше. Знание высокоуровневое и функциональное (мы знаем зачем оно в целом) и совершенно неличное, потому что рядом с "простыми библиотеками" оказываются массивные фреймворки, от которых, быть может, используется 3% возможностей (оставляя 97% в тени).
gecube
03.07.2022 12:28+2Во-первых прокси - ещё более вкусная цель, чем одинокая нода куба.
Логично. Но что проще защитить - 100500 узлов кубера или один единственный прокси? И что будет дешевле защищать?
В конце-концов речь ведь не только про предотвращение проблем, но и сделать так, чтобы мы их могли в принципе увидеть.
Во-вторых, вы не можете в общем случае заставить весь софт снять с себя SSL. Если кто-то хочет SSL и имеет пиненый сертификат, то софт надо пересобирать, и это если сырцы доступны и программисты понимают где и что.
Несомненно. Но никто не мешает и этот софт ограничивать. Или стараться пользоваться более понятным софтом с исходниками. Ещё вариант - для каждого такого «закрытого» софта со своим ссл и пиннингом сертификатов делать отдельную песочницу с четко означенным точками интеграциями с другими кусками инфраструктуры. Это, если делать хорошо. Если делать как обычно - в инфре зоопарк и «каждый может ходить куда угодно». Секурити группы в облаке? Не, не слышал
Ну, давайте простой пример. Кто вообще настраивает acl на ssh? Чтобы закрыть возможность ходить с сервера по ключу на другой сервер? А вообще делается легко - вряд ли человеки будут проксиджампиться через продовые сервера, у них выделенный бастион должен быть (отказоустойчивый), либо какие-то пам штуки с привольными возможностями вроде входа по токенам, а не паролям.
amarao
04.07.2022 12:15Видимо, узлы куба без выхода в интернеты защитить проще, чем прокси, которая в оном интернете голой задницей.
В прочной системе у вас не одна прокся, а кластер из проксей в каждом регионе, что выводит их в новую категорию по сложности. Кроме того, где они деплоятся? Ну, олдфаговый админ поднимет сервер. А новый - швырнёт в тот же куб, только с выходами в интернеты, то есть проблема всё равно вернётся к нодам куба, только кубов теперь больше.
gecube
04.07.2022 12:19Мы как именно сравниваем? Почему мы сравниваем "узлы куба без выхода в интернеты" и "прокси"? Когда очевидно, что узлы кубера с выходом в интернет - это просто черная бездонная дыра.
Лучше рилли прокси + узлы кубера отдельно
А новый - швырнёт в тот же куб, только с выходами в интернеты, то есть проблема всё равно вернётся к нодам куба, только кубов теперь больше.
когда это количество кубов было проблемой? Два кубера - один в DMZ, второй - во внутреннем периметре - очевидно УДОБНЕЕ для обслуживания и БЕЗОПАСНЕЕ, чем один кубер, распределенный по двум сегментам (еще и лови проблемы странные из-за этой сегментации). Админы как-то раньше с 1000-5000 ВМ справлялись, что - с 5-10 куберами не справятся?
amarao
04.07.2022 12:22А теперь вопрос: если это кубы одной версии и там zero day с RCE+LPE, то насколько два куба в DMZ устойчивее, чем один куб? Ну... как один человек на ютубе говорит "little movement on three, four is binding, and we have it opened".
gecube
04.07.2022 12:33и там zero day с RCE+LPE,
против лома нет приема. Системы нынче стали сложными. Лучше - чтобы у тебя был прокси с RCE+LPE в интернет или просто сервер с софтом, где вообще бардак? Сложная дилемма, прям даже не могу выбрать.
amarao
04.07.2022 12:36... если бы кубы были на (условной) бубунте 22.04, а прокси - без всяких кубов на centos7, то вероятность словить парный RCE+LPE одновременно, была бы ниже.
А если бы это ещё была и фря, то совсем нет. С другой стороны, комбинация кубов и фри даёт больший периметр для атаки.
zaiats_2k
02.07.2022 17:59+10"мы не располагаем доказательствами или обоснованными предположениями об утечке платёжных данных" - это для разговора профессионалов. Для широкрй общественности нужно проще выражаться, а то журналисты поймут все с точностью до наоборот.
amarao
02.07.2022 19:37-2Вы совершенно правы. И где мы находимся? Явно не в месте для "широкой общественности". Так что получить за чрезмерно оптимистичные заявления от профи - вполне заслуженно.
Xobotun
02.07.2022 21:03+13Позвольте не согласиться. Всё же хабр находится в интернетах, куда нынче вхож журналист. Если этот критерий недостаточен для "широкой общественности" — то полагаю, что ныне почившие Мегамозг и Гиктаймс таковыми являются. Если и они не — то, емнип, РФ считает Хабр СМИ. Даже включали в какой-то реестр социально значимых ресурсов, к которым положен доступ и без оплаченного интернета (интересно, что там нынче с этой инициативой...). Если и это не убеждает — что ж, я более бессилен. :D
amarao
02.07.2022 22:40То есть правду и точно можно говорить только там, где журналистов нет? То есть нигде?
Не убедили.
Arkt Автор
03.07.2022 12:38+2Спасибо!
Естественно, простые пароли, забытую монгу, disclose секрета мы рассмотрели первыми. Плюс это части основных гипотез тоже. Простите, что я медленно отвечаю, сейчас немного не до того.
constXife
02.07.2022 18:21+26Сегодня в обед украинские хакерские телеграм-каналы сообщили, что осуществлён взлом в качестве «ответки за Новую Почту».
Я правильно понял ситуацию: "За то, что Петя побил Васю, мы побили Станислава"?
YMA
02.07.2022 18:35+10Сейчас так - кто до кого дотянулся, того и похакал... У меня личный веб-сервер висит дома, посмотрел сегодня логи - интенсивность попыток поломать с февраля раза в три больше стала, боты сканят уязвимости GPON-терминалов, роутеров, различных фреймворков...
Вот такие строчки по несколько сотен в час :( С голландских, китайских, немецких IP адресов...
85.202.169.228 - - [02/Jul/2022:18:12:36 +0300] "POST /GponForm/diag_Form?style/ HTTP/1.1" 404 153 "-" "curl/7.3.2"
185.7.214.104 - - [02/Jul/2022:07:57:37 +0300] "GET /_ignition/execute-solution HTTP/1.1" 301 169 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
Интересно, а есть смысл писать хостеру? Посмотрел, заметная доля с адресов хостера serverion.com идет, написал на abuse - пока тишина (да, наивный чукотский парень).
PS: У меня там чистая статика, ломать кроме сервера и nginx нечего ;)
funca
02.07.2022 21:01+1Поэтому многие компании в срочном порядке попрятали свой web за Cloudflare, где отстрел большинства известных атак поставлен на поток. Интересно какие варианты есть в РФ?
Manyak872
03.07.2022 15:37+5Скорее это утверждение не может являться ни истинным, ни ложным. Определённое количество людей рассматривает государство и все службы/компании/граждан этого государства (нужное подчеркнуть) как единый объект. Поэтому с иным набором аксиом это «За то, что коллективный Петя побил коллективного Васю, мы побили коллективного Петю».
Didimus
03.07.2022 09:48А можете работать вообще без персональных данных, например, выдали qr-код тому, кто оплатил билет, и по нему сажают в автобус? Как билет на метро, примерно.
Что этому препятствует?
Ds02006
03.07.2022 10:13+6При перевозке железнодорожным, морским, внутренним водным и автомобильным транспортом перевозчик обязан формировать автоматизированные базы данных пассажиров, которые в соответствии с частью 5 статьи 11 Федерального закона от 9 февраля 2007 г. N 16-ФЗ "О транспортной безопасности" включают:
фамилию, имя, отчество пассажира;
дату и место его рождения;
вид и номер документа, удостоверяющего личность, по которому приобретается проездной документ (билет);
пункт отправления, пункт назначения, вид маршрута следования (беспересадочный, транзитный);
дата поездки.
Dura lex, sed lex.
Didimus
03.07.2022 10:42Погодите, перевозчик, а не продавец билетов же?
DaemonGloom
03.07.2022 11:47+6вид и номер документа, удостоверяющего личность, по которому приобретается проездной документ (билет);
Там зацепили всех подряд этими правилами, документы нужны сразу же.
denis-isaev
03.07.2022 13:32+1А сколько их требуется хранить? Или длительное хранение — это уже отсебятина, а не следование законам?
Tomasina
03.07.2022 19:42+1Не отсебятина, а прикрытие зада руководителем. Завтра контролирующие органы могут предъявить: "А предоставьте записи о поездках, которые были 4 месяца назад. Как не можете? Это прямое нарушение ФЗ-..." И далее будут ачивки в вышестоящие, с разборками, которые по стоимости могут выйти сильно дороже текущего решения "на всякий случай храним год".
Ds02006
03.07.2022 19:55+4Мне кажется, что Вы неправильно понимаете термин "ачивка". Это же синоним слова "достижение" (achievement).
denis-isaev
03.07.2022 22:05+1Так если есть такой ФЗ, то это следование законам и есть, а если такого ФЗ нет, то отсебятина.
YMA
03.07.2022 21:11+1В общем случае Ст. 5 152-ФЗ
7. Хранение персональных данных должно осуществляться в форме, позволяющей определить субъекта персональных данных, не дольше, чем этого требуют цели обработки персональных данных, если срок хранения персональных данных не установлен федеральным законом, договором, стороной которого, выгодоприобретателем или поручителем по которому является субъект персональных данных. Обрабатываемые персональные данные подлежат уничтожению либо обезличиванию по достижении целей обработки или в случае утраты необходимости в достижении этих целей, если иное не предусмотрено федеральным законом.
Закон о транспортной безопасности не накладывает дополнительных условий, поэтому предположу, что максимальный обоснованный срок хранения может быть 3 года с момента окончания исполнения обязательств перевозчиком (исковая давность, на случай, если пассажир предъявит претензии), а минимальный, который я нашел - 1 месяц с окончания.
DmitriiPisarenko
За то, что вы проактивно сообщили об утечке -- большой респект.
eyudkin
Действительно. В современном мире кажется невозможно быть абсолютно неуязвимыми, особенно когда у вас достаточно большая система. Куча компонентов, куча сторонних библиотек разных версий, куча людей работает в конце-то концов. И уязвимость может подкрасться откуда угодно, векторов атаки слишком много.
Поэтому респект и уважение тем, кто честно и по человечески говорит, что "да, взломали, разберемся, починим, будем на связи". Сразу больше симпатии появляется к таким компаниям
в конце концов все там будем.Popadanec
Да, когда привык что со всех щелей льётся только враньё(как правило, чтобы временно скрыть суровую правду) или в лучшем случае полуправда и недоговорки, вы выглядите лучиком надежды на светлое будущее.