Kernel Security

nmap : «Key Exchange (dh 1024) of lower strength than certificate key»

Publicado el 29 mayo, 2017 por kernel

Holas!

Quería compartir una vulnerabilidad que Nessus de momento pasa por alto. Por poner en contexto, cuando en un servidor ssl/tls remoto se identifica DES/3DES, se marca como vulnerable a “sweet32”, igual pasa con RC4 “Bar mitzvah”. (nessus way)

Bien, nmap añadió hace no mucho una comprobación en su script –ssl-enum-ciphers que nos muestra el siguiente warning (comprobar en captura adjunta):

“Key Exchange (dh 1024) of lower strength than certificate key”

Qué quiere decir esto? Nmap a través del script le muestra al servidor remoto todos las modalidades de DH (“Diffie-Hellmann”) que podría aceptar, y de todas ellas, ha escogido la más débil (1024). Teniendo en cuenta que el certificado en este caso tiene una clave RSA de 2048 bits, la solución global está negociando una conexión más débil de que podría.

A qué se debe y qué solución tiene?

Esta vulnerabilidad se debe a que en este caso el servidor auditado es un Nginx (aunque da igual con Apache también), ambos confían en OpenSSL instalado en la máquina GNU\Linux para gestionar la criptografía de los servidores web. Y OpenSSL, por defecto, negocia DH a 1024, por lo que para solucionarlo debemos regenerar parámetros DHE de mayor fortaleza:

cd /etc/ssl/certs
openssl dhparam –out dhparam.pem 4096
Posteriormente, es necesario instar a Nginx a que use esta nueva configuración a través de la siguiente directiva en /etc/nginx/nginx.conf:
ssl_dhparam /etc/ssl/certs/dhparam.pem;

Publicado en Seguridad Informática | Deja un comentario

nmap NSE 99,99%

Publicado el 23 marzo, 2017 por kernel

Demasiado tiempo sin escribir una entrada en el blog, aunque me gustaría y de vez en cuando tengo ideas pero el día a día nos come a todos, aunque esta entrada me parecía breve e interesante. Seguramente os habrá ocurrido que escaneando un target con los scripts de nmap se os cuelga en el 99,99% y no termina nunca, por lo que al final pierdes el output de esos scripts que buscabas.

También puede ocurrir que el porcentaje que inicialmente nos marca cambia, y del 85% pase al 64% por ejemplo, como se puede observar en la siguiente captura:

Esto es debido a que nmap actualmente muestra el tiempo basado en el número de threads completado vs comenzados, debido a esto y a la naturaleza de los scripts y puertos sobre los que se están lanzando, es posible que un thread abra otro thread y así sucesivamente por diseño, por lo que es difícil para nmap ofrecernos cuánto tiempo tardará el escaneo completo en terminar.

Esto podría solucionarse en cierta medida si se mostrara un contador para el número de «spawned threads» y basado en el número estimado de conexiones que hará el script, por lo que nmap podría hacer una estimación algo más acorde. Hablando con la gente envuelta en las pull request en freenode, resulta que hay una de hace pocos días sobre esto mismo, por lo que quizás en no mucho tiempo podríamos ver una mejora en nmap de estas características, y de paso, me he ahorrado abrir yo mismo el thread o duplicar info en la mailing list.

En cualquier caso y retomando el tema inicial del «cuelgue» de nmap en 99,99% lanzando NSE, existe un parámetro –script-timeout que se puede pasar por linea de comandos con valor –script-timeout=40m si ese es el tiempo estimado que tarda nmap en llegar hasta ese punto para que, una vez ahí, «mate» el hilo que se ha quedado colgado, pero mostrando toda la información restante de los demás scripts.

Un saludo!

Publicado en Seguridad Informática | Deja un comentario

Análisis global sobre el fraude en las Telecomunicaciones

Publicado el 6 abril, 2015 por kernel

Esta publicación es un análisis global sobre fraude en las comunicaciones que realiza la Communications Fraud Control Association o CFCA.

La CFCA comenzó en Febrero de 1985 en Roseland, New Jersey (EEUU) como un grupo de profesionales de la seguridad concienciados sobre el fraude en las telecomunicaciones, intentando encontrar una manera más eficiente de combatirlo, en el que había representantes de AT&T, ITT, MCI o Network One entre otras.

El alcance de esta asociación tuvo como consecuencia la expansión e inclusión de ISP´s, proveedores de cable y satelitales, desarrolladores de sistemas contra el fraude, proveedores de VoIP, miembros de los cuerpos y fuerzas de seguridad del estado, consultores, etc, contando actualmente con más de 200 corporaciones que aúnan esfuerzos y elaboran informes acerca del estado del fraude, así como nuevas tendencias cibercriminales en todo el mundo.

Desde 2009 y cada dos años, elaboran una estudio entre los miembros de la asociación para la elaboración de estadísticas, y de ellas se puede sacar mucha información concluyente a ser analizada por todas aquellas compañías / organizaciones que necesitan y prestan servicios de seguridad de la información, como es el caso de Secure&IT.

De entre todas las organizaciones y corporaciones consultadas, se han obtenido resultados de 93 ISP´s alrededor de todo el mundo, de menos de 1.000 empleados a organizaciones de mas de 100 mil, incluyendo proveedores de Wireless, banda ancha, voz, datos o servicios financieros, localizados en las siguientes regiones:

Las informaciones arrojadas a la luz por esta asociación son muy a tener en cuenta, teniendo como puntos fuertes los siguientes datos:

En 2013, año de la realización del último estudio, se estima que el fraude en las telecomunicaciones alrededor del mundo se encuentra en 46.3B$, incrementándose en un 15% desde el último estudio en 2011 debido a la cada vez mayor implementación de entornos Wireless.
De los organismos consultados, el 94% creen que la pérdida global por fraude se ha incrementado o es la misma desde 2011, por tan solo el 4% que afirma que se ha reducido desde el último estudio.

Un dato a tener en cuenta entre todas las organizaciones, es cuánta gente está especializada en organizaciones para la lucha contra el fraude y qué personas se encargan de ellos, siendo estos los resultados:

Comparando los resultados con el estudio de 2011, el crecimiento de los departamentos de fraude ha crecido un 2% desde entonces. Sin embargo, las grandes compañías han reducido sus puestos de Analistas de Fraude en un 5% debido a la crisis económica, con numerosas compañías que informaron que solo una persona se encargaba de este tipo de análisis.

Otro dato interesante, y ya son varios, radica en conocer qué volumen de incidentes analizan las organizaciones al mes por regiones, con el que podemos ver en los siguientes gráficos, mensualmente y globalmente al año:

De lo anterior se desprende además, que de media, los departamentos de fraude reportaron un 117% más casos por mes desde 2011, sobre todo en América del Norte y Europa Occidental.

Otro dato curioso es conocer, de todo ese volumen de fraude, cuánto es puesto en conocimiento de las autoridades competentes, el cual solo alcanza el 11%.

Finalmente, los siguientes datos se organizan por tipo y método de fraude:

Vamos a intentar desgranar en qué consisten algunos de los métodos de fraude anteriormente listados, como por ejemplo el fraude en la subscripción , con un total de 5.22 B$, consistente en dar de alta servicios con nombres falsos o identidades inexistentes, cuyas facturas nunca serán abonadas y que suelen ser dados de baja a los pocos meses de la actividad.

En segundo lugar tenemos PBX Hacking, con un fraude que ascendería hasta los 4.42 B$. Sus ataques consisten en abusar de dispositivos SIP y centralitas que se encuentran accesibles en Internet para todo el público y que no han sido debidamente filtrados sus accesos, siendo un blanco fácil de scanners automáticos que hacen todo el trabajo: buscan, comprometen servicios / accesos, notifican a los cibercriminales, y a partir de aquí, llamadas a números Premium contratadas por los propios delincuentes, llamadas de larga distancia, SPAM telefónico, etc.

Hay que mencionar que no solamente se pueden realizar estafas como las mencionadas, sino que los atacantes podrían incluso, monitorizar el tráfico de manera pasiva y analizar los ficheros de audios, extrayendo las conversaciones en caso de que no exista cifrado en la señalización, transporte, o ambos, tonos DTMF , que son los sonidos que generan los terminales cuando pulsamos los números del 1-9, abriendo una ventana adicional en la que información sensible se podría extraer de la interacción de los usuarios con locuciones ( IVR´s de compañías telefónicas, banca, etc. )

Un término interesante que seguro los lectores pueden haberse preguntado de la anterior lista se denomina “Wangiri”, que se originó en Japón y que más de uno podría haber colaborado inadvertidamente. Wangiri significa “One ring and cut”, y se trata de realizar llamadas masivas a números aleatorios, donde el usuario que recibe la llamada, la “devuelve”, con la típica frase “Hola, tengo una llamada perdida suya…”.

Normalmente, este fraude no implica llamadas de larga duración, ya que el usuario por lo general corta la llamada a los pocos segundos, por lo que el impacto sobre una sola persona puede no ser muy alto, pero si sumamos cientos de personas, hace que el enriquecimiento ilegal aumente, y teniendo en cuenta que poca gente llevará el caso a manos de la Justicia cuando le llegue un recargo adicional de pocos céntimos o euros, parece una alternativa interesante unida a otras técnicas de fraude que pueden ir sumando ganancias.

Como podemos observar, los datos son abrumadores, las compañías y organizaciones tienen la necesidad imperante de securizar sus sistemas empleando el método de Defensa en Profundidad, comenzando desde la educación, pasando por electrónica de red, aplicaciones y metodologías redundantes que permitan una mayor visión de lo que está sucediendo, siendo la única manera de frenar esta tendencia y poder tomar acciones preventivas, proactivas y reactivas en última instancia.

Publicado en Seguridad Informática | Deja un comentario

ShellShock Reverse Exploit PoC

Publicado el 29 septiembre, 2014 por kernel

Hi ! long time since my last post over here, I´ve been busy, but here it is :

Stephane Chazelas discovered a vulnerability related in how environment variables are managed by bash, so if you are able to find a vuln server, like google dorking with some like google:filetype:cgi inurl:cgi-bin, you could easily get shell, escalate privileges, data exfiltration and so on.

There are already a lot of scripts scanning the whole Internet looking for this kind of vuln to get involved in DoS/DDoS attacks, botnet inclusion perl scripts, etc.

His official CVE is CVE-2014-7261, although in the past few days, three vulns have been discovered too, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187 y CVE-2014-6277, last by Michael Zalewski, who have not yet disclosed any technical info about it, so be careful.

All these patches have caused developers to write some specific patches that you´re able to download via apt-get on Debian based distros, or yum/yast, OpenBSD, NetBSD and FreeBSD have developed specific C patches in order to avoid this bash enviromental behaviour, but most of sysadmins have to wait bash devs to release subsequent patches.

Solution is easy… keep up to date

To check if your server is vuln, you can carry out these following steps:

– apt-get install git
– git clone https://github.com/hannob/bashcheck/
– cd bashcheck
– ./bashcheck

Also, you can take a deep look at this URL too:

https://github.com/mubix/shellshocker-pocs

For a PoC, I´ve tested pentesterlab vuln iso that you can download right here, and a NSE script for NMAP :)

http://seclists.org/nmap-dev/2014/q3/493

Vuln VM looks like this when running:

What bad guys are doing is to inject bash scripts in parameters like Header, User-Agent, referer… etc, download rootkits and whatever you want.. its a shell :)

So for the PoC, I simply run a revshell to demonstrate how dangerous this exploitation could be, although this kind of vulnerabilities are well known, and you can do some research and training in exploit-exercises.com.

When a tcp port is listening, and wondering if netcat could not be available in target, we can create a tcp socket and send it to our attacker machine that way:

So, our tcp socket is being generated and in a few seconds we can see some like that :

Publicado en Sin categoría | Deja un comentario

Nebula level10 – Exploiting access() syscall TOCTOU Race Condition

Publicado el 6 junio, 2013 por kernel

In this level, they provide the following C source code:

#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>

int main(int argc, char **argv)
{
char *file;
char *host;

if(argc < 3) {
printf("%s file host\n\tsends file to host if you have access to it\n", argv[0]);
exit(1);
}

file = argv[1];
host = argv[2];

if(access(argv[1], R_OK) == 0) {
int fd;
int ffd;
int rc;
struct sockaddr_in sin;
char buffer[4096];

printf("Connecting to %s:18211 .. ", host); fflush(stdout);

fd = socket(AF_INET, SOCK_STREAM, 0);

memset(&amp;amp;amp;amp;sin, 0, sizeof(struct sockaddr_in));
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = inet_addr(host);
sin.sin_port = htons(18211);

if(connect(fd, (void *)&amp;amp;amp;amp;sin, sizeof(struct sockaddr_in)) == -1) {
printf("Unable to connect to host %s\n", host);
exit(EXIT_FAILURE);
}

#define HITHERE ".oO Oo.\n"
if(write(fd, HITHERE, strlen(HITHERE)) == -1) {
printf("Unable to write banner to host %s\n", host);
exit(EXIT_FAILURE);
}
#undef HITHERE

printf("Connected!\nSending file .. "); fflush(stdout);

ffd = open(file, O_RDONLY);
if(ffd == -1) {
printf("Damn. Unable to open file\n");
exit(EXIT_FAILURE);
}

rc = read(ffd, buffer, sizeof(buffer));
if(rc == -1) {
printf("Unable to read from file: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}

write(fd, buffer, rc);

printf("wrote file!\n");

} else {
printf("You don't have access to %s\n", file);
}
}

This binary takes a file and send it to a specified host on 18211 tcp port ( if you have the right privileges to do so )

First I did was use some static source code analizer, flawfinder, to see where is the vuln, although nebula guys give us a clue :

«The setuid binary at /home/flag10/flag10 binary will upload any file given, as long as it meets the requirements of the access() system call. »

That´s what flawfinder shows:

«level10.c:24: [4] (race) access: This usually indicates a security flaw. If an attacker can change anything along the path between the call to access() and the file’s actual use (e.g., by moving files), the attacker can exploit the race condition. Set up the correct permissions (e.g., using setuid()) and try to open the file directly.

After a bit research through these links [1],[2],[3] and a lot more research, tried a lot more several times and being stuck for many hours, I concluded that TOCTOU ( Time of Check Time of Use ) security flaw attack it´s like if you tell to your friend :

– Hey, take that xbox360, and before you pick up the xbox i´ve changed it by another, and of course you play the xbox that I want ( probably three red circles one ) :P

Problem here arises with the «timing» between system calls ( executed by a setuid binary ), access and open the file given, because the file might be removed or symlinked to another, and this is due of accessing files using filnenames rather than file handlers and file descriptors.

To resolve that level, i had to open a different terminal with a netcat loop trying to get data on port 18211. You´ve to do a netcat loop because the program closes the connection after each upload attempt,that´s how :

Second script as follows :

Trying to run this scenario ( but without & parameter ), i coudn´t get the expected content of /home/flag10/token echoed over netcat, but putting any command in background mode ( & ) made the process ID of that command to decrease, and in this moment, we have a tiny window between the mentioned opening & accesing calls that we want to interfere, and we´re able to access the content of /home/flag10/token symlinked to /tmp/race.

Let´s see how it works:

We can see a lot of attempts with garbage but often it clrearly shows the content of /home/flag10/token file we coudn´t see before ( because it´s owned by flag10 user ) :D, then log in with flag10 user and use that token as password to execute getflag.

Publicado en Privilege Escalation | Deja un comentario

Nebula level 09 – Exploiting preg_replace in PHP

Publicado el 30 mayo, 2013 por kernel

preg_replace is a PHP function that uses PCRE, deprecated in PHP version 5.5.0 ( yo should use preg_replace_callback instead), its main goal is, as its name suggests, string replacement, let´s see an example :

<?php
$string = ' Ugly level';

$pattern[0] = '/Ugly/';
$pattern[1] = '/level/';

$replacement[0] = 'Tricky';
$replacement[1] = 'function';

echo preg_replace($pattern, $replacement, $string);>

Output will be «Tricky function»

Problem arises when using «e» modifier, which allow us to use native PHP functions in replace parameters, like the example in this level,


function spam($email)
{
$email = preg_replace("/\./", " dot ", $email);
$email = preg_replace("/@/", " AT ", $email);

return $email;
}

function markup($filename, $use_me)

{
$contents = file_get_contents($filename);

$contents = preg_replace("/(\[email (.*)\])/e", "spam(\"\\2\")", $contents);
$contents = preg_replace("/\[/", "<", $contents);
$contents = preg_replace("/\]/", ">", $contents);

return $contents;
}

$output = markup($argv[1], $argv[2]);

print $output;

Let´s see how it works, we have set up a file in /tmp that contains 2 lines that will produce two different behaviors within the vuln function of this level, I´ve to say I had to read so many documentation regarding this, but that´s the main reason why i started these challenges, +1PHP,+1PRIVESC+1PCRE,-1preg_repplace,so funny!

First red box shows a /tmp/file we´re passing through the PHP sink function , second box shows id executed from flag09 user, that we want to escalate in, and third red box shows normal behavior of the program, note that flag09.php is executed by a binary that flag09 owns, as you can see in the above picture too.

«There’s a C setuid wrapper for some vulnerable PHP code…»

So if we are able to execute code, it will be under flag09 privileges

For last, I´ve to say I would be caught this time if some admin implemented the method I described in my last post about fsnoop

Publicado en Privilege Escalation | Deja un comentario

Easy monitoring bad guys in GNU\ Linux Servers with fsnoop

Publicado el 23 mayo, 2013 por kernel

In this post I´m going to show an interesting tool for monitoring file access in GNU\Linux. It can be tricky for identifying unauthorized access to Web Servers, if all previous measures have been defeated, but in fact, we can use fsnoop in our daily tasks and not exclusively for security reasons.

Previous example pic shows how www-data, Apache user by default, has created 3 files in /dev/shm, likely after exploiting some RFI or SQLi, the attacker wants to escalate privileges, and /tmp ( aka /dev/shm ) is the first place where bad guys will try to execute code because is worl-readable in most systems.

That way, we can run fsnoop with -d ( daemon ) and -o ( output to a log ) in any path, and check with a shell script & crontab if the log is growing under certain users, then use sendmail to send alerts and take some decissions about.

We can download fsnoop from its main web page and see other useful examples

http://vladz.devzero.fr/fsnoop.php

Publicado en Privilege Escalation | 3 comentarios

WPA/WPA2 WPS design flaws, easy way Part II

Publicado el 12 marzo, 2013 por kernel

As described in the previous post [ I ], WPS has several flaws in it´s design, and I´ll try to explain them in this post, prior to just going for catching the WPA key only. The first flaw arises in how the procotol handles external registrars.

There is some functionalities that enables a client to connect via WPS, like phisical push button, or web interface. But some devices enables external registrars to connect only if they know the PIN,without any kind of authentication, allowing attackers to launch bruteforcing attacks in order to retrieve the correct PIN.

Let´s look again at the picture shown in the last post

Methods enabled for connecting to WPS, Ethernet ( web configuration access ), Label ( only ESSID, Encryption type and pass ) and PBC ( Push-Button-to-Connect).

We can see too how it´s disabled Physical Push Button in this device, and it´s a virtual one you have to push from the Web Configuration page. The other method is as I said before, to bruteforcing the PIN and get the key, that´s the first design flaw.

How WPS handles PIN code?

The method implemented by WPS for PIN auth has been described in the first post [ I ] so we can make a recap based on Stefan Viehböck resesearch :

An attacker can extract useful info from his bruteforce attack ( 8 digits )

If the attacker receives an EAP-NACK after sending M4, 1st half of PIN is incorrect.
If the attacker receives an EAP-NACK after sending M6, 2nd half of PIN is incorrect

This method, which only takes a few digits and is capable of sending valuable info to the attacker, decreases the maximum possible attempts to be made:

from 10^8 ( 100.000.000 ) to 10^4 + 10^4 ( 20.000 )
the final digit is a checksum of the seven previous, so 10^4 + 10^3 = 11.000 attempts

Next step in order to know the whole process is to understand how the PIN code is generated. Assuming the device follows Wi-Fi Alliance specifications, it will be 7 characters and a checksum of the seven previous:

Get BSSID = 5C:33:8E | FF:1E:FC

Take 2nd part of the BSSID, convert to decimal and apply a math funcion to extract checksum
Calculate the checksum and append to the end of final PIN.

Validate checksum C function

Compute checksum C function

These functions have been extracted from Windows Connect Now–NET, :) although his last version was about 2006 and Microsoft now urges to follow WiFi-Alliance specs. Ok so now we are going to show an Android App that shows WPS PIN directly on the screen, you can download it from Play Store for free.

And now a PIC of the process that the app follows to show us that PIN using Python interactively for better understanding:

Ready for recovering the WPA2 key ?

Publicado en Wireless Hacking | Etiquetado Wireless Hacking | Deja un comentario

WPA/WPA2 WPS design flaws, easy way Part I

Publicado el 5 marzo, 2013 por kernel

Hi folks! in this post series I´ll try to analyze the entire process about how to retrieve WPA/WPA2 key when bruteforcing PSK was not successfull or takes a long long time. Attack surface arose in December 2011 when Tactical Network Solutions released a whitepaper describing a WPS related issue that allows an attacker to retrieve WPA/WPA 2 passphrase without the needing of getting wpa handshake, deauth a client and so son.

With this attack, we can get the pass in few hours ( 4,10,15.. ) instead of many years that bruteforcing PSK technique would take, so let´s start talking a bit about WPS implementation.

Taking a look at the documentation that Wi-Fi Alliance provides:

«The primary goal of Wi-Fi Protected Setup is to simplify the security setup and management of Wi-Fi
networks. The goal of this specification is to provide users with the assurance that their wireless
networks are protected against unauthorized access and disclosure of private information.»

In summary, WPS was introduced in AP devices to facilitate the deployment of WiFi «protected» networks without the knowledge of any parameter, except PIN ( 8 chars ) in the back of the device. I will discuss PIN code generation in the second part of this analisys.

AP: An infrastructure-mode 802.11 Access Point and monitoring 802.11 probe request and EAP messages from Enrollees.
Registrar: An entity with the authority to issue and revoke Domain Credentials. A Registrar may
be integrated into an AP, or it may be separate from the AP. A Registrar may not have WLAN
capability. A given Domain may have multiple Registrars and processing enrollee.It handles probing messages and configuring AP with Enrollee MAC address.
Enrollee: A device seeking to join a WLAN Domain. Once an Enrollee obtains a valid
credential, it becomes a Member.

If we move forward to the WiFi Alliance specifications on WPS protocol, we find this :

«The Wi-Fi Protected Setup in-band Registration protocol is designed to provide strong protection against
passive eavesdropping attacks and also to detect and to protect the system from an attempt to perform an
active brute force attack.»

and a more interesting paragraph…

«Users who want strong security should be encouraged to purchase products that support the higher-security Wi-Fi Protected Setup options.»

Or what is the same as saying … «Buy the most expensive device if you want a lockdown policy»

The next section shows message exchange between new Registrar and AP, and attack will be done when we get the PIN and thereby we are able to establish a new authenticated wireless connection, ( M8 ) :

Knowing that info, start sniffing on monitor mode interface, run reaver ( discussed later ) tool and wireshark at each stage to find some useful and interesting info about the remote AP, like the following in the Diffie-Hellman key exchange involving M1 and M2:

EAP Request, Expanded type, WPS, M1

As we can see, we can retrieve manufacturer, model name, WPS Configured (0x02 ), different security procotols handled by such device and wps configuration methods allowed too, Ethernet, Push Button and Label ( printed on the back of the device ) only with M1 trace, cool :).

If you only want to know if there is any WPS device enabled around you, just use wash tool like the following ( rtl8187 chipset / mon0 interface ) :

In the next post, I´ll be dissecting one of the design flaws that is deployed in that poor protocol.

Publicado en Wireless Hacking | Etiquetado Wireless Hacking | 1 comentario

Nebula level08

Publicado el 23 enero, 2013 por kernel

El enunciado del nivel 8 dice lo siguiente :

«World readable files strike again. Check what that user was up to, and use it to log into flag08 account.»

Nos logueamos y vamos al directorio de este nivel, como siempre, del usuario al cual queremos escalar privilegios, /home/flag08, rápidamente vemos un fichero «capture.cap», que puede ser interesante, y le echamos un vistazo » a cara perro » con un editor de texto, a ver si podemos ver algo:

Podemos observar que la captura ha sido realizada sobre una conversación TCP entre un servidor y cualquier usuario :

- Linux 2.6.28

- wwwbugs login

Seguimos investigando, a ver si podemos sacar algo más de información acerca de la captura, para ello, vamos a utilizar capinfos:

Ya sabemos algo más acerca de la captura, pero hay que profundizar aún más para estudiar el caso, por tanto podriamos usar Wireshark en modo gráfico y usar el modo «Follow TCP Stream» para ver la conversación entera, aunque para este caso usaremos la herramienta chaosreader, un script en perl que nos crea un index y recrea las conversaciones tcp de protocolos no encriptados como telnet, ftp, etc de una manera organizada además de separarnos los diferentes urls visitadas, imágenes… muy recomendable para tareas de MitM.

index.html creado por chaosreader

sesión TCP recreada por chaosreader

Bingo ! Podemos observar que el usuario ha introducido la contraseña «backdoor…00Rm8.ate» , que será la que nos piden para pasar de nivel, un momento, ese no es el password, intentamos loguearnos but no success :/ . No nos van quedando muchas opciones ya, salvo revisar el apartado Hexadecimal, el cual es el siguiente :

Estudiando detenidamente el output hexadecimal, junto con una tabla HEX-ASCII, podemos determinar lo siguiente:

- Lo introducido por el usuario está en rojo, de manera que:

- 0x62 = b

- 0x61 = a

- 0x63 = c

- 0x6b = k

- 0x64 = d

- 0x6f = o

- 0x72 = r

- 0x7f = Backspace

- 0x30 = 0

- 0x52 = R

- 0x6d = m

- 0x38 = 8

- 0x7f = Backspace

- 0x61 = a

- 0x74 = t

- 0x65 = e

Ahora si… 0x7f es la tecla DEL para borrar, de manera que se puede preveer que no se sabía la contraseña al 100 % ya que fue reculando y finalmente dio en un Login error. Por tanto, la contraseña que vamos a probar del usuario flag08 es la siguiente :

- backd00Rmate

Ahora si, Bingo ! :)

Publicado en Privilege Escalation | Etiquetado Privilege Escalation | Deja un comentario

nmap : «Key Exchange (dh 1024) of lower strength than certificate key»

nmap NSE 99,99%

Análisis global sobre el fraude en las Telecomunicaciones

ShellShock Reverse Exploit PoC

Nebula level10 – Exploiting access() syscall TOCTOU Race Condition

Nebula level 09 – Exploiting preg_replace in PHP

Easy monitoring bad guys in GNU\ Linux Servers with fsnoop

WPA/WPA2 WPS design flaws, easy way Part II

WPA/WPA2 WPS design flaws, easy way Part I

Nebula level08

Archivos

Meta