Planet

Uno de los primeros pasos con Robocomp será ejecutar algunos de sus componentes para probarlos, y a ser posible entender cómo funcionan. Para resumir todo el proceso (pues tendrás que hacerlo para cada componente que uses), los pasos son los siguientes: Localizar la carpeta del componente a ejecutar y abrirla en terminal. Compilar el componente [...]

Para empezar el proyecto, voy a explicar qué espero conseguir desarrollando YakiTo, analizando qué me ha motivado a ello. En el siguiente documento explico dichas motivaciones, y planteo los principales objetivos del proyecto.

• Lo que se espera de YakiTo

Como el proyecto Robocomp está en contínuo desarrollo, y seguramente tengas que utilizar herramientas que están en fase experimental, siempre será necesario actualizar de vez en cuando, pues puede que obtengas algún error inesperado que se soluciona con una simple actualización. Para actualizar Robocomp sólo necesitamos abrir la carpeta (directorio principal) en un terminal y [...]

Tras arreglar todos los problemas con la página y la forja, comienza oficialmente el desarrollo de JavaDiKt en el marco del V Concurso Universitario de Software Libre. El proyecto se dispone de los siguientes recursos:

• Página oficial, podéis acceder a ella indistintamente desde:
  http://www.ajaest.net/home/javadikt – Dirección del servidor
  http://cusl5-javadikt.forja.rediris.es/ – Dirección de la forja Red Iris
• Noticias:
  http://ajaest.net/home/category/javadikt/noticias/
• Bitácora de desarrollo en:
  http://www.ajaest.net/home/category/javadikt/
• Fedd RSS en:
  http://www.ajaest.net/home/category/javadikt/feed/
• Forja en:
  https://forja.rediris.es/projects/cusl5-javadikt/
• Foro:
  En construcción

En la bitácora publicaremos no solo noticias sobre el desarrollo, sino una amplia explicación sobre todos los aspectos de JavaDikt.
En la forja podréis encontrar el código fuente y la documentación además del repositorio SVN.

Quizas la razon por la que no me gustan los blogs sea la misma por la que de pequeño no me gustaba tener un diario secreto, pero lo cierto es que con la cantidad de veces que me he estampado la cabeza desarrollando el sistema de archivos creo que el hecho de que tengamos que mostrar nuestras inquietudes y nuestros miedos en el concurso es una buena idea, asi que aqui esta: el famoso y siempre infravalorado primer post de un blog :-DY despues del comentario ironico para romper el hielo, la charla. PirannaFS es un sistema de archivos de ambito general con la idea de ser ampliamente modular, ampliable y flexible y que incorpore todas las novedades que traen los sistemas de ficheros modernos pero desde una perspectiva distinta. Hasta ahora, en el State-of-Art todos los grandes sistemas de archivos modernos como son NTFS, Ext3/4, HFS+, el fallecido WinFS o mi siempre idolatrado ZFS han estado implementando funcionalidades de motores de bases de datos como demuestra el hecho de que cuando se abandono el desarrollo de WinFS se utilizo su codigo para mejorar el motor de Microsoft SQL.Y dije yo, ¿para que hacer un sistema de archivos que funcione como el motor de una base de datos cuando se puede usar el motor de una base de datos directamente? Llevaba bastante tiempo queriendo probar como funcionaba la libreria FUSE (Filesystem in USErspace) y debido a mis ultimos proyectos con python he estado usando bastante SQLite, asi que cuando llegue al ultimo capitulo del libro de Tanembaum (respecto a la lectura me parezco un poco a Hermione y su "lectura ligera" :-P ) me di cuenta no solo que eran bastante sencillos de implementar sino que ademas habia mucho terreno donde innovar, asi que la inspiracion para empezar a desarrollar PirannaFS fue casi instantanea: desarrollar una prueba de concepto de un sistema de archivos cuya administracion este gestionada enteramente por un motor de base de datos y aprovechar todas sus ventajas, como journaling de datos, poder personalizar las estructuras de las tablas segun se necesite...Sin embargo despues empece a recordar los comentarios/criticas/quejas/sugerencias/ideas que habia leido al respecto de que con los discos duros externos y los pendrives tan grandes que hay hoy dia un sistema como FAT32 se hace ineficiente, y las alternativas que hay o bien no son practicas para un sistema portatil (NTFS o Ext3 o HFS+ tienen problemas con la portabilidad, y mas importante aun, con los permisos de lectura/escritura que lo unico que hacen en un pendrive es incordiar) o bien estan sujetos a durisimas patentes como es ExFAT, la evolucion de Fat32 a los 64 bits y a los Exabytes que estan por venir, encontrandonos con que no hay ningun sistema de ficheros apto para las necesidades de hoy dia.Por todo esto, cambie las expectativas de PirannaFS a otras mucho mas ambiciosas: desarrollar un sistema de archivos factor comun y minimalista hasta el absurdo delegando toda la funcionalidad extra a modulos externos (el sistema base ni siquiera tiene soporte para links simbolicos :-) ) permitiendo ser usado alla donde no haga falta mas, pero preparado para poder ser ampliado y personalizado a traves de modulos externos que funcionen alla donde esten habilitados segun las necesidades del usuario: versionado de archivos, logging de actividad, ACLs, checksum de los datos, busqueda por metadatos, soporte de varios volumenes de disco simultaneamente...Y aunque todavia falte mucho para ello y quizas tenga que cambiar de python a C y embeber el motor de SQLite dentro de la aplicacion, espero que algun dia en lugar de estar la base de datos separada de los datos propiamente dichos llegue a ser autocontenido y pueda llegar a arrancar linux desde el :-D

Consiste en el desarrollo de un software de Adquisición de Datos, éste recogerá, en una tarjeta de memoria sd instalada en la centralita, a través de diversos sensores una serie de datos, que serán interpretados y mostrado a través de gráficas poligonales, histograma y nube de punto, pudiendo así mejorar una posible puesta a punto de la motocicleta o del pilotaje.

El objetivo principal  Electrónico es diseñar y fabricar un sistema de adquisición de datos, el cuál realiza las funciones de medir las variables físicas de una motocicleta y almacenarlas en una tarjeta de memoria para que sean posteriormente analizadas por el software Snail-DAQ.
Las variables físicas que se van a medir son:

• Velocidad (rueda delantera)
• Revoluciones del motor
• Temperatura del motor
• Recorrido de la suspensión delantera
• Posición del acelerador
• Aceleración y frenado (Fuerza G)
• Presión del freno de la rueda delantera
• Temperatura del neumático trasero

El sistema de adquisición de datos consta de un microcontrolador, encargado de gestionar toda la actividad electrónica. Se ha seleccionado un sensor para cada variable física enumerada anteriormente, de manera que se utilizan sensores tales como potenciómetros lineales, acelerómetros, sensores de temperatura infrarrojos, etc…

El próximo fin de semana 18- 19 Septiembre, haremos la primera prueba de electrónica y software en el circuito de Jerez

Hace unos días apareció una nueva vulnerabilidad en los productos Adobe, en especial para el lector PDF Adobe Reader, en este caso aprovechando una vulnerabilidad en el campo "uniqueName" situado dentro de la estructura de la tabla de fuentes True Type, permitiendo al atacante producir un desbordamiento de pila y ejecutar código arbitrario.En Metasploit no han tardado mucho en desarrollar un exploit e integrarlo para que podamos hacer las pruebas: adobe_cooltype_sing.rbPara poder explotarla:Los parámetros a configurar son el nombre del PDF que se genera y el path donde se almacenará, también podemos configurar el objetivo sobre el cuál queremos lanzarlo.Cargamos el payload a lanzarY por último ejecutamos el exploit y lanzamos el handler a la espera de que el objetivo ejecute el PDF y nos devuelva la sesiónEl único problema es que en determinadas plataformas y versiones de Adobe Reader este se queda colgado y no ejecuta el PDF.Si os dais una vuelta por el SVN del exploit podréis observar los nuevos commits que se van añadiendo y las versiones que se van soportando.

Auditoría de claves Oracle - Mecanismos de contraseñas usado por Oracle (I)Auditoría de claves Oracle - Obtener claves de Oracle (II)Auditoría de claves Oracle - Auditorizando las claves de Oracle (III)Auditoría de claves Oracle - Recomendaciones para mejorar la seguridad (IV)Comienzo otra nueva tanda de entradas donde trataré de dar un enfoque personal a lo que viene ser la auditoría de claves sobre productos Oracle. Si no te gusta el formato que utilizo para dividir las entradas siempre puedes ver directamente el fichero PDF que escribí hace un tiempo.PDF - Auditoría de claves OracleComenzaremos por dar un enfoque sobre los mecanismos de seguridad que son utilizados para generar las claves de forma interna en nuestras base de datos.Mecanismos de contraseñas usados por OracleLas contraseñas de las cuentas de usuario son almacenadas en la tabla SYS.USER$ empleando hashes de 8-bytes conseguidos mediant un algoritmo de hashing sin documentar.En un estudio realizado Joshua Wright & Carlos Cid se recogieron una serie de puntos débiles que comprometían la protección de contraseñas utilizadas en el mecanismo de autenticación:

• Un salt para generar contraseñas muy pobre.
• Pobre juego de caracteres permitidos.
• Algoritmo de hashing bastante débil.

El conocimiento de esto por parte de un atacante permitiria obtener la contraseña en texto plano del hash almacenado para un determinado usuario.Un salt para generar contraseñas muy pobreOracle utiliza una tecnica poco convencional para la obtención de los salt, anteponiendo el nombre de usuario a la contraseña antes de calcular el hash.Esto permite la posibilidad de obtener información sobre la contraseña de un usuario basándonos únicamente en su valor de hash y los credenciales conocidos para cualquier otro usuario.SQL> CREATE user prueba identified by password;User created.SQL> CREATE user prueb identified by apassword;User created.SQL> SELECT username, password FROM dba_users WHERE username LIKE ’PRUEB\ %’;USERNAME: PRUEBAPASSWORD: BBFF158371D315FCUSERNAME: PRUEBPASSWORD: BBFF158371D315FCRevisando el resultado de nuestra consulta, cualquier atacante podría tener fuertes evidencias de la relación existente entre ambas contraseñas de usuario.Además los valores generados para los salt no son aleatorios. Si bien es cierto que permite reducir la eficacia de un ataque de diccionario contra el hash de alguna contraseña larga. Pero eso no evita que un atacante pueda usar una tabla de posibles contraseñas para un usuario común (por ejemplo SYSTEM) y vaya probando en diferentes sistemas hasta dar con los resultados esperados.Pobre juego de caracteres permitidosOtro de los puntos débiles de Oracle es el pequeño abanico de caracteres que utiliza para obtener el hash de una contraseña.Antes de que este sea obtenido, los caracteres de la contraseña son transformados a mayúsculas, independientemente de cómo hayan sido introducidos estos por el usuario.Este comportamiento puede observarse para una misma contraseña introducida de diversas formas en el sistema y comprobar los valores de sus respectivos hashes.SQL> ALTER user prueba identified by "PasswoRd";User altered.SQL> SELECT username, password FROM dba_users WHERE username LIKE ’PRUEBA’;USERNAME: PRUEBAPASSWORD: BBFF158371D315FCSQL> ALTER user prueba identified by "password";User altered.SQL> SELECT username, password FROM dba_users WHERE username LIKE ’PRUEBA’;USERNAME: PRUEBAPASSWORD: BBFF158371D315FCSQL> ALTER user prueba identified by "PASSWORD";User altered.SQL> SELECT username, password FROM dba_users WHERE username LIKE ’PRUEBA’;USERNAME: PRUEBAPASSWORD: BBFF158371D315FCObservando la salida devuelta por nuestras consultas comprobamos que el hash permanece constante ante las modificaciones realizadas a la contraseña. Esto supone una reducción de la entropía de nuestas claves (por ejemplo,si usamos caracteres alfanuméricos, obtendremos un mecanismo que permite 36^n posibles combinaciones de longitud n, en lugar de 62^n , que serían las deseadas).Otro problema es la falsa sensación de seguridad que puede generar para una organización que ponga ciertas restricciones a la hora de generar sus claves, como la combinación de minúsculas y mayúsculas.Algoritmo de hashing bastante débilEl algoritmo utilizado para calcular los hashes no ha sido abiertamente documentado por Oracle, pero en 1993 apareció en el newsgroup de comp.database.oracle un mensaje donde se describía el algoritmo en detalle, reconociendo el uso de un magic number como parámetro de entrada.El proceso es el siguiente:

1. Concatena el nombre de usuario y la contraseña para producir una nueva cadena en texto plano.
2. Se convierte la cadena anterior en mayúsculas.
3. Se contierte la cadena en texto plano al formato multi-byte, teniendo los caracteres ASCII el octeto superior establecido a 0x00.
4. Se cifra la cadena en texto plano (completando con 0 en caso de ser necesario) usando el algoritmo DES en modo CBC con el magic number 0x0123456789ABCDEF.
5. Nuevamente se vuelve a encriptar la cadena en texto plano con DES-CBC, pero utilizando esta vez como magic number el último bloque de la salida devuelta por el paso anterior (ignorando los bits de paridad). Dicho bloque es convertido a cadena para poder producir con ella el hash de la contraseña.

En la siguiente entrega se explicará cómo es posible obtener una copia de todos los usuarios con sus respectivos hashes para poder sacar las contraseñas en texto plano.