You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Henrik K <he...@hege.li> on 2021/07/01 05:25:01 UTC

Re: Office phish

On Wed, Jun 30, 2021 at 05:41:56PM -0400, Alex wrote:
> 
> I modified the ExtractText plugin to also process HTML files
> 
> extracttext_external    htmlcat /usr/bin/cat {}
> extracttext_use         htmlcat   .htm .html
> 

Quite horrible hack, as the result should be _rendered_ text.  Inserting raw
HTML for all body rules is probably breaking more things than fixing.

But yeah a "mimebody" ruletype would probably be useful..


Re: Office phish

Posted by Alex <my...@gmail.com>.
Hi,

> >> I realize blocking all javascript is prone to error,
> > What legitimate email uses javascript?
> And more important: which email clients do actually process Javascript
> that comes within an email? Thunderbird doesn't since 10 or 20 years
> ago. I don't know of any other as well. This phish is probably targeted
> to inferior web-based email readers who don't filter Javascript well.
> Are there any?

It's not a matter of processing/rendering javascript by default in an
email, but someone clicking the ".htm" file, even in Thunderbird,
which then renders the HTML/javascript in the browser.

In this case, the ".htm" file is a rogue O365 login page.

Re: Office phish

Posted by Alex Woick <al...@wombaz.de>.
>> I realize blocking all javascript is prone to error,
> What legitimate email uses javascript?
And more important: which email clients do actually process Javascript 
that comes within an email? Thunderbird doesn't since 10 or 20 years 
ago. I don't know of any other as well. This phish is probably targeted 
to inferior web-based email readers who don't filter Javascript well. 
Are there any?

Re: Office phish

Posted by Benny Pedersen <me...@junc.eu>.
On 2021-07-06 00:32, RW wrote:

> It's a question of whether a simple copy and paste from a web page to
> an email body copies any javascript. I don't see why it would.

diffrent mail programs will give diffrent results of embedded, i dont 
know if javascript in noscript html tag is even ignored or not, the only 
safe way to read mails is ignore scripting, unlees the js is just a 
hello world :=)

-- 

Before the script...

...After the script.

Re: Office phish

Posted by RW <rw...@googlemail.com>.
On Tue, 06 Jul 2021 00:16:00 +0200
Benny Pedersen wrote:

> On 2021-07-05 23:45, RW wrote:
> 
> >> > What legitimate email uses javascript?  
> >> Pretty common! many people copy and paste from webs.. and of course
> >> these are important mails! :-(  
> > 
> > I'm not sure what you are referring to there. If you copy and paste
> > a web page into an HTML email, are you not just copying the
> > formatting?  
> 
> https://www.w3resource.com/javascript/introduction/html-documents.php
> 
> embeeded javascript is possible


It's a question of whether a simple copy and paste from a web page to
an email body copies any javascript. I don't see why it would.

Re: Office phish

Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2021-07-06 at 00:16 +0200, Benny Pedersen wrote:
> On 2021-07-05 23:45, RW wrote:
> 
> > > 
> 
> https://www.w3resource.com/javascript/introduction/html-documents.php
> 
> embeeded javascript is possible
>
Yes, but it may well depend on how the e-mail was assembled.

A message Cut&Paste from a web page formatted with both
<table>..</table> and <ol>...</ol> formatting and displayed using Brave
to construct a new e-mail written, sent and received using Evolution
with the message composer set to use plaintext gave a single block of
body text that didn't contain any HTML formatting.

However, with composer preferences set to use HTML formatting, Evolution
restructured the HTML that was cut and pasted in as an attachment with 

Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="attachment.html"
Content-Type: text/html; charset="utf-8"; name="attachment.html"

as a preamble. and all the HTML formatting pretty much rewritten from
scratch and formatted as a block rather that keeping the original page's
indent structure. The plaintext section again had all HTML formatting
stripped out.

So, it would be interesting to know how similar the output of other
browser/MUA combos is to what Brave+Evolution generates. I would not be
surprised if the e-mail content has a close dependence on what MUA is
used and how its composer preferences are set - and possibly which
browser is being used as well.

Martin


 


Re: Office phish

Posted by Benny Pedersen <me...@junc.eu>.
On 2021-07-05 23:45, RW wrote:

>> > What legitimate email uses javascript?
>> Pretty common! many people copy and paste from webs.. and of course
>> these are important mails! :-(
> 
> I'm not sure what you are referring to there. If you copy and paste a
> web page into an HTML email, are you not just copying the formatting?

https://www.w3resource.com/javascript/introduction/html-documents.php

embeeded javascript is possible

Re: Office phish

Posted by RW <rw...@googlemail.com>.
On Tue, 6 Jul 2021 07:58:15 +0000 (UTC)
Pedro David Marco wrote:

>  
> 
> 
> On Monday, July 5, 2021, 11:45:42 PM GMT+2, RW
> <rw...@googlemail.com> wrote:
> >I'm not sure what you are referring to there. If you copy and paste a
> >web page into an HTML email, are you not just copying the
> >formatting?  
> 
> Agree RW, but... 
> copy and paste from web source to MUA works!

My presumption is that when you do that the browser puts a static
representation of a snapshot of the page into the clipboard. 

Copying across the full page, including javascript,  so another
application could reproduce the page from scratch wouldn't work. 

For example, if I go to an order in my Amazon account and hit ^A ^C and
then go to the windows mail app and paste the the clipboard into the
compose window, I get something that looks vaguely like the web page.
But the mail app isn't authenticated into Amazon and doesn't have
access to the cookies and other internal state within Chrome. The
personal information displayed must have come in the clipboard rather
than by running the javascript and getting it from Amazon.

Re: Office phish

Posted by Pedro David Marco <pe...@yahoo.com>.
 


On Monday, July 5, 2021, 11:45:42 PM GMT+2, RW <rw...@googlemail.com> wrote:
>I'm not sure what you are referring to there. If you copy and paste a
>web page into an HTML email, are you not just copying the formatting?

Agree RW, but... 
copy and paste from web source to MUA works!
----------Pedreter.

Re: Office phish

Posted by RW <rw...@googlemail.com>.
On Mon, 5 Jul 2021 08:01:25 +0000 (UTC)
Pedro David Marco wrote:

>  
> 
>    >On Thursday, July 1, 2021, 05:03:50 PM GMT+2, RW
>    ><rw...@googlemail.com> wrote:    
> 
> > What legitimate email uses javascript?  
> Pretty common! many people copy and paste from webs.. and of course
> these are important mails! :-(

I'm not sure what you are referring to there. If you copy and paste a
web page into an HTML email, are you not just copying the formatting?

Re: Office phish

Posted by Pedro David Marco <pe...@yahoo.com>.
 

   >On Thursday, July 1, 2021, 05:03:50 PM GMT+2, RW <rw...@googlemail.com> wrote:  

> What legitimate email uses javascript?
Pretty common! many people copy and paste from webs.. and of course these are important mails! :-(

Pedreter
  

Re: Office phish

Posted by RW <rw...@googlemail.com>.
On Thu, 01 Jul 2021 18:40:04 +0100
Martin Gregorie wrote:

> On Thu, 2021-07-01 at 18:59 +0200, Benny Pedersen wrote:
> > On 2021-07-01 17:03, RW wrote:
> >   
> > > > I realize blocking all javascript is prone to error,  
> > > What legitimate email uses javascript?  
> > 
> > and what mua will show html attachment as default ?  
> 
> Evolution is as configurable as any MUA I've used:
>  
> - Whether it defaults to showing plain text or the HTML attachment(s)
> is configurable (I use it defaulted to plain text).


I don't know evolution, but in other clients that kind of option is
typically about choosing between text/html and text/plain mime sections
within multipart/alternate. 

The email quoted has an empty text/html section with a separate
attachment of type application/octet-stream with filename=.htm. 

It probably relies on the attachment being opened in a separate
browser, so the javascript can run. 

Re: Office phish

Posted by Martin Gregorie <ma...@gregorie.org>.
On Thu, 2021-07-01 at 18:59 +0200, Benny Pedersen wrote:
> On 2021-07-01 17:03, RW wrote:
> 
> > > I realize blocking all javascript is prone to error,
> > What legitimate email uses javascript?
> 
> and what mua will show html attachment as default ?

Evolution is as configurable as any MUA I've used:
 
- Whether it defaults to showing plain text or the HTML attachment(s) is
  configurable (I use it defaulted to plain text).
- If showing plain text is configured, HTML, if any, appears as
  clickable attachments. 
- Animation scan be suppressed
- Remote content will only be loaded and displayed if the sender is in
  your contacts list
- It prompts you about sending HTML text to contacts who don't want it.

Evolution was developed as part of the Linux Gnome Desktop toolset, but
rapidly spread to other Linux desktops (I use XFCE) and is also a free
download for Windows.

Martin



Re: Office phish

Posted by Benny Pedersen <me...@junc.eu>.
On 2021-07-01 17:03, RW wrote:

>> I realize blocking all javascript is prone to error,
> What legitimate email uses javascript?

and what mua will show html attachment as default ?

Re: Office phish

Posted by RW <rw...@googlemail.com>.
On Thu, 1 Jul 2021 08:42:01 -0400
Alex wrote:


> I realize blocking all javascript is prone to error, 

What legitimate email uses javascript?

Re: Office phish

Posted by Benny Pedersen <me...@junc.eu>.
On 2021-07-01 17:42, Henrik K wrote:

> John's already done something that hits:
> 
> mimeheader   T_OBFU_HTML_ATTACH    Content-Type =~
> m,\bapplication/octet-stream\b.+\.html?\b,i
> 
> Maybe that along with checking for very short body etc.

add htmltidy to extract text plugin would also solve it, perl tidy is 
already done, so external shell commands is not needed in extract text 
for that part of it, save copy io time for another scanner

Re: Office phish

Posted by Henrik K <he...@hege.li>.
On Thu, Jul 01, 2021 at 08:42:01AM -0400, Alex wrote:
> Hi,
> 
> > > I modified the ExtractText plugin to also process HTML files
> > >
> > > extracttext_external    htmlcat /usr/bin/cat {}
> > > extracttext_use         htmlcat   .htm .html
> > >
> >
> > Quite horrible hack, as the result should be _rendered_ text.  Inserting raw
> > HTML for all body rules is probably breaking more things than fixing.
> >
> > But yeah a "mimebody" ruletype would probably be useful..
> 
> Would you explain a bit further? Until such a ruletype exists, how do
> you propose we solve this javascript issue? How do we search through
> MIME attachments without using ExtractText?

If it works for you, then use it.  Just making a point that it's _very_
blunt tool for the job that can mess other rules..

John's already done something that hits:

mimeheader   T_OBFU_HTML_ATTACH    Content-Type =~ m,\bapplication/octet-stream\b.+\.html?\b,i

Maybe that along with checking for very short body etc.


Re: Office phish

Posted by Alex <my...@gmail.com>.
Hi,

> > I modified the ExtractText plugin to also process HTML files
> >
> > extracttext_external    htmlcat /usr/bin/cat {}
> > extracttext_use         htmlcat   .htm .html
> >
>
> Quite horrible hack, as the result should be _rendered_ text.  Inserting raw
> HTML for all body rules is probably breaking more things than fixing.
>
> But yeah a "mimebody" ruletype would probably be useful..

Would you explain a bit further? Until such a ruletype exists, how do
you propose we solve this javascript issue? How do we search through
MIME attachments without using ExtractText?

Block the resulting URI in the javascript body? I was hoping for
something more generic.

I realize blocking all javascript is prone to error, but what about
blocking all "location.href" attempts? Or "document.write"?

Am I really the only one seeing these attacks?