Club Builder

[JesúsGandia]

Seguridad en Interbase.

Resulta que cuando instalas Interbase, se instala un fichero llamado “admin.ib” el cual es una base de datos de interbase que guarda los usuarios del servidor, incluido “SYSDBA” con sus contraseñas. Y claro mi pregunta es: Si yo vendo un programa a un usuario con base de datos de Interbase, el podría tener Interbase en su ordenador o peor todavía podría tener el archivo “admin.ib” con su contraseña y pudiendo copiar su fichero sobre el mío ya podría acceder a mi base de datos.

PREGUNTAS:

1.- ¿Esto no es un error de seguridad?
2.- ¿Cómo se puede solucionar para que el usuario no manipule o copie este fichero?
3.- ¿Os habíais planteado este tema anteriormente?
4-. ¿Es correcto mi planteamiento?

Me he quedado sorprendido al ver que este fichero lo puedo manipular sin problemas y he hecho la siguiente prueba:

1. Abro el “IBConsole” que inicialmente tiene el (USUARIO: SYSDBA, password: masterkey).
2. Compruebo que el usuario es SYSDBA y la clave “masterkey”.
3. Cierro el IBConsole.
4. Copio con otro nombre el fichero “admin.ib”, por ejemplo a “admin1.ib”
5. Vuelvo a entrar al IBConsole.
6. Cambio la contraseña.
7. Cierro el IBConsole.
8. Vuelvo a abrir el IBConsole y compruebo que solo puedo entrar con mi nueva contraseña.
9. Creo mi Base de Datos, supuestamente protegida por contraseña.
10. Cierro otra ver el IBConsole.
11. Borro el fichero “admin.ib”.
12. Renombro el fichero ”admin1.ib”, que previamente había copiado a “admin.ib”
13. Vuelvo a abrir el IBConsole y veo que, no solo puedo abrirlo con SYSDBA y “masterkey”, sino que además puedo ver todas las bases de datos que antes creé.


Después de esto, me he quedado súper sorprendido. ¿Como es posible que sea tan fácil ver los datos de mi Base de Datos?

Por favor díganme que opinan de esto pues estoy un poco traumatizado, ya que yo creía que Interbase era muy… muy… segura.


TEXTO EN EL LIBRO “La Cara Oculta de C++ Builder"

El sistema de seguridad explicado tiene un par de aparentes "fallos". En primer
lugar, cualquier usuario con acceso al disco duro puede sustituir el fichero isc4.gdb
con uno suyo. Más grave aún: si copiamos el fichero gdb de la base de datos en un
servidor en el cual conozcamos la contraseña del administrador, tendremos acceso
total a los datos, aunque este acceso nos hubiera estado vedado en el servidor original.
En realidad, el fallo consiste en permitir que cualquier mequetrefe pueda acceder
a nuestras apreciadas bases de datos. Así que, antes de planear la protección del
sistema de gestión de base de datos (ya sea InterBase o cualquier otro), ocúpese de
controlar el acceso al servidor de la gente indeseable.

PREGUNTA:

Como controlo el acceso al servidor de la gente indeseable o al fichero isc4.gdb o al fichero admin.ib


OTRA CUESTION: Texto sacado del libro “MICROSCOPE”

LOS DISCOS LLAVE
Tal y como prometí anteriormente, y para que ya no haya excusa alguna para poner virus en los programas, salvo mente criminal, aquí propongo todos los algoritmos y el código necesario para hacer un disquete incopiable, así como para proteger de copia las instalaciones de nuestros programas que hagamos sobre Discos Duros.
Existen algunas Empresas de Software que utilizan el método del Disco Llave para proteger sus programas, y con mucho éxito, lo que nos da pié para pensar que quién no usa ese sistema anticopia es porque no lo conoce. Básicamente consiste en instalar la aplicación sobre Disco Duro y cada vez que el usuario quiere usar ese programa, es requerido para que inserte en la disquetera el disquete llave a fin de comprobar que tiene la copia original.
Esto es engorroso para los usuarios. Trataremos de paliar ese inconveniente. Un Disco Llave funciona de la siguiente manera: en su Directorio suele tener una o varias entradas bien con el atributo de oculto y sólo lectura, bien con el primer carácter del nombre puesto a E5H, que lo convierte en entrada borrada. En este segundo caso el programa no está borrado del disco, y todas sus entradas en la FAT están activadas como las de un programa normal, con lo cual podemos llamarlo y ejecutarlo con toda normalidad. Si tenéis a mano alguno de estos discos llave, analizadlo con la opción DIRECTORIO LARGO de MICROSCOPE y veréis como en el primer Cluster os dice que es irrecuperable porque tiene sobrescritos los restantes, señal inequívoca de que esas entradas de la FAT no están puestas a cero como correspondería a un fichero borrado. Además que ninguna Empresa en su sano juicio distribuye sus programas en disquetes usados y sin limpiar.


PREGUNTA SOBRE ESTE TEXTO:
¿Cómo pongo el primer carácter de un archivo o directorio a E5H, para convertirlo en entrada borrada?
_________________
Muchos hombres no se equivocan jamás porque no se proponen nada razonable.

[Cesar C. Salazar Gonzalez]

Me parece interesante la observacion, ya que muchos de nosotros tambien nos hemos dado cuenta, en mi caso, he resuelto, asignando seguridad al usuario, asi mismo estableciendo, un codigo dentro de mi programa, verificando que cada vez que encuentra la clave masterkey, la cambien por la clave que me perimta, yo uso FireBird, y en un momento me preocupó, lo mismo, si alguien tiene o a sufrido, algo similar seria bueno comentarlo.

no intentamos hackear o cracker a Interbase o FireBird, simplemente se buscan soluciones. dentro del foro, se han dejando muchos en enlaces que de una u otra manera, hablan de lo mismo.

Saludos.
_________________

[Touchsoftwares]

Deberiamos analizarlo con mas profundidad, recordemos que una base de datos "seria" no esta pensada para funcionar como una base de datos de escritorio.

Es decir si antes nosotros con dbase,fox o paradox teniamos las tablas "disponibles", directorios a la mano con el explorer o con comandos DOS.

Ahora bien, mysql, oracle, firebird etc etc, "deberiamos" acceder a ellas a travez de la red y no tener acceso a los directorios del servidor.

Asi que no lo veo como una falla de seguridad , mas bien esta diseñada en unenfoque diferente

espero haber sido claro

Por otro lado para modificar las entradas en hexadecimal, puedes usar el DEBUG que viene con el SO, o usar alguna herramienta de disco, norton disk , QUEST etc etc

Saludos
_________________
Ing. Gabriel Góngora Navarrete
TouchSoftwares Inc

http://www.touchsoftwares.com

[Buildero]

Estoy de acuerdo con Touchsoftwares, mas que una falla de seguridad el problema esta en el enfoque con que fue diseñada.

Entiendo la preocupación de JesúsGandia, lo ultimo que deseamos como desarrolladores es que los usuarios tengan acceso a la base de datos y si a esto le aumentas que parte de tu lógica va implicita a través de procedimientos almacenados y disparadores.....pues imaginense sería "facil" tratar de "piratearse" algo de código de los procesos que se ven implicados.

Tengo el caso de un programa demo que baje de Internet, utiliza Interbase y no tuve problemas en ver sus tablas, disparadores y procedimientos almacenados.

Hasta el momento no sé si se este trabajando sobre este asunto... pero es algo que nos debe preocupar, sobre todo para proteger parte de nuestro código.

Saludos
_________________
Quien hace una pregunta teme parecer un ignorante durante cinco minutos, quien no pregunta se mantiene ignorante toda la vida.

[TJOSE]

yo tambien estoy de acuerdo con Touchsoftwares. Tengo intalado, en una cooperativa, firebird y la base queda oculta para los usuarios, esta reside en el servidor, por tanto esta protegida. De todas formas para el caso que planteas una solucion esta dada en este link:

http://www.clubdelphi.com/vertruco.php?id=350

se borra el codigo fuente de los triggers y procedure (estos seguiran funcionando dado que ya estan compilados). Lo que no se puede evitar es que puedan ver la estructutra de tus tablas.

Saludos
TJose