Żądny wiedzy? Wbijaj na Mega Sekurak Hacking Party w maju! -30% z kodem: majearly
Kolejny XSS w Google Colaboratory
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
Extra robota i extra opis!
Życzę kolejnych sukcesów w przyszłości!
Wielki + za to że opisujesz step-by-step swoje odkrycia, ciekawe to jest ;)