[ Pobierz całość w formacie PDF ]
de
proteccion, flujo de datos, y muacion.
10) Buscar en los textos man, y guias de usuario las advertencias en contra de las
X, y tratar variaciones de X. Hacer lo mismo con la seccion de bugs.
11) Buscar comandos o funciones raramente usados o inusuales. En particular seria util
buscar argumentos indocumentados. Buscar flags de distribuciones anteriores, o en
versiones de otros sistemas operativos. Chequear las opciones que otros programas
podrian usar. Por ejemplo, Telnet usa la opcion -h para conectarse...
12) Buscar condiciones raciales.
13) Fallos del software para verificar que realmente esta comunicandose con el
software
o modulo de hardware al que quiere acceder.
14) Falta de deteccion de errores para resetear los mecanismos de proteccion
siguientes al error.
15) Implementacion pobre que da como resultado, por ejemplo, codigos de condicion
testeados inapropiadamente
16) Confianza inplicita: La rutina B asume que los parametros de la rutina A son
correctos por que la rutina A es un proceso de sistema
17) El sistema almacena sus datos o referencia parametros de usuario en el espacio
disponible de las direcciones de usuarios
18) Enterrar procesos de comunicaci3/4n: condiciones de retorno (passwd OK, illegal
parameter, segment error, etc) pueden proporcionar una brecha significativa cuando
son combiandos con el paso 17
19) Los parametros de usuario pueden no estar adecuadamente chequeados.
20) Direcciones que sobrepasan o se refieren a areas del sistema
21) Las comprobaciones de condicion de codigo pueden omitirse
22) Fallo al anticiparse a parametros inusuales o extraordinarios
23) Buscar niveles del sistema donde los modulos alli involucrados fueron escritos
por programadores diferentes, o grupo de programadores - se suelen encontrar
agujeros.
24) Registros que apuntan a la localizacion de valores de parametros en vez de pasar
el parametro el mismo.
25) Cualquier programa ejecutandose con privilegios de sistema (a muchos programas
se
les da UID 0, para facilitar el acceso a ciertas tablas, etc)
26) Archivos temporales, buffers leibles por grupos o por todo el mundo
27) Carencia de valores de "umbral", y carencia de notificacion una vez se han
accionado estos.
28) Cambiar parametros de areas criticas del sistema antes de su ejecucion.
29) Comprobacion inadecuada de los limites al compilar, por ejemplo, un usuario
puede
ser capaz de ejecutar codigo maquina disfrazado como datos en un area de datos
(si las areas de texto y datos estan compartidas)
30) Manipular incorrectamente interrupciones asincronas generadas por usuarios.
Usuarios interrumpiendo un proceso, realizando una operaci3/4n, o bien volviendo para
continuar el proceso o comenzar otro dejaran a menudo el sistema en un estado de
desproteccion. Archivos parcialmente escritos se dejan abiertos, escritura incorrecta
de mensajes de infracciones de proteccion, puesta incorrecta de bits de proteccion, etc,
suelen ocurrir.
31) Codigo que usa fopen(3) sin poner la umask. (ej: at(1), etc.). En general, codigo
que no resetea el UID real y efectivo antes de bifurcarse
32) Tracear es muy util para ayudarte a descubrir que llamadas de sistema usa un
programa
33) Escanea los sistemas de archivos /usr/local de cerca. Muchos administradores
instalaran software de la red. A menudo encontraras tcpdump, top, nfswatch,... suid
root por su facilidad de uso.
34) Comprobar que los programas suid fueron los que originalmente se pusieron en el
sistema. Algunas veces los administradores reemplazaran el password por uno menos
seguro que el de las distribuciones.
35) Buscar programas que se usaran para instalar software o modulos de kernel
36) Programas enlazados dinamicamente en general. Recuerda LD_PRELOAD, creo
que esa
era la variable.
37) La programacion de canales de I/O (Entrada/Salida) es es un blanco primario.
Busca errores logicos, inconsistencias, y omisiones.
38) Ver si es posible que un programa de canales I/O pueda automodificarse, hacer un
loop, y asi ejecutar el nuevo codigo modificado.
39) Si los canales I/O actuan como procesadores independientes tendran acceso
ilimitado
a la memoria, y asi el codigo de sistema podria ser modificado en memoria previamene
a su ejecucion.
40) Buscar bugs que requieran errores en multiples partes del software,ej: di por
ejemplo que el programa "a" puede usarse para cambiar el fichero de configuracion
/etc/a ,
ahora el programa "b" asume que la informacion de a es correcta y esto lleva a
resultados
inesperados (solo mira cuantos programas confian en el fichero /etc/utmp)
41) Cualquier programa, especialmente los suid/sgid, que permites "escapadas" a
shell.
Mejorar la Seguridad de tu Sistema.
Aqui esta un texto eminentemente practico donde se pueden ver algunas de las formas
de
conseguir un archivo passwd.
Esta un poco anticuado pero aun se encuentran maquinas que sucumben ante los
encantos de una de
estas "preciosidades".
Mejorar la seguridad de tu sistema irrumpiendo en el mismo
Dan Farmer Wietse Venema
Sun Microsystems Eindhoven University of Technology
2550 garcia ave MS PAL1-407 P.O. Box 513, 5600 MB
Mountain View CA 94043 Eindhoven, NL
zen@sun.com wietse@wzv.win.tue.nl
Traducido por Tosh & ReK2WiLdS
BBK "Big Bro Killerz"
http://www.geocities.com/SiliconValley/Pines/7347
bigbrokill@hotmail.com
Introducción
Todos los días, en todo el mundo, las redes de ordenadores y hosts son
violados. El nivel de sofisticación de estos ataques varia ampliamente;
mientras hay una creencia generalizada que la mayoría de estas intrusiones
tienen éxito debido a la debilidad de los passwords, hay todavía un gran
numero de intrusiones que hacen uso de técnicas mas avanzadas para entrar.
Poco es sabido acerca de este ultimo tipo de intrusiones , debido
principalmente a su naturaleza y a su dificultad de ser detectadas.
--------
CERT. SRI. The Nic. NCSC. RSA. NASA. MIT. Uunet. Berkeley.
Purdue. Sun. Cualquier sistema en Internet (y muchos que no lo están) son
[ Pobierz całość w formacie PDF ]