Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

HTTPS uses TLS (Transport Layer Security) to encrypt regular HTTP requests and responses. It guarantees the integrity and confidentiality of any data exchange.

An HTTP Listener Connector does not encrypt its communication if its protocol is unspecified or set to HTTP. This exposes the data to unauthorized access, tampering, and potential theft.

Example 1: The following Mule configuration sets the protocol of an HTTP Listener Connector (listener-connection) to HTTP. As a result, connections to the HTTP Listener are insecure.

    <http:listener-config name="http_listener_config">
        <http:listener-connection host="example.com" port="8080" protocol="HTTP">
...
        </http:listener-connection>
    </http:listener-config>

Kubernetes keeps sensitive data in an etcd cluster. Every etcd instance must serve clients over TLS connections but the command-line flags for setting up the TLS connections are missing.

Example 1: The following configuration starts an etcd instance without specifying both the --cert-file and --key-file flags for setting up TLS connections.

apiVersion: v1
spec:
  containers:
    - command:
      - etcd
      - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
  ...

Kubernetes keeps sensitive data in an etcd cluster. Every etcd instance in a cluster should always communicate with peers over a TLS connection but the command-line flags for setting up the TLS connection are missing.

Example 1: The following configuration starts an etcd instance without specifying both the --peer-cert-file and --peer-key-file flags for setting up a TLS connection.

apiVersion: v1
spec:
  containers:
    - command:
      - etcd
      - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
...

Hardcoding a password allows all project developers to view the password. It also makes fixing the problem difficult. After the code is in production, no one can change the password without patching the software. If the account protected by the password is compromised, the system's owners must choose between security and availability.

The tlsCertFile and tlsPrivateKeyFile fields in a Kubelet configuration define the x509 certificate used to serve HTTPS. By failing to provide both of them, a self-signed certificate and key are generated for the public address, which is susceptible to a man-in-the-middle attack.

Example 1: The following Kubelet configuration does not specify the tlsCertFile and tlsPrivateKeyFile fields so the Kubelet automatically generates a self-signed certificate for TLS connections.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration

By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when deciding who can influence the settings because an overly permissive cross-domain policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay, and other attacks. Policy restrictions bypass vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is used to load or modify cross-domain policy settings.
Example 1: The following code uses the value of one of the parameters to the loaded SWF file as the URL to load the cross-domain policy file from.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   flash.system.Security.loadPolicyFile(url);
   ...

Example 2: The following code uses the value of one of the parameters to the loaded SWF file to define the list of trusted domains.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var domain:String = String(params["domain"]);
   flash.system.Security.allowDomain(domain);
   ...

The lack of a PodSecurityPolicy admission controller is indicative of weak security controls unless there is an alternative policy enforcement tool for Kubernetes such as K-Rail, Kyverno, OPA/Gatekeeper. The PodSecurityPolicy admission controller enforces Pod security policies that specify permissible security-related Pod attributes in a cluster. For instance, using PodSecurityPolicy, you can forbid privileged containers and disallow privilege escalation by default whenever a Pod is created.

Example 1: The following Pod definition starts a Kubernetes API server without enabling the PodSecurityPolicy admission controller.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=NodeRestriction
    ...

Most web applications use a session identifier to uniquely identify users, which is typically stored in a cookie and transmitted transparently between the server and the web browser.


Applications that do not store session identifiers in cookies sometimes transmit them as an HTTP request parameter or as part of the URL. Accepting session identifiers specified in URLs makes it easy for attackers to perform Session Fixation attacks.

Placing session identifiers in URLs can also increase the chances of successful Session Hijacking attacks against the application. Session Hijacking occurs when an attacker takes control of a victim's active session or session identifier. It is common practice for web servers, application servers, and web proxies to store requested URLs. If session identifiers are included in URLs, they are also logged. Increasing the number of places session identifiers are viewed and stored increases the chances they will be compromised by an attacker.

The FormsAuthentication.RedirectFromLoginPage() method issues an authentication ticket, which allows users to remain authenticated for a specified period of time. When the method is invoked with the second argument false, it issues a temporary authentication ticket that remains valid for a period of time configured in web.config. When invoked with the second argument true, the method issues a persistent authentication ticket. On .NET 2.0, the lifetime of the persistent ticket respects the value in web.config, but on .NET 1.1, the persistent authentication ticket has a ridiculously long default lifetime -- fifty years.

Allowing persistent authentication tickets to survive for a long period of time leaves users and the system vulnerable in the following ways:

It expands the period of exposure to session hijacking attacks for users who fail to log out.

It increases the average number of valid session identifiers available for an attacker to guess.

It lengthens the duration of exploit when an attacker succeeds in hijacking a user's session.

The WebLogic deployment descriptor should specify a session identifier length of at least 24 bytes. A shorter session identifier leaves the application open to brute-force session guessing attacks. If an attacker can guess an authenticated user's session identifier, he can take over the user's session. The remainder of this explanation will detail a back-of-the-envelope justification for a 24-byte session identifier.

The session identifier is composed of a pseudorandom selection of the 62 alphanumeric characters, which means that if the string were composed in a truly random fashion each byte could yield a maximum of 6 bits of entropy.

The expected number of seconds required to guess a valid session identifier is given by the equation:

(2^B+1) / (2*A*S)

Where:

- B is the number of bits of entropy in the session identifier.

- A is the number of guesses an attacker may try each second.

- S is the number of valid session identifiers that are valid and available to be guessed at any given time.

The number of bits of entropy in the session identifier is always less than the total number of bits in the session identifier. For example, if session identifiers were provided in ascending order, there would be close to zero bits of entropy in the session identifier no matter the identifier's length. Assuming that the session identifiers are being generated using a good source of random numbers, we will estimate the number of bits of entropy in a session identifier to be half the total number of bits in the session identifier. For realistic identifier lengths this is possible, though perhaps optimistic.

If attackers use a botnet with hundreds or thousands of drone computers, it is reasonable to assume that they could attempt tens of thousands of guesses per second. If the web site in question is large and popular, a high volume of guessing might go unnoticed for some time.

A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short inactive session timeout.)

With a 64-bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker may try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes.

Now assume a 128-bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.

Working backwards from bits to bytes, now, the session identifier must be 128/6, which yields approximately 21 bytes. Furthermore, empirical testing has demonstrated that the first three bytes of the session identifier do not appear to be randomly generated, which means to achieve our desired 64 bits of entropy we need to configure WebLogic to use a session identifier 24 bytes in length.

Kubernetes keeps sensitive data in an etcd cluster. An etcd instance accepts connections from clients without certificates signed by trusted certificate authorities because the command to start the etcd with the --client-cert-auth flag is set to false.

Example 1: The following configuration starts an etcd instance and sets the --client-cert-auth flag to false.

...
spec:
  containers:
    - command:
  ...
      - etcd
  ...
      --client-cert-auth=false
  ...

The deletion of Kubernetes namespace removes all objects in that namespace, including Pods and services. The NamespaceLifecycle admission controller maintains the integrity of Kubernetes systems in two ways. First, it prevents objects from being created in non-existent namespaces or in namespaces undergoing termination. Second, it prevents system reserved namespaces, which contain Kubernetes critical services, from being deleted.

The NamespaceLifecycle admission controller is enabled by default but the command to start the Kubernetes API server has disabled it with the --disable-admission-plugin flag.

Example 1: The following configuration starts a Kubernetes API server. The presence of the NamespaceLifecycle included in the --disable-admission-plugins flag disables the NamespaceLifecycle admission controller.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --disable-admission-plugins=...,NamespaceLifecycle,...
    ...

Kubernetes keeps sensitive data in an etcd cluster. Therefore, every etcd instance should only accept connections from authenticated and authorized peers and reject any peers that use self-signed certificates for TLS connections.

Example 1: The following configuration starts an etcd instance and sets the --peer-auto-tls flag to true. As a result, the etcd instance uses self-signed certificates for TLS connections with peers.

	...
	spec:
	containers:
	- command:
	...
	- etcd
	...
	- --peer-auto-tls=true
	...

Unless otherwise specified, any newly created Pod is automatically assigned a default service account. For each service account, an API access token is automatically generated and made available in a mounted directory. Attackers can use the access token in any compromised Container to gain access to insufficiently protected and security-sensitive service APIs.

The automounting of API credentials for the default service account of a Pod is not disabled because automountServiceAccountToken is not defined or the configuration of the default service account contains the automountServiceAccountToken: true setting.

Example 1: API credentials for the default service account of a Pod are automounted if the automountServiceAccountToken is not defined or is set to true, as in this example.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: demo-namespace
automountServiceAccountToken: true
...

Example 2: API credentials are automounted for a Pod because there is an automountServiceAccountToken: true setting in the default service account as in this example.

apiVersion: v1
kind: Pod
  ...
spec:
  automountServiceAccountToken: true
  ...

The Kubernetes controller manager starts without the --root-ca-file flag, which specifies a root Certification Authority (CA) file. As a result, the Kubernetes controller manager does not publish a corresponding root CA certificate to Pods. Without the root CA certificate, the Pods cannot verify the API server's serving certificate before establishing connections. Such connections are susceptible to a man-in-the-middle attack.

Example 1: The following configuration starts a Kubernetes controller manager without the --root-ca-file flag.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-controller-manager
    image: k8s.gcr.io/kube-controller-manager:v1.9.7
    imagePullPolicy: IfNotPresent
      ...

A Kubernetes API server sends instructions to Kubelets to create workload, queries status of Kubelet-managed resources, and provides optional port-forwarding services to Kubelets. By default, the API server does not verify a Kubelet's serving certificate before establishing connection. This connection is therefore susceptible to a man-in-the-middle attack.

Example 1: The following command starts a Kubernetes API server without specifying a root certificate bundle to verify the Kubelet's serving certificate with the --kubelet-certificate-authority flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-maxage=50
    - --audit-log-maxbackup=20
    - --audit-log-maxsize=200
  image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
    ...