COMMAND
Omnis
SYSTEMS AFFECTED
Omnis
PROBLEM
Eric Stevens found following. Not sure of the complete extent of
applications written in Omnis, but from what it is to understand,
it's a multi-platform Rapid Application Development environment.
Essentially, from what is to understand (no personal experience
with the product), you create one program in Omnis, and it's
portable to Win, Mac, and Linux.
Eric was admittedly rather uninformed of the full uses of Omnis,
but what he do knew was that it can provide a interface to
databases of differing formats, including ODBC connections.
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
Eric 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 this advisory.
This is how the vulnerability was discovered. Eric was 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 him that they used Omnis to
develop their application, and thus his lack of experience with
Omnis. Details of the C&P vulnerability are at the end.
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, readers may find
it enjoyable to see how quickly they can figure out the encryption
technique before reading the rest of advisory, 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, Eric got ahold of three
other encrypted passwords to which he did not have the original
value, and successfully decrypted all three to their original
values.
However, Ben Greenbaum added following. The above seems to be
more of a formula to determine the difference between the key of
a byte and the key of the previous byte, meaning that formula
would have to be applied recursively for each byte from that
byte's position all the way back to the last byte position evenly
divisible by 4. After a bit of head scratching, he came up with
this, where 'u' is the unencrypted byte, 'e' is the encrypted
byte, and 'p' is the byte's position in the string mod 4, and
assuming the viewpoint of the attacker:
u = e - 89 + (( 3p^2 - 3p ) / 2)
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.
SOLUTION
Nothing yet.