A security flaw in daygate (AKA the Gibberfish Management Portal) has been discovered which could allow an unauthenticated attacker to eavesdrop on websocket traffic, potentially leaking sensitive information such as passphrases. No encrypted user data or files were made accessible by this flaw.
This issue has been fixed in the most recent commit to the master branch (tags/20181220.0 or later). We quickly ensured that all of Gibberfish’s hosted clients were patched before making this public announcement, but 3rd party users may still be vulnerable if they have not enabled automatic updates via the web interface.
As the Management Portal is designed to run exclusively as a hidden service on the Tor network, an attacker would first need to become aware of the service’s .onion address, which may decrease the likelihood of this vulnerability being exploited.
While we have no evidence to suggest that any user information has been compromised by this flaw, we strongly advise updating to the latest stable code as soon as possible via our git repository. We further recommend that server administrators change their encryption passphrase immediately after updating, for which we have included instructions below.
Clients with servers hosted by Gibberfish, Inc. do not need to update, but we urge all users to change their encryption passphrase.
To update immediately, enable updates via the ‘Updates’ tab, then open a terminal window and manually invoke the update script from the command line:
$ sudo ~daygate/daygate/scripts/update.sh
— OR —
To perform a one-off update without enabling automatic updates, run the following commands:
$ cd ~daygate/daygate
$ git pull
$ sudo scripts/install.sh
A PDF document containing step-by-step instructions for changing the server’s encryption passphrase is linked below.
Please direct any remaining questions to gro.hsifrebbignull@ytiruces.
Daygate consists mainly of two parts: a Django web application and a back-end daemon which communicates with it via websockets. This allows the user to invoke automation scripts on the system via a web interface and see real-time output. The websockets endpoint, implemented with the ‘channels’ library, exists outside of Django’s main url mapping and authentication structures. Early in development, the endpoint was not properly secured. That part of the code-base remained largely untouched, and authentication was never implemented as an oversight.
While the messages passed via the websockets are short-lived and ephemeral, it would be possible for an attacker to make a connection via a Tor-enabled client and intercept messages containing
credentials intended for a legitimate client, including the passphrase used to encrypt and decrypt persistent storage volumes, as well as the default Nextcloud administrator password generated during initial deployment (the latter only exploitable if the administrator ignored recommendations to immediately change this passphrase).
The remediation consists of added middleware which checks for the presence of an authenticated Django user session before accepting remote connections. Connections originating from localhost only can be validated via a randomly-generated token which is passed as a query parameter and rotated on every re-connection.