Se han descubierto varios fallos en la lógica de la comunicación de las principales páginas web de tiendas con servicios de terceros destinados al pago on-line (tipo PayPal), que permitían obtener productos de forma gratuita o a un precio arbitrario.

Investigadores de la Universidad de Indiana (Rui Wang y XiaoFeng Wang) y Microsoft Research descubrieron fallos en la lógica de comunicación de las principales tiendas online que utilizaban servicios de pago de terceros como PayPal, Amazon Payments o Google Checkout (los llamados Cashier-as-a-Service o CaaS). Las técnicas empleadas aprovechaban múltiples inconsistencias introducidas por la complejidad resultante de utilizar medios de pago de terceros. Se basaban en cómo los estados del pago eran percibidos por parte del vendedor y el CaaS y cómo se genera cierta "confusión" al actuar como cajas negras entre ellos.

En un escenario típico para la adquisición del los productos pagando a través del CaaS, el cliente es redireccionado desde la página del vendedor a la del CaaS donde se da la orden de realizar el pago, para finalmente, ser redirigido de vuelta a la web del vendedor con objetivo de validar el pago y terminar el pedido. Este es el "punto débil" de la interactuación entre la tienda y el CaaS.

Los fallos descubiertos, con cierto detalle, son:

* NopComerce integrado junto con PayPal: Una vez que el cliente decide pagar, el vendedor le indica al comprador el identificador del pedido y la cantidad a pagar, procediendo a la inmediata redirección del navegador del comprador hacia la página del CaaS, que valida el ID del pedido... pero no así la cantidad que debe pagarse, pudiendo esta ser modificada antes de ser redirigido a la página donde se realiza el pago.

* Amazon: En este caso es necesario poseer una cuenta de vendedor en Amazon, lo que está al alcance de cualquiera. Un atacante podría realizar un pago a un vendedor (él mismo en este caso) y en el paso de confirmación del pedido, donde se redirige desde la web del CaaS hacia la página del vendedor, indicar la página del vendedor al que le queremos hacer creer que el pago ha sido realizado. Esto ocurre por no verificar que el pago haya sido realizado a la página donde finalmente termina confirmándose la compra.

* Inerspire junto con PayPal: Se aprovecha el fallo de que, que tras haber realizado el pago de cierto producto, es posible cambiar el orderID, que se encarga de identificar los productos que van a ser adquiridos.

* Google Checkout: La variable que identifica el pedido no es creada hasta que se ha realizado el pago; una vez hecho, se crea el pedido con el contenido del carrito. El problema en este caso radica en que esta última operación no es atómica (no se realiza en un solo "movimiento"), por lo que podría aprovecharse para añadir más productos al carrito justo antes de indicar el contenido del mismo.

* Amazon Simple Pay: El problema reside en su SDK, que permite al comprador indicar el certificado que será utilizado para verificar los mensajes del CaaS encargados de confirmar el pago del pedido. En este caso el atacante indicaría un certificado propio y él mismo generaría los mensajes firmados que indicarían que el pago ya ha sido realizado, por lo que ni siquiera se tendría que interactuar con el CaaS, implicando que no se realizaría en ningún momento ningún pago.

Los descubridores llegaron a comprar realmente productos sin pagar y comprobaron realmente la eficacia de las técnicas. Más tarde avisaron de los fallos a los afectados de forma privada, devolvieron los productos que habían adquirido, y trabajaron juntos para arreglarlos. Ya han sido subsanados.

Estos investigadores formaron parte del equipo que descubrió vulnerabilidades en Facebook que podían permitir a sitios maliciosos acceder y compartir datos privados de los usuarios.

Javier Rascón
 jrascon@hispasec.com

FUENTE :http://www.hispasec.com/unaaldia/4555