Descubren cómo comprar gratis pagando con PayPal, Amazon Payments o Google Checkout

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.
Fuente