Ubiquiti UniFi – Storage Replacement (HDD/SSD/SD Cards)

You may need to replace a storage disk when upgrading to a larger storage capacity, or if your current disk has naturally degraded over time, as discussed in our article on Disk Health. UniFi OS makes this process incredibly simple.

Before Replacing a Disk

Back up your UniFi OS Host.
Obtain a compatible disk.
Export any recordings you want to keep (all recordings on the disk will be lost).

How to Replace a Disk

All UniFi Hosts with removable disks can be opened and the disks swapped with ease.

Hosts with HDDs and SSDs (i.e., Dream Machines & Video Recorders): Simply press the disk tray to open it. Then take out and replace the disk in the same orientation.
Hosts with microSD cards (i.e., Dream Router & Dream Wall): Carefully pull the tray out of its slot, then replace the card in the same orientation.

Cloud Key Gen2 Plus and Devices “Managed by Other”

The Cloud Key Gen2 Plus is unique, because it operates entirely off its external storage. Replacing this disk will result in a new database. Any connected devices (i.e., Cameras & Access Points) will still be associated with the old database, and will appear as “Managed by Other.”

In this case, restoring from a backup will resync the devices with your Cloud Key. If you did not make a backup before replacing the storage, you will need to factory reset and readopt your device(s).

Ensure the following when replacing a disk in your CK G2 Plus:

No security devices are connected to the security slot on the side.
Your Cloud Key has been shut down from UniFi OS > Console Settings and is unplugged.
- The HDD should not be removed or installed while the CK is powered on.

Replacing a Disk in an Array

The Network Video Recorder and Network Video Recorder Pro can maximize data protection by creating storage arrays across multiple disks. For more information, see Storage Protect and Data Redundancy

Remember:

Always replace a failed disk first before replacing an at-risk disk.
Replace one disk at a time, allowing storage to fully repair before replacing the next disk.
Repairing a disk takes significant work, and will impact overall performance.

Source :
https://help.ui.com/hc/en-us/articles/12257010646679-UniFi-Storage-Replacement-HDD-SSD-SD-Cards-

NIST Password Guidelines

Joe Dibley

Published: November 14, 2022

Updated: March 17, 2023

What are NIST Password Guidelines?

Since 2014, the National Institute of Standards and Technology (NIST), a U.S. federal agency, has issued guidelines for managing digital identities via Special Publication 800-63B. The latest revision (rev. 3) was released in 2017, and has been updated as recently as 2019. Revision 4 was made available for comment and review; however, revision 3 is still the standard as of the time of this blog post.

Section 5.1.1 – Memorized Secrets provides recommendations for requirements around how users may create new passwords or make password changes, including guidelines around issues such as password strength. Special Publication 800-63B also covers verifiers (software, websites, network directory services, etc.) that validate and handle passwords during authentication and other processes.

Handpicked related content:

Password Policy Best Practices for Strong Security in AD

Not all organizations must adhere to NIST guidelines. However, many follow NIST password policy recommendations even if it’s not required because they provide a good foundation for sound digital identity management. Indeed, strong password security helps companies block many cybersecurity attacks, including hackers, brute force attacks like credential stuffing and dictionary attacks. In addition, mitigating identity-related security risks helps organizations ensure compliance with a wide range of regulations, such as HIPAA, FISMA and SOX.

Quick List of NIST Password Guidelines

This blog explain many NIST password guidelines in detail, but here’s a quick list:

User-generated passwords should be at least 8 characters in length.
Machine-generated passwords should be at least 6 characters in length.
Users should be able to create passwords at least 64 characters in length.
All ASCII/Unicode characters should be allowed, including emojis and spaces.
Stored passwords should be hashed and salted, and never truncated.
Prospective passwords should be compared against password breach databases and rejected if there’s a match.
Passwords should not expire.
Users should be prevented from using sequential characters (e.g., “1234”) or repeated characters (e.g., “aaaa”).
Two-factor authentication (2FA) should not use SMS for codes.
Knowledge-based authentication (KBA), such as “What was the name of your first pet?”, should not be used.
Users should be allowed 10 failed password attempts before being locked out of a system or service.
Passwords should not have hints.
Complexity requirements — like requiring special characters, numbers or uppercase letters — should not be used.
Context-specific words, such as the name of the service or the individual’s username, should not be permitted.

You probably notice that some of these recommendations represent a departure from previous assumptions and standards. For example, NIST has removed complexity requirements like special characters in passwords; this change was made in part because users find ways to circumvent stringent complexity requirements. Instead of struggling to remember complex passwords and risking getting locked out, they may write their passwords down and leave them near physical computers or servers. Or they simply recycle old passwords based on dictionary words by making minimal changes during password creation, such as incrementing a number at the end.

NIST Guidelines

Now let’s explore the NIST guidelines in more detail.

Password length & processing

Length has long been considered a crucial factor for password security. NIST now recommends a password policy that requires all user-created passwords to be at least 8 characters in length, and all machine-generated passwords to be at least 6 characters in length. Additionally, it’s recommended to allow passwords to be at least 64 characters as a maximum length.

Verifiers should no longer truncate any passwords during processing. Passwords should be hashed and salted, with the full password hash stored.

Also the recommended NIST account lockout policy is to allow users at least 10 attempts at entering their password before being locked out.

Accepted characters

All ASCII characters, including the space character, should be supported in passwords. NIST specifies that Unicode characters, such as emojis, should be accepted as well.

Users should be prevented from using sequential characters (e.g., “1234”), repeated characters (e.g., “aaaa”) and simple dictionary words.

Commonly used & breached passwords

Passwords that are known to be commonly used or compromised should not be permitted. For example, you should disallow passwords in lists from breaches (such as the Have I Been Pwned? database, which contains 570+ million passwords from breaches), previously used passwords, well-known commonly used passwords, and context-specific passwords (e.g., the name of the service).

When a user attempts to use a password that fails this check, a message should be displayed asking them for a different password and providing an explanation for why their previous entry was rejected.

Reduced complexity & password expiration

As explained earlier in the blog, previous password complexity requirements have led to less secure human behavior, instead of the intended effect of tightening security. With that in mind, NIST recommends reduced complexity requirements, which includes removing requirements for special characters, numbers, uppercase characters, etc.

A related recommendation for reducing insecure human behavior is to eliminate password expiration.

No more hints or knowledge-based authentication (KBA)

Although password hints were intended to help users to create more complex passwords, users often choose hints that practically give away their passwords. Accordingly, NIST recommends not allowing password hints.

NIST also recommends not using knowledge-based authentication (KBA), such as questions like “What was the name of your first pet?”

Password managers & two-factor authentication (2FA)

To account for the growing popularity of password managers, users should be able to paste passwords.

SMS is no longer considered a secure option for 2FA. Instead, one-time code provider, such as Google Authenticator or Okta Verify, should be used.

How Netwrix Can Help

Netwrix offers several solutions specifically designed to streamline and strengthen access and password management:

Netwrix Password Policy Enforcer makes it easy to create strong yet flexible password policies that enhance security and compliance without hurting user productivity or burdening helpdesk and IT teams.
Netwrix Password Reset enables users to safely unlock their own accounts and reset or change their own passwords, right from their web browser. This self-service functionality dramatically reduces user frustration and productivity losses while slashing helpdesk call volume.

FAQ

What is NIST Special Publication 800-63B?

NIST’s Digital Identity Guidelines (Special Publication 800-63B) provides reliable recommendations for identity and access management, including effective password policies.

Why does NIST recommend reducing password complexity requirements?

While requiring complex passwords makes them more difficult for attackers to crack, it also makes passwords harder for users to remember. To avoid frustrating lockouts, users tend to respond with behaviors like writing down their credentials on a sticky note by their desk or choosing to periodically reuse the same (or nearly the same) password — which increase security risks. Accordingly, NIST now recommends less stringent complexity requirements.

Source :
https://blog.netwrix.com/2022/11/14/nist-password-guidelines/

Top Strategies to Harden Your Active Directory Infrastructure

Joe Dibley

Published: April 28, 2023

Microsoft Active Directory (AD) is the central credential store for 90% of organizations worldwide. As the gatekeeper to business applications and data, it’s not just everywhere, it’s everything! Managing AD is a never-ending task, and securing it is even harder. At Netwrix, we talk to a lot of customers who are using our tools to manage and secure AD, and over the years, key strategies for tightening security and hardening AD to resist attacks have emerged. Here are 10 Active Directory security hardening tips that you can use in your environment:

Handpicked related content:

Active Directory Group Management Best Practices

Tip #1: Clean up stale objects.

Active Directory includes thousands of items and many moving elements to safeguard. A core method for increasing security is to decrease clutter by removing unused users, groups and machines. Stale AD objects may be abused by attackers, so deleting them reduces your attack surface.

You may also find seldom-used items. Use HR data and work with business stakeholders to determine their status; for example, for user accounts, determine the user’s manager. While this takes time, you’ll appreciate having it done during your next audit or compliance review.

Tip #2: Make it easy for users to choose secure passwords.

To prevent adversaries from compromising user credentials to enter your network and move laterally, passwords need to be hard to crack. But users simply cannot remember and manage multiple complex passwords on their own, so they resort to practices that weaken security, such as writing their passwords on sticky notes or simply incrementing a number at the end when they need to change them. That led security experts to weaken their recommendations concerning password complexity and resets.

However, with an enterprise password management solution, you can make it easy for users to create unique and highly secure passwords and manage them effectively, so you do not have to compromise on strong password requirements. A user needs to memorize just one strong password, and the tool manages all the others for them.

Tip #3: Don’t let employees have admin privileges on their workstations.

If an attacker gains control of a user account (which we all know happens quite a bit), their next step is often to install hacking software on the user’s workstation to help them move laterally and take over other accounts. If the compromised account has local admin rights, that task is easy.

But most business users do not actually need to install software or change settings very often, so you can reduce your risk by not giving them admin permissions. If they do need an additional application, they can ask the helpdesk to install it. Don’t forget to use Microsoft LAPS ensure all remaining local admin accounts have strong passwords and change them on a regular schedule.

Tip #4: Lock down service accounts.

Service accounts are used by applications to authenticate to AD. They are frequently targeted by attackers because they are rarely monitored, have elevated privileges and typically have passwords with no expirations. Accordingly, take a good look at your service accounts and restrict their permissions as much as possible. Sometimes service accounts are members of the Domain Admin’s group, but typically don’t need all of that access to function — you may need to check with the application vendor to find out the exact privileges needed.

It’s also important to change service account passwords periodically to make it even more difficult for attackers to exploit them. Doing this manually is difficult, so consider using the group managed service account (gMSA) feature, introduced in Windows Server 2016. When you use gMSAs, the operating system will automatically handle the password management of service accounts for you.

Tip #5: Eliminate permanent membership in security groups.

The Enterprise Admin, Schema Admin and Domain Admin security groups are the crown jewels of Active Directory, and attackers will do everything they can to get membership in them. If your admins have permanent membership in these groups, an attacker who compromises one of their accounts will have permanent elevated access in your domain.

To reduce this risk, strictly limit membership in all of these highly privileged group and, furthermore, make membership temporary. The Enterprise Admin and Schema Admin groups are not frequently used, so for these, this won’t be an issue. Domain Admin is needed much more, so a system for granting temporary membership will have to be set up.

Tip #6: Eliminate elevated permissions wherever possible.

There are three fairly common permissions that attackers need to execute attacks against AD: Reset Password, Change Group Membership and Replication. These permissions are harder to secure since they are so frequently used in daily operations.

Accordingly, you should monitor all changes to security group permissions or membership that would grant these rights to additional users. Even better, implement a privileged access management (PAM) solution that enables just-in-time temporary provisioning of these privileges.

Tip #7: Implement multifactor authentication (MFA)

MFA adds an extra layer of security by requiring users to verify their identity by providing at least two of the following types of authentication factors:

Something they know, such as a password, PIN or answer to a security question
Something they have, such as a code from a physical token or a smart card
Something they are, which means biometrics like a fingerprint, iris or face scan

Tip #8: Closely audit your Active Directory.

It is important to audit Active Directory for both non-secure settings and suspicious activity. In particular, you should perform regular risk assessment to mitigate security gaps, monitor for anomalous user activity, and promptly identify configuration drift in critical system files. It’s ideal to invest in tools that will automatically alert you to suspicious events and even respond automatically to block threats.

Tip #9: Secure DNS.

Securing DNS can help you to block a variety of attacks, including as domain hijacking and DNS spoofing. Steps to take include implementing DNSSEC, using a secure DNS server and regularly reviewing DNS settings.

Tip #10: Regularly back up Active Directory.

Having a recent backup of your Active Directory is crucial for recovery from cyber incidents, including ransomware attacks and natural disasters. Backups should be stored securely, tested regularly and be readily accessible to ensure your critical AD settings are recoverable in the event of a disaster.

Conclusion

Active Directory is an amazing system for controlling access. However, it’s only secure when it’s clean, understood, properly configured, closely monitored and tightly controlled. These tips are practical ways that you can tighten security and harden your Active Directory.

Frequently Asked Questions

What is hardening in Active Directory?

Hardening in Active Directory is the process of securing and strengthening the directory service to reduce the risk of data breaches and downtime. It involves controlling access to sensitive data, removing unnecessary objects, enforcing password policies and monitoring for suspicious activity.

What is domain controller hardening?

Domain controller hardening is the process of strengthening the servers that run Active Directory to reduce the risk of unauthorized access, data breaches and service disruption. It includes deactivating superfluous services, deploying security patches and updates, establishing firewall rules, and enforcing strong password practices.

What happens if a domain controller is compromised?

An adversary who compromises a domain controller can do significant damage, from accessing sensitive data to creating, modifying and deleting user accounts and other critical AD objects.

How do I secure Active Directory?

Securing Active Directory is an ongoing process that involves multiple layers of security controls. In particular, organizations need to implement strong password policies, limit user access, monitor for suspicious activity, keep machines patched and updated, secure domain controllers, use multifactor authentication (MFA) to add extra security, and educate employees on cybersecurity best practices and potential threats.

Source :
https://blog.netwrix.com/2023/04/28/harden-active-directory/

Active Directory Security Groups Best Practices

Kevin Joyce

Published: May 4, 2023

Active Directory security groups are used to grant users permissions to IT resources. Each security group is assigned a set of access rights, and then users are made members of the appropriate groups. Done right, this approach enables an accurate, role-based approach to user management and reduces IT workload.

Why should Security Groups Stay Secure?

Security groups should always be protected with clear security protocols because they govern user and computer access to resources that could be highly confidential, sensitive, and critical to the organization. Any oversight may result in security breaches and data theft with lasting consequences. Hence, you need to establish some best practices for using and managing security groups.

Key Best Practices

The following best practices can help you use security groups effectively.

Use Group Nesting to Simplify Access Management
Give each security group a unique, descriptive name
Limit each group’s permissions to the bare minimum
Make each user a member of only the required groups
Track group activity and changes to security groups
Pay attention to service accounts
Have group owners review their groups regularly, and remove groups that are no longer needed
Use privileged accounts only when required
Always create a recovery plan

Use Group Nesting to Simplify Access Management.

When we talk about group nesting, we refer to making an AD group a member of another group. This strategy enables us to give permissions across domains through universal groups. It works this way:

Give each security group a unique, descriptive name.

When security groups have unclear names, or multiple groups have similar names, such as ‘Sales Group 1’ and ‘Sales Group 2’, it’s difficult to ensure that they have the correct permissions and membership. To reduce risk, establish group naming standards that ensure consistency and uniqueness.

Limit each group’s permissions to the bare minimum.

The least privilege principle is the cornerstone of security. Make sure each security group is assigned only the permissions that its members need to complete their tasks. Granting excessive permissions to a group enables any group member — or an adversary who compromises their account — to abuse those rights.

Make each user a member of only the required groups.

Never add users to groups they do not need to be a part of. Moreover, remove them promptly from groups they no longer need to belong to, such as when they change roles within the organization. For example, when users change departments, remove them from the previous department’s groups and add them to the new department’s groups. That way, each user has access only to the resources they need, which reduces your organization’s attack surface area.

Track group activity and changes to security groups.

Any improper change to the permissions or membership of a security group puts the organization at increased risk of security incidents and business disruptions. Be especially vigilant about monitoring changes to highly privileged groups like Domain Admins and Enterprise Admins.

Look out for the following to detect suspicious behavior:

Unauthorized permission and membership changes
Unnecessary or unusual use of admin accounts
Failed password attempts
Locked out accounts
Disabled or removed antivirus software

At a minimum, log the events and regularly run reports to spot suspicious activity. Even better, use a tool that will alert you in real time to changes to critical security groups, or block those changes from happening in the first place.

Pay attention to service accounts.

A service account is a special user account created to run a particular application or service. Best practices for service accounts include the following:

Set secure passwords.
Do not make service accounts members of built-in privileged groups like Domain Admins.
Enforce least privilege by granting each service account the minimum access required to accomplish its tasks.

Have group owners review their groups regularly, and remove groups that are no longer needed.

Security groups are usually set up to provide access to resources for a particular project team— but when the project is over, the group is often not deleted. By requiring group owners to regularly review their groups, you can improve security by removing groups that are no longer needed.

As a best practice, disable or delete dormant accounts after about 45 days of inactivity. Set up a system to distinguish inactive accounts from active accounts, which would help in removing inactive accounts from security groups. Hackers can easily target unused accounts since no one keeps track of the account’s activities. And if that unused account is a member of multiple security groups, the implications could be devastating.

Use privileged accounts only when required.

Accounts that are members of privileged groups should be used only for performing administrative tasks that require elevated rights. For all other tasks, admins should use their regular user accounts. This strategy reduces the risk of attackers gaining control of an account that is a member of security groups with access to sensitive systems and data.

Always create a recovery plan.

Despite keeping security intact, data breaches may happen at times due to an error. As a proactive measure, have a recovery plan in place with due attention to recovering security groups. IT teams must be trained to handle such a situation with quick and intelligent decision-making.

Simplifying Security Group Management

Netwrix GroupID can help you effectively manage your Active Directory security groups. Here are some of the ways it can help you implement the best practices described above.

Establish and enforce standards for naming groups
Ensure the membership of security groups is accurate
Establish an attestation process for security groups
Set security groups to expire automatically
Set a default group approver

Establish and enforce standards for naming groups.

Netwrix GroupID helps you implement consistency and convention in group names with the following features:

Group name prefixes
Regular expressions
Templates for naming nested groups
Lists of blocked words

Ensure the membership of security groups is accurate.

Netwrix GroupID enables you to manage group membership with LDAP queries as an alternative to manually adding and removing users, thus ensuring that membership is always up to date.

Establish an attestation process for security groups.

Netwrix GroupID makes it easy for group owners to regularly review the attributes, membership, and permissions of their security groups, as well as whether the groups are still needed. This process helps maintain a check on groups.

Set security groups to expire automatically.

You can set an expiry date for a security group, such as a group created for a specific project. Netwrix GroupID sends an email notification to a group’s owner 30 days, 7 days and 1 day before the expiration date. If the group is not renewed, it is automatically deleted. Expired groups that have been deleted can be quickly restored if necessary.

You can easily exempt any security group from expiration, including the default security groups in Active Directory.

Set a default group approver.

You can designate a default approver for groups, who will receive expiry notifications for groups without owners.

Conclusion

Properly managing your Active Directory security groups is vital to protecting your IT systems and data. A solution like Netwrix GroupID can make it easy to implement the best practices detailed here.

Source :
https://blog.netwrix.com/2023/05/04/active-directory-security-groups/

RSA Report: Cybersecurity is National Security

The role of government in stopping supply chain attacks and other threats to our way of life.

By Amber Wolff
April 26, 2023

How governments play a vital role in developing regulations, stopping supply chain attacks, and diminishing other threats to our way of life.

While new issues are always emerging in the world of cybersecurity, some have been present since the beginning, such as what role cybersecurity should play in government operations and, conversely, what role government should play in cybersecurity. The answer to this question continues to shift and evolve over time, but each new leap in technology introduces additional considerations. As we move into the AI era, how can government best keep citizens safe without constraining innovation and the free market — and how can the government use its defensive capabilities to retain an edge in the conflicts of tomorrow?

The day’s first session, “Cybersecurity and Military Defense in an Increasingly Digital World,” offered a deep dive into the latter question. Over the past 20 years, military conflicts have moved from involving just Land, Air and Sea to also being fought in Space and Cyber. While superior technology has given us an upper hand in previous conflicts, in some areas our allies — and our adversaries — are catching up or even surpassing us. In each great technological leap, companies and countries alike ascend and recede, and to keep our edge in the conflicts of the future, the U.S. will need to shed complacency, develop the right policies, move toward greater infrastructure security and tap the capabilities of the private sector.

SonicWall in particular is well-positioned to work with the federal government and the military. For years, we’ve helped secure federal agencies and defense deployments against enemies foreign and domestic, and have woked to shorten and simplify the acquisition and procurement process. Our list of certifications includes FIPS 140-2, Common Criteria, DoDIN APL, Commercial Solutions for Classified (CSfC), USGv6, IPv6 and TAA and others. And our wide range of certified solutions have been used in a number of government use cases, such as globally distributed networks in military deployments and federal agencies, tip-of-the-spear, hub-and-spoke, defense in-depth layered firewall strategies and more.

Because Zero Trust is just as important for federal agencies as it is for private sector organizations, SonicWall offers the SMA 1000, which offers Zero Trust Network Architecture that complies with federal guidelines, including the DoDIN APL, FIPS and CSfC, as well as the U.S. National Cybersecurity Strategy.

This new strategy was at the center of the day’s next session. In “The National Cyber Strategy as Roadmap to a Secure Cyber Future,” panelists outlined this strategic guidance, which was released just two months ago and offered a roadmap for how the U.S. should protect its digital ecosystem against malicious criminal and nation-state actors. The guidance consists of five pillars, all of which SonicWall is in accord with:

Pillar One: Defend Critical Infrastructure
SonicWall offers several security solutions that align with Pillar One, including firewalls, intrusion prevention, VPN, advanced threat protection, email security, Zero-Trust network access and more. We’re also working to align with and conform to NIST SSDF and NIST Zero Trust Architecture standards.
Pillar Two: Disrupt and Dismantle Threat Actors

SonicWall uses its Email Security to disrupt and mitigate the most common ransomware vector: Phishing. And in 2022 alone, we helped defend against 493.3 million ransomware attacks.

Pillar Three: Shape Market Forces to Drive Security and Resilience

This pillar shifts liability from end users to software providers that ignore best practices, ship insecure or vulnerable products or integrate unvetted or unsafe third-party software. And as part of our efforts to aign with the NIST SSDF, we’re implementing a Software Bill of Materials (SBOM).

Pillar Four: Invest in a Resilient Future

Given CISA’s prominence in this guidance, any regulations created will likely include threat emulation testing, and will likely be mapped to threat techniques, such as MITRE ATT&CK. SonicWall Capture Client (our EDR solution) is powered by SentinelOne, which has been a participant in the MITRE ATT&CK evaluations since 2018 and was a top performer in the 2022 Evaluations.

Pillar Five: Forge International Partnerships to Pursue Shared Goals

An international company, SonicWall recognizes the importance of international partnerships and works to comply with global regulations such as GDPR, HIPAA, PCI-DSS and more. By sharing threat intelligence and collaborating no mitigation strategies, we work with governments and the rest of the cybersecurity community to pursue shared cybersecurity goals.

And with the continued rise in cybercrime, realizing these goals has never been more important. In “The State of Cybersecurity: Year in Review,” Mandiant CEO Kevin Mandia summarized findings from the 1,163 intrusions his company investigated in 2022. The good news, Mandia said, is that we’re detecting threats faster. In just ten years, we’ve gone from averaging 200 days to notice there’s a problem, to just 16 days currently — but at the same time, an increase in the global median dwell time for ransomware shows there’s still work to be done.

Mandia also outined the evolution of how cybercriminals are entering networks, from Unix platforms, to Windows-based attacks, and from phishing, to spearphishing to vulnerabilities — bringing patch management once again to the fore.

Deep within the RSAC Sandbox, where today’s defenders learn, play and test their skills, panelists convened to discuss how to stop attackers’ relentless attempts to shift left. “Software Supply Chain: Panel on Threat Intel, Trends, Mitigation Strategies” explained that while the use of third-party components increases agility, it comes with tremendous risk. More than 96% of software organizations rely on third-party code, 90% of which consists of open source—but the developers of this software are frequently single individuals or small groups who may not have time to incorporate proper security, or even know how. Our current strategy of signing at the end isn’t enough, panelists argued—to truly ensure safety, signing should be done throughout the process (otherwise known as “sign at the station”).

Israel provides an example of how a country can approach the issue of software supply chain vulnerability — among other things, the country has created a GitHub and browser extension allowing developers to check packages for malicious code — but much work would need to be done to implement the Israel model in the U.S. AI also provides some hope, but given its current inability to reliably detect malicious code, we’re still a long way from being able to rely on it. In the meantime, organizations will need to rely on tried-and-true solutions such as SBOMs to help guard against supply chain attacks in the near future.

But while AI has tremendous potential to help defenders, it also has terrible potential to aid attackers. In “ChatGPT: A New Generation of Dynamic Machine-Based Attacks,” the speakers highlighted ways that attackers are using the new generation of AI technology to dramatically improve social engineering attempts, expand their efforts to targets in new areas, and even write ransomware and other malicious code. In real time, the speakers demonstrated the difference between previous phishing emails and phishing generated by ChatGPT, including the use of more natural language, the ability to instantly access details about the target and the ability to imitate a leader or colleague trusted by the victim with a minimum of effort. These advancements will lead to a sharp increase in victims of phishing attacks, as well as things like Business Email Compromise.

And while there are guardrails in place to help prevent ChatGPT from being used maliciously, they can be circumvented with breathtaking ease. With the simple adjustment of a prompt, the speakers demonstrated, ransomware and other malicious code can be generated. While this code isn’t functional on its own, it’s just one or two simple adjustments away — and this capability could be used to rapidly increase the speed with which attacks are launched.

These capabilities are especially concerning given the rise in state-sponsored attacks. In “State of the Hack 2023: NSA’s Perspective,” NSA Director of Cybersecurity Rob Joyce addressed a packed house regarding the NSA’s work to prevent the increasing wave of nation-state threats. The two biggest nation-state threats to U.S. cybersecurity continue to be Russia and China, with much of the Russian effort centering around the U.S.’ assistance in the Russia/Ukraine conflict.

As we detailed in our SonicWall 2023 Cyber Threat Report, since the beginning of the conflict, attacks by Russia’s military and associated groups have driven a massive spike in cybercrime in Ukraine. The good news, Joyce said, is that Russia is currently in intelligence-gathering mode when it comes to the U.S., and is specifically taking care not to release large-scale NotPetya-type attacks. But Russia also appears to be playing the long game, and is showing no signs of slowing or scaling back their efforts.

China also appears to be biding its time — but unlike Russia, whose efforts appear to be focused around traditional military dominance, China is seeking technological dominance. Exploitation by China has increased so much that we’ve become numb to it, Joyce argued. And since these nation-state sponsored attackers don’t incur much reputational damage for their misdeeds, they’ve become increasingly brazen in their attacks, going so far as to require any citizen who finds a zero-day to pass details to the government and hosting competitions for building exploits and finding vulnerabilities. And the country is also making efforts to influence international tech standards in an attempt to tip scales in their favor for years to come.

The 2023 RSA Conference has offered a wealth of information on a wide variety of topics, but it will soon draw to a close. Thursday is the last day to visit the SonicWall booth (#N-5585 in Moscone North) and enjoy demos and presentations on all of our latest technology. Don’t head home without stopping by — and don’t forget to check back for the conclusion of our RSAC 2023 coverage!

Source :
https://blog.sonicwall.com/en-us/2023/04/rsa-report-cybersecurity-is-national-security/

Stay in your flow with Microsoft 365 on Microsoft Edge

Microsoft Edge Windows 11 Windows 10 Office for business

Microsoft is always striving to improve and streamline our product experiences—offering a new way to use the classic Microsoft Outlook app on Windows and the Microsoft Edge web browser.

If you have a Microsoft 365 Personal or Family subscription, browser links from the Outlook app will open in Microsoft Edge by default, right alongside the email they’re from in the Microsoft Edge sidebar pane. This allows you to easily access, read, and respond to the message using your matching authenticated profile. No more disruptive switching—just your email and the web content you need to reference, in a single, side-by-side view. And we’re always optimizing the sidebar in Microsoft Edge to give you useful content and tools while you’re browsing so you don’t have to toggle back and forth between windows or even other tabs—whether you’re shopping online or working in a Microsoft 365 web app.

In the future, links from your Microsoft Teams messages will also open in Microsoft Edge by default to help you stay engaged in conversations as you browse the web.

Learn more about multitasking smarter with Microsoft 365 and Edge.

Ultimately though, if this experience isn’t right for you, you can turn off this feature the first time it launches in Microsoft Edge, and then in Outlook settings at any time after that.

FAQ

Why is Microsoft making this change?

To improve your experience between email and browsing—letting you see them both at the same time, in the same place. No more switching back and forth between apps.
To provide a unique experience—at Microsoft, we strive to create the best customer experience across our products.
To reduce task switching and improve workflow and focus—by opening browser links in Microsoft Edge, the original message in Outlook can be viewed alongside web content to easily access, read, and respond to the message, using the matching authenticated profile.

Will this replace my default browser setting in Windows?

No, this only impacts links opened from Microsoft Outlook on Windows and you have the option to turn off this feature in Outlook settings.

I want to open links with the browser set as the default in Windows Settings.  How do I do that?

You can choose your preferred browser for opening links from Outlook the first time it launches in Microsoft Edge. After that you can change this setting in Outlook at any time—select File > Options > Advanced > Link handling and choose your preferred browser from the dropdown menu.

In Outlook, go to File.
Select Options.
Select Advanced > Link handling and choose your preferred browser from the dropdown menu.

Will this change affect me if I’m using a Mac?

No, this change will only be applied to Windows 10 and Windows 11 devices.

Send us feedback

Please let us know what you think about the new experience in one of two ways:

In Microsoft Edge, go to Settings and more > Help and feedback > Send feedback. Follow the on-screen instructions and select Send.
Press Alt + Shift + I on your keyboard. Follow the on-screen instructions and select Send.

Source :
https://support.microsoft.com/en-au/topic/stay-in-your-flow-with-microsoft-365-on-microsoft-edge-b0e1a1c1-bd62-462c-9ed5-5938b9c649f0

Top 27 WordPress Security Vulnerabilities You Need To Know

Just the idea of WordPress Security Vulnerabilities can be daunting, and even a little scary, for some people.

We want to put an end to that.

In this article we’ll dispel some of the confusion and aim to reduce the anxiety that surrounds this topic. We’ll outline the big ticket items and provide clear, actionable advice on steps you can take to protect your WordPress sites.

Before we can talk about WordPress Security Vulnerabilities, let’s get clear on what exactly we mean.

What Is A WordPress Vulnerability?

When we think of vulnerabilities, the first thing to come to mind is usually publicly known software vulnerabilities. They often allow for some form of directed, specific attack against susceptible code.

This certainly is one type of vulnerability, as you’ll see below. But for the purposes of this article, we’re considering anything that makes your website susceptible to attack – anything that puts you at a disadvantage.

You can’t hope to fight hackers if you’re not aware of the weaknesses that your enemy will exploit.

This article will arm you with practical know-how to strengthen your weaker areas and give you the power and confidence to fight back.

Without further ado, let’s get into it.

#1 Outdated WordPress Core, Plugins, Themes

The single leading cause of WordPress site hacking is outdated WordPress software. This includes Plugins, Themes, and the WordPress Core itself.

The simple act of keeping all your plugins and themes up-to-date will keep you protected against the vast majority of vulnerabilities, either publicly known or “unknown”.

A known vulnerability is one that has been discovered, typically by a dedicated researcher, and published publicly – see #6 below. But code vulnerabilities that aren’t publicly known are also important to be aware of.

Any good software developer is constantly improving their skills and their code. Over time, you can expect their code to improve, so keeping software updated ensures that you’re running only the best code on your sites.

How to protect against outdated WordPress software

We recommend making “WordPress Updates” a regular part of your weekly maintenance schedule. Block out some time every single week to get this critical work done.

The WordPress team regularly releases bug-fixing patches for the Core, and since WordPress 3.7+, these are installed automatically. It’s possible to disable that feature, but we strongly recommend that you never do.

# 2 Insecure WordPress Web Hosting

Your WordPress site is only as secure as the infrastructure that hosts it.

This is perhaps the most overlooked area of website security, and is, in our opinion, so critical that we place it in the top-3 in this list. #3 is closely related to this item, so make sure you check that out too.

If your web host doesn’t make server security a priority, then your server will get gradually more vulnerable over time. We see this all the time when customers write to our support team asking for help, only to discover that their web server is running on really, really old libraries.

This happens when the web host isn’t proactive in maintaining the server software that powers the websites of their customers.

Proactive maintenance by the web host has a cost, however. And if you’re paying bargain basement prices, then you can expect a corresponding level of service. That’s not to say that cheap web hosting is inherently insecure, and expensive web hosting isn’t. Not at all, but there is definitely a correlation between quality of web hosting and the price you pay.

How to protect against insecure WordPress web hosting

Cost of web hosting is only 1 indicator of quality. If your WordPress website is important to you or your business, then asking questions from the host about server security and ongoing maintenance should be part of your due diligence process.

You can take on recommendations from colleagues and friends, but never substitute their opinions with your own due diligence. Be prepared to invest in your hosting, as this will not only impact your security, but also your hosting reliability, uptime, and performance.

If you haven’t already done so, talk to your host today and ask them how they maintain the server that host your sites. Not in general terms, but ask them what their actual maintenance and update schedule is.

If you’re not happy with your answers and support, find a new host that will give you answers that you like. Never be afraid to switch service providers.

# 3 WordPress Web Hosting Site Contamination

This is related to the discussion above on web hosting quality. Generally speaking, the cheaper the web hosting, the more corners that will be cut in the service quality. This includes shared web server hosting configuration.

Here’s an over-simplified range of approaches in hosting websites:

Host all sites within the same vhost*
Host each site in separate vhosts, on the same, shared server
Host each site on a separate VPS (Virtual Private Servers) on the same server
Host each site on a separate dedicated server

*vhost is short for “virtual host”, that acts as a semi-independent container for hosting a website

As you move down the list, the cost increases, but the risk of contamination between websites increases. The 1st on the list is by-far the most dangerous, but is unfortunately the most common. This is where you might see something like:

/public_html/mywebsite1_com/
/public_html/mywebsite2_com/
/public_html/mywebsite3_com/
/public_html/mywebsite4_com/
/public_html/mywebsite5_com/

… when you look at the file system of the hosting account.

This is terrible for cross-site contamination as there is absolutely no isolation between individual websites. If any 1 of these sites becomes infected with malware, then you must assume the entire collection of sites is infected.

That’s a lot of cleanup work.

How to protect against web hosting site contamination

You’ll want to ensure that all your websites are, at the very least, hosted within their own vhost.

You could separate sites even further with separate VPSs, but you’ll pay more for it.

You’ll need to choose the type of hosting that best suits your expertise and budget.

If you can avoid it, please steer clear of hosting multiple sites within the same vhost, and if you are doing this already, look to gradually migrate these sites to their own independent vhosts as soon as possible.

For an idea, have a look at how we go about hosting many of our smaller WordPress sites.

# 4 Non-HTTPS Protection

Internet traffic sent via plain HTTP doesn’t encrypt the data transmitted between the website and the user’s browser, making it vulnerable to interception and tampering.

To avoid this, a technology known as Secure HTTP (HTTPS) is used.

Secure HTTPS is provided through the use of SSL/TLS certificates. It’s impossible to verify the identity of a website without certificates, and sensitive information such as login credentials, payment details, and personal information can be intercepted easily.

How to solve Non-HTTPS traffic

All WordPress websites should be using HTTPS by default. SSL Certificates are available for free with the LetsEncrypt service, and many web hosts provide this as-standard.

If your webhost doesn’t supply free LetsEncrypt Certificates, look to move hosts ASAP.

# 5 Insecure File Management (FTP) Vulnerability

Secure File Management is similar to the previous item on secure web/internet communications. If you’re transferring files to and from your web server using a tool like FTP, then this will typically require logging in with a username and password. If you’re not using a secure version of FTP, then you’re transmitting your username and password in plain text which can potentially be intercepted and used to compromise your server.

How to solve Insecure File Management

Practically all web hosts offer secure FTP (either FTPS or SFTP) as standard, but you should check with your hosting provider on whether that’s what you’re using and if not, how to switch.

Always use secure methods of file management. It’s just as easy to use than the insecure methods.

# 6 Known Plugin and Theme Vulnerabilities

Known vulnerabilities is what typically comes to mind when we discuss the topic of WordPress Vulnerabilities. When you’re told to upgrade because there’s a vulnerability, it basically means: a vulnerability has been discovered in the code of a plugin/theme that allows a hacker to perform a malicious attack.

By upgrading the plugin/theme, the vulnerable code has been fixed to prevent said attack.

Each vulnerability is different. Some are severe, some are trivial. Some are hard to exploit, others are easy to exploit.

The worst type of vulnerability are those that are severe, but easy to exploit.

Unfortunately, there is very little nuance in the way vulnerabilities are discussed publicly and so they’re all communicated as being catastrophic. This is not the case.

Of course, some vulnerabilities really are brutal, but many are not.

The point I’m trying to make is that you don’t need to stress about them. All you need to do is stay on top of vulnerability alerts and if your site is using a plugin or theme with a known vulnerability, then you need to update it as soon as possible.

The pseudo-standard practice for vulnerabilities reporting is this:

Existence of vulnerability is reported to the developer
Developer fixes the vulnerability and releases an update
Users update their plugins/themes
Some time passes, say 30 days
Vulnerability details are released to the general public after enough time has passed to allow most people to upgrade the affected plugin/theme.

This brings us back to the first item on our list of vulnerabilities. If you’re performing regular maintenance on your WordPress sites, the likelihood that you’ll be susceptible to a vulnerability is slim-to-none, as you’ll have updated the affected plugin/theme, and you’re already protected.

The problem arises when you don’t regularly update your assets and you’re left with a known vulnerability on your site.

How to solve Known Vulnerabilities

Keeping on top of your WordPress updates is the best way to stay ahead of this type of vulnerability.

Alongside this, you could also use a WordPress security plugin, such as ShieldPRO, that will alert you when there’s a known vulnerability present on your website, and even automatically upgrade plugins when this is the case.

# 7 Untracked File Modifications

At the time of writing this article, WordPress 6.2 ships with over 3,800 PHP and Javascript source files. And that’s just the WordPress core. You’ll have many, many more files in your plugins and themes directories.

An Indicator of Compromise (IoC) that a WordPress site has been hacked is when a file is modified on your WordPress installation, or even added to the site, that shouldn’t be. If this ever happens, you want to know about it as quickly as possible.

The only way to do this reliably is to regularly scan all your files – at least once per day. This involves taking each file in-turn and checking whether its contents have changed from the original file, or whether it’s a file that doesn’t belong.

How to protect against untracked file modifications

Nearly all WordPress security plugins offer this scanning feature, at least for WordPress core files.

But you’ll want to also scan your plugins and themes, too. Not all WordPress security plugins offer this, so you’ll need to check whether this is supported. ShieldPRO supports scanning for all plugins and themes found on WordPress.org.

An additional complication exists for premium plugins and themes, however. Since premium plugins are only available for download from the developers’ sites, the source files for these plugins are not available for us to check against. The developers at ShieldPRO, however, have built a crowdsource-powered scanning system for premium plugins and themes so you can check these also. At the time of writing, this feature isn’t available anywhere else.

# 8 wp-config.php File Changes

If you download the source files for WordPress, you’ll discover there is no wp-config.php file. This file is often created by customising the wp-config-sample.php file with the necessary information. Since there is no universal content for the wp-config.php file, there is no way to scan this file for changes (as outlined in the previous item on this list).

In our experience, the wp-config.php file and the root index.php files are the files that are most often targeted when malware is inserted into a WordPress site, but it’s impossible to scan them using existing techniques.

You will need to constantly keep an eye on these files and be alert for changes.

How to protect against changes to `wp-config.php` files

One approach is to adjust the file system permissions on the file itself. This can be quite complicated so you may need technical assistance to achieve this. If you can restrict the permissions of the file so that it may only be edited by specific users, but readable by the web server, then you’ll have gone a long way in protecting it.

However, this poses another problem. Many WordPress plugins will try to make adjustments to these files automatically, so restricting access may cause you other problems.

The developers at ShieldPRO have custom-built the FileLocker system to address this issue.

It takes a snapshot of the contents of the files and alerts you as soon as they change. You’ll then have the ability to review the precise changes and then ‘accept’ or ‘reject’ them.

# 9 Malicious or Inexperienced WordPress Admins

With great power comes great responsibility.

A WordPress admin can do anything to a website. They can install plugins, remove plugins, adjust settings, add other users, add other admins. Anything at all.

But this is far from ideal when the administrator is inexperienced and likely to break things. It’s even worse if an adminaccount is compromised and someone gains unauthorized access to a site.

For this reason we always recommend adopting the Principle of Least Privilege (PoLP). This is where every user has their access privileges restricted as far as possible, but still allow them to complete their tasks.

This is why WordPress comes with built-in user roles such as Author and Editor, so that you can assign different permissions to users without giving them access to everything.

How to protect malicious or inexperienced administrators

As we’ve discussed, you should adopt PoLP and restrict privileges as far as possible.

Another approach that we’ve taken with Shield Security is to restrict a number of administrator privileges from the administrators themselves. We call this feature “Security Admin” and it allows us to lockout admin features from the everyday admin, such as:

Plugins management (install, activate, deactivate)
WordPress options control (site name, site URL, default user role, site admin email)
User admin control (creating, promoting, removing other admin users)
and more…

With the Security Admin feature we’re confident that should anyone gain admin access to the site, or already have it, they are prevented from performing many tasks that could compromise the site.

# 10 Existing Malware Infections

Think of malware as an umbrella term for any code that is malicious. Their purpose is wide-ranging, including:

stealing user data,
injecting spam content e.g. SEO Spam,
redirecting traffic to nefarious websites,
backdoors that allow unfettered access to the site and its data
or even taking over control of the website entirely

How to protect against WordPress Malware infections

Use a powerful malware scanner regularly on your WordPress sites to detect any unintended file changes and possible malware code. Examine all file changes and suspicious code as early as possible, and remove it.

# 11 WordPress Brute Force Login Attacks

WordPress brute force attacks attempt to gain unauthorized access to a website by trying to login using different username and password combinations.

These attacks are normally automated and there’s no way to stop them manually.

How to protect against brute force login attacks

You’ll need to use a WordPress security plugin, such as ShieldPRO, to detect these repeated login requests, and block the IP addresses of attackers automatically.

A powerful option is to use a service like CloudFlare to add rate limiting protection to your WordPress login page.

We also recommend using strong, unique (not shared with other services) passwords. You can use ShieldPRO to enforce minimum password strength requirements.

# 12 WordPress SQL Injection

WordPress SQL injection refers to attempts by an attacker to use carefully crafted database (MySQL) statements to read or update data residing in the WordPress database.

This is normally achieved through sending malicious data through forms on your site, such as search bars, user login forms, and contact forms.

If the SQL injection is successful, the attacker could potentially gain unauthorized access to the website’s database. They are free to steal sensitive information such as user data or login credentials, or if the injection is severe enough, make changes to the database to open up further site access.

How to protect against SQL injection attacks

The best protection against SQL injection attacks is defensive, well-written software. If the developer is doing all the right things, such as using prepared statements, validating and sanitizing user input, then malicious SQL statements are prevented from being executed.

This brings us back to item #1 on our list: keep all WordPress assets updated.

As further protection, you’ll want to use a firewall that detects SQL injection attacks and blocks the requests. ShieldPRO offers this as-standard.

# 13 Search Engine Optimization (SEO) Spam Attack

WordPress Search Engine Optimization (SEO) spam refers to manipulation of search engine results and rankings of a WordPress website.

SEO spam can take many forms, such as keyword stuffing, hidden text and links, cloaking, and content scraping.

This type of attack normally involves modification of files residing on the WordPress site, that will then cause the SPAM content to be output when the site is crawled by Google.

How to protect against SEO SPAM attacks

Ensuring your site is registered with Google Webmaster Tools and staying on top of any alerts is a first step in monitoring changes in your website’s search engine visibility.

As mentioned earlier, these sorts of attacks normally rely on modifying files on your WordPress site, so regular file scanning and review of scan results will help you detect file changes early and revert anything that appears malicious.

# 14 Cross-Site Scripting (XSS) Attack

WordPress Cross-Site Scripting (XSS) is where an attacker injects malicious scripts into a WordPress website’s web pages that is then automatically executed by other users. The attacker can use various methods to inject the malicious scripts, such as through user input fields, comments, or URLs.

This attack vector can potentially steal user data or have the user unintentionally perform other malicious actions on the website.

How to protect against XSS attacks

The prime responsibility for prevention of this attack lies with the software developer. They must properly sanitize and validate all user input to ensure they are as expected.

Security plugins may also be able to intercept the XSS payloads, but this is less common. The only thing that you, as the WordPress admin, can do is ensure that all WordPress assets (plugins & themes) are kept up-to-date, and that you’re using vetted plugins from reputable developers. (See the section on Nulled Plugins below)

# 15 Denial of Service Attacks (DoS)

WordPress Denial of Service (DoS) attacks attempt to overwhelm a WordPress server with a huge volume of traffic.

By exhausting the server resources, it renders the website inaccessible to legitimate users. This would be disastrous for, say, an e-commerce store.

How to protect against DoS attacks

DoS attacks can be simple to implement for an attacker, but they’re also relatively straightforward to prevent. Using traffic limiting, you can reduce the ability of an attacker to access your site and consume your resources.

Choosing web hosting that is sized correctly with enough resources to absorb some attacks, and even using a provider that implements DoS as part of their service offering will also help mitigate these attacks.

It should be noted that if the DoS attack is large enough, no WordPress plugin will be able to mitigate it. You’ll need the resources of a WAF service, such as CloudFlare, to ensure your web server is protected.

# 16 Distributed Denial of Service Attacks (DDoS)

A Distributed Denial of Service attack is the same as a Denial of Service (#15) attack, except that there are multiple origins for the requests that flood your server.

These attacks are more sophisticated, and more costly, for the attacker, so they’re definitely rarer. But they have exactly the same effect on your site as a normal DoS attack.

How to protect against DDoS attacks

Most web hosts are just not sophisticated enough to withstand a sustained DDoS attack and you’ll need the services of a dedicated WAF, such as CloudFlare.

# 17 Weak Passwords

WordPress Weak Passwords vulnerability is the use of weak passwords by WordPress users. Weak passwords can be easily cracked by attackers, allowing them to gain unauthorized access to the WordPress website and take any type of malicious action.

Related to Brute Force attacks, automated tools can be used to systematically guess or crack weak passwords with ease.

How to protect against Weak Password

To prevent WordPress Weak Passwords Vulnerability, website owners should ensure that all users, including administrators, use strong passwords. Strong passwords are complex and difficult to guess, typically consisting of a combination of uppercase and lowercase letters, numbers, and special characters. Passwords should also be unique and not used across multiple, separate services.

WordPress doesn’t currently enforce strong passwords, so a WordPress security plugin, such as ShieldPRO, will be needed to enforce this.

# 18 Pwned Passwords

Pwned passwords vulnerability is where a WordPress user re-uses a password they’ve used elsewhere, but that has been involved in a data breach.

If a password is publicly known to have been used for a given user, and the same user re-uses it on another service, then it opens up a strong possibility that the user account could be compromised.

How to protect against Pwned Passwords

The Pwned Passwords service provides a public API that can be used to check passwords. You’ll want to enforce some sort of password policy that restricts the user of Pwned Passwords on your WordPress sites. Shield Security offers this feature as-standard.

# 19 Account Takeover Vulnerability

The previous items on this list discussed the importance of good password hygiene. But until we can go through all our accounts and ensure there is no password reuse, no pwned passwords, and all our passwords are strong, we can prevent any sort of account theft by ensuring that the person logging-in to a user account is, in-fact that person.

This is where 2-factor authentication (2FA) comes into play.

It is designed to help verify and ensure that the person logging in, is who they say they are and is a critical part of all good WordPress website security.

2-Factor authentication involves verifying another piece of information (a factor) that only that user has access to, alongside their normal password. This could be in the form of an SMS text or an email containing a 1-time passcode. It could also use something like Google Authenticator to generate codes every 30 seconds.

How to protect against account takeover vulnerability

WordPress doesn’t offer 2FA option to the user login process, by default. You will need a WordPress security plugin that offers this functionality. Shield Security has offered 2FA by email, Google Authenticator and Yubikey for many years now.

# 20 Nulled Plugins and Themes Vulnerabilities

“Nulled” plugins and themes are pirated versions of premium WordPress plugins and themes that are distributed without the permission of the original authors.

They pose significant security risks as they often contain malicious code or backdoors that can be used by hackers to gain unauthorized access to the website.

They may also include hidden links or spammy advertisements that can harm the website’s reputation or adversely affect its search engine rankings. (see SEO SPAM)

How to prevent vulnerabilities through nulled plugins and themes

The simple solution to this is to purchase premium plugins and themes from the original software vendor. A lot of work goes into the development of premium plugins and themes and supporting the developer’s work goes a long way to ensuring the project remains viable for the lifetime of your own projects.

# 21 Inactive WordPress Users Vulnerability

Inactive WordPress users vulnerability refers to the security risk posed by user accounts that haven’t been active for an extended period of time. Inactive accounts can become a target for hackers, as they may be easier to compromise than active accounts. Older accounts are more likely to have Pwned Passwords, for example.

If a hacker can gain access to an inactive user account, particularly an admin account, it’s an open door to your website data. Users automatically bypass certain checks and they can easily post spam or exploit vulnerable code on the website.

How to prevent vulnerabilities from inactive WordPress users

To prevent any vulnerability posed by inactive WordPress users, it’s important to follow these best practices:

Regularly monitor your website’s user accounts and delete any that are inactive.
Implement strong password policies for all user accounts (see above).
Use a security plugin that can detect and alert you to any suspicious user activity.
Use a security plugin that can automatically disable access to inactive user accounts.

# 22 Default Admin User Account Vulnerability

The WordPress default admin user account vulnerability refers to the security risk posed by the default “admin” username that is automatically created in the installation of any WordPress site.

This default account name is widely-known and a common target by hackers, since knowing a valid admin username is half the information needed to gain admin access.

If the admin isn’t using strong passwords or 2-factor authentication, then the site is particularly vulnerable.

How to protect against the admin user account vulnerability

It should be understood that changing the primary admin username of a WordPress site is “security through obscurity”, and that using strong passwords is required regardless of the username.

To eliminate this risk, you’ll want to rename the admin username on a site. The simplest method to do this is to create a new administrator account and then delete the old account. Please ensure that you transfer all posts/pages to the new admin account during this process. Always test this on a staging site to ensure there are no unforeseen problems.

# 23 WordPress Admin PHP File Editing Vulnerability

WordPress comes with the ability to edit plugin and theme files directly on a site, from within the WordPress admin area. The editors are usually linked to within the Plugins and Appearance admin menus, but have recently been moved to the Tools menu, in some cases.

Having this access is far from ideal as it allows any administrator to quietly modify files. This also applies to anyone that gains unauthorised access to an admin account.

There is usually no good reason to have access to these editors

How To Restrict Access To The WordPress PHP File Editors

The easiest way to prevent this is to disallow file editing within WordPress.

The Shield Security plugin has an option to turn off file editing.This can be found under the WP Lockdown module and is easy to turn on and off.

# 24 WordPress Default Prefix for Database Tables

WordPress’ default prefix for database tables represent a potential security risk. Similar to the previous item in the list, this is about reducing your surface area of attack by obscuring certain elements of your site.

If there are attempted attacks through SQL injection, then sometimes knowing the database table prefix can be helpful. If the attacker doesn’t know it, it may slow the attack or prevent it entirely.

The point is, obscuring the names of your database tables from would-be hackers won’t do any harm whatsoever, but may give you an edge over unsophisticated hacking attempts.

Hackers can exploit this vulnerability by using SQL injection attacks to gain unauthorized access to the website’s database. This can result in the theft of sensitive information or the compromise of the website’s security.

How To Change The WordPress Database Table Prefix

This is much more easily done at the time of WordPress installation – always choose a none-default (wp_) prefix.

Changing an existing prefix will require some MySQL database knowledge and we would recommend you employ the skills of a competent professional. And, as always, ensure you have a full and complete backup of your site.

It’s also important to note that, as mentioned above, you should be using a firewall or security plugin that can detect and block SQL injection attacks.

# 25 Directory Browsing Vulnerability

Web server directory browsing is where you can browse the contents of a web server from your web browser. This is far from ideal, as it supplies hackers information they may find useful to launch an attack.

From a hacker point of view, which would be better? Knowing which WordPress plugins are installed, or not knowing any of the WordPress plugins installed?

Clearly, more information is always better. And so we return to the principle of obscurity and reducing your surface area of attack by limiting access to information that hackers can use.

How To Prevent Directory Browsing Vulnerability

The easiest way to prevent this type of vulnerability is to directory browsing altogether.

This is done by adding a simple line to the site’s .htaccess file. Bear in mind that that this is only applicable to websites running the Apache web server (not nginx)

# 26 WordPress Security Keys/Salts

WordPress security keys are the means of encrypting and securing user cookies that control user login sessions. So they’re critical to good user security.

How To Improve User Security With Strong Keys/Salts

This is an easy one to implement for most admins. Here’s a quick how-to guide on updating your WordPress security keys.

# 27 Public Access To WordPress Debug Logs

Another security through obscurity item, the WordPress debug logs are normally stored in a very public location: /wp-content/debug.log

This is far from ideal as normally, without any specific configuration changes, this file is publicly accessible, and may expose some private site configuration issues through errors and logs data.

How To Eliminate Access to WordPress Debug Logs

If the file mentioned above is on your site, then you’ll want to move or delete it. You’ll then want to switch off debug mode on your site as you only need this active if you’re investigating a specific site issue.

Debug mode is typically toggled in your wp-config.php file so have a look in there for the lines:

define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true );

You can either:

Remove the lines entirely,
Comment out the lines, or
Switch true to false for both of these.

Bonus Security Tip: WordPress Website Backup

WordPress backup is often cited as a WordPress Security function. Strictly speaking, it’s not. It forms part of your disaster recovery plan. You might not have a formal DR plan, but having a website backup may be your implicit plan.

If anything ever goes wrong with your WordPress site, whether this is security related or not, having a backup is critical to being able to recover your site.

If you haven’t put a regular backup plan in place for your site, this is probably the first thing you need to do. Some of the items in this list need to be done with the option of restoring a backup in case of disaster.

Final Thoughts On Your WordPress Security

With WordPress being so widely used, it’s the obvious target for hackers to focus their efforts. This means the aspects you have to consider can be almost overwhelming, in your quest to secure your WordPress sites.

The process is never-ending and you might even address all of the items on this list, and still get hacked. But you have to keep at it.

Each step you take to lockdown your site, puts a bit more distance between you and the hackers. You might not always stay ahead of them, and you won’t always have time to address issues immediately, but we can assure that the more steps you take, the more secure your site will be.

Source :
https://getshieldsecurity.com/blog/wordpress-security-vulnerabilities/

How to block Shodan scanners

Shodan is a search engine which does not index web sites or web contents, but vulnerable devices on the internet. To set up this index and to keep it up to date, Shodan uses at least 16 scanners with different AS numbers and different physical locations.

In case you want to block those scanners, this guide might help.

Set up host definitions

First, set up host definitions in the firewall menu and put in the following hosts (it might be useful to put in the rDNS name as a hostname):

Known Shodan scanners (last updated 2022-02-16)

rDNS name	IP address	Location
shodan.io ((it is unclear if this is a scanner IP))	208.180.20.97	US
census1.shodan.io	198.20.69.74	US
census2.shodan.io	198.20.69.98	US
census3.shodan.io	198.20.70.114	US
census4.shodan.io	198.20.99.130	NL
census5.shodan.io	93.120.27.62	RO
census6.shodan.io	66.240.236.119	US
census7.shodan.io	71.6.135.131	US
census8.shodan.io	66.240.192.138	US
census9.shodan.io	71.6.167.142	US
census10.shodan.io	82.221.105.6	IS
census11.shodan.io	82.221.105.7	IS
census12.shodan.io	71.6.165.200	US
atlantic.census.shodan.io	188.138.9.50	DE
pacific.census.shodan.io	85.25.103.50	DE
rim.census.shodan.io	85.25.43.94	DE
pirate.census.shodan.io	71.6.146.185	US
ninja.census.shodan.io	71.6.158.166	US
border.census.shodan.io	198.20.87.98	US
burger.census.shodan.io	66.240.219.146	US
atlantic.dns.shodan.io	209.126.110.38	US
blog.shodan.io ((it is unclear if this is a scanner IP))	104.236.198.48	US
hello.data.shodan.io	104.131.0.69	US
www.shodan.io ((it is unclear if this is a scanner IP))	162.159.244.38	US

The additional following entries have been added on September, 2019:

rDNS name	IP address	Location
battery.census.shodan.io	`93.174.95.106`	SC
cloud.census.shodan.io	`94.102.49.193`	SC
dojo.census.shodan.io	`80.82.77.139`	SC
flower.census.shodan.io (PTR only)	`94.102.49.190`	SC
goldfish.census.shodan.io	`185.163.109.66`	RO
house.census.shodan.io	`89.248.172.16`	SC
inspire.census.shodan.io (PTR only)	`71.6.146.186`	US
mason.census.shodan.io	`89.248.167.131`	SC
ny.private.shodan.io	`159.203.176.62`	US
turtle.census.shodan.io (PTR only)	`185.181.102.18`	RO
sky.census.shodan.io	`80.82.77.33`	SC
shodan.io (PTR only)	`216.117.2.180`	US

The additional following entries have been added on February, 2022:

rDNS name	IP address	Location
einstein.census.shodan.io	`71.6.199.23`	US
hat.census.shodan.io	`185.142.236.34`	NL
red.census.shodan.io	`185.165.190.34`	US
soda.census.shodan.io	`71.6.135.131`	US
wine.census.shodan.io	`185.142.236.35`	NL

The additional following entries have been added on 21st September, 2022:

rDNS name	IP address	Location
wall.census.shodan.io	`66.240.219.133`	US
floss.census.shodan.io	`143.198.225.197`	US
dog.census.shodan.io	`137.184.95.216`	US
draft.census.shodan.io	`64.227.90.185`	US
can.census.shodan.io	`143.198.238.87`	US
pack.census.shodan.io	`137.184.190.205`	US
jug.census.shodan.io	`137.184.112.192`	US
elk.census.shodan.io	`137.184.190.188`	US
tab.census.shodan.io	`167.172.219.157`	US
buffet.census.shodan.io	`143.110.239.2`	US
deer.census.shodan.io	`143.198.68.20`	US

The additional following entries have been added on 30th September, 2022:

rDNS name	IP address	Location
sparkle.census.shodan.io	`137.184.190.194`	US
fish.census.shodan.io	`137.184.190.246`	US
heimdal.scan6x.shodan.io (PTR only)	`137.184.9.17`	US
gravy.scanf.shodan.io (PTR only)	`137.184.13.100`	US
scanme.scanf.shodan.io (PTR only)	`137.184.94.133`	US
frame.census.shodan.io (PTR only)	`137.184.112.103`	US
collector.chrono.shodan.io (PTR only)	`137.184.180.190`	US
ships.data.shodan.io	`143.198.50.234`	US

The additional following entries have been added on 30th September, 2022. These were obtained by using the above IP addresses and then scanning any /16 subnet with more than one IP address in it. They have not necessarily been seen scanning. Note the the same rDNS record can be returned by multiple IPs:

rDNS name	IP address	Location
green.census.shodan.io	`185.142.236.36`	NL
blue.census.shodan.io	`185.142.236.40`	NL
guitar.census.shodan.io	`185.142.236.41`	NL
blue2.census.shodan.io	`185.142.236.43`	NL
red2.census.shodan.io	`185.142.239.16`	NL
census2.shodan.io	`198.20.69.96/29`	US
census3.shodan.io	`198.20.70.112/29`	US
border.census.shodan.io	`198.20.87.96/29`	US
census4.shodan.io	`198.20.99.128/29`	NL
malware-hunter.census.shodan.io	`66.240.205.34`	US
refrigerator.census.shodan.io	`71.6.146.130`	US
board.census.shodan.io	`71.6.147.198`	US
tesla.census.shodan.io	`71.6.147.254`	US
thor.data.shodan.io	`71.6.150.153`	US
grimace.data.shodan.io	`71.6.167.125`	US
house.census.shodan.io	`89.248.172.7`	NL

Sources: own research, log reviews.

Contributor Note!
if you DROP ranges that were in the notorious “AS29073 Quasi Networks LTD” already, you’re already banning the “SC” (Seychelles) sources detailed above; those ranges have been inherited by AS202425. “AS9009 M247 Ltd” contributes to most of the “RO” (Romania) sources; furtherly M247 (AS9009) seem to be the exit point of most NordVPN/pureVPN and many low cost script-kiddies VPN. Firewalling them is usefull for `quietness. Interactions between shodan and m247 seems to be very close.

Contributor Note!

if you DROP ranges that were in the notorious “AS29073 Quasi Networks LTD” already, you’re already banning the “SC” (Seychelles) sources detailed above; those ranges have been inherited by AS202425. “AS9009 M247 Ltd” contributes to most of the “RO” (Romania) sources; furtherly M247 (AS9009) seem to be the exit point of most NordVPN/pureVPN and many low cost script-kiddies VPN. Firewalling them is usefull for `quietness. Interactions between shodan and m247 seems to be very close.

You might add a comment to each host, such as “scanner” or “shodan” to make clear why you added those.

It is possible to block other common scanners here, too. However, please keep in mind that this isn’t a technique which is very scalable. Please consider running an IPS, if possible.

Project 25499 scanners (last updated 2016-02-28)

rDNS name	IP address	Location
scanner01.project25499.com	98.143.148.107	US
scanner02.project25499.com	155.94.254.133	US
scanner03.project25499.com	155.94.254.143	US
scanner04.project25499.com	155.94.222.12	US
scanner05.project25499.com	98.143.148.135	US

Source: http://project25499.com/

Set up firewall group

Second, set up a firewall group and add all those host entries to it. Add a title and a comment to this firewall group. In this guide, we assume you have named the group “shodanscanners”.

Set up firewall rule

Third, create a new firewall rule. Set the “shodanscanners” group as source. For destination, use “standard networks” and set this to “any”. Set “rule action” to “drop”.

The setting “reject” is not recommended here, since the firewall will send an ICMP status message to the host(s) which triggered the firewall rule. By this, however, the host knows that there is something which at least sends ICMP errors back. To avoid this, “drop” is suitable because the network packets will be dropped silently and there is no way of telling (without additional scans) wether the target IP address is just down or drops network packages.

Enter a comment, if you want to and hit “add” to set the new firewall rule.

Please make sure that this rule is placed before rules which accept something (i.e. port forwarding rules) so that shodan scan traffic will be blocked instantly.

Reload the firewall engine to apply the new rule.

Limitations of this rule

The OpenVPN service will not be protected – OVPNINPUT firewall chain is above the chain where this rule will land.

Limitations of this guide

Nobody (and nothing) is perfect. This guide isn’t either. 😉

For example, if the IP addresses of the Shodan scanners change, your firewall rule will be probably useless and does not provide any protection against the scanners any more. Consider setting up an IPS for additional protection since some rules there will also block other scanners which are not mentioned here.

Blocking Shodan scanner is fine, but I want to block all scanners
This is basically possible. However, it is a nightmare to set up a firewall host group which covers all IPs which belong to scanners. (And it is also a nightmare to find out those IP addresses since most scanners do not just put them on their web sites…) In case you are thinking similar, setting up an IPS in combination with suitable rules (this is just one example, there are many out there) might be a solution for you.

Source :
https://wiki.ipfire.org/configuration/firewall/blockshodan

Preventing and Detecting Attacks Involving 3CX Desktop App

In this blog entry, we provide technical details and analysis on the 3CX attacks as they happen. We also discuss available solutions which security teams can maximize for early detection and mitigate the impact of 3CX attacks.

By: Trend Micro Research
March 30, 2023
Read time: 7 min (1870 words)

Updated on:

April 5, 2:39 a.m. EDT: We added Windows, Mac, and network commands to the Trend Micro Vision One™️ guide in the linked PDF.
April 4, 3:29 a.m. EDT: We added Trend Micro XDR filters to the solutions.
April 3, 2:33 a.m. EDT: We added details on d3dcompiler_47.dll‘s abuse of CVE-2013-3900 to make it appear legitimately signed.
April 1, 1:50 a.m. EDT: We added a guide on how Vision One can be used to search for potential threats associated with the 3CX desktop app.
March 31, 11:07 p.m. EDT: We added technical details, an analysis of the info-stealer payload, and information on Trend Micro XDR capabilities for investigating and mitigating risks associated with the 3CX desktop app.
March 31, 3:00 a.m. EDT: We added the execution flow diagram, a link to Trend Micro support page, and a list of Mac IOCs and detection names.

In late March 2023, security researchers revealed that threat actors abused a popular business communication software from 3CX — in particular, the reports mention that a version of the 3CX VoIP (Voice over Internet Protocol) desktop client was being employed to target 3CX’s customers as part of an attack.

On its forums, 3CX has posted an update that recommends uninstalling the desktop app and using the Progressive Web App (PWA) client instead. The company also mentioned that they are working on an update to the desktop app.

For a more comprehensive scope of protection against possible attacks associated with the 3CX Desktop App, the Trend Micro XDR platform can help organizations mitigate the impact by collecting and analyzing extensive activity data from various sources. By applying XDR analytics to the data gathered from its native products, Trend Micro XDR generates correlated and actionable alerts.

Trend Micro customers can also take advantage of Trend Micro Vision One™ to search for and monitor potential threats associated with the 3CX Desktop App, and to better understand observed attack vectors. For more information on how to utilize Trend Micro Vision One features, you may download the PDF guide here.

Additional guidance for Trend Micro customers including help with protection and detection can be found on our support page.

What is the compromised application?

The 3CX app is a private automatic branch exchange (PABX) software that provides several communication functions for its users, including video conferencing, live chat, and call management. The app is available on most major operating systems, including Windows, macOS, and Linux. Additionally, the client is available as a mobile application for both Android and iOS devices, while a Chrome extension and the PWA version of the client allow users to access the software through their browsers.

The issue was said to be limited to the Electron (non-web versions) of their Windows package (versions 18.12.407 and 18.12.416) and macOS clients (versions 18.11.1213, 18.12.402, 18.12.407 and 18.12.416).

According to the company’s website, more than 600,000 businesses and over 12 million daily users around the world use 3CX’s VoIP IPBX software.

How does the attack work?

The attack is reportedly a multi-stage chain in which the initial step involves a compromised version of the 3CX desktop app. Based on initial analysis, the MSI package (detected by Trend Micro as Trojan.Win64.DEEFFACE.A and Trojan.Win64.DEEFFACE.SMA) is the one that is compromised with possible trojanized DLLs, since the .exe file has the same name.

The infection chain begins with 3CXDesktopApp.exe loading ffmpeg.dll (detected as Trojan.Win64.DEEFFACE.A andTrojan.Win64.DEEFFACE.SMA). Next, ffmpeg.dll reads and decrypts the encrypted code from d3dcompiler_47.dll (detected as Trojan.Win64.DEEFFACE.A and Trojan.Wind64.DEEFACE.SMD3D).

The decrypted code seems to be the backdoor payload that tries to access the IconStorages GiHub page to access an ICO file (detected as Trojan.Win32.DEEFFACE.ICO) containing the encrypted C&C server that the backdoor connects to in order to retrieve the possible final payload. In addition, d3dcompiler_47.dll also abuses CVE-2013-3900 to make it appear that it is legitimately signed.

As part of its attack routine, it contacts the servers noted in the list of indicators of compromise (IOCs) at the end of this blog entry. These domains are blocked by the Trend Micro Web Reputation Services (WRS).

Execution flow

Upon execution, the MSI package installer will drop the following files that are related to malicious behavior. Trend Micro Smart Scan Pattern (cloud-based) TBL 21474.300.40 can detect these files as Trojan.Win64.DEEFFACE.A.

3CXDesktopApp.exe: A normal file that is abused to load the trojanized DLL
ffmpeg.dll: A trojanized DLL used to read, load, and execute a malicious shellcode from d3dcompiler_47.dll
d3dcompiler_47.dll: A DLL appended with an encrypted shellcode after the fe ed fa ce hex string

Some conditions are necessary for execution. For example, the sleep timestamp varies depending on the following conditions: First, it checks if the manifest file is present, as well as if it is using a specified date. If the file is not present or if it is using the specified date, the timestamp will generate a random number and use the formula rand() % 1800000 + current date + 604800 (604,800 is seven days). After the date is computed, the malware will continue its routine.

Upon execution of 3CXDesktopApp.exe, ffmpeg.dll, which seems to be a trojanized or patched DLL, will be loaded. It will still contain its normal functionalities, but it will have an added malicious function that reads d3dcompiler_47.dll to locate an encrypted shellcode after the fe ed fa ce hex strings.

Figure 2. Reading "d3dcompiler_47.dll" and locating the “fe ed fa ce” hex string — Figure 2. Reading “d3dcompiler_47.dll” and locating the “fe ed fa ce” hex string

Upon decryption of the malicious shellcode using RC4 with the key, 3jB(2bsG#@c7, the shellcode will then try to access the GitHub repository that houses the ICO files containing the encrypted C&C strings that use Base64 encoding and AES + GCM encryption at the end of the image.

These B64 strings seem to be C&C domains that the shellcode tries to connect to for downloading other possible payloads. However, we were unable to confirm the exact nature of these payloads since the GitHub repository (raw.githubusercontent[.]com/IconStorages/images/main/) had already been taken down at the time of this writing. Note that the process exits when the page is inaccessible.

Figure 3. Code snippet showing the hard-coded GitHub repository

Figure 4. An ICO file from the GitHub repository

The above description applies to the Windows version. The behaviour of the Mac version is broadly similar, although it only uses a subset of the Windows C&C domains.

Info-stealer payload analysis

Based on our ongoing analysis of attacks on 3CX and the behaviors observed, the following section details what we know so far about the payload’s attack vector.

Payloads in investigated 3CX attacks are detected as TrojanSpy.Win64.ICONICSTEALER.THCCABC. Upon analysis of the payload named ICONIC Stealer, we discovered that if it is executed using regsvr32.exe as the DLL loader, it will display the following system error:

Figure 5. Error displayed upon executing the sample using "regsvr32.exe" — Figure 5. Error displayed upon executing the sample using “regsvr32.exe”

Meanwhile, if rundll32.exe is used as the DLL loader, it encounters a WerFault error and displays the following pop-up message:

Figure 6. Error displayed if "rundll32.exe" is used as the DLL loader — Figure 6. Error displayed if “rundll32.exe” is used as the DLL loader

This indicates that the sample must be loaded by a specific application to proceed to its malicious routine.

ICONIC Stealer then checks for a file named config.json under the folder “3CXDesktopApp.”

Figure 7. Checking for "config.json" — Figure 7. Checking for “config.json”

ICONIC Stealer was then observed to steal the following system information:

HostName
DomainName
OsVersion

The gathered data will then be converted into a text-string format.

Figure 8. Converting gathered data into a text-string format

ICONIC Stealer then proceeds to its last behavior, which steals browser data. It uses the function shown in Figure 9 to traverse the infected system using predefined directories related to the browser’s history and other browser-related information.

Figure 9. Function for traversing the infected system

The following figure shows a list of predefined strings:

The system directories on the following list compose the targets identified in the partial analysis of the ICONIC Stealer’s behavior. More information will be provided as this blog is updated.

AppData\Local\Google\Chrome\User Data
AppData\Local\Microsoft\Edge\User Data
AppData\Local\BraveSoftware\Brave-Browser\User Data
AppData\Roaming\Mozilla\Firefox\Profiles

Browser	Target information
Chrome	History
Edge	History
Brave	History
Firefox	places.sqlite

^{Table 1. The targeted section of each browser. Note that “places.sqlite” stores the annotations, bookmarks, favorite icons, input history, keywords, and the browsing history of visited pages for Mozilla Firefox.}

ICONIC Stealer was also found with the capability to limit the retrieved data to the first five hundred entries to ensure that the most recent browser activity is the data that is retrieved:

Figure 11. Limiting data to the first 500 entries

“UTF-16LE”, ‘SELECT url, title FROM urls ORDER BY id DESC LIMIT

“UTF-16LE”, ‘500’,0

“UTF-16LE”, ‘SELECT url, title FROM moz_places ORDER BY id DESC

“UTF-16LE”, ‘LIMIT 500’,0

Figure 12. Retrieved results stored on an allocated buffer

The gathered data will be passed to the main loader module to POST then back to the C&C server embedded in the main module.

What is its potential impact?

Due to its widespread use and its importance in an organization’s communication system, threat actors can cause major damage (for example, by monitoring or rerouting both internal and external communication) to businesses that use this software.

What can organizations do about it?

Organizations that are potentially affected should stop using the vulnerable version if possible and apply the patches or mitigation workarounds if these are available. IT and security teams should also scan for confirmed compromised binaries and builds and monitor for anomalous behavior in 3CX processes, with a particular focus on C&C traffic.

Meanwhile, enabling behavioral monitoring in security products can help detect the presence of the attack within the system.

Indicators of Compromise (IOCs)

SHA256	File name / details	Detection name
dde03348075512796241389dfea5560c20a3d2a2eac95c894e7bbed5e85a0acc Installer: aa124a4b4df12b34e74ee7f6c683b2ebec4ce9a8edcf9be345823b4fdcf5d868	3cxdesktopapp-18.12.407.msi (Windows)	Trojan.Win64.DEEFFACE.A
fad482ded2e25ce9e1dd3d3ecc3227af714bdfbbde04347dbc1b21d6a3670405 Installer: 59e1edf4d82fae4978e97512b0331b7eb21dd4b838b850ba46794d9c7a2c0983	(Windows)	Trojan.Win64.DEEFFACE.A
c485674ee63ec8d4e8fde9800788175a8b02d3f9416d0e763360fff7f8eb4e02	ffmpeg.dll	Trojan.Win64.DEEFFACE.A
7986bbaee8940da11ce089383521ab420c443ab7b15ed42aed91fd31ce833896	ffmpeg.dll	Trojan.Win64.DEEFFACE.A
11be1803e2e307b647a8a7e02d128335c448ff741bf06bf52b332e0bbf423b03	d3dcompiler.dll	Trojan.Win64.DEEFFACE.A
4e08e4ffc699e0a1de4a5225a0b4920933fbb9cf123cde33e1674fde6d61444f		Trojan.Win32.DEEFFACE.ICO
8ab3a5eaaf8c296080fadf56b265194681d7da5da7c02562953a4cb60e147423	Stealer	TrojanSpy.Win64.ICONICSTEALER.THCCABC

Here is the list of IOCs for Mac users:

SHA256	File name	Detection name
5a017652531eebfcef7011c37a04f11621d89084f8f9507201f071ce359bea3f	3CX Desktop App-darwin-x64-18.11.1213.zip	Trojan.MacOS.FAKE3L3CTRON.A
5407cda7d3a75e7b1e030b1f33337a56f293578ffa8b3ae19c671051ed314290	3CXDesktopApp-18.11.1213.dmg	Trojan.MacOS.FAKE3L3CTRON.A
fee4f9dabc094df24d83ec1a8c4e4ff573e5d9973caa676f58086c99561382d7	libffmpeg.dylib	Trojan.MacOS.FAKE3L3CTRON.A
5009c7d1590c1f8c05827122172583ddf924c53b55a46826abf66da46725505a	child macho file of libffmpeg.dylib	Trojan.MacOS.FAKE3L3CTRON.A
e6bbc33815b9f20b0cf832d7401dd893fbc467c800728b5891336706da0dbcec	3CXDesktopApp-18.12.416.dmg	Trojan.MacOS.FAKE3L3CTRON.A
a64fa9f1c76457ecc58402142a8728ce34ccba378c17318b3340083eeb7acc67	libffmpeg.dylib	Trojan.MacOS.FAKE3L3CTRON.A
87c5d0c93b80acf61d24e7aaf0faae231ab507ca45483ad3d441b5d1acebc43c	child macho file of libffmpeg.dylib	Trojan.MacOS.FAKE3L3CTRON.A

The following domains are blocked by Trend Micro Web Reputation Services (WRS)

akamaicontainer[.]com
akamaitechcloudservices[.]com
azuredeploystore[.]com
azureonlinecloud[.]com
azureonlinestorage[.]com
dunamistrd[.]com
glcloudservice[.]com
journalide[.]org
msedgepackageinfo[.]com
msstorageazure[.]com
msstorageboxes[.]com
officeaddons[.]com
officestoragebox[.]com
pbxcloudeservices[.]com
pbxphonenetwork[.]com
pbxsources[.]com
qwepoi123098[.]com
sbmsa[.]wiki
sourceslabs[.]com
visualstudiofactory[.]com
zacharryblogs[.]com

Trend Micro XDR uses the following filters to protect customers from 3CX-related attacks:

Filter	ID	OS
Compromised 3CX Application File Indicators	F6669	macOS, Windows
DLL Sideloading of 3CX Application	F6668	Windows
Web Reputation Services Detection for Compromised 3CX Application	F6670	macOS, Windows
Suspicious Web Access of Possible Compromised 3CX Application	F6673	Windows
Suspicious DNS Query of Possible Compromised 3CX Application	F6672	Windows

Trend Micro Malware Detection Patterns for Endpoint, Servers (Apex One, Worry-Free Business Security Services, Worry-Free Business Security Standard/Advanced, Deep Security with anti-malware, among others), Mail, and Gateway (Cloud App Security, ScanMail for Exchange, IMSVA):

Starting with Trend Micro Smart Scan Pattern (cloud-based) TBL 21474.200.40, known trojanized versions of this application are being detected as Trojan Win64.DEEFFACE.A.
The Mac version of this threat is detected as Trojan.MacOS.FAKE3L3CTRON.A.

Source :
https://www.trendmicro.com/en_us/research/23/c/information-on-attacks-involving-3cx-desktop-app.html

Privilege Escalation Vulnerability Patched Promptly in WP Data Access WordPress Plugin

On April 5, 2023 the Wordfence Threat Intelligence team initiated the responsible disclosure process for a vulnerability we discovered in WP Data Access, a WordPress plugin that is installed on over 10,000 sites. This flaw makes it possible for an authenticated attacker to grant themselves administrative privileges via a profile update, if the targeted site has the ‘Role Management’ setting enabled.

Wordfence Premium, Care, and Response users received a firewall rule to protect against any exploits targeting this vulnerability on April 5, 2023. Sites still using the free version of Wordfence will receive the same protection on May 5, 2023.

We performed our initial outreach to the developer on April 5, 2023, the same day we discovered the vulnerability. We received a response the same day and sent over the full details. The developer released a patch swiftly the next day on April 6, 2023.

We’d like to say a special thanks to the lead developer of WP Data Access, Peter Schulz, who provided an exemplary example of how security issues should be handled by responding immediately and releasing a patch the next day.

We strongly recommend ensuring that your site has been updated to the latest patched version of WP Data Access, which is version 5.3.8 at the time of this publication.

Vulnerability Summary from Wordfence Intelligence

Description: WP Data Access <= 5.3.7 – Authenticated (Subscriber+) Privilege Escalation
Affected Plugin: WP Data Access
Plugin Slug: wp-data-access
Affected Versions: <= 5.3.7
CVE ID: CVE-2023-1874
CVSS Score: 7.5 (High)
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Researcher/s: Chloe Chamberland
Fully Patched Version: 5.3.8

The WP Data Access plugin for WordPress is vulnerable to privilege escalation in versions up to, and including, 5.3.7. This is due to a lack of authorization checks on the multiple_roles_update function. This makes it possible for authenticated attackers, with minimal permissions such as a subscriber, to modify their user role by supplying the ‘wpda_role[]‘ parameter during a profile update. This requires the ‘Enable role management’ setting to be enabled for the site.

Vulnerability Analysis

WP Data Access is a WordPress plugin designed to make data table creation in WordPress more intuitive and easier to manage for site owners. One feature of the plugin is the ability to enable role management, which makes it possible for a site owner to create custom roles and assign multiple roles to different users. Unfortunately, this functionality was insecurely implemented making it possible for authenticated users to assign any role to themselves, including the administrative role.

Taking a closer look at the code, we see that the ‘multiple_roles_update‘ function used to assign a user’s new roles upon updating a profile is hooked via ‘’profile_update‘’. This hook is triggered immediately after any user profile is updated and it does not perform any sort of authorization checks on the user performing the action. As such, this means that any update to a user’s profile, including on the profile.php page, will invoke the hooked function ‘multiple_roles_update‘.

This makes it possible for any authenticated users with an account, such as subscribers, to invoke the ‘multiple_roles_update‘ function.

229	`$this->loader->add_action(` `'profile_update',` `$wpda_roles,` `'multiple_roles_update');`

If the associated function had a capability check, then it may have prevented these users from fully executing the function, however, that was not the case. Reviewing the hooked function, we see a check verifying that the role management setting is enabled, but nothing more. The function then determines the user and looks for the ‘wpda_role‘ array parameter from a given request. If present, it will process the supplied roles and add the role and applicable permissions to the user retrieved in the first step.

This made it possible for authenticated users, such as a subscriber, making profile updates to supply the ‘wpda_role‘ array parameter with any desired roles, such as administrator, during a profile update that would be granted immediately upon save of the profile updates.

5051525354555657585960616263646566676869707172737475767778798081828384 publicfunctionmultiple_roles_update( $user_id) { if( ! $this->is_role_management_enabled ) { return; } $wp_user= new\WP_User( $user_id); if( isset( $wp_user->data->user_login ) ) { $user_login= $wp_user->data->user_login; // Get access to editable roles global$wp_roles; if( isset( $_REQUEST['wpda_role'] ) && is_array( $_REQUEST['wpda_role'] ) ) { // Process roles $sanitized_roles= array(); foreach( $_REQUEST['wpda_role'] as$new_user_role) { // phpcs:ignore WordPress.Security.ValidatedSanitizedInput $sanitized_new_user_role= sanitize_text_field( wp_unslash( $new_user_role) ); // input var okay. $wp_user->add_role( $sanitized_new_user_role); $sanitized_roles[ $sanitized_new_user_role] = true; } // Remove unselected roles foreach( $wp_roles->roles as$role=> $val) { if( ! isset( $sanitized_roles[ $role] ) ) { $wp_user->remove_role( $role); } } } else{ // BUG!!! REMOVED!!! // When plugin role management is enabled, this removes all user roles when a user updates his profile. // foreach ( $wp_roles->roles as $role => $val ) { // $wp_user->remove_role( $role ); // } } }}</pre><pre>

As with any Privilege Escalation vulnerability, this can be used for complete site compromise. Once an attacker has gained administrative user access to a WordPress site they can then manipulate anything on the targeted site as a normal administrator would. This includes the ability to upload plugin and theme files, which can be malicious zip files containing backdoors, and modifying posts and pages which can be leveraged to redirect site users to other malicious sites.

Disclosure Timeline

April 5, 2023 – Discovery of the Privilege Escalation vulnerability in WP Data Access. Wordfence Premium, Care, and Response users receive a firewall rule to provide protection against any exploits that may target this vulnerability.
April 5, 2023 – We initiate contact with the plugin vendor asking that they confirm the inbox for handling the discussion.
April 5, 2023 – The vendor confirms the inbox for handling the discussion.
April 5, 2023 – We send over the full disclosure details. The vendor acknowledges the report and begins working on a fix.
April 6, 2023 – A fully patched version of the plugin, 5.3.8, is released.
May 5, 2023 – Wordfence free users receive the firewall rule.

Conclusion

In today’s post, we detailed a flaw in the WP Data Access plugin that enabled authenticated attackers, with at least subscriber-level access to a site, to elevate their privileges to that of a site administrator which could ultimately lead to complete site compromise. This flaw has been fully patched in version 5.3.8.

We recommend that WordPress users immediately verify that their site has been updated to the latest patched version available, which is version 5.3.8 at the time of this publication.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as this is a serious vulnerability that can lead to a complete site takeover.

If you are a security researcher, you can responsibly disclose your finds to us and obtain a CVE ID and get your name on the Wordfence Intelligence leaderboard.

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2023/04/privilege-escalation-vulnerability-patched-promptly-in-wp-data-access-wordpress-plugin/

Before Replacing a Disk

How to Replace a Disk

Cloud Key Gen2 Plus and Devices “Managed by Other”

Replacing a Disk in an Array

What are NIST Password Guidelines?

Quick List of NIST Password Guidelines

NIST Guidelines

Password length & processing

Accepted characters

Commonly used & breached passwords

Reduced complexity & password expiration

No more hints or knowledge-based authentication (KBA)

Password managers & two-factor authentication (2FA)

How Netwrix Can Help

FAQ

Tip #1: Clean up stale objects.

Tip #2: Make it easy for users to choose secure passwords.

Tip #3: Don’t let employees have admin privileges on their workstations.

Tip #4: Lock down service accounts.

Tip #5: Eliminate permanent membership in security groups.

Tip #6: Eliminate elevated permissions wherever possible.

Tip #7: Implement multifactor authentication (MFA)

Tip #8: Closely audit your Active Directory.

Tip #9: Secure DNS.

Tip #10: Regularly back up Active Directory.

Conclusion

Frequently Asked Questions

Key Best Practices

Use Group Nesting to Simplify Access Management.

Give each security group a unique, descriptive name.

Limit each group’s permissions to the bare minimum.

Make each user a member of only the required groups.

Track group activity and changes to security groups.

Pay attention to service accounts.

Have group owners review their groups regularly, and remove groups that are no longer needed.

Use privileged accounts only when required.

Always create a recovery plan.

Simplifying Security Group Management

Establish and enforce standards for naming groups.

Ensure the membership of security groups is accurate.

Establish an attestation process for security groups.

Set security groups to expire automatically.

Set a default group approver.

Conclusion

The role of government in stopping supply chain attacks and other threats to our way of life.

FAQ

Why is Microsoft making this change?

Will this replace my default browser setting in Windows?

I want to open links with the browser set as the default in Windows Settings. How do I do that?

Will this change affect me if I’m using a Mac?

Send us feedback

What Is A WordPress Vulnerability?

#1 Outdated WordPress Core, Plugins, Themes

How to protect against outdated WordPress software

# 2 Insecure WordPress Web Hosting

How to protect against insecure WordPress web hosting

# 3 WordPress Web Hosting Site Contamination

How to protect against web hosting site contamination

# 4 Non-HTTPS Protection

How to solve Non-HTTPS traffic

# 5 Insecure File Management (FTP) Vulnerability

How to solve Insecure File Management

# 6 Known Plugin and Theme Vulnerabilities

How to solve Known Vulnerabilities

# 7 Untracked File Modifications

How to protect against untracked file modifications

# 8 wp-config.php File Changes

How to protect against changes to wp-config.php files

# 9 Malicious or Inexperienced WordPress Admins

How to protect malicious or inexperienced administrators

# 10 Existing Malware Infections

How to protect against WordPress Malware infections

# 11 WordPress Brute Force Login Attacks

How to protect against brute force login attacks

# 12 WordPress SQL Injection

How to protect against SQL injection attacks

# 13 Search Engine Optimization (SEO) Spam Attack

How to protect against SEO SPAM attacks

# 14 Cross-Site Scripting (XSS) Attack

How to protect against XSS attacks

I want to open links with the browser set as the default in Windows Settings.  How do I do that?

How to protect against changes to `wp-config.php` files