tenemos un apuntador fijo, que se mueve respecto a que tantas cosas le hemos metido al stack.
si le metemos un int, sube un byte, si le metemos un carácter, sube 10 bytes.
en teoría no podemos movernos hasta abajo del stack.
Bufferoverflow lo que hace es aprovecharse de la estructura del stack.
el programa siguiente
void function(int a, int b, int c){
char buffer1[15];
char buffer2[10];
}
void main(){
function(1,2,3);
}
la funcion si no esta definida en bibliotecas de C, se va para arriba.
yendose a la pila, como se necesita regresar al main, se guarda una foto con el IP
instruction pointer -> tiene que regresar al main.
la funcion que dice que se tiene que regresar el instruction pointer es return pointer.
return pointer -> a donde tenemos que regresar para seguir con el procesamiento.
bottom of stack -> se tiene que ver de cabeza, porque las ddirecciones de memoria crecen a la derecha, pero en realidad crecen en direccion opuesta a como crece el stack.
al stack se le agregan primero las 3 variables que son parámetros de la funcion, luego return, luego sfp.
como las direcciones crecen a la derecha,
buffer2 buffer1
[ ] [ ]
si queremos escribirles a los buffers mas de lo que les cabe, se pasa al segundo buffer, pero si le escribimos más se puede ir al sfp, volandonos el primer byte del sfp, lo que puede pasar:
es que se llena el sfp, ya no encontrando el retorno que debería de encontrar, generando un segmentation fault, o lo que pudiera pasar seria que se sobreescribiera el ret.
sacando un segmentation fault, que es una actividad ilegal sobre un segmento de memoria que no te corresponde.
Podría pasar:
generar un buffer lo suficientemente grande para ejecutar un código que se pueda ejecutar.
PFF!!
modificando la siguiente instrucción del IP, eso es la explotación de buffer overflows para código arbitriario.
podriamos ejecutar un SHELL.
contructors en C
#include
void main(){
char *name[2];
name[0] = "/bin/sh";
name[1] = NULL;
}
pudieramos ver las instrucciones que nos arroja el ejecutable en asm, pudiendo ver las tablas de código.
un NULL, lo podemos obtener dinámicamente con operaciones dinámicas como XOR's.
en llamadas al sistema, o en ensamblador (libro ABEL).
la explotación de buffer overflows para código arbitrario se ve en CWE-120
cwe.mitre.org
listado de las vulnerabilidades en código, nota: se tienen que saber si nos dedicaremos a desarrollo de software.
TIPS:
Areas:
Infraestructura -> Hardening, mitjitzu alto, para UNIX muy bien, administración, pero no se necesita saber el manejo de memoria. Es más avanzado que un sysadmin. Area sencilla.
Auditoria -> se tiene que saber un poco de todo, se tienen que meter a areas administrativas, aprender cuestiones de relaciones interpersonales, vestirse para el éxito! jaja.
Pentesting -> aprender como ser curiosos, la mayoria de los pentesters tienen un conocimiento académico y de herramientas, necesitamos dominar la curiosidad, tendríamos que pensar como atacantes, pero con la ética de un hacker ético juaZ!!
auditoria y aplicaciones -> documentación mas que nada, curso en word nivel sayayin jajajajaja
Software o aplicaciones seguras -> necesitan técnicas para desarrollo de código seguro, hay varios libros, uno de ellos es el Writting secure code, ese libro es la biblia del desarrollo de código seguro, la razón por la cual es bueno, es porque microsoft a principios de las interfaces, se dio cuenta que lo que estaban atrasados en el desarrollo. Consultaron con los mejores desarrolladores de código seguro, si queremos estar en microsoft lo que piden es desarrollar código seguro.
y si nos metemos a Web -> es meternos a saber los manejos de servidor web, HTTP, detalle de especificaciones de JavaScript, CSS, que cosas se pueden hacer o no con él.
Incidentes o atención a incidentes -> es un Área muy administrativa, con que sepamos un poco de todo pasa.
Malware -> necesitamos saber codigo a bajo nivel, ensamblador a su máxima expresión, conocer las plataformas de windows o moviles, que son las que son actualmente atacadas, practicar con ensambladores, smashing, debería de ser rápido, no debería de ser un reto.
Pensandolo bien, me gustaría más malware...
Forense -> implica un conocimiento profundo de las plataformas que haremos los análisis forenses, sistemas de archivos (FS) HFFS, UTFS, tablas de particiones .. lo tenemos que saber bien.
todo lo anterior es para administrar los tiemos libres para las Áreas que nos gustan más.
Terminamos el viernes con SSH.
ps -> platicamos sobre ppid, parent process id, que son los identificadores del proceso, éste nos puede llevar a las distintas analogías.
pki -> public key infraestructure, y la privada, para cifrar un medio, haciendo un entorno seguro.
los CSR se pasan por la CA , a través de un proceso, transformando llaves públicas genéricas con sellos de autenticidad, generando CRT's.
la confianza sobre las CA's es implicita
casi siempre se debe de tratar la seguridad por capas, como cebollas o como lechugas, a pesar de que ya hay un esque ma de la capa de transporte no impide que se abarque con otro esquema partes que no se aplican.
Estandar SMTP, checar RFC
Protocolos.
Helo
RCPT
SEND -> iniciamos la transacción.
el estándar dice, primero mandamos todo y luego entregalo.
RESET(RSET)
VERIFY
SPAN
los estándares son simples, ya que son a lo mucho 15 comandos. Por lo tanto ese stack de comandos, implica varias respuestas.
Reply genericos, (checarlos)
Service reado 220.
mail , podria ser que nos conteste con 421, con 221 etc.
podria ser un 354 porque dice start mail, pero tal vez sería correctamente para Datos.
en que situaciones se definen en los rfc.
www.anta.net/misc/telnet-troubleshooting/smtp.shtml
las negritas es donde marcan los protocolos.
recapitulando, nos metimos al estandar porque usaremos los certificados, porque el viernes nos metimos a smtp.
Es probable que alguno de los estándares estén los comandos que definan autenticación.
algujno de ellos describe lo que esta usando gmail, estamos usando gmail como salida.
por lo tanto podría ser delivery.
estamos viendo actualmente el rfc 4954, que implica los comandos de autenticacion, para intercambiar credenciales.
el intercambiar las contraseñas codificadas en BASE64, es muy vulnerable, pudiendole la seguridad a nivel capa 4, implementandose a partir de la infraestructura pki.
Retomando el ejercicio del viernes, de saltos automáticos:
tenemos un server que se conecta mediante un agente.
copiando la llave publica se podria concetar al server externo.
cifra token con la llave publica, si no tenemos la llave privada correspondiente al token generado no se puede conectar.
Agent -> con él se puede guardar en ram con las credenciales, no se necesita meter el passphrase.
haciendo un forwarding del agent, lo haremos con un archivo de configuración.
(checar un forward del agent)
1)copiamos con ssh-copy-id al primer salto
2)eval `ssh-agent``
copiamos en la ram con ssh-add
(estudiar) jua jua jua, aunque mañana veremos taller basico de awk
ps -fea | grep ssh-agent | awk '{pint $2}' | xargs kill -9
obtenemos todos los procesos, todos los que tengan ssh-agent, y los matamos jua
eval `ssh-agent`
ssh-add
le damos la contra de la privada, para que la agregue en ram.
jua jua
hacemos login sin contra
podemos copiar el .pub, podemos ver lo que hay en la llave publica
2) lo seleccionamos, y lo copiamos al intermedio, añadimos eso al authorized_keys del ultimo salto.
ya que llegamos al ultimo, creamos un archivo con nuestro nombre, y copiamos juanito a authorized_keys.
uyna vez que esta en safe y despues con el cat al authorized...
podemos conectarnos al primero, enviamos una copuia del agent a safe para que lo tenga:
ssh usr@remoto "ls -l" y automaticamente cierra la sesion
el truco es hacer que se conecte al server que queremos
ssh usr@remoto1 "ssh usr2@remoto2" , en vez de listar lo conectamos.
no funcionará porque quieren asignarnos una pseudo terminal.
ssh -t usr1@server1 "ssh test@remoto2"
ya se esta haciendo el usuario.
para que se fordwarde el agent es con -tA
ssh -tA usr1@server1 "ssh usr2@remoto2"
se puede argegar con n servidores, solamente se agrega la publica con el otro server y al comando, agregamos con comillas escapadas
" ' ' " para agregar el nuevo server
mañana hablaremos con X, que son gráficos, veremos sistemas de escritorios, pero con X PUM
veremos sesiones remotas con VNC
fundamentos lights de iptables
veremos programación en bash y awk poco, con eso acaba el curso.
No hay comentarios:
Publicar un comentario