Ataki PyPI LiteLLM Telnyx: ochrona łańcucha dostaw

Ataki na łańcuch dostaw PyPI: przypadki LiteLLM i Telnyx z praktycznymi zaleceniami

Przestępcy skompromitowali pakiety litellm i telnyx poprzez wyciek tokena API z zależności Trivy. 19 marca 2026 roku opublikowano złośliwe wersje: litellm 1.82.7 i 1.82.8, telnyx 4.87.0 i 4.87.2. Kod aktywuje się przy imporcie modułów, skanuje środowisko w poszukiwaniu sekretów i eksfiltruje dane na zdalne serwery.

Złośliwy payload w litellm zbiera klucze SSH, dane uwierzytelniające Git/Docker, pliki .env, tokeny K8s, hasła do baz danych, konfiguracje LDAP, historię powłoki i klucze kryptograficzne. Próbuje wyodrębnić tokeny chmurowe z serwerów metadata i AWS Secrets Manager. Dane trafiają na models.litellm.cloud. Dla utrzymania trwałości tworzy usługę SystemD "System Telemetry Service" lub pod K8s, który pobiera instrukcje z checkmarx.zone.

W telnyx złośliwy kod w _client.py ładuje etapy z plików WAV na 8.42.209.203. W Windows umieszcza msbuild.exe w Startup do autostartu, w innych systemach operacyjnych — skrypt Python. Wersja 4.87.1 zawierała literówkę, blokującą wykonanie. Powiązanie z TeamPCP przez klucz szyfrowania.

Deweloperzy zareagowali rotacją tokenów, usunięciem wydań i wdrożeniem trusted publishers w PyPI.

Cechy ataków na popularne pakiety OSS

W przeciwieństwie do typowych ataków na PyPI (typosquatting lub nowe pakiety), tutaj złośliwy kod został wstrzyknięty do istniejących projektów o dużym ruchu. Łańcuch: kompromitacja repozytoriów → kradzież tokenów PyPI/GitHub → publikacja malware → zbieranie danych uwierzytelniających z maszyn deweloperskich → powtórna kompromitacja.

LiteLLM został pobrany ponad 119 tys. razy w czasie ataku. Około 40-50% instalacji bez wersji (latest), około 1700 instalacji/min. Czas reakcji PyPI:

• LiteLLM: od publikacji do kwarantanny — 2 godziny 32 minuty (13 zgłoszeń użytkowników).
• Telnyx: 3 godziny 42 minuty (auto-kwarantanna trusted users).

Środki PyPI przeciwko malware

Codziennie około 700-800 nowych projektów. PyPI polega na społeczności do skanowania i zgłaszania przez "Report as malicious". Funkcja od 2024 roku przyspiesza kwarantannę. Trusted publishers aktywują auto-reakcję.

Zalecenia: okres chłodzenia zależności

Opóźnienie instalacji świeżych wydań daje czas na wykrycie malware. Format RFC 3339 (P3D = 3 dni).

• uv: globalnie w ~/.config/uv/uv.toml lub pyproject.toml:

[tool.uv]
exclude-newer = "P3D"

• pip v26.1+: w pip.conf:

[install]
uploaded-prior-to = P3D

• pip 26.0 (data bezwzględna):

python -m pip install --uploaded-prior-to=$(date -d '-3days' -Idate) package

Obejście dla łat bezpieczeństwa: --uploaded-prior-to=P0D lub Dependabot/Renovate (ignorują opóźnienia).

Blokowanie zależności dla odtwarzalności

Pliki lock z hashami zapobiegają podmianie kodu przy reinstalacji.

| Narzędzie | Polecenie | Format |

|------------|---------|--------|

| uv | uv lock | uv.lock |

| pip-tools | pip-compile --generate-hashes | requirements.txt |

| pipenv | pipenv lock | Pipfile.lock |

pip freeze jest niewystarczający — bez hashów. Oczekiwany pip lock (pylock.toml).

Ochrona projektów OSS

• Wdrożyć trusted publishers w PyPI.
• Używać 2FA + klucze sprzętowe dla PyPI/GitHub.
• Ograniczać uprawnienia tokenów (scopes).
• Monitorować publikacje przez webhooki.
• Skanować repozytoria Trivy/Grype.

Dla maszyn deweloperskich:

• Izolować skompromitowane środowiska.
• Rotować wszystkie dane uwierzytelniające.
• Sprawdzić pod kątem trwałości (SystemD, pody K8s, Startup).
• Analiza ruchu/logów.

Co jest ważne

• Ataki wykorzystują rzeczywiste pakiety OSS; sprawdzaj świeże wydania.
• Okres chłodzenia P3D + pliki lock = podstawowa ochrona.
• Ponad 119 tys. instalacji LiteLLM przed kwarantanną; latest jest niebezpieczny.
• Eksfiltracja obejmuje metadata chmurowe i Secrets Manager.
• Trusted publishers i społeczność przyspieszają reakcję PyPI.

— Editorial Team