Методы выявления typosquatting-атак через анализ названий пакетов

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

Практический подход состоит не в определении вредоносности только по имени, а в создании механизма поиска потенциально опасных совпадений. Такая система сравнивает названия пакетов, выделяет необычные случаи и передаёт их для дальнейшего анализа метаданных, содержимого и истории публикаций. Исследования атак на цепочку поставок программного обеспечения показывают, что похожие имена могут использоваться для введения разработчиков в заблуждение, однако надёжное обнаружение требует сочетания нескольких признаков. citeturn0search1turn0academia24

Как работает обнаружение подозрительных имён пакетов

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

Анализ имён обычно включает несколько последовательных этапов:

1. Формирование доверенного набора названий известных пакетов, например используемых внутри организации или популярных в конкретном реестре.
2. Нормализация имён с учётом правил выбранной экосистемы.
3. Расчёт нескольких показателей сходства между названиями.
4. Поиск кандидатов с необычно близкими именами или характерными изменениями.
5. Учёт контекста: популярности исходного пакета, области имён, назначения проекта и истории публикаций.
6. Передача подозрительных случаев на дополнительную проверку перед установкой.

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

Нормализация имён перед сравнением

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

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

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

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

Расстояние Левенштейна как базовый метод

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

• вставка символа;
• удаление символа;
• замена одного символа другим.

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

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

Взвешенные расстояния и смысл операций

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

Например:

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

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

Damerau-Levenshtein и перестановки символов

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

Например, условное имя pakcage отличается от package перестановкой двух соседних символов. Обычный алгоритм Левенштейна может оценить такую ошибку менее естественно, тогда как Damerau-Levenshtein учитывает её как отдельную операцию.

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

N-граммы и сходство Jaccard

N-граммные методы рассматривают название пакета как набор последовательных фрагментов определённой длины. Например, биграммы состоят из двух символов, а триграммы — из трёх.

Условное имя library можно представить как набор триграмм: lib, ibr, bra, rar, ary. Чем больше общих фрагментов у двух строк, тем выше их сходство.

Jaccard similarity сравнивает пересечение и объединение таких наборов. Упрощённо показатель показывает долю общих n-грамм среди всех уникальных фрагментов двух имён.

Преимущества метода:

• хорошо выявляет длинные совпадающие части строк;
• подходит для быстрого поиска среди больших наборов данных;
• дополняет методы на основе редакционных расстояний.

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

Косинусное сходство и векторизация имён

Ещё один подход — представить имя пакета в виде вектора признаков. Например, можно использовать частоты символов или n-грамм, а затем сравнивать полученные представления с помощью косинусного сходства.

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

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

Unicode, визуальное сходство и confusable characters

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

При анализе имён следует учитывать:

• смешение латинских и других алфавитов;
• Unicode-символы с похожим отображением;
• редко используемые символы в конкретной экосистеме;
• правила допустимых символов выбранного реестра.

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

Клавиатурные модели опечаток

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

Такая модель может учитывать:

• соседние клавиши;
• пропуск символов;
• двойной ввод одной буквы;
• перестановку соседних символов;
• разные раскладки клавиатуры.

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

Подмена структуры имени пакета

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

• добавление префиксов или суффиксов;
• удаление части названия;
• повторение отдельных фрагментов;
• изменение разделителей;
• замена одного смыслового компонента.

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

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

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

Приоритет кандидатов можно рассчитывать с учётом:

• популярности исходного пакета;
• степени сходства названий;
• характера изменения символов;
• редкости нового имени;
• контекста использования;
• наличия нескольких независимых признаков.

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

Сравнение методов анализа названий пакетов

Метод	Что обнаруживает	Сильные стороны	Ограничения	Сценарий применения
Левенштейн	Вставки, удаления и замены	Простота и понятная интерпретация	Не различает смысл операций	Первичный поиск близких имён
Damerau-Levenshtein	Также перестановки соседних символов	Лучше отражает типичные опечатки	Не решает проблему смыслового сходства	Поиск ошибок ввода
N-граммы и Jaccard	Общие фрагменты строк	Подходят для индексации больших наборов	Зависят от длины имени и значения N	Быстрый поиск кандидатов
Косинусное сходство	Сходство векторных представлений	Гибкость при разных наборах признаков	Требует правильной подготовки данных	Комбинированные системы поиска
Клавиатурная модель	Ошибки, связанные с вводом	Учитывает поведение пользователя	Зависит от языка и раскладки	Оценка вероятных опечаток
Unicode/confusable-анализ	Визуально похожие символы	Выявляет отдельный класс подмен	Может создавать ложные срабатывания	Проверка необычных символов
Комбинированный скоринг	Несколько типов сходства одновременно	Учитывает разные сигналы	Требует настройки и контроля качества	Промышленные процессы проверки

Скоринг кандидатов на typosquatting

Практические системы обычно объединяют несколько признаков. Иллюстративная модель может учитывать:

• редакционное расстояние;
• сходство n-грамм;
• клавиатурную близость;
• визуальное сходство символов;
• популярность исходного пакета;
• длину имени;
• тип изменения названия.

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

Практический алгоритм обнаружения

1. Получить список доверенных и известных пакетов.
2. Выполнить нормализацию имён по правилам выбранного реестра.
3. Создать механизм предварительного поиска кандидатов, чтобы не сравнивать каждый пакет со всеми остальными.
4. Рассчитать несколько показателей сходства для найденных пар.
5. Определить характер изменения имени.
6. Учесть популярность и контекст исходного пакета.
7. Исключить очевидные легитимные совпадения.
8. Сформировать список приоритетных кандидатов.
9. Проверить метаданные и содержимое подозрительных пакетов перед принятием решения.

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

Ложные срабатывания при анализе имён

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

Основные причины ложных срабатываний:

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

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

Почему анализ только названия недостаточен

Сходство имени пакета является поводом для проверки, а не доказательством вредоносности. Решение об использовании или блокировке зависимости должно учитывать дополнительные признаки.

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

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

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

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

Проверку похожих имён можно встроить на разных этапах жизненного цикла проекта:

• регулярный анализ новых пакетов в используемых реестрах;
• проверка новых зависимостей перед добавлением в проект;
• анализ lock-файлов;
• проверки в CI/CD;
• использование внутренних списков доверенных пакетов;
• предупреждения перед установкой неизвестных зависимостей.

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

Типичные ошибки при создании системы обнаружения

• Использование только расстояния Левенштейна. Такой подход не учитывает визуальные подмены и структурные изменения. Лучше объединять несколько признаков.
• Один порог для всех имён. Короткие и длинные названия ведут себя по-разному, поэтому правила оценки должны учитывать особенности данных.
• Игнорирование Unicode. Это оставляет без внимания часть визуальных совпадений.
• Сравнение со всем реестром без фильтрации. Большие наборы требуют индексации и предварительного отбора.
• Отсутствие учёта популярности. Не все похожие имена имеют одинаковый уровень интереса для проверки.
• Автоматическая блокировка всех кандидатов. Это повышает риск проблем с легитимными пакетами.
• Проверка только вручную. Количество новых зависимостей может превышать возможности ручного анализа.
• Смешение typosquatting с другими типами атак. Похожие названия, подмена области имён и компрометация владельца требуют разных подходов.

Итоговый подход к выявлению typosquatting

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

Главная задача такого анализа — не объявить пакет вредоносным только по названию, а быстро выделить зависимости, которые требуют дополнительного внимания. При правильной настройке проверка похожих имён становится полезным элементом защиты software supply chain и помогает разработчикам замечать подозрительные совпадения до того, как неизвестная зависимость попадёт в рабочий процесс.