A vizsgálat paraméterei

• Időtartam: 2025.07.18. – 2025.07.30.
• Összes vizsgált domain: 770.000
• Script futási ideje: ~12 nap

A cél az volt, hogy képet kapjunk arról, hány domain „él” ténylegesen, mennyire jól konfiguráltak, és hogyan állnak a biztonság szempontjából alapvető HTTPS beállítások.

Az eredmények röviden

• Teljes tartomány: 770.000 domain
• Nem elérhető, nem működik, parkoltatott: ~110.000
• Papíron működik: ~660.000

Na de mit jelent az, hogy „működik”? Itt jön a lényeg:

• Betölt HTTP-ként: 241.000
• Átirányít biztonságosra (HTTPS): 367.000
• A maradék: különböző hibák, timeout, üres válasz stb.

És most a két legfontosabb tanulság:

1. HTTPS-re való átirányítás hiánya
   Az a 241.000 domain, amelyik betölt, nagyon nagy arányban nem irányít át biztonságos (HTTPS) kapcsolatra. Pedig ez ma már alapvető elvárás – és technikailag nem bonyolult megoldani.
2. Átirányítok, de… hibára visz
   A 367.000 átirányított domain között kb. 14.000 olyan van, ahol a céloldal nem működik. Vagyis a látogatókat hibás oldalra irányítják. Ez nemcsak felhasználói élmény szempontjából problémás, hanem SEO és biztonsági kockázatot is jelent.

Mit jelent ez a gyakorlatban?

• A magyar webes jelenlét egy része technikailag elavult vagy hiányos.
• A HTTPS beállítása 2025-ben már nem kérdés – ez az alap.
• Az átirányításokat nem elég beállítani, ellenőrizni is kell, hogy valóban működik-e a céloldal.

Miért fontos mindez?

• Biztonság: A HTTPS nem csupán „szép zöld lakat” a böngészőben, hanem védi a felhasználói adatokat.
• SEO: A keresőmotorok hátrébb sorolják a nem biztonságos oldalakat.
• Hitelesség: Egy rosszul beállított oldal vagy hibás átirányítás bizalomvesztést okoz.

Záró gondolat

A vizsgálat azt mutatta, hogy még bőven van hova fejlődni. A jó hír: ezek a problémák gyorsan és olcsón javíthatók. Egy tudatos webmester néhány lépésben sokat tehet a biztonságért és a látogatók bizalmáért.

Ha van weboldalad, ellenőrizd most:

• Van érvényes SSL-tanúsítványod?
• Minden forgalmat átirányítasz HTTPS-re?
• Az átirányítás a megfelelő oldalra vezet?

Ha nem, itt az ideje lépni – a felhasználóid és az üzleted érdekében.

A Teljes .hu tartomány vizsgálata: 241.000 oldal figyelmen kívül hagyja az alapbiztonságot bejegyzés először AntiHack.hu-én jelent meg.

Aki egy kicsit is jártas volt a webes biztonság világában, és volt hozzáférése néhány domainhez (vagy épp sokhoz), az könnyen összerakhatott magának egy folyamatosan megújuló Burp Pro hozzáférést. Én személy szerint kb. „X darab” különböző domainre kértem próbaverziót – és mindig működött.

A játék vége

A módszer annyira kézenfekvő volt, hogy idővel szinte már túl jól működött. Nem csoda, hogy a Burp Pro-t fejlesztő cég a PortSwigger idővel szigorított a rendszeren. Ma már csak ténylegesen létező IT cégek kaphatják meg a próbaverziót – és ha tippelnem kellene, még mindig számít a domain, csak épp már alaposabb háttérellenőrzés is történik.

A legjobb rész? Ők tanítottak meg rá.

A legnagyobb irónia? Hogy ezt a logikát – vagyis a rendszer működésének üzleti oldalú kijátszását – éppen a PortSwigger tanította meg nekem a saját Business Logic Vulnerabilities (Üzleti Logikai Sérülékenységek) labor gyakorlataiban. Ott tanultuk meg felismerni, hogyan lehet egy rendszerrel „korrektül” viselkedve, de a logikáját megkerülve elérni valamit, amit valójában nem akartak engedélyezni.

Tehát gyakorlatilag ők tanították meg, hogyan használjunk ki egy ilyen regisztrációs rendszert. Én pedig alkalmaztam az elvet.

Mit tanulhatunk belőle?

Ez az egész egy jó példa arra, hogy:

• Egy technológiailag jól összerakott rendszer is lehet sérülékeny a logikai hibákra.
• A domain-alapú hitelesítés önmagában semmit nem garantál.
• A valódi korlátozást nem csak technikai eszközök, hanem üzleti szabályok (és azok következetes ellenőrzése) biztosítják.

És végül: mindig legyünk tisztában vele, mit tanítunk, mert a hallgatóink lehet, hogy túl jól megértik a leckét.

A A biztonsági cég tanított meg kiskaput keresni… aztán én találtam egyet náluk bejegyzés először AntiHack.hu-én jelent meg.

1. Első lépés: Mi a cél?

Először is tisztázni kell, hogy pontosan mire van szükség. Egy egyszerű bemutatkozó oldal, egy blog, egy webshop vagy egyedi funkcionalitásokkal ellátott rendszer? A weboldal típusa meghatározza, milyen technológiát érdemes használni.

2. CMS, webshop vagy egyedi fejlesztés?

• CMS (Tartalomkezelő rendszer): Ha dinamikus tartalmakat szeretnénk kezelni, egy CMS, mint a WordPress vagy a Joomla, jó választás lehet. Azonban ezeknél mindig fennáll a biztonsági kockázat, ha nem frissítjük időben a rendszert és a plugineket.
• Webshop: Ha termékeket akarunk értékesíteni, a WooCommerce (WordPress alapú), Magento vagy Shopify lehet opció. A webshopok különösen érzékenyek a biztonsági hibákra, mivel pénzügyi tranzakciók folynak rajtuk.
• Egyedi weboldal: Ha speciális funkciókra van szükség, vagy kiemelten fontos a sebesség és biztonság, egy egyedi fejlesztésű weboldal lehet a legjobb megoldás.

3. Ha WordPress-t választunk…

A WordPress világszerte népszerű, de egyben a leggyakrabban célponttá váló CMS is. Ezért, ha WordPress-t használunk, gondoskodni kell:

• Rendszeres frissítésről: A WordPress mag, a bővítények és a sablonok frissítése kulcsfontosságú.
• Megbízható bővítényekről: Csak hivatalos forrásból származó, rendszeresen karbantartott plugineket érdemes használni.
• Erős jelszavakról: Az admin jelszó ne legyen „admin123”! Használjunk hosszú, komplex jelszavakat.
• Biztonsági mentésről: Mindig legyen friss backup, hogy egy esetleges támadás után gyorsan helyre lehessen állítani az oldalt.

4. Egyedi fejlesztés esetén

Ha egyedi weboldalt szeretnénk, fontos, hogy a fejlesztő biztonságos kódolási gyakorlatokat alkalmazzon.

• SQL injekció és XSS ellenőrzés: A bemenetek ellenőrzése elengedhetetlen.
• HTTPS: Az SSL tanúsítvány nem csak biztonsági, hanem SEO szempontból is fontos.
• Minimalizált kód: A felesleges kód és pluginek csökkentik a biztonságot.

5. Ki véd meg minket?

Bármilyen megoldást is választunk, nem érdemes egyedül hagyni a weboldalunkat.

• Rendszeres karbantartás: Egy szakember vagy csapat folyamatosan figyelje a frissítéseket, a lehetséges sebezhetőségeket.
• Biztonsági auditok: Időnként érdemes pár független tesztet futtatni, hogy biztosan minden renden van-e.
• Megfelelő tárhelyszolgáltató: Olyan szolgáltatót válasszunk, amely komolyan veszi a biztonságot, tüzfalakat és behatolásvédelmi rendszereket használ.

Záró gondolat

Egy weboldal nemcsak egy online névjegykártya, hanem egy komoly felelősség is. Ha biztonságos alapokat akarunk, akkor nem elég egy jól megtervezett dizájn, hanem folyamatos figyelmet és karbantartást igényel. A következő részben a leggyakoribb weboldal sebezhetőségekről lesz szó – és arról, hogyan kerüljük el őket!

A A weboldalak biztonsága 1. rész: Avagy hogyan csináltassunk biztonságos weboldalt? bejegyzés először AntiHack.hu-én jelent meg.

Egy kisebb vállalkozás (KKV) biztonsági megerősítése volt a célunk, és abból kellett kihoznunk a legtöbbet, ami épp rendelkezésre állt. Egyértelmű volt, hogy az alapvető biztonsági beállítások rendben vannak: a router megfelelően konfigurálva, a jelszavak erősek, és az összes szoftver naprakész. De ez még nem elég.

A támadók nem alszanak

Ahogy haladtunk előre a védelem megerősítésében, észrevettük, hogy valami nincs rendben. A router naplófájljait átnézve kiderült, hogy rendszeresen próbálkoznak külső IP-k a rendszer elérésével. És nem barátságos IP-k voltak, hanem olyanok, amelyek gyanús tevékenységeikről híresek.

Itt jött képbe az AbuseIPDB, ami egy közösségi adatbázis a rosszindulatú IP-címekről. Összevetettük az észlelt IP-ket az adatbázisukkal, és hamar kiderült, hogy bizony nem véletlen próbálkoztak ezek a címek.

Gyanús IP-k, amiket találtunk:

• 103.102.230.2
• 103.102.230.3
• 103.102.230.4
• 103.102.230.5
• 103.102.230.6

Ezeket az IP-ket a rendszerünk folyamatosan blokkolta, és ahogy egyre többet tiltottunk le, úgy csökkent a gyanús próbálkozások száma. De persze felmerült a kérdés: kik ezek?

Az Abuseipdb ezt mutatja:

Kik állhatnak a támadások mögött?

Amikor egy sorozatban érkező IP-k ennyire aktívan próbálkoznak (85.000 bejelentés volt erre a a bizonyos IP-re), akkor két lehetőség van:

1. Egy feltört szolgáltató – lehet, hogy egy cég infrastruktúráját törték fel, és most azt használják támadásokra.
2. Egy szervezett bűnözői csoport – olyan támadók, akiknek megvannak a saját kis „játszótereik” és rendszeresen automatizált botneteket használnak.

Ami biztos: egyik verzió sem jó hír.

Mit tanultunk ebből?

A védekezés nem csak annyi, hogy „legyen egy tűzfalunk” és „használjunk erős jelszavakat”. A hálózati forgalom monitorozása, a gyanús IP-k kiszűrése és a proaktív védekezés kulcsfontosságú. Ha ezt nem tettük volna meg, akkor talán a következő lépés az lett volna, hogy egy nap arra ébred a cég, hogy valaki feltörte a rendszerüket.

Amit minden vállalkozás megtehet:

Használj egy megbízható tűzfalat és állítsd be megfelelően.
Figyeld a bejövő forgalmat – ha gyanús IP-k próbálkoznak, az nem véletlen.
Használj olyan szolgáltatásokat, mint az AbuseIPDB, hogy időben felismerd a veszélyt.
Gondolj a védelemre előre, ne csak akkor, amikor már baj van.

A kiberbűnözők nem alszanak. De ha a Blue Team is éber, akkor nincs könnyű dolguk.

A Blue Team Akcióban: Hogyan Erősítettük Meg Egy KKV Védelmét? bejegyzés először AntiHack.hu-én jelent meg.

A Red Team a támadók szerepét játssza. Ők azok a biztonsági szakértők, akik szimulált támadásokat hajtanak végre a rendszer ellen. A céljuk, hogy megtalálják a gyenge pontokat, és bebizonyítsák, hogy egy valós támadó hogyan tudná azokat kihasználni. Gyakorlatilag „etikus hackerek”, akik segítenek felkészülni a valódi fenyegetésekre.

Ezzel szemben a Blue Team a védelmet képviseli. Ők felelősek a hálózatok, rendszerek és adatok biztonságáért. Feladatuk a támadások megelőzése, észlelése és elhárítása. Monitoring rendszereket használnak, incidenseket vizsgálnak, és gondoskodnak a megfelelő biztonsági konfigurációkról.

A Purple Team a kettő között helyezkedik el. Ők összehangolják a red és blue team munkáját, hogy a támadási és védekezési stratégiák együtt fejlődjenek. Ahelyett, hogy egymás ellen dolgoznának, közösen elemzik a támadási technikákat és a védekezési módszereket, így hatékonyabb biztonsági megoldásokat hoznak létre.

Összefoglalva: a red team támad, a blue team védekezik, a purple team pedig összeköti a kettőt a hatékonyabb védelem érdekében. Ezek a csapatok együtt dolgozva segítenek a szervezeteknek felkészülni a valós kiberfenyegetésekre.

A Blue, Red és Purple Team – Mi a különbség? bejegyzés először AntiHack.hu-én jelent meg.

A 10 tipp hogyan legyen biztonságos a WordPress-es weboldalad bejegyzés először AntiHack.hu-én jelent meg.

Egy iráni fickó megnézi az e-mailjeit. Beírja a böngészőjébe a gmail.com címet, és megnyomja az Entert. Egy furcsa figyelmeztetés jelenik meg. Azt írja, hogy érvénytelen szervertanúsítvány. Nem tud belépni a Gmailbe. Csatlakozik egy VPN-hez, és újra megpróbálja. A VPN-en keresztül rendben van a kapcsolat. Úgy gondolja, hogy valami furcsa dolog történhetett. Feltesz egy kérdést a Google fórumán, hogy lehetséges-e egy man-in-the-middle támadás. Azt is mondja, hogy gyanítja, hogy az internetszolgáltatója vagy az iráni kormány valami gyanúsat csinál. A Google nem csak a fórumbejegyzésre reagált, hanem biztonsági figyelmeztetést tett közzé a világ számára, és egy vészhelyzeti javítást adott ki a Chrome böngészőjéhez. A Mozilla, a Microsoft és az Apple gyorsan követte hasonló biztonsági frissítésekkel. Valójában egy man-in-the-middle támadás történt a Gmail felhasználók ellen; egy olyan támadás, amely aláásta az összes böngésző biztonságát, egy olyan támadás, amely pusztító következményekkel járt.

JACK (INTRO): Ez a Darknet Diaries, igaz történetek az internet sötét oldaláról. Jack Rhysider vagyok.

JACK: A HTTPS, az SSL és a TLS mind olyan technológiák, amelyek biztosítják a világhálót. Mindegyik a tanúsítványokra támaszkodik, amelyek egyfajta azonosító kártyát jelentenek a weboldalak számára. A tanúsítványokat kiállító vállalatokat tanúsítványkiadó hatóságoknak vagy CA-knak nevezik. A hitelesítésszolgáltatók és a tanúsítványok fogalma annyira bonyolult, hogy majd valaki más elmagyarázza.

GERVASE: A nevem Gervase Markham, és az elmúlt körülbelül tizenkét évben részt vettem a Mozilla Certificate Authority Root programjában. A tanúsító hatóság alapvetően egy olyan személy, aki ellenőrzi a személyazonosságot, és akiben megbízunk, hogy ellenőrizze a személyazonosságot. Az ellenőrzés szintje a tanúsítvány típusától függ. Lehet, hogy csak azt ellenőrzik, hogy az a személy, aki azt állítja, hogy a foo.com domain tulajdonosa, valóban a foo.com domain tulajdonosa. Azt is mondhatják, hogy egyébként ez a Foo Corporation of 116 Acacia Avenue, Birmingham, UK, és ez a telefonszámuk, ez a vállalati hivatkozási számuk és hasonlók. Lehet, hogy mindezeket a dolgokat ellenőrzi, de bizonyos szintű információt ellenőriz. A hitelesítésszolgáltató elsődleges célja az, hogy amikor beírja a foo.com címet a böngészőjébe, és a kérés elindul az interneten keresztül, amelyet a hálózat különböző részeit ellenőrző ellenséges vagy rosszindulatú emberek bármelyike benépesíthet, a visszakapott adatok a) valóban a foo.com-tól származnak, és b) nem manipulálták őket, vagy nem tekinthetők meg útközben. A tanúsítványrendszer alapvetően a web biztonságos kapcsolódási képességének alapja.

JACK: Az olyan webböngészők, mint a Firefox, tartalmazzák a megbízható hitelesítésszolgáltatók belső listáját, és tartalmazzák az ellenőrzéshez használt gyökértanúsítványok listáját. Amikor meglátogat egy webhelyet, az egy tanúsítványt mutat be, amely azonosítja a webhely tartományát. A tanúsítványban az is szerepel, hogy melyik hitelesítésszolgáltató ellenőrizte és igazolta ezt az információt. A böngésző ezután ellenőrzi, hogy a hitelesítésszolgáltató megbízható-e. A böngésző tartalmazza az összes megbízható hitelesítésszolgáltató és gyökértanúsítvány listáját. A Firefox például rendelkezik…

GERVASE: 64 szervezet és 159 tanúsítvány.

JACK: A megbízható szervezetek ezen listáját gyökértárolónak nevezzük. Amikor egy vállalat úgy dönt, hogy tanúsítványkiadó hatósággá akar válni, együtt kell működnie a böngészőkkel, hogy felvegyék a gyökértárba. Ha nem kerülnek hozzá, a böngészők nem fognak megbízni ezekben a webhelyekben.

GERVASE: Négy nagy gyökérraktár van. Van mi, van a Microsoft, van az Apple és van a Google. A hitelesítésszolgáltatók felvételére vonatkozó kritériumaink között szerepelnek majd bizonyos ellenőrzések, amelyek azt próbálják bizonyítani, hogy a hitelesítésszolgáltató a vonatkozó biztonsági irányelveknek megfelelően jár el. Az auditorok bejönnek és ellenőrzik ezt, és ezeket az auditokat sok különböző gyökérprogramnak tudják majd bemutatni.

JACK: Gervase és csapata felelős annak eldöntéséért, hogy mely hitelesítésszolgáltatók megbízhatóak és melyek nem. Ez egy rendkívül fontos feladat. Ő olyan, mint az internet biztonsági őre, aki vigyáz mindenkire, aki a Firefoxot használja, és gondoskodik arról, hogy a megbízható listán szereplő szervezetek biztonságosak legyenek a világ számára. Gondolj bele, ha a Firefoxot használod, akkor megbízol abban, hogy ez az ember, Gervase Markham tudja, mely szervezetek megbízhatóak.

JACK: Gervase úgy véli, hogy az ilyen jellegű döntéshozatalt a nyilvánosság előtt is meg kellene nyitni, hogy láthassák a döntéshozatali folyamatot, és akár bele is szólhassanak a döntés meghozatalába. Ezt érti azon, hogy a gyökérprogramja nyílt és átlátható, mert ahogyan azt el lehet képzelni, nehéz feladat eldönteni, hogy mely hitelesítésszolgáltatók megbízhatóak.

GERVASE: A bizalom egy szerves dolog, igaz. A bizalom nem olyasvalami, ami egy jelölőnégyzet végére érve jön létre. Ha olvasunk egy újságcikket, amelyben például az áll, hogy a kazahsztáni kormány azt fontolgatja, hogy minden állampolgárát manipulálja, és aztán kapunk egy kérelmet a kazahsztáni kormánytól, hogy a böngészőnkben használhassuk a gyökértanúsítványukat, még ha minden papírmunka meg is van, akkor is vonakodhatunk attól, hogy a gyökértanúsítványt a böngészőnkhöz adjuk, mert külső információkkal rendelkezünk arról, hogy a kormány mire akarja használni a tanúsítványt. Felmerül a kérelmező szervezet hírnevének kérdése is. Ez nem egy egyszerű ellenőrző lista, de megpróbálunk olyan kritériumokat felállítani, amelyek legalábbis homályosan objektívek, hogy a hitelesítésszolgáltatók tudják, mit kell tenniük ahhoz, hogy felvegyék őket a listára.

JACK: De van néhány probléma ezzel az egész megközelítéssel a gyökértárolók és a hitelesítésszolgáltatók használatával kapcsolatban. A biztonsági kutatók még mindig próbálnak jobb megoldásokat találni erre a problémára. Az egyik probléma…

GERVASE: A tanúsítványrendszerben a leggyengébb láncszem problémája volt. Vagyis, ha 64 különböző szervezetben bízol, és az egyiknek a biztonsága gyenge, akkor gond van. Nem számít, hogy az adott webhely a másik 63 közül az egyiket használja-e, mert a támadó szerezhet egy tanúsítványt a gyengébbtől, és utána megszemélyesítheti magát.

JACK: Vagyis, ha az egyik 64 szervezetet feltörik, az tönkreteszi az összes többi hitelesítésszolgáltató bizalmát. Alapvetően a hacker ekkor kerülne fel a megbízható tanúsítványok listájára. A hitelesítésszolgáltatók biztonságának csúcsminőségűnek és áthatolhatatlannak kell lennie. A Comodo a világ egyik legnagyobb hitelesítésszolgáltatója. Világszerte több millió weboldal számára állítanak ki tanúsítványokat, és 2011 elején feltörték őket. [A hacker kilenc hamis tanúsítványt állított ki, de a Comodo ezt azonnal észlelte, és visszavonta a tanúsítványokat. Néhány nappal később a Comodo kijavította a problémákat, és nyilvánosan bejelentette, hogy betörés történt, de néhány nappal ezután egy második betörés történt. Ezúttal azonban a hacker nem járt sikerrel. Minden próbálkozás kudarcot vallott. [A hacker be tudott jutni a hálózatba, de ennél többet nem tudott tenni. Nem tudtak tanúsítványokat kiállítani, vagy bármi jelentőset tenni.

Aztán egy furcsa poszt jelenik meg a Pastebinon. A Pastebin egy olyan weboldal, ahol bárki névtelenül közzétehet egy üzenetet. Ezt az üzenetet egy Comodo Hacker nevű személy írta, és így szól: „Hello. Ezt írom az egész világnak, hogy többet tudjatok rólunk, de először szeretnék néhány pontot adni, hogy biztosak lehessetek benne, hogy én vagyok a hacker. Meghekkeltem a Comodo-t az azonnali SSL-ből. A Comodo felhasználónevük/jelszavuk GT admin és globális bizalom volt. Én nem vagyok egy csoport. Egyetlen hacker vagyok 1000 hacker tapasztalatával.” Idézet vége. Az üzenet tovább magyarázza, hogyan jutott be és mit csinált. A legvégén perzsául írja: „Feláldozom a lelkem a vezetőmért”. Öt nappal később a Comodo bejelenti a második behatolást, de megemlíti, hogy a hacker nem tudott mit tenni, és kijavították a lyukakat a hálózatukon. Összességében a Comodo elég jól kezelte ezt az ügyet. Gyorsan észlelték és kijavították a problémát, és értesítették a nyilvánosságot. A Comodo nem az egyetlen hitelesítésszolgáltató. Egy másik népszerű a DigiNotar. Ez egy holland székhelyű vállalat, és 1998-ban kezdték meg közjegyzői hitelesítésekkel kapcsolatos tevékenységüket Hollandiában. Végül tekintélyes hitelesítésszolgáltatóvá váltak. Valójában a holland kormány a DigiNotart használta hitelesítésszolgáltatóként számos weboldalához. 2011 elején a VASCO majdnem 13 millió dollárért megvásárolta a DigiNotart.

JOSEPHINE: A DigiNotar szerintem egy olyan eset, amely valóban sokat fektetett a biztonságba, ahogyan azt egy tanúsítványkiadó hatóságnak tennie is kell.

Ő Josephine Wolff.

JOSEPHINE: A Rochester Institute of Technology Közpolitikai és Számítástechnikai Biztonsági Tanszékének adjunktusa vagyok.

JACK: Nemrégiben publikált egy cikket és egy palacsintát a DigiNotarral kapcsolatban.

JOSEPHINE: A hálózatot csak ezekkel a szegmensekkel állították fel, a nyilvános, a külső hálóval, a DNZ belsővel, majd a több réteggel azon túl, de fizikai ellenőrzéseket is tartottak. Ha egyszer bejutottál a hálózat legbiztonságosabb részébe, ha aztán ténylegesen hozzá akartál férni a tanúsítványok kiállítására használt gyártási szerverekhez, akkor el kellett jutnod ezekhez a számítógépekhez, amelyeket egy olyan szobában tároltak, ami egy James Bond-filmből való. Kétféle ajtó van, van egy kézfelismerő eszköz és egy PIN-kód, és be kell helyeznie egy elektronikus kulcskártyát, hogy ténylegesen megkezdődhessen a tanúsítványkiadási folyamat. Több biztonsági szintet is át kell lépni ahhoz, hogy tanúsítványt lehessen kiállítani.

JACK: A DigiNotar tudta, hogy a biztonság létfontosságú a vállalat hírneve szempontjából, ezért nagy összegeket fektetett be saját biztonságába. Néha szeretek úgy gondolni egy hálózat biztosítására, mint egy tízezer ajtóval és ablakkal rendelkező kastély biztosítására. Még ha időt is szánunk arra, hogy minden ajtót és ablakot ellenőrizzünk, hogy biztosan zárva van-e, előfordulhat, hogy egyet kihagytunk, vagy nem is tudunk róla, és idővel biztosan elkövetünk egy hibát, és nyitva hagyunk egy ajtót. Talán mert lusta voltál vagy szórakozott, de az emberek hibáznak. 2011 nyarán a DigiNotar is elkövetett egy ilyen hibát, és egy hacker behatolt a hálózatukba.

A betörés azzal kezdődik, hogy az elkövető ténylegesen csatlakozik a DigiNotar által üzemeltetett, nyilvános webszerverekhez. Ez egy kicsit elavult. Van néhány javítás, amit nem frissítettek a tartalomkezelő szoftverben. Az elkövető csatlakozik a webszerverekhez, kihasználja az elavult sebezhetőségeket, és ezeket a sebezhetőségeket arra használja, hogy a tűzfalszabályok hihetetlenül kiterjedt rendszerén keresztül bejusson a hálózatuk elvileg legbiztonságosabb silójába.

JACK: A hacker végül eljutott a tanúsítványokat kiállító szerverre, de a DigiNotar biztonsági ellenőrzést vezetett be, amely szerint a tanúsítvány kiállításához egy fizikai kulcskártyának kellett a számítógépben lennie.

JOSEPHINE: Kiderült, hogy van egy kulcskártya, amit állandóan bent hagynak. Nem csak lustaságból, hanem azért, mert a DigiNotar képes akar lenni automatikusan létrehozni úgynevezett tanúsítvány-visszavonási listákat. Minden alkalommal, amikor egy tanúsítvány megbízhatatlanná válik, vagy elavul, vagy valamilyen okból visszavonásra kerül, a DigiNotar automatikus listákat akar kiállítani ezekről a tanúsítványokról, hogy az összes böngésző, amely megbízik a DigiNotar tanúsítványaiban, ne bízzon többé az adott tanúsítványokban. Ahhoz, hogy ezeket a listákat ki lehessen állítani, be kell helyezni az egyik ilyen kártyát a teremben lévő biztonságos szerverek egyikébe, és mivel a kártyát csak úgy otthagyják, kiderül, hogy a biztonsági rétegek, amelyek túlzásnak tűnnek, megkerülhetők. A behatoló képes egy csomó hamis tanúsítványt kiállítani a legkülönbözőbb tartományok nevében. A legnagyobb, ami felbukkan, a Google.com tanúsítványok, de azt hiszem, a cia.gov tanúsítványokat is kiállították, és még sok-sok másikat.

JACK: Ezekkel a tanúsítványokkal a hacker mostantól Google-vé válhat. Be tudják csapni a böngészőt, hogy azt higgye, ők a google.com. Ez azért van, mert a DigiNotar volt az egyik megbízható hitelesítésszolgáltató a böngészőben. Ez a betörés 2011. július 10-én történt, és végül 531 hamis tanúsítványt állított ki. Kilenc nappal később a DigiNotar észlelte a betörést, de nem jelentette be nyilvánosan. Több mint egy hónappal később jelent meg a Google fórumbejegyzése arról az iráni emberről, aki nem tudott hozzáférni a gmail.com-hoz.

JOSEPHINE: Az iráni embereket, akik megpróbáltak csatlakozni a Gmail fiókjukhoz, átirányították, ami egy rossz weboldalra irányította őket, ami valószínűleg pontosan úgy néz ki, mint az igazi Gmail. Mivel ezek a DigiNotar által kiállított hamis tanúsítványokat kapták, azok, akik ezt a hamis Gmail vagy Google weboldalt létrehozták, képesek aláírni azt, és úgy néz ki, mintha valóban a Google oldala lenne. De mivel rendelkeznek ezzel a hamisított tanúsítvánnyal, képesek erre, az emberek a Google-oldalnak hitt oldalakra mennek, és megadják a hitelesítő adataikat. Gyanítjuk, hogy ezeket a hitelesítő adatokat arra használják, hogy különböző módon kémkedjenek a Google-fiókjaik után.

JACK: A hacker ezután fogta ezeket a tanúsítványokat, és egy man-in-the-middle támadást hajtott végre. Ez az, amikor a hacker elfogja a forgalmat, amelynek máshová kellene mennie. A hamis tanúsítványok csak a fele annak, ami egy man-in-the-middle támadáshoz szükséges. A hackernek át kell irányítania az embereket a saját szerverére a Google valódi szerverei helyett. Nem tudjuk pontosan, hogyan csinálta ezt, de a legjobb elmélet, amelyet a legtöbb tény támaszt alá, az, hogy DNS-mérgezéses támadást hajtott végre. A DNS-kiszolgáló lefordítja a google.com-hoz hasonló tartományt egy IP-címre, hogy a routerek megtalálják, hova kell menniük. Átverte az iráni DNS-kiszolgálókat, hogy aki a google.com címet keresi, azt az ő IP-címére irányítsák át.

JOSEPHINE: Nincs egyértelmű bizonyíték arra, hogy így történt az átirányítás. Vannak közvetett bizonyítékok, amelyekkel megpróbálhatja ezt az ügyet alátámasztani. Lehetséges, hogy van egy iráni internetszolgáltató, amely vagy bűnrészes, vagy kompromittálódott, és ezért átirányítja a forgalmat ezekre a csalárd oldalakra. Egy másik lehetőség, hogy egy nagyon magas szintű DNS-kiszolgálót kompromittáltak, és a hamis rekordokat továbbítja a többi DNS-kiszolgálónak, amelyek a hierarchiában erre támaszkodnak. A nyomozók a bizonyítékok alapján úgy érzik, hogy valószínűleg nem erről van szó, mert ha megnézik, hogy hány embert irányítanak át, és hogy mikor, akkor ez nagyon ritka. Azaz, nagy kiugrást látunk a hamis oldalra küldött emberek számában, majd az leáll, és újra kiugrik, ami arra enged következtetni, hogy valószínűleg nem nagymértékű mérgezésről van szó. Valószínűleg néhány helyi DNS-kiszolgálót elárasztanak olyan üzenetekkel, amelyek úgy néznek ki, mintha magas szintű, megbízható DNS-kiszolgálóktól érkeznének, de valójában a támadóktól származnak, akik azt mondják, hogy itt van a google.com helyes, frissített DNS-rekordja. Ez csak egy bizonyos ideig fog tartani, mert utána a DNS-kiszolgáló megkapja a helyes rekordot a magasabb szintű DNS-kiszolgálótól, így újra a megfelelő oldalra fogja küldeni az embereket. A támadónak vissza kell jönnie, és újra meg kell mérgeznie.

JACK: Iránból több mint 300 000 ember látogatta meg a gazember szervert. Úgy tűnt, hogy ez a támadás iráni civileket célzott meg. Ez a támadás egy ideig észrevétlen maradt volna, de a Google-nek volt egy okos módja a felderítésére.

JOSEPHINE: Mivel a Google által gyártott Chrome böngészőn belül csinálják ezt, és mivel a Google tulajdonában van a Chrome böngésző, amely ellenőrzi ezeket a tanúsítványokat, és a Google tulajdonában van a weboldal, amelyet imitálásra használnak, a böngésző észreveszi. Ez egy olyan tanúsítvány, amely egy megbízható tanúsító hatóságtól származik, igaz, a Chrome megbízik a DigiNotar által kiállított tanúsítványokban, de tudjuk, hogy ez nem a megfelelő tanúsítvány, mert tudjuk, hogy mik a Google tanúsítványaink. Ez nem tartozik közéjük.
JACK: Ezért volt a fickónak a Google fórumokon szervertanúsítvány hibája. Gervase a Firefoxnál volt a frontvonalban.

GERVASE: A Google arról értesített minket, hogy egy tévesen kiállított tanúsítványt észleltek a starter, google.com számára, amelyet aktív támadásokban használtak az iráni felhasználók ellen. Megkezdtük a vizsgálatot. Gyakorlatilag azonnali válaszadást vállaltam, így nagyon elfoglalt voltam. A DigiNotar esetében a hálózatukba alaposan behatoltak, és ez már hónapok óta így volt. A naplóikban nagy volt a káosz. Az infrastruktúrájuk egy káosz volt. Nem lehetett megmondani, hogy milyen mértékű volt a behatolás, és ezért nem lehetett egy adott root-ra vagy egy csoport root-ra, vagy egy köztesre vagy egy csoport köztesre korlátozni. A katasztrofális biztonsági hibák miatt lehetetlen volt a DigiNotar rendszerei és szervezetei iránti bizalom bármilyen formáját fenntartani.

JACK: Amikor a Mozilla úgy döntött, hogy a DigiNotar már nem megbízható, eltávolította őket a gyökértárból, de a felhasználóknak frissíteniük kellett a böngészőjüket, hogy megkapják a Firefox azon verzióját, amely nem bízik a DigiNotarban. Az összes többi root store is eltávolította a DigiNotart a megbízható listáról. Közel két hónappal a behatolás után, és jóval azután, hogy Irán egy masszív man-in-the-middle támadás célpontja lett, a DigiNotar végül nyilvánosan elismerte, hogy behatoltak hozzájuk.

JOSEPHINE: A holland kormány közbelép, és átveszi a DigiNotar irányítását, ami példa nélküli a magáncégek elleni jogsértések történetében. Amint ez megtörtént, a vállalat nagyrészt kikerült a képből. A vezetőségük már nem hoz döntéseket a nyomozók felvételéről és minden másról.

JACK: A holland kormány a DigiNotart használta elsődleges hitelesítésszolgáltatóként számos kormányzati webhely és alkalmazás esetében. Amikor a böngészők elkezdték eltávolítani a DigiNotart a megbízható gyökértárból, a holland kormány számos rendszerét tönkretette. Felkeresték a gyökértárolókat, és kérték, hogy a DigiNotart helyezzék vissza a gyökértárolóba. A böngészők visszavették a DigiNotart megbízható hitelesítésszolgáltatóként, de a hamisított tanúsítványok problémájának megoldása érdekében a gyökértárak blokkoltak minden olyan tanúsítványt, amelyet a DigiNotar 2011 júliusa után állított ki. Ez lehetővé tette a holland kormány számára, hogy folytassa a munkát, és új hitelesítésszolgáltatót találjon. Végül a holland kormány új hitelesítésszolgáltatóhoz fordult, és a jogsértést követő három hónapon belül a DigiNotar véglegesen leállt.

JACK: A DigiNotar felbérelt egy Fox-IT nevű biztonsági céget, hogy vizsgálja ki, mi történt. Számos problémát találtak a DigiNotar hálózatában. Megállapították, hogy a Windows tartományi rendszergazdai fióknak egyszerű jelszava volt, és könnyen meg lehetett erőszakolni. Ezután az összes tanúsítványt kiállító szerver egyetlen tartományban volt. Ez azt jelenti, hogy egyetlen adminisztrátori fiók mind a nyolc tanúsítványszerverükhöz hozzáférhetett. Számos rendszerben nem volt jelen vírusirtó, ami megakadályozhatta volna a támadások egy részét. Nem volt központi naplózás és a kritikus rendszerek elkülönítése. Mindezen hibák kombinációja az, ahogyan a hacker képes volt kijátszani az összes biztonsági ellenőrzést. A Fox-IT átnézte a bizonyítékokat is, hogy megpróbálja kideríteni, ki követte el ezt a támadást.

JOSEPHINE: Nem tudjuk, ki tette ezt. Senkit sem kaptak el, és senkit sem vontak felelősségre ezért a betörésért.

JACK: Igaz, nem tudtuk megállapítani, hogy ki tette ezt, de amikor a Fox IT vizsgálta a betörést, találtak néhány érdekes nyomot. Először is megnézték az összes IP-címet, amelyet a hacker a hálózaton használt. Egy kivételével minden IP-t vissza tudtak vezetni egy proxyhoz. Ez az IP Iránból csatlakozott a DigiNotar hálózatához, és nem proxyból származott. Csak néhány másodpercre csatlakozott, majd megszakadt a kapcsolat. Ezután egy új kapcsolat jelent meg egy proxyról. Ez lehetett a hacker hibája, aki aztán nagyon gyorsan korrigálta magát. Ez az IP korábban a DigiNotart is meglátogatta, ami lehet, hogy felderítésre szolgált. A Fox-IT azt is megállapította, hogy a hacker üzenetet hagyott a feltört szerveren. Részben ez állt benne, idézem: „Nem létezik olyan hardver vagy szoftver a világon, amely meg tudná állítani a súlyos támadásaimat, az agyamat, a képességeimet, az akaratomat vagy a szakértelmemet”. A végén egy perzsa nyelvű üzenettel: „Feláldozom a lelkemet a vezetőmért”. Egy új Pastebin üzenetet is látunk attól a személytől, aki azt állította, hogy feltörte a Comodo CA-t. Ez a Comodo hacker most magára vállalja a DigiNotar feltörését is, és ugyanezzel a perzsa nyelvű üzenettel írja alá Pastebinjét. Azt is írja, hogy huszonegy éves és egyedül dolgozik.

JOSEPHINE: A DigiNotar és a holland kormány természetesen nagyon belekeveredik ebbe, mivel ők az eszköz, amelyen keresztül mindez történik, de a valódi célpont az iráni állampolgárok ellen irányuló kémkedés volt.

JACK: De ki akarja elolvasni az iráni állampolgárok e-mailjeit? Az USA-nak konfliktusai voltak Iránnal, így gyanús lehet. Bruce Schneier, egy neves biztonsági szakértő szerint lehet, hogy az NSA munkája vagy az NSA kihasználása, de szerinte elsősorban egy kiszivárgott NSA dokumentum miatt, amely szerint az NSA-nak hozzáférése volt a DigiNotarhoz. Ez az elmélet nem túl erős és szinte semmilyen más bizonyítékkal nem rendelkezik, akkor ki más célozná meg az iráni köznépet? Maga az iráni kormány. Ahhoz, hogy megértsük, miért, vissza kell tárcsáznunk két évvel a hack előtt. 2009-ben elnökválasztás volt Iránban. Mamoud Ahmadinezsád 63 százalékos szavazati aránnyal nyerte meg a választást, de erős ellenzék volt ellene. Sok iráni úgy vélte, hogy a szavazatokat manipulálták, és a választást megbundázták. Azonnal tüntetések kezdődtek. Ez megosztottságot teremtett az iráni emberek között. Egyesek rendkívül bizalmatlanok lettek a kormánnyal szemben, míg mások rendkívül lojálisak lettek. A rendőrség elkezdte letartóztatni a tüntetőket, és amikor a tüntetők nem távoztak, paprikaspray-vel, gumibotokkal ütötték őket, és néha lőttek rájuk.

A választást követő három hónapon belül hetvenkét tüntető halt meg. A korrupció annyira súlyos volt, hogy a rendőrség arra kényszerítette a családokat, hogy írják alá a papírokat, amelyek szerint halott rokonaik szívrohamban haltak meg, nem pedig rendőri brutalitás következtében. Képzelheti, hogy ez csak még nagyobb indulatokat szított az iráni emberek körében. Ezt követően az iráni kormány évekig keményen dolgozott azon, hogy minden kormányzati ellenzéket felszámoljon. Ez egészen addig folytatódott, amíg ez a DigiNotar-támadás meg nem történt. Erős az elmélet, hogy ezt a hackert maga az iráni kormány, vagy valaki, aki megpróbálta segíteni az iráni kormányt. Valószínűleg átnézték az e-maileket, hogy megtalálják a disszidenseket és azokat, akik elégedetlenek az iráni elnökkel. Ha megtalálták őket, akkor az emberek letartóztatásához, megkínzásához vagy megöléséhez vezethetett. Az igazoló hatóságok és a böngészőfejlesztők komoly tanulságokat vontak le a DigiNotarból. A hitelesítésszolgáltatóknak szigorúbb ellenőrzéseken kell megfelelniük ahhoz, hogy felvehessék őket a gyökértárakba. A nyilvános kulcsok rögzítését egyre gyakrabban használják. A Google ezt tette a Chrome böngészőjével, hogy észlelje ezt a jogsértést. Rákényszerítették a Chrome-ot, hogy csak a Google hitelesítésszolgáltatójától kiállított tanúsítványokat fogadjon el, lényegében egy adott hitelesítésszolgáltatóhoz rögzítve a tanúsítványt.

A DigiNotar óta ezt több weboldal is megtette, de ennek is megvannak a maga hiányosságai. Képzelje el például, milyen problémákat okozna egy weboldalnak, ha a tanúsítványát egy olyan hitelesítésszolgáltatóhoz kötné, amely megszűnt, vagy képzelje el, ha egy hacker egy hamis hitelesítésszolgáltatóhoz kötné a tanúsítványát. A tanúsítvány kitapasztásának feloldása jelenleg bonyolult feladat. A DigiNotar óta a Firefox egy új funkcióval bővült, amely segít a hamis tanúsítványok blokkolásában. Itt van Gervase, hogy meséljen nekünk erről.

GERVASE: Van egy OneCRL nevű rendszerünk, ami, ha úgy tetszik, egy vészhelyzeti visszavonási rendszer. A Firefoxok huszonnégy óránként ellenőrzik a tanúsítványokat ezen a fekete listán. Ha szükség van egy egyedi tanúsítvány, vagy akár egy teljes tanúsítványfa vészhelyzeti visszavonására egy közbenső tanúsítvány alapján, akkor azt feltehetjük a OneCRL-be, és huszonnégy órán belül minden Firefox, amelyik rendelkezik ezzel a rendszerrel – és már jó ideje használjuk -, nem bízik többé ezekben a tanúsítványokban. Nem szükséges frissítést telepíteni ahhoz, hogy ne bízzunk meg valamiben.

JACK: Amikor egy hackelésre kerül sor, akkor az világméretű. Megváltoztatja a biztonságot. Bizonyos értelemben a hackerek olyanok, mint az internet immunrendszere. Megfertőznek minket, megbetegszünk, meggyógyulunk, és utána még erősebbek leszünk. Még ma, hat évvel később is, amikor egy céggel történik egy nagyobb betörés, valaki mindig emlékeztet minket a DigiNotar sorsára.

JACK: Köszönjük Josephine Wolffnak, hogy mesélt nekünk a DigiNotarról, és egy nagy, túlzó köszönet Gervase Markhamnek, hogy eljött a podcastba, mert körülbelül egy évvel azután, hogy ez az epizód eredetileg adásba került, Gervase elhunyt. Huszonkét évesen rosszindulatú nyálmirigyrákot diagnosztizáltak nála, és miután tizennyolc évig küzdött ellene, negyvenévesen elhunyt. Gervase jelentősen hozzájárult a Firefox és a Bugzilla eszköz biztosításához. Neki köszönhetjük, hogy biztonságban tart minket ebben a bizonytalan világban. Hiányozni fogsz nekünk, Gervase. A zenét Ian Alex Mac és Kevin MacLeod szolgáltatja.

A #3 Darknet diaries: DigiNotar, Te vagy a leggyengébb láncszem, Viszlát! bejegyzés először AntiHack.hu-én jelent meg.

Az internet világában rengeteg olyan weboldal és alkalmazás létezik, amiket naponta használunk. De vajon mennyire vannak ezek biztonságban? Az OWASP (Open Web Application Security Project) egy non-profit szervezet, amely azért jött létre, hogy segítsen megvédeni ezeket az alkalmazásokat a kibertámadásoktól. Fontos a felhasználók számára, mert az általuk fejlesztett irányelvek biztosítják, hogy az online rendszereink biztonságosak maradjanak.

Miért érdemes odafigyelni az OWASP-ra?

A weboldalak és applikációk, amiket használunk – legyen az egy online bank, egy webshop vagy akár egy közösségi média oldal – folyamatos támadásoknak vannak kitéve. Az OWASP segít a fejlesztőknek és a cégeknek megérteni, hogyan védhetik meg ezeket a rendszereket a leggyakoribb támadások ellen. Így amikor például banki adatokat vagy személyes információkat osztunk meg egy weboldalon, nagyobb esély van rá, hogy azok nem kerülnek rossz kezekbe.

Mi az OWASP célja?

Az OWASP célja, hogy mindenki számára elérhető és érthető biztonsági megoldásokat nyújtson. Publikálnak útmutatókat, eszközöket és listákat, amikkel a fejlesztők biztonságosabbá tehetik az alkalmazásokat. Az egyik legismertebb projektjük az OWASP Top 10, amely a leggyakoribb webes biztonsági problémákat sorolja fel, például az adatlopásokat és hacker támadásokat.

Mi az OWASP Top 10?

Az OWASP Top 10 egy olyan lista, amely összefoglalja a legveszélyesebb online biztonsági hibákat. Ezek olyan problémák, amiket a támadók rendszeresen kihasználnak, és amelyekkel szinte bárki találkozhat. Például:

• Adatszivárgás: Olyan hiba, amikor a felhasználók érzékeny információi – mint jelszavak, bankkártyaadatok – kikerülnek a netre.
• Hitelesítési hibák: Ezek akkor fordulnak elő, amikor egy weboldal nem tudja helyesen ellenőrizni, hogy ki használja a fiókot.

Ezek a problémák nagy veszélyt jelentenek, ha nem kezelik őket megfelelően.

Miért számít ez neked?

Bár nem mindenki fejlesztő vagy biztonsági szakember, az OWASP munkája minden internetező életére hatással van. Ha a weboldalak és alkalmazások, amiket használsz, az OWASP irányelvei szerint készülnek, akkor nagyobb biztonságban vagy. Például egy biztonságosan felépített webshopon sokkal kisebb az esélye, hogy a fizetési adataid ellopják.

Hogyan segít az OWASP téged?

Az OWASP nem csak a fejlesztőknek segít, hanem közvetetten neked is. Azáltal, hogy jobb biztonsági eszközöket és irányelveket ad a cégek kezébe, te biztonságosabban böngészhetsz és vásárolhatsz az interneten. Ha egy weboldal figyelembe veszi az OWASP ajánlásait, az segít elkerülni a különféle adatlopásokat és vírusokat.

Záró gondolat

Az OWASP egy olyan globális szervezet, amely segít abban, hogy biztonságosabb legyen az internet. Legyen szó a banki fiókodról, egy online játékos profilodról vagy az e-mail fiókodról, az OWASP célja, hogy ezeket az értékes digitális információkat megvédje a támadóktól. Így amikor legközelebb egy online szolgáltatást használsz, remélhetőleg kicsit jobban érzed magad, tudva, hogy mögötte ott lehet az OWASP által megteremtett biztonság.

A Mi az az OWASP? bejegyzés először AntiHack.hu-én jelent meg.

2015. december 15., kedd van, és letartóztattak egy gyanúsítottat a VTech gyerekjátékok feltörésének ügyében. A brit rendőrség néhány órával ezelőtt bilincset csapott egy 21 éves férfira a hackerügyben folyó nyomozás részeként. Becslések szerint közel 6,5 millió gyerekprofil és közel ötmillió felnőtt fiók került veszélybe az évek óta talán a leggátlástalanabbul címlapokra kerülő hackelés során. Hitelkártyaadatokhoz nem jutottak hozzá, de a gyerekek neveihez és címeihez állítólag hozzáfértek, ami amellett, hogy a VTech-et megalázó, egyszerűen csak hátborzongató. A gyanúsítottat még nem nevezték meg, de valami azt súgja, hogy a rácsok mögött töltött következő napjai valószínűleg nem lesznek túl kellemesek. Boldog ünnepeket, szemétláda.

JACK: Ez itt a Darknet Diaries, igaz történetek az internet sötét oldaláról. Jack Rhysider vagyok.

JACK: A mai gyerekek látják, hogy a szüleik tabletet és telefont használnak, és ők is játszani akarnak. A játékgyártók megpróbálták ezt kihasználni azzal, hogy gyerekbarát tableteket és okosórákat kínálnak. Ezek a gyerekbarát készülékek ugyanúgy online vannak és csatlakoznak az internethez, mint bármely más tablet. Olyan funkciókkal rendelkeznek, amelyek lehetővé teszik, hogy a gyermek üzeneteket küldjön a tabletről a szülő telefonjára. De nem csak csevegéseket.

A gyerek képeket, videókat vagy hangfelvételeket is küldhet. A VTech az egyik gyártója az ilyen gyerekbarát eszközöknek. Olyan tableteket és telefonos alkalmazásokat készítenek, amelyeket kifejezetten gyerekeknek terveztek. A VTech táblagép vásárlásakor megkér, hogy regisztráld a készüléket. Kérik a szülő nevét és fizikai címét, valamint a felhasználónevet és a jelszót. Ezután a játéktabletta megkérdezi a gyermek nevét is, hogy fiú vagy lány, és hogy mi a születésnapja. Még azt is javasolja, hogy készítsen egy képet a gyermekről, amint a táblagépet használja a profil beállításához. Ez a regisztráció lehetővé teszi, hogy a szülő telefonja csatlakozzon a gyerek tabletjéhez. A VTech által létrehozott technológia, amely összekapcsolja a szülő telefonját a gyermek tabletjével, a Kid Connect nevet viseli. A VTech saját alkalmazásboltot is létrehozott The Learning Lodge néven, ahonnan a tabletjük segítségével alkalmazásokat, játékokat és könyveket tölthetnek le. Tippeljen, mi történik, ha a hackerek kezébe kerülnek ezek a játéktabletek.

A végén a határokig feszegetik a tableteket. Van egy fórum, amely a VTech táblagépek feltörésével foglalkozik. Az emberek mindenféle dolgot meg tudtak csinálni. Az egyik hacker szétszedte a készüléket, és egy forrasztópáka segítségével be tudott jutni a Linux operációs rendszerbe. Onnan a hackereknek sikerült root hozzáférést szerezniük. Aztán végül valaki megmutatta, hogy a kis játéktáblával a Doomot, azt a régi PC-s játékot a 90-es évekből, le tudta játszani. A hardveres hacker közösségben gyakran hallani, hogy ha nem tudod kinyitni, akkor nem is a tiéd. Ahogy a saját autódon is legálisan dolgozhatsz, úgy a saját elektronikádat is legálisan módosíthatod. Lehet, hogy érvényteleníti a garanciát, de nem illegális szétszedni és azt csinálni vele, amit csak akar. Ahogy ez a fórum egyre népszerűbb lett, végül másfajta hackereket vonzott. A hardveres hacker helyett ez a fickó hálózati hacker volt. Körbenézett, és rájött, hogy a táblagépek gyakran beszélnek egy planetvtech.com nevű weboldalhoz. Megnézte ezt a weboldalt, és szinte azonnal rájött, hogy sebezhető az SQL-injekcióval szemben.

Az SQL-injekciók az első számú kockázat, amellyel a weboldalaknak szembe kell nézniük. Kihasználja a gyenge kódot, és megpróbálja kihasználni a mögöttes adatbázist. Az ilyen hálózati hackerek gyakran már rengeteg olyan szkripttel és programmal vannak felszerelve, amelyek automatikusan végrehajtják a támadást. Puszta kíváncsiságból, néhány billentyűleütéssel ez a hacker lefuttatott egy szkriptet a planetvtech.com ellen, amely megpróbálta kihasználni az SQL-t. Meglepetésére működött. Shell hozzáférést kapott a weboldalhoz. Néhány billentyűleütéssel később már root hozzáférése volt. Azt mondta magának, idézem: „Szent szar. Van root hozzáférésem. Ez könnyű volt. Mit találhatok?” Idézet vége. Teljes hozzáférése volt a planetvtech.com weboldalhoz. 100 százalékos irányítással. Miután a hacker bejutott a webszerverre, körülnézett. Számos más szervert is látott a VTech hálózatán, köztük egy adatbázis-szervert. Képes volt beugrani az adatbázisba, és amikor ott körülnézett, megállapította, hogy az adatbázis hatalmas. A hacker mindenről másolatot készített az adatbázisban, letöltötte az egészet, majd továbbment egy másik adatbázisba, és ott is másolatot készített mindenről. A hacker ezután lecsatlakozott a VTech szervereiről.

Tudta, hogy bűncselekményt követett el, és idegesség hulláma söpört végig rajta. Ez a betörés 2015. november 16-a körül történt. A hacker egyformán csalódott és izgatott volt. Úgy gondolta, hogy túlságosan is könnyű volt bejutni a VTech hálózatába. Nagyon rövid idő alatt képes volt több adatbázisuk teljes tartalmát megszerezni. A VTech adatbázisának saját számítógépén lévő másolatával lassan át tudta nézni, hogy milyen adatokkal rendelkezik. Az első dolog, amit észrevett, egy „Szülő” nevű táblázat volt. A következő mezők voltak benne: Keresztnév, vezetéknév, e-mail cím, titkosított jelszó, titkos kérdés, titkos válasz, lakcím, IP-cím. Ahogy a hacker nézte, rájött, hogy ez a teljes felhasználói adatbázis mindenkinek, aki regisztrált az oldalon. Ebben a táblázatban 4,8 millió ember szerepelt. Nem hitt a szemének.

A 4,8 millió felhasználói fiókot tartalmazó lista forró téma lenne a sötét hálózaton. Egy ekkora lista tisztességes Bitcoin bevételre tehet szert, de a hackernek nem állt szándékában eladni az adatokat. A hacker még egyszer átnézte az adatbázist, és talált egy másik érdekes táblát, a Membert. Ez tartalmazta a gyerekek nevét, születésnapját, nemét és a szülők azonosítóját. A hacker rájött, hogy a két tábla kombinálásával egyértelműen azonosítani tudja, hogy mi a gyermek vezetékneve és hol lakik. Ez a táblázat 200 000 gyermek adatait tartalmazta. A születési dátumokat megnézve a gyermek átlagéletkora öt év volt. A hacker kikapcsolta a számítógépét, és sétálni ment, hogy átgondolja, mit tegyen. Sokkal inkább dühös volt, mint izgatott. Dühös volt, hogy a VTech ennyire hanyagul gondoskodott az oldaluk biztosításáról, és hogy ennyi gyermek személyes adataihoz ilyen könnyen hozzájutott. A hacker számára világossá vált, hogy rá kell vennie a VTech-et, hogy ismerje el, hogy biztonsági problémájuk van, és hogy orvosolja azt. A gyermekek személyes adatainak ilyen laza védelme elfogadhatatlan volt a hacker számára, ezért elkezdett azon gondolkodni, hogyan lehetne megoldani a problémát. Bemehetne, és maga is kijavíthatná, de ez nem tanítaná meg a VTech-et arra, hogyan tartsa biztonságban a jövőben. Gondolt arra, hogy megkeresi a VTech-et, de úgy gondolta, hogy soha nem hallgatnák meg, vagy megpróbálnák kijavítani a problémát, és letagadnák, hogy valaha is probléma volt. A hacker néhány napig gondolkodott azon, hogy mit tegyen.

Úgy döntött, hogy szól a médiának. Így a történet világszerte elterjedne, és a VTech-nek gyorsan meg kellene oldania a problémát. Úgy döntött, hogy megkeresi Lorenzo Franceschi-Bicchierai-t, a Vice’s Motherboard riporterét. A Motherboard egy olyan hírportál, amely kifejezetten a számítógépekkel kapcsolatos történetekkel foglalkozik, és Lorenzo sok igazán nagyszerű történetet hozott nyilvánosságra a jogsértésekről. Sok biztonsági riporter számos módot biztosít arra, hogy az emberek névtelenül elérjék őket, néha jelzésen keresztül, vagy PGP e-mailek, titkosított chat vagy más eszközök segítségével. A hacker biztonságosan kapcsolódott Lorenzóhoz, és kérte, hogy névtelen maradjon. Átadta Lorenzónak a 4,8 millió felhasználói adatot és a 200 000 gyermek adatát, és megkérte, hogy hozza nyilvánosságra a történetet. Egyértelműen közölte Lorenzóval, hogy ő egy etikus hacker, és nem áll szándékában ezeket az adatokat semmi rosszindulatú célra felhasználni. A hacker azt mondta Lorenzónak, idézem: „Adatbázis export adatokból profitálni nem szoktam, különösen akkor nem, ha gyerekekről van szó. Csak azt akarom, hogy a problémákra felhívják a figyelmet és kijavítsák azokat. Elég könnyű volt a dumpolás, így valaki sötétebb indítékkal könnyen megszerezhette. Őszintén szólva rosszul vagyok attól, hogy képes voltam megszerezni ezeket a dolgokat. A VTech-nek meg kellene kapnia a büntetést.

Lorenzóra hárult most az a teher, hogy kitalálja, mit tegyen. Először is megpróbálta megállapítani, hogy a hacker igazat mond-e, és hogy ezek az adatok újak és legálisak-e. A legrosszabb dolog, amit egy riporter tehet, hogy hamisan vádol valakit. Ez rágalmazás lenne. Ez tönkretenné a riporter hírnevét, ezért Lorenzo elküldte a dumpot Troy Huntnak, hogy ellenőrizze azt. Troy egy biztonsági kutató, aki leginkább a haveibeenpwned.com weboldal működtetéséről ismert. Troy annyi e-mail dumpot szerez meg, amennyit csak tud. Ezek olyan e-mail címek óriási listái, amelyeket biztonsági résekben látnak. A listát aztán nyilvános szolgáltatássá alakítja, hogy bárki megnézhesse a weboldalán, hogy az ő e-mail címe is része volt-e a jogsértésnek. Elsőre azt gondolhatod, hogy egy ilyen oldal egy adathalász átverés, és néhányan azok is, de Troy bebizonyította, hogy etikus és legális. Ő és a honlapja megbízható. Több mint négymilliárd e-mail cím van az adatbázisában, amelyet az összes nyilvános jogsértésből gyűjtött össze. Troy vetett egy pillantást erre a Lorenzo által küldött új dumpra. Úgy találta, hogy a jelszó mező nem volt titkosítva az adatbázisban, ahogyan azt állította.

Ehelyett a jelszavakat egy egyszerű, sótlan MD5-ös hash segítségével tárolták. Anélkül, hogy túlságosan részleteznénk, mi is az az MD5, csak annyit kell tudni, hogy rossz biztonsági gyakorlat a jelszavakat így tárolni. Néhány MD5-ös hash egyszerűen megkeresheti a Google-ban a jelszót. Vannak olyan szuper számítógépek, amelyek képesek az MD5 hash-értéket brutális erővel és viszonylag gyorsan feltörni. A jelszavak MD5-ös hash-ként való tárolása súlyos biztonsági hiányosság. Troy először megdöbbent ezen. Ezután felment a weboldalra, hogy megnézze, hogyan néz ki. Azonnal észrevette, hogy az oldal sehol nem használ HTTPS-t, sem a hitelesítéshez, sem az API-hoz, semmihez. Azt is észrevette, hogy a webhely ASP 2.0-t használ, amelyet a Microsoft már több mint négy éve nem támogatott. Azt is észrevette, hogy a weboldal egyes részei több információt szivárogtatnak ki, mint kellene, és meglepő eredményekkel hibákat küldenek vissza. Egy sikertelen bejelentkezési üzenet valójában a bejelentkezéshez használt SQL-lekérdezést mutatta. Troy-t sokkolták azok az adatok, amelyeket egyszerűen a webhely használatával tudott összegyűjteni, és még csak meg sem próbálta feltörni azt.

Troy számára a dump átment a „szimatpróbán”, de a közel ötmillió felhasználói rekordnál segítséget kért, hogy ellenőrizze, hogy a tartalom legális-e. Troy Have I Been Pwned? weboldala hatalmas sikert aratott, és egy további szolgáltatást is kínált: nem csak azt tudta ellenőrizni, hogy az e-mail címe nem szerepelt-e a betörésben, hanem meg is adhatta neki az e-mail címét, és ő értesítette, ha a jövőben feltűnik a betörésben. Ekkorra Troynak már majdnem 300 000 feliratkozója volt erre az e-mail megfigyelő listára. Troy átnézte a feliratkozóit, és megpróbált olyanokat találni, akik szintén felbukkantak a VTech felhasználói adathalmazában. Valójában sok egyező e-mail címet talált, ezért felkereste ezeket az embereket. Megkérdezte, hogy van-e VTech-fiókjuk, és megkérdezte, hogy a lakcím és az internetszolgáltató pontos-e. A válaszok a következők voltak. „Igen, ez pontos. Tényleg regisztráltam a VTech-nél, hogy le tudjak tölteni kiegészítőket egy játék laptophoz”. „Igen, ez pontos. Ez egy régi cím. Annak idején annál az internetszolgáltatónál voltam, így tudom ellenőrizni az információt. Én is a VTech weboldalát használtam volna a lányom számára abban az időben.” „Igen, 2014-ben, miután megvásároltam a Cora Cubot a gyermekemnek, valóban beléptem a VTech Learning Lodge oldalára. Ahhoz, hogy személyre szabhassa a hangvezérelt funkcióját, csatlakoznia kellett a The Learning Lodge-hoz.” Ezen a ponton Troy meg volt győződve arról, hogy a dump legális, és elmondta Lorenzónak, hogy mit talált.

JACK: Ekkorra Lorenzo már többször is megkereste a VTech-et. Lorenzo újra és újra nem kapott választ, vagy máshová irányították át. Végül napokkal később Lorenzo a következő választ kapta a VTech szóvivőjétől, Grace Pingtől. Idézet: „November 14-én egy illetéktelen fél hozzáfért a VTech ügyféladataihoz a Learning Lodge alkalmazásboltunk ügyféladatbázisában. Nem volt tudomásunk erről a jogosulatlan hozzáférésről, amíg Ön nem figyelmeztetett minket.” Idézet vége. A VTech azt állítja, hogy megkapták az e-mailt Lorenzótól, másnap bizonyítékot találtak a hackelésre, majd három nappal később sajtóközleményt adtak ki, és e-mailben értesítették ügyfeleiket. A kezdeti sajtóközleményük homályos és nem volt egyértelmű, hogy mit vittek el és kiket érintett. Azt is közölték, hogy a jelszavakat titkosították, de az MD5 hashing technikailag nem titkosítási módszer. A dátum sem stimmelt, mivel a dumpban szereplő adatokat két nappal azután jelölték meg időbélyegzővel, hogy közölték, hogy a jogsértés megtörtént.

A következő weboldalakat azonban leszedték: planetvtech.com, vsmilelink.com és sleepybearlullabytime.com. Ezeknek a weboldalaknak a leállítása nagy döntés lehetett a VTech számára. Képzelje el, hogy az alkalmazásbolt több mint egy hónapig nem elérhető a telefonján. Nincs frissítés, nincs letöltés, nincs üzenetküldés a készülékek között. A játékaik jelentős funkciókat veszítettek ez idő alatt, de a vállalat helyesen cselekedett, amikor leállította a szervereket. Ha nem így tesznek, akkor sok más hackert is magukhoz vonzottak volna, és sokkal nagyobb katasztrófa lett volna a vége. Miután a sebezhető weboldalakat lekapcsolták, és kiadtak egy sajtónyilatkozatot, Lorenzo ezután tette közzé cikkét, amelyben jelezte, hogy a VTech-et adatvédelmi incidens érte. Közzétette az összes részletet, amit a hacker adott neki. Troy Hunt ezt követően egy saját, lesújtó blogbejegyzéssel követte. A hír gyorsan elterjedt a VTech gyenge biztonsági ellenőrzéséről. A szülők világszerte felháborodtak azon, hogy gyermekeik adatai kiszivárogtak. A VTech egy hongkongi székhelyű vállalat, de nagy piaca van az Egyesült Államokban, Spanyolországban, az Egyesült Királyságban, Németországban és Franciaországban. A VTech részvényei zuhanni kezdtek.

Troy etikai dilemma elé is került. A haveibeenpwned.com honlapja lehetővé tette a felhasználók számára, hogy olyan e-maileket keressenek, amelyek nyilvános adatszivárgásokban láttak napvilágot. A 4,8 millió e-mail címet felvette az oldalára, de a gyerekek nevét nem volt hajlandó kereshetővé tenni. A VTech-be betörő hacker még egyszer megnézte az általa megszerzett adatokat. Meglepetésére még több adatot talált, mint amennyit eredetileg gondolt. Volt egy bizonyos könyvtár, amely 190 gigabájtnyi adatot tartalmazott. Ahogy átnézte, rájött, hogy több mint 100 000 képet tartalmaz, amelyeket a gyerekek készítettek a táblagépeikkel, óráikkal vagy laptopjaikkal. Sok ilyen kép duplikátum volt, elmosódott vagy egyszerűen csak fekete, így nehéz volt kitalálni, hogy hány tényleges fotóról van szó. A hacker tovább nézte az általa készített fájlokat. Úgy találta, hogy voltak olyan csevegési naplók, amelyek egy egész évre visszamenőleg is visszanyúltak. Ezek lennének az összes csevegőüzenet, amelyet a gyermek táblagépe és a szülő telefonja között küldtek. Még tovább vizsgálva az adatokat, a hacker talált egy könyvtárat, amely tele volt hangfájlokkal. Megnyitott egyet, és lejátszotta. Ezt hallotta.

Gyermek: Hűséget fogadok az Amerikai Egyesült Államok zászlajának és a köztársaságnak, amelyért ez a zászló áll, egy nemzet Isten alatt és …

JACK: Több ezer ilyen felvétel volt. Ezek olyan felvételek, amelyeken gyerekek beszélnek a tabletjükbe. A hacker visszanyúlt Lorenzóhoz, és átadta neki a 190 gigabájtnyi fotót, az évekig tartó chatnaplókat és számos hangfelvételt. Néhány nappal később Lorenzo egy második cikket is közzétett a Motherboardon ezekkel az új eredményekkel. Most már láthatjuk a gyerekek szerkesztett képeit és hallhatjuk a hangjukat. Ez újabb sót szór a VTech sebeire. Egyre több szülő jön rá, hogy gyermekeik személyes adatait nem tartották biztonságban. A hacker elmondta Lorenzónak, hogy elégedett azzal, ahogy a hírek elterjesztik a probléma tudatosságát. Idézem: „Ez pont akkora visszhangot kelt, mint amekkorát reméltem”. Idézet vége. A hacker azt is elmondta, hogy lehet, hogy új célpontot fog keresni. Idézet: „Talán a VTech versenytársaiba, nem tudom”. Idézet vége. December 1-jén, két héttel a betörés után a VTech közzétett egy GYIK-et. Ez további információkat tartalmazott a hackelésről. A VTech azt állítja, hogy nem csak 200 000 gyermekfiókot vittek el, hanem ez a szám 6,3 millió gyermekfiók volt.

A VTech azonban nem ismerte el, hogy bármilyen fényképet elvittek volna. Ezután Edward Markey és Joe Barton amerikai szenátorok levelet küldtek a VTech-nek, amelyben a gyermekek online adatainak védelméről szóló törvényre (The Children’s Online Privacy Protection Act, más néven COPPA) hivatkoztak, amely 1998-ban született a gyermekek online védelmére. Levelük kilenc kérdést is tartalmazott, amelyekre a VTech-től választ vártak, például: Milyen adatokat gyűjtenek tizenkét év alatti gyermekekről? Mire használják fel ezeket az információkat? Eladják-e ezeket az adatokat bárkinek is? Milyen titkosítást használnak az adatok védelmére? A VTech nem válaszolt azonnal, de végül frissítették a GYIK-et, hogy megválaszoljanak néhányat ezek közül a kérdések közül. Egy héttel a jogsértés után a VTech felbérelte a FireEye nevű biztonsági céget, hogy segítsen az incidensek elhárításában. A FireEye képes volt megtalálni és megoldani a biztonsági problémákat. Január 25-én, két hónappal a szerverek leállítása után, részben helyreállították azokat. A felhasználók újra frissíthették és regisztrálhatták készülékeiket, de az alkalmazásboltot továbbra sem tudták használni.

Egy hónappal a jogsértés után egy angliai bűnügyi egység egy 21 éves férfit fogott el és tartóztatott le egy Londontól nyugatra fekvő városban. Letartóztatták a számítógép jogosulatlan használatának gyanújával, amely körvonalazza az 1990-es számítógépes visszaélésekről szóló törvényt. A bűnügyi egység több talált elektronikus eszközt is lefoglalt. Azt is megemlítették, hogy ez összefüggésben lehet a VTech-csel, de a sajtóközlemény nem közölte a letartóztatott férfi nevét. Lorenzo megpróbálta elérni a hackert, de nem kapott választ. Két hónappal a betörés után Lorenzo részt vett egy elektronikai szakkiállításon, és az egyik standon a VTech-et találta. Éppen egy vadonatúj termékcsaládot mutattak be. Ezek azonban nem gyerekeknek készültek. Intelligens izzókat, ajtóérzékelőket és biztonsági kamerákat árultak. Amikor Lorenzo megkérdezte a VTech marketingigazgatóját, hogy ezek biztonságosak-e, azt mondta, hogy idézem: „egy harmadik fél által végzett behatolásteszteken mennek keresztül, és minden nagyon biztonságos lesz”. Idézet vége.

A következő hónapban a VTech megváltoztatta a szolgáltatási feltételeket a weboldalán. Mostantól ez állt benne, csupa nagybetűvel,
ÖN TUDOMÁSUL VESZI ÉS ELFOGADJA, HOGY AZ OLDAL HASZNÁLATA SORÁN KÜLDÖTT VAGY KAPOTT INFORMÁCIÓK NEM BIZTONSÁGOSAK, ÉS AZOKAT ELFOGHATJÁK, VAGY KÉSŐBB ILLETÉKTELENEK MEGSZEREZHETIK. Úgy tűnik, hogy a VTech úgy gondolja, hogy felmentheti magát a vétkek alól azzal, hogy egyszerűen tudatja ügyfeleivel, hogy adataik nem biztonságosak és bármikor feltörhetik őket. Néhány jogász kommentálta ezt, és úgy vélik, hogy egy ilyen záradék nem állja meg a helyét az Egyesült Államokban vagy az Egyesült Királyságban, olyan dolgokra hivatkozva, mint a COPPA-törvények. Számos politikus és államügyész kereste meg a VTech-et, hogy részletesen megvitassák a COPPA-törvényeket. A VTech frissítette adatvédelmi szabályzatát, hogy jobban megfeleljen a COPPA-nak. Az adatvédelmi szabályzatukban például mostantól azt írják, hogy minden kép és hangüzenet titkosítva van, amikor tárolják. A VTech részvényei a jogsértés előtt csökkenő tendenciát mutattak, a jogsértés után pedig a részvények 13 százalékkal estek. Három hónapon belül ismét a jogsértés előtti szint fölé emelkedett. A játékokat továbbra is árulják a világ nagy játékboltjaiban.

A jogsértést követő hetekben több feldúlt szülő beperelte a VTech North America vállalatot. A pereket egyetlen, csoportos perbe fogták össze. A felperesek között nyolc felnőtt és tizennégy gyermek volt. Másfél évvel később, 2017 júliusában az ügy a bíró elé került. A VTech kérte a bírót, hogy utasítsa el az ügyet, aminek a bíró helyt adott. Azért utasította el az ügyet, mert a felperesek nem tudták bizonyítani, hogy milyen kár érte őket. A bíró nem talált bizonyítékot arra, hogy személyazonosság-lopás vagy bármilyen kár érte volna a felpereseket. A bíró idézte Lorenzo cikkét, amely szerint a jogsértést olyan valaki követte el, akinek nem állt szándékában rosszindulatúan felhasználni az adatokat. Van egy frissítés a történethez. 2018. január 8-án az FTC valóban úgy találta, hogy a VTech megsértette a COPPA-törvényeket. A VTech beleegyezett, hogy kifizeti az FTC által kiszabott 650 000 dolláros bírságot, de kiadott egy sajtóközleményt is, amelyben azt állítják, hogy nem sértettek meg semmilyen törvényt. Emellett kötelesek felülvizsgálni a biztonsági programjukat és biztonsági auditokat végezni a következő húsz évben. [Nem láttuk, hogy ennek a dumpnak a tartalma felbukkant volna bármelyik dark netes oldalon. Ez arra enged következtetni, hogy a hacker betartotta az ígéretét, és nem próbált hasznot húzni az ellopott adatokból.

A VTech GYIK-je tartalmazott egy kérdést, amiben azt kérdezték, hogy mi történt a letartóztatott hackerrel. A GYIK több mint egy éven keresztül egyszerűen csak a letartóztató bűnügyi egység által kiadott sajtóközleményre hivatkozott. A sajtóközlemény nagyon kevés információt tartalmazott. Még a nevét sem tartalmazta. 2016 decemberében, több mint egy évvel a jogsértés után a VTech frissítette a GYIK-et, és más választ adott erre a kérdésre. Azt írta, hogy az elfogott férfi 2016 novemberében egyszerűen csak hivatalos rendőrségi figyelmeztetést kapott. Ha ez igaz, akkor ez azt jelenti, hogy egy teljes évig volt őrizetben, mielőtt rendőrségi figyelmeztetést kapott volna. A rendőrségi figyelmeztetést általában kisebb bűncselekmények esetén tartják fenn, hogy néha megspórolják a teljes rendőrségi jelentés kitöltését, de a bűncselekményt mégis feljegyzik a nyilvántartásba. Lehet, hogy a GYIK elírta az évszámot. Még most, két évvel később is tisztázatlan, hogy pontosan mi történt a hackerrel. Nem tudjuk, hogy letartóztatták-e vagy sem. Még a nevét és a státuszát sem tudjuk. Ha csak egy rendőrségi figyelmeztetést kapott, akkor a történetnek vége. De lehet, hogy még mindig valahol a börtönben ül. Bár a hacker bűncselekményt követett el, a szándéka csupán az volt, hogy feljelentő legyen, és elsődleges célja a gyermekek adatainak biztonságának javítása volt.

A fordítás a https://www.deepl.com segítségével törtönt.

A #2. Darknet Diaries: A VTech Hacker különös esete bejegyzés először AntiHack.hu-én jelent meg.

A kis- és középvállalkozásoknak 1:3 az esélyük, hogy kibertámadás célpontjává váljanak.

Az új-zélandi kormánybiztonsági hivatal (GCSB) részét képező Nemzeti Kiberbiztonsági Központ új kutatása szerint a magas kockázat ellenére sok vállalkozás csak akkor léptet életbe kiberbiztonsági intézkedéseket, amikor már túl késő.

Az NCSC azon dolgozik, hogy megbízható és hiteles információkat és tanácsokat adjon, miközben összeállítja az új-zélandi fenyegetettség profilját.

Michael Jagusch igazgató szerint a vállalkozásoknak javítaniuk kell védekezésüket, mielőtt megtámadják őket.

Az NCSC legújabb kutatása – a Cyber ​​Security Behavior Tracker – kimutatta, hogy a kis- és középvállalkozások (kkv-k) 36 százaléka tapasztalt legalább egy kibertámadást az elmúlt hat hónapban.

Ezek 57 százaléka új lépéseket tett, hogy nagyobb biztonságban legyen az interneten, míg a kkv-k mindössze 27 százalékát nem érte támadás.

Az aggasztóbb megállapítások közül néhány az volt, hogy a kkv-k több mint egyharmada nem készített rendszeresen biztonsági mentést adatairól, és 23 százalékuk nem frissítette rendszeresen a szoftvereket.

„A cégtulajdonosok azzal vannak elfoglalva, hogy azt csinálják, amit szeretnek cégeikkel, ezért célunk, hogy időt takarítsunk meg azáltal, hogy segítünk azonosítani, mely kiberbiztonsági gyakorlatokra kell összpontosítaniuk.”

A legfrissebb felmérés szerint míg a kkv-k 55 százalékának ez volt a legfontosabb prioritása, kevesebb mint a fele mondta azt, hogy felkészült egy kiberincidensre.

„Bár jó látni, hogy néhányan lépéseket tesznek, de a többség az nem. A vállalkozások tisztában vannak azzal, hogy a kiberbiztonság kritikus fontosságú, de más aggályok prioritást élveznek.”

A Kiberfenyegetések: A kkv-k nem tudják, hol kellene elkezdeni… bejegyzés először AntiHack.hu-én jelent meg.