Cloanto   Home     Products & Services     Purchase     Support     Search: Go
Currency System :: Support :: White Papers
System Overview
Currency Server
Managed Services
Web Tools
:: Overview
:: FAQ
:: Troubleshooting
:: White Papers
:: Internationalization
:: The Euro
:: Currency Codes
:: Web Links
:: Support Plans
:: Contact

Currency Server Security Analysis

The are no known security issues involving the default configuration of Currency Server, which includes a security sandbox to limit access to resources.

The following sections discuss various security-related aspects of Currency Server as they apply to version 6.x of the software.


Related Links

As with all server applications, it is recommended to use NTFS permissions to restrict write access to the software installation directory (e.g. "C:\Program Files\Cloanto\Currency Server"). Only administrators and the local system account should be able to write to this directory. If an intruder were to get write access to this directory (which would mean that the system has already been compromised), then malicious code could be launched with the privileges granted to the Currency Server services.

By default, Currency Server collects currency data from servers located on the internet. The location of the server(s) and additional details about the the collection procedure (e.g. manual or automatic) are configured via the Currency Server Manager user interface.

Clients may request data from Currency Server via COM (DCOM-compatible) and Web service (.NET/SOAP) interfaces. The methods and properties through which data is made available to COM and Web service clients provide read-only access to exchange rate information, conversion and localization functionality. All objects exposed in this way are read-only.

Currency Server can be configured to invoke FX feed filter executables files, client validation executable files, and custom action executable files. No such executables are invoked in the default configuration. All executables which may be run by the software must be stored inside the special directories which are part of the Currency Server security sandbox.

The loading and saving of configuration data files, the triggering of notification events, as well as the invocation of exchange rate data updates, are also available via an "Admin" object in the COM and Web service interface. Access to this object is disabled by default, and can be selectively enabled on one or both interfaces. Even when enabled, functionality is restricted by the Currency Server security sandbox.

Windows Installer

Some of the Windows Installer (MSI) options described in the documentation include the possibility to specify the "Log on as" settings of the "Currency Server" service. If a user is explicitly set, the specified service logon username and password may be temporarily stored as plain text, posing a potential security threat if a malicious user has access to the system. This is known to occur in the following two cases:

  • If the installation logging option is enabled, either explicitly (i.e. Windows Installer command line option) or as a system policy, then depending on the logging flags the log file may include the service logon details.
  • If a reboot is required to complete the installation (which is normally not the case), then the installation options (which include the service logon details) are stored in the system registry until the installation is complete.

These are known conditions which are also documented by Microsoft.

Protocols and Ports

The default data transport mechanism used by Currency Server to collect exchange rate data and to provide Web service functionality is HTTP (Hypertext Transfer Protocol), i.e. the same protocol used by browsers to access websites. This does not usually require any configuration changes in firewalls, proxy servers, routers and similar systems, and does not compromise in any way the security features which are in place on the network.

Currency Server normally collects currency information from the internet via HTTP over TCP port 80. Some FX feed filters (e.g. Oanda FXP) support connections via different protocols and ports.

The FX feed filters refer to the FX servers by host name, therefore requiring DNS client functionality for name resolution (usually TCP and UDP port 53 to and from port 53 and random port numbers greater than 1023). It is possible to manually edit the FX feed address or filter configuration to reference the servers by IP address rather than by host name, so that the software will run on systems with tighter security settings (e.g. where only port 80 may be open), however in this case it is strongly recommended to set up appropriate Notification options in order to be able to promptly correct any connection problems (e.g. a change of IP address).

The Web service uses SOAP as its communications protocol. SOAP sends and receives data over HTTP, and as such it does not introduce any new security issues at the transport level. Web service client requests are received and replied to via HTTP over TCP port 80, or as set in the Internet Information Services (IIS) configuration of the applicable website. Furthermore, since SOAP packets declare their "intent" by publishing interface and method names in the HTTP header, it is possible for firewalls to perform filtering based on this information (the SOAP specification states that implementations must verify that this information must match the corresponding headers and tags in the SOAP payload, otherwise the call should be rejected).

Distributed COM (DCOM) clients leverage the remote procedure call (RPC) subsystem to communicate across the network. By default, DCOM clients initially connect to the DCOM Service Control Manager (SCM) on port 135 for both TCP and UDP, after which port numbers are dynamically allocated, using port numbers greater than 1023. It is possible to restrict the range of ports that DCOM will use to assign to applications.


Both the Currency Server exchange rate data access protocols and the Web service interface support authentication both at the protocol level (e.g. HTTPS) and at the proxy/firewall level (e.g. Windows NT Challenge/Response Authentication).

Currency Data

With respect to the protocols directly supported by the software as distributed by Cloanto, the currency data being exchanged is always in plain text format, and contains no executable code that could host "virus" or other harmful programs.

COM Interface

The COM interface of Currency Server is not known to be able to expose the system to possible security risks, regardless of the identity of the requesting entity and its security privileges.

The COM interface is implemented as an in-process server DLL. It operates with the same privileges as the user accessing the interface. When accessed via DCOM, the server inherits the security privileges of the system default surrogate process.

Web Service Interface

The Web service interface of Currency Server is not known to be able to expose the system to possible security risks, regardless of the identity of the requesting entity and its security privileges. This interface is an optional installation feature (enabled by default), and is not required for the operation of the COM interface.

The Currency Server Web service is based on the Microsoft .NET Framework. The Web service does not directly serve client requests. Interaction with web service clients occurs via Internet Information Services (IIS).

JavaScript Interface

Currency Server can dynamically generate JavaScript code that makes available up-to-date currency properties and other functionality dedicated to dynamic web applications such as widgets and convert-as-you-type fields. This code is written as a file (via a Post-Update Action), or generated via the COM or .NET Export() methods.

Unlike the COM or Web service interfaces, the JavaScript functionality is exposed in full isolation from the Currency Server software (there is no communication flowing back from the JavaScript to the software).

The JavaScript data generated by Currency Server is not known to be able to expose either the host system or the client to possible security risks.

JSON Interface

The JSON (JavaScript Object Notation) export functionality exposes a subset of the currency properties that are available in the JavaScript interface.

As is also the case for the JavaScript output, the JSON functionality is exposed in full isolation from the Currency Server software (there is no communication flowing back to the software).

The JSON data generated by Currency Server is not known to be able to expose either the host system or the client to possible security risks. The general security considerations that apply to JSON, in particular those concerning the use of eval() rather than a JSON-specific parser such as JSON.parse(), also apply to the data generated by Currency Server.

Currency Server allows a prefix to be specified (i.e. JSON with Padding, or JSONP), which typically is the name of a callback function that serves the purpose of overcoming the "same origin policy" that normally limits XMLHttpRequest. Although the data written by Currency Server is generally not considered "sensitive", an inappropriate deployment of JASONP may leave the information exposed to access from unintended sites. Furthermore, if the data itself is compromised (i.e. written by an unintended application, rather than by Currency Server), and the eval() function is used to parse the data (rather than a JSON parser), this could result in a malicious JavaScript code injection attack.

Software User Interface

Currency Server services do not present a user interface (which may allow hostile code to be executed through the message queue associated to a window). All user interface components (e.g. Currency Server Manager, the messages window and the notification area icon) are executed at the level of the originating user.

Currency Server Security Sandbox

Currency Server includes a security sandbox to restrict access to internal objects and to limit interaction with the local file system. These measures were designed to prevent Currency Server from being reconfigured or otherwise used to further damage an already compromised system. Currency Server itself is not known to suffer from any security vulnerabilities.

The security sandbox includes the following measures:

  • FX feed filter executables, client validation executables and custom action executables must be stored inside the "Filters", "Validators" and "Actions" subfolder of the Currency Server installation folder, respectively. Any such files cannot be accessed or executed outside of these folders. This prevents other files (e.g. system files or other known files) from being accessed through Currency Server.
  • Log files written by Currency Server must have a name ending with ".log". The suffix is automatically appended if missing or different. This prevents abuse of the logging functionality in order to overwrite other types of files.
  • Configuration files read and written by Currency Server must have a name ending with ".cs-cnf". The suffix is automatically appended if missing or different. This prevents abuse of the configuration load/save functionality to overwrite or otherwise access files other than those intended.
  • The license key parameter provided by Web service clients is normalized (""", "/", "\" and ":" are converted to underscore characters) and truncated after 254 characters. This helps prevent possible buffer overrun, directory traversal and other command line argument exploits when the handling of license key validation is performed by external code (not under the control of Currency Server).
  • The URLs which are passed to external FX feed filter executables are truncated at 254 characters. This helps prevent possible buffer overrun exploits when the initial processing of currency data is performed by external code (not under the control of Currency Server).
  • Standard objects exposed via the COM and Web service interfaces are read-only.
  • Access to administrative objects (loading and saving of configuration settings, and invocation of exchange rate updates and notification messages) via the COM and Web service interfaces is disabled by default. Configurations loaded via this administrative functionality remain subject to the restrictions of the security sandbox.
  • Sample code is not distributed and installed with Currency Server, but rather is available for separate installation from the Currency Server website.
  • All executable files which are part of Currency Server are digitally signed with Authenticode. Currency Server was designed to be installed and run on systems where policies prohibit the execution of unsigned code.

Worst Case Scenario

The following worst case scenario is entirely hypothetical and implies that the system has already been compromised.

Currency Server includes two services, "Currency Server" and "Currency Server Messenger", which may run with system and/or administrative privileges. If an intruder were to have write access to the Currency Server installation directory it would be possible to replace the service executable files and gain the same privileges. Similarly, if Currency Server was configured to run external executables (which by default it is not), and if an intruder had access to the security sandbox directories (which are subdirectories of the Currency Server installation directory) then Currency Server could be exploited to run malicious code as a user having more privileges than those which the intruder already had.

The above can be prevented by properly securing the Currency Server installation directory as recommended at the beginning of this article. As a minimum, NTFS permissions should be such that write access is denied or not allowed for the Everyone group. Ideally, write access should only be allowed to administrators and to the local system. If NTFS permissions and additional policies are not already in place to protect the entire Program Files directory, you should consider questioning whether your entire system is properly secured in the first place.

Software Director

The Currency Server installer includes the optional Software Director component to check for software-related news and updates. After explicit confirmation, Software Director loads its data from the internet via HTTP over TCP port 80. No information about installed applications is sent to the server. Nothing is ever installed without explicit user request or confirmation. The software is completely idle between checks.

Additional Keywords: hack, hacker, crack, cracker

© 1998-2021 Cloanto Corporation. All rights reserved.     Legal     Privacy