Montando un HoneyPot SSH- Kippo

Un HoneyPot es, básicamente, un servidor vulnerable y fácil de atacar que colocaremos en nuestra red para atraer la atención de los atacantes y alejarlos de los servicios legítimos, además monitoriza y registra los intentos fallidos de autenticación y cualquier ataque contra el supuesto servicio. Os dejo más información en este enlace: honeypots.

En esta ocasión vamos a instalar “Kippo”, un honeypot para el servicio ssh, en un servidor linux.

Sigue leyendo Montando un HoneyPot SSH- Kippo

Mejorando nuestra WIFI – Montaje de un Hotspot con Hostapd y una Raspberry Pi

Hace un tiempo realicé un curso mediante Coursera sobre el Internet de las Cosas, un poco pobre, la verdad. El caso es que había unos requisitos hardware necesarios para hacer el curso entre los que estaba un kit starter de Raspberry Pi. Recomendaban la compra de este Kit en Vilros y creo que fue lo mejor que saque del curso. Puedes echarle un vistazo a la página si quieres: Kits Raspberry de Vilros.

Hace un par de días, y con un proyecto en mente que iré desgranando entrada tras entrada, desempolvé las raspberry dispuesto a darle un uso más cotidiano al miniordenador.

Hoy voy a explicaros cómo crear un Punto de Acceso WiFi con el que mejoraremos la calidad de nuestra red y tendremos un control total de ella gracias a nuestra RaspberryPi. Para ello necesitaremos una RaspberryPi con el SO Raspbian instalado, un adaptador WiFi, un cable de red, teclado y ratón. Sigue leyendo Mejorando nuestra WIFI – Montaje de un Hotspot con Hostapd y una Raspberry Pi

Insignia Padawan -El reto de Mondragón Universitatea

Os voy a contar la odisea que pasé para la obtención de la Insignia Padawan que reparte la Universidad Mondragón:

En primer lugar, os recuerdo que podéis revisar mis enlaces anteriores en los que relataba cómo realizar un “information gathering” para obtener información del objetivo a auditar, una serie de “recursos interesantes” que os pueden ayudar a hacer vuestro trabajo o mejorar vuestros conocimientos, y la “utilización de sinffers de tráfico” para analizar el tráfico de la red de un objetivo.

Además de lo anterior, realicé una reflexión en el foro de la universidad Mondragón acerca del caso de Hacking Team como excusa para reflexionar sobre la ética de los hackers. En concreto hacían las siguientes preguntas:

¿Qué opinas sobre la acción realizada contra Hacking Team? ¿Consideras que los hackers se han excedido en sus ‘funciones’? ¿Cuáles crees que deberían ser los límites del hacker? ¿Piensas que la ciudadanía es consciente del rol que los hackers pueden jugar en favor de su propia seguridad en la red detectando aquellos sitios que no son seguros ya sea porque ponen en riesgo los datos de los usuarios o bien porque hacen un uso ilegítimos de los mismos?

    En primer lugar creo que la pregunta acerca de los límites del hacker es tremendamente ambigua, es como preguntar “cuáles son los límites de un ser humano”. Cada hacker tiene sus propios intereses e ideales, ya sean “buenos”, “malos” o incomprendidos, por lo que habría que categorizar los distintos tipos de hacker. Si hablamos de los white hat, está claro, su límite es el marco legal; si hablamos de los black hat se puede suponer que no tienen límite alguno, ni legal ni moral; si vamos a referirnos a los gray… dependerá de cómo valoremos el poder de los ideales, el límite de lo moral o si el fin justifica los medios.

    De todas formas, tengo claro que en el momento que comercializas tus “descubrimientos”, realizados sin ningún tipo de consentimiento, para el beneficio propio en lugar de una mejora para la sociedad, estás en el bando negro, muy alejado de la ética o incluso de cualquier ideal.

    Por último, es obvio que la ciudadanía no es que no sea consciente del rol que pueda jugar nadie en cuanto a su seguridad, sino que directamente les es indiferente, y esto lo vemos cada día en los perfiles de las redes sociales, en la información que se hace pública, en vender el alma a las organizaciones aceptando a ciegas cualquier “terminos y condiciones”… Y para mí la culpa no es de la gente que usa la tecnología, ya que ellos simplemente son usuarios de un servicio y no tienen por qué tener conocimientos técnicos, sino de los fabricantes y responsables de estos servicios. Es posible pensar que el trabajo de los gray hat para dejar en evidencia a estas empresas puede servir para que dediquen más recursos a blindar la seguridad de sus beneficiarios, pero creo que va más hayá, cuando incluso a ciertas instituciones no les interesa que exista la privacidad. Yo he llegado a escuchar de boca de representantes legales, en un debate sobre redes anónimas, que el uso de ellas ya implica la ilegalidad, ya que si no tienes nada que esconder para qué las usas. Este argumento siempre me ha parecido tan banal…es como decir que “por qué no dejas la puerta de tu casa abierta, si no tienes nada que ocultar qué importa que tu vecino se entere de todo lo que haces”.

    Voy a dejarlo aquí porque creo que este tema da para largo. Un saludo a todos!!!!

Te invito a que te sumes al debate y dejes tu opinión.

EL ENIGMA

Para poder acceder al Reto final que la universidad establecía para entregarnos las insignias, primero debían poner a prueba nuestras aptitudes mediante un Enigma que teníamos que resolver. En él nos indicaban que teníamos que descargar un archivo de texto cifrado en el que estaba la resolución, y para poder descifrarlo antes necesitábamos hacernos con la clave. La única pista para ello, además del enlace a una web con acceso a una máquina DVWA (una aplicación hecha en PHP y MySQL para el entrenamiento de explotación de vulnerabilidades web), nos la daba el maestro Yoda:

consejoyoda
Pista Yoda

Estaba claro que lo que había que encontrar era la tabla con el nombre Guestbook dentro de la sección de SQL Injection del DVWA facilitado.

Primeramente verifiqué que existía esta tabla dentro del information_schema (el lugar donde se almacena la información sobre otras BBDD que contiene el servidor de MySQL) utilizando la inyección

%’ and 1=0 union select null, table_name from information_schema.tables #

guestbook
Captura de la salida tras la inyección

Ahí estaba. Ahora podía profundizar en el contenido de esta tabla y ver qué columnas existían. La siguiente inyección obligada era:

%’ and 1=0 union select null, concat (table_name, 0x0a, column_name) from information_schema.columns where table_name = ‘guestbook’ #

Columnas.png
Salida 2

Sabiendo las columnas existentes lo único que quedaba era sacar el contenido de las mismas. Una última inyección y ya tendríamos nuestra clave para descifrar el archivo que nos han proporcionado:

%’ and 1=0 union select null, concat(comment_id, 0x0a, comment, 0x0a, name) from guestbook #

Clave.png
Yoda nos da LA CLAVE

Parece que es Yoda otra vez el que nos da la clave para descifrar nuestro archivo: “use the force”. Seguiremos el mismo consejo que le dio a Luke una vez.

Descifrado.png
Descifrado del mensaje y resolución del enigma

ENIGMA descifrado y listo para solicitar audiencia ante el Consejo Jedi en la dirección que me han facilitado.

EL RETO

time

Ahora es cuando había que demostrar los conocimientos que teníamos. Tras supuerar el Enigma y solicitar audiencia en el Consejo Jedi, nos organizamos en grupos de 8 personas y a cada grupo se le facilitó un servidor con una serie de servicios instalados entre los que se encontraban tres archivos que debíamos proteger. El grupo del que yo era miembro era el autodenominado “JEDI WARRIORS” y teníamos por delante dos tareas…

Defensa del servidor:

La primera tarea era la de impedir que cualquier persona ajena al grupo tuviera acceso a nuestro servidor y, por tanto, a nuestros queridos archivos.

El primer paso fué realizar un análisis individual de las distintas vulnerabilidades que existían con distintas herramientas como nmap, para averiguar la información que podían obtener personas ajenas, y Nikto, Openvas, OWASP Zap, Sparta, Nessus o Acunetix para ver las vulnerabilidades a las que estábamos expuestos. En mi caso realicé un escaneo con las herramientas Owasp y Openvas, mostrándome ambas una vulnerabilidad grabe en la aplicación Cacti con sistente en una “inyección remota de comandos OS”. Además, compañeros míos realizaron trabajos de investigación para averiguar otras vulnerabilidades y la manera de explotarlas, como las de GitList, que en unos casos permitía el envío de comandos como ls, cd, cp… por medio del navegador, y en otros, como yo hice, la entrada en el servidor mediante metaesploit para la instalación de una webshell que me permitiese acceder a su sitema de archivos.

En segundo lugar, y una vez estudiado el servidor, había que proceder con las actuaciones de fortificación. Nos dividimos el trabajo acorde a los conocimientos y/o interés que teníamos en los distintos campos. Se ralizaron tareas como el cambio de contraseñas a contraseñas robustas, cifrado del http, el redireccionamiento obligatorio del puerto 80 al 443, actualización del servidor al completo, edición de la página web con el diseño personalizado del grupo, modificación del puerto ssh (del 22 al 3112), reducción de permisos de los usuarios, desactivación de la navegación web a través de directorios y, por mi parte, la securización del servidor FTP eliminando el usuario Anonymous, creación de un usuario funcional con contraseña robusta, la utilización de ssl, la gestión de permisos para poder descargar…

imageb

Ataque de los servidores enemigos:

Una vez fortificado nuestro servidor llegó el momento de atacar los del resto de compañeros y ver si las aptitudes de esos jóvenes padawans podían retener nuestro conocimiento de la fuerza xP.

Nos dividimos las IP’s por integrantes del grupo. En estas IP’s debíamos hacer más incapié a la hora de estudiarlas, pero eso no impedía poder intentar el ataque con el resto de servidores, lo primordial era obtener los archivos de los otros servidores y trasladar la forma y el conocimiento al resto de compañeros. Uno de los Jedi Warriors generó un script para obtener los archivos de los servidores FTP que no habían capado el usuario anonymous. Otros utilizaron la vulnerabilidad de gitlist para obtener los archivos mediante el navegador (un gran manual facilitado por Fabián). El acceso a los archivos level 03 a través de MySQL apoyándose en la vulnerabilidad anterior.

Por mi parte, cuando pude realizar el ataque, mis compañeros ya habían aprovechado todas las grietas de los servidores para obtener el mayor número de archivos, aun así analicé las ip’s que se me habían asignado pero no conseguí acceder de ninguna forma, estaban bien securizados, por lo que tuve que rebanarme más los sesos. Aprovechando que mis conocimientos estaban más orientados a las redes, y siendo consciente de que muchos servidores estaban en la misma porción de red y que nadie cifraba las comunicaciones salvo nosotros, intenté realizar lo que se denomina ARP Spoffing mediante el envenenamiento de tablas ARP. Para ello sigo los siguientes pasos.

Sigue leyendo Insignia Padawan -El reto de Mondragón Universitatea

Sniffers de tráfico

Un sniffer es una aplicación que comprende los protocolos de red que se usan en Internet y nos puede ayudar a obtener información que viaja por la red, siempre que tengamos acceso al tráfico que nos interesa. Evidentemente si la información que se atrapa con un sniffer está cifrada con protocolos criptográficos no es de utilidad.

En cualquier ocasión, todo el tráfico existente en la red va a ser tratado por nuestra tarjeta de red, pero según la configuración de ésta va a tratarlo de tres formas distintas:

  • La forma común y por defecto es la  de rechazar todo el tráfico que no esté destinado a ella y procesar el resto.
  • Procesar todo el tráfico existente en la red a la que estamos conectados, descartando el tráfico proviniente de otras redes. Este modo se conoce como “Modo Promiscuo”.
  • Procesar todo el tráfico existente sea cual sea la red que lo origine. Este modo es denominado “Modo Monitor”.

Analizando un protocolo inseguro – Telnet

Una de las aplicaciones más comunes utilizadas para la captura (sniffer) de tráfico es Wireshark, la cual voy a utilizar para analizar una captura ya existente y poder determinar la inseguridad del protocolo “Telnet” , ya que es un protocolo que no utiliza cifrado para la transmisión de información.

captura1
Captura de tráfico filtrada por telnet.

Para obtener información de la traza basta con hacer click derechpo encima del primer paquete que tenemos y seleccionar la opción “Follow TCP Stream”. De esta forma podemos ver qué contiene el flujo de comunicación seleccionado.

captura2
Selección de la información del flujo.

 

captura3
Información contenida en el flujo de paquetes.

 

 

Es fácilmente deducible el usuario y la contraseña utilizados para realizar la conexión al servidor, además del sistema operativo y los comandos utilizados en la sesión, así como el resultado de los mismos:

login: fake
Password: user
OpenBSD 2.6-beta
Comandos:
                       $ ls
                       $ ls -a
                       $ /sbin/ping http://www.yahoo.com

Analizando SSL

La siguiente captura que voy a utilizar es de una traza de tráfico SSL, que es un protocolo seguro que utilizan otros protocolos de aplicación como HTTP y usa certificados digitales X.509 para asegurar la conexión.

Captura4.jpg
Traza SSL

Se puede observar que en el segundo paquete, el equipo con IP 65.54.179.198 (equipo servidor, ya que en el primer paquete la IP 10.1.1.2 inicia la comunicación identificándose como cliente) envía el certificado. Voy a ver la información del flujo, como hemos hecho en el caso del telnet, para intentar identificar, por ejemplo, la autoridad que emite el certificado. Para ello el certificado debería estar en claro.

La entidad emisora del certificado es “RSA Data Security, Inc.”, empresa dedicada a la criptografía y al software de seguridad. En el mismo certificado vemos información acerca de “Verisign” que actuaba como una Autoridad de Certificación (AC) y se creó en 1995 a partir de la escisión de los servicios de certificación de “RSA Data”.

captura5
Información cifrada del flujo SSL con el certificado en claro.

Hay que indicar que le certificado asegura la identidad del servidor, ya que ha sido éste el que lo ha emitido.

Analizando SSH

Una alternativa a usar Telnet a la hora de conectarnos a máquinas remotas es SSH, que realiza una negociación previa al intercambio de datos de usuario. A partir de esta negociación, el tráfico viaja cifrado.

Voy  a intentar determinar en qué paquete de la traza comienza el tráfico cifrado.

Captura6.jpg

En los primeros paquetes se realiza la conexión y el intercambio de claves para el cifrado, pero podemos observar que en el número 13 de la traza, el que está seleccionado, el paquete enviado por el cliente es un “Encrypted packet” o “Paquete cifrado”, por lo que determinaremos que aquí empieza el tráfico cifrado, siendo el sshv2 el único protocolo que no va en claro.
Gracias a la seguridad de este método nos es imposible ver alguna información de usuario, como contraseñas de acceso,  tal y como sí hemos podido averiguar en métodos anteriores.

Y por hoy eso va a ser todo… a ser buenos!!!

 

Lección 2: Recursos insteresantes en lo que a hacking se refiere.

En esta corta entrada voy a hablaros de un par de sitios donde encontrar recursos o poder aprender algo de hacking.

  • En primer lugar me gustaría hacer referencia a un canal de youtube, “Palabra de Hacker”, de reciente creación, unos 8 meses, que ya presenta un alto contenido de material relacionado con el mundo de la ciberseguridad. Según la propia descripción del canal:

Un canal creado por la periodista Yolanda Corral dedicado al mundo de la seguridad digital donde el verbo hackear y el sustantivo seguridad se dan la mano para aprender con los mejores profesionales y construir entre todos una red más segura.

En él se organizan diversos hangouts en directo con distintos profesionales en la materia, charlas y entrevestias con gente como Chema Alonso (Actualmente CDO de Telefónica y anteriormente fundador y CEO de Eleven Paths), Josep Albors (director de comunicación y del laboratorio de ESET España) o Carlos Ayala (Consultor de Seguridad Informática y Ciberinteligencia).

 

  • Como segundo recurso os voy a enseñar una web que me gustó bastante y la incorporé enseguida en mi base de datos personal de recursos hacking. Se llama “hackthissite” y, a parte de contener multitud de información, enlaces a blogs, noticias, artículos… lo que me enamoró de ella fue la sección de “Challenges”. Esta sección se basa en la realización de misiones o retos, ordenados por dificultad, en los que se repasa todo el espectro de vulneravilidades conocidas (bueno, quizás no todo, pero sí un largo abanico). Solo tiene una pega: es en inglés.

Por ejemplo, el primer nivel de las misiones básicas, titulado “The idiot test”, denominado así por su simplicidad, nos solicita que introduzcamos una contraseña que, obviamente, no conocemos ni aparece, en principio, en nigún sitio. Únicamente nos dan la pista de que, si no tenemos ni idea, aprendamos HTML.

Simplemente hay que acceder al código fuente y buscar la password entre la estructura.

hachthisbasic

No os hagáis ilusiones, a partir de aquí la cosa se complica.

Por cierto, para acceder a todo este cúmulo de recursos es obligatorio el registro.

  • Y para terminar hoy, un enlace donde comentar, reunir opiniones, consultar información, en fin, relacionarte con otros amantes del hacking y la ciberseguridad, os voy a pasar una de las para mí más activas páginas que pueden encontrarse en facebook. Es la página de la “Organización Hispana de Ciberseguridad“. No es el único lugar de reunión, por supuesto existen multitud de ellos. Estudiadlos todos y me contais si algún otro os gusta más.

 

Que lo disfrutéis y… a ser buenos!!!

Lección 1: “Information Gathering”

Se entiende por cibercrimen, o delito informático, cualquier crimen que involucra una ordenador personal y una red (Moore, 2005). El equipo puede haber sido utilizado en la comisión del delito, o puede ser el objetivo.

El proceso habitual que sigue un hacker para realizar un ataque comienza con la obtención de información sobre el sistema que se quiere atacar: direcciones IP, nombres de sistemas, sistemas operativos, aplicaciones instaladas, etc. Es lo que se denomina “Information Gathering”, y se subdivide en dos paso: “Footprinting”, que consiste en la búsqueda de cualquier tipo de información pública, la cual puede conseguirse con el desconocimiento del objetivo o porque haya sido publicada a conciencia; y “Fingerprinting”, que consiste en analizar las huellas que dejan las máquinas, por ejemplo para obtener el sistema operativo, la versión de una aplicación, puertos abiertos, existencia de firewalls, etc.

Como tarea inicial vamos a intentar obtener información de un servidor web.
El host a atacar será http://www.euskalert.net (un servidor web de la universidad Mondragón con fines educativos).

ping

Como podemos observar en la imagen, al realizar un Ping sobre la url del host obtenemos la IP del servidor. Según los paquetes recibidos (cero) podemos suponer que dicho host no está disponible, o que tiene capado este protocolo o las ip origen que pueden realizar la consulta.

El siguiente paso será la realización de una consulta WhoIs sobre la IP obtenida anteriormente para sacar el nombre de la persona que figura como contacto técnico y administrativo, ayudándonos de la herramienta online de DOMAINTOOLS.

person:         Jesus Lizarraga
address:        Mondragon Eskola Politeknikoa
address:        Loramendi, 4
address:        E-20500 Mondragon
address:        SPAIN
phone:          +34 943794700
fax-no:         +34 943791536

person:         Pedro Amallobieta
address:        Mondragon Eskola Politeknikoa
address:        Loramendi, 4
address:        E-20500 Mondragon
address:        SPAIN
phone:          +34 943794700
fax-no:         +34 943791536

A continuación averiguaremos mediante una consulta nmap qué puertos están abiertos para el servidor objetivo euskalert.net. Basta con introducir el host a atacar en la aplicación y esperar los resultados.

En un primer momento, los resultados que obtuve no me daban mucha información, más hayá del puerto 80 abierto, uno de los denominados puertos bien conocidos, orientado a conexión (TCP) y utilizado para http, por lo que podía intuir que estamos trabajando con un servidor WEB.

Puertos.jpg

Sin embargo quería obtener algo más de información acerca de las aplicaciones y sus versiones que estaban corriendo en cada uno de los puertos y así averiguar algún tipo de vulnerabilidad existente que poder explotar. En ese momento volví a realizar distintos tipos de consultas, cada una de ellas con resultados diferentes:

  • Desde mi ordenador y utilizando el mismo aplicativo para la realización de las consultas ya no conseguía obtener información de los puertos.

scan_fail

  • Con una consulta online, desde la web “Self Audit My Server“, tampoco consegía obtener nada. Todos los puertos filtrados.

scan_self_fail

  • Sin embargo, un compañero desde Argentina, realizando la consulta a través de la misma web, obtiene el mismo resultado que yo obtuve en un principio: puerto 80 abierto. Pero segúia siendo información básica, y yo quería más.

scan_self_compa

  • Como última prueba, utilicé el aplicativo web de “Hackertarget“. En esta ocasión obtuve lo que quería, tanto los puertos abiertos, como la aplicación y versión que corre en ellos. Ahora sí podemos revisar qué vulnerabilidades podemos explotar. “Un servidor Apache httpd versión 2.4.7 corriendo en Ubuntu sobre el puerto 80” .

scan_hackertarget

No sé por qué los resultados en las distintas pruebas que hice difieren tanto. Quizás por algún tipo de filtro o firewall que distingue entre las redes de origen.

Me gustaría que desde Mondragón arrojasen un poco de luz a este inconveniente.

Lo último que realizaremos en esta entrada será averiguar si la versión de la aplicación descubierta, “Apache httpd 2.4.7 ((Ubuntu))”, tiene algún tipo de vulnerabilidad a la que esté expuesta.

Para ello vamos a consultar la Base de Datos de Vulnerabilidades Nacional de Estados Unidos (NVD) introduciendo en el cuadro de búsqueda las palabras “apache 2.4.7”.

Esta búsqueda nos devuelve un resultado con el CVE-2012-2378. En él podemos estudiar qué vulnerabilidad en concreto es posible aprovechar para lanzar nuestro exploit.

 

Y por el momento eso ha sido todo…..a ser buenos!!!!