What i'm saying is...
if the attackers goal is only to get passwords, you will not be dealing with a bigger problem. In that hypothetical there would not be a bigger problem or any other problem.
the only problem is passwords leaking in that case.
The attacker goes out of their way to not cause any other problems on the server.
they do this to avoid getting noticed by admins.
as long as admin does not know there is malware on their server, the malware could run for years harvesting passwords. That would be the hypothetical attackers only goal on that server - not to bother anything, just to harvest user email passwords.
and the admin will not be dealing with a "bigger problem", because the admin will not know they've been hacked, because hacker does not cause any problems on the server. admin will think everything is fine on their server.
there could be email servers right now that are compromised and yielding passwords in this way, and if dovecot suddenly started writing those passwords the logs in some scrambled way - the malware would suddenly stop being able to harvest clear text passwords. hacker then could either quietly go away, or start doing something else on the machine, which the admins may or may not become aware of. might get a big surprise that they've been hacked.
This type of "quiet" malware of course definitely exists in the real world, for example, on phones. Many people's phones have been hacked and they are unaware of it, and they continue using the phone for years without realizing it's been hacked.
Sometimes attackers mess up the devices they hack, sometimes they don't, they just quietly use the hacked device for their own purposes (which of course are the hacks to really worry about). whenever there are big announcements of hacks to major organizations, the story always unfolds that the hackers had access for quite a while before admins became aware. this is the timeframe that really puts one's "security efforts" to the test - after machine is compromised, but before admins are aware.
it makes no sense to make things easy for hackers during this time when they are operating in the target machines/network and the admins are not yet aware that devices have been compromised.
in mitigating such risk, why not go for the "low hanging fruit" by simply not storing passwords on disk in clear text ? unless there is some reason why clear text passwords actually have to be written to disk.
-- John Tulp johntulp@tulpex.com tulpex
On Tue, 2022-10-11 at 17:58 +0300, Odhiambo Washington wrote:
@Tulp - the attacker has to 0wn your server first. In which case they will have found a password to SSH in - regardless of dovecot being there or not.
You will be dealing with a bigger problem than dovecot.
On Tue, Oct 11, 2022 at 5:39 PM John Tulp johntulp@tulpholdings.com wrote:
I find this conversation "interesting". Serveria, i think some can't see the attack scenario where the attacker's goal is simply to get email passwords, and nothing else. it would make sense for their strategy to do nothing else "bad" on the server to attract attention to their intrusion. In that case, all they would do is send back the treasure trove of passwords to their home server(s), and sit there, remaining possibly for years, hiding, exploiting the fact that dovecot, with no code modification, will allow them to grab email passwords. If a dovecot server has thousands of email accounts, that represents thousands of other devices they could target, which is worth much more to the attacker than a single dovecot server. Oh well, food for thought. On Tue, 2022-10-11 at 15:11 +0300, Serveria Support wrote: > Yes, I realize that. But I can't think of a reason this password is > necessary in the logs. It's kind of a backdoor and has to be removed > from code. Why make intruder's life easier? > > On 2022-10-11 13:39, Arjen de Korte wrote: > > Citeren Serveria Support <support@serveria.com>: > > > >> Yes, there is a tiny problem letting the attacker change this value > >> back to yes and instantly get access to users' passwords in plain > >> text. Apart from that - no problems at all. :) > > > > If an attacker is able to modify your Dovecot configuration, you have > > bigger problems than leaking your users' password. Much bigger...-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)