Немногие истории написаны в буквальном смысле на основе данных машинных логов, сегодня — пример одной из них. Мной реконструирована детальная хронология одного крупного взлома, построенная сугубо на основе сухих фактов: ведь любое человеческое мнение, воспоминание и оценка — субъективны, и лишь серверные логи — святы и беспристрастны.
И как приятно смотреть на любимого, но еще молодого актера, естество и талант которого пока не сковывает будущая слава и тяжесть раздутого самомнения, — так интересно посмотреть на еще совсем молодую 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), при этом некоторые детали могут не совпадать с реальным ходом событий.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.