Bugtraq mailing list archives

FW: MS Access 'known database attack'


From: Matt_Barrie () OTI COM (Matt Barrie SYD)
Date: Wed, 9 Jul 1997 20:19:07 -0600


Looks like another bad implementation of something that should have been
more secure:

On Sun, 6 Jul 1997, Mark Rosen wrote:

[Included message below]

I have examined the encryption on MS Access (v 2.0) and found that it was=
=20
really easy to break without ever having to determine the key.  I wasn't=20
aware that it was RC4 based.  During my examination of it, I found it=20
behaved as a stream cipher where the stream was XORed with the database.

MS Access databases grow in 2K increments, so it makes since that=20
everything is done the way described below.

However, encrypting with MS Access has a major flaw: It does not ask you=20
for a password!  You might expect that, like almost every other thing=20
with encryption, you would be prompted for a password.  In effect the=20
same key is used for encryption and decryption.

The method to break:
 - Create a known database which is at least as large as the database you=20
are trying to break.
 - Encrypt it.
 - Find the XOR between the known database and its encryption.  This is=20
the key stream.
 - XOR the key stream against the target database you are trying to break.

So there is no need for a brute force attack.  MS can use a 900,000+ bit=20
key and it won't matter.  :)

As a result, the encryption is a thin layer on top of the pseudo-security=
=20
objects which Access has.  Good enough to keep people from simply walking=
=20
through the database with DEBUG, but it isn't enough for real security.

 -Giff

giff () uu net


[relevant inclusion]

    I recently had cause to investigate the cryptography used in
    one of the applications of a very popular office suite, released
    this year. A password recovery specialist I spoke to claimed that=
=20
    the crypto used was 40-bit RC4! If this is true, it may apply to
    all of the applications of that suite, and thus the apps are
    susceptible  to brute force attacks of quite modest scale - ones
    which may be undertaken in a small office in a relatively short
    time.
=20
    Producing key search apps which can brute the crypto in this
    suite would force the manufacturer to answer as to why it chose
    such poor cryptography, and produce a stronger (albeit currently
    unexportable) version. It would also light a fire under the=20
    manufacturer to lend it's not inconsiderable weight in the=20
    export battle.
=20
=09Microsoft Access uses 32-bit encryption (RC4 I assume... not sure). Th=
is
is ripe for the picking! Giggle. Most large corporations use an Access
database. Here's the KB article:
=20
Knowledge Base
=20
=20
=20
INF: How Microsoft Access Uses Encryption
=20
Article ID: Q140406=20
Creation Date: 29-NOV-1995
Revision Date: 20-SEP-1996=20
=20
The information in this article applies to:=20
=95Microsoft Access versions 1.0, 1.1, 2.0, 7.0=20
=20
=20
=20
=20
SUMMARY=20
=20
=20
Advanced: Requires expert coding, interoperability, and multi-user skills=
.=20
=20
This article discusses how encryption is used in Microsoft Access.=20
=20
=20
=20
MORE INFORMATION=20
=20
=20
Encryption enables you to prevent anyone from using a utility program or
word processor to read and write data in a Microsoft Access database (.md=
b)
file. This feature is different from Microsoft Access security (which set=
s
user and group permissions on database objects); its sole purpose is to
make a database indecipherable by a file or disk editor.=20
=20
Microsoft Access uses an RC4 encryption algorithm with a 32-bit key from
RSA Data Security Incorporated. If you are creating an international
application, this algorithm is acceptable for export outside of the Unite=
d
States (according United States export laws) because the key is less than
40-bits.=20
=20
When you encrypt a database, all objects (tables, forms, queries, indexes=
,
and so on) are affected because encryption is implemented at the page-
level and not at the data-level. Microsoft Access encrypts a database in =
2K
(kilobyte) pages, regardless of the data stored in a page. Each encrypted
page is assigned a unique 32-bit key.=20
=20
=20



Current thread: