Ez a blog elsősorban informatikai biztonsággal, és annak különböző területeivel (PKI-vel, kriptográfiával, intelligens kártyákkal, biztonsági kockázatokkal, hibákkal, vírusokkal stb.) foglalkozik, de néha mindenféle másról is írok, amiről csak kedvem tartja.

Ez egy személyes blog, amiket leírok benne, az nem feltétlenül egyezik meg a munkahelyem hivatalos véleményével. Az ezen az oldalon lévő szöveg, tartalom az én alkotásom (kivéve, ahol külön jelölöm, hogy nem), de a kifelé mutató linkek mások weblapjaira mutatnak, amelyek mások alkotásai, így mások véleményét, álláspontját tükrözik. Az blogban a jelen weboldalon szereplő tartalom a forrás (a nevem és az URL) egyértelmű megjelölése mellett szabadon felhasználható. Minden más tartalom - különösen publikációim és előadásaim - előzetes írásbeli engedélyemmel használható fel.

Patchelni vagy nem patchelni - ősi kínai bölcsesség 2010-07-30

"Ősi kínai bölcsesség", méghozzá Marcus Ranum tollából, amelyben Szun Ce, a Háború Művészete írója szájából hangzik el, hogy az informatikai rendszerek vég nélküli patch-elése vesztes csata. Aki pedig folyamatosan vesztes csatákat vív, az bizony: vagy eleve kudarcra ítélt háborút vív, így ne lepődjön meg, ha veszít, vagy nem a megfelelő csatákat vívja, vagy egyszerűen csak hülye. Egyre több jel mutat arra, hogy a vég nélküli patch-elés nem működik. Túl sok patch jelenik meg (ma szinte minden szoftvergyártó folyamatosan frissíti a termékeit), túl gyorsan kellene telepíteni őket, és túl gyakran omlanak össze rendszerek az újonnan telepített patch-ek miatt. Telepítés előtt gondosan tesztelni kell a patch-eket, hogy nem rontanak-e el valamit, a rengeteg patch gondos kitesztelése elképesztő mennyiségű erőforrást emésztene. Így túl sok rendszert törnek fel azért, mert azok nincsenek megfelelően patch-elve... Ez mind igaz, de tud ma valaki jobb megoldást?

Comodo vs Verisign 2010-06-28

A Comodo nevű hitelesítés szolgáltató honlapján megjelent hír szerint a Comodo súlyos hibát talált a Verisign tanúsítvány-kibocsátási eljárásában, és e hibát jelezte a Verisignnak. A Verisigntól Tim Callan az SSL Blogjában reagált, miszerint szerinte egyáltalán nincs szó súlyos hibáról, a Comodo apróságot talált, amit azóta javítottak. A megjelent hírekből annyit állapítottam meg, hogy a Comodo a Google keresések segítségével megtalált a Verisign oldalán egy olyan speciális tanúsítvány-igénylő lapot, ahol egy nagy bank küldi be az igényléseit. Ez egy dedikált, nem nyilvános igénylő oldal, amit csak ez a bank használ, de úgy értettem, az oldal még egy jelszót is kér. Ha ez igaz, akkor ha a Verisign korrektül jár el a tanúsítvány kibocsátása során, és az oldalt védő jelszó erős, akkor ez egy kellemetlen, de nem jelentős biztonsági probléma. A Comodo az utóbbi időben nagyon megerősödött, aggresszív marketing stratégiával nyomul a piacon. Például, sok biztonsági szoftvert - tűzfalat, vírusölőt - teljesen ingyenesen ad, ezzel csinál reklámot a tanúsítványainak. Lényeges, hogy a hitelesítés szolgáltatók gondosan járjanak el a tanúsítvány-kibocsátások során, különben minden Internet felhasználót veszélyeztetnek. A sebezhetőség nyilvánosságra hozatala során a Comodo a Common Computing Security Standards Forum (CCSS) ajánlásait követte, és egy független harmadik felet kért fel közvetítőnek. Igaz, a hiba jelzését követően alig néhány nappal már a honlapjunkon is közzétették a hírt, így az eljárásuk aligha tekinthető barátságosnak. Nem ismervén a sebezhetőség pontos részleteit, én mindezt egyelőre a Comodo marketing stratégiája részének tartom. Ui: Korábban egy Comodo-partner eljárásában derült fény hibára, amelynek következtében a Comodo ellenőrzés nélkül bocsátott ki SSL tanúsítványt. Az valóban csúnya ügy volt.

Firefox sync 2010-06-23

A Firefox sync egy plugin a Mozilla Firefox böngészőhöz, amellyel a Firefoxok könyvjelzőit szinkronizálhatjuk. Ha az egyik gépen felveszek egy weboldalt a Firefoxban a könyvjelzők közé, a Firefox sync segítségével a többi gépen lévő Firefoxban is automatikusan elérhető lesz az új könyvjelző. A Firefox sync úgy működik, hogy egy központi szerverrel - alapesetben a Mozilla szerverével - szinkronizálja a gépek könyvjelzőit. Érdekessége, hogy a könyvjelzőket kliens oldalon titkosítja egy jelmondat (passphrase) alapján, így a szinkronizáláshoz használt központi szerver nem tudja meg, hogy milyen könyvjelzőink vannak. (A szerver eléréséhez így három dolgot kell beállítanunk: felhasználónevet, jelszót és a könyvjelzők titkosításához használt jelmondatot.) Több könyvjelző-szinkronizáló alkamazást megnéztem és kipróbáltam (az Opera például alapértelmezetten rendelkezik ilyen funkcióval), a Firefox sync a kliens oldali titkosítás miatt tetszett meg.

A Symantec megveszi a Verisignt 2010-06-05

A Symantec megveszi a Verisignt. A Verisign márkanév is meg fog szűnni.

Piroska és a farkas meséje 2010-05-16

Bruce Schneier minden év április 1-én kiír egy pályázatot "Movie-Plot Security Contest" címmel. Az idei feladatkiírás szerint olyan mesét (állatmesét, tündérmesét) kellet írni, amely a félelem magjait ülteti el az olvasóban/hallgatóban, és ezzel egy képzeletbeli elnyomó rezsim hatalmát támasztja alá. Idén én is indultam, Piroska és a farkas meséjének egy orwelli világban elmondott változatával neveztem. Schneier kiválasztotta a legjobb öt mesét, az én mesém is szerepel a legjobb öt között. Közülük a blog olvasói választják ki az első helyezettet, méghozzá szavazással. A bloghoz fűzött hozzászólásokban lehet szavazni, május végéig. Szavazzatok rám! ;) 2010-06-28: Köszönöm szépen a szavazatokat! Valószínűleg én lettem a második.

Parancssor futtatása PDF-ből 2010-05-08

Ez az oldal bemutatja, hogy létre lehet hozni olyan speciális PDF fájlt, amelyet megjelenítve egy parancssort is lefuttatunk a gépen. A szerző állítása szerint nem a PDF megjelenítő implementációs hibáját használta ki, hanem egy PDF nyelvi elemet használt kreatívan. Az Acrobat Reader futtatás előtt megkérdezi, hogy futtathatja-e az adott parancssort. (Ha a támadó ügyes, a felhasználó a parancssorban megjelenő értelmes szöveget is a kérdés résznének tekinti.) A Foxit Reader viszont kérdés nélkül futtatott. (A Foxitet azóta frissítették, a legfrissebb Foxit már szintén kérdez.) Itt egy zip fájl, benne egy PDF, amin ki lehet próbálni a támadást. Csak egy cmd.exe-t futtat le, paraméterek nélkül, azaz egy shell ablakot nyit. A szerző szerint az a legnagyobb baj, hogy nem lehet kikapcsolni a megjelenítők ezen funkcióját, így mindenképpen megkérdezi a felhasználót a PDF megjelenítő. Ezt a funkciót valószínűleg alapértelmezetten le kellene tiltani. A rosszindulatú programok általában a legelterjedtebb szoftvereket (és azok implementációs hibáit) célozzák meg. Ezért, ha a kevésbé elterjedt szoftvert használjuk (pl. Windows helyett Linux, Explorer helyett Firefox vagy Opera), gyakran eleve immunissá válunk a legtöbb rosszindulatú kódra. Ez az eset érdekes példa arra, hogy ez sem mindig igaz. Itt nem implementációs hibáról volt szó, és az Acrobat jobban kezelte e trükköt, mint a kevésbé elterjedt Foxit.

Mennyire erős az AES-256? 2010-05-08

Korábban írtam egy támadásról, amely 2^119 lépésből töri a 256 bites AES kulcsot (az elvi határ, a 2^256 lépés helyett). Akkor azt írtam, hogy "egyes vélekedések szerint a 128 bites AES most épp "erősebb", mint a 256 bites", de azt is írtam, hogy összetett problémáról van szó. Ez az oldal e kérdést magyarázza el: Az AES-256 elleni új támadást nem minden esetben lehet kivitelezni. Csak akkor működik, ha az AES-t bizonyos módon használják, és megfelelő mennyiségű (a támadó által választott) nyílt szöveg - rejtett szöveg párra van szükség hozzá. Az AES-256 elleni új támadás kivitelezéséhez nagyon nagy (2^119-nel arányos) tárterület szükséges, és ez jelentős nehézséget jelent. (Míg az AES-128 elleni "brute force" támadásnak nincs jelentős tárigénye.) Akár 128 bites, akár 256 bites kulccsal használjuk az AES-t, az ma biztonságosnak tekinthető. Ma nem lehet reálisan végrehajtani sem a 2^256, sem a 2^128, sem a 2^119 lépést igénylő támadást.

SSL lehallgatása? 2010-04-15

E cikk egy SSL lehallgatására alkalmas támadást ír le. A támadás arra épül, hogy a kapcsolatot lehallgatni kívánó ország kötelez egy hitelesítés szolgáltatót (bármelyik hitelesítés szolgáltatót azok közül, amelyekben a felhasználó vagy az ő alkalmazása megbízik) egy csaló tanúsítvány kibocsátására. Amikor a felhasználó az X weboldallal szeretne https kapcsolatot kiépíteni, a kapcsolatot lehallgatni kívánó ország kormányzata, titkosszolgálata "szerez" magának egy csaló tanúsítványt az X weboldal címére, megszemélyesíti az X weboldalt, majd a felhasználó kéréseit továbbítja a weboldalnak, a weboldal válaszait pedig visszaküldi a felhasználónak (azaz ún. man-in-the-middle támadást hajt végre). Egy kormányzat esetleg kötelezhet egy hitelesítés szolgáltatót egy ilyen tanúsítvány kibocsátására, bár ha egy hitelesítés szolgáltató részt vesz egy ilyen műveletben azzal az egzisztenciáját kockáztatja, végképp elveszhet benne a bizalom. Webszerver tanúsítvány kibocsátása előtt egy hitelesítés szolgáltatónak ellenőrznie kell, hogy az igénylő valóban kontrollálja-e azon domaint (vagy domaineket), amelyre a tanúsítványt igényli. Rengeteg hitelesítés szolgáltató létezik, és sok alkalmazás (pl. Internet Explorer, Mozilla) nagyon-nagyon sok szolgáltató gyökértanúsítványát elfogadja. Elég egyetlen együttműködő szolgáltatót találni, az alkalmazás összes felhasználója támadhatóvá válik. A cikk egyik fő érve arra épül, hogy létezik olyan, kormányzatok számára hirdetett berendezés, amely a fenti támadás kivitelezésére szolgál. A cikk alapján megjelenő egyes sajtóhírek egyenesen azt sugallják, az SSL nem sokat ér, mert egyes kormányzatok - hitelesítés szolgáltatókkal együttműködve - le tudják hallgatni az SSL kapcsolatokat, és le is hallgatják őket. (Az alapcikk nem állít ilyet, sokkal visszafogottabban fogalmaz, és mutat néhány tippet és trükköt is az ilyen lehallgatások felfedésére.) A következő a véleményem ezzel kapcsolatban: 1. A támadás technikailag természetesen kivitelezhető. Már régóta léteznek megoldások, amelyek ehhez hasonló módon teszik lehetővé, hogy egy szervezet/vállalat szűrhesse a tűzfalrendszerén átmenő titkosított forgalmat, vagy monitorozza a titkosított csatornán történő rendszergazdai belépéseket (pl. SSH). Sok szervezet használ ilyen technológiát, például azért, hogy a felhasználóik ne töltsenek le vírusokat SSL-en keresztül. Ez egy teljesen korrekt, "fehér" megoldás, ha az érintett felhasználók is tudnak róla. 2. Vannak országok, amelyek masszívan korlátozzák vagy figyelik saját állampolgáraik Internet-használatát. 3. Nem tartom valószínűnek, hogy szabad országok állampolgárait ilyen módon titokban, tömegesen figyeljék. A csaló tanúsítvány ekkor ugyanis lekerül a megfigyelt felhasználó számítógépére. Ha a megfigyelt felhasználónak feltűnik, hogy az oldalnak nem olyan tanúsítványa van, amint amilyen szokott lenni (pl. a paypal.com tanúsítványát a csalafinsztáni állami CA bocsátotta ki), akkor a megfigyelő nagyon csúnyán lebukik, és nemigen tudja kimagyarázni magát - sem ő, sem a CA. A megfigyelt aláírt bizonyítékhoz jut a megfigyelésről, és világraszóló botrányt csaphat. Az alkalmazások kidobják a tanúsítványtárukból a csaló tanúsítványokat kibocsátó szolgáltatókat. Időközben Schneier blogjában is megjelent e hír. Én nem érzem ezt akkora nagy durranásnak, mint amekkora felhajtás van körülötte.

Hogyan használhatunk elektronikusan aláírt okiratokat? 2010-04-15

Az origo.hu oldalon megjelent cikk.

ATV, elektronikus számlázás 2010-03-27

2010. március 11-én az ATV "Jam" című műsorában beszéltem az elektronikus számlázás előnyeiről.

Computerworld interjú 2010-03-19

Az e heti (2010. március 16-án megjelent) Computerworld újságban szerepel egy "Szűk keresztmetszet" című cikk, amely egy velem készült interjú alapján készült. Arról beszéltem, hogy hitelességet zárt rendszerrel is, és kriptográfiai eszközökkel is lehet biztosítani, és e két lehetőséget hasonlítottam össze. Az interjú az Ügyfélkapu körüli események kapcsán készült.

Támadás chipes bankkártyák ellen 2010-03-07

A közelmúltban a cambridge-i egyetem kutatói egy támadást publikáltak a bankkártyás fizetéseknél használt EMV (Europay-Mastercard-Visa) protokoll ellen. A támadó beépül a terminál és a kártya közé, a terminállal azt hiteti el, hogy PIN kódos tranzakció indul, míg a kártya úgy tudja, hogy a felhasználó (kézzel írott) aláírással hitelesítette a tranzakciót. A kártya így nem kér PIN kódot, a banki rendszer naplói szerint viszont PIN kódos tranzakció történt. A támadó (pl. egy csaló kereskedővel együttműködve) így le tudja emelni a felhasználó számlájáról a pénzt, és a bank naplóiban az fog szerepelni, hogy PIN-es tranzakció történt, vagyis a tranzakciót jóváhagyó személy ismerte a kártya PIN kódját. (Ezért a kereskedő minden gyanú felett áll, a bank pedig nem fizet kártérítést.) A szerzők állítása szerint teljesen megtörték a chipes bankkártyákat. A támadást részleteit leíró teljes cikk itt érhető el. A cikk szerzői közül Ross Anderson a legismertebb név, ő pl. a Security Engineering című könyv szerzője. A könyv letölthető Ross Anderson honlapjáról. (Az első kiadása teljes egészében, a második kiadásból csak néhány fejezet.)

NSA ajánlás kriptográfiai algoritmusokról (2009. november) 2010-03-07

Ez az NSA által kibocsátott, kriptográfiai algoritmusokra vonatkozó ajánlás 2009. novemberében jelent meg. Két biztonsági szintet különböztet meg: 1. SECRET szinten legalább 128 bites szimmetrikus kulcs (AES-128), 256 bites blokkméretű hash függvény (SHA-256) és legalább 256 bites kulccsal működő elliptikus görbékre épülő kriptográfiai (ECC) algoritmus (ECDH, ECDSA) használható. 2. TOP SECRET szinten legalább 256 bites szimmetrikus kulcs (AES-256), 384 bites blokkméretű hash függvény (SHA-384) és legalább 384 bites kulccsal működő ECC (ECDH, ECDSA) használható. Az RSA-val kapcsolatban csak egy megjegyzés szerepel: SECRET szinten, az ECC-re való teljes áttérésig még szabad RSA-t használni, 2048 bites kulccsal.

Elektronikus kézbesítés III 2009-12-22

Újabb cikk jelent meg az Origo.hu-n az e-tértivevény törvényről, ezúttal én mondom el a véleményemet a témával kapcsolatban.

Megfelelés a szabályozásnak =/= biztonság 2009-12-13

Cikk arról, hogy gyakran összekeverik a szabályozásnak való megfelelést a biztonsággal. A szerző szerint az, ha egy rendszer megfelel egy biztonsági követelményrendszernek, az még önmagában nem jelent biztonságot, ez csak az első lépés a biztonság felé.

SSL renegotiation hiba 2009-12-08

Hibát találtak az SSL protokollban. Az SSL (újabb nevén TLS) protokoll segítségével két fél - egy kliens és egy szerver - nyilvános kulcsú kriptográfiai algoritmusok segítségével meggyőződhetnek egymás kilétéről, majd közös szimmetrikus kulcsokban állapodhatnak meg, és e szimmetrikus kulcsok segítségével biztonságos - titkosított és hitelesített - csatornát hozhatnak létre, majd e csatornán titkosan és hitelesen kommunikálhatnak egymással. A protokoll egyik gyakran használt változata, amikor csak a szerver rendelkezik tanúsítvánnyal, így csak a kliens győződik meg a szerver kilétéről, de a protokoll úgy is működhet, hogy mind a kliens, mind a szerver bemutatja tanúsítványát, és kölcsönösen authentikálják egymást. Az SSL kapcsolat felépítésekor lefolytatott kulcsegyeztetést (itt nemcsak kulcsokat, de pl. kriptográfiai algoritmuskészleteket is egyeztetnek egymással) később is megismételhetik résztvevők, ez az ún. renegotiation. Ez történhet azért, hogy lecseréljék a régen használt kulcsokat, azért, hogy erősebb kriptográfiai algoritmusokra térjenek át, vagy azért, hogy anonim SSL kapcsolatról (amikor csak a szerver mutatja be a tanúsítványát) kétirányú authentikációra váltsanak (amikor mindkét félnek van tanúsítványa), vagy vissza. A probléma ezen regnegotiation lehetőséggel kapcsolatos. Az SSL protokoll nem biztosítja, hogy renegotiation előtt és után ugyanazon felek vesznek részt a kommunikációban. Így például előfordulhat a következő támadás: A támadó anonim SSL kapcsolatot létesít egy webszerverrel, majd elküld neki egy kérést, amihez már authentikációra van szükség. A szerver ezért renegotiation-t kezedményez, és elkéri a kliens tanúsítványát. A támadó ekkor egy olyan legális klienssl köti össze a webszervert (ún. man-in-the-middle támadással), aki rendelkezik megfelelő authentikációs tanúsítvánnyal, és épp hozzá akarna kapcsolódni a webszerverhez. A szerver és a legális kliens elvégzik a renegotiationt, kulcsot cserélnek egymás tanúsítványai alapján, és innentől kezdve a támadó már nem lát bele a köztük lévő kapcsolatba. A problémát az jelenti, hogy a szerver az egészből annyit lát, hogy küldtek neki egy kérést, ő authentikációt kért, és az authentikáció sikeres volt, így végrehajthatja a kérést. Ez annyit jelent, hogy a támadó - aki nem rendelkezik megfelelő authentikációs tanúsítvánnyal - be tud szúrni egy legális kliens authentikált SSL kapcsolata elejére valahány byte-ot. A fenti egy webes támadás, amely kliens oldali authentikációs tanúsítványokra épül. A probléma ennél tágabb, nemcsak a kliens oldali authentikációs tanúsítványok esetén, és nemcsak webes környezetben merül fel. A hiba magában az SSL protokollban van, nem pedig valamelyik implementációban, így elvileg minden SSL-t használó szerver érintett lehet. A megjelenő patch-ek úgy orvosolják a problémát, hogy megszüntetik a renegotiation lehetőséget az adott alkalmazásban. (Ez persze jelentheti azt, hogy a patch-elt webszerverekkel egyes weboldalak már nem működhetnek ugyanúgy, mint korábban.) A probléma állítólag augusztus óta ismert, csendben dolgoztak a kijavításán, de novemberben nyilvánosságra került az ügy. A hibát igazán az fogja megoldani, ha az SSL (TLS) protokollt javítják ki. Az IETF megjelentetett már egy Internet-Draftot, ami szerint kriptográfiailag hozzá lehetne kapcsolni a renegotiation-t az adott SSL (TLS) kapcsolathoz.

Kritika az e-tértivevény törvényről 2009-12-08

Érdekes kritika jelent meg az Origo.hu-n az e-tértivevény törvényről. A cikk két részből áll, az Ormós Ügyvédi Iroda szakértői készítették.

Texas Instruments kulcsok törése 2009-11-16

Történet arról, hogy valaki rövid, 512 bites (RSA), aláíró kulcsokat használt, telt-múlt az idő, és nem cserélte őket hosszabbra, és egyszer csak megtörték őket. Még csak nem is haszonszerzési céllal törték fel a kulcsokat: e kulcsok csupán Texas Instruments számológépek oprendszer frissítéseit hitelesítették. (Így - mivel a kulcsokat nyilvánosságra hozták - mostantól elvileg bárki aláírhatna olyan oprendszer frissítést, amelyet aztán bizonyos TI számológépek "gyári" frissítésnek fogadnának el.) Tudtommal ezek az első "éles" 512 bites RSA kulcsok, amelyeket kimerítő kereséssel találtak meg.

Újabb PKI tanfolyam 2009-08-30

Az előző PKI tanfolyam nagy sikerére való tekintettel, szeptemberben ismét indul a PKI tanfolyam a BME Mérnöktovábbképző Intézet szervezésében.

Klubrádió interjú 2009-08-30

Augusztus 6-án beszéltem a Klubrádióban az elektronikus aláírásról. Itt érhető el, hogy mit mondtam.

Támadások az AES-256 ellen 2009-08-26

A közelmúltban több támadás is megjelent az AES ellen. Mindkettő az AES-256 bites kulcsú változata (illetve 256 bites kulcsú változat egyes variánsai) ellen irányul. Az AES (Advanced Encryption Standard) egy szimmetrikus kulcsú titkosító algoritmus. Az NIST 1997-ben pályázatot írt ki az addigra már elavult DES kiváltására. A pályázaton a Rijndael algoritmus nyert, amely 2001 óta az AES nevet is viseli. Az AES blokkrejtjelező, amely 128 bites blokkmérettel dolgozik, de a kulcs mérete lehet 128, 192 és 256 bit is. Az AES úgy nevezett "fordulókból" (round) áll, 128 bites kulcs esetén 10-szer, 192 bites kulcs esetén 12-szer, 256 bites kulcs esetén 14-szer végzi el egymás után ugyanazon műveleteket. (E műveletek: byte-ok lecserélése helyettesítéssel /substitution/, byte-ok felcserélése egymással /permutation/, és végül mod2 hozzáadja az eredményhez az adott fordulóhoz generált forduló-kulcsot.) Ez az ábra nagy vonalakban mutatja be az AES lépéseit, ez a flash animáció pedig részletesen szemléltei, hogy mikor mi történik. Biryukov és Khovratovich támadása 2^119 lépésből "töri" az AES-256-ot (2^256 lépés helyett). A szerzők súlyos gyenge pontot találtak az algoritmuson, de a 2^119 lépés még mindig túl sok, e támadás még nem kivitelezhető. (E cikk emellett az AES-192 ellen is mutat támadást, amely 2^123 lépést igényel.) Biryukov, Dunkelman, Keller, Khovratovich és Shamir támadása nem a gyakorlatban is használt, teljes AES-256, hanem annak egyszerűsített változatai ellen szól. Az egyszerűsítés annyiból áll, hogy olyan AES-256-variáns ellen működik, amely a teljes AES-256-nál kevesebb fordulóból épül fel. A szerzők támadásokat mutattak - a 9 fordulóból álló AES-256 ellen 2^39 lépésből (azaz ízekre szedték), - a 10 fordulóból álló AES-256 ellen 2^45 lépésből (szintén ízekre szedték), - a 11 fordulóból álló AES-256 ellen 2^70 lépésből (akár még ez is megvalósítható lehet) (Az igazi AES-256 14 fordulóból áll, a legjobb támadás ellene továbbra is 2^119 lépést igényel.) Érdekes, hogy pont a leghosszabb, 256 bites kulcsú AES ellen jelentek meg a legsúlyosabb támadások. Állítólag, a 256 bites változat kulcsütemezője (ami a forduló-kulcsokat számítja) a "gyenge", így ezek a támadások nem működnek a 128 bites változat ellen. Így egyes vélekedések szerint a 128 bites AES most épp "erősebb", mint a 256 bites. (Bár ez egy nagyon összetett kérdés, mert ha pl. egy SSL kapcsolatot szeretnénk támadni, nem biztos, hogy teljesülnek a támadásokhoz szükséges feltételek.) Bár e támadások jelentős eredmények, de az AES-256 továbbra is biztonságosnak tekinthető. (Az előbbi támadás még nem kivitelezhető reális időn belül, a második pedig nem a gyakorlatban is használt, teljes AES ellen irányul.)

Újabb támadás az SHA-1 ellen 2009-06-13

Az SHA-1 elleni első sikeres támadás 2005-ben jelent meg. Eszerint 2^69 lépésben található két olyan őskép, amelyekhez azonos SHA-1 lenyomat tartozik. Az új támadás már 2^52 lépésben talál ütközést. (Összehasonlításképpen, egy 2^56 lépésben törhető DES kulcs, ma már nem számít biztonságosnak.) A gyakorlatban is használható támadásokat - mint pl. az MD5 elleni támadás, amiről korábban írtam - elsősorban akkor lehet majd véghezvinni, ha majd értelmes, ütköző lenyomatú ősképeket is lehet találni. Ennek ellenére várható, hogy hamarosan meg kell majd szüntetni az SHA-1 használatát olyan területenek ahol az ütközés-ellenállóság számít, így pl. elektronikus aláírás esetén. A munkahelyemen kibocsátottunk egy tájékoztatót arról, hogy milyen lépéseket kell elvégezni a meglévő, elektronikus aláírást használó rendszerekben, hogy a rendszer továbbra is biztonságos maradjon - immár SHA-256 alapon.

Krasznay Csaba a kormányzati informatikáról 2009-01-28

Krasznay Csaba az itcafe.hu oldalon megjelent cikkében többek között adatvédelmi, átláthatósági, és információszabadsági szempontból is kritizálja a magyar kormányzati informatikában jelen lévő erős központosítást.

MD5-re épülő tanúsítványok hamisítása 2009-01-12

December 30-án jelent meg egy cikk a következő támadásról: A támadó - egy kutatócsoport, akik támadásukkal egy biztonsági hibára hívták fel a figyelmet - kerestek egy olyan CA-t, amelyiknek a root tanúsítványa széles körben elterjedt, sok böngésző elfogadja, és még mindig bocsát ki olyan tanúsítványokat, amelyek MD5-re épülő aláírásokat tartalmaznak. Generáltak egy kulcspárt, és PKCS#10 tanúsítványkérelem alapján igényeltek és kaptak a CA-tól egy legális végfelhasználói tanúsítványt. Az MD5 hibája miatt speciális PKCS#10-et tudtak konstruálni: A visszakapott legális végfelhasználói tanúsítványon lévő aláírás egyúttal egy másik, csaló tanúsítványhoz is helyes aláírás lett. Így létre tudtak hozni egy csaló CA tanúsítványt (MD5 Collisions Inc. néven) egy saját kulcspárhoz. Innentől, amit e kulcspár magánkulcsával aláírnak, azt a böngészők mind-mind elfogadják... Itt próbálható ki, ennek az oldalnak van tanúsítványa a csaló CA-tól. (A csaló tanúsítványokat - különösen a csaló CA tanúsítványát - úgy bocsátották ki, hogy még véletlenül se fogadja el senki, ezért a weboldal kipróbálásához 2004 augusztusira kell visszaállítani a gép dátumát.) A támadás önmagában véve nem új, az MD5-ről már régóta tudjuk, hogy nem biztonságos (reális mennyiségű erőforrás befektetésével előállítható két különböző őskép, amelyekhez azonos MD5 lenyomat tartozik). Ezen túl, már létezik két olyan tanúsítvány is, amelyhez azonos aláírás tartozik (így aki az egyik tanúsítványhoz aláírást szerez, az egyúttal a másik tanúsítványhoz is szerzett aláírást). A december 30-án bemutatott támadás e korábbi, elméleti támadásnak egy gyakorlati alkalmazása. Az érintett hitelesítés szolgáltató a Verisign tulajdonában van, Tim Callan, a Verisign alelnöke a Securityfocus hasábjain reagál a támadásra. Elismeri a támadást, de a gyakorlati jelentőségét csökkenteni próbálja. Ezen kívül arról ír, hogy a támadás új volt, a kutatók nem léptek velük kapcsolatba, de a szolgáltató mégis nagyon gyorsan elhárította: beszüntette az MD5-re épülő tanúsítványok kibocsátását, és - habár senki nincs veszélyben - ingyen új tanúsítványt ajánlott fel az MD5-re épülő tanúsítványok birtokosainak. Jómagam nem értek egyet azzal, hogy a támadás annyira váratlan lett volna: az MD5 biztonsági hibája már régóta ismert, Magyarországon például már egy ideje tilos MD5-re épülő (elektronikus aláírás létrehozására szolgáló) tanúsítványt kibocsátani. Azzal sem értek egyet, hogy a felsorolt óvintézkedésekkel megoldódna a probléma: az MD5-re épülő tanúsítványok birtokosai legfeljebb a tanúsítvány árát veszítik el, ha a böngészők végre úgy döntenek, hogy elutasítják az MD5-re épülő tanúsítványokat. A böngészőprogramok felhasználói vannak igazán kitéve a veszélynek, mert ők azok, akik automatikusan elfogadnák a hasonló csaló CA-k által kibocsátott tanúsítványokat. Ha a szolgáltató nem bocsát ki MD5-re épülő tanúsítványt, azzal csak azt gátolja meg, hogy esetleg további csaló CA-kat hitelesítsen felül. Esélye sincs annak ellenőrzésére, hogy nem jöttek-e létre más csaló CA-k, így nem sokat tehet ellenük. A támadásban a szolgáltató annyit hibázott, hogy még nem vezette ki a rendszeréből az MD5-öt. Ezt remélhetőleg elősegítik a fentihez hasonló támadások, amelyek kárt nem okoznak, hanem csak felhívják a figyelmet az ismert biztonsági hibákra.

Comodo ügy 2009-01-12

Nagy port kavart fel, amikor a közelmúltban egy Mozilla-aktivista vásárolt egy SSL szerver tanúsítványt a mozilla.com domainre egy nagy nemzetközi hitelesítés szolgáltató, a Comodo egy viszonteladójától. A tanúsítványt ugyanis nem a domain tulajdonosa vásárolta, és az illető egyáltalán nem jogosult a Mozilla címére tanúsítványt igényelni. Állítása szerint semmilyen ellenőrzés nem történt a tanúsítvány kibocsátása során, a Commodo viszonteladó kérdés nélkül kibocsátotta a számára az SSL tanúsítványt. Mindebből azt vonta le, hogy az adott viszonteladó általában így szokott eljárni, és így akár bárki bármilyen domainre igényelhetne SSL tanúsítványt. SSL segítségével a kérdéses webszerver tanúsítványa alapján győződhetünk meg róla, hogy valóban azzal a weboldallal kommunikálunk, amelyikkel szeretnénk. Ha igaz lenne, hogy bárki bármilyen névre/címre igényelhet tanúsítványt, egy támadó bármely oldalt megszemélyesíthetne. A Mozilla komolyan vette az ügyet és megkezdte annak kivizsgálását. A Comodo 25%-ra taksálja saját piaci részesedését az SSL tanúsítványok globális piacán. Így ha a Mozilla drasztikus szankciókat alkalmazna a Comodoval szemben (pl. alapértelmezetten elutasítaná a comodos tanúsítványokat), valószínűleg minden résztvevő rosszul járna: aki comodos tanúsítványt vett, annak egyszer csak nem működik a tanúsítványa Mozilla alatt; a Comodonak nagy veszteségei lennének, mert sokan visszakövetelnék a pénzüket; a Mozilla nem működne egy csomó weboldallal; és a Comodo valószínűleg be is perelné a Mozillát. Számomra kissé elszomorító, hogy úgy tűnik, nem sok eszköz van egy nagy CA-val szemben. Ha szolgáltatók egy adott körét fogadjuk el valamilyen célra (pl. SSL tanúsítványok hitelesítésére), a PKI legfeljebb akkora biztonságot jelenthet, mint a legkisebb biztonsággal működő szolgáltató legkisebb biztonsággal működő viszonteladója. Hibás tanúsítványok, hibás gyakorlatok bármikor előfordulhatnak, kíváncsi vagyok, mi lesz az ügy eredménye. (A Comodo egyébként ingyenes informatikai biztonsági szoftvereket is készít, ezzel is hírverést csapva tanúsítványainak. A napokban próbáltam ki a Comodo Internet Security /tűzfal+vírusölő/ ingyenes változatát, és egyelőre nagyon jók a tapasztalataim.)

PKI oktatás 2008-12-17

A BME Mérnöktovábbképző intézet "Az elektronikus aláírás és a nyilvános kulcsú infrastruktúra (PKI) alapjai" címmel továbbképzést szervez olyan szakemberek részére, akik mélyebben is meg szeretnék ismerni a nyilvános kulcsú infrastruktúra (PKI) területét, valamint az elektronikus aláírás felhasználásának módjait, lehetőségeit. A képzés elsősorban műszaki jellegű, de egyéb (pl. jogi) aspektusaival együttesen közelíti a témakört, és az elektronikus aláírással már kapcsolatban lévő vagy hamarosan kapcsolatba kerülő szakembereket (tanácsadókat, vezetőket, fejlesztőket, üzemeltetőket és rendszergazdákat) célozza meg. A mély elméleti ismeretek mellett a hallgatók - számítógép előtti gyakorlat során - gyakorlati tapasztalatokra is szert tesznek, különösen az elektronikus aláírás "nagyüzemi", szerver oldali felhasználásának területével kapcsolatban. A hallgatók a képzés keretében minősített elektronikus aláírás létrehozására alkalmas tanúsítványt és intelligens kártyát kapnak, gyakorlati feladataik egy részét ezen eszközzel oldják meg a képzés során. Az előadások jelentős részét én tartom. A sikeres vizsgát tett hallgatók részére a BME Mérnöktovábbképző Intézet állít ki igazolást a képzés elvégzéséről. A képzésről további információ a http://www.e-szigno.hu/?lap=pki_oktatas címen érhető el. A képzés hamarosan megjelenik a BME MTI honlapján is. Kiegészítés (2009-01-12): A tanfolyam adatlapja a BME MTI honlapján

Google biztonsági kézikönyv böngészőkről 2008-12-16

A Google kibocsátott egy böngészőkről szóló biztonsági kézikönyvet.

Az Empire State Building ellopása 2008-12-16

Ez a cikk arról ír, hogy amerikai újságírók "ellopták" (a saját nevükre íratták) az Empire State Buildinget. Akciójuk célja a figyelemfelkeltés volt (kb. egy nappal később vissza is íratták az épületet az eredeti tulajdonos nevére), arra hívták fel a figyelmet, hogy az érintett hivatalban egyáltalán nem ellenőrzik a benyújtott dokumentumok hitelességét. E cikk szerint míg az Empire State Building "ellopása" hamar feltűnne, kevésbé nevezetes ingatlanok esetén kevésbé szembetűnő, ha egyszer csak egy csaló nevére kerülnek. A cikk olyan csalókról is ír, akik kölcsönt vesznek fel az így megszerzett ingatlanra, majd megpróbálnak eltűnni a pénzzel.

Internetes támadások a NASA ellen 2008-12-06

Érdekes cikk NASA elleni informatikai támadásokról, ezek felderítéséről, történetéről, eltussolásáról és mindezek következményeiről.

A 2008. december 1-ei órám diái 2008-12-05

A Károli Gáspár Református Egyetemen december 1-én elhangzott előadásom diái itt érhetőek el.

Támadás a WPA ellen 2008-11-18

Ez a cikk a WPA - egy WiFi hálózatokban alkalmazott titkosítási módszer - ellen mutat támadást, amely szerint egy támadó néhány (7-15) csomagot küldhet a WiFi hálózatra. Ugyanakkor, e támadás nem teszi lehetővé a a hálózat titkosításához használt ideiglenes- és mesterkulcsok visszafejtését. A támadás a korábbi, WEP elleni támadás kiterjesztése. Csak a TKIP algoritmus esetén működik, így az AES algoritmussal biztonságosan használható a WPA.

A 2008. november 11-ei BME-s óra diái 2008-11-18

A november 11-ei "A biztonságos elektronikus kereskedelem alapjai" órán elhangzott előadásom diái itt érhetőek el.

Hacktivity 2008 2008-09-25

Sajnos a Hacktivity 2008 konferenciának csak az első napján tudtam ott lenni. Buherátortól hallottam egy különösen emlékezetes előadást. Sokakat hallottam már korábban SQL injection támadásokról beszélni, és a neten is rengeteg érdekes példa található, de számomra ez volt az első olyan előadás, ahol valaki azt is megmutatta, hogy a támadó hogyan gyűjthei össze a támadáshoz szükséges technikai részleteket, hogyan térképezheti fel a megtámadott weboldal mögötti adatbázis struktúrát, honnan ismerheti meg az adatbázis táblák neveit stb. Eddig is tudtam, hogy egy rendszer védelmét nem szabad arra alapozni, hogy a támadó nem ismeri a rendszer felépítését, mégis szíven ütött, hogy ez esetben ez tényleg semmilyen védelmet nem jelent: a támadó - szintén SQL injection támadás segítségével - ezen adatokat is egészen egyszerűen megkérdezheti az adatbázis-kezelőtől. Én a PKI és a phishing kapcsolatáról beszéltem, arról, hogy a PKI mennyiben alkalmazható adathalász támadások kivédésére. Úgy gondolom, az adathalászat elsősorban nem technológiai probléma, és nem hiszem, hogy önmagában - más védelmi intézkedések nélkül - bármilyen technológia megfelelő védelmet nyújthatna ellene. Az előadásom itt érhető el.

A 2008. szeptember 18-ai BME-s óra diái 2008-09-18

A BME-n a "A biztonságos elektronikus kereskedelem alapjai" című tágy mai óráján elhangzott előadásom diái itt érhetőek el.

Orosz hash függvény sebezhetősége 2008-09-18

Egy, a CRYPTO 2008 konferencián megjelent cikk az orosz GOST hash algoritmus ellen mutatott támadást ütköző lenyomatú eltérő ősképek keresésére, amely 2^23-szor (~ 8 milliószor) hatékonyabb, mintha véletlenszerűen próbálkoznánk. A GOST hash függvény 256 bit hosszú lenyomatot képez, így a születésnapi paradoxonra épülő támadás szerint 2^128 véletlenül választott ősképből már legalább 50% valószínűséggel van két olyan, amelyhez azonos lenyomat tartozik. A cikkben szereplő támadáshoz 2^105 lépésre van szükség, ami azt jelenti, hogy a gyakorlatban még nem kivitelezhető. Ugyanakkor, sikerült fogást találni az algoritmuson, és ez komoly eredmény. (A 160 bites blokkmérettel dolgozó SHA-1 elleni támadás, amelyhez 2^69 lépésre van szükség, hiába jelentett "csak" ~2000 szeres (2^11), gyorsulást, már sok helyen elegendő indokot jelentett az algoritmus kivezetésére.) Oroszország saját kriptográfiai algoritmusokat dolgozott ki, ott nem a világ többi részén elterjedt algoritmusokat (RSA, SHA-1 stb) használják. (Van pl. GOST szabvány szerinti blokkrejtjelező is.) Oroszországban sok helyen a GOST algoritmusok használata kötelező.

Google Chrome 2008-09-18

A Google a közelmúltban megjelentetett egy saját, Chrome névre hallgató böngészőt. Egylőre csak béta, és csak Windows alatt működik, de feltehetően hamarosan megjelenik más platformokra is. Igaz, hogy már sok böngésző van, de a Google erősen meghatározó szerepet tölt be a web fejlődésében. Könnyen lehet, hogy a Chrome jelentős szereplő lesz.

SZJA visszaigénylés hamis adóbevallással 2008-09-01

Egy csaló kb. 30 millió forintot igénylet vissza mások nevében beküldött hamis személyi jövedelemadó bevallásokkal. Kb. 250 áldozat nevében küldött be adóbevallást, levelezési címnek postafiókot adott meg, a pénzt pedig hajléktalanok nevében nyitott bankszámlákra kérte. Az egyes áldozatok nevében csak kisebb összegeket igényelt vissza, hogy az APEH-nek ne tűnjön fel a kiugróan nagy visszaigénylés. A cikkek szerint az APEH-nek az tűnt fel, hogy egyesektől több adóbevallás is érkezett, ez alapján járt utána a hatóság az ügynek. Sikerült felvennie a kapcsolatot az áldozatokkal, akik a két bevallás közül csak az egyik aláírását ismerték el sajátjuknak. A csalónak kb. 19 millió forintot sikerült felvennie, a feltehetően pénzfelvételkor kaphatták el. Az áldozatok ugyanazon a munkahelyen dolgoztak, így könnyen lehet, hogy a csaló az ottani nyilvántartásból jutott hozzá az adataikhoz. Látható, hogy az emberek személyes adatai sok helyen megvannak, nem szerencsés, ha önmagában a személyes adatokkal érdemi visszaélést lehet elkövetni. A támadás alapvetően azt használta ki, hogy az APEH az adóbevallás befogadásakor alig-alig tudja ellenőrizni a bevallás hitelességét. A bevallásban szereplő adatokon kívül (amelyeket esetünkben a csaló elég jól tudott hamisítani), csupán azt tudja megvizsgálni, hogy a bevalláson van-e - kézzel írott - aláírás. Úgy vélem, ehhez képest csekély előrelépés a most használt, felhasználónév-jelszó alapon beadott adóbevallás. Most felhasználónevek és jelszavak ügyes, social engineering alapú összegyűjtésével lehetne talán kivitelezni egy nagyon hasonló támadást, ahol még az aláírások alapján sem lehet rendet tenni. Az adóbevallást olyan példaként szokták emlegetni, ahol érzékeny adatok mozognak ugyan, de nem sok értelme van valaki más nevében adóbevallást beadni, így nemigen van lehetőség a visszaélésre. Ez az eset jó példa rá, hogy bizony, még az adóbevallással is történnek visszaélések, vannak csalások. A csalót nem vették volna észre, ha a hamis adóbevallások beküldése mellett az áldozatok igazi adóbevallását is el tudta volna téríteni (vagy pl. el tudta volna hitetni az APEH-hel, hogy a csaló adóbevallás az igazi adóbevallás korrekciója). Így is csak azért kapták el, mert nem hagyta abba elég hamar a pénzfelvételt. Tekinthetjük ezt egy elszigetelt esetnek, de az is felmerülhet bennünk, hogy vajon hány olyan eset van, ahol nem kapják el a csalót, és esetleg fény sem derül a bűntényre.

e-Szignó tudásbázis 2008-08-10

Az utóbbi időben keveset bloggoltam, mert az e-szigno.hu oldalon lévő e-szignó tudásbázisba írtam elektronikus aláírásól és PKI-ről szóló ismeretterjesztő anyagokat. Ezek a dokumentumok a http://www.e-szigno.hu/?lap=tudasbazis címen érhetőek el.

Hol tart a hazai védekezés a DNS hibával szemben? 2008-08-10

A BME Crysys labor kutatói megvizsgálták, hogy egy hónappal a hibajavítások megjelenése után mennyire maradtak sérülékenyek a magyar szerverek a Kaminsky-féle DNS támadással szemben. Megállapításaik szerint a nagy Internet szolgáltatók frissítették a DNS-eiket, de a megvizsgált hazai DNS szerverek nagy része továbbra is sebezhető e hibával szemben. A részletes eredmények itt érhetőek el.

DNS hiba 2008-07-16

A közelmúltban nagy port vert fel a DNS protokoll egy hibája. (A DNS az Internet egyik alapvető szolgáltatása, amely a szerverek szöveges címét - pl. - IP címmé fordítható le.) A hiba azt tette lehetővé, hogy egy külső, azonosítatlan támadó megmérgezhette a DNS cache-t, azaz elhitethette a DNS-sel, hogy egy adott domain egy csaló IP címhez tartozik, és így a DNS ezen csaló IP címet terjesztette. Nem implementációs hibáról, hanem elvi hibáról van szó, amely így (szinte) minden DNS implementációt érintett. Sok nagy gyártó összahangoltan összehangoltan, egyszerre jelentette meg a hibát kiküszöbölő frissítéseit. A hibát Dan Kaminsky fedezte fel. A DNS-t még a nyolcvanas években találták ki; meglepő, hogy ennyire régi protokollokban is még mindig lehet találni ilyen súlyos hibákat.

A közfeladatot ellátó szervek egységes iratkezelése 2008-07-16

Az Intelligens Települések Országos Szövetsége és az e-Írástudásért Alapítvány megjelentettek egy kiadványt A közfeladatot ellátó szervek egységes iratkezelése címmel. A kiadvány elektronikus aláírásról szóló fejezetét Barsi András kollégámmal közösen írtuk. A kiadvány papíron és elektronikusan is megjelent, az elektronikus változat itt érhető el.

PKI: egy ember - egy tanúsítvány? 2008-03-31

A Networkshop 2008 konferencián hangzott el "PKI: egy ember - egy tanúsítvány?" című, Endrődi Csilla kolléganőmmel közös előadásunk. Az előadáshoz tartozó cikk itt, az előadáshoz tartozó diák itt érhetőek el.

"Kijózanító" cikk a kvantumszámítógépekről 2008-03-27

A kvantumszámítógépek merőben más elvek szerint működnek, mint a ma használt számítógépek, így kvantumszámítógépek segítségével ma nehéznek tartott algoritmikus problémák is hatékonyan megoldhatóak lehetnének. Például, az RSA nevű nyilvános kulcsú kriptográfiai algoritmus biztonsága azon alapszik, hogy ma nem ismert hatékony algoritmus nagy egész számok prímtényezőkre bontására. Kvantumszámítógépek segítségével e probléma hatékonyan megoldható lenne, de a kvantumszámítógépek még gyermekcipőben járnak. Ezt a kérdéskört vizsgálja ez a blogbejegyzés. Megnézi, hogy ma hány bites számot tudnak kvantumszámítógéppel faktorizálni (a cikk szerint 4 bites számnál tartanak), feltételezi, hogy a kvantumszámítógépek teljesítménye is a Moore törvényhez szerint robbanásszerűen fog növekedni, és ez alapján azt becsüli, hogy még vagy 45 év kell, amíg a 4096 bites RSA is törhető lesz kvantumszámítógép segítségével. Ha kicsit is helyes a becslése, még jó ideig nem kell félnünk attól, hogy kvantumszámítógép segítségvel törik fel a kulcsainkat. Érdekes a cikknek azon megjegyzése is, amikor a www.keylength.com oldalra hivatkozva azt állítja, hogy a ilyen időtávolságban a hagyományos számítógépekkel is törhető lehet a 4096 bites RSA. (Megjegyzés: Ebben a témakörben nagyon-nagyon nehéz kicsit is pontos becsléseket tenni.) A cikk arra a következtetésre jut, hogy a kvantumszámítógépek körül nagyobb a felhajtás, mint amekkora a jelentőségük. 2008-03-31 kiegészítés: A kvantumszámítógépek működéséhez nem értek, e cikk megközelítési módját tartottam érdekesnek, azért hivatkoztam meg. Nem tudom, mennyiben helytálló, ami benne szerepel.

Online játékok biztonsági kérdései 2007-12-23

Riport Gary McGraw-val az online játékok biztonságáról. Elsősorban olyan sokszereplős online (szerep)játékok biztonsági kérdéseit tárgyalja, amelyekhez dedikált kliensprogram szükséges. A riport konkrétan a World of Warcraft-tal foglalkozik. Az ilyen játékokhoz óriási virtuális világ tartozik, és e hatalmas világ minden egyes csücske (állapota) nem a központi szerveken van, hanem a felhasználók számítógépein. A cikk szerint a World of Warcraftnak kb. tízmillió előfizetője van, akik elvileg akár egyszerre is beléphetnének (a gyakorlatban egyszerre jóval kevesebben játszanak), és kizárólag központi szerverekkel nem lehet ekkora közösséget kiszolgálni. Az ilyen játékokban ezért olyam megoldásokat használnak, hogy a világ nagy része a klienseken fut, a központi szerverek pedig a közvetítik, szinkronizálják az eseményeket a kliensek között, hogy a virtuális világ konzisztens maradjon. A riport arra a problémára mutat rá, hogy a kliensek nem megbízhatóak, a felhasználók manipulálhatják a klienseiket, és elérhetik, hogy olyasmi történjen, amit a világ szabályai nem engednének meg. (Így a virtuáls világban különleges képességekre vagy vagyonra tehetnek szert, majd - a gyakorlat ezt mutatja - a virtuális világban szerzett vagyont a valós világban valós pénzért értékesítik.) Elterjedt megoldás, hogy a játék mellett egy másik, a kliensgépet figyelő program települ fel a felhasználó számítógépépre, és e program jelzi a központnak, ha a felhasználó csalni próbál. McGraw szerint ez rossz megoldás, mert ahogy a csaló magát a játékot manipulálhatja, ugyanúgy manipulálhatja az őt figyelő programot (hiszen az is az ő számítógépén fut). A fejlesztőknek fel kell tételezniük, hogy a klienseken futó kód manipulált, így a kliensről szártmazó adat nem megbízható. McGraw szerint az olyan védelmi intézkedéseknek van létjogosultsága, amelyek a kliensekről származó adatokat ellenőrzik. Szerinte nem lehet mindent ellenőrizni, a fejlesztőnek azt kell jól eltalálnia, hogy mely információk ellenőrzésével lehet kiszűrni a csalásokat.

BME előadás a PKI gyakorlati problémáiról 2007-10-16

A BME-n A biztonságos elektronikus kereskedelem alapjai című tárgy óráján ma elhangzott előadásom diái innen tölhetőek le.

Storm féreg 2007-10-11

Bruce Schneier Storm nevű féregről szóló írása szerint míg a klasszikus vírusokat, férgeket, trójaiakat, rosszindulatú programokat (e területek manapság egyre inkább összemosódnak) készítőik hírnévért írták, a maiakat profi bűnözők készítik, tisztán nyereségvágyból. (Krasznay Csaba az idei Hacktivity konferencián elhangzott előadásában is az internetes profi bűnözéssel - elsősorban spammel és phisinggel - foglalkozott, és megtudtuk, hogy ezekből egyesek nagyon-nagyon jól élnek.) A Storm egyik legérdekesebb tulajdonsága, hogy türelmes, diszkrét. Nem hirtelen terjed, nem is terjed folyamatosan. Ha megfertőz egy gépet, egy ideig lappang, és nem is minden fertőzött gép terjed tovább. A vírus/féreg nem lassítja le a gépet, hálózatot, és nem akadályozza a felhasználót a munkában, így a felhasználó nem fog gyanút, és nem fordul szakemberhez. A regényekben, filmekben szereplő (biológiai) vírusok általában nagyon gyorsan terjednek, és néhány nap alatt ölnek (általában igen brutális módon). Úgy gondolom, ezek a valóságban túl gyorsan pusztítanák el a fertőzötteket, akiknek nem lenne elég ideje össze-vissza utazni, mászkálni, másokat megfertőzni. A Storm nem informatikai biztonsági hibát használ ki, hanem az ún. social engineering segítségével, levélben terjed: a levélből úgy tűnik, hogy a csatolmánya érdekes híreket tartalmaz, a kíváncsi felhasználó pedig megnyitja. Schneier azt állítja, hogy hiába oktatjuk a felhasználókat, mindig lesznek tömegek, akik rákattintanak az érdekesnek tűnő csatolmányokra. Ezt a problémát nem oldja meg egy patch feltelepítése. Nagyon nehéz a fertőzőtt gépeket felderítni, és Schneier szerint a vírusirtó cégek nem is igazán tudnak a folyamatosan változó, rejtőzködő Stormmal szemben érdemi megoldást felmutatni. Az írás azzal végződik, hogy a Storm eddig még nem csinált semmit, csak erősödik, terjed, és egy jókora botnetet épít ki. E botnetet előbb-utóbb valaki majd használni is fogja valamire...

Elterjedt Diffie-Hellman implementációs hiba 2007-10-01

Ez az írás arról számol be, hogy egy kulccsereprotokoll minden implementációjában egyazon biztonsági hiba van. (Az IKE protokollban alkalmazott Diffie-Hellman kulccsere esetén elmaradt egy paraméter-ellenőrzés.) E válasz szerint nem konspirációról van szó, hanem egészen egyszerűen ilyen esendőek a programok; a kriptográfiai megoldások gyakran ilyen "buta" implementációs hibákon buknak el.

Hacktivity 2007 előadás 2007-09-30

A Hacktivity 2007 konferencián elhangzott előadásom itt érhető el.

Egy számítógépes betörés felderítése 2007-08-21

A szerző leírja, hogy hogyan szúrta ki, hogy egy ismerőse gépét feltörték és távolról irányítják, leírja és elmagyarázza, hogy hogyan próbálta nyomok követni a támadót, majd értékeli, hogy a támadó milyen hibákat követett el a támadás során.

A velencei dózsék választására szolgáló protokoll analízise 2007-08-01

Ez a cikk a velencei dózsék választására szolgáló protokollt vizsgálja meg biztonsági szempontból. Nagyon érdekes, hogy régen milyen biztonsági alkalmazásokat találtak ki; ezek közül néhány akár több száz éven keresztül is sikeresen működött. A pápaválasztás (ma is alkalmazott) protokolljáról itt található egy analízis.

Harry Potter kiszivárgott a BitTorrenten keresztül 2007-07-20

A megjelenése előtt néhány nappal az utolsó Harry Potter könyv "kalóz" változata megjelent az Interneten. A könyv a BitTorrent, egy peer-to-peer fájlcserélő rendszer segítségével jelent meg. Úgy működik, hogy ha valaki megoszt egy fájlt BitTorrent segítségével, azt mások kis darabokban tölthetik le, véletlenszerű sorrendben. Mindenki, aki letölt, egyúttal fel is kínálja az általa már letöltött csomagokat mások számára. Így minél többen töltenek le valamit, annál többen kínálják fel azt letöltésre. A rendszer elosztott, nincsen olyan központja, aminek a megsemmisítésével vagy bezárásával lebéníthatnánk. Ez azt eredményezi, hogy ami egyszer felkerül, azt nagyon-nagyon nehéz leszedni. BitTorrentet használni nem illegális; védett tartalmat nem szabad letölteni vele. Van olyan program, amit a fejlesztője BitTorrenten keresztül is terjeszt. A könyv nem szöveges formában került fel a netre, hanem minden egyes oldalát lefényképezték, és a képeket töltötték fel. Bruce Schneier szerint aki van annyira fanatikus, hogy ilyen formában olvas el egy könyvet, az van annyira fanatikus, hogy később meg is vegye. Szerinte ez a kalózakció nem sok bevételt vesz el a kiadótól, sőt, inkább reklámot jelent a felhajtás. Nagyon nehéz egy könyvet úgy tartani titokban, hogy amint megjelenik, rögtön mindenhol kapható legyen, de előtte ne szivárogjon ki. Túl sok embernek kell előkészítenie a gyártást, szállítást, terjesztést, elég ha közülük csak egy ki akaja szivárogtatni. Schneier szerint nem az a meglepő, hogy a Harry Potter könyv kiszivárgott, hanem az, hogy csak ilyen kevés idővel a megjelenése előtt szivárgott ki.

docs.google.com 2007-07-06

A docs.google.com oldalon egy irodai alkalmazás alapvető funkcionalitását érhetjük el: szöveget szerkeszthetünk, táblázatot kezelhetünk webes felületen keresztül. Az elkészült fájlok a webre kerülnek, a google oldalán keresztül felhasználónévvel és jelszóval férhetünk hozzájuk. Megoszthatjuk dokumentumainkat más felhasználókkal, és kereshetünk is bennük. Láthatóan a Google azt célozta meg, hogy a keresés mellett teljes irodai környezetet - levelezést, szövegszerkesztést, táblázatkezelést, naptárat, fényképmegosztást - kínál ingyenesen, és ezáltal méginkább központi hellyé válik az internetezők számára. Ez a cikk az ezzel kapcsolatos biztonsági kérdéseket feszegeti - elsősorban jogi szempontból. Nem arra fókuszál, hogy így egy helyen igen sok adat gyűlik össze valakiről. Nem azt feszegeti, hogy mennyire megbízható-e a szolgáltató, akinél a dokumentumokat elhelyezzük. Nem annak a veszélyeiről ír, hogy a szolgáltató így bármit megtehet a feltöltött dokumentumokkal. A cikk arról szól, hogy ezek a dokumentumok, táblázatok kikerülnek a felhasználó irányítása alól. Ha azt is mondjuk, hogy a feltöltött, fent szerkesztett dokumentumok a felhasználó tulajdonát képezik, azok a dokumentumok igenis a szolgáltatónál vannak. Arra a kérdésre összpontosít, hogy egy bíróság vagy hatóság a felhasználótól vagy a szolgáltatótól követelheti-e a dokumentumokat, és ha a szolgáltatótól kéri őket, akkor kell-e erről értesíteni a felhasználót. Magánszemély megteheti, hogy a nem érzékeny adatait ilyen helyen tárolja. Az érzékeny (esetleg vállati) adatokat nem így kell tárolni, feldolgozni.

Nem elég kifizetődőek a DDoS támadások? 2007-05-03

A Symantec azt írja, az utóbbi időben hirtelen lecsökkent a DDoS (distributed denial of service) támadások száma, és ennek az az oka, hogy már nem elég kifizetőd DDoS támadásokkal foglalkozni. Azt nevezzük DoS (denial of service) támadásnak, amikor a támadó nem "bejutni" akar egy informatikai rendszerbe, nem akar (vagy nem tud) hozzáférni a benne lévő adatokhoz, hanem a rendszer lebénítására törekszik. Gyakori például, hogy a támadó egy programmal sok üzenetet generál, eláraszt egy informatikai rendszert (pl. egy webszervert), és azt reméli, hogy a szervert megbénítja a sok kérés. Ha a támadó egy gépről indítja a támadást, a szerver kiszúrhatja ezt a gépet, és dönthet úgy, hogy nem fogad róla több kérést. Azt nevezzük disztributív DoS támadásnak, amikor a támadó nem egy, hanem sok gépet használ a támadásra, tehát sok gépről egyszerre áraszt el egy rendszert. DDoS támadások ellen különösen nehéz védekezni, mert nehéz megállapítani, hogy a sok kapcsolódó számítógép közül melyik a valódi ügyfél, és melyik a támadó "ügynöke". (Ez a cikk például a DDoS támadók statisztikai alapon történő felismerésével és kitiltásával foglalkozik.) A támadók általában nem a saját gépeikről indítják a DDoS támadásokat, hanem úgy nevezett bot-okról. Például, vírusok segítségével megfertőznek és az irányításuk alá vonnak sok-sok számítógépet (tipikusan otthoni felhasználók gyengén védett, de folyamatos internet kapcsolattal rendelkező gépeit), és az áldozataik számítógépeit használják a támadás megindítására. Így hiába fedezzük fel az egyes botokat, csak áldozatokat találunk, az igazi bűnös a háttérből irányítja őket. Az interneten rengeteg számítógép van, és óriási botnetek léteznek. (Ez a hír például egy másfél millió számítógépből álló - lebukott - botnetről szól.) A Symantec híre olyan támadókról szól, akik megfenyegetnek cégeket, informatikai rendszereket, hogy megbénítják, elárasztják őket, ha nem fizetnek védelmi díjat. A hír úgy spekulál, hogy kockázatos lépés valóban megindítani egy támadást - a támadó támadáskor könnyen elveszítheti botjai egy részét, vagy akár az összeset (pl. ha valaki felfedezi, hogyan irányítják a botokat). Azt írják, ha a megfenyegetett cég nem fizet, a támadó meg kellene, hogy támadja, de a támadás kockázatos, és a megtámadott pedig már biztos, hogy nem fog fizetni. A gondolatmenet furcsa, mert úgy tudom, a védelmi díjak szedése a valóságban virágzó üzletág. A cikk azt is írta, hogy a botnetek tulajdonosai valószínűleg más, csábítóbb üzletekbe vágtak, például spam-eket küldenek - talán ezzel is magyarázható az utóbbi időben hirtelen megnövekedett spam mennyiség...

Networkshop 2007 2007-04-24

Az idén is megrendezésre került a Networkshop konferencia. Kolléganőm, Endrődi Csilla az archív aláírásokról beszélt, én pedig az elektronikus archiválás szolgáltatással kapcsolatos főbb elvi kérdésekről tartottam előadást. (A prezentációm itt érhető el.)

Új web, új támadások 2007-04-20

A világháló kezdetben statikus weboldalakból állt, és a felhasználók azokat nézegették, olvasgatták. Később egyre több aktív tartalom került ezekre az oldalakra, fórumok, blogok (mint pl. ez a blog), wikik jelentek meg. Ahogy az Internet fejlődik, a rajta lévő információnak egyre hányada származik a weboldalak fenntartóitól, és egyre nagyobb a súlya annak a tartalomnak, amit a weboldalak felhasználói, látogatói készítenek el és töltenek fel. Ilyen oldal a Wikipedia (lexikon), a YouTube (videó-megosztó hely), és ilyenek a social networking oldalak, mint az iWiW vagy a MySpace. A Time magazin 1927 óta minden évben megválasztja az év emberét, az adott évben a legnagyobb befolyással bíró személyt. 2006-ban az év emberének a fényképe helyén egy tükröződő felület díszelgett: az év embere az olvasó, a világra az átlag internet felhasználók összessége bír a legnagyobb befolyással. Kétségtelen, hogy az utóbbi időben gyökeresen megváltozott a web (ezt nevezik egyesek web 2.0-nak is). Az Internet fejlődésével az informatikai támadások is fejlődnek, új biztonsági kockázatok jelennek meg. A sokak által használt, tartalom feltöltését is lehetővé tevő weboldalak is új, érdekes támadásoknak nyitnak teret. A manapság "divatos", cross-site scripting támadások gyakran ezt használják ki. Ilyen támadás lehet például, amikor valaki olyan tartalmat helyez el egy weboldalon, amellyel a weblapot megnéző felhasználók gépein futtathat le kódot. Ha a saját, ismeretlen honlapján teszi ezt, az nem annyira súlyos eset, de manapság frekventált, sokak által látogadott weboldalakra is feltölthető tartalom. A támadó nem jut be a webszerverre, nem fér hozzá a szerver erőforrásaihoz, "csak" a weboldal látogatóinak a gépén futtathat le kódot. Az így "megfertőzött" áldozatok esetleg további aktív tartalmakat tölthetnek fel, és további felhasználókat fertőzhetnek meg, így a rosszindulatú kód vírusszerűen is terjedhet. Ez a támadás például a MySpace (egy iWiW-szerű külföldi oldal) segítségével terjedt, és a készítője kb. 1 millió "ismerőst" szerzett a segítségével. Ahogy a egyere növekszik a kisember-internet-felhasználó tömegek jelentősége, egyre több támadás számára ők, és nem a szerverek jelentenek az igazi célpontot.

Internetes rövidítések 2007-04-20

Internetes fórumokon barangolva gyakran találkozhatunk cseles rövidítésekkel. Ilyen az RTFM, a IANAL, az IMHO, és a ROTFL. Róluk, és sok hasonlóról szerepel egy aranyos kis gyűjtemény itt itt, a Cygwin oldalán.

Birkákkal a klímaváltozás ellen 2007-04-03

A birkák alapvetően fehérek. (Ez persze nem mindig igaz, vannak kifejezetten fekete bárányok is. Azt talán mégis kimondhatjuk, hogy a birkák többsége fehér, legalábbis fehérebb, mint a mező, amin legelnek.) Ez a cikk arra épül, hogy a fehér színű birkák jobban visszaverik a fényt (azaz kevesebb fényt nyelnek el), mint a mező, amin legelnek. Ezáltal, minél nagyobb mértékben birkák foglalják el a Föld felszínét, annál több energiát nyel el a földfelszín, és annál többet ver vissza. A cikk statisztikákat mutat arról, hogy milyen ütemben csökkent a birkák száma Új Zélandon, és ezzel együtt hogyan nőtt a globális felmelegedés. Ezzel a cikk arra utal, hogy nagy mennyiségű birkával megállítható lenne a klímaváltozás :)... A cikk április 1-én jelent meg :)...

Kockázatok felmérése 2007-03-19

A biztonságot (és így az informatikai biztonságot) tekinthetjük kockázatokal történő tudatos szembenállásnak. Véges erőforrásokkal rendelkezünk, így minden veszély ellen nem tudjuk megvédeni magunkat. Ehelyett felmérjük, hogy milyen fenyetettségek leselkednek ránk, értékeljük, hogy melyik mekkora kockázatot jelent, és olyan módon védekezünk, hogy a védelem "költséghatékony" legyen. Meghatározzuk, mekkora az a kockázat, amit még el tudunk fogadni, és minden kockázatot ez alá a szint alá csökkentünk. A védelmi intézkedések meghatározásánál nemcsak azt kell figyelembe venni, hogy az adott intézkedés milyen kockázatokat csökkent, hanem azt is, hogy az mennyibe kerül. (A "költség" és az "erőforrás" szavak cégek esetén tipikusan pénzben kifejezhető, anyagi költséget jelentenek, de a vállalt kényelmetlenség, az aggódás és az erkölcsi kár is ennek tekinthető.) Egy cég vagy szervezet informatikai rendszerének védelmét ma ilyen megközelítés szerint szokás megtervezni. Például a CobIT rendszer egy ilyen megközelítésre épül. Gyakran - bár nem tudatosan - magánszemélyek is hasonló elvek alapján védekeznek. Igaz, néha alaposan mellényúlnak. Ez a cikk például arról szól, hogy az emberek - gyakran a média keltette tömeghisztéria hatására - bizonyos kockázatokat (amelyeknek szinte elenyészően kicsi a valószínűsége) túlértékelnek, és azokon tépelődnek, míg más kockázatokat (dohányzás, autóbaleset) szinte észre sem vesznek. Eszerint az írás szerint a terrorizmus jelent szinte elhanyagolható kockázatot, éves szinten kb. annyian halnak meg tőle (az USÁ-ban), mint pl. villámcsapástól. Igaz, gyakran más szempontok is vannak egy védelmi intézkedésről szóló döntés esetén, mint az, hogy az mennyire hatékony, ilyen például, hogy lehetőleg minél kevésbé lehessen felelősségre vonni vagy kirúgni azt, aki a döntést hozza.

Otthoni routerek elleni támadás 2007-02-24

Ez a rafinált támadás a tipikus felhasználók otthoni routereit célozza meg. A következő módon működik: A támadó készít egy trükkös weblapot, amit az áldozat megnéz a böngészőjével. A támadás működéséhez az áldozatnak ezen kívül semmi mást nem kell tennie (nem kell engedélyeznie semmit, nem kell rákattintania semmire stb). A weblapon lévő javascript kód lefut az áldozat gépén, és új kapcsolatokat nyit. A támadó weblapjáról letöltött javascript így próbál meg belépni az áldozat gépéről az áldozat otthoni routerére. A script az otthoni routerek tipikus belső ip címeit próbálja ki, és az alapértelmezett adminisztrátor jelszóval próbál meg belépni rájuk. Az a tapasztalat, hogy a legtöbb felhasználó úgy használja a routert, ahogy a dobozból kivette, és még az alapértelmezett jelszót sem változtatja meg. Ha sikerül belépnie, a támadó tetszőlegesen átállíthatja a routert. Például, megváltoztathatja az áldozat DNS szerverét, és így megtévesztheti az áldozatot: ezentúl hiába írja be egy weboldal (pl. xyzbank.hu) címét a böngészőjébe, mégis a támadó számítógépével lép majd kapcsolatba. Az ilyen jellegű routereket az alapértelmezett beállítás szerint kívülről, az Internet felől nem lehet adminisztrálni, csak belülről engednek meg ilyen belépést, ezért elsőre nem is tűnne szükségesnek az alapértelmezett jelszó megváltoztatása. Ez a támadás éppen azt használja ki, hogy belülről, az áldozat gépéről lép be a routerre. A javascript futtatás letiltása kivédené ezt a támadást, de ez nem reális védekezés; nagyon sok oldal használ javascriptet, amelyeket e nélkül a funkció nélkül egyáltalán nem lehetne megnézni. Megjegyezzük, hogy ez a támadás nem a javascript hibáját használja ki: weblapokon gyakran használnak olyan funkciót, hogy javascript nyit meg új oldalakat. Tanulság: Vannak fontos és kevésbé fontos jelszavak. Az utóbbiak esetén is célszerű követni azt az ökölszabályt, hogy az alapértelmezett jelszavakat meg kell változtatni. Itt található további információ erről a támadásról.

XAdES aláírás-típusok 2007-02-20

A www.e-szigno.hu oldalon megjelent egy írásom a xades aláírás-típusok összehasonlításáról. Arról szól, hogy csak akkor "letagadhatatlan" egy aláírás, ha érvényes, pontosabban, ha meg tudunk győződni az érvényességéről. Az ETSI TS 101 903 (XAdES) specifikáció szerinti aláírásformátumokat hasonlítom benne össze, leírom, hogy az egyes aláírásformátumok ("egyszerű" aláírás, időbélyeggel ellátott aláírás, archív aláírás stb.) milyen elemeket tartalmaznak és miért, valamint leírom, hogy melyiket mikor célszerű használni.

A megtévesztés művészete 2007-02-15

Kevin Mitnick "A megtévesztés művészete" ("The art of deception") című könyvében az informatikai rendszerek biztonsági szempontból talán leggyengébb eleméről, az emberről ír. Példákat mutat rá, hogy hogyan lehet különböző informatikai rendszerekbe olyan módon "betörni", hogy a támadó akár számítógépet sem használ. Mindössze felhívja (például) egy nagyvállalat néhány dolgozóját, udvariasan elbeszélget velük, és apró információmorzsákat csikar ki belőlük a vállalat működésével kapcsolatban. Az így szerzett információkat arra használja fel, hogy a vállalat más dolgozóival szemben már belső embernek, munkatársnak adja ki magát, és tőlük már valóban fontos, bizalmas információkat (például jelszavakat vagy a vállalat ügyfeleivel kapcsolatos adatokat, hitelkártyaszámokat) szerez meg. Olyan értelemben nem informatikai támadásról van szó, hogy a támadáshoz gyakran még számítógépet használ. Ugyanakkor a támadó - a dolgozókkal való ügyes kommunikáció segítségével - a megtámadott szervezet informatikai rendszerét térképezi fel, és annak gyengeségeit használja ki. Az ilyen jellegű támadásokat nevezzük social engineeringnek. A könyv nem a támadások számítástechnikai részleteiről szól, hanem arról, hogy valaki hogyan, milyen eszközökkel manipulálhat embereket távolról. Van, hogy hízeleg, van, hogy fenyeget, van, hogy valamelyik főnökre hivatkozik. Előfordul, hogy az emberi naivitást, hiszékenységet használja ki, gyakran pedig az embereknek arra a természetes ösztönére támaszkodik, hogy szívesen segítenek bajba jutott embertársaiknak, kollégáiknak. A részletesen leírt támadások közül némelyik igen hátborzongató, szerintem nagyon nehéz feladat lehet egy nagy szervezet informatikai biztonsági rendszerét úgy kialakítani, és a hozzá tartozó személyzetet úgy kiképezni, hogy a könyvben leírt támadások mindegyike elhárítható legyen. Mitnick maga is nagy tapasztalattal rendelkezik a social engineering terén, börtönben is ült különböző informatikai rendszerekbe - többek között social engineering eszközökkel végrehajtott - betörések miatt. Az ő nevéhez kapcsolódik az egyik első (de talán az egyik leghíresebb) számítógépes betöréssel kapcsolatos bírósági per. A könyv Magyarországon, magyar nyelven is kapható (bár szerintem a magyar fordítás elég gyenge).

Mit kíván a felhasználó? 2007-01-04

Felhasználói szemmel megfogalmazott elvárásokat olvashatunk az informatikai biztonsággal szemben ezen az oldalon. A szerző elengedi a fantáziáját, és leírja, milyen biztonsági funkciókat, megoldásokat szeretne használni. Nagyon érdekes, hogy milyen egyszerű, "természetes" elvárásokat fogalmaz meg, és ezek mennyire távol állnak a technológia (mai) lehetőségeitől. Természetesen néhány elvárás ellentmond egymásnak, és néhány (például a "csak az olvashassa el a fájljaimat, akinek és megengedem, még akkor is, ha a fájl már nem az én birtokomban van" vagy a "mondhassam meg, hogy egy fájl meddig maradjon meg és mikor pusztuljon el, és ez vonatkozzon minden egyes példányra, függetlenül attól, hogy azok hol, kinél vannak, és kiknek küldtem el") már önmagában is lehetetlennek tűnik. Ráadásul, az ilyen egyszerű és természetes elvárások szinte biztos, hogy ütközhetnek más hasonló egyszerű és természetes elvárásokkal. A szerző tudatosan rugaszkodott el a valóságtól, talán arra próbál rávilágítani, hogy a csilli-villi technológia megoldások nem mindig azt nyújtják, amit a laikus felhasználó elvár. Így ezek az ellentmondások nem hibái, hanem talán a legfőbb értékei e cikknek.

PKI az adathalászat (phishing) ellen? 2006-12-21

Azt nevezzük adathalászatnak (vagy phising-nek), amikor egy bűnöző hamis üzeneteket küld valakinek a nevében, és így próbál érzékeny információkat kicsalni az áldozataitól. Magyarországon az utóbbi napokban többször történt olyan eset, hogy bűnökzők bankok nevében küldtek szét hamis leveleket, amelyekben a bank nevében (például valamilyen biztonsági okra hivatkozva) arra kérték a címzetteket, hogy adják meg a bankhoz tartozó felhasználónevüket és jelszavukat. A levélben általában szerepelt egy link is, amely egy az adott bank honlapját utánzó csaló weboldalra mutatott. Vajon PKI alapon meg lehetne-e akadályozni az ilyen támadásokat? Ha igen, akkor milyen eszközök segítségével? Az egyik megoldás szerint a felhasználók a webszerverek SSL tanúsítványa alapján győződhetnek meg arról, hogy biztonságos kapcsolaton kommunikálnak a bankjukkal. A böngésző programok egy apró lakatot jelenítenek meg az állapotsorban, így jelzik, hogy a felhasználó SSL kapcsolaton keresztül néz egy oldalt. Ez a lakat mindössze annyit jelent, hogy valakivel SSL kapcsolaton keresztül (titkosított és hitelesített csatornán) kommunikálunk. Ahhoz, hogy a kommunikációt valóban biztonságosnak nevezhessük, azt is meg kell vizsgálni, hogy kicsoda az, akivel a biztonságos csatornát kiépítettük. Nem sok értelme van az SSL kapcsolatnak, ha nem tudjuk, ki az, akivel titkosítva és hitelesítve kommunikálunk. Az erre az egyik lehetőség, hogy ellenőrizzük a böngészőben annak oldalnak a címét, amelyikkel kapcsolatba léptünk. El kell döntenünk, hogy valóban annak az oldalnak a címe szerepel-e (HTTPS-sel) a böngésző címsorában, mint amelyiken lenni szeretnénk. A másik, talán biztonságosabb megoldást azt jelenti, ha rákattintunk a lakatra, és megnézzük a webszerver tanúsítványát is. A tanúsítványból kiderül, hogy a tanúsítványt pontosan kinek vagy minek a számára bocsátották ki. (Itt fontos megjegyezni, hogy csak igazi, megbízható hitelesítés szolgáltató által kibocsátott tanúsítványban bízhatunk igazán. Bármelyik csaló bármikor kibocsáthat saját maga számára tanúsítvánt. Ha figyelmen kívül hagyjuk a böngésző program azon figyelmeztetését, hogy a tanúsítványt nem megbízható szolgáltató bocsátotta ki, akkor az SSL nyújtotta védelem lehet, hogy semmit sem ér.) Mindkét esetben az a probléma, hogy nem könnyű eldönteni, hogy a böngészőben lévő cím vagy a tanúsítványban szereplő megnevezés valóban azt a bankot vagy szervezetet jelenti-e, amelyiknek az oldalán lenni szeretnénk. Például, sok phising üzenet www.xyzbank.net címet tartalmazott, holott a bank valódi címe pedig www.xyzbank.hu volt. Onnantól kezdve, hogy a támadó valóban megszerezte a www.xyzbank.net domaint, nem kerül neki komoly erőfeszítésbe webszerver tanúsítványt szerezni hozzá. Az a tapasztalat, hogy - habár a böngészőkben vannak biztonsági megoldások - a laikus felhasználók nem ismerik, és így nem tudják kihasználni őket. (Ez a tanulmány ilyen próbálkozásokat, kísérleteket mutat be.) Az SSL hiába jelent erős (ma megtörhetetlen) titkosítást és hitelesítést, szinte soha nem használjuk igazán biztonságos módon. A PKI olyan megoldásokat is kínál, miszerint a felhasználó, a kliens azonosítja magát biztonságos módon (tanúsítvány alapon, esetleg intelligens kártya segítségével). Nyilvánvaló, hogy az ilyen megoldás nem segít a phising ellen: itt ugyanis éppen nem a felhasználót, hanem az szervert kellene azonosítani, a csaló szerver bármilyen felhasználó azonosítást elfogad. Igaz, ebben az esetben a támadónak nem elég kicsalnia a felhasználó jelszavát, más (például a felhasználó magánkulcsa vagy intelligens kártyája) is szükséges ahhoz, hogy a támadó megszemélyesíthesse a felhasználót. Sajnos, a tapasztalat azt mutatja, hogy a támadók stratégiát váltanak, könnyen alkalmazkodnak az ilyen megoldásokhoz, és így is tudnak csalni. Akár elektronikus aláírás segítségével is próbálhatunk a phising ellen védekezni. Ennek egyik módja az lehet, hogy a bank csak elektronikusan aláírt leveleket küld az ügyfeleinek. Ez csak akkor működhet, ha a bank erről egyértelműen tájékoztatja az összes felhasználót. Ráadásul, itt is felmerülnek az SSL tanúsítványokhoz hasonló problémák: a felhasználónak ekkor is ellenőriznie kell az elektronikus aláírásokat, és gondosan meg kell vizsgálni az aláíráshoz tartoz tanúsítványokat, és el kell tudniuk dönteni, hogy azok valóban a bankhoz tartoznak-e. (Igaz, ez itt egyszerűbb lehet, mint SSL tanúsítványok esetén.) A PKI több olyan eszközt is kínál, amely használható az ehhez hasonló támadások kivédésére, de önmagában egyik sem elegendő. Így az olyan kijelentéseket "vegyetek tanúsítványt, és akkor minden (biztonsági) problémátok megoldódik" erős túlzásnak tartom. A phising alapvetően nem az emberek tapasztalatlanságát, naivságát használja ki. A támadás az ember becsapására irányul, és lehet, hogy a védekezés legegyszerűbb módja az, ha az ember tudomásul veszi, hogy igazi bankok ehhez hasonló emaileket nem küldenek, és sem telefonon, sem emailben nem kérik el a PIN kódokat. Az emailekben kapott linkeken lévő oldalakon pedig nem szabad érzékeny információkat megadni.

Onion Routing, Tor 2006-12-21

Ha egy weboldallal biztonságosan szeretnénk kommunikálni, általában SSL csatornát építünk ki. (Ezt úgy tehetjük meg, ha a böngészőbe https:// szöveget írunk a weboldal címe elé. A böngészők egy kis lakatot jelenítenek meg a jobb alsó sarokban, így jelzik, hogy SSL-en keresztül kommunikálunk.) Ilyenkor - ha a webszerver tanúsítványa alapján meggyőződünk róla, hogy nem egy hamis weboldallal van dolgunk - biztonságosan kommunikálhatunk a weboldallal; biztosak lehetnk benne, hogy üzeneteinket a csatornán nem hallgathatják le, és nem módosíthatják illetéktelenek. Hiába nem tudja a támadó lehallgatni vagy módosítani az üzeneteinket, továbbra is megfigyelheti, hogy kivel, mikor és mennyit kommunikálunk. Ha a támadó ilyen információkat használ a támadáshoz, akkor forgalom-analízis (traffic analysis) támadásról beszélünk. Különféle módszerek léteznek a forgalom-analízis támadások kivédésére. Megtehetjük, hogy felesleges üzeneteket küldözgetünk össze-vissza, így rejtjük el valódi, fontos üzeneteinket. Másik lehetőség, hogy sokan összefognak, és "kézről kézre adják" a titkosított üzeneteket, így a hálózatot figyelő támadó összezavarodhat, nem tudja megállapítani, hogy ki kinek küld üzeneteket. Egy ilyen lehetőség például a CROWDS, egy másik pedig az onion routing. Az onion routingot az USA haditerngerészeti kutatólaboratóriumában fejlesztették ki. E technológia szerint speciális routerek (ún. onion routerek) adják át egymásnak a csomagokat a hálózaton. A csomagok többszörösen titkosítva közlekednek, és - mivel a titkosítások hagymahéjszerűen egymásba ágyazódnak - az egyes hálózati útvonalakon elhelyezkedő routerek nemcsak a csomagok tartalmát nem ismerik meg, de azt sem tudják, hogy a csomag honnan jön, és hová tart. Egyedül annyit tudnak, hogy melyik másik onion routertől kapták a csomagot, és melyik másiknak kell továbbadni azt. A technológia érdekessége, hogy a biztonság olyan erős, mint a (hálózati útvonalban lévő routerekből álló) lánc legerősebb láncszeme. Itt található egy részletes leírás arról, hogy az onion routing milyen elvek szerint működik. A TOR (the onion router) egy ingyenes, onion routingra épülő kezdeményezés. Ingyenes szoftverek segítségével lehet hozzá csatlakozni, és bárk létrehozhat saját onion routert is. A TOR elsősorban a webböngészést támogatja (különösen például Mozilla Firefox alatt), de más célra, más protokollal is használható. (A Torpark egy olyan speciális Firefox, amely beépített TOR támogatást tartalmaz.) Az onion routing biztonságos technológia, de csak akkor, ha megfelelően használják. Léteznek támadások a TOR ellen, de ezek jellemzően nem az onion routingban találtak hibát, hanem egyes böngészőprogramok gyengeségeit használják ki: Ráveszik a hibás böngésző programokat, hogy - a TOR által kiépített anonim csatornán keresztül, vagy azt megkerülve - mégis áruljanak el maguról információkat. A böngészőket megfelelően kell használni és konfigurálni, különben elronthatják az onion routing technológiából származó - egyébként erős - védelmet.

Megjelent a Firefox 2.0 változata 2006-10-30

A Mozilla Firefox egy nyílt forráskódú, ingyenes böngésző. Magyar változata is van. Önálló program, független a levelezőrendszertől (a régi Mozillákban egyben volt a levelezőrendszer és a böngésző), így kisebb és gyorsabb lett. A Mozillának biztonsági szempontból is sok előnye van. A felhasználók többsége (több, mint 90%) Internet Explorert használ, így a támadások is szinte mindig Explorer böngészőre készülnek. A Mozilla nyílt forráskódú, tehát bárki megnézheti, hogy hogyan készült, hogy működik. Így sokkal könnyebb benne hibát keresni. Ez azért jó, mert így rengeteg ember segíti a fejlesztőket, akik sokkal könnyebben javítják ki a program hibáit. Ugyanakkor, ennek hátulütői is vannak: egy támadónak is sokkal több eszköz van a kezében, ha kihasználható hibát akar keresni. Nem egyértelmű, hogy a zárt vagy a nyílt forráskód jelent nagyobb biztonságot, de mindkét hozzáállásnak számos híve van. Egy viszont biztos: Önmagában már az is igen jelentős biztonsági előrelépés, ha valaki nem ugyanazt, a hibáktól hemzsegő Internet Explorert használja, amit mindenki más.

Célzott vírusok? 2006-10-25

Már régóta fenyegetik az informatikai rendszereket különféle vírusok, kémprogramok, férgek, trójai programok és egyéb rosszindulatú szoftverek. (A köztük lévő határok kezdenek összemosódni, így az egyszerűség kedvéért nevezzük őket csak vírusnak.) Az Interneten keresztül (eseleg automatikusan, emberi beavatkozás nélkül) terjedő vírusok rendkívül gyorsan, akár néhány óra alatt is , rengeteg számítógépet megfertőzhetnek. A vírusok készítői hibát fedeznek fel valamilyen programban vagy rendszerben, olyan vírust készítenek, amely kihasználja ezt a hibát, majd útjukra bocsátják a vírust, amely rengeteg gépet megfertőz. A vírusok egy része közvetlenül pusztít: tönkreteheti a megfertőzött rendszert, valamint letörölhet vagy módosíthat adatokat. A vírusok egy másik része esetleg nem csinál mást, "csak" terjed, de így is óriási károkat okozhat. A gyorsan terjedő vírus önmagában a terjedésével is leterhelheti, megbéníthatja a rendszereket. Olyan vírusok is vannak, amelyek nem pusztítanak ugyan, viszont lehetővé teszik, hogy valaki távolról irányíthassa a megfertőzött számítógépeket, és így például adatokat lophasson róluk, vagy róluk indíthasson támadást más informatikai rendszerek ellen. A vírusok gyors terjedésének - bármilyen abszurdnak is hangzik - előnyei is vannak. Felhívják a figyelmet az informatikai rendszerek hibáira, így azok készítői biztonsági javításokat (patch-eket) adnak ki rájuk, valamint a vírusvédelmi szoftverek készítői is felkészülnek az ilyen hibákat kihasználó vírusokra. Ráadásul, számos vírust önmagában már az alapján fel lehet ismerni, hogy terjed. Ha sok helyen, egyszerre hasonló "furcsaság" jelenik meg, statisztika alapon is ki lehet mutatni, hogy egy új vírus jelent meg, akkor is, ha még nincs olyan vírusvédelmi szoftver, amely felvehetné vele a harcot. Ilyen módon riasztani lehet vírusvédelmi szoftvereket gyártó cégeket, vagy biztonságtechnikai szakembereket, akik kivizsgálhatják a vírusgyanús eseteket, és megvédhetik a rendszert az új támadásoktól. Ha egy bizonyos hibát kiküszöbölnek, akkor a víruskészítőknek új hibát kell keresni. Így a vírusok - és a terjedésük - hozzájárul az informatikai biztonság fejlődéséhez. Egyre több hír jelenik meg a vírusok egy új generációjáról, a célzott vírusokról. Az ilyen vírusnak (gyakran inkább trójai programnak) az az erőssége, hogy nem terjed. Ilyenkor bűnöző olyan programot készít, amellyel nem sok millió számítógépet akar megfertőzni, hanem csak néhányat - de azt pénzért. A program eddig ismeretlen, új hibát használ ki valamilyen rendszerben. A cél általában üzleti információ ellopása, vagy ipari kémkedés (például egy konkurens vállalat megbízásából). Az áldozat általában észre sem veszi a támadást, és mivel csak egy-egy rendszert fertőznek meg, a vírusvédelmi szoftvert gyártó cégek és vírusvédelmi szakemberek sem figyelnek fel a támadásra.

A felhasználók oktatása a biztonságra? 2006-09-08

Bruce Schneier ezen írása, azt a kérdést feszegeti, hogy amikor az informatikai biztonsági problémákat a felhasználók oktatásával próbáljuk megoldani, akkor a technológia hiányosságait, gyengeségeit küszöböljük ki. Schneier szerint a hiba ekkor nem az emberekben, hanem a technológiában van.

Hogyan írjuk olyan programot, amelyre nem lehet rábizonyítani a hibákat? 2006-07-12

Vicces írás arról, hogy egy szoftverfejlesztő hogyan kerülheti el, hogy rábizonyítsák a programhibákat. Az szerepel benne, hogy olyan programot kell írni, amely nem determinisztikus módon fagy le (esetleg úgy csinál, mintha a hiba nem is benne lenne, hanem egy másik programban), és így nem lehet reprodukálni a hibákat.

USB pen drive-ok jelentette biztonsági kockázatok 2006-06-27

Érdekes cikk arról, hogy mekkora veszélyt jelenthetnek az USB pen drive-ok, és arról, hogy a felhasználók ennek mennyire nincsenek tudatában.

Az információs társadalom négy nagy betegsége :) 2006-06-15

Ismerős...

Hogyan kell ellenőrizni egy elektronikus aláírást? 2006-06-13

A fenti címmel megjelent egy cikkem a HTE Híradástechnika című folyóiratában. A cikkben azokat a lépéseket tekintem végig, amelyeket egy elektronikus aláírást befogadó félnek el kell végeznie, illetve végig kell gondolnia. Az aláírás kriptográfiai ellenőrzése viszonylag egyszerű, könnyen automatizálható feladat, de a kriptográfiai ellenőrzésen kívül számos egyéb kérdés is felmerül, amelyekre minden elektronikus aláírásra támaszkodó rendszerben valamilyen módon választ adunk. Ezen választ, megoldást célszerű tudatosan megválasztani, így kaphatunk "jó", költséghatékony, használható elektronikus aláírás megoldásokat.

Hálózatbiztonsági verseny (USA) 2006-06-02

Lásd itt.

A kalózmásolatok gazdasági hatása 2006-05-29

Előfordulhat, hogy gazdaságilag nem az a célravezető, ha tökéletesen meggátoljuk, hogy egy szellemi termékről (szoftverről, filmről, zenéről) kalózmásolatot készítsenek. Az erős "másolásvédő" (DRM) rendszerek irritálhatják a legális felhasználókat, a kalózmásolatok pedig időnként még hasznot is hozhatnak. Shapiro és Varian az Information Rules című könyvükben bemutatják, hogy bizonyos termékek esetén a termék értékét nagyban befolyásolja, hogy az mennyire elterjed. Így, ha egy termékről sok kalózmásolat van forgalomban, az akár azt is eredményezheti, hogy a terméket a "fizetős" vásárlók drágábban is hajlandóak megvásárolni.

Agyonvertek egy spammert Moszkvában 2006-05-29

A spam valóban sok embert idegesít, és az is kimutatható, hogy a spam gyakran jeletős anyagi kárt is okoz. Ennek ellenére, nem ilyen eszközökkel kell a spam ellen küzdeni.

Gemalto 2006-05-26

Két nagy kártyagyártó cég - az Axalto (korábban Schlumberger) és a Gemplus - bejelentette, hogy egyesülnek. A közös nevük: Gemalto.

Intelligens kártyára épülő rendszerek Európában 2006-05-26

Rónai Tibor előadása az európai kormányzati intelligens kártya alkalmazások helyzetét tekinti át. Országos rendszert csak Belgiumban, Észtországban és Szlovéniában említ, a többi országban csak helyi rendszerek vannak. Az előadás az Intelligens Kártya Fórum szakmai napján hangzott el.

Elindult a berta.hu 2006-05-19

Megújult honlapom új domainen, itt a berta.hu oldalon jelenik meg.