Шрифт:
Многие другие проблемы можно выявить с помощью специализированных сценариев или тестирования вручную. Например, понять, какова политика управления паролями. Для тех аспектов политики, которые связаны со временем, придется проявить творческий подход. Например, если вы хотите знать, заставит ли приложение сменить пароль по истечении заданного времени, то, наверное, не стоит ждать несколько месяцев, проще перевести часы сервера вперед.
Что проверить трудно, так это качество самого протокола аутентификации. Хотя вы, конечно, можете узнать, посылаются ли пароли в открытом виде, но для понимания внутренней логики протокола лучше провести анализ кода.
Примеры из реальной жизни
Есть множество примеров парольных систем, в которых обнаружены серьезные дефекты. Проблемы встречаются настолько часто, что мы уже к ним привыкли и часто склонны не обращать внимания на опасность. Поэтому многие приложения, которые, строго говоря, нарушают правила безопасности (например, в финансовом мире, где к качеству паролей, частоте их смены и т. д. предъявляются жесткие требования), не считаются среди специалистов непригодными к использованию.
И все же некоторые ошибки попали в базу данных CVE . Мы рассмотрим парочку сообщений, а затем два примера, которые мы считаем «классической» иллюстрацией поджидающих вас опасностей.
CVE–2005–1505
В почтовом клиенте, поставляемом в составе системы MAC OS X 10.4, есть мастер для создания новых учетных записей. При создании записи для протокола IMAP мастер спрашивает, хочет ли пользователь защитить соединение по протоколу SSL/TLS. Но даже если вы соглашаетесь, программа уже собрала всю необходимую для входа информацию и с помощью нее установила соединение с сервером – без всякого SSL/TLS. Противник может перехватить начальный обмен данными и узнать пароль.
Хотя в данном случае риск однократный, но этот пример иллюстрирует тот факт, что при проектировании многих базовых протоколов Интернет защите паролей не уделялось сколько–нибудь серьезного внимания. Считается допустимым, что почти все почтовые клиенты в мире отправляют по сети пароли для протоколов IMAP или POP в открытом виде. Даже при использовании шифрования принимающая сторона может увидеть незашифрованный пароль и что–то сделать с ним. Все широко используемые протоколы в этом отношении никуда не годятся, признать их хотя бы условно приемлемыми можно лишь, если пользователь защищает канал по протоколу SSL/TLS. Однако во многих случаях это не делается. Иногда пароли хранят в открытом виде, и редко когда прилагаются хоть какие–то усилия к тому, чтобы качество паролей было высоким.
Конечно, сеть Интернет проектировалась во времена, когда люди больше доверяли друг другу. Пароли – это средство получить неавторизованный доступ к ресурсам, поэтому, проектируя свои приложения, не будьте столько прекраснодушны, как отцы–основатели Интернет.
CVE–2005–0432
Это простой, документированный пример широко распространенной проблемы. Сервер BEA WebLogic версий 7 и 8 выдает разные сообщения об ошибках, когда вводится несуществующее имя пользователя и неправильный пароль. В результате противник, априорно не знающий имен пользователей, все же может отыскать действительные учетные записи и провести для них атаку полным перебором.
Ошибка в TENEX
Гораздо более известная утечка информации имела место в операционной системе TENEX. Когда пользователь хотел войти в систему, у него запрашивали имя и пароль. Проверка пароля производилась примерно так:
for i from 0 to len(typed_password):
if i >= len(actual_password) then return fail
if typed_password[i] != actual_password[i] then return fail
if i < len(actual_password) then return fail
return success
Противник мог угадать пароль, пробуя строки, размещенные в памяти на границе страниц. Если он хотел узнать, начинается ли пароль с буквы «а», то мог поместить строку «а» на одну страницу, а строку «ххх» – на другую. Если пароль действительно начинается с буквы «а», то произойдет отказ из–за отсутствия следующей страницы в памяти, в результате которого она будет загружена. Если же догадка ошибочна, то отказа не будет. Обычно задержка будет настолько маленькой, что для получения статистически значимого результата придется провести много испытаний. Но если пароль пересекает страницы и символ непосредственно перед границей угадан правильно, то время, затрачиваемое менеджером виртуальной памяти на загрузку отсутствующей страницы в память, настолько велико, что задержка видна невооруженным взглядом. Таким образом, для проведения атаки уже не нужно разбираться в математической статистике, достаточно знать этот фокус.
Но и не прибегая к страничному отказу, можно путем статистической обработки измеренного времени ответа добиться того же результата, только для этого придется автоматизировать тесты. Возможность подобной атаки – это одна из причин, по которой в хороших системах регистрации для обработки паролей применяются криптографические односторонние функции хэширования.
Кража у Пэрис Хилтон
В начала 2005 года во всех новостях прошел сюжет о том, что кто–то «хакнул» мобильный телефон модели T–Mobile Sidekick, принадлежащий актрисе Пэрис Хилтон, и опубликовал в Интернете все содержимое его памяти, включая контактные данные многих знаменитостей. На самом деле взломали не телефон. Архитектура Sidekick устроена так, что многие данные хранятся на сервере, так что владелец имеет к ним доступ как с телефона, так и из Web. Противник сумел взломать учетную запись актрисы и перекачать информацию через Web–интерфейс.