|
Fontos információ: az Ördöglakaton kivitelezhető támadások nem jöhettek volna létre, ha
a weblap készítői komoly mérnöki munkával meg nem oldják, hogy az IIS6 olyasmit csináljon, amire
biztonsági okokból nem hajlandó: a CMD.EXE szerveroldali futtatása egyáltalán nem volt triviális feladat!
A lyukak mesterségesek, emiatt a támadások, legyenek azok bármilyen rosszindulatúak, vagy hatásúak, nem minket minősítenek, hanem a támadót!
Incidens I.
Incidens II.
Incidens III.
Újak: Incidens IV.
Incidens V.
Incidens VI.
Incidens VII.
Incidens VIII.
Incidens IX.
Security Incident I.
| Időpont: 2007. december 6 14:34:21 - 2007. december 6 16:41:18 |
A támadás típusa: Denial of Service |
| Károk: 1 óra 7 perc szolgáltatáskiesés, az annyi mint 23.678.921 $ |
Ellenlépések: Ütemezett feladat, mely 10 percenként kilövi az NC.EXE-ket |
| Az eset leírása: |
2007. Mikulás napján délután három óra felé kaptuk az első telefonos bejelentést
az Ördöglakat elérhetetlenségéről. Mivel ekkor a fő rendszergazda házonkívül volt,
további egy óra telt el a hathatós intézkedésig. Az első jelekből arra lehetett
következtetni, hogy sikeres Denial of Service támadást hajtottak végre a webhely
ellen, amit a későbbi vizsgálatok igazoltak is.
A rendszert közel tízperces megfeszített munkával, 16:41:18-kor tudtuk ismét elérhetővé
tenni.
Az események menete:
- Idő: 16:18 PM, egy órával az incidens után. Az alábbi ábrán leolvasható az első látvány, ami a szerveren
fogadott minket:
- Idő: 16:20 PM. Bejelentkezés után az eseménynaplóban megtaláltuk a memória elfogyására
utaló bejegyzést, ami 14:23:27-kor keletkezett:
- Idő: 16:23 PM. A nyomozás folytatódik! A Task Managerben látható, hogy a nap folyamán az egyik játékos
a Backdoor pályán felkínált belépési lehetőség birtokában
ciklusban elindított mintegy 100 db SQLCMD.EXE-t, amelyek némelyike ráadásul SQL
scripteket is futtatott, ezzel megette az összes memóriát, sőt többet is. Egy TASKKILL -IM
SQLCMD.EXE -F parancs a memóriagondot azonnal helyretette. A tapasztalatok fényében
a vezetőség a lapozófájl kikapcsolása mellett döntött, hogy legközelebb ilyen esetben
se lassuljon be a rendszer (magyarázat hamarosan a NetAcademia Tudástárban)
- Idő: 16:28 PM. Alaposabb vizsgálat kimutatta, hogy az ISA Server Firewall Service
az alapértelmezett biztonsági beállításoknak megfelelően (a C:\ meghajtó betelése
miatt) 14:34:21-kor leáll, mivel nem tudott naplóbejegyzést készíteni. Ez tekinthető
a szolgáltatáskiesés hivatalos kezdetének:
- Maga a partícióbetelés már 13:55-kor elég jól haladt, de innentől még fél óráig
bírta a rendszer:
- Idő: 16:36 PM. A következő lépés a teletömködött alkönyvtár megkeresése volt. Érdekesség,
hogy egy olyan könyvtárat kellett keresni, amiben a Backdoor pályán használt NETWORK_SERVICE
felhasználónak írási joga van. Ezt meg is találtuk a \Windows\Temp könyvtár "személyében".
Néhány gigabájt szemét kihajítása után a Windows kezdte jól érezni magát:
- Idő: 16:41 PM. A rendszererőforrások felszabadítása és a logok átvizsgálása után
az ISA Server Firewall szolgáltatást újraindítottuk:
- Idő: 16:50 PM. Szolgálati közlemény elhelyezése az Ördöglakaton a kedélyek lecsillapítása
érdekében:
Szolgálati közlemény: az iménti leállás egy DOS támadás következménye volt.
A támadás összes részletét hamarosan publikáljuk. Egyelőre röviden: valaki a Backdoor pályán ciklusban
elindított kb. rengeteg SQLCMD.EXE-t, amivel megette az összes RAM-ot. Ügyes! (De nem ez a feladat!)
- Idő: 2007. december 7. 10:37 AM. Jelen incidensriport elkészítése és publikálása.
|
Security Incident II.
| Időpont: 2007. december 8. 22:31 |
A támadás típusa: akasztják a hóhért :-) |
| Károk: 10-es faktorú leégés, az annyi mint 73.437.191 $ |
Ellenlépések: Server.HtmlEncode() minden injektált mező kiíratása köré. |
| Az eset leírása: |
2007. december 8-án 22:31-kor kaptuk az alábbi - stílszerűen Ördöglakat meghívóként
megkomponált - hibajelentést, amely arról tájékoztat, hogy a diplomamegjelenítő
nem lett eléggé átgondolva, mert ez is egy Deface-pálya, ha a játékos HTML-kódot
injektál be az SQL-táblába:
Ilyen esetben eléggé bután néz ki a diplomalista, amint az az alábbi ábrán látató.
Sőt, kiderül, hogy másoknak is kedvük támadt erre a trükkre (Kuszi):
Ha pedig megnyitjuk a képecskés diplomát, az aztán a szívet melengető látvány! Két
ördöglakat egymás alatt!
Köszönet és hála Mavikának, aki a szabályok teljes betartásával jelentette az eseményt!
|
Security Incident III.
| Időpont: 2007. december 12. valamikor este |
A támadás típusa: jelszóváltoztatás az SQL Serveren |
| Károk: éjszaka nem ment az Ördöglakat, az annyi mint 12.487.537 $ |
Ellenlépések: egyelőre semmi. |
| Az eset leírása: |
2007. december 12-én reggel az Ördöglakaton az alábbi ábrán szereplő hibaüzenet fogadott,
nevezetesen hogy az Ordoglakat nevű felhasználó nem tudott belépni az SQL Serverbe:
Már vártuk ezt a fajta támadást, ami tulajdonképpen elkerülhetetlen, HA az ember idegeneket
enged be a gépére. Miről is van szó? Elsőre talán azt gondolnánk, hogy az SQL Injection pályán
változtatható meg a jelszó, hisz ott is "be vagyok engedve", egy SQL-felhasználó vagyok, nyilván
jogom van a saját jelszavam megváltoztatására. Azonban ha valaki kipróbálja az ALTER LOGIN (korábbi
nevén sp_password) parancsot, láthatja, hogy egy normál felhasználónak nincs joga megváltoztatni a
saját jelszavát. (Ahhoz ALTER ANY LOGIN jogosultság kellene.)
Íme a bizonyíték, hogy nem így hajtották végre a jelszómódosítást. Kizárásos alapon
a másik bejárat marad, a NetCat, ahol a beérkező felhasználó az IIS nevében, az IIS fiókjával ténykedik,
ami a Network Service nevű fickó.
Nézzük meg, kinek a nevében fut az SQL Server?
Nocsak-nocsak! Ez ugyanaz a pasas! Nincs ennek véletlenül erős jogosultsága az SQL Serveren? Nincs:
Innentől - bevalljuk - ez az incidens olyan módszerrel készült, amit nem ismerünk.
Várjuk a becsületes megtaláló jelentkezését, hogy kiírhassuk ide, ő volt a "feltaláló"!
(És persze hogy hogyan csinálta?)
|
Security Incident IV.
| Időpont: 2007. december 12 19:31 |
A támadás típusa: Adatlopási kísérlet |
| Károk: nyilvános pánik a köbön, eszeveszett kapkodás, az annyi mint 5.234.921 $ |
Ellenlépések: Semmi, a VI. incidens megoldása ezt is megoldotta. |
| Az eset leírása: |
2007. december 15. Rutinellenőrzés során gyanús fájlokat találtunk a .net Temp könyvtárában.
Első közelítésre a végrehajtható fájl egy SpyWare-nek tűnt, de később kiderült, hogy csak egy átnevezett
NetCat.EXE. A másik fájl viszont egyértelműen az Ördöglakat adatbázis mentése, amiben az a gáz,
hogy ebben bent van az összes regisztrált felhasználó neve, emailcíme és jelszóhash-e.
A legnagyobb kár akkor ért volna bennünket, ha az emailcímek kikerülnek, illetve ha az egyik emailcím
alapján kiderül, hogy az egyik játékosunk milliárdos, mert annak azért érdemes lett volna a jelszavát fetörni.
Ilyenkor térül meg, hogy annak idején úgy döntöttünk: mindenki random jelszót kap. Így legalább
csak azoknak lett azonos a felhasználóneve és jelszava bármi mással, ha ezért tevékenyen tett, küzdött,
és ő maga lecserélte a jelszavát valami "kényelmesre".
Az események menete:
- Idő: 19:40 PM, 9 perccel az incidens után. A gyanús fájlok felfedezése:
- Idő: 19:43 PM. Az elkövetés módjának felfedezése. A tettes kihasználta, hogy a Backdoor pályán
buta módon ugyanazt a felhasználótengedjük be (Network Service), mint akinek a nevében az
SQL Server is fut, így képes volt engedélyezni parancssorból az xp_cmdShell külső tárolt eljárást,
ami bizony szarvashiba volt a mi részünkről.
Mármint az, hogy nem teszteltük végig, mire képes
a Network Service, hanem hittünk a blablának, hogy ez egy gyenge felhasználó (lásd még Incident VI.):
- Idő: 22:34 PM. Még mindig nem tudjuk, hogy az illető vajon el is
vitte-e az adatbázist, vagy "csak" lementette. Pánikroham, a regisztrált felhasználók értesítése.
- Idő: 23:02 PM. Alaposabb vizsgálat kimutatta, hogy a fájlt nem tudta a tettes az ISA Serveren
átvinni, már bizonyos, hogy adatlopás nem történt. Szolgálati közlemény elhelyezése, szunya.
- Idő: másnap 14:11 PM. Az előző napi emailes riadóra eddigre visszaérkezett kommentek mindegyike azt kérdezte,
hogy miért tároltuk a jelszavakat Clear Textben. Mivel ez a képtelenség egy csomó játékosban felmerült,
hosszas tanakodás után úgy döntöttünk, hogy mégiscsak ki kell küldeni mégegy szpemet, hogy ezt a
félreértést tisztázzuk. Kiment a Riadó lefújva üzenet.
|
Security Incident V.
| Időpont: 2007. december 16 |
A támadás típusa: keylogger kísérlet |
| Károk: 0 $ |
Ellenlépések: DELETE *.* /Y /S |
| Az eset leírása: |
2007. 16-án rutinellenőrzés során az alábbi gusztustalanságokat találtuk a Backdoor pályán engedélyezett
felhasználó számára is írható C:\WMPUB könyvtárban:
Örülünk neki, kedves ajándék, de igazán nem kellett volna!
|
Security Incident VI.
| Időpont: 2007. december 6 14:44 |
A támadás típusa: Denial of Service |
| Károk: 1 perc szolgáltatáskiesés, az annyi mint 546.456 $ |
Ellenlépések: Leszámolás a Network Service-illúzióval |
| Az eset leírása: |
2007. december 16. 14:44-kor az Ördöglakat leesett a hálózatról. Rövid vizsgálat kiderítette, hogy az egyik játékos
az általunk beengedett Network Service felhasználóval (az ominózus Backdoor pálya már megint) kipróbálta, fel tud-e
venni statikus bejegyzést az ARP cache-be.
Szégyen és gyalázat: igen! És persze mi történik, ha hülyeségeket visz be az ARP Cache-be? Azonnali teljes megvakulás
az adott cím(ek) felé. Ő nem aprózta el, a Default Gateway címét ütötte felül egy véletlenszerű MAC Addressel:
Az alatta lévő parancsról meg ne is beszéljünk :-(
Hogy fordulhatott elő ez a hiba? Úgy, hogy a határidő szorításában senki nem tesztelte végig, mit is tud pontosan
a Network Service. A marketing bullshit szerint ez egy gyenge felhasználó, direkt abból a célból, hogy ha ezzel fut
egy szolgáltatás, de megborítják, a támadónak ne legyen semmiféle rongálási joga. Idézet
innen:
The Network Service account is a special, built-in account that is similar to an authenticated
user account. The Network Service account has the same level of access to resources and objects as members of the Users
group. This limited access helps safeguard your system if individual services or processes are compromised.
A tapasztalat nem ezt igazolta. A Network Service röpült, hogy a lába nem érte a földet.
Mellékhatás: a Backdoor pálya bedöglött, mivel per pillanat annyira gyenge felhasználóval fut az IIS, hogy annak nincs
joga processt indítani. A probléma megoldásán, a pálya kijavításán dolgozunk, lesz itt ismét Backdoor!
|
Security Incident VII.
| Időpont: 2007. december 16-17 egész hétvégén |
A támadás típusa: a programozó téved |
| Károk: elérhetetlen weblapok, sérült pályák, hiányzó CSS stb. Az annyi mint: 123.123.123.123.123 $ |
Ellenlépések: küzdelmes áttérés |
| Az eset leírása: |
|
2007. december 16. Az Ördöglakat mindenféle idióta hibaüzenettel szórakoztatja a játékosokat.
Missing LINQ.DLL és hasonlók. Néha a fekete alap fehérré változik. A Deface pálya és a Diploma
hibaüzenetet ad.
A probléma oka: az egyik fejelsztő, aki áttért Visual Studio 2008-ra, eszement módon "Yes"-t
nyomott arra a fenyegető kérdésre, hogy "Áttérjünk-e .net Framework 3.5-re?". A hülyeség bekövetkezésének
esélyét nagyban növelte az akut adatlopási pánik (Incidens IV.). Ha az nem lett volna, bizonyára ez a gomb sem
nyomódott volna meg.
A projekt átállt. A szerver meg nem. A hatás nem maradt el, mivel ez a Framework verzió nincs is feltelepítve az Ördöglakatra :)
Az Ördöglakat azért van, hogy tanuljunk a hibákból...
|
Security Incident VIII.
| Időpont: 2008. augusztus 9. |
A támadás típusa: a programozó téved |
| Károk: kihagyható páylák az Ördöglakaton! Megőrülök! A kár: felbecsülhetetlen $ |
Ellenlépések: asp.net kód átnyálazása |
| Az eset leírása: |
|
2008. augusztus 9, szép nyári nap. Egyik játékosunk egy árnyas fa alatt
ülve az Ördöglakatot kínozza. Hiába, általában dögunalom a nyaralás, fel kell dobni valamivel :-)
Játékosunk türelmetlen, azon agyal, hogyan léphetne előre a diploma felé kicsit nagyobb léptekkel,
mint ahogy azt a Tervezők tervezték, anélkül, hogy vére folyna (életerő). Rövid (!) próbálkozás utánn sikerrel jár! Jaj!
Az eljárás menete:
- Juss el egy játékosoddal bármi áron a bármelyik szintre. Mindegy, hogy milyen lassan és bénán,
mekkora életerővel, mert ez a játékos csak töri az utat. Használd fel az összes hintet bátran.
- Regisztálj egy másik néven.
- Lépj be az agyongyötört felhasználóddal, melynek már szinte semmi élete sincs, de jól előrejutott.
- Menj a legmagasabb pályára, ahová a másik, friss játékosoddal repülni akarsz.
- Lépj ki a ronccsal, lépj be az újjal, és tádá! Egyből azon a szinten vagy, ahol a kolléga "haldoklik"
A "hiba" oka az, ahogyan az asp.net alapból kezeli a ki- és bejelentkezéseket. Alapjában véve nem igazi hiba,
hanem inkább kényelmi szolgáltatás, hogy ha kijelentkezünk, azonnal és automatikusan eldob a login lapra,
mégpedig úgy, hogy ha sikerül a bejelentkezés, visszadob ugyanoda, ahonnan jöttünk. Ez a mi
esetünkben hiba, mert ugyanaz a lap nem feltétlenül érhető el az új felhasználó számára. Lássuk, hogyan történik ez.
A "kijelentkezés" link megnyomása eldob minket a login.aspx lapra, ahol megfigyelhető, hog az eredeti lap elérési útja
hozzáfűződik az URL végéhez, vagyis alapból feltöltődik annak a lapnak a címével, ahonnan a kijelenkezést
kezteményeztük (ReturnUrl paraméter):
A megoldást az jelenti, ha a "kijelentkezés" link teljesen kidob a főoldalra. Szerencsére erre az asp.net
fejlesztői is gondoltak, ezért további két paraméter megadásával, programozás nélkül be tudtuk foltozni a
biztonsági rést:
Many thanks to Diamont Ágoston
|
Security Incident IX.
| Időpont: 2008. december 17. |
A támadás típusa: a programozó ismét téved |
| Károk: már megint kihagyható páylák az Ördöglakaton! A kár: felbecsülhetetlen $ |
Ellenlépések: asp.net kód átnyálazása |
| Az eset leírása: |
|
2008. december eleje-közepe, készülődés a nyugodt-békés karácsonyra. Egyszer csak levél jön, hogy
már megint meg lehet kerülni a pályákat! Az eszem megáll! Ez meg hogy lehet már megint?!
Hát úgy, hogy minden szoftver garantáltan bugos! Az Ördöglakat is! Most éppen az volt a baja,
hogy a kolléga, aki a többnyelvesítést végezte, a saját kényelme érdekében kikommentezett
egy létfontosságú csalásdetektort, ami megakadályozta, hogy olyan pályára lépjen bárki,
ami még nem jár neki.
A kikommentezést nem dokumentálta, el is felejtette. A kódot ezzel a "kisebb" módosítással
véglegesítettük december tizenvalahanyadikán.
Nem kellett hozzá egy hét, hogy valaki rátaláljon a biztonsági résre!
Az eljárás menete majdnem ugyanaz, mint augusztusban:
- Juss el egy játékosoddal bármi áron a bármelyik szintre. Mindegy, hogy milyen lassan és bénán,
mekkora életerővel, mert ez a játékos csak töri az utat. Használd fel az összes hintet bátran.
- Regisztálj egy másik néven.
- Lépj be az agyongyötört felhasználóddal, melynek már szinte semmi élete sincs, de jól előrejutott.
- Menj a legmagasabb pályára, ahová a másik, friss játékosoddal repülni akarsz.
- Kopizd ki az URL-t, és másold be a friss felhasználónál. A pálya kicsit betegen jön be, de a továbbjutási
kérdés látszik, a gomb ottvan, add meg a helyes választ, és továbblépsz!
A hiba oka ennek az egy sornak a kimommentezése volt:
Many thanks to Blackpro921
|
|