Читаем без скачивания 19 смертных грехов, угрожающих безопасности программ - Дэвид Лебланк

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

Что проверить трудно, так это качество самого протокола аутентификации. Хотя вы, конечно, можете узнать, посылаются ли пароли в открытом виде, но для понимания внутренней логики протокола лучше провести анализ кода.

Примеры из реальной жизни

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

И все же некоторые ошибки попали в базу данных CVE (http://cve.mitre.org). Мы рассмотрим парочку сообщений, а затем два примера, которые мы считаем «классической» иллюстрацией поджидающих вас опасностей.

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–интерфейс.

Как это могло случиться? Очевидно, противник каким–то образом узнал ее имя пользователя и зашел на сайт, заявляя, что он и является этим пользователем, но забыл свой пароль. Система была готова переустановить пароль, если получала правильный ответ на «личный вопрос», который запоминался при создании учетной записи. Если пользователь давал правильный ответ, то получал возможность сменить пароль.

Предположительно вопрос Хилтон был таким: «Кличка вашего домашнего любимца». Конечно, она выступала по телевидению вместе со своей собакой Tinkerbell, и противник это знал. Это и был правильный ответ, позволивший взломать ее учетную запись. Отсюда урок: персональную информацию, используемую для переустановки пароля, часто бывает легко получить. Лучше просто отправить новый пароль на почтовый адрес пользователя или, как в данном случае, на его мобильник в виде текстового сообщения. Хотя электронная почта – не самая безопасная среда, но для противника это дополнительная сложность, так как ему надо оказаться в таком месте, откуда можно организовать перехват почты. Это возможно, если противник имеет доступ к локальной сети, в которой жертва читает свою почту, но Хилтон такая мера все же помогла бы.

Искупление греха

О, вы много чего можете сделать, так что садитесь поудобнее! И приготовьтесь слушать.

Многофакторная аутентификация

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

□ Что вы знаете. Сюда относятся ПИНы, парольные фразы, в общем, все, что можно охарактеризовать как пароль.

□ Чем вы обладаете. Речь идет о смарт–картах, криптографических маркерах, кредитной карте и т. д.

□ Чем вы являетесь. Это различные виды биометрии.

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

Можно усилить аутентификацию, объединив все три технологии. Если противник похитит физический предмет, то ему еще предстоит узнать пароль. И даже если беспечная жертва оставит свой пароль под клавиатурой, противнику все же придется преодолеть барьер физического устройства аутентификации.

Подчеркнем, что защита системы усилится, лишь если вы будете учитывать при аутентификации разные факторы. Если же она построена по принципу «или–или», то противнику нужно взломать только самое слабое звено.

Хранение и проверка паролей

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

Стандартный и надежный способ дает алгоритм PBKDF2 (password–based key derivation function, Version 2.0 – функция выработки ключа на основе пароля, версия 2.0). Он описан в документе Public Key Cryptography Standard # 5 (PRCS #5–стандарт криптографии с открытым ключом). Хотя первоначально эта функция разрабатывалась для создания криптографического ключа из пароля, но она хороша и для наших целей, поскольку является стандартной, открытой и удовлетворяет всем выдвинутым требованиям. Она односторонняя, но детерминированная. Можно задать размер результата, так что выбирайте валидаторы длиной не менее 128 битов (16 байтов).