12 octubre, 2018

Caché de credenciales y passwords almacenadas de los recursos de red de Windows

Existen varias formas de poder visualizar las credenciales "dominio\usuario y password" de los recursos de red almacenados como caché en Windows.

Para que esta caché de almacenamiento sea posible debemos tener habilitado y en ejecución (por defecto ya suele estarlo) el servicio de "Administrador de credenciales" (VaultSvc) que proporciona el almacenamiento seguro y recuperación de credenciales de usuarios.

Hace uso de LSASS (Local Security Authority Subsystem Service) responsable de la política de seguridad en el sistema, audita y verifica quien inicia sesión en sistemas Windows, cambios de contraseñas y crea tokens de acceso.

Figura 1: Servicio de administrador de credenciales.

Cuando se accede a un recurso de red el cual nos solicita usuario y contraseña mediante una autenticación NTLM y se marca el checkbox de "recordar esta contraseña" esta se almacena en un fichero cifrado en nuestro perfil de usuario añadiéndose al Windows Vault.
C:\Users\USUARIO\AppData\Roaming\Microsoft\Credentials

C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Credentials

C:\Users\USUARIO\AppData\Local\Microsoft\Vault

C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Vault

C:\ProgramData\Microsoft\Vault


Administrador de credenciales

Una de las formas más habituales para visualizar las credenciale almacenadas de Windows es a través del Administrador de credenciales situado en el panel de control. Ahí veremos tanto las credenciales de Windows como las credenciales web, en caso de que tengamos guardadas credenciales de sitios web en Internet Explorer únicamente.

Figura 2: Administrador de credenciales de Windows.

KRShowKeyMgr

Otra forma de gestionar estas credenciales es través del "KRShowKeyMgr", se puede ver las credenciales almacenadas, borrarlas y agregar nuevas de forma gráfica.

Para invocar esta ventana escribimos en una cmd o una ventana ejecutar:
rundll32.exe keymgr.dll, KRShowKeyMgr
Figura 3: KRShowKeyMgr - Administrador de nombres de usuario y contraseñas alamacenadas.

cmdkey

Si no tenemos acceso (por restricciones GPO de dominio o similar) al panel de control o poder invocar desde ejecutar, pero si a una consola cmd. Podemos ver estas credenciales a través del comando cmdkey.

Realmente esto es lo que se está usando de forma subyacente a las interfaces gráficas anteriores


Figura 4: cmdkey - Administrador de crecenciales.

Mostrando la ayuda con "cmdkey /?" vemos las posibilidades que tenemos.
Para mostrar la lista de credenciales disponibles:
   cmdkey /list
   cmdkey /list:destino

Para crear credenciales de dominio:
   cmdkey /add:destino /user:usuario /pass:contraseña
   cmdkey /add:destino /user:usuario /pass
   cmdkey /add:destino /user:usuario
   cmdkey /add:destino /smartcard

Para crear credenciales genéricas:
El modificador /add puede reemplazarse por /generic para crear credenciales genéricas

Para eliminar credenciales existentes:
   cmdkey /delete:destino

Para eliminar credenciales RAS (Remote Access Service):
   cmdkey /delete /ras


Herramientas de terceros

Todo lo anterior son formas nativas del sistema de poder gestionar estas credenciales alamacenadas. Pero no permite visualizar las contraseñas en texto plano. Para ello podemos usar algunas herramientas de terceros. Nirsoft desarrolla multitud herramientas de este tipo para sistemas Windows.

CredentialsFileView descifra y muestra las contraseñas en texto plano almacenadas en los archivos de credenciales de Windows (C:\Users\USUARIO\AppData\Roaming\Microsoft\Credentials).

Figura 5: Credentials File View.

VaultPasswordView descifra las contraseñas y otros datos almacenados en Windows Vault (C:\Users\USUARIO\AppData\Local\Microsoft\Vault) del sistema actual o de una unidad externa que se le indique.

Figura 6: Vault Password View.

EncryptedRegView según se le indique escanea el registro de Windows del disco local o de un disco externo. Busca datos cifrados con DPAPI (Data Protection API), intenta descrifralos y mostrarlos en texto plano. No solo mostrará contraseñas almacenadas sino también otro tipo de datos que estuviesen cifrados de productos de Microsoft y también de terceros.

Figura 7: Encrypted Registry View.

Network Password Recovery similar a CredentialsFileView con la diferencia de que este solo muestra aquellas credenciales que afecten con recursos de red.

Figura 8: Network Password Recovery.


Saludos!

19 julio, 2018

Solución al problema de licencias de conexiones RDP entre Windows Server 2016 y Windows Mobile (RDM), Windows CE o versiones antiguas RDP 5.x / 6.x

Actualmente RDP (Remote Desktop Protocol) está en versión 10.x,versiones más actualizadas que incluyen importantes mejoras de seguridad. Como pueden ser: mayor longitud de clave generada por el servidor de licencias RDS 4096 bits con un algoritmo de seguridad SHA256, soportando SSL/TLS y NLA (Network Level Authentication).

Versiones iguales o inferiores a RDP 6.x no soportan las características anteriores. El límite de longitud para las claves es de 2048 bits con algoritmo de seguridad SHA1 (Secure Hash Algorithm 1).

Esta clave se genera en base al método de activación de licencias del administrador de licencias de Escritorio remoto. Si el método empleado es "Web Browser" (Explorador Web) las claves de licencias, se pueden generar un requisitos más bajos que si lo activásemos con otro método, con una longitud de 2048 bits SHA1.

Si aún no tenemos activado el servidor de administración de licencias de Escritorio remoto y queremos tener la compatiblidad entre vesriones más antiguas y actuales para establecer conexiones RDP. Selecionaremos la opción de activar por el método de conexión Web Browser.

En caso de que ya tengamos activado el servidor de licencias procederemos del siguiente modo.

En el servidor Windows Server 2016 que recibirá la conexión RDP desde el dispotivo Windows Mobile o Windows CE comprobamos que NLA esté desactivado.

Figura 1: Desactivar NLA (Autenticación a nivel de red) en Windows Server 2016.
Añadir un rol de instalación de Servicios de Escritorio remoto para VDI (Virtual Desktop Infraestructure).

Figura 2: Añadir rol de instalación de RDS.

En este paso podría ser "Implementación estándar" o "Inicio rápdio".

Figura 3: Implementación estándar para el rol RDS.

Para este esceneario será implementación de escritorio basada en sesión.

Figura 4: Implementaicón de escritorio basada en sesión.

Una vez agregados los servicios RDS. Creamos una colección y no dirigimos a ella.

Figura 5: Colleción de host de sesión de Escritorio remoto.

Dentro de las tareas de colección de RDS configuramos las opciones de seguridad para conexiones RDP.
  • Nivel de seguridad de protocolo de Escritorio remoto (RDP).
  • Nivel de crifrado: Bajo.
  • Deshabilitamos NLA.
Figura 6: Configuración de opciones de seguridad para conexiones RDP.

Como comentaba al princpio, si eligimos un método de conexión basada en Explorador Web. No es necesario realizar ninguna otra acción y las conexión RDP entre Windows Mobile o Windows CE y Windows Server 2012/2016 estarán funcionales.

De igual modo, selecionamos el método de conexión por Explorador Web o Web Browser y aceptamos.

Figura 7: Selección del método de conexión "Web Browser". 

Eliminamos los tipos de claves REG_BINARY correspondientes a las claves de certificado X509 del método anterior de licencias RDS. En el registro del servidor de administrador de licencias de Escritorio remoto.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM
  • Certificate
  • X509 Certificate
  • X509 Certificate ID 
  • X509 Certificate2

Figura 8: Eliminación de claves de licencias generadas por el administrador de licencias de Escritorio remoto.

¿Por qué eliminar estas claves de certificados del registro? 

Entre versiones de RDP actuales la longitud de clave de certificados es de 4096 bits con un algoritmo de seguridad SHA256, estas claves se generan en la primera instancia de conexión entre un acuerdo entre el nivel de seguridad compatible entre las dos máquinas que establecen la conexión RDP.

El equipo del usuario que mantiene la conexión con el servidor al que se conecta establece la longitud y algoritmo de esta clave, si el equipo que se conecta usa una versión de protocolo reciente no habrá problemas, pero si el equipo cliente se trata de un sistema Windows Mobile o similar este no podrá conectarse debido a que el servidor administrador de licencias no puede generar claves de una longitud y algoritmo inferior a los requisitos mínimos que establece el método de conexión (figura 7), por ese motivo el método de conexión Web Browser tiene unos requisitos menos restrictivos y puede generar claves de longitud más corta y cifrados de menor nivel.

Conexión establecida

Como equipo cliente para este ejemplo usaré un Windows XP SP1 que dispone de versión RDP v5.x (funcionaría igual para Windows Mobile, Windows CE o similares con versiones RDP v5.x o v6.x).

Vemos como la conexión RDP se estableció correctamente. En ese momento Windows XP SP1 estableció el acuerdo de certificados X509 de conexión. Si añadimos la desactivación de NLA y el nivel de cifrado más bajo sin SSL/TLS, la conexión es posible.

Figura 9: Conexión RDP establecida entre versioens RDP antiguas y Windows Server 2016.

Saludos!

11 julio, 2018

Ver las passwords Wifis almacenadas a las que nos hemos conectado

Cada vez que desde nuestro equipo Windows nos conectamos a una red inalámbrica WiFi y recordamos la password de indentificación de la red, esta se alamacena en el sistema.

Con el uso de la utilidad de comandos netsh (en la sección de wlan) podemos visualizar las redes que tenemos almacenadas y también la password de acceso que en su momento le indicáramos para autenticarnos en dicha red.

Visualizar los nombres de las redes alamacenadas por Windows en el equipo.
netsh wlan show profile
Establecemos el nombre de la red (SSID - Service Set Identifier) y el valor clear para key.
netsh wlan show profile name=SSID key=clear
Para este ejemplo se usó la red con SSID "prueba".

Figura 1: Netsh - Ver perfiles wlan y obtención de password wifi almacenada.

Otra opción sería usar el "Centro de redes y recursos compartidos" del "Panel control". Una opción con entorno gráfico de Windows 7 es que podíamos ver las redes almacenadas y editar su configuración, en Windows 10 solo podemos ver las redes almacenadas pero no editar su configuración sino estamos conectados en ese momento a esa red. Por lo que hacerlo de una forma gráfica solo nos servirá para ver la password almacenada de la Wifi actual en la que estemos conectados.

Seleccionamos la red Wifi en la que actualmente estemos conectados. Propiedades inalámbricas > Pestaña Seguridad > Mostrar carácteres (nos saltará el UAC por seguridad, para ejecutar esto con privilegios administrativos).

Figura 2: Ver password wifi conectada actualmente.


Saludos!

09 julio, 2018

Especificar servidores de licencias y modo de licencias CAL de servicios de Escritorio remoto (RDS)

Este ejemplo sería aplicable para un entorno en la que disponemos de varios Windows Server. Uno de ellos será el que tendrá el rol instalado de Administrador de licencias de Servicios de Escritorio remoto (RDS - Remote Desktop Services) en el que instalaremos licencias CAL (Client Access Licenses) ya sean por usuario o por dispositivo.

En este caso habrá 5 licencias CAL por usuario para RDS.

Figura 1: Administrador de licencias de Escritorio remoto.

En lo que se centrará esta entrada no será en como activar el servidor de licencias e instalar las licencias CAL para RDS. Sino en como especificamos al resto de servidores que, dependiendo de cada caso, también permitirán conexiones de Escritorio remoto, acepten estas conexiones según el número de licencias CAL disponibles.

Si solo aplicamos esto a la misma máquina que es el administrador de licencias no será necesario nada de esto. 

En caso de una máquina sea el administrador de licencias de Escritorio remoto y queramos que ciertos usuarios se conecten a otro servidor, habrá que especificar en ese otro servidor quien está suministrando las licencias RDS y de que modo se tratan las licencias (por usuario o por dispositivo). 

En el caso de que tengamos más de una máquina que admita conexiones por Escritorio remoto es recomendable emplear objetos de directivas de grupo (GPO - Group Policy Object) de AD (Active Directory).

Por lo que mostraré como hacerlo mediante la instalación de roles RDS y como hacerlo por medio de una GPO.

Método 1: Instalación de roles RDS para VDI (Virtual Desktop Infrastructure)

Agregamos un rol para instalar servicios de Escritorio remoto para VDI.

Figura 2: Instalación de roles RDS para VDI.

Una vez tenemos instalado servicios de Escritorio remoto, en la sección de información general > Administrador de licencias > "Seleccionar el modo de licencias de Escritorio remoto".

Figura 3: Selección del modo de licencias de Escritorio remoto.

En la sección de "Administración de licencias de Escritorio remoto". Establecemos (en este caso) que el modo de licencias CAL será "Por usuario" y que el servidor que proporcionará las licencias será otro. Se podrían agregar varios en caso de haberlos y definir su preferencia, subiendo y bajando su posición en la lista.

Figura 4: Selección del servidor de licencias y el modo de licencias CAL (por usuario o por dispositivo).

Método 2: Creanción de una GPO de Active Directory

Previamente se debería crear una OU (Organizational Unit) en Active Directory e incluír dentro de esta los equipos a los que vincularemos la GPO (aunque esto dependerá de la organización jerarquica de cada sitio). 

Abrimos el "Administrdor de directivas de grupo" (gpmc.msc) de cualquier controlador de dominio, preferiblemente el DC (Domain controller) primario. Creamos una nueva GPO ya vinculada para la la OU donde estarán las máquinas a las que nos conectaremos por Escritorio remoto.

Editamos la GPO y nos situaremos en el siguiente path jerérquico.
Configuración del equipo > Plantillas administrativas > Componentes de Windows > Servicios de Escritorio remoto > Host de sesión de Escritorio remoto > Licencias
Habilitaremos el estado de dos objetos de directiva.

Figura 5: GPO - Licencias CAL para RDS en host de sesión de Escritorio remoto.

Habilitamos: "Usar los servidores de licencias de Escritorio remoto especificados". Espcificando el servidor/es administrador de licencias que se usará.

Figura 6: GPO - "Usar los servidores de licncias de Escritorio remoto especificados".

Habilitamos: "Establecer el modo de licencia de Escritorio remoto". Espefificamos si se trata de licencias CAL por usuario o por dispositivo (en este caso sería por usuario).

Figura 7: GPO - Establecer el modo de licencia de Escritorio remoto.

Aceptamos y cerramos el editor de directivas de grupo. Finalmente podemos abrir una cmd de los servidores a los que les estaría afectando esta directiva y actualizar las políticas con un: gpupdate /force. Puede que nos solicité cerrar sesión y volver iniciarla. 

Para comprobamos la aplicación de directivas, desde un cmd con un gpresult /r o simplemente rsop (RSoP - Resultant Set of Policy).

Saludos!

04 julio, 2018

Exportar certificados digitales no exportables a .PFX (PKCS #12) y restablecer password de la clave privada

En el momento de importar un certificado digital, ya sea para el usuario actual como para el equipo, tenemos la opción de establecer dicho certificado como exportable. Esto nos permite exportar el certificado (clave pública) con la clave privada en un mismo fichero en formato .pfx.


Figura 1: Checkbox "Marcar clave como exportable" al importar un certificado digital.

Si no marcamos el check "Marcar esta clave como exportable" cuando se importar un certificado. En el momento de exportarlo del almacén de certificados del usuario actual: Botón derecho > todas las tareas > exportar...

Figura 2: Exportar certificado del administrador de certificados.
Vemos desmarcada la opción "Exportar la clave privada".

Figura 3: Intento de exportación de clave privada, opción deshabilitada, certificado no exportable.
Para poder exportar un certificado ya instalado en el almacén de certificados del usuario actual, el cual no podemos exportar junto con la clave privada. Podemos usar dos opciones.


Usando Jailbreak

Jailbreak nos permitirá abrir una consola de Microsoft (MSC) del alamacen de certificados de Windows y poder realizar la exportación de la clave privada estableciendo una nueva password.

Una vez descargado Jailbreak abrimos una consola cmd con el mismo usuario donde tenemos instalado el certificado y nos situamos en el raíz, ejecutamos el proceso por lotes "jbcert32.bat". Este nos lanzará una ventana del alamacén de certificados (certmgt.msc).

Figura 4: Ejecución de jailbreak para exportar certificados no exportables.

Ahora vemos como al intentar exportar el certificado nos permite exportar la clave privada.

Figura 5: Opción habilitada para exportar clave privada.

Elegimos un formato .pfx (este almacenará tanto la clave pública como la clave privada), podemos también marca la opción de "Exportar todas las propiedades extendidas".

Figura 6: Opciones disponibles para exportar el certificado en formato .pfx.

Podemos establecer una nueva contraseña para la clave privada, este sería el modo de restablecer la clave privada. Al finalizar el asistentte tendremos exportado un certificado .pfx que contiene ambas claves y volver importarlo en otro usuario o equipo.

Figura 7: Establecer una nueva contraseña para la clave privada.


Usando Mimikatz

Otra opción para poder exportar certificados no exportables de forma sencilla es con la herramienta Mimikatz (comentanda ya en este blog).

Una vez descargado Mimikatz abrimos una consola cmd y nos ubicamos en el raíz ejecutando "mimikatz.exe" (dependiendo la arquitectura del sistema operativo que tengamos win32 o x64).
crypto::capi
crypto::certificates /export
Esto buscará los certificados del alamacén del usuario actual y los exportará en codificación .der y formato .pfx. La contraseña por defecto que establece Mimikatz es "mimikatz" (sin comillas). 

Podremos cambiar la password importando el certificado y volviendo a exportarlo con la clave privada estacleciendo una nueva password (como se muestra en la figura 7).

Figura 8: Mimikatz - Exportar certificados no exportables.

Saludos!

28 junio, 2018

Volcado de las contraseñas de Windows con Mimikatz

Mimikatz es una herramienta archiconocida de cracking que nso permitirá la obtención de contraseñas de usuarios de un sistema. Nos volcará (dumping) las contraseñas den texto plano y los hashses de la SAM (Security Account Manager). que nos mostrará .

Hay mucha información al respecto sobre esta tool y como sacarle un buen partido. Más info: https://adsecurity.org/?page_id=1821

De todos modos, no había hablado de ella hasta ahora. Recientemente tuve que hacer uso de ella para conocer la password de unos usuarios locales creados en un sistema. Comprobé que aún seguía funcionando para Windows 10 como lo hacía para Windows 7 ya que el desarrollador fue actualizando esta herramienta.


Para un correcto funcionamiento Mimikatz debe ejecutarse con privilegios de administrador. Podremos ver en texto plano las contraseñas del resto de usuarios locales y de las credenciales de puntos de montaje que tengamos en el sistema.


Una vez descarguemos Mimikatz, abrimos una consola de comandos y nos situamos en el path donde lo hubiésemos descargado, ejecutamos el binario "mimikatz.exe" dependiento la arquitectura de nuestro sistema (32 bits o 43 bits). Para acceder al prompt que nos proporciona y escribimos.
privilege::debug
sekurlsa::logonpasswords
Figura 1: Ejecutando Mimikatz.

Finalmente obtenemos el resultado con las contraseñas de usuarios locales en texto plano.

Figura 2: Volcado de contraseñas en texto plano de usuarios locales de Windows.

Saludos!

25 junio, 2018

Crear un punto de acceso Wifi (WAP) compartido desde una conexión cableada Ethernet (IEEE 802.3)

En esta entrada se detalla el procedimineto de creación para una zona Wifi a través del adaptador de red cableada de Windows, compartiendo la conexión de este al adaptador inalámbrico que hará de WAP (Wireless Access Point) y puente de conexión.

Será necesario disponer de dos tarjetas de red, una conectada a través de una conexión cableada Ethernet 802.11 y otra tarjeta inalámbrica ya sea mediante un zócalo interno PCI o conectada por un USB.

El esquema que comentaré será para el siguiente ejemplo:

Un dispositivo inalámbrico con el que nos conectaremos (smartphone en este caso) a un punto de acceso que proporciona la adaptador Wifi y que a su vez este mediante una conexión compartida de Internet que proporciona nos proporciona el adaptador de conexión cableada Ethernet.

Figura 1: Esquema de conexión WAP Windows.

Para toda la configuración haremos uso de la herramienta de comandos Netsh (Network Shell) nativa en Windows.

Comprobamos las interfaces disponibles.
netsh wlan show interfaces

Figura 2: Netsh - Listar interfaces wlan.

Será necesario comprobar que el driver de la tarjeta de red inalámbrica admita red hospedada.
netsh wlan show drivers

Figura 3: Netsh - Conocer la compatibilidad de interface wlan para red hospedada.

Si el resultado es una "Red hospedada admitida: si". Procedemos a crear el hostednetwork con su SSID (Service Set Identifier) y contraseña de acceso.
netsh wlan set hostednetwork mode=allow ssid=nombre_wap key=password
Sustituyendo en cada caso el nomre y la contraseña que deseemos.

Figura 4: Netsh - Crear hostednetwork (WAP).

En este punto creamos el "puente de conexión" entre el adaptador inalámbrico (Conexión de área local* 4 en este caso) y el adaptador de red cableada (Ethernet).

En las propiedades de la interface Ethernet, pesataña de "Uso compartido", compartimos la conexión a Internet permitiendo que los usuarios que se conecten desde la red de la interface inalámbrica (Conexión de área local* 4).

Figura 5: Compartir conexión Internet entre dos interfaces de red (cableada e inalámbrica).

Iniciamos el hostednetwork.
netsh wlan start hostednetwork
Podemos consultar su estado.
netsh wlan show hostednetwork

Figura 6: Activar el hostednetwork (WAP).

Para comprobar su funcionamiento me conectaré desde un dispositivo smartphone. Vemos como estoy conectado al WAP con SSID zonasystem.

Figura 7: Conexión desde un terminal inalámbrico a la nueva red inalámbrica creada.

Vemos la MAC y dirección IP que nos está otorgando por DHCP. Generando la propia interface un ámbito de red 192.168.137.0/24. Cuando la red original es de un ámbito 10.0.0.0/24. Por defecto la propia interface crea su propia subred.

Figura 8: Comrobación de información de red de la conexión.

Comprobamos de nuevo el estado del hostednetwork de la wlan. Vemos como hay un dispositivo conectado o autenticado, se trata del smartsphone conectado anteriormente. Consultamos la tabla ARP (arp -a) para contrastar la información.

Figura 9: Verificación del cliente autenticado en el nuevo hostednetwork (WAP).

Ahora bien, si se trata de un sistema operativo Windows 10, todo lo anterior no tendría sentido. Windows 10 incorpora una característica para hacer esto de forma muy sencilla. Igualmente está bien conecer lo anterior para entender este funcionamiento.

De forma automática Windows configurará un WAP en el que podremos personalizar tanto el SSID como la passphrase.

Desde el nuevo panel de control de Windows 10 (Tecla Windows + i) > "Red e Internet" > "Zona con cobertura inalámbrica móvil". Tendremos que estar conectados a internet ya bien sea por que compartimos nosotros la conexión de un adaptador de red a otro o por que nos autenticamos en una red inalámbrica directamente. Habilitamos este modo y listo.

Figura 10: Crear WAP de forma sencilla "Zona con cobertura inalámbrica móvil" en Windows 10.

Saludos!

07 mayo, 2018

Nmap DHCP Discover: Conocer los servidores DHCP de una red

El protocolo de red DHCP (Dynamic Host Configuration Protocol) permite la asignación de configuración IP, como mínimo la dirección IP y máscara de red, en una arquitectura cliente/servidor. Si un equipo cliente tiene una configuración en su interface de red en modo automático, el cliente solicita una configuración IP de red si existe un servidor DHCP en la misma red este ofrece asignando un configuración de direccionamiento IP en el cliente que realizó la solicitud.

Figura 1: Esquema DHCP.

El protocolo BOOTP (Bootstrap Protocol) es utilizado por lo clientes para obtener una dirección IP automáticamente. Los puertos por defecto utilizados por BOOTP son: 67/udp (servidor) y 68/udp (cliente).

Proceso de funcionamiento DHCP en cliente/servidor
  1. El cliente solicita una IP difundiendo una mensaje DHCP DISCOVER á la subred local.
  2. Los servidores ofrecen una dirección IP (DHCP OFFER) y el resto de parámetros de configuraciones locales para el cliente (DNS, nombre de dominio, puerta de enlace, etc.), si esta está configurada para ser entregada en las opciones de configuración del servidor DHCP. Si ningún servidor DHCP responde al cliente, este envia un DHCP DISCOVER cada 0, 4, 8, 16 y 32 segundos y luego un intervalo aleatorio hasta un minuto. Si pasado 1 minuto no se recibe respuesta:
    • Si el cliente usa APIPA (Automatic Private IP addressing), el cliente se autoconfigurará con una IP (en el caso de Microsoft usará una IP de la red 169.254.0.0/24).
    • La interface del cliente no se inicia (IP 0.0.0.0/0).
  3. El cliente al recibir el DHCP OFFER indica a uno de los oferentes que acepta la IP recibida (DHCP REQUEST).
  4. El servidor envía una configuración DHCP ACK al cliente indicándole los términos de arrendamiento. A partir de ahora el cliente ya puede usar una IP asignada.
  5. El cliente solicita una renovación de la IP cuando pase la mitad del tiempo de conesión.
  6. El servidor le concede la renovación.
  7. El cliente libera la IP.

Figura 2: Esquema de funcionamiento DHCP cliente/servidor.

En la figura 3 se puede ver un ejemplo de captura de tráfico pcap de la solicitud cliente-servidor de un asignamiento automático de una dirección IP. Vemos los datagramas DHCP Discover, Offer, Request y finalmente ACK.

Figura 3: Captura pcap Wireshark del funcionamiento DHCP.


Conocer el servidor/es DHCP de una misma red en un cliente Linux

El fichero /var/lib/dhcp/dhclient.leases alamacena, entre otras cosas, las concesiones de direcciones que ofrecen al cliente los servidores DHCP.

Para descubrir los servidores DHCP, si la interface de red está en modo de asignación automática. Podemos liberar la dirección IP actual y volver a asignar una nueva configuración IP con la utilidad dhclient.
$ sudo dhclient -r eth0
$ sudo dhclient eth0
En la imagen de la figura 4 se puede ver como se crea el fichero dhclient.leases después de liberar (parámetro -r de dhclient) y volver a solicitar una nueva dirección IP (simplemente dhclient) a los posibles servidores DHCP de la misma red. En este caso el servidor DHCP es el mismo que la puerta de enlace.

Figura 4: Asignación de direción IP en un cliente Ubuntu.

En el log del sistema /var/log/syslog vemos la comunicación que fue realizada entre el cliente y el servidor DHCP.

Figura 5: Encontrando servidor DHCP en /var/log/syslog.


Conocer el servidor/es DHCP de una misma red en un cliente Windows

Un equipo cliente Windows poderemos liberar su configuración IP actual con el parámetro /release de la utilidad ipconfig y volver a solicitar una nueva configuración IP al servidor DHCP de esa red con el parámetro /renew.
ipconfig /release
ipconfig /renew
Figura 6: Liberación y asignación de nueva IP a un cliente Windows.

Con ipconfig /all se puede ver la configuración completa en las interfaces de red, al contrario que en sistemas Linux, Windows ya nos muestra el servidor DHCP que le ofreció la concesión de dirección IP.

Figura 7: Conocer servidor DHCP en cliente Windows.


Conocer el servidor/es DHCP con Nmap DHCP Discover

Si estamos en una red en la que sabemos que pueden exister múltiples servidores DHCP e incluso servidores DHCP Relay, existe una utilidad-script dentro de la utilidad Nmap que nos permitirá descubrir los servidores DHCP disponibles de la red.

Con -sU escaneamos UDP y -p escaneamos un puerto, que en este caso sería el 67 (67/udp). Pasamos el script "dhcp-discover" y a continuación el target que sería la dirección de red con su notación CIDR.
nmap -sU -p 67 --script=dhcp-discover <target>
En la imagen vemos el servidor DHCP marcado como el server identifier. 

Figura 8: DHCP Discover con nmap.

Estos scripts están ubicados en el directorio scripts/ de Nmap con formato propietario .nse (Nmap Scripting Engine) editables. Otra opción sería utilizar el script "broadcast-dhcp-discover".

En la website oficial de Nmap se detallan las diferencias entre los scripts .nse:

Saludos!
Entradas Relacionadas