Bughunting. Carlos Sarraute Ezequiel Gutesman Core Security Technologies 5 mayo Facultad de Informatica - UNLP

Transcripción

1 Bughunting Carlos Sarraute Ezequiel Gutesman Core Security Technologies 5 mayo 2006 Facultad de Informatica - UNLP

2

3 Introducción

4 Preguntas motivadoras Porque buscamos fallas de seguridad? Que es la seguridad? Que son las vulnerabilidades? Como se descubren? Que pasa con las fallas encontradas?

5 La seguridad no existe Acotemos la pregunta a la seguridad de un sistema de encripción Que quiere decir un sistema de encripción sea perfectamente seguro? Respuesta de Claude Shannon en 1949 Communication Theory of Secrecy Systems define lo que llama perfect secrecy

6 Sistema de encripción P = espacio de textos planos C = espacio de textos cifrados K = espacio de claves { E k : k K } = funciones de encripción { D k : k K } = funciones de desencripción

7 Sistema de encripción simétrico Alice y Bob intercambian una clave k usando un canal seguro Alice y Bob se comunican por un canal inseguro Alice calcula c = E k (p) Se lo manda a Bob Bob calcula p = D k (c) Se cumple D k ( E k (p) ) = p Distribución de probabilidades en los espacios P y K Pr(p), Pr(k) suponemos Pr(p) > 0 para todo p P

8 Secreto perfecto o secreto de Shannon Para todo p P y para todo c C Pr( p c ) = Pr( p ) Teorema: la cota de Shannon (1949) Si un sistema mantiene el secreto perfecto entonces K P Demostración por el absurdo. Fijamos un c C. Sup que existe p 0 P tal que para toda k K, p 0 D k (c) Entonces Pr( p 0 c ) = 0 < Pr( p 0 ) Luego para toda p P, existe k K tal que p = D k (c)

9 El One-time Pad Conclusión: la clave tiene que ser por lo menos tan larga como el mensaje Existe un sistema de encripcion asi: c = p k p = c k No sirve en la práctica aunque se usó durante la guerra fría que ataques se les ocurre?

10 Que es la seguridad? La seguridad no es un estado, es un proceso Es el proceso de construir sistemas menos inseguros con menos vulnerabilidades La busqueda de vulnerabilidades es un elemento clave de ese proceso La seguridad es un arte de lo particular empieza en los limites de los modelos generales

11 Vulnerabilidades en binarios

12 Un koan informatico void youwin(int x, char *s) { volatile char a; char buf[20]; a = x; strcpy(buf, s); a -= x; } if (a == 4) printf("you win!\n");

13 Registros y memoria eip Instruction pointer esp stack pointer ebp frame pointer 0x x0012ffff 0x stack code Local vars Parameters Framepointers Ret address Exe Code Dll Code General Purpose 0x0040a000 data bss Globals dtors jumptables flags heap Dynamic data Dyn objects mallocs

14 Disposición del stack (pila) void youwin(int x, char *s) { volatile char a; char buf[20]; buf stackptr a = x; strcpy(buf, s); a -= x; if (a == 4) printf("you win!\n"); } memory a main s frameptr retaddr youwin() stack void main() { int loc1,loc2,loc3; youwin.arguments main() youwin(101, hola ); } main.locals saved frameptr

15 Buffer Overflow void youwin(int x, char *s) { volatile char a; char buf[20]; buf stackptr a = x; strcpy(buf, s); a -= x; if (a == 4) printf("you win!\n"); } memory a main s frameptr retaddr youwin() stack void main() { int loc1,loc2,loc3; youwin.arguments main() youwin(93, aaaaaaaaaaaaaaaaaaaaaaaa ); } main.locals saved frameptr

16 Qué es una vulnerabilidad? Informalmente: No es un error, es un feature escondido opción de menú escondida Exploits: método o programa para sacar provecho de uno de estos features El buffer overflow es el ejemplo paradigmático veamos un caso donde explotamos la vulnerabilidad

17 Aplicación que vamos a atacar Autoreply Algo así como vacation en Unix. Procesa mails y genera respuestas enlatadas Target Machine mail.txt secret.txt autoreply Atacante Tiene acceso remote a la aplicación Control sobre los parametros y subject (del original) From: abc@zzzz.com Subject: pregunta To: abc@zzzz.com Subject: Re: pregunta Lo lamento pero Objetivos del ataque Acceder a recursos de la maquina donde se ejecuta autoreply Atacante

18 autoreply.c void printmail(char *fname) { FILE *f; char buf[100]; } From: abc@zzzz.com Subject: pregunta void autoreply(char *subject, char * , char *mailfile) { char buf[40]; printmail(mailfile); } To: abc@zzzz.com Subject: Re: pregunta Lo lamento pero int main(int argc, char *argv[]) { char * , *subject; autoreply(subject, , argv[1]); } = abc@zzzz.com subject = pregunta argv[1] = mail.txt

19 El Stack de autoreply void printmail(char *fname) { FILE *f; char buf[100]; } void autoreply(char *subject, char * , char *mailfile) { char buf[40]; printmail(mailfile); } memory int main(int argc, char *argv[]) { char * , *subject; autoreply(subject, , argv[1]); } eip subject frameptr stackptr main()

20 El Stack de autoreply void printmail(char *fname) { FILE *f; char buf[100]; } void autoreply(char *subject, char * , char *mailfile) { char buf[40]; printmail(mailfile); } eip memory retaddr autoreply() stackptr subject int main(int argc, char *argv[]) { char * , *subject; autoreply(subject, , argv[1]); } mailfile subject main() frameptr

21 El Stack de autoreply void printmail(char *fname) { FILE *f; char buf[100]; } void autoreply(char *subject, char * , char *mailfile) { char buf[40]; printmail(mailfile); } int main(int argc, char *argv[]) { char * , *subject; autoreply(subject, , argv[1]); } eip memory buf[] frameptr retaddr subject mailfile subject frameptr stackptr autoreply() main()

22 El Stack de autoreply void printmail(char *fname) { FILE *f; char buf[100]; } eip buf[] f frameptr stackptr printmail() void autoreply(char *subject, char * , char *mailfile) { char buf[40]; printmail(mailfile); } memory retaddr autoreply fname buf[] frameptr retaddr autoreply() int main(int argc, char *argv[]) { char * , *subject; autoreply(subject, , argv[1]); } subject mailfile subject main() frameptr

23 Overflow en autoreply() void printmail(char *fname) { FILE *f; char buf[100]; } void autoreply(char *subject, char * , char *mailfile) { char buf[40]; sprintf(buf, "re: %s", subject); } int main(int argc, char *argv[]) { char * , *subject; autoreply(subject, , argv[1]); } eip memory buf[] frameptr retaddr subject mailfile subject frameptr stackptr autoreply() main()

24 Un ejemplo de exploit void printmail(char *fname) { FILE *f; char buf[100]; } void autoreply(char *subject, char * , char *mailfile) { char buf[40]; sprintf(buf, "re: %s", subject); } int main(int argc, char *argv[]) { char * , *subject; autoreply(subject, , argv[1]); } eip memory buf[] frameptr printmail subject mailfile subject frameptr stackptr autoreply() main()

25 Un ejemplo de exploit void printmail(char *fname) { FILE *f; char buf[100]; } eip void autoreply(char *subject, char * , char *mailfile) { char buf[40]; sprintf(buf, "re: %s", subject); } memory buf[] f printmail() printmail frameptr int main(int argc, char *argv[]) { char * , *subject; autoreply(subject, , argv[1]); } retaddr subject = subject fname = mailfile subject main() frameptr

26 Usando shellcode void printmail(char *fname) { FILE *f; char buf[100]; } void autoreply(char *subject, char * , char *mailfile) { char buf[40]; sprintf(buf, "re: %s", subject); } int main(int argc, char *argv[]) { char * , *subject; autoreply(subject, , argv[1]); } eip memory shellcode buf[] frameptr &buf subject mailfile subject frameptr stackptr shellcode() main()

27 Vulnerabilidades en aplicaciones web

28 Web Applications Las aplicaciones web estan estructuradas de manera diferente a los programas desarrollados para desktop. Ejecución cliente / servidor. Algunos módulos se ejecutan en el web server (cgi, asp, php, java,.net), otros del lado del cliente (javascript, Java applets etc.). Las vulnerabilidades cambian, los escenarios cambian, los vectores de ataque cambian.

29 Web Applications Vulnerabilidades, introducción Capas HTTP Cliente Transporte Firewall Web server Web app CGI's / API's Firewall Servidor de BD XSS, spoofing Peligros Man-in-the-middle, session hijacking Permisión de http/https Buffer overflow, format string, directory traversal, cuentas por default, shell injection. Metacaracteres, caracteres \x00, buffer overflow. Red interna SQL Injection, Queries restringidas

30 Factores a tener en cuenta Cada vez es más fácil desarrollar aplicaciones web. Los lenguajes emergentes permiten un desarrollo más rápido y un nivel de experiencia menor por parte de los desarrolladores. Los desarrolladores recién iniciados, no tienen en cuenta aspectos de seguridad. Su enfoque se centra en la funcionalidad. Cometen errores involuntarios, que comprometen a la aplicación desde el punto de vista de la seguridad de la información.

31 Cualidades de las vulnerabilidades Generalmente, las vulnerabilidades se producen por el mal uso de un lenguaje, o de segundos lenguajes que son utilizados desde la aplicación web (ej: SQL, shell) Son explotadas, en general, con inputs mal formados, pudiendo provenir estos de un usuario conocido o no. Muchas veces, a pesar de tener en cuenta factores de riesgo, los programadores se confían de las herramientas que proveen los diferentes lenguajes para la sanitización de los datos, sin saber que estas también pueden ayudar a que los ataques se produzcan.

32 Vulnerabilidades SQL-Injection: Se manipulan los datos que puede ingresar un potencial atacante (cualquier usuario) haciendo uso de las vías de comunicación normales entre el usuario y la aplicación (formularios, cookies, certificados, etc...) SQL es un lenguaje de consultas para interactuar con motores de base de datos (BD). Es un estándar utilizado en casi todos los lenguajes de programación (en algunos casos las técnicas para la conexión con un motor de BD varían, pero las vulnerabilidades siguen presentes). Se produce por la mala sanitización del input del usuario y de su uso para la realización de consultas en lenguaje SQL.

33 Ejecución de un programa cliente-servidor en PHP Usuario: Contraseña: manolo **************** Formulario en una página web (cliente) POST/GET Internet Web Server

34 Ejemplo: dentro del web server... Archivo.php <?php... $username $password = $_POST[ username ]; = $_POST[ pass ]; $query = select * from users where username='. $username. ' and password ='. $password. ' ; $result = mysql_query($query);?> if (mysql_num_rows($result)) { echo Bienvenido! ; }else{ echo Usuario o contraseña inválidos ; }

35 Ejemplo: dentro del web server... (II) Archivo.php Consulta (1) BD HTML Output (2) Se ejecuta la siguiente consulta: select * from users where username='manolo' and password ='unapass' Input ingresado por el usuario El motor de BD devuelve el resultado al script y luego de procesarlo, devuelve un resultado al usuario que envió los datos.

36 Pero... qué problema hay con eso? El usuario podría, por ejemplo, llamarse... Usuario: Contraseña: manolo' 1 = 1; -- **************** Haciendo que la consulta anterior se transforme en... select * from users where username='manolo' 1 = 1; --' and password ='unapass' Coloreando... los guiones comentan el resto de la consulta select * from users where username='manolo' 1 = 1; --' and password ='unapass'

37 Pero... qué problema hay con eso? (II) Esa consulta devuelve a todos los usuarios, ya que la condición de la clausula WHERE es siempre verdadera. Dónde está el problema? $username = $_POST[ username ]; $pass = $_POST[ pass ]; $query = select * from users where username='. $username. ' and password ='. $password. ' ; Los datos obtenidos del $_POST no son sanitizados correctamente.

38 Peligros Un atacante podría ser mas malicioso, y en lugar de sólo autenticarse sin credenciales podría... select * from users where username='manolo'; drop table users; --' and password ='unapass' select * from users where username='manolo'; update users set password = 'a'; --' and password ='unapass' etc...

39 Otros tipos de ataque Cross Site scripting (XSS): Se produce cuando el ataque es, de alguna manera, indirecto. Impacta al usuario final directamente en su browser. En un formulario de registración, nos registramos... Usuario*: Contraseña*: <script language= javascript >... </script> **************** Cuando por ejemplo, se imprima una lista de usuarios (en algún módulo de administración) va a producirse el ataque, ejecutando en el browser del cliente, todo lo que se encuentra entre los tags <script> y </script>.

40 Otros tipos de ataque Shell command injection Se producen cuando se utilizan utilidades del sistema operativo subyacente. Los lenguajes de programación proveen funciones que permiten interactuar directamente con el shell. En el caso de PHP la función passthru(). El método de explotación es el mismo que para los injections de SQL.

41 Otros tipos de ataque Directory Traversal Malas configuraciones en el servidor web pueden, por ejemplo, permitir la manipulación de la url para la lectura de toda la estructura de directorios. Incluso al permitir que los usuarios suban archivos propios al web server (cv's, imagenes, papers, etc.) si el nombre del file no se encuentra bien validado, puede derivar en la posibilidad de escribir CUALQUIER archivo en CUALQUIER directorio del filesystem (incluso, scripts PHP ;) )

42 Otros tipos de ataque Parameter tampering De alguna manera se llegan a manipular los parámetros con los cuales son construidas las url's, o se logra modificar el valor de algún input box de tipo hidden. Sin los chequeos adecuados, modificando los valores de los parámetros, un atacante podría causar errores en la ejecución del script o bien obtener datos de otros usuarios.

43 Otros tipos de ataque Cookie poisoning Se produce cuando un usuario manipula las cookies (files guardados por una aplicación web en la máquina local del cliente) permitiendose a si mismo, realizar operaciones que no debería, o bien, autenticarse ante una página como otro usuario. Otros: Session Hijacking, improper error handling, DoS, también buffer overflows, etc.

44 Cómo detectarlos? Auditoría de código Siempre es la opción que más recursos demanda. Los auditores deben ser experimentados Demanda mucho tiempo de alta concentración Black box testing Es el más común dada una aplicación web, sin disponibilidad del código fuente tecnologías subyacentes Desconocimiento del objetivo» Fuzzing» Manipulación de parámetros / inputs

45 Prevención Best practices Utilizar técnicas y conocimientos de programación segura. Desconfiar siempre del input del usuario. Conocer las vulnerabilidades y sus impactos. Conocer las tecnologías y sus capacidades / falencias. Guiar a los nuevos programadores. Separación en capas de la aplicación (típicamente): Presentación Negocios Datos

46 Prevención Separación física de componentes del sistema: Web server Database server Certificados Certificados otorgados por entidades reconocidas como autoridad por el usuario. Conexiones seguras (SSL,TLS) Prestar atención!

47 En resumen

48 Como se descubren vulnerabilidades? El atacante / investigador / consultor descubre vulnerabilidades: Buscando patrones comunes vulnerables por azar: un blue screen es un accidente feliz... Transpolando una nueva vulnerabilidad desde otra aplicación Nuevos técnicas, nuevas ideas (inspiración) Manipulando las posibles entradas del programa examinado

49 Auditoría de código Con acceso al código fuente RTFS = read the fine source buscar patrones de vulns conocidas hacer una búsqueda exhaustiva del código por patrones sospechosos requiere mucho tiempo y esfuerzo

50 Reverse Engineering Sin acceso al código fuente ingeniería inversa para entender como funciona (si esta disponible el binario) Herramientas Desensambladores como el IDA (interactive dis-assembler)» requiere mucho tiempo y esfuerzo Debuggers» seguir la ejecución paso a paso

51 Fuzzear fuerza bruta dar input al azar ó con forma sospechosa un fuzzer es una herramienta diseñada especialmente para eso

52 Black Box testing Web server mandarle requests malformados basandose en bugs de seguridad conocidos Appliance de red Firmware en un artefacto tamper resistant

53 El proceso de reporte

54 Proceso de reporte de vulnerabilidades actores del proceso Investigadores que descubren la vulnerabilidad Los autores del software vulnerable Centro de coordinación como el CERT Usuarios Descubrimiento Investigación y Documentación Notificación Desarrollo de la solución Lanzamiento

55 Características del proceso Respuesta del fabricante antes era más lenta y aleatoria ahora los vendedores importantes tienen un departamento que se ocupa de responder a los reportes de vulns fabrica un patch (remedio a la vulnerabilidad) independiente ó integrado a una nueva versión Respuesta del usuario Antes no había procesos automáticos de actualización El impacto y alcance del problema influye en la urgencia definida entre el fabricante y el investigador, y asumida por los usuarios Descubrimiento Investigación y Documentación Notificación Desarrollo del patch Lanzamiento

56 Ejemplos de la vida real En nuestro laboratorio venimos haciendo investigacion en seguridad desde advisories publicados por Core Dos casos de vulnerabilidades que descubrimos: ejemplo 1: Active Directory ejemplo 2: Snort

57 Ejemplo 1: vulnerabilidad en Active Directory Active Directory es un componente esencial de Windows 2000 Server y siguientes permite a las organizaciones administrar y compartir recursos en una red, actuando como autoridad central de la seguridad de la red El problema descubierto: pedido con mas de 1000 operaciones AND causa un Stack Overflow en el servicio Y provoca un crash del servidor (denial of service)

58 Active Directory: cronograma de comunicaciones CORE notifica a Microsoft Microsoft notifica CORE de que el problema está resuelto en SP lanzamiento de Windows 2000 Service Pack se publica nuestro advisory probamos el exploit desarrollado en nuestro laboratorio (para win2000 sp3) con el service pack 4 resultado: es vulnerable!!

59 Active Directory: cronograma CORE notifica Microsoft de que la vulnerabilidad no está arreglada Microsoft publica Microsoft Security Bulletin MS La vulnerabilidad arreglada en SP4 era para pedidos de tipo: AND (cond1) (cond2) (cond3)... La vulnerabilidad que habíamos encontrado era para pedidos del tipo: AND (AND (AND (cond1) (cond2)) (cond3)) (cond4)...

60 Active Directory: conclusión al no tener acceso al código fuente, los investigadores no pueden determinar exactamente donde está el problema descubren síntomas, no necesariamente la causa los ingenieros del fabricante arreglan los síntomas que les reportaron Los investigadores no tuvieron acceso a la solución antes de la publicación El valor de un exploit: nos dimos cuenta del problema porque teníamos forma de explotar realmente la vulnerabilidad

61 Ejemplo 2: vulnerabilidad en Snort Snort es un IDS (intrusion detection system) muy popular, open source detecta cientos de ataques analizando los paquetes que recibe y aplicando un conjunto de reglas de pattern matching encontramos un heap overflow mandando trafico malicioso en una red donde está Snort corriendo se puede explotar y ejecutar comandos arbitrarios en la máquina que corre Snort

62 Snort: la vulnerabilidad if( (spd->seq_num + spd->payload_size) <= s->last_ack ) offset = spd->seq_num - s->base_seq (offset = 0xffdc) memcpy(buf + offset, spd->payload, spd->payload_size) detección precisa de donde ocurre la vulnerabilidad y bajo que condiciones Core notifica a los autores de Snort Publicación del patch y del advisory

63 Snort: conclusión Validamos el patch previo a su publicación (código fuente) las nuevas vulnerabilidades en aplicaciones open source son cada vez más dificiles de encontrar y explotar posteriormente, los autores de Snort nos pidieron una auditoría del código fuente de Snort

64 De la vulnerabilidad al ataque Severidad de la vulnerabilidad Complejidad de construcción del exploit en Linux, los exploits son cada vez mas complejos Precisión lograda Disponibilidad del ataque Acceso a los exploits Acceso a maquinas vulnerables Ventana de exposición

65 De la dificultad de reportar y corregir bugs un mismo error puede tener múltiples síntomas, dependiendo de los detalles del entorno y forma de operar del usuario es difícil para el programador reproducir las sutilezas del entorno en el cual el tester encontró el bug en el caso open source, el tester y el desarrollador pueden compartir su modelo mental del programa el tester encuentra la fuente del bug en el código, se puede eliminar de un golpe decenas de síntomas relacionados

66 C O R E S E C U R I T Y T E C H N O L O G I E S Carlos Sarraute carlos@coresecurity.com Ezequiel Gutesman ezequiel.gutesman@coresecurity.com