Linux/Filecoder.ECh0raix

Linux-security

Egy XPenology-t futtató NAS-t megevett regglre egy Linux/Filecoder.ECh0raix nevezetű trójai.

Minden fájlnév végéhez került egy .encrypt kiterjesztés, a fájlok mellett pedig egy README_FOR_DECRYPT.txtt fájlban az "instrukciók"

Van erre valami gyógyszer? Gondolom, ha fizetne is valaki, akkor sem történne semmi.

(az "állítsd vissza biztonsági mentésből" jellegű kommenteket kérem mellőzni)

További információk: https://hup.hu/comment/2659697#comment-2659697

  • 1245 megtekintés

Az ilyen generic-es jelzések esetében lehet gyanakodni, hogy az ellenőrző program a vizsgált program viselkedése alapján itéli meg, hogy az veszélyes lehet-e.

Mivel a dekóder program a lényegéből fakadóan olvas, kódól és módosít más fájlokat, ezért akár ez lehet fals pozitív jelzés is az antivírus programok részéről.

Ha parázol akkore egy izolált, hálózat nélküli VM-ben, külön adat lemezre dekódolhatod a fájlaidat. A dekódolásra használt VM-et azán eldobod, az adatdiszkjét pedig egy másik, biztosan tiszta VM-hez felcsatolod és így nyered ki az adataidat.

( friiz | 2021. 08. 06., p – 08:18 )

Welcome to the club!

Én 2 éve várom hátha lesz rá valami, 2019 jul 20-án már a v2-s verziós mókolta a synologykat, amihez tudtommal mai napig nincs dekóder, ha előtte 2 héttel szívom be akkor még lehet jó lett volna az is.

Az a verzió amit fent mutattak az eredeti qnap verzióra volt jó, a synology féle v2-höz már nem működik.

( neutrino v | 2021. 08. 06., p – 08:58 )

Töltsd vissza backupból. Vagy ha nincs backup, meg csirke is vagy a linkelt decryptort használni, akkor pedig őszinte részvétem a veszteséged miatt.

Aláírás _Franko_ miatt törölve. 
RIP Jákub.
neut @

Ebben félig igazuk van. A NAS egyfajta backup, és mint ilyen, fogalmilag egy min. 2. másolatnak kéne lennie, azaz meg kéne lennie azoknak az adatoknak, amikről anno a backup készült. Értem egyébként, hogy rosszul esik a kritika a kollégának, de jogos. Biztonsági mentésnek lennie kell. Lehetőleg minél több lábon állónak. Ez ilyen műfaj, nem szabad semmit csak egy helyen tárolni. Mert akármilyen secure csoda NAS, akár Linux, akár BSD alapú, hardened, NSA approved, friss firmware, RAID/ZFS, stb.. az mind nem ér semmit, ha egy windowsos gépen teljes jogú Samba megosztásként fel van csatolva, úgy olyan simán megy át rajta a locker/wiper virnyák, mint kés a vajon.

Tehát hogy neki is világos legyen: nem a ransomware okozza az adatvesztést, hanem a felelőtlen user, aki 1) windowsos gépei felől támadható, réseket hagy, 2) nem tart backupot. A ransomware-esek ezt csak kihasználják, és szerintem ezzel jót is tesznek, mert ránevelik a usert az adataival kapcsolatos tudatosságra. Ezen most nem a kárörvendést értem, hanem valamiből tanulni kell, és ez a keserű tanulópénz. Ezen meg lehet sértődni, de az a tényeken  nem változtat.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

De vannak, de itt a NAS-ok támadása nem magán a host OS-en történik, hanem a kliensek felől, Windowson, jelszó és korlátozás nélküli automatikus Samba csatolás miatt. Mert ugye a user kényelemből beállítja, hogy a rendszer ne kérjen loginkor meg hálózati megosztás felcsatolásakor jelszót, mert az milyen kényelmetlen már, hogy gépelgetni kell, meg legyen minden admin joggal futtatva, hogy az UAC-vel se kelljen szarakodni, hogy hülyeséget kérdezgessen. Közben meg ezzel ágyaznak meg az ilyen zsarolóvírusoknak. Sokszor ezek ellen egy jól beállított megosztás is jól véd, pl. hogy a user csak egyetlen feltöltési mappába tudjon írni, és onnan a rendszer feltöltés után átmozgatja archív, readonly mappákba, akkor a vírnyák beszopta, mert nem tudja a fájlokat titkosítani, felülírni. Vagy pl. ha a megosztás felcsatolása nem automatikus, vagy jelszó kell hozzá, akkor is pattan lefelé az egész ügyeskedés. De míg a felhasználók a kényelmet keresik, addig a user lesz a támadási pont, mindegy milyen rendszert teszünk alá. Amíg beállítják, hogy ne legyen jelszó, mert macera, ne frissítsünk, mert idő, és macera, jajj, nem kell több mentés, mert idő és macera, addig ez lesz, könnyű támadhatóság, könnyű károkozás, visszavonhatatlan adatvesztésekkel, nagy bőgéssel a végén.

Vannak persze a host oldaláról támadó vírusok is, de azok meg megint olyanok, hogy ha a rendszer jól van beállítva, és rendszeresen frissítve, akkor nem lesz esélye a vírnyáknak, eleve befoltozott rendszerrel fog találkozni, meg nem lesz joga semmihez, hogy garázdálkodjon vele.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Hát pont, hogy egy rakás linux alapú nas-t (synology, qnap) törnek automatikusan, féreggel, és egymást fertúzik halálra ezek a gépek. Nem a kliens os felöl jön mindig a támadás.

"ha a rendszer jól van beállítva, és rendszeresen frissítve, akkor nem lesz esélye a vírnyáknak, eleve befoltozott rendszerrel fog találkozni, meg nem lesz joga semmihez, hogy garázdálkodjon vele."

Pont mint windows-on.

( tigrincs | 2021. 08. 06., p – 09:02 )

Az kiderult, hogy hogyan sikerult bekapni?

Sajnos nem. Egy adott főverziót addig faragnak amig hajlandó elindulni. Ha csak egyetlen patch-et is felraksz rá dsm alól, az többet nem bootol be. Package-eket persze rakhatsz fel, frissitheted is őket folyamatosan, de maga a linux az lyukas marad alatta.

(én legalábbis igy tapasztaltam mikor játszottam vele)

Semmiképpen nem a topicnyitót bántva, de nem egészen értem, hogy valaki miért nem inkább saját megoldást csinál.

Fogni valami normális méretű dobozt (ami elfér a speizban vagy a garázsban vagy bárhol) bele egy disket az OS-nek, meg az összes többi szabad helyet telerakni diskekkel, majd rá egy standard, karbantartott NAS szoftvert, vagy akár csak egy sima linuxot és kész, nincs vendor függőség, meg backdoor meg lószar.

Nekem ez most csak egy RPi akárhány, 2 darab külső USB-s diskkel. Lassú mint a disznó, de nem is kell gyors legyen (háztáji felhasználásra elég).

hogy valaki miért nem inkább saját megoldást csinál.

Mert ahhoz nem árt egy kis tudás, nem csak kattingatni. Persze utólag kiderül, hogy néha az ilyen megoldásokhoz is jó lenne, de akkor már általában már késő.

Fedora 41, Thinkpad x280

ahogy irtak, a sajat cucchoz erteni kell. te ertesz hozza van >10 ev linux/unix tapasztalaod. ha nem csak egy fileszerver kell, hanem egy kicsit tobb (pl torrent, online doksi, keptar, backupolas, stb) ott mar azert kell egy jokora tudas osszerakni. a dsm meg eleg jo lehet egy atlag usernek, nemkell hozza 3 ev linux ismeret es osszerakhato benne eleg sok minden. persze a synology vedi a sajat cuccat (hogy vegye meg mindenki a nemolcso hw-t), ezert kellenek ezek a xpenolgy hackok, hogy elinduljon "normal" vason is. aztan persze megy a macska-eger harc... :/

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Vagy ha már NAS, akkor legyen dobozos, támogatott termék, ne egy gányadék. Nem ismerem az xpen..izét, de ahogy irjátok, nincsenek rá patchek? Innentől kezdve játékszer.

Nekem pl. synology van ami automatikusan telepiti a security fixeket.

A saját összerakás sem rossz, mert nagy a kontrollod felette, de rengeteg idő és odafigyelés tényleg korrektül összerakni.

Lehet hogy nem közös a megértésünk.

Az xpenology egy hoki-projekt, amit nem megveszel, hanem letöltesz és telepitesz a hoki-összerakott PC-dre. Innentől a te felelősséged, problémád, hogy a hoki-hardveres hoki-szoftvered nem támogatott. Ezt lehet tudni, de legalábbis sejteni.

A synology, QNAP, meg társaiért bemész a boltba, setupolod, és megkapod a security supportot x évig.

( elod v | 2021. 08. 06., p – 09:44 )

Szerkesztve: 2021. 08. 06., p – 09:44

Ilyenkor gondolkozom el mindig azon, hogy az állományok tárolását, snapshot-ot, backup-ot nagyon el kéne már különíteni a felhasználó felé "szolgáltató" rétegtől.

Nyilván. De amíg nem ér el magához a tárolóig, addig a snapshottal nem tud mit kezdeni.

Ha viszont azon a rendszeren snapshotolgatsz amit felnyomott, ott vígan kezdheti azoknak a törlésével. Ahogy annó Windows-on a shadow copy-val.

Lehet containerben gondolkozni vagy full VM-ben. Az utóbbi még elég ritka kisebb Syno-n.

"Ahogy annó Windows-on a shadow copy-val."

Annyiszor le lett már irva, hogy ez hülyeség. Szart sem tud kezdeni egy windows-os fileszerver shadow copy-jával a kliens, még ha system jogot is szerez a kliensen, nehogy törölni.

Már ugye nyilván file szerverről beszélünk egy cég esetén és nem a kliens saját gépéről.

Tucatnyi fileszerver fut igy nálunk. Kényelmes, a user tudja böngészni a shadow copy-kat, magának vissza is tudja állitani amit elcseszett, de törölni nem tudja a shadow copy-kat a szerverről. Tökéletesen véd ransomware ellen amig a kliensen futtatják azt. (nyilván, ha a szerveren futtatnák ott már gond lenne, ha system jogot is meg tudná szerezni, de ott nyilván nem történik ilyen)

Én a saját NAS-omon úgy csinálom, hogy 2 óránként lövök egy snapshotot, ami nem érhető el SMB-n keresztül. A két órás snapshotokat egy hétig tárolom, illetve minden hétről el van rakva egy egy hónapra, és minden hónapról egy egy évre. Van egy másik gépem, amit manuálisan szoktam indítani, semmi másra nem használom, és rsync-en áthúzza az adatkupac lényegesebb részét (fényképek, nehezen pótolható anyagok).

( falu v | 2021. 08. 08., v – 20:57 )

További információk:

Valahogy bejutott a rohadék a NAS-ra, majd megkezdte "áldásos" tevékenységét. Úgy fedeztük fel, hogy a kliens gépek munka könyvtárai Syncthing segítségével voltak szinronban tartva egymással és a NAS-sal, ez meg szépen leszórta a titkosított fájlokat a kliens gépekre. Backup volt, de nem mindenről. A kritikus adatok 99%-ban vissza lettek állítva, de nem lenne rossz, ha a többit is sikerülne valahogy.

A neheze (számomra) több részből áll:

- a NAS-on egy több lemezes szoftvres RAID 1-ben voltak/vannak a lemezek, ezek másik gépre felcsatolva, Linux RAID fájlrendszerként látszanak, fogalmam sincs (még), hogyan lehetne úgy mountolni ezeket, mint a NAS-on, ennek megfelelően az adatokat se tudom leszedni róluk

- a NAS elindul a lemezek nélkül is (lemezekkel nem merem indítani), ez azért is jó, mert valahogy meg lehetne találni a kis genyót, lelőni a processzt, de fogalmam sincs, hogy a sokból melyik lehet az. Attól tartok, hogy ha újból lemezekkel indítom el, akkor tovább dologozik a mocsok

Maga a rendszer egy pendrive-on van. Más live linux simán bootol. A vas egy HP MicroServer N54L

[Falu.Me]==>[-][□][X]

( Adamyno | 2021. 08. 09., h – 14:20 )

OFF

Ezek után biztosabb lettem abban, hogy ha magamnak készítek NAS-t, akkor fontos a rendszeresen karbantartott és friss szoftverekre/kernelre épülő megoldás.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

+ külön container vagy VM mindenféle csilivili alkalmazásnak.

 

Pont a topic miatt tegnap megnéztem a TrueNAS-t, hogy milyen. Az is mindent jail-be akar tenni (az más kérdés, hogy nem sikerült neki...). Szóval igen, VM-ek vagy konténerizáció. Meg az automata snapshot-ok.

Mit egyszerűsít le ?  Ha nekem kell egy apache2 minek rakjam konténerbe ? Mit nyerek velek ? 

Nekem van otthon házi szerver virtualizálva van rajta egy openwrt ami a router, van rajta egy nas, amin fut minidla, samba, torrent, plexmedia szerver. A torrent amit leszedek rögtön kiszolgálja az előző 3 protokoll. plex letölti hozzá a feliratok ha kell stb.

Mivel egyszerűbb ha ezeket külön külön konténerbe rakom ? Ráadásul akkor még adatcserét uid/gid problémákat is meg kell oldani.

 Persze lehet én nem látom át :D

Fedora 41, Thinkpad x280

Jó neked, ha még sosem szaladtál bele abba, amikor két szolgáltatás valamilyen függőségből két eltérő verziót akar, és egyik sem hajlandó a másikéval működni. Na arra például tök jó.

Egyébként a konténerezés nem feltétlenül egyenlő a dockerrel. Az a hozzáállás nekem sem szimpatikus. Viszont azt szeretem, ha az egybe tartozó dolgokat össze tudom csomagolni, és nem kell reszelgetni a közös pontokat, hogy megférjenek egymás mellett. Pl. nekem is volt telepítve apache, meg mariadb, meg hasonlók a gépre, amik a saját kis tákolt, belső hálón használt szolgáltatásomat működtették. Aztán akartam egy librenms-t, csináltam neki egy konténert, telepítettem bele, megy minden alapbeállításokkal. Később akartam egy nextcloudot is, ő is kapott egy konténert, meg egy virtuális hálókártyát is. Így el tudtam rakni külön publikus VLAN-ra, meg szanaszét tudom tűzfalazni (mert a paranoia jó).

Jó neked, ha még sosem szaladtál bele abba, amikor két szolgáltatás valamilyen függőségből két eltérő verziót akar, és egyik sem hajlandó a másikéval működni. Na arra például tök jó.

De futottam, de ez számomra már a tákolás, és ilyet kerülöm :D Azt a verziót használom, ami distro szállít, akár külső repokkal. 

Persze van nálam is 1-2 tákolás, de akkor megoldottam chroot-al (centos 7, alatt centos6) oszt jónapot (mert konténer ide vagy oda az még azért működik)

Fedora 41, Thinkpad x280