Banner image of Monthly review – November 2019

Each month, we publish a review that covers the most important activities of the last 30 days. This month, we talk about attacks on RCS, security vulnerabilities in VNC software, a huge 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 remotely control other computers. 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.

Huge data leak

Finally, Data Viper, a threat intelligence platform, released a report about a huge 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

Check if you were affected, and change your credentials. Besides, feel free to subscribe to our RSS/Atom feed, or directly follow us in the Fediverse to learn about data breaches and much more.

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

Prerequirements 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 actually 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 getconf PAGE_SIZE and 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 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.

Afterwards, 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 complex, however, we won't cover this in detail.)

Let's tell fscrypt to use “A custom passphrase” here. Assign a name, and then enter and confirm your password. The final output should be something like “is now encrypted, unlocked, and ready for use.”

Enter 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 important 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 (like suggested above).

During normal 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, Keybase, Mastodon (Fediverse), Threema, 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?”

The problem are internal services unknowingly exposed to the internet. This isn't unique to Elasticsearch. Other examples are exposed IP cameras (see “Christmas holidays: more exposed IP cameras will go online within the next few days” and “Hi, I'm your insecure IP camera, broadcasting your life 24/7”), PLCs in industrial environments, and office printers. Regularly scan your own public and private IP address ranges to detect open ports and services, and apply common security practices. Never just assume something is configured – actually 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 really doesn't track you. You always must trust the statements of the provider. The most important feature of a search engine is likely to actually find what you are looking for. Some people say that meta search engines like MetaGer or SearX are good for them while others say they can't find anything anymore. Others like to use DuckDuckGo or Startpage. So we can't recommend anything special here.

Just send us your questions. Maybe, your question will be listed in the next monthly review.

Our activities of the month

In November, we published one new tutorial:

Besides, we changed several things on our blog:

  • We updated our policies (privacy policy, security/disclosure policy) to improve readability and to provide more details.
  • We centralized Git pushes to codeberg.org. Due to this, we are able to 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 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 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. This 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 own Mastodon instance since this would result in a huge 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:
@infosechandbook

Closing words

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

See also