Or how to avoid getting locked-out of another Google Account
This guide will describe how to setup a persistent browser (for Evil Corp) that’s isolated in a sandbox (with firejail) and forced to use a SOCKS5 proxy to retain a static IP address (using proxychains)
Have you ever been locked out of your own account, and then got an email for your service provider annoyingly letting you know that they’ve “blocked a login attempt — for your protection?“
There’s countless reports of frustrated users who have permanently lost access to their own gmail accounts because of Google’s faulty “fraud protection” systems that locked the account owner out of their own account, due to false-positives.
Problem
Especially the past 10 years, large corporations have been using machine learning anomaly detection systems on their login pages. Unfortunately, sometimes this is (ab)used to have priority over credential authentication challenges.
Even if you enter your username, password, and 2FA credentials correctly on the very first login attempt, you may get locked out of your own account because you “look different”
This post will help to provide historical context and demystify what’s under the hood of Heads, PureBoot, and other tools to provide Trusted Boot.
I will not be presenting anything new in this article; I merely hope to provide a historical timeline and a curated list of resources.
Intro
The Librem Key cryptographically verifies the system’s integrity and flashes red if it’s detected tampering
I’ve always felt bad about two things:
Because I run QubesOS, I usually disable “Secure Boot” on my laptop I travel a lot, and I don’t have a good way to verify the integrity of my laptop (eg from an Evil Maid that gains physical access to my computer)
To address this, I have turned to Heads and PureBoot — a collection of technologies including an open-source firmware/BIOS, TPM, and a USB security key that can cryptographically verify the integrity of the lowest firmware (and up the chain to the OS).
While Purism has written many articles about PureBoot and has some (minimal) documentation, I found they did a lot of hand waving without explaining how the technology works (what the hell is a “BIOS measurement”?). So I spent a great deal of . . . → Read More: Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot)
This post will outline recommended steps to harden phpList after install to make it reasonably secure.
phpList is the most popular open-source software for managing mailing lists. Like wordpress, they have a phplist.com for paid hosting services and phplist.org for free self-hosting.
Earlier this week, it was announced that phpList had a critical security vulnerability permitting an attacker to bypass authentication and login as an administrator using an incorrect & carefully-crafted password in some cases. This bug is a result of the fact that [a] PHP is a loosely typed language and [b] the phpList team was using the ‘==‘ operator to test for equality of the user’s hashed password against the DB. This security pitfall has been known in PHP since at least 2010 (a decade ago!), but I’m sure the same mistake will be made again..
Indeed, security is porous. There’s no such thing as 100% vulnerability-free code, and phpList is no exception. But if we’re careful in adding layers of security to our infrastructure, then we might be able to protect ourselves from certain 0-days.
That said, here’s my recommended steps to making your phpList install reasonably secure.
