Vigilante: End-to-End Containment of Internet Worms

OS Seminar, DIKU efterår 2005.

Præsentation af Troels Larsen.

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å.

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).

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.

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.

Resten af præsentationen

• Hovedpunkter i Vigilante:– SCA-generering, -verificering og –distribution.– Filter-generering.

• Desuden:– Eksperimentelle resultater på virkelige orme.– Fremtidige optimeringer.

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.

Eksempel på en SCA

• SCAs har et fælles format:– identifikation af den sårbare service og af SCA-typen.– verifikationsinformation (til hjælp for verificeringsprocessen).– sekvens af beskeder, som skal sendes til servicen.

• SCA for Slammer:

Service: Microsoft SQL Server 8.00.194

Alert type: Arbitrary Execution Control

Verfication information: Address offset 97 of message 0

Number of messages: 1

Message: 0 to endpoint UDP:1434

Message data: 04,41,41,41,41,42,..... (376 bytes, 1. byte = 0x04).

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årbarhed findes).

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.

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).

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.

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.

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.

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.

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).

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.

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.

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.

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.

Service# inficeret pc’er

Infektions-

hastighed

SlammerMicrosoft SQL Servere

75.000 8,5 s

CodeRedMicrosoft IIS Servere

360.000 37 min

BlasterMicrosoft Windows RPC service

500.000 37 min

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.

18

206

2667

2

457

18573899

1

10

100

1000

10000

Slammer Blaster CodeRed Slammer (NX)

Genereringstid (ms) SCA size (bytes)

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.

1018

75

0

10

20

3040

50

60

70

80

Slammer Blaster CodeRed

Verifikationstid (ms)

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.

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

STg (ms)

Tv (ms)

Slammer0,117 75.000 18 10

CodeRed0,00045 360.000 2667 75

Blaster0,00045 500.000 206 18

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.

24

273

3402

1

10

100

1000

10000

Slammer Blaster CodeRed

Filtergenereringstid (ms)

0,2

0,76

2,07

0

0,5

1

1,5

2

2,5

SQL RPC ISS

Overhead (%)

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.