El sitio web del Banco Central de Chile es vulnerable a ataques Cross-Site Scripting y, posiblemente, un SQL Injection. Son muchos los sitios de bancos que son vulnerables a este tipo de ataques, pero muy pocos quienes solucionan los errores luego de reportarlos, es por eso que se toma la decisión de hacer un disclosure sobre las vulnerabilidades para denunciar este tipo de hechos.
El sitio web del Banco Central pareciera no tener ningun tipo de validación de los parametros de entrada que se pasan mediante formularios o mediante URL, exponiendo a los usuarios y al servidor a distintos tipos de ataques.
El XSS que encontré, está en el archvo rim/default.asp en el subdominio si2.bcentral.cl.
Como prueba de concepto, incrustaré un ‘iframe’ con el sitio web de Google dentro del sitio del Banco Central
Perfectamente, el atacante podría incrustar un sitio malicioso con la intención de robar la identidad del banco y aprovecharse de la confianza que el usuario tiene sobre el sitio web, incluso usando el sitio “seguro“.
Tambien el atacante podria, mediante esta vulnerabilidad, modificar el formulario de inicio de sesión que aparece en la imagen, para robar los datos de los usuarios y enviar la información a terceros.
[Leer Más →]
Etiquetas: Hacking · Interes general · Seguridad · Sitios Vulnerables
Los captchas (Completely Automated Public Turing test to tell Computers and Humans Apart) son mecanismos de detección de robots o procesos automatizados que se conectan a nuestros sistemas y nos permite diferenciar entre humanos y maquinas. Muchas veces los captchas previenen registros masivos, bots que se dedican a recolectar información o bien intentos de ataques (por ejemplo fuerza bruta).
En el caso de Facebook, el captcha está de adorno. Manualmente, un usuario puede hacer uso de google para buscar personas y llegar a su página de Facebook, por ejemplo, buscamos a “Juan Perez” y llegamos a su perfil http://www.facebook.com/juan.perez, Facebook nos mostrará un captcha para poder ver si perfil
Si ingresamos las palabras que nos aparecen (iedshm, and) podremos ver un poco más sobre el usuario como su foto
Una persona debería poder ver este tipo de información si ingresa a facebook e ingresa el captcha correspondiente, para evitar que programas automatizados o bots se dediquen a recolectar información de los usuarios, pero la verdad es otra. El captcha de Facebook está de adorno.
[Leer Más →]
Etiquetas: Hacking · Interes general · Privacidad · Sitios Vulnerables
Con el fin de mejorar la interacción del usuario con algun sistema, los diseñadores y desarrolladores adoptan distintas técnicas de usabilidad para hacerle el trabajo más fácil al usuario, el problema es cuando se prioriza la usabilidad por sobre la seguridad. Para muchos podría parecer que la gente que desarrolla los sistemas piensan que los usuarios son unos tontos unos niños ingenuos, y que por no hacerlos pensar “donde hacer click” le dan todo en bandeja pasando por alto las normas de seguridad. Es por esto que escribiré sobre como la usabilidad pasa por encima de la seguridad.
Como ejemplo, tomaré el caso del Banco Santander y analizaré como una función para hacerle el trabajo más fácil al usuario puede atentar contra la seguridad del mismo usuario. Para muchos podría ser algo básico, pero si lo ven como si fueran un usuario “normal“, se darán cuenta que realmente es un riesgo y que al usuario le podría pasar perfectamente.
Esta es la pantalla de inicio de sesión que vemos al ingresar a www.santander.cl.
[Leer Más →]
Etiquetas: Interes general · Privacidad · Seguridad
Me refiero a discos virtuales a los que creamos usando dd. Cuando creamos un disco utilizando por ejemplo dd if=/dev/zero of=imagen.img y lo usamos para crear una máquina virtual, en este caso con Xen, luego le instalamos un sistema operativo que maneje ya sea CentOS, RHEL, Debian o cualquier otro que maneje LVM en la instalación, hay veces que necesitamos manipularlo ya sea para clonarlo, hacerle mantención o simplemente montarlo para ver los archivos. En mi caso, tuve que clonar la máquina virtual en caliente y quedó el FS corrupto, por lo que tuve que corregirlo, tambien sirve para hacer tareas de mantención como aumentar o disminuir el tamaño del disco o volúmenes lógicos.
Tengo mi disco original llamado “vm1.img” y la clono simplemente con un cp o bien con “dd if=vm1.img vm1_clon.img“, paso a paso, lo que tenemos que hacer es:
- Crear un dispositivo “loop” en base a nuestro disco virtual
- Mapear el dispositivo loop creado
- Revisar los dispositivos creados en /dev/mapper/
- Activar el volúmen y realizar las tareas necesarias
Las herramientas que usé son losetup, kpartx y vgchange.
[Leer Más →]
Etiquetas: Documentacion · GNU/Linux · Tips
Así es, el portal chileno de pagos en línea más seguro nuevamente es vulnerable a XSS. Esta vez se trata de la página de registro de usuarios, modificando el valor de la variable “Rut” es posible inyectar código javascript y poner en riesgo al usuario.
El sitio web de Servipag se ha caracterizado ultimamente por tener una serie de vulnerabilidades criticas que afectan al servidor donde se encuentra el sitio web y tambien a los usuarios, poniendo en riesgo información sensible sobre sus clientes. Según una declaración de Servipag mediante su twitter, los “XSS visual” no afectan al usuario:
Como a ellos no les preocupan los XSS, publicaré con detalles la vulnerabilidad.
[Leer Más →]
Etiquetas: Hacking · Interes general · Seguridad · Sitios Vulnerables
Una forma de hacer un bypass a los sistemas de autenticación es poder acceder a archivos “sensibles” que sólo un usuario con autorización debería poder ver. Existen muchos sitios que tienen panel de administración pero no protegen los directorios donde se encuentran los archivos, por ejemplo, imaginemos que el usuario “admin” subió un archivo con datos de acceso a un servidor y en el sistema configuró que sólo algunos usuarios puedan verlo, sin embargo, cualquier persona que se sepa la URL puede acceder a el … Aunque suene bastante simple e incluso estúpido, es lamentable que existan sistemas o sitios web que lo permiten.
Por lo general, esto sucede cuando no existe una capa intermedia entre el archivo y el sistema, sino que se linkea directamente. Algo que debería ser http://www.dominio.cl/sistema/index.php/descargar/949394 es http://www.dominio.cl/sistema/admin/archivos/usuarios_y_passwords.docx, y en el peor de los casos hasta se puede eliminar el nombre del archivo y listar el contenido del directorio “archivos” 
Los sistemas web deberían manejar internamente un “id” o nombre ficticio del archivo, hasheado y mapeado al momento de subirlo, para no permitir que cualquier usuario pueda acceder. Por ejemplo, si tenemos la URL de prueba dada anteriormente, 949394 correspondería al ID del archivo, el sistema debería -internamente- hacer una consulta a la base de datos y ver a que archivo corresponde ese ID, luego ver quienes tienen permisos para acceder a ese archivo y, luego de verificar la sesión y permisos, permitir la descarga del archivo.
Para evitar la descarga directa de los archivos, el directorio “uploads” debería estar fuera del directorio de la aplicación, por ejempo, si el directorio de la aplicación es /var/www/html/sistema1/, el directorio debería estar fuera de “sistema1″, sino, aunque hagas todas las validaciones posibles, de todas formas se podrá acceder directamente al archivo saltandose la validación de la aplicación.
Etiquetas: Hacking · Interes general · Programación · Seguridad
Pasa el tiempo y, luego de haber reportado las vulnerabilidades que afectaban a Servipag, siguen apareciendo nuevas vulnerabilidades que afectan al portal de pagos. Esta vez se trata de 2 nuevas vulnerabilidades, una reportada en Secureless, que atenta contra la privacidad de los usuarios, permitiendo que cualquier persona pueda acceder a los comprobantes de pago de cada cliente, simplemente moficiando una variable en la URL, la segunda se trata de un XSS en el mismo sitio del comprobante de pago.
Servipag continua diciendo que sus politicas y tecnologías de seguridad son en base a altos estandares nacionales e internacionales y segun ellos, las vulnerabilidades que existen no ponen en riesgo la informacion de los usuarios, ya que todo el proceso de compra/pago y transaccion no se hacen directamente en los servidores de ellos … PERO, sorpresa, ellos guardan un comprobante de pago de forma local, pudiendo acceder a TODOS los comprobantes de pagos de quienes usen el servicio, sean o no usuarios registrados.
Que tipo de información podemos ver aqui?
1. Se refiere al “cliente” como “Usuario”, lo mas probable que no esté registrado en servipag, de lo contrario mostraría el nombre.
2. El banco mediante el cual se hace el pago.
3. Empresa o servicio que se paga.
4. Monto, fecha y ID del pago realizado.
Con esta información es posible relacionar a personas con un banco especifico y ademas con el consumo de un servicio, en una fecha especifica. Esta información podría ser útil para enviarle una trampa al usuario, un correo fake (phishing) con datos reales como su nombre, banco al que pertenece, servicios que consume, fechas en las que hace el pago … en fin, una serie de información que nadie tendría que saber.
[Leer Más →]
Etiquetas: Hacking · Interes general · Privacidad · Seguridad · Sitios Vulnerables
Ultimamente se han puesto de moda los ataques de “Anonymous”, ataques como tirar un sitio abajo o saturación de servidores, algo bastante simple que no requiere mucho conocimiento y es por esto que mucha gente se ha sumado. Algunos medios los han llamado ‘hackers‘ otros ‘simples aficionados que se descargan un programa, introducen una URL, se coordinan y presionan enter‘. Por suerte del gobierno se comparan con los ataques originales de Anonymous o LulzSec. Cuando digo “originales” me refiero a esos ataques que han salido a la luz donde divulgan información sobre las cuentas de usuario e información sensible y privada de las empresas, no a unos wannabe.
Según mi opinión, un ataque de denegación de servicio a sitios del gobierno no tiene ningun sentido y no hacen daño ni provocan preocupación, creo que los ataques deberian realizarse hacia “servicios” y no a “sitios”, donde se vean afectados los servicios que los ciudadanos usan y que el gobierno se sienta incapaz de brindarselos. Esto sucede porque no se hace un estudio sobre la víctima, para darle donde más le duele, se puede llamar “ataque organizado” porque se acuerdan una hora y todos presionan el botón ese dia a esa hora, pero no hay una real coordinación donde se investigue un objetivo donde realmente llame la atención, y mientras siga siendo así, seguiran siendo ataques simbólicos.
El gobierno chileno tiene muchas brechas de seguridad informática y de la información, es por esto que me hago la pregunta, ¿Está preparado el gobierno de Chile para recibir un ataque de robo de información?, la respuesta clara es: NO. No está preparado el gobierno, ni las personas, ni los encargados, no existen políticas (y si existen no se cumplen), encargan su seguridad a un simple firewall que solo les sirve para que sus empleados no puedan ingresar a ver youtube. Obviamente no puedo decir que “todas las entidades del gobierno tienen fallos de seguridad”, pero me refiero al gobierno en general.
Desde hace un tiempo que he estado investigando las distintas vulnerabilidades web en sitios del gobierno, intentando reportar la mayoría. En algunos casos no responden, en otros casos no hay forma de contactarlos pero en el mejor de los casos, recibo respuestas y unas satisfactorias gracias.
[Leer Más →]
Etiquetas: Hacking · Interes general · Privacidad · Seguridad
Ya vimos en el caso de Servipag unos filtros de protección anti LFI inútiles, ahora es el turno de uno de los sitios web de Cooperativa.cl, el cual implementa unos filtros de protección anti-XSS y anti-SQLi bastante vergonzosos y obviamente de “protección” no tiene nada.
El sitio afectado corresponde al subdominio “musica.cooperativa.cl” el cual es vulnerable a inyección de código sql y cross site scripting.
La vulnerabilidad se encuentra en el archivo disco.php mediante la variable id. Es posible generar un error facilmente ingresando una comilla simple (‘):
Hasta el momento el “filtro” escapa el la comilla y anteponiendo un backslash (\), intentamos hacer el típico SQL Injection para obtener información sobre la base de datos usando ‘+or 1=+ union+select+database(),user()+–+ y obtenemos como resultado “Error select * from disco where id=3342\’ 1= (),() –”
Efectivamente el “filtro” está eliminando las palabras que ponemos y dejando sólo los caracteres que no son letras. Ahora, si intentamos inyectar un tag html como por ejemplo <em>prueba</em>, obtenemos Error select * from disco where id=3342<></>
Bien, ahora nos saltaremos los filtros que nos han puesto…
[Leer Más →]
Etiquetas: Hacking · Seguridad · Sitios Vulnerables
