Embed Size (px)
Citation preview
Wireshark. Analizando Eventos SMB / CIFS - NetBIOS. Parte 1.alfonn 29-10-2009 GTM 1 @ 13:06
Ya vimos en el artículo Tshark . Detectando borrado de archivos de la red y otros eventos. , algunos eventosSMB a través de Wireshark, tales como borrado de
archivos y toda la información que se podía extraer capturando sesiones SMB, etc. A petición de lectores que me piden este artículo usando Wireshark en
vez deTshark, aprovecho, también, para explicar y avanzar un poco más en los protocolos SMB, CIFS Y NETBIOS .
SMB (Server Message Block), básicamente se trata de un protocolo que permitre compartir archivos, impresoras, puertos serie, etc entre hosts
conectados en red. Pertenece a la capa de aplicación OSI y es un protocolo del tipo cliente-servidor. SMB se encuentra por encima de NETBIOS, que es la
que se encarga de la resolución de Nombre host / IP.
CIFS (Common Internet File System) es una implementación que supone, también, una evolución de SMBpara el sistema Windows en sus versiones más
modernas. Al tratarse de un protocolo de alto nivel, necesita apoyarse en protocolos de transporte como NETBIOS. Al ser una evolución e implementación de
SMB, es también un protocolo cliente-servidor.
La forma de trabajar de CIFS, como envía paquetes request de cliente a servidor, como responde, etc, etc.
Todo esto lo veremos, como siempre, con ejemplos de capturas Wireshark.
Para, en este artículo, entender SMB/CIFS, vamos a centrarnos, en las capturas, a todo lo referente a estos protocolos y las trazas quese ven involucradas.
Comenzamos con la siguiente captura con los filtros adecuados para la ocasión y observemos el intercambio de paquetes entre CLIENTE (192.168.1.30 )
Y SISTEM (192.168.1.5), los dos host involucrados en una sesión en la que SISTEM se conecta a CLIENTE para usar el recurso compartido COMPARTIR y usa
los archivos de dicha carpeta editándolos, borrando o creando un nuevo.
Parte de la captura es la siguiente:
Paquete 7. NAME QUERY NB CLIENTE (00)Comienza la sesión con una petición de de resolución de nombre de host mediante Name query NB CLIENTE<00> Esto se hace usando NetBios mediante
broadcast (192.168.1.255).
Responde 192.168.1.30 con Name query response NB 192.168.76.1
NOTA: Observad que aparcece la IP 192.168.76.1 en vez de 192.168.1.30 que sería lo lógico. Esto es así porque el host CLIENTE tiene otra interface de red
que corresponde a VMWare.
Name query NB y Name query response usan el puerto 137y UDP.
Vamos a hora a fijarnos en la ventana de protocolos (imagen de arriba). Observamos como hemos indicado ya los puertos usados (137) y nos centramos
en NetBIOS Name Service.
Y para tener una referencia tenemos aquí el formato de paquete de Name Service de NETBIOS:
Y, a continuación el Header o cabecera:
Y ahora a destripar los datos.
Tenemos una sere de campos y Flags:
NAME_TRN_ID ó Transaction ID. (0x8022) Identificación del proceso de resolución de nombre.
Opcode. código de tipo de paquete. Se divide a su vez en dos campos: Response (0) en este caso inica un message is a query y Opcode propiamente
dicho (0) que indica un query.
Flags (0x0110) :
o Truncated (0). Indica no truncado
o Recursion desired (1) se encuentra activado e indica que se trata de un query o pregunta recurrente.
o Broadcast (1) está activado e indica que la resolución se realiza a través de un paquete broadcast.
RCODE. Muestra un código con el resultado de la petición name query (paquete 7 de la captura wireshark). Lógicamentre no aparece aquí, aparecerá en
el resultado o Name query response.
QUESTION ENTRIES ó Questions. (1) Número entero que indica en número de entradas coincidente con una pregunta por nombre.
ANCOUNT ó Answer RRs (0). Indica número de recursos que se tratan de una respuesta, en este caso obviamente es 0 porque es una pregunta.
ARCOUNT ó Additional RRs. (0) BNúmero indicando recursos adicionales.
Vemos también el campo Queries que nos da infomación de la pregunta o consulta solicitada, en este caso preguntamos por la máquina CLIENTE.
Y hasta aquí la primera parte en la que hemos tratado de destripar, sacar información, del paquete Name query NB, paquete nº 7 de nuestra captura. En
los siguientes cápitulos veremos la resupuesta o Name query response (paquete 11) de la captura.
Wireshark. Analizando Eventos SMB / CIFS - NetBIOS. Parte 2.alfonn 03-11-2009 GTM 1 @ 18:01
Seguimos avanzando en el análisis de eventos SMB / CIFS y NETBIOS. Ya vimos en la primera parte de esta serie (Wireshark. Analizando eventos SMB / CIFS - NetBIOS. Parte 1.) algunos eventos SMB, a través deWireshark, involucrados en una conexión de un host
a otro para usar un determinado recurso compartido. En el primer artículo nos centramos en la petición de resolución de nombre de host mediante Name
query NB. En esta segunda parte la dedicaremos a la respuesta Name query response NB.
volvemos a la captura de la Parte 1 de la serie:
Paquete 11. NAME QUERY RESPONSE NB 192.168.76.1 (00)Comienza la sesión con una petición de de resolución de nombre de host mediante Name query NB CLIENTE<00> Esto se hace usando NetBios mediante
broadcast (192.168.1.255).
Responde 192.168.1.30 con Name query response NB 192.168.76.1
NOTA: Observad que aparcece la IP 192.168.76.1 en vez de 192.168.1.30 que sería lo lógico. Esto es así porque el host CLIENTE tiene otra interface de red
(virtual) que corresponde a VMWare. De cualquier forma, vemos que la NIC física está indicada en la captura en la columna Source: (192.168.1.30)
Al igual que Name query NB, response también usa el puerto UDP 137:
Vemos muchas más diferencias respecto a Name query NB, vamos a verlas.
Antes que nada nos fijamos en el campo Transaction ID. (0x8022) que ya vimos que se refería a la identificación del proceso de resolución de nombre. Pues
esta identificación es la misma (0x8022) tanto para Name query NB como para Name query response. Esto es así para indentifica un mismo proceso,
proceso de petición y de respuesta. Paquetes 7 y 11.
Vamos ahora al resto de campos.
... antes que nada la referencia de la cabecera:
Opcode. código de tipo de paquete. Se divide a su vez en dos campos: Response (1) en este caso inica un Message is a
response y Opcode propiamente dicho (0) que indica un query.
Flags (0x8500) :
o Truncated (0). Indica no truncado. Para establecer si el contenido es mayor que 576 bytes.
o Recursion desired (1) se encuentra activado e indica que se trata de un query o pregunta recurrente.
o Broadcast (0) desactivado, indica que no es un paquete broadcas y no se usa.
Se añaden otros flags / campos que son los siguientes:
o Authoritative (1).
o Recursion available (0)
o Reply code (0) ó RECODE Muestra un código con el resultado de la petición name query (paquete 7de la captura wireshark). En este caso (0)
indicando No error. Otros códigos son:
0 indica que no hay error
1 error de formato
2 error de servidor
3 error de nombre
4 solicitud no compatible.
5 por politicas de servidor, denegación de respuesta.
6 Active error.
7 error de nombre. Conflico.
Seguimos:
QUESTION ENTRIES ó Questions. (0) Número entero que indica en número de entradas coincidente con una pregunta por nombre. En este caso 0. Se
trata de una respuesta.
ANCOUNT ó Answer RRs (1). Indica número de recursos o registros que se tratan de una respuesta.
NSCOUNT ó Authority RRs (0). Número de registros de la sección authority de Name Serivce packet
ARCOUNT ó Additional RRs. (0) Número indicando recursos adicionales.
El siguiente campo tratándose de un paquete Name query response NB, se llama Answers, al contratio deQueries, que veíamos en el capítulo anterior
para un paquete Name query NB.
Este campo contiene la respuesta a la petición del Name query NB. REsponde con el nombre de host y su IP. Aquí vemos 3 IPs que corresponden a las tres
interfaces de red: 2 VMWare y una física 192.168.1.30:
Básicamente y de forma sencilla. En el procedimiento de resolución del nombres, que se basan en broadcast, en servidor o en ambos, se pueden usar:
broadcast a la red,
usando NETBIOS: NBNS ó WINS (sistemas Windows).
por ello, cada host se puede configurar:
solo usando broadcast
solo NBNS
primero broadcast y seguidamente NBNS en el caso de no respuesta al broadcast.
lo contrario de lo anterior. Primero NBNS y en caso de no respuesta broadcasting.
Eso lo vemos en nuestra captura en los campos:
b-node (00). cuando solo se usa broadcast a la red
p-node (01). cuando solo se usa NBNS
m-node (10). cuando se usa primero broadcast y en caso de no obtenerr respuesta se usa NBNS.
h-node (11). cuando primero se realiza mediante NBNS y en caso de no respuesta broadcasting.
Vemos en nuestra captura que las 3 respuestas obtenidas para las tres IPs, se realizan bajo b-node (00)o broadcast a la red.
Apreciamos también otras informaciones como TTL (Time To Live), Type NB (Servicios de nombres de NETBIOS), Class (Resource Record Class), en este
caso Internet Class.
-----------------------------------
En el siguiente capítulo veremos los siguientes paquetes correspondientes a ICMP Echo request y Echo reply para obtención de la dirección MAC, el
establecimiento de conexión con el recurso, ngoaciación del protocolo Request y Response (SMB), etc.
Wireshark. Analizando Eventos SMB / CIFS - NetBIOS. Parte 4.alfonn 03-02-2010 GTM 1 @ 16:43
En los tres primeros capítulos de esta serie dedicada a los eventos SMB / CIFS - NETBIOS, hemos visto los mensajes del tipo Name query NB, Name
query response NB y los pasos previos a Negotiate protocol Request y Negotiate protocol Response. Estos pasos, recordad, eran:
Echo ping request
Echo ping response
Session request, to....
Positive session response
En esta cuarta parte vamos a estudiar:
Negotiate protocol Request y
Negotiate protocol Response
En el anterior artículo nos quedamos en session request y possitive session response. De esta forma se enviaba una petición de sesión y la
confirmación "positiva" en caso de que todo esté correcto.
Es el momento entonces de comenzar, una vez establecida la conexión, el diálogo. Este comienza enviando un paquete del tipo Negotiate protocol request
(0x72), en el cual envía una lista de dialectos Requested Dialects que entiende, con los que establecer diálogo con la otra parte (para nosotros, CLIENTE).
NOTA: Vamos a ver de forma rápida este paso previo a la autentificación con el servidor del recurso y resto de pasos más importantes.
Vemos en la captura que envia una lista con 6 dialectos:
PC NETWORK PROGRAM 1.0
LANMAN1.0
Windows for Workgroups 3.1a
LM1.2X002
LANMAN2.1
NT LM 0.12
Observamos la captura correspondiente. Paquete 26, que, aunque no se corresponde a la captura de los anteriores capitulos, es exactamente el mismo
proceso.
El host identificado como SISTEMAS (192.168.1.5) envía a 192.168.1.30 CLIENTE un paquete, en la captura el 26.
Vemos que, como en casos anteriores, se le asigna un número de proceso en Process ID (65279) y dos campos más que son:
Tree ID que está a 0 puesto que aín no se a establecido la conexión al requros compartido.
User ID también a 0 por la misma razón
Resto de campos a 0.
En el siguiente paquete (27) vamos a ver como la otra parte, el servidor del recurso compartido (CLIENTE), responde con un paquete del tipo Negotiate
Protocol (0x72) en este caso Response, en el cual responde a la petición anterior (paquete 26 Negotiate protocol request) de que el dialecto
seleccionado es el número 5:NT LM 0.12
Observad que en el paquete 26 del Request, el dialecto NT LM 0.12, estaba en la posición 6. En la respuesta se ordena y asigna el número 5.
Vemos también que el campo Process ID ó identificador del proceso, es el mismo (65279) que el anterior.
En Capabilities, se envia información sobre el servidor del recurso compartido.
Security mode, nos informa sobre subprotocolos de autentificación que espera el servidor del recurso compartido.
-----------------------------------------------------------------
Para la siguiente entrega estudiaremos la negociación de autentificación con el servidor del recurso.
Wireshark. Analizando Eventos SMB / CIFS - NetBIOS. Parte 5.alfonn 09-03-2010 GTM 1 @ 17:27
En los cuatro primeros capítulos de esta serie dedicada a los eventos SMB / CIFS - NETBIOS, hemos visto los mensajes del tipo Name query NB, Name query response NB, pasos previos a Negotiate protocol y Negotiate protocolRequest y Negotiate protocol Response . Estos pasos, recordad, eran:
Echo ping request Echo ping response Session request, to....
Positive session response Negotiate protocol Request Negotiate protocol ResponseEn esta ocasión vamos a ver la negociación de autentificación con el servidor del recurso.Los procesos de los que vamos a hablar hoy lo podemos ver en el siguiente gráfico:
Los dos primeros los vimos en el anterior capítulo, los enmarcados en cuadro rojo los veremos hoy.
Se trada del proceso de negociación de autentificación que es iniciado (paquete 28) or el host identificado como SISTEMAS (192.168.1.5) que envía a
192.168.1.30 CLIENTE un paquete Session Setup Andx Request, NTLMSSP_NEGOTIATE.
Cada paso corresponde a los paquetes 28,29,30 y 31 que pasamos a describir según la siguiente captura:
El objetivo es la autentificación usuario / contraseña o credenciales contra el servidor del recurso. Por defecto son tomadas las credenciales con que, en
este caso, SISTEMAS (192.168.1.5) se conectó a su sistema. Se negocia también que la contraseña se cifrará. La contraseña forma parte del
campo Security Blop.
En la captura paquete número el 28 vemos los detalles.
En este paquete, a parte de otros valores de campos que ya hemos visto, el host que inicia el proceos de negociación, envia datos como:
Versión S.O. Windows 2002
Service Packs Service Pack 3 2600
Administrador LAN Nativo Windows 2002 5.1
También envía las capacidades soportadas establecidas en Capabilities. Podeis desplegar en Wireshark este campo para ver las capacidades que
envia SISTEMAS.
Seguimos con el siguiente paquete.
Responde 192.168.1.30, paquete 29, con Session Setup Andx Request, NTLMSSP_CHALLENGE.
El host receptor CLIENTE (192.168.1.30 ) comprueba las credenciales si no es correcto, se envia un código de error. Si es correcto, se envia el UID que
SISTEMAS (192.168.1.5) que debe usar en el proceso.
En este caso la etiqueta Error: STATUS_MORE_PROCESSING_REQUIRED no es un error es si, significa quenecesita más procesamiento, hay más
información de autentificación que transmitir.
Vemos en el paquete 29 que ya se establece un UID (User ID: 2048), en el paquete 28 estaba a 0. El resto de paquetes llevarán establecido User ID:
2048.
El paquete 30 es la segunda solicitud Session Setup Andx Request, del tipo NTLMSSP_NEGOTIATE y comprende la parte final de la autenticación de
contraseña y contiene el nombre de usuario del administrador.
En este paquete se envia también información sobre:
Nombre de la máquina
Nombre Netbios
Usuario
El campo Byte Count indica el tamaño de Security Blop.
En todos los casos observamos que el tipo de comando SBM es Session setup (0x73) lo vemos claramente en las capturas.
El paquete 31 indica el final del SMB Session setup para la autentificacióncon el servidor del recurso.
Observad el campo Action 0x0000, está desactivado e indica que no se ha logeado como guest.
Observad también el NT Status: STATUS_SUCESS (0x00000000). Se trata de que la autentificación se realizó de forma exitosa.
Vemos los campos de los que hemos hablado en los paquetes o frames 28 y 29:
Paquete 28.
Paquete 29.
----
En la sexta parte veremos los paquetes del tipo Tree Connect Andx Reques, Response .....
