Security Art Work

Durante la gestión de casos forenses, hay veces que nos encontramos en un callejón sin salida, donde tras la detección de un indicador de compromiso de carácter crítico, nos toca abordar un análisis con evidencias poco sólidas.

Es por ello, que decidí llevar a cabo el desarrollo de una herramienta de carving que se basara en la detección con reglas Yara. Dicha herramienta también debía de manejar archivos en raw y ser capaz de llevar a cabo una gran variedad de opciones sobre estos datos de manera flexible, por lo que decidí utilizar Radare2.

De esta combinación nació YaraRET, una herramienta de carving de ficheros desarrollada en Go, cuya versión estable está disponible en el repositorio de YaraRules: https://github.com/Yara-Rules/YaraRET

La versión de desarrollo puede ser encontrada en el siguiente repositorio: https://github.com/wolfvan/YaraRET

Así pues, durante el siguiente artículo se va a exponer la resolución de un caso forense ficticio con YaraRET, el cual está basado en la combinación de varios casos que me he ido encontrando desde hace unos cuantos meses. [Read more…]

Durante los últimos años han proliferado en el mercado tecnológico soluciones relacionadas con la detección del fraude a través de sistemas de inteligencia artificial basada en explotación de datos masiva (Big Data). La detección de patrones anómalos y correlación de eventos son dos de los elementos clave de éstas soluciones que permiten detectar los “inicios” de las anomalías antes de que se produzcan tanto a nivel de transacciones económicas, operacionales como de cualquier otro dato relacionado o no que se determine en un orden del tiempo o en lugar concreto.

Las soluciones FDP tienen por objetivo la correlación de eventos de manera efectiva dentro de los procesos de negocio relacionando datos de transacciones (financieras, comerciales u operativas) con determinaciones de patrones de riesgo. Así pues, basado en un modelo de datos adecuado consiguen hacernos llegar potenciales situaciones de riesgos previamente identificadas con un detalle adecuado para poder gestionar “la anomalía”.

Profundizando en las soluciones FDP (Fraud Detection and Prevention) hemos de encontrar primero aquellas que se han “encasillado” en un determinado nicho de trabajo con alta especialización y, por otro lado, las que desde la particularidad han ido adquiriendo gradualmente mayores ámbitos de aplicación. [Read more…]

Aquellos que llevamos muchos años protegiendo la información corporativa e investigando incidencias de fuga de información lo tenemos claro. No todo está detrás de un teclado en materia de secuestro de información, pérdida de datos y prevención de dichos eventos.  A pesar de ello, los esquemas de incidencia, los eventos no esperados, las acciones de las personas y el entorno no dejarán jamás de cambiar de forma sorprendente.

Básicamente hay que diferenciar tres elementos clave para determinar una incidencia de fuga de información:

Entorno: La evidencia de investigación no siempre está en un directorio, un equipo o un archivo. El entorno de fuga de información está compuesto por un conjunto de características de personas, la cultura empresarial, los medios y tiempo en que se desarrolla el proceso de fuga. En la evaluación del entorno podemos encontrar las relaciones de confianza, la segregación funcional, los sistemas de comunicación y un largo etcétera completado por las medidas de control puestas en marcha para la prevención de fuga de información.

Valor de la información:  No todas las fugas de información son importantes ni es posible prevenir el 100 % de los casos. No es lo mismo que se lleven unos resultados empresariales antes de cierre de ejercicio cuando la situación financiera es adecuada que cuando no lo es. De una manera sencilla, el valor de la información tiene una cotización dependiendo de la clasificación de la información que pudiéramos realizar más el impacto que significaría dicha fuga de información a nivel corporativo. Por lo tanto, la clasificación no es un elemento estático al que recurrir sino que proporciona el valor de impacto en caso de fuga dependiendo de un conjunto de criterios asociados al momento en que se produce, la estrategia empresarial y el valor en mercado negro (habitualmente a través de Dark Web). Existen más criterios para determinar el valor de información pero, desde luego, la categorización debe de adaptarse a la realidad del propietario de la información.

Motivación: La fuga de información corresponde a una motivación, racionalización y un esquema de vulneración. Uno de los problemas que suele aparecer en las investigaciones de fuga de información es que no se realiza dicho análisis desde una perspectiva plural y relacionada con la motivación y suele centrarse en la determinación del esquema en uno de los entornos. Es por ello que cuando hablamos de fuga de información basada en sistemas de información puede dejarse de lado el resto de elementos que constituyen la visión global del incidente. Si perdemos ésta perspectiva global, difícilmente podríamos adoptar medidas correctoras o preventivas que respondieran a una situación similar.
[Read more…]

Normalmente, cuando auditamos una aplicación web mal programada en su backend, es habitual encontrarnos con vulnerabilidades de inyección SQL. Principalmente inyecciones ciegas basadas en error o, si tenemos mucha suerte, basadas en unión de tablas. Sin embargo, lo que no es muy habitual es encontrarnos con una inyección sql fuera de banda.

Éstas no solo dependen de que la aplicación sea vulnerable sino de que el servidor tenga habilitados mecanismos que nos permitan exfiltrar la información por una banda distinta a la propia aplicación web.

El propio hecho de que los resultados sean devueltos por una vía completamente diferente, unido a que éstas pueden ser muy variadas, hace que sea muy difícil utilizar herramientas automatizadas para explotar este tipo de vulnerabilidades. Aún así, en ciertos casos donde los tiempos de respuesta de un servidor sean muy lentos o irregulares, puede merecer la pena tratar de exfiltrar la información de dicha forma.

Como ejemplo vamos a echar un vistazo a una inyección que me he encontrado recientemente en una auditoría web.

En este caso, la vulnerabilidad resultaba muy extraña puesto que el parámetro se llamaba sql***, pidiendo a gritos una inyección, pero la web no devolvía errores y no parecía ser afectada por técnicas basadas en tiempo. Sin embargo, nuestro mejor amigo Burp active scan parecía convencido de que existía una inyección en dicho parámetro.
[Read more…]