windows archivos - Sidertia by Izertis

En el contexto informático actual, cuando hablamos en el ámbito de las grandes empresas, la gestión de correo y documentación ofimática es una ardua tarea y supone una vulnerabilidad. Para ello Microsoft actualiza sus herramientas con nuevas características que nos permiten hacer más sencilla la administración de cuentas y la detección de ciertos ataques de ingeniería social destinados a los usuarios, en este caso de alto cargo.

Las cuentas administradas por altos cargos suelen tener acceso a información más sensible y contar con privilegios de acceso, Microsoft denomina a estas como cuentas prioritarias o de alta prioridad.

Lo que hace más difícil de proteger este tipo de cuentas es que, hay una gran cantidad de tráfico legítimo y necesario, pero de igual manera, tráfico irregular que suele ser spam, phishing, etc. Y es en esto en lo que se pueden basar los atacantes para realizar sus incursiones. Estudian el tráfico que fluye, tanto de correo como documentación y lo pueden utilizar para solicitar algún tipo de acceso o privilegio, incluso directamente hacerse con la cuenta.

Las mejores medidas convencionales contra este tipo de ataques, es prevenir a través de una buena política de concienciación y formación constantes, habilitando además una zona de reportes de correo sospechoso entre otros.

Desde Sidertia Solutions, somos conscientes de la problemática actual que esto conlleva y por ello hacemos esto mismo con simulacros para que nuestros empleados estén siempre alertas y minimizar riesgos, ya que tratamos con información sensible.

Además de siempre intentar concienciar a nuestros clientes de este tipo de medidas y lo importante que es su aplicación en todos los niveles y tipos de usuarios.

Microsoft incorpora continuamente herramientas de inteligencia que cada vez más ayudan a mitigar este tipo de problemáticas. Con herramientas de análisis y de control de tráfico, etiquetando como hemos dicho, los tipos de cuenta a nivel administrativo y valorando las direcciones y los dominios a los que pertenecen. Aprendiendo de ataques anteriores y mejorando el sistema de análisis con cada intento de ataque.

Microsoft 365 ha añadido dos nuevas funcionalidades para la protección en este ámbito:

Protección de cuenta prioritaria
Supervisión de flujo de correo premium.

Protección de cuentas prioritarias Microsoft

Microsoft Defender para Office 365 admite el uso de etiquetas especiales en las cuentas prioritarias que se pueden usar como filtros en alertas, informes e investigaciones.

Las etiquetas se habilitan desde el panel de seguridad:

Se añaden además dos funcionalidades extra sobre estas cuentas:

Heuristica adicional: La etiqueta de cuentas prioritarias ofrece un análisis con una heurística adicional especial que se adapta singularmente a las cuentas de cargos ejecutivos. Aprendiendo de análisis previamente

Supervisión de flujo de correo premium

La capacidad en un servicio de correo, de fluir de manera eficiente y sin dar grandes fallos, es una característica especialmente importante en estas cuentas que manejan información sensible, por tanto, esta opción que nos da la etiqueta de cuenta prioritaria, consiste en alertas para los administradores cuando los correos fallidos o pendientes de reenvío superan cierto umbral de fallo, mismo que el administrador deberá valorar con base en el tipo de cuenta prioritaria y su experiencia.

Con esta opción activada podremos ver también informes de los eventos fallidos de los últimos 15 minutos y los mensajes de correo electrónico retrasados de las últimas 6 horas que se enviaron desde cuentas prioritarias.

La sección de correo electrónico incorrecto muestra la siguiente información sobre los mensajes del usuario marcado como prioritario:

Fecha
Remitente
Destinatario
Asunto
Estado, siendo el valor de este último Fallido o Retrasado.

Requisitos a tener en cuenta:

La característica de protección de cuentas prioritarias sólo está disponible con los siguientes requisitos:

Microsoft defender para Office 365 plan 2, incluidos aquellos con Office 365 E3, Office 365 E5 o Microsoft 365 E5 Security.

La característica de supervisión de flujo de correo premium está disponible con los siguientes requisitos:

Tener al menos 5000 licencias de uno o varios de los siguientes servicios: Office 365 E3, Microsoft 365 E3, Office 365 E5, Microsoft 365 E5.
Tener al menos 50 usuarios activos mensuales para una o más cargas de trabajo principales: Teams, One Drive for Business, SharePoint Online, Exchange Online y aplicaciones de Office.

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:

https://github.com/dineshshetty/Android-InsecureBankv2/releases/tag/2.3.1

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>

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.

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.

Etiqueta: windows