Podatność XSS w Twitterze. Zdenerwowany badacz udostępnił PoCa. Klikasz w linka i masz przejęte konto

Program Bug Bounty łatwo rozpocząć, trudniej jest nim sprawnie zarządzać i nawiązywać dobre relacje z badaczami bezpieczeństwa. Stawką może być full disclosure na własnej platformie o czym przekonał się X (dawniej Twitter). 

Użytkownik @rabbit_2333 umieścił 11.12.2023 r. post z PoC-em do reflected XSS-a. 

PoC zawierał link do portalu analytics.twitter.com, który służy do prezentacji statystyk powiązanego konta Twittera. URL ten wyglądał w następujący sposób:

hxxps://analytics.twitter.com/mob_idsync_click?BKLISTID=fbzzx&Country=fxpzg&FSale_25Offer_RLE_Ends_EPD00E25=fwngn&OrgURL=cvvff&TIBCO=v6zjh&_101_returnToFullPageURL=otohn&ad_tracking=true&bep_csid=b3atc&brzu=nj1zx&cc=vg6yk&device_id=thlat&embtrk=r32wa&hideCard=g8b7k&idb=AAAAEICqlMGCMk-gSiMpMuNiRkC-SR1GJ1-zqKcpLy1Hrmbe9fxsnRpuyLA6TP25Zu8ATg93eSHJoznfQpU7JEl0f62r5Pe2LWJWQUzL_4ACZlFDOqZ1HXMYjZ-HNR44awQbp-aYickBlzMBKzP0qBykrS_Veox31HBnRjXPeqqyqkxSQ5cObnSxYNYbPQTRyiSOx3kS-f6ZiBIHxtBwbX1PHr6fgstZjZqMR_56ZohShKJeO8z2TPXZuisb7KmTI2J7qLg75L0xPv9_btDhj0Rc1g&ke_efl=t2tk5&pcode=h70ud&prev_fmts=eydk9&q_mailing_7TUwnpGAByUKFEoRC3VwHdrbpSRRaXie9kfMJ=zj7zd&segment_index=zey6z&sfvc4enews=mc1uc&slug=mmkDvcuyDJ&subscribe_cta=hmwlm&tailored_ads=true&twclid="-eval(atob("YWxlcnQoJ1hTUyBQb0MgaGVyZScp"))-"

Interesujący zdaje się być ostatni parametr twclid, który wykonuje funkcję eval na odkodowanym z base64 wywołaniu funkcji alert. Po odwiedzeniu tego adresu w przeglądarce, pojawiał się monit prezentujący wykonanie payloadu z ostatniego parametru. 

Okazuje się, że to znalezisko nie kwalifikowało się do programu nagradzającego zgłaszane luki, jednak po publikacji posta użytkownik został wyrzucony z programu bug bounty:

Wcześniej, jak twierdzi @rabbit_2333, jego raport dotyczący tego błędu został uznany za duplikat (zespół bezpieczeństwa miał być świadomy o istnieniu luki od roku) i odrzucony. 

Początkowo sam reflected XSS nie wydawał się mieć większych konsekwencji, ponieważ ciasteczka twittera mają ustawioną flagę HttpOnly, a portal korzysta z tokenów anty-CSRF. Dodatkowo Content Security Policy ogranicza możliwość dołączenia zewnętrznych skryptów. Więcej o CSP można przeczytać na Sekuraku pod tym linkiem: https://sekurak.pl/czym-jest-content-security-policy/

Jednak Chaofan Shou (@shoucccc) wskazał, że niektóre nieudokumentowane (sic!) endpointy api.twitter.com wykorzystują do uwierzytelnienia nie tylko tokeny, ale też ciasteczka. To powoduje, że XSS na dowolnej subdomenie twitter.com będzie mógł wykonać zapytanie, do którego zostaną dołączone ciasteczka sesyjne użytkownika. 

Okazuje się, że token anty-CSRF to tak naprawdę wynik funkcji skrótu z ciasteczka csrf_id, nie mającego flagi HttpOnly. Co znaczy, że wstrzyknięty kod JS będzie w stanie odczytać csrf_id, a następnie wygenerować poprawny token anty-CSRF. 

Badacz zaprezentował pełny chain pozwalający na dokonanie przejęcia konta (account takeover) przez… kliknięcie w link:

Duże serwisy i platformy internetowe przez ostatnie lata prezentowały raczej dojrzałe podejście do bezpieczeństwa otwierając między innymi programy Bug Bounty. Jednak sam (aktywny) program to oczywiście za mało. Zgłoszenia trzeba przyjmować, dokonywać oceny krytyczności oraz podejmować współpracę z zespołami bezpieczeństwa oraz badaczami w celu załatania wykrytych podatności. 

Tutaj proces ten zdecydowanie poszedł “nie tak”, a badacze postanowili dokonać full-disclosure. Co zmusiło zespół Twittera do wdrożenia poprawek:

~fc