FEATURE

Java and ActiveX: Background and Risks to the Business

Stewart Hayes, Insight Consulting

J ava and ActiveX, commonly known as mobile code, are becoming more prevalent as the

Internet and more specifically the World Wide Web develops. Concerns are being voiced about the security of these utilities and what impact they may have on the security of systems making use of Internet-based services. This article describes the background to and usage of these utilities, the likely threats and what precautions can be taken to minimize any risk.

"There is a lot of concern in the security community as to what can actually be achieved through the introduction of rogue mobile code, though to date there have only been a few reported incidents of failed Java or ActiveX applets."

The Web is basically a mech- anism for enabling easier access to information. It is done through the use of ' pages ' of i n fo rma t ion which can be accessed e i ther by searching for specific contents or from links in other pages. These were in i t ia l ly tex t -based and reduced the need for user under- standing to 'point and c l ick ' . Em- bedded within the page were

the detai ls necessa ry to go to the next page of information.

As the use of the Web grew, so did the capabilities of the pages. Graphics were introduced along with links to other Internet services - - file transfer, E-mail etc. This gave the ability to download information or executable programs directly from a Web page to the user's machine. It was, however, a manual operation and the user had to down load code that was specifically designed for their workstation.

To overcome this manua l opera t ion , Sun Microsystems developed Java. This was intended as a universal programming language which would allow code to run on any workstation. Conse- quent ly , the user was no longer required to download a specific version of code thereby removing the manual involvement.

"The threats arising from mobile code are similar to those caused by computer viruses."

Developers were now able to develop Web pages with 'active content ' ; code could be downloaded to the user's workstation and executed locally. Graphical images could be made to move, different screens could be displayed depending on response and values could be modified locally.

This had the benefit of being able to 'virtually' transfer large amounts of information and graphics to a user's workstation over low speed links. It made Web pages more jazzy and attractive and gave rise to some business benefits which are only now being exploited such as what-if scenarios on Portfolios, projected research values etc. These are in the main done by temporarily downloading small applications (applets) to the user workstation for execution or in some cases installing larger applications which remain in the workstation permanently.

Java was developed with a lot of emphasis being placed on the secur i ty func t ions . The dangers inherent in this type of system were recognized early on and where possible, steps were taken to minimize them.

ActiveX was developed by Microsoft as a direct rival to Java. It offers similar functionality and has proved very popular in its ease of use, however, there is

Computer Fraud & Security July 1998 © 1998 Elsevier Science Ltd

FEATURE

some debate in the security community as to the effectiveness of the security features.

T h r e a t s

The threats arising from mobile code are similar to those caused by computer viruses. In this case, however, the 'carrier ' code is being installed and

executed without the knowledge of the user. Code can

be downloaded that would assess the applications the user has on their system and return the information to another company, it may collect passwords, it may act as a virus and cause the sys t em to opera te in un in tended ways - - delete informat ion , modify information or erase the whole system. These are known as ' rogue applets ' and may be generated acc iden t a l l y th rough care less p r o g r a m m i n g or deliberately with malicious intent.

There is a lot of concern in the security community as to what can actual ly be achieved through the

i n t r o d u c t i o n of

"it may collect rogue mobile code, though to date there

passwords, it may have on ly been

act as a virus and a f e w reported incidents of failed

cause the system Java or Ac t iveX

to operate in applets. These were mainly as a result

unintended ways" of bad cod ing causing the systems

to 'hang' or information to be displayed incorrectly. It is anticipated, however, that these will become more d e l i b e r a t e as use of the p r o g r a m m i n g languages becomes widespread with targeted attacks being used to gather information about users, make unwanted changes to sys tem conf igura t ions or simply to create as much damage to a user's system as possible.

It may be that a developed applet was tested and found to be secure when the sys tem was first established, but it may have been modified whilst on an unsecured server or the server itself could be u n s u s p e c t i n g 1 y hosting additional applets that were placed there without the owners' knowledge. From the commercial aspect, those companies that are using the Internet and Web to provide information

must not be in a position of being found to be the source of rogue applets. This could have immediate and serious implications on corporate image and could well affect a companies standing in the marketplace.

It is certain that the use of mobile code will develop as the perceived benefits far outweigh the current risks. Already, the use of applets is becoming widespread in the Internet business community and in some cases is essent ia l to the provis ion and exchange of informat ion. This gives rise to the alternative threat of denial-of-service - - for those users who do not allow applets to execute on their workstations.

S e c u r i t y m e a s u r e s

The measures that can be taken both to protect a workstation and protect a server are at present limited.

Workstations

There are generally two approaches taken. First, allow all active content code in to the company's network and hence the individual's workstation on the basis that the business needs to access those pages and the reported number of incidents (and therefore the envisaged risk) is low. Second, block all active content from entering the network. At present, the affect of these policies is minimal, however, as the usage of active content grows and the proliferation of rogue applets also grows, the policy will need to be refined significantly.

The approaches that are being cons ide red throughout the business Internet community are as follows.

"targeted attacks being used to gather information about users, make unwanted changes to system configurations"

Allow Java applets in but block ActiveX applets as the risk associated with Java is con- sidered lower. This is true to a certain extent but does not address the fact that the ma jo r i ty of business sites on the In te rne t will be

10 Computer Fraud & Security July 1998 © 1998 Elsevier Science Ltd

FEATURE

coded using ActiveX as it is cheaper and easier. For example, most of the Microsoft-based sites would be blocked if this policy was applied.

Only allow in applets from known sites. This would require the operational management team to constantly update their policy to add new sites, remove sites that have been compromised or modify sites that change address. There is still no guarantee that the originator of the applet has carried out sufficient testing and follows strict enough procedures to ensure the applet will operate correctly.

Only accept 'signed' applets. These applets have a cryptographical ly

"it is unlikely that the signatures of the applets are actually checked before execution," obtained by anyone making an

derived signature to ve r i fy that they o r ig ina ted f rom a known source. There is some doubt over the validity of this as the ability to create a valid cryptographic s igna ture can be

application to the few certification authorities on the Internet. Further, it is unlikely that the signatures of the applets are actually checked before execution.

Run all applets in a 'sacrificial' system outside the organization's secure boundary. Products are available and are being developed to do just this. This system does offer a high level of security against attack by rogue applets but should be tested for performance and configuration capabilities.

Servers When a source of active content pages, steps must be taken to ensure the integrity and security of the site is maintained. It is essential that the server itself is installed in a secure location behind a firewall and the policy prevents any unauthorized access. The content of the server must be monitored to check for any changes and where poss ib le all applets should be signed cryptographically before being released. The applets themselves must be thoroughly tested by a separate team from those that developed them to ensure no unacceptable code is del iberately or accidental ly entered into a company Web page.

R e c o m m e n d a t i o n s

At present the risk from rogue applets is relatively small and the impact likely to be slight. This will change within the next year as E-commerce develops and the commercial use of the Internet grows. Steps must be taken now to address the potential problems and ensure the bus iness is in a pos i t ion to take advantage of the Internet whilst maintaining a good level of internal security.

The best solution at the moment is to allow normal usage of the Web browser as the browser configuration is guaranteed to reflect the browser security policy. Security-relevant browser settings should be locked so that users cannot switch off policy enforcement. The policy should consider the areas below:

Configuration locking." conf igura t ion sett ings should be defined by the security administrator and should be locked to prevent users from changing them.

"These applets have a cryptographically derived signature to verify that they originated from a known source."

Cookies: A cookie is a short text file used by Web servers to ga ther i n fo rma t i on abou t a user supposedly to enable navigation around the Web to be easier. They will not cause machine disruption but may gather privileged information (passwords, credit card data etc.) that should not be disclosed. There should be a warning given if cookies are received. Cookies cannot compromise the security on the machine but they can track user behaviour on

the Web. Therefore, users shou ld be made aware of the c o n s e q u e n c e s of accep t ing cook i e s (user awarenes s ) . (Note : this cou ld lead to user frustration as the use of cook i e s is now prolif ic across the Web.) Ano the r op t ion is to

automatical ly delete the cookie file when the browser is closed. This means that cookies are available for the current session only which would make the information stored in the cookies less privacy-critical.

Computer Fraud & Security July 1998 © 1998 Elsevier Science Ltd

11

FEATURE

Java applets/JavaScript: Java/JavaScript is an important part of the Web today and therefore should be allowed in. Code signing technology is not widely used yet though in the near future will be available and then signature verification should be used. Certificates must be imported securely. The other option to increase security is to restrict the privileges Java has in the sandbox (the area the Java applet executes in).

ActiveX: Act iveX should only be a l lowed if controls are signed by trusted organizations (e.g. by Microsoft). In general, ActiveX controls which are signed by unknown organizations or which are not signed at all should be rejected. Again, certificates must be imported securely.

Plug-ins: Users should not be able to install plug- ins on their machines. If a plug-in is required, the user should contact the administrator who will get a verified copy from the plug-in vendor.

Awareness: It is essent ial that users are kept informed about the risks associated with using a Web browser. This should prevent users from by- passing security features. All users should receive security awareness training with their browser. This expla ins the responsibili t ies of the user, the concept of trust , and the c o n s e q u e n c e s of potent ial secur i ty breaches. Examples of appropr ia te statements include:

"the server itself is installed in a secure location behind a firewall and the policy prevents any

- Think very unauthorized carefully before accep t ing a access," digitally signed message (da ta or p rogram file). How competent and trustworthy is the signer?

- Never surf the Web using a computer that contains highly sensit ive informat ion; for example medical records or client details.

- Be aware that an attacker may compromise your computer if you mn untrusted programs on your machine.

- Never d i sc lose your pas sword or o ther privileged information (e.g. bank account PINs) while using a browser.

"Browser security should not rely on the firewall's active content filtering."

Firewall: If certain types of active content are supposed to be disabled, the flrewall should be con- figured in such a way that this active content already gets filtered out at the firewall. This adds a bit of

extra security. Apart f rom that, the firewall policy will not have any impl ica t ions on browser securi ty. Browser secur i ty should not rely on the firewall's active

content filtering.

Active Content Scanning." Investigate the usage of a cent ra l f i l t e r ing proxy server to suppor t the company's policy on managing active content.

Summary The use of act ive code is an e s sen t i a l part of information provision and gathering via the Web. Positive steps must be taken at this early stage to understand the possible effects of this code on the organization either as recipients or as a source. There are security measures that can be taken to minimize the risks, but these can only be applied effectively if the threats and poss ib le impacts are eva lua ted through a structured, well maintained risk analysis process.

12 Computer Fraud & Security July 1998 © 1998 Elsevier Science Ltd