Lucene search

K
packetstormEric StevensPACKETSTORM:21979
HistoryJan 23, 2000 - 12:00 a.m.

omnis.txt

2000-01-2300:00:00
Eric Stevens
packetstormsecurity.com
24
`  
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.  
  
  
-Eric Stevens  
  
hope this helps  
`