En el artículo anterior revisamos cómo extraer un fichero APK, en esta ocasión explicaremos cómo parchear las Apps de Android.
Una vez tenemos el fichero APK de la aplicación a analizar, es posible que detectemos una serie de comportamientos o restricciones que presenta la aplicación y que nos dificulta su análisis. Para evadir estas restricciones hay varias opciones:

  • Instrumentación dinámica de la aplicación
  • Parcheo del código Smali

Según la naturaleza de la restricción puede ser más interesante una opción que la otra, aunque desde Sidertia solemos preferir el parcheo del código Smali.
Las aplicaciones Android contienen ficheros .dex (Dalvik Executable). Estos ficheros se pueden descompilar para obtener un código de bajo nivel llamado Dalvik Bytecode. Utilizando smali/baksmali (ensamblador/desensamblador) se puede obtener una representación en un lenguaje de bajo nivel con el que se puede trabajar más fácilmente, al cual llamaremos código Smali.

Las aplicaciones Android contienen ficheros .dex (Dalvik Executable). Estos ficheros se pueden descompilar para obtener un código de bajo nivel llamado Dalvik Bytecode. Utilizando smali/baksmali (ensamblador/desensamblador) se puede obtener una representación en un lenguaje de bajo nivel con el que se puede trabajar más fácilmente, al cual llamaremos código Smali. Para este ejemplo, vamos a utilizar la APP InsecureBankv2, descargable desde: 

La cual cuenta con detección de rooteo del dispositivo y es la restricción que vamos a parchear:

El primer paso es ejecutar la utilidad apktool para desempaquetar el fichero APK y la utilidad enjarify para obtener una aproximación del código fuente de la aplicación (desde Sidertia recomendamos enjarify frente a dex2jar). Para realizar esta operación usamos el siguiente comando:

				
					apktool d <FICHERO_APK> && enjarify <FICHERO_APK>
				
			

Utilidad apktool

 

Se utiliza la opción “d” de apktool para desempaquetar la aplicación. Apktool creará una carpeta llamada como el fichero, en este caso base y enjarify creará un fichero llamado base-enjarify.jar:

 

En este caso vamos a buscar la cadena que aparece en la pantalla, aunque hay que saber que el hecho de encontrar el punto donde se produce el comportamiento o restricción puede llegar a ser más difícil que el propio parcheo. Para buscar esta cadena, ejecutamos el siguiente comando dentro del directorio que se creó por la ejecución de apktool:

				
					grep -iR "<CADENA_A_BUSCAR> "
				
			

 

Se utiliza la opción -iR de grep para que se realice una búsqueda recursiva por los diferentes subdirectorios y que la búsqueda no discrimine entre mayúsculas y minúsculas. En este punto ya sabemos que la cadena está escrita tal cual en el código (no se usa el fichero strings.xml para referenciar la cadena) y sabemos también qué fichero la contiene.

Con la utilidad JD-GUI y el fichero resultado de enjarify podemos ver el código fuente de la clase PostLogin:

 

Aunque enjarify ha dado un fallo en la función showRootStatus, se observan las siguientes cuestiones:

  • En la línea 7 se llama a la función doesSuperuserApkExist() que comprueba si está instalado el apk.
  • En la línea 16 se llama a la función doesSUexist() que comprueba si el comando “su” está disponible en el sistema

La representación de esta función en el código Smali es la siguiente:

En la imagen anterior se detalla en rojo la función doesSuperuserApkExist() y en caso de que esta función devuelva un resultado verdadero, envía la ejecución a la sección “cond_0”, donde se establece el valor de la variable local v0 al valor de v1, que es 1, por tanto v0 tomará el valor 1 y a continuación la ejecución entra en la sección “goto_0”.

Se detalla en amarillo la función doesSUexist() y en caso de que el resultado sea falso, envía la ejecución a la sección “cond_1”, donde se establece la variable local v0 con el valor 0 y se envía la ejecución a la sección “goto_0” (detallado en naranja).

En la sección “goto_0” se comprueba si el valor de la variable local v0 es igual al valor de v1. En caso de no ser igual, la ejecución va a la sección “cond_2” y se establece el mensaje de que el dispositivo no está rooteado. En caso de ser igual, la ejecución continúa y se establece el mensaje de que el dispositivo sí está rooteado.

En este momento, cuando ya tenemos un conocimiento de las operaciones que se ejecutan, aparecen varias opciones para modificar el comportamiento, en este caso vamos a optar por la modificación más sencilla que consiste en introducir un salto de ejecución al principio de la función, directamente a la sección “cond_2”. Por tanto, el inicio de la función cambia de la siguiente forma:

Llegados a este punto, lo que queda es volver a empaquetar la aplicación, firmarla, instalarla y comprobar si la modificación ha surtido el efecto que buscábamos.

Estas operaciones se explicarán en otra entrada.

 

¿Qué es el TAP?

TAP (Temporary Access Pass) es un código de acceso de tiempo limitado que permite a los usuarios registrar métodos de autenticación sin contraseña y recuperar el acceso a su cuenta sin necesidad de una contraseña.

Microsoft ha anunciado en junio que su Pase de Acceso Temporal (TAP) ya se encuentra disponible para todo el público. Fue en el mes de marzo cuando se pudo comenzar a probar esta nueva funcionalidad como public preview, ahora, oficialmente ya ha adquirido la condición de general availability.
En su lucha diaria por conseguir un equilibrio entre la seguridad y la fluidez en el trabajo, ha desarrollado esta funcionalidad como un nuevo método de autenticación sin contraseña que puede ser implementado a escala por las organizaciones, dentro del marco de operaciones de Microsoft 365.

Métodos de Autenticación

Antes de adentrarnos en las cualidades y beneficios de TAP, hagamos un repaso de algunos de los diferentes métodos de autenticación existentes y su valía respecto a la seguridad que proporcionan.

Métodos de autenticación 

 

Nivel de seguridad:

  • Malo – Contraseña: El uso de únicamente una contraseña como factor de autenticación representa la peor de las soluciones en cuanto a seguridad se refiere. Para el usuario es el método más fácil y cómodo de autenticación, pero el uso de diccionarios, fuerza bruta o ingeniería social pueden comprometer su descubrimiento.
  • Bueno – Contraseña y…: El añadir a la contraseña un segundo método de autenticación, mediante el envío de un SMS o una llamada a un dispositivo registrado, mejora la seguridad, pero tiene el inconveniente de impedir la autenticación en entornos donde no exista cobertura.
  • Mejor – Contraseña y…: Debido a los inconvenientes que podría suponer el método anterior, se establecieron nuevos métodos de autenticación multifactor. A la tradicional contraseña se le podrían añadir notificaciones push, a través de una aplicación de autenticación, así como tokens, tanto de software como de hardware, de un solo uso.
  • Lo mejor – Sin contraseña: Métodos que no hacen uso de contraseñas pueden ser Windows Hello (que basa la autenticación en biometría o pin local), mediante una aplicación de Autenticador (Single Sign-On a través de móvil) o dispositivos FIDO2 (autenticación dactilar o token hardware).

El tiempo ha demostrado que el uso de contraseñas es contraproducente para el usuario en un doble sentido, por un lado, la posibilidad de olvido por parte del usuario o la posibilidad de descubrimiento por algún actor malicioso y, por otro lado, el tiempo perdido que supone su escritura cada vez que tenemos que hacer uso de ella. 

Por este motivo, cada vez más se hace uso de métodos de autenticación sin contraseña, como el TAP de Microsoft.

Volviendo al TAP

También se puede usar un TAP para configurar dispositivos Windows, ya sea que los usuarios estén configurando directamente sus propios dispositivos o que usen Windows AutoPilot, uniendo dispositivos a Azure AD o incluso configurando Windows Hello para empresas.

Se puede instalar y configurar TAP para la organización con la directiva de métodos de autenticación. Por ejemplo, se puede limitar la asignación de TAP a usuarios y grupos específicos, limitar el uso durante un período corto o configurarlo para un uso único.

Una vez que el método de autenticación está habilitado por la directiva, un administrador de autenticación con privilegios o un administrador de autenticación puede crear un TAP para el usuario visitando la hoja de métodos de autenticación del usuario o accediendo a través de una API. También se ha agregado la capacidad de los administradores para anular los TAP existentes o eliminarlos.

El Usuario Final

Una vez que un usuario tiene un TAP válido, puede usarlo para iniciar sesión y registrar información de seguridad, como el inicio de sesión telefónico sin contraseña directamente desde la aplicación Authenticator, para agregar una clave FIDO2 desde la página “Mi información de seguridad” o incluso para configurar Windows Hello for Business en máquinas unidas a Azure AD e híbridas unidas a Azure AD. En escenarios donde se requiere MFA, TAP también se puede usar como un factor adicional.

Con esta nueva funcionalidad, Microsoft sigue desarrollando nuevas maneras de tener un entorno de trabajo cada día más seguro y eficaz. En definitiva, TAP ha venido para quedarse.