(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Google Android CVE-2016-0833 Unspecified Denial of Service Vulnerability
 
Linux Kernel 'drivers/hid/hid-cp2112.c' Local Denial of Service Vulnerability
 
Linux Kernel 'drivers/net/usb/catc.c' Local Denial of Service Vulnerability
 
Linux Kernel CVE-2007-6761 Local Information Disclosure Vulnerability
 
Oracle PeopleSoft Enterprise SCM eSupplier Connection CVE-2017-3522 Remote Security Vulnerability
 
Oracle Primavera Products CVE-2017-3508 Remote Security Vulnerability
 

Enlarge (credit: Countercept)

After Microsoft officials dismissed evidence that more than 10,000 Windows machines on the Internet were infected by a highly advanced National Security Agency backdoor, private researchers are stepping in to fill the void. The latest example of this open source self-help came on Tuesday with the release of a tool that can remotely uninstall the DoublePulsar implant.

On late Friday afternoon, Microsoft officials issued a one-sentence statement saying that they doubted the accuracy of multiple Internet-wide scans that found anywhere from 30,000 to slightly more than 100,000 infected machines. The statement didn't provide any factual basis for the doubt, and officials have yet to respond on the record to requests on Tuesday for an update. Over the weekend, Below0day released the results of a scan that detected 56,586 infected Windows boxes, an 85-percent jump in the 30,626 infections the security firm found three days earlier.

Both numbers are in the conservative end of widely ranging results from scans independently carried out by other researchers over the past week. On Monday, Rendition Infosec published a blog post saying DoublePulsar infections were on the rise and that company researchers are confident the scan results accurately reflect real-world conditions. Rendition founder Jake Williams told Ars that the number of infected machines is "well over 120k, but that number is a floor."

Read 5 remaining paragraphs | Comments

 
IBM Cúram Social Program Management CVE-2016-9980 Unspecified Cross Site Scripting Vulnerability
 
Portrait Displays SDK CVE-2017-3210 Local Privilege Escalation Vulnerability
 
Adobe Flex BlazeDS CVE-2017-3066 Remote Code Execution Vulnerability
 
Multiple IBM Products CVE-2015-0107 Directory Traversal Vulnerability
 
Linux Kernel 'drivers/net/usb/pegasus.c' Local Denial of Service Vulnerability
 
Adobe ColdFusion CVE-2017-3008 Unspecified Cross Site Scripting Vulnerability
 
Linux Kernel 'drivers/char/virtio_console.c' Local Denial of Service Vulnerability
 
Google Nexus Qualcomm Crypto Engine Driver CVE-2016-10230 Remote Code Execution Vulnerability
 
IBM Security Guardium CVE-2017-1122 Local Command Injection Vulnerability
 
Linux Kernel CVE-2017-8066 Local Denial of Service Vulnerability
 

[This is a guest diary submitted by J. Edward Durrett, GCUX]

While going over an SSL report from SSL Labs [1], I noticed something that I had not seen before: a check for CAA records. Certification Authority Authorization (CAA) is a DNS record which restricts which Certificate Authority can issue a certificate for a given domain [2]. Lets say I get all my Certificates for example.org from Certificate_authority.com. I can specify in my DNS that only Certificates issued by Certificate_authority.com are valid for my domain. This is done with a CAA record, which looks like this in my domains zone le:

example.org. CAA 0 issue certificate_authority.com

CAA support is going to become a mandatory standard in Certificate issuance in September 2017 [2]. That means, in the process of Certificate issuance, it will be mandatory that the the Certificate Authority check for the existence of CAA records for the domains they are issuing Certificates to [3] [4]. Consequently, if you dont have a properly formatted CAA record for your domain, you might not get a Certificate.

Although it remains to be seen how Certificate Authorities implement this standard, failure to have a CAA record for a domain, or having an improperly formatted CAA record, may cause automated Certificate management to fail unexpectedly. This, of course would leave sites with expired/missing Certificates.

For sites running their own DNS, adding a CAA record to the zone is all that is needed. Current versions of BIND, for example, support CAA records so this can be done now. Procedures and scripts for setting up new domains need to be updated to reflect the additional step of adding CAA record before attempting to obtain a Certificate. In addition, in the event of changing Certificate Authorities, the CAA record would also need to be updated to reflect the new issuer.

For organizations that rely on third party DNS providers, the case is different. From a quick search of support pages, I only found a couple that support CAA records [5] [7]. That will probably change as September gets closer, but having a backup plan is never a bad idea.

The best reference document for I found CAA is RFC 6844 DNS Certi cation Authority Authorization (CAA) Resource Record [3]. The example I have above will work for most sites. The structure of a CAA is like this:

FQDN CAA flags property value

There are some things to note. It is possible for a domain to have more than one CAA record:

example.org. CAA 0 issue letsencrypt.org
example.org. CAA 0 issue comodo.com

This would allow a Certificate to be issued from letsencrypt.org or comodo.com. This is useful in cases where the Certificate for the smtp server is issued by letsencrypt.org and the web server uses one from comodo.com.

There are three properties which can be specified issue, issuewild, or iodef [3]. issue means a Certificate Authority is allowed to issue a Certificate for the domain. To completely bar Certificates being issued for a domain, this configuration is possible:

example.org. CAA 0 issue

To only allow wild card Certificates, ones that would match *.example.org, to be issued, the issuewild property is used:

example.org. CAA 0 issuewild certificate_authority.com

For reporting, the iodef property can be specified. This tells the Certificate authority to send a report to either an email or an http/https service [3]:

example.org. CAA 0 issue certificate_authority.com
example.org. CAA 0 iodef mailto:[email protected]
example.org. CAA 0 iodef https://iodef.example.org/

In the above example, Certificate_authority.com can issue a Certificate for example.org and then Certificate_authority.com is directed to send an IODEF incident report to [email protected] and to the web service at https://iodef.example.org.

In all of the configuration examples above the flag is set as 0. Setting the flag to 128 instructs the Certificate Authority that the property is critical [3]. That is, the Certificate Authority must understand the property before issuing a Certificate.

Each Certificate Authority has some ANSWER SECTION: google.com. 86400 IN CAA google.com. 86400 IN CAA

0 issue pki.goog
0 issue symantec.com

86399

IN

TYPE257 \# 19
TYPE257 \# 15

By piping the encoded output through xxd, we can see the property and issuer the record specifies:

$echo 00056973737565706B692E676F6F67 | xxd -r -p
issuepki.goog

The drill utility, found on FreeBSD, does support querying CAA records:

There is also a program written in Go called dnscaa which can be found on GitHub [6].

I searched through several domains looking for CAA records. This was not an exhaustive or scientific search, just a handful of domains. Outside of Certificate Authorities like Comodo and Symantec, Google was the only domain I found with CAA records. Considering that Lets Encrypt alone has issued Certificates for close to 35 Million domains [8], there is likely a significant portion of administrators who have not published CAA records. As issuers reach out to their customers, I would expect to see more records published in the coming months.

The addition of CAA records to DNS and the critical role they will play in Certificate issuance makes an already key part of infrastructure even more valuable. Both the suppression and spofing of records being sent to the Certificate Authorities could result in an attacker obtaining an unauthorized Certificate or causing a denial of service condition [3]. Communicating with Certificate Authorities certainly would justify a method of signing and validating DNS records. Luckily, there already is such a method DNSSEC.

Interestingly, this may ( finally!) encourage the wide spread adoption of DNSSEC. Although RFC 6844, says in section 4.1 the use of DNSSEC is strongly RECOMMENDED but not required, it goes on to say in section 6.4 Where possible, issuers SHOULD perform DNSSEC validation to detect missing or modified CAA record sets. [3]. If deploying DNSSEC is something that you have been putting o for the last 20 years, this might be a good time to revisit.

In conclusion, the CAA record type is relatively new to DNS yet with up to date infrastructure in place it is fairly easy to implement. The lack of CAA support by third party DNS providers might prove challenging for some organizations. As issuers roll out their policies for CAA validation, the impact of RFC 6844 will become clearer. There is plenty of time between now and September to test and adopt procedures for dealing with CAA and its role in Certificate issuance.

J. Edward Durrett, GCUX

[1] https://www.ssllabs.com/ssltest/index.html
[2] https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum [3] https://tools.ietf.org/html/rfc6844
[4] https://cabforum.org/pipermail/public/2017-March/009988.html
[5] https://support.dnsimple.com/articles/caa-record/
[6] https://github.com/weppos/dnscaa
[7] https://cloud.google.com/dns/overview#supported_dns_record_types
[8] https://letsencrypt.org/stats/

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Linux Kernel 'crypto/ccm.c' Local Denial of Service Vulnerability
 
Linux Kernel 'drivers/hid/hid-cp2112.c' Local Denial of Service Vulnerability
 
IBM Cúram Social Program Management CVE-2016-9979 Unspecified Cross Site Scripting Vulnerability
 
IBM Curam Social Program Management CVE-2016-8923 Information Disclosure Vulnerability
 
IBM Curam Social Program Management CVE-2016-9978 Information Disclosure Vulnerability
 
Google Chrome Prior to 50.0.2661.94 Multiple Security Vulnerabilities
 
Red Hat OpenShift Enterprise CVE-2016-5409 Information Disclosure Vulnerability
 
Palo Alto Networks PAN-OS CVE-2017-7216 Information Disclosure Vulnerability
 
WeeChat CVE-2017-8073 Buffer Overflow Vulnerability
 
pcs CVE-2016-0720 Cross Site Request Forgery Vulnerability
 
Linux Kernel CVE-2010-5329 Local Denial of Service Vulnerability
 
KL-001-2017-008 : Solarwinds LEM Management Shell Arbitrary File Read
 
KL-001-2017-007 : Solarwinds LEM Management Shell Escape via Command Injection
 
TP-Link TL-SG108E CVE-2017-8078 Security Bypass Vulnerability
 
TP-Link TL-SG108E CVE-2017-8075 Information Disclosure Vulnerability
 
TP-Link TL-SG108E CVE-2017-8074 Information Disclosure Vulnerability
 
Oracle MySQL Connectors CVE-2017-3586 Remote Security Vulnerability
 
[SECURITY] [DSA 3833-1] libav security update
 
KL-001-2017-009 : Solarwinds LEM Database Listener with Hardcoded Credentials
 
[slackware-security] mozilla-firefox (SSA:2017-112-01)
 
[slackware-security] proftpd (SSA:2017-112-03)
 
[slackware-security] ntp (SSA:2017-112-02)
 
CVE-2017-5887: Starscream library before 2.0.4 SSL pinning not applied for websocket handshake
 
Authentication bypass vulnerability in Western Digital My Cloud allows escalation to admin privileges
 
Oracle Solaris CVE-2017-3623 Remote Security Vulnerability
 
Oracle E-Business Suite CVE-2017-3592 Remote Security Vulnerability
 
Internet Storm Center Infocon Status