Отчёт о расследовании Debian взлома серверов

02 Декабря 2003

Команда администрирования Debian и эксперты в области безопасности, наконец, смогли точно определить метод, использованный для взлома четырёх серверов проекта. Тем не менее, кто это сделал, остаётся невыясненным.

Архив пакетов взломщиком не изменён.

Команда администрирования Debian и команды безопасности проверили архивы (security, us, non-us) почти сразу после обнаружения взлома и переустановки. Именно поэтому проект смог снова открыть доступ к архиву исправлений, связанных с безопасностью, и подтвердить, что обновление стабильного выпуска (3.0r2) не затронуты вторжением.

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

Чтобы проверить пакеты и убедиться в том, что архив не изменён взломщиком, были использованы несколько различных методов:

Хронология событий

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

Обнаружение

Вечером (по Гринвичу) четверга, 20 ноября команда администрирования заметила несколько записей о сбоях ядра (oops) на master. Поскольку система работала без ошибок достаточно долгое время, нужно было изучить проблему и проверить, нет ли неполадок в аппаратном обеспечении. Однако в то же время в точности те же проблемы были отмечены на другой машине, murphy. Администраторы заподозрили что-то неладное.

На klecker, murphy и gluck установлена "Усовершенствованная система обнаружения взлома ("Advanced Intrusion Detection Environment", пакет aide), регистрирующий изменения в файловой системе. В то же время он выдал предупреждение о том, что /sbin/init заменён другим файлом и изменены значения mtime и ctime в /usr/lib/locale/en_US.

Дальнейший анализ показал, что причиной обеих проблем была программа SucKIT root-kit (1.3b). В её возможности входит подбор паролей и защита от обнаружения (т.е. инструменты для сокрытия процессов и файлов), которые устанавливаются непосредственно в ядро, что в свою очередь, приводит к появлению замеченных сбоев ядра.

Подробный анализ атаки

В среду, 19 ноября, приблизительно в 17 часов по Гринвичу подобранный пароль был использован для входа в систему на klecker (.debian.org) с непривилегированной учётной записью разработчика. Затем нападающий по протоколу HTTP получил исходный код, необходимый для применения неизвестного (на данный момент) способа использования уязвимости ядра, и посредством этого использования присвоил привилегии пользователя root. Затем был установлен SucKIT root-kit.

Те же учётная запись и пароль были использованы для входа на машину master, присвоения тем же образом привилегий root и установки SucKIT root-kit.

Затем нападающий попытался получить доступ к серверу murphy, используя ту же учётную запись. Это не удалось, поскольку murphy — машина с ограниченным доступом, она работает только в роли сервера списков рассылки, и входить в систему могут лишь немногие разработчики. Поскольку первая попытка входа не удалась, нападающий использовал доступ с правами пользователя root на master для доступа к административной учётной записи, используемой для целей резервного копирования. Используя эту запись, он получил доступ также и к murphy. На этой машине также был установлен SucKIT root-kit.

На следующий день нападающий использовал пароль, подобранный на master для входа на gluck, присвоения привилегий пользователя root на этой системе и, как и прежде, установки SucKIT root-kit.

Тщательный анализ позволил установить точные моменты времени перезаписи /sbin/init и установки root-kit. Аналитики также обнаружили исполняемый файл, использованный для присвоения прав пользователя root на этих машинах, защищённый и "затемнённый" Burneye. После разворачивания и дизассемблирования этого кода эксперты по безопасности выяснили, какая ошибка в ядре была использована.

Использовался выход за границы допустимых целочисленных значений в системном вызове brk для перезаписи памяти ядра (изменения битов защиты страниц). Таким образом нападающий получил полный контроль над пространством памяти ядра и возможность изменить любое значение в памяти.

Несмотря на то, что этот участок кода ядра был отредактирован ещё в сентябре Эндрю Мортоном (Andrew Morton), и это исправление попало в последние предварительные версии ядра (начиная с октября), аспект безопасности этой проблемы не рассматривался. Поэтому ни один из поставщиков дистрибутивов не выпустил предложений по безопасности. Тем не менее, после обнаружения способа локального использования уязвимости, проект Common Vulnerabilities and Exposures присвоил проблеме идентификатор CAN-2003-0961. Она исправлена в ядре Linux 2.4.23, выпущенном на этих выходных, и описана в предложении Debian по безопасности DSA 403.

Linix 2.2.x не содержит этой уязвимости, поскольку раньше выполнялась проверка границ. Предполагается также, что этой уязвимости нет в ядрах для архитектур Sparc и PA-RISC, поскольку пользовательские адреса и адреса ядра на этих архитектурах хранятся в различных адресных пространствах.

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

Восстановление

После выключения взломанных машин были созданы и сохранены на отдельных машинах образы жёстких дисков. Они были предоставлены людям, расследовавшим проблему. Три машины в США (master, murphy и gluck) впоследствии были восстановлены, и их функционирование в точности возобновлено после изучения вопроса администраторами соответствующих служб.

Однако полное исследование klecker было отложен до планового анализа, чтобы функционирование архива обновлений, связанных с безопасностью, было восстановлено раньше, чем другие службы. Также в это время у нас не было консольного доступа к klecker, поэтому восстановление приходилось выполнять удалённым образом. После создания образа диска путём входа на локальную машину с последовательной консоли через сетевое соединение, защищённое брандмауэром, был удалён root-kit, заменено и укреплено ядро, тщательно проверена целостность двоичных файлов. Архив обновлений был сверен с нескольким внешними источниками. Машина будет восстановлена в течение нескольких недель.

В качестве меры предосторожности были отключены учётные записи всех разработчиков в LDAP, а ключи SSH удалены. Это сделано, чтобы не пострадали другие машины. Однако, это делает невозможным почти любое участие в деятельности проекта, связанное с загрузкой файлов на сервер или доступом к репозиториям CVS.

Все пароли на quantz (т.е. все пароли Alioth, arch и subversion) также отключены. Все авторизованные ключи SSH удалены. Для создания нового пароля используйте, пожалуйста, систему восстановления потерянных паролей.

После того, как будут снова запущены все службы и будут приняты меры по безопасности машин, LDAP будет восстановлен и разработчики смогут создать новые пароли. Однако, предсказать, когда это произойдёт, нельзя.

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

Выводы

Обновите ваш пароль!

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

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

Если ключ SSH был сгенерирован или хранился на одной из наших машин и использовался для входа на другие машины (т.е. помещён в .ssh/authorized_keys), его также следует удалить.

Секретные ключи GnuPG/PGP, обнаруженные на машинах debian.org, также удалены из сети ключей Debian и, таким образом, больше не могут использоваться.

Разработчики, беспокоящиеся о собственных машинах, должны, по крайней мере, запустить chkrootkit и проанализировать его вывод. Мэтт Таггарт (Matt Taggart) сопровождает обратный перенос на woody, который можно найти по следующему адресу:

Кроме того, Вичерт Аккерман (Wichert Akkerman) и Мэтт Таггарт (Matt Taggart) составили подробный список мер предосторожности.

SucKIT Root-Kit

SucKIT — это инструмент, представленный в 58-м выпуске Phrack, статья 0x07 ("Изменение на лету ядра Linux без LKM" авторства sd & devik). Это полностью рабочий инструмент, загружаемый через /dev/kmem, т.е. для его работы не требуется ядро с поддержкой загружаемых модулей ядра. Он предоставляет оболочку защищённого паролем удалённого доступа с обратным соединением, инициируемым поддельным пакетом (минующим большинство брандмауэров). Может скрывать процессы, файлы и соединения.

Обычно SucKIT запускается как /sbin/init при загрузке системы, разветвляется для установки самого себя в ядра, запускает фоновый процесс и передаёт управление от родительского процесса (pid 1) исходному двоичному файлу init. Любое последующее выполнение /sbin/init будет перенаправлено на исходный init.

Защита TESO's Burneye

Burneye  это средство "затемнения" двоичных файлов формата ELF на платформах UNIX, представленное в 58-м выпуске Phrack, статья 0x05 ("`Бронирование' ELF: двоичное шифрование на всех платформах UNIX" авторства grugq & scut). Используя средства типа TESO's Burneye, нападающий может изменить выполняемую программу так, чтобы скрыть её истинное назначение, скрыв её от фильтров брандмауэров, систем обнаружения вторжения, антивирусного ПО и зоркого взгляда исследователей.

Благодарности

Отклики прессы

Для связи

Чтобы получить более подробную информацию, посетите web-страницы Debian или отправьте ваш вопрос по адресу press@debian.org.