Адрес электронной почты ключевой элемент защиты личных данных. На него часто завязаны другие учетные записи пользователя. Завладев чужим e-mail, злоумышленник в состоянии восстановить или сбросить пароли связанных со взломанной учеткой сервисов. Если человек не использует двухфакторную аутентификацию (2FA), то он практически беззащитен. Двухфакторная аутентификация тоже не панацея, но здесь киберпреступнику потребуются дополнительные усилия нужно перевыпустить SIM-карту или перехватить код аутентификации. Реализовать перехват достаточно сложно, поскольку коды обычно присылают в SMS или приложении-аутентификаторе.


^{Скриншот одного из сайтов, предлагающих услуги по взлому почтовых аккаунтов}
Как бы там ни было, взлом почтовых ящиков востребованная услуга. Интересно, что часто ее заказывают не прожженные преступники, а подозрительные супруги или влюбленные. Муж или жена просто хотят быть в курсе онлайн-переписки своей половинки, поэтому заказывают взлом. Используют подобную возможность и конкуренты по бизнесу ведь при успешном взломе можно получить доступ к секретам соперника.

Взлом почтового ящика в терминологии ИБ считается таргетированной или целевой атакой. Такими вещами занимается государственная разведка вроде АНБ и ГРУ, но есть и черный рынок услуг для простых смертных, где можно заказать взлом любого ящика за скромную плату. Это рынок хакеров по найму (hack-for-hire). Он активно процветает в РФ, поскольку здесь, в отличие от западных стран, за такие мелкие преступления не грозит уголовная ответственность.

Несмотря на популярность, инфраструктура этого рынка не слишком хорошо изучена. О том, как работают эти хакеры и насколько большую угрозу они представляют, известно мало. Но подробности постепенно появляются. Так, относительное небольшое исследование рынка провела Ариана Мириан из Калифорнийского университета в Сан-Диего. Результаты опубликованы на конференции WWW'19: The World Wide Web Conference и в научном журнале Communications of the ACM (December 2019, Vol. 62 No. 12, Pages 32-37, doi: 0.1145/3308558.3313489).

Сколько стоит такая услуга?

Команда проекта выявила и изучила 27 розничных сервисов по взлому учетных записей электронной почты. Большинство услуг рекламировалось на русском языке. Стоимость услуги от $23 до $500 за один аккаунт. Дешевле всего получить доступ к ящикам российских провайдеров. Западные стоят дороже, а взлом аккаунтов Facebook и Instagram обойдётся чуть дешевле, чем Yahoo и Gmail.

^{Цены на взлом почтовых ящиков и аккаунтов. Иллюстрация: Калифорнийский университет Сан-Диего}
При помощи подставных учетных записей Ариана Мириан связалась с исполнителями и заказала взлом учеток подставных жертв. На каждом аккаунте была включена двухфакторная аутентификация по SMS.

Методика проведения эксперимента

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

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

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

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

Наконец, анализировался весь сетевой трафик на сайт каждой из жертв. Если злоумышленник заходил на сайт со страницы Facebook, это отражалось в записи трафика.

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

Результаты

Только 5 из 27 хакеров стали выполнять условия задачи, поставленной заказчиком.



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

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

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

<sup>Приманки, которые использовали хакеры для фишинга: письма якобы от Google (выделены зеленым), государственной службы (красным), из банка (оранжевым), от незнакомца (темно-синим) или от знакомого человека (голубым). Крестик соответствует успешному взлому аккаунта. В правой колонке указано количество писем. Иллюстрация: Калифорнийский университет Сан-Диего

Пример поддельного письма из суда. Иллюстрация: Калифорнийский университет Сан-Диего

Фишинговая страница, похожая на окно ввода пароля Gmail. Источник: Калифорнийский университет Сан-Диего</sup>
Все атаки начинались с письма-приманки от авторитетной организации или лица. Это должно было успокоить жертву и привести ее к необходимому действию переходу по ссылке на фишинговый ресурс. Злоумышленники использовали разные подставные фигуры: знакомого человека жертвы, крупный банк, незнакомца, государственную организацию и Google. К письму прилагалось изображение или фишинговая ссылка.

В среднем злоумышленники отправили 10 сообщений в течение 25 дней, используя разные предлоги, как показано на диаграмме выше. Самый популярный прием подделать письмо Google, затем следуют письма от партнеров и подставные e-mail от незнакомцев.

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

Как не стать жертвой киберпреступников

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

Чтобы защитить себя и родственников от подобных атак, специалисты рекомендуют использовать для 2FA аппаратный USB-ключ безопасности, а также быть внимательными это стандартная рекомендация.

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

Двухфакторая аутентификация

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

Знание считается одним фактором аутентификации; двумя другими распространёнными факторами являются то, что у вас есть, например, физическое устройство, и то, кем вы являетесь, например, отпечатки пальцев или сетчатка глаза.



В большинстве случаев выполнение биологической идентификации малореализуемо, особенно когда мы говорим о безопасности веб-приложений, поэтому при двухфакторой аутентификации (two factor authentication, 2FA) обычно используется второй атрибут то, что у вас есть. Одним из популярных вариантов этого второго фактора является физический токен, например, RSA SecurID:


Физический токен часто используется для аутентификации в корпоративных VPN и финансовых сервисах. Для аутентификации в сервисе нужно использовать и пароль, и код на токене (который часто изменяется) в сочетании с PIN. Теоретически, для идентификации нападающий должен знать пароль, иметь токен, а также знать PIN токена. В сценарии сброса пароля сам пароль очевидно неизвестен, однако обладание токеном можно использовать для подтверждения владения аккаунтом. Разумеется, как и в случае с любой реализацией защиты, это не обеспечивает защиту от дурака, но определённо повышает барьер входа.

Одна из основных проблем такого подхода стоимость и логистика реализации; мы говорим о передаче физических устройств каждому клиенту и об обучении их новому процессу. Кроме того, пользователям нужно иметь с собой устройство, что в случае физического токена бывает не всегда. Ещё один вариант реализовать второй фактор аутентификации с помощью SMS, которое в случае 2FA может служить подтверждением того, что человек, выполняющий процесс сброса, имеет мобильный телефон владельца аккаунта. Вот как это делает Google:


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


После идентификации адреса электронной почты аккаунта Google определяет, что была включена 2FA и мы можем сбросить аккаунт с помощью верификации, которая передаётся через SMS на мобильный телефон владельца аккаунта:


Теперь нам нужно выбрать начало процесса сброса:


Это действие приводит к отправке электронного письма на зарегистрированный адрес:


Это письмо содержит URL сброса:


При выполнении доступа к URL сброса отправляется SMS и веб-сайт просит его ввести:


Вот это SMS:


После ввода его в браузер мы возвращаемся на территорию классического сброса пароля:


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

Проблема связана со смартфонами. Показанное ниже устройство может удостоверять только один фактор аутентификации оно способно получать SMS, но не электронную почту:


Однако вот это устройство может получать SMS и получать письма о сбросе пароля:


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

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

Сброс по имени пользователя против сброса по адресу электронной почты

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

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

Так что же происходит, когда кто-то забывает своё имя пользователя? Если принять, что имя пользователя не является сразу адресом электронной почты (а такое бывает часто), то процесс похож на то, как начинается сброс пароля вводим адрес электронной почты, а затем отправляем сообщение на этот адрес, не раскрывая его существования. Единственное отличие в том, что на этот раз сообщение содержит только имя пользователя, а не URL сброса пароля. Или это, или в электронном письме будет написано, что для этого адреса нет аккаунта.

Проверка личности и точность адресов электронной почты

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

Очевидно, что электронная почта является наиболее удобным и самым распространённым каналом проверки личности. Она не защищена от неумелого обращения (от дурака), и существует множество случаев, когда простой возможности получать письма на адрес владельца аккаунта недостаточно, если требуется высокая степень уверенности в идентификации (поэтому и используется 2FA), однако почти всегда она является начальной точкой процесса сброса.

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

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

Идентификация того, кто инициировал процесс сброса

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

Вот пример из функции сброса, которую я сейчас встраиваю в ASafaWeb:


Ссылка find out more (Узнать больше) переносит пользователя на сайт ip-adress.com, сообщающий такую информацию, как местоположение и организация запрашивающего сброс:


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

Уведомление об изменениях по электронной почте

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

Причинами смены пароля могут служить два источника:

1. Смена пароля после входа в систему, потому что пользователь хочет новый пароль
2. Сброс пароля без входа в систему, потому что пользователь его забыл

Хотя этот пост в основном посвящён сбросу, уведомление в первом случае снижает риск того, что кто-то изменит пароль без ведома законного владельца. Как такое может произойти? Очень распространённым сценарием является получение пароля законного владельца (повторно использованного пароля, утекшего из другого источника; пароля, полученного кейлоггингом; легко угадываемого пароля и т.д.), после чего злоумышленник решает его изменить, заблокировав таким образом владельца. Без уведомления по электронной почте настоящий владелец не будет знать о смене пароля.

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

О, и на случай, если это ещё не очевидно не отправляйте новый пароль по почте! Кого-то это может рассмешить, но подобное случается:

Логи, логи, логи и ещё немного логов

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

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

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

Делегирование ответственности другим исполнителям

Если вы считаете, что всё это представляет огромный объём работы, то вы не одиноки. На самом деле, построение надёжной системы работы с аккаунтами непростая задача. Дело не в том, что она тяжела технически, просто в ней есть множество особенностей. Она заключается не только в сбросе, существует целый процесс регистрации, надёжное хранение паролей, обработка множественных неверных попыток входа в систему и т.д, и т.п. Хотя я продвигаю идею использования готовой функциональности наподобие ASP.NET membership provider, помимо неё нужно сделать ещё многое.

Сегодня существует множество сторонних поставщиков, с радостью берущих на себя все мучения и абстрагирующих всё это в один управляемый сервис. Среди таких сервисов есть OpenID, OAuth и даже Facebook. Некоторые люди безгранично верят этой модели (OpenID и в самом деле оказался очень успешным на Stack Overflow), однако другие в буквальном смысле считают её кошмаром.

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

Злонамеренный сброс

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

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

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

Самое слабое звено

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

ASafaWeb хостится на потрясающем сервисе, предоставляемом AppHarbor. Процесс сброса аккаунта хостинга происходит так:

Этап 1:


Этап 2:


Этап 3:


Этап 4:


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

Смысл в том, что стойкость реализации защиты следует рассматривать целостно: нужно смоделировать угрозы каждой входной точки системы, даже если это поверхностный процесс, например, вход в систему AppHarbor. Это должно дать мне хорошее представление о том, сколько усилий мне нужно вложить в процесс сброса пароля ASafaWeb.

Соединяем всё вместе

Этот пост содержит большой объём информации, поэтому я хочу сконцентрировать его в простой визуальной схеме:


Помните, что следует выполнять максимально подробный логгинг каждого из этих пунктов. Вот и всё, это просто!

Итоги

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

Даже несмотря на то, что сброс не так сложен, часто его реализуют неправильно. Выше мы видели пару примеров, когда реализация может привести к проблемам, и существует гораздо больше прецедентов, когда неправильный сброс действительно вызвал проблемы. Недавно выяснилось, что сброс пароля использовали для кражи биткойнов на сумму 87 тысяч долларов. Это серьёзный негативный результат!

Поэтому будьте аккуратнее со своими функциями сброса, моделируйте угрозы в разных точках, а при проектировании функции не снимайте своей чёрной шляпы, потому что есть большая вероятность, что её наденет кто-то другой!

---

На правах рекламы

VDSina предлагает недорогие серверы в аренду с посуточной оплатой, каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!

Часто задаваемый вопрос, как надежно защитить свой VPS / выделенный сервер от взлома? Поэтому я решил написать инструкцию о внедрении двухфакторной аутентификации.

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

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

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



Берем в руки телефон и осуществляем настройку приложения аутентификатора. Сделать это достаточно просто. Можно использовать разные программы, но я рекомендую Twilio Authy 2-Factor Authentication.
Скачать ее можно по этой ссылке: https://play.google.com/store/apps/details?id=com.authy.authy&hl=ru
Официальный сайт программы: authy.com
Преимуществом Twilio Authy 2-Factor Authentication является возможность работать сразу на нескольких устройствах одновременно, даже на десктопе или ноутбуке. В Google Authenticator такой возможности нет. Если вы вдруг потеряете свой смартфон, вы сохраните все свои данные для доступа к аккаунтам.
Устанавливаем приложение с Google Play и запускаем его. Затем система попросит ввести код страны и номер телефона. Обязательно указывайте тот номер телефона, к которому у вас имеется доступ. Также не забудьте указать свой e-mail.



Следующий шаг подтверждение. Выберите тот способ, который наиболее удобен для вас получение sms-сообщения или ответ на звонок.
Пакет аутентификатора нужно будет установить в систему. Делается это следующим образом:
Для Debian 9/10:
root@alexhost:~# apt install libpam-google-authenticator - y

Для CentOS в первую очередь нужно будет подключить epel репозиторий:
root@alexhost:~# yum install epel-release

Только после этого можно будет установить пакет:
root@alexhost:~# yum install google-authenticator

На следующем этапе запускаем
root@alexhost:~# google-authenticator

Система задаст вопрос: Do you want authentication tokens to be time-based (y/n. Отвечаем y, т.к такой вариант наиболее надёжный.



На вопрос Do you want me to update your "/root/.google_authenticator" file? (y/n) отвечаем y

На вопрос Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) отвечаем в зависимости от того, насколько сильно вы беспокоитесь о безопасности и готовы ради нее пожертвовать удобством.

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

Дальше нас ждет еще один вопрос: By default, a new token is generated every 30 seconds by the mobile app. In order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. This allows for a time skew of up to 30 seconds between authentication server and client. If you experience problems with poor time synchronization, you can increase the window from its default size of 3 permitted codes (one previous code, the current code, the next code) to 17 permitted codes (the 8 previous codes, the current code, and the 8 next codes). This will permit for a time skew of up to 4 minutes between client and server. Do you want to do so? (y/n) отвечаем y

Очередной вопрос: If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s.

Вновь смотрите, что для вас важнее удобство или безопасность. Единственного правильного ответа нет, все зависит от ваших предпочтений. Если вы ответите y, система разрешит не более 3 попыток входа в течение 30 секунд.



Следующее, что вам нужно будет сделать это нажать на + в приложении аутентификаторе и отсканировать предложенный qr код в терминале



Затем понадобится установить защитный пароль для бекапов, который будет состоять минимум из 6 символов. Разумеется, все аккаунты, добавленные в приложение, сохраняются в облаке.
Сохраните свой аккаунт под любым удобным вам именем



Внимание! Не забудьте записать экстренные коды. В рассматриваемом нами случае, это:
Your emergency scratch codes are:
13455461
88816366
91315051
48752467
40022285

root@alexhost:~# nano /etc/pam.d/sshd

В самом конце файла необходимо будет добавить auth required pam_google_authenticator.so
Сохраните файл Ctrl+O, а затем нажмите Enter
Выходим из редактора, нажав одновременно клавиши Ctrl+X
Кстати, вы без проблем сможете воспользоваться другим текстовым редактором. Вам вовсе необязательно использовать nano



Следующее, что нужно сделать:
root@alexhost:~# nano /etc/ssh/sshd_config заменить ChallengeResponseAuthentication no на ChallengeResponseAuthentication yes
Не забудьте обязательно добавить в конце файла AuthenticationMethods keyboard-interactive
Нажимаем Ctrl+O и сохраняем файл, затем Enter
Выходим из редактора Ctrl+X



На одном из последних этапов нужно будет перезапустить службу ssh
root@alexhost:~# systemctl restart sshd

Подключаемся. Система сперва запрашивает пароль, затем двухфакторный ключ



Вот и все поздравляем, настройка успешно завершена!

---

Немного рекламы

1.5 GB RAM / 1 Ядро / 10GB SSD диска 4 /месяц или 11.88 в год!
4GB RAM / 2 Ядро / 40GB SSD диска 10 /месяц или 60 в год!
8GB RAM / 4 Ядра / 80GB SSD диска от 16 /месяц или 144 в год!
ТУТ AlexHost.com

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

До недавних пор нигде, кроме как при входе в аккаунт, пароль не запрашивался. Дела изменились тогда, когда добавили возможность передачи канала другому аккаунту, а сегодня и передачу ботов. Мало того, что для трансфера необходимо соответствовать критериям, например, иметь включенную 2FA и просидеть с ней 7 дней, не менять пароль и прочее, дык ещё и повторно ввести пароль при переносе статуса владельца канала. И это замечательно!

Каково было моё удивление, когда я решил сменить мобильный номер на своём основном аккаунте. Следите за действиями: зашёл в настройки, нажал на редактирование, тапнул по номеру, подтвердил намерения, ввёл новый номер, ввёл код, который пришёл SMSской на новый номер, всё



Чего-то не хватает Как-то слишком просто Ах, да, а где 2FA как при передаче канала? Она же у меня включена! Ладно если бы я ей не пользовался!

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

Теперь никто не может войти в аккаунт. После смены номера человек закрыл все сессии на ваших других девайсах, оставив только тот, что отобрал. Вы не в силах войти в аккаунт, так как вам нужен код с SMS на номер, который вы не знаете. Злоумышленник не в силах войти с другого устройства, так как ему нужен пароль от 2FA, но у него есть доступ к вашему аккаунту! Больше ему и не надо!

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

В Telegram есть механизмы по удалению аккаунтов, когда сотовый оператор передал номер другому владельцу, а номер оказался зарегистрированным и с 2FA. Столкнулся с этим лично. У меня было 7 дней для отмены всей процедуры. Чтобы её отменить необходимо ввести код из SMS с номера, доступа к которому у меня уже не было. Другим вариантом было сменить номер телефона на другой. Я просто перенёс всё с того аккаунта на другие ии его удалили.

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

Только что вышло обновление Bot API 5.0! Очень сочно, за это отдельное спасибо, но помимо этого довели до прода возможность передачи прав на ботов между аккаунтами. И даже несмотря на то, что всё управление через BotFather'a (официального бота), оно умудряется запрашивать 2FA! Такой тип inline кнопки не задокументирован. При нажатии всплывает окошко с вводом пароля.

Посмотрев на всевозможные случаи, увидев разные подходы в Telegram, можно попросить Павла (@durov) только об одном Давайте использовать подтверждение 2FA не только при входе и смене владельца бота/канала, но и при смене номера телефона и удалении аккаунта.


Конечно, что уж тут говорить про возможность удаления аккаунта без 2FA, когда его всё ещё можно удалить с помощью переименования аккаунта в Saved Messages.


Моя самая маленькая статья, поэтому без привычного спасибо, что дочитали аж до сюда.

P.S. Не используем Face ID, сканеры отпечатков пальцев. Не храним пароли в голове. Генерируйте случайные, храните в парольных менеджерах. Хоть что-то, хоть как-то. Идеально не будет никогда.
P.S.S. Спасибо Олегу, за удаление двух аккаунтов для видеоматериала данной статьи.

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

Скрипты установки

Команда npm install поддерживает ряд скриптов (например: preinstall, install/postinstall), которые могут выполняться в процессе установки пакета. При этом содержимое таких скриптов ничем не ограничивается и выполняется от лица пользователя, выполняющего установку. Такие скрипты являются одним из основных способов для злоумышленников влезть в компьютер, на котором устанавливается вредоносный пакет, и похитить важную информацию.

Пример пакета, содержащего вредоносный скрипт:

Если пользователь выполнит команду установки пакета из примера выше: npm install malicious-package, то это приведет к выполнению скрипта evil.sh, который потенциально может совершить любые действия от лица текущего unix-пользователя.

Возможно, вы слышали, что в середине 2018 года произошел громкий инцидент с пакетами eslint-scope и eslint-config-eslint, когда злоумышленник смог получить к ним доступ и опубликовать новую версию пакетов, содержащую вредоносный код в скриптах установки.

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

Чтобы изолировать проблему, команде npm пришлось отозвать все токены npm, которые были сгенерированы до даты начала атаки. Это привело к тому, что npm registry начал испытывать проблемы с доступностью, потому что пользователи начали массово перевыпускать токены, не говоря о том, что это нарушило работу огромного количества автоматизированных конвейеров, которые обращались к npm с использованием токенов.

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

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

Если у вас есть существенные причины не доверять устанавливаемому пакету, то вы можете запретить выполнение скриптов установки при помощи следующей команды:

npm install suspicious-package --ignore-scripts

Также, вы можете полностью запретить выполнение скриптов установки при помощи следующей команды (или добавить настройку в .npmrc):

npm config set ignore-scripts true

Но учтите, что некоторые пакеты используют скрипты установки для собственной инициализации и не будут корректно работать при установке с запретом на запуск скриптов. Такую практику стоит использовать только в том случае, если у вас есть очень серьезные на то причины.

Ограничение среды выполнения

Чтобы дополнительно обезопасить себя от подобных атак, постарайтесь максимально ограничить среду, в которой выполняются команды npm, такие как npm install. Как вариант, их можно выполнять внутри Docker-контейнера, на виртуальной машине или в любой другой песочнице с ограниченным доступом. Разумеется, никогда не стоит запускать npm от лица root-пользователя; наоборот, лучше запускать эти команды от лица пользователя с минимальным доступом и набором прав. Антивирусы и брандмауэры также могут сократить риски. Принцип прост: чем меньше полномочий получит процесс npm, тем безопаснее будет его работа.

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

Безопасность токенов и ключей

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

Если вам всё же необходимо использовать токен аутентификации npm в каком-то автоматическом конвейере (например, для CI/CD), то ограничьте его полномочия. Например, если токен нужен только для установки пакетов из приватного репозитория, то создавайте его в режиме read-only, чтобы в случае его утечки злоумышленник не мог отправить вредоносный код в ваш репозиторий. Это позволит ограничить масштаб угрозы.

Также хорошей практикой является привязка токена аутентификации npm к определенному диапазону IP-адресов (CIDR). Закажите себе статический IP (или серию IP) и привяжите его к своему серверу. Как правило, любой облачный провайдер позволяет это сделать, даже если ваш сервер запускается по запросу (on-demand). Таким образом, если злоумышленник сможет украсть токен, то он не сможет использовать его с другой машины.

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

Сгенерировать новый токен можно при помощи команды npm token create, которая опционально принимает следующие аргументы:

• --read-only создаёт токен, который позволяет только считывать данные из репозитория (т. е. устанавливать пакеты, но не публиковать их);
• --cidr=<CIDR> создаёт токен, который позволяет аутентифицироваться только хостам в указанном диапазоне IP. Рекомендую использовать калькулятор CIDR, чтобы быть уверенными в корректности задания диапазона IP. Пример: --cidr=192.0.2.0/24.

Также рекомендуется регулярно проводить аудит всех токенов, привязанных к npm-аккаунту, и отзывать ненужные. Посмотреть список всех токенов можно в личном кабинете на сайте npm, либо при помощи команды npm token list.

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

Аутентификация в файле ~/.npmrc выглядит следующим образом:

//registry.npmjs.org/:_authToken=00000000-0000-0000-0000-000000000000

Если вы используете различные независимые npm registry, то таких строк может быть несколько.

Убедитесь, что содержимое файла ~/.npmrc доступно только вашему unix-пользователю!

Что касается закрытых ключей шифрования (например, для SSH), то убедитесь, что они защищены сильным паролем и используют надежный алгоритм шифрования. В случае компрометации такого ключа злоумышленник не сможет им воспользоваться, т. к. не знает пароль, а методы математического взлома окажутся неэффективными. В случае с SSH, в настоящее время алгоритм EdDSA считается наиболее надежным. Однако стоит учесть, что старые системы могут его не поддерживать. Тогда используйте два ключа: Ed25519 (EdDSA) для всех совместимых систем и RSA (с минимум 2048 битным ключом) для устаревших систем.

Очепятки

Одним из старейших приемов в рукаве злоумышленников является использование названий, похожих на оригинальные, но отличающихся одним или несколькими символами. Пользователи часто совершают опечатки при вводе тех или иных названий. Особенно это критично при вызове команды, например, npm install packae-name: в лучшем случае это приведет к ошибке 404, а в худшем может вызвать вредоносный код.

Команда npm старается автоматически вычислять попытки подобного подлога и блокировать пакеты, которые выдают себя за другие. Вам же, как пользователю, следует просто внимательнее относиться к вводу названий пакетов с клавиатуры, по возможности пользуйтесь функцией copy-and-paste.

Безопасные пароли

Про правила использования безопасных паролей сказано уже очень много, не вижу смысла повторяться, однако отмечу основные моменты:

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

Для решения всех вышеописанных вопросов стоит использовать специальное ПО: менеджер паролей. Я использую открытый KeePass (есть версии практически для любой платформы). Базу данных паролей стоит защитить сложным мастер-паролем, который вам необходимо запомнить. Дополнительно можно использовать файл-ключ, который хранится, например, на флешке. Сам же файл базы данных можно положить в любое облачное хранилище (Яндекс.Диск, Google Drive или DropBox), чтобы иметь к нему синхронизированный доступ сразу со всех устройств.

Мой коллега недавно перевел статью, в которой подробнее разбирается вопрос оптимальной длины пароля, рекомендую ознакомиться!

Мультифакторная аутентификация (MFA)

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

К счастью, npm также поддерживает двухфакторную аутентификацию при помощи программ-аутентификаторов. Она работает в двух режимах: только аутентификация или аутентификация и запись. Лучше всего использовать режим аутентификация и запись, т. к. это гарантирует самый высокий уровень безопасности, потому что npm будет просить вас ввести токен OTP не только при вызове команды npm adduser, но и при любой попытке записать что-то в реестр (например, при вызове npm publish).

О том, как включить npm 2FA, написано подробно в официальной документации. Процесс в целом ничем не отличается от стандартного: вам нужно выбрать режим работы, а затем просканировать QR-код, который будет показан на экране при помощи выбранной вами программы-аутентификатора. Сделать это можно как через личный кабинет на официальном сайте, так и через CLI при помощи команд:

• npm profile enable-2fa auth-and-writes
  режим аутентификация и запись (рекомендуется)
• npm profile enable-2fa auth-only
  режим только аутентификация

При использовании CLI npm попросит вас ввести пароль от аккаунта (даже если вы уже аутентифицированы), а затем покажет QR-код. После сканирования кода нужно ввести одноразовый пароль (OTP), который покажет приложение на устройстве, чтобы подтвердить успешность процедуры.

При привязке аутентификатора npm также выдаст вам набор одноразовых кодов восстановления, их необходимо сохранить в надежном месте, на случай, если придется восстанавливать доступ к аккаунту при утере аутентификатора.

Если утеря всё же произошла, вы можете ввести неиспользованный ранее код восстановления вместо одноразового пароля при аутентификации, а затем сбросить 2FA командой npm profile disable-2fa, введя затем еще один код восстановления. Если же вы потеряли и аутентификатор, и коды восстановления, то вам придется обратиться в службу поддержки npm (надеюсь, они защищены от социальной инженерии).

Ограничение публикуемых файлов

По умолчанию, когда вы выполняете команду npm publish, npm собирает в архив все файлы в директории пакета за исключением некоторых.

Часто из-за этого в registry утекают файлы, которые не должны быть опубликованы, например, файлы с паролями. Это серьезная угроза безопасности. Если вы случайно отправили в реестр npm какие-то чувствительные файлы, то вам придется не только удалить архив пакета из реестра, но и полностью заменить все скомпрометированные данные.

А чтобы обезопасить себя от подобных утечек, я рекомендую всегда использовать поле files в файле package.json. Оно представляет собой массив, содержащий перечисление файлов (можно использовать шаблоны glob), которые должны попасть в архив собранного пакета. Такой явный подход гарантирует, что в публичный доступ случайно не утекут какие-то нежелательные файлы.

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

• package.json
• README
• CHANGES, CHANGELOG, HISTORY
• LICENSE, LICENCE
• NOTICE
• Файл, указанный в поле main

При этом файлы README, CHANGES, LICENSE и NOTICE могут иметь любой регистр символов в названии и расширение.

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

Чтобы проверить, что же попадет в архив при запуске команды npm publish, можно использовать флаг --dry-run либо команду npm pack --dry-run. Вторая команда, в отличие от первой, пропустит скрипты препаблишинга и сразу попытается собрать архив. Аргумент --dry-run гарантирует, что изменения будут произведены в тестовом режиме только на вашей машине, пакет не будет никуда отправляться, и архив не будет реально создан в файловой системе.

Продолжение следует

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

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

---

Если вам понравился материал, то, пожалуйста, ставьте лайки, подписывайтесь на наш блог и делитесь ссылками с коллегами. Так мы будем понимать, что наша работа востребована и продолжим радовать вас новыми полезными материалами.

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

Все изображения в статье являются собственностью своих авторов или законных правообладателей и используются исключительно в некоммерческих образовательных целях.