| Arador | ok, nuestro proximo conferenciante es Seth Arnold |
|---|
| Arador | Trabaja como investigador y experto de seguridad desde los EEUU |
|---|
| Arador | trabaja en Wirex, y esta envuelto en el desarrollo de la distribucion Inmunix |
|---|
| Arador | tambien esta involucrado enla organizacion de esta conferencia |
|---|
| Arador | Sin el esta conferencia habria sido muy distintza |
|---|
| Arador | ba a hablar sobbre un proyecto interesante sobre auditoria de seguridad |
|---|
| Arador | codigo abierto : "Sardoniz: haciendo la mayoria de nuestro open source" |
|---|
| Arador | Gracias a el por preparar esta chrla sonre este interesante tema y a todos por venir |
|---|
| Arador | Mr. Arnold.... |
|---|
| Arador | <sarnlod> gracias fernado |
|---|
| Arador | las preguntas van en #qc |
|---|
| Arador | sentiros libres de preguntar en cualquier momento :) |
|---|
| Arador | querria agradecer a los traductores su trabajo |
|---|
| Arador | me gustaria empezar diciendo |
|---|
| Arador | que no quiero noesautorizar a RMS cuando hablo de codigo abierto |
|---|
| Arador | creo que dice muchas cosas buenas, incluso si irritantes a veces ;) |
|---|
| Arador | pero no quiero decir nada especifrico por "codigo abierto" contra "codigo libre" |
|---|
| Arador | hay una anotacion: "con suficientes ojos, todos los bugs son superficiales" |
|---|
| Arador | ha sido atribuido a linus torvalds y eric s raymond |
|---|
| Arador | quizas los dos lo han dicho :) |
|---|
| Arador | pero el problema es que _no hay_ suficientes ojos |
|---|
| Arador | la amyoria del software en el que creemos no ha sido propiamente auditado |
|---|
| Arador | buena parte ha sido escrito por entusiastas para divertirse |
|---|
| viZard | esto es maravilloso -- --- excepto porq, los programadores cometen errores y sin una infraestructura para intentar corregir esos errores pueden convertirse en serios problemas. |
|---|
| viZard | hay _algunos_ proyectos organizados de auditacion, como el projecto OpenBSD, Solar Designer's Openwall, y los equipos de seguridad de SuSE y Caldera |
|---|
| viZard | sin embargo, los equipos de seguridad de caldera y suse han camiado drásticamente.... |
|---|
| viZard | ellos ya no invierten tanto tiempo para auditar como antes |
|---|
| viZard | < tarzeau:#qc> y qué de debian? y el hurd? |
|---|
| Arador | < tarzeau:#qc> y debian? y hurd? |
|---|
| Arador | tarzeau: debian tiene un equipo de seguridad activo, que yo sepa, es orientados principalmente a la respuesta -- meter a los desarrolladores de paquetes en el arreglo de bugs |
|---|
| viZard | tarzeau: debian tiene un equipo de seguridad activo; pero a mi entender, ellos están orientados a modo de respuesta--- manteniendo los parches de seguridad al día. |
|---|
| viZard | tarzeau: a mi entender, el proyecto hurd no hace auditoría de nada. talvez lo hacen. no sé. |
|---|
| viZard | < rene:#qc> y microsoft? :) |
|---|
| viZard | rene: microsoft está moviéndose hace C#, lo que puede reflejar enormes ventajas de seguridad con el tiempo. |
|---|
| viZard | rene: pero el problema más grande de microsoft es su enorme complejidad |
|---|
| raul | rene: de cualquier forma microsoft puede afrontar el contratar miles y miles de programadores para que simplemente lean el codigo fuente y encuentren vulenerabilidades... quizas hay contratados un grupo para haer especificamente eso en su ultimo intento de hacerlos seguros, la comunidad opensource no puede afrontar elc ontratar a docenas de programadores que checkeen el trabajo de otros. |
|---|
| raul | volvamos de nuevo a sardonix! :) |
|---|
| raul | ña fierza de la comunidad opensource es que mucha gente hace suyos los programas que usa cada dia |
|---|
| raul | fernand0:#qc> hay otro problema: auditar el codigo no es facil |
|---|
| raul | fernand0 lo ha entendido. |
|---|
| raul | los programadores se han acostumbrado durante año a usar metodos inseguros de programacion y muchos errores son muy sutiles |
|---|
| raul | sin embargo, cuando alguien como Al viro le echa un vistazo a un codigo fuente, _cualqueir codigo fuente_, durante 5 minutos, el es capaz de encontrar fallos |
|---|
| raul | Al vrio es unico, pero no necesariametne en una moda que no pueda ser seguida |
|---|
| raul | que cualqueira pueda encontrar bugs asi de arpido significa que tenemos un camino a seguir |
|---|
| raul | necesitamos un metodo para animar a la gente a encontrar bugs |
|---|
| raul | y hacerlo asi con un metod que no implique gastar un monton de dinero |
|---|
| raul | mi jefe, Crispin Cowan, ha estado influenciado por slashdot durante años |
|---|
| raul | mas especialmente, como la gente gasta _un monton_ de tiempo intentando aumentar "puntos de karma" en sus envios |
|---|
| Arador | sardonix nacio |
|---|
| Arador | la idea es simple: hacer un repositorio para almacenar auditorias de seguridad |
|---|
| raul | la gente se sale de su camino para escribir utiles y incitantes comentarios, porque seran moderados alto, y un historial consistente de comentarios utiles es un reclamo |
|---|
| Arador | atar las auditorias fuertemente a los auditores, y podemos producir puntuaciones de como los auditores trabajan |
|---|
| Arador | teniendo semejante sistema de puntuacion, podriamos ayudar a los auditores a mirar al software y ser precisos en sus auditorias |
|---|
| Arador | < rene:#qc> sarnold: especificamente al open software creo que hay otro problema. Algunaes veces cuando encuentro un bug, no lo reporto porque lo estaba arreglando yo mismo ( tengo el codigo fuente despues de todo..) meterse demasiado en eso, atascarse a mitad de camino, y dejarlo tirado |
|---|
| Arador | rene: si, hay esta el problema |
|---|
| Arador | rene: aunque quizas la solucion simple es reportar primero el bug a alguien, y entonces despues intentar parchearlo |
|---|
| Arador | rene: de esa manera, si produces un parche, sera probado (siempre un plus) y la gente recibira mejor tus reportes de bug en el futuro :) |
|---|
| Arador | < jose_n:#qc> putua tambien sardonix a los distribuidores? por ejemplo: "-a no responde", o "+5 rapida respuesta, trabajo bien con la comunidad para arreglarlo" |
|---|
| Arador | jose_n: actualmente no; para ser honesto, la puntuacion no funciona del todo bien todavia ;) |
|---|
| Arador | jose_n: aunque tenemos planes de puntuar programas especificos con respecto a sus historiales de bugs |
|---|
| Arador | jose_n: La idea es, el sistema de puntuacion de karma de slashdot es casi todo automatico. Nos gustaria que sardoniz fuera enteramente automatico.....puntuar basandonos en la respuesta complicaria los problemas un poco, pero probablmente merece la pena investigar ;) |
|---|
| Arador | < docelic:#qc> deberia ponerse un monton de esfuerzo en avisar a los programadoes existentes/nuevos en como escribir codigo con al menos algunos aspectos de seguridad en mente (en adiccion a solamente trabajar en arreglar los bugs que alguien hizo en algun momento del pasado) |
|---|
| Arador | docelic: sinceramente estoy de acuerdo, mi propia experiencia educativa me muestra que esas cosas de seguridad no se tocan en la escuela |
|---|
| Arador | docelic: uno de mis profesores era incapaz? de ver una condicion de carrera en accion -- imagina que si ella fuera a estar programando software que no aceptara carcateres no previstos? el resultado no seria bueno |
|---|
| Arador | docelic: como jose_n apunto, esto no es por falta de recursos -- es en parte, porque la insdutria del software esta mas basada en las nuevas caracteristicas que en la fabilidad |
|---|
| Arador | docelic: asique eneñar a los pprofesores a escribir codigo rapidamente ha sido mas importante que enseñar a los profesores a escribir codigo correctamente |
|---|
| Arador | docelic: con las consecuencias esperadas ;) |
|---|
| Arador | < fernand0:#qc> hay otro problema: auditar codigo no es facil |
|---|
| Arador | fernand0 dria no saber esto cuando lo dijo (quizas lo sabia ;) pero porbar codigo que no tiene fallos de seguridad es un problema insalvable |
|---|
| raul | ha sido probado que asegurarse que el código no tenga fallas en él isomórfo (tiene el mismo problema que) resolver el problema del Manto de Turín. |
|---|
| raul | < riel:#qc> sarnold: un problema que he estado viendo es que la gente copia código con fallas de seguridad de los libros y ejemplos en línea. ¿Sabes si existe algún esfuerzo para auditar material educativo para fallas de seguridad? |
|---|
| raul | riel, no conozco proyecto alguno; sería muy difícil bajo algunas circunstancias, como existen cientos de libros de programación con errores depresivamente largos (y obvios), |
|---|
| raul | las fallas de seguridad en los mismos, usando funciones no segurar... y prácticamente cada página de un (popular) libro que tengo, está lleno de fallas de seguridad. |
|---|
| raul | riel: ambos, jose_n y yo, hemos apuntado anotaciones en ejemplos de codigo en revistas sobre linux; ambos escribimos quejas a los editores, pero esto era duro. |
|---|
| raul | < fork:#qc> No será ese que Stevens estuvo pagando para que se sacaran los errores de su libro? |
|---|
| viZard | fork: no recuerdo que stevens haya estado pagando específicamente por errores; knuth ofreció una recompensa de $2.56 por error hallado por la primera persona en reportar un error, sin embargo dudo que alguien _realmente_ haya cobrado esos cheques. |
|---|
| viZard | Dado que la audotoría de código s difícil, ningún auditor hallará todos las fallas; así que necesitamos alentar a _muchas_ personas a auditar software, y esperemos que todos juntos, podamos encontrar la mayoría de ellas. |
|---|
| viZard | y, parte de sardonix es el aspecto de investigación: ver si _podemos_ alentar a gente para que audite software proviendo la carroza proverbial, y esperemos que los "putos del karma" se unan a la causa. :) |
|---|
| viZard | < docelic:#qc> concerniente a los fallos en ejemplos en línea y/o libros... talvez algunas personas pueda ofrecerse de voluntario en sardonix para auditar el código que se publicará.... |
|---|
| viZard | docelic: esa es una gran idea. Creo que debemos ponernos en contacto con una gran editora y ver que podemos hacer |
|---|
| viZard | < tarzeau:#qc> a veces la programación segura no es tan importante.... |
|---|
| viZard | < tarzeau:#qc> o no existe una diferencia entre la frontera entre lo seguro y los fallado |
|---|
| viZard | tarzeau: Iván Arce, de CORE-SDI tiene una folosofía maravillosa: "rendimiento es cuando los programas hacen lo que deben hacer; seguridad es cuando los programas hacen lo que deben, nada mas" |
|---|
| viZard | tarzeau: y tienes razón, ése tipo de software no necesita reaalmente ser seguro |
|---|
| Arador | los juegos son un ejemplo popular |
|---|
| Arador | tarzeau: a pesar de eso, muchos sistemas han sido comprometidos por juegos --- cualqueir caballo de trolla que instale cuentas nuevas con privilegios nivel-root cuando se ejecuta por un administrador del sistema, o cuyo fichero |
|---|
| Arador | de "maxima puntuacion" pueda ser usado para explotar el sistema |
|---|
| Arador | tarzeau: algunos juegos, como el quake, pueden funcionar en una red -- y cualquier usuario de la red puede enviar al quake alguna entrada pobremente formateada y provocar que este ejecute otro codigo |
|---|
| Arador | tarzeau: aunque algunos programas no necesiten ser programados de forma segura, si ellos aceptan cualquier entrada de fuentes que no han sido verificadas completamente, ellos necesitan ser programados pensando en la seguridad. |
|---|
| Arador | < Borja:#qc> De echo, las maquinas de juegos pueden ser una excelente artilleria de zombies para hacer ataques DOS. |
|---|
| Arador | Borja: si :) esto es porque los juegos necesitan ser programados pensando en la seguridad |
|---|
| Arador | tarzeau: en general, solo empezar con una programacion defensiva es todo lo que se necesita para escribir un software seguro |
|---|
| Arador | tarzeau: debe de estar en mente, con cada funcion, "como podia ir esto mal si alguien lo usara mal?" |
|---|
| Arador | <tarzeau:#qc> no encuentro critico si el software no es seguro que causaria daño/muerte a los humanos o a otras formas de vida |
|---|
| Arador | < blackkoal:#qc>define seguridad en una palicacion tl y como tu la entiences |
|---|
| Arador | el software que es critico para una persona no lo es para alguien mas |
|---|
| Arador | y, en general, el software de codigo abierto no tiene a ser usado en aeropuertos, o sistemas que soportan la vida en los hospitañes |
|---|
| Arador | y , uno de los valores del codigo abierto es que la gente que confia en ellos puede realizar sus propias auditorias de seguridad |
|---|
| Arador | creo que a este punto, he hablado suficiente sobre la auditoria |
|---|
| Arador | espero que hayamos llegado al punto de que la auditoria de software es un aspecto importante del desarrollo de software en general |
|---|
| Arador | (como mi jefe dice, "eso es por lo que lo llamamos 'investigacion :) |
|---|
| Arador | < Borja:#qc>de todas maneras, no creo que la auditoria sea el objetivo principal |
|---|
| Arador | < Borja:#qc> el software deberia ser fuerte por diseño |
|---|
| Arador | < rene:#qc>sarnold: lo siento por no tener pists, pero que es el "karma whore"? |
|---|
| Arador | rene: karma whore -- el efecto de postear de eslashdot, en el que la gente se va fuera de su camino escribiendo comentarios utiles...solo para reconocer :) |
|---|
| Arador | borja: el tipo que escribio "the mytical man month" clasifica a los bugs en dos categorias |
|---|
| Arador | borja: "incidentales" e "intrinisecos" |
|---|
| Arador | borja: los bugs incidentales son los buffer overflows y los bugs de printf -- bugs que se podrian mitigar usando otras herramientas (como los lenguajes de tipo seguro: java, ml, haskell, etc) |
|---|
| Arador | borja: esos bugs tienden a hacer lineas de cabecera frecuentemente: "otrovrus de outlook" "otro bug de seguriodad del IE" |
|---|
| Arador | borja: auditar puede descubirr amabs clases: la auditoria del diseñador de xinetd (100 kb de parche) tenia ambos intrinsecos y extrinscos |
|---|
| Arador | borja: pero encontrar los bugs intrinsecos toma mas trabajo: de ahi la necesiadd de mejor educacion |
|---|
| Arador | y hablando de educacion, pienso que esta charla podria ser mas interesante si mencion algunos de los fallos comunes que se introducen en el software |
|---|
| Arador | el mas popular es el buffer overflow (sobreescritura del buffer) |
|---|
| Arador | se hace muy facil en C porque las cadenas son presentadas como colecciones de carcteres terminados en un caracter null |
|---|
| Arador | asique un codigo como este muy tipico permite al atacante tomar el control del progra,a |
|---|
| Arador | char buf[MAX]; |
|---|
| Arador | strcpy(buf, input); |
|---|
| Arador | dependiendo de la longitud de la coleccion de carcteres en "input" una persona maliciosa podria sobreescribir el buffer "buf", esto podria escribir sobre variablescercanas o direcciones de rtorno de funciones, o otros elementos del programa |
|---|
| Arador | este trozo deberia reescribirs para asegurarse que solo MAX-1 caracteres son copiados en buf, o abortar si linput es demasiado largo |
|---|
| Arador | (usando strncpy, strlcpy, o strlen) |
|---|
| raul | dependiendo del largo del arreglo de caracteres en "input", una persona malicionsa puede sobrecargar el buffer "buf"; esto puede sobre escribir algunas variables, or devolver direcciones, u otros elementos de programa: |
|---|
| Arador | < rene:#qc> strlcpy? |
|---|
| Arador | rene: strlcpy fue introducido por el proyecto openbsd como reemplazo de strncpy .. el cual tenía inconsistencias e semántica. |
|---|
| Arador | < blackkoal:#qc> otra pregunta: existe en algún lado un sitio web acerca de cómo escribir código limpio (me refiero con buenos comentarios...?) especialmente como escribir comentarios) |
|---|
| Arador | blackhoal: existe una lista de recursos disponible en https://sardonix.org/Auditing_Resources.html |
|---|
| Arador | blackhoal: y para lo de escribir comentarios, hay una cierta regla que es "no describas lo que hace el código; eso debería ser obvio. describe _por qué_ el código hace lo que hace." |
|---|
| viZard | la próxima falla de seguridad más común es el "printf" |
|---|
| viZard | por muchos años, la gente ha asumido que printf es una función segura |
|---|
| viZard | pero, en la primaver/verano del 2000, alguien apuntó que printf tiene un método que permite la escritura en la memoria. |
|---|
| viZard | y _muchos_ programas permiten entradas maliciosas a suplir strings format |
|---|
| viZard | así que el código luce como sigue: |
|---|
| viZard | printf(foo); es más o menos vulnerable pero en desuso. |
|---|
| viZard | debería ser reescrito como printf("%s", foo); |
|---|
| viZard | existe un problema complejo con printf, pero está mejor discutido en un foro específico para printf (como la conferencia INFOSEC de hace unos meses atrás) |
|---|
| viZard | otra clase de error común es la carrera de sistemas de archivos (filesystems) |
|---|
| viZard | esta es la especialidad de Al Viro :-) |
|---|
| viZard | esto puede ser algo tan simple como usar access(2) en un programa privilegiado para determinar si el acceso a archivos debe ser dado en una llamada abierta hecha a nombre del usuario. |
|---|
| viZard | (el uso normal va como sigue: if (access("/etc/shadow", S_IWUSR)) open("/etc/passwd", O_WR);) |
|---|
| viZard | el problema es que alguien puede reemplazar el /etc/shadow usando el access(2) y el open(2) |
|---|
| viZard | esto es conocido como " tiempo de revisión a tiempo de uso" |
|---|
| viZard | la solución a este problema es mucha más complejo: el uso de setuid(2) y setgid(2) y setgroups(2) para asegurar que el _kernel_ hace la revisión. |
|---|
| viZard | Linux introdujo la herramiente fsuid, que puede ser usada para permitir que un programa emule los privilegios de un ususario específico a un sistema de archivos, sin arrojar los privilegios totales. |
|---|
| viZard | Esto puede ser implementado principalmente para el daemon NFS, pero puede ser usado por otros programas, como Sendmail, para asegurar que la entrega de correos funciona perfectamente. |
|---|
| viZard | Otros problemas con entradas sin revisar incluye la función system(3) |
|---|
| viZard | esta función ejecuta un comando usando /bin/sh, así que es extremadamente poderoso y simpre de usar -- con la salvedad de que si cualquier entrada es suplida por el usuario, uno debe tener cuidado de los metacaracteres del shell |
|---|
| viZard | así, que si un usuario puede suplir parte de un comando con input, algo como "rm -fr /" podría arruinarnos el día. |
|---|
| Arador | un problema de fuente en el que poca gente piensa es en el entorno! |
|---|
| Arador | el cargador provee funcionalidad permitiendo a las librerias ser pre-enlazadas en el programa, reemplazando las librerias del sistema, usando LD_PRELOAD |
|---|
| Arador | asique, incluso usuarios pueden reemplazar funciones con funcione sd eus eleccion! |
|---|
| Arador | esto es mitigado en la libc limpiando el entorno cuando se hace un exec() pero no es perfecto |
|---|
| Arador | PATH es tambien popular, muchos sistemas incluyeron . (CWD) en si variable PATJ.....proporcionando un programa /tmp/mail, uno podria ser afortunado si el root lee su email desde /tmp ;) |
|---|
| Arador | < majeu:#qc> como puede uno evitar los problemas con LD_PRELOAD, aparte de compilar estaticamente? |
|---|
| Arador | no hay mucho que se pueda hacer, LD_PRELOAD se maneja principalmente por glibc en los sistemas linux, pero el problema es indicativo de la naturaleza especial de las variables de entorno |
|---|
| Arador | el otro dia, recibi un email de Steven Christey, del proyecto MITRE CVE, con una lista de errores de codificacion....era sobre 60 categorias, y muchas entradas tenian una docena o mas subcategorias |
|---|
| Arador | pondremos esta lista en el sitio web de sardonix como una guia para ayudar a los auditores a la hora de auditar software, parece que los auditores tienen un terreno fertil para buscar problemas de seguridad :) |
|---|
| Arador | alguien tiene mas preguntas (canal #qc) |
|---|
| viZard | ¿Alguien tiene preguntas? |
|---|
| Arador | < sh0nX:#qc> cuantas de las utilidades open source (como la base de herramientas GNU) y semejantes se auditan= |
|---|
| sarnold | (¿Alguien tiene preguntas? otherwise, i'm done.. :) |
|---|
| raul | sh0nX: no suficientes. La gente aún encuentra vulnerabilidades en tar, rm, et |
|---|
| raul | sh0nX: me gustaría pensar que 18 es tiempo suficiente para que tengamos un tar estable y libre de fallas, pero ... supongo que no es así |
|---|
| raul | < crispin:#qc> La lista de Steven Christey es una forma más rica que la lista patológica de sardonix. |
|---|
| viZard | í, debe hacerse notar que solo he dado unos cuantos ejemplos de errores :) su lista es muy grande y completa |
|---|
| viZard | < sh0nX:#qc> quisiera ver un consorcio de auditoría de open source |
|---|
| viZard | sh0nX: eso es mas o menos la meta de sardonix .. pero tratando de imitar el efecto slashdot, esperamos alentar gente para que audite software con un poco más que reconocimiento y paga :) |
|---|
| viZard | < sh0nX:#qc> y qué de herramientas automatizadas para buscar cosas |
|---|
| viZard | https://sardonix.org/Auditing_Resources.html enlista muchas herramientas que ayudan en los problemas de códigos |
|---|
| viZard | < pflanze:#qc> probablemente sería buena idea usar "sandboxing" para aplicaciones como browsers, icq y clientes irc. |
|---|
| viZard | pflanze: sí, estas en lo cierto, eso puede ayudar significativamente. Proyectos como LSM (http://lsm.immunix.org) están proveyendo infraestructuras para módulos de seguridad en el kernel de Linux para ayudar a activar cosas como sandboxes (TrustedBSD for the FreeBSD fans) |
|---|
| viZard | < tarzeau:#qc> ¿Alguien conoce SELinux? |
|---|
| viZard | tarzeau: el problema más grande de SELinux, como lo veo, es que el tamaño de la complejidad de las reglas de sus políticas es demasiado alto. |
|---|
| viZard | tarzeau: esto es otro inconveniente -- los sandboxes pueden ser muy ceñidos y explicitos --- pero lleva mucho tiempo el prepararlos y validarlos, o seran demasiado timples y muy granulados, pero son simples de preparar y validar |
|---|
| viZard | < pflanze:#qc> demostrar que un codigo no tiene fallos de seguridad es un problema inresolvible: es solamente iresolvible en cuanto que no se puede partir desde el putno de vista de que las caracteristicas son mas importantes que las correcciones. :) |
|---|
| Arador | pflanze: bien, esto actualmente no se ha probado que sea el caso -- determinas las spropiedades de seguridad de programas arbitrartios es imposible |
|---|
| Arador | pflanze: para programas especificos, tienes razon, pero incluso programas simples y pequeños (fingerd es uno que me viene a la cabeza) tiene pobre seguridad |
|---|
| Arador | < pflanze:#qc> por ejepmlo,si eres cuidadoso desde el principio (como DJB) podria ser posible escribir codigo 100% seguro |
|---|
| Arador | pflanze: tienes razon, alguna diligencia por parte de los autores del software puede a largo plazao asegurar buesnos registros de seguridad |
|---|
| Arador | pflanze: con los problemas que la funcionalidad sufre (por ejemplo, servidores DNS recursivos deberia ser posible) |
|---|
| Arador | al menos que no haya mas preguntas, me inclino a llamarlo una presentacion :) |
|---|
| Arador | gracias a todos |
|---|
| Arador | <traduccion terminada> |
|---|
| sarnold | gracias arador :) |
|---|
| raul | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| Arador | de nada sarnold ;) |
|---|
| viZard | aplauso aplauso aplauso aplauso |
|---|
| angelLuis | plas plas plas plas plas plas plas plas plas |
|---|
| Arador | gracias a raul y viZard tambien :) |
|---|
| viZard | aplauso aplauso aplauso aplauso |
|---|
| angelLuis | plas plas plas plas plas plas plas plas plas |
|---|
| angelLuis | plas plas plas plas plas plas plas plas plas |
|---|
| angelLuis | plas plas plas plas plas plas plas plas plas |
|---|
| viZard | aplauso aplauso aplauso aplauso |
|---|
| angelLuis | :)) |
|---|
| viZard | aplauso aplauso aplauso aplauso |
|---|
| viZard | aplauso aplauso aplauso aplauso |
|---|
| viZard | aplauso aplauso aplauso aplauso |
|---|
| viZard | aplauso aplauso aplauso aplauso |
|---|
| MJesus | clap clap clap clap clap clap clap clap clap clap |
|---|
| MJesus | clap clap clap clap clap clap clap clap clap clap |
|---|
| MJesus | clap clap clap clap clap clap clap clap clap clap |
|---|
| MJesus | clap clap clap clap clap clap clap clap clap clap |
|---|
| raul | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas p |
|---|
| raul | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|