La URL vulnerable es http://tvndeportes.cl/intersitial/index.html?link=, a “link” podemos asignarle cualquier URL y el navegador será redireccionado a esa URL. Por ejemplo:

http://tvndeportes.cl/intersitial/index.html?link=http://sitio.webmaligno.com/pics/pics.exe

Quizá este método solo nos permita redireccionar a un usuario y nada mas, pero con un poco de imaginación y trabajo, perfectamente ese usuario podría ser engañado por email para ingresar a un sitio confiable de TVN y redirigirlo a un sitio de streaming falso, donde le haga aceptar la descarga de un archivo (troyano) para que pueda ver el video. Aprovechandose de todo esto del mundial, la locura por ver los partidos en alta definicion, perfectamente un atacante podría insitar a un usuario a descargar un programa para poder ver el partido, desde el sitio de tvn, en alta definición y gratis, obviamente “ese” programa sería un virus o algo similar.

Compartir/Guardar

Generalmente los criterios para asignar accesos a los distintos sistemas es los mismos, existen las que son aleatorias con y sin patrones, las típicas “dos letras iniciales del apellido seguido del año de nacimiento”, etc. Quizá el problema no está en asignarles claves por defecto fáciles a los usuarios, sino en los mismos usuarios que no las cambian o bien tardan una eternidad en ingresar por primera vez al sistema. Por esto mismo, pienso que la seguridad de los sistemas no debe depende de los usuarios, debe depender del sistema, a menos que tengamos muy acotado el tipo de usuarios que tendrá el sistema.
En este post hablaré sobre los tipicos accesos a universidades, cuentas de correo de empresas, cuentas de servidores ftp, ssh, web, etc.

En primer lugar, pienso que, el hecho de querer facilitarle las cosas al usuario final asignandole una password que sea “recordable”, es riesgoso. El hecho de que una password siga un patrón quiere decir que es altamente descifrable o descubrible por un atacante. Como patrónoes entendemos password como:

• usuarioYYYY: donde YYYY puede ser el año de nacimiento, el año que la persona ingreso a la institución u otra cosa que tenga relación.
• Primeros o últimos 3 o 4 digitos del rut: Por ejemplo si el rut de una persona es 6.714.870-9, la clave podría ser 6714 o bien 8709
• Nombre de usuario: aunque no lo crean, es muy comun tambien que se asigne como contraseña lo mismo que le entregan como nombre de usuario
• Juego con las iniciales de los nombres y/o apellidos y año de nacimiento o año de ingreso: Por ejemplo, para Juan Perez, una posible password sería jperez2009, juanp2009, jp2010, etc.

Quiza lo que acaban de leer pareciera ser algo muy estúpico o algo demasiado básico, pero es increible que suceda. Hace un par de semanas publiqué dos ejemplos muy claros al respecto, lo pueden ver en:

La poca importancia de la seguridad en la Universidad Mayor
Seguridad en accesos de ex alumnos del Instituto Profesional CIISA

El hecho de saber un patrón de asignaciones de contraseñas por defecto de una empresa o alguna institución les abre una puerta trasera enorme y, a mi criterio, es una vulnerabilidad que debe ser considerada critica si se desea proteger el robo de información y la privacidad de la institución y de los mismos usuarios.

La contraseña de un usuario puede comprometer el acceso a otros usuarios, por ejemplo si mi password por defecto corresponde a la primera inicial de mi nombre, seguido de mi apellido, luego un guión bajo (_) y finalmente mi año de nacimiento y es interceptada por algun atacante, sea como sea, independiente de que esa persona haya querido atacarme a mi o independiende de que si yo tengo informacion privada o si me interesa la seguridad o no, estoy dando el paso para que esa pesona pueda adivinar contraseñas de las demas personas.

Un caso muy comun es el hecho que cuando una persona ingresa a trabajar a una empresa generalmente le preparan un computador con todo listo, su cuenta de correo lista, configurada y lista para usarse por lo que el usuario jamás tendrá curiosidad de cambiarla, asi mismo todos o la gran mayoría de la empresa. Una persona sin muchos conocimientos podría probar el mismo patrón de contraseñas para ingresar como su compañero de trabajo, luego que ingresa al correo de esa persona exitosamente, lo gracioso sería intentar ingresar a otras cuentas por ejemplo al sistema de tickets u otros sistemas con el que podríamos hacer más daño. Según mi punto de vista, las contraseñas por defecto deberían ser por defecto aleatorias y obligar a que el usuario se loguee apenas es creada la cuenta y cuando ingrese por primera vez obligarlo a cambiar la contraseña.

Los desarrolladores o administradores pueden quejarse con la típica frase “es que son sistemas que acceder desde la red interna, desde la lan solamente”, pero la verdad es que uno nunca sabe desde que lado esta el atacante.

Aunque no lo crean, muchas veces esas mismas empresas que le asignan esas contraseñas por defecto a sus empleados, lo hacen tambien con sus clientes. Por ejemplo, una empresa de hosting o diseño web, en ambos casos, cuando le quieren dar acceso a ftp o bien acceso a algun sistema para que hagan el “testing”, cumplen el mismo patron, si no es “123456″ es, por lo general, el nombre del cliente. Puedo entender que es engorroso asignar contraseñas tan dificiles de recrodad a los clientes para que hagan simplemente un checkeo de una aplicación, pero aveces la seguridad requiere de un poco de esfuerzo.

Compartir/Guardar

Lo más comun, y que me da muca risa y aveces rabia, y me desespera un poco, es ver como los usuarios avanzan lentamente, directorio por directorio, hasta llegar a la destino final. Por ejemplo:

$ cd /
$ cd home
$ cd usuario
$ cd public_html
$ cd includes

En lugar de ejecutar directamente
$ cd /home/usuario/public_html/includes

Y peor aun, hay veces que el usuario es inseguro y prefiere verificar si lo hizo bien y termina su caminata por los directorios haciendo un “pwd”:

$ cd /
$ cd home
$ cd usuario
$ cd public_html
$ cd includes
$ pwd
/home/usuario/public_html/includes
$

Hay algo que me desespera aun mas, es cuando el usuario tiene la necesidad de listar el contenido de CADA directorio:

$ cd /
$ ls -l
$ cd home
$ ls -l
$ cd usuario
$ ls -l
$ cd public_html
$ ls -l
$ cd includes
$ pwd
/home/usuario/public_html/includes
$ ls -l

Para los que no saben, para esto existe un truco (tip!), no digo que se aprendan los directorios de memoria, pero pueden ejecutar todo en una sola linea, por ejemplo, cuando escriben / pueden presionar tabular dos veces y automaticamente aparecerá el listado de archivos y directorios dentro de /. Asi mismo, si escriben /home/ y dos veces tabular, veran todo el contenido de /home, sin tener que ejecutar cd /home, presionar enter y luego un ls.

Otra cosa que es muy comun, aunque no lo crean, es encontrar las passwords de las bases de datos, especialmente de MySQL. La gente está acostumbrada a ejecutar el comando mysql para conectarse a la base de datos pasandole como parametro el usuario y la password

$ mysql -uproduccion -p4gSg4ws -hlocalhost mydatabase
mysql>

Tambien usan esta misma tecnica para generar los típicos respaldos usando mysqldump.

$ mysqldump -uproduccion -p4gSg4ws -hlocalhost mydatabase >>mydatabase.sql

Obviamente esto es un problema de seguridad, ya sea porque no se educó bien al usuario o simplemente porque no existen medidas de seguridad dentro del contexto donde se está ejecutando este tipo de comandos.

Tambien es muy usual encontrar a usuarios que intentan pasarle la password de root al comando “su”, ejecutando comandos tipo:

$ su - 354dr2

Pensando que 354dr2 es la password de root, al igual que

$ sudo su - password_del_usuario

Pensando que de esa forma no le pedirá el password. Lo que no sabe el usuario es que todo lo que ejecuta esta siendo logueado y que está comprometiendo la seguridad del servidor.

El .bash_history o historial de comandos bash, muestra mucho como trabajan los usuarios, qué hacen y de qué forma lo hacen, de esta forma es posible obtener información sobre algun sistema o servicio que esté corriendo en el servidor, por ejemplo si entramos a la mala a un servidor y queremos buscar información privada o información que nos interese, podemos ver el historial de los usuarios para saber qué hacen, por donde se mueven y seguir sus pasos.

Un dia me tocó ver que un usuario tenia un script “escondido” que se conectaba vía llave pública a 4 o 5 servidores (incluyendo uno fuera de la red), obviamente, la llave privada estaba en el servidor donde yo estabam por lo que pude acceder a todas sus cuentas en los otros servidores.

Compartir/Guardar

Tanto las empresas como los usuarios (clientes) no tienen las suficientes medidas de seguridad al utilizar uno de éstos servicios, muchas veces los usuarios no denuncian una anomalía, por lo que para las empresas es difícil dar solución a algo de lo que no tienen conocimiento. Por otro lado, las empresas, cuando un usuario les denuncia algun problema, no son capaces de dar solución.

Tarjetas de crédito

El proceso corecto para realizar una compra (tanto por parte del usuario como por parte del vendedor) es entregar al vendedor la tarjeta de crédito y el carnet de identidad, el vendedor imprime desde la maquinita una boleta o ticket, el comprador debe firmar y anotar su número de identidad, luego el vendedor debe verificar la validéz de éstos datos con el carnet de identidad. ¿Qué pasa generalmente? El vendedor entrega el carnet de identidad y la tarjeta de crédito antes de que el comprador firme el ticket, por lo que obviamente, el vendedor jamás podrá comparar si la firma y el número de identidad son correctos. Yo he hecho el ejercicio más de una véz, cuando me entregan el ticket simplemente firmo con un “yeah!” y escribo cualquier número de identidad muy distinto al mio, el vendedor lo único que hace es decir “gracias por la compra, hasta luego“. ¿Qué pasa actualmente? En las últimas 5 compras que he hecho, el vendedor no ha sido capáz de pedirme ni si quiera el carnet de identidad.

Con todo ésto, yo me siento vulnerable, siento que si se me pierden mis documentos o me los roban, podrán realizar compras sin ningún problema y claro, cuando yo vaya a reclamar al banco, ellos no me darán ninguna solución. Está de moda en los bancos ofrecer un “seguro anti fraude” que te “protege” de éste tipo de hechos, pero hay que pagar, es decir, hay que pagar por la seguridad que ellos deben ofrecernos.
Yo me he puesto a pensar en más de una oportunidad que perfectamente podría reclamar que jamás he hecho una compra, ya que no tendrían como comprobar que fui yo quien hizo la compra en ese local, ya que el vendedor jamás verificó si mis datos eran reales.
Actualmente, los bancos están implementando en famoso PinPass que, supuestamente, mejoraría la seguridad y ayudaría al usuario a realizar sus compras de una forma más tranquila. En éstas 5 últimas compras que he hecho, el vendedor me pregunta ¿Tiene su pinpass? y mi respuesta es “no” entonces él me dice “ok, entonces presione enter sin escribir nada“.
Yo intenté denunciar éste hecho con mi ejecutivo de cuentas pero no obtuve respuesta. Les dejo el email que le he enviado:

Hola,

En los ultimos 5 o 6 meses, cada vez que compro con mi tarjeta
mastercard, con o sin cuotas, no me piden ni mi carnet ni tampoco me
hacen firmar la boleta. Esto demuestra que el metodo de compra no tienen
ningun mecanismo de seguridad, mi problema nace cuando pienso que que
pasaria si me roban mis documentos incluyendo mi tarjeta de credito? La
persona podra comprar como si nada.

El dialogo entre yo y el vendedor es:

Vendedor: Como cancela?
Yo: Con mastercard
Vendedor: Ok … Deslicela por ahi
Yo: Ok.
Vendedor: Tiene PinPass?
Yo: No.
Vendedor: Ok, entonces presione ‘enter’.
Yo: Ok.
Vendedor: Muchas gracias por su compra, hasta luego!

Esto me tiene bastante molesto ya que de una u otra forma, me estoy
sintiendo presionado por el banco a contratar el “seguro de fraude” (o
algo asi), siento que si no lo contrato, como no me piden carnet ni
firma al comprar, no tendre derecho a reclamo si algo me llega a suceder.

Me gustaria saber que solucion me pueden dar para esta inquietud.

Saludos.

Intentaré escalar el problema a otra persona, hasta que me den alguna respuesta.

Artículo relacionado.

Cajeros automáticos

Hace unos días leí un artículo que hablaba sobre el Skimmer, se trata de un aparato que se sobrepone a la ranura donde se inserta la tarjeta y el usuario no se da cuenta y apenas inserta la tarjeta ésta es clonada.

Irónicamente, este “dispositivo” mejora la usabilidad del cajero, ya que en algunos casos les agrega una leyenda de ayuda de cómo insetar la tarjeta y tambien una leyenda en braile.

El dispositivo de la imágen fue creado con partes de un reproductor mp3. Algunos Skimmers son altamente sofisticados y son capaces de enviar sms cada véz que se inserta una tarjeta.
El artículo completo fue publicado en meneame y se pueden leer comentarios bastante interesantes al respecto. El artículo original lo puedes encontrar aquí.

Teléfonos públicos

En este punto solo quiero enlazar a un articulo que escribi hace un tiempo, contando una anéctoda cuando me sentí estafado por 3 “actores”: el personal del metro de santiago, telefónica y por una persona que abría los teléfonos y se llevaba el dinero.
El artículo se llama: Robo en los teléfonos públicos de telefónica.

Compartir/Guardar

Luego de haberles comentado lo que estábamos preparando junto a la gente del HacklabCL y luego de varias reuniones y discusiones, ya hemos puesto fecha a nuestra primera jornada oficial de difusión de la filosofía del software libre.
Se llevará acabo en Kernelhouse el día miércoles 20 de Enero a las 20:00 horas. Los temas a tratar son introducción a los conceptos y paradigmas del software libre, respeto hacia la voluntad del autor, libertad tras las licencias populares y un tema bastanta particular titulado “tangibles e intangibles”.

Compartir/Guardar

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.

Compartir/Guardar

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

Compartir/Guardar

Phishing es un término informático que denomina un tipo de delito encuadrado dentro del ámbito de las estafas cibernéticas, y que se comete mediante el uso de un tipo de ingeniería social caracterizado por intentar adquirir información confidencial de forma fraudulenta (como puede ser una contraseña o información detallada sobre tarjetas de crédito u otra información bancaria).

Como dice la definición, son técnicas que se aplican mediante ingeniería social y ésta es, por si misma, un arte.
Podemos detectar distintos tipos de phishing, desde uno muy simple como falsificar un sitio y lanzarlo al mundo para que la gente caiga o bien uno más complejo con objetivos determinados y con víctimas específicas. En el primer tipo, me gustaría hacer referencia a todos los conocidos ataques que se han hecho a bancos simplemente falsificando el sitio web y obteniendo información de gente al azar, por ejemplo el caso en que se vio envuelto Mastercard Argentina. Con el segundo tipo, quiero hacer referencia a casos más trascendentes que generalmente no son conocidos, ya que no afectan a mucha gente sino mas bien a una víctima específica. Para mi, el primer tipo es una mierda, sin embargo, me gustaría destacar los ataques del segúndo tipo. De ahora en adelante, los distinguiré según su tipo.

Primero, voy a entrar en detalles con el phishing de primer tipo. Cualquier persona con mínimos conocimientos en desarrollo puede copiar una página y conseguirse un dominio similar al original para hospedarla y lanzarla al mundo para ver quienes caen, generalmente con estos tipos de ataques no sabes quienes son las personas que caen en tu trampa, simplemente obtienes sus datos para fastidiarles, ingresas a sus cuentas y ver si tiene algo entretenido, no tiene ninguna ciencia. Este tipo de ataques no tienen ningún sentido, no se está aplicando ingeniería social ni mucho menos.
Existe una gran diferencia entre dirigir los ataques a una persona o víctima en particular versus el direccionarlo a quien caiga: la dificultad y la emoción.

El segúndo tipo es en el que quiero profundizar más. Cuando tenemos una víctima en la mira, es mucho más emocionando hacer éste tipo de ataques, ya que nos costará más y nuestro fín es único, no afectará a otras personas quienes no nos interesa. Para hacer ataques dirigidos, tenemos distintas técnicas, desde ataques locales hasta ataques remotos, podemos hacernos pasar por otra persona, engañando a nuestra víctima para que crea lo que nosotros queremos que crea y así obtener lo que queremos, hasta podemos manipularla. La víctima debe pensar que somos alguien de confianza, que se mueve dentro de su círculo de amigos o conocidos, sabemos mucho de ella y ella cree saber mucho de nosotros. Hacer que la víctima confíe en nosotros toma mucho tiempo, hace que haga lo que nosotros queremos más aún. Se puede lograr desde ataques sicológicos hasta con ataques netamente informáticos pero sin duda lo mejor es una combinación de ambos. Generalmente las víctimas de éste tipo de ataque son conocidos (nosotros lo conocemos, pero muchas veces él a nosotros no) a menos que sea por encargo.
La captura de datos o información se puede lograr falsificando websites, por teléfono, en persona, mediante algun tipo de mensajería instantanea, sniffeando la red, etc. Todo va a depender de nuestra imaginación, conocimiento y capacidades.

Cuando tenemos una víctima elegida, es muy entretenido el proceso en el cual hay que seducirla y mucho más aún, cuando la persona cae en nuestro juego y una véz obtenida la información es mucho más emocionante aún. Luego es el proceso de la verificación de información y posteriormente, una des-seducción de nuestra víctima, es decir, hacer que poco a poco se vaya alejando, pero sin perder el control de la situación y obviamente, sin pretender que nuestro objetivo se de cuenta de lo que planeamos hacer. Lo mejor es confundirlo.
No siempre se logra el objetivo, aveces porque nuestras técnicas han fallado y otras veces porque la persona que elegimos como víctima no es tan fácil de seducir. Hay que saber en qué momento abortar misión, porque los afectados podemos ser nosotros.

Existe un concepto errado de lo que es el phishing, al igual que muchas cosas, la popularidad de los términos terminan deformandose. Para mucha gente éste término es sinónimo de “robo de cuenta del banco y transferencias de dinero ilícitas“, que sería la definición peyorativa.
Detrás de muchos hackeos existen, implícita o explícitamente, técnicas de phishing aplicadas sobre las víctimas, y no podemos desperdiciar todo el proceso pensante y las capacidades del atacante para elaborar un ataque de ésta magnitud.

Compartir/Guardar

En Chile lanzaron un proyecto de ley para la protección de datos personales, luego de diversos hackeos ocurridos, donde se “publicó” información de millones de chilenos desde sistemas de información del servicio electoral y junaeb, entre otros. Lo que quieren hacer con éste proyecto de ley, es “aumentar las sanciones a quienes resulten responsables” y “entregarles las facultades a las distintas entidades afectadas para que puedan dar garantías“. Irónicamente, la ley sólo protegerá a quienes hagan mal su trabajo y no a los afectados, las entidades públicas que no sepan proteger la información privada de las personas, tendrán ahora una ayuda desde el gobierno para que nadie pueda hacer públicas sus fallas y, por ende, las personas afecetadas jamás sabrán que sus datos son públicos.

Una de las preguntas que me hago es ¿Si son privados los datos, entonces por qué son de acceso público?
Existen muchas entidades públicas y privadas que simplemente no protegen la información, formularios sin captchas, acceso a información mediante el RUT o con usuarios y password basadas en el rut. Para los que no saben, el RUT cumple con un patrón y generar millones y millones de RUT es tan fácil como sumar dos números.

En un principio, fue la ” base de datos” del Servicio Electoral (servel) la que fue publicada, sin embargo, era posible acceder a ella sólo con el RUT. Cualquier persona puede probar distintas combinaciones de números e ir recolectando información manualmente, una persona con conocimientos más avanzados podrá crear un script que automatice ésta tarea de tal forma que recopile la información más rápido.

< ?
function valida_rut($r)
{
        $r=strtoupper(ereg_replace('\.|,|-','',$r));
        $sub_rut=substr($r,0,strlen($r)-1);
        $sub_dv=substr($r,-1);
        $x=2;
        $s=0;
        for ( $i=strlen($sub_rut)-1;$i>=0;$i-- )
        {
                if ( $x >7 )
                {
                        $x=2;
                }
                $s += $sub_rut[$i]*$x;
                $x++;
        }
        $dv=11-($s%11);
        if ( $dv==10 )
                $dv='K';
        if ( $dv==11 )
                $dv='0';
        if ( $dv==$sub_dv )
                return true;
        else
                return false;
}
$rut = 10000000;
$i = 1;
$dv = 0;
for($i = $i; $i < = 11; $i++)
{
        if($i == 11) $dv = "k";
        else $dv = $i;
        for($rut = $rut; $rut <= 20000000; $rut++)
        {
                $full_rut = $rut."-".$dv;
                if(valida_rut($full_rut) )
                        print $full_rut."\n";
        }
}
?>

Con este script generamos RUTs consecutivos con su respectivo dígito verificador, es decir, números RUT válidos.

[...]
10004366-1
10004383-1
10004397-1
10004402-1
10004416-1
10004433-1
10004447-1
10004450-1
10004464-1
10004478-1
10004481-1
10004495-1
10004500-1
10004514-1
10004528-1
10004531-1
10004545-1
10004559-1
10004562-1
10004576-1
10004593-1
10004609-1
[...]

Otro hackeo conocido fue el que se le ha hecho a la Junaeb en distintas oportunidades, tambien tiene relación con este tema, ya que es información obtenida en base al rut de las personas. Existen muchas páginas dónde podemos encontrar información “personal” ingresando sólo éste nombre, por ejemplo el de la autopista vespucio norte, que con sólo tener el rut es posible obtener los partes, patente y cuanto vehículos tiene una persona. Pueden ver el artículo que escribió Ivan al respecto: Bug en sitio de empresa avn.cl, Avenida Vespucio Norte.

Yo me sigo preguntando, ¿Si mis datos “personales” son “privados”, entonces por qué mierda son accesibles para cualquier persona?

El proyecto de ley que se está gestando busca aumentar las sanciones a las personas que hagan pública la información que, con mucho esfuerzo, recopilamos, pero lo que yo busco es que las sanciones sean para las personas que NO cuidan esta información, por negligencia. Deberían crear estándares para el manejo de información personal y privada de las personas y la gente que esté a cargo de éstos estándares deben ser personas altamente capacitadas.

Hace unos meses escribí sobre cómo obtener información en NIC Chile, pudiendo crear una base de datos nombre-rut. NIC Chile se descartó y dijo que correspondía a una caracteristica y no a un error, ni si quiera fueron capaces de poner captcha al sistema de registro de dominios.

Compartir/Guardar

¿Y cómo termina todo esto?
Por ejemplo, con ésto.

Como dice mi querido amigo Clark en un comentario de un post anterior:

@Zerial, con respecto a este tema te encuentro toda la razon, sin tener mucho conociento en el tema hice algunas pruebas por una wifi con cifrado wep de una universidad X y chan! claro despues de un rato de acostumbramiento comence a adquirir user y pass de los funcionarios, pc’s, servidores y mas informacion, claro ahora estoy con la duda de dar a conocer sus problemas?, vuelvo a repetir no tengo muchos conocimientos en el tema pero hacerlo fue gratificante como dice @andres. ademas puedo decir que me encanto y me pico el bichito de la curiosidad lo que me lleva a documentarme mejor en el tema! y ahora se que alguien siempre esta escuchando del otro lado :s.

No hay que ser un experto, no hay que ser un jajajahacker ni un experto en seguridad informática, simplemente hay que tener las herramientas para hacerlo y ni si quiera saber ocupar las herramientas al 100%, actualmente con la información que hay en el manual de ettercap es posible lograr muchas cosas. Al igual que en una conversación telefónica, celular o lo que sea, siempre puede haber un tercero que esté filtrando la información, siempre puede existir un “hombre en el medio” (MiTM).
No se trata de un tema de paranoia ni nada por el estilo, pero creo que debemos tomar conciencia y tener conocimiento de donde nos estamos conectando, a traves de quien estamos pasando, etc.

En mi caso, cuando me conecto a unas de estas redes no dejo de hacer las cosas que hago siempre, pero me aseguro de que nadie esté “escuchando” lo que estoy haciendo. Si me aparece un certificado falso, obviamente no lo voy a aceptar (cosa que el común de la gente si lo hace), no voy a hacer transferencias ni ingresar a la cuenta de mi banco, y si trafico información importante me aseguro de que la información viaje por un canal seguro.

Tal véz deba existir algo que regule éste tipo de cosas.

Compartir/Guardar

El cronograma final del hackmeeting lo pueden encontrar en el siguiente enlace: http://hackmeeting.kernelhouse.org/wiki/doku.php?id=programacion

Las presentaciones de algunas charlas que se efectuaron:

• Buffer overflow for fun and profit (tty0)
• Behind the enemy lines (dererk)

Las fotos de la actividad las pueden encontrar en este link: http://fotos.kernelhouse.org

Compartir/Guardar

Durante el fin de semana pasado se realizó el Hackmeeting versión 2009, aunque un poco desordenado, fue todo un éxito. 3 días duró este encuentro que reunió a gente de Chile, Argentina y Bolivia, participando de charlas, debates y lo más importante, compartiendo sin una pantalla entre medio. Casualmente, coincidio con la fecha de termino de las Jornadas Regionales del Software Libre y tambien con la realización de Hackmeetings en otras partes del mundo como México y España.

Pronto publicaré las charlas, fotos y videos de este encuentro.

Compartir/Guardar

En ese momento, me comuniqué con los encargados e intercambiamos 4 o 5 correos. Les comuniqué que tanto su sitio como sitios de clientes tenian graves vulnerabilidades, les dije exactamente que tipo de vulnerabilidades tenian y la forma de corregirlas. Luego de esto, la gente de GoldenData me preguntó si le podía hacer auditoría a otros sitios que tienen ellos … y yo, nada de tonto, le dije que si, pero como era un servicio que ellos me estaban pidiendo les cobraría mis horas hombre, luego de este último correo… la gente no se contactó nunca más conmigo… pues claro, querían que les hiciera auditoria gratis. Ahora me entero que la gente cambió totalmente el sitio web de su empresa pero no ha corregido los sitios de sus clientes. Esta véz no me centraré en GoldenData.cl, hablaré sobre los desarrollos que hacen ellos, es decir, sus clientes:

• http://www.artpetit.cl/
• http://www.videocity.cl/
• http://www.arapemaquetas.cl/
• http://www.questor.cl/
• http://www.almendradec.cl/
• http://www.kelsopro.cl/
• http://www.zanartu.cl/
• http://www.riosycia.cl/
• http://www.beeone.cl/

Tampoco me desgastaré en algo que ya hice: Comunicarme con la empresa, ya que además de ser aprovechadores, no supieron dar la cara.

Antes de empezar hice un análisis rápido a todos los sitios para descartar los que no tengan vulnerabilidades a simple vista. Los sitios descartados son: beeone.cl, almendradec.cl, kelsopro.cl, zanartu.cl y questor.cl. Empezaré a analizar las restantes:

1- http://www.artpetit.cl/
Las URL sospechosas para realizar LFI, RFI y XSS son las siguientes:

1. http://artpetit.cl/productos.php?categoria=Miniaturas
2. http://artpetit.cl/?pag=contactenos
3. http://artpetit.cl/?pag=contactenos&codigo=009F2&nombre=Oso%20en%20Balanc%EDn

Si intentamos agregar un código como por ejemplo <script>alert(object)</script> o cambiar el valor de la variable pag por algun path interno o externo (rfi, lfi) nos mostrara un mensaje que nos dirá: Not Acceptable.

Por lo que, si bien parecen ser vulnerables, no lo son. Por otro lado, si transformamos la variable pag o categoria a un arreglo (pag[]) veremos que el nos imprime el valor del Array, lo que nos dice automáticamente que no está parseando los valores de entrada, el mensaje “Not Acceptable” es a nivel de servidor y no de aplicación. Este error no ses crítico y no compromete en absoluto la seguridad del sistema.

http://artpetit.cl/productos.php?categoria[]=asdf

2- http://www.videocity.cl/
Si navegamos por el menú podremos ver una url como http://www.videocity.cl/#vitrina.php?dpto=Audio, lo primero que se nos ocurrirá es cambiar el valor de la variable dpto pero veremos que no tiene ningún resultado, la página se sigue viendo exáctamente igual. El truco es el siguiente: Remover el símbolo “#” y dejar la URL de la siguiente forma:

http://www.videocity.cl/vitrina.php?dpto=<script>alert(this)</script> y veremos que nos va a mostrar el alert. Con esto demostramos que este sitio es vulnerable a XSS, pudiendo insertar un iframe para realizar phishing o usar el sitio para cualquier cosa que nos imaginemos.
Podemos intentar el mismo truco para otras url donde se almacenen los id o secciones. Este sitio tiene el mismo error que el anterior al transformar alguna variable a Array.

3- http://www.arapemaquetas.cl/
Si intentamos hacer XSS a las URL del menú nos encontraremos con el mismo error que en el primer caso: Not acceptable. Sin embargo, la técnica de transformar la variable en un array nos permitirá saber el path del sitio dentro del sistema. A esto se le llama Full Path Disclosure.
La URL es:

http://www.arapemaquetas.cl/maquetas.php?categoria[]=Arquitectura

Obtendremos un resultado como:

Warning: include(htmls/array.html) [function.include]: failed to open stream: No such file or directory in /home/arapemaq/public_html/maquetas.php on line 18

Warning: include(htmls/array.html) [function.include]: failed to open stream: No such file or directory in /home/arapemaq/public_html/maquetas.php on line 18

Warning: include() [function.include]: Failed opening ‘htmls/array.html’ for inclusion (include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /home/arapemaq/public_html/maquetas.php on line 18

4- http://www.riosycia.cl/
Este sitio es vulnerable a XSS mediante la siguiente URL:

http://www.riosycia.cl/productos_categorias.php?categoria=%3Cscript%3Ealert%28this%29%3C/script%3E

Si recorremos los distintos links del sitio podremos encontrar la ruta a un fichero llamado clave.php:

http://www.riosycia.cl/aplicaciones/clave.php

Si ingresamos un correo cualquiera nos dirá que no está en la base de datos, sin embargo, si ingresamos el comodín

‘ or ’1′=’1

Nos dirá que el correo fue enviado a esa dirección. Lo que nos comprueba que ese formulario es vulnerable a SQL Injnection.

Vulnerabilidades detectadas: Full Path Disclosure, SQL Injection, XSS.
Alcance de las vulnerabilidades: Uso del sitio para hacer phishing y, mediante SQLi tener una infinidad de opciones para realizar ataques, incluyendo un D-o-S.
Errores detectados: Parametros de entrada sin filtros.

Como conclusión podemos decir que estas personas no  dedican tiempo al tema de la seguridad ya que los sitios que no eran vulnerables es porque son sitios estáticos y feos y aquellos que al intentar violarlos aparecia el menasje de “Not Acceptable” es porque el servidor donde esa empresa tenia alojada el sitio web estaba protegido. Esto último explica el hecho de que los sitios hechos de la misma forma funcionen en un servidor y en otros no.

Por lo tanto, NO recomiendo esta empresa.

Compartir/Guardar

Fuente: Focus.com

Compartir/Guardar

Si bien todo esto podría ser usado indebidamente, no es el propósito. Antes de hacerlo público será necesario que generemos un disclaimer sobre los usos de la herramienta. Nosotros sólo estamos entregando una herramienta, el uso de ella va a depender de la ética de cada persona.

Lanzamiento …
Tenemos pensado lanzar al publico este proyecto en el Hackmeeting.

La herramienta …
La herramienta es super sencilla y consta de un pequeño formulario para reportar una vulnerabilidad.

Luego de esto, los distintos sitios web son almacenados en una base de datos y ordenados.

Compartir/Guardar