Vulnerability

    Omnis

Affected

    Omnis

Description

    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.