Red Hat Security Advisory 2023-2097-03 - Red Hat Satellite is a systems management tool for Linux-based infrastructure. It allows for provisioning, remote management, and monitoring of multiple Linux deployments with a single centralized tool. Issues addressed include code execution, cross site scripting, denial of service, deserialization, improper neutralization, information leakage, and remote shell upload vulnerabilities.

Red Hat Security Advisory 2023-2097-03

Auth. (admin+) Stored Cross-Site Scripting (XSS) vulnerability in WPMobile.App plugin <= 11.18 versions.

**Solution**

Update the WordPress WPMobile.App — Android and iOS Mobile Application plugin to the latest available version (at least 11.19).

Found this useful? Thank Rio Darmawan for reporting this vulnerability. Buy a coffee ☕

Rio Darmawan discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress WPMobile.App Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has been fixed in version 11.19.

**2 other known vulnerabilities for this plugin**To plugin page

**Report to Patchstack Alliance bounty platform and earn monthly cash prizes.**

Learn more

CVE-2023-26010: WordPress WPMobile.App — Android and iOS Mobile Application plugin <= 11.18 - Cross Site Scripting (XSS) vulnerability - Patchstack

Categories: News
Critical technology should not require an annual pep talk to function correctly.



(Read more...)




The post World Password Day must die appeared first on Malwarebytes Labs.

The continued existence of World Password Day is a tell that something has gone badly wrong in cybersecurity.

Now in its tenth year, the day is supposed to act as an annual reminder for people to follow good password hygiene: Don’t reuse passwords; use long passwords; no, longer passwords than that; use a collection of random words; no, not those words; use a phrase; use a collection of phrases; don’t forget the weird characters; etc., etc.

This is bad. Critical technology should not require an annual pep talk to function correctly. There is no annual “how to avoid nuclear meltdown” day.

And make no mistake, password authentication is critical technology. It is the bedrock on which security is built. Fail at authentication and it doesn’t matter how “military-grade” your encryption is or if you patch twice a day before flossing, you’re toast.

The existence of World Password Day is a symptom of two problems.

The first is that password authentication is a terrible design. Its success hinges on humans being good at something humans are really bad at: Creating and remembering long strings of random characters.

In an environment where users must now remember about 100 passwords each, it is impossible to use passwords well without assistance. The only chance you have of making it work is to outsource the “creating and remembering” part you’re really bad at to a computer, in the form of some password management software.

Password managers are great—apart from where they aren't, like when you're logging in to Windows—but from what we can tell, most people still don’t use password managers, and those that do are almost certainly the most security-aware among us; in other words, the folks who need its help the least.

And when I write “impossible” I am not being hyperbolic. You cannot remember 100, different, strong passwords. You just can’t. Almost all of us run into serious problems juggling fewer than ten. (If you’re still doubtful, read Why (almost) everything we told you about passwords was wrong, it’s got more details and links to the research.)

The second problem is that for too long we made passwords a problem for users to solve instead a problem for IT or security. Dispersing the responsibility like this created an enormous headache that has consumed untold resources. A system is only as strong as its worst password choice, but we almost never know what the worst choice is or who made it. That creates a situation where improving security rests on our ability to _improve every single user_ in the hope that we’ll reach the worst.

Attempts to level up users often boil down to edicts about how to do passwords better, such as making sure each password includes a mixture of uppercase and lowercase letters, and that passwords are not reused.

It’s like we asked the janitor to configure the firewall rules and then tried to fix our terrible mistake by having a firewall expert constantly lecture the janitor about not messing up the firewall.

Repeated password breaches over decades—which show us real users’ password choices—suggest that these edicts are having little effect. This shouldn’t be a surprise. Reusing passwords and making passwords simpler may be bad for security, but they make perfect sense if your most pressing problem is working out how to juggle an unmanageably large portfolios of passwords.

Our experiment in shifting responsibility and blame to users hasn’t worked. Ransomware gangs rely routinely on phished, stolen, or guessed passwords to break into corporate networks through VPNs or remote desktops, causing untold damage and disruption.

The good news is that while there isn’t much we can do about problem number one, number two was a choice, and it’s a choice we can un-make. There is another way, but it requires a shift in mindset.

Instead of thinking about how to get users to choose stronger passwords, businesses should focus on protecting themselves from users’ poor password choices instead.

The most powerful way to do this is to remove passwords entirely. Thankfully, after decades of false starts, a slew of technologies like Apple’s Touch ID, Windows Hello, and FIDO2 has appeared that now make this a viable option in a number of areas.

Passwords are going to be with us for a long time yet though, so we still need ways to cope with bad ones where passwordless authentication is unavailable.

Where you can’t abandon passwords, the next best option is multi-factor authentication (MFA). In 2019, Microsoft’s Alex Weinert wrote that “Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.”

MFA comes in different flavors and your choice of flavor makes a difference: Hardware keys are better than push notifications from an app, which are better than One-Time Password (OTP) codes from an app, which are better than OTP codes over SMS. But the improvements that come in the steps between the different forms of MFA are incremental. The step between MFA of any kind and no MFA at all is transformational.

More than any other choice or technology, MFA puts the responsibility for password security back into the hands of IT and security specialists where it belongs.

There are other measures, too. When you go to an ATM you don’t have to type in a 14-character password with eight quattuordecillion (that's a number with 45 zeroes at the end of it) possible combinations to get your money—a 4-digit PIN with a paltry 10,000 possible combinations will do.

Why? Because the ATM isn’t going to give an attacker 10,000 chances to guess the correct PIN, it’s going to give them three, and then it’s going to eat the card. The same thing happens on your iPhone. Six wrong guesses and you’re on the naughty step. Ten wrong guesses and your data can self-destruct.

No normal user is going to make hundreds of guesses at their password before phoning support, so take a leaf out of your bank’s playbook and give your users a handful of chances to enter their password correctly.

Like MFA, account lockouts allow users to stay secure even with truly awful password choices. (After all, EVERY 4-digit PIN is a terrible password choice.)

In the interests of defense in depth, businesses may still want to ensure that users are making strong passwords, or at least avoiding weak ones. Here, the thinking has changed in the last decade, and that change is enshrined in the National Institute of Standards and Technology (NIST) Digital Identity Guidelines.

Forcing people to create passwords to a formula, insisting on at least one uppercase letter, at least one special character etc, is out. And so are periodic password resets. Both are far more effective at annoying users than they are at improving security.

Instead, NIST says, it’s more effective to simply stop users choosing known bad passwords, such as passwords that have appeared in breaches or that are based on dictionary words.

If you are going to insist on strong passwords, please make a password manager part of the standard software suite on all your organization’s machines, and make sure employees actually know how to use it. Many users simply don't trust password managers, and unless you've sat with somebody using one for the first time, you may not appreciate how difficult it can be for people to make sense of them.

The measures I’ve suggested in this article are not interchangeable or equally effective: You should start at the top and work down. If you do that, you can improve password security, remove the need for toothless edicts, and perhaps we can finally get rid of these annual pep talks.

Malwarebytes removes all remnants of ransomware and prevents you from getting reinfected. Want to learn more about how we can help protect your business? Get a free trial below.

TRY NOW

World Password Day must die

A out-of-bounds write in Fortinet FortiOS version 7.2.0 through 7.2.3, FortiOS version 7.0.0 through 7.0.10, FortiOS version 6.4.0 through 6.4.11, FortiOS version 6.2.0 through 6.2.13, FortiOS all versions 6.0,  FortiProxy version 7.2.0 through 7.2.1, FortiProxy version 7.0.0 through 7.0.7, FortiProxy all versions 2.0, FortiProxy all versions 1.2, FortiProxy all versions 1.1, FortiProxy all versions 1.0 allows an authenticated attacker to execute unauthorized code or commands via specifically crafted requests.

** PSIRT Advisories**

**FortiOS & FortiProxy - Out-of-bound-write in sslvpnd**

**Summary**

An out-of-bounds write vulnerability \[CWE-787\] in sslvpnd of FortiOS and FortiProxy may allow an authenticated attacker to achieve arbitrary code execution via specifically crafted requests.

**Affected Products**

FortiOS version 7.2.0 through 7.2.3  
FortiOS version 7.0.0 through 7.0.10  
FortiOS version 6.4.0 through 6.4.11  
FortiOS version 6.2.0 through 6.2.13  
FortiOS 6.0 all versions  
FortiProxy version 7.2.0 through 7.2.1  
FortiProxy version 7.0.0 through 7.0.7  
FortiProxy all versions 2.0, 1.2, 1.1, 1.0

**Solutions**

Please upgrade to FortiOS version 7.4.0 or above  
Please upgrade to FortiOS version 7.2.4 or above  
Please upgrade to FortiOS version 7.0.11 or above  
Please upgrade to FortiOS version 6.4.12 or above  
Please upgrade to FortiOS version 6.2.14 or above  
Please upgrade to FortiProxy version 7.2.2 or above  
Please upgrade to FortiProxy version 7.0.8 or above

Workaround:

Disable "Host Check", "Restrict to Specific OS Versions" and "MAC address host checking" in sslvpn portal configuration. For example for "full-access" sslvpn portal:

config vpn ssl web portal  
edit "full-access"  
set os-check disable  
set host-check none  
set mac-addr-check disable  
end

**Acknowledgement**

Internally discovered and reported by Gwendal Guégniaud of Fortinet Product Security team in the frame of an internal audit of the SSL-VPN component.

**Timeline**

2023-04-13: Initial publication

CVE-2023-22640: Fortiguard

The Databricks Platform as of 2023-01-26 suffered from a cluster isolation bypass vulnerability through insecure defaults and shared storage.

Databricks Platform Cluster Isolation Bypass

Categories: News
Google has promised to add end-to-end encryption to Google Authenticator backups after users were warned against turning on the new feature.



(Read more...)




The post Google Authenticator WILL get end-to-end encryption. Eventually. appeared first on Malwarebytes Labs.

Following criticism, Google has decided to bring end-to-end encryption (E2EE) to its Google Authenticator cloud backups. The search giant recently introduced a feature that allows users back up two-factor authentication (2FA) tokens to the cloud, but the lack of encryption caused some commentators to warn people off using it.

Google Authenticator is an authenticator app used to generate access codes, called one-time passwords (OTPs). These OTPs are only valid for a short period and are generated on demand. They serve as an additional form of authentication by proving that you have access to the device generating the OTP. Google Authenticator is one of the most well-known authenticators. Although it's made by Google it's not limited to Google’s own services, but can also be used with Facebook, Twitter, Instagram, and many more.

On April 24, 2023, Google announced an update across both iOS and Android, which added the ability to safely backup the secrets used to generate OTPs to your Google Account. This allows users to create a backup which they can use if their device is lost, stolen, or damaged. Since OTPs in Google Authenticator were previously only stored on a single device, a loss of that device locked you out of any service where you used it to log in.

Shortly after the new feature was rolled out, Mysk’s security researchers advised against turning on the new feature. They analyzed the network traffic that occurs when the app syncs the secrets, and found out that the traffic was not end-to-end encrypted. This would mean that in case of a data breach or if someone obtains access to your Google Account, all of your OTP secrets would be compromised, and they would be able to generate OTPs as if they were you.

The likelihood of someone stealing the secret seeds from Google’s servers is relatively small, but since it is better to be safe than sorry and one problem less is always good to have, users asked Google to add a passphrase to protect the secrets. This would introduce an extra safeguard that makes them accessible only to their owner.

Google’s primary objection to this method was that it heightens the risk of users getting completely locked out of their own data. Meaning that if you lost your device and the passphrase, you would lose all access to your accounts.

Google Group Product Manager Christiaan Brand tweeted that end-to-end encryption (E2EE) will be made available for Google Authenticator down the line, but they are rolling out this feature carefully.

> (2/4) We encrypt data in transit, and at rest, across our products, including in Google Authenticator. E2EE is a powerful feature that provides extra protections, but at the cost of enabling users to get locked out of their own data without recovery.
> 
> — Christiaan Brand (@christiaanbrand) April 26, 2023

According to Google, the option to use the app offline will remain an alternative for those who prefer to manage their backup strategy themselves. But, if you want to try the new Authenticator with Google Account synchronization, simply update the app and follow the prompts.

Malwarebytes removes all remnants of ransomware and prevents you from getting reinfected. Want to learn more about how we can help protect your business? Get a free trial below.

TRY NOW

Google Authenticator WILL get end-to-end encryption. Eventually.

The tech industry’s transition to passkeys gets its first massive boost with the launch of the alternative login scheme for Google’s billions of users.

Google is announcing a major effort to let its account holders log in with the password replacement known as “passkeys.” The feature launches today for the company's billions of accounts, and users will be able to proactively seek it out and turn it on. Google says it plans to promote passkeys in the coming months and start nudging account holders to convert their traditional username and password login to a passkey.

Password-based authentication has been standard across the internet (and computing in general) for decades, but the system has serious security issues, namely that attackers can steal your password or trick you into giving it to them in phishing attacks. The passkey scheme is specifically designed to address phishing attacks by relying on a different model that uses cryptographic keys stored on your devices for account authentication. 

In the year since the industry association known as the FIDO Alliance began publicly promoting the rollout of passkeys, the makers of the world's biggest consumer operating systems—Microsoft, Google, and Apple—have launched the necessary infrastructure to support passkeys. But if you still have never used a passkey in your daily life, you're far from alone.

The next step toward passkey adoption is for services to actually offer passkeys as a login option for user accounts. So far, companies like PayPal, Shopify, CVS Health, Kayak, and Hyatt have taken the plunge. Today's launch of passkeys for Google’s users is noteworthy given the company's resources and sheer scale.

“It's very, very significant,” says Andrew Shikiar, executive director of the FIDO Alliance. “It's an inflection point. A company like Google enabling this with so many people actually seeing passkey sign-ins, they’ll be more likely to use them elsewhere. And it will also accelerate other companies’ deployment plans and help them deploy better, because we will learn from this as a body."

You can log in with passkeys using biometric sensors like fingerprint or face scanners, your smartphone's device lock PIN, or physical authentication dongles like YubiKeys. To transition your Google account, you'll navigate to this link, log in with your username, password, and any additional authentication factors you have set up, and then click “+ Create a passkey” on the device you're using.

“We have an opportunity here to change the way users think about signing in,” says Christiaan Brand, an identity and security product manager at Google and co-chair of the FIDO2 technical working group. “If we can change the way that signing in works for your Google account, we hope that consumers will start to get more accustomed to the technology, and also signal to industry that we’re not just _talking_ about this stuff—it is ready for prime-time adoption.”

Passkeys can sync between your devices through end-to-end encrypted services like Google Password Manager and iCloud Keychain. Or you can set up passkeys on multiple devices by generating a QR code on a device that's logged in to your Google account that will anoint another device where you want to log in. 

All of your Google account passkeys will be listed on the “Passkey Management Page,” where you can review and revoke them. You can even store a passkey for your account on the device of someone you trust as a recovery option. If you issue a passkey to log into your Google account on a shared device, be sure to revoke it once you're done.

“What doesn’t help is when a vendor or developer only rolls out passkey for iOS or only rolls it out for Android. That’s not how passwords work; passwords are ubiquitous," Brand says. “So for us, it was important to cover as wide a range of devices as possible on launch day, no carve-outs.”

Google says that even once you make a passkey for your account (or five), your traditional username and password login isn't going anywhere, and you can still use it if you choose. But the company is betting that once people get used to passkeys, they'll like them better and find them easier to manage than passwords. And once you've set up a passkey on a device, Google will automatically detect it and prompt you to log in that way going forward.

Brand says that in early tests on a few thousand users, sign-in success rates with passkeys were immediately higher than for traditional username and password logins. That doesn't mean there won't be what Brand calls “rough edges” or use cases where there are passkey bugs. But Google says it hopes to discover and iron out as many of these issues as possible, so smaller organizations can feel more confident implementing passkeys.

Google's announcement comes on the eve of World Password Day on Thursday. But passkey proponents are ramping up their efforts to make the occasion obsolete.

“Eventually, it's going to be like World Horse and Buggy Day, I think,” Shikiar says. “For the time being, it’s a good reminder of the challenge we have to get rid of passwords.”

Google Is Rolling Out Passkeys, the Password-Killing Tech, to All Accounts

Apple and Google have teamed up to work on a draft industry-wide specification that's designed to tackle safety risks and alert users when they are being tracked without their knowledge or permission using devices like AirTags.
"The first-of-its-kind specification will allow Bluetooth location-tracking devices to be compatible with unauthorized tracking detection and alerts across Android and

Apple and Google have teamed up to work on a draft industry-wide specification that's designed to tackle safety risks and alert users when they are being tracked without their knowledge or permission using devices like AirTags.

"The first-of-its-kind specification will allow Bluetooth location-tracking devices to be compatible with unauthorized tracking detection and alerts across Android and iOS platforms," the companies said in a joint statement.

While these trackers are primarily designed to keep tabs on personal belongings like keys, wallets, luggage, and other items, such devices have also been abused by bad actors for criminal or nefarious purposes, including instances of stalking, harassment, and theft.

The goal is to standardize the alerting mechanisms and minimize opportunities for misuse across Bluetooth location-tracking devices from different vendors. To that end, Samsung, Tile, Chipolo, eufy Security, and Pebblebee have all come on board.

In doing so, tracking devices manufactured by the companies are required to adhere to a set of instructions and recommendations as well as notify users of any unauthorized tracking on iOS and Android devices.

"Formalizing a set of best practices for manufacturers will allow for scalable compatibility with unwanted tracking detection technologies on various smartphone platforms and improve privacy and security for individuals," according to the spec.

"Unwanted tracking detection can both detect and alert individuals that a location tracker separated from the owner's device is traveling with them, as well as provide means to find and disable the tracker."

A crucial aspect of the proposed specification is the use of a pairing registry, which contains verifiable (but obfuscated) identity information of the owner of an accessory (e.g., phone number or email address) along with the serial number of the accessory.

UPCOMING WEBINAR

Learn to Stop Ransomware with Real-Time Protection

Join our webinar and learn how to stop ransomware attacks in their tracks with real-time MFA and service account protection.

Save My Seat!

Besides retaining the data for a period of minimum 25 days after the device has been unpaired (at which point it's deleted), the pairing registry is made available to law enforcement upon submitting a valid request.

The companies are soliciting feedback from interested parties, following which a production implementation of the specification for unwanted tracking alerts is expected to be released sometime by the end of the year on both mobile ecosystems.

The last time Apple and Google came together, it was to devise a system-level platform that utilizes Bluetooth low energy (BLE) beacons to allow for contact tracing during the COVID-19 pandemic without using location data.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Apple and Google Join Forces to Stop Unauthorized Tracking Alert System

RosarioSIS 10.8.4 is vulnerable to CSV injection via the Periods Module.

**RosarioSIS vulnerable to CSV Injection**

High severity GitHub Reviewed Published May 2, 2023 to the GitHub Advisory Database • Updated May 2, 2023

Tag

#ios