Category: update

Nextcloud-Tools: Working with the Nextcloud Server-Side Encryption

02.12.2019 yahe administration code security update

At the beginning of the year we ran into a strange problem with our server-side encrypted Nextcloud installation at work. Files got corrupted when they were moved between folders. We had found another problem with the Nextcloud Desktop client just recently and therefore thought that this was also related to synchronization problems within the Nextcloud Desktop client. Later in the year we bumped into this problem again, but this time it occured while using the web frontend of Nextcloud. Now we understood that the behaviour did not have anything to do with the client but with the server itself. Interestingly, another user had opened a Github issue about this problem at around the same time. As these corruptions lead to quite some workload for the restore I decided to dig deeper to find an adequate solution.

After I had found out how to reproduce the problem it was important for us to know whether corrupted files could still be decrypted at all. I wrote a decryption script and proved that corrupted files could in fact be decrypted when Nextcloud said that they were broken. With this in mind I tried to find out what happened during the encryption and what broke files while being moved. Doing all the research about the server-side encryption of Nextcloud, debugging the software, creating a potential bugfix and coming up with a temporary workaround took about a month of interrupted work.

Even more important than the actual bugfix (as we are currently living with the workaround) is the knowledge we gained about the server-side encryption. Based on this knowledge I developed a bunch of scripts that have been published as nextcloud-tools on GitHub. These scripts can help you to rescue your server-side encrypted files in cases when your database was corrupted or completely lost.

I also wrote an elaborate description about the inner workings of the server-side encryption and tried to get it added to the documentation. It took some time but in the end it worked! For about a week now you can find my description of the Nextcloud Server-Side Encryption Details in the official Nextcloud documentation.

Update

Due to popular demand I wrote the decrypt-all-files.php script that helps you to decrypt all files that have been encrypted with the server-side encryption. It is accompanied with a somewhat extensive description on how to use it.


.local, .home.arpa and .localzone.xyz

11.11.2019 yahe administration update

35 years ago the IETF defined special IPv4 addresses in RFC 1597 to be used solely in private intranets and with that created the separation between internal networks and the internet. 5 years later they proceeded to define special-use top-level domains like .example, .invalid and .test in RFC 2606. However, the IETF did not reserve a top-level domain to be used within the private intranets that they had introduced before. This lead to confusion with administrators that still persists to the current day.

Every time an administrator was tasked to design a network structure they also had to think about naming conventions within the network. As there was a pre-defined set of "valid" top-level domains within the internet, it was rather easy to just select an "invalid" TLD and use that for the private network. At least, until the ICANN decided to delegate new TLDs to anyone who was willing to apply and pay the required fees. The ICANN even provided a paper on how to identify and mitigate name collisions to be used by professionals.

With RFC 6762 the .local TLD was approved as a special-use TLD to be used in internal networks and many administrators thought that this would solve the problems, but unfortunately, it did not. .local was designated to be used with multicast DNS, meaning that each device in a network could grab its preferred hostname. At the beginning this was not a big deal, but as more and more devices implemented Apple's Bonjour protocol (also known as zeroconf) interoperability problems started to pop up. Appendix G of said RFC even mentioned alternative TLDs that might be used, however, the ICANN did not accept any of them as special-use domain names.

Years later the new RFC 7788 defined .home as a potential local-only TLD, but it was changed to the rather unusual .home.arpa domain name with RFC 8375. This domain is safe to be used in local networks and was accepted as a special-use domain name by the ICANN. Unfortunately, due the word "home" in the domain it is not quite fitting for business environments.

There are two more TLDs that might be safe to use: .corp and .home are not officially recognized special-use domain names but the ICANN has refrained from delegating them to bidders as the risk of breaking internal networks is deemed to be too big.

As of today, most tutorials still propose to use a publicly registered domain for internal networks. This is why I registered .localzone.xyz about half a year ago. It is explicitly meant to be used locally, has public DNS records set to prevent any public CA from issuing trusted TLS certificates for that domain as well as DNS records defining all mails using that domain as SPAM and will not be used for publicly accessible services as long as it is owned by me. I am using this domain internally myself and am also trying to get the domain added to the public suffix list. This list defines domain and cookie boundaries so that e.g. example-a.com is not able to set cookies for example-b.com.

So if you are looking for a domain that you can use for internal domain names then look no further: Either use the special-use domain name .home.arpa (which might not be fitting for businesses) or use .localzone.xyz as I am. It makes clear that you are in a local environment without being too specific about whether it is a private or business network.

Update

On October 6th, 2020 localzone.xyz has finally been added to the public suffix list.


Bug in Login With Ajax Plugin erstellt Nutzeraccounts

29.08.2014 yahe legacy security update wordpress

Anfang dieser Woche hatte ich über ein Plugin informiert, mit dem ein Angreifer ungefragt neue Nutzer anlegen kann. Damit ist das vorgestellte Plugin leider nicht allein. Denn auch das Login With Ajax Plugin hat diese unschöne Sonderfunktion.

In der Datei "login-with-ajax.php" befindet sich die Klasse "LoginWithAjax", die man mit einem präparierten Formular dazu bringen kann, neue Accounts anzulegen, selbst dann, wenn die Registrierung neuer Nutzer eigentlich in der Wordpress-Konfiguration ausgeschaltet wurde:

<form action="http://example.com/" method="POST">
  <input type="hidden" name="lwa" value="true" />
  <input type="hidden" name="login-with-ajax" value="register" />
  <input type="hidden" name="user_login" value="exploit" />
  <input type="hidden" name="user_email" value="exploit@example.com" />
  <input type="submit" />
</form>

Ich bekam vor mehreren Wochen von den Entwicklern die Aussage, dass sie das Problem ASAP beheben würden. Seitdem ist jedoch nichts mehr geschehen. Der Tipp an dieser Stelle kann deshalb nur lauten, das Plugin zu deaktivieren, bis es ein Update gegeben hat. Viele andere Plugins prüfen häufig lediglich, ob ein Nutzer eingeloggt ist, bevor sie ihre Funktionalität bereitstellen. diese Absicherung kann aufgrund des Bugs derzeit umgangen werden.

Update

In der Version 3.1.3 wurde dieser Fehler nun endlich behoben.


Bug in Form Builder Plugin ermöglicht vollständige Kompromittierung

21.08.2014 yahe legacy security update wordpress

Und wieder einmal ist mir ein besonders fieser Bug über den Weg gelaufen. Dieses mal habe ich ihn im Form Builder Plugin gefunden. Form Builder ist dafür gedacht, Webformulare per Drag&Drop zu erstellen und einfach im Blog auf Seiten und in Beiträgen einbinden zu können. Das ganze funktioniert, indem man einen "form"-Tag mit einer zugehörigen ID in den Seitentext schreibt. Das Plugin klinkt sich in den "the_content"-Hook ein, sucht nach dem "form"-Tag, nimmt die ID, geht damit gegen einen Server des Plugin-Anbieters und ruft das HTML des Formulars ab, um es anzuzeigen.

Zum Abrufen haben die Entwickler des Plugins eine eigene Klasse namens "formHttpRequest" geschrieben, die sich in der Datei "includes/http.class.php" befindet und per CURL die Serveranfragen stellt. Leider benimmt sie sich dabei etwas merkwürdig. Anstatt einfach nur eine Anfrage an den Server zu stellen, bereitet sie vorher jede Menge vor, unter anderem nimmt sie in der Methode "connect()" alle per POST gesendeten Dateien an und versucht sie in den Uploads-Ordner zu schreiben (normalerweise "./wp-content/uploads/"). Aufgrund eines fehlenden Slashes misslingt das aber, sodass die Dateien anschließend z.B. "./wp-content/uploadstest.txt" heißen, wenn die ursprünglich hochgeladene Datei "test.txt" hieß.

Die hochgeladenen Dateien werden zwar nach Beenden des Requests wieder gelöscht, während der Request noch läuft können sie jedoch aufgerufen werden. Da man zudem beliebig viele und (von der Serverkonfiguration abhängig) auch beliebig große Dateien mitschicken kann, kann die für den Request benötigte Zeit auch beliebig verlängert werden. Sollte der Server des Pluginanbieters zudem den Request mit einem Fehler beantworten, werden die Dateien gar nicht mehr entfernt.

Der Exploit-Code ist simpel. Der POST-Request muss einfach gegen eine Seite des Blogs gerichtet werden, auf der sich ein entsprechendes Formular befindet. Während der Exploit läuft, muss man dann nur versuchen, seine hochgeladene Datei aufzurufen:

<form enctype="multipart/form-data" action="http://example.com/example" method="POST">
    <input type="hidden" name="MAX_FILE_SIZE" value="30000" />
    Uploads: <input type="file" name="file[]" multiple="multiple" />
    <input type="submit" />
</form>

Es ist bisher nicht bekannt, ob diese Lücke bereits aktiv zum Angreifen von WordPress-Blogs verwendet wurde. Der Fehler wurde in der aktuellen Version 2.4.2 zumindest gemindert. Die Dateien werden zwar immer noch verarbeitet, verbleiben nun jedoch zumindest im temporären Upload-Ordner von PHP (z.B. "/tmp"). Installationen, bei denen der temporäre Upload-Ordner über das Web erreichbar ist, bleiben damit weiterhin angreifbar. Trotzdem sollten alle Nutzer dieses Plugins schnellstmöglich updaten.

Update

Ich hatte noch einmal Kontakt mit den Entwicklern gehabt, die nun eine neue Version 2.4.3 mit einem wesentlich besseren Lösungsansatz veröffentlicht haben.


Wikipad: Etherpad-Lite mit DokuWiki synchronisieren

17.04.2014 yahe code legacy linux update

Vor einiger Zeit habe ich mir ein Etherpad-Lite installiert, um verteilt und auch unterwegs Texte verfassen zu können, die ich anschließend veröffentliche oder anderweitig nutze. Das ist soweit toll, doch die Veröffentlichung war in meinen Augen unpraktischer, als sie sein müsste, da ich den Text kopieren, irgendwo anders einfügen und neu formatieren musste. Meine Idee war es deshalb, die Veröffentlichung direkt aus dem Etherpad-Lite heraus erledigen zu können, zum Beispiel bei kleineren Texten, die ich anderen zur Verfügung stellen möchte. Die Frage war nur, über welche Plattform die Veröffentlichung stattfinden sollte.

Anfangs dachte ich daran, eine eigene Oberfläche zu entwickeln, allerdings wäre die nicht sonderlich hübsch geworden. Vor kurzem bin ich nun auf DokuWiki gestoßen, das perfekt zu sein scheint. Das besondere an DokuWiki ist, dass keine Datenbank verwendet wird, sondern alle Inhalte in einfachen *.txt-Dateien abgelegt werden. Ich könnte also einfach Pads exportieren, als Textdatei ablegen und wäre fertig. Die Idee zu Wikipad war geboren.

Texterstellung in Etherpad-Lite

Implementiert habe ich die Synchronisation in PHP. Es gibt einen Pad-Präfix und einen Wiki-Präfix. Alle Pads, deren Name den Pad-Präfix ("<Pad-Präfix>!<Name>") beinhalten, werden in einen Namespace des Wikis überführt ("<Wiki-Präfix>:<Name>"). Man kann die Präfixe auch weglassen, dann werden diese ignoriert und ohne Präfixe gearbeitet. In meinem Fall verwende ich z.B. den Pad-Präfix "wiki!" und einen leeren Wiki-Präfix.

Als erstes lasse ich aus der Etherpad-Lite Datenbank auslesen, welche Pads es mit dem Pad-Präfix gibt. Anschließend wird geprüft, wieviele Revisionen es von diesem Pad gibt. Hat sich seit der letzten Synchronisation die Anzahl der Revisionen geändert, so wird das Pad exportiert und in den data-Ordner des DokuWikis geschrieben.

Veröffentlichung in DokuWiki

Neben den Präfixen habe ich noch ein paar weitere Steuerungsmechanismen implementiert. So werden Pads nicht synchronisiert, wenn sie direkt nach dem Präfix einen Punkt im Namen haben (z.B. "wiki!.beispiel"). Zudem ist es möglich, inline (das heißt im Content des jeweiligen Pads) die Synchronisation eines Pads zu beeinflussen. Damit ein Pad aus dem Wiki gelöscht wird, muss der Padinhalt mit dem Text "[.remove]" beginnen. Möchte man stattdessen ein Pad bearbeiten, ohne, dass die aktuell gültige Fassung im Wiki gleich ersetzt wird, so muss der Padinhalt mit dem Text "[.ignore]" beginnen. In diesem Fall bleibt die aktuelle Seite im Wiki erhalten, wird jedoch nicht mit der neusten Revision des Pads überschrieben.

Update

In Etherpad Lite Version 1.5.0 wurde der DokuWiki-Export entfernt. Wikipad wurde nun so angepasst, dass es trotzdem noch verwendet werden kann. Leider kann man nun nicht mehr die WYSIWYG-Formatierung von Etherpad Lite nutzen, sondern muss die DokuWiki-Stylingsyntax verwenden.


Search

Links

RSS feed

Categories

administration (42)
arduino (12)
calcpw (2)
code (37)
hardware (16)
java (2)
legacy (113)
linux (28)
publicity (7)
review (2)
security (61)
thoughts (22)
update (9)
windows (17)
wordpress (19)