Breaking out of Jail with Microsoft Word

by patrick.ogenstad on October 4, 2006

“Can you really break out of jail with just Microsoft Word, or are you just pulling my leg?”

No I would never do that, Word is really powerful, it can take you places!

Intended audience

If you are a convicted felon and reading this from prison; sorry but you are not the target audience. However, don’t despair: there’s something in here for you too!

This article is for people who care about security. If you don’t fall into this second category you really are in the first group, i.e. not the intended audience. When I’m talking about “jail”, I’m referring to a restricted Windows environment. What I mean with this is a locked down Terminal Services session, or a public Windows XP box in “kiosk” mode.

Administrators who have locked down their terminal services sessions care about what the users can do on the machine. They only want users to run the programs that are approved by the security policy. This means no cmd.exe, no freecell and no poking around in the system.

So why isn’t this article for people who haven’t locked down their environments? Because of the good ol’ “Security is a Weakest Link Problem”, meaning if you haven’t even tried to lock down your environment, you have other issues to take care of before you read this article.

Operation Lockdown

For the environment that I have set up to test this, I’ve installed a Windows Server 2003 machine and set it up to run Terminal Services. I’ve also installed Office, the goal here is to only allow a user to run Microsoft Word and nothing else.
The user’s desktop is then redirected to a share where the user doesn’t have write access. The desktop contains one item; a link to Word. Logging in to the terminal server, everything looks good; the user can basically run Word and change his password.

Apart from the above setting the rest of the GPO settings are located at the end of this article. It’s basically a few lockdown settings and a software restriction policy defaulting to “disallowed”, with an additional path rule allowing Microsoft Word.

Given this configuration let’s see what we can do.

Where does Word enter into it?

I guess the title says it all; Yes, Word is the application we are going to use to break out of the locked down jail. If you’ve tried my SYDI project, you’ve probably realized that I like Office automation. This concept would work in any Office application but I have chosen Word. If you don’t have Office installed in your locked down environment, I still think you should continue reading. Hopefully you’ll enjoy the article anyway.

What I’ve done is to write a Word macro which allows me to run shell commands or code of my choice.

You might object and say, “So? I have Macro Security set to Very High. You’d have to digitally sign the macro first.”

I most certainly would not! The Macro setting in the Office suite is to protect you against an entirely different threat. In that scenario the threat is that an attacker can send us (or our users) a Word document with an evil macro inside which is run when we open the document.

This setting does not disallow developers to create macros, run them while developing and then sign them when they are in a state where they can be shared with others.

What does this mean for us? It means that we cannot use a pre-created Word document which contains the macro. We have to create the macro ourselves on the fly each time we want to run macros. See the difference? The security setting in Word doesn’t disallow you to create and run your own macros. If we would save the document and open it again, then the security setting would kick in and disallow the macro. If we had signed it before saving then we would be allowed to run it.

In order to prevent this we would have to have a setting in office called “Don’t Allow Users to Develop Macros”.

VBA-PrisonBreak

I named the macro I created VBA-PrisonBreak (I must have been watching too much TV). You can download the VBA-PrisonBreak from here. To test it in your environment open up Microsoft Word and press [Alt]+[F11] to enter the VBA editor. Double click on “This Document”. This will give you a code Window on the right side. Copy the contents from the VBA-PrisonBreak.txt file and paste it in the Window. The file contains different subroutines, or programs if you will.

To run one of these programs you set the cursor somewhere after the Sub [Program] and before the End statement. To execute the program you press Play or [F5].

To give it a try and test something harmless, start the routine called RunCommand() and enter.

ping 127.0.0.1

When the command is completed, go back to the Word document. If everything worked out as it should you will see which command you tried to run and the results.

Let’s see if we can poke around a bit:

cmd /c dir

Hm, this won’t work unless we have command prompt scripting allowed. Then again we can create scripts of our own and run them instead. Another sub routine of VBA-PrisonBreak is called ListFilesinFolder() and takes a directory as an argument. This is just a simple example but a lot can be accomplished by scripting.

So we haven’t done anything terribly exiting. The commands we can run by using the RunCommand() routine depend on a few factors, we will look at the Software Restriction Policies. We know we can run Word, but what about the default additional ones? Among others this includes commands under c:\windows and c:\windows\system32.

“net view” and “net user /domain” might be interesting and could give us some information. After looking around we might come to the conclusion that we want to run a command which isn’t allowed by the software restriction policy.

As a normal unprivileged user we will not have write access to c:\windows or c:\windows\system32, so we can’t place any files in those directories. But in our configuration we have write access to c:\windows\temp, and even better CREATOR_OWNER has Full Control. If we can place a file in this directory we will be able to run it with RunCommand() by entering:

C:\windows\temp\mycommand.exe

Now how would we place a file there? We can’t just use copy since cmd.exe is blocked. We might be able to use xcopy or tftp. If tftp isn’t available we might still be able to expand (.exe) it from c:\windows\i386\tftp.ex_. There is also a function in VBA-PrisonBreak which lets you download files through http (HTTPDownload()). It takes source url and target file as arguments.

From here we can download netcat and gain shell access to the server. Note that cmd.exe is still restricted; unfortunately an attacker can use another file or edit a version of cmd.exe. This edited shell file can then be placed under c:\windows\temp.

It is important to realize that the credentials used in this shell will be that of the unprivileged user account.

How to Protect Yourself

It’s really easy to protect yourself against this feature, remember this is not a vulnerability or an exploit in Windows or Word. We are trying to remove features from Windows (such as disabling cmd.exe), since the features we want to remove can be used in harmful ways.

When you install Office you don’t have to install all the features, one of these features is vba (Visual Basic for Applications). Without vba this prison break wouldn’t be possible (in the way I’ve described). You can find information about this in the Office Security pages. However as you can see on the page, Microsoft recommends that you don’t disable vba and also lists the reasons why, so you have to decide for yourself. This page also mentions the “very high” macro setting, but remember what I said before: this setting doesn’t apply in this context.

Another option is to disable vba through group policies. You can do this by using the .ADM files for Microsoft Office. This is only an option if you won’t be using any macros.

Even if your business requires you to be able to run vba, I have three words for you; Defense in Depth. If one part of the system fails, this shouldn’t mean that the defense has been breached.

The default Software Restriction Policies obviously didn’t restrict as much as we would have hoped. We will definitely want to explore these settings. If a user has write (and execute) permissions to any location within a SRP Path rule that user can run whatever he wants. You could set up deny rules for these directories or you could tighten the NTFS permissions and remove execute permissions.

It would be nice if the default policies provided some sort of protection, at least since Microsoft has written in several places that they shouldn’t be changed unless you are an “advanced user”. But the Software Restriction Policies can be fixed and in this case that’s not really the problem. Since we can write VBA code we have a lot of options. VBA-PrisonBreak is mostly a proof of concept; it doesn’t really do much.

On a network level if we take the example with tftp, there’s no reason why this should be allowed to or from your machine. If we were only supposed to run Word, allowing http doesn’t make much sense either.

Earlier on I said it would be good if there was a setting in Office called “Don’t Allow Users to Develop Macros”. Unfortunately, as far as I know this kind of setting doesn’t exist. However we can create one of our own. The VBA editor is using vbe6ext.olb which by default is located in this location:

C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB

If we deny the execute permission (NTFS) to this file for the users we want to lock down they won’t be able to launch the vba editor, but will be able to run signed macros. A little word of caution; I don’t know if there are any other issues you should be aware removing execute permissions to this file, but I don’t think there is.

The problem with scripting

The macro RunCommand() creates an object called Wscript.Shell. Is this required by your business? If you remove the NTFS execute permission (for the terminal services users) to the file c:\windows\system32\scrrun.dll, they won’t be able to use the RunCommand().

Is there another library an attacker can use if you deny the features from Wscript.Shell? Disabling scrrun.dll would still allow a malicious user to download files with HTTPDownload() it uses an object called Microsoft.XMLHTTP. There are a lot of scriptable libraries in Windows. Chasing them all down is hard, and it wouldn’t solve the whole problem.

As I said above the problem isn’t related to Software Restriction Policies. Even if the SRPs are set up in a way that would prohibit the user to run a non approved executable, that user would still be able to write vba code. If vba code isn’t scary enough, an attacker could pre compile a dll with a com interface and load the functions from that dll from vba.

The Weakest Link

To find the weakest link you might have to think outside the box. But that is the fun part of security. :)

Ask Jesper what he thinks of Security Guides and he will tell you that they won’t make you secure (or in Jesper-/Stevespeak you won’t be Protected).

I think security guides are great but still they are just guides, not a blue print for a secure network. Most guides are fairly generic and you have to decide what parts of it to use in your environment. The security of a network isn’t as strong as the sum of all security settings; it’s as strong as the weakest link. When it comes to SRPs, a guide can’t tell you which applications makes sense in you environment.

Summary

VBA-PrisonBreak in itself won’t allow a malicious user to take control of your server. That user would have to escalate his privileges first, unless the attacker was a “power user” or an administrator to start with.

VBA-PrisonBreak is just a way to gain another foot-hold in your environment. When trying to protect our networks we don’t want to give any more ground than we have to.

If you are a criminal and have been wondering through this article how Word can help you to get out of a real prison: It’s quite easy really; just open up Word and start writing “Dear Congressman”, press [enter] twice and write your plea for pardon. If you’re really lucky a magical paper clip will come to your aid!

Note: We did not lock down the Help Menu in Word, but since we didn’t use it to gain access that way I chose to ignore that and a few other threats in this article.

Credits

I, Patrick Ogenstad, work at Netsafe. I would like to thank John Laerum from Cornerstone for providing feedback on this article.

If you liked this article, please stick around! You can subscribe to the “feed”, or get updates by email. Also be sure to check out my security fiction stories.

If you have any feedback concerning this, please post a comment or contact me.

Appendix

The group policy settings used in the test environment:

  • Hide these specified drives on My Computer – All Drives
  • Prevent Access to Drives on My Computer – All Drives
  • Remove My Computer Icon on the Desktop
  • Remove My Documents icon from Start Menu
  • Remove Help Menu from Start Menu
  • Remove and prevent access to the shutdown command
  • Remove All Programs list from the Start Menu
  • Prohibit Access to Control Panel
  • Removed pinned Program list from Start Menu
  • Remove frequent program list from Start Menu
  • Remove Search Menu from Start Menu
  • Remove Run Menu from Start Menu
  • Remove Recycle Bin icon from Desktop
  • Prevent Access to the Command Prompt – Disable Command prompt scripting also
  • Prevent Access to registry editing tools
  • Run Only Allowed Windows Applications – winword.exe
  • Software Restriction Policies – Default Security Level – Disallowed

I have left the default additional path rules as unrestricted:

  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%*.exe
  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%System32\*.exe
  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Office in installed on D:\ so I added one path rule:

  • D:\Program Files\Microsoft Office\OFFICE11\winword.exe

[tags]Security, Locked Down, Software Restriction Policies, Terminal Services, VBA[/tags]

{ 3 comments… read them below or add one }

Locutus October 13, 2006 at 10:05 pm

You have probably read my blogs and I just want to let you know that I read yours. You have a very devious mind and I like the way you think. If my end users were half as smart as you I would be in serious trouble :) If I would let them….;P

Patrick Ogenstad October 16, 2006 at 8:47 pm

Locutus, yes I’ve seen your blog over at the Toolbox. I didn’t know you had another one?

Well hopefully your users are like me, i.e. not malicious. :)

Luís Barreto November 24, 2006 at 11:16 pm

I’ve found your blog because some time ago found SYDI (and translated it to PT).

This article among others deserve more than I will say:

- Great reading! The way you explain/explore this meticulous security questions is IMO awsome.

It’s curious that I’m almost in the end of a process of replacing our company’s Terminal Server… so, quite on time

Keep the great work ;-)

Leave a Comment

{ 1 trackback }

Previous post:

Next post: