Most egy másik módot próbálunk ki az SQL beillesztésére. Nézzük meg, hogy az adatbázis folyamatosan dob-e hibaüzeneteket. Ezt a módszert "várakozás késleltetésre" nevezzük, maga a késleltetés pedig a következőképpen írható: waitfor delay 00:00:01'. Ezt kimásolom a fájlunkból, és beillesztem a böngészőm címsorába.
Mindezt "ideiglenes vak SQL injekciónak" nevezik. Itt csak annyit csinálunk, hogy "várjon 10 másodpercet". Ha észreveszi, a bal felső sarokban van a "connecting ..." felirat, vagyis mit csinál az oldalunk? Megvárja a csatlakozást, és 10 másodperc múlva a megfelelő oldal jelenik meg a monitoron. Ezzel a trükkel megkérjük az adatbázist, hogy tegyen fel még néhány kérdést, például ha Joe a felhasználó, akkor várnunk kell 10 másodpercet. Ez egyértelmű? Ha a felhasználó dbo, akkor is várjon 10 másodpercet. Ez a Blind SQL Injection módszer.
Úgy gondolom, hogy a fejlesztők nem javítják ki ezt a biztonsági rést a javítások létrehozásakor. Ez SQL injekció, de az IDS programunk sem látja, mint a korábbi SQL injekciós módszerek.
Próbáljunk ki valami érdekesebbet. Másolja ki ezt a sort az IP-címmel, és illessze be a böngészőbe. Működött! Programunkban a TCP sáv pirosra vált, a program 2 biztonsági fenyegetést észlelt.
Oké, lássuk, mi történt ezután. Egy fenyegetésünk van az XP rendszerhéjra, a másik pedig egy SQL-befecskendezési kísérlet. Összesen két kísérlet történt a webalkalmazás megtámadására.
Oké, most segíts a logikában. Van egy manipulációs adatcsomagunk, amelyben az IDS azt mondja, hogy reagált a különféle XP shell manipulációkra.
Ha lefelé megyünk, egy HEX kódok táblázatát látjuk, amitől jobbra van egy zászló xp_cmdshell + &27ping üzenettel, és ez nyilván rossz.
Lássuk, mi történt itt. Mit csinált az SQL Server?
Az SQL szerver azt mondta, hogy "megkaphatod az adatbázis jelszavamat, megkaphatod az összes adatbázis rekordomat, de haver, egyáltalán nem akarom, hogy rajtam futtasd a parancsaidat, ez egyáltalán nem jó"!
Amit tennünk kell, az az, hogy még ha az IDS fenyegetést jelent is az XP rendszerhéjnak, a fenyegetés figyelmen kívül marad. Ha SQL Server 2005-öt vagy SQL Server 2008-at használ, ha a rendszer SQL-befecskendezési kísérletet észlel, az operációs rendszer héja zárolva lesz, ami megakadályozza a munka folytatását. Nagyon bosszantó. Szóval mit tegyünk? Meg kell próbálnia nagyon szeretetteljesen megkérdezni a kiszolgálót. Mondjak valami olyasmit, hogy „kérlek, apa, kaphatom ezeket a sütiket”? Én ezt teszem, komolyan, nagyon udvariasan kérdezem a felszolgálót! Kérek további lehetőségeket, kérek egy újrakonfigurálást, és kérem az XP shell beállítások módosítását, hogy elérhető legyen a shell, mert szükségem van rá!
Úgy látjuk, hogy az IDS ezt észlelte – itt már 3 fenyegetést észleltek.
Csak nézzen ide – felrobbantottuk a biztonsági naplókat! Úgy néz ki, mint egy karácsonyfa, sok minden van itt felakasztva! Akár 27 biztonsági fenyegetés! Hurrá srácok, elkaptuk ezt a hackert, elkaptuk!
Nem attól tartunk, hogy ellopja az adatainkat, de ha a "dobozunkban" rendszerparancsokat tud végrehajtani - az már komoly! Megrajzolhatod a Telnet útvonalat, FTP-t, átveheted az adataimat, ez jó, de én emiatt nem aggódom, csak nem szeretném, ha átvennéd a "dobozom" héját.
Olyan dolgokról szeretnék beszélni, amelyek igazán megfogtak. Dolgozom szervezeteknek, évek óta dolgozom nekik, és ezt azért mondom el, mert a barátnőm azt hiszi, hogy munkanélküli vagyok. Azt hiszi, én csak a színpadon állok és dumálok, ez nem tekinthető munkának. De én azt mondom: „nem, örömöm, tanácsadó vagyok”! Ez a különbség – kimondom a véleményemet, és pénzt kapok érte.
Hadd fogalmazzam meg: mi hackerek szeretjük feltörni a héjat, és számunkra nincs nagyobb öröm a világon, mint "lenyelni a héjat". Amikor az IDS elemzői megírják a szabályaikat, láthatja, hogy úgy írják őket, hogy védjék a shell-hackelést. De ha beszél a CIO-val az adatok kinyerésének problémájáról, felajánlja, hogy gondolkodjon el két lehetőségen. Tegyük fel, hogy van egy alkalmazásom, ami óránként 100 "darabot" készít. Mi a fontosabb számomra - az összes adat biztonságának biztosítása ebben az alkalmazásban vagy a "doboz" shell biztonsága? Ez egy komoly kérdés! Mitől kellene jobban aggódnia?
Csak azért, mert elromlott a "doboz" shell, nem feltétlenül jelenti azt, hogy valaki hozzáfért az alkalmazások belső működéséhez. Igen, több mint valószínű, és ha még nem történt meg, hamarosan megtörténhet. De vegye figyelembe, hogy sok biztonsági termék arra a feltevésre épül, hogy egy támadó barangol a hálózaton. Tehát odafigyelnek a parancsok végrehajtására, a parancsok befecskendezésére, és meg kell jegyezni, hogy ez komoly dolog. Felhívják a figyelmet a triviális sebezhetőségekre, nagyon egyszerű cross-site scriptelésre, nagyon egyszerű SQL-injekciókra. Nem törődnek az összetett fenyegetésekkel, nem törődnek a titkosított üzenetekkel, nem törődnek az ilyesmivel. Elmondható, hogy minden biztonsági termék a zajt keresi, a "nyafogást" keresi, meg akar állítani valamit, ami a bokáját harapja. Íme, mit tanultam a biztonsági termékekkel kapcsolatban. Nem kell biztonsági termékeket vásárolnia, nem kell hátramenetben vezetnie a teherautót. Hozzáértő, képzett emberekre van szüksége, akik értik a technológiát. Igen, istenem, emberek! Nem akarunk dollármilliókat költeni ezekre a problémákra, de sokan közületek dolgoztak ezen a területen, és tudják, hogy amint a főnöke meglát egy hirdetést, a boltba szalad, és azt kiabálja, hogy "meg kell szereznünk ezt a dolgot!". De igazából nincs is rá szükségünk, csak helyre kell hozni azt a rendetlenséget, ami mögöttünk van. Ez volt ennek az előadásnak az előfeltétele.
A magas szintű biztonsági környezet olyan dolog, amellyel sok időt töltöttem, hogy megértsem a védelmi mechanizmusok működésének szabályait. Miután megértette a védelmi mechanizmusokat, a védelem megkerülése nem nehéz. Például van egy webalkalmazásom, amelyet saját tűzfal véd. Kimásolom a beállítások panel címét, beillesztem a böngésző címsorába, majd belépek a beállításokba, és megpróbálom alkalmazni a cross-site scripting-et.
Ennek eredményeként tűzfal üzenetet kapok egy fenyegetésről – letiltottak.
Szerintem rossz, egyetértesz? Biztonsági termékkel áll szemben. De mi van, ha valami ilyesmivel próbálkozom: a Joe'+OR+1='1 paramétert tedd a stringbe
Mint látható, működött. Javítsatok ki, ha tévedek, de láttuk, hogy az SQL injekció legyőzte az alkalmazás tűzfalát. Most pedig tegyünk úgy, mintha biztonsági céget akarnánk alapítani, ezért vegyük fel a szoftvergyártó kalapját. Most a gonoszt testesítjük meg, mert ez egy fekete kalap. Tanácsadó vagyok, így ezt szoftvergyártókkal is meg tudom csinálni.
Új behatolásészlelő rendszert szeretnénk építeni és telepíteni, ezért szabotázsfelderítési kampányt indítunk. A Snort nyílt forráskódú termékként több százezer behatolási fenyegetés aláírását tartalmazza. Etikusan kell eljárnunk, így nem fogjuk ellopni ezeket az aláírásokat más alkalmazásoktól, és beilleszteni őket a rendszerünkbe. Csak leülünk, és átírjuk őket – hé, Bob, Tim, Joe, gyertek ide, és gyorsan fussátok át azt a 100 000 aláírást!
Létre kell hoznunk egy sebezhetőség-ellenőrzőt is. Tudja, hogy a Nessus, az automatikus sebezhetőség-kereső jó 80 XNUMX aláírással és szkripttel rendelkezik, amelyek ellenőrzik a sebezhetőségeket. Ismét etikusan járunk el, és személyesen írjuk át mindet programunkban.
Az emberek azt kérdezik tőlem: "Joe, ezeket a teszteket nyílt forráskódú szoftverekkel, például Mod Security, Snort és hasonlók segítségével végzi, mennyire hasonlítanak más gyártók termékeihez?" Azt válaszolom nekik: „Egyáltalán nem hasonlítanak egymásra!” Mivel a gyártók nem lopnak el dolgokat nyílt forráskódú biztonsági termékekből, leülnek és maguk írják le ezeket a szabályokat.
Ha saját aláírásait és támadási karakterláncait nyílt forráskódú termékek használata nélkül is működőképessé teheti, ez egy nagyszerű lehetőség az Ön számára. Ha nem tud versenyezni a kereskedelmi termékekkel, jó irányba halad, meg kell találnia egy olyan koncepciót, amely segít ismertté válni a szakterületén.
Mindenki tudja, hogy iszom. Hadd mutassam meg, miért iszom. Ha csináltál már valaha életedben forráskód auditot, biztosan berúgsz, hidd el, utána kezdesz inni.
Tehát a kedvenc nyelvünk a C++. Vessünk egy pillantást erre a programra – a Web Knight egy tűzfalalkalmazás webszerverekhez. Alapértelmezett kivételei vannak. Érdekes – ha telepítem ezt a tűzfalat, nem véd meg az Outlook Web Accesstől.
Csodálatos! Ennek az az oka, hogy sok szoftvergyártó szabályokat húz ki egyes alkalmazásokból, és anélkül helyezi be a termékébe, hogy egy csomó megfelelő kutatást végezne. Tehát amikor egy hálózati tűzfalalkalmazást telepítek, úgy gondolom, hogy a webmailt illetően mindent rosszul csinálnak! Mert szinte minden webmail sérti az alapértelmezett biztonságot. Olyan webkóddal rendelkezik, amely végrehajtja a rendszerparancsokat és lekérdezi az LDAP-t vagy bármely más felhasználói adatbázis-tárat közvetlenül az interneten.
Mondd, melyik bolygón tekinthető biztonságosnak az ilyesmi? Gondolj csak bele: megnyitod az Outlook Web Accesst, megnyomod a b ctrl+K billentyűkombinációt, megkeresed a felhasználókat és minden más, az Active Directoryt közvetlenül az internetről kezeled, rendszerparancsokat hajtasz végre Linuxon, ha "squirrel mail" vagy Horde vagy bármi mást használsz. valami más. Kivonja az összes eval-t és más típusú nem biztonságos funkciókat. Ezért sok tűzfal kizárja őket a biztonsági fenyegetések listájáról, kérdezze meg a szoftver gyártóját erről.
Térjünk vissza a Web Knight alkalmazáshoz. Sok biztonsági szabályt ellopott egy URL-szkennertől, amely az összes IP-címtartományt ellenőrzi. És mi van, mindezek a címtartományok ki vannak zárva a termékemből?
Szeretné valamelyikőtök telepíteni ezeket a címeket a hálózatára? Szeretné, hogy a hálózata ezeken a címeken működjön? Igen, elképesztő. Rendben, görgessük le ezt a programot, és nézzünk meg más dolgokat, amelyeket ez a tűzfal nem akar megtenni.
„1999”-nek hívják őket, és azt akarják, hogy webszerverük a múltban legyen! Emlékszik közületek valaki erre a baromságra: /scripts, /iishelp, msads? Talán páran nosztalgiával emlékeznek majd rá, milyen jó móka volt ilyen dolgokat feltörni. „Ne feledje, ember, milyen régen „öltünk meg” szervereket, király volt!”.
Ha megnézi ezeket a kivételeket, látni fogja, hogy megteheti ezeket a dolgokat – msads, nyomtatók, iisadmpwd – mindezt, amire ma senkinek nincs szüksége. Mi a helyzet azokkal a parancsokkal, amelyeket nem hajthat végre?
Ezek a következők: arp, at, cacls, chkdsk, cipher, cmd, com. Felsorolásukkor elárasztanak a régi idők emlékei, „haver, emlékszel, hogyan vettük át azt a szervert, emlékszel azokra az időkre”?
De itt van az igazán érdekes – látja valaki a WMIC-et vagy esetleg a PowerShellt? Képzeld el, hogy van egy új alkalmazásod, amely úgy működik, hogy parancsfájlokat futtat a helyi rendszeren, és ezek modern szkriptek, mert Windows Server 2008-at akarsz futtatni, és én nagyszerű munkát fogok végezni annak védelmében a Windowsra tervezett szabályokkal. 2000. Annak érdekében, hogy a következő alkalommal, amikor egy eladó megérkezik Önhöz a webalkalmazásával, kérdezze meg tőle: „Hé, haver, biztosítottál olyan dolgokat, mint a bits admin vagy a powershell parancsok végrehajtása, ellenőrizted az összes többi dolgot, mert megyünk frissíteni és használni a DotNET új verzióját"? De ezeknek a dolgoknak alapértelmezés szerint jelen kell lenniük a biztonsági termékben!
A következő dolog, amiről beszélni szeretnék önnel, az a logikai tévedések. Menjünk a 192.168.2.6-ra. Ez körülbelül ugyanaz az alkalmazás, mint az előző.
Ha lejjebb görgeti az oldalt, és rákattint a Kapcsolat linkre, akkor valami érdekeset észlelhet.
Ha megnézi a "Kapcsolatfelvétel" lap forráskódját, amely az egyik állandó tesztelési módszer, akkor észreveszi ezt a sort.
Gondold át! Hallom, hogy ennek láttán sokan azt mondták: "Wow!" Egyszer penetrációs tesztet végeztem mondjuk egy milliárdos banknál, és ott valami hasonlót vettem észre. Tehát nincs szükségünk SQL-befecskendezésre vagy webhelyek közötti szkriptekre – megvan a legfontosabb, ez a címsor.
Tehát túlzás nélkül - a bank azt közölte, hogy mindkettőjük van - és egy hálózati szakember, és egy webellenőr, és nem tettek észrevételt. Vagyis normálisnak tartották, hogy egy szöveges fájl böngészőn keresztül megnyitható és olvasható.
Ez azt jelenti, hogy a fájlt közvetlenül a fájlrendszerből olvashatja. A biztonsági csapatuk vezetője azt mondta nekem: „igen, az egyik szkenner megtalálta ezt a sebezhetőséget, de kisebbnek tartotta.” Mire azt válaszoltam, oké, adj egy percet. A címsorba beírtam a filename=../../../../boot.ini, és el tudtam olvasni a fájlrendszer indítófájlját!
Erre azt mondták: „nem, nem, nem, ezek nem kritikus fájlok”! Azt válaszoltam – de ez a Server 2008, nem? Azt mondták, igen, ő az. Mondom – de ennek a szervernek van egy konfigurációs fájlja a kiszolgáló gyökérkönyvtárában, igaz? – Helyes – válaszolják. „Remek” – mondom –, mi van, ha a támadó ezt teszi, és beírom a címsorba a filename=web.config. Azt mondják - mi van, nem látsz semmit a monitoron?
Azt mondom - mi van, ha jobb gombbal kattintok a monitorra, és kiválasztom az "Oldalkód megjelenítése" opciót? És mit találok itt? "Semmi kritikus"? Látni fogom a szerver rendszergazdai jelszót!
És azt mondod, nincs itt semmi probléma?
De a kedvenc részem a következő. Nem engedi, hogy parancsokat futtassak a dobozban, de ellophatom a webszerver rendszergazdai jelszavát és adatbázisát, megnézhetem a teljes adatbázist, kiszedhetem az összes adatbázis- és rendszerhiba-cuccot, és elsétálhatok vele. Ez az az eset, amikor a rosszfiú azt mondja, hogy "hé ember, ez egy nagyszerű nap"!
Ne hagyd, hogy a biztonsági termékek betegségeddé váljanak! Ne hagyja, hogy a biztonsági termékek megbetegedjenek! Keress néhány bohócot, add át nekik a Star Trek-emlékeket, keltsd fel érdeklődésüket, bátorítsd őket, hogy maradjanak veled, mert azok a majom büdösek, akik nem zuhanyoznak naponta, az alábbiak szerint működnek a hálózatod! Ők azok, akik segítenek a biztonsági termékek megfelelő működésében.
Mondjátok meg, hányan tudtok huzamosabb ideig egy szobában maradni egy olyan személlyel, aki folyton azt mondja: "Ó, sürgősen ki kell nyomtatnom ezt a forgatókönyvet!", És ki van ezzel elfoglalva állandóan? De olyan emberekre van szükséged, akik működésre késztetik a biztonsági termékeidet.
Ismétlem, a biztonsági termékek buták, mert a lámpák mindig rosszak, állandóan szar dolgokat csinálnak, egyszerűen nem nyújtanak biztonságot. Soha nem láttam még olyan jó biztonsági terméket, amihez ne kellene egy csavarhúzós fickó megcsípni, ahol kell, hogy többé-kevésbé normálisan működjön. Ez csak egy hatalmas szabálylista, amely szerint ez rossz, és ennyi!
Szóval srácok, szeretném, ha figyelnétek az oktatásra, olyan dolgokra, mint a biztonság, a politechnika, mert sok ingyenes online kurzus létezik a biztonsági kérdésekről. Tanuljon Pythont, tanulja meg az Assemblyt, tanulja meg a webalkalmazások tesztelését.
Íme, mi segít igazán biztonságossá tenni hálózatát. Az okos emberek védik a hálózatokat, a hálózati termékek nem védenek! Menj vissza dolgozni, és mondd meg a főnöködnek, hogy több költségvetésre van szükséged több okos ember számára. Tudom, hogy most válság van, de mindenesetre mondd meg neki, hogy több pénzre van szükségünk az oktatáshoz. Ha megveszünk egy terméket, de nem veszünk tanfolyamot a használatáról, mert drága, akkor miért vesszük meg egyáltalán, ha nem tanítjuk meg az embereket a használatára?
Rengeteg biztonsági termékgyártónál dolgoztam, szinte egész életemet ezeknek a termékeknek a bevezetésével töltöttem, és kezd elegem lenni ezekből a hálózati hozzáférés-szabályozásokból és egyebekből, mert telepítettem és futtattam ezeket a szar termékeket. Egyik nap elmentem egy klienshez, a 802.1x szabványt akarták implementálni az EAP protokollhoz, így minden porthoz volt MAC címük és másodlagos címük. Jöttem, láttam, hogy rossz, megfordultam, és nyomkodni kezdtem a nyomtató gombjait. Tudja, a nyomtató képes kinyomtatni a hálózati berendezés tesztoldalát az összes MAC- és IP-címmel. De kiderült, hogy a nyomtató nem támogatja a 802.1x szabványt, ezért ki kell zárni.
Ezután kihúztam a nyomtatót és megváltoztattam a laptopom MAC címét a nyomtató MAC címére és csatlakoztattam a laptopomat, ezzel megkerülve ezt a drága MAC megoldást, gondolj bele! Tehát mit tud nekem segíteni ez a MAC-megoldás, ha az ember bármilyen berendezést egyszerűen nyomtatónak vagy VoIP-telefonnak adhat ki?
Tehát ma számomra a pentesztelés azt jelenti, hogy időt töltök azzal, hogy megértsek és megértsek egy olyan biztonsági terméket, amelyet ügyfelem vásárolt. Most már minden banknál, ahol penetrációs tesztet végzek, megvan ez a sok HIPS, NIPS, LAUGTHS, MACS és egy csomó más mozaikszó, ami egyszerűen szívás. De megpróbálom kitalálni, hogy ezek a termékek mit és hogyan próbálnak elérni. Aztán ha rájövök, hogy milyen módszertannal és logikával biztosítanak védelmet, egyáltalán nem lesz nehéz megkerülni.
A kedvenc termékem, amelyet meghagyok, az MS 1103. Ez egy böngésző alapú exploit, amely HIPS-t, Host Intrusion Prevention Signature vagy Host Intrusion Prevention Signature-t szór. Valójában a HIPS aláírások megkerülésére szolgál. Nem szeretném bemutatni, hogyan működik, mert nem akarok időt szánni a bemutatására, de nagyszerűen megkerüli ezt a védelmet, és szeretném, ha elfogadná.
Rendben srácok, most elmegyek.
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com