sábado, 29 de marzo de 2014

El abc para desproteger un Excel con contraseña

Desde que soy consultor de seguridad una de las herramientas que más utilizo de mi arsenal de hacking es... Excel ٩(͡๏̯͡๏)۶ ... y cómo este blog va de lo que va... pues vamos a mostraros un pequeño "how-to" para romper las principales protecciones de nuestras hojas de cálculo favoritas.

Cifrar con contraseña

Algo muy común es proteger el acceso total al fichero con una contraseña:




Lo que hace Excel por debajo para proteger la hoja de cálculo de esta manera es cifrar el archivo con AES y una clave de 128 bits (ojo porque hay un pequeño truquito para aumentarla a 256 bits modificando el registro). Para romperlo, lo mejor en este caso es utilizar un ataque de diccionario con John the Ripper o cualquier otra herramienta que gustéis.... 

Primero obtenemos el hash de la contraseña del documento con office2john incluido en laversión jumbo 1.7.9 compilada por Robert Harris:
D:\Hacking\john-1.7.9-jumbo-7-Win-32\run>office2john.exe /cygdrive/d/Libro1.xlsx  > hash_excel.txt

/cygdrive/d/Libro1.xlsx:$office$*2010*100000*128*16*507e4f65f0c73a48077b22ce5473ccec*50946a93488c091f536b4063eb3ae667*799528a214fb108b73f91ef5806222ebf9049d87e963238ac5a1acf82f9eb9db

Ahora un poquito de benchmarking para comprobar la capacidad de mi patata de PC: 
D:\Hacking\john-1.7.9-jumbo-7-Win-32\run>john --test --format=office
Benchmarking: Office 2007/2010 SHA-1/AES [32/32]... DONE
Raw:    30.1 c/s real, 30.3 c/s virtual

Después iniciamos el ataque de fuerza bruta con el diccionario elegido: 
D:\Hacking\john-1.7.9-jumbo-7-Win-32\run>john -w:dicio.txt hash_excel.txt
Loaded 1 password hash (Office 2007/2010 SHA-1/AES [32/32])
123456           (/cygdrive/d/Libro1.xlsx)
guesses: 1  time: 0:00:00:00 DONE (Fri Mar 28 00:27:47 2014)  c/s: 14.83  trying
: 123456
Use the "--show" option to display all of the cracked passwords reliably
   
Y en menos de 5 segundos tenemos acceso al mismo, gracias en parte a que el dueño del documento utilizó una de las peores contraseñas posibles

Finalmente guardamos el fichero como Libro2.xlsm, pero antes en el desplegable 'Herramientas' seleccionamos 'Opciones generales' y eliminamos la contraseña de apertura:
  

Bloquear el proyecto VBA

Otra opción es establecer una contraseña para ver las propiedades o incluso visualizar el proyecto VBA (las macros). 




Sin embargo esta *irrisoria* protección es para el UI y básicamente añade unas pocas líneas al form:

CMG="0604AB00EA009E049E049A089A08"
DPB="C6B41DD07A30374D374DC8B3384DDC63D35C51C89D809616E325E4129493EEFDBC48EE77D47B79"
GC="6664CAA0CBE07BE17BE17B"


Estos campos corresponden a ProjectProtectionState, ProjectPassword y ProjectVisibilityState respectivamente. Por lo que si borramos esos campos (reemplazando el texto con espacios en blanco) Excel no nos pedirá una contraseña para ver el código del proyecto...

Para ello descomprimimos el fichero Libro2.xlsm como si de un zip se trataba, editamos el fichero xl\vbaProject.bin con notepad++ (u otro editor hexadecimal) y cambiamos DPB= por DBx=.

Luego guardamos el archivo con la misma extensión .BIN y agregamos al zip sustituyendo el mismo archivo.

Al abrir de nuevo el fichero Excel nos dirá que contiene una clave 'DPx' no válida:



Simplemente continuamos cargando el proyecto, ignoramos el error, asignamos una nueva contraseña en las propiedades de VBAProject y salvamos...

Al volver a abrirlo tendremos acceso al código de la macro:


Proteger hoja actual y estructura del libro

Otra opción que normalmente se utiliza es la de proteger la hoja actual y la estructura del libro para que otros usuarios no realicen cambios:


Sin embargo, quitar esta protección también es bastante trivial. Simplemente añade al proyecto VBA la siguiente macro: 


Sub PasswordBreaker()
    'Breaks worksheet password protection.
    Dim i As Integer, j As Integer, k As Integer
    Dim l As Integer, m As Integer, n As Integer
    Dim i1 As Integer, i2 As Integer, i3 As Integer
    Dim i4 As Integer, i5 As Integer, i6 As Integer
    On Error Resume Next
    For i = 65 To 66: For j = 65 To 66: For k = 65 To 66
    For l = 65 To 66: For m = 65 To 66: For i1 = 65 To 66
    For i2 = 65 To 66: For i3 = 65 To 66: For i4 = 65 To 66
    For i5 = 65 To 66: For i6 = 65 To 66: For n = 32 To 126
    ActiveSheet.Unprotect Chr(i) & Chr(j) & Chr(k) & _
        Chr(l) & Chr(m) & Chr(i1) & Chr(i2) & Chr(i3) & _
        Chr(i4) & Chr(i5) & Chr(i6) & Chr(n)
    If ActiveSheet.ProtectContents = False Then
        MsgBox "One usable password is " & Chr(i) & Chr(j) & _
            Chr(k) & Chr(l) & Chr(m) & Chr(i1) & Chr(i2) & _
            Chr(i3) & Chr(i4) & Chr(i5) & Chr(i6) & Chr(n)
         Exit Sub
    End If
    Next: Next: Next: Next: Next: Next
    Next: Next: Next: Next: Next: Next
End Sub

Ejecutalá y se mostrará la clave de respaldo que ocupa internamente el código de Excel en dicha hoja: 
  

A partir de ahora ya podremos editar la hoja excel e incluso desproteger el fichero:


Y nada, a correr!

jueves, 27 de marzo de 2014

Demonizando Latch para proteger archivos con dos llaves


Imaginemos que tenemos un servidor dispuesto para nuestros usuarios. Tenemos cierto archivo o carpeta que tiene que estar disponible para dos usuarios en concreto; el cual no puede ser leído o modificado sin el permiso de ambos.

Sería genial que ambos usuarios pudiesen tener el control sobre este hecho, como si se tratase de un cofre el cual necesita dos llaves (podrían ser más) para ser abierto, sin ni siquiera tener un acceso físico a la máquina, es decir,  que puedan decidirlo por control remoto desde su smartphone y así tener el control total sobre el acceso a dicho archivo o carpeta... 

Esta situación es posible si miramos las posibilidades que nos brinda LATCH (de paso les agradezco a 11paths el juguetico que me hace pasar unas horas muy entretenido) y hacemos un apañejo, o chapucilla a la espera de que implementen algo parecido (que seguro que lo han pensado).

Pues bueno vamos a ver como lo hacemos y al tiempo aprenderemos a hacer nuestros propios demonios en Linux.

Lo primero sería dar dos usuarios de alta en Latch, para así disponer de "las llaves" para nuestro cofre (una para cada uno). Lo haremos en latch.elevenpaths.com.

No me entretendré en este proceso por no alargar la entrada, si queréis verlo detenidamente echar un ojo a esta otro post crear cuenta latch.

Una vez hecho ésto pasaremos a registrar ambas cuentas en el sistema con el siguientescript , tambien tenemos descrito el proceso en la entrada anterior en la parte deemparejar nuestra cuenta. Como es obvio, lo haremos una vez por cada id de aplicación y su correspondiente secreto y en distintos archivos (latch-llave1.account y latch-llave2.account). Con ésto ya tenemos nuestras "2 llaves":


Liberando nuestro demonio

"Un demonio, daemon o dæmon (de sus siglas en inglés Disk And Execution MONitor), es un tipo especial de proceso informático no interactivo, es decir, que se ejecuta en segundo plano en vez de ser controlado directamente por el usuario. Este tipo de programas se ejecutan de forma continua (infinita), vale decir, que aunque se intente cerrar o matar el proceso, este continuará en ejecución o se reiniciará automáticamente. Todo esto sin intervención de terceros y sin dependencia de consola alguna.” (Wikipedia)

En este caso vamos a utilizar un demonio sencillo en System V, pero no olvidemos que lo podemos complicar tanto como queramos... 
#NUESTRO DEMONIO
#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/bin/daemonkeeper #Ruta a nuestro fichero a ejecutar
DAEMON_OPTS=''
NAME=daemonlatch            #nombre de nuestro demonio
DESC=keeper_of_seven_keys
PIDFILE="/var/run/${NAME}.pid" #Donde se guarda el pid del proceso
QUIET="--quiet"
START_OPTS="--start ${QUIET} --background --make-pidfile --pidfile ${PIDFILE} --exec ${DAEMON} ${DAEMON_OPTS}"
STOP_OPTS="--stop --pidfile ${PIDFILE}"
OWNER=root                              #el dueño del proceso
LOGDIR=/var/log/${NAME}          #donde guardaremos nuestros logs

test -x $DAEMON || exit 0

# SI NO EXISTE EL DIRECTORIO LOG, LO CREAMOS
if [ ! -d "$LOGDIR" ]; then
    mkdir -m 750 $LOGDIR
    chown $OWNER:$OWNER $LOGDIR
fi

set -e

case "$1" in
  start)
 echo -n "Starting $DESC: "
 start-stop-daemon $START_OPTS
 echo "$NAME."
 ;;
  stop)
 echo -n "Stopping $DESC: "
 start-stop-daemon $STOP_OPTS
 echo "$NAME."
        rm $PIDFILE
 ;;
  restart|force-reload)
 echo -n "Restarting $DESC: "
 start-stop-daemon $STOP_OPTS
 sleep 1
 start-stop-daemon $START_OPTS
 echo "$NAME."
 ;;
  *)
 N=/etc/init.d/$NAME
 echo "Usage: $N {start|stop|restart|force-reload}" >&2
 exit 1
 ;;
esac

exit 0
Guardaremos esta parte del demonio en /etc/init.d/ y le cambiaremos los permisos a 700. De manera que solo sea root quien pueda leer, escribir y ejecutar el archivo.

También crearemos el archivo pid en /var/run:
#chmod 700 daemonlatch 
#touch /var/run/daemonlatch.pid

Esta parte será la encargada del control; con la cual podremos parar, arrancar o re arrancar el demonio:
/etc/init.d/nombre del demonio /start/stop/restart

Ahora pasaremos a la segunda parte del demonio que llamaremos thekeeper que será la que se encargará de ver el estado de cada llave en el servidor de latch, de manera que si las dos llaves están activadas el archivo o carpeta se podrá leer, modificar,etc. según convengamos, o de lo contrario no se podrá:
#!/bin/bash
cofre=/home/manuel/importante.gpg
applicationId2="571a1Wfq8jnspoxk66pm"
secretkey2="rX2eZoqoBu6P1xWWwHVJNW15ErrlVgRcEqbtARF3"
LATCH2="/home/LATCH/latch-llave2.account"
account2=`grep "^$USER:" $LATCH2 |cut -d: -f2`
logs="/var/log/daemonlatch/daemonlatch.log"
##COMPROBAMOS LLAVE2
if [ -z `echo "$account2"|cut -d: -f2`  ]; then exit 0; fi
URL="/api/0.6/status/$account2"
requestSIgnature+="GET\n"
date2=`date -u '+%Y-%m-%d %H:%M:%S'`
requestSIgnature+="$date2\n\n$URL"
signed=`echo -en "$requestSIgnature" | openssl dgst -sha1 -hmac "$secretkey2" -binary|sed -e 's|.*= \(.*\)|\1|g'`
b64signed=`echo -n "$signed"|base64`
auth_header="Authorization: 11PATHS $applicationId2 $b64signed"
date_header="X-11Paths-Date: $date2"
JSON=`wget -q --no-check-certificate -O - --header "$auth_header" --header "$date_header" "https://latch.elevenpaths.com$URL"`
status2=`echo -e "$JSON" | sed -e 's|.*status":"\(.*\)","name.*|\1|g'`
echo $status2

##COMPROBAMOS LLAVE1

applicationId="JXM2krpxLzNxi41Ru0oe"
secretkey="SeTQQo4OzyJ02T2SB9q6qPAA8lNyWkUcA4NZdNiI"
LATCH="/home/LATCH/latch-llave1.account"
account=`grep "^$USER:" $LATCH |cut -d: -f2`
if [ -z `echo "$account"|cut -d: -f2`  ]; then exit 0; fi
URL="/api/0.6/status/$account"
requestSignature+="GET\n"
date=`date -u '+%Y-%m-%d %H:%M:%S'`
requestSignature+="$date\n\n$URL"
signed=`echo -en "$requestSignature" | openssl dgst -sha1 -hmac "$secretkey" -binary|sed -e 's|.*= \(.*\)|\1|g'`
b64signed=`echo -n "$signed"|base64`
auth_header="Authorization: 11PATHS $applicationId $b64signed"
date_header="X-11Paths-Date: $date"
JSON=`wget -q --no-check-certificate -O - --header "$auth_header" --header "$date_header" "https://latch.elevenpaths.com$URL"`
status=`echo -e "$JSON" | sed -e 's|.*status":"\(.*\)","name.*|\1|g'`
echo $status
if [ "$status" == "on" ] && [ "$status2" == "on" ]; then
date >>$logs
echo -e "cofre abierto " >> $logs
chmod 777 $cofre
elif [ "$status" == "off" ] && [ "$status2" == "off" ]; then
echo -e "cofre cerrado" >> $logs
chmod 000 $cofre
elif [ "$status" == "off" ] && [ "$status2" == "on" ]; then
echo -e "cofre cerrado" >> $logs
chmod 000 $cofre
elif [ "$status" == "on" ] && [ "$status2" == "off" ]; then
echo -e "cofre cerrado" >> $logs
echo 000 $cofre
else 
echo -e "Error de LATCH. Intenta de nuevo\n" >>$logs
echo 000 $cofre
fi

Por último haremos la tercera parte de nuestro demonio que llamaremos daemonkeeper, la colocaremos en el directorio /bin y le daremos permisos 700.

Con esta parte lo que se controlará es el tiempo que pasará entre chequear el estado de las llaves, en este caso será 30 seg.. 
#!/bin/bash
date >>/var/log/daemonlatch/daemonlatch.log
echo "demonio arrancado" >> /var/log/daemonlatch/daemonlatch.log
while true
do
sleep 30
/bin/thekeeper
done
Una vez creado nuestro demonio vamos a asignarle los niveles de ejecución o Runlevels.

Tenemos varios niveles de ejecución, y cada uno de ellos nos proporciona unas funcionalidades diferentes, y un entorno de trabajo distinto. 

La definición de cada runlevel la encontramos en el fichero /etc/inittab. En mi caso son los siguientes DEBIAN WHEEZY:

# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

Para saber en qué nivel de ejecución estamos actualmente podemos utilizar el comando runlevel. Para iniciar o parar un demonio al entrar en un runlevel simplemente tenemos que crear un enlace simbólico en el directorio correspondiente al runlevel en el que queremos iniciar/parar el demonio. Los directorios con los enlaces a los scripts de los demonios son los de /etc/rcX.d/ donde X se corresponde con el número de runlevel. Así, por ejemplo, en el directorio /etc/rc5.d/ tenemos los enlaces a los scripts de los demonios que se iniciarán/pararán al entrar en el runlevel 5. Ahora que ya sabemos dónde hemos de colocar nuestros enlaces ya podemos crearlos. 

Es muy importante el nombre que le damos a los enlaces ya que de él depende si el demonio se inicia o se para y el orden en que se inicia/para. La sintaxis que se sigue en el nombre del enlace es la siguiente: S (para iniciar el demonio apuntado por el enlace) K(para parar el demonio apuntado por el enlace) y luego el orden en que se ejecutará; que puede ir desde 00 hasta 99 (siendo 00 la máxima prioridad). Además puede haber varios con la misma prioridad. 

Bueno al tajo!! Ahora para crear los enlaces simbólicos debemos hacerlo en los runlevels adecuados. Para iniciar en el runlevel 5 (multiusuario gráfico) y 3 (multiusuario) y para pararlo en el runlevel 6 (reinicio) y 0 (apagado). Lo hacemos con el comando ln de la siguiente manera:

ln -s /etc/init.d/daemonlatch /etc/rc5.d/S30daemonlatch
ln -s /etc/init.d/daemonlatch /etc/rc3.d/S30daemonlatch
ln -s /etc/init.d/daemonlatch /etc/rc6.d/K05daemonlatch
ln -s /etc/init.d/daemonlatch /etc/rc0.d/K05daemonlatch


Ya tenemos listo nuestro demonio!!!

Tan solo nos queda probarlo. Para ello simularemos que uno de los usuarios crea un archivo cifrado que se llamará 'importante' en su /home (igual lo podemos hacer con una carpeta)
$touch /home/manuel/importante
$gpg -c /home/manuel/importante


$rm /home/importante

Esto creará importante.gpg del cual ambos usuarios tendrán la clave.

Arrancamos el demonio:

#/etc/ini.d/daemonlatch start 

Cada cierto tiempo (el que hayamos estimado en el archivo daemonkeeper) nuestro demonio conectará con el servidor de LATCH consultando el estado de las llaves...

En cuanto uno de los dos usuarios que tienen las llaves en su poder bloquee su llave en LATCH, el archivo deja de estar disponible para nadie... y no estará accesible hasta que ambos lo decidan...

Con esto hemos conseguido que estos usuarios tengan un archivo mancomunado y pleno control en el acceso, les hemos dado una capa nueva de protección...

Podríamos hacer esto más complejo y elegante, como por ejemplo llevar un sistema de log mas pensado, hacer un fichero de configuración para el demonio y que recoja las variables de él, etc, etc....

Un saludo y sean buenos...

martes, 25 de marzo de 2014

Falsificación de extensiones de ficheros en WinRAR (0-day)

Hace poco se mostraba en un blog israelí una vulnerabilidad 0-day en la versión 4.20 de WinRAR (otras versiones podrían verse también afectadas) con la que es posible engañar muy fácilmente a un usuario para que ejecute por ejemplo... un troyano. Además es sumamente sencilla de explotar...

Para nuestra PoC empezaremos creando un simple vbs 'pruebas.vbs':


MsgBox("PWNED! jajaj")

y lo comprimiremos creando el fichero 'pruebas.zip':

 
Cuando tratamos de comprimir el archivo en "formato ZIP" con WinRAR, la estructura de archivos es la estándar pero WinRAR añade varias propiedades adicionales, como un segundo nombre de archivo:



¿Qué pasa si modificamos ese nombre con nuestro editor hexadecimal por algo más "sugerente" como 'tetazas.jpg'?:



Veamos el resultado:



Al abrir el fichero comprimido nos muestra aparentemente una imagen, pero al hacer doble clic en ella se ejecutará nuestro script, es decir, hemos falsificado el nombre y la extensión del fichero comprimido ... con lo que todo ello supone...

Pórtense bien

viernes, 14 de marzo de 2014

El CCI crea un juego de mesa sobre ciberseguridad (yet another cyber WTF)


El Centro de Ciberseguridad Industrial español ha creado un juego de mesa de C*berseguridad , donde cada jugador asumirá el papel de un investigador que debe utilizar sus facultades de deducción para descubrir dónde, cómo, por qué y quién ha provocado un incidente que ha paralizado una planta industrial.

Este juego llamado Ciber Sospecha pretende servir como una herramienta profesional de concienciación y formación en cib3rseguridad para Proveedores, Administradores y Usuarios de los Sistemas de Operación industrial y los Sistemas de Información Corporativos, pero ha sido especialmente diseñado para sensibilizar a los Directivos de las organizaciones.

Que quieres que te diga, o no veo a un director o consejero jugando a este juego en casa con sus hijos, pero quizás tendría buena cabida en un taller o seminario de esos que les gusta organizar a los departamentos de RRHH (una partida suele durar entre 30 y 50 minutos y permite de 3 a 8 jugadores).

El juego estará disponible el próximo 25 de marzo, aunque ya puede reservarse. Contiene un tablero de 60x60 cm, un manual de usuario, notas de investigación, las tarjetas, las piezas de juego, dados y un sobre confidencial.

El objetivo es ser el primero en descubrir, a través de la deducción y la eliminación, en un tiempo máximo establecido por los jugadores de la partida, a la persona que ha causado el incidente de c1berseguridad que paralizó el proceso automatizado de una planta industrial, y también en cual de las ubicaciones de la planta o el cib*respacio se originó, así como qué vulnerabilidades y amenazas eran las empleadas.

Cuanto menos nos ha parecido curioso, así que acá les dejamos el enlace:

http://www.cci-es.org/web/cci/detalle-evento/-/journal_content/56/10694/58103


lunes, 10 de marzo de 2014

bWAPP: una aplicación web extremadamente insegura para practicar


bWAPP, o una aplicación web con errores (buggy web application), es una aplicación web deliberadamente insegura.

 
bWAPP ayuda a entusiastas de la seguridad, desarrolladores y estudiantes a descubrir y prevenir vulnerabilidades web. bWAPP prepara para llevar a cabo pruebas de intrusión y proyectos de hacking ético 
con éxito.

Pero ¿qué hace bWAPP tan único? Bueno, tiene más de 60 bugs web! Cubre todas las principales vulnerabilidades web conocidas, incluyendo todos los riesgos del proyecto OWASP Top 10.

bWAPP es una aplicación PHP que utiliza una base de datos MySQL. Puede ser alojada en Linux y Windows utilizando Apache/IIS y MySQL. Se puede instalar con WAMP o XAMPP.

Otra posibilidad es descargar bee-box, una VM personalizada pre-instalada con bWAPP.

Este proyecto es parte del proyecto ITSEC GAMES. ITSEC GAMES es un enfoque divertido para la educación de TI de seguridad. Seguridad informática, hacking ético, la formación y la diversión ... todo mezclado.

Web del proyecto: http://sourceforge.net/projects/bwapp/

miércoles, 5 de marzo de 2014

Malware en Android usa WhatsApp, Telegram y ChatON para suscribir números de teléfono a sistemas SMS Premium


Hace ya algún tiempo que se publicó ya el artículo de la linterna molona para Android, un software malicioso que busca generar dinero mediante una estafa de suscripción de las víctimas a sistemas de envío de mensajes SMS Premium. El esquema de Fraude Online que utilizan los creadores de ese tipo de app maliciosa para Android consiste en conseguir ejecución de la app en un terminal, desde ahí localizar el número de teléfono de la víctima y suscribirlo a un programa de mensajes SMS Premium.
Para localizar el número de teléfono la linterna molona buscaba en la app de WhatsApp el número - una forma curiosa de espiar el WhatsApp de alguien - después vía web suscribía dicho número de teléfono, y cuando llegaba el SMS con el código de confirmación lo leía y lo utilizaba para confirmar la suscripción. Este esquema se ha replicado por muchas apps, y hasta se creó una app llamada STOP Estafas SMS Premium que evalúa los permisos que tiene cualquier app para bloquear todas aquellas que puedan ser similares a la linterna molona.
Figura 1: STOP Estafas SMS Premium
El laboratorio de Eleven Paths lleva tiempo mirando en detalle cómo el malware evoluciona en Google Play, de donde salieron todas las apps fraudulentas de WhatsApp, y un detallado estudió de cómo el Crapware vive por Google Play. En uno de los análisis ha aparecido esta app, llamada Cámara Visión Nocturna - actualmente viva y disponible en Google Play - que realiza la misma estafa que la linterna molona.

Figura 2: Otra app que estafa con SMS Premium
No hace falta ser muy listo para darse cuenta de que es una estafa, ya que con mirar los comentarios de la gente se puede ver que se dedica a suscribir a las víctimas a sistemas de mensajes SMS Premium, algo que debería ser suficiente para que no se la instalase nadie. Eso sí, los tipos detrás de la estafa con BlackSEO consiguen un 3.5 de valoración media en la app

Figura 3: Algunos comentarios de la app

Para montar el esquema de la estafa, la app utiliza el conocido BroadcastReceiver que tanto se explica en el libro de Desarrollo Seguro para Android, que es utilizado de forma habitual por el malware bancario, ya que permite acceder a los mensajes SMS en los que llegan los códigos OTP de confirmación de operaciones.

Figura 4: Busca el mensaje SMS con ese texto para hacer la suscripción

Lo curioso de este malware es que tiene en cuenta el despliegue masivo de Telegram y lo de moda que está entre todos los usuarios, y como hiciéramos nosotros con Telegram Anti-Delete Protection Tool para evitar que se borren los mensajes remotamente, han debido estudiar la app en detalle para sacar más partido a su estafa. En este caso, entre las víctimas de esta app maliciosa para Android, en una sección del código se puede ver cómo además de espiar WhatsApp hace uso de Telegram para buscar el número de teléfono de la víctima y así poder suscribirlo a la web de envío de mensajes SMS Premium. Por si no fuera poco el uso de Telegram, este malware también hace uso de ChatON de Samsung para localizar el número de teléfono de la víctima.

Figura 5: Esta app busca en WhatsApp, Telegram y ChatON el número de teléfono de la víctima
Al final, el mundo del malware para Android busca cualquier modelo de negocio, ya sea vendiendo troyanos para espiar Android, creando juegos para robar el WhatsApp o haciendo estafas SMS como la linterna molona. Lo que llama poderosamente la atención es que Google Play permita que esto pase, que meter crapware sea tan fácil como falsificar WhatsApp, o que incluso suban apps que pidan las cuentas de Apple para usar iMessage o directamente suplanten el software comercial de Apple en Google Play. Parece que algo hay que cambiar en las políticas de control de las apps que se publican.