Security Basics mailing list archives
RE: FUD - was FAX a virus
From: "Craig Wright" <cwright () bdosyd com au>
Date: Tue, 6 Mar 2007 12:43:51 +1100
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.
Current thread:
- RE: FUD - was FAX a virus Craig Wright (Mar 06)
- <Possible follow-ups>
- FUD - was FAX a virus Craig Wright (Mar 06)
- Re: FUD - was FAX a virus Robert Wesley McGrew (Mar 06)
- RE: FUD - was FAX a virus Craig Wright (Mar 06)
- RE: FUD - was FAX a virus Scott Ramsdell (Mar 06)
- RE: FUD - was FAX a virus Scott Ramsdell (Mar 06)
- Re: FUD - was FAX a virus TheGesus (Mar 06)
- Re: FUD - was FAX a virus Robert Wesley McGrew (Mar 06)
- RE: FUD - was FAX a virus Craig Wright (Mar 06)
- RE: FUD - was FAX a virus Craig Wright (Mar 06)
- Re: FUD - was FAX a virus Robert Wesley McGrew (Mar 07)
- RE: FUD - was FAX a virus Peter Denyer (Mar 07)
- Re: FUD - was FAX a virus Robert Wesley McGrew (Mar 07)
(Thread continues...)