Etiquetainseguridad

Servicio de Impuestos Internos (SII) expone las contraseñas de los usuarios

El sistema en línea del Servicio de Impuestos Internos estuvo bajo mantención durante la noche redireccionando a todos los usuarios a https://www.sii.cl/pagina/actualizada/suspension/hpi_suspension.htm. El problema es que el mensaje no se desplegaba al momento de ingresar al sitio, sino que luego de iniciar la sesión o más bien, luego de enviar el formulario de inicio de sesión o de intentar ingresar mediante certificado.

Seguir leyendo

Bancos en Chile: La precaria seguridad de la banca en linea

Es comun que la mayoría los bancos tengan una sección en su sitio web dedicado a la seguridad donde todos llegan a la misma conclusion: los fraudes eletronicos se producen por culpa del usuario y nunca por culpa del banco, ya que usan certificado SSL en sus sitios web. Dando cientos de consejos para no caer en el juego de los correos electrónicos fraudulentos (phishing), diciendo que ellos jamas te llamaran para pedirte información y otras cosas por el estilo.
Por un lado los bancos nos dicen que jamás enviarán correos pidiendo datos personales ni mucho menos las claves de coordenadas, tambien nos “enseñan” a reconocer una URL falsa…

Y por otro lado el mismo banco es quien nos entrega las herramientas para poder suplantar su identidad, aunque usen cifrado SSL de un millon de bits, mediante las conocidas vulnerabilidades Cross-Site Scripting. Si bien en este mismo blog he publicado varias vulnerabilidades de este tipo que afectan a los bancos, lo que busco dar a conocer en este artículo es exponer la poca seguridad que nos entregan los bancos a nosotros sus clientes.

Seguir leyendo

Acceso al codigo fuente del Banco Santander Chile

Ya he publicado algunas vulnerabilidad que afectan a los clientes del Santander, esta vez escribiré sobre una vulnerabilidad que afecta directamente al Banco y que permite al atacante obtener el codigo fuente de la banca. El atacante puede navegar por los directorios en busca de los archivos “asp” y descargar el archivo, teniendo acceso al codigo fuente del sistema.

Se trata de una vulnerabilidad Local File Include + Directory Traversal = Source Code Disclosure, solo debemos modificar el valor de una variable de la URL para obtener el archivo que necesitemos. Se trata de un fallo basico e irresponsable que ningun alto estandar de seguridad permite.

Lo curioso es que segun el aviso de seguridad oficial del banco santander, hay una empresa “lider” en seguridad informática que les hace auditoría periodica:

Cierto, parece un chiste.
Seguir leyendo

Servipag: Nuevamente vulnerable a Cross-Site Scripting

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.

Seguir leyendo

Servipag: Continua siendo un portal de pagos inseguro

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.

Seguir leyendo

Vulnerabilidades en Cooperativa.cl: Saltándose los filtros.

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…

Seguir leyendo