Kolejny XSS w Google Colaboratory

18 września 2018, 17:25 | Teksty | komentarze 2

Trzy miesiące temu opisywałem na Sekuraku XSS-a, którego znalazłem w aplikacji Google Colaboratory. Przed przystąpieniem do czytania tego tekstu, zalecam wrócić do tego poprzedniego, bowiem w tym niejako rozwijam tamten temat.

Natomiast w największym skrócie, co się poprzednio wydarzyło:

Szukałem XSS-a w aplikacji Google Colaboratory (aplikacja, która opiera się o Jupyter Notebook, umożliwiając współdzielenie tekstu w MarkDown i wykonywanego po stronie chmury google’owej kodu pythonowego),
Odkryłem, że korzysta ona z biblioteki Mathjax,
Znalazłem błąd w bibliotece MathJax w makrze \unicode{}, które pozwoliło mi na wykonanie dowolnego kodu JS.

Od strony czysto technicznej, ten błąd nie był w samym MathJaksie, tylko we wtyczce, która jest w nim domyślnie włączona, nazywającej się: Assistive MathML.

Zanim twórca MathJaksa naprawił błąd w swojej bibliotece, Google – w ramach łatki – po prostu wyłączyło Assistive MathML. Wydawało się to sensowne podejście, bowiem główna przyczyna XSS-a została całkowicie wyłączona…

Ponowne włączenie Assistive MathML

… o ile oczywiście nie istnieje sposób na ponowne włączenie tej wtyczki!

Któregoś razu, klikając sobie po Google Colaboratory i szukając w nim kolejnych błędów, zauważyłem, że jak dodam kod LaTeX w nagłówku markdownowym i kliknę na niego w postaci wyrenderowanej w konspekcie, wyświetla się wówczas menu MathJaxa.. Co ciekawe, to menu nie pojawiało się w zwykłym tekście. Widać to na poniższym wideo:

Najpierw klikam prawym przyciskiem na „zwykłym” tekście i dostaję standardowe menu z Colaboratory,
Następnie klikam prawym przyciskiem na konspekcie – i tam dostaję menu z MathJaxa.

Dlaczego to menu jest takie ważne? Bo dzięki niemu odkryłem, że istnieje możliwość włączenia ponownie wtyczki Assistive MathML (Rys 1.)!

Rys 1. Możliwość włączenia Assistive MathML z poziomu menu MathJaksa

Okazało się, że po włączeniu tej opcji w menu, byłem w stanie wykonać identycznego XSS-a jak poprzednio, tj. jeszcze raz użyć kodu np.

$ \unicode {41<img src=1 onerror=alert(document.domain)>} $

Efekt widać na rysunku 2.

Rys 2. XSS po włączeniu Assistive MathML

Czy to oznacza, że mamy już na tacy gotowego XSS-a i możemy prosić o bounty? Niezupełnie. Na razie Assistive MathML udało się włączyć ręcznie poprzez menu. Otwarta pozostaje kwestia ustalenia, czy można tę opcję włączyć komuś innemu.

Przechowywanie informacji o Assistive MathML

Zacząłem więc przeglądać miejsca, w których MathJax mógłby zapisywać informację o włączonym Assistive MathML. W pierwszej chwili stawiałem na localStorage, lecz tam było pusto. Drugim typem były ciasteczka i tam rzeczywiście znalazłem następujący zapis:

mjx.menu=assistiveMML%3Atrue

Fakt, że są to właśnie ciasteczka jest fantastyczną wiadomością, bo można ustawić ciasteczko, które będzie wysyłane do innych poddomen tej samej domeny. Opisywałem to kiedyś w tekście pt. Gmail i Google+ – czyli opowieść o dwóch XSS-ach. W największym skrócie atak sprowadza się do tego, że:

Mamy XSS w domenie absolutnie-cokolwiek.google.com,
Wykonujemy tam kod: document.cookie=”mjx.menu=assistiveMML%3atrue; Domain=.google.com; Path=/”
W efekcie, ciasteczko mjx.menu=assistiveMML%3atrue jest wysyłane do wszystkich poddomen google.com.

Atak zasymulowałem przez przypięcie w /etc/hosts domeny some-random-domain.google.com do 127.0.0.1, a następnie wykonałem w niej kod:

<!doctype html><meta charset=utf-8>
<button onclick=exploit() style=font-size:48px>Set cookie and redirect to Colaboratory!</button>
<script>
	function exploit() {
		const COLAB_URL = "https://colab.research.google.com/notebooks/welcome.ipynb";
		document.cookie = "mjx.menu=assistiveMML%3atrue; Domain=.google.com; Path=/";
		location = COLAB_URL;
	}
</script>

Efekt widoczny na filmie:

Podsumowanie

Z powyższego opisu można wyciągnąć dwa istotne wnioski:

Jeśli w ramach bug bounty uda nam się znaleźć jeden błąd, to warto szukać błędów „dookoła” tego błędu.
Jak używamy zewnętrznych bibliotek JS, to warto w trakcie ich audytów zerknąć gdzie one mogą zapisywać dane. Jak pokazuje przykład MathJaksa, może się okazać, że dane z konfiguracji aplikacji mogą zostać nadpisane przez ciasteczka!

Google wypłaciło bounty w tej samej wysokości co dla poprzedniego XSS-a w Colaboratory (tj. $3133,7) pomimo faktu, że ten przypadek niewątpliwie jest trudniejszy w praktycznym wykorzystaniu (wymaga bowiem XSS-a w innej aplikacji). Z tego chyba można wyciągnąć wniosek, że w google’owym bug bounty warto szukać XSS-ów przez ciasteczka ;-)

— Michał Bentkowski

Zaopatrz się w najnowszą książkę sekuraka!

Kolejny XSS w Google Colaboratory

Ponowne włączenie Assistive MathML

Przechowywanie informacji o Assistive MathML

Podsumowanie

Spodobał Ci się wpis? Podziel się nim ze znajomymi:

Komentarze

Odpowiedz