Kürzlich habe ich bei einem manuellen Penetrationstest im Rahmen unserer SWAT-Lösung (SWAT ist die Penetrationstest-as-a-Service-Lösung von Outpost24) eine interessante Race-Condition-Sicherheitslücke in der E-Commerce-Software nopCommerce entdeckt. Diese Sicherheitslücke (CVE-2024-58248) betrifft nopCommerce, eine in C# geschriebene Open-Source-E-Commerce-Plattform, die Entwickler beim Aufbau von Online-Shops unterstützt.

Wenn sie ausgenutzt wird, ermöglicht sie es einem Angreifer, eine Geschenkkarte mithilfe einer Technik namens „Single-Packet-Attack” mehrfach einzulösen. Richtig durchgeführt, können Angreifer so Artikel kostenlos erhalten.

In diesen Blogartikel werde ich Ihnen zeigen, wie mein Team und ich diese spezifische CVE entdeckt haben, und Ihnen einen besseren Einblick in Race-Condition-Schwachstellen und Single-Packet-Attacken geben.

Wie CVE-2024-58248 ausgenutzt werden kann

Ein Angreifer kann in zwei verschiedenen Sitzungen dem Warenkorb Artikel hinzufügen und dann in jeder der beiden Sitzungen denselben Geschenkkarten-Code eingeben. Anschließend kann er den Zahlungsprozess in beiden Sitzungen fortsetzen, bis er die Seite mit der Schaltfläche „Bestätigen” erreicht. Hier kann der Angreifer einen Single-Packet-Angriff durchführen, wenn er die an /checkout/OpcConfirmOrder/ ausgehende Anfrage abfängt. Wenn beide Anfragen parallel verarbeitet werden, prüfen beide das Guthaben der Geschenkkarte, bevor es auf einen neuen Wert aktualisiert wird, was eine Race-Condition zur Folge hat. 

Zeitliche Abfolge der Ereignisse

• 07-08-2024: Entdeckung der Schwachstelle
• 08-08-2024: Erstkontakt mit dem Anbieter
• 21-08-2024: Bericht mit Details an Anbieter gesendet
• 29-08-2024: Schwachstelle vom Anbieter bestätigt
• Januar 2025: Kontakt mit MITRE (weltweit anerkannte Wissensdatenbank für Angriffstechniken und -taktiken)
• April 2025: Zuweisung einer CVE-Nummer seitens MITRE

Es gilt zu beachten, dass der Anbieter mitgeteilt hat, dass er die Sicherheitslücke im Dezember 2024 behoben hat. Als der Patch veröffentlicht wurde, haben wir ihn im Rahmen des verantwortungsvollen Meldeprozesses analysiert. Wir haben festgestellt, dass die Sicherheitslücke mit einer geringfügigen Änderung des Reproduktionsablaufs weiterhin besteht, und haben den Anbieter gemäß unserer Richtlinie zur verantwortungsvollen Offenlegung über unsere Ergebnisse informiert. Darüber hinaus haben wir beschlossen, die Details in diesem Blog zu veröffentlichen, um das Bewusstsein für dieses Problem zu schärfen.

Was sind Race-Condition-Schwachstellen?

Eine Race Condition tritt auf, wenn zwei oder mehr Threads, Prozesse oder externe Akteure gleichzeitig auf dieselbe gemeinsam genutzte Ressource (Speicher, Datei, Hardwaregerät usw.) zugreifen und diese manipulieren und das Endergebnis von der genauen Abfolge ihrer Operationen abhängt. Da diese Abfolge nicht deterministisch ist, kann es zu unerwartetem (oder sogar völlig falschem) Verhalten kommen.

Bei einer Race Condition geht es im Wesentlichen um Timing und Parallelität. Wenn mehrere Akteure ohne Koordination mit demselben veränderbaren Zustand interagieren, können sich ihre Aktionen auf unvorhersehbare Weise überschneiden, was zu Logikfehlern, Inkonsistenzen, Abstürzen oder sogar Sicherheitslücken führen kann. Eine ordnungsgemäße Synchronisation (oder besser noch, Designs, die gemeinsam genutzte veränderbare Zustände gänzlich vermeiden) sind der Schlüssel zur Vermeidung solcher Probleme.

So funktionieren Race Conditions

Ein Beispiel für eine Race Condition im Kontext einer Webanwendung wäre eine Verlosung, an der ein Benutzer nur einmal teilnehmen kann. Die Anwendung verfolgt mit der Variablen has_participated, ob ein Benutzer bereits teilgenommen hat. Diese Variable ist standardmäßig auf „false” gesetzt und wird auf „true” gesetzt, wenn ein Benutzer an der Verlosung teilnimmt. Wenn ein Benutzer an der Verlosung teilnimmt, führt die Anwendung möglicherweise Folgendes aus:

1. Sie überprüft die Variable „has_participated“, um festzustellen, ob der Benutzer bereits teilgenommen hat.
2. Sie nimmt den Benutzer in den Pool für die Verlosung auf.
3. Sie setzt die Variable „has_participated“ auf „true“.

Wenn keine Synchronisations- oder Sperrmechanismen vorhanden sind, entsteht eine Race Condition, wenn zwei oder mehr Anfragen desselben Benutzers parallel verarbeitet werden. Die Anfragen „konkurrieren“ miteinander, um die Überprüfung in Schritt 1 zu bestehen, bevor die Variable in Schritt 3 aktualisiert wird, sodass ein Benutzer mehrmals an der Verlosung teilnehmen kann.

Warum sind Race-Conditions schwer aufzuspüren?

• Nicht deterministisch: Sie treten oft nur unter bestimmten Bedingungen bei Timings oder unter Last auf, sodass Tests mitunter 999 Male erfolgreich sind, dann jedoch unvorhergesehen beim 1000. Mal scheitern.
• Nichtreproduzierbare Programmfehler, alias „Heisenbugs“: Das Hinzufügen eines Logging-Mechanismus oder die Verwendung eines Debuggers allein kann das Timing des Programms genug verändern, um den Fehler zu verbergen.
• Maßstab: In verteilten Systemen führen Netzwerkverzögerung und Taktabweichung von Uhren zu zusätzlichem nicht deterministischem Verhalten.

Was ist ein Single-Packet-Angriff?

Der Single-Packet-Angriff ist eine Technik, die von PortSwiggers James Kettle entwickelt wurde. Hierbei wird es zwei oder mehr Anfragen erlaubt, am Server einzutreffen und nahezu simultan verarbeitet zu werden. Dazu wird jede Anfrage nur zum Teil verschickt, die letzten Bytes jeder Anfrage werden jedoch zurückgehalten. Dann werden die letzten Bytes jeder Anfrage in einem einzigen (single) TCP-Paket gesendet, daher der Name. Das heißt, dass der Server erst dann mit der Verarbeitung der Anfragen beginnen wird, wenn er das Paket mit den finalen Bytes erhalten hat. So wird der Server gezwungen die Anfrage parallel zu verarbeiten.  

Mit dieser Technik wird zeitliches Jitter im Netzwerk (Netzwerk-Jitter) und andere externe Faktoren minimiert, sodass Anfragen fast gleichzeitig eintreffen können. Dies eröffnet Möglichkeiten für Timing-Angriffe und Race Conditions, die bisher als nicht realisierbar galten. 

Gehen Sie mit SWAT von Outpost24 auf Nummer sicher! 

Testen Sie Ihre Web-Applikationen auf die neuesten Schwachstellen mit PTaaS von Outpost24. Unser SWAT-Paket bietet eine kontinuierliche Überwachung Ihrer internetbasierten Webanwendungen über ein SaaS-Bereitstellungsmodell. Die Lösung kann vollständig an Ihre Anforderungen angepasst werden, wodurch unnötige Belastungen oder Risiken für sensible Umgebungen minimiert werden.

Die meisten Schwachstellen werden von unserem internen Testteam gefunden und von erfahrenen Penetrationstestern überprüft. Über das Portal können Sie auch direkt mit unseren Sicherheitsexperten in Kontakt treten, um Validierungen und Hinweise zur Behebung von Schwachstellen zu erhalten.

Buchen Sie noch heute Ihre Live-Demo.