This is the first time I've heard of slopsquatting, but it does seem like a major and easily exploitable risk.
However, blocking an email domain will dissuade only the lowest effort attacker. If the abusers think slopsquatting is effective, they'll easily be able to find (or create) an alternative email provider to facilitate it.
And assuming that the attacks will persist, sometimes it's better to let them keep using these massive red flags like an inbox.ru email so that it remains a reliable way to separate the the fraudulent from legitimate activity.
reconnecting · 30m ago
'tirreno guy' here.
You can use open-source security analytics (1) to detect fraudulent accounts instead of blocking domain names. Blocking domains only shows your system is fragile and will likely just shift the attackers to use other domains.
Feel free to contact us if you need assistance with setup.
Id say it’s big standard for php apps and have been for awhile. Wordpress has a similar install flow. Docker images are provided tho.
reconnecting · 17m ago
Yes, Matomo/Piwik, WordPress, and ProcessWire have more or less the same installation steps, but maybe we missed something along the way.
reconnecting · 24m ago
Can you elaborate, please?
snickerdoodle12 · 8m ago
The instructions aren't all that unusual for PHP software, especially those that target shared hosting, but are unusual compared to most other software.
> Download a zip file and extract it "where you want it installed on your web server"
The requirements mention apache with mod_rewrite enabled, so "your web server" is a bit vague. It wouldn't work with e.g. `python -m http.server 8000`. Also, most software comes bundled with its own web server nowadays but I know this is just how PHP is.
Huh, so anyone who can access my web server can access the installation script? Why isn't this a command line script, a config file, or at least something bound to localhost?
> After the successful installation, delete the install/ directory and its contents.
Couldn't this have been automated? Am I subject to security issues if I don't do this? I don't have to manually delete anything when installing any other software.
kstrauser · 1m ago
I'll side with you here. This gives attackers a huge window of time in which to compromise your service and configure it the way they want it configured.
Yes, this is not something specific to tirreno, as it's the usual installation process of any PHP application.
kassner · 16m ago
composer install should be pretty much what one needs nowadays. Any installing scripts (although you really shouldn’t) can also be hooked into it.
WmWsjA6B29B4nfk · 10m ago
It’s funny they are talking about low hundreds of emails. This is what a single properly instructed human can create with any provider in a few hours, no bots needed.
Scene_Cast2 · 48m ago
Oh hey, I was the person who reported this.
mananaysiempre · 31m ago
I have to say that I don't understand the approach. On one hand, addresses @inbox.ru are administered by Mail.Ru, the largest Russian free email host (although I have the impression that its usage is declining), so quite a few (arguably unwise) real people might be using them (I’ve actually got one that I haven’t touched in a decade). On the other, the process for getting an address @inbox.ru is identical to getting one @mail.ru and IIRC a couple of other alternative domains, but only this specific one is getting banned.
takipsizad · 24m ago
pypi has blocked signups from outlook before.
I don't think they care about the impact it creates
dewey · 6m ago
I know a bunch of sites who do that and the problem is usually that register emails get flagged by outlook and never arrive, causing a lot of support burden. Easier to then nudge people into the direction of Gmail or other providers that don't have these issues.
nzeid · 15m ago
I don't understand how a mere account signup is the bar for publishing packages. Why not queue the first few publishes on new accounts for manual review?
stavros · 1m ago
Probably because that would be too expensive for PyPI.
Tiberium · 10m ago
I'm really not following -- why does the ban specifically focus on a single domain instead of attempting to solve the core issue? Do the maintainers not know that accounts for any big email provider (gmail, outlook, you name it) can be bought or created for very, very cheap. Which is obviously what the attackers will now do after this ban.
The blog post references [0] which makes it seem like the maintainers do, in fact, just ban any email providers that attackers use instead of trying to solve the issue.
What is the core issue and how would you solve it?
lysace · 21m ago
I don't understand why this is newsworthy. Spam never ends.
perching_aix · 20m ago
Because of:
> See a previous post for a previous case of prohibiting a popular email domain provider.
lysace · 17m ago
That was outlook.com/hotmail.com. So? Incompetent/malicious/disengaged mail providers come in all shapes and forms.
perching_aix · 13m ago
The implication is that this other email host also being one of the popular ones means there'll be a more widespread user impact than when they block smaller providers. So just like with Outlook, they put out this statement on why they're doing this.
lysace · 10m ago
Ah, I see your point.
Although: I don't think the kind of developers that use low quality email providers like that follow HN.
ajross · 36m ago
The whole model is broken. The NPM/PyPI idea (vscode extensions got in similar trouble recently) of "we're just a host, anyone who wants to can publish software through us for anyone in the world to use with a single metaphorical click" is just asking for this kind of abuse.
There has to be a level of community validation for anything automatically installable. The rest of the world needs to have started out by pulling and building/installing it by hand and attesting to its usefulness, before a second level (e.g. Linux distro packagers) decide that it's good software worth supplying and supporting.
Otherwise, at best the registries end up playing whack-a-mole with trickery like this. At worst we all end up pulling zero days.
jowea · 19m ago
And who is going to do all this vetting and with what budget?
perching_aix · 3m ago
Could force package publishers to review some number of other random published packages every so often. (Not a serious pitch.) Wouldn't create any ongoing extra cost I believe?
ajross · 6m ago
Right now: we are. And we're collectively paying too much for a crap product as it stands.
Debian figured this out three decades ago. Maybe look to them for inspiration.
However, blocking an email domain will dissuade only the lowest effort attacker. If the abusers think slopsquatting is effective, they'll easily be able to find (or create) an alternative email provider to facilitate it.
And assuming that the attacks will persist, sometimes it's better to let them keep using these massive red flags like an inbox.ru email so that it remains a reliable way to separate the the fraudulent from legitimate activity.
You can use open-source security analytics (1) to detect fraudulent accounts instead of blocking domain names. Blocking domains only shows your system is fragile and will likely just shift the attackers to use other domains.
Feel free to contact us if you need assistance with setup.
(1) https://github.com/tirrenotechnologies/tirreno
> Download a zip file and extract it "where you want it installed on your web server"
The requirements mention apache with mod_rewrite enabled, so "your web server" is a bit vague. It wouldn't work with e.g. `python -m http.server 8000`. Also, most software comes bundled with its own web server nowadays but I know this is just how PHP is.
> Navigate to http://your-domain.example/install/index.php in a browser to launch the installation process.
Huh, so anyone who can access my web server can access the installation script? Why isn't this a command line script, a config file, or at least something bound to localhost?
> After the successful installation, delete the install/ directory and its contents.
Couldn't this have been automated? Am I subject to security issues if I don't do this? I don't have to manually delete anything when installing any other software.
In my recent experience, you have about 3 seconds to lock down and secure a new web service: https://honeypot.net/2024/05/16/i-am-not.html
The blog post references [0] which makes it seem like the maintainers do, in fact, just ban any email providers that attackers use instead of trying to solve the issue.
[0] https://blog.pypi.org/posts/2024-06-16-prohibiting-msn-email...
> See a previous post for a previous case of prohibiting a popular email domain provider.
Although: I don't think the kind of developers that use low quality email providers like that follow HN.
There has to be a level of community validation for anything automatically installable. The rest of the world needs to have started out by pulling and building/installing it by hand and attesting to its usefulness, before a second level (e.g. Linux distro packagers) decide that it's good software worth supplying and supporting.
Otherwise, at best the registries end up playing whack-a-mole with trickery like this. At worst we all end up pulling zero days.
Debian figured this out three decades ago. Maybe look to them for inspiration.