Vigilante: End-to-End Containment of Internet Worms

1. Vigilante: End-to-End Containment of Internet Worms OS Seminar, DIKU efterår 2005. Præsentation af Troels Larsen.

2. Generelt om ormebekæmpelse • Ormebekæmpelse skal • automatiseres, • fordi orme spreder sig hurtigere end mennesker kan reagere. • være præcis. • Dvs., de må ikke forårsage netværksudfald ved at blokere harmløs traffik. • være svær at omgå.

3. Beslægtet arbejde • Nyligt arbejde bekæmper orme på netværksniveau. • Disse teknikker • blokerer/begrænser videresendelse af pakker fra hosts, som udviser unormal opførsel. • har ikke adgang til information om, hvilke sårbarheder en given orm vil udnytte. • Disse teknikker har begræsninger. De kan • ikke håndtere orme, som har normale trafikmønstre. •  systemet kan omgåes (3. krav). • have falske positive (netværksudfald). •  systemet er ikke præcist (2. krav).

4. Overblik over Vigilante • Vigilante foreslår et automatisk end-to-end system. • Dermed har systemet information om, hvilke sårbarheder en orm vil udnytte. • Instrumenteret software hos hosts detekterer orme (detektions-maskiner). • Ved detektion genererer og distribuerer hosts self-certifying alerts (SCAs). • SCAs • er bevis på en sårbarhed. • kan let verificeres af sårbare hosts. • fjerner behov for tillid mellem hosts.

5. Overblik over Vigilante • SCAs verificeres før distribution og ved modtagelse fra netværket. • Ved at reproducere infektionsprocessen i en sandkasse. • Advaret hosts genererer automatisk filtre, som blokerer beskeder, før de når den sårbare service. • Filtre har • lavt overhead, • ingen falske positive og • Kan blokere ormevarianter.

6. Resten af præsentationen • Hovedpunkter i Vigilante: • SCA-generering, -verificering og –distribution. • Filter-generering. • Desuden: • Eksperimentelle resultater på virkelige orme. • Fremtidige optimeringer.

7. SCA typer • Arbitrary Execution Control (AEC) • omdirigering af programudførelsen til et vilkårligt sted i servicens adresserum. • Arbitrary Code Execution (ACE) • kode-indsprøjtnings sårbarheder. • Arbitrary Function Argument (AFA) • data-indsprøjtnings sårbarheder.

8. Eksempel på en SCA • SCAs har et fælles format: • identifikation af den sårbare serviceog afSCA-typen. • verifikationsinformation (til hjælp for verificeringsprocessen). • sekvens af beskeder, som skal sendes til servicen. • SCA for Slammer:

9. SCA verificering • Verificering i en virtuel maskine (VM). • Verificerings-setup: • Hosts har en verifikationsmanager. • Netværksservices er instrumenteret. • Ved at loade biblioteker indeholdende en Verified funktion. • Kritiske funktioner er wrapped: • Dvs., hvis argumentet til en kritisk funktion matcher en referenceværdi fra manageren, kaldes Verified. • Uden for VM: • SCA-verifier virker som interface til VMen og omvendt firewall. • Verificering er: • hurtig, • simpel og ensartet (tillader forskellige detektionsmaskiner), • og har ingen falske positive (succes  sårbarhedfindes).

10. SCA verificering • For at verificere: • SCA-verifier sender SCAen til manageren. • Manageren identificerer servicen og ændrer ormebeskedens bytestreng ved det angivet offset, til: • adressen af Verified for AEC. • koden for call Verified for ACE. • referenceværdien for AFA. • Succes hvis Verified udføres. Ellers mislykket efter timeout.

11. SCA generering • Hosts logger beskeder fra netværket. • Når et ormeangreb detekteres • generes en kandidat-SCA ved at søge loggen igennem; • hvis kandidaten kan verificeres, distribueres den. • SCAs har en generel udformning. • Muliggør mange forskellige detektion-maskiner (forskellighed  færre falske negative). • Vigilante beskriver to detektion-maskiner: • non-executable pages (lavt overhead+dækning), • dynamic dataflow analysis (højt overhead+dækning).

12. SCA generering • Non-executable pages. • Kan generere AEC og ACE. • Idé: • Når en orm forsøger at eksekvere en beskyttet side, kastes en undtagelse. • Detektoren fanger undtagelsen og forsøger at generere en SCA til distribution.

13. SCA generering • Dynamic dataflow analysis. • Kan også generere AFA. • Idé: • Marker data modtaget fra netværket som beskidt og følg den ved en simpel algoritme: • Når beskidt (ren) data flyttes, bliver destinationen også beskidt (ren). • Detektions-maskinen blokerer farlig brug af beskidt data: • Hvis beskidt data er ved at blive loadet ind i PCen, signaleres en mulig AEC. • Hvis beskidt data er ved at blive eksekveret, signaleres en mulig ACE. • Hvis en kritisk funktions argumenet er beskidt, signaleres en mulig AFA. • Problemer ved dynamic dataflow analysis: • En (lille) falsk positiv ratio. • En ringe performance i software. • Vigilantes løsninger: • Verificering før distribution. • Samarbejdende detektions-maskiner spreder byrden.

14. SCA distribution • Generelle krav til SCA distribution. • Hurtig. • Skalerbar. • Pålidelige og sikker. • Vigilante bruger et sikkert overlay; dvs. hver host har • et certifikat signeret af en betroet autoritet • binder et public/private nøglepar til et host_id. • et betydeligt antal naboer, som forbindes til ved autentificering og kryptering. • SCAs distribueres ved flooding til naboerne.

15. SCA distribution • Kompromiterede hosts kan søge at forhindre distribution med DoS-angreb. • Vigilante har tre modforanstaltninger. • Kun verificerede SCAs videresendes. • Blokerede eller duplicate SCAs videresendes ikke. • Naboloft. • Problemer med verificering-før-distribution. • Nogle hosts er ikke i stand til at verificere en given SCA. • Med flooding er sandsynligheden dog stor for, at en verificérkyndig host modtager SCAen. • Verificering medfører forsinkelse. • Dog ikke meget.

16. SCA distribution • Orme kan spredes hurtigere, hvis de har viden om et netværks topologi. • Derfor må viden om overlay’ets topologi skal holdes hemmeligt. • Vigilante gemmer denne viden med brug af super-peers. • Super-peers kører kun overlay-kode og VMs med sårbar service til hurtig verificering. • Hver host forbindes til et lavt antal super-peers (fx. 2).

17. Filtre • Hosts skal forsvare sig ved succesfuld SCA verificering. • Mulighed: at stoppe servicen eller brug af detektions-maskiner. • Vigilantes tilgang: blokering af ormetrafik ved filtre. • Fordel: servicen ændres ikke og kan fortsat fungere under angreb. • Krav til filtrene • genereres automatisk, • have ingen falske positive, • være effektive og introducere lavt overhead.

18. Filtre • Hosts genererer filtre ved at analysere eksekveringsstien for ormen. • Alle instruktioner instrumenteres for at opbygge en dataflow-graf. • Idéen er at stoppe eksekvering ved samme betingelser som for detektering. • Fx., filter-genereringen for en ACE stopper, når programmet er ved at overgive kontrollen til kode fra ormbeskeden. • Filtrene har ingen falske positive, men måske falske negative (de er for specifikke). • Vigilantes løsning: færre falske negative med to filtre. • Et specifikt filter uden falske positive. • Og et generelt filter, som måske har falske positive, men matcher flere beskeder for at blokere ormevarianter.

19. Filtre • Beskeder matches først mod det generelle. • Hvis ingen match, gives beskeden til programmet. • Ellers matches beskeden mod det specifikke. • Hvis match, droppes beskeden. • Ellers sendes den til en detektions-maskine, som endeligt afgør om beskeden er harmløs. • Hvis beskeden ikke er harmløs, droppes beskeden og detektions-maskinen genererer en passende SCA.

20. Eksperimentelle resultater • Tre virkelige orme blev evalueret: • Slammer opnår kontrol gennem en UDP pakke. Mens SQL-serveren kopierer en bytestreng fra pakken, overskrives en returadresse på stakken. • CodeRed sender en GET-besked. Mens IIS-serveren processerer beskeden, overskrives en adresse til en exception handler. • Blaster er en to-besked orm. Mens der kopieres et felt i den anden besked, overskrives en returadresse på stakken.

21. Eksperimentelle resultater • SCA-generering: • Tidstagning: • fra modtagelse af sidste ormebesked til detektoren har genereret en SCA. • verificering medregnes ikke. • Detektorer: • non-executetable pages og dynamic dataflow analysis.

22. Eksperimentelle resultater • SCA-verificering: • verificering i en Virtual PC 2004 virtuel maskine. • før enhver SCA-verificering gemmes VMs tilstand til disken. • efter verificering skabes en ny VM fra disken; den gamle skrottes. • Verificeringen er hurtig fordi: • en VM holdes kørende. • overhead lavt: CPU-forbrung < 1%; memory-forbrug ca. 84MB. • hvis VMs generes fra disken ad hoc bruges yderligere 4s.

23. Eksperimentelle resultater • SCA distribution – setup: • Simulering for at evaluere på stor skala (½mio. hosts). • S hosts er modtagelige (de kører den sårbare software). • p af de S hosts er detektorer; resten af S blot sårbare. • Ved modtagelse af en ormebesked: • En sårbar host bliver inficeret. • En detektor genererer og distribuerer en SCA. • Specielle forhold: • Netværk-congestion indregnes; forårsaget af ormeudbrudet. • Inficerede hosts laver DoS-angreb på nabohosts ved kontinuerligt at sende falske SCAer. • Initielt er 10 hosts inficerede.

24. Eksperimentelle resultater • SCA distribution – resultater: • Til forsøget er brugt parameterværdierne vist i tabellen. • Forsøget viser, at: • med få detektorer (p=0,001) inficereres max 5 %af den sårbare befolkning. • med betydelige stigninger i Tv,  og antallet af initielt inficerede hosts (og med DoS-angreb) forbliver Vigilante effektiv

25. Eksperimentelle resultater • Filtre: • Øverste figur viser filter-genereringstider. • Filtrene er effektive: • Det specifikke har ingen falske positive og blokerer også en del variationer af angrebet. • Nederste figur viser overheadet • i et forsøg, hvor netværksbeskeder indfanges og filtreres og hvor der samtidig også er angreb.

26. Fremtidige optimeringer • Ad hoc VM-generering forbundet med stort overhead. Da orme spredes hurtigt, holdes en VM derfor kørende. • Teknikker til at starte VMs med lav forsinkelse undersøges. • Filtrene kan omgåes ved pakkefragmentering. • Velkendte modtræk mod fragmentering vil implementeres.