viernes, 28 de agosto de 2015

¿Dónde se instalan las aplicaciones en Windows 10?

Si necesitas saber donde se instalan las aplicaciones en Windows 10, tan solo debes dirigirte al siguiente directorio/carpeta y ahí las encontrarás:


C:\Program Files\windowsapps ó


C:\Archivos de Programa\windowsapps


Recuerda que al igual que en Windows 8 (como ya comenté aquí), esta carpeta está protegida y necesitarás los permisos adecuados para poder acceder a ella.



RAII (Resource Adquisition is Initialization)

Todo programador de C/C++ sabe que un handicap extra a la hora de diseñar software e implementarlo correctamente, es la gestión de recursos/memoria. En este lenguajete de programación es bien conocido el trabajo de punteros y reservas/liberación de memoria y los riesgos que ello conlleva si no se realiza correctamente. Encontrarse con problemas de "fugas de memoria", "saturación de recursos", "buffer overflows", UaF, además de propiciar el mal funcionamiento del software o su comportamiento no controlado, pueden dar pie a graves problemas de seguridad.

Con esta idea en mente, un buen día Bjarse Stroustrup, inventor del lenguaje de programación C++, ideó una técnica de programación conocida como RAII (Resource Adquisition Is Initialization). Traducido al español, significaría algo así como que la adquisición de recursos es inicialización. La idea general consiste en dejar que sea el propio destructor del objeto el que se encargue de liberar los recursos que se habrán reservado previamente en la inicialización del mismo.

Vamos a plantear un caso práctico donde tiene mucho sentido implementar un patrón de estas características tipo RAII. Supongamos que tenemos un clase cuyo objetivo es guardar determinados eventos en un archivo de registro (LOG) clásico. RAII nos estaría diciendo que debemos inicializar y posiblemente abrir el archivo de registro en la inicialización del objeto o en su constructor y, que dicho archivo debería cerrarse y por ende, liberar sus recursos en el destructor de dicho objeto.

Esto cobra un gran sentido, si planteamos un escenario donde el archivo de registro se ha abierto con total normalidad, pero al escribir algún determinado evento en el mismo, se produce alguna excepción., o incluso excepciones que no tengan una relación directa con la clase encargada de gestionar el registro de eventos. Algo que debemos saber, es que ante tales excepciones, el código que con seguridad se va a ejecutar es el correspondiente al destructor de los objetos, lo cual garantizaría la liberación de los recursos. Sin embargo, si no utilizamos esta técnica, podríamos estar fugando la memoria correspondiente a los recursos consumidos por el objeto, dado que tras producirse la excepción, estos no serían liberados.

A continuación podemos ver una clase donde se hace uso de la técnica de programación RAII.


class CEventLog
{
public:
 // Constructor
 CEventLog(const char* nombrearchivo)
 : _pvFile(std::fopen(nombrearchivo, "w+")) {
  if (!_pvfile) {
   throw std::runtime_error("Error al abrir el archivo de registro (LOG).");
  }
 }
 // Destructor
 ~CEventLog() {
  if (std::fclose(_pvfile)) {
   throw std::runtime_error("Error al cerrar el archivo de registro (LOG).");
  }
 }
private:
 std::FILE* _pvFile;
 // ...
};


Pues bien, esta clase la podríamos utilizar con total tranquilidad, en cuanto a la liberación de los recursos consumidos por FILE se refiere, ya que estos, serán liberados "sí o sí", en el destructor de la clase, aunque se produjeran excepciones.


Como conclusión final, recordad que la liberación de los recursos consumidos por nuestros programas, es tan importante o más que su reserva.

sábado, 22 de agosto de 2015

Base64 encoding & decoding with OpenSSL

Just a Little reminder about using base64 with OpenSSL in Windows Operating Systems.

Encoding:

C:\> OpenSSL enc -base64 < file_name_plain_text.txt

Decoding:

C:\> OpenSSL enc -base64 -d < file_name_base64_encoded.txt

domingo, 2 de agosto de 2015

Android Stagefright Exploit / POC (III)

En la anterior entrada del blog comentaba que podíamos seguir principalmente dos vectores de búsqueda a la hora de localizar código vulnerable en el caso que nos ocupa (Android Stagefright).

Pues bien, en esta nueva entrada me voy a centrar en el vector de búsqueda por código fuente. Dado que tenemos acceso al código fuente, la manera más sencilla de localizar alguna vulnerabilidad, sin lugar a dudas será esta.

Son muchos los tipos de vulnerabilidades que puede tener un software y, una de ellas bien conocida y documentada son los "Integer Overflows" y los "Integer Underflows".

Parece bastante lógico pensar, que dada la complejidad del código de un sistema operativo (Android en este caso), no será difícil que algún programador cometa determinados tipos de errores y los desbordamientos de números, enteros en este caso, no son una excepción.

Como sabemos a día de hoy, desde la versión Android 2.2 hasta Android 5.1.1.r4 se han encontrado diversos fallos relacionados con los Integer overflows/underflows.

Para poder verlo de una manera más clara, nada mejor que echar un vistazo al código fuente de Android y en concreto al framework multimedia Stagefright que ha suscitado tanta polémica en los últimos días (y no es para menos,  según  dicen, más de 900 millones de dispositivos podrían ser vulnerables).

A continuación tenemos un pedazo de código fuente de Stagefrigtht en donde vamos a ver claramente uno de estos "Integer underflows", se trata de la función parseESDescriptor, cuya firma o prototipo tiene la siguiente forma:

status_t ESDS::parseESDescriptor(size_t offset, size_t size)

Rápidamente podemos observar que requiere de un par de parámetros de tipo size_t, que como sabremos se trata de un tipo entero sin signo (unsigned int), utilizado principalmente para devolver el tamaño en bytes de algún tipo de objeto, etc.

Esto significa que tanto "offset" como "size" debieran contener algún valor de tipo entero mayor o igual que cero, pero nunca menor, es decir, nunca debiera ser negativo.

Pues bien, aquí es donde han cometido el fallo, los chicos de Google cuando programaron esta función, cuyo cuerpo podemos ver a continuación, eso sí un poco abreviado para no mostraros código innecesario para la prueba de concepto:

1.  status_t ESDS::parseESDescriptor(size_t offset, size_t size) {
2.  
3.  if (size < 3) {
4.         return ERROR_MALFORMED;
5.  }
6.  
7.  offset += 2; // skip ES_ID
8.  size -= 2;
9.  
10. unsigned streamDependenceFlag = mData[offset] & 0x80;
11. unsigned URL_Flag = mData[offset] & 0x40;
12. unsigned OCRstreamFlag = mData[offset] & 0x20;
13. 
14. ++offset;
15. --size;
16. 
17. if (streamDependenceFlag) {
18.        offset += 2;
19.        size -= 2;
20. }
21. 
22. if (URL_Flag) {
23.        if (offset >= size) {
24.              return ERROR_MALFORMED;
25.        }
26.        unsigned URLlength = mData[offset];
27.        offset += URLlength + 1;
28.        size -= URLlength + 1;
29. }
30. ...
31. ... código eliminado intencionadamente
32. ...
33. }


Analicemos un poco este código para darnos cuenta donde está realmente el fallo encontrado. Si os fijáis en la primera sentencia de comparación, en caso de que size sea menor que 3 la función retornará con un error controlado y esto no supondrá a priori ningún problema (siempre que este sea tratado correctamente). Es decir, solo se seguirá ejecutando el código de la función cuando size sea mayor o igual que 3.

Supongamos que size vale 3, en la siguiente instrucción menos como se le resta 2 a size, con lo que pasaría a valer 1. Y en la siguiente instrucción que hace referencia a size, se le vuelve a restar 1, por lo tanto ahora size valdría 0.

Hasta aquí todo correcto, pero ahora viene la parte delicada, que provocará el desbordamiento de tipo entero (Integer overflow/underflow).


Se trata de la siguiente sentencia de comparación:


1.  if (streamDependenceFlag) {
2.         offset += 2;
3.         size -= 2;

4.  }


Recordad que en estos momentos size valdría 0, por lo tanto si se cumple la condición, es decir, si streamDependenceFlag es True, entonces se le restará nuevamente 2 al valor de size, dando como resultado "-2" y como hemos dicho anteriormente, el tipo de datos size_t es un tipo de datos entero sin signo, por lo tanto estaremos intentando almacenar un valor negativo en una variable que solo admite valores positivos, provocándose entonces el desbordamiento.


Ahora bien, ¿qué es lo que haría que se cumpla tal condición? pues si nos fijamos en la línea 10 del código:


1.  unsigned streamDependenceFlag = mData[offset] & 0x80;


Se hace una operación binaria entre mData[offset] y el valor 0x80, por lo tanto si en los datos almacenados en el array mData, y en el índice indicado por 'offset' almacenamos un valor tal que de como resultado TRUE, entonces la condición que provoca el desbordamiento se cumplirá.

La función completa tiene más código, pero es a partir de lo expuesto cuando se produce el verdadero desbordamiento y en las siguientes llamadas a funciones que se hacen en el resto de código, se pasa size como parámetro pero en esta ocasión con un valor del tipo 0xfffffffe

En el caso expuesto, hemos visto una función muy concreta del framework multimedia de Android (Stagefriht), que se encargaría de parsear o analizar archivos MPEG-4 en el caso de que el codec utilizado sea por ejemplo un 'mp4v'. Se trata de una extensión del formato de video MPEG-4 conocida como "Elementary Stream Descriptor" o ESDS para los amigos.


En todo caso, aquí tenéis un pequeño ejemplo con el que jugar para comprobar lo explicado:


unsigned datos[] = {0x01, 0x02, 0x98, 0x04, 0x45};


int Integer_Underflow(size_t offset, size_t size)
{
       if (size < 3)
            return -1;

       size -= 2;
       unsigned flag = datos[offset] & 0x80;
       --size;

       if (flag)
       {
             size -= 2;
       }

       return 0;
}



int main(int argc, char *argv[])
{
       return Integer_Underflow(2, 3);
}