Una sonda en las Webs de SMS gratuitos

Hace algunos días y realizando un proceso de registro en un servicio Web me solicitaron un número de teléfono al que enviar un SMS para confirmar la cuenta que estaba creando, de modo que busqué algún servicio gratuito al estilo de 10minutemail pero aplicado a mensajería SMS y encontré el artículo que escribió Yago Jesús: Cómo obtener números SMS temporales .

Una vez introducido el número de teléfono en el servicio que estaba registrando y como estaba tardando más de la cuenta la recepción del SMS, aproveché para dar una vuelta por estas Webs de SMS públicos y curiosear.

Encontré que gran cantidad de los servicios gestionaba correctamente la cantidad de información expuesta al enviar credenciales de acceso parciales:

Mientras que en otros casos no han sido tan cuidadosos y han expuesto los credenciales de acceso al completo:

También se pueden encontrar publicadas licencias de uso de servicios:

E incluso transacciones de banca online:

O deducirse ataques por fuerza bruta al ver el mismo patrón prolongado durante horas:

...

Como dudo que sea el primero o el último que mire con curiosidad estos servicios he querido hacer una última prueba, crear un sencillo honeypot:

Y publicar en cada página de SMS unos credenciales de acceso distintos para el honeypot:

El honeypot no tiene nada más que una pantalla de inicio de sesión y si se supera el proceso de login una pantalla que indica que se encuentra en mantenimiento.
Aquí lo interesante de la prueba es confirmar si hay personas o sistemas barriendo estos servicios para intentar acceder a información con los credenciales publicados, y esto queda confirmado como podéis ver en el enlace directo al fichero de log del honeypot, aunque no existe un alto grado de actividad, podemos confirmar que desde luego hay movimiento:

Os dejo también unos enlaces a una herramienta que he desarrollado para descargar todos los SMS de algunas de estas Web. Con sólo ejecutar ya se encarga él solito de descargarlo todo a un CSV, y podéis pararlo y volver a iniciarlo y continuará por donde se quedó:

• Proyecto en GitHub
• ZIP con la aplicación

Tenéis más información en su README, pero en resumen la herramienta os dará las siguientes posibilidades:

• Se puede dejar en ejecución e irá capturando todos los nuevos SMS que no haya procesado previamente
• A través del fichero SMShound.exe.config podréis establecer diferentes variables como el tiempo entre descargas de nuevos SMS, parámetros de envío de correo o rutas a ficheros de salida y entrada de datos
• Descargar los SMS a un fichero en formato CSV para su posterior análisis. Si detenéis la aplicación (cerrando la ventana o con CONTROL+C) podréis volver a iniciarla y continuará descargando desde donde se quedó
• Definir en un fichero palabras_clave.txt palabras especiales a buscar entre los mensajes. Cuando la aplicación los detecte enviará los SMS por email a la cuenta que hayáis configurado
• Y por último y os sirve más allá de su alcance actual,  podéis ajustar el código del proyecto para recolectar información de otros servicios.

Conclusiones finales

Como habéis visto en las capturas de ejemplo hay que tener cuidado con los servicios en los que nos registramos utilizando estos números de teléfono para recibir el SMS, un mal servicio podría enviar un SMS exponiendo públicamente información personal como nuestro nombre real o el de usuario, la dirección de correo, una contraseña que utilicemos o incluso una licencia de uso (permitiendo a una herramienta automatizada robar ese dato).

Artículo cortesía de Miguel Ángel García

Twitter: @nodoraiz

Leer más...

¿Anonimato con un proxy? tal vez no

Todos conocemos que existen distintos tipos de proxy web cuando buscamos anonimato en la red. Distinguiendo entre nombres como "anónimo", "altamente anónimo" o incluso "élite".

Su denominación varía según la información que es enviada al servidor remoto en forma de cabeceras HTTP. Entre estas cabeceras es común encontrar:

• X_FORWARDED_FOR: esta cabecera no está definida en el RFC de HTTP, ha sido creada por el proxy cache "Squid" con el objetivo de enviar la dirección IP del cliente al servidor Web. Dada su popularidad es se le ha dado relevancia y actualmente es soportada por la mayoría de aplicaciones. A tener en cuenta que es transmitida por el cliente y por lo tanto puede ser modificada, por lo que ningún control de acceso debería confiar en esta información, al igual que ocurre con otras cabeceras como User-Agent o Referer. No es común que los servidores a los que accedemos almacenen esta información en vez de la dirección IP del proxy, pero puede ocurrir, lo que significa que no somos tan anónimos como nos imaginamos.
  


• VIA: Definida en el RFC como obligatoria cuando es usado un servidor proxy indica el camino que ha seguido la petición desde su origen al destino, identificando los protocolos que se han seguido. El objetivo principal de esta cabecera es evitar bucles infinitos.

Una vez hemos configurado el proxy en nuestro navegador, se puede conocer si estas cabeceras están siendo utilizadas accediendo a una página web del tipo "Cual es mi IP", que nos mostrará si utilizamos proxy o no y las direcciones IP que es capaz de detectar. Otra opción es hacer nuestro propio script donde se muestren las cabeceras enviadas con algo tan simple como:

<?php
foreach($_SERVER as $h=>$v)
if(ereg('HTTP_(.+)',$h,$hp))
echo "<li>$h = $v</li>\n";
header('Content-type: text/html');
?>

Pero estas cabeceras HTTP no son la única forma de conocer la dirección IP real de un cliente u otra información de interés, estos datos puede ser filtrados mediante otras técnicas, entre ellas:

1. Peticiones DNS del cliente web, que solicita la dirección IP de un subdominio monitorizado, de esta forma el servidor DNS de ese dominio será capaz de averiguar el servidor DNS que utiliza el cliente y por lo tanto compañía y localización.
   
2. Peticiones DNS desde applet Java, utilizando la socket API se solicita la resolución DNS de un subdominio, si este no es el mismo que el que sirve el applet, se genera una excepción de seguridad y no produce resultado, aunque la petición de DNS es enviada y al igual que en el punto anterior, se podría conocer los servidores DNS del cliente.
   
3. Envío de paquetes UDP en applet Java, mediante el envío de un paquete UDP al servidor que sirve el applet es posible conocer la dirección IP de origen, este método no funciona con las últimas versiones de Java y requiere que el destino sea el propio que sirve el applet.
4. Acceso a IP y hostname mediante la API de socket de Java, que permite obtener el nombre del sistema y su dirección IP mediante un applet, esta información puede revelar la IP interna del equipo (en caso de NAT) o uso de proxy.
5. Mediante un paquete TCP en Flash, que revela la dirección IP de origen y que no utilizará la configuración proxy que tenga el navegador.
   
6. Con Microsoft Office, si este está configurado para que abra directamente los documentos y estos contienen imágenes serán descargados sin utilizar el proxy.
   
7. Utilizando plugin de Quicktime, que mediante un parámetro permite solicitar que la conexión se haga directamente contra el servidor remoto evitando el uso de proxy.
   
8. Con el protocolo "itms://" de iTunes, en caso de tener instalado este software, si se accede a una dirección del tipo "itms" esta conexión se realiza sin utilizar la configuración del proxy del navegador.
   

Todas estas técnicas las ha implantado HD Moore en el sitio: http://decloak.net/. Esta aplicación online permite realizar un test sobre nuestro navegador una vez hemos configurado el proxy tratando de conseguir la dirección IP real de nuestro equipo.

Además permite la descarga del código fuente del applet de los puntos 2 y 3 y el flash del punto 5.

Algunas compañías que trabajan con comercio electrónico ya están haciendo uso de estas técnicas para evitar fraudes y conocer el origen real de los ataques que reciben.

Si lo que queremos es evitar esta identificación, solo cabe utilizar un navegador sin ningún tipo de complemente instalado, como son Java, Flash, iTunes u Office, eliminar la conexión directa con Internet, es decir, que nuestro sistema no pueda salir a Internet sin utilizar un proxy y utilizar servidores DNS públicos como OpenDNS.

Leer más...

Listas de correo de seguridad.

Este resumen no está disponible. Haz clic en este enlace para ver la entrada.

Leer más...

La búsqueda del Google .uk revela detalles de más de 19.000 tarjetas de crédito

Los caminos del buscador de Google son inescrutables, y si no, que se lo pregunten a más de 19.000 británicos consumidores de servicios de comercio electrónico, que pudieron observar asombrados como los datos al completo de sus tarjetas de crédito aparecían como resultados de este gigante tan referenciado por aquí.

Lo más ¿gracioso? de todo es que dichos datos no quedaban disponibles a causa de un fallo en el servicio de shopping online, mediante querys imposibles con el buscador y demás, si no que era información que había sido previamente obtenida por un grupo de cibercriminales, y posteriormente subida a internet para poder ser vendida a otros delincuentes en la India.

El servidor, alojado en Vietnam, ya había sido cerrado, pero la caché de Google que sabemos que funciona a la perfección para según que servicios, conservaba una copia, fácilmente indexable, buscable, crawleable...

Según Google, los datos han sido retirados, y según la asociación británica APACS, las tarjetas de crédito canceladas, pero...¿nos quedamos conformes?

[+] Google search reveals 19,000 credit card details (InfoWorld)

Leer más...

¿cómo vas? ¿y tú certificado SSL qué tal?

SSLFail.com es una web que nace con el objetivo de evidenciar a todos a aquellos que utilizan servicios SSL y que disponen de un certificado erróneo por alguno de los múltiples motivos que se pueden dar.

Salvo curiosidades de algunas webs, tampoco parece ser demasiado interesante, pero usaremos una captura para explicar a que se deben estos errores.




La imagen superior muestra lo que es el fallo más típico. A la hora de generar un certificado SSL se solicita el "CommonName" o CN, que es el nombre DNS del sistema junto al domino al que pertenecen, también denominado FQDN. En el ejemplo, en el momento de la generación se introdujo "www.verisign.com", lo que es correcto siempre y cuando se acceda a esa URL únicamente mediante la dirección: http://www.verisign.com.

La captura, en cambio, evidencia que se accedió sin utilizar el subdominio "www", pero los servidores DNS resuelven ambas direcciones a la misma IP y por lo tanto el certificado SSL es el mismo.

[aramosf@sbd ]$ host www.verisign.com
www.verisign.com is an alias for www.verisign.net.
www.verisign.net has address 65.205.249.60
[aramosf@sbd ]$ host verisign.com
verisign.com has address 65.205.249.60

El navegador, al solicitar el certificado comprueba que el nombre introducido en la URL (verisign.com) y el CN (www.verisign.com) son distintos. Lo que genera el error: "ssl_error_bad_cert_domain" y que puede ser saltado añadiendo una excepción.

Este aviso en concreto y conociendo lo que hacemos, no es realmente grave y es muy habitual cuando se acceden a servicios mediante https eliminando las "www", ya que por usabilidad es práctica habitual que el dominio responda al mismo contenido que el web principal.

Los certificados pueden ser consultados manualmente con la aplicación "openssl":

[aramosf@sbd ~]$ openssl s_client -connect verisign.com:443

CONNECTED(00000003)

---
Certificate chain
0 s:/serialNumber=2497886/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/C=US/postalCode=94043/ST=California/L=Mountain View/streetAddress=487
East Middlefield Road/O=VeriSign, Inc./OU=Production Security Services/OU=Terms of use at www.verisign.com/rpa (c)06/CN=www.verisign.com
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Au
thority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Au
thority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGCDCCBPCgAwIBAgIQakrDGzEQ5utI8PxRo5oXHzANBgkqhkiG9w0BAQUFADCB
vjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
[...]

También existen servicios online que nos muestra el certificado SSL de un host, como el que ofrece serversniff.net



Por último, una aplicación gráfica para entornos Windows con la que también se pueden hacer estas consultas. SSLDigger de Foundstone.

Leer más...

Recuperando información de discos duros siniestrados

Sobre todo antiguamente, seguro que tenemos experiencias con catástrofes en discos duros. La calidad de los mismos, así como las tecnologías utilizadas no daban mucho más de sí. Se decía que los SCSI aparte de más rápidos que los IDE, eran aún más fiables.

Yo tuve de los dos tipos, y en ambos sufrí los típicos errores de sectores defectuosos que te obligaban a tirar de FSCK o de Scandisk (según el tipo de sistema de ficheros y sistema operativo utilizado en el momento) para intentar recuperar tus datos, después de escuchar unos molestos y continuos ruidos de reintento de lectura/escritura.

Parece ser que la tecnología ha ido evolucionando hacia discos duros más fiables (IBM fue el primero en sacar discos duros con tecnología airbag para sus portátiles), sistemas de almacenamiento de información sin piezas móviles (memorias flash, pendrives USB,..) que incrementan la fiabilidad. Asimismo, cada vez en mayor número de empresas, se instalan los servidores con configuraciones de discos en RAID. De esta manera, se utiliza espacio en discos auxiliares para guardar información redundante, de manera que si un disco falla (en el caso del RAID 1 o RAID 5) se pueda reconstruir la información con los discos restantes.

Sin embargo, hay veces que no hay tecnología que pueda hacer frente a ciertos desastres naturales. Basta recordar incendios como el del Windsor, inundaciones como las producidas por el huracán Katrina en Nueva Orleans, terremotos, radiación electromagnética o degaussing producida por tormentas solares geomagnéticas, descargas de electricidad estática sobre un disco duro externo (¿verdad Yago?)... para que se te ponga la piel de gallina al pensar en la cantidad ingente de información destruida e irrecuperable que haga pensar en si el último backup hecho habrá funcionado o no correctamente.

En este post me habría gustado dar soluciones fiables para poder restaurar íntegramente dicha información en casa. Cierto es que dependiendo del tipo de problema del disco, es posible "revivirlo" el tiempo suficiente como para poder volcar la información existente a otro lugar más seguro y luego deshacernos de él.

Os dejo este enlace [fotosok.com] para poder hacer una pre-reparación casera para algunos casos. Aquí se nos indica incluso que podemos tener que recurrir a meter el disco duro en una bolsa de plástico y proceder a congelarlo incluso.

Sin embargo, he de deciros que pese a no estar todo perdido en la mayoría de los casos, se hace imprescindible contar con servicios profesionales especializados. Puede darse lo que se llama un head crash que es cuando, por una caida de tensión por ejemplo, el peine con las cabezas del disco se caen directamente sobre los platos provocando pérdidas de información.

Para reparar este tipo de discos siniestrados, las empresas disponen de lo que se llaman cámaras blancas, habitaciones con garantía de estar libres de motas de polvo en un porcentaje muy elevado. Se suelen llamar de clase 100, que exige menos de 100 partículas de más de 0.5µm por pie cúbico de aire. Este requisito es imprescindible puesto que el polvo de una habitación puede depositarse entre los platos de un disco duro y dañarlo aún más.

La pega principal es que suelen ser servicios bastante caros (entre 500 y 2000 euros para discos duros y hasta 6000 euros en el caso de algunos discos en RAID 5). Obviamente, si la información que contiene el disco son los últimos avances en una energía renovable independiente del petróleo, seguramente merecerá la pena.

Siempre podéis comprar un disco duro externo como el que nos ofrece SentrySafe que se vanaglorian de poder aguantar 850 grados Celsius durante media hora o 24 horas bajo el agua (precios a partir de 250 euros).

Esperemos que no os haga falta pero por si acaso os enlazo a diferentes compañías que realizan estos servicios en España.

• Recovery Labs: Empresa multinacional dedicada exclusivamente a la recuperación de información por catástrofes. En Madrid y Barcelona.
  
• Datex: Empresa especializada con 20 años de experiencia. Presencia multinacional, pero en Barcelona únicamente para España.
• Lineared: Situada en Madrid. Capacidades para recuperar información de un montón de tipos de diferentes tipos de discos y sistemas de ficheros.

Leer más...

Electronic vaulting: Mashup con fuse-sshfs, truecrypt y qdsync

¿Quieres vulnerar la política de seguridad de tu organización para robar información crítica y vendérsela a la competencia para poder pagar la hipoteca de una forma más cómoda?

Si además de poder pasar las fronteras árabes con PDFs más pesados de lo normal decides que según se haga un cambio en un directorio concreto, quieres ser el primero en enterarte de qué es lo que se ha modificado, sigue este post y sacia tu curiosidad.

Decir que la idea inicial era sincronizar un directorio "en tiempo real" con un espacio que físicamente se encuentra en otra localización. Sentadas las bases, lo deseable es lograr que cada vez que se realice un cambio en un directorio, queden reflejados en un lugar remoto (la finalidad puede ser como un backup online o electronic vaulting para evitar catástrofes como las del edificio Windsor, replicar logs de forma remoto para que sirvan de evidencia para propósitos forenses, robo selecto de información, etc,...)

Importante es que la información quede almacenada de forma cifrada en el destino remoto, con controles de acceso sólidos, así como que el canal de comunicación y sincronización también sea cifrado y autenticado.

Manos a la obra y planifiquemos (como nos decían los compradores de Auna) cómo hacerlo. Necesitamos un repositorio remoto accesible 24 horas (en este caso un servidor linux con el servicio SSH funcionando), un canal de comunicación cifrado y autenticado (SSH cumple perfectamente los requisitos), para guardar los datos de forma segura en la localización remota utilizaremos un contenedor cifrado con TrueCrypt (hablamos en su día de la confidencialidad que aporta el contenedor cifrado aquí), para sincronizar directorios utilizaremos QdSync (podríamos haber utilizado rsync y sería más POSIX).

Sé positivamente que a golpe de scp podríamos haber copiado y movido ficheros, sin embargo, pienso que es mucho más cómodo utilizar un módulo fuse llamado fuse-sshfs, que permite montar un sistema de ficheros remoto mediante SSH y utilizar ese espacio para almacenar información. Ni que decir tiene que el servicio SSH no tiene por qué estar en el puerto TCP 22 sino que puede ser cualquier otro (se especifica en el momento del montaje)

Por partes:

1.-) Instalamos el módulo fuse. En mi caso en una CentOS 4.7 instalamos el paquete fuse-sshfs-2.0-1.el4.rf.i386.

2.-) Descargamos y descomprimimos QdSync (en mi caso en /opt/qdsync)

3.-) Decidimos qué directorio vamos a sincronizar puesto que hay que establecer una "marca" inicial para comparar el estado del directorio con el actual (Esto se entenderá mejor más adelante). En nuestro caso he elegido el directorio /var/motion. Para hacer la primera "marca" ejecutamos un "du -ah /var/motion > /var/index_motion"

4.-) Creamos el contenedor cifrado en local con truecrypt (importante elegir el tamaño y el sistema de ficheros que mejor se adecúen a nosotros) y lo copiamos a la ubicación remota de forma manual.

5.-) Añadimos al fichero .ssh/authorized_keys2 del directorio remoto para añadir nuestra clave pública SSH. La idea es poder comunicarnos entre ambas localizaciones con SSH with Keys de manera que sea siempre de forma no interactiva

6.-) Creamos un script como el siguiente, que realice de forma automatizada todo el proceso teniendo en cuenta posibles problemas (que la localización remota esté ya montada, que no sea accesible por SSH, etc...). En mi caso el directorio a sincronizar es /var/motion. Hemos elegido /mnt/remote para hacer el primer montaje con el sistema de ficheros SSH y /mnt/cifrado como punto de montaje para el contenedor cifrado con truecrypt desde el propio sistema de ficheros remoto.

#!/usr/bin/perl
#Script que sincroniza /var/motion con contenedor cifrado en ubicación remota
#1.- Compruebo que no está montado ya /mnt/remote

if ( `mount | grep -i remote` || `mount | grep -i cifrado`)
{
system "logger \"Algo habia montado, no hago nada mas\n\"";
}
else
{
#2.- Validamos si algo ha cambiado con lo anterior
my $temp="/tmp/syncing";
$temp.=rand(100);
system "du -ah /var/motion > $temp";
if (`diff $temp /var/index_motion` != '') #Si ha cambiado algo nos interesa sincronizar
{
my $tries=0;
while ( (`mount | grep -i remote` eq '') && ($tries < style="font-style: italic;"> `sshfs root\@200.XX.YY.ZZZ:/root/Lawrence /mnt/remote`;
#montamos el sistema de ficheros remoto
$tries++;
}

if (`mount | grep -i remote` eq ''|| $tries==10) {die "no he podido montar /mnt/remote";}
# Generamos de nuevo fichero index_motion
system "du -ah /var/motion > /var/index_motion";
#montamos el contenedor como sistema de ficheros también
system "truecrypt --non-interactive -p securitybydefault /mnt/remote/Lawrence.tc /mnt/cifrado";

#Sincronizamos
system "/opt/qdsync/src/qdsync /var/motion/ /mnt/cifrado/";

#TO DO: valida tamaño que queda en contenedor sea menor que lo que hay que sincronizar
system ("truecrypt -d /mnt/cifrado");# Desmontamos el contenedor
sleep "5";
system ("fusermount -u /mnt/remote");# Desmontamos el sistema de ficheros remoto
}
unlink ($temp);

7.-) Añadimos una línea en el cron que cada minuto ejecute el script anterior. También se puede ejecutar dicho script como demonio y controlar el tiempo cada X segundos de forma manual


De esta manera, cada minuto se ejecutará el script anterior y, si ha habido algún cambio en el directorio seleccionado (o alguno de sus subdirectorios) se montará y sincronizará de forma segura.

Leer más...

DLP: Y las fugas de información...

Muy de moda se encuentran las siglas DLP (Data Loss Prevention o Data Leak Protection) para referirse a diferentes mecanismos y prodedimientos de seguridad pensados para evitar las temidas fugas de información confidencial. Partiendo de la base que la información es poder, y de que por dinero y poder se puede tentar a cualquiera, es importante que la política de seguridad de una compañía contemple mecanismos para evitar que las maltrechas economías/ grado de satisfacción de algunos empleados derive en una fuga de datos.

Imaginemos qué efecto podría causar en la economía de nuestra organización, que un inocente empleado desvíe hacia fuera ficheros con planificación estratégica, listado de clientes, roadmap de nuestros productos, etc,.... Ni que decir tiene que si lo que se exporta a manos no autorizadas conllevan datos personales de nuestros clientes, empleados o proveedores, las cuantías de las sanciones pueden llegar a ser millonarias (hasta el punto incluso de hacer perder el sentido de una organización).

Formas comunes de llevar a cabo este tipo de actuaciones (con mejor o peor fe) podrían ser:

• Envío de información hacia el exterior mediante mensajes de correo electrónico (en general se suele utilizar soluciones de cifrado para evitar que el contenido pueda verse en texto claro). Esto puede hacerse mediante el propio servidor de correo dentro de la organización (hay que ser muy inconsciente para hacerlo así) o con webmails (Gmail, Hotmail, Yahoo,...) vía HTTPS de manera que vaya cifrado el tráfico y no se pueda interceptar por el camino si la comunicación es directa entre cliente y webmail
  
• Utilizar protocolos estándar de transferencia de ficheros (FTP). Enviar los ficheros con información confidencial a servidores externos
• Utilización de las capacidades de envío de ficheros mediante mensajería instantánea (MSN, Google Talk, Yahoo Messenger)
• Puertos USB habilitados en los PCs corporativos de las organizaciones. Dada la suerte de diversos dispositivos de almacenamiento extraibles que existen (cámaras, pendrives, discos duros externos,...) es un gran problema para las organizaciones tenerlos activos (aunque hay ocasiones que es necesario y práctico por lo que no se deshabilitan por defecto)
• Exceso de confianza en los propios empleados con ordenadores portátiles corporativos. Dentro de esta categoría podemos incluir muchos tipos de riesgos: robos, olvidos en lugares públicos, instalación de software externo a la organización que pueda contener malware en cualquiera de sus formas, mala configuración de las políticas de seguridad de red de los mismos, etc,...
• Utilización de software de descargas Peer-to-Peer (P2P ) y sus capacidades de compartir carpetas con información confidencial (recordemos que por ejemplo Emule te sugiere compartir todo el contenido de tus discos duros por defecto en el momento de la instalación). De esto ya se habló en SbD
  
• Impresoras: si la información se puede imprimir y llevar en papel también es un riesgo a tener en cuenta
  

En general, todo este tipo de riesgos pueden mitigarse (es muy difícil eliminar todos ellos de forma efectiva) mediante la combinación de diferentes procedimientos y buenas prácticas de la seguridad corporativa en las organizaciones. Partiendo de la utilización de dispositivos cortafuegos (y de una óptima y mínima configuración); proxies que registren la actividad de los usuarios, deshabilitando los dispositivos USB de los PCs y servidores; registrando la actividad de los trabajos de impresión (así como asignando permisos a los usuarios que así lo necesiten); registrar correctamente la actividad de los servidores de correo salientes; utilización de diverso software destinado a evitar DLP (casi todos los grandes fabricantes disponen de alguna solución endpoint para cubrir este nicho de mercado como RSA o McAfee)...

Ante todo, creo que una buena medida puede ser la utilización de tecnologías de contenedores cifrados para almacenar información sensible, así como la distribución de claves diferentes para acceder a los datos internos en base al usuario que demande el acceso. Asimismo es imprescindible un alto nivel de logging de la actividad al acceso a la información. En realidad si la información sale de la organización, ya nada se puede hacer, pero al menos podrá tomarse medidas contra el usuario malicioso.

Leer más...

La búsqueda de información en un test de intrusión.

El primer paso de un test de intrusión es la búsqueda de información o information gathering. Esta información será utilizada para organizar el ataque de la forma más precisa posible en las siguientes fases. Hay desarrolladas múltiples aplicaciones para tratar de automatizar esta pesada tarea, aunque la necesidad de hacer consultas y búsquedas manuales es imprescindible.

Maltego es una herramienta completa, sencilla y vistosa que deja impresionado a todo consultor. Existe una versión gratuita denominada "Community Edition" y otra comercial, "commercial edition". Seguramente Veronica Mars habría reducido su temporada a un par de episodios y hubiera prescindido de los servicios de su amiga "Mac" si hubiese conocido esta utilidad.

Entre otras cosas permite encontrar las relaciones que existen entre sistemas de información y personas:

• Localización de nombres de usuario, nombres reales, números de teléfono, correo-e.
  
• Localización de sistemas mediante DNS, Google Hacking, BBDD de RIRs
• Búsqueda de otros dominios relacionados
• Búsqueda de documentos y metadatos en los documentos
• Representación gráfica de toda la información recolectada
• En su versión comercial además, función de cliente/servidor.

Podéis ver algunas imágenes más y un vídeo de demostración en la página del fabricante: http://www.paterva.com/maltego/screenshots/

Otras herramientas también muy útiles pero más básicas son:

SEAT	http://thesprawl.org/code/src/seat-0.2.tar.bz2
Goolag	http://www.goolag.org/ http://www.goolag.org/download.html
MetaGoofil	http://www.edge-security.com/metagoofil.php
TheHarvester	http://www.edge-security.com/theHarvester.php
Goog-Mail.py	http://www.darkc0de.com/misc/googemail.py http://www.darkc0de.com/misc/emailcollect_v1.3.py
Fierce DNS	http://ha.ckers.org/fierce/
Extract Subdomains	http://www.darkc0de.com/misc/goog-subdomains.py
The Revisionist	http://lcamtuf.coredump.cx/strikeout/
Herramientas web	http://www.serversniff.net http://www.robtex.com http://www.serversniff.net
Maltego	http://www.paterva.com/maltego/
Base de Datos RIPE	ftp.ripe.net/ripe/dbase/ripe.db.gz
Infocrobes	http://www.gnucitizen.org/blog/infocrobes/
Hachoir-Metadata	http://hachoir.org/wiki/hachoir-metadata
sameips.sh	http://www.514.es/download/sameips.sh
httprecon	http://www.computec.ch/projekte/httprecon/
BidiBlah	http://www.sensepost.com/research/bidiblah/

Leer más...

Medios digitales de seguridad en papel

Dado los tiempos que corren, es tanta la información que leemos diariamente en diversos diarios digitales, blogs, RSS, ficheros PDF, etc,... que finalmente nos olvidamos de procesar información con los mecanismos de comunicación escrita en soporte físico (libros, revistas, periódicos,...) que han usado nuestros antepasados. Los periódicos físicos han pasado a ser el material con el que envolver el bocadillo o compartir el café del bar, más allá de aquellos que lo utilizan cuando van al transporte público.

En la comunicación de seguridad de las tecnologías de la información, es bien sabido que existen multitud de blogs, agregadores o consolidadores de noticias. Muchos de nosotros dedicamos un rato al día a procesar información que viene dada a través de este tipo de websites o listas de correo incluso, a fin de estar más al día de los avances tecnológicos que se van produciendo. Por citar sitios relacionados con seguridad informática que frecuento a menudo (además de www.securitybydefault.com se entiende :-D) podría indicar entre otros: Kriptópolis, Securityfocus, Packetstorm,... amén de diferentes blogs de tecnología y noticias en general: Genbeta, Microsiervos, Abadiadigital, Meneame, Slashdot, Barrapunto,....

La pregunta es: ¿qué sucede con las diferentes publicaciones existentes en formato de Gutemberg? ¿Ya no se leen? ¿Quizá van enfocadas a un público diferente, algo más especializado en seguridad pura?

He querido mencionar entre otros unos cuantas publicaciones conocidas a nivel nacional, así como mi opinión personal sobre los contenidos y calidad general de las mismas. Decir que como profesional del mundo de la seguridad informática española, soy un consumidor activo de este tipo de revistas. Para mí constituyen en general una lectura bastante amena al tratarse de noticias y novedades referentes a empresas, fabricantes, mayoristas e integradores de seguridad, con los que estoy familiarizado de tratar en la mayoría de los casos.

Las más conocidas son las siguientes:

• Revista SIC: Una de las primeras y más importantes e interesantes en cuanto a calidad, selección y fiabilidad en sus contenidos. Muy buena presentación y distribución. Se te pasan las horas leyéndola asimilando "el estado del arte" de los productos de seguridad actuales, te permite sacar conclusiones sobre las tendencias de los fabricantes, de los primcipales clientes, de sus preocupaciones principales, etc,... Asimismo siempre incluye artículos de opinión bastante interesantes, comparativas, y una sección final de laboratorio de pruebas de productos comerciales diversos avalados por Javier Areitio Bertolín de quien guardo especial recuerdo y aprecio al haber sido mi director de proyecto de fin de carrera.

• Red & Seguridad: Sin duda una de mis favoritas también. La editorial Borrmart cuenta con un enorme portfolio de publicaciones dirigidas cada una a un sector concreto: Seguridad Lógica, Seguridad física, Apasionados del automóvil, etc,... En este caso, Red & Seguridad, después de su quinto aniversario el año pasado modificó el estilo de la edición por completo para darle un aire más moderno, un enfoque diferente, que como resultado obtiene en el lector una lectura bastante cómoda también. El tamaño de letra es adecuado, los artículos son bastante interesante (aunque mal está que yo lo diga al haber publicado uno en el número 34 de Mayo pasado, pero bueno). Esta revista cuenta con artículos de diversa índole, aunque predominan contenidos con base bastante técnica, se intercalan algunos relativos a las diversas leyes de la información (LOPD, LSSI, etc,...), metodologías de gestión de la información y estándares de calidad (ISOs varias). En definitiva una revista que procuro leer en cuanto me llega.

• TCN: Esta revista de publicación semanal, edita una vez al mes un suplemento de seguridad que resume bastante bien las principales noticias a nivel internacional incluso. Cubren en una sección especial los ataques o amenazas más candentes de ese mes, parches publicados por Microsoft, etc,... No es tan especializado ni tan largo como las anteriores pero resulta bastante interesante de leer igualmente.

• E-Security: Reconozco que la lectura de esta publicación la tengo un poco más abandonada, no porque no me guste, al contrario, los números que he podido leer, los he disfrutado igualmente, pero al no estar suscrito no puedo hacerlo como quisiera. La destaco porque es una de las más conocidas también en el sector nacional. De hecho la página web me parece que tiene un aire mucho más moderno que las anteriormente nombradas e incluso permite ojear virtualmente la revista. Yago publicó años atrás varios artículos bastante interesantes en esta revista.
  

Y vosotros lectores, ¿recomendáis algún otro tipo de publicación en papel que debería añadir a mis lecturas habituales de seguridad?

Leer más...