Cipherli.st: Configuraciones SSL robustas para servicios

El portal Cipherli.st realiza una labor más que interesante: recopilar en una sóla página fragmentos de configuraciones seguras para establecer el cifrado más fuerte posible en multitud de aplicaciones y servicios.

En ella podréis encontrar configuraciones de cifrado robustas para servidores web como Apache, nginx y Lighttpd. Sobre dichas configuraciones se puede realizar un copy/paste sobre nuestros ficheros propios, lo que hará fortificar al máximo recomendable la configuración referente a cifrado.

Configuraciones SSL recomendadas para los servicios web más usados

Obviamente, dichas configuraciones no son la panacea, y es recomendable estudiar el posible impacto de aplicarlas en entornos productivos. Eso sí, en caso de que al establecer esta configuración todo funcione a la perfección, podremos asegurar que nuestro servicio tendrá un nivel aceptable de seguridad SSL. Para estar totalmente seguros, siempre se puede recurrir a portales como SSL Labs de Qualys, que prueban la seguridad SSL de servicios web externos, ofreciendo consejos para su mejora en caso de detectar alguna mala práctica o posible configuración insegura. El objetivo siempre será conseguir un A+

Si bien inicialmente el portal se enfocó a servicios web, debido al auge de vulnerabilidades que ponían en entredicho a todo lo referente a SSL, poco a poco se han ido añadiendo fragmentos para otras aplicaciones como haproxy, postfix, exim, ProFTPd, OpenSSH (tanto cliente como servidor) entre otros. ¡Se aceptan pull requests!

Configuraciones SSL recomendadas para otros servicios

[+] Cipherli.st

Leer más...

[1/2] Seguridad en Redis - Fortificación

Si estás leyendo este artículo seguramente sea porque ya conoces Redis, un motor de base de datos basado en clave/valor que almacena los datos en memoria y que últimamente, debido al alto rendimiento que ofrece, está de moda.

En este artículo se detallarán medidas de seguridad a aplicar para asegurar su fortificación. 

En la mayoría de los sistemas Linux las instalaciones por defecto  ya tienen en consideración algunas de estas inquietudes, pero por requisitos o por instalaciones manuales en ocasiones son modificadas.

La propia documentación de Redis nos pone en aviso de que está diseñado pensando en los mundos de Yupi: "Redis is designed to be accessed by trusted clients inside trusted environments", algo extraño teniendo en cuenta que su autor es Salvatore Sanfilippo (antirez), al que conocemos de otros proyectos como hping 

1.- Escucha del servicio.

El demonio de redis debería escuchar únicamente en loopback o un socket de Unix. Si no, nuestro servicio será accesible a toda la red, por defecto, sin autenticación.

Para configurar las interfaces en las que escucha se debe modificar el fichero redis.conf y especificar las IPs en el parámetro bind y el puerto con el parámetro port, que en caso de ser 0, no permitirá conexiones TCP.

Tal y como comentaba inicialmente, esta configuración viene por defecto para 127.0.0.1 6379/tcp pero en ocasiones "pasan cosas", tal y como se puede ver en shodan 

port 6379
bind 127.0.0.1

En caso de que sea necesario el uso por red, es conveniente filtrar el puerto mediante un firewall en local.

# 6379 = redis port
# 10.1.2.3 = clientIP1
iptables -I INPUT -p tcp --dport 6379 -s 10.1.2.3 -j ACCEPT
iptables -I OUTPUT -p tcp --sport 6379 -d 10.1.2.3 -j ACCEPT

iptables -I INPUT -p tcp --dport 6379 -j DROP

Para habilitar el socket de unix se especifica mediante los siguientes valores.

unixsocket /var/run/redis/redis.sock
unixsocketperm 755

2.- Ejecución con los mínimos privilegios.

El servicio debe arrancarse bajo un usuario no privilegiado específico y si es posible, en un entorno enjaulado. Como veremos en el siguiente artículo esto puede volverse uno de los mayores problemas.

El cambio de usuario implica que los ficheros que utiliza el motor sean también propiedad de este usuario. Como son el fichero de PID (especificado mediante pidfile en redis.conf), el log (logfile) y los directorios de la base de datos (dir).

En caso de Ubuntu todos estos parámetros de arranque están en el propio script de inicio: /etc/init.d/redis-server, al igual que en CentOS: /etc/rc.d/init.d/redis

En general, estos parámetros también deben estar así si se instala un paquete, aunque por desgracia si se desea enjaular será necesario hacerlo manualmente.

pidfile /var/run/redis/redis-server.pid
logfile /var/log/redis/redis-server.log
dir /var/lib/redis

3.- Establecer autenticación. 

Este punto es crítico, ya que por defecto se puede acceder a la base de datos sin ningún tipo de autenticación. El acceso es total y permite ejecutar absolutamente todos los comandos de la base de datos.

Para establecer autenticación se debe especificar una contraseña (en texto claro) con el parámetro requirepass en el archivo redis.conf 

Redis no soporta usuarios ni roles, por lo que aquel que conecte tendrá todo o nada.

requirepass SuperInfinitoOOoOOoOO

Si la base de datos se replica, los esclavos deben de definir esta contraseña en su configuración.

masterauth SuperInfinitoOOoOOoOO

4.- Desactivar los comandos no usados.

La base de datos soporta decenas de comandos distintos. Algunos de ellos completamente innecesarios para el funcionamiento normal de la base de datos y mucho menos, para usuarios que no deberían tener privilegios de administración (como los desarrolladores).

Para desactivar un comando se renombra a "" (nada) y dejará de ser posible su uso. También se puede renombrar a algo desconocido para que solo aquellos que lo conozcan puedan hacer uso de la llamada.

Lo ideal es identificar los comandos que son necesarios y deshabilitar el resto, son especialmente peligrosos: FLUSHDB, FLUSHALL, CONFIG, DEBUG, MIGRATE, SLAVEOF y SHUTDOWN, Este último es usado para parar el servicio por los scripts de inicio y que por lo tanto requerirá que estos se modifiquen.

La lista completa de comandos se encuentra en: http://redis.io/commands

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command DEBUG ""
rename-command SHUTDOWN SHUTDOWNSECRET
rename-command CONFIG ""
rename-command MIGRATE ""
rename-command SLAVEOF ""
rename-command CLIENT ""
... otros rename-command ...

5.- Cifrado de tráfico entre cliente y servidor.

La comunicación entre cliente y servidor es en texto plano y nativamente no es posible aplicar ningún tipo de cifrado en esta conexión. Si la red no es confiable (ninguna lo es) se debe utilizar una segunda herramienta sobre la que delegarlo. Existen múltiples opciones como stunnel, socat o ssh.

# cliente
stunnel -c -d 6379 -r servidor_redis:1999
# servidor
stunnel -d 1999 -r localhost:6379 

6.- Almacenamiento  de registros.
Los ficheros de registro deben salvaguardarse en un directorio seguro. Estos archivos deben rotarse y mantener la misma política de seguridad que para otros registros del sistema. Si no se define logfile serán mandados a la salida estandar del sistema. Si el parámetro daemonize está activado, serán enviados a /dev/ null.

loglevel notice
logfile /var/log/redis/redis-server.log

Si fuera necesario, existe la posibilidad de mandar los ficheros a syslog.

syslog-enabled yes
syslog-ident redis
syslog-facility local0

7.- Ajustes de rendimiento.
Como comentábamos inicialmente redis está diseñado pensando en el rendimiento, por ese motivo cambiar ajustes que afecten a este aspecto es un problema importante. Desgraciadamente, obtener el máximo rendimiento y ser susceptible a una denegación de servicio abusando de los recursos de memoria o red suelen ir de la mano.

Para ajustar esta línea, se debe jugar con varios parámetros que permitirán que el servicio permanezca estable y siga siendo óptimo en su rendimiento. De momento no existe una fórmula mágica para definirlos, dependerá de las especificaciones hardware de los servidores, número de peticiones y otros factores.

maxclients XXXX
timeout XXX
tcp-keepalive XXX
maxmemory XXXXXXXXX

Referencias:

• http://redis.io/topics/security
• http://blog.7elements.co.uk/2012/03/installing-and-hardening-redis.html
• http://www.packtpub.com/article/using-redis-in-hostile-environment-advanced

Leer más...

Microsoft Security Compliance Manager

Microsoft Security Compliance Manager es una herramienta que facilita enormemente la gestión del bastionado de sistemas y servicios basados en tecnología Microsoft. Esta aplicación gratuita, actualmente en su versión 2.5, aunque disponible la beta de la 3. Permite distintos métodos de administración de la configuración de seguridad basados en plantillas. Por un lado descarga las Baselines de buenas prácticas creadas por la propia Microsoft y por otro, también crea una línea base en función a la configuración actual de un sistema, en caso de que la organización tenga parámetros distintos ya configurados.

Una vez se dispone de las baselines, ya sean creadas por los administradores o las propias de Microsoft, están se pueden comparar o exportar a distintos formatos, como son hojas Excel (para gestión), GPOs, SCAP, SCCM DCM o SCM (en el caso de que se deseen importar posteriormente). De tal forma que puedan ser aplicadas también en equipos fuera del dominio y por lo tanto fuera del alcance de la GPO.

Otra ventaja importante es la forma en la que aterriza los documentos del fabricante en medidas técnicas, detallando que hace cada una de las opciones, a que vulnerabilidad afecta, como se configura la solución y el posible impacto que pueda tener en los sistemas.

La pantalla principal está dividida en tres partes: las lista de baselines, tanto las propias "custom", como las de Microsoft, las configuraciones en la parte central, y las opciones a aplicar a las plantillas.

Si se despliegan las configuraciones y los detalles por cada una de ellas se observan los siguientes detalles:

La herramienta también es auto-actualizable en cuanto a las guías que soporta, por ejemplo, la versión 3.0 incluirá Hyper-V, Windows 8, Server 2012, Internet Explorer 10, etcétera.

Leer más...

Seguridad en Tomcat - JSESSIONID en la URL

En una análisis de seguridad reciente me he encontrado una vulnerabilidad (funcionalidad) del manejo de sesiones dependiente de los Servelts  de Java que no conocía.

Según parece, añaden la sesión de un usuario a la URL como parámetro con el objetivo de controlar aquellos navegadores que no soporten el manejo de esta cabecera (wtf?).

Este comportamiento provoca que esta información sea almacenada en registros de pasarelas HTTP intermedias o historiales de navegación. Una vulnerabilidad de sobra conocida y documentada.

La siguiente captura muestra un ejemplo del comportamiento descrito anteriormente:

Para solucionar el problema en Tomcat 7, que soporta la versión 3.0 de la especificación de Servlets, basta con añadir la siguiente configuración al fichero web.xml:



En el caso de Tomcat 6, que se basa en la versión 2.5, se ha de deshabilitar de la siguiente forma:

Leer más...

Fortificación de lighttpd

Lighttpd es otro servidor web libre y gratuito que está desarrollado con el objetivo de ser ligero y altamente eficaz.

Al igual que la semana pasada con nginx, vamos a repasar algunas directivas que pueden impactar en la seguridad y que se han de tener en cuenta en una instalación o auditoría.

Lo primero y más básico es arrancar el servicio con un usuario no privilegiado, por lo que el fichero de configuración ha de incluir dos lineas como las siguientes:

server.username = "lighttpd" 
server.groupname = "lighttpd"

Para evitar que se generen listas del contenido de un directorio en caso de no existir un archivo index.html, es necesario deshabilitar el parámetro dir-listing tal de la siguiente forma:

dir-listing.activate = "disabled" 

Para modificar la cabecera Server y no mostrar la versión y producto del servidor web se especifica la cadena en server.tag:

server.tag ="HTTPD"

Si se desea restringir el acceso a determinadas extensiones de ficheros, que pueden existir residualmente o ser de configuración, puede hacerse como en este ejemplo:

url.access-deny = ( "~", ".inc", ".bak" )

Si el servidor no va a recibir ficheros, también se puede limitar el tamaño de una petición a 1kb, 

server.max-request-size  = 1

TRACE y TRACK, no están soportados en lighttpd, pero para deshabilitar todos los métodos menos los esencialmente necesarios como son GET, HEAD y POST:

$HTTP["request-method"] !~ "^(GET|HEAD|POST)" {
url.access-deny = ( "" )
}

Si queremos molestar a los auditores y denegar el acceso a algunas herramientas automáticas en base a su user-agent, se puede hacer con una expresión regular. ¡Ojo!, que esto es fácilmente evadible y sirva más de ejemplo para evitar bots o ataques concretos.

$HTTP["useragent"] =~ "(acunetix|nikto)" {
url.access-deny = ( "" )
}

Para evitar que las imágenes del servidor sean enlazadas desde otro sitio (hotlinking), tan solo hay que añadir las siguientes líneas:

$HTTP["referer"] !~ "^(hxxp://sbd\.com|hxxp://www\.sbd\.com)" {
url.access-deny = ( ".jpg", ".jpeg", ".png", ".gif" )
}

El status es un módulo que muestra información sobre el servidor, en ocasiones estos datos pueden incluir datos confidenciales y debería estar restringido a direcciones IP. Si no se utiliza, es aconsejable eliminarlo, borrando la línea que contenga "status.status-url" y verificando que no está cargado en "server.modules"

status.status-url = "/server-status"
server.modules = ( ..., "mod_status", ... )

Por último, si se hace uso de SSL, es recomendable deshabilitar la v2 y algunos ciphers. Una configuración robusta (a falta de parche para BEAST) podría ser esta:

ssl.use-sslv2 = "disable"
ssl.cipher-list = "TLSv1+HIGH !SSLv2 RC4+MEDIUM !aNULL !eNULL !3DES @STRENGTH"

Para restringir un recurso a varias direcciones IP, rangos o localhost, lighthttpd permite este tipo de sintaxis:

$HTTP["remoteip"] !~ "192.168.1.3|10.0.5.*|127.0.0.1" { 
   $HTTP["url"] =~ "^/Admin/" { url.access-deny = ( "" ) }
}

En caso de querer proteger un directorio con usuario y contraseña, del RFC 2617 se ha de usar digest y nunca basic, con una sintaxis del módulo mod_auth, similar a la siguiente

auth.backend = "htdigest"
auth.backend.htdigest.userfile = "lighttpd-htdigest.user" 
auth.debug = 2

auth.require = ( "/protected/" =>
    (
    "method"  => "digest",
    "realm"   => "Nombre de mi directorio con Password",
    "require" => "valid-user"
    ),
)

Para crear el fichero lighttpd-htdigest.user:

# htdigest -c lighttpd-htdigest.user 'Nombre de mi directorio con Password' aramosf

Leer más...

Fortificación de nginx

nginx es un popular servidor web y proxy inverso libre y gratuito que ya aloja más de 43 millones de dominios, entre los que se encuentra Wordpress, Dropbox, Facebook o TechCrunch.

En esta entrada vamos a ver algunos aspectos a configurar para que su instalación sea más segura.

Lo primero es eliminar información que identifique la versión de nginx todo lo que se pueda. Esto no hace el servicio más seguro, pero pone trabas a la hora de intentar buscarle fallos.

Para eliminar la cadena "nginx" de la cabecera Server, es necesario modificar el código fuente, en concreto del fichero  src/http/ngx_http_header_filter_module.c  siguientes líneas:

static char ngx_http_server_string[] = "Server: nginx" CRLF;
static char ngx_http_server_full_string[] = "Server: " NGINX_VER CRLF;

Por

static char ngx_http_server_string[] = "Server: httpd" CRLF;
static char ngx_http_server_full_string[] = "Server: httpd" CRLF;

Si únicamente se desea eliminar el número de versión, dejando  tan solo "nginx", o no se puede recompilar, en la configuración se puede especificar con la directiva:

server_tokens off;

Una vez instalado, hay que asegurarse de que no se ejecuta con un usuario con privilegios de administración. En su configuración ha de figurar el usuario y grupo son distintos de root.

user              nginx nginx;

La identificación de la versión también es posible si se observan los mensajes de error del servicio. Para asegurar que no se reporta en ningún momento lo mejor es modificar las siguientes líneas del fichero src/http/ngx_http_special_response.c:

static u_char ngx_http_error_full_tail[] =
"<hr><center>" NGINX_VER "</center>" CRLF
"</body>" CRLF
"</html>" CRLF
;


static u_char ngx_http_error_tail[] =
"<hr><center>nginx</center>" CRLF
"</body>" CRLF
"</html>" CRLF
;

Por otras que no incluyan la variable NGINX_VER:

static u_char ngx_http_error_full_tail[] = CRLF;
static u_char ngx_http_error_tail[] = CRLF;

También se puede especificar en el fichero de configuración, dentro de server {}, cuáles serán las páginas de error personalizadas para cada una de los errores. En este ejemplo se redirige a error.html:

error_page 400 401 402 403 404 405 406 407 408 
409 410 411 412 413 414 415 416 417 495 496 497 500 501 502 503 504 
505 506 507 /error.html;
location /error.html {
    internal;
}

Una vez modificado el código fuente, se compila deshabilitando todos los módulos que no se usen. La web de nginx facilita una lista completa con su descripción. Especialmente interesante de eliminar es el autoindex. Para deshabilitar se utiliza una línea como la siguiente:

./configure --with-http_ssl_module --without-http_autoindex_module
--without-http_browser_module --without-http_fastcgi_module
--without-http_geo_module --without-http_empty_gif_module 
--without-http_map_module  --without-http_proxy_module
--without-http_memcached_module --without-http_ssi_module
--without-http_userid_module  --with-http_ssl_module 

Como se gestionan los recursos dependerá más de las necesidades de rendimiento que de la propia seguridad, salvo se detecte y conozca algún fallo concreto. Si es posible y no impacta a este factor, se especifican tamaños de buffer pequeños donde sea más difícil explotar una vulnerabilidad.

client_body_buffer_size 1K;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;
client_body_timeout 10;
client_header_timeout 10;
send_timeout 10;
keepalive_timeout 60 60
send_timeout 60

Otra directiva interesante es activar la opción para ignorar todas las cabeceras invalidas:

ignore_invalid_headers   on;

Para deshabilitar métodos HTTP, la mejor opción es usar listas blancas, marcando únicamente aquellos que se vayan a utilizar. Esta configuración también afecta al rendimiento, ya que procesar la expresión regular es costoso. También es importante destacar que nginx no soporta el método TRACE, ni PUT/DELETE/MKCOL/COPY/MOVE siempre y cuando no se compile con soporte Webdav

if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 500;
}

Otras características interesantes son la posibilidad de devolver un código de error en base al user-agent o al referer con una expresión regular, tal y como se muestra en el siguiente ejemplo, que además no hace distinción entre mayúsculas y minúsculas al haber especificado: ~*

if ($http_user_agent ~* (acunetix|nikto) ) {
  return 500;
}
if ($http_referer ~* (porn|webcam|bing) ) {
return 500;
}

También es posible evitar que enlacen directamente a las imágenes (hotlinking)  desde la configuración de nginx:

location ~* (\.jpg|\.png|\.css)$ {
 if ($http_referer !~ ^(hxxp://www.sbd.com) ) {
  return 500;
 }
}

Por último, si el servicio necesita servir páginas mediante HTTPS, una configuración válida y robusta que evita el ataque BEAST es la siguiente:

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1;
ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=2592000; includeSubdomains";

Aunque es aconsejable saber los requerimientos de navegación y comprobar los resultados en el servicio de análisis de SSL de Qualys.

Leer más...

Buenas prácticas de seguridad para publicación de proyectos

Ayer os contábamos el caso del malware incrustado en el instalador de CamStudio, probablemente debido a una intrusión en el servidor de descargas y modificación del fichero de instalación.

Éste no es un caso aislado, y es que a proyectos tan importantes como irssi, Wordpress, UnrealIRCd, ProFTPd o recientemente vsftpd también les ha pasado algo parecido.

Si bien no se puede decir que sea inevitable, se pueden tomar algunas medidas de seguridad para que las posibilidades de que ésto suceda se reduzcan al mínimo, o ayudar a detectar el problema lo antes posible para aplicar una solución.

1.- Publicar hashes de los ficheros

Ya sea mediante MD5, SHA1, SHA512, WHIRLPOOL u otro que nos guste más, es básico publicar junto con el paquete la huella del mismo para que los usuarios que lo descarguen puedan comprobar que es el mismo fichero que el autor subió. La elección del algoritmo debería depender del tamaño de los ficheros y la popularidad del mismo, por ejemplo, MD5 sería una buena opción para ficheros grandes por ser rápido y SHA1 para los pequeños.

Por supuesto, las huellas y los ficheros de descarga deben estar en diferentes sitios independientes.

2.- Publicar firmas GPG de los ficheros

La idea es la misma que la anterior, pero utilizando GPG en vez de hashes.

3.- Separar sitio web y sitio de descargas

Por una razón lógica, y es que si consiguen hacer una intrusión en uno habrá discordancias que permitirán detectar el problema rápidamente. Por ejemplo, si tenemos los hashes en el sitio web y vulneran el sitio de descargas para reemplazar un paquete, no podrán cambiar también el hash de dicho paquete, y tanto los usuarios como el administrador podrán ver rápidamente que algo no funciona como debería.

4.- Evitar alojamientos o servicios compartidos

Para que no nos pase lo mismo que a Ettercap deberíamos evitar servicios compartidos de alojamiento como SourceForge o Google Code. Un fallo de seguridad en su sistema puede afectarnos directamente.

Por el mismo motivo también deberíamos evitar alojamientos compartidos, donde se comparte un único espacio con múltiples clientes.

5.- Comprobar la integridad de los ficheros en algún proceso

Si el proyecto consta de instalación no está de más que se compruebe la integridad del paquete durante el proceso teniendo como referencia los hashes almacenados en nuestro servidor. Si el proyecto no consta de instalación, se podría programar un pequeño script que realizara el proceso.

Con estas medidas podemos reducir significativamente el riesgo de que nuestro proyecto sufra alguna modificación malintencionada externa. ¿Se os ocurre alguna medida más? ¿Creéis que son medidas excesivas? ¿Las cumplen los proyectos, especialmente los de productos relacionados con la seguridad?

Leer más...

F*CKTool - Herramienta de Fortificación y configuración de Kioscos

En la actualidad, multitud de información o servicios se ofrecen al público a través de ordenadores encerrados en un armazón, con posibilidad de pantalla táctil, situados en diferentes puntos tales como mercados, parques, o zonas de turismo. Estos ordenadores son conocidos como kioscos interactivos.

Los kioscos interactivos proveen un servicio de interés para la diferente audiencia a la que se dirige, pero también provee un sistema al que atacar si no está lo suficientemente protegido o fortificado tanto física, como lógicamente.

En nuestra memoria quedan diferentes ataques perpetrados hacia estos dispositivos como la reproducción de

una película de contenido indecoroso a la vista de cualquier viandante.

La herramienta F*CKTool (Herramienta de Fortificación y configuración de Kioscos) ha sido desarrollada como proyecto final del Máster Universitario de Seguridad de las Tecnologías de la Información y las Comunicaciones de la Universidad Europea de Madrid dirigido por Alejandro Ramos Fraile.

Escrita en Visual C# para su utilización en plataformas .Net, esta herramienta permite fortificar sistemas Microsoft Windows 7 cuyo funcionamiento es muy sencillo e intuitivo.

La operación de fortificación se realiza sobre el registro del sistema (regedit.exe) Windows, aunque también se modifican otros componentes como las listas ACL (Access Control List) para cambiar permisos de acceso a determinadas aplicaciones de configuración del sistema que deben ser ocultas para un usuario del kiosco interactivo.

La herramienta actúa sobre los siguientes ámbitos de fortificación:

1. Navegador web Internet Explorer: El navegador web constituye una fuente de amenazas para la obtención de información del sistema a través del navegador. Se han aplicado una serie de opciones de fortificación que harán  que el usuario pueda modificar muy pocas configuraciones del navegador.
   Algunas a destacar:

• Modo FullScreen.

• Eliminación de ficheros temporales, cookies, historial de navegación.

• Desactivación de tecnologías como Flash, Microsoft SilverLight, PDF, etc.

2. Opciones del sistema: Entre muchas otras opciones, destacan las que deshabilitan e impiden la ejecución de aplicaciones o programas de configuración del sistema.

• msconfig.exe
• cmd.exe
• regedit.exe
• activación del firewall
• Desactivación del panel de control

3. Sistema de ficheros: La herramienta permite denegar el acceso a operaciones de escritura sobre la partición del sistema. De esta forma se consigue que si un usuario se descarga algún fichero, no lo pueda escribir o almacenar en dicha partición.

4. Dispositivos externos: Otro aspecto en el que se hace especial hincapié, lo representan los dispositivos de    almacenamiento externo, ya que un usuario podría instalar ficheros autoarrancables en ellos e intentar ejecutar programas con el objetivo de comprometer la disponibilidad del kiosco. La herramienta desactiva los puertos USB, la unidad de CD-ROM.

Como líneas de trabajo futuras, se pretenden incluir las siguientes mejoras:

• Opción para instalar y configurar IE para su ejecución dentro de una sandbox.
• Ampliar opciones de fortificación de Windows.
• Difusión de la herramienta entre las empresas de software de gestión de kioscos.
• Ejecución bajo Microsoft Windows XP.
• Permitir a los administradores de kioscos añadir opciones de fortificación introduciendo los valores del registro adecuados.

Cabe destacar que F*CKTool no sólo realiza una completa fortificación del sistema Windows del kiosco, sino que además es capaz de realizar la operación inversa.

Para los que queráis probar la herramienta, siempre bajo vuestra responsabilidad ya que los creadores no se hacen cargo del uso indebido o inadecuado ni de los efectos de la misma, la podéis encontrar aquí. Son necesarios privilegios de administrador.

[+] Página del proyecto F*CKTool

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

Autores del proyecto:

• Sergio Adrián Trujillo
• Santiago Álvarez Román
• Ernesto Corral Messía de la Cerda
• Joaquín Pano Bueno

Leer más...

ArpON para defenderse de ARP Spoofing/Poisoning y otros vicios

ArpON es un programa que pretende securizar ARP para mitigar ataques de tipo Man In The Middle (MITM) mediante ARP Spoofing/Poisoning, además de detectar y bloquear ataques derivados más complejos del estilo de DHCP Spoofing, DNS Spoofing, WEB Spoofing, Session Hijacking y SSL/TLS Hijacking.

Está pensado para funcionar en modo demonio, y actualmente está adaptado para sistemas GNU/Linux, Mac OS X, FreeBSD, NetBSD y OpenBSD.

Podemos encontrarlo en los repositorios de algunas distribuciones de GNU/Linux, o descargarlo desde su sitio web, donde hace unos pocos días publicaron la versión 2.2.

Implementa los siguientes algoritmos:
- SARPI - Static ARP inspection: Redes sin DHCP. Utiliza una lista estática de entradas y no permite modificaciones.
- DARPI - Dynamic ARP inspection: Redes con DHCP. Controla peticiones ARP entrantes y salientes, cachea las salientes y fija un timeout para la respuesta entrante.
- HARPI - Hybrid ARP inspection: Redes con o sin DHCP. Utiliza dos listas simultaneamente.

Una vez instalado la activación no es muy compleja. Tendremos que editar su fichero de configuración (/etc/default/arpon en Debian) para definir un algoritmo, la interfaz, el log y fijar el inicio en el arranque.

En modo DARPI, el log nos informa de las peticiones ARP entrantes que podrían ser un ataque, su bloqueo, y las peticiones verídicas.

  12:12:35 - Wait link connection on wlan0...
  12:12:43 - DARPI on dev(wlan0) inet(192.168.1.2) hw(ca:fe:ca:fe:ca:fe)
  12:12:43 - Deletes these Arp Cache entries:  # Al inicio se borran las entradas.
  12:12:43 - 1)     192.168.1.1 ->   fa:ba:da:fa:ba:da
  12:12:43 - Cache entry timeout: 500 milliseconds.
  12:12:43 - Realtime Protect actived!  # Protección activada.
  12:12:44 - Reply   << Delete entry  # Intentos de ARP Spoofing (entradas no verídicas).
192.168.1.1 -> fa:ba:da:fa:ba:da
  12:12:54 - Reply   << Delete entry
192.168.1.1 -> fa:ba:da:fa:ba:da
  12:13:04 - Reply   << Delete entry
192.168.1.1 -> fa:ba:da:fa:ba:da
  12:13:06 - Request >> Add entry 192.168.1.1  # Petición propia de refresco.
  12:13:06 - Reply   << Refresh entry 192.168.1.1 -> be:be:be:be:be:be  # Entrada verídica (respuesta dentro del timeout).

En mi caso no ha funcionado bien el arranque al inicio, ya que no detectaba la interfaz. Además, prefiero elegir en qué interfaz activar la protección y cuando, por lo que he hecho un script para lanzarlo cuando lo desee (algoritmo DARPI).

#!/bin/bash

if [ $# -ne 1 ]; then
        echo "Help: enable-arpon interface"
        echo "  Ex: enable-arpon eth0"
else
        /usr/sbin/arpon -q -f /var/log/arpon/arpon.log -g -d -i $1
fi

Como bien comentan en la documentación, la protección ideal sería tener todas las interfaces de la red protegidas con ArpON para conseguir una protección bidireccional en las comunicaciones.

Sin duda, un demonio que no debería faltar en ninguna máquina que se pasee por redes extrañas de cuando en cuando.

Leer más...

Hardening PHP mediante php.ini

En algunas ocasiones una buena configuración nos puede salvar de un fallo de programación que pueda desembocar en una brecha de seguridad. Es el caso de PHP, cuya configuración tiene algunas medidas de seguridad que pueden ser útiles.

Vamos a ver estas opciones centrándonos en las versiones actuales de PHP5 y con PHP6 ya en mente.

El fichero de configuración de PHP es php.ini. Puede estar localizado en diferentes directorios según plataforma o distribución, por ejemplo en Ubuntu está en /etc/php5/apache2/php.ini

- open_basedir

Si está definido, limita todas las operaciones con ficheros a la ruta especificada (root de PHP) y las contenidas por ella. Nos ayuda a evitar vulnerabilidades del tipo Directory Traversal. Esta directiva no está afectada por el hecho de que el modo seguro (Safe Mode) esté On u Off.

Ejemplo:

open_basedir = /var/www/

- disable_functions

Deshabilita funciones de PHP. Podemos quitar funciones peligrosas como system() o exec() para restringirlas en el proceso de desarrollo, o prevenirnos de ellas en el entorno final. Si un usuario consigue subir y ejecutar un script PHP (por ejemplo una shell) no podrá ejecutar las funciones definidas en la directiva. No es una garantía, ya que aunque no se puedan usar comandos del sistema se pueden utilizar otras funciones de PHP, pero puede servirnos para hacerle perder tiempo a un atacante, evitar ataques genéricos, e incluso defendernos de un atacante con pocas habilidades técnicas en PHP.

Ejemplo:

disable_functions = system, exec, php_uname

- display_errors

Habilita o deshabilita que se muestren los errores de PHP (el log no se verá afectado). En el proceso de desarrollo es algo tedioso tenerlo deshabilitado, pero en el entorno final nos ayuda a que un atacante no descubra la estructura de nuestra aplicación, lo que le hará más complicada la detección y explotación de un fallo.

Ejemplo:

display_errors = Off

- register_globals [Obsoleto desde PHP 5.3.0]

Habilita o deshabilita que las variables EGPCS (Environment, GET, POST, Cookie, Server) sean globales o no. Si está habilitado permite el uso de variables sin especificar cual es su origen. Desde PHP 4.2.0 la directiva está fijada en Off por defecto.

Ejemplo práctico:

Cuando nosotros le pasamos a un script una variable por GET (/script.php?nombre=Pepe), si tenemos activado register_globals la variable en el código podrá ser utilizada como $name, en cambio, si lo tenemos desactivado tendremos que usar la variable como $_GET["name"]. La segunda forma es más segura (y a nivel de desarrollo opino que mejor), ya que un atacante no podría inyectarnos variables en un origen desde otro ($_POST vía $_GET por ejemplo).

El único motivo para habilitar esta característica es que nuestra aplicación sea antigua y el uso de variables sea el obsoleto. Aún así, es recomendable actualizar el código al segundo modelo.

Ejemplo (recomendado):

register_globals = Off

- Deshabilitar Remote File Includes

En algunas ocasiones los desarrolladores hacen inclusiones de código incluyendo en ellas datos que introduce el usuario. Si un atacante identifica una, puede utilizarla para incluir y ejecutar su propio código de forma remota, sin tener permisos de escritura en el servidor (RFI). Más información en php-security.

Ejemplo (recomendado):

allow_url_fopen = Off

allow_url_include = Off

- file_uploads

Habilita o deshabilita la subida de ficheros mediante HTTP. Si nuestra aplicación no usa subida de ficheros es una buena idea deshabilitarlo.

Ejemplo:

file_uploads = Off

- magic_quotes_gpc y magic_quotes_runtime [Obsoleto desde PHP 5.3.0]

Con estas funciones podemos escapar caracteres que pueden causar problemas con la interacción de bases de datos y permitir inyección de sentencias (como ' o "). No es una protección adecuada, por lo que es necesario utilizar las funciones específicas para solucionar estos fallos.

Ejemplo:

magic_quotes_gpc = On

magic_quotes_runtime = On

- safe_mode [Obsoleto desde PHP 5.3.0]

Es un intento de solucionar los problemas de hosting compartido a nivel de PHP. Por defecto compara el UID de ficheros cuando se intentan abrir. Permite algunas características adicionales.

Ejemplo:

safe_mode = On

Referencias:

- PHP: Security

- Hardened-PHP

- Hardening PHP from php.ini

Leer más...

Secure Sanitizer, limpiar de forma segura el caché de tu Firefox

Cuando pensamos en navegación privada, una de las primeras cosas de las que siempre nos preocupamos es de borrar todo el rastro que hayamos podido dejar en el navegador una vez terminada la navegación.

Por supuesto, es una buena medida, pero ineficiente si pensamos en que esos datos se pueden recuperar, ya que normalmente los navegadores no hacen un borrado seguro.

Ésto es lo que intenta solucionar Secure Sanitizer, un complemento para Firefox que añade opciones de borrado seguro cuando eliminamos los datos privados de navegación. A cambio, solo sacrificaremos unos cuantos segundos adicionales en el proceso de borrado.

Concretamente añade dos opciones (además de borrado normal):

• Random data (fast) - Sobreescritura con datos aleatorios.
• US DoD 5220 3 steps (secure) - Método de borrado introducido por el Departamento de Defensa de EEUU. Más seguro que la sobreescritura simple.

El complemento se integra con Firefox en la opción de borrado de datos privados de la siguiente forma:

Por supuesto, también es compatible con Iceweasel:

En las últimas versiones de Firefox, cuando lo configuramos para que se borren los datos de navegación de forma automática cuando se cierra, no aparece este cuadro de dialogo. El autor recomienda instalar otro complemento llamado AskForSanitize para forzar que aparezca cuando se cierra, y así verificar que los datos se borran de forma segura.

Sin duda, otro complemento obligatorio para aquellos que quieren un poquito más de privacidad.

Leer más...

Información disclosure en los correos de notificación al sistema

Es importante que los administradores/operadores de sistemas reciban en tiempo real las notificaciones de los eventos críticos. En la mayoría de los sistemas estos correos de notificación son enviados en texto plano, suponiendo un riesgo si contienen información que pueda ser usada por un atacante para acceder a un equipo.

Normalmente se suelen enviar correos de monitorización de alarmas, como sucede en los sistemas puros de monitorización de sistemas (como Nagios) o en sistemas de centralización de eventos de seguridad (o SIEM). Estos correos de notificación reportan información interna de la red o de elementos remotos que monitorizan. También las tareas programadas basadas en el demonio cron envían por defecto la salida estándar de una tarea en texto plano como pueden ser: chkrootkit (monitorizar posibles rootkits en el sistema), AIDE/Tripwire (integridad de ficheros), fail2ban (baneo mediante iptables por intentos excesivos de login hacia sshd, ftpd...), logcheck o logwatch (notificación de posibles eventos en los logs del sistema), etc.

Podemos ver en el cron el script para ejecutar chkrootkit:

  [root@se cron.daily]# more chkrootkit

  #!/bin/sh

  /usr/bin/chkrootkit | mail -s "Daily chkrootkit from se" lain@localhost

En los logs del cron /var/log/cron vemos como se lanza la tarea:

  Nov 23 03:25:05 se run-parts(/etc/cron.daily)[7082]: starting chkrootkit

  Nov 23 03:25:21 se run-parts(/etc/cron.daily)[8594]: finished chkrootkit

Mediante Wireshark capturamos el correo donde vemos como se envía en texto plano:

Una notificación de red puede facilitarnos información disclosure como por ejemplo, usuarios logeados, ficheros que cambian, eventos notificados por correo, posibles cuentas de correo de sysadmins o del departamento de seguridad.

Vemos otro ejemplo de una salida del log de logcheck:

  Nov 16 17:40:01 se cron[18283]: (root) CMD (logcheck finished && mail lain@localhost )

Email de monitorización de logcheck que circula por la red:

  [header removed]

  To: lain@localhost

  Subject: se 11/16/10:14.00 system check

  Unusual System Events

  =-=-=-=-=-=-=-=-=-=-=

  Nov 16 13:00:01 se kernel: grsec: exec of

  /usr/bin/logtail (/usr/bin/logtail /var/log/iptables.log ) by

  /bin/bash[sh:17739] uid/euid:0/0 gid/egid:0/0, parent

  /bin/bash[sh:17725] uid/euid:0/0 gid/egid:0/0

  Nov 16 13:00:01 se kernel: grsec: exec of

  /usr/bin/logtail (/usr/bin/logtail /var/log/pax.log ) by

  /bin/bash[sh:17740] uid/euid:0/0 gid/egid:0/0, parent

  /bin/bash[sh:17725] uid/euid:0/0 gid/egid:0/0

  Nov 16 13:00:01 se kernel: grsec: exec of

  /usr/bin/logtail (/usr/bin/logtail /var/log/grsec.log ) by

  /bin/bash[sh:17741] uid/euid:0/0 gid/egid:0/0, parent

  /bin/bash[sh:17725] uid/euid:0/0 gid/egid:0/0

  grsec: From 192.168.13.77: exec of /usr/sbin/useradd (useradd ) by

  /bin/bash[bash:18333] uid/euid:0/0 gid/egid:0/0, parent

  /bin/bash[bash:18311] uid/euid:0/0 gid/egid:0/0

  grsec: From 192.168.13.77: exec of /bin/dmesg (dmesg ) by

  /bin/bash[bash:18334] uid/euid:0/0 gid/egid:0/0, parent

  /bin/bash[bash:18311] uid/euid:0/0 gid/egid:0/0

  ...

Como podemos ver, este simple correo nos da suficiente información como para ir organizando un poco la metodología de trabajo del administrador del servidor. A qué hora se envía, a qué destinatario (es una cuenta externa), el kernel usa grsec, se analizan los logs en busca de eventos para iptables, pax/grsec. El usuario root conecta desde la máquina 192.168.13.77 a este servidor por lo que no hay una buena configuración del demonio SSH. En general es información sensible que no debe circular por la red.

Si un atacante consiguiera acceso a un servidor de una organización podría capturar los paquetes que circulan por la red, estos podrían serle de utilidad para acceder a determinadas máquinas y obtener datos que más tarde le servirían para obtener información vital a la hora de hacer un pentesting.

Cualquier red es sniffable, si no es mediante un MitM, se puede intentar conseguir acceso al switch, podría ser que usasen VLANs pero hay técnicas para saltárselas o unirse a una VLAN. Destacamos la herramienta Yersinia de s21sec que surge tras la necesidad de realizar ataques de capa 2.

- Contramedidas:

Para evitar poner en manos de un atacante este tipo de información, se deberían empezar a concienciar en la necesidad de cifrar los correos de notificación al sistema. Lo ideal sería que la organización incluyera una política de cifrado para todos los correos, pero ¿en cuántas organizaciones se cifran los emails? A no ser que estén supeditados por auditorías o contengan información con un alto grado de confidencialidad, bien sabemos que pocas. Debemos concienciarnos que el cifrado de los correos es vital para mantener la confidencialidad de la información que circula por nuestra red. Y ya no hablemos de información corporativa como puede ser documentación interna, contratos, facturación, etc.

Nos replanteamos nuestras notificaciones de las tareas programadas cifrando los correos de notificación:

Modificamos nuestro script de logwatch, cifrando con GnuPG los correos enviados, previamente habremos importado la clave publica del destinatario:

  [root@se cron.daily]# more logwatch

  #!/bin/sh

  /usr/sbin/logwatch | gpg -ea -r "Recipient" | mail -s "Daily logwatch from se" lain@localhost

Podemos ver en el log de cron la tarea ejecutada:

  Nov 21 15:38:25 se run-parts(/etc/cron.daily)[3224]: starting logwatch

  Nov 21 15:38:32 se run-parts(/etc/cron.daily)[5171]: finished logwatch

Capturamos la traza que se envía por red, y vemos como el correo ha sido cifrado:

Además de los correos de notificación del sistema, debemos tener en cuenta los mensajes que se envían desde Syslog. Syslog es un sistema de gestión de logs en red que registra información sobre actividades del sistema operativo, anomalías, alertas, errores, accesos correctos/incorrectos al sistema, etc. y también se envían mensajes en texto plano que podrían facilmente ser capturados por un sniffer. Para mantener la confidencialidad de la información que viaja por la red podríamos usar Stunnel para que los datos viajen cifrados mediante SSL/TLS.

Estas medidas harán que la información viaje por la red de forma más segura manteniendo la confidencialidad de los datos, y así se lo pondremos un poco más difícil a los atacantes que intentan comprometer nuestros sistemas.

Artículo cortesía de: Laura García.

Leer más...