Abusing, czyli taki jakby hacking...

O bezpieczeństwie mówi teraz prawie każdy. Prześcigają się w odmętach internetu "specjaliści" od antywirusów, personal firewalli, bezpieczeństwie systemu operacyjnego czy przeglądarki nań działającej. Często pomysły są wręcz kuriozalne, nie wiadomo czy śmiać się, czy płakać. Dodatkowo spotykam się często ze stereotypem, że jeśli ktoś czegoś nie stracił, to znaczy, że system jest bezpieczny. Pogląd mylny, co zamierzam w poniższym tekście udowodnić. Posłużę się tu przykładem mam nadzieję okazałym i przemawiającym do wyobraźni. Nie będę niczego jednak hackował, sensu stricte. Ja tylko... lekko nadużyję. Zanim jednak przejdę do omawiania przykładu kilka uwag na początek: opisane tutaj metody nie będą gotowymi przykładami do zastosowania w domu. Co więcej - stosowanie tych metod w praktyce jest najprawdopodobniej nielegalne i można za to trafić za kratki. Rzeczy, o których mówię powinny pozostać w wersji teoretycznej, póki potencjalna ofiara nie wyrazi zgody na ich wykorzystanie. Polecam tutaj wszystkim wstęp do podręcznika o metasploicie "Metasploit. Przewodnik po testach penetracyjnych".

Rys historyczny

Całkiem niedawno, mniej niż pół roku temu w końcu zdecydowałem się na zakup FIFY trzynastej tym samym rezygnując z większości wolnego czasu, życia rodzinnego, snu, a czasem nawet ograniczając potrzeby fizjologiczne. Gra ta, żadna to nowość, oferuje grę przez internet, a jednym z najbardziej popularnych trybów gry jest tzw. UltimateTeam. Polega on między innymi na zbieraniu kart zawodników, które można wymieniać lub sprzedawać za wirtualną walutę. Jedną z podstawowych kart jest karta kontraktu (szczegóły łatwo wygooglać). Byłem mocno zdziwiony, gdy karty w dobrej cenie pojawiały się i znikały w czasie tak szybkim, że niemożliwe było zakupienie ich przez konsole. Zacząłem więc interesować się tym odrobinę bardziej i odkryłem (ależ ze mnie Kolumb!), że EA oferuje interfejs webowy do swojej aplikacji. Dzięki niemu, korzystając po prostu z przeglądarki, można zarządzać talią kart. A skoro przeglądarka...

Scouting

Jak wyobrażałem sobie dotychczas przekazywanie informacji przez konsole o wystawionej na aukcji karcie? Nie wyobrażałem sobie w ogóle. Po tym jak uświadomiłem sobie (błyskotliwy, niczym perła na dnie oceanu), że system ten musi być jednocześnie rozproszony i uniwersalny wyobraziłem sobie tylko jedno - REST. Czyli krzyk mody w programowaniu systemów rozproszonych opartych o webserwisy. Mimo, że aplikacja przeglądarkowa oparta jest o flash, bez obaw wdusiłem F12, przeszedłem do zakładki Sieć i patrzyłem co się dzieje... a dzieje się, oj dzieje.

Oczywiście, poza podstawowymi żądaniami o obrazki itd, w oczy rzucają się trzy pierwsze posty. Są tą typowe RESTful zapytania z nagłówkiem X‑HTTP-Method-Override, który odpowiada za zmianę po stronie serwera metody, którą zgłosiła przeglądarka (co zapewnia kompatybilność z różnymi i nieraz kapryśnymi przeglądarkami). Łatwo zauważyć, że zapytania te odpowiadają za pobranie informacji o stanie konta (credits), nowych kartach (new cards) oraz kartach przeznaczonych do wymiany (tradepile). Przy odpowiednim "klikaniu" pojawi się nam czwarty post - watchlist, zawierający informację o kartach przez nas licytowanych.

W związku z tym, że RESTful przekazuje parametry w URL to dość łatwo powinno się dać wykonać wywołanie takiego żądania przez zwykłą przeglądarkę. I tak, wpisując w polu adres następujący url:

https://utas.fut.ea.com/ut/game/fifa13/tradepile

oczekujemy informacji o wystawionych przez nas kartach. Tymczasem dostajemy w odpowiedzi:

{"message":null,"reason":"expired session","code":401}

Tutaj pojawia się pytanie, które by nie padło, gdybyśmy poświęcili trzy minuty na wcześniejszą analizę wymiany nagłówków. Ale jak to mówią, co nagle to po diable.

Odrobina teorii. Jest tylko jedna najbardziej popularna metoda identyfikacji użytkownika w sieci. To ciasteczka. Ewentualnie można czasem usłyszeć, że to sesja, przy czym de facto sprowadza się to do tego samego. Serwer zwraca przeglądarce nagłówek Set‑Cookie, a ta, do momentu, gdy ciasteczko nie wygaśnie lub serwer nie zażąda jego usunięcia (co tak naprawdę sprowadza się do ustawienia tego samego ciasteczka z czasem wygaśnięcia z przeszłości) , będzie wysyłać w żądaniach nagłówek Cookie. Przeglądarka będzie wysyłać ciasteczko zawsze do domeny, z której przyszło i pod ograniczony przy ustawieniu path (czyli ścieżkę). Przynajmniej powinna...

Jak to się ma do naszego RESTa? Ano tak, że gdyby programiści EA ograniczyli zabezpieczenia do ciasteczek, to nasze żądanie wygenerowane w przeglądarce powinno zwrócić odpowiedź zgodną z oczekiwaniem. Tymczasem - expired session. Dlaczego tak się dzieje?

Ano dlatego, że programiści EA zaimplementowali zabezpieczenia dodatkowe, które jednak i tak rzucają się w oczy. Popatrzmy na request skopiowany przez FireBuga:

POST /ut/game/fifa13/user/credits HTTP/1.1
Host: utas.fut.ea.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: s_nr1=1377099186561-REPEAT; utag_main=_st:1377100987464$ses_id:13770xxxxxxx%3Bexp-session; __utma=1190xxx5.25369668.1373555369.1376929564.1377099188.7; __utmz=119042845.1377099188.7.7.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=fifa%2013%20auction%20glitch
Connection: keep-alive
Accept	application/json
Content-length	1
Content-type	application/json
X-HTTP-Method-Override	GET
X-UT-Embed-Error	true
X-UT-PHISHING-TOKEN	2116153xxxxxxx48185467
X-UT-SID	52be5248-ae13-45f9-a8c1-6axxxxx1412

Jak widać leci jakiś cookie (choć, gdy planowałem ten tekst cookie nie było w ogóle. Jest on jednak prawdopodobnie związany z tzw. glitchem, czyli utykaniem kart na aukcjach), ale w oczy rzuca się X‑UT-PHISHING-TOKEN oraz X‑UT-SID.

A co jeśli to właśnie te dane identyfikują użytkownika? Wystarczy popatrzeć na inne requesty- w obrębie "sesji" są takie same. Zmieniają się obie wartości po przelogowaniu. Wszystko więc wskazuje na to, że właśnie w ten sposób następuje identyfikacja.

Skoro mamy już jako takie pojęcie jak odpytywać serwer warto się zainteresować co dostaniemy w odpowiedzi. I tutaj ogromna niespodzianka...

Odpowiedź, którą otrzymujemy jest w JSONie (dla tych bardziej praktycznych - zwracam uwagę na nagłówek Accept-Encoding). Czyli wszystko pięknie zserializowane, bardzo proste i poręczne do użycia. Co więcej - dane przekazywane w JSON zawierają informacje, których nie przedstawia interfejs (ani ten na XBOX, ani ten w przeglądarce)! Nic tylko...

Concept

Mamy więc za sobą rozeznanie, wszystko wskazuje na to, że system da się łatwo wykorzystać. Jak? Na przykład tworząc własnego klienta, którym zautomatyzujemy procesy, do których przeznaczony jest interfejs. Klient może za nas kupować karty, sprzedawać, realizować jakąś narzuconą logikę (nawet bardzo skomplikowaną), wszystko bez tak zwanego elementu białkowego. Czy ktoś coś stracił? Dosłownie - na pewno nie. Czy jesteśmy legalni? Na pewno nie. Czy doszło do hackingu? Naturalnie, że nie. To tylko abusing. Czy więc system jest bezpieczny? No panie...

Posłowie

Za niecałe trzy tygodnie wychodzi najnowsza, czternasta część FIFY. Mam nadzieję, że do tego czasu aplikacja od EA ulegnie modernizacji, która pozwoli w mniejszym stopniu na jej nadużywanie. Z mojego doświadczenia jednak wynika, że mało kto potrafi dobrze zabezpieczyć aplikację www na tego typu ataki (tego typu, to znaczy na ich wykorzystanie niezgodnie z założeniami twórców). Za przykład podam jednak interfejs do zakładania kont na gmailu. Kiedyś mieli z tym problem, dziś to doskonały przykład, że jednak da się to tak skomplikować, że się nie chce nad tym siedzieć. Zwłaszcza, że setki innych i podobnych interfejsów jest dostępnych.

PS. przestrzegam kolejny raz - nie korzystajcie w praktyce z omówionych tutaj przeze mnie metod.

PS#2 - wpis sponsoruje słówko interfejs.