6. fejezet - Biztonsági tesztelés

Ez a fejezet áttekinti a biztonsági támadások leggyakoribb típusait. Az itt leírt biztonsági támadások a www.owasp.org oldalon található szabad cikkek fordításai.

A támadások azok a technológiák, amiket a támadók használnak, hogy kihasználják az alkalmazások sebezhető pontjait. A támadásokat gyakran tévesztik össze a sebezhető pontokkal. Egy támadás leírása azt mondja el, hogy mit tenne a támadó a gyengeség kihasználására, nem pedig az alkalmazás gyenge pontjait ismerteti.

Ebben a fejezetben a legfontosabb biztonsági támadásokat ismertetjük, hogy a tesztelés során tudjuk, minek lesz kitéve az alkalmazásunk. Ha ismerjük a biztonsági támadásokat, akkor a tesztek során kipróbálhatjuk, hogy alkalmazásunk ellen áll-e a támadásnak. Ha igen, akkor a kiadott szoftverünk kisebb kockázatot jelent a használójának és így nagyobb értéket képvisel. A támadás ellenállóság egyrészt verseny előny, másrészt az elkérhető magasabb ár fedezi a tesztelés extra költségeit. Az extra költségek a magasan képzett tesztelők magasabb munkadíjából és a támadás ellenállóság tesztelésének viszonylag időigényes volta jelenti. Ugyanakkor a támadás ellenállóság vizsgálatához nem elég csak a legfontosabb támadásokat ismerni, hiszen újabb és újabb támadási módszereket fejlesztenek ki az IT rendszerek feltörésére specializálódott hacker-ek.

A támadás ellenállóság tesztelése általában feketedobozos teszt. Történhet a rendszer kiadása előtt vagy után is. Ha utána történik, akkor általában etikus törési kísérletről beszélünk. Ehhez általában külső szakembereket, fehér kalapos hacker-eket szoktak felkérni. Ha a kiadás előtt történik, akkor általában a legmagasabban képzett belső tesztmérnökök feladata. Ez a fejezet nekik szól, de a szükséges ismereteknek csak egy részét tartalmazza.

A biztonsági támadások legfontosabb típusai (támadás fajtái – konkrét támadások):

  1. „Működés ellehetetlenítése – Cache Mérgezés” (Abuse of Functionality - Cache Poisoning )

  1. (Data Structure Attacks - Overflow Binary Resource fájl )

  2. „Ártalmas kód beágyazása – logikai/időzített bomba (Embeeded Malicious Code - Logic/time bomb)

  3. „Trójai” (Troyan Horse)

  4. „Azonosítási folyamat kihasználása – Account kizárási támadás” (Exploitation of Authentication - Account lockout attack)

  5. „Befecskendezés – Közvetlen statikus kód befecskendezése” (Injection - Direct Static Code Injection)

  6. „Útkeresztezési támadás” (Path Traversal Attack)

  7. „Próbálgatós technológiák – nyers erő támadás” (Probabilistic Techniques - Brute force attack)

  8. „Protokol manipuláció – http válasz szétválasztás” (Protocol Manipulation - Http Response Splitting)

  9. „Forrás kimerítés – aszimmetrikus erőforrások elfogyasztása (erősítés)” (Resource Depletion - Asymmetric resource consumption (amplification))

  10. „Erőforrás manipuláció – kémprogram” (Resource Manipulation – Spyware)

  11. „Szimatoló támadás – Hálózati lehallgatás” (Sniffing Attacks - Network Eavesdropping)

  12. „Átverés – oldalakon keresztüli kérelem hamisítás (CSRF)” (Spoofing - Cross-Site Request Forgery (CSRF))

6.1. Működés ellehetetlenítése – Cache Mérgezés

Leírás

A károsan felépített válasz hatása fölnagyítható, ha egy több felhasználó által használt web cache tárolja vagy akár egyetlen egy felhasználó böngésző cache-e. Ha egy választ egy megosztott web cache-ben tárolnak, mint például amik legtöbbször találhatóak a proxy szerverekben, akkor a cache minden használója mindaddig a káros tartalmat fogja kapni, amíg a cache bejegyzést ki nem tisztították. Ehhez hasonlóan, ha a választ egy egyéni felhasználó böngészője cache-eli (tárolja), akkor az a felhasználó mindaddig a káros tartalmat fogja kapni, amíg a cache bejegyzést meg nem tisztították, ebben az esetben csak a helyi böngésző másolata lesz érintve.

Hogy egy ilyen támadás sikeres legyen, a támadónak a következőket kell tennie:

  1. Megtalálni a sebezhető service kódot, amin keresztül több fejléccel terhelheti meg a http fejléc mezőjét.

  2. Rákényszeríteni a cache szervert, hogy flush-olja az aktuális cache tartalmat, amit szeretnénk, hogy cache-eljen a szerver.

  3. Küldeni egy speciálisan elkészített kérelmet, amit a cache tárolni fog.

  4. Küldeni a következő kérelmet. A korábban befecskendezett, a cache-ben eltárolt tartalom lesz a válasz erre a kérelemre.

Ez a fajta támadás meglehetősen nehezen kivitelezhető valós környezetben. A szükséges feltételek listája hosszú és nehezen teljesíthető a támadó által. Ennek ellenére még mindig egyszerűbb ezt a technikát használni, mint a Felhasználók Közötti Elcsúfítást (Cross-User Defacement).

A Cache Mérgezés támadás a HTTP Válasz Szétválasztás (HTTP Response Splitting) és a hálózati alkalmazás hibái miatt lehetséges. A támadó szempontjából létfontosságú, hogy az alkalmazás engedélyezze a fejléc mező feltöltését több fejléccel a Kocsi Visszatérés (CR (Carrige Return)) és a Sor Betáplálása (LF (Line Feed)) karaktereket használva.

Példa:

Találtunk egy weblapot, ami a szolgáltatási nevét a „page” argumentumtól kapja, aztán visszairányít (302) ehhez a kiszolgálóhoz.

pl.: http://testsite.com/redir.php?page=http://other.testsite.com/

A redir.php példa kódja:

   rezos@dojo ~/public_html $ cat redir.php
   <?php
     header ("Location: " . $_GET['page']);
   ?>

A megfelelő kérelem elkészítése: [1]

1 – a lap eltávolítása a cache-ből

   GET http://testsite.com/index.html HTTP/1.1
   Pragma: no-cache
   Host: testsite.com
   User-Agent: Mozilla/4.7 [en] (WinNT; I)
   Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
   image/png, */*
   Accept-Encoding: gzip
   Accept-Language: en
   Accept-Charset: iso-8859-1,*,utf-8
        

A HTTP fejléc mezők - "Pragma: no-cache" vagy "Cache-Control: no-cache" – eltávolítják a lapot a cache-ből (már ha tárolva volt benne természetesen).

2 – a HTTP Válasz Szétválasztást használva arra kényszerítjük a cache szervert, hogy két választ generáljon egy kérelemre.

  GET http://testsite.com/redir.php?site=%0d%0aContent-
  Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aLast-
  Modified:%20Mon,%2027%20Oct%202009%2014:50:18%20GMT%0d%0aConte
  nt-Length:%2020%0d%0aContent-
  Type:%20text/html%0d%0a%0d%0a<html>deface!</html> HTTP/1.1
  Host: testsite.com
  User-Agent: Mozilla/4.7 [en] (WinNT; I)
  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
  image/png, */*
  Accept-Encoding: gzip
  Accept-Language: en
  Accept-Charset: iso-8859-1,*,utf-8
         

Szándékosan állítjuk be a jövő időt (a fejlécben 2009. október 27-re van állítva) a második válasz HTTP fejléc „Last-Modified” mezőjében, hogy tároljuk a választ a cache-ben.

Ezt a hatást megkaphatjuk a következő fejlécek beállításával:

  1. Last-Modified [Utoljára-Módosítva] (Az „If-Modified-Since” fejléc ellenőrzi)

  2. ETag (Az „If-None-Match” fejléc ellenőrzi)

3 – küldjünk kérelmet a lapnak, amit szeretnénk kicserélni a szerver cache-ében

   GET http://testsite.com/index.html HTTP/1.1
   Host: testsite.com
   User-Agent: Mozilla/4.7 [en] (WinNT; I)
   Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
   image/png, */*
   Accept-Encoding: gzip
   Accept-Language: en
   Accept-Charset: iso-8859-1,*,utf-8
         

Elméletben a cache szervernek össze kellene párosítania a második választ a kettes kérelemből a hármas kérelemmel. Így kicseréltük a cache tartalmát.

A kérelem maradékét egyetlen kapcsolat alatt kivitelezni lehet (hacsak a cache szerver nem igényli kifinomultabb módszer használatát), valószínűleg az egyiket azonnal a másik után.

Ennek a támadásnak a használata problémásnak tűnhet, ha általános Cache Mérgezési megoldásként szeretnénk használni. Ez a cache szerverek különböző kapcsolati modellje és kérelem feldolgozási megoldása miatt van így. Mit jelent ez? Például azt, hogy az a módszer, amivel az Apache 2.x cache-ét a mod_proxy és mod_cache modulokkal hatékonyan tudjuk mérgezni, nem fog működni a Squid esetében.

Egy másik probléma az URI hossza, ami időnként lehetetlenné teszi, hogy betegyük a szükséges válasz fejlécet, amit legközelebb a kérelemhez kellene párosítani a megmérgezett laphoz.

Az felhasznált kérelem példák az alábbi linken[1] található dokumentumból származnak és a cikk szükségleteinek megfelelően lettek módosítva.

Az alábbi dokumentumban bővebben olvashat ezekről a támadási fajtákról: [1]http://packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf, készítette: Amit Klein, Director of Security and Research