Los Desarrolladores son los Culpables.

Ok, ok, no quiero a decenas de desarrolladores comentando este post con mensajes de odio ;). Sólo estaba pensando el otro día lo mucho que criticamos a los usuarios por ser “el eslabón más débil”, por “no tener ni idea” o “ser poco inteligentes”.

Pero si se ponen a pensar, realmente la mayoría de las amenazas que pululan en Internet, en las redes internas y sistemas son originados o facilitados por las vulnerabilidades presentes en sistemas operativos y aplicaciones. Tenemos al fulano que le roban su dinero al usar banca en línea, o la computadora que es usada para ser parte de una bot y más recientemente, un ataque a los sistemas de una planta nuclear.

Inyección de SQL, cross site scripting, troyanos y gusanos que aprovechan debilidades de software para concretar sus objetivos. Un reciente ejemplo fue la conferencia de BlackHat de este año que estuvo nutrida por demostraciones de debilidades…en software: http://tinyurl.com/BlackH11.

Sí claro, ya que se explota la debilidad de software, muchas veces el usuario ayudará a finalizar el ataque. Sin embargo piensen en un mundo imaginario donde el software no tiene vulnerabilidades: cuántos ataques se podrían llevar a cabo? Se me ocurre el phishing donde el usuario da su usuario/contraseña en un sitio web falso. No intervino ninguna debilidad de software…el usuario es el “culpable”.

Pero salvo en algunas excepciones, realmente el problema de raíz es el software que si bien funciona, tiene buffer overflows y demás imperfecciones que hacen posible en primera instancia que un ataque sea exitoso. Hay desarrolladores detrás de Adobe Reader, Windows, Adobe Flash, Java JRE, QuickTime, Linux, Safari, Office o Mac OSX…todas ellas con debilidades. Sin mencionar las aplicaciones que se hacen en las corporaciones e instituciones de todo el mundo.

Y no siendo suficiente el hecho de meterle debilidades al software, los desarrolladores y diseñadores no le agregan la funcionalidad de actualización automática a la aplicación (esto último ya ha estado cambiando en Windows y algunas aplicaciones).

En fin, lo anterior se lo comenté a un desarrollador durante una plática y me dijo:

a) El aprendizaje que recibí y recibo para codificar no involucró la parte de seguridad. La escuela no lo hizo y mi empresa tampoco me da una capacitación al respecto, sólo me queda hacerlo por mí mismo…sin embargo mis empleadores no valorarían esa inversión de tiempo porque lo que quieren es que la aplicación jale. Sinceramente dentro de las empresas lo que se busca es sacar aplicaciones funcionales en el menor tiempo posible, así es que eso de “la seguridad” realmente es un gasto de tiempo indeseable.

b) Es fácil criticar la inseguridad de mis aplicaciones web que desarrollo, pero enséñame tres aplicaciones de más de 5,000 líneas de código que esté exenta de errores y entonces me callo. Desarrollar software seguro es difícil, y entre más complejo sea la aplicación, más difícil es darse cuenta de ese tipo de errores. Enséñame un sistema operativo sin bugs que se ejecute en una computadora moderna…eso no existe hoy y dudo que pueda pasar en el mediano plazo.

Ahhhhhh verdad?. La cosa no está tan fácil ¿Los desarrolladores tienen la culpa? Tú dime…al parecer el problema es más complejo que apuntar a “los desarrolladores”, a “los de seguridad” o a “los usuarios”. Dejando de lado quién tiene “la culpa”, pienso que los desarrolladores deben de ver el hecho de codificar aplicaciones con una noción de seguridad en mente como un “plus” o un extra que pueden incorporar a sus destrezas y verlo como una ventaja competitiva, en lugar de verlo como “pérdida de tiempo” o “si a mis jefes no les importa, para qué aprenderlo?”.

Si eres desarrollador piensa en lo que dije…es posible que puedas verlo como una habilidad que te dará una ventaja competitiva? Si eres empleador de un desarrollador, anímalo a que se capacite o aprenda esta habilidad y premia el hecho de que no sólo se hagan aplicaciones funcionales sino lo más seguras posibles.

Como muchas veces, las cosas no van a cambiar si dejamos que “el gobierno”, “la regulación”, “el jefe”, “los de seguridad” o “el vecino” hagan algo al respecto. ¿Qué puedes hacer desde tu trinchera?

(Googleando me encontré con esta página que habla del tema…parece que no soy el único en poner este tema sobre la mesa: http://www.nextgov.com/nextgov/ng_20100216_8606.php).

Nota: a mí en la Universidad no me enseñaron codificación segura…se omitió prácticamente de los temarios.

¿Vivir con los Workarounds? Not.

¿Esperan los fabricantes de software que sigamos cada uno de sus workarounds para las vulnerabilidades de día cero? Debe de ser una mala broma.

Tenemos una debilidad de día cero en una aplicación o sistema operativo; esas que tanto nos gustan donde no hay parche que le dé solución y en la cual simplemente nos tenemos que aguantar…o comernos un sabroso workaround que es una medida temporal para evitar un ataque (esto claro, siempre y cuando el fabricante de software se “digne” siquiera a publicar un workaround; hay casos en donde simplemente hay que esperar el parche y uno mismo tiene que ideárselas para tratar de evitar el ataque).

En fin, podríamos pensar que los “workarounds” son los buenos de la película, ya que una vez que hay un defecto en el software, el buen fabricante nos propone esta medida alterna para ser aplicada y evitar un ataque a la falla. ¿Qué puede haber de malo en eso?

Si tuvieras días cero de vez en cuando y si tuvieras pocas aplicaciones en un solo sistema operativo, no tendría casi ninguna queja. Sin embargo eso no es la realidad ni para un usuario en casa y menos para una empresa donde al menos existe un sistema operativo (dije: al menos) y hay cientos de aplicaciones.

Tal vez para un usuario en casa aplicar workarounds no sea del todo fastidioso (aún así, cuántos usuarios en casa lo hacen?), pero aplicar un workaround en una organización no es de “enchílame éstas”. Hay que probar estos workarounds para ver que no afecten gachamente la operación, posteriormente aplicar progresivamente el dichoso workaround en todas las computadoras (efectivamente, algunos pocos workarounds se pueden aplicar en controles perimetrales). Luego cuando sale el parche conviene hacerle “undo” al workaround.

Y siendo sinceros, varios de esos dichosos workarounds son peor que el exploit, por decirlo de alguna manera. Para los que los hemos tratado de aplicar, finalmente te das cuenta de que se pierde tanta funcionalidad que es mejor olvidarlos. Tendrías a N usuarios llamándote para ver por qué diablos no pueden ver páginas web normalmente o una imagen en un documento. Ah sí, cuando bien te va; una vez me tocó un workaround que al cambiar una llave del registro salía la pantalla azul de la muerte en Windows.

Seguirle el paso a los workarounds de los día cero (ubicar-> probar-> implementar-> undo cuando salga el parche) del software en una empresa es un dolor de cabeza (y fui amable). Que levante la mano el que ha implementado todos los workarounds de los días cero del 2010 al menos para el software de Microsoft y de Adobe. Sí, debe de ser una broma.

¿Qué puedes hacer? Volverte esclavo de los workarounds o tener controles preventivos: una buena hardenización, un IPS personal y un sandbox, por poner unos ejemplos. Otra medida es analizar primero si la debilidad de día cero realmente te afecta y por otro lado ver si no tienes ya controles que mitiguen el riesgo para poder olvidarte del workaround hasta que salga el parche.

Seamos sinceros, no vas a aplicar todos los workarounds habidos y por haber (y créeme, no te culpo), así es que debes de pensar en una estrategia que te permita sobrevivir a los día cero…y a sus workarounds.

Nota: Las debilidades de día cero y sus workarounds están a la orden del día. Por poner sólo un ejemplo, entre el 14 de diciembre y el 5 de enero, salieron 4 debilidades de día cero sólo para Microsoft. Al día 9 de enero siguen sin parche. Y para varias de ellas se proponen workarounds. Checa lo que implican. Y como ejercicio, durante el 2011 ve cuántos workarounds te estarán proponiendo los fabricantes y checa cuántos de ellos puedes implementar sin problema.

“Consejos” para Navegar Seguro.

Me encontré con una lista de consejos del nic para navegar seguro en Internet donde varios de ellos lejos de ayudarme me hicieron quedar con cara de “what?”. Analicemos algunos de ellos con la intención de criticarlos constructivamente.

Respecto a las contraseñas nos dicen: “Se recomienda hacer uso de contraseñas largas, con diferentes letras, números y símbolos que al mismo tiempo sean fáciles de recordar”. Por “largas” creo que podemos decir que 8 caracteres puede ser suficiente (el nic no lo especifica). Sin mencionar que cuando tenemos 10, 15 ó 20 sitios a los que entramos seguido, acordarnos de “n” contraseñas complejas, diferentes pero fáciles de recordar es algo que pocos hacemos y que el nic no toma en cuenta. Lo que yo hago es usar LastPass que me ayuda a “recordar” estos passwords; así podemos cumplir con eso de que sean diferentes para cada sitio y complejas (y sin necesidad de tenerlas en la mente).

De los sitios nos dicen: “Evitar sitios de origen dudoso. Es importante pensar dos veces antes de hacer click en uno de estos anuncios, pues pueden ser causa de virus o spam”. En su consejo no nos dicen qué es un “sitio de origen dudoso” y nos recomiendan que pensemos dos veces antes de hacer click en “uno de estos anuncios”. Es ambiguo y no del todo cierto: hoy en día hasta sitios legítimos pueden contener contenido malicioso en frames, por ejemplo. No sé cómo definir un “sitio de origen dudoso”, ya que hay unos que ciertamente intuimos que lo pueden ser (por ejemplo pornográficos) pero otros ni idea (como el malware que apareció en el sitio del New York Times). Yo uso NoScript en los sitios que visito para dejar de pensar en si es dudoso o no; puede ser una verdadera lata pero hace su trabajo…pruébenlo y me dicen qué les pareció.

Pongamos el extracto completo que nos ofrece el nic para que vean que no ando intencionalmente seleccionando extractos incompletos: “Cuidar datos personales: El mal uso de los datos personales no sólo se remite a lo que el usuario comparte en sus redes sociales, pues también es importante considerar que nunca hay que escribir nombres, apellidos, direcciones, teléfonos o cuentas bancarias en sitios que no sean seguros. Para saber si un sitio es seguro, basta con revisar que el inicio de su dirección incluya una letra s (https://)”. Me llama la atención la última parte en donde dicen que para saber si un sitio es seguro debemos de revisar que tenga “https” porque me es difícil ligar el tema de “datos personales” con el de TLS (https). Cuando un sitio cambia a https, lo que nos dice es que tiene un certificado válido; pero NO nos dice nada de qué harán con nuestros datos ni del cuidado de los mismos. El “https” crea un canal cifrado entre tú y el sitio, quien quiera que el sitio sea o pretenda ser. Nada más. Pueden intentar https://www.RoboTarjetasDeCredito.com y estarán tranquilos de saber que usa “https” y que aparece un candadito en su navegador, cierto?

Nos dicen: “No ejecutar archivos sospechosos” comentando que al navegar algunos sitios mal-intencionados nos pedirán descargar algún archivo aparentemente necesario. De nueva cuenta, eso de “archivos sospechosos” es ambiguo y poco claro, y por lo tanto poco útil. Sitios legítimos me piden también que descargue algún software (quítenle flash a su navegador y se sorprenderán) y me piden que habilite ActiveX o JavaScript (con NoScript se darán cuenta de esto último). ¿Entonces qué hacemos? Podemos usar un Sandbox, un firewall personal u otros controles (de preferencia preventivos como los ofrecidos) que le permitan al usuario común dejar de decidir si un archivo es “sospechoso”.

En fin, estos fueron algunos de los consejos que llamaron mi atención. La lección –creo- es que no debemos de aventar consejos ambiguos a los usuarios y sí usar nuestro sentido común para revisar bien lo que estamos diciendo; yo mismo he caído en esta trampa al asumir que el usuario a quien me dirijo es un CISSP.

Por otro lado, a algunos no les late poner “marcas” en su blog o artículo, pero las “marcas” pueden apoyar nuestras ideas o consejos. Tal vez se valga decir que no navegues en sitios inseguros y que puedes usar NoScript, por ejemplo. Así si no queda claro lo de “sitios inseguros”, al menos le estás dando un consejo claro y preciso de usar una herramienta. En fin, aquí siempre está el tema de “me pagan para poner marcas” que yo simplemente ignoro.

Si te das un tiempo de leer los consejos del nic, creo que coincidirás conmigo en que su concepto o lo que quisieron transmitir es valioso. Pero la ambigüedad y no ponerse en el lugar del usuario promedio a quien supuestamente van dirigidos los consejos, no fue muy atinado. ¿Tú qué opinas?