Коллектив авторов - Защита от хакеров корпоративных сетей

Аутентификация приложений

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

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

Во-первых, ключ должен быть действительно случайным. Любая предсказуемость ключа повысит шансы злоумышленника вычислить его. Ключ не следует вычислять при помощи линейной возрастающей функции. Системные функции UNIX /dev/random и /dev/urandom могут не обеспечить необходимой случайности ключей, особенно при генерации ключей большого размера. Например, слишком быстрый вызов функций /dev/random или /dev/ urandom может отразиться на «случайности» генерируемых ключей, потому что в этом случае функции обращаются к предсказуемому генератору псевдослучайных чисел.

Во-вторых, ключевое пространство должно быть достаточно большим по отношению к числу ключей, необходимых в любой момент времени. Пусть ключ имеет 1 млрд возможных значений. Страшно даже подумать об атаке «грубой силы» на ключевое пространство в 1 млрд ключей. Но популярный сайт электронной коммерции может обслуживать около 500 000 открытых сессий каждый рабочий день. В этом случае у злоумышленника хорошие шансы найти подходящий ключ в каждой серии из 1000 проверенных ключей (в среднем) и его не отпугнет последовательный перебор 2000 ключей со случайно выбранного значения.

Рассмотрим некоторые современные схемы аутентификации. Какое-то время назад организация PacketStorm (www.packetstormsecurity.org) решила перепрограммировать на языке Perl программное обеспечение своего Web-форума после нахождения уязвимости в пакете wwwthreads.

authkey=rfp.23462382.temp&uname=rfp

Рассматривая систему аутентификации как «черный ящик» без малейшего представления о принципах его работы, была предпринята попытка найти закономерности работы системы при изменении входных данных параметров. Первый шаг состоял в изменении значения параметра authkey: сначала имени пользователя, а затем случайного числа и дополнительной величины «temp». Целью данных манипуляций было проверить возможность аутентификации пользователя с другими случайными недействительными значениями параметра. Не получилось. Затем значение параметра uname было изменено на другое правильное имя пользователя. В результате была получена строка вида

authkey=rfp.23462382.temp&uname=fringe.

После этого удалось зарегистрироваться под именем другого пользователя («fringe»). Исходя из этого, был восстановлен фрагмент программы аутентификации на языке Perl (заметим, что без знания истинного кода форума PacketStorm):

if (-e “authkey_directory/$authkey”) {

print “Welcome $uname!”;

# do stuff as $uname

} else {

print “Error: not authenticated”;

Таким образом, authkey – это файл, создаваемый при входе в систему с использованием случайного числа. Приведенный фрагмент программы позволяет любому пользователю, изменившему параметр uname, получить доступ к учетной записи иного пользователя, используя известный и правильный authkey (например, свой собственный).

Основываясь на форматах параметров authkey и uname, естественно было предположить, что значение authkey относится к файловой системе. Прежде всего потому, что значение параметра authkey в формате username.999999. temp не похоже на информацию, которую хранят в базе данных. Вполне возможно, что приложение разделяло параметр authkey на три части, используя для запроса к базе данных имя пользователя и случайное число. При этом отпадала необходимость в передаче через значение параметра uname имени пользователя, а постоянное окончание «.temp» становилось бесполезным и бессмысленным. Следуя интуиции и зная, что формат представления параметра authkey похож на задание имени файла, было высказано предположение, что значение параметра authkey определяет имя файла, как в итоге и оказалось.

if (-e “ authkey_directory/$authkey” && $authkey=~/^$uname/) {