Żądny wiedzy? Wbijaj na Mega Sekurak Hacking Party w maju! -30% z kodem: majearly

Google: Korea Północna uderzyła w badaczy bezpieczeństwa. Fałszywe blogi, fałszywe projekty w Visual Studio, 0daye na Chrome, lewe DLL-ki, …

26 stycznia 2021, 11:29 | Aktualności | komentarzy 5

Tego chyba jeszcze nie było. Google donosi o intrygującej kampanii realizowanej przez rząd Korei Północnej:

The actors behind this campaign, which we attribute to a government-backed entity based in North Korea, have employed a number of means to target researchers which we will outline below.

O co dokładnie chodzi? Napastnicy wynajęli ludzi, którzy stworzyli fałszywe twitterowe profile badaczy bezpieczeństwa (były tez profile na LinkedIN czy w innych miejscach):

powstał również cały blog z ciekawymi „znaleziskami”:

W szczególności, w styczniu 2021 został opublikowany PoC w formie filmu, dostępnego na YoutTube, na podatność: CVE-2021-1647. Sam film miał pokazywać odpalenie windowsowego CMD poprzez wykorzystanie dziury w Windows Defenderze. Film okazał się być fałszywką…

Po co to wszystko – zapytacie? Ano po to, żeby zaatakować badaczy bezpieczeństwa. W akcji był wykorzystywany np. scenariusz socjotechniczny, polegający na zaproszeniu danego badacza do wspólnej pracy (kto by nie chciał dostać dostępu do jakiegoś świeżego, ciekawego 0-daya). Tutaj oferowany był np. projekt w Visual Studio + dodatkowe dll-ki, które okazały się być… backdoorem:

After establishing initial communications, the actors would ask the targeted researcher if they wanted to collaborate on vulnerability research together, and then provide the researcher with a Visual Studio Project. Within the Visual Studio Project would be source code for exploiting the vulnerability, as well as an additional DLL that would be executed through Visual Studio Build Events. The DLL is custom malware that would immediately begin communicating with actor-controlled C2 domains. An example of the VS Build Event can be seen in the image below.

Inny scenariusz, pod przykrywką ciekawych podatności, wykorzystał realne 0-daye celujące w komputer badacza. Wystarczy, że odwiedził on pewnego bloga. W pełni załatany Windows 10 + Chrome – to nic, backdoor i tak dostawał się na komputer ofiary:

In each of these cases, the researchers have followed a link on Twitter to a write-up hosted on blog.br0vvnn[.]io, and shortly thereafter, a malicious service was installed on the researcher’s system and an in-memory backdoor would begin beaconing to an actor-owned command and control server. At the time of these visits, the victim systems were running fully patched and up-to-date Windows 10 and Chrome browser versions. 

W szczególności napastnicy komunikowali się z potencjalnymi ofiarami z wykorzystaniem takich platform jak: Twitter, LinkedIn, Telegram, Discord, Keybase (były tez komunikacje z wykorzystaniem e-maila).

W raporcie dostępne są znane aliasy, konta czy domeny biorące udział w akcji (czasem są to „normalne” domeny, jednak zostały wcześniej przejęte przez atakujących). Z oczywistych przyczyn nie zalecamy odwiedzania cytowanych w raporcie profili czy linków.

–ms

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Na koncie admina, czy nie?

    Czy dla zadzialania tych exploitow, ktore powodowaly „a malicious service was installed on the researcher’s system and an in-memory backdoor would begin […]” dochodzilo, gdy ofiara weszla na strone bloga z konta nieuprzywilejowanego, czy musiala byc na koncie administratora Windows?

    Odpowiedz
    • Trochę się pomądrzymy (bo trzeba by zerknąć do researchów ;) Najprawdopodobniej nie. Zazwyczaj ktoś wykorzystuje buga w Chrome, musi wyskoczyć z sandboxa i zrobić eskalację uprawnień do admina (choć ta ostatnia klasa błędów jest względnie częsta – nie wiadomo czy exploit miał też taki fragment; albo może wiadomo tylko trzeba poczytać trochę głębiej).

      Odpowiedz
      • ruduś

        Polecam posłuchać podcast Darknet Diaires – 82: Master Of Pwn. Zostaje tam w sumie omówiona kwestia wydostawania się z sandboxa i przejmowania systemu, tylko poprzez załadowanie strony :)

        Odpowiedz
        • Oczywiście jest to możliwe, ale 0daye na cały ciąg podatności są… dość drogie. No więc taka operacja rzeczywiście ekstremalnie utrudnia eksploitację (vs. scenariusz ze zwykłą przeglądarką odpaloną bezpośrednio w głównym OS).

          Odpowiedz
          • Kurak

            Historia CVE pokazuje, że łatwiej wyskoczyć z sandboxa Chrome niż zrobić RCE w rendenerze. Czy był możliwy ciąg podatności na skompromitowanie całego systemu?
            Artykuł napisany przez Google TAG, a zobaczcie sobie na podatności zgłoszone przez ten zespół w ostatnich miesiącach ubiegłego roku jako „exists in the wild”: CVE-2020-17087, CVE-2020-15999, CVE-2020-16009, CVE-2020-16010 :)

Odpowiedz na sekurak