13:43
6/5/2019

Porywanie danych dla okupu niekoniecznie musi mieć formę ransomware’u. W czasie majowego weekendu (od 2 maja) ktoś włamywał się na prywatne repozytoria Git i zagroził ujawnieniem przetrzymywanego na nich kodu. Sami programiści mogli ułatwić sprawę atakującym.

Ofiarą tego ataku był m.in. rumuński webdeveloper Stefan Gabos, który opisał swój przypadek na StackExchange.  Stefan pracował na pewnym prywatnym repozytorium i nagle zauważył, że zniknęły z niego pliki z kodem, a pozostał jedynie plik tekstowy o nazwie WARNING.

W pliku była wiadomość od “porywaczy”, którzy zażądali wpłacenia 0.1 BTC na wskazany adres i następnie przesłania dowodu wpłaty mailem w zamian za zachowanie i nieujawnienie kodu. Jeśli wpłaty nie będzie, kod zostanie upubliczniony po 10 dniach.

Oto treść pliku WARNING

To recover your lost code and avoid leaking it: Send us 0.1 Bitcoin (BTC) to our Bitcoin address 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA and contact us by Email at admin@gitsbackup.com with your Git login and a Proof of Payment. If you are unsure if we have your data, contact us and we will send you a proof. Your code is downloaded and backed up on our servers. If we dont receive your payment in the next 10 Days, we will make your code public or use them otherwise.

Stefan przyznał, że takie coś zdarzyło się na tylko jednym z jego repozytoriów, a wszystkie były prywatne. Z tego właśnie powodu wykluczył on możliwość ataku na jego komputer z Windowsem 10 albo na klienta SourceTree, którego używał. Zaatakowane repozytorium miało słabe hasło, w ocenie Stefana łatwe do złamania. To konkretne hasło mogło też znaleźć się w wycieku wraz z adresem e-mailowym Stefana.

Setki dotkniętych repozytoriów?

Inni deweloperzy zaczęli wkrótce zgłaszać podobne problemy. Baza Bitcoin Abuse zawiera obecnie 35 zgłoszeń dotyczących adresu zawartego w wiadomości z żądaniem okupu.

Jeśli przeszukamy GitHuba pod kątem adresu bitcoin powiązanego z atakiem to okaże się, że problem dotknął ponad 300 repozytoriów z tej usługi.

 

Deweloperzy raczej nie zaczną masowo płacić za odzyskanie kodu. Bardziej prawdopodobne jest płacenie za nieujawnienie kodu, a przecież w niektórych przypadkach wyciek kodu może się równać wyciekowi danych osobowych (por. E-maile osób, które przestały korzystać z Fixly, wylądowały na Githubie).

W chwili pisania tego tekstu  na wskazany adres dokonano tylko jednej wpłaty w wysokości 0.00052525 BTC.

Ofiary mogły same ujawnić hasła

Ofiary były też na GitLabie i Bitbuckecie. Przedstawicie GitLaba potwierdzili, że w ramach tej usługi było 131 zaatakowanych użytkowników i 163 zaatakowane repozytoria (wyłącznie prywatne, wszystkie bez 2FA).

Firma Atlassian (dostawca BitBucketa) nie wydała żadnego oświadczenia, ale przynajmniej jeden deweloper dostał od niej wiadomość o ataku. Atlassian twierdzi, że hasła zostały pozyskane z jakiejś innej usługi.

Within the past few hours, we detected and blocked an attempt — from a suspicious IP address — to log in with your Atlassian account. We believe that someone used a list of login details stolen from third-party services in an attempt to access multiple accounts.

Atakujący najprawdopodobniej nie wykorzystali żadnej luki, tylko nieostrożność programistów. Mogli przeskanować sieć pod kątem plików konfiguracyjnych Git, w których przechowywano hasła. Podobnego zdania jest Kathy Wang z GitLaba, która dla prasy wydała oświadczenie poniższej treści.

As a result of our investigation, we have strong evidence that the compromised accounts have account passwords being stored in plaintext on a deployment of a related repository. We strongly encourage the use of password management tools to store passwords in a more secure manner, and enabling two-factor authentication wherever possible, both of which would have prevented this issue.

Problem trzymania na produkcji danych dotyczących kontroli wersji był opisywany już przed laty i dotyczył także czołowych serwisów.

Na blogu GitLab czytamy jeszcze, że w niektórych przypadkach skrypt wykorzystany przez atakujących dostał się na konto, ale nie dokonał w nim żadnych zmian. To zaś sugeruje, że skrypt stworzony z myślą o użytkownikach różnych usług (GitLaba, GitHuba i Bitbucketa) nie zawsze działał poprawnie.

Co robić? Jak żyć?

Wierzymy, że w przypadku większości ofiar repozytorium online nie było jedynym miejscem przechowywania kodu. I zapewne ewentualne ujawnienie kodu może wzbudzać większe obawy.

Wspomniany na początku Stefan Gabos zorientował się, że kod nie został usunięty, ale dokonano zmian w HEAD. Dlatego jeśli dotknął Cię ten problem…

  1. najpierw zabezpiecz dostęp do konta zmieniając hasło i najlepiej włączając dwuskładnikowe uwierzytelnianie (2FA). Oczywiście hasło zmień na takie, którego nigdzie wcześniej nie używałeś/używałaś.
  2. Prawdopodobnie masz kopię repozytorium na swoim komputerze, użyj komendy
    git push origin HEAD:master –force.
  3. Możesz też użyć git reflog albo git fsck by znaleźć swoje ostatnie zmiany i zmienić HEAD. GitLab sugeruje zapoznanie się w tym celu m.in. z tym artykułem Jordana Bacha. No i zawsze warto poszerzyć swoją wiedzę w zakresie tego czym jest HEAD i jak go odzyskać.
  4. Firmy powinny dodatkowo sprawdzić w jaki sposób ich programiści uzyskują dostęp do repozytoriów i czy dane uwierzytelniające nie wyciekły lub nie są dostępne publicznie.

Na prowadzonych przez nas szkoleniach bardzo często spotykamy się z poglądem, że programistów i innych “technicznych” nie trzeba szkolić z podstaw bezpieczeństwa, bo tylko biurowi humaniści nie pilnują swoich haseł. Niestety… równie często spotykamy się z tym, że w danej firmie zaledwie garstka inżynierów używa menedżerów haseł i 2FA, a jeśli zdecydowana większość osób w danej firmie tak robi, jest to bardziej efekt polityki firmy niż osobistego wyboru. Nie wspominamy już o tym, że fachowcy potrafią użyć haseł w rodzaju admin/admin (por. Hasło “admin123” zabezpieczało dostęp do danych posiadaczy Karty Krakowskiej, ponoć “testowych”, ale…).

Okupu lepiej żądać od zawodowca

Z tej historii szczególnie jedna rzecz jest warta zapamiętania. Domaganie się okupu za dane to atrakcyjny, prosty i wydajny model biznesowy. Być może coraz rzadziej będziemy słyszeć o masowych atakach takich jak WannaCry albo Petya. Naprawdę duże pieniądze przynoszą ataki wycelowane w firmy oraz w osoby robiące coś zawodowo. Ostatni duży atak ransomware dotyczył przecież producenta aluminium (zob. To ransomware uderzył w Norsk Hydro).

Firma Sophos ostatnio ostrzega przed ransomwarem o nazwie MegaCortex, który jest narzędziem bardzo zaawansowanym i uderza w firmy z Włoch, USA, Kanady, Holandii, Irlandii i Francji. Co ciekawe, ataki MegaCortex wydają się być wspierane atakami Emoteta co z kolei kojarzy się z ransomwarem Ryuk, który też korzystał z pomocy Trojna i celował w firmy. Nie lubimy przewidywania przyszłości, ale tym razem posuniemy się do wróżenia, że osoby robiące cokolwiek zawodowo będą coraz częściej stykać się z ransomwarem oraz innymi formami “porywania” danych.

To co stało się z repozytoriami Git nie było typowym atakiem ransomware’u, ale jednak było interesującą próbą rozszerzenia tego modelu biznesowego.

Przeczytaj także:

14 komentarzy

Dodaj komentarz
  1. Toć to zwykłe piractwo jest.

  2. Wątpię, aby ktoś zapłacił. No chyba, że kod był wrzucony przez ofiarę na githuba wbrew umowie czy prawom autorskim – wtedy może się opłacać ryzyko dania okupu, odszkodowanie za taki występek może być dużo większe niż dziesięć bitgroszy :-)

  3. Kto normalny wrzuca swój prywatny kod na obcy server?

    • ja wrzucam …ale nie jestem normalny :D – wszystko się zgadza

  4. A Ty trzymasz kod w skarpecie? Czy na niezawodnym ułesbe ktory nie moze sie zepsuc?

  5. Warto dodać że na githubie admin danej organizacji może ustawić ochronę na repo więc w przypadku takiej sytuacji utrata danych ani manipulacja repo nie będzie możliwa.

  6. Tak tylko gwoli scislosci 2FA tu nic nie zmienia :)
    Ja mialem 2FA wlaczone a mimo wszystko “atakiem” zostalem dotkniety. Repozytorium troche zapomniane i sprawdzilem ze haslo moglo byc w ostatnim wycieku danych z morele.net.

  7. Heheh, a mnie nie zaatakowali. Raz że mam backupy, to jeszcze korzystam z Mercuriala a nie gita (który może i działa, ale ma poziom skomplikowania vima kiedy te same “ficzery” da się zrealizować znacznie łatwiej, znacznie prostszymi komendami).

    • Jeszcze raz przeczytałem a skoro przycisku edycji nie ma, to napiszę tutaj “erratę” bo parę rzeczy może być źle zrozumiane: Oczywiście chodziło mi o to że to git jest przekomplikowany, mercurial (hg) jest bardzo łatwy i przyjemny w obsłudze, nawet z linii komend (choć i tak używam nakładek no bo po prostu przyjemniej się przeklikać zamiast otwierać konsolę, wbijać do folderu i dopiero potem commitować/pushować).

    • Dodatkowo jeszcze jedną rzecz którą stosuję to commituję tylko z uwierzytelnieniem przez SSH. Nawet jeśli się ktoś do mojego kodu dobierze to może po HTTPS co najwyżej sobie repo sklonować, bez klucza SSH nic nie zdziała w kwestii modyfikacji repo.

  8. A jak sobie doda klucz?:p

  9. A jak sobie doda klucz?

  10. a to nie ma nic wspolnego z tym ze SHA-1 zostal zlamany a hasla na github sa hashowane tym sposobem?

    • Stawiam ze to wlasnie z tego kierunku poszlo. W panelu nie ma nic na temat logowania itp. A po ssh byl klucz dodany.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: