22 de agosto de 2018

Github avisará si tú contraseña ha sido expuesta en otras webs


Github ha modernizado sus sistemas de seguridad para emitir advertencias a los usuarios cuando sus contraseñas han sido expuestas en línea a través de otras webs.
GitHub se asoció recientemente con Have I Been Pwned, un motor de búsqueda operado por el experto en seguridad Troy Hunt para dar al público en general una manera de descubrir rápidamente si sus cuentas y contraseñas en línea han sido expuestas o no.
En 2012, LinkedIn sufrió una grave violación de datos en la que, cuatro años después, se descubrió que 167 millones de registros de usuarios habían sido robados. Esta brecha de datos posiblemente aumentó la popularidad del servicio Have I Been Pwned y sacó a la luz el tema de las contraseñas reutilizadas, que los atacantes pueden utilizar para comprometer otras cuentas y servicios en línea.

Autenticación de dos factores

La autenticación de dos factores (2FA) es otra capa de seguridad que se puede agregar a muchas cuentas en línea para disminuir el riesgo de compromiso, incluso si la misma contraseña se usa en otro lugar.
Pero con tantos sistemas en línea protegidos por nada más que una contraseña que puede reutilizarse o exponerse en otro lugar, y los usuarios que optan por no habilitar 2FA, notificar a los titulares de cuentas sobre un posible compromiso es un paso crítico hacia una mayor seguridad.
Hunt permitió a Github descargar todo el repositorio de registros de Have I Been Pwned, que actualmente se encuentra en aproximadamente 517 millones de registros.
"Al utilizar estos datos, GitHub creó una versión interna de este servicio para que podamos validar si se ha encontrado la contraseña de un usuario en cualquier otro servicio filtrada públicamente", dice la compañía.
Ahora los usuarios de Github que usan contraseñas comprometidas están siendo conscientes de ello y se les pedirá que creen nuevas credenciales durante el inicio de sesión o en el proceso de registro en la plataforma.
GitHub recomienda que los usuarios habiliten 2FA para mejorar la seguridad de su cuenta.
Los usuarios también deben considerar registrarse para recibir notificaciones que lo alertarán automáticamente si su dirección de correo electrónico ha sido detectada en una nueva brecha de seguridad.
Enlace | Tecnonucleous

21 de agosto de 2018

Un fallo de deserialización en PHP pone en riesgo a millones de sitios web WordPress


El investigador en seguridad Sam Thomas, que trabaja para Secarma, ha descubierto una nueva técnica que podría hacer más fácil a los atacantes la explotación de vulnerabilidades de deserialización en PHP mediante la utilización de funciones que eran consideradas como de riesgo bajo.
PHP es uno de los lenguajes de programación más populares, siendo la tecnología para el tratamiento de páginas web dinámicas desde el lado del servidor más utilizado del mundo. Además, muchos de los CMS más importantes lo utilizan, entre ellos WordPress, por lo que podría haber millones de sitios web vulnerables ante esta nueva técnica descubierta.
La deserialización en PHP fue documentada inicialmente en 2009 y abre la puerta a que atacantes puedan llevar a cabo diferentes tipos de ataques mediante el suministro de entradas maliciosas a la función unserialize(), la cual es una característica oficial y legítima de la implementación oficial del lenguaje que nos ocupa. Básicamente, la función seriar (serialize()) permite convertir los datos de los objetos en texto plano, mientras que deserializar (unserialize()) ayuda al programa a recrear el objeto a partir de la cadena en texto plano.
Sam Thomas ha descubierto que un atacante puede usar funciones de bajo riesgo contra archivos Phar (un formato de fichero en PHP que almacena los metadatos en un formato seriado que se deserializa cuando una función de operación de ficheros intenta acceder a él) para realizar de ataques de deserialización sin requerir la utilización de la función unserialize() en una gran variedad de escenarios.
Para explotar el fallo con éxito, el atacante solo tiene que subir al servidor objetivo un fichero para su conversión a un Phar válido que contenga una carga maliciosa en forma de objeto. Después se tiene que hacer que la función que opera con el archivo acceda utilizando el wrapper de transmisión “phar://” para ejecutar el código arbitrario cuando el programa deserializa los metadatos. Por ejemplo, el investigador ha conseguido explotarlo con una imagen JPEG, la cual pasó de un fichero Phar a una imagen JPEG válida al modificar sus 100 primeros bytes, algo que ha podido realizar a través de la funcionalidad de miniaturas de WordPress, que “habilita a un atacante con privilegios para cargar y modificar elementos multimedia y obtener el control suficiente del parámetro utilizado en una llamada ‘file_exists’ para causar una deserialización.”
Sam Thomas ha reportado la vulnerabilidad al equipo de WordPress a principios del presente año, pero a día de hoy todavía no hay un parche que neutralice al 100% la vulnerabilidad. También lo ha reportado a Typo3 el 9 de junio de 2018, aunque para este CMS sí hay un parche completo que ha llegado a las versiones 7.6.30, 8.7.17 y 9.3.
Fuente | Muy Seguridad

13 de agosto de 2018

¿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

12 de agosto de 2018

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

4 de agosto de 2018

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