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