Shell в студию или как Apache.org хакнули
Те, кто интересуется информационной безопасностью, а конкретно web-безопасностью, скорее всего, в курсе того, что произошло не так уж давно c серверами Apache.org. Ну, собственно, нетрудно догадаться, что раз я начал говорить про безопасность, то на серверы были произведены атаки, и они увенчались успехом, хотя и не таким, каким его хотели видеть злоумышленники, полагаю.
Так вот, естественно, после этого дела от Apache Software Foundation последовал отчет о том, что же случилось и каковы были события в самом центре. Для начала хочу сказать, что виной всему была уязвимость в системе безопасности, она привела к временному отключению некоторых сервисов. Если кому-то интересно еще разок прочесть или он пропустил сей инцидент и сейчас слышит о нем впервые, то вот вам линк
http://www.xakep.ru/post/49304/default.asp
Уже больше месяца все сервисы восстановлены и работают в обычном режиме, только сотрудникам известно, каково было поднимать все с колен. Ну, в общем-то, теперь я вам расскажу о том, что же предприняли специалисты Apache Software Foundation, а также что оказалось эффективным, что оказалось причиной и какие профилактические меры предприняты на теперешний момент.
Как оказалось, сервер, на котором работал apachecon.com (dv35.apachecon.com), был скомпрометирован. Функционировал он под управлением CentOS (практически RedHat Enterprise, немного урезанный), и специалисты считают, что злоумышленники использовали эксплойты для повышения локальных привилегий, которые были пропатчены в RHSA-2009-1222 (https://rhn.redhat.com/errata/RHSA-2009-1222.html).
Владельцем скомпрометированного серва является компания, которая организовывает конференцию ApacheCon, а не Apache Software Foundation, но члены AFT (Apache Infrastructure Team) имеют на этом сервере аккаунты, в том числе и аккаунт для резервного копирования.
Злоумышленники пробовали использовать пароли, которые получили на хосте ApacheCon для авторизации на производственных серверах, но попытки не увенчались успехом. Позднее они воспользовались SSH-ключом, который использовался для аккаунта резервного копирования, и получили доступ к people.apache.org (minotaur.apache.org). Доступ был не особо вкусным, т.к. привилегий у него не было, этот аккаунт использовался для резервного копирования ресурса ApacheCon.
minotaur.apache.org, в свою очередь, трудился под управлением FreeBSD 7-STABLE и был shell account-сервером, который выступает в роли подготовительного сервера для сети зеркал. Угрозы исходникам взлом этой машины не принес, поскольку код контрольных версий на ней не хранился.
Итак, получив шелл к указанному выше серверу, взломщики залили в каталоги некоторых сайтов CGI-скрипты, они скопировались на сервер eos.apache.org, который является производственным. Такое было реализовано из-за процедуры rsync, которая является регулярной. Находясь на сервере eos.apache.org, скрипты стали доступны извне и были необходимы для получения удаленных шеллов. Команды, в свою очередь, посылались при помощи HTTP POST запросов. Защита от подобных атак на производственных серверах Apache Software Foundation затруднена тем, что у них включена опция ExecCGI, которая позволяет при динамической генерации страниц выбирать ближайшее расположенное зеркало по отношению к пользователю.
Как только было замечено наличие CGI-скриптов, реакция от AFT последовала незамедлительно. Было решено отключить все серверы, которые могли быть атакованы. А трафик с этих серверов был перенаправлен на один, проверенный. Естественно, на ресурсах было вывешено объявление, уведомляющее народ, что AFT в курсе происходящего.
Постепенно специалисты Apache Software Foundation «подняли» все серверы в однопользовательском режиме. А после анализа стало ясно, что европейский сервер aurora.apache.org так и не пострадал от атаки. Все очень просто: несмотря на то, что скрипты на него были скопированы тоже, они ни разу не запустились, сервер не был включен в DNS-ротацию :).
Европейский сервер работает под управлением Solaris 10, и его безопасная конфигурация была быстро восстановлена из ZFS-бэкапов, которые были сделаны за день до того, как появились CGI-скрипты. После этого специалисты начали запускать остальные ресурсы, не переставая анализировать причины произошедшего.
Теперь давайте рассмотрим то, что оказалось эффективным, что сыграло отрицательную роль в истории и какие меры предприняты сейчас.
Было эффективным
. Европейский сервер быстро вернулся к рабочему состоянию благодаря использованию ZFS-снимков.
. Большое количество серверов в двух точках расположения позволило запустить сервисы с зеркал, не меняя их географического положения, и продолжать работать с поврежденными серверами.
. Разнообразие в использованных операционных системах на машинах, подвергшихся атаке (Linux/CentOS i386, FreeBSD-7 amd_64 и Solaris 10 на sparc), притормозило злоумышленников в плане поднятия привилегий.
Отрицательная роль
. Использование SSH-ключей упростило атаку. Причиной тому была недостаточно отработанная система их использования, как обычно, понадеялись на «авось не зацепит».
. Использование процедуры rsync позволило взломщикам незаметно скопировать скрипты в каталоги сайтов с people.apache.org.
. Возможность выполнения CGI на любом хосте, хотя в большинстве случаев в этом нужды не было, позволило заразить их без проблем.
. Нехватка логов с хоста ApacheCon не позволила целиком и полностью восстановить картину действия атакующих.
Ну и в конце приведу цитату из отчета.
Предпринятые меры
После вторжения мы проводим ряд изменений для того, чтобы обезопасить нашу инфраструктуру от подобных инцидентов в будущем. Вот список проводимых нами изменений:
. Требование ко всем пользователям с повышенными привилегиями использовать OPIE for sudo на определенных машинах. Это требование уже действует в некоторых местах, однако теперь данная практика будет обязательно расширена.
. Повторное создание и использование SSH, одного для каждого хоста, для использования при резервном копировании. Также – обязательное использование опций from="" и command="" в файле авторизованных ключей на сервере назначения резервного копирования. В совокупности с ограничениями, позволяющими устанавливать соединения только тем машинам, которые действительно создают резервные копии данных, данная мера позволит предотвратить возможность установления SSH-соединений сторонними машинами.
. Строка command="" в файле авторизованных ключей теперь является явно заданной и позволяет осуществлять только односторонний rsync-трафик.
. Новые ключи сгенерированы для всех хостов, минимальная длина ключа при этом– 4096 бит.
. Виртуальная машина, на которой была расположена старая версия сайта apachecon.com, остается отключенной и ожидает дальнейшего детального анализа. Сайт apachecon.com вновь развернут на новой виртуальной машине, у нового провайдера и под другой операционной системой.
. Мы рассматриваем возможность отключения поддержки CGI на большинстве систем с веб-сайтами. Это привело к созданию нового модуля httpd, который будет управлять предоставлением зеркал для загрузок.
. Метод, согласно которому большинство наших публичных веб-сайтов разворачивается на наших производственных серверах, также будет изменен, этот процесс станет более автоматизированным. Мы надеемся в течение ближайших нескольких недель перейти на использование системы,
основанной на SvnSubPub / SvnWcSub.
. Мы вновь внедрим на всех машинах практику бана по IP-адресу после нескольких неудачных попыток авторизации.
. Было выдвинуто предложение по введению системы централизованного журналирования. Эта система включит в себя все логи и возможно также такие сервисы, как smtpd и httpd.
Вот такая вот история о том, как Apache.org пришлось туговато. С другой стороны, это очень и очень хорошо, потому как на их опыте все продуманные админы давно предприняли некоторые меры предосторожности, чтобы не выглядеть так же бледно как парни из AFT. На этом все, следите за логами и не оставляйте серверы без присмотра ;).
По материалам https://blogs.apache.org/infra/entry/apache_org_downtime_report
Евгений Кучук, q@sa-sec.org
Так вот, естественно, после этого дела от Apache Software Foundation последовал отчет о том, что же случилось и каковы были события в самом центре. Для начала хочу сказать, что виной всему была уязвимость в системе безопасности, она привела к временному отключению некоторых сервисов. Если кому-то интересно еще разок прочесть или он пропустил сей инцидент и сейчас слышит о нем впервые, то вот вам линк
http://www.xakep.ru/post/49304/default.asp
Уже больше месяца все сервисы восстановлены и работают в обычном режиме, только сотрудникам известно, каково было поднимать все с колен. Ну, в общем-то, теперь я вам расскажу о том, что же предприняли специалисты Apache Software Foundation, а также что оказалось эффективным, что оказалось причиной и какие профилактические меры предприняты на теперешний момент.
Как оказалось, сервер, на котором работал apachecon.com (dv35.apachecon.com), был скомпрометирован. Функционировал он под управлением CentOS (практически RedHat Enterprise, немного урезанный), и специалисты считают, что злоумышленники использовали эксплойты для повышения локальных привилегий, которые были пропатчены в RHSA-2009-1222 (https://rhn.redhat.com/errata/RHSA-2009-1222.html).
Владельцем скомпрометированного серва является компания, которая организовывает конференцию ApacheCon, а не Apache Software Foundation, но члены AFT (Apache Infrastructure Team) имеют на этом сервере аккаунты, в том числе и аккаунт для резервного копирования.
Злоумышленники пробовали использовать пароли, которые получили на хосте ApacheCon для авторизации на производственных серверах, но попытки не увенчались успехом. Позднее они воспользовались SSH-ключом, который использовался для аккаунта резервного копирования, и получили доступ к people.apache.org (minotaur.apache.org). Доступ был не особо вкусным, т.к. привилегий у него не было, этот аккаунт использовался для резервного копирования ресурса ApacheCon.
minotaur.apache.org, в свою очередь, трудился под управлением FreeBSD 7-STABLE и был shell account-сервером, который выступает в роли подготовительного сервера для сети зеркал. Угрозы исходникам взлом этой машины не принес, поскольку код контрольных версий на ней не хранился.
Итак, получив шелл к указанному выше серверу, взломщики залили в каталоги некоторых сайтов CGI-скрипты, они скопировались на сервер eos.apache.org, который является производственным. Такое было реализовано из-за процедуры rsync, которая является регулярной. Находясь на сервере eos.apache.org, скрипты стали доступны извне и были необходимы для получения удаленных шеллов. Команды, в свою очередь, посылались при помощи HTTP POST запросов. Защита от подобных атак на производственных серверах Apache Software Foundation затруднена тем, что у них включена опция ExecCGI, которая позволяет при динамической генерации страниц выбирать ближайшее расположенное зеркало по отношению к пользователю.
Как только было замечено наличие CGI-скриптов, реакция от AFT последовала незамедлительно. Было решено отключить все серверы, которые могли быть атакованы. А трафик с этих серверов был перенаправлен на один, проверенный. Естественно, на ресурсах было вывешено объявление, уведомляющее народ, что AFT в курсе происходящего.
Постепенно специалисты Apache Software Foundation «подняли» все серверы в однопользовательском режиме. А после анализа стало ясно, что европейский сервер aurora.apache.org так и не пострадал от атаки. Все очень просто: несмотря на то, что скрипты на него были скопированы тоже, они ни разу не запустились, сервер не был включен в DNS-ротацию :).
Европейский сервер работает под управлением Solaris 10, и его безопасная конфигурация была быстро восстановлена из ZFS-бэкапов, которые были сделаны за день до того, как появились CGI-скрипты. После этого специалисты начали запускать остальные ресурсы, не переставая анализировать причины произошедшего.
Теперь давайте рассмотрим то, что оказалось эффективным, что сыграло отрицательную роль в истории и какие меры предприняты сейчас.
Было эффективным
. Европейский сервер быстро вернулся к рабочему состоянию благодаря использованию ZFS-снимков.
. Большое количество серверов в двух точках расположения позволило запустить сервисы с зеркал, не меняя их географического положения, и продолжать работать с поврежденными серверами.
. Разнообразие в использованных операционных системах на машинах, подвергшихся атаке (Linux/CentOS i386, FreeBSD-7 amd_64 и Solaris 10 на sparc), притормозило злоумышленников в плане поднятия привилегий.
Отрицательная роль
. Использование SSH-ключей упростило атаку. Причиной тому была недостаточно отработанная система их использования, как обычно, понадеялись на «авось не зацепит».
. Использование процедуры rsync позволило взломщикам незаметно скопировать скрипты в каталоги сайтов с people.apache.org.
. Возможность выполнения CGI на любом хосте, хотя в большинстве случаев в этом нужды не было, позволило заразить их без проблем.
. Нехватка логов с хоста ApacheCon не позволила целиком и полностью восстановить картину действия атакующих.
Ну и в конце приведу цитату из отчета.
Предпринятые меры
После вторжения мы проводим ряд изменений для того, чтобы обезопасить нашу инфраструктуру от подобных инцидентов в будущем. Вот список проводимых нами изменений:
. Требование ко всем пользователям с повышенными привилегиями использовать OPIE for sudo на определенных машинах. Это требование уже действует в некоторых местах, однако теперь данная практика будет обязательно расширена.
. Повторное создание и использование SSH, одного для каждого хоста, для использования при резервном копировании. Также – обязательное использование опций from="" и command="" в файле авторизованных ключей на сервере назначения резервного копирования. В совокупности с ограничениями, позволяющими устанавливать соединения только тем машинам, которые действительно создают резервные копии данных, данная мера позволит предотвратить возможность установления SSH-соединений сторонними машинами.
. Строка command="" в файле авторизованных ключей теперь является явно заданной и позволяет осуществлять только односторонний rsync-трафик.
. Новые ключи сгенерированы для всех хостов, минимальная длина ключа при этом– 4096 бит.
. Виртуальная машина, на которой была расположена старая версия сайта apachecon.com, остается отключенной и ожидает дальнейшего детального анализа. Сайт apachecon.com вновь развернут на новой виртуальной машине, у нового провайдера и под другой операционной системой.
. Мы рассматриваем возможность отключения поддержки CGI на большинстве систем с веб-сайтами. Это привело к созданию нового модуля httpd, который будет управлять предоставлением зеркал для загрузок.
. Метод, согласно которому большинство наших публичных веб-сайтов разворачивается на наших производственных серверах, также будет изменен, этот процесс станет более автоматизированным. Мы надеемся в течение ближайших нескольких недель перейти на использование системы,
основанной на SvnSubPub / SvnWcSub.
. Мы вновь внедрим на всех машинах практику бана по IP-адресу после нескольких неудачных попыток авторизации.
. Было выдвинуто предложение по введению системы централизованного журналирования. Эта система включит в себя все логи и возможно также такие сервисы, как smtpd и httpd.
Вот такая вот история о том, как Apache.org пришлось туговато. С другой стороны, это очень и очень хорошо, потому как на их опыте все продуманные админы давно предприняли некоторые меры предосторожности, чтобы не выглядеть так же бледно как парни из AFT. На этом все, следите за логами и не оставляйте серверы без присмотра ;).
По материалам https://blogs.apache.org/infra/entry/apache_org_downtime_report
Евгений Кучук, q@sa-sec.org
Компьютерная газета. Статья была опубликована в номере 39 за 2009 год в рубрике безопасность
