Doctor, si se me revuelven las tripas… (II): “Toma un poco de #OSINT con #OSRFramework”

Hola secuaces:

Siguiendo con mi curiosidad, con mi afán de saber quién es el ‘señor’ de mi entrada anterior, “Doctor, si se me revuelven las tripas… (I): “Toma un poco de #OSINT con #Tinfoleak””, y siguiendo con ganas de saber por dónde se mueve, voy a usar otra magnífica herramienta. Por supuesto, respetando toda privacidad, pues únicamente pretendo mostraros cómo funciona este framework.

Se trata de OSRFramework, (Open Sources Research Framework), desarrollada por Féix Brezo, (@febrezo) y Yaiza Rubio, (@yrubiosec), unos analistas de inteligencia, en el sector de las telecomunicaciones, que pertenecen al grupo de i3Visio.

Se trata de un framework para la investigación de usuarios en fuentes abiertas, capaz de buscar datos en 223 plataformas distintas, entre otras funcionalidades. No usa APIs de las plataformas, (salvo en Skype porque hay que darle permisos), si no que se basa en una aproximación de la url. Extrae la información de una forma automática. Y es de código abierto.

Vamos a proceder.

Primeramente, clonamos o descargamos la herramienta, con

git clone https://github.com/i3visio/osrframework.git

Si listamos el directorio, con

ls -l osrframework

Veremos que tiene un instalador. Instalamos la herramienta con

sudo python setup.py build

sudo python setup.py install

Ahora, si listamos el directorio ‘osrframework.egg-info’, observaremos que tiene unas dependencias.

ls -l osrframework.egg-info

Así que ingresamos al directorio y las instalamos, mediante

cd osrframework.egg-info

sudo pip install -r requires.txt

Ahora, si ingresamos en el segundo directorio de ‘osrframework’ y lo listamos, observaremos los módulos de la herramienta

cd home/marcos/osrframework/osrframework

ls -l

Para comenzar, podemos ejecutar el ‘osrfconsole.py’, para ver qué módulos están disponibles y qué hace cada uno de ellos

python osrfconsole.py

Pinta muy interesante, ¿verdad? Pero ahí no figuran todos. Veamos la ayuda de cada uno de ellos

python searchfy.py --help

Módulo que realiza búsquedas en plataformas, tanto de la web de superficie, como de redes anónimas.

domainfy.py --help

entify.py --help

Módulo al que se le pasan documentos o carpetas o una url para extraer entidades, (emails, hashes, urls, direcciones IPV4, DNI, …)

python enumeration.py --help

Módulo al que se le pasa una estructura de una url y que fuerza la búsqueda de los ‘id’ dentro del sitio y la descarga en local para consultarla offline, en formato ‘.html’. Se descarga toda la lista de usuarios que tiene el sitio.

mailfy.py --help

Módulo al que, dados unos nombres de usuarios, alias o direcciones de correo electrónico, verifica si existe esa cuenta de correo electrónico.

phonefy.py --help

Módulo al que, dado un número de teléfono, procede a su chequeo en listas de Spam.

usufy.py --help

Módulo al que se le introduce un alias, un usuario, o lista, y busca la información, relativa al perfil del mismo en diversas plataformas.

Bueno. Visto esto, es hora de ponerla en funcionamiento con el “voluntario” que teníamos en este perfil de Twitter.

Para ello, y conociendo un alias como conocemos, (antoniobanos_), vamos a llamar a ‘usufy.py’, con

usufy.py -n antoniobanos_ -p all

Esta línea nos devuelve algunos resultados.

Como considero que no me es suficiente, voy a usar otro módulo que no os he presentado antes. Se trata de un generador de Alias.

Este es un módulo al que se le introducen una serie de datos para que genere una lista de posibles alias.

Es realmente interesante. Como teníamos una bonita página en la Wikipedia de este ‘señor’, con algunos datos personales, me es más que suficiente para mostraros cómo trabaja este framework.

Así que, vamos a proceder a generar una lista de posibles alias, mediante

alias_genarator.py

Como podéis ver, es muy fácil de usar. Tras finalizar, se presenta la siguiente pantalla, que nos indica el número de alias posibles que se han generado.

¡Casi nada! 1656 nicks generados, en un fichero de texto con nombre ‘output’. Son demasiados, para mostraros el poder de este framework.

Esto podría tardar demasiado tiempo, en torno a 40 segundos por cada alias. Echad cuentas. No tengo ninguna prisa, pero hay que recortar esta lista. Recordáis que había un perfil en Twitter, ¿verdad? Pues vamos a hacer una cosilla.

Nos dirigimos al sitio de Twitter. Clicamos en “¿Olvidaste tu contraseña?”

Introducimos en alias en cuestión y le damos a buscar.

Y se nos presenta esta bonita pantalla.

¿Qué tenemos? Pues tenemos una dirección de correo, de un dominio que empieza por ‘Y’, seguido de cuatro caracteres, con un ‘.’, seguido de dos caracteres. Y un alias, que empieza por ab, seguido de cinco caracteres. Total… siete caracteres de un alias que comienza por ‘ab’.

Como el módulo de ‘alias_generator.py’ nos había generado 1656 posibles nicks,

wc -l /home/marcos/osrframework/osrframework/output.txt

Seleccionamos aquellos que comienzan por ‘ab’ y los copiamos a un nuevo fichero.

wc -l /home/marcos/osrframework/osrframework/ab

Siguen siendo demasiados. Vamos a hacer otra cosa. Los vamos a copiar a una tabla Excel y le vamos a aplicar una pequeña fórmula para ordenarlos por número de caracteres.

Recodáis que, según una cuenta de recuperación de correo electrónico, tenía un total de siete caracteres, comenzando por ‘ab’. Pues copiamos únicamente los posibles alias con siete caracteres a un nuevo fichero de texto.

wc -l /home/marcos/osrframework/osrframework/Alias-7.txt

Hemos pasado de 1656 posibles nicks, a 4. Casi nada.

Esto es un ejemplo de cómo funciona esta herramienta. Os muestro otros

python enumeration.py --u https://assemblea.cat

python enumeration.py --u https://cup.cat

entify.py --u https:// assemblea.cat

entify.py --u https:// cup.cat

mailfy.py -N Alias-7.txt

usufy.py -p all -l output.txt

searchfy.py -p all -q antoniobanos

Todos los resultados obtenidos, a excepción del módulo de ‘enumeration.py’, que se descargan en local, son exportados a un fichero en formato ‘profiles.csv’

ls -l | grep profiles.csv

file profiles.csv

wc -l profiles.csv

En mi caso, el fichero ‘profiles.csv’ creado, me ha generado un total de 627 resultados, matando algunos procesos. Y no os digo nada de los miles de resultados obtenidos de la enumeración.


NOTA: Los resultados obtenidos se basan en supuestos. Es decir, que hay que realizar una comprobación ‘manual’ de los datos obtenidos, intentando correlacionarlos entre sí, para determinar si pertenecen a la persona que se está ‘estudiando’.


Por último, de obligada lectura y obligado visionado:

#RetoISACA2015 – OSRFramework, un framework libre para la investigación de usuarios en fuentes abiertas

Taller de Félix Brezo Fernández y Yaiza Rubio Viñuela en Cybercamp 2015


Esto es todo, por ahora. Nos leemos en la siguiente entrada. Se despide este minion, entregado y leal, de vosotros… por ahora.


Marcos @_N4rr34n6_

En parvulitos de criptografía: pasatiempos para hackers nóveles

Hola compañeros,

Hoy compartimos con vosotros esta humilde entrada sobre las bases del cifrado, algo sencillo sin demasiada complicación y os proponemos un reto al final del artículo que deberéis saber solucionar con lo visto aquí...  ¡Pues bien, comenzamos!

La criptografía proviene de la palabra griega “kryptos” (oculto) y “graphein” (escribir), es decir, un tipo de escritura oculta. La criptografía es entonces un arte que ayudada por la ciencia se transforma en toda una potente herramienta para las comunicaciones ininteligibles entre dos puntos: emisor (cifra el mensaje) y receptor (descifra el mensaje para su lectura). A diferencia de los lenguajes que utilizamos día a día, si el mensaje es captado por terceros no deberían saber interpretarlo...

Los mensajes cifrados se usan desde tiempos inmemoriales para transferir mensajes sin que terceras personas puedan acertar lo que pone. Desde los egipcios utilizando jeroglíficos hasta los tiempos de la Roma Imperial de Julio César (100 aC – 44 aC). Éste usaba mensajes cifrados bajo un código que se ha denominado César en su nombre.

El famoso emperador romano utilizaba dicho código para escribir mensajes secretos sustituyendo las letras del mensaje original por la letra del alfabeto correspondiente a tres posiciones (desplazamiento) más allá. Es decir, la A sería sustituida por la D, la B por la E, la C por la F y así sucesivamente.

Así, un mesnaje como Obsequium amicos, veritas odium parit (en castellano “El servilismo produce amigos, la verdad odio”), podría escribirse cifrado bajo este código César como:

“Revhtxlxo dolfrv, yhulwdv rglxo sdulw”

Como ya sabemos que procede del cifrado mediante código César, descifrarlo nos resultaría fácil invirtiendo la permutación aplicando la regla vista anteriormente. Tan solo debemos sustituir cada letra por su correspondiente desplazándonos tres posiciones en el alfabeto. Podríamos crearnos una tabla para facilitar este trabajo, con las oportunas correspondencias.

Pero imagina que desconoces cual es el código bajo el que se cifra el mensaje, de primeras pensarías que un niño ha estado jugando con el teclado de tu ordenador o que tu mascota se ha paseado sobre el teclado... Sería difícil detectar que tras esas letras o símbolos sin sentido se esconde un mensaje oculto. Y más aun con los avances y complejos algoritmos de cifrado que existen en la actualidad.

Pues bien, esto es lo que usan las agencias de espionaje, ejercito, gobiernos, sistemas de cifrado, comunicaciones con embajadas, etc., pasándose información cifrada para que otros no puedan saber de que se trata, o al menos tarden en conseguir descifrar los mensajes.

En las guerras se suelen usar máquinas de cifrado para las ordenes y objetivos que se transmiten desde el mando al batallón, evitando que si el mensaje es interceptado por el enemigo, éste pueda saber cuales son las intenciones o que tarde en descifrarlo, para cuando ya se ha perpetrado el ataque.
Por ejemplo, el ejercito alemán utilizó una máquina de cifrado llamada Enigma para cifrar los mensajes, evitando que cualquier otro que no poseía los discos rotatorios de cifrado pudiese descubrir el mensaje oculto. Esto hizo que se desentrañase una de las primeras “batallas” criptográficas por descifrar mensajes, tanto de un bando como del otro.

CRIPTOANÁLISIS: ¿cómo descifrar mensajes?

El criptoanálisis es un método por el cual se van probando todas las permutaciones posibles en el texto cifrado hasta lograr captar lo que dice.
Cifrar mensajes empleando fuentes de texto como la Widing (que emplea símbolos en sustitución de las letras) en un editor de texto o los códigos de desplazamiento como los vistos anteriormente puede resultar un juego de niños para un analista criptográfico. Seguro que todos hemos hecho en algún momento algo así, o crear un tipo de fuente propia con un editor de fuentes para pasar mensajes ocultos con un amigo...

Pero los códigos de cifrado actuales hacen que se tengan que utilizar sofisticadas tecnologías para descifrar los mensajes. El método humano a seguir, suele constar de unos pasos relativamente sencillos, pero que requiere de paciencia e inteligencia para lograr descifrar el mensaje oculto. Los pasos son:

1. Contabilizar el número de veces que se repite una letra o símbolo en un mensaje cifrado.
2. Identificar cual o cuales se repiten mayor número de veces (frecuencia).  
3. Escribir el mensaje secreto dejando un espacio bajo él para ir escribiendo las posibles permutaciones.  
4. Ahora imaginemos que esas letras o símbolos que se repiten con mayor frecuencia son las letras más repetidas del idioma en el que está escrito el mensaje. Cada lengua tiene unas letras que se repiten con mayor frecuencia. Por ejemplo, en inglés la letra que más utiliza es la E, seguida de la T y luego la A. En castellano (si consultamos la “Frecuencia de aparición de letras” en la RAE) podemos apreciar como las más repeditdas son la E, seguida de la A y después la O. Si nuestro mensaje cifrado estuviese en inglés (date cuenta que varía en función del idioma), probaríamos a sustituir las letras o símbolos que más se repiten por estas letras para ver si el mensaje cobra algún sentido.  
5. Una vez hechas las estimaciones anteriores, debemos captar cual es el código bajo el que se cifra el mensaje o directamente completar el resto del texto.  
6. Luego podrás identificar como se ha cifrado el mensaje, es decir, qué patrón sigue para futuros descifres.  
7. 
   

Si tu presa o enemigo no se diese cuenta de que alguien lo ha logrado descifrar, tú podrás seguir captando los mensajes ocultos para chafarle sus planos o saber que pretende. Por eso, es una buena práctica, variar el código de cifrado a menudo para evitar este tipo de fallos de seguridad.

Caso práctico:

Imagina que has interceptado un mensaje cifrado y este pone algo así como:

 Fp hpa py wm ñmem op mw wmoa, wwmxmxp

Vamos a aplicar lo dicho en el primer punto, suponiendo que el mensaje lo han escrito compatriotas con el nivel de idiomas de Ana Botella, es decir, en castellano.
 
Para descifrar el mensaje, lo primero que debemos es contabilizar el número de veces que se repite cada carácter, tenemos que la M se repite 7 veces, luego la P se repite 5 veces, seguida de la W que se repite 5 veces. Si sabemos que el mensaje en un idioma determinado, castellano en nuestro caso, podemos probar a sustituir esas letras por las tres letras más repetidas de dicho idioma: E, A, O. Quedaría algo así:

Con la M=E: “Fp hpa py we ñeee op ew weoa, wwexexp”
Con la M=A: “Fp hpa py wa ñaea op aw waoa, wwaxaxp”
Con la M=O: “Fp hpa py wo ñoeo op ow wooa, wwoxoxp”
Con la P=E: “Fe hea ey wm ñmem oe mw wmoa, wwmxmxe”
Con la P=A: “Fa haa ay wm ñmem oa mw wmoa, wwmxmxa”
Con la P=O: “Fo hoa oy wm ñmem oo mw wmoa, wwmxmxo”
Con la W=E: “Fp hpa py em ñmem op me emoa, eemxmxp”
Con la W=A: “Fp hpa py am ñmem op ma amoa, aamxmxp”
Con la W=O: “Fp hpa py om ñmem op mo omoa, oomxmxp”

Pero estos mensajes no son nada legibles. Deberíamos seguir probando letras y combinaciones de varias para ver si el mensaje cobra algún sentido...  En castellano además existen sonidos como la “ll” o la “rr” o la “cc” que producen bigramas de letras seguidas repetidas. Este tipo de sonidos nos facilitan el descifrado, puesto que descartaría muchas posibilidades. Aplicando esto al mensaje cifrado, vemos como ww no tendría sentido que fuese ninguna vocal de las elegidas (E, A, O). Si volvemos a analizar la frecuencia de repetición de ciertas letras en castellano, tenemos que de las consonantes que integran esos tres bigramas vistos, el orden de frecuencia es R, seguida de L y luego C. Como CC y RR al inicio de una palabra no tiene sentido, nos quedaría LL por descarte. Así que ya sabemos que la W se corresponde con la L.

Esta pista nos ha abierto una brecha interesante hacia el descifrado. Ahora sabemos con total seguridad que W=L:

“Fp hpa py lm ñmem op ml lmoa, llmxmxp” 

Si con este nuevo mensaje repetimos las combinaciones anteriores, obtendremos esto (sin contar la W, ya que sabemos de qué letra se trata):

Con la M=E: “Fp hpa py le ñeee op el leoa, llexexp”
Con la M=A: “Fp hpa py la ñaea op al laoa, llaxaxp”
Con la M=O: “Fp hpa py lo ñoeo op ol looa, lloxoxp”
Con la P=E: “Fe hea ey lm ñmem oe ml lmoa, llmxmxe”
Con la P=A: “Fa haa ay lm ñmem oa ml lmoa, llmxmxa”
Con la P=O: “Fo hoa oy lm ñmem oo ml lmoa, llmxmxo”

Si analizamos el resultado, podemos ver datos curiosos. En el caso de M=E, aparecen sonidos posibles en castellano y con sentido (le, el, lle), igual ocurre con M=A (la, al, lla). No es así con M=O, que podríamos descartarla, puesto que “lo” si que existe, pero “ol” no. Así vamos reduciendo las posibilidades. Si intuimos que M puede ser o A o E, entonces se puede descargar que P sea una de estas dos letras. Recopilamos, si M puede ser A o E y W es L:

“Fp hpa py la ñaea op al laoa, llaxmxp” 
“Fp hpa py le ñeee op el leoa, llexexp” 

Ambos podrían ser válidos. Si nos fijamos en la X de la última palabra, debería de ser una consonante. Mirando la frecuencia de la RAE, vemos que las ocho consonantes más usadas son la S, R, N, D, L, C, T y M. Sustituyamos ahora X por estas a ver que nos aparece:

Si X=S “Fp hpa py la ñaea op al laoa, llasmsp”
“Fp hpa py le ñeee op el leoa, llesesp”
Si X=R “Fp hpa py la ñaea op al laoa, llarmrp”
“Fp hpa py le ñeee op el leoa, llererp”
Si X=N “Fp hpa py la ñaea op al laoa, llanmnp”
“Fp hpa py le ñeee op el leoa, llenenp”
…
...
...
Si X=M “Fp hpa py la ñaea op al laoa, llammmp”
“Fp hpa py le ñeee op el leoa, llememp”

Con ayuda de un diccionario, podemos buscar palabras tipo “llas-s-”, “lles-s-”, “llar-r-”, etc. Todas las combinaciones que nos han salido. Como vemos, se podría descartar X=S, X=R, X=D, evidentemente X=L (ya descubierta anteriormente), X=C y X=T. No existen ese tipo de palabras en castellano. Nos quedamos con la N y la M como posibles candidatas. Descartando más palabras que no tendrían sentido, parece que lo más posible es que X=M, ya que el diccionario nos aporta datos que autodescartan al resto de posibilidades.
Parece que ya tenemos una cosa clara, que M puede ser A o E y W es L, mientras que X parece ser M. Analizando esto matemáticamente para buscar alguna correlación, vemos la distancia que existen entre correspondencias:

De M a A =  13 (desplazamiento)
De M a E =  19 (desplazamiento)
De W a L= 15 (desplazamiento)
De X a M= 15 (desplazamiento)

Parece que el número que predomina es el 15, que se repite dos veces. Vamos a crear un abecedario con ese desplazamiento, comenzando por W=L:
W=L, X=M (esta también coincidiría), Y=N, Z=Ñ,...

Seguimos chicos, ya falta menos. En nuestro mensaje cifrado existe una Y, si la sustituimos por N veamos las consecuencias:

“Fp hpa pn la ñaea op al laoa, llamamp”

Delante de la N que hemos sustituido existen una P, si la sustituimos por alguna de las vocales más frecuentes podemos obtener nuevas pistas. Como A, I, O quedan descartadas (no existe an, in y on en castellano), solo nos queda P=E o P=U, pero lo más frecuente es que sea E:

“Fe hea en la ñaea oe al laoa, llamame”

Empieza a cobrar sentido, tenemos algo así como “#e #e# en la #a#a #e al la##, llamame”. ¿Qué letra podría preceder a la “e” el inicio? Podría ser la “L” (Le), la “M” (Me), la “S” (Se), la “D” (De)  o la “T” (Te). La L y la M ya están pilladas, así que la T sería lo más evidente, además coincide con el patrón de desplazamiento de 15 posiciones en el alfabeto.

“Te hea en la ñaea oe al laoa, llamame”

La siguiente palabra comienza por H cifrada, que si también sigue el patrón de 15 posiciones de desplazamiento, debería corresponder a la V:

“Te vea en la ñaea oe al laoa, llamame”

Las A cifradas ya no tienen sentido, puesto que hemos descubierto que la M correspondía a la A. Así que aplicando la regla del 15, tendríamos que A puede ser O (recuerda no sustituir las A ya decodificadas anteriormente):

“Te veo en la caea oe al laoa, llamame”

El mensaje se vuelve legible ahora, intuitivo para una persona. Siguiendo con la regla del 15, la E puede corresponderse a una S, la O a una S y la Ñ a D:

“Te veo en la casa de al lado, llamame.”

¡¡¡Ya hemos descubierto el mensaje cifrado!!! Compruebalo con la tabla de la imagen posterior...

Ahora te propongo un reto:

¿Eres capaz de descifrar esto? (deja un comentario si sabes la solución):

Qe issioixe kw qe qiilk

Te doy pistas: está en castellano... y a lo largo del artículo hay dos pistas más.

Fingerprinting II - Métodos HTTP

Buenas compañeros,

Esta es la segunda entrada de la serie de Fingerprinting, que habíamos dejado pausada tras la anécdota del chihuahua.

El objetivo de esta prueba, que viene marcada en OWASP, consiste en averiguar los métodos HTTP permitidos por el servidor web para comprobar si se encuentra habilitado alguno que no debería y de esta manera aprovecharlos para comprometer el sitio web.

Entre los métodos HTTP se tienen:

GET: El método más común en la navegación web. Devuelve un código de respuesta y las cabeceras asociadas. Incluye el documento solicitado (habitualmente una página) en el cuerpo del mensaje.

HEAD: Idéntico al anterior, con la salvedad de que no devuelve el documento en el cuerpo de la respuesta. Se utiliza para extraer información sobre el documento solicitado o comprobar si existe sin necesidad de enviar y recibir el documento como tal. A veces sirve para bypass controles que requieren de login si se encuentran mal configurados.

POST: Pensado para publicar la información contenida en el cuerpo de la petición en el recurso donde se envía esa petición. La información que se publica y la forma de hacerlo depende completamente del servidor y el recurso. Hoy, el uso que se le da a este método es el de paso de parámetros de cliente a servidor (en muchas ocasiones para ficheros). La respuesta por parte del servidor es la misma que para una petición GET. Es recomendable emplear este método en el envío de formularios que puedan contener información sensible para evitar que aparezcan en logs.

TRACE: Implementa la función de eco para los mensajes HTTP. El servidor responde en el cuerpo del mensaje con la misma petición que el cliente ha realizado. Se utiliza para comprobar que las peticiones son recibidas correctamente. Su finalidad es la de depuración.

OPTIONS: Este método presenta las opciones que el recurso o servidor dispone o requiere. De esto se puede obtener información como por ejemplo los métodos permitidos (en la cabecera ALLOW).

CONNECT: Utilizado para crear la comunicación con un proxy HTTP (SSL).

PUT: Mediante este método es posible almacenar el documento que se envía como cuerpo de la petición en el propio servidor (físicamente en disco). Si el recurso al que se hace referencia en la petición no existe se creará y si existe se sobrescribirá, es decir, para subir ficheros.

DELETE: Al igual que el método PUT, este verbo afecta directamente al recurso al que se hace la petición. Tiene la capacidad de eliminar el elemento y dejar al servidor sin ese recurso.

Tras ver la teoría vamos a la práctica! Para estas prácticas se puede emplear el terminal de Linux con netcat pero este caso vamos a emplear Burpsuite:

OPTIONS

Devuelve información del servidor respecto a los métodos permitidos.

La imagen anterior muestra una correcta configuración, mientras que en la siguiente no sería así:

No fiarse de esta información pues no es ni completa ni veraz. En ocasiones indica que se permite pero luego no está implementado el método.

Y en otras ocasiones ocurrirá lo contrario, la cabecera ALLOW de la petición OPTIONS no mostrará métodos que realmente están permitidos e implementados... aunque luego es posible su ejecución. En resumen, no se deben descartar los métodos que no estén reflejados en esa cabecera.

Es buena práctica comprobar la respuesta del servidor ante cabeceras inexistentes:

Los método más peligrosos son PUT y DELETE pero también destaca TRACE que posibilita posible robo de cookies.

TRACE

En este método se podría incluir un parámetro asociado a un valor, por ejemplo, una cookie de tal manera que, este método devuelve como cuerpo las cabeceras de la petición del cliente, incluyendo la cabecera.

La combinación de este método HTTP con un fallo "Cross Site Scripting" en la aplicación web puede acabar en un robo de sesión de usuario, incluso si las Cookies han sido establecidas como HttpOnly. Este ataque es conocido como "Cross Site Tracing" o XST.


Para más información os recomiendo el siguiente enlace de "el lado del mal":

http://www.elladodelmal.com/2011/11/hijacking-de-cookies-http-only-con-xss.html

PUT

Se intenta subir un fichero:

curl  -T test.txt www.ejemplo.es

Es posible que devuelva un error 417 Expectation Failed.

Entonces se incluye la cabecera Expect:

curl -H Expect: -T test txt www.ejemplo.es

Si se quiere usar Burpsuite, sería:

PUT /test.txt HTTP/1.1

Host: ejemplo.es

 TEST

El uso de este método (así como DELETE) es muy intrusivo por lo que como somos "éticos" no se demuestra su uso mediante PoC, solamente el resultado cuando se encuentra correctamente configurado.

Análogamente, la FOCA identifica la presencia de métodos habilitados en su scan, por lo que se recomienda su uso para no olvidarnos ninguno.

El objetivo de esta entrada es totalmente con fines educativos y formativos, por lo tanto, no nos hacemos responsables de uso para otros fines distintos.

Saludos.

NaxHack5

La mejor defensa es un buen ataque.

[RETO] Noticia importante en FWHIBBIT

Hola a todos!

Tenemos algo muy importante que comunicar, pero obviamente, no os lo íbamos a poner tan fácil, es por ello, que hemos desarrollado un reto (bastante sencillo), para que averigüéis el "secreto".

El Martes daremos la solución, no obstante, si consigues terminarlo, podrás conocerlo hoy mismo.

Si lo consigues, nos gustaría que nos avisaras por twitter y/o facebook (obviamente por privado :P), además, estad atentos pues iremos dejando pistas!

Reto: 

SOLDADO! No sabemos que ha ocurrido, pero el pelotón que se dirija a Cybercamp nos ha enviado esta URL, no sabemos que secretos guarda en su interior, pero estamos seguros de que el futuro de la nación depende de ti! AYÚDANOS!


http://137.74.44.236:8080/

Mucha suerte a todos y gracias por participar!

Análisis básico de ficheros PCAP

Hola chicos!! Como tal vez sabréis, unos cuantos autores el blog estamos participando en el curso online de hacking ético organizado por Mondragon Unibersitatea.

Aunque es un curso de nivel básico, sirve para cubrir algunos aspectos fundamentales en el proceso del pentesting, y estamos disfrutándolo a tope. Además, la última parte, en la que estamos ya metidos de lleno, consiste en un wargame en el que los equipos securizan un servidor y posteriormente tratan de atacar los del resto. ¡Promete!

Este ejercicio que os traigo hoy está sacado del propio curso. Dado que de momento por aquí no hemos tocado demasiado el tema de análisis de ficheros pcap, que contienen los paquetes recogidos en una captura, me parece muy interesante presentároslo.

Os dejo aquí el proceso con explicaciones y cada uno de los ficheros que necesitáis para los ejercicios. Enjoy!!

Primera parte: analizando un protocolo inseguro - Telnet

Fichero de la escucha 

A partir de una captura de paquetes de red recogida en un archivo .pcap realizaremos un análisis de las operaciones realizadas mediante el protocolo Telnet. Este protocolo, al carecer de cifrado, permite que la escucha de red revele todo lo intercambiado en la conexión. 

Podemos abrir el fichero con cualquier analizador de paquetes, como puede ser Wireshark, el cual utilizaremos. 

Lectura del fichero con Wireshark

Como puede verse en la imagen, es muy fácil filtrar el protocolo a mostrar escribiendo simplemente telnet en el campo de filtros del programa.

Podemos ver en texto plano en los campos de análisis de cada paquete los datos intercambiados entre los dos hosts, desplegando la pestaña Telnet. Podemos responder asíl fácilmente a varias preguntas:

• ¿Qué usuario y contraseña se ha utilizado para acceder al servidor de Telnet?
• El usuario es fake, y la contraseña user. 
• ¿Qué sistema operativo corre en la máquina?
• Utiliza un OpenBSD 2.6-beta.
• ¿Qué comandos se ejecutan en esta sesión?
• Se ejecutaron cuatro comandos en la sesión:

ls

ls -a

/sbin/ping www.yahoo.com
(ctrl-c)

exit

Segunda parte: analizando SSL

Fichero de la escucha

En la siguiente parte, realizaremos un análisis muy similar con una traza que ha recogido una sesión SSH. A diferencia de Telnet, el protocolo SSH realiza un cifrado de la conexión, de forma que hace imposible que apreciemos a primera vista los datos que se intercambian. 

Lectura del fichero con Wireshark (2)

Aunque no podemos discernir las operaciones realizadas en la sesión, podemos responder a algunas preguntas: 

• ¿Puedes identificar en qué paquete de la trama el servidor envía el certificado?
• Sí. Los certificados se envían en los paquetes enviados por el servidor y que contienen la información marcada como Certificate. Si abrimos dicha información, se puede ver el certificado. 

Certificado encontrado en la sesión

• ¿El certificado va en claro o está cifrado? ¿Puedes ver, por ejemplo, qué autoridad ha emitido el certificado?
• Para que el cliente pueda ver el certificado antes de realizar una conexión completa mediante SSH y así verificar la identidad del servidor a priori, el certificado se envía en plano, sin cifrar. 

Información del certificado en Wireshark

• Si queremos ver la información algo más clara, podemos exportar el certificado clicando con el botón derecho en la pestaña del certificado y en Export Packet Bytes..., para entonces guardarlo como un fichero .der. Podemos ver este certificado entonces haciendo doble clic sobre él. Entre otras cosas, podemos ver los datos acerca de la autoridad de certificación. 

Visualización de datos del certificado

• ¿Qué asegura el certificado, la identidad del servidor o del cliente?
• El certificado asegura la identidad del servidor. 

Tercera parte: analizando SSH

Fichero de la escucha

Por último para esta tarea, analizaremos otra captura del protocolo SSH para responder a otra serie de preguntas respecto a la misma. 

• ¿Puedes ver a partir de qué paquete comienza el tráfico cifrado?
• Sí. Aunque en la captura solamente se muestran los paquetes enviados desde el lado cliente, puede apreciarse que el tráfico cifrado comienza en el paquete marcado como 13, después de haber intercambiado las claves. 

Primer paquete cifrado de la sesión

• ¿Qué protocolos viajan cifrados, todos (IP, TCP...) o alguno en particular?
• Algunos protocolos viajan cifrados, otros no. Tanto TCP como IP son protocolos de capas inferiores a la de aplicación, la cual es la que suele ofrecer funciones de cifrado. Por ejemplo, el protocolo FTP viaja sobre TCP/IP, pero no está cifrado; su derivado seguro, FTPS, también viaja sobre TCP/IP, pero está cifrado.
• ¿Es posible ver alguna información de usuario como contraseñas de acceso?
• No es posible (al menos de forma matemáticamente rentable) recuperar ningún tipo de dato de la sesión una vez pactadas las claves de cifrado. 

Hasta aquí el ejercicio, hackers. Espero que os sirva para practicar un poco y disfrutar!!