Fix highlighting with Rouge

_site/atom.xml

@@ -4,7 +4,7 @@
  <title>Guía de exploits</title>
  <link href="https://fundacion-sadosky.github.io/atom.xml" rel="self"/>
  <link href="https://fundacion-sadosky.github.io/"/>
- <updated>2018-07-04T14:45:58-03:00</updated>
+ <updated>2018-07-04T14:51:30-03:00</updated>
  <id>https://fundacion-sadosky.github.io</id>
  <author>
    <name>Mark Otto</name>

_site/configuracion.md

@@ -11,7 +11,7 @@ El ASLR ("Address Space Layout Randomization" o mapa de espacio de direcciones a
 
 Es posible temporalmente deshabilitar esta protección desde la terminal configurando el espacio de memoria como "no random".
 
-```bash
+```shell_session
 user@abos:~$ sudo sysctl -w kernel.randomize_va_space=0 #no random
 user@abos:~$ sudo sysctl -w kernel.randomize_va_space=1 #random
 ```
@@ -22,7 +22,7 @@ Los ataques iniciales consistiran en parte en inyectar un código arbitrario en
 
 Por defecto `gcc` compila con esta mitigación habilitada. Para deshabilitar protección de ejecución en la pila, al compilar con `gcc` agregamos el flag `-z execstack`. 
 
-```shell
+```shell_session
 user@abos:~$ gcc -o no-exec programa.c
 user@abos:~$ ./checksec.sh --file no-exec
 NX           ...    FILE
@@ -39,7 +39,7 @@ Para prevenir técnicas de explotación que [sobreescriben la Global Offset Tabl
 Es por ello que en este tipo de ataques que involucran la GOT es necesario que la mitigación RELRO (en inglés *RELocation Read-Only*) se encuentre **deshabilitada o habilitada parcialmente con la variante "RELRO parcial"**. Esta última opción es usada por defecto en la mayoría de distribuciones de Linux modernas, por lo que no es necesaria ninguna configuración extra.     
 No obstante en casos donde un ataque utilice la sección DTORS será necesario deshabilitarlo completamente con el flag `-Wl,-z,norelro`.
 
-```shell
+```shell_session
 user@abos:~$ gcc -o con-relro programa.c
 user@abos:~$ ./checksec.sh --file con-relro
 RELRO           ...    FILE
@@ -58,7 +58,7 @@ Frente a un ataque de reescritura de la dirección de retorno, el valor del cana
 En una primera instancia, de esta manera se evitaría una reescritura de la dirección de retorno de una función y la consecuente ejecución de código malicioso.
 
 Dado que inicialmente se trabajará con técnicas de corrupción de la dirección de retorno en memoria es necesario deshabilitar esta protección de la pila compilando con `gcc` con el `flag -fno-stack-protector`.
-```shell
+```shell_session
 user@abos:~$ gcc -o con-canary programa.c
 user@abos:~$ ./checksec.sh --file con-canary
 STACK CANARY      ...    FILE
@@ -77,7 +77,7 @@ No canary found   ...    sin-canary
 
 ### ¿Cómo compilar los binarios?
 Inicialmente se compilan con los flags mencionados previamente:
-```bash
+```shell_session
 user@abos:~$ gcc -m32 -fno-stack-protector -ggdb -mpreferred-stack-boundary=2 -z execstack -o abo1 abo1.c
 ```
 No se utiliza el flag `-Wl,-z,norelro` para deshabilitar `RELRO`, dado que con una configuración de `RELRO parcial` es posible comenzar. 
@@ -86,7 +86,7 @@ No se utiliza el flag `-Wl,-z,norelro` para deshabilitar `RELRO`, dado que con u
 En muchos exploits es necesario hacer cálculos sobre direcciones de la pila (la dirección de variables, punteros, etc). Como `gdb` agrega variables de entorno que se almacenan en la pila y la modifican, los cálculos sobre las direcciones obtenidas en `gdb` no resultan útiles para explotar el binario por fuera de un entorno de debugging.
 
 Por ejemplo, para ver las diferencias en variables de entorno:
-```bash
+```shell_session
 user@abos:~$  /usr/bin/printenv
 XDG_SESSION_ID=...
 TERM=...
@@ -107,12 +107,12 @@ Existen varias maneras de alinear la memoria dentro y fuera de `gdb`.
 ### Limpiar variables de entorno
 Para limpiar las variables de entorno es posible ejecutar el programa con el *wrapper* `env -i`. Como ejemplo podemos ver como se limpian las variables de entorno al ejecutar `env -i /usr/bin/printenv`:
 **Printenv**
-```bash
+```shell_session
 user@abos:~$ env -i /usr/bin/printenv
 user@abos:~$
 ```
 No obstante, vemos que `gdb` igualmente agrega variables de entorno:
-```bash
+```shell_session
 user@abos:~$ env -i gdb /usr/bin/printenv
 GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
 (gdb) r
@@ -125,15 +125,15 @@ LINES=34
 Una posible solución es usar el *wrapper* `env -i` para limpiar las variables de entorno tanto usando `gdb` como a la hora de ejecutar el programa. Dentro de `gdb` con `show env` es posible detectar qué variables de entorno se mantienen y optar por sumarlas en la ejecución o eliminarlas de `gdb` con `unset env`. 
 
 Por ejemplo, ejecutamos `printenv` con las variables de entorno que incluye `gdb` (usando siempre el `path` completo para ejecutar el programa como hace el debugger):
-```bash
+```shell_session
 user@abos:~$ env -i COLUMNS=72 PWD=$(pwd) LINES=34 /usr/bin/printenv
 COLUMNS=72
 PWD=/home/usuarix/carpeta
 LINES=34
 ```
 O debugeamos `printenv` con `env -i` y eliminamos dentro de `gbd` las variables de entorno que se mantienen con `unset env`:
 
-```bash
+```shell_session
 user@abos:~$ env -i gdb /usr/bin/printenv
 GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
 (gdb) show env
@@ -148,14 +148,14 @@ PWD=/home/usuarix/carpeta
 [Inferior 1 (process 4546) exited normally]
 ```
 Y si lo ejecutamos:
-```bash
+```shell_session
 user@abos:~$ env -i PWD=$(pwd) /usr/bin/printenv
 PWD=/home/usuarix/carpeta
 ```
 
 **Stack 1**
 Probamos la primer solución con el programa [Stack 1](buffer-overflow/1-practica#stack-1) y observamos cómo las direcciones de `buf` y `cookie` son idénticas al ejecutar y debuggear el programa:
-```bash
+```shell_session
 user@abos:~$ env -i LINES=34 PWD=$(pwd) COLUMNS=72 /home/usuarix/abos/stack1
 buf: bffffd94 cookie: bffffde4
 
@@ -166,7 +166,7 @@ buf: bffffd94 cookie: bffffde4
 ```
 
 Y sino, de otra manera, probamos sin variables de entorno en `gdb` y vemos como logramos las mismas direcciones para las variables:
-```bash
+```shell_session
 user@abos:~$ env -i PWD=$(pwd) /home/usuarix/abos/stack1
 buf: bffffdb4 cookie: bffffe04
 
@@ -183,7 +183,7 @@ buf: bffffdb4 cookie: bffffe04
 ```
 
 Si es necesario enviarle un input por stdin al programa vulnerable (que cuenta por ejemplo con una función como `gets()`) esta solución también funciona:
-```bash
+```shell_session
 user@abos:~$ python exploit.py | env -i PWD=$(pwd) /home/usuarix/abos/stack1
 buf: bffffdb4 cookie: bffffe04
 ...
@@ -202,7 +202,7 @@ buf: bffffdb4 cookie: bffffe04
 ```
 
 Y también cuendo el programa vulnerable espera que se le pasen argumentos por ejemplo con una función como `strcpy(buf,argv[1])`):
-```bash
+```shell_session
 user@abos:~$ env -i PWD=$(pwd) /home/usuarix/abos/abo1 "$(./arg-exploit.py)"
 buf: bffff558
 
@@ -219,14 +219,14 @@ buf: bffff558
 ```
 
 Para facilitar esta configuración es posible editar el archivo `.gdbinit`: 
-```bash
+```shell_session
 bash -c "echo 'unset env LINES' >> .gdbinit"
 bash -c "echo 'unset env COLUMNS' >> .gdbinit"
 ```
 
 ##### Script `fixenv`
 Otra solución es utilizar un script como [Fixenv de Hellman](https://github.com/hellman/fixenv) que fija las direcciones del stack. Es posible ver el funcionamiento del script de Hellman (usando `./r.sh` como *wrapper*) con el programa Stack 1.
-```bash
+```shell_session
 ; sin las direcciones de la pila consistentes
 
 user@abos:~$ ./stack1 
@@ -237,7 +237,7 @@ GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
 >>> r
 buf: bffff654 cookie: bffff6a4
 ```
-```bash
+```shell_session
 ; con las direcciones de la pila consistentes
 
 user@abos:~$ ./r.sh ./stack1
@@ -252,7 +252,7 @@ buf: bffff734 cookie: bffff784
 A diferencia de la solución anterior con `env -i` cuando el programa vulnerable toma un input por stdin, este script no resuelve las diferencias entre las direcciones con y sin gdb.
 
 En cambio funciona correctamente cuando es necesario pasarle argumentos al programa vulnerable:
-```bash
+```shell_session
 user@abos:~$ ./r.sh ./abo1 "$(./exploit.py)"
 buf: bffff558