Carta a Papa Noel la saga tenía que continuar…

Hola a tod@s

Querido Papa Noel este año he optado por hacer pública mi carta anual y seguir la tradición que empezó Alejandro Ramos en Security by default. 

Este año he sido muy bueno, he sido papa, así que tendrás más trabajo cuando pases por casa. He organizado un congreso espectacular en Sevilla, repartiendo hacking por la ciudad hispalense, además nos llevamos de paseo por Sevilla a tu primo Richard, jo jo jo ;)

También me he portado muy en Mnemo y en el cliente sacando buenas notas, sin más dilación te describo a continuación los regalos que deseo para este año:

El deseo más anhelado de todos es que exista la paz en el mundo y que a nadie le falte dos cosas básicas en el siglo XXI como es el agua y la comida.

Si se cumple el primer deseo a mí me gustaría tener el teléfono móvil Pwn Phone, este dispositivo se ha hecho muy famoso tras aparecer en la serie Mr. Robot, aunque aquí en Estación Informática ya le dedique un artículo en la primavera del 2014. Se trata de un dispositivo móvil orientado a las pruebas de penetración, cuenta con una versión modificada de Android KitKat, con gran cantidad de aplicaciones de hacking preinstaladas. Además, posee un USB de tamaño estándar como el de cualquier PC al que se pueden conectar diferentes dispositivos (por ejemplo antenas o adaptadores bluetooth) para aumentar la potencia y el alcance de la señal del teléfono.



Como sabes me encanta los juguetes hacking, por eso me voy a pedir la LAN Turtle y la WiFiPineapple. La tortuga se trata de una herramienta de administración de sistemas y pruebas de penetración que se oculta en el sistema proporcionado acceso remoto, recopilación de datos, reconocimiento de red y capacidades de monitoreo tales como man in the middle. El caso de la piña se trata de una herramienta de auditoría red inalámbrica. Ya que entre wifis anda el juego puede ser que venga la piña con una Yagi, se trata una antena direccional que me será de gran ayuda en las auditorías wireless.




Sigamos, es el turno de Pwn Plug R3, el sueño de cualquier pentester. Cuenta con 802.11a/b/g/n Wireless, Bluetooth, funciona con Pwnix, una distro personalizada de Debian basada en Kali Linux y más de 100 herramientas.



PhantomKeystroker, si me llega a tiempo podré trolear a los compis del curro, tan sólo tengo que conectar el dispositivo en el ordenado de la víctima realizando molestos movimientos aleatorios en su ratón pensando que está infectado por algún virus.



Por otro lado me gustaría que me regalaras un KeyGrabber Wi-Fi Premium, estamos hablando de un keylogger inalámbrico equipado con dos microprocesadores de buen rendimiento, completo pila TCP/IP, transceiver WLAN y 4 gigabytes de memoria Flash. Este keylogger inalámbrico se conecta al Punto de Acceso Wi-Fi local, y manda E-mails que contienen el texto interceptado del teclado. Además, se puede conectar a distancia por TCP/IP en cualquier momento y consultar el archivo grabado de log. ¡Todo esto en un dispositivo de tan sólo 5 cm!



Y por último y no menos importante el Crazyradio PA para hacer “cosillas” de radio como Keysniffer digamos que es similar a un keyloger, pues el atacante captura todo lo que la víctima escribe en su teclado. A diferencia de un keylogger no tienes que conectar absolutamente nada en la máquina víctima, ya que la vulnerabilidad radica en teclados inalámbricos, además también podemos inyectar. :p



Sin otro particular, quedo a la espera de los regalos.

Atentamente: Javi.

PD: Ya no hace falta que me traigas la licencia de Shodan, me lo traje del Friday ;)



De 0 a exploiting (II)

Buenas amigos hoy os traigo la segunda entrada de la serie "De 0 a exploiting", donde me obligo a leer un libro de exploting y traeros los conocimientos que obtengo (a mi manera).

Antes de nada, aquí vamos con los preparativos que diré siempre:

###############################################

Desactivar la aleatoriedad en las direcciones de la pila, para ello debeis ejecutar el comando (como root):
echo 0 > /proc/sys/kernel/randomize_va_space

Compilar (hoy si) con:
gcc -g -fno-stack-protector -z execstack codigo.c -o programa
 
###############################################


El otro día os dejé con una pregunta a partir de cuantas 'A's el programa empezaba a petar.

Vamos a explicar hoy el por qué peta (hoy toca algo de teoría) , pues es uno de los conceptos más importantes en el exploiting.



SOBREESCRIBIR EL REGISTRO EIP

 Empecemos por el procesador, un elemento del ordenador el cual procesa datos e instrucciones, para finalmente realizar cálculos para lo cual se suele usar una ALU (Unidad Aritmético-Lógica). Los procesadores pueden guardar los datos en diferentes sitios, para ello pueden usar unas cosas llamadas "registros" los cuales tenemos algunos de proposito general AX,BX,CX,DX , tenemos otros que apuntan a los segmentos dentro de la memoria SS,CS,DS... (Para más información teneis el libro Arquitectura de Computadores de Hennessy y Patterson). Además de los registros, para guardar datos tenemos la memoria (la memoria recuerda cosas....).

De los registros tenemos uno de suma importania, IP o Instruction Pointer o Program Counter. Este registro se encarga de ir apuntando la siguiente dirección de memoria , como el código suelen ser saltos a funciones, condiciones, rutinas ... Pues necesitamos un registro que guarde la siguiente dirección de memoria a ejecutar. Bien en el programa de ejemplo del otro día hacíamos una llamada a una función, eso en ensamblador se convierte en un "Call", el cual es una de las pocas funciones que pueden modificar IP, al volver de la función el programa debe saber donde volver, por tanto guarda en una memoria específica (llamada la Pila a partir de ahora) el valor de IP antes de llamar a la función. En la pila se guardan los argumentos de las funciones, IP, variables locales... Esto permite la recursividad en programación.

Veamos un ejemplo de la llamada a la función del otro día en ensamblador (la cual tenía un argumento):

push arg ;mete argumento en la pila
call func ;llama a la funcion mete valor IP en la pila

Bien una vez dentro de la función debemos reservar como una "Pila" propia de la función para las variables de la función, esto es lo que se llama marco de pila, tenemos un registro llamado BS que apuntará al principio de esa pila, y tenemos SP que apunta siempre al final de nuestra pila. Pues un marco de pila se crea algo como así:

push bs ;guardamos el valor de bs (para no cargarnoslo), luego lo recuperaremos
mov bs, sp ; metemos el valor de sp, en bs (ya tenemos la base de nuestra pila)
sub sp, X ;restamos X al valor de sp, asi agrandamos nuestra marco de pila

Os preguntareis ¿Por qué restas X, en vez de sumar? si lo que queremos es agrandar, bien la pila va desde las direcciones de memoria más altas, a las más bajitas, por tanto para crecer, tenemos que restar (Imaginaos la pila como un hombre algo rata, nos deja unas direcciones lejos de la dirección más baja de la pila, una alta, y para reservar memoria en la pila, tenemos que quitarle direcciones, pues restamos).
Bien pues veamos un dibujo de como quedaría la pila, y a donde apuntarían ahora BS y SP.


(me he currao el dibujito ¿no?)

Bueno vemos que en los registros antes ponemos una 'E', esto significa que es un procesador de 32 bits, y en lugar de guardar 16 bits en el registro, guardamos 32 (un sistema operativo de 32 bits, sus direcciones tienen 32 bits).
Como vemos arriba del todo (las direcciones más altas) tenemos un marco de pila de otra función (por ejemplo main), y seguido metemos unos argumentos, luego la dirección a la que volveremos después, seguido el valor de BP para volver a cogerlo al acabar la función, vemos que EBP, al realizar el mov ebp,esp , ahora ebp apunta a donde se puede ver, seguido se haría sub esp,32 , para guardar la variable nombre, por tanto ahora esp apunta al final del buffer nombre.

Ahora viene lo siguiente la...

¿Por qué? , por que mientras que el buffer Nombre, se reserva para abajo, crece para arriba, y nosotros al meter un gritón de 'A's, llenabamos el buffer, luego llenabamos el valor guardado de EBP y finalmente el valor guardado de EIP, por tanto al acabar la función en donde estaba el valor de EIP ahora hay  "AAAA", y el procesador intentaba saltar a la dirección "0x41414141", la cual no está mapeada en nuestras direcciones de memoria.
Y por eso el programa petaba.

Ahora vamos una vez acaba la teoría, con la parte práctica.
¿Qué vamos a aprender?
  1. Encontrar manualmente cuantos bytes necesitamos para petar el programa.
  2. Encontrar automáticamente cuantos bytes necesitamos para petar el programa.
  3. Explotar este fallo para conseguir una shell.
1. Encontrar manualmente cuantos bytes necesitamos para petar el programa

Bien para realizar esto, vamos a utilizar el debugger: edb-debugger (Descargable aquí: https://github.com/eteran/edb-debugger ).
Para empezar vamos a ejecutar nuestro programa con este debugger y vamos a meter como argumento por ejemplo nuestro nombre y ver como se ejecuta:


Bien ahora iremos al programa edb-debugger a ver que nos encontramos:

En el centro tendremos bien en grandote tenemos el códigooooo (de momento pasad de este, por que no nos vale para nada).
 Tenemos la pila, donde vemos por ejemplo los argumentos de char argv[], el primero es ./ejemplo1 (nombre del programa) y el segundo es Fare9 (nombre).

Y finalmente tenemos los registros, los 4 primeros son registros de proposito general, tenemos EBP, ESP que apunta justo a la cima de nuestra pila (imagen de arriba de la Stack), ESI y EDI (ahora mismo no nos interesan mucho). Y finalmente uno que nos interesa mucho EIP, el cual vemos que está apuntando al principio del código que tenemos (imagen de arriba de código).
Como vemos está apuntando ahora mismo a una librería, todavía no es nuestro código. Por tanto para establecer todo al principio de nuestro main ejecutaremos: F9 .


Ahora tenemos otro código diferente y los registros también han cambiado su valor (en concreto EIP ahora apunta a la primera instrucción de nuestro código). Vamos a intentar reconocer un poco lo que se está haciendo. Lo primero que vemos es un lea (siglas de load effective address) a insertar un valor en ecx, ese valor es  [esp+4]. Esto en ensamblador es una forma sencilla de meter en ecx el valor de esp + 4. Luego se realiza una operación lógica and, seguido de un push, el cual vale para insertar datos en la pila como hace push con [ecx-4] es coge el valor de ecx restale 4 y accede a la dirección de memoria que es igual a ese valor de la resta, y lo metes en la pila. Bien no es un curso de ensamblador para cualquier cosa podéis ir a las referencias de abajo.
Vamos a algo más clave, un cmp (código para compare), compara un valor que guarda la dirección de memoria guardada en eax, con 2 (igual que hacíamos en nuestro programa) estamos comparando argc con 2, en caso de ser iguales (jz [jump if zero] es igual a je [jump if equal])  y vemos que si son iguales salta a0x0804501 (un poquito más abajo).

Para poder avanzar en edb debugger tenéis F7 y F8 , la diferencia entre ambos es que F8 si encuentra un call (o función) la ejecuta y pasa por encima, y F7 NO.

Pues ejecutemos hasta realizar el salto:
Bien ya estamos después del salto, vemos que tenemos 3 instrucciones que lo que hacen es buscar el primer argumento argv[1], el cual es nuestro nombre, antes del call tenemos push eax, que lo que hace es meter la dirección donde se encuentra "Fare9" en la pila, para finalmente llamar a Func(args).
Si vamos observando la pila veremos que al llegar al call, lo que tendremos es Fare9.
Bien, ahora realizaremos el call, y como os he contado antes, se debe meter la dirección siguiente al call ( 0804:8512 ), para entrar al call avanzamos con F7 .
Como vemos en la cima de la pila, se ha guardado la dirección de retorno.
Y vamos a ver el código que tenemos:
Vamos a ver las 3 primeras lineas, estas crean como os conté antes el "Marco de Pila", como vemos reserva en un principio 40 bytes, pasaremos del sub esp,8 . Lo siguiente es la llamada a la función strcpy(Nombre,arg) que teníamos en el código original.
En ensamblador al llamar a una función tenemos que meterle en la pila sus argumentos, los cuales los meteremos de derecha a izquierda, por tanto al meter [ebp+8] metemos el argumento que pasamos antes ("Fare9"), con lea eax,[ebp-40] , estamos haciendo que eax apunte al principio del buffer (40 bytes más abajo), seguido lo metemos en la pila y finalmente llamamos a strcpy. Ahí es donde vendrá nuestra oportunidad de insertar datos y datos. Iremos llamando ahora con F8 hasta llegar al call:
Vemos que primero se metió "Fare9" (la dirección de esa cadena), seguido del lugar de la pila donde se copiará BYTE A BYTE hasta encontrar un \0. Ejecutaremos y veremos la dirección de la pila bffff380:
Bien entonces, vemos que en bffff380 (como se indicó arriba) se ha copiado la cadena Fare9, y abajo del todo en bffff3ac, tenemos la dirección de retorno a donde volveremos después de finalizar Func(), cojamos nuestra calculadora de programador y restemos bffff3ac - bfff:f380.  La respuesta es 2C (el sentido de la vida...) bueno esto es el valor hexadecimal de: 44. Que es el número de bytes que metiamos antes de petar el programa, tras insertar 44, los siguientes petarán el programa, pues como veis ahora GRÁFICAMENTE, estamos modificando el valor de retorno.
Hemos aprendido entonces como ver cuantos bytes necesitabamos para petar el programa manualmente.

2. Encontrar automáticamente cuantos bytes necesitamos para petar el programa.

ahora seremos más rápidos, sabemos que con gdb al ejecutar el programa y petarlo con tropecientas 'A's, nos decía gdb, el programa ha petado por intentar acceder a la dirección 0x41414141, bien¿ y si metemos  "AAAABBBBCCCCDDDDEEEE...."?, depende de con qué sobreescribamos EIP nos dirá que ha petado con otra letra o conjunto de ellas, y después pues calcular "si he metido tropecientas letras en la cadena, y ha petado en la 'E', y cada letra eran 4 veces repetidas..." Bueno si no quereis hacer calculos podéis usar los programas "Pattern_create.rb" y "Pattern_offset.rb" de Metasploit los cuales uno te genera una cadena de caracteres aleatorios, y el otro le dices la cadena y el hexadecimal (creo) de dónde ha petado, y te dice bytes para petar el programa. Peeeero, si queréis un poco que pueda seguir con estas entradas, os pido useis mi versión PatternPetater . Un script en python que te hace las dos cosas a la vez.
En principio vamos a ejecutar el patternpetater, para ello : python randomGenerator.py .
Primero lo ejecuté sin argumentos y después con 128, ha generado una cadena aleatoria de 128 bytes, ahora ejecutaremos el programa ejemplo1 con gdb, seguidamente haremos un RUN y copiamos y pegamos la cadena anterior, lo cual dará un fallo:

Primero llamamos a gdb, seguido dentro de gdb ejecutamos run junto con la cadena que generó PatternPetatter, finalmente tuvimos un error con lo de la dirección : 0x77526846 (se cortó en la imagen). Bien copiamos esta cadena y la pegamos en PatternPetater, que estaba esperando por nosotros:
Como vemos PatternPetater, nos dice que 44 es el máximo de bytes antes de petar el programa, pues el String que causó el error fue FhRw (el cual está dentro de la cadena antes generada).
Bien con esto sacamos automáticamente cuantos bytes tenemos hasta petar el programa y sobreescribir EIP, esto nos será importante para saber que payload (lo explicaré en la siguiente entrega), podemos insertar, ya que 44 bytes no es mucho, por ejemplo un Meterpreter no podríamos.

3. Explotar este fallo para conseguir una shell.

Ahora vamos a crear un primer exploit en python, con lo cual uniremos un payload que se mostrará en el código, junto con purrelez que tenemos que meter para llegar a 44 bytes, más la dirección de retorno que guardaremos en donde estaba EIP, que será el principio del buffer, para que se ejecute nuestro código que insertamos:
 Aquí tenemos el shellcode, los nops son código que el procesador ejecuta sin hacer nada los cuales los pondremos antes del shellcode, para cuando el procesador salte al principio del buffer, ejecute un NOP y siga ejecutando hasta encontrar el shellcode. Como veis, la dirección de retorno es diferente a la que sacamos antes, esto puede cambiar por eso tenemos la última linea (ahora comentada), que nos abriría el debugger, para sacar la dirección a la que tenemos que saltar. Al ejecutar este exploit debemos obtener una shell de comandos:

Como vemos, al ejecutar el exploit, se llamó al printf que teníamos después de strcpy, hizo caplof, y por arte de magia (ir al gif de magic), nos devolvió una SHELL, para poder ejecutar nuestras cosas de Hackers y todo eso, por ejemplo podríamos dejar una shell a la escucha con netcat o aún mejor ncat cifrada con clave pública.

--------------------------------------------------------FIN

Como vemos hoy hemos aprendido mucho, mucho. Vimos como sacar manualmente el número de bytes para petar el  programa, vimos como utilizar herramientas para conseguir esto, y además creamos un primer exploit (no digais que Fare9 no enseña cosas pa' aburrir) .
Ya sabeis que podeis encontrarme en Twitter ( como Fare9 ), o podeis escribir en comentarios e intentaré responderos lo antes posible.

Nos vemos en el siguiente "de 0 a exploiting"




Referencias:

Más información en los apuntes de laboratorio de este hombre: http://atc2.aut.uah.es/~rico/docencia.htm

Troleando a Ubisoft (Watch Dogs ¿Hackers?????)

Buenas amigos, soy Fare9 y hoy os traigo un post extra, debido a algo muy gracioso que encontré en la web de ubisoft participando en un concurso de Watch Dogs 2.
El enlace os lo dejo por aquí: http://ubisoftspain.com/wd2/bienvenido-a-dedsec/ . Es sencillo, tu te logueas y vas respondiendo unas "preguntas" y ellos van posteando y te van dando como realizadas las "tareas" (en total unas 13), con esto vas descifrando un mensaje para poder obtener premios en caso de que descifres a la hora adecuada.



Bien por lo que vi, en cada pregunta que respondes al pulsar el botón "Ejecutar" , se ejecuta un javascript el cual usa una función con un SEND, y el número de la tarea a realizar:

Las tareas que puedes realizar son 4 hasta que la gente vaya participando cada vez más, pero digamos que a mi eso de esperar no me gusta, por tanto fui a investigar en el código.

 
Bueno ahora viene la magia, a la hora de responder fui respondiendo las cuestiones, hasta llegar a la 3 (por ejemplo). La pregunta era algo así como "¿a quién te gustaría trolear?", bien mi respuesta fue "A vosotros", y le di click derecho al botón y luego a "Inspeccionar elemento" (en Firefox).
Me apareció la etiqueta <a> que veis arriba, entonces vi que data-tarea tenía el valor "3" (es lógico, pregunta 3, data 3). Pues aquí empecé a modificar, primero con el 4 y aprietas botón, con esto vi que respondí en verdad a la pregunta 4.

Pues como estabamos en racha, seguí probando con el 5, con el 6 (los cuales parece ser también eran preguntas de añadir texto). Con esto he podido conseguir 7 tareas (respondiendo la 3 al final), cuando sólo 4 estaban disponibles:

Pues hasta aquí este post rápido, el cual no he tenido mucho tiempo de escribir, espero que os gustara y que no hagáis uso mal intencionado de ello (no me responsabilizo de temas legales).
Con esto quiero mostraros que dejar respuesta en la parte cliente, y dejar que un usuario pueda modificar estas cosas NO ES BUENA IDEA. Realmente no se trata de un bug de seguridad, pero en este caso nos estamos aprovechando de una función la cual no controla que las tareas estén activas o no.

Nos vemos en el próximo de 0 a exploiting que estoy preparando. Saludos a todos.


Archive.org corre peligro de extinción

Hola a tod@s
 
El efecto Trump está cambiando el mundo, incluso antes de ser elegido en la urnas. Todo el mundo se encuentra aterrorizado esperando los cambios que realizará el nuevo presidente de los EEUU. Uno de estos cambios afecta al campo de la informática.
 
Si miramos atrás en el tiempo la historia de las bibliotecas son una pérdida tras otra. La biblioteca de Alejandría es conocida por su desaparición. Autenticas obras de arte han sido destruidas para siempre. Esto es lo que quiere hacer Trump con la web archive.org. Para el que no lo conozca se trata de una biblioteca digital gestionada por una organización sin ánimo de lucro dedicada a la preservación de archivos, capturas de sitios públicos de la Web, recursos multimedia y también software.
 
Más de una vez he tenido que recurrir a este servicio para ver cambios realizados en una web, la cual ya no estaba disponible un artículo, una tool o un servicio.
 
¿Por qué quiere el Sr Trump eliminar este servicio? Fácil como cualquier político hace promesas que no cumple y no quieren que los profesionales de la información tiren de archivo. Quizás quiere asegurarse de borrar definitivamente su pasado digital, el Sr Trump no sabe que lo que se sube a Internet es para la eternidad.
 
Este año los responsables del Archive.org se han fijado el objetivo de migrar y crear una copia en Canadá y dejar a salvo los datos de locos como Trump. En cifras para ver la magnitud de este proyecto. 1Petabyte = 1000000 Gigabyte.
 
Estos son los datos de 2014:
Raw Numbers as of August 2014:
4 data centers, 550 nodes, 20,000 spinning disks
Wayback Machine: 9.6 PetaBytes
Books/Music/Video Collections: 9.8 PetaBytes
Unique data: 18.5 PetaBytes
Total used storage: 50 PetaBytes

Este proyecto costará millones. Por ello se piden donaciones para que este proyecto no muera en las garras de un inculto como Trump.

https://archive.org/donate/

No seáis malos. 

De 0 a exploiting (I)

Buenas amigos, soy Fare9 y hoy os traigo una serie de entradas que me gustaría seguir, puesto que me fuerzo a leer un libro, y a la vez escribir sobre ello.
Esta vez me he dicho "... Fare9, ¿por qué no leer un libro de exploiting?", y dije "Verdad es, pues vamos".
Así que me pongo manos a la obra y leo el primer capítulo, y pienso en escribir sobre ello, así que aquí va un poco del primer capítulo para llegar de 0 a exploiting.

###############################################

Antes de seguir vamos a dar un concepto que teneis que seguir antes de empezar cada sesión de exploiting:

Desactivar la aleatoriedad en las direcciones de la pila, para ello debeis ejecutar el comando (como root):
echo 0 > /proc/sys/kernel/randomize_va_space

Para volver a activarlo, ejecutar el comando (como root):
echo 2 > /proc/sys/kernel/randomize_va_space

Ahora para compilar los programas (en esta primera entrega no hace falta, pero bueno mejor ir aprendiendolo):

gcc -g -fno-stack-protector -z execstack codigo.c -o programa

Esto quitará las protecciones que tienen de pila los sistemas operativos actuales, no es muy realista, pero nos vale para ir empezando
###############################################

Bien amigos, el primer concepto que vamos a meter es el Buffer Overflow, o también llamado Stack Overflow ( aquí tenemos un enlace que es de las primeras, y seguramente la primera respecto a buffer overflow: Smashing the stack for fun and profit ).

Que es esto del Stack overflow, un buffer en lenguajes como C o C++, es lo que se suele conocer como array, estos tienen un tamaño fijo en memoria, y tenemos funciones que copian valores a estas buffers, una de ellas y de máxima problemática de seguridad es "strcpy", puesto que no copia mirando cuanto mide el buffer, sino que copia una cadena hasta encontrar un \0, byte null, el ese que a veces pones al final de una cadena como cadena[strlen(cadena)-1] = '\0'.
Bien, pues pueden pasar cosas malas si llenamos demasiado ese buffer.


Vamos a verlo con un ejemplo de código:



Vemos aquí un buffer o array de caracteres dentro de la función func, al cual luego se le copia un argumento el cual es dado por el usuario como primer argumento del programa.

Ahora este programa podemos compilarlo con gcc, o vuestro compilador favorito e introducimos por ejemplo: ./ejemplo1 Fare9 . Obtendremos la siguiente salida:

Como vemos nada malo ocurre. Bien, ahora vamos a intentar desbordar la pila, vamos a intentar ser como esos Hackers que vemos en las pelis, y vamos a causar una denegación en el programa, o Fallo de segmentación debido a un acceso de memoria a la cual no tenemos acceso.
Vamos a meter un montón de 'A' y ver cuando peta, podemos empezar por 33, así como los más chungos, como sólo admite 32, pues con 33 petará.
Para esto vamos a ayudarnos de python y su parámetro -c (así no escribimos 33 'A's):


Vaya, parece ser, que no pasó nada... Podemos retirarnos de este mundillo que no valemos...


TRANQUILOS, si volvemos a los apuntes de Rico, vemos que la memoria se suele gestionar de maneras un poco "genéricas", bien, el programa intentará reservar una cantidad X de memoria un poco mayor al tamaño del buffer por si acaso, puede ser 34, puede ser 53 (bueno dejemos que es más de 32).

Pues probemos con más, probemos con 128 (así por probar).

Bien como vemos, ahora a petado. Podemos usar gdb, para ver un poco mejor por qué ha petado.

Vemos que hay una señal recibida desde el programa, por fallo de segmetanción y nos da una dirección 0x41414141, pero 0x41 es el ASCII de.... 'A' . Ahora las cosas empiezan a tener algo de sentido, parece ser que el programa intentó ir a una zona de memoria referenciada por 0x41414141, y no está mapeada por el sistema operativo para este programa, por tanto, fallo de segmentación.

Bien hasta aquí hemos aprendido un poco que es esto del stack overflow, la semana que viene tendremos la explicación de por qué pasa esto (con imágenes por supuesto).
Como tarea os voy a pedir, que por favor, en los comentarios me dejeis a partir de cuantas 'A', empieza a petar el programa.

Hasta aquí la primera parte (espero que de muchas) de 0 a exploiting.


Playlist Hacking is not a crime

Hola a tod@s

¿Os imagináis un mundo sin música? Yo sin duda no, la música  se convierte en la banda sonora de nuestras vidas, música para lugares, en casa, en la oficina o en el coche. También es cierto que según el tipo de música se puede saber el estado de ánimo de la persona o la personalidad de la misma. 


Obviamente no todos los que nos dedicamos a la seguridad escuchamos la misma música, el cine y la literatura siempre han descrito a un hacker como un tipo anti social, con un aspecto desaliñado y encerrado en un bunker. Igualmente este estereotipo va acompañado de la música, que sólo se escucha música electrónica o sicodélica. No obstante he creado una playlist con temas variados como son canciones de las últimas ediciones de Defcon, BSO de Mr.Robot y la película Hacker piratas informáticos, Prodigy y demás variedad de temas que añadí, como Freestyler, Pink Floyd o Metallica, así como variedad de temas para meterte en tu terminal aislarte de todo y programar como loco.



No seáis malos.

Al rico SPAM (Análisis de una extraña whatsapp web)

Buenas amigos, soy Fare9 y hoy os traigo un pequeño análisis de un spam que me han pasado por Whatsapp (típico en estos días).


Aquí dejo el enlace (lo pongo como texto y no como enlace, vosotros ya vereis): http://goo.gl/QJUqfk

Bien, para realizar este tipo de tareas vamos a usar una máquina virtual (por si las moscas), para ello usaré una máquina virtual con Kali Linux (para quien no sepa que es: https://www.kali.org/).
Una vez tengamos la máquina virtual abierta, vamos a empezar el "análisis", para ello como siempre vamos a ponernos los cascos y elegir algo de música ( aquí mi recomendación: https://www.youtube.com/watch?v=06fjeICUKeU ):

    Para empezar y ver un poco algo superficial de la web, usaremos "whatweb" para ver las tecnologías usadas por el servidor:
 "whatweb http://goo.gl/QJUqfk"

 
 Como vemos la URL que teníamos no nos lleva a una web directamente, ya que el servidor nos devuelve un código 301 (Moved Permanently), este nos lleva a otra URL (http://wd8.co/wifi), el cual no nos devuelve un 200 sino un 302 (Found) para finalmente llevarnos a una URL final, http://mobiapps.online/wifi/es/?lang= , la cual esta vez el servidor nos responde con un 200 OK, y con la cual nos quedaremos, de esta URL obtenemos las cabeceras que el servidor envía. Vemos que tenemos el Country, HTML5, el tipo de servidor HTTP (cloudflare-nginx), tenemos el flag HttpOnly... Todo lo que se puede observar ahí en la imagen.
Bien con esto ya conocemos el servidor, ahora vamos a realizar un Who Is, para conocer un poquito más, esta información nos mostrará nombres y lugares:
"whois mobiapps.online"



 Oh, vaya, cuanta información apuntando a Madre Rusia, pero que le vamos a hacer, esta información no vale para mucho, pero por lo menos es gracioso ver de donde pueden venir estas campañas.

Ahora abriremos BurpSuite, el cual usaremos como proxy para navegar a la web (para saber como configurar Burp y el navegador mirad por aquí: https://portswigger.net/burp/help/suite_gettingstarted.html).

Primero en el navegador iremos a la primera URL (la cual nos pasaron por whatsapp), tras lo cual recibimos la siguiente respuesta al hacer click en "Forward" dentro de burp:
 Como vimos en whatweb, recibimos un 301, y podemos observar un Location, que es la siguiente URL que visitará el navegador. Bien aquí la respuesta:
 
Bien, bien, bien, esta vez el Location nos lleva a una URL más interesante, ya que en whatweb es la última que se nos mostró, por tanto veremos que el navegador finalmente nos lleva a una web con una interfaz muy bonita:



 
Nos vienen regalando Wifi gratis para whatsapp siempre que invitemos a 15 amigos... ¿QUIÉN NO QUIERE WIFI GRATIS?.
Bueno sigamos...

Tenemos esos dos botones principales, uno para Invitar Amigos y otro para Activar, vamos a dar click derecho en el primero y dar a Inspeccionar elemento:
Vemos que ambos botones, son referencias a URLs, aunque el atributo href no lleva a ninguna otra URL, sino, que al hacer click en los "botones" se ejecutan distintas funciones de Javascript, vamos entonces a buscar el código javascript (el cual se encuentra un poco más arriba que este código):

Que imagen tan interesante, vemos que el botón Invitar Amigos lleva a fn1 y Activar lleva a fn2, y parece que de cookies anda el juego, la función getCookie y setCookie son funciones que se encuentran arriba de estas dos, pero por lo que parece buscan ese número 15, que tanto nos incita la web. En Invitar Amigos, vemos que se obtiene la cookie, se suma 1, y se establece el valor cada vez que es pulsado el botón, en caso de que c, sea menor o igual a 15, se establece un href = 'whatsapp://send?text=wifi gratis para WhatsApp - ....', el cual es el mensaje que recibí por whatsapp, buscando por google esta extraña sentencia, obtenemos este enlace: https://www.whatsapp.com/faq/es/android/28000012 . La cual nos indica que es una URL para poder interactuar con whatsapp y enviar ese mensaje a cualquier usuario (una especie de API).

Al hacer click en Activar, nos muestra la alerta de "Por favor Invitar al menos ....", se ve que no es tonto el spam tampoco, y si pulsamos "Invitar Amigo" nos lleva a la URL de whatsapp la cual falla, al estar en un navegador y no tener si quiera el whatsapp web abierto. Bien como de cookies anda el juego, vamos a mirar las cookies, para ello usaremos CookiesManager, un plugin de Firefox que nos permite modificar y mirar las cookies que tenemos. Buscaremos por el nombre "invites":

Vaya, vaya, una bonita cookie, la cual se llama invites, y que tras pulsar una vez el botón de "Invitar Amigos" nos muestra el valor 1... Bien pues vamos a modificar, ya que no quiero invitar a ningún amigo haremos algo de trampas y modificaremos a mano el valor por 33 (bonito número y grado).

Damos a Save y marchando. Tras esto recargaremos la página, y qué narices está pasando, empieza a ir de una web a otra, y a otra, y a otra. Y acabamos en:

Que gente tan amable, primero nos ofrecen wifi gratis para el Whatsapp y luego nos dicen que podemos llevarnos un Iphone 7, por el simple hecho de responder unas preguntas... Joe con gente así en el mundo para que necesitamos trabajar.


Bueno hasta aquí el análisis de este SPAM que se va pasando por Whatsapp, parece incluso real, con una web tan currada y tal... Pero nunca hagais caso a estas cosas, nadie regala nada, y si os regalan que sea conocimiento como hago yo con entradas como esta. 
Nos vemos en una siguiente entrada y como ya dije estaré en la conferencia SEC/ADMIN presentando mi herramienta AndroidSwissKnife
En un principio doy gracias a la emisora de este mensaje a mi whatsapp mi amiga Irene, y a varios compañeros de trabajo los cuales me han aguantado tanta pregunta sobre estos temas de web, de los cuales casi no tenía ni idea (en especial a I. que me tuvo una semana de preguntas xD).