Buscar

Mostrando entradas con la etiqueta Seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta Seguridad. Mostrar todas las entradas

Windows: Exportar certificado digital no exportable

Cuando instalamos un certificado digital en sistemas Windows, disponemos de la opción:

"Marcar esta clave como exportable. Esto le permitirá hacer una copia de seguridad de las claves o transportarlas en otro momento."

Windows: Reset password administrador del dominio

Especialmente en sistemas heredados, nos podemos encontrar con la necesidad de tener que cambiar el password de administrador del dominio sin poder iniciar sesión previamente en el controlador o controladores de dominio.

Veamos la ubicación donde se guarda la contraseña:

- En entornos de Active Directory, el password de administrador del dominio queda guardado en la base de datos de Active Directory, por defecto en: C:\Windows\NTDS\NTDS.dit. La ruta de la base de datos es definida en el proceso de promoción del equipo a controlador de dominio.

- En entornos de workgroup o cuentas locales, el password de administrador queda guardado en el registro de Windows en la rama de seguridad.

Existen herramientas de terceros de Windows para realizar un reset del password.

Este tipo de herramientas puede que no funcionen sobre sistemas con Active Directory, ya que estas herramientas, conectan con el registro de Windows y eliminan el hash correspondiente al password de una cuenta de usuario.

De todas formas, como norma general: Hemos de entender que cualquier sistema operativo donde disponemos de acceso local al mismo, siempre podremos restablecer el acceso de una forma o de otra.

Veamos un procedimiento para realizar un reset del password de administrador del dominio:


* Este procedimiento será valido tanto para realizar un reset del password de cuentas de usuario locales como para cuentas de usuario de dominio, incluida la cuenta de administrador.

Idea: Acceder al sistema de ficheros NTFS de un controlador de dominio (DC), substituir el fichero de la lupa (magnify.exe): "opciones de accesibilidad" por el cmd.exe, reiniciar normalmente y antes de iniciar sesión, ejecutar la lupa. 

Dispondremos de una shell de CMD con permisos de SYSTEM, con los servicios de Active Directory levantados. A partir de aquí, podremos hacer un reset del password de administrador del dominio.

1) Accedemos al sistema de ficheros NTFS:

Una de las formas para acceder al sistema de ficheros NTFS es iniciar el equipo desde un DVD/ISO de Windows Server o Windows cliente.

No es necesario que el DVD/ISO sea la misma versión de sistema Windows que la que tenemos instalada en el controlador de dominio (DC), ya que tan solo necesitamos poder escribir en el sistema de ficheros NTFS.

Veamos como iniciar desde el DVD/ISO de Windows Server 2012 R2 y obtener una consola de CMD:

Iniciamos el DVD, seleccionamos idioma, seleccionamos "Reparar equipo", "Solucionar problemas", "Símbolo del sistema":

Windows: Administrador del dominio reset password

Linux: Vulnerabilidad GHOST

Se ha detectado una vulnerabilidad importante en la librería GLIBC sobre sistemas Linux: (CVE-2015-0235)

En el siguiente enlace podemos encontrar información detallada sobre el problema:


Tal y como podemos leer en el artículo anterior, esta vulnerabilidad es de gran importancia y afecta a múltiples servicios.

La mayoría de distribuciones de Linux, ya han liberado parche para corregir la vulnerabilidad.

Veamos un pequeño FAQ del problema:

1) ¿Qué permite explotar la vulnerabilidad?

Ejecución remota de código arbitrario sobre cualquier servicio que utilice la librería GLIBC y utilice las funciones: gethostbyname() y gethostbyname2(). 

Es por este motivo que la vulnerabilidad se llama GHOST.

Ya se han realizado pruebas de concepto donde se puede explotar la vulnerabilidad de forma remota enviando un correo electrónico a un servicio de correo que utilice la librería GLIBC como Exim.

2) ¿Qué es la librería GLIBC?

GLIBC significa "GNU C Library", es una librería de C muy extendida y utilizada por muchos servicios.

3) ¿Qué servicios utilizan la librería GLIB?

Sobre nuestro servidor Linux:

[root@LINUX1 /]# lsof | grep libc | awk '{print $1}' | sort | uniq
abrtd
abrt-dump
acpid
atd
auditd
automount
awk
bash
certmonge
crond
dbus-daem
grep
hald
hald-addo
hald-runn
init
irqbalanc
lsof
mingetty
mysqld
mysqld_sa
ntpd
pdns_serv
rpcbind
rsyslogd
sort
sshd
udevd
uniq
vmtoolsd

4) ¿Qué versión de GLIBC tenemos instalada en un sistema RedHat/CentOS?

[root@LINUX1 /]# rpm -qa glibc
glibc-2.12-1.149.el6_6.5.x86_64

5) ¿Qué versiones son vulnerables?

Cualquier versión entre 2.17 a 2.2 que no esté parcheada.

Versiones superiores no están afectadas.

Las distribuciones: RHEL 5,6,7 incluyen GLIBC dentro de este rango de versiones, por lo tanto son vulnerables si no parcheamos.

6) ¿Cómo puedo saber si mi sistema es vulnerable?

Existen muchos códigos fuente en "C" de ejemplo para verificar si nuestro sistema es vulnerable.

Bastará con descargar el código fuente en "C", compilarlo con el comando gcc y ejecutarlo.

Ejemplo:

wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
 
gcc GHOST.c -o GHOST
 
./GHOST

Responde vulnerable o not vulnerable.

Vista de ejecución:

Ejemplo de ejecución verificador vulnerabilidad GHOST

7) ¿Cómo parcheo?

Si disponemos de una distribución de Linux dentro del Life-Cycle y no hemos compilado la librería, será tan sencillo como actualizar utilizando el gestor de paquetes a nivel de repositorio.

Por ejemplo, sobre sistemas RHEL/CentOS:  yum update glibc


8) ¿Debo reiniciar después de parchear?

La forma más fácil de que la versión parcheada de GLIBC empiece a funcionar es reiniciar.

La alternativa es reiniciar todos los servicios que utilicen la librería.

9) Una vez parcheo: ¿Qué versiones de GLIBC debería ver sobre RHEL/CentOS?

La versión será la misma que teníamos, pero estará parcheada, así que cambiarán los últimos dígitos de la versión del paquete.

A partir de las siguientes versiones de paquete de GLIBC, ya son versiones parcheadas:
CentOS 6: glibc-2.12-1.149.el6_6.5
CentOS 7: glibc-2.17-55.el7_0.5
RHEL 5: glibc-2.5-123.el5_11.1
RHEL 6: glibc-2.12-1.149.el6_6.5
RHEL 7: glibc-2.17-55.el7_0.5

Si analizamos el changelog del paquete de glib que hemos instalado, veremos la corrección de la vulnerabilidad:
[root@LINUX1 test]# rpm -q --changelog glibc | grep CVE-2015-0235
- Fix parsing of numeric hosts in gethostbyname_r (CVE-2015-0235, #1183532).
- Fix parsing of numeric hosts in gethostbyname_r (CVE-2015-0235, #1183532).

Phishing con Data URI scheme

Recientemente me encontrado con un tipo de phishing distribuido por las redes sociales y correo electrónico que despista a las medidas de protección habituales.

El phishing en cuestión utiliza: Data URI scheme

Data URI scheme permite encapsular elementos como imágenes, ficheros html, etc en una única conexión HTTP en vez de utilizar múltiples conexiones HTTP. 

De esta forma se consigue minimizar el número de peticiones HTTP hacia el servidor web.

Podemos obtener más información sobre Data URI scheme en:


Los navegadores que soportan Data URI son los siguientes:

Chrome: Todas las versiones
Firefox: Todas las versiones
Internet Explorer: A partir de IE 8.0
Opera: A partir de 7.2
Safari: Todas las versiones

Desgraciadamente esta técnica también pude ser utilizada para distribuir phishing ocultando la URL al usuario.

Veamos su funcionamiento con un ejemplo:

Creamos un fichero HTML con el siguiente contenido y lo ejecutamos con el navegador:

Phishing con Data URI scheme

Resultado:
Phishing con Data URI scheme


Codificamos el código HTML anterior con base64. 

Para ello, podemos utilizar un conversor online:

Phishing con Data URI scheme

Una vez obtenemos el código equivalente en base64, procedemos a montar el Data URI en el navagedor:

Empezaremos con: data:text/html;base64,

y a continuación pegaremos el código base64 obtenido.

Veamos el resultado:

Phishing con Data URI scheme