blog

Las redes inalámbricas se identifican utilizando un Service Set Identifier (SSID). Existen diversos tipo de SSIDs. Utilizados por si mismo, el termino SSID se refiere al nombre de la red inalámbrica, ya sea esta una red punto a punto constituida únicamente de clientes inalámbricos individuales intercomunicándose o una red de infraestructura con clientes retransmitiendo sobre puntos de acceso.

Siendo más específico, se tienen “Basic SSIDs” (BSSIDs), los cuales son las direcciones MAC del punto de acceso, un número de 48 bits el cual identifica de manera única cada interfaz de red inalámabrica (y sea el caso, una cableada).

El Extended SSID (ESSID) es un nombre único aplicado hacia una o más puntos de acceso ofreciendo el mismo servicio, como un acceso hacia una red cableada única. En algunos despliegues, ESSIDs únicos son aplicados para cada punto de acceso individual. En otras, todos los puntos de acceso ofreciendo acceso hacia la misma red cableada se le asignan valores ESSIDs idénticos para ayudar a fomentar el “roaming” entre varios puntos de acceso.

Hablando de manera general, cuando se analizan redes LAN inalámbricas, se desea descubrir el BSSID (la dirección MAC) y el ESSID (el nombre aplicado hacia la red inalámbrica como un todo, con un único valor típicamente aplicado para cada punto de acceso individual).

Fuentes:

https://es.wikipedia.org/wiki/SSID
https://es.wikipedia.org/wiki/BSSID
https://en.wikipedia.org/wiki/Service_set_(802.11_network)

802.11 b y g utilizan el espectro de radio de 2.4 GHz, divididas en una serie de canales. Estos canales están separados por 5 MHz, con una amplitud de canal de 22 MHz. Con este ancho en los canales es claro existirá superposición en estos canales. Para evitar la interferencia los puntos de acceso cercanos el uno del otro deben utilizar canales separados por al menos cinco canales. Esto es, para evitar superposición, un punto de acceso podría usar el Canal 1, con otro utilizando el Canal 6, y otro utilizando el Canal 11.

Los canales disponibles en los productos vendidos en diferentes países basan su diferencia en regulaciones gubernamentales para la asignación de canales. En los Estados Unidos se soportan canales desde el 1 hasta el 11. En Europa se permiten los canales desde el 1 hasta el 13. En Japon se soportan 14 canales en total.

Como un profesional en pruebas de penetración y hacking ético, es importante ser consciente de estas diferencias cuando se intenta descubrir puntos de acceso inalámbricos y atacarlos, porque se debe estar seguro es factible descubrir dispositivos sin importar el canal siendo utilizado, y se está atacando el canal apropiado.

Fuentes:

https://en.wikipedia.org/wiki/List_of_WLAN_channels

No hay nada más decepcionante durante una investigación a encontrarse en un callejón sin salida. Uno de los más frecuentes es la ausencia de registros de eventos. En ciertas investigaciones, como en casos de intrusión, los registros de eventos son cruciales para rastrear actividades a través la empresa. En otras, tales como uso inadecuado por parte de los empleados, proporcionan artefactos adicionales para fortalecer el caso, como logon después de la hora, instalación de programas o acceso hacia carpetas restringidas. Un hecho triste es la mayoría de entornos no tienen suficientemente fortalecido el registrar los eventos. Tradicionalmente el registro de eventos en Windows puede generar cantidades abrumadoras de registros si son dejados sin verificar. En entornos más regulados, como tiendas cumpliendo PCI, los registros de eventos frecuentemente están disponibles y son bien manejados.

En la mayoría de instalaciones Windows el registro de eventos esta deshabilitado. El habilitarlo requiere el administrador modifique las políticas para la auditoría de seguridad después de la instalación. Las estaciones de trabajo son donde típicamente se encuentra la menor cantidad de registros de eventos. Esto es particularmente cierto en instalaciones autónomas, pues no hay un registro de eventos habilitado por defecto. Por lo tanto en caso este sistema fuese intervenido por las fuerzas del orden, es más probable no se encuentren registros de eventos en el sistema capturado. En un entorno de Dominio o Directorio Aactivo, la política para auditoría local podría ser sobrescrita por la política de grupo el cual puede habilitar el registro de eventos local.

Muchas investigaciones asumen erróneamente los productos “Server” de Microsoft tienen habilitado un fuerte registro de eventos. Excepto para Windows Server 2003, el cual vigila logon satisfactorios, las configuraciones estándar de “Server” no tienen habilitado por defecto el registro de eventos, desde NT 3.1 hasta por ejemplo Windows Server 2012.

Por defecto la instalación para el Controlador de Dominio en Windows Server 2003 y anteriores tienen algunos registros de eventos habilitados por defecto. Los Servidores Windows 2008 tienen un registro de eventos ligeramente diferente a los otros, porque este sistema operativo proporciona opciones más detalladas de políticas dentro de las diversas categorías para auditoría. Estas opciones detalladas fueron incluidas para permitir un mejor control sobre únicamente los eventos a auditar o revisar por parte de un administrador.

Existe una línea base recomendada y bien aceptada en lo referente a las políticas de auditoría para asegurar sistemas. Esto limita el registro de eventos para uso privilegiado y rastreo de procesos, porque estas dos categorías pueden proporcionar una cantidad abrumadora de datos para cada acción realizada por cada proceso o usuario. Estos son también los eventos menos utilizados cuando se realizan investigaciones de seguridad.

Fuentes:

https://blogs.technet.microsoft.com/askds/2007/10/19/introducing-auditi…
https://technet.microsoft.com/en-us/library/cc749492(v=ws.11).aspx

Las categorías de eventos de seguridad proporciona un medio rápido con el propósito de identificar entradas en el registro de eventos, los cuales podrían ser de interés en una investigación. Siguen directamente desde las políticas de auditoría habilitadas sobre un sistema Windows. Para cada uno de estas categorías, la política de auditoría puede ser ajustada para no auditar, auditar el éxito, falla, o ya sea auditar el éxito o falla.

Cuando los eventos son activados y grabados en los registros, son marcados con la categoría específica a la cual corresponda. Cuando la auditoría está deshabilitada para cualquier categoría, se debe esperar no ver grabado ningún evento de este tipo.

Auditoría de eventos de logon para cuentas: Audita cada instancia del “login” de usuario o el “logout” desde otra computadora en la cual esta computadora es utilizada para validar la cuenta.

Auditoría para gestión de cuentas: Audita cada evento para la gestión de la cuenta sobre la computadora. Ejemplos de mantenimiento de cuenta incluye cambio de contraseñas, cuentas de usuario y modificaciones de grupo.

Auditoría de acceso al servicio de directorio: Audita el evento de un usuario accediendo hacia un objeto del Directorio Activo, el cual tiene especificada su propia lista de control de acceso al sistema (SACL).

Auditoría de eventos de logon: Audita cada instancia del “login” de usuario o el “logout” desde una computadora. Esto es diferente de la categoría “Auditoría de eventos de logon para cuentas”. Esto rastrea el evento de login hacia un servidor específico. Rastrea cual controlador de dominio autentica al usuario.

Auditoría de acceso hacia objetos: Audita el evento de un usuario accediendo hacia un objeto el cual tiene especificada su propia lista de control de acceso al sistema (SACL). Ejemplos de objetos son archivos, carpetas, llaves de registro, impresoras, etc.

Auditoría de cambio de política: Audita cada incidente de cambio a las políticas de asignación para derechos de usuario, políticas de auditoría, o políticas de confianza. Audita uso privilegiado, audita cada instancia de un usuario ejercitando un derecho de usuario.

Auditoría para el rastro del proceso: Audita información de rastreo detallado para eventos como activación de programa, salida de procesos, duplicación de manejo, y acceso indirecto a objetos.

Auditoría de eventos del sistema: Audita cuando un usuario reinicia o apaga la computadora, o cuando un evento ocurre afectando ya sea la seguridad del sistema o el registro de seguridad.

Fuentes:

https://technet.microsoft.com/en-us/library/cc766468(v=ws.29).aspx

Mientras la mayoría de registros de eventos tienen el potencial de ser útiles durante una investigación, la mayoría de preguntas buscando ser respondidas durante un investigación forense tienden a encontrar sus respuestas en el registro de eventos “Security”. Los registro de eventos “System” y “Application” almacenan información más útil para solucionar problemas relacionados a la administración del sistema. Un concepto importante es el hecho de la política de auditoría puede ser definida para activar eventos ya sean intentos fallidos o exitosos. Esto permite una auditoría más fina y proporciona la adaptación para una reducción de datos; sólo registrando la acciones exactas útiles en el entorno para un administrador de seguridad.

El registro de eventos “Security” graba una auditoría de eventos cuando una acción del usuario o sistema cumple el criterio definido por la política de auditoría en uso. Pueden proporcionar detalles sobre una variedad de acciones, incluyendo autenticación de usuarios (logons, comando runas, acceso remoto, etc.), y lo hecho por un usuario particular en el sistema después de su autenticación. Como un ejemplo; un uso privilegiado y auditoría de un objeto puede activar eventos mostrando el acceso hacia un archivo o carpeta protegida, cuando se accedió a una cuenta de usuario, además de la fecha y hora de la ocurrencia. La auditoría es también permitida sobre los ajustes de seguridad por si mismo, proporcionando un buen registro de cualquier modificación a las políticas de seguridad existentes sobre el sistema.

Como un profesional forense, es un ideal todos los eventos se registren, pero esto implica un golpe en el desempeño y almacenamiento, el cual no es posible en varios entornos. Habiendo dicho esto, la política de auditoría deberá se vetada, debido a no siempre es obvio para un profesional no relacionado a la seguridad, porque algo como intentos de logon fallidos y exitosos deben ser registrados (lo primero podría permitir rastrear una cuenta comprometida siendo utilizada a través del entorno, mientras lo último podría indicar ataques para adivinar contraseñas). Se debe tener en mente la posibilidad de adecuar la auditoría para una cuenta de usuario específico utilizando la herramienta en línea de comando de Windows “auditusr.exe”. Entonces si se sospecha del compromiso de una cuenta específica por un intruso, o se requiere una auditoría más detallada sobre cuentas específicas como Administradores de Dominio, la herramienta puede proporcionar esta capacidad.

Debido a esta naturaleza, el registro de eventos “Security” tiene más protecciones implementadas comparado a los registros de eventos “System” y “Application”. Con Windows XP SP2 el API ha sido desfasado de aplicaciones diferentes al Servicio de Seguridad de Windows para activar eventos en el registro de eventos “Security”. Esta capacidad es ahora únicamente manejada por LSASS (Local Security Authority Subsystem Service), pues es responsable de fortalecer la política de seguridad sobre el sistema. Adicionalmente, sólo las cuentas de usuario con permisos de administrador pueden revisar, exportar o limpiar los registros de eventos.

Fuentes:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa363658(v=vs…
https://technet.microsoft.com/en-us/library/cc731826(v=ws.11).aspx
https://en.wikipedia.org/wiki/Windows_Security_Log

El registro de eventos se inició con tres archivos primarios; "Security", "System" y "Application". Estos registros de eventos han mantenido su importancia a través de todas las plataformas Windows NT. A lo largo del camino se han añadido registros de eventos para realizar un registro especializado, los cuales han sido agrupados bajo los registros "Personalizados". En Windows Vista, 7, Server 2008 y posteriores, se ha expandido en gran medida el número de registros personalizados, fortaleciendo la segmentación de registros y proporcionando registros especializados para procesos como Powershell, Programador de Tares, y el Firewall de Windows.

Registro de Eventos "Security": Graba los eventos basados sobre criterios de auditoría proporcionado por las políticas de grupo global o local

Registro de Eventos "System": Graba los eventos registrados por el sistema operativo o sus componentes, como las fallas de un servicio a iniciar durante el ciclo de inicio del sistema.

Registro de Eventos "Application": Graba los eventos registrados por las aplicaciones, como la falla de Microsoft SQL Server para acceder hacia una base de datos o la alerta de un antivirus.

Servicios de Directorio: Estándar sobre los Controladores de Dominio. Graba eventos registrados por el Directorio Activo y sus servicios relacionados.

Servicio para Replicación de archivos: Estándar sobre los Controladores de Dominio. Graba actualizaciones entre la infraestructura del controlador de dominio.

Servidor DNS: Estándar sobre los servidores ejecutando el servicio DNS. Graba consultas DNS, respuestas, y otras actividades del DNS.

Fuentes:

https://technet.microsoft.com/en-us/library/cc722404(v=ws.11).aspx

Los registros de eventos como se conocen en la actualidad se originaron con el sistema operativo NT 3.1 en el año 1993. Se han realizado pequeñas actualizaciones a través de la evolución de Windows NT, pero los nombres y ubicaciones de los registros de eventos se han mantenido sin cambio hasta Windows Server 2003. El formato original del registro de eventos utilizaba la extensión ".evt". Los registros de eventos se almacenan en formato binario, complicando la búsqueda de cadenas a nivel de bytes, y son implementados utilizando un buffer circular. El buffer circular da vueltas para (eventualmente) sobrescribir las entradas más antiguas con las más recientes. Los registro de eventos anteriores a Windows Vista pueden ser encontrados en “%system root%\System32\config”

Iniciando con Windows Vista y Windows Server 2008, se han realizado cambios significativos en las estructuras de los registros de eventos, tipos de registros de eventos, y ubicación de los registros de eventos. Los registros de eventos han tenido históricamente un desempeño no óptimo en los sistemas, y por lo tanto este nuevo formato utilizando la extensión ".evtx" fue creado para solucionar este y muchos otros problemas. Las buenas noticias son, con las nuevas optimizaciones es más probable encontrar registros de eventos siendo utilizados en los nuevos sistemas operativos. Adicionalmente a los cambios radicales hacia las estructuras de los registros de eventos, Vista y versiones recientes ahora emplean un mayor número de registros, y por lo tanto una nueva carpeta es creada para hospedar más de 60 registros. Estos pueden ser encontrados en “%system root%\System32\winevt\logs”

Adicionalmente, el nuevo formato del registro de eventos (finalmente) permite a los registros de eventos ser enviados hacia un recolector remoto de registros, así entonces es importante recordar, registros de eventos adicionales puede estar disponibles en servidores externos.

Es importante también anotar las carpetas detalladas son sólo ubicaciones por defecto. El administrador puede designar ubicaciones para registros individuales dentro de las siguientes llaves del registro de Windows.

HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\System
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security

Fuentes:

https://technet.microsoft.com/en-us/library/cc722404(v=ws.11).aspx
https://technet.microsoft.com/en-us/library/dd277418.aspx
http://www.forensicswiki.org/wiki/Windows_Event_Log_(EVT)
http://forensicswiki.org/wiki/Windows_XML_Event_Log_(EVTX)

El registro de eventos de Windows proporciona una gran cantidad de información la cual puede ayudar a un investigador a juntar las piezas relevantes sobre las acciones ocurridas en el sistema. Los eventos son recolectados y almacenados por el Servicio de Registro de Eventos. De manera similar a otros artefactos forenses, es provechoso realizar el ejercicio mental de determinar cuales preguntas pueden responder los datos del registro de eventos. Algunos de los más comunes se detallan a continuación.

¿Qué ocurrió? (Identificador del Evento, Categorías del Evento, Descripción)

Los registros de eventos pueden ser crípticos para un usuario normal, pero están diseñados para proporcionar información muy específica sobre las actividades ocurridas en el sistema. Cosas como IDs de eventos y Categorías de Eventos es de ayuda para encontrar rápidamente eventos relevantes, y la descripción del evento puede proporcionar mayor información sobre su naturaleza.

¿Cual fue el día y la hora? (Marcas de Tiempo)

Las marcas de tiempo son una parte clave de los registros de eventos, pues proporcionan un contexto temporal para los eventos. Con sistemas registrando miles de eventos, las marcas de tiempo pueden también ayudar al investigador a acercar su enfoque.

¿Quienes son los usuarios involucrados? (Cuenta de Usuario, Descripción)

Cualquier cosa hecha dentro de Windows es realizado dentro del contexto de una cuenta. Se puede identificar referencias hacia usuarios específicos, como también a información sobre las actividades del sistema operativo Windows realizadas mediante una cuenta especial como System o NetworkService.

¿Cuales son los sistemas involucrados? (Nombre del Host, Dirección IP)

En un entorno de red, es muy común encontrar referencias hacia otros sistemas aparte del host, como recursos siendo accedidos remotamente. Originalmente sólo el nombre Netbios era registrado, haciendo el rastreo y la atribución mucho más difícil. En sistemas más recientes, la dirección IP es registrada dentro del registro de eventos (Cuando aplica).

¿Cuales recursos se accedieron? (Archivos, Carpetas, Impresoras, Servicios)

El Servicio de Registro de Eventos puede ser configurado para almacenar información muy granular relacionada a la utilización de varios objetos del sistema. Con casi todos los recursos considerados como un objeto, esto proporciona una muy poderosa auditoría. Como un ejemplo; puede ayudar a identificar intentos de acceso no autorizado hacia los archivos del sistema.

Fuentes:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa385780(v=vs…
https://technet.microsoft.com/en-us/library/cc722404(v=ws.11).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa385772(v=vs…

El registrar eventos proporciona una manera estándar y centralizada para el sistema operativo y aplicaciones asociadas graben información importante del software y hardware. Microsoft describe un evento como cualquier ocurrencia significativa en el sistema o programa el cual requiere ser notificado al usuario, o ser añadida una entrada en el registro. Los eventos son recolectados y almacenados por el “Event Log Service” o por su traducción al español; Servicio de Registro de Eventos. Este almacena eventos desde diversas fuentes en una única colección denominada registro de eventos.

Los registros de eventos proporcionan información histórica la cual puede ayudar a solucionar problemas de seguridad y del sistema, como también para rastrear acciones del usuario y utilización de los recursos del sistema. Sin embargo, lo grabado en estos registros depende principalmente de las aplicaciones involucradas y los ajustes del sistema. Como ejemplo, los registros de eventos de seguridad están deshabilitados por defecto en algunos sistemas Windows. Si existen, los registros de eventos pueden ser una increíble ayuda para una investigación forense, proporcionando un contexto local o de red, el cual es difícil de replicar con otros artefactos.

Fuentes:

https://technet.microsoft.com/en-us/library/cc749408(v=ws.11).aspx
https://support.microsoft.com/en-us/help/308427/how-to-view-and-manage-…

Los ataques lógicos aprovechan la naturaleza de lado del cliente de las aplicaciones Ajax. Ajax y la Web 2.0 son una gran cosa para los ataques lógicos. Esto a razón de la lógica del negocio es enviada y ejecutada sobre el lado del cliente.

Un profesional en pruebas de penetración es capaz de recorrer a través de una transacción satisfactoria. Interceptando cada paso del proceso, se puede examinar cada llamada durante el desarrollo del mismo mirando el flujo de la aplicación. Se puede llamar manualmente porciones de la transacción antes de lo esperado por la aplicación, lo cual puede permitir encontrar vulnerabilidades.

Un ejemplo clásico de ataque lógico es el referente al proceso seguido por un carrito de compras. El proceso está constituido de cuatro fases; añadir artículo a carrito, costo total, autorizar tarjeta y pagar.

Debido a la aplicación almacena el estado de cada paso, el profesional en pruebas de penetración podría llamar a la autorización de la tarjeta antes de añadir el artículo. Esto podría causar una autorización para un balance cero. Luego cuando los artículos sean añadidos, el pago podría ser llamado a continuación. La aplicación podría asumir, la autorización fue hecha antes de añadir los artículos y permitiría pagar.

Los ataques lógicos típicamente no se encuentran mediante la utilización de herramientas automáticas. Esto porque las herramientas no están diseñadas para realizar pruebas lógicas, están diseñadas para ejercitar funcionalidad y encontrar fallas existentes dentro de la funcionalidad. Para encontrar fallas lógicas, la herramienta podría necesitar ser capaz de evaluar el éxito del ataque. Por ejemplo; en la falla en el carrito de compras previamente mencionado; la herramienta podría necesitar entender esta evaluando un carrito de compras y podría también necesitar ser capaz de figurarse donde detectar lo exitoso de la transacción.

Mientras esto hace más difícil encontrar las fallas, es típicamente incluso más difícil solucionarlas. Esto porque la lógica de una aplicación es usualmente integral a la arquitectura, y el cambiarla tiene un gran impacto. Debido a esto, como profesionales en pruebas de penetración, se necesita buscar por recomendaciones las cuales puedan minimizar el riesgo de un ataque. Utilizando nuevamente el ejemplo del carrito de compras, una recomendación podría ser implementar un flujo de trabajo el cual valide las ordenes contra totales de pago antes de la entrega.

Fuentes:

http://zaproxy.blogspot.no/
https://www.owasp.org/index.php/OWASP_Mutillidae_2_Project