КАК ХАКЕРЫ АНОНИМУСЫ ВЗЛАМЫВАЛИ САЙТ ПО БЕЗОПАСНОСТИ…

РАЗДЕТАЯ КРАСОТКА КАК БЫ СИМВОЛИЗИРУЮТ БЕЗЗАЩИТНОСТЬ ИНТЕРНЕТСАЙТОВ...
РАЗДЕТАЯ КРАСОТКА КАК БЫ СИМВОЛИЗИРУЮТ БЕЗЗАЩИТНОСТЬ ИНТЕРНЕТСАЙТОВ...

ЗДАРРРРРРРРРОВА;)
СТАТЬЯ СТАРЕНЬКАЯ УЖЕ НО ИНТЕРЕСНО…
Вся прошлая неделя прошла под знаком взлома фирмы 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 году), подарил взломщикам паролей альтернативный подход. За счет предварительного вычисления большого набора данных и генерации так называемых радужных таблиц, злоумышленники получают компромисс: намного большая скорость взлома паролей в обмен на использование гораздо большего свободного места. Радужные таблицы позволяют взломщику паролей заранее рассчитать и сохранить большое количество хеш-значений и паролей, которые им соответствуют. Затем злоумышленник может найти нужное ему хеш-значение и проверить, есть ли оно в таблице. И если есть — пароль получен.

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

Следующий метод — «соль»: небольшой набор случайных данных добавляется к паролю перед хешированием, значительно увеличивая размер радужной таблицы, необходимой для получения пароля.
Читать далее «КАК ХАКЕРЫ АНОНИМУСЫ ВЗЛАМЫВАЛИ САЙТ ПО БЕЗОПАСНОСТИ…»

ИНТЕРЕСНЫЕ СТАТЬИ САЙТА EZOLIFE.INFO