RE: FUD - was FAX a virus

["Craig Wright" <cwright () bdosyd com au>]

To address this more fully and technically, I have included the
following below. Security is a risk function as I have stated time and
again. Technically infeasible attacks with a low likelihood and lower
impact are way down on the list of items to be concerned with.

In relation to the sending of faxed data, being OCR'd into a database, I
will address the following cases.
1, Oracle:
1.1     The TNS listener
        The Oracle TNS listener generally listens on TCP Port 1521
(although depending on the version this may be different eg TCP 1526).
In Oracle versions prior to 10g, the TNS listener could be administered
remotely without a default password.  However, there is no feasible
manner or method in which a fax stream could be used to administer the
service.  Further, it is infeasible to suggest that either compiled code
or hex values could be fed to this service using fax based stream
import. 
1.2     The Oracle intelligent agent
        This proprietary protocol listens over SNMP, TCP ports 1748,
1808 and 1808. There is no known feasible manner of injecting binary
data into this stream using a text processing stream such as an OCR
engine connected to a fax line.
        Even where the service is configured, there is no known or
feasible manner in which an ALTER USER command could be passed to the
service from that stream.
1.3     Key system Privileges
        It is in feasible to expect that a fax stream could be used to
execute any modifications to the AUD$ tables.  Even including inquiry
such as:
                SELECT  O.NAME FROM SYS.OBJ$ O, SYS.TAB$ T
                WHERE T.AUDIT$ LIKE '%A%'
                And O.OBJ# = T.OBJ#
Will fail to be able to perform the necessary update processes on the
database.

The standard attacks against the listener cannot return database SIDS to
the attacker. CONNECT_DATA commands designed to initiate log file
poisoning cannot be initiated to the TNS from the text input stream used
in this example.

1.4     PL/SQL
        Although PL/SQL may be used interactively to create stored
procedures, functions, triggers and objects in Oracle, there is no
manner in which a remote attacker could gain the feedback necessary to
ensure that this attack could function.  Neither would they have any
feedback of the system errors.
        To attack Oracle over a data stream such as was mentioned in the
initial posting, the attacker would need-to-know not only detailed
database structures, but the authorisation and authentication protocols
used within the database.
        Even given this information, any attack based on this would be
difficult at best and still unlikely to achieve more than a denial of
service at best.  A combination of insider knowledge and advanced Oracle
developer skills could lead to some possibility of an alteration of
certain selected fields when one makes an assumption that either the
database is receiving data from the OCR stream with Oracle DBA
privileges or in the least with table privileges.
        This attack would require insider knowledge as the attacker
would not be able to get feedback as to the names used and assigned to
the entities or relationships within the database. This is the case even
in streams associated with the AUTONOMOUS_TRANSACTION used by the
injection.

Running operating systems commands in this manner would be close to
impossible.  Trying to inject a function over the stream such as:
                Exec oracmd.exed ('net user cracker password /add',);
Would be close to impossible, as would any other attack that requires
extproc to load an external program or executable.

I can see no way in which OS Commands could be attacked over the stream
through the DBMS_SCHEDULER. Although this is a common attack over
networks, it requires interactive access.  There is no manner of
achieving interactive access or necessarily even sequential access
through the input stream provided by the fax server.

With Oracle, Java can be used to access the file system.  The problem
with the fax stream however is that there is no way of maintaining a
constant session.  Each fax will be sent and processed as an individual
and separate function. Similarly, UTL_TCP could not be accessed in this
manner.  The RPC server may allow WRITE_TEXT functions to directly
access the socket, and there is even a simple TCP port scanner which can
work within Oracle using UTL_TCP; again it must be stated that there is
no manner in which this can be accessed through an OCR'd text stream.

2. DB2:
        We have to ignore any of the network based attacks for DB2. Even
assuming a default install of DB2 with the two instances DB2-0 and
DB2CTLSV-0, and listening on TCP ports 50000 and 50001, there is no
valid attack in which we could either find the DAS let alone query it.

There are buffer overflows in DB2 where the system is unpatched and
poorly configured. The following procedures and functions have all been
known to suffer from buffer overflow vulnerabilities:
        XMLClobFromFile
        XMLVarcharFro,mFile
        REC2XML
        GENERATE_DISTFILE
        ..... etc

A SELECT statement such as:
SELECT db2xml.xmlvarcharfromfile ('c:\boot.ini',
'AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOO' ||
chr(204) || 'PPPPQQQQRRRRSSSSTTTTUUUUVVVVWWWWXXXXYYYYZZZZ') from
sysibm.sysdummy1
Could be attempted in order to try to overflow the stack-based buffer.
Even in this case however the attacker would need to be able to gain
interactive access to such that they could connect to the
breakpoint(0xCC) and execute it.

Assuming both a poor install of the database and no patching, the
attacker still would not be able to access the system to make use of a
CALL function or even execute the CREATE WRAPPER command.

XML function attacks such as XMLClobFromFile a potentially dangerous on
a misconfigured DB2 system However these cannot be exploited over the
fax stream.

3.      Other
Attacks against Informix using the stored procedural language (SPL) and
the ability to run arbitrary commands with SPL are not feasible over an
intermittent and non-interactive input stream.

Java-In-ASE attacks against Sybase will fail when the attacker is remote
and unable to interact with the stream.

4.MSSQL
MSSQL sever processes and ports are not able to be accessed over the
OCR's fax stream. Even if the system is abysmally configured, guessing
the SQL stored procedures to make this attack will not be likely.
\x08 Leading Heap overflow attacks do not function on text streams
\x0A Leading Byte network attacks do not function over text streams.
Client overflows will require access to the OCR engine directly.
Something that is not available in the supplied example.

For a SQL Injection attack using the query;
SELECT * FROM users WHERE username = '[username]' AND PASSWORD =
'[password]';
You would need to have permission set to run this. You need to have some
form of access to the record. You need to be able to call back what you
have listed and have the database execute it. But being that you are not
able to set a user supplied cookie, that it is unlikely that you have
knowledge of the internal database structure etc. This is again
infeasible.

In the case where the data is available to the Internet and your have
all the privileges to run the injected code, there is no reason to send
the attack over the fax stream. The Injection would more than likely be
easier to enact using the web interface, making the fax attack redundant
and thus an unlikely source being that if both the fax and web are
available and vulnerable to the attack, it would be mad to attack a
non-interactive stream with a more difficult attack when the easy option
is available and necessarily a part of either attack.

If you read the database attacks listed in the paper:
"Violating Database-Enforced Security Mechanisms" (last viewed 04th Mar
2007)

Http://www.ngssoftware.com/papers/violating_database_security.pdf
By Chris Anley, you will note a number of attacks against the MS SQL
server, none of which will help with the case for attacking the fax
stream.
So to conclude...

Any attack which is being suggested requires that the attacker also be
able to access the Database server (even through another server) using
an interactive method for the attacker to obtain information. This could
be as was suggested a SQL injection.

However, in all cases where this is possible, the attack is also
available directly over the network and the fax stream is the more
difficult attack and more noticeable attack. Given this, and that the
network component of an attack is inclusive, the likelihood of the fax
being used to launch a part of an attack is low at best. The added
difficultly in doing this makes the impact low. The resultant risk in
below minimal.

Regards,
Craig

-----Original Message-----
From: Craig Wright
Sent: Tuesday, 6 March 2007 9:02 AM
To: 'Scott Ramsdell'; security-basics () securityfocus com
Cc: alcides.hercules () gmail com; wesley () mcgrewsecurity com
Subject: RE: FUD - was FAX a virus

Scott has stated - "Is that a risk?  You can determine that by
evaluating how the Windows process operates.  I'm assuming it's a
service on your box.  You will want that service to launch with an
unprivileged user account, not the local system account."

This is not a risk. This is a possible vulnerability. A risk is the
chance that a threat will exploit a vulnerability.

Thus again as was stated, this needs to be a risk based response. The
threat needs to be considered. The impact needs to be taken into
account.

Scott, Yes, as you state you are making assumptions. You also fail to
read the emails. Assumptions are dangerous and it is always better to
clear the issue and not make assumptions.

Regards,
Craig



Liability limited by a scheme approved under Professional Standards Legislation in respect of matters arising within 
those States and Territories of Australia where such legislation exists.

DISCLAIMER
The information contained in this email and any attachments is confidential. If you are not the intended recipient, you 
must not use or disclose the information. If you have received this email in error, please inform us promptly by reply 
email or by telephoning +61 2 9286 5555. Please delete the email and destroy any printed copy. 

Any views expressed in this message are those of the individual sender. You may not rely on this message as advice 
unless it has been electronically signed by a Partner of BDO or it is subsequently confirmed by letter or fax signed by 
a Partner of BDO.

BDO accepts no liability for any damage caused by this email or its attachments due to viruses, interference, 
interception, corruption or unauthorised access.