Adatbányászat rosszul konfigurált adatbázis szerverekből

A Veeam 400 millió rekordos adatszivárgása megint rámutatott arra, hogy néha olyan helyről jön az „áldás”, amelyre nem is gondolunk, pontosabban: nem tudjuk, hogy esetleg hosszabb ideje, időzített bombaként ott „ketyeg” a rendszereinkben valami, amiből ömlik kifelé az adat, amelyet annyira meg akarunk védeni.

A Veeam esetében egy technikai probléma elhárítása okozta a problémát, a hibakereséshez véletlenül kinyitották a Mongo adatbázis szervert, amely így autentikáció nélkül hozzáférhető lett, majd a hibakeresés végén elfelejtették bezárni a szervert és úgy is maradt egészen addig, amíg egy kutató meg nem találta. 445 millió rekord volt a szerverben, igaz, a Veeam később 4.5 millióra becsülte a kiszivárgott, egyedi rekordok számát.

Pár hete a hasonszőrű Elasticsearch adatbázisok (hazai) elérhetőségét nézegettem meg.

Nyilván nincs nagy meglepetés abban, hogy elég elkeserítő eredményre jut az ember ilyen keresésekkel kapcsolatban, viszont a jó hír, hogy a megfelelő értesítés után az üzemeltetők megköszönve az értesítést, szépen becsukogatták a szervereket. Sajnos azonban ez olyan, mint a hidra: az első kör óta újabb nyitott szerverek jelentek meg, szóval kezdődik minden előröl.

Nem csak információszivárgás a kockázat

Az Elasticsearch publikus hozzáférése nem csak azért okozhat problémát, mert hozzáférhetőek a tárolt adatok.

Sajnos a tavalyi évben nagyon sok olyan eset történt, ahol a támadók elkriptálták a nyitott Elasticsearch adatbázisok indexét (vagy az adatokat), ugyanúgy, ahogy korábban a nyitott MongoDB adatbázisok esetén is megtörtént.

crypt.png

Ilyen esetben a kriptált adatokhoz természetesen csak Bitcoinért cserébe lehet hozzájutni, vagy pedig vissza lehet állítani mentésből az adatokat (már, ha volt).

Nyitva van az aranykapu csak bújjatok rajta....

Sok példát lehetne felhozni a hazai, nyitott Elasticsearc adatbázisokkal kapcsolatban, de talán a legjobb példa arra, hogy mindenkit érhet baleset, az XXXXXXX, egyébként romániai telkó-leány, akik a nálunk működő AeroHive Wi-Fi kontrollerük adatbázisát nyitották ki sikeresen és felejtették úgy.

hive-b4.png

hive-b3.png

Bár az adatbázisban „csak” logok tárolódtak, azt tudni kell, hogy egy jó Wi-Fi kontroller mindent lelogol, amit csak lehet: felhasználókat, néha jelszavakat, eszközöket, IP címeket, konfiguráció-változásokat, adminokat, roaming infókat, stb.

hive-b1.png

A logokból és audit eseményekből a rendszer teljes működése (és persze konfigurációja) feltérképezhető, mellette persze szépen legyűjthetők a felhasználók és eszközeik, valamint a felhasználók mozgása az AP-k között, valamint az egyes épületekben.

hive-b2.png

Persze ez csak egy példa a sok közül, de talán jól szemlélteti, hogy a nyitva hagyott adatbázisok nem csak akkor okozhatnak problémát, ha konkrétan több gigányi felhasználói adatot lehet lehúzni belőlük, de akkor is, az adatbázis valamilyen hálózati eszközhöz tartozik.

A magyar érintettek között sokféle terület megtalálható, gyógyszertár, webshop, videótár, étteremkalauz, munkaerő közvetítő, stb.

Szerencsére a legtöbben már fixálták a problémát az értesítés után, érdekes, hogy több esetben is „csak” a fejlesztői vagy teszt rendszerek maradtak nyitva (illetve kriptálódtak el), ami viszont rámutat arra, hogy bizony ezeket a nem „éles” rendszereket akkor sem kezelik megfelelően, ha egyébként éles adatokat tartalmaznak.

- Mi az előnye a szofisztikált fejlesztésnek és annak, hogy külön vannak választva az éles, teszt és fejlesztői rendszerek?

- Hogy legalább három helyről lopható el ugyanaz az adat!