📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
DAY 17 OF 100
PHASE 2: WEB SECURITY
🟢 Day 17 — Security Misconfiguration
Day 100 — Professional Pentester
← Day 16: Broken Access Control
Day 18: File Upload Vulnerabilities →
17
Of every vulnerability category we’ve studied so far, security misconfiguration is the one that requires the least sophistication to exploit and delivers some of the most immediate, dramatic access. An admin panel at /admin with credentials admin:admin. An S3 bucket set to public with confidential documents inside. A phpinfo() page exposing database passwords. These findings don’t require SQL injection knowledge or CSRF exploits — they require knowing where to look.
Security misconfiguration appears on every professional assessment I’ve ever run — not occasionally, not in legacy systems only. Every time, without exception. Today you’ll learn a systematic approach to finding these issues in the first ten minutes of any engagement.
OWASP A05:2021 — Security Misconfiguration — is the result of software and systems that ship with insecure defaults, or that are deployed without proper hardening. The problem is systemic: developers focus on building features, not disabling unnecessary ones. Administrators deploy quickly without reading the hardening guides. The result is systems that are technically functional but leave doors open that attackers walk straight through.
📋 Day 17 Contents
- Why Misconfiguration Is So Common
- Default Credentials — The Lowest Hanging Fruit
- Verbose Error Messages & Debug Mode
- Directory Listing — The Open Filing Cabinet
- Unnecessary Features & Methods Enabled
- Cloud Storage Misconfigurations
- Missing Security Headers
- Nikto — Automated Misconfiguration Scanning
- Hardening Checklist
- Day 17 Practical Task
Why Security Misconfiguration Is So Prevalent
Unlike code-level vulnerabilities such as SQL injection or XSS, security misconfiguration doesn’t require a programming error. It’s the absence of correct security configuration — default settings left unchanged, features not disabled, documentation not read. Three factors make it uniquely persistent:
📦
Software ships with insecure defaults
Vendors prioritise ease of setup over security. Default credentials, open ports, and permissive configurations make the install wizard succeed on the first try. Hardening is left to the administrator — who often doesn’t do it.
⚡
Speed over security in deployment
Development teams deploy to production under time pressure. Security hardening steps — disabling debug mode, removing sample files, restricting CORS — are deferred and forgotten. Deployment pipelines rarely enforce security configuration as a prerequisite.
📈
Accumulation over time
Systems evolve. Features that were once necessary get abandoned but not disabled. Test environments become permanent. Admin accounts created for contractors are never deleted. Infrastructure grows faster than the security team’s ability to audit it.
Default Credentials — The Lowest Hanging Fruit
Default credentials are the first thing every security tester checks — before running any scanner, before looking at a single HTTP request. Vendors publish their default credentials in documentation. Attackers read that documentation. The question is whether the administrator did too.
Default credentials — common systems and what to try first
── Web Applications & Admin Panels ─────────────────────────
WordPress: admin / admin | admin / password
Joomla: admin / admin
Drupal: admin / admin
phpMyAdmin: root / (blank) | root / root
Tomcat Manager: tomcat / tomcat | admin / admin | tomcat / s3cret
Jenkins: admin / admin (check /login for version hints)
Grafana: admin / admin
Kibana: elastic / changeme
── Databases ───────────────────────────────────────────────
MySQL: root / (blank) | root / root | root / mysql
PostgreSQL: postgres / postgres | postgres / (blank)
MongoDB: (no auth by default on older versions)
Redis: (no auth by default — REQUIREPASS not set)
── Network Equipment ───────────────────────────────────────
Cisco routers: cisco / cisco | admin / admin
Linksys: admin / admin | admin / (blank)
Netgear: admin / password
Ubiquiti: ubnt / ubnt
Default credential databases (reference resources)
https://cirt.net/passwords ← 2,000+ default credential entries
/usr/share/seclists/Passwords/Default-Credentials/ ← Kali local lists
Test with Hydra using a default creds list
hydra -C /usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt \
192.168.56.101 http-get /manager/html
🎯 Real assessment impact: Default credentials on a Tomcat Manager panel give direct remote code execution via WAR file upload. Default Redis with no authentication on an internet-facing server means arbitrary data read/write and often full server compromise. Default credentials are not low-severity findings — they frequently lead to the highest-impact access in an engagement.
Verbose Error Messages & Debug Mode — Unintentional Intelligence
Error messages and debug output designed for developers become a goldmine for attackers when they reach production. A detailed error page can reveal the full file system path, software version, database schema, configuration values, and even credentials — in a single response to a malformed request.
Verbose errors — what they reveal and how to trigger them
Triggering errors — submit unexpected input to any parameter
GET /product?id=abc # String where integer expected
GET /search?q=’ # Single quote for SQL errors
GET /api/user/99999999 # Non-existent ID
POST /api/data Content-Type: text/xml # Wrong content type
What verbose errors expose:
PHP Warning: mysql_connect(): Access denied for user ‘root’@’localhost’
using password: YES in /var/www/html/config.php on line 12
→ Database username, server path, config file location revealed
Django/Python traceback:
File “/home/deploy/app/views.py”, line 45, in get_user
SECRET_KEY = ‘django-insecure-abc123xyz789…’
→ SECRET_KEY in traceback = CSRF token forgery + session signing key
Microsoft SQL Server error:
Unclosed quotation mark after character string ”.
Incorrect syntax near ”1”
Server: Microsoft SQL Server 2019 (RTM) – 15.0.2000.5
→ Database type, exact version confirmed → look for version-specific CVEs
Debug mode — disable in every framework before deploying
Django: DEBUG = False in settings.py
Laravel: APP_DEBUG=false in .env
Node.js: NODE_ENV=production (not development)
Rails: config.consider_all_requests_local = false
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)