About...

Napi betevő adag elírás, elütés és helyesírási hiba egy helyen! Amúgy meg #információbiztonság #webcserkészet néha #élettudomány

bardóczi ákos @post.r

blogavatar

minőségi kontent-egyveleg

RSS

cimketenger

ITsec (37),privacy (17),Facebook (17),social media (11),itsec (11),egyéb (10),social web (9),biztonság (8),mobil (8),OSINT (6),jog (6),magánszféra (6),tudomány (6),szellemi tulajdon (6),Google (5),molbiol (5),felzárkóztató (5),webcserkészet (5),szájbarágó (5),plágium (4),Nobel-díj (4),kriminalisztika (4),terrorizmus (4),kultúra (4),big data (4),email (4),genetika (3),pszichológia (3),molekuláris biológia (3),biztonságpolitika (3),CRISPR (3),Android (3),online marketing (3),sajtó (3),élettudomány (3),gépi tanulás (3),Onedrive (3),üzenetküldés (3),jelszó (3),2015 (3),orvosi-fiziológiai (3),Apple (3),Gmail (3),reklám (3),konferencia (3),webkettő (3),biztonságtudatosság (3),kriptográfia (3),levelezés (3),magatartástudomány (3),azelsosprint (3),popszakma (3),hype (3),open source intelligence (3),torrent (3),nyelvtechnológia (3),bejutas (2),tweak (2),villámokosság (2),cas9 (2),Yoshinori Ohsumi (2),Hacktivity (2),génterápia (2),fiziológia (2),természetes nyelvfeldolgozás (2),Reblog Sprint (2),bűnügy (2),Pécs (2),nyílt forrású információszerzés (2),webkamera (2),deep web (2),P2P (2),Netacademia (2),arcfelismerés (2),DDoS (2),Balabit (2),bűnüldözés (2),TOR (2),kulturális evolúció (2),ransomware (2),hitelesítés (2),SPF (2),Whatsapp (2),neuropszichológia (2),szabad információáramlás (2),FUD (2),DKIM (2),2-FA (2),bolyai-díj 2015 (2),molekuláris genetika (2),jövő (2),sudo (2),IDC (2),cyberbullying (2),social engineering (2),malware (2),tartalomszolgáltatás (2),meetup (2),facebook (2),reblog (2),videó (2),titkosítás (2),kutatás (2),epic fail (2),pedofília (2),netkultúra (2),nyelvtudomány (2),vírus (2),hírszerzés (2),iOS (2),farmakológia (2),szociálpszichológia (2),tanulás (2),biológia (2),gépház (2),bulvár (2),bug (2),Tinder (2),öröklődő betegség (2),Yandex (2),könyv (2),beszélgetés rögzítése (2),pszeudo-poszt (2),Twitter (2)

"De nekem nem láthatók a Facebook-ismerőseim"


Képzeljük el azt a prózaian egyszerű szituációt, hogy valamilyen okból tudnunk kell, hogy valakinek kik az ismerősei a Facebookon [2], viszont az érintett felhasználó letiltotta, hogy az ismerősei listája látható legyen. Persze, persze, egy kamu adathalász FB-kisalkalmazással ami az felhasználó “szives hozzájárulása” után lekérdezi mindezt, nem nagy bravúr. Viszont a Facebook alkalmazásfejlesztői környezetében [API] egyrészt nem tud mindenki (adathalász) szoftvert fejleszteni, másrészt ha a felhasználó explicite letiltotta, hogy kisalkalmazások a kontaktlistájához hozzáférjenek, mindez meghiúsul.

Ebben a posztban egy arcpirítóan egyszerű megoldást mutatok be, amin keresztül bárkinek a kontaktlistája lekérhető egyetlen programkód megírása nélkül.

Amikor egy szűz böngészőn keresztül – azaz nem pl. meghívóval – regisztrálunk a Facebookra, az illedelmesen felajánlja, hogy bővítsd az ismerőseid körét és onnan dob fel ajánlatokat ahonnan tud: a rendszer feltételezi, hogy a meglévő ismerőseid ismerőseit nagyobb valószínűséggel ismered, mint véletlenszerűen ajánlott felhasználókat, így eleve őket fogja ajánlgatni a jobb oldallécben. Könnyen belátható, hogy ha még nem nagyon léptél kapcsolatba senkivel és csak egyetlen ismerősöd van, az ő ismerőseit dobja fel – és, most jön a lényeg – teljesen függetlenül attól, hogy a meglévő ismerősöd a saját kontaktlistáját mások előtt rejtettre állította vagy sem. Azaz ha elegendő alkalommal frissíted az ajánlott ismerősök listáját, az összes ismerősdét kigyűjtheted, függetlenül attól, hogy azt elvileg láthatnád-e vagy sem, de a módszer még akkor is működik, ha a célfelhasználó az emlegetett kisalkalmazások számára az ismerősök leolvasását az API-n keresztül is tiltotta [1]. Ez mondjuk – számomra – abszolút nem új.

Amit viszont nemrég vettem észre, hogy, hogy a felvázolt esetben nem csak azokat a felhasználókat dobja fel ajánlottként, akik már a meglévő ismerőseid ismerősei, hanem azokat is, akiket ő ismerősnek jelölt vagy őt jelölték ismerősnek, de még nem igazolta vissza a kapcsolatot. Mindenki döntse el magában, hogy ez mennyire kínos, nekem csak egy leendő számítógépes nyelvész kérdése jutott eszembe: “ez most bug vagy feature?”.

Ismétcsak azt tudom mondani, hogy egy közösségi szolgáltatásban teljesen fölösleges a privacy settings-szel és a hasonlóan szépnevű audience selectorral játszani, hasonlóan ahhoz, ahogy a képek láthatósága is kijátszható volt látható minden más is vagy így vagy úgy, legfeljebb az lehet kérdés, hogy egy-egy módszer mennyire ismert.

Nem kalandoznék el nagyon, de összességében ismétcsak azt tudom mondani, hogy nem az a megoldás, ha bojkottáljuk a közösségi webes szolgáltatásokat, hanem az, hogy csak olyan tartalmat töltünk fel, ami szigurúan publikus.

[1] ennek az egésznek természetesen semmi köze az API-hoz
[2] oké, persze ez sokkal egyszerűbb a LinkedIN-en vagy az iWiW-en, amíg van, ui. nyilván ezek általában átfednek
[3] haladó kérdés: az ismertetett logika + egy FB-sajátosság alapján hogyan kérdezhető le a teljes ismerőslista ha több ismerősöd van, de csak egyvalaki ismerőslistájára vagy kíváncsi, aki mindenki előtt rejtve próbálja tartani az ismerőseit. Megoldás jöhet kommentben és emailen egyaránt!

1 Tovább

Hogyan működik a világ legerősebb titkosítási eljárása?


Na jó, a címadással csaltam egy kicsit: egyrészt az egyik legerősebb ma ismert és civil használatra megengedett titkosítási eljárásról fogok írni, másrészt a számításelméleti részletekbe egyáltalán nem megyek bele.

A PGP vagy annak egy klónja, megbízható becslések szerint az egész világon a titkosítást alkalmazó kütyük - legyen szó mainframe szerverről vagy filléres mobilról - közt legtöbb helyen alkalmazott titkosítási eljárás. A PGP valójában két titkosítási eljárás, egy asszimmetrikus és valamelyik szimmetrikus módszer alkalmazásaként működik.

Az asszimmetrikus titkosítás gyakorlatilag minden esetben az RSA módszeren alapul, aminek a működését a következő módon szemléltetném, ráadásul már-már tankönyvi nevekkel: Alice szeretne üzenetet küldeni Bobnak, viszont abban az esetben, ha Alice az üzenetet titkosítja, akkor a titkosításhoz szükséges kulcsot is el kellene juttatnia Bobnak, hogy Bob ugyanazzal a kulccsal az üzenetet vissza tudja fejteni. Abban az esetben, ha a titkosításhoz szükséges kulcsot közben elkapják a titkosított üzenettel együtt, a titkosítás semmit sem ér, hiszen vissza tudja fejteni az is, aki elkapta. Ezzel szemben az asszimmetrikus titkosításnál Alice és Bob egyaránt rendelkezik egy kulcspárral: mindkettőjüknek van egy saját, privát kulcsa, amit csak ő ismer és egy publikus kulcsa, amit bárki ismerhet és ismernie is kell, ha titkosított üzenetet szeretne küldeni neki. Ebben az esetben a történet a következő módon néz ki:
1. Alice és Bob odaadják egymásnak a saját publikus kulcsukat [ezt csak egyszer kell megtenniük]
2. Alice titkosított üzenetet küld Bobnak olyan módon, hogy az üzenet titkosításához a saját privát és Bob publikus kulcsát használja, majd elküldi az üzenetet
3. az üzenet megérkezik Bobhoz, majd az üzenet visszafejtését a saját privát kulcsával, valamint Alice publikus kulcsával végzi el

Azaz egyszer sem haladt át a teljes titkosításhoz szükséges kulcs, mégis tudják olvasni az egymásnak küldött üzeneteket, így az 1970-es években a több ezer éves (!!) ún. kulcsmegosztási problémát oldották meg. Hogyan kombinálódik is az asszimmetrikus és szimmetrikus módszer?

A szimmetrikus kulcsú titkosításnál ugyan csak egy kulcs van, ami a titkosítást és a visszafejtést egyaránt végzi, de ez ideális esetben eléggé erős.

Teljes kommunikáció RSA-val titkosítani egyrészt elképesztően számításigényes lenne, másrészt szükségtelen is, ebből adódott az ötlet, hogy a kettőt össze lehetne lőni, így létrehozva egy olyan titkosítási eljárást, ami kellőképpen erős ahhoz, hogy minden ma ismert törési próbálkozásnak ellenálljon. Ennek az ötletnek az alapján valósította meg Phil Zimmermann a PGP-nek nevezett titkosítási eljárást 1991-ben, ami a következőképp működik:

1. Alice tömöríti az üzenetet, hogy a műveleteket kisebb adathalmazon kelljen végrehajtani
2. Alice egy egyszer használatos, akkor generált kulccsal titkosítja az üzenetet egy szimmetrikus módszerrel
3. Alice magához a szimmetrikus titkosításhoz használt kulcsot - amit beágyaz az üzenetbe - titkosítja Bob nyilvános kulcsával, majd elküldi az üzenetet

Bob az üzenet visszafejtésekor a saját privát kulcsával először az asszimmetrikus titkosításhoz használt kulcsot éri el, majd azzal bontja ki a teljes üzenetet.

nem a teljes PGP ábrája! csak az asszimmetrikus titkosításé

Kultúrtörténeti érdekesség, hogy az internet hőskorában az, hogy egy egyszerű otthoni számítógéppel olyan erős titkosított üzenetet lehetett létrehozni, amit még a nagy-nagy hárombetűs szervezetek sem tudnak visszafejteni szuperszámítógépekkel, akkora riadalmat keltett, hogy 1993-ban az USA-ban eljárást kezdeményeztek Phil Zimmermann ellen, viszont lévén, hogy nem lehet perelni valakit csak azért, mert túl hatékony algoritmust hozott létre, a vád a fegyverek exportját szabályozó törvény megsértése volt. Végül az eljárást 1996-ban megszüntették vádemelés nélkül, addigra pedig a PGP már úgyis elterjedt az egész világon.

Még középiskolás koromban gondolkoztam azon, hogy ha ennyire egyszerű és ennyire hatékony egy titkosítási eljárás, akkor miért nem megy át minden elképzelhető felhasználói adat két fél közt, azaz például ha emailt vagy SMS-t küldünk valakinek, az eszköz csak betöltené a címtárból a feladó nyilvános kulcsát és a címzett már meg is nyitná az üzenetet a saját privát kulcsával. A teljes magyarázat bőségesen meghaladná ennek a posztnak a kereteit, a legfontosabb indokok mogyoróhéjban az emailezés példáján keresztül: pont a 90-es évek elején robbantak be az ingyenesen elérhető email szolgáltatók, amik döntően webes felületen működtek és a felhasználóik tudatosság szempontjából egész egyszerűen nem voltak érdekeltek abban, hogy az üzeneteik titkosítva legyenek, a szolgáltatóknak pedig nem volt érdekük plusz munkát róni a saját szervereikre, ezen kívül a privát kulcsokat is biztonságosan tárolni kellett volna valahol, ha szempont, hogy a felhasználó a leveleit bárhonnan meg tudja nézni, ne csak azon a gépen, amin a saját privát kulcsa van. Megjegyzem: ebben az időben még pendrive-ok és hasonlók kanyarban sem voltak, amin lehetett volna tárolni és használni a privát kulcsot.

Ma pedig az ingyenes levelezőszolgáltatók leggyakoribb üzleti modellje az, hogy a levelezésért nem kell fizetni, viszont egy algoritmus megvizsgálja a levélben előforduló kifejezéseket, majd annak alapján sebészi pontossággal helyez el targetált hirdetéseket a levél szövege melletti oldallécben. Dollármilliárdos piacról van szó. Ha az üzenet titkosított, természetesen a hirdetés targetálása lehetetlen. A Gmailnek például nyilván veszteséges, de nem tiltja, hogy olyan üzenetek továbbítására használják a felhasználók a fiókjukat, amik teljesen elemezhetetlenek az elemzőmotorjaik számára, ez azonban a felhasználóknak csak nagyon kis részét érinti.

Elméletileg megoldható, hogy egy webes levelezőrendszerben PGP-t alkalmazzanak, ez azonban rendkívüli kockázatot rejt magában, hiszen ha valamilyen módon a privát kulcsokat ellopják, az összes felhasználó titkosított levelezése olvasható lesz, ráadásul új kulcsot kellene mindegyiküknek generálnia. Valójában a publikus levelezőrendszerek közt egyetlen normális kivétel van, a Hushmail, ami a privát kulcsok tárolását saját maga oldja meg, ez a kulcs egyébként le is tölthető.

De mit tegyünk, ha saját magunk akarunk olyan titkosított leveleket küldeni és fogadni, amit aztán tényleg nem olvas se ember, se isten, hacsak nem szerezte meg a privát kulcsunkat? Természetesen több konkrét megvalósítás is van, ezek közül az egyik legelterjedtebb kombót mutatom be, ami működik Windowsban, OSX-en és linuxokon is.

Először is a levelezőszolgáltatónknál engedélyezzük az IMAP4/POP3-letöltést - annyira alap szolgáltatás, hogy ha nem lenne lehetséges, időszerű szolgáltatót váltani - majd telepítsünk fel egy levelezőklienst, például a Thunderbirdöt. Ezt követően szükség lesz egy PGP motorra, amiből többféle is létezik, a legelterjedtebb a Gnu Project által feljesztett GnuPG, ami Windowshoz a http://www.gpg4win.org/ címről, OSX-hez pedig a https://gpgtools.org címről tölthető le, a linux-júzerek meg úgyis tudják. Ezek után a Thunderbirdbe telepítsük az Enigmail addont, ami meg fogja hívni a motort, amikor titkosításra van szükség.

Ha mindez megvan, indítsuk el a GnuPG részeként települt PGA-t [GnuPG Agent] vagy a Kleopatra-t, ahol már gyerekjáték új kulcspárt generálni, kezelni. A kulcsunk mérete lehet 1024, 2048, 3072 és 4096 bites is, viszont erősen ajánlott alapértelmezés szerinti 2048 bites kulcsot generálni, mivel más PGP-szoftverek ezzel garantáltan kompatibilisek, ideértve például mobiltelefonok esetén például Android platformon az APG-t, iPhone-nál használt iPGMailt-t is. Fontos, az is, hogy a kulcs több jellemzője is megváltoztatható, a mérete azonban nem!

Ha a kulcspár készen van, aminek a privát részét egy szerkeszthető jelszó is védi, készítsünk róla másolatot, a publikus kulcsot pedig küldjük át annak, akinek szeretnénk GPG-zet levelet küldeni ill. kérjük el az ő publikus kulcsát. Természetesen azért, hogy mindez egyszerűbb legyen, szerte a neten vannak óriási "GPG-telefonkönyvek", ahol ki lehet keresni más GPG-kulcsát az email címe, neve és egyéb adatok alapján, így a publikus kulcsok betölthetők a saját helyi kulcstárunkba illetve mi is feltölthetjük a sajátunkat. Ha egy nagy GPG-adatbázisba feltöltöttük a publikus kulcsunkat, a többibe már nem szükséges, hiszen ezek szinkronban vannak egymással, Magyarországon ilyen például a http://keys.niif.hu/

Amint mindez kész, írjuk meg a titkosítani kívánt levelet, majd küldéskor üssük be a privát kulcsunkhoz tartozó jelszavunkat, az Enigmail pedig a címzett alapján tudni fogja, hogy kinek a publikus kulcsát kell használnia az üzenet titkosításához a kulcstárunkból és a levelet el is küldtük.

Ami még hatalmas előnye a megoldásnak, hogy ha a levelet digitálisan alá is írtuk, az megmásíthatatlanul bizonyítja, hogy a levelet valóban mi írtuk, akkor, azzal a tartalommal, közben nem írt át benne senki semmit és mivel egy GPG-kulcshoz több email cím is hozzárendelhető, ha az email címünk megváltozik, de a leveleinket továbbra is aláirkáljuk, az igazolja a címzett oldalán, hogy tényleg mi vagyunk csak más címmel, nem pedig valaki a nevünkben akar levelet írni.

A posztban nem tértem ki rá, hogy természetesen minden normális levelezőklienshez hozzá lehet adni olyan kiegészítőt, ami lehetővé teszi a PGP-zést, csak éppen van, amelyikben iszonyatosan fapados módon működik. Ahogy nem tértem ki a kulcspár finomhangolási lehetőségeire sem [érvényességi idő, kulcs értvénytelenítésének lehetősége].

Amit viszont nagyon fontos megjegyeznem, hogy a szimmetrikus- és asszimmetrikus titkosítást természetesen nem csak emailek titkosításánál használják, hanem ez a lelke például az SSL/TSL-titkosításnak is, aminek a nyomát nap, mint nap látunk a böngészőben szinte minden, önmagára valamit is adó webszolgáltatásnál, kis lakatként a böngészőben a címsor elején. Ott az egyszer használatos kulcs ismétcsak nálunk van, de a böngésző belügye, hogy azt hogyan kezeli, míg a publikus kulcs a szervernél, ami éppen kiszolgálja a webhelyet. A titkosítás eléggé világos ok miatt sokkal kisebb, mint 2048 bites kulccsal dolgozik. De a technika egyre több internetes telefonálást vagy chatelést biztosító szolgáltatásban is ott figyel, nem mellékesen nem mindegyikben, amelyikre a gyártó azt mondja, hogy igen. A ütősebb, jóval erősebb hardveres titkosítást alkalmazó pendriveok titkosításának az alapja ugyanez.

Néhány kapcsolódó téma, amibe most szintén nem mentem bele: az alkalmazott asszimmetrikus módszertől függően bizonyos kulcsok csak titkosításra használhatók, digitális aláírásra viszont nem valamint az, hogy a titkosítás szigorúan számításelméleti szempontból feltörhetetlen, nem jelenti azt, hogy a gyakorlatban is az: például, ha az egész véletlenül hibásan van leprogramozva vagy az algoritmusnak az a része, ami a kulcspárok generálásához a dög nagy prímszámokat nem teljesen véletlenül választja ki, így a lehetséges privát kulcsokból sokkal kevesebb állítható elő - amiből nemrég orbitális botrány is lett

A GPG-ről egyébként Thunderbird-GunPG-specifikusabban egy behatóbb cikket is írtam néhány napja, amit itt találtok meg

[kollégák figyelmébe: itt ismeretterjesztő cikkről van szó, ennek megfelelően lett megírva, az egyszerűsítések és az érthetőség kedvéért alkalmazott kevésbé precíz megfogalmazás, a PGP és GPG itt-ott szinonimaként való használata az érthetőséget hivatott szolgálni] A magyarázó ábra forrása: Wikipedia. 

1 Tovább

Facebook-fiók megszerzése kamu ismerősökön keresztül


Többször emlegettem már, hogy ha egy világméretű szolgáltatásról van szó, arról hajlamosak vagyunk azt hinni, hogy a rajta működő fiókunk teljes biztonságban van, főleg a relatíve egyszerű, azaz invazív törési technikákat nem igénylő módszerekkel szemben védett. Nos, nem. Már-már könyvet tudnék írni, hogy ilyen-olyan közösségi szolgáltatásokban hogyan lehet idegen fiókot megszerezni vagy eltéríteni, a felhozatalban pedig a Facebook előkelő helyen lenne. A módszerek többségéhez minimális programozási tudás szükséges vagy még annyi se, én most a legfrissebbet mutatom be.

A Facebook egy nem túl régen bevezetett újításaként a https://www.facebook.com/settings?tab=security&section=trusted_friends&view tabon meg lehet jelölni olyan ismerősöket, akiknek a segítségét lehet kérni abban az esetben, ha a fiókunk hozzáférhetetlenné válik, azaz nem tudunk belépni, de nem küldhető jelszó-helyreállító token sem emailen, sem mobilon SMS-ben, nem állítottunk be biztonsági kérdést és még egy okostelefon sincs hozzárendelve a fiókhoz. Ilyenkor van rá lehetőség, hogy a 3-5 kijelöl megbízható ismerősnek a Facebook küldjön egy-egy kódocskát, amiket hozzánk eljuttatva, majd aokat általunk beütve a Facebook fiók ismét elérhetővé válik. A nem kis probléma pedig az, hogy a Trusted contacts beállítása nem kötelező és a felhasználók többségénél nincs is bekapcsolva, a most bemutatásra kerülő account-hijacking erre alapul.

Tételezzük fel, hogy valaki fel akarja nyomni az accountomat, így a Facebook nyitóoldalán a "Forgot your password?" pontot választja. Itt kereshető az áldozat a "helyreállításra szoruló" fiók egyedi azonosítója, rövid, ún. user-friendly neve, teljes neve, email címe(i), telefonszáma(i) alapján egyaránt. Ekkor valami ilyesmi tárul a szemünk elé:

facebook feltörés

Mivel itt lehetőség van azt az opciót választani, hogy a megadott elérhetőségek egyikéhez sincs hozzáférésünk, ezt követően a Facebook bekér egy tetszőleges email címet, amin felveheti velünk a kapcsolatot szükség esetén.

Továbblépve ezután választhatjuk azt a lehetőséget, hogy a barátainktól kérünk segítséget a fiók visszaállításához és itt jön a csavar: abban az esetben, ha korábban az áldozat nem jelölt ki megbízható kontaktokat az előbb emlegetett Trusted contacts tabon, az összes ismerős közül, teljesen tetszőlegesen lehet választani, hogy kitől kérünk segítséget. Jól ismert, hogy az átlag felhasználó igencsak tapintatos tud lenni, ha ismerősnek jelölik, gyakorlatilag visszajelöl boldogot-boldogtalant, így az sem ritka, hogy egy fogát csikorgató ex vagy éppen egy kirúgott beosztott van fent az ismerősök közt kamu néven, ezen kívül minden további nélkül fent lehet néhány kémkedő - szakargóban stalker - kamu felhasználó is, amit pont a támadó tett oda mondjuk több hónap alatt, hogy ne legyen túl feltűnő. Ha tehát legalább három olyan kamu felhasználót vett fel az áldozat, amit maga a támadó hozott létre és vetette fel velük magát ismerősnek az áldozattal korábban, nem nehéz megjósolni a következményt. Ezen a ponton ha a támadó kijelöli a saját három alvó ügynökét, akiknek a postafiókjába landol a három helyreállításhoz szükséges tokenkódocska és amint a támadó azokat megadja, már meg is szerezte az áldozat Facebook-fiókját.

facebook hacking

Egyedüli részmegoldásként azzal lehet csökkenteni a kockázatot, ha kijelölünk megbízható kontaktokat, így egy ilyen típusú támadás esetén a támadó nem tud tetszőlegesen választani az ismerőseink közül, amik némelyike esetleg mind hozzá tartozik.

Megj.1: a leírás messze nem tér ki minden leetséges scenariora, ezért nem biztos, hogy mindenkinél működik
Megj 2: a Facebook azért nem teljesen hülye, ha valaki amatőr módon, azaz anonimizálási technikák nélkül fog neki egy ilyennek, a Facebook millió meg egy dolog alapján azonosíthatja és végleg kirúghatja a támadót az összes accountjával együtt, ideértve a valódit is. Azaz ne próbáld ki otthon.

6 Tovább