Hacking & Defending DatabasesTodd DeSantisTechnical Pre-Sales [email protected]
AgendaDatabase hacking in 2007Why, Who, What, HowGoogle HackingSQL InjectionGeneral Security RecommendationsThe Best Security Recommendation(Proactive Real-Time DB Monitoring, Alerting, Prevention)
What happened in the last 3 years?February 2005: ChoicePoint BreachCredit history informationClassic social engineering attackResult: 163k consumer records stolen, $15M in penalties and charges, security audits until 2026...December 2005: Guidance Software Inc. Breach3,800 Credit cards, names and more of professionals from NSA, FBI, CIA...Probably SQL injection attack via the webAlso in 2005 - -- University of Southern California, Boston College, California State University, Chico and the University of Georgia, Lexis Nexis, PayMaxx, San Jose medical, DSW all suffered high profile data breaches
This YearJuly 2005 January 2007: TJX45.7M+ credit/debit card records stolenSophisticated attack (WiFi -> Internal Network -> DB)Result: data sold to data brokers and used in many scams, TJX faces lawsuits and losses of $25M until May 07 (will grow considerably)July 2007 Fidelity National Information ServicesBank and credit data of 2.3M customersStolen by a DBAAnd many more breaches not only in the U.S. (e.g. Home Office breach in the U.K.)Many breaches are unknown or not made publicMany breaches remain undetected
What else happened during these years?Regulations kicking in:SB 1386Sarbanes OxleyPCI-DSSSAS 70and moreBad guys are getting more "professional"Perimeter firewalls are doing a better job at protecting databases from external threats Insider threat continues to growOutsourcing IT is the normDatabase vendors begin to ackgnowledge vulnerabilities
Vulnerabilities aboundThe most widely used, diverse and complicated DBMS Oracle is the center of attention as regards DBMS security threatsCVE (Common Vulnerabilities and Exposures, an independent security website) lists the no. of vulnerabilities for DBMSs as follows: No. of vulnerabilities reported since Jan 2006
To resize chart data range, drag lower right corner of range.
Oracle database CVEs (Common Vulnerabilities and Exposures)Total Number of CVEs from 2003 (accumulated)
Why Protect The Database?Databases hold sensitive information and lots of it:Customer data, accounts, transactions, payroll, investor dataWhen a breach occurs, damage is significant:Direct damages and costsBad publicityRegulatory penaltiesWhat is more important to protect than the database?
Know Your EnemyUnauthorized access - not just hackersToo many privilegesInternal attacksDisgruntled employeesJust trying to get the job doneIndustrial espionage, Identity theft, etc.Look around you!!!External attacks
The Database: ExposedDoes a hacker need DBA access?Myriads of privilegesSystem level, Application level, Data accessAny privelege in the right circumstances can be an issueOther issuesIncorrect configurationToo many features large attack surface
Available ExploitsHave someone grant you DBA or ALL PRIVILEGES or ALTER USERDefault passwordsPassword hashes Vulnerable code Built-in package exploitsdbms_metadata.get_ddlctxsys.driload.validate_stmtMany more
To Protect your DB Become a HackerHackers are trying:To cause damageStealGain access to host systemsThink like a hackerLearn exploitsLook for security issuesConfiguration, permissions, bugs
Finding Available ServicesGoogle Hackinghttp://johnny.ihackstuff.com/ghdb.phpora tnsnames, iSQL isqlplus0-Day Database Hacks Become a DBAUse tools for:Brute force password crackingGuessing service names and versionshttp://www.petefinnigan.com/tools.htm
SQL InjectionWikipedia is a technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed.
SQL InjectionExists inApplicationsStored program unitsBuilt inUser createdSeveral typesInject SQL, Inject FunctionsAnnonymous blocks of code
SQL Injection Web ApplicationUsername = ' or 1=1 --The original statement looked like:'select * from users where username = ''' + username + ''' and password = ''' + password + '''The result = select * from users where username = '' or 1=1 --' and password = ''
SQL Injection Built-In PackagesEvery time Oracle patches, several are for SQL Injection vulnerabilitiesOct '07 CPU has 27 DB specific vulnerabilities5 of these can be exploited without user authentication
Hacker boards New ways to hack into Oracle are coming out all the time
Oracle CPUs and hacking forums Roadmaps to your data
Protecting Your DatabaseApply patch sets, upgrades and CPUsEasier said than doneCheck for default and weak passwords regularlySecure the networkListener passwordsValid node checking + firewallUse encryption
Protecting Your DatabaseInstall only what you use, remove all elseReduce your attack vectorThe least privilege principleLock down packagesSystem access, file access, network accessEncrypt critical dataUse secure coding techniquesBind variables, ownership
Protecting Your DatabaseTry out the Hedgehog FREE TRIALhttp://www.sentrigo.comVirtual patchingSQL Injection protectionFine grain auditingCentralized managementTerminate rogue sessionsMore
DBRepositoryServicesWebManagementApplication3rd Party DirectoryServer3rd PartyMonitoringToolsDBSentrigo ServerDirect Memory AttachOCIXML Streaming Over SSL (TCP/IP)JDBCHTTPSLDAPSNMPSentrigo Logical ViewSentrigoSensorSentrigoSensorDatabase MachineDatabase MachineEnd Users
****This is the why slide. Why should we protect databases?This is the who slide. Who are we protecting from? Anyone that has unauthorized access and not just hackers. There are too many privileges around that are easily granted and never revoked. There are internal attacks and external attacks. Also, it is not unheard of that databases are directly exposed to the network or even to the web.*The truth is that to hack a the database, do damage and steal data. There are other issues as well like incorrect configuration and permidatabase you dont need DBA access. You can just as easily steal data as the application user. Many privileges allow you to exploit ssive network access. In Oracle specifically, there are just too many features. There is a large attack surface and its very hard to cover it all. You must disable all features you are not using such as APEX, XDB, extproc and all the example schemas.*The easiest way to gain access is to have someone grant you the privileges you need. This can be done by social engineering or due to lack of attention. If one has access to the user$ table, its very easy to brute force attack the passwords. Vulnerable code exists in build-in packages and in user packages as well. Many example schemas contain too many privileges.*So, what are hackers trying to do? Usually, steal the data and own the server. In the process, they might damage the database either to create a diversion or to cover their tracks. To protect, you need to think like a hacker. Search for exploits and think about security everywhere.*It is very easy to find available services on the web. Just Google for them. After finding, it is extremely easy to hack in using tools.*Example of searching for available TNS names*Found one in the first page available to the world*And it is not even password protected *The definition from Wikipedia. Pretty accurate.*Here Ill do the usual demo using the emps web application
Domain index, package convincing oracle to get the index metadata
2 ways to create packages definer is context of owner, invoker is where the package in run with the runs of the installer of the package**
Click here to load reader