Archive

Archive for the ‘Seguridad Web’ Category

Cómo se crea y detecta un ataque web

agosto 27, 2013 Los comentarios están cerrados

Cómo se crea y detecta un ataque webComo si se tratará de un juego de niños, integrar un troyano una página web es algo mucho más sencillo de lo nos podemos imaginar. De hecho, la navegación web por sitios infectados es una de los principales vectores de ataques. Es por ello que conocer la anatomía de un ataque web es clave para saber cómo defenderse.

Contrariamente a lo que cree la mayoría, las páginas con infecciones no tienen un fondo negro con imágenes de hackers malvados. El 80% de los sitios infectados son legítimos, es decir, puede ser una web corporativa o una tienda on-line en la que dejamos un comentario con nuestra opinión sobre determinado producto. Leer más…

Shell Python Weevely en servidores vulnerados (y II)

agosto 26, 2013 Los comentarios están cerrados

En los artículos anteriores vimos cómo se vulneraba un servidor para alojar Phishing de Mercado Pago a través de Shell PHP y ahora profundizaremos sobre una Shell Python que fue encontrada en el mismo servidor y seguramente subido por algunos de los delincuentes que lo habían atacado. Leer más…

Advierten acerca de un exploit de Joomla

agosto 12, 2013 Deja un comentario

jommla-logoLos investigadores de seguridad de ‘Verasafe’ han identificado un ataque de ‘día cero’ que puede tomar el control completo de los sitios web de Joomla.

Una actualización para la vulnerabilidad aprovechada en el ataque fue lanzada a finales de julio, así que se recomienda que los usuarios actualicen sus instalaciones lo antes posible para protegerse.

Leer más…

Servidor Apache – MOD_SECURITY – Parte X

septiembre 28, 2012 Deja un comentario

MOD_SECURITY es una robusta librería que se encuentra disponible para servidores web Apache y que permite a un administrador, extender la seguridad del servidor con mecanismos adicionales incluidos en este módulo. Se encuentra dentro de la categoría de los WAF (Web Application Firewall) dado que contiene directivas que permiten detectar y filtrar ataques comunes contra la infraestructura de un servidor web. Una de las principales características de este módulo es su capacidad para capturar y analizar de forma dinámica el trafico HTTP, esto es una gran ventaja, dado que estas características le permiten monitorizar, registrar y controlar el acceso de todas las peticiones HTTP que son llevadas a cabo por los clientes, filtrando aquellas que son legitimas y aquellas que tienen altas probabilidades de no serlo. Este módulo es importante habilitarlo en servidores web ya que permite habilitar una capa extra de protección, sin embargo es también importante tener en cuenta que este módulo no puede proteger por completo un servidor web, ya que su contexto de ejecución esta limitado solamente a las aplicaciones web y hay mucho código (propio del servidor web) que se ejecuta antes de que MOD_SECURITY entre en acción.

 

Para comprender como funciona este módulo antes de proceder a instalar y llevar a cabo tareas más concretas como las de establecer reglas y explicar las directivas disponibles, se indica cual es el ciclo de vida de este módulo, explicando cada uno de los pasos involucrados:

  1. Request Headers.Este es el primer paso para el procesamiento de MOD_SECURITY, el principal objetivo de esta etapa es interceptar la petición de un cliente y enviar los headers y el body de la petición del cliente al motor de reglas de ModSecurity, todo esto antes de que se lleve a cabo el procesamiento propiamente dicho de la petición por parte del servidor web.
  2. Request Body.Este paso es uno de los más importantes, ya que se pone en marcha el proceso de análisis de la petición anteriormente interceptada, en este punto las reglas definidas en el motor tienen a su disposición toda la información relacionada con el cuerpo de la petición, es aquí donde las reglas determinan si la petición debe continuar siendo procesada por el servidor, si debe interrumpirse la interacción o debe llevarse a cabo alguna acción adicional.
  3. Response Headers.Este paso entra en acción después de que el servidor web genera la respuesta para una petición dada, donde los headers ya se encuentran generados pero el body aun no se ha leído, en este punto el motor de reglas define que campos deben ser inspeccionados en el cuerpo de la repuesta.
  4. Response BodySe trata de la principal fase de análisis del cuerpo de la respuesta, esta fase toma como insumo la fase anterior (Response Headers) donde el motor de reglas para la respuesta ha sido inicializado y ahora el cuerpo de la respuesta se ha tenido que leer completamente para que con toda la información de la respuesta, el motor de reglas pueda tomar decisiones sobre los datos leídos.
  5. LoggingSe trata de la única fase del ciclo de vida que no puede ser bloqueada, ya que cuando esta fase se ejecuta, la transacción habrá finalizado y es poco lo que el administrador podrá hacer al respecto, las reglas definidas en este paso, solamente definen la forma en la que el logging se llevará a cabo.

Anotar que todos los estos pasos, son llevados a cabo por medio de filtros Input/Output de Apache (que se han explicado en una publicación anterior) y de esta forma, el ciclo de vida se mueve por cada una de sus etapas

Ahora se procede a indicar el proceso de instalación de MOD_SECURITY en un servidor web Apache.

Instalación Mod_Security

En primer lugar la instalación recomendada (y la que explicaré a continuación) es la instalación partiendo del código fuente del módulo, también es posible instalar MOD_SECURITY utilizando alguna versión pre compilada disponible para cada sistema operativo (Debian, backTrack, Ubuntu, etc.) o versiones pre compiladas de terceros.

En primer lugar se deben cumplir las dependencias exigidas por MOD_SECURITY, en sistemas basados en Debian, basta con ejecutar

>apt-get install libcurl3-dev liblua5.1-dev libxml2-dev

Ahora ejecutar el script configure indicando la ruta donde se encuentra disponible APXS.

>./configure –with-apxs=/opt/WebServerFull/httpd-2.2.22/bin/apxs

Finalmente ejecutar

>make>make install

Con las instrucciones anteriores será suficiente para tener instalado Mod_Security en el servidor web, con lo anterior, se ha debido generar el fichero mod_security2.so en el directorio de módulos del servidor web ubicado en <APACHE_INSTALL>/modules.

Ahora que MOD_SECURITY se encuentra instalado en el servidor web, se puede comenzar a utilizar sus directivas (obviamente después de cargar el módulo).

Conocer las directivas, permite tener un mejor entendimiento y conocimiento sobre como funciona este módulo y cuales son las características que implementa, antes de pasar a esa parte, es aconsejado crear una estructura de directorios especifica para este módulo, de tal forma que sea fácil de identificar los ficheros de configuración necesarios y cual será el espacio de trabajo definido para las operaciones que lleve a cabo el módulo. En este caso, se ha creado la siguiente estructura de directorios dentro del directorio de instalación de Apache:

<APACHE_INSTALL_DIR>/etc

<APACHE_INSTALL_DIR>/var

<APACHE_INSTALL_DIR>/var/audit

<APACHE_INSTALL_DIR>/var/data

<APACHE_INSTALL_DIR>/var/log

<APACHE_INSTALL_DIR>/var/tmp

<APACHE_INSTALL_DIR>/var/upload

Esta estructura de directorios cobrará sentido en la medida que se avance con el estudio de las directivas. Ahora, para tener una configuración limpia, en el directorio etc se incluirán todos los ficheros de configuración que se utilizarán, el primero de los ficheros será llamado mainConfig.conf

Ahora, en el de configuración del Apache (httpd.conf) se deben incluir las siguientes lineas:

# Load libxml2LoadFile /usr/lib/libxml2.so

# Load Lua

LoadFile /usr/lib/liblua5.1.so

# Finally, load ModSecurity

LoadModule security2_module modules/mod_security2.so

Include /opt/WebServerFull/httpd-2.2.22/modsecurity/etc/mainConfig.conf

Ahora bien, el contenido del fichero mainConfig.conf, inicialmente puede ser el siguiente:

SecDataDir /opt/WebServerFull/httpd-2.2.22/modsecurity/var/dataSecTmpDir /opt/WebServerFull/httpd-2.2.22/modsecurity/var/tmp

Ahora que se encuentra correctamente instalado y configurado este módulo en el Apache, es el momento de conocer las principales directivas disponibles para conocer su alcance y lo que se puede hacer con él.

DIRECTIVAS EN MOD_SECURITY

Algunas de las directivas más interesantes y las que seguro serán utilizadas.

Directivas para Procesamiento de Peticiones

SecRequestBodyAccess

Sus posibles valores son “on” y “off” y le indica a mod_security cuando debe y cuando no debe acceder al cuerpo de las peticiones, tal como se recordará de los apartados anteriores, dentro del ciclo de vida hay una separación en los datos a los que puede acceder con mod_security, en cualquier caso, los headers de la petición siempre estarán disponibles, (paso 1 del ciclo de vida) sin embargo el cuerpo de la misma esta disponible solamente en el siguiente paso (paso 2 del ciclo de vida). En el caso de que esta directiva tenga un valor de “off” indica que no será posible acceder a los valores que viajan en el cuerpo de la petición (como por ejemplo parámetros que viajan por POST) lo cual desde luego, no es siempre deseado. Sin embargo hay una “desventaja” cuando esta directiva se encuentra activada (con valor “on”) y es que los buffers de los cuerpos de las peticiones son almacenadas en memoria volátil (RAM) lo cual puede ser un problema cuando MOD_SECURITY se ejecuta como un módulo embebido en el Apache. Es aquí donde entran otras directivas que permiten controlar los tamaños de los buffers en memoria, estas directivas se explican a continuación.

SecRequetsBodyInMemoryLimit

Esta directiva, como su nombre indica, permite definir el tamaño en bytes que será reservado en la memoria RAM para que MOD_SECURITY almacene allí los buffers correspondientes a los cuerpos de las peticiones, para que esta directiva tenga alguna efecto, la directiva SecRequestBodyAccess debe encontrarse activada.

#512 KBSecRequetsBodyInMemoryLimit 524288

En el caso de que una petición multipart/form-data superé este tamaño en memoria, automáticamente se comenzarán a volcar bytes a un fichero temporal en disco.

SecRequestBodyLimit

Indica el tamaño máximo de bytes permitido para los buffers correspondientes a los cuerpos de las peticiones, cualquier petición que superé este limite, será rechazada con un error HTTP 413 (Request Entity Too Large)

En el caso de que alguna de las aplicaciones alojadas en el servidor web tenga FileUploads o componentes similares en los que se permita a los usuarios subir ficheros, el tamaño que se le debe asignar a esta directiva debe de ser igual al tamaño máximo de los ficheros que se podrán subir.

#131072 KBSecRequestBodyLimit 134217728

SecRequestBodyNoFilesLimit

Esta directiva es similar a la anterior, con la diferencia de que en este caso, no se toman en cuenta las peticiones que transfieran archivos al servidor (FileUploads), en tales casos toma preferencia la directiva SecRequestBodyLimit. Normalmente este valor debe de ser más pequeño que el establecido en la directiva anterior, ya que el procesamiento de ficheros (que normalmente suelen tener un peso mucho mayor que las peticiones simples)

SecRequestBodyNoFilesLimit 131072

El valor por defecto de esta directiva es de 1 MB.

Esta directiva se ha introducido a partir de la versión 2.5 con el fin de evitar ataques DoS con el uso de la directiva SecRequestBodyLimit.

SecRequestBodyLimitAction

Permite controlar cual será el comportamiento del módulo cuando una petición alcanza o supera el limite definido en la directiva SecRequestBodyLimit en este caso pueden definirse dos valores posibles Reject y ProcessPartial. El valor por defecto es Reject a menos que la directiva SecRuleEngine tenga el valor DetectionOnly en cuyo caso el valor que tomará esta directiva será ProcessPartial

Directivas para Procesamiento de Respuestas

Del mismo modo que existen directivas para controlar los tamaños de los buffers para las peticiones y permitir que MOD_SECURITY haga un análisis de sus contenidos, también existen directivas que permiten tomar control sobre las respuestas que son emitidas por parte del servidor. Aunque en algunos entornos, toman como buenas practicas, desactivar el filtrado de MOD_SECURITY para el análisis de las respuestas que genera el servidor web, esto con el fin de mejorar el desempeño general del servidor ya que el uso de CPU se verá reducido (si, la seguridad cuesta). En algunos casos esto puede ser útil, pero en otros casos, puede convenir analizar las respuestas que esta generando el servidor para verificar que no existen fugas de información o se producen respuestas que exponen información sensible del servidor.

SecResponseBodyAccess

Esta directiva activa o desactiva el procesamiento de MOD_SECURITY para las respuestas generadas por el servidor web. Los posibles valores de esta directiva son “On” y “Off”. El valor por defecto es “Off”

SecResponseBodyLimit

Se trata de una directiva que permite establecer el limite en bytes de las respuestas generadas por el servidor. Es importante tener en cuenta que si este valor es muy pequeño, se pueden “romper” páginas en el servidor, es decir, si las respuestas a peticiones a dichas páginas tienen un tamaño superior al permitido por esta directiva, la respuesta al final será un error HTTP 500 (Internal Server Error)

#512 KB.SecResponseBodyLimit 524288

SecResponseBodyLimitAction

Si el cuerpo de una respuesta es demasiado grande y supera el tamaño definido en la directiva SecResponseBodyLimit se lanzará un error, sin embargo esto no siempre resulta conveniente, por este motivo existe esta directiva que permite indicarle al módulo que acción se debe llevar a cabo en el caso de que se presente esta situación. Los valores posibles para esta directiva son Reject y ProcessPartial, en el caso de que se establezca ProcessPartial la respuesta generada llegará solamente hasta el limite establecido en bytes, el resto de la respuesta será cortado.

SecResponseMimeType

Con esta directiva, se le puede indicar al modulo, los tipos de contenidos MIME que podrán ser almacenados en buffers de memoria, lo cual es bastante útil para indicar al servidor web que se debe procesar y que no. Esta directiva permite la definición de varios tipos MIME.

SecResponseMimeType text/plain text/html text/xml

Esta ha sido una introducción al uso de Mod_security en Apache, en la próxima publicación se hablará más sobre otras directivas interesantes y configuraciones que pueden aplicarse con este módulo.

Fuente: http://thehackerway.com

5 de fallas de seguridad de tu sitio web que puedes solucionar ¡ya!

agosto 29, 2012 Deja un comentario

La página web de una empresa suele ser un objetivo prioritario para los atacantes informáticos. Los criminales cibernéticos pueden utilizar las vulnerabilidades en los sitios para tener acceso a la información confidencial de la empresa o bien, pueden apropiarse de los sitios legítimos para propagar malware a las máquinas de los visitantes.

La buena noticia: A medida que la conciencia de las amenazas está aumentando, los sitios web son cada vez más seguro, según un estudio de 7.000 sitios web [PDF] controlados por WhiteHat Security. El año pasado un promedio de 230 vulnerabilidades de seguridad se encontraban en cada sitio de estudio. En el informe de este año, ese número cayó a 79, una disminución del 66%. Eso ha sido un declive constante visto por WhiteHat desde el año 2007.

Las organizaciones también están cada vez mejor en cuanto a los problemas de mitigación, ya que las vulnerabilidades se solventaron en un promedio de 38 días, que es una gran mejora sobre los 116 días que les tomaba un año antes.
Pero sólo porque las empresas han mejorado en seguridad de sus sitios web, esto no significa que los hackers han abandonado, sol que acaban de cambiar sus enfoques. Por ejemplo, muchos hackers están utilizando más los ataques especializados y destinados a empresas específicas en lugar de la automatización del proceso y no en busca de vulnerabilidades comunes en miles de sitios a la vez.
Cuando los hackers atacar un sitio, ¿cuáles son las vulnerabilidades que tienen más probabilidades de ver? Estos fueron las 10 principales vulnerabilidades encontradas en los sitios web estudiados:

  • Cross-site scripting (55% de los sitios son vulnerables a este tipo de ataque por cierto período de tiempo)
  • Filtración de información (53%)
  • Contenido de suplantación de identidad (36%)
  • Autorización insuficiente (21%)
  • Cross-site request forgery (19%)
  • Ataques de fuerza bruta (16%)
  • Predecibles localización de recursos (12%)
  • Inyección SQL (11%)
  • Sesión fijación (10%)
  • Expiración de sesión insuficiente (10%)

¿Qué hay detrás de esas vulnerabilidades y lo que lleva a los atacantes intentan encontrar y explotarlas? Aquí están cinco de las razones más comunes de los sitios web que son aprovechados por los ataques

1. Falta de actualizaciones de seguridad

Al igual que con muchos tipos de defectos de seguridad, las vulnerabilidades en sitios web a menudo comienzan con aplicaciones que no están parcheados y se mantiene hasta la fecha. Un estudio reciente encontró que la explotación de software obsoleto era método más común que los hackers utilizan para atacar sitios web.

2. Reabren las vulnerabilidades

Las vulnerabilidades encontradas existen por varias razones, como por ejemplo un mal código o configuraciones incorrectas. Y en algunos casos, cuando esos problemas se solucionan, se repiten de nuevo más tarde. De hecho, el 20% de las vulnerabilidades descubiertas por WhiteHat se solucionaron pero volvieron abrirse más adelante en algún momento. Eso pasó por una variedad de razones, tales como que se corrige el problema del código, pero luego se sobrescriben durante una actualización de software o si hay una actualización restaura una configuración vulnerable que se había reparado previamente.

3. La falta de cortafuegos

Uno de los puntos del informe de WhiteHat señala que muchas de las vulnerabilidades más comunes se pueden mitigar mediante el uso de un firewall de aplicaciones web (WAF). Como un firewall de red, protege el sitio web de los ataques maliciosos y los monitores de entrada y salida de tráfico. El informe estima que esta tecnología podría solucionar el 71% de las vulnerabilidades.

4. Procedimientos de inicio de sesión defectuosos

Algunas de las vulnerabilidades en la lista de los 10 son causados por la inseguridad en los procedimientos de inicio de sesión, incluidos los de inicio de sesión en las sesiones con defecto de expiración, como se muestra por el último elemento de la lista. En otro ejemplo, estuvieron presentes muchas vulnerabilidades de fuerza bruta debido a que el sitio web de registro en la página reveló que el nombre de usuario o contraseña eran correctos o incorrectos. Dado que muchos sitios utilizan direcciones de correo electrónico como nombres de usuario, los spammers pueden utilizar estos sitios para extraer direcciones de correo electrónico válidas.

5. La falta de conocimiento acerca de las vulnerabilidades

Mientras que las organizaciones en el estudio eran los clientes del servicio de monitoreo de WhiteHat y por tanto conocía sus problemas, muchas vulnerabilidades pasan completamente inadvertidos para los propietarios de los sitios web y los administradores. De hecho, más de la mitad de los administradores web no saben cuándo sus sitios son atacados, según una encuesta reciente de la empresa de seguridad Commtouch.

Para protegerse contra las vulnerabilidades, WhiteHat recomienda a las organizaciones hacer una lista de todos sus sitios y darles prioridad sobre la base de la importancia que tienen para el negocio de la compañía
A continuación, se debe probar estos sitios periódicamente para asegurarse de que las vulnerabilidades son solucionadas y detectar las nuevas cuando aparezcan.

Fuente: Blog de Carlos Solis (Whitehat en Inglés) Segu-Info

Sucuri SiteCheck, un excelente scanner de sitios para detectar infecciones

agosto 27, 2012 Deja un comentario

Sucuri SiteCheck es un scanner online que permite detectar elementos maliciosos en un sitio web, ideal para realizar un análisis primario en caso de infecciones. El servicio es gratuito y ofrecido por la empresa Sucuri la cual se dedica al monitoreo y remoción de malware.

Sucuri SiteCheck scanner gratuito

sucuri wordpress desactualizado

El funcionamiento es muy sencillo, simplemente hay que ingresar una URL y en cuestión de segundos se obtiene un informe bastante detallado que incluye información del servidor como la IP, el software que utiliza (Apache, CentOS, PHP, WordPress, Drupal, OpenX, etc) y sus versiones, además de una lista de todos los enlaces salientes, archivos javascript e iframes que se cargan y un estado del sitio frente a diferentes listas negras como Phishtank y Google Safe Browsing.

Los siguientes son algunos ejemplos de análisis y detecciones, algo muy bueno de la herramienta es que indica con bastante precisión donde se encuentra el malware o elemento malicioso, además de brindar algunos detalles sobre el problema.

Ejemplo de un sitio web actualmente infectado con un iframe oculto:

iframe oculto infeccion

Y los detalles del elemento malicioso detectado:

detalles sucuri

Clic para ver más grande

Otro ejemplo, un sitio educativo con spam farmacéutico:

spam en sitio educativo

Más spam pero en un sitio gubernamental:

spam en sitio gubernamental

Blog con WordPress desactualizado e infectado con scripts maliciosos:

wordpress infectado

Espero que la información resulte útil, la herramienta la descubrí gracias al foro oficial para Webmasters de Google donde a diario varios usuarios dedican parte de su tiempo para compartir conocimientos y ayudar a otros.

Fuente: spamloco

Estafa con SMS y abuso de dominios .com.ar posicionados en Bing y Google

agosto 15, 2012 Deja un comentario

Hace pocos días publicabamos una investigación de Spamloco.net sobre “Abundante spam en Bing con dominios .com.ar y enlaces“. Allí se muestra una cantidad importante de dominios .com.ar registrados para dirigir al incauto a lo que resultará en un engaño, en una autentica estafa:

“estafar:  2. Der. Cometer alguno de los delitos que se caracterizan por el lucro como fin y el engaño o abuso de confianza como medio.” – www.rae.es

El ejemplo investigado funciona tanto en Bing como en Google, como se aprecia a continuación en esta búsqueda:

Al seleccionar uno de los resultados, somos redirigidos a un sitio preparado para el engaño a través de Bing. Se ve el nombre bing.com en el enlace, que en realidad es otro, es el dominio premiodb.com.ar del estafador [1].
Allí nos sorprende un pop-up con un aviso de promoción de un (inexistente) regalo:

Al aceptar o cancelar, da igual, somos dirigidos a otra página donde se nos ofrece elegir el único regalo disponible, un teléfono celular último modelo:

Seleccionando el premio, pasamos a otra página, ahora en otro dominio: http://www.bestcoolmobile.com/. Este dominio de mala reputación exhibe el teléfono del premio y pide ingresar los datos de nuestro celular para participar.

Si decidimos que no nos interesa el premio e intentamos cerrar la página aparece el siguiente pop-up:

Luego de ingresar los datos de nuestro operador y nuestro número telefónico, recibimos en nuestro móvil un SMS:

Hasta aquí va todo bien, ingresamos el pin en la página (“PARA GANAR”):

Recibimos un nuevo SMS, pero con la siguiente sorpresa: ¡es la confirmación de adhesión a un servicio pago de envios de SMS! y… ¡ya nos engañaron!

En caso de permanecer aparece este ofrecimiento de servicio SMS, ahora en forma clara. Es de la misma empresa a la cual uno es adherido engañosamente tal como se describió arriba.

[1] Los dominios brutoingreso.com.ar y premiodb.com.ar, así como muchos otros .com.ar usados para estos abusos de posicionamiento en Bing como la posterior registración fraudulenta en SMS pagos, están registrados en la mayoría de los casos por Angeletti Fabricio Alfredo y alojados en MejorServer.com, ambos con el mismo domicilio en Rosario, calle Artigas 253.

Esta es una lista parcial de los dominios .com.ar con que abusan de esta forma:

9dejulio1.com.ar
aaaaaaaaaaa.com.ar
acebookacebook.com.ar
argentina00.com.ar
bonopokerstars.com.ar
cargadasariver.com.ar
cargadasariver.com.ar
casino-888.com.ar
contadorarosario.com.ar
cuenvanacuenvana.com.ar
descargaryoutube.com.ar
elderscroll.com.ar
es-ar.chula.com.ar
exclusivegambling.com.ar
faceboofaceboo.com.ar
foo–fighters.com.ar
friv–friv.com.ar
futbol1.com.ar
glups-helados.com.ar
golden-palace.com.ar
granhermanogran2012.com.ar
gratis0.com.ar
hacermirror.com.ar
hotmail–correo.com.ar
hotmailhotmail.com.ar
hoytshoyts.com.ar
inflacion1.com.ar
jimhenson.com.ar
juegos–olimpicos.com.ar
jugar-al-poquer.com.ar
katy–perry.com.ar
localstrikers.com.ar
marianela-mirra.com.ar
masun.com.ar
mcoa.com.ar
megauploadmega.com.ar
mejorbajada.com.ar
mercadolibremercado.com.ar
mreat.com.ar
musicamusicaonline.com.ar
outlookoutlook.com.ar
poker–888.com.ar
poker–gratis.com.ar
poker-titan.com.ar
pokerdetexas.com.ar
pokeronline0.com.ar
pokerstarscom.com.ar
pokerstarsnet.com.ar
pokerstarspoker.com.ar
pronostico–tiempo.com.ar
pumaslospumas.com.ar
queesunservidor.com.ar
queesunvps.com.ar
quilmes–rock.com.ar
reglas–poker.com.ar
reglaspoker0.com.ar
renault–duster.com.ar
rendaz.com.ar
riquelme1.com.ar
rosariocontabilidad.com.ar
satelitequecaera.com.ar
serverdedicadocod4.com.ar
servidordedicados.com.ar
skyrim.com.ar
test-del-amor.com.ar
texas-poker.com.ar
tube0.com.ar
tube1.com.ar
twitter–twitter.com.ar
videosvideos-videos.com.ar
wikipoker.com.ar

Seguiremos investigando…

Autor: Raúl

Fuente:  Segu-Info