Nya tekniker
Datum: 2006-10-02 2006-10-02 Skribent: Jonas Feldt
Föreläsare: Gunnar Kreitz
Den här föreläsningen behandlar säkerhetshål i SQL- och PHP-kod, möjliga exploits av teckenkodningssystemet UTF-8 och så kallad Google-hacking. Även formella metoder (matematiska bevis) för säkerhet tas upp, samt IDS - Intrusion Detection Systems.
1 Mitre
Förra föreläsningen togs Mitre upp, en organisation som bland annat administrerar en databas med Common Vulnerabilities and Exposures (CVE). CVE är till för att namnge säkerhetshål, så att världen har ett gemensamt namn för ett visst hål.
1.1 Kritik mot Mitre
Mitre har fått en del kritik för sin databas. Det som nämns är bland annat:
• Det är inte Mitres sak att hålla reda på säkerhetshål.
• Databasen listar säkerhetshål, inte exploits.
• Man jämför så att säga äpplen och päron när man likställer ett inte så allvar- ligt säkerhetshål som Cross-site Scripting (XSS) med det allvarligare buffer overflow.
• En stor del av säkerhetshålen som samlats in gäller små applikationer, som mycket få personer använder.
2 Varför är XSS och SQL-injection så vanligt?
PHP är ett scriptspråk som används för att skapa dynamiskt webb-innehåll. I och med att det är väldigt lätt att skriva PHP-kod lockar det till sig nybörjare som inte alltid vet hur säker kod ska skrivas. PHP har också en ganska dålig säkerhetsdesign.
2.1 Dålig säkerhet i PHP
• En variabel i PHP är register-globals, som satt till false ger en farlig funk- tionalitet i applikationen. Ett vanligt PHP-anrop, t.ex. f oo.php?f oo = 2 gör att variabeln f oo i programmet får värdet 2. Detta anrop kan utökas till f oo.php?f oo = 2&admin = true, vilket förstås gör att en eventuell boolesk variabel admin får värdet true. Om denna variabel satt till sann ger använda- ren administrator-rättigheter kan mycket tråkigt hända. I tidigare versioner
1
av PHP fanns inte register-globals. En automatisk översättning av variabler i anropet till variabler i programmet utgjorde då ett stort säkerhetshål.
• PHP är inte heller så bra på att isolera kunder från varandra som använder samma webbhotell.
2.2 Exempel på dålig säkerhet i färdigt system
Systemgruppen på KTH laddade ned ett gratis Open Source-bokningssystem för att föreläsare enkelt skulle kunna boka t.ex. salar och projektorer. En snabb granskning av källkoden hittade man
• 3 SQL-injections
• 10 XSS
Detta visar att det är farligt att lita på scripts man installerat på sin webb-server.
3 Don’t Try This At Home!
Folk är snälla och rapporterar hål, men kan trots det råka ut för problem.
• Det är dumt att leta efter säkerhetshål på t.ex. hemsidor frilans". Utan ut- tryckligt tillstånd kan man råka illa ut. Det räcker inte att säga att man letade hål bara för att vara snäll".
• Blir man inhyrd för att göra ett säkerhetstest på ett system ska man se till att ha ett bra och skriftligt kontrakt innan man börjar.
3.1 Du kan råka illa ut
• Engelsmannen Daniel James Cuthbert skulle donera pengar till tsunami-offer, men fick ingen bekräftelse att det fungerat. Han misstänkte att han blivit offer för phising och ville kolla om siten var legitim. Detta gjorde han av någon anledning genom att stoppa in ../../../ i URL:en. Han erkände sig senare skyldig till dataintrång och dömdes för detta.
• I USA skulle McCarthy ansöka till University of Southern California. Han hittade en SQL-injection i ansökningsapplikationen, laddade hem 17 rader ur antagningsdatabasen och rapporterade detta. Han dömdes till 3 års villkorlig dom, varav 6 månader i husarrest, samt 36000 dollar i böter.
4 SQL-injection
Databaser är idag mycket populära och används till det mesta. För att kommuni- cera med dem används SQL. En SQL-fråga kan se ut så här:
SELECT * from author WHERE author_id = $aid;
Genom att sätta $aid = ”0; droptable *” kan man få SQL att tolka frågan som SELECT * from author
WHERE author_id = $aid = 0;
DROP TABLE *
Denna extra DROP TABLE läggs alltså in som en helt ny sats i SQL-queeryn och gör att alla tabeller i databasen raderas. Om PHP-scriptet som denna SQL-fråga körs från inte har rättigheter att t.ex. radera tabeller har man inte detta problem.
4.1 Hur hindrar vi SQL-injection?
• Filtrera indata.
• Använd bättre API/konfiguration.
• Försök göra indata säkert. Tecken som ska undvikas är enkla citationstecken, t.ex. ’foo’, dubbla citationstecken och backslash. Gör istället om ’ till \’, ” till \” och \ till \\ för att slippa problem.
Det här kan gå fel! Oftast missar programmeraren att filtrera någon parameter. En bättre ide är att använda ett bättre API, t.ex:
• JDBC:
SELECT * FROM author WHERE author_id = ?"
• Python: Här kan man skriva SELECT * FROM author WHERE author_id = %(aid)d
för att säkerställa att aid alltid ska vara en signed integer. Det farliga är att en enkel felskrivning kan öppna upp för SQL-injection. Korrekt syntax är för en SQL-fråga är execute(query, params), men råkar man skriva fel, execute(query%params), är SQL-injection möjlig.
5 Teckenkodning och icke-kanonisk form
UTF-8 är ett sätt att koda tecken, en så kallad multi byte-kodning. Den går ut på att man först bortser från eventuella nollor, sedan tittar på första bitarna för att se hur många bytes som följer. Antal bit:
• ≤ 7 bitar ger kodning med 1 byte, på formen 0xxx xxxx.
• 8 - 11 bitar ger kodning med 2 bytes, på formen 110x xxxx 10xx xxxx.
• 12 - 16 bitar ger kodning med 3 bytes, på formen 1110 xxxx 10xx xxxx 10xx xxxx
5.1 Risker med UTF-8
På en webbserver vill man inte tillåta anrop som ger obehöriga tillgång till skydda- de filer. Ett anrop som innehåller t.ex. ../../../etc/passwd skulle eventuellt kunna exponera en lösenordsfil och ska förbjudas. Genom att känna igen och förbjuda tec- kenkombinationen ”../” undviker man den säkerhetsrisken. Problemet när UTF-8 används är att / kan se ut på olika sätt:
• Kodat med 1 byte ser / ut så här:
0010 1111 (2F hexadecimalt).
• Kodat med 2 byte ser / ut så här:
1100 0000 1010 1111 (C0 AF hexadecimalt).
2-bytekodningen är ogiltig, men om den kodas av naivt ger den ändå ett / som resultat. I Microsofts Internet Information Services (IIS) accepterades förut ogiltiga 1-bitsrepresentationer av tecken, vilka senare ej kollades vid valideringen av indata.
En URL som innehöll ”..%C0%AF..” gav nu ett icke önskvärt resultat, eftersom C0AF ju är 2-bytesrepresentationen av /. Den fruktade teckenkombinationen ../
tilläts därför. Hålet är nu lagat och IIS filtrerar ut ogiltiga teckenrepresentationer.
5.2 Problem med fler namn på samma sak
Webbservern Apache gör ingen skillnad på stora och små tecken i filnamn (likaså Windows). Om rättigheter sätts för filen index.html får även filen med namn In- deX.HtMl dessa rättigheter när den öppnas. I Windows rättades problemet till för länge sedan, men nyligen kom svenska databasleverantören MySQL på att de ha- de samma typ av säkerhetshål. Om man satte rättigheter för db.secret fick även db.SeCreT dessa.
6 PKCS 1.5 - paddning för RSA-signaturer
Firefox och Operas implementationer av PKCS (Public Key Cryptography Stan- dards) 1.5 är lite trasiga. Publik exponent e = 3 används ibland i RSA-nycklar av effektivitetsskäl, även av vissa Certification Authorities. Paddning anses ge bättre säkerhet, men att använda 3 som exponent ger upphov till en del problem. PKCS 1.5 ser ut så här: 0.1.FF.FF.1 <hashfunktion> <hashvärde> Skapar man paddningen med en trasig implementation av PKCS 1.5 på detta sätt kan man lätt ordna så att t.ex.
0.1.FF.FF.1 [SHA-1] [160 bit hashvärde] [skräp]
får en giltig signatur, trots att man själv lagt in [skräp] med elakheter i slutet.
Lägger man in rätt sorts [skräp] i slutet så att PKCS-datan blir en jämn kub, kommer en ”trasig” RSA validera meddelandet trots att det inte är orginalet.
7 Google-hacking
Sökmotorn Google exponerar en hel del säkerhetshål i diverse system. Inför valet kunde man söka på mysql_connect ssu.se rootför att få reda på lösenordet till SSUs databas. PHP-koden som då hittades avslöjade allt:
$db = mysql_connect(”[IP-nummer]”,”root”,”[Lösenordet]”);
Anledningen till att koden syntes var ett byte av PHP-version. Den gamla ver- sionen gjorde om .php4-filer till HTML, men när den nya installerades behandlades bara .php-filer. Koden i .php4-filer syntes därför i klartext.
På webbsidan johnny.ihackstuff.com finns en lista över just Google-hacks. Med hjälp av den listan och Google kan man finna:
• Servrar med kända säkerhetshål
• Lösenord (ofta från sidor som visar PHP-kod istället för att köra den)
• Hemlig information. Ett exempel på detta är att det nyligen hittades service- manualer som två bankomattillverkare lagt ut där default-lösenord syntes i klartext. Eftersom default-lösenord ofta inte byts var det möjligt att komma in i vissa bankomater och ändra inställningarna. En man i USA utnyttjade detta och ändrade så att en bankomat istället för att ge 5-dollarsedlar gav 20-dollarsedlar vid uttag.
8 Formella metoder
Tänk om vi kunde bevisa att ett program är korrekt! Först måste vi definiera vad
"korrekt"innebär för just det programmet, sedan bevisa att programmet uppfyl- ler villkoren för korrekthet. För små program kan man bevisa detta, men för mer komplex programvara har man inte kommit på hur man ska gå tillväga. Korrekt- hetsbevis är ett aktivt forskningsområde.
8.1 Proof-Carrying-Code
Om vi kan bevisa något, varför inte skicka med det med programmet? Idén är att den som kör programmet verifierar beviset som kom med. Den stora bördan läggs därför på tillverkaren, men det finns problem med att definiera vad man vill bevisa.
Skulle man få den här metoden att fungera reducerar man i viss mån behovet av signaturer. Om koden behöver ändras skulle beviset fortfarande gälla, om nu inte elak kod lagts till.
9 IDS - Intrusion Detection System
IDS innebär IntrångsDetektionsSystem, som upptäcker attacker. Hindras även at- tackerna kallas systemet för IPS - Intrusion Protection System. Två typer av IDS är NIDS och HIDS.
9.1 NIDS - Network IDS
Ett NIDS känner igen, snarare än spärrar, nätverksattacker. Ett exempel på ett NIDS är Snort, som är en komersiell open source-programvara. Snort har en sig- naturdatabas med kända attacker och kostar pengar för att få snabb tillgång till denna. Vanligaste formen för ett NIDS är just att känna igen farliga mönster, som
”../”, ”cmd.exe” och ”/bin/sh”, samt kända maskar.
9.2 HIDS - Host IDS
Vanliga operationer för ett HIDS är att kontrollera loggar, filintegritet, aktivite- ter, rootkit, virus och program på en enskild maskin. Det finns ett antal HIDS- produkter, men ingen jättestrikt definition på vad ett HIDS är. Grundkomponenter
är nog loggar och integritetsskydd (t.ex. för att kolla att operativsystemets kärna är intakt).
9.2.1 Problem med IDS
Traditionella IDS har en del problem, bland annat att de mest känner igen gamla attacker. En cracker kan därför starta en egen IDS för att på det sättet lära sig undvika det skydd som det tänka offret har. Det vore istället bättre om ett IDS kunde känna igen suspekt aktivitet, även om det inte sett attacken förut. Kanske kan detta lösas med att ett IDS har en modell över vad som är normalt och rapporterar avvikelser utifrån detta. Att utveckla ett sådant IDS är ett aktivt forskningsområde.
9.2.2 Problem med NIDS
NIDS går ofta att lura, t.ex. genom att det finns oklarheter i protokoll.
• IP har t.ex. fragmentering, vilket kan ge problem för ett NIDS om operativ- systemet och NIDS:et tolkar fragmenteringen olika. Att olika operativsystem kan tolka fragmenteringen på olika sätt innebär förstås ytterligare problem.
Ett paket kan skickas uppdelat, se bilden nedan.
När paketet kommer fram ser det inte ut som orginalet, och tolkningsproble- met uppstår.
Vilken version av byte 3 gäller?
• Kodning, UTF-8, kan ge problem.
9.3 Att samköra loggar
Intressant information om vad som hänt i ett system kan fås fram genom att sam- köra loggar från IDS och brandvägg. Det är bra att få reda på vad mer den som gjort IDS-attacken kommunicerat med. Att få ut något användbart ur loggar är svårt. En idé är att beskriva händelser med grafer, men den är inte fullt utvecklad ännu.
9.4 Honeypot
En honeypot är ett system som är uppsatt enbart för att brytas in i. En cracker som upptäcker en honeypot lägger ner tid på att anfalla detta system, istället för att försöka bryta sig in i det riktiga systemet. Med en honeypot får man varningar om intrångsförsök och tillåter en att analysera anfallare riskfritt. Erfarenheter visar att ju bättre honeypot som finns uppsatt, destå mer anfallsaktivitet. En bra honeypot tar det ju längre tid att bryta sig in i och avslöja som falsk.
10 Källor
Python operators: http://rgruet.free.fr/PQR2.3.html
PKCS 1.5: http://www.linuxsecurity.com/content/blogcategory/93/106/7/14/
PKCS 1.5 säkerhetshål: http://66.249.93.104/search?q=cache:C7w9KvVD274J:https://www .identityblog.com/+PKCS+1.5+exponent+3+root+cube&hl=en&gl=se&ct=clnk&cd=7 Bankomathacking:
http://www.eweek.com/article2/0,1895,2018674,00.asp
