Euro Security Watch with Mathew J. Schwartz

Access Management

Root Admin User: When Do Common Usernames Pose a Threat?

Honeypot Hits Reinforce Need for Strong Passwords and Multifactor Authentication
Root Admin User: When Do Common Usernames Pose a Threat?
Image: Shutterstock

Is the default username on any of your internet-exposed remote services root, admin, user or test? If so, it's already being targeted by more than half of the automated, remote hack attacks seen in the wild, said Jesse La Grew, CISO at Wisconsin's Madison College and also a handler for the SANS Institute Internet Storm Center.

See Also: Nudge Toolkit: Your Key to Enhanced Cybersecurity

La Grew's findings come from the 3.7 million usernames collected via attacks that targeted his DShield honeypot over the past 16 months. Of all username submissions, one was clearly the most popular: "root," accounting for 48% of all login attempts. Its prevalence isn't surprising, he said, since" root" is the default username in Linux for the remote-access secure shell - SSH - network protocol, and "SSH is a common attack protocol" cataloged by honeypots.

The trouble with usernames is that many are built-in defaults, and many more can be easily guessed. This begs the following question: Do commonly used usernames pose a security risk?

Experts say the short answer is: only if a known or guessable username is paired with a weak password. Hence one takeaway from La Grew's honeypot data is that it's more important than ever for security managers to have in place policies and procedures designed to ruthlessly eliminate and block the use of weak passwords, especially for remote services.

Failing to do so poses well-known risks. "Knowledge of a default user account can help in brute force attacks," La Grew said. "If the username is already known, only the password needs to be guessed" - unless the account is also protected with multifactor authentication. This isn't foolproof either, but is much more difficult to defeat.

Use Strong Authentication, Cryptographic Keys

The honeypot findings are a reminder that for protecting accounts, "strong authentication, such as MFA, is the best and only real protection," said Johannes Ullrich, dean of research at SANS and founder of its Internet Storm Center. He added that for securing remote access, it's best to employ public key authentication with an encrypted service such as SSH, and that "telnet or other non-encrypted channels like FTP should not be used no matter what authentication method is enabled."

While FTP might sound like a blast from the past, security firm Rapid7 in 2018 said 21 million FTP servers are still internet-connected. Chances are that many of them haven't gone away and may never disappear altogether.

Attackers apparently think so too: "ftpuser" was the tenth-most-common username tried by attackers who targeted La Grew's honeypot.

"Seeing things like 'ftpuser' is sad, as FTP should really not be used any more. But even with FTP disabled, the username may still exist and work for SSH or telnet logins," Ullrich told me.

Scotland-based cybersecurity expert David Stubley said that based on his incident management experience, far too many organizations still use default usernames paired with default credentials. "Think 'admin: admin.' And yes, we still find such accounts in production environments," he said.

Another repeat challenge remains "hardcoded and non-documented usernames/passwords," often in internet of things devices and device firmware, Stubley said. "These accounts are created by the manufacturer - sometimes without any documentation pointing these accounts out to the end user and oftentimes existing within environments for many years."

Hackers Keep Trying Simple Passwords

La Grew's honeypot recorded that for malicious attempts to gain access to SSH with the username "root," the password most often tested by attackers was "345gs5662d34," followed by an empty password field, "root," "123456," "1234," "password" and "12345."

What "345gs5662d34" refers to isn't clear, and La Grew's honeypot only saw it being used as both the username and the password. One suggestion is that it might be the foreign equivalent of a phrase such as "my password" being entered into a non-English-language keyboard.

Regardless, the honeypot data reinforces long-standing security advice to avoid using weak or previously used passwords.

Might the same logic be applied as well to usernames, to further complicate brute force attacks? Ullrich does not recommend attempting username security via obscurity. "I am not a fan of requiring 'nonstandard' usernames," he said. "The security of the account should not depend on the username, but the credentials used, which if possible should be cryptographic keys - not passwords."

Removing or Restricting Default Accounts

One strategy experts recommend is to eliminate default accounts, so long as doing so doesn't break functionality or interdependencies. "Where possible, organizations should look to eliminate default usernames - particularly for those accounts with administrative access," said Brian Honan, CEO of Dublin-based BH Consulting.

This won't always be possible. "Some systems do not allow the default accounts to be disabled or renamed, so organizations need to ensure those accounts are protected by strong passwords and multifactor authentication and to restrict use of those accounts to only trusted devices," he said.

La Grew said organizations can also disable remote access for default accounts such as "root" and instead have "users use their own accounts and request privileges (sudo) when necessary." The Linux command sudo - short for "super user do" or "substitute user do" - allows a system administrator to temporarily delegate selected root-level rights to an account or group.

Delegation can facilitate needed granularity, not least for administrators. "One of the larger risks I see with the use of generic or default user accounts is the lack of ability to audit who is doing what," he told me.

Such auditing facilitates better logging and monitoring, especially to spot unusual activity. When a breach occurs, logs are essential for tracing how someone in possession of a username - be they a malicious insider or an outside attacker who compromised the credentials - traversed the network and what information they may have potentially viewed, altered or stolen.

When all goes well, properly handled usernames keep hackers from getting in. When things go wrong, good username practices can also help investigators figure out what happened.



About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe, ISMG

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the executive editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, among other publications. He lives in Scotland.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.eu, you agree to our use of cookies.