?

Log in

No account? Create an account

July 23rd, 2018







Poco a poco, las organizaciones están implementando sistemas de calidad y de seguridad del código fuente, con un mayor o menor alcance. Algunos se conforman con utilizar sistemas de análisis estático de código fuente y otros van más lejos, llegando a realizar fuzzing de sus aplicaciones más críticas. Pruebas de caja blanca, gris y negra, complementan los test funcionales, para garantizar la seguridad del código. Dicho lo anterior, podemos decir, con toda seguridad, que el concepto de programación segura no es ajeno a muchas empresas fabricantes de software.

Simplificando mucho, podemos decir que un programa funciona adecuadamente, cuando recibe una entrada esperada y se comporta de forma predecible y podemos decir que es seguro, cuando recibe una entrada no esperada y también se comporta de forma predecible. Es lo que denominamos un adecuado manejo de excepciones, el santo grial de la programación segura.

Ahora bien ¿qué es la programación defensiva? pues es cuando un programa es seguro, es decir, gestiona adecuadamente todas y cada una de las excepciones posibles y además genera un log avisando de dicha contingencia. Dicho de otro modo, es una forma adecuada de explotar con fines de seguridad, nuestro notable esfuerzo en encontrar y gestionar adecuadamente cada una de las excepciones que pueden afectar negativamente a nuestro programa.

Ya he hablado de la problemática asociada al aumento del tráfico cifrado y de lo lo interesante que es explotar todas las capas del estándar OSI, siendo la información obtenida más útil para el análisis de seguridad, cuanto más cercana es la capa al usuario.

Por lo tanto, un forma de paliar de alguna forma la pérdida de visibilidad de la capa de presentación por el uso de SSL/TLS, es potenciando la información disponible en otras capas y la de aplicación, es una de las más interesantes, por ser la más cercana al usuario.

A pesar de lo evidente del concepto y lo sencillo y rentable que es su implementación, lo cierto es que no todas las aplicaciones generan logs con las excepciones que gestionan y eso es un problema que pone las cosas muy complicadas a los responsables de seguridad a la hora de correlar eventos.

Una de las cosas más interesantes de la programación defensiva, es que nos permite anticiparnos a un ataque efectivo. Pensemos por ejemplo, en el último fallo del iLO4 de HP, bastaba este mandato para tener acceso sin autenticación a la gestión del sistema en remoto:


curl -H "Connection: AAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

Bien, hasta encontrar el fallo, el atacante ha tenido que probar muchas veces, un escenario de prueba y error, lo que podría ser detectado como un Indicador de Ataque (IOA) en nuestro sistema, aunque estuviera parcheado adecuadamente o se estuviera gestionando esa excepción (por ejemplo, podemos guardar en nuestro log, que se ha recibido una cadena de 26 caracteres idénticos, cuando el programa espera una cadena que cumpla determinadas reglas de construcción de la cadena y que la cadena tiene que ser de menor tamaño).

Es decir, cuando tenemos un IOA, tenemos algo mucho mejor que un IOC, que es un Indicador de Compromiso, y que lo que nos dice realmente, es que alguien ha ya vulnerado nuestro sistema y que nos toca recuperarlo y remediar los daños.

Los IOA nos permiten una defensa proactiva y reactiva, ante los primeros intentos sin éxito de un atacante, por lo que debemos intentar obtener el mayor número posible de dichos IOA, para correlar adecuadamente y rápidamente, los ataques en curso, antes de que tengan éxito.

El concepto de programación defensiva, se podría mejorar fácilmente, por ejemplo, si además de crear un log con las excepciones que gestiona el programa, nos avisa en las aplicaciones WEB, de las inconsistencias entre los datos incluidos interfaz de usuario y la validación de los mismos, antes de guardarlos en la base de datos. Con ello, la programación defensiva también nos puede proporcionar IOAs, ante ataques contra la lógica de negocio, como por ejemplo, los ataques producidos por Burp Suite actuando como HTTP proxy, o en modo scanner e intruder.

Eso es algo parecido a correlar que alguien intenta atacar por fuerza bruta un servidor SSH, o que está haciendo un escaneo de puertos, pero aplicado a las aplicaciones, si lo detectamos al principio, sabemos que algo está pasando, es eso es lo bueno de un IOA.

Si además se lograse una taxonomía adecuada de IOAs asociados a determinados ataques tipo a la capa de aplicación, podríamos detectar los intentos de ataque con más rapidez y precisión.

El efecto sería como quemar el pajar para encontrar la aguja, lo contrario a intentar buscar una aguja en un pajarcmediante bigdata y data minning, en los correladores de eventos con bases de datos monstruosas, lo que requieren grandes recursos de máquina, aplicaciones complejas y un tiempo precioso, que no siempre se tiene ante un ataque en curso.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Latest Month

July 2018
S M T W T F S
1234567
891011121314
15161718192021
22232425262728
293031    
Powered by LiveJournal.com
Designed by Tiffany Chow