Simply performance and safety.

Blog
Doc
Portal

Category: Security

  • Symfony: 8 new security vulnerabilities discovered - Analysis and recommendations

    Symfony: 8 new security vulnerabilities discovered - Analysis and recommendations

    After a flawless year, Symfony unveiled this November 6, 2024 on its blog eight vulnerabilities at once. They affect different versions of the Symfony framework. Here's a summary of these critical vulnerabilities, their potential impact, and the solutions implemented by Symfony. It will help you understand the implications of these vulnerabilities for securing your applications.

    Introduction

    Even the most renowned frameworks, such as Symfony, are never immune to security flaws. Whatever application solution you choose, you need to be vigilant. Safeguards such as a ModSecurity application firewall and automatic attacker blocking (fail2ban), combined with a good outsourced backup policy, are essential.

    On LRob secure web hosting, our Linux servers support your application security with ModSecurity combined with fail2ban actively blocking attempts to exploit vulnerabilities; full outsourced backups are made daily with a one-year retention period. Choose LRob as your hosting provider, is to benefit from a simple, secure hosting solution while adding a rigorous, available and passionate sysadmin to your team!

    Symfony security holes (November 2024)

    CVE-2024-51736: Hijacking command execution on Windows with the Process class

    Versions concerned
    Symfony versions =6, =7, <7.1.7.

    Description
    This flaw enables execution to be diverted on Windows systems when the executable file cmd.exe is in the current working directory. The class Process could then execute this file, paving the way for malicious hijacking.

    Resolution
    Symfony has corrected this problem by forcing the Process to use the absolute path to cmd.exe.

    See the official Symfony article.

    CVE-2024-50341 : Security::login method ignores custom user_checker

    Versions concerned
    Symfony versions >=6.2, =7.0, =7.1, <7.1.3.

    Description
    The method Security::login Symfony did not take into account the user_checker which could lead to unwanted connections.

    Resolution
    The patch now implements a call to the user_checker configured.

    See the official Symfony article.

    CVE-2024-50340 : Change environment via a request

    Versions concerned
    Symfony versions =6, =7, <7.1.7.

    Description
    By manipulating a specific query string, users can change the kernel environment or debug mode when a PHP register_argc_argv is activated.

    Resolution
    The component SymfonyRuntime now ignores argv values for non-CLI environments.

    See the official Symfony article.

    CVE-2024-50342: Enumeration of internal addresses and ports via NoPrivateNetworkHttpClient

    Versions concerned
    Symfony versions =6, =7, <7.1.7.

    Description
    With NoPrivateNetworkHttpClientsome internal information could still be exposed, enabling the enumeration of IP addresses and ports.

    Resolution
    The customer NoPrivateNetworkHttpClient now applies blocked IP filtering from the start of host resolution.

    See the official Symfony article.

    CVE-2024-50343 : Incorrect Validator response with input ending in \n

    Versions concerned
    Symfony versions =6, =7, <7.1.4.

    Description
    Validation using a regular expression could be bypassed by inserting a \n at the end of the input, resulting in an incorrect response from the Validator.

    Resolution
    Symfony now uses the regex modifier D to guarantee validation of the entire input.

    See the official Symfony article.

    CVE-2024-50345: Open redirection via browser-sanitized URLs

    Versions concerned
    Symfony versions =6, =7, <7.1.7.

    Description
    By exploiting special characters in a URL, an attacker could hijack a redirect based on the class Request to send users to another domain.

    Resolution
    The method Request::create now checks URIs for invalid characters.

    See the official Symfony article.

    Twig CVE-2024-51754: Unprotected calls to __toString() in a sandbox

    Versions concerned
    Twig versions =3.12, <3.14.1.

    Description
    In a sandbox environment, an attacker could call the __toString() of an object, even if this method was not authorized by the security policy, opening the door to a circumvention of sandbox restrictions.

    Resolution
    Sandbox mode now systematically checks the call to __toString() on all objects.

    See the official Symfony article.

    Twig CVE-2024-51755: Unprotected calls to __isset() and Array object accesses in a sandbox

    Versions concerned
    Twig versions =3.12, <3.14.1.

    Description
    In a sandbox environment, array-like objects could expose attributes without security checks. This allowed an attacker to access potentially sensitive properties.

    Resolution
    Sandbox mode now controls the properties of Array objects and the call to __isset() after safety check.

    See the official Symfony article.

    Conclusion and recommendations from LRob

    These eight flaws show that even the most robust frameworks like Symfony are not immune to security vulnerabilities. Fortunately, the Symfony team reacted quickly to provide patches. And as it should be, the vulnerabilities were only made public after they had been patched. If you're using Symfony, make sure you update as soon as possible to protect your applications and your users.

    Never forget that no software solution is free from security flaws. Your vigilance must be continuous, and regular updates remain the best line of defense against security flaws and cyberthreats.

    At LRob, our servers offer optimal security:

    • No Windows vulnerability : As our servers run on Linux, they are not affected by Windows-specific vulnerabilities.
    • Server application update Server software is updated daily and monitored 24/7.
    • ModSecurity firewall : By actively filtering malicious requests, our firewall protects your applications.
    • Outsourced backups : We have daily outsourced backups to facilitate data recovery in the event of an incident, and you can also make your own backups to the FTP of your choice (e.g. via a VPS Storage Cloud from PulseHeberg) via Plesk.
    Contact us for more information
    Choose your LRob hosting
  • LRob now contributes to malicious IP reporting with AbuseIPDB

    LRob now contributes to malicious IP reporting with AbuseIPDB

    For a long time, I've been looking for a way to effectively exploit the hacking data blocked by my servers. Intrusion attempts are constant, but thanks to security systems such as Fail2ban, attacks are stopped before they cause any damage. However, beyond simply protecting my systems and customers, I wanted to go further: share this information and make the Internet a safer place for everyone.

    Over 2,000 malicious IPs reported in just 48 hours!

    With this in mind LRob has started contributing to attacker reporting via AbuseIPDBa platform that allows anyone to report malicious IPs. In just 48 hoursover 2000 IP have already been reported, showing just how significant the impact of this initiative can be.

    AbuseIPDB Contributor Badge

    Why report malicious IPs?

    Hackers attack everything, all the time. Whether you're a small business, an individual or a large organization, you're a target. However, while these attacks are relentless, the resources of cybercriminals are limited. By identifying them, we have a chance of combating them more effectively and limiting their scope for action.

    There are two main reasons why reporting malicious IPs is crucial:

    1. Identify and block attackers By reporting these IPs, you contribute to the creation of a database accessible to all, making it easier to block potential threats before they reach other infrastructures.
    2. Informing legitimate guests Some legitimate hosts can be infected or hijacked without their knowledge, serving as relays for attacks. By reporting these IPs, you give them a chance to react and correct the situation.

    Sharing information via platforms such asAbuseIPDB makes the web safer, not just for you, but for the whole community.

    A simple API for efficient reporting

    One of AbuseIPDB's great strengths is its ease of use. Via a API accessible to all, it's easy to contribute to the reporting of malicious IPs. By validating your identity, you can even increase the reporting limit to 5000 IP per daywhich covers a wider spectrum of attacks.

    So I decided to set up a system for automate these postponements, so that the community can benefit from my data on blocked hacks. A banner is now visible at the bottom of my LRob.fr site, linking directly to my AbuseIPDB profile, where anyone can see the IPs I've reported (see my profile here).

    Automated reporting with Plesk and Fail2ban

    For those who, like LRob, use Plesk to manage their servers, I developed a script to automatically report malicious IPs via the AbuseIPDB API using the Fail2ban.

    This script is freely available on GitHub and can be used by any sysadmin wishing to automate this process. Simply configure your API key and you're ready to get started!

    You can find it here: GitHub - Report AbuseIPDB.

    (Don't hesitate to suggest improvements if you see ways to optimize the script or make it more efficient!)

    All you have to do is create a CRON and you're done, for example :

    #Run /root/report_abuseipdb.sh every 6 hours
30 */6 * * * /root/report_abuseipdb.sh

    Towards a more secure internet, together 💪

    We all have a role to play in building a healthier, more secure Internet. Every IP reported is one less potential attack on our infrastructures, one less threat to businesses and individuals. Thanks to the combined efforts of contributors and platforms such as AbuseIPDBwe can reduce the impact of cyber attacks and make the web safer for everyone. 🌐

    So, whether you're an experienced sysadmin or an individual user wishing to contribute, I encourage you to join this initiative. Together, we can make a real difference and make the web more secure. 👊

  • Blacklists (RBL): SPFBL.net's outrageous practices

    Blacklists (RBL): SPFBL.net's outrageous practices

    It's time to denounce an organization - SPFBL.net - which, although it claims to fight spam, actually seems to adopt practices contrary to this objective. Instead of fulfilling its role, this provider seems to be taking advantage of its position to engage in absolutely scandalous and unacceptable practices.

    Not all RBLs are managed ethically. Today's example is SPFBL.net, a Brazilian RBL born in 2015 (source MXToolbox)which is increasingly coming under the spotlight for its highly questionable practices.

    Info: What is RBL?

    An RBL (Real-time Blackhole List) is a list of IP addresses suspected of sending spam or other malicious content. Mail servers use these lists to block or filter potentially dangerous e-mails.

    In this article, we'll take a look at this situation and explain why this company's practices are not only dubious, but potentially harmful to the entire Internet ecosystem if administrators decide to use this RBL. We'll also look at how to combat these practices.

    Users' and service providers' views on the SPFBL blacklist

    Let's start by showing the general opinion emerging from this blacklist. A quick search on the search engines shows that the forums (in English) are full of people crying foul about SPFBL.net.

    Having contacted their support (I'll tell you more about it later), I'd tend to agree with them... Judge for yourself.

    "I contacted the operator of this spfbl.net and he threatened me with getting my IP's blocked throughout the internet, how can something like this be allowed to happen."

    OPALIT

    "We got flagged because we don't have a contact email in our whois record (we have privacy turned on for it). Given that google.com also has that, I conclude that these guys are just a scam who want to be paid to have your domain unrestricted."

    someexgoogler

    The LRob case: another unjustified blacklisting

    The infrastructure server LRob is a perfect example of a system that has been carefully configured and managed for many years. As system administrator of this server, I can say with certainty that no spam has ever been sent from this machine. What's more, all the essential settings are correctly in place: Hostname, rDNS, MX, SPF, DKIMand DMARC.

    Despite these exemplary compliance measures, the server's IPv6 ended up on the blacklist of SPFBL.net.

    SPFBL / DNSBL abusive blacklising example

    Check result of IP
    2a01:4f8:171:28e8:0:0:0:2

    This is the rDNS found:

    A domain is considered non-compliant when the WHOIS search result for that domain does not contain the email address of the domain owner. Update the registration data and remove privacy protection for this domain in WHOIS and wait one hour for the cached result of this WHOIS query to expire.

    This IP was flagged due to misconfiguration of the e-mail service or the suspicion that there is no MTA at it.

    For the delist key can be sent, select the e-mail address responsible for this IP:

    • add a PayPal user's email for 2.00 USD.

    The rDNS must be registered under your own domain. We do not accept rDNS with third-party domains.

    Summary of exchanges with SPFBL.net support

    Naturally, I contacted the RBL to check whether I'd understood their policy correctly and whether it was possible to discuss things with them in a spirit of good understanding. Result: yes, I had understood correctly, and no, I don't think it's possible to discuss matters with them as they stand.

    Here is a ChatGPT summary of the e-mail exchanges:

    1. Initial request (Robin) Robin, system administrator, contacted SPFBL to ask for help with the removal of his IPv6 address from their DNS blacklist. He wanted clarification on the reasons for the listing and advice on how to correct any misconfigurations, suspecting a link to WHOIS privacy protection.
    2. Answer (Leandro) In response, SPFBL's Leandro asked Robin to temporarily remove the WHOIS privacy protection so that the IP could be removed via their online removal tool.
    3. Concerns (Robin) In a statement, Mr. Robin expressed concern about the requirement to remove WHOIS privacy protection, citing RGPD regulations. He questioned the need to expose personal data, pointing out that no reports of abuse had been issued on his domain.
    4. Explanation (Leandro) Leandro explained that their system used domain owner data to predict spam and associate domains under the same owner. No further justification for this policy was given.
    5. Objection (Robin) Robin disputed the usefulness of WHOIS information for assessing IP behavior, calling SPFBL's policy counterproductive. He reiterated that his IP posed no risk and requested its removal from the blacklist.
    6. Options (Leandro) Leandro offered two options for removal: temporarily remove WHOIS protection or pay a fee.
    7. Firm response (Robin) Robin firmly rejected both options, describing the practice as dishonest and tantamount to a scam. He stressed that his IP was compliant and threatened to take legal action if the problem was not resolved.
    8. Final answer (Leandro) Leandro rejected Robin's legal threats, stating that SPFBL respects American law and inviting him to pursue any legal action he deems appropriate.
    9. Last warning (Robin) Robin recalled that the Internet is a global system, and that no location justifies harming legitimate businesses through dubious ethical practices. He confirmed his intention to take the necessary measures, specifying that his contacts would identify the relevant local authorities if necessary.

    These exchanges took place between September 8 and 9, 2024.

    In addition, I have a log showing that they tried to send an e-mail to a non-existent address for testing purposes, so that they could check for themselves that the server was correctly configured and rejected the e-mail:

    Oct 9 14:55:13 ds postfix/smtpd[899530]: connect from matrix.spfbl.net[54.233.253.229]
Oct 9 14:55:14 ds postfix/smtpd[899530]: NOQUEUE: reject: RCPT from matrix.spfbl.net[54.233.253.229]: 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table; from= to= proto=ESMTP helo=
Oct 9 14:55:14 ds postfix/smtpd[899530]: disconnect from matrix.spfbl.net[54.233.253.229] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4
Oct 9 14:55:14 ds psa-pc-remote[2023328]: Message aborted.

    The SPFBL.net case: an abusive practice

    The case of SPFBL.net highlights alarming practices that run counter to the data protection and ethical standards respected by many other RBLs.

    In particular, this RBL blacklists IPs according to abusive criteria, and then imposes highly problematic conditions for untracking IP addresses.

    Let's unpack the "rules for free de-listing" according to the policy posted on their site on September 9, 2024, which also informs us about possible reasons for the initial blacklisting:

    Only IP with rDNS pointing to the same mail server IP will be accepted, with FCrDNS for your convenience;❌ This criterion is certainly standard, but this check should be carried out by the server receiving the e-mail, not by an RBL, which here adds no value.
    The rDNS must be in the domain of the MTA administrator, so third-party domains such as the generic rDNS of the data-center or ISP will not be accepted, and its TLD cannot be free and must have a public and accessible WHOIS without privacy obfuscation;❌ The administrator can very well infomanage the mails of a third party, as in my case where the MTA is "lrob.net" and the administration is done via "lrob.fr". This should not justify blocking.
    ❌ Blocking generic rDNS can be good practice, but that's up to the receiving server, not an RBL.
    ❌ Requiring a public WHOIS contravenes the RGPD in Europe. The right to send emails should not depend on the visibility of personal information in the WHOIS.
    The postmaster account must be configured for the domain registered on the rDNS and the account must be active and responding;❌ rDNS are often technical subdomains, like "ds.lrob.net". Having an e-mail address like "postmaster (at) ds.lrob.net" makes no sense. The postmaster can be contacted via other, more appropriate channels, such as a contact form or a main address.
    If you are using an IPv6 with SLAAC flag, you must keep port 25 opened to proof the existence of an active SMTP service and❌ While the server does need to listen on port 25 to ensure proper SMTP operation, again it's up to the receiving server to check this, not a blacklist to control it.
    Reputation of IP should be below 25% of negative points per total send volume✅ This criterion is consistent with the very principle of an RBL, which assesses the reputation of an IP address based on its actual behavior.

    Let's also take a look at the paid delisting conditions:

    Only static IPs with configured mail server reverseeven if FCrDNS is invalid;❌ Under the pretext of paying, one would allow an invalid rDNS, which is contrary to e-mail configuration standards. This is a circumvention of good practice, which could allow misconfigured mails to be sent.
    A PayPal account is required for the email address of this account to be assigned to the IP, as responsible for the abuse;❌ Forcing PayPal to assign an IP address to an account is an unjustified restriction. It limits users' options and has no legitimate reason in a technical framework.
    The PayPal user must agree to have their email address shown publicly on this platform as responsible for the abuses of that IP and❌ Publicly exposing the email address associated with the PayPal account is an invasion of privacy and can lead to risks of harassment or abuse. This clearly goes against the principles of confidentiality.
    Reputation of IP should be below 25% of negative points per total send volume.✅ This criterion is acceptable and aligns with the principle of assessing the reputation of an IP address on the basis of its actual behavior, as expected of an RBL.

    In short, this blacklist seems to me to be an attempt to reinvent the wheel with blocking rules that make absolutely no sense from a technical point of view.

    As for delisting's conditions, even in its paid version, they remain abusive. From my point of view, this should have dissuaded any sysadmin from using this RBL by now.

    Their aim, of course, seems to be to make a profit on the backs of users while recovering personal data.

    Summary of problems with SPFBL.net

    Several major issues call into question the wisdom of their practices and their negative impact on legitimate businesses.

    Here are the main points to remember:

    1. WHOIS private data exposure
      SPFBL.net requires administrators to remove their WHOIS protection in order to be removed from their blacklist. This means that personal and sensitive information, such as the domain owner's email address, must be publicly accessible for the IP address to no longer be blacklisted. In Europe, this request is in total contradiction with the RGPD (General Data Protection Regulation), which guarantees the protection of users' private data. WHOIS information has been private by default for many years. This requirement would expose system administrators and companies to the risk of abuse or targeted spam, which is contrary to good security and privacy practice.
    2. Payment for delisting
      In addition to removing WHOIS protection, SPFBL.net also offers an alternative : pay $2 to remove an IP address from the blacklist. This practice is perceived by many as a form of blackmail. Demanding payment to restore the legitimacy of an IP address, when there is no evidence of suspicious or malicious activity, calls into question the transparency of their operations. This approach is likely to drive many legitimate companies to pay simply to avoid the inconvenience of blacklisting.
    3. An inefficient detection model
      Grouping domains according to WHOIS information ignores the realities of the modern web, where many legitimate businesses use shared infrastructures, hosted by providers such as Google or OVH. As a result, IP addresses could be unfairly blacklisted simply because they share a domain owner with other users, regardless of their actual behavior.

    A very serious potential impact

    The consequences of these practices are numerous and serious for the Internet ecosystem:

    1. Impact on companies : When an IP address is wrongly blocked, it can affect a company's ability to communicate by e-mail with its customers, partners or service providers. Detection errors or abusive demands can disrupt the smooth running of a business.
    2. Blackmail and extortion : Asking for money to remove an IP address from a blacklist without proof of malicious activity is tantamount to extortion. This approach seriously undermines trust between ISPs and their customers.
    3. Breach of confidentiality : By requesting the removal of WHOIS protection, SPFBL.net is violating the fundamental principles of personal data protection, particularly in Europe, where the RGPD (General Data Protection Regulation) protects users' private information. By exposing this data, SPFBL.net exposes system administrators and companies to the risk of misuse.

    What can I do as an Internet service provider?

    1. Stop using this RBL immediately

    We must all urge our relations at the major service providers NOT to use this RBL.

    It is absolutely essential that Internet service providers stop using SPFBL.net and other RBLs that fail to meet ethical standards. Another such RBL is UCEPROTECT, which blacklists entire IP blocks and then demands money from each of the IP users to unblock them.

    Using a dubious RBL can have harmful consequences for end-users, businesses and the entire digital ecosystem.

    There are many respectable alternatives that focus on detecting malicious activity based on actual behavior, not private information or arbitrary domain groupings. System administrators must remain vigilant and choose solutions that respect privacy and follow fair and transparent practices.

    2. Don't give in

    If, like me, you are a victim of this RBL and feel that these practices are abusive, please don't give in to the outrageous demands of this RBL. On the contrary, fight alongside me.

    3. Report these practices to the appropriate authorities

    Use your connections to get the word out to the French CSIRT (Computer Security Incident Response Team), at the_ANSSI but also to the CNIL for non-compliance with RGPD. If you have contacts at European level, pass on the information. If you're outside France or Europe, contact the organizations you can reach, and don't hesitate to use this article to explain the problem.

    If you don't have a contact but understand what's at stake, pass on the info to people in the hosting and web sysadmin fields.

    Conclusion

    The case SPFBL.net is a blatant example of the dangers of the dubious practices of certain RBLs.

    We understand that those who claim to fight the "bad guys" are not always "good guys" themselves.

    To protect the integrity of the Internet and the respect of users, it is imperative that Internet service providers stop using this RBL and favor more respectful solutions available.

    Fellow sysadmins: don't give in to the grotesque requirements of this RBL.

    LRob will not give in, and this article marks the beginning of a fight which will only stop once the community has won its case. It can be done, by contacting the right people. And you can help.

    If you are confronted with the abusive practices of SPFBL.net, join us in denouncing these actions and protecting the integrity of the Internet ecosystem. Contact the relevant authorities, share this information with your professional networks, and refuse to give in to these unfair practices.

  • Critical security flaw in CUPS on GNU/Linux September-October 2024: What you need to know

    Critical security flaw in CUPS on GNU/Linux September-October 2024: What you need to know

    A quadruple critical security flaw has just been discovered in CUPS for all GNU/Linux systems. This article will be updated with the new information, to provide you with a simple and effective summary of what you need to know and do.

    UPDATE 09/29/2024: These flaws only concern CUPS, so very few servers are affected, unless you have printers in your datacenter...! This article has been rewritten accordingly.

    A critical flaw: what do we know?

    The security researcher Simone Margaritellidiscovered this set of faults in early September.

    This concerns CUPS, the Linux printing service. The researcher highlights a possible Remote Code Execution (RCE). without authentication. This means that attackers could potentially execute commands on remote machines without having to identify themselves, making the flaw particularly dangerous. The CVSS score assigned to these vulnerabilities is between 8.3 and 9.0/10 (after being rated at 9.9).

    On September 26, Naïm Aouaichia, cybersecurity engineer, alerted us and told us before anyone else that this could affect CUPS :

    "Some rumors suggest that this flaw is linked to vulnerabilities in CUPS, the printing service. Yes, your printers may be at the heart of it all. To be confirmed.

    According to some hypotheses, the problem could be linked to a buffer overflow or a race condition."

    Extract from the LinkedIn post of Naïm Aouaichia, cybersecurity engineer

    Update 29/09/2024

    Like Naïm winds it up on September 28This flaw concerns CUPS, with 4 CVEs revealed:

    This does not apply to dedicated servers under firewall and/or with a print service not running.
    For local administrators using CUPS, stay tuned.

    A long-standing problem

    This vulnerability has a long history, having been present in GNU/Linux systems for many years. over a decade. It affects all Linux distributions, including Debian, Ubuntu, RedHat and others.

    Despite the importance of this flaw, there are currently no no correction available. Developers are still debating which aspects of the flaw really affect security, which is delaying the release of a patch.

    Disclosure process

    Researcher Margaritelli, who made the discovery, worked tirelessly for three weeks to alert the open source community and help coordinate patching efforts. However, it met with a great deal of resistance from developersSome are reluctant to accept the existence of this flaw in their code. This underlines the challenges facing vulnerability management in the open source world.

    Some accuse him of trying to boost his popularity. But let's face it: the researcher has indeed discovered a major flaw that everyone has been ignoring for over 10 years.

    Canonical (Ubuntu) and RedHat have confirmed the seriousness of the situation and are actively working on a solution. Full disclosure of the technical details of the flaw is planned. October 6This increases the pressure for a rapid patch release.

    The roadmap is as follows:

    • September 30: Initial disclosure to the Openwall security mailing list
    • October 6: Public revelation with all the elements of vulnerability

    Why is it complicated to correct the flaw?

    Margaritelli indicated from the outset that it would probably be necessary to at least three to six CVE identifiers (Common Vulnerabilities and Exposures) to cover all aspects of the problem. This means that there are several potential attack vectors, each requiring specific analysis and resolution.

    What are the risks for you?

    As we now know, you must absolutely avoid exposing your IPP services to the Internet (port 631 should be blocked on firewalls).

    Although this flaw is critical, it is not so easily exploited. It requires a high level of technical expertise, which means that, for the time being, only highly skilled attackers could make use of it. The details of the flaw are not yet public, limiting its impact. But this should not make you complacent. You need to remain vigilant, because once full disclosure has been made, exploitation attempts will multiply.

    What to do in the meantime?

    Pending an official patch, here are some best practices to limit the risks:

    1. Watch for official announcements Stay informed about security updates released by your Linux distribution. These announcements will let you know when a patch is available.
    2. Reinforce your firewall configuration Make sure your servers are not unnecessarily exposed to the Internet. Restrict access to essential ports and, above all, do not expose port 631!
    3. Limit service exposure Reduce the number of services listening publicly to a minimum by switching off unnecessary services or having them listen on 127.0.0.1.
    4. Get ready for rapid deployment As soon as a patch is released, be ready to install it immediately to protect your machines.
    5. Re-evaluate your backups : Make sure you have a good outsourced backup (LRob already has one, but it's not enough!). we encourage everyone to have their own back-up).

    Conclusion: remain vigilant but serene

    This RCE flaw is undoubtedly one of the most serious to be discovered in the GNU/Linux ecosystem in a long time. However, it's important not to panic. No system is free of flaws, and Linux remains the most reliable and secure operating system. It's worth remembering that most servers don't have a CUPS service running, but if they do, then take extra care. By adopting the recommended security measures and keeping an eye on official announcements, you can minimize the risks. The open source world is generally quick to react and will certainly be able to overcome this ordeal effectively, despite the internal divergences inherent in collaborative work.

    Keep an eye on upcoming patches and make sure your systems are ready for them. IT security is an ongoing challenge, but staying proactive will ensure that your WordPress servers and clients stay protected.

    LRob is keeping a very close eye on this, and if the servers aren't affected, I guarantee that we'll fix this global flaw as soon as the patch is available.

    Finally, for those who will argue that "Linux isn't secure", here's a little comparison Linux VS Microsoft.

    1-year comparison of Linux VS Microsoft security vulnerabilities
    11-year comparison of Linux VS Microsoft security vulnerabilities

    The truth is: there's no such thing as 100% safety, and anyone who claims otherwise is either lying or ignorant! So leave dogmatism aside. No one is spared from vulnerabilities, so it's a question of doing our best and remaining vigilant to make intrusions as difficult as possible.

    Sources :

  • The best free, open-source password manager (KeePass)

    The best free, open-source password manager (KeePass)

    Secure your passwords with an open-source, self-hosted solution

    Managing your passwords is a real headache! We all know that the security of our personal data depends on our passwords, but frankly, who hasn't made a mistake when managing them? Let's take a look at how to avoid the most common pitfalls and find the ideal solution for keeping your passwords safe.

    Common mistakes in password management

    Two simple questions to see where you stand with your password management:

    1. Do you remember your passwords?
      • If your answer is "yes", that's not necessarily good news. It means you're probably using the same password everywhere, or you've got a pattern that's easy to guess. A hacker could then have fun discovering other passwords if he ever found one.
    2. Do you entrust your passwords to a private company?
      • Here again, beware! Many commercial password managers have already been hacked. And since they're "closed-source", it's impossible to know what they're doing with your data. And as for saving passwords in Chrome... I think you see where I'm going with this. 😬

    Don't panic, if you answered "yes" to any of these questions, you're not alone - in fact, you're in the majority. It's time to make it safe and join those who are taking their safety into their own hands!

    KeePass: the ultimate open-source solution

    The right solution for maximum security and total control?

    KeePass

    This free, independent, open-source software lets you store your passwords in an encrypted database, protected by a single master password. No more remembering all your passwords - they can be as complicated and random as you like!

    Let's be honest, the original KeePass app isn't the prettiest. But don't worry, there's a great alternative: KeePassXC. With KeePassXC, you get an improved interface and top-notch security, whether you're on Windows, macOS or Linux.

    And for even greater convenience, don't forget to install the KeePassXC browser extension. It lets you automatically fill in your password fields and easily save new ones.
    And activate the corresponding browser integration in the KeePassXC settings.

    Simplified transition from Chrome

    As many people use Chrome and will inevitably be lazy to make the switch, you should know that it's very easy to export your passwords:

    • Go to Chrome settings
    • Then in "Passwords
    • Click on "Export passwords".
    • Save the .csv file
    • Import it via KeePass using the "Import..." function.
    • Delete the .csv and empty your recycle garbage can

    Stay in control with a self-hosted solution

    One of the big advantages of an open-source solution like KeePass is that you can retain total control over your data. No need to entrust your database to a private company. You can host it yourself on a platform like Nextcloud for offline access. With Nextcloud and KeePass, you can synchronize your passwords across all your devices, while keeping control of your data.

    What's more, Nextcloud isn't just a storage service. It's a complete solution for managing your files, team collaboration and much more. You get all the benefits of proprietary cloud solutions like those from Microsoft or Google, but with total sovereignty over your data.

    If you don't have your Nextcloud instance yet, you can get it very easily with full maintenance here : https://www.lrob.fr/hebergement-web/cloud-prive-nextcloud/

    Mention for Passbolt

    A self-hosting web-based solution also exists: Passbolt.

    Whichever solution you choose, both Passbolt and KeePass feature password import/export functions, so you can switch from one to the other with ease. Once you're free, you're free.

    Conclusion

    Protecting your passwords is essential. With an open-source, fully self-hosted solution like KeePass and Nextcloud, you're sure to make the right choice. You'll have optimum security and control from A to Z, without having to rely on third-party services that could jeopardize your confidentiality.

    So, ready to discover the satisfaction of using a random 128-character password, knowing it's super secure? Now's the time to get started with KeePass and take back control of your data. 💪

  • Apache web server vulnerability affects millions of servers

    Apache web server vulnerability affects millions of servers

    The Apache HTTP server is one of the most widely used web servers in the world. However, like all software, it is not immune to vulnerabilities. And beware: it's a double vulnerability.

    On July 4, a critical security flaw was discovered, affecting Apache version 2.4.60. This flaw is rated CVE-2024-39884.

    The flaw allows the source code of PHP files to be disclosed. This is absolutely critical, as these files may contain, for example, database passwords or confidential proprietary code.

    A patch was therefore released via version 2.4.61 of the Apache server... Except that this patch did not correctly correct the flaw! A second CVE was therefore released, CVE-2024-40725, to re-identify this ultimately uncorrected flaw.

    Here's a summary of these flaws and the corrections made.

    Update 07/30/2024: There is a possibility that this vulnerability is related to a wave of hacks targeting sites hosted by o2switch. Nothing has been established with certainty, as the means of exploiting these flaws and the scale of the problem are not yet public. Nor do I have any information from my hosting partner on the Apache versions used.

    CVE-2024-39884

    • Publication date : July 4, 2024
    • Description : A regression in the kernel of Apache HTTP Server version 2.4.60 means that certain configurations based on content type, such as "AddType", are not correctly taken into account. In some cases, this can lead to the disclosure of the source code of local files, such as PHP scripts, which may be displayed as plain text instead of being interpreted.
    • Solution: We recommend upgrading to version 2.4.61, which fixes this problem.
    • Link : CVE-2024-39884

    CVE-2024-40725

    • Publication date : July 17, 2024
    • Description : This flaw is an additional correction to CVE-2024-39884. It reveals that version 2.4.61 does not completely correct the initial problem. Indeed, certain configurations based on content type may still result in the disclosure of local file source code in certain circumstances.
    • Solution: We recommend upgrading to version 2.4.62, which permanently fixes this problem.
    • Link : CVE-2024-40725

    Debian Patch Roadmap

    Debian, the mother Linux distribution used by LRob, has also taken steps to correct these vulnerabilities in its various versions, either through the "security" repository or natively, depending on the OS version. Here's the roadmap for corrections:

    Source PackageReleaseVersionStatus
    apache2 (PTS)bullseye2.4.59-1~deb11u1vulnerable
    bullseye (security)2.4.61-1~deb11u1corrected
    bookworm2.4.59-1~deb12u1vulnerable
    bookworm (security)2.4.61-1~deb12u1corrected
    sid, trixie2.4.62-1corrected

    LRob server status

    All LRob servers are already up to date and correct this flaw.

    Conclusion

    Administrators of Apache HTTP servers should immediately check the version of their server and upgrade to the corrected versions (2.4.61-1[security] or 2.4.62) to avoid any inadvertent disclosure of source code.

    The open-source community continues to monitor and rapidly correct vulnerabilities to ensure the security and reliability of software used by millions of servers worldwide. Make sure you follow security updates and keep your infrastructure up to date to protect your data and that of your users.

en_US
fr_FR en_US