Insecure Defaults

Insecure Defaults is a community skill for detecting insecure default configurations in software systems, covering default credential scanning, permissive permission detection, weak cryptographic defaults, debug mode identification, and configuration hardening recommendations for security auditing.

What Is This?

Overview

Insecure Defaults provides tools for identifying security-weakening default settings that ship with software frameworks, libraries, and infrastructure components. It covers default credential scanning that detects unchanged passwords, API keys, and authentication tokens left at factory values, permissive permission detection that finds overly broad file, network, and access control defaults that violate least privilege, weak cryptographic defaults that identifies outdated or weak cipher suites, hash algorithms, and TLS configurations, debug mode identification that locates development-only settings left enabled in production deployments, and configuration hardening that generates specific remediation steps for each detected insecure default. The skill enables security teams to audit configurations systematically before deployment.

Who Should Use This

This skill serves security engineers auditing deployment configurations, DevOps teams hardening infrastructure before production release, and developers reviewing default settings in framework configurations.

Why Use It?

Problems It Solves

Software ships with convenience-oriented defaults that prioritize ease of setup over security posture. Default credentials in databases, message brokers, and admin panels persist into production when setup checklists are incomplete. Debug and verbose logging modes left enabled expose internal state and error details to potential attackers. Cryptographic settings default to older algorithms for backward compatibility rather than current security standards.

Core Highlights

Credential scanner checks for known default passwords across common services and databases. Permission analyzer identifies overly broad access control settings. Crypto checker detects weak cipher suites and hash algorithms in configurations. Debug finder locates development mode flags enabled in production environments.

How to Use It?

Basic Usage

import re

class DefaultsChecker:
  DEFAULT_CREDS = {
    'postgres': [
      'postgres',
      'password'],
    'mysql': [
      'root', ''],
    'redis': [
      '', ''],
    'rabbitmq': [
      'guest', 'guest'],
    'mongodb': [
      'admin', '']}

  DEBUG_PATTERNS = [
    r'DEBUG\s*=\s*True',
    r'debug:\s*true',
    r'NODE_ENV\s*=\s*'
    r'development',
    r'FLASK_DEBUG\s*=\s*1']

  def check_config(
    self,
    config_text: str
  ) -> list[dict]:
    findings = []
    for pattern\
        in self\
          .DEBUG_PATTERNS:
      if re.search(
          pattern,
          config_text):
        findings.append({
          'type': 'debug',
          'pattern':
            pattern,
          'severity':
            'high',
          'fix': 'Disable'
            ' debug mode'})
    return findings

Real-World Examples

class TLSAuditor:
  WEAK_CIPHERS = [
    'RC4', 'DES',
    '3DES', 'MD5',
    'NULL', 'EXPORT']
  MIN_TLS = '1.2'

  def audit_config(
    self,
    tls_config: dict
  ) -> list[dict]:
    findings = []
    version = tls_config\
      .get('min_version',
        '1.0')
    if version < (
        self.MIN_TLS):
      findings.append({
        'type': 'crypto',
        'issue': 'TLS '
          f'version {version}'
          ' below minimum',
        'fix': f'Set min'
          f' TLS to '
          f'{self.MIN_TLS}',
        'severity':
          'critical'})

    ciphers = tls_config\
      .get('ciphers', [])
    for cipher in ciphers:
      for weak\
          in self\
            .WEAK_CIPHERS:
        if weak.lower()\
            in cipher\
              .lower():
          findings.append({
            'type': 'crypto',
            'issue': f'Weak'
              f' cipher:'
              f' {cipher}',
            'fix': 'Remove'
              ' weak cipher',
            'severity':
              'high'})
    return findings

Advanced Tips

Build service-specific check profiles that test for known insecure defaults in each technology used in the stack rather than applying generic checks. Integrate default scanning into CI pipelines to catch insecure configurations before deployment. Maintain an internal knowledge base of default credentials for all services used in the organization.

When to Use It?

Use Cases

Audit a new deployment for default credentials and debug settings before production release. Scan TLS configurations across services to identify weak cipher suites and protocol versions. Generate a hardening checklist for infrastructure components based on detected insecure defaults.

Related Topics

Security configuration, hardening, default credentials, TLS security, debug mode, access control, and security auditing.

Important Notes

Requirements

Access to configuration files and service settings for scanning. Knowledge of default credentials for services in the technology stack. Network access for remote configuration checks where applicable.

Usage Recommendations

Do: scan for insecure defaults as part of every deployment checklist before production release. Maintain updated default credential databases as new services are adopted. Report findings with specific remediation steps and configuration examples.

Don't: store default credential databases in public repositories since they aid attackers. Treat passing a default scan as complete security assurance since many vulnerabilities require deeper analysis. Skip rescanning after configuration changes that may reintroduce defaults.

Limitations

Pattern-based scanning cannot detect all insecure configurations since some require understanding the deployment context. Default credential lists become outdated as software versions change. Configuration files may be encrypted or stored in secret managers that are not directly accessible for scanning.