Руслан Рахметов, Security Vision
В работе и в повседневной жизни почти все из нас сталкиваются с необходимостью аутентификации, т.е. с прохождением проверки подлинности наших учетных записей (аккаунтов) при помощи учетных данных для входа на веб-сайты, в операционные системы и приложения - логинов, паролей, одноразовых кодов доступа, отпечатков пальцев или изображений. За успешной аутентификацией следует авторизация, т.е. определение полномочий и предоставление их пользователю на основе заданных в системе политик и правил доступа. Полномочия предоставляются в виде некоторого маркера доступа или кода в виде последовательности символов; в случае веб-приложений таким маркером будет или сессионная cookie (session cookie - традиционный, но более ресурсоемкий подход), или веб-токен доступа (например, JWT-токен, который выдается сервером авторизации, содержит подписанную информацию о правах доступа пользователя и предоставляется веб-приложению при запросе определенных ресурсов). В настоящий момент широко распространена мультифакторная аутентификация, управление учетными записями и доступом стало крупным бизнесом (например, для таких гигантов, как Microsoft, IBM, Oracle, Okta и других), а также наблюдается тенденция перехода к беспарольной аутентификации с помощью аппаратных или программных ключей (например, устройств FIDO2, чипов TPM, решений Apple iCloud Keychain, Google Password Manager, Samsung Pass, 1Password и прочих). Однако, так было не всегда, и многие веб-сайты и приложения до сих пор используют некоторые устаревшие методы аутентификации, включая логины и пароли. В сегодняшней статье поговорим об эволюции способов аутентификации, обсудим основные уязвимости различных методов проверки подлинности и противодействие мошенничеству с учетными данными.
В 1960 году в Массачусетском технологическом институте впервые стали использовать пароли в современном понимании - для разграничения доступа к файлам между научными сотрудниками на одном из первых в мире мейнфреймов. Уже в 1962 году там же был зарегистрирован первый в истории случай кражи паролей - один из сотрудников захотел использовать больше выделенного ему машинного времени для завершения рабочей задачи в срок, поэтому распечатал содержимое файла с паролями своих коллег, пользуясь своим доступом к мейнфрейму, и использовал их учетные записи. В дальнейшем отношение к безопасности паролей постепенно совершенствовалось: так, сначала встречались случаи хранения паролей в открытом виде (например, в конце 1960-х годов в мейнфреймах PDP-10), хэширование паролей было изобретено в 1974 году, а уже позднее совершенствовалась логика работы с паролями в *nix-системах - в них первоначально файл /etc/passwd содержал хэшированные пароли, но был доступен на чтение всем пользователям, что с ростом производительности ЭВМ означало повышение вероятности брутфорса, поэтому хэши паролей переместились в файл /etc/shadow, доступный только суперпользователю root. Со временем важность корректной аутентификации возросла, поэтому в 1986 году компания RSA представила первое средство двухфакторной аутентификации в виде брелка с небольшим экраном, отображающим цифровой код. Сегодня большинство современных сервисов и приложений предлагают пользователям применять мультифакторную аутентификацию, которая подразумевает наличие нескольких факторов, подтверждающих подлинность личности аутентифицируемого субъекта, например, фактор знания (пароль, секретный код, PIN-код), фактор владения (аппаратное устройство аутентификации, например, USB-токены Google Titan Security Key, YubiKey, Nitrokey или смартфон/сим-карта, на которые приходят push-оповещения или СМС), биометрический фактор (отпечаток пальца, фотография лица, радужная оболочка глаза, голос), географические и поведенческие характеристики субъекта (местоположение, скорость ввода пароля, перемещения курсора на веб-странице, скорость скроллинга и т.д.), технические характеристики устройства, с которого осуществляется попытка входа в аккаунт (ОС, разрешение экрана, версия браузера и т.д.). Однако, даже сейчас не все веб-сервисы используют современные способы аутентификации, зачастую предлагая пользователям ненадежные способы подтверждения подлинности или восстановления доступа, такие как:
1. «Секретные вопросы»: набор вопросов, как правило, предустановленных, на которые пользователю предлагается давать честные ответы, что по идее должно помочь пользователю восстановить доступ к учетной записи в случае забытого пароля. Например, типичным вопросом может быть «девичья фамилия матери», ответ на который атакующие могут найти в соцсетях или путем социальной инженерии. В случае, если сайт в обязательно порядке предлагает задать ответы на такие «секретные вопросы», то ответами на них должны стать комбинации символов (буквы, числа, спецсимволы), по сложности и длине не отличающиеся от основного пароля.
2. Запрет на использование спецсимволов при создании пароля, ограничение по длине и сложности пароля, нелогичные «рекомендации» сайта по выбору «сложного пароля»: некоторые сайты по различным причинам не разрешают использовать определенные символы в паролях или даже автоматически ограничивают длину создаваемого пароля без уведомления пользователя.
3. Отсутствие возможности создать произвольный логин, пересылка созданного пароля по email пользователю, присвоение дефолтного пароля (например, состоящего только из цифр), отсутствие возможности сменить пароль также иногда встречаются на некоторых веб-ресурсах.
4. Восстановление пароля без должной валидации: для восстановления доступа некоторые сайты требуют логин или email пользователя, при этом несложные манипуляции с POST/GET-запросами позволяют отправить одноразовый код или ссылку на восстановление доступа на произвольный email-адрес, чем пользуются злоумышленники. Кроме того, некоторые сайты используют не случайные длинные цифробуквенные последовательности символов в качестве кодов восстановления, а генерируют инкрементальные значения, в результате чего для условного пользователя user1 будет сгенерирован код восстановления вида 123456, а для user2 - 123457, для user3 - 123458 и т.д.
5. Некоторые веб-сайты по умолчанию разрешают пользователям аутентифицироваться только по одноразовым паролям, которые приходят по СМС, а функционал создания пароля спрятан глубоко в настройках учетной записи. Чем плох вариант с СМС-кодами - обсудим ниже.
Итак, с развитием интернет-коммерции веб-сайты и веб-приложения стали обрабатывать все больше важных сведений - персональных данных, платежной информации, финансовых данных. Для защиты доступа к такой информации началось внедрение средств двухфакторной аутентификации - первыми активно применяющимися способами стали USB eToken устройства (например, Рутокен, JaCarta, Aladdin, SafeNet и другие) в корпоративных локальных сетях для аутентификации пользователей операционных систем и бизнес-приложений, а также СМС-оповещения с одноразовыми кодами для интернет-сайтов. Именно СМС-оповещения стали на некоторое время самым простым способом для большинства - например, Google внедрила аутентификацию по СМС для пользователей Gmail еще в 2011 году, а в России граждане столкнулось с СМС-кодами верификации при работе в интернет-банкинге в начале 2010-х. Однако, второй фактор в виде СМС-кода не является надежным по следующим причинам:
1. Распространены атаки перевыпуска SIM-карты (англ. SIM swap, подмена сим-карты) - злоумышленники, пользуясь паспортными данными жертвы и поддельной доверенностью на перевыпуск дубликата сим-карты, обращаются в офис телеком-оператора, где им выдают новую сим-карту с интересующим их номером, при этом у настоящего владельца сим-карта работать перестает и всё выглядит так, будто что-то случилось с сотовой сетью или телефоном. Если подобное случится в ночное время или во время зарубежной поездки, то исправить ситуацию в кратчайшие сроки не получится, и мошенники смогут получить все входящие звонки и СМС. Отметим, что атаки перевыпуска сим-карт пользовались популярностью и зарубежом - так, например, взлом официального Twitter-аккаунта Комиссии по ценным бумагам и биржам США был осуществлен как раз путем перевыпуска сим-карты. При этом в последнее время российские операторы сотовой связи всё чаще используют «период охлаждения», который составляет обычно не больше суток - в течение этого времени на перевыпущенную сим-карту не будут поступать входящие сообщения. Кроме того, телеком-операторы оповещают банки о фактах смены сим-карты, а также могут проконтролировать изменение уникального IMSI-идентификатора сим-карты (что происходит при её замене) и изменение IMEI-идентификатора модуля сотовой связи смартфона (что происходит, когда пользователь меняет телефон или мошенник вставляет сим-карту в свой телефон). Кроме описанной мошеннической схемы с поддельной доверенностью, мошенники часто обращаются к услугам инсайдеров - нечистых на руку сотрудников операторов сотовой связи, которые за деньги перевыпускают сим-карту без необходимых документов. Еще одна распространенная схема - это поддельный судебный ордер, с которым к телеком-оператору может обратиться мошенник, выдающий себя за сотрудника силовых структур; на основании ордера оператор связи сообщит все данные по абоненту, включая историю звонков и СМС-сообщений, а также может предоставить доступ к этой информации в онлайн-режиме. Методом частичного противодействия атаке перевыпуска SIM-карты будет написание заявления в офисе оператора сотовой связи на запрет перевыпуска сим-карты по доверенности - в результате, перевыпуск сим-карты может быть произведен только при личном присутствии абонента в офисе оператора.
2. Банальная утеря или кража телефона также может оказаться фатальной: злоумышленники могут извлечь сим-карту из смартфона и вставить в свой телефон для получения входящих СМС. Для противодействия следует устанавливать на сим-карту пользовательский PIN-код.
3. Протокол SS7 (общеканальная система сигнализации №7), используемый в сетях 2G/3G, является небезопасным: исследования показывают, что атакующие, используя относительно ограниченные ресурсы, могут реализовать атаку на SS7 и получить доступ к звонкам и СМС-сообщениям интересующего их абонента. Кроме того, атакующие могут реализовать атаку на сотовую сеть и конкретного абонента с помощью поддельной базовой станции или фемтосоты. В настоящее время телеком-операторы внедряют решения для выявления попыток эксплуатации недостатков системы SS7. Также следует помнить, что при использовании сотовой связи присутствует возможность достаточно легко подменить отображающееся имя отправителя во входящем СМС-сообщении или номер вызывающего абонента при входящем звонке, поэтому, получив СМС с текстом о «запросе подтверждения подлинности» якобы от банка или телеком-оператора, не следует в ответ отправлять полученный в другом СМС-сообщении одноразовый код доступа.
4. Операторы сотовой связи поддерживают функцию переадресации звонков и СМС-сообщений на сторонние номера: подразумевается, что абонент сможет настроить переадресацию на другой номер, когда уезжает в командировку, например. Однако таким функционалом могут воспользоваться и атакующие, получив доступ к личному кабинету абонента (например, с помощью фишинга или социальной инженерии заставав продиктовать пароль для входа в кабинет из СМС) и сделав в нём соответствующие настройки переадресации. Кроме того, у некоторых операторов сотовой связи есть опасная опция «автовход» - автоматический вход в личный кабинет абонента без пароля в случае использования мобильного интернета от этого оператора, что также может привести к несанкционированному доступу к личному кабинету. Описанные опции следует отключить в личном кабинете, а также установить сложный пароль на доступ в него.
5. Заражение смартфона вирусом не спасет даже в случае использования более продвинутых способов аутентификации, но доступ к входящим СМС - это «классическая» функция почти любого вируса для мобильных устройств. Кроме того, в продаже встречаются простые кнопочные телефоны-звонилки, которые могут с завода содержать в прошивке вредоносные модули, в том числе выполняющие пересылку входящих СМС злоумышленникам.
6. Наконец, сим-карта может банально выйти из строя, перестать работать вдалеке от ближайшего офиса оператора или на неё по каким-то причинам не будут приходить сообщения (например, СМС-центр российского оператора недоступен из-за рубежа). В таком случае, также как и при использовании некоторых других способов аутентификации, пользователя может выручить резервный способ восстановления доступа с помощью предварительно сгенерированных и сохраненных в надежном месте кодов восстановления; например, Google предлагает заблаговременно сгенерировать десять одноразовых восьмизначных кодов восстановления, сохранить и распечатать их.
Резюмируя, можно сделать вывод о небезопасности использования одноразовых кодов из СМС-сообщений в качестве средства аутентификации. К счастью, современные сервисы предлагают использовать приложения на смартфоны в качестве средства двухфакторной аутентификации. Самыми яркими примерами таких программных аутентификаторов являются приложения Microsoft Authenticator, Google Authenticator, «Яндекс Ключ», Aegis Authenticator, andOTP и другие. Данные приложения могут либо генерировать одноразовые коды (на основе значения секретного ключа и встроенного счетчика или текущего времени), либо отображать push-уведомления о необходимости подтвердить вход в аккаунт. При добавлении такого метода аутентификации веб-сайт, как правило, предлагает сначала залогиниться с использованием логина и пароля, затем запустить совместимое приложение (тот же Microsoft Authenticator или Google Authenticator) и отсканировать отображаемый на веб-странице QR-код. Данный QR-код содержит текстовую строку с уникальным кратковременным URL-адресом, перейдя по которому приложение связывается по протоколу HTTPS с сервером аутентификации и получает секретный ключ, который помещается в защищенный раздел на смартфоне (например, в Apple Keychain или Android Keystore). Далее, при аутентификации в веб-сервисе, после ввода логина и пароля веб-страница либо попросит ввести одноразовый цифровой код, который сгенерирует настроенное приложение на смартфоне, либо отправит push-уведомление с запросом на подтверждение входа.
Данный вариант считается более надежным методом аутентификации, который, однако, не лишен недостатков:
1. При использовании программного аутентификатора веб-ресурсы всё равно требуют ввода логина и пароля, которые могут быть получены фишингом или социальной инженерией, а также, как правило, допускают откат на менее надежный способ подтверждения подлинности в случае смены смартфона или отсутствия интернет-соединения - в том числе посредством СМС-сообщений.
2. Атакующие, столкнувшись с необходимостью получения подтверждения от пользователя, «засыпят» приложение push-уведомлениями (техника называется Push Bombing или MFA Fatigue Attack) в надежде, что пользователь подумает о технической неисправности и в какой-то момент, устав от запросов, всё же подтвердит несанкционированный доступ, инициированный злоумышленниками. Кроме того, некоторые вендоры, например, Microsoft, вводят дополнительную проверку - в push-сообщении нужно указать двухзначное число, которое отображается на веб-странице, к которой пользователь получает доступ - это сделано для того, чтобы пользователю было понятно, к какой именно странице он подтверждает доступ.
3. Указанные методы не защищают от фишинга: в случае push-уведомлений злоумышленники могут применять методы социальной инженерии (например, позвонить пользователю от имени техподдержки и попросить подтвердить якобы «служебный» вход в аккаунт), а в случае с одноразовыми кодами, сгенерированными в приложении или полученными в СМС, атакующие используют фишинговые сайты, на которых пользователь вводит и логин, и пароль, и одноразовый код. На подобных фишинговых сайтах может быть настроен реверс-прокси (например, на базе Nginx), который пересылает все полученные от пользователя данные (логин, пароль, код) настоящему веб-сайту, получает от веб-сайта сессионную cookie или JWT-токен, которые затем злоумышленники используют для несанкционированного входа на сайт. Пользователь, тем временем, находится на странице фишингового ресурса, но видит в окне веб-браузера содержимое знакомого ему веб-сайта (включая все свои файлы, почту и т.д.), которое проксируется сервером злоумышленников для того, чтобы не вызывать лишних подозрений о подлинности ресурса у сотрудника - подобную атаку можно реализовать, например, через свободно распространяемую утилиту Evilginx. Для противодействия подобной технике веб-сайты могут контролировать одновременное использование одних и тех же сессионных cookie или JWT-токенов из разных географических точек, с разных IP-адресов, а также обнаруживать подобные Evilginx-инсталляции в интернете за счет поступающих от них множественных запросов на аутентификацию.
В итоге, можно заключить, что описанные способы аутентификации с помощью одноразовых кодов защитят пользователя только от взлома или подбора пароля (например, методами брутфорса, Password Spraying, Credential Stuffing), но не от фишинга.
Кроме того, всё более широкое использование QR-кодов (для аутентификации, оплаты услуг, перехода по ссылкам) вызывает у пользователей избыточное доверие к данной технологии. Следует помнить, что QR-код может содержать в себе текст (максимум 4296 цифробуквенных символов) и двоичный код (2953 байта), при этом чаще всего QR-код содержит ссылки с указанием различных протоколов или URI-схем. В настоящее время злоумышленники используют QR-коды для атак методом quishing (QR phishing), в котором вместо обычных текстовых ссылок пользователи получают email-сообщения с QR-кодами, по которым им предлагают перейти под разными предлогами, при этом в QR-коде содержится ссылка на вредоносный или мошеннический ресурс. Еще одна техника атак - QRLJacking: атакующие эксплуатируют ставший популярным в последнее время подход «Войти с помощью QR-кода», запатентованный Google еще в 2013 году. При нормальном использовании данного подхода легитимный веб-сайт (например, Web-версия мессенджера) отображает QR-код, содержащий сессионный токен, а соответствующее мобильное приложение (мессенджер) при сканировании в нём этого кода авторизует (подписывает своим закрытым ключом) данный токен для связи устанавливаемой веб-сессии с используемым аккаунтом в мессенджере - в результате, пользователь видит в браузере свои чаты и переписки так же, как в мобильном приложении. Однако атакующие могут скопировать QR-код для авторизации контролируемой ими веб-сессии и предложить пользователю отсканировать данный QR-код якобы для добавления в друзья или приобретения товара со скидкой в закрытом чате - в итоге, пользователь авторизует данную веб-сессию для атакующих, в рамках которой они смогут получить доступ ко всем перепискам и файлам пользователя, отключить легитимное приложение пользователя и полностью захватить аккаунт. Для защиты от подобных атак, помимо бдительности пользователя, создателям приложений с функционалом входа по QR-коду важно отображать пользователям уведомление о том, что они собираются авторизовать веб-сессию и это может привести к полному контролю над их аккаунтом.
Таким образом, рассмотренные выше способы мультифакторной аутентификации имеют те или иные недостатки, однако, разумеется, на рынке есть и решения, которые считаются сейчас достаточно надежными и не подверженными фишинговым атакам. Публикация NIST SP 800-63B "Digital Identity Guidelines" («Рекомендации по цифровой идентификации») описывает три уровня надежности аутентификаторов (Authenticator Assurance Levels, AALs):
· AAL1 - первый (самый низкий) уровень соответствует простой парольной аутентификации или использованию только одноразового кода для аутентификации;
· AAL2 - второй уровень требует использования средств мультифакторной аутентификации (например, вида «знание+владение» или «владение+биометрия») или комбинации двух однофакторных аутентификаторов (например, вида «знание+знание» и «владение+владение»);
· AAL3 - третий уровень требует использования средств мультифакторной аутентификации, включая программные и аппаратные устройства с защитой от фишинга.
Защиту от фишинга и полное избавление пользователей от паролей предлагает passkey - форма беспарольной аутентификации с использованием программных и аппаратных устройств-аутентификаторов, таких как устройства FIDO2, чипы TPM (технология Windows Hello), решения Apple iCloud Keychain, Google Password Manager, Samsung Pass, 1Password и т.д. По сути, passkey - это технология аутентификации по сертификатам (с использованием средств ассиметричной криптографии) с поддержкой беспарольной аутентификации, с широким функционалом и поддержкой новых аппаратных и программных аутентификаторов. При использовании технологии passkey для каждого веб-сайта, поддерживающего спецификацию WebAuthn, на программном или аппаратном пользовательском устройстве генерируется пара «закрытый - открытый ключ» и сертификат открытого ключа: открытый ключ используется веб-сайтом для проверки подлинности цифровой подписи (создается с помощью хранящегося на устройстве закрытого ключа) challenge-запроса сайта - если проверка проходит, то пользователь успешно аутентифицируется на сайте. Для доступа к закрытому ключу, хранящему на устройстве, пользователь должен разблокировать устройство: либо ввести PIN-код, либо приложить палец – таким образом реализовано требование предоставления второго фактора. Защита от фишинга достигается на основании того, что passkey-устройства сверяют адрес в браузере с адресом сайта, указанном в хранящемся на устройстве сертификате, и не производят аутентификацию в случае несоответствия, что и происходит при входе на фишинговый ресурс. Основными минусами применения passkey являются ограниченная поддержка беспарольного входа (пока что такой способ поддерживает несколько десятков крупных веб-сайтов), возможные проблемы с совместимостью некоторых устройств с некоторыми сайтами, а также необходимость приобретения аппаратного устройства для максимальной защиты (можно выбрать, например, USB-ключи Google Titan Security Key или последние модели YubiKey или Nitrokey). Кроме того, не все сайты разрешают полностью отказаться от стандартных методов аутентификации, поэтому атакующие могут реализовать атаку с понижением уровня (Downgrade Attack), например, за счет функционала восстановления доступа к аккаунту в случае утери или поломки аппаратного устройства, что зачастую сводится всё к тем же паролям и кодам из СМС.
Итак, в настоящее время полностью отказаться от паролей на всех веб-сайтах, увы, не получится, поэтому по-прежнему важно соблюдать определенные правила работы с паролями:
1. Создавайте уникальные пароли для каждого веб-сайта. Если есть возможность задать пользовательский логин, то можно использовать формат userlogin_website, где userlogin - ваше уникальное имя пользователя (делайте его по возможности таким же сложным, как и пароль), а website - адрес сайта, на котором вы регистрируетесь: в случае, если сайт допустит утечку и учетные данные пользователей будут опубликованы в интернете, такой подход поможет вам установить, с какого именно сайта была утечка, и предпринять соответствующие меры предосторожности (например, удалить всю информацию с этого сайта).
2. Не используйте шаблоны при создании паролей, например, формата website2024 (где website - адрес сайта, на котором регистрируетесь). При утечке данных с какого-либо сайта все пароли попадают на анализ злоумышленникам, которые могут понять, по какому шаблону/формату вы создаете пароли, и затем смогут подобрать пароль к вашей учетной записи на других сайтах.
3. При истечении срока действия пароля меняйте его полностью, а не только частично (например, лишь путем добавления одного-двух символов). Часто сайты требуют произвести внеплановую смену паролей из-за утечки, но если вы смените пароль лишь частично, то атакующие смогут подобрать ваш новый пароль на основании имеющегося у них старого пароля.
4. Проверяйте свои учетные данные на предмет утечек, например, на сайтах https://haveibeenpwned.com/ , https://monitor.mozilla.org/ , https://chk.safe-surf.ru/ .
5. Используйте надежные менеджеры паролей: они не только помогут создать сложный и надежный пароль, но и будут подставлять его только на подлинных, а не фишинговых веб-сайтах. Однако, не стоит забывать, что менеджер паролей - это как брелок для ключей, который позволяет потерять все ключи (пароли) сразу; такое может произойти, если в менеджере паролей обнаружат уязвимость.
6. Не забывайте, что аутентификация и авторизация - это разные процессы: за успешной аутентификацией следует передача пользователю определенного «секрета» (сессионной cookie, веб-токена доступа, билета Kerberos), который затем может быть украден или перехвачен атакующими и использован для несанкционированного доступа к ресурсам пользователя. Например, один из способов взлома Telegram (даже при включенной двухфакторной аутентификации) - это кража пользовательской сессии через доступ к папке с установленной Desktop-версией мессенджера на компьютере, в которой хранится токен доступа, полученный пользователем после легитимной аутентификации. Таким образом, вирусы на ПК и мобильных устройствах смогут получить неограниченный доступ к вашим учетным записям, несмотря на включенную мультифакторную аутентификацию.
7. Особую бдительность следует проявлять в отношении защиты аккаунтов, с которыми можно залогиниться на многие веб-сайты: крупные интернет-компании (Google, VK, Яндекс и т.д.) поддерживают протоколы OpenID Connect и OAuth 2.0 для входа на сторонние сайты с одной учетной записью (например, «Войти на сайт через профиль ВК»). Следует также помнить, что, кроме предоставления описанного функционала доступа, подобные интернет-гиганты могут обмениваться данными (покупки, действия, личные данные) о «своих» пользователях с этими сторонними сайтами.
