Mostrando entradas con la etiqueta Metodología. Mostrar todas las entradas
Mostrando entradas con la etiqueta Metodología. Mostrar todas las entradas
En la primera y segunda parte se ha realizado un análisis de la información (gathering) con el objetivo de disponer de una completa visión sobre la aplicación (alcance y magnitud). En este artículo se van a describir los pasos para realizar una completa revisión del código fuente de la aplicación, es lo que se conoce como Análisis Estático.

INDICE:                                                                                                                

E2: Static Analysis

En esta etapa se llevará a cabo una revisión del código fuente de la aplicación, esto puede realizarse de dos formas diferentes:

1 . Obteniendo el código fuente disponible y proporcionado por el equipo de desarrollo de la aplicación. En caso de ser una aplicación open-source, se accedería a su repositorio público.

2. Utilizando ingeniería inversa, de forma que se obtiene el código de la aplicación utilizando de-compiladores y herramientas de manipulación a bajo nivel.

Desde el punto de la seguridad los mejores resultados de una auditoria de aplicaciones se suceden cuando se tiene pleno acceso al código fuente de la aplicación, y se dispone de un entorno de pruebas para la ocasión.

A continuación, se detallan las actividades y tareas en las que se divide una Auditoria de código para aplicaciones móviles.

E2.A1: Requisitos necesarios para la Auditoria de Código                                      

E2.A1.T1 Obtener el código fuente de la aplicación a auditar.

E2.A1.T2 Revisión e identificación de los permisos requeridos por la aplicación (AndroidManifest.xml, iOS Entitlements).

E2.A1.T3 Revisión de las configuración de la aplicación en busca de estados incompletos o errores, configuración insegura, etc.

E2.A1.T4 Identificación y listado de las librerías de terceros utilizadas por la aplicación móvil. 

E2.A1.T5 Comprobar si el dispositivo Android es posible obtener acceso root / jailbreak, si es así, buscar información sobre como es posible realizar con éxito el proceso.

E2.A1.T6 Revisar e identificar las librerías dinámicas que son cargadas por la aplicación para su funcionamiento.

E2.A1.T7 Identificar los permisos que la aplicación solicita para su funcionamiento, y comprobar que dichos permisos son realmente necesarios para su correcto funcionamiento, algunas aplicaciones requieren más permisos de los que realmente necesita.

E2.A1.T8 Identificar los puntos de entrada de información, y comprobar los controles de seguridad aplicados, Ejemplos:
                 > Recepción de datos de otras aplicaciones | sanitización de input / output data
                 > Recepción de SMS
                 > Lectura de datos de una WEB
                 > Lectura de datos de un fichero almacenado en la tarjeta SD.

 E2.A2: Revisión del proceso de Autenticación                    

E2.A2.T1 Identificar las líneas de código que se encargan de manejar la autenticación de los usuarios a través de la interfaz gráfica.

E2.A2.T2 Analizar y evaluar el posible uso de técnicas de ataques de fuerza bruta para la obtención del acceso.

E2.A2.T3 Identificar y determinar que otros métodos, aparte del user / password, utiliza la aplicación:
             > Token
             > Información contextual (localización, IMEI, etc)
             > Certificados
             > Gestión de las sesiones de usuario (intercambios de información de forma segura, etc)


E2.A2.T4 En caso, de detectar la utilización de métodos visuales como método de contraseña, se deberá revisar el método de mapeado utilizado con objeto de verificar que se utiliza con un adecuado nivel de entropia.

E2.A2.T5 En caso, de que la aplicación se comunique con otras aplicaciones, se por el medio que sea (WiFi Direct, Android Beam, NFC, etc), se deberá revisar la gestión adecuada de la autenticación remota de los usuarios, prestando especial interés en la gestión de los errores de autenticación (fail logon).

E2.A2.T6 En caso de utilizar el método Single Sign On, identificar que método esta  utilizando (librerias,etc)

E2.A2.T7 Si se utiliza los SMS para la autenticación, comprobar que no se transmite información sensible comprometedora, utilización de OTP (Password de una sola vez), ¿Que otras aplicaciones tiene acceso a dichos datos?

E2.A2.T8 En caso de utilizar las notificaciones Push ¿Como gestionar la aplicación la verificación de la identidad del servidor de los datos?

 E2.A3: Revisión de los niveles de Autorización de la aplicación                               

E2.A3.T1 Identificar y revisar los permisos que se aplican sobre los ficheros creados durante la ejecución de la aplicación.

E2.A3.T2 Verificar que la aplicación no tiene acceso a otras funcionalidades fuera de los establecido en su rol.

E2.A3.T3 Identificar y localizar puntos potenciales de escalada de privilegios como son:
              > Bases de datos
              > Fichero en texto plano
              > HTTP


E2.A3.T4 Identificar puntos conflictivos del código fuente de la aplicación que pueden saltarse el flujo normal de funcionamiento de la misma. Ejemplo: Puntos de excepción.

E2.A3.T5 En caso, de tratarse de una aplicación con licencia, se debe examinar con detalle el método y el procedimiento de gestión de la misma: resgitro, activación, modificación, expiración, etc.

 E2.A4: Revisión de los métodos de almacenamiento de Información                           

E2.A4.T1 Cifrado de la Información

             > Identificación de los algoritmo de cifrado utilizados.
             > Examinar el método de gestión de la claves de cifrado.
             > Identificar los puntos débiles de dicho método de cifrado.


E2.A4.T2 Identificación y localización de los puntos donde la aplicación almacena cualquier tipo de información (tmp, SD, etc..), incluidos los servicios de backup en la nube (Dropbox, Google Drive, etc)

E2.A4.T3 Analizar el tipo de información expuesta a API de terceros, como por ejemplo: el acceso a los contactos.

E2.A5: Gestión de las comunicaciones Seguras                              

E2.A5.T1 Identificación y análisis de uso de los métodos de conexión accesibles por la aplicación (WiFi, 3G, etc)

E2.A5.T2 Análisis de la gestión de la conexión segura de la aplicación al pasar de un medio de comunicación a otro. Ej: pasar de estar conectado con WiFi a 3G, o incluso utilización mixta.

E2.A5.T3  Identificación y verificación de los certificados utilizados por la aplicación.

E2.A5.T4 Análisis de los certificados: caducidad, autoridad de certificación, válidez, revocación, seguridad, etc.

E2.A6: Información Sensible Accesible (Information Disclosure)                     
E2.A6.T1 Identificación de los puntos de exposición de información. Ejemplo: logs, cache, archivos de configuración, etc.

E2.A6.T2 Análisis de los puntos de exposición de información (PEI) para identificar posibles fugas de información sensible.

E2.A6.T3 Verificación de los PEI en los mensajes de error de la aplicación. Asegurarse que estos mensajes son correctamente gestionados impidiendo que se muestre información considerada sensible.

E2.A6.T4 Identificar y evaluar la información accesible e intercambiada por las librerías (API) de terceros.

Por ultimo si la aplicación (Apps) es una versión WEB para móviles, se deberán de tener en consideración las vulnerabilidades WEB, es decir, Analizar la aplicación en busca de:

    > XSS y HTML Injection.
    > Command Injection (si la aplicación utiliza una shell para desarrollar parte de sus tareas)
    > SQL Injection (si utiliza base de datos, o se comunica con alguna)
    > Gestión de sesiones (Cookies)
    > Proceso de Autenticación
    > Seguridad en HTML5

En todo análisis estático es muy útil realizar búsqueda en el código de cadenas de caracteres y expresiones regulares,  ya que estas podrían estar relacionadas con puntos de entrada / salida de Datos.

Con esto finalizaría el Análisis estático de la aplicación móvil, pasando a continuación a evaluar y analizar la seguridad de la aplicación en funcionamiento, es lo que se conoce Análisis Dinámico.

Pero esto, daría para hablar de ello en otra serie de artículos. Espero que os haya gustado, si es así no olvidéis compartirlo por la redes sociales.

Gracias,
un Saludo.

REFERENCIAS














Como continuación de la primera parte de esta serie, nos introducimos de lleno en la primera etapa de la metodología para un Análisis de la Seguridad de la Aplicaciones Móviles; La correspondiente a la fase de preparación y recepción de toda la información necesaria para llevar a cabo el análisis de seguridad correspondiente en las etapas siguientes.

                                                                 

 E1: Information Gathering

En la primera etapa de la metodología se establece una serie de pasos y/o tareas que el auditor deberá realizar con el objetivo de prepararse para las siguiente fases de la metodología. 

En esta etapa se llevará a cabo un reconocimiento de la aplicación con objeto de identificar la magnitud y alcance de la aplicación. Será necesario la recopilación de la información que ayude a identificar la infraestructura que proporciona soporte a la aplicación así como sus posibles vectores de ataque, esta fase también es conocida como  la fase de "Reconocimiento".

Las Actividades y tareas a realizar durante esta etapa son:

  • E1.A1: Requisitos y/o características necesarias para la Auditoria
  • E1.A2: Análisis de los requisitos de Comunicación
  • E1.A3: Análisis de las funcionalidades y/o características de la aplicación
  • E1.A4: Análisis de la arquitectura software de la aplicación
A continuación se detallan las tareas que cada una de las Actividades aquí planteadas deberían de aplicar.

E1.A1: Requisitos y/o características necesarias para la Auditoria

  • E1.A1.T1 Identificar el sistema operativo y plataforma de desarrollo (SDK) de la aplicación a auditar.
  • E1.A1.T2 Identificar la necesidad de la aplicación de utilizar un dispositivo con acceso "root" o en su defecto "jailbroken" (IOS desbloqueado).
  • E1.A1.T3 Registrar y/o configurar una cuenta de usuario destinada para las pruebas de auditoria, con objeto de disponer al menos de dos cuentas de usuario. (Ideal para realizar las pruebas de elevación de privilegios).
  • E1.A1.T4 Implementar una infraestructura / laboratorio para la realización de la auditoria / pruebas que permita la interceptación y registro de las comunicaciones de red (Man in the Middle), con soporte para realizar un bypass de los certificados de las conexiones seguras (HTTPS).

E1.A2: Análisis de los requisitos de Comunicación

  • E1.A2.T1 Registro (sniffing and logging) de todas las conexiones / comunicaciones de la aplicación, bien realizadas sobre el dispositivo móvil físicamente o en laboratorio de pruebas (simulador / emulador).
  • E1.A2.T2 Identificación de las interfaces de comunicación utilizada por la aplicación móvil: NFC, Bluetooth, Wifi, 3G/4G, VPN, etc
  • E1.A2.T3 Identificación de requisitos específicos en las comunicaciones de la aplicación para el correcto funcionamiento. Ejemplo: es necesario tener activada la WiFi para funcionar o es suficiente con tener conexión 3G/4G.
  • E1.A2.T4 Listado de los protocolos de comunicación utilizados. Identificar la necesidad y correcta utilización de los mismos. Ejemplo: Se utiliza HTTPS para transmitir datos seguros cuando es necesario, o en caso de necesidad (firewall) puede establecerse la comunicación sin cifrado (HTTP) en lugar de HTTPS, ¿es esto posible? anotar toda la información descubierta.
E1.A3: Análisis de las funcionalidades y/o características de la aplicación

  • E1.A3.T1 Utilización manual de la aplicación con el fin de establecer el flujo de trabajo, así como entender el funcionamiento básico de la aplicación. Esta tarea puede ser llevada a cabo sobre la ejecución de la aplicación en un terminal físico o en un emulador / simulador.
  • E1.A3.T2 Identificar las interacciones de la aplicación con otras aplicaciones, servicios o acceso a datos tales como: 
    • Acceso datos de contacto.
    • Acceso a información del telefono (registro de llamadas, SMS, etc).
    • Utilización de la aplicación Google Wallet (tarjeta monedero).
    • Servicios de almacenamiento en la nube (dropbox, box, drive, skydrive, icloud, etc).
    • Integración con redes sociales (facebook, twitter, tuenti, flickr, instangram, google+, etc).
    • Otras aplicaciones: Correo electrónico, block de notas, etc.
E1.A4: Análisis de la arquitectura software de la aplicación

  • E1.A4.T1 Realizar una búsqueda (motores de búsquedas, foros, repositorios de código fuente, etc) exhaustiva sobre la aplicación en Internet, con objeto de recopilar toda la información posible sobre su arquitectura interna. Ejemplo: código / librerías (API) de 3rd utilizados y/o integrados dentro de la aplicación.
  • E1.A4.T2 Identificación y recopilación de información sobre el entorno de ejecución de la aplicación en el lado del servidor (si éxiste). Ejemplo:
    • Hosting
    • Entorno de desarrollo (Rails, ASP.NET, Java, Django, etc)
    • Sistema de autenticación (Single Sign On o API)
    • API / Librerías (Adsense, Cloud, Cifrado, etc)
  • E1.A4.T3 Identificación y listado (primera impresión), en función de la información recopilada, de los posibles (potenciales) puntos de interés de la aplicación desde el punto de vista de la seguridad. Ejemplo: debilidad en la credenciales, errores, información cacheada, etc.
En la siguiente entrega continuaremos con la descripción de la segunda etapa de la metodología, la correspondiente al Análisis Estático de la aplicación móvil, en dicha fase es donde se realiza la revisión y/o auditoria del código fuente principalmente. 

Referencias:

INTRODUCCIÓN

Imagino que muchos de los lectores ya están familiarizados con las principales amenazas o riesgos que se ciernen sobre los dispositivos móviles, siendo plenamente conscientes de la proliferación de aplicaciones infectadas con #malware que continuamente acechan a nuestros dispositivos móviles.

                                                                 
Indice:

Las estadísticas de crecimiento auguran en los próximos años un crecimiento exponencial tanto en dispositivos móviles con sistemas Android / iOS como en malware especialmente diseñados para ellos. Así que cada vez se hace más necesario combatir y prevenir el #malware incluyendo en nuestros procedimientos de seguridad las aplicaciones de los dispositivos móviles corporativos y/o de empresa.

OWASP Apps Mobile - Top 10 Risks

Para llevar a cabo nuestras Auditorias de Seguridad sobre las aplicaciones para los dispositivos móviles de una forma homogénea y repetible, hace falta un estándar o metodología que establezca los pasos a seguir. A este respecto,  OWASP esta trabajando [en estado borrador] en una guía de Seguridad que ayude a estandarizar y homogeneizar las pruebas que se realizan para el análisis de seguridad en las aplicaciones móviles.

Basándome en dicha guía, he establecido una metodología que aplicada al desarrollo de aplicaciones móviles permitiría identificar los puntos débiles del software y tomar las medidas necesarias para subsanar dichos errores antes de que el producto sea puesto en producción.

METODOLOGÍA

La metodología esta pensada para ser puesta en práctica desde el punto de vista de un desarrollador de aplicaciones. De esta forma la auditoria ideal de las aplicaciones móviles sería combinar el análisis dinámico, estático y forense para conseguir cubrir el mayor área (superficie) posible de ataque.

"Análisis dinámico se utiliza para asegurar la calidad y seguridad de la aplicación software durante el proceso de ejecución, mientras que el Análisis estático es la revisión de la seguridad de la aplicación a través del código fuente de la misma, utilizado habitualmente durante la fase de desarrollo de la aplicación"
Tomando como base la "auditoria ideal" para el análisis de seguridad de las aplicaciones móviles, se construyen las siguiente tres etapas de una Auditoria para aplicaciones móviles:
  • E1: Information Gathering
  • E2: Static Analysis
  • E3: Dynamic Analysis
A continuación se describen con detalle todas las etapas, incluyendo las actividades y tareas a realizar en cada una de ellas.

E1: Information Gathering

En la primera etapa de la metodología se establece una serie de pasos y/o tareas que el auditor deberá realizar con el objetivo de prepararse para las siguiente fases de la metodología. 

En esta etapa se llevará a cabo un reconocimiento de la aplicación con objeto de identificar la magnitud y alcance de la aplicación. Será necesario la recopilación de la información que ayude a identificar la infraestructura que proporciona soporte a la aplicación así como sus posibles vectores de ataque, esta fase también es conocida como  la fase de "Reconocimiento".

Las Actividades y tareas a realizar durante esta etapa son:

  • E1.A1: Requisitos y/o características necesarias para la Auditoria
  • E1.A2: Análisis de los requisitos de Comunicación
  • E1.A3: Análisis de las funcionalidades y/o características de la aplicación
  • E1.A4: Análisis de la arquitectura software de la aplicación
En nuestro siguiente artículo se describirán las tareas asociadas a dichas actividades y se continuara con las siguientes etapas de la metodología.
¿Qué es Pentesting?

Son las palabras anglosajonas utilizadas para referirse a las técnicas y herramientas que se utilizan para evaluar la Seguridad de un Sistema. 

Habitualmente estas técnicas se realizan mediante la aplicación de un método de trabajo (metodología) que garantiza, en cierta medida, que los resultados obtenidos se obtienen de forma repetible y verificable. 

En definitiva, el pentesting es el "arte" de poner a prueba los Sistemas de Información mediante la aplicación de técnicas y/o herramientas de Hacking.

¿Por donde empiezo?

Una vez que se conoce el significado de las palabras "Pentesting", y se decide realizar un "test" al respecto, hay varios aspectos iniciales que se deberían de plantear:

Planificación: 

Antes de comenzar a lanzar herramientas, examinar y guardar los resultado es conveniente realizar una planificación tanto del tiempo necesario para la prueba como de las herramientas o tipos de pruebas que se van a realizar. Para ello se recomienda realizar un "Test Plan", que consiste en un pequeño documento que describa "brevemente" cada una de las pruebas que van a realizarse y el tiempo aproximado que llevarán.

Además, es interesante incluir dentro del "Test Plan", los objetivos que se persiguen en cada prueba, así como requisitos previos y/o nombrar las herramientas que se van a utilizar.

El Test Plan persigue dos objetivos: 

   1. Organizar y planificar la prueba que se va a realizar.
   2. Presentar ante el dueño del Sistema bajo "prueba" el proyecto, así como el tipo de pruebas que se van a realizar.

Preparación

Con la ayuda del "Test Plan" que se ha elaborado, se puede determinar los recursos (técnicos y/o humanos) necesarios para llevar a cabo el conjunto de pruebas que se recogen en dicho plan. 

En este punto, el plan elaborado proporciona la organización tanto del tiempo, como de los recursos.

Según lo incluido en Test Plan, se podrá estimar los recursos necesarios para realizar las pruebas. Una vez conocido estos, se procederá a la preparación del entorno y material necesario para realizar las pruebas.

Si las necesidades del entorno y/o sistema que va a ser "analizado" requiere de la actuación de un equipo de personas, conviene reunirse con el equipo y realizar una puesta en común del "Test Plan". Así mismo se recomienda segmentar las pruebas y asignar a uno o varios responsables por cada una de ellas.

En este punto, cada "Pentester" debe de disponer de un equipo y/o entorno de trabajo preparado y personalizado según sus preferencias y habilidades. Es decir, cada uno de los miembros del equipo, deberá preparar su entorno de trabajo con las herramientas necesarias para las pruebas de las cuál es responsable, y es fundamental que este entorno haya sido probado previamente.

Continuará en la siguiente serie ...


Designed with by Way2themes | Distributed by Blogspot Themes