Oh my Microsoft Word: Dridex hackers exploit unpatched flaw Cybercrooks are actively exploiting an unpatched Microsoft Word vulnerability to distribute the Dridex banking trojan, claim researchers. Booby-trapped emails designed to spread the cyber-pathogen have been sent to hundreds of thousands of recipients across numerous organisations, according to email security firm Proofpoint. …
"no sign of ANY Patch Tuesday releases, so far. . ."
HTH!
Which study after study as well as general experience demonstrates that they do dozens of times on a daily basis. Mostly as a result of actually having to do in order to do their jobs in most environments. You know what? I did it this morning. Had a quote in from a supplier, and I opened it.
Having a 100% onus on the user not to open the wrong document as 100% of your security policy is overly lazy and dangerous when even MS word comes with enough group policy options to make most potential threats more or less harmless, such as disabling Active X, Macros and file downloads etc which would prevent this attack using already existing and freely available options that can be enforced on your users centrally with about 2 minutes work, 90 seconds of which opening MMC and the group policy management console.
Received one of these today:
https://virustotal.com/en/file/380b47a8c82b06b1be1655253259d3935b20c439518e4e5ecec8b12551e969b2/analysis/1491999567/
It pretends to be some sort of document from RBS and asks you in the visible text to turn off protected mode. Not particularly convincing, but I guess it catches some numpties...
Really this is a trainwreck waiting to happen since before Win95.
Not a trainwreck waiting to happen, if this article is to be believed, a deliberate attempt to wreck trains:
The Achilles heel of web apps is their restricted permissions on the client machine. By design, any process that runs within a web browser does so with limited access permissions, as to minimize the execution of malicious code. Permission levels can be customized by the user, but they tend to be quite restrictive - especially where untrusted sources are concerned. By-and-large, read, write, and execute rights are not permitted. As web applications have gained popularity, several workarounds have been introduced by vendors. Bill Gates and company have a notable advantage over the competition because they also make the most popular operating system on the planet, that of course being Windows. It should then come as no surprise that they have introduced a means of writing web applications for Internet Explorer that can bypass the usual security restrictions.
[http://www.webreference.com/programming/HTA/index.html ]
So if the source is to be believed, hta was a deliberate development by MS to circumvent sensible security practices!
Given the findings of coconuthead ( https://forums.theregister.co.uk/forum/containing/3151574 )
and my researches across various generations of Windows and the various workarounds being suggested (see thread started by Peter2: https://forums.theregister.co.uk/forum/containing/3151096 ). I have on a (albeit small) pool of systems changed their default file association for application/hta & .hta to Notepad - also I've worked out how to configure my HIPS to both monitor for traffic containing "application/hta" and blocking attempts to execute mshta.exe (32 & 64 bit versions - flagged as malware, but not to be removed for the moment) as yet nothing has broken or been flagged.
So the question is who out there actually uses application/hta as part of their UX delivery - other than hackers. Because as far as I can see, like Flash, mshta.exe needs to be removed.
>So if the source is to be believed, hta was a deliberate development by MS to circumvent sensible security practices!
The incriminating evidence:
Why Use HTAs
Historically, programming languages like C++ and Microsoft Visual Basic have provided the object models and access to system resources that developers demand. With HTAs, Dynamic HTML (DHTML) with script can be added to that list. HTAs not only support everything a webpage does—namely HTML, Cascading Style Sheets (CSS), scripting languages, and behaviors—but also HTA–specific functionality. This added functionality provides control over user interface design and access to the client system. Moreover, run as trusted applications, HTAs are not subject to the same security constraints as webpages. As with any executable file, the user is asked once, before the HTA is downloaded, whether to save or run the application; if saved to the client machine, it simply runs on demand thereafter. The end result is that an HTA runs like any executable (.exe) file written in C++ or Visual Basic.
[https://msdn.microsoft.com/en-us/library/ms536496(v=vs.85).aspx ]
I have on a (albeit small) pool of systems changed their default file association for application/hta & .hta to Notepad
I don't honestly think that's actually an effective blocking method. If somebody is running an API from word then I would assume that you could simply execute mshta.exe with a command line argument to open the HTA file in which case having changed the windows default wouldn't do anything.
The appropriate blocking methods for the executable is basically denying the executable from running through group policy (which is built in to every version of windows as a free tool) to block it with either a Software Restriction Policy or an AppLocker policy.
Personally, I advocate using a software restriction policy with a default level of "disallowed", with allow rules for %program files%. As the users then can't run programs outside of program files, but can't write to that directory then they simply can't actually execute- I had this blocked already before taking any further precautions.
That said, never get complacent, don't rely on a single point of protection and keep reviewing what your doing when new threats pop up. On my network, this HTA threat was blocked in several different ways before this hit the news and is now blocked in six different ways before Microsoft even gets around to doing the patch. But then again, my companies relatively small size has unfortunately no relation to the level of effort miscreants put into emptying our bank accounts so I put equal effort into ensuring that the contents of our bank account stays where it is. So far I'm winning the contest quite decisively.
Peter2 - Agree, use of Policy is a better solution. I was simply implementing a quick trial on a bunch of non-domain systems to see if anything broke. Whilst the real solution is to remove mshta.exe, however, I suspect use of policy will be necessary to prevent execution and a possible future update (or system repair) accidentially re-enabling mshta.exe.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
