Support us

Как это было: LulzSec vs. Apache Infrastructure Team

Оставить комментарий
Как это было: LulzSec vs. Apache Infrastructure Team

Немногие истории написаны в буквальном смысле на основе данных машинных логов, сегодня — пример одной из них. Мной реконструирована детальная хронология одного крупного взлома, построенная сугубо на основе сухих фактов: ведь любое человеческое мнение, воспоминание и оценка — субъективны, и лишь серверные логи — святы и беспристрастны.

И как приятно смотреть на любимого, но еще молодого актера, естество и талант которого пока не сковывает будущая слава и тяжесть раздутого самомнения, — так интересно посмотреть на еще совсем молодую LulzSec в действии. В качестве сцены выступит инфраструктура Apache.org Project. Время действия — апрель 2010 года, место действия — интернет. Именно там и тогда схлестнулись двое парней 19 и 21 года от роду (впоследствии ставшие ядром хакерской группы известной ныне как LulzSec) и международная «университетская команда» сисадминов (Канада, США, Германия, Польша) из проекта Apache.org, под управлением которой тогда находилось около 300 серверов по всему миру.

Страх и ужас в серверной — страшная история на ночь для всех бородатых админов

5 April 2010, 10:12 EST

В понедельник 5 апреля 2010 года, рано утром, в багтрекинге Apache Project появилось уведомление об ошибке INFRA-2591 с пометкой «важно». И хоть точная дата начала этой истории достоверно неизвестна, для простоты принято начинать ее именно с этого момента.

Весьма подробно, технически грамотным языком, неизвестным описана проблема открытия некоторых страниц на сервере royal, входящего в домен apache.org. К сообщению были педантично приложены примеры ссылок на множество проблемных страниц, при обращении к которым сервер выдавал странную Internal Server Error. Кроме того, была указана ссылка на одну из страниц из домена аpache.org, в которую был заранее добавлен JavaScript-код, осуществляющий перехват сессионных cookie с помощью XSS-атаки. Поскольку указанные страницы действительно сбоили, и сервер работал явно нестандартно, ведущие разработчики из нескольких проектов Apache перешли по указанным ссылкам, после чего начался поиск причин такого поведения сервера.

5 April 2010, 14:51 EST

Пока на стороне Apache Project кипела работа по поиску причин крайне таинственных проблем с сервером, неизвестные злоумышленники закончили сбор cookie администраторов через ими же созданную XSS.

Уже к обеду 5 апреля злоумышленники имели административный доступ к системе трекинга ошибок JIRA. После этого покусители сразу отключили ее систему уведомлений об изменениях и поправили пути загрузки дополнений (вложений) в загружаемых реквестах о найденных ошибках.

Этот «новый путь» теперь указывал на другую, «хорошую директорию» сервера, права в которой позволяли запускать любые jsp-файлы. После этого в систему багтрекинга этими же ребятами сразу же было загружено сообщение об ошибке, в которое под видом приложения к тикету был приложен вредоносный скрипт. После его серверного запуска хакеры получили копии содержимого и истории домашних каталогов всех администраторов и пользователей данной локальной системы (royal@apache), а также сохраненные хэши всех паролей в текущей системе.

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

9 April 2010, 12:55 EST

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

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

Дальнейший анализ показал, что, в полном соответствии с классикой жанра, у многих разработчиков был один и тот же пароль сразу ко многим сервисам Apache, что позволило злоумышленникам, развивая атаку, залогиниться уже и на другие сервисы-серверы проекта. Например, как оказалось в процессе анализа «результатов рыбалки», один из пользователей JIRA был полноправным администратором на других сервисах Apache, поэтому уже к вечеру пятницы злоумышленники получили права на запуск команды sudo, для запуска любых команд с правами root — сразу на нескольких серверах проекта.

Подводя предварительные итоги, над сервисами JIRA, Confluence, wiki и Bugzilla (серверы brutus.apache.org и royal.apache.org) к вечеру пятницы был получен полный контроль.

10 April 2010, 02:18 EST

Дальнейший, полностью аналогичный анализ пользователей, зарегистрированных уже в новых системах, позволил найти тех, у кого были прокешированы в домашней директории параметры аутентификации в главном репозитории Subversion, а также доступ к машинам Neptune, Aurora и другим...

В тот момент, имея разные уровни доступа уже почти на половину проектов Apache, взломщики останавливают свою стратегию веерного развития атаки и фокусируются лишь на одном сервере проекта — сервере под сетевым именем Minotaur.

10 April 2010, 12:18 EST

Сервер people.apache.org, известный также как Minotaur, — один из важнейших опорных серверов сетевой инфраструктуры Apache.org. Это — главный административный сервер проекта Apache, где находятся shell-аккаунты всех основных разработчиков проекта, в том числе и всех его корневых администраторов.

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

10 April 2010, 16:18 EST

И вот здесь, именно в «Минотавре», злоумышленниками был применен один из самых изящных и драматических трюков в хронологии взлома. Обнаружив в системе демона синхронизации rsyncd, хакеры стали анализировать возможности его «левого» противоправного использования. И хотя многие серверы были уже под их контролем, самая важная составляющая системы, находящаяся под управлением AFT (Apache Infrastructure Team), по-прежнему оставалась вне досягаемости группы. Специфика уровней безопасностей Unix — это разбитая на множество изолированных отсеков «подводная лодка», где, даже пробравшись достаточно глубоко, вы то и дело будете натыкаться на все новые уровни дверей-отсеков. Нашим героям оставалось последнее и самое сложное — попасть на капитанский мостик всего корабля.

В отношении «Минотавра», одного из таких привилегированных серверов, хакерская гипотеза заключалась в следующем — rsyncd позволяет проводить синхронизацию в двух направлениях. И хоть в подавляющем большинстве вариантов он используется для однонаправленных синхронизаций, в данном случае он использовался для синхронизации файлов-конфигурации множества сервисов в сети зеркал инфраструктуры проекта.

Идея была в том, чтобы воспользоваться уже настроенным на всех хостах механизмом синхронизации, но повернуть его вспять, дабы обновление пошло не от центрального мастер-сервера (как это было изначально задумано и автоматически работало), а от сервера «Минотавр» — рядового в сети этих обновлений, контроль над которым они уже получили. Именно он, согласно этой схеме, и должен был выступить в роли головного, выполнив функцию «троянского коня» по отношению ко всей инфраструктуре.

Многочисленные косвенные признаки показывали, что настройка rsyncd была выполнена недостаточно строго — это не тот тип сервисов, постоянно доступных или видимых извне, который атакуют, — именно поэтому настройки таких «внутренних служебных» сервисов чаще всего остаются дефолтными (где возможность двунаправленного sync'a как раз включена в целях большей универсальности этой службы).

Быстро перетасовав колоду из вариантов, нападавшие сделали ставку на джокер — они запросили upstream-обновление через rsync, предварительно добавив свои CGI-скрипты в корни каталогов с файлами-конфигами локального сервера, тем самым развернув процесс обновления вспять, «пробросив» свое «скриптовое барахло» дальше по всей цепочке зеркалирования. В результате успешно завершившейся процедуры rsync эти скрипты были втянуты на все production-серверы проекта ими же самими (в частности, на центральный eos.apache.org, на котором они стали видимыми извне). Далее данные CGI-скрипты были использованы для получения удаленных шеллов, а информация отсылалась при помощи стандартных команд HTTP POST.

Теория об уязвимом rsyncd полностью подтвердилась — теперь «пламенем были объяты» фактически все основные серверы проекта. Отсчет времени для получения тотального контроля над проектом пошел на минуты…

Baby, don't panic: 10 April 2010, 22:34 EST

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

На этой фазе внедрения, когда метастазы проникли уже во все части системы, необычная активность в корневой системе eos.apache.org привлекла внимание сразу нескольких администраторов Apache Project, которые, осознав уровень «погружения» в систему злоумышленников, вынуждены были… начать банально выдергивать сетевые шнуры серверов из розеток —  риск захвата управления центрального сервера на этом этапе вторжения был чрезвычайно высок, а начинать разбираться во всем происходящем уже было слишком поздно.

10 April 2010, 23:49 EST

Команда AFT (Apache Infrastructure Team), быстро мобилизовавшись через экстренную SMS-рассылку, разделилась на две группы: первая развернула весь трафик на резервный сервер (который по халатности персонала не был включен в DNS-ротацию, и исключительно поэтому остался незараженным), вторая — выдергивала те самые сетевые кабели работающих серверов из розеток. Насчет последней команды «ликвидкома» хочется заметить, что подобный метод борьбы с сетевыми вторжениями уже давно считается самым позорным способом избежать болезненной для самолюбия любого администратора развязки.

Первой командой были оперативно подправлены соответствующие записи DNS для домена apache.org, после чего обслуживание web-запросов было временно перенаправлено на упомянутый «чистый» резервный сервер проекта в Европе.

Из-за того что старые серверы были отключены от сети, а новые были пока недоступны из-за эффекта кеширования старых данных в DNS, 11 апреля сотни тысяч посетителей/пользователей многочисленных проектов Apache столкнулись с тем, что сайт apache.org и его многочисленные поддомены фактически полностью выпали из Сети.

Эй, что это было?

Несмотря на видимость закрытого дела, у независимых аналитиков остается очень много вопросов по факту этого грандиозного взлома... Откуда у Atlassian JIRA взялась уязвимая страница, ведь именно этот проект накануне подвергся серьезному аудиту на безопасность? Откуда взялись эти злополучные «внутренние ошибки сервера» на некоторых страницах, о которых был сделан реальный багрепорт самими же злоумышленниками?

Я не случайно выше подчеркнул, что начало отсчета хронологии этого взлома именно с инцидента с JIRA весьма условно — некоторые специалисты, объясняя все эти странности, склоняются к мнению, что этому взлому предшествовал еще один, более ранний. По их мнению, не получив достаточных привилегий для развития атаки, злоумышленниками и был разыгран этот «марлезонский балет» с багрепортом, чтобы «заставить администраторов сделать то, что от них хотели, чтобы они сделали» — заманив их на специально подготовленную страничку с XSS в домене apache.org, при этом симулировав на своем уровне доступных полномочий серьезные ошибки в работе сервера royal. «Раскачивание лодки» было лишь хорошо спланированным обманным маневром, чтобы заставить местных админов «в хорошем темпе» вбивать свои пароли во всевозможные формы и приложения.

Действующие лица: Apache Infrastructure Team

Список суровых мер, который принял проект Apache в качестве недопущения повторения подобных инцидентов в будущем, позабавил специалистов. Сказать, что в области безопасности проекта все усложнилось — это не сказать ровным счетом ничего. Это и использование OPIE for sudo, это и обязательное повторное создание SSH, уникального для каждого хоста, исключительно для резервного копирования + полное отключение поддержки CGI, введение системы централизованного журналирования с распределенным хранением лог-журналов для каждого конкретного сервиса проекта… и т. д. и т. п. В длинном списке предельно радикальных мер не хватает только строчки «забетонировать все входы и выходы в серверной», чтобы окончательно передать тот дух паранойи, который охватил тамошних админов в процессе «зализывания кровоточащих ран», которые им причинило столь «глубокое бурение» со стороны LulzSec.

И поскольку еще в начале статьи была обещана полная деанонимизация всех действующих лиц этого эпизода, ниже привожу фото четырех главных инженеров-координаторов из Apache Infrastructure Team, которые боролись тогда на стороне Apache Project:

Eric Evans (eevans@apache)

Mark Struberg (struberg@apache)

Jeremy Thomerson (jrthomerson@apache)

Niklas Gustavsson (ngn@apache)


Действующие лица: Lulz Security

Время представить и главных героев с противоположной, атаковавшей стороны — Lulz Security:

24-летний хакер, известный в онлайне под ником Aush0k, оказался жителем городка Поинт-Клер (Point Clare), недалеко от Сиднея. Он работал в австралийском филиале международной ИТ-компании, которая специализируется на компьютерной безопасности. Был арестован в апреле 2013 года совсем за другие дела прямо на своем рабочем месте в офисе.

В реальном мире хакера зовут Мэтью Флэннери (Matthew Flannery), он работал на должности Unified Security Monitoring (Tenable Network Security, Inc). Вот его профиль в LinkedIn.

Второй ветеран LulzSec, который засветился в стремительном налете на Apache.org, — 19-летний (на момент событий) хакер Джейк Дэвис по прозвищу Топайари (topiary), который лично мне запомнился тем, что громко ржал в суде, каждый раз, когда зачитывавшая ему приговор пожилая судья плохо выговаривала название группы LulzSec, символически произнося его как «лузсэк» (по смыслу звучит как «лузерская безопасность»).

В его поддержку со стороны коллег из LulzSec/Anonymous прошла широкая общественная компания в Сети и оффлайне:

А вот таким повзрослевшим он вышел после отсидки:


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

Я с уверенностью заявляю, что перманентное отсутствие интернета сделало меня более целостной личностью. И как представитель молодежи, которая сидит, уткнувшись в экран каждый день, я бы никогда не подумал, что скажу это. До того [как мне запретили пользоваться интернетом] отсутствие Сети виделось мне невыносимым, но теперь (не хочу, чтобы это звучало как откровение, явившееся мне потому, что я так резко "завязал"), просматривая логи моих онлайновых чатов (которых полно в материалах моего дела), я не понимаю, зачем все это было надо».

Впрочем, он оговаривается, что сегодня все-таки сложно жить, вообще не пользуясь сервисами Google и интернетом.

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

На сленге спецслужб внезапное и хорошо отрепетированное молниеносное нападение-захват обозначается как «Tango down». Именно этим термином LulzSec охарактеризовал свои две самые известные операции против инфраструктуры Sony и центрального портала ЦРУ США.

 

Знаменитая лодка группы, на которой LulzSec отправилась в свое плавание по просторам интернета в поисках новых лулзов...

И последнее — практически все взломы со стороны LulzSec носили принципиально недеструктивный характер. Например, после взлома сайта Сената США ничего не было тронуто, лишь главная страничка была заменена на новую с длинным списком госслужащих, любящих посещать сайты с порнографией, извлеченным LulzSec из лог-файла граничного прокси-сервера локальной сети Сената, с таким текстом-пояснением вверху страницы:

Мы очень не любим американское правительство. Несмотря на это, выкладываем лишь небольшой, чисто чтобы поржать, фрагмент внутренних данных сайта Senate.gov. Говорите, типа это акт военной агрессии? У вас какие-то проблемы, джентльмены?».

Примечание: вся хронология базируется на реальном инциденте (сообщение со стороны Apache, сообщение со стороны Atlassian JIRA, альтернативные версии: 1, 2), при этом некоторые детали могут не совпадать с реальным ходом событий.

Место солидарности беларусского ИТ-комьюнити

Далучайся!

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

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

Комментариев пока нет.