Each month, we publish a review that covers essential activities of the last 30 days. This month, we talk about attacks on RCS, security vulnerabilities in VNC software, a massive data leak, fscrypt, our recent Mastodon account migration, and more.
Always stay in the loop!
Subscribe to our RSS/Atom feeds.
News of the month
In November 2019, we read the following news:
Attacks on the SMS successor “RCS”
SRLabs, the German company that offers SnoopSnitch and SIMtester, published a new report about attacks on RCS (Rich Communication Services). RCS is a communication protocol that aims to replace SMS in the future. It brings new features and is already supported by dozens of mobile phone carriers around the globe.
Their report shows that during the provisioning process, attackers can take over user accounts by stealing RCS configuration files and injecting other credentials. There are some other issues like insufficient validation of user identities, user tracking, and possible caller ID spoofing. The exploitability of these vulnerabilities largely depends on your mobile phone carrier. After the Simjacker attack, these vulnerabilities again show that you can’t fully control your smartphone.
Security vulnerabilities in VNC software
VNC (Virtual Network Computing) is a desktop sharing system that allows you to control other computers remotely. It is based on the RFB (Remote Frame Buffer) protocol. RFB itself isn’t a secure protocol. The current version 3.8, released in 2007, only supports a very weak authentication scheme, and there is no encryption.
This month, Kaspersky Lab released a report on 37 security vulnerabilities in LibVNC, TightVNC 1, TurboVNC, and UltraVNC. Some of the vulnerabilities resided in the open-source code for many years, again showing that open-source software isn’t automatically more secure than closed-source software. Some of the reported vulnerabilities are already publicly known for several months, as written in “UltraVNC – a security nightmare."
If you are a user of VNC, check whether you are affected and install updates if available. Keep in mind that you could be affected if your VNC implementation uses LibVNC. Besides, TightVNC 1 is unsupported and won’t get any update.
Massive data leak
Finally, Data Viper, a threat intelligence platform, released a report about a massive data leak that likely originated from People Data Labs and OxyData. PDL and OxyData are so-called data enrichment companies that collect data about people from different sources, combine it, and sell it to their customers.
The leak allegedly contains data about 1.2 billion unique people. Have I Been Pwned added 622 million affected e-mail addresses to their databases. While there are no credentials included, such data (e-mail addresses, phone numbers, social media profiles, and job history data) can be misused for spear phishing and impersonation.
Data breaches and leaks
Moreover, there were some data breaches. Have I Been Pwned added information about the following breaches:
- Vedantu (breached in mind-2019)
- ToonDoo (breached in August 2019)
- GPS Underground (breached in early 2017)
- EpicBot (breached in September 2019)
- GateHub (breached in October 2019)
- People Data Labs (leaked in October 2019), see above
Tool of the month
This month, we talk about fscrypt. It is a high-level tool for the management of Linux filesystem encryption. fscrypt manages metadata, key generation, key wrapping, PAM integration, and provides a uniform interface for creating and modifying encrypted directories. In summary, fscrypt applies encryption at the directory level (no full-disk encryption).
Requirements for fscrypt
To use fscrypt, you need a filesystem with encryption support and a kernel supporting reading/writing from the filesystem:
- ext4 and Linux kernel 4.1 (or newer)
- F2FS (Flash-Friendly File System) and Linux kernel 4.2 (or newer)
- UBIFS (Unsorted Block Image File System) and Linux kernel 4.10 (or newer)
Since ext4 is very common, we only talk about the “fourth extended filesystem” in this section.
Checking ext4 for encryption support
Before we use fscrypt, we first need to check if ext4 supports it. Check the following:
- Check if your filesystem is really ext4 formatted.
- In your terminal, enter
tune2fs -l /dev/device | grep 'Block size'. Both values MUST be identical.
- If you are using GRUB (GNU GRand Unified Bootloader), be sure that you use 2.04 or newer. GRUB older than 2.04 doesn’t support booting ext4 filesystem with encryption enabled.
If all requirements are met, proceed.
Install fscrypt and set it up
Install fscrypt via your system’s package manager. On Arch, you may run
yay -S fscrypt-git.
After this, enter
fscrypt status. The output shows whether your filesystem supports encryption and whether fscrypt is enabled. Check this carefully. If everything looks good, enter
sudo fscrypt setup to create the global configuration file. This is the only time you need root privileges.
After this, you have to decide on which filesystem you want to enable fscrypt. Let’s assume you chose /dev/sdb1. Enter
fscrypt setup /dev/sdb1. This command creates a hidden “.fscrypt” folder that contains relevant metadata.
The next step is already setting up a directory that should be encrypted. Use a new folder for this! Create a new folder (e.g., by entering
mkdir newfolder) and set it up by entering
fscrypt encrypt newfolder.
Afterward, fscrypt asks which protector it should use. A “protector” in fscrypt is just some kind of secret. fscrypt supports your login passphrase, a custom passphrase, or a raw key file. You can change your protector later. (In reality, it is more complicated; however, we won’t cover this in detail.)
Let’s tell fscrypt to use “A custom passphrase” here. Assign a name. Then enter and confirm your password. The final output should be something like “is now encrypted, unlocked, and ready for use.”
fscrypt status newfolder to check again. The output should be similar to “‘newfolder’ is encrypted with fscrypt.”
Using your encrypted folder
After setting up the new folder, you can put some files in there. It is essential to understand that fscrypt can’t encrypt files that were already in the folder before setting it up. Due to this, you need to re-add files after enabling encryption, or you just use a new folder (as suggested above).
During regular use, you don’t need to lock the folder. After a system restart, you can unlock your folder by entering
fscrypt unlock newfolder. You must enter your passphrase, and fscrypt will output “‘newfolder’ is now unlocked and ready for use.” Then, you can use it as any other folder on your system.
In summary, fscrypt provides an easy way to set up folder-based encryption on most Linux systems. For more details, check fscrypt’s documentation on GitHub.
Readers’ questions of the month
Each month, readers send us questions via e-mail, Mastodon (Fediverse), Signal, or via the forum of privacytools.io. In general, we directly reply to questions. However, we would like to list some questions and answers that are interesting for more than only one person:
“Why do we see Elasticsearch leaks all the time?”
Internal services unknowingly exposed to the internet are the problem. Elasticsearch is only one example. There are also exposed IP cameras, PLCs in industrial environments, and office printers. Regularly scan your public and private IP address ranges to detect open ports and services and apply usual security practices. Never just assume something is configured – check and document it.
“Which cloud storage provider do you recommend?”
We don’t recommend any specific cloud storage provider. Some providers may offer additional server-side encryption of some kind; however, you can never be sure about this if you don’t control the server. Keep in mind that TLS encryption is only relevant for encrypting/authenticating data between your computer and the remote server. TLS doesn’t protect your uploaded data on the server. You may use tools like Cryptomator to encrypt your data locally before sending it to the server.
“Which search engine do you recommend?”
There are no real benefits of switching your search engine. In all cases, you can’t check if a search engine doesn’t track you. You must always trust the statements of the provider. The most important feature of a search engine is likely to find answers for your search query. Some people favor metasearch engines like MetaGer or SearX, while others state that metasearch engines are unusable. Others like to use DuckDuckGo or Startpage. So we can’t recommend anything special here.
Just send us your questions. Maybe, we answer your question in the next monthly review.
Our activities of the month
In November, we published one new tutorial:
- How to redact sensitive information with LibreOffice 6.3+: This tutorial shows the risks of leaking information in documents and the new redaction feature of LibreOffice 6.3.
Besides, we changed several things on our blog:
- We centralized Git pushes to codeberg.org. Due to this, we can provide OpenPGP-signed and verified Git repositories for transparency. (Beforehand, our commits were already signed, but the key wasn’t connected to the account.)
- We added information on how to support the InfoSec Handbook.
- Hugo, the tool we use to generate our static blog, introduced a new Markdown parser. Due to this, we had to change the layout of several pages. Furthermore, we re-enabled the automatic rendering of the table of contents on most pages. If you spot any strangely-looking content on our blog, just let us know. We will happily fix it!
Finally, we migrated our Mastodon/Fediverse account from mastodon.at to chaos.social. Migrating was necessary since the admin of mastodon.at announced the shutdown of mastodon.at in February 2020. Unfortunately, this is the second time we had to change our instance. As a result of the latest migration, nearly 275 followers remained on the old instance, and all of our posts are lost. To avoid such chaos in the future, we are currently investigating different options. However, we can already say that we likely won’t run our Mastodon instance since this would result in significant management overhead. We don’t want to invest our leisure time in managing Mastodon but (partially) in writing new blog articles for you. 😉
Follow us on Mastodon:
November is already over. Our original plan was to update some articles of our Web server security series this month, but there was no time for this left. So we again plan to release some content updates in December.
We will also check our Home network security series and plan future articles for this series.
Other current activities are:
- Verena does some web accessibility checks and will write down suggestions to improve it,
- Benjamin improves our server infrastructure (we will post an article about this), and
- Jakub prepares some new articles on “security myths.”
- RCS attacks: New RCS technology exposes most mobile users to hackingexternal link
- VNC security vulnerabilities: VNC vulnerability researchexternal link
- PDL data leak: Personal And Social Information Of 1.2 Billion People Discovered In Massive Data Leakexternal link
- fscryptexternal link
- Cryptomatorexternal link