Information Security News
Ransomware scammers have been exploiting a flaw in Apple's Mobile Safari browser in a campaign to extort fees from uninformed users. The scammers particularly target those who viewed porn or other controversial content. Apple patched the vulnerability on Monday with the release of iOS version 10.3.
"The attackers effectively used fear as a factor to get what they wanted before the victim realized that there was little actual risk," Lookout researchers Andrew Blaich and Jeremy Richards wrote in Monday's post.
On March 25, security researcher Kevin Beaumont discovered something very unfortunate on Docs.com, Microsoft's free document-sharing site tied to the company's Office 365 service: its homepage had a search bar. That in itself would not have been a problem if Office 2016 and Office 365 users were aware that the documents they were posting were being shared publicly.
Unfortunately, hundreds of them weren't. As described in a Microsoft support document, "with Docs.com, you can create an online portfolio of your expertise, discover, download, or bookmark works from other authors, and build your brand with built-in SEO, analytics, and email and social sharing." But many users used Docs.com to either share documents within their organizations or to pass them to people outside their organizations—unaware that the data was being indexed by search engines.
— Kevin Beaumont (@GossiTheDog) March 25, 2017
Within a few hours, Beaumont, a number of other researchers, and Ars found a significant number of documents shared with sensitive information in them—some of them discoverable by just entering "passwords" or "SSN" or "account number."
Google has long been vocal about Symantecs use of test certificates. Google alleged that Symantec does not provide sufficient controls to prevent an abuse of its widely respected certificate authority. Late last week, Ryan Sleevi who is part of Googles Chrome team, announced that Google Chrome / Chromium will phase out trust in Symantecs CAs, and at the same time, no longer recognize them for Extended Validation. 
Root Certificate Authorities are critical for TLS to work and have been in my opinion the weak point when it comes to TLS security. I have yet to find a public example of a system being compromised because SSL v3 was still enabled on the system. On the other hand, there are plenty of examples of certificate authorities either getting compromised to issue fake certificates, or weaknesses in certificate authorities validation schemes being abused. Symantec is far from the only certificate authority with issues and trust in certificate authorities has been revoked in the past. The most notable recent case was probably WoSign/StartSSL which didnt comply with accepted procedures to issue certificates.
Symantec is a major certificate authority. Ryan states in his post that In January 2015, Symantec-issued certificates represented more than 30% of the valid certificates by volume, and From Mozilla Firefoxs Telemetry, we know that Symantec issued certificates are responsible for 42% of certificate validations. So in short: A lot of sites are using certificates based on Symantecs CA and a lot of people visit sites that use certificates based on Symantecs CA. This is an important issue that will likely have a large impact.
To make things more interesting, Symantec based certificates are also issued by resellers, and it may not always be obvious to buyers that a certificate is based on a Symantec CA. Some of these Sub-CAs, if they are operated independently from Symantec, are not included in this action. The list of Symantec roots affected is quite substantial .
Regardless if we agree or do not agree with Googles action on this, here are some of the issues you need to be aware off:
|Chrome Version||Release Date||Maximum Age||Issued Before|
|59 (dev/beta/stable)||June 6th 2017||33 months||Sept 6th 2014|
|60(dev/beta/stable)||August 1st 2017||27 months||May 1st 2015|
|61(dev/beta/stable)||September 12th 2017||21 months||Dec. 12th 2015|
|62(dev/beta/stable)||October 24th 2017||15 months||July 24th 2016|
|63 (dev/beta)||9 months|
|63(stable)||December 12th 2017||15 months||Sept 12th 2016|
|64 (dev/beta/stable)||January 2018?||9 months||Oct 12th 2016|
These dates may of course change. There is currently no published estimated release date for Chrome 64, so I guessed January 2018 
The most pressing issue right now are Extended Validation certificates. But what you need to do soon (if you dont have it already), is to inventory your certificates by Certificate Authority and time it was issued. The easiest way to do this, in my opinion,is bro. If you have bro running on your network, check the x509 logs for any certificates that may be applicable and extract the issuer and the not valid before date. Keeping track of SSL certificates is a good idea anyway, so this exercise isnt all going to be a waste if Google changes its mind.
If you do come across affected certificates: Contact your issuer, see if they have any options like issuing a new certificate signed by a CA that is not going to be blacklisted by Google.