... a Telekom és a BKK képes bizonyítani, hogy van lejjebb. Nem T-Systems nevet említettem, hanem a Telekomot. És igazság szerint nem csak a magyar cégre gondolok, hanem a multira. Mert a feljelentés ügyben sok mindenre lehetett volna mutogatni, csak éppen kötelező protokollra nem. Mert ez egy olyan helyzet volt, amihez normális esetben a protokollnak nem volt köze. Pont azért, mert az érintett hackelés is kívül esett azon a körön aminél lehet vizsgálni, hogy etikus hackelés vagy sem. 

Viszont a normális protokoll egy normális cégnél nem az, hogy a biztonsági igazgató a tények javának a mérlegelése nélkül személyesen megy el feljelentést tenni, a kritikus biztonsági hibák jelentős része marad, a felhasználók képébe hazudnak és ezzel végighaknizzák az egyik oldal politikai médiáját. Ha a Telekom családban bárhol ez a protokoll akkor a Telekom család minden része hiteltelenné válik, hiszen az ilyen szintű becstelenségre felsőbb szinteken is rá kell bólintani.

Ez esetben sok ember és cég nem csak magát a Telekom csoportot fogja kerülni, hanem a T-Systems minden ismert ügyfelét is, hiszen azok ilyen eljárásnak teszik ki őket, olyan cégre bízzák az adataikat ami súlyosan rosszhiszemű, tisztességtelen és megbízhatatlan. Ha viszont mégsem ez a protokoll és a mulasztás kiderül, és az is, hogy ez a kommunikációs stratégia, a rendszer nem leállítása rontott a helyzeten, akkor a felelősök mindegyikét ki kell rúgni, és mindegyik ellen feljelentést kell tenni a cég részéről. 

Félreértés ne essék, az "etikus hacker" bérletvásárlása önmagában belefért. A hiba nyilvánosságra hozatala azonnal, méghozzá úgy, hogy azzal bárki visszaélhetett és nem tudhatta, hogy ezt képes-e utólag kiszűrni a BKK általában már nem az etikus hackelés kategóriája. A "nekem hírnév, nektek kár" helyzet ugyanis nem az. Sem azonnal nyilvánosságra hozott exploitnál, sem defacenél, sem más hasonlónál. 

Vannak olyan hiányosságok amiket azonnal nyilvánosságra szabad hozni. Sőt kell is. Mondjak kapásból példákat? Mert volt itt ilyenből is pár. A plaintext jelszó, a DROWN sebezhetőség az SSL kapcsán vagy éppen a profil szerkesztésnél előre kitöltött jelszó miután tudtunk róla, hogy más profiljába bele lehet nézni hiba esetén.

Három kritikus biztonsági hiba. És ebből kettővel viszonylag korán foglalkozott ez a blog is. Miért mentem publikálni ezeket a hibákat azonnal? Mert a felhasználók számára ezek kulcsfontosságú információk. Arra inti ez az információ csomag az összes felhasználót, hogy változtassa meg a jelszavát. Ugyanakkor a gyorsaság a publikálás kapcsán nem jelentett plusz veszélyt, mert bármely hacker ezzel próbálkozna.

Az viszont, hogy lehet kvázi "ingyen" bérletet venni másokat arra is ösztönözhet, hogy ezt elkövessék. 10000 esetből 9999-ben amikor valaki egy friss exploitot azonnal a potenciális támadók rendelkezésére bocsájt, és csak nevet a károkon azt várnám el, hogy az illető börtönbe kerüljön. Ez az eset viszont az a bizonyos 10000. eset volt. A 10000. eset azért különleges mert olyan weboldalt érint amit széles szakmai konszenzus szerint azonnal le kell állítani mind a felhasználók, mind a közvagyon védelmében. 

A T-Systems viszont elég sok mindent tudott ekkorra. A saját adatbázisukban lévő adatok, a logok, az IPk, a fizetési rendszer felől kapott információk, az általuk is megkapott levélben szereplő adatok, a nyilvános jelzések a hibáról. Azaz, ha az incidenst érdemben elemezték tudniuk kellett kivel állnak szemben és mivel. A sajnálkozást tartalmazó tűzoltó közlemény nem más, mint a teljes magyar lakosságot hülyének néző hazudozás. Mondjuk az is hülye aki mást várt az ügyben résztvevőktől. 

De a politika kapcsán már Sztálin is rég tudta: Egy millió ember halála (vagy sérelme) statisztika. Egyetlen ember sorsa viszont olyan tragédia lehet ami sokakat mozgat meg. Ez a 18 éves srác olyan helyzetben cselekszik amikor ő valószínűleg jogszerűen cselekedett. Ha másért nem, mert a másik oldal súlyos jogsértéseit segített fékezni. 

A T-Systems protokollról, belső szabályokról beszél. Tudjuk, egy nemzetközi cégnél vannak ilyenek. Ezeket pedig többnyire minőségbiztosítás során rögzítik és bizony a teljes vezetés jóvá hagyja. Úgy látszik a T-Systems szabályaihoz nem tartozik hozzá a következő lépések egyike sem: 

• Az SSL kapcsán meglévő kritikus sebezhetőség javítása
• Az ismétlődő jelszavakra tekintettel (fokozott veszély) azonnal elismerni a hibát
• Megfelelő tesztelés
• Biztonságos jelszókezelés
• Bemeneti adatok ellenőrzése
• Az eset körülményeinek mérlegelése

De a felsővezetői szintű bosszú és hakni igen. Telekom ügyfeleknek nem árt ezen elgondolkodni. De azon sem, ha mondjuk egy bank ott van a T-Systems referenciái között és a T-systems esetében ilyenek a protokollok akkor akarunk-e az adott bankban pénzt tartani. De áruházak és más esetében is "akarjuk-e hogy bármi adatunk olyan helyen legyen amihez a T- csoportnak köze van?" Ha az érintettek durván eltértek a cég elvárásairól és ennyire szégyent hoztak a cégre számukra akkor sem lehet sok jövő ebben a szakmában...