Containers, Kubernetes, and Red Hat OpenShift Administration I

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:

• Introduction to container technology
• Create containerized services
• Manage containers
• Manage container images lifecycle
• Create custom container images
• Deploy containerized applications on OpenShift
• Deploy multicontainer applications
• Explore Red Hat OpenShift Container Platform
• Verify the health of a cluster
• Configure authentication and authorization
• Configuring application security
• Configure OpenShift networking for applications
• Control pod scheduling
• Scale an OpenShift cluster
• Describe cluster updates
• Manage a cluster with the web console
• Execute a comprehensive review
  

CVE ⊂ Vuln

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 != Risk

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)

Why a CVSS score is not the same as risk?

Because a CVSS score only helps describe the severity of a vulnerability (CVE) from a technical perspective. 

Then what is a CVSS score?

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)

If CVSS != Risk, then why people using it to manage risk?

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)

So, what's wrong with CVSS score as risk management?

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.

1. Lack of asset priority.
2. Only applicable for known vulnerabilities.
3. Waste of vulnerability remediation effort.
4. Not accounting for those compensating controls.

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:

•  What You Miss When You Rely on CVSS Scores | Kenna Security
•  A Vulnerability Score On Its Own Is Useless | Kenna Security

CWE/SANS TOP 25 Most Dangerous Software Errors

Below are the list of CWE released by SANS (Jun 27, 2011) to help eliminate the top 25 software errors.

The CWE Top 25 

Rank	ID	Name
1	CWE-119	Improper Restriction of Operations within the Bounds of a Memory Buffer
2	CWE-79	Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
3	CWE-20	Improper Input Validation
4	CWE-200	Information Exposure
5	CWE-125	Out-of-bounds Read
6	CWE-89	Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
7	CWE-416	Use After Free
8	CWE-190	Integer Overflow or Wraparound
9	CWE-352	Cross-Site Request Forgery (CSRF)
10	CWE-22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
11	CWE-78	Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
12	CWE-787	Out-of-bounds Write
13	CWE-287	Improper Authentication
14	CWE-476	NULL Pointer Dereference
15	CWE-732	Incorrect Permission Assignment for Critical Resource
16	CWE-434	Unrestricted Upload of File with Dangerous Type
17	CWE-611	Improper Restriction of XML External Entity Reference
18	CWE-94	Improper Control of Generation of Code ('Code Injection')
19	CWE-798	Use of Hard-coded Credentials
20	CWE-400	Uncontrolled Resource Consumption
21	CWE-772	Missing Release of Resource after Effective Lifetime
22	CWE-426	Untrusted Search Path
23	CWE-502	Deserialization of Untrusted Data
24	CWE-269	Improper Privilege Management
25	CWE-295	Improper Certificate Validation

Links:

• Top 25 Software Errors | SANS Institute

Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques

Completed my training on SEC642 today.

This onDemand training begin by exploring some advanced techniques and attacks to which all modern applications' vulnerabilities, such as new web frameworks, encryption and cryptography, alternate web front ends on mobile apps, HTTP/2 and websocket.

Syllabus:

1. SEC642.1: Advanced Attacks
2. SEC642.2: Web Cryptography
3. SEC642.3: Alternative Interfaces and XML
4. SEC642.4: Modern Web Frameworks, Part 1
5. SEC642.5: Modern Web Frameworks, Part II 

Link: Advanced Web Application Penetration Testing and Exploitation | SANS SEC642

How to Simplify Cybersecurity?

We already knew that complexity is the enemy for Cybersecurity. As the threat environment has gotten more sophisticated, it is very likely those (sophisticated) organization responded to new threat by adding new tools to their security stack.

I always believe that "less is more" is also applicable in Cybersecurity world. With all these new challenging threats nowadays, we as the Cybersecurity leaders should take control of the tools/environment, and reducing complexity by leveraging fewer tools, so it can be more efficient and effective at their daily uses.

But how can we do it? 

Based on my 13 years experience, it is possible with the correct approach and people. Here are my recommendations:

1. Automation 
• Try to automate any process, especially those repetitious process like vulnerability remediation, whenever possible.
  
2. Integration (but not consolidation)
•  Don't consolidate the tools as "defense in depth" still applicable in Cybersecurity.
• Use JSON/XML to integrate the tools for measuring any metrics.
  
3. Orchestration
•  Invest in centralized logging SIEM helps orchestrate and streamline the workflow.
  
4. Using cloud for the cloud
• Invest in modern cloud tools rather than using the traditional tool to manage the cloud.
• Then integrate both the new and old tools.
5. Public Relationship Education
• Invest a strong team that can help to communicate security updates and building the trusts with other organizations.
• The team can also provide education for others and set as single channel for communication.
  

With all the modern infrastructure, like mobile apps, IoT, hybrid clouds and DevOps being added to our operating environment, we still need to ensure Cybersecurity can grow faster and work smarter. The answer to this is Simplify Cybersecurity.  And the key to Simplify Cybersecurity is to take a "less is more" approach. 

Keep in mind that simplicity is the ultimate sophistication.

Who should be driving Simplify Cybersecurity ?

Following from the previous Simplify Cybersecurity posts, I'll should you in more details what is Simplify Cybersecurity.

Imagine, your company is entering the digital transformation for IT organization, and you need to transform the Cybersecurity organization too.

By following Simplify Cybersecurity principle, it is very easy to "transform" the Cybersecurity organization.

Even by entering the cloud world, the Cybersecurity core functions haven't changed much. It is still required to Identify, Protect, Detect, Respond, and Recover. The only thing question is, who should be leading the work.

Depends on which stage or which generation of Cybersecurity org is, all you need to do is expand the size/budget of the driving team. For example, nowadays, many company are entering cloud world. And by based on the generation in Simplify Security Stage article, it should be the IAM team that drive the Cybersecurity transformation, and help the whole organization get ready for cloud-based security. 

Many company makes a mistake by forming new team, like cloud security team, to get prepare for company to enter the cloud world. And this is where the Cybersecurity start to get sophisticated. IMO, the CISO may simply have no idea what should be the driving factor in different stage/generation.

CVE-2018-1002105 PoC

In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.

There are 2 POC been released for CVE-2018-1002105.

Authenticated PoC

Proof-of-Concept exploit for CVE-2018-1002105. The current exploit requires create and get privileges on pods and pods/exec. Support has been added for portforward and attach, which require similar permissions.

The current PoC dumps the secrets from the default etcd-kubernetes pod. 

Unauthenticated PoC

The unauthenticated PoC allows privilege escalation within the context of the exposed API. Depending on the functionalities of the API it might be possible to get code execution on pods. This demo currently exploits the bug to gain cluster-admin rights on the servicecatalog.k8s.io API. This exploit should also work for metrics.k8s.io or any API exposed through the aggregated layer.

Links:

• https://github.com/evict/poc_CVE-2018-1002105