Czym jest atak typu Man-in-the-Middle i jak jest on ukierunkowany Pipelines
Jeśli pytasz, czym jest atak typu man-in-the-middle w DevOps, to nie jest to po prostu ogólna technika podsłuchiwania sieci. To ukierunkowany atak. sposób na skompromitowanie twojego CI/CD pipelines poprzez przechwytywanie i manipulowanie przesyłanymi danymi, zależnościami, skryptami lub artefaktami, gdy szyfrowanie jest słabe lub nie występuje.
Rozważmy scenariusz z życia wzięty: program CI pobiera zależności z repozytorium innej firmy za pomocą protokołu HTTP. Jeśli protokół TLS jest nieprawidłowo skonfigurowany lub, co gorsza, nieobecny, atakujący mogą przechwycić to żądanie i wstrzyknąć złośliwe pakiety, które wyglądają na legalne. W szybko zmieniających się pipelineTe artefakty mogą zostać zbudowane i wdrożone, zanim ktokolwiek to zauważy. To typowy atak typu man-in-the-middle, ale z… CI/CD konsekwencje.
Atak nie musi łamać szyfrowania; wykorzystuje słabe konfiguracje. Rozważmy kompilację kontenera, która pobiera obraz bazowy lub skrypt z wewnętrznego repozytorium bez uwierzytelniania. To jest okno na atak MITM, jeśli ruch wewnętrzny nie jest szyfrowany ani segmentowany. Jeśli nadal nie masz pewności, czym jest atak typu man-in-the-middle, wyobraź sobie, że jest to niewidzialny aktor, który po cichu modyfikuje to, co robisz. pipeline spożywać, nie pozostawiając widocznych śladów.
Gdzie Pipeline Przerwy: Prawdziwe punkty wejścia MITM w CI/CD
Istnieje wiele słabych punktów, w których atak typu man-in-the-middle może przejąć kontrolę nad przepływami DevOps:
- Pobieranie pakietów przez HTTP: Częste w starszych kompilacjach lub rejestrach hostowanych samodzielnie. Jeśli pobierasz Pakiety Pythona, NPM moduły lub Obrazy dokowane bez protokołu HTTPS jesteś narażony.
- Niezweryfikowane źródła: Pipelines często korzystają z narzędzi społecznościowych lub open-source bez weryfikacji integralności. Atakujący MITM mogą manipulować tymi plikami do pobrania.
- Repozytoria artefaktów bez uwierzytelniania:Łatwymi celami ataków są kontenery S3, serwery Git LFS lub wewnętrzne magazyny artefaktów, do których można uzyskać dostęp za pomocą zwykłego protokołu HTTP.
- Niezabezpieczone usługi wewnętrzne:Wiele wewnętrznych CI/CD Narzędzia (programy uruchamiające, agenci, skrypty wdrożeniowe) zakładają bezpieczeństwo obwodu sieci. Ataki MITM mogą wykorzystać to założenie.
Przykład:
dependencies:
- wget http://internal.repo.local/package.tar.gz
⚠️ Przykład niezabezpieczony: nie używać w środowisku produkcyjnym
Jeśli ten ruch zostanie przechwycony, atakujący musi jedynie podać zmanipulowany komunikat .tar.gz z ładunkiem. Jest on rozpakowywany i uruchamiany na etapie kompilacji. To jest przedcisCzym jest atak typu man-in-the-middle w dzisiejszych czasach? pipelines: wykorzystuje założenia dotyczące zaufania.
Złośliwe kompilacje: wstrzykiwanie kodu w czasie wykonywania i kompilacji
Ataki typu Man-in-the-middle wykraczają poza przechwytywanie; prowadzą do wstrzyknięcia kodu. Gdy złośliwa zależność lub artefakt przedostanie się do pipeline, atakujący kontroluje kompilację.
- Wtrysk w czasie kompilacjiKompilatory lub skrypty kompilacji uruchamiające niezweryfikowane zależności mogą zawierać kod trojański. Wyobraź sobie zaciemniony wiersz w pliku Makefile, który jest wykonywany z podwyższonymi uprawnieniami.
- Wstrzyknięcie w czasie wykonywania: Zmienne środowiskowe lub sekrety ujawnione w postaci zwykłego tekstu można przechwycić i ponownie wykorzystać. Jeśli Twój program uruchamiający rejestruje eksport AWS_SECRET_KEY=…, masz wyciek, który czeka, żeby się wydarzyć.
- Dynamiczna manipulacja krokami: CI zdefiniowane w YAML pipelines często polegają na curl/wget do pobierania dynamicznych skryptów. Jeśli nie są one chronione, atakujący MITM mogą je zastąpić w locie.
curl http://setup.ci/init.sh | bash # Dangerous without TLS and verification
⚠️ Przykład niezabezpieczony: nie używać w środowisku produkcyjnym
Wiedza na temat ataku typu man-in-the-middle ułatwia zrozumienie, w jaki sposób dochodzi do tego typu wstrzyknięć: atakujący staje się częścią procesu dostarczania oprogramowania, wstrzykując złośliwe instrukcje bez bezpośredniego dostępu do kodu źródłowego.
Zabezpieczanie DevOps Pipelines Przeciwko ryzyku ataku typu Man-in-the-Middle
Nie można wyeliminować zagrożeń związanych z atakami typu „man-in-the-middle”, ale można je wyeliminować. pipelineZnacznie trudniej jest pójść na kompromis.
Kroki do podjęcia:
- Zawsze wymuszaj TLS:Każdy artefakt, zależność i skrypt musi zostać pobrany przez protokół HTTPS.
- Sprawdź sumy kontrolne/hasze:Użyj algorytmu SHA256 lub silniejszego i przeprowadź walidację przed wykonaniem.
- Podpisuj i weryfikuj artefakty: Aby upewnić się co do pochodzenia, skorzystaj z Sigstore lub in-toto.
- Bezpieczne programy CI:Izoluj środowiska, unikaj współdzielonych programów uruchamiających i wyłącz dostęp do powłoki, jeśli to możliwe.
- Izoluj sekrety: Wprowadzaj sekrety tylko w krokach, które ich wymagają. Nigdy ich nie drukuj ani nie przechowuj w logach.
kroki:
- name: Fetch
run: |
curl -fsSL https://secure-repo.com/tool.sh -o tool.sh
echo "<sha256> tool.sh" | sha256sum -c -
✅ Sprawdza integralność skryptu przed wykonaniem
To właśnie tego rodzaju środki wzmacniające sprawiają, że atak typu man-in-the-middle staje się kwestią teoretyczną, a nie incydentem produkcyjnym.
Dlaczego to ma znaczenie: wpływ na łańcuch dostaw i zwiększenie ryzyka
Atak typu „man-in-the-middle” w CI/CD pipeline nie jest tylko problemem lokalnym; psuje to cały twój łańcuch dostaw oprogramowania. Każdy użytkownik Twojej kompilacji jest narażony na ryzyko.
Gdy złośliwy artefakt trafia do kompilacji, jest on dystrybuowany dalej:
- Zagrożone kontenery trafiają do produkcji.
- Zatrute biblioteki są publikowane w rejestrach publicznych.
- Klienci instalują oprogramowanie z ukrytymi drzwiami.
Właśnie dlatego ataki na łańcuchy dostaw są tak szkodliwe. MITM jest często pierwszym krokiem, a nie ostatecznym celem. Jeśli zastanawiasz się, czym jest atak typu man-in-the-middle, teraz już wiesz: jest to punkt wyjścia do złamania zabezpieczeń całego łańcucha.
Wniosek: Przesunięcie w lewo Pipeline Security
Atak typu man-in-the-middle w DevOps nie polega na biernym podsłuchiwaniu, lecz na aktywnym przejmowaniu kontroli nad niebezpiecznymi przepływami w systemie. CI/CD. Nieprawidłowo skonfigurowany protokół TLS, nieuwierzytelnione źródła i niezweryfikowane artefakty otwierają drzwi. Deweloperzy muszą traktować pipelinePodobnie jak kod produkcyjny: przetestowany, zweryfikowany i zabezpieczony. Oznacza to brak nieuwierzytelnionych pobrań, brak źródeł opartych na protokole HTTP i brak dynamicznego wykonywania bez weryfikacji.
Narzędzia takie jak Xygeni pomóż zespołom wzmocnić ich pipelinepoprzez wykrywanie słabych punktów, weryfikację integralności artefaktów i wykrywanie naruszeń zależności zanim się rozprzestrzenią. Przesunięcie w lewo nie jest opcjonalne; to sposób na wyprzedzenie realnych zagrożeń AppSec. Zrozumienie, czym jest atak typu man-in-the-middle, nie wystarczy. Trzeba go wykryć, zapobiec mu i zaprzestać leczenia. pipeline jako obywatel drugiej kategorii w Twoim modelu bezpieczeństwa.
