Grupos de Google ya no admite nuevas publicaciones ni suscripciones de Usenet. El contenido anterior sigue siendo visible.

OT idea desde otra lista...

Visto 0 veces
Saltar al primer mensaje no leído

Ostots

no leída,
25 ene 2002, 12:30:2325/1/02
a
Hola debian,

Esta idea me ha parecido muy interesante y se podrian a partir de esta
base hacer numerosas cosas mas, para administradores, yo como usuario
casero no me veo en la necesidad (jeje ahora no me digais que existe
un soft que ya haga esto eh??, jeje, si lo hay perdonad...):
(de la lista hackindex)

___________________________


El software es bastante sencillo, y lo puede realizar cualquiera
que sepa C en Linux.

Su misión consiste en intentar establecer una última línea de
defensa cuando todos los demás métodos han fallado.


Funcionamiento:

Tenemos el siguiente escenario, un servidor basado en
Linux/BSD/Unix, que está ejecutando uno o varios servidores
vulnerables, wuftpd, sendmail, etc.

Un atacante, encuentra en bug, ejecuta el xploit, por ejemplo un
buffer overflow, y ejecuta ...

* Por ejemplo bash, u otro shell, sh, ash, csh, ksh, etc.

* Algún interprete que pueda estar instalado, como perl.

* El cliente de ftp, para conectarse a su máquina e instalar un
troyano o rootkit...

* etc.

El software que propongo, al que de ahora en adelante voy a llamar
LLD (Last Line Defense, a falta de otro nombre) tiene como
misión sustituir a estos programas, bueno, al menos sólo en el nombre
...

Por ejemplo, renombramos a /etc/bash como /etc/qwert

Y renombramos al programa lld como /etc/bash y su misión
principal, consistirá en ejecutar /etc/qwert

Hasta aquí no hay ninguna seguridad adiccional, ...

La idea consiste, en analizar dentro de lld el descriptor de
fichero de la entrada estandar para averiguar si es un socket o
si es un dispositivo, /dev/console, /dev/pty01, etc.

Si se trata de un dispositivo, la consola o un terminal
tonto conectado a un puerto serie, simplemente ejecuta /etc/qwert
de forma transparente, pasandole cualquier parámetro que pueda
tener.

Pero, si se trata de un socket, simplemente, hacemos un

close(0);
close(1);
close(2);

Pues en este caso, seguro que es una conexión que procede desde
el exterior.

Ahora bién, si queremos hacer eso con 10 o 20 programas de líneas
de comando, ¿recompilamos 10 o 20 veces lld?

No, por que lo primero que se puede hacer dentro de lld, es
analizar el argumento argv[0], para saber que nombre tiene
puesto, y lee en un fichero de configuración, que programa
tiene que ejecutar.

Para evitar usar espacio innecesario en el disco duro, en
realidad lld no se renombraría, sólo se hace enlaces duros. (ln)

Como veis la idea es simple y fácil de implementar, probablemente,
alguien ya la tenga desarrollada, simplemente la
dejo aqui para quien se aburra.

Como posibles mejoras adiccionales, se puede extraer del
decriptor de fichero, en el caso de que se trate de un socket,
la dirección IP de origen, y anotarla en un fichero de trazas,
también se puede anotar el PID y nombre del proceso padre que
ha ejecutado lld.

Y para nota, la posibilidad de permitir ejecuciones desde la
red, en función de la IP o del proceso padre, (no es lo mismo que
bash tenga como proceso padre telnetd que httpd).

Lokutus, asimilando la red.
______________________________________________________


Saludos y ta luego,
Ostots mailto:ost...@navegalia.com

--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Gunnar Wolf

no leída,
25 ene 2002, 12:50:1525/1/02
a
> Hola debian,
>
> Esta idea me ha parecido muy interesante y se podrian a partir de esta
> base hacer numerosas cosas mas, para administradores, yo como usuario
> casero no me veo en la necesidad (jeje ahora no me digais que existe
> un soft que ya haga esto eh??, jeje, si lo hay perdonad...):
> (de la lista hackindex)
> (...)

Hola,

Desafortunadamente... Esto tiene varios peros:

- Hace más lenta la operación general del sistema
- Es muy fácil de brincar... Seguridad por obscuridad, a fin de cuentas.
En un Unix tradicional tienes varias decenas de comandos que te dan
algún tipo de shell, y siempre habrá alguno no contemplado. Y será
también muy fácil que, si este esquema se populariza, los atacantes
se aprendan los nombres reales...
- Dificulta la administración de tu sistema
- No necesitas de un shell para modificar algo en tu sistema víctima...
Puedes ejecutar directamente un 'rm', 'cat','tar' o lo que quieras con
haber explotado una vulnerabilidad sin pasar por un shell
- La única manera de dar seguridad a tu sistema es usar código seguro.

--
Gunnar Wolf - gw...@campus.iztacala.unam.mx - (+52-55)5623-1118
+---
|PARTICIPA EN EL CONSOL - Congreso Nacional de Software Libre,
|http://www.consol.org.mx, Ciudad de México, 11-14 feb 2002
+--

0 mensajes nuevos