2000 << Back To criptograma nº 26

KRIPTOPOLIS presenta... _______________________________________________________________ C R I P T O G R A M A _______________________________________________________________ N·mero 26 15 de Junio del 2000 ________________________________________________________________ SUMARIO: 1. SOAP 2. Reimpresiones de CriptoGrama. 3. Noticias. 4. Novedades desde Counterpane. 5. Java y virus. 6. En la ratonera: Infraworks. 7. El Estßndar de Cifrado de Datos (DES). 8. Comentarios de los lectores. -- Ejemplar gratuito distribuido a mßs de 20.000 suscriptores -- ________________________________________________________________ * Suscripci≤n gratuita: http://www.kriptopolis.com/subs.html * Baja conjunta de Criptograma y Boletφn de Kript≤polis: http://www.kriptopolis.com/subs.html * N·meros anteriores: http://www.kriptopolis.com/criptograma/cg.html _________________________________________________________________ 1. SOAP =================================================== Por Bruce Schneier Traducci≤n: David G≤mez http://www.kriptopolis.com/criptograma/0026_1.html SOAP (Protocolo de acesso a objetos simples) es un standard propuesto para enlazar aplicaciones de Internet que se ejecutan en diferentes plataformas, haciendo uso de mensajes XML. SOAP esta dise±ado para conectar programas que se ejecutan en diferentes arquitecturas, independientemente de quΘ Sistema operativo/CPU haya en cada uno. Son bßsicamente llamadas a procedimientos remotos (RPC) que se implementan a travΘs de HTTP con contenido XML. Como no se requiere ninguna seguridad en HTTP, XML o SOAP, es bastante simple suponer que diferentes personas tratarßn cualquier cuesti≤n de seguridad de diferentes maneras, llevando a distintos agujeros en implementaciones distintas. SOAP va a abrir una nueva vφa a las vulnerabilidades de seguridad. SOAP ha sido dise±ado por un pu±ado de compa±φas, pero es instructivo leer las palabras de la misma Microsoft sobre seguridad y SOAP: "Actualmente, los desarrolladores se esfuerzan en hacer que sus aplicaciones distribuidas funcionen en Internet cuando hay firewalls de por medio. Ya que la mayorφa de los firewalls bloquean todos los puertos menos unos pocos, como el puerto 80 estßndar de HTTP, todos los protocolos de objetos distribuidos de hoy en dφa -como DCOM- se ven afectados, ya que dependen de puertos asignados dinßmicamente para la invocaci≤n de mΘtodos remotos. Si se puede convencer al administrador del sistema para abrir un rango de puertos en el firewall, se podrß dejar a un lado este problema siempre que los puertos usados por el protocolo de objetos distribuidos estΘn incluidos." Para complicar las cosas, los clientes de las aplicaciones distribuidas que se encuentran detrßs de otro firewall de la empresa estßn afectados por el mismo problema. Si no configuran su firewall para abrir los mismos puertos, no serßn capaces de usar la aplicaci≤n. Hacer que los clientes reconfiguren sus firewalls para acomodarse a la aplicacion, simplemente no es prßctico. Ya que SOAP se apoya en HTTP como mecanismo de transporte, y la mayorφa de los firewalls permiten el paso de HTTP, no se tendrßn problemas invocando a los puntos finales de SOAP desde el lado que sea del firewall. No hay que olvidar que SOAP hace posible para los administradores del sistema desde configurar los firewalls a selectivamente bloquear las peticiones SOAP haciendo uso de cabeceras HTTP especφficas de SOAP. Pues bien, esos molestos firewalls impiden a las aplicaciones enviarse comandos de una a otra, asi que SOAP permite a los compa±φas ocultar esos comandos como HTTP para que el firewall no se dΘ cuenta. Continuemos con el ejemplo de DCOM. ┐QuΘ pasa si DCOM se ejecuta sobre un firewall? DCOM es el principal protocolo de Microsoft para la comunicaci≤n entre aplicaciones. No es solo usado por programas que estßn dirigidos a ser servidores; es usado para todos los tipos de aplicaciones de escritorio y de acceso remoto. El resultado es que la mßquina media tiene docenas de programas usando DCOM. La mia muestra 48, incluyendo desde "Microsoft PowerPoint Presentation" a "logagent" e incluyendo el llamado "{000C101C-0000-0000-C000-000000000046}"; usted puede ver las suyas yendo a la lφnea de comandos y escribiendo "dcomcnfg". Ahora, hay montones y montones de maneras de hacer seguras las aplicaciones DCOM, asi que quizß todas esas aplicaciones felizmente estßn respondiendo s≤lo a peticiones autenticadas desde la mßquina local. Por otro lado, hay montones y montones de maneras de hacer las aplicaciones DCOM inseguras, asi que quizßs una de ellas esta esperando a que alguien le envφe una petici≤n sin ninguna autenticaci≤n para que sobreescriba ciertos ficheros en mi disco duro. Los firewalls tienen buenas razones para bloquear protocolos como DCOM que vienen de fuentes que no son fiables. Los protocolos que se escabullen de los firewalls no son lo que se necesita. Informaci≤n sobre SOAP http://soap.weblogs.com Documento de Microsoft (el cual incluye los pßrrafos citados): http://msdn.microsoft.com/library/periodic/period00/soap.htm 2. REIMPRESIONES DE CRIPTOGRAMA =================================================== Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mas http://www.kriptopolis.com/criptograma/0026_2.html Aquellos que se hayan suscrito recientemente pueden haberse perdido estos artφculos de n·meros anteriores: Ataques de tiempo, anßlisis del consumo de alimentaci≤n, y otros ataques de "canales alternativos" contra tarjetas inteligentes: http://www.counterpane.com/crypto-gram-9806.html#side La internacionalizaci≤n de la criptografφa, polφtica: http://www.counterpane.com/crypto-gram-9906.html#policy y productos: http://www.counterpane.com/crypto-gram-9906.html#products Las nuevas clases de virus, gusanos, y otras clases de software malicioso: http://www.counterpane.com/crypto-gram-9906.html#viruses 3. NOTICIAS =================================================== Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mas http://www.kriptopolis.com/criptograma/0026_3.html Nuevos tipos de dispositivos de red que se pueden atacar: http://news.cnet.com/news/0-1003-200- 1864025.html?tag=st.ne.ron.lthd.ni (ObsΘrvese la menci≤n del "cifrado de 128 bits", como si eso lo resolviera todo). ---------- Las autoridades que controlan la publicidad en el Reino Unido han denunciado que un folleto de RSA era publicidad enga±osa al decir que el software de cifrado freeware era en cierta forma inadecuado: http://www.asa.org.uk/adj/adj_4765.htm ---------- Un proyecto dedicado a reducir las vulnerabilidades por desbordamiento de buffer: http://www.bell-labs.com/org/11356/libsafe.html ---------- Phreaking moderno: http://www.wired.com/news/business/0,1367,36309,00.html ---------- ┐QuΘ ocurrirφa si gente inteligente se dedicara a escribir virus informßticos?: http://lcamtuf.na.export.pl/worm.txt ---------- Excelente discurso de Dan Geer sobre gesti≤n de riesgos y seguridad: http://www.stanford.edu/~hodges/doc/Geer-RiskManagement.txt ---------- Configurar Microsoft Windows 2000 para usar DES triple con IPSEC no quiere decir que se estΘ usando: http://www.wired.com/news/technology/0,1282,36336,00.html En algunas circunstancias, el software s≤lo emplea DES. Y para empeorar las cosas, en ning·n momento se preocupa de avisar al usuario. ---------- El gobierno canadiense trat≤ de introducir todos los datos que poseen sobre sus ciudadanos en una gran base de datos, incluyendo la informaci≤n de devoluci≤n de impuestos (que, por ley, la Hacienda canadiense no puede entregar a otras ramas del gobierno). http://www.wired.com/news/politics/0,1283,36435,00.html http://www.canoe.ca/CNEWSArchiveMay00/candigest_may16.html http://www.canoe.ca/CNEWSArchiveMay00/candigest_may17.html Pero el plan se ha abandonado: http://www.hrdc-drhc.gc.ca/common/news/dept/00-39.shtml http://www.wired.com/news/politics/0,1283,36649,00.html ---------- Mßs sobre los peligros de confiar en las PKIs: http://www.DGA.co.uk/customer/publicdo.nsf/public/WP-HERESY ---------- El Asistente de Microsoft Office -ese molesto clip que proporciona ayuda en Office- tiene algunas vulnerabilidades penosas en Office 2000. Parece que un atacante puede escribir scripts para el asistente que pueden hacer todo tipo de cosas da±inas, y parece que se puede ejecutar automßticamente esos scripts cuando el usuario haga click en una pßgina web o cuando abra un correo con HTML. Es una sorprendente brecha de seguridad para Microsoft. Debido a que la compa±φa decidi≤ clasificar todos los scripts del Asistente de Office como "seguros", estos scripts pueden hacer todo lo que quieran. Es exactamente el tipo de vulnerabilidad que los autores de virus explotan. Esto no es un error de programaci≤n; es una decisi≤n de dise±o tomada deliberadamente a un nivel muy alto. A·n mßs pruebas de que Microsoft no se toma en serio la seguridad. http://www.zdnet.com/zdnn/stories/news/0,4586,2570727,00.html Un boletφn de Microsoft que quita importancia al asunto: http://www.microsoft.com/technet/security/bulletin/ms00-034.asp Un parche de Microsoft: http://officeupdate.microsoft.com/2000/downloadDetails/Uactlsec.htm ---------- Alguien ha patentado el uso de un c≤digo de barras tatuado para verificar la identidad de una persona. ┐No estaba eso ya en el libro de las Revelaciones 13:16-18? http://patents.uspto.gov/cgi-bin/ifetch4? ENG+PATBIB-ALL+0+946309+0+7+25907+ OF+1+1+1+PN%2f5%2c878%2c155 ---------- Tesis doctoral sobre la incidencia de ataques serios por Internet. Seg·n esta investigaci≤n, ocurre con menos frecuencia de lo que dice la gente: http://www.cert.org/research/JHThesis/Start.html ---------- ┐Cansado de todos esos virus de Microsoft Visual Basic? C≤mo desactivar el Scripting Host: http://www.fsecure.com/virus-info/u-vbs/ ---------- Real Networks demuestra que no aprenden: http://www.vortex.com/privacy/priv.09.15 ---------- Electr≤nica inteligente que sabe d≤nde estß. ┐Se apuesta alguien algo a que nadie ha pensado en la aplicaci≤n que puede tener esta tecnologφa en la seguridad? http://www.telegraph.co.uk/et?ac= 000111464113065&pg=/et/00/5/7/ntac07.html ---------- No me importa que el gobierno de Estados Unidos estudie la privacidad, pero en este caso un estudio de 18 meses ha significado 18 meses de inactividad: http://www.cnn.com/2000/TECH/computing/ 05/22/new.privacy.study.idg/index.html ---------- Seg·n las noticias, la Uni≤n Europea elimin≤ todas las restricciones sobre la tecnologφa de cifrado, a pesar de las protestas de Estados Unidos. http://www.heise.de/tp/english/inhalt/te/8179/1.html La verdad no era tan buena. En una reuni≤n del 22 de mayo, los ministros de Exteriores de la Uni≤n Europea eliminaron la propuesta de su agenda en el ·ltimo minuto. No se dio ninguna explicaci≤n a este cambio de actitud. Funcionarios de Francia y el Reino Unido expresaron reservas sobre la medidad, y los funcionarios han confirmado que Estados Unidos presion≤ a la Uni≤n Europea para que bloqueara la decisi≤n. Que yo sepa, no se ha hecho ninguna declaraci≤n oficial. http://www.wired.com/news/politics/0,1283,36623,00.html ---------- Buen artφculo introductorio sobre cifrado en IEEE Spectrum: http://www.spectrum.ieee.org/pubs/spectrum/0400/enc.html ---------- XML y c≤mo hacerlo seguro: http://www.zdnet.co.uk/news/2000/20/ns-15500.html ---------- La Comisi≤n Federal de Comercio (FTC) desiste en su intento de imponer la autorregulaci≤n en la privacidad en Internet: http://www.zdnet.com/zdnn/stories/news/0,4586,2574082,00.html Informe de la FTC: http://www.ftc.gov/os/2000/05/index.htm#22 ---------- Ingenierφa social en el mundo real: uso de identidades falsas para entrar en edificios del gobierno. http://www.cnn.com/2000/US/05/25/security.breaches.01/index.html La mejor frase es: "'Creo que cualquier demostraci≤n de las vulnerabilidades es buena', dijo la Fiscal General Janet Reno..." Esto, por supuesto, quiere decir que estß a favor del anuncio p·blico completo de vulnerabilidades de red. ---------- Herramienta de espionaje de lo que se teclea: un peque±o dispositivo puede registrar y almacenar en secreto medio mill≤n de pulsaciones de teclas. Se puede ocultar el dispositivo en un teclado o un conector PS/2, y no necesita la instalaci≤n de ning·n software. http://www.zdnet.co.uk/news/2000/12/ns-14347.html ---------- El mito de la seguridad del c≤digo abierto: un ensayo del autor sobre el programa 'open source' Mailman explica por quΘ el c≤digo abierto no es tan seguro como se puede pensar usando agujeros de seguridad de su propio c≤digo como ejemplo. http://developer.earthweb.com/journal/techfocus/052600_security.html Reacciones de Slashdot al ensayo: http://slashdot.org/articles/00/05/28/1838201.shtml ---------- El penoso estado de la CIA y la NSA: http://www.washingtonpost.com/wp-dyn/articles/A22957-2000May28.html ---------- La NPR emiti≤ un reportaje sobre las estaciones de n·meros de onda corta. Se entrevist≤ a Schneier para el reportaje. http://www.npr.org/programs/lnfsound/stories/000526.stories.html ---------- Declaraci≤n de la EFF sobre la Ley de Copyright para el Milenio Digital. Una lectura interesante. http://cryptome.org/dmca-eff.htm ---------- Virus de correo electr≤nico robado del ordenador de un investigador: http://www.herald.co.nz/storydisplay.cfm? storyID=138622&thesection=technology& thesubsection=general ---------- Pennsylvania considera delito difundir un virus informßtico. No sΘ c≤mo afecta esto a los virus de Outlook que se expanden solos. http://www.cnn.com/2000/TECH/computing/ 06/01/virus.crack.down.idg/index.html ---------- SANS presenta las diez mayores vulnerabilidades crφticas de Internet. http://www.sans.org/topten.htm ---------- Se manipularon pruebas del robo con tarjetas de crΘdito de CD Universe, asφ que no se puede llevar a juicio: http://www.msnbc.com/news/417406.asp?cp1=1 4. NOVEDADES DESDE COUNTERPANE =================================================== Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez http://www.kriptopolis.com/criptograma/0026_4.html El servicio de monitorizaci≤n controlada de seguridad de Counterpane ha estado funcionando muy bien durante estos ·ltimos meses. Estamos monitorizando redes de clientes a lo largo de todos los EE.UU. y estamos empezando a pensar en expandirnos a Europa y Asia. Si estß usted interesado en saber c≤mo podemos monitorizar su red, contacte con nosotros en el (888) 710-8175 o en sales@sj.counterpane.com. Entrevista con Bruce Schneier en Information Security Magazine: http://www.infosecuritymag.com/jun2000/junqa.htm La revista Fast Company analiza Counterpane: http://www.fastcompany.com/online/35/ifaqs.html Giga Research publica una opini≤n sobre el servicio de monitorizaci≤n de Counterpane: http://www.counterpane.com/giga.pdf Conferencia sobre tratamiento de incidencias en seguridad informßtica (Primera), 26-30 Junio, Chicago. Bruce Schneier hablarß el 27 a las 2:00 de la tarde y el 28 a las 9:15 de la ma±ana. http://www.first.org/conference/2000/ Congreso de Seguridad PC Week/DCI, 27-29 Junio, Boston. Schneier copreside y darß su conferencia a las nueve de la ma±ana del dφa 29. http://www.dci.com/brochure/secbos/ Encuentros Black Hat, 26-27 Junio, Las Vegas. Schneier hablarß el 26 por la ma±ana. http://www.blackhat.com El sitio SecurityFocus dispone de una entrevista sonora con Bruce Schneier: http://www.securityfocus.com/templates/media.html?id=25 5. JAVA Y VIRUS =================================================== Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez http://www.kriptopolis.com/criptograma/0026_5.html En la conferencia JavaONE, a principios de este mes, Scottt MacNealy realiz≤ un comentario equivocado sobre Java. CNet lo recogi≤ asφ: "En su conferencia en JavaONE McNealy dijo que Java es inmune a virus como "Melissa" e "I Love You" que se han extendido por medio de Microsoft Outlook, una afirmaci≤n que los expertos en seguridad generalmente apoyan." A mφ me parece que los expertos en seguridad no apoyan esa afirmaci≤n, porque es err≤nea. McNealy confunde una aplicaci≤n (Microsoft Outlook) con un lenguaje de programaci≤n (Java). Y confunde fallos de dise±o con fallos de implementaci≤n. Los principales problemas de seguridad de Outlook se basan en que: a) utiliza por defecto "sin seguridad" en muchos casos. b) oculta por defecto informaci≤n vital para evaluar riesgos (por ejemplo, las extensiones de ficheros). c) es demasiado d≤cil a la hora de ser invocado por otros programas para que haga cosas. Todos estos son fallos de dise±o. Es decir, Microsoft Outlook fue dise±ado por Microsoft para tener esos problemas. No son fallos de implementaci≤n, errores cometidos por los programadores a lo largo del desarrollo. El problema fundamental radica en que las implicaciones para la seguridad del dise±o y las caracterφsticas elegidas nunca fueron examinadas con un poco de sensatez. Ninguno de los fallos de dise±o enunciados arriba puede prevenirse o ser tratado de forma segura por el modelo "sandbox" de Java, ni por su mecanismo de polφticas de seguridad ni por ning·n otro aspecto del modelo de seguridad de Java. De hecho, yo mismo podrφa escribir fßcilmente un programa de correo en Java que tuviera idΘnticos fallos de dise±o que Outlook Express. Nada en Java ni en su modelo de seguridad puede prevenir, ni siquiera estorbar, a tal dise±o. Lo que McNealy quizßs quiere hacer notar es la naturaleza permisiva de Microsoft Outlook al ejecutar ficheros adjuntos, y la naturaleza mßs segura de la "sandbox" de Java. Java dispone de recursos especφficos para manejar "applets" potencialmente peligrosas, e intenta ejecutarlas en un modo protegido que limita fuertemente los efectos que puedan tener sobre otras aplicaciones del ordenador anfitri≤n. El equipo de dise±o de Java ha dedicado mucho tiempo a preocuparse de los ejecutables maliciosos y c≤mo evitar que corran a su antojo. Artφculo de CNet: http://news.cnet.com/news/0-1003-200-2026364.html 6. EN LA RATONERA: INFRAWORKS =================================================== Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna http://www.kriptopolis.com/criptograma/0026_6.html Otra compa±φa mßs proclama tener "nueva tecnologφa patentada y revolucionaria" para controlar el uso de datos en los ordenadores de otras personas. Cito su anuncio de prensa: "Esto significa que puede enviar ficheros digitales a cualquier persona sin temor a una redistribuci≤n no autorizada. Por ejemplo, podrφa adjuntar un documento Word o Excel en un correo electr≤nico enviado a cualquiera en cualquier parte, y prohibir que sean reenviados, impresos, copiados o cortados y pegados tanto en su totalidad como cualquier parte de ellos. Usted establece los permisos, y los datos son borrados cuando los permisos caducan. Usted dispone de un control total sobre su propiedad digital." "Si se intenta realizar una operaci≤n ilegal, el fichero se autodestruye. Justo igual que en Misi≤n Imposible. Ninguna otra tecnologφa puede realizar esto." Alguien debiera recordar a esta gente que Misi≤n Imposible es ficci≤n. http://www.infraworks.com/ 7. EL EST┴NDAR DE CIFRADO DE DATOS (DES) =================================================== Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna http://www.kriptopolis.com/criptograma/0026_7.html El Estßndar de Cifrado de Datos (DES) ha sido el algoritmo mßs popular de cifrado durante los ·ltimos veinticinco a±os. Originalmente desarrollado por IBM Corporation, fue elegido por la Oficina Nacional de Estßndares (National Bureau of Standards, NBS) como el algoritmo estßndar de cifrado del gobierno en 1976. Desde entonces, se ha convertido en un estßndar de cifrado domΘstico e internacional, y ha sido utilizado en miles de aplicaciones. Las preocupaciones por la escasa longitud de su clave han perseguido al algoritmo desde sus inicios, y en 1998 fue construida una mßquina capaz de romper el algoritmo mediante fuerza bruta. Hoy dφa, modificaciones a DES, como triple-DES, aseguran que continuarß siendo seguro en un futuro inmediato. En 1972, el NBS (renombrado posteriormente como el Instituto Nacional de Estßndares y Tecnologφa, National Institute of Standards and Technology, NIST) inici≤ un programa para proteger los ordenadores y las comunicaciones de datos. Como parte del programa, querφan estandarizar dicha protecci≤n en un ·nico algoritmo de cifrado. DespuΘs de dos solicitudes p·blicas de algoritmos, recibieron un candidato de IBM basado en investigaciones realizadas en sus laboratorios de Yorktown Heights y Kensington. Entre la gente que trabaj≤ en este candidato se encontraban Roy Adler, Don Coppersmith, Horst Feistel, Edna Grossman, Alan Konheim, Carl Meyer, Bill Notz, Lynn Smith, Walt Tuchman y Bryant Tuckerman. El algoritmo, aunque complicado, era bastante directo. Utilizaba s≤lo operaciones l≤gicas simples sobre peque±os grupos de bits y podφa ser implementado bastante eficientemente sobre el hardware existente a mediados de los 70. DES no es muy eficiente al ser implementado por software, especialmente en arquitecturas de 32 bits que son las mßs comunes hoy dφa. Su estructura general era algo llamado una red Feistel, tambiΘn usada en otro dise±o de IBM llamado Lucifer. DES es un cifrado de bloques, lo que quiere decir que cifra y descifra los datos en bloques: bloques de 64 bits. DES es un cifrado repetitivo, lo que significa que contiene 16 iteraciones (llamadas vueltas) de un cifrado simple. La primera fortaleza del algoritmo viene de algo llamado una Caja-S (S-box), una operaci≤n de b·squeda sobre una tabla no lineal por la que grupos de seis bits serφan reemplazados por grupos de cuatro bits. Estas b·squedas en tablas se expresaban como cadenas de constantes. NBS carecφa de capacidad para evaluar el algoritmo, por lo que solicitaron ayuda de la Agencia Nacional de Seguridad (NSA). La NSA hizo dos cosas: cambiaron las constantes de las Cajas-S, y redujeron el tama±o de la clave desde el original de 128 bits hasta 56 bits. El algoritmo revisado, llamado DES, fue publicado por el NBS en Marzo de 1975. Hubo considerables protestas p·blicas, tanto referidas a la "mano invisible" de la NSA -los cambios que realizaron no se hicieron publicos y no se dio ninguna explicaci≤n respecto a las constantes de las Cajas-S- como a la corta longitud de la clave. Originalmente se suponφa que la longitud de la clave se reducφa a 64 bits, pero cuando se public≤ el estßndar, convertφa 8 de estos bits en "bits de paridad" usados para confirmar la integridad de los otros 56 bits, y no como parte de la clave. A pesar de las crφticas, DES fue adoptado como un Estßndar Federal de Procesamiento de Informaci≤n en Noviembre de 1976. Era la primera vez que un algoritmo de cifrado evaluado por la NSA se hacφa p·blico, y fue uno de los dos desarrollos mßs importantes que estimularon el desarrollo de la investigaci≤n de cifrado p·blico (el otro fue la invenci≤n del cifrado de clave p·blica). DespuΘs de convertirse en un estßndar del gobierno de los EE.UU., DES fue adoptado por otros organismos de estßndares a lo ancho de todo el mundo, incluyendo ANSI e ISO. Se convirti≤ en el algoritmo de cifrado estßndar en la industria bancaria, y fue usado en muchas aplicaciones en todo el mundo. Los tΘrminos del estßndar estipulaban que debφa ser revisado y recertificado cada cinco a±os. El NBS recertific≤ DES por primera vez en 1987. NIST (como es conocido NBS tras cambiar su nombre) recertific≤ DES en 1993. En 1997 inici≤ un programa para reemplazar a DES: el Estßndar Avanzado de Cifrado (AES). La implicaci≤n de la NSA en los valores de las Cajas-S sali≤ a la luz a comienzos de los 90. Dos cript≤grafos israelφes, Eli Biham y Adi Shamir, inventaron un potente ataque criptoanalφtico llamado "criptoanßlisis diferencial", y mostraron que las Cajas-S habφan sido optimizadas para resistir este ataque, hasta aquel momento a·n desconocido. Mßs tarde se hizo p·blico que el propio equipo de IBM habφa desarrollado este ataque mientras creaban Lucifer y DES, y que la NSA habφa declarado secreta su investigaci≤n. A finales de los 90, se extendi≤ ampliamente la sospecha de que la NSA era capaz de romper DES probando todas las posibles claves, algo llamado criptoanßlisis por "fuerza bruta". Esta posibilidad fue grßficamente demostrada por la Fundaci≤n de Fronteras Electr≤nicas en Julio de 1998, cuando John Gilmore construy≤ una mßquina de 250.000 d≤alres capaz de romper claves DES mediante fuerza bruta en s≤lo unos dφas. A±os antes de esto, aplicaciones mßs seguras ya lo habφan convertido en un algoritmo de cifrado llamado triple-DES (tambiΘn conocido como 3DES). Triple-DES es la aplicaci≤n repetida de tres cifrados DES, usando dos o tres claves diferentes. Este algoritmo afianza toda la seguridad de DES ya que alarga efectivamente la longitud de la clave, y goza de un amplio uso hoy en dφa para proteger toda clase de secretos personales, de negocios y financieros. DES es el algoritmo mßs importante realizado jamßs. Como disponφa de un pedigree NSA se crey≤ ampliamente que era seguro. Es tambiΘn el algoritmo de cifrado mßs estudiado que se ha inventado jamßs, y muchos cript≤grafos "fueron a la escuela" sobre DES. Casi todos los nuevos algoritmos usados hoy en dφa hunden sus raφces en DES, y todavφa en la actualidad se publican documentos analizando diferentes aspectos de DES. 8. COMENTARIOS DE LOS LECTORES =================================================== Por Bruce Schneier http://www.kriptopolis.com/criptograma/0026_8.html De: "J. Christopher Williams" (jcw@datarave.com) Asunto: Artφculo de Phil Agre sobre los gusanos de Outlook --------------------------------------------------------------------- Traducido por Jes·s Reyes Phil Agre escribi≤: "He recibido alrededor de 60 copias del ·ltimo virus de correo electr≤nico de Microsoft y sus variantes. ┐Cußntos recibi≤ Usted? Afortunadamente gestiono mi correo electr≤nico con el mailx de Berkeley y las macros de teclado de Emacs, por lo que estuve fuera de peligro. Aunque si hablamos de los miles de millones de d≤lares en da±os, equivalentes a millones de dφas de trabajo perdidos, entonces creo que tenemos que tener una peque±a charla con Microsoft." Aunque muchos pudieran considerar los comentarios anteriores relevantes para el asunto que tenemos entre manos, utilizar productos de marca como mΘtodo de asegurar sus ordenadores me parece una exageraci≤n. El hecho es que hay varias formas de evitar tales virus y gusanos, algunas de las cuales no requieren ning·n producto software adicional. Estoy de acuerdo en que serφa estupendo si estas caracterφsticas estuvieran habilitadas por defecto. Lo ·nico que podrφa ser usado para prevenir una infecci≤n de virus, no mencionado por el autor, es el cerebro humano. Extra±o, considerando que es el arma de elecci≤n. "... Esto es un comportamiento por dise±o, no un problema de vulnerabilidad de la seguridad. "Mßs lenguaje raro. Es como decir, æ Esto es una roca, no algo que pueda caer al sueloÆ. Es confuso hasta pensar en ello..." El autor puede que sea un experto en seguridad o en informßtica, pero su comprensi≤n de la gramßtica bßsica es bastante pobre. La conversi≤n gramatical correcta deberφa ser: "Esto es un objeto lanzado al suelo, no un objeto en caφda libre". La afirmaci≤n por sφ sola simplemente ayuda a definir quΘ puede ser llamado "lanzado" y quΘ puede ser llamado objeto en "caφda libre". No es err≤nea, a menos que el lector crea en alg·n tipo de campa±a de desinformaci≤n que el autor sugiere. Para mφ el autor estß aparentemente empleando la misma tßctica de "echar la culpa a otro" de la que acusa a Microsoft. "...Esta particular tßctica de echarle la culpa a otro es especialmente falsa, dado que el virus se propag≤ a travΘs de la propia Microsoft, hasta tal punto, que la compa±φa tuvo que bloquear todo el correo entrante (Wall Street Journal 5/5/00)..." Mi compa±φa tuvo menos de 20 empleados infectados sobre un total de mßs de 1600 empleados en todo el paφs, y sin embargo tambiΘn cerramos nuestros servidores Exchange. Hagamos una comparaci≤n estadφstica: cada empleado en la oficina en la que trabajo dispone de un ordenador, sin ninguna excepci≤n. Nosotros experimentamos un crecimiento de mßs de 250 empleados en los ·ltimos 90 dφas, previendo que se doble la cifra de empleados de partida en los pr≤ximos 90 dφas. Otras oficinas se cuidan de estar equipadas de una forma similar, aunque su crecimiento sea diferente. La decisi≤n a tomar, estuvo basada mßs en la posibilidad de infectar a ordenadores que no eran de la compa±φa (es decir, por las consecuencias que podrφa tener la infecci≤n de un cliente y la pΘrdida de su buena disposici≤n) y en el riesgo de recibir material infeccioso adicional mientras ILOVEYOU viviera su minuto de fama. "Microsoft no deberφa dividirse. Deberφa ser cerrada." Estoy de acuerdo en general con el sentido del artφculo, e incluso con su presentaci≤n. Con la excepci≤n de la afirmaci≤n anterior. La afirmaci≤n es muy anti-individuo (en este caso anti-entidad) lo que equivale a prejuiciosa. Creo que el mensaje del autor puede ser resumido en "Microsoft deberφa proteger a un cliente de si mismo, tanto si entiende dicha protecci≤n como si no". Personalmente creo en la seguridad. Creo en las claves de cifrado y en las firmas. Creo tanto en la investigaci≤n pura como en las aplicaciones prßcticas de la teorφa criptogrßfica. Y ademßs creo que este no es el lugar donde el "Gran Hermano" decide quΘ tipo o cußnta criptografφa utilizo. Preferirφa que Microsoft proporcionara un sistema operativo estable con la posibilidad de incorporar la criptografφa. Y preferirφa mucho mßs que gente como Counterpane proporcionara alternativas e investigaci≤n en criptografφa para permitirme escoger la mejor soluci≤n. De uno u otro modo, no creo que el producto perfecto e intachable exista. Como Counterpane ha dicho varias veces: La seguridad no es un destino, es el viaje. Microsoft no puede localizar cada agujero de seguridad que haya en sus sistemas operativos o en sus aplicaciones; de lo que son responsables es de revelar los fallos de seguridad. ╔se es el estßndar que deberφamos tener. Resumiendo mi mensaje: creo que las empresas de software deberφan ser responsables de sus negligencias. Por el hecho de que un programa se demuestre que tiene un fallo y que se siga implementando sin corregirlo, o que a·n no haya sido "parcheado", se deberφa permitir a la parte perjudicada poner un pleito a la empresa desarrolladora del producto. La obvia (para mφ) inclinaci≤n anti-Microsoft de Phil, me lleva a cuestionar su objetividad, y por lo tanto el objetivo con el que escribi≤ su artφculo. De: "Bob Smart" (Bob.Smart@cmis.CSIRO.AU) Asunto: Gusano ILOVEYOU --------------------------------------------------------------------- Traducido por Oscar Esteban Me temo que el mensaje del asunto ILOVEYOU no se ha entendido bien. John Carder acierta en este caso concreto en una respuesta al artφculo de SLATE de James Gleick: "Windows Scripting Host otorga a un script en Visual Basic la autoridad del usuario que ejecuta el script, no la autoridad del autor del script". El problema de ejecutar con seguridad contenido que nos llega a travΘs de la red no estß limitado a Windows. El c≤digo m≤vil es un hecho, sea en forma de software descargado o como applets Java. La comunidad Unix tendrß que prestar atenci≤n a este asunto porque estß claro que ahora Microsoft lo harß. Cuando nuestra recepcionista envi≤ un ejecutable con la felicitaci≤n navide±a que una amiga le habφa enviado yo, por supuesto, no lo ejecutΘ. Sin embargo, si el software estuviera bien dise±ado entonces deberφa ser posible que cualquiera enviase tales cosas a sus amigos. Deberφa ser posible ejecutarlas sin peligro de causar da±o, exactamente igual que un applet en una JVM segura. De: phred@teleport.com Asunto: RTM frente al "Virus del amor" --------------------------------------------------------------------- Traducido por Oscar Esteban Microsoft afirma en su respuesta al artφculo de Jim Gleick en Slate que la situaci≤n del "Virus del amor" es de alg·n modo similar al gusano RTM. Totalmente absurdo. Es muy sencillo: RTM incluφa un destroza-pila y un buscador de claves mediante diccionario con un rudimentario mecanismo de reenvφo y un desvencijado canal de propagaci≤n hacia atrßs. Ninguna intervenci≤n del usuario era necesaria. El gusano RTM se apoyaba en errores de programaci≤n. El "Virus del amor" se apoyaba en caracterφsticas introducidas por Microsoft en sus programas. Esto es lo que marca la diferencia. De: jeff@antistatic.com Asunto: Ingenierφa social y el gusano ILOVEYOU --------------------------------------------------------------------- Traducido por Oscar Esteban Lo del gusano ILOVEYOU fue ingenierφa social de parvulario. Microsoft tuvo suerte de que haya sido un golpe discreto. Podrφa haber sido mucho peor. Si yo hubiera sido el programador malicioso hubiera a±adido un paso crφtico. Tras conseguir el elemento de la lista de direcciones, el script deberφa haber buscado el ·ltimo mensaje enviado por ese usuario y emplear ESA lφnea de asunto. 1) Alice envφa a Bob un mensaje con el asunto "┐Picnic el sßbado?" 2) Carl envφa a Bob el virus. 3) El virus envφa una copia de sφ mismo de Bob a Alice con el asunto "Re: ┐Picnic el sßbado?" El da±o podrφa haber sido mucho peor, y hubiera sido mßs difφcil filtrar en los servidores. A±ßdase un nivel de automodificaci≤n del c≤digo, y se podrφan haber echado abajo totalmente sistemas enteros de correo electr≤nico. De: Peter Houppermans (Peter.Houppermans@pa-consulting.com) Asunto: Sobrecargas de buffer --------------------------------------------------------------------- Traducido por JosΘ Manuel G≤mez No estoy muy seguro de si es s≤lo falta de interΘs en la buena calidad, pero me llama la atenci≤n que algunas casas de software hayan decidido ACEPTAR que "no estß mal" es suficiente para sacar el producto a la venta. El artφculo que apunto mßs abajo realiza algunas observaciones interesantes con las que estoy de acuerdo, aunque yo apuntarφa una causa algo mßs profunda: buenos fundamentos de dise±o. Las sobrecargas de buffer me parecen el resultado de procesos de desarrollo no demasiado bien dirigidos y algunos dirφan que es la consecuencia de utilizar C (por proporcionar suficiente lazo como para colgarse uno o, en mi opini≤n, con la potencia y la flexibilidad viene la responsabilidad). http://www2.linuxjournal.com/articles/currents/019.html En un tono mßs divertido, Microsoft ha descubierto que estß expuesta a las leyes, puesto que en Francia (y, hasta donde yo alcanzo, en toda Europa) la exclusi≤n de garantφa no es legal (es decir, nula y vacφa). Asφ que algunos usuarios emprendedores estßn llevando a Microsoft a los tribunales por maravillosos virus cuyo nombre no quiero mencionar debido a que los filtros rebotarφan el correo ;-) alegando neglicencia puesto que deberφan haber cubierto este tema a raφz del virus Melissa. De: Joe Harrison (joe-harrison@MailAndNews.com) Asunto: Responsabilidad del fabricante por mal software --------------------------------------------------------------------- Traducido por JosΘ Manuel G≤mez Estoy perplejo por sus frecuentes afirmaciones acerca de que los fabricantes de software ponen a la venta productos de tan poca calidad que serφan considerados invendibles, por defectuosos, en otros campos. Quizßs ocurra eso en los EE.UU. pero yo hubiera pensado que muchos (┐la mayorφa?) otros paφses trataran el software exactamente igual que cualquier otro artφculo en los litigios sobre adecuaci≤n a su prop≤sito. Aquφ, en el Reino Unido, los fabricantes han sido denunciados con Θxito y se ha establecido un precedente. Legalmente, su material tiene que funcionar de forma correcta en lo que se supone tiene que hacer. Eche un vistazo a: http://elj.warwick.ac.uk/jilt/cases/97_3stal/stalban.htm De: Ray Jones (rjones@pobox.com) Asunto: Clientes Fiables y Juegos de Ordenador --------------------------------------------------------------------- Traducido por Francisco Leal Vßzquez Usted pinta una imagen bastante triste de las comunidades de jugadores. Quake ha estado teniendo serios problemas ·ltimamente, pero Netrek trataba con clientes fiables allß en 1992 (tenφan instalado un sistema rudimentario antes de eso), y parecen haber evitado problemas serios desde entonces. La comunidad Netrek parece haberse adaptado a Borgs [programas informßticos que asisten el juego] mediante dos medidas: 1- aprobaci≤n binaria con un esquema no trivial 2- provisi≤n de algunos servidores que estΘn de acuerdo con los borgs El sistema de aprobaci≤n estß basado en RSA, con la clave privada del cliente escondida en el binario. Esto permite una distribuci≤n abierta de la lista de claves de clientes aprobadas, de tal modo que cualquiera puede ejecutar un servidor sin tener que estar en alguna lista de fiables de "dioses" servidores. Tener servidores que permitan borgs proporciona un foro reconocido para que los autores de los borg muestren sus habilidades de hacking. Los detalles sobre verificaci≤n no son tan importantes. Lo que es interesante son los ataques que la gente ha utilizado para difundirlos. En particular, de los dos hacks que he escuchado, ninguno contaba con extraer la clave del binario. El primero utilizaba una modificaci≤n del kernel para permitir a un cliente reabrir un socket despuΘs de que el cliente aprobado se hubiera autentificado Θl mismo. El segundo hack se basaba en el c≤digo generador de claves (una pobre generaci≤n de n·meros aleatorios, mea culpa). Ciertamente es posible extraer la clave, y despuΘs incluirla en un borg, pero el resultado no es bueno. Es probable que alguien se dΘ cuenta y rechace la clave, y los autores de borgs ya son capaces de usar sus clientes en escenarios donde poder realizar competiciones reales (borg contra borg). Admitamos que Netrek tiene menos posibilidad de colaboraci≤n entre mentes que Quake, y que tambiΘn es mßs apto para los borgs (siendo mßs tßctico y menos estratΘgico que Netrek, en mi humilde opini≤n). La escasez de ataques puede venir dada porque la gente se interesa menos. De cualquier modo, la combinaci≤n de los dos elementos arriba mencionados (palo, zanahoria) parece haber funcionado bastante bien. Como usted escribi≤ en alguna otra parte del Criptograma de este mes, la seguridad trata sobre reducir los riesgos, no sobre evitar la amenaza. De: Ian Mason (ian@ian.co.uk) Asunto: Re: Mßs sobre Microsoft Kerberos --------------------------------------------------------------------- Traducido por Francisco Leal Vßzquez Si, como hice yo, usted se descarga el .exe correspondiente al auto-extraible del Microsoft Kerberos, pero utiliza WinZip para descomprimirlo, no se verß forzado a aceptar el asφ llamado contrato de aceptaci≤n. Eso me permite utilizar mi copia actuando dentro de las leyes normales de Copyright. Especφficamente eso significa que puedo utilizar los contenidos sin que ello afecte a ning·n tema de secreto comercial. Estß bastante claro que Microsoft estß actuando de un modo anti-competitivo. Piden la adhesi≤n a un "standard" p·blico de Kerberos pero luego lo "amplian" de una forma incompatible. DespuΘs, con la posici≤n dominante en el mercado de los ordenadores de sobremesa, dificultan la creaci≤n de un producto servidor mediante la restricci≤n del acceso a la utilizaci≤n de los detalles de sus extensiones. Quizß es hora de que la IETF se ponga un poco dura con ellos. Tal vez una demanda por pasar por alto la denominaci≤n Kerberos. Aquφ en la Uni≤n Europea tenemos disposiciones que consideran ilegal impedir la ingenierφa inversa con prop≤sitos de compatibilidad. Desafortunadamente, no tenemos una ley que evite a un jugador dominante, forrado de dinero, pagar abogados y vencer a un jugador peque±o en los juzgados, pero ┐existe eso en alg·n sitio? De: Graystrea (wex@media.mit.edu) Asunto: Desactivar software a distancia --------------------------------------------------------------------- Traducido por JosΘ Manuel G≤mez Los fabricantes no tienen que hacer un t·nel a travΘs de los cortafuegos para desactivar software de forma remota. Hoy en dφa la mayorφa, si no todos, los programas se autoactualizan. Observen la caracterφstica "LiveUpdate" de Norton Antivirus como un ejemplo destacado. Otros programas piden permiso para ir a un sitio web y descargar una "actualizaci≤n". Incluso sin planificarlo de antemano, tales autoactualizaciones pueden ser utlizarse para desactivar usuarios de forma selectiva. Asφ es como Napster realiz≤ la prohibic≤n de mßs de 300.000 usuarios identificados por Metallica. Si se conecta a Napster con la versi≤n 2.5 de su cliente, se le pdirß que espere mientras se descarga la versi≤n 2.6. Al ejecutarse la 2.6, usted quedarφa bloqueado de golpe si estuviera en la lista de usuarios prohibidos. Claramente, este tipo de acontecimietno no figuraba en los planes originales de Napster, aunque han sabido implementarlo limpiamente. Espero que Norton, Microsoft y otros fabricantes de software sean igual de limpios a la hora de programas expiraciones en funci≤n de los usuarios. De: Ian Mason (ian@ian.co.uk) Asunto: Tratado sobre Cibercrimen --------------------------------------------------------------------- Traducido por JosΘ Manuel G≤mez El ordenamiento actual no prohibe la investigaci≤n. Para infringir el tratado propuesto se tendrφa que tener intenci≤n de cometer un delito ("dise±ado o adaptado con el *prop≤sito* de cometer un delito"). Si el prop≤sito de uno era investigar vulnerabilidades para prevenir delitos, entonces la intenci≤n de uno claramente no es cometer los delitos. Si no me creen, pregunten a cualquier buen abogado sobre el concepto de "mens rea" (literalmente "mente delictiva", habitualmente leφdo como "intenci≤n de delinquir") en el contexto que hablamos. No propone crear un delito absoluto (uno para el que baste demostrar un 'actus reas', acci≤n delictiva, sin importar la intenci≤n, para demostrar la culpabilidad). Yo puedo, legalmente, fabricar, tener y utilizar una palanqueta. Es ilegal que tenga una con el prop≤sito de utilizarla para cometer robos. El tratado se centra s≤lo en el ·ltimo supuesto. Lo lamento pero, por una vez, se trata de tΘcnicos que no entienden a los abogados, en vez de al revΘs, que resulta mßs habitual. De: Johan Ovlinger (johan@ccs.neu.edu) Asunto: Abogado denuncia a USWest por conexi≤n DSL insegura --------------------------------------------------------------------- Traducido por JosΘ Manuel G≤mez Aunque estoy de acuerdo con el principio de la responsabilidad del fabricante, este es mßs bien un caso del tipo "obtuvo lo que pidi≤, pero no pidi┤┤o lo que querφa". Pacific Bell conectaba su ordenador a Internet de forma continua. Eso es lo que solicit≤ y lo que obtuvo. Que no desactivara la compartici≤n de ficheros es culpa suya. Si hay alguien a quien culpar, serφa Microsoft, por hacer tan lamentablemente fßcil dispararse en el pie como en este caso (no es que Red Hat venga con una configuraci≤n por defecto mucho mejor, pero al menos le obligan a uno a introducir una contrase±a de administrador como parte de la instalaci≤n). En realidad no veo quΘ tiene que ver Pacific Bell con esta compartici≤n de archivos, al menos que ellos la activaran durante la instalaci≤n. Me gustarφa que este pleito se sobreseyera para que no creara un mal precedente (porque espero que pierda). Luego, me gustarφa ver c≤mo se piden cuentas a los autΘnticos responsables por el lamentable estado de su "seguridad". Por desgracia (creo que se nota que no soy un vapuleador de Microsoft), el actual clima polφtico convierte a Microsoft en el ·nico objetivo viable. Si acaban escindidos, sus EULAs se verßn como algo que no vale el papel donde estßn impresos, disponφendoles asφ a todo este tipo de acciones legales. Incluso si eso nunca tuviera Θxito, serφa digno de ver un pleito de una Fortune 500 contra ellos por los muchφsimos gigad≤lares que se perdieron por culpa del ·ltimo gusano de Internet, ┐no es cierto? _____________________________________________________________________ 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: * Francisco Leal Vßzquez * JosΘ Luis Martφn Mßs * Juan Cruz Ruiz de Gauna * David G≤mez * Oscar Esteban * Jes·s Reyes _____________________________________________________________________ -- 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. _____________________________________________________________________ ⌐ Bruce Schneier ⌐ Kriptopolis (versi≤n en Espa±ol). _____________________________________________________________________