Autor: Israel Nadal

A través de su cuenta de Twitter, publico un hilo donde explicaba de forma sencilla y concreta, su metodología para realizar un Pentesting.

Guía para realizar un Pentesting de Israel Nadal

ESCANEO DE LA RED

nmap -sn 10.11.1.* nmap -sL 10.11.1.* nbtscan -r 10.11.1.0/24 smbtree netdiscover

ESCANEO AL HOST

nmap --top-ports 20 --open -iL iplist.txt nmap -sS -A -sV -O -p- ipaddress nmap -sU ipaddress

ESCANEO DE LOS SERVICIOS

SERVICIOS WEB Nikto dirb dirbuster wpscan otdotpwn view source davtest\cadevar droopscan joomscan LFI\RFI Test S.O. LINUX/WINDOWS snmpwalk -c public -v1 ipaddress 1 smbclient -L //ipaddress showmount -e ipaddress port rpcinfo Enum4Linux

OTROS nmap scripts (locate *nse* | grep servicename) MSF Aux Modules

POST EXPLOTACIÓN

LINUX http://linux-local-enum.sh http://inuxprivchecker.py http://linux-exploit-suggestor.sh http://unix-privesc-check.py WINDOWS wpc.exe http://windows-exploit-suggestor.py windows_privesc_check.py windows-privesc-check2.exe

ESCALADA DE PRIVILEGIOS

Acceso a servicios internos (portfwd) Añadir una cuenta WINDOWS Lista de exploits LINUX Sudo su KernelDB Searchsploit

FINALIZACIÓN

Capturas de pantalla IPConfig\WhoamI Dump hashes Dump SSH Keys Borrado de archivos Documentación final.

Me he tomado la liberta de "compartir" esta pequeña guian en el Blog para que no caiga en el olvido del timeline de Twitter.

Gracias Israel por compartir

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.

                                                                 

Indice:

- OWASP: Metodología para análisis de Seguridad en Aplicaciones Móviles (I)

- OWASP: Metodología para análisis de Seguridad en Aplicaciones Móviles (II)

- OWASP: Metodología para análisis de Seguridad en Aplicaciones Móviles (III)

                                                                 

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:

[1] OWASP Mobile Security Project - Security Testing Guide

Acaba de ser publicada por el NIST, una excelente Guia de Seguridad sobre la Gestión de Incidentes, donde e contempla desde la preparación de un equipo de respuesta ante incidentes, hasta los pasos para manejar el incidente una vez "producido".

Los pasos identificados por la guía como necesarios para la "gestión" del incidente son:

Preparación: consiste en la preparación del Sistema para resitir a los incidentes de seguridad, y configurar éstos de forma segura. Configuración segura de los Sistemas para intentar prevenir y/o reducir los incidentes de Seguridad. La guia proporciona una serie de "consejos" (técnico y/o prodedimentales) que preparan el sistema ante los incidentes de Seguridad.
 

Detección y Análisis: una vez ocurrido un suceso (evento / incidente) este debe ser identificado, categorizado, analizado, documentado y por supuesto notificado.
 

Contención, Eliminación y Recuperación: Una vez notificado, lo primero es contener el "incidente", para ello se debe de contar con un plan de contingencia, registrar las evidencias necesarias para posibles análisis forenses posteriores con la correspondiente "cadena de custodia", antes de realizar ninguna actuación en el Sistema. Una vez hecho esto, se esta en condiciones de aplicar el Plan de Contingencia, prodeceder a la contención, eliminación y recuperación de los Sistemas.
 

Lecciones aprendidas: Con objeto de evitar futuros incidentes de seguridad, es muy importante analizar lo sucedido y aprender de los errores cometidos. Además, se deberá de mantener las evidencias hasta que la investigación del incidente de seguridad se de por concluida. El periodo de retenciónn deberá de estar especificado en la política de Seguridad, o dependiendo del Sistema podrá venir impuesto por una normativa especifica.

El ultimo apartado de la guía proporciona una serie de recomendaciones, que nunca esta de mal recordar:

• Preparar todas las herramientas necesarias para la actuación en la gestión del incidente. Tener listo los equipos y juego de herramientas del Equipo de Respuesta (ERI).
• Prevenir los ataques mediante la "securización" de los Sistemas, redes y aplicaciones. Realizar periódicamente análisis de riesgos, y auditorías del Sistema
• Identificar los indicadores necesarios para generar las alertas de seguridad, por ejemplo, configurar sistema de correlación de eventos de Seguridad (SIEM).
• Crear los mecanismos necesarios, así como los canales de comunicación para informar de los incidentes de seguridad a los organismos necesarios (CERT) en caso de necesidad. Lista de teléfonos, contactos establecidos previamente, con persona de contacto, etc.
• Disponer una "baseline" en la auditoría y sistema de registro (logging) de los Sistemas, con el suficiente nivel de detalle como para poder realizar analisis forenses detallados en caso de ser necesario.
• Parametrizar el comportamiento habitual de la Red / Sistema, con objeto de categorizar mejor las amenazas, e identificar / categorizar los incidentes de seguridad.
• Establecer políticas de retención de logs, así como planes de contingencias.
• Muy importante, es establecer un "marco de referencia temporal común", todos los sistemas deberán de estar debidamente sincronizados en el tiempo.
• Crear un sistema (por ejemplo:Wiki) para compartir cada resolución de los eventos / incidentes con objeto de mantener una "base de datos" del conocimiento.
• Por supuesto, se deben de pautar / procedimentar todos los pasos necesarios para la gestión del incidente.

En la guía (SP-800-61-rev2) se puede encontrar con mayor detalle todo lo comentado en este artículo.

Descargar: NIST SP-800-61 Rev2 Computer Security Incident Handling Guide

Via @peterkruse

Level: It's aimed for Pentester / IT Security Auditor.

Now, I want to share with all you the following article, where are expose the secret storage location for password of popular windows applications.

In this context, the article is going to throw a light on those dark regions by exposing the secret storage location and encryption mechanism used by most popular applications.

The article is a complete guide (technical information and related tools) to conduct a full analysis of password file, can be useful in a penetration test or security audit work.

Here, I leave you some example:

Firefox 3.5 or earlier


[Windows XP] 
C:\Documents and Settings\<user_name>\Application Data\Mozilla\Firefox\Profiles\<random_name>.default

[Windows Vista & Windows 7] 
C:\Users\<user_name>\AppData\Roaming\Mozilla\Firefox\Profiles\<random_name>.default


Google Chrome






[Windows XP] 
C:\Documents and Settings\<user_name>\Local Settings\Application Data\Google\Chrome\User Data\Default

[Windows Vista & Windows 7]
C:\Users\<user_name>\Appdata\Local\Google\Chrome\User Data\Default
Internet Explorer 7 or earlier

Basic HTTP Authentication and single sign-on:
HKEY_CURRENT_USER\Software\Microsoft\Protected Storage System Provider

Internet Explorer 7 onwards

The sign-on passwords for each website is stored here:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2


The HTTP Basic Authentication are stored in:
[Windows XP]
C:\Documents and Settings\[username]\Application Data\Microsoft\Credentials

[Windows Vista and Windows 7]
C:\Users\[username]\AppData\Roaming\Microsoft\Credentials

For more details, you should read the original article published here.

By: https://twitter.com/#!/lostinsecurity