another extortion email check
I am seeing a number of extortion emails where the hacker has gotten my email address and an old password from "the dark web". (Probably one of many lists that are out there from one of the many mega-hacks that have occurred.) Is there a way to check for a specific 1-2 words in the body being repeated > n times? The emails seem to be camouflaging their body with random HTML and encoding chars. But they like to repeat my old username and an old password a large number of times pretty clearly (I guess to get our attention). If I can check for these terms (individually would be fine), I think I could setup some meta rules that would score the number of hits in ranges. Once or twice would probably be no score. 3-5 times would be a reasonable score. >5 hits would be an almost automatic spam score. Please help, apparently this person "knows everything about me" :) -AJ
Re: another extortion email check
On 5/1/2020 10:23 AM, AJ Weber wrote: > I am seeing a number of extortion emails where the hacker has gotten > my email address and an old password from "the dark web". (Probably > one of many lists that are out there from one of the many mega-hacks > that have occurred.) > > Is there a way to check for a specific 1-2 words in the body being > repeated > n times? The emails seem to be camouflaging their body > with random HTML and encoding chars. But they like to repeat my old > username and an old password a large number of times pretty clearly (I > guess to get our attention). > > If I can check for these terms (individually would be fine), I think I > could setup some meta rules that would score the number of hits in > ranges. Once or twice would probably be no score. 3-5 times would be > a reasonable score. >5 hits would be an almost automatic spam score. > > Please help, apparently this person "knows everything about me" :) Hi AJ, in KAM.cf, see my CRIM ruleset. It's what I use for these type of scam emails. For your specific question, look at maxhits / multiple and the __KAM_COUNT_URIS might get you a hint. Regards, KAM
Re: another extortion email check
Please help, apparently this person "knows everything about me" :) I got a rash of these a year or two ago, and have started getting a few more reciently. I haven't looked at the body of the recient ones, so don't know if they are still using the standard text. However, the identiying feature is that the subject is a single word, which is the stolen password. You should be able to catch these with a single custom rule along the lines of headerSTOLEN_PASSWORDSubject=~ /old_password/ scoreSTOLEN_PASSWORD10 Loren
Re: another extortion email check
On Fri, 1 May 2020, Loren Wilton wrote: Please help, apparently this person "knows everything about me" :) I got a rash of these a year or two ago, and have started getting a few more reciently. I haven't looked at the body of the recient ones, so don't know if they are still using the standard text. However, the identiying feature is that the subject is a single word, which is the stolen password. You should be able to catch these with a single custom rule along the lines of headerSTOLEN_PASSWORDSubject=~ /old_password/ scoreSTOLEN_PASSWORD10 That's what I do. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Once you’ve convinced yourself that your job is to protect the proles from themselves, any foul action you take becomes excusable, or even noble. That’s progressivism in a nutshell. -- Stephen Green @ instapundit --- Today: May Day - Remember 110 million people murdered by Communism
Re: another extortion email check
Yes, noticed that as well and considered making it simple with that rule. Probably best thing to do anyway. Thank you both. -AJ On 5/1/2020 5:08 PM, John Hardin wrote: On Fri, 1 May 2020, Loren Wilton wrote: Please help, apparently this person "knows everything about me" :) I got a rash of these a year or two ago, and have started getting a few more reciently. I haven't looked at the body of the recient ones, so don't know if they are still using the standard text. However, the identiying feature is that the subject is a single word, which is the stolen password. You should be able to catch these with a single custom rule along the lines of header STOLEN_PASSWORD Subject =~ /old_password/ score STOLEN_PASSWORD 10 That's what I do.
Re: another extortion email check
On 5/1/20 1:55 PM, Loren Wilton wrote: You should be able to catch these with a single custom rule along the lines of header STOLEN_PASSWORD Subject =~ /old_password/ score STOLEN_PASSWORD 10 I'd pondered doing such. But I dislike the fact that the (compromised) password is stored in clear text and wonder about collision with other people using the same password (or strings of characters). Is there any way to compare hashed strings of text? E.g. take each word from a message (header or body), hash it and look for a match of the hashed password? I feel like storing any password in clear text, previously compromised or not, is a Bad Idea™. I would also want to have some way to associate the (hashed) password with a specific account to avoid collisions for other accounts that might not have been compromised. I don't know if it would be able to create the granularity that I want with a meta-rule. Something that matches the account name (or some other similar identifier) and then check the hashed password. I also don't know that I would want the overhead of hashing every word in messages unless they were otherwise suspicious enough to warrant such in depth scrutiny. Note: Everywhere I say "hash", I would really like to see salted and hashed. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: another extortion email check
Well, if you want to do it the hard way there may be a way. I notice that three recient examples I have all failed DKIM check. They also all have a very long header line that appears to have been inserted either by outlook.com or the originating spamware: X-VadeSecure-Cause. This has a very long hashed or possiby base-64 string. While this seems to be part of the outlook.com spam checking info, for all three messages I looked at, the first line (at least) of this cryptic blob was identical. That likely means the message bodies are identical. You could do a match for that and a meta to check that and dkim fail. In my case I could maybe do something like: header _UNSECURE_CAUSE X-VadeSecure-Cause =~ /gggruggvucftvghtrhhoucdtuddrgeduhedrieehgdefkecutefuodetggdotefrodftvfcurfhroh/ header _AUTH_FAIL X-Authentication-Results =~ /dkim=\"fail\"/ header _SUB_ONE Subject =~ /\s/ meta PASSWORD_SCAM _UNSECURE_CAUSE && _AUTH_FAIL && _SUB_ONE score PASSWORD_SCAM 10 This strikes me as a lot of work and probably pretty fragile, and unnecesary. The compromised password is already in plain text in the subject of the message; there isn't much point in hiding it other than embarassment. Loren
Re: another extortion email check
On Sat, 2 May 2020 12:47:12 -0700 Loren Wilton wrote: > Well, if you want to do it the hard way there may be a way. > > I notice that three recient examples I have all failed DKIM check. > They also all have a very long header line that appears to have been > inserted either by outlook.com or the originating spamware: > X-VadeSecure-Cause. This has a very long hashed or possiby base-64 > string. While this seems to be part of the outlook.com spam checking > info, for all three messages I looked at, the first line (at least) > of this cryptic blob was identical. That likely means the message > bodies are identical. You could do a match for that and a meta to > check that and dkim fail. > > In my case I could maybe do something like: > > header _UNSECURE_CAUSE X-VadeSecure-Cause =~ > /gggruggvucftvghtrhhoucdtuddrgeduhedrieehgdefkecutefuodetggdotefrodftvfcurfhroh/ That exact string occurs in a Vade Security header, X-ME-VSCause, added by Fastmail on a completely unrelated legitimate email I received. I think it's more like an obfuscated information header for Vade's own use.
Re: another extortion email check
That exact string occurs in a Vade Security header, X-ME-VSCause, added by Fastmail on a completely unrelated legitimate email I received. I think it's more like an obfuscated information header for Vade's own use. I guess I'm not surprised. I would say then that it is a useless header as a spam or scam marker. Personally I'll stick with the easy method of a subject rule looking for the offending password, or hopefully ex-password. Loren
Re: another extortion email check
On 5/2/20 1:47 PM, Loren Wilton wrote: The compromised password is already in plain text in the subject of the message; there isn't much point in hiding it other than embarassment. What if the email server with the list of plain text passwords is compromised and said list of plain text passwords is released to a wide audience? The list of previous compromised passwords could have been very private (known corporate hack or something like that) and not released to a wide audience. Now, your list of plain text passwords on the email server is the source of a larger and more public release. Why have that list of plain text passwords /anywhere/ if you don't have to? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: another extortion email check
Le 03/05/2020 à 05:27, Grant Taylor a écrit : On 5/2/20 1:47 PM, Loren Wilton wrote: The compromised password is already in plain text in the subject of the message; there isn't much point in hiding it other than embarassment. What if the email server with the list of plain text passwords is compromised and said list of plain text passwords is released to a wide audience? The list of previous compromised passwords could have been very private (known corporate hack or something like that) and not released to a wide audience. Now, your list of plain text passwords on the email server is the source of a larger and more public release. Why have that list of plain text passwords /anywhere/ if you don't have to? In the context of a list of passwords known to be compromised, it is hopefully fair to assume that they are no longer in current use, and thus no longer of any importance. If it isn't fair to assume that, then the organisation has bigger issues in any case! -- John
Re: another extortion email check
On 5/4/20 6:16 AM, John Wilcock wrote: In the context of a list of passwords known to be compromised, it is hopefully fair to assume that they are no longer in current use, and thus no longer of any importance. If it isn't fair to assume that, then the organisation has bigger issues in any case! None of that changes the fact that storing a list of clear text passwords is against current industry best practice. Would you want to explain tot he board of directors / CEO that systems you administer were the source of passwords being compromised because you didn't encrypt / hash the passwords? It does not matter where or how the passwords you put in the list came from or were previously exposed. The fact remains that you are describing maintaining a list of clear text passwords. This is plain and simply against current industry best practice. Further, it would fail security audits at many companies I have worked for. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: another extortion email check
On 5/4/20 10:09 AM, Jeff Mincy wrote: The best practice is to not use common or continue to use exposed passwords. Scripts are probably trying to log into your ssh using those passwords. I completely agree on both accounts. I think you are worrying about the wrong thing. I obviously disagree. I'm already worrying about not using exposed passwords. I'm also worried about creating a list of plain text passwords. I think you're only worrying about the former and not giving any consideration to the latter. The exposed passwords being used in the extortion emails are already widely known and have already been exposed. Yes, the example you cited, and many others, are quite well known. But those aren't the only exposed passwords. If you are still using the exposed password then you've got bigger problems. I completely agree that (re)using exposed passwords is a problem. Bigger or not is a different debate. If you are no longer using the exposed password then disclosing the previously used password further is not going to make any difference. I disagree. Storing any plain text passwords is a bad practice and should be avoided. As such, storing plain text passwords /does/ make a difference. But, if you are really worried about it, don't write a spamassassin rule looking for your exposed passwords in the subject. Which is why I have not. It's also why I asked if there was a way to compare hashed text. To quote: "Is there any way to compare hashed strings of text?" I'll note that my question hasn't been answered. Instead, people have focused on something not germane to my question. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: another extortion email check
On Mon, 2020-05-04 at 13:03 -0600, Grant Taylor wrote: > Which is why I have not. It's also why I asked if there was a way to > compare hashed text. To quote: > > "Is there any way to compare hashed strings of text?" > > I'll note that my question hasn't been answered. Instead, people > have > focused on something not germane to my question. > Encrypt them and put them in a single column database table that's also the prime key for the table? Lookup by encrypting the item being checked before looking for an SQL hit count: select count(*) where log.key = key; 0=miss, 1=hit, 2+ = error. Should run fast. Of course, that would need an SA plugin, but Perl SQL interface code isn't hard and is fairly compact. For added protection, keep the database on an encrypted partition. Any database should do: MariaDB, SQLite, PostgreSQL,... You get points for added security by obscurity it you can stick it in a corner of an existing, unrelated database. Martin
Re: another extortion email check
On Mon, 4 May 2020, Grant Taylor wrote: On 5/4/20 10:09 AM, Jeff Mincy wrote: If you are no longer using the exposed password then disclosing the previously used password further is not going to make any difference. I disagree. Storing any plain text passwords is a bad practice and should be avoided. *if* they are being actively used for authentication, either by the security system (which is a glaring flaw in the design of the security system) or as a reference for accessing the secured resource (e.g. a plaintext passwords file on your desktop, which is user error). I would also suggest it's a bad idea if the user generates passwords using a pattern. A compromised password that is no longer in use anywhere could still potentially expose the pattern used to generate passwords that *are* currently in use. As such, storing plain text passwords /does/ make a difference. But, if you are really worried about it, don't write a spamassassin rule looking for your exposed passwords in the subject. Which is why I have not. It's also why I asked if there was a way to compare hashed text. To quote: "Is there any way to compare hashed strings of text?" I'll note that my question hasn't been answered. Instead, people have focused on something not germane to my question. ...thus, the answer to your question is "no, there is not". You could potentially obfuscate the RE by doing something like: header LEAKED_PASSWORD Subject ~= /\x50\x40\x73\x73\x77\x30\x72\x7c\x29/ ...which would at least not have the password trivially visible in plain text for anyone who can read the config file. (You'd of course, not use a rule name that indicated it was about a password.) -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Where We Want You To Go Today 07/05/2007: Microsoft patents in-OS adware architecture incorporating spyware, profiling, competitor suppression and delivery confirmation (U.S. Patent #20070157227) --- 4 days until the 75th anniversary of VE day
Re: another extortion email check
On 5/4/20 2:06 PM, Martin Gregorie wrote: Encrypt them and put them in a single column database table that's also the prime key for the table? Lookup by encrypting the item being checked before looking for an SQL hit count: select count(*) where log.key = key; 0=miss, 1=hit, 2+ = error. Should run fast. Yep. We're describing similar concepts, encrypt / hash the known value (from the email) and check to see if it's encrypted counterpart is in the list. Though, only encrypting the password and not associating the username could allow for collisions between users with the same password. I think that the minimum needed is the the password and a username (in the form of an email address). Of course, that would need an SA plugin, but Perl SQL interface code isn't hard and is fairly compact. For added protection, keep the database on an encrypted partition. Any database should do: MariaDB, SQLite, PostgreSQL,... Yep. I see little benefit of an SQL database vs rules with the encrypted (hashed) passwords (possibly salted with the usernames / email address) in the SpamAssassin config file. Well, save for possible ease of administration in that SA's config file doesn't need to be updated when passwords are compromised. You get points for added security by obscurity it you can stick it in a corner of an existing, unrelated database. I'd be afraid that would be like setting yourself up for failure in the future. Sure, it's obscure. But it's a ticking time bomb. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: another extortion email check
On Mon, 2020-05-04 at 15:14 -0600, Grant Taylor wrote: > I see little benefit of an SQL database vs rules with the encrypted > (hashed) passwords (possibly salted with the usernames / email > address) > in the SpamAssassin config file. Well, save for possible ease of > administration in that SA's config file doesn't need to be updated > when > passwords are compromised. > The list of such passwords might get rather long, so using a database both makes maintenance easier, as you spotted, and also keeps a lot of junk out of the rule sets. One Perl module and one or two rules triggering it seem a lot easier to maintain than a whole heap of rules containing unreadable junk but of course ymmv unless, of course you write code to autogenerate the rules, but it still sounds like a good way to inflate the ruleset to no good purpose. However, I've long realised that not everybody is as keen on databases as I am. > > You get points for added security by obscurity it you can stick it > > in a corner of an existing, unrelated database. > > > Yep, not really a serious suggestion. Martin
Re: another extortion email check
On 5/4/20 2:51 PM, John Hardin wrote: *if* they are being actively used for authentication, either by the security system (which is a glaring flaw in the design of the security system) or as a reference for accessing the secured resource (e.g. a plaintext passwords file on your desktop, which is user error). Nope. There is no qualification for if it's okay to store passwords unencrypted or not. I would also suggest it's a bad idea if the user generates passwords using a pattern. A compromised password that is no longer in use anywhere could still potentially expose the pattern used to generate passwords that *are* currently in use. This is one of the many reasons why any and all passwords should be stored in a secure manner. You have no way of knowing / guessing if the passwords use such a pattern or not. Ergo, default to storing them in a safe manner; encrypted / hashed. ...thus, the answer to your question is "no, there is not". Fair enough. You could potentially obfuscate the RE by doing something like: header LEAKED_PASSWORD Subject ~= /\x50\x40\x73\x73\x77\x30\x72\x7c\x29/ That is encoded, not encrypted. It is trivially reversible. So much so that SpamAssassin, et al., don't even need to reverse it. "P@ssw0r|)" is better stored as base64 encoding UEBzc3cwcnwp in that at least binary bit manipulation is required. It's trivial for scripts to do, but more difficult for humans to do. Ideally, "P@ssw0r|)" would be stored as a hash from a one way trap function, c8fc4bce46291fd606914d8dcee45465. It's neigh impossible reverse contemporary hashes. ...which would at least not have the password trivially visible in plain text for anyone who can read the config file. (You'd of course, not use a rule name that indicated it was about a password.) Real security doesn't depend on the secrecy of the algorithm used. You can have the rule named "LEAKED_PASSWORD" without any problem. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: another extortion email check
On 5/4/20 3:09 PM, Jeff Mincy wrote: You will have to write a perl plugin for SpamAssassin that finds passwords in an email message and MD5 hashes those passwords and compares against a list of previously saved hashed passwords. The list of passwords could be stored in various ways. ACK Identifying what is and is not a password might be error prone. I suspect it might be more efficient (for the programmer) to simply (salt and) hash every word (possibly over a specific length) in the message and compare that to the list of (salted) hashes. Sure, it's somewhat brute force. But if it's only applied to messages with the proper criteria, it might be acceptable. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: another extortion email check
On 5/4/20 3:59 PM, Martin Gregorie wrote: The list of such passwords might get rather long, so using a database both makes maintenance easier, as you spotted, and also keeps a lot of junk out of the rule sets. I absolutely agree. I like the idea of keeping data outside of configuration files. One Perl module and one or two rules triggering it seem a lot easier to maintain than a whole heap of rules containing unreadable junk but of course ymmv unless, of course you write code to autogenerate the rules, but it still sounds like a good way to inflate the ruleset to no good purpose. Agreed. I think $DatabaseTechnology's main benefit is keeping the password data outside of the configuration files. As I write this, I may have thought of another idea. However, I've long realised that not everybody is as keen on databases as I am. I have absolutely nothing wrong with a database per say. I just want to make sure that it's the proper thing and that the proper type of database is used for a given need. select count(*) where log.key = md5(key); You can move the md5 generation into the SQL server. Of course, you'd want to be mindful of the communications channel between SpamAssassin and the SQL server. I'm not sure how to have SpamAssassin iterate all the words in the message through this routine. If it requires a custom SpamAssassin module, then it might be better to do calculate the MD5 hash in SpamAssassin and avoid the security implications between SpamAssassin and SQL server. Yep, not really a serious suggestion. ;-) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: another extortion email check
On Mon, 2020-05-04 at 16:25 -0600, Grant Taylor wrote: > I think $DatabaseTechnology's main benefit is keeping the password > data outside of the configuration files. > Agreed, in this sort of corner case. > select count(*) where log.key = md5(key); > Neat. > You can move the md5 generation into the SQL server. Of course, > you'd want to be mindful of the communications channel between > SpamAssassin and the SQL server. > I was thinking that the database/whatever would be populated by feeding in lists of dsto=len passwords, since they seem to be more or less freely and at least semi-legally available, but now I'm wondering if it would be possible to use some sort of generic pattern matching to trigger a rule associated with a more complex Perl module which would extract the password string from a message, encrypt it and check it against the database. It it hits, score the message as spam. If not, either: (a) lob its encrypted form into the DB and return a zero score or (b) write its plaintext form to a file for somebody to look at and decide whether its a false positive or to load it into the database. Either way the nonmatch should score zero. Note: this depends on whether SA modules can adjust their triggering rule's score -I don't know if this is possible. The sort of recognition rule I'm thinking of could be something as simple as if its a Subject header with no spaces in the title and either a known length or a prefix such as "password:" > I'm not sure how to have SpamAssassin iterate all the words in the > message through this routine. > Presumably passwords in body text have some surrounding text you could match on along the lines of money with menaces: "I know your bank password, which is x so pay me now". However, since I've not seen any of these messages, this is probably the point where somebody who is getting them will speak up and say that I'm talking garbage. > If it requires a custom SpamAssassin module, then it might be better > to do calculate the MD5 hash in SpamAssassin and avoid the security > implications between SpamAssassin and SQL server. > That makes sense because the closer to source you can encrypt the password the more secure the whole system becomes. Doing it at the database end would require a fairly gung-ho database - one that supports a built-in (usually proprietary) procedural language. PostgreSQL, SQLServer, Sybase, DB2 and other heavyweights have provide procedural languages / stored procedures, but the likes of SQLite, Derby, MariaDB probably do not. Martin
Re: another extortion email check
On Mon, 4 May 2020, Grant Taylor wrote: On 5/4/20 2:51 PM, John Hardin wrote: *if* they are being actively used for authentication, either by the security system (which is a glaring flaw in the design of the security system) or as a reference for accessing the secured resource (e.g. a plaintext passwords file on your desktop, which is user error). Nope. There is no qualification for if it's okay to store passwords unencrypted or not. I would also suggest it's a bad idea if the user generates passwords using a pattern. A compromised password that is no longer in use anywhere could still potentially expose the pattern used to generate passwords that *are* currently in use. This is one of the many reasons why any and all passwords should be stored in a secure manner. You have no way of knowing / guessing if the passwords use such a pattern or not. Ergo, default to storing them in a safe manner; encrypted / hashed. ...thus, the answer to your question is "no, there is not". Fair enough. You could potentially obfuscate the RE by doing something like: header LEAKED_PASSWORD Subject ~= /\x50\x40\x73\x73\x77\x30\x72\x7c\x29/ That is encoded, not encrypted. It is trivially reversible. So much so that SpamAssassin, et al., don't even need to reverse it. Note I said "obfuscate". "P@ssw0r|)" is better stored as base64 encoding UEBzc3cwcnwp in that at least binary bit manipulation is required. It's trivial for scripts to do, but more difficult for humans to do. Ideally, "P@ssw0r|)" would be stored as a hash from a one way trap function, c8fc4bce46291fd606914d8dcee45465. It's neigh impossible reverse contemporary hashes. Both of those require code changes to SA, best implemented in the form of a new plugin. I was assuming that the question "can a hash be compared?" was implying "using existing code", for which the answer is no. Otherwise the answer is trivially "Yes. Patches welcomed." The big problem for either approach is: how much of the message do you include in the operation, and where are the boundaries? The only *reliable* option I can see is "hash each word separately" - which is going to be a ton of work for very little gain, unless it is only applied to small parts of the message, for example, the subject header (modulo the inevitable cases where the entire email body is in the subject header either do to incompetence or an attempt to bypass body text filters). Then we're making assumptions about where the leaked password would appear, which potentially weakens the detection. I could see a simple plugin that hashes each word in the subject header separately into a new internal header like: X-Spam-Subject-Hashed: c8fc4bce46291fd606914d8dcee45465 635e304de3f24679f41e789a5d0d5059 6e2458faf2b8349b5c3fc2dc8bf6a880 2a462d9a15339fef5d7a54dc8b53ed95 ...to which normal header rules could be applied, e.g.: header LEAKED_PASSWORD X-Spam-Subject-Hashed ~= /\bc8fc4bce46291fd606914d8dcee45465\b/ There probably would need to be a length limit for this to address the Incompetent Sender case noted above. Note that even this is potentially trivially easy for the spammer to avoid, if they do something like: Subject: Your password is "P@ssw0r|)"! ...which would at least not have the password trivially visible in plain text for anyone who can read the config file. (You'd of course, not use a rule name that indicated it was about a password.) Real security doesn't depend on the secrecy of the algorithm used. I'm aware of that. I was suggesting something better than plaintext (granted, not much) that can be implemented *today*. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Our politicians should bear in mind the fact that the American Revolution was touched off by the then-current government attempting to confiscate firearms from the people. --- 4 days until the 75th anniversary of VE day
Re: another extortion email check
On Tue, 5 May 2020, Martin Gregorie wrote: On Mon, 2020-05-04 at 16:25 -0600, Grant Taylor wrote: I think $DatabaseTechnology's main benefit is keeping the password data outside of the configuration files. Agreed, in this sort of corner case. select count(*) where log.key = md5(key); Neat. Agreed, but we still have the boundary problem. In the hopes of leveraging existing facilities: Is there a way to mark individual bayes tokens as poison pills? The message is already being tokenized and scanned for Bayes (presuming you have that enabled). If there's a way to mark a token in Bayes as causing an automatic 1.000 then that might be a usable approach. (Granted, it's not encrypted.) -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- I'm seriously considering getting one of those bright-orange prison overalls and stencilling PASSENGER on the back. Along with the paper slippers, I ought to be able to walk right through security. -- Brian Kantor in a.s.r --- 4 days until the 75th anniversary of VE day
Re: another extortion email check
You can move the md5 generation into the SQL server. Of course, you'd want to be mindful of the communications channel between SpamAssassin and the SQL server. I was thinking that the database/whatever would be populated by feeding in lists of dsto=len passwords, since they seem to be more or less freely and at least semi-legally available, How about modifying the interface to bayse to MD5 all of the words in the email and match against that? There seems to be a basic conceptual flaw here with the current thinking. It is bad to store an unencrypted password. *How do you KNOW that any random word in any random email is NOT a password?* You don't. Any word or phrase can be a password. Putting ANY word or phrase in a rule or database is potentially storing an unencrypted password, even if the database used is named "shopping list" or the rule is KNOWN_SPAMMER_NAMES. Just because the extortion email claims to know a password does not mean that it IS (or ever was) a password. The email address it is sent to might be the acual password, and the putative password might be a mcguffin. Or some phrase in the extortion mail might be the acutal password. What if some major account is compromised because the password of "I knOw YOur passwOrd" is discovered and you had a rule that contained =~ /i know your password/i ? That woulnd't look very good for you, would it? Clearly you are best off modifying the input stream to SA to MD5 all of the input text, and rewrite all local rules to use MD5 rule names and have MD5 lookup text. You can probably write a simple preprocessor for the existing SA rule base, so you don't have to take chances there. Loren
Adding approximate matching (see also: another extortion email check)
Hi, I’ve recently gotten emails (a lot of them, as it happened) with the following subject line: Subject: H¡gh level of r¡sk. Your account has been hacked. Change yøur passwørd. and I’ve seen other similar emails in the past using simple mechanical substitutions (Greek alpha for ‘a’, Cyrillic a for ‘a’, Cyrillic A for ‘A’, Cyrillic VE for ‘B’, Cyrillic IE for ‘E’, Cyrillic EN for ‘H’, etc). The String::Approx module (see https://metacpan.org/pod/String::Approx) allows for weighting insertions/deletions/substitutions, and what we’re seeing here is a heavy use of substitutions. I’m thinking about a module where you could enter the ASCII string of: High level of risk. Your account has been hacked. Change your password. and all permutations of it via substitution would be matched as long as some threshold isn’t exceeded (say 10 or 15% substitutions, which seems like a reasonable ceiling). There are also Spam I’ve seen where words have been deliberately misspelled as a way of avoiding exact matches, with doubled letters being dropped, similar letters being transposed (’n’ for ‘m’, ‘z’ for ’s’, ‘k’ for ‘c’, etc) so simply replacing non-ASCII letters with their ASCII “approximates” wouldn’t be sufficient because of the shuffling in the ASCII space as well. Has anyone else considered approximate string matching? Thanks, -Philip
