Jak zkontrolovat FiveM resource na backdoor dřív, než ho nainstalujete

Skoro každý kompromitovaný FiveM server, o kterém se dozvíme, byl kompromitován kódem, který si jeho majitel nainstaloval sám. Ne exploitem proti FiveM runtime, ne ukradeným server keyem — resourcem staženým z marketplace, z Discordu nebo z leak fóra, nakopírovaným do resources/ a spuštěným. Jediná skutečná práce útočníka byla přimět vás k instalaci.

To je vlastně dobrá zpráva, protože rozhodující kontrola je ve vašich rukou: revize, která proběhne dřív, než se resource vůbec spustí. Tenhle článek je postup, který používáme my, napsaný tak, abyste ho zvládli ručně. U běžného resource zabere deset až dvacet minut a odchytí drtivou většinu toho, co reálně koluje.

Než začnete: pracujte tam, kde se resource nemůže spustit

Archiv rozbalte na stroji, který není váš herní server, a nic z něj nespouštějte. Čtete soubory, netestujete chování. Ten rozdíl je zásadní: resource, který je škodlivý hned při startu, nepotřebuje vaši nepozornost nijak dlouho.

• Rozbalte do dočasného adresáře mimo strom serveru, ať se omylem nic neocitne v resources/.
• Neotvírejte .exe, .dll, .bat, .ps1 ani .sh, které přišly v údajně čistě Lua resource — jejich přítomnost je sama o sobě nález.
• Sledujte path traversal přímo v archivu (položky začínající na ../). Slušný archiv obsahuje jen vlastní složku.
• Původní archiv si nechte. Když něco najdete, právě nezměněný soubor posíláte do scanneru nebo na kontakt pro hlášení.

Krok 1 — Přečtěte fxmanifest.lua a udělejte si mapu

fxmanifest.lua deklaruje, co FiveM skutečně načítá a kde to běží. Je to jediný soubor, který vám řekne, na kterých z dvou set souborů v archivu záleží. Čtěte ho vždycky první a zapište si tři seznamy: serverové skripty, klientské skripty a zbytek.

fx_version 'cerulean'
game 'gta5'

shared_scripts { 'config.lua' }

client_scripts {
  'client/main.lua',
  'client/ui.lua',
}

server_scripts {
  '@oxmysql/lib/MySQL.lua',
  'server/main.lua',
}

files { 'html/index.html', 'html/app.js' }
ui_page 'html/index.html'

Strana, na které se soubor načte, rozhoduje o tom, kam dosáhne. Klientský skript běží na strojích hráčů, může vám lhát, ale do databáze nevidí. Serverový skript běží ve vašem procesu s vašimi přihlašovacími údaji, vaším MySQL připojením a vaší konzolí — backdoor tam vlastní všechno, co vlastní server. Když máte málo času, čtěte serverové skripty.

Krok 2 — Hledejte čtyři ingredience backdooru

Backdoor, který dává útočníkovi trvalou kontrolu, potřebuje kombinaci čtyř schopností. Jednotlivě jsou všechny legitimní; riziko je v tom, jak se propojí.

# Dynamické načítání kódu — přečtěte každý zásah
grep -rn --include='*.lua' -E '\b(load|loadstring)\s*\(' .

# Odchozí síťová volání
grep -rn --include='*.lua' -E 'PerformHttpRequest|os\.execute|io\.popen|socket' .

# Udělování oprávnění a identit
grep -rn -E 'add_ace|add_principal|ExecuteCommand' .

# Dlouhé bloby, které vypadají zakódovaně
grep -rnE '[A-Za-z0-9+/]{120,}={0,2}' --include='*.lua' .

Zásah není verdikt. Shop resource volající PerformHttpRequest na platební bránu dělá svou práci. Vy hledáte cestu: data přijdou ze sítě, projdou dekódováním a skončí jako argument load(). Pokud tuhle čáru napříč souborem nakreslíte, díváte se na vzdálené spuštění kódu — a o tom, co se na vašem serveru spustí zítra, rozhoduje provozovatel té URL.

Krok 3 — Sledujte data, ne klíčová slova

Vážně míněné backdoory nedávají celý řetěz na jeden řádek. Rozprostřou ho: URL složená ze tří kousků řetězce v konfiguraci, odpověď uložená do tabulky, pomocná funkce v druhém souboru, která ji dekóduje, a volání load() někde, kde to vypadá jako inicializační kód. Hledání klíčových slov najde dílky; řetěz najde jen sledování hodnot.

1. 1

   Začněte u každého load() a jděte pozpátku

   U každého dynamického načtení se ptejte, odkud přišel jeho argument. Literál ve stejném souboru je v pořádku. Proměnná je otázka. Proměnná, která kdykoli držela HTTP odpověď, je odpověď.

2. 2

   Začněte u každého síťového volání a jděte dopředu

   Kam jde odpověď? Pokud se jen porovnává, loguje nebo zobrazuje, dobře. Pokud se dekóduje a předává dál, sledujte ji dál.

3. 3

   Zkontrolujte, co resource dělá při startu

   Podívejte se na kód na nejvyšší úrovni a na první CreateThread. Backdoory chtějí běžet, aniž by musely čekat, až něco spustí hráč.

4. 4

   Přečtěte pořádně konfigurační soubor

   Konfigurace jsou oblíbená skrýš, protože je revizoři přelétnou a provozovatelé v nich edituje. Base64 blob nebo URL v configu si zaslouží stejnou pozornost jako v server/main.lua.

Krok 4 — Posuzujte obfuskaci v kontextu

Obfuskované Lua je u placených resources běžné a samo o sobě není důkazem zlého úmyslu — prodejci jím ztěžují kopírování. Ničí ale vaši schopnost cokoli prověřit, takže mění hodnotu „čisté revize“. Berte ji jako násobitel rizika, ne jako nález: obfuskace v jinak nečinném UI skriptu je jedna věc, obfuskace v serverovém skriptu, který zároveň otevírá socket, je důvod přestat a vyžádat si od prodejce čitelný kód.

Krok 5 — Zautomatizujte mechanickou část

Kroky 1 až 3 jsou přesně ta práce, kterou stroj zvládne lépe než unavený člověk o půlnoci: naparsovat manifest, sestavit graf souborů, protrasovat hodnoty od síťových zdrojů k místům spuštění a nahlásit cestu. Přesně na to jsme postavili FXScan. Nahrajete archiv, nástroj z něj nic nespustí a nahlásí řetěz s názvy souborů a čísly řádků, abyste si nález mohli ověřit sami místo důvěřování skóre.

Nástroj používejte na pokrytí, vlastní čtení na úsudek. Scanner je velmi dobrý v „tahle hodnota se přes čtyři skoky dostane do load()“ a nemá vůbec žádný názor na to, jestli je pro vás přijatelné, že resource volá domů na licenční server prodejce. Tuhle druhou otázku si zodpovíte vy.

Co čistý výsledek znamená a co ne

Statická analýza uvažuje o kódu, aniž by ho spouštěla. To je její síla — během revize se nic škodlivého nespustí — a zároveň její hranice. Resource může dnes stahovat neškodný obsah a příští měsíc něco jiného. Kód lze skládat za běhu způsoby, které žádný statický nástroj nerozpletě. A resource může být naprosto poctivý, a přesto tak špatně napsaný, že hráči předá admina.

• Čistý znamená: v dodaném kódu nebyl nalezen žádný známý škodlivý vzor ani sledovatelná cesta ze síťového zdroje ke spuštění kódu.
• Čistý neznamená: navždy bezpečný, dobře napsaný, bez logických chyb ani důvěryhodný v tom, co dělá s daty, která legitimně sbírá.
• Skenujte znovu při každé aktualizaci. Verze, kterou jste prověřili, není verze, kterou v noci nainstaloval auto-updater.

Právě proto je jednorázový sken u produkčního serveru jen půlka odpovědi. Průběžné sledování — opakovaná kontrola každého resource při změně a upozornění, když se objeví něco nového — je to, k čemu slouží Titan Security Cloud. Jednorázová kontrola vám řekne, co instalujete; opakovaná to, co se změnilo.

Krátký checklist na doma

1. 1Rozbalte mimo strom serveru; nikdy z archivu nic nespouštějte.
2. 2Přečtěte fxmanifest.lua a vypište, co se načítá na serveru.
3. 3Grepujte load/loadstring, síťová volání, přidělování ace/principal a dlouhé zakódované bloby.
4. 4Každý zásah sledujte dopředu i dozadu, dokud nevíte, odkud hodnota přišla a kam jde.
5. 5Obfuskaci posuzujte podle okolí a odmítněte escrow, kterému nejste ochotni věřit naslepo.
6. 6Spusťte automatický sken kvůli pokrytí a čtěte důkazy, ne verdikt.
7. 7Zapište si, kterou verzi jste schválili, a revidujte znovu při každé aktualizaci.

Nic z toho nevyžaduje být bezpečnostní výzkumník. Vyžaduje to brát instalaci jako rozhodnutí, ne jako formalitu — a udělat těch deset minut čtení dřív, než resource dostane přístup k databázi, ne až potom.