Relatedly, I was recently horrified to learn that not only will Excel (and LibreOffice Calc) automatically parse formulas in plain CSV files, but there is also a formula that will _run external programs_.
Yep. To add insult to injury, for many years there either wasn’t a setting to disable loading of external programs or doing so required a subscription of some kind to a MS enterprise license/endpoint/policy management feature.
I'm skeptical that Excel does this without prompting. Microsoft takes these kinds of vulnerabilities—opening a data file causing ACE—seriously. Do you have more information?
> Microsoft takes these kinds of vulnerabilities (...) seriously.
Sorry, CVE database disagrees with you when looking at the statistics of how often RCE macro loopholes are found in embedded VBA APIs inside spreadsheets.
From those 439 around ~350 are _remote_ execution exploits with their own CVE ID, meaning another VBA API or programming paradigm was affected and downloaded and executed code remotely without the user noticing.
I'd argue that "taking this seriously" is the opposite of the sheer amount of those CVE IDs.
And these are only the vulnerabilities we publicly know of, there are far worse VBA exploits being traded on dark markets.
The reason why Microsoft took so long to deprecate these VBA APIs is that large enterprise-grade organizations do almost everything in Excel. From querying a database server to storing a financial report remotely on a mounted net share drive to even including another external file for the inclusion of modules or methods. It really makes you wannacry.
> Sorry, CVE database disagrees with you when looking at the statistics of how often RCE macro loopholes are found in embedded VBA APIs inside spreadsheets.
Sure, but there's a difference between having a large codebase to cover and what is being discussed above. Nothing you've said is contrary to GP.
I am willing to counter any bet that Excel formulas will open an external program without prompting.
> around ~350 are _remote_ execution exploits with their own CVE ID, meaning another VBA API or programming paradigm was affected and downloaded and executed code remotely without the user noticing
Exploits and macros are orthogonal. Macros don't require exploits to run, and I've never seen an exploit bother running a macro. It already owns the process at that point. It can do anything it wants.
> The reason why Microsoft took so long to deprecate these VBA APIs
Microsoft isn't deprecating anything, just disabling macros for files with ZoneId=3. This won't be a particularly effective change in the near term given the practical realities of how people work*, but it's long overdue.
* Roughly what will happen at mid-sized+ companies: 1) New feature is enabled. 2) New feature breaks a bunch of existing workflows. 3) IT is flooded with tickets. 4) New feature is disabled with plans to redeploy with exceptions for finance and other teams whose workflows were broken. 5) Everyone gets busy with other projects and new feature is never revisited.
I wouldn't call it serious, more like indifference. Microsoft has been watching viruses and malware spread by emailed office files for 25+ years. They listen to their users when users want insecure features, and are fanatically committed to only incrmeental changes and backward compatibility - like they do in their other products. Some of this of course is the field of industry called anti-virus software, where glorified blacklists of previosuly observed harmful files are dressed in security theater costumes and MS users are guilted into paying various large costs for them.
This bit of news shows that there are people at MS who takes the vulnerabilities seriously as well, but they very rarely have the influence to effect change if it's weighted against anything else.
It prompts about enabling macros, generally. I haven't tested in the most recent versions of Excel but we see this about once a year at clients. You can test it yourself by with a test CSV like:
I just tried that CSV in Excel for Windows and it gave two warnings about it being insecure, had the disabled button default each time, and even 'enable' each time it still didn't run that cell.
I've come to the conclusion that absolute security is a fool's game, sort of like never getting sick. You have a Turing machine, you have a tape, it's not going to be secure. It's better to invest in research on an adversarial "immune system", so to speak.
This is absolutely correct! Modern technical security practice preaches defense-in-depth. Over a long enough period of time, you WILL be compromised. It’s much more effective to plan for it and mitigate the damage than it is to attempt perfect security.
The trick is to make sure you have good network segmentation, don’t allow apps/users more access than they need, and have reliable monitoring and anomaly detection in place so you can respond rapidly to breaches that do occur.
The only problem with that take is that people will hear it and remember “don’t attempt security because it’s hopeless”. It’s the same problem that comes from people discussing premature optimization and using it as a reason to skip simple and obvious performance improvements.
Nuance has a way of being lost in advice like that.
Like many things, it's about how far into the diminishing returns you want to go. At some point it's more effective to apply further investment to other parts of the ecosystem.
My own conclusion for the security of a small business was to set up a honeypot - a virus needs to search for vulnerabilities to transmit itself, and that search can be detected. Any virus that doesn’t search for vulnerabilities is much more benign.
That might be how worms work, but it’s not going to protect someone from installing a keylogger or a RAT from opening an infected Excel spreadsheet in an email, for example.
That’s much more reactive than proactive either way. Better as a secondary measure for a large business than as a primary measure for a small business.
Wait until you learn Windows has a default file handler for JavaScript (wscript.exe), which can execute external applications, write files and much more.
That's not the right move. The right move would be a sandbox around every word/excel file being viewed/opened. Ideally, backed by a kernel mechanics such as CreateRestrictedToken WinAPI.
What they are doing instead, shifting responsibility to end users. Specifically, they're simply training users to click on "I agree" buttons.
> they're simply training users to click on "I agree" buttons
Are macros at all common? My perception is they're very very rarely used, especially in file downloaded from the internet. In that context, a file asking for permission to run macros would seem pretty strange to the user and that they might actual reconsider things before clicking I agree.
They're pretty rare in files from the internet, but normal people don't really regard "files from the internet" and "this attachment of an email" as separate concepts.
In traditional business (like banking, where I have my experience) macros are EXTREMELY common. Both in local files, and in what normal users would consider remote files (from intranet sites and email).
The prompt to enable macros is near identical to the "protected mode" prompt, that users must click in order to do things like "print" and "copy to clipboard". No user ever questions it.
To answer your question though, pretty much every place I've worked with had people writing VBA macros.
Wrong. They are the number one security problem for email in traditional business, state and semi-state sectors. Certainly in my corner of Europe.
I always ask orgs to consider a blanket ban on them but almost none can go that far. They are extremely widely used and shared among healthcare, pharmaceutical, government councils and many other types of organisations.
If you sandboxed enough to prevent bad things, you would break the functionality of good things. If people were not using these features then they would not exist.
"The right move" would be for them to do away with programmable documents altogether, and replace them with a simple scripting language that reads and generates documents, similar to how static HTML is generated by template languages.
That way, it would be clear for users that they are not "opening a document" but "execute a program".
There simply is no need to conflate documents and programs.
I think you’re right. Fifteen years ago would have been the right time to disable macros by default. Now, we have the technology to sandbox everything to largely mitigate security concerns.
However, sandboxing is a much higher investment from MS’ POV. This feels like they’re making this move specifically to distract from the fact that they should have made the tech investment into sandboxing today.
I don’t think any platform, either Linux or Windows, has successfully implemented secure sandboxing aside from true virtualization, if that. The isolation provided by kernel-level sandboxing like cgroups has proven to be a thin layer of protection in practice; it will just shift the problem to fixing sandboxing issues.
> "This feels like they’re making this move specifically to distract from the fact that they should have made the tech investment into sandboxing today."
In summary, each successive version of Office actually walked back the tone of the warning if you tried to enable macros. Office 2000 was still more strict than what we'll have after this change. Office 2010 reduced it to the one yellow bar and a single click enable.
Edit: For those reading, this has been for a while something of an embarrassment. The creator of mimikatz only just made this callout in response to Microsoft's security advertising:
The change means there won't be a prompt within the open word document to enable the macro at all. You would need to exit word and change the document properties.
For all intents and purposes, macros are enabled by default. Yes, there's a simple "Click to enable" prompt. Everyone looks at it as "the button you need to click to load the document". People do it without even realising because it's so benign looking.
Look at the Word document in this campaign, which is just one example of many:
I can only relate to the experience of sending out phishing tests that rely on users clicking "enable". Either the business has it disabled by a policy, or the success rate will be close to 100%.
I'm reading it as it being disabled beyond a confirmation modal. You probably have to change some file attribute to re-enable it, perhaps.
Edit: Yep, from the linked article inside the article -
"Once a user opens an attachment or downloads from the internet an untrusted Office file containing macros, a message bar displays a Security Risk that the file contains Visual Basic for Applications (VBA) macros obtained from the internet with a Learn More button.
The Learn More button goes to an article for end users and information workers that contains information about the security risk of bad actors using macros, safe practices to prevent phishing & malware, and instructions on how to enable these macros by saving the file and removing the Mark of the Web (MOTW)."
> Attackers have already had to adapt to tricking users into affirmatively running macros, but the new moratorium means targets would have to carry out a much more involved process to be infected—making it much less likely that attackers will be able to successfully guide them through it.
I didn't see a description of the new process, but it sounds like they beefed it up some.
Right click on the file, click properties, click "unblock". Or use the Powershell command "Unblock-File". Close and reopen. it's not actually a new process, it's just a changed default. Some businesses set that default years ago.
>How does this article reconcile with the existing disabled by default practice?
AFAIK it's usually combined with some sort of social engineering attack to get the user to bypass the warning. eg. "this document is password protected by Adobe Protect™ to view document, click enable macros".
After re-reading, it sounds like there's an additional "are you sure" flag if the file came from outside your organization.
My point is that macros are already disabled by default. If you're going to get phished or engineered, then adding more "are you sure" prompts is of questionable value, without trying to sound overly cynical about InfoSec.
Bottom line: if the "feature" is not explained in a straight-forward way to a tech-savvy crowd like HN, then I have a lot of questions about its efficacy.
Macros are less commonly used as an attack vector for initial access nowadays. Sure they’ll make it harder for macros, but still is possible to run a one-click attack by attaching a js, jse, hta, paf, ws, wsf, scr, etc. to an email.
Huh. My work computers have always disabled macros, regardless of the file source. I guess this was a corporate configuration that's just now becoming default in the consumer versions.
They say: "Windows marks files you download with a metadata attribute known as “Mark of the Web” or “zone.identifier.”". Where is this metadata written and at which point?
Does adding this metadata messes up checksum or digital signature?
>Where is this metadata written and at which point?
NTFS alternate data stream.
It's the responsibility of the software that created the file to populate such a stream. Common browsers do so for downloaded files. Something like `curl` probably doesn't (I don't have Windows to check).
>Does adding this metadata messes up checksum or digital signature?
ADS contents are not considered when checking the signature.
I don't know how it works on Windows, but there is equivalent metadata for Internet-downloaded files on macOS. It's stored in the filesystem extended attributes of the file (see getxattr(3)) and generally does not break digital signatures (including the macOS binary code signatures).
First of all, are outlook attachments even maked as internet zone? Ok, let's say they are. What if they are in a zip file? With exe's you have to click a few times through a warning dialog to run them when downloaded from the internet, but guess what... not if you stuff them in an ISO. Works reliably too.
Ok, let's say they are disablng macros by default... is it just the orgs I worked at that set this as a default? Because I thought you had to enable editing and then enable macros each time? From a corporate security perspective, an office document with a malicious macros almost never gets past email security appliances.
There are two things true about a significant portion of the user population (even most seasoned security folks and myself as well having had to work in this specific are 5+ years): 1) Users will download untrusted files and open them 2) A much lesser but significant number of users will click through any number of warnings and obstacles to get content to work because at that point to them it is trusted content. It isn't phishing, Bob at so and so company who they work with regularly sent this important document (little do they know, Bob's account is pwned)
Already, you have to work very hard and target a large enough population for the law of averages to work in your favor ad an attacker. Defender had gotten really good even with just the default setting (and much much more with cloud submission) at behavioral detections as well in this area. Majority of succesful compromises I've responded to or read about with office docs have also been Excel 4.0 macros not vba Macros as well.
Here is a thing about modern O365: it's very web centric. Very common to open office docs in the browser office app or with a layer of OneDrive or SharePoint prior. You know what reliably gets past the most hardened email security appliances and tricks majority of users? Put your content in a zip or iso (preferably encrypt it and send the code in the email because it is all so important and confidential) and put it in onedrive or sharepoint and share it with a small but significant population (per compromised or staged+verified account), they will get a very convincing email from O365.
If I had to really stick to vba macros for some reason and users can't enable macros no matter what, I will just include a very convincing image based instructions on how they should add c:\ or something as a trusted folder (4-5 clicks though). Oh, that's disabled too? Here is a neat trick attackers have been using recently: the file in a zip/rar contains a Zone.Identifier ADS stream that marks it as from a trusted zone. As far as I know, this only works because zone.identifier marking from embedded content isn't overriden or checked strictly.
At the end of the day, macros are very useful and powerful. They are even adding python macros in the future. For the same reason you can unblock exe's and even powershell scripts from the internet, macros will be unblockable too and users will unblock even with multiple layers of obstacles. Remember, the legitimacy of the document is beyond question to users at that point.
When I interview users post-incident, they have no idea what happened. They did not get any suspicious email or oprn questionable document. When they are willing, I have had to get them to share their screen and go through their inbox on the day of the compromise (for personal email since it isn't monitored) or just tell them the subject and pull it up to which they are adamant that is a legitimate email.
Also remeber this: the goal id not to infect most users (they would like that though) but to get a foothold on at least one device. The atrackers that send this type of content are experts at delivery and execution, usually not a lot more beyond that (except maybe still information, persist and tamper with defender). Their main goal is to sell access to another party who would use another malware (cobaltstrike is popular but less so these days) to perform manual hacking and lateral movement. It is usually 6-72hrs before the real bad guys show up.
One more thing: SEO optimization and plain ol jscript seems to be working reliably, groups like ReEvil had switched to that last year.
In summary: this is welcome improvement but the game of cat and mouse must go on. Meet the new security, same as the old security. There are threat actors that mail malicious USB drives with teddy bears, just like security evolves so will attacks.
I only dabble with red-team stuff but even then the initial access primitives that work reliably a few months ago are useless now(RIP mshta+js). Red-teams that have to get initial access keep this a secret protected by NDA for that reason.
If Microsoft really wants to be a game changer, they should open up a lot more security controls to all their users not just E5 license holders.
This was tested on a few Twitter threads, the confirmation being yes, .zip files and even .iso files will retain the mark of the web confirming they were downloaded.
The special case is where 7-zip is used, which doesn't respect that marker. How many businesses actually deploy that globally? Well this same thread on Reddit resulted on several "oh, but I deployed 7-zip across the enterprise" answers.
And yes, every single org I've walked into to talk about security, my very first discussion has been about macros because they've been globally enabled in every business I've walked into.
Not an entirely good thing with 7zip. Let's say they download a malicious program from the internet and want to share with their colleagues, email policy will block that so they will zip it up. Now their unsuspecting recipients will not get a warning about the embedded file's origins.
Also, I love the fact that zone.identifier also embeds the referrer URL for the download.
Honestly, I wonder if VBA's most effective security feature has been its bad reputation. There's so much access to inexplicably vast swaths of the Windows ecosystem, combined with a nearly perfect consensus of users who have no idea what a macro is, that it's kind of surprising that VBA hacking isn't more ubiquitous. Security through obscurity via popular loathing?
I made an ‘Execel App’, using power query to connect to web data sources and VBA to interact with the local OS and file system, what I was able to accomplish, in my mind was amazing. I hate that these changes are necessary for security because how easy VBA is to learn and how powerful it is, it is sad to say goodbye to.
VBA viruses were quite prevalent for a while, though mostly primitive. The mitigation strategies put in place were not perfect but they were effective enough to move malicious actors towards more attractive vectors.
