Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Network Encryption in Modern Relational Database Management Systems

In this post I'll continue on the topic of data encryption (see my previous post on Encrypting Data At Rest).

Network communications between the client and the database server should always be secured. Historically relational database management system (RDBMS) network communication protocols are in clear text by default. This allows attackers sniffing on the wire to intercept sensitive data like logins/passwords, object names and even actual table data coming back from database server to client. That's why it is important to secure network communications in addition to encrypting data at rest. Most modern RDBMS rely on PKI (public key infrastructure) to implement network encryption. SSL protocol is the de-facto standard in Oracle, Microsoft SQL Server, and Sybase ASE for encrypting network communications. While SSL provides more capabilities than encryption (e.g. authentication) I will highlight only the encryption aspect. There are additional options for data encryption in transit:secure tunnels and IPSec, but I will focus on the encryption features provided in the database.

Oracle 11g R2

The Oracle Advanced Security Option (ASO) provides two ways to encrypt data flow: using Network Data Encryption and using SSL. The former is built on symmetric key encryption, the latter uses PKI. To configure secure communication via SSL in an Oracle Database we will create a Wallet to store authentication and signing credentials (e.g. certificates) and make changes to several configuration files (sqlnet.ora, listener.ora). Provided that the ASO option is installed on both the server and the client, you can configure encryption via SSL by:

  1. Using the Oracle Wallet Manager create a Wallet. The tool will suggest setting the Wallet password and preparing a certificate request. Next, a certificate must be obtained for the request from Certification Authority or (CA) and then added to the Wallet. For testing purposes a self-signed certificate may be sufficient: see Oracle documentation how to do this with the Oracle PKI Tool (orapki).
  2. BSL_12921_982d551c-51c3-4f97-9715-6c3a996d76b4

  3. Using Oracle Net Manager specify the Wallet location.
  4. BSL_12922_9c7a8b94-24ac-4476-95a9-77c0be94d37f

    These steps will add configuration information to the sqlnet.ora files that looks like this snippet:

    SSL_CLIENT_AUTHENTICATION = FALSE
    SSL_VERSION = 0
    WALLET_LOCATION =
    (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
    (DIRECTORY = C:\app\Administrator\product\11.2.0\dbhome_1\admin\orcl\wallet)
    )
    )
  5. Create a Listening Endpoint that uses TCP/IP with SSL on the server. Oracle recommends port 2484 to be used for it. The listener configuration file will look like:
    (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=oracle11g)(PORT=2484)))

Now to should configure the client: add an entry to the tnsnames.ora file so that the client will use tcps protocol for connections. Next, import the trusted root certificate into the client Wallet. This step is required especially in the self-signed scenario because otherwise the client won't be able to trust the server certificate. Again the Oracle PKI Tool can be used:

orapki wallet add -wallet . -trusted_cert -cert root_certificate.txt -pwd Secr3tPassw0rd

Once the client is configured, you can test the connection via sqlplus. This is the packet capture for SELECT * FROM DBA_USERS server response without SSL:

BSL_12918_23644a01-42dd-4c83-8ff0-f2beaf756af5

This is the same query ran with SSL turned on:

BSL_12917_08178f58-b3d2-4ffa-96db-bb16961515b3

You'll see that the data is no longer visible in plain text. Of course there are much more SSL configuration options in Oracle Database - please consult your user documentation for details.

Microsoft SQL Server 2008

Microsoft SQL Server 2008 provides connection encryption for all editions, including Express. By default, the server generates a self-signed certificate during startup even when encryption isn't configured. This makes it possible to always encrypt login sequence so that logins/passwords aren't visible. However, subsequent data exchange will expose clear text data so it's necessary to configure SSL properly. Here is how:

  1. Obtain a server certificate. The certificate can be self-signed or from a real CA.
  2. Install the certificate on the server. It can be placed in the local computer certificate store or in the SQL Server service user certificate store.
  3. Set the option to encrypt all communications on the server via the SQL Server Configuration Manager. The option name is ForceEncryption, it should be set to Yes. This will encrypt all client-server communication. If a client cannot process encryption, the connection will fail.

Assume we have a simple query like SELECT name FROM syslogins. When no encryption is used the query and response are sent in clear text:

BSL_12927_fb981bb1-a9bc-41a9-9dd3-8b7bf60996c0

The same packet with a query after ForceEncryption is set to Yes and the server is restarted:

BSL_12926_f1a590df-94fb-4cfb-a866-63ceef7f9b4b

It should be noted that self-signed certificates are suitable for testing purposes only because they are susceptible to man-in-the-middle attacks. In a production environment only certificates from trusted authorities should be deployed.

For additional details see Microsoft's overview on Encrypting Connections to SQL Server

Sybase ASE 15

The Sybase ASE client-server communication is by default, in clear text. SSL or Kerberos can be used for the network encryption. The following details apply only to SSL.

As with Microsoft SQL Server, we must provide the server with a valid server certificate for SSL to function. Steps to enable SSL encryption on Sybase ASE 15 (also see the Sybase System Administration Guide PDF):

  1. Generate a certificate for the server. Tools provided with the ASE could be used to get the certificate for testing purposes (certreq, certauth). Take into account this excerpt from Sybase ASE documentation: "To create a server certificate file that Adaptive Server understands, append the certificate requestor's private key to the end of the signed certificate file."
  2. Place the trusted root certificate file under %SYBASE%\%SYBASE_ASE%\certificates ($SYBASE/$SYBASE_ASE/certificates on UNIX) and name it after the server: servername.txt
  3. Issue the T-SQL command: sp_configure 'enable ssl', 1
  4. Add the SSL filter to the interfaces file: to do so, add ",ssl" at the end of master and query lines.
  5. Use the sp_ssladmin stored procedure to add a certificate to the certificates file created in step 1.
  6. Shut down and restart Adaptive Server for the changes to take effect.

To connect to the server now one must update the interfaces configuration file on the client to include the ssl filter and repeat step 4. When the self-signed server certificate is used the trusted certificate file must be specified via -x option to isql:

isql -S SYBASE155ESD2 -U sa -x trusted.cert

For Interactive SQL one must import the trusted certificate file into keystore first with the keytool.

Now let's compare the traffic before and after SSL option. Here is how the login sequence looks like without encryption:

BSL_12924_aa762c73-2fd8-44bd-b6d1-3af3f77fe1a9

Note that the username and password is embedded into the packet.

select name from syslogins query results are coming back:

BSL_12920_898df9b5-fe11-4bf3-b594-80cae4e7090e

Next, let's enable SSL using steps provided. The login exchange packets no longer contains username and password in clear text and looks like this capture:

BSL_12919_732aded0-1f50-4215-a1cb-fde447b5b895

The response packet to the SELECT query looks like this:

BSL_12923_9d44011f-b194-48ac-ac73-3c9b880d46dd

To examine what cipher suite is used for the current connection use @@ssl_ciphersuite T-SQL global variable:

SELECT @@ssl_ciphersuite
----------------------------
TLS_RSA_WITH_AES_256_CBC_SHA

If the result is non-null, the current connection is SSL-encrypted.

Encryption drawbacks

As always security comes at cost. There is more pressure on memory since the server needs additional space to encrypt/decrypt the data. Performance also decreases because extra CPU time is spent in crypto code. Therefore thorough testing is required before putting encryption to production.

References

http://download.oracle.com/docs/cd/E11882_01/network.112/e10746/asossl.htm

http://msdn.microsoft.com/en-us/library/ms189067%28v=sql.100%29.aspx#

http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc31654.1550/pdf/sag1.pdf

Latest SpiderLabs Blogs

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More

Physical Address Strangeness in Spam

Ten years ago, Congress passed the "CAN-SPAM Act" (also known as theYou-CAN-SPAM Act, since it defined legal spam and supersedes any stricter state-antispam laws). One of the provisions of the act is...

Read More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising

During an Advanced Continual Threat Hunt (ACTH) investigation that took place in early December 2023, Trustwave SpiderLabs discovered Ov3r_Stealer, an infostealer distributed using Facebook...

Read More