martes, 15 de julio de 2014

Configuración de red con netsh

Viendo lo fácil que es establecer la configuración de red de un equipo en Linux, quise mirar cómo se podría hacer lo mismo en Windows. Al final es un poco más engorroso (o eso me parece a mí), y la sintaxis de los comandos es un poco más compleja.

Aquí entra en juego nuestro amigo netsh, la utilidad de línea de comandos del sistema operativo de Microsoft para trabajar con las opciones de red. En mi caso, como estoy con el portátil de la oficina a casa y de la casa a la oficina, y tengo que estar cambiando las configuraciones de red de mi equipo a cada rato, quise hacer esto un poco más rápido.

Lo básico, es establecer la dirección IPv4, la máscara de red, la puerta de enlace, y los DNS primario y secundario. Ésto, con netsh, sería de la siguiente manera:

#Para listar las conexiones de red
netsh interface show interface

#Establecemos la dirección IP, la máscara de red y la puerta de enlace por defecto
netsh interface ip set address "Conexión de área local" static 192.168.2.10 255.255.255.0 192.168.2.1 1

#Si queremos establecer otra dirección IP para el equipo
netsh interface ip add address "Conexión de área local" 10.168.2.128 255.255.255.0

#Establecemos el DNS primario
netsh interface ip set dnsservers "Conexión de área local" static 8.8.8.8 primary

#Establecemos el DNS secundario
netsh interface ip add dnsservers "Conexión de área local" 8.8.4.4 index=2

Podríamos crearnos un script, para ejecutar todos los comandos en lote. Las consideraciones a tener en cuenta serían que hay que ejecutar este script con la línea de comandos en modo Administrador, y a la hora de generar el script (un .bat por ejemplo), mejor seguir este truco, ya que no se traga bien las tildes y demás caracteres "extraños".

Espero que os haya servido de ayuda ;)

Referencias:

viernes, 4 de abril de 2014

ARP

Address Resolution Protocol. No voy a entrar en detalle a explicar el protocolo. Para ello, os dejo las siguientes referencias, que son bastantes claras y sin muchos rodeos:



Ya en IPv6 no tenemos ARP, sino su equivalente, NDP (Neighbor Discovery Protocol).

Lo que sí me gustaría destacar de ARP es lo siguiente:

  1) Consiste simplemente en mensajes de solicitud-respuesta (request-reply). El request siempre es en modo broadcast, preguntando por la MAC address del host destino.



El reply es en modo unicast, donde el host destino responde con su MAC address al host origen.



  2) Los sistemas guardan una caché ARP para no estar enviando requests todo el rato. Para las entradas de tipo dinámico, una vez expira el periodo de timeout predeterminado, el sistema eliminaría dicha entrada, la cual solo se volvería a añadir en el caso de recibir el reply correspondiente.



  3) ARP es un protocolo sin estado. Independientemente de si se ha enviado un request o no, si se recibe un reply, se actualiza dicha entrada en la caché. Tampoco existe autenticación alguna, así que cualquiera podría enviar replies "spoofeados", conocido como gratuitous ARP.


Básicamente, de estas características se aprovecha el ARP spoofing, que luego se puede usar para sniffing, man-in-the-middle, DoS o mac flooding. Dicho ésto, os pongo los siguientes enlaces:



Como ya hemos dicho, en IPv6 tenemos NDP, y por lo tanto, su ataque equivalente:


Existen propuestas para mitigar estos ataques, como puede ser el cifrado de la comunicación ARP, trabajar con entradas estáticas, la existencia de un servidor ARP central en lugar de mantener una caché en cada host; o mantener una correlación de solicitudes y respuestas, o monitorización de tramas ARP mediante SNMP en los switches, pero creo que ninguna se ha implementado a gran escala debido a los costos añadidos que tiene.

También tenemos herramientas como:

  • PatriotNG - permite la monitorización de cambios en la caché ARP (en entornos Windows).

jueves, 13 de marzo de 2014

A la caza de malware con Sysinternals

En el vídeo de arriba, Mark Russinovich, miembro técnico de la división Cloud y Enterprise de Microsoft, además de claramente reconocido experto en sistemas Windows, nos cuenta las novedades de algunas de las herramientas que conforman la suite de Sysinternals, y cómo le han servido a él para encontrar y eliminar malware en distintos casos a los que se ha enfrentado. Todos estos casos los desmenuza y los explica uno a uno en su blog, donde además tiene otros artículos muy interesantes de cómo ha resuelto problemas de funcionamiento de equipos Windows y explicaciones bastante detalladas de la arquitectura de un sistema Windows.

A modo de resumen, he querido destacar los puntos que indica el autor a tener en cuenta a la hora de embarcarnos en la tarea de hacer frente al malware (extraído del vídeo) y que además Mark hace mención en sus diapositivas

Pasos a seguir para limpiar malware

  • Desconectar el equipo de la red. Puede darse el caso en el que un "bicho" hace que se descarguen n "bichos" más, y así, perder la pista de lo que estabas investigando en un principio. 
  • Identificar procesos y drivers maliciosos. 
  • Termniar procesos identificados como para "eliminar". Una curiosidad que tiene que ver con este punto, es tener cuidado con los procesos "colegas". Ésta es la terminología que usa el autor para referirse a un conjunto de procesos que se ayudan entre ellos, de forma que si matamos a uno de ellos, los otros se encargan de lanzar uno nuevo como contramedida. Para evitar esto, nos recomienda que usemos la función de "Suspender" antes de "matar". 
  • Identificar y eliminar entradas maliciosas en "autoarranque/inicio automático". 
  • Borrar archivos malware del sistema de ficheros. 
  • Reinciamos y repetimos hasta ver que no se repiten los patrones encontrados anteriormente.

¿Y qué estamos buscando?

Básicamente buscamos procesos que cumplan los siguientes criterios, pero antes que nada, me gustaría destacar la diferenciación que hace el autor entre procesos e hilos:

  • Un proceso en Windows es un contenedor que almacena la imagen de un archivo ejecutable. Está representado por un objeto proceso de kernel y Windows emplea ese objeto y sus estructuras de datos asociadas para almacenar y realizar un seguimiento de la ejecución de dicha imagen. 
  • Un proceso incluye uno o más hilos que realmente ejecutan el código, y están representados por objetos hilo de kernel. Técnicamente, los que corren son los hilos, y no los procesos. 

Fuente: https://blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx 


Dicho ésto, enumeramos esos criterios que hay que tener en cuenta para "la caza" en los procesos analizados:
  • No tienen icono. 
  • No tienen descripción o nombre de compañía. 
  • Imágenes de procesos Microsoft no firmados. 
  • Ubicados en el directorio Windows (%SytemRoot%) o en el perfil del usuario (%userprofile%)
  • Están "empaquetados". Respecto a este punto, hay una serie de artículos en SecurityByDefault muy interesantes de Abraham Pasamar acerca de qué son los crypters, cómo funcionan y qué técnicas usan para llevar a cabo la evasión de antivirus. Y en concreto, en el primero de ellos, en la introuducción, menciona lo siguiente:

Crypters vs. packers 

Hay que puntualizar que en algunos entornos se habla indistintamente de 'crypters' y 'packers', pero en realidad son cosas distintas. El objetivo de un packer es 'empaquetar' o 'comprimir' el archivo ejecutable. Sería como usar un ZIP pero sin perder la estructura de un archivo ejecutable PE (Portable Executable). El objetivo del 'crypter' es 'cifrar' el ejecutable. Sería como usar PGP o TrueCrypt, pero sin perder la estructura PE. 

Fuente: http://www.securitybydefault.com/2013/07/introduccion-los-crypters.html

Éstos son los procesos a los que se refiere Mark, tanto empaquetados como cifrados, o ambos.

  • Incluyen URLs extrañas en sus Strings. 
  • Tienen conexiones TCP/IP abiertas a ubicaciones no esperadas. 
  • Incluyen DLLs o servicios sospechosos. 

No siempre un proceso que tenga estas características corresponde a malware, pero sí en la mayoría de los casos. Espero que os haya parecido interesante y hasta la próxima!!!