¿Bug o no bug?

“DLL Hijacking”... alguien había escuchado de este término? Si jamás lo llegaste a escuchar, no te sientas mal, es otro terminajo que nos encanta a los de seguridad. En las últimas semanas de agosto tomó relevancia ya que se descubrieron problemas de DLL hijacking en cierto sistema operativo (adivinen cuál).

Cuando una aplicación, digamos AppX.exe se ejecuta, es probable que haga uso de una DLL. Una DLL es una “librería que contiene código y datos que pueden ser usados por más de un programa a la vez”. En caso de que haga uso de esa librería, nuestra amiga AppX.exe va a buscarla en el mismo directorio donde vive.

Ejemplifiquemos. Si la AppX.exe reside en “c:\program files\AppX\”, entonces ahí mismo va a buscar primero su DLL. Si no la encuentra ahí seguirá un orden preestablecido de búsqueda y se irá a tratar de encontrarla en otras rutas, como la del sistema o la de Windows; lo anterior sucederá a menos que el desarrollador haya especificado una ruta (y que es lo que debería de suceder en un mundo ideal).

Pues bien, ya se imaginan a dónde voy. Si saco a AppX.exe de su entorno natural y la pongo (por ejemplo) en un USB junto con una DLL maliciosa que yo hice, lo que hará AppX.exe es llamar a esa DLL porque ambas están juntas en el mismo directorio y ya no buscará su DLL benigna a donde vivía antes: c:\program files\AppX\.

Espero no haberte confundido más. En fin, Microsoft dice en pocas palabras que ese no es su problema porque los desarrolladores deben de especificar en su codificación una ruta definida donde la aplicación busque su DLL (lo que evitaría este ataque). Tal vez a los codificadores les da flojera o ignoran este peligro y llaman a su DLL (desde las líneas de código) sólo por nombre y sin poner su ruta específica.

Y no se trata de un par de aplicaciones afectadas por ahí, sino que hay toda una lista. Safari, Chrome, Media Player, PowerPoint, Microsoft Movie Maker o Firefox, entre otras. Y sí, hay aplicaciones de Microsoft que se ven afectadas. Así es que ellos mismos hicieron el error de llamar a las DLL por nombre y sin especificar una ruta, chups.

Para no variar y como varios ataques populares, este DLL hijacking ya tiene video-demo. El usuario abre una presentación PowerPoint y cuando lo hace, zas! Acabó todo para la víctima. Como ven, se necesita participación del usuario. Pero vaya, digamos que los usuarios en general son muy cooperativos, cierto?

¿Bug o no bug? Por diseño se permite llamar a una DLL por nombre (supongo que para facilitar la vida y no tener que poner una ruta cada vez que se llama a una DLL), así es que es una vulnerabilidad o una simple funcionalidad abusada inteligentemente?

Debido a este DLL hijacking no se va a acabar el mundo ni se van a crear gusanos apocalípticos como Blaster. Me llamó la atención desde el inicio y quería comentarlo aquí porque es un ejemplo de una semi-vulnerabilidad que está en el limbo debido a que no hay contundencia en que sea una debilidad o una característica de la cual se ha abusado.

Aunque si un atacante puede realizar un ataque aprovechándose de esta “funcionalidad”, pues que no es...mmhh...una vulnerabilidad?

Tendencias en Seguridad.

Las áreas de seguridad tienden a transformarse. Empezarán a diluirse y entretejerse cada vez más en otras áreas organizacionales de TI. En el futuro cercano, en las corporaciones ya no deberá de haber un área de seguridad informática como se concibe hoy, sino que las funciones de seguridad estarán bajo la responsabilidad de diversas áreas de TI.

Dentro de una empresa, el área de desarrollo será responsable de codificar software no sólo funcional sino seguro y tendrá uno o más codificadores capacitados para desarrollar con seguridad. La Oficina de Redes también ya no sólo será responsable de la operación de las redes, sino de su seguridad, por sí sola esta Oficina tendrá un par de ingenieros capacitados en seguridad que propondrán productos de protección, revisarán su buen funcionamiento y estarán al tanto de las tendencias en ataques y controles que los mitiguen.

Los administradores de servidores o bases de datos ya no andarán sólo atendiendo que “la operación” prevalezca, sino que también estarán a cargo de la seguridad de los servicios que residen en sus servidores y de los servidores mismos.

Las áreas de seguridad informática tienden a transformarse y especializarse en ciertos temas “avanzados” de seguridad y en entender las tecnologías para poder atender los riesgos a los que se enfrentan. Las funciones operativas de seguridad tienden a absorberse. Los productos de seguridad tienden a ser administrados ya no por esos de “Seguridad”, sino por cada área administrativa.

¿Antivirus? Para los de Servicios de Sistemas Operativos. ¿Firewall perimetral? Para Redes. ¿Antispam? Para los encargados del Correo. ¿Filtrado de contenido y/o DLP? Redes también (bueno, hablemos de DLP cuando madure un poco más).

El área de seguridad cambiaría su nombre a algo así como “Protección de la Información” o “Administración de Riesgos de la Información”, probablemente con funciones de análisis de riesgos informáticos y de la información, auditorías de seguridad (incluyendo revisión de configuraciones) y pentest. Así lo veo (y algunas de estas ideas de hecho las empecé a escuchar de @ElProfeSeguro). ¿En todas las corporaciones? Estimo que por la naturaleza del cambio, esto se daría en organizaciones medianas y grandes (si no es que ya se está dando de forma natural).

Lo anterior también se puede ver en la tendencia de incorporar la seguridad en servicios y productos. Google en su servicio de GMail tiene un satisfactorio filtro antispam y control de malware. Microsoft muere de ganas por incorporar su antivirus Security Essentials en Windows y eventualmente lo hará de alguna manera u otra al 100% (por ejemplo, ¿recuerdan la integración del firewall de MSFT en XP-SP2? Ahí van poco a poco, no?). Asimismo, Intel acaba de comprar a McAfee. HP a Fortify.

Tiene lógica. Cuando compro un auto, no quiero comprarle por separado dos bolsas de aire, cinco cinturones de seguridad, un sistema ABS o una alarma. Hoy en día estas protecciones vienen incorporadas en muchos de los autos nuevos, y así debería de ser. La seguridad forma parte de las características del auto, como el sistema de frenos o el eléctrico.

Bueno, eso es todo de este tema. Ahora cambio de dirección y les comparto algunas de mis opiniones respecto a la compra Intel-Mcafee anunciada la semana pasada (que fue la que me dio la idea de este post):

+ Intel pagó un 60% más por acción. Muestra un gran interés y que le ven potencial a McAfee. Osease, ven lana.

+ Intel en su comunicado comentó que la seguridad no es suficiente en dispositivos móviles, ATM o automóviles. Intel, el gran fabricante de chips para las PC, no lo es para el mercado móvil que representa un jugoso futuro. Tal vez quiera ofrecer productos/servicios de seguridad para estas “nuevas” áreas de oportunidad y estar presente ahí.

+ Se ha dicho que de alguna forma se delegarán funciones del software de seguridad (Mcafee) al hardware (chip Intel). No estoy convencido de esto. Tal vez (eso sí) vayan a crear hardware (no forzosamente procesadores) especializado en seguridad que se incorpore en los sistemas de cómputo o móviles. La idea de Intel tal vez sea que la seguridad estará –mejor- en el hardware y no en el software.

+ Se ha dicho que este tipo de adquisiciones afecta la innovación. Yo no ligo poca innovación con grandes corporaciones. Creo que la innovación se da cuando están las bases puestas.

+ Se ha dicho que Intel buscaba especialistas en seguridad para colaborar en los diseños de sus procesadores y que de ahí la compra. No creo que hayan tenido que comprar toda una compañía para conseguir a estos especialistas.

¿Cuál es tu lectura de la compra?

Finalmente, un comentario de Bruce Schneier del 2008: “What we're going to see is consolidation of non-security companies buying security companies. So, remember, if security is going to no longer be an end-user component, companies that do things that are actually useful are going to need to provide security. So, we're seeing Microsoft buying security companies, we're seeing IBM Global Services buy security companies, my company was purchased by BT, another massive global outsourcer. So, that sort of consolidation we are seeing, it's not consolidation of security; it's really the absorption of security into more general IT products and services”.

Pentesteando

El hackeo ético (pentest) se refiere a pagar por los servicios de alguien con el fin de que realice un hackeo controlado y “ético”. ¿Por qué alguien pagaría para que lo hackearan?

El objetivo es evaluar el estado de la seguridad informática de una corporación; equivaldría a contratar los servicios de un perpetrador ético para que intente entrar a nuestro hogar (y que prometa no llevarse nada) e informarnos qué y cómo le hizo para en su caso tomar medidas correctivas (una nueva cerradura, una pared más alta, etc.).

Si quieres contratar los servicios de un pentesteador (sí ya sé, no existe esa palabra) en México, el primer problema al que te enfrentas es dónde buscarlo. No conozco como tal una sección amarilla completa de pentesteadores nacionales. ¿Qué hacer? Tal vez un conocido lo haya contratado y te haga una recomendación, puede ser que busques en Google y trates de ver en su página ese “algo” que te llame la atención. Podrías usar LinkedIn o Twitter para tratar de averiguar quién se dedica a esta actividad. Finalmente, algunas consultoras famosas tal vez ofrezcan estos servicios (¿tú cómo los buscarías?).

Bueno, ya que de alguna manera tuvieras un menú de posibles pentesteadores, ahora el problema es evaluarlos. ¿Los evalúas conforme lo bonito de su página web? ¿Dependiendo de quiénes fueron sus anteriores clientes? ¿Objetivos alcanzados? ¿Reportes que puedan mostrar? ¿Recomendaciones de sus clientes?

Si ves, la evaluación del mejor pentesteador para tu corporación (y que no cobre en diamantes) es medio nebulosa porque el hackeo ético es en cierta manera más un arte que una metodología. Hay esfuerzos que tratan de bajar el arte del hacking a una serie de pasos a seguir, pero el que ofrece los servicios de pentest debe de tener esa intuición, malicia, creatividad y habilidad que no te la da una “metodología”. Y ahí está la problemática: cómo evalúas la creatividad para lograr encontrar un camino vulnerable, la malicia para pensar como atacante, esa creatividad para salirte de los típicos ataques y penetrar con diversas técnicas o la habilidad para programar tus propios códigos de explotación e inclusive hasta descubrir nuevas debilidades de día cero para usarlas. ¿Cómo, cómo lo evalúas a ciencia cierta?

¿Puedes evaluar al que va a llevar a cabo el pentest con pequeños retos u objetivos a cumplir? ¿Sólo viendo sus reportes de algunos pentest pasados? ¿Preguntando por la gama de herramientas usadas? ¿Cantidad de debilidades día cero descubiertas? ¿Todo lo anterior? No sé si tú lo veas claro como el agua; pero yo lo veo gris como cielo del DF.

Supongamos que ya elegiste a alguien y lo pones a chambear. Te entrega los resultados después de semanas de trabajo y se les ve muy contentos. Te dan la mano. Te felicitan. Eres un gran experto en seguridad. ¡No encontraron nada! Seguridad perfecta. Ni un hueco. Abres el champagne. Todos sus intentos por vulnerarte fracasaron. Chups. ¿Qué haces? ¿Saltar de alegría porque no encontraron nada? ¿O decirles que su trabajo fue pésimo porque es imposible no encontrar nada? Aquí estoy siendo muy absolutista, piensen en las variantes que de todas maneras te generan dudas: encuentran sólo huecos de menor importancia; se encuentran sólo un par de debilidades importantes (¿eran todas?), etc.

Al final de cuentas, el buen hackeo ético es más un arte que una ciencia con metodología. Es como cocinar unas sabrosas costillas de cordero: si yo sigo las instrucciones te entregaré una porquería; si las hace un chef: a chuparse los dedos! (la diferencia es que con las costillas puedes decir si se hizo un buen trabajo…no así cuando te entregan los resultados del pentest -¿pudieron haber más hallazgos?-).

El trabajo de quien contrata los servicios será tratar de poner en blanco y negro su forma de evaluar a quien puede prestar dichos servicios y la forma de evaluar los resultados entregados. El trabajo de quien presta estos nobles servicios, es demostrar quién es y lo que puede ser capaz de hacer (recuerden, en PowerPoint todo se puede llegar a ver realmente muy bien).

Reflexiones aleatorias:

· Un pentest puede o no incluir la ingeniería social. Desde engañar para hacer click o la llamada telefónica al estilo Mitnick.

· Yo veo dos tipos de pentest: por objetivos (este servidor web, aquella red inalámbrica, con privilegios de administrador) o a ver qué descubren (“tú búscale y a ver qué te encuentras”).

· En mi opinión, los verdaderos hackers no usan los pasos de una metodología de hackeo (en el sentido de que no sacan su librito a ver qué paso sigue); libros como Hacking Exposed, la OSSTMM o Ethical Hacker tratan de bajar el arte del hacking hacia una metodología.

· El pentest no es sólo sentarte a ejecutar herramientitas de BackTrack o el Nessus; eso lo puedo hacer yo mismo.

· Le han hecho un “pentest” al Titanic. Te informan que no han encontrado una manera de hundirlo. Por fin te sientes tranquilo y lo pones a navegar.

Reflexiones Sobre el Día Cer0

Por alguna razón, el Día Cero siempre me ha sonado a título de película apocalíptica donde Stallone, Willis y Schwarzenegger protagonizan la cinta y ya saben, empieza con una música tenebrosa diciendo “Son los mejores mercenarios del mundo. La única vida que conocen es la del Día Cero (Ah! Ese es un trailer, verdad?).

Pero dejando mi imaginación esquizofrénica a un lado, de lo que quiero hablar es del tema de las llamadas “vulnerabilidades de día cero”. Los asiduos lectores del blog (quiero pensar que tengo un par) sabrán de lo que hablo: cuando se publica en Internet una debilidad de software sin que tenga su parche (solución) correspondiente, se dice que hay una debilidad de día cero. Ahí está el error latente, pero debemos esperar a que haya una respuesta (parche) del fabricante.

Por ejemplo, el viernes 6 de agosto se anunció de una debilidad de día cero en el kernel de Windows.

¿Son las debilidades de día cero la gasolina principal que mueve al mundo underground criminal? El éxito que han tenido los criminales en línea no se debe a estas debilidades de día cero (morirían de hambre, por así decirlo). Estos señores viven realmente de los millones de usuarios que tienen software des-actualizado.

El esfuerzo (tiempo y dinero) que se podría invertir en descubrir las debilidades de día cero (que tampoco son de “enchílame éstas”), simplemente es mejor invertirlo en explotar la gran cantidad de debilidades –conocidas y con solución- que tienen en su conjunto los sistemas en todo el mundo pertenecientes a cualquier tipo de usuario.

Existen millones de computadoras que no se encuentran al día y que seguramente tendrán un hueco en el sistema operativo o sus aplicaciones. Por ejemplo, tú podrías asegurar que tienes tu sistema “updeiteado” 100% al día de hoy?

¿”Tons pa” qué sirven las debilidades de día cero? Sé lo que están pensando (sin ser el pulpo Paul): en ataques dirigidos. Esos ataques donde específicamente se tiene a una persona u organización en la mira. Depende de quién lo haga, le sacará mayor provecho (sin ser una regla).

Desde el punto de vista del crimen en línea, para qué esforzarse en la investigación y descubrimiento del día cero? Mejor usar una debilidad conocida, probada y hasta documentada. No me malentiendan, las debilidades de día cero sí se han usado y se llega a pagar por ellas, pero para el crimen en línea no es realmente tan rentable ya que confían en que “sus” usuarios tendrán huecos de seguridad explotables existentes: piensen en el gusano Conficker que sigue siendo exitoso a pesar de que el parche que en gran medida lo previene se publicó hace más de 18 meses.

Desde el punto de vista de Estados, el espionaje dirigido bien puede valerse de estos días cero y podría ser el mayor cliente. Y aún así no es forzoso; hasta en el ataque dirigido podemos apostar a que la víctima tiene al menos un hueco de seguridad explotable en su operativo o respectivas aplicaciones.

En conclusión. ¿Debemos temerle a las debilidades de día cero? Estimados, debemos temerle en todo caso a las debilidades conocidas con parche. Si “nos cae” un exploit, es altamente probable que ataque una debilidad conocida con parche publicado y que nosotros no hemos aplicado.

Si mantenemos nuestro sistema al día en todo momento (más fácil de decir que de hacer), habremos eliminado a la gran, gran mayoría de malware que usa exploits y que abundan en Internet. Claro, otra opción sería usar OS X o Linux, pero ese es tema de otro blog!

(Varias de estas ideas me las dio mi amigo @danchodanchev).