Página 39 de 51

Xen: Migración de discos fisicos a discos virtuales (pt3)

quantum-bigfoot La migración de discos físicos a discos virtuales para poder montar una VM en Xen es, en teoría, fácil. Es simplemente hacer una copia con dd de las particiones que deseas. Hay que tener mucho cuidado, no debemos hacer una imágen del disco completo, sólo las particiones que deseamos, sin el sector 0 (mbr), ni tabla de particiones, etc. Tampoco recomiendo migrar la swap, es mejor crearla (en teoría demoraría menos).

Cuando se trata de máquinas de producción o servidores, lo que debemos hacer para no tener conflictos con las direcciones ip, hostnames, fstab o cualquier configuración especial que tenga esa máquina que de una u otra forma pueda generar conflictos, es montarla con loop y modificar las configuraciones directamente desde la imágen que creamos.
Los pasos a seguir (recomendados por mi) son:

  1. Determinar qué particiones son las que debemos migrar.
  2. Hace las imágenes correspondientes de cada partición.
  3. Configuración de la máquina virtual (crear el .cfg).
  4. Montar las particiones que podrían generar algún tipo de conflicto y modificar los archivos necesarios.
  5. Creación de la swap.
  6. Levantar la máquina.

Seguir leyendo

Cómo agregar una capa más de seguridad a un login

Un sistema de inicio de sesión tradicional funciona simplemente enviando, en texto plano, los datos de usuario y password al sistema en php o el lenguaje que sea, el sistema lo recibe, lo encripta y lo compara con la información de la base de datos para saber si es correcto o no. Lo que no está mal, pero deja abierta la posibilida de que alguien este sniffeando la red y capture los datos en bruto (raw) o texto plano.
Como podemos ver en el siguiente esquema:

secure-js1

Una forma que se me ocurrió para que los datos del formulario, especialmente la password, no viajarán en texto plano, fue encriptarla mediante javascript al momento de hacer el submit. De esta forma, cuando el atacante logre capturar los datos lo que verá es una cadena en md5, como aparece en el siguiente gráfico:

secure-js2

Seguir leyendo

¿Qué es una vulnerabilidad File/Path Disclosure?

Una vulnerabilidad del tipo File o Path Disclosure es cuando queda al descubierto la ruta de la aplicación o script en ejecución y de esta forma saber en que directorio especificamente se encuentra el sitio web. A simple vista parece ser inofensivo, pero cuando se necesita subir maliciosamente un archivo o descargar algo indevidamente, esto es muy útil.

disclosure

Esta vulnerabilidad corresponde a un error de programación al no atajar correctamente los errores o excepciones, por ejemplo, uno de los casos mas frecuentes se da con la famosa función include o requiere (en php):

  1. <?php
  2. include($_GET[‘section’].".php");
  3. ?>

Es muy común ver en sitios web como se pasa por parámetro la sección, algo similar a https://sitio.cl/index.php?section=contacto, entonces el script index.php recibe la variable “section”, le agrega la extension .php y la incluye, pero …

¿Qué pasa cuando cambiamos contacto por letras al azar como fdsghjk?
Fácil, la función include intentará incluir el archivo fdsghjk.php y como no existe, php mostrara un error parecido a Failed to open stream: No such file or directory in /home/web/public_html/index.php y con esto, ya tenemos la ruta donde se está ejecutando la aplicación: /home/web/public_html. De esta forma se nos facilita un ataque LFI o RFI.

IMPRESENTABLE: Gendarmeria expone su base de datos al público.

gendarmeria0

Así es, el sitio web de Gendarmedia en Chile, expone los datos de sus usuarios al público. Me parece muy mal que estas cosas sucedan en sitios del gobierno, deja mucho que desear en cuanto a la privacidad de la información y seguridad informática.
Me llama mucho la atención que cuando ingreso al sitio y voy a la sección de “Politica de Privacidad” donde podemos leer el siguiente mensaje:

gendarmeria1

Y por otro lado me encuentro con esto:

gendarmeria

Ademas de esta información, lo que se deja público son los correos o el mensaje que las personas dejan mediando los fomrularios de contácto del sitio web de Gendarmeria, además de todos los correos y nombres de las personas que utilizan este formulario de contacto.
Realmente lo encuentro vergonzoso.

Sitios vulnerables de la semana: 6

La semana pasada fue el turno de vulnerabildiades de tipo XSS, esta semana será una lista de sitios con vulnerabilidades RFI, XSS y SQL Injection. Los sitios o empresas afectados son:SQLInjection1

Ecored.cl
iti.cl (https)
stiport.cl (https)
Lucylafuenteindo.cl
latitud90.com
Maqval.cl

Con “Lucylafuenteindo.cl” intenté comunicarme para solucionar el problema pero luego de corregir parcialmente el problema ni se contactaron conmigo. Ecored.cl parece ser (o fue) una empresa de informatica bastante vieja, nose si aun utillizaran el sitio. Con los otros sitios estoy intentando contactarme.
Para leer mas detalladamente las fallas en cada uno de los sitios lea el articulo completo.

Seguir leyendo

Los clientes: Unos de los principales problemas de seguridad

A la hora de desarrollar a medida o implementar algún tipo de sistema para algún cliente, ya sea trabajando de forma independiente o para una empresa, el cliente (quien solicita el trabajo) se transforma en la principal amenaza de seguridad. Es muy común entre los desarrolladores recibir presiones, cambios a última hora, mejoras de “usabilidad” que atentan contra la seguridad, etc. Generalmente, cuando un cliente necesita algo, él piensa que todo es magia y comienza a apresurarnos, acortando el plazo y exigiendo features nuevas lo que nos pone a nosotros, los desarrolladores, en una situación muy crítica.
seginf1

En lo personal, me ha pasado que por evitar una falla de seguridad he
decidido hacer validaciones de formularios con 3 niveles, validación
por javascript, validación por php y validación a nivel de base de datos
y me he demorado 3 o 4 veces más de lo que me hubiese demorado si
hubiese dejado solo la validación por javascript, lo que permite, obvia-
mente, hacer un post directo sin pasar por el formulario y saltarse esa
validación.

Otro factor crítico es el tema del presupuesto, generalmente los clientes quieren todo por muy poco dinero y en muy poco tiempo y nosotros, al necesitar el dinero, aceptamos y, lo que empieza siendo un trabajo extra para ganar unaas monedas termina siendo un dolor de cabeza.

Si bien es cierto que los clientes en lo general son los que provocan este tipo de fallos, no hay que dejar de lado cuando se le encargan sistemas a personas que no están capacitadas, queines, para mi, representan un peligro mucho mayor que un cliente apresurado, pero creo que es menor frecuente.

Como conclusión, en estos temas informáticos, lamentablemente el cliente no siempre tiene la razón.
Como opinón propia, creo que cuando alguien logré ingresar a un sistema indevidamente se debería juzgar al desarrollador, por incompetente 🙂