Firstly, apologies to everyone for the extended downtime. Unfortunately, it was for a pretty bad reason. We were hacked.

The bad news is that it was a comprehensive attack, and the attackers had privileged access to our database system, across all of our services (except for writefreely, which doesn't use postgres). From what we can tell, the attacker did not do anything with that access, so we don't believe any user data was accessed, but we can't be certain of that. For lemmy, the impact of this should be minimal. If you registered with a real email address, they may have that. User passwords are encrypted in the database, so if you were using a secure, non trivial password, it should be safe, but you should still change it. You should also reset your 2 factor authentication if you had it enabled, as the seeds for these are not encrypted.

Our understanding is that the attacker used a peertube exploit, then a postgres exploit and then a kernel exploit to systematically gain access to different layers of our database server. A side effect of the hack was that it filled up our database servers hard drive, and caused it to fail over to our backup, which we believe mitigated some of the potential fall out.

We have had to reset activitypub keypairs for every account and community on lemmy, so there may be some federation hicoughs for a day or so, until remote servers have dropped any cached copies of our users public keys. This is uncharted territory though, so hopefully it's as smooth as we think it will be, but we can't be sure!

As stated earlier, our writefreely instance is still up and running as it wasn't impacted by this attack. Vernissage (our pixelfed replacement) has been brought back online, as has our matrix server.

We will be bringing up Sharkey, and then Piefed hopefully later today, but we have to rotate keypairs on those services too, which is also uncharted territory, so the timelines are hopes, not guarantees. At this point in time, we don't plan on bringing pixelfed back online, as it was slated for shutdown in August in any case. If people still need access to pixelfed to export data, we can spin it up briefly if needed, so please reach out if this is you. We also won't be bringing peertube back up at this point. It was not heavily utilised, and it was the source of the attack, so Kaity is a bit gun shy about spinning it back up on shared database infrastructure. If there is a strong desire to bring peertube back, we can consider doing that on isolated hardware, but at the current utilisation level, it doesn't seem worth the cost/effort to run it isolated.

in any case, you can read a fuller explanation of the attack by Kaity here https://pen.blahaj.zone/supakaity/weve-been-hacked

all 60 comments

sorted by: hot top controversial new old
[–] 160 points 4 months ago* (last edited 4 months ago) (5 children)

The feeling when a small hobby non-profit project gets hacked and the owners quickly respond to the users and say "hey, we got hacked but don't worry, your passwords are safe because they were encrypted!!"

But a damn multi-billion company gets hacked, takes months to tell the users and their answer is: "so... a few months ago, we got hacked, but it wasn't that bad so we didn't think about telling you until someone found our database for sale in a forum. Also, change your passwords, email, physical adress, bank account, credit cards and if you sent it to us, your SSN, because we didn't think it was important so it was all stored in a plain wordpad file without any encryption".

I know this must have been awful for you guys, but damn if it feels good to know that even if the fucker got access to your database, they couldn't do shit because you were competent and took measures to protect your users in a way a multi-billion company doesn't.

  • source
  • hideshow 5 child comments
  • [+] -18 points 4 months ago (4 children)

    I get your sentiment, but the difference is the mega-company has to worry about what they say for when they inevitably get sued.

    No one is going to sue blahaj, and their currency is trust and communication, so it helps to be open.

  • source
  • parent
  • hideshow 4 child comments
  • No, the difference is that blahaj encrypts user passwords while a multi-billion dollar company stores them in a fucking plaintext file (alongside the credit card numbers and other sensitive data).

    Also, under GDPR, a company must inform of a databreach ASAP, and they only do when they get caught.

  • source
  • parent
  • [–] -2 points 4 months ago (2 children)

    I’ve been on Lemmy for a while and the sheer naive idealism on here boggles me sometimes. You guys think “megacorp is evil and stoopid”, when realistically the person who discovered the breach freaks out because he may lose his job and is the sole breadwinner of the family, then takes it to his manager, who isn’t in a much better position. It bounces through a few low level admins and teams trying to figure out the extent, since there are hundreds of applications and systems, all while the clock is ticking by what you want to see. Only once they have things does it get bubbled up because they want to make sure they can answer to the VP in hopefully a way they won’t be scapegoated and lose their jobs. Finally it may get to the people who do have control of information but by now it’s been a while and past your idealistic timeframe. All because a common working man doesn’t want to become homeless.

    But sure, blame the corporation, because it’s a single monolithic entity that you can focus your ire on instead of showing some sympathy for the working people, who are also here on Lemmy, fearing for their jobs.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 71 points 4 months ago

    Thank you 🫂 I've been through some disastrous code deployments, but I know those experiences could never truly compare to something like this- stress, fear, accountability, and just feeling violated. You all must have put in sooo much effort and had to make some difficult decisions. Thank you for all of your time and knowledge to creating and supporting this space for us 🩷

  • source
  • [–] 54 points 4 months ago

    See, this is why I respect the hell out of you Ada. Well, one of the reasons, because there are plenty more. But this is a perfect example of the kind of person you are, as well as the kind of admin. Transparency, rapid response, and you even opened up with an apology for someone else having screwed things up.

    That goes for the entire blahaj team, but you are very much the face of it, and I just wanted to say something that I very often think, that we're all damn lucky you're here.

  • source
  • [–] 37 points 4 months ago

    Thank you so much kaity and ada for everything you do and your moral integrity. I don't envy any of this.

  • source
  • [–] 37 points 4 months ago

    Thank you all for everything you're doing to keep users safe and the servers functional ~

  • source
  • [–] 36 points 4 months ago

    Sounds like a real mess. It must be a lot of work running infrastructure like this, so you should know we appreciate all the work you guys do.

  • source
  • [–] 33 points 4 months ago*

    Getting hacked is never an if, it's a when.

    So sorry that you've had to shoulder all this. I really do hope you took breaks and didn't overwhelm yourselves. I understand remediating the hack itself quickly was important, but I hope you took a break and got good rest before you brought everything back online. Even in such a serious situation, I want to know my admins are still caring for themselves, too. It's hard to do this stuff on such a small scale when we have literal nation state actors doing hacks, it's a literal 24/7 threat.

    Anyway, please be kind to yourselves. Thanks so much for all the hard work and bringing a beautiful community together.

  • source
  • [–] 30 points 4 months ago

    Fingers crossed this gets sorted out, blahaj.zone is such a blessing.

  • source
  • [–] 25 points 4 months ago* (last edited 3 months ago) (2 children)

    Thank you so much, Ada and Will. Appreciate the transparency! :3

    To all curious, for the future: if you cannot go to your account on the Blåhaj instance or open up any stuff from there, check the desktop website of the instance, just go to lemmy.blahaj.zone (or its piefed equivalent).

    Chances are, that there may be something on it. If you have an alt, I'd recommend one on an instance that's mutually federated with the Blåhaj one. See TherapyGary's post below - their instance has the same bans as dbzer0 and blahaj, so that should help!

    For changing passwords, your app may not support it - use the desktop environment.

    Consider donating to the Blåhaj instance - kofi link!

    (Might be good to put that in the sidebar too...)

  • source
  • hideshow 2 child comments
  • [–] 3 points 4 months ago* (last edited 4 months ago) (1 child)

    This feels like an inappropriate time & place to plug my instance, but I have a bot set up to mirror instance bans from blahaj (and dbzer0), so my instance can be a safe space as a back up for folks who need one. Important differences in that regard though are that I do have downvotes enabled, federate with hexbear, and could only copy bans going back a little over a year (which is over 3000 accounts banned btw! They do so much work to keep a safe space it's jaw dropping- I donate monthly as a thanks for the ban list lol)

  • source
  • parent
  • hideshow 1 child comment
  • [–] 24 points 4 months ago

    thank you for all your hard work Kaity, Ada, and the rest of team, and for the transparency. even tho this was a horrible thing, the honesty and work makes me hopeful in a dark world. lots of love <333

  • source
  • [–] 22 points 4 months ago

    Thank you both for working so hard to deal with this! I’ve changed my password, hopefully nothing more will come of it. I hope other instances are also on the lookout for this hack.

  • source
  • [–] 22 points 4 months ago*

    Thank you for your hard work and transparency, Blahaj Zone team!

  • source
  • [–] 21 points 4 months ago

    Thank you for bringing my favorite source of memes back online. You two are much appreciated!

  • source
  • [–] 19 points 4 months ago

    I've waded through my share of critical incidents and systems recoveries. The work can be deeply stressful and infuriating as you gradually uncover inevitable missteps, find the footprints of malicious actors and dream up countless hindsight mitigations that would have prevented all this.

    Bless you, kind friends. I know how hard this is. Your work and diligence has value, and this entire community appreciates it.

  • source
  • [–] 18 points 4 months ago

    o7 Admiring your tenacity, welcome back.

    People wishing to manage their lemmy account should use the Lemmy UI (web) frontend.

  • source
  • [–] 16 points 4 months ago (7 children)

    Were your services containerized? Just curious. Systems architect here. Find me on LinkedIn. Curious if you need or want a hand. - Opal Wild

  • source
  • hideshow 7 child comments
  • [–] [S] 13 points 4 months ago (6 children)

    Mostly no. Our smaller ones were.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 4 points 4 months ago (5 children)

    Your passion project is community. You're doing well and good. Thank you for protecting me and protecting us. If you need, I'm free as in beer and sex. 💖🫶

  • source
  • parent
  • hideshow 5 child comments
  • [–] 3 points 4 months ago (4 children)

    Slightly off topic but what is the exact meaning of the 'free as in sex' phrase? I know 'free as in speech' (which is ironic because speech is not that free nowadays) and 'free as in beer' but it is first time coming across the sex version.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 4 points 4 months ago (2 children)
  • [–] 3 points 4 months ago (1 child)

    If that were true, the sex would most definitely not be free.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 4 months ago

    No, it's true. I'm being appreciative. Also, maybe don't try to call out transsexual sex workers offering alms to the gods of Blahaj Zone. 😕 I'm also a systems architect. You coulda just read my posts to verify and be kinder to me. 😔

  • source
  • parent
  • [–] 11 points 4 months ago

    Ouch, that’s rough. Good work and good luck!

  • source
  • [–] 11 points 4 months ago

    Thx for resurrecting us back.

  • source
  • [–] 11 points 4 months ago

    Oof! I'm really sorry that happened, to our blaj kindred. Hopefully everyone and everything successfully mitigates damage and restored to the fullest extent.

  • source
  • [–] 8 points 4 months ago (4 children)

    This is a reminder from someone in IT with an interest in security, use discrete, unique passwords for accounts you are concerned about. Finance, health, banking, etc. use different passwords. For places you don't care about use a throw away only for those sites that don't have PII or HIPPA.

  • source
  • hideshow 4 child comments
  • [–] 3 points 4 months ago (2 children)

    Use a password manager. Keepass if you're paranoid, Bitwarden if you're slightly less paranoid.

    Idk how the built-in OS and browser ones are these days. Browser seems a little loose.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 8 points 4 months ago* (1 child)

    Thanks for sharing all the technical details!

    Did you have ssh keys configured between your machines, or is all of blahaj on a single server? (Wondering how they got from postgres -> root -> other servers)

  • source
  • hideshow 1 child comment
  • [–] [S] 16 points 4 months ago

    We run our instances across multiple servers, but the postgres databases are all hosted together on a single server, though technically not a single server, as, at the time of the attack, we also hosted a backup database server, which was spec'd to backup our instances, but not serve them. Their access was limited to the main postgres server, but that server holds the databases for all of our instances. It looks like the script they used in the postgres exploit to give them local access interfered with the cleanup/backup process, so WOL files would get written, but not deleted, which filled up the disk on the main machine, and ultimately, caused it to fail over to the backup machine.

    In theory, they could have used the same script/exploit on the backup machine, but because it wasn't spec'd to serve all of our instances at once, everything fell over at this point. That is what alerted us to the issue, and also limited the attackers available time in the system.

  • source
  • parent
  • [–] 7 points 4 months ago (2 children)

    As ever, both of your dedication to transparency and communication is both excellent and very gratefully received! I did see you said in the post above Ada that keypair rotation and all that that entails would make Piefed a tricker recovery but I was wondering if you had any updates for Piefed recovery? If you don't, you don't :) I fully appreciate how time consuming dealing with all this is, I just thought I'd ask.

  • source
  • hideshow 2 child comments
  • [–] [S] 5 points 4 months ago (1 child)

    We just ran out of time to get Piefed back yesterday (Australian time). We're also navigating around moving house and the Kaity's day job. It will be up as soon as we can today (It's currently 7am here)

  • source
  • parent
  • hideshow 1 child comment
  • [–] 7 points 4 months ago (5 children)

    Are IP addresses stored? And if so are they affected?

  • source
  • hideshow 5 child comments
  • [–] [S] 10 points 4 months ago (4 children)

    It looks like IP addresses are stored in the DB in lemmy. It's possible that the attacker had access to those IPs, but we don't believe they accessed them.

    This is the sort of thing we would turn off if we could :\

  • source
  • parent
  • hideshow 4 child comments
  • [–] 4 points 4 months ago (2 children)

    I believe IP addresses are anonymized on hexbear although I dont know how it's done.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 4 months ago

    Had a feeling that this was the fact. Glad to be back

  • source
  • [–] 5 points 4 months ago

    So happy you're back! I was so desperate as to visit Reddit a few times. It was horrible. You're amazing! ❤️❤️❤️

  • source
  • [–] 5 points 4 months ago

    It’s good to be back

  • source
  • [–] 5 points 4 months ago (2 children)

    Status of Blahaj registration links?

  • source
  • hideshow 2 child comments
  • [–] 5 points 4 months ago

    Oof. People can be shitty. It sounds like not collecting data spared a lot of potential damage, though, so good on you for that. I know was the point, and this just proves why that was such a good decision.

    Oh, minor thing: there's some piece of punctuation in the name pgcrypto that your blog software is interpreting as markdown to start and stop italics. Luckily you mention it twice in fairly quick succession, so the passage in italics is relatively short, but you might want to escape out that character. I realize this is an unbelievably low priority right now, and possibly forever. It's just something I would want pointed out to me if it were my post.

  • source
  • Guess we now know where the database problems where coming from.

  • source
  • im glad that they didnt do too much damage. the person/people who did this have to truly have nothing better to do with their time. i cant imagine how sad it must be to be them.

  • source
  • [–] 1 point 4 months ago

    I was wondering what was going on. First noticed it with matrix, then Lemmy.

  • source
  • [–] 1 point 4 months ago

    Yikeeeesss. Wishing you all the best, and many thanks for the work you do for the community!

  • source
  • 34 comments in c/fediverse@lemmy.world view that post
    [–] 46 points 4 months ago (3 children)

    Then they transfered a file to /tmp/exp which was linux kernel CVE-2026-43500, nicknamed ‘Dirty Frag’, an RxRPC local privilege escalation. I had not patched these internal servers that nobody should have access to against this.

    Lessons Learned #1:
    Install your patches.
    "But I have a firewall!"
    That is not a sufficient control.
    Install.
    Your.
    Fucking.
    Patches!

  • source
  • hideshow 3 child comments
  • [–] 17 points 4 months ago (1 child)

    "Just patch" is advice for a windows administrator, where updates break everything so you have to sit and baby them and apply them manually.

    On Linux, there are ways to enable automatic security updates, including automatic reboots, so you can safely receive the mitigations your distro provides. That way, you don't have to worry about forgetting to patch (until the distro release becomes unmaintained, at least).

    Now, dirty frag was a zero day, meaning that it was released and probably in the wild before a mitigation was pushed out to handle it. So you did need to apply an actual configuration patch... unless you had some form of kernel based isolation, which I mention as #2 of my other comment in this thread: https://programming.dev/post/52129409/24414213

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 4 months ago

    Sadly, a reluctance to install patches isn't unique to Windows administration. I worked at a site with a well functioning Satellite infrastructure and support contracts with Red Hat. And we (InfoSec) were still chasing down admins to get their shit patched. Thankfully, we had NAC and authorization to disconnect systems that feel out of compliance. Most departments got with the program pretty quick when they ignored the "please patch all critical vulnerabilities in three days' email and ended up with a "you are out of compliance and have been disconnected" email.

    And Docker had made the whole Linux situation even worse. So many devs love to spin up containers, basically disable any sort of firewall, don't bother with IP filtering. Oh and let's just use passwords for ssh. Also, who needs logs? It's a container, right. So, let's disable all logging and not forward those anywhere. Then they promptly forget about the container until we run a vuln scan and find it's got half a dozen RCE vulns and have to run them down and ask why the fuck it's still running.

    Linux is a much better base to build on. But bad security hygiene is still rife and still really bad for security.

  • source
  • parent
  • [–] 34 points 4 months ago

    Thanks for sharing the details 👍

  • source
  • [–] 32 points 4 months ago

    Fookin' hell. Nightmare scenario.

  • source
  • [–] 23 points 4 months ago

    Really appreciate the transparency. Time to change my blahaj password!

  • source
  • [–] 60 points 4 months ago (12 children)

    well, there goes 75% of shitposts on lemmy.

    Also a vital support network for LGBT+ people, I guess?

  • source
  • hideshow 12 child comments
  • [–] 20 points 4 months ago (10 children)

    Also a vital support network for LGBT+ people, I guess?

    Mhm and the instance where the only women's community is hosted :(

  • source
  • parent
  • hideshow 10 child comments
  • [–] [S] 18 points 4 months ago* (7 children)

    i know this isn't my place as a cis white dude, but can anarchist.nexus be a resource for a women's space? i've been looking for gaps in the threadiverse we could nurture and foster. my #1 concern lately with the makeup of the hegemony of the threadiverse lately has been:

    • eurocentricism
    • authoritarianism by default
    • black and white thinking (see above)
    • unchecked and unchallenged mysoginy

    my commitment to you as a cis white dude admin would be to stay the fuck out of the way of moderators looking to host a women's issues community here, within reason. obviously it wouldn't be okay to break instance rules against bigotry and such, but i can offer my commitment to shutting my mouth and knowing my role

    edit: also, i bet @poVoq@slrpnk.net and @ProdigalFrog@slrpnk.net from my second original home instance would be happy to have a women's issues community hosted on slrpnk.net, i'm still figuring out what my new relationship and responsibility to the threadiverse is now, but i think just like how there's more than one world news community, there could be more than one women's issues community so that people have a preferred and fallback space on days like today. the one thing i don't want to diminish in this comment is the incredible work people like @ada@lemmy.blahaj.zone have done in creating a welcoming space on the threadiverse for marginalized people. i just don't want that to be work that is only done alone. we should be collaborative towards a better, freer, world

  • source
  • parent
  • hideshow 7 child comments
  • [–] 18 points 4 months ago (1 child)

    For what it's worth, I absolutely want to see duplicate communities across multiple instances. Even if it's a backup community, folks shouldn't be left without a space if an instance goes offline, or if an admin goes rogue. I want to see more communities for vulnerable folk across more instances.

    I wish there were more queer first instances too, and hopefully, this incident pushes someone in to spinning one up!

  • source
  • parent
  • hideshow 1 child comment
  • [–] [S] 1 point 4 months ago

    i know one person who's interesting in hosting some queer focused fediverse infrastructure, however they wants no part of the threadiverse since they considers reddit and reddit-alikes to be intrinsically prone to toxicity

  • source
  • parent
  • [–] 14 points 4 months ago (1 child)

    There used to be a women's space on slrpnk.net (although a bit unfortunately named after a controversial Reddit community), but we could never really find women willing to moderate it longer term and the amount of dudes showing up with trollish comments became a bit too much for us admins to handle.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 10 points 4 months ago (2 children)

    Maybe! LadyButterfly is the mod of the womensstuff community and she does a great job, maybe we can get this info to her.

    I really appreciate your acknowledgement of some of the issues with the diversity in the threadiverse. And appreciate your support <3

  • source
  • parent
  • hideshow 2 child comments
  • [–] [S] 12 points 4 months ago (1 child)

    @LadyButterfly@piefed.blahaj.zone , when your instance is online again let's have a discussion about what resources i can make available to you that will center your community's needs without someone like me colonizing the discussion.

    (unless i have the wrong ladybutterfly, then my apologies)

  • source
  • parent
  • hideshow 1 child comment
  • [–] 20 points 4 months ago

    I've been wondering why it's down, that's my home instance. That's unfortunate :/

  • source
  • [–] 15 points 4 months ago* (last edited 4 months ago) (6 children)

    Excellent writeup, and I appreciate the transparency. I have some suggestions on how to mitigate something like this from happening in the future.

    1. Use a separate DBMS (that is, a separate postgres/mariasql/etc container) for each service. Give each one service unique passwords, which you can define in the docker compose.

    This is simpler than trying to control postgres permissions granularity. Even if one application that connects to a database gets owned, it doesn't have access to other postgres databases, preventing data leaks/exfiltration.

    1. Use a virtual machine or application container based runtime for your containers.

    Kata containers is a container runtime, that is virtual machine.

    There is also Gvisor and Syd Box, which are application kernels. Application kernels are reimplimentations of the parts of the Linux kernel needed to run apps, and in this case both Gvisor (Go) and Syd Box (Rust) are in memory safe langauges.

    Kata containers are faster, but you will need nested virtualization in order to use them. Application kernels are slower, but you can install them anywhere, including hosts where virtualization is disabled (like a VPS that doesn't let you enable nested virtualization.

    Both take a tiny bit more resources intensive due to no longer being able to share the host kernel, but for most part, it is worth it. They don't bring an entire kernel along, just what is needed to run apps.

    Both offer similar levels of isolation, and preventing applications running inside them from touching the host kernel directly. They effectively manage to prevent issues like copy fail, dirty frag, and so on, from owning your host.

    They are fairly easy to install, docker has some docs here: https://docs.docker.com/engine/daemon/alternative-runtimes/ . But if you are using podman or kubernetes, you can also install them there.

    1. Enable automatic security updates (and reboots) on stable distros.

    A large part of the draw of stable Linux like Debian or Red Hat, is that they only do security updates. They don't do feature updates, or even bug fixes (except for critical ones). In doing so, there is essentially a guarantee of reliability, where it is impossible for updates to break anything.

    This makes it possible to enable automatic security updates, and you can even configure it to automatically reboot in order to load a new kernel that includes mitigations against issues like dirty frag. Make sure your docker containers are configured to automatically restart and everything will be smooth.

    "Just patch" is a good but it is never enough, and I am frustrated hearing it so frequently. The way I view it is, any time I have to patch, what I really need to do is to improve my security architecture so I never have to "patch" this specific issues again. Patches are the exact kind of security toil that I complain about in this comment.

  • source
  • hideshow 6 child comments
  • [–] 8 points 4 months ago (5 children)

    Use a separate DBMS (that is, a separate postgres/mariasql/etc container) for each service. Give each one service unique passwords, which you can define in the docker compose.

    unique passwords is good practice, but separate db server for each of the services is extreme. it brings much more resource consumption. the solution here is being subscribed to security releases and updating soon. those application kernels also sound like a good idea. and as I understand, postgres permissions were not at fault, the permission system had a bug.

    Even if one application that connects to a database gets owned, it doesn't have access to other postgres databases, preventing data leaks/exfiltration.

    except that because of the bug, anyone with query permission could have become postgres superuser.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 4 points 4 months ago* (4 children)

    except that because of the bug, anyone with query permission could have become postgres superuser.

    If a user can't log in to a DBMS, they don't have query permission.

    separate db server for each of the services is extreme. it brings much more resource consumption.

    Yes. It consumes more resources. But it's not that much more, and you can make it fit easily. Many users using docker compose unwittingly do this since docker composes often bring their own database containers. When done consciously, you make a trade off for peace of mind.

    the solution here is being subscribed to security releases and updating soon.

    I addressed takes like these in the last part of my previous comment. The linked comment also elaborates on my opinions about manual updates, manually watching security releases, and other forms of security toil.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 4 months ago (3 children)

    If a user can't log in to a DBMS, they don't have query permission.

    weren't they having access through peertube? you can't revoke access to something that needs it.

    sure, they could run dedicated postgreses for each service, but I think this kind of bug is so rare that it is not worth wasting lots of RAM on that, and even then, it would rather just deter people from hosting services they want.
    also at that point, the question arises why not just run everything in qubes OS, each service in its own VM and its own VLAN. and the response is that it is unfeasible, and it was unfeasible even before the RAM shortage, unless you have enterprise hardware with 100+ GB RAM, consuming way too much power compared to a server made from desktop PC hardware, even when there is no meaningful CPU load.

    But it's not that much more, and you can make it fit easily.

    I run 3 separate database servers on the same OS because I made a bad decision at one point, and I regret it. I just don't have time to merge them.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 4 months ago* (2 children)

    weren’t they having access through peertube? you can’t revoke access to something that needs it.

    The peertube database did not have the vulnerable extension enabled. They got access but connecting to another database:

    We did not have pgcrypto installed in the peertube database, but I overlooked that someone could connect to the main postgres database if they say had a nodejs plugin running.

    From that database they escaped. So if they only had access to the peertube database, that path would have been cut off for the attackers.

    also at that point, the question arises why not just run everything in qubes OS, each service in its own VM and its own VLAN.

    VLAN's suck. They allow for traffic to travel within each VLAN them, unmonitored and unrestricted. Sometimes red teamers call that "hard outside, soft inside, like an eggshell".

    Better, is a private VLAN. Private VLAN's enable the firewall to monitor or block all traffic within them. For many usecases, a single private VLAN can replace the complex, many VLAN setups that people spend so much effort setting up. You just block everything within itself from communicating with eachother, and then you can explicitly allow the stuff that actually needs to talk.

    Often, there is no reason to allow devices with a VLAN to communicate with eachother. And even if you are allowing intra-pvlan communication within a private VLAN, you can now monitor the traffic, which you can't do with a regular VLAN.

    Qubes OS

    Yeah. That's basically what virtual machine or application kernel based runtimes are doing. The trick is that they are designed for this usecase, with the goal of making the isolation as cheap and performant as possible. Qubes runs full Linux VM's since it is designed for a desktop isolation usecase.

    Anyway. It's a matter of threat model and effort. I like application containers/vm container runtimes due to how simple and easy they are to run, and the clear security benefits they provide. Install in < 30 min, configure the container runtime, restart your containers, done. Switching from a regular Linux desktop to Qubes is not as simple, so it's harder for me to recommend that, and it becomes a matter of threat model.

    It's also common to separate services out in different Proxmox VM's, which offers isolation benefits akin to Qubes.

    I run 3 separate database servers on the same OS because I made a bad decision at one point, and I regret it. I just don’t have time to merge them.

    Congrats on the security isolation!

    In all seriousness, you should be able to migrate them into the same database by dumping the database with pg_dump or a similar utility, and then loading them up using pg_restore. Other databases have equivalent tools. I used the Dbeaver open source database GUI to do this a few days ago.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 4 months ago (1 child)

    They got access but connecting to another database:

    We did not have pgcrypto installed in the peertube database, but I overlooked that someone could connect to the main postgres database if they say had a nodejs plugin running.

    how? did they use the same database user account for all databases? unless I misunderstood it, peertube's database user shouldn't be able to operate in other databases of the same server.

    VLAN's suck. They allow for traffic to travel within each VLAN them, unmonitored and unrestricted. Sometimes red teamers call that "hard outside, soft inside, like an eggshell".

    nonsense. if you don't use VLANs, you are essentially using a single huge VLAN. of course using VLANs don't exclude monitoring and firewall restrictions. could as well say, networking sucks, lets disconnect everything. if you don't set up monitoring, and you don't set up restrictions, then yeah, there will be no monitoring and no restrictions, like on any network.

    Better, is a private VLAN. Private VLAN's enable the firewall to monitor or block all traffic within them.

    didn't you just say VLANs wholesale suck?

    also, peertube will require access to the internet..

    You just block everything within itself from communicating with eachother,

    only if it was so simple. you can set up routing restrictions between subnets on the IP level, but the switch will gladly forward all traffic anywhere inside of the VLAN, according to the destination MAC address. with that, a compromised system can confuse every other on the VLAN with ARP poisoning and faking DHCP servers.

    In all seriousness, you should be able to migrate them into the same database by dumping the database with pg_dump or a similar utility, and then loading them up using pg_restore. Other databases have equivalent tools. I used the Dbeaver open source database GUI to do this a few days ago.

    yeah, that's the easier part. but one of the databases is mysql, which I want to get rid of completely. and conversion is nontrivial. probably dbveaver could handle it though.

  • source
  • parent
  • hideshow 1 child comment
  • only if it was so simple. you can set up routing restrictions between subnets on the IP level, but the switch will gladly forward all traffic anywhere inside of the VLAN, according to the destination MAC address. with that, a compromised system can confuse every other on the VLAN with ARP poisoning and faking DHCP servers.

    This is what private VLAN's fix. The switch isolates all traffic, forwarding it to the firewall instead, where the firewall can then monitor and control it. It's usually done with a combination of port isolation, where layer2 traffic within a subnet is essentially blocked, and proxying the arp requests. Nothing can communicate with each other directly at the Layer 2 level, only with the switch, which then replies to all ARP requests instead. Then the switch forwards the traffic that was supposed to go to that IP address through the firewall and back as Layer 3 traffic.

    with that, a compromised system can confuse every other on the VLAN with ARP poisoning and faking DHCP servers.

    This is what Private VlAN's fix. Any ARP requests a device attempts is simply blocked at the switch level via port isolation. Only the switch is able to communicate with attached devices unrestricted. It serves the DHCP, and assigns and IP address... and then if the device attached to the port attempts to lie about it's IP address or the like, the switch simply ignores it since it knows what ports are supposed to have what IP addresses (port security).

    This allows for much more granular isolation, but also a simpler architecture, since you can replace complex multi VLAN setups with fewer private VLAN's. Maybe even just a single private VLAN. I say VLAN's suck because by default, yeah they kinda suck. You pointed out the problems. I guess private VLAN's are a type of VLAN but they are a different thing, just like not having any VLAN's is really technically just one big VLAN.

    yeah, that’s the easier part. but one of the databases is mysql, which I want to get rid of completely. and conversion is nontrivial. probably dbveaver could handle it though.

    Is it a custom service? Or a service you are consuming from someone else? If the services supports mysql/maria/postgres, I would be worried that the adapter under the hood might be using different schema or something like that.

    It does look like dbeaver has a data transfer feature: https://dbeaver.com/docs/dbeaver/Data-transfer/#supported-formats

    Where you can transfer data across tables, across databases, and even across database types. There is also "Data export" mentioned on that page, where you can export data to json, or other non sql formats. If the schema match, maybe you could use that to transfer.

    If the services supports both mysql and postgres, you might be able to start by making a backup of the mysql database, loading that into a test database, and then setting up a clone of the service, but pointed at postgres instead. Then you could investigate the schema, or safely attempt data transfer from the mysql replica into the postgres database. Or mariadb, but mariadb is compatible with mysql (fork of it), so I am assuming you meant postgres which is different.

  • source
  • parent
  • [–] 14 points 4 months ago

    Oof, that sucks :(

  • source
  • Oof, hope it works out for them 😣

  • source
  • [–] 9 points 4 months ago

    Damn, i hope the femcelmemes crew is fine

  • source
  • [–] 8 points 4 months ago

    Bummer! I was wondering what had happened. Thanks for the update!

  • source
  • [–] 3 points 4 months ago* (last edited 4 months ago)

    Thank you very much for sharing this, it makes all Lemmy instances safer. Good job!

    Im curious how they could execute that postgres archive command to write a marker. Did they use the oauth token to be able to do that?

    Just not sure how they can run postgres queries as a normal user. What made that possible?

  • source
  • [–] 1 point 4 months ago

    Ha that instance's mods got all upset at me for pointing out you shouldn't celebrate "kys posts"

  • source
  • 3 comments in c/meta@jlai.lu view that post
    [–] [S] 7 points 4 months ago* (1 child)

    Traduction auto des infos importantes:

    Les mots de passe sont chiffrés dans la base de données ; si vous aviez un mot de passe suffisamment complexe, aléatoire ou impossible à deviner, et qui n'avait jamais été compromis auparavant, vous êtes probablement en sécurité — bien qu'il soit tout de même recommandé de le changer. Toute information personnelle que vous avez fournie (noms réels, adresses e-mail, dates, etc.) est potentiellement entre les mains du pirate.

    Vous devez considérer que la double authentification (2FA/TOTP) a probablement été compromise et la reconfigurer si vous l'utilisiez ; toutefois, sans accès aux mots de passe valides, l'attaquant ne peut pas faire grand-chose avec les codes 2FA. En théorie, l'attaquant a également pu accéder aux messages privés et aux publications privées sur Sharkey. En théorie, des données Matrix/Synapse ont aussi pu être exposées, mais cela ne concernerait que le contenu non chiffré, le contenu chiffré restant hors de portée de l'attaquant.

    Nous ferons notre possible pour révoquer tous les jetons et sessions de connexion ; vous devrez donc vous reconnecter sur chaque appareil pour chacun de nos services. Nous procédons également au renouvellement des paires de clés d'activité sur tous nos services afin d'éviter toute attaque par usurpation d'identité. Ce renouvellement étant une opération manuelle, nos instances seront progressivement remises en ligne, une par une, une fois sécurisées.

  • source
  • hideshow 1 child comment
  • [–] 2 points 4 months ago

    Ouin c'est moche 🫂

  • source