Biztonsági rés

A számítógépes biztonság területén, a biztonsági rés, sebezhetőség, sérülékenység kifejezéseket olyan gyengeség jelölésére használják, amely egy számítógépes rendszerre jellemző, és amelynek kihasználásával egy támadó kárt tehet a rendszer integritásában. A biztonsági rések fakadhatnak többek között:

• gyenge jelszavakból
• szoftver hibákból
• számítógépes vírusokból
• egyéb kártékony szoftverekből
• script vagy kód injektálásból
• speciális rendszereknél SQL injektálásból
• a rendszer nem megfelelő konfigurálásából

Egy biztonsági kockázatot biztonsági résnek nyilvánítanak, ha arról bebizonyosodik hogy a gyakorlati életben is kihasználható gyengeséget jelent. Egy biztonsági kockázathoz, amennyiben biztonsági réssé lép elő, általában egy vagy több úgynevezett exploit tartozik. Az exploit a biztonsági rés egy működő és teljesen implementált demonstrációja. Az úgynevezett sebezhetőségi ablak egy időintervallum, amely attól az időponttól kezdődik, hogy egy szoftverben biztonsági rést találnak, és addig tart amíg hivatalos javítás meg nem érkezik hozzá.

Általában elmondható, hogy egy szoftvert minél bonyolultabb és alacsonyabb szintű nyelven készítenek el, annál nagyobb teret enged az emberi hibázásból adódó biztonsági kockázatoknak. Egy programnyelv önmagában nem jelent kockázatot, a kockázatot a programozó (nem)tudása és munkafelfogása jelenti. Például, az ANSI C nyelvben a programozó maga tervezi meg és implementálja a memóriakezelést, C# .NET esetén viszont ezt a rendszer úgynevezett szemétgyűjtő algoritmusokkal leveszi a programozó válláról. Az ANSI C vagy C++ nyelven készített alkalmazások gyakran szenvednek memóriaszivárgással vagy buffer-túlcsordulással kapcsolatos gyengeségekben.

A biztonsági rések eredete

• Jelszó menedzselési hiányosságok: A felhasználó gyenge jelszavakat használ. A felhasználók néha nincsenek tájékoztatva hogy milyen követelményeknek kell megfelelnie az általuk használt jelszónak, hogy Brute force támadásoknak ellenálló legyen. Esetleg a felhasználó a számítógépén olyan dokumentumban is tárolja jelszavát amely könnyen elolvasható. Máskor a felhasználók minden szolgáltatáshoz és rendszerhez ugyanazt a jelszót használják.
• Operációs rendszer - alapvető tervezési hibák: bizonyos operációs rendszerek fejlesztői rá voltak/vannak kényszerítve arra, hogy a könnyű kezelhetőség miatt hiányos biztonsági szabályokat alkalmazzanak. Például a Microsoft Windows korai kiadásaiban minden felhasználó teljes jogosultsággal használta a rendszert, felügyelet és korlátozás nélkül. [1]
• Szoftver hibák: A programozó valamilyen okból (például elégtelen tesztelésből kifolyólag) hibákat hagy a kiadásra szánt szoftver verzióban. Ezen szoftverhibák aztán a piacra került verziókkal együtt kerülnek a felhasználókhoz.
• Nem megfelelően ellenőrzött adatbevitel: A program feltételezi hogy minden adatbevitel megfelelően átgondoltan érkezik. Bizonyos szoftvermegoldások használatakor a speciálisan formázott felhasználói bemenettel manipulálható a szoftverrendszer.

Biztonsági hibák közzététele

A számítógépes biztonsággal foglalkozók körében mindig éles vitákat vált ki. Általában nincs konszenzus arra vonatkozóan, hogy például egy sok felhasználót érintő biztonsági hibát egyáltalán nyilvánosságra kell-e hozni. Egyesek szerint kötelesség bármilyen, gyakran használt szoftver hibájának minél szélesebb körben való közzététele. Mások szerint a felhasználók biztonsága (vagy biztonságérzete) okán bizonyos ideig várni kell a hiányosságokról híreket közölni. Megfelelően megfontolt várakozási idő beiktatásával a fejlesztők kidolgozhatják megoldásaikat a hibákra, amelyeket előbb eljuttatnak a felhasználóikhoz, a hiba részleteit pedig csak ezután fedik fel. Manapság a számítógépes szoftverek biztonságával szinte külön iparág foglalkozik. Számos cég új gyakorlatot vezetett be: pénzjutalmat ígérnek azon felhasználóknak, akik első kézben bizonyítanak be új sebezhetőségeket („zero day”). Ez egy új és legális piac, ahol a biztonsági rések információival kereskednek.

A biztonság szemszögéből, a szabad, nyilvános és azonnali közzététel csak akkor sikeres, ha az érintett fejlesztők előbb kapják meg az információkat, mint a számítógépes bűnözők (vagy ellenérdekeltek), illetve a fejlesztők el is készítik a javításokat. A másik gyakorlat esetén, ahol a titkolózás a megoldás, ugyanez a szabály érvényesül, de a bűnözőknek a biztonsági rések kiadásáig (amennyiben az egyáltalán megtörténik) sokkal több idejük és szabadságuk van a rések felfedezésére, azok kihasználására. A hátrány itt a nyilvánosság hiánya: ha egy rést egy bűnöző vagy egy bűnözői csoport felfedez egy titkolózással „védett” szoftverben, és arról nem értesíti a fejlesztőket vagy a nyilvánosságot, megfelelő ügyességgel korlátlan ideig élhetnek titkukkal.

Léteznek kereskedelmi és nonprofit csatornák ezen érzékeny információk archiválására és közzétételére. Ilyen például a CERT, a SecurityFocus, vagy a Secunia.

A sebezhetőségek nyilvánosságra hozatalának mikéntjét az alábbi kategóriák jellemzik:

• Az információ szabadon elérhető a teljes nyilvánosság számára, valamely forrásból, valamely részletességgel és megbízhatósággal
• Az információt egy megbízott, vagy egy szakterület által elismert szervezet tesz közzé, valamely részletességgel
• Az információ megbízott szakértők alapos analízise és kritikusság szerinti besorolása után teszik közzé, megbízható helyen, megfelelő részletességgel

A biztonsági hibák javítása

Sok olyan eszköz létezik, amelyek segítenek a fejlesztőknek a biztonsági rések felfedezésében, vagy akár annak eltávolításában. Ezek az eszközök megfelelően alkalmazva jó segítséget adnak, de nem helyettesítik az emberi ítélőképességet. Ezen úgynevezett "scanner" szoftverek gyakran hagynak figyelmen kívül biztonsági réseket vagy gyakran okoznak vaklármát.

Sebezhetőségek minden jelentős operációs rendszerben kerültek már felfedezésre, többek között a Microsoft Windowsban, a Mac OS X-ben, a Unix-Linux rendszerek számos változatában, az OpenVMS-ben és másokban. Az egyetlen út a biztonságos használathoz a rendkívül megfontolt módon végzett telepítés (akár a rendszert izolálva), a rendkívül komolyan vett és folyamatos karbantartás, (a biztonsági figyelmeztetők figyelése és minden biztonsági frissítés alkalmazása), az üzembe helyezés és üzemeltetés ökölszabályainak elfogadása és alkalmazása (például tűzfalak), vírusvédelem) illetve egyéni, a szervezetre szabott biztonsági házirend kidolgozása, annak következetes fejlesztése, frissítése, betartatása, oktatása.

Példák sebezhetőségekre

• Memória biztonsággal kapcsolatos sebezhetőségek:
  • buffer-túlcsordulás
  • Memóriaszivárgás
• Adat- vagy bemenet-ellenőrzési hiányosságok:
  • Sztring formázási hiba
  • Shell programok nem megfelelő használata
  • SQL injektálás
  • Kód injektálás
  • E-mail injektálás
  • Cross-site scripting
  • HTTP header injektálás
• Versenyhelyzetek:
  • Szimbolikus linkek versenye
  • Tranzakciók versenyhelyzete
• Privilégium-korrupció:
  • Cross-site authentikációs hiba
  • Clickjacking ("kattintás elterelés")
  • FTP bounce
• Privilégium-megszerzés
• Felhasználói felülettel kapcsolatos hibák
  • Áldozat-vádolás: A szoftver a felhasználóra bíz egy biztonsággal kapcsolatos döntést, anélkül hogy elég információval látná el a megfelelő döntéshez

Külső hivatkozások angol nyelven

• Languages Standard's group: Útmutató fejlesztőknek a sebezhetőségek elkerülésére a nyelv megválasztásával és használatával
• Microsoft Security Response Center: A biztonsági rés definíciója
• Nyílt gyűjtőadatbázis nyílt- és zártforrású szoftverek biztonsági réseihez