Positive technologies

или как хакеры ломали наш опенсорс платежный процессинг в кибергороде.

Привет! Мы тут недавно с процессингом RBK.money приняли активное участие в киберполигоне The Standoff это когда делают виртуальную модель целого мегаполиса со всей его инфраструктурой, энергостанциями, магазинами и прочими важными элементами. А потом пускают в этот цифровой двойник города команды blue team (6 команд в этом году) и red team (29 команд в этом году соответственно), первая защищает всю эту инфраструктуру, вторая же активно пытается что-то сломать.


из к/ф Бегущий по лезвию 2049

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

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

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

Подсказки хакерам

Ещё до раскатки процессинга на кибергород мы намеренно оставили там два довольно слабых места.

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

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

Зато взошли наши собственные косяки.

Поспешишь не всё защитишь

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

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

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

А ещё наприлетало из-за особенностей кубера.

В Kubernetes основное хранилище о состоянии кластера ETCD, полезная распределенная система, на которой можно строить весьма и весьма надежные штуки. Но она слишком критична к latency жестких дисков.

Как я писал, мы разворачивали процессинг в виртуальной среде кибергорода. На соседние с нами объекты шли довольно активные атаки, и однажды к нам на датастор кубера передвинули один из таких шумных объектов, инфраструктуру одного из участников, которую ломали долго и упорно. И хотя де-факто мы в этом случае не были мишенью и в тот момент никто не ломал именно процессинг, он продолжал работать штатно, но сам кластер начал дико тормозить, харды просто не справлялись (успели заметить что вывод команды ls -l занимал порядка 19 секунд). Получилось, что вышел своеобразный DoS, и в одну ночь мы отдавали на все запросы наших стандартных котиков.



После этой ситуации организаторы The Standoff передвинули нас на другие диски, то есть погасили одну виртуальную машину и включили еще одну, в другой локации. После чего наша распределенная СУБД радостно словила split-brain, половина нод содержали одну информацию, половина другую, и особо не могли с собой договориться. На бою мы, конечно, серьезнее бы заморочились с миграцией и не допустили подобного. А в тестовой среде куда проще было просто грохнуть все имеющееся и инсталлировать заново, что мы и сделали, потратив, кстати, 2 часа. Почему я это выделяю потому что мы развернули полноценный рабочий процессинг со всеми составляющими за два часа, и такое с нашим процессингом вы можете проделать на бою в своей компании. Классические процессинги обычно разворачивают в компаниях месяца 3.

Так вот, про split-brain, это все спешка. Мы в запаре просто на одной из нод под корень снесли /tmp. Кто ж знал, что модуль CSI LVM, который раздает локальные тома с железа в поды, скрыто (!) монтирует персистентный том кубера в /tmp. Таким образом получилось, что мы своими собственными руками снесли данные под ногами СУБД, которые на ней крутились. Причем, несмотря на то, что мы снесли хранилище для части нод в кластерах баз, у нас все продолжало работать до первого перезапуска виртуальной машины, который случился, когда нас начали переносить на новые сторы.

Blue-team медленно выключает свою защиту

В один из дней команды blue-team решили выключить внешние защиты (firewall и прочее). То есть первые пару дней хакеры пытались ломать системы с включенной защитой такого рода, а потом без. У нас также стоял сторонний WAF, который в ингрессе с нжинксом в виде модуля подгружался и защищал наш трафик.

И вот настал этот день, мы пошли выключать WAF и поняли, что он и так уже отключен. Два дня назад. Потому что мы молодцы и в спешке (да, да), настраивали ingress kubernetes, на котором был экземпляр WAF. И всё бы хорошо, но WAF банально не достучался до управляющего сервера, не смог с него скачать файл лицензии, пожал плечами и просто выключился от греха. И получается, что мы все эти два дня Ломаем с включенной защитой сидели, собственно, без этой защиты.

Но всё равно нас не сломали.

Ещё одно подкрепление тезиса, что спешить вредно (вдруг вам мало предыдущих) ситуация с нашим антифродом. Я описывал его в предыдущих постах блога, там волшебная коробка с набором правил. Антифрод защищает от перебора банковских карт, попыток оплатить в одну точку из разных локаций / IP / email и прочих недружественных действий. Мы сказали команде защиты, что сами вдумчиво настроим все эти правила.

И мы это сделали мы тщательно настроили все правила для антифрода. На нашем боевом сервере RBK.money вместо инсталляции для The Standoff. Банально перепутали урлы UI в адресной строке браузера. То есть антифрод на это время представлял собой коробку с молчаливой загадочной пустотой.

Это и стало одним из успешных векторов для редов:
например, они до этого взломали сторонний интернет-банк, стырив PAN-код карты (сами цифры, Primary Account Number), имя держателя карты и подобрав дату действия. После этого уже в нашем процессинге по этому PAN стали перебирать CVV. И все было бы хорошо, после 3 попытки перебора карты были бы заблокированы нашим антифродом. Если бы см выше.

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

Конечно, первым делом грешили на мисконфиг, непонятную работу кластера.

С DNS проблему быстро решили выносом CoreDNS подов прямо на ноды, где этот трафик не фаерволился, а с NTP нам повезло по счастью, большого clock skew мы не поймали, а при создании кластера ноды еще успели синхронизироваться.

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

Другие атаки

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

Хорошо, что мы не перепутали урлы алертов над эластиком и в мониторинге, и видели их достаточно точно и достаточно быстро.

Для примера, как в случае со взломом нашего олигарха и уведённым API-ключом. Взломали его в 22.17 МСК. В 22.22 мы на своей стороне заметили это и сразу отрепортили команде защитников и организаторам. Заметили, кстати, благодаря кривому использованию API хакеры передали в первом запросе странный заголовок content type, вызывали редкий метод нашего API, еще кое-какие нюансы вот и был повод сработать алерту.

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

На будущее

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

И это на самом деле было очень классно и весело. Фактически мы получили большой набор Chaos Monkey-кейсов, которые не факт что стали бы воспроизводить на продакшене, мы протестировали процессинг на атаки, получив за 2 дня больше атак, чем к нам штатно приходит за полгода.

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

Нам очень понравилось и хочется ЕЩ.

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

Каждый год мы с друзьями ходим в баню. Каждый год, когда наши большие друзья, компания Positive Technologies проводит свое глобальное мероприятие для настоявших экспертов в области информационной безопасности PHDays. И каждый год мой друг и коллега Алексей Лукацкий говорит мне Миша, давай что-нибудь технологическое сделаем!. А потом выясняется, что заваленный рутиной, я опять все пропустил. Но этот год, как мы все уже заметили, глубоко особенный. И вместо PHDays было проведено очень эффективное и масштабное мероприятие под названием Standoff. В этот раз я решил послушать Алексея Викторовича и успеть что-то сделать! Тем более, что мероприятие существенно превосходило все, что когда-либо делалось ранее. Посмотреть детали этого впечатляющего киберполигона можно вот тут: https://standoff365.com/battlefield.
Вкратце скажу, что он эмулировал собой полноценный, и весьма немаленький город, в котором было практически все начиная от аэропорта, и заканчивая финансовыми организациями и парком аттракционов! Это давало злоумышленникам возможность проявить свои навыки взлома, а защитникам свои навыки обнаружения и отражения угроз.

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

Мы понимали, что вмешиваться в работу полигона мы не должны, а также заниматься детальной подстройкой профилей обнаружения атак формат мероприятия не позволяет, то и было выбрано решения класса NTA (NTA Network Traffic Analytics) это решения, которые определяют угрозы по анализу сетевой телеметрии, или, попросту говоря, профилю сетевого трафика. Внедрение таких систем идет гораздо проще и бесшовнее, чем, например, внедрение классических систем обнаружения и предотвращения вторжений. Это связанно и с тем, что нет необходимости вносить изменения в сетевую топологию, а также тем, что ядром таких систем является машинное обучение в сочетании с данными аналитики угроз. Такой подход позволяет системе не только быстро идентифицировать типовые угрозы, но и обучиться за определенный интервал времени, а затем использовать полученные знания для обнаружения нештатного поведения пользователей, систем и приложений. Также такие системы, просто по своему подходу, являются существенно менее шумными с точки зрения оповещения о всевозможных угрозах и гораздо более точными с точки зрения идентификации реальных инцидентов. На этом краткий экскурс в данную тему я закончу, кто хочет почитать об этом подробнее, советую обратить внимание на вот такой материал:
http://personeltest.ru/aways/habr.com/ru/company/cisco/blog/348532/

Изначально, я решил использовать давно и хорошо известный продукт Cisco Stealthwatch Enterprise, успешно применяемый многими моими коллегами в разных организациях. И уже собрался позвонить коллегам в Positive чтобы рассказать им, сколько мне нужно процессоров, места дисках, виртуалок и т. п. В этот момент странная мысль посетила меня я вспомнил, как много ресурсов и людских и технических было положено на создание этого киберполигона, и подумал, что на то, что часть этих ресурсов попрошу я, никто не рассчитывал. С другой стороны, отказываться от идеи не хотелось, и в рамках современных тенденций в области обеспечения информационной безопасности я решил перейти на облачное решение под названием Stealthwatch Cloud. Надо сказать, что это решение называется облачным не зря, так как оно умеет собирать и анализировать телеметрию частных облаков, создаваемых внутри публичных облаков, через прикладные программные интерфейсы (API). Т. е. с помощью этого решения я могу анализировать, с точки зрения информационной безопасности, происходящее внутри Amazon AWS, Microsoft Azure, Google GCP, а также контейнеров Kubernetes. Но сейчас мне было нужно другое применение этого продукта а именно мониторинг частных сетей. В этом случае в такую сетку просто устанавливается датчик (сенсор), которые и отдает телеметрию в облачную консоль мониторинга и управления. В предыдущем предложении я употребил слово просто и теперь попробую развернуть его подробнее.

Итак, как же выглядит процесс?

Надо запросить триалку, это занимает пару минут.
Ссылка тут:
https://www.cisco.com/c/en/us/products/security/stealthwatch/stealthwatch-cloud-free-offer.html?dtid=osscdc000283

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

cisco-YOUR_CISCO_USERNAME.obsrvbl.com, например: cisco-mkader.obsrvbl.com.

Заходя туда, мы видим главный экран, откуда можно скачать виртуальную машину сенсора для мониторинга частных сетей. Требования под эту виртулку не велики 2 vCPU, 2 гига памяти и 32 гига места на диске. А в целом процесс установки крайне прост и описан в непривычно простом и удобном руководстве, сделанным в виде листаемой электронной книги:
https://ebooks.cisco.com/story/swc-sensor-install/
Сразу скажу, что у сенсора есть два интерфейса один служит для связи с консолью управления и также собирает на себе телеметрию, например NetFlow, а заодно и мониторит весь приходящий на него трафик. Второй же может работать в режиме захвата пакетов (promiscuous mode) и генерировать телеметрию по пойманному им трафику. В нашем конкретном случае мы использовали только первый интерфейс.

После установки сенсор бежит в облако, где размещена консоль это на самом деле AWS и выдает прекрасное сообщение:
{error:unknown identity,identity:185.190.117.34}

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



И через некоторое время сенсор окрашивается в зеленый цвет это означает, что сенсор установил соединение с консолью.
И, в общем то, на этом запуск системы завершен. Следующий шаг это добавление источников телеметрии, в дополнение к том, что сенсор слушает сам. Если мы хотим получать телеметрию по протоколу NetFlow, то крайне полезным является сайт https://configurenetflow.info/

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



И скопировать полученную информацию на наши сетевые устройства. Все система готова к работе! Вернее даже уже начала работать.
Кстати, примеры настроек Netflow с этого сайта можно использовать не только под Steathwatch, а под любой другой продукт, которому может пригодится такая телеметрия например Cisco Tetration, IBM QRadar и т. п.

Теперь можно заняться и мелким тюнингом системы. Сразу хочу сказать, что я очень люблю смотреть, как разные продукты компании Cisco по информационной безопасности сообщают мне обо всем происходящим на единую консоль мониторинга и реагирования Cisco SecureX. На самом деле SecureX штука крайне интересная и заслуживает отдельного описания. В двух словах это облачная система мониторинга информационной безопасности (SIEM), проведения расследований (Threat Hunting), расследования и реагирования на инциденты, а заодно еще и автоматизации процессов (SOAR). Очень рекомендую подробнее ознакомиться с этой системой, причем она прилагается по умолчанию к любому продукту Cisco по информационной безопасности. Ну и немного маркетинга по это теме вот тут: https://www.cisco.com/c/ru_ru/products/security/securex.html

Итак, первым делом и настроил такую интеграцию:



Заодно я настроил интеграцию и с нашей облачной платформой предоставления услуг безопасности Cisco Umbrella: http://personeltest.ru/aways/habr.com/ru/company/jetinfosystems/blog/529174/



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

После этого я создал себе новую консоль мониторинга в SecureX. Все это суммарно заняло минут 5, а может и того меньше. Пара картинок из моего SecureX -а ниже:





После этого я решил отключить неинтересные мне уведомления, и включить интересные. Для этого я вернулся в консоль SWC и пошел настраивать эти самые уведомления:



Сразу скажу, что по каждому из уведомлений можно посмотреть, что оно из себя представляет, сколько дней сбора телеметрической информации требуется для обнаружения соответствующей угрозы, и как она ложится, если ложится, на модель MITRE ATT&CK.
Количество обнаруживаемых угроз и связанных с ними уведомлений постоянно растет по мере развития самого по себе решения. Но мне про это думать особо не надо облако же, как что новое добавили, так это сразу в моем распоряжении.
Я отключил большую часть уведомлений, связанных с атаками на облака AWS, Azure, GCP, так как они в рамках данного полигона не использовались, и включил все уведомления, связанные с атаками на частные сети.
Также я могу поуправлять политиками мониторинга по разным подсетям, которые я хочу контролировать. Можно отдельно включить и мониторинг по особо интересующим нас странам:



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

Ну а теперь что же мы увидели?

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





Во-вторых, оценить масштабность мероприятия с какими же странами был наиболее активный обмен трафиком:



На самом деле есть и более удобный формат представления этих данных, но тут я решил показать больше детализации.
Итак, основными внешними, помимо России, пользователями полигона были США, Германия, Голландия, Ирландия, Англия, Франция, Финляндия, Канада, хотя определенное взаимодействие было практически со всеми странами, включая страны Южной Америки, Африки и Австралию:



Конечно, мы могли посмотреть, кому принадлежат увиденные адреса:



И при желании, спросить про них у других полезных аналитических источников:



Что позволило увидеть, например, активное взаимодействие с ресурсами компании Microsoft во многих странах.
Причем таблицу наиболее активных взаимодействий можно было увидеть и в виде динамической картинки соединений с возможностью ее более подробного анализа:



Но что-же все-таки мы собрали именно с точки зрения атак?
Об этом нам рассказывает список уведомлений, часть которого вы видите ниже:



Всего было идентифицировано 117 атак, подтвержденных множеством наблюдений (Observables) Мы видим тут и сетевые сканирования, и подозрительные длинные сессии, проблемы с SMB, некорректное использование сетевых портов и сервисов, странное поведение сетевых узлов, неожиданное изменение их поведения и прочие странности, которые должны насторожить специалиста по информационной безопасности.
По каждому интересующему нас событию мы можем получить подробную информацию, включая что оно из себя представляет, чем оно плохо и рекомендации по предотвращению. Пару таких интересный событий можно увидеть ниже это неожиданный запуск SSH сервера на рабочей станции Windows и использование нестандартного диапазона портов. Также можно обратить внимание на то, что, при настроенной интеграции можно прямо из описания события перейти в консоль проведения расследований SecureX Treat Response для подробного анализа данного инцидента:





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

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

Третий участники полигона тоже активно пользовались облачными сервисами, например сервисами компании Microsoft

Четвертый автоматизированный машинный анализ разнообразной сетевой телеметрии позволяет легко выявить инциденты ИБ, включая спланированную деятельность злоумышленников. И советую обратить внимание на то, что уже существует множество проработанных сценариев эффективного применения решения Cisco Stealthwatch для нужд информационной безопасности. Каждый из читателей может найти себе сценарий по душе вот тут: https://cisco.bravais.com/s/kCvJYJKyhuyQqAZSU6Xk.

Ну и маленький заключительный комментарий в этой статье я сознательно не стал подробно перечислять полученные списки адресов IP, доменов, детали взаимодействия и т. п., понимая, сколько усилий стоило компании Positive Technologies собрать данный полигон и надеясь, что он неоднократно пригодится им и нам и в дальнейшем. И облегчать жизнь будущим атакующим мы не будем.