Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Zárt rendszerek

2013.08.17. 09:59 | buherator | 2 komment

Egy floridai börtön maximális biztonsági szintű szárnyának cellaajtajai kinyíltak, az egyik helyi banda tagjai üldözőbe vették egyik riválisukat, aki kiugrott egy második emeleti erkélyről, hogy elkerülje az összetűzést. Hasonló eset történt ugyanitt még májusban, áprilisban pedig Marylandben nyílt ki egyszerre 500 cellaajtó - akkor a számítógépes rendszer hibáját okolták a történtekért, melynek lehetőségét egyelőre floridában sem zárták ki. 

Természetesen kívülállóként szinte lehetetlen meghatározni az események valódi kiváltó okát - az összes ajtókinyílását eredményező "Group Release" utasítást akár egy korrupt őr is kiadhatta, a vezérlőteremben nincs kamera, a szoftver pedig úgy tűnik, nem végez megfelelő logolást - de szakértők már évekkel ezelőtt figyelmeztettek rá, hogy a börtönök vezérlő szoftverek a munkaállomások és a PLC-k szintjén is kiszolgáltatottak a belső és külső támadásoknak. 

“The software in the computer has only one kind of thing, operator error, and we don’t know what triggers that, so part of the inquiry is to find out what the software is saying,”
Tim Ryan, Miami-Dade Corrections

Ennek kapcsán osztanám meg egy gondolatomat, ami már régebb óta motoszkál a fejemben: A közelmúltban a nyilvánosságra került hírek és a saját személyes tapasztalatom is abba az irányba mutatnak, hogy a szűk piacra szánt informatikai rendszerek valódi aranybányát jelentenek a biztonsági kutatóknak, illetve a sérülékenységeket kihasználni kívánó feketekalaposoknak.

A legszembeötlőbb példa a Siemens WinCC ipari irányító és automatizáló szoftver, ami a Stuxnet kapcsán került reflektorfénybe. Azelőtt feltehetően csak kevesen tudtak a létezéséről, és még kevesebben voltak azok, akik rendelkeztek egy használható tesztpéldánnyal, nem beszélve a hozzá tartozó hardverről. A Stuxnet azonban megmutatta, hogy a szoftver minősége nem éppen kimagasló, azóta pedig számos arcpirító sérülékenységet fedeztek fel a programban. A hosszú időn át fenntartott alacsony sérülékenység- illetve incidensszámot tehát nem a jól kidolgozott szoftverfejlesztési folyamat, hanem a hozzáférhetetlenség garantálta. 

Ha belegondolunk, a helyzet hasonló egy időutazáshoz: a hőskori hackerek sokszor azért folyamodtak a biztonsági rendszerek kijátszásához, hogy a szélesebb nyilvánosság számára elérhetetlen eszközökhöz és dokumentációkhoz férjenek hozzá, a tapasztalat pedig azt mutatja, hogy a most górcső alá vett rendszerek biztonsági szintje is sokszor a 80-as, 90-es éveket idézi.

Az ebből eredő kockázat nyilvánvaló: miért foglalkozna egy támadó a széles körben elterjedt - ezért a tűzkeresztségen ("pwned!") sokszorosan átesett -, széjjelhardenelt alkalmazásokkal, mikor a nagy halaknál úgyis telepítve van valami ősi célszoftver, amin még a stack canary sincs engedélyezve? 

A történelem már sokszor megmutatta, hogy a helyzet nem változik egészen addig, amíg a vásárlók elég nyomást nem gyakorolnak a gyártókra, ehhez pedig rengeteg kutatásra és az információk nyílt megosztására van szükség. Mindehhez azonban feltétel a hozzáférés kiterjesztése, melyhez segítséget főként kalóz testvéreinktől várhatunk. 

Szóval kedves falábú-kampókezű barátaink, ha egy kis kihívásra vágytok amíg az aktuális, másfél oldalas forgatókönyvvel készített hollywoodi szuperprodukció transzkódolódik, vessetek egy félszemű pillantást az olyan appokra is, melyekkel például a delejt adják a gépetekbe, meg a gázt a rumfőzdébe - kincskereső térképeket tudok adni, ha kell.

Címkék: gondolat börtön scada stuxnet plc

CampZer0

2013.08.15. 11:33 | buherator | Szólj hozzá!

A hacker és maker közösségek sátras-kempingezős-szabadtéri konferenciáinak legutóbbi iterációja, az idei Observe Hack Make inspirálta a H.A.C.K. budapesti hackerspace tagjait egy magyar változat szervezésére. A cél egy szabadtéri konferencia létrehozása, ahol nem csak a hazai, hanem a környező és távolabbi országokból érkező hackereket és makereket is szívesen látják. Az esemény béta, CampZer0-nak keresztelt változata szeptember végén kerül megrendezésre, helyszíne a komáromi monostori erőd. A holland és német táborok mintájára készülő CampZer0 is önkéntesek munkájára alapoz, ezért akinek van elfekvő előadás-témája, vagy egyéb javaslata a szervezéssel kapcsolatban, az a levlistán/IRC-n/stb. csatlakozhat a projekthez.

A Call for Papers itt olvasható.

Címkék: esemény hsbp campzer0

A Google elismerte az Android CSPRNG hibáját

2013.08.15. 10:05 | buherator | Szólj hozzá!

A nagyjából 1 millió forintos BitCoin lenyúlást követően először ismerte el Google alkalmazott az Android kriptográfiailag biztonságos véletlengenerátorának (CSPRNG) hibáját. Alex Klyubin blogposztjában kifejti, hogy az Android SecureRandom implementációja ugyan a jó kriptográfiai tulajdonságokkal rendelkező OpenSSL könyvtárat használja, de az ebben található véletlengenerátort automatikusan nem seedeli. Ennek eredményeként minden alkalmazás, ami az Andorid SecureRandom implementációjára támaszkodik, vagy megfelelő seedelés nélkül, közvetlenül használja az OpenSSL véletlengenerátorát veszélyben lehet. 

Bár a gyártó kiadott egy hibajavítást a probléma megszűntetésére, nem lehet megjósolni, hogy ez mikor fog eljutni a különböző szolgáltatók által kibocsátott készülékekre, így az érintett szoftverfejlesztőknek azt javasolják, hogy emeljék be a Google által kiadott, elkerülő megoldást biztosító kódot az alkalmazásaikba. Ez egyrészt megkeveri az OpenSSL CSPRNG állapotát, másrészt egy új, jól seed-elt Providert regisztrál, így mint a JCA-t, mind közvetlenül az OpenSSL-t használó alkalmazások megvédhetik magukat.

Címkék: google patch android kriptográfia bitcoin prng

DEFCON: A dokumentumfilm

2013.08.14. 12:00 | buherator | Szólj hozzá!


Kötelező darab!

Frissítőkedd - 2013. augusztus

2013.08.13. 23:13 | buherator | Szólj hozzá!

Microsoft

MS13-059: Az ehavi IE frissítőcsomag összesen 8 kritikus hibajavítást hoz a böngészőhöz. A Microsoft hasznos újítása a havi összefoglalóhoz csatolt "kihasználhatósági táblázat", melyből megtudhatjuk, hogy az egy-egy bulletinen belül megoldott problémák hogyan érintik az adott szoftverek legfrissebb illetve régebbi verzióit. Az MS13-059 esetében például ehhez a javított sérülékenységhez még a legfrissebb Internet Explorerhez is nagy valószínűséggel születhet exploit a közeljövőben. A frissítés ezen túl mélyreható védelmet nyújt az ún. LdrHotPatchRoutine exploit technikával szemben, amiről részletesebben megemlékezünk majd az MS13-063 kapcsán.

MS13-060: Az OpenType feldolgozót érintő hiba javítása. A probléma csak a Windows XP és 2003 rendszereket érinti, azokat is csak akkor, ha a bengáli Unicode karakterkészlet telepítve van.

MS13-061: Oracle Outside In hibajavítások beemelése az Exchange Serverbe a gyártó júliusi illetve áprilisi CPU-jából. A sérülékenységek kódfuttatást eredményezhetnek az Exchange kiszolgálóna, amennyiben valamelyik felhasználó megnyit egy speciális csatolmányt OWA-ban.

MS13-062: Távoli privilégiumemelésnem becézett probléma a Microsoft RPC szolgáltatásában - egy autentikált felhasználó megszemélyesítheti a rendszer más felhasználóit így gyakorlatilag korlátlan hatalmat szerezve a hoszt felett. A csúnyának tűnő probléma minden támogatott Windows verziót érint, exploit születésére magas az esély.

MS13-063: Ez a javítás küszöböli ki a Yang Yu által nem rég a CanSecWesten bemutatott, privát exploitokban már korábban is használt univerzális ASLR+DEP megkerülést biztosító lehetőséget. Az SRD összefoglalója szerint a kiskaput a SharedUserData nevű memóriaterület jeleni, ami mindig fix pozícióra töltődik be a folyamatok címterébe, és tartalmaz egy rakás mutatót az NTDLL-re. Ezzel ugye egy tetszőleges olvasást biztosító hiba után megvan az ASLR megkerülés, de a módszer igazi szépségét az adja, hogy az egyik hivatkozott eljárás, az LdrHotPatchRoutine, ami megteszi a támadónak azt a szívességet, hogy tetszőleges helyről (pl. egy hálózati megosztásról) betölt egy DLL-t, innentől pedig már ROP-olgatni sem kell. Windows 8-on ez a csel nem működik, a korábbi OS változatok felhasználói mostantól nem kell, hogy EMET-et használjanak a fenti módszert használó exploitok megállítására.

A folt ezen kívül orvosolja a Pwnie díjas j00ru három kernel sérülékenységét, melyek rendszer szintre történő jogosultságkiterjesztést tesznek lehetővé.

MS13-064: Egy NAT-olást végző Windows 2012 Server megdögleszthető egyetlen ICMP csomaggal. Ping of Death 2013?

MS13-065: Bármilyen XP/2003-nál újabb Windows megállítható egyetlen ICMPv6 csomaggal. Ping of Death v6?!

MS13-066: A végére úgy tűnik egy WTF gyűjtemény jutott. Az Active Directory Federation Services "információt" (feltehetően a szolgáltatáshoz tartozó felhasználó nevét) szivárogtat, amit egy támadó felhasználhat például arra, hogy bejelentkezési kísérletekkel zárolja a szolgáltatás felhasználói fiókját, ezzel működésképtelenné téve azt.

További jó hír, hogy a Microsoft kivezeti az MD5-öt használó tanúsítványait - ideje volt...

Google

A Google frissítette a Chrome OS stabil ágát, a mi szempontunkból viszont sokkal izgalmasabb, hogy a Chrome böngésző biztonsági hibáinak bejelentéséért fizethető jutalmakat a gyártó 5000 dollárra emelte, ami majdnem ötszörös jutalmat jelent az eddigiekhez képest. A Google ezen kívül bejelentette, hogy eddig összesen 2 millió dollárt fizettek ki a különböző sérülékenységvadász programokban (beleértve a Pwn2Own illetve Pwnium versenyeket is), így három év alatt több mint 2000 biztonsági hibát sikerült javítani. 

Mozilla

A Mozilla kiadta a Firefox böngésző 23-as változatát. A böngészőben több kritikus biztonsági hibajavítás mellett megjelent a Mixed Content Blocking, ami alapértelmezetten letilt bizonyos, HTTPS kapcsolaton elért oldalakra betöltődő HTTP tartalmat (helló microsoft.com!), így megnehezítve a közbeékelődéses támadások kivitelezését.

VMware

A VMware külső féltől származó könyvtárakat frissített az ESX illetve ESXi termékekben. Az OpenSSL könyvtárban időzítésen alapuló side-channel problémát illetve DoS előidézésére alkalmas NULL pointer dereferenciát javítottak, a libxml2-ben szintén DoS-hoz vezető, a belső entitások feloldásával kapcsolatos hibát foltoztak, a GnuTLS-ben pedig egy korábbi javítás javítása jött ki most, szintén DoS lehetőséget orvosolva.

Cisco

A Cisco arra figyelmeztet, hogy az OSPF routing protokolkezelőjének hibája miatt egy autentikált támadó kiürítheti az érintett eszközök routing tábláját és egy új LSA adatbázist tölthet fel, ezzel gyakorlatilag saját igényei szerint eltérítve a forgalmat, ami szolgáltatásmegtagadáshoz illetve közbeékelődéses támadásokhoz vezethet az érintett AS-ben. Az OSPFv3 illetve FSPF protokollt használó hálózatokat nem érinti a probléma. 

A gyártó ezen kívül több kritikus súlyosságú, kódfuttatásra alkalmas sérülékenységet javított több multimédia-átvitelt támogató termékben illetve a WAAS Central Managerben.

3COM/HP 

A SANS ISC arra figyelmeztet, hogy a 3COM/HP egyes routerei és switchei távolról kihasználható, kódfuttatást eredményező sérülékenységgel érintettek. A sérülékenységek 7.1 illetve a maximális 10.0 CVSS pontszámot kapták, ami jól jelzi a problémák súlyosságát. Frissítsetek, mielőtt valaki visszafejti a patch-et!

Címkék: microsoft google windows firefox patch internet explorer hp cisco mozilla vmware esx esxi ospf 3com chrome os ldrhotpatchroutine exchange server msrpc ping of death

Autó hackelés

2013.08.13. 14:55 | buherator | Szólj hozzá!

Bár az idei BlackHat számos kiváló kutatási témát mutatott be, egy kis hiba azért csúszott a gépezetbe: a valódi "rocksztárként" számontartott (az idei Hacktivity-re is hivatalos) Charlie Miller és Chris Valasek autóhackelésről szóló előadását valamiért nem fogadta el a programbizottság (bekerült viszont ez a hiperaktuális SQL injection előadás). Pánikra azért nincs ok, Millerék a DEFCON-on prezentálták munkájukat, a kutatási anyag pedig  ma végre felkerült az IOActive oldalára

A gyakorlatilag minden modern gépkocsiban jelenlévő vezérlőrendszerek hackelése nem teljesen új téma, a Washingtoni Egyetem kutatói már 2010-ben publikálták, hogy egyes autók szoftvere fölött Bluetooth vagy egy egyszerű CD segítségével át tudták venni az irányítást. Millerék munkája azért bír nagy jelentőséggel, mert a kutatópáros a vizsgált járművek (Ford Escape, Toyota Prius) beágyazott számítógépei által használt protokollok és algoritmusok részletes dokumentálása mellett az ezek hackelését megkönnyítő eszközkészletet is kiadták. 

A különböző számítási feladatokat végző elektronikus vezérlőegységek (electronic control unit - ECU) között egy CAN busz valósít meg közel real-time kommunikációt. Az üzenetküldés broadcast módon történik, vagyis minden üzenetet minden ECU megkap, az üzenetek küldője pedig nincs azonosítva, ami jelentősen megnehezítni a protokolüzenetek visszafejtését. Ennek ellenére a kutatóknak sikerült olyan univerzális szoftvereket készítenük, melyet úgy használhatunk, akár egy Netcat-et az IP hálózaton (innen valamint a fizikai interfész nevéből az eszköz neve: Ecomcat). 

A különböző kommunikációs szabványok alapján ezután elkezdhetünk játaszani a különböző ECU-kkal, melyek például az automata parkolást, sávkövetést segítik, vagy éppen az ütközéselkerüléskez nyújtanak asszisztenciát. Bár a legfontosabb hibakereső interfészek illetve funkciók használata autentikációhoz kötött, a kutatóknak a gyári diagnosztikai szoftverek visszafejtésével sikerült megszerezniük az egyszerű kihívás-válasz protokoll kulcsait, a Ford Escape esetében pedig egy olyan ECU-t is találtak, ami egy vélhetően ottfelejtett debug kódnak köszönhetően mindig azonos kihívást (seedet) generál. 

Mindezek ismeretében a vezérlőknek privilegizált parancsok adhatók, sőt még a működést meghatározó szenzorok adatai is meghamisíthatók, így például fixen rögzíthető vagy teljesen ki is kapcsolható a fék, melynek eredményeként Miller sikeresen le is rombolta garázsának hátsó traktusát. De a gyárban használt felületek segítségével akár ki is olvasható, majd tetszőleges adattal felül is írható az ECU-k memóriája, így gyakorlatilag saját szoftvert írhatunk az autónkhoz.

A Forbes videója

Mivel a vezérlőegységekhez csak az utastéren belülről, néhány esetben a műszerfal burkolatának eltávolítása után lehet hozzáférni, ezek az eredmények nem jelentik azt, hogy napjaink járművei egy otthon ülő hacker által átprogramozhatók lennének, de ne felejtsük el, hogy az autók belsejéhez történő fizikai hozzáférés sokszor egyszerűbb, mint gondolnánk. A most kiadott kutatási anyag és eszközkészlet a klasszikus hacker iskola első kérdéseinek, a "Hogyan működik?" és a "Mi történik ha?" megválaszolásában fog nagy segítséget nyújtani, ezt követően pedig jó, ha felkészülünk a meglepetésekre. 

Címkék: autó defcon blackhat ecu charlie miller chris valasek beágyazott rendszer

Android PRNG hiba - BitCoin tárcák veszélyben!

2013.08.11. 20:58 | buherator | 6 komment

A BitCoin.com-on megjelent figyelmeztető szerint az Android biztonságos véletlengenerátorának hibája miatt elcsenhető a készülékeken generált címekről azok tartalma. A HackerNews kommentelői szerint - és ezt a BitCoin Talk fórumbejegyzései is alátámasztják - a problémát az okozza, hogy a BitCoin tranzakciók aláírására használt ECDSA algoritmushoz az Android készülékek esetenként azonos véletlenszámot generálnak, két azonos véletlent használó tranzakcióból alapján pedig egy támadó új tranzakciót indíthat (a matekot frissítésben leírom).

A problémát tovább súlyosbítja, hogy az ilyen, nem megfelelően hitelesített tranzakciók (így a sérülékeny tárcák) könnyedén megtalálhatók, a BitCoin Talk már a probléma aktív kihasználásáról is beszámolt. 

Hab a tortán, hogy ha tényleg az Android PRNG-jével van a baj, az kriptográfiai alkalmazások sokaságát érintheti. Szerk.: Itt egy viszonylag friss kutatás a különböző SecureRandom implementációk biztonsági problémáiról.

A posztot folyamatosan frissítem.


BitCoin matek

Akkor a lájtos pánik közepén próbáljuk lenyugtatni magunkat némi egyszerű matekkal! Ahogy a BitCoin wiki írja, "az ECDSA az az algoritmus, ami garantálja, hogy a BitCoin-okat csak jogos tulajdonosuk költhesse el" - szóval egy elég fontos algoritmusról van szó :) Az ECDSA a (remélhetőleg) jól ismert DSA algoritmus elliptikus görbékre kiterjesztett változata. Az elliptikus görbék (EC) részleteibe vasárnap éjjel nem szeretnék belemenni, wacher jegyzetei remek összefoglalót adnak a témában, méghozzá magyar nyelven. A jelenlegi probléma megértéséhez a következőkkel kell tisztában lennünk:

  1. Az EC kriptorendszerek ún. trapdoor eljárása, ami garantálja az algoritmusok biztonságát az elliptikus görbék felett értelmezett sakláris szorzás, amit *-al fogunk jelölni. Q=n*P esetén (ahol P és Q egy adott görbe ismert pontjai) n skalár megtalálása nehéz feladat.
  2. Egy m üzenetre jelentősen leegyszerűsítve az ECDSA aláírás a következő módon áll elő (minden mod n értendő, n egy nagy szám): s=k^-1(H(m)+xr), ahol
    • k egy véletlen szám,
    • H() egy kriptográfiai hash függvény,
    • x az aláíró privát kulcsa,
    • r pedig a k*G pont első koordinátája, mellesleg az aláríás másik nyilvános tagja s mellett. 

Így két üzenetre az aláírások ideális esetben:

s1=k1^-1(H(m1)+xr1)
s2=k2^-1(H(m2)+xr2)

Amennyiben azonban k=k1=k2:

s1=k^-1(H(m1)+xr)
s2=k^-1(H(m2)+xr)

s1-s2=H(m1)/k+xr/k-(H(m2)/k+xr/k)=(H(m1)-H(m2))/k

Innen pedig k sima szorzással/osztással kijön, ahonnan az egyik ismert egyenlőséget átrendezve

x=(ks1-H(m1))/r  //Igen, ez a privát kulcs

(TL;DR) Vagyis a támadó végignézi a tranzakcióidat (ezt a BitCoin hálózat nyilvántartja), és ha talál két azonos k-val generált aláírást, kiszámolja a privát kulcsodat, amivel az összes lóvédat átutalhatja magának. 

Örülnék, ha egy kriptoguru átnézné ezt a részt, ezen kívül miért nincs a blog.hu-n LaTeX?

 

Címkék: android kriptográfia bitcoin prng

PoC || GTFO 0x00

2013.08.10. 18:17 | buherator | Szólj hozzá!

Az új Phrack megjelenésére várva néhány hacker nagyágyú egy új kezdeményezést indított PoC||GTFO néven. A digitális újság nulladik száma nevéhez méltóan egy PoC is melyben az ötletgazdák példával mutatják be, hogyan is működik az elképzelésük: A PoC||GTFO elsődleges célja az inspiráció, melyhez a szerkesztőség olyan rövid, de frappáns írásokat vár, melyek nem jutnak el a Phrack vagy az Uninformed magasságáig, cserébe viszont könnyebb megszülni őket és új, értékes gondolatokat plántálhatnak az értő olvasó fejébe. 

Az elvárás teljesítésére kiváló példa Travis Goodspeed cikke, melyben bemutatásra kerül, hogy hogyan alakítható egy régi iPod önmegsemmisítő adathordozóvá egy néhány soros patch segítségével. A módszer lényege, hogy a firmware detektálja, ha a felhasználó a fájlrendszer bejárása helyett szekvenciálisan olvas a lemezről (ahogyan azt sok forensic eszköz teszi), ilyen esetben pedig felülírja a tároló tartalmát. A módszer persze nem bombabiztos, de legalább az iPod rendeltetésszerűen használható marad.

A nulladik számban sok szó esik az ELF metaadatokról is. Sergey Bratus és Julian Bangert munkájából megtudhatjuk például, hogy a Linux kernel és dinamikus betöltő eltérő implementációja miatt egy ELF bináris egyszerre lehet futtatható állomány és dinamikus könyvtár, melyek ráadásul teljesen más funkcionlitással rendelkeznek. De hasonló kavarodást tud okozni az egyszeri reverse engineer fejében Bx is, aki az ELF metaadatokat a libc-be történő visszatérésre használja az úgynevezett IFUNC szimbólumok segítségével. 

Persze a technikai anyagok mellett frissítőül néhány történelmi témájú értekezés is elfért, Pastor például az elmúlt idők tapasztalatai alapján javaslatot tesz az eljövendő idők kutatásainak helyes publikálási módjára, egyúttal megpróbál békéltetni a sötét és világos oldalak között, FX pedig számos tanulságot szolgáltat arról, hogy miként ne próbáljunk meg aranykiadó automatát hackelni Abu-Dhabiban.

Jó inspirációgyűjtést, reméljük az első számban találkozunk majd közeli ismerősökkel! 

Címkék: linux gondolat bx elf fx pastor forensics travis goodspeed pocorgtfo segey bratus julian bangert

FireFox (Ped)0-day

2013.08.04. 21:13 | buherator | 13 komment

Írországban letartóztatták Eric Eoin Marquest, a FreedomHosting tulajdonosát, akit pedofil tartalmak terjesztésével vádolnak. A Freedom-Hosting szolgálta ki a Tor rejtett szolgáltatások nagyjából felét. A vád szerint a szolgáltató nagy számú oldalon szolgált ki "extrém erőszakos", gyerekkorú áldozatokat szerepeltető tartalmakat.

A gyermekpronográfiával foglalkozó online fórumokon jelenleg pánik uralkodik, ugyanis úgy tűnik, hogy az nyomozást végző FBI Firefox 17-et célzó 0-day exploitot helyezett el több FH-s oldalon (érdekes, bár valószínűleg véletlen egybeesés, hogy egy sérülékenység bróker néhány hónapja külön jutalmat tűzött ki FF 0-day-ekre), hogy bemérhesse a látogatókat - bár maga a Tor szolgáltatás biztosítja a felhasználók és a szolgáltatások anonimitását, a Tor kliens gyakran a Firefox böngészővel egybecsomagolva érkezik, így a szoftver sérülékenyégeit kihasználva, a Tor hálózatából kilépve le lehet buktatni a felhasználókat. 

Az exploit első blikkre egy szokásos use-after-free-nek tűnik, de a megbízható kihasználással illetve a teljes analízissel még akadnak problémák.

Marquest amerikai-ír kettős állampolgár, jelenleg az Államokba történő kiadatására vár, és óvadák ellenében sem helyezhető szabadlábra. 

Friss(201308050117): A Tor Project közleménye itt olvasható.

Friss(201308051642): Úgy tűnik, mégsem 0-day sérülékenységről van szó.

Friss(2013052033): Úgy tűnik, a malware az NSA-hez szólt haza.

Címkék: firefox bukta fbi pedofil tor anonimitás 0day freedom-hosting

Pwnie Awards 2013

2013.08.02. 15:53 | buherator | Szólj hozzá!

A BlackHat konferencián ottani időszerint tegnap átadták az idei Pwnie-díjakat, íme a győztesek, illetve néhány szó a többi jelöltről:

Legjobb szerver-oldali bug

Idén a Ruby on Rails elég erősen kezdett, a különbözö YAML injection problémák már-már kiírthatatlannak tűntek, miközben mindent-nyitó kulcsot adtak alkalmazások sokaságához - Ben Murphy megérdemelten kapta tehát a díjat, de reméljük a többi Ruby hackert is meghívja majd egy-egy sörre.

A kategóriában jelölték még az offline jelszótörést lehetővé tevő Oracle sérülékenységet, az Asterisk távolról kihasználható, kódfuttatásra alkalmas sérülékenységét, az Internet irányából is gyakran elérhető SAPRouter heap-overflow-it, illetve az Nginx két HTTP fejlécekkel kihasználható (ha úgy tetszik, régimódi) sérülékenységeit. 

Legjobb kliens-oldali bug

A kliens-oldali sérülékenységek jelentőségét jól mutatja, hogy az idei jelöltek vagy Pwn2Own/Pwnium győztesek voltak, vagy ipari/államtitkokat nyúltak le a segítségükkel. A zsűri most a hivatásos feketekalaposokat ítélte jobbnak: Az Adobe Reader tiszta ROP payloadot használó, sandboxból is kitörni képes exploitja olyan gyöngyszemeket utasított maga mögé, mint egy másik célzott támadásban bevetett, kifinomult heap-manipulációt használó Flash exploit, a VUPEN IE10/Win8 kombót legyűrő gyöngyszeme,, vagy az MWR Chrome törése.

Legjobb jogosultság-kitrejesztést eredményező bug

A nyertes az evasi0n iOS jailbreak-je, melyet nap mint nap használ nagyjából 5 millió felhasználó. 

Bár Tavis Ormandy Windows 0-day-e, vagy sd ősrégi Linux kernel bugja után megnyalja a tíz ujját az egyszeri hacker, ezzel a népszerűséggel nem tudtak versenyezni.

A leginnovatívabb kutatás

A kategóriát idén uralták az alacsonyszintű problémák (kivételt csak a CRIME jelentett), melyek közül j00ru és Gynvael Coldwind Windows kernelt célzó race-condition kutatását emelte ki a döntőbizottság, ami összesen 37 privilégiumemelést lehetővé tevő bugot (és ezekhez kapcsolódó, szintén érdekes exploitot) eredményezett. 

A kategóriában ezen kívül láttunk user- és kernel-világbeli ASLR megkerülést és tisztán x86 MMU-val megvalósított Turing-gépet is. 

Legepikusabb FAIL

A hakin9-t és testvérmagazinjait (PenTest, eForensics stb.) sokan ismerik intenzív spam kampányaik eredményeként, de az Errata szépen összeszedi plagizált, ki nem fizetett és egyéb inkorrekt módon lehozott tartalmaikat. Szerencsére valaki megelégelte a lengyel csapat taktikáját, és beküldött egy - feltehetően Markov-láncokkal generált - marha professzionálisnak kinéző, de teljesen értelmetlen cikket "Nmap: The Internet Considered Harmful - DARPA Inference Checking Kludge Scanning" (DICKS) címmel, amit az újság profeeszinális szerkesztőgárdája csont nélkül le is hozott. 

A kategóriában indult még a Sophos, ami több lyukat nyitott a gépeken, mint amennyit bevédett, a kriptográfiából többszörösen megbuktatott CryptoCat, a digitális tanúsítványok ellenőrzését elbénázó Android, valamint az Egyesült Államok kormánya, aki 170.000 dollárnyi számítástechnikai felszerelést zúzatott be egy nem létező vírusfertőzés miatt. 

Legepikusabb 0wnage

US vs. Snowden - ezt azt hiszem nem kell kommentálni.

Szép volt még az Internet Census, melynek keretén belül valaki megtört egy halom SOHO routert, és ezekkel végig portscannelte az Internetet, Mudge kinyitotta a DARPA zsebeit hackerek számára, és érdemes megemlékeznünk arról is, hogyan hackelte vissza a Malware.lu az APT1 csapatot.

Az Életműdíjat a nem rég tisztázatlan körülmények között elhunyt, ATM és pacemaker hackjeivel híressé vált Barnaby Jack kapta.

Végül, de utolsó sorban, a legjobb dalnak kikiáltott Dual Core - All the Things azt hiszem, a jövő heti hekkcamp-re is tökéletes alapot fog szolgáltatni :)

iOS töltőhack

2013.08.02. 13:50 | buherator | Szólj hozzá!

Az idei BlackHat egyik lenagyobb médiavisszhangot kiváltó előadása az iOS eszközök töltőn keresztüli 0wnolása volt - az előadás után kikerültek a slide-ok, illetve a kapcsolódó cikk is, lássuk tehát, hogyan működik ez a támadás!

A módszer szépségét az adja, hogy a sérülékenységet felfedező Georgia Tech-es kutatók nem valamiféle alacsony-szintű feketemágiát használtak, hanem az iOS (néha túlzottan széles lehetőségeket adó) kényelmi funkcióit, valamint az Apple fejlesztők számára kialakított folyamatainak hiányosságait kötötték láncba és hozták létre a Mactans nevű, töltőnek látszó eszközt (valójában egy kis beágyazott számítógép, de az iOS interfésze számára ez mindegy), amely képes a legtöbb csatlakoztatott készüléket uralma alá hajtani. A kihasznált problémák/lehjetőségek listája a következő (itt a kliens az iOS-t futtató kütyü, a csatlakozó eszköz pedig a hoszt):

  1. Az iOS készülékek számára minden fizikailag csatlakoztatott hoszt alapértelmezetten megbízható
  2. A felhasználó nem kap tájékoztatást arról, ha a csatlakoztatott hoszt lekérdezéseket vagy módosításokat hajt végre a kliensen
  3. A telepített alkalmazások elrejthetők a felhasználó elől ugyanazzal a módszerrel, ahogy az Apple is elrejti a saját demó/teszt alkalmazásait a legyártott készülékeken
  4. A csatlakoztatott hoszt a felhasználó tudta és beleegyezése nélkül indíthat el alkalmazásokat a kliensen
  5. Az Apple Provisioning Portalon automatizáltan regisztrálhatók új készülékek

Mindezek ismeretében a támadás a következő módon zajlik:

  • A felhasználó feltolja a kütyüjét egy Mactans töltőre
  • Az 1. pont miatt a Mactans képes lekérni a kütyü egyedi azonosítóját, a UDID-t
  • A Mactans a beépített WiFi/3G modemsegítségéval kapcsolódik az Apple Provisioning Portal-jához, és az UDID-t felhasználva regisztrálja a készüléket (az 5. pont miatt ezt egy szoftver is megteheti). Ekkor a Mactans szert tesz egy Apple által aláírt tanúsítványra, ami lehetővé teszi számára, hogy módosítsa a kliens állapotát - pl. új alkalmazásokat telepítsen és elindítsa azokat
  • A Mactans telepíti a kapott provisioning profile-t a készülékre
  • A Mactans tetszőleges alkalmazást telepíthet a kliensre, melyet el is indíthat. 

Ennél a pontnál felhasználó nem vett észre semmit, a támadó lehetőségei pedig szerteágazóak (2., 3., 4. pontok):

Egyrészt a 3. pont miatt a Mactans pl. indíthat egy rejtett alkalmazást a háttérben, amely bizonyos időközönként képernyőképet készít, és így megvalósít egy érintőképernyős billentyűzetfigyelőt. Az alkalmazás elrejtéséhez mindössze egy "hidden" tartalmú node-ot kell elhelyezni az alkalmazás Info.plist fájljában, az ilyen alkalmazások sem a kliens menüjében, sem a folyamatkezelőben nem jelennek meg. 

Mindezt továbbgondolva láthatjuk, hogy a Mactans egyszerűen kikerüli az Apple szoftver-ellenőrzési folyamatát, így egyszerűen telepíthetünk olyan alkalmazásokat, melyek az AppStore-ba soha nem kerülhettek volna be, mindezt jalibreak nélkül. A legitim felhasználási módok mellett egy támadó könnyen telepíthet hátsú kaput biztosító alkalmazásokat, vagy jailbreakelheti a készüléket. 

ios_trust.png

A támadás kihasználhatóságát csökkenti, ha a kliens passcode-dal védett, ilyen esetben a felhasználónak fel kell oldania a zárat, miközben a készüléke a Mactans-hoz kapcsolódik. Az Apple ezen kívül legfeljebb 100 készülékre ad provisioning jogot egy fejlesztőnek, így nagy mennyiségű kliens megfertőzéséhez több fejlesztői hozzáférésre vna szükség. Végleges megoldásként a bétában elérhető iOS 7 már beleegyezést kér a felhasználótól, ha egy addig ismeretlen hosz próbál csatlakozni az eszközhöz.

Címkék: apple töltő blackhat ios mactans

Ezévi TLS támadás: BREACH

2013.08.01. 22:55 | buherator | 1 komment

Elkezdődött a BlackHat, és bár a politika idén talán kissé hangsúlyosabb a rendezvényen a szokásosnál, azért ebben az évben is megkapjuk a már jól megszokott TLS támadásunkat, melyet ezúttal BREACH névvel illetnek.

A módszer lényegében a CRIME újragondolása, vagy talán azt is lehetne mondani, hogy a CRIME egy eddig elhanyagolt alkalmazási lehetőségének kidomborítása:

Míg a CRIME a TLS tömörítési lehetőségét használja ki a HTTP kérések egyes részeinek megfejtésére, a BREACH a HTTP gzip kódolását használja a protokoll válaszüzeneteiben leküldött titkok megfejtésére.

A kutatást publikáló Gluck-Harris-Prado trió az Outlook Web Access-t használta a probléma demonstrálására. Ez a szoftver amellett, hogy igen elterjedt, CSRF tokeneket használ a beérkező kérések forrásának azonosítására, valamint megteszi azt a szívességet is, hogy a felhasználó által megadott URL paramétereket (megfelelő szűrés után) visszaírja a válaszba. 

Innentől kezdve a támadás lényegében megegyezik a CRIME-al: A támadó lehallgatja az áldozat TLS forgalmát, valamint ráveszi az áldozatot, hogy látogasson el egy általa kontrollált weboldalra. A támadó oldala ezek után kéréseket intéz a célpont kiszolgáló irányába, a lekért URL-be szúrva a CSRF token nevét (canary) valamint az első megtippelt byte-ot. Amennyiben a megtippelt byte értéke helyes volt, a válaszüzenet mérete az LZ77 tömörítésnek köszönhetően kisebb lesz, mint helytelen tipp esetén, így a canary értéke byte-onként kipörgethető, a titok ismeretében pedig a felhasználó (részben) megszemélyesíthetővé válik.

A gyakorlatban persze kevésbé egyszerű a dolog, a legnagyobb problémát a DEFLATE kódolás másik fele, a Huffman-kódolás okozza, ami könnyen elronthatja a mérési eredményeket (egy Huffman-kódolt helytelen tipp rövidebb kriptoszöveget eredményezhet, mint a helyes), de néhány ügyes trükkel ez a probléma is kiküszöbölhető.

Bár a most közzétett kutatási anyag igyekszik megoldásokat javasolni a problémára, ezek egyike sem tűnik olyan kézenfekvő gyógyítnek, mint a TLS tömörítés kikapcsolása volt a CRIME esetében, vagy a titkosító algoritmusok átpriorizálása a BEAST-nél (a módszer blokk- és folyamtitkosítók esetén is hatásos).

És bár a támadás viszonylag erős támadói modellt feltételez, mostanában a Rizzo-Duong páros által felvetett, állami kihasználás egyre valósabb problémának tűnik a nyugati államokban is, ezért a legjobb, ha meghallgatjuk Keith Alexander tábornok előadását, aki majd jól megnyugtat mindenkit :)

Címkék: kriptográfia crime tls blackhat breach

Júliusi jelszócsere

2013.07.22. 11:17 | buherator | 1 komment

Úgy tűnik a nagy melegtől beindultak a banditák: a napokban elvitték az Ubuntu Forums adatbázisát (itt saltolt, hash-elt jelszavak voltak), elvitték a NASDAQ fórumának felhasználói információit, az Apple Dev Centeréből pedig kevésbé értékes személyes adatokat sikerült zsákmányolni, egyelőre mindkét site áll.

Lazán kapcsolódó hír, hogy a Tumblr-nél észbekaptak, hogy az iOS-es alkalmazások nyílt szövegként küldik el a felhasználók jelszavait bejelentkezéskor, így azok passzív hálózati támadók számára lehallgathatók lehetnek. Mivel a probléma kihasználásának valószínűsége igen magas a szolgáltató az alkalmazás összes felhasználójának jelszócserét javasol

Címkék: apple incidens ubuntu nasdaq tumblr devcenter ubuntuforums.com

Újabb Android aláírás hiba

2013.07.16. 14:54 | buherator | Szólj hozzá!

A kínai Android Security Team [meglepetés kínai link] egy, a Bluebox-éhoz hasonló problémát fedezett fel az Android APK ellenőrző eljárásában. Az APK fájlok fejléce egy változó méretű mezőt ("extra field") tartalmaz, melynek aktuális méretét egy korábbi, 2 byte-os érték adja meg. Az APK ellenőrzésekor az operációs rendszer erre a 2 byte-os értékre hagyatkozva dönti el, hogy hol kezdődnek az alkalmazás fájljai, köztük a lefordított osztályokat tartalmazó classes.dex fájl. A baj az, hogy a rendszer ezt a hosszértéket előjeles shortként értelmezi, így az érték negatívba billenthető:

Forrás: H-Online, Android Security Team

Amennyiben az érték 0xFFFD, az ellenőrzés az extra field-et megelőző 3. byte-on fog kezdődni, ami éppen a fájlnevet (classes.dex) tartalmazó fejléc vége, vagyis a dex karakterlánc, ami megegyezik a .dex fájlok első három "magic" byte-jával. Ezt kihasználva egy támadó bemásolhatja az eredeti classes.dex fájlt (minusz az első három byte-ot) az extra field-be, a rendszer pedig ezt az eredeti fájlt fogja ellenőrizni, futtatni viszont az APK törzsébe elhelyezett, módosított változatot fogja.

A sérülékenység kihasználását korlátozza, hogy az extra field mérete maximum 64KB lehet, ennél nagyobb .dex-el tehát nem működik a támadás. A problémára a Google és a CyanogenMod is javítást adott ki.

Címkék: google android apk android security team

Frissítőkedd - 2013. július

2013.07.10. 23:53 | buherator | Szólj hozzá!

Microsoft

MS13-052: 7 hibajavítás a .Net keretrendszerhez, és a Silverlighthoz. A legsúlyosabb probléma kliens oldalon kernel módú kódfuttatást tesz lehetővé (ismét TrueType) speciálisan összeállítot weboldalakon keresztül. A .Net sérülékenységek a Code Access Security megkerülésére is lehetőséget adnak.

MS13-053: Ebben a csomagban összesen hét kernel driverekhez kapcsolódó problémát javítanak, köztük még egy TrueType fontkezeléshez kapcsolódó, weben keresztül kihasználható biztonsági problémát, valamint a Tavis Ormandy által korábban nyilvánosságra hozott sérülékenységet is. Utóbbi sérülékenységet az hírek szerint már korábban kihasználták célzott  támadások során privilégiumemelésre.

MS13-054: Ééés még egy TrueType-pal kapcsolatos hiba! Ez a rosszaság a GDI+ rétegben bújt el és Office-on, Lyncen illetve Visual Studion keresztül tesz lehetővé kódfuttatást, ismét csak rendszer szintű jogosultságokkal. 

MS13-055: Összesen tizenhét hibajavítás az Internet Explorer különböző változataihoz. Kliens-oldali támadásokhoz ezek is remekül használhatók, de nem rögtön az rendszermagba dobják a szerencsés támadót, hanem "csak" a bejelentkezett felhasználó jogait biztosítják. 

MS13-056: Egy tetsztőleges-írást biztosító probléma a DirectShow API-ban kódfuttatást tesz lehetővé, ha a felhasználó megtekint egy spéci GIF-et valamilyen, a hibás API-t használó, harmadik féltől származó alkalmazás segítségével. 

MS13-057: A Windows WMV dekóderének hibája kódfuttatást tesz lehetővé speciálisan összeállított médiafájlok lejátszásakor. Vigyázzatok a megbízhatatlan forrásbóül származó pornóval audiovizuális műalkotásokkal! ;)

MS13-058: Az ehavi gyűjtés egyetlen nem kritikus besorolású eleme a Windows Defendert érinti. A védelmi szoftver frissítéskor lefuttat egy meghatározott nevű fájlt a C:\ gyökérből, ami értelem szerűen jogosultságkiterjesztést enged azon felhasználók számára, akik képesek létrehozni/módosítani ezt a fájlt.

A fentieken túl a Microsoft új biztonsági szabályzatot vezet be a cég online piacterein. Ennek értelmében a Microsoft értesíti a feltöltött alkalmazások gazdáit a szoftverük fontos és kritikus sérülékenységeiről, melyeket a fejlesztő 180 napon belül köteles javítani, ellenkező esetben, illetve ha a sérülékenységet aktívan kihasználják, a Microsoft eltávolítja az alkalmazást.

Adobe

Szokásosan frissült a Flash Player és a Shockwave is, mindkét termékben távoli kódfuttatásra alkalmas problémákat javítottak. Jött egy hotfix a ColdFusion-höz is, ez egy DoS problémán kívül egy olyan sérülékenységet javít, ami lehetővé teszi az alkalmazás komponensek (Component) publikus metódusainak közvetlen meghívását WebSocketeken keresztül.

Az Adobe Reader 9-et nyugdíjazták, használjatok sandboxos X-t vagy méginkább XI-t (bár ezekkel is vannak problémák)!

Google

Megjelent a Chrome 28, a Google kb. 36.000 dollárt fizetett ki a különböző, javított sérülékenységek felfedezőinek, közülük Andrey Labunets 21.500 dollárt tehetett zsebre két hiba mestrei kombinálásáért.

A cég ezen kívül kiadta a foltot a Bluebox által bejelentett problémára - kérdés, hogy ez mennyi idő alatt jut el a különböző szolgáltatókon keresztül a végfelhasználókig.

Cisco

Címkék: microsoft google patch office adobe internet explorer .net cisco silverlight android truetype flash player shockwave player tavis ormandy

110

2013.07.10. 16:35 | buherator | 2 komment

so_many_bugs.pngAki érti, érti ;)

 

Címkék: buherablog

Androkalipszis

2013.07.08. 14:56 | buherator | Szólj hozzá!

A napokban elég rendes sajtóvisszhangja volt a Bluebox bejelentésének, mely szerint egy 900 millió Android készüléket érintő sérülékenységet készülnek demózni a vegasi Black Hat konferencián. Az ilyen bejelentésekkel az a baj, hogy ugyan semmilyen konkrétumot nem tartalmaznak, de igyekeznek minél nagyobb riadalmat kelteni a látogatottság maximalizálása érdekében (lásd még: FUD, publicity stunt). 

Most azonban megjelent egy kódrészlet, melynek szerzője a Google foltja alapján reprodukálta a hibát, melyet feltehetően a Bluebox is bejelentett. A vicc az, hogy mikor múlt héten Dnet számba vette a lehetőségeket, ő is felvázolta ugyanezt a problémát, és ezzel a felismeréssel feltehetően nem volt egyedül

A ZIP (JAR, APK) archívumok tartalmazhatnak duplikált fájlneveket, a jarsigner viszont nem a teljes archívumot, hanem az abban található egyes fájlokat írja alá, így előállhat az az eset, hogy az eszköz az eredeti állomány eredetiségét ellenőrzi (és rendben találja), majd a kicsomagolás során ugyanez a fájl felülírásra kerül az azonos nevű, módosított változattal, így kompromittálva az alkalmazást. 

És hogy mindennek mi a hatása? Ismét Dnetre hivatkoznék:

[...] nehéz globális léptékben, tömegesen kihasználni ezt a sebezhetőséget, mivel az egyes készülékek más-más [tanúsítvánnyal vannak aláírva], így nem lehet egy általánosan működő, mind a 900 millió aktivált androidos eszközt támadó kódot létrehozni. "Aki a Google Play Store-t használja, nehéz támadni, de kérdéses, hogy mi a helyzet az egyéb megoldásokkal, például az Amazon Kindle Fire táblagépek saját boltjával vagy azokkal az országokkal (pl. Kína), ahol nincs Play Store, így saját megoldások működnek, a Google védőszárnyai nélkül."

[...]

"A kutatás ugyanakkor fontos dologra mutat rá, ami egyébként más területekre is kihathat, mivel hasonló aláírást használnak a Java Web Start alkalmazások és a - ma már kevésbé elterjedt - Java appletek"

Címkék: android kriptográfia blackhat digitális aláírás bluebox apk 8219321

Decryptocat

2013.07.04. 13:21 | buherator | Szólj hozzá!

A PRISM botrány kapcsán ismét sorra születnek az átlagemberek számára elérhető titkosítási lehetőségeket bemutató cikkek és blogposztok, melyek szinte állandó szereplője a Cryptocat csevegőalkalmazás. Be kell vallanom, hogy az ilyen cikkekkel kapcsolatban erősek az előítéleteim, miután a Cryptocat indulásakor már sejteni lehetett, hogy nem kifejezett kripto-guruk állnak a szoftver hátterében.

Az ember persze nem véletlenül hajlnamos effajta prekoncepciók gyártására, a módszer az evolúció során már bizonyára sokszor hasznosnak bizonyult, és most sincs ez másként: 

Steve Thomas kicsit utánajárt a Cryptocat véletlengenerálási szokásainak, és több kisebb - de a szerzők (in)kompetenciáját jól demonstráló - bug feltárása után egy katasztrofális problémára derített fényt. Mint kiderült, a fejlesztőknek nagyon nehezen megy a byte-ok illetve decimális számjegyek(!) közti különbségtétel: a beszédes nevű genPrivateKey() függvény egy 32 byte-os véletlenszám helyett egy 32 decimális számjegyből álló stringet adott vissza, melyből az ECC kulcsgenerálási folyamat közben még több helyen lenyestek, így a Cryptocat felhasználói egy 2^54.15 méretű kulcstérből (vö. DES) dolgozhattak nagyjából egy évig (az 1.1.147 és 2.0.41 verziók között). 

A most kiadott Decryptocat egy meet-in-the-middle támadással képes a sérülékeny változatokkal generált kulcsok megtörésére és így az ezekkel generált üzenetek megfejtésére nagységrendileg 2^27 lépésben, ami néhány óra alatt végigjátszható házi eszközökkel. Ugyanezzel a támadással a 2.0.42-es változatban bevezetett algoritmus által nyújtott 2^106.3 méretű kulcstér szintén a gyökére redukálódik, ami egy elszánt támadó számára ugyancsak nem jelenthet leküzdhetetlen akadályt. 

Bár a jelenlegi verzióban a nyilvános kulcsgenerálás Steve szerint már megfelelően működik, a többi felfedezett bug alapján úgy tűnik, hogy nincs remény a szoftver hosszútávú megbízható működésére, a Cryptocat használatát ezért senkinek nem ajánlom!

Szerk.: Kínos mellékszál, hogy a neves Veracode már auditálta a Cryptocat-et, de nem talált semmilyen problémát...

Szerk2.: A Cryptocat közleménye itt olvasható.

Címkék: privacy kriptográfia fail cryptocat decryptocat

PRISM? Socmint? Titkosítsd a telefonbeszélgetéseid!

2013.06.27. 23:25 | buherator | 1 komment

A fél világ ki van akadva a PRISM sztorin, Snowden a poszt születésének pillanatában éppen a szomszédos Ausztriától próbál politikai menedéket kérni [szerk: valójában nem], az új ECHELON lelepleződése idején logikus gondolatnak tűnhet, ha okostelefonainkat különböző titkosító appokkal vértezzük fel. Azonban azon túl, hogy a jelenleg népszerű algoritmusok bizonyos idő elteltével megfejthetővé válhatnak, az okos titkosszolgák felismerik, hogy az igen bonyolult matematikai elméletek helyett érdemes a kevésbé bonyolult, alkalmazott területek felé fordulni.

És hibákat keresni a titkosító alkalmazásokban.

A neves biztonsági szakértő, Mark Dowd észrevette, hogy sok hasonló célra szánt app ugyanazt a nyílt forrású ZRTP könyvtárat használja, a ZRTPCPP-t. A ZRTP-t a SilentCircle alapító, nem mellessleg PGP atya Phil Zimmerman azért találta ki, hogy titkosított és hitelesített hálózati csatornákat építhessünk ki kizárólag RTP felett. Egyebek mellett a következő alkalmazásokban találhatjuk meg a ZRTPCPP könyvtárat:

  • SilentCircle (SilentPhone)
  • CSipSimple
  • LinPhone
  • TiVi

Ezen kívül minden termék érintett lehet, ami a GNU ccRTP könyvtárakat használja.

Rövid kutakodás után Mark távolról kihasználható heap és stack overflow sérülékenységeket talált, melyek kihasználását jónéhány információszivárgás probléma segíti. Így kis tulzással a kémek dolga csak annyi, hogy ránk csörögnek.

Bár a ZRTPCPP ugyancsak SilentCircle-nél dolgozó fejlesztője hamar javította a problémákat, több nagy gyártó még le van maradva, így Mark eltávolította az eredeti blogposztot, de a javítások a ZRTP könyvtár forrásában nagyszerűen böngészhetők GitHubon...

Címkék: bug tivi mark dowd zrtp zrtpcpp ccrtp csipsimple silentcircle linphone

Facebook Facepalm

2013.06.27. 15:38 | buherator | Szólj hozzá!

Sokat gondolkoztam, hogy hogyan adhatnék olyan címet ennek a posztnak, amiben szerepel a "Facebook feltörés" kifejezés, hogy még több féltékenységben örlődő szerencsétlen jöjjön erre, de sajnos nem voltam elég kreatív :(

Szóval Jack 20.000 dollárt zsebelt be egy olyan Facebook hibáért, amin még mindig nem tudok napirendre térni:

Mindenki kedvenc közösségi oldala megengedi, hogy hozzárendeljünk különböző mobil eszközöket, pl. telefonokat a profilunkhoz. Ez úgy megy, hogy az ember bejelentkezés után megadja a telefonszámát a weben, kap SMS-ben egy kódot a megadott számra, amit aztán szépen megad, ugyancsak a web-en, így az NSA a Facebook tudni fogja, hogy az éppen bejelentkezett személy rendelkezik a megadott telefonszámmal. 

Jack barátunk azonban rájött, hogy az SMS-kódot bekérő interfésznek átadásra kerül egy profile_id mező is, amit a felhasználó állíthat be, szerver oldalon pedig nem ellenőrzik , hogy a bejövő profile_id a bejelentkezett felhasználóhoz tartozik-e (ide nem tudok elég felkiáltújelet írni), így bárki fiókjához hozzá lehetett rendelni a saját telónkat. 

Egy regisztrált telefon segítségével pedig az ember remek dolgokat csinálhat, például két-faktorosan autentikálhat, de éppen a jelszavát is megváltoztathatja, méghozzá a régi jelszó ismerete nélkül (elfelejtett jelszó), innentől pedig ugyebár gémóver van. 

Kedves Hölgyeim és Uraim: igen, a Facebooknál is követnek el ekkora szarvashibákat!

(via dnet)

Címkék: bug facebook sms facepalm

Malware Opera tanúsítvánnyal

2013.06.27. 10:01 | buherator | Szólj hozzá!

Illetéktelenek hatoltak be az Opera infrastruktúrájába, ahonnan legalább egy régebbi, lejárt kódaláíró tanúsítványt sikerült zsákmányolniuk. A támadók a tanúsítványt kártékony programok hitelesítésére használták, melyek az Opera egyik szerverén keresztül letöltődtek néhány ezer olyan felhasználó gépére, akik június 19-én itteni idő szerint 3:00 és 3:36 között Windowson használták a böngészőt. 

Információ a malware-ről illetve az azt sikeresen detektáló AV-k listája megtalálható a VirusTotal-on. Az Opera ma kiadott egy új verziót, ami elméletileg automatikusan felülcsapja a régebbi (potenciálisan fertőzött változatokat), ezt mindenkinek érdemes telepítenie. 

Címkék: opera incidens malware

Java frissítések

2013.06.21. 11:28 | buherator | Szólj hozzá!

A héten megjelent az Oracle júniusra időzített Java frissítő csomagja. A 40 javított sérülékenység közül 17 távolról, autentikáció nélkül kihasználható. 34 javítás kizárólag kliens oldali alkalmazásokat érint, 4 darab szerverekre és kliensekre is veszélyes. Egy sérülékenység a Java installeren keresztül tesz lehetővé helyi privilégium-kiterjesztést, végül a Javadoc eszköz foltja megakadályozza, hogy a generált dokumentáción keresztül frame injection támadást lehessen végrehajtani. A már legenerált dokumentációkat ezzel az eszközzel lehet megjavítani.

A frissítés kiadásával párhuzamosan az Oracle nyugdíjazta a Java 6-ot, mindenkinek ajánlott a frissítés a 7-es főverzióra. 

Látható, hogy a Java még mindig bőséggel tartogat veszélyes sérülékenységeket, melyek első sorban (de nem kizárólag!) a kliens-installációkat érintik. A Java 7-re történő váltás már csak a beépített biztonsági policy-k miatt is erősen ajánlott, aki pedig csak desktop alkalmazásokat kíván futtatni, annak továbbra is javasolható a Microsoft FixIt-je, ami letiltja az IE-ben futtatandó minialkalmazásokat - az alternatív böngészők felhasználói eleve jól használható védelmet kapnak a beépített click-to-play-el. 

Címkék: java patch internet explorer oracle fixit

Microsoft vérdíjak

2013.06.20. 13:39 | buherator | Szólj hozzá!

A Microsoft június 26-tól három pályázatot indít a szoftvereiben használt biztonsági megoldások fejlesztésére. 

A Mitigation Bypass Bounty-ban 100.000 dollárt ajánlanak fel annak a kutatónak, aki a leginnovatívabb általános megoldást adja a cég legfrissebb szoftvereiben implementált memóriavédelmi megoldások megkerülésére. Példaként említik a JIT-spraying technikát, ami a szoftverhibák széles skáláájának kihasználását teheti lehetővé.

50.000 dollár üti a markát annak a kutatónak, aki a cég jelenlegi technikáit kiegészítő, praktikusan alkalmazható új védelmi megoldást javasol.

A harmadik kategórában a cég 500-11.000 dollárt fizet az Internet Explorer 11 bétájában talált hibákért. Az alsó határon az ASLR kijátszására használható információszivárgások, a felsőn a Windows 8.1-en demonstrált, távoli, közepes integritási szintű kódfuttatást eredményező exploitok állnak.

A Microsoft tehát folytatja a BlueHat Prize-al megkezdett utat, de félreértés azt hinni, hogy ezzel a cég beállna az ipar többi nagy neve által diktált sorba, és ezen túl általánosan díjazná a sérülékenységek bejelentését. Úgy tűnik, hogy a cég még mindig elsősorban a defenzív kutatást támogatja, így valószínű, hogy a nagy megbízhatóságú 0-day-ek ezen túl is a nagyságrendekkel jobban fizető szürkegazdaságba fognak szivárogni. 

Címkék: microsoft blue hat prize microsoft security bounty program msbp

Spotify

2013.06.19. 17:26 | buherator | Szólj hozzá!

A Spotify egyik felhasználója fórumbejegyzésben hívta fel a közösség (és a fejlesztők) figyelmét, hogy tetszőleges felhasználói fiók felett át lehet venni az irányítást. A történet a Unicode karakterek kezelésével volt összefüggésben, a Spotify ugyanis úttörő módon megengedi a nem-ASCII karakterek használatát a felhasználónevekben. A támadás valahogy így nézett ki:

  1. Vegyük az áldozat felhasználónevét - az eredeti példánál maradva legyen ez a példában a bigbird
  2. Generáljunk egy új, unicode felhasználónevet valahogy így: ᴮᴵᴳᴮᴵᴿᴰ 
    ( u’\u1d2e\u1d35\u1d33\u1d2e\u1d35\u1d3f\u1d30′)
  3. Kérjünk jelszóemlékeztetőt az új fiókra
  4. A jelszóemlékeztető e-mail megérkezik a címünkre, de az abban szereplő link már bigbird jelszavának megváltoztatására szolgál

És hogy mi okozta ezt a furcsa hibát?

A Spotify a regisztrált felhasználóneveket kanonizálja, vagyis úgy alakítja át, hogy a kanonizált formában eltűnjenek az eredeti forma apró különbségei, melyek az adatok felhasználása során problémát okozhatnak. Például nem regisztrálható olyan felhasználónév, melynek kanonizált alakja már regisztrált, elkerülendő például a bigbird és Bigbird felhasználók összekeverését.

A Spotify különböző alrendszereiben gyakran kanonizálták a felhasználóneveket, abban a tudatban, hogy a művelet idempotens, vagyis egy bemenetet többször kanonizálva mindig ugyanazt az első kanonizált alakot kapjuk - így nem kell odafigyelni, hogy két modul együttműködésekor az interfészeken közlekedő adat milyen formában érkezik. 

Esetünkben azonban ez nem volt így, a felhasznált Twisted könyvtár ugyanis a Python egyik API-jának megváltozásának következtében nem idempotens kimenetet adott:

>>> canonical_username(u'\u1d2e\u1d35\u1d33\u1d2e\u1d35\u1d3f\u1d30')
u'BIGBIRD'
>>> canonical_username(canonical_username(u'\u1d2e\u1d35\u1d33\u1d2e\u1d35\u1d3f\u1d30'))
u'bigbird'

A regisztrációkor illetve a jelszóemlékeztető küldésénél a felhasználónevek egyszer kerültek kanonizálásra, míg a jelszó kiütésénél kétszer, így a támadás 4. lépésében más felhasználóval dolgozott a rendszer mint az előző háromban. 

A Spotify élvezetes blogposztban foglalta össze a hiba feltárását, valamint a javítás folyamatát, melyben néhány hasznos tanulságot is összegeztek, ezek az én interpretációmban valahogy így szólnak:

  • Megfelelő bemenetellenőrzéssel a problmának elejét lehetett volna venni
  • A Unicode nehéz, és sokszor még az elterjedt könyvtárak sem kezelik jól
  • Nem érdemes nekimenni a hibát feltáró felhasználónak, hiszen hasznos információkkal szolgálhat a probléma megoldásához. A tárgyalt hibát bejelentő felhasználót a Spotify ingyen hónapokkal jutalmazta
  • Néha a verziófrissítés is bevezethet új hibákat.

Címkék: python twisted unicode spotify

EMET 4

2013.06.18. 18:29 | buherator | 1 komment

Megjelent az Enhanced Mitigation Experience Toolkit legfrissebb, 4-es verziója. A hoszt-hardening eszköz új főverziójában számos izgalmas újdonság található:

A Certificate Pinning lehetőséget biztosít, hogy Internet Explorer használata közben detektáljuk az SSL/TLS-el védett oldalak tanúsítványának változásait. Az EMET figyelmeztet, ha egy hoszt gyökér tanúsítója megváltozik, így könnyen észlelhetjük, ha például iráni srácok lopott tanúsítványokkal játszanak. Hasonló lehetőség más böngészőkhöz kiegészítők szintjén már rendelkezésre állt, de most azok is detektálhatják a PKI tökéletlenségeit kihasználó man-in-the-middle támadásokat, akik valamilyen oknál fogva a Microsoft böngészőjéhez ragaszkodnak. 

Az exploit-mitigációs technikák is továbbfejlődtek, lépést tartva a támadások finomodásával: Az új EMET kiterjeszti a ROP-védelmet az alacsony szintű memóriamanipulációs API-kra, és védelmet nyújt az EMET által dinamikusan beszúrt ellenőrző rutinok átugrására játszó módszerekkel szemben is. Az étlapra került ezen kívül az idei CanSecWest konferencián bemutatott (de privát exploitok ban már régebb óta használt) LdrHotPatchRoutine() feketelistázása is, így még egy kicsit feljebb került a léc az ASLR+DEP kijátszásához. 

Fontos újdonság továbbá, hogy az EMET ezen túl képes lesz együttműködni a Microsoft naplózó szolgáltatásaival, így a rögzített policy-sértések akár vállalati szinten, akár a Microsoft segítségével globálisan is felhasználhatók lesznek az új fenyegetések észlelésére és tanulmányozására. 

Az eszköz a fentieken túl számok kisebb újdonsággal, például átszabott felhasználói felülettel valamint konfigurációs varázslókkal érkezik, a verzióugrás tehát nagyon is indokoltnak tűnik. 

Tekintettel a célzott kliens-oldali támadások aktuálisan zajló aranykorára, az EMET használata minden komoly helyen megszívlelendő! 

Címkék: microsoft dep aslr rop hardening emet

süti beállítások módosítása