1 / 29

Säkerhetsanalys av applikationer

Internet Security Summit 2002. Säkerhetsanalys av applikationer. Vem är Anders Ingeborn?. Civilingenjör Datateknik KTH Säkerhetkonsult i eget företag Fokus på produktevaluering Frilansskribent Föredragshållare. Bakgrund. Teorin Många bra algoritmer Många bra protokoll

Télécharger la présentation

Säkerhetsanalys av applikationer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Internet Security Summit 2002 Säkerhetsanalys av applikationer

  2. Vem är Anders Ingeborn? • Civilingenjör Datateknik KTH • Säkerhetkonsult i eget företag • Fokus på produktevaluering • Frilansskribent • Föredragshållare

  3. Bakgrund • Teorin • Många bra algoritmer • Många bra protokoll • Många bra modeller • Praktiken • Många osäkra produkter • Många osäkra IT-system • Många osäkra företag

  4. Vad är det som brister? • Sällan matematiken • Ofta lösenorden • Design • Rätt mekanism på fel plats • Fel mekanism på rätt plats • Implementation • Slarv, stress...

  5. Granskning/validering • Exempel på två problemområden • Kryptografi (t.ex. autentisering) • Minneshantering på låg nivå • Typer av granskning • Interaktion, ej labbmiljö • Maskinkodsanalys, labbmiljö • Källkodsanalys (annan föreläsning) • Kunden ofta mer intresserad än leverantören?!

  6. Autentisering • Bevisa att något är äkta • T.ex. en identitetsangivelse • Användningsområde för lösenord • Naivt: ”Sesam öppna dig” • Inte så lyckat om någon kan avlyssna • Inte så lyckat om någon kan läsa databasen

  7. Saltvärden • Bra för att ”skydda” lösenord • Lagring i lösenordsdatabas • Förhindra att två användare med samma lösenord får samma krypterade lösenord • En användare ska inte kunna dra slutsatser om en annan användares lösenord även om han/hon får en kopia av /etc/shadow etc • Slutsats • ”Saltvärden är bra”

  8. Rätt sak på fel plats • Teori • Autentisering behöver säkerhet • Saltvärden är bra; ger säkerhet • Marknadsföring • ”...Our security measures encompass a complete package...”

  9. 1: Autentisering 4 34.321306 192.168.0.2 -> 192.168.0.17 TCP 1419 > xxx [PSH, ACK] 0030 44 08 30 f6 00 00 00 00 00 7f 00 00 00 04 00 00 D.0............. 0040 00 00 00 00 00 02 23 c3 46 02 00 00 0c 1c 00 00 ......#.F....... 0050 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0060 00 00 00 00 00 00 00 00 00 05 75 73 65 72 31 00 ..........user1. 0070 00 00 42 34 41 45 45 46 46 31 34 32 33 33 32 35 ..B4AEEFF1423325 0080 39 31 38 34 32 44 43 30 35 44 45 32 44 31 31 42 91842DC05DE2D11B 0090 37 34 32 30 30 33 44 45 38 32 37 31 44 38 43 41 742003DE8271D8CA 00a0 43 30 33 30 36 31 34 30 45 39 45 37 41 43 37 41 C0306140E9E7AC7A 00b0 45 31 30 35 41 E105A 5 34.370202 192.168.0.17 -> 192.168.0.2 TCP xxx > 1419 [PSH, ACK] 0030 42 ca a2 6c 00 00 00 00 00 20 00 00 00 04 00 00 B..l..... ...... 0040 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0050 00 00 ff ff ff fe ...... 6 34.479239 192.168.0.2 -> 192.168.0.17 TCP 1419 > xxx [ACK] 0030 43 e8 a1 7a 00 00C..z..

  10. Utvärdering • Användarnamn i klartext • Autentisering i ett steg, ”Sesam…” • Ingen serverautentisering • Samma lösenord vid flera försök ger olika ”kryptosträng” • Saltvärden? • Slutsats: En bra mekanism använd i fel sammanhang

  11. Liten liknelse • Ganska bra • Vaktpost ropar ”14” • Soldat svarar ”7” • Summa 21? Differens 7? • Ganska dåligt • Soldat ropar ”14 och 7”

  12. En bättre autentisering • VPN implementeras ofta med protokollet IPSec • Autentisering, sekretesskydd, riktighetsbevarande etc. • Bättre än det mesta, t.ex. • Publika algoritmer • Challenge/response • Ömsesidig autentisering

  13. IKE Aggressive-Mode, PSK Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I --> • Får man som angripare checksumman kan man försöka en attack med ordlista på lösenord/PSK • Slutsats: Även bra protokoll behöver anpassas till hotbilden!

  14. Nu något om kryptering • Kryptering vs. nonsens • LDAP-kryptering, MD5-krypterat • ”...Krypterar med 256-bitars AES och dekrypterar med 2048-bitars Diffie Hellman...” • ”...A folder containing secret or confidential information becomes invisible when the archive is locked...”

  15. Kryptografi/maskinkodsanalys • Inget nytt under solen • Auguste Kerckhoff • La Cryptographie Militaire 1883 • Säkerheten ska ligga i nyckeln inte i algoritmen • ”Hemlig specialutvecklad kryptering”

  16. Räcker detta? • Det finns uppenbarligen gott om möjligheter att göra fel i alla fall • Program för t.ex. signering av filer • Bra algoritm, bra implementation, bra nyckel…men… • Privata nyckeln inkompilerad som en konstant i programkoden utan skydd • Glöm inte att skydda nyckeln!

  17. 2: Binärkodsanalys

  18. Något om ECB-mode • Electronic Code Book • Blockvis, oberoende kryptering • Block av krypterade data kan bytas ut • Riktighetsindikerande funktion • T.ex. en icke-linjär checksumma

  19. 3: Exempel på ECB-mode

  20. 4: Användning av ECB-mode badpassword:1007:39ead569b79c7ea239ead569b79c7ea2:12f21f3c752398a9b2b692c58ff9612e: • Lösenordet var ”11111111111111” • Men inget lösenord blir någonsin ”starkare” än 7 tecken

  21. Minneshantering • Vanligaste typen av säkerhetsbrist de senaste tio åren • Rapport fr. Oregon Institute of Technology • Programmeringsspråken C & C++ • Övergripande förklaring • Skriva utanför reserverat minne • Skriva över sparad instruktionspekare • Styra om exekveringen till egen kod

  22. Fyra generationer • Överskrivning i stack-minnet • strcpy, strcat etc. • En byte utanför • vektor[17] ger 0...16 • Formatsträngar • sprintf( dst, ”%s”, src ); • Överskrivning i heap-minnet • Kontrollblock varvat med minnesblock

  23. 5: Minneshantering/interaktion • >telnet labbserver 4711 • 0 OK labbserver • HELP %8x%8x%8x • 5e6f7a8b9c0d1e2f3a4b5c6d • >telnet labbserver 80 • GET /index.html HTTP/1.1 • Basic-Authentication: AAAAAAA...AAAAAA • Connection to host lost...

  24. Fördel med interaktion • Enkelt, kräver inga avancerade verktyg • Identifierar tanke-/beräkningsfel • ”Rätt” funktion: strncpy vs. strcpy • ”Rätt” plats: maxgräns för dynamisk inmatn. • Fel i alla fall • Beräknat maxgränsen fel • Ganska komplext med automatiserad maskinkodsanalys

  25. 6: Exempel på tankefel while( buf[bufptr] != '\n' && buf[bufptr] != '\0' ) { if( buf[bufptr] == ' ' && argptr == 0) { argptr = bufptr + 1; } bufptr++; } if( argptr == 0 ) { strncpy( cmd, (const char *)buf, bufptr ); cmd[bufptr] = 0x00; printf( "Server log: Command: %s\n", cmd ); } else { strncpy( cmd, (const char *)buf, argptr-1 ); cmd[argptr-1] = 0x00; strncpy( args, (const char *)buf+argptr, (bufptr-argptr) );}

  26. Studera funktionsanrop • Maskinkodsanalys • Vilka argument skickas? • Vilka lokala variabler används? • Vilka funktioner anropas? • Importerade funktioner från delade systembibliotek?

  27. 7: Exempel på ”formatsträng”

  28. Avslutning • Falsk kryptografisk säkerhet är farligare än ingen säkerhet alls • Fel i minneshantering ger lömska fel • Räkna upp egenskaper.. • Nyckellängder, funktioner • ..sämre än att utvärdera säkerheten • Common Criteria, ITSEC, TCSEC/OrangeBook, FIPS-140 etc.

  29. Frågor?anders.ingeborn@bredband.net

More Related