Visual Basic 2008: Security Features

La vuelta de las vacas este año ha sido un poco más dura de lo habitual, es de esas veces donde desconectas del mundo de la Seguridad al 99% y olvidas casi casi a lo que te dedicas haciendo que el dia de vuelta te apetezca realizar Ctrl + Alt + Sup mental. Mientras que el año pasado aproveché para realizar “experimentos” de diversa índole en esta ocasión he tenido otras tareas. Por razones familiares tuve que crear una pequeña aplicación Cliente – Servidor para una clínica.

Haciendo flash—back recordé la agilidad con la que allá por el 2000 me desenvolvía en Visual Basic 5.0 y me dije, ¿Cuánto habrá podido cambiar? Y me decidí a bajarme el Visual Studio Express Edition, concretamente el Visual Basic (que ya va por la versión 9.0). Lo cierto es que no me llevé muchas sorpresas, en su esencia sigue siendo tremendamente cómodo, intuitivo y ágil. Eso sí, hay muchas novedades y utilidades para aplicar Seguridad desde los albores de un proyecto:

Permisos de aplicación: UAC

Dentro del explorador de soluciones en las propiedades del proyecto podemos cambiar los privilegios que requiera la aplicación así como las posibles llamadas al UAC. Como es obvio debemos tratar de trabajar con los menores de los permisos, así evitaremos por ejemplo que ante un “crash” de nuestra aplicación tiremos el sistema.

Código XML con el que definimos la seguridad UAC de la aplicación

Seguridad ClickONCE

Las aplicaciones que desarrollamos en VB se apoyan en la infraestructura .NET Framework y estarán sujetas a restricciones de código. Dentro de las propiedades del proyecto también podremos habilitar o deshabilitar restricciones según los permisos que requiera nuestro código, esto puede incluir transferencia de ficheros, cuadros de diálogo, permisos de impresión, generación de sockets, etc. etc.

Configurando permisos ClickONCE

Firma de Código: Generación de certificados

Es cierto, podremos garantizar a nuestros clientes que el software distribuido es nuestro a través de la firma digital. Para ello disponemos de una utilidad de generación de certificados que en cierta forma me recuerda al PGP y que a buen seguro aumentará la confianza a nuestros clientes:

Acceso a BBDD

También me ha llamado la atención la gestión de BBDD que hay disponible, si bien a priori podemos tirar “solo” de Microsoft Access y SQL Server (en el Wizard de Agregar Conexión), próximamente disponemos de opciones de autenticación de usuario al realizar las consultas, restringido eso sí a usuarios de SQL Server o de Windows (supongo que se podrán utilizar usuarios de Dominio, pero no lo he probado). También podremos crear y cifrar BBDD basadas en SQL Compact Server así como incluir o no en los argumentos de nuestras cadenas de conexión y consultas SQL el usuario y password con el que nos conectamos (no recomendable ya que viajará en claro).

Agregamos la cadena de conexión a nuestra BBDD

Creamos nuestra BBDD con el cifrado que permita la plataforma host.

Login Form

Todavía recuerdo esos viejos días en que independientemente del texto que introdujeras en el TextBox debías mostrar asteriscos para que ataques por shoulder surfing no fuesen un problema (algo que todavía no está limado del todo en plataformas como el Iphone [^^!]), en la última versión de VB tenemos los formularios predefinidos más comunes disponibles a un par de clicks (Proyecto à Agregar), entre ellos el Login Form, una gozada :D (que por supuesto he usado).

Formulario por defecto para hacer "Login"

Y tras haber trasteado con esta plataforma y tener casi terminada mi aplicación no he utilizado ni visto mucho más, aunque a buen seguro habrá muchas más opciones, solo hace falta explorar un poquito. La esencia de Visual Basic no ha variado un ápice en estos 9 años, sin embargo el abanico de facilidades no ha dejado de crecer (incluso para nosotros).

Salu2 y,,, ¡cuidado con la vuelta!

Database Hardening

Haz 100 flexiones más, 200 abdominales y da 15 vueltas al campo de fútbol.

Respuesta: Ufff, si que es difícil endurecer los servicios.

Todos sabemos que donde nosotros vemos ladrillos, medidas de seguridad, obstáculos a saltar, etc. Los chicos malos ven grietas, agujeros y facilidades, después de casi un año leyendo estas líneas creo que no os sorprendo si digo que no hay ninguna medida de seguridad o herramienta que sea la panacea, así que la única solución es utilizar varias de ellas que trabajen codo con codo con un objetivo común. La estrategia utilizada para que todo esto funcione como un engranaje se llama “defensa en profundidad”, y ya la utilizaban los militares en la 2ª Guerra Mundial y posiblemente, mucho antes.

¿Cuál es la profundidad aquí? Pues hay muchas y depende de cómo se mire, pero nosotros lo vamos a llamar arquitectura multicapa (frontend – middleware – backend). Si ponemos un nuevo servicio en producción, es lógico y normal que hagamos “hardening” del mismo, eso se suele traducir en bastionar el equipo, eliminar usuarios y contraseñas por defecto, deshabilitar servicios innecesarios, configurar control de acceso, etc. etc. Todo esto está bien pero, ¿qué pasa con las otras capas? Estamos dando por sentado que nadie pasará la frontera de Bélgica y holanda, pero esto ya les pasó a los franceses y ya sabéis como acabó .

Hoy vamos a hacer hardening del backend y vamos a ver cómo nunca tenemos que perder de vista los datos, el verdadero foco de la cuestión. Redactar todas las cositas que hay que mirar en un backend puede ser un checklist bastante extenso que seguramente no aporte mucho, casi todos los sistemas tienen sus checklist publicados, ya sea vía proveedor, vía NIST, etc. Lo que vamos a hacer es concentrarnos en tres cosas:

-   Detectar fallos de configuración (cuentas por defecto, servicios innecesarios, etc.)

-   Detectar vulnerabilidades software (no hay una política de “critical path update”)

-   Detectar mal uso (cuenta de administrador compartida por varios usuarios, consultas al backend con excesivos privilegios).

Existen herramientas para automatizar estos análisis especializadas en bases de datos como son AppDetective o NGSSQuirrel, la diferencia de los escáneres tradicionales con estos radica en la especialización, si bien un Nessus te detectará vulnerabilidades de todo tipo en dispositivos de red, servidores, Workstation, etc. nunca podrá realizar exámenes tan exhaustivos como por ejemplo Nikto hace con servidores web o AppDetective con una base de datos. Pero no solo de escáneres vive el Consultor, aunque con ellos y nuestro conocimiento (valor añadido) podremos comenzar a detectar fallos y recomendar medidas de hardening.

Medidas adicionales que nos ayudarán a mantener todo securizado (la seguridad es un proceso, recordemos) será habilitar un detector de cambios en la configuración, para ello tenemos herramientas como Intrust de Quest Software (que ya nos contó Carles Matin) o algunas más sencillas como habilitar las opciones de auditoria de SQL Server (si es esa nuestra BBDD).

Finalmente tenemos los datos, el quiz de la cuestión, toda la estrategia “defense in depth” se basa en este tesoro que puede ser expuesto a pesar de todo lo dicho hasta ahora. Una puerta trasera, una copia no autorizada, una migración de backend, unas pruebas desde otros entornos como certificación, desarrollo, etc. y ya tenemos nuestra temida fuga de datos. La principal medida en estos casos pasa por hacer lo que en el CISSP llamaban “Data Sanization” y que se traduce en preparar esos datos sensibles para que no pierdan su estructura (claves foráneas, atributos, tablas relacionales, etc.) y sin embargo no se puedan entender o pierdan su significado, es decir, ofuscar los datos. Para ello me he guardado en último lugar una herramienta que descubrí hace unos días, se llama Data Masker y tiene una funcionalidad interesante. Permite conectarse a las bases de datos, obtener su estructura, crear reglas de ofuscado, ejecutarlas, etc:

DataMasker: Autenticación en las conexiones.

DataMasker: Tablas de ejemplo para jugar.

Y esto es todo por hoy, recordad, proteger el frontend está muy bien pero...¡el foco siempre en los datos!

Salu2