skip to Main Content

it.sec Security Team findet unbekannte Schwachstellen im Oracle Communications Enterprise Session Border Controller (Oracle E-SBC)

Im Zuge eines Kundenprojekts konnte das Research Team der it.sec GmbH, zwei bisher unbekannte Schwachstellen im Oracle Communications Enterprise Session Border Controller (Oracle E-SBC) identifizieren und auszunutzen. Bei den Schwachstellen handelte es sich um ein Denial of Servcice (DoS) und eine unmaskierte Anzeige von Klartext-Passwörtern.

Was ist der Oracle E-SBC

Der Oracle Enterprise Session Border Controller (E-SBC) verbindet Kommunikationsnetzwerke auf IP-Basis. Des Weiteren wird ein Augenmerk auf die Interoperabilität gelegt, um eine zuverlässige Kommunikation zu erreichen. Der E-SBC dient zur Absicherung gegen Sicherheitsbedrohungen und Kontrolle von Echtzeit-Telefonie, Video und genereller Unified Communications beim Übergang in andere IP-Netze

DoS Schwachstelle – Die betroffene Funktion

Während des Penetrationstest des Oracle E-SBC wurde eine administrative Funktion zum Setzen eines Login-Banners für das Webinterface identifiziert. Dieses Banner wurde nach Aktivierung beim Loginprozess allen Nutzern angezeigt, welche korrekte Logindaten eingegeben hatten. Das Login-Banner wurde in einer HTML-Textarea dargestellt. Nachfolgend wurden die Benutzer zum Dashboard weitergeleitet.

Der Fehler

Beim Bearbeiten des Login-Banners über das Webinterface wurden alle getesteten Zeichen korrekt encodiert, bzw. entfernt. Das Login-Banner konnte jedoch genutzt werden, um potenziell schädliche Zeichen einzuschleusen, indem die HTTP-Anfragen direkt an den Server gesendet wurden. Somit konnte der clientseitige Schutzmechanismus umgangen werden.

Die Zeichenfolge \< wurde erfolgreich und ohne Encodierung in den Login-Banner übernommen. Jedes Mal, wenn ein Benutzer sich mit korrekten Zugangsdaten am System anzumelden versuchte, wurden diese Zeichen via Login-Banner an den Nutzer gesendet. Nachdem diese Antwort des Servers an den Client gesendet wurde, stoppte die Applikation, bzw. führte keine Weiterleitung zu dem Dashboard durch. Ein Aktualisieren der Seite führte zu einem leeren Login Formular.

Unterschiedliches Browserverhalten

Wurde die Seite mit Google Chrome aufgerufen, gab es keine Möglichkeit das DoS zu umgehen. Es war keinem Benutzer möglich sich an der Applikation anzumelden. Wurde jedoch der Mozilla Firefox verwendet und die Seite kurz nach Eingabe der Zugangsdaten aktualisiert, konnte ein erfolgreicher Login durchgeführt werden. Ist die Seite zu spät aktualisiert worden, wurde der Nutzer gleich wie im Google Chrome Browser nicht eingeloggt, sondern wieder auf die leere Login-Seite weitergeleitet

Fazit – DoS

Je nach Verfügbarkeit verschiedener Browser, bzw. Änderungen im aktuellen Mozilla Firefox kann das Webinterface komplett unbenutzbar gemacht werden. Sollte es keine alternative Möglichkeit geben das Login-Banner zu setzen, z. B. via SSH, ergibt sich ein potenziell hoher Schaden. Für den Angriff wird jedoch ein administrativer Benutzer benötigt, was die Ausnutzbarkeit deutlich erschwert.

Generell zeigt diese Schwachstelle, dass eine strikte Eingabevalidierung und Encodierung aller Zeichen auch serverseitig erfolgen muss, um Angriffe zu verhindern.

Unmaskierte Klartextpasswörter

Der Oracle Enterprise Session Border Controller (E-SBC) erlaubte das Setzen von verschiedenen Boot-Parametern, wobei auch ein FTP-Dienst genutzt werden konnte, um das Boot-Image zu laden. Des Weiteren konnte ein FTP-Dienst genutzt werden, um ein Softwareupgrade durchzuführen.

In beiden Fällen waren Username und Passwort im Klartext im Webinterface abrufbar.

Die Zugangsdaten zu den Systemen wurden beim Aufruf der entsprechenden Seiten sofort angezeigt, ohne, dass eine separate Demaskierungsfunktion oder ähnliches aufgerufen werden musste. Da nicht nur aktuell eingegebene Passwörter, sondern auch gespeicherte angezeigt wurden, mussten diese in einem zurückrechenbaren Format vorliegen.

Dies bedeutet, dass Passwörter vermutlich auch im Backend der Applikation im Klartext vorlagen.

Fazit – Unmaskierte Klartextpasswörter

Werden Passwörter im Klartext verschlüsselt oder codiert im Backend gespeichert, kann ein Angreifer mit Zugriff auf die Daten, diese potenziell auslesen und für den Angriff auf diese Systeme verwenden.

Passwörter sollten nur in Form eines kryptographisch starken Hashes in einer Datenbank gespeichert werden. Zusätzlich sollte jedes Passwort mit einem Salt gehasht werden, um Angriffe zu erschweren.

Aktueller Stand und weitere Informationen

Die Schwachstellen CVE-2021-2416 und CVE-2021-2414 wurden bereits behoben und ein Security Patch steht bereit. Wir raten allen Oracle E-SBC Betreibern Sicherheitsupdates stets zeitnah zu installieren, um bekannte Schwachstellen zu beheben. Weitere Informationen zu den Schwachstellen können aus dem Oracle Critical Patch Update Advisory für Oktober 2021 entnommen werden.

Ihr it.sec Research Team

Back To Top