11.2 ActiveX Security

Team-Fly    

 
Malicious Mobile Code: Virus Protection for Windows
By Roger A. Grimes
Slots : 1
Table of Contents
Chapter 11.  Malicious ActiveX Controls

11.2 ActiveX Security

Java's default security model runs untrusted code in a security sandbox. ActiveX's default model (see Figure 11-3 later in this chapter) doesn't run untrusted code, period! The defining question is how ActiveX determines what is untrusted code. In many cases, it doesn't, you do. When you download an ActiveX control, Internet Explorer checks for the existence of a digital signature to verify its authorship. Depending on the browser's security setting, you may then be asked (see Figure 11-1) to accept or deny the control's downloading and execution.

Figure 11-1. Internet Explorer ActiveX warning
figs/mmc_1101.gif

As you are prompted to accept a new, signed control for the first time, the browser will also allow you to accept every control signed by the same author, if you check the Always trust content from box. If you do, future controls from the same author or vendor, now considered trusted publishers , will not result in additional notifications. They will download and execute without warning. This is a lot of trust to give a vendor, so give it with due consideration. Microsoft writes trusted publishers to the following registry keys:

  • HKU\Software\Microsoft\Windows\CurrentVersion\WinTrust\TrustedPublishers\SoftwarePublishing\TrustDatabase\0

  • HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\TrustedPublishers\SoftwarePublishing\TrustDatabase\0

A few sneaky controls have ignored the user 's authority by directly modifying the registry to make themselves trusted publishers. After the user initially accepted the control, the control, unbeknownst to the user, makes its creator a trusted publisher. Then any control signed by the same vendor can download without further user notification. This type of predefined trust is also found on a lot of new computers. In an effort to provide better technical support, several leading vendors include controls and publishers on brand new PCs that are configured as trusted. Again, this is taking the decision of who to trust out of the hands of the user.

Figure 11-2. Unsigned control message
figs/mmc_1102.gif

If a control is not signed, you are given the option of accepting or denying it (see Figure 11-2). Microsoft considers all unsigned controls as unsafe. While this can be true, many of the controls you will download are legitimate and safe, yet are unsigned. If you accept, the unsigned control runs and you will not be prompted again for the same control. If you deny the control, the code is not executed (although it has already been downloaded to a temporary file location).

With ActiveX, an author writes his program in any one of the dozens of accepted ActiveX languages, compiles it into 32-bit machine language and stores in an .OCX file. Microsoft then hopes developers will digitally sign their code before placing it on the Web, although this doesn't happen in many cases. Users download the ActiveX control and may be prompted by the browser to accept or deny the program. If accepted, the browser runs the control and it has full access to anything on your system that you have -- sometimes more.

Figure 11-3. ActiveX development and security model
figs/mmc_1103.gif

Microsoft's ActiveX security stands (or falls ) on whether or not you, or your browser, accepts the code as trusted. It doesn't tell you what system resources the control will access or what it might do (as Java's new security model attempts to do). ActiveX's entire security scheme is based upon signed code, security zone policies, and end-user judgment. (See the ActiveX development and security model in Figure 11-3.)

11.2.1 Digital Signing and Certificates

Central to ActiveX's security (and to a lesser extent, Java) is the concept of digital signing . Digital signing is recognized by hundreds of software applications, including Microsoft's Internet Explorer, Outlook, Outlook Express, Office, and Netscape. Digital signatures allow a user to verify, prior to running executable code, that it came from the developer it says it came from; and that nobody else has modified the code. It doesn't guarantee who distributed it or where it ultimately came from. And it doesn't mean the code is bug free or not malicious. Digital signing only authenticates those who created or intended to distribute the code. The code can still be malicious or used maliciously. As has been the case in so many past incidents, malicious mobile code has been able to insert itself into other, supposedly trustworthy, code. If the original author doesn't recognize the infection, his code will still be digitally signed and electronically distributed as if it were safe.

There are several digital-signing platforms, including Microsoft's Authenticode figs/u2122.gif , Netscape's Object Signing figs/u2122.gif , Javasoft's Jar Signing figs/u2122.gif , and Apple's Code Signing figs/u2122.gif . Although based on a similar concept, they are not compatible. Developers are forced to make a decision they don't want to make. Either they direct their code-signing efforts toward one particular platform and thereby exclude using secure code on competing architectures, or they work harder fulfilling the code-signing requirements on multiple platforms. Programmers writing ActiveX controls will choose Microsoft's Authenticode initiative.

11.2.1.1 Digital authentication summary

Digital signing allows authors and users to verify (authenticate) that a particular piece of code hasn't been tampered with. Software developers wishing to digitally authenticate their code, have to put their finished code product through a series of additional steps, as shown in Figure 11-4. First, they write their program and apply a series of processes to digitally sign their code. The code is examined by a mathematical hash algorithm to produce a unique digital fingerprint . The author encrypts the digital fingerprint with his private key to create a digital signature . This signature will not be the same for any other vendor or any other piece of code. The digital signature is attached to the code, along with a public decrypting key , and a certificate verifying the decrypting key, and is placed on the Web. When a user downloads the signed code, it is placed into a temporary file (usually C:\%windir%\Temporary Internet Files ). The control's certificate is inspected to see if it was granted by an authority the browser trusts. If so, the software vendor's certificate is used to verify the authenticity of the decrypting key. The browser then decrypts the digital signature with the decrypting key back into its hashed fingerprint. The code is rerun through the same hashing algorithm as the author performed and the two results are compared. If identical, the code is executed and run. If the two hash totals don't agree, then the code is considered unsigned. The end-user portion of this process is performed seamlessly by the browser.

Figure 11-4. Digital authenication summary
figs/mmc_1104.gif

As you can see, a lot of examination goes into verifying signed code. If any of these processes fails, the code is discarded or the user is warned that the code is unsigned. Encryption is a crucial part of ensuring that the crucial parts of authentication cannot be faked.

11.2.1.2 Encryption

Encryption , as explained in earlier chapters, is the process of taking a plain text message and scrambling it in such a way that it is not understandable during transport, and then converting it back to its original form for the intended recipient(s). A key is the character representation that can be mathematically applied to scramble or unscramble the message. A good key and encryption routine uses special mathematical properties to create the following characteristics in the encoded message:

  • Encoded message should be beyond difficult to reverse engineer back to plain text

  • Different messages should never create the same encoded result

  • Encoded result should be always be identical for the same message

11.2.1.3 A simple encryption example

A very simple encryption method might be subtracting one letter from any alphanumeric character in the message. Thus A becomes Z, B becomes A, C becomes B, and so forth. A message in its plain-text form might read, "The safe combination is 32-23-42." While encrypted it would read, "Sgd rzed bnlahmzshnm hr 31-22-41." Both parties of the intended communication would know to add one letter (the decryption key) to each character to unscramble. This is, of course, a very simple example that would not be used in real life. This type of encryption, where the same key is known to both parties, is called symmetric cryptography , or private key encryption .

During the discussion on encryption I will frequently refer to encrypted messages . A message in cryptography means any type of content (executable code, text, graphic, sound, etc.) and not just printed text.

One of the critical problems in private key technology is how to transport the private key in a secure method to all the parties involved. There is the fear that during the transport of the private key it will somehow become compromised and make the encryption session unknowingly insecure . Also, private key encryption cannot prove who made a particular message (authentication). Since all of the involved parties use the same private key, any of them can forge a message from any other. Enter public key security .

11.2.1.4 Public key security

Central to any digital certificate scheme is the use of public key cryptography (see Figure 11-5), which uses two related keys for secure communications. In our case, keys are used to encrypt a message or create a digital signature. With this form of encryption, the originating party generates two keys: a private key and a public key . Only the originating party has and knows the master, private key. Everyone else can have the related public key that is common to all parties involved. Only the user(s) with the private key can create an encrypted message (in our case, a digital signature) that can be unencrypted with the related public key. Anyone with the public key can unscramble it. The public key will only unscramble messages signed with the related private key. The private key can create or read encrypted messages. Public keys can be used to make messages that only the private key owner can read. The official name for this type of system is asymmetric key pair .

Figure 11-5. Authentication with public key cryptography
figs/mmc_1105.gif

This scheme allows the message source to be authenticated because the sender is the only one who can create the message. Second, since anyone who wants to read the message need only get a public key, it doesn't compromise the security of the private key. So far the legal status of digital signatures has not been thoroughly tested in the court system, although they are readily accepted by many authoritative regulatory bodies (GAO, UCC, NIST) as nonrepudiated evidence. Nonrepudiation is legalese for "You can't say it didn't come from you." Still, someone might be able to prove that their private key was compromised and subsequent messages were faked.

Public key cryptography was introduced in 1976 by Whitfield Diffie and Martin Hellman.

Security experts are always concerned about malicious mobile code of the "Family & Friends" type. These can infect a person's computer and automatically send emails that appear as if they were sent by the sender. There are hundreds of attacks that do this. A "Family & Friends" malicious program could easily send email signed by a user's private key. For that reason, private keys should always be password protected, and stored in a secure location.

11.2.1.5 Hashing

Signing content involves performing a quick mathematical check against a predefined area of the code. This is called hashing , fingerprinting , or message digesting . The hash calculation is done using a standard well-known formula (such as MD5 or SHS), which is difficult to reverse engineer and fake. That is, if someone finds out the hash total, it is difficult to reconstruct the message it was applied against; and it is difficult to manipulate the message in any way without a different hash result appearing. You can review the Message-Digesting-5 (MD5) algorithm in Internet RFC 1321 (http://www.ietf.org/rfc).

The result of the mathematical analysis is called a hash total , or digital fingerprint , and is encrypted using the author's private key and stored with the code. Later, when the file is sent, the same mathematical check is applied again and verified against the original hash total. As long as the message has not been tampered with, the hash results will always be the same. If the source and destination hash totals don't agree, the digital signature and related certificate are not authenticated. This check lets you know that the code has not been modified after the code was signed.

It's important to understand that although encryption is used to sign the hash fingerprint, the code itself is not encrypted. Encrypting the complete code would take lots of additional time without adding significant benefits. And for this reason, signed code can be exported outside the US without breaking exportation laws. If the code itself needs to be encrypted, it would have to be put through another set of cryptographic processes. Fortunately, both Java and ActiveX contain standard APIs for code encryption.

11.2.1.6 Certificates and certificate authorities

A document that guarantees that the public key was created by the person or company claiming to be its creator is called a certificate . A certificate does not identify who distributed the key or where it came from, only who generated the key. A certificate is unique per user (or company) or it can be unique per product. A message can be signed with multiple certificates. When you download code, your browser looks for the presence of a digital signature and its public certificate. With its default security settings, Internet Explorer will refuse to automatically execute unsigned ActiveX. Both Netscape and Internet Explorer force unsigned applets to run in the security sandbox.

Certificates relied upon by the public are issued by independent third parties known as Certificate Authorities (CA), who play the most important part in the public key infrastructure. CA's ultimately attest that they have verified the identity of the certificate holder. Depending on the attestation process and how involved it is, the resulting certificate can be designated as Class 1, 2, or 3. Class 1 certificates are given with minimal credential checking, maybe only verifying the requestor's email address. Class 3 certificates, on the other hand, require substantial verification. The requestor has a lengthy application process, must provide irrefutable evidence of identity, and may even need to make a personal appearance. Consequentially, Class 3 certificates provide more reliance than a Class 1 certificate. Most CA's require a Class 3 verification process before they will grant a digital certificate to a software developer.

Digital certificates issued to software publishers are signed with the CA's own private key (to authenticate the CA) and contain at least the following: owner's public key, owner's name, expiration date of the certificate, name of the CA, serial number of the certificate, and the digital signature of the CA. Dozens of companies offer digital certificates. VeriSign figs/u2122.gif (http://www.verisign.com) is currently considered the industry leader in digital certificates, but other companies (such as Equifax Secure figs/u2122.gif (http://www.equifax.com) and GlobalSign figs/u2122.gif (http://www.globalsign.net) are growing. Certificate authorities can allow other third-party companies to assign certificates on its behalf . The highest governing certificate authority along the chain of trust is known as the trusted root authority .

11.2.1.7 Digital certificate incompatibilities

In order for your browser to automatically trust signed code, the certificate must have been created by certificate authority your browser already trusts. Digital certificates and IDs, although based on x.509 standards, are not usually compatible between different code-signing products. It means that signed code meant for Internet Explorer and Netscape browsers will often have to have two versions, each signed by a separate certificate. And of course, the developer has to buy a different certificate to support each platform. A few companies, like Thawte figs/u2122.gif (http://www.thawte.com), recently purchased by VeriSign, offer certificates compatible for multiple code-signing platforms.

11.2.1.8 Certificate granting process

Certificates are granted the following way: a programmer generates a key pair, public and private, as the initial part of the certification process and sends the public key (as proof of the private key) to CA along with a proof of identification. The CA verifies the identifying information and creates, using its own private key, a certificate (also called the digital ID ) that the programmer can attach to his program. Typically, this process takes three to five days. The certificate is relied upon by end users as evidence that the public key used to decrypt an encrypted message was created by the private key owner. Without a mechanism to attest to the validity of the public key, malicious parties could distribute code with their own keys and claim to be a particular vendor.

Inherently, you must trust the CA who issues the digital certificate to do the job of validation, or else you shouldn't trust the certificate. In many cases, a programmer's public key is posted at the CA so that anyone getting an encrypted message can obtain the public key and extract the plain text contents. With browsers and downloaded code, the owner's public key is usually transmitted with the certificate to decode the digital signature. When the public key is not transmitted with the signed code, the browser will attempt to locate the author's public key at the CA's web site.

11.2.1.9 Trusting the trust giver

Signed code is a chain of trust. The certificate says you can trust that the code publisher's public key is authentic . In trusting the certificate you are saying that you trust (or in reality, your browser trusts) the certificate authority to verify the publisher's identity. You are trusting the developer not to program his software to do anything you don't want it to do. You are trusting that the developer took reasonable steps to protect his private key. You are trusting that the developer's software was not infected with malicious code when he signed. You must trust that cryptology experts created hashing and public key algorithms that can't be faked. It is all a matter of trust, and like any chain, it is only as strong as its weakest link. Thus, when you hear the phrase trusted code , it often means digitally signed code attested by a certificate.

Internet Explorer will list at least four types of certificates:

  • Personal

  • Server

  • Software publisher

  • Certificate authority

Personal certificates are for use by individual users to authenticate the actions or coding of one user or developer. Personal certificates can also be used to authenticate a user to a secured web site or for use with secure email. Server certificates allow web servers to operate in secure mode, encrypting information between the browser and server. This chapter is concerned with the next two types. Software publisher certificates (listed under Other People in Internet Explorer) are the certificates of developers the user or browser has designated as trusted (see Figure 11-6). Signed code arriving from one of these developers will automatically execute in most cases.

Figure 11-6. Example list of software publisher certificates trusted by Internet Explorer
figs/mmc_1106.gif

Certificate authorities certificates are the CAs the user or browser will automatically trust to attest the validity of the other three types of certificates. When you download signed code and its digital certificate, Internet Explorer immediately examines the certificate and verifies that the certificate authority is one whom it trusts. If Internet Explorer does not have the CA's public key, it will prompt the user on whether they want to accept a new CA. If so, the browser contacts the CA and installs the CA's public key. In practice, dozens of CA's are preinstalled as a trusted root CA by Microsoft browsers. The public CA certificates contain an expiration date. Earlier browser versions had trust certificates that expired on January 1, 2000, but most new browsers contain trust certificates with expiration dates (e.g., 2010) that should outlive the browser.

Figure 11-7. Example certificate
figs/mmc_1107.gif

If you want to see the list of CA's Internet Explorer trusts, choose Tools figs/u2192.gif Internet Options figs/u2192.gif Content figs/u2192.gif Certificates and choose either the Intermediate Certification Authority or Trusted Root Certification Authorities (see Figure 11-7 for an example of a CA certificate).

11.2.1.10 Revocation

Digital certificates, as recognized by today's browsers, follow the CCITT X.509 version 3 standard. Most certificates have an expiration date and can be revoked prior to its expiration date by the issuing certificate authority. Revocation can be started because the developer thinks the certificate was compromised or initiated by the CA because the holder violated terms of the license agreement. CAs publish lists of revoked certificates that users can compare against any suspected public certificate they are inspecting. This process is becoming more automated, but isn't always reliable. Fortunately, there have been very few revocations.

11.2.1.11 Always trusting a certificate

If you trust a particular vendor to always deliver trusted code, you can accept the vendor's public key with your browser and any code signed with the vendor's private key will be accepted for the duration of the certificate. The first time you accept a signed control from a particular vendor, Internet Explorer and Netscape will offer the opportunity to always accept any signed content from that vendor. Some versions of Internet Explorer allow you to accept any object signed by a particular CA. Be careful, as this is a lot of trust to give any vendor or CA.

11.2.2 Authenticode

Microsoft's initiative for digitally signing code is known as Authenticode figs/u2122.gif and is available with Internet Explorer 3.x and above. Authenticode is based on a 128-bit cryptographic system involving X.509 (certificate specification), PKCS #7 (encrypted key specification), SHA and MD5 hash algorithms, and PKCS #10 (certificate request formats). So although Authenticode is proprietary, it is based on popular industry-accepted technology. Authenticode can be used to sign any 32-bit .EXE (PE files), .DLL, .CAT , .CTL , .OCX , .CAB , and .CLASS file. Figure 11-8 displays a message in Internet Explorer alerting the user about an Authenticode validated control.

Authenticode does not sign Internet scripting language files

Figure 11-8. Code signed by a valid Authenticode certificate
figs/mmc_1108.gif

In order to digitally sign a control, all the necessary files must be merged into one .CAB file and then signed as a whole. Individual signing of files within a single cabinet file is not supported. This makes authentication easier to manage. If one file within the cab is changed, the whole cab must be resigned. In this way, the author always reestablishes his ownership of the whole package, and not just a part of it.

Authenticode digital certificates ( Class 3 Commercial Software Publisher Digital ID ) routinely cost $100-$400 per year and are assigned to corporations who can prove their identity. Companies obtaining a commercial certificate promise never to intentionally distribute malicious code. Authenticode's end-user license (EULA) contains Microsoft's standard boilerplate language absolving Microsoft of liability for any damage caused by the use of Authenticode.

Individual certificates (usually Class 2 Digital IDs ) for small software developers can be had for less money per year and the user's promise to take reasonable steps to protect the private key. Unfortunately, many CAs (including, VeriSign) have either discontinued Class 2 IDs for Authenticode or never offered them because the cost to verify the developer's identity outweighed the revenue. Personally, I feel this significantly weakens Microsoft's code signing security model. ActiveX depends on Authenticode for security. By pricing most digital certificates at several hundred dollars per year, most small developers and home programmers will not sign their controls. This has led, and will lead, to substantially more unsigned code than signed code on the Web. Users will become accustomed to downloaded controls being unsigned, ignore the cautionary warnings, and thus weaken the overall model.

11.2.2.1 Java, Authenticode, and Internet Explorer

Authenticode is only supported by Internet Explorer, or in Netscape by using an Authenticode plug-in. Most objects signed by JavaSoft or Netscape technologies will run in Internet Explorer, but won't be interpreted as signed. Authenticated Java applets can be downloaded in Internet Explorer as long as they are part of a signed .CAB file. During the signing process, the .CAB specifies any special resources its wants outside the normal Java sandbox. While being downloaded, Internet Explorer examines the signature, verifies it, and then compares any requests for resources outside of the sandbox to what is allowed in the Internet security zone. If the requests are predefined as allowable , the applet will launch without any notification to the user. If the applet requests access permissions outside the predefined set, the user will be prompted to allow or deny them.

11.2.2.2 Timestamping

Digital IDs rely on encryption, and any encryption scheme can be cracked in time. For this reason, digital IDs have an expiration period to remain trustworthy. Authenticode digital IDs are only good for one year. This creates a problem because most software code is used for a longer period of time. Software developers can choose to resign their code every year, or as they should, timestamp their code. When a software author signs new code, the hash result is sent to VeriSign (http://www.verisign.com) and timestamped. The hash signature is forever documented as having been valid during the digital signing process. If users download expired, timestamped code, they will see that the digital signature is valid even though the certificate has expired. Expired, timestamped code should be trusted. Expired, untimestamped code should not be given the same amount of trust.

VeriSign is the only CA offering Authenticode timestamping.

11.2.3 Signed Code in Action

The treatment of executable code by Internet Explorer depends on the type: ActiveX or Java. Microsoft gives any ActiveX control, signed or allowed by the user, complete access to the computer system. Users determine whether or not a signed or unsigned ActiveX object can be automatically executed without end-user intervention by defining allowed behaviors per security zone. By default, unsigned ActiveX objects cannot automatically run in any Internet Explorer security zone. In high, medium, and medium-low zones, unsigned ActiveX objects are not allowed to run and are ignored. In the lowest setting, usually reserved for the trusted sites zone, unsigned ActiveX controls will still prompt the user to approve before running (not always so in earlier versions of Internet Explorer).

With Java, unsigned code will typically either not be allowed to run or be forced to run in a limited security sandbox. Internet Explorer allows users to predefine the level of default trust and access to local system resources to be given to authenticated Java code. Internet Explorer allows Java security policy to be configured in a user-friendly menu (Tools figs/u2192.gif Internet Options figs/u2192.gif Security figs/u2192.gif Custom Level figs/u2192.gif Java Permissions figs/u2192.gif Custom figs/u2192.gif Java Custom Settings figs/u2192.gif Edit Permissions).

When incoming signed Java code is recognized by the browser, Internet Explorer immediately inspects the signed .CAB file for requested permissions. If the requested permissions don't exceed those predefined for the particular zone, the applet is allowed to run without user intervention. If the applet requests access beyond the predefined options, the user will be prompted to allow or deny the additional access. Since Internet Explorer does this during the initial download of the code, the user knows immediately what the code is capable of requesting and the approval process only done once.

11.2.3.1 Internet Explorer and Authenticoded Java

When Internet Explorer downloads a signed applet requesting permissions beyond those allowed in the security zone and the browser has been instructed to prompt the user for additional access requests, the user will be given the opportunity to approve or deny the additional permissions (see Figure 11-9 and Figure 11-10).

Figure 11-9. Java applet requesting full permissions to the local system
figs/mmc_1109.gif

Figure 11-9 shows a Java applet requesting full permissions to the local file system in Internet Explorer. In the example, the developer's certificate has expired. Although Internet Explorer considers the expired certificate as untrusted, most people consider expired certificates as somewhat trustable. At some previous point, the developer of this application held a valid certificate, and since then the code has not been modified. If the code had been modified since then, Internet Explorer would consider the digital certificate as invalid, and say so.

Figure 11-10. Signed applet asking for additional permissions
figs/mmc_1110.gif

In both Figure 11-9 and Figure 11-10, the applets are asking for additional specific permissions beyond those allowed in the current security zone. Had Java permissions been set to Disable instead of Prompt, the applets' additional requests would have been denied without user involvement. Many applets are not given enough error-checking routines and the denied access will result in incomplete web pages, blank gray boxes, and other unpredictable, minor consequences.

Additionally, applets wishing to access the local file system in Windows must use Microsoft-proprietary Java classes. Meaning that although an applet written to run in the sandbox can easily be cross-platform, applets wishing to exceed default limitations must be specifically written for the Microsoft platform ( causing problems on other platforms). This type of forced exclusionary coding behavior has long been debated between JavaSoft and Microsoft.


Team-Fly    
Top


Malicious Mobile Code. Virus Protection for Windows
Malicious Mobile Code: Virus Protection for Windows (OReilly Computer Security)
ISBN: 156592682X
EAN: 2147483647
Year: 2001
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net