Durante aproximadamente 7 meses hemos estado recopilando sitios webs con distintas vulnerabilidades, gracias a nuestras propias investigaciones o colaboraciones de distintos usuarios, hasta la fecha registramos aproximadamente 1058 sitios web, de distintos paises, distintos tipos de entidades (universidades, bancas, etc) y con distintos estados. Actualmente en Secureless manejamos 3 tipos de estados, las Reportadas, No Reportadas

La diferencia que existe entre las Reportadas y las Sin Reportar, principalmente se da porque los sitios web no publican un correo o alguna forma de contacto para poder reportar este tipo de fallas, por lo general se limitan a poner un formulario de “consultas” y muchas veces en bancos, universidades o sitios del gobierno, hay que completar un formulario con cientos de campos obligatorios.

Los sitios web que realmente deberian tener este tipo de procedimiento como los bancos, Universidades o sitios del gobierno que manejen información sensible de personas, no lo hacen. Muchas veces debemos enviar el reporte a correos genericos y/o aleatorios como contacto@dominio, info@dominio o webmaster@dominio, sin tener respuesta.
La relación que existe entre las Reportadas y las Solucionadas, nos demuestra que de alguna forma estamos apuntando para el lado correcto, ya que el 90% de las vulnerabilidades reportadas se solucionan.

De los tipos de vulnerabilidades, hay dos categorías que pelean el puesto para ser los que más sitios registran, el SQL Injection y al Cross-Site Scripting

Es curioso, ya que una es client-side (xss) y la otra server-side (sql-i), pero ambas ocurren por una mala sanitización de los parametros de entrada.

La que los sigue es Full Path Disclosure, una vulnerabilidad que por si sola no es muy critica y que muchas veces se le da la responsabilidad al encargado del servidor, que no deshabilita los errores o el debug, aunque segun yo, el programador debería ser capaz de manejar los errores y validar los parametros de entrada para evitar el crash de la aplicación y asi evitar cualquier tipo de error sin atajar. El tipico ejemplo, cuando modificamos los parametros por GET y transformamos una variable en un Array.

Si analizamos la cantidad de sitios por tipo de organización, nos encontramos con el siguiente gráfico:

Las universidades son de las entidades (segun nuestro criterio) que más vulnerabilidades tienen, ya que muchas de ellas les abren espacios a sus clientes alumnos, por lo general un servidor compartido entre usuarios y en algunos casos extremos, un servidor compartido con aplicaciones de la universidad (intranets, etc).
Luego viene los del gobierno, que mientras más sitios y sistemas ofrecen, menos control tienen sobre las aplicaciones y sobre los datos que manejan. Es muy comun en sistemas y sitios del gobierno encontrar tecnologias antiguas y en muchos casos, obsoletas.
Con eCommerce, me refiero a sitios que ofrecen “comercio por internet”, como PC Factory, Falabella, Ripley, etc.
Finalmente tenemos a los queridos Bancos, que sinceramente ellos ni si quiera deberian aparecer en este listado.

El último gráfico, corresponde a sitios segun su pais o dominio

No significa que Chile sea mas vulnerable que los otros, simplemente que en un principio nos dedicamos unicamente a almacenar sitios chilenos, pero poco a poco fuimos aceptando colaboraciones de otros paises y otros dominios.

En Chile, los bancos tienen una campaña contra el phishing donde se limitan a entregar manuales y decir “no ingreses tus datos donde no debes”, pero realmente no se preocupan de tener mecanismos de validación y protección, permitiendo que cualquier persona pueda suplantar su identidad y usar la confianza que tiene el usuario en el sitio.
Existe un sitio llamado “avispate.cl“, que supuestamente es para hacer un llamado a la gente y educar para que no caigan en este tipo de trampas y no entreguen información a cualquier sitio.

Bien, por un lado tenemos que los usuarios entregan información a personas que no corresponden, que caen en las trampas pero por otro lado, algo que es claramente responsabilidad del banco: Hacer que sus sitios y sistemas sean 100% seguros!

Los bancos en lugar de ayudar a los usuarios y prevenir este tipo de ataques, prefieren cobrar:

En secureless, comenzamos a trabajar en una investigación en busca de vulnerabilidades XSS, CSRF y otras que puedan afectar directamente al usuario. Nuestro propósito es dejar en claro que los bancos deben ser competentes y responder por las fallas de seguridad que tienen. Hasta ahora, según nosotros, como este tipo de vulnerabilidades no les afecta a ellos, sino que afecta a los clientes, entonces no se preocupan lo suficiente.
El proyecto consiste en publicar estas vulnerabilidades diariamente durante un par de dias, demostrar y dejar al descubierto este tipo de negligencia. Comenzaremos por Chile, luego seguiremos atacando bancos de otros paises.

Sobre XSS y CSRF …

Las vulnerabilidades XSS permiten realizar modificaciones en los sitios web por el lado del cliente, cuando una entidad bancaria con certificado ssl (https) tiene este tipo de vulnerabilidad, se combierte en un sitio potencial para ser atacado y sus usuarios los afectados. Por ejemplo, si un sitio permite inyectar código html o javascript, facilmente podriamos poner un iframe que ocupe todo el ancho y alto del navegador, y que el usuario no se de cuenta que está visitando a otra página.

Por otro lado tenemos los ataques CSRF, que combinado con XSS, practicamente es posible hacer lo que queramos con el usuario: llevarlo de un sitio a otro, pasar parametros de un sitio falso a uno verdadero, etc.

Secureless nace simplemente de la necesidad de investigar y aprender aun mas sobre este tipo de vulnerabilidades y seguridad en la web. Aunque a muchos no les parezca lo correcto, con el tiempo nos hemos dado cuenta que las fallas se corrigen mucho mas rapido cuando son publicadas y creemos que de esta forma podemos ayudar a que los sitios sean más seguros.

Lo que buscamos en esta version es explorar un poco más en el mundo de la (in) seguridad en aplicaciones web. En esta primera version agregamos la posibilidad de que la gente pueda reportarnos mediante un mensaje cifrado sitios vulnerables y de esta forma poder contribuir de forma “segura” a este proyecto, aunque la mayoría (99%) de los sitios publicados son producto de nuestra propia invesgitacion, agradecemos a quienes nos apoyan y nos envian información al respecto.

Como primera anecdota, tuvimos el caso de NIC Chile quien fue notificado al mismo tiempo de publicar la vulnerabilidad en Secureless, quienes resolvieron el problema en menos de 20 minutos. La vulnerabilidad que afectaba a NIC Chile era de tipo XSS en uno de sus scripts cgi.

Ya estamos planificando noches de “hacking” para dedicarnos a seguir publicando sitios importantes con fallas de seguridad.

Links:

- Twitter @secureless

- Secureless.org

El código es simple, requiere python-twitter y pyzenity y lee los parametros de OAuth como TOKEN y SECRET etc desde un archivo llamado .simple-pytweet en tu $HOME.

El esquema de lo que tenemos en mente es el siguiente:

Podemos ver tres antenas sobr ela torre triangular, las identifiqué como “verde”, “roja” y “negra”. El color verde simboliza nuestra LAN y nuestra WLAN y la roja nuestra DMZ donde se encuentran nuestros servidores con nombres de personajes de los simpsons.
La idea principal de todo esto es tener dos redes separadas, nuestra WLAN y LAN que simplemente tenga acceso a internet y que nuestra DMZ tenga entrada y salida a internet, mediante una VPN, un tunel o como sea, la idea es dejar abierto los servidores al público y en algun momento (cuando armemos el proyecto) entregar accesos a shell para servicios de anonimato para quienes lo necesiten.

El evento, llamado “Archlinux Orphan’s Day” no busca difundir el uso del software libre ni nada por el estilo, simplemente orientar a los usuarios de archlinux sobre cómo empaquetar software para la distribución, adoptar los ya existentes y cómo mantenerlos. Para la organización hemos utilizado el wiki del hacklab donde pueden encontrar información sobre el temario, programa, etc.

El modelo actual de difusión del software libre no está siendo efectivo, queremos mejorarlo.

En una reunión improvisada que tuve con 3 o 4 amigos, salió el tema del software libre y el cómo se está difundiendo en el país. Cuestionamos la efectividad de los distintos centros de difusión, grupos de usuarios, métodos y formas de difusión, etc. Dentro de tantas cosas que conversamos, decidimos volver a juntarnos para continuar conversando el tema y así buscar una solución a los distintos problemas que encontramos. Lo primero que decidimos fue que ante cualquier opinión o desacuerdo que tengamos, actuaremos. No buscaremos llenarnos la boca de palabras. Nuestro fín, es encontrar una solución al problema de la difusión de la filosofía del software libre en nuestro país, para ésto, hicimos una lista de los principales problemas que detectamos en el actual modelo de difusión:

• Los distintos grupos de difusión no están practicando lo que predican.
• Los eventos de difusión buscan masividad y no efectividad.
• Por lo general se buscan usuarios, dejando de lado el concepto de libertad.
• Se busca difundir el software libre usando software, drivers o firmwares privados.
• Las charlas no son efectivas, pues siempre asiste la misma gente. Además, las personas buscan que les enseñen, no que les digan cómo hacer las cosas. (hay una pequeña situlesa en aquella diferencia)

Para éstos problemas, nosotros encontramos la siguiente solución:

Mediante un proceso de educación y concientización, buscamos una migración efectiva y no masiva. No nos enfocamos en migrar sistemas operativos, sino en migrar mentes.

Antes de comenzar, me gustaría darle créditos a dererk por la parte de la frase donde dice que buscamos migrar mentes y no S.O.

Bien, ya hemos tenido dos reuniones en las cuales nos hemos dado el trabajo y, luego de largas discusiones, tenemos un borrador con los apuntes y con las decisiones que hemos tomado. La primera reunión que tuvimos, era para encontrar los problemas y fallos de los actuales modelos de difusión del país, tambien proponer soluciones y junto con todo ésto, agendar una segunda reunión donde podamos ver el documental “Revolution OS“, para quienes no lo han visto, y además, afiatar el compromiso de cada uno con éste nuevo proyecto.

Reunión 1

Mediante distintas analogías, logramos determinar lo importante que es el software libre y la importancia de difundirlo.

Llegamos a la conclusión que gnu/linux no es para todos. Ésto puede sonar bastante talibán o bastante cerrado, pero es a lo que llegamos. Hicimos la analogía del dildo de goma gigante, si tu quieres lo puedes usar y metertelo por el culo, nadie te dice que no lo hagas, pero no es para ti, estas en la libertad de hacerlo pero, claramente (creo), no lo harás. Con GNU/Linux pasa lo mismo,  cualquier persona puede descargarselo, instalarlo y usarlo, pero claramente no todos podrán sobrevivir con él, no todos podrán ser linuxeros y no todos compartirán la filosofía que conlleva. En simples palabras, GNU/Linux no es para todos, es para quien quiera usarlo.
Bajo ésta premisa, nos enfocaremos en éste tipo de usuarios, los que quieran usarlo.

Otro punto que discutimos, fue el no atacar a la competencia, a nuestro rival: Microsoft. Sino buscar forma de, por medio del argumento y la palabra, lograr que las mismas personas se den cuenta de lo malo del software privado. Tambien, nuestro amigo leo, hizo la analogía con una frase que dijo la Madre Teresa de Calcuta: Nunca iré a una marcha que diga “no a la guerra”, pero si dice “si a la páz”, iré. No buscamos el “no al software privado” o el “no a microsoft”, mas bien buscamos el “si al software libre”, “si a gnu/linux”.

Con todo ésto, buscamos, claramente, una migración efectiva y no masiva, buscamos la elección por parte de los usuarios, la concientización. Creemos que para evangelizar, debemos reforzar las bases de lo que estamos promoviendo. No podemos promover el uso de GNU/Linux si nos olvidamos de la base del software libre y sus libertades.

Hicimos la siguiente analogía para explicar un poco el tema del software privado vs software libre:

Imaginemos una escalera gigante y mucha gente, lo perfecto seria que cada vez que una persona suba un escalon le diga a la otra persona, “oye, logre subir, mira hazlo de esta forma” y asi sucesivamente van avanzando hasta llegar al ultimo escalon, pero, que pasa si las personas no dicen como subir pero sin embargo los ayudan a subir, y les cobran algo a cambio, quien llega a la cima primero?

Segúnda reunión

Vimos “Revolution OS” y armamos un debate, entre quienes ya lo habiamos visto y entre quienes lo vieron en ese momento, sobre cómo captaron el mensaje del documental. Tomamos apuntes sobre los distintos temas tratados en el documental y además, fijamos puntos para una próxima reunión. La idea de ésta segúnda reunión, es haberla hecho entre pocas personas, los que estamos formando parte de éste movimiento, para presentarnos con ideas claras hacia las demas personas. Hoy Sábado, tenemos nuestra tercera reunión, donde invitamos a personas que nosotros estimamos conveniente, que sabemos que podría existir interés hacia el software libre, amigos o conocidos de nosotros, para estudiar su reacción, ver como enfrentan el tema y cómo ven el documental. Luego de esta tercera reunión, tenemos planeado hacer algo un poco más masivo.

Para poder organizarnos, armamos un wiki en el cual vamos tomando notas y apuntos de las distintas reuniones que tenemos. Lo tenemos en http://wiki.hacklab.cl

Analizaré tanto los servidores de las empresas como sus sitios web, al igual que los sitios web de sus clientes.

Desde hoy en adelante, con el fin de ayudar y promover la seguridad de la información en Chile, comenzaré a publicar -en lo posible- todos los fines de semana una lista de al menos 5 sitios con fallas de seguridad de distintos tipos y, a fin de cada mes, haré un resumen de todos los
sitios publicados durante el mes.

• dirhack:  Script escrito en bash que nos ayudará al momento de querer hacer auditorias en nuestro servidor web con multiples usuarios. El script buscara en los directorios especificados los ficheros con información sensible que esten legibles y/o modificables por otros usuarios. Se puede ejecutar desde el explorador web o desde algun tipo de terminal o consola.

• password salt cracker: Tambien escrito en bash, este script será útil cuando queramos romper algun password encriptado con un salt. Sirve para cualquier tipo de encriptacion como md5, sha, shadow, etc. La forma en que trabaja es netamente fuerza bruta y se basa en un diccionario de palabras. Lee palabra por palabra y la encripta con el salt especificado, si las password coinciden entonces bingo!.

• web login por fuerza bruta/brute force web login: Con esta utilidad podremos realizar pequeñas pruebas a nuestro sistema de autentificacion y tambien verificar la calidad de nuestras contraseñas. Consiste en realizar determinadas peticiones POST a paginas que validen el login de una sesion. Debido a que esta basada en un diccionario de palabras, podría tardar horas en dar algun resultado.

• firewall-router: Este es otro script en bash que facilita la creacion de reglas sobre iptables. Nos puede servir para que nuestra maquina sea un router y tambien firewall. Permite el routeo de paquetes, redireccionamiento de puertos, bloqueo de puertos, etc. Es bastante util y facil de usar, ademas permite el uso de ficheros externos para definir redirecciones de puertos, direcciones ip para bloquear, etc.

• twitsh/twitbash: Lo desarrolle pensando en facilitar el uso te twitter en fluxbox. Esta herramienta no nos servira para leer los twits de otra gente pero si para enviar nuestros updates.

La idea es que este ORM/Framework haga todas las tareas de consultas y accesos a la base de datos de manera mas simple, por ejemplo, en Saporm, para que el framework sea capaz de abstraer la base de datos solo hay que crear una clase con los atributos correspondientes, segun los campos que tenga la tabla de la base de datos.
Por ejemplo, tenemos dentro del directorio “model” la siguiente clase:
(Usuarios.class.php)

Saporm se encargará, automaticamente, de mapear la tabla “Usuarios” con sus atributos “id, username y password” y nos permitirá trabajarla como si de un objeto se tratara. La herramienta nos creara un objeto con el nombre Usuarios que contará con varios métodos y atributos, como por ejemplo:

$usuarios->search();
$usuarios->loadData();
$usuarios->select();
$usuarios->query();
$usuarios->insert();
$usuarios->update();
…

Este framework será extendible a distintos motores de bases de datos, actualmente estoy desarrollandolo para MySQL y pienso exportarlo a PostgreSQL y a Oracle.
Hasta el momento no llevo mucho programado, pero he hecho avances significativos, me pasé todo el día programando y mentalizando el modelo mental/lógico para lograr lo que busco. Saporm tiene las funcionalidades para precargar datos desde distintas tablas y para hacer una busqueda condicionada.

A continuación, un ejemplo de es la estructura básica para implementar Saporm:

Con este codigo obtenemos una instancia de SimpleORM llamada $SimpleORM, podemos referenciarla para cambiarle el nombre para trabajar con un nombre de variable mas amigable, por ejemplo $db: $db = &$Saporm y, desde ahora en adelante, trabajaremos con el objeto $db.

Si queremos precargar los datos de la base de datos, tenemos el método loadData(), que pondra a nuestra disposicion un arreglo con todos los registros de la tabla en cuestion.

Esta seria una manera de listar los 3 primeros registros de la base de datos, previamente cargada en los atributos de la clase “usuarios”.

Tambien es posible hacer una busqueda con criterio usando el metodo search():

Espero poder seguir con esta idea y lograr un ORM sencillo y facil de usar, que nos permita el desarrollo de proyectos pequeños en poco tiempo y de manera más agil. Cuando tenga un poco mas maduro el codigo lo pondre para que lo puedan descargar. Si alguien tiene ganas de unirse o darme feedback, puede contactarse conmigo sin ningun problema.

Editado (05-05-2009):
- Se unió osu (es que no le gusta que lo nombren) al desarrollo y decidimos cambiarle el nombre, ya que “SimpleORM” ya estaba creado como proyecto en SourceForge. Desde ahora lo llamaremos Saporm.

El servidor lo compré por recomendación de vostorga en Linode. Espero que me sirva.

Eso.

Materiales:
En este caso utilizaremos un Mouse optico (cualquier marca) USB, pero tambien puede ser un mouse no-optico y de cualquier interfaz (usb, ps/2, etc) y algunas rejillas para sostener el mouse sobre la puerta dejandolo a una distancia razonable para que active el sensor, acomodaremos la sensibilidad con materiales extras como carton o plastico que nos ayuden con el roce de la puerta con el Mouse.

1. Mouse:
   
2. Cable de red o usb para extension: Con este cable de red o cable largo usb podremos crear una extension por si nuestro PC esta lejos de la puera o ventana.
3. Cinta adhesiva: Para poder fijar nuestro mouse a la plataforma que crearemos donde se generara el roce.

Preparacion (el hack):

Abrimos nuestro Mouse y lo desconectamos del cable, lo dejamos libre

Creamos alguna plataforma de apoyo en la pared donde este la ventana o la puerta que queremos monitorear y montamos el mouse con la imaginacion de cada uno:

Cuando ya tengamos todo montado, debemos alargar el cable usb del mouse para que llegue hasta nuestro computador.  Se puede hacer cortando a la mitad el cable del mouse y añandiendo una extension de cable de red, no muy larga, 3 o 4 metros.

Cuando tengamos la conexion hecha revisamos que todo quedo en orden, conectamos el un extremo del cable al computador y el otro exremo al mouse, verificamos que funcione perfecto, que se encienda la luz, verificamos los logs de systema dmesg|tail o tail /var/log/syslog y todos esos sintomas que nos dicen. Dejamos ejecutando en una consola el comando: cat /dev/input/mice si es usb o cat /dev/psaux si es un mouse ps/2, una vez hecho esto vamos a donde esta el mouse y calculamos una distancia apropiada para que al cerrar o abrir la puerta (o ventana) el mouse detecte el movimiento, cuando en la consola donde dejamos corriendo el comando aparezcan caracteres raros es porque ya esta listo. Si les queda muy alto el mouse de la puerta, puede agregar un carton o un plastico (como un ala) que haga el roce con la puerta.

Cuando esten todos estos pasos cumplidos, tendremos nuestro sensor ya instalado, lo probamos abriendo y cerrando la puerta y vamos viendo la salida del comando cat en nuestra consola. que el mouse fue detectado.

Podemos asegurar nuestro Mouse para que quede bien firme.

Cerramos nuestra consola donde teniamos ejecutando a cat, sellamos bien el mouse, dejamos todo bien instalado.

Aplicacion/Programa:

- Descarga:
He desarrollado un prqueño software (libre porsupuesto) que nos permitira interactuar con nuestro querido sensor. Lo pueden descargar desde aqui.
- Instalacion:
Nos situamos en el directorio donde lo hemos descargado y escribimos: tar xjvf door-version.tar.bz2 Ingresamos al directorio creado: cd door-version (Pueden leer el fichero README y el INSTALL para mas informacion) Compilamos el programa: make Nos ponemos como root y lo instalamos: make install Nos quedamos como root y ejecutamos el programa de la siguiente manera: door /dev/input/mice 5 (lease README para mas informacion) Y comenzamos a disfrutar de nuestro mouse sensor.

Demostracion:

www.youtube.com/watch?v=AuSOYCTA4Es

• Distintos niveles de privilegios (administrador, owner de un canal, access de un canal)
• Funcion para realizar busquedas en Google (!google <palabra>)
• Function para buscar definiciones en Google (!define <termino>)
• Distintas funciones de administracion de usuarios (!admin|access add|del|list)
• etc

Algunas de las caracteristicas de este bot es su proteccion anti flood que se define por el owner del canal y el Oráculo (Oracle; término puesto por mi a esta funcionalidad) que permite enseñar al bot definiciones de palabras para luego ser consultadas (!learn palabra significado, ?? palabra).
Este bot corre bajo php-cli (command line interface), es decir, por consola y tambien puede ser ejecutado desde la web. Queda trabajando como un demonio.

Version Actual:
La version actual es la misma desde enero del año 2007, no he vuelto a tocar el codigo (aunque sigo usando el bot), funciona todo menos las busquedas de terminos y definiciones en Google que, me imagino, hay que hacerle un par de modificaciones al codigo para que parsee bien las busquedas.

Changelog

VERSION 1.0.4 – 26 ENE 2007

- Cambiado el sistema de autentifiacion. Se verifica que el usuario
este identificado con NickServ.

VERSION 1.0.3 – 19 ENE 2007

- Se agrego a la clase Bot el metodo TXTflood( … ) que verifica
el flood de texto de un usuario en un canal especifico, esta opcion
puede ser habilitada o desactivada por usuarios con privilegios mediante
!flood on|off en el canal.
- Se ha reescrito la clase que permite la identificacion y permite que los usuarios
tengan distintos privilegios. (CHAdmin.)
- Corregido el bug que expulsaba de manera distinta a !k o !kick (0 nick o [spacio] nick)
- Agregada la clase Google con los metodos !define y !google.

VERSION 1.0.2 – 16 ENE 2007

- El bot corre en segundo plano (fork).
- Agregada una funcion extra en la clase del bot usando el binario ‘numerador’
ubicado en el directorio extras, la funcion es !num NUMERO.
- Fixeado bug que causaba la caida del bot al enviar dos veces el comando
para setear una clave. (reportado por Pons)
- Agregado soporte para unrealircd (antes solo habia sido probado en bahamut).
- Testeado en dancer-ircd, bahamut, Hyperion y unrealircd.

VERSION 1.0.0 – 15 ENE 2007

- Corregido el fallo que cerraba la conexion a la base de datos por idle.

Descargar:
Version 1.0.4: zip | tar.gz | tar.bz2