2010. szeptember havi bejegyzések

Ismét Ethical Hacking képzés a BME-n – Gyere el a bemutatóra!

Az Automatizálási és Alkalmazott Informatikai Tanszék, valamint a NetAcademia közös szervezésében hamarosan ismét hivatalos Ethical Hacking képzés indul a BME-n. Hogy kedvet csináljunk a képzéshez, szeptember 30-án tarunk belőle egy nyilvános bemutatót. Gyere el Te is!

Ami a bemutatón történni fog:

  • Mesélünk a képzésről és a szerezhető CEH minősítésről
  • Demózunk:
    • Fóti Marcell (NetAcademia): Hogyan legyünk SYSTEM? Egy törésmenet bemutatása user szintről a csúcsig.
    • Zsíros Péter (NetAcademia): A MetaSploit szépségei: exploitok „használata”
    • Balássy György (BME AAIT): Webalkalmazások felhasználó- és munkamenet-kezelésének kijátszása
    • Dávid Zoltán (BME AAIT): Windows jelszavak visszafejtése a tanszék saját jelszótörő programjával


A bemutató időpontja:
szeptember 30. (csütörtök), negyed 5
Helyszín: BME, Informatika épület, B.028. terem
A részvétel ingyenes.

Minden érdeklődőt szeretettel várunk!

Üdvözlettel:
a szervezők

Ui.: ha fent vagy a Facebookon, ott is jelentkezhetsz a bemutatóra – vagy csak gyere el: http://www.facebook.com/event.php?eid=147343205303988&index=1

 

Technorati-címkék:

Xamalot – clipart hegyek

Markus Egger Xamalot webhelye 13.000 ingyenes grafikai elemet, főként clipartot kínál letöltésre. Ez eddig még nem lenne különösebben érdekes, az igazi durranás az, hogy ezen a webhelyen a képek XAML Canvas, XAML Brush, SVG Vector Format és Bitmap (PNG, JPG…) formátumban tölthetőek le. Mivel a rendszer belül natívan XAML formátumban tárol mindent, ezért a letöltésnél további paraméterek (pl. namespace, resource dictionary stb.) adhatóak meg, sőt a bitmap formátumú fájlok is röptében keletkeznek az általunk megadott formátumban és méretben.

A webhelyen tárolt tartalom a közeljövőben folyamatosan bővülni fog, és várható, hogy a clipartok mellett sablonok, skinek, shaderek is letölthetőek lesznek – méghozzá ingyen.

Érdemes megnézni: http://www.xamalot.com/

Technorati-címkék: ,,,,

jQueryUI a Microsoft CDN-en

Ismét bővült a Microsoft CDN, ezúttal a jQueryUI legújabb, 1.8.5. változata került fel rá. Nem csak a scriptek kerültek fel, hanem a theme fájlok is, így az összes színben és stílusban elérhetőek a vezérlők.

Aki esetleg a Google CDN-t használja: oda is felkerült az 1.8.5 változat, valamint a theme fájlok is elérhetőek ott, csak épp nem dokumentálták agyon.

Technorati-címkék:

Kritikus 0day ASP.NET sebezhetőség és gyors védekezés

Utolsó kiegészítés: 2010.10.01. (Végjáték! Lásd a cikk végén)

Ahogy korábban már írtam róla, két hacker elég komoly hibát fedezett fel, amely az ASP.NET-es alkalmazások által használt titkosítást érinti. Sajnos a sebezhetőség részleteit csak pénteken hozták nyilvánosságra, ráadásul egy kész eszközt is közreadtak a kihasználására, sőt előtte a Microsofttal sem közölték a pontos módszert, így most a rossz fiúknak két teljes napjuk van, mielőtt a legtöbb webhely gazdája észbe kap (micsoda “véletlen” időzítés). Fontos, hogy a hiba alapvetően az összes ASP.NET-es webhelyet érinti, legyen az egyedi fejlesztésű, vagy kész rendszer, DotNetNuke vagy SharePoint ugyanúgy borulhat. Az üzemeltetőknek gyorsan kell lépniük!

A támadás egy ún. Padding Oracle Attack (semmi köze az adatbáziskezelőhöz), amely egy általános támadási módszer blokk titkosítások ellen – tehát nem csak ASP.NET, hanem például Apache MyFaces ellen vagy egy mezei CAPTCHA ellen is. A módszer alapja, hogy a blokk titkosítások működéséhez fel kell tölteni a blokkokat (padding), és ezt a paddingot a dekriptáláskor ellenőrizni kell. Ezért ha az alkalmazás egy titkosított értéket kap, akkor valójában háromféle dolog történhet:

  1. Ha a visszafejtett érték helyes és a padding is helyes, tipikusan HTTP 200 OK választ kapunk, az alkalmazás működik, ahogy kell.
  2. Ha a dekriptálás után a padding nem helyes, akkor az alkalmazás tipikusan valamilyen kriptográfiával kapcsolatos kivételt dob, és gyakran HTTP 500 Internal Server Error választ kapunk.
  3. Ha a visszafejtés után a padding helyes, de a dekriptált érték nem, akkor az alkalmazás valamilyen egyedi hibaoldalt dob (szintén HTTP 200 OK).

A beküldött értéket manipulálva a támadást brute force módon lehet automatizálni, a válaszul kapott értékekből és a válaszidőkből pedig meghatározható, hogy a fenti három esetből éppen melyik történt.

A dolog szépsége, hogy egy ASP.NET-es webalkalmazásnak számos helyen lehet ilyen titkosított értéket küldeni, a leggyakoribb célpont a query string, a ViewState és az authentication cookie lehet. Brute force próbálkozásokkal mindössze néhány perc alatt meghatározható a titkosításhoz használt initialization vector értéke. Erre már több kész eszköz létezik, az egyiket úgy hívják, hogy Padding Oracle Exploit Tool (POET).

Ha pedig megvan a “titkosító kulcs”, akkor természetesen szinte végtelenek a támadó lehetőségei, például:

  • Képes a titkosított ViewState visszafejtésére, ahol használható információkat találhat (information disclosure).
  • Képes a query string manipulálására. Itt a fő célpont a ScriptResource.axd, amit rá lehet venni a diszken lévő fájlok (pl. web.config) olvasására és visszaküldésére. Egyelőre úgy néz ki, hogy az alkalmazás mappáján kívül nem tud olvasni a támadó.
  • Képes az authentication cookie manipulálására. Ha a cookie szerepköröket is tartalmaz, akkor akár elő is léptetheti magát. Itt egy videó arról, hogy lesz a támadó atyaúristen DotNetNuke-on pár perc alatt, sőt a gépet is megszerzi SYSTEMként.

A korábbi információkkal ellentétben tehát a hiba nem az AES titkosításban van, így nem segít, ha csak az algoritmust állítjuk át.

A Microsoftnál gőzerővel dolgoznak a probléma megoldásán, és a javasolt workaround kidolgozásán. Mivel a sebezhetőség felfedezői nem voltak kimondottan együttműködőek, így a Microsoft is csak a nyilvánossággal egy időben tudta meg a részleteket. Már van egy Security Advisory (2416728), amelyből kiderül, hogy gyakorlatilag az összes .NET Framework verzió érintett, másrészt, hogy a gyors megoldás a web.config fájlban a customErrors szekcióban a mode=”On” és a defaultRedirect attribútum beállítása, valamint a hibaoldalak válaszidejének randomizálása. Fontos, hogy a customErrors=”remoteOnly” beállítás önmagában nem elég (ez a gond például a DotNetNuke-kal is, ami “csak” 600.000 éles site-ot érint), mert úgy még a támadó elég információhoz jut (átmennek a HTTP hibakódok), kell az On és az, hogy az összes hiba esetén azonos válaszoldalt kapjon a hívó.

Készül egy VBS szkript, amellyel könnyen detektálhatóvá válnak a szerverünkön azok az alkalmazások, ahol a customErrors szekció beállítása nem megfelelő. Ez a szkript még nem tökéletes, már többször frissült a blog post, folyamatosan javítják a hibáit. A futtatásához IIS 7-en az IIS 6 Metabase Compatibility modul telepítése szükséges és Run As Administratorként kell futtatni.

Lesz hivatalos patch is, de mivel csak péntek délután óta dolgozik ezen a csapat, még eltart pár napig, amíg az összes framework és operációs rendszer verzión tesztelik és kikerül a Windows Update-re. Ezért különösen fontos, hogy ezt a workaroundot a lehető leggyorsabban alkalmazzuk az összes alkalmazás esetén.

ScottGu pedig írja már a blog postját…

Kiegészítések (2010.09.20.)

  • Scott Guthrie blog postja megjelent és itt olvasható: http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
  • A Microsoft éjjel-nappal dolgozik a javításon, valószínűleg nagyon hamar meg fog jelenni a Windows Update-en, még a következő frissítő kedd előtt. Addig is érdemes a Scott blogjában és a Security Advisory-ban említett workaroundot SOS alkalmazni.
  • Fontos: bár minden szalagcím arról szól, hogy ez egy ASP.NET-es sebezhetőség, nem csak az ASP.NET-et érinti! Más platformon futó alkalmazások is lehetnek célpontok.
  • Egyre több szerveren látunk paddinggal kapcsolatos security exceptionöket, ami arra utal, hogy a támadások, vagy legalábbis a próbálkozások megindultak (bár ez a kivétel önmagában utalhat másra is).
  • A tanszékünkön fejlesztett Lens tesztelő eszközbe bekerült egy alapvető (nem 100%-os) távoli tesztelési lehetőség: http://ethicalhackingaspnet.codeplex.com/

Kiegészítések (2010.09.21.)

Kiegészítések (2010.09.25.)

  • A javítás sajnos egy hét alatt sem készült el, még mindig várjuk 😦
  • Scott újabb cikkében kiegészítést közölt a korábbi workaroundhoz, konkrétan, hogy célszerű UrlScant is alkalmazni a webszerveren.
  • Frissült a Security Advisory (2416728) is, bekerültek az UrlScan (IIS6) és a Request Filtering Module (IIS7) telepítésének lépései. A Request Filteringnél a script sorban /section:requestfiltering helyett helyesen szerintem /section:system.webServer/security/requestfiltering kellene, biztos majd kijavítják.
  • Kristofer Anderson készített egy POET Sniffer Service-t, ami a logokat elemzi folyamatosan, és jelez, ha a Padding Oracle támadásra jellemző jeleket talál.
  • David L. Penton írt egy listát azokról a beállításokról, amiket célszerű alkalmazni még a web.configban a támadás esélyének csökkentésére. Ezeket egyébként ettől a támadástól függetlenül is érdemes alkalmazni.

Kiegészítések (2010.09.30.)

  • Szép map ez a mai, megvan a javítás, pontosabban megvannak a javítások. Sajnos minden operációs rendszerhez és minden .NET verzióhoz külön patch van, az MS10-070 Security Bulletinben megtalálható mind. Sajnos tudásbázis cikkből is több van, nehéz lesz azonnal felismerni a frissítés száma alapján. A linkek megtalálhatóak a Gu friss blog postjában is a gyakori kérdésekkel és válaszokkal együtt.
  • Fontos: A .NET 3.5 RTM és .NET 3.5 SP1-hez két javítófoltot kell telepíteni, az egyik a 2.0, a másik a 3.5 réteget frissíti.
  • A javítás egyelőre csak a Microsoft Download Centerből érhető le és csak manuálisan telepíthető. Még néhány nap, mire kikerül a Windows Update-re és az automatikus frissítő csatornákra. A kritikus rendszereket érdemes mielőbb kézzel patchelni.
  • A javítás elég tutinak tűnik, már felkerült az Azure szerverekre is.
  • A patchet telepíteni kell a TFS, TFS proxy, SharePoint és Reporting Services szerverekre is.
  • A telepítés után nem kell újraindítani a gépet, de a webszerver és az alkalmazások átmenetileg le fognak állni.
  • Fontos, hogy a patch megváltoztat bizonyos titkosítással és aláírással kapcsolatos részeket az ASP.NET-ben, ezért fontos, hogy egy farm összes gépére egyszerre kerüljön fel a javítás. Ha nem, akkor előfordulhat, hogy az egyik gép által adott forms authentication cookie-t a másik gép nem fogadja el.
  • Marginális eset, de fontos lehet, hogy annak idején az ASP.NET 2.0 RTM (vagy SP1) és a 2.0 SP2 között történtek változások a titkosítás terén. Mivel a 2.0 SP1 a 3.5 RTM része, a 2.0 SP2 pedig a 3.5 SP1 része, ezért gond lehet abból, ha a farm egyes elemei nem azonos verziójú Frameworköt futtatnak. A megoldás, hogy minden gépet ugyanarra a verzióra kell frissíteni.

Kiegészítések (2010.10.01.)

  • A javítások megjelentek a Windows Update-en, tehát elvileg hamarosan minden jólnevelt gépre fel fognak menni automatikusan. Szomorú, de nálam egy sima Windows 7 gépen telepítés után újra akarta indítani az operációs rendszert Szomorú arc
  • Mellékhatásként előfordulhat, hogy egy korábban elmentett perzisztens authentication cookie-t (Emlékezz Rám funkció) a rendszer nem fogad el, de ezt az esetet az ASP.NET automatikusan kezeli és hibaüzenet nélkül át fogja irányítani a felhasználót a bejelentkezés oldalra. Következő alkalommal már nem lesz gondja vele.
  • Ha az alkalmazásban egyedi authentication cookie matató kód van, annak lehet, hogy gondja lesz a cookie új formátumával. Ebben az esetben vagy a kódot kell frissíteni, vagy ha az alkalmazás nem bánja, akkor át lehet nevezni a cookie-t a web.config-ban.
Technorati-címkék: ,,,

IE9: Google Chrome Microsoft bőrben

Megjelent az IE9 első nyilvános béta változata, érdemes megnézni, hogy min dolgoztak a redmondi fiúk több, mint másfél évig. Lássuk be, épp ideje volt előrukkolni egy új verzióval, hiszen ennyi idő alatt a Google Chrome például négy nagy verziót lépett előre és szinte a semmiből érkezve elhalászta a piac jelentős részét. Nem is csoda, másfél naptári év internet években mérve több ezer évnek számít, ennyi ideig nem lehet csöndben csak ígérgetni az új verziót. Úgy tűnik, hogy megérte várni, az új verzió egészen impresszív.

“Ez egy Google Chrome” – ez volt az első benyomásom a telepítés után (erre még visszatérek). Először is egy villanás alatt elindult (de tényleg), másrészt a GUI éppolyan egyszerű és letisztult, mint a Chrome esetén. Aki ott nem szerette, hogy egyetlen mindent tudó beviteli mező van (itt a marketingesek One Box-nak hívják), nincs menü, állapotsor, az itt sem fogja szeretni az alapbeállításokat. Ráadásul statisztikák alapján odáig jutottak, hogy a legtöbb felhasználó egy böngésző ablakban csak kevés tabot nyit, ezért azok elférnek a címsorral egy vonalban. Nekem ez így elsőre kicsit szűkösnek tűnik, egy 1280×1024 felbontású monitoron nagyon hamar teljesen összezsúfolódnak a tabok feliratai:

Letisztult GUI

A “Clean” szlogenhez tartozik, hogy alapértelmezés szerint összesen egy menü van, az a fogaskerék “A” felső sáv jobb szélén, amiből még a nyomtatás sem megy egy kattintással, ezért bevallom, ez nem tetszik. Ki fogja használni ezek után a Safety menü funkcióit (pl. InPrivate Browsing), ha megtalálni sem lehet?

IE9-Menu

Persze, ha akarom, elő lehet varázsolni a Command Bart, de az olyan IE8-as feeling 🙂

Ugyanebbe a sorba került a Home gomb is, ez is jobbra. Nem tudom más hogy van vele, nálam a Home gomb a kezdet, az origo, a kályha, a tabula rasa. És mivel ahonnan én jövök, ott balról jobbra olvasunk, bizony számomra teljesen illogikus ennek a gombnak a mostani helye. A Stop és Refresh gombokat (amik a címsor jobb szélén vannak) át lehet tenni balra, a Home gombot nem (vagy csak nem jöttem rá, hogyan). Percekig kerestem, mire ráleltem.

Szintén percekig fogják keresni a felhasználók az ablak alsó részén felbukkanó figyelmeztetéseket és kérdéseket. Állítólag ott kevésbé zavaró, hát én pont azt gondolnám, hogy az ilyen üzenetek legalább annyira legyenek zavaróak, hogy észrevegye őket a felhasználó.

IE9-Notification Bar

Van végre beépített letöltéskezelő, amiben leginkább az tetszik, hogy összenőtt az IE SmartScreen Filterével, ami sok átlagfelhasználó számára fogja biztonságosabbá tenni a böngészést (persze csak azoknak, akik elolvassák az üzeneteket).

 IE-DownloadManager

Szintén hasznos újításnak tűnik, hogy a böngésző felhívja a felhasználó figyelmét azokra a beépülő modulokra, amik fojtogatják:

 IE9: addons advisor (Forrás: Arpit Kumar)

Bár ezt úgy “árulják”, hogy majd az átlagfelhasználó számára teszi gyorsabbá és élvezhetőbbé a böngészést, szerintem pont ők nem fognak tudni mit kezdeni ezzel az ablakkal, inkább fejlesztőknek szól. Szintén a fejlesztők fognak örülni, hogy a Firebug után pár évvel végre az IE Developer Toolsban is megjelent a Network fül, így végre Fiddler nélkül lehet belekukkantani a hálózati forgalomba:

IE9-Developer Tools Network fül

Hasznos, hogy a Go To Detailed View gombra kattintva további részleteket tudhatunk meg az egy requestekről és response-okről, a fejléc mezőkön, a tartalmon és a cookie-n kívül azt is, hogy a böngészőnek mennyi ideig tartott a kérés feldolgozása:

IE9-Developer Tools Detailed View

És persze nem feledkezhetünk meg a HTML5 és a CSS3 támogatásról sem, a hírek szerint ebből a szempontból az IE9 maga a paradicsom. És ez nekem alapvetően tetszik is, bár én ezt úgy fogalmaznám, hogy az IE9 felzárkózott a többi böngésző mögé. Arra tippelnék, hogy ha néhány nagyobb webhely (Google, YouTube, Facebook) elkezdenének csak HTML5 tartalmat szolgáltatni, maximum egy év alatt lecserélődne a teljes böngészőkészlet a klienseknél, ami nagyon, nagyon jó hír lenne a webfejlesztők számára. De nem fognak. Mégpedig (többek között) azért nem, mert az IE9 nem fog Windows XP-n futni, és még ezek a nagy webhelyek sem engedhetik meg maguknak, hogy a forgalmuk jelentős részét elveszítsék. Ha mégis, akkor a Microsoft nem fog jól járni, tömegesen fognak átállni a felhasználók más böngészőkre, mert böngészőt váltani sokkal egyszerűbb, mint operációs rendszert (amihez sokszor hardver váltás is szükséges).

Ezt a Windows 7 integrációt (többek között) az IE9 Pinned Sites funkciója használja ki. Eddig ha egy weboldalt ráhúztunk a tálcára, akkor a böngésző ikonja jelent meg a böngésző funkcióival. Most a weboldal funkciói közvetlenül a tálcán lesznek elérhetőek a Jump Listnek köszönhetően:

IE9-PinnedJumpList IE9-PinnedJumpListWithContols

Ez jól jöhet olyan helyeken, ahol a böngésző csak néhány alkalmazás kereteként funkcionál, mert egyébként ez nem más, mint egy előretolt Kedvencek lista. Ezen kívül nem hiszem, hogy sok webhely esetén igény mutatkozna erre a funkcióra (hányan gyártanak OpenSearch providert vagy acceleratort?), de majd meglátjuk.

Sajnos tehát az IE9 még mindig nem egy önálló böngésző, hanem az operációs rendszer szerves része, még a telepített programok között sem jelenik meg, csak a telepített frissítések között és persze csak Windows 7-en. Pedig milyen szép is lenne, ha egy derűs őszi napon a világ összes Windows felhasználója arra ébredne, hogy új böngészője van, ami megbízható, gyors benne a JavaScript motor és támogatja a HTML5 és a CSS3 újdonságait. A webfejlesztők megünnepelnék azt a napot, amikor az utolsó IE6 és IE7 változatok is eltűnnek a gépekről.

(A cikk szubjektív válogatás a böngésző újdonságaiból, teljes lista és leírás a http://www.beautyoftheweb.com oldalon található.)

Technorati-címkék: ,

Durva ASP.NET forms authentication sebezhetőség

Két kutató, Thai Duong és Juliano Rizzo hibát talált az ASP.NET űrlap alapú hitelesítésében, mégpedig a sütik (cookie) titkosításának megvalósításában. Állításuk szerint az általuk használt Padding Oracle Exploit Tool (POET) segítségével 100%-os biztonsággal, 30-50 perc alatt tetszőleges webhelyre meg tudják határozni a titkosításhoz használt Machine Key értékét. Márpedig ha megvan a Machine Key, akkor lehet offline hamis sütiket sütni, sőt, ha a webhely ezekben a sütikben szerepköröket is tárol, akkor a támadó akár magasabb jogosultságú szerepkörbe is léptetheti magát.

A helyzet ennél rosszabb, ugyanis a hiba a .NET Framework AES implementációjában van, ami akár más komponenseket és rendszereket is érinthet. Szerencsére az ASP.NET esetén elég egyszerű a megoldás, csak a web.configban át kell állítani a titkosítást 3DES-re:

  <machineKey validationKey="AutoGenerate,IsolateApps"         
    validation="3DES"                           
    decryptionKey="AutoGenerate,IsolateApps"
    decryption="3DES" />  

Ennél több részletet egyelőre nem hoztak nyilvánosságra, talán a pénteki Buenos Aires-i ekoparty Security Conference-en többet tudunk meg. A Microsoftnál már vizsgálják az esetet, hivatalos válasz egyelőre nincsen.

Ha kiderül, hogy a sebezhetőség igenis létezik, az bizony elég sok webhelyet érintene. Azonban nem árt tudni, hogy nem ez az egyetlen gyenge pontja az ASP.NET-es alkalmazásoknak. A tavaszi Ethical Hacking konferencián mutattam pár módszert, ami a fejlesztők szokásait és az alapbeállításokat használja ki, sőt a tanszéken saját eszközt is készítettünk ezek tesztelésére. Hamarosan ismét lesz Ethical Hacking képzés és bemutató a BME-n, ott mutatok ebből párat, mindenkit szeretettel várunk!

Technorati-címkék: ,,