Recientemente se ha publicado un informe de la Cloud Security Alliance en el que se destacan las principales amenazas o problemas de seguridad que se pueden encontrar en la utilización de la computación en la nube (también conocida por su sinónimo en inglés Cloud Computing). Como ustedes sabrán, la computación en la nube se basa en la externalización de toda la infraestructura utilizada por la empresa en sus procesos informáticos, de forma que un proveedor de servicios mantiene tanto el hardware como el software necesario, y proporciona al usuario un punto de acceso a toda esa infraestructura.

Como mantener una infraestructura separada para cada cliente es muy costoso, las empresas que proporcionan este tipo de servicios (llamados Infraestructure as a Service, o IaaS) utilizan técnicas de virtualización para rebajar costes y aumentar las posibilidades de escalado de sus sistemas. La virtualización permite en este caso compartir recursos del proveedor entre varios clientes. Pero estos recursos no suelen estar preparados para soportar los niveles de aislamiento requeridos por las tecnologías actuales de virtualización. Para salvar este bache y controlar los recursos que se asignan a cada cliente, los entornos de virtualización disponen de un sistema (llamado Hipervisor) que actúa de mediador entre los sistemas virtuales de los clientes y el sistema principal.

Una vez hemos realizado los ataques, vamos a acabar esta breve serie, analizando que han sido capaces de capturar el Snort empleando las reglas del VRT, y un OSSEC con la configuración por defecto.

Por parte del Snort, éste ha detectado 4 ataques. Como vemos en la captura, éste detecta el acceso por Terminal Server y el acceso al recurso compartido C por contraseña, o el uso del llsrpc pero no vemos rastro real de la ejecución del exploit o del meterpreter. Esto es debido a que las reglas por defecto que generan dichas alertas dan lugar a muchos falsos positivos y por defecto están deshabilitadas:

En la parte del OSSEC nos llama la atención que no salten alertas tales como la creación de nuevos usuarios en la máquina o de usuarios agregados al grupo de Administradores. Debemos recordar que la configuración es la de por defecto, sin habilitar logs extendidos ni otras variantes.

Tal como vimos ayer en la entrada anterior, hemos montado un laboratorio de análisis de ataques y comportamientos anómalos de una red; espero que los más laboriosos —y con más tiempo libre— se hayan decidido a acompañarme con su propio equipo. Como prueba de concepto del laboratorio, se va a realizar un ataque explotando la vulnerabilidad ms08-067 empleando para ello el framework Metasploit, donde se introducirá como payload Meterpreter, una shell residente en memoria.

Una vez explotada dicha vulnerabilidad, crearemos un usuario “s2”, lo introduciremos en el grupo de administradores, obtendremos las hash de los usuarios del sistema (muy importante para el pass the hash), descargaremos ficheros, subiremos ficheros, modificaremos la web del servidor y nos conectaremos por Terminal Server. Así pues, comencemos con ello.

Comenzamos con este artículo una serie de tres entradas en las que se va a mostrar como construir un (relativamente) sencillo laboratorio virtual sobre una única máquina física para la detección y prevención de ataques. Como requisitos previos, el laboratorio se monta sobre un entorno Linux, empleando la herramienta VirtualBox para las máquinas virtuales. Para conectar las máquinas virtuales entre si se empleará un hub virtual mediante la herramienta de virtualización UML (uml_switch).

Este entorno va a estar formado por tres máquinas virtuales: la primera será la máquina atacante (Linux Debian), la máquina víctima (Windows 2000 SP4) y por último la máquina IDS (Linux Ubuntu Server). Esta última dispondrá de una serie de herramientas de monitorización para observar y analizar los ataques producidos desde la máquina atacante a la máquina víctima, y de esta forma localizar un patrón que identifique dichos ataques. En concreto hemos instalado un servidor OSSEC (HIDS), una sonda Snort sobre un MySQL con B.A.S.E. (NIDS) y un analizador de red (wireshark y tcpdump).

Algunos tuvimos la oportunidad de celebrar el pasado día mundial de Internet con una mesa redonda sobre Cloud Computing en la que participaron ocho personalidades de distintas multinacionales, de las que solo una de ellas era española. La mesa redonda estuvo moderada por la Consejera de Justicia y Administraciones Públicas de la Generalitat Valenciana y la verdad es que fue bastante interesante, e incluso yo diría que pertinente y adecuada en los tiempos que corren, tanto por la forma, como por el fondo.

Cloud es una moda. Todos estaban de acuerdo en que ya no es una utopía. Es una realidad, pero una realidad de moda. También parecían estar todos de acuerdo que una de las grandes ventajas que tiene este nuevo paradigma (así lo presentan algunos) es la reducción de costes. “Es una nueva forma de hacer outsourcing en un entorno global y virtual”, decían algunos. “Es una forma clara de reducir costes e incluso de incrementar la productividad”, decían otros. La verdad es que en medio de todas estas afirmaciones, vertidas incluso en ocasiones con pasión, yo me preguntaba si no será este otro de esos conceptos que usan las grandes firmas para seguir haciendo negocio con cosas que el resto de los mortales no acaban de entender.

Ayer, leyendo noticias sobre la serie “Lost”, de la cual soy fan, he visto algo que me ha llamado la atención. Panda Security, a través de PandaLabs ha publicado que en las últimas horas han proliferado en los motores de búsqueda numerosas páginas web que distribuyen el falso antivirus (rogueware) “MySecurityEngine”, usando para ello como gancho el final de la serie “Lost”. Cuando alguien busca en Internet información sobre la serie o referencias para visualizar el ultimo capitulo online mediante streaming aparecen como resultados webs falsas que han sido indexadas para aparecer en las primeras posiciones. Cuando el usuario pincha uno de estos enlaces se le pide su consentimiento para descargar algún archivo, como por ejemplo un códec, momento en el cuál se instala el falso antivirus en su ordenador; sorprende la velocidad con la que consiguen crear las webs e indexarlas a través de Google.

También se comenta que no sólo se usa el final de “Lost” para engañar a los internautas; series como Padre de Familia, Glee , la película Iron Man 2, o el reciente fallecimiento del cantante de ‘Rainbow’ o ‘Black Sabbath’, Ronnie James Dio, también son usados como reclamo para desplegar un ataques de Black Hat SEO a través de Internet, es decir usando métodos y técnicas que no son admitidas como legales para posicionarse en los buscadores, pero que son efectivas.

Noticia de hoy, calentita: un fallo en la web del Ministerio de Vivienda daba acceso a datos personales de solicitantes de la renta de emancipación, permitiendo al parecer acceder incluso a información fiscal de otros solicitantes (datos de nivel medio). Pero no, no voy a entrar en la desgastada discusión de que si esto pasa o no pasa porque las administraciones públicas no tienen una especial sensibilidad ni concienciación en cuanto a sus responsabilidades en el tratamiento de los datos de carácter personal, de si esto pasa porque no están sujetas al régimen sancionador de la LOPD, etc.

Quiero ir por otro lado. A mi juicio este incidente es un ejemplo práctico y claro que hace patente la necesidad de que el Esquema Nacional de Seguridad (ENS) pase de ser una mera declaración de intenciones a una obligación real y efectiva. El servicio de gestión, consulta y seguimiento del estado de tramitación de las citadas solicitudes de renta de emancipación ante el Ministerio de Vivienda es un servicio sujeto, se mire por donde se mire, al cumplimiento de la Ley 11/2007 de acceso electrónico de los ciudadanos a los servicios públicos. El artículo 42 de esta ley decía que se establecerían unos criterios para definir el marco en materia de seguridad, normalización de la información y de las aplicaciones a utilizar para que este acceso electrónico se desarrolle de manera segura. Por eso en enero de este año se publicaron el Esquema Nacional de Seguridad (RD 3/2010) y el Esquema Nacional de Interoperabilidad (RD 4/2010).

Seguimos con la serie sobre Honeynets, esta vez para hablar de las tipologías, que dependerán de los recursos de los que disponemos para implantar la honeynet. Según la tipología, aún siendo válidas todas ellas, estarán más o menos limitadas en el cumplimiento de los objetivos propuestos.

Tendremos en cuenta la clasificación que propusimos en el anterior post donde se diferenciaba por localización. El tipo de honeynet a implantar, bien sea conviviendo con nuestros sistemas en producción o en un entorno totalmente aislado de la organización, marcará las directrices a la hora de decidir que tecnologías utilizar.

Entorno de PRODUCCIÓN

Si nos decantamos por una honeynet integrada en nuestra red organizativa en producción, debemos conocer las tecnologías que forman parte de nuestros sistemas para no utilizar otra que pueda interferir en el modelo productivo. En este caso y como ejemplo, si tenemos una política de seguridad donde se exige que la implantación de nuevos sistemas debe hacerse mediante virtualización, sabemos que la instalación de los diferentes honeypots no podrá realizarse en sistemas físicos convencionales.

Resulta que el pasado 27 de abril la agencia de protección de datos alemana realizó una queja a Google relacionada con la información Wi-Fi recogida por la flota de coches Street View, que por si no lo sabían, además de realizar fotografías, también capta información de SSIDs y MACs. El departamento legal de Google respondió que la única información Wi-Fi que recopilaban era, en efecto, esa. Es decir, en palabras de Google, que Networks also send information to other computers that are using the network, called payload data, but Google does not collect or store payload data

El caso es que la agencia de protección de datos alemana, que es una desconfiada, se queda con la mosca detrás de la oreja, y a principios de mayo se le antoja realizar una auditoría de esa información Wi-Fi. Y en estas que estamos, Google descubre, atónita y con sorpresa mayúscula, que aunque pensaba una cosa, ha resultado otra. Pensábamos que no, y resulta que sí; qué confusión más tonta.

Acaba de publicarse la noticia de que Microsoft dejará de actualizar la seguridad de los equipos con Windows XP y Service Pack 2 el próximo 13 de Julio, para actualizar únicamente las versiones mas modernas de este operativo. No han querido valorar cuántos equipos dejarán de estar actualizados, pero esta noticia revela la importancia de disponer de un repositorio centralizado para las actualizaciones de los equipos, y sobre todo de monitorizar que dichas actualizaciones se aplican correctamente.

En muchas organizaciones se siguen políticas centralizadas para la instalación de los parches del sistema operativo, para ciertas aplicaciones corporativas, para el uso de los antivirus corporativos con reglas restrictivas, para el uso de accesos externos a la empresa como VPN, etc. Sin embargo, no hay que dejar de lado que la mayor parte de las aplicaciones no permiten una actualización por políticas centralizadas, y que en la mayor parte de los entornos, un equipo suele tener instalados una infinidad de programas (necesarios) cuya actualización no es para nada sencilla, y que van mucho más allá del sistema operativo, Microsoft Office y el navegador. Tampoco conviene olvidar que la aplicación final de las actualizaciones suele depender del usuario, por varias razones.