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.
Overview
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.
Authentication
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 |
