W zeszłą środę GitHub ogłosił, że ulepszył funkcję skanowania tajnych danych. Funkcja, dedykowana dla głównych usług w chmurze, umożliwia teraz użytkownikom sprawdzanie ważności ujawnionych danych uwierzytelniających.
Funkcja skanowania tajnych informacji była dostępna od marca 2023 r. Po zmianach ma wydajniej pomóc organizacjom i programistom zidentyfikować potencjalnie ujawnione tajemnice w ich repozytoriach i podjąć natychmiastowe działania.
Skanowanie jest wspierane przez wielu dostawców usług w programie partnerskim GitHub, wysyła alerty do programistów po wykryciu ujawnionych kluczy hostowanych samodzielnie, a także powiadamia partnerów GitHub o ujawnionych „sekretach” w publicznych repozytoriach.
Opcja wymaga włączenia i funkcjonuje we wszystkich repozytoriach. Działa w ten sposób, że wysyła powiadomienia, gdy tylko „sekret” zostanie przypadkowo uwzględniony w zatwierdzeniu kodu.
Aby pomóc organizacjom i programistom w szybszej selekcji alertów i naprawianiu ujawnionych tokenów, na początku tego roku GitHub wprowadził kontrolę ważności własnych tokenów, eliminując potrzebę sprawdzania, czy każdy ujawniony token jest aktywny, czy nie.
Obecnie platforma do hostingu kodu (której właścicielem jest Microsoft) rozszerza możliwości na tokeny AWS, Google, Microsoft i Slack.
„Odpowiadają one za niektóre z najczęstszych typów »sekretów« wykrywanych w repozytoriach w GitHub. Będziemy stale rozszerzać obsługę walidacji większej liczby tokenów w naszym programie partnerskim zajmującym się skanowaniem tajnych danych” – informuje platforma.
Właściciele przedsiębiorstw i administratorzy repozytoriów mogą włączyć sprawdzanie poprawności w sekcji „Bezpieczeństwo i analiza kodu” w ustawieniach, włączając opcję „Automatycznie sprawdzaj, czy sekret jest ważny, wysyłając go do odpowiedniego partnera” w sekcji „Skanowanie sekretów”.
Po włączeniu ustawienia informacja o tym, czy walidowany token jest aktywny, będzie uwzględniana w otrzymywanych alertach.
Skanowanie, jak twierdzi GitHub, odbywa się okresowo w tle, ale można również przeprowadzić kontrole ręczne, klikając „Zweryfikuj sekret” w prawym górnym rogu.
Podnoszenie bezpieczeństwa w platformie takiej jak GitHub jest oczywiście wymogiem koniecznym. Platforma hostująca kod to idealny cel dla haków na tzw. łańcuch dostaw. Czym grożą takie ataki, przekonaliśmy się w przypadku włamania do SolarWinds.
GitHub jest atakowany. Pod koniec września Checkmarx, firma zajmująca się bezpieczeństwem aplikacji, zaobserwowała, że hakerzy przesyłają fałszywe wpisy programu zależnego do setek repozytoriów GitHub, aby wstrzyknąć złośliwy kod.
Kampania została zidentyfikowana w lipcu. Opierała się na skradzionych osobistych tokenach dostępu do GitHub w celu uzyskania dostępu do repozytoriów i wypychania kodu, by wykraść poufne informacje z projektów i hasła użytkowników końcowych.
Aby uniknąć wykrycia, napastnicy sfałszowali komunikaty zatwierdzeń, tak że sprawiały wrażenie wygenerowanych przez Depabot – bezpłatne, zautomatyzowane narzędzie do zarządzania zależnościami, dostępne w serwisie GitHub, pomagające twórcom oprogramowania identyfikować i eliminować luki w zabezpieczeniach ich kodu.
Algorytm stale skanuje zależności projektu i generuje żądania aktualizacji podczas identyfikowania problemów. Te ostatnie wymagają oczywiście potwierdzenia ze strony użytkownika.
W ramach obserwowanej kampanii napastnicy utworzyli komunikat o zatwierdzeniu „poprawki”, który najwyraźniej został przesłany przez konto usługi, w ten sposób oszukując programistów, by uwierzyli, że zatwierdzenia pochodzą z narzędzia GitHub.
Korzystając z tej techniki, cyberprzestępcy obrali za cel setki repozytoriów, w tym repozytoria prywatne, dodając nowy plik „hook.yml” jako plik przepływu pracy w celu wysyłania danych poufnych do zewnętrznego serwera przy każdym zdarzeniu „push”.
Oprócz wstrzyknięcia tej akcji, osoby atakujące zmodyfikowały wszystkie pliki .js w docelowych projektach, dodając na końcu zaciemnioną linię kodu.
Kod tworzył nowy znacznik skryptu po uruchomieniu w przeglądarce, a jednocześnie ładował dodatkowy skrypt ze zdalnego serwera w celu przechwytywania formularzy opartych na hasłach i wysyłania danych uwierzytelniających użytkownika do atakujących.
Według Checkmarxa skradzione osobiste tokeny dostępu do GitHub użyte w tej kampanii zostały najprawdopodobniej wydobyte z systemów ofiar po pobraniu przez nie szkodliwego pakietu.
Firma zajmująca się bezpieczeństwem zauważa, że ataki były prawdopodobnie zautomatyzowane i że ofiarom trudno było zidentyfikować naruszenie tokena, ponieważ aktywność dziennika dostępu tokena nie jest pokazywana w dzienniku audytu konta.
„Cała ta sytuacja uczy nas, że powinniśmy uważać na to, skąd bierzemy nasz kod, nawet z zaufanych miejsc, takich jak GitHub. To pierwszy przypadek, gdy byliśmy świadkami zdarzenia, w którym hakerzy używali fałszywych zatwierdzeń w celu ukrycia aktywności, wiedząc, że wielu programistów nie sprawdza rzeczywistych zmian” – zauważa Checkmarx.