Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
CircleCI to platforma ciągłej integracji, na której możesz definiować szablony wskazujące, co chcesz, aby zrobiła z kodem i kiedy to zrobić. W ten sposób możesz automatyzować testowanie lub wdrożenia bezpośrednio z głównej gałęzi repozytorium na przykład.
CircleCI dziedziczy uprawnienia z githuba i bitbucketa związane z konto, które się loguje. W moich testach sprawdziłem, że tak długo, jak masz uprawnienia do zapisu w repozytorium na githubie, będziesz mógł zarządzać ustawieniami projektu w CircleCI (ustawiać nowe klucze ssh, uzyskiwać klucze api projektu, tworzyć nowe gałęzie z nowymi konfiguracjami CircleCI...).
Jednak musisz być administratorem repozytorium, aby przekształcić repozytorium w projekt CircleCI.
Zgodnie z dokumentacją istnieją różne sposoby ładowania wartości do zmiennych środowiskowych w ramach workflow.
Każdy kontener uruchamiany przez CircleCI zawsze będzie miał specyficzne zmienne środowiskowe zdefiniowane w dokumentacji takie jak CIRCLE_PR_USERNAME, CIRCLE_PROJECT_REPONAME lub CIRCLE_USERNAME.
Możesz je zadeklarować w postaci jawnego tekstu wewnątrz komendy:
Możesz zadeklarować je w czystym tekście wewnątrz run environment:
Możesz zadeklarować je w czystym tekście wewnątrz build-job environment:
Możesz zadeklarować je w czystym tekście wewnątrz środowiska kontenera:
To są sekrety, które będą dostępne tylko dla projektu (dla każdej gałęzi). Możesz je zobaczyć zadeklarowane w https://app.circleci.com/settings/project/github/<org_name>/<repo_name>/environment-variables
Funkcjonalność "Import Variables" pozwala na importowanie zmiennych z innych projektów do tego.
To są sekrety, które są ogólnodostępne w organizacji. Domyślnie każde repo będzie mogło uzyskać dostęp do każdego sekretu przechowywanego tutaj:
Należy jednak zauważyć, że można wybrać inną grupę (zamiast wszystkich członków), aby przyznać dostęp do sekretów tylko wybranym osobom. To jest obecnie jeden z najlepszych sposobów na zwiększenie bezpieczeństwa sekretów, aby nie pozwalać wszystkim na ich dostęp, ale tylko niektórym osobom.
Jeśli masz dostęp do VCS (takiego jak github), sprawdź plik .circleci/config.yml każdego repo na każdej gałęzi i wyszukaj potencjalne sekrety w czystym tekście przechowywane tam.
Sprawdzając kod, możesz znaleźć wszystkie nazwy sekretów, które są używane w każdym pliku .circleci/config.yml. Możesz również uzyskać nazwy kontekstów z tych plików lub sprawdzić je w konsoli internetowej: https://app.circleci.com/settings/organization/github/<org_name>/contexts.
Aby ekstrahować WSZYSTKIE sekrety projektu i kontekstu, wystarczy mieć dostęp do ZAPISU do tylko 1 repo w całej organizacji github (a twoje konto musi mieć dostęp do kontekstów, ale domyślnie każdy może uzyskać dostęp do każdego kontekstu).
Funkcjonalność "Import Variables" pozwala na importowanie zmiennych z innych projektów do tego. Dlatego atakujący mógłby zaimportować wszystkie zmienne projektu ze wszystkich repo i następnie ekstrahować je wszystkie razem.
Wszystkie sekrety projektu są zawsze ustawione w zmiennych środowiskowych zadań, więc wystarczy wywołać env i obfuscować go w base64, aby ekstrahować sekrety w konsoli logów internetowych workflow:
Jeśli nie masz dostępu do konsoli internetowej, ale masz dostęp do repozytorium i wiesz, że używany jest CircleCI, możesz po prostu utworzyć workflow, który jest wyzwalany co minutę i który wykrada sekrety do zewnętrznego adresu:
Musisz określić nazwę kontekstu (to również ekstrahuje sekrety projektu):
Jeśli nie masz dostępu do konsoli internetowej, ale masz dostęp do repozytorium i wiesz, że używany jest CircleCI, możesz po prostu zmodyfikować workflow, który jest wyzwalany co minutę i który wykrada sekrety do zewnętrznego adresu:
Po prostu stworzenie nowego .circleci/config.yml w repozytorium nie wystarczy, aby uruchomić budowę w circleci. Musisz włączyć to jako projekt w konsoli circleci.
CircleCI daje Ci możliwość uruchamiania swoich budów na ich maszynach lub na własnych. Domyślnie ich maszyny znajdują się w GCP, a początkowo nie będziesz w stanie znaleźć nic istotnego. Jednak, jeśli ofiara uruchamia zadania na swoich własnych maszynach (potencjalnie w środowisku chmurowym), możesz znaleźć punkt końcowy metadanych chmury z interesującymi informacjami.
Zauważ, że w poprzednich przykładach wszystko uruchamiano wewnątrz kontenera docker, ale możesz również poprosić o uruchomienie maszyny wirtualnej (która może mieć różne uprawnienia chmurowe):
Lub nawet kontener docker z dostępem do zdalnej usługi docker:
Możliwe jest tworzenie tokenów użytkowników w CircleCI do uzyskania dostępu do punktów końcowych API z dostępem użytkowników.
https://app.circleci.com/settings/user/tokens
Możliwe jest tworzenie tokenów projektów do uzyskania dostępu do projektu z uprawnieniami nadanymi tokenowi.
https://app.circleci.com/settings/project/github/<org>/<repo>/api
Możliwe jest dodawanie kluczy SSH do projektów.
https://app.circleci.com/settings/project/github/<org>/<repo>/ssh
Możliwe jest tworzenie zadania cron w ukrytej gałęzi w niespodziewanym projekcie, które leak wszystkie zmienne środowiskowe kontekstu codziennie.
Lub nawet stworzenie w gałęzi / modyfikacja znanego zadania, które będzie leak wszystkie konteksty i sekrety projektów codziennie.
Jeśli jesteś właścicielem githuba, możesz zezwolić na niezaufane orbsy i skonfigurować jeden w zadaniu jako tylną furtkę.
Możesz znaleźć lukę w wstrzykiwaniu poleceń w niektórych zadaniach i wstrzyknąć polecenia za pomocą sekretu, modyfikując jego wartość.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
