Conferencia sobre seguridad y capacitación SOURCE Boston 2012. Día 2: Conferencia de Dan Geer, Android Modding y seguridad en la nube

La fantástica conferencia de Dan Geer inauguró el segundo día de la Conferencia SOURCE Boston esta mañana. La charla fue emocionante y compleja a la vez, y requirió toda nuestra atención. También fueron muy interesantes las conferencias de Jeremy Westerman sobre seguridad en la nube (Covering *aaS – Cloud Security Case Studies for SaaS, PaaS and IaaS), y la de Dan Rosenberg sobre modding en Android (Android Modding for the Security Practitioner).

“Internet nunca será tan libre como lo es esta mañana”. Dan Geer es uno de los más destacados conferenciantes sobre seguridad informática y de redes. Dio una presentación de muy alto nivel, describiendo detalladamente y con abundantes ejemplos la dependencia que tiene de Internet casi cada uno de los países desarrollados. “La dependencia de internet es transitiva, al contrario de la dependencia de la televisión… Estamos en un punto en el que ya no es posible llevar una vida sin depender críticamente de Internet; incluso si uno vive alejado de todo, en algún momento necesitará comprar clavos o gasolina”. Asimismo, brindó numerosos ejemplos de fracasos en los sistemas de EE.UU. para ofrecer opciones alternativas. Habló sobre su pequeño banco local, al que escribió una carta en papel solicitando el cierre de una cuenta autocreada de banca online que nunca usó. De forma excepcional, se la cerraron de inmediato. Por el contrario, Fidelity Investments no aceptó una solicitud similar. La compañía sigue enviándole todo tipo de contenidos sobre marketing a la dirección desde la cual él envía sus cartas. Al parecer, sus auditores aprueban que Fidelity rechace toda comunicación escrita en papel iniciada por el cliente, y en cambio, acepte comunicaciones por correo electrónico, chat, o por teléfono. Esta discusión continuó con el diseño de sistemas, la teoría de campo unificado, la tolerancia de fallas, y tocó puntos clave sobre por qué la prevención de intrusiones no es considerada un modelo viable, y en lugar de ello, es la elegancia de la “tolerancia de intrusiones” que debe incorporarse en los sistemas, y que los países y organizaciones que no pueden incorporar esta tolerancia en sus sistemas no son sostenibles. Citas notables: “Olvídate de los bancos, es Internet el que es demasiado grande como para colapsar”, “¿Hay lugar para quienes deciden no participar en Internet?”, “HTML5 es Turing total, HTML4 no lo es”, y “¿Debemos conservar los medios manuales? Conservar las alternativas no sólo es prudente sino esencial”.

En su charla sobre la seguridad en la nube, Jeremy Westerman presentó varios casos de diseño para universidades y otras organizaciones. La mayor enseñanza de esta conferencia es que la gestión de llaves API, por desgracia, no se tratada con la misma urgencia y conciencia que las llaves privadas SSL para grandes organizaciones. Esta llave API, en el contexto de las soluciones múltiples, populares y de firma única (SSO) que se usan en varias universidades, es la llave para decenas de miles, o cientos de miles, de cuentas de correo. Similares esquemas de llaves API se implementan en soluciones laaS, como el ambiente Amazon EC2 con soporte de Xen, y los ambientes VMWare vCloud Teramark. Sin la necesaria conciencia, los desarrolladores guardan esta llave en lugares inapropiados, como el disco duro de la máquina de firmas, o en los discos duros de su sistema de desarrollo en lugares poco obvios, enviándosela entre ellos por correo o por “dropbox” y transfiriendo después las llaves API al ambiente de producción, en lugar de emitir otras llaves API. Resulta prácticamente imperativo que estas llaves dejen de estar en las manos de los desarrolladores. Estos ejemplos de mala práctica son una mala noticia, pues códigos virales, como Sality, y gusanos que estaban en el tope de nuestras estadísticas de prevención mantienen su funcionalidad para robar contraseñas de las cuentas administrador de sistema y FTP para poder ocultar códigos maliciosos, codificados o no, en sitios web legítimos, sin que su dueño se entere de ello. Es decir, los desarrolladores fueron blancos efectivos y débiles para el robo de credenciales, permitiendo el silencioso secuestro de sitios web para darles uso malicioso. Y ninguna universidad quiere que le suceda esto. Recuerdo una desafortunada notificación en una pequeña universidad en la que el administrador de su sitio web no quería aceptar que el BLOB codificado de datos alojados en su servidor web era en realidad un virus que actualizaba los sistemas infectados de los estudiantes y estaba ahí porque Sality había robado sus credenciales después de intentar ejecutar software pirateado que se distribuía por una red P2P. De todas maneras, esto sucede, pero se puede prever y evitar.

La conferencia de Dan Roseberg (Android Modding for the Security Practitioner) fue la sazón para una discusión técnica sobre Android, pues aclaró las técnicas rooting/modding y el lenguaje que usan, además de las consecuencias de seguridad cuando se realiza el modding en los teléfonos Android.

Entre las citas notables, tenemos: “las compañías telefónicas incentivan a que sus clientes vean sus teléfonos como descartables y que adquieran el último modelo y firmen nuevos contratos por varios años”. “De las 10 vulnerabilidades que he descubierto y usado para el rooting en Android, 9 están relacionadas con el “estúpido” permiso para archivos que no es parte del código original de Android pero que lo introducen los fabricantes”, y en seguida mostró ejemplos concretos de Motorola y Sony que implementan estos terribles permisos. “Las vulnerabilidades root benignas a menudo se parchan con mayor rapidez que las malignas” que ponen en peligro a millones de usuarios de Android.

Dan se refirió a algunos de los entresijos del diseño de la partición, bootloaders (bloqueados y desbloqueados), protocolos de flasheo, y el modelo de permisos para archivos, y vulnerabilidades y técnicas de modding. Concluyó mostrando una fantástica lista corta de consejos de seguridad para los responsables de las decisiones: 1. Es imposible evaluar la “seguridad de Android” sin considerar al fabricante del hardware y el chipset. 2. Si es posible, codifica el disco. 3. Desactiva la depuración por medio de USB en tu teléfono. 4. El rooting es una espada de doble filo: permite los parches (que las compañías telefónicas no ofrecen), pero también puede permitir otras vulnerabilidades.