2018-08-13

¿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 el estándar data del año 2013, no fue hasta hace algunos meses que los proveedores de DNS y las entidades de certificación comenzaron su implementación. Algunos de ellos aun no aceptan registros del tipo CAA y otros aun no verifican la existencia del registro antes de emitir sus certificados, pero están gradualmente modificando sus infraestructuras para hacerlo. En mi caso utilizo DNS Made Easy desde hace algunos años y, además de soportar este tipo de registros, siempre he tenido estupendos resultados.

En lo que respecta a la creación de registros CAA, están compuestos por tres elementos. Demos un vistazo a su topología:

  • flag: Un entero entre 0 y 255.
  • tag: Existen tres tags definidos por el RFC.
  • issue: Permite autorizar explícitamente a una única entidad de certificación a emitir certificados para ese dominio o subdominio. De ser necesario autorizar a más de una, se deberán crear múltiples registros CAA.
  • issuewild: Permite autorizar explícitamente a una única entidad de certificación a emitir certificados de comodín (wildcard) para ese dominio/subdominio. Ningún otro certificado que no sea wildcard podrá ser emitido por esa entidad, salvo que esté expresamente configurado.
  • iodef: Especifica a dónde deben enviarse los reportes de intentos de emisión de certificados por una entidad no autorizada (El formato debe ser "mailto:alguien@ejemplo.com").
  • value: El valor del registro.


Vamos con algunos ejemplos:

Si queremos autorizar a Let’s Encrypt y a Comodo, debemos agregar un registro CAA para cada entidad:

pablofain.com.  CAA 0 issue "comodo.com"
pablofain.com.  CAA 0 issue "letsencrypt.org"

Si la idea es autorizar a Let’s Encrypt y a Comodo, pero solo a esta última para emitir certificados wildcard, debemos configurar los registros de la siguiente manera:

pablofain.com.  CAA 0 issue "letsencrypt.org"
pablofain.com.  CAA 0 issuewild "comodo.com"

Para recibir una notificación sobre el intento de emisión de certificados mediante una entidad de certificación no autorizada:

pablofain.com.  CAA 0 iodef "mailto:alguien@ejemplo.com"

Finalmente, para el caso de los subdominios podemos configurar cada uno de ellos para autorizar a diferentes entidades de certificación. En este ejemplo, Let’s Encrypt podría emitir certificados para todos los subdominios de pablofain.com, excepto sub1 y sub2.

pablofain.com.        CAA 0 issue "letsencrypt.org"
sub1.pablofain.com.   CAA 0 issue "comodo.com"
sub2.pablofain.com.   CAA 0 issue "rapidssl.com"

Hasta Abril de 2017, las entidades de certificación que verifican la existencia de registros CAA son: Amazon, Certum, Comodo, DigiCert, Entrust, GlobalSign, GoDaddy, Izenpe, QuoVadis, Starfield GoDaddy, StartCom WoSign, Let’s Encrypt, Symantec, GeoTrust, Thawte, T-Telesec, Trustwave y WoSign.

En cuanto a las desventajas o puntos débiles de CAA, a simple vista podemos observar dos:

  • Si la entidad de certificación ha quedado comprometida o no realiza la verificación de registros CAA, el certificado podría ser emitido con normalidad.
  • Si la zona DNS del dominio ha quedado comprometida, el registro CAA podría modificarse por el valor deseado por el atacante. Una buena idea para prevenir esto es implementar DNSSEC.

Si necesitan ayuda para configurar sus registros CAA, el sitio SSLMate ofrece un wizard que funciona a la perfección.

Fuente: Pablo Fain

2018-08-12

Corregida en pocas horas, grave vulnerabilidad remota en CGit

Esta semana se ha resuelto una grave vulnerabilidad remota en CGit, relacionada con el salto de restricciones (Path traversal) y la capacidad de mostrar información sensible del servidor cgit vulnerado. En unas pocas horas el fallo fue corregido por los desarrolladores.


CGit es una interfaz web (CGI) del sistema de repositorios git, escrito en C, que facilita la gestión remota entre diferentes usuarios.

La vulnerabilidad (CVE-2018-14912), descubierta por el investigador de Google Project ZeroJann Horn, estaba localizada en la función cgit_clone_objects() y específicamente en la combinación de send_file() y git_path().
Esta última función no aplicaba los filtros necesarios en las rutas recibidas, para impedir este tipo de vulnerabilidad. Al explotarse, cualquier usuario malintencionado podría construir peticiones de este tipo:

http://<servidor>/cgit/cgit.cgi/git/objects/?path=

que, al ejecutarse por parte del servidor, devolverían el contenido del path/fichero invocado. Ejemplo de una petición utilizando curl, que mostraría el fichero de usuarios del sistema:

$ curl http://127.0.0.1/cgit/cgit.cgi/git/objects/?path=../../../../../../../etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin

Analizando el diff dispuesto para corregir la vulnerabilidad, se detalla además que el fallo fue introducido en 2008Debido a la longevidad de la misma (las versiones 0.8 a la 1.2 se verían afectadas) y que es trivial a la hora de explotarse, recomendamos encarecidamente actualizar urgentemente a la última versión disponible CGit 1.2.1:
git://git.zx2c4.com/cgit

Fuente | una-al-dia

2018-08-04

WordPress 4.9.8 - Versión de mantenimiento

Estamos encantados de anunciar la disponibilidad inmediata de WordPress 4.9.8. Esta versión de mantenimiento soluciona 46 fallos, mejoras y benditas tareas, incluida la actualización del tema Twenty Seventeen incluido.
A continuación tienes lo más destacado de las novedades.

Mensaje “Prueba Gutenberg”

A la mayoría de los usuarios se les mostrará un aviso en su escritorio de WordPress. Este “Prueba Gutenberg” es una oportunidad para los usuarios de usar el editor de bloques Gutenberg antes de su lanzamiento en WordPress 5.0.
En WordPress 4.9.8, el mensaje se mostrará a los siguientes usuarios:
  • Si Gutenberg no está instalado o activo el mensaje se mostrará a los usuarios administradores en los sitios simples, y al super administrador en multisitios.
  • Si Gutenberg está instalado y activo el mensaje se mostrará a usuarios colaboradores y superiores.
  • Si está instalado y activo el plugin Classic Editor el mensaje se ocultará a todos los usuarios.
Puedes aprender más leyendo  “Try Gutenberg” Callout in WordPress 4.9.8 (en inglés).

Arreglos/mejoras de privacidad

Esta versión incluye 18 arreglos de privacidad centrados en asegurar la consistencia y flexibilidad en las nuevas herramientas de datos personales que se añadieron en la versión 4.9.6, incluyendo:
  • El tipo de solicitud a confirmar ahora se incluye en la línea del asunto en todos los correos de confirmación de privacidad.
  • Mejoras de consistencia con el nombre del sitio utilizado en los correos de privacidad en multisitio.
  • Ahora se puede ajustar la paginación en las pantallas de administración de solicitudes de privacidad.
  • Se ha incrementado la cobertura de pruebas para varias funciones de privacidad incluidas.
Descarga WordPress 4.9.8 o pásate por tu Escritorio → Actualizaciones y haz clic en “Actualizar ahora”. Los sitios compatibles con las actualizaciones automáticas en segundo plano ya están empezando a actualizarse automáticamente.

Entradas populares