Are you someone (A DBA, Developer, etc) that connects to SQL Server to use data? You probably hear a lot about how protected your database can be when at rest. But what about when you connect to SQL and start running some queries? Using a simple hacking technique we will dig into some packets on our network and see what's in them. You may be shocked! Then we will create a self-signed SSL certificate, use it to encrypt our connections on the SQL Server, and see the actual changes in the packet as hackers would.
Demo scripts and processes not included in great detail with the slide deck. Some presentation notes are included.
Regular SQL Server setup No encrypted connections setup No network encryption setup Show 3 connections 1) SSMS login and simple query 2) capture with rawcap – view with wireshark 3) show values in plain text sent & returned 4) Use Excel – establish connection and don’t even put data in spreadsheet – show values 5) back to SSMS – connect and pull an encrypted value through – once without key open, once with key open
Purchased from certificate authority Research companies, check references, assured identity
Encrypt a message with the server's public key (encrypt only), send it, and if the server can tell you what it originally said, it just proved that it got the private key without revealing the key.
Process – Client attempts to connect to server (server has private key and personal certificate) Server sends client copy of certificate Client checks that it is trusted, if so confirm back to server with message encrypted by public key Server sends back a digitally signed acknowledgement decrypted by private key to start SSL encrypted session Encrypted data shared between client and server.
Connec tto woxemo vm machine Show IIS self signed certificate creation process Grant permission to SQL Service account to use certificate Set certificate and restart SQL Set enforce encryption in protocol to ‘yes’ Connect and sniff packets as in previous demo to see if now protected
Show how turning the yes to no in enforce means that it is optional, not by default. Yes ensured the connection has to be encrypted
You can’t just protect data at rest, nor can you just protect data in motion. Primary focus of many places is data in motion Anthem stated: Our state of the art system protected the data – in motion – they did not encrypt it when at rest. All plain text. Because HIPAA said they didn’t have to. Think about that. A large company with private information decided on minimal compliance rather than minimal risk.
Hacking Exposé - Using SSL to Secure SQL Server Connections
ExposéUsing SSL to Protect SQL Connections
Who Am I?
• WaterOx Consulting
• SQL Server MVP
• Friend of Redgate
• SQL Saturday DC & Nova Scotia
• SQL Summer Camp
How safe is your data?
Hacking / Cracking
• Modifying computer hardware or software
• Accomplish goals outside of original purpose
Measures taken to protect your data
• Primarily at rest
• In motion over the network
• Not always the case
Easy to get tools
• Command line tool
• Run from USB
• Captures packets into a file for reference later
• Captures packets as well
• Reads other capture files
Lots of others out there
• Secure Socket Layer
• Standard security technology
• Provide communication security over network
• Encrypts data flowing between parties
• Primarily prevent eavesdropping and tampering
How SSL Works
1. Client attempts to connect to server
2. Server send client copy of certificate
3. Client confirms trust
4. Server sends back acknowledgement to start SSL
5. Encrypted data shared between client and server
No single solution
Data in motion
• SSL – encrypt connections
• File encryption tools
Data at rest
• Column level encryption
By default connections are not encrypted
• Need to setup SSL (self signed minimum)
• Requires restart
• Encrypts data being transmitted
No one solution
• Protect data in transit
• Protect data at rest
• Separation of duties