El resurgimiento del virus Conficker, que se extendió aprovechando un agujero de seguridad en Windows, violando contraseñas débiles e infectando sistemas a través de memorias USB, demuestra las graves consecuencias que pueden generar los errores en la programación de aplicaciones informáticas.

La aparición del gusano informático Conficker, también conocido como Downadup, que en las últimas semanas infectó millones de computadoras en el mundo aprovechando un error en el sistema operativo Windows, volvió a demostrar que los errores en la programación de aplicaciones tecnológicas pueden generar graves peligroso a la seguridad de las personas y a las organizaciones.
El virus explota la vulnerabilidad de Microsoft que permite a los delincuentes infectar las computadoras de los usuarios. Puede leer más sobre este código malicioso en las notas relacionadas.
La empresa de seguridad informática británica Sophos realizó una encuesta sobre quién es el responsable del nuevo estallido del Conficker. El sondeo, realizado en línea a 165 usuarios de empresas entre el 19 y el 21 de enero de 2009, indica que el 30% de los encuestados piensa que los administradores de sistemas son los mayores responsables del reciente brote del gusano, por haber sido demasiado lentos a la hora de instalar el parche de seguridad lanzado por Microsoft para el Windows.

Pero también Microsoft fue implicada, ya que el 17% de los encuestados culpa al fabricante del sistema operativo de tener un agujero de seguridad.

“La mayoría de usuarios cree que los creadores de virus son los últimos responsables por crear y lanzar este gusano, que ha afectado a empresas de todo el mundo poco protegidas”, afirmó Graham Cluley, consultor de Tecnología de Sophos “Pero lo más sorprendente es que muchos técnicos culpan a sus iguales por no realizar un mejor trabajo para defender sus redes. Muchas compañías parecen estar increíblemente frustradas por la continua necesidad de crear parches de seguridad en sus redes. Lo preocupante para Microsoft es que uno de cada cinco usuarios, lo sitúan en primer lugar como culpable de dicha vulnerabilidad”.
Microsoft había lanzado a finales de octubre de 2008 un parche de seguridad urgente para poder prevenir la infección del gusano Conficker.
En la última semana hubo un resurgimiento de este gusano que se extendió de nuevo aprovechando el agujero de seguridad, violando contraseñas débiles e infectando los sistemas vía dispositivos USB como los pen drives.

iProfesional entrevistó sobre la seguridad en el desarrollo de los códigos a Roberto G. Langdon, presidente y CEO de 2Minds, una empresa que realiza consultorías de seguridad informática en el sector corporativo. Puede leer más sobre estos problemas en las entrevistas relacionadas al final de esta nota.

-¿Por qué el código seguro no es aún una realidad?

-Los avances de los ataques de seguridad informática a las aplicaciones están creciendo cada vez más rápido, y fundamentalmente es porque todavía no existe en forma masiva, una conciencia de uso de sistemas de prevención de intrusos (los llamados sistemas IPS), y eso los cyberdelincuentes lo saben, y lo aprovechan. Aún ven grandes facilidades para realizar sus ataques, valiéndose de que los desarrolladores no están tomando en consideración todas las acciones que deben encarar actualmente, en lo que respecta a presentación de datos, gestión de datos y manipulación de datos dentro de las aplicaciones. Hasta se debe tomar control del comportamiento y manejo de los errores dentro del programa, pues justamente los mensajes de error por exceptiones de datos (o errores de datos) hacen que se presente en pantalla del browser mucha información que es de mucha utilidad para quien quiere ir obteniendo información paulatinamente, para ajustar su ataque.
Existen controles que debieran implementarse para evitar la alteración de instrucciones en el programa, y que justamente son explotadas en las instrucciones donde se deben ingresar datos en forma externa, fundamentalmente. El día que todos los desarrolladores codifiquen códigos seguros, el tipo de ataque de Inyección de Código SQL habrá quedado en el olvido, o habrá sido reemplazado por otro tipo de ataque más sofisticado.
Por otra parte, lograr un código seguro implica una mayor inversión en tiempo de los desarrolladores y de los testeadores de productos, factores generalmente escasos por urgencias en tiempos, o por escasez de recursos, o por ambos al mismo tiempo.

¿Cuáles son las técnicas que deberían aplicarse para aumentar los controles?

-A los propios mecanismos de protección y segurización del código, se deben agregar controles de hash, de fechas y de otros datos que permitan “autenticar” que la versión en ejecución es la efectivamente colocada en producción, y no ha cambiado. Quizás parezca paranoico, pero son consideraciones que se deben tomar ahora, que hace unos años atrás eran innecesarias, pero que actualmente es frecuente la detección de situaciones delictivas habiendo tomado control de la aplicación, modificarla, y reemplazar la que está en vigencia.

Eso sí, a la codificación segura de aplicaciones se la debe acompañar de una protección perimetral acorde a las circunstancias actuales.

-¿Las empresas desarrolladoras de software están preocupadas para que el código que escriben sea más seguro?
-Debieran estarlo, porque cualquier alteración que sus productos permitan ejecuciones no deseadas, van en contra del buen nombre del producto.

¿Qué medidas están tomando en ese sentido?

Voy a indicar cuales serían las medidas que deberían tomar en este sentido, y que se pueden abrir en dos grupos: el primer grupo corresponde a la etapa de desarrollo, y el segundo grupo a la etapa de testeo.
En el primer grupo, se debe contar con recursos de control y auditoría de código, para no solamente verificar la calidad del mismo, sino también asegurarse que se han tomado acciones para proteger el código y los datos que maneja. Se debe hacer hincapié en como se controla el dato de entrada y sus características, como se rechazan los caracteres no habilitados (metacaracteres, por ejemplo), como se manipulan los nombres de usuario y sus passwords, para que luego de haber sido autenticados, no queden disponibles para que cualquiera pueda obtenerlos provocando un vuelco de memoria.
En el segundo grupo, además de verificar que los sets de prueba arrojen resultados esperados, se deben someter las aplicaciones a tests de penetración, que dentro de sus rutinas, verifican el comportamiento de la aplicación ante diversos tipos de ataques, y detectan e identifican estos expuestos para que sean resueltos por la gente de desarrollo. Es mandatorio que el grupo de desarrollo sea distinto al del grupo de test.

-¿Se debe replantear por completo la forma en que se escribe el código?
-Se debe capacitar a los desarrolladores en las técnicas de codificación segura, valiéndose de documentación emanada por la ISO, que en todo lo relacionado a calidad y desarrollo de software tiene mucho camino transitado. La seguridad informática se ha convertido en una disciplina por sí misma, y como tal, debe ser difundida tanto en el grupo de desarrollo como en el de test. Yo me pregunto cuántas empresas de desarrollo de software finalizan su trabajo con un test de penetración, para determinar que efectivamente su producto está a prueba de las condiciones en vigencia. Pareciera que ese es un problema del usuario, pero en realidad debiera ser del desarrollador.

César Dergarabedian
(©) iProfesional.com


Link relacionados:
-La seguridad en el código informático es cada vez más una inquietud de todos
-La mayoría del software no es suficientemente seguro