31 julio 2013

Seguro que muchos de nuestros lectores ya conocen el paquete de instalación que ofrece Gpg4win, y que incluye una versión de todo el software necesario para facilitar el intercambio de correo y ficheros cifrados y firmados. En concreto:
  • GnuPG, el motor de cifrado, la  herramienta que se encarga de todo el proceso.
  • Kleopatra: la utilidad para gestionar certificados desde una interfaz gráfica cómodamente.
  • GpgOL: la extensión de Outlook para cifrar y firmar correos de forma sencilla.
  • GpgEx: la extensión de Explorer para cifrar o descifrar con el botón derecho.
  • Claws Mail: un cliente de correo electrónico.
Por desgracia, GpgOL solo tiene soporte de la versión 2003 y 2007 de Outlook lo que supone un problema importante para extender la herramienta en el uso doméstico y de pequeñas organizaciones que no pueden implantar otros sistemas alternativos.

Gracias a Deja vu Security, ahora es posible contar con una extensión más: Outlook Privacy Plugin, que amplía el soporte para las versiones más recientes: 2010 y 2013, tanto en 32bits como en 64bits. Eso sí, siempre en Windows Vista, 7 ó 2008, ya que requiere del Framework 4.5 de .NET y este no se encuentra disponible en el ya obsoleto y decadente Windows XP.

La puesta en marcha es un poco engorrosa, una vez configurado Gpg4win y el ya comentado framework 4.5 de .NET, se ha de instalar también Visual Studio 2010 Tools for Office Runtime de Microsoft y por último la última versión disponible del plugin, que está en continuo desarrollo y fase BETA (o dicho de otra forma, mejor que nada y prepárate para algún que otro casque)

Cuando todo finalice, al arrancar Outlook, aparecerán nuevas opciones a la hora de componer un mensaje como las que se muestran en esta imagen:

Acciones de Outlook Privacy Plugin a la hora de componer un nuevo correo.

La pantalla de configuración es simple, pero cumple con sus funciones:

Configuración (botón Settings) del plugin.

Con que poco se hace feliz a este pobre usuario.

Leer más...

30 julio 2013

Anti Ransom 1.0

Últimamente ando lidiando con casos de RansomWare, ya publiqué aquí un par de artículos sobre el tema.

Tal y como están las cosas hoy día con respecto a este tipo de amenazas, lo cierto es que a nivel técnico, una vez se ha producido la infección, poco se puede hacer.

El uso de algoritmos robustos y contraseñas aleatorias dificultan ¿imposibilitan? un final feliz que no sea pagando a estos estafadores.

Con suerte 'solo' serán unos pocos cientos de euros, pero ya se han visto casos de miles de euros en los que sobre todo empresas, ante la desesperación de ver su negocio bloqueado, han terminado pagando.

Este tipo de amenazas se dedican a recorrer las unidades de disco y cifran los documentos que van encontrando dejándolos inutilizados.

Una vez pagas el rescate, te facilitan una herramienta que es capaz de revertir ese proceso y hacer que los ficheros vuelvan a su estado original

En muchas ocasiones el afectado en cuestión no necesita el total de sus ficheros, y lo que le hace pagar es el poder recuperar varias carpetas muy concretas.

Recapitulando mi experiencia en este tipo de amenazas se me ocurrió una forma de intentar detectar lo antes posible la presencia de una amenaza de este tipo en un sistema.

Madurando esa idea el resultado ha sido Anti Ransom 1.0

A diferencia de los sistemas más tradicionales basados en firma, lo que hace mi herramienta es basarse en comportamiento, y para ello emplea una suerte de 'honeypots para ransomware', lo que permite detectar que el sistema está siendo víctima de un ataque Ransom y actuar de una forma rápida salvando en muchos casos la mayoría de ficheros importantes.

El funcionamiento es muy fácil de explicar:

Durante el proceso de instalación se crea una carpeta con nombre aleatorio en C:\ (caso de Windows XP) o en la carpeta personal del usuario (%HOMEPATH%) en el caso de Windows 7.

Se ha procurado que dichas carpetas comiencen con una secuencia numérica para 'posicionarlas' lo más arriba posible con la intención de que sean las primeras sobre las que se realice el cifrado 

En esa carpeta se crean un número aleatorio (nunca es el mismo número) de ficheros con formatos PDF, Excel y RTF. El contenido de esos ficheros también es aleatorio, de forma que resulte más complejo distinguir lo que es una carpeta legítima de una carpeta señuelo.

Carpeta señuelo
Una vez creado el honeypot, se instala un programa (igualmente en ubicación aleatoria y con el nombre igualmente random) que se dedica a monitorizar esa carpeta buscando cambios en ella. Bien sea que se ha creado un nuevo fichero (las amenazas de tipo RansomWare cuando cifran un fichero lo renombran con alguna extensión nueva), o bien si se altera el hash md5 del fichero, señal inequívoca de que un fichero que no debe cambiar está siendo alterado por una amenaza Ransom.

Cuando detecta actividad sospechosa, informa al usuario de ello



A futuro estoy trabajando en formas de identificar el proceso que ha causado la alerta e intentar 'matarlo'. No obstante, en este tipo de amenazas, dado que el tiempo juega un papel vital, lo más fiable es apagar el equipo y plantearse analizarlo offline, es la única forma de evitar que se pierdan los datos con ciertas garantías.

El programa se instala / desinstala de una forma muy sencilla:


Una vez instales el programa, guarda la carpeta desde donde hiciste la instalación, esto es MUY importante ya que, en aras de hacer más difícil su detección, el programa no usa los mecanismos habituales para registrarse en windows, y para desinstalar solo lo podrás hacer si ejecutas la desinstalación desde la carpeta donde realizaste la instalación.

En principio este programa ha sido diseñado para estaciones de trabajo (probado en XP y Windows 7) y mi objetivo es sacar una versión para servidores lo antes posible (con auto-apagado, notificación por correo electrónico ...)

Podéis descargar la beta de Anti Ransom 1.0 desde aquí 

Para instalar simplemente ejecutad setup.exe
Leer más...

29 julio 2013

Funcionamiento de los 'crypters'



Tal y como avanzamos en el anterior post de esta serie sobre 'crypters', los Antivirus, en adelante AVs, escanean los archivos en el disco del ordenador y no en la memoria RAM y este comportamiento es el que aprovechan los 'crypters' para evadir la detección de los AVs. Veamos como lo hacen.

Cifrado

Los 'crypters' utilizan técnicas de 'cifrado' para ocultar los archivos maliciosos. Repasemos rápidamente en qué consiste un cifrado. Un cifrado es un procedimiento que utiliza un algoritmo y una clave para transformar un mensaje legible en otro indescifrable.

Veámoslo con un ejemplo: vamos a 'cifrar' el mensaje "HOLA" con el algoritmo de cifrado ROT  (también conocido como cifrado César) y la clave de cifrado será "1". Este algoritmo lo que hace es, para cada caracter del alfabeto, avanza tantas posiciones como el valor de la clave de cifrado establecida, en este caso "1". Así pues, tras aplicar el algoritmo, la letra "A" se transforma en la "B", la "B" en la "C" y así sucesivamente. Por tanto el mensaje "HOLA" se transforma en "IPMB". De este modo hemos ocultado nuestro mensaje y para que alguien pueda descifrarlo, necesitará conocer tanto el algoritmo empleado (ROT) como la clave de cifrado (1). Obviamente este es un algoritmo muy sencillo y una clave igualmente sencilla, lo cual permitiría llevar a cabo ataques con el propósito de deducir el algoritmo y la clave, sin embargo, existen infinidad de algoritmos de cifrado enormemente complejos que pueden utilizarse y son utilizados para cifrar 'malware'.

Cifrando malware

La idea básica que subyace en el concepto de 'crypter' es la siguiente: si se cifra un archivo malicioso, éste será transformado en un archivo 'ininteligible' para el AV y por tanto no será detectado. Lo cual es cierto, pero claro, existe un pequeño problema, y es que el archivo malicioso cifrado no funciona, no puede ejecutarse, así que es necesario encontrar una solución, una técnica que se encargue de descifrar y ejecutar el archivo malicioso. Esta pieza de software se denomina 'stub'.

'Crypter' y 'stub'

Por regla general un 'crypter' consiste en dos elementos: el 'crypter' y el 'stub'. Esta última es la pieza más importante del conjunto.

El 'crypter' consiste generalmente en un programa que permite buscar y seleccionar en el sistema de archivos del ordenador el ejecutable a cifrar (generalmente un archivo malicioso, pero es posible cifrar cualquier archivo que se desee). Algunos, permiten adicionalmente introducir la contraseña de cifrado de forma manual o generarla aleatoriamente. Y en ocasiones, algunos permite activar cierta medidas anti-forenses, pero esto es otra historia que trataremos más adelante.

Una vez seleccionado el archivo a cifrar y pulsado el botón de 'cifrar' (Build en el ejemplo de la imagen) nos generará un 'nuevo ejecutable', el cual en realidad consiste en una composición del 'stub' y un 'payload', que no es más que el malware cifrado.


Crypter (malware) = Stub + [malware cifrado]


Como puede observarse, 'crypter' y 'stub' están relacionados, ya que el 'crypter' se encarga de ejecutar el algoritmo de 'cifrado' y el 'stub' se encarga de ejecutar el algoritmo de 'descifrado'. Para que el 'stub' pueda descifrar el malware necesita conocer la clave utilizada en el proceso de cifrado. En algunos casos, el programador del 'crypter' no da opción al usuario a elegir una clave, sino que la ha definido de antemano en su código, y en otras sí permite elegirla o generarla aleatoriamente, en cualquier caso, al generar el 'nuevo ejecutable' el 'crypter' ha de almacenar la clave en el algún lugar para que el 'stub' pueda encontrarla y descifrar el malware.

Si se observa en detalle este 'nuevo ejecutable', lo que vemos es una configuración bastante habitual, en la que tras el archivo ejecutable que constituye el 'stub', se añaden unos separadores de delimitan el lugar en el que se encuentra la almacenada la clave y a continuación se añade el malware cifrado. Obviamente cada programador puede organizar esta distribución como más le guste y en ocasiones, en lugar de añadir directamente el malware cifrado tras el stub, lo introducen en un recurso del ejecutable  PE.


Cuando este 'nuevo ejecutable', valga la redundancia, es ejecutado, el 'stub' se encarga de copiar a la 'memoria RAM' el malware cifrado, descifrarlo allí mismo, y a continuación ejecutar dicho 'malware' ya descifrado. Trataremos este punto en detalle en el siguiente artículo de la serie.

Artículo cortesía de Abraham Pasamar
Leer más...

28 julio 2013

Enlaces de la SECmana - 185

Leer más...

26 julio 2013

Vuestros "ETHERNET EXPOSED" - XIX


Seguimos recibiendo más y más fotos con vuestros ETHERNET EXPOSED, imágenes que realizáis a tomas ethernet que se encuentren expuestas en lugares curiosos, transitados, accesibles... y que posteriormente nos enviáis a nuestra dirección de contacto.

En la edición de hoy contamos con dos contribuciones de Javier Vaquerizo (Madrid) y una de Gustavo Villa (Uruguay).

Javier Vaquerizo nos envía dos Ethernet Exposed. El primero de ellos corresponde con las bocas disponibles de dispositivos de red que están dentro de un rack en un CPD un tanto especial:

"El viernes pasado fui a visitar las oficinas de un cliente y al entrar al baño me encontré con esto. O_O.  Directamente el rack en el cuarto de baño al alcance de cualquiera. Además tenía el papel higiénico encima, ideal cuando vas con las manos mojadas. Comentaros también que el ambiente húmedo del baño lo combatían eficazmente con el calefactor que se ve en el suelo.

Nada más verlo me acordé de vosotros, y como estas cosas sin foto son difíciles de creer, saqué la foto que os envío como archivo adjunto."




Como segundo Ethernet Exposed de Javier Vaquerizo, recibimos lo siguiente:

Os vuelvo a escribir para pasaros otro par de fotillos, estas un poco más "habituales". Son de la cafetería de la uem, en el edificio C (donde damos clase con Álex) abajo del todo. Es un sitio bastante discreto y se podría conectar un portátil perfectamente. La máquina es para cambiar dinero, recargar la tarjeta monedero de la universidad, etc. El otro día sacando los tickets de la comida en la máquina de al lado nos dimos cuenta, y cuando miramos debajo ya flipamos al ver el módem colgando.





La verdad es que dejar algo así en una Universidad dónde se está impartiendo un Master de seguridad informática, ¡es muy arriesgado!

Por último, tenemos una contribución por parte de Gustavo Villa, que se acordó de esta sección cuando se encontró el siguiente caos:

Hola, hace días había entrado a mi aula en I.T.S. Arias Balparda, (Montevideo. Uruguay) y de coincidencia me encuentro con lo siguiente, y me acorde de los grandiosos Ethernet Exposed de SBD, bueno les dejo la imagen.



Aunque parezca un poco a desmano, una vez sea accesible se podría dejar colocado algún dispositivo por detrás de los cables de red y conectarlo.

Como siempre os decimos, nuestra dirección de correo sigue abierta a todas aquellas contribuciones de ETHERNET EXPOSED que os encontréis, ¡muchas gracias a todos y hasta la próxima!

---------------

[+] Vuestros "ETHERNET EXPOSED" - XIX

Leer más...

24 julio 2013

Se acaba la fiesta Open Source

Hoy nos hemos desayunado con la noticia de que Cisco anda tras SourceFire, la empresa que está detrás de el famoso IDS/IPS Snort.

Esto me ha llevado a una reflexión: ¿Queda algún proyecto relevante en el mundo de la seguridad que siga siendo 'realmente' OpenSource? 

Sí, ya se que Snort sigue siendo software OpenSource, pero también es cierto que tras dar el paso de proyecto OpenSource a proyecto OpenSource 'tutelado', ha ido poco a poco perdiendo el foco en favor de su versión comercial (sobre todo en la parte gráfica).

El motor sigue siendo de código abierto, la comunidad lo usa, reporta fallos, lo mejora, etc pero las mejoras que aportan valor añadido se quedan en la parte comercial

Ya en 2005 el gigante Check Point puso sobre la mesa 225 millones para hacerse con la compañía, operación que terminó fracasando. Y si nos creemos las cifras publicadas: año 2005 --> 225 millones, año 2013 --> 2700, fue providencial que esa operación no se llevase a cabo.

Ahora, si finalmente cae en manos de Cisco, nos podemos temer lo peor, una empresa con una cultura no precisamente enfocada en lo 'Open' que puede derivar en otro 'MySQL-Gate'.

Previo a esto tenemos el caso Nessus, herramienta que fue Open Source hasta que su creador dijo basta y que, si bien ha mantenido una versión 'free', nuevamente nos encontramos con un producto mermado en comparación a su versión de pago e incluso con una licencia que prohíbe su uso comercialmente.

También destacable el 'Caso Metasploit', proyecto que en 2009 fue adquirido por Rapid7 y del que han derivado versiones mejoradas de pago y 'closed source'

Igual soy yo que soy muy mal pensado pero tengo la impresión que la mayoría de proyectos que se lanzan con licencia Open Source, utilizan el concepto meramente como vehículo para la promoción, para captar usuarios, ideas y esfuerzos hasta que alcanzan un nivel de visibilidad que les permite monetizar el concepto.

No es algo que critique -OJO-, me parece genial y no tengo nada que objetar. Si que lo siento por la gente que vive el movimiento Open Source como algo filosófico en su faceta más asceta.

Lo que si tengo claro es que ahora mismo cuando veo el anuncio de una nueva herramienta con el eslogan 'Open Source', siempre me viene a la cabeza la escena del chico que entra a un bar y le dice a una chica 'solo quiero invitarte a una copa' Y más si encima es un proyecto 'patrocinado' por una empresa
Leer más...

23 julio 2013

Introducción a los 'crypters'

En la pasada edición de la NcN tuve la oportunidad de poder exponer sobre 'crypters', tema sobre el que no es sencillo, en mi opinión, encontrar información de cierta calidad. Este artículo es el primero de una serie en la que pretendo explicar, con cierto nivel de detalle, el funcionamiento y uso de los 'crypters', así como las técnicas que se utilizan para lograr dejar indetectable un 'crypter' ya 'quemado'.

Para evadir la detección de malware por parte de los programas Antivirus, en adelante AVs, se utilizan diferentes técnicas, una de ellas es el uso de 'crypters'. Éstos permiten cifrar cualquier archivo binario para hacerlo 'invisible' a los AVs.

Es cierto, como mencionaba Yago Jesús recientemente en su post que los 'crypters' tienen mala fama, pero también la tenían los exploits hace unos años y hoy en día están integrados en todo tipo de aplicativos de seguridad, como Metasploit por ejemplo. Obviamente los 'crypters' son usados por los delincuentes para evitar la detección de los AVs e infectar los ordenadores, llevando a cabo todo tipo de tropelías, pero también pueden ser utilizados, entre otros casos, en el contexto de una auditoría de seguridad.

¿Quién no se ha encontrado con detecciones de AVs en el transcurso de una auditoría usando Metasploit u otras herramientas? Especialmente en aquellos casos en los que se 'dropean' (vuelcan) binarios al disco. De hecho, metasploit cuenta con una gran variedad de técnicas de ofuscación cuyo objetivo es hacer indetectable el binario a los programas AV. Las técnicas o herramientas que ofrece Metasploit  Community para llevar a cabo las tareas de indectección son básicamente:

  • Utilizar plantillas de programas ejecutables conocidos (Calculadora de Windows, Notepad, etc.)
  • Codificar mediante múltiples 'pasadas' del algoritmo que más nos guste el código del archivo ejecutable, todo ello a través la herramienta msfencode
Estas técnicas son muy efectivas con algunos AVs pero sobre otros no tienen ningún efecto. Por lo tanto, pueden servir en ciertos escenarios pero desde luego no sirven para evitar la detección de todos, o la mayor parte de los AVs. En la versión Metasploit Pro se proporcionan además binarios firmados que aumentan el nivel de 'indetección'.


En la imagen puede verse un ejemplo de uso de msfencode combinado con msfpayload para tratar de evadir la detección por parte de los AVs del payload shell_reverse_tcp, en el que se utilizan 10 pases de la codificación shikata_ga_nai, la plantilla del ejecutable calc.exe y como resultado se genera el archivo outputfile.exe.


En definitiva, si queremos asegurarnos de volver 'indetectable' un determinado binario que es detectado por multiples AVs, necesitamos un 'crypter' indetectado o FUD (Full UnDetectable).

Cryters vs. packers

Hay que puntualizar que en algunos entornos se habla indistintamente de 'crypters' y 'packers', pero en realidad son cosas distintas. El objetivo de un packer es 'empaquetar' o 'comprimir' el archivo ejecutable. Sería como usar un ZIP pero sin perder la estructura de un archivo ejecutable PE (Portable Executable). El objetivo del 'crypter' es 'cifrar' el ejecutable. Sería como usar PGP o TrueCrypt, pero sin perder la estructura PE.

Programas AntiVirus

En lo que sigue vamos a centrarnos en el explicar qué son y cómo funcionan los 'crypters', pero antes debemos entender de forma básica cómo funcionan los AVs. Éstos, son cada vez más sofisticados y utilizan todo tipo de técnicas para identificar el malware, entre estas técnicas destacan dos: las firmas binarias y las firmas heurísticas.

Las primeras buscan secuencias de bits características del malware previamente identificado. Es decir, buscan secuencias de bits, a modo de patrón, de aquel malware que haya pasado por el laboratorio de la empresa de AVs. Es decir, que en algún momento del tiempo, en la empresa de AV han recibido una muestra del malware para analizarlo y una vez identificado como malicioso han fijado o definido un patrón característico que constituye la firma binaria del mismo. En definitiva, un malware totalmente nuevo, recién 'codeado', difícilmente será detectado por este tipo de firmas. Para poder anticiparse y detectar malware que no haya sido analizado previamente, existen las denominadas firmas heurísticas. Básicamente lo que hacen es detectar elementos que típicamente forman parte de los programas maliciosos, como el uso de determinadas funciones, algoritmos de cifrado, etc. Mediante estás técnicas, es posible detectar de forma anticipada malware 'nuevo', pero, además de ser más compleja su implementación y consumir más recursos del sistema que las firmas convencionales, también implican un mayor nivel de riesgo debido a la detección de falsos positivos.

Análisis o escaneo en disco


Las tareas de análisis o escaneo de los archivos binarios son realizadas por los AVs a nivel de disco, no en la memoria RAM. Cuando un AV nos indica que está escaneando la memoria, lo que está haciendo realmente es buscar el binario en disco que arrancó un determinado proceso que en ese momento está ejecutándose en la memoria RAM y una vez ha localizado el mismo, escanea dicho binario (en el disco) en busca de firmas de malware. Así es como funcionan los AVs, escanean los archivos en el disco y los 'crypters' basan su existencia en este principio básico.


En próximas entregas veremos cómo funcionan y cómo se crean los 'crypters' indetectables (FUD).

Artículo cortesía de Abraham Pasamar.
Leer más...

22 julio 2013

Zarp: Framework para Ataques de Red

El grupo Ballast Security cuenta, entre otras muchas, con una herramienta bastante interesante que seguro que en el futuro podremos añadir a nuestro "arsenal". Zarp más que una herramienta, es un framework para realizar ataques a nivel de red con el fin de explotar redes locales, sin incluir ataques directos sobre sistemas (al contrario que metasploit). ¿Estamos por fin ante una posible alternativa a Cain & Abel pero para sistemas Linux?


Gracias a Zarp, podremos deshacernos de tantos scripts y herramientas que utilizamos de forma individual, pudiendo recopilar la mayoría de ataques dentro de este ámbito en un mismo ejecutable, y de forma centralizada. 

Pensando además en el framework de HD Moore, desde la herramienta podemos disponer de un conjunto de sesiones o comunicaciones abiertas (sección Sessions) tras un ataque satisfactorio, a las que posteriormente realizar un conjunto de ataques (post-explotación). Un caso típico sería, en primer lugar, realizar un ataque de poisoning y seguidamente, iniciar un sniffer de red enfocado a comunicaciones HTTP y obtener credenciales de autenticación a través del protocolo.

Entre las categorías de ataques a realizer destacan las siguientes agrupaciones:

[1] Poisoners

Dentro de esta categoría tendremos módulos que nos permitirán el envenenamiento de sistemas en red para realizar ataques de man-in-the-middle, robo de sesiones, etc, incluyendo protocolos DNS, DHCP, ARP, etc. Zarp realiza envenenamiento DHCP estableciendo un servidor 'rogue' intermedio escuchando paquetes DHCP-ACK o DHCP-DISCOVER. Con DNS ocurre de la misma manera: se interceptarán peticiones DNS y se responderá con paquetes maliciosos. También tendremos lo referente a ARP spoofing, redirección ICMP, etc.



[2] Denial of Service

Imaginaos el juego que da esta categoría, debido a la variedad de ataques de Denegación de Servicio que se pueden realizar. Actualmente Zarp cuenta con ataques Teardrop, IPv6 NDP RA, Nestea, LAND, TCP SYN, SMB2, e incluso el ataque publicado por KingCope sobre Denegación de Servicio por IGMP en kernels de Linux desde la 2.6.36 a la 3.2.1.



[3] Sniffers

Al igual que ocurre con Metasploit, en Zarp se disponen de determinados módulos idóneos para realizar una acción posterior a, por ejemplo, haber envenenado las comunicaciones entre sistemas en la red. En el apartado de sniffers, se cuenta con módulos específicos de obtener información concreta sobre flujos HTTP, contraseñas, conexiones a bases de datos, e incluso modificación de paquetes al vuelo.



[6] Services

En este caso, el propósito de estos módulos es la de actuar emulando un conjunto de servicios y servidores para que posibles víctimas se conecten a nosotros y posteriormente, obtener credenciales. Muy útil sobretodo a la hora de actuar como un honepot de estos servicios de manera rápida y sencilla.



La herramienta actualmente está en su versión 0.1.3, está preparada para entornos Linux con python y scapy preinstalados, y en sus próximos pasos destacaa la inclusión de ataques sslstrip, implantar un módulo de pass-the-hash, modificación de tráfico, etc. Además, en la página del proyecto se encuentran una serie de ejemplos entre los que se emulan situaciones reales para este tipo de ataques de red.

La página principal de la herramientra se encuentra en esta URL: 
Leer más...

21 julio 2013

Enlaces de la SECmana - 184


Leer más...

20 julio 2013

Seguridad y Optimización en servidores GLAMP [PDF]

El siempre polifacético dabo que, un día nos sorprende con un post sobre seguridad, al día siguiente con un podcast y al tercero una estupenda guía sobre administración de sistemas, ha publicado un interesante PDF que abarca las estrategias necesarias para securizar un entorno GLAMP.

El PDF es oro puro, no tiene una palabra de más y está plagado de enlaces a herramientas. Personalmente prefiero este tipo de documentos frente a otros donde el autor se explaya páginas y páginas en introducir un concepto y te mantiene tediosamente ocupado hasta que llegas al enlace.

Índice del PDF:

- Introducción a Apache

- Seguridad por oscuridad

- Seguridad en PHP

- IDS / IPS

- Fuerza bruta DoS / WAF

- Logs / monitorización

- Rootkits / Malware

Podéis descargar el PDF desde aquí
Leer más...

18 julio 2013

¿Y ahora nos preocupamos por la privacidad? Gracias #Snowden

Hacia mucho tiempo que no acercaba una contribución a los grandes amigos de Security By Default, a los cuales les agradezco el honor de poder tener el espacio. En esta oportunidad, les acerco algunos puntos de vista respecto al espionaje de la NSA revelado por el ¿nuevo héroe? llamado #snowden.

Con el reciente escándalo de la NSA y el "topo" #Snowden, el mundo entero (ahora) parece estar preocupado por la privacidad, en lo que podría interpretarse como la primera vez en que la información de los ciudadanos se percibe ante un peligro real. Sin embargo, es algo que se había comenzado a debatir con los cables diplomáticos difundidos por Wikileaks allá por 2010. Si bien en muchos ámbitos lo que hoy se conoce ya se hablaba hace tiempo e incluso se asumía, para muchos es algo completamente nuevo. De todas formas, para quienes nos preocupamos por el resguardo de la privacidad y la toma de conciencia respecto a los riesgos referidos con las nuevas tecnologías, toda situación que permita el debate y conocimiento de la problemática es bienvenida.



Lo que no deberíamos hacer es dejar pasar el momento e interés que generó en la opinión pública el cuidado de la privacidad ya que no son frecuentes. Pero si tenemos que ser sinceros, ¿acaso alguien dejó de almacenar información en EEUU conociendo la existencia del Patriot Act? ¿acaso se presentó una baja masiva de usuarios de las plataformas involucradas en el espionaje de la NSA? ¿acaso alguien ahora lee los permisos que requiere una aplicación móvil antes de instalarla en su smartphone?


El espionaje por parte de los Gobiernos es peligroso, incluso en algunos países se lo relaciona con las épocas más oscuras de la historia. El Estado siempre termina siendo el más fuerte, sobre todo si del otro lado se encuentran los ciudadanos de a pie. Quizás lo más preocupante de todo este tema es el nivel de des-protección con el que podrían sentirse los ciudadanos cuando es el Estado quien "decide" espiarlos. Acuerdos Internacionales, Organismos Independientes de control y demás herramientas políticas y diplomáticas podrían formar parte del conjunto de medidas para minimizar la falta de garantías de los ciudadanos, aunque podría incluso también ser insuficiente.

Pero sin olvidar que este es un blog de seguridad informática (y porque saben como pienso sobre estos temas), entiendo que tendríamos que mirarnos un poco al espejo. Amigos, ¿tenía que surgir #snowden para que nos preocupe la privacidad? ¿tenía que conocerse que muchas plataformas tecnológicas de uso masivo brindan información al Gobierno, para que nos empecemos a preocupar por lo que subimos/publicamos en internet?

Creo que tenemos que ser menos hipócritas y asumir nuestro compromiso, ocupar nuestro lugar. Lo que se conoce generalmente es lo que nosotros permitimos que se conozca, más allá de algún caso específico en el cual el Estado es quien cuenta con la información, en lo que tiene que ver con las redes sociales y servicios masivos, nosotros somos los que damos la información. Somos los que por una entrada de cine no tenemos reparos en brindar con lujo de detalles nuestros gustos e intereses, somos los que en twitter publicamos la foto de nuestro vehículo nuevo y lo que estamos comiendo en las vacaciones. ¿Estamos evaluando los riesgos ante cada publicación?

No debería confundirse que lo que intento decir es que no utilicemos internet o los servicios actuales, ya que eso seguramente sería un error en la mayoría de los casos, lo que intento decir es que no deberíamos utilizar un servicio (cerrando un contrato) sin conocer los términos y condiciones, sin leer la cláusula de privacidad y seguridad. ¿Por qué si lo hacemos en algún otro ámbito de la vida, lo relajamos cuando se trata de internet?


¿Acaso a partir de #snowden surgieron las técnicas de cifrado o borrado seguro? están allí hace años, muchos las conocemos y sin embargo muy poca gente las utiliza. A veces parece algo osado hablar de cifrado cuando quizás aún no contamos con la realización de copias de resguardo como un hábito elemental, o la utilización de un antivirus, sin embargo, muchas herramientas que tienen años de madurez podrían minimizar el impacto de una brecha o fuga de información. Si aún no hacemos copias de resguardo, ni utilizamos un antivirus, seguro cualquier propuesta de cloud computing sea algo mejor, pero la solución no es "escapar" al cloud, sino realmente gestionar mejor nuestra información, asignarle un valor y aplicar medidas de protección relacionadas con ello. ¿Cuánto vale la infancia de nuestros hijos en fotos? ¿Cuánto vale la investigación que estoy desarrollando hace varios meses? ¿Qué valor tiene el resultado de un examen clínico? ¿Cuánto vale la idea de mi próximo proyecto? Todo eso hoy está en internet, quizás con el mismo nivel de protección que este post. No creo que lo mejor que podamos hacer para mejorar esa situación sea asombrarnos del espionaje...

Tampoco creo que debamos bajar el nivel de disgusto sobre las actividades reveladas por #snowden que involucran a EEUU y que podrían involucrar a varios países más, pero también creo que en muchos casos nos estamos sumando al reclamo, cuando al instante dejamos de interesarnos por nuestra privacidad.

Como indica el título de este post, ¿y ahora nos preocupamos por la privacidad?

Gracias #snowden, la seguimos...

Contribución gracias a Mariano M. del Río @mmdelrio
Leer más...

17 julio 2013

Seguridad en entornos de movilidad

¿Y si cambio el portátil corporativo por mi Tablet? 

Últimamente todo el mundo habla de Bring Your Own Device (trae tu propio dispositivo, en inglés) como una de las modas que está revolucionando los entornos corporativos. De hecho, está suponiendo un importante impacto (y también un pequeño desconcierto) en las empresas, porque extiende los límites operacionales de la organización fuera del entorno TIC y los responsables de TI tienen que tomar medidas, y hacerlo de forma urgente.

El desafío es poder atender un entorno tremendamente heterogéneo, dando soporte multidispositivo y multisistema operativo,  preservando la seguridad de la información corporativa y estableciendo políticas y normas que dicten cómo utilizar esos dispositivos dentro de la organización (y respetando los derechos del propietario del dispositivo !!!???).

Como en cualquier entorno de movilidad corporativo,  además de utilizar soluciones de antivirus, bloqueo, borrado remoto, ubicación por GPS, etc., es necesario que entendamos y securicemos todo el circuito end-to-end de acceso y de uso de la información.



Y si se trata de dispositivos BYOD, como añadido hay que  entender las diferencias entre éstos y los corporativos, y definir estrategias y políticas específicas para nuestra organización. En este sentido, hay dos grandes tendencias radicalmente opuestas (y entre este blanco y negro muchos niveles de grises):
La política del todo (“todos a bordo”) conlleva aplicar exactamente el mismo tipo de políticas, normas de uso y soluciones tecnológicas a los dispositivos corporativos que a los “BYOD”. Esta estrategia tiene ventajas de gestión, ya que se pueden aplicar las  mismas soluciones de MDM, antivirus, NAC, infraestructura de acceso y cifrado de las comunicaciones, entre otras. Pero también tiene bastantes desventajas para el propietario: ya no voy a poder acceder a todas las apps, markets y servicios en la nube que quiera, por la política de uso de mi compañía, ni navegar por donde quiera, porque habrá un control de navegación. Además, en caso de pérdida o robo se puede llegar a borrar todos los datos, tanto corporativos como personales, aunque si bien es cierto que tecnologías como Knox prometen acabar con este problema.

La tendencia opuesta es aplicar la política de la parte. Es decir,  viajas en mi barco, pero poco y solo a donde yo digo. Consiste en gestionar la seguridad BYOD aplicación a aplicación, generando aplicaciones seguras. Algunas de los elementos de seguridad que se utilizan en estas aplicaciones seguras son: biometría para la autenticación de usuario, VPN propia solo para la aplicación, no copy&paste fuera de la aplicación, políticas de uso horario y temporal, sandbox cifrado, etc. Todas ellas se pueden ejecutar para acceder a servicios corporativos concretos y con requisitos de seguridad distintos uno a uno. Desde un punto de vista puro de seguridad, lógicamente no es lo mismo securizar la aplicación individual que securizar el dispositivo y además las aplicaciones, ésta también es una vía legítima que puede resolver parcialmente el problema, al menos hasta que la separación efectiva y segura de entornos corporativo y personal en el mismo dispositivo esté suficientemente probada y madura para su aplicación  práctica.

Y la pregunta es: ¿Cuál de las dos estrategias es la mejor? Dependerá totalmente de las necesidades y cultura  de cada organización (sí, la cultura puede influir y mucho). Al final los responsables de TI necesitarán dar respuesta al usuario de una forma segura, cómoda y con usabilidad, donde no siempre el todo o nada, es válido.


-------------------------------------------------

Contribución gracias a Manuel Sampedro
Leer más...

16 julio 2013

Monitorizar ficheros y carpetas en Windows y Linux

En muchas ocasiones resulta interesante tener la capacidad de poder monitorizar ciertas carpetas de cara a saber la actividad que se produce en ellas en un momento determinado.

Bien sea porque estamos ejecutando un programa del que no tenemos su código fuente y queremos saber 'que toca' (ejemplo típico cuando analizas malware), o bien porque simplemente queremos saber en tiempo real cuando un fichero es accedido, creado o alterado.

Después de buscar soluciones, encontré una que permite hacerlo de forma multiplataforma (windows / linux), su nombre: fsmonitor

fsmonitor es en realidad una librería en Python y una suerte de ejemplos que la acompañan.

En Linux, se basa en inotify para monitorizar, y en Windows emplea ReadDirectoryChangesW

Viene con dos ejemplos / utilidades que permiten hacer exactamente lo que dice el título del post: monitorizar ficheros y carpetas

El primer ejemplo es en modo gráfico:


Como podemos ver, estamos monitorizando la papelera en un sistema Windows mientras hacemos un 'vaciar papelera'. Cabe señalar que fsmonitor, en Windows, detecta como modificación un acceso al fichero, es decir, la alerta se genera con la misma descripción tanto ante un acceso (ver contenido) como si se altera, en Linux si discrimina entre una cosa u otra.

Veamos un ejemplo por línea de comandos en Linux:

# python dirwatch.py /tmp

create /tmp holamundo
attrib /tmp holamundo
modify /tmp holamundo
access /tmp holamundo

Bonus: Cómo hacer que Windows actualice la fecha de acceso a ficheros

Durante las pruebas con fsmonitor, descubrí que algunos sistemas Windows no actualizan la fecha de acceso a los ficheros, en principio pensé que era un fallo de fsmonitor, luego descubrí que simplemente ese campo no se actualizaba. Se supone que es una forma de optimizar el rendimiento

El efecto final es que fsmonitor era incapaz de alertar cuando un fichero era accedido

Indagando, encontré una solución: emplear el comando fsutil para hacer que Windows guarde esa información.

(desde un cmd.exe) Primero ejecutamos:

fsutil behavior query disablelastaccess

Si obtenemos:

disablelastaccess = 1

Significa que tenemos deshabilitada esa opción. Debemos activarla ejecutando:

fsutil behavior set disablelastaccess 0

Y luego re-iniciando Windows
Leer más...

15 julio 2013

Libro: Ethical Hacking 2.0




En el año 2012, tuve el honor de ir como speaker al Congreso de Seguridad más reconocido en Latinoamérica: Ekoparty. Allí, aparte de pasármelo genial con un montón de amigos y conocidos del sector, tuve la oportunidad de desvirtualizar a un montón de lectores argentinos, todos ellos curiosos por la seguridad. Con algunos ya había intercambiado algunos tweets, y otros espontáneamente se me presentaban como lectores. Entre los del primer grupo, conocí a Héctor Jara presentado por nuestro colaborador Mariano del Río, con quien tuvimos la oportunidad de compartir buenos momentos, durante la estancia en el Congreso. En los últimos días, Héctor me contó que había escrito un libro junto a un amigo, Federico Pacheco sobre metodología de pentest y que me quería regalar un ejemplar dedicado. 

En general, no me regalan libros todos los días, (aunque en Latinoamérica siempre tienen esos bonitos detalles), se lo acepté con una gran ilusión. 

Ya con tiempo decidí devorarlo de principio a fin y ofrecer mi crítica a los lectores de Security By Default. 

El libro Ethical Hacking 2.0, que ya promete al estar prologado por el gran Claudio Caracciolo, se trata de un enfoque metodológico de penetration testing, explicado en un lenguaje bastante llano, sencillo, que resulta agradable a la lectura, de muy fácil digestión. Habla del hacking en general, se centra en el hacking ético, una forma de abrir el melón que es un test de intrusión. Delimita las diferentes fases de informtion gathering, análisis de vulnerabilidades, búsqueda de puntos débiles y exploiting. Además, tiene capítulos específicos destinados a ataques web, infraestructura e ingeniería social.

Aparte del formato en papel (reconozco que los libros me gustan en formato físico), el ejemplar que me regalaron es de tapas blandas y de un tipo de hoja bastante agradable al tacto (sé que no aporta nada al contenido) pero mejora bastante la "experiencia de usuario". 
Igualmente, en la parte inferior de casi todas las hojas, los autores regalan al lector, en un cuadro de texto, perlas resumidas que enlazan a herramientas, blogs, historia de la seguridad, etc,…  relacionadas con la materia que se está leyendo en cada capítulo.

Se puede adquirir a través de la web de la editorial Red Users o vía Amazon

En mi opinión, un libro que barre un amplio espectro de conocimientos de hacking, pero sin profundizar en ninguno de ellos de una forma especial.   


Como digo, el lenguaje es muy asequible y los contenidos, pese a ser bastante básicos, creo que resultarían de gran interés para muchos aquellos lectores que nos envían correos preguntándonos por dónde empezar en el mundo de la seguridad. La lectura de este libro no les convertiría, ni mucho menos, en grandes maestros shaolin del hacking, pero les daría un muy buen punto de entrada, clarificando y ordenando un montón de conceptos de seguridad. y sobre todo, de metodología, sin entrar en términos ni demostraciones complejas. 
Leer más...

14 julio 2013

Enlaces de la SECmana - 183

Leer más...

12 julio 2013

GooDork, Google Hacking desde la línea de comandos

Quien se inicia en el mundo del hacking y/o el pentesting en sí, ha oído hablar del llamado "Hacking con buscadores", me refiero a términos como Google hacking, Bing hacking etc...

Ha habido distintas herramientas a lo largo del tiempo que se han usado para estos menesteres. El hacer Google hacking no significa que sea solo para encontrar sitios vulnerables. Puede ser que sea por ejemplo para encontrar FTP's abiertos con MP3 disponibles para descargar. :D La otra vertiente de la que podemos sacar provecho es usar estos dorks para encontrar servidores o páginas webs presuntamente vulnerables.

Seguro que mas de uno/a recuerda algunas de las herramientas que pongo a continuación.

Una de las primeras herramientas que personalmente pude ver para hacer Google hacking desde Windows era esta:


¿A alguien le trae buenos recuerdos?

Luego tenemos proyectos como los de Stach&Liu


El artículo de hoy no va sobre este proyecto sino sobre GooDork. Podremos hacer Google Hacking desde la línea de comandos!

Para usar la herramienta la clonamos desde el GitHub.

darkmac:~ marc$ git clone https://github.com/k3170makan/GooDork.git
Cloning into 'GooDork'...
remote: Counting objects: 103, done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 103 (delta 53), reused 95 (delta 46)
Receiving objects: 100% (103/103), 32.96 KiB, done.
Resolving deltas: 100% (53/53), done.

Para poder usarlo hay que instalar dependencias, en mi caso solo ha echo falta instalar BeautifulSoup4. Se puede instalar vía pip o easy_install.

Vamos a hacer una búsqueda.


Aquí tenemos la respuesta por parte de servidor, ahora veremos que es lo que ha encontrado.


Podemos acotar más la búsquedas:


La herramienta es muy sencilla de usar:


Si no tenemos mucha idea de como escoger los dorks adecuados podemos visitar webs tan emblemáticas como:


No hará falta que diga que se podría hacer un módulo para SQLmap que buscara algo parecido a:


Y lanzará sqlmap directamente, pero no daremos más malas ideas :P

[+] Github del Proyecto: https://github.com/k3170makan/GooDork
[+] Web con el artículo del autor: http://blog.k3170makan.com/2012/03/goodork-super-charging-your-google.html
[+] Web con múltiples Google Dorks: http://www.exploit-db.com/google-dorks/


Artículo cortesía de Marc Rivero López


Leer más...

11 julio 2013

Análisis Forense en Linux: Analizando la memoria con Volatility



Como indicaba en un post anterior, una de las cosas que conté en el curso de Análisis Forense que dictamos Conexión Inversa  y Securízame, cuya experiencia relató genialmente Pedro Sánchez, fue el análisis de la memoria de un sistema Linux. Para ello, primero adquiríamos una imagen de la misma, sin alterar la evidencia, con LIME, en RAW. 

Ahora es cuando toca, con ayuda del cincel y el martillo extraer una bonita estatua del bloque de piedra de la sucesión de 1s y 0s que es la memoria en crudo.

La ventaja de trabajar directamente contra la memoria es que es independiente de los rootkits que puede tener la máquina. Me explico: Si nos conectamos por consola al equipo comprometido y ejecutamos un ps o un netstat, si el sistema operativo ha pasado por hábiles manos, puede que veamos todo, excepto lo que el atacante quiera (ocultación de procesos o de sockets abiertos mediante rootkits). Sin embargo, si le extraemos el cerebro completo, es decir la memoria, leeremos directamente de éste lo que la máquina sabe, pero no nos quiere contar por interfaz de comandos.

Para ello, una de las mejores herramientas que hay es Volatility, que además de estar disponible tanto para Windows como para Linux, nos permite realizar montones de operaciones sobre la memoria adquirida. Entre otras, puedes extraer la tabla de conexiones, entradas ARP, ficheros abiertos, módulos cargados, procesos existentes, etc,…. que había en el momento del volcado de memoria.

Los parámetros que tenemos que pasar a Volatility son, obviamente, la imagen de memoria sobre la que vamos a trabajar, la operación a realizar (ver conexiones, procesos, etc,…) y un perfil que contiene el formato o la estructura de memoria del sistema operativo del que tenemos la imagen de la memoria. Y aquí,… con el clero hemos topado! Cuando hablamos de una imagen de memoria de un sistema operativo Windows, no hay ningún problema, puesto que Volatility trae incorporados los perfiles para Windows, dependiendo de la versión del mismo, el Service Pack aplicado, si es de 32 o 64 bits, etc,… Pero en el caso de Linux, donde cada distribución añade el kernel que quiere, lo compila con los módulos que quiere y versiona como quiere,… es imposible que Volatility disponga de todos ellos.

Así pues, nos tocará crear un perfil basado en la estructura de memoria del sistema objetivo. Para contaminar lo mínimo posible la evidencia (en este caso nada), aprovecharemos la máquina que hemos instalado anteriormente para crear el módulo de LIME, y que tiene el mismo kernel que la que queremos analizar, y crearemos el perfil Volatility aquí. Para ello:

1.-) Instalaremos paquetes con dependencias que sean necesarias. En el caso de CentOS, tuve que instalar kernel-devel, make, gcc, gcc-c++,….

2.-) Descargamos libdwarf, y compilamos a mano e instalamos “warfdump”

3.-) Descargamos Volatility for Linux con "svn checkout http://volatility.googlecode.com/svn/trunk/tools/linux volatility-linux-profile"

4.-) Al ejecutar un make, nos generará un fichero llamado "module.dwarf"

5.-) Para generar el perfil (que no es más que un zip), ejecutamos "zip module.dwarf /boot/System.map-`uname-r`", conteniendo las estructuras del kernel y los mapas de símbolos necesarios para entender correctamente la estructura de la ristra de 1s y 0s que hay en el fichero de la memoria.

6.-) En la máquina en la que vayamos a hacer el análisis forense y tengamos Volatility, copiaremos este fichero .zip a /usr/local/lib/python2.7/dist-packages/volatility/plugins/overlays/linux/

7.-) Ejecutamos "vol.py --info | grep -i linux" y nos aparecerá el perfil creado para Linux (y los que tuviéramos de antes) así como una lista de los comandos que podemos utilizar

Así ejecutaremos vol.py –f --profile y veremos qué secretos escondía la máquina en su memoria.
Por poner un ejemplo de la salida de uno de los comandos existentes, aquí podemos ver  la lista de sockets abiertos:

root@lawcaine:/tmp# vol.py -f mem.raw --profile CentOSx64 linux_netstat
Volatile Systems Volatility Framework 2.3_beta
UNIX /dev/log
TCP      0.0.0.0:22    0.0.0.0:0     LISTEN              sshd/940  
TCP      :::22    :::0     LISTEN              sshd/940  
TCP      0.0.0.0:0     0.0.0.0:0     CLOSE             httpd/1000 
TCP      :::80    :::0     LISTEN             httpd/1000 
TCP      0.0.0.0:0     0.0.0.0:0     CLOSE             httpd/1072 
TCP      :::80    :::0     LISTEN             httpd/1072 
TCP      0.0.0.0:0     0.0.0.0:0     CLOSE             httpd/1073 
TCP      :::80    :::0     LISTEN             httpd/1073 
TCP      0.0.0.0:0     0.0.0.0:0     CLOSE             httpd/1074 
TCP      :::80    :::0     LISTEN             httpd/1074 
TCP      0.0.0.0:0     0.0.0.0:0     CLOSE             httpd/1075 
TCP      :::80    :::0     LISTEN             httpd/1075 
TCP      0.0.0.0:0     0.0.0.0:0     CLOSE             httpd/1076 
TCP      :::80    :::0     LISTEN             httpd/1076 
TCP      0.0.0.0:0     0.0.0.0:0     CLOSE             httpd/1077 
TCP      :::80    :::0     LISTEN             httpd/1077 
TCP      0.0.0.0:0     0.0.0.0:0     CLOSE             httpd/1078 
TCP      :::80    :::0     LISTEN             httpd/1078 
TCP      0.0.0.0:0     0.0.0.0:0     CLOSE             httpd/1079 
TCP      :::80    :::0     LISTEN             httpd/1079 


Volatility en Linux dispone de un montón de comandos que permiten analizar la situación real de la máquina, en base al análisis de la memoria extraída, sin tener que confiar en una interfaz que puede haber sido preparada maliciosamente, por parte de un atacante experimentado.   
Leer más...