TecnoHell: septiembre 2012

miércoles, 19 de septiembre de 2012

Registro de windows y software dedicado

A la hora de administrar una red local, entre otras muchas tareas que ya hemos visto, es posible que tengamos que controlar ciertos tipos de activades relativas a dispositivos conectados a las máquinas de los usuarios como dispositivos USB, teléfonos moviles, cámaras digitales, adaptadores WiFi, Bluetooth, etc. Los dispositivos conectados a través de puertos USB pueden acarrearnos muchos problemas de seguridad y fugas de información.

USB audioria. Device Class ID USBSTOR Unique Instance ID

En esta ocasión veremos la forma de auditar este tipo de dispositivos, historial de uso y toda la información relativa a cada dispositivo conectado, así como fechas. Lo veremos a través del registro de Windows y programas diseñados para tal efecto y como pueden ser USB History Dump, USBDeview y DeviceLock Plug and Play Auditor.

El Registro de Windows.

Cuando a una máquina se conecta un dispositivo USB, el administrador Plug and Play recibe una notificación, consulta el descriptor de dispositivos para obtener información tal como el fabricante, etc para encontrar un driver o controlador para el dispositivo o cargar un nuevo controlador. Todo esto queda reflejado en el archivo setupapi.log que registra información relativa a los dispositivos instalados, drivers y el historial de instalación y errores. También se almacenará la fecha y la hora en que el dispositivo de almacenamiento extraíble USB se conectó al sistema por primera vez:

[2010/01/21 12:33:16 644.7 Driver Install]
#-019 Buscando Id. de hardware: usbstor\diskkingstondatatraveler_2.01.00,usbstor\diskkingstondatatraveler_2.0,usbstor\diskkingston,usbstor\kingstondatatraveler_2.01,kingstondatatraveler_2.01,usbstor\gendisk,gendisk
#-018 Buscando Id. compatibles: usbstor\disk,usbstor\raw
#-198 Línea de comando procesada: C:\WINDOWS\system32\services.exe
#I022 Encontrado “GenDisk” en C:\WINDOWS\Inf\disk.inf; Dispositivo: “Unidad de disco”; Controlador: “Unidad de disco”; Proveedor: “Microsoft”; Fab: “(Unidades de disco estándar)”; Nombre de sección:”disk_install”.
#I023 Sección de instalación actual: [disk_install.NT]. Rango: 0×00000006. Fecha de controlador efectiva: 07/01/2001.
#-166 Función de instalación de dispositivo: DIF_SELECTBESTCOMPATDRV.
#I063 El controlador seleccionado se instala desde la sección [disk_install] in “c:\windows\inf\disk.inf”.
#I320 El GUID de clase del dispositivo se conservará como {4D36E967-E325-11CE-BFC1-08002BE10318}.
#I060 Se ha establecido el controlador seleccionado.
#I058 Se ha seleccionado el mejor controlador compatible.
#-166 Función de instalación de dispositivo: DIF_INSTALLDEVICEFILES.
#I124 Realizando instalación sólo de copia de “USBSTOR\DISK&VEN_KINGSTON&PROD_DATATRAVELER_2.0&REV_1.00703120512562&0″.
#-166 Función de instalación de dispositivo: DIF_REGISTER_COINSTALLERS.
#I056 Coinstaladores registrados.
#-166 Función de instalación de dispositivo: DIF_INSTALLINTERFACES.
#-011 Instalando sección [disk_install.NT.Interfaces] desde “c:\windows\inf\disk.inf”.
#I054 Se han instalado las interfaces.
#-166 Función de instalación de dispositivo: DIF_INSTALLDEVICE.
#I123 Realizando instalación completa de “USBSTOR\DISK&VEN_KINGSTON&PROD_DATATRAVELER_2.0&REV_1.00703120512562&0″.
#I121 La instalación del dispositivo de “USBSTOR\DISK&VEN_KINGSTON&PROD_DATATRAVELER_2.0&REV_1.00\0703120512562&0” terminó correctamente.

A continuación genera una entrada en el registro denominada Device Class ID en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR que identifica la clase del dispositivo.

Bajo esta clave se crea otra clave ID de formá uníca ó Unique Instance ID utilizando el número de serie del dispositivo o de no haberlo obtenido o encontrado, el sistema genera un identificador también único. Eso lo podemos identificar si el segundo carácter del identificador ( Unique Iinstance ID ) contiene el símbolo &.

Lo vemos:

En rojo tenemos el Device Class ID y en azul el Unique Instance ID.

En la ventana de la derecha del editor de registro vemos también:

USB audioria. Device Class ID USBSTOR Unique Instance ID ParentIDPrefix

Observamos que el ClassGUID 4D36E967-E325-11CE-BFC1-08002BE10318 lo tenemos también en el fragmento del archivo setupapi.log que tenemos más arriba.

Observad el ParentIdPrefix: 7&146f1415&0 que lo usaremos un poco más abajo.

Si realizamos una búsqueda en el registro por el valor de Unique Instance ID que más arribas tenemos marcado en azul: 0703120512562&0 vemos que lo encontramos en:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses

Enmarcado en rojo tenemos el valor de Unique Instance ID que más arribas tenemos marcado en azul: 0703120512562&0

Un poco más abajo tenemos otra subclave que contiene el ParentIdPrefix: 7&146f1415&0 :

Estas dos subclaves anteriores corresponden a Class GUID keys de disco y de volumen.

Tenemos otra clave HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

Aquí y con el valor de ParentIdPrefix, veremos en que volumen se montó el dispositivo USB. Solo tenemos que editar el valor binario para en la parte en Haxadecimal buscar el valor ParentIdPrefix mencionado:

En este caso no aparece el volumen. Puede ocurrir. En la mayoría si:

En este último caso, y buscando en la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR vemos que se trata de un dispositivo similar para el cual se ha creado un Unique Instance ID diferente:

Vamos ahora con las fechas y otras informaciones que nos pueda aportar las claves. Si volvemos a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses y elegimos la subclave que nos interesa, por ejemplo, las mismas marcadas en el ejemplo más arriba reseñado, hacemos lo siguiente: botón derecho del ratón y explortar en archivo .txt, si lo editamos encontraremos:

Software para auditar eventos de dispositivos USB.

Para esta tarea tenemos programas como USBDeview o DeviceLock Plug and Play Auditor que, además, puede auditar Firewire (IEEE 1394) y PCMCIA. Para usar en la consola DOS, tenemos también USB History Viewing. que, además, puede auditar Firewire (IEEE 1394) y PCMCIA. Para usar en la consola DOS, USB History Dump.

DeviceLock Plug and Play Auditor

Con DeviceLock Plug and Play Auditor podenos escanear una red local en busca de dispositivos en pouertos USB:

La información que nos aporta es mucha y como vemos más abajo tenemos dispositivos moviles Nokia, USB extraibles, etc y además información de si está en este momento en uso:

Para poder entrar en las máquinas a escanear, previamente hay que introducir las credenciales desde el menu File > Credentials..

Tenemos las siguientes columnas de información:

Description: la descripción del dispositivo que proporciona su fabricante.
Device Information: información adicional relativa al dispositivo proporcionada por el fabricante.
Connected to: interfaz donde está conectado el dispositivo (USB, FireWire oPCMCIA).
Class: la clase del dispositivo proporcionada por Windows.
Class description: la descripción de la clase del dispositivo proporcionada por Windows.
Present: indica si el dispositivo está actualmente conectado o no (Yes o No).
DeviceID: texto proporcionado por el fabricante que identifica un dispositivo en particular.
Driver: nombre del controlador que está controlando este dispositivo.

USBDView.

Al ejecutar el programa:

botón derecho del ratón en cualquiera de los items y Propiedades.

Como veis no tiene mucha historia:

USB History Dump.

Lo descargamos desde aquí: http://sourceforge.net/projects/usbhistory/files/usbhistory/release%20one/usbHistory.r1.i386.zip/download

Lo ejecutamos desde una consola DOS:

Aquí tenemos información relativa a:

Unique InstanceID
ParentIdPrefix
en que unidad se montó el dispositivo por última vez
Disk Stamp y Volume Stamp.

Del los ejemplos que hemos visto más arriba en el registro de Windows:

(6) — Kingston DataTraveler 2.0 USB Device

instanceID: 0703120512562&0
ParentIdPrefix: 7&146f1415&0
Driver:{4D36E967-E325-11CE-BFC1-08002BE10318}002
Disk Stamp: 05/13/2010 07:56
Volume Stamp: 05/13/2010 07:56

instanceID: 2008012500000000000002AB&0
ParentIdPrefix: 7&15730ba3&0
Driver: {4D36E967-E325-11CE-BFC1-08002BE10318}011
Disk Stamp: 04/15/2010 13:35
Volume Stamp: 04/15/2010 13:35

instanceID: 20080125000000000000039D&0
ParentIdPrefix: 7&154fd82a&0
Last Mounted As: \DosDevices\E:
Driver: {4D36E967-E325-11CE-BFC1-08002BE10318}003
Disk Stamp: 05/13/2010 12:03
Volume Stamp: 05/13/2010 12:03
—————

Nmap NSE Scripting. Parte 3

Seguimos con esta serie dedicada a los scripts nmap o nmap NSE. Ya vimos en la primera parte de esta serie dedicada a Nmap y, en concreto, al scripting NSE (Nmap NSE Scripting. Breve reseña para creación y ejecución scripts NSE nmap. Parte 1) nociones de como ejecutar un script, como interpretarlo, paso de argumentos, filtros, ejemplos, etc. Aprendimos también a analizar un script para ver su estructura y, de esta forma, aprender a modificar o crear nuestros propios scripts según nuestras necesidades (Nmap NSE Scripting. Breve reseña para creación y ejecución scripts NSE nmap. Parte 2).

En esta ocasión vamos a estudiar y practicar con los scripts SMB.

Scripts nmap SMB.

Existen muchas formas de auditar, descubrir, etc, todo lo relacionado con NETBIOS, por ejemplo, con el uso NBTSTAT, utilidades como NBTSCAN (Esas pequeñas utilidades. NBTSCAN) y comandos NET. De esta forma podemos descubrir nombres NETBIOS, SHARES o recursos compartidos, usuarios, etc. Pues bien, Nmap , tiene una serie de scripts NSE cuyo propósito es precisamente el descubrimiento y enumeración NETBIOS.

Y sin más dilación, vamos al lío.

SMB Security Mode.

smb-security-mode.nse

Security mode, nos informa sobre subprotocolos de autenticación que espera el servidor del recurso compartido. Esta información forma parte de Negotiate Protocol Response y puede tomar valores como:

Mode: USER security mode.
Pasword: ENCRYPTED password. Use challenge/response.
Signatures: Security signatures NOT enabled.
Sig Req: Security signatures NOT required.

Para el descubrimiento de Security mode usaremos:

nmap -P0 -n -sS -p445,139 –script=smb-security-mode.nse 192.168.1.23

Nmap done: 1 IP address (1 host up) scanned in 1.61 seconds

SMB OS Discovery

smb-os-discovery.nse

Dentro del los paquetes tipo Session Setup Andx Request, NTLMSSP_NEGOTIATE, parte del proceso de autenticación, tenemos una serie de campos, entre ellos Native OS.

Tenemos otro tipo de paquetes de respuesta: Session Setup AndX Response con información, también de Native OS. Esta es la que nos interesa, con información añadida de Service Pack, etc.

nmap -P0 -n -sS -p445,139 –script=smb-os-discovery.nse 192.168.1.23

Host script results:
| smb-os-discovery:
| OS: Windows Server 2003 R2 xxxx Service Pack 2 (Windows Server 2003 R2 5.2)
| Name: XXXX\XX-3
|_ System time: 2010-12-14 13:40:54 UTC+1

Nmap done: 1 IP address (1 host up) scanned in 1.59 seconds

SMB Enum Shares.

smb-enum-shares.nse

Corresponde a los paquetes del tipo Tree connect Andx Request. A esta peitición, el servidor o host objetivo del descubrimiento de recursos compartidos, enviará un paquete tipo Tree Connect AndX Response. Este último paquete puede quedar así o contener alguna información de error, por ejemplo Error: STATUS_BAD_NETWOTK_NAME o NT_STATUS_ACCESS_DENIED.

Usa el script smb-brute.nse mediante un include, e intenta conectar con una serie de recursos tales como BACKUP, WWW, cualquier letra para unidades compartidas (Z o Z$), etc. Por defecto usa el usuario guest / invitado o sin usuario.

nmap -P0 -n -sS -p445,139 –script=smb-enum-shares.nse 192.168.1.23

Nmap done: 1 IP address (1 host up) scanned in 3.36 seconds

Si tuviésemos algún usuario / password, podríamos usar argumentos para enumerar recursos compartidos para ese usuario. Lo vemos más adelante.

SMB Enum Users.

smb-enum-users.nse

Corresponde a los paquetes del tipo Name Query NBSTAT. A esta peitición, el servidor o host objetivo del descubrimiento responde con una lista de los usuarios del sistema mediante Name Query response

NBSTAT.

También usa, para obtener más información, los paquetes del tipo :

Session Request, to usuario
Negotiate protocol Request
LookupDomain request, usuario
Connect4 request
EnumDomains request
OpenDomain request
QueryDisplayInfo

con sus Response para cada uno de los Request.

De la lista anterior, los 5 últimos corresponden a SAMR (Security Account Manager Remote Protocol).

Por ejemplo:

Para una petición LookupDomain request, usuario, tenemos una respuesta LookupDomain request para informar del SID del usuario:

Probamos en un Windows 2000.

nmap -sU -sS –script smb-enum-users.nse -p U:137,T:139 192.168.1.30

|     Flags:       Password does not expire, Normal user account
|   HOST0FI\INTERNAT (RID: 1001)
|     Full name:   INTERNAT
|     Flags:       Password does not expire, Normal user account
|   HOST0FI\Invitado (RID: 501)
|     Description: Cuenta para acceso como invitado al equipo o dominio
|     Flags:       Password not required, Password does not expire, Account disabled, Normal user account
|   HOST0FI\USUARIO4 (RID: 1012)
|     Full name:   USUARIO4|_    Flags:       Password does not expire, Normal user account

Nmap done: 1 IP address (1 host up) scanned in 2.05 seconds

Bien, ya tenemos algunos usuarios. Vamos a usar los argumentos–script-args () para obtener, mediante smb-enum-shares.nse los recursos compartidos y tipos de acceso para un determinado usuario y con un password (smbpass) por defecto.

La prueba:

nmap -P0 -n -sT -p445,139 –script=smb-enum-shares.nse –script-args=smbuser=USUARIO1,smbpass=1234 192.168.1.30

Obtenemos para este caso:

SMB Enum Process.

smb-enum-process.nse

Enumeración de procesos de un host remoto u objetivo. Para ello debemos, nmediante argumentos, indicar el usuario administrador y password.

Hace uso de Remote Registry Service con requests del tipo:

QueryValue
OpenHKPD

El servidor con QueryValue response, enviará las información del Registrode Wwindows relativo a los procesos.

nmap -P0 -n -sT -p445 –script=smb-enum-processes –script-args=smbuser=Administrador,smbpass=TALYTALYTAL 192.168.1.30

Nmap done: 1 IP address (1 host up) scanned in 3.52 seconds

Si añadimos verbouse (-v ), obtendremos mayor información. Relativa al PID del proceso, Prioridad, etc:

Host script results:
| smb-enum-processes:
| PID PPID Priority Threads Handles
| —– —– ——– ——- ——-
|
|     0     0        0       1       0 `+-Idle
|     8     0        8      57     206 | `-System
|   216     8       11       6      33 |   `-smss
|   236   216       13      16     394 |     `+-WINLOGON
|   288   236        9      36     554 |      | `+-SERVICES
|   520   288        8      17     193 |      | | `+-spoolsv
|   548   288        8       4      71 |      | | +-sched
|   560   288        8      23     117 |      | | +-avguard
|   572   288        8       3      87 |      | | +-CdfSvc
|   588   288        8       9     212 |      | | +-cisvc
| 1116   588        4       4     141 |      | | | `-cidaemon
|   632   288        8       3      95 |      | | +-dsNcService
|   680   288        8       4     121 |      | | +-FreeSSHDService
|   724   288        8      13   34046 |      | | +-mysqld-nt
|   772   288        8       2      94 |      | | +-tcpsvcs
|   808   288        8       3      92 |      | | +-nvsvc32
|   864   288        8       6      67 |      | | +-RadeSvc
|   868   288        8       4      95 |      | | +-regsvc
| 1016   288        8       2      43 |      | | +-uphclean
| 1132   288        8       4     123 |      | | +-winmgmt
| 1156   288        8       2      52 |      | | +-mspmspsv
| 1168   288        8       7     401 |      | | `-svchost
|   300   236        9      15     282 |      | +-LSASS
| 1456   236        8      13     304 |      | `-explorer
|   240   216       13      10     352 |      `-csrss
|_ 396 1028        8       2      31 `-thebat

=======================================

Nmap NSE Scripting. Parte 2

En esta ocasión vamos a analizar uno de ellos para ver su estructura y, de esta forma, aprender a modificar o crear nuestros propios scripts según nuestras necesidades.

Esctructura de un script NSE.

Vamos a analizar un script, de los más simples, para ver su estructura.

Antes veremos, brevemente como están conformados.

Básicamente un script se compone de las siguientes secciones, no todas son necesarias y pueden no aparecer:

Cabecera.

id descripción corta, nombre del script que se muestra en la salida Nmap.
description: breve descripción del script, notas, etc. Caracter informativo.
author autor del script.
tags o categories categoría del script
license licencia (no es procesado)
dependencies / require scripts que necesita ejecutar antes, depende de ellos.

Funciones.

portrule / hostrule (regla)se espera unos datos para decidir si se cumple y ejecuta el script. Los datos pueden ser host y/o port.
action (acción) es la parte importante de script, es script propiamente dicho.

Como hemos dicho, no todos los campos se requieren para la escrutura del script. Los requeridos y necesarios son:

descriptiona
categories
portrule ó hostrule
action

Ejemplo. Estrucutura

Lo vemos con el script, muy básico, daytime.nse:

nmap nse script structura cabeceras funciones

Vemos de forma clara la cabecera con la description, author, license y categories. En este caso description nos cuenta que se trata del descubrimiento del servicio UDP Daytime (definido en el RFC 867), categories tiene discovery y safe (lo vimos en el la Parte1). Se trata pues de un script de:

discovery distintas pruebas de descubrimento en una red “interrogando” al los distintos servicios
safe modo inofensivo para el objetivo.

require nos “dice” que necesita comm.lua y shortport.lua que dos script Lua con funciones necesarias para nuestro script dytime.nse.

Vamos ahora con la parte importante del script.

portrule

En este script es portrule = shortport.port_or_service(13, “daytime”, {“tcp”, “udp”})

Hemos visto antes que en la línea 12 de script (require) hace uso de la librería shortport.lua, pues bien, esta librería contiene la función shortport.port_or_service con los argumentos entre paréntesis (13, “daytime”, {“tcp”, “udp”}) . Se usa para comprobar el objetivo. Se comprueba el puerto 13 del servicio daytime en los protocolos tcp o udp.

NOTA: La misma librería shortport.lua, nos explica el uso: usage portrule = shortport.port_or_service(22,”ssh”)…..

Como argumentos, en este caso, shortport.port_or_service soporta un puerto o lista de puertos, un solo servicio o lista, un solo protocolo o lista de protocolos.

Seguimos.

De ser cierto (True), la condición de comprobación de portrule, entonces se ejecuta la parte contenida en action

action

En actión se define una función que necesita la librería comm.lua, cuya llamada se realiza mendiante require. Se llama a la función exchange mediante comm.exchange(host, port, “dummy”, {lines=1, proto=port.protocol}).

La sintáxis es exchange = function(host, port, data, opts)

Daytime está hoy en día prácticamente en desuso, así que vamos a ilustrar el funcionamiento de action con el script daytime.nse, emulando mediante netcat (ncat) el servicio en nuestro BackTrack 4.0

los hacemos mediante la siguiente línea:

ncat -l 13 –send-only –exec “/bin/date”

Vemos el resultado:

Analizamos en resultado.

Vemos que como resultado se retorna el banner de los datos aportados por el servicio descubierto.

Modificando / creando un script.

Bueno, vamos a modificar e incluso crear un script tenendo como base daytime.nse. Lo haremos de forma muy básica. En próximos capítulos iremos avanzando y profundizando.

modificamos description = [[Retrieves the day and time from the UDP Daytime service.]]

description = [[Descubrimiento de serivicio ftp. Imprimimos un banner en la salida]]

dejamos categories y eliminamos los requerimientos, no necestiamos de ninguna librería auxiliar y modificamos el author

portrule

Creamos la función y realizamos las condiciónes necesarias para que se cumpla (True) y se ejecute action

portrule = function(host, port)
return port.service == “ftp” and
port.number == 21
and port.protocol == “tcp”
and port.state == “open

action

action = function()
return “El puerto 21 esta abierto. Pillin tienes el servivio ftp activo”

Respetmos los end y lo dejamos de esta forma es scritp que llamaremos efetepe.nse

description = [[
Descubrimiento de serivicio ftp. Imprimimos un banner en la salida
]]

author = “Alfonn”

license = “Same as Nmap–See http://nmap.org/book/man-legal.html”

categories = {“discovery”, “safe”}

portrule = function(host, port)
return port.service == “ftp” and
port.number == 21
and port.protocol == “tcp”
and port.state == “open”
end

action = function()
return “El puerto 21 esta abierto. Pillin tienes el servivio ftp activo”
end

El resultado:

Para entenderlo mejor, si cambiamos return port.service == “ftp” por return port.service == “ft” o el valor de cualquiera de las “condiciones” de cumplimiento de portrule veremos no imprime el banner. Si eliminamos una, si se imprime el banner.

Otro ejemplo y usando condiciones if()

description= [[ Ejemplo para ftp y ftp-data ]]
author =”alfon”
categories = {“safe”,”discovery”}

portrule = function(host, port)
if (
port.number == 20 or
port.number == 21 or
port.service == “ftp-data” or
port.service == “ftp”
and port.protocol == “tcp” )
then
return true
else
return false
end
end
action = function()
return “FTP puertos abiertos”
end