Alle moderneren Web-Applikationen arbeiten mit zwei Schichten. Da ist einmal die Pr\u00e4sentation der Inhalte im Web-Browser bei den End-Ger\u00e4ten. Auf der anderen Seite stehen die Server (z.B. die ArchivistaBox), auf denen die Daten verarbeitet werden. Bei der Darstellung der Inhalte kommt dabei meistens JavaScript zum Einsatz. Damit k\u00f6nnen beim User-Interface (z.B. WebDMS) Informationen sehr flexibel (quasi on-the-fly) dargestellt und ver\u00e4ndert werden, ohne dass jeweils s\u00e4mtliche Daten bei jedem Aufruf zwischen Client (WebDMS) und dem Server (ArchivistaBox) neu \u00fcbermittelt werden m\u00fcssen.<\/p>\n Nachteilig im Sinne der Sicherheit von JavaScript ist, dass die entsprechenden Programme direkt im Web-Browser abgearbeitet werden.Dies deshalb, weil damit die Hoheit an einen externen Partner (Web-Browser) delegiert wird. Und auch wenn JavaScript-Programme unleserlich dargestellt werden, die Sourcen liegen quelloffen vor. Der Code kann dabei ohne grossen Aufwand im Web-Browser eingesehen und (deutlich „unangenehmer“) auch ver\u00e4ndert werden. Der aufgerufene Server kann dabei nicht feststellen, ob sein externer Partner in guter oder schlechter Mission, d.h. mit ge\u00e4nderten Quellen arbeitet.<\/p>\n Die einzige Kontrolle des Servers \u00fcber seinen Klienten (Web-Browser) besteht darin, dass die Sourcen beim Aufruf vom Server geladen werden. Ob das ausgelieferte Programm in korrekter Weise abgearbeitet wird, dar\u00fcber entscheidet nicht der Server (ArchivistaBox), sondern der jeweilige Web-Browser. Beim sogenannten Cross-Site-Scripting, auch bekannt unter XSS-Attacken, passiert genau dies. Der JavaScript-Code wird im Web-Browser kompromittiert.<\/p>\n Eine Unterart von solchen Attacken liegt bei den reflektierten Angriffen vor. Der „Angriff“ erfolgt dabei \u00fcber einen externen Link, der z.B. \u00fcber pr\u00e4parierte PDF-Dokumenten oder Mails ausgeliefert wird. Klicken ahnungslose Anwender\/innen darauf und geben dabei unbedarft Benutzername und Passwort ein, so „f\u00e4ngt“ der externe Server die Anmeldedaten ab und kann danach mit den so gewonnen Daten problemlos auf die gew\u00fcnschten Web-Applikation zugreifen.<\/p>\n Wichtig dabei zu wissen ist, die Anmeldedaten werden dabei auf einem externen Rechner eingegeben. Wer bei Eingabe von Daten \u00fcberpr\u00fcft, ob in der Navigationsleiste des Web-Browsers die Adresse des gew\u00fcnschten Servers steht, kann in dieser Form nicht „\u00fcbert\u00f6lpelt“ werden. Eine Unterart des reflektierten Angriffs besteht darin, dass zwar die gew\u00fcnschte Website (z.B. ArchivistaBox) aufgerufen wird, dass dabei jedoch direkt JavaScript-Code \u00fcbermittelt wird. Anbei ein Beispiel:<\/p>\n Um das Beispiel ausf\u00fchren zu k\u00f6nnen, muss bei der IP-Adresse 192.168.0.99 die IP-Adresse einer ArchivistaBox eingegeben werden. Abgesehen davon, dass der obige Link relativ lang ist, sollte einem im \u00fcbrigen nicht prim\u00e4r „Hacking X“ stutzig machen (ein „b\u00f6sartiger“ Hacker w\u00fcrde einem nicht mit ‚Hacking X‘ begr\u00fcssen, sondern das Fragment ‚<script>…<\/script>‘, da darin ja ganz bewusst ein externer Code „eingeschleust“ werden soll.<\/p>\n Im Prinzip sollte jeder Server \u00fcberpr\u00fcfen, ob derartige Codefragmente an ihn \u00fcbermittelt werden. Korrekt geparst w\u00fcrde das Fragment ‚<script>…<\/script>‘ dann einfach als Text im entsprechenden Feld der Anwender\/innen ausgegeben, d.h. der „eingeschleuste“ Code wird als Text und nicht als Script verarbeitet. Diese Kontrolle erfolgte in fr\u00fcheren Version von WebDMS leider mangelhaft. Zwar war es nicht m\u00f6glich, beim Arbeiten in WebDMS nach dem Anmelden derartige Code-Fragmente abzusetzen, doch beim Login-Formular erfolgte leider keine solche Kontrolle.<\/p>\n Grunds\u00e4tzlich sind alle bisherigen ArchivistaBoxen (Versionen vor 2022\/I) davon betroffen, da beim Login-Formular das Fragment ‚<script>…<\/script>‘ nicht zwingend in Text umgewandelt wurde. Auch wenn entsprechende Angriffe ohne die Mithilfe unbedarfter Dritter nicht m\u00f6glich sind, so soll die Maschine (hier ArchivistaBox) nat\u00fcrlich trotzdem alle m\u00f6glichen Checks durchf\u00fchren, damit solche Angriffe m\u00f6glichst vermieden werden k\u00f6nnen. Mit ‚m\u00f6glichst vermieden‘ sei zum Ausdruck gebracht, dass nur das vermieden werden kann, was auch bekannt ist.<\/p>\n Die Antwort lautet: Update „bestellen“ und \u00fcber WebConfig einspielen. „Bestellen“ bedeutet, dass Kunden mit Wartungsvertrag jederzeit kostenfrei eine aktualisierte Version erhalten, sofern sie dies w\u00fcnschen (Mitteilung per Telefon, Mail oder in Briefform gen\u00fcgt).<\/p>\n An dieser Stelle darf die Frage aufgeworfen werden, warum nicht einfach alle ArchivistaBox-Systeme automatisch aktualisiert werden. Die Antwort lautet, dass dies im Konzept der ArchivistaBox so nicht vorgesehen ist, da solche Updates einen automatisierten Zugriff auf die ArchivistaBox erfordern w\u00fcrden. So praktisch solche Updates auch sein m\u00f6gen, Systeme, welche jederzeit automatisiert aktualisiert werden k\u00f6nnen, sind in weit gr\u00f6sserem Masse „angreifbar“, als wenn Updates durch Menschen „angestossen“ werden.<\/p>\n Wie bereits oben ausgef\u00fchrt, reflektierte Cross-Site-Scripting-Angriffe erfordern immer ein (mehr oder minder) naives Mittun der Benutzer\/innen. Wer unbedarft auf Links klickt bzw. sich bei Eingabe von Benutzername und Passwort nicht darum schert, wem diese Informationen anvertraut werden, muss sich nicht wundern, wenn ein Takeover erfolgt. Die \u00dcbernahme des Systems erfolgt ja erst dadurch, dass auf einer Drittseite die Anmeldedaten „preisgegeben“ werden. Die gleiche Situation liegt vor, wenn die gleichen Benutzerdaten in s\u00e4mtlichen m\u00f6glichen und unm\u00f6glichen Situation verwendet werden.<\/p>\n Selbst das beste Passwort n\u00fctzt herzlich wenig, wenn es tausendfach bei s\u00e4mtlichen Systemen zur Anwendung gelangt. Ebenso sollten nat\u00fcrlich die Standardpassw\u00f6rter gerade nicht zur Anwendung gelangen. In diesem Sinne stellen reflektierte Cross-Site-Scripting-Angriffe ein eher kleineres Problem dar. Dennoch soll und darf dar\u00fcber gesprochen werden.<\/p>\n Zur\u00fcck zur Frage, warum eingangs von einer Odysee die Rede ist. Der erste Anruf erfolgte im Oktober 2021. Eine Person gibt sich als Security-Forscher aus und verweist auf eine Firmen-Webseite mit Sitz in Deutschland. Mit bestimmter Tonalit\u00e4t m\u00f6chte der Anrufer, dass die Firma Archivista ein Dokument (passwortgesch\u00fctzt) ab einer Webseite herunterl\u00e4dt. Die Sicherheitsl\u00fccke betreffe einen Kunden, dies habe ein Audit ergeben.<\/p>\n Da weder der Name des Kunden genannt wird, da keine Gesch\u00e4ftsbeziehung zum Anrufer besteht, da der Anrufer ab einer unbekannten und nicht verifizierbaren Mobilfunknummer aus einem Drittland anruft, da ein Blick auf die angegebene Firmen-Homepage nicht im engeren Sinne eine Firma mit hunderten von Mitarbeitern (wie im Telefonat erw\u00e4hnt) vermuten l\u00e4sst, wird der Anrufer eingeladen, die „angebliche“ L\u00fccke per Mail zuzusenden. Dies wiederum m\u00f6chte der Anrufende um keinen Fall, dies sei unsicher.<\/p>\n Der Einwand, dass bei Open Source gut und gerne auch \u00f6ffentlich \u00fcber Sicherheitsprobleme diskutiert werden d\u00fcrfe bzw. m\u00fcsse, \u00fcberzeugt den Anrufenden nicht. Er beharrt darauf, dass die L\u00fccke nur vertraulich \u00fcbermittelt werden k\u00f6nne. Selbst der Vorschlag, das Dokument in Briefform (mit\/ohne USB-Stick) zuzustellen, findet keine Gnade. Irgendwann verweist die Firma Archivista auf die Meldestelle f\u00fcr Cyberattacken des Bundes. <\/a><\/strong>Der Anrufende betont, dass sollte das Dokument nicht heruntergeladen werden, eine solche Meldung erfolgen w\u00fcrde und dass die Sicherheitsmeldung danach \u00f6ffentlich publiziert w\u00fcrde.<\/p>\n Anfangs Februar erfolgt ein Anruf eines Herrn Knoepfel, der beim nationalen Zentrum f\u00fcr Cybersicherheit arbeite. Dieser bittet um einen R\u00fcckruf. Leider gelingt es nicht, den Herrn Knoepfel zu erreichen. Weiter ist es relativ schwierig zu \u00fcberpr\u00fcfen, ob Herr Knoepfel wirklich Mitarbeiter der besagten Bundesstelle ist, denn auf der Homepage der Meldestelle f\u00fcr Cyberattacken des Bundes<\/a><\/strong> gibt es einzig ein Web-Formular, um Meldungen zu erfassen. Wer nach einer Telefonnummer sucht, findet eine solche nicht.<\/p>\n Wer erfahren m\u00f6chte, wer bei besagtem Amt arbeitet, m\u00fcsste sich \u00fcber Linkedin.com anmelden, der Link https:\/\/www.linkedin.com\/company\/ncsc-ch<\/a> <\/strong>befindet sich ganz unten auf der entsprechenden NCSC-Homepage. Da Linkedin.com vor einigen Jahren dadurch aufgefallen war, dass \u00fcber 100 Millionen Passw\u00f6rter abgekupfert wurden, wird auf das Er\u00f6ffnen eines Kontos verzichtet. Herr Knoepfel meldet sich einige Tage sp\u00e4ter per Mail. Es sei eine Sicherheitsl\u00fccke bei der Meldestelle eingegangen, die Forscher w\u00fcrden die L\u00fccke wohl in naher Zukunft ver\u00f6ffentlichen.<\/p>\n In der Mail findet sich ein Verweis auf eine weitere Mail, worin behauptet wird, die Firma Archivista habe am 17. Dezember 2021 die Sicherheitsl\u00fccke erhalten. Da dies mit den Logs bzw. dem Spam-Ordner nicht verifiziert werden kann, erfolgt abermals ein Anruf bei besagter Nummer. Erneut l\u00e4dt der Anrufbeantworter zur Hinterlegung einer Nachricht ein.<\/p>\n Eine Web-Recherche f\u00f6rdert die Telefonnummer der NCSC bei help.ch<\/a><\/strong> zutage. Beim Anruf unter dieser Nummer nimmt eine Frau Minder ab. Sie sei Kommunikationsbeauftragte des Finanzdepartementes. Die Nachfrage, ob ein Herr Knoepfel bei der NSCS arbeite, beantwortet sie zun\u00e4chst damit, es sei kein Herr Knoepfel bekannt. Erst auf den Einwand, dass, wenn es den Herrn Knoepfel nicht gebe, es einer Meldung bei der NCSC bed\u00fcrfe, wonach sich jemand als NSCS-Mitarbeiter mit dem Namen Knoepfel ausgebe, fragt Frau Minder nach, wie der Herr Knoepfel geschrieben werde. Unter ‚Kn\u00f6pfel‘ gebe es niemanden, aber unter Knoepfel, doch, dieser existiere.<\/p>\n Die telefonisch angegebene Nummer stimmt mit der Nummer in der Mail \u00fcberein. Erneut wird versucht, Herrn Knoepfel telefonisch zu kontaktieren. Da dies nicht gelingt, wird eine l\u00e4nger Mail mit Schilderung der Sachlage verfasst. Ehe die Mail verschickt wird, klingelt das Telefon. Herr Knoepfel ruft zur\u00fcck und meint, ich h\u00e4tte mehrfach angerufen.<\/p>\n Es wird die Situation geschildert, wonach der Firma Archivista bis heute keine Sicherheitsmeldung vorliege, obwohl darum per Mail mehrfach gebeten wurde. Herr Knoepfel best\u00e4tigt, dass eine Meldung bei der NCSC eingegangen sei. Auf Nachfrage hin wird die Sicherheitsmeldung per Mail durch Herrn Knoepfel zugestellt.<\/p>\n Es handelt sich um ein achtseitiges PDF-Dokument, welches eine reflektierte Cross-Siting-Script-L\u00fccke (wie oben beschrieben) in der Anmeldemaske protokolliert. Ebenfalls wird recht gut beschrieben, wie das Ausf\u00fchren von JavaScript \u00fcber manipulierte Links vermieden werden kann bzw. in unserer Applikation verifiziert werden kann, dass beim Anmelden die Werte nicht korrekt verarbeitet werden.<\/p>\n Stutzig in besagtem Dokument macht ein Screenshot, welcher Archivista WebClient mit Version 5.2 ausweist. Die Version 5.2 datiert aus den Jahren 2005 bis 2007. Folglich wird klar, dass der „mysteri\u00f6se“ Kunde keine je bei Archivista erworbene ArchivistaBox betreibt. Vielmehr kommt eine Open Source Version zum Einsatz, die mittlerweile irgendwo zwischen 15 und 20 Jahre auf dem Buckel hat.<\/p>\n Selbstverst\u00e4ndlich beinhaltet das Recht bei der GPLv2-Lizenz, eine jede Software in beliebiger Form einzusetzen. Allerdings erstaunt es doch sehr, dass sich eine Firma ein Security-Audit (solche \u00dcberpr\u00fcfungen sind nicht ganz „g\u00fcnstig“) leistet, um eine ca. 15 bis 20 j\u00e4hrige Software (hier Archivista WebClient, aktuell WebDMS) \u00fcberpr\u00fcfen zu lassen.<\/p>\n Nun k\u00f6nnte die betreffende Firma, welche die ArchivistaBox \u00fcber offensichtlich diesen Zeitpunkt ohne Wartung und Support im Einsatz stehen hat, das Problem ja selber angehen — immerhin liegen die Sourcen ja vor. Genau dies allerdings erfolgte nicht. Stattdessen wurde die Audit-Firma beauftragt, die L\u00fccke mit Klassifikation „vertraulich“ zu dokumentieren.<\/p>\n Dies f\u00fchrte dazu, dass besagte Audit-Firma das Dokument um keinen Preis per Mail oder in Briefform zustellen wollte. Immerhin, nach vielen Um- und Irrwegen \u00fcber die Meldestelle f\u00fcr Cyberattacken des Bundes<\/a><\/strong> erhielt die Firma Archivista GmbH endlich Einblick in Problematik — und konnte schliesslich handeln.<\/p>\n Angriffe mit reflektiertem Cross-Siting-Sripting sind letztlich so effektiv wie die Nutzer\/innen unbedarft auf irgendwelche Links klicken bzw. ihre Kennw\u00f6rter ungeniert eingeben. \u00dcber solche L\u00fccken soll und darf diskutiert werden. Sie d\u00fcrfen bzw. sollten aber nicht \u00fcberbewertet werden.<\/p>\n Ganz unabh\u00e4ngig davon bedeutet Open Source Offenheit auf der Basis von Vertrauen und Fairness. Wo die Sourcen offen gelegt sind, bringt „Geheimhaltung“ wenig bis nichts. Allf\u00e4llige Schwachstellen sind ohnehin \u00f6ffentlich im Code einsehbar. Und darum d\u00fcrfen alle jederzeit allf\u00e4llige Schwachstellen gerne kommunizieren. Im Sinne der Offenheit werden solche Meldungen aber auch in Zukunft vorzugsweise per Mail<\/a><\/strong> entgegen genommen.<\/p>\n\n\n\n\t![\"\"](\"https:\/\/archivista.ch\/cms\/wp-content\/uploads\/2022\/02\/nordkapp0-scaled.jpg\")
<\/a><\/p>\nWorum geht es bei Cross-Site-Scripting?<\/h2>\n
Reflektierte Attacken<\/h1>\n
http:\/\/192.168.0.99\/perl\/avclient\/index.pl?target=_top&host=localhost\"><script>alert(\"Hacking 1\")<\/script>&db= \"><script>alert(\"Hacking 2\")<\/script>&uid= \"><script>alert(\"Hacking 3\")<\/script> &uid=Admin&db=archivista&pwd=xxxx<\/strong><\/pre>\n
<\/a><\/p>\nIst meine ArchivistaBox davon betroffen?<\/h1>\n
Was gilt es zu tun?<\/h1>\n
Wenn ein unbekannter Dritter zum Download einl\u00e4dt<\/h2>\n
<\/a><\/p>\nNationale Meldestelle nur per Web-Formular erreichbar<\/h2>\n
NSCS-Telefonnummer „nur“ bei help.ch<\/a><\/strong><\/h2>\n
Der „omin\u00f6se“ Kunde mit Version 5.2<\/h2>\n
Die Moral von der Geschichte…<\/h2>\n