Desarrollo de aplicaciones seguras

Curso: 5007427 (28585) Diseno de aplicacionesseguras (Bloque Servicios Web y seguridad

informatica)

Fernando Tricas Garcıa

Departamento de Informatica e Ingenierıa de SistemasUniversidad de Zaragoza

http://www.cps.unizar.es/~ftricas/

ftricas@unizar.es

Departamento de Informatica e Ingenierıa de Sistemas (Univ.Zaragoza) - Curso: Desarrollo de aplicaciones seguras

1

Introduccion

Fernando Tricas Garcıa

Departamento de Informatica e Ingenierıa de SistemasUniversidad de Zaragoza

http://www.cps.unizar.es/~ftricas/

ftricas@unizar.es

Departamento de Informatica e Ingenierıa de Sistemas (Univ.Zaragoza) - Curso: Desarrollo de aplicaciones seguras

2

Un ındice

I Introduccion

I Gestion de riesgos

I Seleccion de tecnologıas

I Codigo abierto o cerrado

I Principios

I Auditorıa de programas

3

Un ındice (cont.)

I Desbordamiento de memoria

I Control de acceso

I Condiciones de carrera

I Aleatoriedad y determinismo

I Aplicacion de la criptografıa

4

Un ındice (cont.)

I Gestion de la confianza y validacion de entradas

I Autentificacion con claves

I Seguridad en bases de datos

I Seguridad en el cliente

I En la web

5

Introduccion. Antes de empezar.

I Se invierte mucho tiempo, dinero y esfuerzo en seguridad anivel de red por la mala calidad de los programas.

I Algunas veces los cortafuegos, los sistemas de deteccion deintrusos (IDS) ayudan.

I Los programas malos son mucho mas abundantes de lo quecreemos.

I La forma de desarrollar los programas es responsable en granmedida del problema.

6

Cifras

I El 30 % de los proyectos en entornos empresariales se cancelansin haber sido finalizados.

I De los que se terminan, el 30 % cuesta al final entre un 150 %y un 200 % del presupuesto original.

7

Cifras

I Menos del 10 % de proyectos en empresas grandes terminan atiempo, y cumpliendo el presupuesto.

I Las tasas de defectos en productos comerciales se estimanentre 10 y 17 por cada 1000 lıneas de codigo.Otras estimaciones: entre 5 y 50 fallos.

8

Mas cifras

I Diciembre de 1990: Miller, Fredrickson. ‘An empirical study ofthe reliability of Unix Utilities’ (Communications of the ACM,Vol 33, issue 12, pp.32-44).

I Entre el 25 y el 33 % de las utilidades en Unix podıaninterrumpirse o colgarse proporcionandoles entradasinesperadas.

I 1995: Miller otra vez, ejecutando Fuzz en nueve plataformastipo Unix diferentes:

I Fallos entre un 15 y un 43 %I Muchos fallos ya avisados en el 90 seguıan allıI La menor tasa de fallos: utilidades de la FSF (7 %) y a las

incluidas junto con Linux (9 %) (¿Uh?)

No consiguieron hacer fallar ningun servidor de red. Tampocoel servidor X Window. Muchos clientes de X, si

9

Cifras

I 2000: Miller y Forrester. Fuzz con Windows NT.I 45 % de los programas se colgaron o se interrumpieronI Enviar mensajes aleatorios Win32 a las aplicaciones hacıa fallar

al 100 %

I Miller, Cooksey y Moore. Fuzz y Mac OS X.I 7 % de las aplicaciones de lınea de ordenes.I De las 30 basadas en GUI solo 8 no se colgaron o se pararon.

10

Cifras

I 2004-2005. Honeypot, con varios sistemas (Windows, Mac,Linux)

I Windows XP. SP 1.I Fue atacado 4857 vecesI Infectado en 18 minutos (Blaster y Sasser)I En una hora era un ‘bot’ controlado remotamente, y

comenzo a realizar sus propios ataques

I Feb-Marzo 2005: menos del 24 % de los Windows XPobservados en un estudio de AssetMetrix Research Labstenıan SP2. Menos del 7 % del total lo tenıan. 251 empresasnorteamericanas (seis meses despes de su lanzamiento).

http://www.stillsecure.com/docs/StillSecure_DenverPost_Honeypot.pdf

11

Estudio OpenSSHI Julio 2002 se descubrio un fallo de desbordamiento de

memoria remotoI Dos semanas despues de la publicacion del anuncio del fallo,

mas de 2/3 de los servidores observados seguıan siendovulnerables.

I Septiembre 2002. Un gusano explotaba el fallo (Slapper).I El 60 % de servidores era todavıa vulnerable.

Security holes. . . Who cares?http:

//www.cgisecurity.com/lib/reports/slapper-report.pdf

12

Introduccion. Antes de empezar.

I Los programas no tienen garantıa (¿todavıa?).

I La seguridad es un problema de gestion de riesgos.

I Pensemos en la seguridad durante el diseno, despues ya estarde.

13

Puede haber castigo

Cada vez se habla mas de la responsabilidad de las empresas quedesarrollan programas:

I 1999. Ambrosia Software (Rochester, N.Y.) anuncio que si algunode sus productos requerıan la reparacion de errores, el responsablede marketing comerıa insectos en alguna feria.http://www.ambrosiasw.com/PRs/eatbugs_PR.html

Parece que finalmente tuvieron que comerlos . . .

http://www.ambrosiasw.com/news/old_newsletter.php?id=34019&page=3

I 31 de diciembre de 1999. Las autoridades chinas obligaron a losejecutivos de la companıa aerea nacional a volar durante esa nocheen los vuelos programados.

14

¿Por que es importante?

I Cada vez hay mas computadores y en mas sitios.

I La gente ni sabe ni quiere saber de estos temas.

I Aun peor, saben lo que dicen las noticias.

15

Son los programas

I Dependemos (mucho) de los computadores (y sus programas).

I El principal problema es que la mayorıa de los desarrolladoresni siquiera saben que hay un problema.

I Ni los cortafuegos ni la criptografıa resolveran los problemas(el 85 % de los avisos del CERT no se pueden prevenir concriptografıa).

16

Son los programas (estupido)

I Esta bien proteger la transmision pero los atacantes prefierenlos extremos

I Las aplicaciones que interactuan con Internet son las masdelicadas, pero no es imprescindible que tengan contacto conla red para ser peligrosas.

17

Son los programas

I Empezar pronto

I Conocer las amenazas

I Disenar pensando en la seguridad

I Cenir el diseno a los analisis de riesgos y las pruebas

18

Gestion del riesgo

I La seguridad es un compromiso entre muchos factores:I Tiempo hasta que se puede venderI CosteI FlexibilidadI ReutilizabilidadI Relaciones entre los anteriores

I Hay que establecer las prioridades, a veces la seguridad no esla principal necesidad.

19

Seguro o Inseguro

I Mucha gente piensa en la seguridad como algo que se tiene ono se tiene.

I Es muy difıcil probar que un sistema de complejidad medianaes seguro.

I Frecuentemente, ni si quiera vale la pena.

20

Seguro o Inseguro

I Es mas realista pensar en terminos de gestion de riesgo:

I ¿Cuanto riesgo?I ¿Cuanto cuesta reducirlo?

Recordar: los ’malos’ no crean los defectos, simplemente losutilizan.

21

Fallos en los programas

I Ano 2000: aproximadamente 20 nuevas vulnerabilidades cadasemana

I Muchas en programas con codigo, pero otras tantas en lasque no se conoce

I Unix y Windows tambien estan equilibrados

I Siguen apareciendo problemas en programas probados yusados.

22

Algunas cifras

NIST: National Institute of Standards and TechnologyNVD: National Vulnerabilities Database

http://nvd.nist.gov/statistics.cfm?results=1

21 de febrero de 2007

23

Mas cifras

CERT: Organizacion del Software Engineering Institute (SEI).

http://www.cert.org/stats/18 de febrero de 2008

24

Y mas . . . la web

Figure 1. (a) Breakdown of disclosed vulnerabilities by softwaretype in May 2006, and (b) current vulnerability types disclosed in

Web-based applications. (Source: SecurityFocus.com)http://www.computer.org/portal/site/security/menuitem.6f7b2414551cb84651286b108bcd45f3/index.

jsp?&pName=security_level1_article&TheCat=1015&path=security/2006/v4n4&file=gei.xml

Resumida: http://tinyurl.com/3862ba

25

Mas cifras

http://www.cisco.com/web/about/security/cspo/docs/Cisco2007Annual_Security_Report.pdf

26

Consecuencias

http://www-935.ibm.com/services/us/iss/pdf/etr_xforce-2007-annual-report.pdf

27

¿Donde conocerlos?

I Bugtraq (http://www.securityfocus.com/)

I CERT Advisories http://www.cert.org/

I http://www.rediris.es/cert/

I Equipo de Seguridad para la Coordinacion de Emergencias enRedes Telematicas (http://escert.upc.edu/)

I ICAT Metabase (http://nvd.nist.gov/)

I OSVDB, Open Source Vulnerability Database(http://osvdb.org/)

I INTECO, http://www.inteco.es/

I RISKS Digest (http://catless.ncl.ac.uk/Risks/)

I Help Net Security http://www.net-security.org/

28

¿Y las tecnologıas?

I La complejidad introduce riesgos.I Anadir funcionalidades (no presente en el original)I Invisibilidad de ciertos problemasI Dificultad para analizar, comprender, asegurar.

29

Complejidad en navegadores

http://www.spinellis.gr/blog/20031003/index.htmlMozilla 1.3 // Explorer 5

30

La complejidad

I Windows NT → 35 millones de lıneas de codigo.

I Windows XP → 40 millones de lıneas de codigo.

I Windows Vista → 50 millones de lıneas de codigo.

I Linux 2.2 → 1.78 millones,

I Solaris 7 → 400000.

I Debian GNU/Linux 2.2 55 millones

I Red Hat 6.2 17 millones.

I Mac OS X Darwin 790000 (el kernel)

I Seguimos programando en C! (en el mejor de los casos C++)Esto va cambiando . . . Java, .Net, . . .

I Luego hay que instalar, configurar, usar

31

La complejidad

I Windows NT → 35 millones de lıneas de codigo.

I Windows XP → 40 millones de lıneas de codigo.

I Windows Vista → 50 millones de lıneas de codigo.

I Linux 2.2 → 1.78 millones,

I Solaris 7 → 400000.

I Debian GNU/Linux 2.2 55 millones

I Red Hat 6.2 17 millones.

I Mac OS X Darwin 790000 (el kernel)

I Seguimos programando en C! (en el mejor de los casos C++)Esto va cambiando . . . Java, .Net, . . .

I Luego hay que instalar, configurar, usar

31

Complejidad

Linux + Apache Windows + IIS

http://blogs.zdnet.com/threatchaos/?p=311Why Windows is less secure than Linux

Abril 2006

32

Complejidad, vulnerabilidades, incidentes, . . .

Dan Geer, 2004http:

//www.stanford.edu/class/msande91si/www-spr04/slides/geer.pdf

33

En red

I Cada vez mas redesI Los ataques pueden venir de mas sitiosI Ataques automatizados/automaticosI Mas sitios para atacar, mas ataques, mas riesgo

34

Extensibilidad

I Codigo movilI ‘Enchufables’ en el navegador (‘plugins’)I Modulos, ‘drivers’I Muchas aplicaciones tienen lenguajes que permiten extenderlas.

Economicamente conveniente (reutilizacion) pero ...

35

El entorno

I Anadir seguridad a un sistema ya existente es casi imposible

I Es mejor disenar con la seguridad en mente

I Otra fuente de problemas es ‘ambiental’: un sistemacompletamente seguro en el entorno para el que fue disenado,deja de serlo en otros.

36

Pero ... ¿Que es seguridad?

Primero, es importante establecer una polıtica que describa laforma de acceder a los recursos.

I Si no queremos accesos sin autentificar y alguien accede ...

I Si alguien hace un ataque de denegacion de servicio ...

37

Pero ... ¿Que es seguridad?

A veces es evidente lo que esta mal, y no hay que hilar tan fino,pero ...

I ¿Un escaneo de puertos es un ataque o no?

I ¿Hay que responder? ¿Como?

38

¿Tiene que ver con la confiabilidad?

‘Reliability’, confiabilidad, ¿no deberıa proporcionar seguridad?

I La confiabilidad se mide segun la robustez de la aplicacionrespecto a los fallos.

I La definicion de fallo es analoga a la definicion de polıtica deseguridad.

39

¿Tiene que ver con la confiabilidad?

I Entonces, la seguridad serıa una parte de la confiabilidad: si sepuede violar alguna parte de la polıtica de seguridad, hay unfallo.Sin embargo...

I Los problemas de robustez no siempre son problemas deseguridadLo son mas frecuentemente de lo que se piensa, de todosmodos.

I Si disenamos pensando en su robustez, seguramente tambienmejoraremos su seguridad

40

Malas practicas

Se hacen los programas, se espera a que aparezcan problemas, y seresuelven (si se puede).

I Solo se resuelven problemas conocidos por los desarrolladores

I No se trabaja ni con el tiempo, ni con la tranquilidad que hacefalta.

I Los parches habitualmente atacan al sıntoma, no al problema

I Los parches hay que aplicarlos ...

41

Las metas

I La seguridad no es una caracterıstica estatica

I 100 % seguro no existe (o es mentira)Mejor ...

I ¿Que queremos proteger?I ¿Contra quien?I ¿Contra que?

42

Prevencion

I Normalmente, se presta atencion cuando ya es tardeI El tiempo en la red es distinto (velocidad)

I Los ataques se propagan muy rapidoI Incluso se automatizan

43

Trazabilidad, auditabilidad

I Los ataques ocurriran

I Los contables lo saben (dinero)

I Estas medidas ayudan a detectar, comprender y demostrar losataques

I Es delicado

44

Vigilancia

I Auditorıa en tiempo real

I Se puede hacer a muchos nivelesbusqueda de ‘firmas’, patrones ...... pero tambien aserciones, codigo a proposito.

I A menudo, con trampas sencillas se puede capturar a unladron, o al menos evitar que haga dano.

45

Privacidad y Confidencialidad

(Privacidad ←→ Intimidad)

I Privacidad y confidencialidad son terminos muy relacionados

I Las empresas deben proteger los datos de sus clientes, inclusode los anunciantes

I Los gobiernos tambien

46

Privacidad y Confidencialidad

I No siempre comprendemos bien las consecuencias de nuestrasacciones

I Los programas deberıan asegurar la privacidad ...... pero los programas solo sirven para hacer el trabajo

I Si es posible ... no almacenar secretos

47

Seguridad multinivel

I Hay secretos ‘mas secretos’ que otros

I Ni las empresas ni los gobiernos quieren que se sepan algunosdatos

I Ademas, no todo el mundo tiene que saber lo mismo ......

I Es complejo

48

Anonimato

I Arma de doble filo

I A veces, hay razones sociales para favorecerlo (SIDA)

I Pero tambien las hay para controlarla (racismo, terrorismo,..)

I Junto con la privacidad, es de los temas mas importantes quehay que decidir.

I Global Identifier de Microsoft sirve para saber que copia deMS Office origino un documento

I WGA (Windows Genuine Advantage)

I las ’supercookies’ de Google y Microsoft . . .

49

Anonimato

I Carnivore, Echelon, ... ¿quien nos garantiza que se usan‘adecuadamente’?

I ¿Y las galletitas? ¿Realmente son necesarias? ¿Y si nos lasroban?

I Hay empresas que las ‘coleccionan’

I ¿Y si tenemos que hacerlo nosotros? ¿Que pasa si algo vamal? ¿La comodidad es compatible con la privacidad?

50

Autentificacion

I Saber quien para saber que puede hacer

I Hasta no hace mucho bastaba con la presencia fısica

I Internet!!!

I ¿mibancofavorito.com realmente es MiBancoFavorito?¿Realmente es un banco?

I SSL da tranquilidad pero ... ¿que garantiza?

51

Autentificacion

I Nadie mira los datos

I De muchas formas: mibancofavorito.com →mibacofavorito.com

I Si vale dinero, hay que tener cuidado.

I Algunos esquemas suponen anonimato, otros auditorıa.

I Algunos esquemas estan orientados a sesiones, otros atransacciones.

52

Integridad

I Seguir teniendo ‘lo mismo’

I Precios, cotizaciones, ... ¿y si nos los cambian?

I La informacion digital es muy facil de simular

53

Conociendo al enemigo

Es bueno conocer los errores frecuentes, sobre todo porque no sesuele hablar mucho del tema.

I Errores de programacion (buffers, condiciones de carrera,numeros aleatorios)Pero tambien ...

I La construccion es importante y tambien como se usaI Arquitectura cliente/servidorI Ingenierıa socialI Entradas maliciosas

54

En resumen

I Ver lo que va por la red, ponerse en medio

I Modificar lo que va por la red

I Simular lo que deberıa ir por la red

I Reemplazar el flujo de datos

I Grabar y repetir

55

Las metas de un proyecto

I Funcionalidad (resolver el problema)

I Ergonomıa -usabilidad- (a veces la seguridad interfiere con lacomodidad/conveniencia)

I Eficiencia (a nadie le gusta esperar)

I El mercado (habitualmente en contra de la simplicidad, y dela gestion de riesgos)

I Simplicidad (buena para los proyectos, buena para laseguridad)

56

Bibliografıa

I John Viega and Gary McGraw. Building Secure Software.Addison-Wesley

I Michael Howard, David C. LeBlanc. Writing Secure Code.Microsoft Press. Second Edition.

I Innocent Code. A security wake-up call for web programmers.Sverre H. Huseby. Wiley.

57

Mas libros

I Software Security. Gary McGraw. Addison-Wesley SoftwareSecurity Series.

I OWASP Guide to Building Secure Web Applications (va porla version 3.0)http://www.owasp.org/index.php/OWASP_Guide_Project

58

Mas bibliografıa

I Mark G. Graff, Kenneth R. Van Wyk. Secure Coding:Principles and Practices. O’Reilly & Associates

I John Viega, Matt Messier. Secure Programming Cookbook forC and C++. O’Reilly & Associates.

I Gary McGraw, Edward W. Felten. Securing Java: GettingDown to Business with Mobile Code

59

Bibliografıa

El otro lado.

I Greg Hoglund, Gary McGraw. Exploiting Software. How tobreak code. Addison Wesley.

I Cyrus Peikari, Anton Chuvakin. Security Warrior. O’Reilly.

I Andrews & Whittaker. How to Break Web Software. AddisonWesley.

I Tom Gallagher; Bryan Jeffries; Lawrence Landauer. HuntingSecurity Bugs. Microsoft Press.

60

Mas bibliografıa

En la red:

I Secure Programming for Linux and Unix HOWTOhttp://www.dwheeler.com/secure-programs/

I Security Developer Center Microsofthttp://msdn.microsoft.com/security

I Improving Web Application Security: Threats andCountermeasureshttp://www.microsoft.com/downloads/details.aspx?familyid=

E9C4BFAA-AF88-4AA5-88D4-0DEA898C31B9&displaylang=en Hay mas...

61

Algunas listas de correo

I Secure Coding http://www.securecoding.org/list/

I WEB APPLICATION SECURITYhttp://www.securityfocus.com/archive/107

I SECPROG http://www.securityfocus.com/archive/98

I Web Security http://webappsec.org/lists/

I Listas de OWASPhttp://lists.owasp.org/mailman/listinfo

I HACK http://mailman.argo.es/listinfo/hacking

62