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

Egy legendás levelezőrendszer esete a biztonsággal, na meg a felhasználókkal


"Celebrating our 15th anniversary with our new feature: Two-Step Verification" jelentette be a legendás Hushmail májusban a Twitteren, amit - kéretik figyelni! - mindössze egyetlen felhasználó favolt és retwittelt, én meg konkrétan nem vettem észre, pedig jópár éve hardcore hushmailes vagyok. Értem én, hogy a jó munkához idő kell, de ha egy olyan levelezőrendszernél, aminek a születésénél maga Zimmermann, a PGP titkosítóalgoritmus atyja bábáskodott, IMHO máig az egyik legbiztonságosabb levelezőrendszer a világon, gyakorlatilag le vannak maradva az end-user szemében a többiekhez képest, na, az nem jó. Nem jó, mert 2FA téren megelőzte őket az összes nagy, látszólag ingyenes, a felhasználók adataiból élő kommersz mailszolgáltató  Google Mail - Yahoo - Outlook.com sorrendben, ahogy az egy-egy újításnál lenni szokott. Szóval Hushmailék  túl kevéssé kommunikálták a történetet. 

Az, hogy beelőzték őket, még a kisebb probléma: a PRISM-parát meglovagolva ugyanis egy rakás "überbiztonságos", semmiből előtűnő freemium modellel működő vagy előfizetéses levelezőszolgáltatás jelent meg a piacon, amik jó esetben nem zárják be a boltot maholnap és tipliznek a Bahamákra az ügyfelek pénzével ill. jó esetben ezeket a szolgáltatókat nem valamilyen szépnevű hárombetűs szervezet fedőcége vagy nehézsúlyú adathalászok hoztak létre pont azoknak a megfigyelésére, akik éppen azért fizetnek, hogy a levelezésük ne legyen látható. 

Fejtegethetném, hogy nem, nem csak akkor van szükséged elfogadhatóan biztonságos levelezésre, ha egy jó nagy cég vagy hírportál vezetője vagy (egyébként is, 5-10-15 év múlva még lehetsz és igen, 5-10-15 év múlva is valakinél meglesz levelezésed), az meg sokkal cirkalmatosabb téma, hogy mikor is tekinthetünk egy levelezőrendszert biztonságosnak, ugyan egy részét itt már érintettem korábban. 

Az átlag felhasználótól nem várható el, hogy megállapítsa egy levelezőszolgáltatásról, hogy mennyire biztonságos, elég csak rákeresni a neten, hogy melyik is a legbiztonságosabb levelezőrendszer a világon és belenézni az első néhány találatként talált fórumba. Ezt a tudatlanságot kihasználva szedte meg magát egy rakás, elvben biztonságosnak tűnő levelezést kínáló startup olyan jól hangzó, ámbár szakmai szempontból még debilebb érvekkel, minthogy a szervertermük be van fúrva egy hegy gyomrában, skandináv országban/Svájcban van, amire kevésbé lát rá az NSA vagy éppen azzal érvelt a szolgáltató, hogy saját titkosító algoritmust fejlesztett ki, de hogy mi az, na, azt nem árulja el. Ha nem vagy terrorista, a levelezést amúgy nem az NSA-tól kell félteni, hanem mondjuk egy üzleti versenytárstól, aki alighanem meg tud fizetni olyan szakit, aki technikai tudással és/vagy kapcsolati tőkével szinte bármelyik szerverbe bele tud nézni, ha eleget fizetnek neki. Eloszlatnám azt a közhelyet, hogy "minek foglalkozni vele, mert úgyis feltörhető", tökéletes biztonság nincs, viszont elfogadható biztonság igenis van. És általában nem a legdrágább megoldásokkal. 

Ha egyéni felhasználóként vagy cégvezetőként arról szeretnél informálódni, hogy mi az, ami tényleg biztonságosnak tekinthető, ne a zöldségest, hentest vagy a szomszéd neandervölgyi kinézetű, informatikus végzettségű photoshop-artistát kérdezd, hanem olyat, aki ért is hozzá, mondjuk mert ez a hivatása. Ha a netről informálódnál, az csalóka lehet, ugyanis az ezzel kapcsolatos netes keresésnek csak akkor van értelme, ha pontosabb képed van róla, hogy mit is keresel, azaz az értékes információhoz nem meglepő módon eleve jól kell feltenni a kérdést. 

Securityreactions tumbliról schmittelt képpel zárnám soraimat: 

"Why aren’t you worried about the NSA spying on your internet use or emails?"

0 Tovább

"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.

9 Tovább

Tanárplagi: ahol már a vizsgabeugró is plágium


De nem ám a hallgató által adott válaszok, hanem az oktató által írásban feltett tesztkérdések!

Zaválnij Bogdán

Nos, ha a szellemi tulajdon védelméről van szó, az alatt a jónéhány év alatt, mióta elkezdtem foglalkozni ezzel a témával, láttam már a kategóriában a "bolti csokilopástól" kezdve a "profin kivitelezett terrorcselekményig" mindent. Azt hiszem, hogy nem szorul különösebb magyarázatra, hogy miért nem villantok rendszeresen konkrét eredményekkel ezen a területen, elvégre nem szeretném izgalmasabbá tenni az életem a delikvensek revansa miatt, akik vélhetően nem szeretik, ha a szakmai reputációjukat kidumálhatatlan veszteség éri, mert kimondom nekik: LOPTATOK. Az más kérdés, hogy bizonyos esetekben tudományetikai kötelességem az illetékeseket anonim módon tájékoztatni róla.

Zaválnij BogdánNyugi, a minimálisan szükségesnél jobban nem megyek bele, hogy forrásmegjelölés nélkül elhappolni szellemi tulajdont miért sokkal súlyosabb dolog, mint azt a többség gondolja, a mostani eset pedig ugyan pitiáner, mi több, a műfajon belül a biciklilopás kategória, a régóta betegeskedő felsőoktatás egyik súlyos tünete.

Történt ugyanis, hogy közzétettek egy beugrót az arra adható válaszokkal együtt a Pécsi Tudományegyetem TTK-ján tanuló informatikus hallgatóknak az Operációs rendszerek tárgyhoz, a beugró egyébként ala' natúr itt tekinthető meg.

Jól látod. De ez nem ám valamiféle draft, hanem maga a dokumentum, magyar kérdésekkel, schmittelés-gyanus angol válaszokkal, összességében pedig már-már alulmúlhatatlan igénytelenséggel. PTE-s forrásaim tényként kezelik, hogy a kérdéssort az Operációs rendszerek tárgyat idén tanító Zaválnij Bogdán készítette és adta ki, azaz magának a dokumentumnak a metaadatait nem kellett megvizsgálni lévén, hogy azok nem relevánsak.

A kérdések kivétel nélkül I. A. Dhotre Operating Systems könyvéből illetve a Silberschatz, Galvin és Gagne Operating System Concepts Essentials szintén ARR jogvédett művéből származnak.

Nos, azzal - hangsúlyozom: a gyakorlatban - még különösebb probléma nem lenne, ha egy oktató egy sima kollokviumi vizsgaanyag elkészítéséhez - akár változatlan formában - máshonnan emel át szövegrészeket, azzal már igen, ha a közzétett anyagban semmilyen formában nem jelöli meg a forrást.

Zaválnij Bogdán egyébként PTE-s körökben egy fogalom a maga módján, az olvasó számára pedig érdekes lehet, hogy mégis ki lehet az, aki ilyen remek mestermunkát ad ki a kezéből. Az egyik személyes oldalát elnézve nem egy webergonómia zseni, az biztos, a MarkMyProfessor oldalon megjelent review-k pedig szintén magukért beszélnek.

A PTE TTK egyik kiadványában saját maga beszél arról, hogy az ELTE fizikus szakát félbehagyva átment az ELTE orosz szakára, amit ismétcsak megszakítva a BME mérnök informatikus szakán tanult, amit megszakítva ismét visszament orosz szakra, ahol orosz szakos diplomát szerzett orosz anyanyelvűként vélhetőleg cca. 10 év alatt, amiért innen is gratulálok! Ezt az értéket egyébként a neten fellelhető információk alapján saccoltam be, például az alapján, hogy a 2003-as OTDK munkájának elkészítése idejét harmadéves volt.

Egyetemi oktatói pozíciókat jobb családokban kemény szakmai sztenderdeknek megfelelő pályázat útján lehet elnyerni, ehhez képest az interjúban Zaválnij saját maga mondja el, hogy őt egy ismerőse hívta a PTE-re és ment is.

Teljes interjú innen tölthető le http://ptettkhok.hu/tietekp/2011/december.pdf‎ ha esetleg "elveszne", akkor innen

Ha eddig nem dobtad volna el az agyad azon, hogy a PTE több, saját maga által felállított szabályzatnak ill. az akkor hatályos jogi környezetnek szembemenve felvett egy bölcsészt egyetemen programozást tanítani, aki anno még PhD-fokozattal sem rendelkezett [az interjú azt a téves benyomást kelti, hogy a PhD akkor már megvolt], majd most fogod: végül szerzett ugyan PhD-t jópár évvel később filozófiából

Zaválnij BogdánA dolog pikantériája, hogy már a PhD-tézisek is az általam megkérdezett két, filozófiával hivatásszerűen foglalkozó kutató véleménye szerint tudományos nívóját tekintve finoman fogalmazva alacsony.

Hagyjuk is Zaválnij Bogdánt, így is jobban belementem a kelleténél ökörhúgy egyenességű életútjának felvázolásába, vissza a plágiumhoz és főként annak beláthatatlan következményeihez.

Ahogy írtam, az egész beugró-kérdéssorral az igénytelenségét leszámítva nem lenne semmi gáz, ha meg lenne jelölve, hogy honnan lettek az anyagok átvéve. Nem lettek. Ez pedig rendkívül rossz üzenet a hallgatók felé. Hogyan várható el a hallgatótól, hogy kellő tudományos és etikai normáknak megfelelően készítsen el akár egy órai beadandót, akár a tudományos diákköri dolgozatát, akár a diplomamunkáját, ha még az oktatótól is azt látja, hogy még a beugró kérdések is mindössze két könyvből lettek összekukázva? Hogyan várható el a hallgatótól az, hogy a tudományhoz egészséges mértékű alázattal viszonyuljon, amikor azt tapasztalja, hogy egy szakmailag megkérdőjelezhető kompetenciájú oktató a már emlegetett, nyilvánosan elérhető források alapján gyakorlatilag random osztályozza a Drága Jó Népet? És egyáltalán: mi várható az utánpótlástól, ha ilyen mintákat lát az erre fogékony egyetemista korosztály? Ezek bizony törpegalaxisok fajsúlyával bíró kérdések, amire sok mindent lehet mondani, csak éppen megnyugtató választ nem.

A posztban felhasznált képek forrása a hvg.hu.

UPDATE (13:28 CEST): egy másik forrás szerint úgy fest, hogy "csak" fordítási plágium történt, ezt a fájlt maga az oktató készítette.

http://bardoczi.net/static/zavalnij-bogdan/beugro.pdf (md5: BE3CBF90CEE51993EC8F49BE64C14A6B)

0 Tovább