FITT: Herramientas de auditoría Informática

Clase 13-14

NMap Scripting Engine

Aplicaciones

Instrucciones: Realice una investigación sobre el uso de las opciones y a partir de los escaneos que se presentan identifique cada el uso de cada opción.

Nmap –v www.falabela.com.pe

Esta opción sondea todos los puertos TCP Reservados en el Servidor.

La Opción –v activa el Modo detallado.

Escaneos por defecto:

a) Intense scanVer anexo.

b) Intense scan plus UDPnmap –sS –sU –T4 –A –v www.falabela.com.pe

c) Intense scan, all TCP ports

nmap –p 1-65535 –T4 –A –v www.acerosarequipa.com

d) Intense scan, no pingnmap –T4 –A –v –Pn www.acerosarequipa.com

e) Ping scannmap –sn www.acerosarequipa.com

f) Quick scannmap –T4 –F www.acerosarequipa.com

g) Quick scan plusnmap –sV –T4 –O –F –version-light www.acerosarequipa.com

h) Quick traceroutenmap –sn –traceroute www.acerosarequipa.com

i) Regular scannmap www.falabela.com.pe

j) Slow comprehensive scannmap –sS –sU –T4 –A –v –PE –PP –PS80,443 –PA3389 –PU40125 –PY –g 53 –script “default or (discovery and safe)” www.falabela.com.pe

Hping2

En base a la información que usted encontrará en:

http://www.hping.org/

http://www.hping.org/documentation.php

http://www.itforensic-la.com/revistas/El-Atacante-Informatico-Cp4.pdf

http://wiki.hping.org/86

Responda:

a) ¿Cuáles son las funcionalidades de ésta herramienta?b) ¿Para qué tipo de auditoría es recomendado?c) ¿Cuáles son las principales características técnicas de éste producto?d) ¿Cuál es el alcance de Hping /Hping2 / Hping3?e) ¿Cuenta con la documentación pertinente para su uso?f) ¿Cuáles son las destrezas mínimas que necesita el usuario para que

utilice la herramienta?

XSS

Cross Site Scripting (XSS)

En base al video: Auditando vulnerabilidades XSS

http://www.youtube.com/watch?v=Q-QZOOBJheM

Responda:

a) ¿Para qué tipo de auditoría es aplicable?b) ¿Cuáles son los conocimientos mínimos que debe de tener el

usuario?c) Visite:

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet ¿Qué información le brinda?

d) Véa el siguiente ejemplo descriptivo respecto a XSS:

Ejm.: Seguridad en Aplicaciones Java, Cross-Site Scripting, conocido por su abreviatura como

XSS.

Este ataque puede ser bastante complejo en cuanto al daño que se pueda hacer y los lugares

por donde se puede realizar (vectores de ataque). Sin embargo, el fundamento es muy similar al

de la inyección de SQL: usar datos que capturan los usuarios, sin validarlos apropiadamente.

La inyección de SQL permite que un usuario malicioso pueda enviar a una aplicación ciertos

datos que incluyan sentencias de SQL que se ejecutarán en el servidor de base de datos. Los

ataques de XSS usan ese mismo principio pero los datos que se envian, pueden incluir código

HTML y/o Javascript; la principal diferencia es que dicho Javascript es inocuo en el servidor pero

al ser incluido en páginas que se envían a otros usuarios, sus navegadores posiblemente

ejecutarán dicho Javascript.

¿Cuál puede ser el daño? Pues depende del Javascript que se inyecte en la página, pero a fin de

cuentas si el sitio permite que un usuario teclee un texto (por ejemplo un comentario en un foro)

y ese texto contiene comandos de javascript y se incluyen tal cual en la página generada ya con

ese comentario incluido, se le está dando oportunidad a un atacante de ejecutar programas de

Javascript en los navegadores de los otros usuarios que visualizan esa página. Pueden por

ejemplo leer todos los cookies del usuario y enviarlos a otro lugar; incluso si el navegador

solamente permite que Javascript invoque URL's del mismo sitio, puede ser que el atacante ya

tenga algo puesto en sitio (por ejemplo un foro o un perfil de usuario) y la info tomada de los

usuarios se envia como comentario o mensaje privado a dicho perfil.

Este ataque no es muy común en aplicaciones hechas en Java, gracias a que la mayoría de los

frameworks que se utilizan hoy en día como Struts, JSF, JSTL, Tapestry, etc, tienen ya integrada

la protección contra esto, por medio del componente o mecanismo que despliega cadenas

obtenidas en tiempo de ejecución, escapando los caracteres especiales como < y >

(principalmente) y algunos otros que podrían tener un efecto no deseado en el despliegue de

una página en el navegador del usuario.

El ejemplo que mostré en la plática simplemente incluía un campo de texto donde se pueda

teclear algo y después se despliega ese texto en la página (el típico "hola mundo" en JSP):<form action="xss.jsp">Escribe tu nombre: <input type="text" value="nombre" /><input type="submit" value="Enviar" /></form><% if (request.getParameter("nombre") != null) { %>Hola, <%= request.getParameter("nombre") %><% } %>

El problema es cuando se teclea algo como <script>alert('Hola!');</script>; si ese

texto tal cual se pone en la página generada, el navegador interpretará el Javascript y lo

ejecutará; como consecuencia, cuando se teclea el texto y se da enter, en cuanto aparece la

página resultante aparece un diálogo de Javascript con el texto "Hola".

En vez de poner ese Javascript tan sencillo se podría incluir un script mucho más largo y

complicado que hiciera otras cosas. La idea es que se está poniendo el texto que los usuarios

teclean, tal cual, en la página.

Para remediar esto hay distintas soluciones, que dependen de la tecnología. Los frameworks de

GUI que están construidos sobre JSP o JSF por lo general incluyen un tag, componente, elemento,

alguna sintaxis especial o algo para desplegar cadenas de texto en la página; casi siempre por

default escapan el HTML. Por ejemplo, con JSTL si usamos ${} para desplegar el resultado, no se

filtra el texto, pero si usamos <c:out> ese elemento por default escapa los caracteres

especiales de XML, a menos que se le indique escapeXml="false".

Ejemplo corregido con JSTL:<form action="xss2.jsp" method="POST">Escribe tu nombre: <input type="text" name="nombre"><input type="submit" value="Enviar" /></form><c:if test="${not empty param.nombre }">Hola, <c:out value="${param.nombre}" /></c:if>

El ejemplo original tiene una desventaja adicional: la forma no tiene el atributo method y eso

causa que por default se use GET, que consiste en incluir los datos de la forma en el URL destino.

Esto causa un problema de fuga de información ya que los datos viajan en el URL y se quedan en

el log del web server, son visibles en la barra de dirección del navegador, pasan tal cual por el

proxy quedando en su log, etc. El segundo ejemplo usa POST, que envía los datos de la forma

después del URL y los encabezados de HTTP, por lo que no son visibles en el URL, evitando estos

problemas (aunque siguen viajando sin protección alguna, pero es una protección de lo más

básico).

En Struts 2, el tag <s:property> también ya escapa el HTML en el texto que se le pase, a

menos que se le ponga escape="false".

En Tapestry 3 y 4 el componente Insert escapa el HTML del texto que despliega, a menos que

se le indique raw="true". En Tapestry 5, el componente Output funciona igual, es decir escapa

el HTML por default a menos que se le indique filter="false".

El tag <h:outputText> de JSF por default escapa el HTML a menos que se le indique lo

contrario con escape="false".

Sin embargo no deja de ser importante probar en sus aplicaciones web que no se pueda inyectar

código HTML directamente. Todos estos frameworks que acabo de mencionar, filtran el

XML/HTML al momento de desplegarlo, sin embargo no filtran los datos que se capturan. Por lo

tanto si un usuario inyecta código HTML, XML o Javascript en algún campo de texto, se puede

almacenar en la base de datos. Al tenerlo ahí guardado puede ser una bomba de tiempo porque

lo único que se necesita es que en el futuro alguien desarrolle una página donde por descuido se

despliegue un texto que venga de la base de datos y que contenga HTML/XML/JS para habilitar

un ataque de XSS. En algunos casos es mejor analizar el texto que los usuarios capturan y

filtrarlo de una vez, escapando los caracteres que puedan causar problemas y almacenar así la

información en la base de datos. Esto no siempre es posible o factible, pero es la mejor manera

de evitar estos ataques.

Anexo Nro. 1: NMap Scripting Engine

map 6.01 ( http://nmap.org )

Usage: nmap [Scan Type(s)] [Options] {target specification}

TARGET SPECIFICATION:

Can pass hostnames, IP addresses, networks, etc.

Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254

-iL <inputfilename>: Input from list of hosts/networks

-iR <num hosts>: Choose random targets

--exclude <host1[,host2][,host3],...>: Exclude hosts/networks

--excludefile <exclude_file>: Exclude list from file

HOST DISCOVERY:

-sL: List Scan - simply list targets to scan

-sn: Ping Scan - disable port scan

-Pn: Treat all hosts as online -- skip host discovery

-PS/PA/PU/PY[portlist]: TCP SYN/ACK, UDP or SCTP discovery to given ports

-PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes

-PO[protocol list]: IP Protocol Ping

-n/-R: Never do DNS resolution/Always resolve [default: sometimes]

--dns-servers <serv1[,serv2],...>: Specify custom DNS servers

--system-dns: Use OS's DNS resolver

--traceroute: Trace hop path to each host

SCAN TECHNIQUES:

-sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans

-sU: UDP Scan

-sN/sF/sX: TCP Null, FIN, and Xmas scans

--scanflags <flags>: Customize TCP scan flags

-sI <zombie host[:probeport]>: Idle scan

-sY/sZ: SCTP INIT/COOKIE-ECHO scans

-sO: IP protocol scan

-b <FTP relay host>: FTP bounce scan

PORT SPECIFICATION AND SCAN ORDER:

-p <port ranges>: Only scan specified ports

Ex: -p22; -p1-65535; -p U:53,111,137,T:21-25,80,139,8080,S:9

-F: Fast mode - Scan fewer ports than the default scan

-r: Scan ports consecutively - don't randomize

--top-ports <number>: Scan <number> most common ports

--port-ratio <ratio>: Scan ports more common than <ratio>

SERVICE/VERSION DETECTION:

-sV: Probe open ports to determine service/version info

--version-intensity <level>: Set from 0 (light) to 9 (try all probes)

--version-light: Limit to most likely probes (intensity 2)

--version-all: Try every single probe (intensity 9)

--version-trace: Show detailed version scan activity (for debugging)

SCRIPT SCAN:

-sC: equivalent to --script=default

--script=<Lua scripts>: <Lua scripts> is a comma separated list of

directories, script-files or script-categories

--script-args=<n1=v1,[n2=v2,...]>: provide arguments to scripts

--script-args-file=filename: provide NSE script args in a file

--script-trace: Show all data sent and received

--script-updatedb: Update the script database.

--script-help=<Lua scripts>: Show help about scripts.

<Lua scripts> is a comma separted list of script-files or

script-categories.

OS DETECTION:

-O: Enable OS detection

--osscan-limit: Limit OS detection to promising targets

--osscan-guess: Guess OS more aggressively

TIMING AND PERFORMANCE:

Options which take <time> are in seconds, or append 'ms' (milliseconds),

's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).

-T<0-5>: Set timing template (higher is faster)

--min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes

--min-parallelism/max-parallelism <numprobes>: Probe parallelization

--min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies

probe round trip time.

--max-retries <tries>: Caps number of port scan probe retransmissions.

--host-timeout <time>: Give up on target after this long

--scan-delay/--max-scan-delay <time>: Adjust delay between probes

--min-rate <number>: Send packets no slower than <number> per second

--max-rate <number>: Send packets no faster than <number> per second

FIREWALL/IDS EVASION AND SPOOFING:

-f; --mtu <val>: fragment packets (optionally w/given MTU)

-D <decoy1,decoy2[,ME],...>: Cloak a scan with decoys

-S <IP_Address>: Spoof source address

-e <iface>: Use specified interface

-g/--source-port <portnum>: Use given port number

--data-length <num>: Append random data to sent packets

--ip-options <options>: Send packets with specified ip options

--ttl <val>: Set IP time-to-live field

--spoof-mac <mac address/prefix/vendor name>: Spoof your MAC address

--badsum: Send packets with a bogus TCP/UDP/SCTP checksum

OUTPUT:

-oN/-oX/-oS/-oG <file>: Output scan in normal, XML, s|<rIpt kIddi3,

and Grepable format, respectively, to the given filename.

-oA <basename>: Output in the three major formats at once

-v: Increase verbosity level (use -vv or more for greater effect)

-d: Increase debugging level (use -dd or more for greater effect)

--reason: Display the reason a port is in a particular state

--open: Only show open (or possibly open) ports

--packet-trace: Show all packets sent and received

--iflist: Print host interfaces and routes (for debugging)

--log-errors: Log errors/warnings to the normal-format output file

--append-output: Append to rather than clobber specified output files

--resume <filename>: Resume an aborted scan

--stylesheet <path/URL>: XSL stylesheet to transform XML output to HTML

--webxml: Reference stylesheet from Nmap.Org for more portable XML

--no-stylesheet: Prevent associating of XSL stylesheet w/XML output

MISC:

-6: Enable IPv6 scanning

-A: Enable OS detection, version detection, script scanning, and traceroute

--datadir <dirname>: Specify custom Nmap data file location

--send-eth/--send-ip: Send using raw ethernet frames or IP packets

--privileged: Assume that the user is fully privileged

--unprivileged: Assume the user lacks raw socket privileges

-V: Print version number

-h: Print this help summary page.

EXAMPLES:

nmap -v -A scanme.nmap.org

nmap -v -sn 192.168.0.0/16 10.0.0.0/8

nmap -v -iR 10000 -Pn -p 80

SEE THE MAN PAGE (http://nmap.org/book/man.html) FOR MORE OPTIONS AND EXAMPLES

nmap: option requires an argument -- b