Здравия, хабралюди! думаю, многие помнят бородатый анекдот:
Однажды товаровед Валенька ушла на обед, не заблокировав 1С.
Добрые коллеги, шутки ради, добавили от имени Валентины накладную:
Получено: Наручники стальные, с розовым мехом (BDSM) 3 шт, ц.: 10000 р., сумма: 30000 р.
А после была в этом офисе ревизия, и долго ревизоры допытывались:
Зачем в офисе розовые наручники, и куда они пропали?

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

Надёжность паролей, взято с XKCD.com .

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

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

1. Сначала мы придумываем мнемонику (фразу для запоминания), например Серёга крутой хакер;
2. Затем переводим каждое из трёх слов на разные (знакомые Вам) языки, у меня вышло так: Серёга (оставим на русском) + атти (по-узбекски, я не знаю современную орфографию узбекского, которая на латинице) + hacker (англ.);
3. Далее всё, что записано не латиницей транслитерируем: Seryoga + qattiq + hacker;
4. Теперь немного исказим текст: Ser#gaQat7iqX@ker. Готово.

Достоинства метода:

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

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

Источники:
List of Rainbow Tables
Хит-парад паролей

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

Мы живем в опасное время

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

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

npm как источник угроз

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

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

Малоизвестно, но разработчики npm активно использовали помощь компании ^Lyft Security (эксперта по компьютерной безопасности) с самого начала разработки платформы: специалисты из Lyft не только активно проверяли исходный код npm на наличие уязвимостей, но и проводили регулярные аудиты безопасности и pen-тесты серверной инфраструктуры. Помимо прочего, консультанты из Lyft активно участвовали в разработке так называемой Node Security Platform (NSP) [платформы безопасности Node], которая отвечает за безопасность экосистемы Node и npm-пакетов. Партнерство двух компаний оказалось настолько удачным, что в начале 2018-го года npm Inc. просто купила ^Lyft Security, и её эксперты по безопасности напрямую влились в команду npm.

Таким образом, компания npm обладает выделенной командой экспертов по безопасности, которые занимаются исключительно этими вопросами, существенно улучшая здоровье самой крупной в мире экосистемы (JavaScript). За всё время работы над Node Security Platform компании npm удалось внедрить много важных решений и инструментов, которые значительно повышают безопасность и позволяют нам чуточку лучше спать по ночам.

Кроме того, в начале 2020 года компания GitHub (Microsoft) купила npm Inc., что автоматически увеличило ресурсы компании и открыло прямой путь для интеграции между npm и GitHub. А, как известно, у GitHub также имеется своя серьезная команда по безопасности GitHub Security Lab. Наличие таких значительных ресурсов и возможностей для коллаборации должно еще сильнее повысить безопасность экосистемы, ведь теперь Microsoft может полностью отследить и обезопасить путь от исходного кода на GitHub до скомпилированного пакета в npm registry.

---

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

Сканирование пакетов

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

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

Чтобы повысить эффективность сканера, команде npm удалось собрать самую большую в мире библиотеку вредоносного кода на JavaScript, которая постоянно пополняется. Эта библиотека, в том числе, содержит списки опасных доменных имен, IP-адресов и URL, которые могут использоваться злоумышленниками, а также другие индикаторы заражения. Команда npm планирует открыть доступ к этой библиотеке, которая получила название Security Insight API. Это позволит энтузиастам со стороны разрабатывать собственные решения, которые еще более повысят безопасность экосистемы.

Автоматический отзыв токенов аутентификации

npm поддерживает аутентификацию при помощи специальных токенов вместо логина и пароля. Это необходимо для публикации пакетов в npm registry, для работы с закрытыми (private) пакетами в рамках автоматизированных процессов (например, используя CI/CD-конвейер), а также для интеграции со сторонними решениями.

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

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

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

Компрометация паролей

Довольно часто пользователи используют один и тот же пароль между различными сервисами и аккаунтами. При этом они могут даже не догадываться, что их данные оказались в публичном доступе из-за утечки с одного из сайтов, где они были зарегистрированы. Сервис Have I Been Pwned содержит огромную базу данных утечек и позволяет по вашему E-mail адресу определить, попали ли именно ваши данные в одну из них. Например, мой адрес на GMail, которым я пользуюсь уже 11 лет, попал аж в 14 утечек. Я уверен, вас тоже ждут интересные новости!

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

Ручной аудит пакетов

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

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

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

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

По словам специалистов из npm, из всех отчетов об уязвимостях, которые им присылают, только 20 % в итоге подтверждаются и доходят до публикации. На момент написания этого поста в базе npm было 1427 рекомендаций по безопасности (security advisories). Полный список рекомендаций можно посмотреть на официальном сайте в специальном разделе. Также доступен список рекомендаций со стороны GitHub.

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

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

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

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

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

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

Краткое содержание

• Guardicore обнаружили сложный ботнет пиринговой (P2P) сети FritzFrog, который еще с января 2020 года активно взламывал SSH серверы.
• Вредоносное ПО на Golang: FritzFrog исполняет модульный, мультипоточный и безфайловый вредоносный код на Golang, который не оставляет следов на жестком диске зараженного устройства.
• Активное таргетирование государственных, образовательных, финансовых и прочих ресурсов: FritzFrog пытался брутфорсить и распространяться на десятках миллионов IP адресов правительственных офисов, образовательных учреждений, медицинских центров, банков и множества телекоммуникационных компаний. Среди них успешно подвержены атаке оказались более чем 500 серверов, включая известные университеты США и Европы, и одну железнодорожную компанию.
• Сложность: FritzFrog полностью проприетарен, его имплементация P2P написана с нуля, что говорит о высоком уровне профессионализма его создателей в области разработки ПО.
• Перехват: Guardcore Labs разработали клиентскую программу на Golang, способную перехватывать P2P соединения FritzFrog и подключаться к сети как пир.
• Принадлежность: мы не смогли определить конкретную группу, ответственную за создание FritzFrog, однако текущий ботнет частично похож на ранее известный ботнет Rakos.

Введение

FritzFrog это очень изощренный пиринговый ботнет, который активно взламывает SSH серверы по всему миру. Благодаря своей децентрализованной структуре он распределяет контроль по всем своим узлам. В этой сети нет единой точки отказа, и пиры постоянно общаются друг с другом, чтобы поддерживать ее в устойчивом, обновляемом и постоянно активном состоянии. P2P соединение проводится через зашифрованный канал с использованием AES для симметричного шифрования и протокола Диффи-Хеллмана для обмена ключами.

В отличие от других P2P ботнетов, FritzFrog уникален набором своих свойств: он безфайловый, поскольку собирает и исполняет пакеты прямо в памяти; несмотря на эффективное равномерное распределение целей в своей сети, он очень агрессивно их брутфорсит; его проприетарные P2P протоколы не основаны ни на одной из ныне известных реализаций.

Написанный на Golang вредоносный код очень переменчив и не оставляет следов на жестком диске. Он создает бэкдор в виде публичного SSH ключа и тем самым открывает злоумышленникам постоянный доступ к устройству жертвы. С самого начала его активности мы выявили 20 различных версий исполняемого вредоносного ПО.

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

Guardicore Labs предоставили доступ к Github репозиторию со скриптом для обнаружения этого вредоносного ПО и списком индикаторов компрометации (IoC) его деятельности.


Географическое распределение зараженных узлов. Наиболее подверженными атакам странами оказались США, Китай и Южная Корея.

Исследование FritzFrog

Впервые Guardcore Labs обратили внимание на деятельность FritzFrog в ходе исследования Botnet Encyclopedia. 9 января были обнаружены новые атаки с исполнением вредоносных процессов ifconfig и nginx. Мы начали отслеживать стабильный и значимый рост вредоносной деятельности, которая вскоре достигла 13 тысяч атак на Guardcore Global Sensors Network (GGSN). За все время мы отследили 20 различных версий бинарников FritzFrog.


График демонстрирует количество атак FritzFrog на GGSN.

Удивительным оказалось то, что вредоносный код на первый взгляд не связывался с каким-либо сервером командования и контроля (CNC). Только когда мы начали серьезно исследовать ботнет, мы поняли что никакого сервера не было и в помине.

Для перехвата сети ботнета Guardcore Labs разработали на Golang клиент, способный обмениваться ключами с вредоносным ПО, а так же отправлять команды и получать ответы. Эта программа, которую мы затем назвали фроггер, позволила нам исследовать природу и задачи сети, и благодаря фроггеру мы добавили в сеть наши собственные узлы, сумев подсоединиться к ботнету, и поучаствовали в передаче данных активного P2P трафика.

FritzFrog брутфорсил миллионы IP адресов, среди которых оказались правительственные офисы, образовательные учреждения, медицинские центры, банки и множество телекоммуникационных компаний. Из них успешно подвержены атаке оказались более чем 500 серверов, включая известные университеты США и Европы, и одну железнодорожную компанию.

Новое поколение P2P

Почему Новое поколение?

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

• Безфайловость: FritzFrog работает без рабочей директории, а обмен файлами происходит прямо в памяти через массивы двоичных данных (BLOB).
• Постоянные обновления: базы данных целей и пораженных устройств обновляются плавно и органично.
• Агрессивность: брутфорс ведется с использованием обширного словаря. Для примера, недавно обнаруженный P2P ботнет DDG в поле логина использовал только root.
• Эффективность: Цели равномерно распределены между узлами.
• Проприетарность: P2P протокол ботнета полностью проприетарен и не основывается на каком-либо из известных P2P протоколов, например TP.

Как только жертва оказывается успешно взломана, на ней запускается UPX-запакованный вредоносный код, который затем тут же сам себя удаляет. Для минимизации подозрений вредоносные процессы исполняются под наименованиями ifconfig и nginx. В самом начале своей работы вредоносный код прослушивает порт 1234 в ожидании команд. Первые полученные команды синхронизируют жертву с базой данных пиров сети и целей брутфорса.


Кластер узлов сети FritzFrog. Каждый узел это зараженный SSH сервер. Размер узлов демонстрирует их связность с остальной сетью.

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


FritzFrog туннелирует свои P2P команды через классический SSH порт, для чего пользуется локальным netcat клиентом зараженного устройства.

Злоумышленники FritzFrog внедрили зашифрованный командный канал с более чем 30 различными командами. Параметры команд и отклики передаются в указанных структурах данных и выпускаются (мобилизуются) в формате JSON. Перед отправлением данные зашифровываются симметричным шифрованием AES и кодируются в Base64. Для обмена ключами участвующие в передаче данных узлы используют протокол Диффи-Хеллмана.



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

Погружение во вредоносный код

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

FritzFrog определяет состояния управления жертвой и целевым устройством следующим образом:

1. Target (цель): устройство из запроса цели будет затем передано модулю Cracker, который в свою очередь постарается просканировать и взломать его.
2. Deploy (развертывание): успешно взломанное устройство встает в очередь на заражение вредоносным кодом через модуль DeployMgmt.
3. Owned (владение): успешно зараженное устройство будет добавлено в P2P сеть модулем Owned.

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


Рабочая функция в дизассемблере. Каждая ветка соответствует поддерживаемому P2P функционалу.

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

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDJYZIsncBTFc+iCRHXkeGfFA67j+kUVf7h/IL+sh0RXJn7yDN0vEXz7ig73hC//2/71sND+x+Wu0zytQhZxrCPzimSyC8FJCRtcqDATSjvWsIoI4j/AJyKk5k3fCzjPex3moc48TEYiSbAgXYVQ62uNhx7ylug50nTcUH1BNKDiknXjnZfueiqAO1vcgNLH4qfqIj7WWXu8YgFJ9qwYmwbMm+S7jYYgCtD107bpSR7/WoXSr1/SJLGX6Hg1sTet2USiNevGbfqNzciNxOp08hHQIYp2W9sMuo02pXj9nEoiximR4gSKrNoVesqNZMcVA0Kku01uOuOBAOReN7KJQBt

Вредоносный файл прогоняет всевозможные команды оболочки на локальном устройстве, некоторые по несколько раз, для отслеживания состояния системы. Например, он прогоняет free m для проверки доступной оперативной памяти, uptime, journalctl s @0 u sshd для отслеживания SSH логинов, и прочие команды для вывода статистики нагрузки процессора. Эта статистика оказывается доступна другим узлам в сети, и используется для принятия различных решений, например запускать ли криптомайнер на устройстве или нет. Если решение принято, вредоносный код запускает отдельный процесс, libexec, для майнинга Monero. Этот майнер основан на популярном майнере XMRig и связывается с публичным пулом web.xmrpool.eu через порт 5555.

Злобная торрентоподобная сеть

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

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

Когда узел А хочет получить файл от своего пира, узла B, он моет выслать узлу В запрос getblobstats чтобы узнать какими массивами он владеет. Затем узел А может получить конкретный массив через его хэш, как с помощью P2P команды getbin, так и с помощью HTTP по адресу http://1234/. Как только узел А получает все массивы, он собирает файл через модуль Assemble и запускает его.


Результат команды getblolbstats. Каждый узел в сети сообщает, каким он обладает массивом в соответствии с поддерживаемым списком файлов.

Присвоение

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

Даже при сравнении с другими P2P ботнетами FritzFrog остается уникальным: он не использует IRC как это делает IRCflu, в отличие от DDG он работает прямо в памяти, и он запускается на Unix-устройствах в противовес ботнету InterPlanetary Storm. Если он на кого и похож, особенно в плане наименования функций и нумерации версий, так это на Rakos, P2P ботнет на Golang, проанализированный ESET еще в 2016 году.

Отслеживание действий И смягчение последствий

Guardcore Labs предоставили скрипт по отслеживанию FritzFrog для запуска на SSH серверах. Он ищет следующие индикаторы ботнета:

• Запуск процессов nginx, ifconfig или libexec, чей исполняемый файл более в системе не существует (как можно видеть ниже).
• Прослушивание порта 1234.

В дополнение к этому, TCP трафик через порт 5555 может указывать на сетевой трафик к пулу Monero.

ubuntu@ip-111-11-11-11:~$ ./detect_fritzfrog.sh
FritzFrog Detection Script by Guardicore Labs
=============================================

[*] Fileless process nginx is running on the server.
[*] Listening on port 1234
[*] There is evidence of FritzFrog's malicious activity on this machine.

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

Слабые пароли оказываются ключевой уязвимостью для атак FritzFrog. Мы рекомендуем использовать сильные пароли и публичные ключи авторизации, что намного безопаснее. Кроме того, критически важно исключить публичный ключ FritzFrog из файла authorization_keys чтобы не дать злоумышленникам доступ к устройству. Роутеры и IoT устройства обычно раскрывают свой SSH и потому становятся уязвимы для атак FritzFrog; мы рекомендуем сменить таким устройствам SSH порт или, если функционал не используется, полностью отключить SSH.

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

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

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



В большинстве случаев выполнение биологической идентификации малореализуемо, особенно когда мы говорим о безопасности веб-приложений, поэтому при двухфакторой аутентификации (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-атак!

Доброго времени суток.

Просторы интернета давно не являются безопасным пространством (если его вообще можно было когда-либо считать как таковым) для пользователя. Тем более необычным является то, что многие не считают нужным (или не знают как) соблюдать относительно простые правила, так называемой, IT-гигиены.



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

Давайте приступим.

Нюансы проблематики

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

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

Если говорить обобщенно, то в рамках IT-гигиены можно выделить такие относительно простые правила как:

• Наличие отдельных почт для серьезных аккаунтов и всех остальных;
• Использование блокировщиков рекламы, а, в идеале, скриптов, iframe, cookies и всего подобного;
• Наличие VPN (хотя бы бесплатного);
• Использование разных паролей для всех сайтов без исключения (помогает в этом Lastpass, Keepass и другие менеджеры паролей);
• Повсеместно должна быть включена двухфакторная аутентификация, причем, желательно, не с использованием sms, а кода с использованием приложений;
• И, пожалуй, такая простая, но очевидная вещь, как не хранить пароли в очевидных местах, будь это физические решения вроде пароля на листочке под клавиатурой (или стикером на мониторе) или где-нибудь в блокнотике на рабочем столе или переписки в телеграмме.

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

Теперь давайте подробнее.

Отдельная почта

Старейшим и простейшим из методик IT-гигиены можно считать наличие отдельной почты для серьезных и важных вещей.

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



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

Блокировщики рекламы

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



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

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

Разные пароли

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

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



Наиболее удобным способом будет использование расширения, например, Lastpass. Умеет генерировать, хранить и систематизировать пароли от всех сайтов, есть для всех браузеров, прост и неприхотлив в настройке.



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




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

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

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

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



К сожалению, не все сервисы поддерживают (но уже очень много таковых есть, это и Google, и дискорды и многое что еще) его, но там где есть нужно использовать. На класс увеличивает защиту аккаунта и, в отличии от смс, не подвержен типовым обходам, вроде подделки сим-карты и перехвата кодов.

Приложений для этого есть уже достаточное количество. Из основных это Google Authenticator и тот же Lastpass Authenticator. Какие-то сервисы используют свои приложения (Яндекс.Ключ, Microsoft Authenticator) и не поддерживают сторонние. Это не очень удобно, но лучше чем смски или вообще без защиты.

VPN

Является основным из критериев IT-гигиены. Дарит приватность, защищает от утечек IP-адреса (и не только) и не даёт привязать аналитику непосредственно к Вам, шифрует трафик и скрывает многое другое.



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



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

Не хранить пароли

Почему-то всё ещё существует практика хранения паролей где попало. Не надо так делать. Храните пароли или в голове и/или в сервисах типа упомянутых выше Lastpass. Решения вроде стикеров на монитор, пароля под клавиатурой, телеграмма, блокнота и тп, это весьма небезопасные (что уже неоднократно доказано) идеи и так делать не стоит вообще и совсем.

Послесловие

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

На днях в сети появился файл объемом в 100 ГБ с 8,4 млрд паролей внутри (8 459 060 239 уникальных записей). Эксперты предполагают, что эти пароли компиляция предыдущих утечек. Логинов в файле нет, только пароли размером от 6 до 20 символов. Огромное их количество сложные пароли со спецсимволами. Все они содержатся в одном файле с названием RockYou2021.txt.

Выложил этот файл пользователь с одноименным ником RockYou2021. Скорее всего, этот ник является отсылкой к утечке 2009 года, которая называлась Rock You. Но та утечка была в разы меньше в файле, выложенном в 2009 году, содержалось всего 32 млн строк.

Количество паролей в файле превышает население Земли, которое пока еще не добралось к отметке в 8 млрд. Общее число интернет-пользователей на планете, по разным оценкам, составляет примерно 5 млрд человек. Можно предположить, что многие пароли реальны и ими до сих пор пользуются.


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


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

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

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

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

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

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

Кстати, в феврале 2021 года в сети оказался еще один список 3,2 млрд связок логин/пароль от учетных записей почтовых сервисов Microsoft и Google. Тот файл представлял собой компиляцию многих других утечек, случившихся ранее.

А что насчет других утечек?

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

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

В 2020 году в сеть утекло около 100 млн записей персональных данных россиян, что гораздо опаснее, чем выложенный кем-то файл с миллиардами паролей. При этом около 80% нарушений пришлось на сотрудников компаний, большая часть в результате умышленных действий. В России чаще других утечки случаются в финансовых сервисах, госсекторе и hi-tech отрасли.

Что касается мира, то по итогам 2020 года в сети появилось около 11 млрд записей персональных данных и платежной информации (понятно, что в таких утечках на одного пользователя приходится несколько учеток, это не 11 млрд отдельных учеток). Самой большой утечкой можно считать проблему с Whisper у сервиса украли 900 млн записей одномоментно, то есть в сеть слили все записи со дня основания ресурса в 2021 году. На втором месте китайский сервис Weibo, допустивший утечку примерно 500 млрд записей. На третьем компания Estee Lauder. Здесь никаких хакеров не понадобилось, компания сама выложила 440 млн учеток на одном из облачных сервисов.

Всем привет! В прошлом посте мы начали рассматривать важный вопрос о безопасности в 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-проекта. Я настоятельно рекомендую всегда иметь эти аспекты в виду и внедрить описанные инструменты у себя в наше сложное время дополнительные меры защиты никогда не будут лишними.

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

---

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

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

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