Az elmúlt napokban futótűzként terjedt a hír, miszerint kártevők egy új kasztja "intelligens" háztartási eszközöket, TV-ket, hűtőszekrényeket (pontosabban "legalább egy hűtőszekrényt"), médiacentereket is megfertőz és ezek erőforrásait spamelésre használja fel.
Egy otthoni hálózat legtöbbször ugyanis egy NAT-olást végző routeren keresztül lát ki a netre, így minden belső hoszt tevékenysége ugyanarról az IP címről indul ki az Internet irányából tekintve a dolgokat. Emellett ha valaki a router külső címét kezdi szólítgatni, azt találhatja, hogy a különböző portokon keresztül a port forwardingnak köszönhetően különböző belső hosztokra fut be a forgalom.
Emiatt feltehetően az történt, hogy amikor a Proofpoint végigpásztázta a spam forrásként azonosított címeket, megtalált néhány portot, melyek "egzotikus" gépekhez vezettek a spam valódi forrássa azonban más belső végpontok, feltehetően hagyományos munkaállomások lehettek.
A Symantec végponti adatokat is felhasználó adatai szerint a Proofpoint által felfedezett botnet a már jól ismert Khelios kártevő által lett összegrundolva, így bár az okosodó háztartási elektronika elméletileg új célpontokat nyújthat a malware-ek számára, a gyakorlatban úgy tűnik még senki nem vette a fáradságot, hogy a sokféle architektúrán, operációs rendszeren és egyedi szoftververziókkal futó géptömegre hatékony kártevőt készítsen.
Több helyen is megjelent, hogy a viagraárusok újabban Chrome kiegészítőkön keresztül tolják a felhasználók arcába az Internet legjavát. A trükk az, hogy a reklámok olyan, eredetileg teljesen jószándékú kiterjesztéseken keresztül érkeznek, melyek jogait a spammerek megvették az eredeti fejlesztőktől.
A dolog több szempontból is érdekes. Egyrészt ugyanez a játék bármelyik másik, automatikus kiegészítőfrissítést támogató böngészővel eljátszható, szóval ha a Google elkezdi hatékonyan szűrni az ilyen adware-eket, a terjesztők feltehetően áttérnek majd Firefoxra is, ami még több aggodalomra adhat okot, ahogy tanult kollegám, Z fogalmaz:
Firefox-ban semmilyen jogosultságkezelés sincs (pl. ez a kiegészítő engedélyt kér ahhoz hogy ...), illetve semmilyen értelmes sandbox sincs, gyakorlatilag user jogokkal bármit meg lehet tenni. A másik probléma, hogy nincs központilag kikényszerített extension store.
Persze egy megfelelően korlátozott kiterjesztés-API/sandbox sem ér sokat, ha életünk nagy részét amúgy is a böngészőben éljük, és
[A] jelszólopás mindenhol működik, form injection mindenhol működik, bináris malware droppolása és indítása csak Firefox Windows alatt, és végül fájlok olvasása/írása csak Firefox alatt.
A kevésbé jelentős (otthoni) bázissal rendelkező böngészőket tekintve:
Safari OSX alatt:
Sok kártékony funkciót azért nem lehet megtenni, mert új még a Safari-ban az extension fogalma, és nem készítettek API-t hozzá. Ez egyelőre biztonságos, de a későbbiekben nem tudni hogyan változik. Jogosultságkezelés nincs, sandboxing van de nem ismert túl sok részlet, csak aláírt extension telepíthető (ehhez érvényes Apple developer ID kell), de nincs kikényszerítve a központi extension store. Az extension aláírás is megkerülhető, pl. vannak olyan webes alkalmazások ahol az ember megadja a saját Safari extension forráskódját és rendes aláírt Safari extension-t kap a HTTP válaszban :)
Internet Explorer: nehéz az IE kiegészítőket (BHO) összehasonlítani a többi böngészővel, mivel itt onnan indul a telepítés, hogy egy bináris fájlt kell elindítani, ami telepíti a bináris kiegészítőt [ami általában DLL-ként töltődik be az alacsony intergritású processzekbe - a szerk.]. A kockázatos dolgokat, mint jelszólopás, sütilopás, form injection, stb. természetesen egy IE BHO bármikor tud. Mivel először bináris állományt kell futtatni a telepítéshez, így szerintem nincs értelme a "hogyan török ki a böngészőből" típusú kérdéseknek (és egyébként sem vizsgáltam).
Egy remek összefoglaló a különböző böngészők kiegészítőinek lehetőségeiről itt érhető el, szintén Z jóvoltából.
Egy szóval a mostani kampány feltehetően nem a Chrome biztonságának, inkább piaci elterjedtségének indikátora.
Magasabb szinten vizsgálva a kérdést itt lényegében egy TOC-TOU problémáról van szó, csak már gyakorlatilag a felhasználó szintjén (layer 8), ez a veszélyforrás pedig más szoftveres környezetben is jelen lehet, amennyiben:
A felhasználó független fejlesztőtől származó kóddal egészítheti ki az alaprendszert
A telepített "kisalkalmazások" automatikusan frissülnek - itt nem kell feltétlenül a Chrome-éhoz hasonló, teljesen csendes településre gondolnunk, hiszen a felhasználók gyakorlatilag soha nem ellenőrzik a frissítéseket forrás/gépi kód szinten.
A "kisalkalmazások" beszerzése nem megfelelően ellenőrzött forrásból történik - erről kicsit később
Rövid gondolkodás után az alábbi területeken is teljesen analóg támadások képzelhetők el:
Facebook alkalmazások
Alternatív AppStore-ok - az origi AppStore-ban eléggé allergiásak arra, ha egy app új funkcionalitás tud magába tölteni (ld. pl. a C64 emulátor esete), így az Apple hivatalos boltjában jól hasznosítható appot találni elég reménytelen
A lista minden bizonnyal folytatható, a "csinájunk mindenből okostelefont" mánia pedig várhatóan egyre több sérülékeny architektúrát fog kitermelni.
Védekezni leginkább a böngészők körültekintő megválogatásával ("biztosan szükségem van erre?") illetve a telepített kiegészítők (alkalmazások) rendszeres felülvizsgálatával, és a gyengék könyörtelen purgálásával lehet.
A poszt létrejöttének támogatásáért köszönet jár Csabnak és Z-nek.
Nem gondoltam, hogy valaha meg fogok emlékezni a Való Világról ezen blog hasábjain, de úgy tűnik, hogy hosszú idő után ezt a szerveződést érte az a "megtiszteltetés", hogy automatizált botok helyett céltudatosabb támadók deface-eljék a weboldalát.
Ahogy az a comment:com posztjából kiderül, a támadók egy kamu ablakot szerkesztettek, melyben emelt díjas SMS küldésre próbálták rávenni a látogatókat. A felületelem egy külföldi hoszting szolgáltatónál elhelyezett Javascripttel töltődött be, ami szerencsére még mindig elérhető (bár az egyetlen utasítást kikommentezték):
Az online.php tartalmazza magát a megjelenő HTML kódot, az általam sebtiben le-wgetelt változatban nincs malware, ami arra utal, hogy nem profi malware-gazdákkal van dolgunk, mivel feltehetően nem volt kész botnet infrastruktúra, amibe be tudták volna húzni a valóságshow iránt érdeklődőket. A betöltődő oldal az "élőkép" helyére egy sima JPG-t rak, amiből egy gyors strings után megkaphatjuk a kép készítéséhez használt szoftver nevét, illetve a létrehozás idejét:
Az év első javítócsomagja a Microsoft részéről elég lazára sikerült.
MS14-001: Három hibajavítás (úgy tűnik kezd kimerülni a Google aktuális bugbányája) a Word windowsos illetve weben működő változataihoz. A sérülékenységek kódfuttatást tesznek lehetővé memóriakorrupción keresztül, amennyiben a felhasználó egy speciális dokumentumot nyit meg.
MS14-002: Az NDProxy kernel driver sérülékenysége privilégiumemelést tehet lehetővé Windows 2003-on és XP-n
MS14-003:Szintén jogosultságkiterjesztésre alkalmas probléma javítása a jó öreg win32k.sys-ben.
MS14-004: DoS-t előidéző probléma javítása a Dynamics AX-hoz.
Szerencsére a Google-nél nem egy fuzz-farm dolgozik, Gynvael Coldwind és j00ru közös blogposztjából pedig betekintést nyerhetünk, hogy hogyan sikerült nagyjából 2 év alatt több mint ezer (!) potenciális biztonsági hibát kigyomlálni a számos népszerű szoftverben (pl. a Google Chrome-ban és a VLC-ben is) felhasznált könyvtárból.
Érdemes belegondolni, hogy a nyílt forrású, de komplex formátumfeldolgozást végző és igen elterjedt FFmpeg valóban megátólértetődő célpont, és gyakorlatilag teljesen buta fuzzing módszerekkel, "mindössze" 2000 magot bevetve olyan látvány tárul az ember szeme elé, mintha sörétes puskával lőttek volna a forráskódra. Ezek alapján vajon a "kevésbe együttműködő" szervezeteknél hány 0-day lehet még raktáron?
evasi0n
A sok kritikával illetett evad3rs csapatra újabb össztűz zúdul, miután @winocm felfedezte, hogy a csapat jailbreakjével ellátott telefonokon egy app egy egyszerű rendszerhívással tetszőleges helyre ugrathatja a program számlálót kernel módban, ami elég kényelmes utat teremt pl. a sandboxing kijátszására. Az evad3rs a problémát a JB 1.0.4-es változatában javította.
Cisco
A hálózati óriás múlt héten adott ki frissítést több termékéhez, mellyel egy dokumentálatlan teszt interfészt csuktak be. A felület autentikációt nem igényelt, ellenben instant rootot adott a hozzá csatlakozó klienseknek. Külön pikáns, hogy az érintett termékek között a gyártó N-es Access Point-jai mellett ún. "Security Routerek" is szerepelnek. Félelmetes, hogy 2014-ben még ilyen csontvázak esnek ki a szekrényből...
Oracle
Ebben a hónapban az Oracle jelentkezett a legnagyobb csomaggal, a gyártó különböző termékeiben több mint 130 sérülékenységet orvosoltak. A legnagyobb foltot nem meglepő módon a Java kapta, mellyel kapcsolatban szerver alkalmazásokat is érintő, CVSS 10.0-ás sérülékenységeket is találunk, a 7-es főverzióban bevezetett biztonsági figyelmeztetők illetve beépített click-to-play lehetőség kijátszására alkalmat adó probléma viszont úgy tűnik nem került elő, így a kliensek terén nagyjából higgadtak maradhatunk (a frissítést emellett természetesen javasolt megejteni amint lehet).
A holnap esti Cryptonite-on egy különösen érdekes témával, a kvantuminformatika (amivel az NSA is nagy erőkkel próbálkozik) kriptográfiára gyakorolt hatásával foglalkozunk. 19:00-tól kezdünk, felvétel elméletileg lesz.
Jövő hétfőn (január 13. 19:00) kerül megrendezésre a második (az elsőről úgy tűnik lemaradtam...) Budapesti IT-Security meetup a Prezi HQ-ban. Akik hozzám hasonlóan nem tudnak személyesen jelen lenni, Ustreamen követhetik az izgalmasnak ígérkező előadásokat (itt megnézhető az előző eseményről készült felvétel is).
Idén is volt szerencsém ellátogatni a Chaos Computer Club éves kongresszusára, a 30. Chaos Communication Congress-re (30C3). Belegondolva, ez a társaság már akkor az XC3 szervezésével foglalatoskodott, amikor én még meg sem születtem! A CCC mostanra a világ egyik legnagyobb és minden bizonnyal legpatinásabb hacker rendezvényévé nőtte ki magát - néhány éve a "hatalmas" szóval leírható Berlini Kongresszusi Központpól a rendezvényt a még nagyobb hamurgi létesítménybe kellett költöztetni, melynek nagyelőadói leginkább a Galaktikus Szenátus üléstermére emlékeztetnek, az épület folyosóin barangolva pedig négy nap után is komplett új épületszárnyakba botlik az ember, ahol addig ismeretlen geek kolóniák vertek tanyát.
A teljes rendezvényt egy ember egy alkalom alatt minden bizonnyal képtelen átlátni, a változás pedig évről évre olyan mértékű, hogy átfogó beszámolót adni legfeljebb a gonzó újságírás megközelítéseit bevetve lehetne. Én most néhány, számomra emlékezetes előadást illetve pillanatot emelnék ki annak reményében, hogy sikerül átadnom néhányat azok közül az elvek, megközelítések közül, melyek a CCC-t (a rendezvényt és a szervezetet egyaránt) olyanná tették, amilyen, és amiket semmilyen szponzor, hosztessz sereg vagy ajándékcsomag sem tud pótolni.
X
A hacker konferenciák programjában hagyományosan kiemelt helyen szerepelnek a (jelen blog gerincét is adó) biztonsági témájú előadások, így elsőként nézzük meg Ilja van Sprundel prezentációját az X kliens és szerver biztonságáról! Az előadás egyrészt jó példa arra, hogy egyetlen felkészült kutató is képes szignifikánsan hozzájárulni az alapvető szoftver-infrastrukturánk biztonságosabbá tételéhez, ehhez azonban hosszú, kitartó munkára van szükség. Srundel több mint egy évig foglalkozott a témával, és az előadás pillanatában a problémakör csak egy kis szeletén sikerült átrágnia magát, de ez egyáltalán nem vált az előadás kárára. A cél ugyanis nem egy csomó bug, vagy egy mindent vivő exploit bemutatása volt, hanem az, hogy a jelen lévő szakértő közönségnek (akiknek nem kell minden évben újra elmagyarázni, hogy mi az a memória korrupció...) megmutassa azokat a hónapok alatt feltárt ösvényeket, melyeken keresztül az X dzsungele feltérképezhető és "gyarmatosítható" lehet.
failoverfl0w
Az idén Wii U hackelésben utazó failoverfl0w csapat remek példaként szolgál az "egységben az erő" filozófiájára: a játékkonzol tokától bokáig történő széthackeléséhez (legalább) három, specializált szakértelemmel rendelkező kutató összefogására volt szükség, és bár végül nem mindegyikük munkája vezetett egyformán fontos eredménre, egymás motiválása és az egészséges belső verseny nélkül ez a projekt valószínűleg nem valósulhatott volna meg. Ehhez kapcsolódóan az előadást már csak azért is érdemes megnézni, hogy lássuk, az olyan exploit-zsenik, mint @comex is ugyanúgy végigszívnak ezer tévutat és adott esetben téglásítják a saját gépüket a semmiért, mint más földi halandó - szóval nem kell megrettenni a kudarctól, hanem ezredszerre is újra kell kezdeni az agyalást, az ezerháromszázharminchetedik sikeres kísérlet után annál édesebb lesz a győzelem!
Házi űrközpont
Travis Goodspeed igazi mintahacker, akinek nem mindennapi kognitív kapacitása mellé elképesztő kreativitás, szorgalom és nem utolsó sorban rendkívül szórakoztató, laza stílus párosul. Munkái általában nem valamilyen világmegváltó témát érintenek (bár például a legutóbbi Snowden leakből kiderül, hogy a firmware rootkiteket az NSA már jó ideje használja), inkább valami hardverközeli bütykölésre (kénsavval meg elektronmikroszkóppal...) kell számítani, aminek a végén minden alkalommal végigfut az ember fejében a gondolat, hogy "Banyek, ez a srác megcsinálta!".
Jelen esetben arról van szó, hogy Travis megvett egy leselejtezett radar dómot egy hadihajóról, amit felállított a kertben, aztán köréépített vezérlést és informatikát, hogy tesztőleges (látható) műhold kommunikációját meg tudja figyelni (majd dekódolni). Ez egy olyan projekt, aminek megvalósításához egyrészt kicsit ki kell szakadni az otthonos 0-1 univerzumból, másrészt sok apró, egymástól alapvetően különböző feladatot kell úgy megoldani, hogy végül a komponensek harmónikusan együttműködjenek. Az sikerhez vezető út itt sem rövid vagy könnyű, de az biztos, hogy menőbb téma a bárpultnál a kerted végében működő radarállomás (a csajozós/pasizós szövegek legyártását mindenkire rábízom), mint hogy hogyan reszelted össze random cég Java-Lotus-Outlook-Debian-... kompozícióját.
A PoC||GTFO legújabb 30c3-s különkiadása innen letölthető (Travis a helyszínen jelentkezőknek a nyomtatott példányok mellé zsírkrétákat osztott a színezős feladatok megoldásához :)
Együttműködés
A CCC-k meghatározó elemei az önszerveződő workshopok, beszélgetések, projektek és más mikroprogramok, melyeket a látogatók szerveznek látogatóknak. A repertoárban a hagyományos (bit)hegesztős témákon túl hangsúlyosan szerepelnek a politikai, kulturális és szórakoztató programok. Bár a magam részéről általában ellene vagyok annak, hogy "széknek használok egy asztalt" meg a "kettőt lapoztam a szakácskönyvben" típusú próbálkozásokat egy kalap alá vegyük a hackelés eredeti területeivel, de az biztos, hogy jól esik egy-egy több órás debug-maraton után elbeszélgetni a helyi mesterekkel, hogy pl. hogyan érdemes Lappföldön szeszt főzni.
Ezeknek az összejöveteleknek a legnagyobb előnye azonban nem elsősorban ez, hanem az emberek összehozása. A hivatalos honlapon elérhető (de szintén közösségileg szerkesztett) étlapon mindenki megtalálhatja a számára releváns témákat, és ezen keresztül a hasonló érdeklődésű embereket is, ami egy ilyen széles közösséget mozgató rendezvény esetében különösen fontos.
Én a SCADA Strangelove csoport által szervezett ipari vezérlőrendszerekkel foglalkozó workshopra jutottam el, ahol a tesztkörnyezetként működő kisvasutat ugyan nem sikerült kisiklatni, de végre nekiállhattam játszani egy igazi ipari PLC-vel (sikerült is lefagyasztani :), és válthattam pár szót néhány ICS pentesztelésben jártas szakival.
Mivel gyakran az így létrejött ismeretségek segítenek hozzá egy-egy téma kidolgozásához (általában szakmai segítségen, inspiráción keresztül), elmondhatjuk, hogy a közösségi élet megfelelő támogatása (amihez elég egy wikioldal, valamint megfelelő számú asztal és szék biztosítása) az, ami egy konferenciát passzív fogyasztóból a szakmai vérkeringésben aktív szerepet játszó, számottevő tényezővé emelhet.
Az idei terveim között szerepel (legalább) egy ilyen program összehozása. Eddig a "Drunken Debugging" cím körül forognak a gondolataim, de szívesen fogadok javaslatokat! :)
Kikapcsolódás
Végül, de nem utolsó sorban had ejtsek néhány szót a kikapcsolódásról. A CCC (mint a vérbeli hacker konferenciák általában) nem zár be a nap végén, hanem (hasonlóan egy nyári fesztiválhoz) folyamatos programot nyújt a résztvevők számára. A mindig nyüzsgő HackCenter mellett folyamatosan működő konyha és bárpult, teázó és egy hatalmas party hangár ("lounge") várja a megfáradt hackereket. Utóbbi helyszínen korrekt fénytechnika, a demoscene jelenlétét sugalló vetítések, egy kiszuperált vízágyú, profi hangcucc és persze profi DJ-k biztosítják a felhőtlen szórakozást olyan minőségben, hogy az ember a végkimerülés határán is fájó szívvel indul el a szállására néhány óra kényszerű alvásért.
Ezek a gondos szervezésről és végtelen odafigyelésről tanúskodó elemek bizonyítják, hogy a CCC-t ma is ugyanolyan elkötelezett csapat szervezi, mint 30 éve, akiknek a célja évről évre a kategória legjobb rendezvényének összehozása, melyet nem írhat felül semmilyen üzleti, anyagi vagy akár személyes szempont.
Remélem idén év végén a mostaninál is nagyobb, legalább ilyen lelkes csapattal sikerül majd újra tiszteletünket tenni német barátainknál, addig viszont dolgozzunk közösen azon, hogy néhány évtized múlva mi is úgy emlékezhessünk vissza erre az időszakra, mint amikor valami jó és maradandó dolog elkezdődött!
BÚÉK minden kedves látogatónak Még igyekszem kiheverni az év végi pálinka (kösz Balu!)-pezsgő-töltöttkáposzta sokkot, úgyhogy csak egy gyors poszt az OpenSSL incidensről:
Aki lemaradt volna Twitteren, az openssl.org-t december 29-én deface-elték. Január 1-én az üzemeltetők egy rövid üzenetetet tettek közzé, melyben leírják, hogy az incidensre a hoszting szolgáltató hypervisorán keresztül került sor, melyre válaszul a VMware is kiadott egy közleményt, melyben tagadják, hogy az ő terméküket érintő problémát használtak volna ki a támadók. A hírek szerint az openssl.org-t az IndIT hosztolja, akik VMware mellett KVM virtualizációs technológiát is használnak, de egyes spekulációk szerint az is elképzelhető, hogy a "hypervisort" ezen a rétegen tűlmenően kell értelmezni ebben az esetben (jelentsen ez bármit...).
Az OpenSSL könyvtár tárolóját az incidens nem érintette, a honlapot visszaállították.
Friss(201401031827): Az OpenSSL csapat újabb közleményt adott ki, melyben a támadást egy, a hoszting szolgáltató menedzsment felületén használt gyenge jelszóra vezették vissza, hypervisor exploitot tehát nem kell (olyan hevesen) keresni.
Az evad3rs csapata kiadta a rég óta várt iOS 7 jailbreaket. Apró szépséghiba, hogy a kiadás előtt álló iOS 7.1-en már döglöttek a kihasznált hibák, emellett pedig az sem aratott osztatlan sikert a jailbreak közösségen belül, hogy kínai felhasználóknak a JB egy kínai appstore-t telepít a szokásos Cyda helyett - ezért a lépésért többekszerint 6 számjegyű (dollárban értve természetesen) összegeket ígértek korábban különböző szolgáltatók, miközben az evad3rs nagy erőkkel gyűjtötte az adományokat a jailbreak kifejlesztéséért.
Friss (201312222322): @Jadeye_hu hívta fel a figyelmem, hogy félteértettem a 7.1-el kapcsolatos híreket. A JB működik a 7.1b2-n, ezt többen megerősítették, de emellett elég jó esély van arra, hogy (az exploitok birtokában) a végleges kiadásban betömik a lyukakat, magyarul úgy néz ki, nem lett túl jól időzítve ez a kiadás.
Friss (201312222334): A fentiekhez hozzátartozik, hogy a jelek szerint PS3 jailbreakelésével ismertté vált GeoHot versenyben volt az evad3rs-el a JB kiadásában. Itt hallgatható egy beszélgetés, ami állítólag GeoHot és egy jailbreakre pályázó vevő között zajlott. Egyes értesülések szerint azért került most sor a jailbreak kiadására (a logikusabb 7.1 release dátumot követő kihozatal helyett), mert az evad3rs nem akarta hogy GeoHot megelőzze őket, illetve olyan exploitokat szivárogtasson ki, melyek a későbbi iOS változatok megtörésére tartogatott a csapat.
Friss (201312231754): A kínai store-t hosztoló TaiG sajtótájékoztatót tartott az első "kínai jailbreakről", ami némileg ellentmond az evad3rs azon állításának, hogy az exploitokat másnak nem adták át. Közben a kínaiak egyik domainjét deface-elték a csalódott jailbreakerek.
A Reuters Snowden dokumentumokra hivatkozva arról számolt be, hogy az NSA 10 millió dollárt fizetett a jelenleg az EMC részeként működő RSA Security társaságnak, hogy azok Bsafe nevű kriptográfiai könyvtárában a minden bizonnyal hátsó kaput tartalmazóDual_EC_DRBG véletlengenerátort tegye alapértelmezetté.
Az RSA - bár a Dual_EC_DRBG-vel kapcsolatos információk kiszivárgása után szeptemberben maguk javasolták ügyfeleiknek a Bsafe használatának hanyagolását - természetesen tagadja, hogy szándékosan gyengítették volna bármely terméküket, a hivatalos sztori szerint azért ezt az algoritmust választották (nyeljétek le a forraltborotokat, és kapaszkodjatok meg!), mert az EC alapú kriptó abban az időben trendinek tűnt.
Annyira trendinek, hogy a döntés meghozatalakor a NIST még nem is szabványosította az eljárást, hovatovább a Reutersnek nyilatkozó források szerint az NSA egyik ütőkártyája a szabványosítási folyamatban éppen az volt, hogy az eljárást már jelentős piaci szereplők alkalmazzák.
Itt egyrészt tényleg meg kell emelnem a kalapom az illetékes NSA lobbisták előtt, másrészt azt is be kell látnom, hogy a kriptoparanoidoknak végig igazuk volt, és ideje megismerkednünk a lehetséges következményekkel:
Látnunk kell, hogy egy nem megfelelően működő véletlengenerátor tetszőleges biztonságos algoritmust vagy protokollt képes gallyra vágni: leegyszerűsítve a dolog úgy néz ki, hogy az NSA minden, egyébként feltörhetetlen lakathoz ki tudja számolni a megfelelő kulcsot. A súlyos helyzetet az teszi közel katasztrofálissá, hogy ezt a generátort az ügynökségnek nem egy-két kész termékbe, hanem egy fejlesztői könyvtárba sikerült beügyeskedniük, így minden olyan termék problémás lehet, amiben a Bsafe-t felhasználták.
Egy olyan, bizalomra épülő iparágban, mint a biztonság, a bizalom a legnagyobb érték, az EMC/RSA-nak ezt sikerült elkótyavetyélnie. Az Államokban idő közben az NSA működésének vizsgálatára alapított bizottság javaslatot tett a kriptográfiai eszközök gyengítését célzó törekvések megszüntetésére és megtiltására.
A nap agyolvasztó kutatása: a GnuPG által használt RSA kulcsok megszerezhetők, ha a támadó meghallgatja (szó szerint: mikrofonnal) egy meghatározott kriptoszövegeket éppen fejtő gép hangját.
A számítógépek feszültségszabályzójának elektronikus alkatrészei rezegnek, ami nem vagy csak alig hallható magas frekvenciás zajt eredményez a gép környezetében. A Tel Avivi Egyetem és a Weizmann intézet kutatói réjöttek, hogy bár ezek a rezgések sokkal alacsonyabb frekvenciájúak, mint a számítógép órajele, bizonyos hosszú processzorutasítás-szekvenciák a többitől megkülönböztethető zajt eredményeznek. Ezek megfigyelésével beazonosíthatók pl. az RSA algoritmusban használt moduláris hatványozás művelet részei, melynek segítségével kötvekeztetni lehet a használt kulcsbitekre.
Hasonlóan, a gépház elektromos potenciáljának, vagy a gép áramfelvételének mérésével is hasonló információ szerezhető.
A kutatóknak sikerült kivitelezniük a támadást egy 4096 bites kulccsal szemben egy, a gép közvetlen környezetébe helyezett mobiltelefonnal, illetve legfeljebb 4 méterről irányított mikrofonnal is. Az egyelőre nem világos, hogy a választott kriptoszövegek megfejtésére az áldozat pontosan hogyan vehető rá, de a TLS protokollban talán lehet fantázia.
A probléma demonstrálására használt GnuPG-t most frissítették, de a támadási mód még sok feltáratlan területet sejtet. A kutatás egyúttal remekül demonstrálja, hogy a kriptográfia implementálása mekkora szívás is valójában.
Stefan Frei az NSS Labs kutatója igen érdekes fejtegetésekbe kezdett az utóbbi időben. A KrebsOnSecurity-n találtam (idő közben a Biztonságportál is nagy vonalakban beszámolt a kutatásról) meg az első tanulmányát, melyben egyebek mellett konzervatív becslés kapunk arra, hogy nagyjából mekkora is ma a világ 0-day termelő képessége - kizárólag a nyilvános adatokra támaaszkodva azt kapjuk, hogy naponta(!) több mint 80, addig ismeretlen sérülékenységet fedeznek fel, és figyelembe véve a javítási ablakokat, gyakorlatilag esélyünk sincs, hogy az ezeket felhasználó támadásokat hosszú távon kivédjük.
A helyzetértékelés mellett azonban fontos lenne a megoldási lehetőségek keresése is, erre pedig Frei második esszéjében vállalkozik. A kiinduló tézis az, hogy bár a sérülékenységekből származó károk évente a legszerényebb becslések szeirnt is több milliárd dollárra rúgnak
a) a szoftverhibáktól nem tudunk megszabadulni,
b) a hibák harmadik fél általi felfedezése nem kiküszöbölhető
c) a sérülékenységek piaca szárnyal,
d) az eddigi megoldási kísérletek pedig nem működnek.
Ismét egy remek példa, hogy érdemes oda figyelni a CrySys-re, elég frankó dolgok alakulnak a környéken:
A BME CrySyS !SpamAndHex nevezetű csapatának eredménye a második helyezés lett az idei iCTF versenyen résztvevő 122 csapat közül. Nagyon fontos megjegyezni, hogy ilyen jellegű hacker versenyből számos van, de az iCTF az egyik legnagyobb ilyen verseny, és ez a legfontosabb és legjobban megszervezett azok közül, amelyben egyetemi csapatok a résztvevők.
A verseny bonyolult volt és komplex. A tematika a napisajtóból lett átvéve, a képzelt folyamat az uránbányászat, urándúsítás, nukleáris bomba készítést követte, természetesen csak elméletben, ugyanakkor a feladatok pontosan olyan számítástechnikai támadásokra épültek, amelyet a számítógépes bűnözők, vagy akár államok követkek el nap, mint nap. 10 szolgáltatást hoztak létre a szervezők, ezek mindegyike esetében az volt a feladat, hogy a csapatok felismerjék a szolgáltatás gyengeségeit, és ez alapján védelmi módszert (javítást), detekciós módszert (felismerni a támadó jellegű adatáramlást) és támadó eszközt fejlesszenek, utóbbival a többi csapat szolgáltatásait lehetett megtámadni.
Gratulálunk a !SpamAndHex-nek a kiváló eredményért, remélem a megoldott feladatokból is kapunk majd jóféle bitszagú beszámolókat!
Rambo osztotta Twitteren a hírt, miszerint jogerősen börtönre ítéltek néhány arcot, akik egy partner vállalkozástól több mint 80 milliót loptak egy kémprogram segítségével. A sztori lényegi része az SG.hu-ról:
Az elsőrendű vádlott letöltött az internetről egy távoli hozzáférést biztosító kémprogramot, amelyet a másodrendű vádlott föltelepített a kft. gazdasági igazgatójának számítógépére. Az elsőrendű vádlott 2010. április 16-án, egy pénteki napon átvette az irányítást a gazdasági igazgató számítógépe fölött, majd kilenc részletben összesen 82,5 millió forintot átutalt egy számlára, amelyet egy ismerőse nyitott.
Hasonló esetek elkerülése érdekében (avagy az alapokat nem lehet elégszer ismételni):
Telepítesz antivírust - a mezei, netről letöltött kémprogramokat ezek nagyrészt megfogják
A vírusírtó kikapcsolását jelszóhoz kötöd vagy egyéb módon korlátozod (pl. csak adminisztrátor tudja kikapcsolni)
Nem adminisztrátorként használod a gépet
Mindez persze egy egyel fifikásabb támadót már nem állít meg (egy kolléga pár órája ért vissza egy sikeres social engineering küldetésből...), de WC-s bácsik ellen még hatékony lehet.
Az ehavi frissítőcsomag viszonylag izgalmasra sikerült, kezdjük mindjárt azzal, hogy a Google-nél észlelték, hogy a francia ANSSI hitelesítő szolgáltató alá tartozó egyik CA a keresőóriás domainjére szóló tanúsítványt állított ki. Ahogy az érintett CA közleményéből kitűnik, a tanúsítványt a francia pénzügyminisztérium számára generálták, ott pedig hálózatmonitorozó eszközökben használták. A cég közleménye szerint erre "emberi hiba" miatt kerülhetett sor, bár én inkább a "kormányzati ügyfél szava szent" filozófiát vélem felfedezni a lépés mögött. Az érintett köztes branch tanúsítványát visszavonták, a böngészőgyártók pedig úgy tűnik nem tesznek újabb lépéseket az ügyben.
Microsoft
MS13-096: Ebben a bulletinben kerül javításra a kb. egy hónapja napvilágra került 0-day sérülékenység, ami a TIFF feldolgozó hibáján keresztül ad kapásból SYSTEM hozzáférést a támadónak. Tessék azonnal telepíteni!
MS13-097: Nagyon úgy tűnik, hogy az ehavi Internet Explorer csomagban javítják James Forshaw BlueHat Prize-t érő sandbox kitörését, ami nem csak azért remek hír, mert sikerült néhány általánosan használható kiskaput bezárni, hanem mert ezek után remélhetőleg a nyilvánosság is képbe kerülhet a 100.000 dollárt érő módszerrel.
MS13-098: Egy támadó képes a digitális aláírás elrontása nélkül megváltoztatni egy PE fájl viselkedését - a szintén csodaszépnek látszó hiba természetesen a Windows össze támogatott verzióját érinti.
MS13-099: Egy use-after-free sérülékenység javítása a MS Scripting Runtime Object Library-ban. A probléma speciális tartalmakat kiszolgáló weboldalakon keresztül távoli kódfuttatást tehet lehetővé a böngésző felhasználó jogkörével.
MS13-101: Egy sor helyi jogosultságkiterjesztésre alkalmas probléma javítása a Windows kernelben. Érdekesség, hogy egy általában távoli kódfuttatásra is alkalmas TrueType feldoglozás problémát is sikerült orvosolni - úgy tűnik, hogy ebben az esetben a hiba kihasználása trükkösebb volt az átlagnál. A csomag a jelek szerint nem tartalmazza a célzott támadások során kihasznált NDProxy.sys sérülékenység javítását.
MS13-102: Kommentben valaki elmagyarázhatná, hogy az LRPC (Local Remote Procedure Call) mi a csoda tulajdonképpen, nekem a FAQ alapján nem sikerült rájönnöm... Minden esetre egy LRPC szerver puffer túlcsordulást triggerelhet a kliensén, jogosultságkiterjesztést eredményezve.
MS13-103: Cross-Site Scripting probléma javítása az ASP.NET SignalR-hez
MS13-104: Egy támadó kipakolhat egy spéci Office dokumentumot egy kiszolgálóra, amit ha valaki megtekint, a támadó megszerezheti a SharePoint-hoz illetve más Office szolgáltatásokhoz hozzáférést biztosító azonosító tokent, ezzel megszemélyesítve a felahasználót a szolgátlatások felé. A Microsoft szerint a problémát célzott támadások során aktívan kihasználják.
MS13-105: Átvezettek az Exchange-be két hibajavítást az Oracle Outside-inből, melyek DoS-t illetve távoli kódfuttatást eredményezhetnek, ha az áldozat OWA-n keresztül megtekint egy speciális fájl csatolmányt - mázli, hogy a támadó alapértelmezetten csak LocalService jogokat kap. Ezen kívül, mint kiderült, az OWA-ban nem volt engedélyezve a ViewState MAC, ami távoli kódfuttatásra adhat lehetőséget a szolgáltatás kiszolgálóján. Végül pedig javításra került egy árva XSS is.
Az Adobe két hibát javított a Flash Playerben, ezek közül az egyiket aktívan ki is használják. Abban a szerencsés helyzetben vagyunk, hogy a hibát bejelentő Suszter Attila részletes elemzést posztolt a sérülékenységről: Ebből kiderül, hogy a most javított probléma kísértetiesen hasonlít egy Attila által korábban felfedezett hibára, melynek lényege abban állt, hogy a Flash tartalmat beágyazó alkalmazás egy másik szálon kitehette a lejátszó szűrét a memóriájából, míg a lejátszó threadje egy üzenetablakot jelenített meg gyönyörű use-after-free szituációt produkálva az üzenetablak bezárulása után. A poén az, hogy ilyen módszerrel nagyjából mindig átvehető a program futása feletti kontroll, mikor a lejátszó üzenetablakot jelenít meg (vagy más hasonló API műveletet használ), így vagy az Adobe részéről lenne szükség egy igen alapos code review-ra, vagy (és talán ez a fájdalommentesebb megoldás) a Microsoftnak (meg az Apple-nek?) kéne implementálnia valamilyen univerzális megerősítő megoldást a hasonló bakikból eredő károk minimalizálására.
Emellett a Shockwave lejátszó is kapott egy jelenleg kevésbé fenyegető, de hasonlóan fontos hibajavítást, szóval azt a lejátszót is frissítsétek.
D-Link
A mainstream médiában is lehetett olvasni arról a D-Link hátsó ajtóról, amit a cég múlt hónap végén nagy kegyesen eltávolított a hivatalos firmware legfrissebb kiadásából. Aki lemaradt volna: megfelelő User-Agent beállításával jelszó nélkül hozzá lehetett férni az érintett eszközök menedzsment felületéhez - valamiért erről a sztoriról mindig az Internet Census 2012 ugrik be...
Drupal
Zorg, a Rettenetes hívta fel a figyelmem, hogy - feltehetően az elmúlt idők témába vágó kutatásainak hatására - a Drupalban lecserélték az mt_rand() alapú véletlengenerátorokat, melyekkel többek között a CSRF tokeneket illetve más biztonságilag kritikus funkciókat is etettek. Az új változat ezen kívül több más, kisebb nagyobb sérülékenység javítást is tartalmaz, a frissítés tehát erősen indokoltnak látszik.
VMware
A VMware javította a Player és Workstation termékek újabb főverzióiban a vmware-mount privilégiumemelésre alkalmas problémáját, melyet már többen felfedeztek. Tavis Ormandy leírását itt olvashatjátok, de úgy rémlik, hogy voltak más bugok is, de ezeket perpill nem találom :(
A fentieken tól van új Apache 2.4 meg PHP, a vonatkozó kiadási megjegyzésekben biztonsági infót nem találtam, a Tor Browser Bundle pedig új Firefox-t kapott.
Egy olyan szervezetnek, ami vadászrepülőket meg önvezető autókat tervez kritikus fontosságú a vasakat működtető szoftverek megbízhatósága, melyre legjobb garanciát a formális, matematikai bizonyítás adhat. A baj az, hogy a programokt hagyományosan modellező gráfok elméletében még van néhány nehéz probléma, így egy program egyes tulajdonságainak belátása a gyakorlatban sokszor csak nagyon-nagyon drágán (vagy egyáltalán nem) kivitelezhető.
A DARPA egyik friss projektje erre a problémára próbál részleges megoldást adni a felmerülő nehéz kérdések közösségi megoldása segítségével: A Verigames egy sor Flash játékot kínál, melyek hátterében valós szoftverproblémák állnak, az egymással versengő játékosok pedig a pontgyűjtés során ezek megoldásában segítenek saját idejük és persze szürkeállományuk befektetésével.
Tíz perc próbálgatás után azt mondom, hogy a játékok alapvetően nem sikerültek rosszul, bár az biztos, hogy nem adnak olyan instant sikerélményt, mint egy Angry Birds (bár nekem az se ment :P), az viszont biztos, hogy jó ráhangolódást nyújtanak a készülőben lévő reversing-témájú poszt-sorozathoz ;)
Jó szórakozást!
U.i.: Vajon kellő mennyiségű rosszindulatú játékos be tud betonozni egy-egy bugot mondjuk a készülő X-37-esbe?
Ó, és itt ragadnám meg az alkalmat, hogy bevágjam ezt a videót Grace Hopperrel, aki ma lenne 107 éves:
Az előző packetfu postokban a layer3 és 4 magasságában mozgolódtunk, most elmaszatolunk a 2-esen is egy kicsit. Ez a post elsősorban az ethernet, és routing lehetőségeit kapirgáltuk. Az eddig leírt módszerek magasabb layereken dolgoznak, de lehet az L2-n is sumákolni. A post első felében a layer2: a switch, és Ethernet témát piszkáljuk. Nincs benne semmi fu, de a kung-fu-nak sem a verekedés a lényege. (Ezt a Kung-fu pandában hallottam. Jó film.) Szóval kellenek az alapok is. Tudom hogy sok mindenkinek ezek nem mondanak újat, de olyanok is olvassák akiknek ezekből nem volt meg minden, a hackelés alapja pedig a megismerés. Lesz azért némi fu is.
A 444-en jelent meg a hír, miszerint a gonosz Prezi nem volt hajlandó fizetni egy ügyes Google hackernek, aki kritikus hibát talált a magyar startup üdvöske rendszerében.
Mint a felelős hibabejelentést (tudom, nem ez a legjobb kifejezést) évek óta gyakorló, és a nemzetközi hibavadász programokban résztvevő szakember, néhány dolgot fontosnak tartok leszögezni:
Shubham Shah a Prezi által megszabott területen kívül, vagyis a Prezi engedélye nélkül dolgozott
Ilyen esetben a Prezi simán ráküldhette volna a hatóságokat a srácra - mivel ausztrál illetőről van szó, ennek feltehetően lett is volna eredménye
A Prezi nem így cselekedett, helyette megköszönte a munkát, és némi jelképes ajándékot is felajánlott
Ez a gesztus - bár pitiánernek tűnhet - még mindig megelőzi pl. az Oracle-t, a Microsoftot vagy az Apple-t, akik nagyjából egy köszönőlevéllel intézik ezeket a dolgokat, esetleg kirakják a neved valahová
A hibavadász programok üzemeltetése ugyanis nem valamiféle kötelesség, hanem egy lehetőség, melyet néhány előremutatóan gondolkodó tech cég (a saját üzleti stratégiáját figyelembe véve) választ, a kifizetett jutalmakról pedig emiatt saját hatáskörében dönthet
A mostani eset emiatt egy dologra jó, mégpedig arra, hogy a hasonló programok indításában gondolkozó cégeket elbátortalanítsa, hiszen egy szerencsétlen visszajelzés (amiből a Prezinek sem kettőt kell kiküldeni naponta) a rinyáló versenyzők és a szenzációra vadászó sajtó összejátszásával könnyen PR katasztrófát okozhat.
A Prezi reakciója itt olvasható, a bounty területe az eset hatására kiterjesztésre került.
Friss: Közben az Index is lehozott egy szokásosan fogalmatlan cikket, én a Prezi helyében kiadnék egy sajtóközleményt, amit újságírók is megértenek...
A hatalmas bizonytalansági tényezők miatt a blog hasábjain eddig nem szenteltem figyelmet a #badBIOS témának, de az elmúlt napok néhány eseménye azt hiszem, megadják keretet a téma felvezetéséhez.
A lényeg tömören annyi, hogy Dragos Ruiu, a mostanában leginkább a CanSecWest konferencia és az ehhez kapcoslódó Pwn2Own játék megalkotása révén ismert őshacker hetek óta posztolgat egy rejtélyes kártevőről, amit képtelen leírtani az egyébként airgappel védett rendszereiről. Az állítólagos malware egyik jellemzője, hogy keresztplatformos - feltehetően USB kulcsokon keresztül képes megfertőzni Windows, Linux, OS X és egyes BSD rendszereket is, melyekbe később olyan mélyen belerágja magát, hogy az eltávolítási kísérlet esetenként a gép "téglásodását" eredményezi, de az a minimum, hogy a BIOS nem hajlandó többé CD-t bootolni (innen a név). A különböző terjedési és újrafertőzési módszerekről több elmélet is született a speciális IPv6 tunnelektől kezdve a nagyfrekvenciás audió-jelekig, utóbbi módszert most a Fraunhofer Institut kutatóinak sikerült is demonstrálni (bár azt nem tudni, hogy a kutatásnak volt-e köze a #badBIOS talányához):
A kísérlet során egy átlagos laptop hangszórón keresztül az emberi fül számára érzékelhetetlen frekvenciájú hanghullámokat sugároztak, melyeket egy másik laptop mikrofonja rögzített és dekódolt. Ilyen módon sikerült nagyjából 20 bps átviteli sebességet elérni, ami harmatos, de nagy biztonsági követelményű környezetben végzetes lehet, ilyen módon ugyanis az elzárt rendszerek - hálózatra kötött társaikon keresztül - távolról vezérelhetővé válhatnak, és bizonyos rövid, de kritikus fontosságú információk (pl. jelszavak) ki is juttathatók róluk. (lica újabb anticikke a témában az Indexen olvasható...)
Hogy hasonló eset zajlott-e Dragos holmijai között, azt egyelőre nem tudjuk, tegnap viszont fel került a netre egy dump, ami a hacker egyik szerverének legyalázását dokumentálja, egyúttal hangsúlyozva, hogy nem kell ide csodafegyver. Az anyag eredetiségét lényegében Dragos is elismerte, hozzátéve, hogy egy 2011 óta lekapcsolt webkiszolgálóról van szó.
Függetlenül attól, hogy a #badBIOS egy valódi szuperkártevő vagy csak paranoia rúgott ki a hámból be egy sokat tapasztalt szakértő fejében, a történet végkifejlete mindenképpen nagy hullámokat fog verni az IT-biztonság tengerében, addig viszont mindenki tartsa meg az egészséges szkepszisét!
Csabika25 hívta fel rá a figyelmem, hogy "támadás érte" a Szellemi Tulajdon Nemzeti Hivatalát (.gov.hu), amivel kapcsoaltban megjelent néhányközlemény, meg elindult a konteógyártás (regisztráció után megtekinthető tartalom, no comment...), de megmondom őszintén, így egy kiadós IDA maraton után körülbelül egy perc után füstölt el az agyam a jogászkodós bullshittől, a lényeg kb. ez:
"Amint arról a sajtó is beszámolt, a Szellemi Tulajdon Nemzeti Hivatalának (SZTNH) informatikai rendszerét a közelmúltban támadás érte, amelynek következtében közzététel előtt álló szabadalmi dokumentumok kerülhettek a támadó birtokába. Az SZTNH erre figyelemmel fokozta az információbiztonság érdekében tett intézkedéseit, megtette a szükséges intézkedéseket a további visszaélések megakadályozása és az elkövetők felderítése érdekében, a potenciálisan érintett szabadalmi bejelentéseket pedig azonosította. Az ilyen bejelentések benyújtóit az SZTNH levélben keresi meg annak érdekében, hogy az esetből következő kockázatok kezelhetők legyenek, és a bejelentőket ne érhesse hátrány. Azok az ügyfelek, akik nem kapnak ilyen értesítést, biztosak lehetnek abban, hogy szabadalmi bejelentésük nem esik a támadás által érintett körbe."
Lefordítva ez nagyjából annyit jelent, hogy ha valaki ismerte egy szabadalom hivatkozási számát, akkor a megfelelő URL paramétert megváltoztatva nem publikus szabadalmi kérelmekhez is hozzáférhetett egy nyilvános felületen. Hogy ez a szellemi tulajdon védelme szempontból mennyire gáz, arról a fenti két linken megy a vita, én a probléma ezen vetületéhez kevésbé tudok hozzászólni, de a büntetőjogi megítélése az esetnek a nemzetközi példák alapján érdekes lehet (már ha megfognak valakit az ügyben):
Elég nagy felzúdulást keltett a tengeren túlon, hogy weev-et végül lecsukták az AT&T felhasználók jelszavainak kiszivárogtatásáért, ami technikai értelemben analóg eset volt: ott sem kellett mást tenni, mint egy azonosító értékét megváltoztatni a böngésző címsorában. A dolog pikantériája többek között az, hogy eszerint a logika szerint szerint nem szerkeszthetem át tetszés szerint egy (by design) szerkeszthető mező tartalmát a saját számítógépemen, ami azért elég abszurdnak hangzik - kíváncsi vagyok, hogy egy hazai bíróságon egy hasonló érvelés megállná-e a helyét?
Minden esetre remélem, legalább jól megfizették adópénzből azt a tehetséges programozót, aki mindezt így összelapátolta!
A hét eddigi legjobb hackjét eddig Michael Ossmann és Kyle Osborn prezentálta: Bár előadásukat a BlackHaten már előadták, úgy tűnik, hogy a Toorcon bizonyult a jobb táptalajnak ennek a vérbeli hacker prezentációnak, amiben van forrasztóón, pia, nem dokumentált funkcionalitás, kódfaragás, demóeffekt és persze sok vidámság.
Az nagyjából köztudott, hogy amennyiben a távoli hibakeresés engedélyezve van Androidon, egy sima USB kábellel a készülékre csattanva átvehetjük az uralmat a készülék felett, szerencsére azonban ez a funkció letiltható.
Az előadás alapötlete onnan ered, hogy a derék mérnökök szeretnek mindenféle nem tervezett funkciót megvalósítani a különböző kábeleken és csatlakozókon, ha már úgyis ott vannak. Remek példa erre a DSL technológia, de számomra például az újdonság erejével hatott, hogy szabvány szerűen közlekedhet analóg audió jel az USB interfészen és fordítva.
Mint kiderült, a legtöbb okostelefonba épített USB port nem csak az USB vezérlővel beszélgethet. A megfelelő datasheetek átnyálazása után megtudhatjuk, hogy a megfelelő pineket egy megfelelő ellenállással összekötve egy UART-ot beszélő debug porthoz kapunk hozzáférést.
Ez néhány esetben instant rootot jelent, de túlnyomórészt egy erősen korlátozott felhasználói hozzáférést kapunk, ez a hozzáférés azonban elég arra, hogy újra engedélyezzük a debuggert, innentől pedig vége a játéknak.
Összefoglalva: rádugsz egy primitív kábelt egy akár lezárt telefon USB portjára, és tiéd a készülék - persze a megoldáshoz vezető út soha sem egyenes, mindenképpen ajánlom a videó megnézését, de előtte adjunk hálát a titkosszol^W gyártóknak, hogy ilyen remek játékokkal árasztanak el minket! :)
A Pwn2Own versenysorozat mobil kiadását idén a tokiói PacSec konferencián rendezték meg, ami végre az ázsiai csapatok számára is testközelbe hozta a megmérettetést, ami természetesen nem is maradt eredmények nélkül:
A japán Team MBSD a Samsung Galaxy S4 telefonra alapértelmezetten telepített alkalmazások sérülékenységeinek láncolatán keresztül sikeresen telepített egy új alkalmazást a készülékre, miután annak "gyanútlan" tulajdonosa rábökött egy linkre - a kritikus probléma tehát nem az Andorid operációs rendszert, hanem a Samsung hozzáadott komponenseit érintette.
A kínai Keen Team két Safari hiányosságot is demózott iOS-en, az egyik probléma kihasználásával a felhasználó Facebook jelszaváttudták ellopni, a másikkal pedig a telefonon tárolt fotókat voltak képesek megszerezni. Érdekesség, hogy egyik problméma sem valamilyen megszokott memóriakorrupciós sérülékenységre vezethető vissza, hanem a böngésző magasabb szintű biztonsági korlátozásainak nem megfelelő megvalósításából adódik. Mivel a csapat a iOS sandbox-át nem törte át, a teljes 40.000 dolláros jutalom helyett 27.500 dodóval kellett megelégedniük, ami persze még mindig szép summa.
Friss2: Pinkie Pie egy két sérülékenységet kihasználó, sandbox escape-es Chrome exploittal behúzta a Galaxy-ért és a Nexus 4-ért járó 50.000-es díjat.
Az Apple közben kiadta az iOS 7.0.4-et, ami a fenti problémákat nem, de az AppStore-ból megfelelő autorizáció nélküli vásárlást már orvosolja több kevésbé fontos biztonsági és egyéb bugot orvosol.
A Microsoft ebben a hónapban megkezdi a SHA-1 üzenetpecsétet használó digitális tanúsítványok kivezetését, "elavultnak" jelölve az algoritmust a Root Certificate programban. Az algoritmus 2016-tól nem lesz efogadható. Emellett PKI-t érintő változás, hogy egy másik frissítésnek köszönhetően a Windows 8.1-hez hasonlóan a korábbi operációsrendszer típusokon is letilthatóvá válik az RC4 folyamtitkosító használata, az okokról az SRD-nél lehet olvasni.
De térjünk rá a javított sérülékenységekre:
MS13-088: Az ehavi IE javítócsomag összesen 10 sérülékenységet orvosol, de vigyázat, a vadon keringő 0-day exploitok megfogására nem ez a frissítés lesz a jó!
MS13-089: Egy integer túlcsordulás a GDI alrendszerben távoli kódfuttatást tehet lehetővé rendszer szintű jogkörrel minden támogatott Windows változaton speciális Windows WRI fájlokon keresztül.
MS13-090: Ez egy külön javítás azInformationCardSigninHelper ActiveX vezérlő aktív kihasználás alatt álló,kódfuttatást lehetővé tevő problémájához. A vadon keringő exploit a ROP lánca pontos megválasztásához egy msvcrt.dll-t érintő információszivárgás problémát használ ki, mellyel megállapítható a DLL fordítási ideje - ezt a hibát ebben a hónapban nem javítják, mint ahogy a szintén
MS13-092: Windows 8 és Server 2012 Hyper-V megvalósítását érintő probléma javítása, ami lehetővé teheti kékhalál előidézését guestből a hoszt rendszeren, vagy idegen guestek memóriájához történő hozzáférést.
MS13-093: Az Ancillary Function Driver hibája lehetővé teszi a kernel memória olvasását alacsony jogosultságú folyamatok által. A probléma információszivárgás, a sérülékenység jogosultságkiterjesztésre önmagában nem alkalmas.
MS13-094: Speciális S/MIME e-maileken keresztül az Outlook hibáján keresztül ki lehet fürkénszni, hogy mi a kliens IP címe, illetve hogy milyen portokat tart nyitva. Fifikás bug lehet, kár, hogy általában nem túl hasznos.
MS13-095: A támogatott Windows változatokon futó webszolgáltatások megölhetők speciális X.509 tanúsítványokkal, már amennyiben a célpont szolgáltatások feldolgoznak ilyet.
A Google Chrome-ban - a Flash frissítésén túl - 25 hibát javítottak, ebből 7 kritikus sérülékenységre összesen 11000 dollárt fizetett ki a cég.
OpenSSH
Az OpenSSH-ban egy autentikáció után triggerelhető memóriakorrupciós sérülékenységet javítottak. A probléma az AES-GCM titkosító mód használata esetén jelentkezik. mivel a probléma a bejelentkező user nevében futó folyamatot érinti, a kódfuttatás elérése elssorban az esetleges shell korlátozások megkerülésére lehet használható.
A CrySys Labor az Ukatemivel közösen elemzést készített az Adobe-tól kiszivárgott dumpban - ez jelenleg a legnagyobb nyilvános, éles rendszerből származó jelszó-adatbázis - található, magyar vonatkozású címekről. A statisztikák sajnos nem támasztják alá a marslakó-elméletet: úgy tűnik, mi is ugyanolyan rossz jelszavakat használunk mint bolygótársaink (illetve a maslakók is ugyanolyan rosszul választanak jelszót mint a földlakók, esetleg csak viszonylag kevés magyar marslakó...). Mivel az Adobe megtette azt a szívességet is a támadóknak, hogy jelszó-emlékeztető szövegeket is bekért a felhasználóktól, a kiszivárgott adatok ennek a kényelmi funkciónak a kockázatait is jól demonstrálják, a CrySys-Ukatemi megállapításai is jelentős mértékben támaszkodnak ezekre az információkra:
Sok citromail.hu felhasználó jelszava “citrom” – nem túl kreatív és veszélyes
Sok jelszó-tanács nagyon egyszerű ” a van ellentéte” “nem narancs” “A tudom ellentéte”
Sok tanács kiad plusz információt “Ugyanaz, mint az xy@z.hu címemen” – ez külön segítség, hogy mit támadhatunk meg még a jelszóval. “Mint mindenhol” – ez is egyértelműen gond, nemcsak, hogy ugyanazt a jelszót használja a felhasználó, de még segíti is a támadót, hogy továbbmenjen.
Sok felhasználó “nevem” “barátnő neve” “második nevem” szöveget írt, mondván, esetleg az email címéből ez nem következik. Ugyanakkor, a többi azonos jelszót használó felhasználónak elég egy szempillantást venni az email címeire, és triviális, hogy ha 20 emberből 10-nek csilla szerepel a címében, akkor a jelszó csilla, vagy annak becézése lesz. És innentől egy vadidegenről azt is tudhatjuk, hogy mi a neve, barátnője neve, második neve stb., ami segítség ún. social engineering támadásokhoz is.
Az elemzés emellett kitér a helyes jelszóválasztási gyakorlat fontosságára is, kiemelve a jelmondatok, illetve hosszú, véletlengenerált jelszavak használatának előnyeit - itt ragadnám meg az alkalmat, hogy egy kicsit elmélyedjek a jelszótörés parktikus szempontjaiban, és megpróbáljam kicsit tisztázni a biztonsági szakemberek sokszor kuszának tűnő tanácsait. A mostani tanács pl. így szól:
a cseresznye151pok[1] sokkalta biztonságosabb, mint a kr1sztinaIloveyou[2]. A legjobb, ha valami generátorral készítünk jelszavakat, ezek sem tudnak csodát tenni, de egy DooYee7goe5EeFa[3] nagyon erős.
Tegyük most félre a jelszóemlékeztetőket (ezekkel általában nagyon könnyű a támadó dolga), és nézzük meg, miért rosszabb a 2. jelszó a társainál!
A legfontosabb érv, hogy a felhasználó családi hátterének, szokásainak ismeretében a 2. jelszó kitalálható. Ez természetesen nem jó, ha nem szeretnénk, ha pl. Krisztina megnézné, kinek és mit üzengetünk a fészen.
Érdemes azonban megjegyezni, hogy egy Adobe-hoz hasonló incidenst követően a támadó nem fog nekiállni találgatni (helyes kriptót, és nem létező jelszóemlékeztetőt feltételezve), hanem szótárakat és nyers erőt használ. Ebben az esetben a 2. jelszó vélhetően hasonlóan jól fog teljesíteni, azonban sajnos a kíváncsi hozzátartozók gyakoribbak, mint a jelszavakat érintő incidensek, ezért érdemes az előbbire is felkészülni.
Egy másik vetülete a problémának, hogy a jelmondatok is lehetnek rosszak: az ómilycsodásteazsúr[4] például gyengébb lehet, mint az 1. jelölt, mégpedig azért, mert a felhasznált szavak nem függetlenek egymástól (eltekintve attól, hogy a jelsóz egyben egy idézet is, ezekre pedig szintén lehet szótárakat készíteni):
A jelszótörők körében rég óta bevett módszer, hogy a lehetséges jelszavakat nem természetes sorrendjükben (pl. ABC sorrendben) próbálgatják, hanem valamiféle használati statisztikára alapozva. Egyszerű jelszavak esetén például feltételezhetjük, hogy a magán- illeve mássalhangzók felváltva követik egymást, hogy a jelszó kimondható és ezzel könnyebben megjegyezhető legyen. Ugyanígy a jelmondatoknál feltehetjük, hogy egy melléknevet jó eséllyel egy főnév fog követni (hú, de rég volt nyelvtan óra!). Ezzel persze a támadó által bejárandó kulcstér azonos méretű marad, azonban a nem véletlenszerűen generált jelszavakat hamarabb megtalálhatja. Elméletileg.
Gyakorlatilag azonban jelmondatok esetén számolni kell egy jó adag bizonytalansági tényezővel a nyelvtől elkezdve a ragokon és kötőszavakon át egyészen a mondat stílusáig (nagyon nem mindegy, hogy Ady-t idézünk, vagy a lulz-nyelvtant követjük). Emiatt az erősség-megjegyezhetőség egyensúlyára való tekintettel egy ilyen jelmondat jó kompromisszum lehet.
Mindemellett persze nem szabad megfeledkeznünk a jelszavak újrafelhasználásából adódó kockátokról, melyeket leginkább egy jól megválasztott (offline) jelszó menedzser alkalmazással minimalizálhatunk. Ezekekkel egy füst alatt a komplex jelszavak problémáját is elintézhetjük.
PS: Észrevettétek, hogy pl. a PayPal Copy-Paste-t letiltó biztonsági rendszere kifejezetten megnehezíti a jelszómenedzserek használatát?
A fejleményekért és jövőbeni eseményekért kövessétek az esemény wiki oldalát.
+++
Kevésbé technikai agyú érdeklődőknek a Jövőképp csütörtöki (nov.14.) rendezvényét tudom ajánlani, melyet a BME-n tartanak 18:00-20:00 között, a téma pedig ismét a lehallgatási botrány lesz, mellyel kapcsolatban Bencsáth Boldizsár és Kiss Álmos Péter társaságában fogjuk osztani az észt - részletekért figyeljétek az egyesület honlapját!
