AutorZerial

Xen: Instalación y configuración (pt1)

Esta es la primera parte de una serie de artículos que escribiré sobre cómo configurar y usar Xen, crear y administrar máquinas virtuales, clonación y migración, asignación de procesadores, memoria y configuración de la red entre otras cosas.
Aunque soy usuario de Archlinux, los servidores que administro están bajo Debian, por lo que estos tutoriales los haré en base a esa distribución.

A continuación, una serie de instrucciones de cómo instalar y dejar corriendo Xen en la máquina servidor en sencillos pasos:

Debemos instalar el kernel correspondiente y las utilidades de xen. Lo hacemos todo con el siguiente comando:

apt-get install xm-utils-common xen-linux-system-2.6.26-2-xen-686 linux-image-2.6.26-2-xen-686

Se van a instalar automáticamente las dependencias y otras utilidades que se necesiten.
Reiniciamos y booteamos con el kernel correspondiente: Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-2-xen-686

Hay que fijarse que se instalaron dos: linux-image y xen-linux-system. El primero se usará para que las máquinas guest booteen y el segundo para el domU.

Cuando ya hayamos iniciado con xen-linux-system, debemos editar el fichero /etc/xen/xend-config.sxp. Vamos a la linea donde configuramos la red, debe aparecer algo como “(network-script network-dummy)” y debemos cambiarlo por “(network-script network-bridge)“. Cuando intentemos crear nuestra primera máquina virtual, xen nos enviará un mensaje advirtiendo que debemos configurar esa linea en el fichero de configuración.

Eso es todo.

Vulnerabilidades más comunes en los sitios web

Estamos en el año 2009 y es increible que existiendo tantas herramientas de auditoría y el peligro/riesgo que existe por el mal tratamiento de la información, los desarrolladores esten cayendo en errores tan básicos.

Voy a listar las vulnerabilidades que, según mi experiencia, son las más comunes en los sitios web.

  • File/Path Disclosure: Esta vulnerabilidad es más comun de lo que uno pueda imaginar, aunque generalmente para poder llegar a explotarla es necesario pasar algun sistema de autentificacion ya que es muy comun en sistemas donde los usuarios tienen acceso a descargar o subir información como un sitio de una Universidad, biblioteca, intranet, etc.
  • XSS (Cross-Site Scripting): Esta vulnerabilidad tambien es muy comun, aunque es un poco mas compleja de explotar, requiere conocimiento en javascript, manejos de cookies y un poco de experiencia en el tema. Con esta vulnerabilidad es posible robar cookies para ingresar a algun sistema autentificado con un usuario ajeno.
  • SQL Injection: Hace un tiempo fue el boom de esta vulnerabilidad, muchos sitios tenian fallos de este tipo. Estuvo de moda explotar vulnerabilidades de phpnuke o phpbb basadas en SQL Injection que nos permitian escalacion de privilegios. Esta tecnica consiste basicamente en manipular una consulta sql para lograr nuestro proposito como saber nombre de tablas, version de la base de datos y tambien manipular ingresos de datos a la base de datos para modificar campos de tablas, crear archivos, cambiar privilegios, etc.
  • Authentication bypass:  Desde mi punto de vista, esta vulnerabilidad, bug o fallo es uno de los mas estupidos que un programador/desarrollador puede cometer. Para hacer un login es necesario manejarse con el tema de cookies o sesiones, segun el lenguaje o las necesidades y cuando una persona sin estos conocimientos intenta hacer un codigo de autentificacion sucede lo peor. El caso mas comun y sencillo de este tipo de fallo es saltarse el login haciendo un cambio en la URL. Por ejemplo, tenemos https://example.com/login.php y nos damos cuenta que ese login.php hace un POST con nuestros datos a https://example.com/admin/valida.php, luego, sin ingresar ningun usuario ni password escribimos manualmente la url https://example.com/admin y sorpresa! estamos en el sitio de admin sin usuario pass ni nada, habiendonos saltado el login. Aunque no lo crean, es bastante comun.

Validar correctamente la subida de un archivo con php

Cuando nos enfrentamos a esta situación se nos viene a la cabeza distintas formas de querer validar un fichero, según sea la necesidad; por tamaño, extension, etc.
Lo que voy a explicar es como realizar la una validación correcta y eficiente del tipo de archivo que se está subiendo y aprovecho de explicar tambien la importancia de realizar bien esta validación.

Antes que todo, hay que tener en claro como funciona esto de la subida de archivos y tener en mente que la validación se puede y debe hacerse a nivel de cliente y a nivel de servidor. Muchas veces me he enfrentado a situaciones donde el desarrollador solo hace la validación a nivel de cliente, en javascript. Por ejemplo, así:

  1. <script>
  2. function validar(archivo){
  3.    var b = archivo.split(‘.’);
  4.    if(b[b.length-1] == ‘txt’)
  5.       return true;
  6.    else{
  7.       alert(‘Error: El archivo debe ser .txt’);
  8.       return false;
  9.    }
  10. }</script>

Si llamamos a esa función pasando como parámetro archivo.txt no mostrara ningún error, de lo contrario, si pasamos otro argumento como pelicula.avi devolverá error y no nos dejará continuar.
Este tipo de validación es el menos eficiente, ya que realizar una petición por POST sin pasar por el formulario es algo muy simple, basta con tener las herramientas necesarias como por ejemplo curl.
Hay que dejar en claro que el hecho de validar un formulario unicamente en javascript es una gran irresponsabilidad, ya sea la validación de unos simples datos como los típicos nombres, apellidos, email hasta la subida de archivos. El realizar una validación por javascript nos entrega una capa más de seguridad, pero no la única.

Seguir leyendo

TryWho y el susto de los Chilenos

Hace días que vengo leyendo tweets, informaciones en blogs y sitios de noticias sobre el nuevo sistema de lucro mediante la información pública y privada de las personas. Lo que más me llama la atención es la poca información (por no decir ignorancia) de la gente que se asombró con esto, siendo que son ellos mismos quienes no se encargan de proteger su información, como lo expliqué en un post anterior.

Estoy trabajando en un artículo dónde demostraré muchas falencias en los sitemas de información en Chile, no queria quedarme sin dar mi opinion respecto a lo que se habla, mucho menos ahora que tambien se esta hablando de una posible modificacion en alguna ley de protección de datos.

Links relacionados:

Información sensible expuesta publicamente en la UCV

Al igual que en el post anterior, que hablaba sobre la vulnerabilidad en uno de los sitios de la Universidad de Chile, esta vez es el turno de la Universidad Catolica de Valparaiso (UCV), especificamente el campus virtual.

Al parecer el sitio estaba en mantenimiento ya que me encontre con varios mensajes que del tipo “Este sitio esta en mantencion“, pero esto no es excusa. Dejar un directorio que contiene informacion sensible de clientes, empleados, empresa, alumnos, etc no puede estar publicado en internet con permisos de listar directorio habilitado. Existen varias formas de proteger el contenido de un directorio desde la configuracion del fichero .htaccess hasta algo tan simple como el crear un index.php|html|htm vacios, sin dejar de lado que se puede hacer agregado reglas de acceso a la configuracion del dominio.

Bueno, encontré un directorio con información sensible de alumnos de esa Universidad, quizas la informacion es un poco antigua pero que importa eso si ni el nombre ni el rut de las personas cambia. Intenté comunicar con la webmaster del sitio pero no obtuve respuesta.

En este caso, se han expuesto en internet datos de aproximadamente 2000 alumnos.


Informacion hecha publica por la UCV

Informacion hecha publica por la UCV

En esa imagen podemos ver un poco de la informacion que aparece en el directorio vulnerable. Es un fichero separado por gatos (###) donde podemos ver que lo mas interesante son las columnas 3, 4, 5 y 6 que corresponden al rut, nombre completo de la persona, nombre de usuario y password respectivamente.

Seguir leyendo

Vulnerabilidad en un sitio de la Universidad de Chile

Se trata del sitio de la biblioteca virtual de la Facultad de Economia y Negocios (FEN) de la Universidad de Chile. Hace un par de dias descubri una vulnerabilidad del tipo path disclosure en https://bibliodoc.fen.uchile.cl.

La forma de explotar este fallo era iniciar sesion con cualquier usuario y buscar algun documento, cuando acercabamos el mouse hacia el link podiamos ver:

uchile-path

Si modificabamos ese link, remplazando documento para descargar.pdf por alguna ruta a un archivo de sistema, podremos descargarlo. Por ejemplo

uchile-path1

Con ../../../../ nos aseguramos retroceder lo suficiente para llegar a la raiz y con /etc/passwd le decimos al script download.php que nos entregue el fichero passwd, que guarda la informacion de usuarios de sistema. Obteniendo lo siguiente:

uchile-path2

Dias despues de explotar y confirmar esta vulnerabilidad, me di el trabajo de comunicarles a los de soporte de ese sitio sobre este fallo obteniendo una respuesta en poco tiempo. Estaban muy agradecidos por haberles comunicado el problema. En unos minutos me agrego a gtalk/jabber el desarrollador del portal y me hizo unas preguntas, para saber como habia logrado explotar esa vulnerabilidad y en que consistia y, luego de haberle respondido algunas preguntas y haberlo ayudado, rapidamente solucionó el problema.

Las vulnerabilidades de tipo file/path disclosure son aquellas donde de alguna u otra forma podemos acceder a archivos del sistema que estan fuera del path de la web, como en este caso, por ejemplo si la web hubiese estado en /var/www/bibliodoc, mediante este bug pudimos acceder a un archivo ubicado en /etc/ que, claramente, esta fuera del directorio.