In the WordPress ecosystem, you can have plugins auto-update and I’ve had that enabled for all plugins in the WordPress installations I manage. I’m reconsidering that decision based on a few recent events.

Attackers have bought popular WordPress plugins, giving them access to potentially hundreds of thousands of installations, then released malicious updates.

The issue isn’t isolated to WordPress. The same thing has happened numerous times to web browser extensions, which auto-update whether you like it or not. Attackers have bought the extension from the original owner, or paid existing maintainers to introduce malware. It’s hard to blame the maintainers when they’re devoting their time for free and often deal with complaints from entitled users.

Regardless of the reasons behind the attacks, you’re left with a conundrum: Do you update to the latest version and risk supply chain attacks or do you hold off and hope you’re not exploited by a known vulnerability?

An approach used by package managers such as Bun and pnpm for Javascript’s NPM packages is a cooldown or delay. This provides time for third party malware scanners to discover issues before you install the update. Attackers have thwarted these somewhat by releasing delayed attacks, where the initial release shows no signs of trouble, then a backdoor is triggered several months later.

Although it’s not available for WordPress plugins, you could simulate the same behavior by keeping track of each plugin release and manually updating a week or so after. It’s clearly not ideal.

We rely on so many dependencies maintained by a large number of developers, but what’s a better alternative? It’s our reality and we’ve known about it for years.

I wish I had a better solution, but I’m not aware of a good, clean fix. I’ve reduced the number of WordPress plugins and browser extensions I use to reduce the attack surface. And of those I still use, I selected ones with tens of thousands of installs in the hopes that someone will detect an issue and warn the rest of us before too much damage is done.

The post To Update Or Not To Update appeared first on Amidst a tangled web.

Whatever the cause, the end result is the same – your data is no longer accessible. It’s easy (and lazy) to blame someone else. Why didn’t they have redundant power? Why didn’t they have better security? Why didn’t they allow temporary access to the data after my server was spamming? Why didn’t they spend thousands of dollars to fight the government subpoena to protect my $7/year service?

You are responsible for your data.

It’s usually in the terms of service, but even if it’s not, that’s the reality. No one cares about your data except you. If it’s important, back it up.

The beautiful thing is when you have automated, periodic backups, would-be disasters become mild annoyances. If your server data is no longer available, you can set up a new server, restore from backups and you’re on your way again with no data loss.

If you don’t back up your data, then you are behaving as if it’s not worth preserving. So please stop whining when it’s gone.

The post Backups Make Everything Better appeared first on Amidst a tangled web.

It felt like being caught with my fly down. Why in the world docker does this by default is beyond me. And it’s not as if they’re not aware of it. This GitHub issue clearly lays out the problem. It’s disappointing the issue has existed for so long and the Docker team isn’t willing to fix it. It’s a major violation of the secure by default principle.

If you too are learning about this, here’s the fix.

1. Create /etc/docker/daemon.json if it doesn’t already exist
2. Add the following content to the file

{
  "iptables": false
}

3. Restart docker sudo service docker restart

Who knows if there are other docker vulnerabilities I’m not aware of, but at least in this case, my servers have zipped up.

Update: I discovered that disabling iptables has the side effect of blocking outgoing network requests from your containers due to ufw’s default behavior. If this creates a problem, you can leave iptables enabled, but bind your ports to localhost. For example, instead of using 3001:3001 for your ports, use localhost:3001:3001. Alternatively, you can make ufw allow outbound requests.

The post Local Docker Port Exposed appeared first on Amidst a tangled web.

The fix was not at all obvious, hence this blog post. I had to disable the “SameSite by default cookies” flag.

1) Open this URL in Chrome: chrome://flags/#same-site-by-default-cookies

2) Select “Disabled” in the dropdown.

3) Restart Chrome (the entire browser, not just the tab or window)

I was able to log in to the aforementioned sites in Firefox, so my guess is the Chrome team is using their monopoly to push a more restrictive security feature that ends up breaking sites that haven’t gotten the memo. Hopefully this is a temporary fix and the flag can be enabled again once sites realize their users can’t log in with Chrome.

The post Chrome 85 Causing Login Failures appeared first on Amidst a tangled web.

My solution has continued to work surprisingly well for the past few years. It’s a bookmarklet that removes all sticky elements (ones that stay visible when you scroll).

The bookmarklet in action on a random Medium.com page

To use it, drag the link below to your browser’s bookmarks bar then click on it whenever a web page looks a little cluttered.

-sticky

The post Cleaning Up The Web appeared first on Amidst a tangled web.

Download Weekly Planner

Download Daily Planner

Happy planning!

The post Free Printable Weekly and Daily Planners appeared first on Amidst a tangled web.

I found the wallpaper at New Evolution Designs. Here’s the original. And the fresh falling snow is thanks to DesktopSnowOK.

The post Christmas Desktop 2018 appeared first on Amidst a tangled web.

Brian Krebs’ blog post has the details. Bruce Schneier (a renowned security expert) echoed Brian’s recommendation.

“never give out any information about yourself in response to an unsolicited phone call.” Always call them back, and not using the number offered to you by the caller. Always.

The post Beware of Voice Phishing Scams appeared first on Amidst a tangled web.

And if you use the same password everywhere, like many folks do, all of your passwords would be exposed if even the weakest link was broken. (Note: The weakest links are broken with morbid regularity)

I had some concerns when I first heard about using a password manager, but I have been using KeePass for years and rest easy at night. Let’s dig a little deeper so you can too.

Alternatives

• Same password for everything – one site’s password is exposed and the gig is up
• Try to memorize dozens of long, hard to remember passwords – nearly impossible
• Writing passwords down – not bad, but tedious and less accessible
• Saving passwords in your browser – not as secure and doesn’t work for non-web passwords

None of these alternatives work as well as a password manager, or scale to hundreds of passwords. It’s not to say you should never use them, just that for the balance of convenience and security, a password manager wins out.

Attack vectors

• A web site you use is hacked, revealing your password
• Keylogger
• Physical access to your machine

The first attack vector is depressingly common. LinkedIn, eHarmony, Gawker media, Sony Playstation Network and plenty more have all had their passwords exposed. When this happens I can change my password to another random password quickly and easily. The longest part of the process is finding the option in the account settings.

A keylogger is pretty much game over if you’re typing your passwords in. But password managers make an effort to be resistant to key logging. And if someone has physical access to your machine, a password manager has your passwords encrypted. If you use a relatively short inactivity timeout, your passwords would still be safe from prying eyes.

While no solution is perfect, a password manager gives you strong, random passwords for every login. I use KeePass, but there are plenty of options.

• KeePass – Standalone application, free and open source
• LastPass – Web site with browser extensions, free and paid plans
• BitWarden – Apps save encrypted passwords to the cloud, free and open source (can be self-hosted)
• 1Password – Paid plans only

The post How Secure Are Password Managers? appeared first on Amidst a tangled web.