Excel and VBA - a great combination - should be more widely used. I would expect all firewalls to quarantine office documents with attached VBA. I would expect all group policies to set the security level so macros aren't allowed automatically. I would expect the risks of macros to be included in security training. Sad that this isn't the case.
The dangers of allowing Office macros have been underlined by a newly discovered attack against European and Israeli companies. Malicious Office macros were used as the launchpad of the so-called RocketKitten attacks presented at this year's Chaos Communication Congress hacking conference (stream here, relevant material starts …
Wednesday 31st December 2014 12:41 GMT Peter2
Wednesday 31st December 2014 16:49 GMT xyz
Yeah, I wrote an app(lication) that did this back in 2008. IIRC it was a bit of a 'mare because of the different ways each MS app (Word, Excel, Visio, Access, etc) handled things. Anyhoo, the upshot was that the users kept their beloved macros and the sysAdmins kept their hair. Suppose I should have marketed the thing.
Wednesday 31st December 2014 13:22 GMT Destroy All Monsters
Excel and VBA - a great combination - should be more widely used.
Excel: A bad idea, implemented badly. A dataflow program presented in a way that resembles a 2-D sheets for beancounters. Unmaintainable. Can't even compute correctly in the best of cases (uses floats instead of the appropriate fixed-point arithmetic). Stats show that most of the Excel sheets out there have errors that go unnoticed. Cancer.
VBA: Acceptable, but people with no training use this, resulting in overcooked macaroni and more cancer.
Wednesday 31st December 2014 17:18 GMT serendipity
B*llocks!! For starters, we all know that translating binary to decimal and back has inherent limitations. That's just a fact of life. That doesn't mean spreadsheets aren't useful, they've been used successfully for years. But every tool has its limitations, you wouldn't use an F1 car for rallying would you? Yes some mis-guided users have tried to over reach the limits of Excel, but that doesn't mean it's not a useful tool for data analysis. And adding automation via VBA can enhance a solution if used sensibly. I mean plenty of stupid apps have been created for iOS, it doesn't mean per se that creating apps is bad per se (evil yes, as it's supporting Apple ;-). Baby and bath water come to mind here!!
Thursday 1st January 2015 04:57 GMT david 12
Wednesday 31st December 2014 12:34 GMT Tezfair
"newly discovered attack" ??????
I have been waging a battle with word and excel attachments for around 3~4 months. Almost daily I will get a client asking me to check if it's legit or not.
Problem for Anti Virus is that VBA isn't something that can be checked (at least on my one), so I have to rely on bad spelling or the RBLs snare it.
Wednesday 31st December 2014 12:57 GMT Peter2
Re: "newly discovered attack" ??????
This seems to be the only solution to macros and PDF exploits that exists, but it's a good one.
Basically, it detects if there is any embedded active content in pretty much any format (including extracting and scanning files embedded in zip files!), and it has options to remove any said active content.
The standalone version is excellent and in tests of the stuff that makes it through to the quarentine mailbox it has proven excellent, but I can't see a hugely easy way of implementing it in an exchange environment given it's a python script. The only way I can think of to implement it is via other third party programs such as XWall.
Wednesday 31st December 2014 13:17 GMT linicks
Re: "newly discovered attack" ??????
LibreOffice has a security setting to NOT run macros unless you agree. Then this becomes a user issue, not a security issue.
But as we know, certain people, no matter how intelligent, end up with the brain of a chimp when sitting at the keyboard (no offence to chimps).
Wednesday 31st December 2014 13:47 GMT Peter2
Friday 2nd January 2015 05:49 GMT Robert Helpmann??
Re: "newly discovered attack" ??????
Then this becomes a user issue, not a security issue.
How are these mutually exclusive, other than for the assignation of blame? Of course the solution proposed in the article to limit who can use macros to those who have training, et cetera, poses its own inherent problems. Training would need to be made, given and maintained; an additional user group would have to be maintained (a non-trivial effort even in small companies); there would need to be real and meaningful efforts to enforce the restriction (it's easy to say "enforce by GPO" but that can sometimes have unexpected consequences) and to monitor those who are legitimately allowed to use them.
Barring not allowing macros at all (my preferred solution), it would be best to allow macros to run only on an air-gapped network with new macros only allowed on after being reviewed by someone qualified to check for malicious intent... after a suitably long waiting period. I am only half-joking.
Friday 2nd January 2015 14:31 GMT Captain Scarlet
Re: "newly discovered attack" ??????
Yes but becomes annoying for users who use VBA enabled Office docs on a regular basis.
I've simply nicked a bit of VBA code so it will add our managed folders and stop flagging them as I we do want users to have to give permission to run code from files which aren't in our managed folders (Although they would probably run it anyway and then complain).
Wednesday 31st December 2014 13:09 GMT linicks
This is so 90's
Crikey - these dodgy macro files were rampant in the late 90's - I can't believe it's still a problem.
I remember one that infected the normal.dot (or whatever it's called) and thus ending up self-replicating and infecting every document produced from the compromised machine (usually a sales rep's).
Wednesday 31st December 2014 14:05 GMT Anonymous Coward
Excel "safe" macros
One way to reduce the risks of unintended Excel VBA activation is to put the macros in their own workbook without any data. When loading that file the user will know to expect the "Enable macros" prompt.
Data files would never be expected to raise that prompt - and a user will be less likely to get into a habit of hitting "Enable" as a reflex action.
The VBA can create Add-ins menus for the user to execute the programmed operations. It is a much cleaner way of using a standard set of VBA macros with many different instances of "dumb" data workbooks.
Wednesday 31st December 2014 14:38 GMT ShelLuser
Nah, there are much more options than that.
First the one I mentioned in my own post; simply disable the override option so that an end user cannot enable macro's if the document got opened from another location.
Then I remembered another, so easy I fully overlooked it: code signing. VBA programs can be code signed ever since Office 2008 (I think; 2010 for sure). So if you simply make sure that all your own macro code is signed (using an in-company certificate, you don't even need an officially recognized one) then all you have to do is make sure that the office environments will only run signed code.
Problem solved; now all the 3rd party macro code cannot be executed no matter what.
There are plenty of ways to secure your Office environment, the problem is that hardly anyone seems to use them (guess reading sites such as TechNet and MSDN is really old school ;)).
Wednesday 31st December 2014 15:59 GMT admiraljkb
> (guess reading sites such as TechNet and MSDN is really old school ;)).
You got that right. Both have excellent resources available and code snippets out the wazoo. It seems that a good chunk of current batch of 'Softies seem to be experts in "next, next, next, Finish". Unfortunately I've learned that the hard way with Sharepoint "experts" that didn't know anything about IIS and MS SQL. Their initial deployment was installed exactly as stated, and had to be completely demolished and re-done by old timers who knew how to configure old skool crap. The kids had no clue on web server farms and clustered SQL servers... Much of Corp Management is also convinced MS means "next, next, next, Finish", so trying to talk to them about configuration issues as you've mentioned is as productive as talking to a brick wall. What I would get back a lot of the time is "Its installed and working isn't it?" Ugh..
Which gets us into why Macros are still a problem ~20 years after the first attacks... I agree that Code signing is the solution, but invariably Finance will push back because it'll break some legacy spreadsheet from 1997 that the author has left the company 12 years ago, nobody understands how it works, and they're unwilling to even test. (and yes, I've had several very similar scenarios, very frustrating, and a reason why Excel 2003 was still required on a lot of machines rather than actually updating the sheets in question with modern code so as to be able to upgrade Office...)
Thursday 1st January 2015 23:56 GMT Mark 65
Code signing is the real work-around here as you can enforce a strict policy and allow essential use. The issue is that everywhere I have ever worked central IT has never allowed for code signing, will not set it up, and even if they did they would make you jump through unworkable hoops in order to get anything signed. Reap that which you sow.
Sunday 4th January 2015 09:05 GMT P. Lee
Re: Excel "safe" macros
The problem is VB doesn't have feature controls.
excel.exe -enable-vb=yes -VBOptions=noNetSockets -VBwriteFileAccess=false, domain=corporate.com
In fact, if its VB for Applications, network socket access should be off by default, file writing by VB should be off by default, reading files should be off by default except from a specified list or from the main application's, "File-Open" menu. These restrictions need to be noted when launching the parent application and enforced by the OS. The OS should flag if security options on an application have changed.
I've seen a lot of VB doing things like document formatting, corporate template generation. That means everyone must have it turned on.
Wednesday 31st December 2014 14:08 GMT Mikel
Wednesday 31st December 2014 14:23 GMT ShelLuser
"Visual Basic for Applications (VBA) is one of the easiest methods to deliver malware nasties: simply by dropping malicious code into an Office doc as a macro and attaching to an email. The victim would be lured by a plausible pretext into opening an Office file attachment delivered to them by email."
Nice theory but based on old Office technology. Microsoft was late to the party, sure, but they have been working on securing their macro environment. First the differentiation between documents with macro's and those without (.doc vs .docx and .docm (document using macros) extension).
But most of all: Secure locations.
When I open an e-mail attachment which contains a weird macro then so what? Because Office will open the document with macro execution disabled, because it got opened from an insecure location.
By default only the standard location for Office documents is trusted, and those are not the places where downloaded documents or e-mail attachments will end up in.
The only way where this will go wrong is if the user is still tempted to click the button next to the big warning: "Macro execution has been disabled, click here if you want to enable it.". And even then it won't execute fully.
This has been the case since Office 2010 (which is no longer supported even), and I think it may even have been part of 2008 as well.
“Office macro exploits are just about the only cool thing that Visual Basic gets used for any more,” he added.
Then this guy is completely ignorant of what you can actually do with VB or Office macro's.
My whole company administration is automated through VBA. All handwritten but the best part is that I could easily "tie" the components together. Example: I store a lot of customer data in Outlook, its for keeping appointments, e-mails, etc. So; if I have an appointment I can quickly check the address if needed.
So what happens when I need to send 'm a bill or letter? Simple! My Word macro opens the Outlook contact database, checks for the customer name and then retrieves the right data and adds it to my template. Last time I manually typed a customer address in Word is 3 - 4 years ago.
Document references.. You don't think I'm making those up myself do you? That's what my "Private Function RefGen(naam As String) As String" function is for.
Note that I'm not saying that there is no risk at all, but I do think it's hardly as extreme as this guy wants us to believe. For starters he's ignoring the issue that the end user once again needs to click on a button which has a big bold warning next to it.
The solution is a group policy to only allow certain people to run macro's? Uh huh. I'd personally opt to disable the "run macro anyway" override option which is also doable. Through a policy or, for example, by using a VBA macro which gets automatically started when Office starts.
Wednesday 31st December 2014 14:42 GMT hplasm
Wednesday 31st December 2014 17:02 GMT serendipity
But because it's Microsoft and VB you automatically think it's uncool even though you probably know f*ckall about it!
Wednesday 31st December 2014 15:16 GMT linicks
Re: Bullshit - and the real world
But what happens is all the users complain about jumping through hoops to get their stuff to work, so all complain to pointy haired boss who then orders the IT department to turn it all off of so the sales guys can do their work faster...
This is a user issue, combined with the MS psychology of letting people be able to use computers without thinking even if they shouldn't be allowed anywhere near a computer. .
Wednesday 31st December 2014 16:00 GMT A Known Coward
I could build an entire office out of Lego, that doesn't mean it's the right tool for the job.
The fact is that the sorts of basic actions you describe above should not require scripting of any kind. Additionally macros should be restricted to pulling in information from a well designed, restricted APIs, not the apparently unfettered access they currently have to systems. It was criminally bad design by Microsoft, apparently unable or unwilling to create applications which simply worked together the way they ought to, they decided to give their customers the components and told them that "building it yourself" was a virtue and not an abject failure on their part.
VB is a loaded handgun painted in primary colours with the trigger labelled "Pull me!" . It's aimed at precisely those people who aren't capable of using anything more sophisticated and who therefore should never, ever have be allowed such power in the first place.
Wednesday 31st December 2014 17:09 GMT serendipity
What drivel !!
I think MS missed a trick, they should of added, say Python, as the scripting language, then all the cool Open Source types (who usually have closed source MacBooks, oh the irony) would have thought it was all wonderful, even if Python is the VB!
Wednesday 31st December 2014 17:46 GMT A Known Coward
"Office's extensive functionality can't possibly cover all scenarios."
Not even something like pulling contact details from Outlook into a document without a VB macro, as per the OP?
Really? You did read the original poster, didn't you, or were you too busy looking for anything remotely critical of the one thing you know how to do?*
Office doesn't have to cover all scenarios, 99% of tasks which are currently attempted using VB Macros are just as basic as those listed by the OP. The rest should be left to those who know what they are doing, with the proper tools and not a language programmed through a WYSIWYG editor. (Yes, you can hand code VB, that's not the point).
* Yes, we've noticed how often you only reply to leap to the defence of VB, .Net and Microsoft in general. Your one man battle against the 'evil' conspiracy by those nasty open source types. Wait ... who first mentioned open source in this thread?
Wednesday 31st December 2014 17:10 GMT serendipity
Wednesday 31st December 2014 22:51 GMT Roland6
"It’s often the finance department that relies on macros - ah yes, the department that has access to the company bank accounts and makes the ideal target for banking credential theft. The average user simply doesn't need them, so this isn’t going to cause much inconvenience,”
Like the security approach, don't protect the machines in the one department that actually needs strong security against accidental user in-attention...
Obviously Ken Munro, hasn't seen an unfiltered inbox - in both mine and a client's we have seen a large number of emails with attached 'invoices'/'purchase orders'...
Thursday 1st January 2015 15:40 GMT AOD
Reg sub editor not yet recovered from Xmas excesses?
The headline wittering on about VBScript misses one small but rather salient point.
VBScript is not VBA.
The two may be closely related but they are distinct. VBScript is a lightweight scripting language, VBA is a programming language embedded within an MS Office app such as Excel, Word, Access.
Although they share a lot of similarities (reserved words, flow control mechanisms) they are not the same thing. For example, in VBScript, all variables are treated as Variant, whereas in VBA (and VB) they can be strongly typed (eg String, Integer etc).
Friday 2nd January 2015 11:08 GMT Anonymous Coward