Само през последните няколко месеца кибератакистите са регистрирали над 100 000, а според някои оценки – над един милион, зловредни копия на хранилища в GitHub.

Схемата за „объркване на хранилища“ е проста: програмно копиране, троянизиране и повторно качване на съществуващи хранилища с надеждата, че разработчиците ще изтеглят грешното.

Изглежда, че автоматичните механизми за сигурност на GitHub идентифицират и премахват по-голямата част от тези евтини фалшификати, но според ново изследване на Apiiro много от тях все още се промъкват през пукнатините.

Анатомия на атака за объркване на хранилището

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

Този зловреден софтуер на свой ред се включва в софтуерни проекти и предизвиква рискове по веригата на доставки.

Ключът към успеха на тази последна кампания е автоматизацията. Атакуващият автоматично клонира, заразява и презарежда хранилища в голям мащаб, като по оценки на изследователите общо са създадени милиони хранилища. И за да се добави легитимност, процесът на автоматизация разклонява тези проекти хиляди пъти всеки и ги популяризира в различни уеб форуми и приложения.

Така че, когато недоспали или многозадачни разработчици разклонят подражателя вместо оригинала, те ще получат силно замаскирано копие на BlackCap Grabber, който освен други злонамерени функции събира идентификационни данни от различни приложения, бисквитки на браузъра и други данни.

От своя страна GitHub сваля повечето от тези злонамерени репо-сборници в рамките на часове след публикуването им.

„Изглежда обаче, че автоматичното откриване пропуска много репозитории, а тези, които са били качени ръчно, оцеляват. Тъй като цялата верига от атаки изглежда е предимно автоматизирана в голям мащаб, 1 %, които оцеляват, все още възлизат на хиляди злонамерени репозитории“, обяснява Apiiro в публикацията си в блога.

Говорител на GitHub заяви, че организацията работи по извличането на зловредния код. „GitHub е домакин на над 100 млн. разработчици, които изграждат в над 420 млн. хранилища, и се ангажира да предоставя безопасна и сигурна платформа за разработчиците. Разполагаме с екипи, посветени на откриването, анализирането и премахването на съдържание и акаунти, които нарушават нашите политики за приемливо използване. Използваме ръчни прегледи и мащабни открития, които използват машинно обучение и постоянно се развиват и адаптират към тактиките на противниците“, се казва в изявлението на говорителя. „Също така насърчаваме клиентите и членовете на общността да докладват за злоупотреби и спам.“

Защо GitHub се използва за атаки за объркване

По своята същност GitHub предлага определени предимства за атаки за объркване. „Лесното автоматично генериране на акаунти и репозитории в GitHub и други подобни, с помощта на удобни API и меки ограничения на скоростта, които са лесни за заобикаляне, в комбинация с огромния брой репозитории, сред които може да се скрие, го правят идеална цел за тайно заразяване на веригата за доставка на софтуер“, пише Apiiro.

Шон Лоувланд, главен оперативен директор на Resecurity, посочва два допълнителни проблема. „Единият е компромис между неприкосновеността на личния живот и сигурността: GitHub не разглежда хранилищата, но тогава престъпниците могат да се възползват от тях“, казва Лоувланд. „А другият е самият брой на компрометираните акаунти в GitHub, което позволява на лошите  да влязат в частни репозитории и след това да направят дубликати.“

Киберпрестъпниците могат да копират публични хранилища и без този допълнителен достъп.

„Току-що погледнах в нашата база данни“, отбелязва Ловланд. „Почти 100 000 компютъра на потребители, които влизат в GitHub, са били заразени със злонамерен софтуер през последните 90 дни.“

Как организациите могат да се защитят както от преките, така и от последващите ефекти на злонамерено репо в GitHub? „Компаниите трябва да имат политика за използване на GitHub, [която] да съобщават на служителите и доставчиците си, дори ако самите те не използват GitHub“, предлага той, защото дори компаниите, които не се ангажират пряко с код на трети страни, разчитат на разработчиците в някакъв момент от веригите си на доставки.

„Дори компания, в която никой не използва GitHub, пак може да стане жертва“, казва Лоулънд.