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)

Vérciki hibát találtak a világ egyik vezető vírusirtójában magyar kutatók


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

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

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

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

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

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

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

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

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

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

Kép: blog.varonis.com

0 Tovább

Reggeli villámokosság: kifejezések első előfordulása a neten


azelsosprint Reblog Sprint nyelvtechnológia haladó keresés szájbarágó etimológia SZÖKIK A MÁLNAAkár egy komolyabb fórumon folytatott vitában, akár az igényesen végzett kutatásban szükségessé válhat, hogy ésszerű energiabefektetés mellett meg lehessen állapítani egy adott kijelentésről, hogy ki is mondhatta először. Az első előfordulás megsaccolásának persze számos más területe is lehetséges. Hangsúlyozom, egy-egy kifejezés első előfordulását rendszerint csak megbecsülni lehet, ezek egyike sem bizonyító erejű.

Nem akarok túl elméleti felvezetéssel kezdeni, de érdemes tudni, hogy kapcsolódó, de más műfaj az etimológia, ami az önálló kifejezések eredetének feltárásával foglalkozik, ez természetesen magában foglalja, hogy egy kifejezés miből származtatható, hogyan alakulhatott és sokszor azt is, hogy mikor. Az etimológiai eszközökről viszont tudni kell, hogy egy-egy konkrét kérdést nem lehet velük felelősségteljesen megválaszolni mélyebb nyelvtudományi, nyelvtörténeti tájékozottság nélkül. A másik, hogy minél nagyobb korpusz áll rendelkezésre az adott nyelven, annál bőségesebb és pontosabb adatbázisokat tudnak kiépíteni a kutatók, viszont még a legtöbb természetes beszélővel rendelkező nyelvek esetén sem lehet minden kifejezésről 100%-os pontossággal megállapítani a származását és első előfordulását. A magyar pongyolán fogalmazva közepes írásbeliségű nyelv, viszont az etimológiai szótárak közt már több is elérhető a neten, ilyen például a Tótfalusi-féle etimológiai nagyszótár

Érthetően sokkal nagyobb információtartalommal feltöltött és régebbi, megkockáztatom, hogy az összes közül a legkomolyabb etimológiai adatbázis az Etymonline angol nyelvű változata, ami – az én ismereteim szerint – pontosságában még a több természetes beszélővel rendelkező mandarin kínai, hindi és spanyol etimológiai adatbázisok pontosságát is lepipálja.  

Na de mi a helyzet a gyakorlattal? Azaz amikor egy idézet első előfordulását szeretnénk megállapítani. Több eszköz is van, amik közül csak a legegyszerűbbeket említem.

A Google Keresőben adjuk meg a kifejezést idézőjelezve és/vagy válasszuk ki a verbatim keresési módot, ami jelezni fogja a kereső felé, hogy a kifejezés szó szerinti előfordulására vagyunk kíváncsiak. Ezt követően, precízebb találatot kapunk, ha nem a felajánlott opciókat használva, hanem keresőoperátor megadásával állítjuk be, hogy kimondottan időbeli előfordulásra vagyunk kíváncsiak.

Azaz ha arra szeretnénk választ kapni, hogy melyik dokumentumban fordult először elő az a kifejezés, hogy

szökik a málna

akkor a következő keresőkifejezést építhetjük fel. Az egyik valahogy így néz ki

"szökik a málna" before:2016/05/23

természetesen ha nincs találat, akkor a before: és az after: operátorokkal lehet játszani, ezzel szűkíteni a találati halmazt, ami fontos, hogy mivel keresőoperátorokról van szó, a keresőkifejezés literálja(i) után kell, hogy álljanak, csupa kis betűvel, kettősponttal. Ínyencek próbálkozhatnak még a daterange: operátorral, ahol Julianus-naptár szerinti értékkel kell megadni azt a dátumtartományt, amiben a kifejezést keressük.

Bizonyos esetekben hasznos lehet még a Google Trends bevetése, ami ugyan csak tömeges előfordulású kifejezéseknél hatékony, kiindulópontnak jó lehet például olyan szempontból, hogy mikor kezdte el foglalkoztatni a net népét az a téma, amihez az adott fogalom szorosan kapcsolódik.

azelsosprint Reblog Sprint nyelvtechnológia haladó keresés szájbarágó etimológia SZÖKIK A MÁLNA

Miért is kezdtem azzal, hogy csak saccolni lehet ezekkel az egyszerű módszerekkel, pontosan megállapítani az első előfordulást nem vagy csak kivételes esetben? A sok-sok ok közül az egyik az, hogy abban az esetben, ha a dokumentum, amiben a kifejezést elsőként szerepelt, már törölve lett, egy idő után a Google indexből is kikerül, így nyilván nem jelenik meg a keresési kifejezések közt, mint gyorsítótárazott tartalom. A másik ok, hogy a Google igencsak hasonlóan olvassa a webhelyeket, ahogyan az ember, márpedig szinte minden korszerű webhelyen vannak olyan dinamikus elemek, amik más-más tartalmat jelenítenek meg a külön-külön lapletöltések alkalmával. Kevésbé kocka módon fogalmazva: gyakorlatilag minden hírportál ajánlgat korábbi vagy éppen újabb cikkeket az alatt a cikk alatt, amit aktuálisan olvasunk, hasonló témában, amit persze a Google is figyelembe vesz. Ez viszont technikai szempontból azt jelenti, hogy hiába fordul elő például az

"részeg árvíztűrő tükörfúrógép támadt a súlytalan rugóra"

egy olyan posztban, ami mondjuk 2016. május 23-án jelenik meg, mivel nem egy statikus oldalról van szó, lévén, hogy közben újabb elemek jelennek meg a cikk alatt, amikor a Googlebot újra pásztázza az oldalt, az ő kis snapshotjához tartozó időbélyeget meg fogja változtatni egy későbbi időpontra, így olyan, mintha a kifejezést valójában csak később írták volna le. Megoldás: nincs mese, a találatok egy részét külön-külön meg kell nézni, és abban látható a poszt, twit, cikk, akármilyen bejegyzéstípus pontos dátuma.

Ezen kívül segíthet még az inurl: operátor, ha azt úgy adjuk meg, hogy az operátor után az URL-ekben gyakran előforduló formában adjuk meg a dátum egy részét. Példa:

"részeg árvíztűrő tükörfúrógép támadt a súlytalan rugóra" inurl:2016/05

persze több találat esetén az inurl: után megadott dátumnál egyre korábbi dátumokkal lehet próbálkozni, de szóba jöhet még az intitle: is.

Soha ne felejtsük el, hogy nem csak Google Search létezik a világon, más-más keresőkben más-más haladó keresési operátorok érhetők el.

Gépház üzen: a kérdésekre nem fogok tudni a megszokott sebességgel válaszolni pár napig :(

0 Tovább

DDoS szájbarágó – annyira azért nem bonyolult


Lényeg, hogy bárki, de tényleg bárki indíthatja, csak pénz kérdése. Csak a feketepiacon be kell boltolni egy ún. botnet hálózatot, amiről volt szó korábban. Azaz olyan fertőzött gépek tömegét, ami egy Command and Control szerver irányításával, tipikusan a fertőzött gépek tulajdonosainak tudta nélkül képes támadást indítani egy adott célpont felé.

0 Tovább

Meghamisított email - amit mindenkinek illene tudnia


 email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítésAhogy egyre nagyobb részben folytatjuk a személyes és munkához kapcsolódó kommunikációt is a neten, folyamatosan vált egyre fontosabbá, hogy minden olyan eszköz, ami ezt biztosítja egyre stabilabb és biztonságosabb legyen. Ezeknek az szolgáltatásoknak az egyike az email, ami - ahogyan írtam a korábbi posztomban - mai formájában legalább három évtizede létezik, megelőzte a web születését közel tíz évvel, a net legősibb, máig széles körben használt szolgáltatása és alighanem minden webes óriást túl fog élni, amiről ma még nem gondolnánk, hogy valaha bizony vége lesz.  
 
Kiemelt fontosságú, hogy ha emailt kapunk, ellenőrizhető legyen, hogy a feladó valóban az-e, akinek gondoljuk, ezt pedig sokszor ugyan azokra a technikákra támaszkodva lehet megtenni, amit spamvédelem céljából kitaláltak. Egy durván meghamisított levél példáján mutatom be, hogy mikor mit érdemes nézni, az emailek hosszú fejléce minden webes levelezőrendszerben megjeleníthető, a legelterjedtebb Gmail esetén például a levél megnyitását követően a legördülő menüben a Show original pontra kattintva. 

email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítés

email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítés


 Amikor valaki egy nevet és egy hozzá tartozó email címet lát a feladó mezőben, teljesen természetesnek veszi, hogy a levelet az írta, akinek a neve és címe olvasható, nemde? Óriási tévedés! Az, hogy a feladó neve és a cím mezőben mi álljon, csupán egy adalék információ, amit a feladó szervere az email fejlécéhez hozzáfűz, viszont semmiféle megkötés nincs azzal kapcsolatban, hogy ott mi szerepelhet, mi több, még az sem megkötés, hogy ki legyen töltve. Viszont abban az esetben, ha valaki megmókolja a levelezőrendszert a levélküldés idejére olyan módon, hogy az valamilyen tetszőleges címet csapjon a levélhez, a levél elmegy ugyan, a címzettnél akár a spam mappába megy, akár sem, a levelezőrendszerek a címzettnél jó esetben figyelmeztetnek azzal kapcsolatban, hogy a levél valószínűleg hamisívány. Viszont, ahogy a frissen előállított példában látszik, simán lehet, hogy nem, annak ellenére, hogy minden arra utal, hogy a levél hamisítvány, mégsem jelzett a Gmail emiatt. Hamisított levélre utaló figyelmeztetést eredményezhet más is legitim levelek esetében, viszont érdemes tudni, hogy hogyan tudható meg esetleg több a valódi feladó kilétéről. 
 
Nosza, lássuk azt az előbb emlegetett hosszú fejlécet! 
 
Delivered-To: bardoczi@gmail.com 
Received: by 10.27.186.198 with SMTP id k189csp415282wlf; 
        Fri, 8 Jan 2016 03:48:06 -0800 (PST) 
X-Received: by 10.140.101.201 with SMTP id u67mr91933194qge.33.1452253686478; 
        Fri, 08 Jan 2016 03:48:06 -0800 (PST) 
Return-Path: <president@whitehouse.gov> 
Received: from ecbiz178.inmotionhosting.com (ecbiz178.inmotionhosting.com. [104.193.143.56]) 
        by mx.google.com with ESMTPS id r9si92146028qhb.7.2016.01.08.03.48.06 
        for <bardoczi@gmail.com> 
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); 
        Fri, 08 Jan 2016 03:48:06 -0800 (PST) 
Received-SPF: softfail (google.com: domain of transitioning president@whitehouse.gov does not designate 104.193.143.56 as permitted sender) client-ip=104.193.143.56; 
Authentication-Results: mx.google.com; 
       spf=softfail (google.com: domain of transitioning president@whitehouse.gov does not designate 104.193.143.56 as permitted sender) smtp.mailfrom=president@whitehouse.gov 
Received: from localhost ([::1]:63179 helo=ecbiz178.inmotionhosting.com) 
    by ecbiz178.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) 
    (Exim 4.85) 
    (envelope-from <president@whitehouse.gov>) 
    id 1aHVWX-000DKS-T9 
    for bardoczi@gmail.com; Fri, 08 Jan 2016 06:48:06 -0500 
Received: from 179.43.161.147 ([179.43.161.147]) by 
 secure178.inmotionhosting.com (Horde Framework) with HTTP; Fri, 08 Jan 2016 
 11:48:05 +0000 
Date: Fri, 08 Jan 2016 11:48:05 +0000 
Message-ID: <20160108114805.Horde.zOWNX3cXXgeNf-MxqaUvuw5@secure178.inmotionhosting.com> 
From: President of US <president@whitehouse.gov> 
To: bardoczi@gmail.com 
Subject: =?utf-8?b?aGFkw7x6ZW5ldA==?= - fake =?utf-8?b?bGV2w6ls?= 
Reply-to: akos@null.net 
User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) 
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes 
MIME-Version: 1.0 
Content-Disposition: inline 
Content-Transfer-Encoding: 8bit 
X-OutGoing-Spam-Status: No, score=3.6 
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report 
X-AntiAbuse: Primary Hostname - ecbiz178.inmotionhosting.com 
X-AntiAbuse: Original Domain - gmail.com 
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] 
X-AntiAbuse: Sender Address Domain - whitehouse.gov 
X-Get-Message-Sender-Via: ecbiz178.inmotionhosting.com: authenticated_id: akos@genetics.bardoczi.net 

 
A valódi küldő felhasználó azonosítása és a feladó mező összevetése az első lépés.  
 
email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítésA hosszú fejléc sorai közt az X-szel kezdődők nem kötelezők a levelezőrendszerek számára. A levelezőrendszereknek nem kötelező hozzáfűzniük, hogy egy levelet pontosan milyen felhasználó vagy alkalmazás feladói felhatalmazásával küldenek, viszont ha nem totálisan hülyén van konfigurálva a levelezőrendszer, akkor tartalmaz ilyet, ez jelen esetben az "authenticated_id: " sor, amivel gyakorlatilag semmi sem stimmel. A sorban lévő akos@genetics.bardoczi.net csak annyit mond, hogy amikor a levelezőrendszer átvette kézbesítésre a levelet, akkor ezzel a felhasználói névvel lett feljogosítva a levélküldésre. Ha semmilyen azonosítás nem feltétele egy levél kiküldésének, ún. open relay szerverről beszélünk, azaz olyan levelezőszerverről, amin keresztül bárki bármit küldhet bármiféle azonosítás nélkül. Mivel valamikor rég ezeket előszeretettel használták a spammerek, open relay-t már nagyon keveset találunk, hiszen ha olyan helyről érkezik email, azzal valami teljesen biztos, hogy nem stimmel. Ugyan vannak a neten olyan oldalak, ahol egyszerűen csak meg kell adni, hogy mi kerüljön a feladó, a tárgy és az üzenet mezőbe, hova menjen az email, az ilyen levelek jobb helyeken közel biztos, hogy spamben landolnak, másrészt általában még az ilyen kamu emailek sem open relayen keresztül mennek, hiszen a hamisító szolgáltatás van feltüntetve küldésre feljogosított felhasználóként, ami persze csak a hosszú fejlécből derül ki. Viszont vegyük észre, hogy legalább van lehetőség azonnal kideríteni, ellentétben például a Facebook-üzenettel, amivel a továbbiakban nem fogom hasonlítgatni az emailt.  
 
A bűvös boríték és "vissza a feladónak", azaz envelope és return-path 
 
Ha jobban megfigyeljük a levelet, figyelmesek lehetünk az egyik Received sorban található "envelope-from <president@whitehouse.gov>" részre. Az envelope, azaz boríték azonosításához a levelezőrendszerek sokszor külön sort hoznak létre, akkor biztosan, ha az nem egyezik a valódi emailcímmel, ami felhasználói név is egyben. Még a Return-path sorban is a hamis email cím szerepel, ami azt a címet tartalmazza, ahova a címzett szerverének mailer daemonjától várja a visszaküldést akkor, ha a kézbesítés sikertelen valami miatt, azaz ide pattan vissza a feladóhoz a levél. Egy szó, mint száz, ebben az esetben (sem) szerepelt valami fényesen a legelterjedtebb kommersz levelezőrendszer a kamu levél kiszűrérében. 
 
A postás és a postahivatal  
 
Persze az azonosított feladó cím lehet, hogy még mindig nem mond semmit, az első Received sorban lévő szerver hosztneve és IP-címe már egyértelműen azonosítja, hogy mi is vette át a levelet küldés céljából elsőként:  
 
Received: from ecbiz178.inmotionhosting.com (ecbiz178.inmotionhosting.com. [104.193.143.56]) 
 
Márpedig ha ennek utánanézünk például az ARIN adatbázisában, abból kiderül, hogy a levél egy mezei hosztingszolgáltatótól jött, ráadásul azon belül is egy olyan szerverről, ahova a filléres hosztingot igénylő ügyfelek oldalait teszik, mint amilyen az én életrajzi oldalam. Ennek ténye egyre valószínűtlenebbé teszi, hogy a levél valóban a Fehérházból jött volna.  
 
Amikor az email küldéshez szerver sem kell  
 
Megjegyzem, elvben az is megoldható, hogy valaki az otthoni gépére telepítsen olyan szolgáltatást, amin keresztül tud levelek küldözgetni úgy, hogy maga a levelezőszerver is az ő otthoni gépe. Normál esetben egy levelezőszerver IP-címéhez tartozik egy hosztnév, ebben az esetben a reverse hostname-re gondolok, azaz ha nem tudnánk, hogy a ecbiz178.inmotionhosting.com hosztnévhez a 104.193.143.56 cím tartozik, a cím alapján meg lehet nézni a hosztnevet, már ha van.   
 
Egy egyszerű internetszolgáltatással rendelkező gépnek viszont nincs feltétlenül szüksége arra, hogy ahhoz hosztnév legyen hozzárendelve, abban az esetben pedig, ha mégis van hozzárendelve, akkor arról általában süt, hogy otthoni felhasználók gépeinek, végfelhasználóknak kiosztott hosznévről van szó. Egy UPC-s magánelőfizető IP reverzje aaa.bbb.ccc.ddd cím esetén catv-aaa-bbb-ccc-ddd.catv.broadband.hu lesz, azaz látszik ugyan, de ebből azonnal kiderül az is, hogy nem szerverről, hanem valakinek az otthoni gépéről van szó, a címre egyszerűen elég rákeresni az európai és közel-keleti IP-ket nyilvántartó RIPE-adatbázisában, ha nem lenne elég egyértelmű. Hasonlóan például egy Vodafone-os magánelőfizető címe hiába reverselhető, a RIPE lekérdezés alapján egyértelmű, hogy magánelőfizetőről van szó és nem pedig levelezőszerverről:  
 
 Még egy kicsit a hamisított feladói címről  
 
Adott címről érkező levél esetén természetesnek vesszük, hogy arra simán válaszolva a címzettnél meg is érkezik valami. Amikor emailt küldünk valakinek, a kézbesítéshez többek közt a domain név szolgáltatáson keresztül le kell kérdezni a hosztnévhez tartozó ún. MX-rekordokat, ami azt dönti el, hogy a beérkező emaileket mely gépek kezeljék, azaz kik töltik be a postahivatalok szerepét, ha a domain-nevet tekintjük a címzett városának. Ez a freemail.hu esetén például fmx.freemail.hu ugyan a netes szolgáltatások szabványosításáért dolgozó IETF azt javasolja, hogy levelet fogadó domainhez legalább kettő MX-rekord, azaz „postahivatal” tartozzon arra az esetre, ha az első valami miatt nem érhető el vagy túlterhelt, de ne is legyen belőle 10-nél több. Persze könnyen lehet, hogy ha csak egy MX-rekord van, akkor az egy terheléselosztó vagy tűzfal, mögötte sok-sok postással. Mégis gyakoribb megvalósítás, hogy MX-rekordból több van, a secure.bardoczi.net domain esetén például 14, földrajzilag gondosan távol egymástól, épphogy a Holdon nincs.   
  
Viszont ha az email címben szereplő domainhez nem tartozik MX-rekord, akkor gyakorlatilag biztos, hogy kamu címről van szó, hiszen MX-rekord nélkül az adott domain nem tud emailt fogadni, az pedig életszerűtlen hogy úgy működjön egy domain név, amiről csak küldeni tud, de fogadni már nem. A genetics.bardoczi.net jelen esetben ilyen:  

http://mxtoolbox.com/SuperTool.aspx?action=mx%3agenetics.bardoczi.net&run=toolpage  

Mi lehet a célja egy ilyen emailes scamnek?  
 
Felmerül a kérdés, hogy a példában hozott scam emailnek mi lehet a célja, miért kér a feladó bankkártyaadatokat, ha ezek szerint a president@whitehouse.gov címre érkezett levelet úgysem kapná meg, mivel nem is ő küldte? És egyáltalán: mindig érdemes a levél tartalma alapján felállítani néhány forgatókönyvet azzal kapcsolatban, hogy valaki kamu címmel, kamu személyazonossággal vajon miért írja pont azt, amit? Ebben a levélben ugye arról van szó, hogy ha a címzett nem küldi a bankkártyaadatait, itt bizony vér fog folyni. Mivel a Gmail rövid fejlécéből nem derül ki semmi szokatlan, a laikus felhasználó gondolhatná, hogy ha a válasz gombra kattint, a levél a whitehouse.gov-os címre küldi a levelet, ha viszont kamu, úgyis visszapattanna, nemde? Igen ám, viszont abban az esetben, ha a válaszcím, azaz az a cím, amire a feladó a választ várja, eltér a feladó címétől, ilyenkor a levelezőrendszernek kötelező elhelyeznie egy Reply-to sort, amiben pedig az akos@null.net cím van, aminek aligha van bármi köze is a Fehérházhoz. Viszont amikor az egység sugarú felhasználó a válasz gombra kattint, egyáltalán nem veszi észre, hogy a címzett mezőben már más cím szerepel, mint amiről a levél érkezett, amit épp megválaszol és erre a levelezőprogramok nem is hívják fel a figyelmet!  
 
Jelen példa persze blőd, de gondoljunk bele, hogy a feladó mezőben simán szerepelhetne egy bank címe is, a levélben a bankra jellemző arculati elemekkel és persze hihetőbb szöveggel, a válaszcím pedig lehet bármilyen ingyenes mailszolgáltatónál létrehozott, esetleg totálisan visszakövethetetlen emailcím, amire a csaló a kért adatokat megkapja, ha az áldozat válaszol is rá.   
 
A spamekkel és scamekkel vívott automatizált küzdelem  
 
email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítésFelmerülhet a kérdés, hogy hogyan jelenthet csak a spam önmagában sok-sok százmillió dolláros össz-veszteséget évről évre, ha olyan levelekről van szó, amiket a felhasználó úgysem olvas el? Úgy, hogy a spamek küldése, fogadása mind használja az IT erőforrásokat, legyen szó akár az adatátvitelről, akár arról, hogy ezeket a leveleket a levelezőszervereknek fel kell dolgozniuk, ami ugye processzoridőben mérhető, és persze valameddig tárolni is kell őket, aminek szintén forintosítható-dollárosítható ára van. Ahogyan annak is, ha az alkalmazott megnyit egy spamet, ha az olvasására csak negyed percet szán, az is a munkaidejéből megy el. Mindezek bagatell apróságoknak tűnnek, de ha nagyban gondolkozunk, ha már felhasználók számilliói érintettek, érthető, hogy miért kerül nagyon sokba a spam, még ha jól is van szűrve, nem is beszélve arról az esetről, amikor egy fontos levél falspozitívként kerül spambe és valaki nem értesül időben valamiről, ami egyébként fontos lenne. A scam, azaz a megtévesztő levél más műfaj és máshogy is okoz költségeket és kellemetlenségeket, például ha a felhasználó olyan linkre kattint, amivel valamivel alaposan lefertőzi a gépét, amit az antivírus termék nem szúr ki.  
 
Ami a spamben és a scamben közös, hogy nyilván minél jobban hasonlítaniuk kell a legitim levelekhez, hogy megtévesszék a spam- és scamszűrő rendszereket és eljuthassanak a felhasználókig. Így a versenyfutás a spammerek és a levelek biztonságáért felelős fejlesztők és kutatók közt folyamatos. Alapvetően a legitim és fölösleges-kártékony levelek szűrése a tartalom és a fejléc automatizált elemzésével történik. A tartalom alapú elemzéssel itt egészen röviden foglalkozom. Igencsak kifinomult gépi tanuláson alapuló mechanizmusok dolgoznak a háttérben, amikor nagy mintán tanulják a szerverek, sokszor közösen, hogy mik a spamek és a legitim levelek jellemzői, ez alapján következtetnek.  
 
A gépi tanulás lényegéről korábban már itt írtam annak kapcsán, hogy hogyan idomítottak be egy gépet arra, hogy megkülönböztesse az előnyös és az előnytelen szelfiket. A kifinomult tanulóalgoritmusok helyett vegyük a legegyszerűbb hipotetikus spamszűrőt: ha tudjuk, hogy egy 1000 levélből álló mintában abból a 200-ból, ami tartalmazza a Viagra kifejezést pontosan 199 spam, akkor a jövőre nézve biztosak lehetünk benne, hogy ha jön egy levél, aminek a szövegezésében a Viagra szerepel, jó eséllyel ugyancsak spam lesz. Ez az ún. Bayes-valószínűségen alapuló szűrés.  
 
Vissza a fejlécekhez  
 
A levélszemét szűrésének tartalmi elemzést megelőző lépése viszont a – sokkal kisebb számításigényű – fejlécelemzés, ráadásul ha a fejléccel túl sokminden nem stimmel, a levelet esetleg a szűrő már nem is vizsgálja tartalmi szempontból. A header elemzésekor többek közt a levelezőrendszer olyan sajátosságok után kutat, amikről írtam a poszt első felében, azaz amik végképp nem jellemzők egy normális emailre. Másrészt idővel bevezettek olyan technológiákat, amik a fejlécben helyeznek el extra, az emailt hitelesítő sorokat, azaz olyan sorokat, amiket pillanatok alatt ki tud elemezni első körben a fogadó szerver. Ezek ugyan messze nem tökéletesek, de jobbak, mintha csak tartalom alapú elemzésre és az alapvető ellentmondások elemzésére támaszkodhatna a spamszűrő.  
 
A Sender Policy Framework, avagy SPF  
 
A legősibb és legegyszerűbb megoldást az SPF jelentette. Szinte minden levél hosszú fejlécében találunk SPF-re vonatkozó sort, ami mutatja, hogy a domainhez beállított SPF-szabályokkal összevetve a levelet milyennek értékelte a szerver. Az SPF-szabályokat pedig a doménnév szolgáltatásból tudja lekérdezni. A kiértékelés eredménye lehet semleges, legitim vagy éppenséggel bukó, de ezzel a levél sorsa természetesen nem dől el végleg, hanem csak hozzáad vagy kivon abból a pontszámból, ami fölött a fogadó szerver egy levelet spamnek talál.  
 
Példaként, ha az SPF-szabály IP-cím alapján van meghatározva a domainhez tartozó domain név szerverben, az egy ilyesmi bejegyzés lehet a domainhez tartozó rekordok közt:  
 
v=spf1 a:kuldoszerver.example.com –all  
 
Ez annyit jelent, hogy a fogadó fél megnézi a küldést végző hosztnév IP-címét vagy hosztnevét és ha az egyezik azzal az IP-címmel, ami a kuldoszerver.example.com domainhez tartozik, akkor az a levél legitim, minden más esetben viszont valószínűleg spam, ezért el kell dobni, amit a -all paraméter határoz meg.  
 
Az SPF szűrési logikája alapulhat még más egyéb tényezőkön is, a fenti példát azért választottam, mert a legegyszerűbb, de van még pár beállítási lehetőség bőven.  
 
Fontos, hogy az SPF nem élet és halál ura, azaz ha például egy adott domainről érkezik hamisított feladóval egy levél, amit biztosan nem a domainhez tartozó levelezőszerveren keresztül küldtek, akkor az az SPF szerint spam ugyan, viszont a kifinomultan konfigurált spamszűrő csak egy valószínűségi értéket rendel hozzá, hogy ennek alapján a levél elbuktott, legitim vagy semleges. Hosszú lenne kifejteni, de az SPF működésmódjából adódóan egyrészt még ez is megkerülhető a spammerek számára, másrészt elvben előfordulhat, hogy egy teljesen legitim levél repül spambe. Másrészt ahogy írtam, az SPF megléte a névszerveren  nem is kötelező.  
 
Példaként ha valaki nem webes felületről, hanem kliensprogramból használja a postafiókját, viszont Indamailt vagy Freemailt használ, amivel a levelek letölthetők ugyan, viszont küldeni levelezőprogramon keresztül nem lehet, a felhasználó kénytelen lesz más szervert használni a küldéshez, például a netszolgáltatója levélküldőjét, azaz SMTP-szerverét. Könnyen belátható, hogy az előző SPF-logika alapján a levél minimum spamgyanusnak lesz nyilvánítva a fejléce alapján, ilyen szempontból kész szerencse, hogy eléggé kevesen használnak levelezőprogramot böngésző helyett a levelezéshez, viszont akik igen, ezt általában tudják is. Azt hinnénk, hogy a túl szigorú SPF beállítás, azaz amikor a szűrést végző szerver nem csak lepontozza a levél hitelességét, hanem vakon az SPF alapján jár el és el is dobja azt, nem túl gyakori beállítás. Sajnos olyan cégek is gyakran rosszul konfigurálják a szűrést küldésre és fogadásra vonatkozóan, amikről nem hinnénk.    
 
DomainKeys, DKIM és az Identified Internet Mail  
 
Ezek a megoldások elvben nem voltak jobbak vagy rosszabbak, mint az SPF, hanem teljesen mások, gyakorlatilag viszont jóval korszerűbbek, számos olyan sajátossággal rendelkeztek, amik mégis nagyban megnehezítették egy-egy email meghamisítását.  
 
Mindháromnak az alapját az jelenti, hogy a domaint működtető névszerveren be van állítva egy publikus kulcs, amit a küldő szerver aláír, majd a fogadó fél szervere lekérdezve ezt a publikus kulcsot ugyancsak a névszerverről, a feladó legitimitásának azonosításán túl azt is ellenőrzik, hogy az emailt átvitel közben esetleg nem hamisították-e meg, ami sokkal gyakoribb és egyszerűbb, mint ahogy azt az Olvasó gondolná.  
 
Ugyanakkor több szempontból sokkal nagyobb rugalmasságot biztosít, mint az SPF, hogy mást ne mondjak, elvben az SPF egy sima szöveges rekord ugyan a névszerveren, mi több, lehet el kilométeres is, gyakorlatilag a fogadó fél gyakran nem értelmezi a szabályt, ha 255 karakternél hosszabb.  
 
A Yahoo által kitalált DomainKeys és a Cisco-tól származó IIM összegyúrásából született DKIM esetén viszont ugyanazzal az email-címmel való üzenet küldéséhez használhatjuk teljesen eltérő szolgáltatók küldő szervereit is, a küldő szerver egyszerűen csak hozzácsapja a nyilvános kulccsal és persze az általa használt titkosító algoritmussal kiszámított ellenőrzőösszeget, amit a fogadó fél majd ellenőriz. Ugyan a DomainKeys-t, azaz DK-t, amit gyakran kevernek a DKIM-mel, elvben felváltotta az utóbbi, gyakorlatilag viszont nagyon sok szerver előnyben részesíti, ha a levél a régivágású módszerrel is alá van írva. Annyira, hogy a példánál maradva a Gmail máig csak akkor fogad el teljesen hitelesnek egy levelet, ha helyes DomainKeys értéket is talál benne.  
Az alábbi ábrát az appmaildev.com-ról vettem át:  
 

email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítés

Hogy a saját leveleink tartalmaznak-e SPF, DK és DKIM értékeket, valamint azok helyesek-e a http://www.appmaildev.com/en/dkim/ -en ellenőrizhetjük, ahol egy email-címre küldött levelet követően a szolgáltatás egy részletes elemzést fog visszaküldeni.  
 
Hasonló, kevésbé részletes, de áttekinthetőbb eredményt ad, ha  a http://dkimvalidator.com oldalon megjelenő email címre küldünk emailt, majd néhány másodperc múlva megnézzük az eredményt.  
 
Esetleg marginálisnak tűnik foglalkozni ilyen részletekkel, egyszer mindenkinek érdemes eljátszania vele azért is, mert abban az esetben, ha valaki egy beígért emailt nem kap meg, annak senki sem örül főleg akkor nem, ha fontos emailről lett volna szó.  
Az emailek itt ismertetett hitelesítése protokoll-szinten működik, még mindig összesen csak annyit bizonyít, hogy egy-egy adott levelet a feladó postafiókjából küldtek, azt viszont nem, hogy valóban a postafiók tulajdonosa küldte, nem pedig valaki, aki odament a lezáratlan gépéhez vicceskedni ebédidőben.  
 
Alkalmazásréteg szintjén a levelek hitelesítése a korábban tárgyaltaktól teljesen függetlenül a digitális aláírással oldható meg, aminek de facto standardja a PGP, aminek az alapjairől korábban írtam itt  a finomhangolásáról pedig ebben a posztban.  
 

Igaz, nemrég ígértem, hogy bemutatom, hogyan azonosítható egy webes felületről elküldött Gmail-es levél földrajzi helye, annak ellenére, hogy a Gmail-en keresztül küldött levél nem tartalmazza a kliens IP-címét - ellentétben a Google Apps-en keresztül küldött levelekkel, amik igen! -  mindez esélytelen lenne ésszerű terjedelemben úgy, hogy közérthető is legyen - viszont kommentben tippelni lehet!  
Képek: filterforge.com, pophangover.com, themetapicture.com 

0 Tovább

SSL/TLS: hogyan hallgathatják le a munkahelyén?


Ahány munkahely annyi szokás, viszont alighanem mindenki belefutott már abba a kérdésbe, hogy vajon mennyire jó ötlet a munkahelyi gépet magáncélra használni, mennyit tudhat róla az IT-s, a főnök, esetleg olyan is, aki jóval pletykásabb az elviselhetőnél.

Vannak munkahelyek, ahol az alkalmazott azonnal aláír egy nyilatkozatot azzal kapcsolatban, hogy a munkahelyi IT infrastruktúrát csak a munkájához szükséges célokra és módon fogja használni, ha pedig ez a policy változik, arról a munkahelynek őt is köteles értesítenie. Ez jellemzően tartalmazza azt, hogy a munkahelyi levelezés nem használható másra a rendeltetésén kívül és ezt a munkahely ellenőrizheti, mondjuk szúrópróbaszerűen és ez így helyes. Ami viszont már sokkal kacifántosabban, esetleg kevésbé érthetően van megfogalmazva, hogy a munkahely milyen mélységig láthat bele az alkalmazott netezésébe, ami a privát kommunikációját is érintheti. Főleg akkor, ha a zavarosan megfogalmazott szabályzat kiterjedhet a BYOD-eszközökre is, azaz azokra a kütyükre, amiket az alkalmazott saját maga visz be és a céges hálózatot használják.

UTM ITsec biztonság SSL TLS firesheep kriptográfia szájbarágó

Amivel alighanem mindenki egyetért, hogy a munkahelyére alapvetően dolgozni jár az alkalmazott, tehát mindenki joggal várhatja el, hogy ne csessze el az időt olyannal, aminek semmi köze nincs a munkájához. Ugyanakkor nagyon gyorsan kiderült az is, hogy azokon a helyeken, ahol letiltották az egyértelműen magán célra szánt, közkeletű alkalmazások használatát, mint a Twitter, a Gmail vagy a Facebook, az alkalmazottak feszélyezettebben érezték magukat, ennek megfelelően a produktivitásuk is csökkent. Röviden: az olyan típusú szolgáltatások tiltásának bevezetése, amik mindennapi kommunikációnk részévé váltak és megszoktuk, hogy elérhetőek, amikor kell, értelemszerűen csak feszültséghez vezethet. Ugyanakkor természetesen senkinek sem jó, ha az alkalmazott elcsetelgeti a munkaidő felét.

Komolyan nem tudnám megmondani, hogy melyik a legidiótább céges korlátozás, amiről olvastam vagy hallottam, de alapvetően kerülendő minden olyan módszer, ami az alkalmazottban olyan benyomást kelt, mintha a főnöke a háta mögött egész nap azt figyelné, hogy hogyan dolgozik. Természetesen kivételek vannak, kritikus feladatokat ellátó szervezeteknél nyilván megengedhetetlen lenne biztonsági szempontból, hogy onnan az alkalmazottak szabadon netezgessenek, így esetleg lefertőzzenek véletlenül egy olyan hálózatot, ami egy SCADA-rendszerhez vagy minősített adatokat tartalmazó rendszerhez kapcsolódnak valamilyen módon. Ahogy az is ismert, hogy több hadsereg nagyon helyesen megtiltotta az állománya tagjainak, hogy egyáltalán a közösségi webet használják.

Ami általánosságban elmondható, hogy az alkalmazottak alapvetően tájékozatlanok, aminek eredményeként veszélyeztetik egyrészt a céges adatok séthetetlenségét, másrészt a saját magánszférájukat is.

2010-ben hatalmas botrányt kavart a Firesheep, ami lényegében egy olyan böngésző-kiegészítő volt, ami lehetővé tette, hogy a géppel egy hálózaton lévő több gép titkosítatlan adatforgalma már-már kínos egyszerűséggel teljes egészében lehallgatható legyen. Azaz bárki, elemi informatikai előismeretekkel láthatta és jókat derülhetett rajta, hogy tőle nem messze egy kollégája miket olvas éppen a neten. Nem az az érdekes az egészben, hogy megjelent egy böngészőbővítmény, ami lehetővé tett, hogy egy mezei felhasználó úgy láthassa a másik tevékenységét, ahogyan az a zsékategóriás kémfilmekben ábrázolni szokták. Ugyanis ennek a lehetősége már ezer éve adott volt, az olyan jól ismert alkalmazások, mint mondjuk a Wireshark ugyanerre képes volt már a Firesheep előtt 10 évvel korábban is, csak éppenséggel azzal a különbséggel, hogy a Wireshark által sniffelt adatforgalom nem úgy jelent meg, mint valami kémfilmben, hanem az adatcsomagokat szépen összerakva pici hozzáértéssel simán olvasható volt a titkosítatlan forgalom, ami származhatott vezeték nélküli hálózatból és persze vezetékes hálózatból, azaz például a munkahely helyi hálózatára csatlakozva egyaránt.

UTM ITsec biztonság SSL TLS firesheep kriptográfia szájbarágó

Tehát igaz, hogy a probléma ismert volt már száz éve, mégis egy, végülis teljesen átlagos, mindenki számára használható böngészőbővítményre volt szükség ahhoz, hogy a világ legnagyobb szolgáltatói arra kényszerüljenek, hogy az alapértelmezett beállítás az legyen, hogy a felhasználó böngészője és a szerver közti adatforgalmat titkosítsák. Ez a gyakorlatban nem csak abból látható, hogy a böngésző címsorában a cím https-sel kezdődik, hanem az is, hogy az elején látható egy - jó esetben zöld színű, nem törött - lakat ikonja, amire rákattintva láthatjuk, hogy a kommunikáció egészen pontosan milyen titkosítás mellett történik, és egy ún. certifikátum megfelelően igazolja-e, hogy a webhely, amire kapcsolódunk, valóban az a webhely-e, aminek a címét a címsorban látjuk.

De hát ha a címsorban az áll, hogy www.bankom.tld, akkor az csak a bankom webhelye lehet, nem? Nem. Amikor a böngészőbe beírjuk a címet, a kérést az oprendszeren keresztül átadja a DNS-szervernek, ami alapértelmezés szerint mindenkinek a saját internetszolgáltatójának azon két szervere, amelyik elvégzi a névfeloldást, azaz megkeresi vagy megkeresteti a webcímhez tartozó IP-címet, ez visszakerül a böngészőhöz a kommunikáció innentől a felhasználó címe és böngészője, valamint a DNS-től megtudott www.bankom.tld oldal IP-címe közt fog folytatódni végig. /*egyszerűsítve*/

Kivéve, amikor nem!

Ugyanis lévén, hogy semmi sem garantálja azt, hogy a névfeloldásra irányuló kérésbe senki sem fog belepiszkálni a felhasználó és a szolgáltató DNS szerveri közt ún. közbeékelődéses támadással

Másrészt a szolgáltatók DNS szerverei ha mondjuk az elmúlt néhány órában már több milliószor feloldottak egy bizonyos címet, nem fogják ismét megkeresni azt a net dzsungelében, hanem a gyorsítótárból, "emlékezetből" veszik elő azt, a legnagyobb sérülékenységet pedig pont ez jelenti. 2008-ban éppen egy névfeloldással kapcsolatos sebezhetőség sokkolta a világot.

Tételezzük fel, hogy a támadók sikeresen beléptek a szolgáltató DNS-szerverére  és a nemrég lekért, www.bankom.tld hosztnévhez tartozó IP-címet aaa.bbb.ccc.ddd-ről átírták xxx.yyy.ppp.qqq címre, ez utóbbi pedig egy, a Karibi-térségben vagy hasonló remek klímájú országban elhelyezett szervert jelöl, amin olyan webhely fut, ami megtévesztésig hasonlít a www.bankom.tld bejelentkezőoldalára. Az ügyfél ekkor beírja a felhasználói nevét és jelszavát, amit a támadók naplóznak. A belépési adatok megadása után a felhasználó hibaüzenetet kap, miszerint rosszul adta meg a belépési adatait, majd átirányítják a valódi webhelyre, ahol már szabályosan be tud lépni, viszont nem veszi észre, hogy a bejelentkezéshez szükséges azonosítókat a támadók ellopták.

Ez ugyan egy erősen egyszerűsített példa volt a DNS működésével és annak eltéríthetőségével kapcsolatban, hiszen nincs olyan hülye bank, ami ne használna az éles felületen titkosított kommunikációt, a szerver és a kliens azonosítását, a belépés vagy egy-egy konkrét banki művelet pedig plusz egy jóváhagyást kérnek az ügyfelektől, ami mondjuk egy SMS-ben érkező számsor megadása. Viszont tartsuk észben, hogy számos levelezőrendszer van mind a mai napig, aminek a webes felülete nem alkalmaz titkosított kommunikációt, ilyen esetben ha a DNS-t célzottan eltérítik, olyan, mintha a felhasználó teljes egészében odaadta volna a postafiókja használati jogát a támadónak.

A DNS eltérítés gyakoribb, egyszerűbb, na meg sokkal kevésbé feltűnő módja, ha nem a szolgáltató DNS kiszolgálóját piszkálják meg, hanem a felhasználó gépét kihasználva azt, hogy a kliens szintén gyorsítótárazza a korábban feloldott neveket. Ha például valaki folyamatosan a Gmail-en lóg, nem fogja a böngésző minden alkalommal arra utasítani az operációs rendszert, hogy kérdeztesse le a Gmail.com-hoz tartozó IP-címet, amikor megszólítja az oldalt, hanem azt a lekéréseket cachelő helyről vagy egy,  állandó hosztnév-IP-párosokat tartalmazó, de megmókolt fájlból húzza elő, ez a másik módja a DNS hijackingnek.

Miután tisztáztam, hogy a névfeloldás jelentősége mekkora, nem csoda, hogy gyakorlatilag minden kicsit is normális operációs rendszer és személyi tűzfal úgy kezeli a hosztnév-IP-cím párosokat tartalmazó fájlba való beavatkozási kísérleteket, mintha a támadó páncéltörvővel próbálna bejönni az ajtón. Könnyebb megérteni, ha belenézünk ezekbe a fájlokba.

OSX esetén a fájlt /private/etc/hosts helyen találjuk, a legtöbb linux disztróban az /etc/hosts alatt, ha csak kimondottan át nem helyezték, míg Windows esetén a rendszergyökér\Windows\System32\drivers\etc\hosts.txt fájlban. Ez ugyan csak az állandó hozzárendeléseket tartalmazza, így nem valami izgalmas, viszont kis trükkel előcsalható, hogy az operációs rendszer az adott pillanatban miket gyorsítótárazott, itt jelen esetben biztosan meg fogjuk találni mondjuk azt, hogy a reblog.hu-hoz  a 84.2.32.100 vagy 84.2.32.101 cím, esetleg egy ún. kanonikus név tartozik. Nosza! A lista megjelenítéséhez viszont ismét lehet, hogy adminisztrátori jogosultságokra lesz szükség. A Windowsban egyszerűen el kell indítani egy parancssort adminisztrátori jogosultságokkal, majd ott kiadni az

 ipconfig /displaydns | more

parancsot, majd lehet is böngészni benne.  

Nem kell pánikba esni, ha a vártnál sokkal több hosztnevet látunk, hiszen nem csak a webes böngészéshez kapcsolódó címek láthatók it. Ha gyakran frissít a víruskeresőnk, fut közben a Skype, meg még  ki tudja mi, minden alkalmazás és szolgáltatás, ami használja a hálózatot kapcsolódik pár jóhelyre. Tovább bonyolít a helyzeten, hogy a terheléselosztás miatt egy hosztnévhez tartozhat több IP-cím is, egy IP-címhez több hosztnév, de még egy adott webhely is a tartalmainak egy részét teljesen más hosztnévről cibálja be, így például a Facebookra töltött képek esetén a scontent.xx.fbcdn.net helyről, aminek további IP-címei vannak.

Az olvasó esetleg korábban is tudott róla, hogy mi is a névfeloldás, mostanra világosabb lehet, hogy hogyan is működik, ebből adódóan mekkora kockázata annak, ha ebbe valamilyen módon beleberhelnek, a harceddzettebb bitbúvároktól elnézését kérek az egyszerűsítésekért.

A DNS-eltérítés kockázatát persze már az internet hajnalán felismerték, ezért ki kellett találni egy olyan megoldást, ami azonnal beavatkozik vagy jelez, ha erre utaló jelet talál. És persze egy pillanatig se felejtsük el, hogy ennek a megoldásnak teljesen függetlennek kellett lennie az átvivő közegtől, ideértve a csatorna köztes szakaszait is. Azaz függetlennek kell lennie attól, hogy a netező LAN-kábelen keresztül csatlakozik, titkosítatlan wifin keresztül, az adatcsomagok egy ideig telefonkábelen keresztül haladnak át, mire célbaérnek keresztülmennek 8-10 szerveren, útválasztón, amikről azt sem tudni, hogy kié és így tovább. Azaz feltétel volt a tervezésnél, hogy legyen független a megoldás a fizikai, adatkapcsolati, stb. rétegektől, így került a megoldást jelentő SSL és a vele gyakorlatilag azonos TLS [Transport Layer Security] és ami kapcsolódik hozzá, megjelenítési rétegbe.

Hogy szemléletes legyek, tételezzük fel, hogy egy papírcetlin szeretnék üzenni valamit a kollégámnak és olyan valakit bíznék meg azzal, hogy a papírcetlit vigye el neki, akiről tudom, hogy biztos, hogy úgyis elolvassa, másrészt még pletykás is, a papírcetlire az üzenetet mondjuk arab avagy japán nyelven írom, amit a címzett megért ugyan, de aki átadja neki a cetlit, nem. Ez esetben az, akit megkérek a levél továbbítására, a fizikai vagy adatkapcsolati rétegnek feleltethető meg, míg ami a cetlire kerül az átvivő számára értelmezhetetlen nyelven, megfeleltethető az alkalmazási vagy megjelenítési rétegnek.

Az SSL/TLS titkosítási és azonosítási feladatokat is ellát. Amikor arról van szó, hogy mennyire okos dolog mondjuk reptéri nyílt wifit használni netbankoláshoz vagy levelezéshez, alapvetően azért hülye a kérdés, mert ha SSL titkosítás mellett működik az adott webhely a böngészőbe, hiába hallgatja le a wifit valaki, az a kommunikáció, ami a laptop és a banki szerver vagy levelezőszerver közt bonyolódik, értelmezhetetlen adatmasszaként fog csak megjelenni, hiszen titkosított. [SSL/TLS-t viszont nem csak a böngésző használ! Lazán kapcsolódik, de ilyenkor ésszerűen azt kellene figyelembe venni, hogy a laptopon futhatnak olyan szolgáltatások, amik viszont sehogy sem titkosítanak. Okostelefonok pedig gyakorlatilag általános, hogy az appok erőforrásigényének csökkentése miatt számos alkalmazás egyáltalán nem használ titkosítást vagy csak nagyon gyengét, ami igencsak rizikós annak tudatában, hogy az okosmobilok többsége, hacsak nincs készenléti állapotban, automatikusan csatlakozik a nyílt hálózatokhoz, ha olyat lát, a mobil gyengén vagy sehogy sem titkosító szolgáltatásai és alkalmazásai pedig kapásból küldik is az adatokat a szervereik felé.] Akit a titkosítás pontos módja érdekel, itt olvashat róla

UTM ITsec biztonság SSL TLS firesheep kriptográfia szájbarágó

A titkosítással a gyakorlatban együtt jár, hogy egy, a kommunikációtól független, harmadik  fél előzetesen tanusítványt állított ki a szerver számára, ami igazolja, hogy ő tényleg az, akinek mutatja magát a kliens felé, akárcsak a szerver személyi igazolványa lenne. A böngészőprogramok pedig szintén tudják, hogy milyen típusú tanusítványokat fogadnak el és ha olyan tanusítvánnyal találkoznak, amivel valami nem stimmel, azonnal jelzik a felhasználó felé.

Visszautalva arra, amit a cikk elején írtam, ha a szolgáltató oldalán a DNS-szerver a névfeloldásokat hibásan végzi, a gyorsítótárában hamis hosztnév-IP-cím összerendelések vannak, ennek megfelelően téves adatot ad át a kliensnek, előfordulhat, hogy a http://bardoczi.net címen valamilyen kábszicsempész-gyilokpornós-fegyverkereskedős cég oldala jelenik meg. Ugyanez történik akkor is, ha a felhasználók  gépén az emlegetett hosts fájlokban valótlan párosítások vannak megadva, lényeg, hogy a felhasználó fejében meg sem fordul, hogy alighanem nem azt az oldalt látja, amit keresett.

Abban az esetben viszont, ha valaki a httpS://bardoczi.net címet látogatja meg, számos forgatókönyv elképzelhető, ha a DNS-kérés hamis. A jólnevelt böngésző azonnal jelez, hogy a domainnévhez tartozó certifikátumot a Comodo olyan módon állította ki, hogy a bardoczi.net hosztnévhez a 70.39.146.219 IP-cím tartozik, viszont a tartalom ennek ellenére mégsem erről a címről csorogna be, hanem teljesen máshonnan – teljesen más tartalommal. A felhasználónak lehetősége van arra kattintani, hogy vállalja a kockázatot és mégis betölti az oldalt, de csak annál a látogatásnál, minden újabb látogatásnál a böngésző erre újra rá fog kérdezni. Ami viszont tragikus, hogy a böngészők a mai napig lehetővé teszik, hogy egy-egy oldal "hamis személyivel" felkerüljön a kivételek közé, azaz a felhasználó minden látogatásakor a problémás certit elfogadja a böngésző, ami nem csak annyit jelent, hogy a felhasználó esetleg nem is azt az oldalt látja, amelyiket szeretné, hanem man-in-the-middle támadással más az egész adatforgalmat lehallgathatja. A certi részletei egyébként minden böngészőben lekérdezhetőek a címsor elején lévő lakatra kattintva.

Nos, képzeljük el, hogy valaki egyszer elfogadott egy hamis tanusítványt - vagy valaki, akivel közösen használják a böngészőt – ezen kívül a hosts fájl is meg van buherálva. Így előfordulhat, hogy hónapokon keresztül úgy használja mondjuk a gmail.com-ot, hogy azt valaki, akinek a szerverén keresztül megy az adat, aki a már említett közbeékelődéses támadással a felhasználó és a gmail.com közt áll, minden nehézség nélkül lehallgatja felhasználónévvel, jelszóval, a küldött levelek tartalmával, mindennel együtt! Az azonosításon kívül a titkosítás arra is kiterjed, hogy az adatfolyamot bizonyos méretű adatblokkonként ellenőrzi, hogy megfelelően titkosított-e, ha nem, figyelmeztet vagy eldobja a kapcsolatot menet közben.

Ha a böngésző tanusítványhibát jelez, annak ugyan lehet számos más oka is, de mindig mérlegeljünk előtte, hogy megéri-e a kockázatot, ha továbbmegyünk.  

Egyre több szervezet alkalmaz ún. UTM, azaz unified threat management megoldásokat aminek a lényege, hogy a biztonságot veszélyeztető szolgáltatásokat nem külön-külön küszöbölik ki. Azaz nem külön egy tűzfalas megoldás figyeli a hálózati forgalmat, egy antivírus megoldás kergeti a vírusokat, ezen kívül megint másik arra ügyel, hogy az alkalmazottak véletlenül ne küldözgessenek kifelé olyan információkat, amiket nem szabadna, hanem ezeket egy szolgáltatás suite-ba csomagolják. Itt ismét néhány egyszerűsítéssel fogok élni. Képzeljük el, hogy az elérendő célja az IT staffnak, hogy az alkalmazottak ne használjanak Yahoo Mail-t céges adatok átküldésére, de nem akarjuk elzárni őket a privát levelezésüktől sem. Azaz ezt valahogy ellenőrizni kell. Ekkor nincs mese, annak ellenére, hogy a Yahoo levelezője titkosított forgalmat bonyolít a szerver és az ügyfél közt, valamilyen módon meg kell figyelmi a forgalmat tartalmi szempontból olyan nyomok vagy mintázatok után kutatva, amik arra utalnak, hogy valaki nem túl bölcs módon mondjuk üzleti szempontból kritikus információkat küldözget, amiről tipikusan nem is tudja, hogy mennyire kritikus, csak azt, hogy a kollégának kényelmesebb átküldeni Yahoo-n, ha már úgyis oda van belépve. Megint más esetben ha már Facebookozik az alkalmazott, a forgalom titkosított ugyan, mégis ellenőrizni kell, hogy véletlenül se kattintson olyan linkre, amivel lefertőzi a céges gépet.

Van-e megoldás arra, hogy az alkalmazott magánszéfrája ne sérüljön, ugyanakkor mégis maradjon házon belül az az infó, amit házon belül szeretne tartani mondjuk egy vadászrepülőket tervező cég? A rövid válasz, ahogyan sejthető: nincs.

Ha valaki bele akarna fülelni a titkosított forgalomba, a böngésző azonnal jelezne, aminek annyira nem örülne a felhasználó. Mit lehet kezdeni azzal az adatfolyammal, ami titkosított? Nincs mese, fel kell oldani valahogy a titkosítást, dekódolni kell, megszaglászni, hogy nincs-e benne valamilyen kényes adat, majd titkosítani, de már a céges szerverrel és úgy továbbítani a  külső szerver felé. Ha a külső szerver persze észleli, hogy valaki belepiszkált az adatfolyamba, ennek megfelelően lehet, hogy egy olyan ködös hibaüzenetet dob, hogy nem felel meg a kapcsolat az elvárt biztonsági standardoknak, ezért vége a mókának. A webes szolgáltatások viszont nagyon sok esetben sokkal megengedőbbek, ha SSL-ről és certikről van szó, mivel tisztában vannak vele az üzemeltetők, hogy lehetnek olyan felhasználók is, akik annyira régi böngészőt használnak, amelyik az alkalmazott titkosítási módszert még nem támogatja megfelelően vagy olyan államból használnák a szolgáltatást, ahol a webes szolgáltató és az adott állam megállapodást kötött azzal kapcsolatban, hogy a felhasználóikat lehallgathatják. Kínában például így

UTM ITsec biztonság SSL TLS firesheep kriptográfia szájbarágó

Felmerül a kérdés, hogy mégis hogyan oldják meg a titkosított kapcsolat elemzését alkalmazó cégek azt elegánsan, hogy a felhasználók ne kapjanak figyelmeztetést, maximum törött lakat látszódjon a címsorban, ami azt jelzi, hogy titkosított a kapcsolat ugyan, csak a másik fél, azaz a szerver valódisága nem garantált? Úgy, hogy a céges gépre az előtelepített böngészőbe a célnak megfelelően megmókolt tanusítványok kerülnek, mivel tudható, hogy a magán kapcsolattartásra leggyakrabban használt webhelyek melyek és milyen certit használnak, amihez a cég hozzábiggyeszti a sajátját. Ezen kívül a cég saját DNS-szervereket használ, ami a szükséges oldalakat eltéríti.

Azért valami feltűnőbb nyoma csak van annak, ha gyakorlatilag hakkolva van az a technológia, amit arra fejlesztettek ki, hogy a kliens és a szerver tökéletesen bízhasson egymásban, nem? Igen, viszont olyan helyen, amit a felhasználó tipikusan soha az életbe nem néz meg. Ahogy már írtam, a címsor elején lévő lakatra kattintva, majd azon belül a tanusítvány részleteit kiválasztva jeleníthetők meg a szerver hitelesítésével kapcsolatos részletek. Ez például a LinkedIN esetén a Digicert által LinkedIN-nek kiállított tanusítvány, a Gmail esetén egy Geotrust/Google CA által Gmail-nek kiállított tanusítvány és így tovább. Abban az esetben, ha ettől eltérő tanusítványinformációkat látunk, akkor vagy a cég mókolt valamit, ahogy természetesen az sem zárható ki, hogy a céget egy kifinomult támadás érte, a támadó helyezett el  hamis certiket a böngészőben az alkalmazottak lehallgatására.

0 Tovább
«
12