I've been using KennaSecurity for one year. Then I found that something strange with KennaSecurity GUI.
When you try to list users in Kenna, you can't find yourself in the list even you are administrator.
Thus, I create a simple ruby script that help me to list all the users, including myself. ;)
Here, I collected some essential commands for OpenSSL.
Check the Connection:
$ openssl s_client -showcerts -connect www.microsoft.com:443
Decoding BASE64 (PEM) Certificate
Capture the output between “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” tags, and save as a text file (i.e. cert_microsoft.com).
Run the command below to read the file, and display it in a textual format.
$ openssl x509 -noout -text -in cert_microsoft.com
Decoding Binary Certificate (DER) Certificate
DER is a binary certificate format and the content is the same as PEM (Base64).
$ openssl x509 -noout -text -inform der -in cert_microsoft.der
Convert Certificate between DER and PEM format
By the way, -inform is short for “input format”
$ openssl x509 -inform der -in cert_microsoft.der -out cert_microsoft.pem
$ openssl x509 -inform der -in cert_mirosoft.der -outform pem -out cert_microsoft.pem
$ openssl x509 -in cert_microsoft.pem -outform der -out cert_microsoft.der
$ openssl x509 -inform pem -in cert_microsoft.pem -outform der -out cert_microsoft.der
Checking the Chain of Trust
$ openssl verify -verbose cert_microsoft.pem
If you see "Error 20 at 0 depth lookup", it means that the intermediate certificate (or certificate for the Issuer of the server certificate) is missing.
$ openssl verify -untrusted cert_symantec cert_microsoft.pem
If you see "Error 20 at 1 depth lookup", it means the error is no longer on the server certificate (0 depth) but now can't find the issuer certificate for the Symantec cert.
$ openssl verify -untrusted cert_symantec -CAfile ./RootCerts.pem cert_microsoft.pem
You should see everything is "OK" now.
If you have more than 1 intermediate certificate, just concatenate both certs into one.
$ cat inter1.pem inter2.pem > inter_both.pem
Testing SSLv2/SSLv3/TLSv1/TLSv1.1/TLSv1.2/TLSv1.3
$ openssl s_client -ssl2 -connect microsoft.com:443
$ openssl s_client -ssl3 -connect microsoft.com:443
$ openssl s_client -tls1 -connect microsoft.com:443
$ openssl s_client -tls1_1 -connect microsoft.com:443
$ openssl s_client -tls1_2 -connect microsoft.com:443
$ openssl s_client -tls1_3 -connect microsoft.com:443
$ openssl s_client [-no_ssl3, -no_tls1, -no_tls1_1, -no_tls1_2, -no_tls1_3] -connect microsoft.com:443
Get the Common Name (cn) or Subject
$ openssl x509 -noout -subject -in cert_microsoft.pem
Renegotiation (by client)
$ openssl s_client -connect www.microsoft.com:443
HEAD / HTTP/1.0
R
<CRLF>
Testing Weak Ciphers
$ openssl s_client -cipher NULL,EXPORT,LOW,3DES -connect <site:port>Testing NULL Cipher
$ openssl s_client -cipher aNULL -connect <site:port>Forward Secrecy
Testing RC4 ciphers
$ openssl s_client -cipher RC4 -connect <site:port>Testing Compression (CRIME/TLS or BREACH/HTTP)
"Compression: zlib compression" and "Compression: 1 (zlib compression)"
indicate that the remote server is vulnerable to the CRIME attack. "Compression: NONE" means not vulnerable to TLS compression.
$ openssl s_client -connect <site:port>
GET / HTTP/1.1 Host: example.com Accept-Encoding: compress, gzip
<CRLF><CRLF> If the response contains encoded data, it indicates that HTTP compression is supported; therefore the remote host is vulnerable (to BREACH).
Today, just completed the training on [DO285] "Containers, Kubernetes, and Red Hat OpenShift Administration I" (Oct 21~25).
The training helps me to build the skills on building local containers, establishing the health of a new OpenShift cluster, and managing access to cluster. One major focus is to troubleshoot the common problems beside configuring the Red Hat OpenShift Container Platform cluster.
The outline for the course:
CVEs are not the ONLY vulnerabilities. In another words, CVE is a subset of vulnerabilities.
CVE stands for Common Vulnerabilities and Exposure. It is used to track security vulnerability. It has the format of CVE-YYYY-XXXXXXX, where YYYY denotes the year, and XXXXXXX is the tracking number.
By definition, a CVE is always equal to a vulnerability. But not every vulnerability has a CVE number.
For example, password configuration, such as password policy (length, complexity, renewal) has no CVE number assigned but is considered as vulnerability.
Next, mis-configurations, such as default admin credential or well-known login/password, and those ICMP configuration that leak system information, has no CVE number too. But those are always been highlighted by any vulnerability scanning tools.
Weak encryption (can is a kind of mis-configuration) can lead to disclosure of sensitive information, has not been assigned to any CVE number too.
CVSS does not equal risk; CVSS does not equal risk; CVSS does not equal risk. (We should always repeat at least 3 times for an important thing)
Surprisingly nowadays, there are still Cybersecurity people managing vulnerabilities based on CVSS score, and claim that they are doing risk management. (don't laugh, check with your CISO)
Because a CVSS score only helps describe the severity of a vulnerability (CVE) from a technical perspective.
CVSS stands for Common Vulnerability Scoring System. There are 2 versions of CVSS: CVSS 2.0 and CVSS 3.1. CVSS has 3 metric groups: Base Score, Temporal Score, and Environment Score. Each metric group has own set of metric names.
There is a CVSS Scoring calculator at Common Vulnerability Scoring System Version 3.1 Calculator (first.org)
Here's a sample of CVSS score: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N
And it is common for only the CVSS Base Score to be used to prioritize how quickly those Cybersecurity team are responding to a new vulnerability.
(Ask your Cybersecurity team when is the last time they are looking at the Temporal and environment scores)
IMO, it is not their fault. This is all due to regulatory bodies have built CVSS scores into their compliance schemes, and require remediation of all vulnerabilities above certain Base CVSS score in order to remain compliant. (Yes, I'm talking about PCI-DSS)
First, CVSS score does not take into account the importance of asset. A same vulnerability should have different priority between a domain controller server and a workstation.
Secondly, not all vulnerability has CVE and CVSS score. There are may vulnerabilities go far beyond CVE/CVSS. If a vulnerability without an assigned CVE/CVSS, does it mean you can skip the remediation?
Third and I think this is most important. Not every vulnerability is exploitable. Instead of remediating all vulnerabilities based on CVSS score, we should focus on those high/critical and exploitable vulnerabilities. Remediation based on CVSS score is not only unfeasible, it is also take up a lot of resource and probably still an unachievable goal. (remember 80/20 rules)
Forth. The CVSS score provides no accounting for other compensating controls, like firewall and antivirus, and thus it doesn't reflect the actual situation.
In summary, CVSS != Risk, simply because of the following reasons.
Unlike CVSS and other static scoring methods, KennaSecurity provides the context required to understand the true level of risk that vulnerabilites pose to an organization, using a risk score. The purpose of the score is to provide Cybersecurity, IT and infrastructure teams with an understanding of the relative urgency of the vulnerability so that everyone can prioritize the remediation efforts of some over others based on real-world exploitability.
References: