News items for tag security - Koos van den Hout

Noticed in the recent logs, lots of variations on:

Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <mail@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <support@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <reply@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: srv-eml.info [185.222.211.11]: Possible SMTP RCPT flood, throttling.
Jun  6 19:15:41 gosper sm-mta[22466]: x56HFCbH022466: <financeiro@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22473]: x56HFVoi022473: <biuro@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22468]: x56HFItg022468: <michael@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22471]: x56HFPIC022471: <chris@some.domain>... No such user in domain 
Jun  6 19:16:51 gosper sm-mta[22466]: x56HFCbH022466: lost input channel from srv-eml.info [185.222.211.11] to MTA-v6 after rcpt
Jun  6 19:17:16 gosper sm-mta[22475]: x56HFc06022475: <jobs@some.domain>... No such user in domain 
Jun  6 19:17:17 gosper sm-mta[22475]: x56HFc06022475: <wh5gkoxp5wqk@some.domain>... No such user in domain 
Jun  6 19:17:18 gosper sm-mta[22475]: x56HFc06022475: lost input channel from srv-eml.info [185.222.211.11] to MTA-v6 after rcpt
Jun  6 19:17:18 gosper sm-mta[22475]: x56HFc06022475: from=<20tv13b4bu0h2107@europcar.ua>, size=0, class=0, nrcpts=1, proto=ESMTP, daemon=MTA-v6, relay=srv-eml.info [185.222.211.11]

All from the same IP, trying a lot of addresses (and failing), with a retry later trying all those addresses again.

Just seen in an e-mail with a virus, looking like it's something from a bank:

Security tips

1. Install virus detection software and personal firewall on your computer. This software needs to be updated regularly to ensure you have the latest protection.
2. To prevent viruses or other unwanted problems, do not open attachments from unknown or non-trustworthy sources.
3. If you discover any unusual activity, please contact the remitter of this payment as soon as possible. 

But the attachment has malware.

While making a lot of my websites available via HTTPS I started wondering about enabling Server Name Indication (SNI) because the list of hostnames in the one certificate (subjectAltName parameter) keeps growing and they aren't all related.

So on a test system with haproxy I created two separate private keys, two separate certificate signing requests and requested two separate certificates. One for the variants of camp-wireless.org and one for most of the idefix.net names. The whole requesting procedure happened on the system where my automated renewal and deployment of LetsEncrypt certificates with dehydrated happens so the request went fine. For the configuration of haproxy I was following HAProxy SNI where 'terminating SSL on the haproxy with SNI' gets a short mention.

So I implemented the configuration as shown in that document and got greeted with an error:

haproxy[ALERT] 123/155523 (3435) : parsing [/etc/haproxy/haproxy.cfg:86] : 'bind :::443' unknown keyword '/etc/haproxy/ssl/webserver-idefix-main.pem'.

And found out that the crt keyword has to be repeated.

This is why I like having a test environment for things like this. Making errors in the certificate configuration on the 'production' server will give visitors scary and/or incomprehensible errors.

So the right configuration for my test is now:

frontend https-in
    bind :::443 v4v6 ssl crt /etc/haproxy/ssl/webserver-campwireless.pem crt /etc/haproxy/ssl/webserver-idefix-main.pem

And testing it shows the different certificates in use when I use the -servername parameter for openssl s_client to test things.

$ openssl s_client -connect testrouter.idefix.net:443 -servername idefix.net -showcerts -verify 3
..
Server certificate
subject=/CN=idefix.net
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
..
Verification: OK
$ openssl s_client -connect testrouter.idefix.net:443 -servername camp-wireless.org -showcerts -verify 3
..
Server certificate
subject=/CN=www.camp-wireless.org
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
..
Verification: OK

The certificates are quite separate. Generating the certificate signing requests with a separate private key for each request works fine.

So if I upgrade my certificate management to renew, transport, test and install multiple certificate for the main webserver it would work.

After upgrading to the new homeserver my old setup to allow two passwords for IMAPS logins so I can use a separate password for IMAPS access for those devices that insist on saving a password without asking.

I have the following PAM libraries:

ii  libpam-modules 1.1.8-3.6    amd64        Pluggable Authentication Modules

And I debugged the problem using the pamtester program which makes debugging this problem a lot easier than constantly changing the configuration and restarting the imap server.

The relevant configuration now is:

# PAM configuration file for Courier IMAP daemon

#@include common-auth
# here are the per-package modules (the "Primary" block)
auth    required    pam_succeed_if.so quiet user ingroup users
#auth   [success=1 default=ignore]      pam_unix.so nullok_secure
auth    sufficient      pam_unix.so nullok_secure
auth    sufficient  pam_userdb.so db=/etc/courier/extrausers crypt=crypt use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
@include common-account
@include common-password
@include common-session

And now both my unix login password and the extra password are accepted.

I noticed a lot of entries in my mail logging about aborted smtp transactions

Mar 22 21:04:04 gosper sm-mta[30180]: x2MK437r030180: [193.169.254.68] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:04:58 gosper sm-mta[30229]: x2MK4vv0030229: [185.234.217.222] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:05:25 gosper sm-mta[30307]: x2MK5Oas030307: [193.169.254.68] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:06:01 gosper sm-mta[30328]: x2MK5xAc030328: [185.234.217.222] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:06:02 gosper sm-mta[30331]: x2MK5xg5030331: [185.222.209.209] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSP-v6

And I wondered what was going on, until I did a capture of the session and had a look:

    1   0.000000 185.234.217.222 → 82.95.196.202 TCP 68 55448 → 25 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
    2   0.000314 82.95.196.202 → 185.234.217.222 TCP 68 25 → 55448 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
    3   0.034751 185.234.217.222 → 82.95.196.202 TCP 56 55448 → 25 [ACK] Seq=1 Ack=1 Win=65536 Len=0
    4   6.038967 82.95.196.202 → 185.234.217.222 SMTP 395 S: 220-gosper.idefix.net ESMTP Sendmail 8.15.2/8.15.2/Debian-8; Fri, 22 Mar 2019 21:00:55 +0100; (No UCE/UBE) | 220-   This is a private SMTP server. | 220-   The use of this or any related system for the transmission of | 220-   Unsollicited Bulk E-mail (UBE) is prohibited. | 220 logging access from: [185.234.217.222](FAIL)-[185.234.217.222]
    5   6.072501 185.234.217.222 → 82.95.196.202 SMTP 76 C: EHLO 82.95.196.202
    6   6.072915 82.95.196.202 → 185.234.217.222 TCP 56 25 → 55448 [ACK] Seq=340 Ack=21 Win=29312 Len=0
    7   6.073011 82.95.196.202 → 185.234.217.222 SMTP 267 S: 250-gosper.idefix.net Hello [185.234.217.222], pleased to meet you | 250-ENHANCEDSTATUSCODES | 250-PIPELINING | 250-EXPN | 250-VERB | 250-8BITMIME | 250-SIZE | 250-DSN | 250-ETRN | 250-STARTTLS | 250-DELIVERBY | 250 HELP
    8   6.106154 185.234.217.222 → 82.95.196.202 SMTP 68 C: AUTH LOGIN
    9   6.106585 82.95.196.202 → 185.234.217.222 SMTP 86 S: 503 5.3.3 AUTH not available
   10   6.141445 185.234.217.222 → 82.95.196.202 TCP 56 55448 → 25 [FIN, ACK] Seq=33 Ack=581 Win=65024 Len=0
   11   6.141775 82.95.196.202 → 185.234.217.222 TCP 56 25 → 55448 [FIN, ACK] Seq=581 Ack=34 Win=29312 Len=0
   12   6.174430 185.234.217.222 → 82.95.196.202 TCP 56 55448 → 25 [ACK] Seq=34 Ack=582 Win=65024 Len=0

Each session starts ESMTP and even with the ESMTP reply not listing AUTH the next command is 'AUTH LOGIN' for authenticated smtp, and as soon as my server denies offering this the session gets aborted. This does mean no failed authentication attempt is logged which would trigger fail2ban.

This does look like a bit of a distributed attack, but without the network remembering that the attack is not going to work in this way and therefore trying it again and again.

Update: IPs active in this scanning attack sofar: 185.234.217.222 193.169.254.68 185.234.219.56 37.49.225.232 185.222.209.202 141.98.80.15 114.207.112.188 185.222.209.209 23.227.207.215 185.211.245.170 141.98.80.17 89.248.171.176 185.211.245.198 164.132.45.117 37.49.225.224 119.176.218.216 103.114.104.175 37.49.225.47 103.207.37.40 37.49.227.49 185.234.219.57

Update 2019-03-24: I noticed the incorrect EHLO above and looked at options for HELO/EHLO checking in sendmail. Searching did not show a lot of options, trying with the $&s delayed s macro did not fire on the given HELO/EHLO. So I kept searching and found the latest sendmail administration guide ('Bat book') with FEATURE(block_bad_helo). I activated this feature to see if it stops some of this traffic.

An interesting bit of news: SSH client gets patched after RSA key exchange memory vuln spotted.

The fixes implemented on PuTTY over the weekend include new features plugging a plethora of vulns in the Telnet and SSH client, most of which were uncovered as part of an EU-sponsored HackerOne bug bounty.

Get your updated putty at the PuTTY download page.

Update: Interesting visual change in putty: informational lines from the client are now prefixed by a putty logo. This could make it harder to mislead the user in certain attacks.

According to “FINAL WARNING” email – have they really hacked your webcam? - Naked Security there is a big flood the last day(s) of "Sextortion" scam mails going around. Don't fall for these. It's all fake.

A new level of stupid in the "I have you on video watching porn" extortion scams: the whole message embedded as an image, including the instructions to carefully cut and paste the bitcoin wallet address.

Links: Report history for 12Vso1cRX7zQovZG4wH7RAz2HqtdW1Lvek - Bitcoin Abuse Database, Bitcoin Address 12Vso1cRX7zQovZG4wH7RAz2HqtdW1Lvek.

Before, before, before.

In the inbox this morning, another attempt at extortion.

Subject: IMPORTANT! You have been recorded masturbating! I have Koos Website.mp4!

Hi there,

The last time you visited a porn website with teens,
you downloaded and installed the software I developed.

My program has turned on your camera and recorded
the process of your masturbation.

My software has also grabbed all your email contact lists
and a list of your friends on Facebook.

I have the - Koos Website.mp4 - with you jerking off to teens
as well as a file with all your contacts on my computer.

You are very perverted!

If you want me to delete both the files and keep the secret,
you must send me Bitcoin payment. I give you 72 hours for the payment.

If you don't know how to pay with Bitcoin, visit Google and search.

Send 2.000 USD to this Bitcoin address as soon as possible:

34vKT8SpK2zYAgJUDww9ih1o7Ky3JKmCdP
(copy and paste)

1 BTC = 3,850 USD right now, so send exactly 0.525386 BTC
to the address provided above.
Do not try to cheat me!
As soon as you open this Email I will know you opened it.
I am tracking all actions on your device.

This Bitcoin address is linked to you only,
so I will know when you send the correct amount.
When you pay in full, I will remove both files and deactivate my program.

If you don't send the payment, I will send your masturbation video
to ALL YOUR FRIENDS AND ASSOCIATES from your contact lists I hacked.

Here are the payment details again:

Send 0.525386 BTC to this Bitcoin address:

----------------------------------------
34vKT8SpK2zYAgJUDww9ih1o7Ky3JKmCdP
----------------------------------------


You саn visit police but nobody can help you. I know what I am doing.
I don't live in your country and I know how to stay anonymous.

Don't try to deceive me - I will know it immediately - my spy software is
recording all the websites you visit and all keys you press.
If you do - I will send this ugly recording to everyone you know,
including your family.

Don't cheat me! Don't forget the shame and if you ignore this message your
life will be ruined.

I am waiting for your Bitcoin payment.
You have 72 hours left.

Anonymous Hacker

Given the address it's clear someone managed to visit this website. Actually hacking my computer and removing the webcam cover or installing the webcam is harder!

Bitcoin links: Report history for 34vKT8SpK2zYAgJUDww9ih1o7Ky3JKmCdP - Bitcoin Abuse Database and Bitcoin Address 34vKT8SpK2zYAgJUDww9ih1o7Ky3JKmCdP.

Het blijft actueel: Verschillende afpersmails in omloop - Fraudehelpdesk.

Ik zie ze zelf ook op verschillende plekken. Trap hier niet in.

Dit keer een bitcoin adres waar nog geen transacties in zichtbaar zijn: 12PUa2SHjWAUEpZZUxQNvxa7epab7g2Ksb alleen is mij niet duidelijk of deze site het verschil tussen een echt aangemaakt adres zonder transacties of een willekeurig adres weet.

Toevoeging 2019-02-07: Een bedrag van 808 dollars in bitcoins staat nu in de wallet, in 2 transacties. Gegeven het bedrag in het originele mailtje zijn er dus 2 mensen ingetrapt.

Toevoeging 2019-02-11: Er is nu over de 3000 dollar in bitcoins binnen. Als ik zo naar de transacties kijk lijken er 7 mensen ingetrapt.

Nog meer informatie: Bitcoin Abuse Database for 12PUa2SHjWAUEpZZUxQNvxa7epab7g2Ksb (engelstalig).

Today I tried to follow a link to http://www.independentri.com/ but I got an error message:

451: Unavailable due to legal reasons

We recognize you are attempting to access this website from a country belonging to the European Economic Area (EEA) including the EU which enforces the General Data Protection Regulation (GDPR) and therefore access cannot be granted at this time

And indeed in the headers:

$ lynx -head -dump http://www.independentri.com/
HTTP/1.1 451 Unavailable For Legal Reasons

I see the real reason as 'not wanting to comply with European consumer protection laws'. I have no idea how many visitors the site is missing due to this regionblock but since it's a regional weekly newspaper in the United States of America: probably not a lot of the intended audience.

Ik kreeg een mail zoals deze Afpersingsmail: Bedreiging voor uw veiligheid! ***@*********.nl is gecompromitteerd. - Fraudehelpdesk.

De tekst leest kwa stijl of de auteur niet echt Nederlands kent en deels hulp heeft gehad van een automatische vertaling of van meerdere mensen die stukjes vertaald hebben.

Het volgen van het bitcoin adres in het mailtje (deels gemaskeerd bij fraudehelpdesk) levert een interresant beeld op: dit levert blijkbaar wel wat op. Als ik de bitcoin rekening opzoek op Bitcoin Address 1PRUG1TrBWKLpvMJYfYXhZVSDagSySqXuz zie ik diverse bijschrijvingen in de afgelopen twee dagen en een afschrijving. De eerste drie bijschrijvingen lijken erg op betalingen in de buurt van de genoemde 35 euro. Maar als ik diep in de transacties duik zonder enige voorkennis van bitcoin zie ik allemaal verwarrende dingen.

Opvallend is wel dat dezelfde wallet dus op meer plekken genoemd is. Daarmee is het traceren van degene die betaald heeft onmogelijk, waardoor het verhaal in de afpersingsmail ook compleet ongeldig is.

I use the logcheck package to monitor for unexpected log entries. Since upgrading to the new homeserver conway I noticed DNSSEC failures coming back regularly, even at weird times of the night while the domain names seemed related to services we sometimes interact with during the day. To search deeper I enabled query logging on DNS (with a short retention period) in order to find the source.

Eventually I found it: the DNSSEC failures came at the time the mail from logcheck was delivered, because it mentioned domain names that cause a DNSSEC failure. So the way to 'fix' this problem and avoid similar other problems was to whitelist logcheck mail.

Update 2018-10-05: That only helps when enabling the Mail::SpamAssassin::Plugin::Shortcircuit plugin and enabling the USER_IN_WHITELIST shortcircuit.

Update 2018-10-07: Even with whitelist and shortcircuit I still see queries for domain names in the logcheck mails. Call to spamassassin is now changed...

Now, once again...this time with FEEwing

This morning I was looking on shodan for open remote desktop servers in the work network since RDP was mentioned as an attack vector in the latest GANDCRAP ransomware.

Searching for '3389' on shodan found something completely different: an open industrial control system (ICS) for tankstation gauges.

IN-TANK VOORRAAD        

TANK PRODUCT             VOLUME TC VOLUME   VULVOL   HOOGTE    WATER     TEMP
  1  UL 98                 9757      9693    10283    939.2      0.0    20.09
  2  EURO                 2...

According to The Internet of Gas Station Tank Gauges -- Take #2 - Rapid7 this was already a reported issue in January 2015 and according to their research it may be possible to do bad things with this access.

The above is from a gas station I can find on google maps.

Oh I found the way to search for open remote desktop servers on shodan: port:3389.

According to this article: Students blamed for university and college cyber-attacks - BBC News the new pattern is that attacks on IT systems in higher education happen in active times in education.

Interesting quote (for me):

There was a very sharp decline in attacks in the Christmas, Easter and summer breaks and during half-terms - with attacks rising again sharply when terms resumed.

I remember starting in system administration and learning quickly that the Christmas holidays period was the busiest period in attempts to break in to computer systems all over the world. This was simply explained by the fact that the Christmas holidays are the most universal school holiday in the world and all the teenage hackers had time to play with computers, modems and networks.

Since activating sendmail authentication with secondary passwords I see a number of attempts to guess credentials to send mail via my system. This is not very surprising, given the constant attack levels on the wider Internet.

For work I am looking at log correlation and monitoring and with that in mind I noted that finding the right information from sendmail where and when the attempt came from is quite hard since there are several processes busy and it's hard to correlate the logging. The failed attempt is logged by saslauthd in /var/log/auth.log:

Aug 16 12:28:57 greenblatt saslauthd[32648]: pam_unix(smtp:auth): check pass; user unknown
Aug 16 12:28:57 greenblatt saslauthd[32648]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug 16 12:28:59 greenblatt saslauthd[32648]: do_auth         : auth failure: [user=monster] [service=smtp] [realm=idefix.net] [mech=pam] [reason=PAM auth error]
Aug 16 12:29:00 greenblatt saslauthd[32649]: pam_unix(smtp:auth): check pass; user unknown
Aug 16 12:29:00 greenblatt saslauthd[32649]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug 16 12:29:02 greenblatt saslauthd[32649]: do_auth         : auth failure: [user=monster] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

This is probably related to this sendmail log information:

Aug 16 12:28:56 greenblatt sm-mta[20716]: STARTTLS=server, relay=62.82.128.182.static.user.indesat.com [62.82.128.182] (may be forged), version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256
Aug 16 12:29:02 greenblatt sm-mta[20716]: w7GASspx020716: 62.82.128.182.static.user.indesat.com [62.82.128.182] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MSP-v6

But I can't be sure as there are multiple 'did not issue MAIL/EXPN/VRFY/ETRN' messages in the logs. So I can't build a fail2ban rule based on this.

----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014
.0.4830 / Virus Database: 4365/10772 - Release Date: 13/08/18

[-- Attachment #2: doc10089752487652120190813.docx.jar --]

I guess No known virus found was a better message for AVG.

The authenticated SMTP setup with sendmail and secondary passwords I created is also attracting a new kind of attack: trying credentials from dataleaks. Leading to interesting tries in the log:

Aug 10 17:29:01 greenblatt saslauthd[32650]: do_auth         : auth failure: [user=409shop.com] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Aug 11 10:48:42 greenblatt saslauthd[32649]: do_auth         : auth failure: [user=409shop.com] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

After thoroughly automating Let's Encrypt certificate renewal and installation I wanted to get the same level of automation for systems that do not expose an http service to the outside world. So that means the DNS-01 challenge within the ACME protocol has to be used.

I found out dehydrated Let's Encrypt certificate management supports DNS-01 and I found a sample on how to do this with bind9 at Example hook script using Dynamic DNS update utility for dns-01 challenge which looks like it can do the job.

It took me a few failed tries to find out that if I want a certificate for the name turing.idefix.net that it will request the TXT record for _acme-challenge.turing.idefix.net to make me prove that I have control over the right bit of DNS. I first assumed something in _acme-challenge.idefix.net which turned out wrong. So the bind9 config in /etc/bind/named.conf.local has:

zone "_acme-challenge.turing.idefix.net" {
        type master;
        file "/var/cache/bind/_acme-challenge.turing.idefix.net-zone";
        masterfile-format text;
        allow-update { key "acmekey-turing"; };
        allow-query { any; };
        allow-transfer {
                localnetwork;
        };
};

And in the idefix.net zone there is just one delegation:

_acme-challenge.turing  IN      NS      ns2

I created and used a dnskey with something like:

# dnssec-keygen -r /dev/random -a hmac-sha512 -b 128 -n HOST acmekey-turing
Kacmekey-turing.+157+53887

This gives 2 files, both with the right secret:

# ls Kacmekey-turing.+157+53887.*
Kacmekey-turing.+157+53887.key  Kacmekey-turing.+157+53887.private
# cat Kacmekey-turing.+157+53887.key
acmekey-turing. IN KEY 512 3 157 c2V0ZWMgYXN0cm9ub215

and configured it in /etc/bind/named.conf.options:

key "acmekey-turing" {
        algorithm hmac-md5;
        secret "c2V0ZWMgYXN0cm9ub215";
};

And now I can request a key for turing.idefix.net and use it to generate sendmail certificates. And the net result:

        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256          
        verify=OK)                                                              

SMTP between systems with TLS working and good certificates.

I needed to configure sendmail authenticated access because I want a strict SPF record for idefix.net which means I always have to make outgoing mail originate from the right server.

For the sendmail authenticated smtp bit I used How to setup and test SMTP AUTH within Sendmail with some configuration details from Setting up SMTP AUTH with sendmail and Cyrus-SASL. To get this running saslauthd is needed to get authentication at all and I decided to let it use the pam authentication mechanism. The relevant part of sendmail.mc:

include(`/etc/mail/sasl/sasl.m4')dnl
define(`confAUTH_OPTIONS', `A p')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl

And now I can login to sendmail only in an encrypted session. And due to sendmail and other services now having valid certificates I can set up all devices to fully check the certificate so I make it difficult to intercept this password.

And after I got that working I decided I wanted 'secondary passwords' just like I configured extra passwords for IMAPS access so I set up /etc/pam.d/smtp to allow other passwords than the unix password and restrict access to the right class of users.

auth    required    pam_succeed_if.so quiet user ingroup users
auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    sufficient  pam_userdb.so db=/etc/courier/extrausers crypt=crypt use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so

Now I can set up my devices that insist on saving the password for outgoing smtp and if it ever gets compromised I just have to change that password without it biting me too hard.