In an earlier post, I wrote a brief overview of Monad’s three main security features:

• Not allowing users to double-click on Monad scripts by default
• Requiring that all scripts be signed by a trusted publisher
• Requiring that users explicitly invoke scripts in the current directory

The discussion was helpful, but a little abstract.  How do the security features of Monad compare to those of other shells?    How exactly do Monad’s security features prevent a scripting virus attack?  I’d like to spend a few minutes to demonstrate that.  We’ll do this from the perspective of a determined attacker, and very willing victim.

The first line of defense comes from the email transport infrastructure, such as that of a managed Exchange deployment.  To start, the attacker sends their original attempt: a malicious Monad script directly attached to email.  With server-side virus scanning, the user sees only:

This is where most fully-automated email worms would be stopped.  If the user follows security best practices, their desktop-based anti-virus software will strip the virus if their mail server does not.  However, the user is very interested, and replies: “I’m sorry, Evil Hacker.  Exchange quarantined your virus!  Please send again!”

In response, the attacker changes the malicious script to evade the signature-based virus detection algorithms.  Some viruses, known as “polymorphic” viruses, do this automatically.

Now, any type of script is really an executable.  This is true for WSH “.vbs” attachments, Batch “.bat” attachments, Unix “.sh” attachments, and more.  MSH scripts are no different.  Exchange server blocks most of these on the server side.  In addition, both Outlook and Outlook Web Access block many forms of executable content on the client side.  MSH scripts will be no different:

Since the user is really interested, he or she replies, “I’m sorry, Outlook blocked your executable attachment.  Please send again!”

To get around this, the attacker sends the file in a password-protected ZIP file.  Some viruses do this automatically, as their relative lack of success can attest to. 

Alternately, the user might use an email client that does not support executable attachment blocking (and might use a server that does not, either.)  In that case, the attacker’s script would get through.

Now, let’s see how different shells would protect a user, once they’ve gone through the difficulty of shepherding the malicious script on to their system.  The user double-clicks the .cmd file, and up pops its window:

DOS didn’t offer much resistance.

Unix does much better, as it’s not generally configured to allow you to double-click on a script.  In addition, you have to explicitly tell it that the script is both in the current directory, AND executable.

Now, let’s see the attack with an MSH script.

Like the Unix shell, the user was not able to double-click on the file to run it.  It would have opened notepad if he or she were to try.  Also like the Unix shells, they had to explicitly call the script from the current directory.

At this point, the attacker’s best chances are to instead send the user a traditional Windows executable.  However, we’re not talking about traditional executables, we’re talking about Monad.

The user replies, “I’m sorry, attacker.  Could you please sign that script?  My system only accepts scripts signed by trusted publishers, with certificates granted by a reputable Certificate Authority”

Our attacker, being a willing participant, goes to an industry-recognized certificate authority (such as Verisign or Thawte) to get a code signing certificate.  He or she provides the required Government-approved documentation to the business, along with the $400 application fee.  The business then verifies:

• They are issuing it to the correct Company.
• The company owns the Internet Domain Name in the request.
• The Company is registered in one or more countries.
• The registered Company Name is the same as the name on the Certificate Request.

    [http://search.thawte.com/thawte/solution.jsp?id=vs1515]

The attacker then signs the script, and re-sends it to the user in a password-protected zip file.  The user dutifully runs it, and sees:

At this point, the user has made almost half a dozen implicit trust decisions, and one very explicit trust decision.  If the user decides to run the script at the “Untrusted Publisher” prompt, then no amount of infrastructure can save them from themselves.  The user is responsible for his or her actions, not the implementation language of the attack in question.

It’s at that point where security best practices (such as running with least privilege) can help limit the amount of damage that malicious code can do.

[Edit: Monad has now been renamed to Windows PowerShell. This script or discussion may require slight adjustments before it applies directly to newer builds.]