12.1 Database Architectures, Default Ports & Authentication

12.1 Database Architectures, Default Ports & Authentication

Databases represent the primary repositories of confidential organizational data, housing customer personally identifiable information (PII), payment card records, intellectual property, and internal authentication credentials. In a multi-tier enterprise application architecture, the database tier operates as the persistence layer behind web servers, application runtimes, and message queues. For a penetration tester preparing for the CREST Practitioner Security Analyst (CPSA) examination, assessing database security requires a comprehensive understanding of Relational Database Management System (RDBMS) architectures, network listener configurations, default port allocations, administrative credential defaults, and client-server connectivity middleware.

---

Relational Database Management System (RDBMS) Architecture

An RDBMS structures data into formal mathematical relations, known colloquially as tables. A table consists of vertical columns (attributes with defined data types and constraints) and horizontal rows (records or tuples representing discrete data entities). The architectural composition of an enterprise RDBMS encompasses several decoupled components:

+-----------------------------------------------------------------------------+
|                        ENTERPRISE RDBMS ARCHITECTURE                        |
+-----------------------------------------------------------------------------+
|  Client Applications / Web Tiers / DBA Tools (SSMS, sqlplus, psql, DBeaver) |
+-----------------------------------------------------------------------------+
                                      |  (TCP/IP, Named Pipes, Shared Memory)
                                      v
+-----------------------------------------------------------------------------+
|                             NETWORK LISTENER                                |
|   (e.g., Oracle TNS Listener, MSSQL TDS Endpoint, MySQL Listener Daemon)   |
+-----------------------------------------------------------------------------+
                                      |
                                      v
+-----------------------------------------------------------------------------+
|                         RELATIONAL DATABASE ENGINE                          |
|  - Parser & Lexer      : Validates SQL syntax and builds abstract trees     |
|  - Query Optimizer    : Calculates cost-efficient query execution plans     |
|  - Execution Engine   : Processes operators and enforces access controls    |
|  - Lock Manager       : Enforces ACID concurrency and transaction isolation |
+-----------------------------------------------------------------------------+
                                      |
                   +------------------+------------------+
                   v                                     v
+--------------------------------------+ +------------------------------------+
|            STORAGE ENGINE            | |           SYSTEM CATALOG           |
| (InnoDB, MyISAM, Heap, Buffer Pools) | | (Data Dictionary, Meta-Schemas)    |
+--------------------------------------+ +------------------------------------+
                   |                                     |
                   +------------------+------------------+
                                      v
+-----------------------------------------------------------------------------+
|                           PHYSICAL DISK STORAGE                             |
|         (Data Files [.mdf/.dbf], Transaction Logs [.ldf], Undo Logs)        |
+-----------------------------------------------------------------------------+

Key Architectural Components

1. Network Listeners: A dedicated service listening on network sockets (or local IPC mechanisms) that handles connection handshakes, protocol translation, authentication negotiation, and connection routing to database worker threads.
2. Database Engine & Parser: The query execution pipeline. When a query arrives, the parser validates its syntax against the database grammar, the optimizer calculates the optimal index and join strategies, and the execution engine executes operations against data stored in memory or disk.
3. Schemas & Namespaces: A logical collection of database objects (tables, views, stored procedures, triggers, indexes) owned by a specific database user or security principal. While some engines treat a database and a schema interchangeably (e.g., MySQL), enterprise engines like Oracle, MSSQL, and PostgreSQL maintain schemas as distinct namespaces within databases.
4. System Catalog & Data Dictionary: Read-only system views and metadata tables that describe the internal structure of the database itself. The catalog tracks table names, column data types, user accounts, granted permissions, constraints, and audit configurations. Attackers exploit catalog views during enumeration to reconstruct the database schema.
5. Storage Engines: The low-level software module responsible for writing, retrieving, and indexing data on physical storage. In engines like MySQL, the storage engine is modular (e.g., transactional InnoDB vs non-transactional legacy MyISAM). In MSSQL and Oracle, the storage subsystem is tightly integrated with write-ahead transaction logging (WAL) to guarantee ACID (Atomicity, Consistency, Isolation, Durability) compliance.

---

Default Network Ports & Services

During external and internal network penetration assessments, identifying database listening services is a critical reconnaissance objective. Network mapping tools such as Nmap identify database instances by their default port allocations and service signatures.

+-----------------------------------------------------------------------------+
|                     CPSA CORE DATABASE PORT REFERENCE                       |
+-----------------------------------------------------------------------------+
| Database Engine              | Default Port / Transport | Service Function  |
+------------------------------+--------------------------+-------------------+
| Microsoft SQL Server (MSSQL) | TCP 1433                 | Default Instance  |
| MSSQL Browser Service        | UDP 1434                 | Dynamic Discovery |
| Oracle RDBMS (TNS Listener)  | TCP 1521                 | Primary Listener  |
| Oracle Alternate Listeners   | TCP 1522 - 1526          | Secondary / RAC   |
| MySQL / MariaDB              | TCP 3306                 | MySQL Daemon      |
| PostgreSQL                   | TCP 5432                 | PostgreSQL Server |
| IBM DB2                      | TCP 50000 / 50001        | Instance Port/SSL |
+-----------------------------------------------------------------------------+

Microsoft SQL Server (MSSQL): TCP 1433 & UDP 1434

• TCP Port 1433 (Default Instance): The standard network endpoint for the primary, unnamed MSSQL instance. Clients communicate with this port using the Tabular Data Stream (TDS) protocol.
• UDP Port 1434 (SQL Server Browser Service): When multiple MSSQL instances run on a single host (named instances), instances other than the default instance are allocated dynamic TCP ports. The SQL Server Browser service listens on UDP port 1434 to answer client queries regarding which TCP port corresponds to a specific named instance.
• Penetration Testing Significance: Penetration testers query UDP 1434 (e.g., using nmap -sU -p 1434 --script ms-sql-info <target> or Metasploit's mssql_ping) to discover hidden instances, exact database versions, service pack levels, and dynamic listening ports without needing to perform full TCP port sweeps.

Oracle RDBMS: TCP 1521 & Alternate Listeners

• TCP Port 1521 (TNS Listener): The Oracle Transparent Network Substrate (TNS) listener coordinates client connections to Oracle database instances. The listener resolves client connection requests against registered System Identifiers (SIDs) or Service Names.
• TCP Ports 1522–1526: Alternate ports frequently assigned to secondary listeners, Oracle Real Application Clusters (RAC), or staging environments.
• Penetration Testing Significance: The TNS listener can be interrogated using utilities like tnsping, Nmap scripts (oracle-tns-version), or odat (Oracle Database Attacking Tool). Unprotected listeners may permit remote SID brute-forcing, version enumeration, or even remote listener poisoning if TNS administration passwords are unset.

MySQL / MariaDB: TCP 3306

• TCP Port 3306: The default listening port for MySQL and its open-source fork MariaDB. Clients connect using the MySQL Client/Server Protocol, which transmits an initial handshake packet disclosing the server version, protocol capabilities, and cryptographic challenge salt.

PostgreSQL: TCP 5432

• TCP Port 5432: The default listening port for the PostgreSQL database server. PostgreSQL uses a custom binary wire protocol that supports SSL negotiation during the initial connection phase.

IBM DB2: TCP 50000 & 50001

• TCP Port 50000: The default port for standard unencrypted IBM DB2 database communication.
• TCP Port 50001: Typically designated for secure, SSL/TLS-encrypted DB2 communications.

---

Default Administrative Accounts & Authentication Models

Default credentials and weak authentication mechanisms frequently grant unauthorized administrative access during penetration tests. Each RDBMS features distinctive administrative accounts, system privilege models, and architectural security boundaries.

+-----------------------------------------------------------------------------+
|                  DEFAULT ADMINISTRATIVE ACCOUNTS & PRIVILEGES               |
+-----------------------------------------------------------------------------+
| RDBMS      | Administrative Account | Authentication Models / Defaults       |
+------------+------------------------+---------------------------------------+
| MSSQL      | sa                     | Windows Only vs. Mixed Mode           |
| Oracle     | SYS (SYSDBA), SYSTEM   | Operating System Auth, Password File  |
| MySQL      | root                   | Historically blank, auth_socket, PAM  |
| PostgreSQL | postgres               | peer (local socket), md5, scram-sha-256|
+-----------------------------------------------------------------------------+

Microsoft SQL Server Authentication

MSSQL supports two distinct authentication security modes:

1. Windows Authentication Mode (Integrated Security): MSSQL trusts the underlying Active Directory / Windows Local Security Authority (LSA) to validate user identities via Kerberos or NTLM tokens. Passwords are never validated directly by the database engine. This is Microsoft's recommended, most secure deployment mode.
2. Mixed Mode (SQL Server and Windows Authentication): Permits both Windows-integrated logins and native SQL logins. Enabling Mixed Mode activates the built-in system administrator account, sa.
   • The sa (System Administrator) Account: Possesses the sysadmin fixed server role, granting complete, unrestricted control over the entire database server, its files, and underlying OS interaction procedures. Default or weak passwords assigned to sa during legacy installations represent an immediate, catastrophic risk.

Oracle RDBMS Accounts & Architecture

Oracle maintains several default administrative and diagnostic accounts created during installation:

• SYS: The internal database owner. Must be accessed using administrative roles, typically AS SYSDBA or AS SYSOPER. SYS owns the core data dictionary tables.
• SYSTEM: The default database administrator account used for operational management. Lacks certain internal privileges of SYS but retains DBA privileges.
• SCOTT: A legacy demonstration schema created in older Oracle releases. Famously configured with the default password TIGER. While obsolete in modern releases, its persistence in legacy corporate deployments allows immediate unauthenticated access.
• DBSNMP: The account used by Oracle Enterprise Manager Intelligent Agent to monitor database health. Frequently left configured with the default password DBSNMP.
• Default System Identifiers (SIDs) & Service Names: Before authenticating to an Oracle database, a client must supply a valid SID or Service Name. Common default identifiers include ORCL (standard enterprise default) and XE (Oracle Express Edition).

MySQL / MariaDB Authentication

• The root Account: The superuser account for MySQL, possessing the ALL PRIVILEGES grant on *.*. Historically (MySQL 5.6 and earlier), initial installations created the root account with a blank (empty) password, and established anonymous user accounts that permitted unauthenticated local or network connections.
• Modern Posture: MySQL 5.7+ and MariaDB default to using the auth_socket or caching_sha2_password authentication plugins, which restrict root authentication to local Unix socket connections initiated by the operating system root user, significantly mitigating default remote password attacks.

PostgreSQL Authentication

• The postgres Account: The superuser account for PostgreSQL. PostgreSQL controls client authentication through its host-based configuration file, pg_hba.conf.
• Authentication Methods: Local socket connections typically use peer authentication (verifying that the operating system username matches the database username). Remote connections use password authentication methods such as md5 (legacy) or scram-sha-256 (modern, cryptographically secure salted challenge-response).

---

Database Connection Protocols & Middleware Security

Enterprise applications interact with back-end databases through standardized programming abstractions and middleware drivers. The two predominant specifications are ODBC and JDBC.

+-----------------------------------------------------------------------------+
|                        CLIENT DATABASE INTERFACING                          |
+-----------------------------------------------------------------------------+
| Client Code (C#, Python, PHP)        Java Application (Spring, Jakarta EE)  |
|           |                                       |                         |
|           v                                       v                         |
|    ODBC Driver Manager                     JDBC Driver Manager              |
|           |                                       |                         |
|           v                                       v                         |
|    Specific ODBC Driver                    Type 4 Pure Java JDBC Driver     |
| (e.g., FreeTDS, MySQL ODBC)               (Translates directly to wire)     |
+-----------------------------------------------------------------------------+
                                      |
                                      v (Native Database Network Protocol)
+-----------------------------------------------------------------------------+
| Database Server Listener (TDS on 1433, TNS on 1521, MySQL Wire on 3306)     |
+-----------------------------------------------------------------------------+

ODBC (Open Database Connectivity)

Developed by Microsoft and the SQL Access Group, ODBC is a C-based Application Programming Interface (API) that provides a uniform interface for accessing disparate database management systems. An application calls standardized ODBC functions (SQLConnect, SQLExecDirect), and the ODBC Driver Manager routes the requests to the database-specific driver library (such as a SQL Server or DB2 driver), which packages the data into native wire-format packets.

JDBC (Java Database Connectivity)

JDBC is Java's native API for database connectivity. JDBC drivers are categorized into four types, with Type 4 (Direct-to-Database Pure Java Driver) being the enterprise standard. A Type 4 driver converts JDBC calls directly into the vendor-specific network protocol (such as Oracle Thin Driver communicating directly over TNS), requiring no native client libraries on the application server.

Microsoft Access & File-Based Database Back Ends

Not every database tier is a listening network service. Microsoft Access (.mdb, .accdb) is a file-based engine with no TCP listener at all: the Jet/ACE database engine runs inside the calling application's process and opens the database file directly from disk or from an SMB share. For an assessor this inverts the usual model:

• There is no port to scan. Access back ends are found by reading connection strings, not by port scanning. Look for Provider=Microsoft.ACE.OLEDB.12.0;Data Source=\\fileserver\apps\hr.accdb in web.config, global.asa, ODBC DSN entries, or decompiled thick-client binaries.
• Access control collapses to file permissions. Any account with read access to the share can copy the whole database — tables, queries and all — and open it offline. NTFS/share ACLs, not database logins, are the only control (see the Windows permissions section).
• Legacy workgroup security is trivially broken. The .mdw workgroup file and the old database password are obfuscation, not encryption; freely available tooling recovers them instantly. Modern .accdb files do support real AES encryption, but only when a database password is set.
• Web-facing Access back ends are still injectable. Classic ASP and legacy .NET applications that concatenate user input into Jet SQL are vulnerable to SQL injection; Jet uses [] for identifier quoting, * as its wildcard in some contexts, and supports UNION SELECT against MSysObjects for schema enumeration when read permission on the system tables has not been revoked.

Treat a discovered Access back end as both a data-at-rest exposure (copy the file, own the data) and a web application flaw (injection), and report it against the file share rather than a port.

Network Traffic Encryption & Cleartext Risks

Historically, database protocols transmitted both authentication credentials and query payloads across the local network in plaintext. In the absence of TLS/SSL enforcement:

• Credential Sniffing: Attackers positioned on the local network (via ARP spoofing, rogue switch configurations, or compromised adjacent hosts) can capture plaintext credentials during the authentication handshake.
• Data Exfiltration: Sensitive query results—including credit card numbers, password hashes, and personal records—can be captured passively from network traffic.
• Man-in-the-Middle (MITM) Tampering: Unencrypted TDS, TNS, or MySQL sessions can be hijacked to inject arbitrary queries or alter returning query results.

Modern Hardening Requirement: Database listeners must be configured to require TLS/SSL (e.g., Force Encryption = Yes in MSSQL Server Configuration Manager, or ssl = on in postgresql.conf), and clients must validate the database server's X.509 certificate to prevent MITM attacks.