Unethical access to website’s databases hacking using sql injection
Download as PPTX, PDF7 likes57,932 views
The document discusses the critical importance of database security, highlighting how vulnerabilities, especially through SQL injection, can lead to significant data breaches and financial losses. It outlines methods of hacking databases, preventative measures, and emphasizes the necessity of robust security practices to protect sensitive information. Recommendations include using encryption, strong password policies, and regular audits to safeguard against attacks.
Unethical access to website’s databases hacking using sql injection
- 1. Unethical Access to Website’s Databases Hacking Using SQL Injection January 9, 2012 Satyajit Mukherjee Website-http://satyajit.page4.me
- 2. Overview • Introduction • Why database security? • How databases are hacked? • More on SQL Injection • How to protect against attacks? • Conclusions • References
- 3. Introduction • By one estimate, 53 million people have had data about themselves exposed over the past 13 months. (InformationWeek, 03/20/2006) – This is old news, right now the number is > 100 million !!! • Data theft is becoming a major threat. • Criminals have identified where the gold is. • In the last year many databases from fortune 500 companies were compromised. • As we will see compromising databases is not big deal if they haven't been properly secured.
- 4. Introduction Rank # of Records Entity Date of Incident Type of or People or Report Incident TJX, Inc. 2007-01-17 Hack 1 94,000,000 2 90,000,000 TRW 1984-06-22 Hack 3 40,000,000 Card Systems 2005-06-17 Hack 4 30,000,000 Deutsche Telekom 2008-11-01 Exposure U.S. Department of 5 26,500,000 2006-05-22 Stolen Laptop Veterans Affairs HM Revenue and Customs / 6 25,000,000 2007-10-18 Lost Tapes TNT 7 18,000,000 Auction.co.kr 2008-02-17 Hack National Personnel Records 8 18,000,000 1973-07-12 Fire Center 9 16,000,000 Revenue Canada 1986-11-23 Theft Bank of New York Mellon / 10 12,500,000 2008-03-26 Lost Tape Archive Systems Inc. Note: As of April 10, 2009 Date: PogoWasRight.org
- 5. Introduction • • Want to be more scared? • –Chronology of Data Breaches • http://www.privacyrights.org/ar/ChronDataBreaches.htm • –Some estimated money losses • • ChoicePoint: $15 million • • B.J.'s Wholesale: $10 million • • Acxiom: $850,000 • • Providence Health System: $9 million
- 6. Why Database security? • Databases are were your most valuable data rest – Corporate data. – Customer data. – Financial data. – etc. • If your databases don't work then your company won't work – Try to do a quick estimation of how much money you will • lose if your databases don't work for a couple of hours, a day, etc. • If your databases are hacked then your company can • run out of business or you can lose millions.
- 7. Why Database security? • You must comply with regulations, laws, etc. – Sarbanes Oxley (SOX). – Payment Card Industry (PCI) Data Security Standard. – Healthcare Services (HIPAA) . – Financial Services (GLBA) . – California Senate Bill No. 1386 . – Data Accountability and Trust Act (DATA). – Etc.
- 8. Why Database security? • Database vulnerabilities affect all database vendors – Some vendors (like Oracle) are more affected than others. • On 2006 Oracle released 4 Critical Patch Updates related to database servers – Fixed more than 20 remote vulnerabilities!!! • On 2007 there are still > 50 unpatched vulnerabilities on Oracle Database Server – No matter if your server is up to date with patches, it still can be easily hacked.
- 9. Why Database security? • Perimeter defense is not enough – Databases have many entry points • Web applications • Internal networks • Partners networks • Etc. • If the OSs and the networks are properly secured, databases still could be: – Misconfigured. – Have weak passwords. – Vulnerable to known/unknown vulnerabilities. – etc.
- 10. How Databases are hacked? • Password guessing/bruteforcing – If passwords are blank or not strong they can be easily guessed/bruteforced. – After a valid user account is found is easy to complete compromise the database, especially if the database is Oracle. • Passwords and data sniffed over the network – If encryption is not used, passwords and data can be sniffed • Exploiting misconfigurations – Some database servers are open by default • Lots of functionality enabled and sometimes insecurely configured.
- 11. How Databases are hacked? • Delivering a Trojan – By email, p2p, IM, CD, DVD, pen drive, etc. – Once executed • Get database servers and login info – ODBC, OLEDB, JDBC configured connections, Sniffing, etc. • Connect to database servers (try default accounts if necessary). • Steal data (run 0day and install rootkit if necessary). • Find next target – Looking at linked servers/databases. – Looking at connections. – Sniffing. • Send encrypted data back to attacker by email, HTTPS, covert channel, etc.
- 12. How Databases are hacked? • Exploiting known/unknown vulnerabilities – Buffer overflows. – SQL Injection. – Etc. • Exploiting SQL Injection on web applications – Databases can be hacked from Internet. – Firewalls are complete bypassed. – This is one of the easiest and preferred method that criminals use to steal sensitive information such as credit cards, social security numbers, customer information, etc.
- 13. How Databases are hacked? • Stealing disks and backup tapes – If data files and backed up data are not encrypted, once stolen data can be compromised. • Insiders are a major threat – If they can log in then they can hack the database. • Installing a rootkit/backdoor – Actions and database objects can be hidden. – Designed to steal data and send it to attacker and/or to give the attacker stealth and unrestricted access at any given time.
- 14. More on SQL Injection • What is SQL Injection? • SQL Injection Attack • SQL Injection Prevention • Cross-Site Scripting
- 15. What is SQL Injection? • SQL injection is a basic attack used to either gain unauthorized access to a database or to retrieve information directly from the database. • SQL injection can occur when an application uses input to construct dynamic SQL statements. Successful SQL injection attacks enable malicious users to execute commands in an application's database. • Many web applications take user input from a form. Often this user input is used literally in the construction of a SQL query submitted to a database. A SQL injection attack involves placing SQL statements in the user input. • Almost all existing databases are subject to SQL injection attacks to varying degrees.
- 16. SQL Injection Attack • Take an asp page that will link you to another page with the following URL: • http://sqlinject/index.asp?customer=Talentica • In the URL, 'customer' is the variable name, and ‘Talentica' is the value assigned to the variable. In order to do that, an ASP might contain the following code • v_cat = request("customer") sqlstr="SELECT * FROM Customer_Master WHERE Customer='" & v_cat & "'" set rs=conn.execute(sqlstr) • thus the SQL statement should become: SELECT * FROM Customer_Master WHERE Customer = 'Talentica' • Now, assume that we change the URL into something like this: http://sqlinject/index.asp?customer=Talentica or 1=1— • Now, our variable v_cat equals to " Talentica ' or 1=1-- ", if we substitute this in the SQL query, we will have: • SELECT * FROM Customer_Master WHERE Customer = ‘Talentica’ or 1=1--'
- 17. SQL Injection Attack (Contd) • Take the following page for another example: http://sqlinject/index.asp?id=10 • We will try to UNION the integer '10' with another string from the database: http://sqlinject/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '%25USER%25'-- • SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME= 'USERS' AND COLUMN_NAME LIKE '%USER%'
- 18. SQL Injection Attack(Contd) • The login page had a traditional username-and-password form, but also an email-me-my-password link; the latter proved to be the downfall of the whole system. SQL SqlDataAdapter myCommand = new SqlDataAdapter( "SELECT username, passowrd FROM users WHERE username = '" + SSN.Text + "'", myConnection); The following script shows a simple SQL injection. The script builds an SQL query by concatenating hard-coded strings together with a string entered by the user: var iusername, ipassword user = Request.form ("iusername"); password = Request.form ("ipassword"); var sql = "SELECT username,passowrd FROM where username = '" + user + "'" password = '" + password + "'"; The developer's intention was that when the code runs, it inserts the user's input and generates a SQL the following statement. SELECT username,passowrd FROM users WHERE username=@existinguser
- 19. SQL Injection Attack(Contd) select * from Users where username ='test' Depending on response is a dead giveaway that user input is not being sanitized properly and that the application is ripe for exploitation. select * from Users where username ='test' OR 'x'='x‘ SELECT * FROM Users WHERE emailid = 'x' OR username LIKE '%test%'; SELECT * FROM Users WHERE emailid = 'x'; DROP TABLE test; --'; SELECT * FROM Users; INSERT INTO Users VALUES (3,‘test',‘test','abcd@yahoo.com');--'; SELECT * FROM Users WHERE emailid = 'x'; UPDATE Users SET emailid = 'abcd@yahoo.com‘ ;
- 20. SQL Injection Prevention • Check and filter user input Length limit on input (most attacks depend on long query strings). Do not allow suspicious keywords (DROP, INSERT, SELECT, SHUTDOWN). Call stored procedures, instead of directly sending SQL statements to the database. parameter is treated as a literal value and not as executable code • Eliminate string concatenation to create SqlCommandText . Use SqlCommand with Parameters . Eliminate EXECUTE (@sql) If dynamic SQL required: Use sp_executesql with parameters Review Your Application's Use of Parameterized Stored Procedures • Principal of Least Privilege A user or process should have the lowest level of privilege required in order to perform his assigned task. If you know a specific user will only read from the database, do not grant him root privileges. Segregate users. Define roles. • The Microsoft Source Code Analyzer for SQL Injection tool is available to find SQL injection vulnerabilities in ASP code Coding techniques available for protecting against Sql injection
- 21. Cross-Site Scripting Dynamic websites suffer from a threat that static websites don't, called "Cross Site Scripting" Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website. Many popular guestbook and forum programs allow users to submit posts with html and javascript embedded in them. e.g. an attack on your database and update up to 5000 rows in every table and replace your strings in your database with random XSS attacks. Everything from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. To prevent cross-site scripting: –Check that ASP.NET request validation is enabled. –Review ASP.NET code that generates HTML output. –Determine whether HTML output includes input parameters. –Review potentially dangerous HTML tags and attributes. –Evaluate countermeasures.
- 22. How to Protect Against Attacks? • Set a good password policy – Strong passwords. • Educate users to use passphrases. – No password reuse. – Login lockdown after x failed logins attempts. • Keep up to date with security patches – Always test them for some time on non production servers first and monitor for patch problems on mailing lists • Sometimes they could open holes instead of fixing them.
- 23. How to Protect Against Attacks? • At firewall level – Allow connections only from trusted hosts. – Block all non used ports. – Block all outbound connections • Why the database would need to connect to a host or Internet? • Set exceptions for replication, linked databases, etc. • Disable all non used functionality – Use hardening guides from trusted parties. – Remember to test on non production servers first.
- 24. How to Protect Against Attacks? • Use encryption – At network level • SSL, database proprietary protocols. – At file level • File and File System encryption – Backups, Data files, etc. – At database level – Column level encryption. – Databases encryption API. – Third party solutions.
- 25. How to Protect Against Attacks? • Periodically check for object and system permissions – Check views, stored procedures, tables, etc. permissions. – Check file, folder, registry, etc. permissions. • Periodically check for new database installations – Third party products can install database servers • New servers could be installed with blank or weak passwords. • Periodically check for users with database administration privileges – This helps to detect intrusions, elevation of privileges, etc. • Periodically check for database configuration and settings.
- 26. How to Protect Against Attacks? • Periodically check database system objects against changes – Helps to detect rootkits. • Periodically audit your web applications – SQL Injection. – Misconfigurations. – Permissions. – etc. • On web applications use low privileged users to connect to database servers – If vulnerable to SQL Injection, attacks could be limited.
- 27. How to Protect Against Attacks? • Run database services under low privileged accounts – If database services are compromised then OS compromise could be a bit difficult. • Log as much as possible – Periodically check logs for events such as: • Failed logins. • Incorrect SQL syntax. • Permissions errors. • Etc. • Monitor user activities. • Monitor user accesses.
- 28. How to Protect Against Attacks? • Build a database server honeypot – Helps to detect and prevent internal and external attacks. – Usually attackers will go first for the low hanging fruit. – Set up an isolated server • All outbound connections should be blocked. • Set it to log everything, run traces and set alerts. • Set up other services to create a realistic environment. • Set blank or easily guessable passwords. • Make the server looks interesting – You can link it from production servers. – Set it an interesting name like CreditCardServer, SalaryServer, etc. – Create databases with names like CreditCards, CustomersInfo, etc. – Create tables with fake data that seems real.
- 29. How to Protect Against Attacks? • Build a home made IDS/IPS – On sensitive Database Servers depending on available functionality you can set alerts to get notifications or to perform some actions when some errors occur: • Failed login attempts. • Incorrect SQL syntax. • UNION statement errors. • Permissions errors.
- 30. How to Protect Against Attacks? • As we just saw Data Theft threat is real and database security is very important. • One simple mistake can lead to database compromise. • Perimeter defense is not enough. • You must protect your databases and you have to invest on database protection. • If you don't protect your databases sooner or later you will get hacked – This means lot of money loses. – In worst case running out of business.
- 31. Conclusions • Protect your data as you protect your money!!!!!!! – Think about it, if you lose data you lose money. • Use third party tools for – Encryption. – Vulnerability assessment. – Auditing. – Monitoring, Intrusion prevention, etc. • Train IT staff on database security. • Ask us for professional services :).
- 32. References • A Chronology of Data Breaches Reported Since the ChoicePoint Incident http://www.privacyrights.org/ar/ChronDataBreaches.htm • The high cost of data loss http://www.informationweek.com/security/showArticle.jhtml?articleID =183700367&pgno=1 • Swipe toolkit calculator http://www.turbulence.org/Works/swipe/calculator.html • How much are your personal details worth? http://www.bankrate.com/brm/news/pf/20060221b1.asp
- 33. References • Security & Privacy - Made Simpler http://bbb.org/securityandprivacy/SecurityPrivacyMadeSimpler.pdf • NTLM unsafe http://www.isecpartners.com/documents/NTLM_Unsafe.pdf • Manipulating MS SQL Server using SQL Injection http://www.appsecinc.com/presentations/Manipulating_SQL_Server _Using_SQL_Injection.pdf • Papers, advisories and exploits http://www.argeniss.com/research.html
- 34. ● Questions? ● Thanks. ● Contact: satyajit.mukherjee@gmail.com