SQL Injection Attack

  • Hi All,

    An attempted SQL injection attack was made on our DB using the below code

    This was appended on to the query : AND UNICODE(SUBSTRING((SELECT TOP 1 ISNULL(CAST(MyDataBase..sysusers.name+CHAR(46)+MyDataBase..sysobjects.name AS NVARCHAR(4000)),CHAR(32)) FROM MyDataBase..sysobjects INNER JOIN MyDataBase..sysusers ON MyDataBase..sysobjects.uid = MyDataBase..sysusers.uid WHERE MyDataBase..sysobjects.xtype IN (CHAR(117),CHAR(118)) AND MyDataBase..sysusers.name+CHAR(46)+MyDataBase..sysobjects.name NOT IN (SELECT TOP 0 MyDataBase..sysusers.name+CHAR(46)+MyDataBase..sysobjects.name FROM MyDataBase..sysobjects INNER JOIN MyDataBase..sysusers ON MyDataBase..sysobjects.uid = MyDataBase..sysusers.uid WHERE MyDataBase..sysobjects.xtype IN (CHAR(117),CHAR(118)) ORDER BY MyDataBase..sysusers.name+CHAR(46)+MyDataBase..sysobjects.name) ORDER BY MyDataBase..sysusers.name+CHAR(46)+MyDataBase..sysobjects.name),1,1))>64 AND (4372=4372)

    Having a dig around on the internet i found this code originates from the following SQL injection Testing Project : http://sqlmap.org/

    We have rectified the frontend code to stop the SQL injection

    What could they have gained from this?

    Thanks

    B

  • It seems to me the attack aimed at obtaining the database schema definition.

    If the application is vulnerable to sql injection, the attacker could have gained access to anything.

    -- Gianluca Sartori

  • I thought as much. Is there a way to deny the public role read access to system tables?

  • Rather focus on making your app injection-proof.

    They wouldn't have used public for this, they'd have been using whatever the application's account is, since it's a query exploiting the application's willingness to run untrusted input.

    All queries of that form would have got them is a list of the tables in the database, probably done as preparation for a more targeted attack to obtain useful-looking data.

    You do have all sensitive data (passwords, credit card numbers, account numbers, social security numbers, etc) stored encrypted, right?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • GilaMonster (10/28/2014)


    Rather focus on making your app injection-proof.

    They wouldn't have used public for this, they'd have been using whatever the application's account is, since it's a query exploiting the application's willingness to run untrusted input.

    All queries of that form would have got them is a list of the tables in the database, probably done as preparation for a more targeted attack to obtain useful-looking data.

    You do have all sensitive data (passwords, credit card numbers, account numbers, social security numbers, etc) stored encrypted, right?

    I know its not the public role, but the app user has this role by default which grants view access to system tables.

    I have tried to deny view to sys tables on the user by running this script but it doesn't seem to work?

    DENY SELECT On SCHEMA::sys To my_user

    DENY SELECT On SCHEMA::INFORMATION_SCHEMA To my_user

    All users details are encrypted. We always code our front end queries correctly to stop SQL injection, its just one query that slipped through as it wasn't using the correct function.

    Thanks

    B

  • Even if you're able to do that, there are other ways they could determine the schema, harder, but not impossible. Focus on making sure your queries are injection-proof (no concatenating of input into strings which then get executed), possibly using stored procs and denying select on all user tables.

    Attackers knowing the schema is not the problem, them being able to use that knowledge to obtain or change data is.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Looks like this is coming from sqlmap (sqlmap.org), automated injection tool.

    😎

  • Eirikur Eiriksson (10/28/2014)


    Looks like this is coming from sqlmap (sqlmap.org), automated injection tool.

    😎

    Yep... this is what i mentioned in my original post.;-)

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply