bugtraq - Re: Is predictable spam filtering a vulnerability?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 18 Jun 2004 11:52:01 -0700
From: PSE-L@...l.professional.org (Sean Straw / PSE)
To: bugtraq@...urityfocus.com
Subject: Re: Is predictable spam filtering a vulnerability?

At 19:27 2004-06-17 +0200, Joel Eriksson wrote:
>On Wed, Jun 16, 2004 at 01:26:28PM +0200, R Armiento wrote:
>[snip]
> > For example: attacker 'A' sends 'B' a social engineering request
> > for "the secret plans" and says "if you are unsure, forward my
> > request to your boss and ask if this is okay". 'B' forwards the
> > email to his boss 'C' and asks "Is this okay?". However, 'C':s
> > spam filter silently drops the email. 'A' forges a reply from
> > 'C' saying: "Sure, no problem, go ahead."
>
>Many will probably discard the above as farfetched or ignore it
>since it's not a "real" vulnerability that gives remote root to
>the attacker, I think it's beautiful though. :)

A far more plausible vulnerability would be for the attacker, if they had 
exploited the mail and/or DNS hosts used by user B to intercept or redirect 
mail.  This would significantly increase the workability of further 
socially engineered exploits.

FTR, the proposed failing wouldn't be possible if such decisions were 
digitally signed (PGP/GNUPG, etc) - the "forged" email would fail to be 
verified.

The success of the supposed mail vulnerability relies upon the gullibility 
of user B, not upon an automated system.  There are other factors to 
consider in there as well, such as SPF filtering at the mailhost of user B 
(which could reject the forged mail because the originating mailserver 
isn't correct for the sending address), or of user B sending a response to 
the forged authorization, and THAT message going unresponded to, or at 
least of user A (attacker) not RECEIVING that message to know to respond to 
it.  For that matter, it relies upon the message from user B to user C not 
including other details which user A would fail to address when sending the 
forged reply, and that user B doesn't simply pick up the phone and call 
user C, which renders the whole matter moot.

---
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.

  Sean B. Straw / Professional Software Engineering
  Post Box 2395 / San Rafael, CA  94912-2395