Ingenium Admin Password Vulnerability

Type securityvulns
Reporter Securityvulns
Modified 2002-10-16T00:00:00


The vendor was contacted, but I have not received any response (other

than an autoresponder) over the past week... -E

Security Advisory -- Click2Learn's Ingenium LMS Brian Enigma <>


Product: Ingenium Learning Management System Versions: Known to work on v5.1 and v6.1. It is likely that all versions are vulnerable. Click2Learn's Aspen LMS has not been tested. Vulnerabilities: (1) Administrator password, public visibility (2) All user passwords visible with database SELECT access Affected Systems: All Ingenium installations visible to the public internet (do a Google search for "Ingenium Web Connect") Reporter: Brian Enigma <> Vendor Contacted: 2002-10-07, no response Publication Date: 2002-10-14 Company: Click2Learn Company URL:


I work for a company that uses Click2Learn's Ingenium Learning Management System. Part of my job involves locating, evaluating, and fixing security vulnerabilities in an assortment of products. A few things about Ingenium have recently caught my interest. First, a user on the public internet can retrieve the administrator's password hash. Second, the password hash is easily reversible. Third, user passwords (not as easily accessible, as they are stored in a Microsoft SQL database) are also hashed using the same reversible algorithm.


This is a very serious problem. Any site using Ingenium as their learning management system is vulnerable. Since the HTML title used by the frameset in all Ingenium installations is "Ingenium Web Connect," a Google search will reveal quite a number of vulnerable sites. In theory, a user can log into any of these sites as an administrator using these vulnerabilities.


Ingenium stores a number of configuration parameters in a Microsoft SQL database. It also must store a few values on the local system, as it needs to know several important values before being able to access the database--for instance, the location, login, and password for connecting to the database. Basically this is the database "bootstrap" information. In examining the file more closely (it is called [install directory]/config/config.txt), I also noted that the application's administrator password, as a hashed value, is also stored in this file. Even further inspection of the file location, directory structure, and IIS installation shows that the file is located in a folder under the htdocs web directory! This means that a simple HTTP request can grab the config file!

In most default installations, replacing the "default.asp" file name in the URL, when looking at the Ingenium home page, with "config/config.txt" will retrieve the file, including the administrator password hash. This is just plain silly! Most web programmers with any amount of training or experience know that you need to store your data out-of-band from the documents/programs. Raw data files should not be web accessible.

While this particular vulnerability is a known issue (see Click2Learn's Knowledge Base article Q1254), it is brushed off as advice for the paranoid. Personal observation has not shown a single site that hides this configuration file. Utilizing this vulnerability leads us to the importance of the next one.


You may or my not already know that the best way to store passwords in a persistent data store is with a one-way hash function. In fact, this is how all Unix systems work. You cannot reverse out a password from a password hash without a lot of brute force--in most cases, so much number crunching that the process is not worth it. You may also know that one of the worst ways to store passwords (or any data) is with XOR "encryption." Two large enough samples and a minute of math will give you a pretty darn good idea of what the "encryption" key is. An even less secure method of encrypting data is with a secret decoder ring. In fact, most newspapers have a "Cryptogram" section with the Sunday comics that lets you solve these as a diversion (shameless self-plug: It is called a Caesar cypher and is made mildly more challenging/annoying by varying the offset depending on the position of the letter in the message.

I'll give you three guesses what Ingenium uses to store passwords, but the first two guesses cannot be "Caesar Cypher." Yes, Ingenium uses about the same encryption as a Flash Gordon Secret Decoder Ring. Implementation would have been an exercise left for the reader, but it was a slow Friday, so the Java source will be supplied with this advisory. Passwords are not case sensitive--it would appear they are converted to uppercase before being "encrypted." The example code will only decode letters and numbers, no special symbols, but the theory still applies.

In this particular cipher implementation, the key is:


This key repeats if the plaintext is longer than ten characters. To decode a given piece of cyphertext, you simply take the hex value of the cyphertext character and subtract the hex value of the key character in the same position, giving you a plaintext hex characters. Note that the number space wraps between 0x20 and 0x7D. Just in case you are not following, an example is in order. Let us say, as an example, that the password line in config.txt is "General\LocalAdmin=|smh|#'hp{9'$%10". The decoding goes something like this:

cypher: |smh|#'hp{9'$%10 subtract key: 9'$%100'%69'$%10

You will note that only the first ten characters are significant. The rest are nulls in the plaintext, giving the cyphertext character the same value as the key character at that position. Worked out in hex, this becomes:

cipher: 7c 73 6d 68 7c 23 27 68 70 7b subtract key: 39 27 24 25 31 30 30 27 25 36 ----------------------------- equals: 43 4c 49 43 4b 51 55 41 4b 45 in ASCII: C L I C K Q U A K E

You will notice that the "Q" and "U" wrapped down below 0x20, and back around to 0x7D. Experimentation also shows that the numeric digits are somehow offset such that zero (normally 0c30) is mapped to lowercase n (0x6E). Symbols are also mapped into this area, but have not been completely explored.


This issue is not as severe as the administrator password. A user will need SELECT access in the database to utilize this vulnerability. A simple SELECT * FROM IWC_USR will give you a list of logins and their corresponding password hashes. The password hash employs the same algorithm as above, only you will need to remove the "$" at the beginning of the password hash and use a slightly different key (the characters "i0)'0+7/" repeated).


A good long-term solution would be a software update from Click2Learn that moves the files in the "config" directory (and possible others) to a path outside of the web documents. This requires engineering time and QA resources. Also, this solution may not apply to entities that purchased the Ingenium LMS without a support contract.

A simple and immediate solution would be to block the config.txt file from being downloadable. Configuring IIS to block access to this directory can achieve the desired result. This is a simple operation. First, open the Internet Management console. Next locate the "config" web folder. Right-click on it and select "Properties." Uncheck the "Read" and "Index" checkboxes and click "OK."

-= QED =-