Odoo hacking IX

 En la anterior entrada, visualizamos como obtener información sobre a que módulos tenemos acceso mediante un usuario de portal, claro que esto también puede aplicar a un usuario interno en Odoo. Sin embargo el acceso al modelo ir.model no siempre estará disponible en todas las instancias de Odoo y no por eso debemos confiar que nuestra instancia esta segura, pues por medio de un ataque de fuerza bruta es posible validar a que modelos tiene acceso un usuario de portal y que clase de acceso posee.

Es importante listar estos modelos corregir accesos en los que corresponda, aunque eso podremos verlo mas adelante, en esta entrada, estaremos limitados a obtener esta información que nos podrá ser útil adelante para atacar la instancia de Odoo. 

Para lograr listar los modelos, emplearemos un ataque de fuerza bruta, mediante un diccionario de modelos estándar de Odoo, en el cual se pueden incorporar mas modelos, por ejemplo, si se posee el listado de aplicaciones instalas y hay aplicaciones de terceros instalas con código fuente disponible, se pueden agregar al listado por defecto.

Vídeo : Ataque de fuerza bruta a modelos y accesos.

Saludos.

Lexer Pars.

Script Odoo Hacking

Odoo Hacking I

Odoo Hacking II

Odoo Hacking III

Odoo Hacking IV

Odoo Hacking V

Odoo Hacking VI

Odoo Hacking VII

Odoo Hacking VIII

Odoo Hacking IX

Odoo hacking VIII

El día de hoy seguiremos ampliando la funcionalidad para nuestro script, esta vez agregaremos un método que nos permita validar si tenemos acceso de lectura y escritura, para ello utilizaremos el método check_access_rights, el cual nos devolverá un True si el usuario tiene acceso a un determinado modulo o False si no lo tiene.

Si tenemos acceso al modulo ir.model, podremos listar los accesos sobre cada uno de los módulos disponibles, si fuera el caso que no tenemos acceso a este modelo, en la siguiente entrada, incluiremos una funcionalidad que permita consultar los modelos estándar que de Odoo, que mal implementados en una instancia, nos podrían dar acceso a información útil.

Con esta funcionalidad, fácilmente se puede validar que modelos tenemos inseguros en cuando a lectura y escritura, esto claro esta, para usuarios de tipo portal. Mas adelante, agregaremos una funcionalidad, para construir un reporte de la auditoria realizada a la instancia.

Video: Funcionalidad para validar accesos.

Saludos.

Lexer Pars.

Script Odoo Hacking

Odoo Hacking I

Odoo Hacking II

Odoo Hacking III

Odoo Hacking IV

Odoo Hacking V

Odoo Hacking VI

Odoo Hacking VII

Odoo Hacking VIII

Odoo Hacking IX

Odoo hacking VII

 Antes de empezar con el tema, me gustaría poder realizar las entradas del blog, con mas carga de información, para avanzar con los temas, pero en los últimos días, se me ha complicado mucho la vida, en cuanto a lo laboral, estudios y vida social, que se me ha  llegado a limitar bastante el tiempo, sin embargo, espero poder hacer un espacio mas grande de tiempo con el cual, comparta mas de información.

Y continuando con el tema, un modelo con mucha información que debemos tratar de minar, por decirlo así, en otras palabras, extraer toda la información posible, es mail.mail, no siempre, pero si en muchos casos, este modelo se encuentra desprotegido y es posible obtener muchos o mejor dicho, todos los correos enviados y recibidos en la instancia de Odoo. 

Lo anterior es bastante bueno, puesto que nos permite con facilidad y algo de suerte, obtener un listado interno de usuarios, esto nos daría la posibilidad de poder realizar un ataque de fuerza bruta a dichos usuarios, para intentar adivinar su clave de acceso.

Es muy importante que al momento de estar desprotegido este modelo y permita obtener la información, realizar la extracción, registro por registro, ya que la cantidad de información recibida puede hacer que el sistema colapse y se realice una denegación de servicio. 

Les comparto un video donde se aprecia esta funcionalidad en el script que hemos venido trabajando.

Video : Funcionalidad para obtener correos y enumerar modelos

Saludos.

Lexer Pars.

Script Odoo Hacking

Odoo Hacking I

Odoo Hacking II

Odoo Hacking III

Odoo Hacking IV

Odoo Hacking V

Odoo Hacking VI

Odoo Hacking VII

Odoo Hacking VIII

Odoo Hacking IX

Odoo hacking VI

 Continuando con la herramienta, una vez ya enumeramos la información básica, empezaremos a utilizarla, iniciaremos obteniendo el listado de modelos disponibles en la instancia de Odoo, para ello podremos emplear un usuario interno o bien un usuario de portal. Para lograr esto debemos realizar una petición por medio de xmlrpc, empleando el método search_read.

Imagen 1: Código para obtener listado de módulos en Odoo.

Lo anterior es importante puesto que con ello obtendremos el listado completo de modelos disponibles en la instancia, con esto, podremos verificar en cada modelo, posibles métodos y funciones inseguras que permitan comprometer la instancia, esto empleando ataques de fuerza bruta para adivinar nombres de métodos y funciones, así como buscar código fuente de aplicaciones en internet.

Imagen 2: Resultado de búsqueda de modelos.

En la imagen 2 obtenemos el listado de modelos, empleando un usuario de portal, con lo cual, ya tendremos un listado de información suficientemente grande para auditar, además, de validar a cuanta información tenemos acceso en cada modulo, que ya iremos obteniendo mas adelante.

Saludos.

Lexer Pars.

Script Odoo Hacking

Odoo Hacking I

Odoo Hacking II

Odoo Hacking III

Odoo Hacking IV

Odoo Hacking V

Odoo Hacking VI

Odoo Hacking VII

Odoo Hacking VIII

Odoo Hacking IX

Odoo Security | Blindando el Sistema desde el Desarrollo

 Hace ya varios días hemos abordado temas sobre malas practicas al momento de implementar Odoo, así como malas practicas al momento de desarrollar en Odoo, que pueden dar paso a que un atacante acceda  a nuestra instancia de Odoo e incluso acceder al servidor que lo aloja.

Hoy encontré un video muy bueno de ateneolab, donde abordan temas sobre buenas practicas orientadas a la seguridad en el desarrollo de aplicaciones en Odoo, aunque de momento aun no hemos abordado temas sobre seguridad en instancia de Odoo, si que quiero compartir este video, con buenas practicas.

Con la herramienta para auditar Odoo que estamos trabajando, podremos detectar inseguridades que pueden dejarnos vulnerables, con lo cual, podremos aplicar las medidas compartidas en el video, para asegurar nuestros métodos públicos.

Mas adelante estaremos abordando estos temas de seguridad, tanto a nivel de instancia de Odoo, programación segura, y hardening a servidores. 

Video : Blindando el Sistema desde el Desarrollo

Saludos.

Lexer Pars.

Odoo hacking V

 Después de haber incorporado las funciones para listar la versión, el tipo de instancia, la versión del protocolo, listar las base de datos, listar las aplicaciones instaladas en una instancia, opción para registro de usuarios de portal, así como restablecimiento de contraseñas.

Lo próximo será, realizar una comprobación rápida, de usuarios y claves que pueden emplearse por defecto, aunque parezca mentira, hay muchas instancias que contienen credenciales comunes y fáciles de adivinar, por ello, realizaremos un breve ataque de fuerza bruta, a todas las bases de datos que se dispongan, en caso de poder listar las base e datos, activaremos este ataque de fuerza bruta.

Video 1: Funcionamiento de odoo script y fuerza bruta.

En el video anterior, podrás visualizar el script en funcionamiento, donde se realizar la obtención de información básica de la instancia, así como obtener todas las base de datos, y por ultimo un ataque de fuerza bruta a cada una de las base de datos, con credenciales básicas. Todo lo anterior de una primera fase de una auditoria, con una comprobación básica de información.

Mas adelante, incorporaremos un ataque de fuerza bruta, basado en un diccionario externo, tanto para usuarios y claves, así como para nombres de funciones y parámetros de módulos instalados en una instancia.

Saludos.

Lexer Pars.

Script Odoo Hacking

Odoo Hacking I

Odoo Hacking II

Odoo Hacking III

Odoo Hacking IV

Odoo Hacking V

Odoo Hacking VI

Odoo Hacking VII

Odoo Hacking VIII

Odoo Hacking IX

Odoo hacking IV

 Continuando con nuestro script, ahora, agregamos una función que nos permita recuperar las aplicaciones instaladas en la instancia de Odoo, esto aun sin autenticarnos en el sistema. Cabe mencionar que no todas las instancias poseen esta información, como carácter publico.

Para ello, accederemos al recurso website/info, esta pagina es muy importante al momento de auditar una instancia de Odoo, puesto que ofrece un listado de aplicaciones instaladas, con nombre y url del autor, esto ofrece un repertorio de código que puede analizarse para determinar si existen aplicaciones inseguras, desde luego, siempre y cuando estas aplicaciones estén disponibles para descargar en internet.

El recurso anterior esta disponible, siempre y cuando exista una sola base de datos en el servidor, o bien, exista un filtrado de base de datos y el administrador tenga publico este recurso, o no permita listar las bases de datos, en caso contrario, no podrá ser accedido.

Para lograr esto, utilizaremos una función, que nos retorne esta información, apoyándonos de técnicas como web scraping.

Imagen 1: Función que obtiene aplicaciones instaladas.

Tras ejecutar el script, con un servidor alojando múltiples bases de datos, no obtendremos nada adicional, como vemos a continuación.

Imagen 2: Múltiples base de datos, no permite listar aplicaciones.

Y si no esta el recursos disponible, tendremos como resultado un 404, como se muestra a continuación.

Imagen 3: Not found, website/info.

Imagen 4: Listando aplicaciones instancia Odoo.

Como notamos, en los casos correctos, obtendremos el listado de aplicaciones instaladas en la instancia del servidor, con el cual ya tendremos información para verificar la seguridad de las aplicaciones. En las próximas entradas estaremos agregando mas funcionalidad al script, el cual puedes clonar, para testear.

Saludos.

Lexer Pars.

Script Odoo Hacking

Odoo Hacking I

Odoo Hacking II

Odoo Hacking III

Odoo Hacking IV

Odoo Hacking V

Odoo Hacking VI

Odoo Hacking VII

Odoo Hacking VIII

Odoo Hacking IX

Odoo hacking III

 Como hemos observado con anterioridad, para fijar la conexión xmlrpc a Odoo, son importantes 3 cosas, el usuario, la clave y la base de datos, en nuestro script de Odoo hacking, tenemos el método listar base de datos directamente, sin embargo en muchos de los casos esto no es posible, debido a problemas de acceso, esto se debe a que el archivo de configuración tiene el parámetro db_list como False.

Sin embargo hay otro mecanismo para obtener el nombre de la base de datos, el cual se basa en registro y recuperación de contraseña, desde luego, no todas las implementación de Odoo tiene habilitado esto, usualmente se tiene disponible al tener tienda en lineal o ecommerce.

Agregaremos esta funcionalidad al script, para detectar cuando permita el poder registrarse como usuario de portal, en Odoo y tenga habilitado la recuperación de contraseña. 

Imagen 1: Funcionalidad para detectar registro y restablecimiento.

Con esto ya tendremos habilitado, la detección de esta información, si realizamos una prueba de esto, veremos el siguiente resultado.

Imagen 2: Odoo hacking, reflejando disponibilidad en ambos métodos.

Imagen 3: Odoo hacking, reflejando que no permite el registro de usuarios de portal.

Imagen 4: Odoo hacking, refleja que ninguno de los métodos, registro y recuperación. 

La ultima imagen, si bien es cierto, nos retorna el listado de las bases de datos, nos refleja que no dispone de los métodos de registro de usuarios de portal, y tampoco permite recuperar la contraseña de los usuarios. En este tipo de casos, se puede optar por realizar ataques de fuerza bruta, a los usuarios y contraseñas. Pero esto lo incluiremos mas adelante en el script.

Saludos.

Lexerpars.

Script Odoo Hacking

Odoo Hacking I

Odoo Hacking II

Odoo Hacking III

Odoo Hacking IV

Odoo Hacking V

Odoo Hacking VI

Odoo Hacking VII

Odoo Hacking VIII

Odoo Hacking IX

Odoo hacking II

Ya recopilamos información básica de Odoo con nuestro script, sin embargo aun hace falta un largo recorrido para completar sus funcionalidades.

Otro método importante es listar las bases de datos, que posee un servidor, para ello emplearemos el método xmlrpc.

Imagen 1: Método que obtiene el listado de base de datos.

El método de versión y base de datos, puedes probarlo en cualquier servidor, puesto que es información que puede ser obtenida sin caer en ninguna ilegalidad, para ello puedes emplear el siguiente dorck para google hacking :  allinurl:8069/web/database .

Imagen 2: Obteniendo listado de base de datos, servidor localizado en internet.

Adicional a esto, debemos validar que este permitido el listar las base de datos por medio de xmlrpc, ya que si realizamos esto, sin validarlo, obtendremos un error de acceso denegado, como se muestra a continuación.

Imagen 3: Acceso denegado db.

Imagen 4: Validación de acceso denegado.

Con esto ya tendremos preparados los métodos versión y db, con lo cual podremos obtener la información básica de Odoo, así como las bases de datos que tiene disponible.

Imagen 4: Listando información básica y base de datos.

Saludos.

Lexerpars.

Script Odoo Hacking

Odoo Hacking I

Odoo Hacking II

Odoo Hacking III

Odoo Hacking IV

Odoo Hacking V

Odoo Hacking VI

Odoo Hacking VII

Odoo Hacking VIII

Odoo Hacking IX

Odoo hacking I

Hace algunos días abordamos el tema de la seguridad en el ERP Odoo, y como es posible "hackear Odoo", aprovechando una mala implementación del sistema, así como malas practicas al momento de desarrollar nuevos módulos.

En las siguientes entradas veremos como crear nuestro propio script para automatizar las tareas de realizar una auditoria de seguridad a nuestro sistema ERP Odoo, esto debido a que no hay muchas, si es que ningún script para auditar este sistema 100% dedicado a Odoo. Este script lo trabajaremos en el repositorio de git de odoo_hacking, el cual puedes descargar para utilizarlo.

Iniciaremos con algo básico, para ello emplearemos el lenguaje de programación python, en mi caso empleare el Spyder como entorno de desarrollo. 

Empezaremos solicitando un parámetro, el cual es el host donde se aloja Odoo, esto nos servirá en adelante, ya será nuestro objetivo para realizar la auditoria.

Como primer punto, debemos conocer el sistema que vamos a auditar, si bien es cierto, sabemos que es Odoo, aun debemos determinar que versión es, puesto que hay muchas versiones, y las mas vulnerables son las mas antiguas y las mas recientes. Esto es porque las versiones antiguas tienen menos soporte, la prioridad suelen ser versiones mas recientes. Por otro lado, las versiones mas recientes, en este caso la versión 15, existen muchos bugs que salen con frecuencia, debido a su reciente salida al mercado. Aunque existen versiones estables, como lo son la 13 y 14, aunque suelen ser estables, pueden ser objeto de ataque.

Además de lo anterior, debemos conocer si es Enterprise o Comunitaria, aunque la seguridad es buena en Odoo, puede lleguemos a punto, donde encontremos una vulnerabilidad en un modulo Enterprise, el cual nos será imposible auditar bajo una Comunitaria.

Para obtener esta información, debemos invocar el método versión, por medio del protocolo xmlrpc, este método puede ser llamado sin estar autenticado en el sistema de Odoo.

Imagen 1: Código para obtener la versión de Odoo.

Imagen 2: Script Odoo hacking main.

Imagen 3: Ejecución de script para obtener versión.

En las próximas entradas estaremos agregando mas funcionalidades al script, para que nos permita realizar una auditoria mas amplia de Odoo.

Saludos.

Lexerpars.

Script Odoo Hacking

Odoo Hacking I

Odoo Hacking II

Odoo Hacking III

Odoo Hacking IV

Odoo Hacking V

Odoo Hacking VI

Odoo Hacking VII

Odoo Hacking VIII

Odoo Hacking IX

Conclusión programación insegura y seguridad por obscuridad

Después de realizar múltiples ataques, en su mayoría de fuerza bruta, logramos ir escalando privilegios, partiendo desde una cuenta de portal en Odoo, obteniendo un usuario interno de Odoo, mediante la recopilación de información en el sistema, basado en malas practicas al momento de implementar Odoo, seguidamente explorar aplicaciones con códigos inseguros, realizando ataques de fuerza bruta a funciones de modelos y parámetros que estas reciben. Por ultimo comprometer el servidor, debido a un código inseguro en una aplicación de backups, hasta llegar al usuario root.

Para evitar esto, es recomendable realizar una implementación correcta y segura de Odoo. Hay muchas cosas a tomar en cuenta. Por mencionar algunas:

1. Utilizar claves seguras en los servicios.
2. No utilizar claves repetidas para los servicios.
3. Fijar políticas de claves robustas para los usuarios.
4. De ser posible, emplear autenticación de 2 factores.
5. Tras una instalación de Odoo, atacarlo y confirmar la solides.
6. Utiliza certificados SSL.
7. Realiza un proceso de hardening al servidor.
8. Utilizan un filtrado de puerto y no dejes expuestos servicios sin razón alguna.
9. Utiliza servidores separados para Odoo y Postgres o tu motor de base de datos.
10. Realizar pruebas de funcionalidad y seguridad a los módulos o programación.
11. Realiza auditorias de seguridad de manera recurrente.
12. Mantén actualizado el sistema con los últimos parches.

Están son 12 medidas mínimas que se deben realizar, para garantizar que el sistema este protegido, desde luego que hay otro gran grupo de medidas de seguridad que se pueden agregar, pero ya veremos en el transcurso de este año.

Saludos.

Lexer Pars.

Programación insegura y seguridad por obscuridad I

Programación insegura y seguridad por obscuridad II

Programación insegura y seguridad por obscuridad III

Programación insegura y seguridad por obscuridad IV

Conclusión Programación insegura y seguridad por obscuridad

Programación insegura y seguridad por obscuridad IV

Dentro del servidor, con una conexión ssh, examinaremos la configuración del sistema Odoo, regularmente se encuentra en /etc/odoo-server.conf., en mi caso, al ubicar el archivo, este no se encuentra disponible. Podemos ubicarlo, sin embargo, emplearemos el comando history, para saber que sucedió antes que tuviéramos acceso al mismo.

Imagen 1: Ubicando archivo de configuración de Odoo.

Imagen 2: Comando history.

Después de ejecutar el comando history, obtenemos el archivo de configuración. el cual se encuentra el home de odoo, llamado .odoo-server. Para ello realizamos un cat .odoo-server. De lo anterior, quisiera resaltar 2 aspectos importantes, contamos con una contraseña para la base de datos, y una contraseña master odoo, la cual permite habilitar un crud para base de datos.

Imagen 3: Archivo de configuración de Odoo.

Intentamos ingresar a la cuenta root probando ambas claves, para ello ejecutamos sudo su.

Imagen 4: Probando claves con root.

Después de realizar esto, verificamos que la clave de root, es la misma que admin_passwd. Con esto hemos logrado acceder al 100% del servidor, esto debido a que el servidor de la base de datos y Odoo se encuentran en el mismo servidor. Lo cual resulto muy fácil, ya que el hecho de aplicar la misma contraseña para múltiples servicios, es una mala practica. Sin embargo, si no hubiera sido el caso, podríamos intentar crackear la clave por medio de john.

Como puedes ver, el hecho se sumar una mala implementación en Odoo y utilizar programación insegura y agregando la seguridad por obscuridad, dan como resultado un sistema totalmente expuesto ante ataques, que dejan comprometida toda la información del sistema, el sistema y el servidor en cuestión.

Saludos.

Lexer Pars.

Programación insegura y seguridad por obscuridad I

Programación insegura y seguridad por obscuridad II

Programación insegura y seguridad por obscuridad III

Programación insegura y seguridad por obscuridad IV

Conclusión Programación insegura y seguridad por obscuridad

Programación insegura y seguridad por obscuridad III

Para recapitular, hemos atacado por fuerza bruta, mediante xmlrpc, para obtener los nombres de las funciones de modelos y parámetros, con eso encontramos una función que nos permite ejecutar comandos directamente en el servidor, utilizando el usuario de Odoo.

Veremos como escalar privilegios, desde el usuario de Odoo, para ello, iniciaremos obteniendo el archivo  /etc/passwd.

Imagen 1: Comando cat /etc/passwd.

Al listar los usuarios, comprobamos que hay un usuario llamado postgres, lo cual nos da la pauta que la probabilidad que la base de datos este instalada en el mismo servidor, lo cual, no es recomendable, aunque falta comprobar que esto es cierto. Verificaremos el archivo de configuración ssh, el cual se encuentra en /etc/ssh/sshd_config, para verificar si hay una configuración que nos limite el uso de este servicio, en este caso, nos permite autenticarnos con una clave publica.

Imagen 2: Archivo de configuración servicio ssh.

Verificamos el archivo authorized_keys, para el usuario de odoo y confirmamos que hay una clave publica asignada.

Imagen 3: Clave publica ssh.

Procederemos a crear nuestra propia clave publica y privada, para autenticarnos al servidor. Con la clave publica, agregamos la clave publica al archivo authorized_key, mediante el comando echo public_key >> /home/odoo/.ssh/authorized_keys.

Imagen 4: Generación de clave publica y privada.

Imagen 5: Clave publica agregada al servidor.

Una vez realizado todo lo anterior, realizamos la conexión vía ssh al servidor, y confirmamos que ya tenemos acceso con el usuario odoo al servidor.

Imagen 6: Acceso a servidor mediante ssh, con usuario Odoo.

Una vez conseguido acceso al servidor, veremos a que mas recursos tenemos acceso en el servidor, así como escalar privilegios dentro del servidor, en la próxima entrada.

Saludos.

Lexer Pars.

Programación insegura y seguridad por obscuridad I

Programación insegura y seguridad por obscuridad II

Programación insegura y seguridad por obscuridad III

Programación insegura y seguridad por obscuridad IV

Conclusión Programación insegura y seguridad por obscuridad

Programación insegura y seguridad por obscuridad II

Es muy importante prepara un diccionario con nombres de funciones o métodos, una fuente para obtener estos nombres es github , una vez preparado el diccionario, procedemos a realizar el ataque de fuerza bruta. En mi caso prepare un diccionario con 12,341 posibles nombres de función, de esto, obtuve 12 nombres de funciones, como se puede visualizar en la siguiente imagen.

Imagen 1: Funciones encontradas por medio de fuerza bruta.

Una vez enumeradas las funciones, podremos proceder a realizar un ataque de fuerza bruta a cada una de las funciones, para saber la cantidad de parámetros que recibe cada función y el tipo de dato que recibe, por defecto, siempre reciben 1 parámetro (self), por lo tanto si la función recibe 1 parámetro por parte adicional, mostrara que recibe 2 parámetros, en este caso, solo tendremos que enviar 1 parámetro a la función, como se muestra a continuación.

Imagen 2: Función requiere parámetros, pero solo recibe self.

En mi caso las funciones encontradas son: ['write', 'search', 'read', 'get_dir', 'send_noti', '_noti', '_convert', 'save_disk_path', '_conn_ftp', 'validations', 'prepare_64', '_uni'] de las cuales, write, search,read, son nativas de odoo, es importante colocar funciones nativas, para confirmar que nuestro ataque se esta llevando acabo, las demás funciones, son propias del modulo. De todas las funciones propias del modulo, unicamente prepare_64 y save_disk_path reciben 1 parámetro adicional a self y de esas ultimas 2 save_disk_path no retorna absolutamente nada.

Al evaluar la ultima función, le enviamos un diccionario, y al fallar, nos refleja, un código posiblemente inseguro, el cual llama una funcion, llamada shell_bk, al tratarse de un modulo de copias de seguridad, quisiera imaginar, que lo usan, para almacenar copias en el mismo server, mediante la ejecución de comandos.

Imagen 3: Función con posible shell.

Llegados a este punto, veremos si es una función para correr algún comando, para ello, haremos un simple "whoami", y el resultado es, que logramos ejecutar el comando directamente.

Imagen 4: Ejecutando whoami.

Imagen 5: Listando directorio del servidor.

Por ultimo, trataremos de obtener acceso total al servidor, lo cual, lo veremos en una tercera parte.

Saludos.

Lexer Pars.

Programación insegura y seguridad por obscuridad I

Programación insegura y seguridad por obscuridad II

Programación insegura y seguridad por obscuridad III

Programación insegura y seguridad por obscuridad IV

Conclusión Programación insegura y seguridad por obscuridad

Programación insegura y seguridad por obscuridad I

En los últimos días y debo agregar, algunos años ya, he trabajado mucho con el sistema Odoo, el cual es muy amigable y robusto. Así que en lo que va del año encontraran muchas entradas relacionadas al tema, tanto en temas de defensa, así como ataque al sistema Odoo. Anteriormente en una serie de entradas, observamos una de las formas de "hackear odoo", esto basado en una mala implementación, políticas de contraseña débil, y mala gestión de accesos.

Sin embargo, con todo lo anterior, únicamente se ha visto comprometido el sistema Odoo, ya que, el sistema esta diseñado para hacer frente a las diversidad de ataques existentes, como ataques de inyección sql, robo de sesiones, ejecución remota de código, etc.

Todo esto esta muy, sin embargo, en muchas ocasiones los desarrolladores al momento de programar nuevos módulos para extender o crear nuevas funcionalidades al sistema, emplean código inseguro, el cual no es debidamente protegido, para que no pueda ser ejecutado por cualquier usuario y menos utilizando xmlrpc. 

A día de hoy, no se si existe un método o forma de listar todos los métodos disponibles para un modelo, desde xmlrpc, sin embargo, si existe una manera fácil de lista la mayoría de aplicaciones instaladas en una instancia de Odoo, para ello solo tienes que dirigirte a /website/info , como se muestra a continuación.

Imagen 1: Aplicaciones instaladas

La idea de tener esta información, es buscar las aplicaciones instaladas, ya que hay muchas aplicaciones de terceros que se pueden descargar de github o bien de la apps de odoo . Esto con el fin de tener todo el código fuente y explorar en busca de código inseguro. Si tienen el código, podrán tener acceso a todos los métodos de un modelo, que no estén protegidos de manera adecuada, al estar en un lenguaje como python, entenderlo es muy fácil, el siguiente código es un extracto, de una aplicacion de odoo, en la cual se puede observar el modelo account.move con algunos métodos disponibles.

Imagen 2: Código fuente, con métodos y modelo

Particularmente de todas las aplicaciones mostradas en la imagen 1, me llama la atención Backups online drive, sin embargo, este modulo a pesar de ser de terceros, es un modulo privado, puesto que al buscarlo por internet, no se encuentra el código fuente para descargarlo.

Al no disponer de código fuente, tendremos que realizar un ataque fuerza bruta, para adivinar que métodos están disponibles para un modelo, esto empleando xmlrpc, para ello tenemos que preparar un diccionario, con los posibles nombres de los métodos, que se nos ocurran, haya utilizado el o los desarrolladores, para un determinado modelo. Para ello podemos emplear la siguiente petición por medio de xmlrpc.

Imagen 3: Código para fuerza bruta de métodos.

Si el método no existe, recibiremos un mensaje como el siguiente

Imagen 4: El método no existe.

Si encontramos un método que exista, recibiremos un mensaje como a continuación.

Imagen 5: Método existe, error parámetros.

 

Cuando encontremos, si bien no todos los métodos, pero si un buen numero, faltara, de igual forma, adivinar la cantidad de parámetros que recibe dicho método, y si esto te parece poco, también hay que  adivinar el tipo de dato que recibe en cada parámetro., algún string, un entero, una lista, un diccionario, set o conjuntos, matrices, funciones, modelos, etc.

Imagen 6 : Fuerza bruta a tipo de dato recibido por método.

En la siguiente entrada veremos como, seguir realizando este ataque, y aprovechar la programación insegura para atacar Odoo.

Saludos.

Lexer Pars.

Programación insegura y seguridad por obscuridad I

Programación insegura y seguridad por obscuridad II

Programación insegura y seguridad por obscuridad III

Programación insegura y seguridad por obscuridad IV

Conclusión Programación insegura y seguridad por obscuridad

Atacando ERP Odoo - Conclusión

Durante las ultimas 4 entradas observamos una forma de atacar el sistema Odoo, sin embargo no es la única forma, pues, si bien no existe un numero grandes de exploits o vulnerabilidades conocidas que se puedan explotar, con algo de tiempo y dedicación se pueden encontrar y explotar.

Por ello, es importante que si tienes Odoo o cualquier otro sistema expuesto y de cara a internet, realices una auditoria de seguridad, con la cual puedas determinar que puntos son débiles, están mal implementados o representan un riesgo para tu empresa y tu información.

Además de la importancia de realizar un proceso de calidad sobre el código de los módulos instalados, ya que las malas practicas de desarrollo y la falta de evaluación de estos módulos, puede llevar a que publiques código que sea vulnerable a ataques que comprometan el sistema.

Otro hecho que cabe mencionar, es la importancia de orientar a los usuarios, utilizar contraseñas robustas que sean difícil de vulnerar y la implementación de mecanismos de autenticación de 2 factores. También es recomendable realizar un proceso de hardening tanto al sistema como al servidor.

Si estas interesado en realizar una auditoria a tu sistema o servidores o realizar un proceso de hardening , no dudes en ponerte en contacto conmigo,

Saludos,

LexerPars

Atacando ERP Odoo I

Atacando ERP Odoo II

Atacando ERP Odoo III

Atacando ERP Odoo IV

Atacando ERP Odoo - Conclusión 

Atacando ERP Odoo IV

Llegados a esta publicación, habremos obtenido un listado de usuarios en el sistema de Odoo. Con este listado de usuarios prepararemos un vector de ataque. Ya que disponemos de un método de autenticación,  podremos intentar hacer un ataque de fuerza bruta, para adivinar la clave de los usuarios en el sistema. Regularmente los usuarios utilizan claves simples de recordar, y los administradores de sistemas, en su mayoría, no fijan políticas de seguridad, para fijar contraseñas, de tal forma, que cumplan con un nivel de complejidad aceptado y no sean fáciles de adivinar, así como fijar una caducidad a las claves y no permitir usar contraseñas históricas.

Imagen 1: Obtención de clave para usuario interno.

Cabe mencionar, que el ataque de fuerza bruta, tardara en base a la complejidad de la clave fijada por el usuario, así mismo de la potencia del equipo. Una obtenido el usuario, procedemos a autenticarnos al sistema con el usuario interno, para verificar a que tenemos acceso con el nuevo usuario.

Imagen 2: Accediendo al sistema.

Imagen 3: Aplicaciones de Odoo, usuario interno.

Los modelos y vistas, así como los controladores, pueden limitarse por reglas de acceso, sin embargo, en muchas ocasiones muchos recursos están sin protección de lectura, incluso de escritura y en su mayoría, Odoo no te mostrada la información. Si embargo, para podemos jugar un poco el numero de acción. Las url están compuestas en su mayoría de esta forma: https://www.dominio.net/web#view_type=kanban&model=res.partner&action=814&menu_id=613 , action=814, es el numero de acción, cambiando numero podremos encontrar muchas cosas a las que visualmente seguramente no tendremos acceso.

Imagen 4: Contactos de Odoo - formato url action.

Si encuentras algo a lo que no tienes acceso, recibirás un error similar a este:

Imagen 5: Regla de seguridad, no permite acceder a recurso.

Odoo ofrece una manera fácil de localizar recursos, el cual se le conoce como buscador global, el cual lo localizas desde la vista principal de aplicación, buscas lo que necesitas, y te evitas algunos clicks, o te permite ubicar un recurso que no recordabas donde estaba ubicado, sin embargo, este no es útil al momento de ubicar recursos a los que no debes tener acceso, pero, si los tienes. Un ejemplo de esto, son los métodos de pago, si realizamos la búsqueda global, ocurrirá esto.

Imagen 6 : Búsqueda de métodos de pago por búsqueda global sin resultados.

Sin embargo al momento de realizar la búsqueda por medio de numero de acción, el resultado será completamente diferente.

Imagen 7: Búsqueda de métodos de pago por medio de action.

Imagen 8: Credenciales credomatic visibles y con permiso de escritura.

Continuando con la búsqueda de recursos, no protegidos, encontramos los parámetros del sistema, de estos, caben resaltar a mi criterio, usuario de base de datos, password de base de datos (estos se especifican en un archivo de configuración) que son usados por un modulo para hacer conexiones directas a la base de datos, el código enterprise de la empresa, ya que si este ultimo es utilizado en otra base de datos, pueden tener problemas, debido a que bloquean la base de datos, y esto no les permitirá operar con normalidad.

Imagen 9: Parámetros del sistema.

Imagen 10: Listado de usuarios.

Imagen 11: Cambiar clave de usuarios.

Dentro de las opciones disponibles, tenemos el poder cambiar las contraseñas de los clientes, así como exportar la información disponible.

Saludos,

LexerPars.

Atacando ERP Odoo I

Atacando ERP Odoo II

Atacando ERP Odoo III

Atacando ERP Odoo IV

Atacando ERP Odoo - Conclusión