2000 << Back To criptograma nº 23

-----BEGIN PGP SIGNED MESSAGE----- _______________________________________________________________ C R I P T O G R A M A _______________________________________________________________ N·mero 23 15 de Marzo del 2000 ________________________________________________________________ SUMARIO: 1. Kerberos y Windows 2000. 2. Counterpane: investigaci≤n documentada. 3. Noticias. 4. Novedades AES. 5. Noticias de Counterpane. 6. El software como herramienta para robar. 7. En la ratonera: Asamblea de Virginia. 8. Complejidad del software y seguridad. 9. Comentarios de los lectores -- Ejemplar gratuito distribuido a mßs de 19.000 suscriptores -- ________________________________________________________________ * Suscripci≤n gratuita: http://www.kriptopolis.com/subs.html * N·meros anteriores: http://www.kriptopolis.com/criptograma/cg.html _______________________________________________________________ 1. Kerberos y Windows 2000 ================================================= Por Bruce Schneier Traducci≤n: Sergio Pozo Hidalgo http://www.kriptopolis.com/criptograma/0023_1.html Kerberos es un dise±o de autenticaci≤n basado en clave simΘtrica. Fue desarrollado en el MIT (n. del t.: Massachussets Institute of Technology, Instituto de Tecnologφa de Massachussets) en los 80 como una parte de su Proyecto Athena -el protocolo fue publicado en Octubre de 1988- y ha sido implementado en varios tipos de UNIX. La versi≤n actual es Kerberos Versi≤n 5, que corrigi≤ algunas vulnerabilidades de seguridad de la Versi≤n 4. Nunca ha sido asumido por el mundo de la autenticaci≤n, pero es usado en varias redes. Hoy en dφa, el Internet Engineering Task Force (IETF) controla la especificaci≤n para Kerberos. Kerberos es un protocolo de autenticaci≤n cliente-servidor. ("Criptografφa Aplicada" revisa el protocolo en detalle.) Desde el punto de vista de este artφculo, recuerde que existe un servidor seguro de Kerberos en una red. Los clientes entran en el servidor de Kerberos y consiguen "tickets" seguros. A continuaci≤n pueden usar estos tickets para entrar en otros servidores en la red: servidores de ficheros, bases de datos, etc. Kerberos es ahora parte de Microsoft Windows 2000, mßs o menos. La cuesti≤n es que Microsoft ha realizado cambios sobre el protocolo para no hacerlo interoperativo con el estßndar Kerberos ni con ning·n producto que implemente Kerberos correctamente. Concretamente, la incompatibilidad tiene que ver con algo llamado "campo de autorizaci≤n de datos" en los mensajes de Kerberos. Todas las implementaciones importantes de Kerberos dejan el campo vacφo. La nueva implementaci≤n de Microsoft no, y usa el campo para intercambiar privilegios de acceso entre el Servidor de Kerberos y el cliente. Hay dos formas de contemplar esto: Como el campo no tiene usos especφficos en el protocolo (y nadie mßs lo usa), el hecho de que Microsoft estΘ usßndolo es inocuo. Ya que Microsoft reh·sa publicar detalles sobre su uso propietario del campo, estßn da±ando la interoperabilidad y estandarizaci≤n. Otros proveedores de Kerberos no pueden soportar Windows 2000 directamente. A·n peor, Microsoft se salt≤ al IETF en este proceso (existe un procedimiento que se supone que vas a seguir si quieres afinar, desviarte de, o modificar un estßndar IETF). Superficialmente, esto es una prßctica de empresa poco agradable. Si eres una compa±φa que ha invertido en un sistema de autenticaci≤n Kerberos basado en UNIX y quieres soportar sistemas Windows 2000, tu ·nica opci≤n real es comprar un servidor Kerberos de Windows 2000 y pagar por la integraci≤n. Estoy seguro de que esto es lo que quiere Microsoft. Mi preocupaci≤n se centra mßs en la seguridad. Los protocolos son muy frßgiles; hemos aprendido, una y otra vez, que no se puede hacer cambios a un protocolo de seguridad y dar por sentado que el protocolo modificado sea seguro. Microsoft se ha apropiado del protocolo Kerberos -un protocolo p·blico que ha estado sometido a escrutinio a lo largo de una dΘcada- y le ha hecho cambios que afectan a la seguridad. A·n peor, han realizado esos cambios en secreto y no han revelado esos detalles al mundo. Que no le enga±en. El Kerberos de Windows 2000 no es Kerberos. No se asemeja al estßndar Kerberos. Es como Θl, pero no sabemos cuan seguro es. Pßgina Web de Kerberos: http://www.isi.edu/gost/gost-group/products/kerberos/ Especificaci≤n IETF: ftp://ftp.isi.edu/in-notes/rfc1510.txt ftp://athena-dist.mit.edu/pub/kerberos/doc/techplan.txt Informaci≤n de Microsoft sobre Kerberos: Borrador sobre la autentificaci≤n de Kerberos en Windows 2000: http://www.microsoft.com/windows2000/library/howitworks/security/kerbe os.asp Introducci≤n a los servicios de seguridad de Windows 2000: http://www.microsoft.com/WINDOWS2000/guide/server/features/secintro.as Guφa sobre la interoperabilidad de Kerberos: http://www.microsoft.com/windows2000/library/planning/security/kerbste s.asp Artφculo de David Chappell sobre Kerberos y Windows 2000: http://www.microsoft.com/msj/defaulttop.asp?page=/msj/0899/kerberos/ke berostop.htm 2. Counterpane: investigaci≤n documentada ================================================= Por Bruce Schneier Traducci≤n: Sergio Pozo Hidalgo http://www.kriptopolis.com/criptograma/0023_2.html "Una comparaci≤n del rendimiento de los cinco finalistas AES" (B. Schneier y D. Whiting, Tercera Conferencia de Candidatos de AES, 2000, por aparecer). En 1997, el NIST anunci≤ un programa para desarrollar y escoger un Estßndar Avanzado de Cifrado (n. del t.: Advanced Encryption Standard - -- AES) para reemplazar al envejecido Estßndar de Cifrado de Datos (n. del t.: Data Encryption Standard -- DES). El NIST escogi≤ a cinco finalistas en 1999. Comparamos el rendimiento de los cinco finalistas AES en una diversidad de plataformas software corrientes: CPUs de 32-bit actuales (tanto procesadores grandes como mßs peque±os, tarjetas inteligentes y microprocesadores empotrados) y CPUs de altas prestaciones de 64-bit. Nuestro objetivo es ense±ar a grandes rasgos c≤mo la velocidad de los algoritmos se equipara a travΘs de una diversidad de CPUs. DespuΘs, proporcionamos los ciclos mßximos criptoanalizados para cada uno de los algoritmos, y reexaminamos todas las cifras de rendimiento para estas variantes. Luego comparamos los algoritmos otra vez, usando las mφnimas variantes seguras como un modo de perfilar con mßs imparcialidad la seguridad de los cinco algoritmos. http://www.counterpane.com/aes-comparison.html 3. Noticias ================================================= Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mßs http://www.kriptopolis.com/criptograma/0023_3.html Mßs comentarios sobre si es Θtico hacer p·blicas vulnerabilidades: http://boardwatch.internet.com/mag/99/oct/bwm62.html http://cgi.zdnet.com/slink?22157:8469234 Una opini≤n sobre los ataques DDS y el fiasco de CD Universe: http://www.osopinion.com/Opinions/GaryMurphy/GaryMurphy7.html Hay un nuevo estßndar DSS: Texto: http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=2000_registe &doc id=00-3450-filed PDF: http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=2000_registe &docid=00-3450-filed.pdf BAIT, DIRT, y otras herramientas hackers empleadas para las investigaciones policiales. Parte del asunto suena demasiado bien como para ser cierto. http://www.codexdatasystems.com/ Inseguridad de los Bloques H&R: http://news.cnet.com/news/0-1005-200-1550948.html? tag=st.ne.1002.tgif?st.nefd.gif.d El peor producto de seguridad es el que no se usa. Estos son los resultados de un estudio sobre uso de PGP. La mayorφa de la gente no puede entender c≤mo usarlo. Algunas personas enviaban mensajes de correo electr≤nico sin cifrar, creyendo que era algo seguro. http://www.wired.com/news/news/business/story/21484.html http://www.cs.cmu.edu/~alma/johnny.pdf Novell public≤ un "agujero de seguridad en los Servicios de Directorio Activo de Microsoft" el dφa antes del lanzamiento de Windows 2000. Microsoft public≤ una respuesta poco despuΘs. Ambos documentos estßn repletos de las tφpicas frases de marketing. Russ Cooper ha escrito una descripci≤n objetiva de este asunto inexistente: http://ntbugtraq.ntadvice.com/NDSvsADS-01.asp Buen software de seguridad: una herramienta de lφnea de comandos que permite analizar c≤digo fuente de C y C++ en busca de vulnerabilidades de seguridad. Se llama ITS4. http://www.rstcorp.com/its4/ Documento de Mixter sobre el cracking: http://mixter.void.ru/crack.txt Excelente ensayo sobre la diferencia entre hackers y vßndalos: http://www.villagevoice.com/issues/0007/thieme.shtml Comentarios sobre los ataques de denegaci≤n de servicio distribuidos: http://www.pbs.org/cringely/pulpit/pulpit20000217.html http://www.thenation.com/issue/000313/0313klein.shtml Nombres de usuario y passwords a la venta: http://www.wired.com/news/politics/0,1283,34515,00.html?tw=wn20000224 Se ha parado la exportaci≤n de Jap≤n de la PlayStation 2 de Sony debido a la tecnologφa criptogrßfica que incluye el sistema: http://www.theregister.co.uk/000302-000026.html Se ha fabricado un mu±eco que representa a los soldados navajos americanos de la Segunda Guerra Mundial encargados del cifrado de las comunicaciones militares con su idioma: http://www.gijoe.com/lnavajo_code_talker.html Mßs especulaciones sobre Echelon: http://www.zdnet.com/enterprise/stories/security/news/0,7922,2455560,0 .html http://www.wired.com/news/politics/0,1283,34932,00.html Uso interesante de una trampa para hackers del Centro de Supercomputaci≤n de San Diego (o el SDSC jaquea a los hackers): http://security.sdsc.edu/incidents/worm.2000.01.18.shtml 4. Novedades AES ================================================= Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mßs http://www.kriptopolis.com/criptograma/0023_4.html Las grandes noticias sobre AES tendrßn lugar en la semana del 10 al 14 de abril del 2000 en Nueva York. El lunes, martes y miΘrcoles tendrß lugar el 7║ taller de Cifrado Rßpido por Software (FSE 2000). El jueves y el viernes se celebrarß la 3¬ Conferencia de Candidatos al AES (AES3). Ambos actos serßn en el Hilton and Towers de Nueva York. En el FSE 2000 se incluirßn varios excelentes documentos sobre los candidatos al AES (nuevos ataques a MARS, RC6, Rijndael y Serpent), y en cambio no en la AES3. Se han seleccionado los documentos del FSE 2000 y estßn listados en el web indicado mßs abajo. A·n no se han anunciado cußles serßn los documentos que se presentarßn en la AES3. (Se pas≤ hace tiempo el plazo de presentaci≤n para ambas conferencias). Vengan, sean parte de la Historia de la Criptografφa. Serß divertido. FSE 2000: http://www.counterpane.com/fse.html AES3: http://csrc.nist.gov/encryption/aes/round2/conf3/aes3conf.htm 5. Noticias de Counterpane ================================================= Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mßs http://www.kriptopolis.com/criptograma/0023_5.html Se entrevist≤ a Bruce Schneier en Business Week: http://www.businessweek.com/2000/00_10/b3671089.htm 6. El software como herramienta para robar ================================================= Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mßs http://www.kriptopolis.com/criptograma/0023_6.html Esto es extra±o. Se acus≤ a dos personas de Minneapolis que supuestamente robaron informaci≤n de sus empleados de tener una "herramienta de robo", L0phtcrack, el programa que averigua automßticamente contrase±as de Windows. No se ven claras las ramificaciones del asunto. Hay ciertas herramientas empleadas en robos que no se pueden llevar encima salvo que se sea un profesional con licencia (por ejemplo, ciertas herramientas usadas para forzar cerraduras); el simple hecho de tenerlas es ilegal. Pero los destornilladores y los alicates tambiΘn pueden ser herramientas de robo si se usan con la intenci≤n de cometer un delito. Lo que para mφ significa es que las leyes se estßn tomando esto en serio. http://www.channel4000.com/news/stories/news-20000217-164727.html?&_re =1005006010 7. En la ratonera: Asamblea Legislativa de Virginia ==================================================== Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mßs http://www.kriptopolis.com/criptograma/0023_7.html Recientemente aprobaron la Ley de Transacciones Uniformes de Informaci≤n en Ordenadores (UCITA). Es preocupante. Se podrφa subtitular "La Lista de Deseos de la Industria del Software" debido a la cantidad de control que se da POR LEY a los distribuidores de software (sin que tengan que dar cuentas de ello). Bajo la UCITA, Microsoft no s≤lo no tiene que corregir ni uno de los 63.000 bugs de Windows 2000, ni siquiera tendrφa por quΘ decir que los hay. TambiΘn podrφa desabilitar el sistema operativo de cualquiera que quisiera por prßcticamente cualquier raz≤n que se les ocurriera (por ejemplo, un incumplimiento de los tΘrminos de licencia que restringen que se mencionen p·blicamente bugs aparentes del software). El gobernador a·n no ha firmado la ley, pero se espera que lo haga. http://www.lawnewsnetwork.com/practice/techlaw/news/A16380-2000Feb16.h ml http://www4.zdnet.com:80/intweek/stories/news/0,4164,2436874,00.html http://www.computerworld.com/home/print.nsf/CWFlash/000215ECDA http://www.cnn.com/2000/TECH/computing/03/07/ucita.idg/index.html 8. Complejidad del software y seguridad ==================================================== Por Bruce Schneier Traducci≤n: Isidre Marques Serret http://www.kriptopolis.com/criptograma/0023_8.html El futuro de los sistemas digitales estß en la complejidad, y la complejidad es el peor enemigo de la seguridad. La tecnologφa digital ha sido una serie inacabable de innovaciones, consecuencias imprevistas, y sorpresas, y no hay ninguna raz≤n para creer que esto se detenga en cualquier futuro pr≤ximo. Pero hay una cosa que se ha mantenido constante a travΘs de todo este tiempo, y es que los sistemas digitales se han vuelto cada vez mßs complejos. Lo hemos visto durante los ·ltimos a±os. Los microprocesadores se han vuelto mßs complejos. Los sistemas operativos se han vuelto mßs complejos. Los ordenadores se han vuelto mßs complejos. Las redes se han vuelto mßs complejas. Las redes individuales se han combinado y han aumentado todavφa mßs su complejidad. Lo he dicho antes, pero merece la pena repetirlo: Internet es probablemente la mßquina mßs compleja que la humanidad ha construido jamßs. Y no se volverß mßs simple en un futuro pr≤ximo. Como consumidor, pienso que esta complejidad es magnφfica. Hay mßs posibilidades de elegir, mßs opciones, mßs cosas que se pueden hacer. Como profesional de la seguridad, pienso que es aterrador. La complejidad es el peor enemigo de la seguridad. Esto ha sido verdad desde el principio de los ordenadores, y probablemente serß verdad en un futuro previsible. Y mientras el ciberespacio siga volviΘndose mßs complejo, seguirß volviΘndose menos seguro. Hay varias razones por las que esto es verdad. La primera raz≤n es el n·mero de fallos de seguridad. Todo software contiene fallos. Y cuando la complejidad del software aumenta, el n·mero de fallos tambiΘn lo hace. Y un porcentaje de estos fallos afectarß a la seguridad. La segunda raz≤n es la modularidad de los sistemas complejos. Los sistemas complejos son necesariamente modulares; no hay otra forma de manejar su complejidad que reduciΘndola a m≤dulos manejables. Nunca podrφamos haber creado una Internet tan compleja e interesante como es hoy sin la modularidad. Pero el aumento de la modulardad significa que la seguridad disminuye, porque la seguridad falla a menudo donde dos m≤dulos se comunican. Ya hemos visto ejemplos de esto al conectarse cada dφa mßs aparatos a Internet. Durante a±os supimos que las aplicaciones de Internet como el sendmail y rlogin tenφan que ser seguras, pero la reciente epidemia de virus de macro demuestra que Microsoft Word y Excel tambiΘn han de ser seguros. Los applets de Java no s≤lo necesitan ser seguros para los usos a que estßn destinados, tambiΘn deben ser seguros para cualquier otro uso que un asaltante pueda intentar darles. Las fotocopiadoras, las conexiones de mantenimiento en los routers, las unidades de almacenamiento masivo: todos pueden tener acceso a y desde Internet, con los riesgos de seguridad asociados. Los controladores inadecuados pueden comprometer la seguridad de Windows NT. Los adjuntos da±inos en un correo electr≤nico pueden atravesar los cortafuegos. Las comodidades ofrecidas en Microsoft Outlook pueden comprometer la seguridad. La tercera raz≤n es el aumento de los requisitos de pruebas para los sistemas complejos. He hablado en otra parte sobre la seguridad y la comprobaci≤n de errores. La ·nica manera razonable de probar la seguridad de un sistema es realizar evaluaciones de seguridad en Θl. Sin embargo, cuanto mßs complejo es el sistema, mßs dura se vuelve la evaluaci≤n de su seguridad. Un sistema mßs complejo tendrß mßs errores relacionados con la seguridad en su anßlisis, dise±o y programaci≤n. Y desgraciadamente, el n·mero de errores y la dificultad de evaluaci≤n no crece de acuerdo con la complejidad, crece mucho mßs rßpido. Para simplificar, asumamos que el sistema tiene diez opciones diferentes, cada una con dos posibles alternativas. Entonces hay 45 pares diferentes de alternativas que podrφan interactuar de maneras inesperadas, y 1024 configuraciones diferentes en total. Cada posible interacci≤n puede llevar a una debilidad de seguridad, y debe probarse explφcitamente. Ahora, asumamos que el sistema tiene veinte opciones diferentes. Esto significa 190 pares diferentes de alternativas y en torno a un mill≤n de configuraciones diferentes. Treinta opciones diferentes significan 435 pares diferentes y unos mil millones de configuraciones diferentes. Incluso aumentos ligeros en la complejidad de los sistemas significan una explosi≤n en el n·mero de configuraciones diferentes, cualquiera de las cuales podrφa esconder una debilidad de seguridad. El mayor n·mero de posibles interacciones crea mßs trabajo durante la evaluaci≤n de seguridad. Para un sistema con un n·mero moderado de opciones, verificar todas las interacciones de los pares de opciones es una cantidad ingente de trabajo. Verificar cada posible configuraci≤n es prßcticamente imposible. Asφ, tambiΘn la dificultad de realizar evaluaciones de seguridad crece muy rßpidamente con la creciente complejidad. La combinaci≤n de adicionales debilidades (potenciales) y un mßs difφcil anßlisis de seguridad inevitablemente lleva a sistemas mßs inseguros. La cuarta raz≤n es que cuanto mßs complejo es un sistema, mßs difφcil es de entender. Hay toda clase de puntos de vulnerabilidad -interface entre usuario y mßquina, interacciones del sistema- esto crece exponencialmente cuando no se puede mantener el sistema completo en la cabeza. La quinta (y ·ltima) raz≤n es la dificultad de anßlisis. Cuanto mßs complejo es un sistema, mßs duro es hacer este tipo de anßlisis. Todo es mßs complicado: su anßlisis, su dise±o, su programaci≤n y su uso. Y como hemos visto una y otra vez, todo es importante para el anßlisis de la seguridad. Un sistema mßs complejo pierde en todos los frentes. Contiene mßs debilidades para empezar, con su modularidad exacerba esas debilidades, es mßs difφcil de probar, es mßs difφcil de entender, y es mßs duro de analizar. Y a·n se pone peor: este aumento en el n·mero de debilidades de seguridad se relaciona destructivamente con la propiedad del eslab≤n mßs dΘbil de la seguridad: la seguridad del sistema global estß limitada por la seguridad de su eslab≤n mßs dΘbil. Cualquier simple debilidad puede destruir la seguridad de todo el sistema. Los sistemas reales no muestran ninguna se±al de volverse menos complejos. De hecho, estßn volviΘndose mßs y mßs complejos rßpidamente. Microsoft Windows es un claro ejemplo de esta tendencia a la complejidad. Windows 3.1, publicado en 1992, tenφa 3 millones de lφneas de c≤digo; Windows 95 tenia 15 millones y Windows 98 tiene 18 millones. Windows NT original (tambiΘn de 1992) tenφa 4 millones de lφneas de c≤digo; NT 4.0 (1996) tenia 16.5 millones. En 1998, a Windows NT 5.0 se le calcularon 20 millones de lφneas de c≤digo; cuando su nombre cambi≤ a Windows 2000 (en 1999) tenφa entre 35 y 60 millones de lφneas de c≤digo, seg·n a que fuentes creamos. (Como punto de comparaci≤n, Solaris se ha mantenido estable en aproximadamente 7 a 8 millones de lφneas de c≤digo en sus ·ltimas versiones, y Linux, incluso con la suma de X Windows y Apache, todavφa se mantiene por debajo de los 5 millones de lφneas de c≤digo.) El tama±o de Windows 2000 es absolutamente increφble, y tendrß mßs fallos de seguridad que Windows que NT 4.0 y Windows 98 juntos. En su defensa, Microsoft ha dicho que emple≤ 500 a±os-persona para hacerlo fiable. Indico este n·mero simplemente porque sirve para ilustrar que 500 a±os-persona son inadecuados. Las redes del futuro, necesariamente mßs complejas, serßn menos seguras. La industria de la tecnologφa estß impulsada por la demanda de mßs funcionalidades, mßs opciones, mßs velocidad. No hay ninguna norma para la calidad o la seguridad, y no se pueden exigir responsabilidades por el software inseguro. No hay ning·n incentivo econ≤mico para crear alta calidad. En cambio, hay incentivos econ≤micos para crear la mßs baja calidad que pueda soportar el mercado. Y a menos que los clientes exigen mejor calidad y mejor seguridad, esto nunca cambiarß. Veo dos alternativas. La primera es reconocer que el mundo digital tendrß cada vez mßs opciones y caracterφsticas, nuevas versiones cada menos tiempo y mayor complejidad, pero menos seguridad. ╔ste es el mundo que tenemos hoy, y podemos decidir aceptarlo a sabiendas. La otra opci≤n es reducir la velocidad, simplificar e intentar agregar seguridad. Los clientes no exigirßn esto -estos problemas son demasiado complejos para que los comprendan- para eso se requiere un grupo de defensa de los consumidores. Podemos imaginar fßcilmente una organizaci≤n similar a la FDA (Food and Drugs Agency, la agencia americana que aprueba los alimentos y medicamentos para su venta al p·blico) para Internet, pero para aprobar un nuevo medicamento para la venta pueden ser necesarios diez a±os, asφ que esta soluci≤n podrφa no ser econ≤micamente viable. Repito: la complejidad es el peor enemigo de la seguridad. Los sistemas seguros deben reducirse al mφnimo y deben hacerse tan simples como sea posible. No hay ning·n sustituto para la simplicidad. Desgraciadamente, la simplicidad va contra todo lo que se da por supuesto en nuestro futuro digital. 9. Comentarios de los lectores ==================================================== http://www.kriptopolis.com/criptograma/0023_9.html De: Shawn Hernan (svh@cert.org) Asunto: Revelaci≤n total - ---------------------------------------- Traducido por Juan Cruz Ruiz de Gauna Estoy intrigado por su reciente serie de editoriales en Crypto-Gram referentes al movimiento "revelaci≤n total" y, especialmente, en lo referente a CERT. Escribo para responder a su artφculo. Algunas de sus crφticas hacia CERT son vßlidas, y estoy de acuerdo con ellas; pero me gustarφa puntualizar un par de cosas de las que quizßs no se haya dado cuenta sobre nuestras prßcticas. Cuando decidimos quΘ publicar y cußndo, usamos una variedad de criterios diferentes. Primero, cualquier cosa que publiquemos debe ser *cierta*. Vamos hasta el extremo para validar y verificar cualquier cosa que publicamos, y puede suponer algunas de las discusiones que siguen a lo que es "cierto". Segundo, como una regla bßsica, nuestras advertencias se refieren generalmente a problemas muy serios. Tenemos una mΘtrica formal que usamos para intentar poner las vulnerabilidades en una escala lineal de "gravedad" y la usamos como una estimaci≤n de primer orden sobre la gravedad del problema, y usamos nuestra experiencia como factor final decisorio. Generalmente, los problemas publicados en consultorφas estßn en el percentil 90 de esta escala (internamente llamada la "mΘtrica de la amenaza"). Tercero, aunque ha podido ser cierto en el pasado, nunca ha sido el caso durante mi estancia aquφ (ahora mismo unos cuatro a±os) que la planificaci≤n de las publicaciones haya dependido totalmente (o en parte) de la disponibilidad de las soluciones. Ciertamente preferimos tener soluciones disponibles a la hora de la publicaci≤n, pero si descubrimos que una vulnerabilidad estß siendo explotada, la publicaremos sin tener en cuenta la disponibilidad de soluciones o parches. Mi equipo (el equipo de manejo de vulnerabilidades) trabaja diariamente muy pr≤ximo al equipo de respuesta a las incidencias para entender si una vulnerabilidad estß siendo explotada. Dando todas estas explicaciones, intento encontrar vφas responsables y prßcticas para publicar mßs informaci≤n acerca de vulnerabilidades de diversas maneras. Somos una organizaci≤n relativamente peque±a, y no estoy dispuesto a sacrificar la verdad por oportunismo. De: Ryan Russell (ryan@securityfocus.com) Asunto: Distribuyendo Exploits - -------------------------------------------- Traducido por Juan Cruz Ruiz de Gauna No resulta totalmente coherente en lo que dice: "Tercero, Yo creo que es irresponsable, y posiblemente criminal, distribuir exploits." Usted ya ha reconocido que esto es lo que consigue que se produzcan acciones. "La ingenierφa inversa de sistemas de seguridad, descubriendo vulnerabilidades, y escribiendo documentos de investigaci≤n acerca de ello beneficia a la investigaci≤n; esto nos hace mßs inteligentes a la hora de dise±ar sistemas seguros. Distribuir exploits s≤lo nos hace mßs vulnerables." Reconozca que su conducta es inconsistente con sus palabras, que se quedan a medio camino y no estßn ni en un lugar ni en otro. La reacci≤n no siempre se debe a un exploit, sino que a veces se debe a una nota de prensa. Thievco sac≤ un "exploit" para decodificar las contrase±as de Netscape hace un a±o y medio. Netscape no hizo nada. RTS. Corp. hizo lo mismo, junto con una nota de prensa. Esto si capt≤ la atenci≤n de Netscape. "Por ejemplo, Mixer es un hacker alemßn que escribi≤ la herramienta Tribal Flood Network (Inundaci≤n Tribal de Red) usada en alguno de los ataques de denegaci≤n de servicio. Yo creo que tiene mucho de lo que responder. Su ataque no sirvi≤ para nada bueno." No es cierto. De no haber sido por Θl, probablemente estarßamos viendo misteriosas herramientas que estarφan siendo usadas y de cuyo c≤digo fuente no dispondrφamos, y no podrφamos analizarlas fßcilmente. Mixer ha evitado mucha CONFUSION mostrßndonos exactamente el tipo de cosas que pueden usarse, de tal forma que los periodistas no pudieran salir corriendo a decirle al p·blico que los diab≤licos hackers disponen de superarmas de las que los expertos en seguridad no saben nada. Sirvi≤ a los criminales y cost≤ a un mont≤n de compa±φas mucho dinero. Su existencia hace las redes menos seguras. Tal y como dice, como cualquier herramienta, qued≤ disponible tanto para los buenos como para los malos. Tal y como habφa apuntado, el problema de seguridad ya estaba allφ, las herramientas no hicieron sino revelarlo. Permφtame hablar de la parte de su diatriba contra Mixter. Algunas personas piensan que Mixter merece alg·n castigo. Yo no, pero puedo entender algo de la l≤gica usada. Realmente a mφ me parece que si alguien merece un castigo son las personas que han usado la herramienta. ┐Hicieron Mixter e incluso los atacantes realmente algo dentro del espφritu del movimiento de revelaci≤n total?. Sφ. Nos hemos estado quejando durante a±os sobre el problema del spoofing, y hemos esperado que los ISPs (Proveedores de Servicios Internet) hiciesen el filtrado. No ha ocurrido nada. Mixter sac≤ su herramienta. Hubo algunos encuentros para discutir DDoS (Ataques distribuidos de denegaci≤n de servicio). No ha habido cambio en el comportamiento, pero hubo cierta cantidad de planes avanzados, lo que fue una buena preparaci≤n. Finalmente, alguna persona (sφ, criminal) se puso a ello y realmente us≤ la herramienta. No tiraron abajo la seguridad de los sitios para hacerlos parecer malos. No fueron detrßs del gobierno. Iban detrßs del comercio electr≤nico, que debo suponer que fue dise±ado para una reacci≤n mßxima. Supongo que ahora tendremos algo de acci≤n. De: Greg Guerin (glguerin@amug.org) Asunto: ┐Circulos en los ataques de publicidad? - ------------------------------------------------- Traducido por David G≤mez Tengo que admitir que estaba aguantßndome la risa todo el tiempo mientras leφa la carta de Fernandes/Cryptonym en el Criptograma de Febrero 2000. Especialmente cuando al final se cubre a sφ mismo con la mßscara de la integridad profesional. Ya he escrito dos artφculos sobre el descubrimiento de Fernandes y su ZIP de "reparaci≤n" disponible: http://amug.org/~glguerin/opinion/win-nsa-key.html http://amug.org/~glguerin/opinion/crypto-repair-kit.html Aunque ninguno de ellos es acerca de la integridad profesional de Fernandes, ambos mencionan unos cuantos puntos acerca de prßcticas especφficas. Para resumir los puntos (ver los artφculos para la explicaci≤n completa): 1) el ZIP contiene 2 EXE's, 2 DLL's y un fichero fuente. 2) el ZIP descargable no tiene firma digital. 3) nada dentro del ZIP tiene una firma digital por separado. 4) La clave PGP de Fernandes no tiene ning·n apoyo. 5) no se se±alan otros que puedan atestiguar los puntos 2 y 4. 6) el fuente no era compilable seg·n se proporcionaba (falta cabecera). El punto 6 s≤lo tiene un poco de importancia porque significa que se debe confiar en el EXE seg·n se da. Pero de todas maneras habφa s≤lo un fichero fuente, asφ que se confφa completamente en el otro EXE. Y se debe confiar en ambas DLL's completamente. Siendo prudente con los riesgos, confiar a ciegas en el 75% es virtualmente idΘntico a confiar ciegamente en el 100%, asi que no es ·til hacer la distinci≤n. Es como elegir si matar algo tres o cuatro veces; con matarlo una vez basta. Observe que en ning·n momento aparece la "integridad profesional", s≤lo "prßctica profesional". No estoy discutiendo la INTENCI╙N (integridad), s≤lo estoy describiendo el RESULTADO (prßctica). La integridad y la intenci≤n sin manchas no pueden sobrevivir a errores evitables por mucho tiempo en la prßctica. Observando prßcticas un observador puede deducir habilidad, integridad, o ambas, o ninguna. Esos juicios, y los criterios de fiabilidad que los subyacen, son dejados completamente al observador particular. Todo lo que puedo decir es lo que yo deducirφa de mis observaciones y porquΘ. Deberφais arrojar vuestras propias conclusiones, ya que mis criterios para la fiabilidad pueden diferir de los vuestros. Pero deberφais tambiΘn invertir tiempo en comprender porque llegßsteis a esas conclusiones; fallos en el proceso pueden llevaros por mal camino. De: "Rolf Oppliger" (rolf.oppliger@esecurity.ch) Asunto: Ataques de Denegaci≤n de Servicio distribuidos - --------------------------------------------------------- Traducido por David G≤mez Lo primero de todo, me gustarφa felicitarle por tu descripci≤n y anßlisis de los ataques de denegaci≤n de servicio distribuidos (DDoS) en el boletφn de Febrero de su publicaci≤n Criptograma. Estoy totalmente de acuerdo con la mayorφa de las declaraciones, incluyendo la visi≤n pesimista de que todas las aproximaciones para resolver el problema son insatisfactorias de una manera u otra. En su artφculo, sin embargo, tambiΘn discute que "a largo plazo, la se±alizaci≤n fuera de banda es la ·nica manera de enfrentarse con muchas de las vulnerabilidades de Internet, los ataques DDS entre ellos." No estoy de acuerdo con esta declaraci≤n. Cualquier canal de se±alizaci≤n fuera de banda puede tambiΘn estar sujeto a ataques de DoS y de DDoS. Creo que la raz≤n porque las redes telef≤nicas no estßn sujetas a ataques DoS y DDoS a gran escala es debido al hecho de que te cargan y facturan los gastos, mßs que su uso de la se±alizaci≤n fuera de banda (la se±alizaci≤n fuera de banda tiene muchas ventajas en otras ßreas). Intentar establecer una gran cantidad de conexiones en una red telef≤nica es simplemente demasiado caro... Creo que la lecci≤n aprendida de las redes telef≤nicas es que la carga y facturaci≤n basada en paquetes -combinados con adecuados mecanismos de seguridad- puede ser una soluci≤n viable para la protecci≤n contra ataques DoS y DDoS a larga escala en Internet (mßs que la se±alizaci≤n fuera de banda). Sin embargo, la carga y facturaci≤n basada en paquetes tambiΘn tiene muchas desventajas, incluyendo, por ejemplo, una enorme sobrecarga de administraci≤n. Consecuentemente, supongo que la carga y facturaci≤n basada en paquetes no sera aplicada a Internet, y que el "inteligente" filtrado de paquetes realizado por los ISP's serß la mayor arma para protegerse contra los ataques DoS y DDoS de gran escala en el futuro. De: Ethan Benatan (benatan@duq.edu) Asunto: Defensa contra los ataques DOS: secar los pantanos - ------------------------------------------------------------- Traducido por Oscar Esteban Si son bienvenidas las meditaciones de un bi≤logo, me gustarφa hacer un comentario sobre su analogφa del pantano. SΘ que nunca lo ha dicho asφ pero hay que apuntar que los pantanos no son "malos" en ning·n sentido defendible, ni secarlos es "bueno" incluso si hacerlo puede tener una consecuencia inmediata deseable. Estoy seguro de que en su propio campo se le ocurrirßn muchos ejemplos en los que un remedio, si bien efectivo, puede haber sido peor que la enfermedad. El RIESGO aquφ es olvidar que en cualquier sistema complejo los cambios se dan a un coste; cuanto mßs complejo (o menos comprendido) es el sistema, mßs difφcil es predecir el coste. Creo que esto es aplicable a Internet. Desde luego es aplicable en la naturaleza. No le aburrirΘ con ejemplos. De: pclites@cdsfulfillment.com Asunto: deCCS - ------------------------------------ Traducido por Oscar Esteban En el Criptograma de febrero de 2000 escribφa: "Un razonamiento importante es que los DVDs pueden ser copiados y pirateados sin usar deCSS ni cualquier otro tipo de descifrado, lo que ciertamente hace que las demandas originales de 'prevenci≤n de la piraterφa' parezcan tremendamente ignorantes o descaradamente enga±osas". Hay un aspecto en el que el argumento de "evita la piraterφa" tiene sentido. deCSS facilita copiar los datos de un DVD no s≤lo a otro DVD, sino a otro formato, uno mßs fßcil de copiar y transmitir. En ese sentido, uno podrφa decir de Θl que facilita la piraterφa. Algo similar a la l≤gica que subyace tras la distinci≤n entre versiones impresas y electr≤nicas del c≤digo fuente en las restricciones originales de exportaci≤n de criptografφa; pero para un producto de datos de consumo, creo que es una distinci≤n mßs significativa. Tendrφa que disfrazar la decisi≤n del jurado como una aplicaci≤n correcta de una ley mala, en lo que puede llegar a ser un caso que siente precedente. De: "Bryan Alexander" (xande1@bellsouth.net) Asunto: Linux seguro - ---------------------------------------------- Traducido por Oscar Esteban La NSA ha formalizado un contrato con Secure Computing Corp. para realizar una versi≤n segura de Linux. No sΘ si la licencia de Linux le permite a la NSA hacer una versi≤n segura del sistema operativo, si luego no distribuyen libremente los resultados. La GPL (Gnu Public License, que cubre casi todas las partes de Linux) sφ lo permite. No hay nada en la licencia que precise que se redistribuya todo aquello basado en la GPL, s≤lo lo que hay que hacer *si* se redistribuye un trabajo basado en la GPL. Ademßs, el Proyecto GNU ha dicho especφficamente que no se pretende con la licencia evitar que la gente cree (sin verse forzada a distribuir) sus propias versiones modificadas de software bajo GPL para su uso propio. El texto de la GPL se encuentra en http://www.gnu.org/copyleft/gpl.html. (N.T.: En el sitio web de LuCAS se encuentra una versi≤n traducida) (http://lucas.hispalinux.es/Otros/gples/gples.html) Es posible encontrar un escrito en que se considera la obligatoriedad de distribuir versiones modificadas de software una "restricci≤n inaceptable" en http://www.gnu.org/philosophy/apsl.html bajo el tφtulo "Falta de respeto hacia la privacidad". Es parte de una discusi≤n sobre los "fallos fatales" en la licencia APSL de Apple. (No puedo encontrar la fuente original del comentario sobre esto en relaci≤n con la GPL ahora mismo, lo siento). _____________________________________________________________________ CriptoGRAMA es la versi≤n espa±ola de Crypto-GRAM, elaborada por el equipo de traductores de Kript≤polis, con autorizaci≤n expresa de Bruce Schneier. Este ejemplar nunca hubiera sido posible sin la colaboraci≤n desinteresada de las siguientes personas: * Isidre Marques Serret * JosΘ Luis Martφn Mßs * Juan Cruz Ruiz de Gauna * Sergio Pozo Hidalgo * David G≤mez * Oscar Esteban _____________________________________________________________________ -- AVISO IMPORTANTE -- Kript≤polis dispone de la pertinente autorizaci≤n de Bruce Schneier para traducir, elaborar y publicar la versi≤n espa±ola de su boletφn Crypto-GRAM. La informaci≤n contenida en CriptoGRAMA s≤lo puede ser redistribuida siempre que se haga de forma completa y con expresa menci≤n de Bruce Schneier como autor de Crypto-GRAM y de Kript≤polis como responsable de CriptoGRAMA. Crypto-GRAM es un boletφn mensual gratuito dedicado a res·menes, anßlisis, comentarios e ideas sobre criptografφa y seguridad informßtica. Crypto-GRAM es elaborado por Bruce Schneier, presidente de Counterpane Systems, autor de "Applied Cryptography" y creador de los algoritmos Blowfish, Twofish y Yarrow. Schneier ha pertenecido a la direcci≤n de la International Association for Cryptologic Research, EPIC y VTW, y es asiduo escritor y conferenciante sobre criptografφa. _____________________________________________________________________ Este ejemplar se ha distribuido gratuitamente a mßs de 19.000 personas. Si desea recibir la edici≤n mensual de CriptoGrama y la edici≤n semanal del Boletφn de Kript≤polis, inscrφbase gratis en: http://www.kriptopolis.com/subs.html ⌐ Bruce Schneier ⌐ Kriptopolis (versi≤n en Espa±ol). _____________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: Clave en http://www.kriptopolis.com/claves/jmg.asc iQEVAwUBONik2hiK3dCT8TvxAQFlHwf/SnVX7QYOaPQdF+3nJApAROlnCWp2S1Fn if+dyLAeRmgGd5DLFPBwhRVL3ELBNFXclcP+I1PEbJXLA+IIXctPpUdnVQSaSmsK 6dLHzD8boZ++X4BoPBX+mK2EcbtY1Dpnf+rlkfqijU1Yr1CbqYdadykGQLAXkHjv 8nnYN7Ekdz437g+BkGrUqUiSDFHdUDX4aQJGu0YgP31ym24g0YMa5yXLQGbVw7G9 KI5HMDUyxr4AVdxwWmD7ij7BlyGORnv1c6s0dv3WcCwGfJ50waImj+w7qf34B1EY Som7uPZFXSZHWxvt75xaFetMEdyKuVdH4qAQP7OAvC3ZTPFU+ITzuw== =A0+K -----END PGP SIGNATURE-----