Generative Data Intelligence

Хакери створюють законні фішингові посилання за допомогою Ghost GitHub, коментарі GitLab

Дата:

Хакери використовують неопубліковані коментарі GitHub і GitLab для створення фішингових посилань, які, здається, надходять із законних проектів програмного забезпечення з відкритим кодом (OSS).

Розумний трюк, вперше описаний Сергієм Франковим з Open Analysis минулого місяця, дозволяє будь-кому імітувати будь-яке сховище, яке вони бажають без відома власників цього сховища. І навіть якщо власники знають про це, вони нічого не можуть зробити, щоб це зупинити.

Приклад: хакери мають вже зловживали цим методом розподіляти троян Redline Stealer, використовуючи посилання, пов’язані з розміщеними на GitHub сховищами Microsoft «vcpkg» і «STL», згідно з McAfee. Frankoff самостійно виявив більше випадків, пов’язаних із тим самим завантажувачем, який використовувався в тій кампанії, а Bleeping Computer знайшов додаткове уражене репо «httprouter».

За матеріалами Bleeping Computer, проблема стосується як GitHub — платформи з понад 100 мільйонами зареєстрованих користувачів, так і її найближчого конкурента GitLab із понад 30 мільйонами користувачів.

Цей дивовижний недолік GitHub і GitLab полягає в, мабуть, найпростішій функції, яку тільки можна уявити.

Розробники часто залишають пропозиції або повідомляють про помилки, залишаючи коментарі на сторінці проекту OSS. Іноді такий коментар буде включати файл: документ, скріншот або інший носій.

Коли файл потрібно завантажити як частину коментаря в мережі доставки вмісту (CDN) GitHub і GitLab, коментарю автоматично призначається URL-адреса. Ця URL-адреса явно пов’язана з будь-яким проектом, якого стосується коментар. У GitLab, наприклад, файл, завантажений із коментарем, отримує URL-адресу в такому форматі: https://gitlab.com/{project_group_name}/{repo_name}/uploads/{file_id}/{file_name}.

Хакери з’ясували, що це забезпечує ідеальне прикриття для їхнього шкідливого програмного забезпечення. Вони можуть, наприклад, завантажити завантажувач зловмисного програмного забезпечення для RedLine Stealer до репо Microsoft і отримати посилання натомість. Незважаючи на те, що в ньому міститься зловмисне програмне забезпечення, будь-якому глядачеві це здасться законним посиланням на справжній файл репо Microsoft.

Але це ще не все.

Якщо зловмисник розміщує зловмисне програмне забезпечення в сховищі, можна припустити, що власник цього сховища або GitHub помітить це та усуне.

Тож вони можуть опублікувати коментар, а потім швидко видалити його. URL-адреса продовжує працювати, а файл все одно залишається завантаженим у CDN сайту.

Або, ще краще: зловмисник може просто не опублікувати коментар. Як на GitHub, так і на GitLab робоче посилання створюється автоматично, щойно до поточного коментаря додається файл.

Завдяки цій банальній примхи зловмисник може завантажити зловмисне програмне забезпечення в будь-яке сховище GitHub, яке забажає, отримати посилання, пов’язане з цим сховищем, і просто залишити коментар неопублікованим. Вони можуть використовувати його для фішингових атак скільки завгодно довго, тоді як імітований бренд навіть не підозрюватиме, що таке посилання було згенеровано.

Шкідливі URL-адреси, пов’язані з законними репозиторіями, надають вірогідність фішинговим атакам і, навпаки, загрожують збентежити та підірвати довіру імітованої сторони.

Що гірше: вони не мають жодного виходу. Відповідно до Bleeping Computer, немає налаштувань, які дозволяють власникам керувати файлами, прикріпленими до їхніх проектів. Вони можуть тимчасово вимкнути коментарі, одночасно запобігаючи звітам про помилки та співпраці зі спільнотою, але постійного виправлення немає.

Dark Reading звернувся до GitHub і GitLab, щоб запитати, чи планують вони виправити цю проблему та як. Ось як один відповів:

«GitHub прагне розслідувати повідомлені проблеми безпеки. Ми відключили облікові записи користувачів і вміст відповідно до Політика прийнятного використання GitHub, які забороняють публікувати вміст, який безпосередньо підтримує незаконні активні атаки або кампанії зловмисного програмного забезпечення, які завдають технічної шкоди», — повідомив представник GitHub в електронному листі. «Ми продовжуємо інвестувати в підвищення безпеки GitHub і наших користувачів і шукаємо заходи для кращого захисту від цієї діяльності. Ми рекомендуємо користувачам дотримуватися інструкцій, наданих супроводжувачами, щодо завантаження офіційно випущеного програмного забезпечення. Технічні працівники можуть використовувати Випуски GitHub або випустити процеси в реєстрах пакетів і програмного забезпечення для безпечного розповсюдження програмного забезпечення серед користувачів».

Dark Reading оновить історію, якщо GitLab відповість. Тим часом користувачі повинні діяти легко.

«Розробники, які бачать ім’я надійного постачальника в URL-адресі GitHub, часто вірять, що те, що вони натискають, є безпечним і законним», — каже Джейсон Сороко, старший віце-президент із продуктів Sectigo. «Було багато коментарів про те, що елементи URL-адреси не розуміють користувачі або не мають багато спільного з довірою. Однак це чудовий приклад того, що URL-адреси важливі та можуть викликати помилкову довіру.

«Розробникам потрібно переглянути своє ставлення до посилань, пов’язаних із GitHub або будь-яким іншим репозиторієм, і витратити деякий час на ретельний аналіз, як вони могли б це зробити з вкладенням електронної пошти».

spot_img

Остання розвідка

spot_img

Зв'яжіться з нами!

Привіт! Чим я можу вам допомогти?