Auditoría de aplicaciones en Android - Tirando del hilo...

1 comentarios
En la actualidad el 90% de las personas llevan un terminal móvil en su bolsillo la mayor parte del día, con las ventajas que esto supone en cuanto a acceso a la información y poder estar conectado a la red en cualquier momento. No obstante, esto ha puesto a estos dispositivos en el punto de mira de los desarrolladores de malware y por tanto hace que nos debamos preocupar también de la seguridad de estos dispositivos al igual que lo hacemos con nuestros PC portátiles o de sobremesa, ya que el crecimiento de malware para dispositivos móviles está creciendo en gran medida día a día.

En la actualidad el sistema operativo que triunfa en estos dispositivos es IOS, pero en segundo lugar y no menos importante lo hace Android, que año tras año le va comiendo terreno al sistema operativo de la manzana. A continuación os muestro un gráfico de los porcentajes de uso de SSOO móviles del año 2013:

El objetivo de esta entrada en el blog es conocer un poco como podemos llevar a cabo la auditoría de una aplicación en Android que una empresa ha desarrollado y nos pide que evaluemos su seguridad. Para ello lo primero que vamos a hacer, como en todo proceso de auditoría, no es otra cosa que obtener la mayor cantidad de información de la aplicación. En nuestro caso, la investigación no va orientada a buscar malware, sino a testear nuestra APK para poder corregir posibles vulnerabilidades.

Estructura de una APK

A la hora de auditar cualquier aplicación o sistema operativo, es muy importante conocer como funciona y la estructura de ficheros de un proyecto en Android. Por tanto toda APK desarrollada contiene:
  • Un descriptor de la aplicación: AndroidManifest.xml, en donde podemos encontrar los permisos que necesita la aplicación, así como la definición de parámetros de funcionamiento. Un permiso sería poder hacer una llamada de teléfono desde la aplicación. Pincha aquí para más info.
<uses-permission android:name="android.permission.CALL_PHONE"/>
  • Código fuente de la aplicación: los ficheros .java que se ubican en la carpeta src, así como .
  • Ficheros de recursos: .xml con las interfaces gráficas, menús o parámetros usados por la aplicación, ficheros de imágenes (.jpg, .png, etc), archivos multimedia... todo ello en la carpeta res. Pincha aquí para más info.
Desempaquetando la APK

Lo primero que debemos hacer en este momento es desempaquetar el APK. Este fichero no es sino un fichero comprimido en ZIP,si nosotros renombramos la aplicacion .apk a .zip y abrimos con cualquier descompresor, podemos ver los archivos internos que trae, simplemente tendremos que utilizar la herramienta adecuada para poder visualizarlos correctamente.

1.Para el AndroidManifest que está codificado en XML binario usaremos apktool, disponible para Windows, Linux y MAC OS. Nos descargaremos de https://code.google.com/p/android-apktool/ la aplicación y el script de instalación según la plataforma que elijamos. Y ahora ejecutamos el siguiente código para poder obtener el XML original:

apktool d aplicacion.apk directorioSalida

2.Para los ficheros de código fuente, cogeremos el fichero classes.dex (está dentro de la APK al abrirlo con WinZip). Este fichero contiene las clases de Java compiladas en formato .dex, dicho formato es el necesario para ejecutarse sobre la máquina virtual Dalvik (Dalvik VM). 

Haciendo uso de la herramienta dex2jar (http://code.google.com/p/dex2jar) obtendremos un fichero .jar, que no es sino el fichero de clases compilado en java.. Para obtener el código java podemos usar JD-GUI (http://jd.benow.ca/jd-gui/) y analizar, ahora si, código java legible. Si lo que buscamos es algún tipo de malware, entonces deberíamos buscar si dicho código tiene alguna función sospechosa como: 
  • openFileOutput: método que nos permite escribir ficheros en la memoria interna.
  • openFileInput: método que nos permite leer ficheros de la memoria interna.
  • Socket: clase que se utiliza para comunicaciones Cliente-Servidor y por tanto intercambio de información.
  • Webview: clase que nos permite visualizar una Web dentro de una aplicación Android y por tanto la ejecución de código javascript, con las consecuencias que esto puede conllevar.
3. Por último tenemos los ficheros de recursos en la carpeta res donde encontramos, entre otras, las siguientes subcarpetas:
  • drawable: las imágenes que utilza la aplicación.
  • layout: ficheros xml con las configuraciones de las diferentes vistas de la interfaz. Para poder visualizarlas desde el código java se asocia la vista con estos ficheros xml. Además es necesario declaran en el AndroidManifest alguna actividad, caso de no ser así quiere decir que la aplicación no tiene interfaz de usuario y seguramente se instale como servicio de sistema, muy común en los malware.
  • menu: ficheros xml con las configuraciones de los menús.
  • values: ficheros de configuración como valores de las cadenas que aparecen en la interfaz, colores, estilos...
  • xml: ficheros xml con las preferencias que pueden ser configuradas en la aplicación, hay que tener cuidado con la información que la aplicación almacena sobre las preferencias de las mismas o datos nuestros, ya que cualquier usuario con acceso root o una aplicación con acceso a la memoria interna puede acceder a información sensible que contega el fichero de preferencias:

/data/data/nombre.del.paquete/files/shared_prefs/nombre.del.paquete_preferences.xml 

  • Podéis encontrar más información al respecto aquí.
Auditando AndroidManifest.xml

Manitree: el objetivo de esta herramienta es detectar posibles inseguridades en el fichero AndroidManifest.xml, ya que si introducimos en dicho archivo valores erróneos podemos comprometer la APK. Descargamos la aplicación en Kali Linux y ejecutamos sobre un archivo AndroidManifest.


En la imagen anterior vemos los permisos a los cuales tiene acceso la APK cuyo fichero xml hemos utilizado, vemos que nos da una advertencia bastante peligrosa (nivel HIGH) ya que la aplicación tiene acceso a la raíz del dispositivo (pathPrefix="/"), lo cual podría comprometer toda la info que podamos tener en el mismo. En esta aplicación el desarrollador debería haber indicado la carpeta en concreta a la cual se puede tener acceso, que debería ser pathPrefix="/directorio.de.la.aplicacion", y no la raíz del sistema.

Si ejecutamos la herramienta con otro fichero AndroidManifest.xml que hemos renombrado con SecretCode.xml obtenemos lo siguiente:


Esta vez hemos encontrado dos códigos de marcación ocultos (*#*#8351#*#* y *#*#8350#*#*), que pueden llevarnos a menús secretos o acciones ocultas (un ejemplo de una puerta trasera o backdoor) que se han reservado los desarrolladores de la aplicación.

A continuación os dejo un enlace donde podéis encontrar todos los permisos que podemos encontrarnos en el AndroidManifest.xml. http://developer.android.com/reference/android/Manifest.permission.html

Ingeniería inversa sobre una APK (.java)

Para llevar a cabo este proceso de ingeniería inversa existen multitud de aplicaciones que obtienen el código fuente a partir del código ya compilado, cierto es que existen ofuscadores de código, pero aún así es posible descompilar gran parte del código ofuscado.

El objetivo de nuestra auditoría no es centrarnos en este proceso, ya que nosotros ya tenemos el código fuente porque nos lo facilita el cliente. No obstante si vamos a indicar que existe una distribución Linux con un set de herramientas preparadas para ingeniería inversa, ya preparadas y configuradas, se llama Android Reverse Engineering (ARE) y podéis descargarla desde https://redmine.honeynet.org/projects/are/ sus credenciales son android/android.

A continuación enumeramos las herramientas que contiene y una breve descripción de las mismas:

  • Androguard: herramienta en python para manejar ficheros dex, apk, xml binarios y recursos android arsc.
  • Android sdk/ndk: kit de desarrollo de herramientas para android
  • APKInspector: herramienta con interfaz gráfica para la inspección de todos los ficheros contenidos en el paquete APK.
  • Apktool: herramienta de ingeniría inversa casi perfecta que te devuelve los ficheros originales de los que surgió una aplicación.
  • Axmlprinter: conversor de fichero xml binario a xml.
  • Ded: herramienta para descompilar apk de android.
  • Dex2jar: conversión de ficheros .dex a .jar.
  • DroidBox: herramienta de análisis dinámico de aplicaciones android. Lectura de hashes, paquetes entrada/salida en la red, operaciones de entrada/salida de ficheros, permisos eludidos, sms enviados, llamadas, fugas de información, etc.
  • Jad: descompilador de Java con interfaz gráfica disponible para MAC OS, Linux y Windows.
  • Smali/Baksmali: ensamblador/desensamblador de ficheros dex.

Análisis online con Andrubis

Existe en la red una aplicación llamada Anubis que nos permite chequear nuestros binarios de Windows en busca de malware. El proyecto ha ido creciendo y han creado Andrubis, el cual ahora también nos permite analizar las aplicaciones de Android en busca de malware, para lo cual obtenemos gran parte de información valiosa.

Andrubis nos ofrece un informe detallado sobre el comportamiento de la aplicación, incluyendo el acceso a archivos, acceso a la red, las operaciones criptográficas, código dinámico de carga y las fugas de información. Además también cuenta con un análisis estático donde nos indica las actividades de la aplicación, los servicios, las librerías externas y permisos que necesita.

Con Andrubis tenemos la posibilidad de llevar a cabo el escaneo online (APK máx 8MB) o descargarnos su APK desde la Web e instalarla en el móvil para auditar directamente cualquier aplicación. De una forma o de otra podemos registrarnos para que así nos cree nuestro perfil y puedan guardar todos los informes de todas las aplicaciones que hemos escaneado. Una vez registrados y activada nuestra cuenta vamos a probar el escaneo online:


Seleccionamos el archivo .apk y enviamos para su correspondiente análisis.

Una vez que termine el proceso podemos ver bastante información sobre la aplicación escaneada, tenemos la posibilidad de verlo en HTML o XML. Os dejo el enlace al reporte que genera:

https://anubis.iseclab.org/?action=result&task_id=16c9ab98c8e760ee455d61ec258f6ab15&format=html

De donde podemos sacar permisos que necesita la aplicación, urls, entrada/salida de ficheros en memoria interna, puertos de comunicación...

Análisis en el propio terminal móvil con ISecDroid (apk de Andrubis)

Además de la versión online podemos usar la aplicación de Andrubis para el móvil, sólo la podéis descargar de la Web ya no se encuentra en Google Play y es necesario estar registrado en la Web para introducirle usuario y contraseña. La aplicación se llama ISecDroid y al abrirla nos aparece la siguiente interfaz:


En la opción de Configuration ponemos el nombre de usuario y contraseña así como otras opciones más específicas de configuración, entre otras el poder analizar aplicaciones mayores de 8 MB. El siguiente paso es pulsar sobre la opción App submission y elegir aquellas aplicaciones de las cuales queremos llevar a cabo el análisis.


Le damos a Submit y lo que hace la aplicación es llevar a cabo el análisis y subir el reporte al servidor de la aplicación en la cuenta (username/password) que hemos configurado previamente.


Por último podemos ver en History los reportes de las aplicaciones que hemos analizado.


Lo bueno que tiene el registrarte en la Web de Andrubis es que todos los reportes de los análisis que has llevado a cabo tanto desde el escáner online como desde tú teléfono, son accesibles desde la Web en tu perfil de usuario. Lo vemos en la siguiente imagen:

Una cosa muy interesante de usar la aplicación de ISecDroid en el terminal móvil es que te genera un archivo .pcap con el tráfico de la aplicación, caso de que esta se comunique con algún servidor exterior.

En el siguiente link vemos el reporte del análisis de esta aplicación y vemos como obtenemos direcciones IP y dominios a los cuales se conecta. En el siguiente enlace lo podéis comprobar.

https://anubis.iseclab.org/?action=result&task_id=1c0ca8f10949f2224a5d3cee06e0e7ae8&format=html

Conclusión y Recomendaciones de Seguridad

Como hemos podido comprobar son muchos los datos que podemos obtener de un simple archivo APK y estos exponen información que puede hacer vulnerable nuestro sistema. A continuación os voy a dar una serie de recomendaciones a tener en cuenta a la hora de desarrollar una aplicación en Android, de manera que desde el primer momento que nos pongamos a escribir la primera línea de código, ya estemos teniendo en cuenta la seguridad de la aplicación:

  • Mantener una política de privacidad en cuanto a los datos que se utilicen en la misma.
  • Reducir al mínimo los permisos que se le facilitan a la aplicación.
  • Dar a elegir a los usuarios donde almacenar la información.
  • No recabar en la aplicación información innecesaria que nos pueda comprometer.
  • No envíe información del dispositivo a través de la aplicación.
  • No reutilices código fuente que no entiendes.
  • No almacenes a través de la aplicación ficheros logs sobre usuarios o información de tu dispositivo.
  • Usa mecanismos de ofuscación de código para evitar o dificultar la ingeniería inversa.
  • En todas las entradas de datos debes tener en cuenta su validación previa para evitar posibles errores.
Llegados hasta aquí, creo haber dado una visión en profundidad tanto de la estructura interna de una aplicación en Android, como los posibles fallos de seguridad que podemos encontrar en ellas. Hemos mostrado algunas herramientas que son de utilidad, pero existen muchas otras en la red igual de válidas. Además de estas técnicas, también podemos añadirle a nuestro análisis otras comúnmente usadas, como el escaneo externo de puertos que usa la aplicación o la obtención de metadatos de los ficheros de la misma.

Sin más, me despido hasta la próxima entrada, no sin antes nombrar a Miguel Ángel Arroyo (@Miguel_Arroyo76) responsable del magnífico blog http://hacking-etico.com. Espero que te sirva esta información, ya que siempre somos los demás los que ampliamos conocimientos gracias a tus charlas, entradas en tu blog o tus tweets. 

Un handshake compañero !!

@eduSatoe

"No se puede desatar un nudo sin saber cómo está hecho."
Aristóteles

Fraude online: Infraestructura FastFlux

0 comentarios
Algo que siempre me ha llamado la atención es conocer la forma en la que actúan los cibercriminales, que métodos utilizan para distribuir malware sin que nos demos cuenta etc.. Por ello siempre he estado buscando información sobre este tema e intentar llevarlo a cabo yo mismo dentro de mi propia red virtual para ponerme en la piel de un cibercriminal. Viendo la facilidad con la que se puede llevar a cabo este ataque, voy a explicaros de que trata eso de "Infraestructura FastFlux" de la mejor forma que pueda para que no sean tan técnico y hasta las personas que no tengan mucha idea sobre esto, sepa de que va y pueda así tener un poco más de seguridad a la hora de navegar por Internet.

A diario que navegamos por Internet hacemos peticiones a los servidores para ver su contenido y poder navegar por el sitio web del dominio. Esto es una simple arquitectura cliente-servidor. Os dejo una imagen a continuación y os explicaré paso a paso lo que hacemos todos los que navegamos por Internet a diario.

Conexión a un servidor web

Paso 1: Cuando queremos entrar por ejemplo en el dominio marca.com para visualizar su contenido, lo primero que hacemos es teclear en la barra de direcciones la url que en este caso sería, http://www.marca.com, al hacer esa petición le preguntamos a nuestro servidor DNS que normalmente es el que nos proporciona nuestro ISP (vodafone, orange, ono..) si conoce la dirección marca.com.
Paso 2: El servidor DNS nos contesta con la dirección IP que corresponde a marca.com.
Paso 3: Hacemos la petición HTTP a la dirección IP que nos dio anteriormente el servidor DNS, es decir 193.110.128.199.
Paso 4: El servidor de marca.com nos responde con la página principal y así podremos navegar por la página y visitar cada una de las secciones que tenga.

Una vez entendido como funciona esta arquitectura tan típica de cliente-servidor, vamos a ponerlo ahora un poco más complicado y explicaremos en que consiste la infraestructura que utilizan muchos cibercriminales llamada FastFlux simple para distribuir código malicioso, hacer phishing, enviar spam entre otras cosas. Es muy común ver en esta técnica como los ciberdelincuentes utilizan dicha técnica para intentar ocultar la dirección del servidor, una de las maneras puede ser con goo.gl o bitly. En esta técnica el servidor DNS devolverá varias direcciones IP que irán cambiando cada cierto tiempo muy corto. Estas direcciones IP serán zombies (ordenadores infectados) que actuarán de proxys (intermediarios) entre el cliente que será la víctima y el servidor atacante que quiere infectarnos. En la siguiente imagen podemos verlo y a continuación pasaré a explicarlo.

Infraestructura FastFlux simple

Paso 1: Al igual que en el anterior ejemplo que hemos visto, le preguntamos al servidor DNS por la dirección de ejemplo.com
Paso 2: El servidor DNS le responde con la dirección IP 1.2.3.4 que en realidad no es la de ejemplo.com, es la de un servidor proxy que está haciendo de intermediario.
Paso 3: La víctima hace la petición HTTP a la dirección 1.2.3.4 que se trata de un ordenador infectado haciendo de proxy.
Paso 4: El ordenador zombie hace la petición al verdadero servidor ejemplo.com el cual la víctima en ningún momento sabe que este existe, está oculto para el, sólo es visible por el ordenador zombie.
Paso 5: El servidor real le devuelve al proxy  la petición que había realizado.
Paso 6: El proxy le devuelve a la víctima la respuesta que le ha dado el servidor real, en la comunicación que existe en el paso 3.

Cada poco tiempo el DNS devolverá una dirección diferente a la victima, todas esas direcciones IP que le devuelva serán de ordenadores infectados que actuarán exclusivamente como intermediarios entre el dominio ejemplo.com y la víctima.

Y os preguntareis, ¿Cómo detectar este tipo de red? podemos detectar que es una red fastflux con la herramienta dig la cual nos permite hacer consultas al servidor dns y así obtener la dirección IP del servidor al que se hace la consulta, en caso de darnos varias direcciones IP con un TTL (Tiempo de vida) bajo, posiblemente significará que nos encontramos frente a un servidor que esté utilizando una red fastflux y podemos comprobar haciendo varias peticiones durante 30-60 segundos como van cambiando las direcciones IP y de esta manera la estructura no siempre es igual, en ese caso es una clara infraestructura FastFlux por lo que con un simple baneo de IP no podríamos detener la distribución de malware. A continuación os dejo una imagen para que os podáis hacer una idea de como detectarlo.

Ejecución del comando dig


Una vez tenemos una idea de como actúan los cibercriminales, ya sabemos como evitar una posible infección. Añadir que estas personas, aprovechan noticias de gran repercusión para así poder conseguir infectar los equipos ya que, siempre que ocurre algo importante nosotros somos los primeros que buscamos información para saber que ha pasado exactamente. Mucho ojo ahora con la muerte del entrenador de FC Barcelona Tito Vilanova (En paz descanse) con los sitios que visitáis para buscar información porque seguro que muchos de los dominios se habrán creado hace horas para distribuir malware. Si queréis visitar un sitio porque creéis que tiene información pero la URL está acortada y no os fiais mucho, podéis visitar knowurl.com y escribirla para que os diga de donde viene exactamente e incluso hacer un virusscan, después podéis analizarla con los sitios que Edu nos enseño en su entrada de analizando objetivos sin hacer ruido.
knowurl.com analizando una url acortada

Un saludo!

@Joseliyo_Jstnk

Descubriendo la infraestructura con Maltego

0 comentarios
Aprovechando que Edu escribió su entrada sobre la primera fase de una auditoría de seguridad - Analizando objetivos sin hacer ruido, voy a hablaros de una herramienta que sin duda no puede faltar a la hora de la recolección de información. Maltego es una herramienta que se encarga de recopilar información y mostrárnosla de forma gráfica para que esta sea más fácil de analizar. Entre otras características nos permite iniciar búsquedas a partir de correos, IPs, dominios, etc..

Por suerte, Kali incluye esta fantástica herramienta la cual ejecutaremos simplemente introduciendo el comando maltego en una terminal para que se inicie. Una vez iniciado tendremos que registrarnos para poder usarla. Después de registrarnos nos saldrá un asistente para seleccionar cual va a ser el dominio que vamos a escanear y el tipo de escaneo entre otras cosas que pueden ser los siguientes:
  • Company Stalker: Intentará obtener todas las direcciones de correo y cuales dan resultado en las redes sociales. También obtendrá los documentos alojados en el dominio y extraerá los metadatos. Necesita un dominio de entrada para analizar.
  • Footprint L1: Footprint de nivel 1, rápido y básico sobre el dominio.
  • Footprint L2: Footprint de nivel 2, medio sobre el dominio.
  • Footprint L3: Footprint de nivel 3, intensivo sobre el dominio. Este caso puede consumir muchos recursos y se necesita tiempo para llevarlo a cabo.


  • Person - Email Addres: Intenta obtener los correos de una persona y averigua los sitios web en los que aparecen. Se necesita indicar un correo para iniciarlo.
  • Prune Leaf Entities: Elimina las entidades sin nodos dependientes.
  • Twitter Digger: Busca una frase como un alias de Twitter. Puede darse el caso de que la máquina se vea bloqueada por la API de twitter.
  • Twitter Geo Location: Intenta encontrar la geolocalización de una persona en twitter


  • Twitter Monitor: Monitoriza Twitter en busca de hashtags.
  • URL to network add domain information: A partir de una URL obtiene información del dominio y la red.



En mi caso he seleccionado Footprint de nivel 2 y el dominio que le he indicado ha sido pp.es de lo que ha conseguido la siguiente información:




Como podemos ver en la esquina inferior derecha hemos obtenido registros MX, NS, redes entre otras cosas.. Al acercar el gráfico hasta algún punto podemos encontrarnos la información más ampliada.



Con esta herramienta tan sencilla y en un simple Footprint de nivel dos hemos conseguido información muy valiosa de un dominio, la cual podemos utilizar en el paso previo al ataque como es el de recolección de datos de nuestra víctima haciéndonos una idea de como está distribuido su dominio y a partir de ahí conseguir escanear por ejemplo hosts en busca de vulnerabilidades, aunque también podríamos obtener información de una persona en concreto y lanzar ataques dirigidos.

Un saludo :-)!




Analizando objetivos sin hacer ruido

0 comentarios
Al igual que lo haría un ciberdelincuente, el primer objetivo antes de un ataque es la recopilación de información para conocer más a fondo nuestro objetivo. Se pueden utilizar diferentes técnicas, desde un simple escaneo de puertos a una dirección IP mediante NMap (búsqueda activa), hasta una simple búsqueda a través del servicio Whois para obtener información gracias a un tercero (búsqueda pasiva).

Tenemos que ser capaces de ponernos en la piel del atacante y actuar al igual que lo haría él, sin conocimiento alguno del objetivo (pruebas de caja negra). Lo más importante es no dejar rastro a la hora de llevar a cabo el descubrimiento de vulnerabilidades, para lo cual podríamos usar algún sistema de proxys como Proxy Chains o la la famosa red Tor, en próximas entradas nos centraremos en ello.

Nosotros nos vamos a centrar en la utilización de varias páginas y servicios de Internet que nos ofrecen gran cantidad de información de nuestros objetivos, lo que se conoce como búsqueda pasiva de información. Las páginas a usar son las siguientes y vamos a explicar que información podemos sacar de cada una:

WHOIS.NET - Obteniedo info de un dominio

Mediante el protocolo whois podemos descubrir mucha información de cualquier dominio simplemente buscamos una Web la cual nos de servicio de dicho protocolo y este accederá a una base de datos de los servidores whois para obtener información como el propietario del dominio, nombre del administrador, correo, etc.


Aquí podéis ver los resultados de la búsqueda y la cantidad de datos que obtenemos:



URLQUERY.NET - Analizando posible malware en un dominio

Urlquery es una Web que nos da servicio para analizar y detectar posible malware en un determinado dominio Web, además de obtener información de dicho dominio como su IP, su ASN (ISP), la ubicación, etc.


Podemos ver en la página principal como aparecen las últimas búsquedas y cuales han sido sus resultados en cuanto a Sistemas de Detección de Intrusos (IDS - Intrusion Detection Systems) y Listas Negras (BL - Black List)

Una vez que hacemos la búsqueda podemos comprobar si algunos de los script antimalware que se les han pasado a la Web han detectado algo, así como IDS que hacen saltar las alarmas, también si la Web ha estado en alguna lista negra, etc.

Aquí podéis ver parte de los resultados de la búsqueda:


SHODAN - Buscando dispositivos

Shodan es un buscador de dispositivos según el software que utiliza, la geografía, el sistema operativo, la dirección IP y más. Lo primero que debemos hacer es darnos de alta, que es gratuito, y así nos devolverá muchos más resultados de las búsquedas.

Para buscar un dispositivo en la casilla de búsqueda podemos poner un dominio, una ip, una palabra en concreto e incluso usar operadores como city, country, geo, hostname, etc. Vamos a hacer una búsqueda sencilla, dispositivos cisco de españa:



Podemos buscar por palabras concretas sobre un cierto software o servicio como Apache o ip camera, o una cierta marca de router Zyxel, o por un cierto modelo de decodificador de satélite dreambox. Si Shodan lo tiene en su base de datos, nos lo mostrará.

NETCRAFT.COM - Información de dominios

Netcraft proporciona servicios de seguridad de Internet, nos facilita informacion de dominios y subdominios, si un dominio ha estado en alguna lista negra, la configuración que usan, el histórico de versiones, el sistema operativo utilizado, etc.

Vamos a llevar a cabo una búsqueda de un dominio y veremos los resultados obtenidos.

Nos salen los dominios y subdominios asociados, junto con otra información.


Ahora pulsamos en Informe del Sitio del sitio principal y obtendremos bastante información como: dirección IP, ubicación, servidores DNS, si ha estado en alguna black list, versión del servidor Web, si tiene o no activado PHP, etc. Para poder ver esa información pulsar aquí.

ARCHIVE.ORG - Ver historiales de sitios Web

Internet Archive es un sitio Web donde podemos encontrar los historiales de los sitios Web más visitados. A continuación vemos los resultados de una búsqueda para uno de estos sitios.



Así si un sitio Web ha eliminado cierta información que no podemos encontrar ya, haciendo uso de archive.org nos podemos ir a la fecha que si estaba publicada y verla.


Existe también una herramienta muy útil dentro de Kali Linux que hace uso tanto de búsqueda pasiva como de búsqueda activa para obtener información de dominios, se llama theHarvester, os dejo un enlace donde encontrar información: https://code.google.com/p/theharvester/

Además de todas estas Web de búsqueda pasiva haciendo uso de terceros, existen muchas otras, de tal forma que no tengamos que hacer ningún ruido para nuestra primera fase de una auditoria de seguridad, que no es sino la búsqueda de información.

Espero que os sea de utilidad !!

@eduSatoe

"Nunca releo mis libros, porque me da miedo." 
Gabriel García Márquez

dnsenum - Transferencias de zonas

3 comentarios
En mi primera publicación voy ha hablaros de una herramienta que a mi me llamó mucho la atención cuando supe de su existencia, se trata de la herramienta dnsenum. Antes de explicaros de que va, voy hacer una breve introducción a lo que sería un servicio DNS instalado en un servidor primario y como hace sus transferencias de zonas a uno secundario.

Cuando nosotros instalamos un servicio de DNS en un servidor primario, lo hacemos con la idea de facilitarnos el trabajo y no tener que recordar tantas direcciones IP ya que una de las funciones que realiza es la de traducir nombres en direcciones y viceversa. Un equipo cliente teclea el nombre del host remoto a un servidor DNS y este le contesta con la dirección IP correspondiente. A la hora de instalar y configurar este servicio, en ocasiones se hace la misma instalación en un servidor secundario para que en caso de que falle el primario, éste pueda resolver nombres a través de las transferencias de zonas que le delega el primario, aunque a veces esto no es tan bonito. A causa de una mala configuración podemos dejar al descubierto el archivo de zona de nuestro dominio. Y muchos de vosotros os preguntaréis ¿Qué peligro tendrá eso? pues bueno, el peligro basicamente es que en la fase de recopilación de información de un atacante o un test de intrusión, saber la estructura interna de una empresa puede significar un ahorro de trabajo muy grande y un avance considerable pudiendo conocer los subdominios, rangos de direcciones IP, hosts, registros MX etc...

El objetivo de esta herramienta es conseguir esa transferencia de zona que el servidor DNS primario le brinda al secundario, recordamos que la transferencia de zona siempre la inicia el servidor secundario. El uso de dnsenum es muy sencillo, basta con llamarlo y escribir acto seguido el nombre del dominio, por ejemplo "dnsenum ejemplo.com". En caso de que la transferencia de zona nos llegue, quiere decir que la configuración del servidor no tiene definido un servidor secundario(o ninguno en caso de no tener un servidor secundario) para realizar dicha transferencia. Vamos a ver un claro ejemplo con un servidor DNS bind9 del cual intentaremos conseguir la transferencia de zona con dnsenum que lo lleva incorporado la famosa distribución dirigida a la auditoría Kali.

El nombre de dominio que tengo en el servidor DNS es "joseluissanchez.local", por lo que llamaremos la aplicación en Kali simplemente escribiendo dnsenum joseluissanchez.local. Al no tener ningún servidor habilitado para la transferencia de zona me la dará sin ningún problema.




Como podemos ver, recibimos todos los registros que tiene la zona del dominio pudiendo ver rangos de direcciones IP, subdominios, también podemos deducir que quizás tengan un servicio de correo por los alias pop3, imap, smtp.. En este caso la zona del dominio no contiene muchos registros, en otras ocasiones nos podemos llegar a encontrar una transferencia de zona con miles de registros.

¿Cómo solucionar este problema? En caso de tener el servicio de bind9, basta con poner dentro de la configuración de la zona que tiene que tener el archivo named.conf.local lo siguiente; 

allow-transfer { 192.168.23.10; };

Pero.. ¿los que no tienen un servidor secundario al que le pueden hacer las transferencias están librados de este problema? ¡ERROR! deberán hacer el mismo paso anterior pero de la siguiente manera;

allow-transfer { "none"; };


De esta manera cualquier intento de transferencia de zona que no sea al servidor secundario o ninguno en caso de haberlo indicado así, no se realizará con exito y nos saldrá el siguiente mensaje.




Espero que haya sido de vuestro agrado la primera publicación por mi parte. Si queréis que hablemos de algún tema específico Edu o yo, siempre podeis escribirnos a nuestro email que lo teneis a la derecha.

Un saludo :-)!

@Joseliyo_Jstnk

Metaesploitable - Creando nuestro laboratorio de Hacking Ético

2 comentarios
En primer lugar daros la bienvenida a este nuevo blog de seguridad cuyos autores son @Joseliyo_Jstnk y un servidor @eduSatoe. Espero que sirva de punto de reunión entre aquellos que nos apasiona la seguridad informática y el mundo del hacking... siempre ético por supuesto !!

Hoy os vengo a presentar una distribución linux que nos va a ayudar mucho a la hora de hacer nuestras pruebas de intrusión, se trata de Metaesploitable: una máquina virtual linux, basada en Ubuntu, la cual nos ofrece unos servicios que están listos para ser vulnerados. Dicha distribución se suele utilizar para crearnos un laboratorio de prueba y aprender así sobre aspectos de seguridad, herramientas de testeo y técnicas de penetración, todo ello dentro del marco de la legalidad, ya que las pruebas de hacking las haremos contra esta máquina.

Lo primero que haremos es descargarnos la máquina virtual de la distribución Metaesploitable2 y cargarla sobre VMWare Player, también podríamos hacerlo sobre VirtualBox. Aquí el link de descarga de la versión 2:

Una vez descargada, descomprimimos el .zip de la nueva máquina y la abrimos desde VMWare Player. Si nos fijamos, aparece como máquina Ubuntu y con 512MB de memoria RAM. Arrancamos dicha máquina con Play Virtual Machine y entramos con los siguientes credenciales:
User: msfadmin  Password: msfadmin

Importante: Antes de arrancar la máquina debes configurar la tarjeta de red de Metaesploitable2 para que se vea en toda tu red, debéis seleccionar la opción de Bridged, para que así simule la conexión al router directamente, como si dicha máquina estuviera conectada físicamente a tu router.

Una vez dentro de dicha máquina hacemos ifconfig para obtener la ip de la máquina Metaesploitable2 y así saber la dirección ip a la que atacar. El siguiente paso es arrancar otra máquina virtual con Kali Linux o desde una máquina física que esté en el mismo rango de red que la máquina Metaesploitable2. La información que obtenemos es la siguiente 192.168.0.204/24

Nos vamos a nuestra máquina Kali Linux y comprobamos que estamos en la misma red ( (192.168.0.203/24). Ahora tan solo tenemos que utilizar algún escáner de puertos como Nmap y ver que encontramos: 
nmap -sV 192.168.0.204

El resultado del escaneo es el siguiente:


Y llegados a este punto sólo se trata de dejar volar la imaginación, ya tenemos información de los servicios que corren en el servidor objetivo (nuestro Metaesploitable2). Ahora sólo tendríamos que buscar posibles vectores de ataque, como buscar un exploit que afecta a un servicio porque tenga una versión que tiene una vulnerabilidad, un ataque de fuerza bruta, testear servicios en busca de "missing configuration" y un largo etcetera de posibilidades.

Espero que os haya servido y explotéis mucho vuestros Metaesploitables en vuestros laboratorios de hacking ético.

Saludos!! 

@eduSatoe 

"Vive como si fueras a morir mañana. Aprende como si fueras a vivir siempre
Mahatma Gandhi


Copyright © C43S4RS