Why Weak Passwords and Unpatched Redis Threaten Operational Security

Introduction

Operational security is the foundation of enterprise security, especially for internet companies. Unlike web, mobile, or business security, it resides at the lowest layer, involving servers, network devices, and basic applications. A security incident in ops usually signals flawed processes and can affect many machines and core business services.

Are Weak Passwords Just "123456"?

The most critical issue in ops security is weak passwords. The following examples are all considered weak because they are common keyboard patterns on English keyboards and have long been listed as insecure:

123456

111111

qwe@123

1qaz2wsx

1qaz@wsx

6yhnNHY^

A strong password should be longer than eight characters and consist of a random mix of upper‑case, lower‑case letters, numbers, and special symbols without predictable patterns.

How Dangerous Is an Unpatched Public Vulnerability?

The 2015 Redis incident showed that if Redis runs as root without authentication, an attacker can write an

authorized_keys

file to

/root/.ssh/

and gain password‑less SSH access. The exploitation steps are illustrated below:

Generate a key pair locally.

Save the key to a file.

Write a

crackit

key to vulnerable Redis instances on the Internet.

Rename the key to

authorized_keys

in the target filesystem.

Attempt to log in to the compromised machine via SSH.

Key Questions from This Example

Why run Redis as the root user?

Why is SSH not using certificate authentication?

Why is Redis unauthenticated?

Why is the Redis port exposed to the public Internet without ACLs or whitelisting?

Changing Ports Won’t Fool Attackers

Simply moving a service to a non‑standard port does not reduce risk. In one case, an FTP service originally on port 21 was moved to 85 and SSH from 22 to 87; attackers still identified the services via banner grabbing and exploited weak credentials.

Your Password May Have Been Used Multiple Times

Since 2011, over a billion data‑leak records have been disclosed, covering major internet companies, social platforms, mobile manufacturers, government sites, domain registrars, and online games. Much of the undisclosed data is sold on “social‑engineering databases” (社工库) for profit, either by providing masked results for free or selling full plaintext data for 68–128 RMB per VIP account.

These leaked credentials often aid APT attacks. Therefore, avoid using corporate email or credentials on personal social platforms, and protect internal systems (VPN, email, OA) with two‑factor authentication or SMS verification.

Scary Cases from Third‑Party Vulnerability Platforms

The WooYun platform aggregates vulnerability reports from researchers. Below are several recent ops‑security‑related cases.

Case 1: Lateral Movement Inside a Large E‑Commerce Site

Code was pushed to a public repository (e.g., GitHub) with email‑sending functionality that used the company’s mail server. The mail server was linked to VPN authentication without MFA, allowing an attacker to log into the corporate VPN and roam the internal network.

Issues Exposed

Source code published to a public platform.

Email configuration exposed internal mail server.

VPN shared credentials with email and lacked MFA.

Attacker leveraged compromised VPN account for internal network traversal.

Case 2: Compromising a Popular Navigation App Company

Similar code‑leak scenario, plus an unprotected address‑book API that allowed enumeration, followed by a bulk weak‑password attack using BurpSuite, eventually retrieving a plaintext

password.txt

from an ops employee’s mailbox.

Issues Exposed

Public code repository.

Unrestricted email‑sending configuration.

Address‑book enumeration without limits.

Mass weak‑password cracking.

Exposure of plaintext credentials via email.

Case 3: Search Engine Vulnerability Leading to Massive Data Leak

Missing security checks before release exposed the

.git

directory, allowing attackers to retrieve source code, extract a

UC_KEY

, obtain a webshell, and pivot into the internal network.

Issues Exposed

No security audit;

.git

directory leaked.

Source code revealed internal keys.

Webshell used for internal access.

Further internal compromise via the webshell.

Case 4: Zabbix Misconfiguration on an Established Portal Site

Default Zabbix credentials (admin/zabbix) were left unchanged, enabling command execution, remote shell acquisition, and privilege escalation within the internal network.

Issues Exposed

Default Zabbix credentials.

Execution of arbitrary commands via Zabbix modules.

Server callbacks to attacker-controlled machines.

Acquisition of Zabbix shell.

Further privilege escalation inside the network.

Final Summary

Security is holistic; protecting a system does not rely on a single strong point but on identifying and shoring up weak spots. Do not assume safety simply because no incident has occurred—maintain a constant sense of crisis. — Quote from WooYun white‑hat “Zhu Zhu Xia”