en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

March 2021 Security Roundup

Happy Spring to all our readers! Welcome to this March edition of the SSL.com Security Roundup, in which we look back on another month passed in 2021. Specifically, we are looking back at the past month in digital security, and have collected what we consider to be the most newsworthy things in that realm, for you, below.

eSigner offers SSL.com customers a unified platform and UI for cloud document and code signing. Currently in limited beta release. Learn more about eSigner.eSigner

IETF Deprecates TLS 1.0 and 1.1

We’ve known for awhile now that TLS versions 1.0 and 1.1 are insecure. The Internet Engineering Task Force (IETF) just made it official with RFC 8996, which formally deprecates these obsolete TLS versions.

From the abstract:

This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.

SSL.com’s Takeway: Disabling early, insecure versions of SSL and TLS is an important best practice for internet security. If you aren’t sure if TLS 1.0 and 1.1 are still enabled on your servers, now is a great time to check and update your settings if necessary. Check out these resources from SSL.com for more information:

Chrome 90 Will Default to HTTPS

As of version 90, Chrome’s address bar will be using HTTPS as the default protocol. That means that URLs entered without the prefix, as most users tend to do, will get the more secure https:// instead of http://, which was the Chrome default up until this point. The switch has obvious safety implications—HTTPS is more secure and prevents interception and snooping by encrypting traffic. The switch by Chrome also offers a boost in performance in that it eliminates the need for redirection from the previous default to the more-widely used protocol. As reported by the Chromium Blog:

In addition to being a clear security and privacy improvement, this change improves the initial loading speed of sites that support HTTPS, since Chrome will connect directly to the HTTPS endpoint without needing to be redirected from http:// to https://. For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails (including when there are certificate errors, such as name mismatch or untrusted self-signed certificate, or connection errors, such as DNS resolution failure).

Initially, the switch will roll out on Chrome Desktop and Chrome for Android. A switch for Chrome on iOS will follow.

SSL.com’s Takeaway: With most websites now HTTPS enabled, this change in Chrome will increase security and speed for users. Obviously, we co-sign any move that has these goals in mind.

Verkada Hack Exposes 150,000 Security Cameras

In a rather inauspicious start, a Silicon Valley startup known as Verkada suffered a massive security breach. Hackers took control of more than 150,000 cameras located in places like jails, police stations, Tesla factories, hospitals, gyms, and even the offices of the company itself. Why were these cameras in such sensitive locations? Well, because Verkada, unfortunately enough, is a security company. According to an extensive report by Bloomberg’s William Turton, the hackers gained access through a username and password found online for a “Super Admin” account, granting access to the cameras of all of the company’s customers.

That access allowed the intruders to see into hospital rooms, witness interviews between police and criminal suspects, and see who had used access control card in a Tempe hospital. As for the motivation behind the hack, Bloomberg reports:

The data breach was carried out by an international hacker collective and intended to show the pervasiveness of video surveillance and the ease with which systems could be broken into, said Tillie Kottmann, one of the hackers who claimed credit for breaching San Mateo, California-based Verkada. Kottmann, who uses they/them pronouns, previously claimed credit for hacking chipmaker Intel Corp. and carmaker Nissan Motor Co. Kottmann said their reasons for hacking are “lots of curiosity, fighting for freedom of information and against intellectual property, a huge dose of anti-capitalism, a hint of anarchism—and it’s also just too much fun not to do it.”

The hack “exposes just how broadly we’re being surveilled, and how little care is put into at least securing the platforms used to do so, pursuing nothing but profit,” Kottmann said.

Following the incident, Verkada disabled all internal administrator accounts and launched an investigation.

SSL.com’s Takeaway: Steering clear of the overall critique of life in a surveillance society, we’ll focus on the common sense lesson here. Don’t expose login credentials on the Internet, but do consider more secure options like certificate-based authentication too.

Major Security Flaws Found in Netop Vision Software

In scary news for parents just trying to get through the rest of at-home learning, major security vulnerabilities have been found in Netop Vision—a popular virtual learning software used by about 3 million teachers and students. Netop enables at-home learning by serving as a student monitoring system that allows teachers to work remotely on their students’ computers, and is mainly used to manage school computer labs or classrooms. However, because of Covid, students have taken home computers with the software for distance learning, increasing its reach and vulnerability.

Researchers at McAfee announced that they had found four critical flaws in the classroom management software. The flaws could allow attackers to take control of computers, steal credentials or install ransomware. Worryingly, the security issues could also allow hackers to pose as teachers and observe students.

Benjamin Freed at EdScoop reported on the issue in March:

Members of McAfee’s Advanced Threat Research Group tested the Netop program by creating a simulated virtual classroom, with one computer acting as the teacher’s station and three student devices. One of the first things the researchers noticed was that teacher and student user profiles carried different permissions levels. They also quickly spotted that all network traffic between the teacher and students was being sent in unencrypted packets — including screenshots of students’ screens being sent to the teacher — with no option to turn on encryption.

“With this information, the team was able to disguise themselves as a teacher by modifying their code,” the McAfee researchers wrote.

After learning about the attack, the company acted quickly to fix most of the issues. However, the software continues to use unencrypted connections, which is a continued risk.

SSL.com’s Takeaway: This is a good reminder that any software used for remote learning (or remote anything else, really) should use network encryption to prevent eavesdropping or worse.

 

 

Need a Certificate? SSL.com provides a wide variety of digital certificates, including:

COMPARE SSL/TLS CERTIFICATES

Subscribe to SSL.com’s Newsletter

Don’t miss new articles and updates from SSL.com