Наши партнеры

Библиотека сайта rus-linux.net

Безопасная эксплуатация Apache, часть 6: атаки на механизм управления сессиями (продолжение)

Перехват идентификаторов сессий при помощи снифферов

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

Одним из примеров такого сниффера является HTTP-сниффер Effetech. Этот сниффер позволяет захватывать IP-пакеты, содержащие данные HTTP-протокола, воссоздавать из захваченных данных HTTP-сессии, а также позволяет вмешиваться в процесс передачи файлов по протоколу HTTP. На Рисунке 2 изображен упрощенный пошаговый процесс перехвата идентификатора сессии с помощью сниффера.

Рисунок 2: Перехват идентификатора сессии с использованием сниффера

Фиксация сессий

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

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

Успешная атака фиксации сессии в общем случае заключается в преодолении трех следующих фаз:

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

Чтобы описанное выше стало более понятным, давайте рассмотрим следующий сценарий атаки...

Предположим, что банк предоставляет услуги с помощью сайта www.bank.com. Идентификаторы сессий передаются от браузера клиента серверу в составе строки URL при помощи аргумента с названием sessionID. Механизм проведения атаки фиксации сессии:

Взломщик начинает работу в рамках своей учетной записи на сайте банка как обычный пользователь.
После этого взломщик получает идентификатор сессии от сайта www.bank.com, скажем, 2435345.
Далее взломщик отправляет ссылку, подобную www.bank.com/login.php?sessionID=2435345 жертве атаки и каким-либо образом склоняет ее к переходу по ней.
Как только жертва атаки переходит по ссылке, серверу банка отправляется следующий запрос: login.php?sessionID=2435345.
Веб-приложение устанавливает, что идентификатор сессии 2435345 уже существует и сессия находится в активном состоянии, следовательно, не следует создавать новую сессию. Наконец, жертва атаки передает свои идентификационные данные сценарию для входа и банк предоставляет доступ к учетной записи.
Но на данный момент взломщики также знают, что идентификатор сессии имеет значение 2435345 (в конце концов, это их сессия), поэтому они могут получить доступ к учетной записи пользователя, использовав строку URL http://www.bank.com/account.php?sessionID=2435345.

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

Рисунок 3: Атака фиксации сессии

Методы фиксации идентификаторов сессий жертв атаки включают в себя техники, описанные ниже.

Фиксация сессии с помощью аргумента в строке URL

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

Фиксация сессии при хранении идентификатора в куках

Использование кук является самым удобным и эффективным способом реализации атак фиксации сессии. Однако, существует два разных способа фиксации сессий с использованием кук - при помощи сценариев на стороне клиента и тэга META.

При атаке с использованием сценария на стороне клиента взломщик, эксплуатируя XSS-уязвимость на сервере bank.com, должен отправить примерно следующую строку URL жертве атаки:

Следует отметить, что атрибут domain=.bank.com в данной строке URL позволяет браузеру жертвы атаки отправлять куки не только установившему их серверу, но и всем серверам, использующим данный домен. При этом в случае либерального управления сессиями возможно осуществление атаки с долговременной фиксацией путем использования постоянно существующих кук (срок хранения которых истекает, например, через 10 лет), которые позволят сохранить фиксацию сессии даже при перезагрузке компьютера пользователя. Эта цель может быть достигнута путем создания следующей вредоносной строки URL и отправки ее жертве атаки:

Атака с использованием тэга META используется для сохранения данных в куках с помощью вставки соответствующего тэга <META> в возвращаемый пользователю HTML-документ подобным образом:

<meta http-equiv=Set-Cookie content="sessionID=2435345">

В данном случае взломщик может отправить следующую строку URL жертве атаки:

Следует помнить о том, что хотя тэги <META> обычно и размещаются между тэгами <HEAD> и </HEAD>, они также обрабатываются браузером в случае размещения в любой части HTML-документа.

Другие уязвимости механизма сессий

В этом разделе описывается множество других опасных ошибок, допускаемых при реализации механизма сессий.

Недостаточная проработка механизма учета времени окончания сессии

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

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

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

Хороший пример важности учета времени сессий можно наблюдать в интернет-кафе, где жертва атаки забывает завершить сессию и уходит. Следующий пользователь того же компьютера просматривает историю браузера для посещения последнего сайта из списка. В данном случае это страница банка с активной сессией пользователя. Теперь, так как сессия пользователя до сих пор активна, второй пользователь может перевести средства, от имени жертвы атаки. Однако, если бы приложение банка использовало период времени бездействия, равный, например, 2 минутам, ошибка жертвы атаки, заключающаяся в том, что сессия не была завершена, не дала бы шансов на выполнение мошеннических переводов средств следующему пользователю. Малая длительность сессии значительно снижает вероятность подобных ситуаций.

Пониженная криптостойкость алгоритмов шифрования

Пониженная криптостойкость алгоритмов для шифрования идентификаторов сессий является одной из наиболее часто встречающихся уязвимостей, позволяющей использовать атаки подбора или предсказания идентификаторов. Использование алгоритма хэширования md5 для шифрования идентификаторов сессий является сложившейся практикой, но было установлено, что идентификаторы сессий, зашифрованные с помощью данного алгоритма, могут быть легко расшифрованы с помощью таких свободных инструментов, как Cain & Abel, THC Hydra, John the Ripper, и.т.д.

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

Недостаточная длина идентификатора сессии

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

Незащищенная передача

Предположим, что веб-сайт не использует технологию SSL (поле secure в куках имеет значение false), при этом информация не защищена при помощи шифрования. В этом случае взломщики могут без лишних сложностей захватить HTTP-трафик и интерпретировать идентификаторы сессий с помощью сниффера.

Прокси-сервера и кэширующие сервера раскрывают все данные

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

Небезопасное хранение идентификаторов сессий на стороне сервера

Некоторые фреймворки используют специально выделенное место на диске веб-сервера для хранения данных сессий. В частности, PHP использует директории /tmp в UNIX и c:\windows\temp в Windows по умолчанию. Эти директории не предоставляют никаких механизмов защиты данных сессий, что может привести к получению доступа к данным веб-приложения при несанкционированном доступе к файловой системе веб-сервера.

Мероприятия по повышению безопасности

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

Мероприятия по защите от фиксации сессий

Так как фиксация сессий строится на том, что жертва атаки начинает работу с приложением в рамках сессии с идентификатором, выбранным взломщиком, должен быть применен механизм запрета входа в уже существующие сессии. Для этого веб-приложения должны отклонять любые идентификаторы сессий, заданные пользователями, а после успешной аутентификации пользователя вместо использования этих идентификаторов открывать новые сессии.
Использование сетевого адреса клиента и времени в качестве дополнительных данных для генерации идентификатора сессии и проведение дополнительных проверок при изменении сетевого адреса является неплохим шагом по повышению безопасности приложения.
Следует убедиться в том, что куки передаются в зашифрованном виде и атрибут secure установлен.
Не забудьте об устранении XSS-уязвимостей вашего веб-приложения - они могут значительно помочь в организации похищения и фиксации сессий. Для получения дополнительной информации об XSS-атаках обратитесь к части 2 данной серии статей.
Более того, если это возможно, добавьте функцию записи в журнал приложения или системный журнал информации о попытках соединения с некорректными или просроченными идентификаторами сессий, включающей в себя IP-адрес клиента.

Инструменты

Archilles является HTTP/HTTPS прокси-сервером, позволяющим перехватывать, сохранять и модифицировать веб-трафик в реальном времени.
Paros является набором инструментов для перехвата трафика (man-in-the-middle MITM) в режиме прокси. Эти инструменты позволяют перехватывать данные HTTP-сессий, передаваемые в обоих направлениях, и позволяют пользователю изменять данные перед отправкой. Вы можете использовать их для оценки восприимчивости ваших приложений к атакам на механизм сессий с использованием перехвата трафика.
Burp suite является интегрированной платформой для тестирования безопасности веб-приложений. Кроме функций перехвата трафика и прокси, данный инструмент может использоваться также и в качестве сканера веб-приложений.
Firesheep является расширением браузера Firefox для демонстрации атак похищения HTTP-сессий. Оно начинает работу в фоновом режиме сразу после установки с помощью Firefox. С помощью него можно без лишних сложностей осуществлять захват сессий. Сразу после захвата сессии взломщик может использовать полученную информацию для доступа к учетным записям, принадлежащим другим людям. Это действие реализуется путем перехвата незашифрованных данных кук от тех веб-сайтов, которые шифруют только идентификационные данные, но не шифруют куки, создаваемые после аутентификации. Для организации данной атаки взломщик должен находиться в публичной незащищенной сети (такой, как открытая сеть Wi-Fi), а в случае успешного завершения он может получить доступ к учетным записям пользователей, использующих данную сеть. Было установлено, что с помощью Firesheep можно без информирования пользователей получить доступ к их учетным записям Facebook, Twitter, Yahoo Mail, и.т.д., так как эти сайты используют протокол HTTPS/HTTP только для аутентификации, после чего обмен данными происходит по протоколу HTTP без шифрования. Это расширение довольно опасно, так как для его использования не требуется технических знаний; даже новичок может использовать его. Для того, чтобы не стать жертвой атаки с использованием Firesheep,используйте расширение Firefox HTTPS-Everywhere, которое конвертирует все строки URL (для доменов, внесенных в список расширения) для работы по протоколу HTTPS вместо HTTP. Аналогичным расширением является Force-TLS. Другое расширение Firefox, известное под названием BlackSheep, было создано в ответ на создание Firesheep. Это расширение уведомляет пользователя в том случае, когда кто-либо использует расширение Firesheep в его сети, предоставляя IP-адрес. Его принцип работы заключается в отправке некорректных идентификаторов сессий для определения наличия Firesheep. Также для этой цели может использоваться программа FireShepherd, так как целью ее работы является прекращение функционирования всех экземпляров Firesheep в используемой сети путем отправки специально сформированных пакетов.

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

Всегда помните: нужно знать все о взломе, но не заниматься им.

Дополнительные ресурсы

Продолжение серии: "Безопасная эксплуатация Apache, часть 7: атаки с использованием функций ОС сервера"