A Sucuri és a Malwarebytes kutatói észlelték a tömeges fertőzést, amely egy korábban már sérülékenynek jelentett Wordpress Duplicator plugin miatt következett be. 

A pontos érintettek száma nem ismert, egy egyszerű Google keresés azonban több, mint 2600 találatot mutat, de az indexelés miatt ennél jóval magasabb is lehet a fertőzöttek száma.

A Google alapján magyar érintettet nem találtunk (pontosabban csak egy olyan oldalt, ahol a Google szerint még szerepel a kód, de egyébként már nem).

Igen népszerű lett az előző „Olcsók a feltört magyar weboldalak” című poszt, amelyben arról írtunk, hogy egy orosz fórum piacterén több, mint 3000 feltört weboldalhoz kínálnak hozzáférést, amelyek között magyar oldalak is akadnak.

Sok megkeresés érkezett a témában, sok kérdést kaptunk, illetve egy érdekes és figyelemfelkeltő fejleményről is be tudunk számolni.

Egy orosz forum piacterén több, mint 3000 feltört weboldalhoz kínálnak hozzáférést. Igen széles a választék, a megszerzett adminisztációs jelszó mellett lehet (backdoor) shell, vagy akár SSH hozzáférést is vásárolni a meghekkelt oldalakhoz.

Igazán professzionális és funkciógazdag marketplace, lehet országra, nyelvre, CMS rendszerre, programozási nyelvre, hozzáférés módjára (admin access, shell, SSH, FTP stb) is szűrni, kiválasztva ezzel, hogy milyen hozzáférést akarunk vásárolni.

Fülig Jimmy mondása, miszerint „Mindnyájunkak érhet baleset” a Veeam esetében is igaz: a magát „global leader in Intelligent Data Management”-nek aposztrofáló adatmentésre és mentőrendszerekre specializálódott cég igen masszív adatszivárgási incidensbe keveredett.

A korai analízisek 445 millió rekordról beszélnek, noha két adatbázis szivárgott ki, az egyik 199 millió, a másik pedig 244 millió rekordot tartalmaz.

A vizsgálatok szerint jelentős átfedés van a két adatbázis között, ez ugyan a rekordszámot nem csökkenti, viszont az egyedi adatokkal kapcsolatban csökkenhet a szivárgás mérete, erre később a Veeam is rámutat. (A 4.5 millió egyedi adatokat tartalmazó rekord meg már majdnem semmi).

Az előző postban kicsit összehasonlítottam a 2017-es tavalyi évet a jelenlegi 2018-as évvel, és az eredményből sajnos nem az körvonalazódik, hogy észlelhető pozitív változások következtek volna be.

A 2018-as év nyara meglehetősen súlyosra sikerült, csak augusztusban 215 millió, júliusban 140 millió, míg júniusban 146 millió adatrekord kompromittálódott vagy bizalmassága sérült.

Melyek voltak a legsúlyosabb, vagy legfontosabb adatszivárgások a nyáron?

Nem feltétlenül a kiszivárgott rekordok számossága alapján próbálok szemezgetni a bőséges termésből, igyekszem olyan nevekkel foglalkozni, amelyek itthon sem teljesen ismeretlenek, vagy kellően érdekes eseteket takarnak.

GOMO (Sungy Mobile)

A GOMO adatszivárgási ügye kicsit kiesik a szkópból, a felfedezője május 25-én észlelte (egy Flash Gordon nevű kutató), hogy a cég egy backupja minden további nélkül elérhető egy teljesen védtelen, hitelesítést nem kérő webszolgáltatáson keresztül.

A cég nem tüntetett fel értesítési címet a weboldalán, valamint a közösségi médiás megkeresésekre sem reagált, és Flash Gordon május 27-én egy másik IP címen megtalál egy csomó további mentés,- minden bejelentkezés vagy hitelesítés nélkül elérhető, állományait.

Május 30.-án végül sikerült az NTT Com Asia segítségével elérhetetlenné tenni az állományokat, de június 2.-án már ismét elérhetőek voltak. Az ismételt bejelentés után az NTT Com Asia segítségét kérve végül sikerült a szervereket újra elérhetetlenné tenni.

A kicsomagolva csaknem 100GB adatban aztán volt minden jóság, 70 adatbázis, 50 millió emailcím, jelszó, telefonszám-rekord, céges felhasználói adatok, ügyféladatok, fejlesztési környezet, forráskódok, stb. Gyakorlatilag minden.

A GOMO augusztus 16.-án reagált érdemben az eseményekre, a válaszban azt közölték, hogy a vizsgálat alapján két letöltés (??) történt az esemény időszakában, illetve elmondták, hogy egy műszaki probléma javítása miatt kellett a 80-as portot megnyitniuk, amelyet aztán egy másik technikai hiba miatt nem sikerült bezárniuk (konkrétan, szerintem az első hiba tűzoltása közben teljesen megfeledkeztek róla). A GOMO arra is reagált, hogy nem volt az oldalukon kontakt lehetőség, és jelezték, hogy már van.

Szerintem az eseményből a legfontosabb tanulság, hogy egy hibajavítás (mint ASAP tevékenység) mennyire megmutatja a prioritásokat: a rendelkezésre állás mindig is magasabb prioritással bírt, mint a biztonság. Szintén érdemes az esetből kiemelni, hogy két sor hozzáadása (két email cím) a weboldalhoz mennyivel hatékonyabba tette volna az incidens keresését. Néha ilyen apróságon nagyon sok tud múlni.

Huazhu Hotels 

A 3000 hotelből álló kínai hotellánc augusztusban került a figyelem középpontjába, mivel a 130 millió ügyfélrekordjuk kiszivárgása Kína egyik legnagyobb adatszivárgási ügyévé vált. Az esemény a hotellánc Hanting, Grand Mercure, Yi, Novotel, Mercure, CitiGO, Orange, All Season, Starway, Ibis Styles, Ibis, Elan, Haiyou hoteljeit érintette (és ezek között azért pár jól ismert név is szerepel).

A kiszivárgott adattömb 240 millió sora a foglalási adatokat tartalmazza, természetesen email címek, telefonszámok, bankszámla adatok, regisztrációs jelszavak, személyi okmányazonosítók is szerepelnek az adatbázisban.

Ami miatt különösen érdekes a sztori, hogy az adatok szinte azonnal megvásárolhatóvá váltak a DarkNet bugyrában, az eladó 8 Bitcoin-ért kínálta fel a megszerzett adatokat, amely kb. 14.5 millió Ft-nak felel meg a mai árfolyamon. Aki esetleg sokallja ezt az összeget az örülhet, mivel a breach híre gyorsan elterjedt és a hotel is reagált az eseményre, a megszerzett adatok gyorsan értéktelenedni kezdtek, és hamarosan már 1 Bitcoin-os áron (1.8 millió Ft) is megvásárolhatók lettek.

A világ 12. legnagyobb hotellánca érdemben reagált az eseményre (biztonsági céget bízott meg az adatok validálásával és esemény kivizsgálásával), nem is csoda, az elmúlt 5 évben ez az esemény bizonyult Kína egyik legsúlyosabb adatszivárgási incidensének, legalábbis az esetet vizsgáló biztonsági cég állásfoglalása alapján.

T-Mobile

A szolgáltató neve igen ismerősen cseng, bár jelen esetben az amerikai szolgáltatóról van szó, akiknek augusztusban sikerült elszenvedniük (pontosabban akkor ismerték el tájékoztatásban) a 2.3 millió ügyfélrekordot érintő adatszivárgási incidenst.

„Szerencsére” az esemény csak email címeket, neveket, születési dátumot, számlázási címeket, előfizetői azonosítókat érintett, bankkártya vagy más, fizetéssel kapcsolatos adatok nem kompromittálódtak.

A T-Mobile reagálása abban példaértékű volt, hogy viszonylag gyorsan megkezdték az esemény kivizsgálását és szinte azonnal értesítették az ügyfeleiket. A T-Mobile saját biztonsági csapattal rendelkezik, szóval nem kellett külsőst bevonniuk az esemény kivizsgálására.

(A T-Mobile Austria azért nem ilyen szerencsés, miután kiderült, hogy részletében cleartext-ben tárolják a jelszavakat (legalábbis az ügyintézők látják a jelszó első négy karakterét), sikerült a Twitteren „véletlenül” azt nyilatkozniuk, hogy nem értik, ez miért probléma. Ez mindjárt hozott is nekik egy jelölést a Pwnie Awards-on, a „Legbénább reagálás” kategóriában, amit aztán végül annak ellenére sem sikerült megnyerniük, hogy bevallották, a jelszót teljesen cleartextben tárolják.)

Azonban nem szép az összkép az amerikai T-Mobile esetében sem, mert az eredeti bejelentésben azt nyilatkozták, hogy jelszavak nem kompromittálódtak, majd később, hogy azért nem kompromittálódtak a jelszavak, mert titkosítva voltak.

Innen már csak egy lépés volt, hogy kiderüljön, a T-Mobile a titkosítás alatt az MD5 hash-t értette...Legalábbis kutatók vizsgálták meg a hasheket, amelyek azért nem tiszta MD5 hashek (valamit mókoltak vele), viszont legalább úgy néz ki, hogy egy nagyobb mintából kikövetkeztethető az algoritmus és visszaállítható a jelszó (egyes kutatók szerint viszont sima MD5 hashek kerültek ki).

A T-Mobile úgy látszik nem feltétlenül a tájékoztatásban nyerő, az ausztriai fiaskóval együtt ez kezd kicsit tendenciózusnak tűnni.

MyHeritage

Az egyik legnevesebb DNS-kutató és genealógiai oldalt június 4.-én értesítette egy szakértő, hogy egy, a szolgáltatótól független kiszolgálón talált „myheritage” nevű állományban a szolgáltatótól származó adatok találhatók.

A vizsgálat később kiderítette, hogy az állomány a 2017 október végéig regisztrált felhasználók email címeit és hashelt jelszavait tartalmazta, összesen 92 millió adatrekordot. A szolgáltató szerint a DNS-és egyéb vizsgálati adatok nem kerültek idegen kézbe, ami azért megnyugtató.

Az adattömb elemzése megerősítette, hogy salted hasheket tartalmaz az adatbázis, tehát nem csak simán elhashelték a jelszavakat (gyenge MD5-tel mondjuk), de legalább jól megsózták őket és elvileg minden felhasználó esetében egyedi hash- tároltak le.

A MyHeritage esetében szerintem a legfontosabb, hogy az oldal egyáltalán nem tette lehetővé a kétfaktoros hitelesítés használatát, a szuperérzékeny személyes adatok és DNS vizsgálati eredmények eléréséhez a bejelentkezéshez a felhasználóknak elegendő volt egyetlen jelszó megadása.

Ezt a tényt Brian Krebs, a legismertebb security blogger is erősen sérelmezte, és megjegyezte, hogy meglehetősen fura, hogy a MyHeritage csak most, az esemény után gondolkodik el a dolgon és kezdi meg annak megvizsgálását, hogyan tudna kétfaktoros hitelesítést bevezetni.

Ticketfy

A nyár nem kedvezett a jegyértékesítő oldalaknak, az angol Ticketmaster júniusban értesítette az ügyfeleket, hogy kb. 40 ezer rekordjuk kompromittálódott. Később kiderült, hogy a február és június között jegyet vásárlókat érintette az esemény.  

Az Eventbrite tulajdonában lévő jegyekkel üzletelő Ticketfly május 31.-én néhány napra leállította a weboldalát és szolgáltatását, mivel „kibertámadás” érte őket, amelyről később kiderült, hogy 26 millió felhasználói adatot kompromittáló adatszivárgás-incidens.

Június 2-án tért vissza a szolgáltatás és jelent meg a szolgáltató közleménye az esettel kapcsolatban, ahol elismerték, hogy hackerek fértek hozzá az adatbázishoz.

A későbbiekben megerősítésre került, hogy nem csak sima adatlopás történt. A hacker közzétette a megszerzett adatok egy részét (az email címeket, illetve kisebb számban felhasználó neveket, telefonszámokat, lakcímeket, viszont a jelszavakat, bankkártya adatokat nem).

Kiderült, korábban a hacker jelezte a biztonsági rést a Ticketfly-nak, és 1 Bitcoin-ért cserébe segített volna a biztonsági rést befoltozni, azonban a szolgáltató nem reagált a megkeresésére. A hacker erre a sérülékenységet kihasználva defacelte az oldalt, majd elvitte és nyilvánosságra hozta az adatok egy részét.

A tanulság ebből az, hogy egy sérülékenység lejelentésére nem az a válasz, hogy nincs válasz. Nem arra gondolok, hogy a Ticketfly-nak ki kellett volna fizetnie a „segítség” díjját (konkrétan zsarolást), ám az sem megoldás, hogy figyelmen kívül hagyták az egész szituációt. (Bár szerintem, ha a vezetőség előre látta volna, hogy mi fog történni, akkor boldogan kifizették volna a nevetséges 1 Bitcoin-os összeget, amely elenyésző az így bekövetkezett kárhoz képest).

British Airways

Rájár a rúd a légitársaságokra, Rambó kolléga a kiváló és méltán népszerű Antivírus blogon a napokban írta meg az Air Canada adatszivárgásának esetét, úgyhogy erre csak a British Airways lehet a Kiberblog válasza.

A légitársaságnál is átnyúlunk az időben szeptemberig, mivel az eset feltételezett időpontja augusztus 21 és szeptember 5 közé esik.

A BA rendszeréből 380 ezer rekord került ki, amelyek financiális adatokat, fizetési információkat és személyes adatokat tartalmaznak. Meg bankkártya számokat, lejárati időt és biztonsági kódot a kártyához...Szóval bár számosságában ez az eset eltörpül a sokmilliós incidensekhez képest, súlyosságát tekintve azonban az élvonalba tartozik.

Az eset a ba.com és a hozzá tartozó mobilalkalmazás felhasználóit, jegyfoglalóit, vásárlóit érinti. Az Avast kutatója szerint a támadók a légitársaság és a fizetést biztosító szolgáltató közé ékelődhettek be valahogyan, erre enged következtetni, hogy tisztán csak a fizetésekkel kapcsolatos adatok kompromittálódtak, olyan adatok viszont nem, amelyek az utazásra vonatkoznának.

Adidas

Június végén az Adidas is csatlakozott az adatszivárgást elszenvedett nagyvállalatok illusztris köréhez.

Az amerikai weboldal sérülékenységét kihasználva a támadók „néhány millió” ügyfélrekordhoz fértek hozzá. Meglehetősen kevés információ áll rendelkezésre az esettel kapcsolatban (még mindig zajlik a vizsgálat), nem ismert pontosan az érintettek száma sem, az Adidas szóvivője maga is néhány millióról beszél.

Az Adidas a közleményében azt állítja pénzügyi adatok, bankkártya információk nem szivárogtak ki, az eset a felhasználói email címet és a titkosítottan tárolt jelszavakat érintette.

Helsinki utca

Hogy ne csak az elektronikus adattárolás kerüljön górcső alá, Helsinkiben egy csomó páciens adatait tartalmazó dokumentumot reptetett ide-oda szél az utcán.

Az 1980 és 1990 között keletkezett iratok (kizárólag nőkről) aztán mindenféle jóságot tartalmaztak a neveken és azonosítókon kívül, kórtörténetet, nemibetegség-leírásokat, vizsgálati eredményeket, stb.

Nagyjából megállapítható volt, hogy a dokumentumok olyan 1960-as években született, női betegek adatait, vizsgálati eredményeit tartalmazták, akik valamilyen módon a szexuális úton terjedő betegségekkel, azok megelőzésével kapcsolatos vizsgálatokban és tanulmányokban szerepeltek.

SingHealth

Ha már egészségügy, Szingapúr egyik legnagyobb adatszivárgási incidensét szenvedte el a SingHealth egészségügyi intézmény.

Az eset érdekessége, hogy a kommunikáció alapján elsősorban nem a betegadatokra mentek a támadók, hanem kifejezetten Lee Hsien Loong miniszterelnök adatai érdekelték őket (persze ki tudja, lehet, hogy itt is az volt, hogy: „Bástya elvtársat már meg sem akarják ölni?”).

A miniszterelnököt korábban mindenféle betegséggel, többek között prosztatarákkal is kezelték az intézményben, de hogy valóban ő volt-e a célpont, azt nem lehet tudni. Bár érdemes belegondolni, hogy a támadók végül 1.5 millió beteg adataival, a nekik felírt gyógyszerek listájával távoztak, és ezek az adatok kétségtelenül értékesebbek, mint a miniszterelnök egyébként is ismert betegségéről szóló adatok.

U.S. Airforce

Bizony, az amerikai légierő is igen kellemetlen adatszivárgási ügybe keveredett júliusban. A támadó az egyik tiszt számítógépéhez fért hozzá, amelyről katonai terveket, kézikönyveket, adatokat, többek között a MQ-9A Reaper csapásmérő drón üzemeltetési és karbantartási oktatóanyagait vitte el.

(Az a jó az ilyen anyagokban, hogy elsőre nem feltétlenül tűnnek veszélyesnek, de ahogy a kutatók rámutattak, ezekben az anyagokban olyan iformációk is vannak, amelyek az adott eszközök gyengeségeivel foglalkoznak, szóval rossz kezekben sajnos ezek az adatok is veszélyessé válnak)

Külön kellemetlen, hogy egy sérülékeny Netgear routeren keresztül fért hozzá a támadó a számítógéphez, csak remélni tudom, hogy a tiszt otthoni hálózatáról van szó, bár az sem csökkenti az eset súlyát túlzottan.

A Recorded Future kutatócég talált rá az adatokra, amelyeket a hacker eladásra kínált fel a DarNet-en. A kutatók később megerősítették az adatok hitelességét, és sikerült a hackerrel is kapcsolatba lépni, innen származik a Netgear-re vonatkozó információ.

Summer in the City

Lehetne még sorolni az eseteket, de szerintem a fentiekből is látszik, hogy az idei nyár nem csak időjárás szempontjából volt forró. Rengeteg breach-ről nem is tudunk, nem kapnak nagy nyilvánosságot, holott elképesztő adatokról vagy érintettszámról lehet szó.

Ki hallott már a Taringáról (28 millió rekord) vagy az acquirehealth.com-ról (31 millió rekord)? Százas nagyságrendű weboldal és szolgáltatás kompromittálódik havonta, amelyekről vagy semmit, vagy csak nagyon keveset tudunk.

Ez a nyár biztosan nem úgy vonul be az IT biztonság történelmébe (bár a történelmet a győztesek írják, szóval kérdés, hogy ki lesz aki írja?), mint a nyugodt pihenés időszaka. És még csak most jön az ősz és az év vége, jó lesz felkészülni!

A tavalyi, 2017-es egészen jó év volt ha a kiszivárgott adatok mennyiségét nézzük. Legalábbis az idei augusztushoz képest bizonyosan.

A kezembe került az IT Governance által kiadott infógrafika, amely összefoglalja a 2017-es esztendőt adatszivárgási szempontból: 488 észlelt adatszivárgási eseményből 826,526,181 (Nemzeti Alaptanterven nevelkedettek számára 826 millió) adatrekord szivárgott ki.

Nem is akármilyen adatszivárgások voltak ezek: 146 eseményben egészségügyi, 33 eseményben a financiális szektor, 67 eseményben technológiai szektor volt érintett. Érdekesség, hogy 64 eseményben valamilyen oktatási szolgáltatással kapcsolatos adatok kerültek ki, és a listában a telkó és a védelmi ipar is képviselteti magát 8, illetve 3 „szerény” eseménnyel.

Szép év volt, de vajon hogy állhatunk most? A kibertér óceánján, a GDPR paradicsomi boldogságában vajon merre tart velünk a Harland and Wolff gyárában szerelt, rekeszes törzsű „elsüllyeszthetetlen” hajó?

Nézzük az elmúlt hónapokat:

Összesen tehát most, 2018 verőfényes szeptemberének elején 621 millió adatrekordnál járunk, amelyet valamilyen adatszivárgással kapcsolatos incidens érintett.

Nem rossz, 2017-ben összesen 826 millió, idén pedig eddig 621 millió rekord volt érintett - és még hátravan 4 hónap az évből.  Mondhatni, majdnem arányosan rosszul állunk, és ezen a június-július-augusztus sem segített, pedig ugye már a GDPR paradicsomában vagyunk.

Brutális ezeket a számokat látni. 2017-ben 5 olyan hónap is volt amikor legalább 50 millió rekord kompromittálódott, és 2018-ban már 4 ilyen hónappal is megvagyunk.  

Na és a GDPR?

Egy másik szemüveget felvéve azt lehet mondani, hogy az összefoglaló alapján jól látható (de csak ezzel a szemüveggel), hogy miért van szükség az adatvédelemre és miért van szükség a GDPR-ra, még akkor is, ha a GDPR erőfeszítései nem az idei év statisztikájában fognak jelentős javulást hozni.

A 2017-es évben közel 58 millió rekord biztonsági problémák miatt kompromittálódott, míg majdnem 8 millió rekord valamiféle hibás beállítás miatt került rossz kezekbe. 274 millió rekord bizalmassága sérült valamilyen belső, hibás folyamat miatt, 4.5 millió rekordot pedig egyszerűen csak elhagytak.

Azt gondolom, hogy a GDPR és a farvizén megvalósított műszaki védelmi intézkedések csökkenteni fogják ezeket a számokat, de abban is biztos vagyok, hogy nem idén, és talán nem is jövőre.  

De valaminek meg kell változnia, mert a Harland and Wolff gyárában szerelt, rekeszes törzsű „elsüllyeszthetetlen” hajón (talán már kitaláltátok, a Titanicról van szó) Frederic Fleet őrszem 23:40-kor meghúzta a vészharangot.

UPDATE: a Veeam szeptemberi 445 millió rekordos breach-ével lenyomtuk a 2017-et, tehát idén szeptemberig már túlteljesítettük a 2017-es évet :)

A „Schrödinger macskája” gondolatkísérlet elég régóta foglalkoztatja az embereket és főleg a tudós elméket, akiknek egyébként nincs jobb dolguk, mint ilyesmiken gondolkodni.

A kísérlet nagyon egyszerűen arról szól, hogy egy képzeletbeli dobozba zárt macska atombomlás-indikálta cianidmérgezés következtében élő vagy hol állapotban létezik, avagy a macska egyszerre élő és holt mindaddig, amíg valaki ki nem nyitja a dobozt és ezzel eldől, mely állapotában létezik a macska a dobozban.

Évek óta szórakoztató mémek tucatjai jelentek meg már az elméletről és a híres macskáról, de én nem tudok arról, hogy az esetet a macska szempontjából bárki is vizsgálta volna. Pedig kellene, hiszen a macska szempontjából áttekintve a dolgot a helyzet összetettebb és sokkal több teljesen felesleges gondolkozásra tudja sarkallni az unatkozó tudós elmét.

A macska szempontjából ugyanis Schrödinger létbeli állapota négy dologtól függ:

• Ha a macska saját maga mászott a dobozba (a macskák valamiért nagyon vonzódnak a zacskókba és dobozokba bújáshoz), Schrödinger bár a macska számára a következő etetésig teljes mértékben érdektelen, így Schrödinger a macska számára egyszerre lehet élő és halott.
• Amennyiben Schrödinger saját kezűleg erőltette a macskát a dobozba, akkor Schrödinger a macska számára HALOTT.
• Ha a dobozba cián helyett szaftos macskatáp kerül, a macska számára Schrödinger ismét érdektelen, és a doboz kinyitása után a macska számára a következő etetésig egyszerre lehet élő vagy halott.
• (és természetesen, ha a macska halott, akkor a macska számára Schrödinger teljesen érdektelen, egyszerre lehet élő vagy halott, mert halott macska leszarja.)

Szóval lehet, hogy nem árt egy problémát vagy gondolatkísérletet más szempontok alapján is értelmezni.

A tanulság ebből az, hogy ha macskát zársz egy dobozba, a végén a hullámfüggvényed egyszerre fogja élő és halott valód hullámfüggvényét tartalmazni.

Hát megtörtént.

Alig 2 hónapja az EU parlament határozatban mondta ki, hogy a Kaspersky vírusvédelmi és végpontbiztonsági megoldása(i) szerinte potenciálisan veszélyesnek – pontosabban arról hozott határozatot, hogy az EU intézmények nézzék át az infrastruktúrájukat és távolítsák el a rosszindulatú, veszélyes alkalmazásokat, mint pl. a Kaspersy Lab („such as Kaspersky Lab”).

Tegnap (08.13) csendben megjelent egy magyar kormányhatározat, amely a Kormány irányítása és felügyelete alá tartozó szervek és vállalkozások esetében már a Kaspersy megoldások kiszűrését és elhárítását írja elő.

Nem akarok belemenni abba, hogy mi állhat az Amerikából elindult, és a Kaspersky-t bedaráló döntések hátterében (egyesek tényleg orosz kémeket és az FSZB-t látják a termékben, mások a Kaspersy piaci részesedésének megszerzését említik), de annyi bizonyos, hogy ezzel Magyarországon (is) vége a Kaspersky-nek. Lehet, hogy otthoni vagy kisvállalati verziókban még egy ideig meg-megjelenik, de vállalati és kormányzati szinten innentől kezdve a Kaspersky használata tilos.

Ami valakinek keserű, az másnak bizony édes: alig várom, hogy elinduljanak a pl. „Cseréld a Kaspersky-t Minden Ellen Védő Sárga Vírusgyilkosra” reklámkampányok.

Nyugodj békében Kaspersky!

Local Admin occidere nolite timere bonum est si omnes consentiunt ego non contradico, azaz “a lokáladmint megölni nem kell félnetek jó lesz ha mindenki egyetért én nem ellenzem” - mondhatta volna a kétértelműség hazai apostola Merániai János érsek, ha II. András idejében királynő helyett a lokális adminisztrátor keserítette volna meg a magyarok életét.

A felhasználókhoz delegált lokális adminisztrátori jogosultság ugyanúgy kihozza a sodrából az egyszeri szekuritist, ahogy II. András idejében Bánk Bánt bőszítette fel a neje megbecstelenítése: a lokális adminisztrátori privilégium a szépen kidolgozott jogosultsági rendszer inzultálása, amire egy vérbeli szekuritis minimum megszurkálná azt, aki kitalálta, hogy a felhasználónak legyen ilyen privilégiuma.

A lokális adminisztrátori jogosultság egy saját magára fogott töltött fegyver a felhasználó kezében, kibiztosítva. Az első, akit a felhasználó el fog találni, az saját maga lesz, aztán meg lehet a utána takarítani.

A lokális adminisztrátori jogosultság ugyanis tökéletesen képes bármilyen műszaki intézkedés védelmi értékét a nullára degradálni: a privilégium bírtokában bármely (a legtöbb) műszaki védelmi intézkedés megkerülhető, kikapcsolható, vagy működésében korlátozható.

Egy másik, és nem elhanyagolható probléma, hogy a (lokális) adminisztrátori jogosultsággal futtatott alkalmazások eleve veszélyesek: a malware és exploit szeretettcsomagok tipikusan örülnek az ilyesminek, hiszen az alkalmazásból kitörve már nem is kell privilégiumot emelniük, a legtöbb esetben eleve admin joggal tudnak futni.

Nyilván, ha valaki a felhasználói tevékenységét eleve admin jogkörrel végzi, a nevében és jogosultságával elinduló alkalmazások (akár malware kódok) is eleve adminisztrátori jogosultsággal fognak futni. Az admin joggal futó malwarek aztán nagyon csúnya munkát tudnak végezni, gyakorlatilag nem csak az adott munkaállomást kompromittálják, de a teljes hálózatra is potenciális veszélyt jelentenek.

Ezért alap, hogy egy normálisan menedzselt hálózatban a lokális adminisztrátori jogosultság coki!

Illetve...

Hát igen. Sajnos mindig vannak kivételek.

Nem csak az ügyvezető, manager, kisfőnök, nagyfőnök – ezeket még egy rátermettebb biztonságis csak-csak el tudja tántorítani a jogosultságtól, nade...a fejlesztők...a devopsok...a rendszergazdák...a tudj isten kicsodák nagy hanggal és sajnos jogos igénnyel!

Pl. egy fejlesztő esetében roppant nehéz megoldani, hogy el tudja a munkáját végezni admin jog nélkül. Sajnos sok esetben naponta 58 komponenst telepítenek, törölnek, állítanak, fordítanak, stb. – szóval ha nincs lokál admin joguk, a munkavégzésük fog meghiúsulni.

Persze vannak alternatív lehetőségek, hogy a fejlesztőket mondjuk nem engedjük fel az éles hálózatra, karanténozzuk őket, akár két munkaállomásuk van, stb. – de ezt egyre nehezebb megtenni, és sok esetben ez sem fog megoldást jelenteni.

Aztán ott vannak a kisebb szervezetek, ahol az sem működőképes, hogy a 20-30 felhasználó alkalmazás-telepítési igényeit azonnal kiszolgálja az outsource rendszergazda, a felhasználók meg sok mindent nem szeretnek, de várni aztán biztosan nem.

Auditorként nagyon sok esetben találkozom ezzel a problémával, tele van a cég permanens lokális (rosszabb esetben domain) adminokkal, és a rendszergazda meg a biztonságis legfeljebb a vállukat tudják megvonni: - Tudjuk, de nem vonhatjuk meg a jogosultságot, mert akkor nem tudnak dolgozni.

A felhasználó adminisztrátori jogosultságának problémákra jelent jó megoldást az AdminByRequest.

AdminByRequest

A cucc röviden arra alkalmas, hogy egy felhasználó meg tudja igényelni a kiemelt privilégiumot, amely egy időablakban ítélődik oda neki, majd automatikusan, az időablak végén visszavonásra kerül.

Tehát ha Gyula szeretne egy alkalmazást telepíteni, amelynek elvégzéséhez admin privilégiumra van szüksége, Gyula meg tudja igényelni a jogosultságot 30 percre, el tudja végezni a tevékenységét, majd a jogosultsága automatikusan visszavonásra kerül. A felhasználónak nem kell permanens adminisztrátori jogosultsággal rendelkeznie, hiszen csak a telepítés (vagy más tevékenység) idejére van szükség a jogosultságra, azt és arra az időre pedig megkapja, ha megigényli.

Gyula megigényli a jogosultságot

Az adminisztrátor email értesítést kap az igénylésről, majd a menedzsment felületen jóváhagyja az igénylést

Gyula megkapta a jogosultságot, most már bármilyen kiemelt privilégiumú tevékenységet el tud végezni, ha a Windows bekéri az admin felhasználót és jelszót, a saját felhasználó nevével és jelszavával el tudja végezni a tevékenységet. 30 perc után a jogosultság visszavonásra kerül. 

Arra is van lehetőség, hogy egyes alkalmazásokhoz meg se kelljen igényelnie a jogosultságot, az alkalmazás elindításakor az már adminisztrátori jogosultsággal fog elindulni.

A rendszer működéséhez egy agent programot kell a munkaállomásokra telepíteni, a szabályrendszerek és logok a megoldás cloud-alapú menedzsment felületében találhatóak, és állíthatók be.

(Aki nem szereti a cloud megoldásokat, van olyan termék, amely onprem működésű és közel ugyanezt tudja).

A rendszer lehetőséget biztosít scoped policy kialakítására, azaz mindenkire érvényes egy alapértelmezett szabályrendszer, de felhasználói csoportonként akár eltérő szabályrendszerek is kialakíthatóak. Pl. a felhasználók jelentős részénél egy humán személynek (már amennyire egy rendszergazda ma még humánnak minősöl) jóvá kell hagyni az igénylést, de pl. egy kiemelt felhasználó esetében a jogosultságigényléshez nem kell a rendszergazdai jóváhagyás, ha megigényli, automatikusan meg is kapja az admin jogot.

A rendszer minden jogosultság-igénylést lenaplóz, és még azt is megmutatja, hogy mit csinált és mit telepített fel vagy indított el a felhasználó, amíg birtokolta a kiemelt privilégiumot.

A felhasználó ezeket a programokat indította el kiemelt privilégiummal

Ha a felhasználó éppen nem rendelkezik Internet kapcsolattal, és nem tudja megigényelni a jogosultságot (mert pl. az agent nem éri el a cloud menedzsment felületet), akkor is van lehetőség kiemelt jogot biztosítani a szerencsétlen usernek, ehhez minden felhasználóhoz egy napig érvényes PIN-kódot biztosít a rendszer. Azaz, ha a user legalább a rendszergazdát fel tudja hívni, az meg tudja nézni az adott user napi PIN-kódját, amelyet lediktálhat a felhasználónak, így az egy napig offline is megigényelheti a kiemelt privilégiumot.

Összefoglalás

Az AdminByRequest igen jól és egyszerűen használható megoldás, amely megszüntetheti a felhasználói permanens adminisztrátori jogosultságokból adódó kockázatokat. Nem kell állandóan admin jogosultság a felhasználóknak, csak akkor kapják meg a privilégiumot ha szükségük van rá, megígénylik és ha valaki jóvá is hagyja (vagy akár automatikusan jóváhagyódik).

Még arra is gondoltak, hogy egyes rafinált userek az ideiglenes jogosultságból megpróbálhatnak állandó jogosultságot csinálni, azaz az admin joggal hozzáadnák magukat a lokális adminisztrátori csoporthoz. Nyilván ezt megtiltani nem lehet, de az agent a munkaállomás következő újraindításakor kitakarítja az adminisztrátori csoportot, azaz ha a trükkös felhasználó újra indítja a gépét, az általa felvett felhasználó már nem lesz lokális adminisztrátor.

Az AdminByRequest egészen megfizethető árú cucc, érdemes kipróbálni és eljátszogatni vele. Akit a cloud menedzsment riasztana, annak a Basic Byte Access Director Enterprise lehet, hogy jobban fog tetszeni, talán  drágább megoldás, de teljesen onprem.

Nemrég belefutottam a filter:max Kft. egyik ATO-val kapcsolatos anyagába, amely az Account Takeover-elleni védekezés tévhiteit veszi sorba. Meg is örültem az anyagnak, igaz, hogy fordították a SpyCloud doksijából, de alapjaiban egészen jól összefoglalják a dolgot.

Van néhány szempont, amely nem kapott hangsúlyt (vagy promó anyagként más hangsúlyt kapott), vagy pedig meg sem említették a cikkben, viszont szerintem érdemes róla beszélni.

Account Takeover (ATO)

Több helyen credential stuffing vagy credential breach néven hivatkoznak rá, gyakorlatilag arról van szó, hogy a támadó valamilyen módon (jellemzően valamilyen alkalmazás, szolgáltatás meghekkelésével megszerzi a felhasználói adatbázist) hozzájut egy vagy több felhasználó jelszavához, és a megszerzett jelszóval további visszaéléseket követhet el.

Ha cégről, szervezetről beszélünk (és korrekt definíciót akarunk), akkor az ATO a Szervezethez kapcsolódó, a Szervezet felhasználói által igénybe vett belső és/vagy külső szolgáltatások hozzáféréseinek kompromittálódását jelenti. Az ATO incidens során egy vagy több, külső vagy belső rendszerhez hozzáférő felhasználó bejelentkezési azonosítója és jelszava illetéktelen kézbe jut, bizalmassága súlyosan sérül.

A kétfaktor nem jó védelem?

A filter:max cikkében az szerepel, hogy „1. tévhit: a többfaktoros hitelesítés mindent megold, ha ATO-ról van szó” – és egy kissé elferdítve, a cím azt sugallja, hogy a kétfaktoros hitelesítés nem jó megoldás, hiszen:

• Kevesen használják
• Probléma lehet az SMS vagy más kódok bevitelével (WTF??)
• A nyilvános profilokból összerakhatók a biztonsági kérdések (WTF2?)

Nekem az a véleményem, hogy a kétfaktor mindenképpen jó és hatékony védelemnek számít.

A filter:max-nak abban tökéletesen igaza van abban, hogy kevesen használják – nade attól, hogy kevesen használják a biztonsági övet, attól a biztonsági öv még kiváló védelmi intézkedés. Nyilván, ha mindenki és mindenhol kétfaktoros hitelesítést használna, az esetlegesen megszerzett jelszót nem lehetne felhasználni.

Vagy mégis?

Hopp, hát, de. A napokban indult el megint egy jó zsaroló kampány, ahol a zsaroló levél hitelesítéséhez pont kiszivárgott jelszavakat használnak.

Szóval sajnos a kétfaktor lehet hogy a lopott jelszóval történő bejelentkezést megakadályozza, de a jelszóval való egyéb visszaélést nem.

Jelszókezelők használata

„2. tévhit: Ha jelszókezelő rendszert használsz, nyugodtan hatra dőlhetsz” – emeli ki a filter:max második tévhitként a jelszókezelők használatát.

Nem is akarok foglalkozni azzal, hogy miért tartja a filter:max tévhitnek a dolgot, inkább azt hiányolom, hogy az az egyszerű tény nem szerepel az összefoglalásban, hogy hiába tárolja a random generált jelszót jelszókezelőben a felhasználó, és hiába használ minden alkalmazásban eltérő jelszavakat – ha pl a támadó egy sérülékeny webes alkalmazásból szerezi meg a jelszavakat.

Ebben az esetben az fog megvalósulni, hogy a random generált es 29 karakter hosszú „biztonságos” jelszót a felhasználó nem tudja (miért is tudná, azért van jelszókezelő, hogy az tudja), ellenben a támadó tudja, hiszen megszerezte, ott van nála.

Nyilván ennek a megoldása nem a felhasználó oldalán, hanem a webes alkalmazás gazdájánál és fejlesztőjénél van: neki kell megfelelően tárolnia a jelszavakat, és nyilván meg kellene akadályozni, hogy a támadó elvigye a felhasználói adatbázist.

Egy másik ablak ugyanerre a térre, sajnos hiába van jelszókezelő és hiába kerül bele a böngészőbe automatikusan a jelszókezelőből a jelszó, ha a gépen olyan malware működik, amelynek a célja a jelszó- és más, hasznos adatok ellopása (pl Azorult Botnet, Cred/Info Stealer, stb.). Sajnos ezek a malwarek nicsenek tekintettel a jelszókezelőre, adatként el fogják vinni az autopastolt, POST-olt jelszót.

Scraping vs HUMINT

Az ötödik pont „5. tévhit: Deep & Dark webes szkennerek gyorsan felfedezik a visszaéléseket” a kedvencem. Való igaz, hogy ATO esetében a lopott hozzáférések publikálása és eladása általában nem az első lépés.  

A lopott adatok először csak egy nagyon szűk körben kerülnek felhasználásra, nyilvánvaló, hogy csak a „tej lefölözése” után kerülnek ki ezek az adatok a nagyobb nyilvánosságra és piacterekre. Az automata szkennerek és crawlerek már csak akkor férnek hozzá ezekhez az adatokhoz, ha azokat kipakolják a nagyobb nyilvánosság elé (még mindig a DarkNet fórumairól beszélünk).

A jobb ATO-megoldások azért a „favágó” automata scraper robotok mellett HUMINT műveleteket is végeznek, megpróbálnak beépülni az egyes szűkkörű csoportokba és közösségekbe, hiszen ha ott megszerzik a lopott adatokat mielőtt az még a nyilvános piactéren landol, akkor képesek értesíteni az érintett áldozatokat.

Biztonságtudatosság

Az utolsó ponttal „6. tévhit: Ha van vállalati policy, akkor már jók vagyun ATO szempontból” kapcsolatban is igazat kell adnom a filter:max cikkének. Személyes tapasztalat, hogy ezzel a területtel igen kevés cégnél foglalkoznak megfelelően.

Sajnos, hiába írják le a szabályzatokba, hogy tilos vállalati címmel külső szolgáltatásokba regisztrálni, és tilos olyan jelszóval regisztrálni, amelyet a felhasználó belül is használ, ez nem több, mint egy reménytelen próbálkozás.

20-25 ATO vizsgálat után ki merem jelenteni, hogy a felhasználónak ez mit sem számít: ha regisztrálni akar a randi oldalra, akkor regisztrálni fog a randi oldalra. Es a céges email címével fogja megtenni.

Mitől is tartana? Jobb esetben ez ki sem derül. És ha mégis? Akkor sem lesz belőle semmi.

Nyilván nem csak a felhasználóval van a baj.

Ha a szervezet nem érteti (tanítja) meg a felhasználókkal az egyes védelmi intézkedések értelmét és célját (biztonságtudatosság), akkor nemigazán várhatja el, hogy az intézkedést betartsák. A képzés, fejlesztés, oktatás a legolcsóbb és leghatékonyabb védelmi intézkedés!

A másik oldal, hogy a szervezetek az ATO problémának csak a „password reuse” kockázatát látják, a többivel egyáltalán nem foglalkoznak (nagyon helytelenül egyébként, mivel az ATO számos egyéb kockázatot is jelent, nem utolsó sorban, hogy a kiszivárgott adatok mind a személyes adatok köréhez tartoznak).

Szóval alapjában véve érdemes a filter:max cikkét elolvasni a témával kapcsolatban,   még akkor is, ha csak a felszínt karcolgatja az anyag, és hát kissé marketing ízű :)