Arxiu de la categoria: Seguridad

Cómo ganar siempre al “Apalabrados” (para Hackers)

Confieso que no he entrado en el tema “Apalabrados”, pero conozco a mucho enfermo del tema. Este artículo, extraido íntegramente de Security by Default, no pretende que hagáis trampas, o no siempre, ni va de las famosas aplicaciones para que os lo den hecho. En realidad va de ver las tripas de como funciona el juego y cómo hackearlo, o sea que aquí os lo dejo por si quereis experimentar…

Esto es lo que nos cuentan desde Security by Default:

Apalabrados, o “Angry Words”, el juego de moda. Muchos lo hemos descubierto como un desafío más. Algo a lo que se puede jugar con cualquiera y que consiste en exprimirse el cráneo pensando, con las letras que tienes, cómo completar palabras en un tablero. El concepto ya existía con el Scrabble de toda la vida, pero en este caso jugando de forma online contra amigos/conocidos o incluso contra personas seleccionadas de forma aleatoria.
Así que empecé a jugar y ví como ganaba algunas partidas, pero perdía otras. Y he de reconocer que no me gusta mucho perder ;DCon el tiempo, incluso aparecieron aplicaciones online o servicios que te “ayudaban” con la generación de palabras, en base a las letras que dispones, y las ya colocadas en el tablero, para que efectúes la mejor de las jugadas. Pese a que nunca llegué a hacer uso de estas aplicaciones, pensé en echar un vistazo a las tripas del juego, por aquello de ver cómo funciona y buscar alguna otra debilidad que me permitiese hacer esto de las palabras cruzadas algo más divertido.

Para ello, y como se jugaba desde un dispositivo móvil, monté una herramienta de intercepción de tráfico, que me permitiese analizar los mensajes intercambiados entre la aplicación, y el servidor correspondiente. Una vez identifiqué que las peticiones eran simples llamadas a una API web, dispuse el conocido proxy Paros para poder estudiar las mismas.
Os cuento mis findings principales:
  • El servidor hacia el que realiza las peticiones el juego es api.apalabrados.com y se encuentra en Amazon EC2, aunque tiene configurado el timezone de Argentina, tal cual denotan la hora de algunas respuestas del servidor. Tiene cierta lógica, puesto que la empresa desarrolladora de Apalabrados, es de las latitudes de la tierra del exquisito dulce de leche.
  • El proceso de login se puede hacer a través de usuario facebook (dando privilegios a la aplicación para el login) o mediante correo electrónico y contraseña. No he probado a fuzzear el acceso mediante correo electrónico con contraseñas, para ver si existe bloqueo de cuentas al hacer ataques de diccionario o fuerza bruta, pero CAPTCHA, no hay. Por mi parte, y aunque me he centrado en intentar trampear el juego con sesiones ya iniciadas, podemos ver que la contraseña de login viaja completamente en claro en una petición POST.

 

  • El protocolo utilizado es HTTP en plano, sin SSL, sin nada de nada. Meras peticiones web, sin autenticación con certificados de por medio que pongan la cosa un poco más complicada (saltable, pero con algo más de dedicación y esfuerzo). Impresionante que ni siquiera el login en la aplicación tenga un nivel mínimo de cifrado.
  • Al tratarse de un juego al que se puede acceder desde diferentes dispositivos a la vez de forma simultánea, lógicamente, las partidas y el estado del usuario ha de almacenarse en los servidores de Apalabrados, siendo los clientes, quienes piden información en cada ocasión. Analizando el tráfico web intercambiado, se ve que, en el login, se establece una sesión web corriente y moliente, el servidor nos inyecta una cookie con un sessionID (ap_session) que los clientes tendrán que utilizar en todas las peticiones que hagan hacia el servidor.

 

  • Si situamos a un cliente en una situación MiTM sencillo, forzando a jugar a los usuarios mediante una red wireless, podemos interceptar el identificador de usuario enviado en todas las peticiones GET y POST, y la cookie de sesión necesaria, así podríamos hacer peticiones del tipo: GET http://api.apalabrados.com/api/users/[mi_usuario_ID]/games con la cookie “ap_session” con el valor interceptado y obtendríamos la lista completa de los juegos de un usuario, con un montón de información de cada uno, el usuario contra el que se juega, su identificador Facebook (si se conectó haciendo login en facebook en vez de con correo electrónico), si ha de mostrar o no foto, la fecha de creación del juego, los turnos pasados, el número de fichas que quedan, la última palabra jugada, etc,…
  • Si pulsamos en cada uno de los juegos disponibles, podemos ver que se hace una petición al servidor para rellenar el mismo. La petición es del tipo: GET http://api.apalabrados.com/api/users/[mi_usuario_ID]/games/ Como bien podéis imaginar, con la cookie de sesión, podemos ver directamente la configuración de juego del usuario interceptado, y por supuesto, podemos actuar, como si fuera él.
  • Cuando se crea una palabra, con nuestras letras y las del tablero, el cliente envía una primera petición GET a http://api.apalabrados.com/api/dictionaries/ES?words=palabra. Así comprueba en su diccionario (depende del idioma) si la palabra existe o no. La respuesta es del tipo {“answer”:true,”wrong”:[],”ok”:[“palabra“]} si es válida; o del tipo {“answer”:false,”wrong”:[“palabra“],”ok”:[]} cuando es incorrecta.
  • Es posible manipular las peticiones y las respuestas entre el cliente y el servidor, de manera que le llegue al cliente lo que nosotros queramos, y que lógicamente, la aplicación ejecutará sin comprobar nada más. Es decir, que podemos modificar la respuesta del servidor diccionario, para que devuelva por válida cualquier palabra que le pongamos, sin problemas, pero los desarrolladores han tenido en cuenta estas trampitas, y hacen que, cuando confirmas posición de las letras, se comprueben, de nuevo, en el diccionario internamente y claro, dará un error por no existir la palabra. De momento, no he encontrado forma de engañar al servidor para que acepte palabras que no existen.
  • En la siguiente imagen podéis ver que se puede enviar al usuario el texto en las posiciones que queramos, cuando simplemente el cliente pregunte por un juego en concreto. No es necesario ni modificar el ID de la respuesta para que coincida con el que el cliente espera. Directamente, se le envía cualquier cosa y se la come,… incluso es posible enviarnos las letras que nos convengan para la siguiente jugada.

 

Teniendo en cuenta que es una matriz de 15×15, la posición de cada letra viene dado por la posición de la 0 a 224. Así que si queremos, podemos devolver el mapa de caracteres que queramos (ni siquiera han de ser sólo letras) y/o cuantos comodines nos venga en gana.
 
  • El problema está en que, como las partidas quedan grabadas en el servidor, cada vez que la aplicación cliente pida el estado de la partida, deberemos modificar el cuerpo de la respuesta que queramos. En otro caso, machacará en la aplicación cliente toda la creatividad que hayamos creado anteriormente y se verá la partida real.
  • Entonces, ya que el servidor no permite modificaciones de las letras disponibles, del número de fichas o que se coma aquellas palabras que yo quiera, está claro: si no puedo engañar al servidor ,engañemos a los clientes!  Aquí ya viene la parte maliciosa. En Apalabrados, la API permite preguntarle al servidor por la situación de algún juego (o de todos) mediante GET, y también ejecutar un comando, mediante POST, pasando en el POST DATA la acción. Las más agresivas son “Paso” o “Rendirse”, de manera que enviaríamos al servidor, falseando al cliente, en nuestro entorno MiTM una petición POST a  http://api.apalabrados.com/api/users/[mi_usuario_ID]/games/[juego_ID]/turns con el POST DATA el valor {“type”:”PASS”}, y estaremos simulando que el cliente ha pasado. Si hacemos esto por cada vez que sea el turno del usuario, a éste podemos devolverle un error cualquiera de conexión al servidor, mientras vamos jugando alegremente una partida en la que la víctima siempre pasará, perdiendo la partida por goleada.
  • Otra opción más agresiva aún es forzar a un usuario a Rendirse a una partida. ¿Cómo? pues enviando la petición POST a http://api.apalabrados.com/api/users/[usuario_ID]/games/[juego_ID]/turns el valor {“type”:”RESIGN”} en el cuerpo del POST. Con esto al servidor le llega, la petición fraudulenta de Rendirse, por lo que forzaremos que esa partida se pierda y se deprecie el valor del usuario en su perfil, por partidas renunciadas. Por contra, si estamos jugando contra la víctima, ganaremos automáticamente la partida, porque el contrario renunció.
  • Otra forma de forzar a un usuario a perder la partida es no devolver ninguna letra a nuestro contrincante,… Para ello, la devolución de letras en el caso de una jugada sería del tipo
    {“type”:”NORMAL”,”turns_played”:44,”replacement_tiles”:””,”my_score”:221,”opponent_score”:199,”game_status”:”ACTIVE”,”expiration_date”:”07/08/2012 08:51:21 EDT”,”id”:85302734} es decir, sin “letras de recambio”. En este caso, directamente es un Game Over para la víctima, puesto que no tiene ninguna letra para jugar y sólo le quedarán las opciones de darle al botón “Pasar” o “Rendirse”.
  • En estos tres últimos casos, estamos causando un perjuicio a un jugador, en nuestro beneficio. Sin embargo, también podemos enviarle lo que queramos a la víctima, o a nosotros mismos. Desde un “Has Ganado” o un “Has perdido”, aunque sea ficticio puesto que el servidor conoce el estado real de la partida. Pero, en cualquier caso, siempre es divertido enviarle mensajes malformados a un usuario para ver su reacción….

 

Y por supuesto podemos escribir lo que queramos en los puntos, el nombre del adversario, o incluso el mapa de letras que queramos que queden reflejados… Quise probar cuánto era el mayor puntaje que podía obtenerse en Apalabrados, así que probé rellenando con todo Z (valen 10 puntos) todo el tablero… Al forzar un WIN, el programa se pasa de largo sumando y calculando las triple/doble letra/palabra y da un resultado de 248, que obviamente es un resultado incorrecto,…
 
  • El apartado de ver perfiles de los usuarios (incluso del propio) también es susceptible de modificaciones, pudiendo modificar cualquier campo, poniéndonos los puntos que queramos en mejor juego, mejor jugada, palabra más larga, o incluso el número de partidas ganadas, perdidas o renunciadas, apareciendo el palmarés que queramos. Evidentemente, esto es sólo a ojos del cliente, porque en el servidor no se modifican estos stats

 

Estuve probando por si, por debajo, la aplicación llamase a Safari y fuese posible generar un XSS… pero no hubo suerte con la única prueba que hice.

Bueno, pero… ¿y cómo lo pueden arreglar?
El problema fundamental de Apalabrados, es que no han tenido en cuenta ningún tipo de checksum, o lo que sería aún mejor, una firma digital del hash de cada mensaje recibido. Las manipulaciones o tampering de los datos enviados por el servidor a los clientes, deberían ser comprobadas por el mismo, de manera que, si alguien ha dado rienda suelta a su creatividad por el camino, debería dar un error de integridad y no interpretar el contenido del mensaje.
Respecto al envío de mensajes por parte del cliente hacia el servidor, tanto con las jugadas con letras que se envían, como con los mensajes de “Rendirse” o “Pasar”, deberían ir cifrados, por ejemplo, con una contraseña de sesión. Otra opción, sería hacerlo con un hash de la contraseña del usuario que se mantenga en el cliente y que al estar ya almacenada en el servidor, pudiese dar la capa de confidencialidad necesaria a los mensajes. La opción optima sería firmar digitalmente todos los mensajes, pero eso implicaría un despliegue de certificados por cada usuario, que posiblemente hiciera inviable el juego.Ni siquiera se han preocupado que, cuando el login se hace mediante usuario-correo/contraseña, el envío de la misma se efectúe mediante un canal SSL, sino que la contraseña viaja en claro para que cualquiera, en determinadas condiciones, pueda acceder a ella cómodamente. Como recomendación, no uséis la misma contraseña que utilizáis para otras cosas, y por supuesto, ya que el nombre de usuario es una dirección de correo, haced el favor que la contraseña no sea la del servicio de correo!

La única “medida de seguridad” implementada (que yo creo que ha sido por casualidad) es el escaso tiempo de time-out, que obliga a hacer la manipulación de los parámetros en tiempo récord, o tener hecho el mensaje antes, para inyectarlo en la respuesta cuanto antes. La otra opción es diseñar un programa que cuando detecte las peticiones, formatee las respuestas según nuestras necesidades de forma automática.
Pensé en buscar un BOFen la devolución de alguno de los parámetros, ya que, como habéis podido comprobar, es posible modificarlos todos a nuestro gusto. Así que a base de pruebas, quizá sea posible ejecutar código remoto en el dispositivo de la víctima. Mi intención eran los fines académicos y lúdicos para conseguir la victoria en el juego, no en el dispositivo completo.Cierto es, que en el lado servidor, han tenido en cuenta “alguna” medida de seguridad, como la doble comprobación de que la palabra existe. Sin embargo, no han controlado todas las posibles reacciones de un usuario con un pelín de mala uva.

Recordad además que esto sólo es posible en aquellas situaciones en las que se utilice una red wireless para la comunicación de datos y sea posible el MiTM. En caso de jugar con 3G no habría forma de efectuar estas manipulaciones, y en caso de GPRS, hay que mirar que los @Taddong no estén cerca.
Noticia extraida de: Security by Default

No le toquéis los huevos a un informático!

Post que he encontrado en Hermano temblón y que pongo aquí tal cual porque no se puede explicar mejor.

no-tocar-los-huevos

Queridos amigos. Hoy os voy a dar un buen consejo:

Nunca le toquéis los huevos a un informático (sobre todo si este es de redes y sistemas).

A lo largo de estos ocho años trabajando por mi cuenta he conocido todo tipo de empresarios:

Algunos buenas personas, algunos serios, algunos completamente chiflados, algunos un poco hijos de putas… y los menos:

Los auténticos hijos de puta

Y no, no hablo de esos empresarios que realmente está arruinados y no te pueden pagar, o de esos “vaciletas” que quieren hacerte ver que eres su puto esclavo y no su proveedor, o esos otros que te quieren engañar de forma picara e incluso patéticamente graciosa…

Hablo de esos hijos de puta que no solo se ríen de ti, si no que además, te desprecian, te engañan y se pasean por Madrid con sus coches de gran cilindrada mientras te dicen a la cara que no te van a pagar.

Hablo de esos sinvergüenzas que te amenazan cada vez que les llamas para cobrarles una factura varios meses atrasada y que los fines de semana los ves como se fuman un puro en la puerta del Restaurante Chistu antes de pegarse la gran comilona e irse de putas.

A esos clientes yo les diría:

La persona a la que menos deberías tocarle los huevos es al informático al que has contratado…

¿Y por que? (se preguntará usted querido lector). Pues por muchos motivos, como por ejemplo estos:

1- El informático tiene acceso a toda tu contabilidad y todos tus emails.

Efectivamente…Tu contabilidad podría aparecer en Internet o manos de algún inspector de hacienda.

También podría ser que tu mujer recibiera una copia de esos correos electrónicos que escribes a tu querida o a tus “colegas” comentándoles las jugadas que has hecho en la última noche de farra en el puti-club.

2- El informático sabe todo el software pirata que hay en tu empresa.

Pues si, efectivamente este listado de software pirata podría aparecer mañana en un correo a la BSA y encontrarte con una inspección.

3- El informático sabe que tus trabajadores están sin contrato:

Seguro que a la Seguridad Social esto le iba a encantar

4- Tus bases de datos con presupuestos, precios y clientes podrían aparecer en manos de la competencia.

5- Es posible que tus servidores y tus equipos de sobremesa no arranquen jamás.

Cosas raras que pasan ¿no?

6- Es posible que cuando intentes restaurar tu última copia de seguridad te encuentres que la misma contiene una película con primeros planos de Rocco Sifredi.

7- En la red de tu empresa podrían aparecer tantos virus como para hacer que la OMS la declare “zona catastrófica”.

8- La web de tu empresa podría aparecer con una bonito video en primer plano llamado “Two girls, one cup”

9- Tu servidor podría convertirse en un FTP anónimo donde cualquier bicho de los que pululan por Internet te dejase recuerdos de sus aficiones y pasatiempos.

10- Con la misma, tu servidor podría albergar 10.000 ficheros MP3:

A la SGAE esto le va a encantar.

11- Y así se me ocurren un millón de “cositas” más que un informático te podría hacer.

Si este informático además tiene los conocimientos para conectarse a tu red desde una Wifi pirateada con un programa como Air-Crack:  sabe borrar convenientemente su huellas, y salta entre varios Router ADSL abiertos…

Pues ya ni te cuento!!!!!!

Así que amigos ya sabéis:

Pensároslo mucho antes de tocarle los huevos a un informático.

Vía: Hermano temblón

Nuevos controles de tráfico

Esta foto no necesita palabras, es un falso control de policía hecho de cartón. La verdad es que puede ser efectivo, siempre y cuando lo vayan cambiando de sitio.

La filosofía no encaja mucho con la idea que tiene tráfico en nuestro país (y sobretodo en Cataluña) donde el objetivo de todos los radares y controles no es que no corras para que no haya accidentes, si no recaudar pasta, por lo que no creo que los Mossos de Escuadra adopten este sistema.

Además esta foto me ha recordado una de las tácticas de Sadam Hussein en la 1ª Guerra del Golfo, que usaba tanques inflables para fingir que tenia mas recursos de los que en realidad tenía.

O sea que a veces el cartón piedra funciona… y es mas barato!!!

Falsos antivirus

Desde hace tiempo, al navegar podemos encontrarnos algunos supuestos programas antivirus o antispyware y demás que en realidad son un virus ellos mismos.

A veces nos saldrá un aviso de que nuestro sistema está infectado y nos proponen una supuesta solución.

En esta página encontrareis información sobre todos ellos: PC Threat.com

Antivirus

Hay unos consejos básicos que conviene seguir:

– Confiar en programas antivirus y otros de seguridad con una larga y contrastada trayectoria. Para usuarios domésticos, sino quereis pagar y no quereis delinquir o arriesgaros con cracks y demás, habeis de saber que hay muchos productos buenísimos (incluso mejor que los de pago) totalmente gratuitos para usuarios domésticos, como puede ser Avast Antivirus u otros.

– Consultar a San Google. Visitar foros y páginas especilaizadas antes de instalar productos que desconozcais, sobretodo si os los ofrecen.

En PC Threat os informan de todos estos programas falsos y perjudiciales: PC Threat.com

Ah! Y os recuerdo que to esto es para Windows, el mejor antivirus que podeis encontrar se llama Linux (GNU/Linux) !!!!!!!!!!!

Grave problema de seguridad en los DNS

Al parecer el problema es muy serio y permitiría a un atacante redirigir cualquier sitio web. El problema fué detectado de forma accidental por Dan Kaminski, de IOActive. Kaminski al descubrirlo advirtió del problema e inmediatamente las grandes empresas de internet (Microsoft, Sun Microsystems y Cisco) se pusieron a buscar una solución de forma discreta, para no poner sobre aviso a posibles crackers. Ahra ya se están distribuendo actualizaciones de software automáticas que corrigen el problema. Kaminski ha creado una web www.doxpara.com para permitir a los usuarios poner a prueba su vulnerabilidad frente a esta amenaza.

Hemos de agradecerle a Dan Kaminski que en lugar de hacerse el bussiness ha actuado de la mejor manera posible por el bien de toda la comunidad.

Thanks, Dan!

Dan Kaminski

Este es su Twitter

Noticia completa: El Mundo.es

Nueva interfaz gráfica para ufw: Gufw

En la última versión de Ubuntu 8.04 se incluyó ufw (Uncomplicated FireWall), una utilidad para gestionar las reglas de iptables, el firewall Linux, mediante la línea de comandos.

Ahora existe Gufw, una interfaz gráfica que nos permite gestionar ufw con unos pocos clics, crear reglas de acceso, impedir ping, …

php6vTT9G

Pueden descargarlo desde aquí.

Vía: Blog de Marcelo Ramos

Vulnerabilidad de claves SSH en sistemas Debian

Como muchos sabreis, hace poco se ha descubierto un bug en las claves SSH de tipo DSA que afecta a Debian y a los sistemas basados en el (como Ubuntu). Es un problema muy serio, ya que afecta a particulares, pero sobretodo la gravedad está en los servidores, ya que hay muchos de tipo Debian.

Debian es una distribución desarrollada totalmente por un equipo de voluntarios y el apoyo del resto de la comunidad. Siempre ha sido considerada muy estable y por ello ideal para servidores. A raiz de este problema, se ha abierto un debate sobre las distribuciones voluntarias, sobre la seguridad del software privativo, etc.

Para comprender mejor el problema aquí os dejo una entrevista difundida por VSantivirus de Mercè Molist a Jordi Mallach Pérez, desarrollador de Debian, sobre el “bug”.

MM: ¿A quién afecta esto?

JMP:  El impacto es enorme. La biblioteca libssl de Debian y sus distribuciones derivadas ha estado generando material criptográfico débil durante casi dos años. En Debian la mayoría de la gente ha estado afectada desde el lanzamiento de la última versión, etch, hace un año, pero los usuarios de Ubuntu han estado expuestos al error durante tres versiones.
Debian es bastante popular en ambientes universitarios y entre muchos administradores de sistemas, y Ubuntu es el líder en los usuarios domésticos, con lo que estamos hablando de millones de ordenadores afectados. Ahora bien, es difícil de estimar cifras concretas porque nadie sabe, ni puede saber a ciencia cierta cuantas instalaciones de Debian o Ubuntu hay en el mundo; existe una opción en ambas distribuciones, desactivada por defecto, que permite saber de la existencia de esa instalación y la versión de sus paquetes instalados, pero el porcentaje de usuarios que la han activado es ínfima.
Lo más grave es que no sólo los usuarios de Debian deben estar intranquilos. Todos los administradores de servidores con SSH o certificados SSL, sean o no basados en Debian, deberían hacer una comprobación exhaustiva de todos sus certificados SSL y claves SSH en busca de claves vulnerables, porque pueden tener autorizadas claves públicas débiles, que podrían permitir entradas a sus servidores.

Por ejemplo, por la manera que se usan las claves SSH de tipo DSA, no es exagerado decir que *todas* las claves DSA, tanto las generadas en máquinas vulnerables o en máquinas “seguras” deberían considerarse comprometidas y no usarse más. Algunos administradores están recomendando desactivar el soporte para claves DSA y usar sólo RSA a partir de ahora. Y eso no significa que las claves RSA sean  seguras. No lo son, si se han generado en sistemas con una libbssl débil.
MM: ¿Qué significa para las empresas? ¿A qué peligros las expone?

JMP:  Básicamente deberán estudiar el uso que hacen de la criptografía en sus sistemas, entender hasta dónde hay riesgos incluso si no usan Debian o Ubuntu e invertir el tiempo necesario en asegurarse de que no están autorizando ninguna entrada insegura en el sistema. De no hacerlo, es más que probable que si tienen servidores afectados accesibles desde Internet, estos acaben infectados por gusanos diseñados
para aprovechar esta vulnerabilidad.
MM: ¿Y para el resto de usuarios?

JMP:  Exactamente lo mismo, pero a nivel más local y reducido. Si no toman medidas, en unos meses su ordenador puede convertirse en un “zombi”. O un usuario podría conectar a un servidor web supuestamente seguro que use un certificado generado por una versión afectada de OpenSSL. Sería posible descifrar datos sensibles ya que la parte privada del certificado usado para el cifrado es conocida.

MM: ¿Se va a solucionar pronto?

JMP:  No, este problema va a persistir durante años, porque no basta con actualizar los servidores y aplicar los parches.
También hay que, manualmente, comprobar los certificados del sistema y las claves de SSH de los usuarios para asegurarse de que el sistema no está autorizando entradas con claves débiles. Lamentablemente habrá servidores con esta debilidad en la red durante años, que a buen seguro acabarán siendo controlados por alguna “botnet”.

MM: ¿Demuestra eso que no hay que fiarse del software desarrollado por voluntarios?

JMP:  Yo no lo creo. Sí debe servir para que la gente se tome el argumento de “código abierto = código auditado” con un poco más de perspectiva: la realidad es que aunque el código está disponible para ser revisado, hay muy poca gente dedicada a auditarlo para encontrar posibles vulnerabilidades. En este caso, Luciano Bello lo encontró por casualidad dos años después de pasar inadvertido por todos los controles.
Con el software privativo, no podemos saber si hay errores de este tipo esperando a ser explotado porque no podemos comprobarlo como ha pasado en este caso, ni ahora ni dentro de dos años. Por otro lado, también se puede analizar la respuesta de Debian, Ubuntu y la comunidad del software libre frente a este problema. Pese a ser un error mayúsculo, que seguramente dañará la credibilidad y reputación de Debian, creo que la respuesta y el trato que se le ha dado a la situación ha sido totalmente profesional. Desde el primer momento, se ha informado transparentemente de la magnitud del problema y se ha ofrecido toda la información y herramientas para ayudar a los usuarios y administradores a identificar y reemplazar el material criptográfico vulnerable.

MM: Si eso hubiese sucedido en Microsoft, habría cabezas cortadas.

JMP:  Debian es un proyecto voluntario y evidentemente no va a haber “despidos” ni “expulsiones”. En muchos medios “on-line”, se está haciendo ver que todo el problema viene porque un “novato” tocó un par de líneas de código que no entendía realmente, generando así una especie de apocalipsis criptográfica. No es tan sencillo; el autor del cambio trató de informarse de la idoneidad y consecuencias del cambio
preguntando a los autores de OpenSSL, recibiendo, debido a un cúmulo de malentendidos, una respuesta positiva. Aunque la responsabilidad final es claramente de Debian, los autores de OpenSSL también han aprendido algunas lecciones y seguramente serán más cuidadosos a la hora de informar correctamente de
cómo se puede contactar con ellos para este tipo de consultas, y comentarán los trozos de código tan crítico como este para que quien lo revise sea consciente de lo que supone cambiar una línea.
Dentro del proyecto se es muy consciente de la gravedad del asunto, y a la vez que se tomaban las medidas necesarias para publicar información útil sobre la vulnerabilidad, y se parcheaban y reemplazaban las claves de los servidores internos, la comunidad de desarrolladores ya discutía en los blogs y las listas de correo qué hacer para intentar evitar situaciones como esta en el futuro. Además, esta no es el tipo de piedra en el que se tropieza dos veces. Está claro que las personas que mantienen código de seguridad, criptográfico, etc. irán con pies de plomo y serán mucho más explícitos a la hora de pedir opinión a los autores originales, para que no haya malentendidos como en esta ocasión.

MM: El artículo no podrá ser muy largo, así que tendré que resumir bastante lo que me cuentas. Si te parece bien, cuando haya salido publicado, publicaré yo por mi cuenta la entrevista entera.

JMP:  He sido “verbose” porque quería explicar muchas cosas, y porque no me han gustado nada algunos calificativos de este incidente por parte de algunos medios (chapuza, ñapa, etc), y por eso quería darte un escrito suficientemente claro sobre este tema. Lo que defiendo es que la cagada por parte de Debian es mayúscula, pero no es fruto de que alguien ha tocado algo que no sabe, ni que Debian va por libre y la caga
y tal. Que hay también muchas cosas a corregir en OpenSSL, y que esto puede pasar otras veces en otras distribuciones.


Jordi Mallach Pérez — Debian developer
http://www.debian.org/

http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

* Más información:

Un grave fallo en Debian pone en peligro millones de máquinas
http://ww2.grn.es/merce/2008/debian.html

* Relacionados:

Grave problema en Linux afecta la seguridad de Internet
http://www.vsantivirus.com/16-05-08.htm

(*) Copyright 2008 Mercè Molist.
Verbatim copying, translation and distribution of this entire
article is permitted in any digital and no commercial medium,
provide this notice is preserved.

(c) Video Soft – http://www.videosoft.net.uy
(c) VSAntivirus – http://www.vsantivirus.com