Более подробное описание инцидента с безопасностью в мае 2019 года: отзывы о публикации в блоге
Мы только что опубликовали обновление об инциденте безопасности , произошедшем еще в мае 2019 года, с техническими подробностями о том, что произошло, как это произошло, и о мерах, которые мы применили, чтобы предотвратить повторение подобного инцидента. Вот пара отрывков из сообщения - сначала из введения:
12 мая 2019 г., примерно в 00:00 по Гринвичу, мы были предупреждены о неожиданном повышении привилегий для новой учетной записи несколькими членами сообщества. Пользователь, которого никто не узнал, получил доступ на уровне модератора и разработчика ко всем сайтам в сети Stack Exchange. Нашим немедленным ответом было отозвать привилегии и приостановить действие этой учетной записи, а затем запустить процесс выявления и аудита действий, которые привели к событию.
После первоначального обнаружения мы обнаружили, что повышение привилегий было лишь верхушкой айсберга, и атака фактически привела к утечке нашего исходного кода и непреднамеренному раскрытию PII (электронная почта, настоящее имя, IP-адреса) 184 пользователей. сети Stack Exchange (все они были уведомлены). К счастью, ни одна из баз данных - ни общедоступная (читай: контент Stack Exchange), ни частная (Teams, Talent или Enterprise) - не была извлечена. Кроме того, не было никаких свидетельств прямого доступа к нашей внутренней сетевой инфраструктуре, и злоумышленник никогда не имел доступа к данным в продуктах Teams, Talent или Enterprise.
И из последнего абзаца:
Этот инцидент напомнил нам о некоторых фундаментальных методах обеспечения безопасности, которым должен следовать каждый:
- Регистрируйте весь свой входящий трафик. Мы ведем журналы всех входящих подключений. Это позволило провести все наши исследования. Вы не можете исследовать то, что не ведете.
- Используйте 2FA. Оставшаяся система, которая все еще использует устаревшую аутентификацию, может быть вашей самой большой уязвимостью.
- Лучше охраняйте секреты. В TeamCity есть способ защиты секретов, но мы обнаружили, что не используем его постоянно. Объясните инженерам, что «секреты - это не просто пароли». Защитите SSH-ключи и строки подключения к базе данных. В случае сомнений защитите их. Если вы должны хранить секреты в репозитории Git, защитите их с помощью git-crypt или Blackbox .
- Проверяйте запросы клиентов. Чем более необычен запрос от клиента, тем важнее проверить, является ли запрос законным.
- Относитесь серьезно к отчетам о безопасности. Мы благодарны нашему сообществу за то, что наше сообщество так быстро сообщило о подозрительной активности. Спасибо!
В этом сообщении блога есть еще много всего - пожалуйста, не стесняйтесь задавать любые вопросы или комментарии, относящиеся к сообщению ниже, и мы сделаем все возможное, чтобы на них ответить. Мы не можем комментировать какие-либо другие подробности, связанные с атакой, помимо того, что включено в сообщение в блоге, в связи с продолжающимся расследованием.
Ответы
Вы можете прокомментировать намерения злоумышленников?
Похоже, они преследовали определенную цель / определенные (пользовательские) данные?
Или, возможно, это было больше похоже на «любопытного подростка», который тыкает палками, пытаясь понять, как далеко они могут забраться?
PS спасибо за открытость в этом вопросе, это очень ценно!
Эта строка:
Этот процесс поиска вещей (посещение вопросов) в сети Stack Exchange становится частым явлением и позволяет нам предвидеть и понимать методологию злоумышленника в ближайшие дни. (курсив мой)
звучит так, как будто в режиме реального времени , когда атака происходила, вы могли точно определить, что злоумышленник будет делать, основываясь на том, что он посетил в Stack Overflow, а не на том, что он сделал, криминально изучив то, что он просматривал (после атаки). Что вы имели в виду?
Несколько вопросов касались в основном злоумышленника:
- Что случилось с злоумышленником?
- Вы заблокировали их аккаунт?
- Связывался ли SE когда-либо с атакующим?
- Почему бы вам не раскрыть личность злоумышленника?
- Кто-нибудь еще пробовал использовать этот же метод атаки позже?
Был ли обнаруживаемый цикл сна на другом конце событий?
Отредактируйте, чтобы уточнить:
Узнав об атакующем, и поскольку вы следили за некоторыми из их действий по мере их развития, заметили ли вы что-нибудь, напоминающее биологический цикл, как повседневный, так и ретроспективно? Например: прием пищи (перерыв на 1-2 часа), сон (режим бездействия 8 часов), "короткий сон " (90 минут) и т. Д.?
На самом деле это не часть инцидента, а более общая озабоченность по поводу мер безопасности вокруг учетных записей сотрудников. В этом инциденте было много шагов, но последний из них - повышение привилегий учетной записи SE. Я могу представить гораздо более простые способы попытаться это сделать, чем получение административного доступа к серверу CI через экземпляр dev для выполнения SQL в производственной среде, и меня интересует, какие меры защиты и меры безопасности внедрил SE для защиты от более простых попыток получить доступ к учетной записи сотрудника.
Очевидно, что вы не можете поместить основные сайты SE за брандмауэр, поэтому они всегда будут открыты. И внутренний метод входа в систему SE не предоставляет никаких методов 2FA, что меня несколько беспокоит.
- защищены ли учетные записи сотрудников с помощью 2FA с помощью других средств (или других поставщиков входа)?
- Существуют ли какие-либо меры по обеспечению того, чтобы к учетным записям сотрудников не были привязаны частные адреса электронной почты или провайдеры входа в систему, которые могут быть менее безопасными и по-прежнему использоваться для получения писем для восстановления для получения доступа к учетной записи?
- есть ли мониторинг попыток входа в систему из новых источников для учетных записей сотрудников?
- есть ли дополнительные средства защиты для опасных инструментов сотрудников на случай, если кто-то получит доступ к текущему сеансу учетной записи сотрудника (например, снова потребовать пароль и / или токен 2FA при доступе к критически важным для безопасности инструментам)
Что-то вроде целевого фишинга, вероятно, все еще остается одним из наиболее вероятных способов получить доступ к учетной записи сотрудника.
Примерно в то же время, когда произошел инцидент с безопасностью, несколько дней спустя некоторые пользователи начали замечать, что OneBoxing в Twitter больше не работает . Впоследствии в феврале следующего года сотрудник подтвердил, что он действительно был намеренно отключен из-за необходимости «закрыть некоторые бреши» в результате этого инцидента с безопасностью.
Можем ли мы получить полное объяснение того, почему в результате этого инцидента с безопасностью пришлось отключить Twitter Onebox в чате? В сообщении в блоге, опубликованном в то время, говорилось, что «другие потенциальные векторы» были закрыты, а в сообщении сотрудников от февраля 2020 года, которое я привел выше, говорилось, что функция OneBoxing в Twitter «использовала один из закрытых нами пробелов». Что это было за штуку и какую угрозу безопасности она создавала?
Наконец, есть ли способ снова реализовать эту функцию безопасным способом? В августе 2020 года, через несколько месяцев после сообщения персонала выше, отчет об ошибке, поданный в то время, был помечен другим сотрудником как статус по дизайну . Будет ли рассмотрен запрос функции на обратное изменение дизайна (безопасным способом), или это невозможно сделать, не открывая вектор атаки?
Я бы отметил, что типы параметров «пароль» в TeamCity не считаются безопасными:
Значение пароля хранится в файлах конфигурации в каталоге данных TeamCity. В зависимости от настроек шифрования сервера значение либо зашифровывается, либо зашифровывается с помощью специального ключа.
Значение журнала сборки скрыто с помощью простого алгоритма поиска и замены, поэтому, если у вас есть простой пароль «123», все вхождения «123» будут заменены, потенциально раскрывая пароль. Установка для параметра типа пароля не гарантирует, что исходное значение не может быть получено. Его может получить любой администратор проекта, а любой разработчик, который может изменить сценарий сборки, потенциально может написать вредоносный код для получения пароля.
Почему волшебная ссылка в dev, доступная для просмотра CM (предположительно только в dev), была настоящей волшебной ссылкой?
Это действительно потрясающий отчет об инциденте! Один из лучших, что я читал.
Спасибо, Стэк, за то, что он сделал это общедоступным, и Дину за отличную запись!
Мне просто любопытно узнать несколько вещей:
- Каков размер группы реагирования на инциденты?
- Соблюдались ли какие-то конкретные протоколы во время расследования?
- Какой ключевой фактор был задействован для привлечения внешнего поставщика средств безопасности? Какие моменты учитывались при выборе конкретного поставщика?
- Какие уроки были извлечены из опыта поставщика внешней системы безопасности? Отличается ли их процесс аудита (эффективный / неэффективный) от того, который уже использовался командой?
Статья дает хорошее представление обо всей архитектуре Stack и процессах разработки. Было бы здорово прочитать более подробное прочтение или ссылку, если уже есть статья об этом.
В разделе «Совет другим»:
Регистрируйте весь свой входящий трафик. Мы ведем журналы всех входящих подключений. Это позволило провести все наши исследования. Вы не можете исследовать то, что не ведете.
Как такая загруженная сеть, как Stack Exchange, может регистрировать весь входящий трафик? Это записи веб-сервера журналов, IP-потоки или полные TCP-сеансы?
Я мог записывать большинство записей и попыток подключения в моей крошечной сети, но я понятия не имею, как это делает такая большая сеть.
Не могли бы вы более четко объяснить, что означает «общедоступная собственность» в приведенной ниже цитате?
у нас есть база данных, содержащая журнал всего трафика к нашим общедоступным объектам