Banner image of Monthly review – January and February 2020

Monthly review – January and February 2020

Each month, we publish a review that covers the most important activities of the last 30 days. This time, our monthly review actually covers the first two months of 2020. We talk about the 36C3, the end of SHA-1, CRLite in Firefox, the Kr00k attack, and more.

Always stay in the loop!
Subscribe to our RSS/Atom feeds.

News of the month

In January and February 2020, we read the following news:

36C3

The 36th Chaos Communication Congress (36C3) took place in December 2019. In January 2020, recordings of most talks became available. We recommend the following talks if you didn’t watch them so far:

There is also an InfoSec survival guide that could be helpful.

The end of SHA-1

One big (but already expected) story was SHA-1 is a Shambles in January. Researches demonstrated the first chosen-prefix collision for SHA-1, for instance, an impersonation attack using GnuPG and SHA-1.

In summary, don’t use SHA-1 for any cryptographic purposes anymore. Use SHA-2, SHA-3, or Poly1305 if available.

Firefox tries CRLite

In January, Mozilla announced to introduce CRLite in Firefox Nightly. Revocation of digital certificates is still a big problem for today’s internet security. Only a small number of web browsers support standards like OCSP, and each standard comes with disadvantages. On the other hand, traditional Certificate Revocation Lists (CRLs) are too big and too static for reliable revocation information.

CRLite is a new technology proposed by a group of researches in May 2017. Mozilla published several blog articles on Firefox and its experimental use of CRLite. Their results show that CRLite seems to be 99% faster of the time when compared with OCSP so that CRLite might replace OCSP in Firefox in the future.

OpenSSH supports U2F

In February, OpenSSH 8.2 was released. This release introduced support for U2F. For U2F, OpenSSH 8.2 adds new public key types (“ecdsa-sk” and “ed25519-sk”). Furthermore, they removed a key signature algorithm due to the first chosen-prefix collision for SHA-1.

We will update our Web server security series accordingly in early 2020.

Kr00k – a new attack on WPA2

Finally, some researches presented their new Kr00k attack on current WPA2 encryption for Wi-Fi (CVE-2019-15126). Under certain conditions, Wi-Fi chips manufactured by Broadcom and Cypress can be forced to use an all-zero encryption key for WPA2-Personal and WPA2-Enterprise. This attack affects the latest AES-CCMP encryption.

Since an attacker needs to trigger disassociations repeatedly, this attack is very likely detected by the user due to continuously losing the Wi-Fi connection. Network traffic that is already encrypted on higher layers (like TLS or SSH) isn’t affected by this attack.

Some affected devices were Amazon’s Echo (2nd generation), Apple’s iPhone (6, 6S, 8, XR), and the Raspberry Pi 3. If affected, install system updates as soon as possible.

Data breaches and leaks

Moreover, there were some data breaches and leaks. Have I Been Pwned added information about the following breaches and leaks:

  • Universarium (breached in November 2019)
  • Indian Railways (leaked in November 2019)
  • Go Games (breached in October 2015)
  • BtoBet (breached in December 2019)
  • Planet Calypso (breached in July 2019)
  • europa.jobs (breached in August 2019)
  • Tout (breached in September 2014)
  • DailyObjects (breached in January 2018)
  • MGM Resorts (breached before July 2019)
  • Slickwraps (breached in February 2020)
  • Straffic (leaked in February 2020)

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 time, we look at CutyCapt. CutyCapt is a handy tool that uses WebKit’s rendering to store snapshots of websites in different formats (e.g., PNG, JPG, PDF). This tool requires Qt 4.4.0 or higher. It should be available for most operating systems. For instance, on Arch Linux, you find it in the AUR. Kali Linux recently added this tool to their repository.

To store a snapshot of a website, enter cutycapt --url=[a-website] --out=[file.png] in your terminal. For example, the following command stores a snapshot of our blog’s landing page: cutycapt --url=https://infosec-handbook.eu --out=ish-snapshot.png.

You may realize that this snapshot only has a narrow width. You can change the width by setting the --min-width flag. We change the command to: cutycapt --url=https://infosec-handbook.eu --min-width=1200 --out=ish-snapshot.png. Now, the width of the snapshot is at least 1200px.

CutyCapt also supports setting HTTP methods, headers, the user-agent, and zooming. You can even enable and disable JavaScript and Java execution. To see all supported commands, enter cutycapt --help.

Tip of the month

This month’s tip is about detecting report-to and report-uri directives using curl. curl is a popular tool for transferring data using various network protocols. It is a Swiss Army knife, and you likely have curl already installed on your system.

Several HTTP response headers allow server admins to set the (older) report-uri or the (upcoming) report-to (W3C Reporting API) directives. As soon as a web client with support for these directives comes across such headers and produces an event (e.g., violation of the CSP, network-level error), the web client transparently sends data to a (third-party) reporting server (e.g., report-uri.com or uriports.com). This data includes the client’s IP address, User-Agent, and other protocol-/error-specific information. “Transparently” means that network traffic to the reporting server is invisible for most users. They must actively enable the developer options of their web browser or monitor their network traffic with other tools to detect this traffic.

Therefore, you should consider detecting such potential behavior when it comes to privacy and data protection. We suggested such detection for the online assessment tool Webbkoll in October 2019.

At the moment, you can simply detect these directives using curl on your local client. Open your terminal and enter curl -I -Ss [url] | grep report. This command means:

  • -I: Tells curl to only fetch the HTTP header using the HTTP method HEAD.
  • -Ss: Hides the progress meter of curl, but tells curl to print any errors that occur.
  • grep report: Looks at the output and only prints lines that contain “report.”

If you get any output, the web server sets one or both directives. This means that your “normal” web client (e.g., Chrome, Firefox, Safari) may send any error reports to the URL defined by these directives.

If there is no output, the web server didn’t set these directives. So there won’t be any report-to/report-uri data transmissions in the background.

Three examples:

  • curl -I -Ss https://infosec-handbook.eu | grep report: There should be no output since we didn’t set the directives.
  • curl -I -Ss https://scotthelme.co.uk/ | grep report: You should see the Content Security Policy, the Network Error Logging (NEL) header, the X-XSS-Protection header, and the Report-To header. The directives point to report-uri.com, one of the common third-party services that collect such reports.
  • curl -I -Ss https://cyberciti.biz | grep report: You should see the Expect-CT header. This server sends errors related to this header to cloudflare.com.

Several server operators claim that these directives are purely security-relevant and don’t affect privacy at all. However, for us, this is another data transmission. If third parties are involved, the website should mention and explain this in their privacy policy.

Keep in mind that such reports are only sent if there is some kind of violation detected. For example, the web server’s Content Security Policy tells your web browser that the execution of JavaScript is forbidden. If there is JavaScript on the website (either added by the web server itself or injected in your client), your client recognizes the violation and send a report to the specified collector.

Our activities of the last two months

In January and February, we did not publish any articles. For us, 2020 started with a lot of security work (network traffic analysis, redesign, and reconfiguration of production networks, awareness training, further education, and more) in different European countries (Austria, Germany, UK, Czech Republic, Belgium).

Due to this, we had to reduce our activities on our blog. Reduced blog activity also means that we—unfortunately again—have to postpone the significant updates of our Web server security series and Home network security series. However, we documented all planned changes and won’t forget this. There are also many requests by our readers for content to be added so that we won’t die of boredom. 😉

Follow us on Mastodon:
@infosechandbook

Closing words

As mentioned above, we are currently busy. We publish security news in the Fediverse as usual (feel free to subscribe to our RSS/Atom feed, or directly follow us in the Fediverse). We expect to return to a “normal” state in April 2020.