Actualizar firmware de un Access Point Aruba

Escrito por Blai el 30.5.18

Cómo actualizar el firmware de un Wireless Access Point de la marca Aruba, cómo actualizar firmware de un AP de Aruba Networks via web GUI o interfaz gráfica.



Como sucede con todos los dispositivos de red, los Access Point (APs) que sirven señal WiFi utilizan firmware que debe ser actualizado periódicamente para solucionar fallos (y añadir nuevas funciones).

En el caso de los APs de la marca Aruba, podemos actualizar su firmware por las vías habituales: subiendo una imagen con el firmware vía web, cargando la imagen por SSH, por FTP... Además, estos APs pueden conectarse directamente a los servidores de Aruba y descargar desde allí las imágenes de firmware correspondientes a su modelo, lo cual simplifica enormemente el proceso de actualización.

Para actualizar el firmware de un AP Aruba desde los servidores de Aruba, podemos conectarnos a la interfaz web de gestión del AP en cuestión y realizar todos los pasos desde allí.



Una vez dentro, clicamos la opción "Maintenance" en el menú superior derecho. Se nos abrirá una nueva ventana donde veremos el modelo de AP (Type) y la versión del firmware en ejecución:



Vamos a la pestaña "Firmware" y allí volvemos a ver la versión del firmware en ejecución, además de la posibilidad de cargar nuevo firmware desde una ubicación local, URL o automáticamente desde Aruba:



Clicamos "Check for New Version" y el propio AP se conectará vía internet a los servidores de Aruba en busca de nuevas versiones de firmware para su gama:



Una vez el AP haya encontrado una nueva versión de su firmware, toca aplicarla. Para ello, basta con pulsar el botón "Upgrade now". Hay que decir que después de pulsar el botón de upgrade, el AP se reiniciará tanto si marcamos la casilla "Reboot all APs after upgrade" como si no la marcamos.



Cuando acabe de desplegarse el nuevo firmware, el AP mostrará el siguiente mensaje:



Como comentaba, después de instalarse el nuevo firmware, el AP se reiniciará automáticamente:



Una vez reiniciado el AP, volvemos a Maintenance > Firmware y veremos ya la nueva versión de firmware. Podemos entonces volver a buscar una versión más reciente. En este caso, no la hay.



En este ejemplo no hay ninguna versión de firmware posterior a la que acabamos de instalar pero en otros casos puede que haya que ir actualizando versiones hasta llegar a un número de versión concreto que nos permita luego desplegar la última versión lanzada por el fabricante.


Fuentes:

https://www.arubanetworks.com/techdocs/Instant_423_WebHelp/InstantWebHelp.htm#CLI...

Leer más »

Usar SSH desde 'Símbolo del sistema' de Windows

Escrito por Blai el 23.5.18

Cómo instalar el cliente de OpenSSH en Windows, guía de instalación de cliente de SSH en Windows, configurar OpenSSH Client en Windows, usar SSH en Windows desde consola, usar SSH desde cmd.



En la pasada Fall Creators Update de Windows 10, Microsoft introdujo una caracterísitca a Windows que pasó desapercibida a muchos usuarios pero que, personalmente, me parece muy interesante: la posibilidad de usar SSH en Windows 10 de forma nativa desde la línea de comandos, tanto en el lado servidor como en el lado cliente. Y lo mismo para Windows Server, a partir de la revisión 1709.

SSH (Secure Shell o "intérprete seguro") es un protocolo (y programa) propio de los sistemas *NIX (Linux, FreeBSD, Solaris, etc.) y hasta la fecha requería software de terceros para poder ser usado desde Windows. A partir de ahora, con la adopción de OpenSSH de forma oficial por parte de Microsoft, ya no se requiere el uso de PuTTy, WinSCP ni similares para efectuar conexiones SSH/SFTP desde Windows.

Para instalar el cliente de OpenSSH nativo de Windows, primero debemos ir a la opción "Aplicaciones y características" de Windows (recordemos que debemos ser administradores locales o remotos de una máquina para poder instalar / desinstalar características de Windows).

Podemos ir al menú de aplicaciones de varias maneras:

- Escribiendo "aplicaciones" en el menú de inicio de Windows y clicando en la opción cuando aparezca.

- Haciendo clic derecho sobre el icono de Windows de la barra de tareas y eligiendo "Aplicaciones y características".

- Haciendo clic en las notificaciones de la barra de tareas y eligiendo "Todas las configurac."

Una vez en el apartado "Aplicaciones y características", clicaremos la opción "Administrar funciones opcionales", justo encima de la lista de programas instalados en el equipo:



A continuación clicaremos "Agregar una característica":


Bajamos abajo del todo y elegimos "OpenSSH Client (Beta)".


La instalación del cliente de OpenSSH tardará menos de un minuto, y cuando acabe, abriendo una sesión de cmd y escribiendo ssh deberíamos ya ser capaces de usar SSH y SFTP desde la línea de comandos de Windows (y también desde la terminal de PowerShell).

Comentar que a mi no me ha funcionado a la primera. Para poder usar SSH, he tenido que irme al directorio donde queda instalado (C:\Windows\System32\OpenSSH) y ejecutar el comando SSH desde allí (es decir, desde donde está ubicado ssh.exe).


Para solucionar este problema, podemos añadir la ruta de OpenSSH a las variables de entorno o reiniciar la máquina para que adopte los cambios por sí misma. Decir que después de reiniciar la máquina, Windows ya me ha ejecutado SSH desde cualquier ubicación usando cmd.

Ahora sí, ya he podido conectarme por SSH a otras máquinas mediante "ssh usuario@ip":


A partir de este momento, ya podemos incluir conexiones SSH en nuestros scripts - o conexiones SFTP - sin tener que depender de software de terceros como WinSCP.

Microsoft advierte en mayúsculas y en negrita que OpenSSH para Windows está aún en estado Beta y no debe usarse en producción, así que no está de más avisar. Y es que, sí SSH se lanzó en 1995 para los sistemas *NIX y lleva usándose desde entonces con normalidad, en 2018 Windows aun no es capaz de ejecutarlo correctamente. Pero están en ello, que es lo importante.


Fuentes:

https://blogs.msdn.microsoft.com/powershell/2017/12/15/using-the-openssh-beta-in-windows-10-fall...
https://blogs.msdn.microsoft.com/commandline/2018/01/22/openssh-in-windows-10/

Leer más »

Actualizar firmware de un firewall Sonicwall

Escrito por Blai el 16.5.18

Cómo averiguar la versión de firmware de un Sonicwall, cómo averiguar la última versión de firmware liberada para un Sonicwall, cómo actualizar el firmware de un Sonicwall.



Cuando se trata de un firewall, es casi obligatorio actualizar su firmware cada vez que se lanza una nueva versión de este. Idealmente, deberíamos comprobar si ha salido una nueva versión del firmware (y aplicarla) cada 6 meses (o como mínimo, una vez al año).

En el caso de un firewall de la marca Sonicwall, podemos realizar el proceso de comprobación y actualización de firmware manualmente de la siguiente forma. Primero, accedemos al panel de administración web del Sonicwall que queramos actualizar y nos dirigimos a System > Status:



Allí podemos ver el modelo de Sonicwall con el que estamos trabajando, en este caso un TZ 210, y la versión de Firmware que está usando, en este caso SonicOS 5.5.1.0-5o. Hay que decir que el procedimiento para comprobar la versión de firmware es exactamente el mismo para cualquier otro modelo de Sonicwall: Sonicwall NSA, Sonicwall SOHO, Sonicwall TZ 205, Sonicwall TZ 215, etc.

Una vez localizados el modelo y versión de firmware del Sonicwall, vamos a la web de clientes de Sonicwall, mysonicwall.com, y buscamos el modelo en cuestión en la sección Downloads (tenemos que haber registrado allí el Sonicwall previamente para poder descargar nuevo firmware para él).



En mysonicwall descargamos el firmware más reciente para el modelo que estemos gestionando, en este caso el firmware 5.9.1.10-1o de SonicOS para el Sonicwall TZ 210.

Con el archivo de firmware ya descargado, volvemos al Sonicwall y ya podemos proceder a cargarlo. Para ello, vamos a System > Settings y clicamos el botón "Upload New Firmware...".



Seleccionamos el archivo .sig que nos hemos descargado de mysonicwall.com y lo subimos.

NOTA: si después de subir el archivo vemos el mensaje "Status: The firmware upload failed." debemos asegurarnos que estamos subiendo el firmware correspondiente al modelo que estamos gestionando (especial atención a los modelos Wireless. Es diferente un TZ 215 que un TZ 215 W). Si el firmware es el correcto y el problema persiste, hacer reboot del dispositivo y volver a subir el archivo.



Una vez subido el nuevo firmware, aconsejo generar un backup del estado actual del Sonicwall antes de aplicar el nuevo firmware. Para hacerlo, pulsar el botón "Create Backup Settings". Esto generará un archivo con el firmware actual y la configuración actual - todo en uno.



Para descargar el archivo de backup, clicar en el icono de descarga de "Current Firmware with Backup Settings" y guardar el archivo en nuestro disco duro. Si algo fallase después de aplicar el nuevo firmware, siempre podemos subir este archivo y recuperar así el Sonicwall al estado actual (funcional).

Una vez guardado el backup, ya podemos aplicar el nuevo firmware. Para ello, clicar el icono de boot de "Uploaded Firmware with Backup Settings" para reiniciar el Sonicwall e instalar el firmware:



Tal y como muestra el cuadro de diálogo, el dispositivo tardará unos 4 minutos en reiniciarse y aplicar los cambios. Acto seguido, nos tendremos que logear de nuevo en el Sonicwall y, una vez dentro, veremos como ya estaremos usando la nueva versión del firmware (mirar firmware version):



Si nos encontráramos con algún problema usando el nuevo firmware, siempre podemos cargar el archivo de backup generado anteriormente, para seguir funcionando, y luego buscar una solución en:

https://www.sonicwall.com/en-us/support/knowledge-base

Para el que se pregunte cómo actualizar el Safemode o la ROM version de un Sonicwall, decir que no es posible hacerlo sin contactar antes con el soporte técnico de Sonicwall, ya que las ROMs no se ofrecen en descarga en mysonicwall.com, según detallan en este artículo.

Leer más »

Primer vistazo a Amazon Linux

Escrito por Blai el 9.5.18

¿Qué es Amazon Linux? ¿En qué distribución está basado? ¿Puedo usarlo fuera de Amazon Web Services? Veamos los entresijos de esta peculiar distribución de Linux.



Amazon Linux es una distribución GNU/Linux creada por Amazon Web Services (AWS) a partir del código fuente de Red Hat Enterprise Linux. A diferencia de Red Hat, que cobra a sus usuarios por ofrecerles soporte sobre su sistema, AWS ofrece asistencia y actualizaciones gratuitas para Amazon Linux a sus clientes, lo cual lo convierten en una opción muy interesante para las empresas, al no tener estas que abonar licencias adicionales para obtener soporte para sus sistemas si usan Amazon Linux.

Como contrapartida, hay ciertas voces críticas con Amazon Linux que se quejan del hecho de que no se pueda descargar una imagen de este sistema operativo para usarlo fuera de AWS. Esto obliga a los DevOps a tener su entorno de desarrollo también en AWS para evitar tener dos entornos diferentes entre desarrollo y producción, aumentando así el gasto en la factura de AWS.

Amazon Linux fuera de AWS

Hasta hace poco, era cierto que no se podían descargar imágenes de Amazon Linux para su uso fuera de AWS; no obstante, con la llegada de Amazon Linux 2, AWS cambió de estrategia y decidió liberar una imagen de Amazon Linux 2 para Docker, así como varias imágenes de Amazon Linux 2 preparadas para su descarga y uso en local en entornos VMware, Oracle VirtualBox y Microsoft Hyper-V. Desde entonces, la afirmación de que no se puede descargar una imagen de Amazon Linux para su uso en local ha dejado de ser cierta (al menos para Amazon Linux 2).

Por si esto fuera poco, AWS ofrece el código fuente de Amazon Linux 2 para descargar, así que si ninguna de las soluciones anteriores te convence, siempre puedes probar a compilar el sistema desde código fuente antes de empezar a usarlo.

Versiones

AWS ofrece dos versiones de Amazon Linux: Amazon Linux 2 LTS y Amazon Linux.


Especificaciones de ambas distribuciones tal cual aparecen en AWS al desplegar una nueva instancia.

Hace poco tuve la oportunidad de trastear con ambas AMIs. A continuación, expongo lo que pude ver.



Aunque haya aparecido Amazon Linux 2, Amazon Linux (1) se sigue actualizando.



Aquí están listadas las novedades de Amazon Linux 2 respecto a la versión anterior, entre ellas la adopción de systemd frente a SysV, como cambio más notable.

Lo primero que me llamó la atención de ambas distros es que ambas usan una versión de kernel muy reciente en comparación con los kernels que equipan de serie otras distros comerciales como SLE o Ubuntu. Además, pude comprobar que al igual que está ocurriendo con todas las distribuciones de Linux destinadas a ser usadas en servidores, Amazon Linux sólo se ofrece en versión 64 bits.

Por otro lado, ambos Amazon Linux usan yum como gestor de paquetes al igual que su sistema base. Los repositorios a los que se conectan varian en función de la region de AWS donde esté desplegada la instancia (las URLs de cada repositorio usan variables que luego apuntan a uno u otro servidor, por lo que pude ver). Como se aprecia, todas las órdenes (como yum update) deben introducirse con sudo.

Opinión

No pude hacer mucho más que desplegar Apache en ambas instancias y ejecutar cuatro comandos, pero mi primera impresión de Amazon Linux es que se trata de una distro muy mimada, con un especial émfasis en la seguridad (ver Amazon Linux Security Center), pre-cargada con herramientas que permiten acceder a las APIs de AWS directamente, y algo muy interesante: con soporte gratuito.

Si a lo anterior le unimos la capacidad de usar Amazon Linux 2 en entornos on-premise, por ejemplo para su uso en máquinas dev, me parece una distribución de Linux a tener muy en cuenta.


Fuentes:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html
http://www.entredevyops.es/posts/amazon-linux-si-o-no.html
https://www.edgehosting.com/blog/2017/06/amazon-linux-versus-centos/
https://aws.amazon.com/es/amazon-linux-2/faqs/
https://cloudonaut.io/migrating-to-amazon-linux-2/

Leer más »

BSides Vancouver: 2018 (Workshop)

Escrito por Blai el 2.5.18

Nombre: BSides Vancouver: 2018 (Workshop)
Autor: abatchy
Enlace: https://www.vulnhub.com/entry/bsides-vancouver-2018-workshop,231/

El fin de semana pasado me animé a probar a resolver un desafío CTF de vulnhub.com por primera vez. Elegí la VM más reciente, llamada "BSides Vancouver: 2018 (Workshop)" y... conseguí el flag!!! :D
Viendo que en vulnhub aún no hay ningún walkthrough (tutorial) sobre como resolver este desafío, he decidido compartir mis pasos desde el boot de la VM hasta el momento de conseguir el flag.

Los pre-requisitos de la VM requerían "VirtualBox pre-installed", así que tuve que descargar VirtualBox. Lo instalé y configuré un segmento de red de esta forma:

Fui al menú Archivo > Preferencias > Red y allí cree una "Red NAT".

Una "Red NAT" no es otra cosa que una VLAN solo visible por VirtualBox. En esta VLAN, junté las dos máquinas que usaría en este CTF: un Kali Linux para realizar el ataque y la propia VM a atacar.



VirtualBox me ofreció 10.0.2.0 como segmento por defecto. Yo le metí máscara /28 para que el escaneo posterior con nmap para descubrir la IP asignada a la VM fuese más rápido. Podría haber usado /29 para acotar más, pero /28 ya me estaba bien ya que me permitiría importar más VMs para jugar... :)

Una vez asignado el segmento de red, cargué las imágenes de ambas VMs en VirtualBox, las inicié y lancé un escaneo del segmento desde Kali usando nmap para descubrir la IP del objetivo:



Una vez descubierta la IP de la máquina objetivo, 10.0.2.6, lancé un escaneo más exhaustivo sobre su IP:



Lo primero que me llamó la atención fue que el servidor soportara acceso anónimo al FTP. Al ir a conectarme a la VM por FTP, me di cuenta que Kali no trae el comando ftp instalado por defecto (¿¿??) así que tuve que instalarlo mediante un "apt install ftp". Una vez instalado "ftp", probé a conectarme con "ftp anonymous@10.0.2.6" pero no resultó, así que busqué en Google y encontré un enlace que hablaba sobre cómo conectarse a un FTP de forma anónima.



Una vez dentro del FTP, encontré un archivo llamado users.txt.bk. Lo descargué con un "get" para ver qué contenía y al abrirlo vi que era una lista de usuarios. De posibles usuarios del sistema. Llegados a este punto, podría haber echado un ojo a la web, ya que la VM tenía un servicio corriendo en el puerto 80, y buscar más cosas pero decidí probar suerte con la lista de usuarios.

Lo que tenía en mente en este momento era lanzar un ataque de diccionario contra el servidor usando todos los nombres de usuario de users.txt.bk. Para ello, podría haber usado Hydra pero decidí usar otra herramienta, un script al que yo mismo contribuí con código hace algún tiempo: getsshpass.sh.

getsshpass.sh es un script hecho en bash por Radovan Brezula aka Brezular cuya función es probar usuarios y contraseñas contenidos en archivos de texto contra una IP por SSH hasta dar con unas credenciales de acceso válidas. Tal y como cuenta su creador, en un test Hydra tardó 4min 45s en obtener el password de un usuario mientras que getsshpass.sh lo obtuvo en 3min 29s. getsshpass.sh es más rápido que Hydra porque Hydra está limitado a un máximo de 64 sesiones paralelas mientras que getsshpass.sh usa el máximo de sesiones paralelas posibles según el hardware donde está corriendo.

Descripción completa y descarga de getsshpass.sh

Me descargué el script y le di permisos de ejecución.



Ejecuté el script usando la famosa wordlist "rockyou.txt" contenida en Kali y esperé...



...Hasta obtener el password del usuario "anne" ¡en 3 segundos! Viva getsshpass.sh :D

Para el que se pregunte por qué el script empezó por el usuario "anne" cuando había tres usuarios por encima de anne en la lista, lo hizo así porque añadí una función al script que comprueba si el usuario a testear puede acceder al sistema vía SSH con password o sólo con publickey. Si solo puede acceder vía SSH con publickey, lo desestima y prueba con el siguiente usuario. Y así hasta dar con un usuario que pueda acceder con password. Entonces, inicia el ataque con ese nombre de usuario.

Me conecté por SSH a la VM usando las credenciales recientemente encontradas. Una vez en la terminal, lancé el comando "id" y me encontré con que anne estaba incluida en el grupo "sudo". Miré entonces qué comandos podía ejecutar anne con sudo mediante "sudo -l".



Viendo que anne tenía acceso a todos los comandos (ALL), bastó con hacer "sudo su" para pasar a la cuenta root y capturar así el flag contenido en /root/flag.txt.

Opinión

El flag dice que hay varios métodos para superar este CTF. Supongo que yo usé el método más basto, pero fue igualmente efectivo y me permitió usar getsshpass.sh, lo cual me hizo ilusión.

El uso del FTP anónimo, por su parte, fue interesante, aunque el hecho de encontrar dentro sólo un archivo fue demasiado directo. Pienso que se podría haber ocultado de algún modo, por ejemplo creando una estructura de directorios, poniendo varios archivos con nombres a priori prometedores pero sin contenido interesante y haciendo, en definitiva, que el atacante tuviera que rebuscar por ese árbol de directorios hasta dar con la lista de usuarios.

Leer más »