Vulnerabilities in Desktop Applications Derek Ditch (lead) Dylan McDonald Justin Miller Missouri University of Science & Technology Computer Science Department April 29, 2008 Vulnerabilities in Desktop Applications
Outline Objective: To protect desktop applications and user data from SQL injection attacks 1 Background Akonadi Architecture Akonadi & 2 Types of Attacks Example 3 4 Vulnerabilities in Desktop Applications
Background Background Akonadi Architecture Akonadi & Why choose Akonadi? Part of core architecture for upcoming KDE 4.1 release Significant privacy data at risk Lack of protection for Qt applications in general from SQL injection Vulnerabilities in Desktop Applications
Akonadi Akonadi Architecture Background Akonadi Architecture Akonadi & Desktop neutral Personal Information Manager (PIM) service Akonadi stores/caches Email Chat logs Calendars Address Books RSS Feeds Uses MySQL backend Provides IMAP client interface Vulnerabilities in Desktop Applications
Akonadi Akonadi & Background Akonadi Architecture Akonadi & <<thread>> nager AkonadiConnection use <<TcpServer>> AkonadiServer 1 rage NotificationCollector 1 <<thread>> CacheCleaner <<interface>> clear old values IMAP <<realize>> handler Handler Append Delete Status send changes 1 build db DataStore DbInitializer Rogue client accesses IMAP socket interface Executes valid IMAP client command, with inter-mixed SQL as user data User data is injected into SQL query SQL is passed through API directly to database layer <<interface>> MySQL Database Vulnerabilities in Desktop Applications
Types of Attacks Example SQL injection attacks inject arbitrary text into prepared SQL buffers to perform actions unintended by the developer Even with internal SQL data stores, poorly crafted or protected queries are vulnerable In particular, Akonadi uses a passwordless internal SQL store protected only by file permissions Vulnerabilities in Desktop Applications
Types of Attacks Types of Attacks Example Tautology adds logic that is trivially true in order to make query return more results than intended Comment uses special character sequence ( -- or /* ) in input to disable parts of intended query Subqueries inserts a query within a query to change behavior of database server or modify arbitrary data within SQL database Vulnerabilities in Desktop Applications
Attack Setup Types of Attacks Example Suppose we have a user table: User Password Admin tauritzd takecs348 T ajfrost hackallatms F justinmiller offtoiowa F Queries like SELECT * FROM users WHERE user = $un AND password = $pwd; are often used to authenticate users when they enter their username and passwords in the application Let s see how ajfrost can become an admin! Vulnerabilities in Desktop Applications
Attack Result Types of Attacks Example We will now try an attack by entering SQL logic into an application s password field, resulting in this SQL query: Resulting SQL Query SELECT * FROM users WHERE username = ajfrost AND password = OR 1 = 1 AND admin = T ; We can use any row to be an administrator Vulnerabilities in Desktop Applications
Command Line Interface A special interactive mode flag can be passed from the command line for testing multiple queries in short order When in interactive mode, a prompt is displayed and as queries are entered, the provided and cleaned queries are run against a MySQL database Command line and interactive modes both show the impacts of the queries on the database Vulnerabilities in Desktop Applications
Example API Example usage: 1 // Create sqlcleaner then autoclean query 2 SQLSanitizer sqlcleaner(query); 3 4 if( true == sqlcleaner.cleaned() ) 5 // Process query 6 query = sqlcleaner.getquery() 7... 8 else 9 // Handle error Vulnerabilities in Desktop Applications
Example Output %./sqlsan "SELECT * FROM users WHERE username = ajfrost AND password = OR 1 = 1 AND admin = T ;" SQLSanitizer Test App v1 By: Dylan McDonald, Justin Miller, Derek Ditch Sanitized Query: SELECT * FROM users WHERE = ajfrost AND password = AND admin = T ; Vulnerabilities in Desktop Applications
Under the hood What happens to the string? If no parameters are given to the constructor then default, safe behavior is used. The query is automatically processed unless the parameter is set to false. The query is checked for commands that change the schema, subqueries, and tautologies. If all went well, cleaned() returns true. Otherwise, it returns false. Vulnerabilities in Desktop Applications
Make the smarter Handle more complex queries Reduce overhead of added protection Give back to community Ensure code conforms to KDE standards Submit patch to KDE developer mailing lists Make additional changes as necessary Publish findings Vulnerabilities in Desktop Applications