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 (36),privacy (17),Facebook (17),social media (11),itsec (11),egyéb (10),social web (9),mobil (8),biztonság (8),OSINT (6),magánszféra (6),tudomány (6),szellemi tulajdon (6),jog (6),Google (5),webcserkészet (5),molbiol (5),szájbarágó (5),felzárkóztató (4),Nobel-díj (4),terrorizmus (4),kriminalisztika (4),big data (4),kultúra (4),email (4),plágium (4),Apple (3),jelszó (3),nyelvtechnológia (3),genetika (3),Android (3),biztonságpolitika (3),pszichológia (3),webkettő (3),reklám (3),élettudomány (3),gépi tanulás (3),CRISPR (3),Onedrive (3),üzenetküldés (3),2015 (3),orvosi-fiziológiai (3),online marketing (3),kriptográfia (3),molekuláris biológia (3),azelsosprint (3),torrent (3),konferencia (3),magatartástudomány (3),hype (3),biztonságtudatosság (3),open source intelligence (3),popszakma (3),levelezés (3),Gmail (3),szabad információáramlás (2),Yoshinori Ohsumi (2),bejutas (2),Hacktivity (2),Reblog Sprint (2),tweak (2),Pécs (2),génterápia (2),DKIM (2),cas9 (2),bűnügy (2),fiziológia (2),hitelesítés (2),TOR (2),kulturális evolúció (2),villámokosság (2),deep web (2),ransomware (2),bűnüldözés (2),DDoS (2),természetes nyelvfeldolgozás (2),arcfelismerés (2),FUD (2),nyílt forrású információszerzés (2),Balabit (2),P2P (2),webkamera (2),Netacademia (2),neuropszichológia (2),Whatsapp (2),SPF (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),sajtó (2),tanulás (2),biológia (2),szociálpszicholó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)

Semmi új: mindenki FB-üzenetei olvashatók voltak egy egyszerű trükkel


Két nappal ezelőtt hozta nyilvánosságra Ysrael Gurt, a Cynet kutatója azt a sebezhetőséget, amit kihasználva egy nagyon egyszerű trükkel bárki olvashatta másvalaki összes üzenetét, eddig, mivel a Facebook most végezte el a bugfixet. Arról már volt szó, hogy ne bízzunk egy szolgáltatásban csak azért, mert több száz millióan, jelen esetben pedig több, mint egy milliárdan bíznak benne, ami meg konkrétan a Facebookot illeti, a hiba még akkor is több, mint durva, ha figyelembe vesszük, hogy az üzenetküldőt messze nem bizalmas üzenetek továbbítására találták ki, majd írták át egy egyszerű XMMP-alapú chatmodulból. Nyugi, nem szedem elő ismét azt a rémesen nyomasztó jelenséget, hogy már sokan már a Messengert használják az email helyett annak ellenére, hogy mennyi elképesztő, Messengert érintő sebezhetőség jelent meg csak idén.

A mostani sebezhetőség lényege, hogy amikor csetelés vagy üzenetküldés közben a kliens XML HTTP kéréseket küld, közben egy Javascript folyamatosan ellenőrzi, hogy a kommunikáció valóban a kliens és a Facebook csetszervere közt történik-e, teszi mindezt a kérésekkel továbbítódó Access-Control-Allow-Origin és Access-Control-Allow-Credentials fejlécekkel dolgozva. A bökkenő csak az, hogy a Facebook egyedileg implementált, oldalon keresztüli kéréseket ellenőrző része megtéveszthető egy rosszindulatú, az áldozat által gyanutlanul lefuttatott Javascript-kóddal olyan módon, hogy az üzenetfolyam _bármilyen_ szerver, jelen esetben mondjuk a támadó szervere irányába menjen illetve legyen hozzáférhető. Az eredmény: a támadott felhasználó összes üzenete, annak minden csatolmányával, teljes egészében ellopható. A hiba természetesen minimum azóta rohad a Facebook üzenetküldőjében, mióta átálltak az XMMP-szerű rendszerről, azaz több éve.

A támadás kivitelezéséhez nem kell sztárhekkernek lenni, bárki kivitelezhette, aki jártas a webfejlesztésben.

A bejelentés egyszerűsített változata itt érhető el a műértők számára érdemes megnézni a teljes bugreportot itt

Az Originull-nak csúfolt sebezhetőség PoC-videója pedig itt tekinthető meg

Alighanem többen vannak, akiket a technikai részletek kevésbé érdekelnek, ezért írok egy kicsit arról is, hogy milyen, technikai problémán messze túlmutató hatása van annak, hogy világméretű szolgáltatások ilyen fájdalmas hibákat tartalmaznak. Ugyanis az este mutattam egy fejlesztő ismerősnek, aki eljópofizta a dolgot, amivel instant sikerült felidegesítenie.

A Gartner előrejelzése szerint 2020-ra a felhasználói információk átlagosan kétharmad-háromnegyed részben semmilyen módon nem lesznek megvédhetőek, ami ha valóban bekövetkezik, akkor egy eléggé vérfagyasztó szingularitás küszöbén állunk, ami a teljes civilizációra komolyabb hatással lesz, mint első blikkre tűnik. Mire gondolok konkrétan?

Egyrészt ismert, hogy mióta kialakult a mai értelembe vett emberi kommunikáció, megelőzve az írásbeliséget, ezzel egy időben jelent meg az emberben annak az igénye, hogy amit a másikkal közöl, bizonyos esetekben ne tudja mindenki. A civilizációk többségében ha négyszemközt mond az egyik fél valamit a másiknak, akkor azt nyilván azzal az elvárással teszi, hogy az az információ valóban köztük marad, hiszen számos esetben nagyon súlyos következménnyel is járhat az, ha valakitől vagy valakiktől széles körben elérhetővé válna olyan közlés, amit titokban kellene tartaniuk. És még csak nem is kell nagy dolgokra gondolni, teljesen köznapi esetekben is vannak ilyenek, hacsak valaki nem egy remete, mondott már el olyan a bizalmasainak, amik ha nyilvánosságra kerülnének, minimum vércikik lennének, de sanszos, hogy az illetőnek az egzisztenciája, melója, önbecsülése veszne oda.

Másrészt több modell igazolja, hogy a társadalmat stabilizáló egyik legfontosabb tényező az emberek egymás közti általános, egymásba fektetett bizalma, amit nyilván teljesen aláás az, ha semmit sem lehet mondani úgy senkinek, hogy ne kelljen attól tartani, hogy az a közlés bizony simán kikerülhet. Világos, hogy egy ilyen világban még a legidiótább, legnihilistább embertársunk sem élne szivesen.

Mindezek ellenére a felhasználók döntő része egyszerűen csak legyint az egészre, jön ezzel a „nekem nincs titkolni valóm” című őrülettel annak ellenére, hogy a kommunikációnk olyan mértékben a netre költözött, hogy nem nagyon tudok elképzelni olyan – csúnyán mondva - jelentéktelen embert, akinek ne lehetne okozni súlyos érdeksérelmet, ha csak úgy bele vájkálnának a netes magánéletébe és elkezdenék teregetni, amit találtak, mondjuk egy kirúgott ex.

Amit a tömeg egyszerűen nem ért meg, mi több, alighanem nem is gondolt rá soha, hogy nem csak azoknak az információknak a bizalmasságáért, sértetlenségéért felelős, amiket ő irkál másoknak, akár email, akár IM-üzenet, hanem minimum morális felelősséggel tartozik azért is, hogy megőrizze azoknak az adatoknak a bizalmasságát, amit neki küldött más annak tudatában, hogy azt csak a címzett olvassa majd, legalábbis más nem nagyon. Vegyük észre, hogy előállt egy olyan hülye paradox helyzet, hogy ma az emberek hallgatólagosan elvárják egymástól, hogy amit egymással magánüzenetben közölnek a neten, az bizalmasságát tekintve legyen olyan, mint egy négyszemközti beszélgetés, ugyanakkor egyáltalán nem szocializálódtak bele abba, hogy ennek a feltételeihez alkalmazkodniuk kell, hasonlóan ahhoz, amikor valakinek súgva mond valaki másnak valamit.

Messze nem lehetetlen, hogy konkrétan elszabaduljon a pokol, ha nem szokik hozzá egyszerűen mindenki ahhoz, hogy hogyan kommunikáljon magánban a neten ésszel, éberen, tudatosan. Miért mindenki? Azért, mert én hiába járok el a legnagyobb körültekintéssel, amikor valakinek üzenetet küldök, ha az illető nem veszi komolyan azokat az újonnan megjelenő játékszabályokat a kommunikációban, amik civilizációs léptékben a levelezés vagy könyvnyomtatás megjelenésével összemérhetőek, ilyen módon tőle kikerülhet az az információ is, amit én küldtem neki bizalmasan.

Ennél jobban komolyan nem tudom elmagyarázni, hogy én amolyan tüneti kezelésként miért kérek mindenkit, hogy emailt küldjön, hívjon fel vagy ha már nagyon szeret csetelni, legalább ne valamilyen hulladékot használjon, hanem olyan alkalmazást, amit sejthetően nem lehet csak úgy megroppantani, így például Telegramot, esetleg Signalt.

Többször volt már olyan, hogy valaki nekem valamilyen traumáját nem tudta szóban elmondani, ezért elküldte emailen. Na most akkor szépen képzeljük el, ha a feladó által elküldött levelet nem csak én olvashattam volna, hanem én, plusz a csajom, plusz a legjobb barátom, akikkel alighanem a másik nem osztott volna meg egy olyan többéves traumát, amit velem osztott meg először. Oké, ilyen jellegű levelet azért nem sokat kaptam, viszont olyat rendszeresen kapok, amit a szakmai tartalma miatt felelősségem megfelelően védeni.

Hogy milyen lesz a magánszféra szép új világa? Sejthetően egy rakás, a semmiből megjelenő, parasztvakító cég fog még megjelenni, miközben még a legelővigyázatosabb felhasználó is majd csak lesegethet, mint pocok a lisztben, ha egyetlen hülye levelezőpartnere miatt a teljes köztük lefolytatott levelezés vagy más üzenetküldés kikerül, esetleg felkerül a Pastebin-re vagy a szürke- vagy feketepiacon adják el HR-cégeknek vagy egészségbiztosítóknak, miközben a magánéletét közösségi weben rutinszerűen kiteregető birkanyáj ilyen-olyan kormányzati megfigyeléstől tart.

0 Tovább

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

Paráztat a Google, de nem mondja meg, hogy miért


Google G Suite megmagyarázhatatlan megmagyarazhatatlan ITsecVolt itt már szó arról, hogy nem a legbölcsebb dolog egy olyan cég infrastruktúrájára támaszkodni és ott tárolni minden felhasználói adatot, ami egyrészt elad kilóra, másrészt a közvélemény úgy tudja róla, hogy bizony a Google azért nem ad ki adatot csak úgy holmi hatósági megkeresésre sem, ahhoz Kaliforniáig vagy ha addig nem is, írországig kell menni jogsegélyért, ott meg úgyis beintenek az adatigénylőnek. Múltkor valamelyik magyar lap, amelyiknek a DNS-adatai alapján gondolom nem csak a teljes levelezését, hanem a többi – pl. Drive – szolgáltatását is a Google vállalati verziója, a G Suite, leánykori nevén Google Apps viszi, arról cikkezett, hogy muhaha, mennyi magyar adatigénylést utasított el a Google, ami amúgy itt tekinthető meg.

A hamis biztonságérzetnél pedig nem sok rosszabb van. Merthogy ha valaki nagyon akar, semmi szüksége rá, hogy a Google-höz intézzen adatkérést egy magyar Google felhasználóval kapcsolatban.

Egy kis ismétlés: arról már írtam, hogy ahhoz, hogy a Google Magyarországon elfogadható sebességgel tudjon szolgáltatni – pláne nagy adatforgalmat generáló tartalmakat [Drive, Youtube] – nincs mese, hazai ún. peering vonalakra van szüksége az adatok előtöltéséhez, ami – most figyeld! – nagyobb sávszélességű, mint a Magyar Telekom és a UPC együttvéve a maga laza 60 gbps-es sávszélességével. Az előtöltéshez persze nem csak külföldi irányból fogadni kell az ésszel felfoghatatlan mennyiségű adatot, hanem nyilván Magyarország területén tárolni is.  Ezt ún. CDN-szolgáltatókkal megállapodva teszi, aminek a lényege, hogy olyan, mintha a Google belföldről szolgáltatna, ugyan már nem vagyok annyira biztos benne, hogy ezek a CDN-kiszolgálói adatparkok hol vannak helyileg, a lényeg viszont, hogy ha magyar felhasználó adatát lopná valaki, nyilván csak a megfelelő szerverhotelt kellene megkörnyékeznie.

Ha még mindig nem világos, hogy ez miért elengedhetetlen, plusz egy kis magyarázat. A netes piacon ha valami brutálisan drága, többet közt az adatátvitel, így ha valaki feltölt egy videóklipet Kanadában a Youtube-ra és azt Magyarországon valaki megnézi, Magyarországra elő is töltődik a tartalom és a többi magyar nézőt már eleve helyből szolgálják ki, nem rohadt drágán transzatlanti kapcsolaton keresztül. Ez nem tűnik annyira parának, viszont az már sokkal inkább az, hogy ha a rendszer azt látja, hogy a leveleid és a Drive-ra töltött fájljaid rendszerint Magyarország területén nézed meg, azoknak is minimum egy példánya itt fog tanyázni. Na most innentől kezdve, hangsúlyozom, technikai szempontból nem sokkal bonyolultabb hozzáférni az elvben Google-által kezelt adathoz, mint egy Magyarországon hosztolt szerver tartalmához, az más kérdés, hogy mit mond a törvény bötűje.

Ahogy korábban már szintén írtam, annyira azért hardeningelt a rendszer, hogy az átlag felhasználót megvédjék a saját hülyeségétől, jelszólopásoktól, primitívebb támadásoktól. Azaz ha például valaki rendszerint Budapestről nézi meg a leveleit, majd fél órával az utolsó belépést követően mondjuk Párizsból lépne be, helyes felhasználói név-jelszó párossal, a rendszer joggal gyanakodhat jelszólopásra a szokatlan aktivitás miatt. A rendszer sikongat, SMS-t küld a felhasználónak plusz tokennel, amit meg kell adnia a jelszó mellett, megkérdezi a másodlagos email-címet vagy hasonló olyan adattal próbálja azonosítani a felhasználót, amit elvileg csak az account tulajdonosa tudhat, ha pedig már nagyon nagy gáz van, lezárja az egészet bekér egy személyi igazolvány scant és 1-3 USD-t, amit olyan bankkártyával kell kifizetni, aminél a bankkártyatulajdonos neve az a név, ami a Google-nél meg van adva, de ez eltarthat pár napig.

Ez az egység sugarú felhasználót megvédi mondjuk a közönséges jelszólopásos támadásoktól.

Na de mi a helyzet kifinomultabb támadás esetén? Elvben már 2012 óta a rendszer azonosítja a kormányzati eredetű támadásokat a tragikus csak az az egészben, hogy egy figyelmeztetésen kívül a felhasználó semmilyen további információt nem kap!

2005-ben, amikor gyakorlatilag csak USA-ban élő ismerőstől érkező meghívóval lehetett regisztrálni a Gmail-re, ilyen módon übermenőnek számított, regisztráltam én is, nem olyan rohadt nehéz kitalálni, hogy milyen azonosítóval. Aztán ugye a többi Google-szolgáltatást is ehhez kapcsolták hozzá, gyakorlatilag innentől van értelme arról beszélni, hogy Google Account.

 Google-szolgáltatásokat már évek óta nem használnék, ha nem lenne nagyon muszáj:
-    webanalitikára ingyenes eszközök közül a Google Analytics megfelel
-    a zene a Youtuberól megy
-    keresőbarátabbá válik az a tartalom, amit a Google Plus-ban megosztok a nevemmel
-    rám lehet írni Hangouts-on, rendszerint annyit válaszolok, hogy írjon bárhol máshol : )
-    Translate
-    spam-előszűrés G Suite-tel

Hirtelen ennyi jut eszembe. Erre ma mi jön szembe Translate használat közben? Inkább mutatom:

Google G Suite megmagyarázhatatlan megmagyarazhatatlan ITsec

Nem, nem adathalász oldal volt, kattintottam is a Secure my account gombra, mire kijön ez:

Google G Suite megmagyarázhatatlan megmagyarazhatatlan ITsec

Szóval minden fasza, oszoljanak, nincs itt semmi látnivaló. Mondjuk még meg lehet nézni egy semmitmondó support oldalt, de belépve a Google Security dashboardjára, már ha lehet annak nevezni ezt a szart, ami az átlag felhasználók számára biztos igen hasznos, semmi, de semmi nem derül ki! Azaz például hogy miből következtetett a Google arra, hogy engem biza’ valamelyik kormány próbál meghakkolni, milyen típusú volt a szokatlan aktivitás. Összehasonlításként abban a levelezőrendszerben, amiért fizetek, minden típusú sikeres és sikertelen hozzáférés naplózott olyan ezer évre visszamenőleg.

Röviden: ha advanced userként még mindig ragaszkodsz ehhez a szarhoz, azon se lepődj meg, ha a legszigorúbb biztonsági beállítások mellett megpróbálnak hozzáférni az információidhoz, de semmilyen adatot nem találsz azzal kapcsolatban, hogy mi történhetett.

Az ITsec-szcénában közhelyes, hogy nem az a kérdés, hogy valamit valakik feltörnek-e, hanem az, hogy mikor. Ha nem vállalati környezetről van szó, valami miatt érdekes felhasználó esetén nem az a kérdés, hogy hozzáférnek-e az ingyenes szarokban tárolt információihoz egyszer, hanem az, hogy az mennyire fog fájni. Az meg konkrétan felfoghatatlan, hogy ma egy cég miért választja a Google vállalati suite-ját, aminek az előnye abban merül ki, hogy a webes felület nagyon hasonló, aztán a nyelvújítás táján született felhasználóknak sem kell újat megszokni. A céges környezetben alkalmazott Google suite tehát nem megmagyarázhatatlan: tájékozatlan IT döntéshozó + kényelmes felhasználók.
Ez van.

Kép: Techworm

0 Tovább

Képernyőzár-hekkelés, 10 másodperc alatt


Rob Fuller Hak 5 LAN Turtle munkaállomás feloldása ITsec HacktivityLezárod a géped, ha elmész ebédelni? Ha nincs megfelelően védve, feloldható a képernyőzár, függetlenül attól, hogy OSX vagy Windows fut, mindössze egy 50 dolláros USB-eszközzel.

Amikor szeptember elején találkoztam egy nem mindennapi sebezhetőséggel Rob Fuller egyik blogposztjában, aminek a közérthetőbb magyarázata is megjelent néhány nappal később,  még nem voltam benne biztos, hogy ez azért tényleg ennyire egyszerű és hatékony.

Végfelhasználói szempontból a dolog eléggé egyszerű, ha valaki odamegy egy géphez, aminek a felhasználója be van ugyan jelentkezve, de azért lezárta a munkaállomást, amíg nincs előtte, egy USB-kütyü csatlakoztatásával néhány másodperc alatt feloldható a jelszó ismerete nélkül.

A támadás lényege nagyon egyszerűsítve az, hogy abban az esetben is megkísérli telepíteni az oprendszer a rá csatlakoztatott USB-eszköz illesztőprogramját, ha az egyébként le van zárva, ezt követően pedig az USB-stick minden további nélkül beblöffölheti a rendszernek, hogy valójában egy ethernet-kábelt csatlakoztattak hozzá. Ezt követően a gép, ha korábban wifire volt csatlakoztatva, a vezetékes hálózati kapcsolatot fogja előnyben részesíteni, azon keresztül kísérli meg a hálózati kommunikációt és a megbuherált eszközön lévő, a rendszeren egyébként is létező, de módosított hálózati szolgáltatások indulnak el, konkrétan a DHCP és a Responder szerez olyan jogosultságokat, amivel már elérik a felhasználó bejelentkezési adatait és annak ismeretében feloldják a gépet.

Nagyon úgy tűnik, hogy valóban hatékony, mivel nem sokkal egy hónap elteltével már a neten is rendelhető a Hak 5 LAN Turtle eszköz, konkrétan 50 dollárért, ami ráadásul az összes elterjedetbb Windows-verzió és a legújabb OSX-ek esetén is működik.  

Érdemes megfigyelni, hogy a kísérletezésből, az ötletből mennyire gyorsan válhat piacképes termék, na meg azt, hogy az operációs rendszerek fejlesztői alighanem tudnak a lehetőségről, a megérkező frissítést a felhasználók jórésze alighanem úgysem telepíti, így a módszer a gyakorlatban is használható marad, ha az automatikus frissítés valami miatt le van lőve vagy nem működik, nem is kevés ideig.

Közhelyes, de igaz: minden hekkelhető. Legyen szó akár az ipari vezérlőrendszerek védelmének megkerüléséről, akár egy személyszállító repülőgépről [elvben], de rég ismert, hogy a vezeték nélküli egerek és billentyűzetek kommunikációja is jóideje relatív egyszerűen, olcsón és észrevétlenül lehallgatható, ahogy arról szó lesz a heti Hacktivityn is.

Kép: Techworm

2 Tovább

Hekkerek, testközelben


ITsec Hacktivity webes biztonság alkalmazásbiztonság etikus hekkelés ajánlóSzándékosan nem azt az elcsépelt kérdést adtam címként a posztnak, hogy "Hogyan legyél hekker?" vagy hasonló, több szempontból is, például azért, mert nem kevésbé jól sikerült írás született korábban a témában. Mivel én is rendszeresen megkapom ezt a kérdés, pontosabban azt, hogy hogyan érdemes elkezdeni foglalkozni informatikai biztonsággal, ezért itt vázlatosan összefoglalom az álláspontom.

Az első és legfontosabb, hogy ha van kifejezés, ami eléggé utálok, az maga a "hekker". Emlékszem, még sok-sok évvel ezelőtt a Hacktivity-n volt egy sehova sem vezető kerekasztal-beszélgetés azzal kapcsolatban, hogy valójában ki hekker, ki nem hekker, a kívülállók számára hogyan lehetne megváltoztatni a hekkerekről kialakított negatív képet, ami szerint a hekker a tudásával visszaélő, törvényeket megszegő szararc.

Véleményem szerint teljesen értelmetlen azon dolgozni, hogy a hekker kifejezést a magyar nyelvben megpróbáljuk újraértelmezni ugyanis – itt jön a lényeg – etimológiai szempontból az amerikai angol hacker kifejezésből származik ugyan, de szerinte semmi köze ahhoz, a magyar nyelvben mióta létezik, mindig is pejoratív volt. Jól jegyezzük meg: a magyar nyelvben soha az életben nem volt semmiféle pozitív jelentéstartalma a hekker kifejezésnek, egyszerűen kulturális okokból, például amiatt, ahogyan a számítógépes bűnözéssel kapcsolatos híreket interpretálta a sajtó még a 90-es években. Ez nem jó vagy rossz, egyszerűen ez van, kész. Ezzel szembemenni körülbelül olyan értelmetlen, mint kitalálni, hogy holnaptól a feketére használjuk a fehér kifejezést és fordítva. Ami már teljesen más kérdés, hogy az ebből származtatott kifejezések már természetesen nem mind pejoratívak, például az etikus hekker, amelyik fedi az eredeti angolban ethical hacker kifejezés jelentését és olyan IT biztonsági jómunkásembert jelöl, aki egy megbízásnak megfelelően, de alapvetően ugyanazokat az eszközöket használva, mint egy támadó, felméri egy-egy IT rendszer sérülékenységét.

A fogalomról tehát ennyit. De mégis, mit lehet mondani annak, aki érdeklődne az IT biztonsági témák iránt, foglalkozna vele, de nem tudja, hogy hogyan vágjon neki? Több vélemény szerint nincs igazán jó válasz, mert ha valaki eléggé involvált, kíváncsi, akkor már magától úgyis elkezdett bütykölni valamit, legyen az akár szoftver, akár hardver, akár maga az emberi magatartás, én rokon területnek tekintem a haladó keresési és információkinyerési technikák művészetét is, de lehetne még folytatni a sort.

Én ezzel a véleménnyel nem értek egyet. Lehet valaki kitűnő szoftverfejlesztő, akit érdekelne a biztonság, de nem igazán tudja, hogy hogyan fusson neki. Erre azt tudom mondani, hogy az IT security olyan, mint a programozás: nem lehet könyvből megtanulni, normálisan viszont könyv, mégpedig jó sok könyv nélkül szintén nem.

Vannak olyan etikus hekker képzést kínáló helyek Magyarországon is, amik hajmeresztő összegekért kínálnak oktatást úgy, hogy állításuk szerint az ő képzésükhöz nem szükséges előzetes programozási tudás. Mese habbal, ilyen a világon nincs! Ha nem is kell vérprofi programozónak lenni, de mindenképp legalább alapszintű, de bombabiztos programozási ismeretek szükségesek ahhoz, hogy valaki hozzá tudjon szagolni a témához, ami plusz jó, ha már adott egy bizonyos hacker mentality ez viszont kialakulhat menet közben is.

ITsec Hacktivity webes biztonság alkalmazásbiztonság etikus hekkelés ajánlóNéhány évvel ezelőtt a "hogyan kezdjem?" kérdésre még Erickson Hacking – The Art of Exploitation művét ajánlottam, ami nagyon penge módon, a szoftverek elemi működéséből kiindulva veszi sorra azokat a témákat, amiknek a megértése és megismerése után már bőven tud mit kezdeni a megszerzett tudással az érdeklődő, majd továbbhaladni.

Úgy fogalmaztam, hogy néhány évvel ezelőtt. Az előbb említett könyv az alacsony, gépi szintű műveletek ismeretére koncetrál, legalábbis abból indul ki, ezért mindenképp gyorsabban tud látványos eredményeket elérni az, aki a már sokkal inkább emberközelibb, a szkript-nyelvek világában létező biztonsági problémákkal kezd foglalkozni. Ezek pedig szorosan kapcsolódnak a webalkalmazások biztonságához. Szinte mindegy, hogy valaki a Hacking Exposed sorozat Web Applications [Scambray, Liu, Sima] egy újabb kiadását használja vagy a Stuttard-Pinto szerzőpáros The Web Application Hacker’s Handbook könyvét, mindkettő alapos áttekintést ad a webalkalmazások tipikus sebezhetőségeivel kapcsolatban.

ITsec Hacktivity webes biztonság alkalmazásbiztonság etikus hekkelés ajánlóHogy kiből lehet hekker vagy inkább nevezzük úgy: rokon területen szakértő? Bármilyen misztikusnak tűnik is, ez is ugyanúgy megtanulható, mint bármi más, csak éppenséggel érdeklődés, idő és tehetség kérdése.

Ha pedig valaki szeretne kívülállóként szeretne betekintést nyerni abba, hogy hogyan gondolkoznak, dolgoznak az etikus hekkerek, kutatók, érdemes ellátogatnia olyan szakmai rendezvényekre, mint amilyen a Hacktivity, ahol idén is két szekcióban párhuzamosan mennek majd az előadások,  szóba kerül majd többek közt a kártékony programok analízisének mikéntje, IP-kamerák hekkelése vagy éppen, hogy hogyan segíthetik az evolúciós algoritmusok a jelszavak kitalálására irányuló támadásokat. Ezen kívül két workshopban, kisebb csoportokban van lehetőség ismerkedni olyan témákkal, mint amilyen az andoridos eszközök sebezhetőségének tesztelése vagy éppenséggel a vezeték nélküli hálózatok hekkelése. Az előadásokra és a workshopokra egyaránt igaz, hogy akkor is lehet tanulni belőlük, ha a vendég nem érti minden részletében azt, amiről szó van.

0 Tovább