MovilApp (Crypto 100): Low Pubic Exponent Attack

By @f99942

Descripcion:

La siguiente APK fue extraída por nuestro contacto interno, y creemos fue 
utilizada para acceso a la banca movil desde el celular. 

Un análisis rápido nos dio indicios de que la clase Validator desempeñaba 
tareas críticas, 
sin embargo por alguna razon cayó en desuso en versiones recientes, la función 
solo fue marcada como @Deprecated, y el código se mantiene dentro de la APK  
(busca el paquete hackdef.hcbs)

El comentario siguiente fue encontrado en el Github del desarrollador:

/***
    Esta clase se utilizaba para la encriptacion de datos entre la applicacion 
    movil y el Banco, sin embargo el arquitecto de seguridad recomendo  
    descontinuarla al detectarse una implementacion debil del algoritmo de  
    encriptacion.
    Esta clase fue marcada como Deprecated en la nueva version.
***/

Trata de encontrar la falla en el algoritmo criptografico utilizado y  
desencripta el signature que esta en la clase Validator, creemos que puede 
contener credenciales que siguen usandose en Produccion. 
 
Dichas credenciales seran la flag!

Esta herramienta te puede ayudar:
https://sourceforge.net/p/dex2jar/wiki/UserGuide/



El código de la APK, contiene una clase Validator, la cual contiene la lógica siguiente:

Empleando RSA se realiza una comparación de una cadena fija nombrada como signature, contra lo que genere la exponencianción modular(lo cual nos da el indicio de que se trata de RSA), de una cadena de integridad enviada por un servidor.

Los elementos de la exponenciación modular, N, y e, se encuentran en el código de la aplicación, siendo 3 el exponente, siendo la vulnerabilidad el exponente bajo.


Nota: hbcs.apk es igual a captureBankMovilApp.apk

Analizando la APK decompilada es posible llegar a la solución, buscando las cadenas que hacen referencia a el texto cifrado, N, y e. Sin embargo esto requiere de mas experiencia en análisis de código smali, ya que las comparaciones son fáciles de identificar, pero la exponenciación modular no se puede intuir directamente.
 


Sin embargo es posible extraer la siguiente información.
Modulo:
D10BA0E9CD6DD6C3895FCDF417DB21E581226089C6C7587FC41B3D78DFF52C0F8C29DC6BE9FCCF316832E6FF6FF0496E9E566ECBC131064EB8475D6C1BC828BE4AF454AD62CBF0D1D2CD5A598A241C52B16D8EE1DA0CA9CC56303CD070710E6C181F2A31C6887E52CF14BD76F62580A84692F88198A938490FB2DE1941B11085833DEDCA16673F4AE54BE60FE0DA6624A53DB232DCA6C5887D723C7739C476EF306019A057F1C6BE37A5B820D0919ACFFD1863D22C6FA730FE12E815359D68A4ECE1C01EF7B0ECD95991B3D971D00927995ED66ED6C9933644C4F99EC752809EAF731E69C5C0F9B034E1B8330FEFD40590C46FA179614F7AD28CD18B997369182F46F9E9BA2548C65380E53E22C99BEAA69BF6F863874530BDCE9A68EE6AFBA4E9AE0781BE5B3DF1A517C57EC1B52B4B84B71863A88A35F1C0DF0A1F8EE36C9161D2EF60472A129DB81666223EDD07F3E9D1DA4BFDD2171DBE58A036804DEFFD8FD58EB57A2A454B25C5DE925A1654D5FE670204B840129B8BC5A2D397FAF2157A8BB209A27AFF89B2F8BF18ABDA5371E0C1CF3D68C20B5E3E195F6F6312A3F8EF9788CAFB7661B79AF752159F885017BDE86C7A2EB34E277DAC367D9F5633C5900AD115EF4C8FAE5328DA215CB220B8AEFB09E302628A2BE0569EE7DC171EF3147C6ACE610271E06D5BA71403D32E2AB530765F06A1F1024CD642C49788F1DF

Exponente: 3

Texto cifrado: 
f70e150a8536de5fce562f99bd9ae0791eec0092b2353f51bad99ecbe5187a8452ed7dc77e748be965e3c52a446f0fb1f40fd0415b34182b2aa1bfdd10dc8

 
El método directo es el siguiente. Convirtiendo la aplicación a un jar, es posible decompilar el bytecode de java de manera directa.



 
El código fuente regresado es el siguiente, que es muy similar al original. (Empleando jd-gui):


Es posible obtener la información de una manera más directa y verificar en que momento se hace la comparación que valida la integridad.
Solución
Existe una gran cantidad de writeups que hacen uso de exponentes pequeños. RsaCtfTool nos puede ayudar a resolver esta tarea debido a su facilidad.




Bandera: devadmin: H4ckd3f3nd3R

Comments