Ghost sign up and spam?

Using Ghost
82

Do you think that adding VPS IP address hosting the ghost blog to this setting in Mailgun would help @Cathy_Sarisky ?

Capture dā€™eĢcran 2025-02-08 aĢ€ 16.56.49
Capture dā€™eĢcran 2025-02-08 aĢ€ 16.56.491634Ɨ831 43.1 KB

83

No, this would not change anything. All requests between Ghost and Mailgun will use your VPS IP, since this is an operation that the Ghost server triggers, not a visitor in the browser.

The ā€œfirewallā€ needs to be on Ghostā€™s side ā€“ hence the block list that doesnā€™t let the spam domains through.

Ghost also has brute force protection built in. If too many requests from the same IP are spotted, the client is blocked for a certain period of time. You can set these in your configuration and overwrite these defaults:

Itā€™s extremely hard to predict attack vectors ā€“ so the key really is to monitor activity and take action when you spot anything unusual. The webhooks that Cathy mentioned are a great option to do that:

If you want to build a monitoring system, you could hook these up to Zapier or any other automation platform.

2 Likes
84

Thanks @jannis. I followed a procedure with Mailgun. I had to reset all the passwords and API keys on my account and Iā€™m waiting for their reply to find out if my account will be reactivated.

I donā€™t understand from your explanation whether or not I should touch the default Ghost core firewall. I have the impression that Iā€™d be better off not touching it, and even if I wanted to touch it, I wouldnā€™t know what to put here.

Have you made any changes to this? What can it do for you?

85

Do you mean the spam settings? I have not changed anything about it on Magic Pages and think that they are sensible the way they are set out of the box.

What it can do for you will entirely depend on what you want to reach. You basically have options to tighten the brute force options etc. ā€“ though, as far as I am aware none of the recent spam signups triggered any of these.

86

So Iā€™m not going to touch them. Iā€™m waiting for a reply from Mailgun in the hope that theyā€™ll reactivate my account.

87

So, interesting turn of events here.

I just noticed in my Mailgun logs that there are loads of emails to domains on Magic Pages wide block lists again.

Which was odd. Because I triedā€¦and I could not sign up with these domains, as expected.

Looking at the tokens table, I see this in the data volumn:

{"email":"example@txt.att.net","type":"updateEmail","oldEmail":"example@edny.net"}

So yeah, theyā€™ve got a new angleā€¦target all the members that have been created BEFORE the block list and update their email addresses. This will bypass the block list and create countless emails again.

I am trying to come up with a quick win to solve this, but potentially the block list should also be considered for email updates like these.

88

I was confused why I got a mail delivery failure notifications of one of my blocked domains.

I just checked, the user does not exist in members list anymore.

89

Interesting. So these are spammer accounts that are live from before the blocklist? Interestingā€¦

Looks like the email update is here:

And youā€™d want to pick up this code from over in RouterControllerā€¦

I think!

90

Yeah, I noticed that too. I feel like I donā€™t understand the full picture yet. As inā€¦how do these email update requests come in. Because the usual route needs full authentication to work, but a) I do not see members with the ā€œold emailsā€ and b) the member_login_events are empty too :person_shrugging:

I might miss something obvious. Itā€™s too late hereā€¦

That was my assumption. But as @ajfriesen pointed out, these members do not exist. I am confusedā€¦

91

I just checked on the members list on the web only.

I did not check the database.
Maybe there are some leftovers somewhere?

92

Iā€™ll have a look tomorrow again to see if I can replicate what I saw in the database. I am not logging request bodies in my access logs for privacy and security, so other than seeing that the requests were made, I am a bit blind at the moment.

For now, I have set up a WAF rule that filters requests to /members/api/member/email endpoint that that contain any of the block list domains. That calmed my Mailgun logs a bit :smiley:

Will report if I find anything else tomorrowā€¦

1 Like
93

Thx! Weā€™ll get this patched

4 Likes
94

Pls update to v5.110.3 for fix ā€“ this is being rolled out to Ghost(Pro) rn

4 Likes
95

Thank you, @John! I can only repeat: huge thanks to the entire team for acting so fast :pray:

1 Like
96

Hi everyone ā€” thanks for getting this sorted. Iā€™m a self-taught self-hoster and was surprised by my Mailgun charges this month after I thought I took the correct steps. But just to be clear, as of right now, is there anything else I need to do besides:

  1. Add the spammy domains (in my case, @txt.att.net) to be blocked on the site config file and the Ghost backend (Settings ā†’ Advanced ā†’ Spam Filters)
  2. Remove the spammy members
  3. Upgrade to Ghost 5.110.3

Am I missing anything? Obviously I donā€™t want to open a ticket with Mailgun since Iā€™ve seen how that goesā€¦

Thanks!

97

Yep, just add more of those domains you find in this thread.
They will come :wink:

2 Likes
98

If helpful for others, hereā€™s a list of spam domains that Iā€™ve learned ā€œthe hard wayā€ (i.e. after receiving the Mailgun bill and inspecting the logs):

tmomail.net
txt.att.net
txt.bell.ca
email.uscc.net
pcs.rogers.com
msg.telus.com
vtext.com
edny.net

(In related news, I submitted a PR to make the Spam Filters text field vertically-resizable :slight_smile: šŸŽØ Added ability to vertically resize the Spam Filters text area by evanwon Ā· Pull Request #22311 Ā· TryGhost/Ghost Ā· GitHub)

3 Likes
99

Docker images are up to date now as well. Happy updating!

1 Like
100

Iā€™m seeing a new tactic now; after updating my spam filters and blocking any traffic from the aiohttp user agent Iā€™m seeing this pattern from the spammers:

  1. Fully register with an edny.net email address
  2. Get a JWT from hitting /members/api/session/ (using a normal user-agent like "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36"
  3. Use that JWT against the /members/api/member/email/ endpoint to to change the email to an address from the spamlist (e.g. <number>@txt.att.net)
  4. Repeat

They do this over and over, but right now Iā€™m only seeing it for the one account (although the email associated with the account may change if a victim of the spam accepts the email change).

Because there are no checks for blocked domains on email change (only on signup), the spammers are effectively using this method to bypass the blocking controls.

The good news is that the /members/api/member/email/ endpoint isnā€™t used as part of a normal browser flow. So if you a user modifies their email address via the browser, or if you as an admin modify the email address via the browser, you wonā€™t hit that endpoint. My understanding is that youā€™ll only hit that endpoint if you are using some automations or integrations there.
(This was not correct, actually.)

As a result, Iā€™ll be updating my reverse proxy to block any hits to that API. If you do use that API yourself, you should be able to implement a generic block and then whitelist a specific IP or custom user-agent for your automation.

101

The update to v5.110.3 should fix this comprehensively though. The target of the fix was not the API route, but the underlying controller:

Are you sure you updated to this version and the block list is set?