Egy Full-Disclosure listára érkezett (pontosabban hozzám már meg nem érkezett) levélben valaki az amerikai T-Mobile adatait kínálgatja jó pénzért. Szerintetek?

Egy Full-Disclosure listára érkezett levél tanúsága szerint csúnyán helybenhagyták az  astalavista.com és astalavista.net domaineket. A levelet postázó srshaxsir azzal indokolta a támadást, valamint a megszerzett adatok nyilvánosságrahozatalát, hogy

Amellett, hogy a "közösségért" nem, hanem csak pénzért hajlandók valamit tenni, exploitokat adnak kiskölykök kezébe azzal, hogy ők egy "security közösség", még le is húznak havonta 6.66$-ral, hogy hozzáférhess egy halott fórumhoz, melyben csak egy halom nyilvánosan is elérhető anyagot, és elavult vagy nem működő szolgáltatásokat találsz.

A két domain jelenleg nem elérhető.

Nem rég indult egy új webes e-mail szolgáltatás StrongWebmail néven, amely kétlépcsős autentikációval és korai figyelmeztetésekkel igyekszik garantálni felhasználó biztonságát. A vállalkozás 10.000$-t ajánlott fel annak, aki képes az ügyvezető igazgató (szintén a rnedszerben regisztrált) e-mail fiókját feltörni, pontosabban a fiókhoz tartozó naptárba egy találkozó időpontot felvenni.

Ehhez ráadásul az igazgató felhasználóneve és jelszava is rendelkezésre állt, a problémát (legalábbis a készítők szándékai szerint) egy SMS-ben kiküldött, egyszer használatos PIN kód megszerzése jelentette volna.

Aviv Raff, Lance James és Mike Bailey azonban kicsit más irányból közelítették meg a problémát, és kamu bázisállomások építése, vagy a GSM szolgáltató rendszerének komprommitálása helyett egyszerűen egy speciálisan "megfogalmazott", XSS sebezhetőséget kihasználó levelet küldtek a CEO-nak. Az igazgató nyilatkozata szerint a bejegyzés a levél megnyitása után létre is jött, tehát a kutatók elvileg jogosultak a díjra, bár hivatalos állásfoglalás ezzel kapcsolatban a cég részéről egyelőre nem érkezett.

XSS sebezhetőségekkel tele van a web, az ilyen problémák annyira gyakoriak, hogy őszintén szólva már én sem szívesen fogalalkozom velük. Ez az eset ugyanakkor jól példázza, hogy egy támadás erejét sokszor nem a kihasznált biztonsági hiba minősége, hanem sokkal inkább a támadó által kellő gonddal összeállított körítés határozza meg.

A Remote-Exploit Keykeriki projektjének keretében egy Atmel ATmega 64 alapú, vezeték nélküli billenytűzetek lehallgatásához és a vett jelek dekódolásához használható eszközt bocsátott a széles nyilvánosság rendelkezésére. A készülék szoftver és hardver implementációjának részletei nyilvánosak, így megfelelő szaktudással és néhány ezer forint beruházással bárki építhet magának egyet.

A jelenlegi megvalósítás SD kártyahellyel és egy USART kimeneti interfésszel rendelkezik. Előbbi elsődleges tárolóként szolgál, utóbbihoz pedig a tervezők különböző csatoló egységeket kívánnak létrehozni, melyeken keresztül egy LCD kijelző, vagy akár egy iPhone-on futó alkalmazás is vezérelése is megoldható lenne. 

(jó ez a zene...)

A fentieken túl azt hiszem, érdemes még kitérnem a Keykeriki kriptoanalízis megoldására, amely a maga egyszerűségében nagyszerű. Az eszköz két megközelítést alkalmaz a drótnélküli billentyűzetek által nagyrészt használt, 1 byte-os XOR kulcs röptében való megfejtésére (természetesen offline bruteforce-ra is lehetőség van):

• Mivel a metakarakterek nem kerülnek titkosításra, feltételezhetjük, hogy a Shift-tel együtt bevitt karakter előtt egy szóköz áll (remélhetőleg nem javaProgramozókkalVanDolgunk()), ezért a megtippelt jelet a titkosítatlan szóközével összeXOR-olva remélhetőleg kiesik a kulcs.
• Három egyforma jel esetében a szoftver feltételezi, hogy a 'www' karaktersorozat került begépelésre. Az ellenőrzés a feltételezett kulcs kinyerése után a következő '.' karakter megfejtésével végezhető el.

További infókért látogassatok el a projekt oldalára és tekintségek meg a Keykerikiről szóló prezentációt is!

Korábban már írtam a hacker space-ekről, a legutóbbi Meetup pedig ismét aktuálissá tette a témát. A találkozón Stef, a Hackerspace Budapest képviselője beszélt a hacker terekről általában, és arról is, hogy az utóbbi időben szerencsére idehaza is fejlődésnek indultak ilyen kezdeményezések:

A nemzetközi HackerspaceWiki egyéként a HSPBP mellett a Nextlabot, valamint a KiBu-t tartja számon magyarországi hackerspace-ként, Stef pedig ezeken kívül még az AKKU-t hozta fel példaként. Látogassatok el hozzájuk, osszatok meg és alkossatok, erről szól a történet!

A hír már a magyar sajtóba is begyűrűzött, én is ejtek az esetről néhány szót:

A hitelkártya iparban biztonsági szakértőként tevékenykedő Trustwave munkatársai malware-rel fertőzött bankjegykiadó automatákat fedeztek fel, miközben ATM betörési eseteket vizsgáltak ki Oroszországban és Ukrajnában. A vállalat szerint körülbelül 20 olyan malware-rel fertőzött automatát fedeztek fel, amelyek az ügyfelek adataihoz, PIN-jéhez próbáltak hozzáférni.

A Trustwave által felfedezett fertőzött automaták mindegyike Windows XP-t futtatott. A malware telepítéshez a támadónak fizikai hozzáféréssel kellett rendelkeznie. A támadás nem egy, hanem több ATM gyártó termékei ellen irányul.

(trey@HUP)

A Trustwave jelentése szerint a malware az lsass.exe helyébe lépe veszi át az irányítást a fertőzött rendszer fölött, és egy megfelelő kártya behelyezése esetén interaktív felületet biztosít gazdái számára a megszerzett adatok lekérdezéséhez és más funkciókhoz, mint például a pénztároló kazetták kiadatása. A kártevő az általa gyűjtött adatokat az ATM nyomtatóján keresztül, vagy a behelyezett kártyát tárolóeszközként használva, DES-sel titkosítva képes kiadni. Az elemzésben ugyanakkor hangsúlyozzák, hogy valószínűleg egy korai verziójú szoftverről lehet szó, melynek funkcionalitását a közeljövőben jelentősen kiterjeszthetik.

Hétfőn az Apple kiadta a QuickTime médialejátszó 7.6.2-es változatát. Az új verzió számos illetéktelen kódfuttatásra alkalmas sebezhetőséget orvosol. További információkat a Zero Day Initiative és a Secunia oldalain találhattok.

Ezek mellett az iTunes is új verzióval jelentkezett, a Dev Team azonban óvatosságra int: bár a csapat szerint az új verzió nem tartalmaz direkt jailbreak-elleni megoldásokat, de néhány apróbb változtatás az USB driverben megakadályozza a QuickPwn, PwnageTool és az iPhone Tunneling Suite használatát, ezért a berhelt iPhone-nal rendelkezőknek az iPhone-ukat berhelni kivanoknak nem ajánlatos a frissítés.

Frissítés: Másrészről viszont a TippingPoint által kiadott értesítőben (valamint az iTunes changelogjában) arról olvashatunk, hogy az iTunes új verziója távolról kihasználható, kódfuttatásra alkalmas sebezhetőséget javít. A problémát egy, az alkalmazás által regisztrált itms: protokollkezelőben található stack overflow okozza. Mac-re való exploit itt található.

A Microsoft ma hajnali tanácslatában egy új, távoli kódfuttatásra alkalmas problémára figyelmeztet. A DirectShow platform quartz.dll-jében felfedezett sebezhetőség kihasználható pl. egy speciálisan összeállított, QuickTime tartalmat hordozó weboldalon keresztül is, amennyiben a böngészőben installálva van  a lejátszáshoz szükséges valamely plug-in (akár az Apple-féle is). A probléma a Windows Vista előtti változatait érinti, tehát az XP felhasználók még igen, az Vista és Server 2008 felhasználók már nincsenek veszélyben.

Az MSRC csapata legjobb ideiglenes megoldásként a quartz.dll használatának letiltását javasolja  a következő registry kulcs törlése segítségével:

HKEY_CLASSES_ROOT\CLSID\{D51BD5A0-7548-11CF-A520-0080C77EF58A}

IE felhasználók számára az alábbi killbit bevezetése lehet a legkényelmesebb megoldás:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{6BF52A52-394A-11D3-B153-00C04F79FAA6}] "Compatibility Flags"=dword:00000400

A támadási felületet ezen kívül csökkenti, ha nem adminisztrátorként netezünk (ugye-ugye...).

Az InformationWeek birtokába jutott információk szerint az év elején török támadók sikeres támadást mértek több, az Egyesült Államok hadseregének fennhatósága alá tartozó webkiszolgálóra. A feltehetően SQL injection technikával bevett hosztok látogatóit klímavédelmi üzeneteket tartalmazó weboldalakra irányították.

A magát m0sted-nek nevező egyik behatoló már korábban is szép számmal hajtott végre hasonló támadásokat nagyobb kaliberű intézmények ellen, akkor főként amerikaellenes nézeteinek hangozatása céljából. Ha az eszköz nem is, ebben az esetben legalább a cél békés volt.

Twitteren már írtam, hogy a feléledt HackersBlogon megjelent némi információ a brit Orange és O2 szolgáltatókat érintő SQL injection lehetőségekről. Nos, úgy tűnik valakinek sikerült elrontani a játékát, jött ugyanis egy levél a Full-Disclosure listára, melyben a szerző tisztességes mennyiségű anyázás közepette lehozta a szóban forgó hosztok teljes adatbázisstruktúráját, a támadást lehetővé tevő URL-ekkel együtt...

Az üzenet küldője, aki a "Whitehat Scum" nevet használja, egyébként nem ismeretlen a listán, pattogtassatok egy kis kukoricát, hátha a kiszivárgott adatok mellé kapunk még egy némi flamewart is!

Nosztalgia... Miután a híres L0pht hackercsapat tagjai által alapított @stake Inc-t bekebelezte a Symantec, a maga idejében méltán népszerű L0phtCrack "jelszóerősség-tesztelő" eszköz eltűnt a süllyesztőben. Most azonban a régi fejlesztők visszavásárolták a termékhez fűződő jogokat, és nekiálltak leporolni a régi programsorokat.

A most kiadott 6-os változat már támogatja a 64 bites, többmagos rendszereket, a szivárványtáblák, és a speciális karakterkészletek használtaát, valamint egy sor jelszómenedzsmentet segítő funkcióval is kiegészült. A L0phtCrack hosszabb élettörténetéről, és új funkcióiról az alább látható előadásból tájékozódhattok:

Bár azt hittem, a hasonló intézkedések már kimentek a divatból, a hivatalos weboldal szerint a szoftver az Egyesült Államok exportkorlátozásának hatálya alá esik, így pl. Európában sem használható. A nem-üzleti felhasználók ennek ellenére azt hiszem meg fogják oldani a dolgot.

A lengyelországi Telekommunikációs Intézet munkatársai egy, a szállítási protokollok hibavédelmi funkcióját hasznosító szteganográfiai eljárást dolgoztak ki nemrégiben. A módszer lényege, hogy egy újraküldést használó protokoll (tipikusan TCP) esetében a vevő direkt úgy tesz, mintha hibásan kapta volna meg valamelyik üzenetet, mire a küldő újraküldi az adatcsomagot, amibe ezúttal a rejteni átvinni kívánt üzenetet pakolja bele hasznos teherként.  

Amennyiben a direkt újraküldetett forgalom aránya nem tűnik ki lényegesen a valódi hibák által okozott újraküldésekéből, a rejtett kommunikációból adódó extra sávszélességigény nem tűnik fel a hálózat megfigyelőjének.

Ez persze nem fedi el, hogy mely két végpont kommunikál egymással, a kapcsolat nem lesz anonim. A megoldást az jelenti, ha a kommunikációban résztvevő valamelyik (vagy akár mindkét) fél a fedő csatorna valamelyik közbülső hálózati csomópontján üldögél, és a rajta keresztülfolyó adatfolyamba szúrja be a rejtett kereteket. Így akár egy ismeretlen felek között zajló TCP folyamba is beszúrható útközben némi rejtett adat.

Az azért piszkálja kicsit a fantáziámat, hogy mi van akkor, ha valaki direkt lehallgatja az álcázó csatornát, és megpróbálja összeállítani az azon szállított csomagokban található adatokat: Az újraküldött, elrejtendő információt tartalmazó csomagok tartalma nyilvánvalóan nem fog beleilleszkedni az álcázó adatfolyam struktúrájába, a lehallgató fél viszont úgy fog tekinteni ezekre, mintha egy elhibázott küldés javításai lennének, így tehát ezeket felhasználva fogja összeállítani az elfogott kommunikációt. Ekkor viszont azonnal láthatóvá válik, hogy az újraküldött csomagoknak köze sincs a kommunikáció többi részéhez, ami rögtön gyanút kelthet. Igazam van-e, vagy a fentiek kiküszöbölése nem is kell hogy célja legyen egy ilyen megoldásnak?

Nem rég írtam a Stefano Di Paola és Luca Carettoni áltla közelmúltban bemutatott HTTP Parameter Pollution módszerről, amely megpróbál kiemelkedni a mára már unalomig ismételt webes sérülékenységek hosszú sorából. Annak megítélésére, hogy ez a törekvés mennyire sikeres, eddig kevés információ állt rendelkezésre, most viszont a kutatók a szélesebb közönséggel is megosztották az egyik, Yahoo! Mail Classic szolgáltatásával kapcsolatban felvetődött probléma részleteit. A módszer hatékonyságát az alábbi videó szemlélteti:

De mi is történik itt pontosan?

A támadó ráveszi az áldozatot, hogy kattintson rá egy, a sebezhető rendszer által felkínált linkre. A linkben található egyik GET paramétert az alkalmazás a generált HTML oldalban is felhasználja, mégpedig egy másik link GET paramétereként, dekódolva. Így ebbe, az alkalmazás által generált linkbe egy támadó által meghatározott paraméter kerül. Ebben az esetben ez a paraméter arra utasítja a szolgáltatást, hogy törölje a felhasználó leveleit. A videón ezen kívül látható még egy csavar: a "szennyezésként" bevitt paraméterbe egy másik, duplán kódolt paramétert helyeztek, amely az első link aktiválása után kerül bele (érvényes, önálló paraméterként) az oldalba - ez a paraméter üríti a kukát, ahová előzőleg elvándoroltak a levelek - már ha a felhasználó erre a másik linkre is rákattint*.

A Yahoo! Mail Classic minden parancs esetében anti-CSRF módszereket használ, a fenti módszerrel azonban ezek sikeresen megkerülhetők (voltak, a problémát azóta javították). Hagyományos értelemben vett Cross-Site Scriptingről azért nem beszélhetünk nyugodt szívvel, mert nem kerültek elhelyezésre új HTML vagy JavaScript elemek az oldalon, csupán egy-egy link bizonyos része egészült ki, és az alkalmazás a saját, legitim parancskészelét használtuk, melyek szerveroldalon futottak le. Emiatt a hagyományos XSS-védelmi megoldások is haszontalanokká válnak az ilyen trükkökkel szemben.

Ezek fényében még mindig nehezen tudnám megmondani, hogy hogyan is lenne érdemes értékelnünk a HPP-t. Az ilyen jellegű problémák kihasználhatósága jól láthatóan nagyrészt az implementációtól, annak is sokszor a legapróbb elemeitől függ, így nehéz olyan definiciót találni, amely alapján álalánosságban következtethetnénk a probléma súlyosságára. A napi böngészések során mindazonáltal jónéhány potenciálisan szennyezhető oldallal hoz össze a sors, a tapasztalatszerzésre így legalább megvan a lehetőség...

* Vajon az első műveletett miért nem lehetett elvégezni rögtön a levélben küldött linkkel?

A Secunia kutatói helyi és távoli kódfuttatásra alkalmas sebezhetőségeket fedeztek fel a Sun Solaris 8-as és 9-es (x86 és SPARC) verzióinak Solstice AdminSuite programcsomagjához tartozó sadmind démonban. A heap és integer overflow-t eredményező problémák kihasználásához speciális RPC üzenetekre van szükség, melyeket bármely, a helyi hálózaton tartózkodó, vagy az érintett rendszerbe bejelentkezett felhasználó elküldhet.  A Sun pénteken kiadta a javításokat.

Az US-CERT szerint már aktívan kihasználják a nem rég felfedezett, IIS 5-ös és 6-os szervereket érintő, autentikáció-megkerülésre alkalmas sebezhetőséget, hivatalos javítás pedig még nincs, az izgalom tehát a tetőfokára hágott. A kedélyek megnyugtatása végett álljon itt egy kis vegyesfelvágott a témában megjelent, hivatalos és nem hivatalos forrásokból származó publikációkból:

Érintett-e vagyok?

A Microsoft SRD blogja szerint azok a kiszolgálók érintettek, amelyek

• IIS 5.0, 5.1 vagy 6.0 verziókat futtatnak
• ÉS van olyan könyvtáruk, amelyet az IIS jogosultságkezelő rendszere védi
• ÉS fájlrendszer szinten engedélyezve van a védett tartalomhoz történő hozzáférés az IUSR_[MasinaNeve] fiók számára
• ÉS a védett könyvtár szülőkönyvtárához bárki hozzáférhet

Aki nem szeretné ezeket a kérdéseket minden általa karbantartott gép esetében végiggondolni, annak itt van ez az aranyos kis nmap szkript, amely távolról képes kiszimatolni a sebezhetőséget. A dolog apró szépséghibája, hogy a programocska alapesetben egy szótáron mászik végig, hogy megfelelő könyvtárat találjon a támadáshoz, így nem biztos hogy valóban megtalál minden érintett útvonalat.

És mi van ha igen?

Egy videó többet mond ezer szónál:

Rangos bemutatójában jól látható, hogy a jogosulatlan fájlhozzáférésen kívül megfelelő(en ritka) konfigurációk esetében távoli kódfuttatás is elképzelhető - mindkét esetet jó elkerülni.

Hogyan védhetem meg magam?

Kerülőutak használatával:

• Kapcsold ki a WebDAV-ot (a videón jól látszik hogy ezt hogyan is kell)!
• Korlátozd a IUSR_[GépNév] fiók hozzáférését a védett könyvtárakhoz fájlrendszer szinten!
• Használd a Microsoft URLScanjét, vagy más IDS/IPS rendszert! A "Translate: f" kifejezésre állítólag elég hatékony szűréseket lehet beállítani.

Linkek

• Microsoft Security Research and Defense - Legfontosabb infók első kézből
• Microsoft Security Research and Defense - GYIK
• Thierry Zoller még részletesebb összefoglalója

Most kivételesen nem egy újabb Twitter törésről vagyok kénytelen beszámolni, hanem arról, hogy én is elkezdtem használni ezt a remek szolgáltatást. Ha minden igaz, oldalt már a Google Reader helyett a Twitter által generált mikro-posztokat olvashatjáktok, de hála a TwitterFeed-nek, nem kell lemondanotok a már megszokott Reader-es hírfolyamról sem.

A váltást elsősorban az indokolta, hogy így meg tudok osztani olyan helyről származó híreket is, amelyek hírcsatornáira egyébként nem vagyok feliratkozva. Másrészt a Blog.hu-val ellentétben a Twitteres fejlesztők már rájöttek, hogy az SSL nem egy fölösleges hülyeség, így tehát akkor is nyugodt lelkiismerettel tudok (apróbbakat) posztolni, mikor megbízhatatlan hálózati hozzáférés áll csak rendelkezésre.

 sct küldte az alábbi képernyőképet:

A YouTube blogja még mindig így néz ki, ha valaki tud kínaiul(?), az felvilágosíthatna hogy miről szól a szöveg... A belinkelt viedón egy gördeszkázó kutya látható egyébként.

 trey@HUP:

Landon Fuller arról vált szélesebb körben is ismertté, hogy megpróbált minél hamarabb patch-eket készíteni 2007. januárjában a Month of Apple Bugs figyelmeztetőkben publikált hibákra. A biztonsági szakember most arról ír blogjában, hogy öt hónappal ezelőtt a CVE-2008-5353 hibajegyben leírt és más sebezhetőségeket közölt publikusan és javított ki a Sun Microsystems.

A CVE-2008-5353 figyelmeztetőben leírt sebezhetőség lehetővé teszi a rosszindulatú kód számára, hogy az kitörjön a Java sandbox-ból és tetszőleges parancsokat futtasson az éppen aktuális felhasználó nevében. Ez azt eredményezi, hogy nem megbízható Java applet-ek tetszőleges kódot futtathatnak pusztán azáltal, hogy az érintett rendszerrel rendelkező felhasználó meglátogatja az applet-et hostoló weboldalt.

A szakember szerint ezek a sebezhetőségek azóta is jelen vannak az Apple által szállított JVM-ekben és a Soylatte-ben (Java 6 port Mac OS X 10.4 és 10.5 (Intel) rendszerekhez) 1.0.3-as verziójában is.

Mivel a Soylatte nem kínál böngésző plugint, használata esetén a sebezhetőségből fakadó fenyegetettség kisebb. Az OpenJDK6/Mac OS X legújabb kiadását nem érinti a CVE-2008-5353-ban leírt sebezhetőség.

Landon - hogy bemutassa a hibát - egy proof-of-concept bemutatót készített. Ha az érintett rendszerrel rendelkező felhasználó meglátogatja ezt a weboldalt, akkor a /usr/bin/say fog végrehajtódni a rendszerén a felhasználó saját jogosultságaival.

A szakember több workaround-ot is javasol a hiba orvoslásáig:

• Mac OS X users should disable Java applets in their browsers and disable 'Open "safe" files after downloading' in Safari.

• Soylatte users running untrusted code should upgrade to an OpenJDK6-based release, where possible. No future releases of the JRL-based Soylatte branch are planned at this time. If this is an issue for you, please feel free to contact me.

• No work-around is available for users otherwise running Java untrusted code.

A részletek itt, itt.

PoC exploit erre

A rajongóknak és az örök szkeptikusoknak is fel szeretném hívni a figyelmét a megújult hacktivity.hu-ra, ami jól előrevetíti, hogy az idei buli kicsit más lesz mint az eddigiek. A tartalom még kevés, de legalább már van rendes portálmotor meg RSS, így bárki könnyedén nyomonkövetheti a konferenciával kapcsolatos híreket, eseményeket. A fórum már működik, el lehet kezdeni aktivizálódni!

Stefano Di Paola és Luca Carettoni egy érdekes koncepciót mutattak be nem rég Lenygelországban lezajlott OWASP EU09 konferencián. A HTTP Parameter Pollution-nek keresztelt technika lényegében azt használja ki, hogy a manapság elterjedt webes technológák és maguk a webkiszolgálók is igen eltérő módon kezelik a többszörösen definiált HTTP paramétereket, "a szokatlan viselkedés pedig a biztonsági gyengeségek megszokott forrása". Egy Apache kiszolgálón futó PHP szkript például mindig egy paraméter utoljára definiált értékét tekinti mérvadónak, míg egy IIS-en futó ASP.NET program összefűzi az azonos névvel illetett paramétereket. Mindez pedig a nem megfelelő bemenetellenőrzésekkel összeházasítva figyelemre méltó kombinációt alkothat.

Hogy mire is lehet jó a HPP:

Az alkalmazás-rétegbeli tűzfalak (pl. PHPIDS, Mod_Security) megkerülése viszonylag egyszerűen adódik, de - kellően ügyetlen megvalósítás esetén - a módszer segítségével akár egy webalkalmazás védett, "bedrótozott" változóihoz is hozzáférhetünk. Ez utóbbira a Google Search Appliance megoldásával kapcsolatban mutattak példát a kutók, a Yahoo! levelező szolgáltatásával  kapcsolatban pedig a CSRF védelmet sikerült ilyen módon kijátszani.

Sajnos részletes információk a fenti támadásokról még nem érhetők el, de úgy tűnik, hogy ígéretes lehetőségek rejlenek ezekben a technikákban. Meg kell ugyanakkor jegyezni, hogy a jelek szerint, egy sikeress "szennyezés" kivitelezéséhez legtöbbször a célalkalmazás és a platform mélyreható ismerete szükséges, ami egyrészt kiadós agytornákat helyez kilátásba, másrészt várhatóan valamelyest visszafogja majd az ilyen módszert alkalmazó támadásokat.  Ezen kívül ismét fontosnak tartom hangsúlyozni, hogy jól láthatóan ebben az esetben sem a Szent Grál megkaparintásáról van szó, a HPP is csak meggondolatlan programozói megoldásokból tud táplálkozni. Más kérdés, hogy hány kódernek lesz kedve és lehetősége végiggondolni, hogy - az adott esetben platformfüggetlenre tervezett - programsorok, hogyan fognak reagálni az egyes protokollrétegek által összekuszált, kódolt és dekódolt paraméterekre a rendelkezésre álló platformok széles skáláján.

Puffer túlcsordulást eredményező sebezhetőséget találtak a népszerű időszinkronizációs kiszolgálóban, az ntpd-ben. A probléma a démon jogkörével történő kódfuttatást tehet lehetővé. Az ebből fakadó kellemetlenségek elkerülése érdekében kérjük frissítsenek az ntpd 4.2.4p7 ill. 4.2.4p74 változataira! Köszönjük! 

via H-Security

RobbeR továbbította a dataglobe.eu közérdekű közleményét:

Kedves XY,
Sajnálatos módon 2009.05.17-én 4:30 perc körül, hajnalban hackertámadás érte azt a szerverünket, amelyen az Ön tárhelye is van. A támadás során az oldalakhoz tartozó index.html, index.htm, index.php, állományokat módosította a hacker. A többi fájl módosítás nélkül szerepel a tárhelyen.

[...] 

A mai nap délutánján több beállítást is módosítottunk annak érdekében, hogy többször ne fordulhasson elő ilyen támadás, ennek a beállítása több kimaradást okozott az oldalak elérhetőségében.
Elnézést kérünk a kellemetlenségért!

Hányszor láttunk példát arra az esetre, mikor a kezdő kocsmatöltelék, miután cimborája már szupermen pózba szenderedett, kettőjük félsöréből egy hirtelen mozdulattal igyekszik egy egyészet gyártani, nem számolva a hirtelen habzás kockázatával... És hányszor láttunk már olyat, hogy a szeleburdi programozó nagyobb adag bitet próbál betuszkolni a memóra egyik szegletébe, mint ami odaférne!

A Microsoft úgy döntött, hogy (saját termékeit tekintve legalábbis) leszámol az utóbb említett káros gyakorlattal, és tiltólistára teszi a memcpy(), CopyMemory() és RtlCopyMemory() függvényeket, helyettük pedig a memcpy_s() használatát írja elő, melynél már megadható a kimeneti puffer mérete. Nem ez az első lépés Redmond részéről a potenciálisan veszélyes rutinok kiküszöbölésére, példának okáért az strcpy() és az strcat() függvények is már rég feketelistán vannak. 

Persze a fenti eljárások helytelen használata nem csak az MS-programozók sajátja, és természetesen a tiltás sem egy csodaszer. Teljesen biztonságos kódok talán akkor születnének, ha a nop utasításon kívül semmi mást nem használhatnánk. Reméljük viszont, hogy ez a lépés talán felhívja a figyelmet egyes hőskorban született eljárások veszélyeire, valamint bízzunk abban is, hogy ezt elősegítendő,  a memcpy_s a közeljövőben a GCC csomagba is be fog kerülni.

Kingcope, alias Nikolaos Rangos olyan problémát fedezett fel a Microsoft Internet Information Services 6-os verziójában, amely lehetővé teszi, hogy hozzáférjünk bármely fájlhoz, amelyet WebDAV autentikációt használó védett könyvtárakban tárolnak, valamint elméletileg fel is tölthetünk fájlokat ezekre a helyekre.

A hiba nosztalgikus emlékeket idéz meg a Unicode szabvány elterjedése körüli időkről, különösen ezzekkel a sok galibát okozó, 2000-es és 2001-es IIS5 problémákkal mutat kísérteties hasonlóságot. A problémát most is az okozza, hogy a webkiszolgáló előbb végzi el a jogosultságellenőrzést, mint a karakterkonverziót, így a %c0%af unicode karakter (szebbik formájában '/') használatával a szerver ellenőrzési rutinjai egyszerűen megkerülhetők.

Fontos megemlíteni, hogy a jelek szerint az IIS7 nem éritnett, valamint a WebDAV autentikáció sincs bekapcsolva alapból a 6-os verziókon. Kingcope jelentését megtekinthetitek itt.

Kicsit átszervezték a programomat, így mégis lett új poszt, de sajnos jön még kutyára úthenger...

Szerencsére nem sűrűn fordul elő, hogy a blog prioritási szintje a napi elfoglaltságok küszöbszintje alá süllyed, de talán ti is észrevettétek, hogy az utóbbi pár napban nem tudtam hozni a napi megszokott posztadagot. Még nagyjából 18 órám van hátra az egyéb hajtásokból, ez alatt szinte biztos hogy nem fog új poszt születni, az ezután következő levezető tréningre (aka. kocsmatúra) tekintettel pedig még nagyjából vasárnap estig nem leszek túl aktív. Ezúton is kérem szíves elnézéseteket! Az oldalt látható megosztott feedeket viszont érdemes ezalatt az idő alatt is figyelemmel kísérni!