Page 3 of 27
It is amazing that this sort of thing can still happen:
…the list was compiled by scanning the entire internet for devices that were exposing their Telnet port. The hacker then tried using (1) factory-set default usernames and passwords, or (2) custom, but easy-to-guess password combinations.
Telnet? Default passwords? In 2020?
We have a long way to go to secure the IoT.
EDITED TO ADD (7/14): Apologies, but I previously blogged this story in January.
This study shows that most people don’t change their passwords after a breach, and if they do they change it to a weaker password.
Abstract: To protect against misuse of passwords compromised in a breach, consumers should promptly change affected passwords and any similar passwords on other accounts. Ideally, affected companies should strongly encourage this behavior and have mechanisms in place to mitigate harm. In order to make recommendations to companies about how to help their users perform these and other security-enhancing actions after breaches, we must first have some understanding of the current effectiveness of companies’ post-breach practices. To study the effectiveness of password-related breach notifications and practices enforced after a breach, we examine—based on real-world password data from 249 participants—whether and how constructively participants changed their passwords after a breach announcement.
Of the 249 participants, 63 had accounts on breached domains;only 33% of the 63 changed their passwords and only 13% (of 63)did so within three months of the announcement. New passwords were on average 1.3× stronger than old passwords (when comparing log10-transformed strength), though most were weaker or of equal strength. Concerningly, new passwords were overall more similar to participants’ other passwords, and participants rarely changed passwords on other sites even when these were the same or similar to their password on the breached domain.Our results highlight the need for more rigorous password-changing requirements following a breach and more effective breach notifications that deliver comprehensive advice.
News article.
EDITED TO ADD (6/2): Another news aricle. Slashdot thread.
EDITED TO ADD (7/1): This entry has been translated into Spanish.
Joshua Schulte, the CIA employee standing trial for leaking the Wikileaks Vault 7 CIA hacking tools, maintains his innocence. And during the trial, a lot of shoddy security and sysadmin practices are coming out:
All this raises a question, though: just how bad is the CIA’s security that it wasn’t able to keep Schulte out, even accounting for the fact that he is a hacking and computer specialist? And the answer is: absolutely terrible.
The password for the Confluence virtual machine that held all the hacking tools that were stolen and leaked? That’ll be 123ABCdef. And the root login for the main DevLAN server? mysweetsummer.
It actually gets worse than that. Those passwords were shared by the entire team and posted on the group’s intranet. IRC chats published during the trial even revealed team members talking about how terrible their infosec practices were, and joked that CIA internal security would go nuts if they knew. Their justification? The intranet was restricted to members of the Operational Support Branch (OSB): the elite programming unit that makes the CIA’s hacking tools.
The jury returned no verdict on the serious charges. He was convicted of contempt and lying to the FBI; a mistrial on everything else.
It’s a list of easy-to-guess passwords for IoT devices on the Internet as recently as last October and November. Useful for anyone putting together a bot network:
A hacker has published this week a massive list of Telnet credentials for more than 515,000 servers, home routers, and IoT (Internet of Things) “smart” devices.
The list, which was published on a popular hacking forum, includes each device’s IP address, along with a username and password for the Telnet service, a remote access protocol that can be used to control devices over the internet.
According to experts to who ZDNet spoke this week, and a statement from the leaker himself, the list was compiled by scanning the entire internet for devices that were exposing their Telnet port. The hacker than tried using (1) factory-set default usernames and passwords, or (2) custom, but easy-to-guess password combinations.
A malicious Chrome extension surreptitiously steals Ethereum keys and passwords:
According to Denley, the extension is dangerous to users in two ways. First, any funds (ETH coins and ERC0-based tokens) managed directly inside the extension are at risk.
Denley says that the extension sends the private keys of all wallets created or managed through its interface to a third-party website located at erc20wallet[.]tk.
Second, the extension also actively injects malicious JavaScript code when users navigate to five well-known and popular cryptocurrency management platforms. This code steals login credentials and private keys, data that it’s sent to the same erc20wallet[.]tk third-party website.
Another example of how blockchain requires many single points of trust in order to be secure.
New details:
At the CyberwarCon conference in Arlington, Virginia, on Thursday, Microsoft security researcher Ned Moran plans to present new findings from the company’s threat intelligence group that show a shift in the activity of the Iranian hacker group APT33, also known by the names Holmium, Refined Kitten, or Elfin. Microsoft has watched the group carry out so-called password-spraying attacks over the past year that try just a few common passwords across user accounts at tens of thousands of organizations. That’s generally considered a crude and indiscriminate form of hacking. But over the last two months, Microsoft says APT33 has significantly narrowed its password spraying to around 2,000 organizations per month, while increasing the number of accounts targeted at each of those organizations almost tenfold on average.
[…]
The hackers’ motivation—and which industrial control systems they’ve actually breached—remains unclear. Moran speculates that the group is seeking to gain a foothold to carry out cyberattacks with physically disruptive effects. “They’re going after these producers and manufacturers of control systems, but I don’t think they’re the end targets,” says Moran. “They’re trying to find the downstream customer, to find out how they work and who uses them. They’re looking to inflict some pain on someone’s critical infrastructure that makes use of these control systems.”
It’s unclear whether the attackers are causing any actual damage, or just gaining access for some future use.
Lots of them weren’t very good:
BSD co-inventor Dennis Ritchie, for instance, used “dmac” (his middle name was MacAlistair); Stephen R. Bourne, creator of the Bourne shell command line interpreter, chose “bourne”; Eric Schmidt, an early developer of Unix software and now the executive chairman of Google parent company Alphabet, relied on “wendy!!!” (the name of his wife); and Stuart Feldman, author of Unix automation tool make and the first Fortran compiler, used “axolotl” (the name of a Mexican salamander).
Weakest of all was the password for Unix contributor Brian W. Kernighan: “/.,/.,” representing a three-character string repeated twice using adjacent keys on a QWERTY keyboard. (None of the passwords included the quotation marks.)
I don’t remember any of my early passwords, but they probably weren’t much better.
Expandpass is a string expansion program. It’s “useful for cracking passwords you kinda-remember.” You tell the program what you remember about the password and it tries related passwords.
I learned about it in this article about Phil Dougherty, who helps people recover lost cryptocurrency passwords (mostly Ethereum) for a cut of the recovered value.
Many GPS trackers are shipped with the default password 123456. Many users don’t change them.
We just need to eliminate default passwords. This is an easy win.
EDITED TO ADD (9/12): A California law bans default passwords starting in 2020.
Stuart Schechter writes about the security risks of using a password manager. It’s a good piece, and nicely discusses the trade-offs around password managers: which one to choose, which passwords to store in it, and so on.
My own Password Safe is mentioned. My particular choices about security and risk is to only store passwords on my computer—not on my phone—and not to put anything in the cloud. In my way of thinking, that reduces the risks of a password manager considerably. Yes, there are losses in convenience.
Sidebar photo of Bruce Schneier by Joe MacInnis.