13 septiembre, 2017

Descifrar tráfico SSL/TLS con Wireshark

Para poder descifrar tráfico SSL/TLS necesitamos la clave privada sin passphrase del certificado digital del servidor. No se trata de ningún "hack mágico" con el que podremos descifrar el tráfico SSL/TLS.

Si necesitamos analizar el tráfico de un servidor al que tenemos un acceso legítimo, este es un método que nos permitirá poder ver en texto plano todo el tráfico cifrado que circula por el servidor con el fin de detectar posibles anomalías en un red corporativa.

Una vez obtenida la clave privada podremos añadirla en un sniffer de red como Wireshark, y de ese modo analizar el tráfico HTTPS como si de un paquete HTTP se tratase.

Al intentar hacer un seguimiento de un cifrado HTTPS este se muestra como un paquete TCP. Haciendo un "Follow > TCP Stream" en Wireshark veremos el tráfico cifrado, como se muestra en la siguiente captura. 

Figura 1: Paquete de tráfico TCP cifrado con SSL

Exportamos el certificado con la clave privada del servidor. Una vez tenemos exportado el certificado en formato .pfx con OpenSSL lo convertimos en formato .pem que el formato que Wireshark reconoce. Primero extraemos la clave privada del certificado y después eliminamos la contraseña de la clave privada extraída.

Extraemos la clave privada del certificado y la convertimos a formato .pem.
openssl pkcs12 in certificado.pfx -out claveprivada.pem -nocerts -nodes
Eliminamos la passphrase de la clave privada extraída anteriormente.
openssl rsa -in claveprivada.pem -out claveprivadasinpass.pem
Figura 2: Conversión y extracción de la clave privada del certificado digital .pfx.

Añadir la clave privada .pem sin passphrase extraída del certificado .pfx en Wireshark: "Edit > Preferences... > Protocols > SSL". Editamos para cargar la clave privada.

IP Address: IP del servidor.
Port: 443
Protocol: HTTP
Key File: Path del fichero de la clave privada .pem.
Password: Podremos dejar en blanco este espacio ya que el .pem de la clave privada está sin passphrase.

Figura 3: Añadir la clave privada .pem en Wireshark.

Podremos establecer un fichero de log "SSL debug file". En el que se almacenará en texto plano todos los paquetes cifrados, también podremos analizar desde otra perspectiva el tráfico cifrado desde el fichero log.

Figura 4: Fichero log debug SSL de Wireshark.

Una vez cargada la clave privada .pem reiniciamos Wireshark para actualizar los cambios. Los paquetes TCP cifrados anteriormente serán ahora paquetes HTTP en texto plano y se podrán seguir: "Follow > SSL Stream".

Figura 5: Seguimiento SSL Stream de paquetes HTTP descifrados

En la siguiente captura de pantalla se puede ver el seguimiento del SSL stream en texto plano en paquetes HTTP. En este caso se trata del mismo seguimiento de paquetes TCP referenciados en la "Figura 1".

Figura 6: SSL Stream en texto plano de paquetes HTTP.

Aunque por seguridad, en la generación de cualquier certificado se debería marcar la opción como no exportable para la clave privada, con el fin de minimizar riesgos en la organización. Ya que si alguien no autorizado consiguiese acceso al servidor este podría exportar un certificado PKCS#12 con la clave privada y generar su propia passphrase.

Saludos!

09 septiembre, 2017

Convertir certificados digitales .pfx .pem o .crt y extraer la clave privada de certificados PFX (PKCS#12) con OpenSSL

En Windows Server cuando se genera un certificado autofirmado por el propio servidor este se puede exportar, por defecto en formato .pfx. Se puede exportar el certificado junto a la clave privada, de ese modo el certificado alamacenará tanto la clave pública como la clave privada.

Si necesitamos extraer la clave privada podemos usar OpenSSL el cual utilizará uno de los estándares de criptografía PKCS (Public-Key Cryptography Standards) concretamente PKCS#12 (formatos PFX) que define un formato de fichero usado comúnmente para almacenar claves privadas con su certificado de clave pública protegido mediante clave simétrica (es decir, una passphrase o contraseña).

Exportamos el certificado autofirmado del servidor IIS. Estará en formato PKCS#12.

Figura 1: Exportando certificado del servidor IIS.

Podemos exportar dicho certificado del propio equipo local a través de la consola de Microsoft para la administración de certificados certmgr.msc. Agregar administrador de certificados a través de un MMC. En el asistente de exportación nos permite la opción de incluir la clave privada en el certificado.

Figura 2: Exportando certificado desde certmgr.msc

Descargar OpenSSL para Windows. A través de una CLI de Windows Server ejecutamos OpenSSL con PKCS12 para la obtención de la clave privada del certificado. Tendremos que extraer el certificado (clave pública), la clave privada (nos pedirá la contraseña en ambos casos) y finalmente eliminar el passphrase de la clave privada extraída.

Figura 3: Usando OpenSSL para la extracción de certificados.

Extraer la clave pública del certificado .pfx
openssl pkcs12 -in certificado.pfx -out clavepublica.pem -nokeys
certificado.pfx: Certificado pfx del servidor.
clavepublica.pem: Clave pública. (También se podría exportar a un formato de salida .crt o .cer).
-nokeys: Separará la clave pública de la clave privada del certificado .pfx.

Figura 4: Fichero de salida de la clave pública.

Extraer la clave privada del certificado .pfx
openssl pkcs12 -in certificado.pfx -out claveprivada.pem -nocerts -nodes
certificado.pfx: Certificado pfx del servidor.
claveprivada.pem: Clave privada. (También se podría exportar a un formato de salida .crt o .cer).
-nocerts: Separará la clave privada de la clave pública del certificado .pfx.
-nodes: No cifra la salida de la clave privada (quedando visible en texto plano).

Figura 5: Fichero de salida de la clave privada en texto plano (-nodes).

Eliminar la contraseña de la clave privada extraída del certificado .pfx
openssl rsa -in claveprivada.pem -out claveprivadasinpassphrase.key
Figura 6: Fichero de salida de la clave privada sin passphrase.

Con esto finalmente tendremos la clave privada sin contraseña para poder utilizarla en lo que nos sea necesario.

Saludos!

06 agosto, 2017

Administrar los permisos de un servicio de Windows sobre un objeto

Definimos objeto a un fichero, carpeta, unidad, etc. Todo aquello en lo que se puedan administrar permisos NTFS en el caso de Windows.

Con los permisos NTFS de Windows podemos gestionar las DACL (Discretionary Access Control List) son lista de control de acceso discrecional en las que se pueden controlar quien es el propietario de un objeto y especifica quién tiene permiso y quién no para acceder a dicho objeto.

Sabemos que se pueden conceder DACL a usuarios locales del sistema, de un dominio, equipos o grupos de usuairos sobre uno o varios objetos (ficheros, carpetas o unidades).

¿Se pueden administrar estos permisos a objetos para un servicio de Windows o de terceros?.
Si. Se pueden asignar uno o varios servicios a uno o varios objetos de Windows y establecer permisos sobre ellos. Lo que pasa que no se puede hacer una forma gráfica amigable ni de manera trivial como pasa con los usuarios.

Para conceder permisos a un objeto es necesario conocer el SID (Security Identifier) del usuario, equipo, grupo, etc. Que se va asignar a ese objeto. Por ejemplo en el caso de Windows, buscando el nombre de un usuario y asignándolo a un objeto sería suficiente para administrar las DACL de ese usuario sobre un objeto. De forma subyacente el sistema está reconociendo un SID asociado a ese usuario.

Los SID de los usuarios locales de un equipo se registran en la siguiente rama del registro de Windows.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProfileList
Hay otras formas de conocer los SID de usuarios locales así como también usuarios de dominio y equipos. Para conocer estos SID podemos usar WMIC (Windows Management Instrumentation Command-line).

Para listar todos los usuarios locales filtrando por nombre de usuario y SID.
wmic useraccount get name,sid
Igual que lo anterior pero filtrando un nombre de usuario en concreto.
wmic useraccount where (name='USUARIO') get name,sid
Lo mismo pero para usuarios que pertenezcan a un dominio.
wmic useraccount where (name='USUARIO' and domain='DOMINIO') get name,sid
Con PsGetSid (de Sysinternals) para listar los SID de usuarios locales de equipos remotos y el propio SID de la máquina locales y otras remotas. Para ejecutar cualquier herramienta PsTools de forma remota tendremos que conocer las credenciales de un administrador local o de dominio en la máquina remota.

Comentado todo lo anterior vamos a ver como podemos agregar un servicio a un objeto y gestionar sus permisos.

Lo primero que tenemos que averiguar es el nombre asignado a un servicio. Ya sea de Windows o de una aplicación de terceros la forma de conocerlo sería la misma.

En este caso de ejemplo usaré el servicio de Dropbox para Windows. Abrimos una consola de servicios (services.msc) y buscamos el servicio que queremos utilizar. Cuando abrimos el servicio vemos el apartado "Nombre del servicio" será ese el que usaremos.

Figura 1: Nombre del servicio Dropbox para Windows (DbxSvc).

Para conocer su SID asignado por Windows a un servicio usaremos la herramienta de comandos de Windows SC (Service Controller).
sc showsid DbxSvc
Figura 2: Conocer el SID asignado a un servicio de Windows con SC.

Ahora solo quedaría asociar ese SID a un objeto. De forma gráfica perosnalmente no encontré forma de hacerlo, pero si por la herramienta de comandos de Windows ICACLS. Con la que podemos mostrar y gestionar las listas de control de acceso discrecional (DACL) de un objeto.
En este caso agregaremos a la carpeta llamada "test" (que será el objeto) el servicio de Dropbox mediante el SID obtenido anteriormente.
icacls c:\test /grant *S-1-5-80-315955965-2752282644-3851734118-3415690430-1520210413:(f)
Figura 3: Agregando un servicio a un objeto con ICACLS

Ahora vemos como el servicio DbxSvc ya está integrado en el objeto y podremos manipular los permisos de forma gráfica. 

Figura 4: Administrando de forma gráfica los permisos de un servicio agregado a un objeto.

Saludos!

03 agosto, 2017

Como protegerse de ataques ARP Spoofing

Siguiendo el tema de las entradas en las que comentara los ataques MITM en la tabla ARP.
  1. Ataque MITM: ARP Poisoning y DNS Spoof con Ettercap [Parte 1 de 2]
  2. Ataque MITM: ARP Poisoning y DNS Spoof con ARPSpoof [Parte 2 de 2]
El éxito de esta técnica de ataque radica en que dentro de una misma red local es posible la suplantación de la dirección MAC de la puerta de enlace, por la dirección MAC del atacante en la tabla ARP del equipo atacado. De modo que todo el tráfico que se genere desde en el equipo atacado será interceptado por el equipo atacante y este a su vez lo redireccionará a la dirección de la puerta de enlace legítima de la red local, de esta manera el equipo atacado no será consciente de que su tráfico de red se esté monitoreando, al menos que este consulta su tabla ARP (arp -a).

En la siguiente captura se puede ver una consulta a la tabla ARP de un equipo atacado, consultada antes y después de ser atacado. Vemos como la dirección MAC del Gateway es suplantada por la dirección MAC del atacante (en este caso correspondiente a la dirección IP 192.168.100.20).

Figura 1: Suplantación de MAC en la tabla ARP (ARP Spoofing)

Una opción que podemos aplicar para prevenir la suplantación de la dirección MAC de nuestro Gateway, es incluir dicha dirección MAC en la tabla ARP del sistema local de forma estática. Con esto conseguiremos que el equipo ya tenga definida una ruta estática de dirección IP correspondiente con su dirección MAC, por lo que será imposible el uso de técnicas ARP Spoofing para intentar suplantarla.

En sistemas Windows añadir una o varias rutas estáticas en la tabla ARP es posible con la utilidad de comandos ARP.
arp -s [IP_GATEWAY] [MAC_GATEWAY]
Figura 2: Añadir ruta estática en la tabla ARP en sistemas Windows.

Otra forma de hacerlo es mediante la utilidad de comandos Netsh en su modo interactivo.
netsh
netsh>interface
netsh>ipv4
netsh>add neighbors "[NOMBRE_INTERFACE]" "[IP_GATEWAY]" "[MAC_GATEWAY]"
Figura 3: Añadir una ruta estática en la tabla ARP en sistemas Windows con Netsh.

En el caso de sistemas Linux el argumento y la expresión del comando es la misma que en el caso de Windows.

Vemos como las rutas estáticas en la tabla ARP se marca como "PERM" (permanent).
arp -s [IP_GATEWAY] [MAC_GATEWAY]
Figura 4: Añadir una ruta estática en la tabla ARP en sistemas Linux.

Cualquiera de estas líneas de comandos de la tabla ARP se podría automatizar en un script de inicio del sistema. Ejecutar scripts o aplicaciones al inicio del sistema.

En el caso de Windows se puede crear un fichero por lotes .bat con la instrucción. Y añadir este script en el inicio de sesión o sistema.
@echo off
arp -s [IP_GATEWAY] [MAC_GATEWAY]
exit
En el caso de Linux crearíamos un script .sh en bash. Darle permisos de ejecución a este script y añadiendo el path de ubicación en una línea al final del fichero /etc/rc.local por ejemplo.
#!/bin/sh -e
# Añadir ruta estática gateway en la tabla ARP
arp -s [IP_GATEWAY] [MAC_GATEWAY]
exit 0
Saludos!
Entradas Relacionadas