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 <enigmaat_private>
http://netninja.com/papers/ingenium/
-----------------------
OVERVIEW
-----------------------
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 <enigmaat_private>
Vendor Contacted: 2002-10-07, no response
Publication Date: 2002-10-14
Company: Click2Learn
Company URL: http://home.click2learn.com/
-----------------------
BACKGROUND
-----------------------
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.
-----------------------
SEVERITY
-----------------------
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.
-----------------------
ADMINISTRATOR PASSWORD HASH VISIBILITY
-----------------------
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.
-----------------------
ADMINISTRATOR PASSWORD HASH DECRYPTION
-----------------------
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:
http://sourceforge.net/projects/cryptoslam/). 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:
9'$%100'%6
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.
-----------------------
USER PASSWORD HASH VISIBILITY
-----------------------
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).
-----------------------
SOLUTION
-----------------------
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 =-
This archive was generated by hypermail 2b30 : Tue Oct 15 2002 - 12:21:33 PDT