1999 << Back To criptograma nº 16

C R I P T O - G R A M A ⌐ Bruce Schneier ⌐ Kriptopolis (versi≤n en Espa±ol). http://www.kriptopolis.com/criptograma/cg.html -------------------- N·mero 16 15 de Agosto de 1999 -------------------- SUMARIO: 1. Back Orifice 2000 2. Counterpane: investigaci≤n documentada 3. Noticias 4. Noticias desde Counterpane Systems 5. Novedades desde el NIST sobre AES 6. En la ratonera: HPUX y el algoritmo Crypt de UNIX 7. Correo cifrado vφa Web 8. Comentarios de los lectores -------------------------------------------------------------- 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. Nuevos ejemplares de CriptoGRAMA estarßn disponibles cada mes en: Cripto-GRAMA: http://www.kriptopolis.com/criptograma/cg.html 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. Crypto-GRAM: http://www.counterpane.com/crypto-gram.html ---------------------------------------------------------------- 1. Back Orifice 2000 ------------------------------- Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez Back Orifice es una herramienta gratuita de administraci≤n remota para Microsoft Windows. TambiΘn es una de las mejores herramientas de hacking jamßs desarrolladas. Publicada originalmente el pasado mes de julio, Back Orifice 2000 (BO2K) es la versi≤n actual del programa. Funciona en Windows 95, Windows 98 y Windows NT. Estß mucho mejor escrita que el Back Orifice original. Y es gratuita y de c≤digo abierto. Existen dos partes: un cliente y un servidor. El servidor se instala en la mßquina objetivo. El cliente, que reside en otro ordenador en cualquier lugar de Internet, puede tomar el control del servidor. En realidad, se trata de un requisito legφtimo. Programas perfectamente respetables, como pcAnywhere o el propio Systems Management Server (SMS) de Microsoft, hacen lo mismo. Permiten a un administrador de red revisar en un ordenador de forma remota. Facilitan al responsable del soporte tΘcnico diagnosticar problemas a distancia. Resultan imprecindibles en muchos entornos informßticos empresariales. Las herramientas de administraci≤n remota tambiΘn tienen un lado oscuro. Si el servidor es instalado en un ordenador sin que lo sepa o autorice su propietario, el cliente puede tomar posesi≤n del PC de la vφctima. El rasgo que diferencia a Back Orifice es sobre todo una cuesti≤n de marketing. Puesto que no es distribuido por una empresa respetable, no puede confiarse en Θl. Puesto que fue escrito por hackers es maligno. Puesto que se habla mßs de sus usos malintencionados, sus usos correctos son ignorados. Se trata de un error: pcAnywhere es una herramienta de hacking exactamente igual de perversa que Back Orifice. Bueno, no exactamente. Back Orifice fue dise±ada por equipo de hackers por pura diversi≤n. El cliente no s≤lo puede realizar las tareas normales de administraci≤n en el ordenador que contiene al servidor (subir y bajar ficheros, borrarlos, ejecutar programas, modificar configuraciones, tomar el control del teclado y el rat≤n, ver lo que aparece en la pantalla del servidor), sino que tambiΘn puede hacer cosas mßs subversivas: reiniciar el ordenador, mostrar todo tipo de cuadros de dißlogo, encender y apagar el micr≤fono o la cßmara, capturar pulsaciones de teclas (y contrase±as). Y existe un lenguaje para m≤dulos de extensi≤n (plug-in) que permite crear m≤dulos nuevos. (Estoy esperando que alguien escriba un m≤dulo que automßticamente busque, y grabe, claves privadas PGP). Back Orifice tambiΘn ha sido dise±ado para ocultarse del propietario del ordenador donde reside el servidor. A menos que Θste sepa de su existencia, y la sospeche, nunca sabrß que Back Orifice se estß ejecutando en su ordenador. (Otras herramientas de administraci≤n remota, incluso SMS, disponen tambiΘn de modos protegidos; Back Orifice es a·n mejor en eso). Los programas antivirus han sido actualizados para detectar las configuraciones por defecto de Back Orifice, pero eso s≤lo resolverß la mayor parte del problema. Como Back Orifice es configurable, puesto que puede ser descargado en forma de c≤digo fuente y luego recompilado para darle un aspecto distinto... dudo que todas las variantes puedan ser alguna vez descubiertas. Bien, ┐pero a quiΘn le echamos la culpa? "Cult of the Dead Cow" escribi≤ y public≤ Back Orifice. Seguramente el mundo no resulta mßs seguro gracias a ello, tal y como Sir Dystic (de CDC) dice: "cualquier chaval de catorce a±os que quiera ser un hacker lo probarß." El lema de BO2K dice "demuestra que controlas", y muchos se tomarßn el consejo muy en serio. Back Orifice serß utilizado por montones de gente sin Θtica alguna para realizar todo tipo de acciones carentes de ninguna Θtica. Y eso no es bueno. Por otro lado, Back Orifice no puede hacer nada hasta que su parte servidora sea instalada en el ordenador de alguna vφctima. Esto significa que la vφctima tiene que dar alg·n paso en falso en cuestiones de seguridad antes de que nada pueda ocurrir. Esto tampoco resulta difφcil: montones de personas se conectan a Internet sin la protecci≤n adecuada. Incluso un atacante puede pedir a la vφctima que instale Back Orifice (la ingenierφa social podrφa ayudar); el gusano Worm.ExploreZip de la primavera pasada hacφa exactamente eso. Pero a·n asφ, si la vφctima permanece lo bastante atenta, nunca podrß ser atacada por Back Orifice. ┐Y quΘ decir respecto al entorno informßtico Microsoft? Uno de los motivos por los que Back Orifice es tan da±ino es que Microsoft no dise±a sus sistemas operativos para ser seguros. Nunca lo ha hecho. Cualquier programa que se ejecute en Windows 95 y 98 puede hacer cualquier cosa. En Unix, un atacante tendrφa antes que lograr privilegios de ærootÆ. Pero no en Windows. No existen cosas como privilegios limitados, privilegios de administrador o privilegios de ærootÆ. Microsoft asume que cualquiera puede ejecutar un programa que reformatee el disco duro. Esto podrφa haber tenido alg·n sentido en la era de los ordenadores aislados de sobremesa; al fin y al cabo, para ejecutar un programa habrφa de estar delante del ordenador. Pero en Internet, esto es absurdo. Windows NT se dise±≤ como un sistema operativo seguro, mßs o menos. Existen mecanismos previstos para convertir a Windows NT en un sistema operativo muy seguro, tales como los niveles de privilegios en cuentas de usuarios separadas, permisos de archivos y listas de control de accesos a objetos del n·cleo. Sin embargo, la configuraci≤n que convierte a Windows NT en seguro estß muy muy lejos de la configuraci≤n instalada por defecto. Microsoft admite esto. Se dispone de mßs de 300 comprobaciones de seguridad y cambios para convertir en segura la configuraci≤n por defecto. Y por encima de todo, Microsoft asume que la mayorφa de los usuarios disponen de acceso como administradores a sus ordenadores de sobremesa. S≤lo se preocupan de la seguridad de la red, no de la de sus elementos finales, que son los verdaderamente vulnerables a ataques como Back Orifice 2000. Windows NT podrφa ser seguro, pero Microsoft reh·sa despachar el sistema operativo en tales condiciones (quizßs les preocupa que sus estupendas barras de men·es desplegables pudieran ser pasadas por alto). Las herramientas maliciosas de administraci≤n remota constituyen un importante riesgo para la seguridad. Lo que Back Orifice ha conseguido es hacer consciente del peligro a un enorme volumen de usuarios. El mundo podrφa haber sido mßs seguro si no nos hubieran mostrado el peligro tan grßficamente, pero no estoy muy seguro. Lo cierto es que existen otras herramientas similares en el mundillo hacker (una de ellas, denominada BackDoor-G, ha sido descubierta recientemente), algunas de ellas dise±adas con prop≤sitos mucho mßs siniestros. Y Microsoft s≤lo responde a las amenazas a la seguridad si son demostradas. Explique la amenaza en un trabajo de investigaci≤n y Microsoft la niega; publique una herramienta hacker como Back Orifice y s·bitamente toman la vulnerabilidad en serio. Back Orifice Home Page: http://www.bo2k.com/ Comentario: http://www.zdnet.com/zdnn/stories/news/0,4586,2127049,00.html http://www.infoworld.com/cgi-bin/displayArchive.pl?/99/30/o03-30.36.htm Microsoft Systems Management Server: http://www.microsoft.com/smsmgmt/techdetails/remote.asp http://www.cultdeadcow.com/news/pr19990719.html BackDoor-G: http://www.zdnet.com/zdnn/stories/news/0,4586,2267379,00.html 2. Counterpane: investigaci≤n documentada -------------------------------------------- Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez "Notes on the Design and Analysis of the Yarrow Cryptographic Pseudorandom Number Generator" ("Notas sobre el dise±o y anßlisis del generador de n·meros pseudoaleatorios Yarrow".) J. Kelsey, B. Schneier, and N. Ferguson, Sixth Annual Workshop on Selected Areas in Cryptography, Springer Verlag, Agosto 1999, pendiente de publicarse. Describimos el dise±o de Yarrow, una familia de generadores de n·meros pseudoaleatorios (PRNG). Describimos el concepto de PRNG como una primitiva criptogrßfica separada y los principios de dise±o utilizados para desarrollar Yarrow. Discutimos a continuaci≤n las formas en que los PRNG pueden fallar en la prßctica, lo que motiva nuestra discusi≤n sobre los componentes de Yarrow y c≤mo contribuyen a que Yarrow sea seguro. Luego, definimos un tipo en particular de PRNG de la familia Yarrow que utiliza la tecnologφa hoy en dφa disponible. http://www.counterpane.com/yarrow-notes.html 3. Noticias ----------------------------- Por Bruce Schneier Traducci≤n: David G≤mez Gran ironφa: El presidente Clinton convierte un proyecto en ley firmando con PGP: http://www.wired.com/news/news/politics/story/20775.html Una nueva ley del Reino Unido sobre el comercio electronico tiene la detestable disposici≤n de que la policφa serß capaz de exigir acceso a las claves de cifrado si sospechan un uso delictivo de Internet. Aquellos que se nieguen se ganarßn una sentencia de dos a±os en prisi≤n. http://www.wired.com/news/news/politics/story/20937.html http://techweb.com/news/story/TWB19990726S0010 Texto de la ley: http://www.dti.gov.uk/cii/elec/ecbill.html Comentario sobre la ley por la Fundaci≤n de Investigaci≤n de Polφticas en Internet: http://www.fipr.org/ecommpr.html Los primeros tres capφtulos del tratado de Alan Turing sobre Enigma, reescritos a partir de la unica copia conocida, estßn disponibles en: http://home.cern.ch/~frode/crypto/Turing/index.html L0pht ha sacado una herramienta anti-sniffers. Detecta sniffers en las redes. Desafortunadamente, al menos un sniffer resistente a las detecciones ha sido publicado ya. Y la carrera contin·a... http://www.wired.com/news/news/technology/story/20913.html L0pht: http://www.l0pht.com/ El Information Society, una revista acadΘmica, ha publicado un n·mero especial sobre el anonimato e Internet: vol. 15, no. 2. De hecho, hay artφculos interesantes en la mayorφa de los n·meros atrasados. http://www.slis.indiana.edu/TIS/tables_of_contents/toc.html El sistema de cifrado de ficheros (EFS) incorporado en Microsoft Windows 2000 ha sido vencido. http://www.ntsecurity.net/forums/2cents/news.asp?IDF=118&TB=news Microsoft reivindica que no lo ha sido, que el ataque es debido a que el usuario ha realizado algo incorrectamente: dejar la clave de recuperaci≤n EFS en la mßquina. http://www.microsoft.com/security/bulletins/win2kefs.asp La respuesta del autor: http://www.ntsecurity.net/forums/2cents/GetMessage.asp?RootID=2092&ID=2102&I DF=118&TB=news Me reservo mi juicio, no habiendo estudiado el EFS, el ataque, o la respuesta de Microsoft. A finales de Mayo, Janet Reno escribi≤ al Secretario Federal de Justicia Alemßn Herta Daubler-Gmelin, pidiendole que controle la distribuci≤n de software de cifrado a traves de Internet. http://www.heise.de/tp/deutsch/inhalt/te/5117/2.html Hay otra version de Melissa circulando por ahφ. Esta usa las extensiones ".all" de Microsoft Outlook para colgar los sistemas. Inteligente idea, de hecho. http://www.computerworld.com/home/print.nsf/all/990719B50A Este dispositivo de espionaje bastante impresionante esta siendo vendido como un articulo para cualquier consumidor. http://www.x10.com/home/offer.cgi?!ZDX30,../1index761.htm Ha habido un considerable alboroto sobre el plan del gobierno de los Estados Unidos acerca de monitorizar redes privadas por la intrusi≤n, invadiendo toda privacidad en el proceso. (Todo esto serß con el consentimiento de varias compa±ias, asi que las autorizaciones no son necesarias.) Se llama Fidnet, por Red Federal de Detecci≤n de Intrusiones. http://www12.nytimes.com/library/tech/99/07/biztech/articles/28compute.html http://www.zdnet.com/zdnn/stories/news/0,4586,2304083,00.html?chkpt=hpqs014 http://www.sjmercury.com/svtech/news/indepth/docs/secure072999.htm http://techweb.com/wire/story/TWB19990729S0013 http://www.fcw.com/pubs/fcw/1999/0726/web-plan-7-29-99.html http://www.infoworld.com/cgi-bin/displayStory.pl?990730.enstarwars.htm "Protecci≤n de infraestructuras crφticas y la puesta en peligro de las libertades civiles" de EPIC http://www.epic.org/security/infowar/epic-cip.html Copia del plan de la Casa Blanca, y comentario: http://www.cdt.org/policy/terrorism/fidnet/ El ComitΘ de Asignaciones de la Casa ha aprobado un presupuesto de $36 billones para los departamentos de Justicia, Comercio y Estado, pero incluy≤ contenidos especificamente rechazando cualquier gasto en FIDNET. http://www.techweb.com/wire/story/reuters/REU19990730S0005 Y el gobierno de los Estados Unidos se echa atras. http://www.fcw.com/pubs/fcw/1999/0802/fcw-newssecurityside-08-02-99.html AOL ha sido golpeada por un ingenioso ataque de ingenierφa social. Este mensaje de enga±o, disfrazado como un aviso de enga±o, embauca a los usuarios para que cedan los datos de su cuenta y la informaci≤n de la tarjeta de crΘdito. http://www.zdnet.com/zdnn/stories/news/0,4586,2303536,00.html El FBI estß impidiendo a CMI Communnications, una compa±φa Canadiense, ofrecer servicio de telΘfono por satΘlite en los Estados Unidos porque el FBI no puede realizar escuchas en las llamadas. http://www.nationalpost.com/financialpost.asp?f=990716/29896.html California ha adoptado una nueva ley sobre firma digital, permitiendo el uso de e-mail firmados para los contratos. http://www.computerworld.com/home/news.nsf/all/9907294dig El caso contra Kevin Mitnick ha sido finalmente desestimado. http://www.msnbc.com/news/178825.asp El congresista Porter Goss (Republicano) quiere ofrecer un respiro en los impuestos a las compa±φas que desarrollan productos de cifrado que permiten recuperaci≤n de claves u otros metodos de proporcionar al gobierno acceso a las claves de cifrado. http://www.wired.com/news/news/politics/story/21014.html Una nueva vulnerabilidad en Excel permite a una hoja de calculo maliciosa ejecutar c≤digo arbitrario sin el permiso del usuario. http://www.securityportal.com/list-archive/bugtraq/1999/Jul/0268.html http://www.zdnet.com/zdnn/stories/news/0,4586,2305495,00.html?chkpt=hpqs014 http://officeupdate.microsoft.com/Articles/mdac_typ.htm El Comisionado para la Informaci≤n y la Privacidad de Ontario ha publicado un panfleto que recomienda que cualquiera que use e-mail, aprenda a comprender y a utilizar el cifrado. http://www.ipc.on.ca/Web_site.ups/MATTERS/SUM_PAP/PAPERS/encrypt.htm Y una ·ltima noticia de Microsoft. Para ayudar a salvar su reputaci≤n, Microsoft puso un servidor con una beta de Windows 2000 en el exterior de su firewall, y desafi≤ a los hackers a entrar en el. El problema fue que el servidor no pudo aguantar el suficiente tiempo para que alguien siquiera lo intentara. http://www.zdnet.com/zdnn/stories/news/0,4586,2309474,00.html?chkpt=hpqs014 http://www.windows2000test.com/ 4. Noticias desde Counterpane Systems -------------------------------------- Por Bruce Schneier Traducci≤n: David G≤mez Counterpane Systems ha cambiado su nombre a Counterpane Internet Security, Inc. Hemos recibido fondos de capital empresarial de Accel Partners y Bessemer Ventures, y estamos en el proceso de crear una serie de ofertas de servicios en el area de la seguridad gestionada. Cualquiera interesado en trabajar para Counterpane en la zona del Area de la Bahia deberia contactar conmigo inmediatamente. Vigila este espacio para mas detalles. Esta va a ser la mejor compa±φa de seguridad que nunca has visto. PasswordSafe gana el premio de elecci≤n de los editores de PC Magazine: http://www.zdnet.com/pcmag/stories/reviews/0,6755,2311193,00.html Bruce Schneier retratado en guru.com: http://www.guru.com/profiles_schneier.html Vulnerabilidad del PPTP de Microsoft discutida: http://www.zdnet.com/sr/stories/news/0,4538,2293711,00.html Bruce Schneier estarß hablando en la Network Expo de Escandinavia, en la tarde del 14 de Septiembre y luego el 15 de Septiembre. http://www.networkstelecom.com/index_eng.html http://www.firedoor.se/bruce/bruce.var 5. Novedades desde el NIST sobre AES -------------------------------------- Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna (N.del T.: NIST - National Institute of Standards and Technology, Instituto Nacional de Estßndares y Tecnologφa) (AES - Advanced Encryption Standard, Estßndar de Cifrado Avanzado) AES es el Estßndar de cifrado Avanzado, el algoritmo de cifrado que debe reemplazar a DES. En 1997 el gobierno de los Estados Unidos (NIST realmente), solicit≤ algoritmos candidatos para convertirse en este estßndar. En Junio de 1998 (la fecha lφmite de envφo), NIST habφa recibido quince propuestas. NIST solicit≤ comentarios acerca de estos algoritmos, con el objetivo de reducir la lista a cinco finalistas. NIST convoc≤ una conferencia en Roma en Abril (esta era la segunda conferencia AES, la primera tuvo lugar en Agosto anterior en California), la fecha lφmite para los comentarios era Junio y el pasado Lunes NIST dio a conocer los finalistas. Son los siguientes: Mars, presentado por un amplio equipo de IBM. RC6, de RSA Data Security(incluyendo a Ron Rivest) Rijndael, de un equipo de excelentes cipt≤grafos belgas. Serpent, de tres cript≤grafos muy respetados; Ross Anderson, Eli Biham y Lars Knudsen TwoFish, de Counterpane Systems, incluido yo mismo NIST no solo anunci≤ los cinco finalistas. Publicaron un informe de 52 pßginas en el que explican sus razonamientos -- por quΘ seleccionaron los algoritmos elegidos y por quΘ no seleccionaron los no elegidos -- y vale la pena leerlo para asomarse a su proceso de decisi≤n. El siguiente paso es elegir entre los finalistas. NIST solicita de nuevo comentarios sobre estos algoritmos, y habrß una tercera Conferencia de Candidatos AES en New York en Abril del 2000, convocada conjuntamente con el 7║ encuentro de trabajo de Software Rßpido de cifrado. Los comentarios deben remitirse antes del 15 de Mayo del 2000 y entonces NIST propondrß un estßndar. El AES entonces pasarß al proceso de aprobaci≤n de estßndares del gobierno y se convertirß en un Estßndar Federal de Procesamiento de Informaci≤n (FIPS, Federal Information Processing Standard), y presumiblemente se convertirß en el algoritmo estßndar de cifrado para todo tipo de aplicaciones internacionales. Se espera que todo esto suceda para el verano del 2001; el gobierno se mueve lentamente. Los cript≤grafos estßn muy ocupados analizando la seguridad. Podemos pensar en el proceso como si se tratara de un gran derby de demolici≤n: todo el mundo envφa sus algoritmos y entonces se dedica a atacar los de los otros... el ·ltimo que resista gana. Realmente, no serß tal y como lo hemos descrito. Cuando finalice el periodo de anßlisis, no espero que se encuentren debilidades importantes en ninguno de los finalistas. La elecci≤n del ganador se basarß en otros factores: rendimiento, flexibilidad, idoneidad. Esto significa que necesitamos vuestra colaboraci≤n en este proceso. Ya sΘ que no sois cript≤grafos, y que no sereis capaces de realizar comentarios acerca de las matemßticas de cada uno de los algoritmos candidatos. Pero sφ podeis informar acerca de vuestras necesidades de cifrado, y si los algoritmos en estudio se ajustan a dichas necesidades. AES tendrß que trabajar en una variedad de aplicaciones presentes y futuras, realizando todo tipo de diferentes tareas de cifrado: microprocesadores de 32 bits, microprocesadores de 64 bits, peque±as tarjetas inteligentes de 8 bits, DSPs, FPGAs, ASICs a medida y cualquier otra cosa que a·n no podamos imaginar. Seleccionar un solo algoritmo para todas estas aplicaciones no es fßcil, pero es lo que tenemos que hacer. Podrφa tener mßs sentido tener una familia de algoritmos, cada uno optimizado para una aplicaci≤n particular, pero habrß s≤lo un AES. Y cuando AES se convierta en un estßndar, los clientes querrßn que sus productos de cifrado cumplan "el estßndar de moda". Los solicitarßn en el hardware, en los ordenadores de sobremesa, en las tarjetas inteligentes, en terminales de comercio electr≤nico y en otros sitios en los que jamßs hubiΘsemos pensado que podrφan ser usados. Cualquier cosa que elijamos para AES deberß trabajar en todas estas aplicaciones. ┐C≤mo podeis enviar vuestros comentarios? NIST estß aceptando comentarios formales tanto en papel como a travΘs de correo electr≤nico. Podeis acudir en busca de instrucciones a la pßgina http://www.nist.gov/aes. Aseguraos de identificar a quiΘn representais y quΘ intereses criptogrßficos teneis. Recordad una cosa, AES va a ser vuestro estßndar criptogrßfico para el siglo 21. Necesitamos vuestra ayuda. Pßgina NIST de la segunda vuelta: http://csrc.nist.gov/encryption/aes/round2/round2.htm FSE 2000: http://www.counterpane.com/fse.html Comparaci≤n de rendimiento de los candidatos AES: http://www.counterpane.com/aes-performance.html Una versi≤n de este trabajo aparece en: http://www.zdnet.com/zdtv/cybercrime/features/story/0,3700,2312895,00.html 6. En la ratonera: HPUX y el algoritmo Crypt de UNIX ---------------------------------------------------- Por Bruce Schneier Traducci≤n: Angel Galindo Sßnchez Vamos a hacer una comparaci≤n entre las pßginas de los manuales de Solaris y HPUX, sobre la funci≤n de cifrado de UNIX "crypt". Mismo algoritmo, diferentes interpretaciones, diferentes conclusiones. Seg·n la pßgina del manual de Solaris 2.6 correspondiente a la funci≤n crypt, "crypt implementa una mßquina de un rotor dise±ada de acuerdo a las directrices de la alemana Enigma, pero con un rotor de 256 elementos. Los mΘtodos de ataque a esas mßquinas son ampliamente conocidos, por tanto crypt proporciona una seguridad mφnima". Seg·n la pßgina del manual de HPUX10.20 correspondiente a la funci≤n crypt, "crypt implementa una mßquina de un rotor dise±ada de acuerdo a las directrices de la alemana Enigma. Los mΘtodos de ataque a esas mßquinas son conocidos, pero no ampliamente; en todo caso, la cantidad de trabajo necesario para ello es previsible que sea mucho". De la lectura del manual de HPUX, se tiene la impresi≤n de que crypt ofrece una protecci≤n adecuada para los ficheros. Es un hecho triste el que algoritmos criptogrßficos que se rompen como tarea para casa por los estudiantes de criptografφa, sean recomendados como mΘtodo de protecci≤n de datos por un vendedor de sistemas operativos para grandes mßquinas. 7. Correo cifrado vφa Web ---------------------------------- Por Bruce Schneier Traducci≤n: Angel Galindo Sßnchez La idea es atractiva. De la misma manera que puedes conectarte a Hotmail con tu navegador para enviar y recibir correo electr≤nico, hay sitios web para enviar y recibir coreo electr≤nico cifrado. Hushmail, ZipLip, YNN-mail, Zixmail. No hay que bajarse e instalar ning·n software... simplemente, funciona. Pero, ┐c≤mo de bien? Hushmail (http://www.hushmail.com) es bßsicamente una aplicaci≤n de e-mail tipo PGP o S/MIME que utiliza Java (aunque, extra±amente, Hushmail no es compatible con ninguno de ellos). El remitente se conecta al sitio web de Hushmail, y cifra el mensaje utilizando un applet de Java que se carga automßticamente en la mßquina cliente. Tanto el remitente como el receptor necesitan tener cuentas en Hushmail para que funcione. Las cuentas pueden ser an≤nimas. Los algoritmos son ElGamal de 1024 bits para el intercambio de claves y la firma, y Blowfish para el cifrado del texto. Pero la llave privada de todos los usuarios se guarda en el servidor de Hushmail, protegida por una contrase±a. Esto significa que, presumiblemente, un punto dΘbil serß la contrase±a; es la ·nica protecci≤n que se tiene contra cualquiera que legal o ilegalmente tenga acceso al servidor de Hushmail. (La versi≤n beta actual - Agosto 99 - no te permite cambiar la contrase±a, aunque prometen que existirß esa opci≤n en el futuro). Otro punto dΘbil es el applet de Java. Cuando lo cargas, no tienes ni idea de si es o no el applet correcto. Sφ, el c≤digo fuente es p·blico, pero eso no te sirve de ninguna ayuda cuando estßs en un terminal p·blico de internet tratando de cifrar o descifrar un e-mail an≤nimo. Un applet troyano de Java puede causar todo tipo de da±os, y no hay forma de saberlo. Por supuesto, puedes utilizar una conexi≤n SSL entre tu ordenador y el servidor de Hushmail, pero si no compruebas los detalles del certificado recibido, no tienes ni idea de a quien estßs conectado. Hushmail estß considerando el programar algo que verifique el applet automßticamente, pero ┐c≤mo se puede confiar en el verificador?. Este es un gran problema. El applet puede estar firmado, pero, ┐quiΘn lo firm≤?. Incluso si compruebas el certificado, los navegadores tφpicos permiten por defecto una docena de PKI de raiz, y cualquiera de ellos puede proporcionar un certificado falso. Esto significa que debes tener confianza en todos ellos. Y debes estar seguro de que un troyano no te ha introducido un certificado falso en tu navegador. N≤tese que un verificador descargado de la red nunca resolverß este problema; Θsto transforma la pregunta "┐c≤mo puedo confiar en el applet?" en "┐c≤mo puedo confiar en el verificador?". Un tercer posible punto dΘbil es la localizaci≤n de los servidores de Hushmail. Aunque la empresa estß en Antigua, los servidores estßn en Canadß. Presumiblemente, Canadß es mßs susceptible a los ataques legales. Y recuerde que la seguridad depende de la protecci≤n fφsica del servidor de Hushmail. Teniendo todo esto en cuenta, en mi opini≤n, Hushmail parece una implementaci≤n razonable de la idea. La empresa parece que sabe lo que hace, tiene un sitio web que informa razonablemente y responde adecuadamente a las cuestiones de seguridad. ZipLip (http://www.ziplip.com) es diferente. Ninguna de las dos partes necesitan una cuenta para comunicarse. El emisor se conecta al sitio web de ZipLip y, utilizando SSL, envφa un mensaje a otra persona. ZipLip envφa entonces al receptor un mensaje diciendo que tiene un mensaje esperßndole. El receptor se conecta a ZipLip y recibe el mensaje. El cifrado, aparte de las dos conexiones SSL, es completamente opcional. ZipLip no dice quΘ algoritmo de cifrado utiliza, lo que es suficiente para desecharlo sin necesidad de mßs anßlisis. Pero hacen algo incluso mßs est·pido; permiten que el remitente cree una llave de cifrado y dan al receptor una "pista" para que pueda adivinarla. El propio web de ZipLip sugiere: "El nombre del proyecto en el que estamos trabjando" o "el restaurante en el que cenamos anoche". Quizßs haya unos 100.000 restaurantes, es decir, es una clave de 17 bits. Las amenazas son serias. Tanto el emisor como el receptor necesitan verificar sus conexiones SSL, si no, no habrß ning·n tipo de seguridad. El servidor de ZipLip es un magnφfico objetivo para ser atacado, tanto porque muchos mensajes no serßn cifrados como porque los que lo estΘn tendrßn claves debilitadas por el hecho de que ambas partes deben ser capaces de recordarlas. En el lado de las ventajas, ZipLip sigue la polφtica de borrar todos los mensajes 24 horas despuΘs de ser enviados, lo que proporciona un nivel de inmunidad frente a abogados que Hushmail no tiene... si es que lo implementan adecuadamente. YNN-mail (http://www.ynnmail.com) no merece ni siquiera este pßrrafo. Cifran los mensajes almacenados con una llave de 40 bits, y no utilizan SSL cuando se firma y envφa una contrase±a de larga duraci≤n. El mejor aceite de serpiente que he visto. Acabo de recibir noticias de otro, ZixMail (http://www.zixmail.com). No he tenido tiempo de examinarlo en profundidad, pero el FAQ -atenci≤n a sus comentarios sin sentido sobre cifrado- hace que suene tambiΘn a genuino aceite de serpiente. El correo electr≤nico cifrado basado en web es menos seguro que el correo cifrado con PGP (o e-mail tipo S/MIME) por varias razones. Uno, la interacci≤n constante entre los comunicantes y el servidor deja mßs oportunidades a los ataques de los intermediarios, troyanos, etcΘtera. Dos, la autenticaci≤n basada en SSL es muy vulnerable a la falsificaci≤n, ya que casi nadie se preocupa de comprobar los detalles de los certificados que ha recibido y no existe ning·n mecanismo de revocaci≤n. Y tres, hay algunos objetivos muy atractivos para los atacantes: servidores con una gran cantidad de e-mail secreto y potenciales llaves de cifrado. Ciertamente, el e-mail cifrado basado en web es mejor que el e-mail descifrado, pero prefiero PGP o S/MIME, si es posible. Este artφculo fue escrito con la aportaci≤n de Fred Wamsley. Una versi≤n de este artφculo aparece en: http://www.zdnet.com/zdnn/stories/comment/0,5859,2314064,00.html 8. Comentarios de los lectores ------------------------------- Por Bruce Schneier Traducci≤n: Isidre Marques Serret y Sergio Pozo Hidalgo De: "Couvares, Peter F." peter.couvares@tdstelecom.com Tema: Crypto-hacking ------------------------------------------------------- Por lo que parece se le han adelantado - - Puedo encontrar por lo menos cuatro lugares donde se ha usado ya la expresi≤n "cripto-hacking" o "criptohacking". Google encontr≤ los siguientes, entre otros: http://cc2.gamestats.com/wwwboard/mensajes/894.html http://www.hotwired.com/hablar/club/especialidad/copias/96-03-13.levy.html Todos ellos parecen usarlo en el sentido de jaquear un sistema que emplea criptografφa, en lugar de jaquear criptografφa en sφ misma, sin embargo su definici≤n es mßs ·til como contribuci≤n al vocabulario. De: John Savard Tema: ┐Alarma sin motivo?. No estoy tan seguro. ------------------------------------------------- Ciertamente estoy de acuerdo en que los militares puede permitir sin riesgo que su informaci≤n p·blica estΘ almacenada en servidores web comerciales. Sin embargo, he notado que muchas pßginas militares estßn en servidores propiedad del gobierno de los EE.UU. bajo el dominio .mil. Y es difφcil, particularmente usando sistemas operativos y software de servidores de Internet disponibles comercialmente, mantener el tipo de seguridad inexpugnable necesaria en cualquier sistema que tambiΘn contenga informaci≤n sensible. Hay formas de crear un servidor de Internet esencialmente inmune a la mayorφa de los tipos de ataques. Los servidores Macintosh, al no tener un CLI, parecen ser bastante seguros. Pero hay otras tΘcnicas, la mayorφa de las cuales requieren software, e incluso hardware, especializado. Por ejemplo, podemos aprovechar una idea de la compa±φa telef≤nica, ┐quΘ tal un ordenador con dos CPUs?. La CPU n·mero 1 estß conectada al disco duro que contiene el software para el ordenador, y tiene la posibilidad de leer y escribir en toda la memoria RAM. La CPU n·mero 2 es la que se conecta a la red y tiene acceso de s≤lo lectura a la zona de memoria desde la que ejecutan programas. Pero tiene una zona de memoria de lectura-escritura para almacenar datos y acceso de s≤lo lectura a un disco duro conteniendo el sitio web que va a presentarse a Internet. Si Θste tambiΘn tiene datos que almacenar, obtiene acceso de escritura a un disco duro para ello. El acceso viene dado por ôconexiones fφsicasö, no por privilegios del sistema operativo, que pueden ser alterados. En la mayorφa de los sistemas operativos, sean los de Microsoft o los clones de UNIX, los servicios de red forman parte del sistema operativo, y la conexi≤n TCP/IP a Internet es parte de esa red. Tienen que limitarse explφcitamente sus privilegios, y si alguien consigue privilegios de Administrador o acceso de root puede eliminarse esta limitaci≤n. Esto no deberφa suceder, pero cualquier fallo en el sistema operativo es una posible puerta trasera. Ahora, supongamos en lugar de lo anterior que los S.O. ni siquiera TUVIERAN servicios de red incluidos. Que el puerto conectado a Internet fuera algo de lo que el S.O. ni siquiera supiera que existe, y que todo ese puerto estuviera bajo el control de un ôprograma de aplicaci≤nö sin ninguna clase de privilegio. A·n cuando el S.O. no tuviera ning·n tipo de seguridad, pongamos por ejemplo que fuera MS-DOS, con precauciones contra ataques tales como el desbordamiento de buffer, un programa de aplicaci≤n con capacidades estrechamente limitadas y enfocadas podrφa ser bastante seguro. Aunque nadie llega a estos extremos y aunque tambiΘn es cierto que la vigilancia constante y el uso de mΘtodos de seguridad mßs convencionales (es decir los cortafuegos) pueden dar una seguridad "bastante buena", creo que estß perfectamente justificado que el Pentßgono adopte esa actitud de que el tipo de seguridad ôblindadaö que necesitan simplemente no estß disponible si uno se conecta a Internet. Estoy bastante seguro de que la NSA (National Security Agency û Agencia de Seguridad Nacional) o quien quiera pueda surgir con un "super-cortafuegos" que pudiera actuar como anfitri≤n de un sitio Web p·blico, y a·n asφ ser actualizado desde dentro de una red de ordenadores altamente sensible, con toda seguridad. Pero harφan falta tecnologφas como la esbozada arriba con dos CPUs, que simplemente no estßn disponibles en el mercado. Y es la tecnologφa no disponible en el mercado la que se ha venido utilizando para mantener la presencia de los militares en la red. Asφ que aunque es cierto que hay formas de que los militares se conecten y mantengan su seguridad, tambiΘn es verdad que no estßn inmediatamente disponibles. Desconectar algunos sitios de la Web, hasta que las vulnerabilidades puedan remediarse, no es una polφtica est·pida, a·n cuando puede haber algunos casos concretos incomprensibles en los que sitios sin ning·n riesgo son desconectados. De: dragon@revealed.net Tema: Re: Alarma injustificada ---------------------------------------- Acabo de leer su mensaje sobre el estudio del EjΘrcito acerca de retirarse de la red, y he creφdo que debφa hacer unos comentarios. En concreto estoy en desacuerdo con la pßgina que cree que ha hecho ôun buen anßlisis de una idea est·pidaö. Si bien estoy de acuerdo que la reacci≤n de cerrar la conexi≤n a Internet simplemente porque la compa±φa X lo ha hecho no es prudente, creo que en una organizaci≤n con un personal educado en la seguridad, hay ocasiones en que es aconsejable el corte temporal de la conexi≤n. Concretamente, colaborΘ en tomar esta decisi≤n en una de las compa±φas con las que trabajo; estßbamos preocupados con dos puntos en especial: 1) ya que Melissa se propagaba por medio del e-mail con poca intervenci≤n humana, decidimos cortar el acceso hasta que hubiΘramos conseguido el control suficiente sobre su propagaci≤n interna para no propagarlo a nuestros asociados en la forma que otras compa±φas grandes habφan hecho con nosotros, y 2) dar a nuestros administradores el respiro para ser capaces de comprender racionalmente el impacto que representaba sobre nuestros sistemas de producci≤n y para implementar las actualizaciones/correcciones que nos llegaban desde nuestros proveedores. No sΘ como nadie puede decir que es de idiotas desconectarse de Internet cuando uno se enfrenta a un ataque que es, ademßs de importante en el alcance, relativamente desconocido en su funcionamiento. Sφ, podrφa llegar a considerarse que es ser paranoide, xen≤fobo, y reaccionario, y si bien es cierto que no es necesariamente mßs seguro estar conectado cualquier otro dφa, pero negar a los encargados de la seguridad la posibilidad de levantar el puente levadizo hasta que la amenaza inmediata se identifique por lo menos, nos limita hasta el punto en que realmente no seamos capaces de funcionar. Finalmente, tengo que decir que estoy de acuerdo con por lo menos una parte de la decisi≤n de los militares de retirarse. El hecho es que indicaron que intentaban corregir la situaci≤n de algunos datos delicados. Hay mucha informaci≤n, militar o de otros tipos, que no tiene ning·n lugar en la Internet p·blica. La broma que circula en nuestro departamento es que el ·nico ordenador seguro es el que estß apagado, fundido en una masa, encajado en hormig≤n, y enterrado en el fondo del ocΘano. Sus propios escritos muestran que ni siquiera la criptografφa es completamente segura debido a los adelantos en las matemßticas y los ataques por canales colaterales. Hay muchas, muchas circunstancias en que la sensibilidad y criticalidad de los datos exige que se encuentren en una red que estΘ totalmente separada de otras, seam esas otras redes la p·blica Internet, Intranets menos seguras, o WANS privadas que conectan a proveedores y clientes. La autΘntica idiotez es poner los datos que deben mantenerse seguros en mßquinas que son accesibles por medio de canales p·blicos o casi p·blicos. De: Jon Williams dragon@revealed.net Asunto: Crackeando ficheros ZIP cifrados ----------------------------------------- Acerca del crackeado de ficheros ZIP: Si bien aplicar fuerza bruta sobre la clave puede funcionar en la mayorφa de los casos para la mayorφa de la gente y consumir menos tiempo, se conoce tambiΘn un ataque de texto plano que s≤lo requiere 13 bytes conocidos. Mire en http://www.unix-ag.uni-kl.de/~conrad/krypto/pkcrack.html para obtener un borrador que describe el ataque y el funcionamiento del software. Yo lo he usado con Θxito. De: "David Brownell" david-b@pacbell.net Asunto: SSL en Wells Fargo ---------------------------------------- La web de Wells Fargo sobre banca a·n usa SSL v2... no soporta navegadores configurados para usar versiones mßs seguras (v3, TLS) e incluso ha rechazado conexiones SSL v2 que no usan RC2 (obsoleto). Estoy seguro de que entiende las consecuencias de usar SSLv2/RC2, incluso cuando se usan llaves de 128-bit; no son tan fuertes como las de otros protocolos/cifradores, por lo menos ante los ataques directos que no son su fuerte. La "simple" chapuza en su web, sin embargo, es que si has adoptado una polφtica tal que no vas a usar SSL v2 para transacciones "seguras", el web de Wells Fargo te dice que tu navegador no es lo suficientemente seguro, y que necesitas obtener uno de 128-bit. No dice "tienes que habilitar una versi≤n obsoleta con un cifrador dudoso"... que es lo que deberφa decir, sencillamente. Dice algo completamente equivocado. Eso era una colecci≤n de chapuzas bßsicas. No olvide el otro tipo, usar una pßgina HTTPS que tiene datos comprometidos en los parßmetros de consulta para su URL, y un enlace http://... que provocarß que todos los datos comprometidos sean registrados en los habitualmente inseguros ficheros de registro. (No tengo ejemplos actuales a mano... pero si ve uno de esos, íes un clßsico!). De: David Crick dacrick@cwcom.net Asunto: SSL en BT --------------------------------- British Telecom (BT) es otra companφa con preocupantes perspectivas sobre la seguridad en Internet. Podrφas pensar que con su imagen y status podrφan hacerlo mejor. Su pßgina web de servicios electr≤nicos (http://www.bthome.com/e_services/index_sh.html) permite a sus usuarios comprobar y corregir varios detalles de su cuenta y sus servicios. Pero a pesar de la expansi≤n de los navegadores con criptografφa fuerte (http://www.opera.com) y actualizaciones de seguridad para IE, Windows y Netscape (http://www.replay.com), BT eligi≤ usar SSL de s≤lo 40-bit. ╔sto estß acompa±ado por el siguiente aval y aviso: "Cuando haga pedidos de mercancφas y servicios, aseg·rese de que la web que estΘ usando utilice una sesi≤n "Secure Socket Layer (SSL). La Tienda en Casa de BT usa una de esas sesiones desde el momento en el que va a enviar un pedido." Ademßs: "Si a·n estß inc≤modo usando la web para hacer pedidos en lφnea, deberφa usar un mΘtodo alternativo para ello." Anima poco, ┐no?. TambiΘn le hace a uno dudar sobre su "Plan de Web Segura": "Las webs de Trustwise usan un certificado de Servidor Seguro de BT para establecer una prueba de identidad del due±o de la web y activar una comunicaci≤n segura entre la web y los visitantes de la misma." BT chequea cuidadosamente la identidad de la organizaci≤n due±a de la web y verifica que estß registrada a esa organizaci≤n. El Plan de Web Segura Trustwise de BT le permite aprender mßs de los webs que visita antes de enviar cualquier informaci≤n comprometida o confidencial." De nuevo, s≤lo pude encontrar SSL de 40-bit operativo a pesar del logotipo de "Trustwise" (mire en http://www.bt.com/Talk/). De: Ross Anderson Ross.Anderson@cl.cam.ac.uk Asunto: AES -------------------------------------------- El NIST acaba de anunciar que los finalistas de la competici≤n del Estßndar Avanzado de cifrado (Advanced Encryption Standard, AES) son MARS, RC6, Rijndael, Serpent y Twofish. Eso hace 3 algoritmos estadounidenses, uno belga, y uno que desarrollΘ en colaboraci≤n con unos colegas en Israel y Noruega. Puede ser interesante que bajo los controles de exportaci≤n de intangibles que el DTI inglΘs puso en su borrador, el cual estßn intentando ahora que sea adoptado como una regulaci≤n de la UE, habrφa necesitado una licencia personal de exportaci≤n del DTI para hacer este trabajo. Parece poco probable que una licencia de este tipo me hubiera sido concedida. Las autoridades de exportaci≤n me confesaron que los oficiales del DTI son conocidos por bloquear licencias para castigarlas por "ofensas" como querella contra su proceso de licenciaciamiento. Quizß no habrφa terminado el trabajo; quizß habrφa desafiado a la ley y ahora estarφa envuelto en un enorme caso de prueba en la Corte Europea; quizß no hemos investigado en colaboraci≤n con extranjeros. ┐QuiΘn sabe?. ----------------------------------------------------------------- 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. CriptoGRAMA s≤lo puede ser redistribuida de forma completa (esta nota incluida). KRIPT╙POLIS http://www.kriptopolis.com Equipo de Traductores de Kript≤polis: * Isidre MarquΘs Serret <ismase@mx3.redestb.es> * Juan Ruiz de Gauna Gorostiza <juancruz.ruiz@unavarra.es> * JosΘ Luis Martφn Mas <jlmartin@lander.es> * Antonio Muntaner <mmg@balears.net> * Angel Galindo <agalindo@lacaja.net> * Jaime Millßn de Castro <us_jaime@svalero.es> * Sergio Pozo Hidalgo <sergio.pozo@thepentagon.com> * David G≤mez <davidge@arrakis.es> * Tino <jmilton@arrakis.es> ------------------------------------------------------------------