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!

01 agosto, 2017

Ejecutar scripts o aplicaciones al inicio del sistema

Esta es una entrada muy básica, pero que decidí escribirla para hacer referencia a ella en futuras entradas con el fin de evitar repiticiones de estas acciones en las mismas.

Tanto en sistemas Windows como Linux se pueden automatizar scripts o aplicaciones para que se inicien en el arranque del sistema o en el inicio de sesión de usuario.

Comentaré varias opciones para realizar este proceso, tanto en sistemas MS Windows como en distribuciones Linux.

En Windows 

Se pueden añadir ficheros binarios o scripts en el inicio del sistema o inicio de sesión de usuario de diferentes maneras.
  1. Creando un valor de cadena y estableciendo la ruta del script batch en la clave de registro: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run.
  2. Ubicando el script o binario ejecutable del software en la carpeta para la ejecución de inicio del sistema: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp.
  3. Mediante una directiva local de Windows (GPO): https://technet.microsoft.com/es-es/library/cc770556(v=ws.11).aspx.
  4. Con una tarea programada de Windows (taskschd.msc), estableciendo como desencadenador el "Inicio del sistema" o "Inicio de sesión" y en acciones introducir el path de ubicación del script .bat. https://technet.microsoft.com/es-es/library/cc748841(v=ws.11).aspx

En Linux 

Al igual que Windows, hay varias formas de hacer que un script o aplicación se ejecute en el inicio del sistema. Una de ellas es haciendo uso del fichero /etc/rc.local. Este fichero se ejecuta en el inicio de sesión del usuario. Se ejecuta en el último nivel una vez iniciado el sistema.

Establecemos permisos de ejecución al fichero o programa
sudo chmod +x [script.sh_o_aplicacion]
Añadimos el path de ubicación del fichero como una línea al final del fichero /etc/rc.local. De este modo se ejecutará automáticamente en los próximos inicios de sesión. Esto lo haremos desde un superusuario (root) que tiene permisos de escritura sobre el fichero /etc/rc.local.

También se podría hacer de forma manual editando el propio fichero /etc/rc.local.
sudo su
echo [path_script.sh_o_aplicacion] >> /etc/rc.local
Otra opción sería establecer el script.sh o el programa como un servicio del sistema a través del directorio /etc/init.d/. De este modo se iniciará según el sistema se inicie, como si fuese un servicio más.
Movemos el script.sh o programa al directorio /etc/init.d/. Establecemos permisos de ejecución sobre el fichero y actualizamos el update-rc.d.
sudo mv [path_script.sh_o_aplicacion] /etc/init.d/
sudo chmod +x /etc/init.d/[script.sh_o_aplicacion]
sudo update-rc.d [script.sh_o_aplicacion] defaults
Si estamos trabajando con un script .sh y al ejecutar el último comando de actualización de update-rc.d nos diese algún/os error/es del tipo "insserv: missing ...".
Tendríamos que referenciar en modo de comentarios los siguientes parámetros en el propio fichero del script.
#!/bin/bash
### BEGIN INIT INFO
# Provides:           descripción
# Required-Start:     $syslog
# Required-Stop:      $syslog
# Default-Start:      2 3 4 5
# Default-Stop:       0 1 6
# Short-Description:  descripción
# Description:        descripción
### END INIT INFO
[SCRIPT AQUÍ]
Saludos!

29 julio, 2017

Fuerza bruta en ficheros kdbx de KeePassX

KeePassX es un aplicación para la gestión de contraseñas. Es un derivación de KeePass Password Safe pero en su versión GNU GPL. Creando un nuevo almacén (fichero base de datos), al que vincularemos con una contraseña maestra, podemos guardar usuarios y contrasañeas asociadas a determinados servicios, estos "almacenes" se guardan en un fichero .kdbx en el caso de KeePassX y ficheros .kdb en el caso de KeePass. De este modo con acordarnos de una única contraseña tendremos acceso a las de más.
Si tenemos la contraseña maestra podemos desempatear el fichero de la base datos y cargarlo correctamente en la aplicación para su uso y visualización de contraseñas.

La base de datos se cifra en AES o Twofish usando una clave de 256 bits. La base de datos KeePassX (kdbx) es compatible con KeePass Password Safe.

Aplicando técnicas de ataque brute-force en la que le pasaremos un wordlist, podemos extraer la contraseña maestra y tener acceso al fichero kdbx en este caso.

Una de las herramientas utilizadas será KeeCracker. Le pasaríamos un diccionario o wordlist, en este caso crearé uno con palabras concretas como prueba de concepto.

Figura 1: Fichero wordlist para PoC

Ejecutamos en una consola el binario KeeCracker.exe en el que le pasamos el diccionario con el argumento -w (lista.txt) y seguidamente la base de datos .kdbx de KeePassX.
KeeCracker.exe -w [fichero_wordlist] [fichero_kdbx]

Figura 2: PoC de KeeCracker

Como vemos la password maestra de la base de datos kdbx a sido encontrada. Dependerá del wordlist que tegamos pueda ser encontrada la password establecida en la base de datos kdbx. Esto influirá lógicamente, como todos los ataques de fuerza bruta, en la complejidad de la contraseña maestra que se establezca en la base de datos.

KeeCracker también puede ser usado con John the Ripper de forma incremental. Por ejemplo:
john --incremental --stdout | KeeCracker -w - KeePassDb.kdbx
Saludos!

18 julio, 2017

Automatizar copias de seguridad FTPS con WinSCP y Taskschd

Hace tiempo que quería comentar ya este tema, como hago mis copias de seguridad.

No hace falta decir que es recomendable y tendría que ser una práctica rutinaria realizar backups de la información importante. Sobretodo para no echarnos las manos a la cabeza llegado el momento de recuperar cierta información que por cualquier situación hubiésemos perdido.

Se pueden realizar copias de seguridad de una manera u otra. Ya sea copiando directamente la información algún medio extraíble, subiéndola algún servicio de almacenamiento cloud, copias redundantes en ambos medios, etc. A su vez, cuantas más medidas de seguridad se tomen para cada una de estas técnicas, más segura estará la información, pero también más "pasos" habrá que desencadenar para llegar a ella.

En este caso expondré la forma en la que personalmente realizo mis copias de seguridad. Intento no utilizar, siempre que sea posible, aplicaciones locales o almacenamientos cloud de terceros bien conocidos como pueden ser: GoogleDrive, OneDrive, Dropbox, etc. Ya que actualmente son los servicios más extendidos y usados, por lo que tienen un véctor de ataque continuo pero a su vez son servicios que están constantemente actualizándose, lo que los hacen ser "insuficientemente seguros".
En el caso de usar un servicio de terceros de almacenamiento cloud habría que intentar contratarlo en una empresa no tan extendida pero de confianza.

En mi caso tengo una carpeta con toda la información a respaldar, esta carpeta está ubicada en un disco duro extraible protegido con un cifrado Bitlocker. Es decir, que cuando conectamos el disco duro extraible a un puerto USB del equipo tenemos que introducir una password para desbloquearlo y así poder acceder a la información.  

Primera medida de seguridad es el disco duro extraible por lo que nunca tengo la información en el disco local del sistema ni en un segundo disco conectado directamente a ningún puerto SATA de la placa base.


Segunda medida de seguridad es el cifrado por Bitlocker.
De este modo puedo llevarme el disco duro extrabible a cualquier parte y conectarlo a cualquier equipo con un sistema operativo Windows que admita Bitlocker, sin recurrir a ningún software de terceros para el cifrado del disco, por que como ya dije, prefiero utilizar mecanismos propios de los sistemas operativos y así garantizar la disponibilidad de la información en un entorno Windows de forma nativa.

Tercer paso sería garantizar esta información en caso de pérdida, tener una redundancia.
¿Que pasaría si en un futuro perdiese físicamente el disco duro extraible o no pudiese acceder a el porque hubiese sido dañado?.
Pues esta redundancia la tendríamos en un sitio de ubicado geográficamente distinto, un sitio de terceros. Actualmente tengo contratado un servicio de almacenamiento cloud en una empresa de Hosting, la cual es de mi confianza.
Este servicio me ofrece un espacio FTP con un certificado SSL/TLS, por lo que puedo usar el canal de control y el de data para transferir información de forma segura mediante FTPS "FTP over SSL" (no confundir con SFTP "SSH-FTP").

Cuarto paso sería automatizar esta tarea. Generar un script que pudiese realizar por ejemplo, una copia semanalmente de toda esta carpeta y la transfiera de forma síncrona a este espacio de almacenamiento vía FTPS. En Windows existe la característica de habilitar el cliente FTP por línea de comandos, pero no podemos usar certificados sobre este cliente. Por lo que obté en usar la herramienta WinSCP, esta incorpora una utilidad en línea de comandos (winscp.com) la cual podemos generar un script en batch en integrarla perfectamente.

Generamos un fichero por lotes .bat con la siguiente línea de código:
winscp.com /log="backup.log" /command "open ftp://USER:PASSWROD@PATH_SERVER -explicit" "synchronize remote -delete -mirror -transfer=binary J:\ADRIAN /Backup" "close" "exit"
Figura 1: Script batch usando winscp.com para conexiones FTPS con sincronización de local a remoto

Iniciamos la utilidad winscp.com, con /log crearemos el fichero de log (esto sería opcional pero no está de más tener un registro de la actividad) este fichero lo tendremos que crear vacío de forma manual en el mismo directorio donde se lanzará el script.
A continuación indicaremos los parámetros realmente importantes, al usar winscp.com en un script batch tendremos que indicarle el modificador /command para que sepa que los próximos modificadores serán realizados en una sola instrucción. Podríamos crear un fichero a parte con los mismos modificadores del comando necesarios, en mi caso solamente realizo una única transferencia por lo que he obtado por unificarlo en un mismo fichero .bat.

Abrimos la conexión al servidor FTP (open) y la invocamos de forma explícita (-explicit). De esta forma el cliente solicita de forma explícita la seguridad acordada para empezar la comunicación con el servidor FTP de modo que tanto el canal de control como el de data sean cifrados.
synchronize remote: Los cambios del directorio local se actualizan con los remotos.
-delete: Elimina archivos obsoletos.
-mirror: Modo espejo (sincroniza también archivos antiguos).
-transfer=binary: Modo de transferencia binario, necesario por ejemplo para transferir ficheros de tipo imagen, vídeo, pdf, etc.
J:\ADRIAN: Directorio local.
/Backup: Directorio remoto.
Finalmente cerramos la conexión (close) y salimos de la sesión (exit).

Más información sobre WinSCP en command line:
https://winscp.net/eng/docs/ftps
https://winscp.net/eng/docs/scriptcommand_open
https://winscp.net/eng/docs/scriptcommand_synchronize

Con esto conseguiremos que cada vez que se ejecute el script este solo hará un repaso a todos los ficheros tanto locales como remotos haciendo un espejo y adaptando solamente los cambios, con lo que conseguiremos una reducción de tiempo en futuras transferencias.

Una vez que tenemos generado el script, tendremos que ejecutarlo manualmente y eso no sería práctico, llegados a este punto lo mejor será automatizar este script para que por ejemplo se ejecute un día y hora en concreto de la semana.
Para no recurrir a herramientas de terceros usaremos el "Programador de tareas" de Windows (taskschd.msc).

Creamos una nueva tarea. Como descadenador será según una progamción, semanalmente los Domingos a las 22:00. En mi caso lo tengo así programado ya que se que ese día y a esa hora tendré el equipo encendido.

Figura 2: Estableciendo el desencadenador de la tarea programada.

Las acción será iniciar un programa o script, indicamos el path de la ruta donde se encuentra el script. En mi caso no quería crear una variable de entorno de Windows por lo que tengo que indicarle al sistema donde se encuentra la utilidad winscp.com, por lo que le indico donde se debería iniciar el path en "Iniciar en".

Figura 3: Estableciendo la acción para ejecutar el script.

La configuración de la tarea programada la establecí del siguiente modo. Si la tarea no se ejecuta, reiniciarla cada 1 minuto durante un número de intentos de 5 veces y si sobrepasa las 12 horas de ejecución detener la tarea.

Figura 4: Configuración de la tarea programada.

Finalmente en la pestaña general designamos un nombre a la tarea programada. Una vez llegados a este punto tendremos dos opciones:
- Ejecutar solo cuando usuario haya iniciado sesión: En este caso veremos la vetana de la consola de Windows ejecutando todo el proceso.
- Ejecutar tanto si el usuario inició sesión como si no: En este caso la tarea se ejecutará de forma subyacente al usuario.

Si escogemos la primera opción no tendremos problemas. Pero si escogemos la segunda opción ya que puede darse el caso de que no estemos con la sesión iniciada en el equipo, pero este si esté encendido (y con el Bitlocker desbloqueado en mi caso). Al intentar establecer la tarea nos dirá que "la cuenta de usuario especificada tenga derechos para iniciar sesión como trabajo por lotes". Esto ocurre por que en mi caso el usuario que habitualmente uso por seguridad no está dentro del grupo Administradores, sino dentro del grupo Usuarios y por lo tanto no tiene los suficientes permisos como para llevar a cabo esta acción.

Figura 5: Ejecutar tarea programada tanto si el usuario inicia sesión como si no.

Para ello solamente tendremos que agregar la cuenta de usuario en el editor de directivas seguridad local (secpol.msc directamente o través de gpedit.msc) buscamos "Iniciar sesión como proceso por lotes" y agregamos el usuario.

Figura 6: secpol.msc - Iniciar sesión como proceso por lotes para una tarea programada.
De este modo ya podremos autenticar con las credenciales del usuario local, independientemente de si se marca el checkbox de "No almacenar contraseña" como si no.
Más información: https://technet.microsoft.com/en-us/library/cc722152(v=ws.11).aspx

Figura 7: Autenticación de credenciales del usuario local para tarea programada.

Para poder hacer un seguimiendo de la ejecución de la tarea programada habilitamos el historial. Esta opción afectará a todas las tareas programadas que tengamos en la biblioteca.

Figura 8: Habilitar el historial de las tareas programadas.

Una vez se ejecute y concluya la tarea, en la pestaña de historial veremos la auditoria de información de tiempos. Para hacerse una idea, en mi caso, según mi conexión de DSL y el ancho de banda contratado con el Hosting que me proporciona el server FTP. En menos de 25 minutos se hicieron transferencias de un total aproximado de 40GB.

Figura 9: Historial de la tarea programada.

Si consultamos el fichero .log que creamos para el registro de actividad de conexiones y transferencias hacia el servidor FTPS. Vemos como la conexión se establece de forma expícita solicitando el certificado y se establece la conexión TLS.

Un detalle a tener en cuenta de este log es que la password se visualiza como "*********", si se hubiese generado el log a partir de un script en dos partes, es decir que un fichero estaría el .bat que después llamaría al fichero donde se almacenaran los modificadores del comando winscp.com, esta password se visualizaría en texto plano. Por lo que no es lo mismo generar un log con winscp.com /log, que estableciendo el /log en un fichero a parte.

Figura 10: Fichero de log de las transferencias realizadas al servidor FTPS.

Espero que esto le resulte de utilidad algún usuario o le sirva de ejemplo para realizar sus propios métodos de copias de seguridad.

Saludos!

12 julio, 2017

Convertir disco VMDK a VDI y extender espacio en un disco VDI

VMDK y VDI son formatos de discos virtuales.
Si trabajamos con Virtual Box y quisiésemos extender el tamaño de almacenamiento de un disco VMDK en el que ya esté instalado un sistema operativo, no podríamos. Tendríamos que convertir primero ese disco VMDK en un disco VDI (formato por defecto de Virtual Box) y después extender el espacio en este último.
La conversión de disco es necesaria por que para redimensionar el espacio de un disco virtual usaremos la utilidad de línea comandos "VBoxManage.exe" de Virtual Box, para este tipo de modificaciones esta solo trabaja con discos en formato VDI.

Convertir disco VMDK a VDI:

Nos aseguramos que la máquina no está corriendo en ese momento y después eliminamos todas las snapshots si las hubiese.

Abrimos una línea de comandos y nos situamos el path donde tengamos instalado Virtual Box. Por defecto: "%systemdrive%\Program Files\Oracle\VirtualBox". Una vez ahí tendremos acceso a la utilidad VBoxManage.exe por lo que clonamos el disco vmdk a un disco en formato vdi.
vboxmanage clonehd --format vdi c:\vms\DISCO_1.vmdk c:\vms\DISCO_2.vdi
Donde DISCO_1.vmdk será el disco orignal a clonar y DISCO_2.vdi será el disco de salida ya clonado en el nuevo formato. El directorio "c:\vms" tendría que ser creado con aterioridad o simplemente indicaríamos una salida a otro directorio que tuviésemos.

Una vez hecho lo anterior podremos extender el tamaño del disco a lo que deseemos.

Extender el tamaño de almacenamiento de un disco VDI:

Desde la misma consola ejecutamos lo siguiente para redimensionar el disco VDI recién clonado.
vboxmanage modifyhd "c:\vms\DISCO_2.vdi" --resize 35840
modifyhd: modifica el tamaño del disco duro.
--resize: tipo de modificación que queremos hacer (redimensionar).
35840: tamaño que queremos extender el disco. En este ejemplo unos 35GB será su tamaño total NO adicional del que ya tenga.

Se generará una nueva zona sin un sistema de ficheros asignado. Con el administrador de discos de Windows (diskmgmt.msc) podemos extender la partición primaria-activa actual de nuestro OS hacia la zona sin asignar.

Saludos!

11 julio, 2017

Ataque MITM: ARP Poisoning y DNS Spoof con ARPSpoof [Parte 2 de 2]

Siguiendo la entrada anterior: Ataque MITM: ARP Poisoning y DNS Spoof con Ettercap [Parte 1 de 2].
Esta vez comentaré prácticamente lo mismo pero realizando el ataque desde una terminal de forma manual, sin una GUI. Desde una distribución Kali Linux usando arpspoof y el plugin DNS_Spoof de Ettercap también desde la terminal.


El equipo atacante (KaliLinux) tendrá que "hacer de router" por lo que se tendrá que habilitar ip_forward para enrutar todo el tráfico que llegue a el. De modo que deje salir a la puerta de enlace original todo el tráfica de la víctima. Si esto no se hiciese la vícitma se daría cuenta de algo extraño sucede ya que se quedaría sin conexión a Internet.
Para este ejemplo el equipo atacante tendrá la dirección 192.168.100.20.
echo 1 >> /proc/sys/net_ipv4/ip_forward
Figura 1: Habilitar ip_forward para el enrutamiento de tráfico.

Con Nmap (integrado también en Kali) escanemos toda la red local disponible, en este caso una clase C con máscara 24. De todas las direcciones IP obtenidas.
Para este ejemplo la víctima será la 192.168.100.10.
nmap -sP [DIRECCIÓN_RED/CIDR]
Figura 2: Escaneando toda la red local con Nmap.

Envenenamos la tabla ARP del equipo atacado y le hacemos creer qu ela dirección MAC verdadera del equipo atacante (192.168.100.20) es la misma que la de su puerta de enlace (router: 192.168.100.1).
Inicio del ataque, especificamos la interfaz de salida con -i y con -t el target (víctima) seguido del equipo (router) en el que suplantaremos la dirección MAC para la víctima.
En la captura podemos ver como las direcciones MAC de la tabla ARP del equipo víctima (Windows) cambiaron después del ataque. La MAC del router es la misma que la del atacante.

Dejaremos esta terminal minimaza y siempre funcionando.
arpspoof -i [INTERFAZ_RED] -t [IP_VÍCTIMA] [IP_ROUTER]
Figura 3: arpspoof - Antes y después del ataque.

Empezamos a capturar tráfico en Wireshark desde el equipo atacante.
Como ejemplo ingresaré en una web con mi nombre de usuairo y contraseña.
Este sitio no utiliza HTTPS, por lo que toda la información que veamos o ingresemos en un formulario no irá cifrada y será visible en texto claro.

Figura 4: Ingresando credenciales en un formulario de un sitio que no utiliza HTTPS.

Una vez interceptado HTTP el tráfico en Wireshark, podemos ver la solicitud POST de login. Examinado este paquete vemos el nombre de usuario y la contraseña en texto introducidos por la víctima.

Figura 5: Captura de credenciales introducidas por la víctima en el sitio web.

Iremos un paso más allá incorporando el plugin dns_spoof de Ettercap.
Como se trata de redirigir las peticiones a direcciones DNS que solicite la víctima, crearemos una website (que puede ser una réplíca visualmente de un sitio web conocido: facebook.com, gmail.com, etc.). Para ello crearemos un servidor HTTP con Apache.
Creamos un documento HTML, en este ejemplo no replicaré ningún sitio ya que llevaría más trabajo y como prueba de concepto me basearé en la representación y entendimiento de la técnica más que en su elavoración.

Figura 6: Creación de un posible sitio web malintencionado.

Redirigimos las peticiones DNS a las direcciones IP que quereamos, en este caso al servidor Apache que estará sirviendo en la máquina del atacante.

Como ejemplo redirigeremos las peticiones que vayan hacia google.es hacia una dirección IP correspondiente a otro sitio web que se verá más adelante, facebook.com y a este blog se redirigirán al servidor Apache del atacante.

Editamos el fichero del plugin "dns_spoof" de Ettercap.
/etc/ettercap/etter.dns
Figura 7: Editando fichero etter.dns para redirección de peticiones DNS de la víctima.

Una vez creado el documento principal y redirigido las peticiones DNS a la dirección IP de nuestro servidor, arrancamos el servicio del servidor Apache (ya instalado por defecto en Kali).
service apache2 start
Figura 8: Iniciar el servicio del servidor Apache

Lanzamos el plugin dns_spoof a través de ettercap haciendo uso de la terminal. Estando la terminal de arpspoof funcionando. Abrimos una nueva terminal para ejecutar lo siguiente.
ettercap -T -q -i [INTERFAZ_RED] -M arp:remote -P dns_spoof //[IP_ROUTER]// //[IP_VÍCTIMA]//
Figura 9: Ejecución del plugin dns_spoof de Ettercap en la terminal.

Si observamos las siguientes capturas de pantalla, vemos como el cliente intenta acceder a facebook.com y este lo redirige a nuestro servidor Apache.
Es curioso que siendo sitios webs bien conocidos y que de forma automática redirigen estas solicitudes a conexiones HTTPS y no HTTP. Pero en ciertas ocasiones y también dependiendo de como tengamos de "limpio" los navegadores webs tanto en IE como MFirefox, en ambos casos redirigieron estas solicitudes a donde se esperaba.

En la mayoría de ocasiones esto no fue posible mostrarlo tal cual aparecen en las capturas, ya que como ya dije al final del post de la parte 1 existen técnicas (HSTS y HPKP) que evitan que esto pase así como tampoco sería efectivo con SSLStrip el cual veremos en una futura entrada de este blog.

De manera que en la gran mayoría de ocasiones (no en todas) tuve que forzar la petición por "HTTP://facebook.com" en la barra de direcciones del navegador. Estos sitios web están configurados para redireccionar de forma automática sus solicitudes HTTP a HTTPS. Aunque se acceda por algún enlace o se escriba solamente "facebook.com" estos websites siempre intentarán redirigir a su sitio seguro y comprobar su certificado.

En el caso de este blog al no disponer de HTTPS y menos de un certificado de confianza, vemos que no existe ningún problema en redirigir tráfico HTTP.

En el último caso la redirección de google.es hacía la dirección IP establecida vemos que ha funcionado. Lo cual no siempre fue así de las pruebas realizas, por la misma razón que comenté anteriormente, la redirección HTTP a HTTPS.

 Figura 10: Redirección de facebook.com hacia el servidor Apache del atacante.

Figura 11: Redirección de es.es.facebook.com hacia el servidor Apache del atacante.

Figura 12: Redirección de zonasystem.com al servidor Apache del atacante.

Figura 13: Redirección de google.es hacía la dirección IP establecida en etter.dns.

Con nslookup vemos la comprobación de redirecciones DNS en el equipo atacado. En este caso facebook.com redirige al servidor Apache del equipo atacante.

Figura 14: Comprobando las redirecciones DNS en el equipo atacado.

En próximas entradas comentaré para que como sirve y como usar SSLStrip. Las desventajas que actualmente existen y que posibilidades de redirigir tráfico HTTPS hacia HTTP.

Saludos!

09 julio, 2017

Ataque MITM: ARP Poisoning y DNS Spoof con Ettercap [Parte 1 de 2]

Existen múltiples utilidades para realizar técnicas de ataques Man In The Middle (MITM). Es un tema que está más que documentado en Internet. En una anterior entrada ya comentara en que consisten y como realizar estos ataques desde Cain & Abel en entornos Windows.

Con el fin de tener esto como un apunte personal más, comentaré como realizar un "ARP Poisoning" y incorporar el plugin "DNS_Spoof" con Ettercap, una utilidad gráfica que podemos descargar e instalar en cualquier entorno Linux. Por defecto también está disponible está disponible en Kali Linux.

Ettercap es muy sencillo de utilizar, por lo que no me extenderé explicando los detalles. Solamente con las capturas de pantalla se pueden seguir los pasos perfectamente y entender sus funciones.

Establecemos las librerías pcap. Sniff > Set pcap filter...

Figura 1: Set pcap filter Ettercap

Asignamos una interfaz de red para el sniffing. Sniff > Unified sniffing...

Figura 2: Asignar interfaz de red para la captura de paquetes.

Indicamos la interfaz de red, en este caso eth0.

Figura 3: Indicar interfaz de red

Escanemos los hosts disponibles de la red local. Scan for hosts...
Una realizado el escaneo listamos los hosts disponibles. Hosts list.

Figura 4: Escaneo de hosts disponibles de la red local.

En este escenario vemos dos hosts disponibles, el equipo que nos interesa atacar es el que corresponde a la dirección IP 192.168.100.10. Lo seleccionamos y realizamos el ARP Poisoning hacia este equipo. Mitm > ARP poisoning...

Figura 5: Selección de la víctima para ARP poisoning.

Nos interesa capturar las conexiones del equipo remoto por lo que seleccionamos Sniff remote connections.

Figura 6: Sniff para conexiones remotas.

En esta punto ya estaremos envenenado la tabla ARP de la víctima. Pero añadiremos el plugin "dns_spoof" que integra Ettercap. Esto nos servirá para suplantar peticiones DNS y así redirigir estas peticiones a la dirección IP que tengamos establecida en el fichero "/etc/ettercap/etter.dns".

Administramos los plugins disponibles en Ettercap. Plugins > Manage the plugins...

Figura 8: Administrar plugins en Ettercap.

Se abrirá una nueva pestaña en la que buscaremos y seleccionaremos el plugin dns_spoof.

Figura 9: Selección del plugin dns_spoof.

Por último solo restará modificar el fichero local /etc/ettercap/etter.dns (en Kali Linux) para redirigir las peticiones de nombres de dominio del equipo víctima hacia las direcciones IP que establezcamos. En este caso las redirigí al propio equipo local (atacante) que tiene la IP 192.168.100.20. En este equipo tengo un servidor Apache el cual podría almacenar una réplica de la website que estamos redirigiendo, de este modo podríamos "engañar" a la víctima haciendo creer que está hacciendo a facebook.com cuando realmente está accediendo en mi web indéntica de facebook.com alojada en mi servidor Apache.

Figura 10: Fichero etter.dns. Redirigiendo websites.

Tiempo atrás se podía realizar con éxito este ataque. Hoy en día gracias a las mejoras de seguridad existen mecanismos que dificultan los DNS Spoof como son HPKP y HSTS.
Estos pueden interceptar las comunicaciones, cookies y otros parámetros. Obligando el uso de protocolos seguros como HTTPS, redirigiendo los sitios webs a su lugar legítimo.

De forma informativa y educativa en posteriores entradas comentaré una de las técnicas que podemos utilizar para intentar bypasear este tipo de mecanismos de seguridad.

Saludos!

19 junio, 2017

Generando actividades falsas en Strava

En esta entrada mostraré una sencilla técnica en la que podremos cambiar el tipo de dispositivo con el que se registró una determinada actividad en Strava, de modo que "engañaríamos" a la App haciendo creer que cierta actividad se registró con un dispositivo smartphone cuando en realidad se hizo con otro tipo de dispositivo, por ejemplo un GPS de Garmin, quién sea usuario de esta App sabrá a lo que me estoy refiriendo. Así como también la posibilidad de cambiar la fecha y otros posíbles parámetros.

Por defecto en Strava cuando realizamos alguna actividad a través de su App Strava este da la opción de poder publicar dicha actividad nada más terminarla. Esta actividad se publica en los tiempos, fecha/hora que se realizaron, así como el tipo de dispositivo en el que fue registrada.

Tiene la opción de poder subir un fichero .gpx de algún dispositivo GPS Garmin estos dispositivos establecen unos metadatos que definen exactamente el tipo de dispositivo, ya sea Garmin un fichero GPX sin ningún metadato establecido, etc.

No sería fácil entonces engañar a Strava subiendo actividades falsas, modificando la fecha/hora, velocidades, etc. Ya que igualmente podremos ver como el tipo de dispositivo sería un fichero .gpx y no un dispositivo como un smartphone que use la App Strava. Por lo tanto sería poco creíble una actividad que sea todo un logro subida directamente desde un fichero .gpx.
¿Pero que pasaría si se pudiese modificar cualquier parámetro y a su vez que las actividades se registren y publiquen a través del dispositivo móvil, pareciendo que dicha actividad fue subida de forma pública a través de la App de Strava?.

Una actividad registrada desde un dispositivo Garmin, abriendo el fichero gpx original en Notepad++ vemos que los datos se establecen en formato XML y la etiquetas de referencias para ficheros GPX son de estandar. la etiqueta "gpx creator=" será la que nos interesa para modificar el tipo de dispositivo con el que se registró la actividad. Así como las fechas de realización de la actividad, cogeré las fechas como ejemplo a modificar, pero se podrían establecer, velocidades, distancias, nuevas coordenadas gps, etc.

Figura 1: Fichero gpx original de Garmin

Si subimos dicha actividad a Strava veremos como tanto la fecha como el dispositivo (GPX) es la original del track gpx.

Figura 2: Actividad del fichero gpx original anterior

Para comprobar que metadatos registra Strava cuando este genera su propio GPX a través de su App desde un dispositivo smartphone, descargamos cualquier actividad previamente ya registrada desde la App en Strava. Exportamos el GPX y a continuación lo exploramos.

Figura 3: Exporar GPX ya registrado por la App de Strava

Abriendo el gpx original que exportamos desde Strava de otra actividad vemos que la etiqueta gpx creator apunta a "strava.com Android" (en el caso de iPhone abría que hacer lo mismo y mirar que valor toma) en cualquier caso para engañar la subida de la actividad como un dispositivo móvil nos servirá con Android.

Figura 4: gpx original exportado de Strava APP

Una vez sabemos el valor a sustituir, abrimos el GPX original, con Notepad++ reemplazamos todos los campos que sea de una fecha por otra (Search > Replace > Replace All o Ctrl+H) y modificaremos unicamente el valor gpx creator="Garmin Desktop App" por gpx creator="strava.com Android". A mayores podemos directamente eliminar/borrar o modificar también las etiquetas xml de <metadata> de los enlaces de referencia <link href> y <text>.

El resto de datos los dejaremos igual, ya que pude comprobar que si establecen exactamente los mismos datos que el gpx original de Strava, este se da de cuenta en el momento de subir el fichero gpx a Strava y nos cancela la subida. ¿Por que pasa esto? básicamente los metadatos del gpx contienen los enlaces al tipo de mapa o topo con el que se registrará la actividad y realizará los cálculos. Por lo que Strava se da de cuenta de estas modificaciones si cambiamos todos los valores que tengan que ver con sus metadatos. De modo que dejaremos el resto de datos del gpx original de Garmin en este caso, con su topo con DEM (desniveles del terreno), sus distancias, etc. El mapa y la actividad registrada con los datos del Garmin pero el tipo de dispositivo se establecerá como "Strava App Android".
El resto de valores competentes con tiempos, fechas/horas, velocidades, etc. no se verán influenciadas por los filtros de protección de Strava a la hora de subir las actividades en ficheros gpx.

Figura 5: gpx modificado de Garmin para Strava APP

Guardamos el fichero ya modificado y subimos de nuevo la actividad a Strava desde un fichero GPX, esta vez ya nos aparecerá la fecha modificada y el tipo de dispositivo que registró la actividad será Strava Android App.

Figura 6: gpx anterior modificado y subida la actividad a Strava

Saludos!
Entradas Relacionadas