miércoles, 26 de noviembre de 2014

Robas el WiFi al vecino? Cuidado !!!

lunes, 24 de noviembre de 2014

HTTP fingerprint- HTTP anti- fingerprinting.

Una de las tareas mas importantes para un administrador de sistemas, relacionado o comprometido con la seguridad, es la de implementar medidas anti-fingerprinting en sus servidores.


Ocultar la versión concreta de un servicio, o incluso ocultar el nombre del propio servicio es algo básico para dificultar a los atacantes maliciosos la obtención de información, que sin duda, usarán para intentar comprometer el sistema buscando un exploit publicado.

En esta ocasión vamos a comentar algunas cositas sobre el reconocimiento o fingerprinting de un web server.

Una de las acciones básicas es cambiar el banner del servidor mediante Mod Security,

SecServerSignature "Nginx"

Podemos cambiar otro tag en Httaccess tan sencillo como esto:

Header unset X-Powered-By

Vamos a ver que opinan las herramientas.
Wappalyzer
Openvas.
Nikto 

Ahora voy a bajar una herramienta clásica en la obtención de información, Httprint de Net-square. Ejecutamos el reconocimiento...


Ups, parece que no se traga el banner de Nginx, y detecta a la perfección la versión de Apache.

Voy a probar con una herramienta on-line para los mismos menesteres, HTTPRECON.


Recordar que podemos bajar un cliente Windows de Httprecon desde aquí.

Al parecer las herramientas generalistas que usamos para el pentesting no reconocen bien la versión del webserver, por lo que tenemos que acudir a herramientas específicas de reconocimiento HTTP.

Una de las medidas extras que vamos a realizar es borrar los Etags de Apache.

Header unset ETag
FileETag None


Ahora parece que tenemos algo más de información anti-fingerprint.


Espero que os sirvan estas medidas de seguridad básicas para vuestros servidores web, y las herramientas mencionadas para fingerprint vuestros ( o ajenos) servidores.

Gracias por leerme.



viernes, 21 de noviembre de 2014

Auditoria IT. Netwrix. Parte 2. Eventos en Active Directory.

Espero que os gustará el último artículo sobre la plataforma Auditor 6.5 de la compañía Netwrix 


En esta ocasión vamos a configurar unas cuentas opciones a nivel de Active Directory, algo que podéis hacer sin la necesidad de la herramienta.

La idea es preparar la estructura base de seguridad en nuestro Active Directory, para luego gestionarla desde la consola de Netwrix Auditor 6.5.


Lo primero que voy a hacer es desde un controlador de dominio, voy a crear una política de seguridad para añadir todas las opciones que voy a habilitar, y así poder indentificar facilmente a la hora de ajustar.


De esta manera vamos a habilitar la auditoría de acceso a objetos de Active Directory, eventos relacionados con la administración, con los inicios de sesión...

El siguiente paso es habilitar un tamaño aceptable al log, a los registros del Visor de Eventos.


Hemos asignado un tamaño máximo de retención de logs de 1gb. 1048576 kilobytes

Accedemos a Usuarios y Equipos de Active Directory y habilitamos las opciones avanzadas.


Accedemos a la opción de auditoría.


Creamos una entidad de auditoría, para el grupo de usuarios TODOS, y habilitamos todas las opciones salvo las 3 que se aprecian en la imagen.


Ahora vamos a configurar la auditoría del esquema Active Directory, algo importante para auditar :-)



Para hacer un resumen, hasta este punto, hemos habilitado la auditoría de objetos Active Directory. Podemos comprobar que realmente se están monitorizando los cambios.

Voy a tomar un usuario y voy a agregarlo al grupo de administradores de Active Directory.

Volvemos a Netwrix Auditor 6.5 y ejecutamos manualmente la recolección de datos. Automáticamente recibimos un correo con la información de cambios.


Como podemos apreciar, nos indica que un usuario se ha activado (estaba desactivada la cuenta) y se ha añadido al grupo administradores.

En el caso de sufrir un incidente de seguridad en nuestra organización, la elevación de privilegios es uno de los pasos que realizará un atacante para conseguir aumentar sus acceso. De esta manera, podemos detectar una intrusión o simplemente un cambio de configuración no autorizado.

Vamos a realizar otra prueba, crear una simple unidad organizativa.


Una de las configuraciones que debemos realizar es la programación de estas notificaciones. Por defecto se hará una vez al día, a las 3 de la mañana. Podemos cambiarlo desde aquí.


Ahora es el turno de visualizar las opciones de reporting que nos genera la herramienta.

Vamos a seleccionar uno al azar, para ver como se genera un report.


Otra de las opciones que más interesante me parece es la de poder revertir la configuración de Active Directory a un estado anterior. Cada vez que se hace una recolección de información, se genera un SnapShot del estado del sistema. Podemos usar esta instantánea para revertir el estado. Las imágenes hablan de lo sencillo del proceso.


Creo que ha quedado suficientemente claro las posibilidades que nos ofrece esta plataforma, Netwrix Auditor 6.5 por un precio bajo. Si hay más de un sysadmin para Active Directory, o se manejan un gran número de usuarios, una herramienta para la detección de cambios es necesaria. 

En otras entregas de Inseguros hablaremos de otros módulos del programa para monitorizar cambios en otras plataformas, como pueda ser Vmware, muy interesante en mi caso.

Espero que os guste, gracias por leerme !!!




jueves, 20 de noviembre de 2014

Auditoria IT. Netwrix.

Estimados amigos de Inseguros.

En el episodio de hoy vamos a trabajar con una herramienta de auditoría IT llamada Netwrix Auditor 6.5


Para empezar, debemos entender que es el proceso de auditoría IT. No estamos hablando de los mismos procesos y herramientas que nuestras auditorías de seguridad, aunque ambas se entrelazan de la mano ya que un despliegue de nuestros activos IT de manera correcta y segura, incide directamente en la seguridad de nuestros sistemas.

Imaginemos un escenario con servidores de dominio Microsoft, Active Directory, 1000 usuarios, bases de datos, virtualización con Vmware, intranet con Sharepoint, Sql Server de aplicaciones. Lo que viene siendo la media de las empresas. Una o varias personas administrando los sistemas.

Imagino cientos, miles de objetos de seguridad auditados, como acceso a ficheros, lectura, borrado, creación. Objetos de seguridad relacionados con la autenticación. Cuentas de usuario, pertenencia a grupos, configuraciones de seguridad GPO. File Integrity Monitor de archivos confidenciales. Lo mismo para Sql Server/Exchange/Sharepoint etc.


Es difícil, casi imposible, manejar toda esa información en tiempo real. Información que nos aporte valor para poder actuar, y por qué no decirlo, para cumplir con los requisitos de las certificaciones PCI, COBIT y demás de la industria IT.

Netwrix nos permite gestionar toda esta información de manera centralizada mediante un cuadro de mando. Más de 200 informes predefinidos que nos muestran la información de manera intuitiva, no navegando por el visor de sucesos. Con la herramienta podemos hacer seguimiento a todos los cambios en las configuraciones de objetos de Active Directory ( O Sql Server, Exchange o cualquier producto que licencies) e incluso revertir el estado de la configuración en un momento concreto, sin necesidad de backups. Esto sería una pieza indispensable en el plan de respuesta ante incidentes, en el caso de sufrir un incidente de seguridad interno. No todos los hackers son externos, están los que ahora se denominan Insiders !!!

Todo esto tiene un precio, 1/3 de lo que puede contar una licencia de antivirus.

Vamos a revisar la herramienta para detallar las funcionalidades.
Podeís descargar una versión Quick Guide la configuración para Active Directory.

Recordar que os podéis bajar una versión de prueba full-features para 20 días.

El proceso de instalación no podría ser tan sencilla como ejecutar el asistente. En el caso de no tener instalar el .Net Framework 3.5 o cualquiera otra dependencia (Sql Server Express Advanced  o STD), nos indicará como solucionarlo. Me resulta irónica decirlo, pero debes tener Windows 7 o superior ( o windows 2008 r2 o superior).

La pantalla de inicio podría ser esta.


Empezamos la configuración desde Managed Objects. Vamos a configurar el servidor de correo y de informes y los datos de usuario y contraseña con permisos en Active Directory, en este caso.



Sería interesante crearnos previamente una cuenta para este "servicio" con el fin de delimitar los permisos sobre los file-servers.










Si prestas atención a esta pantalla, hemos establecido que el concepto de cuenta inactiva es aquella que no producido actividad de Login en los últimos 30 días. Recordar que las cuentas de equipo tambien se auditan...Podemos desmarcar el check de Disable para que solo nos alerte, para hacer las pruebas.

Podríamos haber hecho algo parecido con Powershell, pero deberíamos configurar una tarea programada, que suelen ser un punto de "hackeo" habitual. Deberíamos cambiar los parámetros en modo texto, configurar un servidor de correo para el powershell, crearnos una plantilla. Sin duda, estas herramientas ayudan mucho con estas tareas. No obstante, os paso un posible Powershell:

get-aduser -filter * -properties lastlogondate | Where-Object {$_.enabled -eq "true"-and $_.lastlogondate -lt (get-date).adddays(-90)} | Set-Aduser -enabled $false

Comentar que de esta manera tiramos de aduser, no de adcomputer, por lo que deberíamos crear otra sentencia para las cuentas de equipo.


No es necesario configurarlo todo desde este asistente. En cualquier momento podemos acceder a Settings y añadir o modificar los datos tanto del servidor de correo como el SqlServer.

Una vez configurado nuestro primer objeto "managed" o gestionado vamos a ejecutar la comprobación de los datos actuales.



Una vez generada la recolección de datos, comienzan a llegarnos unos correos muy interesantes. Este respecto a la caducidad de cuentas.


Recuerda que esto es un requisito, por ejemplo, para PCI DSS 8.5.5.

8.5.5 Remove/disable inactive user 
accounts at least every 90 days.
8.5.5 Verify that inactive accounts over 90 days old are either 
removed or disabled

El siguiente correo que aprecio es relativo a la configuración de directivas de auditoría de Active Directory, que deben estar configuradas previamente para poder recolectar información.

Dejamos hasta aquí esta entrega sobre Netwrix Auditor 6.5

En el siguiente capítulo habilitaremos todas las opciones necesarias en los servidores de dominio respecto a la auditoría de cambios. Recuerda que este tipo de herramientas gestionan la información que hay configurada, realmente son consolas MMC (Microsoft Management Console) que leen información de Active Directory mediante LDAP.

Espero que os guste, y que uséis estas recomendaciones, independientemente de la compra de este producto o no.

Gracias por leerme !!!




miércoles, 19 de noviembre de 2014

All you need is Log !! Capítulo 1.

En el capítulo de hoy voy a comenzar una mini seria sobre el mundo de los logs.
Después de escribir varios artículos sobre OSSIM y tocando de cerca muchos conceptos de la gestión de eventos de seguridad de la información o SIEM, creo que debo empezar a comentar la base sobre la que se sostiene, los logs de información.

Todos los manejamos a diario, o deberíamos, pero leyendo muchos artículos, manuales y sobre todo, hablando con los compañeros, percibo un cierto desconocimiento de todo el poder que nos brindan, y que en pocas ocasiones veo en clientes buenos despliegues.

Quizás la primera tarea que debemos cumplir al iniciarnos en un proyecto de gestión de logs es la definición del propósito.

Debemos establecer el tiempo en el que mantendremos nuestros logs en cada sistema, según sea su propósito.

Pongamos el ejemplo de una infraestructura en la que contamos con un servidor web Apache, que escribe sus logs localmente en un fichero. Si estamos usando un servidor centralizado de logs debemos enviar los eventos a dicho servidor, pero debemos borrar los registros locales en el servidor Apache, ya que esa información ya se ha transmitido y nos genera espacio, y riesgo de fugas de información en caso de verse comprometido. Este post de Security By default nos da unas buenas pistas de como solucionarlo.


Si estamos usando un servidor para SIEM como OSSIM o Splunk, para gestionar eventos de seguridad, debemos de tener en cuenta que son sistemas para monitorizar la seguridad en tiempo real. Podemos hacer uso de las opciones de búsqueda para realizar un análisis forense de un suceso a investigar, pero no son herramientas diseñadas para ello, y puede que necesitemos cierta agilidad que no nos proporcionan estas herramientas. 

Para solucionar esta situación podemos instalar un segundo servidor de logs denominada Retención, en el que a priori, no realizaremos ninguna gestión diaria, pero la información estará disponible para futuras investigaciones.

Un ejemplo práctico y simple de entender. Puede que en nuestra consola de seguridad OSSIM descartemos los eventos de login correcto de los sistemas Windows, ya que solo genera "ruido" y puede que no solo no aporte información, sino que enmascare información real. PERO puede que esa información sin sea necesaria para investigar un Data Leak en un futuro.

Esta reflexión puede ser trivial, pero es importante realizar este esquema de funcionamiento y retención de logs entre los sistemas. Un fichero de log en un escenario de brute force, de DDOS, debug de algún sistema, o cualquier anomalía, puede crecer exponecialmente, sobrepasando nuestra "tranquilidad" de un fichero de unos cuantos MB a llenar el disco. Creerme, la solución no es comprar más discos.

Otra consideración a la hora de hacer este esquema es el de "inventariar" nuestras fuentes de logs, incluyendo en nuestra estructura centralizada todos los registros de sistemas que queremos monitorizar en tiempo real, o archivar. Seguro que haciendo esta auto-reflexión descubres servicios que llevabas MUCHO tiempo sin revisar sus logs.


En muchas escuelas, en distintas asignaturas se emplea la conexión: Dato, Información, Conocimiento. Que para nuestra aproximación nos viene genial

En la primera fase de nuestro despliegue de gestión de logs vamos a trabajar, a ser posible, a nivel DATO. Vamos a poner un ejemplo con Snort.

Si tenemos un paquete con el único flag FPU marcado Snort bien configurado seguramente nos tirará una alerta del tipo Nmap Xmas Scan.

El dato sería el stream tcp con la cabecera, el payload, TODO.
La información sería que estamos sufriendo un Xmas Scan.
El conocimiento podría ser si cruzamos la información de la ip de origen con una base de datos de reputación, en la que el conocimiento sea "Posible ataque desde esta IP maliciosa".

Si ponemos el ejemplo de un servicio web, el dato seria el registro concreto de la petición http, cookie, user-agent, etc.
La información podría ser una alerta de posible Sql Inyection.
El conocimiento podría ser si se detecta que la misma fuente está probando varias secuencias de comandos, o solo ha sido una botnet intentando explotar un fallo concreto.

No esperes llegar al conocimiento sin pasar por una buena gestión de información y por supuesto dato.

Podemos empezar a clasificar los logs según su categoría:
  • INFO.
  • DEBUG.
  • WARNING.
  • ERROR.
  • ALERT.
Esta clasificación suele ser estandard. Para el caso que vamos a estudiar en detalle, el formato SYSLOG, podemos encontrar con que la categoría se denomina Security Level y es tal que así, vía WIKIPEDIA( o mejor el RFC):


Podemos clasificar los logs según su manera de transmitir:
  • SYSLOG. Suele ser el formato nátivo de los sistemas Linux y puede transportarse mediante TCP y UDP. En formato texto sin cifrar.
  • WINDOWS EVENT: El formato nativo de los sistemas Microsoft, es un formato binario, por lo que necesitaremos una herramienta para visualizarlos.
  • SNMP: Algunos sistemas emplean este protocolo para el envio de tramas hacia un servidor central, las cuales c.ontienen la información de log.
  • DATABASE: Sistemas que escriben su información de logs directamente en una base de datos.
  • PROPIOS FABRICANTE.
De momento esto es todo por hoy sobre el mundo de los logs.

En próximas ediciones analizaremos en detalle más sistemas de logs y alguna herramienta para su gestión, aparte de OSSIM :-).

Espero que os guste, gracias por leerme.



martes, 18 de noviembre de 2014

Faraday. Un IDE para pentesting.

En el capítulo de hoy os voy a comentar una herramienta muy curiosa que ha caído por mis manos llamada Faraday. Introduce para mi el concepto de IPE, Integrated Pentest Environment.


Se trata de una aplicación que mediante plugins, modifica en "el aire" los comandos que introducimos por consola, añadiendo la salida de cada herramienta que es capaz de interpretar.

El proceso de instalación es un poco engorroso:

$ git clone https://github.com/infobyte/faraday.git faraday-dev
$ cd faraday-dev
$ ./install
Se conecta con una CouchDb para almacenar los resultados, y los presenta en pantalla de manera amigable.


Una de las funciones que me agradan de este IPE es la de autocompletar. Veamos un ejemplo con nmap.

El solo nos auto-completa el -P* y el -s*

Como se aprecia en el menú de la derecha, nos aparecen los equipos que vamos auditando. Podemos desplegar la información obtenida de escaneo Nmap.

Como podemos abrir varias shells, nos permite realizar múltiples escaneos, con distintas opciones, o distintos host, sean cual sean tus hábitos, toda la información que se va generando se aglutina de manera gráfica.

Hablando de interface gráfica, vamos a pulsar sobre las estadísticas y ver como se nos despliega un informe web con el resultado de nuestras pruebas.



En este vídeo podemos ver la herramienta en funcionamiento.


La lista de plugins para Faraday es la siguiente.
  • Retina, Retina Network 5.19.2.2718
  • Openvas, 2.0
  • BeEF, 0.4.4.9-alpha
  • Qualysguard, Qualysguard
  • Arachni, 0.4.5.2
  • Hydra, 7.5
  • Acunetix, 9
  • Dnsenum, 1.2.2
  • Nessus, 5.2.4
  • Sqlmap, sqlmap/1.0-dev
  • ftp, 0.17
  • Listurls, 6.3
  • whois, 5.0.20
  • Wapiti, 2.2.1
  • Netsparker, Netsparker 3.1.1.0
  • W3af, 1.2
  • ping, 1.0.0
  • Telnet, 0.17
  • Dnsmap, 0.30
  • Amap, 5.4
  • arp-scan, 1.8.1
  • Fierce, 0.9.9
  • X1, Onapsis X1 2.56
  • Burp, BurpPro 1.5.18
  • Metasploit, 4.7.2
  • Metagoofil, 2.2
  • Dnswalk, 2.0.2
  • Goohost, v.0.0.1
  • Theharvester, 2.2a
  • Nikto, 2.1.5
  • Core Impact, Core Impact 2013R1
  • Reverseraider, 0.7.6
  • propecia, 1.0
  • Dnsrecon, 0.8.7
  • Skipfish, 2.1.5
  • Nmap, 6.40
  • Medusa, 2.1.1
  • Nexpose, Nexpose Enterprise 5.7.19
  • Zap, 2.2.2
  • Webfuzzer, 0.2.0
  • Shodan
  • evilgrade, 2.0.6
Como nota negativa tengo que decir que me parece un proyecto MUY interesante, el cual venden de dos versiones superiores, de pago, pero la herramienta está muy inmadura. Funciona, pero va lento. No encuentro la documentación para importar la información que generan muchas de estas herramientas. Esto me hace pensar que si encuentro la manera de usarlos, en cuanto las herramientas cambien algún formato, la herramienta quedará colgada. Si, lo puedes hacer tú mismo...

Me ha parecido bien comentarla y animaros a probarla, lo mismo podéis contribuir con mas información que yo no he podido obtener.

Espero que os guste, gracias por leerme.