bardóczi ákos @post.r

Igen, jól olvasod, ennyire ügyesen sikerült implementálni a kétlépcsős hitelesítést és valószínűtlen, hogy elsőként vettem észre.

Nem clickbait, azzal kapcsolatban meg mindenkit megnyugtatok, hogy nem arról fogok írni már megint, hogy miért necc az, hogy egy Google/Gmail-heroinista világban élünk.

Aki bekapcsolta a Google Accountján ennek a remek, überbiztonságos rendszernek a beállításai közt a kétlépcsős hitelesítést annak ugye ún. alkalmazásjelszavakat kell létrehoznia, ha például levelezőklienssel is használná a Gmail-t, mivel értelemszerűen a kliensprogram nem tudja pár percenként elvégezni a 2-FA-t magától.

Elvben az alkalmazásjelszavakban pont az a szép, hogy nem kell a felhasználónak fejben tartania, így egyszer kell kopipésztelni a megfelelő helyre és kész, kilopni legfeljebb egy hülyén programozott alkalmazásból lehet, amiben meg lett adva.

Na már most normális ésszel az ember azt gondolná, hogy abban az esetben, ha a felhasználó a 2-FA-t kikapcsolja, akkor az összes alkalmazásjelszó semmissé válik, így például a levelezőkliesen keresztül a levelek csak a fő jelszó beírásával lesznek elérhetőek. Van egy nagyon szar hírem a Google fanoknak: a korábban létrehozott alkalmazásjelszavak nemhogy érvényüket vesztenék, hanem továbbra biztosítják a hozzáférést a fiók adott szolgáltatásához, legalábbis az IMAP4 esetén biztos, Google Drive és a többi esetén valószínűleg, a hasonló  azonosítási séma miatt. Nem, nem ideig-óráig működik, egy érintett fiók több, mint egy hónapja elérhető az elvben már nem létező alkalmazásjelszó használatával úgy - most figyelj! - hogy a fiók fő jelszava is meg lett változtatva. Még az is full mindegy, hogy OAuth2-vel vagy sima, ugyan titkosított csatornán átküldött jelszóval jelentkezik fel a kukkoló alkalmazás!

Mit jelent ez a gyakorlatban? Tételezzük fel, hogy a támadó a célpont gépéhez ül, amíg nincs ott, majd generál egy alkalmazásjelszót olyan névvel, ami még akkor sem lesz feltűnő, ha a Google kényszeríti az érintett felhasználót a security checkup végigjátszására, az app password leírása lehet mondjuk "Gmail", "Mail", "iPhone" vagy hasonló, a megtámadott felhasználónak miért lenne gyanus? A támadó az alkalmazásjelszót feljegyzi. Az alkalmazásjelszóval a támadó belép egy levelezőklienssel, majd IMAP4-en keresztül tokkal-vonóval olvashatja a célpont postafiókjának tartalmát. A Google vagy küld figyelmeztetést az érintett felhasználónak, hogy bejelentkezett valaki mondjuk egy japán VPN-en keresztül, ami igencsak anomáliaszerű, ha a felhasználó sosem használ VPN-t és korábban még csak nem is járt Japánban. Viszont vegyük észre, hogy éppen azért, mert levelezésről van szó, a támadó ezt a levelet simán tudja törölni, mielőtt a felhasználó el tudná olvasni a biztonsági figyelmeztetést!

Tehát ha a felhasználó valamilyen okból kikapcsolja a 2-FA-t, de előtte nem vonja vissza az alkalmazásjelszavak érvényességét, teljesen logikusan arra gondolva, hogy azok ilyen módon érvényüket vesztik, valójában erről szó sincs. Egy korábban beállítva maradt fiókhoz a levelezőprogram úgy fér hozzá máig, hogy az érintett fiókon a 2-FA-t 2018. február elején ki lett kapcsolva, a fő jelszó pedig át lett írva!

A támadó vagy úgy felejtett alkalmazás csak akkor veszti el a hozzáférést az érintett postafiókjához, ha az érintett fiók tulajdonosa ismét bekapcsolja a 2-FA-t, egyébként meg gusztus szerint úgy tesztelheti a hibát, rosszabb esetben pedig kukkolhat, ahogy csak akar.

Az abnormális működést 2018. március 5-én, azaz ma 10:13-kor sikerült reprodukálni egy teszt fiókkal, ugyan nem csináltam sem TCPdumpot, sem HAR-t, mert jobb dolgom is van, aki ráér, annak szabad a pálya.

Hogy ez most bug vagy kényelmi feature,  na, azt nem tudom, ahogy azt sem teszteltem, hogy a Google mára kőkeményen fizetős, vállalati verziója, a G Suite is érintett-e benne, de valószínűleg igen.

Legegyszerűbb bugfix: ne használd azt a szart, legfeljebb spamszűrésre, azaz olyan beállítással, hogy a beérkező leveleket azonnal forwardolja is normális helyre és végleg törölje.

Áldásos lenne, ha ahelyett, hogy a felhasználók leginkább veszélyeztetett néhány ezrelékét nem riogatnák azzal, hogy kormányzati támadást észleltek, ezért változtassanak jelszót és költözzenek le a pincébe, bármiféle indoklás nélkül, hogy miből következtetett erre a rendszer.

Valamint a felhasználók ugyanezen veszélyeztetett csoportjára nem akarnák rátukmálni pusztán a biztonságérzetet növelő, de legalább jó drága baromságokat az Advanced Protection Program keretében, hanem a mezei Gmail-fiók úgy működne, ahogy az amúgy logikusan elvárható. Az én, eredetileg még googlemail.com végződéssel, 2004-2005. körül USA-ból kapott meghívóval létrehozott fiókom pedig csak azért is marad amolyan bóvli kis emlékként.

Az a helyzet, hogy nem lehet kikerülni bizonyos hírekben megjelenő témákat, akkor sem, ha összeszorított farpofával szeretném, mert egyszerűen a csapból is az folyik. Képzelem, ahogy a műkörmös szalonban a szakértő hölgyek azzal kapcsolatban hüledeznek, hogy egy 18 éves diák jelentette a BKK e-ticket jegyvásárlását érintő sebezhetőséget, na jó, ez így bonyolult, inkább csak annyit mondanak egymás közt, hogy meghakkolták a Békákát, erre elvitték a zsaruk. Micsoda világban élünk, elviszik a hékek azt, aki csak segíteni akart. Nem röhögni! A 10 legolvasottab magyar sajtótermék szerintem ennél nem sokkal magasabb szinten tárgyalja vagy lényegében nem eltérő interpretációban tárgyalja a témát. De úgy fest, hogy még az IT-sek közt - na meg aki annak mondja magát - is sokaknál elszállt a séró', ezért gondoltam, hogy egy kicsit oszlatom a ködöt.

Miről is van szó ténylegesen?

A BKK és a T-Systems közösen egy netes jegyvásárlási rendszert vezetett be, aminek az alkalmazásában bennmaradt egy olyan hiba, amilyenre én tankönyvi hibaként szoktam hivatkozni, mert annyira triviális. Innentől kezdve úgy írom, hogy az a műkörmös is megértse, aki még nem látott forráskódot, az informatikában minimálisan is jártas műkörmösöktől pedig előre is elnézést kérek! Több hibáról van szó egyébként, a legegyszerűbbet fogom kivesézni. /*azt is pongyolán, amiért pedig azok elnézését kérem, akik értik, hogy miről van szó*/

Amikor egy alkalmazás/szolgáltatás/API adott típusú bemenő adatot, azaz például egy pozitív egész számot kér, mint amilyen pozitív egész egy BKK-bérlet ára forintban, akkor nyilván nem logikai értéket, negatív számot, éppenséggel a Despacito szám egyik sorát, mint sztringet, azaz karaktersorozatot fogja megkapni, hanem valóban pozitív egészet. Na már most, elvben nincs akadálya annak, hogy egy egész számot váró szolgáltatás más típusú adatot kapjon, viszont elemi, na még egyszer: _elemi_, hogy fel kell készíteni a szoftvert az ilyen eset kezelésére. Nyilván nem fordulhat elő véletlenül, hogy a rendszer a 9500, mint egész szám helyett /*egy havi bérlet ára forintban*/, a szerver felé - a továbbiakban: szerveroldalra - mondjuk a "Sí, sabes que ya llevo un rato mirándote" karaktersorozatot küldje vagy mondjuk egy logikai  értéket. Viszont kábé az első, ha nem nulladik dolog az, amit nem hogy egy éles üzembe állított rendszeren egy fekete kalapos hekkernek, fehér kalapos hekkernek vagy egy médiában kikiáltott balfácánnak kell ellenőriznie, hanem a tesztelőnek már az adott modulban ki kell szúrnia - módszertantól függően - mondjuk az unittesztelés során. És abban az esetben, ha azt észleli, hogy a fejlesztő annyira hülye volt, hogy egy ilyen egyszerű trükkre, azaz az adat on-the-fly átírhatóságára nem készítette fel a szoftver adott részét, alaposan dokumentálja, iszik egy felest, majd megpróbál egy kulturált levelet írni a fejlesztőnek, ami tartalmazza a javítással kapcsolatos instrukciókat /*részletekbe menően vagy kevésbé*/, aztán ez vagy sikerül européer stílusban vagy sem.

A leírt folyamatot, azaz azt, hogy egy szoftver ellenőrizze, hogy valid adatot kapott-e és nem egy nyári sláger első sorát karaktersorozat formátumban, esetleg egy olyan bitsorozatot /*nagy általánosságban fogalmazva*/, ami tetszőleges műveletet hajt majd végre a szerver oprendszerén vagy annak valamelyik szolgáltatásában röviden parserelésnek nevezzük, persze ez önmagában még mindig nem elég.

Azaz amellett, hogy leprogramozzák, hogy valami egész számot vár, biztosítani és ellenőrizni is kell, hogy oda csak egész szám kerülhet, majd továbbítódhat-e.

írok egy olyan sebezhetőséget, de én inkább tweaknek nevezném, ami gyakorlatilag dettó ugyanerre épül, pont az előző posztban írtam róla, csak én nem egy szaros jegyvásárlási rendszerrel csináltam meg, hanem a Facebookkal, másrészt nem azért, hogy én legyek egy hétig a nemzeti Robin Hood, hanem azért, mert praktikusnak találtam. A következőről van szó: a Facebook egész számokkal azonosítja a jogosultságokat - többek közt - azaz, hogy valaminek a láthatósága, eléghetősége Only me, Friends, Friends of Friends vagy Public/Everyone vagy egy általad definiált, ismerősöket tartalmazó lista. Azaz amikor a Facebookon beállítod, hogy ki jelölhet be ismerősnek, azaz "Who can send you friend requests?", akkor alapvetően egy egész számot továbbít és rögzít a rendszer. Évekkel ezelőtt észleltem, hogy éppen ennek az azonosítónak az átírásával a Facebook olyan beállítást is elfogad, aminek konkrétan nincs értelme, azaz például, hogy csak önmagamat jelölhetem ismerősnek, csak a barátaim jelölhetnek ismerősnek [nem is tudnak, mert eleve a ismerőseim ugye], de még olyat is, hogy az ismerőseim egy listában tárolt része jelölhet ismerősnek, ami ugye még elborultabb. Viszont minden ilyen szokatlan beállításnak az lett az eredménye, hogy konkrétan senki sem tudott ismerősnek jelölni - hál' Istennek - akit eléggé érdekesnek találtam, azt úgyis bejelöltem én. /*csak egy üres listába tartozó felhasználók "tudtak" ismerősnek jelölni*/ Mi történt? Az, hogy a Facebook nem ellenőrizte, hogy értelmes beállítást kap-e egyáltalán, azaz hogy csak olyanok jelölhetnek ismerősnek, akivel van közös ismerősöm vagy éppen mindenki. Ez a bemenet valószínűleg nem volt parserelve vagy parserelve volt ugyan, egyéb helyen eltolva. Az előző posztban írtam, hogy ezt a beállítást a mobilappon sikerült elállítanom, viszont az évekkel korábbi módszerrel visszaállítani nem sikerült, ami bosszantott pár percig, aztán nem érdekelt.

Ami a BKK jegyrendszerét érinti, meggyőződésem, hogy a legvadabb hibákat egymástól függetlenül több százan szúrták ki, mert annyira triviálisak. Volt és sejthetően még mindig van benne néhány sokkal súlyosabb hiba is, ami ennyire röviden nem magyarázható el Ádámtól-Évától. Nem világos, hogy mennyien jelentették a hibát, az igen, hogy végülis volt egy jól beazonosítható, 18 éves gyerek is, aki igen. Innentől különösen fontos egészében nézni az eseményeket, mert elképesztő zavar van a fejekben.

Nem tisztem megvédeni a T-Systems-t, és nincs is rá szükségük - bár ilyen PR mellett ki tudja - de szó sincs róla, hogy a nagy, gonosz, hülye, bugyirózsaszín IT-cég vagy épp a BKK szemétkedésből tett volna feljelentést, hanem azért, mert ilyenkor jogszabályi kötelessége feljelentést tenni! Igen, még akkor is, ha világos, hogy pont annak a 18 éves srácnak az évszázad hakkolásával' együtt a társadalomra való veszélyessége nem is mérhető. Mindemellett a T-Systems kríziskommunikáció szempontjából megbukott, alighanem senki sem mert időben beleállni a dologba azzal, hogy köszönik, hogy a hibát jelentették, de azért a feljelentést meg kellett tenniük. Akinek nem világos, hogy ez miért van így, annak fingja nincs róla, hogy hogyan működik ez az egész. Ami pedig a Készenléti Rendőrséget illeti - amelyiket ugyancsak nem kell megvédenem - onnantól kezdve, hogy érkezik hozzájuk egy ilyen feljelentés, nem gusztus dolga, hogy eljárnak vagy sem, hanem szintén a törvény betűjét követve kell eljárniuk, akkor is, ha az sajnos az adott esetben életszerűtlen és aránytalan intézkedést ír elő, mint amilyen az előállítás. Azt azért szögezzük le, hogy nem éjszaka jelentkezett a hatóság, hanem reggel 7-kor, nem rúgták rá az ajtót, hanem kopogtattak, ami pedig az előállítást illeti, senki sem gondolhatja komolyan, hogy vezetőszáron kellett volna bevinni a gyereket Hannibal-maszkban. Azaz a Rendőrség, amelyiknek a tagjai már teljesen megszokták, hogy általában teljesen igazságtalanul élcelődik rajtuk a plebs, ugyancsak jogszerűen jártak el.

Egészében az eljárás - ahogy egy, az Ibtv. /*aka 2013. évi L. törvény*/ megalkotásában részvevő ismerősöm megjegyezte, jogszerű volt, de szégyenletes.

Na most ami a sajtót illeti, az egész hírértékét az adta, hogy mégiscsak egy jókora céget mogyoróztak meg, a szoftver lefejlesztésében tényleg orbitálisan nagy hibák vannak, az már mindegy, hogy mik, lehet hülyézni és kész. Ilyen esetben egyetlen nagyobb sajtóorgánum sem teheti meg, hogy ne szálljon fel a dilivonatra és tolja a hülyeséget, ezen kívül szokásosan mindenki egyszerre lesz telekommunikációs szakjogász, na meg a műszaki etika szakértője egyszerre.

A szerencsétlen módon előállított csávó pedig nem is etikus, nem is hekker, ami pedig legalább ilyen fontos, hogy vagy eszelősen naiv volt vagy eszelősen hülye.

A bugreporting, azaz egy-egy sebezhetőség bejelentése már-már külön tudomány, már ha úgy akar valaki eljárni, hogy abból senkinek se származzon kára, ő is legyen jogilag védve, nem mellékesen pedig a felhasználók is, akiknek az adatai pont egy-egy ilyen pszeudo-full disclosure miatt kerülhettek veszélybe, már ha igaz, hogy még az e-ticketes ügyféladatbázis is lopható volt.

Azaz ha észlelünk egy hibát, akkor nem, nem ész nélkül, azonnal jelentjük saját néven, tök hülyén, hozzátéve, hogy Proof-of-Concept, a sebezhetőséget még ki is használtuk, hanem megkérdezzük a területen jártas jogászt, utánakotrunk, hogy milyen policy szerint érdemes a hibát jelenteni a konkrét esetben, ha meg minden kötél szakad vagy csak nincs cérnánk ilyen részletekkel tökölni, akár teljesen névtelenül jelentjük. Aztán ha még továbbra sem javítják, akkor jöhet a full disclosure, gusztus, na meg vérmérséklet kérdése, hogy mennyi idő várakozás után. Tipikusan egyébként már az nem egyértelmű, hogy a hibát hova lenne érdemes jelenteni, azaz hogyan érhető el a tényleges responsible contact, mert egy sima, ügyfélszolgálati címre küldött email biztos, hogy nem az. Nem nehéz rájönni, hogy az ügyfélszolgálatok nem ilyen típusú minősített adatokkal dobálóznak nap, mint nap, sok-sok kézen megy keresztül a bug részletes leírása, aztán jó esetben senki sem használja ki, aki olvasta. Például akinek az ügyfélszolgálatos véletlenül elmondja, aztán akinek elmondta vesz 1000 darab havi bérletet 10 forintért, ami pedig a bejelentést illeti, majd vagy eljut az illetékeshez vagy sem.

Akinek van egy csöpp esze szinte mindig úgy dönt, hogy nem tököl-kockáztat, ha hibát talál, eljuttatja annak a körnek, amelyik a legnagyobb valószínűséggel illetékes és nyugodtan alszik a bejelentő. Illetve amikor valami nagyon meredekről van szó, akkor olyat kell kérdezni előzetesen, aki meg tudja jósolni, hogy egy bejelentést követően mire lehet számítani.

Na most egy olyan világban, ahol az emberek már akkor sértve érzik a magánszférájukat, ha valaki, akivel ismerkednek netes társkeresőn vagy anonim fórumon, aztán meg meg vannak lepődve, ha a másik megtalálja őket a keresztnevük és a koruk vagy egy általuk kedvelt oldal vagy meglátogatott esemény alapján /*igen, ennyi pontosan elég hozzá*/, akkor se a jogalkotóktól, sem a megoldásszállító cégektől, se a sajtótól, se a hatóságoktól nem várható el, hogy életszerűen tudjanak kezelni egy ilyen helyzetet.

Konkrétan ebben az esetben senki se jöjjön azzal, hogy inkább jutalmazni kellett volna a srácot, mivel totálisan töketlen volt a hiba bejelentése, az eset valamire azért nyomatékosan felhívja a figyelmet. Mégpedig arra, hogy bárki, akár etikus hekker, akár advanced user, akár érdeklődő, ha rendelkezik olyan ismerettel, amivel az átlag felhasználó nem, inkább tartsa a dolgot titokban, de komolyan! Ugyanis ez akár igazságos, akár nem, de a többség totálisan félreérti az egészet, elég egy kommunikációs botlás és már megállíthatatlanul borul is az illetőre a trágyalé. Hogy mást ne mondjak, sokszor egy tényleges informatikai bűncselekmény kapcsán nem azon kerültek a lehetséges gyanusítottak körébe sokáig, akiknek érdekükben állhatott az elkövetése, hanem azok, akikről tudvalevő volt, hogy technikailag képesek rá, ami nettó őrület, de így van. A Google- és Facebook-fiókhardeningelős posztjaim után halomra kaptam a segghülye leveleket azzal kapcsolatban, hogy én mennyiért törnék fel ilyen-olyan accountot. Szóval ennyire nem értették meg néhányan, amiről azt hittem, hogy egyértelmű annak, aki nem analfabéta, nevezetesen, hogy a cikkek lényegi mondanivalója nem az, hogy hogyan törjünk FB-fiókot, hanem az, hogy hogyan csökkenthetjük a rizikóját annak, hogy megtörténjen. A gyógyszerész is tud mérget keverni, de aligha fog, hiába kéri tőle valaki jópénzért. Hasonlóan, aki tud hardeningelni, nyilván törni is, de nem fog.

Tudsz valamit? Tagadd le! De tényleg! És akkor nem fognak lehekkerezni meg összemosni mindenféle idiótával. Majd akkor lehet előhozakodni security- és privacy-related tudással, amikor az a közeg, amiben élünk, kellően érett lesz hozzá, addig inkább ne.

Na, én most megyek, keresek az utcában egy lakatosként dolgozó szomszédot, hogy este elmenjünk buliból betörni, aztán majd szelfizünk egyet a kinyitott ajtó előtt, szigorúan úgy, hogy látszódjon az utca és a házszám, majd töltjük is fel a Fészre, betaggelve a kerületi rendőrség oldalát...

kép: Knowyourmeme

Két nappal ezelőtt hozta nyilvánosságra Ysrael Gurt, a Cynet kutatója azt a sebezhetőséget, amit kihasználva egy nagyon egyszerű trükkel bárki olvashatta másvalaki összes üzenetét, eddig, mivel a Facebook most végezte el a bugfixet. Arról már volt szó, hogy ne bízzunk egy szolgáltatásban csak azért, mert több száz millióan, jelen esetben pedig több, mint egy milliárdan bíznak benne, ami meg konkrétan a Facebookot illeti, a hiba még akkor is több, mint durva, ha figyelembe vesszük, hogy az üzenetküldőt messze nem bizalmas üzenetek továbbítására találták ki, majd írták át egy egyszerű XMMP-alapú chatmodulból. Nyugi, nem szedem elő ismét azt a rémesen nyomasztó jelenséget, hogy már sokan már a Messengert használják az email helyett annak ellenére, hogy mennyi elképesztő, Messengert érintő sebezhetőség jelent meg csak idén.

A mostani sebezhetőség lényege, hogy amikor csetelés vagy üzenetküldés közben a kliens XML HTTP kéréseket küld, közben egy Javascript folyamatosan ellenőrzi, hogy a kommunikáció valóban a kliens és a Facebook csetszervere közt történik-e, teszi mindezt a kérésekkel továbbítódó Access-Control-Allow-Origin és Access-Control-Allow-Credentials fejlécekkel dolgozva. A bökkenő csak az, hogy a Facebook egyedileg implementált, oldalon keresztüli kéréseket ellenőrző része megtéveszthető egy rosszindulatú, az áldozat által gyanutlanul lefuttatott Javascript-kóddal olyan módon, hogy az üzenetfolyam _bármilyen_ szerver, jelen esetben mondjuk a támadó szervere irányába menjen illetve legyen hozzáférhető. Az eredmény: a támadott felhasználó összes üzenete, annak minden csatolmányával, teljes egészében ellopható. A hiba természetesen minimum azóta rohad a Facebook üzenetküldőjében, mióta átálltak az XMMP-szerű rendszerről, azaz több éve.

A támadás kivitelezéséhez nem kell sztárhekkernek lenni, bárki kivitelezhette, aki jártas a webfejlesztésben.

A bejelentés egyszerűsített változata itt érhető el a műértők számára érdemes megnézni a teljes bugreportot itt. 

Az Originull-nak csúfolt sebezhetőség PoC-videója pedig itt tekinthető meg

Alighanem többen vannak, akiket a technikai részletek kevésbé érdekelnek, ezért írok egy kicsit arról is, hogy milyen, technikai problémán messze túlmutató hatása van annak, hogy világméretű szolgáltatások ilyen fájdalmas hibákat tartalmaznak. Ugyanis az este mutattam egy fejlesztő ismerősnek, aki eljópofizta a dolgot, amivel instant sikerült felidegesítenie.

A Gartner előrejelzése szerint 2020-ra a felhasználói információk átlagosan kétharmad-háromnegyed részben semmilyen módon nem lesznek megvédhetőek, ami ha valóban bekövetkezik, akkor egy eléggé vérfagyasztó szingularitás küszöbén állunk, ami a teljes civilizációra komolyabb hatással lesz, mint első blikkre tűnik. Mire gondolok konkrétan?

Egyrészt ismert, hogy mióta kialakult a mai értelembe vett emberi kommunikáció, megelőzve az írásbeliséget, ezzel egy időben jelent meg az emberben annak az igénye, hogy amit a másikkal közöl, bizonyos esetekben ne tudja mindenki. A civilizációk többségében ha négyszemközt mond az egyik fél valamit a másiknak, akkor azt nyilván azzal az elvárással teszi, hogy az az információ valóban köztük marad, hiszen számos esetben nagyon súlyos következménnyel is járhat az, ha valakitől vagy valakiktől széles körben elérhetővé válna olyan közlés, amit titokban kellene tartaniuk. És még csak nem is kell nagy dolgokra gondolni, teljesen köznapi esetekben is vannak ilyenek, hacsak valaki nem egy remete, mondott már el olyan a bizalmasainak, amik ha nyilvánosságra kerülnének, minimum vércikik lennének, de sanszos, hogy az illetőnek az egzisztenciája, melója, önbecsülése veszne oda.

Másrészt több modell igazolja, hogy a társadalmat stabilizáló egyik legfontosabb tényező az emberek egymás közti általános, egymásba fektetett bizalma, amit nyilván teljesen aláás az, ha semmit sem lehet mondani úgy senkinek, hogy ne kelljen attól tartani, hogy az a közlés bizony simán kikerülhet. Világos, hogy egy ilyen világban még a legidiótább, legnihilistább embertársunk sem élne szivesen.

Mindezek ellenére a felhasználók döntő része egyszerűen csak legyint az egészre, jön ezzel a „nekem nincs titkolni valóm” című őrülettel annak ellenére, hogy a kommunikációnk olyan mértékben a netre költözött, hogy nem nagyon tudok elképzelni olyan – csúnyán mondva - jelentéktelen embert, akinek ne lehetne okozni súlyos érdeksérelmet, ha csak úgy bele vájkálnának a netes magánéletébe és elkezdenék teregetni, amit találtak, mondjuk egy kirúgott ex.

Amit a tömeg egyszerűen nem ért meg, mi több, alighanem nem is gondolt rá soha, hogy nem csak azoknak az információknak a bizalmasságáért, sértetlenségéért felelős, amiket ő irkál másoknak, akár email, akár IM-üzenet, hanem minimum morális felelősséggel tartozik azért is, hogy megőrizze azoknak az adatoknak a bizalmasságát, amit neki küldött más annak tudatában, hogy azt csak a címzett olvassa majd, legalábbis más nem nagyon. Vegyük észre, hogy előállt egy olyan hülye paradox helyzet, hogy ma az emberek hallgatólagosan elvárják egymástól, hogy amit egymással magánüzenetben közölnek a neten, az bizalmasságát tekintve legyen olyan, mint egy négyszemközti beszélgetés, ugyanakkor egyáltalán nem szocializálódtak bele abba, hogy ennek a feltételeihez alkalmazkodniuk kell, hasonlóan ahhoz, amikor valakinek súgva mond valaki másnak valamit.

Messze nem lehetetlen, hogy konkrétan elszabaduljon a pokol, ha nem szokik hozzá egyszerűen mindenki ahhoz, hogy hogyan kommunikáljon magánban a neten ésszel, éberen, tudatosan. Miért mindenki? Azért, mert én hiába járok el a legnagyobb körültekintéssel, amikor valakinek üzenetet küldök, ha az illető nem veszi komolyan azokat az újonnan megjelenő játékszabályokat a kommunikációban, amik civilizációs léptékben a levelezés vagy könyvnyomtatás megjelenésével összemérhetőek, ilyen módon tőle kikerülhet az az információ is, amit én küldtem neki bizalmasan.

Ennél jobban komolyan nem tudom elmagyarázni, hogy én amolyan tüneti kezelésként miért kérek mindenkit, hogy emailt küldjön, hívjon fel vagy ha már nagyon szeret csetelni, legalább ne valamilyen hulladékot használjon, hanem olyan alkalmazást, amit sejthetően nem lehet csak úgy megroppantani, így például Telegramot, esetleg Signalt.

Többször volt már olyan, hogy valaki nekem valamilyen traumáját nem tudta szóban elmondani, ezért elküldte emailen. Na most akkor szépen képzeljük el, ha a feladó által elküldött levelet nem csak én olvashattam volna, hanem én, plusz a csajom, plusz a legjobb barátom, akikkel alighanem a másik nem osztott volna meg egy olyan többéves traumát, amit velem osztott meg először. Oké, ilyen jellegű levelet azért nem sokat kaptam, viszont olyat rendszeresen kapok, amit a szakmai tartalma miatt felelősségem megfelelően védeni.

Hogy milyen lesz a magánszféra szép új világa? Sejthetően egy rakás, a semmiből megjelenő, parasztvakító cég fog még megjelenni, miközben még a legelővigyázatosabb felhasználó is majd csak lesegethet, mint pocok a lisztben, ha egyetlen hülye levelezőpartnere miatt a teljes köztük lefolytatott levelezés vagy más üzenetküldés kikerül, esetleg felkerül a Pastebin-re vagy a szürke- vagy feketepiacon adják el HR-cégeknek vagy egészségbiztosítóknak, miközben a magánéletét közösségi weben rutinszerűen kiteregető birkanyáj ilyen-olyan kormányzati megfigyeléstől tart.

A Silent Signal kutatói hétfőn egy blogposztban számoltak be róla, hogy a világ egyik vezető biztonsági csomagja, a Panda Adaptive Defense 360 olyan hibát tartalmaz, amit kihasználva az antivírus motor simán megengedi rosszindulatú kód lefutását, ha az azt tartalmazó fájlt tévesen fehérlistára tette a víruskergető. A Silent Signal nem először mutat rá éppen olyan termékek hibáira, amik éppen informatikai rendszerek biztonságát kellene, hogy fokozzák.

Haladó felhasználók most ne olvassanak tovább, szájbarágó poszt következik, több helyen egyszerűsítésekkel.

Hogy mennyi kártékony kód létezik a világon, csak nagyságrendileg sejthető, egy eléggé megbízható forrás szerint az azonosított vírusok száma 2016-ban 600 millió körül járt és közel négyszázezer új rosszindulatú kód jelenik meg naponta, ugyan ezeknek egy jókora része korábbi vírusok polimorfjai.

A vírusirtók gyártói már régen olyan megoldásokat építettek a termékeikbe, amik nem csak ismert vírusok után keresnek, hanem például az éppen futtatott alkalmazások és szolgáltatások viselkedéséből következtetnek rá, hogy a gép vírusfertőzés áldozata lett. Emellett gyakori egy másik, igencsak megbízhatónak látszó megoldás az ún. fehérlisták összeállítása, azaz amikor a security suite telepítését követően a védelmi szoftverek megjegyzik, hogy mely fájlok futtathatóak anélkül, hogy különösen szaglászni kellene őket, hiszen így az egész kevésbé lassítja a gépet, akár egy végponti gépről, akár egy szerveroldali megoldásról van szó. Ilyenek például a Windows megszokott szolgáltatásai, gyakran használt alkalmazások, a fehérlista pedig később bővíthető egy-egy új alkalmazás telepítése után, jó esetben úgy, hogy a víruskergető azért előtte ehhez a felhasználó szives beleegyezését kéri.

Abban az esetben, ha az AV termék a fájlokat például önmagában a nevük alapján jegyezné meg és tenné fehérlistára, szinte értelmetlen lenne, hiszen a vírusok ezt kihasználva egyszerűen felülírnának egy legitim, fehérlistán lévő fájlt egy olyannal, ami rosszindulatú kódot tartalmaz, majd a fertőzött fájl legitimként futna le. Ezért a biztonsági termékek inkább elkészítik a fájl teljes ún. hash-lenyomatát és mindig ezt használja a fájl azonosítására. A hash-érték pedig függetlenül attól, hogy miből generálódott, állandó, de kis hosszúságú, például 128 bit.

Egyszerűsítve, ha az elindított alkalmazáshoz vagy szolgáltatáshoz tartozó fájl apró hash-értéke egyezik azzal, amit a víruskergető korábban tárolt, akkor futtatható, ami nyilván sokkal gyorsabb, mintha a teljes, akár több megabájtos fájlt tárolni kellene, majd az elejétől a végéig mindig megnézni, hogy egyezik-e a korábban tárolttal.

Ideális esetben természetesen egy adott tartalomhoz, jelen esetben egy fájl tartalmához csak egy hash-érték tartozhat illetve olyan hash-algoritmust használ egy jólnevelt szoftverrendszer, amit nem lehet csak úgy becsapni, hiszen ekkor a vírusok akár fehérlistás alkalmazásoknak is álcázhatnák magukat.

Viszont nyilván vannak erős, ugyanakkor rosszul leprogramozott vagy egyszerűen becsapható hash-algoritmusok, mint amilyen a Panda terméke által használt, eltéríthető MD5 algó.

A leginkább para pedig az az egészben, hogy egy olyan termékben, amelyik biztonsági csomagként azért lenne felelős, hogy biztosan azonosítsa a biztonságos és esetlegesen kártékony folyamatokat, ez simán eltéríthető, ahogy azt a Silent Signal egy videón keresztül be is mutatja.

Adja magát a kérdés, hogy akkor mégis miért használnak még biztonsági termékekben is MD5 algót valamilyen más helyett? Több lehetséges tippem is van, az egyik legerősebb érv talán a fejlesztői lustaság és megszokás, ami jelen van függetlenül attól, hogy biztonsági csomagot vagy valamilyen faék egyszerűségű appot kell fejleszteni.

Kép: blog.varonis.com

Volt itt már szó arról, hogy nem a legbölcsebb dolog egy olyan cég infrastruktúrájára támaszkodni és ott tárolni minden felhasználói adatot, ami egyrészt elad kilóra, másrészt a közvélemény úgy tudja róla, hogy bizony a Google azért nem ad ki adatot csak úgy holmi hatósági megkeresésre sem, ahhoz Kaliforniáig vagy ha addig nem is, írországig kell menni jogsegélyért, ott meg úgyis beintenek az adatigénylőnek. Múltkor valamelyik magyar lap, amelyiknek a DNS-adatai alapján gondolom nem csak a teljes levelezését, hanem a többi – pl. Drive – szolgáltatását is a Google vállalati verziója, a G Suite, leánykori nevén Google Apps viszi, arról cikkezett, hogy muhaha, mennyi magyar adatigénylést utasított el a Google, ami amúgy itt tekinthető meg.

A hamis biztonságérzetnél pedig nem sok rosszabb van. Merthogy ha valaki nagyon akar, semmi szüksége rá, hogy a Google-höz intézzen adatkérést egy magyar Google felhasználóval kapcsolatban.

Egy kis ismétlés: arról már írtam, hogy ahhoz, hogy a Google Magyarországon elfogadható sebességgel tudjon szolgáltatni – pláne nagy adatforgalmat generáló tartalmakat [Drive, Youtube] – nincs mese, hazai ún. peering vonalakra van szüksége az adatok előtöltéséhez, ami – most figyeld! – nagyobb sávszélességű, mint a Magyar Telekom és a UPC együttvéve a maga laza 60 gbps-es sávszélességével. Az előtöltéshez persze nem csak külföldi irányból fogadni kell az ésszel felfoghatatlan mennyiségű adatot, hanem nyilván Magyarország területén tárolni is.  Ezt ún. CDN-szolgáltatókkal megállapodva teszi, aminek a lényege, hogy olyan, mintha a Google belföldről szolgáltatna, ugyan már nem vagyok annyira biztos benne, hogy ezek a CDN-kiszolgálói adatparkok hol vannak helyileg, a lényeg viszont, hogy ha magyar felhasználó adatát lopná valaki, nyilván csak a megfelelő szerverhotelt kellene megkörnyékeznie.

Ha még mindig nem világos, hogy ez miért elengedhetetlen, plusz egy kis magyarázat. A netes piacon ha valami brutálisan drága, többet közt az adatátvitel, így ha valaki feltölt egy videóklipet Kanadában a Youtube-ra és azt Magyarországon valaki megnézi, Magyarországra elő is töltődik a tartalom és a többi magyar nézőt már eleve helyből szolgálják ki, nem rohadt drágán transzatlanti kapcsolaton keresztül. Ez nem tűnik annyira parának, viszont az már sokkal inkább az, hogy ha a rendszer azt látja, hogy a leveleid és a Drive-ra töltött fájljaid rendszerint Magyarország területén nézed meg, azoknak is minimum egy példánya itt fog tanyázni. Na most innentől kezdve, hangsúlyozom, technikai szempontból nem sokkal bonyolultabb hozzáférni az elvben Google-által kezelt adathoz, mint egy Magyarországon hosztolt szerver tartalmához, az más kérdés, hogy mit mond a törvény bötűje.

Ahogy korábban már szintén írtam, annyira azért hardeningelt a rendszer, hogy az átlag felhasználót megvédjék a saját hülyeségétől, jelszólopásoktól, primitívebb támadásoktól. Azaz ha például valaki rendszerint Budapestről nézi meg a leveleit, majd fél órával az utolsó belépést követően mondjuk Párizsból lépne be, helyes felhasználói név-jelszó párossal, a rendszer joggal gyanakodhat jelszólopásra a szokatlan aktivitás miatt. A rendszer sikongat, SMS-t küld a felhasználónak plusz tokennel, amit meg kell adnia a jelszó mellett, megkérdezi a másodlagos email-címet vagy hasonló olyan adattal próbálja azonosítani a felhasználót, amit elvileg csak az account tulajdonosa tudhat, ha pedig már nagyon nagy gáz van, lezárja az egészet bekér egy személyi igazolvány scant és 1-3 USD-t, amit olyan bankkártyával kell kifizetni, aminél a bankkártyatulajdonos neve az a név, ami a Google-nél meg van adva, de ez eltarthat pár napig.

Ez az egység sugarú felhasználót megvédi mondjuk a közönséges jelszólopásos támadásoktól.

Na de mi a helyzet kifinomultabb támadás esetén? Elvben már 2012 óta a rendszer azonosítja a kormányzati eredetű támadásokat a tragikus csak az az egészben, hogy egy figyelmeztetésen kívül a felhasználó semmilyen további információt nem kap!

2005-ben, amikor gyakorlatilag csak USA-ban élő ismerőstől érkező meghívóval lehetett regisztrálni a Gmail-re, ilyen módon übermenőnek számított, regisztráltam én is, nem olyan rohadt nehéz kitalálni, hogy milyen azonosítóval. Aztán ugye a többi Google-szolgáltatást is ehhez kapcsolták hozzá, gyakorlatilag innentől van értelme arról beszélni, hogy Google Account.

 Google-szolgáltatásokat már évek óta nem használnék, ha nem lenne nagyon muszáj:
-    webanalitikára ingyenes eszközök közül a Google Analytics megfelel
-    a zene a Youtuberól megy
-    keresőbarátabbá válik az a tartalom, amit a Google Plus-ban megosztok a nevemmel
-    rám lehet írni Hangouts-on, rendszerint annyit válaszolok, hogy írjon bárhol máshol : )
-    Translate
-    spam-előszűrés G Suite-tel

Hirtelen ennyi jut eszembe. Erre ma mi jön szembe Translate használat közben? Inkább mutatom:

Nem, nem adathalász oldal volt, kattintottam is a Secure my account gombra, mire kijön ez:

Szóval minden fasza, oszoljanak, nincs itt semmi látnivaló. Mondjuk még meg lehet nézni egy semmitmondó support oldalt, de belépve a Google Security dashboardjára, már ha lehet annak nevezni ezt a szart, ami az átlag felhasználók számára biztos igen hasznos, semmi, de semmi nem derül ki! Azaz például hogy miből következtetett a Google arra, hogy engem biza’ valamelyik kormány próbál meghakkolni, milyen típusú volt a szokatlan aktivitás. Összehasonlításként abban a levelezőrendszerben, amiért fizetek, minden típusú sikeres és sikertelen hozzáférés naplózott olyan ezer évre visszamenőleg.

Röviden: ha advanced userként még mindig ragaszkodsz ehhez a szarhoz, azon se lepődj meg, ha a legszigorúbb biztonsági beállítások mellett megpróbálnak hozzáférni az információidhoz, de semmilyen adatot nem találsz azzal kapcsolatban, hogy mi történhetett.

Az ITsec-szcénában közhelyes, hogy nem az a kérdés, hogy valamit valakik feltörnek-e, hanem az, hogy mikor. Ha nem vállalati környezetről van szó, valami miatt érdekes felhasználó esetén nem az a kérdés, hogy hozzáférnek-e az ingyenes szarokban tárolt információihoz egyszer, hanem az, hogy az mennyire fog fájni. Az meg konkrétan felfoghatatlan, hogy ma egy cég miért választja a Google vállalati suite-ját, aminek az előnye abban merül ki, hogy a webes felület nagyon hasonló, aztán a nyelvújítás táján született felhasználóknak sem kell újat megszokni. A céges környezetben alkalmazott Google suite tehát nem megmagyarázhatatlan: tájékozatlan IT döntéshozó + kényelmes felhasználók.
Ez van.

Kép: Techworm