Hacker breaching Postfix SASL PLAIN authentication via sasl_username and spamming

SYSTEM INFORMATION
OS type and version: Ubuntu
Webmin version: 1.973
Virtualmin version: 6.16
Related products version: Postfix

We have a stock Ubuntu 20.04 / Virtualmin installation.

A hacker is breaching Postfix and rotating IPs to avoid us blocking them.

We have:

  1. Changed, and tested, the user’s email password.
  2. We have disabled login for the user in Virtualmin so it’s displaying red as if it’s working.

In spite of this, the hacker is still able to log on, and send email.

Example of event:

Aug 11 15:23:27 server-name postfix/smtpd[1521637]: AA1176CD007: client=189-210-152-183.static.axtel.net[189.210.152.183], sasl_method=PLAIN, sasl_username=our-user@example.com

I really don’t know what to say except that someone is able to use Postfix to send email, from random IP addresses, apparently using one of our usernames.
Whose password has been changed. Whose account login is disabled.

My remedy for now is to monitor the log for that event and when I see it do this:

root@server-name:~# firewall-cmd --add-rich-rule='rule family=ipv4 source address=189.210.152.183 reject' --permanent
success

root@server-name:~# firewall-cmd --reload
success

# service postfix restart

root@server-name:~# postqueue -p | tail -n +2 | awk 'BEGIN { RS = "" } /our-user@example/ { print $1 }' | tr -d '*!' | postsuper -d -

The last command is to clear the queue because we’re expecting to get blacklisted.

For some reason updating the firewall rule doesn’t take effect until I restart Postfix which I find very strange but anyway.

Please I need some advice.

Are you sure you’re not seeing queued emails from before you disabled the user? I don’t see how they’d successfully authenticate after disabling…the password becomes impossible to use to authenticate (it gets an ! prepended, making it never valid). Spammers tend to spew as much mail as possible as fast as possible, so thousands might queue up.

1 Like

Hi @Joe,

Thanks for the reply.

Are you sure you’re not seeing queued emails

Yep we are sure. Here is a screenshot:

On this screenshot the red user’s password was changed. Also the user is disabled that’s why it’s red.

But I’m tailing the log file

tail -f /var/log/mail.log | grep "sasl_username=user-user@example"

and every few minutes yet another new IP address, a new message in the queue.

The last command in my sequence postqueue is trashing the queued messages, and there are new one deposited all the time.

I’m thinking the attacker has null’ed the password or something.

Here is my only other clue in View All Headers, received from localhost 127.0.0.1

Unless they’ve obtained root, they can’t have nulled the password. They might be able to reset the password with a buggy RoundCube password reset, though, if you’ve got RoundCube installed and an old version of the Virtualmin password plugin enabled (we don’t maintain that or have anything to do with it, but I seem to recall it had security issues in the past).

Are you sure you’re enforcing authentication? What’s your smtpd_recipient_restrictions in the Postfix main.cf?

Are you sure you’re enforcing authentication?

Not sure how to check but hopefully all is on defaults.

What’s your smtpd_recipient_restrictions in the Postfix main.cf?

smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_policy_service inet:127.0.0.1:10023

I’m thinking if they obtained root then things would be a lot worse than a single repeated user logging in and sending email.

We’ve just backed up the mailbox using IMAPSYNC to another server, and we’re about to entirely delete it, and recreate it. Perhaps it will reset something bad.

EDIT: Recreating the mailbox didn’t work, still having breaches.

Any tips on checking if there are holes here:

  • permit_mynetworks
  • permit_sasl_authenticated
  • reject_unauth_destination
  • check_policy_service
  • inet:127.0.0.1:10023

Edit 2:

We have completely deleted the mailbox, but the hacker is still logging in to Postfix using that username. Need advanced Postfix support will pay $$

What’s in mynetworks? I assume they’re coming in from somewhere postfix considers local, somehow.

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

We’re thinking it’s a website breach due to 127.0.0.1 in view headers on email but I did full text searching in /var/log/virtualmin for specific IPs that are breaching and we don’t see Apache access log entries.

Also client had a WordPress website, but that’s disabled now and problem persists. Every four minutes a new IP.

All that’s left is maybe Usermin or some other random website, and I have to point of some sophistication because they’re using a username that did exist but doesn’t anymore. Does Usermin have an access log?

/var/usermin/miniserv.log

But, I doubt it’s Usermin. If the user doesn’t exist, it can’t login to Usermin.

Are log entries still showing a remote client IP and username?

Any clues in the journal for saslauthd? (journalctl -fu saslauthd to tail the log, probably, though I’m not sure the daemon is called that on Ubuntu…I know it is on CentOS).

Well I’ve done full text search from /var/ now and I don’t see any IPs matching.

/var/log/mail.log shows

Aug 11 17:35:08 our-server postfix/smtpd[1869769]: ACE586CD4C1: client=mx-ll-223.206.226-178.dynamic.3bb.co.th[223.206.226.178], sasl_method=PLAIN, sasl_username=our-user@example.com
Aug 11 17:40:42 our-server postfix/smtpd[1872933]: 149A66CDE13: client=unknown[190.120.253.81], sasl_method=PLAIN, sasl_username=our-user@example.com

journalctl -fu saslauthd works but mostly shows failure events and doesn’t seem to relate to these breaches.

You can also look at everything from that unit and search the journal (with /searchterm, if you use the standard pager, which is less, I think), using journalctl -u saslauthd. So, you can search for that username.

I’m not sure how the sasl_username would get populated without a sasl auth event happening in the log.

@vander.host To me this looks like they get access from WordPress, just install Wordfence on that website and scan, Also check that WordPress website for ‘old’ and no longer maintained plug-ins. Wordfence might tell you anyway. Update to latest version and remove any not used themes / plug-ins once as they might get still access through those plug-ins or themes whatsoever, I am thinking of this because you changed password for email and they still get access. Perhaps updating this account to use latest PHP and check the environment is fully up to date, Install CSF firewall and enable the mail locks so you get warnings and so on. But WordPress would def. be my concern.
Nick

Try disabling greylisting, which I think is responsible for the 127.0.0.1:10023 entry in smtpd_recipient_restrictions. They might be getting in that way.

Yes right! That’s why He must need to clear the queue after disabling the user! :slight_smile:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.