30 junio 2014

Libro: El Arte de la Intrusión



El libro del que voy a hablar hoy, tiene ya sus añitos. En realidad, la versión en Inglés, “The Art of Intrusion” de Kevin D. Mitnick y William. L. Simon, data de Marzo de 2005.  Por cosas de la vida, nunca había reparado en esta obra, ya que el único libro de Kevin Mitnick que me había leído, mejor dicho, escuchado en audiolibro, era "The Art of Deception", pero fue en el evento Mundohacker Day, donde conocí en persona a Mitnick, que compré la edición en español, que la editorial Ra-Ma aprovechó a publicar para la ocasión. 


El libro narra diferentes historias relacionadas con el hacking, de una u otra forma, llevadas a cabo por gente con la que Kevin o el co-autor, se han entrevistado en alguna ocasión. Cabe resaltar que, en una de las historias del libro, el protagonista entrevistado es el llamado Robin Hood Hacker, el mismísimo Adrian Lamo que cuenta entre otras, sus peripecias con Excite@Home o The New York Times.

En cada capítulo, primero se narra la historia de cómo se le cruzó una víctima, entre ceja y ceja, al protagonista del mismo y cómo fue llegando más y más lejos, en la organización objetivo, saltando diferentes barreras para llegar al queso. Al final de cada capítulo, hay un apartado denominado “Dilucidación" (en la traducción al español), en la que Kevin desgrana la historia, identificando las diversas vulnerabilidades encontradas, las claves por las que el atacante logró rascar una pared de mármol con una cucharilla de postre y que le permitieron llegar al final. El objetivo de esta parte, es concienciar al lector, de las contramedidas a tener en cuenta para evitar que estos fallos puedan afectarle. En realidad, me recuerdan mucho a las guías que doy en ciertos módulos del curso “Buenas Prácticas de Seguridad en Entornos Corporativos”, respecto a medidas a tener en cuenta en seguridad perimetral, hardening de dispositivos, minimización de la superficie de exposición, procedimientos a tener en cuenta con provisioning de usuarios, gestión de contraseñas... y por supuesto, grandes dosis de concienciación a usuarios ante cómo comportarse tanto dentro de la oficina, como fuera de ella, para evitar caer en las fauces de un depredador ingeniero social.

Así como la mayoría de los capítulos se basan en ataques de red, excepto el primero que consiste en hacking de casinos (y que he de reconocer que me pareció sensacional), los últimos hablan de casos relacionados con ingeniería social, combinados con otras técnicas de hacking. 

Por un lado, se ve que los ataques recopilados son antiguos, pero hay que pensar que hablamos de un libro publicado en 2005. Si queremos ataques más nuevos, podemos leer “Hacking Épico” de mi compañero Alejandro Ramos y Rodrigo Yepes, cuya segunda parte esperamos con ansia unos cuantos. No obstante, las experiencias expuestas en el "El Arte de la Intrusión", pese a ser antiguas, son totalmente viables en servidores de organizaciones actuales, expuestos a Internet de una forma negligente, permitiendo tambalear los cimientos de la misma, a alguien con la motivación y el compromiso suficiente.

Desde el punto de vista de la edición en español, en la traducción he notado algún que otro detalle que le hace perder cierto rigor. Quizá traducciones al español del nombre de alguna herramienta o de alguna técnica de hacking, le resta algunos puntos. Quiero remarcar que los materiales utilizados para la plastificación del libro no han resultado de mi agrado. No es que yo tenga lija en las manos, pero el plástico brillante que protege la encuadernación, en mi caso, se ha ido desprendiendo a tiras,y he optado a quitarlo completamente, como se puede ver en la foto que comienza este artículo.

Por lo demás, un libro muy recomendable y entretenido. Aquellos a los que nos encantan las historias de épocas pasadas, en el que el hacking era de verdad, que había que devanarse los sesos para zapar metro a metro, y cuyos logros reconfortaban como si de ganar un Mundial se tratara, somos potenciales devoradores de “El Arte de la Intrusión".
Leer más...

29 junio 2014

Enlaces de la SECmana - 230


Leer más...

27 junio 2014

Desde Italia hasta tu móvil o PC con amor

No es nada nuevo que algunos(?) gobiernos han desarrollado y potenciado divisiones orientadas al ciber-espionaje, y la ciber-guerra. A estas alturas hablar de Stuxnet suena a material 'usado'

En este caso vamos a hablar de las nuevas revelaciones que ha puesto sobre la mesa Kaspersky y el dossier publicado sobre 'Galileo' un software de espionaje capaz de troyanizar todo tipo de sistemas operativos de PC y de móvil.

Meterle mano a un PC con Windows no es algo que sorprenda ni que impresione hoy día, por eso lo que más me ha llamado la atención es una de las formas que emplea este sistema para meterle mano a dispositivos IOS.

A día de hoy, pese a quién le pese, Iphone y en general cualquier dispositivo con IOS es claramente un sistema menos vulnerable ante el espionaje mediante troyanos. El ecosistema IOS, controlado por Apple, ofrece bastantes protecciones para que el móvil no sea 'troyanizado', en este punto creo que es de agradecer y de reconocer la política de seguridad de Apple con sus clientes.

Por eso, el método que emplea Galileo para troyanizar el móvil es bastante sutil. De entrada compromete y troyaniza un PC que ejecute Windows en el que el usuario del móvil tenga instalado Itunes para sus backups. Una vez el 'bicho' detecta la presencia del móvil, procede realizarle un jailbreak silencioso y a instalar 'el regalo'. 

Al menos con esta información se infiere que un móvil IOS sin jailbreak es razonablemente seguro. Algo a tener en cuenta

¿Y quién está detrás de este prodigio? Aparentemente una empresa Italiana llamada 'hacking team' que se dedica a comercializar este software. No es que se escondan, tienen hasta página web y un brochure de su producto incluso en Wikileaks se puede encontrar más información sobre lo que hacen.

En este punto es interesante detenerse y reflexionar sobre la industria de la seguridad 'para gobiernos', según citizenlab la 'cadena de transmisión' del espionaje pasa primero por una visita a VUPEN, empresa especializada en desarrollar exploits para comprar el exploit, y luego, visita a Hacking Team para comprar la herramienta que permite monitorizar al individuo. Como ir al súper y empezar por la carnicería, luego la frutería etc etc.

Otro de los puntos bastante curioso es cómo estas empresas se dotan de un halo 'pro gobiernos', se venden como desarrolladores de herramientas anti terrorismo etc etc pero existen indicios más que razonables que los vinculan a gobiernos totalitarios con fuerte componente represivo ante disidentes
Leer más...

26 junio 2014

Anti Ransom V2-BETA

Parece que la tendencia del RansomWare sigue al alza, cada vez se leen más casos y parece que esta nueva amenaza ha llegado para quedarse.

Hace tiempo publiqué Anti Ransom 1.0 como herramienta heurística que permite detectar un ataque de RansomWare y, en la medida de lo posible, evitar que se agrande el daño.

Mucha gente se descargó la herramienta y casi todos pidieron unánimemente que, además de detectar, se añadiesen medidas proactivas.

El pueblo habla, nosotros escuchamos: En esta nueva versión (todavía en fase BETA) he integrado varias herramientas de Sysinternals para poder detectar qué proceso es el que está editando los ficheros señuelo y detener el proceso provocando un volcado de su memoria.

Volcar la memoria del proceso permite, en teoría, poder localizar las claves que ha usado para cifrar el contenido del disco duro. De esta forma se podría llevar a cabo un análisis de la memoria del proceso y con la clave que haya usado, revertir las partes del disco que hayan sido cifradas.

En concreto estoy usando Handle y Procdump. La primera para localizar el proceso que está haciendo 'el mal' y la segunda para generar un volcado analizable mediante WinDBG.

Para instalar la herramienta, lo ideal es que tengas conectividad directa, esto es necesario ya que Sysinternals NO permite redistribuir su software así que es necesario descargarlo de la web. Si no tienes conectividad directa, simplemente descarga los ficheros zip de ambas herramientas en el directorio de instalación. En caso de tener conectividad directa, Anti Ransom descargará el solito las herramientas

Una vez hecho eso, simplemente ejecuta setup.exe


Y selecciona 'install'

Recuerda que es MUY IMPORTANTE NO BORRAR la carpeta de la instalación para poder desinstalar la herramienta. Esto es así para que resulte menos evidente que la herramienta se encuentra instalada en el sistema. La instalación/desinstalación no depende de Windows y se realiza únicamente desde el instalador. Para desinstalar hace falta LA MISMA CARPETA desde la que se hizo la instalación y ejecutar setup.exe pero en modo 'Uninstall'

Una vez se detecte la amenaza, debería salir un aviso tal que así:



Y junto con el aviso, un volcado de los procesos que hayan sido detectados como sospechosos. 

Mi idea, si el proyecto tiene calado, es ir desarrollando pequeñas sub-herramientas para analizar volcados de memoria y sacar las claves en función del tipo de malware que sea. 

Podéis descargar Anti Ransom V2-BETA desde aquí
Leer más...

25 junio 2014

Desde hace tiempo tengo ganas de rendir un merecido tributo al gran Ricardo narvaja quien sin duda es la persona que más ha hecho por crear documentación sobre ingeniería inversa en Español.

A SbD llegan recurrentemente correos del tipo 'cómo puedo iniciarme en temas de ingeniería inversa' y casi siempre respondemos enviándolos a la web de Ricardo Narvaja.

En su web (muy look 90's) podéis encontrar un montón de tutoriales para empezar en el mundo de la ingeniería inversa.

Para empezar, el ya mítico INTRODUCCION AL CRACKING CON OLLYDBG DESDE CERO que es el mejor amigo de todo aquel que quiera iniciarse en el uso de este debugger tan famoso y que en muchas ocasiones tanto intimida a alguien que nunca se ha puesto a profundizar en él.

Nos acercamos al verano y es buen momento para devorar tutoriales y practicar.

Una vez terminado el curso sobre la introducción a olly, se puede seguir por alguno de los que también se encuentran en la web de Ricardo y entre los que podemos encontrar información sobre anti-debugging, cómo escribir 'key-gens' o recursos sobre programación en ensamblador.

Si tienes ganas, tiempo y siempre has querido empezar en el mundo del reversing, no dudes en bajarte cuanto documento encuentres en la web del Sr Narvaja !
Leer más...

24 junio 2014

Versión en español del post también disponible => http://www.securitybydefault.com/2014/06/r2dr2-analisis-y-explotacion-de.html

------------------------

Since we began our studies in the Master's degree on ICT security at the European University, drew our attention the possibility of doing a project under the guidance of Alejandro Ramos (@aramosf), a professional of the scene that we admire. After several ideas and proposals by both parties, we decided to make a project about finding new attack vectors on distributed reflection denial of service attacks (DRDOS). Recently this blog talked about it in a article focused on SNMP vulnerability, publishing also a tool for exploitation.

We set ourselves the objective of finding some new amplification in various protocols. To do this, first we made a research about already known vulnerabilities which were published by CERTs and some communities related to computer security. Swiftly we realized the technical complexities with the conditions that had to have the vulnerabilities: based on UDP, not having authentication, with an amplification of at least 2 times the bytes sent, implemented on a large number of sites... and they have to been undiscovered.

We classified our search into three frames where to look: 
  • Common UDP-based protocols (such as DNS or NTP) 
  • Media streaming and game platforms. 
  • Private Applications that use UDP
Most undocumented protocols are just strings of bytes in and out. Each of them mean something, but, if the protocol is private, only the developer knows the meaning. After months of analysis and, some frustrations, we have managed to take advantage of several implementations based on UDP that can be used to make large-scale attacks:

SIP protocol: Options method 


SIP is a signaling protocol for VoIP whose implementation is identical to HTTP-based messages. The main difference, apart from its utility, is that SIP can operate on UDP port 5060. After a Shodan search we saw that there are over 40 million devices connected. Doing some deep research through the RFC we conclude that it was possible to reduce the "OPTIONS" request to some bytes and obtain an amplified response. Those servers that implement a response to "OPTIONS" with SDP information can have a big amplification.




RESPONSE TO "OPTIONS" REQUEST WITH SDP PROTOCOL IMPLEMENTED.


The returned messages had an average multiplier factor of 5 times for every byte sent, slightly above some of the protocols published by the US-CERT. Nowadays, there are over 2 million computers with this multiplier factor, so a highly distributed attack could make a dent on a big company.

Amplification in mobile games


The growth of multiplayer games is something that excited us, a very cool place to research. However, many of these games do not use UDP as transport layer, preferring to use APIs under TCP. Fortunately, most interactive games tend to use UDP, here we found serious vulnerabilities with quite high multiplication factors, some of them 500 to 700 times per byte sent The problem is that those services are not usually large enough to be considered hazardous. Additionally, some mobile gaming platforms like exitgames.com implements triple handshake implemented over UDP, which completely prevents such attacks..



BIG AMPLIFICATION ON “DEADZONE” GAME FOR IOS

Citrix ICA protocol amplification


In an almost obsessive quest to find large amplification factors, we detect that there was a property on a private protocol which had not been taken into account as a possible vector amplification UDP. The affected protocol is the Citrix ICA protocol, designed for shared application servers.



One of the features in certain versions of the protocol, is to communicate the client what shared applications exists, and also the available servers. This message is transmitted by UDP on port 1604 and it does not implement authentication. When the list of applications and servers is large enough, this information disclosure becomes an attack vector for DRDoS attacks.


AMPLIFICATION ON CITRIX ICA BROWSER.

With a simple payload of 84 bytes, a response with an amplification factor of 25 to 40 times for every byte sent is received. The interesting thing about this vulnerability is that in our discovery phase we detected over 12,000 Citrix servers and corroborated that at least 2,000 were vulnerable.

Operating Tool: r2dr2 DRDoS attack tool

To make our proof of concept, we have developed a full-featured UDP amplification attacks program, called "r2dr2". The main difference from other tools, is that it receives a JSON file with the configurations. There you can especify the payload of the running service in hexadecimal format, which makes it highly customizable. Our aim is that the tool will be able to exploit vulnerabilities found not only for us but also any other researcher; we have found that works very well with many protocols.


The following video demonstrates, on a real environment, a distributed amplification attack using UDP with only 10 Citrix ICA servers, that can deny service to a real server on the Internet.




 
Configuring payloads on r2dr2 This video only exploit Citrix ICA protocol information disclosure vulnerability, with almost 25 to 45 bandwidth amplification factor, but in the JSON file that r2dr2 receives you can configure much more payloads from different services and set the amount of times you want to use each IP. This example shown the payload required for amplification in the Citrix ICA UDP, SIP, CHARgen, and NTP protocols.



Dowload JSON configuration file for r2dr2
Download application: r2dr2 DRDoS UDP Amplification

Conclusions
This project has taught us much more than we expected; this is the final conclusion. Find vulnerable protocols it is not a trivial task, but as we demonstrated in the video, effectiveness is large. There will be ways to do DRDOS attacks for a long time, mitigation depends on the talent and budget of each organization.

Daniel Ferreira (@daniel0x00)
Pablo Alobera (@IllegalPointer)
Leer más...
English version of this post also available => http://www.securitybydefault.com/2014/06/r2dr2-analysis-and-exploitation-of-udp-amplification-vulns.html

------------------------

Desde que comenzamos nuestros estudios en el Máster Universitario de Seguridad de las TIC en la Universidad Europea, nos llamó la atención la posibilidad de realizar un proyecto bajo la tutela de Alejandro Ramos (@aramosf), profesional del mundillo que admiramos. Después de varias ideas y propuestas por ambas partes, decidimos realizar un proyecto centrado en la búsqueda de nuevos vectores de ataque de denegación de servicio distribuidos reflejados (DRDoS). Recientemente en este blog se ha hablado de ello en un artículo centrado en el protocolo SNMP, llegándose a publicar incluso una herramienta de explotación.

Nos marcamos como objetivo encontrar algún vector de amplificación nuevo en algún protocolo. Para ello, primero hicimos un research de cuales eran las vulnerabilidades conocidas, publicadas por CERTs y algunas comunidades relacionadas a la seguridad informática. Nos percatamos de la complejidad técnica al evaluar las condiciones que tenía que tener la vulnerabilidad: basarse en UDP, no tener autenticación, tener amplificación de al menos 2 veces los bytes enviados, encontrarse implantado en un gran número de sitios y no haber sido explotado anteriormente.

Clasificamos nuestra búsqueda en tres grandes “sitios” donde mirar, para organizarnos entre tanto protocolo: 
  • Protocolos comunes basados en UDP (como DNS o NTP) 
  • Plataformas de streaming o juegos. 
  • Aplicaciones privadas que usen UDP por alguna razón
La mayoría de los protocolos sin documentación no son más que ristras de bytes y más bytes entrando y saliendo. Cada uno de los bytes significa algo que, si el protocolo es privado, sólo la empresa desarrolladora conoce. Luego de meses de análisis y de, por qué no decirlo, frustraciones, hemos logrado aprovecharnos de varias implementaciones basadas en UDP que pueden ser utilizadas para hacer ataques a gran escala:

El método OPTIONS en el protocolo SIP

SIP es un protocolo de señalización para VoIP cuya implementación es idéntica que HTTP: basada en mensajes. La principal diferencia, aparte de su utilidad final, es que SIP funciona bajo UDP en el puerto 5060. Después de unas búsquedas en Shodan y ver que existen más de 40 millones de dispositivos, rebuscamos por el RFC y concluimos que era posible reducir la petición OPTIONS a pocos bytes con el fin de obtener una respuesta amplificada. Aquellos servidores que implementan en la respuesta al OPTIONS el protocolo SDP, responden con un mensaje más grande.

RESPUESTA AL MÉTODO OPTIONS CON PROTOCOLO SDP ACTIVADO.

El mensaje de regreso tiene un factor multiplicador de 5 veces por cada byte enviado, en promedio. Un poco por encima de algunos de los protocolos publicados por el US-CERT. Hay más de 2 millones de equipos con este factor multiplicador, por lo que un ataque muy distribuido podría hacer mella.

Amplificación en juegos móviles

El crecimiento de juegos multijugador es algo que nos entusiasmó, un lugar muy fresco donde buscar. Sin embargo muchos de estos juegos no utilizan UDP como capa de transporte, decantándose por usar APIs bajo TCP. Afortunadamente, para los juegos de más interacción, que si suelen utilizar UDP, se encontraron vulnerabilidades importantes con factores de multiplicación bastante altos, algunos entre 500 y 700 veces por cada byte enviado. El problema es que no suelen ser servicios masificados lo suficiente como para considerarse peligrosos. Además, algunas plataformas de hosting de juegos móviles ampliamente distribuidas como exitgames.com implementan triple handshake sobre UDP, lo que impide completamente este tipo de ataques.

AMPLIFICACIÓN GRANDE EN JUEGO “DEADZONE” PARA IOS.

Amplificación en aplicaciones: protocolo Citrix ICA

En una búsqueda casi obsesiva por encontrar factores de amplificación grandes, logramos detectar que había una característica de un protocolo privado que no había sido tenida en cuenta como posible vector de amplificación UDP en el protocolo ICA de Citrix, que es un protocolo diseñado para servidores de aplicaciones compartidas.

Una de las características del protocolo, en determinadas versiones, es comunicar al cliente qué aplicaciones compartidas existen en el servidor, así como los servidores disponibles. Este mensaje se transmite por UDP en el puerto 1604 y además no implementa autenticación. Cuando la lista de aplicaciones y servidores es considerablemente grande, este Information Disclosure se convierte en un vector de ataque de amplificación UDP distribuido.

AMPLIFICACIÓN EN CITRIX ICA BROWSER.

Con un sencillo payload de 84 bytes, se recibe una respuesta con un factor de amplificación de entre 25 y 40 veces por cada byte enviado. Lo interesante de esta vulnerabilidad es que en nuestra fase de descubrimiento detectamos más de 12.000 servidores Citrix de los cuales al menos 2.000 corroboramos vulnerables.

Herramienta de explotación: r2dr2 DRDoS attack tool

Para llevar a cabo la prueba de concepto, hemos desarrollado una completa herramienta de explotación de ataques de amplificación UDP, a la que hemos llamado “r2dr2”. La principal diferencia respecto a otras herramientas, es que ésta recibe de un archivo JSON varias configuraciones, entre las que destaca la recepción del payload de explotación del servicio en formato hexadecimal. Nuestro objetivo es que la herramienta fuese capaz de explotar no solo las vulnerabilidades encontradas por nosotros si no también cualquier otra del pasado y del futuro; hemos comprobado que funciona correctamente con varios protocolos.

En el siguiente vídeo se demuestra, en un entorno real, que un ataque distribuido de amplificación UDP utilizando apenas 10 servidores Citrix ICA es capaz de denegar el servicio a un servidor real en Internet. 


 
Configuración de payloads en r2dr2

El vídeo únicamente explota el protocolo ICA de Citrix, pero al archivo JSON que recibe r2dr2 se le puede configurar más payloads de distintos servicios y configurar las veces que se desea que se explote determinada IP. En este ejemplo se muestra el payload necesario para conseguir amplificación UDP en los protocolos Citrix ICA, SIP, NTP y CharGEN:


Descarga un archivo de configuración JSON de r2dr2
Descarga la aplicación r2dr2 DRDoS UDP Amplification

Conclusiones

Este proyecto nos ha enseñado mucho más de lo que esperábamos; esta es la verdadera conclusión. Encontrar protocolos vulnerables no es tarea trivial, pero como se demuestra en el vídeo la efectividad es muy grande. Existen y existirán formas de realizar ataques DRDoS, la mitigación depende del talento y del presupuesto de cada organización.

Daniel Ferreira (@daniel0x00)
Pablo Alobera (@IllegalPointer)
Leer más...

22 junio 2014

Enlaces de la SECmana - 229


Leer más...

19 junio 2014

Abierto el Call For Papers para la Ekoparty 10 #eko10

Hace unas horas se ha anunciado el Call For Papers para la próxima edición de uno de los congresos latinoamericanos más importantes: La EkoParty. La décima edición se celebrará entre los días 29 y 31 de Octubre en Buenos Aires (Argentina). La localización está por confirmar pero con el motivo de este aniversario, se avecinan varias novedades, como la ekoCamp, una zona de acampada en la que poder disfrutar de actividades a todas horas. Los días 27 y 28 tendrán lugar los trainings del congreso.


Sin más dilación, a continuación os dejamos el CFP que se ha publicado en la siguiente URL:

¡Estamos muy orgullosos de anunciar la décima edición del congreso de seguridad ekoparty! 

Este año va a ser especial debido a que celebramos la #eko10. Tendremos una nueva localización, la ekoCAMP para poder quedarte a dormir y disfrutar de actividades nocturnas, una gran fiesta de clausura y muchas más cosas especiales. 

ekoparty se ha convertido en la conferencia técnica más importante de Latinoamérica, ofreciendo los conocimientos más profundos sobre el tema. Esperamos poder volver a atraer a más de 3000 especialistas en seguridad. Si tienes algo que compartir ESTE es el congreso ideal, te arrepentirás si no asistes este año. 

Durante los tres días de charlas de alto voltaje, también disfrutaréis de actividades como el famoso LOCKPICKING VILLAGE, el WIFI ATTACK LABORATORY, WARDRIVING por la ciudad, WORKSHOPS gratuitos, el CTF más importante de latinoamerica, y sin olvidar, como no, ¡las geniales fiestas! También como novedad en esta #eko10:


* ekoCAMP: ¿tres días de charlas de alto voltaje no son suficientes? sólo por esta décima edición, ¡podrás acampar en esta ekoparty! ¡Quédate toda la noche jugando al CTF!

* ekoparty reconocerá la trayectoria de los investigadores de latinoamerica, así como sus impresionantes investigaciones. ¡Permaneced atentos!

El equipo de la organización de la ekoparty invita amablemente a quién esté interesado en mostrar y compartir sus investigaciones y / o desarrollos en el campo de la Seguridad de la Información.

Como temas de interés se incluyen, aún no siendo los únicos:
- 0 days
- Satellite Hacking
- Web Security
- Privacy
- Embedded Systems Technologies
- GSM, GPRS and CDMA Security
- RFID Security
- VoIP Security
- Lockpicking
- Wireless Security
- Exploitation
- IPv6 Security
- Attack and Defense Techniques
- Reverse Engineering
- Application Security, Testing, Fuzzing
- Code Auditing
- Virtualization Security
- Malicious Code
- Databases Security
- Packet Pungas
- Viruses, Worms, and Trojans
- e-crime, Phishing and Botnets
- Malware, Crimeware
- NSA’s Baby shower.
- Banking Security
- Phreaking
- Unit 61398 Asado techniques
- Hardware hacking
- Cryptography
- Forensics & AntiForensics

* Todas las charlas serán traducidas simultáneamente para romper las barreras con el idioma.

Tipos de propuestas:
Charlas completas (50 minutos)
Charlas turbo (20 minutos)
Talleres (120 minutos)
Formaciones (1 or 2 days)
Actividades nocturas
Juegos Geek

* Ponentes que incluyan una propuesta de taller conseguirán puntos extras en el CFP

Fechas importantes

18 Junio - Se abre el CFP
31 Julio - Primera ronda de selecciones
29 de Agosto - Cierre del CFP
27 & 28 Octubre - Formaciones de ekoparty 

29, 30 & 31 Octubre - ekoparty security conference

Privilegios para ponentes

Viaje de ida y vuelta
Alojamiento
ASADO ekoparty (BBQ)
Entrada extra para el congreso

Privilegios para los formadores

50% de los beneficios netos de la formación
3 días de alojamiento
ASADO ekoparty (BBQ)

Entrada para el congreso

Actividades extra

Buscamos nuevas actividades para ser llevadas a cabo en paralelo al congreso y durante la ekoCAMP para las noches. Envíanos tu propuesta a: organizacion@ekoparty.org 


Leer más...

18 junio 2014

Durante los tests de intrusión internos, uno de los hitos más importantes es aquel en el que, si todo va como la seda, consigues el listado de hashes de los usuarios del dominio o locales de algún sistema comprometido.

Desde hace años, la gran ventaja cuando se habla de la explotación y post-explotación en sistemas Windows es la utilización de una técnica llamada "Pass-The-Hash", la cual nos permite realizar autenticación en sistemas Windows utilizando el usuario y el hash obtenido, sin necesidad de su crackeo previo para averiguar la contraseña. Metasploit, el framework por excelencia para la realización de tests de intrusión, permite la introducción de hashes como autenticación (en lugar de la contraseña) tanto para módulos como para exploits que así lo requieran. Un lujo para no tener que dedicar horas a la obtención de contraseñas mediante crackeo que nos harían perder tiempo en situaciones en las que suele ser muy limitado.

Obviamente, la desventaja es si necesitamos acceder a un servicio que tenga integrada la autenticación con el directorio activo, ya que al no disponer de la contraseña y únicamente el hash, no podremos acceder a él. Esta autenticación NTLM nos la podremos encontrar por ejemplo para acceder a sistemas de administración de dispositivos (los cuales disponen de consola HTTP o HTTPS).

Pues bien, echando un vistazo a las slides de la charla que dieron Alva ‘Skip’ Duckwall y Chris Campbell en la BlackHat USA 2012, llamada Still Passing the Hash 15 Years Later… (video disponible en este enlace de Youtube), podremos hacernos con un conjunto de herramientas las cuales han sido parcheadas para que puedan realizar autenticaciones NTLM con usuario y hash una vez lo requieran, como por ejemplo, Samba, WMI, etc.

También publicaron (tanto para Windows como para Linux) una versión del navegador Mozilla Firefox que permite introducir hashes en lugar de contraseñas para realizar autenticación NTLM en servicios que así lo requieran, únicamente activando una opción de la configuración. La slide en la que lo presentan es la siguiente (número 46):



La opción de configuración se puede encontrar, accediendo al about:config y buscando la directiva network.auth.force-generic-ntlm para establecerla de su valor por defecto, false, a true:

Valor por defecto para la directiva network.auth.force-generic-ntlm

Estableciendo a true la opción network.auth.force-generic-ntlm
Sin duda, algo que nos ayudará a no utilizar esta técnica indispensable únicamente en Metasploit. En el mismo repositorio, los autores de la charla han parcheado algunas otras aplicaciones para permitir introducir hashes como contraseñas en caso de requerir autenticación NTLM, como por ejemplo, el cliente web por consola curl o la propia libreria libcurl, además de WMI y WinEXE, clon de psexec. 

En Kali se pueden encontrar un buen conjunto de binarios parcheados para permitir la autenticación NTLM a partir de hashes. En su mayor medida, el parcheo consiste en añadir una opción más de autenticación para que, si se incluye una cadena de texto de longitud NTLM se realice un Pass-The-Hash en vez de autenticación regular. Estos binarios los tenéis ya disponibles, comenzando todos por "pth-":


[+] Blog de passing-the-hash
[+] Repositorio Google Code de la Pass-The-Hash Toolkit
Leer más...

17 junio 2014

Haciendo un honeypot con Portsentry y Fail2ban





Hace unos días me desplacé a Santa Cruz de Tenerife a un evento organizado por el CECOES 1-1-2 en el que dí una charla titulada “En el (ciber)-amor y en la (ciber)-guerra, todo vale”. Y precisamente este título me viene al pelo para expresar lo que quiero contaros en esta entrada.

Cuando se hace una auditoría desde fuera a un sistema, una de las primeras pruebas que se llevan a cabo, es un mapeo de los puertos, o de los servicios que esa “dirección IP” ofrece. En base a eso, se intenta identificar qué tipo de servicio hay asociado a cada puerto, así como la versión del mismo. Posteriormente, se suele tirar de biblioteca para buscar vulnerabilidades existentes en las versiones detectadas, e intentar explotarlas para descubrir información extra, volcar ficheros de sistema, ejecutar código remoto o incluso ganar acceso directo al sistema. Obviamente, cuantos menos servicios se estén ejecutando en un sistema, así como más protegidos, actualizados y mejor configurados se encuentren, mucho mejor. A esto también ayuda una rigurosa configuración de la política de firewall que protege la máquina, ya sea perimetral o local, únicamente a los servicios de tráfico necesarios, tanto entrante como saliente.  

Seguramente, muchos de vosotros conoceréis ya Portsentry. Se trata de una herramienta que monitoriza un interfaz de red, en una serie de puertos que configuremos, y cuando detecte una conexión (ya sea TCP o un paquete UDP a un puerto dado) devuelva al atacante que el puerto está abierto e incluso un banner que definamos. Además, permite llevar a cabo acciones posteriores con la IP atacante, que generalmente consiste en banearle el acceso al sistema de alguna de las siguientes maneras: Añadir una ruta nula al sistema, incluirla como regla de iptables al principio de la tabla filter para INPUT o bloquearla mediante TCPWrappers. 

En mi caso, y teniendo en cuenta que cualquier escaneo, incluso un "nmap -F” probará el puerto 23 TCP, es donde pongo el señuelo. Para que esto funcione, la política de IPtables de la máquina ha de permitir el tráfico al puerto “trampa”, aunque no haya servicio escuchando “bindeado” en dicho puerto.

Esta es la regla en Firewall Builder para permitir que el tráfico llegue a portsentry


Así, cualquier dirección IP que pruebe un único TCP SYN al puerto 23 contra mi IP pública, su tráfico posterior será bloqueado, mediante una regla iptables. 

El problema que tiene portsentry, es que es capaz de bloquear una dirección IP, pero no he encontrado forma de establecer un tiempo máximo de baneo, quedándose hasta que se vuelva a aplicar el fichero con la política de iptables, siendo la opción de añadir una tarea al cron de la máquina, algo poco limpio.

Así que teniendo en cuenta que también tengo instalado Fail2ban en el sistema, que sí que es capaz de establecer ese control, he querido integrar ambas cosas.

En el caso de portsentry, cuando bloquea una dirección IP, lo deja, por defecto, en el fichero /usr/loca/psionic/portsentry/portsentry.blocked.atcp (al arrancar portsentry para que fucnione con -atcp), dejando una línea como esta: 

1402854031 - 06/15/2014 19:40:31 Host: 14.146.31.13/14.146.31.13 Port: 23 TCP Blocked"

Desde Fail2ban he creado un filtro tan sencillo como este: 

failregex = \/<HOST>  Port\: 23 TCP Blocked

y luego en el fichero /etc/fail2ban/jail.conf, un bloque como este otro:

[portsentry]
enabled = true
filter = portsentry
logpath = /usr/local/psionic/portsentry/portsentry.blocked.atcp
action = iptables-allports
             sendmail-whois-lines[name=portsentry, logpath=/var/log/fail2ban.log]
bantime = 604800
findtime = 86400
maxretry = 1

Así con que sólo vea una entrada en el fichero de log de portsentry (de hecho no puede haber más de una), debería bloquearlo… Sin embargo, lamento deciros que esto NO funciona así. 

Me daba un error que no era capaz de detectar el tipo de datetime del evento. Por ello, he tenido que modificar el fichero "/usr/share/fail2ban/server/datedetector.py", añadiendo un template de fecha específico para los logs de Portsentry en la clase DateDetector

# Portsentry 06/15/2014 19:40:31
template = DateStrptime()
template.setName("Month/Day/Year:Hour:Minute:Second")
template.setRegex("\d{2}/\d{2}/\d{4} \d{2}:\d{2}:\d{2}")
template.setPattern("%m/%d/%Y %H:%M:%S")
self.__templates.append(template)

Con esto, ha empezado a funcionar estupendamente, y tengo la tranquilidad de que Fail2ban gestionará el tiempo máximo que las direcciones IP permanecerán baneadas.


De estas y otras herramientas hablé en mi módulo, en el curso de "Attack y Hardening de Sistemas GNU/Linux" que dimos Yago, con la colaboración del gran Dabo, y un servidor, para Securízame

Aunque las sesiones online del mismo ya terminaron, aún puedes apuntarte a verlas grabadas desde WebEx, teniendo acceso a la plataforma de documentación y las sesiones hasta el 1 de Agosto de 2014. 

Por ello, si estás interesado, date de alta en el formulario y contactaremos contigo…    
Leer más...

16 junio 2014

Las consecuencias de un servicio FTP mal configurado




Cuando se quiere buscar alguna vulnerabilidad en el servidor que aloja una aplicación web o hace de hosting para ver el grado de implicación que ésta puede tener, una de las cosas que suele comprobarse es si la aplicación web se encuentra alojada en un servidor compartido y, de ser así, alquilar un espacio del disco duro del servidor compartido por el resto de los usuarios.

Otra opción es ver qué aplicaciones web se encuentran alojadas en el mismo servidor compartido. Para ello, con conocer la dirección IP del servidor que hace de hosting y utilizar un buscador como bing para ver qué aplicaciones web utilizan esa misma máquina con esa dirección IP 




 y después ver quién de ellos es vulnerable, se podría tratar de aprovechar las vulnerabilidades en el aplicativo web (en caso de que las tuvieran) y ver cuál sería el grado de incidencia en el hosting que las aloja
En la mayoría de las ocasiones, cuando se contrata un servicio de hosting, éste suele venir acompañado de otros servicios, como por ejemplo el servicio FTP para poder subir los ficheros web de la aplicación al servidor y, puede que el servidor FTP que corre en el hosting no esté bien securizado. 




Para comprobar si nuestro servidor FTP está bien securizado y enjaula a los clientes, después de tener acceso al servicio de hosting contratado, probé a conectarme desde un cliente FTP al hosting como se muestra en la siguiente imagen:




Me llamó notablemente la atención que el cliente FTP mostrase la ruta absoluta de mi directorio HOME, /home/centroXXX, así que, como el servidor al que me había conectado hacía las funciones de hosting, probé a poner en la ruta absoluta del cliente FTP /etc/apache2 a ver si podía ver los ficheros de ese directorio:




Como el hosting sí me permitió ver el contenido del directorio /etc/apache2, decidí probar a ver si era posible obtener el nombre de los usuarios que compartían el disco del servidor conmigo, y el resultado fue positivo.



De esta forma podría saber qué usuarios estaban compartiendo hosting conmigo y muy probablemente los nombres de los usuarios bajo el nombre de dominio coincidieran con los nombres de usuarios de otros servicios en esa misma máquina, tales como usuarios de FTP, SSH, correo electrónico. 
Podría pensarse en dar un paso más allá y con la información obtenida gracias a la mala securización del servidor FTP, obtener datos de los ficheros de log para, con la información recogida, tratar de realizar ataques de ingeniería social.




Contribución por cortesía de Amador Aparicio
Leer más...

15 junio 2014

Enlaces de la SECmana - 228


Leer más...

14 junio 2014

Conferencias UPM TASSI disponibles en Youtube

Copiamos la información con las charlas de TASSI 2014, personalmente he visto  la de Raúl Siles y Pablo Gonzalez y me han parecido muy interesantes. Os las recomiendo en ambos casos ya que son expertos en la materia y tienen gran experiencia profesional y divulgando información.

----
Se encuentran disponibles en el canal YouTube de la Universidad Politécnica de Madrid los 7 vídeos del X Ciclo de Conferencias UPM TASSI 2014, impartidas en el campus sur de dicha universidad en Madrid, España, entre el 20 de febrero y el 22 de mayo de 2014:

Conferencia 1: Latch. Protección de identidades digitales, a cargo de D. Antonio Guzmán de Eleven Paths

Conferencia 2: Posibilidades del voto telemático en la democracia digital, a cargo del Dr. Justo Carracedo de la UPM

Conferencia 3: Bitcoin: moneda y mercados, a cargo de D. Jonás Andradas de GMV

Conferencia 4: Protección de comunicaciones en dispositivos móviles, a cargo de D. Raúl Siles de DinoSec

Conferencia 5: Ethical hacking: afrontando una auditoría interna, a cargo de D. Pablo González de Eleven Paths

Conferencia 6: La amenaza del cibercrimen, a cargo de D. Juan Salom de la Guardia Civil

Conferencia 7: Ocultación de comunicaciones en el mundo real. Esteganografía y estegoanálisis, a cargo del Dr. Alfonso Muñoz de Eleven Paths

La documentación utilizada por los ponentes puede descargarse desde la sección TASSI de la página web de la red temática Criptored.


Leer más...

13 junio 2014

VUESTROS "ETHERNET EXPOSED" - XXV

Seguimos recibiendo más y más fotos con vuestros ETHERNET EXPOSED, imágenes que realizáis a tomas ethernet que se encuentren expuestas en lugares curiosos, transitados, accesibles... y que posteriormente nos enviáis a nuestra dirección de contacto.

En la edición de hoy contamos con las contribuciones de Steven y Civan.

En primer lugar comenzamos con la contribución de Steven, que nos cuenta lo siguiente:
Buen día amigos de SBD, hace algunos días estuve de paso por el Aeropuerto Schiphol en Amsterdam y en la sala de espera para abordar el avión (Puerta D47) me encontré con este bonito y elegante punto de red, señalizado y con la especificación de la categoría del cableado (CAT 6).. Les adjunto las imágenes 
Saludos Cordiales y Felicitaciones por el trabajo que realizan...


El aeropuerto de Schiphol en Amsterdam, visitado por los asistentes a Black Hat Europa, los cuales todos sabemos que alguno de ellos no se quedaría quieto ante algo así tan accesible. 

Por último, Civan nos presenta lo siguiente:
Hoy me ha tocado acercarme a renovar los certificados del DNIe en la nueva y flamante comisaría de CNP de Cáceres y me he encontrado con esta joya de instalación en un hall enorme con la única vigilancia de un agente de recepción bastaaante lejos.  
Cierto es que luego estas máquinas no funcionaban muy bien y me ha tocado meterme en otra sala con otra máquina más de estas, y más funcionarios cerca, pero la instalación de red era igual :D 
Quiero pensar y no fallar en que luego habrá un buen sistema de acceso montado por la red que está detrás, que si no me da algo. 


Curiosamente, de la mayoría de Ethernet Exposed que recibimos suelen tener este tipo de ubicaciones como protagonista, alrededor de toda España. La tranquilidad que nos deja siempre es que alrededor, siempre que el puesto esté dentro de las instalaciones, habrá alguien vigilando cualquier actividad sospechosa.

Como siempre os decimos, nuestra dirección de correo sigue abierta a todas aquellas contribuciones de ETHERNET EXPOSED que os encontréis, ¡muchas gracias a todos y hasta la próxima!

---------------

Leer más...

11 junio 2014

Zed Attack Proxy o ZAP es un proxy HTTP  ampliamente utilizado en los análisis de seguridad web. Nace como fork de paros, otro viejo conocido. Seguro que junto a Burp, es una de las herramientas más utilizadas para llevar a cabo pruebas manuales.

Una de las opciones más interesantes de las que dispone esta utilidad es la del "spidering" de la aplicación, que permite recorrer la página en búsqueda de recursos y sus formularios, sobre los que posteriormente se harán pruebas de seguridad. Estos tests también pueden ser hechos automáticamente por la propia herramienta. Además, tal y como se puede ver en la comparativa de sectoolmarket sus resultados son bastante buenos. Sobre todo si tenemos en cuenta que es una herramienta gratuita.

Una opción poco conocida es la de utilizar ZAP mediante línea de comandos. Para hacer esto hay que arrancarla y posteriormente interactuar con su API.

Para hacerlo aún más sencillo, os dejo por aquí un script que se encarga de arrancar el proxy y lanzar el análisis devolviendo un JSON con los resultados. Tan solo es necesario dejar el script dentro de la ruta de ZAP e invocarla con la URL a analizar como primer argumento. 


#!/usr/bin/python
import os
import subprocess
import time
from collections import defaultdict
from pprint import pprint
from random import randrange

from zapv2 import ZAPv2
import sys

if len(sys.argv) != 3:
    print 'usage %s <url>' % sys.argv[0]
    sys.exit()

print 'starting ZAP.'
proc1 = subprocess.Popen(['./zap.sh', '-daemon'], stdout=open(os.devnull, 'w'))
print 'proc1 = ', proc1.pid
print 'waiting for ZAP...'
time.sleep(20)

TARGET = sys.argv[1]
print "checking %s with zap" % TARGET
zap = ZAPv2()
zap = ZAPv2(proxies={'http': 'http://127.0.0.1:8080', 'https': 'http://127.0.0.1:8080'})
# TODO anyadir urls de otros scanners
zap.urlopen(TARGET)
time.sleep(2)
zap.spider.scan(TARGET)
print "spidering"
while (int(zap.spider.status) < 100):
    print 'Spider progress %: ' + zap.spider.status
    time.sleep(3)
print "spider completed"
zap.ascan.scan(TARGET)
print "spider results:"
pprint(zap.spider.results)

print "scanning"
while (int(zap.ascan.status) < 100):
    print 'Scanning progress %: ' + zap.ascan.status
    time.sleep(3)
print 'scan completed'
zap.core.save_session(sys.argv[2])

print 'hosts: ' + ', '.join(zap.core.hosts)

pprint(zap.core.alerts())

print 'shutting down ZAP ...'
zap.core.shutdown
proc1.kill()

Al final, nada sustituye el análisis manual que haga un hacker experimentado, pero para pruebas concretas, este tipo de soluciones son una buena opción.
Leer más...