Hi All
An interesting phishing attack using blank images within Docusign:
Regards
Caute_Cautim
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.
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.
@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.
@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.