abraxas/opencart-reward-free-checkoutProof-of-concept exploit e lab per un bypass dei punti premio di OpenCart 4.1.0.4 insieme al pagamento Free Checkout, che consente a un cliente autenticato di mantenere i punti e pagare meno gli ordini.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · opencart-reward-free-checkout
OpenCart 4.1.0.4 - OpenCart Ltd
CVE-2025-15116 era una race sui coupon fino alla 4.1.0.3. Nella 4.1.0.4, coupon.save rimuove payment_method quando il coupon cambia. reward.save non lo fa. Applica abbastanza punti affinché getTotals sia <= 0.00, scegli Free Checkout, poi azzera i punti. La conferma riscrive la riga pendente al prezzo di catalogo. free_checkout.confirm controlla solo il codice di pagamento in sessione.
Un cliente autenticato con punti reward può spedire uno SKU di catalogo come Free Checkout e tenersi i punti.
| ID | nessuna CVE al momento |
| CWE | CWE-840, CWE-863 |
| CVSS | High: 6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N |
| Prodotto | OpenCart |
| Affetto | fino alla 4.1.0.4 reward + Free Checkout |
| Auth | cliente autenticato (il carrello guest non è questo bug) |
| Licenza | GNU Affero GPL v3.0 |
| Lab | solo 127.0.0.1 |
Effettua il login, metti nel carrello uno SKU coperto dai punti, applica abbastanza reward affinché Free Checkout venga elencato, salva quel metodo, poi reward.save con 0. La seconda conferma scrive il totale di catalogo. free_checkout.confirm promuove l'ordine a pagato. I punti non vengono mai addebitati.
Non ottengono una shell. Il checkout guest non è questo bug: reward richiede un cliente. Free Checkout viene solo elencato con total <= 0. Il bug è che azzerare i punti non lo rimuove dall'elenco, e la conferma non ricontrolla il totale.
Ho letto reward.save, poi coupon.save, poi getMethods (total <= 0.00), poi editOrder mentre lo stato è 0, poi free_checkout.confirm. Nella 4.1.0.4, reward=0 elimina session.reward. Non tocca payment_method. Il coupon, dopo l'hardening della 15116, sì.
Il primo client che guarda questo applicherà 100 punti, sceglierà Free Checkout, confermerà una volta e otterrà un onesto ordine a totale zero. Questa è la funzionalità, non il bug.
Vicoli ciechi già registrati: coupon.save invece di reward.save (quel percorso rimuove il metodo); checkout guest; prodotto con points=0 (Free Checkout non viene mai elencato); lasciare reward in sessione attraverso free_checkout.confirm (ordine gratuito onesto, i punti dovrebbero essere addebitati); guardare solo order_status_id=0 (pending non è pagato). L'oracolo è status 1, total 100.00, payment free_checkout, debit 0.
Lab: login cliente. Aggiungi al carrello 36 (iPod Nano, points=100). reward.save 100. I metodi di pagamento elencano Free Checkout. Salvalo. La conferma scrive l'ordine 3 a 0. reward.save 0. La conferma riscrive l'ordine 4 a 100.00. free_checkout.confirm. Il seed elimina tasse e spedizione così reward può azzerare getTotals esattamente. Questo non è il bug. Uno SKU di catalogo i cui punti coprono la riga è il caso realistico. Il cliente ha ancora i 1000.
cd lab
./run.sh
Target solo http://127.0.0.1:18108. Metti prima OpenCart 4.1.0.4 upload/ in lab/www. Quell'albero non è in questo repo.
SUCCESS OpenCart reward + Free Checkout underpay
IOC order-after-reward 3 total=0.0000 status=0 free_checkout.free_checkout
IOC order-after-clear 4 total=100.0000 status=0 free_checkout.free_checkout
IOC free_checkout.confirm redirect checkout/success
IOC order-final 4 total=100.0000 status=1 debit=0 balance=1000
unset di payment_method in reward.save come già fa coupon.save, e far rifiutare a free_checkout.confirm i casi con total > 0.
reward.php · coupon.php · free_checkout.php controller · free_checkout.php model · confirm.phpGNU Affero GPL v3.0. Vedi LICENSE. Solo lab su loopback. Nessuna garanzia.