Omnis Weak Encryption - Many products affected

[Eric.Stevens () AVENTIS COM (Eric.Stevens () AVENTIS COM)]

I'm not sure of the complete extent of applications written in Omnis, but
from what I understand, it's a multi-platform Rapid Application Development
environment.  Essentially, from what I understand (having no personal
experience with the product), you create one program in Omnis, and it's
portable to Win, Mac, and Linux.  I am admittedly rather uninformed of the
full uses of Omnis, but what I do know is that it can provide a interface to
databases of differing formats, including ODBC connections.  Please, some of
what I say is speculation based upon facts that I do have about the
software, if someone can shed more light on the subject, do so.  Sadly I
have little time to really work with the Omnis application point.

One of the features that Omnis provides for attaching to the database is the
ability to encrypt fields, and obscure them from prying eyes.  In actuality,
this encryption is extremely weak, and I /accidentally/ discovered the
encryption technique in attempting to help a company that develops with
Omnis strengthen their program security wise.  The specifics of the weakness
of this encryption is discussed at the end of my post.

For the past two weeks, I've been helping Clients and Profits (C&P),
developer of a job tracking and billing system targeted to marketing
corporations, to fix a security bug in their program wherein any user with
access to the database (which was any person who was allowed to log in to
the database, as well as potentially others) could gain the passwords of all
users, including the managerial accounts, thus exposing vital information
such as job estimates and employee salaries.  It was only recently that C&P
divulged to me that they used Omnis to develop their application, and thus
my lack of experience with Omnis.  Details of the C&P vulnerability are at
the end of my post.

A week ago I put in a request to Omnis for technical support on this issue,
so that I could help them come up with a more effective encryption technique
for encrypting data before storing to the database.  As of yet, I have not
even received a "Thank you for your request" email.

-----The Omnis problem-----

The technique used by Omnis to "encrypt" data is weak enough that it can
easily be decrypted with a hand calculator, and for those with extensive
hexadecimal experience, and good ASCII knowledge, performed in your head.
Just for a bit of fun, bugtraq readers may find it enjoyable to see how
quickly they can figure out the encryption technique before reading the rest
of my post, call it Eric's game of the day.
Here is a password: encrypted
Here is its encrypted form: bec4b3b9d2c6c4acbd

If you want to play with that, don't read any farther until you've figured
it out (it won't take you long)

It is almost immediately noticeable that the encrypted password is actually
a hexadecimal sequence, or very likely that it is.  There are no letters
above E, and especially, none above F.  If you break it down by hexadecimal
pairs, and line up each with a letter of the original password, you get
 e  n  c  r  y  p  t  e  d
 BE C4 B3 B9 D2 C6 C4 AC BD
Seems to be a good match for the number of letters.  Let's get numeric
values for each now:
101 110  99 114 121 112 116 101 100
190 196 179 185 210 198 196 172 189
If you're reading this with out having tried to decrypt it, you should
almost at this point have accidentally decrypted it.  If you take the
difference of each of those value pairs, you get
89 86 80 71 89 86 80 71 89
or 89 - (3 * ((charpos - 1) mod 4))

To confirm that this wasn't just a fluke, I got ahold of three other
encrypted passwords to which I did not have the original value, and
successfully decrypted all three to their original values.

According to those with whom I've spoken on this matter which know more
about Omnis than I do, this is the only encryption option available.

-----The Clients and Profits Problem-----

The C&P vulnerability exists because core functionality of all versions of
their software aside from the most expensive SQL version (which attaches to
Oracle) requires a shared network path wherein the database sits, and this
is how all clients access the shared database.  Users must have full
read/write access to the database (which is in and of itself a very weak
design, there is no client/server role here) in order to access it.  Any
user with a hex editor needs only open the database and conduct a search for
the username for which they wish to gain access.  The password will be
contained within about 500 characters, and will easily stand out, unless a
very clever password is used.  In all versions prior to 4.02, the password
will be contained in plain text.  4.02 and later versions will have the
password encrypted in the method described above, making even the most
clever password easily distinguishable.

I had been working closely with Clients and Profits up until nearly the same
time that I attempted to communicate with Omnis regarding this issue.  At
that point, all my C&P contacts stopped responding to my via email or phone.

> From what I know of Omnis, this is a security threat to any applications
developed under Omnis which depend on it's encryption technique.