Document id: 2004-003-meena
Revision: 0.2 11/16/2004 (wcw)
http://asg.web.cmu.edu/arch/ao/2004-003-meena
Early Disclosure was provided for the use of the BridgeTrak software for DSP [DSP-CALL-ED] at a Discovery Board meeting. There were enough concerns with the issues that this document was commissioned.
The focus of this document is to discuss the integration aspects and future risks of this approach.
Even in the case where usage is strictly internal, the use of direct Active Directory authentication is not ideal as this service is currently only provisioned to support legacy systems. [AD-PW-RESET] However, given the small number of internal users affected, this is not viewed as a show stopper.
BridgeAccess also requires an Active Directory userid and password to be entered. Given (a) we strongly recommend against web services that do not use pubcookie; (b) the use of Active Directory only authentication is only provisioned to support legacy services; (b) the vendor plans to have a "single sign on" feature implemented by (Q2'2005), we recommend investigating BridgeAccess again after the vendor deploys the new code.
The use of local accounts is an even worse option. We strongly recommend against the use of local accounts for campus people, especially where the local account matches the Andrew userid. Machines have been removed from the campus network as a result of this.
The system is a database backed application. The software (BridgeTrak) is run on individual PCs. All workstations have the same software; however, machines may be targeted as the "administrative" workstation.
The user of the Administrative workstation is authorized to perform additional tasks, such as pulling over email and syncing users and customers with data in Active Directory.
All authorizations are performed by the application using access groups defined in its database.
A diagram of the system is provided below:
The system also provides additional hooks for clients to submit requests: via a web interface (BridgeAccess) or by sending email. Note that customers are required to log in in order to have full use of the web interface.
BridgeTrak appears to have been initially designed as an application which manages all user information internally in its database. This makes sense if a domain is not available.
A recent software release provided Active Directory integration. This allows data in Active Directory to be sync'd into its database. Another feature was to allow password authentication to go against Active Directory instead of comparing it to a value stored in its database.
However, if the software is being run in the domain context, it does not need to have this additional password check. If a user is logged into a domain machine, then the user's identity has already been verified.
Similarly, within a domain IE and IIS have the ability to do "single sign on" so that domain credentials can be passed from a client machine to a web server without a password having to be entered again.
The vendor recognizes that their current Active Directory can be improved and the improvements should be easy. They project to have a "single sign on" solution available by Q2'2005.
There is also an additional add-on called BridgeWebLite. This software behaves similarly to BridgeAccess but it is for the DSP consultants and not the clients. From a system point of view, it did not seem that BridgeWebLite and BridgeAccess were significantly different and so anything that refers to BridgeAccess likely applies to BridgeWebLite.
This tool was developed as an interim measure with the intent of providing authentication to non-Kerberos down-level clients (e.g. Windows 98, Windows ME and Macintosh OS) for Windows 2000 Services File and Print Sharing. Because this service is intended to be a temporary solution, its use should be limited for accessing Windows 2000 File and Print Sharing services.We strongly recommend that departments migrate their users to Kerberos compatible clients (Windows 2000, Windows XP and Macintosh OS X). If you intend to use this authentication channel for other purposes (e.g. KDC trusts, Microsoft IIS Services, Microsoft SQL server, etc.) please contact Computing Services to examine other alternatives. It is the intent of Computing Services to eliminate this service as soon as acceptable alternatives are deployed, and hence we actively discourage the reliance upon this authentication method for departmental infrastructure initiatives.
The adoption of Kerberized services has not been as rapid as we would have hoped. As such there is activity underway in Technology Integration to revisit this. However, it is still at the Discovery stage so creating additional end-user dependence on the service will likely make any transition significantly more difficult and so is discouraged.
As such, any user who can run the BridgeTrak software has full access to the BridgeTrak database and thereby have full access to the BridgeTrak data.can read, change or modify any data via the SQL interface.
The vendor asserts that the Microsoft ODBC Oracle driver must be used instead of an ODBC driver from Oracle as the Oracle driver has concurrency problems.
If encryption does not occur then the userid and password of the database can be sniffed. This means that if a DSP consultant is using the software on a wireless network in the UC, then anyone nearby can compromise the password and thereby have full access to read, modify, or delete any data in the BridgeTrak database.
The vendor was not able to answer this issue; they said he hasn't come up before. If a definitive answer is required then further investigation and experimentation will be required.
A more significant problem is that the connection is not encrypted and so the userid and password can be sniffed on the network. By gaining access to the email account, an attacker can read, modify, or delete any incidents currently submitted.
The Security Office is also moving towards prohibiting applications that send clear text passwords.
The vendor expects to have this addressed in the 7.0 release which is slated for Q3'2005.
There is a security problem where the password may be the same as their Andrew password and now anyone who can read the database may be able to obtain the password. Given the security concerns of this database, this issue is magnified in this instance.
There is a general accounts management problem. By provisioning the account, you are now responsible for creating the account, changing passwords, deleting the account, etc. While this may not seem like a big deal, users tend to be confused when these exceptions occur and therefore call the Help Center which may result in further escalation and so you end up with a bunch of people wasting their time investigating a problem.
We assume (and require) that the following items be true:
[DSP-CALL-ED] Early Disclosure document for DSP
Call Tracking: [doc]
[DSP-CALL-REQ] Requirements listing for
DSP Call Tracking: [doc]
ChangeLog
11/16/2004 - 0.2 (wcw) - clarified 2.0 #2. Added 3.2 #8 based on kvd
feedback.
11/16/2004 - 0.1 (wcw) - Initial draft
Time Tracking
As DSP is a cost recovery organization, we are accounting for the time
spent on this consulting activity.
11/04/2004 - 1 hour - research using the vendor web site; requesting
clarification to information found there.
11/05/2004 - 1 hour - reading documents; clarification email
11/10/2004 - 1 hour - analyzing more installation documents
11/11/2004 - 1 hour - updating question list
11/12/2004 - 1 hour - obtained more documents; updated question list
11/15/2004 - 1 hour - phone conversations with vendor developers
11/16/2004 - 1 hour - base writeup
11/16/2004 - 1 hour - revisions
(c) 2004 Carnegie Mellon University. All Rights Reserved.