blog

La amenaza poseída por una vulnerabilidad puede cambiar con el tiempo. Tres de tales factores capturados por el CVSS son: confirmación sobre los detalles técnicos de la vulnerabilidad, el estado de remediación de la vulnerabilidad, y la disponibilidad del código del exploit u otras técnicas. Dado lo opcional de las métricas temporales, pueden incluir un valor de métrica la cual no tiene efecto sobre la puntuación. Este valor es utilizado cuando el usuario percibe la no aplicación de una métrica y desea “saltar” sobre esta.

Explotabilidad

Esta métrica mide el estado actual de las técnicas del exploit y disponibilidad del código. La disponibilidad pública de un código de exploit fácil de utilizar incrementa el número de atacantes potenciales incluyendo aquellos quienes no tienen experiencia, de este modo se incrementa la severidad de la vulnerabilidad.

Inicialmente la explotación en el mundo real puede ser solo teórico. Puede seguir la publicación de pruebas de concepto, código de exploit funcional, o suficientes detalles técnicos necesarios para explotar la vulnerabilidad. Sin embargo, el código del exploit disponible puede progresar desde una demostración de una prueba de concepto hasta un código de exploit el cual es satisfactorio en explotar la vulnerabilidad consistentemente. En varios casos, puede ser entregado como una carga útil de un gusano o virus basado en red. Los valores posibles para esta métrica se listan a continuación. Mientras más fácil puede ser explotada una vulnerabilidad, mayor la puntuación de la vulnerabilidad.

Valor de la Métrica | Descripción

• Prueba Sin Probar (U) | No está disponible un código de exploit, o un exploit es enteramente teórico.
• Prueba de Concepto (POC) | Esta disponible el código de exploit de prueba de concepto o una demostración del ataque el cual no es práctico para la mayoría de sistemas. El código o técnica no es funcional en todas las situaciones y puede requerir modificaciones substanciales por un atacante experimentado.
• Funcional (F) | Esta disponible un código de exploit funcional. Este código trabaja en la mayoría de situaciones donde existe la vulnerabilidad.
• Alto (H) | Ya sea la vulnerabilidad es explotable por código funcional autónomo móvil, o no se requiere un exploit (activación manual) y los detalles están ampliamente disponibles. El código funciona en toda situación, o está siendo activamente entregado mediante agentes móviles autónomos (como un gusano o virus).
• No definido (ND) | Asignar este valor a una métrica podría no influenciar la puntuación. Esta es una señal para saltar este métrica en la ecuación.

Nivel de Remediación (RL)

El nivel de remediación de una vulnerabilidad es un factor importante para la prioridad. Una vulnerabilidad típicamente está sin parchar cuando es inicialmente publicada. Arreglos o soluciones pueden ofrecer remediación provisional hasta la entrega del parche oficial o actualización. Cada una de estas respectivas fases se ajusta a puntuaciones temporales hacia abajo, reflejando la decreciente urgencia de una solución definitiva. Los valores posibles para esta métrica se listan a continuación. Mientras menos oficial y permanente sea la solución, es mayor la puntuación de la vulnerabilidad.

Valor de la Métrica | Descripción

• Arreglo Oficial (OF) | Esta disponible una solución completa del proveedor. Ya sea el proveedor ha entregado un parche oficial, o está disponible una actualización.
• Arreglo Temporal (TF) | Esta disponible un arreglo oficial pero temporal. Esto incluye una instancia donde el proveedor entrega una revisión, herramienta o solución temporal.
• Solución (W) | Esta disponible una solución no oficial no del proveedor. En algunos casos, los usuarios de la tecnología afectada pueden crear un parche por ellos mismos, o proporcionar los pasos para solucionar o de otra manera mitigar la vulnerabilidad.
• No Disponible (U) | No está disponible una solución o es imposible aplicarla.
• No Definida (ND) | Asignar este valor a una métrica no incluye en la puntuación. Esta es una señal para saltar esta métrica en la ecuación.

Confianza de Reporte (RC)

Esta métrica mide el grado de confidencia en la existencia de la vulnerabilidad y la credibilidad de los detalles técnicos conocidos. Algunas veces, solo se publicita la existencia de la vulnerabilidad, pero sin especificar los detalles. La vulnerabilidad puede ser luego corroborada y confirmada a través de un reconocimiento por el autor o proveedor de la tecnología afectada. La urgencia de una vulnerabilidad es mayor cuando se conoce la existencia con certeza de una vulnerabilidad. Esta métrica también sugiere el nivel de conocimiento técnico disponible a los posibles atacantes. Los valores posibles para esta métrica se listan a continuación. Mientras más validada sea una vulnerabilidad por el proveedor u otra fuente de reputación, mayor la puntuación.

Valor de la Métrica | Descripción

• Sin Confirmar (UC) | Existe una única fuente sin confirmar o posiblemente reportes diversos en conflicto. Existe poca confidencia en la validez de los reportes. Un ejemplo es un rumor generado desde el mundo subterraneo del hacking.
• Sin Corroborar (UR) | Existen diversas fuentes no oficiales, incluyendo posiblemente compañías de seguridad independientes o organizaciones de investigación. En este punto pueden estar en conflicto detalles técnicos o alguna ambiguedad persistente.
• Confirmado (C) | La vulnerabilidad ha sido reconocida por el proveedor o autor de la tecnología afectada. Esta vulnerabilidad también puede ser Confirmada cuando su existencia en confirmada desde un evento externo como la publicación de un exploit funcional de prueba de concepto o una explotación extendida.
• No Definida (ND) | Asignar este valor a una métrica no incluye en la puntuación. Esta es una señal para saltar esta métrica en la ecuación.

Fuentes:

http://www.first.org/cvss/cvss-guide
http://www.reydes.com/d/?q=Introduccion_a_CVSS_Common_Vulnerability_Sco…
http://www.reydes.com/d/?q=Metrica_Base_de_CVSS_Common_Vulnerability_Sc…

El grupo de métrica base captura las características de una vulnerabilidad constante con el tiempo y a través de ambientes de usuario. El Vector de Acceso, Complejidad de Acceso y Métricas de Autenticación capturan como la vulnerabilidad es accedida y si se requieren o no condicionales adicionales para explotarla. La métrica de impacto mide como una vulnerabilidad, si es explotada, podría directamente afectar un activo de TI, donde los impactos son definidos independientemente como el grado de perdida de confidencialidad, integridad y disponibilidad. Por ejemplo, una vulnerabilidad puede causar una perdida parcial de integridad y disponibilidad, pero no perdida de confidencialidad.

Vector de Acceso (AV)

Esta métrica refleja como es explotada la vulnerabilidad. Los posibles valores para esta métrica se listan a continuación. Mientras más remoto sea un atacante para atacar el host, mayor es la puntuación de la vulnerabilidad.

Valor de la Métrica | Descripción

Local (L) | Una vulnerabilidad explotable solo con acceso local requiere al atacante tener ya sea acceso físico al sistema vulnerable o una cuenta local (shell). Ejemplos de vulnerabilidades explotables localmente son ataques periféricos como ataques Firewire/USB DMA, y escalado de privilegios (por ejemplo, sudo).

Red Adyacente (A) | Una vulnerabilidad explotable con un acceso de red adyacente requiere al atacante tener acceso ya sea al dominio de difusión o colisión del software vulnerable. Ejemplos de redes locales incluyen subred IP local, Bluetooth, IEE 802.11, y segmentos de Ethernet local.

Red (N) | Una vulnerabilidad explotable con acceso a red significa que el software vulnerable está en la pila de red y el atacante no requiere acceso a la red local o acceso local. Esta vulnerabilidad es algunas veces denominada como “explotable remotamente”. Un ejemplo de un ataque de red es un desbordamiento de buffer RPC.

Complejidad de Acceso (AC)

Esta métrica mide la complejidad del ataque requerido para explotar la vulnerabilidad una vez el atacante gana acceso al sistema objetivo. Por ejemplo, considerar un desbordamiento de buffer en un servicio de Internet, una vez ubicado el sistema objetivo, el atacante podría lanzar el exploit a voluntad.

Otras vulnerabilidades sin embargo, pueden requerir pasos adicionales para ser explotadas. Por ejemplo, una vulnerabilidad en un cliente de correo es solo explotable después de la descarga y apertura por parte del usuario de un adjunto contaminado. Los valores posibles para esta métrica son listados a continuación. Mientras menos complejidad es requerida, mayor puntuación para la vulnerabilidad.

Valor de la Métrica | Descripción

Alta (H) | Existen condiciones especiales de acceso. Por ejemplo.

• En la mayoría de configuraciones, la parte atacante debe tener privilegios elevados o burlar sistemas adicionales en adición al sistema atacante.
• El ataque depende de métodos de ingeniería social los cuales podrían fácilmente ser detectados por gente conocedora. Por ejemplo, la victima debe realizar muchas acciones sospechosas o atípicas.
• La configuración vulnerable raramente es vista en la práctica.
• Si existe una condición de carrera, la ventana es muy estrecha.

Medium (M) | Las condiciones de acceso son un tanto especializadas, los siguientes son ejemplos:

• La parte atacante está limitada a un grupo de sistemas o usuarios con algún nivel de autorización, posiblemente no confiable.
• Debe ser obtenida alguna información antes de poder ser lanzado un ataque satisfactorio.
• La configuración afectada no es por defecto, y no es configurada comúnmente (por ejemplo, una vulnerabilidad presente cuando un servidor realiza una autenticación de cuenta de usuario mediante un esquema específico, pero no presente en otros esquemas de autenticación).
• El ataque requiere una pequeña cantidad de ingeniería social lo cual podría ocasionalmente engañar a usuarios cautelosos (por ejemplo, ataques de phishing para modificar el estado del navegador web para mostrar un enlace falso, teniendo que estar previamente en la lista de amigos de alguien antes de enviar el exploit de IM).

Bajo (L) | No existen condiciones de acceso especializado o circunstancias extenuantes. Los siguientes son ejemplos:

• El producto afectado requiere típicamente acceso a un amplio rango de sistemas y usuarios, posiblemente anónimos o no confiables. (por ejemplos, una web de cara a Internet, o servidor de correo).
• La configuración afectada es por defecto o ubicua.
• El ataque puede ser realizado manualmente y requiere poca experiencia o captura de información adicional.
• Una condición de carrera es perezosa (por ejemplo, técnicamente es una carrera, pero fácilmente ganable).

Autenticación (Au)

Esta métrica mide el número de veces el cual un atacante debe autenticarse hacia un objetivo para explotar un vulnerabilidad. Esta métrica no mide la fuerza o complejidad del proceso de autenticación, solo el requerimiento por parte del atacante de proporcionar credenciales ante de la ocurrencia de un exploit. Los valores posibles para esta métrica se listan en la siguiente tabla. Mientras menos instancias de autenticación se requieren, mayor la puntuación de la vulnerabilidad.

Valor de la Métrica | Descripción

• Varios (M) | Explotar la vulnerabilidad requiere la autenticación del atacante dos o más veces, aún si las mismas credenciales son usadas cada vez. Un ejemplo es un atacante autenticándose a un sistema operativo además de proporciona credenciales para acceder a la aplicación hospedada en este sistema.
• Único (S) | La vulnerabilidad requiere al atacante registrar su ingreso en el sistema (como en la línea de comando o mediante una sesión de escritorio o interfaz web).
• Ningún (N) | No se requiere autenticaión para explotar la vulnerabilidad.

La métrica debe ser aplicada basada en la autenticación requerida por el atacante antes de lanzar un ataque. Por ejemplo, si un servidor es vulnerable a un comando entregado antes de la autenticación del usuario, la métrica debe ser puntuada como “Ningún”, debido al lanzamiento del exploit por parte del atacante antes de requerirse las credenciales. Si el comando vulnerable es solo disponible después de una autenticación satisfactoria, entonces la vulnerabilidad debe ser puntuada como “Único” o “Varios”, dependiendo de cuantas instancias de autenticación deben ocurrir antes de entregar un comando.

Impacto a Confidencialidad (C)

Esta métrica mide el impacto sobre la confidencialidad de una vulnerabilidad explotada satisfactoriamente. La confidencialidad se refiere a limitar el acceso a la información y su exposición a únicamente usuarios autorizados, como también preservar su acceso o exposición a aquellos no autorizados. Los posibles valores para esta métrica se listan a continuación. El incremento en el impacto a la confidencialidad incrementa la puntuación de la vulnerabilidad.

Valor de la Métrica | Descripción

Ningún (N) | No existe impacto a la confidencialidad de un sistema.
Parcial (P) | Existe una considerable exposición de información. Es posible el acceso a algunos archivos del sistema, pero el atacante no tiene control sobre lo obtenido, o el alcance y la perdida está limitada. Un ejemplo es una vulnerabilidad divulgando solo ciertas tablas de una base de datos.
Completo (C) | Existe una exposición total de información, resultando en la revelación de todos los archivos del sistema. El atacante es capaz de leer todos los datos del sistema (memoria, archivos, etc.).

Impacto a Integridad (I)

Este métrica mide el impacto a la integridad de una vulnerabilidad explotada satisfactoriamente. La integridad se refiere a la confiabilidad y garantía de veracidad de la información. Los valores posibles para esta métrica son listadas a continuación. El incremento en el impacto a la integridad incrementa la puntuación de la vulnerabilidad.

Valor de la Métrica | Descripción

Ningún (N) | No existe impacto a la integridad del sistema.
Parcial (P) | Es posible la modificación de algunos archivos del sistema o información, pero el atacante no tiene control sobre lo modificable, o el alcance sobre lo afectado es limitado. Por ejemplo, los archivos del sistema o aplicación pueden ser sobrescritos o modificados, pero ya sea el atacante no tiene control sobre los archivos afectados o el atacante puede modificar solo archivos en un contexto o alcance limitado.
Completo (C) | Existe un compromiso total de la integridad del sistema. Existe una completa perdida de protección del sistema, resultando en el compromiso total del sistema. El atacante es capaz de modificar cualquier archivo sobre el sistema objetivo.

Impacto a Disponibilidad (A)

Esta métrica mide el impacto a la disponibilidad de una vulnerabilidad explotada satisfactoriamente. La disponibilidad se refiere a la accedibilidad de los recursos de información. Los ataques consumiendo ancho de banda, ciclos de procesador, o espacio en disco impactan en la disponibilidad de un sistema. Los valores posibles para esta métrica son listados a continuación. El incremento en el impacto a la disponibilidad incrementa la puntuación de la vulnerabilidad.

Valor de la Métrica | Descripción

Ningún (N) | No existe impacto en la disponibilidad del sistema.
Parcial (P) | Existen interrupciones o desempeño reducido en la disponibilidad del recurso. Un ejemplo es un ataque de inundación basado en red el cual permite un limitado número de conexiones exitosas hacia un servicio de Internet.
Completo (C) | Existe un reinicio total del recurso afectado. El atacante puede hacer el recurso completamente no disponible.

Fuentes:

http://www.first.org/cvss/cvss-guide
http://www.reydes.com/d/?q=Introduccion_a_CVSS_Common_Vulnerability_Sco…

Actualmente, la gestión de TI debe identificar y evaluar vulnerabilidades a través de diversas plataformas hardware y software dispares. Se necesita priorizar estas vulnerabilidades y remediar aquellas poseedoras de un riesgo alto. Pero cuando son muchas a arreglar, cada una debe ser puntuada utilizando diversas escalas, ¿Cómo pueden los gerentes de TI convertir esta montaña de datos sobre vulnerabilidades en información factible de ser procesada? Common Vulnerability Scoring System (CVSS) o por su traducción al idioma español, Sistema Común para la Puntuación de Vulnerabilidades, es un marco de trabajo abierto para direccionar este tema. El cual ofrece los siguientes beneficios:

• Puntuaciones Estandarizadas sobre Vulnerabilidades: Cuando una organización normaliza las puntuaciones sobre vulnerabilidades a través de todas sus plataformas de software y hardware, puede aprovechar una sencilla política para la gestión de vulnerabilidades. Esta política puede ser similar a un acuerdo para el nivel de servicio (SLA) el cual indica cuan rápidamente una vulnerabilidad en particular debe ser validada y remediada.
• Marco de Trabajo Abierto: Los usuarios pueden ser confundidos cuando se le asigna a una vulnerabilidad una puntuación arbitraria. “¿Cuales propiedades le dieron esa puntuación?”. ¿Cómo difiere de la publicada el día de ayer?. Con CVSS, cualquiera puede ver las características individuales utilizadas para derivar una puntuación.
• Riesgos Priorizados: Cuando la puntuación ambiental es computada, la vulnerabilidad se convierte ahora en contextual. Esto es, la puntuación de la vulnerabilidad es ahora representativa sobre el riesgo actual para una organización. Los usuarios conocen cuan importante es una vulnerabilidad en relación a otra vulnerabilidades.

¿Qué es CVSS?

CVSS está compuesto de tres grupos de métricas; Base, Temporal y Ambiental, cada una consistente de un conjunto de métricas.

Estas métricas de grupos son descritas a continuación:

• Base: Representa las características intrínsecas y fundamentales de una vulnerabilidad constantes sobre el tiempo y ambientes de usuario.
• Temporal: Representa las características de una vulnerabilidad cambiante sobre el tiempo, pero no entre ambientes de usuario.
• Ambiental: Representa las características de una vulnerabilidad relevante y única a un entorno de usuario particular.

El propósito del grupo base de CVSS es definir y comunicar las características fundamentales de una vulnerabilidad. Este objetivo se enfoca en caracterizar las vulnerabilidades para proporcionar a los usuarios con una representación clara e intuitiva de una vulnerabilidad. Los usuarios pueden invocar los grupos temporal y ambiental para proporcionar información contextual el cual refleje más precisamente el riesgo para un ambiente único. Esto permite tomar decisiones más informadas cuando se intenta mitigar los riesgos de las vulnerabilidades.

¿Cómo funciona CVSS?

Cuando las métricas base tiene valores asignados, la ecuación base calcula una puntuación con un rango desde 0 a 10, y se crea un vector. El vector facilita la naturaleza “abierta” del marco de trabajo. Es una cadena de texto conteniendo los valores asignados para cada métrica, y es utilizada para comunicar exactamente como la puntuación para cada vulnerabilidad es derivada. Por lo tanto el vector siempre debe ser mostrado con la puntuación de la vulnerabilidad.

Si se desea, la puntuación base puede ser refinada asignando valores a las métricas temporales y ambientales. Esto es útil para proporcionar contexto adicional para una vulnerabilidad, con un reflejo más preciso del riesgo poseído por la vulnerabilidad en el ambiente del usuario. Sin embargo esto no es requerido. Dependiendo del propósito, la puntuación base y el vector pueden ser suficiente.

Si se necesita una puntuación temporal, la ecuación temporal podría combinar métricas temporales con una puntuación base para producir una puntuación temporal con un rango desde 0 hasta 10. De manera similar, si se necesita una puntuación ambiental, la ecuación ambiental podría combinar la métricas ambientales con la puntuación temporal para producir una puntuación ambiental con un rango desde 0 a 10.

¿Quienes realizan la puntuación?

Generalmente, las métricas base y temporal son especificadas por los analistas de los boletines sobre seguridad, proveedores de seguridad para un producto, o proveedores de un aplicación, debido a la tenencia de mejor información sobre las características de una vulnerabilidad. Las métricas ambientales, sin embargo, son especificadas por los usuarios debido a la mejor capacidad de evaluar el impacto potencial de una vulnerabilidad dentro de los propios ambientes.

¿Quién posee CVSS?

CVSS está bajo la custodia y cuidado del Forum of Incident Response and Security Teams (FIRST) o Foro de Equipos de Respuesta de Incidentes y Seguridad. Ninguna organización “posee” CVSS y la afiliación en FIRST no requiere utilizar o implementar CVSS. El único requerimiento para las organizaciones es publicar puntuaciones conforme a las directrices descritas y proporcionar la puntuación además del vector de puntuación, así otros pueden comprender como fue derivada la puntuación.

¿Quienes utilizan CVSS?

Diversas organizaciones están utilizando CVSS, y cada una de ellas encontrando valor de diferentes maneras. A continuación algunos ejemplos.

• Proveedores de Boletines sobre Vulnerabilidades: Organizaciones comerciales o sin fines de lucro están publicando puntuaciones base y temporal además de vectores en sus boletines libres sobre vulnerabilidades. Estos boletines ofrecen mucho más información, incluyendo la fecha de descubrimiento, sistemas afectados, y enlaces al proveedor para las recomendaciones de solución.
• Proveedores del Software de Aplicación. Los proveedores de software de aplicación están proporcionando puntuaciones base CVSS y vectores para sus clientes. Esto los ayudar a comunicar adecuadamente la severidad de las vulnerabilidades en sus productos y ayuda a sus clientes a gestionar efectivamente su riesgo de TI.
• Organizaciones de usuarios: Diversas organizaciones del sector privado están utilizando internamente CVSS para hacer decisiones informadas sobre gestión de vulnerabilidades. Ellos utilizan tecnologías de vigilancia y escaners para localizar primero vulnerabilidades en el host y aplicaciones. Combinan estos datos con puntuaciones CVSS base, temporal y ambiental para obtener información más contextual sobre el riesgo y remediar las vulnerabilidades poseedoras de un mayor riesgo para sus sistemas.
• Gestión y Escaneo de Vulnerabilidades: Las organizaciones gestionando vulnerabilidades escanean las redes por vulnerabilidades en TI. Ellas proporcionan puntuaciones CVSS base para cada vulnerabilidad sobre cada host. Las organizaciones de usuarios utilizan flujos de datos críticos para gestionar más efectivamente sus infraestructuras de TI reduciendo cortes y protegiéndolas contra amenazas de TI maliciosas o accidentales.
• Investigadores: Un marco de trabajo abierto como CVSS permite a los investigadores realizar análisis estadísticos sobre las vulnerabilidades y propiedades de la vulnerabilidad.

Definiciones rápidas.

• Vulnerabilidad: Una falla, error, debilidad, o exposición de una aplicación, sistema, dispositivo, o servicio el cual podría conducir a un fallo de confidencialidad, integridad, o disponibilidad.
• Amenaza: La probabilidad o frecuencia en la ocurrencia de un evento dañino.
• Riesgo: El impacto relativo que una vulnerabilidad explotada podría tener en el ambiente del usuario.

Fuentes:

http://www.first.org/cvss/
http://www.first.org/cvss/cvss-guide

MetaData Working Group (MWG) es un consorcio de compañías lideres en la industria de medios digitales, enfocado en los siguientes objetivos: Preservación e interoperabilidad de metadatos en imágenes digitales. Interoperabilidad y disponibilidad para todas las aplicaciones, dispositivos y servicios.

MGW publica especificaciones técnicas las cuales describen como almacenar metadatos efectivamente dentro de archivos de medios digitales. Estas especificaciones libres están a disposición de desarrolladores de software, fabricantes y proveedores de servicios de tal manera que puedan crear productos utilizando metadatos en una manera consistente, y permitir a los clientes describir, organizar y encontrar sus medios mucho mejor. Cuando es posible, estas especificaciones se basan en estándares existentes, y ayudan a crear una aproximación unificada y cohesionada para la aplicación de estos estándares.

Directrices para manejar metadatos de imagen

El compartir imágenes ha sufrido un incremento con la madurez de los servicios en Internet para almacenar, manipular, y compartir fotografías. Sin embargo, la mayoría de estándares relacionados a las imágenes están orientados hacía la documentación de la creación de una imagen o hacia el uso profesional (por ejemplo medios impresos) y gestión de imágenes. Además el solapamiento de contenido entre los estándares más comúnmente utilizados puede generar algo de confusión. Este documento describe como utilizar mejor los estándares existentes como Exif, IPTC, y XMP para direccionar las preguntas clave sobre metadatos organizacionales formuladas por muchos consumidores. La guía actualizada proporciona actualizaciones para algunos temas previamente cubiertos como codificación de texto y ubicación, sin embargo también abarca nuevos tópicos incluyendo regiones de imagen, metadatos jerárquicos, y colecciones de imagen.

Archivos de Prueba para Verificación.

Con el propósito de asegurar un comportamiento consistente con respecto a las Directrices para el manejo de la especificación de metadatos de imagen, MGW proporciona una conjunto de herramientas y archivos de evaluación para ayudar a la verificación en la correcta implementación de la especificación por un producto.

Descargado correctamente el archivo se procede a descomprimirlo, para luego ingresar al directorio de nombre “\MWG_Test_Files\bin\”

Para los siguientes ejemplos se utilizarán archivos en formato JPG descargados en el directorio de nombre “/Archivos/”.

DumpImage es una herramienta en línea de comando la cual permite hacer un volcado de todos los metadatos desde el archivo de entrada.

C:\> DumpImage.exe ..\..\Archivos\IMG_1127.jpg

De igual manea la salida generada por el comando puede ser redireccionada hacia un archivo de texto.

TweakImage es una herramienta en linea de comando la cual permite alterar los metadatos en un archivo de entrada basado en las Directrices.

Para el siguiente ejemplo se modifica DateTime, DateTimeOriginal y DateTimeDigitized, a una fecha y hora definida futura.

C:\> TweakImage read ..\..\Archivos\IMG_1127.jpg set exif dates 2088-07-27T17:17:17-05:00 write imagen1.jpg

Para propósito del ejemplo se ha procedido a definir la salida hacia el archivo de nombre “imagen1.jpg”, el cual contiene los metadatos modificados. Para volcarlos se utilizará nuevamente el comando DumpImage.

C:\> DumpImage.exe imagen1.jpg

Se visualiza la modificación de los metadatos con la nuevos datos definidos. Esta misma definición de valores se puede aplicar a “description”, “copyright”, “creator”, “dates”, “rating”, entre otros.

Sugiero la lectura del documento conteniendo las Directrices para el manejo de metadatos en imágenes, y el archivo PDF de nombre “MWG Test Files.pdf”, la cual explica la convención de nombramiento de los archivos y actúa como una guía para los archivos. Utilizando esto con los archivos de prueba, los lectores e implementadores pueden saber lo que se espera sobre los metadatos.

Fuentes:

http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf
http://www.metadataworkinggroup.org/specs/test_files.html
http://www.adobe.com/devnet/xmp.html

Las expresiones regulares son maneras de describir un conjunto de cadenas basados en características comunes compartidas por cada cadena en el conjunto. Estas pueden ser utilizadas para buscar, editar, o manipular texto y datos. Es útil aprender la sintaxis específica para crear expresiones regulares, esto va más allá de la sintaxis normal del lenguaje de programación Java. Las expresiones regulares varían en complejidad, pero una vez comprendido lo básico sobre su construcción, se será capaz de descifrar (o crear) cualquier expresión regular.

Los siguientes ejemplos descifran las cuatro expresiones regulares incluidas en Autopsy 3, relacionadas a Direcciones de Correo Electrónico, Número de Teléfono, Direcciones IP y URL.

Número de Teléfono

[(]{0,1}\\d\\d\\d[)]{0,1}[\\.-]\\d\\d\\d[\\.-]\\d\\d\\d\\d

El caracter entre corchetes representa el mismo caracter.
X{n, m}Representa al menos lo precedente n veces, pero no más de m veces.
\\ Representa el caracter slash.
\d Representa un dígito [0-9]

Direcciones IP

(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])

- El guión representa un rango entre corchetes.
| La tubería es el operador lógico OR.
X{n} Representa X al menos un número n de veces.
\\ Representa el caracter slash.

Antes de continuar con los dos ejemplos siguientes, mencionar un concepto sobre los Grupos y Capturas.

Número de Grupo:

La captura de grupos son numerados contando sus paréntesis de apertura de izquierda hacia derecha. En la expresión ((A)(B(C))) por ejemplo existen 4 grupos.

1 ((A)(B(C)))
2 (A)
3 (B(C))
4 (C)

El grupo cero es sinónimo de toda la expresión.

La captura de grupos es así denominada debido, durante una comparación, cada subsecuencia de la secuencia de entrada que corresponde al grupo es guardada. La subsecuencia capturada puede ser utilizada luego en la expresión, mediante una nueva referencia, y también puede ser recuperada desde el comparador una vez completada la operación de comparación.

Nombre de Grupo

A un grupo de captura también se le puede asignar un “nombre”, un grupo de captura nombrado, y luego ser posteriormente referenciado de nuevo por este “nombre”. Los nombres de grupo están constituidos de los siguientes caracteres. El primer caracter debe ser una letra.

Las letras mayúsculas 'A' a 'Z' ('\ u0041' al '\ u005a'),
Las letras minúsculas 'a' a 'z' ('\ u0061' al '\ u007a'),
Los dígitos '0' al '9' ('\ u0030' al '\ u0039'),

Un grupo de captura nombrado está numerado tal como se describe en el número de grupo.

La entrada capturada asociada con un grupo es siempre la subsecuencia del grupo comparado más recientemente. Si un grupo es evaluado una segunda vez debido a la cuantificación entonces su valor es el previamente capturado, en este caso, será retenido si una segunda evaluación falla. Compararla cadena “aba” contra la expresión (a(b)?)+ por ejemplo, deja dos grupos definidos a “b”. Toda la entrada capturada es descartada al inicio de cada comparación.

Los grupos que inician con (? son ya sea grupos puros de no captura que no capturan texto y no cuentarán para el total del grupo, o grupo de captura nombrado.

Direcciones de Correo

(?=.{8})[a-z0-9%+_-]+(?:\\.[a-z0-9%+_-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\\.)+[a-z]{2,4}(?<!\\.txt|\\.exe|\\.dll|\\.jpg|\\.xml)

?=X Representa X mediante una búsqueda hacia adelante positiva de anchura cero.
X+ Representa X uno o más veces.
?:X Representa X como un grupo de captura nombrado.
X* Representa X cero o más veces.
?<!X Representa X mediante una búsqueda hacia adelante negativa de anchura cero.

URLs

((((ht|f)tp(s?))\\://)|www\\.)[a-zA-Z0-9\\-\\.]+\\.([a-zA-Z]{2,5})(\\:[0-9]+)*(/($|[a-zA-Z0-9\\.\\,\\;\\?\\'\\\\+&amp;%\\$#\\=~_\\-]+))*

X? Representa X una vez o de ningún modo.
$ Representa el final de una línea.

Fuentes:

http://docs.oracle.com/javase/tutorial/essential/regex/intro.html
http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html
http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html

El kit de herramientas Apache Tika detecta y extrae metadatos y contenido de texto desde varios documentos – desde PPT, CSV hasta PDF – utilizando librerías existentes de interpretación. Tika unifica estos interpretes bajo una misma interfaz para permitir fácilmente interpretar más de mil diferentes tipos de archivos. Tika es útil para la indexación de motores de búsqueda, análisis de contenido, traducción, y mucho más.

Para construir Tika desde las fuentes se necesita Java 6 y Maven 2. Pero se puede sencillamente saltar hacia la extracción utilizando el archivo app jar de Tika encontrado en la página de descarga. Otra opción es utilizar uno de los wrappers escritos para usar Tika en otros lenguajes de programación, como Julia o Python.

Luego de descargado el archivo pertinente se procede a generar su hash SHA-1 para verificar la integridad del archivo.

La aplicación jar Tika puede ser utilizado como una utilidad en línea de comando para extraer contenido texto y metadatos desde todo tipo de archivos. Este archivo jar ejecutable contiene todas las dependencias necesarias, razón por la cual no hay necesidad de preocuparse sobre los ajustes del classpath para ejecutarlo.

$ sudo java -jar tika-app-1.6.jar -?

Microsoft Office y otras aplicaciones relacionadas producen documentos en los formatos OLE 2 y Open XML. El antiguo formato OLE 2 fue introducido en Microsoft Office versión 97 y fue el formato por defecto utilizado hasta Office versión 2007 y el nuevo formato OOXML basado en XML. Las clases “OfficeParser” y “OOXMLParser” utilizan la librería Apache POI para soportar la extracción de texto y metadatos desde documentos OLE2 y OOXML.

Se analiza un archivo en formato Microsoft Office con extensión “doc”. La opción “-t” genera una salida en texto plano del contenido del archivo.

$ sudo java -jar tika-app-1.6.jar -t ~/Archivos/manual.doc

Se procede a generar una salida únicamente de los metadatos desde el archivo con extensión “doc”. La opción “-m” permite realizar esta tarea.

$ sudo java -jar tika-app-1.6.jar -m ~/Archivos/manual.doc

La clase “ImageParser” utiliza la funcionalidad estándar java.imageir para extraer metadatos sencillos desde formatos de imagen soportados por la plataforma Java, como PNG, GIF, BMP. Metadatos de imágenes más compleja están disponibles mediante la clase “JpegParser” y las clases “TiffParser” las cuales utilizar la librería metadata-extractor para soportar extracción de metadatos Exif desde imágenes JPEG y TIFF. La clase “PSDParser” extrae metadatos desde imágenes PSD.

Se extraen los metadatos desde un archivo de imagen con extensión “jpg”.

$ sudo java -jar tika-app-1.6.jar -m ~/Archivos/vita.jpg

También se puede especificar la URL del documento a ser interpretado en lugar del nombre del archivo.

Si no se específica ningún nombre de archivo o URL (o se usa el nombre especial “-”), entonces se interpreta el flujo de datos estándar. Sino se especifica ningún argumento ni datos de entrada, se inicia el GUI.

$ sudo java -jar tika-app-1.6.jar

A través de la Interfaz Gráfica de Usuario de Tika se pueden realizar las mismas acciones realizadas mediante la línea de comando.

Mencionar la utilización de Tika y otras librerías en Autopsy 3 para extraer texto desde archivos HTML, Microsoft Office, PDF, RTF y otros formatos más.

Fuentes:

http://tika.apache.org/
http://tika.apache.org/1.6/gettingstarted.html
http://tika.apache.org/1.6/formats.html
http://www.sleuthkit.org/autopsy/keyword.php

Solr es una popular plataforma empresarial de búsqueda open source del proyecto Apache Lucene. Su principal característica incluye una poderosa búsqueda de texto completo, resaltado de coincidencias, búsqueda por facetas, indexación casi en tiempo real, clustering dinámico, integración con base de datos, manejo de documentos enriquecidos (como Word, PDF, etc.), y búsqueda geoespacial. Solr es altamente confiable, escalable y tolerante a fallos, proporcionando indexación distribuida, replicación y consulta con balanceo de carga, conmutación por error y recuperación automática, configuración centralizada y más. Solr da poder a las funcionalidades de navegación y búsqueda a varios de los sitios de Internet más grandes del mundo.

Solr está escrito en Java y se ejecuta como un servidor de búsqueda completo independiente dentro de un contenedor servlets como Jetty. Solr utiliza la librería de búsqueda Java Lucene en su núcleo para indexar y buscar texto completo, y tiene un HTTP/XML similar a REST y APIs JSON lo cual facilita su uso desde virtualmente cualquier lenguaje de programación. La poderosa configuración externa de Solr permite adaptarse a casi cualquier tipo de aplicación sin codificación Java, y tiene una amplia arquitectura de plugins cuando se requieres personalizaciones más avanzadas.

A continuación se expondrá un sencillo ejemplo para ejecutar Solr utilizando un esquema de ejemplo y algunos datos de ejemplo.

Se requiere tener instalado Java 1.7 o una versión superior. Además de Solr.

$ java -version

Descomprimir el archivo descargado.

$ sudo unzip -q sol-4.10.1.zip
$ cd solr-4.10.1/
$ ls-l

Solr puede ejecutarse en cualquier contenedor Servlet Java a elección, pero para simplificar el presente escenario, el indice de ejemplo incluye una pequeña instalación de Jetty.

Para lanzar Jetty con Solr WAR y configuración de ejemplo, ejecutar.

$ cd example/
$ ls -l
$ sudo java -jar start.jar

Lo anterior iniciará el servidor de aplicación Jetty en el puerto TCP 8983, y utilizará el terminal para mostrar la información de los registros desde Solr.

Para visualizar el funcionamiento de Solr cargar un navegador web e ingresar a la URL respectiva. Este es el punto de inicio principal para administrar Solr.

El servidor Solr está levantado y funcionando, pero no contiene ningún dato. Se puede modificar el indice de Solr enviando comandos hacia Solr para añadir (o actualizar) documentos, borrar documentos, y comprometer pendientes de adición y borrado. Estos comandos pueden estar en una diversidad de formatos.

El directorio de nombre “exampledocs” contiene archivos de ejemplos mostrando los tipos de comandos que Solr acepta, como también una utilidad en Java para enviarlos desde la línea de comando (un script shell “post.sh” también está disponible, pero se utilizará un cliente Java).

Abrir una nueva terminal, ingresar al directorio de nombre “exampledocs” y ejecutar “post.jar” sobre algunos de los archivos XML en este directorio.

$ cd exampledocs/
$ ls
$ sudo java -jar post.jar solr.xml monitor.xml

Ahora se tienen indexados dos documentos en Solr, y comprometido estos cambios. Ahora buscar por “solr” cargando la pestaña de nombre “Query” en la interfaz de administración, ingresando “solr” en la caja de texto “q”. Luego hacer clic en el botón de nombre “Execute Query”.

Los resultados serán expuestos en el lado derecho, antecedidos por la URL utilizada para la consulta.

Se puede también indexar todos los datos de ejemplo.

$ sudo java -jar post.jar *.xml

Ahora se puede buscar por todo tipo de cosas utilizando la sintaxis de consultas de Solr (un superconjunto de la sintaxis de consulta de Lucene).

• video
• name:video
• +video +price:[* TO 400]

Existen otras diversas maneras de importar datos a Solr.

• Importar registros desde una base de datos utiilzando DIH (Data Import Handler)
• Cargar un archivo CSV (valores separados por comas), incluyendo aquellos exportados por Excel o Mysql
• Enviar documentos JSON
• Indexar documento binarios somo Word y PDF con Solr Cell (ExtractingRequestHandler).
• Utilizar SolrJ para Java y otros clientes Solr para crear programáticamente documentos a enviar a Solr.

Es factible también actualizar datos, borrar datos, consultar datos de manera más elaborada, entre otra gran diversidad de acciones muy poderosas. Sugiero la lectura de la copiosa y buena documentación sobre Solr desde su sitio web oficial.

¿Porque escribir algo sobre Apache Solr?. Autopsy 3 utiliza este poderoso motor para la indexación de texto, el cual proporciona una rápida y robusta funcionalidad para la búsqueda de palabras claves.

Fuentes:

http://lucene.apache.org/solr/
http://wiki.apache.org/solr/
http://lucene.apache.org/solr/4_10_1/tutorial.html
http://www.sleuthkit.org/autopsy/keyword.php

CAINE (Computer Aided Investigative Enviroment) o por su traducción al español “Entorno de Investigación Asistido por Computadora” es una distribución GNU/Linux creado como un proyecto de Forense Digital. El manejador actual del proyecto es Nanni Bassetti.

CAINE ofrece un entorno forense completo que está organizado para integrar herramientas de software existentes como módulos y para proporcionar una interfaz gráfica amigable. Los principales objetivos en el diseño de CAINE permiten garantizar lo siguiente:

• Un entorno interoperable que apoye al investigador digital durante las cuatro fases de la investigación digital
• Una interfaz gráfica amigable
• Herramientas amigables para el usuario

CAINE 6.0 fue liberada el 6 de Octubre del año 2014. El procedimiento de instalación se describe a continuación.

Iniciar el Sistema desde el DVD o Imagen ISO sea el caso, y seleccionar la opción “Boot Live System” o Iniciar Sistema Vivo.

CAINE iniciará en modo “Vivo”.

Para cambiar la resolución de la pantalla o monitor hacer clic en “System -> Preferences -> Monitors”.

Y ajustar la configuración del Monitor.

Para iniciar la Instalación de CAINE 6 hacer clic en el ícono de color verde de nombre “Systemback (Installer)” ubicado en el escritorio. Mencionar que esta acción no inicia el proceso de instalación.

Se procede a abrir una consola y a ejecutar el instalador con los permisos de root.

$ which systemback
$ sudo systemback

Se expone un mensaje de error relacionado con el no reconocimiento de la etiqueta del disco “/dev/sda”.

Para solucionar este error se utiliza la herramienta “Parted”, la cual permite particionar un disco y redimensionar una partición también, entre otras opciones útiles.

El comando “mklabel” crea una nueva etiqueta del disco (tabla de partición). El tipo de etiqueta puede ser bsd, dvh, gpt, loop, mac, msdos, pc98, o sun.

$ sudo parted -l
$ sudo parted /dev/sda
(parted) print free
(parted) mklabel dos
(parted) print free
(parted) quit

Corregido el problema ya es factible iniciar el instalador. Ingresar la información solicitada, como el nombre de usuario, contraseña, etc.

Realizar el particionado pertinente.

Para la presente instalación de CAINE 6 se ha creado una partición SWAP de 4 GB, y otra partición para el Sistema de Archivos Raíz "ext4".

Se muestra una ventana donde se detalla el uso de un punto de restauración para instalar el sistema. Hacer clic en el botón de nombre “Start” o Iniciar.

La instalación del Sistema ha iniciado.

El Sistema se ha instalado correctamente.

Reiniciar el Sistema para empezar a utilizar CAINE 6.

Fuentes:

http://www.caine-live.net/
http://serverxpert.blogspot.com/2012/05/how-to-partition-disk-set-its-f…
http://linux.die.net/man/8/parted

En un contexto de captura de información se puede utilizar la automatización para realizar una enorme cantidad de peticiones hacia el servidor web, intentando adivinar nombres de usuarios o identificadores de funcionalidades ocultas.

Utilizando el Spidering dirigido por el usuario y el Spidering automático con Zed Attack Proxy, ya ha sido factible identificar contenidos de la aplicación, como los siguientes directorios:

ht tp://DireccionIP/DoingBusiness/
ht tp://DireccionIP/Procedures/
ht tp://DireccionIP/cgi-bin/
ht tp://DireccionIP/images/
ht tp://DireccionIP/scanbot/
ht tp://DireccionIP/supplier/

El primer paso en un esfuerzo automatizado para identificar contenido oculto, podría implicar realizar peticiones a diversos nombres de directorios para encontrar directorios adicionales válidos.

Utilizando Zed Attack Proxy esto se realiza utilizando el “Fuzzer” y un archivo conteniendo una lista de palabras correspondiente a los nombres directorios a evaluar.

Seleccionar en el panel inferior la pestaña de nombre “History” o Historial, para luego seleccionar una de las interacciones. Luego en el panel superior derecho seleccionar la pestaña de nombre “Request” o Petición, para luego hacer clic en la parte final del símbolo “/”. Hacer clic derecho y seleccionar la opción “Fuzz”.

En la nueva ventana presentada seleccionar en el campo “Fuzz Category” la opción “Custom fuzzers”. Luego seleccionar el nombre del archivo a utilizar, para el propósito del ejemplo se utiliza el archivo de nombre “directory-list-2.3-small.txt”. Para iniciar el proceso hacer clic en el botón de nombre “Fuzz”.

Este procedimiento demanda una considerable cantidad de tiempo, factor dependiente del número de palabras contenidas en el archivo utilizado, congestión de la red, configuración del servidor web, entre otros.

En la pestaña de nombre “Fuzzer” ubicada en el panel inferior es factible realizar ordenamientos en base a los contenidos de cada columna, por ejemplo la columna de nombre “Status” o Estado.

No se debe asumir el hecho de interpretar la respuesta “200 Ok” como la existencia de un recurso solicitado, y una respuesta “404 Not Found” como la no existencia del mismo. Diversas aplicaciones manejan las peticiones para recursos inexistentes de un manera personalizada, algunas veces devolviendo un mensaje de error con una respuesta “200 Ok”.

Para el ejemplo realizado se ha encontrado un nuevo directorio de nombre “Backup”. La respuesta devuelta por el servidor web se visualiza en la pestaña de nombre “Response” del panel superior derecho. Adicionalmente es factible abrir este nuevo directorio en un navegador web.

Se sugiere que este procedimiento sea realizado de manera recursiva con todos los directorios descubiertos.

Fuentes:

https://code.google.com/p/zaproxy/wiki/HelpStartConceptsFuzz
https://code.google.com/p/zaproxy/
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Es común para las aplicaciones contener contenido y funcionalidades las cuales no están directamente enlazadas o no factibles de ser alcanzadas desde un contenido principal visible. Un ejemplo común de esta funcionalidad es aquella implementada para propósitos de prueba o depuración la cual nunca fue removida.

Otro ejemplo surge cuando las aplicaciones presentan funcionalidades diferentes para categorías de usuarios diferentes (por ejemplo, usuarios anónimos, usuarios regulares autenticados, y administradores). Usuarios con un nivel de privilegio quienes realizan un spidering exhaustivo de la aplicación web pueden perder alguna funcionalidad la cual es visible a usuarios en otros niveles. Un atacante que descubra estas funcionalidades podría ser capaz de explotarlas para elevar privilegios dentro de la aplicación web.

Existen otros incontables casos en los cuales contenido o funcionalidad interesante puede existir, que las técnicas de mapeo previamente realizadas podrían no identificar. A continuación algunos ejemplos.

Copias de Seguridad de archivos en funcionamiento. Para el caso de páginas dinámicas, sus extensiones del archivo pueden haber sido cambiadas a una no factible de ser mapeada como ejecutable, permitiendo revisar el código fuente de la página por vulnerabilidades que luego pueden ser explotadas.

Hacer clic en la pestaña “Request” o Petición habiendo seleccionando previamente la interacción pertinente.

Para el presente ejemplo se realizará un fuzzing contra las extensiones del archivo “index.php”. En la nueva ventana presentada seleccionar el archivo de nombre “extensiones.txt”, para luego hacer clic en el botón “Fuzz”.

En los resultados obtenidos es sencillo identificar la existencia de un archivo de nombre “index.bak”. Para esto solo verificar la información expuesta principalmente por las columnas “Status” o Estado y “Reason” o Razón.

Este archivo puede ser descargado, el cual al visualizarlo expone código PHP.

También es factible encontrar copias de seguridad o de respaldo (Backups) conteniendo una captura completa de un conjunto o la totalidad de los archivos dentro del directorio web raíz, permitiendo fácilmente identificar todo el contenido y funcionalidad dentro de la aplicación.

Para el siguiente ejemplo se hace una inferencia en base al nombre del directorio en el cual reside la aplicación, dado que el directorio tiene asignado el nombre “joomla” se buscarán en la raíz del servidor web, archivos comprimidos con este nombre.

Se realiza una petición con una extensión aleatoria, para luego seleccionarla y elegir la opción “Fuzz”.

En la nueva ventana presentada se selecciona un archivo el cual contiene una lista de extensiones para archivos comprimidos.

Para visualizar los resultados hacer clic en la pestaña de nombre “Fuzzer” ubicado en el panel inferior. Nuevamente se obtiene un resultado satisfactorio dada la existencia del archivo de nombre “joomla.zip”

Este archivo también puede ser descargado, descomprimido y su contenido analizado.

Utilizando un mecanismo similar se pueden obtener versiones antiguas de archivos, archivos fuentes, archivos de configuración o inclusión, y de igual manera funcionalidades desplegadas en el servidor con propósitos de prueba.

Fuentes:

https://code.google.com/p/zaproxy/wiki/HelpStartConceptsFuzz
https://code.google.com/p/zaproxy/
http://www.file-extensions.org/filetype/extension/name/temporary-files
http://en.wikipedia.org/wiki/List_of_archive_formats