Recently I've been noticing someone using the username SerpentSecurity32. I'm not sure if they're trying to impersonate me, but just in case, I've released the following notice:

SerpentSecurity32 is *not* my account. A full summary of my accounts can always be found at git.envs.net/NobodySpecial/who

My minisign public key is: RWSAnvfq8XXGcw5iUd2+q7OWwlITbIKkp5lUPKR3haFhdIWDdXFf1Rla

My account summary (linked above) has a detatched signature signed by the above public key

I've been away from blogging for a while, but I've decided to start again. Serpentsec.1337.cx is being moved to nobodyspecial.neocities.org

Check out the new site for new articles

@isobel
My scripts do not replace GrSecurity. They are additional hardening that is applied on top of an already-hardened kernel

@isobel
I chose AppArmor because these scripts are meant to bring improved security to the average Linux desktop. The "AppArmor is easier to use" point is a trade-off to allow not-so-expert users to have at least a hope of customizing their MAC. Although my scripts mostly use Bubblewrap to provide isolation, not the full-system MAC.

@isobel
Additionally, my scripts increase the difficulty of heap exploitation to initially gain access to a system by using Daniel Micay's hardened malloc. For the even more paranoid, my scripts allow users to enforce isolation via QEMU-KVM, which is itself isolated within a Bubblewrap sandbox. I also include scripts for sandboxing basic functionality within the command line, such as isolating GPG, mplayer, mpv, elinks, and more, within a Bubblewrap sandbox

@isobel
Also, I would like to shout out to Whonix developer Madaidan. My script uses many of the hardening measures discussed in his Linux hardening guide, as well as measures from Arch Wiki's security guide

madaidans-insecurities.github.

wiki.archlinux.org/index.php/s

@isobel
My scripts setup AppArmor with a set of default policies if you're running an Artix system. However, this doesn't protect against certain vulnerabilities. For example, even an app isolated via SELinux cannot be protected against vulnerabilities in the kernel itself, while my script's boot parameter and sysctl hardening can prevent such vulnerabilities from allowing malicious code to escape isolation by hardening the kernel itself

@isobel
While I could install OpenBSD to avoid Linux vulnerabilities, that doesn't protect me against OpenBSD vulnerabilities

I'm developing a Linux hardening script. The goal is to develop the most secure system possible, while not sacrificing usability. codeberg.org/SalamanderSecurit

I developed a script to generate anonymous email addresses over Tor (or any proxy configuration you want): anonfiles.com/neLfc753qf/tmpma

It relies on proxychains for proxying traffic anonymously.

(This is a fork. The original can be found at github.com/sdushantha/tmpmail)

@ratonfire Email is, in general, not a good protocol for security/privacy. However, if you want something that use more modern encryption than PGP, I recommend using Age for encryption, and Minisign for signing

github.com/FiloSottile/age
github.com/jedisct1/minisign

As a reminder to anyone currently using PGP/GPG, you shouldn't. PGP is an outdated, overly complex protocol that doesn't meet the standards of a modern secure system.

latacora.micro.blog/2019/07/16

Someone in a Matrix room I'm a part of mentioned this:

C: Do you want more buffer overflow vulnerabilities? No? Well... take it anyway!
nitter.net/FiloSottile/status/

Of course `gcrypt` would have an exploitable heap overflow. This is why I recommend avoiding PGP

A while back I performed a mini-audit on the Threema messaging app. You can read about Threema on my blog: serpentsec.1337.cx/threema

@KitKat MLS uses a design that allows encrypting message senders, and as such, is more resistant to metadata leaks. A federated system using MLS would only leak the homeserver of the sending party. The major issue then becomes allowing homeservers to interact without revealing the sending homeserver. Perhaps this could be implemented by requiring inter-homeserver communication to use Tor.

@KitKat In Matrix, the MXID could be hidden without breaking authentication. However, device/session IDs must still be made public in order to allow proper authentication. Since device IDs are linked to a specific user, hiding MXIDs without hiding device/session IDs would be of purely aesthetic benefit.

@KitKat The way handles message verification requires it to know which user and device sent a message before decryption. Perhaps a major update to OLM/MegOLM could change this, but the implementation complexities aren't insignificant. Matrix is good for what it is, but it's not a private messaging service.

With today being data privacy day, I decided to publish an article explaining why privacy is important, and discussing why we shouldn't simply believe companies who try to claim "we care about your privacy". I imagine many people here already understand this, but I figured I'd release the article anyway.

serpentsec.1337.cx/privacy-day

In light of a recent report from Google's TAG, I'm like to remind everyone of the importance of verifying trust. According to TAG, North Korean attackers have been posing as security researchers to steal research and obtain vulnerability information they can exploit.

TAG also discovered the same attackers have been exploiting a zero-day in Chrome on Windows.

serpentsec.1337.cx/trust-and-v

Show older
IOC.exchange

INDICATORS OF COMPROMISE (IOC)
InfoSec Community within the Fediverse. Newbies, experts, gurus - Everyone is Welcome! Instance is supposed to be fast and secure.

We have a Getting Started Guide here: https://ioc.wiki/mastodon

HAVE FUN and STAY SAFE!