(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 

(credit: Lookout)

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 flaw involved the way that Safari displayed JavaScript pop-up windows. In a blog post published Monday afternoon, researchers from mobile-security provider Lookout described how exploit code surreptitiously planted on multiple websites caused an endless loop of windows to be displayed in a way that prevented the browser from being used. The attacker websites posed as law-enforcement actions and falsely claimed that the only way users could regain use of their browser was to pay a fine in the form of an iTunes gift card code to be delivered by text message. In fact, recovering from the pop-up loop was as easy as going into the device settings and clearing the browser cache. This simple fix was possibly lost on some uninformed targets who were too uncomfortable to ask for outside help.

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

Read 3 remaining paragraphs | Comments

 
Schneider Electric VAMPSET Local Memory Corruption Vulnerability
 
WordPress recent-backups Plugin 'download-file.php' Arbitrary File Download Vulnerability
 
ZoneMinder CVE-2016-10203 Cross Site Scripting Vulnerability
 
Apple iOS/Mac CVE-2017-2391 Information Disclosure Vulnerability
 
 
APPLE-SA-2017-03-27-1 Pages 6.1, Numbers 4.1, and Keynote 7.1 for Mac; Pages 3.1, Numbers 3.1, and Keynote 3.1 for iOS
 
WordPress YOP Poll Plugin CVE-2017-2127 Unspecified Cross Site Scripting Vulnerability
 
LibTIFF 'libtiff/tif_ojpeg.c' Divide By Zero Denial of Service Vulnerability
 
EyesOfNetwork CVE-2017-6087 Multiple Arbitrary Code Execution Vulnerabilities
 
LibTIFF 'libtiff/tif_read.c' Divide By Zero Denial of Service Vulnerability
 
MuPDF CVE-2017-7264 Use After Free Denial of Service Vulnerability
 
WordPress Filedownload Plugin CVE-2015-1000003 SQL Injection Vulnerability
 

Enlarge

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.

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

Read 9 remaining paragraphs | Comments

 
Linux Kernel CVE-2010-5328 Local Denial of Service Vulnerability
 
GOsa CVE-2014-9760 Cross Site Scripting Vulnerability
 
Node.js CVE-2014-9772 Cross Site Scripting Vulnerability
 
AMD Ryzen Processor CVE-2017-7262 Local Denial of Service Vulnerability
 

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. [1]

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 [2].

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:

  1. Right now, this is just a proposal. Nothing has been implemented yet, and Google may change its mind, or change its schedule.
  2. This issue will only affect Google Chrome users. Google Chrome is by some counts currently the most commonly used browser. But it will only affect HTTP(S), not other services like imapthat are not supported by Chrome. It will also not affect internal web services that are not used by browsers.
  3. The most pressing issue right now are Extended Validation certificates. Google proposes to no longer indicate that a certificateis an Extended Validation certificate. Users will not see the green URL bar and may not see the companys name in the URL bar. The certificate will however be considered valid. This is likely going to confuse some security minded users, but for the most part, users are likely going to ignore this issue or not notice it at all.
  4. For all other certificates, Google proposes an elaborate phase-out plan. The phase out plan is based on Google Chrome versions, not on specific dates. In each release, certificates that exceed a certain age, will no longer be trusted.
    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 [3]

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.

[1]https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs
[2] https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/roots
[3]https://www.chromium.org/developers/calendar

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Logsign Remote Command Injection Vulnerability
 
EyesOfNetwork CVE-2017-6088 Multiple SQL Injection Vulnerabilities
 
Apple macOS CVE-2016-4617 Multiple Security Bypass Vulnerabilities
 
Google Android NFC CVE-2017-0481 Remote Privilege Escalation Vulnerability
 
Miele Professional PG 8528 CVE-2017-7240 Directory Traversal Vulnerability
 
IBM Kenexa LCMS Premier CVE-2017-1142 Man in the Middle Information Disclosure Vulnerability
 
IBM Kenexa LCMS Premier CVE-2017-1143 Man in the Middle Information Disclosure Vulnerability
 
[SECURITY] [DSA 3817-1] jbig2dec security update
 
Internet Storm Center Infocon Status