Дослідження ReversingLabs висвітлило критичну прогалину у Visual Studio Code Marketplace: після повного видалення розширення (hard delete) його ім’я знову стає доступним для інших видавців. На проблему звернули увагу після виявлення шкідливого розширення ahbanC.shiba, подібного до раніше зафіксованих ahban.shiba та ahban.cychelloworld. Ці інциденти демонструють, як управління ідентифікаторами може перетворитися на поверхню атаки для зловмисників.
ReversingLabs: повторне використання імен у VS Code Marketplace
За даними ReversingLabs, усі згадані розширення виконували роль завантажчиків PowerShell-пейлоаду з віддаленого сервера. Після отримання завантажувач шифрував файли у директорії testShiba на робочому столі жертви та вимагав викуп у токенах Shiba Inu. Хоча поведінка виглядала як рання стадія розробки шкідливого ПЗ, ризик для користувачів уже був реальним — особливо для тих, хто покладається на довіру до каталогу розширень.
Як працює ідентифікація розширень та де виникає вразливість
У екосистемі VS Code кожне розширення має унікальну пару <publisher>.<name>. Поле name має бути у нижньому регістрі, без пробілів і унікальним для магазину. У досліджених випадках змінювався лише видавець, а фактичне ім’я збігалося. Аналіз показав: після фізичного видалення артефактів (hard delete) початкове ім’я можна повторно зареєструвати під іншим видавцем. Якщо ж виконано лише депублікацію (unpublish), ім’я не звільняється. Така логіка створює вікно можливостей для brandjacking — захоплення впізнаваних назв з подальшою публікацією нового, потенційно шкідливого контенту.
Паралелі з PyPI та уроки для екосистем пакетів
Подібні інциденти вже траплялися у Python Package Index (PyPI), де після видалення пакета ім’я проєкту ставало доступним за певних умов (відмінності у файлах дистрибутиву). Водночас у PyPI діє виняток: імена, помічені у зловживаннях або інцидентах безпеки, можуть бути заблоковані й виведені з обороту. За спостереженнями ReversingLabs, у VS Code Marketplace не продемонстровано наявність еквівалентного механізму превентивного блокування для імен, пов’язаних із шкідливою активністю.
Ризики для розробників та організацій
Повторне використання імен суттєво підвищує імовірність атак name-squatting і typosquatting, а також підміни результатів у пошуку чи автоматизованій інсталяції. Якщо популярне легітимне розширення зникає з каталогу (через модерацію, юридичні або операційні причини), його ім’я може швидко перехопити зловмисник, щоб розповсюджувати завантажчики PowerShell, шифрувальники або шпигунські модулі під «знайомою» назвою.
Сценарій компрометації на практиці
Користувач бачить у Marketplace знайоме ім’я, встановлює розширення й не помічає, що змінився видавець або дата публікації. У середовище розробки потрапляє новий пакет, який запитує розширені дозволи, виконує команди через термінал або підвантажує пейлоад із мережі — типова ланка компрометації через екосистему розширень.
Рекомендації з мінімізації ризиків
Для платформи VS Code Marketplace
Резервування (quarantine) імен після видалення розширень, щоб унеможливити негайну перереєстрацію. Блокування імен, помічених у зловживаннях, до завершення перевірок. Підсилення верифікації видавців і чіткі попередження при спробі повторної реєстрації відомих імен. Прозорий журнал історії володіння ім’ям, доступний користувачам перед інсталяцією.
Для організацій
Allowlist довірених видавців/розширень і фіксація залежностей на рівні publisher ID та конкретних версій. Використання корпоративного проксі/дзеркала для контролю джерел пакетів. Моніторинг встановлень і мережевої активності IDE, а також EDR/AV-політики для контролю PowerShell на робочих станціях розробників.
Для розробників і мейнтейнерів
Надавати перевагу депублікації замість повного видалення, щоб не звільняти ім’я. Верифікувати облікові записи видавця, документувати fingerprint розширень (назва, видавець, хеши) і оперативно інформувати користувачів про зміну каналу розповсюдження.
Інцидент із ahbanC.shiba наочно показує, що слабкі місця в управлінні ідентифікаторами перетворюються на реальні ризики ланцюга постачання ПЗ. Посилення модерації, верифікації та резервування імен з боку платформи, а також дисципліна організацій і розробників здатні зменшити ймовірність захоплення бренду, підміни розширень і поширення шкідливих завантажчиків у довірених каталогах. Перегляньте політики встановлення розширень вже сьогодні: зафіксуйте залежності за publisher ID, активуйте моніторинг PowerShell і підтримуйте прозорий інвентар розширень у команді.
