28 febrero 2010

¿Está la seguridad reñida con la ecología?

¿Nos estaremos cargando el planeta con tanta producción? Calentamiento global, lluvias desmesuradas, grandes tragedias naturales como el terremoto de Haití o de Chile, tormentas perfectas, etc, etc,...

Debido a la concienciación de los diferentes medios de comunicación para prolongar la salud del Planeta Tierra, los entornos TI se ponen las pilas para minimizar el gasto energético, intentando mantener un buen nivel de servicio ahorrando, entre otros, en la factura de la luz.

En varias empresas en las que he trabajado, a la hora de finalización de jornada, para no tener que esperar el tiempo de arranque al día siguiente, era práctica común apagar el monitor únicamente en el PC de escritorio. Sin embargo, y gracias a estas buenas prácticas ecológicas, se aconseja/conciencia a los usuarios que apaguen el PC por la noche ahorrando energía (ni que decir tiene el malgasto de energía en un fin de semana o un puente de una cantidad grande de PCs).

En este artículo, el CIO de una empresa indicaba que aquellos usuarios que tenían la costumbre de apagar el PC por la noche solían tener un porcentaje mayor de infecciones de malware que aquellos PCs que quedaban encendidos. ¿Por qué? pues la respuesta es sencilla. La política de la compañía, en cuanto a actualización de parches de Sistema Operativo estaba programada (por otra parte es totalmente razonable) para llevarse a cabo de madrugada. Al apagarse los PCs por la noche, los parches de sistema operativo, no se actualizaban y el malware lo tenía más fácil para hacer daño.

En organizaciones en las que el departamento de seguridad planifica estos mantenimientos o securizaciones masivas en base a desplegar actualizaciones por dominios por ejemplo, sería interesante establecer otro tipo de horario para aplicar estos parches. Quizá definir un horario de aplicación de parches conocido y declarado por la organización haría que los usuarios supieran que podrían llegar a tener problemas de rendimiento en sus aplicaciones, pero que es por la seguridad de sus sistemas. Una buena política sería pedir a los usuarios que no apagaran su PC al salir de la empresa y llevar las labores de mantenimiento a las 20:00 (por ejemplo) y forzar por política de dominio un apagado de todas las máquinas de usuarios al terminar. Así siempre se apagarían los PCs sin depender de la buena concienciación de los usuarios.

Leer más...

27 febrero 2010

Publicado el horario de Rooted CON

Durante esta semana se ha publicado el horario de las ponencias que formarán Rooted CON 2010. Tras la publicación de los detalles tanto de los ponentes como de algunas de sus charlas, finalmente disponemos del programa para los días 18, 19 y 20 de Marzo.


Como podemos observar en la siguiente imagen, que abarca el programa de los 3 días, este congreso se caracterizará por los distintos ámbitos en los que se encuentra su temática: desde los temas dedicados al mundo profesional, orientación, concienciación, reflexión sobre el estado actual de la seguridad, hasta el nivel más técnico referente a distintos tipos de plataformas y técnicas avanzadas.


El primer día (jueves 18) se perfila como el día menos técnico, pero no por ello menos interesante. Nuestro compañero Alejandro Ramos ofrecerá una charla que pretende servir, entre otras cosas, de orientación profesional para todos aquellos que quieran dedicarse al mundo de la seguridad informática, un tema del que hemos recibido infinidad de correos tras la publicación del post "¿Y ahora qué?". Ideal para aquellos que están próximos a iniciarse en el mundo laboral, recién llegados o los que quieran cambiar de rumbo en su vida, profesionalmente hablando. Además, como broche del día se realizará un debate-coloquio denominado RootedPanel que contará con profesionales que debatirán y expondrán los detalles sobre la modificación del código penal para este 2010, en el que se incorporan diversas actividades, tradicionalmente relacionadas con el hacking, quedando estas tipificadas como delictivas en la mayoría de los casos.

Al día siguiente (viernes 19), también para cerrar la jornada, se realizará otro RootedPanel en el que se contará con la presencia de miembros de los primeros y más famosos grupos de hackers de la scene española. Este Panel será moderado por Security By Default, algo que nos enorgullece enormemente.

Tanto el viernes como el sábado, para esta primera edición se tienen reservadas charlas no presentadas en ningún otro congreso con anterioridad, e incluso se liberarán vulnerabilidades, técnicas y herramientas nunca antes puestas a disposición del público.


Las entradas para Rooted CON se agotaron hace ya semanas, pero recordamos que todavía podéis asistir a las acciones formativas RootedLabs que tendrán lugar los tres días previos al congreso, Lunes 15, Martes 16 y Miércoles 17 de Marzo. Con más del 75% de ocupación, actualmente el número de plazas disponibles es el siguiente:
  • 15 de Marzo 2010
  1. Reverse Engineering (por Rubén Santamarta) = Sin plazas
  2. Digital Forensics (por Juan Garrido) = 4
  3. Técnicas de Inyección en Aplicaciones Web (por Chema Alonso) = 8
  • 16 de Marzo 2010
  1. Malware Analysis (por Ero Carrera) = 5
  2. Secure Enterprise WiFi Networks (por Alejandro Martín Bailón) = 5
  3. Pentesting (por Alejandro Ramos) = Sin plazas
  • 17 de Marzo de 2010
  1. Pentesting (por Alejandro Ramos) = Sin plazas
  2. Técnicas de Inyección en Aplicaciones Web (por Chema Alonso) = 4
  3. Reverse Engineering (por Rubén Santamarta) = Sin plazas
Puedes obtener más información en este enlace.

"Vaya semanita" que nos espera...¿y tú? ¿Irás a la primera Rooted CON?

[+] Rooted CON | RootedLabs | @rootedcon
Leer más...

26 febrero 2010

hping3 cheatsheet

Siguiendo con la cheatsheet de Nmap, continuamos con otra chuleta para otra herramienta imprescindible como es hping. Hping nació como utilidad para la manipulación de paquetes icmp, aunque actualmente soporta tanto tcp, como udp o IP. Es tan compleja como la propia pila tcp/ip y eso es lo que la hace tan versátil.

Algunas de sus utilidades más comunes son:
  • Análisis de reglas de cortafuegos
  • Escáner de puertos avanzando
  • Túneles ocultos (covert-channel)
  • Puertas traseras
  • Predicción de números de secuencia
  • Uptime de un sistema
  • Denegaciones de servicio (synflood, land, udpflood... etc etc)
  • Formación en tcp/ip
Dejo pendiente algunos de estos ejemplos y usos avanzados para otra entrada.

La chuleta en español:
http://sbdtools.googlecode.com/files/hping3_cheatsheet_v1.0-ESP.pdf

La chuleta en inglés:
http://sbdtools.googlecode.com/files/hping3_cheatsheet_v1.0-ENG.pdf

Pronto... ¡la siguiente!
Leer más...

25 febrero 2010

Syn Flood, que es y como mitigarlo

Hoy día es sorprendente ver como ataques que fueron descritos a principios de los 90 perduran y siguen siendo efectivos en un buen numero de situaciones.

Uno de ellos, tal vez de los más clásicos, es el Syn Flood. Este tipo de ataque es posible debido a la forma en la que funcionan las conexiones TCP. Cuando un extremo desea iniciar una conexión contra otro equipo, inicia la conversación con un 'SYN', el otro extremo ve el SYN y responde con un SYN+ACK, finalmente el extremo que empezó la conexión contesta con un ACK y ya pueden empezar a transmitir datos.


Un ataque de tipo Syn Flood lo que hace es empezar un numero especialmente alto de inicios de conexión que nunca son finalizados, dejando al servidor a la espera del ack final, y por tanto consumiendo recursos de forma desproporcionada. Existen muchas herramientas escritas en todo tipo de lenguajes para hacer un ataque de tipo Syn Flood y no se requiere especial habilidad para llevar acabo un ataque de ese tipo.

Mitigando un ataque Syn Flood

A la hora de fortificar un sistema para contrarrestar un ataque de tipo Syn Flood existen parámetros que se pueden configurar en el sistema operativo para hacerlo mas resistente.

En sistemas Linux:

Primer paso, activar las syn cookies (mas información sobre que es y como se construye una syn cookie aquí)

# sysctl -w net.ipv4.tcp_syncookies="1"

Segundo paso, aumentar el 'backlog queue' (es decir, dar mas holgura al sistema para procesar peticiones entre-abiertas)

# sysctl -w net.ipv4.tcp_max_syn_backlog="2048"

Tercer paso, hacer que el sistema minimice el tiempo de espera en la respuesta al SYN+ACK. En principio un sistema Linux 'por defecto' esperará 3 minutos, nosotros lo vamos a dejar en 21 segundos

#sysctl -w net.ipv4.tcp_synack_retries=2

(una vez probados los cambios, hay que hacerlos permanentes en /etc/sysctl.conf)

En sistemas Windows :

Activación de la protección anti Syn Flood:

C:\>reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v SynAttackProtect /t REG_DWORD /d 1

Aumentamos el 'backlog queue'

C:\>reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v EnableDynamicBacklog /t REG_DWORD /d 1

C:\>reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v MinimumDynamicBacklog /t REG_DWORD /d 20

C:\>reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v MaximumDynamicBacklog /t REG_DWORD /d 20000

C:\>reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v DynamicBacklogGrowthDelta /t REG_DWORD /d 10
 
Decrementamos el tiempo de espera en conexiones 'Half Open'

C:\>reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpMaxConnectResponseRetransmissions /t REG_DWORD /d 2

Ya solo queda rebootar Windows para que los cambios tengan efecto

[+] Las configuraciones han sido extraídas de este magnífico artículo 
Leer más...

24 febrero 2010

Licencia para Wondershare Office Recovery 1.5.0

Hasta el 10 de abril de este año la compañía especialista en soluciones de optimización, recuperación y mantenimiento de software Wondershare ofrece una licencia permanente de su producto Office Recovery gratuitamente, valorado en 30$.

Este producto permite la recuperación de documentos ofímáticos de los siguientes formatos:

Documentos de Microsoft Office 2007, XP, 2003 ó 1997 y archivos PDF, o lo que es lo mismo, las siguientes extensiones:
  • Recuperación de documentos Word (.doc, .docx)
  • Recuperación de hojas de cálculo Excel (.xls, .xlsx)
  • Recuperación de presentaciones PowerPoint (.ppt, .pptx)
  • Recuperación de buzones de correo Outlook (.pst)
  • Recuperación de buzones de correo Outlook Express (.dbx)
  • Recuperación de bases de datos Access (.dbx, .accdb)
  • Recuperación de proyectos Project (.mpp)
  • Recuperación de publicaciones Publisher (.pub)
  • Recuperación de documentos de OneNote (.one)
  • Recuperación de esquemas Visio (.vsd)
  • Recuperación de formularios Infopath (.xsn)
  • Recuperación de documentos PDF (.pdf)



Recordad que no se ha de instalar en mismo disco duro del que se tratarán de recuperar para no sobrescribir sectores del disco duro marcados como libres cuando podrían contener datos.

Para solicitar la licencia hay que introducir nombre, apellidos y dirección de correo electrónico en la url:
Leer más...

23 febrero 2010

A la hora de lanzar un ataque, los atacantes más eficaces hacen sus deberes para descubrir tanto acerca de su objetivo como sea posible. Mientras que un script kiddie se lanzaría en la búsqueda de sistemas débiles sin tener en cuenta quién es su propietario, los atacantes con más experiencia se toman su tiempo en llevar a cabo misiones de reconocimiento antes de lanzar cualquier paquete contra la red destino.

Para entender por qué la fase de reconocimiento (aka recon) es tan importante para un atacante, echemos un vistazo a cómo se desarrollan los ataques en el mundo real. Al igual que un ladrón de bancos estudia los planos del edificio, las cámaras de seguridad, los horarios de los vigilantes y empleados; un atacante debería recoger la mayor cantidad información posible antes de pasar a la siguiente fase: el escaneo.

Existen varias técnicas de reconocimiento, entre las que podemos destacar:
  • La ingeniería social
  • Spoofing de números de teléfono
  • Saltarse los controles físicos
  • Rebuscar en la basura
  • Búsquedas en la web
  • Análisis de bases de datos whois
  • Consulta de los DNS
Para prevenir que los atacantes obtengan demasiada información que les haga más fácil el ataque, se proponen una serie de recomendaciones para las organizaciones:
  • El método de defensa más eficaz contra la ingeniería social y el spoofing de números de teléfono es la concienciación del usuario. Se debe informar a todo el personal (desde la alta dirección hasta el becario que acaba de incorporarse) sobre estos tipos de ataques y formarles para que no revelen información sensible. Deben conocer cuáles son los procedimientos para un reseteo de contraseña, ya que en muchas organizaciones no hay razón por la que un administrador de sistemas, secretaria o director solicite una contraseña. Además el equipo de help desk debe tener unos procedimientos específicos sobre cómo han de verificar la identidad de quienes solicitan un reseteo de contraseña, tampoco se debe confiar en personal desconocido que nos llame solicitando información sobre la configuración de los sistemas, datos sensibles, aunque nos aseguren que es de vital importancia. Se debe tener en cuenta que estos procedimientos dependen del nivel de seguridad requerido por cada organización.

  • Las tarjetas de identificación personal son una de las medidas más extendidas para evitar que personas ajenas a la entidad se salten los controles físicos. Un vigilante de seguridad o un lector de tarjetas deberá verificar la identidad de los empleados que accedan a las instalaciones. Muchas organizaciones gastan mucho dinero en estas medidas que luego no son utilizadas como deben. La tarjeta de identificación ha de llevarse en un lugar visible, y el personal de seguridad física debe revisar que todos los empleados están correctamente identificados. Si nos cruzamos en el dispositivo de entrada al edificio con una persona que dice haber olvidado su tarjeta y nos pide usar la nuestra para entrar a las instalaciones, debemos indicarle que puede dirigirse al mostrador central donde le proporcionaran una temporal. Cuando las instalaciones se vacíen de personal, las puertas de las salas de ordenadores han de estar debidamente cerradas con llave. Se debe establecer una política que indique a los usuarios el deber de bloquear su sesión cuando abandonen su puesto de trabajo. Los portátiles y los dispositivos de almacenamiento externos que entran y salen del edificio y que contienen información sensible deben estar cifrados (por ejemplo con TrueCrypt), al igual que los correos que contengan información confidencial (por ejemplo con PGP o GPG), se debe educar al personal de lo importante que es esta función.

  • Todo material en papel, CDs y DVDs deberán ser destruidos cuando vayan a ser desechados. Las cintas y discos duros deberán ser debidamente desmagnetizados ya que la sobrescritura con unos y ceros no elimina la información completamente. Cuando los empleados se trasladan entre distintas oficinas se debe tener controlado todo el material para que este no se extravíe, la mejor opción es depositarlo en un contenedor (caja o similar) debidamente identificado que será trasladado por el personal.

  • Se deben establecer unas políticas para determinar qué información va a estar disponible en los servidores web. No debe subirse información sensible de clientes ya que los bots de Google acabarán por encontrarla. Tampoco debe subirse información sobre los productos que utilizan, su configuración o su entorno. Es mejor que un atacante no conozca que medidas de seguridad tenemos para no ponerle las cosas más fáciles. Tampoco debe aparecer la lista de correo de empleados, planes de negocio, PDFs aunque no contengan información sensible, ya que pueden incluir metadatos de donde extraer información. Si no queremos que Google los indexe, además de modificar el fichero robots.txt (este archivo es un arma de doble filo, ya que indicando dónde no queremos que busque podemos dar pistas a los atacantes de dónde buscar), debemos solicitar a Google que nos elimine de su cache, aunque puede que esta información permanezca en otra cache como Wayback Machine.

  • Podríamos pensar que registrar información errónea en las bases de datos whois nos puede mantener a salvo, pero en determinadas ocasiones es necesario contactar con los administradores de la entidad para gestionar un incidente, y desde una perspectiva de seguridad es necesario mantener actualizadas estas bases de datos whois. Se debe mantener la mínima información y no información adicional que puedan ser útil a un atacante. Podríamos pensar en usar los servicios de registro anónimos, pero para gestionar un incidente es necesario contactar de forma rápida cuando ocurre un ataque a una máquina. Por ello es más recomendable mantener la mínima información pero válida y educar al personal de nuestra organización para evitar los timos por ingeniería social. Desde SbD ya os hablamos en otra ocasión sobre cómo defender un dominio securizando el whois.

  • Para que los atacantes no extraigan demasiada información de los servidores DNS, se deben emplear una serie de técnicas. Primero, debemos estar seguros que no se está filtrando información adicional. El DNS es necesario para mapear nombres hacia y desde direcciones IP, e indicar servidores de nombres y correo, no se requiere otra información adicional, como información de los sistemas internos. Los nombres de dominio no deben indicar el tipo del sistema operativo. Segundo, se deben restringir las zonas de transferencia, se deben adoptar directrices que especifiquen las direcciones IP y redes, que vamos a permitir para iniciar las transferencias de zona. Muchas organizaciones tienen sus DNS secundarios en ISPs, y muchos de estos no limitan las transferencias de zonas, en estos casos es aconsejable ponerse en contacto con el administrador e indicarle que política ha de seguir. Por último es recomendable aplicar la técnica de split DNS para limitar la cantidad de información DNS que está disponible al público. Se podría usar un servidor DNS externo y otro interno. El externo contendría la información que puede hacerse pública y el interno contendría información para nuestros sistemas internos. Con la técnica de split DNS los atacantes sólo tendrán acceso a los DNS externos, mientras que los usuarios de la red interna podrán resolver tanto nombres internos como externos. Desde SbD se recomendó pasar el protocolo DNS a TCP.
¿Cuántas de estas buenas prácticas veis que vuestra organización no está cumpliendo? Yo estoy harta de ver puestos de trabajo sin bloquear, personal físico que no comprueba las tarjetas de identificación, personal pasando por los controles sin tarjeta física, usuarios que siguen poniendo sus claves en un post-it, entrada y salida de portátiles con información sensible sin cifrar, información sensible de organizaciones en Google y en las bases de datos whois. Luego no nos extrañemos cuando los atacantes se paseen por nuestra organización como si fuera su propia casa.
Leer más...

22 febrero 2010

Curso: "Hacking Techniques, Exploits & Incident Handling"

Nuestro amigo Jose Selvi nos ha hecho llegar la excelente noticia de que va a ser instructor en un curso del prestigioso SANS titulado 'Hacking Techniques, Exploits & Incident Handling'

Imagino que muchos de vosotros ya conoceréis el buen hacer de Jose en el blog Pentester y la forma tan didáctica que tiene cuando explica conceptos.

El curso en cuestión está orientado a la gestión de incidentes y se trata de formar a alguien para que desarrolle las habilidades necesarias a la hora de afrontar un problema de seguridad.

Tenéis mas información en la web de Pentester.
Leer más...

Contraseña más robusta para acceso a Iphone

Tiempo atrás Jose Antonio nos daba unos cuantos buenos consejos para securizar la por defecto mediocre configuración de nuestros Iphones, sobre todo si los íbamos a utilizar para conectarnos a Internet, en un entorno de alto riesgo como puede ser una conferencia de hackers.

Sin embargo, para evitar a curiosos con acceso físico al dispositivo, este tipo de teléfono permite, como otros, configurar una clave númerica como mecanismo de seguridad para poder desbloquearlo y operar con él. Esta clave numérica tiene el formato de un código PIN de una SIM, es decir, un número de cuatro dígitos (0000-9999); 10000 combinaciones diferentes posibles con numeros grandes para ser marcados, y fácilmente vistos por curiosos que nos observen operar con nuestro teléfono a una distancia demasiado cercana. Quién sabe si además utilizamos ese mismo código de seguridad para el PIN de la SIM, el código de la alarma o el de seguridad de la tarjeta de crédito para operar en un cajero automático.

En general se considera que una contraseña ha de ser lo suficientemente robusta como para que el averiguarla por fuerza bruta sea más caro en el tiempo, que lo que supone acceder a la información que esa contraseña (o mecanismo de seguridad) protege. Si nos roban el iPhone, puede ser una tarea tediosa probar 10000 combinaciones a mano, pero, puede hacerse. En Iphone podemos configurar por defecto que a los 10 intentos de contraseña incorrecta el teléfono, la información personal interna, se borre automáticamente. Esto que puede parecer una ventaja de seguridad, puede llegar a ser la consecuencia de una "broma pesada", si perdemos de vista el teléfono un tiempo y tenemos algún "amigo" excesivamente gracioso.

Por ello, y aunque ya ha sido publicado en múltiples foros dedicados a aplicaciones para Iphone exclusivamente, me gustaría comentar que existe una nueva configuración de seguridad de acceso físico para Iphone. En 9to5mac.com podemos descargar, desde el propio dispositivo, un perfil de seguridad que, una vez instalado no permitirá/obligará a configurar una contraseña alfanumérica con cierta complejidad (mezcla de letras y números) para acceso al teléfono.

Puede resultar un poco incómodo tener que escribir una contraseña más larga y compleja sobre el teclado típico de Iphone en vez del cómodo teclado númerico infalible que se ofrece por defecto. Sin embargo, si de verdad nos importan los datos que contiene nuestro dispositivo, con una mayor dificultad a la hora de ser crackeada por shoulder surfing y por fuerza bruta, esta puede ser una buena medida.

En caso que queramos volver a dejar el dispositivo como estaba, resultará tan sencillo como ir a "Sistema -> General -> Perfiles -> 9to5mac" y darle al botón Eliminar. Después hay que ir a "Sistema -> General -> Bloqueo con código", deshabilitar el acceso con código y luego volver a habilitar un código numérico de los de toda la vida.
Leer más...

21 febrero 2010

Nmap cheatsheet - Chuleta de Nmap 5

¡Chuletas! Trozos de papel pegados en cualquier parte del cuerpo, garabatos escritos en la piel, en una calculadora o incluso las uñas. ¡Chuletas! esa pequeña ayuda que profesionalmente está admitida en sitios como el teatro, el cine o dando charlas,  pero prohibida en cualquier examen.

¿Qué utilidad tiene memorizar 200 parámetros de un comando o los Reyes Godos? ¿No es más práctico saber dónde y cómo consultar esa información? Aprendamos a pensar, deducir e interpretar y usaremos la cabeza para cosas más útiles. ¿Realmente pretendemos saber escribir 200 fórmulas de física si luego no se entiende su utilidad? Hay que quemar a los estudiantes con prácticas, con ejercicios, con pruebas, con casos prácticos y no evaluar su memoria fotográfica.

Y ahora que ya me he desfogado con el exámen de física que he suspendido. Os presento una chuleta que hemos elaborado para la herramienta Nmap en su versión 5. Si bien es cierto que ya hay alguna   anterior demasiado resumida, queríamos darle una vuelta y actualizarla.

La versión en español:
http://sbdtools.googlecode.com/files/Nmap5 cheatsheet esp v1.pdf

La versión en inglés:
http://sbdtools.googlecode.com/files/Nmap5 cheatsheet eng v1.pdf

Continuamos trabajando en las siguientes que esperamos os sean de utilidad.
Leer más...

20 febrero 2010

Bad Heroes: Dark Avenger

Muchas veces, cuando se habla de seguridad es fácil caer en las típicas hagiografías resaltando hechos, talentos o capacidades de la persona (solo hay que darse una vuelta buscando bios de Kevin Mitnick o el mítico Capitán Crunch). Pero también existen otros personajes cuyos 'méritos' no son precisamente positivos y también merecen un espacio donde hablar de ellos.

Inaugurando esta sección empezamos con 'Dark Avenger' personaje que alcanzó su fama a principios de los 90 y cuyo pasatiempo era crear virus. Cuando hablo de virus no me refiero a esas burdas creaciones que llevan desde el 2000 copando portadas de diarios como el infame virus 'I Love You', hablo de virus técnicamente brillantes y que requerían una dosis de conocimiento bastante alta.

De lo poco que se sabe sobre Dark Avenger es que era Bulgaro y vivía en Sofia. En una época donde tener un ordenador era un lujo al alcance de muy poca gente (y mas en un país como Bulgaria) el gobierno Búlgaro decidió muy hábilmente invertir en equipamientos informáticos destinados a centros de formación para educar en nuevas tecnologías y eso permitió a nuestro protagonista de hoy acceder a un ordenador y empezar a adquirir destreza.

A raíz de un artículo publicado en una revista especializada en el que se hablaba de los incipientes virus-informáticos, Dark Avenger se interesó por el tema y en 1989 lanzó su primera 'creación' que se conoció por el original nombre de 'Dark Avenger'. Este virus era bastante pernicioso ya que tenía como finalidad destruir datos almacenados en el disco duro sobre-escribiéndolos con frases inspiradas en un disco de Iron Maiden.

A pesar de las lógicas limitaciones geográficas (recordemos, Internet no fue un fenómeno ampliamente difundido hasta mediados de los 90) este virus llego a infectar equipos en EEUU y Asia e incluso fue mencionado en un artículo del Washington Post. El virus era técnicamente bastante brillante ya que incluida técnicas de polimorfismo bastante adelantadas para el momento.

En aquellas épocas donde la mayor motivación eran las luchas de ego, no pudo faltar su 'pique' personal con un experto en técnicas de detección llamado Vesselin Bonchev y en algunos de sus virus aparecía como autor Vesselin con la intención de difamarlo y crear polémica.

¿Quien era Dark Avenger en realidad? En este punto y como todo buen super-bad-heroe que se precie, las teorías son infinitas. Unos sostienen que en realidad Dark Avenger era el propio Vesselin Bonchev y que lo hacía para promocionarse. Otra curiosa historia habla de un supuesto ciber-romance con una investigadora llamada Sarah Gordon con la que coincidía en BBS relacionadas con virus y la que posteriormente publicó algunos de los e-mails intercambiados. Hay gente que sostiene que en realidad Sarah era Dark Avenger.
Leer más...

19 febrero 2010

Expl()tando vunerabilidades humanas con Metasploit

Una de las técnicas empleadas por un atacante durante la fase de reconocimiento es la ingeniería social.

Manipular a las personas para ganar su confianza y obtener acceso a su sistema logrando que nos revele información confidencial es todo un arte. En muchas ocasiones puede resultar más fácil engañar al usuario que encontrar una vulnerabilidad en el sistema.

Todos conocemos la frase: "el usuario es el eslabón más débil", aprovechar sus debilidades para lograr que nos revele la clave de acceso a su sistema o abra un pdf, no es una tarea muy complicada. ¿Quién se resiste a un pdf que contiene un calendario de fotos de chicas sexys? o un supuesto administrador de la red, que nos llama con un número que parece de nuestra compañía utilizando las técnicas de spoofing de números de teléfono y nos informa que ha detectado una infección en nuestra máquina y necesita nuestra contraseña para revisar el problema.

Uno de los expertos en este arte es Kevin Mitnik, quien asegura que aunque los usuarios sigan unas políticas de seguridad, nuestra naturaleza humana nos hace vulnerables. ¿Quién no siente la necesidad de ayudar a un supuesto administrador de sistemas que se ha ganado nuestra confianza previamente?

Desde Metasploit nos presentan The Social-Engineering Toolkit (SET) que fue diseñado para el proyecto Social-Engineering Framework.

Podemos descargarlo desde nuestra Back|Track 4 mediante:

$ svn co http://svn.thepentest.com/social_engineering_toolkit/ SET/

Esta toolkit incorpora en una interfaz sencilla varios ataques de ingeniería social, con el propósito de automatizar y mejorar muchos de los ataques que existen en la actualidad.


Permite realizar ataques de tipo:
  1. Ataques vía e-mail
  2. Vector de ataques a sitios web
Además nos da la opción de actualizar nuestro Framework de Metasploit, nuestro Toolkit y la posibilidad de crear nuestro propio Payload y Listener.

Podríamos hacer uso de otra de las técnicas de reconocimiento, como es el Google Hacking y obtener una lista de e-mails de una organización. Seleccionaríamos por ejemplo el ataque mediante e-mail, que nos permitirá crear un pdf que contiene un exploit. Una vez el usuario abre el pdf, el payload se ejecutará y se creará una conexión que nos permitirá acceder a la shell de su máquina.


Otra opción sería llevar al usuario a una página web que muestra un error, y para funcionar necesita cargar un applet, al aceptarlo el applet actúa como troyano.


En definitiva, un proyecto muy interesante en el que solo se echa de menos la posibilidad de escoger los mensajes en otros idiomas aparte del Inglés.
Leer más...

18 febrero 2010

Jugando a espías internacionales

Lo que voy a relatar a continuación, parece obtenido de un libro de Dan Brown, pero las fuentes indican que es real.

Allá por Junio de 2001, Brian Regan, sargento de la Fuerza Aérea Americana, se tomó un montón de molestias para esconder, en el Pocahontas State Park del estado de Virginia, cierta información que previamente había sustraido de una entidad para la que había trabajado, la National Reconnaissance Office (dedicada a la gestión de los satélites espía).

La información que consideró que podía a llegar a generar una guerra si saliera a la luz era material con información sobre misiles Libios, defensas aéreas de Irak, operaciones de espionaje americano en China e Irán. Así pues, enterró en lugares estratégicos cuidadosamente para que no pareciera que había tierra removida, paquetes hechos con bolsas de basura con los diferentes documentos. Usando un GPS apuntó las coordenadas donde iría enterrado cada paquete.

Tiempo después, habiendo hecho creer a su jefe que se iba de vacaciones a Disneland, se fue en coche al aeropuerto de Dulles (Washington) para coger un vuelo destino Zurich (Suiza). En realidad, Regan iba a reunirse con oficiales de la embajada China e Iraquí para vender la jugosa información de la que disponía por 13 millones de dólares. Momentos antes de coger ese avión, fue arrestado por agentes del FBI.

Le requisaron varias cosas: una hoja que llevaba en la plantilla del zapato con direcciones de Embajadas de Irak y China en Europa, así como una libreta en la que se leían 13 palabras sin conexión entre ellas como tricycle, rocket y glove; además de otras 26 palabras en una tarjeta; una carpeta con 4 hojas con números de 3 dígitos, así como un papel en la cartera con una frase de varias letras y números.

Brian Regan, había sido entrenado en criptoanálisis por la Fuerza Aérea. Llevaba bajo vigilancia durante meses porque una fuente extranjera de contraespionaje había recibido una carta en la que se ofrecía vender información. La carta en sí tenía muchos fallos tipográficos, por lo que, al ser Regan disléxico, fue uno de los primeros en levantar sospechas para ser sometido a vigilancia.

¿Cómo resolvieron el puzzle en el FBI?

Gracias a fotos obtenidas de cámaras escondidas en su oficina, pudieron ver que navegaba por Intelink y, mientras visionaba la foto de un misil chino en la pantalla, tomaba notas en la libreta, relacionadas con las 13 palabras. Pensando en que podrían ser las coordenadas de la localización de ese misil, los investigadores del FBI llegaron a la conclusión que tricycle era el número 3; motorcycle (dos ruedas) y switch (interruptor ON/OFF) sería el número 2, etc,... Para codificar las coordenadas Regan hizo algo muy común en gente con dislexia, usar imágenes para acordarse de textos. Así aplicaron lo mismo contra la tarjeta de 26 palabras y sacaron otros dos sets de coordenadas que indicaban dónde estaban otros misiles iraquíes.

El papel que llevaba en la cartera, finalmente fue descubierto que contenía las direcciones de varios bancos suizos y que había sido cifrado con el conocido Cifrado de César, con una único desplazamiento de posición en el alfabeto.

Respecto a las hojas con los números de tres dígitos, uno de los expertos del FBI sospechó que apuntaban a palabras de un libro. Sólo faltaba identificar cuál. Regan confesó que se trataba del anuario de su colegio. El criptógrafo del FBI se dio cuenta que entre los dígitos aparecía 7 veces (como 7 eran los secretos que había enterrado Regan) el código "13A". Contando 13 posiciones desde la foto en la que Regan aparecía en el anuario se veía la imagen de un tipo que aparecía con el nombre "El Hombre Misterioso", lo cuál daba a entender que era el separador de cada uno de los "tesoros" escondidos. Finalmente los expertos del FBI no llegaron a decodificar el criptograma completo, y el propio Regan no recordaba cómo interpretarlo del todo, por lo que al final confesó dónde había escondido una lista con las coordenadas de los 7 secretos en texto plano en un recipiente portacepillo de dientes enterrado también, por si perdía las coordenadas cifradas. Así el FBI pudo desenterrar los 7 secretos y a Brian Regan lo condenaron a cadena perpetua

Tiempo después Regan (ya en la cárcel) recordó el mecanismo con la que había cifrado las coordenadas y las comunicó al oficial del FBI.

La historia entera explicada con fechas, pelos y señales, la podéis leer aquí.

La verdad es que pese a que Brian se tomó un montón de molestias en el cifrado de las coordenadas donde estaban los "tesoros enterrados", el FBI resolvió bastante rápido los otros dos retos: El de los números mediante imágenes (aunque fueran palabras), y el del Cifrado de César (este es el Hola Mundo! de los tipos de cifrado que se enseñan en los libros de criptografía). El del reconocimiento de las coordenadas mediante palabras de un libro también es conocido, aunque muy laborioso de identificar, sobre todo porque hay que conocer el libro.

Sin embargo, si Regan hubiera querido llevarse a la tumba la localización exacta de donde escondió sus secretos, tendría que haber destruido el texto en claro con las coordenadas, haciendo morir en el olvido dicho material.
Leer más...

17 febrero 2010

Google Buzz sabe donde estás...¿y quién más?

RSnake, de la página ha.ckers.org también conocida como tiene-que-estar-en-tus-favoritos-seguro-aunque-sea-por-la-cheatsheet-de-XSS, comentaba ayer en su blog que había recibido un e-mail de TrainReq que detallaba una vulnerabilidad en Google Buzz.

Antes de nada, si queréis saber un poco más de este tal TrainReq, con esta búsqueda en Google quizás os suene un reporte suyo anterior. Eso si, si viendo el anterior enlace alguien que pase por vuestro lado os mira raro, no tenéis más que decir que estáis realizando un trabajo de obtención de información sobre un nick que habéis leido por ahí... En resumen, TrainReq es el hacker que accedió a una cuenta de correo antigua de Miley "Hannah Montana" Cyrus y consiguió fotos del estilo "me encanto, y me hago fotos en el baño para myspace" para más adelante distribuirlas por internet (TrainReq, no ella)

Volviendo al tema que nos ocupa, RSnake complementa su post con una imagen de la vulnerabilidad en acción, en la que se ve claramente una vulnerabilidad de Cross-Site Scripting explotada satisfactoriamente (se ha inyetado un código javascript que muestra un alert con la cadena TrainReq) en la versión móvil (m.google.com/app/buzz) de Google Buzz


Qué pasará con las versiones móviles de este tipo de herramientas, que siempre acaban resultando ser una puerta de entrada vulnerable aún siendo muy seguras sus versiones desktop...poca comunicación entre departamentos quizás.

Retomemos el debate infinito sobre lo que supone un Cross-Site Scripting, y recuperemos el condicionante "dónde se encuentra la vulnerabilidad". Por su twitter, RSnake afirma que se trata de un XSS persistente, y seguidamente en su post se exponen 4 ingredientes (como los 4 bloques que forman el logo, que casualidad) que hacen realmente MUY interesante la reflexión sobre esta vulnerabilidad:
  1. Nos encontramos en un dominio que no pasa desapercibido, como es, google.com
  2. Nos encontramos sobre SSL (eso nos da seguridad...creo...)
  3. Nos encontramos en la aplicación Google Buzz, lo que supone un posible secuestro de la cuenta. Bueno, si no has llevado a cabo la guía de Alejandro sobre como desactivar por completo este servicio, esta vulnerabilidad te afecta.
  4. Curiosamente, en la imagen vemos como el navegador nos está pidiendo la confirmación para enviar al servicio la información sobre dónde nos encontramos. ¿Se podrá entonces obtener ese dato explotando el XSS? Podéis probar en Firefox por ejemplo a acceder a la siguiente dirección para comprobar la petición, y NEGAD LA PETICIÓN:
https://m.google.com/app/buzz?force=1#~buzz:view=nearby

Aún no se tiene confirmación oficial por parte de Google sobre si se ha arreglado esta vulnerabilidad y más detalles, pero seguro que no se hace esperar.
Como se puede comprobar, en lo que menos se piensa teniendo esta vulnerabilidad a mano es explotar el Cross-Site Scripting para meter una imagen y hacer una captura...
[+] Google Buzz Security Flaw (ha.ckers.org) | @rsnake
Leer más...

16 febrero 2010

Hackeos memorables. Juan Galiana, el amigo de Facebook.

Tuvimos el placer de conocer a Juan Galiana (twitter) en el concurso de seguridad que organizamos en la Campus Party de Valencia el año pasado. Juan, quedó el segundo y resolvió las pruebas  más difíciles con gran ingenio. Además, se preocupó y no paró hasta averiguar las respuestas de todas aquellas que dejo pendientes.

Galiana, que trabaja como consultor de seguridad en IsecAuditors está dando últimamente algún que otro dolor de cabeza a los administradores de seguridad de Facebook y es que en lo que va de año ya ha publicado dos vulnerabilidades en la sobrevalorada red social. Todo un hackeo memorable.

La primera de ellas, un XSS que permitía la inserción de código HTML o javascript que encontró el 2 de enero y no liberó públicamente el fallo hasta que lo solucionaron un mes después (3 febrero). Aunque según parece y dicta su nota con la línea temporal, sin demasiado interés.

La vulnerabilidad estaba en uno de los parámetros de la versión móvil de la aplicación:

http://m.facebook.com/friends.php?q=%3Cscript%3Ealert(%22XSS%22)%3B%3C%2Fscript%3E
El segundo problema era más complejo, se trataba de un CSRF que permitía la modificación de los datos de un usuario si este se encontraba autenticado en la parte móvil y era engañado para cargar una página web con un contenido similar al siguiente:

<html>
<head>
<script>
function send() {
document.forms[0].submit();
}
</script>
</head>
<body onload="send();">
<form
action="http://m.facebook.com/a/editprofile.php?edit=phone_cell&type=contact";
method="post">
<input type="hidden" name="phone_num" value="600000000">
<input type="hidden" name="save" value="">
</form>
</body>
</html>

Nuevamente, la publicó el día 12 de febrero una vez a habían solucionado, pero esta vez tardando mucho menos.

En la intimidad nos ha confesado que sigue esperando a que arreglen algunos fallos  más para seguir mostrándonos sus vergüenzas.
Eso sí, ha conseguido pasar de ser una persona a la que prestaban poca atención, a formar parte de los agradecimientos que la propia compañía muestra en su página a todos aquellos que siguen su política de publicación responsable.

Desde SbD, ¡enhorabuena Juan!
Leer más...

14 febrero 2010

Reutilización de credenciales de e-banking

Hace relativamente poco publicamos un post sobre lo complicado que es gestionar diferentes identidades digitales para todos los servicios que consumimos en Internet, debido fundamentalmente a la heterogeneidad y variedad de los mismos.

Sin embargo, me gustaría dar a conocer los resultados de un estudio realizado por parte de la empresa Trusteer, en el que deja claro que un alto porcentaje de los internautas (un 73%) utiliza la MISMA contraseña de su banca online para al menos otro servicio online. Y además, un 47% de los usuarios utilizan ambos, identificador y contraseña, en al menos otro servicio. Para concluir estos porcentajes, han escogido una muestra de 4 millones de PCs, por lo que no parece que el estudio se haya hecho entre una pandilla de amigos.

¿Qué consecuencias pueden darse por esta mala práctica? Pues que un inteligente atacante (en este caso es más probable que sea alguien que te conoce) pueda intentar conseguir el identificador y/o contraseña de un usuario en otro tipo de servicio y probar si coincide con la de la banca online de la víctima.

Los bancos cada vez inventan nuevos mecanismos de seguridad (OTP, clave de firma, tarjetas de coordenadas, certificados digitales,...) para proteger al usuario al menos a la hora de realizar operaciones críticas como por ejemplo las transacciones electrónicas. Asimismo los propios servicios de banca online suelen asignar directamente el nombre de usuario y una contraseña aleatoria a cada usuario, para que ni siquiera éste tenga que pensarse qué identificador/contraseña elegir.

Esto me recuerda lo cierto que es, lo que nuestro compañero Yago comentó en el Security Blogger Summit 2010. La seguridad de las acciones de los usuarios en Internet no deberían dejarse en sus manos (o al menos, no todas) y que es más seguro dárselo lo más hecho posible. El usuario ni tiene ni quiere preocuparse por la seguridad, quiere que funcione y que los procedimientos sean ya lo más seguros posibles.

Está demostrado que los ataques que mayor éxito tienen son todos aquellos que conlleven en engañar al usuario para involucrarlo en revelar sus credenciales: phishing, ingeniería social (esta pregunta cae en el examen de cualquier certificación de seguridad) y acceso a sitios inseguros (aquellos operados por cibercriminales que puedan ofrecer servicios gratuitos a cambio de un inocente registro).

Aún así, hay que seguir adelante con las campañas de concienciación, buenas prácticas e información a los usuarios, puesto que si con ellas, se siguen cometiendo ciertas aberraciones, si existiera aún más desinformación, la situación sería aún peor.

El informe original de Trusteer, así como sus recomendaciones e indicaciones lo podéis descargar de aquí
Leer más...

13 febrero 2010

Como deshabilitar Google Buzz (de verdad)

Esta entrada se ha actualizado, lee el final para  un proceso más sencillo.
-------------------------------------------------

No me gusta hablar mucho de temas "calientes" que se acaban leyendo en -todos- los blogs,  mucho menos si encima ya están templados y además de ser algo poco fresco, agotan a todo lector. 

Pero no puedo dejar de explicar cómo deshabilitar de forma correcta el nuevo servicio de Google: el Google Puff, como ya hicimos para Youtube y para Gmail.

Nuestros compañeros de PuntoGeek nos dieron una sencilla directiva para hacerlo de forma rápida. Aunque nos gustaría ampliar esa información, ya que si se deshabilita únicamente con el botón: "desactivar buzz"  que se muestra al final de la página de Gmail, seguiremos publicando contenido y siguiendo nosotros a otros contactos.

Los pasos son los siguientes:

1.- No desactivar Buzz, si lo has hecho, vuelve a activarlo y pulsa sobre la pestaña para mostrar su contenido. En la parte superior se mostrará de que sitios obtiene la información que publicarás y quienes son las personas que te siguen tal y como muestra la siguiente imagen:


2.- Elimina TODOS los portales de la lista de "sitios conectados". Es tan sencillo como pulsar sobre "Editar" y posteriormente en "Eliminar sitio".


3.- Bloquea a las personas que te siguen (otros Puffers), no te preocupes, no recibirán notificación de tan hostil acto. Para hacer esto, pulsa en el número de seguidores mostrado en la primera imagen y una vez  en la lista, accede mediante "Dejar de seguir" (si nosotros también somos puffer suyos) y luego "Bloquear".


Una vez hayas terminado, la lista tendrá un aspecto menos amigable:



Cuando termines pulsa sobre "Finalizar".

4.- Elimina Buzz de Gmail, ahora sí, al final de la página puedes quitar la pestaña de Buzz pulsando sobre "deshabilitar buzz".

Yo personalmente lo dejaré activado sin publicar nada, así veo como avanza el servicio, que es bastante similar a lo que ofrece Facebook si enlazas portales y publicas en tu muro.

A mis contactos, ya sabéis: ¡os estaré vigilando ¬¬ !

Fuente: http://news.cnet.com/8301-17939_109-10451703-2.html

 Actualización:

Ahora Google permite deshabilitar el servicio real y efectivamente desde la sección de "Configuración" de Gmail, y en la pestaña de Buzz, pulsando sobre la opción "Inhabilitar Google Buzz", aunque también se deshabilitará el perfil de Google Reader y otros productos.


Leer más...

Adobe, o ¿deberíamos llamarlo 0daybe?

A mi sinceramente ya me da pena que día sí y día también Adobe tenga que lanzar un boletín de seguridad sobre alguno de sus productos. Llevamos mucho tiempo comentando los problemas con su lector de ficheros PDF Adobe Acrobat, pero hoy le ha tocado conjuntamente a los productos Adobe Flash Player (versión 10.0.42.34 y anteriores) y Adobe AIR (versión 1.5.3.1920 y anteriores).

Poco se ha desvelado sobre las vulnerabilidades, lo único que se ha publicado es que son vulnerabilidades críticas, cuyo impacto consiste en pasarse por alto la sandbox del dominio y realizar peticiones no autorizadas, y que el descubridor de este fallo es el coreano Michael Yong Park (no busquéis información sobre él...). 

Aún teniendo reservados los CVE-2010-0186 y CVE-2010-0187 (este último por una supuesta denegación de servicio también) con detalles "reservados" todavía, lo que tenemos que hacer cuanto antes es actualizar tanto el Flash Player como el AIR a sus últimas versiones disponibles, por lo que pueda pasar, y para evitar que graciosillos nos la lien cuando nos intenten pasar un juego tan adictivo en flash o una super-aplicación que acaban de desarrollar en AIR.

No seais duros con ellos, seamos solidarios que lo están pasando mal con tanto fallo, ¡apadrinemos un .swf, un .pdf o un .air!

[+] Adobe goes critical - (via The Inquirer)
Leer más...

12 febrero 2010

Comprobar tipos de cifrado SSL

Parece que nos pasamos el día hablando de SSL. Normal, teniendo en cuenta ejemplos como el de la Agencia Pituitaria, el fallo que se reportó el año pasado o las coñitas que hace todo geek que se precie sobre la aleatoriedad del openssl de debian.

Hoy os presentamos una herramienta llamada SSL Audit (zip) de Thierry Zoller (G-Sec) para averiguar los cifrados SSL soportados por un servicio de este tipo y sus niveles de fortaleza. Algo similar a lo que hace serversniff.net o SSLDigger, pero un poco más potente, ya que no se limita a los soportados por OpenSSL o NSS. 

Para usarlo tan solo hay que añadir el host y su puerto y pulsar sobre 'Start'. Para rematar, como opción experimental  se realiza fingerprint sobre el servidor en base a la respuesta. Si hace falta más ayuda, en el archivo comprimido también se incluye un breve manual de uso, y en la web un vídeo.

La aplicación aún es Alpha y el fingerprint está verde (el autor reconoce que reporta falsos positivos), aunque por lo que he podido comprobar, funciona bastante bien.


Leer más...

11 febrero 2010

Dominios poco recomendables para navegar

Internet se parece bastante a lo que puede ser una gran Urbe como Madrid, Barcelona o New York. Igual que en toda ciudad hay 'zonas buenas' y 'zonas no tan buenas' (de esas a evitar a ciertas horas de la noche), en Internet hay dominios 'buenos' y otros mas sospechosos.

Evidentemente el hecho de frecuentar una zona aparentemente buena no es garantía 100% de que ahí no te va a pasar nada, en todos lados cuecen habas, pero si es verdad que las probabilidades de que te pase algo desagradable en, digamos Arturo Soria (zona residencial de Madrid, con señoras henchidas de botox y Mercedes), son mucho menores que en la infame 'Calle Montera'

McAfee ha publicado un estudio donde han analizado 'top-level-domains' (lease .com / .es / .uk ...) y ha establecido un Top de dominios en los que mas probabilidades hay de encontrar malware que infecte un equipo.

El estudio, disponible en formato PDF aquí indica que el peor sitio donde debes clicar es en un dominio terminado en .cm (Camerún) y por contra donde menos probabilidades de llevarte un susto es en un .jp (Japon)

España (.es) aparece en un mas que honroso puesto numero 27 muy alejado de la cabeza (veremos como cambia esto con el nuevo plan E orientado a I+D tecnológico)

El top 5 queda así

  1. Camerun (.cm)
  2. Dominios comerciales (.com)
  3. China (.cn)
  4. Samoa (.ws)
  5. Dominios informativos (.info)
Leer más...

10 febrero 2010

Hotspots: virtudes y peligros

En innumerables ocasiones, los que nos consideramos enganchados a Internet, tenemos que buscarnos la vida para nuestras actividades (correo, redes sociales, noticias, blogging,... ) en los lugares más recónditos. Afortunadamente, y gracias a los accesos con 3G en el móvil o mediante "pincho" USB, tenemos el problema resuelto; al menos en el territorio nacional, porque cuando uno va al extranjero (como me pasa a mí mientras escribo offline este post en el Iphone debido a un retraso en el vuelo desde Lisboa) si habilito el 3G la factura es astronómica...

Si se cuenta con el portátil, se puede intentar realizar túneles DNS a través de redes que requieren portal cautivo. Sin embargo, utilizar este tipo de redes puede tener efectos secundarios no deseados. Siempre hay sitios más probables que otros: por ejemplo en el Security Blogger Summit, no faltaron los más avispados que intentaron ataques de arp spoofing, lógicamente para captar cuantos más usuarios/contraseña posibles, cookies, navegación varia en claro, etc... En aquel evento, Luis Corrons monitorizaba la red wireless y avisaba por twitter, pero ¿qué sucede en las redes wireless en las que no hay un vigilante? ¿quién nos garantiza la integridad de nuestras sesiones? Evidentemente, lo más seguro es tunelizar todo hacia un punto seguro y de forma cifrada y así evitar las miradas/análisis de los posibles curiosos.

De hecho, algunos hotspots, podrían ser un buen punto de salida para llevar a cabo actividades no muy bien consideradas, gracias al anonimato que permiten. Siempre he pensado que si tuviera que llevar a cabo alguna mala arte, usaría la red wireless gratuita de un Starbucks por ejemplo. Con la simple precaución de cambiar la dirección MAC del PC (o haría uso de una aleatoria de una máquina virtual), y utilizando la contraseña de acceso a la red que te dan al pedir el caro café (incluso posiblemente desde un coche fuera del local para levantar aún menos sospechas), sería el anonimizador perfecto...

Sin embargo, ¿qué podría suceder en el resto de los PCs cuyos dueños disfrutan de ese agradable café mientras leen su correo o sus noticias? Los sistemas operativos actuales vienen preparados de fábrica para prohibir accesos entrantes a recursos compartidos por defecto (qué tiempos del C$ permitido) aunque siempre hay alguna triquiñuela de red a la que se pueda recurrir como por ejemplo el mencionado ARP Spoofing; y a las malas siempre podemos contar con el factor más probable de todos para tener éxito en cualquier ataque: la ingeniería social sobre la inocencia humana.
Leer más...

09 febrero 2010

Top 6: Mejoras en seguridad para Windows 7

Durante el Security Blogger Summit que organizó Panda Security la semana pasada, Yago expuso en una de sus intervenciones la imprudencia que supone dejar la seguridad del ordenador exclusivamente en manos de los usuarios.

Estos no suelen preocuparse y tampoco se les debe hacer responsables únicos de esa materia, por tanto se debe hacer hincapié en la construcción de sistemas operativos y programas más robustos.

Microsoft parece que lo tiene claro, y ha apostado por reforzar las medidas de seguridad de su último sistema operativo Windows 7. Además de fortificar el kernel, ha mejorado las funcionalidades de seguridad que profesionales y usuarios pueden utilizar para su beneficio.
  1. BitLocker To Go. Microsoft en Windows Vista añadió BitLocker que permite el cifrado del disco duro interno. Ahora con BitLocker To Go, disponible en las ediciones Enterprise y Ultimate de Windows 7, extiende la funcionalidad a los discos duros externos y USB. Mantener la confidencialidad de la información que almacenan estos dispositivos de un posible robo o extravío es primordial en una organización.
  2. Navegación más segura en Internet Explorer 8. El navegador que ya viene incorporado en Windows 7 incluye: navegación InPrivate en la que no se almacenan los datos de sesión ni los archivos temporales, el historial web, las cookies están deshabilitadas, modo Protected, filtro SmartScreen que te avisa de sitios inseguros, y prevención ClickJack para proteger al usuario del clickjacking, enlaces de apariencia normal o botones que esconden código embebido en donde se oculta un enlace malicioso.
  3. Microsoft Security Essentials. Software adicional para protegernos contra virus, spyware, rootkits y trojanos disponemos de MSE. No está al nivel de las suite de Symantec, Panda, McAfee o Kaspersky. Microsoft también dispone de Windows Defender y el firewall de Windows que proporcionan un alto grado de seguridad.
  4. AppLocker. Microsoft recomienda que los usuarios dentro de una organización no dispongan privilegios de administración, si por el contrario fuera necesario dárselos, con AppLocker se protege a la organización no permitiendo a los usuarios ejecutar cualquier software, sino especificando que aplicaciones puede usar y bloqueando aquellas que puedan resultar peligrosas.
  5. Más control de cuentas de usuario. Muchos usuarios de Windows Vista se quejaron por los continuos pop-ups solicitando confirmación cuando se abrían los programas, esto supuso que muchos de ellos desactivasen la funcionalidad UAC lo que hacía más inseguro su sistema operativo. En Windows 7 el control de cuentas de usuario (UAC) es mucho más flexible, reduciendo el número de aplicaciones y añadiendo cuatro opciones de notificación.
  6. Copias de seguridad. La funcionalidad de copia de seguridad y restauración ha sufrido un lavado de cara en Windows 7. Permite seleccionar los ficheros, librerías o unidades de los que queremos hacer la copia y programarla para que se realice en un momento determinado, o realizar la copia en el momento deseado. Una vez inicializado el proceso Windows 7 realiza un seguimiento de los archivos modificados o borrados que serán añadidos a la copia, además puede almacenarla en un disco duro externo, DVD o en una ubicación de red (funcionalidad incluida en las ediciones Professional, Enterprise o Ultimate).
[+] http://www.networkworld.com/news/2010/020110-windows-7-tips-best-security.html?page=1
Leer más...

08 febrero 2010

El KGB estaba en todas partes

No es algo nuevo que bajo el telón de acero uno de los deportes favoritos de los regímenes totalitarios era el auto-espionaje a sus propios ciudadanos en busca de 'disidentes'

Tal vez hayáis visto la película 'la vida de los otros' que refleja muy muy bien lo que ocurría en la Alemania del este.

Hoy día, con el advenimiento de 'lo digital' es relativamente fácil implementar un sistema de monitorización al estilo de SITEL, pero ¿Y antes? ¿Realmente pensáis que en esa época no había 'hackers' que ponían su talento al servicio de los gobiernos? Hace poco cayó en mis manos un post contado en primera persona por un habitante de la URSS en los 80 donde narra como el KGB tenía implementado un rudimentario pero efectivo sistema de espionaje a gran escala.

Por lo visto la idea generalizada que tenia la sociedad Rusa sobre como 'podían ser espiados' estaba basada en agentes vestidos con gabardina apostados frente a sus casas y micrófonos escondidos en sus domicilios.

Pero nada mas lejos de la realidad. Según la investigación de Hovik Melikyan, que en los 80 era un adolescente, el sistema que el KGB empleaba para monitorizar a sus ciudadanos estaba basado en una peculiaridad de ciertos teléfonos 'antiguos' (esos que tenían una ruedecilla con números).

Según narra Hovik, en un momento dado su familia recibió la visita de alguien proveniente de los EEUU, y pese a que existían rumores sobre que esas visitas llamaban la atención del KGB, nadie se tomaba muy en serio esos rumores. El caso es que en el momento que el ilustre huésped llego a casa, el teléfono empezó a hacer cosas raras, casi siempre estaba inutilizado y curiosamente todos los días a las 9 de la mañana y a las 9 de la noche emitía un RING. En otra ocasión el teléfono empezó a retransmitir una conversación aparentemente de un hogar cualquiera, con el sonido propio de un salón, conversaciones del tipo 'hoy para comer voy a hacer X'. Lo inquietante es que el sonido no provenía del auricular (como hubiera sido lógico) sino del propio teléfono.

Movido por la curiosidad, Hovik destripó el teléfono y se dio cuenta de una particularidad cuanto menos curiosa, el 'Ringer' (realmente no se como traducir este término pero creo que se entiende) es en si un altavoz (con acceso a la linea telefónica) capaz de emitir sonidos (los típicos Ring Ring) y, lo que tal vez no sea tan obvio es que, un altavoz de esas características es a la vez un micrófono. Supongo que muchos de vosotros en alguna ocasión habéis usado unos cascos cualquiera como improvisado micrófono pinchando el jack en la entrada micro y pese a que el sonido es un poco deficiente, funcionar funcionan.

¿Que estaba sucediendo entonces? Por lo visto el KGB tenía implementado un sistema a gran escala de escuchas capaz de capturar conversaciones en cualquier sitio donde hubiera un teléfono empleando el Ringer como micrófono (virtualmente, en cualquier hogar, oficina, etc). Y ese era el motivo del misterioso Ring de las 9 AM y 9 PM, sin duda era el turno de vigilancia de los agentes del KGB.

Impresionante historia.
Leer más...