2000 << Back To criptograma nº 27

_______________________________________________________________ C R I P T O G R A M A _______________________________________________________________ N·mero 27 15 de Julio del 2000 _______________________________________________________________ SUMARIO: 1. La Revelaci≤n Total y la CIA 2. Noticias de Counterpane 3. Mßs noticias de Counterpane 4. Noticias 5. Ni el Presidente sabe escoger una buena contrase±a 6. En la Ratonera: Intuit QuickBooks 7. Revelaci≤n total y fabricaci≤n de cerraduras 8. Riesgos de seguridad de Unicode 9. Reimpresiones de CRIPTOGRAMA 10. Comentarios de los lectores _______________________________________________________________ * N·meros anteriores: http://www.kriptopolis.com/criptograma/cg.html _______________________________________________________________ 1. La Revelaci≤n Total y la CIA ================================================= Por Bruce Schneier Traducci≤n: Francisco Leal Vßzquez http://www.kriptopolis.com/criptograma/0027_1.html En su sitio web, el New York Times public≤ un documento de la CIA de 1954, previamente clasificado, sobre el derrocamiento del gobierno iranφ. No estoy seguro de c≤mo el New York Times se hizo con el documento, pero el peri≤dico decidi≤ listar los nombres de los ciudadanos iranφes implicados en el tema. El documento era un fichero PDF escaneado. Lo que el Times hizo fue crear una cubierta sobre las pßginas, y dibujar recuadros negros sobre los nombres que querφan ocultar. El resultado fue un fichero que a·n tenφa la informaci≤n digital pero contenφa comandos extra para ocultar esa informaci≤n. Como era de prever, alguien aplic≤ ingenierφa inversa a los nombres originales (era sorprendentemente fßcil) y public≤ el documento original. En el Times cundi≤ el pßnico y eliminaron el documento original, pero era demasiado tarde; existen copias disponibles en varios lugares por todo el mundo. Las reacciones ante esto han sido extra±as, y de forma casi uniforme fuera de lugar. He aquφ una de William Hugh Murray: "Proteger la identidad de las fuentes de inteligencia es una de las pocas razones legφtimas para los secretos gubernamentales. Un 'Activista pro-libertad de informaci≤n' no sirve a su propia causa, y mucho menos a un interΘs nacional, mediante un comportamiento tan imprudente." Ignorando el orgullo de Murray al asegurar conocer las motivaciones de alguien de forma mas profunda que ese alguien, ┐quΘ tiene este caso que ver con los secretos de gobierno? Fue el New York Times quien decidi≤ redactar el documento, no la CIA. La gente que nos dio los papeles del Pentßgono decidi≤, por si misma, no mostrar la informacion que la CIA les habia mostrado. Esto es muy diferente de que el gobierno quisiera mantener un secreto. Seg·n lo ·ltimo que sΘ, el New York Times no forma parte de la comunidad de inteligencia. John Young, a quien critica el activista Murray, da los argumentos clßsicos a favor de la revelaci≤n completa. La informaci≤n fue publicada por el New York Times. Aunque tomara algo de trabajo extraerla, la gente la estß extrayendo. Partiendo de la certeza de esto, es mejor mostrar la informaci≤n de forma que todo el mundo pueda tener acceso a ella - no s≤lamente los pocos al azar que apliquen ingenierφa inversa al fichero PDF. Young dijo "Los sujetos cuyos nombres aparecen tienen un interΘs personal en saberlo". La parte opuesta reacciona de una manera igualmente predecible: la informaci≤n debe mantenerse secreta. S≤lo porque el New York Times err≤ e hizo que la informaci≤n estuviera disponible para unos pocos no significa que debiΘramos aumentar el error y hacer que la informaci≤n estuviera disponible para todo el mundo. Es una situaci≤n complicada, a·n mßs enturbiada gracias a la decisi≤n del New York Times de reescribir el documento. Si la CIA le dio al New York Times el documento sin modificar, ┐por quΘ decidi≤ el Times limitar el conocimiento p·blico sobre la informaci≤n? Para mi, este es un caso tφpico del poder de la revelaci≤n completa. La informaci≤n en cuesti≤n - los nombres de los ciudadanos iranφes - ha sido mostrada al p·blico. Inicialmente, s≤lo era conocida por los pocos que habφan hecho ingenierφa inversa al fichero PDF, y por los que sabφan que la informaci≤n habφa sido divulgada. Si se la hubiera dejado como estaba, esta informaci≤n se hubiera divulgado lentamente. Quizß alguien que quisiera hacer da±o a esta gente sabrφa de esta informaci≤n; ya sabe con certeza que la informaci≤n existe. Quizß alguien de los que aparecen listados sabrφa que lo estß, y podrφa realizar las acciones oportunas. Pero este proceso es lento y azaroso. Lo mejor es mostrar la informaci≤n a todo el mundo, rßpidamente. Esto limita el da±o que se puede realizar. La gente que aparezca en la lista es mßs probable que se entere de que aparece, y es mßs probable que eso ocurra rßpidamente. Aquellos que quieran sacar partido del relativo secreto de la informaci≤n no pueden hacerlo. Todo el mundo conoce la informaci≤n, y esto nivela la situaci≤n. Es la situaci≤n en la que s≤lo unos pocos al azar conocen la informaci≤n, y otros la descubren a trozos, algo que resulta inestable y peligroso. Artφculos en las noticias: http://www.wired.com/news/politics/0,1283,37205,00.html http://www.securityfocus.com/news/51 El documento: http://cryptome.org/cia-iran-all.htm 2. Noticias de Counterpane ================================================= Por Bruce Schneier Traducci≤n: Oscar Esteban http://www.kriptopolis.com/criptograma/0027_2.html Counterpane tiene el placer de anunciar un nuevo acuerdo de aseguramiento con Lloyd's of London. ╔sta es una oferta exclusiva para clientes de Counterpane: si Counterpane monitoriza su red, entonces puede adquirir este seguro. Por primera vez en la historia, las organizaciones pueden comprar un seguro contra el hacking sin una auditorφa de seguridad y sin importar quΘ productos de seguridad en particular utilicen. Las organizaciones pueden tambiΘn comprar, por primera vez en la historia, una cobertura de garantφas que proteja a sus clientes contra la pΘrdida de ingresos y datos. La seguridad informßtica siempre se ha vendido como "prevenci≤n de riesgos". Cifrado, cortafuegos, antivirus, PKI... todas estas son tecnologφas que evitan riesgos concretos. La prevenci≤n de riesgos es un coste, y si una organizaci≤n no entiende los riesgos, entonces podrφa no estar dispuesta a pagar por la prevenci≤n. La autΘntica seguridad de los negocios, por otro lado, tiene que ver con la gesti≤n de riesgos. La gesti≤n de riesgos no es un coste, es una forma de hacer dinero. Si una organizaci≤n puede gestionar su riesgo mejor que otra, entonces tendrß mayores beneficios. Las compa±φas inteligentes pueden aceptar el riesgo, buscar mßs, y pensar c≤mo hacer negocios contando con Θl. Viendo la seguridad informßtica como una herramienta de gesti≤n de riesgos, hay muchas mßs opciones que la prevenci≤n de riesgos. Hay detecci≤n y respuesta: gestionar el riesgo encontrando ataques en curso y deteniΘndolos. Y tambiΘn hay seguros: empaquetar riesgo y vendΘrselo a alg·n otro. Estas cosas son el futuro de la seguridad informßtica, y no las tecnologφas profilßcticas que prometen una mßgica cobertura de seguridad. Desde el principio he mantenido que Counterpane Internet Security se ocuparß de los problemas reales de la seguridad de redes. Nunca he creφdo que simplemente instalando productos se pueda jamßs proteger a nadie, y me he centrado en la seguridad como proceso. Una parte de ese proceso es la Monitorizaci≤n de Seguridad Dirigida, que es de lo que trata el negocio de Counterpane. La otra parte son los seguros. Ahora los clientes de Counterpane, y s≤lo los clientes de Counterpane, tienen acceso a ambas. Resumen de la oferta: Counterpane Internet Security Inc., Lloyd's of London, Frank Crystal & Co., y SafeOnline Ltd. han desarrollado de forma conjunta una exhaustiva soluci≤n aseguradora de gesti≤n del riesgo, la primera en su gΘnero, especφficamente destinada a satisfacer las necesidades del comercio electr≤nico de hoy en dφa. Protecci≤n disponible de hasta 100 millones de d≤lares. Dos productos disponibles: 1. Cobertura de protecci≤n de activos Internet e ingresos ofrece un seguro a los clientes de la Monitorizaci≤n de Seguridad Dirigida de Counterpane que incurran en pΘrdida de/o da±o a activos de informaci≤n como resultado de una brecha de seguridad o fallo de tecnologφa. TambiΘn cubre la interrupci≤n de negocio por pΘrdida de uso debida a una brecha. 2. Plan de garantφa de protecci≤n de activos Internet e ingresos para ISPs/ASPs que empleen los servicios de Monitorizaci≤n de Seguridad Dirigida de Counterpane; este de un plan personalizado de garantφas apoyado en un seguro para ampliar la protecci≤n de activos Internet e ingresos a sus clientes. Estos seguros se venden a travΘs de corredores de seguros autorizados. Resumen rßpido: http://www.counterpane.com/pr-lloydssl.html Nota de prensa: http://www.counterpane.com/pr-lloyds.html Preguntas y Respuestas: http://www.counterpane.com/pr-lloydsqa.html Documento oficial describiendo la oferta de seguro y su contexto: http://www.counterpane.com/pr-lloydswp.html Cobertura en prensa: http://news.cnet.com/news//0-1005-200-2232221.html?tag=st.cn.sr.ne.1 http://www.internetwk.com/story/INW20000710S0001 http://www.computerworld.com/cwi/story/0,1199,NAV47_STO46992,00.html?am http://www.zdnet.com/zdnn/stories/news/0,4586,2600511,00.html http://www.crn.com/dailies/digest/dailyarchives.asp?ArticleID=18243 http://slashdot.org/articles/00/07/10/139201.shtml 3. Mßs noticias de Counterpane ================================================= Por Bruce Schneier Traducci≤n: Oscar Esteban http://www.kriptopolis.com/criptograma/0027_3.html Es posible encontrar mßs informaci≤n sobre el servicio de Monitorizaci≤n de Seguridad Dirigida de Counterpane en: http://www.counterpane.com/oursol.html http://www.counterpane.com/coverage.html Bruce Schneier hablarß en BlackHat (26 de julio) y DefCon (29 de julio) en Las Vegas. http://www.blackhat.com http://www.defcon.org Bruce Schneier se dirigirß a la Digital Commerce Society of Boston el 1 de agosto. En WebDefense, en Washington DC (9 de agosto), Bruce Schneier darß una charla titulada "┐QuΘ nivel de seguridad podemos razonablemente esperar?" http://www.acius.net/webd_overview.html Para el programa completo de conferencias Counterpane, vea: http://www.counterpane.com/conf.html 4. Noticias ================================================= Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna http://www.kriptopolis.com/criptograma/0027_4.html Otro interesante artφculo sobre creaci≤n de virus informßticos: http://www.hackernews.com/bufferoverflow/99/nitmar/nitmar1.html Software (software infantil, ni mßs ni menos) que automßticamente espφa por usted: http://www.salon.com/tech/col/garf/2000/06/15/brodcast/ La necesidad de seguridad. Buen artφculo. http://www.acm.org/crossroads/columns/onpatrol/june2000.html Problemas con las infraestructuras de clave p·blica. Este artφculo fue escrito bastante antes de que yo empezase a pensar acerca de estos problemas: http://world.std.com/~dtd/compliance/compliance.ps Algunos paφses estßn llevando a cabo un reconocimiento militar de las redes de ordenadores de los E.E.U.U.: http://www.zdnet.com/zdtv/cybercrime/hackingandsecurity/story/0,9955,2590577,00.html Artφculos provocadores sobre los riesgos de la nueva ley de firma digital: http://www.pfir.org/statements/2000-06-17 http://www.securityfocus.com/templates/article.html?id=50 Una interesante historia sobre criptografφa. Un partido polφtico mexicano quiere que se rompa una clave de cifrado, porque creen que el texto en claro resultante pondrß en aprietos al partido en el poder. http://www.theregister.co.uk/content/1/11508.html http://www.wired.com/news/politics/0,1283,37337,00.html Comentario sobre la exageraci≤n que rodea a las noticias de prensa sobre seguridad informßtica. http://www.computerworld.com/cwi/story/frame/0,1213,NAV47-68_STO46049,00.html No estoy de acuerdo: Considero que el actual despliegue insensibilizarß a la gente sobre las autΘnticas amenazas y riesgos. La OTAN saca un virus. (Hay bastantes cosas extra±as en esta historia como para hacerme dudar sobre su veracidad, pero quiΘn sabe). http://www.the-times.co.uk/news/pages/sti/2000/06/18/stinwenws01024.html Los motivos y psicologφa de la comunidad BackHat. Otro buen artφculo de Lance Spitzner. http://www.securityfocus.com/focus/ids/articles/kye/motives.html?&_ref=3948`32126 Publius es un sistema para publicar en la Web, de forma an≤nima y resistente a la censura. http://cs.nyu.edu/waldman/publius/ http://www.washingtonpost.com/wp-dyn/articles/A21689-2000Jun29.html Estßn buscando a gente que quiera alojar un servidor Publius. El Servicio Secreto estß desarrollando un Programa de Agentes Especiales para delitos electr≤nicos. Los agentes analizarßn nuevos productos de seguridad y alertarßn a los fabricantes sobre debilidades. http://www.fcw.com/fcw/articles/2000/0626/web-secret-06-27-00.asp Empresas "Punto Com" fracasadas estßn vendiendo informaci≤n privada: http://news.cnet.com/news/0-1007-200-2176430.html Mßs pruebas de que, para empezar, no se les deberφa permitir recolectar dicha informaci≤n y de que las polφticas de privacidad que exhiben no valen ni las colores con que se muestran. El esquema de protecci≤n anticopia de Sega Dreamcast ha sido roto. ┐Alguien se sorprende? http://www.mhzgaming.com/articles/dc629.htm http://news.cnet.com/news/0-1005-200-2181596.html Informe especial de noticias sobre Echelon: http://www.zdnet.co.uk/news/specials/2000/06/echelon/ El gobierno de Francia estß investigando: http://dailynews.yahoo.com/h/nm/20000704/ts/france_usa_dc_1.html http://news6.thdo.bbc.co.uk/hi/english/world/europe/newsid%5F819000/819210.stm Interesante artφculo sobre la falta de seguridad en los sitios web del gobierno Australiano: http://www.theregister.co.uk/content/1/11686.html Y otros artφculos sobre el mismo tema: http://www.it.fairfax.com.au/breaking/20000630/A43356-2000Jun30.html http://www.afr.com.au/news/20000701/A44576-2000Jun30.html Hubo rumores sobre hackers que perturbaron al Space Shuttle hace unos a±os. Aquφ hay una historia que parece coherente: http://news.excite.com/news/ap/000702/20/news-britain-hacker La NASA lo niega: http://news.excite.com/news/ap/000703/19/nasa-hacker La pregunta es: ┐Por quΘ estos sφstemas crφticos estßn conectados a redes p·blicas? Comercio Electr≤nico: ┐QuiΘn carga con el riesgo de fraude?. http://www.fipr.org/WhoCarriesRiskOfFraud.htm El NIST ha publicado un φndice de vulnerabilidades informßticas. Llamado ICAT, enlaza a los usuarios hacia una variedad de bases de datos de vulnerabilidades disponibles p·blicamente y sitios donde hay parches. ICAT no es en sφ mismo una base de datos de vulnerabilidades, sino un φndice que admite b·squedas y nos dirige a recursos sobre vulnerabilidades e informaci≤n sobre parches. ICAT permite buscar con un alto grado de precisi≤n (una caracterφstica no disponible en la mayor parte de bases de datos de vulnerabilidades), mediante la caracterizaci≤n de cada vulnerabilidad mediante mßs de 40 atributos (incluyendo el nombre de software y su n·mero de versi≤n). ICAT indexa la informaci≤n disponible en los informes de CERT, ISS X-Force, Security Focus, NT Bugtraq y una gran variedad de comunicados de seguridad y parches de fabricantes. ICAT hace uso del estßndar de denominaci≤n de vulnerabilidades CVE. http://csrc.nist.gov/icat La inseguridad de la informßtica inalßmbrica: http://www.msnbc.com/news/429748.asp?cp1=1 Nueva tecnologφa para la recuperaci≤n de datos borrados en sustratos electr≤nicos: http://www.sciencenews.org/20000708/fob1.asp Buen editorial. El mayor problema en la seguridad informßtica no son los ordenadores, sino los usuarios. http://www.osopinion.com/Opinions/DanielHiggs/DanielHiggs1.html Estßn surgiendo un mont≤n de sitios de "Pago por navegar", que pagan a los usuarios por ver anuncios web, junto con una industria artesanal de programas que ayudan a que los falsos navegantes se salten las reglas y a·n asφ sigan cobrando. http://www.wired.com/news/culture/0,1284,37329,00.html?tw=wn20000710 N·mero de la Seguridad Social de ricos y famosos: http://news.cnet.com/news/0-1005-200-340248.html Un nuevo estudio dice que la votaci≤n a travΘs de Internet es insegura (esto no es sorprendente). Artφculo con la noticia: http://www.wired.com/news/politics/0,1283,37504,00.html El autΘntico estudio: http://www.voting-integrity.org/text/2000/internetsafe.shtml Spam con enormes adjuntos multimedia. ┐Alguien se preocupa de considerar las implicaciones para los escritores de virus? http://adage.com/interactive/articles/20000710/article2.html "El Carnφvoro", del FBI. Un sistema experto que busca a travΘs del correo electr≤nico. http://www.zdnet.com/zdnn/stories/news/0,4586,2601502,00.html La ACLU se queja: http://www.wired.com/news/politics/0,1283,37470,00.html La empresa "Cyber Group Network Corp" anuncia que tiene una tecnologφa que permite localizar un ordenador robado, recibir informaci≤n desde Θl de forma remota, y destruirlo. Suena un poco fantasioso. Pero esta empresa lleva la "Seguridad mediante obscuridad" a nuevas alturas: "Seg·n Nish Kapoor, un portavoz de Cyber Group Network, la tecnologφa pendiente de patente que hace esto posible estß siendo desarrollada y fabricada en una localizaci≤n remota secreta identificada s≤lo como 'Area 74'". íOh! http://www.newsbytes.com/pubNews/00/151921.html Y a·n peor, software que permite a las compa±φas localizar (y presumiblemente perseguir) a aquellos que digan cosas desagradables sobre ellos en Internet. ┐QuΘ ha sucedido con la libertad de expresi≤n en Internet?. http://www.businessweek.com/bwdaily/dnflash/july2000/nf00707g.htm 5. Ni el Presidente sabe escoger una buena contrase±a ================================================= Por Bruce Schneier Traducci≤n: Jes·s Reyes http://www.kriptopolis.com/criptograma/0027_5.html Seg·n una historia sobre Clinton firmando el proyecto de ley de firma electr≤nica con una tarjeta magnΘtica: "Con una tarjeta magnΘtica y con el nombre de su perro Buddy como contrase±a, el Presidente Clinton firm≤ el viernes, utilizando su firma electr≤nica, el proyecto de ley que permitirß equiparar la autenticidad de la firma electr≤nica con la firma tradicional en papel". Observen la elecci≤n de la contrase±a. Tiene 5 caracteres, son todos letras y probablemente todas en min·scula. Al menos no la guarda escrita en un Post-it en su escritorio. http://www.foxnews.com:80/elections/063000/clinton_ebill.sml 6. En la Ratonera: Intuit QuickBooks ========================================================== Por Bruce Schneier Traducci≤n: Jes·s Reyes http://www.kriptopolis.com/criptograma/0027_6.html QuickBooks de Intuit, es un programa de gesti≤n financiera para peque±as empresas. Tiene un mont≤n de buenas caracterφsticas y es uno de los mßs populares productos de gesti≤n disponibles. Desafortunadamente la seguridad es su punto dΘbil. Las primeras versiones de QuickBooks almacenaban los nombres de usuarios y contrase±as sin cifrar. Conforme el n·mero de la versi≤n crecφa, tambiΘn lo hacφa la ofuscaci≤n: primero aplicaban un XOR a los datos con una mßscara constante, luego a±adφan algunas rotaciones de bytes y otros jugueteos con los bits. Las ·ltimas versiones de QuickBooks usan DES para cifrar los bloques de datos que contienen el nombre de usuario y su correspondiente contrase±a. Esto hubiera hecho mucho mßs difφcil de romper el sistema, si no fuera porque las claves de cifrado eran almacenadas en el fichero. Para comprobar que el usuario tiene la contrase±a correcta, QuickBooks busca la clave de descifrado, descifra el bloque, y compara el resultado con la contrase±a que el usuario escribi≤. Nada evita que, sin autorizaci≤n, un programa realice los mismos pasos y saque impresos los nombres y contrase±as de los usuarios. Gracias a Mike Stay por mostrarnos este problema. 7. Revelaci≤n total y fabricaci≤n de cerraduras ==================================================== Por Bruce Schneier Traducci≤n: Jes·s Reyes http://www.kriptopolis.com/criptograma/0027_7.html "En cuanto a la fabricaci≤n de cerraduras, muy poco lugar puede quedar para la falta de honradez en la intenci≤n: el inventor fabrica una cerradura que Θl cree honestamente que tiene tales o cuales calidades; y declara su opini≤n al resto del mundo. Si hay otros que discrepan con Θl respecto a dichas calidades, son totalmente libres para decirlo; y la discusi≤n, sinceramente llevada, debe resultar en algo provechoso para todos: la discusi≤n estimula la curiosidad, y la curiosidad estimula la invenci≤n. Nada excepto un punto de vista parcial y limitado sobre la cuesti≤n podrφa llevarnos a pensar que el proceso pueda resultar da±ino: si hubiera da±o, serφa compensado de sobra por todo lo bueno." "Tratado sobre la fabricaci≤n rudimentaria de cerraduras", de Charles Tomlinson, publicado alrededor de 1850. 8. Riesgos de seguridad de Unicode ==================================================== Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez http://www.kriptopolis.com/criptograma/0027_8.html Unicode es un juego internacional de caracteres. Como ASCII, proporciona una correspondencia estßndar entre los n·meros binarios, que entienden los ordenadores, y las letras, dφgitos y signos de puntuaci≤n que entienden las personas. Pero a diferencia de ASCII, trata de proporcionar un c≤digo para cualquier carßcter en cualquier idioma del mundo. Para lograr esto, necesita mßs de los 256 caracteres del conjunto ASCII de 8 bits; Unicode por defecto utiliza caracteres de 16 bits y existen reglas incluso para ampliarlo mßs. No sΘ si alguien ha tenido en cuenta las implicaciones de seguridad de todo esto. ┐Recuerdan todos aquellos ataques de validaci≤n de entradas que se basaban en sustituir caracteres con sus representaciones alternativas, o que exploraban delimitadores alternativos? Por ejemplo, existφa un agujero en el servidor web IRIX: si se lograba reemplazar espacios por tabuladores se podφa volver loco al analizador, y se podφan utilizar escapes hexadecimales, comillas extra±as y caracteres nulos para inutilizar la validaci≤n de las entradas. La especificaci≤n Unicode incluye todo tipo de nuevas y complicadas secuencias de escape. Hay cosas llamadas UTF-8 y UTF-16, que permiten varias posibles representaciones de varios c≤digos de carßcter, varios sitios diferentes donde colocar caracteres de control, un esquema para situar acentos y diacrφticos en caracteres separados (pareciΘndose demasiado a un escape) y centenares de nuevos caracteres de puntuaci≤n y caracteres no pertenecientes al alfabeto. La filosofφa que subyace a Unicode es proporcionar todos los posibles caracteres ·tiles para aplicaciones de 8 ≤ 16 bits netos. Es admirable, pero resulta casi imposible filtrar una cadena de caracteres Unicode para decidir lo que es "seguro" para alguna aplicaci≤n y lo que no. ┐QuΘ ocurre si: - empezamos a dar significados a los nuevos caracteres como delimitadores, espacio en blanco, etc.? Con miles de caracteres y nuevos caracteres a±adiΘndose constantemente, resultarß extremadamente difφcil categorizar todos los posibles caracteres de forma coherente, y donde hay incoherencia tiende a haber agujeros de seguridad. - alguien utiliza caracteres "modificadores" de una forma no prevista? - alguien utiliza UTF-8 ≤ UTF-16 para codificar un carßcter convencional en una forma nueva que se salte las comprobaciones de validaci≤n? Con el juego de caracteres ASCII, podemos estudiar cuidadosamente una peque±a selecci≤n de caracteres, categorizarlos con claridad y tomar decisiones relativamente sencillas acerca de la naturaleza de cada carßcter. Y a·n asφ, ha habido errores (olvidar tabuladores, confusiones con secuencias de control multicarßcter, etc.). A pesar de todo, un dise±ador cuidadoso puede idear una forma segura de manejar cualquier posible carßcter que provenga de un enlace poco fiable, por eliminaci≤n si es necesario. Con Unicode, probablemente no seremos capaces de obtener una definici≤n consistente sobre quΘ aceptar, quΘ es un delimitador y bajo quΘ circunstancia o c≤mo manejar de forma segura cadenas arbitrarias. Es s≤lo cuesti≤n de tiempo que sencillos validadores pasen datos, y las capas superiores del software, intentando ser ·tiles, a±adan significados a caracteres mßgicos, y estaremos ante una variedad completamente nueva de agujeros de seguridad. Unicode es demasiado complejo para ser seguro. * Unicode: http://www.unicode.org/ (Gracias a Jeffrey Streifling, que me proporcion≤ gran parte del material de este artφculo.) * Versi≤n web de este artφculo: http://www.kriptopolis.com/criptograma/0027_8.html * Counterpane Internet Security: http://www.counterpane.com/ 9. Reimpresiones de CRIPTOGRAMA ==================================================== Por Bruce Schneier Traducci≤n: Jes·s Reyes http://www.kriptopolis.com/criptograma/0027_9.html Aquellos que se hayan suscrito recientemente pueden haberse perdido los siguientes artφculos publicados en n·meros anteriores: Desclasificaci≤n de SKIPJACK: http://www.counterpane.com/crypto-gram-9807.html#skip El futuro del Cripto-Hacking: <http://www.counterpane.com/crypto-gram-9907.html#hacking> Las chapuzas de SSL: <http://www.counterpane.com/crypto-gram-9907.html#doghouse> 10. Comentarios de los lectores ==================================================== Por Bruce Schneier http://www.kriptopolis.com/criptograma/0027_10.html De: Bernard Peek (Bernard@postar.co.uk) Asunto: Desactivaci≤n remota de software Traducci≤n: Fernando Garnacho ------------------------------------------ En el Reino Unido existen medidas legales para proteger frente a la desactivaci≤n de software mediante comandos remotos. En tΘrminos generales el mencionado uso es ilegal si no cuenta con el consentimiento previo del usuario. Se permitirφa en el caso de que el usuario aceptase una licencia de uso de la aplicaci≤n que incluyese las clßusulas apropiadas. A mi entender, a falta de un consentimiento previo, cualquier proveedor que desactivase un programa ejecutßndose en un ordenador dentro del Reino Unido estarφa transgrediendo la legalidad vigente britßnica. El hecho de provocar la desactivaci≤n de forma remota no servirφa como defensa. Tengo entendido que un proveedor de software incluy≤ un dispositivo temporal no documentado que inutilizaba el programa. El dispositivo-trampa se ponφa en funcionamiento si el proveedor no lo desactivaba. S≤lo lo hacφan (desactivarlo) cuando el cliente pagaba el ·ltimo plazo. Uno de los plazos estaba todavφa bajo disputa cuando el dispositivo-trampa se activ≤. Ganaron una querella contra el proveedor, que tuvo que pagar una multa y una indemnizaci≤n por los da±os causados. Me ha llamado la atenci≤n que algunos archivos contienen certificados de seguridad con fechas de caducidad, habiendo programas que no funcionan si les expiran los archivos. Cuento conque los proveedores tengan a punto mecanismos que los reemplacen antes de que les expire la fecha o bien tengan una copia firmada por el cliente de la licencia de uso de la aplicaci≤n, en la que se especifiquen los detalles bajo los que la aplicaci≤n deja de funcionar. De: Matt Curtin (cmcurtin@interhack.net) Asunto: Forzamiento de claves DES Traducci≤n: Fernando Garnacho ------------------------------------------ En la publicaci≤n del 15 de junio de CRYPTO-GRAM, se discute la (in)-seguridad de DES debido a la relativa poca longitud de la clave. > El algoritmo ha estado desde el principio bajo sospecha debido a la poca > longitud de la clave, construyΘndose en 1998 un dispositivo capaz de vencer DES por fuerza John Gilmore y compa±φa presentaron un avance importante en 1998 con Deep Crack, abriendo claves DES muy rßpido. La primera apertura de una clave DES mediante software se realiz≤ de hecho en 1997, con un equipo dirigido por Rocke Verser. Justin Dolske y yo escribimos un documento describiendo la arquitectura del sistema que se public≤ en mayo de 1998 en un n·mero especial de ;login. Me parece que merece la pena mencionarlo, no s≤lo porque nos permite adelantar en un a±o el tiempo que llev≤ romper claves DES, sino porque qued≤ demostrado (dos veces, ya que otro equipo hizo lo mismo al a±o siguiente) que la longitud de la clave era tan corta que se podφa abrir en software utilizando solamente ciclos no utilizados, aleatorios de ordenadores comunicßndose a travΘs de un protocolo simple. Antes de descartar esta tΘcnica como un ataque impracticable habrφa que tener en cuenta los recientes ataques de denegaci≤n de servicios realizados por agresores que toman control de los ordenadores de terceros, coordinando luego estos "ordenadores zombies" para que hagan su trabajo. Si hay agresores que hagan esto con ataques DoS tambiΘn se podrφa utilizar para abrir claves. No obstante, me imagino que debido a la ineficiencia del ataque, esto solo lo harφa gente que no tuviese dinero, creo.... El artφculo tΘcnico se encuentra disponible en http://www.interhack.net/pubs/des-key-crack/ y el artφculo no tΘcnico (escrito originariamente para la prensa) que describe brevemente ataques criptogrßficos de fuerza bruta, junto con los Θxitos de nuestro proyecto estß en http://www.interhack.net/projects/deschall/what.html De: Paul Bissex (pb@e-scribe.com) Asunto: Re: Criptograma 6/15, Williams/Agre Traducci≤n: David G≤mez -------------------------------------------- Un breve comentario sobre la respuesta de J. Christopher Williams a Phil Agre. Creo que el Sr. Williams tenφa una legφtima diferencia de opini≤n aquφ, aunque no comparto sus puntos de vista. Sin embargo, decir que "su [en referencia a Agre] dominio de la gramßtica bßsica es menos que firme" es simplemente de risa, especialmente despuΘs de que uno se haya peleado con unas cuantas docenas de lφneas de la pomposa prosa del Sr. Williams. Hay pocas personas que escriban sobre tecnologφa con tanta inteligencia, erudici≤n, y precisi≤n como Phil Agre. Resulta desafortunado que el Sr. Williams sintiera la necesidad de transformar su opini≤n en un ataque personal. De: "Jay R. Ashworth" <jra@baylink.com> Asunto: Comentarios a Schneier sobre Agre Traducci≤n: David G≤mez ------------------------------------------- En los comentarios publicados en el Criptograma de Junio, Sr. Williams, habla sobre los comentarios apuntados por Phil Agre en la, creo, previa edici≤n del boletφn... Microsoft escribi≤: > ".. Este es un comportamiento del dise±o, no una > vulnerabilidad de seguridad." Agre coment≤: > "Mas lenguaje rebuscado. Es como decir, 'Esto es una roca, > no algo que pueda caer al suelo'. Es confuso solo pensar > sobre ello. > ..." Su observaci≤n: > El autor puede ser un experto en seguridad o en ordenadores, > pero su dominio de la gramßtica bßsica es menos que firme. > La conversi≤n gramatical mßs precisa serφa "Esto es un > objeto lanzado al suelo, no un objeto cayendo libremente." > La sentencia en si misma meramente ayuda a definir lo que puede > llamarse la campa±a de "lanzar" y la de "caer libremente" que el > autor sugiere. Para mi el autor esta metiΘndose al parecer en la > misma "tßctica de echar las culpas" de la que acusa a Microsoft. La manera en la que *yo* veo esto es asφ: Agre siente, y yo estoy de acuerdo con Θl, que Microsoft, en su redacci≤n, estß sugiriendo que puesto que [el comportamiento en cuesti≤n] es por dise±o, *no puede ser* una vulnerabilidad de seguridad; esto es, que son mutuamente excluyentes. Si de hecho esta es la afirmaci≤n que Microsoft estß intentado que la gente deduzca, estßn equivocados. Como prueba, simplemente necesitamos mirar a uno de los mßs famosos agujeros de seguridad de todos los tiempos: el comando DEBUG de sendmail. Obviamente Θste fue puesto en el software por dise±o. Igualmente obvio, era una vulnerabilidad de seguridad. Por lo tanto, debe ser posible para un elemento de un programa ser ambas de estas cosas. Por lo tanto, la explicaci≤n de Microsoft no debe ser nada ingenua, ya que estßn intentando afirmar que esas dos descripciones de una parte del programa no pueden ser ambas verdad a la vez. El problema no es que Phil no comprenda el lenguaje, es que Microsoft estß jugando con Θl. De: kragen@pobox.com (Kragen Sitaker) Asunto: Riesgos del XML Traducci≤n: David G≤mez -------------------------------------- Usted escribe: > XML y como hacerlo seguro: > http://www.zdnet.co.uk/news/2000/20/ns-15500.html Este tema es como el del "ASCII y c≤mo hacerlo seguro." Este pßrrafo lo dice mejor: > Y este es un gran problema. Internet es tan insegura > como siempre, y el ASCII no harß nada por mejorarla. > De hecho, la tentaci≤n de interceptar y alterar un > documento ASCII conteniendo datos vitales en ruta desde > una aplicaci≤n bancaria a otra atraerß a muchos vßndalos > de Internet. Bueno, en el original, decφa XML, no ASCII, pero tiene igual de sentido de la otra manera. De: Darren Cervantes (cervante@roguewave.com) Tema: Seguridad de SOAP Traducci≤n: JosΘ Manuel G≤mez ---------------------------------------------- Su boletφn me fue reenviado hace poco. Estoy interesado en su opini≤n sobre los asuntos de seguridad de SOAP. Su ·ltimo artφculo sugerφa que cualquier comando SOAP podrφa ser capaz de llegar a su ordenador y hacer algo malicioso. Usted afirma: los cortafuegos tienen buenas razones para bloquear protocolos como DCOM llegando de fuentes no fiables. Los protocolos que se los saltan no son bien recibidos. Por lo que yo sΘ del procolo SOAP, tienen que ocurrir unas cuantas cosas para que un RPC se cuele: 1) Tiene que instalarse un Servidor SOAP especφfico. 2) El servidor SOAP debe "traducir" SOAP a servicios de empresa o RPCs. 3) Ese servidor tiene que estar configurado para ejecutar ciertos servicios SOAP (en otras palabras, si el servicio no ha sido definifdo, no estß disponible para SOAP. 4) El servidor dispone de una oportunidad para reconocer el servicio SOAP y rechazarle o bloquearle si no es vßlido. A·n mßs; en el documento SOAP de Microsoft, se establece que tanto el cifrado HTTP (SSL) como los protocolos de autenticaci≤n HTTP pueden ser utilizados en combinaci≤n con cualquier seguridad de punto final (presumiblemente autorizaci≤n). Esto ayudarφa a negar el factor de las "fuentes no fiables". Tal y como yo lo entiendo, se tendrφa que configurar un servidor SOAP y un servicio explφcito para "borrar el disco duro". Se tendrφa que permitir despuΘs que el servidor aceptara la petici≤n. En ese sentido, parece que idΘntica preocupaci≤n serφa aplicable tambiΘn a otras muchas tecnologφas. Si SOAP se implementara irresponsablemente, por supuesto podrφa resultar inseguro, pero ┐no es posible implementarlo de forma segura? ____________________________________________________________________ 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 * Juan Cruz Ruiz de Gauna * David G≤mez * Oscar Esteban * Jes·s Reyes * Fernando Garnacho _____________________________________________________________________ -- 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. _____________________________________________________________________ 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). _____________________________________________________________________