Chloé Obry Digital Marketing Manager Kassow Robots ApS Tel: +45 61 40 42 81 cob@kassowrobots.com https://www.kassowrobots.com/ > ---------- Forwarded message --------- > De : Support Kassow Robots <su
Simon De Ridder
Simon De Ridder
hello@simonderidder.com
Digital Marketing Manager
Kassow Robots ApS
Tel: +45 61 40 42 81
cob@kassowrobots.com
www.kassowrobots.com/
Petr Kovář
Začátek přeposílané zprávy:
Datum: 23. října 2023 9:42:21 SELČ
Komu: info@kassowrobots.com, adm@kassowrobots.com, support@kassowrobots.com
Předmět: Re: Security Vulnerability Disclosure 01
Hi,
I hope this email finds you well
I am here to talk about my reports which I submitted to you, but got no response regarding them.
It would be much appreciated if you update me, kindly advise on the compensation.
thanks
I'm Danish
I have detected that your website is vulnerable to this vulnerability.
Vulnerability Report 01 : Missing Certificate Authority Authorization Rule
Vulnerable Location : https://caatest.co.uk/kassowrobots.com
Description:
Certificate Authority Authorization (supported by Lets Encrypt and other CAs) allows a domain owner to specify which Certificate Authorities should be allowed to issue certificates for the domain. All CAA-compliant certificate authorities should refuse to issue a certificate unless they are the CA of record for the target site. This helps reduce the threat of a bad guy tricking a Certificate Authority into issuing a phony certificate for your site.
The CAA rule is stored as a DNS resource record of type 257. You can view a domain’s CAA rule using a DNS lookup service:
Proof of concept :
You should set a CAA record to help prevent mis issuance of a certificate for its domains.Impact :
Unfortunately, history has shown that even with periodic security audits and automated controls, cases of certificate “mis-issuance” — when certificates are issued to someone other than the domain owner — do happen. And not only do they happen, but it’s relatively hard to discover these breaches of trust externally.
A recent and very visible case led to Symantec deciding to sell its CA business to DigiCert after Google announced plans to gradually untrust all of its certificates in Chrome until October 2018. Google’s action comes in response to multiple cases of certificate mis-issuance discovered at Symantec or its partners since 2015 and is very significant since Symantec is one of the world’s largest CAs.
While the Symantec incidents had an internal cause and were the result of improper monitoring or failures to enforce existing policies, there have been cases at other CAs in the past where hackers broke in and obtained valid SSL certificates for high-profile domains. In 2011, fraudulent certificates for Google’s domains were obtained from a hacked certificate authority in the Netherlands and were used to launch a large-scale man-in-the-middle traffic interception attack against most internet users in Iran.
That attack was discovered because Chrome has an internal record of Google’s legitimate SSL certificates and reports back to the company if any unauthorized certificate for the company’s services is observed in the wild. There is a similar mechanism called HTTP Public Key Pinning (HPKP) that all website owners can use, but it is hard to implement and can leave websites inaccessible for long periods of time if configured incorrectly.
The Certification Authority Authorization (CAA) is a DNS-based mechanism that allows domain administrators to specify which specific certificate authorities are allowed to issue SSL certificates for their domain names. CAA was standardized in 2013 but didn’t have too much impact until now because CAs were not forced to honor it. That’s no longer the case.
The CA/Browser Forum, an organization that combines major browser vendors and certificate authorities, voted earlier this year to make CAA checking mandatory as part of the certificate issuance process. The CA/Browser Forum maintains the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates,” an industry-accepted set of guidelines that all CAs have to follow.
The CAA requirement goes into effect on September 8 and most certificate authorities have already made changes to their systems in order to be compliant. DNS software and service providers have added support for this record type, but domain owners might want to check if their hosting companies allow adding it.
The CAA DNS record supports three properties: issue, issuewild and iodef. The “issue” and “issuewild” properties allow specifying one or more certificate authorities that are allowed to issue certificates or wildcard certificates for the parent domain. CAs listed under the “issue” property can issue all types of certificates, while those listed under “issuewild” can only issue wildcard certificates.
The “iodef” property is used for reporting purposes and can be very useful. It allows users to specify an email address or hostname where CAs will have to send reports if they receive requests to issue certificates but the domain’s CAA policy doesn’t authorize them. This provides a way for domain owners to learn if someone might try to fraudulently obtain certificates for their domain names.
Of course, if hackers manage to obtain a certificate from a CA authorized by the domain owner, there will be no report. Also, if hackers break into a CA they might be able, depending on what kind of access they gain, to bypass CAA checks entirely. So, CAA with its iodef reporting is not a silver bullet, but it’s better than nothing.
Thank you
Regards:
Danish