Trojaner in 3CX - Sicherheitsaudit für Pascom wünschenswert

Support
, ,
#1

Nachdem ich bereits vor über einem halben Jahr Schwachstellen gegenüber XSRF/CSRF, fehlender Session-Sicherheit sowie Content-Security-Policy und dem Fehlen eines zweiten Faktors bei Pascom gemeldet hatte und seitdem nichts in dem Bereich passiert ist und ich den Quellcode der Anwendungen Client und Server nicht kenne, würde ich mir wünsche, dass Pascom hier einen Schritt weiter geht und sich extern auditieren lässt und das Ergebnis veröffentlicht, um ein maximales Level an Vertrauen zu schaffen, das in dem Bereich internetfähiger Software absolut notwendig ist.

Derzeit kann in Pascom alleine durch den Aufruf einer Webseite Formulare in Richtung Pascom abgesendet werden und somit Daten manipuliert werden und dies ohne, dass der Angreifer Zugangsdaten kennen muss und der Betroffene es überhaupt mitbekommt. Zudem können Browser-Erweiterungen Sitzungen übernehmen, da diese nicht vor Client-Zugriff geschützt sind.

Auf Einzelheiten funktionierender Angriffe gehe ich hier nicht ein, da ich weiterhin hoffe, dass Pascom diese Lücken demnächst schließt und sich anschließend prüfen lässt. Da kommt man meiner Meinung nach insbesondere in der EU nicht mehr dran vorbei.

1 Like
#2

Hallo @hazington

selbstverständlich unterziehen wir uns dauerhaft (jeden Monat) externen Security Audits. Die hiermit beauftrage Firma ist https://www.enablesecurity.com/.

Auch Deine Bedenken haben wir damals zum Audit gegeben und bewertet. Wie Du selbst sagst: Du kennst weder den Quellcode noch die Infrastruktur und daher die möglichen Angriffsvektoren nicht.

Wenn Du in der Lage bist uns einen Angriffsvektor zu demonstrieren, bei dem man ohne Authentifizierung Kundendaten manipulieren kann, kannst Du uns diesen gerne per PM zukommen lassen und wir werden diesen selbstredend umgehend eliminieren.

Solange das nicht der Fall ist, bitte ich Dich, mit Aussagen über mögliche nicht authentifizierte Manipulationsmöglichkeiten von Kundendaten sehr vorsichtig zu sein.

LG
Mathias

#3

@Mathias

Kann ich im Laufe der nächsten 4 Wochen gerne dazwischen schieben und demonstrieren. Dass das Session-Cookie ungeschützt ist, dass es keine Content-Security-Policy gibt und, dass es keinen XSRF-Schutz gibt, dass sehe ich sofort in der Browser-Konsole. Logge ich mich ein, wird kein CSRF-Token mitgesendet und genau das gleiche Spiel bei jeder Speicheraktion. Schaue ich mir das Cookie an, fehlt SameSite, Secure und HttpOnly. Das heißt, ich kann ohne SSL-Verbindung und vom Client per JavaScript (daher auch Erweiterungen) aus auf das Cookie zugreifen und dies sogar von einer anderen Domain aus.

Um das zu sehen, brauche ich den Quellcode nicht und um diese Schwachstellen zu schließen (XSRF ausgenommen), braucht man maximal 1 Stunde. Da hier der PHP-Session-Handler verwendet wird und das Cookie nicht per PSR-15 Middleware und PSR-7 Response gesetzt wird, kann man das Cookie dennoch mit folgenden Einstellungen schützen:

Es empfiehlt sich übrigens die Header bei Nutzung des PHP-Session-Handlers nach session_start() aufzuräumen, da unter anderem veraltete Header wie Pragma gesetzt werden, die Probleme mit HTTP/2 verursachen können.

Für die Content-Security-Policy kann man sich z.B. hier Informationen dazu holen:

Ob es andere Schwachstellen wie SQL-Injections oder unsichere/veraltete Bibliotheken gibt, das kann ich hingegen nicht sehen, weil ich den Quellcode nicht kenne. Wenn hier aber regelmäßig geprüft wird, ist das schon Mal ein gutes Zeichen, allerdings sollten die von mir genannten Punkte normalerweise sofort auffallen und was ebenfalls sofort auffällt, ist, dass die Server-UI mit eher veralteten Techniken entwickelt wurde, was aber an sich nicht schlimm ist, wenn zumindest alles für den Schutz der Anwendung getan wird.

Gibt es die Berichte des Audits irgendwo abrufbar für Kunden?

1 Like
#4

Hallo Mathias, ich lese in dem Beitrag von @hazington kein Wort von Kundendaten, die manipulierbar wären. Daher finde ich die Aussage “… über mögliche nicht authentifizierte Manipulationsmöglichkeiten von Kundendaten sehr vorsichtig zu sein.” - als sehr irreführend und sieht für mich nach einer Drohung aus. Das wiederum führt zu der Annahme, dass etwas verschleiert werden soll. Also geht das so nach hinten los und verspielt spätestens jetzt das Vertrauen. Eine Aufklärung ohne Drohung wäre da wohl der bessere Schritt gewesen. Viele Grüße NetzMerlin

3 Likes
#5

Hallo Hazington,

vielen Dank, dass Du Deine Erkenntnisse mit uns teilst. Ich würde mich über weitere Infos sehr freuen.

Liebe Grüße
Stephan

#6

@Mathias

Leider kam ich bisher noch nicht dazu ein Proof of Concept zu entwickeln, wobei der Angriffsvektor relativ eindeutig ist.

Dennoch möchte ich klarstellen:

Pascom Kunden sind derzeit NICHT akut gefährdet und es besteht auch NICHT die Gefahr, dass allgemein Kundendaten entwendet werden! Dies hatte ich auch niemals behauptet, möchte hier aber von vornherein mögliche Missverständnisse ausräumen.

Die Schwächen in der Session- und CSRF-Konfiguration erlauben es einem Angreifer jedoch einen gezielten Angriff auf eine bestimmte Instanz auszuführen. Sprich, der Angreifer muss es schon auf jemanden abgesehen haben.

Die Voraussetzung für einen erfolgreichen Angriff sind:

a) Der Kunde (Admin) ist in seiner Pascom Instanz eingeloggt und klickt auf einen Link zu einer Seite, die den fehlenden CSRF-Schutz nutzt, um Formulare an die Instanz abzusenden. Hier kann aber bereits die leicht umsetzbare CSP die Instanz for einfachen Angriffen aus dem Browser schützen.
b) Der Kunde installiert eine Browser-Erweiterung, die das Session-Cookie ausliest, da dieses in der Konfiguration des Cookies nicht vor Client Zugriff geschützt ist. Auch hier, setzt einfach das Flag HttpOnly und Secure (5 bis 10 Minuten Arbeit) und dieser Angriff ist nicht mehr möglich.

Sprich, mit a) kann die Instanz direkt manipuliert werden, mit b) ebenfalls, allerdings kann b) gleich die gesamte Sitzung übernehmen. Wie gesagt, bei beiden Varianten muss es der Angreifer gezielt auf eine Instanz und den Admin abgesehen haben.

Die Lücken sind also nicht kritisch. Da sie jedoch mit überschaubaren Aufwand behoben werden können, wundere ich mich, dass es bis heute nicht passiert ist. Das ist etwas, das schiebt man kurz dazwischen und hat da einen Haken hinter. CSRF ist etwas schwieriger umzusetzen, aber das Cookie absichern und eine CSP setzen, die das Einbinden in Frames und das Absenden von Formularen anderer Domain unterbindet, ist nun wirklich kein Hexenwerk und in ein paar Minuten erledigt.