Welcome to Scaleway's Trust Center. We strive to include security in each and every aspect of our business. You will find in this Trust Center information and documentation to attest our actions towards delivering a safe and secure Cloud service.
Bienvenue sur le Trust Center de Scaleway. Nous nous efforçons d'inclure la sécurité dans tous les aspects de notre activité. Vous trouverez dans ce Trust Center des informations et de la documentation qui attestent des actions entreprises pour garantir la sécurité de nos services.
We may provide security-related reports upon request.
Definition
CVE-2024-47076, CVE-2024-47175, CVE-2024-47176 and CVE-2024-47177 are vulnerabilities affecting CUPS.
Those vulnerabilities allow an attacker to create a malicious printer, attach it to a CUPS server without any authentication, and execute remote commands on that server.
How it works
CUPS is vulnerable only when cups-browsed is enabled.
In that situation the port 631 is left opened, giving access to attackers to a vulnerable server that allows unrestricted access such as the public internet or an internal network where local connections are trusted.
Via an UDP-based protocol, an attacker can advertise a malicious IPP (Internet Printing Protocol) and thereby set up a malicious (virtual) printer. If a victim tries to print anything on that printer, the attacker will be able to execute remote commands on the CUPS server.
Impact
CUPS RCE has a medium impact of security:
- It allows attackers to execute remote code execution ONLY if the victim tries to print anything via the malicious printer.
Fix
Check your OS editor in order to see if they have already released a patch for those vulnerabilities or not.
If it's not the case, here are some mitigations steps you can apply in the meantime:
- Edit /etc/cups/cups-browsed.conf
- Search for the BrowseRemoteProtocols configuration option
- Set the option to none (the default value is "dnssd cups")
- Restart cups-browsed using systemctl restart cups-browsed
Another option is to disable cups-browsed service:
- systemctl disable --now cups-browsed
Here are some OS editors blogposts regarding those CVE and available patches:
- https://ubuntu.com/blog/cups-remote-code-execution-vulnerability-fix-available
- https://www.redhat.com/en/blog/red-hat-response-openprinting-cups-vulnerabilities
- https://security-tracker.debian.org/tracker/CVE-2024-47177
- https://security-tracker.debian.org/tracker/CVE-2024-47176
- https://security-tracker.debian.org/tracker/CVE-2024-47076
- https://security-tracker.debian.org/tracker/CVE-2024-47175
Detection
For Linux users check:
- If cups-browsed is enabled on your machine
- The version of CUPS. The affected versions of CUPS by the vulnerabilities are the following:
- cups-browsed <= 2.0.1
- cups-filters <= 2.0.1
- libcupsfilters <= 2.1b1
- libppd <= 2.1b1
For MacOS users, at the moment, there's no indication that your machine could be affected by those vulnerabilities.
Conclusion
CUPS RCE is based on 4 vulnerabilities : CVE-2024-47076, CVE-2024-47175, CVE-2024-47176 and CVE-2024-47177.
They allow an attacker to perform remote code execution if a victim prints something on a malicious printer set on a vulnerable server with the help of cups-browsed.
So far, only Linux users are impacted depending on their version of CUPS and if the service is enabled or not.
Documentation
- https://ubuntu.com/blog/cups-remote-code-execution-vulnerability-fix-available
- https://www.redhat.com/en/blog/red-hat-response-openprinting-cups-vulnerabilities
- https://security-tracker.debian.org/tracker/CVE-2024-47177
- https://security-tracker.debian.org/tracker/CVE-2024-47176
- https://security-tracker.debian.org/tracker/CVE-2024-47076
- https://security-tracker.debian.org/tracker/CVE-2024-47175
Definition:
A serious security flaw has been found in the TH1520 CPU used in our EM-RV1 servers. This isssue, called GhostWrite allows unprivileged code to read and write any part of the system's memory.
How it works:
The non-compliant implementation of the high-order strided vector-store instructions vse128.v to vse1024.v doesn't treat the address as virtual ones but physical ones and allows writing and reading any part of memory regardless of current privileges. It's immediate and works everytime.
Impact:
Any data held in RAM such as cryptographic keys can be extracted by any user. Local users can easily gain higher privileges by manipulating memory. As this directly manipulate physical memory, no isolation technology such as Docker can protect against this.
Fix:
We already provide patched kernels that disables the RVV 0.7.1 vector extension, this disables the offending instructions. As those draft extensions weren't used by the software provided with the distributions we propose, this has no performance impact. If your EM-RV1 install predates the 6th of June 2024, you need to update your kernel manually. You can follow this documentation to do so: https://www.scaleway.com/en/docs/bare-metal/elastic-metal/reference-content/elastic-metal-rv1-guidelines/
Documentation:
Regresshion
Definition
CVE-2024-6387, named RegreSSHion, is a vulnerability affecting OpenSSH.
This vulnerability allows an attacker to remotely execute arbitrary code with Root privileges. This is a regression of CVE-2006-5051: the vulnerability was patched but reappeared after numerous software updates.
How it works
In order to authenticate an SSH session, the connecting user must complete the process within a given time. If this is not the case, a signal is sent by the system, SIGALRM, which is processed asynchronously and triggers actions at system level. The problem is that the actions triggered were not designed to be securely asynchronous.
If several conditions are met, an attacker can exploit this vulnerability to trigger a race condition: a situation in which a signal is processed while another action is executed. In this case, the action can be stopped prematurely and cause the system not to act as expected.
In the case of RegreSSHion, the race condition (if successfully exploited) leads to a memory boundary violation and remote code execution (RCE).
Impact
It is clear that RegreSSHion is a major security problem. It allows an attacker to potentially :
- Shut down hosts remotely
- Install malware and spyware on critical hosts
- Access critical data
- Create persistent access to critical hosts
- Erase access logs and manipulate proof of intrusion.
In order to exploit the vulnerability, an attacker needs to make a large amount of attempts (tens of thousands). As mentioned above, in order for the signal to be processed asynchronously, the user must wait a certain amount of time before sending attempts: this makes the attack very slow: it may take a few days. In addition, the attacker must create a custom payload for the specific version of the vulnerable package and operating system he is attacking.
Fix
There are two ways to mitigate this vulnerability. You can update the package if a patched version exists and you can set LoginGraceTime to 0 in the sshd_config file located in /etc /ssh /sshd_config
. This should only be done if there is no corrected version, as this configuration makes the host vulnerable to a denial of service.
For the update part, you can follow the following guides to update your packages:
-
Ubuntu: https://ubuntu.com/security/CVE-2024-6387
- Jammy: 1:8.9p1-3ubuntu0.10
- Mantic: 1:9.3p1-1ubuntu3.6
- Noble: 1:9.6p1-3ubuntu13.3
-
Debian: https://security-tracker.debian.org/tracker/CVE-2024-6387
- Bullseye: 1:8.4p1-5+deb11u3
- Bookworm (Security): 1:9.2p1-2+deb12u3
- Sid: 1:9.7p1-7
Detection
To detect whether the vulnerability affects your system, you need to find the vulnerable packages.
Conclusion
RegreSSHion is a resurgence of a 2006 vulnerability identified as CVE-2006-5051.
It allows an attacker to execute code as root on unauthorised hosts. These hosts must have the vulnerable version of the OpenSSH packages, which can be found in the vendors' security advisories.
RegreSSHion has an impact on many systems as OpenSSH is widely used to secure access to other hosts.
An update is required to correct the problem.
Documentation
- https://nvd.nist.gov/vuln/detail/CVE-2024-6367
- https://nvd.nist.gov/vuln/detail/CVE-2006-5051
- https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server
- https://www.picussecurity.com/resource/blog/openssh-regresshion-cve-2024-6387-vulnerability-exploitation-mitigation
- https://seclists.org/oss-sec/2024/q3/2
- https://www.cert.ssi.gouv.fr/alerte/CERTFR-2024-ALE-009/
- https://www.kaspersky.com/blog/openssh-vulnerability-mitigation-cve-2024-6387-regresshion/51603/
Definition
Ebury is a sophisticated malware and SSH backdoor that targets Linux and Unix systems. Its first goal is to compromise SSH credentials to create persistent and malicious system access. This backdoor allows the attacker to: Steal SSH credentials and use them elsewhere to continue to comprise systems;
- Create persistent remote access on systems;
- Execute arbitrary code on infected systems.
- Ebury has been used in various contexts in terms of cybersecurity and is known for its ability to remain undetected for extended periods. Thus, it is a significant threat to compromise networks.
How it works
After getting access to a system with stolen or forced credentials, Ebury will modify legitimate SSH binaries to obtain more credentials for each connection. Those stolen credentials are then sent to the attackers. Also, those attackers can use a backdoor planted by Ebury to control the system without more authentication. The malware stays undetected by using advanced stealth techniques and modifying critical system binaries.
Impact
Ebury has a significant impact in terms of security:
- It allows attackers to get critical information.
- It allows attackers to control an unauthorized system.
- It can propagate easily.
- It is hard to detect.
The remediation is very heavy regarding time, work, and finance.
Mitigation
To mitigate Ebury, you should follow those good security practices:
- Instead of using only a password to connect to a system with SSH, you should use a key-based authentication. Also, you should use a TOTP to complement the key-based authentication.
- Monitor SSH connections on your system.
- Monitor logs and network traffic to prevent malicious behaviors.
- Isolate infected systems.
By securing SSH access, you may prevent Ebury from infecting your system.
Detection
Several actions must be taken to detect Ebury:
- Your system should be monitored as much as possible, security-wise. Alerts should be raised when critical files are reached, and strange behaviors are detected.
- If you suspect Ebury to live on a system, you must analyze the running processes: strange processes can run. Remember that Ebury uses advanced stealth techniques, so this step may not give answers.
- As said before, Ebury will send the collected information to the attackers. This will generate network traffic, which should be monitored. You can use various tools to check kernel extensions. Tools like “rkhunter” allow one to search for rootkits and may give information about Ebury on the scanned system.
- You can use the dedicated detection script written by ESET, which you can find here: https://github.com/eset/malware-research/tree/master/ebury.
You may detect Ebury on your system using all the previous steps.
Resolution
The resolution for this malware is heavy. If your system is infected, you must:
- Isolate it as fast as possible to prevent propagation.
- Please change your credentials, keys, and certificates. The previous ones may have been sent to attackers, making them obsolete.
- Backup your important files.
- Reinstall the OS and restore your data.
- Follow the mitigation steps to avoid another infection.
There is no “easy and fast” way to resolve this problem: the infected system must be erased and replaced by a fresh one.
Conclusion
Ebury is an advanced malware that modifies legitimate OpenSSH binaries to get credentials and to get unauthorized access to systems. Ebury has a very large impact, being hard to detect and present for many years. Good security practices such as MFA, key-based authentication, and system security monitoring must be followed to mitigate this threat. If a system is infected, the recovery process can be heavy regarding time and work: it implies erasing the OS and reinstalling the system.
Documentation
- ESET’s Ebury presentation https://web-assets.esetstatic.com/wls/en/papers/white-papers/ebury-is-alive-but-unseen.pdf
- Detection Script: https://github.com/eset/malware-research/blob/master/ebury/detect_ebury.sh
- 2019 Cyber Alert on Ebury: https://digital.nhs.uk/cyber-alerts/2019/cc-3096
Dear All,
On the 21st of May 2024, our Trust & CSIRT Teams have detected a minimal number of customers from our offer « Webhosting » were targeted using a mix of some fuzzing methods.
The threat actor attempted to retrieve credit card information by simulating a fake invoice payment page and credential account information.
Scaleway will never request payment through an email link. As always, if there is an issue with your payment, you will receive a message informing you about the situation.
We took the necessary actions, including reaching out to the provider hosting the threat actor’s website and stopping all reception from those illicit senders to avoid impacting our customers.
If you have any doubts about an email supposedly sent by Scaleway, we invite you to contact our technical assistance, available 24/7, by opening a ticket.
You can also take a look at our documentation about how to identify a suspicious email: https://www.scaleway.com/en/docs/console/account/troubleshooting/protecting-yourself-fraud-phishing/.
If you have entered information in response to an email from a phishing campaign, we encourage you to contact support as soon as possible.
We strongly recommend that all our customers activate 2FA on their account; they can follow the steps with this documentation: https://www.scaleway.com/en/docs/dedibox-console/account/how-to/enable-two-factor-authentication/
If you need help using this Trust Center, please contact us.