Advice: Security of VBA project

[Ken Puls]

Hi everyone,

I'm perfectly aware that Excel is not a secure development plaform, but have a question about VBProject security.

How easy is it to break VBProject security? I have a workbook with a workbook open password to keep it secure from non-authorized individuals, but recently was informed of an advanced user in our system. I've never had to set project level security, as most people don't know how to get into the VB Editor, let alone go further.

Basically, what I'm after is to just lock the project down to keep in from being modified without my approval, but I'm curious to know if it can easily be hacked. (It's set with "lock project for viewing" and a password.)

I know that worksheet level security can easily be broken by brute force, but project security I'm not sure about.

Any insight would be appreciated.

[Zack Barresse]

Hey Ken,

As far as my (limited) knowledge goes, you can't break the VBA Project Password w/o some kind of third party program. Do you have a file you want tested?

[Ken Puls]

Hi Zack,

I could probably come up with one...

[Jacob Hilderbrand]

The problem is that the VBA Project is not excrypted when it is locked, just the password is encrypted. So replace the encrypted password with another encrpted password (that you know the password key for) and you have access.

[Ken Puls]

Okay, now that is interesting...

So the chance of someone uncovering the password is pretty slim then, but they can overwrite it with their own? It'll make it pretty obvious if it happens then, I guess.

I'm guessing that you need some more advanced knowledge than I've picked up so far, though, as everything password related in VBIDE seems to be read only...

EDIT: I'm not asking how to do this, mearly trying to figure out how easy it is to track down the code if someone were a malicious user.

[Zack Barresse]

So the chance of someone uncovering the password is pretty slim then,

Try slim to none. Without 'professional' software, it almost can't be done. The preferred method for 'hacking' a VBAProject password, along with any Excel passwrod really, lies in changing it w/o knowing it.

And yes, I could test it for you.

[Ken Puls]

All righty then...

Try this file. No workbook password, but does have a VBProject password. Only a msgbox in the module. What does it say?

[Zack Barresse]

Option Explicit

Private Sub sectest()
MsgBox "This is a test procedure with no value!", vbOKOnly, "testing!"
End Sub

They are not that hard, unfortunately.

[Ken Puls]

No kiddin!

Okay, so did you use a VBA procedure to unlock it?

[Zack Barresse]

No.

[Anne Troy]

Guys....do we want to leave this in the open discussion area? Just wondering. Zack: I'm gonna let it be your call.

[XL-Dennis]

Hi all,

I find it unethical to discuss issues like this in public.

Kind regards,
Dennis

[Jacob Hilderbrand]

I don't see any problem with discussing security issues in generalities. Especially if people want to know how secure their programs really are.

So long as we discuss it as we are without providing step by step instructions, I don't see the problem.

[CBrine]

Whether it's discussed here, or someone does a google search and finds any one of the 1000's of hacker sites that discuss issues like this doesn't really matter? I for one would rather have a legitimate site, with trusted content to be able to discuss these types of issues on. It's good to know that even the VBE password can be hacked, which just reinforces the issue of Excel not being a secure environment. Though to be honest, there's not a lot of users of DRJ's caliber running around, thank God(or your choice of Deity). I know I couldn't have bypassed the VBE password without a ton of research.

Cal

[Zack Barresse]

Thanks Anne/Dennis/Calvin,

I find it borderline. It could go one way or the other. I'm going to edit the thread, not delete it. I do find it good information as I think *most* of the populous will. The methods used will not be public material. If there is anything that is still borderline after editing, please let me know via private message.

Thanks all for you input!

[Zack Barresse]

A few words from mvidas:

As discussed, VBAProject security is not secure at all. 3rd party 'professional' software is not needed. If the creator truly believes that their methods are one-of-a-kind and should not be seen by anyone, it should not be made in excel or vba.

However, as far as creating routines in VBA and protecting the vba project, I honestly feel that anyone who is determined enough to break that protection can probably write the same code themselves and that should not be a deterrant for releasing anything written in vba.

[Zack Barresse]

A few words from kpuls:


I?ve asked Zack to share my opinions on the ethical question, as the thread was locked before I had the chance. First off, though, I do want to say that I agree that the thread, in its original form, was pushing over into the darker side of ethical boundaries.

I want to make clear that my intention for this post was never to leave a ?how to? trail, and I?m glad that all references to the methods used have been removed, as I feel that it brings this post back into the acceptable realm of discussion.

What I was trying to prove (to myself), was how easy or difficult it would be for a malicious, somewhat skilled user to source out the method to crack my vbProject security. Keeping in mind that I dealt with people who both knew and trusted my intentions. It also became apparent that someone who knows what they?re doing, can do it.

For my situation, I have come to the conclusion that if I have a user in my network with both the skills and intent to plan and implement this kind of breach, my spreadsheets are probably the last things I have to worry about. A user of this class will most certainly attempt to deliver a far more devastating payload than attacking our Excel files.

I do feel, however, that this post illustrates how easy it is to compromise Excel?s security. Yes, this spells out, in black and white, just how vulnerable Excel is, but as developers, I feel we have both the right and need to know.

If anyone has any comments on this at all, please feel free to PM me to discuss.

[Anne Troy]

I'm going to open this thread back up for discussion purposes. I see no reason we can't discuss the issue. I like what's being said.

This is a pretty touchy subject to some, and others feel completely different about it. Since the *hack info* was removed, I think it's cool if we continue the discussion.

Great stuff, guys! Great job, Zack!

[XL-Dennis]

It's good to make users aware of the weak protection Excel have. The reason for it as well this is the price, is that Excel and many other end-users softwares are so called open systems/softwares.

Instead of trying to improve the present protection abilities I strongly believe we need to take an another stand on the issue.

Nowadays I rarely protect workbooks instead I solve it by using other possibilities including signing contracts with clients to assure that the solutions are intact. This could easily be transferred to internal solutions as well, i e agreements within the department and/or between departments. The benefit is that the users can take part of the solution and perhaps learn one or more thing. Another advantage may be that clients can, to some degree, do the maintance by themselves.

For larger projects a better approach, both when it comes to protection as well as performance, is to separate code from interface, user-data etc. The code is compiled into COM add-ins. By using this approach the maintance can easily be done.

Sometimes this approach is not acceptable or not wanted for one or more reasons and then I just leave the solution unprotected, especially if the solutions have been installed on many end-users computers and contracts have been applied.

And I agree that if someone would like to take a closer look into a secret they can do it no matter how much protection we add, i e if You want to keep things secret then a good start is to not use a computer.

[Ken Puls]

Hi Dennis,

I am a firm believer in leaving my Excel workbooks open to modification when it makes sense to do so. For the most part, I protect worksheets with no password, and let my users know this. The purpose is not to lock the file down at all, but rather to make sure that they don't do something nasty by accident. I do try to make sure that if they need to be able to change something, that they can. I also encourage my users to learn about Excel so that I'm not the only one in my organization to support the workbooks.

Unfortunately, however, there are times when protection is necessary, as honesty is just not a human trait that we can always rely on. In this case, the spreadsheet is a vital link between many of our point of sales systems and our general ledger. I know that sounds bad, but we have 4 legacy POS systems and a G/L which do not support any kind of interfacing technology except human hands! Excel can at least be used to create a journal entry in an acceptable format to import (manually) into our G/L. If I lose this spreadsheet, it will affect not only myself, but a few others in the organization. If we had the funds, this spreadsheet would not even be necessary, as we would have installed a fully integrated property management system, but unfortunately we're not there yet.

I do understand where you're coming from, but I, for one, do feel that protection abilities should be increased for this product. Excel has been pushed out to the business community for a long time, and is used the world over for purposes exactly like mine. I am also certain that many others also share my concerns.

I don't believe that anything out there is, or ever will be completely unhackable. I do think, however, that it should be a little more difficult than it currently is.

I am going to have to do some research on the COM add-in. That sounds very interesting to me...