TTZ-WUE entdeckt neue Schwachstelle: Reflected Cross-Site Scripting (XSS) in BEO GmbH „BEO Atlas Einfuhr Ausfuhr“ 3.0

Reflected XSS in BEO Atlas Einfuhr-Ausfuhr 3.0 (Login: userid, password)
Entdecker: Lennard Kießling
CVE: CVE-2025-61427
Status: Patch veröffentlicht (Responsible Disclosure)

Kurzfassung

In der Login-Komponente von BEO GmbH — BEO Atlas Einfuhr – Ausfuhr 3.0 haben wir eine reflected Cross-Site Scripting (XSS)-Schwachstelle gefunden. Durch nicht ausreichend escaped/validierte Parameter (userid, password) kann ein Angreifer eine präparierte URL erzeugen, durch deren Öffnung im Browser eines Opfers beliebiges JavaScript ausgeführt wird.

Die Schwachstelle wurde gegenüber BEO GmbH gemeldet und von diesem bestätigt. Am 19. August 2025 wurde ein Patch veröffentlicht, der die Problematik behebt.

Betroffene Produkte / Versionen

• BEO Atlas Einfuhr – Ausfuhr 3.0 — Build/Release 20250328 (Stand: 08.05.2025).
  Betroffen sind die Versionen vor dem Patch vom 19. August 2025. Bitte bezieht euch auf die Release-Notes des Vendors für genaue Build-IDs.

Technische Beschreibung

Die Login-Seite reflektiert Benutzereingaben aus den Parametern userid und password, ohne diese kontextsensitiv zu escapen. Dadurch kann unter anderem schädlicher JavaScript Code in die Seite eingeschleust werden.

Angreifer-Szenario:

1. Ein Angreifer konstruiert eine URL zur Login-Seite mit einem präparierten Payload in userid oder password.
2. Das Opfer klickt den Link (z. B. in einer E-Mail oder Chatnachricht).
3. Der Browser des Opfers lädt die Seite; der Payload wird in der Response reflektiert und ausgeführt — z. B. zum Diebstahl von Session-Cookies, zur Manipulation der Seite oder zum Nachladen weiterer Payloads.

Wichtig: Zur Minimierung missbräuchlicher Nutzung enthält dieses Advisory keine einsatzbereiten Exploit-URLs oder aktiven Payload-URLs. Die Demonstration unten ist absichtlich abstrahiert und dient nur der Nachvollziehbarkeit.

Proof of Concept (abstrahiert)

Hinweis: Ich veröffentliche keine aktiven Exploit-URLs oder ausführbaren Payloads. Folgende vereinfachte Darstellung zeigt die Art der Schwachstelle, nicht ein fertiges Exploit:

1. Öffne die Login-URL der Anwendung (z. B. https://<host>/beo-software).
2. Hänge an die URL einen Query-Parameter userid oder password an, der HTML/JS-Inhalt enthält
   ?userid="><script>/*payload*/</script>&password=anything
3. Die Login Page reflektiert die URL Parameter und läd somit den Payload

Abbildung 1: Das Bild zeigt, die aktive Ausnutzung der XSS Schwachstelle beim Kunden. Aufgrund von anonymisierung wurde der Name des Kunden geschwärzt.

Wie haben wir die Schwachstelle gefunden?

1. Directory-Scan: Im Rahmen eines autorisierten Scans haben wir alle öffentlich erreichbaren Pfade der Anwendung aufgelistet.
2. Auswahl nach Design: Eine gefundene Seite wirkte aufgrund ihres Designs „alt“ und einer Eigenentwicklung, deswegen entschieden wir uns, diese gezielt zu pentesten.
3. Initiale Tests: In ersten Eingabetests überprüfte ich typische Felder auf unsauberes Escaping (wie SQL Injection, XSS, usw.). Als ich dann einen treffer beim XSS hatte, sah es zunächst so aus, als müssten die User selbst Werte in die Felder eingeben, damit dieses Schwachstelle ausnutzbar wäre.
4. Versuch Reflected XSS zu erreichen: Bei weiterem gezielten Testen nach reflected XSS entdeckte ich, dass die Anwendung Eingaben aus der URL direkt in die DOM reflektiert. Damit lässt sich die XSS-Payload über eine, wie im PoC gezeigt, präperierte URL einfügen. Hier entsteht ein viel leichterer Angriffsweg, weil er ohne direkte Interaktion mit dem Formular funktioniert (Opfer muss nur auf einen Link klicken).
5. Reporting: Nach dem Fund, setzen wir uns direkt mit unserem Kunden und dem Softwaredienstleister in Verbindung, der direkt einen Patch veröffentlichte und dem Kunden aufspielte.
6. Nachtrag: Im Nachhinein haben wir erfahren, dass die betroffene Login-Seite eigentlich nicht von extern erreichbar sein sollte. Gerade deshalb war der Directory-Scan entscheidend. Nur dadurch fiel die Fehlkonfiguration auf und die Seite konnte als potenzieller Angriffsvektor identifiziert werden.

Timeline (kompakt)

• Entdeckung: während autorisiertem Assessment (intern dokumentiert)
• Vendor informiert: unmittelbar nach Verifikation
• Patch veröffentlicht (Vendor): 19.08.2025
• CVE zugewiesen: CVE-2025-61427
• Öffentliche Beschreibung: dieser Eintrag (31.10.2025)

Fazit

Nur weil eine Anwendung eigentlich nur intern verfügbar sein soll, bedeutet das nicht, dass sie es auch immer ist. Durch besondere Umstände oder eine Fehlkonfiguration kann ein Endpunkt plötzlich von außen erreichbar werden.

Genau das war hier der Fall.

Der unerwartete Zugriff von außen hat letztlich dazu geführt, dass ich die Schwachstelle in der Anwendung von BEO identifizieren konnte.