Говорят Anonymous: как был взломан HBGary

Вся прошлая неделя прошла под знаком взлома фирмы HBGary и ее отделения
HBGary Federal. Генеральный директор HBGary Federal Аарон Барр думал, что он
разоблачил лидеров Anonymous и готовился назвать и пристыдить ответственных за
координацию действий группировки, включая DDoS-атаки, ударившие по MasterCard,
Visa и другим предполагаемым врагам WikiLeaks в конце прошлого года.

Когда Барр сообщил одному из тех, кого он считал главарем Anonymous, о его
предстоящем разоблачении, ответ Anonymous был стремительным и оскорбительным.
Группировка вторглась на сервера HBGary, украла e-mail-ы, опубликовав их
впоследствии, уничтожила информацию компании, и повредила веб-сайт. В качестве
дополнительного бонуса второй сайт, находящийся под руководством Грега Хоглунда,
владельца HBGary, был выведен из строя, а также была опубликована
пользовательская база данных.

Anonymous: уже не детки

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

Что касается сервисов, компания предлагает экспертную оценку при внедрении
IDS и безопасности сетей, а также выполняет оценку уязвимостей и тестирование
систем и программного обеспечения на устойчивость к проникновению.
Многочисленные "трехбуквенные" организации, включая NSA, как и Интерпол,
поддерживали постоянный контакт с HBGary, которая также работала с хорошо
известной фирмой безопасности McAfee. Однажды даже компания Apple выразила
интерес к продуктам или сервисам HBGary.

Сайт Грега Хоглунда rootkit.com является уважаемым ресурсом, где обсуждаются
и анализируются руткиты и соответствующие технологии; годами его сайт атаковался
рассерженными хакерами, недовольными тем, что их продукты обсуждаются,
разбираются по частям, и часто пренебрежительно высмеиваются плохо написанные
участки кода.

Кто-то может подумать, что такая уважаемая организация станет непреодолимым
препятствием, не поддающимся взлому, для группы недовольных детей. Всемирно
известные, признанные правительством эксперты против Anonymous? У HBGary не
должно было возникнуть никаких проблем.

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

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

На самом деле многие операции, осуществляемые от имени Anonymous, довольно
просты, но и эффективны тоже: атаки на MasterCard и других были DDoS атаками,
произведенными с помощью модифицированной версии утилиты нагрузочного
тестирования сети Low orbit
Ion Canon (LOIC). Модифицированный LOIC позволяет создавать большие ботнеты,
в которых пользователи участвуют осознанно: ПО может быть настроено на получение
управляющих инструкций через IRC-чаты, что позволяет организаторам атаки
удаленно контролировать сотни компьютеров и таким образом управлять масштабными
атаками, способными быстро выводить сайты из строя.

Судя по просочившимся письмам, Аарон Барр считал, что веб-сайт HBGary тоже
подвергся DDoS-атаке сразу после того, как Барр назвал себя кому-то, кого он
считал главным лидером Anonymous. Но человек, с которым я общался на эту тему,
отрицает какую-либо причастность к данной атаке. Это не говорит о том, что атаки
не было вообще - просто это человек не знал о ней или не принимал в ней участия.
В любом случае, планы у Anonymous шли куда дальше, чем грубый DDoS.

Время для инъекции.

Сайт HBGary Federal – hbgaryfederal.com, работал под управлением системы
управления контентом (CMS). CMS - это типичный компонент
контент-ориентрированных сайтов, она позволяет легко добавлять и изменять
содержимое сайта без необходимости возиться с HTML, беспокоиться, что все ссылки
на месте, и т.д. и т.п. Вместо использования готовой CMS, HBGary по причинам,
известным только руководству, решили использовать самописную CMS-систему от
стороннего разработчика.

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

Стороннему решению для сайта HBGary такой поддержки явно недоставало. И если
HBGary проводили хотя бы какую-то оценку степени уязвимости ПО - а ведь это, в
конце концов, одна из услуг компании - эта оценка проглядела очень существенный
недостаток. CMS система на hbgaryfederal.com была уязвима к атакам типа
SQL-инъекция. Как и многие другие, CMS на hbgaryfederal.com хранит данные в SQL
базе данных, получая данные из нее с помощью соответствующих запросов. Некоторые
запросы фиксированы - это внутренняя логика работы самой CMS. Однако для других
нужны параметры. Например, для запрос из CMS на получение статьи, как правило,
требуется параметр, соответствующий её ID (идентификационному номеру). В свою
очередь эти параметры обычно передаются к CMS из веб-интерфейса.

SQL-инъекция возможна если код, работающий с этими параметрами, содержит
ошибки. Многие приложения объединяют параметры из веб-интерфейса с жестко
закодированными запросами, а затем передают этот склеенный запрос в базу. И
обычно проверки на валидность параметров нет. Это подвергает систему опасности -
через SQL-инекцию. Передав специально измененные параметры, злоумышленник может
указать базе данных выполнить тот запрос, который он хочет. Вот точный адрес URL,
которым воспользовались для взлома hbgaryfederal.com:

http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27

У адреса два именованных параметра: pageNav и page, выставленные в значения 2
и 27 соответственно. Один или оба из них некорректно проверялись в CMS, позволяя
хакерам получить из БД те данные, к которым у них не должно было быть доступа.

Радужные таблицы

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

Основной момент тут в том, что процесс необратим - вы не можете взять хеш и
конвертировать его обратно в пароль. В случае с хеш-алгоритмом, традиционно есть
только один способ узнать пароль - полный перебор всех возможных паролей с
проверкой, не совпадает ли какой из них с имеющимся хешем пароля. Т.е сначала
проверяем "a", потом "b", потом "с"... потом "z", потом "aa", "ab", ну и так
далее.

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

Однако подход, впервые опубликованный в 2003 году (являющийся уточнением
методики, описанной в 1980 году), подарил взломщикам паролей альтернативный
подход. За счет предварительного вычисления большого набора данных и генерации
так называемых радужных
таблиц, злоумышленники получают компромисс: намного большая скорость взлома
паролей в обмен на использование гораздо большего свободного места. Радужные
таблицы позволяют взломщику паролей заранее рассчитать и сохранить большое
количество хеш-значений и паролей, которые им соответствуют. Затем злоумышленник
может найти нужное ему хеш-значение и проверить, есть ли оно в таблице. И если
есть - пароль получен.

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

Следующий метод - "соль": небольшой набор случайных данных добавляется к
паролю перед хешированием, значительно увеличивая размер радужной таблицы,
необходимой для получения пароля.

В принципе, любой хещ-функцией можно воспользоваться для генерации радужных
таблиц. Однако для медленных хеш-фунций генерировать радужные таблицы намного
дольше, чем для быстрых, и хеш-функции, выдающие короткий хеш, требуют намного
меньше места чем те, которые генерируют длинный результат. Так что на практике
лишь несколько хеш-алгоритмов доступны в распространенном ПО для генерации
радужных таблиц. Наиболее известен и широко распространен, пожалуй, MD5, который
рассчитывается быстро и выдает на выходе хеши размером лишь 128 бит (16 байт). И
благодаря этим факторам он наиболее уязвим для взлома через радужную таблицу.
Есть несколько программных продуктов, позволяющих сгенерировать или скачать
готовые радужные таблицы для MD5, и затем использовать их для взлома паролей.

И как назло, CMS hbgaryfederal.com использовала MD5. Хуже лишь то, что MD5
использовался в самом простом случае: не было ни итеративного хеширования, ни
"соли". В результате скачанные пароли были очень восприимчивы к взлому через
радужные таблицы, чем не преминули воспользоваться злоумышленники, взломав
пароли из CMS hbgaryfederal.com с помощью утилиты для взлома через радужные
таблицы.

Даже с учетом недостатка с MD5, с HBGary могло все быть в порядке из-за
лимита в радужных таблицах: каждая таблицы охватывает только пароли
определенного типа. Например, какая-то таблица может содержать пароли длиной 1-8
символов нижнего и верхнего регистра, а другая - только пароли длиной 1-12
символов в верхнем регистре.

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

Увы, два работника HBGary Federal - генеральный директор Аарон Барр и главный
операционный директора Тед Вера - использовали очень простые пароли - в каждом
было 6 букв в нижнем регистре и две цифры. Такие простые комбинации могут быть
найдены в любой нормальной радужной таблице, так что именно эти пароли узнали
быстрее всего.

Очень удивляет использование в компании по безопасности такой дырявой CMS.
Неверная работа с паролями и недостаток защиты от SQL-инъекций - стандартные
ошибки. Система не пала жертвой какой-нибудь сложной и малозаметной ошибки: её
взломали обычными, хорошо известными техниками. И не смотря на то что, не все
пароли были получены через радужные таблицы, двух выбранных неправильно паролей
было достаточно.

Позже в IRC-чате с Anonymos владелец HBGary Пенни Ливи сказал, что
компания-разработчик CMS была отстранена от дел.

Проблема паролей

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

Увы, но не для HBGary Federal. Ни Аарон, ни Тед, не следовали стандартным
практикам. Вместо этого они пользовались тем же паролем в куче разных мест,
включая почту, аккаунты в Twitter и LinkedIn. Для обоих мужчин пароли давали
доступ к почте. Однако, это ещё не все.

Давайте начнем с пароля Теда.

Вместе с веб-серверами, в HBGary была машина на Linux, support.hbgary.com, на
которой у многих работников HBGary были консольные аккаунты с доступом по ssh, у
каждого был пароль для авторизации. Одним из работников был Тед Вера и его ssh
пароль совпал со взломанным паролем для доступа к CMS. Что мгновенно дало
хакерам доступ к машине тех.поддержки.

Для ssh не обязательно использовать пароли для авторизации. Конечно, пароли -
дело привычное, но они подвержены такого рода проблемам (среди прочих). Для
борьбы с этим многие организации и пользователи, особенно беспокоящиеся о
безопасности, не используют пароли для авторизации по ssh. Вместо этого
используется шифрование по открытому ключу: у каждого пользователя есть ключ,
состоящий из закрытой и открытой части. Открытая часть связана с его аккаунтом,
а закрытая часть - ну, на то она и закрытая. И ssh использует эти два ключа для
авторизации пользователя.

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

Хотя злоумышленники и могли зайти на машину, осмотреться и чего-нибудь
поломать возможности почти не было: Тед был всего лишь обычным пользователем.
Работа в пределах одного аккаунта очень ограничивает возможности на Linux
машине. Это портит все удовольствие - вы не можете прочесть данные других
пользователей, не можете удалять не принадлежащие вам файлы, не можете спрятать
следы взлома. Это полный облом для хакеров.

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

Эксплоит этой уязвимости дал злоумышленникам из Anonymous полный доступ к
системе HBGary. Уже после они обнаружили много гигабайт бэкапов и
исследовательских данных, которые они просто удалили из системы.

Пароль Аарона принес ещё больше плодов. В HBGary пользовались сервисами
Google Apps для организации почты, и для обоих Аарона и Теда взломанные пароли
дали доступ к их почтовым ящикам. Но Аарон был не просто пользователем Google
Apps: у его аккаунта были правда администратора почтового сервера компании. С
такими высокими правами он мог сбросить пароль любого почтового ящика, а значит
получить доступ к почте всей компании, не только к своей. Именно так был получен
доступ к почтовому ящику Грега Хоглунда.

Что же сделали с почтой Грега?

Совсем ничего, лишь немного социальной инженерии.

С помощью моих друзей

В письмах Грега было два полезных кусочка информации. Первый - рутовый пароль
к машине, на которой крутился сайт Грега rootkit.com или "88j4bb3rw0cky88" или
"88Scr3am3r88". Второй: у Юсси Яаконахо, "Главного специалиста по вопросам
безопасности" в Nokia, был доступ к руту. До издевательств над сайтом, который
находился на машине, оставалось всего ничего.

Нападавшим нужно было ещё немного информации: нужен был обычный, нерутовый
аккаунт, т.к. по стандарту безопасности прямой ssh доступ заблокирован для рута.

Итак, социальные инженеры, вооруженные полученной ранее информацией, а также
подконтрольным им почтовым аккаунтом Грега, приступили к выполнению своей
задачи. Лог переписки показывает всю картину целиком:

От: Грег
Кому: Юсси
Тема: нужно зайти по ssh на rootkit
я в Европе, мне бы залезть по ssh на сервер. Ты бы не мог подправить фаервол и
открыть доступ по какому-нибудь порту типа 59022?
и кстати, пароль ещё 88j4bb3rw0cky88 или мы уже поменяли его на 88Scr3am3r88?
Спасибо

спасибо

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

Позже, Юсси, похоже, заметил, что что-то не то:

-------------------------------------
От: Юсси
Кому: Грег
Тема: Ответ: нужно зайти по ssh на rootkit
Ты там ничего на старших портах не запускал?

Как и в случае с машиной в HBGary, всего этого можно было избежать, если бы
для доступа использовались ключи, а не пароли. Но они не использовались.
Rootkit.com был уже под контролем.

Стандартные практики

Как только логин и пароль были получены, поиздеваться над сайтом не составило
труда. Залогиниться под Грегом, переключиться на рута, и вперед! Но нападавшие
сделали даже лучше: они сделали дамп пользовательской базы rootkit.com со
списком почтовых ящиков и хешей паролей всех, кто когда-либо регистрировался на
сайте. И, как и в CMS-системе hbgaryfederal.com, пароли были захешированы всего
лишь одним MD5, а значит, опять же, были уязвимы ко взлому через радужные
таблицы. Так что взломали и все пароли, которые можно было.

Что же получилось в итоге? Веб-приложение, уязвимое к SQL-инъекциям и
небезопасные пароли. Плохо выбранные пароли. Одни и те же пароли для разных
сервисов. Сервера с доступом по паролю. Непропатченные системы. И удивительная
готовность выдать доступ по электронной почте, хотя и человек, отвечавший за
это, должен был уловить подвох.

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

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

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

И HBGary не одиноки.
Анализ паролей, украденных у rootkit.com и Gawker показывает, что
использование одних паролей в разных местах очень распространено, этим грешат
порядка 30% пользователей. И сайт HBGary не будет последним взломанным с помощью
SQL-инъекций, и пользователи по прежнему будут использовать парольный доступ к
защищенным системам, поскольку это намного удобнее авторизации по ключу.

Из всей этой истории можно извлечь два урока. Во-первых, типичное решение -
хорошее решение. Ничего бы не случилось будь соблюдены лучшие практики. Даже
останься ошибка с SQL-инъекцией, она бы не привела к каскаду случившихся
проблем.

Однако второй урок в том, что типовые решения не достаточно хороши. Им не
следуют даже признанные эксперты по защите информации. На что же надеяться всем
остальным?

Источник:
http://arstechnica.com/