domingo, 15 de agosto de 2010

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.

domingo, 8 de agosto de 2010

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).

domingo, 1 de agosto de 2010

Cajero Violado


¿Han tenido un sueño en donde el cajero automático se vuelve loco y les avienta un billete tras otro sin parar? Barnaby Jack ha hecho esto posible, presentando en su conferencia de Black Hat una demostración de cómo hacer que estos cajeros automáticos (ATM) “se vuelvan locos”.

Black Hat es un evento (de los más importantes en su ramo) donde se presentan una serie de conferencias de seguridad con diferentes temas. En esta ocasión nos concentraremos en la que hizo Barnaby.

El investigador obtuvo dos cajeros de las marcas Tranax y Triton. Después de analizarlos por más de un año (iba a hacer esta presentación en 2009), pudo hackearlos y adueñarse de ellos. Estas marcas de cajeros no son de un banco en específico, al menos en EUA se usan como las típicas ATM que se encuentran en súpers o restaurantes.

Para el caso de Tranax, se explotó una debilidad en el software del cajero que permitía evadir los controles de autenticación e instalar así cualquier programa (obvio, no se ejecutó cualquier programa sino uno especialmente diseñado para controlar la ATM). Este ataque se puede llevar a cabo sin tocar al cajero, es decir, por Internet o por dial-up.

Jack nos dice que para realizar el ataque, se necesita saber la dirección IP del cajero o su “número telefónico” (se puede hacer un wardialing -barrido- y descubrir a los cajeros de esta marca, por ejemplo). Una vez que se tiene al cajero en la mira, se le instala un rootkit vía red, Barnaby codifico uno y lo bautizó como Dillinger. A partir de ese momento, se puede ordenar al cajero sacar todo el dinero o simplemente grabar la información de las tarjetas que a partir de ahora se inserten en él. El cajero ha cambiado de dueño.

Para el caso del cajero marca Triton, se debe de interactuar con el cajero. Éste se abre con el fin de conectar una memoria USB, la cual infecta al cajero con un troyano. La llave para abrir esos cajeros cuesta 10 dólares en EUA y es una llave maestra para todos los cajeros de esa marca. ¿Así o más fácil?

¿Qué significa todo esto? Que al menos esas marcas de ATM y me atrevo a decir que otras también, carecen de una seguridad medianamente aceptable. ¡Ah! Por cierto. ¿Mencioné que usan el sistema operativo Windows CE? ¿No? Pequeño detalle.

Para mi gusto, el error principal es la siguiente fórmula: Cajeros=PC. Desgraciadamente estos cajeros no cuentan con mucha tecnología “propia”, es decir, me parece que se limitaron a transformar una computadora en cajero. Tiene todos los elementos: Windows, puertos USB, son programables, etc. Es lo más barato, ciertamente, pero al menos pueden echarle neuronas para hacerlo más seguro y de paso hasta eficiente.

Lo he dicho antes y lo repito ahora. No tengo nada en contra de Windows, sino del uso extendido que se le da para todo tipo de sistemas. Desde el sector militar, hasta equipos destinados para seguridad nacional, administración de infraestructura (agua, electricidad) y hasta en cajeros automáticos podemos encontrar “ventanas”.

Si usas el mismo operativo que usan millones de personas, estás sujeto a las “mil y una” debilidades encontradas y usadas por los hackers. Es decir, un cuate con Windows puede experimentar con él todo lo que quiera, y sabrá que sus ataques funcionan en sistemas críticos en todas partes del mundo. Es como darles un ambiente de pruebas para atacar nuestros ambientes de producción.

Y también como he dicho antes, el problema no es tanto el hecho de usar Windows, sino que se instala y configura sin tener a la seguridad en mente. Si vas a poner Windows en un cajero, al menos endurécelo y deshabilita los USB; no es infalible pero al menos habrás avanzado un tanto y no te cuesta.

Puedes buscar videos de estos hackeos a los cajeros en Youtube (buscar por “Barnaby ATM”) y encontrarás un par.

#NoTechHack: Aquí se hacen hackeos más primitivos: “sopletean” a los cajeros; quién necesita encontrar debilidades en el software cuando el mismo objetivo$ se puede alcanzar? Supongo que es “the mexican way”.

domingo, 25 de julio de 2010

Ya pues, Llévatelo.


Me imagino la conversación.

- Si nuestro dinero te quieres llevar, tu código fuente nos debes de dar.

- Pero, así nada más? Es que…saben? Nuestro código fuente es nuestro negocio, seguro no lo van a usar para fines comerciales, cierto? ¿O peor, para “otros” fines?

- Tú tranquilo y nosotros preocupados. Somos el gobierno ruso…acaso no confías en nosotros?

- Ya pues, llévatelo.

Recientemente, Microsoft (MSFT) anunció que daría acceso al código fuente de varios de sus productos al gobierno de Rusia a través del Servicio de Seguridad Federal ruso.

Tendrán al Windows Server 2008, Office 2010 y SQL Server. Por un lado, los rusos quieren ver el código fuente para verificar que no tenga backdoors (funciones no deseadas o no esperadas) y para ponerle criptografía –de alguna manera según ellos- a algunas partes de los productos de MSFT.

Analicemos el hecho de darle el código fuente a un gobierno extranjero.

a).- Encontrar bugs se facilita. Es mentira que si no tienes el código fuente no puedes encontrar vulnerabilidades en el software (cada segundo martes, MSFT nos lo recuerda con la publicación de sus benditos parches).

Pero si tienes el código fuente, el hecho de encontrar estos bugs se facilita y tienes un mucho mejor entendimiento del funcionamiento interno de un programa directamente viendo el código fuente (y sin usar des-ensambladores).

Ya sé qué están pensando. “Pero cualquiera puede tener acceso al código fuente de Linux también, cuál es el problema en tener el de MSFT”? Ajá. Aquí va: mientras que todos tenemos acceso al código fuente de Linux, en el caso de MSFT, sólo unos cuantos tienen acceso completo a él. ¿Ven la diferencia? Eso es jugar en desventaja porque sólo algunos pueden analizar el preciado código fuente.

b).- Ejecutables (binarios) vs código fuente. Tú sospechas de mi programa; me pides el código fuente para “analizarlo”. Te lo entrego. Lo revisas. Estás tranquilo sabiendo que no esconde nada raro. Yo me río: el código fuente que te di a revisar no es el mismo que está “viviendo” y ejecutándose en tu sistema. Get it?

c).- Windows en sistemas críticos. Si yo fuera del gobierno de EUA, le ordenaría a MSFT no entregarle el código fuente a un gobierno extranjero o en todo caso, ver cuáles son los términos de entrega dentro del marco del programa Government Security Program y hacer los ajustes necesarios (espero hayan hecho esto último).

El problema de entregar esto a un estado foráneo es que muchos de los sistemas de misión crítica (infraestructura, seguridad nacional, milicia) tienen Windows (al menos en EUA). Cosa que en primera instancia está…mal. Desde hace mucho debieron ordenar poner en esos sistemas de misión crítica un sistema operativo con seguridad en mente.

OpenBSD, FreeBSD…tal vez AIX, NetBSD o hasta un Windows endurecido (hardening). Pero instalar un Windows con sus default con el típico next, next, next, finish y dar por sentado que ya podemos empezar a manejar esos sistemas que administran una presa o una planta eléctrica, pues sí que deja mucho que desear. Aclaremos, usar Windows no es el problema, sino las decisiones que hiciste al instalarlo y el endurecimiento posterior que no hiciste.

En fin, y todo por las ganancias. Entiendo que MSFT dio este código fuente para ver si el gobierno ruso se animaba a comprarles más licencias. Si los rusos de verdad obtienen el código fuente que se ejecutan en los sistemas (¿en serio le dieron el “bueno”?), entonces podrán analizarlo calmadamente, ver sus debilidades informáticas y usarlas aquí y allá en sistemas de EUA y por qué no, de otros países.

Se me olvidaba preguntar. Microsoft es una compañía de EUA. ¿Es razonable pensar que el gobierno de ese país tiene acceso a las entrañas de los productos de esa empresa desde hace años? Ups.

Quisiera seguir con el blog. No hay tiempo, debo revisar unas comunicaciones extrañas de mi Vista hacia una dirección IP en Rusia. No creo que…no, claro que no.

Nota: esto de la entrega de código fuente no es la primera vez que sucede. Ha sucedido en el pasado y sospecho que sucederá en el futuro.