В 2017 году команда Навального открыла штабы по всей России. Сначала они были предвыборными, а затем стали региональными политическими центрами. Опасная для Путина, сеть штабов подвергалась непрерывным и усиливающимся репрессиям: обыски, аресты счетов и сотрудников, физическое насилие, угрозы. В 2021 году власти выдумали дело об экстремизме, и штабы пришлось закрыть — для защиты всех участников.
В декабре 2022 года наша команда возобновила работу штабов Навального — теперь в виде подпольной организации. Нужно было разработать средства для коммуникации и коллаборации координаторов и активистов в онлайне. Осознавая риски для сторонников и активистов, находящихся в России, мы подошли к вопросу обеспечения их безопасности максимально серьёзно. Мы строим нашу систему безопасности, не полагаясь на принцип security via obscurity, поэтому, рассказывая о ней, мы не подвергаем ее значительным дополнительным рискам, а напротив — даем возможность специалистам понять уровень ее безопасности и дать свою оценку качества нашей работы.
Описание системы
Сайт Штабов Навального представляет из себя личный кабинет. Активисты могут зарегистрироваться в нем по профессиональному и территориальному признаку. На базе платформы публикуются задачи, которые назначаются в соответствии со специальностью и интересами участников, имеется возможность связи с координатором. Пользователь может заработать баллы за выполненные задачи, достигнуть определенных уровней и, например, приобрести за это аватары. В августе 2023 года на базе платформы вышло большое обновление: запущен мессенджер, обеспечивающий анонимную коммуникацию участников в рамках задачи.
Моделирование угроз и нарушителей
Разработку системы мы начали с моделирования угроз — определения целей, которые могут ставить перед собой злоумышленники. Как главную угрозу мы определили идентификацию участников штабов. Вторичные угрозы — блокировка доступа пользователей к сервису, компрометация секретных проектов и планов, компрометация программного обеспечения нашего сервиса и получение через него доступа к другим сервисам.
Вторым этапом мы произвели моделирование нарушителя — прикинули, кто может быть нашим злоумышленником (очевидно, это сотрудники коррумпированных правоохранительных органов и спецслужб, органов обеспечения цензуры в интернете), и какие у них есть возможности по достижению их целей. Мы рассматривали четыре основных вектора атак: на серверы (хакерство), на активистов (обыски), на сотрудников (внедрение, подкуп, угрозы) и самое простое: «товарищ майор» в чате.
Моделирование угроз и нарушителей — это фундамент обеспечения информационной безопасности. Поставив безопасность активистов во главу угла, мы были вынуждены часто принимать продуктовые решения в ущерб юзабилити, удержанию пользователей и т.д. Например, мы не могли позволить себе сделать удобное приложение для телефона с крутым обходом блокировок, как в Умном голосовании, с уведомлениями, возвращающими неактивных пользователей, — ведь при досмотре телефона это приложение будет легко найти.
Когда мы определили, с какими угрозами надо бороться, мы начали планировать эшелонированную систему безопасности с несколькими периметрами защиты. Каждый раз, когда мы возводили очередную стену: «тут у нас аутентификация», «тут у нас файрвол», — мы думали: «Хорошо, а что будет, если эта защита будет взломана? Что сможет сделать злоумышленник?» — и придумывали, как сделать, чтобы этого было недостаточно для успешной атаки.
Tor
Одним из ключевых решений стало размещение сайта в dark web. Обычные браузеры не только раскрывают много информации о пользователе, например метаданные с типом и именем устройства, IP-адрес пользователя, но и оставляют много следов на устройстве — историю посещений, кэши. Нами было принято решение для подключения к штабам использовать исключительно браузер Tor, который ничего из этого не делает и предпринимает еще много других мер для защиты пользователей. Доказать причастность пользователя к деятельности организации, в случае изъятия устройства, таким образом проблематично — видно, что приложение Tor установлено, но для чего оно использовалось — непонятно. И тут на ум приходит интересный факт: именно Tor использовал Эдвард Сноуден для коммуникации с журналистами при сливе секретных данных АНБ. Кстати говоря, Tor разрабатывает некоммерческая организация, и если у вас есть возможность, поддержите коллег финансово — donate.torproject.org.
С помощью данного браузера можно спрятаться и от Роскомнадзора. С момента введения повсеместного DPI на большинстве провайдеров в России сохранить в тайне доступ к сайтам на HTTPS стало гораздо сложнее. В популярных браузерах до сих пор отсутствует возможность использования протокола ECH, и, хотя Роскомнадзор не знает, какая именно информация передавалась между пользователем и сайтом, он видит, какой пользователь на какие домены обращался. Поэтому нами было принято решение разместить сайт на onion-сервере, обратиться к которому из обычного браузера нельзя. Таким образом пользователи даже случайно не смогут зайти на сайт и «засветиться» в логах DPI.
Персональные данные
Для того чтобы зарегистрироваться в системе, активисту не нужно предоставлять свои личные данные. Мы видим активистов только под их псевдонимами, не зная и не пытаясь узнать их реальные личности. У каждого активиста есть репутация, которая измеряется в баллах. Баллы выдаются по мере выполнения заданий и делают активиста более доверенным — ему можно поручать более секретные и серьёзные задания. Таким образом, если «товарищ майор» захочет узнать больше о секретных проектах, ему придется выполнять больше простых заданий — расклеивать листовки и рисовать протестные граффити. Пусть наконец сделает что-нибудь полезное!
Для регистрации в системе штабов участнику необходимо придумать свой псевдоним (логин), достаточный по сложности пароль и коротко описать свои профессиональные навыки в свободной форме.
Реальных имён, электронных почт и телефонов не требуется. Все регистрации проходят дополнительную модерацию, после которой пользователю открывается доступ к полному функционалу системы. Модерация также защищает от флуда регистрациями. Поскольку в Tor клиенты анонимны, это ровно так же защищает от нас и самих злоумышленников, которые могут ботами заполнить миллионы анкет, а потом заспамить систему накрученными сообщениями. Чтобы это не повлияло на работу сайта, модераторы проверяют анкеты, отсеивая мусорные, размечают активистов по их профессиональным интересам (программисты, дизайнеры, юристы и т.д.) и только после этого пропускают их на сайт.
Поэтому, пожалуйста, отнеситесь с пониманием к тому, что нам нужно время на проверку ваших анкет. Мы ставим цель — 1-3 суток, но в случае атак оно может и затянуться.
Риски от инсайдеров
Инсайдеры — это сотрудники штабов: координаторы, модераторы, программисты, системные администраторы и т.д. У них по роду деятельности есть дополнительный доступ к системе, которым могут воспользоваться злоумышленники. Мы доверяем нашим сотрудникам, но всё равно предпринимаем меры на случай их компрометации — ведь сотрудник может не только стать злоумышленником по своей воле (по идейным соображениям или быть подкупленным), но и быть взломанным (фишинг никто не отменял) или принужденным к сотрудничеству, например, через давление на родственников.
Для того чтобы защититься от угроз со стороны инсайдеров, мы предпринимаем специальные меры. Во-первых, мы всегда руководствуемся принципом минимальных привилегий — у наших сотрудников нет лишнего доступа, который не нужен им для выполнения прямых обязанностей. Например, у программистов есть доступ к репозиторию с кодом, но нет доступа к серверам. У тестеров есть доступ к тестовому окружению, но нет доступа к продакшну. Во-вторых, мы используем несколько периметров и для защиты от угроз инсайдеров. Скажем, даже если системные администраторы сделают дамп базы данных или скопируют все файлы из хранилища загруженных файлов, они не смогут их расшифровать.
Шифрование
Все чувствительные поля базы данных и все загружаемые на сервер файлы зашифрованы. Мы используем симметричное шифрование с аутентификацией (AEAD), защищающее также от подмены зашифрованного содержимого. Ключи шифрования хранятся не в приложении, а в облачной системе управления ключами Cloud KMS от Google. Файлы шифруются при помощи envelope encryption — каждый файл шифруется своим эфемерным ключом, который уже шифруется KMS.
У ключей Cloud KMS запрещён экспорт. Они хранятся в отдельном проекте Google Cloud, доступ к которому есть только у самых доверенных администраторов. Доступ к шифрованию и расшифрованию этими ключами выдан только сервис-аккаунтам, связанным с workload identity сервисов, которые должны работать с базой данных.
Такой подход к шифрованию минимизирует периметр защиты данных. Например, даже если администраторы будут делать запросы к базе данных, они не смогут увидеть содержимое. То же самое касается и бэкапов. Более того, даже системы, делающие бэкапы, не должны расшифровывать данные. Всё бэкапится в зашифрованном виде, и для того, чтобы украсть данные, надо ещё и получить доступ к ключам KMS, что сильно усложняет задачу компрометации данных.
Атаки на приложение
Если будет скомпрометировано само приложение через какую-нибудь техническую уязвимость, злоумышленник может получить доступ ко всему, к чему имеет доступ приложение. Это самый ценный актив системы, и успешная атака способна нанести очень большой ущерб. Чтобы его минимизировать, мы во-первых, не храним никаких персональных данных пользователей, чтобы даже в случае перехвата всех данных было максимально сложно идентифицировать активистов, а во-вторых мы стараемся минимизировать возможности злоумышленника закрепиться в системе.
Поскольку серверы работают на GKE, они являются виртуальными машинами, которые периодически обновляются и заменяются новыми. В качестве базового образа используется COS (Container-optimized OS) от Google, представляющий из себя защищенную Linux-систему. Для аутентификации сервисов мы не используем экспортируемые JSON-ключи сервис-аккаунтов, которые можно украсть и использовать длительное время. Вместо этого применяется GKE Workload Identity, которая дает приложениям только временные токены со сроком жизни несколько минут.
Деплой
Вся инфраструктура разделена на две части — доверенную и недоверенную. В недоверенной работает тестовое окружение, в котором нет никаких секретных данных. Оно используется для разработки и тестирования. В доверенной напротив — работает всё, у чего есть доступ к защищаемым данным.
Сборкой кода приложения и контейнеров, занимаются специальные защищенные виртуальные машины (раннеры), работающие в изолированной от других проектов и инженеров среде. Доступ к проекту, в котором работают эти раннеры, есть у ограниченного количества доверенных инженеров, и то только на случай их поломки. У сервис-аккаунтов этих машин есть административный доступ к продакшну, что позволяет использовать подход gitops, в котором история всех изменений продакшна ведется в двух местах — в логах git и в аудит-логах Google Cloud, что позволит если не предотвратить атаки полностью, то хотя бы проследить их ретроактивно.
Мы используем недоверенную среду для сборки кода из незащищенных веток GitLab. Это ветки, куда любой разработчик может делать свои коммиты для ревью или выкатки на тестовые серверы. Даже если разработчик закоммитит что-то вредоносное, что скомпрометирует сервер сборки, это не даст ему никакого доступа к продакшну. После ревью другим сотрудником и мержа ветки в основную продакшн-ветку, код собирается уже в доверенной среде и деплоится в прод.
Для экономного расходования средств и достижения плотной загрузки серверов мы используем Kubernetes, а для системы сборки — собственное решение включения виртуальных машин раннеров только в тот момент, когда они нужны. Система управления раннерами также работает в защищенной среде.
DoS-атаки
При запуске системы штабов команда рассчитывала, что, в отличие от открытого интернета, в Tor злоумышленникам будет накладно устраивать DoS-атаки. Но атакующие не заставили себя долго ждать, и наш мониторинг вскоре зафиксировал резкое увеличение нагрузки на серверы. Мы были готовы к фильтрации трафика на уровне HTTP, и поначалу этого было достаточно, но злоумышленники стали поступать хитрее — они создавали множество маршрутов и нагружали наш клиент Tor.
Здесь надо немного объяснить, как работают onion-сайты. В отличие от обычного интернета, где клиенты подключаются к серверам напрямую, в Tor и клиенты, и серверы, подключаются к специальным узлам дискавери, которые "знакомят" их друг с другом, а после этого для передачи данных и те, и другие подключаются к узлам рандеву, устанавливают туннели с обеих сторон, и сервер рандеву замыкает их в единую цепь, по которой потом уже будет ходить обычный HTTP.
В нашем случае злоумышленники отправляли огромное количество запросов на установку соединений, вынуждая наш сервер заниматься установкой соединений с серверами рандеву и сопутствующей дорогостоящей асимметричной криптографией. Далее они даже и не пытались ничего отправлять по этим туннелям, и атака даже не доходила до HTTP.
Обычные средства защиты от DoS-атак типа определения источников и их временной блокировки в Tor невозможны, поскольку мы никак не можем идентифицировать клиентов. С этой целью было разработано специальное решение. Дело в том, что обычный onion-сервер не умеет масштабироваться. Когда запускается Tor, он подключается к сети и публикует дескриптор сервиса, указывающий на него единственного. Если запустить второй инстанс того же сервера, он затрет дескрипторы первого, и они вместе работать не смогут.
В качестве решения проблемы мы используем onion balance - сторонний инструмент, который позволяет запустить несколько onion-серверов (каждый из которых работает на своём случайном onion-адресе), а затем загрузить из сети их дескрипторы, объединить в единый дескриптор и опубликовать уже в качестве дескриптора основного onion-сайта. Это позволяет распределять нагрузку на серверы и выдерживать пропорционально больший трафик.
Так выглядит архитектура нашего решения:
Tor-balancer - это обёртка над onionbalance, которая обращается в наш кластер, получает список здоровых и активных инстансов тор-сервера, генерирует конфиг для onionbalance и запускает его. Если набор активных инстансов меняется (например, какой-то отключился, или новый включился), то конфиг регенерируется, и onionbalance перезапускается.
Tor-frontend управляет обычным onion-сервером. Он генерирует случайный onion-адрес, запускает onion-сервер на этом адресе, ждёт, пока он успешно зарегистрируется и станет доступным в сети тор, а потом начинает отвечать на HTTP-запросы собственным onion-адресом. Именно обращаясь к этому HTTP, tor-balancer может узнать, какие индивидуальные onion-адреса надо использовать для компиляции общего большого дескриптора.
Клиент устанавливает маршрут (circuit) с сервером один раз. Обычно это медленная и «дорогая» операция с точки зрения ресурсозатратности, а дальше может устанавливать любое количество логических соединений в рамках одного circuit — это уже быстро и дешево. Для борьбы с атаками настроено правило: если какой-то клиент внутри своего circuit установил большое количество соединений, такой circuit либо разрывается совсем или замедляется rate limit’ом на ingress-nginx. Это позволяет эффективно бороться с атаками.
Таким образом мы распределяем нагрузку между onion-адресами с помощью «дискавери» дескрипторов и не даем злоумышленнику нагрузить один конкретный адрес и завалить систему.
Вторым уровнем защиты от атак был отказ от конфиденциальности сервера. Поскольку у нас не дарк маркет и нам не надо прятать сервер (мы и так с гордостью говорим, чей он), серверу нет никакой нужды устанавливать тройное соединение с точкой рандеву. Вместо этого мы используем опцию Tor, которая позволяет нашему серверу устанавливать прямое соединение. Это позволило нам резко сократить объем асимметричной криптографии, который надо делать на сервере, и в несколько раз сократить нагрузку на сервер. Конфиденциальность клиентов при этом никак не страдает, а серверу — легче.
Больше успешных DoS-атак на сервер не было.
Координаторы
В системе штабов любой участник может написать сообщение координатору и получить ответ. Например, он может сообщить о выполненном задании или задать вопрос.
Для работы координаторов мы используем специальную административную панель на базе фреймворка Django. Его функционала более чем достаточно для удобного разбора заявок на регистрацию, постановки задач и оценки их выполнения и общения с активистами в личном чате. Модераторы не видят реальных логинов пользователей, но, чтобы они могли как-то идентифицировать их, модераторы видят пользователей под еще одним уровнем псевдонимов — для них пользователи обозначены обезличенными порядковыми номерами. Для всех администраторов включено принудительное правило двухфакторной аутентификации, действует разграничение доступа по направлениям работы, и доступ включен только из-под служебного VPN. Ведется журнал действий, чтобы всегда можно было установить, какой сотрудник каким доступом пользовался.
Координаторы команды ставят задачи, следят за их исполнением, оценивают, поддерживают связь в личном чате с пользователем. Это требует человеческих ресурсов и создает проблему отсутствия быстрой обратной связи. Поэтому на базе платформы было решено запустить публичные групповые чаты для взаимодействия активистов друг с другом напрямую в рамках задачи.
Чаты
По функционалу и дизайну, интерфейс чатов приближен к ленте мессенджера типа Telegram. В нем можно переключаться между чатами, читать, писать и удалять сообщения, отвечать на чужие сообщения и чистить историю.
Чаты работают поверх вебсокетов внутри Tor. Каждое сообщение чата зашифровано при помощи Cloud KMS, и чтобы избежать избыточного количества запросов к KMS, в системе реализован локальный кеш расшифрованных сообщений в памяти приложения.
Сообщения в чате можно удалять вручную, а по прошествии времени они удаляются автоматически.
Для защиты чатов от спама сообщениями, в системе настроено ограничение на количество отправляемых сообщений в единицу времени, после которого сообщения перестанут приниматься. Мы также проводили нагрузочное тестирование чатов различными сценариями, чтобы убедиться, что сервер выдерживает расчетную нагрузку.
Мы предприняли меры по защите пользователей чата от их идентификации по метаданным. Дело в том, что злоумышленники, имеющие доступ к СОРМ, видят, когда пользователи пользуются тором. Они не знают, что именно пользователи там делают, но сам факт скрыть довольно сложно. Они могут подключиться к популярному чату в системе штабов, отправить какое-то большое сообщение заведомо известной длины и по данным СОРМ посмотреть, какие из пользователей по всей России в тот же самый момент получили сообщение той же самой длины. Сигнал зашумлен, идентификация будет нечеткой, но после нескольких таких сообщений они смогут достоверно выяснить, кто из россиян сидел в это время в чате. Чтобы сильно затруднить возможность такой атаки, мы рандомизируем размер сообщений, отправляемых пользователям, и задержки времени между ними, чтобы размыть сигнал и сделать его ниже уровня шума.
Анонимность
Самый глубокий уровень нашей обороны — это анонимность. Даже если все предыдущие уровни падут — серверы будут взломаны, координаторы куплены, а админы запытаны, — все, что получит злоумышленник, — это историю общения анонимов с анонимами, прямо не раскрывающую никаких идентифицирующих данных.
Но даже без всякого взлома, общедоступные чаты также подразумевают наличие в них спамеров, провокаторов и прочих злоумышленников. Поэтому мы предпринимаем соответствующие меры защиты.
Во-первых, за каждым чатом закрепляется модератор. Он видит чуть больше, чем обычный пользователь. Общую ленту, в которую падает поток всех сообщений, которые он модерирует, и ленту нарушений — жалобы от других пользователей. В этих административных чатах модератор имеет функционал удаления сообщений и блокировки пользователей - на определенное время или насовсем. При этом модератором не обязательно должен быть администратор с доступом в отдельную панель. Это обычный пользователь, зарегистрированный в личном кабинете, только с повышенными привилегиями.
А во-вторых, чтобы «товарищ майор» не мог, долгое время наблюдая за чатом, собрать достаточно информации на пользователя, чтобы идентифицировать его по косвенным данным, мы ввели еще один принудительный уровень псевдонимизации. Каждому пользователю в чате назначается случайное имя, отличное от того, которое он использует для основного входа в систему — именно его и видят другие участники. Имена пользователей, с помощью которых участники штабов входят в личный кабинет, нигде не фигурируют. Мы заранее подготовили комбинации из прилагательных и существительных, чтобы покрыть всех участников забавными и уникальными именами. «Пятнистый Гиппогриф» или «Милый Кот» — такими видят пользователи друг друга. Доступна функция смены имени на другое, но тоже случайное.
Бот Федор, постоянно присутствующий в чате, напоминает участникам о правилах безопасности - например не рассказывать ничего про свою реальную жизнь или регулярно менять свой ник, чтобы разорвать связь с собой прошлым. Он выглядит, как обычный участник чата, берет случайное сообщение из своей базы знаний и отправляет в чат.
Загрузка файлов
Мессенджер — это не только обмен короткими сообщениями, но и загрузка изображений. Мы позаботились о том, чтобы их метаданные автоматически очищались при загрузке в общий чат, и чтобы никто не мог узнать, кем, когда и где они были созданы.
В качестве решения для очистки метаданных был выбран exiftool. Он поддерживает наибольшее количество форматов и прост в использовании. Однако важно обратить внимание на то, что exiftool использует множество кодеков, написанных на С — языке, на котором очень легко написать уязвимый код, дающий возможность удаленного исполнения кода злоумышленником.
Чтобы скомпрометированный exiftool не привел к компрометации всего приложения, мы запускаем его отдельным микросервисом в изолированной песочнице, чтобы при загрузке вредоносного файла, хакер не мог бы получить доступ к основному сервису либо закрепиться на сервере и перехватывать файлы других пользователей. Мы запускаем этот микросервис в бессерверной среде исполнения Cloud Functions от Google, благодаря которой он живет короткое время и на уровне сети не имеет доступа к базе данных и другим микросервисам.
В первый день работы чатов террористы тестеры подбросили нам настоящую zip-бомбу в виде картинки из миллионов пустых пикселей. Zip-бомба — это архив на миллиарды нулей которые сжали компрессором до очень компактного размера. Если получатель пытается его распаковать, у него просто напросто кончится или память, или диск, или и то, и другое.
_decompression_bomb_check
raise DecompressionBombError(
PIL.Image.DecompressionBombError: Image size (50625000000 pixels) exceeds limit of *N* pixels, could be decompression bomb DOS attack.
К счастью, бомба так и не разорвалась - сработала защита в библиотеке. Но даже если бы она сработала, основному сервису это бы никак не повредило.
Заключение
Мы создали уникальный инструмент, дающий возможность сторонникам и активистам в России более эффективно бороться с режимом, поддерживая связь между собой и не боясь быть раскрытыми. А оплачено все это за счет пожертвований наших активистов, за что им огромное спасибо! Вы тоже можете присоединиться и поддержать Штабы прямо сейчас:
Патреон Штабов: https://www.patreon.com/shtab_navalny
Вы можете пожертвовать нам акции компаний через сайт DonateStock. Это быстро и удобно, к тому же площадка иногда удваивает сумму. https://donatestock.com/rikolto-ltd
Криптокошельки ФБК (ACF):
Bitcoin
3QzYvaRFY6bakFBW4YBRrzmwzTnfZcaA6E
Ethereum
0x314aC71aEB2feC4D60Cc50Eb46e64980a27F2680
Monero
42e1hkdsTHUUWSM24jVgLTH4MDJPMbNS1XDt7rK36dTBSKweohz9FSWKAAoqHLN9nSVgocnSnkR2AaLMWtsrmAoQGPdWSE1
Zcash (Z-адрес)
zs1l8ztrqpk0qyn2hyte3x9m568taz64jyc90ppfskylqgawxw7r3gq453yn6hk9swq2l0dq9yal0a
USDT (ВЕР-20)
0x9A4B20a7909Af03dd8B4f28A419840F9715E1F73
Вы можете оформить корпоративное пожертвование, чтобы помочь Штабам Навального работать. Это можно сделать через платформу Benevity.
Benevity — программа для корпоративных пожертвований, которую используют более 900 компаний: Apple, Google, Twitter, Facebook и другие. Если вы работаете в крупной компании, скорее всего, на вашем корпоративном сайте есть раздел Employee Giving. Там в поисковой строке вбейте Anti-Corruption Foundation и введите сумму. Плюс системы Benevity в том, что иногда корпорации в несколько раз увеличивают размер сделанных через нее пожертвований.
Top comments (0)