jueves, enero 31, 2013

Fin de Gira en Galicia y cursos de Forense & Hacking

La semana que viene llegamos al final de la Gira Up To Secure 2013, donde pasaremos por las ciudades de Vigo y A Coruña para finiquitar por el momento esta actividad. Además de estos eventos, durante la semana que viene tendremos una serie de formaciones dedicadas a Análisis Forense de Sistemas Windows y Análisis Forense de Dispositivos Móviles en las oficinas de Informática64 y un curso de Ataques en redes de datos IPv4 & IPv6 que realizaremos Online.

Para completar toda la información de actividades, hoy tenemos la presentación del libro Hacker Épico a la que aún puedes apuntarte y yo mañana estaré dando una conferencia en FiturTech sobre alguna cosa que tenga que ver con Seguridad Informática & Hacking. El calendario completo de lo que queda de semana y de la semana siguiente es:
31 de Enero - Madrid: Presentación de Hacker Épico [*][G]
01 de Febrero - Madrid: FiturTech 
[*][G]
04 de Febrero - Móstoles - Análisis Forense de sistemas Windows
05 de Febrero - Radio: La Mañana de la Cope a las 11:30 
[*][G]
05 de Febrero - Vigo: Gira Up To Secure 2013 
[*][G]
05 de Febrero - Vigo: IT Camp 
[G]
05 de Febrero - Online: Ataques en redes de datos IPv4 & IPv6
06 de Febrero - A Coruña: Gira Up To Secure 2013 
[*][G]
06 de Febrero - A Coruña: IT Camp 
[G]
07 de Febrero - Móstoles: Análisis Forense de Dispositivos Móviles
 
[*] Estaré yo [G] Gratuito
Saludos Malignos!

miércoles, enero 30, 2013

Incidentes de Ciberguerra y Ciberespionaje entre países

La ciberguerra o el ciberespionaje entre países no existe, o eso insisten en defender la mayoría de los gobiernos, lo que sin duda significa una clara declaración de lo contrario. Desaprovechar un escenario de batalla tan cómodo para los ejércitos como la red es demasiado suculento como para no ser utilizado. Es mucho más barato enviar un exploit que una dotación de tropas, con sus correspondientes aprovisionamientos y armamentos. Además, bien hecho, puede ser el comando más indetectable de todos, por lo que todo son ventajas... a priori.

Las desventajas son las mismas que se convierten en ventajas, pero desde el punto de vista enemigo. La mayoría de los sistemas defensivos pierden utilidad cuando no hay una objeto físico que golpear, sino un payload que bloquear. Hay que cambiar el foco de los presupuestos. Hay que comprar algo menos de hierro y un poco más de talento e inteligencia que pueda ser utilizado tanto en ataque como en defensa.

Dicho esto, hay que decir que mientras que todo el mundo niega hacerlo, algunas organizaciones con OTAN han encargado a expertos la realización de estudios sobre legislación internacional que puede ser aplicada a la ciberguerra, el ciberespionaje o el ciberterrorismo, dando como resultado el Manual Tallinn, que dice cosas como que es legal matar hackers civiles si participan en incidentes.

Hablar de ciberguerra, ciberespionaje o ciberterrorismo se puede hacer sólo desde el punto de vista de los incidentes que han podido ser descubiertos, aunque en muchos de ellos no se ha podido determinar su autoría más allá de ciertas especulaciones. Sin embargo, todos los que han sido descubiertos han contado con alguna ciberarma "cyberweapon", término que aunque a muchos suena mal hace referencia a un tipo de software malicioso creado con un único objetivo, y que lo normal es que solo tenga un uso, pues su ejecución provocará necesariamente su inutilidad.

Es decir, que una vez que se lance hay que darlo por perdido, tanto si tiene éxito como no, pues solo vale para un objetivo. Esta regla no es del todo cierta, pues si el enemigo no aprende del ataque, entonces podrá seguir siendo utilizado algo por lo que los países necesitan sus equipos de defensa cibernética: si no para defender, sí para aprender y no ser atacados dos veces de la misma forma.

Rusia vs Estonia

Dicho esto, como el primer incidente de ciberguerra en la modernidad actual se habla siempre del ataque de denegación de servicio distribuido (D.D.O.S) que se lanzó contra Estonia y que afectó a varios sitios web del gobierno. Estonia acusó al gobierno de Rusia de estar detrás de los ataques, que se produjeron tras la retirada de un memorial escultórico soviético del centro de la ciudad de Tailin para ser recolocado, durante los días del 25 de Abril al 5 de Mayo de 2007. Al final, solo algún joven como Dmitri Galushkevich fue condenado por estos ataques.

China vs USA: Operación Aurora

La Operacion Aurora se catalogó como un ataque de ciberespionaje, aunque alguno alzó la voz para decir que fue un ataque de China a Estados Unidos, aunque realmente se produjo contra los servidores de Google que se encontraban en aquel país. Se produjo durante el año 2009, cuando Google detecto a finales de año que alguien había instalado un backdoor en sus servidores para robar el código fuente de sus proyectos. Tras analizar en detalle el binario utilizado, se descubrió que utilizaban algoritmos de código de redundancia cíclica CRC de los que sólo había documentación en chino y además pudieron descubrir varias rutas que hacían referencia a un programa llamado Aurora, lo que dio nombre a toda la operación.

Figura 1: Código de Aurora donde se ve la ruta del proyecto

Google abandonó China, empezó a servir desde Hong-Khong y se reunió con el presidente Obama al que trasladaron sus sospechas de que el gobierno chino estaba detrás del ataque y llegaron a apuntar hasta a un centro de entrenamiento del gobierno. Se siguió el exploit que había sido utilizado - un 0day del motor JavaScript de Internet Explorer 6 - y se localizó a un descubridor  en oriente medio que se lo había notificado a Microsoft seis meses antes, pero se sospecha que alguien lo vendió al gobierno chino. No pasó nada más ante los medios y Google recomendó a todos sus usuarios utilizar Mac OS X o Linux.

Los incidentes entre China y USA son muchos, y se sospecha que atacantes chinos se colaron en los satélites de USA para interceptar comunicaciones durante los años 2007 y 2008. Lo más curioso se produjo quizá en 2011, donde en un programa de la televisión China aparecía un software para hacer ciberataques en el que se escapó en una lista que se estaba atacando a una universidad americana, lo que levantó ampollas en los USAChina, por su parte también se quejó y denunció también en la televisión que estaba siendo atacada desde direcciones IP pertenecientes a equipos de las redes del gobierno americano, mostrando los datos por la televisión para que todos lo vieran.

Figura 2: La dirección americana que "supuestamente" atacaba a China

Otro popular indicente entre USA y China es, por supuesto, el Informe Mandiant sobre APT1, donde se acusa desde Estados Unidos de la existencia de una unidad militar en el ejercito chino llamada Unit 61398 dedicada al ciber-espionaje estratégico mundial. En el último informe del año 2013 que el DoD (Departement of Defense) del gobierno americano que se envió al Congreso de los USA, se afirma directamente que el ejercito de China ha realizado operaciones de ciberataque a los sistemas de defensa. Concretamente, en el informe de Sistemas Militares Resistentes y Ciberamenzas Avanzadas, el DoD afirma que le han robado diseños militares de alta importancia para la seguridad nacional.

China VS Tibet

Mientras que por otro lado, los activistas políticos pro-Tibet se encuentran desde hace mucho tiempo bajo una orda de ataques especialmente diseñados para Mac OS X - el Dalai Lama usa Mac OS X- donde mutan una y otra vez el malware para robar información de sus sistemas. OSX/Imuler ha sido descubierto en diferentes formas, pero siempre con un gancho que pudiera atraer a miembros pro-Tibet, como una carta en su favor, o unas fotografías de alguna reunión de ellos. Por supuesto, todos apuntan a China como origen de los mismos.

Figura 3: El Dalali Lama usando Mac OS X
Siria, Bahréin, Vietnam e Irán vs disidentes del régimen

No solo China ataca a sus disidentes, los regímenes de Siria, Bahréin, Vietnam e Irán utilizan un buen número de herramientas para censurar las conexiones a Internet y vigilar a los ciudadanos contrarios a ellos, com se recoge en el informe de Reporteros sin Fronteras titulado Enemigos de Internet. Muchos de ellos utilizan técnicas de ciberespionaje con herramientas como FinFisher o Trovicor, y si es necesario tira abajo las conexiones de Internet, como ya hicieran primero Egipto y luego Siria. Todos los actos de este tipo, son recogidos en la web Spy Files de Wikileaks.

USA & Israel vs Irán

Sin duda, el incidente de ciberguerra más impactante a día de hoy sigue siendo Stuxnet, el ataque que se produjo contra las centrales nucleares iranís y del que a día de hoy se sigue hablando en las noticias - que según parece el gobierno americano busca saber quién dio datos a los medios de comunicación sobre que era una operación americana -. Fue descubierto en Junio de 2010 y fue el responsable de acabar con las centrales nucleares iranís mediante la manipulación de los datos en el sistema SCADA.

A día de hoy es ampliamente asumido que fue creado a medias por el gobierno de los Estados Unidos de América e Israel, para conseguir acabar con el programa de enriquecimiento de Uranio del presidente de Irán - no os perdáis las entrevistas del documental de ciberguerra sobre este tema -. El gusano Stuxnet se difundía utilizando varios 0days utilizando los pendrives como medio de infección, ya que los equipos de las centrales nucleares estaban aislados de Internet.

Una vez infectado uno de los equipos de la red, Stuxnet manipulaba valores en los sensores que alimentaban el sistema SCADA, haciendo creer a los ingenieros que algo iba mal en la central, de tal forma que al final lanzaron las medidas de protección, anulando su funcionamiento.

Figura 4: Gráfico de infecciones encontradas de Stuxnet por países

El gusano se les fue de las manos, y a dia de hoy todavía hay equipos infectados con él por todo el mundo. Una obra de ingeniería de seguridad ofensiva que causó por igual miedo y admiración por parte de los técnicos que incluso le premiaron con un Pwnie Award.

¿? vs USA

Estados Unidos no solo ha sido puesto en el lado de los atacantes y él también se ha quejado de intrusiones de ciberataques, ya que según parece, en el año 2008 el Pentágono fue seriamente comprometido por un pendrive que se conectó a una máquina en el oriente medio, y que tuvo acceso a documentos confidenciales que fueron enviados a servidores bajo el control de agencias de inteligencia extranjeras.

USA vs Rusia

También en el año 2010 el gobierno de USA deportó a varios espías rusos - que intercambió con Rusia por otros espías americanos  en Suiza - por acusación de traición, de los cuales uno de ellos había trabajado en Microsoft, lo que hizo que se revisaran todos los procedimientos y datos que podrían haber sido enviados a la otrora némesis en la guerra fría.

Rusia vs Georgia

Y es que a este juego parece que juegan todos y de todas las formas posibles, ya que en noviembre del 2012, la República de Georgía cazó a un ciberespía ruso robando datos por medio de un exploit en un PDF que fue utilizado en su propia contra para ser grabado y reconocido por la antaño República Soviética, lo que volvió a dejar claro que parece que nadie parece resistirse al jugo que dan los ataques cibernéticos a las fuentes de información de las agencias de inteligencia nacionales.

Figura 5: El espía ruso grabado con su propia cam con su propio malware

Ciberespionaje: Duqu, Flame, Red October y NetTraveler

En 2011 apareció Duqu, un gusano cuasi idéntico a Stuxnet pero con un objetivo distinto. Según el análisis técnico del mismo, Duqu fue creado para generar una base de datos de inteligencia mundial, robando datos de todos los equipos infectados. Según parece, tanto Duqu como Stuxnet fueron creados en el año 2007, pero se tardaron años en descubrir.

En el año 2012 apareció Flame, un nuevo malware ligado muy de cerca según Kaspersky a Stuxnet debido a las similitudes en algunos módulos, que estuvo años infectando equipos por todo el mundo y recolectando datos masivamente. Utilizaba varias funciones de infección, y recolectaba hasta los metadatos de las fotografías, pero lo más peculiar de Flame fue tal vez el sistema de protección e infección que usó basándose en un ataque criptográfico a los certificados que Microsoft utilizaba en las licencias de Terminal Services, lo que le dio cuasi carta blanca frente a la mayoría de las soluciones antimalware que no iban a eliminar un software firmado por Microsoft. No se supo quién estaba detrás de él, pero se asume que es una evolución de la operación Stuxnet y Duqu. Por supuesto, también Flame ganó un Pwnie Award al mejor mass ownage.

En Noviembre de 2012 saltó a la primera plana Red October, un malware pensado para crear una infraestructura de robo de información a la carta. Con más de mil módulos distintos para buscar información, y enfocada a altas esferas, el malware tiene detalles de búsqueda de datos tan curiosos como las extensiones de documentos cifrados con Acid Cryptofiler, un software que parece que utilizan en la OTAN.

Figura 6: Operación Red October

En Junio de este año, la operación de espionaje descubierta fuer NetTraveler, un sistema similar a Red October que estaba funcionando desde el año 2004, y que se dedicaba a robar datos de clientes para venderlos al mejor postor.

Ciberespionaje ciudadano en Egipto y USA: FinFisher, FinSpy y 12 Monkeys

Por supuesto, en temas de ciberespionaje hay que hablar de las empresas que venden software  y servicios profesionales de infección vigilancia y control, como el caso del software comercial FinFisher que fue encontrado en las dependencias del gobierno Egipcio - con su versión para dispositivos móvil FinSpy - o todos los servicios de ciberespionaje que ofrecía la empresa HBGary al gobierno americano, como por ejemplo 12 monkeys. A día de hoy, los paneles de control de FinFisher & FinSpy han sido localizados en 25 países.

Las filtraciones de Edward Snowden, el programa PRISM y el espionaje americano

Hay que dedicar un apartado especial a las filtraciones del programa de espionaje PRISM filtradas a la prensa que mostraban cómo el gobierno de USA estaba utilizando a las tecnológicas americanas para espiar a ciudadanos extranjeros. Rápidamente las compañías negaron dar acceso a los servidores, aunque la propia ley les prohibe hablar de ello, así que la información estará siempre mediatizada. La última revelación fue que se armaron comitivas de espionaje para eventos de espionaje del G8 y el G20 que tuvieron lugar en Londres, donde se espió a primeros ministros, como el ruso Dmitry Medvedev.

No pretende ser este post más que una reflexión personal para dejar claro que cuando se dice eso de que la ciberguerra, el ciberespionaje o el ciberterrorismo es cosa de mentira o exageraciones de los medios de comunicación es porque no han visto a un exploit manipular los grados de posicionamiento de los mapas de un avión en un proceso de aproximación para el aterrizaje... Yo sí, y desde entonces no duermo igual de bien ni me subo a los aviones con la misma calma.

Saludos Malignos!

martes, enero 29, 2013

Recuperar mensajes borrados de WhatsApp

Desde el mes de Octubre del año pasado llevamos trabajando en Informática 64 junto con Alejandro Ramos (@aramosf) en Recover Messages y ya, con varias funciones bastante testeadas - aún estamos ajustando cosas -, hemos decidido anunciarlo, aunque ya lleva online desde principios de año.

Figura 1: Página principal de Recover Messages

El servicio está orientado a recuperar, con técnicas forenses, mensajes recuperados de bases de datos de WhatsApp para Android y para iPhone, aunque después nos hemos venido arriba y estamos añadiendo otras bases de datos como la de los SMS, e-mail, Line o Tuenti - por ahora.

Figura 2: Funciones actuales activas en Recover Messages

El funcionamiento es bastante sencillo. Se sube una base de datos de uno de esto servicios, y Recover Messages muestra los registros que se almacenan en la base de datos, las fotografías enviadas y los datos recuperados mediante técnicas forenses, donde aparecen mensajes completos o parciales que se han intercambiado con WhatsApp o el resto de aplicaciones.

Figura 3: Panel de registros recuperados de una base de datos WhtasApp Android

Para bases de datos grandes, el servicio tiene un coste, pero para ver los registros de bases de datos pequeñas es gratuito.

IMPORTANTE: Si haces como dicen algunos un proceso de desinstalación de WhatsApp y vuelta a instalar machacarás todos los mensajes borrados de la base de datos. WhatsApp sólo restaurará los antiguos que no hayan sido borrados y perderás toda posibilidad de hacer uso de RecoverMessages para extraerlos de la base de datos con técnicas forenses.

Saludos Malignos!

Actualización: Si quieres evitar que se borren los mensajes de WhatsApp en un terminal puedes utilizar WhatsApp Anti-Delete Protection Tool y si quieres saber más sobre cómo sacar la información de un terminal iPhone debes leer el libro de Hacking iOS: iPhone & iPad.

lunes, enero 28, 2013

Entrevista a Rodrigo Yepes, autor de Hacker Épico

Es más que probable que muchos no conocierais a Rodrigo Yepes (@rodripol) antes de leeros el libro de Hacker Épico, yo tampoco lo conocía hasta que el libro estuvo a punto de ser terminado. Amigo personal de Alejandro Ramos (@aramosf) y amante de la literatura, no trabaja en nada que tenga que ver con hacer pentesting o seguridad informática, por lo que ha sido el balance perfecto la historia de Hacker Épico. Lector incansable, y amante de la novela negra, ha dejado su impronta en el libro, consiguiendo ese efecto tan peculiar en el libro que hace que todo el mundo que nos lo hemos leído lo hayamos hecho en tiempo record.

Figura 1: Rodrigo Yepes

El día 31 de Enero estará en la presentación del libro de Hacker Épico - a la que podéis asistir - que vamos a hacer en Madrid, donde os vamos a contar muchas cosas sobre cómo salió el libro, y las novedades - que las hay - sobre esta historia que va a traer secuelas, así que para que conozcáis mejor a Rodrigo Yepes, le he hecho una entrevista. Disfrutadla.

Saludos Malignos!

1.- Rodri, ¿cómo acabaste sin dedicarte a la seguridad informática 64 metiéndote en un libro de hackers?

La respuesta a esa pregunta tiene nombre propio: Alejandro Ramos. Somos amigos desde los nueve años, así que cuando me pidió que escribiéramos juntos un libro sobre su gran pasión, la seguridad informática, un libro que yo sabía que anhelaba escribir desde hacía tiempo, no pude negarme. Además, la idea de utilizar una historia para desarrollar los diferentes elementos técnicos, en definitiva, de escribir una mezcla de novela y manual de hacking, me pareció tan original y tan llena de posibilidades que no sólo me limité a aceptar, sino que me zambullí en el proyecto lleno de ilusión.

2.- Se notan en el libro muchos tintes de novela negra... ¿tienes algo tú que ver en esto?

La idea de escribir algo diferente a los muchos y muy buenos manuales técnicos de hacking que ya existen (y nadie me apunta con una pistola cuando digo que casi todos son de la Editorial Informática64) no fue mía, sino de Yago Jesús, que lo explica muy bien en el excelente prólogo de Hacker Épico.

El paso siguiente fue construir una historia que fuese atractiva por sí misma, no sólo la excusa o el camuflaje de las explicaciones técnicas que Alejandro quería introducir. Al principio, lo único que teníamos claro era el protagonista.

Queríamos que fuese un joven informático al que unas especiales circunstancias obligaran a echar mano de sus conocimientos. La resolución de un misterio por un investigador con habilidades concretas es la premisa de la novela detectivesca o policiaca.

Como también queríamos describir el ambiente en el que se mueven los personajes e incorporar algunos elementos de crítica social, decidí que la novela negra era el mejor vehículo para contar nuestra historia. Además, la novela negra es el género que mejor conozco y con el que me sentía más cómodo.

3.- ¿Cuáles son tus escritores y libros preferidos?

Cualquier lista que te diera quedaría incompleta, pues son muchos los autores que califico de excelentes y muchos los títulos que me han marcado como lector. Si dejamos al margen a los clásicos y nos centramos en el género negro, empezaría por citar a los padres del mismo: Dashiell Hammett con su “Cosecha Roja” y Raymond Chandler con “El largo adiós”. También Ross MacDonald y “El caso Galton” entrarían en esta categoría.

De los escritores más modernos, los mejores momentos los he pasado con George V. Higgins (“Los amigos de Eddie Coyle” tiene los mejores diálogos jamás escritos), Joseph Wambaugh (“Los nuevos centuriones” y la divertida “Hollywood Station”) y, sobre todo, James Ellroy (La trilogía americana es simplemente imprescindible). Michael Connelly (“El Eco Negro”, “Más oscuro que la noche”, el mejor heredero de Chandler), Dennis Lehane (sobre todo por “Cualquier otro día”) y Don Winslow (“El poder del perro” es para mí ya un clásico de la Literatura con mayúsculas) son geniales. Algo más ligeros, pero con muchas características interesantes, son Robert Crais (“L.A. Requiem” es impresionante), Lee Child (“El camino difícil”; Child es el creador de Jack Reacher, de moda por la película de Tom Cruise), Harlan Coben (“No se lo digas a nadie”) y Barry Eisler (“Sicario”).

Aunque suene a tópico, no están todos los que son, pero sí son todos los que están.

4.- ¿Has aprendido mucho hacking escribiendo el libro?

Por supuesto. No es que ahora sea capaz de hacer las cosas que hace Ángel Ríos en el libro, pues para eso hay que tener los conocimientos y la experiencia de Alejandro, que es el responsable de toda la parte técnica, pero sí que he comprendido las enormes posibilidades que ofrecen las diferentes herramientas y procesos utilizados, así como la importancia de la seguridad informática en el mundo actual.

Antes de embarcarme en este emocionante proyecto, me sentía seguro delante del ordenador. Ahora, gracias a vosotros, me comporto de forma más lógica y coherente, es decir, como un jodido paranoico. Incluso he tapado con cinta aislante la webcam de mi portátil…

5.- ¿Esperabas que la gente tuviera una reacción tan positiva con la lectura del libro?

Ni mucho menos. Confiábamos en que la originalidad de la propuesta fuese atractiva para los profesionales del sector y los estudiantes que empiezan en esto de la seguridad informática, pero ni siquiera soñábamos con una recepción tan entusiasta, incluso de personas ajenas a este mundo.

La verdad es que las críticas en blogs especializados y los comentarios recibidos tanto en la web www.hackerepico.com como por Twitter han superado todas nuestras expectativas. Estamos muy contentos por cómo está funcionando el libro y por las constantes peticiones de una segunda parte, prueba de que los lectores han aceptado la original mezcla de conceptos y se han enganchado a la historia de los personajes, además de alabar la parte técnica. A todos ellos sólo puedo decirles: muchas gracias.

6.- ¿Tienes tú algo del personaje Marcos del libro?

¿Yo? ¿Por qué lo preguntas, colega? Si eso te supone algún problema, podemos salir a la calle y solucionarlo… Es broma. Claro que sólo se entiende si se ha leído el libro. Pero la respuesta es que no mucho, a parte de que ambos somos unos ignorantes en materia de hacking. A Alex y a mí nos pareció gracioso introducir un personaje que fuera amigo del protagonista pero ajeno a su mundo, que resolviera los obstáculos de forma distinta y viera con otra luz las diferentes situaciones que se les plantean.

Para caracterizar a Marcos, utilicé varios elementos presentes en personajes antológicos que conocí como lector y algunos otros que son completamente originales. No creo que sea mi alter ego ni nada por el estilo, aunque creo que cuando escribes ficción siempre dejas algo de ti en cada personaje.

7.- El día 31 de Enero tenemos la presentación del libro en Madrid, ¿hay ya nuevas historias de los personajes rondando tu cabeza?

Después de poner el punto y final a la novela, no volví a pensar en el destino de los personajes ni en ningún tipo de continuación, pero después de la gran acogida que ha tenido Hacker Épico y de las muchas peticiones recibidas para escribir una segunda parte, es natural que hayamos pensado en nuevas aventuras y en la forma de contarlas.

Si algún día lo hacemos, mantendremos la misma óptica que ha hecho original al libro, pero sin que sea más de lo mismo. Queremos que tanto los personajes como el tratamiento de los aspectos técnicos evolucionen. Sólo cuando estemos seguros de poder ofrecer una historia atractiva y un material novedoso nos pondremos a ello. Pero de momento todo está muy verde.

8.- ¿Ha sido duro el proceso creativo de Hacker Épico o estabais bastante de acuerdo en todo?

El proceso creativo ha sido duro, pues la redacción de un libro de estas características representa un trabajo inmenso, pero las dificultades no han venido porque haya habido fricciones entre nosotros. Todo lo contrario. Una vez nos pusimos de acuerdo en la forma que debía adoptar la novela, en la estructura de la historia y en la caracterización de los personajes, el resto fue sobre ruedas. Las ideas buenas eran aceptadas y las malas descartadas independientemente de quién las aportara. En ese sentido ayudó mucho que, como amigos que somos, compartiéramos los mismos intereses y que ambos tuviéramos bastante clara la meta a la que queríamos llegar.

Lo duro –y también lo divertido- fue completar el camino. Yo me encargaba de hacer avanzar la historia sin preocuparme por cómo el protagonista conseguía descifrar un documento o penetrar en una red wireless. Para mí eso era magia. Alejandro me decía: “puede hacerse”, y rellenaba los huecos que yo iba dejando con sus asombrosas explicaciones técnicas.

9.- Cuando yo lo leí, quería mataros. Cada capítulo me dejaba enganchadísimo y tenía que empezar en el siguiente. ¿Medís la intensidad de la trama con una cuadrícula?

¡Jajaja! Me alegra saberlo, pues esa era nuestra intención. No utilizamos ninguna cuadrícula, pero sí que queríamos mantener la tensión narrativa para que el lector no abandonara el libro a las primeras de cambio. La idea era servirnos de la historia para desarrollar materias de hacking, pero también aspirábamos a que la historia fuera lo suficientemente atractiva por sí misma para que el lector quisiera seguir hasta el final.

Después, podría releer los capítulos y prestar mayor atención a los aspectos técnicos e incluso profundizar en ellos acudiendo a los apéndices y referencias, pero primero queríamos que enfatizara con los personajes y sus conflictos, que observara el hacking desde una perspectiva y bajo unas circunstancias diferentes a las habituales. Para lograrlo, utilizamos la estructura narrativa y los elementos característicos de la novela negra, y por supuesto algún que otro cliffhanger.

Hemos recibido muchos comentarios similares al tuyo, de lectores que nos felicitan por lo adictivo de la trama y por haberles “obligado” a terminar el libro en pocos días o incluso horas. Es muy gratificante porque significa que hemos logrado el objetivo que nos habíamos propuesto.

10.- ¿Qué le dirías a alguien que aún no haya leído la historia de Hacker Épico? ¿Cómo describirías el libro?

En primer lugar le diría que se va a encontrar con una propuesta muy original. Hacker Épico es una mezcla de novela negra y manual de hacking, donde la ficción sirve para desarrollar diferentes materias técnicas que son tratadas con absoluto rigor. A pesar de parecer que novela y manual son formatos antagónicos, hemos tratado de conjugarlos de tal modo que ninguno prevalezca sobre el otro.

Se podría decir que el resultado es una novela técnica o un manual novelado. En él se narra la historia de Ángel Ríos, un auditor de seguridad informática que se ve envuelto en una trama criminal por tratar de ayudar a una antigua amiga del instituto. Durante su aventura, se encontrará con muchos obstáculos y peligros. Para enfrentarse a estas extraordinarias circunstancias tendrá que echar mano de sus conocimientos sobre hacking, aunque también dispondrá de una ayuda más convencional.

El libro contiene numerosas referencias al mundo de la tecnología, el cine, la televisión, los comics… y particulares homenajes a algunos títulos que nos han marcado como espectadores o lectores. También algún componente de denuncia y crítica social, que no podía faltar en una novela negra.

En definitiva, Hacker Épico pretende ser tan útil como entretenido, un libro dirigido a los amantes de la seguridad informática que buscan algo distinto del clásico manual, pero también una novela que cualquiera pueda leer con independencia de sus conocimientos informáticos. A buen seguro que al terminar sentirá más interés en ampliarlos.

domingo, enero 27, 2013

Cálico Electrónico en Windows 8 y Huérfanos Electrónicos

Acaba de hacer un año que arrancamos con el proyecto de Cálico Electrónico y se nos ha pasado volando. En este tiempo, tras lanzar la página web oficial de Cálico Electrónico, hemos sacado ya cinco capítulos de la temporada 4, hemos recuperado todos los capítulos en HD a Ful de las temporadas 1, 2 y 3. También estamos acabando de recuperar los 50 capítulos de Mundo Cálico y hemos comenzado ya con los Huérfanos Electrónicos

Figura 1: Huérfanos Electrónicos. Capítulo 1: La ciudad sin héroe

Cada miércoles, desde hace ya muchos meses sacamos las tiras de cómic de Deili Electrónico - donde acabamos de subir un nuevo visor para ver mejor las tiras y compartirlas cómodamente -, y para tener informado a todo el mundo, mantenemos un canal en Twitter, un canal en Google Plus, una cuenta en Tuenti, un canal Youtube y una página en Facebook - que ha superado hace poco los 10.000 likes -.

Figura 2: Nuevo visor de tiras Deili Electrónico con miniaturas e integración social

Además, estamos trabajando en llegar a todas las plataformas móviles, para lo que tenemos por ahora una aplicación de un fan en Android, una aplicación propia para Windows Phone y acabamos de subir otra aplicación propia para Windows 8, donde podéis seguir todos los capítulos y noticias de nuestro héroe.

Figura 3: App de Cálico Electrónico para Windows 8

Además de eso, para mantener vivo el proyecto, hemos hecho trabajos en el mundo de la publicidad, visitado una decena de congresos y festivales de cómic, seguimos manteniendo la tienda oficial Cálico Electrónico donde tienes el merchandising oficial y el pendrive más molón de la historia, se ha cerrado la ilustración de un libro que pronto saldrá a la venta y hemos firmado un nuevo cómic con Ediciones Babylon que está a punto de ver la luz.

Figura 4: El pendrive de Cálico Electrónico

Ha sido un año largo, pero intenso - en el que incluso hemos ganado un premio a la mejor serie de animación en el festival de Girona - donde hemos peleado para mantener vivo al gordito. Gracias a todos los que seguís las cuentas oficiales, distribuis nuestros contenidos, os instalais nuestras apps y nos apoyáis comprando algo de merchan.

Saludos Malignos!

PD: Como seguro que lo vais a preguntar, el último capítulo de la temporada 4 está pensado para principios del mes de Marzo de 2013... no queda tanto...

sábado, enero 26, 2013

Examen Máster Seguridad UEM 2012-2013

Aquí tenéis el examen del curso 2012-2013 del módulo de Seguridad en Aplicaciones Web del Máster de Seguridad de la UEM. El tiempo de realización es de 1 hora y media. No vale copiar, no vale hablar con el compañero y si estás en tu casa haciéndolo no vale usar Internet para buscar las respuestas. Las soluciones las pongo mañana.

1.- Tienes una empresa con una aplicación web de presencia en Internet que carga los contenidos que se publican dinámicamente desde una base de datos. Desde esa web, hay un acceso especial para clientes que pueden acceder a una aplicación de compras. Además, la empresa tiene una intranet para la gestión del personal. ¿Qué medidas de seguridad consideras que se deberían tomar en cuanto a la arquitectura de servidores y servicios? Cita reglas generales y medias concretas que creas convenientes.

Respuesta: Fortificación de un servidor web Apache. Las leyes de la fortificación

2.- Describe en qué consiste un ataque XSS No-persistente, un entorno en el que se pueda encontrar esta vulnerabilidad y cómo puede ser utilizado para distribuir malware a través de Google.

Respuesta: Buscadores como arma de destrucción masiva: Ataques XSS Google-Persistentes 

3.- Describe como se puede hacer un proceso de hijacking de sesión a un usuario de una red social en la que las cookies no vayan por HTTP-s si la web no tiene una vulnerabilidad de código (ni SQLi, ni XSS).

Respuesta: Firesheep o Wirehsark

4.- Describe algún método para robar una cookie marcada como HTTP-Only con un ataque de XSS.

Respuesta: Usando el método TRACE, usando errores 400 en Apache o usando Applets Java

5.- Una aplicación web de una empresa carga un Applet Java en la página de login para autenticar a los usuarios. Tras probar varios usuarios erróneos, se puede comprobar que la aplicación no hace Post-Back. ¿Qué fallo de seguridad podría tener esta aplicación y cómo debería investigarse?

Respuesta: Validación local. Se usarían decompiladores de Applets 

6.- Una aplicación web en PHP con MySQL es vulnerable a SQL Injection. Se quiere extraer la versión de Mysql realizando un ataque de Blind SQL injection. Describe el proceso que habría que realizar.

Respuesta: Blind SQL Injection en MySQL y Optimización de Blind SQL Injection en MySQL

7.- Describe en qué consisten los ataques de Time-Based Blind SQL Injection y cómo pueden realizarse sin hacer uso de funciones específicas de retardo de tiempo como delay o sleep.

Respuesta: Técnicas avanzadas de ataques Blind SQL Injection

8.- Una empresa de venta online, tras un balance de fin de mes, comprueba que los cobros realizados por las ventas no corresponden con el precio de venta de los artículos vendidos. ¿Qué se debería comprobar en la aplicación web si se sabe que nadie ha manipulado los precios en la base de datos?

Respuesta: Coja su cambio, sea justo.

9.- Dado el siguiente código PHP del lado del servidor ubicado en la ruta web siguiente:

http://www.miweb.test/home/public_html/descargafichero.php
<?php
session_start();
$sDocumento = $_GET['documento'];
header("Content-type: application/force-download");
header("Content-Length: ".filesize($sDocumento));
header("Content-Disposition: attachment;
filename=".basename($sDocumento));
header("Content-Transfer-Encoding: binary");
if (!@readfile($sDocumento)) echo "Error";
?>
Responde a las siguientes cuestiones:

a) Determina qué tipo de vulnerabilidad está presente en él y describe sus riesgos.
b) Escribe una URL de ataque que permita explotarla para poder acceder al código fuente de la página descargafichero.php
c) Escribe la URL de ataque para descargar un fichero con todos los usuarios de un sistema *NIX*.

Respuesta: El cucharón

10.- En una aplicación web, la aplicación autentica a los usuarios con un árbol LDAP, para ello, cada usuario tiene un atributo uid y un atributo password. El programador ha filtrado el * y utiliza la función crypt antes de usar la contraseña en una consulta AND LDAP como ésta.
V_username: valor de usuario introducido en la página web por el cliente.
V_passwd: valor de contraseña introducido en la página web por el cliente.
C_passwd =crypt(v_passwd) 
Consulta que da acceso o no a la aplicación:
(&(uid=+v_username+)(password=+c_passwd+))
¿Con qué inyección LDAP conseguirías entrar si la se está utilizando un árbol LDAP basado en OpenLDAP?

Respuesta: Or uno igual a uno ... en LDAP Injection

Saludos Malignos!

Hoy examen de seguridad de aplicaciones web a las 11:00

Para terminar esta ajetreada semana que me ha llevado por Bilbao, Burgos, Palencia, Valladolid, Madrid y Palma de Mallorca, toca ir hoy a Villaviciosa de Odón a dar una clase y examinar a mis chic@s del Máster de Seguridad de la UEM. El examen se lo voy a poner sobre las 11:00, así que por si alguno quiere hacerlo al mismo tiempo, lo voy a poner al mismo tiempo en el blog. Tenéis 1 hora y media para resolverlo ¡Sin utilizar Google

Mientras tanto, puedes repasar con los exámenes de años anteriores, como seguro que ya han hecho ellos:
- Examen Máster Seguridad UEM 2009-2010
- Examen Máster Seguridad UEM 2010-2011
- Examen Máster Seguridad UEM 2011-2012
En el 2008-2009 hice trabajo, pero desde entonces exámen. A ver que tal os sale a vosotros la prueba de este año - que será fácil.. A las 11:00 preparados para responder. }:))

Saludos Malignos!

viernes, enero 25, 2013

Bypassing logins & malicious cookies en una web insegura

En cualquier auditoría de seguridad de aplicaciones web, es imposible evitar poner una comilla, dejándola caer como el que no quiere la cosa, sobre un campo de login para ver si la auditoría va a ser "rápida" o no. Si el resultado es el buscado inevitablemente toca colocar un 'or '1'='1. Si aún con esas no hemos conseguido nuestro objetivo, tocará hacer más pruebas, como probar passwords suprayectivas o la fuerza bruta para ver si la ofensa que indirectamente nos lanza el - por ahora -astuto sistema de logins de la aplicación web en cuestión lo va a soportar o no, mientras la observaremos con recelo en todo momento que nos tenga en jaque.

Figura 1: Login de acceso

Hace ya tiempo, mientras auditaba uno de esos sitios en los que no se encuentran más que páginas estáticas y pocas variables de las que aprovecharse, un panel de login se interpuso en mi camino. Sería él por supuesto, el que me daría paso mediante un SQL Injection para abrirme la puerta a toda la base de datos. Lo primero en estos entornos es saber cómo funciona, así que enviamos un usuario y contraseña al azar, para ver como trata la aplicación las peticiones.

En este entorno que reproduce una situación análoga a lo que os cuento, esa petición POST se encargará de validar mis datos de acceso mediante las variables user= y pass= con una aplicación PHP que, como es lógico, me re-direccionará a una página de error.

Figura 2: Análisis de la petición POST usando Burp Suite

Como anteriormente ya habían sido sometidas esas variables a torturas con mis jeringuillas cargadas de SQL y el famoso Intruder de Burp Suite, se me ocurrió valerme de un login similar en otro dominio, desde el que había conseguido un acceso con SQLi y así ver la forma en que la aplicación trataba a las cookies. Entre las variables de una sesión de login que conseguí se encontraban:
PHPSESSID=(Sesión Cifrada)
user_tipo=(Un dígito que define el Rol)
id_usuario=(Identificador de usuario)
user_user=(Usuario en texto claro)
id=(Identificación no utilizada)
user=(Usuario en texto claro)
pass=(Hash de la contraseña)
Sobra decir que las malas formas de gestionar las cookies saltan a primera vista, ya que el usuario y hash puedan verse en cada petición y por tanto compromete gravemente la seguridad de los usuarios administrativos ante ataques de sniffing.

Capturando la siguiente petición, la página me echaría fuera del acceso ya que introduje un login erroneo, pero mediante los campos nombrados anteriormente pude abrirme paso saltando directamente al nombre de un PHP interno de aplicación, agregando como valores tres campos importantes.

Figura 3: Petición modificada

La variable del tipo de usuario “user_tipo=1”, mostraría a la aplicación que mi cookie pertenece a un usuario con número 1 de rol, que coincide con el que utilizaría un administrador. La segunda variable y no menos importante, sería “id_usuario=1”. Sin esta variable la aplicación no nos daría acceso ya que buenamente comprueba el número de usuario de la base de datos. Es decir, que basta con manipular las cookies y no hace falta autenticarte ni nada.

Por último, “user_user=admin” es una variable no tan necesaria para el proceso de login, aunque evitaríamos errores en la página de administración y nos da juego para explotar una inyección Cross Site Scripting (XSS), ya que la aplicación lee el valor de la cookie y lo muestra directamente en la página sin filtrar caracteres extraños.

Figura 4: SQL Injection en un PHP interno gracias a la evasión del login con las cookies

Ya estamos dentro pero… ¿y el login y la password? Aprovechando que muchas aplicaciones administrativas  suelen estar mal desarrolladas - que ya hemos visto muchas cosas en el SOCtano .... - bajo premisas de "¡Total! ¡Qué más dará! ¡Si todo queda adentro!", con la facilidad de la inyección, no  hubo más que buscar en Google las passwords crackeadas que estas eran más facilonas que las del Kapital ;)

Con el acceso en mano ya solo queda trastear, ¿que pasaría si ponemos un Cross Site Scripting  (XSS) Persistente en una cookie? Una vez que escribes en la página algo con el nombre de usuario modificado, al quedar reflejado en la base de datos, éste se rescataría y se ejecutaría en el equipo de todos los usuarios.

Figura 4: XSS en la cookie

Un entorno perfecto para hacer un poco de Black SEO, distribución de malware, ataques de phising, etc..., que gracias a la auditoría ya no es vulnerable a ninguno de estos ataques. Si es que hay que hacer bien las aplicaciones web y si no... auditarlas antes de ponerlas online.

Antes de terminar - y visto que todo esto es por hacer una mala gestión de las cookies de una sesión - no podía acabar este artículo sin recomendar el Session Management Cheat-Sheet de Raúl Siles para la gestión segura de cookies de sesión y el libro del boss y Enrique Rando sobre SQL Injection.

Autor: Germán Sánchez "Un tal 4n0nym0us en el PC"
Consultor de Auditoría Web en Informática 64

jueves, enero 24, 2013

Conferencias en Palma de Mallorca, Madrid y en Málaga

Hoy estamos en Valladolid, llegando ya a la mitad de la Gira Up To Secure 2013, y ya se nota que las demos están más ajustadas, los tiempos más organizados y todo mucho más rodado. Las siguientes paradas de la gira nos llevarán, este viernes, y durante la semana que viene, a las ciudades de Palma de Mallorca, Madrid - donde se unirá Pablo González a hablar de Metasploit para para Pentesters - y Málaga, donde además de las charlas, podrás acceder apuntarte a los IT Camps, y en Málaga, además, tendremos a Hispasec Sitemas y el gran Sergio de los Santos de compañeros de evento.


También durante esa semana tendremos la presentación de Hacker Épico en la casa de Zamora en Madrid - con varias sorpresas - donde te puedes apuntar al evento en el que estarán los compañeros de SecurityByDefault. Estas son las fechas y los enlaces de registro de todo:
- 25 de Enero: Palma de Mallorca [Evento] [IT Camp]
- 29 de Enero: Radio [La mañana]
- 29 de Enero: Madrid [Evento] [IT Camp]
- 30 de Enero: Málaga [Evento] [IT Camp]
- 31 de Enero: Madrid [Presentación de Hacker Épico]
Saludos Malignos!

miércoles, enero 23, 2013

From Sticky Keys to PowerShell in Windows Server 2008

Cuando un servidor con Citrix o RDP permite el truco de las Sticky Keys, suelo usar siempre los mismos caminos. Cuando es un Windows Server 2000 o Windows Server 2003, siempre uso el truco de llamar a la ayuda para hacer clic con el botón derecho sobre tooltip informativo y llegar al panel de impresión.

Figura 1: Hacker el jailbreak desde las Sticky Keys de un Windows Server 2003

En Windows Server 2008 y Windows Server 2008 R2 solía utilizar un camino distinto, pidiendo c:\ desde la ventana del panel de control, pero después de pegarme con varios, creo que el camino más corto es pedir Powerhell.exe desde la barra y listo, que de hecho no suele estar bloqueado en ninguno de los que he probado.

Figura 2: Ejecutar PowerShell.exe desde las Sticky Keys en Windows Server 2008

Es un camino rápido, directo, y que no suele estar bloqueado en ningún servidor, así que acuérdate de él.

Saludos Malignos!

martes, enero 22, 2013

El algoritmo de cifrado que reta a los hackers "revelaed"

Muchos somos los que hemos pedido un análisis sobre la nueva patente criptográfica que ha salido por todas las noticias a nuestro experto particular en estos lares, Jorge Ramió, así que al final ha optado por escribir junto con el Dr. Alfonso Muñoz un documento en la red Criptored, que os paso a transcribir aquí por lo detallado del análisis.

Primeras impresiones sobre la solicitud de la patente “Procedimiento de doble criptograma simétrico de seguridad de Shannon por codificación de información para transmisión telemática y electrónica”

Jorge Ramió Aguirre - Alfonso Muñoz Muñoz
Miembros de la Red Temática Criptored
Madrid, 21 de enero de 2013

1. Introducción

Referencias periodísticas (entre otras):
- El País: Patente valenciana antipiratas- El Mundo: Un físico reta a los 'hackers'- Documento de la solicitud de patente
El presente escrito pretende dar luz sobre diferentes cuestiones aparecidas en la prensa nacional (España) el 3 y 17 de enero de 2013, relativas a una patente de un nuevo algoritmo criptográfico "indescifrable". Si este breve escrito sirve de guía para evaluar mejor en un futuro este tipo de sistemas, o servir de referencia a periodistas que han dado una publicidad inusual a este hecho, los firmantes del mismo se dan por satisfechos.

Este informe viene a petición de diferentes miembros de la red en cuanto a publicar una opinión, personal que no colectiva de la red, a este respecto. En los últimos días, diferentes blogs y comunidades de internautas relacionadas con la seguridad de la información se han expresado y se están expresando también en este sentido, entre ellos:
- Blog de Arturo Quirantes
- Kriptópolis
Nota: Ninguno de los miembros ni los editores de la Red Temática de Criptografía y Seguridad de la Información Criptored, con base en la Universidad Politécnica de Madrid, suele realizar comentarios sobre la opinión de terceros en cuanto a la ciencia de la criptología, centrándose su trabajo fundamentalmente en la difusión, y en su caso evaluación y estudio de trabajos publicados en conferencias, congresos y seminarios científicos, que siguen por tanto un riguroso proceso de evaluación por terceras partes. No obstante, vemos importante hacer una excepción en este caso -dada la notoriedad social que esta noticia ha alcanzado- para aclarar diferentes cuestiones.

2. Comentarios sobre la solicitud de patente en cuestión

A continuación se adjunta una serie de comentarios basados en el estudio de la solicitud de patente a la que puede acceder desde la dirección ya indicada.

En primer lugar, sin entrar a valorar aún las operaciones que en dicha solicitud indica realiza el algoritmo propuesto, hay que decir que si todo se limita a operaciones matemáticas lineales - como así parece ser- (ver el estudio del algoritmo en párrafos posteriores) el sistema tiene muchas posibilidades de ser inseguro, puesto que una de las máximas en criptografía simétrica moderna para que los algoritmos sean robustos es la no linealidad de algunas de sus operaciones.

La redacción de la patente no ayuda mucho en dar credibilidad al algoritmo. Sin ser exhaustivos, comentar son un par de cuestiones:

Aunque sea muy común en Latinoamérica usar las palabras 'encriptar' y 'desencriptar' por influencia directa del inglés, lo cierto es que en lengua española esas palabras no existen y lo correcto, más aún en un documento oficial, sería utilizar cifrar y descifrar.

Toda la redacción está plagada de afirmaciones sin fundamento, errores de concepto y diversos errores básicos de lenguajes de programación.

Por ejemplo, en la página 25 (línea 25) se afirma:
"un ordenador actual difícilmente puede operar con exactitud con números enteros de más de 15 dígitos".
Cualquier lenguaje de programación moderno permite implementar programas que manejen números de tamaño arbitrario en ordenadores normales. Por ejemplo, en lenguaje Java con la clase BigInteger.

En cualquier caso, y sólo a modo anecdótico, incluimos a continuación unas cuantas aclaraciones que el lector puede observar en el documento de solicitud de patente en cuestión:

1. Sección Descripción, página 1, línea 25:

Afirma:
"... y operaciones bancarias, criptografía de obras musicales y audiovisuales, y firmas"
Aclaración:
No existe la 'criptografía de obras musicales y audiovisuales'; sí algoritmos criptográficos que permiten proteger obras musicales y audiovisuales, así como diversos métodos basados en la criptografía, marcas de agua, etc.
2. Sección Descripción, página 2, líneas 13 y 14:

Afirma:
"Actualmente hay diversos lenguajes de cifrado"
Aclaración:
No existen 'lenguajes de cifrado'; lo que existe son algoritmos de cifra que se implementan con uno u otro lenguaje de programación, en el caso de software criptográfico como lo es el invento que se propone.
3. Sección Descripción, página 2, líneas 15 y 16:

Afirma:
"... o bien como sistema de cifrado asimétrico. Este último es muy seguro"
Aclaración:
Si el algoritmo que se presenta es de tipo simétrico, esta afirmación no es adecuada en este entorno pues son igual de seguros (o inseguros) los sistemas de cifra simétricos que asimétricos. Hablar solamente de los asimétricos como 'muy seguros' supone excluir a los primeros, lo cual es un error.
4. Sección Descripción, página 2, líneas 16 y 17:

Afirma:
"... pero no por eso resulta imposible romperlo por el procedimiento llamado fuerza bruta"
Aclaración:
Los sistemas de cifra asimétricos no se rompen por fuerza bruta, aunque podría intentarse -si se desea- pero no tiene sentido con la capacidad de cómputo actual. Existen, no obstante, algoritmos específicos para romper su fortaleza, que está basada generalmente por un problema matemático tipo NP (exponencial) de costosa solución computacional cuando los números son grandes, e.g. sobre mil bits, llámese éste problema del logaritmo discreto, problema de la factorización entera, etc. Los sistemas de cifra donde es más común usar fuerza bruta -aunque existan otros procedimientos más elegantes- son los simétricos, nunca los asimétricos. 
En el mundo real los ataques por fuerza bruta son la última solución, porque son los más costosos. De hecho, en criptografía hay un dicho cuando estamos en el mundo real: "la criptografía no se ataca, se esquiva". 
En el mundo real es más fácil obtener una clave almacenada indebidamente, procesada incorrectamente, usar fallos de programación de los algoritmos criptográficos, de los sistemas que lo implementan, etc., que atacar al propio algoritmo de cifrado.
5. Sección Descripción, página 2, líneas 18 y 19:

Afirma:
"... acaban averiguando los números primos a partir de cuyo producto se ha construido el criptograma"
Aclaración:
El autor supone que como sistema asimétrico sólo existe el algoritmo RSA, que efectivamente utiliza dos primos grandes cuyo producto es el módulo o cuerpo de cifra, pero existen otros algoritmos para el intercambio de clave y/o firma digital que no usan dos o más primos sino solamente uno como es el caso de Diffie y Hellman, Elgamal, DSA (en este caso dos primos pero en sentido diferente), además de curvas elípticas, etc. Así mismo no es apropiado afirmar que "a partir de cuyo producto se ha construido el criptograma": el criptograma se construye mediante una operaciónmatemática (generalmente exponenciación) donde interviene ese producto, el módulo o cuerpo de cifra, pero nada más.
6. Sección Descripción, página 2, líneas 19 y 20:

Afirma:
"Y no es nada fácil descubrir y almacenar números primos suficientemente grandes"
Aclaración:
En tanto no especifique el autor qué entiende por 'números primos suficientemente grandes', lo cierto es que existen muchas librerías que permiten encontrar números primos grandes con total facilidad y rapidez para las necesidades actuales. Además no se entiende qué quiere decir con 'almacenar números primos'.
7. Sección Descripción, página 2, líneas 21 y 22:

Afirma:
"... uno de los lenguajes más solventes continua siendo el llamado algoritmo DES"
Aclaración:
Insistiendo en que en este caso el DES jamás ha sido patentado como un lenguaje, decir que continúa (el acento lo ponemos nosotros) siendo el más solvente significa remontarnos al estado del arte de la criptografía simétrica antes del año 1997. Después del DES, existen muchos algoritmos más robustos tanto en diseño como en longitud de clave, e.g. IDEA, AES. Si se desea hacer una afirmación en ese sentido en pleno siglo XXI, la elección obviamente es AES.
8. Sección Descripción, página 2, líneas 24 y 25:

Afirma:
"... DES consta de 256 claves, lo que significa que si se dispone de un ordenador capaz de realizar un millón de operaciones por segundo, se tardarían más de 2.200 años en probar todas las claves"
Aclaración:
Aunque los cálculos son correctos, es necesario recalcar que estos ataques a sistemas simétricos permiten un divide y vencerás en red, por lo que hablar en un documento científico como éste de un solo ordenador con capacidad de cálculo de un millón de claves por segundo, resulta como poco inapropiado. Ya en el DES Challenge III cuando se rompió la clave del DES en 1999 en menos de un día, la capacidad de cómputo en red y con la máquina DES Cracker alcanzó los 250 mil millones de claves por segundo, y estamos hablando de 13 años atrás.
9. Sección Descripción, página 5, líneas 10, 11 y 12:

Afirma:
"Además la conjunción de muchos ordenadores muy potentes puede romper claves asimétricas, consideradas largas, en poco tiempo"
Aclaración:
Se están mezclando conceptos de ataques a criptografía simétrica con la criptografía asimétrica. El trabajo de 'la conjunción de muchos ordenadores muy potentes' se entiende como un trabajo en red, una acción en paralelo. Si el autor conoce soluciones de ataques en red al problema de la factorización entera o del logaritmo discreto, debería nombrarlos. Por lo tanto, no se sabe qué ha querido afirmar aquí el autor, y menos aún dilucidar qué entiende por 'poco tiempo'.10. Sección Descripción, página 5, líneas 31 y 32 y página 6, líneas 1 y 2:
Afirma:
"Pues bien, todos los cifradores por bloques trabajan con cadenas fijas de n bits a las que se aplican alternativamente procesos de sustitución en las llamadas S-cajas (Sboxes) y de permutación en las P-cajas (P-boxes)"
Aclaración:
Esto no es cierto. No se puede generalizar las operaciones que se realizan en el algoritmo DES a todos los demás algoritmos simétricos; es más, no tienen nada que ver, e.g. IDEA no usa cajas y en AES no se llaman S-boxes.
11. Sección Descripción, página 7, línea 7:

Afirma:
"... mediante la operación or exclusivo byte a byte"
Aclaración:
Aunque está sacado de la referencia del libro de D. Manuel José Lucena, que cita, tal vez merecería la pena no dejar la sensación de que sólo existe ese tipo de cifra en flujo. Si bien es cierto que algunos algoritmos de flujo cifran byte a byte, otros algoritmos lo hacen bit a bit. De hecho, el principio básico de la cifra de flujo (Solomon Golomb) es la cifra bit a bit.
12. Sección Descripción, página 10, línea 1:

Afirma:
"... cuando conoce las claves que han sido utilizadas para codificarlo"
Aclaración:
Debería haber terminado la frase con la palabra 'cifrarlo' y no 'codificarlo'. Codificar es algo estático y siempre entrega el mismo valor (código ASCII, código Baudot, código Morse, etc.), en cambio cifrar es algo dinámico; en función de una u otra clave utilizada en la cifra, se obtiene uno u otro criptograma. Por esta misma razón no es adecuado usar en el título de esta solicitud de patente la frase “por codificación de la información” cuando en realidad lo que se quiere decir es “por cifrado de la información”.
En esa misma página 10 y en las línea 2 y 3, vuelve a insistir en que el único sistema de ataque a 'todos' los sistemas de cifra es la fuerza bruta.

No merece la pena profundizar en sus apreciaciones sobre lo que denomina “criptogramas seguros de Shannon”, algo inexistente, si bien existe el concepto de cifrado con secreto perfecto introducido por Shannon, pero son cosas distintas.

No haremos valoraciones sobre afirmaciones tales como que el sistema es inexpugnable 'incluso' (página 2, línea 33) para los ordenadores del futuro y otras afirmaciones que aparecen en el documento como usar la palabra 'pirata' (página 9, línea 33) como la persona que intercepta una comunicación porque sería entrar en el plano personal.

En resumidas cuentas, que no tiene interés seguir con esto. Creemos que queda claro lo que pretendemos decir; continuemos con la descripción del algoritmo para entender mejor las conclusiones de esta nota y las recomendaciones.

3. Comentarios sobre el algoritmo presentado

Si hemos entendido bien el algoritmo, lo cual no es sencillo a partir de la redacción, éste podría resumirse en lo siguiente:
1. Un residuo es un número del 1 al 9. Es posible combinarlo en grupos: 1 al 9, 11 al 99, 111 al 999, etc. 
2. Tenemos una matriz alfanumérica (básicamente representamos los caracteres ASCII en matriz). 
3. Tenemos una matriz base de residuos numéricos (representamos todos los residuos posibles en una matriz). Por ejemplo, si estamos trabajando con los residuos desde el 111 al 999 pues los ordenamos en una matriz. 
4. Se necesita una clave de equivalencia Es una clave formada por números naturales. Se agrupan en parejas e indican qué fila "conmutar" por otra "fila". 
5. Matriz base de residuos + clave equivalencia = matriz base de residuos ordenadas. Conmutamos la matriz en función de lo que nos indica la clave, dando lugar a una nueva matriz. 
6. Construimos una tabla de equivalencias.
a. Extraemos los valores de la matriz alfanumérica y los hacemos corresponder con uno o más valores de la matriz base de residuos ordenadas.
b. Única condición que no se repitan los valores,
7. Construir plantilla (criptograma reducido)
a. Ponemos el mensaje a cifrar en ASCII.
b. Seleccionamos uno de los posibles valores de la tabla de equivalencia para cada carácter ASCII a cifrar.
8. Necesitamos una clave de protocolo. Una secuencia de números naturales, cada número indica el número de dígitos en los que se convertirá cada "carácter ASCII cifrado (residuo)". 
9. Define un algoritmo “simple” para asignar valores a los dígitos indicados. No queda claro cómo es la generación de los números aleatorios indicados. Y... eso es todo. 
Emisor y receptor necesitan compartir:
1. Clave de protocolo.
2. Clave de equivalencias.
3. La matriz base de residuos (cómo ordenar los residuos en la matriz).En el ejemplo que pone para cifrar "la reunión es mañana jueves" (23 dígitos) el resultado es de 462 dígitos (20 veces más).

4. Opinión y conclusiones

1. Primer inconveniente del algoritmo.

El autor afirma que una de las bondades de este algoritmo es precisamente la "expansión" de los dígitos a cifrar, múltiples opciones entre las que elegir. Esto tiene un problema claro: el texto cifrado es mucho más grande que el texto en claro. Únicamente por esto se puede afirmar que este algoritmo no será de utilidad en la práctica. Un algoritmo de cifrado moderno no sólo debe ser seguro, sino que debe ser eficiente en múltiples aspectos. Los algoritmos modernos producen, típicamente, texto cifrados del mismo tamaño que el texto en claro (dejaremos aparte cuestiones de relleno). Un ejemplo es el actual estándar mundial AES, el cual tiene ciertas propiedades interesantes para su ejecución en terminales de bajo recursos, almacenamiento, etc.

2. Emisor y receptor necesitan compartir 3 claves.

Es necesario compartir por algún procedimiento 3 claves (o una que las componga) cuyo tamaño total es mayor que las claves criptográficas actuales para proporcionar una supuesta seguridad no probada. El proceso en el que interviene la clave es crítico en cualquier algoritmo simétrico moderno. La patente no deja claro cómo se debería elegir la clave con unas mínimas consideraciones de seguridad, es más, en el texto recomienda que incluso emisor y receptor podrían repetir la clave una y otra vez en el proceso, recordando a algoritmos clásicos rotos hace siglos. Cómo interviene la clave en el cifrado o cómo se selecciona no es baladí. Muchos de los algoritmos simétricos utilizan generadores de subclaves basados en una clave principal que van proporcionando bits de clave según una serie de condiciones muy estudiadas. La seguridad de estos generadores es crítica para la seguridad global del algoritmo.

3. La descripción del algoritmo es oscuro y "variable".

Los algoritmos "serios" describen una serie de pasos a realizar de manera impermutable. La descripción de este algoritmo deja abierta la selección de multitud de cuestiones al emisor y receptor; esto puede introducir problemas.

4. Cualquier algoritmo criptográfico que se precie debe resistir un ataque con texto en claro conocido

Esto es algo básico y no lo vemos reflejado en el documento. Sin estas pruebas elementales, ningún algoritmo puede darse por bueno.

5. El algoritmo tiene pinta de mezcla de procedimientos básicos de criptografía clásica.

En ocasiones, recuerda a cifradores por homófonos, en otros casos a cifradores basados en matrices y transposiciones de sus elementos. En cualquier caso, no queda claro que los procedimientos establezcan procesos no lineales en los que basar una seguridad real. Hablando de sistemas de cifra lineales con espacios de claves muy grandes (que parece ser el fuerte de este sistema), más grandes incluso que los actuales cifradores modernos que son no lineales, hay que ser muy cautos; e.g. si en el algoritmo de matrices de Hill se usa una simple matriz de 8x8 y un cuerpo de cifra de todos los caracteres ASCII imprimibles, se obtiene un espacio de claves válidas exorbitante ... pero el sistema se rompe con una simple matriz de Gauss-Jordan y tres o cuatro palabras del texto en claro y su correspondiente texto cifrado.

6. Si se desea probar la seguridad del sistema es bien sencillo, hay dos opciones no excluyentes. 

La primera es publicar sus resultados en cualquiera de los congresos o conferencias científicas de renombre en criptografía, tanto en España como en otros países, y someter sus resultados a investigaciones independientes. Una segunda, y aconsejable, liberar una herramienta concreta que implemente su algoritmo y ser sometido al escrutinio de la comunidad científica e internautas. Si se incentiva a la comunidad de alguna manera para atacar su sistema, tanto mejor.

Ante todo lo anterior no sólo podemos afirmar que este algoritmo ni mucho menos va a desplazar a los algoritmos actuales, sino que no le auguramos ningún futuro. Sería conveniente, especialmente para los profesionales del periodismo que difunden este tipo de noticias en grandes medios, recordar que en España disponemos de excelentes profesionales, tanto expertos en seguridad informática como criptólogos; a la mayoría de ellos se les podría consultar antes de publicar noticias sensacionalista como las que nos ocupa. Atentamente,

Dr. Jorge Ramió

Profesor Titular de la Universidad Politécnica de Madrid. Desde el año 1994 imparte diversas asignaturas relacionadas con la seguridad y criptografía. Entre sus facetas destaca su interés por la difusión de la seguridad informática en Iberoamérica. Autor del libro electrónico de Seguridad Informática y Criptografía en 2006, de libre distribución en Internet y con más de 120.000 descargas, creador en 1999 de la Red Temática de Criptografía y Seguridad de la Información Criptored, organización de los congresos iberoamericanos CIBSI y TIBETS, creador y director de la cátedra UPM Applus+ de seguridad, creación y dirección de la Enciclopedia de la Seguridad de la Información Intypedia y del primer MOOC en español sobre seguridad de la información Crypt4you, participación como profesor invitado en cursos de posgrado en España y países de Latinoamérica.

Dr. Alfonso Muñoz

Doctor de Telecomunicaciones por la Universidad Politécnica de Madrid e investigador postdoctoral en Computer Security & Advanced Switching Network en la Universidad Carlos III de Madrid. Especialista en protección de datos digitales y diseño de sistemas seguros (criptografía, esteganografía, dpi, etc.). Ha publicado más de 20 artículos en revistas y congresos científicos de alto impacto (revisión ciega por pares) en el campo de la seguridad informática, y ha trabajado en proyectos con organismos europeos, ministerios y multinacionales. Su trabajo de investigador lo combina con su faceta de divulgación. Algún ejemplo destacable es la creación y dirección técnica de Intypedia, creación del primer MOOC en español sobre seguridad de la información Crypt4you, artículos de divulgación en revistas o blogs del sector o la participación en conferencias de seguridad informática y hacking