+Note:  This is being released without Meridian or CERT approval.
Meridian has been dragging their feet and has shown no good intent
since I first tried to contact them.  My guess is that they will be
following all of my releases claiming I was uncooperative.  The only
information Meridian ever sought was my identity.  With my identity my
company assumed they would be revoking our license/contract as way to
quell the issue.
CERT - Assigned VU#120593

+Subject
Meridian Prolog Manager Username and Plain Text Password Disclosure

+Version
All Prolog Manager Versions (2007, 7.5 and pre 7.5 versions)

+Impact
Potentially High

+Description
When logging into a Prolog database all of the usernames and passwords
are sent to the workstation.  Depending on the encryption level of the
database cracking the passwords is trivial to annoying.

If you attempt a login with ANY username/password combination the
entire dataset of usernames and passwords is passed to the workstation
to parse and authenticate.  Any network sniffer can catch the dataset
to be cracked offline.

"No Encryption" databases passes every password in plain text as it is
returned from the sql query.
"Standard Encryption" databases use a rotational encryption to secure
the password as it is returned from the sql query.
"Enhanced Encryption" databases use the Standard Encryption and then
save it into a binary data field which is then returned from the sql
query.
No matter the encryption to the database the username is passed in
plain text inside the sql query sent to the server.

The Standard Encryption is easy to crack just by changing your
password to all of one letter and observing the data coming back in
HEX.   Building the key takes less than 30 minutes.

Enhanced Encryption is only slightly better since it takes the
Standard Encryption rotational keyed password and then sends it to the
database to be stored in a binary field instead of a text/varchar
field.  Even using this "encryption" once the password is over four
characters the first returned hash (16 HEX characters after a standard
lead in) is the same no matter what follows.  Making a rainbow table
of the first four characters would be annoying but takes less than a
day done by hand.  Once you had the first four characters making the
next four would take another day for any given first four, again by
hand.  So cracking any one account's 1-8 character password would take
1-2 days (1-12 characters would take 1-3 days and so on).  Given how
most people pick passwords, given the first four characters it would
be trivial to guess the rest.  I would also guess that once you had a
full set of the first four characters figuring out the patterned for
the binary storage would be trivial.  Building a script to build the
tables would not be difficult and would speed the process up to a
matter of hours to create a full 1-8 character rainbow table.

+Impact:
This would allow anyone to login as another user allowing them
increased privileges and/or removing or altering data which would be
logged as someone else.

+Workarounds:
No workarounds.

+Programming Fix:
The easy fix would be to only return the password for the username
entered.  This would still allow anyone to put in any username and
return the password for that user in the "database" encryption type.
The best solution would be to create a one way hash and send it to the
server for authentication, instead of allowing the workstation to do
the authentication.  This would eliminate known good passwords from
going across the network.

+Contact
May 29th 2007 - Email to Security and Support as well as
vendor/reseller, no response.
June 20th 2007 - Email to Security and Support as well as
vendor/reseller, no response.
August 20th 2007 - Email to Cert and SOC.
August 20th 2007 - Response from CERT - Assigned VU#120593
October 3rd 2007 - Meridian Requests contact info from CERT about who
found the issue.  This was at the last moment of the 45 day limit
allowed by CERT.
October 3rd 2007 - Respond to CERT letting them know they can release
prolog.disclosure@gmail.com as my contact info; no other info can be
released for fear of contract being nullified.
November 14 2007 - Asked CERT if anything is going on.  Response that
they would check with Meridian.
December 4 2007 - Asked CERT again if anything was going on.  They
again contacted Meridian.
December 5th 2007 - Meridian asked for contact info and other
information.  Responded with other information but not direct contact
information for fear of retaliation.  Other information included
specifics about how the issue was found.  Gave CERT option to release
this information with weekly release along side this release.  Gave
Meridian till December 11th to respond.
December 11th 2007 – No response from Meridian or CERT.  Public
notified through BugTraq, Full Disclosure, and Prolog Support Forums.