Firma Google zaprezentowała projekt OSS Rebuild, który ma na celu identyfikację ukrytych zmian w gotowych pakietach publikowanych w repozytoriach. Praca OSS Rebuild opiera się na koncepcji reprodukowalnych kompilacji i polega na sprawdzaniu zgodności pakietu umieszczonego w repozytorium z pakietem uzyskanym w wyniku rekonstrukcji z odniesionego kodu źródłowego, odpowiadającego deklarowanej wersji pakietu. Kod narzędzia napisano w języku Go i jest rozpowszechniany na licencji Apache 2.0.
Obecnie w OSS Rebuild zaimplementowano wsparcie dla weryfikacji pakietów z repozytoriów NPM (JavaScript/TypeScript), PyPI (Python) oraz Crates.io (Rust). W przyszłości planuje się rozszerzenie liczby wspieranych repozytoriów. W praktyce narzędzie to pozwala na identyfikację ataków klasy "łańcuch dostaw", w trakcie których po skompromitowaniu kont opiekunów lub dywersji wewnątrz projektu w repozytorium publikowane jest złośliwe uaktualnienie. W tym przypadku kod w podstawowym repozytorium projektu pozostaje poprawny, a złośliwe zmiany wprowadzane są tylko w gotowych pakietach.
System stara się automatycznie tworzyć scenariusz dla reprodukowalnej kompilacji wybranego pakietu, wykorzystując heurystykę i dobierając parametry, które pozwalają osiągnąć tożsamość artefaktów dostarczanych w pakiecie. Jeśli nie udaje się automatycznie odtworzyć umieszczonego w repozytorium pakietu, istnieje możliwość ręcznego dodania specyfikacji kompilacji. Po udanym odtworzeniu pakietu narzędzie OSS Rebuild zachowuje opis procesu kompilacji do późniejszej weryfikacji nowych wersji pakietu. Dodatkowo publikowane są informacje do weryfikacji z wykorzystaniem frameworka SLSA.
Po przeprowadzeniu weryfikacji konkretnej wersji pakietu generowane są dane attestation, które mogą być wykorzystywane przez innych do oceny już zweryfikowanych pakietów. Weryfikację można przeprowadzić poprzez uruchomienie narzędzia wiersza poleceń lub porównanie hasha zapisanego w oddzielnym magazynie chmurowym. Infrastrukturę do weryfikacji pakietów można uruchomić na własnym serwerze. Można także skorzystać z informacji o weryfikacjach przeprowadzonych przez Google dla kilku tysięcy pakietów.
Jako przykłady różnych metod ataków, przed którymi OSS Rebuild mógłby chronić, podano dodanie backdoora do XZ, wstrzyknięcie złośliwego kodu do oficjalnego klienta JavaScript dla kryptowaluty Solana oraz podstawienie zmian przez handler Actions changed-files:
- W przypadku projektu XZ kod w repozytorium nie zawierał podejrzanych zmian, a elementy wprowadzające backdoora dostarczane były w plikach używanych w zbiorze testowym do sprawdzania poprawności działania dekompresora XZ. Backdoor aktywował się na poziomie systemu budowania, a sam kod źródłowy XZ pokrywał się z kodem z repozytorium. Aktywujące backdoor makra m4 dla narzędzi Automake były zawarte tylko w gotowym archiwum z kodem i nie występowały w repozytorium. W celu wykrywania podobnych ataków w OSS Rebuild stosuje się dynamiczną analizę dostarczanych w pakiecie artefaktów, ścieżek wykonania i podejrzanych operacji.
- Podstawienie złośliwych zmian w bibliotece @solana/web3.js miało miejsce z powodu kompromitacji konta osoby prowadzącej projekt, z wykorzystaniem metod inżynierii społecznej i phishingu. W repozytorium NPM umieszczono nową wersję, zawierającą złośliwe zmiany. W repozytorium Git projektu ta wersja nie została utworzona, a złośliwe zmiany były obecne tylko w wynikowym pakiecie. Ochrona w tym przypadku sprowadza się do wykrywania w pakiecie kodu, którego brakuje w głównym repozytorium.
- Kompromitacja repozytorium handlera changed-files umożliwiła przeprowadzenie ataku na projekty korzystające z changed-files do śledzenia zmian plików i katalogów w infrastrukturze ciągłej integracji opartej na GitHub Actions. Aby chronić przed podstawianiem zmian po kompromitacji środowiska budowania, w OSS Rebuild stosuje się śledzenie zmian i podejrzanej aktywności w standardowych uproszczonych środowiskach budowlanych.
Źródło: opennet.ru
