El rincón de Zerial

En mi nuevo lugar de trabajo, misteriosamente está bloqueado por el firewall, entre otras cosas, la salida al puerto 25 de cualquier servidor. Desde mi portatil uso el cliente de correo Thunderbird conectandose a distintas cuentas  de correo que tengo alojadas en Google Apps asi que no podía quedarme sin revisar mis cuentas de correo, por lo que tuve que buscar la forma de hacerlo.
Lo primero que se me vino a la cabeza es hacer un port forwarding con ssh usando un servidor externo, sabiendo que tengo el puerto 22 desbloqueado para salir. Entonces, accedería a cualquier servicio corriendo en el puerto 25 mediante un redireccionamiento a traves del puerto 22. Con esta técnica podemos saltarons el firewall y todas las restricciones.

[Leer Más →]

Para complementar un poco lo que publicó d3m4s1@d0v1v0 en ITFreekZone sobre el Reflected XSS mediante SQL Injection, me gustaría demostrarles otra manera de realizar Cross-Site Scripting aprovechandose de una vulnerabilidad de inyección SQL.
La teoría es muy sencilla, basta con que encontremos un sitio vulnerable a inyección SQL, no importa que tenga protecciónes contra comillas simples o dobles, o similar, basta con que podamos generar un error por lado del servidor por ejemplo cambiando un número (id) por una letra (en el caso de oracle, sql server u otros que tengan problemas de compatibilidad por el tipo de dato pasado), agregas signos raros o una comilla obligando a que el servidor arroje un error de sintáxis, lo que vamos a hacer es insertar código javascript justo donde se genera el error sql.

[Leer Más →]

Los ataques XSS son cada día más frecuentes, pareciera ser que al desarrollador no le interesa o por desconocimiento no sabe a lo que se está exponiendo, pero por otro lado, los desarrolladores de los navegadores si están concientes y desarrollan técnicas anti XSS. La forma más común de realizar un ataque XSS es insertando tags cómo parámetor de URL o bien dentro de un campo del formulario, como por ejemplo el conocido:

<script>alert(‘this.cookie’)</script>

Cuando los ataques XSS mediante tags no son posibles, existe la posibilidad de realizar el ataque usando las propiedades de cada tag. Puede ser usando el atributo style, src o algúnos gatilladores de eventos como onMouseOver, etc. Para poder realizar el ataque es necesario usar comillas (simples o dobles), aunque tambien en algunos casos existe la posibilidad de no usarlas, para poder agregar una nueva propiedad al tag en el cual hemos conseguido insertar el código.

[Leer Más →]

La idea de este post es crear una lista de sitios que no se preocupan por la protección de datos, ya sea de la misma empresa o bien de personas (clientes o empleados). Si bien estos errores son cometidos por el desarrollador o programador de la plataforma, los que se deben preocupar de que el sitio quede bien hecho y que no tenga éste tipo de fallos, son los encargados de contratar a éste programador.

Los errores más estúpidos comunes son validaciones mal hechas para ingresar a intranets, ficheros de respaldos visibles publicamente, directorios con información confidencial no protegidos, etc. Yo, como programador, se como funcionan estas cosas, los clientes quieren muchas cosas por muy poco dinero y, por ésto mismo, el programador decide optar por el camino más rápido posible. Por otro lado, sabemos que a los clientes no les importa mucho la seguridad y que cuando le dices que cobrarás un poco más por el hecho de agregarle seguridad al sitio o al sistema, ellos no lo entienden y prefieren el camino más barato. En fín, mientras no se invierta en seguridad, seguirán sucediendo cosas como las que les mostraré a continuación.

[Leer Más →]

Si hablamos de un Instituto Profesional y Centro de Informática e Ingeniería de Sistemas en Administración, nos imaginamos un lugar para estudiar y aprender temas relacionados con informática, redes, etc.
Como se describen ellos mismos:

El IP CIISA es una entidad de educación superior que tiene la misión de formar profesionales y técnicos de nivel superior en las áreas del conocimiento vinculadas a las tecnologías de la información y las redes y comunicación de datos.

Sin embargo, si ingresamos al sitio web y nos vamos a “ExAlumnos” podemos ver como ellos mismos nos indican, publicamente, la clave de acceso para cada usuario.

Dice claramente: “4 primeros dígitos del rut + año de nacimiento“.

Me recuerda mucho a una entrada que vi en SecurityByDefault hace un par de meses atrás, donde ponían un código de seguridad sobre el teclado numérico para escribir el mismo.

Con seguridad cotidiana me refiero a la seguridad de lo que vivímos en el día a día, cuando usamos un teléfono público, cuando vamos a un cajero automático a sacar dinero o bien cuando hacemos una compra con tarjeta de crédito.
Yo he sido víctima de la falta de seguridad en éstos 3 casos, si bien nunca me han robado dinero ni clonado mi tarjeta, si me he sentido inseguro utilizando alguno de los servicios. No hablaré solamente del fallo de seguridad de las empresas, tambien de la poca seguridad que tienen los mismos usuarios

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.

[Leer Más →]

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”.