Buenas a todos, hoy vamos a hablar de una historia basada en hechos reales pero que ha podido recibir cierto dramatismo, como los de las películas de los “States” pero a la española. Imaginaros por un momento que tenéis interés en tener todo el listado de teléfonos internos de una organización, ¿motivaciones para ello? saber por ejemplo el teléfono de alguien que no quiere ser localizado telefónicamente y solo nos deja comunicarnos con él vía email o solo nos permite llamarnos desde un número oculto (vease como ejemplo las ofertas de ADSL, que nos llaman al teléfono para ofrecernos una oferta, pero nunca nos dejan un teléfono de contacto para volver a preguntarles, aunque esto último sea un tema a tratar a parte ya que la mayoría de las veces viene motivado porque tienen bloqueadas las llamadas entrantes).

Ahora supongamos que esa organización utiliza teléfonos VOIP y tiene uno asignado a cada uno de sus miembros. Los números de los teléfonos no están publicados en Internet, así que teóricamente son imposibles de localizar… ¿o no?

Vamos a intentar probar si es posible averiguar este tipo de números de teléfono con un poco de vision, ingeniería social, algún fallo de configuración y una buena herramienta para identificarlo, pongamos como ejemplo, Anubis V1.3 [podría valernos un simple nslookup o dig, pero hay que hacer publicidad de nuestros productos ]

La teoría es la siguiente, analizaremos la página web de la organización y en casi la mayoría de las ocasiones localizaremos varios números de teléfono. Supongamos que todos ellos se caracterizan porque tienen los primeros números iguales y los últimos tres o cuatro varían. Por lo que podríamos suponer que esos últimos números fuesen consecutivos dentro de un rango.

Ya sabemos que los teléfonos de esta compañía comenzarían por 91-6-NÚMERO TAPADO-XYZ (91, si se tratase de un prefijo de Madrid), ahora nos faltaría averiguar el XYZ para terminar de averiguar todos los números que queremos localizar. Recordar que al comienzo del artículo hemos dicho que se trataría de teléfonos VOIP, y quizás hasta las letras IP del “Voz sobre IP” nos sirvan para algo…

Si consiguiesemos obtener un listado de las direcciones IP de la organización, obtendríamos también las direcciones IP de los teléfonos VOIP, hasta aquí todo bien, y… ¿cuánto os apostáis a que estas IP tienen algo que ver con el número?

En nuestro libro La biblia del Footprinting hablamos de varias maneras de conseguir direcciones IP internas de una organización. Para el ejemplo de hoy nos bastará con aprovechar un fallo de configuración en la transferencia de zona, habilitada hacia el exterior.

Tras solicitar una transferencia de zona recibiríaos el listado entero de direcciones IP de la organización (que podría llegar a ser muy denso por cierto), y entre ellos veríamos como se encuentran algunas IP que terminan exactamente igual que los teléfonos que hemos encontrado en la página web de la organización, ¿casualidad? no creo…. 

Contrastamos así que los teléfonos VOIP se construyen con un rango fijo al comienzo y los últimos números de su dirección IP. Y conseguiríamos de esta manera tan sencilla el listado completo de teléfonos de la organización. Ideal para un ataque de SPAM de marcadores automáticos y para averiguar cualquier teléfono que nos interesase.

Todas las pruebas han sido realizadas dentro de una jaula de faraday… saludos!

Buenas a todos, en el post de hoy os traemos un videotutorial acerca de la herramienta Wikto, en el que probaremos esta herramienta contra el panel de control Web de Flu.

Wikto es una aplicación desarrollada por Sensepost, con la que podremos desde localizar directorios, ficheros o la huella del servidor hasta localizar varias de las vulnerabilidades más comunes. Además, automatiza algunas búsquedas de Google Hacking para recuperar información de interés.

Os dejamos con el video, disfrutarlo:

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

saludos!

Buenas a todos, L0phtCrack es una herramienta bastante conocida en el sector y una de las más utilizadas a la hora de recuperar contraseñas en sistemas Windows. Se basa en ataques por diccionario y fuerza bruta, y combinaciones de ambos para romper el cifrado y averiguar las claves del sistema en claro.

A continuación os dejamos con un videotutorial que hemos grabado mostrando como recuperar los hashes de las contraseñas de la SAM de Windows y como crackearlos.

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

Disfrutarlo:

saludos!

Algunos shellcodes o malware incorporan protecciones para los curiosos, en el caso del malware por ejemplo para evitar que se pueda saber, por ejemplo, a que objetivos está enfocado el troyano. Cifran el archivo de configuración de manera que cuando el analista de malware se dedica a conseguir el archivo de configuración del troyano, se encuentra con que el archivo esta cifrado, de manera que es ininteligible a la vista del usuario.

El cifrado XOR en si, es vulnerable y se puede conseguir la clave al comparar varios mensajes cifrados en XOR

Existe una manera rápida de saber si realmente lo que estamos buscando se encuentra dentro de un archivo de configuración de esa manera podemos rápidamente hacer fuerza bruta de un string en un archivo cifrado.

La utilidad es del gran Didier Steven, el “mago de los PDF”, se llama xorsearch con esta utilidad podremos de manera muy sencilla hacer búsquedas contra un fichero cifrado con XOR.

Aquí tenemos un ejemplo del fichero en ascii, no se puede leer por lo tanto haremos una búsqueda con xorsearch

Descargamos la utilidad de aquí.

Ahora hacemos la búsqueda contra el fichero cifrado:

C:\Users\seifreed\Desktop>xorsearch config.dat credem.it Found XOR 11 position 1637: credem.it

Podemos ver que ha encontrado lo que estábamos buscando así que nos sirve para realizar las búsqueda de cosas concretas en archivos cifrados con xor.

Estaba continuando con el análisis del malware en la máquina virtual del artículo que salió ayer, sobre los Fake AV, cuando al volver a infectar la máquina virtual, ya que la tengo por snapshots para conservar las herramientas que tengo instaladas para hacer más tarde el análisis estático del malware, me encontré con ciertas sorpresas.

La máquina tenía que estar totalmente limpia y me encontré con estas peticiones DNS a servidores de Rusia…

En fin miré a que dominios hacía las peticiones y todos eran C&C de un Zeus, las búsquedas me llevaron al tracker de Zeus.

Buenas a todos, hace algunos meses publicamos el artículo PoC: Robar archivos de Android con Metasploit, un folio y un poco de salero, que tuvo mucho éxito, y algunos de vosotros nos pedisteis un video en el que se viese todo el proceso. Aprovechando que presentamos esta prueba de concepto en una ponencia recientemente y lo grabamos en video, lo hemos publicado para que podáis disfrutarlo:

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

Saludos!

Buenas a todos, en el post de hoy hablaremos de la herramienta Google Password Decryptor. Esta herramienta, publicada en 2010 por SecurityXploded, permite extraer usuarios y contraseñas de cuentas de Google que se encuentren almacenados en un equipo durante un proceso de auditoría de seguridad. Es totalmente funcional desde Windows XP hasta Windows 7.

Google Password Decryptor es capaz de extraer las credenciales de Google de un usuario de las siguientes aplicaciones:

• Google Talk
• Picasa
• Google Desktop Search
• Gmail Notifier
• Internet Explorer
• Firefox
• Google Chrome

Podéis descargarla gratuitamente desde aquí.

Una vez descargada la herramienta, procederemos a instalarla (siguiente, siguiente). Al ejecutarla nos mostrará una pantalla con una tabla en blanco en la que aparecerán los usuarios y contraseñas tras la recuperación de la información. Para comenzar dicha extración pulsaremos sobre el botón “Start Recovery”, y una vez que aparezcan los datos pulsaremos sobre el botón “Show password”:

¿Sencillo verdad? Una utilidad muy interesante para procesos de auditoría.

Cuidado de donde dejáis cacheadas las contraseñas… Saludos!

La ya famosa vulnerabilidad de RDP, gran protagonista de lo que llevamos de año, sigue captando el foco de atención. Esta vez hablamos de su incorporación al framework de Metasploit. En el presente artículo hablaremos de ello y realizaremos una prueba de concepto, enseñando como evitarlo.

¿Sobre cual probamos? Un 7 por ejemplo…

El equipo víctima será un Windows 7, el cual dispondrá de los servicios de escritorio remoto activos. Si estos servicios no estuviesen activos no se podría realizar el ataque DoS sobre la máquina. Además, si el servicio de escritorio remoto estuviera configurado con autenticación a nivel de red tampoco se podrá realizar la denegación de servicio.

Bien, imaginemos que la víctima dispone de un escritorio remoto, que permite la conexión desde cualquier cliente de escritorio remoto. Parece que la vulnerabilidad no es tan crítica como parecía… y encima sale, una vez Microsoft presenta el parche, visto así no es tan fiero el león como lo pintan, ¿no?

Configuremos Metasploit y probemos la eficiencia del ataque DoS… un poco de PoC por aquí… y bien, en Metasploit se dispone de un módulo auxiliar en la siguiente ruta auxiliary/dos/Windows/rdp/ms12_020_maxchannelids. Lanzamos el comando use, tras arrancar Metasploit, y accedemos a dicha ruta. Después con un show options se visualiza las distintas opciones que hay que configurar para lanzar el ataque.

¿Sólo tenemos que indicarle la dirección del equipo remoto? La respuesta es… SI. Con el comando set asignamos la dirección al parámetro RHOST y ejecutamos el comando run para lanzar la denegación de servicio.

Y una vez hecho esto… si la víctima es vulnerable, ¡actualizad administradores! Se obtiene lo siguiente…

En conclusión, se observa lo sencillo que puede ser tirar una máquina abajo, y lo sencillo que es configurar Metasploit para realizar diversos ataques. De nuevo, ¡actualizad!

Buenas a todos, hoy concluiremos la cadena de articulos sobre recuperación de contraseñas de Windows en texto plano y que comenzamos la semana pasada hablando de Mimikatz.

Tras la publicación de la herramienta Mimikatz,  Hernán Ochoa, autor de la genial utilidad Windows Credential Editor (WCE), ha publicado una actualización (versión 1.3), que incluye entre sus muchas funcionalidades las mismas que utiliza Mimikatz para recuperar las credenciales en claro de un usuario de Windows que se ha autenticado en el sistema.

La nueva versión de WCE (disponible tanto para 32bits como para 64bits), se caracteriza como en sus versiones anteriores por su sencillez. Para ejecutar el programa simplemente tendremos que copiar los archivos descargados en el equipo. A continuación y con un usuario con permisos de debug (que ya vimos la semana pasada como obtener), ejecutaremos la aplicación añadiendole el argumento “-w”:

wce.exe –w

Á continuación, si no ha ocurrido ningún problema deberíamos ver el usuario y su contraseña en claro:

Más sencillo imposible

Podéis obtener más información en el FAQ de la aplicación:

http://www.ampliasecurity.com/research/wcefaq.html

Espero que os haya gustado la cadena, saludos!

¿Quién no conoce ya el proceso del famoso Sticky Keys para saltarse una pantalla de login? Si bien hay que decir que se puede proteger al sistema contra este tipo de ataques, también hay que recordar que si se dispone de acceso físico a la máquina, la cosa pinta mal…

En GNU/Linux no se libran de un proceso similar, más bien similar por el objetivo y consecuencia, pero no en su precondición. El objetivo es ver si una máquina Linux dispone de un grub editable, y cambiar el boot para que se devuelva una shell, por ejemplo bash, y de este modo disponer de una shell de root por las buenas. Podéis pensar, ¿cómo va a funcionar eso? es una locura, ¡Linux es seguro! !no existe malware! y otros tópicos del montón…

Frente a frente con la bestia

Nos encontramos con un Linux, como diría Jhonny Face To Face, y nos preguntamos ¿me dejará editar el grub? Por defecto, en ciertas distribuciones si, y en otras podemos indicarle parámetros de booteo directamente… benne benne. Al arrancar la máquina nos encontramos con el grub, pulsando la tecla e, por ejemplo en ubuntu, se puede editar. Entonces, si me dejan editarlo… habrá que aprovecharlo.

En la línea dónde se llama a la imagen del kernel que se va a cargar y la partición y usuario con la que se arrancará el sistema se debe modificar de la siguiente manera:

Ahora, tecla F10, lanzamos el booteo y… si… una shell como root, para lo que quieras…

Bueno pues esto es todos por hoy… para quién no conociese esta técnica comentar que no es una vulnerabilidad, al igual que el sticky no lo es en Windows, solo es una mala configuración de las muchas que se pueden encontrar en las aplicaciones por defecto, así que cuidar vuestras configuraciones por defecto