cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Caute_cautim
Community Champion

Blank images in Docusign

Hi All

 

An interesting phishing attack using blank images within Docusign:

 

https://www.bleepingcomputer.com/news/security/new-blank-image-attack-hides-phishing-scripts-in-svg-...

 

Regards

 

Caute_Cautim

4 Replies
JoePete
Advocate I

Once again, an attack facilitated by HTML email. To address this topic in inverse priority, HTML email is a poor choice from a usability standpoint - you have no assurance how such an email will be rendered by a recipient's email client. But from a security standpoint, HTML email has proven to be a continual threat. Yet, the uphill battle to educate people as to why sending HTML email is the equivalent of sneezing in someone's face and reading it is the equivalent of opening your mouth in such a situation while walking barefoot over used needles only steepens. 

denbesten
Community Champion

The article states "embedded JavaScript code" was the bit that enabled the attack.  Emailing executable content seems the much bigger risk than emailing formatted text and embedded images.  

 

HTML email is one of those things for which people's risk appetite varies.  And since the execs seem to lean towards "accept", I don't feel attempts to banish would succeed.  The thing we really need are better controls so that we can tune the risk to match our individual appetite.

 

Personally, I would like the client to strip out any tags allowing access to the local file system, the Internet, executable code, and JavaScript.   And it sounds like Joe would like to turn the knob a bit further, eliminating all HTML tags (except possibly <P>).

 

Even with plain text email one has no assurances how it will be displayed because the sender does not know the recipient's screen width.

 

 

JoePete
Advocate I


@denbesten wrote:

The article states "embedded JavaScript code" was the bit that enabled the attack.  Emailing executable content seems the much bigger risk than emailing formatted text and embedded images.  


The JavaScript seems to be embedded as part of an .svg that is in an HTML embed element. It seems a bit like a trojan, undoubtedly to avoid detection. My guess would be some (many?) email clients won't run the JavaScript. Those who read email in a full-blown web browser, though, might be most susceptible. I agree, stripping out scripting on the incoming (and outgoing) server would be a good idea, but this trick might circumvent typical filters (they see the SVG and let it pass through rather than actually decoding the Base64 and figuring out it's really a JavaScript).

 

 And it sounds like Joe would like to turn the knob a bit further, eliminating all HTML tags (except possibly <P>).

No, I'd take out <p> too 😉 But I like the idea of a knob. The problem is right now we have essentially plaintext or HTML, and not much in between.

denbesten
Community Champion


@JoePete wrote:
JavaScript seems to be embedded as part of an .svg

In attempt to keep the discussion focused, I did gloss over that particular detail but the concept remains.  Neither executable code nor filesystem/Internet access is needed for rendering a document (html,pdf) or an image (svg).  It does not seem like it would be much of a stretch for the fabled "knob" to apply to multiple file formats.

 

FWIW, SVG really is just an XML file.  In many respects, it is a "full featured" document description language, similar to PDF and HTML -- just with more of an "image" perspective.