Aprende a utilizar la herramienta CLI Nikto v2 para buscar vulnerabilidades conocidas en servidores en Kali Linux.

Cómo buscar vulnerabilidades en un servidor web usando Nikto2 en Kali Linux

Nikto es un escáner de vulnerabilidades de servidor web de código abierto, está escrito en Perl, disponible públicamente desde 2011. Nikto ofrece la posibilidad de buscar en servidores web vulnerabilidades ampliamente conocidas. Hace por sí mismo más de 6.400 verificaciones sobre fallas potencialmente peligrosas del servidor web. No todos los cheques son un problema de seguridad, aunque la mayoría lo son. Hay algunos elementos que son verificaciones de tipo "solo información" que buscan cosas que pueden no tener una falla de seguridad, pero que el webmaster o el ingeniero de seguridad pueden no saber que están presentes en el servidor. Estos elementos suelen estar debidamente marcados en la información impresa. También hay algunas comprobaciones de elementos desconocidos que se han visto escaneados en archivos de registro. Para obtener más información sobre Nikto, visite el repositorio oficial del proyecto en Github aquí  ovisita la documentación oficial aquí .

En este artículo, te explicaremos brevemente cómo utilizar Nikto de forma correcta y sencilla en Kali Linux.

¿Cómo usarlo?

Nikto se incluye de forma predeterminada en cualquier distribución de Kali Linux, por lo que si escribe en la consola:

nikto --help

Deberías poder ver todas las opciones que tiene la herramienta CLI en la salida. Ahora, para buscar vulnerabilidades en un sitio web / servidor es tan simple como ejecutar el siguiente comando:

nikto -h <server-ip> -p <port>

Donde:

  • -h: es la dirección IP o el nombre de host del servidor que desea escanear.
  • -p: como no todos los sitios web se ejecutan en el puerto 80, puede especificar el puerto con esta opción.

Ten en cuenta que algunos servidores pueden ejecutar varios sitios web en el mismo servidor, por lo que compartirán la misma IP, por lo que si desea un escaneo específico para el sitio web correcto, proporcione el dominio (nombre de host) en lugar de la IP, por ejemplo, google.com. Sin embargo, si deseas escanear un sitio web que utiliza un certificado SSL (conexión segura), el puerto obviamente también debería cambiar, por ejemplo, para escanear nuestro propio sitio web, simplemente podríamos ejecutar:

nikto -h ourcodeworld.com -p 443

Y el escaneo también debería comenzar. Con un sitio web seguro, verá también la información del certificado SSL y Nikto ejecutará una prueba adicional para verificar las vulnerabilidades en el certificado SSL. La salida de nikto en la línea de comando se ve así:

Nikto CLI Kali Linux Example

El escaneo tardará un poco. En nuestro caso, tomó alrededor de 15 minutos y Nikto realizó 8348 solicitudes buscando vulnerabilidades:

Nikto CLI completed scan

Como administrador del servidor, ¿debo arreglar todo en la lista generada?

Después de detectar todas las vulnerabilidades del servidor, depende de ti corregirlas en el servidor que acabas de probar. Ten en cuenta que no todos los + son vulnerabilidades, sino también información, por lo que deberás interpretar correctamente la información proporcionada por Nikto y proceder de acuerdo con la advertencia. Nikto utiliza los códigos OSVDB (base de datos de vulnerabilidades de código abierto) para proporcionar información sobre las vulnerabilidades descubiertas.

Por ejemplo, cuando escaneamos la salida de nuestro sitio web a través del protocolo HTTPS, tendremos advertencias adicionales:

- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          69.64.34.144
+ Target Hostname:    ourcodeworld.com
+ Target Port:        443
---------------------------------------------------------------------------
+ SSL Info:        Subject:  /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.ourcodeworld.com
                   Ciphers:  ECDHE-RSA-AES256-GCM-SHA384
                   Issuer:   /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
+ Start Time:         2019-05-18 14:53:34 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache
+ Retrieved x-powered-by header: PleskLin
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The site uses SSL and the Strict-Transport-Security HTTP header is not defined.
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Server leaks inodes via ETags, header found with file /cgi-bin/, fields: 0x31b 0x56c06c7df334a 
+ The Content-Encoding header is set to "deflate" this may mean that the server is vulnerable to the BREACH attack.
+ Server is using a wildcard certificate: *.ourcodeworld.com
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-3092: /sitemap.xml: This gives a nice listing of the site content.

El mensaje "El servidor está usando un certificado comodín: * .ourcodeworld.com" lo genera la herramienta, pero, ¿qué significa esto? Quiero decir, estamos usando un certificado SSL para proteger el sitio web, eso es mejor que nada, ¿verdad? Bueno, en teoría Nikto muestra esta advertencia porque los certificados comodín son menos seguros que los certificados normales, ¿no es interesante ?. Otro ejemplo importante que debe interpretar correctamente es el siguiente: "El encabezado Content-Encoding está configurado para" desinflar ", esto puede significar que el servidor es vulnerable al ataque BREACH", puede encontrar una explicación detallada pero fácil de entender sobre el ataque BREACH aquí. Como se menciona en el artículo, la solución para este problema puede ser desactivar la compresión HTTP, pero ¿cómo demonios enviaría recursos sin comprimir a sus usuarios? Eso aumentaría los tiempos de descarga, etc., las soluciones recomendadas para este problema estarían en nuestro código, no en el servidor por sí mismo:

  1. Protegiendo las páginas vulnerables con un token CSRF.
  2. Agregar bytes aleatorios a la respuesta para ocultar la longitud comprimida real.
  3. Separar los datos sensibles de las páginas donde se muestra el texto de entrada.

El otro mensaje épico es el "OSVDB-3092: /sitemap.xml: Esto da una buena lista del contenido del sitio". Seguro que en algunos casos la exposición de esta información en un sitio web sería perjudicial, ¡pero este tipo de archivo es necesario para que Google Web Masters posicione el sitio web en google! Con tales mensajes, como pentester, no necesita ser paranoico y leer cuidadosamente las advertencias e intervenir adecuadamente para no estropear las cosas que ya están funcionando correctamente.

Feliz pentesting ❤️!


Interesado en la programación desde los 14 años, Carlos es un programador autodidacta, fundador y autor de la mayoría de los artículos de Our Code World.

Conviertete en un programador más sociable

Patrocinadores