2000 << Back To criptograma nº 25

-----BEGIN PGP SIGNED MESSAGE----- _______________________________________________________________ C R I P T O G R A M A _______________________________________________________________ N·mero 25 15 de Mayo del 2000 ________________________________________________________________ SUMARIO: 1. Seguridad informßtica: ┐aprenderemos alguna vez? 2. Novedades desde Counterpane. 3. Noticias. 4. En la ratonera: tratado sobre ciberdelito. 5. Mßs sobre Microsoft Kerberos. 6. Software cliente fiable. 7. Virus ILOVEYOU. 8. Comentarios de los lectores. -- Ejemplar gratuito distribuido a mßs de 20.000 suscriptores -- ________________________________________________________________ * Suscripci≤n gratuita: http://www.kriptopolis.com/subs.html * N·meros anteriores: http://www.kriptopolis.com/criptograma/cg.html _________________________________________________________________ 1. Seguridad informßtica: ┐aprenderemos alguna vez? =================================================== Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna http://www.kriptopolis.com/criptograma/0025_1.html Si algo hemos aprendido durante los dos ·ltimos a±os, es que los fallos de seguridad informßtica son inevitables. Los sistemas son desprotegidos, las vulnerabilidades se publican en prensa y a·n asφ bastante gente confφa en el siguiente producto, o en la siguiente actualizaci≤n o en el siguiente parche. "Esta vez es seguro", suelen decir. Y despuΘs de todo, no lo es. La seguridad es un proceso, no un producto. Los productos ofrecen alguna protecci≤n, pero la ·nica forma de hacer negocios de forma efectiva en un mundo inseguro es colocar procesos que reconozcan la inseguridad inherente a los productos. El truco estriba en reducir el riesgo de revelaciones sin tener en cuenta los productos o sus parches. Consideremos los ataques de denegaci≤n de servicio (ataques DoS). Los ataques DoS son unos de los ataques mßs antiguos y sencillos del manual. A pesar de ello, en febrero del 2000, ataques DoS coordinados y distribuidos echaron abajo fßcilmente algunos sitios web de alto trßfico, incluyendo Yahoo, eBay, Amazon.com y CNN. Consideremos los ataques por desbordamiento del buffer. Se habl≤ ya de ellos ni mßs ni menos que hacia la dΘcada de los 60 -los sistemas de tiempo compartido sufrφan este problema- y eran conocidos en la literatura de seguridad incluso desde antes. En la dΘcada de los 70 eran usados frecuentemente como un punto de ataque contra los primeros ordenadores en red. En 1988 el gusano Morris hizo uso de un desbordamiento de buffer en el demonio Unix fingerd: un uso muy conocido de este tipo de ataque. Hoy dφa, mßs de una dΘcada despuΘs de Morris, y aproximadamente 35 a±os despuΘs del descubrimiento de estos ataques, podriamos pensar que la comunidad dedicada a la seguridad deberφa haber resuelto el problema de las vulnerabilidades de seguridad basadas en desbordamiento de buffer. PensΘmoslo de nuevo. Cerca de las dos terceras partes de las advertencias CERT en 1998 se debieron a vulnerabilidades provocadas por desbordamientos de buffer. Durante una semana normal en 1999, se localizaron vulnerabilidades de desbordamiento de buffer en la herramienta criptogrßfica RSAREF (ívaya!), en el sistema operativo HP, en el sistema operativo Solaris, en Microsoft IIS 4.0 y Site Server 3.0, Windows NT e Internet Explorer. Un reciente estudi≤ declar≤ los desbordamientos de buffer como el problema de seguridad mßs com·n. Consideremos los algoritmos de cifrado. Algoritmos propietarios secretos son publicados regularmente y son rotos. Una y otra vez el mercado aprende que los algoritmos propietarios secretos son una mala idea. Pero las compa±φas y las industrias -como Microsoft, el consorcio DVD, los proveedores de telΘfonos celulares y otros- contin·an eligiendo estos algoritmos propietarios en lugar de los p·blicos, que son alternativas gratuitas. ┐Hay alguien que tenga esto en cuenta? ====================================== Tristemente, la respuesta a esta pregunta es: realmente no. O al menos hay mucha menos gente teniΘndolo en cuenta de la que debiera haber. Y la enorme necesidad de productos de seguridad digital precisa de gente para dise±arlos, desarrollarlos e implementarlos. La escasez resultante de expertos implica que el porcentaje de gente teniendo esto en cuenta serß a·n menor. La mayor parte de los productos que usan seguridad no estßn dise±ados por alguien con experiencia en temas de seguridad. Incluso los productos de seguridad son generalmente dise±ados e implementados por gente que tiene una experiencia en seguridad limitada. La seguridad no puede ser probada funcionalmente -ninguna cantidad de beta testers podrφa descubrir los fallos de seguridad- por lo que los fallos de seguridad alcanzan a los productos que llegan al mercado. Estoy constantemente asombrado por el tipo de cosas que rompen productos de seguridad. He visto un producto de cifrado con una interfaz de usuario que accidentalmente guarda la clave en claro. He visto VPNs (Redes Privadas Virtuales) donde el fichero de configuraci≤n telef≤nica accidentalmente permite a una persona aleatoria autenticarse ante el servidor, o que permite a un cliente remoto ver ficheros de otro cliente remoto. Hay infinitas formas de hacer un producto inseguro, y los fabricantes acostumbran a tropezar en algunas de estas formas una y otra vez. Nadie tiene esto en cuenta porque nadie tiene que hacerlo ========================================================= Los productos de seguridad informßtica, como el software en general, tienen un modelo de calidad de producto muy extra±o. No tienen nada que ver con un autom≤vil, un rascacielos o una caja de pollo frito. Si compras un producto y resultas perjudicado a causa de un defecto del fabricante, puedes demandarle... y ganarßs. Los fabricantes de coches no pueden salir adelante construyendo coches que estallen al chocar; las tiendas de pollos no pueden salir adelante vendiendo cajas de pollo frito mezclado con algo sospechoso. No serφa de recibo que los constructores de edificios dijeran cosas como: "Huy! Otro que se cae. Lo sentimos. Pero basta con que espere a Rascacielos 1.1; íestarß libre al 100% de derrumbamientos!". El software es diferente. Se vende sin posibilidades de reclamaci≤n. Tus bases de datos de facturas por cobrar pueden irse abajo, llevßndose a tu compa±φa con ellas, y no podrßs quejarte a la compa±φa de software. Tu procesador de textos puede corromper tus ficheros accidentalmente y no tendrßs forma de solucionarlo. Tu cortafuegos puede convertirse en algo totalmente ineficiente -de forma que difφcilmente sea mejor que no tener nada- y a·n asφ serß tu culpa. Microsoft sac≤ adelante Hotmail con un error que permitφa que cualquiera leyera las cuentas de unos 40 millones de suscriptores, con contrase±a o sin ella, y nunca se preocuparon de disculparse. Los fabricantes de software no tienen que fabricar productos de calidad porque no tienen responsabilidades si no lo hacen. Y el efecto de esto en los productos de seguridad es que los fabricantes no necesitan fabricar productos que sean realmente seguros, porque nadie puede demandarles aunque hagan un mont≤n de afirmaciones falsas acerca de su seguridad. El resultado de esto es que el mercado no ofrece autΘntica seguridad. La autΘntica seguridad es difφcil, lenta y mßs cara, tanto a la hora de dise±arla como a la de implementarla. Puesto que el p·blico dispuesto a comprar no tiene forma de diferenciar la autΘntica seguridad de la mala, el camino para ganar cuota de mercado es dise±ar software que acaba siendo tan inseguro como podamos imaginar. Microsoft sabe que el software fiable no resulta rentable en relaci≤n a su coste. De acuerdo con estudios, entre el 90% y el 95% de los errores son inofensivos. Nunca son descubiertos por los usuarios y no afectan al rendimiento. Es mucho mßs barato sacar software err≤neo y arreglar ese 5% ≤ el 10% de los errores que la gente descubre y de los que se quejan. Microsoft tambiΘn sabe que la autΘntica seguridad tampoco resulta rentable en relaci≤n a su coste. Sus productos son reventados por vulnerabilidades de seguridad varias veces por semana. Arreglan los que pueden, escriben notas de prensa enga±osas acerca de los que no pueden arreglar, y esperan que el escßndalo vaya agotßndose (lo que realmente sucede). Y seis meses mßs tarde sacan la siguiente versi≤n de software con nuevas caracterφsticas y todo tipo de nuevas inseguridades, porque los usuarios prefieren caracterφsticas nuevas que seguridad. La ·nica soluci≤n es buscar procesos de seguridad ================================================= No existe la seguridad perfecta. Aunque no deja de ser interesante, esto no es necesariamente un problema. S≤lo en los EE.UU., la industria de las tarjetas de crΘdito pierde 10.000 millones de d≤lares al a±o; ni Visa ni MasterCard muestran signos de que vayan a quebrar. El hurto estimado en los EE.UU. estß actualmente entre 9.500 y 11.000 millones de dolares al a±o, pero nunca veremos las "reducciones" (como son conocidas) mencionadas como la causa cuando un negocio quiebra. Recientemente tuve que registrar ante el notario un documento. Trataba sobre el protocolo de seguridad mßs est·pido que habφa visto jamßs. Sin embargo, funciona bien para lo que se usa. La seguridad no tiene que ser perfecta, pero los riesgos deben ser manejables. La industria de las tarjetas de crΘdito entiende esto. Saben c≤mo estimar las pΘrdidas debidas al fraude. Su problema es que las pΘrdidas a travΘs de transacciones telef≤nicas usando tarjeta de crΘdito son aproximadamente cinco veces mßs numerosas que las producidas por transacciones cara a cara (donde la tarjeta estß presente). Las pΘrdidas por transacciones en Internet son varias veces mßs numerosas que las debidas a transacciones telef≤nicas, y son la fuerza impulsora que se encuentra detrßs de SET. Mi primera preocupaci≤n acerca del ciberespacio es que la gente no entiende los riesgos, y pone mucha fe en la habilidad de la tecnologφa para evitarlos. Los productos solos no pueden resolver los problemas de seguridad. La industria de la seguridad digital necesita desesperadamente un cambio de percepci≤n. Las contramedidas se venden como formas de contrarrestar amenazas. El buen cifrado se vende como una manera de evitar escuchas. Un buen cortafuegos es una forma de evitar ataques de red. La PKI (Infraestructura de Clave P·blica) se vende como gesti≤n segura, de forma que no confiemos en gente en la que no queremos confiar. Y asφ otras muchas cosas. Esta forma de pensamiento estß completamente anticuada. La seguridad es antigua, mßs a·n que los ordenadores. Y la vieja guardia de la industria de seguridad ve las contramedidas no como una forma de contrarrestar amenazas, sino como una forma de evitar riesgos. Esta distinci≤n es enorme. Evitar riesgos s≤lo admite dos posibilidades: o se evitan o no. Aceptar riesgos es algo continuo: hay una cierta cantidad de riesgo aceptable, y otra cantidad no aceptable. Los procesos de seguridad son la forma de evitar riesgos. De la misma manera que los negocios usan los procesos de contabilidad de doble entrada, con comprobaciones internas y comprobaciones externas para asegurar sus finanzas, tambiΘn necesitan hacer uso de una serie de procesos de seguridad para proteger sus redes. Los procesos de seguridad no deben reemplazar a los productos; son una forma de usar los productos de seguridad de manera efectiva. Pueden ayudar a mitigar los riesgos. Los productos de seguridad de red pueden tener defectos; los procesos son necesarios para atrapar a los atacantes que explotan estos defectos y para corregir los defectos una vez que son conocidos. Los ataques internos se pueden producir; los procesos son necesarios para detectar los ataques, reparar los da±os y seguir a los atacantes. Grandes defectos de los sistemas pueden llegar a comprometer productos enteros y servicios (pensemos en los telΘfonos celulares, los protocolos de contrase±a de Windows NT o el DVD); los procesos son necesarios para recuperarnos del peligro y seguir en la industria. He aquφ dos ejemplos sobre c≤mo centrarnos en procesos en cuanto a seguridad de redes empresariales: 1. Examinar las vulnerabilidades conocidas. Los ataques de seguridad de red mßs exitosos se basan en vulnerabilidades conocidas para las que ya existen parches. ┐Por quΘ? porque los administradores de redes ni siquiera instalaron los parches o porque los usuarios reinstalaron los sistemas vulnerables. Es fßcil actuar inteligentemente en el primer caso, pero hay que vigilar el otro. Hay muchas formas de comprobar vulnerabilidades conocidas. Los scanners de vulnerabilidades de red como Netect y SATAN las compueban. Los scanners de telefonφa como PhoneSweep buscan modems que no estßn jugando limpio en su organizaci≤n. Otros scanners buscan vulnerabilidades en sitios web. Utilicen este tipo de productos regularmente y tengan en cuenta los resultados. 2.- Monitorice continuamente sus productos de red. Casi todo en su red produce un flujo continuo de informaci≤n auditable: los cortafuegos, los sistemas de detecci≤n de intrusos, los routers, los servidores, las impresoras, etc. La mayor parte de esta informaci≤n es irrelevante, pero alguna contiene pistas para un ataque exitoso. Observar toda esta informaci≤n es vital para la seguridad, porque un ataque que salte un producto puede ser atrapado por otro. Por ejemplo, un atacante puede usar un defecto en un cortafuegos y pasar un IDS, pero su intento para obtener acceso root en un servidor interno aparecerß en los logs de auditorφa del servidor. Si disponemos de un proceso situado para observar estos logs, atraparemos al intruso en su intento. En este boletφn y en cualquier otro, he escrito de forma pesimista acerca del futuro de la seguridad informßtica. El futuro de los ordenadores es complejo y la complejidad es un anatema de la seguridad. Lo ·nico que puede hacerse es reducir el riesgo tanto como sea posible. No podemos evitar las amenazas, pero podemos reducir el riesgo. En ninguna otra parte de la sociedad se pone tanta fe como en la tecnologφa. Nadie ha dicho jamßs, "esta cerradura es tan efectiva que no necesitamos protecci≤n policial, ni leyes contra el allanamiento". Los productos funcionan en una cierta medida, pero necesitamos emplazar procesos para afianzar su efectividad. Una versi≤n de este ensayo publicado originalmente en el n·mero de Abril de "Information Security Magazine": http://www.infosecuritymag.com/apr2000/cryptorhythms.htm 2. Novedades desde Counterpane ================================================= Por Bruce Schneier Traducci≤n: Isaac Carreras http://www.kriptopolis.com/criptograma/0025_2.html Probablemente, se ha estado preguntando quΘ ha estado haciendo Counterpane desde el ·ltimo verano. Hemos cambiado nuestro nombre por el de Counterpane Internet Security, Inc. No seguiremos suministrando servicios de consultorφa. Hemos contratado a 95 personas. La antigua Counterpane Systems se ha convertido en Counterpane Labs, la rama de investigaci≤n de la compa±φa. Y nosotros nos estamos ocupando de los problemas reales de la seguridad informßtica. Nunca se ve en la cerradura de una puerta un anuncio con este eslogan: "Este cerrojo previene robos". En lo referente a la seguridad de ordenadores, siempre se veneste tipo de cosas. "E±l cifrado previene las escuchas ilegales". "Los cortafuegos protegen de intrusiones en la red". "PKI evita impostores". En realidad, esto no es cierto. Cuando compras una caja fuerte, viene catalogada. "30TL" -- 30 minutos, herramientas. "60TLTR" -- 60 minutos, herramientas y soplete. Lo que significa es que un ladr≤n profesional de cajas fuertes, con sus correspondientes herramientas y un soplete de oxiacetileno, necesitarß una hora para conseguir abrir la caja fuerte. Si la alarma no suena y los guardas no llegan rßpido, en una hora, la caja fuerte es in·til. Todo lo que compra con la caja fuerte es tiempo, y debe gastar con sensatez. Prevenci≤n. Detecci≤n. Respuesta. La industria de la seguridad informßtica se ha concentrado en la protecci≤n y ha ignorado durante mucho tiempo la detecci≤n y la respuesta. Los sistemas de detecci≤n de intrusos hacen sonar las alarmas, pero a menos que haya alguien que responda, no son mejores que la alarma de un coche que todo el mundo ignora. No tiene sentido. Si los mecanismos de protecci≤n fueran perfectos, no se necesitarφa la detecci≤n y posterior respuesta. Si la caja fuerte pudiera resistir a los ladrones indefinidamente, no se molestarφa con alarmas. Si sus cortafuegoss nunca tuvieran ning·n fallo de seguridad ni estuvieran nunca mal configurados, si el cifrado siempre fuera perfecto y si el PKI nunca tuviera ninguna vulnerabilidad, no necesitarφa detectar ni responder a nada. Pero ning·n producto de seguridad informßtica es perfecto. Cada dφa se descubren nuevas vulnerabilidades de seguridad en sistemas operativos, programas de servidores, aplicaciones de Internet, cortafuegoss y otros dispositivos de seguridad. Estos productos no muestran se±ales de ser mßs seguros; si acaso, la creciente complejidad de Internet los estß llevando a ser incluso menos seguros. Se necesita detecci≤n y respuesta. Counterpane Internet Security, Inc. proporciona esa detecci≤n y respuesta. Somos un servicio de monitorizaci≤n de la seguridad informßtica. No sustituimos sus productos de seguridad: cortafuegos, VPNs, IDSs, PKIs, servidores, routers... Nos encantan esos productos y queremos que sean mejores y mejores. Lo que hacemos es vigilarlos. Enviamos sus alertas a nuestros capacitados analistas de seguridad y contactamos con usted cuando hallamos alguna fisura. Somos su compa±φa de alarma en Internet. Complementamos sus productos de prevenci≤n con un servicio de detecci≤n y respuesta. Es la ·nica manera de mantener la seguridad en el mundo interconectado de hoy. Counterpane Internet Security, Inc. no vende productos de seguridad; s≤lo vendemos el servicio. Estamos convencidos de que los problemas fundamentales en seguridad no estßn relacionados con la tecnologφa, sino con c≤mo utilizar la tecnologφa. Visite el web de Counterpane; estarΘ encantado de explicarle nuestra empresa en mayor profundidad. Sitio Web de la empresa: http://www.counterpane.com Un documento sobre lo que hacemos: http://www.counterpane.com/whitepaper.html Un folleto: http://www.counterpane.com/brochure2.html Prensa: http://www10.nytimes.com/library/ tech/00/04/biztech/articles/03code.html http://news.cnet.com/news/ 0-1007-200-1626469.html?tag=st.ne.fd. lthd.1007-20b0-1626469 http://www.nwfusion.com/news/ 2000/0403intrusion.html http://www.thestandard.com/article/ display/0,1151,13474,00.html El lanzamiento de Counterpane: http://www.counterpane.com/pr-unveiling.html Los socios de Counterpane: http://www.counterpane.com/pr-partners.html La financiaci≤n de Counterpane: http://www.counterpane.com/pr-funding.html La importancia de la vigilancia: (escrito por Schneier): http://www.zdnet.com/special/ stories/defense/0,10459,2510681,00.html 3. Noticias ================================================= Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mas http://www.kriptopolis.com/criptograma/0025_3.html Robado otro portßtil con informaci≤n secreta, en este caso uno del Departamento de Estado de Estados Unidos: http://www.cnn.com/2000/US/04/17/state.computer.02/index.html http://www.computerworld.com/home/print.nsf/all/000419D6BA http://news.cnet.com/news/0-1003-200-1708583.html http://www.gcn.com/vol19_no9/news/1783-1.html Y mßs: http://www.zdnet.com/zdnn/stories/newsbursts/0,7407,2562861,00.html ******************** Intel estß abandonando el uso del n·mero de serie ·nico en sus microprocesadores. Son buenas noticias, y se debe felicitar a Intel por este cambio de postura. http://yahoo.cnet.com/news/0-1006-200-1773089.html? pt.yfin.cat_fin.txt.ne ********************* Tras casi dos a±os de estudio, un comitΘ secreto del gobierno alemßn ha concluido que los ataques a travΘs de Internet sustituirßn a los conflictos armados en los pr≤ximos a±os. http://www.zdnet.com/enterprise/stories/ main/0,10228,2504525,00.html ********************* Artφculo sobre las clasificaciones de seguridad de los militares americanos: http://www.ostgate.com/classification.html ********************* A nadie le caus≤ sorpresa el que el gobierno ruso dijera que iban a intervenir las comunicaciones a travΘs de Internet, pero ahora el gobierno britßnico quiere leer el correo electr≤nico: http://www.the-times.co.uk/news/pages/ sti/2000/04/30/stinwenws01034.html ********************** Comentario interesante sobre la "password de la puerta trasera" de Linux Red Hat. http://www.securityfocus.com/commentary/25 ********************** Un artφculo moderado y escΘptico sobre Echelon: http://www.thebulletin.org/issues/2000/ma00/ma00richelson.html ********************** Otra raz≤n mßs por la que no tiene sentido ocultar las listas de URLs que filtran los sistemas de filtrado de contenidos: http://www.news.com/Perspectives/Column/0,176,421,00.html ********************** El hacker Kevin Mitnick, que fue procesado y condenado, sali≤ de la cßrcel en libertad condicional hace unos pocos meses. Desde entonces ha escrito artφculos para revistas, ha comparecido ante el Congreso, y dado varias conferencias. De repente, su funcionario de condicional ha decidido callarle. Mitnick responde p·blicamente: http://news.cnet.com/news/0-1005-200-1781398.html? tag=st.ne.1002.bgif.1005-b200-1781398 ********************** Mßs invasiones de la intimidad, esta vez a travΘs del proveedor de acceso a Internet: http://www.vortex.com/privacy/priv.09.13 ********************** Buen artφculo sobre _Database Nation_: http://www.oreillynet.com/pub/a/network/ 2000/04/27/garfinkel/index.html que es, por cierto, un libro excelente: http://www.oreilly.com/catalog/dbnation/ ********************** Mßs informaci≤n sobre la UCITA. La moraleja parece ser que es mßs inteligente gastar los d≤lares del grupo de presi≤n a nivel estatal, en lugar de jugßrselos en el todo o nada de una ley federal. Todo esto es MUY peligroso. http://www.infoworld.com/articles/op/ xml/00/04/24/000424opfoster.xml ********************** Microsoft estß tanteando el empleo de seguridad biomΘtrica para resolver sus problemas de seguridad. http://www.wired.com/news/business/0,1367,36050,00.html http://www.msnbc.com:80/news/402255.asp?cp1=1 http://news.excite.com:80/news/r/000502/ 18/tech-microsoft-biometrics http://library.northernlight.com/FA20000503570000125.html? cb=0&dx=1006&sc=0 ********************** Esta noticia ronda el absurdo. La seguridad biomΘtrica no harß nada que mejore el estado general de la seguridad en Windows, y no tendrß ning·n efecto en la mayorφa de los problemas de seguridad que han estado sufriendo. E incluso en el mejor de los casos, la seguridad biomΘtrica no hace lo que afirman los sectores que la defienden. Ver mis otros artφculos sobre el tema: http://www.counterpane.com/insiderisks1.html http://www.counterpane.com/crypto-gram-9808.html#biometrics ********************** Hay algunas novedades en el frente de la criptografφa cußntica. No iba siquiera a tomarme la molestia de contar esto, pero he recibido suficientes preguntas del mundo de la prensa como para darme cuenta de que la mayorφa de la gente no entiende lo que se deriva de esto. Como cientφfico, lo encuentro interesante. Como profesional de seguridad, sΘ que es irrelevante. En otros momentos he descrito la confianza en la criptografφa como poner un clavo enorme en el suelo y esperar que el enemigo lo pise. Los problemas reales no estßn relacionados con la criptografφa: son errores de implementaci≤n, meteduras de pata en el modelo de confianza, mal uso intencionado, errores de configuraci≤n, etc. La criptografφa cußntica es un avance interesante, pero no tiene sentido discutir si el clavo mide 1000 o 1500 metros de altura. (Si alguien se pregunta quΘ es la criptografφa cußntica, hay una explicaci≤n muy clara en el ·ltimo capφtulo del libro de Simon Singh _The Code Book_). Es mucho mßs ·til empezar a preocuparse de todas las vulnerabilidades no relacionadas con la criptografφa. http://www.aip.org/releases/2000/release03.html ************************* He considerado durante mucho tiempo la falta de responsablidad del fabricante como una de las causas principales por las que Internet es insegura. TambiΘn predije una ola de demandas este a±o. Los abogados estudiaron Informßtica para prepararse para los juicios por el a±o 2000, y se aburren. Esta es una primera se±al de lo que puede venir: un abogado ha demandado a US West porque su conexi≤n por DSL dej≤ expuestos al p·blico sus archivos. Aunque no me gusta resolver los problemas judicialmente, estß bien. http://cgi.zdnet.com/slink?29949:8469234 ************************* Excelente historia de Village Voice sobre el caso de la protecci≤n anticopia de los DVDs de DeCCS: http://www.villagevoice.com/issues/0018/howe.shtml ************************* El presidente Clinton ha firmado una ley que obliga a los cuerpos de seguridad del Estado a documentar la frecuencia con la que interceptan conversaciones cifradas entre sospechosos de un delito. http://www.wired.com/news/politics/0,1283,36067,00.html Declaraciones de Clinton: http://www.politechbot.com/docs/clinton-crypto.050300.html Estadφsticas de pinchazos de 1999: http://www.uscourts.gov/wiretap99/contents.html ************************** Anßlisis de las polφticas de intimidad: los grandes websites tienen polφticas de intimidad, ┐no? ┐Ha tratado de leer alguna? USA Today lo intent≤, y no lo logr≤. http://www.usatoday.com/life/cyber/tech/cth818.htm ************************** Buena introducci≤n a IPSec: http://www.cisco.com/warp/public/759/ipj_3-1/ipj_3-1_ip.html ************************** Otro estudio sobre el debate de la seguridad del c≤digo abierto: http://www.securityfocus.com/commentary/19 ************************** 4. En la ratonera: tratado sobre ciberdelito ================================================= Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mas http://www.kriptopolis.com/criptograma/0025_4.html El Consejo de Europa ha presentado un borrador de propuesta de acuerdo sobre delitos en el ciberespacio. (El Consejo de Europa estß formado por 40 paφses, que incluyen a Estados Unidos, Canadß, Rusia y Sudßfrica). Aunque con buenas intenciones, tiene un artφculo que podrφa da±ar la posibilidad de investigar. El pßrrafo en cuesti≤n dice: ++++ Artφculo 6: Dispositivos Ilegales. Las partes tendrßn que adoptar las medidas legislativas y de otras clases que sean necesarias para definir delitos seg·n sus leyes cuando se cometan intencionadamente y sin derecho: a. la producci≤n, venta, adquisici≤n para uso, importaci≤n, distribuci≤n o el disponer de la forma que sea de: 1.a dispositivos, incluidos programas informßticos, dise±ados o adaptados [especφficamente] [principalmente[ [en particular] con el fin de cometer cualquiera de los delitos definidos seg·n el Artφculo 2. ++++ Esto harφa ilegal crear, publicar o descargar cualquier software que sea "dise±ado o adaptado" para asaltar un sistema informßtico. Es otra de esas medidas del tipo "apagar el fuego con gasolina". Muchas herramientas de seguridad con usos legales- scanners de vulnerabilidad, por ejemplo- entran en esa categorφa. Lo mismo ocurre con la mayorφa de la investigaci≤n en seguridad informßtica que descubre y corrige vulnerabilidades. Los efectos de este acuerdo, si se aplicara, s≤lo crearφan mßs software inseguro. No veo de quΘ forma puede hacer da±os a los delincuentes informßticos esta ley. Estßn distribuyendo herramientas de ataque, y la mayorφa lo hacen an≤nimamente. Esto afectarß sobre todo a la investigaci≤n en seguridad con fines legφtimos. Tratado: http://conventions.coe.int/treaty/en/projets/cybercrime.htm Artφculo de prensa: http://wired.com/news/politics/0,1283,36047,00.html 5. Mßs sobre Microsoft Kerberos ================================================= Por Bruce Schneier Traducci≤n: Francisco Leal Vßzquez http://www.kriptopolis.com/criptograma/0025_5.html Microsoft ha puesto a libre disposici≤n sus extensiones propietarias sobre Kerberos..., mßs o menos. Se puede bajar un documento con las lφneas generales sobre los cambios desde el sitio Web de Microsoft. No obstante, el documento se entrega como un ejecutable auto-extraφble. Pero cuando se ejecuta el .exe, se muestra un acuerdo de licencia con el que debes estar de acuerdo para ver el documento. Este es el pßrrafo relevante: "b. La Especificaci≤n es informaci≤n confidencial y un secreto de mercado de Microsoft. Por consiguiente, no se puede revelar la Especificaci≤n a nadie (excepto a los detallados abajo), y se deben tomar razonables medidas de seguridad (como mφnimo tan grandes como las precauciones tomadas para proteger su informaci≤n confidencial), para mantener la confidencialidad de la Especificaci≤n. Si es una entidad, puede desvelar la Especificaci≤n a sus empleados a tiempo completo sobre la base de una necesidad de conocimiento por parte de los mismos, una vez probado de manera suficiente que ha ejecutado los acuerdos por escrito con sus empleados para cumplir con los tΘrminos de este Acuerdo." Lo que tenemos aquφ es una manera de distribuir la especificaci≤n a la vez que se convierte en ilegal el hecho de construir implementaciones compatibles. Esto frustra por completo las metas de interoperabilidad de la IETF, y ayuda a que Microsoft pueda extender su monopolio de los ordenadores de escritorio al mercado de los servidores. Sitio Web de Microsoft: http://www.microsoft.com/technet/security/kerberos/default.asp Artφculos de las noticias: http://slashdot.org/articles/00/05/02/158204.shtml http://www.infoworld.com/articles/en/xml/00/04/28/000428enkerpub.xml La cosa empeora. Parece que ha habido una discusi≤n sobre la especificaci≤n de Kerberos de Microsoft en Slashdot. Alguna parte de esta discusi≤n viol≤ los tΘrminos del ridφculo acuerdo de licencia arriba mostrado. Asφ que Microsoft envi≤ a Slashdot una iracunda carta legal, quejßndose de que los mensajes violaban el DMCA (La Ley del Milenio sobre Copyright Digital, la que prohibe la ingenierφa inversa). Mientras se escriben estas lφneas, Slashdot todavφa no ha quitado los mensajes ofensivos, pero la cosa pudiera ponerse fea. Tengo la esperanza de que esto vaya de hecho a juicio, y que algunas de las disposiciones mßs extravagantes del DMCA (y la UCITA) sean desechadas. La discui≤n a la que se opone Microsoft: http://slashdot.org/article.pl?sid=00/05/02/158204 La carta legal de Microsoft y la respuesta inicial de SlashDot: http://slashdot.org/article.pl?sid=00/ 05/11/0153247&mode=nested&threshold=0 Mßs comentarios de SlashDot: http://slashdot.org/features/00/05/13/2038233.shtml Mirror con la especificaci≤n de Kerberos (en el momento de escribir esto el link estß a·n activo): http://members.xoom.com/MSKerberos/ En las noticias: http://salon.com/tech/log/2000/05/11/slashdot_censor/index.html http://news.cnet.com/news/0-1003-200-1857407.html?tag=st http://www.washingtonpost.com/wp-dyn/articles/A52826-2000May11.html http://slashdot.org/features/00/05/12/1421258.shtml Un artφculo: http://www.securityfocus.com/news/33 6. Software cliente fiable ========================================================== Por Bruce Schneier Traducci≤n: Oscar Esteban http://www.kriptopolis.com/criptograma/0025_6.html Ha habido recientemente una oleada de artφculos sobre temas de seguridad en el software del lado de cliente. Distintas compa±φas afirman vender soluciones seguras de correo electr≤nico donde un mensaje no puede ser leφdo tras una determinada fecha, al ser este, a todos los efectos, "borrado". Otras compa±φas dicen vender software de gesti≤n de derechos: ficheros de audio y video que no se pueden copiar o redistribuir, datos que se pueden leer pero no imprimir, software que no se puede copiar. El elemento com·n de todas estas "soluciones" es que promueven una situaci≤n en la que el propietario de un fichero puede controlar quΘ ocurre con ese fichero una vez se ha cedido a otra persona. No tiene ning·n sentido. Controlar lo que el cliente puede hacer con unos datos da por supuesto un elemento software fiable (desde el punto de vista del propietario inicial del fichero) ejecutßndose en el cliente. Tal cosa no existe, asφ que estas soluciones no funcionan. Como ejemplo, obsΘrvese la comunidad de jugadores on-line. Muchos juegos permiten una interacci≤n multijugador a travΘs de internet, y algunos juegos incluso tienen competiciones con premios en metßlico. Los hackers han escrito "bots" que ayudan al jugador en algunos de estos juegos, en especial Quake y NetTrek. La idea es que los bots pueden reaccionar mucho mßs rßpido que un humano, y que el jugador se vuelve mucho mßs efectivo con la ayuda de estos bots. Ha comenzado una carrera armamentφstica, a medida que los dise±adores de juegos tratan de desactivar estos bots y forzar un juego mßs limpio, y los hackers hacen los bots mßs inteligentes. Estos juegos intentan apoyarse en un software cliente fiable, y la comunidad hacker ha conseguido saltar todos los obstßculos que los dise±adores de juegos les han colocado. Me sorprendo continuamente ante los esfuerzos realizados por los hackers para romper la seguridad. La lecci≤n es doble: no s≤lo no hay forma razonable de confiar en el lado del cliente de un programa en el uso real, sino que no hay forma posible de conseguir jamßs ese grado de protecci≤n. Contra todos estos sistemas -correo que desaparece, gesti≤n de derechos de m·sica y vφdeo, juego limpio- hay dos tipos de atacantes: el usuario medio y el atacante experto. Contra el usuario medio cualquier cosa vale; no hace falta un software de seguridad complejo. Contra el atacante experto nada sirve. Y peor a·n, la mayorφa de sistemas necesitan ser seguros ante el mßs inteligente de los atacantes. Si una persona rompe la seguridad de Quake (o Intertrust, o DisappearingInc), puede escribir una herramienta de uso sencillo que cualquiera pueda emplear. De pronto un sistema de seguridad que era seguro ante casi cualquier atacante puede ahora ser roto por cualquiera. Construir un cliente de fiar mediante software, y tratar de limitar las capacidades de un usuario en un ordenador de prop≤sito general estß condenado al fracaso. De momento, no obstante, ofrece una falsa sensaci≤n de seguridad. 7. Virus ILOVEYOU ==================================================== Por Bruce Schneier Traducci≤n: David G≤mez http://www.kriptopolis.com/criptograma/0025_7.html Lo que mßs me impacta de este virus es lo bien que hace ingenierφa social con el usuario. Viene de alguien que el usuario conoce. Tiene un tφtulo sugerente en el mensaje. En Microsoft Outlook la extensi≤n ".vbs" se suprime por defecto, asi que parece un inocuo fichero ".txt". Incluso con todas las advertencias de no abrir correo con ficheros adjuntos que no se esperen, el usuario medio no tiene ninguna oportunidad contra un virus como este. Serß incluso peor en el futuro. Los sistemas corriendo ya sea Microsoft Office 2000 o Internet Explorer 5.0 pueden ser infectados con estos tipos de virus incluso si el receptor no abre el fichero adjunto. Asφ es; si el sistema esta ejecutando Internet Explorer con la configuraci≤n por defecto, es vulnerable. El problema es causado por un error de programaci≤n en un control ActiveX de Internet Explorer. Gracias, Microsoft. Regreso al virus ILOVEYOU. Lean el excelente articulo de James Gleick: http://slate.msn.com/Features/lovebug/lovebug.asp Y el comentario de Phil Agre es tan perfecto, que voy a repetirlo aquφ. Puede subscribirse a su servicio de noticias, "Red Rock Eater News Service," en: http://dlis.gseis.ucla.edu/people/pagre/rre.html Phil dice: "He recibido unas 60 copias del ·ltimo virus Microsoft y sus variantes. ┐Cuantas recibiste t·? Afortunadamente gestiono mi correo con el mailx de Berkeley y las macros de teclado de Emacs, asi que no estaba en riesgo. Pero si estuvieramos hablando de miles de millones de d≤lares en da±os, lo que se equipara a millones de dias de trabajo perdido, entonces creo que Microsoft y nosotros tendrφamos que tener una peque±a charla." Leyendo los recortes de prensa, la postura de Microsoft hacia esta situaci≤n ha sido desafortunada. La mayorφa de sus declaraciones han sido cuidadosamente elaboradas para desligar a la compa±ia de cualquier responsabilidad sobre el problema. Una de las versiones sigue el hilo de esta cita dicha por Scott Culp de Relaciones P·blicas de Microsoft, perd≤n, quiero decir Centro de Respuestas de Seguridad de Microsoft (Microsoft Security Response Center). "Esta es una cuesti≤n general, no una cuesti≤n relativa a Microsoft. Se puede escribir un virus para cualquier plataforma. (New York Times 5/5/00)." Hay que fijarse en la tecnologφa de relaciones p·blicas que estß en marcha aquφ: manipular el asunto, como para alejar la atenci≤n de las vulnerabilidades especφficas de la arquitectura de aplicaciones de Microsoft y llevarla hacia el concepto difuso de "un virus". Las personas tΘcnicas comprenderßn el problema aquφ, pero la mayorφa de la gente corriente no lo harß. El Sr. Culp tambiΘn dice esto (CNET 5/5/00): "Este es el comportamiento por dise±o, no una vulnerabilidad de seguridad." Mßs palabras sin pies ni cabeza. Es como decir, "Esto es una roca, no algo que pueda caer al suelo". Es incluso confuso pensar sobre ello. Incluso aunque Microsoft especificamente ha sido informada del problema de seguridad en su software, ha rechazado repararlo. Microsoft incluso intent≤ echar la culpa de su problema a Netscape, que *sφ* lo habφa arreglado: http://news.cnet.com/news/0-1005-200-1820959.html El pr≤ximo paso es echar la culpa a los usuarios. El mismo Sr. Culp lee en la radio un texto de aviso que los usuarios que dispersaron el virus habφan supuestamente ignorado. Ese aviso concluφa con una frase al efecto de que no deberφan ejecutar ficheros adjuntos de fuentes en las que no se confφe. Ley≤ esta parte algo rßpido, como se podφa esperar, dado que la idea principal de este virus es que la gente recibe un anexo de una persona que le ha incluido en su libro de direcciones. Esta tßctica concreta de echar las culpas a otros es particularmente poco ingeniosa, dado que el virus se distribuy≤ rßpidamente a travΘs de la propia Microsoft, hasta el punto de que la compa±φa tuvo que bloquear todo el correo entrante (Wall Street Journal 5/5/00). Igualmente, CNET (5/4/00) cit≤ a un desconocido "Representante de Microsoft" diciendo que las compa±φas deben educar a los empleados para "no ejecutar un programa de un origen en el que no se confφe". Destacar la ciertamente ambigua palabra "origen". El virus llega a tu buz≤n claramente marcado como enviado por un individuo en particular con quien probablemente tengas un contacto establecido. No lleva ning·n otro signo acerca de su "origen" que un usuario ordinario fuera capaz de interpretar, aparte de la ejecuci≤n del fichero adjunto. Entonces, ┐quΘ rayos estß haciendo Microsoft permitiendo que los adjuntos ejecuten c≤digo en un lenguaje de script lleno de agujeros que puede, entre otras cosas, enviar correo de forma invisible? El "Representante de Microsoft" dice: "Incluimos tecnologφas de scripting debido a que nuestros clientes nos pidieron que las pusieramos ahφ, las cuales permiten el desarrollo de aplicaciones de producci≤n crφticas para los negocios que millones de nuestros clientes utilizan." Hace falta que haya una moratoria sobre expresiones tal como "nuestros clientes nos pidieron que". ┐Se refiere eso a todos los clientes? ┐O s≤lo a algunos de ellos? Hay que prestar atenci≤n a la ambiguedad de algunos/todos, que es otra de las tecnologφas centrales de las relaciones p·blicas. ┐Esos "clientes" de verdad preguntaron de forma especφfica por scripts totalmente genΘricos que los anexos puedan ejecutar, o solamente pidieron ciertas caracterφsticas que pueden ser implementadas de diversas maneras, algunas de las cuales implican anexos que ejecutan scripts? ┐Comprenden los clientes, que supuestamente pidieron estas cosas sin sentido, sus consecuencias? ┐Pidieron que fueran activadas por defecto, para que cada cliente sobre la tierra sufriera el lado malo y que unos pocos clientes pudieran aprovechar mßs c≤modamente el lado bueno? Y destacar como el "Representante de Microsoft" manipula la cuesti≤n de nuevo, pasando del asunto concreto de los scripts que pueden ser ejecutados por anexos, al concepto difuso de las "tecnologφas de scripting", como si cualquiera estuviera sugiriendo que las tecnologφas de scripting, como tales, en general, fueran culpables. Microsoft no deberφa ser dividida. Deberφa ser cerrada. Agre tiene incluso mßs ejemplos del doble mensaje de Microsoft en: http://commons.somewhere.com/rre/2000/RRE.notes.and.recommenda6.html 8. Comentarios de los lectores ==================================================== Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez http://www.kriptopolis.com/criptograma/0025_8.html De: David Wadsworth (dwadsw@etna.demon.co.uk) Asunto: Robada mßquina Enigma ********************************************* Seg·n parece, la mßquina robada fue una Abwehr Enigma, como la utilizada por el Servicio Alemßn de Inteligencia durante la guerra. Resulta creible que s≤lo queden tres de ellas en el mundo, puesto que estaban mßs protegidas que las Enigmas normales y sus operadores estaban mßs predispuestos a destruirlas para evitar que fueran capturadas. Tuvieron un interΘs especial para los cript≤logos, puesto que presentaban dos innovaciones: en primer lugar, el cuarto rotor (reflectante) desplazable en vez de estßtico, y que cada rueda desplazaba a la siguiente varias veces en cada giro, en lugar de una sola. El libro "The Codebreakers" describe esta mßquina en el capφtulo 16, y sugiere que BP hubiera tenido problemas para vencerla si no hubiera sido por la circunstancia de que los alemanes omitieron la tarjeta conectable que se utilizaba en las Enigma normales. De: David Jones (dej@inode.org) Asunto: UCITA, autoayuda remota e implicaciones para cortafuegos **************************************************************** UCITA en teorφa permite a los fabricantes desactivar software a travΘs de Internet. ┐C≤mo se realiza esto concretamente? Todas las empresas que conozco que utilizan software comercial tienen cortafuegos que evitan acceder a los recursos internos desde el exterior. Incluso en casa, mi propia red tiene un cortafuegos. Para que un fabricante pudiera desactivar software de forma remota a travΘs de Internet, necesitarφa acceder al servidor que contiene la licencia de software, a travΘs del cortafuegos del cliente. Esto trae a colaci≤n unos cuantos asuntos. Los fabricantes tendrφan que documentar los protocolos requeridos para realizar la deshabilitaci≤n remota (por ejemplo, quΘ puertos utilizar) de modo que los clientes pudieran abrir sus cortafuegos. Los fabricantes necesitarφan asegurarse de que los clientes permiten de hecho el acceso, quizßs a base de obligar a que las licencias en red fuesen renovadas peri≤dicamente. Diferentes paquetes podrφan tener requisitos diferentes de desactivaci≤n. En el caso del software que utiliza una tΘcnica de licencia com·n (como el FlexLM de Globetrotter), los protocolos de desactivaci≤n remota podrφan entrar en conflicto unos con otros (┐Cußntos servidores de licencias diferentes funcionan en su negocio?). Por supuesto, los fabricantes probablemente tambiΘn necesitarßn que todo el mundo lo realice de la misma forma, puesto que los fabricantes no querrßn tener que llevar la cuenta de quΘ puertos utiliza cada cliente. Como director de informßtica, ┐le gustarφa tener que vΘrselas con todo esto? _____________________________________________________________________ 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: * Isaac Carreras * Francisco Leal Vßzquez * JosΘ Luis Martφn Mßs * Juan Cruz Ruiz de Gauna * 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 20.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 Para no recibir CriptoGrama ni el Boletφn de Kript≤polis: http://www.kriptopolis.com/baja.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 iQEVAwUBOSl/bxiK3dCT8TvxAQHHkAf+LbbpGVVc2CLVXdgSnh+TdyOi60r43m/6 4BhG2ut+CPdK9HhPI98YngxL8TOh9rnBrQmvyuYWAgS0zMDLMitoUG7trdiG6v7x PMqY0x1+66BFRZNCvhpvWKkUCtDDnXIUBemouhasd6wRda+y/+TXm+4urt/0woxy OTQKrCDeevm1dBsfz2lG8bArTCatDAW8H0GXWxFM082RBqjL9t/lyrFWkJzvSzfy KV8v06+ZKkURQcltHOTbeFunxaXTX/h+gvVJ8933YbmsItGYPagVrBy9YUdF0EG/ UIdqsJ0rrg43gWCUacu3lsCdQdYDozw7nWeJvfRuzCQ0BHsxSNqy7g== =hHB8 -----END PGP SIGNATURE-----