[ Pobierz całość w formacie PDF ]
operativo Unix distinto al que estamos hackeando no servirán de nada),
por eso os aconsejé la distribución en directorios de los bugs según el
sistema o protocolo al que afecten. Esa organización os evitará pérdidas
de tiempo (con lo que aumenta la impaciencia del hacker :-) ) y os
ayudará a decidir las técnicas de hacking que debeis intentar de las que
no debeis intentar.
A la hora de intentar explotar algún bug relativo al sistema que estemos
hackeando también es importante tener los exploits bien organizados y
convenientemente editados (muchas veces los exploits vienen mezclados
en mensajes de texto) para que lo único que tengamos que hacer sea
subirlos por FTP al sistema y ejecutarlos (y compilarlos si no fueran
shell scripts).
2 - En caso de que no os funcione ningún bug en el sistema de los que teneis,
ante todo mucha calma. :-)
Importante: En este caso lo que debemos buscar es dejar las menos huellas
posibles en el sistema. Las huellas que habeis dejado hasta
el momento no podreis borrarlas así que por mucho que os
preocupeis por ellas no podreis hacer nada, sólo esperar que
el administrador no se dé cuenta de vuestras intrusiones
(tanto en el utmp, wtmp o los logs del syslog). No intenteis
cosas a lo loco como explotar bugs que funcionan en otros
sistemas porque lo único que conseguireis será dejar más
huellas y perder el tiempo.
Lo que sí podeis hacer es intentar explotar bugs que afecten a los
sistemas Unix en general (hay algunos) o bugs que afecten a alguno de
los protocolos TCP/IP. Si siguen sin funcionar ninguno dedicaos a
explorar el sistema (hasta donde os permitan vuestros privilegios)
para tener una visión general de cómo está protegido el sistema (por
ejemplo viendo si los usuarios tienen ficheros .rhosts, si determinados
ficheros tienen permisos set-uid, que propietario tienen determinados
ficheros, etc...), y a partir de ahí teneis dos opciones PRINCIPALES (es
decir, que puede haber más opciones pero yo siempre utilizo una de estas
dos):
I - Olvidarse durante un par de días del sistema que intentamos hackear
y aprender todo lo que podamos sobre el sistema operativo Unix que
utiliza esa máquina, ya sea buscando bugs más modernos que sirvan
para la versión del sistema que intentamos hackear como examinando
FAQs, documentos o páginas html que traten sobre dicho sistema en
general y su seguridad en particular, etc...
II - Hackear otra máquina del mismo dominio y que sea más fácil de
hackear, es decir, que sea mucho más insegura (hay sistemas más
"fáciles" o "inseguros" que otros debido a que se conocen más bugs
sobre ellos. Seguramente el SunOS 4.1.x sea el sistema del que se
conocen más bugs). Este método suele ser el más utilizado cuando
una máquina se nos resiste debido a que existen más recursos
al hackear una máquina (con técnicas que permiten conseguir
privilegios de root A LA VEZ que conseguimos entrar en dicha
máquina) desde una máquina de su mismo dominio que desde una máquina
que no pertenezca a su dominio.
3 - Cuando no conseguimos acceder a un ordenador que pretendemos hackear el
recurso que más se suele utilizar es el que hemos comentado antes. Se
trata de hackear otra máquina del mismo domino que sea más insegura y
desde esa máquina hackear la máquina que nos hemos puesto por objetivo.
I - La forma más sencilla es poner un sniffer en la máquina insegura
que hemos hackeado esperando conseguir una cuenta de la máquina
objetivo que pretendemos hackear.
II - Como he dicho antes, existen muchos más recursos para hackear una
máquina desde otra máquina de su mismo dominio de los que se pueden
utilizar al tratar de hackearla desde una máquina que no es de su
dominio. Por ejemplo aprovechando los ficheros .rhosts mediante
los comandos rlogin o rsh, comprobando si la máquina objetivo
exporta directorios a la máquina que hemos hackeado, etc...
Para terminar un par de consejos para determinadas situaciones que se aprende
a resolverlas a base de práctica, práctica y más práctica. Podeis leer un
montón de documentos sobre hacking como este pero si quereis aprender a
hackear de verdad lo mejor es la práctica y ponerse manos a la obra cuanto
antes, y que vosotros seais vuestros propios profesores.
4 - Nunca os de miedo de intentar hacer cosas dentro del sistema (mientras
tengan algún sentido claro, como he dicho antes, no hay que hacer las
cosas a lo loco). No penseis que os van a pillar y que os van a cerrar el
acceso. Si os pillan y os cierran el acceso mala suerte, eso forma parte
del aprendizaje del hacker, os vais a hackear otro sistema y se acabó
(incluso puede ser otro sistema del mismo dominio), pero siempre teneis
que experimentar, intentar las cosas por vosotros mismos, no os limiteis
a leerlas en un papel. Os descubrirán muchas veces y os cerrarán el acceso
otras tantas veces, pero cada vez ireis espabilando y lo ireis haciendo
mejor. Errores que cometisteis una o dos veces, más adelante no los
volvereis a cometer. En definitiva: aunque os dé angustia el que os
cierren el acceso a algún ordenador al que ya habiais conseguido entrar,
no os dé miedo explorar el sistema y experimentar.
5 - Muchas veces intentareis compilar un programa para explotar algún bug y
os dará errores cuando se supone que debía compilar correctamente.
Debuggar los programas también forma parte de las labores del hacker.
Con la práctica aprendereis a reconocer porqué tal o cual código fuente
no compila correctamente.
--------------------------------Cut Here-------------------------------------
2600 FAQ . Las preguntas más preguntadas.
Este texto esta traducido por mi del original en Ingles por lo que se observaran
muchos fallos que espero corregir con vuestra ayuda.Son preguntas que todos nos
hemos hecho alguna vez al empezar que
que tiene en este texto una respuesta clara y yo creo que sencilla . Ademas tambien
trae codigo de lenguaje C ,
C++ que puede ser util para determinadas circustancias. Que lo disfruteis.
Archive-Name: alt-2600/faq
[ Pobierz całość w formacie PDF ]