Thursday, April 19, 2012

SQL injection by truncation

This is an old attack technique. More details can be found at

http://msdn.microsoft.com/en-us/magazine/cc163523.aspx

https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Neerumalla.pdf

The question is “If I use quotename() or replace() or wrap all my SQL parameters, are my dynamic SQL statements still subject to SQL injection?

Even with quotename() or replace(), your dynamic SQL statements might be vulnerable to SQL injections due to truncations if you make these mistakes:

  1. The dynamics SQL is assigned to a variable whose buffer is not large enough. An attacker can force truncation by passing unexpectedly long strings to your stored procedure.
  2. The results returned by quotename() or replace() are saved into local variables whose buffer are not large enough. Those returned strings are truncated. An attacker can manipulate it to his advantages.

Here is the example showing truncation problems:

CREATE PROCEDURE sp_MySetPassword

@loginname varchar(128),

@old varchar(200),

@new varchar(128),

AS

DECLARE @login sysname

DECLARE @newpassword sysname

DECLARE @oldpassword sysname

-- the data stored in command might be truncated because its small size

DECLARE @command varchar(200)

-- the data stored in those temp variables might be truncated becuase

-- quotename() can return up to 258 characters and replace() can return up to 400 characters

SET @login = QUOTENAME(@loginname, '''')

SET @oldpassword = REPLACE(@old, '''', '''''')

SET @newpassword = QUOTENAME(@new, '''')

SET @command = 'UPDATE Users set password = ' + @newpassword

+ ' where username =' + @login + ' AND password = ' + @oldpassword;

EXEC (@command)


To avoid truncation issues, the best approach is to use parameterized queries in your stored procedures. If you must use quotename() or replace(), you can address those two issues: i) use a large buffer for the command variable or directly execute the dynamic T-SQL. ii) use large buffers for those temporary variables or call quotename() or replace() directly in dynamic SQL statement.

The above example can be fixed like this:


CREATE PROCEDURE sp_MySetPassword

@loginname varchar(128),

@old varchar(200),

@new varchar(128),

AS

DECLARE @command varchar(3000)

SET @command = 'UPDATE Users set password = ' + QUOTENAME(@new, '''')

+ ' where username =' + QUOTENAME(@loginname, '''') + ' AND password = ' + REPLACE(@old, '''', '''''');

EXEC (@command)

Tuesday, April 17, 2012

Search Engine Security for Google Chrome?

http://feedproxy.google.com/~r/zscaler/research/~3/4GiUgKrJpRE/search-engine-security-for-google.html

According to the vendor,
"Most hijacked websites used for Blackhat SEO check the Referer header and the User-Agent, to decide whether to redirect the visitor to a harmless spam page or to a malicious domain (Fake AV page, Blackhole exploit kit, etc.). By modifying these 2 headers when the user leaves a Google, Bing or Yahoo! search, Search Engine Security fools the hijacked site into thinking that the visitor is not a real user and therefore avoids redirection to the malicious content."

Are you serious? We all know it is trivial for the hijacked site to change their codes not to check those two headers. It is not really smart to try to fool bad guys and give good users a false sense of security.

Business logic Abuse for Nordstrom

http://silvertailsystems.wordpress.com/2012/04/17/business-logic-abuse-makes-headlines-nordstrom-defrauded-of-1-4m/

A very interesting story. Two brothers figured out a ways to abuse Nordstrom website by leveraging fatwallet. Their orders were rejected by Nordstrom and no transactions went through. However, Nordstrom still credit fatwallet for the transactions and pay them cash back for those fake purchases.

My feeling is that the cashback application of Nordstrom only check for transactions placed into the system assuming that those transactions are good transactions. However, some transactions turned out to "not-so-good" later and might be blocked by the company. The assumption is broken here.