GitHub се превърна в любимата площадка за игра на милиони разработчициУроци, които изглеждат обещаващи, хранилища, пълни с примери, и скриптове, готови за копиране и поставяне. Често срещано е да търсите „как да създадете нещо с Java, Angular и т.н.“ и да попаднете на привидно сериозна статия, чийто изходен код е свързан с публично хранилище. Усещането е за пълно доверие... но това доверие не винаги е оправдано.
Логичният въпрос е: Мога ли да се заразя с вирус само чрез клониране на хранилище или изпълнение на GitHub скрипт? Какво се случва, ако някой създаде добре написан урок, но използва хранилището като стръв, за да промъкне зловреден софтуер? Краткият отговор е „да“, има реални рискове и те не се ограничават до „двойно щракване и заразяване“: те засягат веригата за доставки на софтуер, вашите CI/CD тръбопроводи, вашите данни и дори репутацията на вашия проект.
Опасно ли е да се изтеглят скриптове и проекти от GitHub?
GitHub, като платформа, не е по своята същност злонамерен, но не е и гаранция за сигурност. масивна услуга, където отличен код може да съществува едновременно с некачествени скриптове и висококачествени злонамерени полезни товари. Киберпрестъпниците са научили, че „ако нещо е твърде полезно, никой не го блокира“, така че GitHub се е превърнал в перфектен канал за разпространение на зловреден софтуер, маскиран като легитимен код.
Клониране на хранилище с git clone Не те заразява по магически начин.Но опасността възниква, когато компилирате, изпълнявате скриптове, стартирате контейнери или интегрирате зависимости, без да ги проверявате. Атакуващите експлоатират именно това: те се възползват от факта, че много разработчици копират и изпълняват README инструкции, без да ги поставят под въпрос.
В корпоративна среда трафикът към GitHub обикновено се счита за „нормален“. И често не се следи толкова стриктно, колкото другите изтегляния. Това позволява скриптове, двоични файлове или полезни товари за издания да бъдат изтегляни, без да се поражда подозрение, особено ако се извикват от автоматизирани конвейери.
Освен това, Проблемът не е само в скрипта, който виждате в урока.Има атаки, които злоупотребяват със зависимости, библиотеки, коментари, прикачени файлове или дори PoCs (доказателства за концепция) за уязвимости, маскирайки зловредния софтуер като легитимен технически ресурс.
Често срещани тактики за скриване на зловреден софтуер в GitHub
Злонамерени лица са професионализирали използването на GitHub като канал за разпространение, до степен да използват модели „зловреден софтуер като услуга“ (MaaS), където GitHub е по същество CDN за злонамерени полезни товари. Това са... Някои от най-опасните техники, които са били наблюдавани:
Злонамерени хранилища и скриптове с невинен външен вид
Една от най-директните тактики се състои в качване на очевидно злонамерени скриптове или двоични файлове към хранилища, които на пръв поглед изглеждат нормални. Имената на файловете и хранилищата са избрани така, че да вдъхват доверие или поне да не предизвикват подозрение. Те могат да бъдат предполагаеми инструменти за администриране, системни помощни програми, малки клиенти или „помощници“ за автоматизиране на задачи.
В някои кампании Открити са акаунти със стотици хранилища с произволно име, където всяко хранилище съдържа един злонамерен файл в секцията „Издания“. Видимият код може да е безобиден или неподходящ; истинската опасност се крие в изданието, изтеглено от директна връзка, понякога споделена извън GitHub (форуми, чатове, имейли, социални мрежи).
Ангажирани агенции и книжарници
Друг, много по-фин подход е инжектиране на злонамерен код в привидно легитимни зависимостиВместо да атакува основния проект, нападателят компрометира често използвана библиотека или създава клонинг с почти идентично име (типосквотинг) и го публикува в GitHub и/или съответния регистър на пакетите.
Когато разработчик добави тази зависимост към своя проект (например, като копира реда от README файла на злонамереното хранилище или фалшив уебсайт), той интегрира зловреден софтуер като естествена част от процеса на изграждане. Резултатът: злонамерен код се изпълнява в средата за разработка, на CI/CD сървъри и понякога дори в продукцията.
PoC (доказателства за концепция) на модифицирани експлойти за инсталиране на RAT-ове
Публикуваните в GitHub експлойти за доказване на концепция се превърнаха в много сочна цел.Много администратори, изследователи и „членове на червения екип“ изтеглят Proofs of Concept (PoCs), за да оценят уязвимостите в своята среда, често приемайки, че щом е в GitHub и изглежда техническо, значи е легитимно.
Този тип злонамерен PoC Обикновено включва вериги за изпълнение в няколко фазисъздаване на пакетни скриптове, Извикване на PowerShell, изтегляне на допълнителен полезен товар и настройване на планирани задачи, така че жертвата да се сдобие с троянски кон за отдалечен достъп, който регистрира ключове, краде идентификационни данни и комуникира със сървър за командване и контрол.
Използване на коментари и чернови за промъкване на файлове
GitHub и GitLab позволяват Прикачване на файлове към коментари в задачи и заявки за изтеглянеОбикновено качвате екранни снимки, лог файлове или минимални примери за код. Проблемът е, че в GitHub, когато някой прикачи файл към коментар, в CDN се генерира директна връзка към файла, дори ако коментарът не е публикуван.
Това означава, че нападателят може да се подготви коментар със злонамерен прикачен файлникога не кликвайте върху „Публикуване“ и все пак ще получите работеща връзка като github.com/User/Repo/files/id/fileОт гледна точка на жертвата, линкът изглежда принадлежи към легитимно хранилище и известен разработчик.
Собственикът на хранилището не може да види този файл, не може да го изтрие или заключи.защото коментарът остава в невидимо състояние на чернова. Освен това няма конфигурация за сигурност на ниво хранилище, която да предотвратява тези видове качвания, освен пълното деактивиране на коментарите, което нарушава динамиката на сътрудничество в проекта.
Фалшиви страници и уроци, които пренасочват към зловреден софтуер, хостван в GitHub
Друг широко разпространен метод включва създаване на уебсайтове, които имитират добре познати проекти, инструменти или компаниикъдето потребителите са поканени да изтеглят „официалната версия“ или „най-новата компилация“ от линк, сочещ към GitHub. След като види домейна на GitHub и името на предполагаемия проект в URL адреса, потребителят се отпуска и изтегля файла без допълнителни проверки.
В някои случаи това е наблюдавано тактика, свързана с хранилищата на големи компаниидобавяне на връзки към предполагаеми кодове за игри или допълнителни инструменти. Докато един много наблюдателен потребител може да намери нещо подобно в хранилище на Microsoft за дразнещо, много хора забелязват само ключовите думи „GitHub“ и „Microsoft“ и не анализират контекста по-подробно.
Реално въздействие: от машината на разработчика до веригата за доставки
Рисковете не се ограничават само до заразяване на лаптопа на разработчик. Когато злонамерен скрипт навлезе в работния ви процес, Това може да засегне цялата организация: изходен код, среди за изграждане, канали за внедряване, тайни и данни за клиентите.
Последните кампании показаха как програми за зареждане като Emmenthal работят на слоеве, криейки истинския код до последния момент и едва накрая изпълнявайки инструкции, които изтеглят полезния товар (например зловредния софтуер Amadey) от GitHub или други публични хранилища.
Amadey и подобен зловреден софтуер са предназначени да събиране на системна информация, кражба на идентификационни данни и изтегляне на допълнителни модули в зависимост от профила на жертвата. Това дава на нападателите голяма гъвкавост: от крадци на информация като Redline или Lumma до троянски коне за отдалечен достъп като AsyncRAT, скриптове, маскирани като видео файлове, или Python код със скрити функции.
Когато тези видове заплахи проникнат в CI/CD инфраструктурата, въздействието се умножаваКомпрометирана задача може да инжектира код в артефакти, които след това се разпространяват до клиентите, да измъкне променливи на средата с токени и ключове или да промени конфигурациите на внедряването, за да отвори задни врати.
От регулаторна и съвместима гледна точка, използването на непроверени хранилища и зависимости Това може да доведе до сериозни нарушения на политиките за сигурност, стандарти като ISO 27001 или дори специфични за сектора изисквания. (финансови, здравни и др.), особено ако има изтичане на лични данни или интелектуална собственост.
GitHub действия, CI/CD и други чувствителни точки
Непрекъснатата интеграция и работните процеси за доставка са приоритетни цели. Защото те концентрират код, идентификационни данни и автоматизация. GitHub Actions, Jenkins, GitLab CI или друг подобен инструмент могат да бъдат засегнати от злонамерени скриптове, изтеглени от привидно невинни хранилища.
Лошо конфигуриран работен процес CI/CD може изпълнявайте скриптове с прекомерни разрешенияИзтриване на клонове, презаписване на история, качване на злонамерени двоични файлове в официални издания или дори промяна на критични конфигурационни файлове. Всичко, от което се нуждаете, е една-единствена неправилно поставена или злонамерена команда или git push --force изпълнява се от действие с права за запис в защитен клон.
También съществува рискове от повреда или загуба на данни при използването на Git и GitHub: разрушителни команди (git clean -fdx, git push --mirror), грешки в скриптове за автоматизация, проблеми с Git LFS, лошо управлявани подмодули, неправилно разрешени конфликти при сливане… Всичко това може да причини всичко - от случайни загуби до огромни щети върху историята на проекта.
Грешките в управлението на разрешенията и достъпа са друг класически пример.Главни клонове без правила за защита, външни сътрудници с повече привилегии от необходимото, открити или неротирани лични токени за достъп, изтекли SSH ключове… Всяко пренебрегване на този фронт отваря вратата за изтривания, промени в кода или злонамерени вмъквания от външни нападатели или недоволни вътрешни лица.
Специфични рискове за разработчиците и организациите
За индивидуалния разработчик, Най-очевидният риск е заразяването на собствения ви екип. При изпълнение на скриптове, изтеглени от GitHub: загуба на файлове или криптиране, кражба на паролаОтвличане на акаунти, наблюдение на активността и т.н. Но щетите не спират дотук.
Ако този разработчик сътрудничи по споделени проекти, Зловредният софтуер може да променя код, да въвежда задни врати или да качва манипулирани артефакти, които в крайна сметка достигат до клиенти или крайни потребители., което сериозно уронва репутацията на проекта и компанията.
На организационно ниво експозицията е още по-голяма.Частните хранилища съхраняват интелектуална собственост, конфигурации, вътрешна документация и понякога лошо съхранени идентификационни данни. Атака, която получава достъп до тези елементи, може да доведе до масивни нарушения на данните, саботаж на продукти и продължителни прекъсвания на услугите.
Освен това, злоупотребата с GitHub като „официален източник“ за изтегляния във фишинг кампании увеличава риска нетехнически служители да попаднат в измами: имейли или съобщения с връзки, които започват с github.com o gitlab.com и следователно изглеждат надеждни, въпреки че всъщност доставят злонамерени изпълними файлове, генерирани от коментари към чернови или фалшиви хранилища, или които променят файл с хостове.
Технически мерки за намаляване на рисковете
- Ако приемем, че никой GitHub скрипт не е безобиден по подразбиранеВсичко, което се изтегля и изпълнява, трябва да се третира като потенциално враждебен код, дори ако е свързано с много популярен урок или високо оценен акаунт.
- Статичният и динамичният анализ на кода е фундаменталенИзползването на SAST и DAST инструменти, скенери за зависимости и анализ на състава на софтуера (SBOM) ви позволява да идентифицирате подозрителни модели, остарели зависимости, съмнителни мрежови функции или извиквания към PowerShell, WScript или други компоненти, често използвани във вериги за атаки, както и да прегледате мениджъри на пакети в Windows.
- Автоматизирането на тези контроли в рамките на CI/CD конвейера е ключово.Интегрирането на скенери във всяка заявка за push или pull, блокирането на сливания, ако бъдат открити критични уязвимости, и приоритизирането на най-уязвимите, значително намалява риска злонамерен скрипт да достигне до продукцията незабелязано.
- Контролът на зависимостите е жизненоважен: валидиране на произхода на всяка библиотека, избягване на пакети с имена, подозрително подобни на известни проекти, преглед на историята и репутацията на създателите на програмата и поддържане на пълен списък с компоненти, използвайки SBOM, за да се знае какво е инсталирано и къде.
- Специализирани инструменти за сигурност на хранилища и конвейери, като например решения от типа XygeniТе помагат за автоматизирането на голяма част от тази работа: наблюдават разрешенията, сканират зависимости за злонамерен софтуер или правописни грешки, наблюдават аномални дейности, защитават CI/CD потоците от несигурни конфигурации и дори генерират автоматични заявки за изтегляне с корекции и актуализации.
Контрол на достъпа, идентификационни данни и резервни копия
Сигурността на скриптовете, изтеглени от GitHub, също зависи от защитете собствения си акаунт и хранилищаНе е много полезно да следите кода, който импортирате, ако оставите проектите, токените или SSH ключовете си достъпни за всеки.
- Активирайте двуфакторно удостоверяване (2FA) в GitHub и GitLab А в организациите използва еднократно влизане (SSO) с доставчик на корпоративна идентичност. За предпочитане е да се използват TOTP приложения или физически ключове за сигурност, вместо SMS кодове.
- Приложете принципа на най-малките привилегии: предоставя само необходимите разрешения на всеки потребител или екип, ограничава кой може да изпраща до главните клонове, кой може да налага актуализации, да изтрива хранилища или да променя правилата за защита.
- Отнасяйте се с тайните такива, каквито са: високочувствителен материалИзбягвайте качването на токени, API ключове или пароли към вашия код. Използвайте защитеното хранилище за секрети на платформата, инструментите за сканиране на секрети и куките преди записване, за да блокирате записи, съдържащи идентификационни данни.
- Не подценявайте значението на резервните копияПравете редовни резервни копия на хранилищата (включително клонове, етикети и издания), съхранявайте ги криптирани на отделни места и редовно тествайте процедурите за възстановяване. В случай на атака или широко разпространена повреда, наличието на скорошно резервно копие е разликата между незначително неудобство и продължително бедствие.
В крайна сметка, безопасното използване на скриптове, изтеглени от GitHub, изисква комбиниране на здравословен скептицизъм, технически контрол и зрели процеси.Прегледайте кода си, преди да го стартирате, винаги валидирайте изходния код, защитете акаунтите и процесите си и използвайте инструменти, които автоматизират мониторинга. С този подход GitHub остава мощен ресурс, без да се превръща в черна дупка в сигурността.
