Excel macro testing

ssj100 wrote:I think the macro wasn't even loaded when the Excel document eventually opened (despite already changing the macro security level to "Medium").

That's right. Didier wrote the macro in VBA, while OOO tries to open it with BASIC and fails. Besides, OOO's Object model is quite different from Excel's. And as a rule, you have to go through a lot before you can open "foreign" macros in OOO, so you have plenty of time to think whether opening it at all is what you really want.

Paul

MS Office uses, what I call, "blame the victim" security. It asks the user to allow each macro based on whether they trust the source. While users can judge well whether their friend/family member is well-intentioned, it is difficult for non-technical users to judge whether their friend/family member has good security. When a user allows a malware macro because they trust the sender's intentions, Microsoft covers their ass by saying the choice was made by the user.

Comodo's HIPS essentially also has "blame the victim" security. When I used it in Paranoid Mode, it took months to fully train. My non-technical spouse adapted by allowing everything. When CIS introduced Clean PC Mode, training after installation was eliminated. But when I installed new software, pop-ups occasionally occurred, and my spouse still reacted by allowing everything. If we had ever been hit by real malware, Comodo's HIPS would be effectively useless. Complaints about this on the Comodo forum are met with smug blame of the user.

The strategy I now take with MS Office files depends on the setting. I used to work for a large company that standardized on MS Office. In that setting, I had to run MS Office and allow macros to make company documents work. If I still worked there, I would run MS Office in a Sandboxie sandbox with start/run access restrictions to block foreign executables like cmd.exe and regedit.exe. Sandboxie notifies the user about the failed execution, which is a clue that the file contains malware. No decisions are needed to achieve malware containment.

At home, nobody writes macros. I can't think of a legitimate reason for friends and family to forward MS Office files with macros to us. Since I have a non-technical spouse who would allow files from people with known-good intentions, my strategy at home is to block all MS Office macros. OpenOffice.org effectively does just that -- renders the content without the macros. No decisions, and its free.

A good security approach Binky! And as p2u has offered, Microsoft Office also provides the option to block all macros dead (default-deny).

And yes I agree that Sandboxie can provide a clue that a file may be malicious if it pops up a deny-execution box. However, this test shows that not all execution will be detected by such means - even Faronics Antiexecutable and Classical HIPS software were unable to differentiate the new executable code hidden inside "EXCEL.EXE". In fact, even Process Explorer was unable to display these new processes.

Anyway, nice to see another knowledgeable person converting to use Sandboxie - it makes me feel that I'm not delusional about the power of it haha.

Just caught this thread and admittedly I briefly checked it out. My thoughts:

Fairly low risk as long is it requires users to physically enable macros as they are disabled by default. That requirement would vastly limit the success of something like that in the wild.

You mentioned regedit.exe and cmd.exe as "foreign code", what makes them untrusted and foreign? Are they the standard windows binaries or have they been modified in some way?

Even though I would consider this a low risk issue, we will definitely look into it. The only other issue I've seen was the dll pathing issue, which isn't something that we could feasibly address. Software developers as well as Microsoft themselves need to address that issue. I wish we could be everywhere at once, still haven't figured out how to do that just yet. You can always drop us an email at support@bluepointsecurity.com for forums.bluepointsecurity.com, we take these things seriously and look at every single report of something like this. We also have to make a determination if something is feasible for us to address, which I think this could be addressed but we'll have to check it out.

Happy hunting!

Zero_One wrote:You mentioned regedit.exe and cmd.exe as "foreign code", what makes them untrusted and foreign? Are they the standard windows binaries or have they been modified in some way?

They are "foreign code" because they are built into the Macro. I think they are the standard windows binaries, but I can't tell for sure. The code could have been something malicious, but Didier Stevens isn't out there to "destroy" systems haha.

Zero_One wrote:The only other issue I've seen was the dll pathing issue, which isn't something that we could feasibly address. Software developers as well as Microsoft themselves need to address that issue.

This is actually the same kind of problem; not with dll's only, but with virtually any type of executables, mapped into memory. No, it's not funny to see how the system "bypasses itself", but this is not a bug, not a vulnerability; it's legitimate behavior. I'm afraid MS won't do anything about it, and although I'll keep my fingers crossed for you, I don't think you can solve this without breaking too much. A sandbox can contain it, but nobody can stop it.

Paul

That's the tough part about it, it is intended behavior. The fact that it in order for the attack to be successful the user would have to specifically enable this type of thing is important to note. Users can change all sorts of "turned off by default" behavior and open up themselves to all kinds of issues, where's the line? Macros are sort of a terrible idea in the first place, especially with the functionality that they do have.

What if someone dropped IE's security settings all to "Low", should a vendor step in and try to deal with that situation? This kind of thing is exactly why vendors sometimes choose not to resolve issues, just because there's an issue, it doesn't always demand a solution from a security vendor. Hence the massive "BYPASSED" forum titles can be a bit misleading.

Good points. However, I suppose one could interpret "BYPASSED" as a reminder to not forget to use the stuff between our ears haha. In the end, this is just as (or more) important as (than) the security software we use.

Zero_One wrote:What if someone dropped IE's security settings all to "Low"

Interesting point. And what do you do when a "Trusted" application changes such settings without the user's knowledge? I know lots of "Trusted" programs that make themselves search engines by default (mainly to make money with advertising and tracking deals), put those settings in obscure places (Opt-Out, of course), so that the average user won't notice and will unknowingly "agree", place their home addresses into IE's Trusted Zone, change the browser's home page (each "hit" counts, right?) and generally don't comply with the over-all security policy, thus actually weakening in-built system security features (advertising channels are continuously hijacked and compromised, and so are search engines; the "funny" thing is that you don't need an executable to do that). Not to speak of "schedulers" of all kinds. RealPlayer's TBell.exe, for example, its "tinkerbell", reporting to their site, updating their news, and executing other undocumented tasks). Even if you have opted out of everything and you remove it from startup with msconfig, it will be there next time and continue doing its thing. The only way to stop it is to rename it... Should one "throw this baby [with an impressive vulnerability history] out with the bath water" and "untrust" it completely, or could one simply remove its plugin and block the player complete access to the Internet with a firewall? (silent hint at an answer why outbound filtering with a firewall may not be so useless after all... )

Paul

Zero_One wrote:What if someone dropped IE's security settings all to "Low", should a vendor step in and try to deal with that situation? This kind of thing is exactly why vendors sometimes choose not to resolve issues, just because there's an issue, it doesn't always demand a solution from a security vendor. Hence the massive "BYPASSED" forum titles can be a bit misleading.

What if a piece of malware dropped IE's security settings all to "Low", should a good security program such as MBAM or SUPERAntispyware correct this?

Guys, was just reading Didier's latest blog post, and came across this:
http://blog.didierstevens.com/2010/03/09/frisky-solitaire-another-info-stealer/

It appears that he coded a trojan that runs purely in memory via an Excel Macro. Some key points from the blog post:

this made me realize that social engineering is a key element to get people to run macros from a spreadsheet of unknown origin.

I took Solitaire from ReactOS, turned it into a DLL and embedded it with my memory loading shellcode into Excel macros (the same technique as I developed for cmd.dll and regedit.dll).

Basically "cmd.dll" and "regedit.dll" are what I tested in this thread.

Frisky Solitaire is trojaned with an info stealer… No need to exploit a software vulnerability to steal info. Given that here too, everything is done in memory, detection is unlikely.

Obviously I don't know exactly what information this trojan steals or how it steals it. However, it's clear that one could safely run it sandboxed with Sandboxie (with appropriate "Blocked Access" restrictions, although I'm not sure if this is even required), play the entire game through, and then use the good "security approach" of terminating/deleting the sandbox before doing any eg. online banking. Keep in mind that with Sandboxie, the terminating/deleting of the contents can all be done automatically and with great convenience (unlike other programs).

Clearly arguments like OpenOffice.org not running the Macro is completely irrelevant here (which was one of my points earlier in this thread) - eg. the home user wants to run it, and there are a few ways for them to do it safely, thus maintaining their general "freedom" and "entertainment" options.

ssj, this is a good example of why an outbound firewall is useful.

Excel is trusted, allowed to run/open the dodgy spreadsheet.

The macro runs, maybe it steals information, but it can't do anything with that info if it can't access the web!

Stephen2 wrote:ssj, this is a good example of why an outbound firewall is useful.

Excel is trusted, allowed to run/open the dodgy spreadsheet.

The macro runs, maybe it steals information, but it can't do anything with that info if it can't access the web!

Why use an outbound firewall when I can open all newly introduced files in a sandbox which doesn't allow ANY internet access?

Don't get me wrong, on Windows Vista/7, I would certainly make use of the built-in firewall (for outbound control) mainly just because it's there. However, on Windows XP, there is simply no significant advantage (and potentially some disadvantages) of installing a third party firewall. Just my personal opinion that applies to my own security/setup approach (which uses Sandboxie quite heavily).

EDIT: by the way, tzuk may be implementing more configurable "firewall" features in Sandboxie for the next version:
http://www.sandboxie.com/phpbb/viewtopic.php?t=9627

ssj100 wrote:it's clear that one could safely run it sandboxed with Sandboxie (with appropriate "Blocked Access" restrictions, although I'm not sure if this is even required), play the entire game through, and then use the good "security approach" of terminating/deleting the sandbox before doing any eg. online banking.

OK. Let's say it can't do any harm within the sandbox. But now imagine this scenario:
The user (who doesn't know there's a Trojan in there) is stupid enough to download and launch this. He/she REALLY WANTS to run this game and it works as advertised (except for the info stealer part, of course). Is it plausible that the user will want to KEEP IT to play it a couple of times? In such a case he/she will most likely carry it out of the sandbox, right? The info stealer will go unnoticed anyway. So, in such a scenario, a DefaultDeny firewall for your real system *may* still prevent info leaks if your settings are right...

Paul

p2u wrote:OK. Let's say it can't do any harm within the sandbox. But now imagine this scenario:
The user (who doesn't know there's a Trojan in there) is stupid enough to download and launch this. He/she REALLY WANTS to run this game and it works as advertised (except for the info stealer part, of course). Is it plausible that the user will want to KEEP IT to play it a couple of times? In such a case he/she will most likely carry it out of the sandbox, right? The info stealer will go unnoticed anyway. So, in such a scenario, a DefaultDeny firewall for your real system *may* still prevent info leaks if your settings are right...

Yes, I never said the software firewall (outbound control) is useless for everyone. In fact, it can act as an additional layer of security, just like Antivirus software, Behaviour Blocking software, Anti-logging software etc. It's really up to the individual user to work out which layers work for them, and how many they want on their system. For myself, I use a sandboxing and "windows hardening" approach because I find it gives the best balance between usability and security.

Oh and by the way, it's not hard to keep a possibly "dodgy" program in the sandbox and keep launching it from there (retaining saved settings too). In fact, some people install and run their web browsers this way.

ssj100 wrote:[It's really up to the individual user to work out which layers work for them

That's right. The ultimate truth is that you *can't* really protect users from themselves. (In)security lies in the assumptions one makes, not in "super-secure" technology...

Paul