Security News Chum: Browsers, Berkeley, Ransom and Requests

userpic=cardboard-safeReady for the third course of news chum? This part of the meal is a collection of articles related to cybersecurity:

  • Help! I’m DROWNing. This week, researchers announced yet another attack against TLS, the protocols used to secure the traffic that you see as HTTPS://. More than 11 million websites and e-mail services protected by the TLS protocol are vulnerable to this low-cost attack that decrypts sensitive communications in a matter of hours and in some cases almost immediately. The attack works against TLS-protected communications that rely on the RSA cryptosystem when the key is exposed even indirectly through SSLv2, a TLS precursor that was retired almost two decades ago because of crippling weaknesses. The vulnerability allows an attacker to decrypt an intercepted TLS connection by repeatedly using SSLv2 to make connections to a server. In the process, the attacker learns a few bits of information about the encryption key each time. While many security experts believed the removal of SSLv2 support from browser and e-mail clients prevented abuse of the legacy protocol, some misconfigured TLS implementations still tacitly support the legacy protocol when an end-user computer specifically requests its use. The most notable implementation subject to such fatal misconfigurations is the OpenSSL cryptographic library.
  • More Exposure at Berkeley. No, I’m not talking exposure of a student body, but exposure of the student body. The University of California, Berkeley, has admitted to a second data breach which may have exposed the data of 80,000 people to misuse. Current and former students, faculty members and vendors linked to the university are among those who have been warned about the incident, which took place through financial management software which contained a security flaw, allowing an attacker — or group — to access internal services. In total, 57,000 current and former students, including student workers, 10,300 vendors and others — at a ratio of roughly 50 percent of current students and 65 percent of active employees — could have had their information taken.
  • Dealing with Ransomware. Our biggest worry used to be viruses. Those were the days. Today, the big fear is ransomware — malware you get by a drive-by-download or clicking on a bad link in an email. These attacks encrypt the data on your computer and require you to pay a ransom if you want to have any hope of decrypting it. Here’s a reasonably good PCWORLD article with somethings you can do to prevent attacks. As usual, it boils down to the 4 “E”s: Use the engineering in your system to stop attacks by having a good always-on malware and dangerous site scanner; have usage policies and enforce them about not clicking on links, using non administrative accounts, etc.; educate your users on what to look for, and what not to do; and plan for emergency services by having a external disk backup that is not always connected using a reliable back tool.
  • Dealing with Requests. This article from ComputerWorld explains what really is at risk in the Apple vs FBI fight. The issue is not encryption or encryption backdoors. The FBI is not trying to break the encryption on the phone. They are trying to unlock the phone, which will decrypt it. To find that key they need to do a brute force attack; to do that attack, they can’t have the system wipe the phone after 10 failures. So what they want Apple to do is put up a special signed software update that the phone will automatically install that will remove the limit. In other words, this request is to force Apple to put up an untrustworthy software update that weakens the phone. That’s the precedent that Apple does not want to set. In particular, such an update can’t be limited to just one phone, and if a faked update can get out, then the entire spider-web of automatic software updates becomes untrustworthy. If it becomes untrustworthy, people won’t automatically install updates, and that will result in known holes being unpatched, which means weaker systems.

 

Share