¿Qué es y cómo funciona el nuevo registro DNS CAA?

En Enero de 2013, Rob Stradling propuso y formalizó la implementación de un estándar para la Autorización de Entidades de Certificación (Certification Authority Authorization, por sus siglas en inglés) mediante el RFC 6844. El propósito de los registros CAA es “designar” una o más entidades de certificación a emitir certificados SSL/TLS a un dominio o subdominio específicos. Los dueños de dominios podrán, además, declarar una dirección de correo electrónico para recibir notificaciones en caso que alguien solicite un certificado a una entidad de certificación no autorizada. De no existir un registro CAA, cualquier entidad está autorizada a emitir certificados para ese dominio o subdominio. Si bien … Seguir leyendo…

OpenSSL recibe una importante actualización de seguridad

Los responsables del proyecto OpenSSL, paquete de herramientas de administración y bibliotecas que suministran funciones criptográficas a otros paquetes como OpenSSH, y pieza fundamental de las implementaciones de protocolos de transferencia seguro (como SSL o TLS), han publicado hace pocas horas una serie de actualizaciones de seguridad, incluyendo algunas de caracter crítico. Las versiones 1.0.1, 1.0.0 y 0.9.8 de OpenSSL deben ser actualizadas inmediatamente a 1.0.1k, 1.0.0p y 0.9.8zd respectivamente. Por su parte, la versión 1.0.2 debe ser actualizada a la 1.0.2a. Entre las actualizaciones se soluciona una vulnerabilidad que podría permitir que atacantes intercepten comunicaciones seguras (“man-in-the-middle attack”) y otra que podría permitir ataques de denegación de servicio (DDos). Se recomienda a todos … Seguir leyendo…

Google Play se transforma para ofrecer más seguridad

Asi lo asegura Eunice Kim, Product Manager de Google Play en un artículo publicado en el blog oficial de la tienda de aplicaciones de Android. Los cambios incluyen un sistema de clasificación de contenido y un proceso de revisión de aplicaciones. Sistema de clasificación de contenido Este nuevo sistema permitirá a Google cumplir con las reglamentaciones vigentes en cada país respecto del contenido de sus aplicaciones y juegos y ofrecer a los desarrolladores la posibilidad de llegar al mejor público, asi como a los usuarios de encontrar el contenido más relevante. Google, aseguran en el artículo, comprende que cada país y cada cultura entienden de … Seguir leyendo…

GHOST, la primer gran vulnerabilidad del 2015

Qualys, firma internacional de seguridad informática, publicó hace algunas horas los detalles acerca de una antigua vulnerabilidad conocida como GHOST y registrada en la base de CVE (Vulnerabilidad y exposiciones comunes, por sus siglas en inglés) bajo el número 2015-0235. GHOST, quien recibe su nombre del método GetHostByName, fue introducido originalmente en la librería glibc-2.2 que data de noviembre del año 2000 y corregido en mayo de 2013 (en las librerías glibc-2.17 y glibc-2.18). Sin embargo no fue tratado como una brecha de serguridad, por lo que un gran porcentaje de las distribuciones de Linux alrededor del mundo continúan afectadas … Seguir leyendo…

Todo lo que necesitas saber acerca de POODLE

Hace algunos días fue confirmada una vulnerabilidad de la que se habían oído rumores tiempo atrás. Se trata de POODLE (Padding Oracle On Downgraded Legacy Encryption, por sus siglas en inglés), un fallo en el protocolo SSL 3.0 que podría permitir ataques del tipo MitM (Man in the Middle) en los que un atacante podría leer y modificar la información intercambiada entre dos equipos sin generar ninguna sospecha.

El fallo, registrado bajo el identificador CVE-2014-3566, fue descubierto por Bodo Möller, Thai Duong and Krzysztof Kotowicz del equipo de Seguridad de Google y publicado en el blog de la compañía.

Si bien la vulnerabilidad no es tan seria como sí lo fueron Heartbleed o Shellshock, debe ser tenida en cuenta y mitigada por los administradores de sistemas. SSL 3.0 ya cumplió 18 años, pero aún es utilizado por los navegadores para “escapar” de algunos errores que impedirían el correcto uso de protocolos más recientes. De esta manera, un atacante podría forzar el uso de SSL 3.0 para explotar sus deficiencias.

Usuarios hogareños

Para el caso de los usuarios hogareños u organizaciones que quieran proteger a sus usuarios de esta vulnerabilidad y evitar que un atacante intercepte la información intercambiada con un servidor que aún no ha mitigado el fallo, alcanza con deshabilitar el protocolo SSL 3.0 en los navegadores de internet.

Seguir leyendo…

Llegó la hora de reemplazar los certificados SSL con cifrado SHA-1

Han pasado casi 20 años (19 para ser precisos) desde que se publicara la versión 1 de SHA, el algoritmo de cifrado más utilizado en el mundo y con el que operan la gran parte de los certificados SSL de la web.

SHA-1 es un método de cifrado desarrollado por la Agencia Nacional de Seguridad de los Estados Unidos (NSA, por sus siglas en inglés) y es considerado un estándar federal en el procesamiento de la información para el gobierno de aquel país. El método de salida de SHA-1 produce un valor de hash seguro de 160 bits (20 bytes), equivalente a un número hexadecimal de 40 dígitos de longitud.

En el año 2005 fueron publicadas dos investigaciones en las que se demostraron grandes debilidades en este mecanismo. Sucede que los hashes tienen un enemigo natural llamado “colisiones”. Las colisiones son la posibilidad de encontrar mediante ataques de fuerza bruta un identificador que no sea único, es decir, que un mismo SHA-1 represente a dos flujos de datos entrantes diferentes.

Por definición podríamos decir que existe 1 posibilidad en 1208925819614629174706176 (280) de generar colisiones en SHA-1. Sin embargo, a principios de 2005 un grupo de investigadores chinos redujo la cantidad de intentos a 269. Tiempo más tarde se avanzó hasta 263 y, finalmente, en la Universidad de Macquarie (Australia) lograron reducirlo hasta 252 (cerca de 2000 veces más rápido de lo esperado).

Como consecuencia de esto, el CA/Browser Forum recomendó en el año 2011 comenzar a abandonar SHA-1 tan pronto como sea posible. De hecho, el gobierno de los Estados Unidos dejó de utilizar este mecanismo en el 2010.

Acerca de SHA-2

Seguir leyendo…

Qué es HSTS y cómo implementarlo para incrementar la seguridad de mi sitio

Desde que Google anunciara días atrás que subiría el ranking de búsqueda a los sitios que utilicen HTTPS, múltiples han sido las webs que comenzaron a hacer pruebas con el protocolo de transferencia seguro.

En esta edición vamos a trabajar sobre HSTS, una política o mecanismo de seguridad estandarizado que anuncia a los navegadores cuándo una web (y todos sus enlaces) deben ser accedidos exclusivamente utilizando HTTPS.

HSTS significa, por sus siglas en inglés, HTTP Strict Transport Security y sus detalles están especificados en el RFC 6797. Su principal objetivo es impedir que un atacante convierta una conexión HTTPS en HTTP. El mecanismo instruye al UA (user agent o navegador del usuario) a finalizar la conexión con el servidor de destino si ocurre algún error mientras intenta establecer una comunicación segura (SSL/TLS), incluyendo certificados revocados. Además, todos los enlaces de la página se visualizarán como HTTPS inluso si no fueron creados de esa manera.

 

HSTS envía un mensaje al navegador del usuario que podría ser interpretado como: “¡Hola! Toda nuestra comunicación debe ser encriptada, caso contrario tendrás que mostrar un mensaje de error.”

Seguir leyendo…

Cómo proteger mi sitio de WordPress con SSL

Hace algunos días anunciábamos los cambios que está implementando Google en su motor de búsqueda, relacionados con la idea de “subir” el ranking de los sitios que trabajen bajo un protocolo de navegación seguro (SSL/TLS) en los resultados de búsqueda.

Esto, sumado a los acontecimientos que en los últimos meses han demostrado la necesidad de tomar mayores recaudos a la hora de hablar de seguridad en Internet, nos lleva a evaluar diferentes alternativas para proteger nuestra información. En este post les ayudaré a implementar un certificado de seguridad (SSL/TLS) en un sitio de WordPress self-hosted.

WordPress.com no soporta el uso del HTTPS en dominios personalizados. Sin embargo, sí lo permite en aquellos blogs con dominio finalizado en wordpress.com. Más info aquí.

TLS (Transport Layer Security, por sus siglas en inglés) es uno de los protocolos de cifrado de información comunmente utilizados en Internet para proteger los datos enviados entre dos equipos. Más conocido como “HTTPS” o “HTTP con candado”, TLS y SSL, su antecesor, permiten a los usuarios asegurarse que los datos que intercambian en un sitio web viajan de manera segura y no puedan ser interceptados por usuarios malintencionados.

Hosting y SSL

Seguir leyendo…

Contraseñas de usuarios de Bitly comprometidas (y van…)

Hace algunos días el equipo de seguridad de Bitly, popular servicio de acortamiento de direcciones conocido por sus dominios bit.ly o j.mp, fue alertado de un posible acceso no autorizado a sus bases de datos.

Al respecto, Rob Platzer, CTO de la compañía con sede en New York, informó mediante un comunicado de prensa publicado en su blog que el entorno productivo de Bitly no se encuentra comprometido.

Nuestro equipo de Seguridad logró determinar con un alto grado de confianza que no existieron conexiones externas hacia nuestra base de datos de usuarios de producción, asi como tampoco a nuestras redes o servidores. Sin embargo, observaron una cantidad inusual de tráfico originado desde nuestro sistema de almacenamiento externo de backup. En este punto, consideramos que el mejor camino era considerar nuestra base de usuarios comprometida y ejecutar un inmediato plan de respuesta que incluyó algunas tareas para proteger las cuentas de Facebook y Twitter conectadas a nuestros usuarios.

Las acciones ejecutadas por el equipo de Seguridad de Bitly fueron las siguientes:

Seguir leyendo…

Vulnerabilidad Heartbleed. ¿De qué se trata?

vulnerabilidad-heartbleed-de-que-se-trata_001Quizá en los últimos días hayan oído mencionar mucho las palabras Heartbleed y OpenSSL. Pero… ¿De qué se trata todo esto?

Heartbleed es el nombre que se le dió a un agujero de seguridad (bug o vulnerabiliad) que afecta a los servidores web como Apache y Nginx que utilizan tecnología OpenSSL para procesar sus transacciones seguras.

OpenSSL, hermano de OpenSSH, es un paquete de herramientas y librerías de código abierto que permite a los administradores de sitios web encriptar las comunicaciones cliente <–> servidor mediante certificados de seguridad (el famoso HTTPS), entre otras funcionalidades. Está basado en la librería SSLeay desarrollada por Eric Young y Tim Hudson y permite su uso con propósitos comerciales y no comerciales. Es, por esto último, que se estima que dos tercios de los sitios web de Internet podrían estar o haber estado afectados por esta vulnerabilidad.

 

Un poco de historia

La vulnerabilidad fue introducida en Diciembre de 2011 y distribuida junto con la versión 1.0.1 y posteriores de OpenSSL, publicada a partir del 14 de Marzo de 2012.

El pasado 3 de Diciembre de 2013, Neel Mehta, del equipo de Seguridad de Google, reportó la existencia de un bug en el código de las versiones 1.0.1, 1.0.1f  y 1.0.2 beta-1 que podría permitir que las comunicaciones cifradas sean interceptadas utilizando el método man-in-the-middle, en el que un atacante es capaz de leer y modificar la información intercambiada entre dos equipos sin generar ninguna sospecha. Además, la vulnerabilidad pone en riesgo las claves SSL privadas de los servidores, por lo que los sitios afectados debieron re-generar sus certificados de seguridad luego de corregir el fallo.

El nombre heartbleed (sangrado del corazón) fue elegido por un ingeniero de la firma de seguridad informática Codenomicon, quien también diseñó el logo y puso en línea el sitio oficial de la vulnerabilidad. Según información proporcionada por Codenomicon, Mehta reportó el fallo primero aunque ambos lo hicieron de manera independiente.

La vulnerabilidad quedó registrada bajo el CVE (Common Vulnerabilities and Exposures, por sus siglas en inglés) CVE-2014-0160. Considerando que fue introducida al código de OpenSSL en la versión 1.0.1, veriones anteriores también se encuentran seguras (1.0.0 y 0.9.8). Mediante el sitio oficial del proyecto, el pasado 7 de abril se publicó la versión 1.0.1g de OpenSSL que elimina la vulnerabilidad y se espera que en las próximas semanas se publique la 1.0.2-beta2 con la misma modificación.

 

Recomendaciones para usuarios

Seguir leyendo…