Two years ago when “Michael,” an owner of cryptocurrency, contacted Joe Grand to help recover access to about $2 million worth of bitcoin he stored in encrypted format on his computer, Grand turned him down.
Michael, who is based in Europe and asked to remain anonymous, stored the cryptocurrency in a password-protected digital wallet. He generated a password using the RoboForm password manager and stored that password in a file encrypted with a tool called TrueCrypt. At some point, that file got corrupted, and Michael lost access to the 20-character password he had generated to secure his 43.6 BTC (worth a total of about 4,000 euros, or $5,300, in 2013). Michael used the RoboForm password manager to generate the password but did not store it in his manager. He worried that someone would hack his computer and obtain the password.
“At [that] time, I was really paranoid with my security,” he laughs.
Grand is a famed hardware hacker who in 2022 helped another crypto wallet owner recover access to $2 million in cryptocurrency he thought he’d lost forever after forgetting the PIN to his Trezor wallet. Since then, dozens of people have contacted Grand to help them recover their treasure. But Grand, known by the hacker handle “Kingpin,” turns down most of them, for various reasons.
Grand is an electrical engineer who began hacking computing hardware at age 10 and in 2008 cohosted the Discovery Channel’s Prototype This show. He now consults with companies that build complex digital systems to help them understand how hardware hackers like him might subvert their systems. He cracked the Trezor wallet in 2022 using complex hardware techniques that forced the USB-style wallet to reveal its password.
But Michael stored his cryptocurrency in a software-based wallet, which meant none of Grand’s hardware skills were relevant this time. He considered brute-forcing Michael’s password—writing a script to automatically guess millions of possible passwords to find the correct one—but determined this wasn’t feasible. He briefly considered that the RoboForm password manager Michael used to generate his password might have a flaw in the way it generated passwords, which would allow him to guess the password more easily. Grand, however, doubted such a flaw existed.
Michael contacted multiple people who specialize in cracking cryptography; they all told him “there’s no chance” of retrieving his money. But last June he approached Grand again, hoping to convince him to help, and this time Grand agreed to give it a try, working with a friend named Bruno in Germany who also hacks digital wallets.
If you build a gadget that connects to the Internet and sell it in the United Kingdom, you can no longer make the default password “password.” In fact, you’re not supposed to have default passwords at all.
A new version of the 2022 Product Security and Telecommunications Infrastructure Act (PTSI) is now in effect, covering just about everything that a consumer can buy that connects to the web. Under the guidelines, even the tiniest Wi-Fi board must either have a randomized password or else generate a password upon initialization (through a smartphone app or other means). This password can’t be incremental (“password1,” “password54”), and it can’t be “related in an obvious way to public information,” such as MAC addresses or Wi-Fi network names. A device should be sufficiently strong against brute-force access attacks, including credential stuffing, and should have a “simple mechanism” for changing the password.
There’s more, and it’s just as head-noddingly obvious. Software components, where reasonable, “should be securely updateable,” should actually check for updates, and should update either automatically or in a way “simple for the user to apply.” Perhaps most importantly, device owners can report security issues and expect to hear back about how that report is being handled.
Violations of the new device laws can result in fines up to 10 million pounds (roughly $12.5 million) or 4 percent of related worldwide revenue, whichever is higher.
Besides giving consumers better devices, these regulations are aimed squarely at malware like Mirai, which can conscript devices like routers, cable modems, and DVRs into armies capable of performing distributed denial-of-service attacks (DDoS) on various targets.
As noted by The Record, the European Union’s Cyber Resilience Act has been shaped but not yet passed and enforced, and even if it does pass, would not take effect until 2027. In the US, there is the Cyber Trust Mark, which would at least give customers the choice of buying decently secured or genially abandoned devices. But the particulars of that label are under debate and seemingly a ways from implementation. At the federal level, a 2020 bill tasked the National Institutes of Standard and Technology with applying related standards to connected devices deployed by the feds.
Everyone with a Roku TV or streaming device will eventually be forced to enable two-factor authentication after the company disclosed two separate incidents in which roughly 600,000 customers had their accounts accessed through credential stuffing.
Credential stuffing is an attack in which usernames and passwords exposed in one leak are tried out against other accounts, typically using automated scripts. When people reuse usernames and passwords across services or make small, easily intuited changes between them, actors can gain access to accounts with even more identifying information and access.
In the case of the Roku attacks, that meant access to stored payment methods, which could then be used to buy streaming subscriptions and Roku hardware. Roku wrote on its blog, and in a mandated data breach report, that purchases occurred in “less than 400 cases” and that full credit card numbers and other “sensitive information” was not revealed.
The first incident, “earlier this year,” involved roughly 15,000 user accounts, Roku stated. By monitoring these accounts, Roku identified a second incident, one that touched 576,000 accounts. These were collectively “a small fraction of Roku’s more than 80M active accounts,” the post states, but the streaming giant will work to prevent future such stuffing attacks.
The affected accounts will have their passwords reset and will be notified, along with having charges reversed. Every Roku account, when next requiring a login, will now need to verify their account through a link sent to their email address. Alternatively, one can use the device ID of any linked Roku device, according to Roku’s support page. (Forcing this upgrade yourself is probably a good idea for past or present Roku owners.)
Security blog BleepingComputer reported around the time of the incident that breached Roku accounts were sold for as little as 50 cents each and likely obtained using commonly available stuffing tools that bypass brute-force protections through proxies and other means. BleepingComputer reported that “a source” tied Roku’s recent updates to its Dispute Resolution Terms, which all but locked Roku devices until a customer agreed, to the fraudulent activity. Roku told BleepingComputer that the two were not related.
Attackers have transformed hundreds of hacked sites running WordPress software into command-and-control servers that force visitors’ browsers to perform password-cracking attacks.
A web search for the JavaScript that performs the attack showed it was hosted on 708 sites at the time this post went live on Ars, up from 500 two days ago. Denis Sinegubko, the researcher who spotted the campaign, said at the time that he had seen thousands of visitor computers running the script, which caused them to reach out to thousands of domains in an attempt to guess the passwords of usernames with accounts on them.
Visitors unwittingly recruited
“This is how thousands of visitors across hundreds of infected websites unknowingly and simultaneously try to bruteforce thousands of other third-party WordPress sites,” Sinegubko wrote. “And since the requests come from the browsers of real visitors, you can imagine this is a challenge to filter and block such requests.”
Like the hacked websites hosting the malicious JavaScript, all the targeted domains are running the WordPress content management system. The script—just 3 kilobits in size—reaches out to an attacker-controlled getTaskURL, which in turn provides the name of a specific user on a specific WordPress site, along with 100 common passwords. When this data is fed into the browser visiting the hacked site, it attempts to log in to the targeted user account using the candidate passwords. The JavaScript operates in a loop, requesting tasks from the getTaskURL, reporting the results to the completeTaskURL, and then performing the steps again and again.
A snippet of the hosted JavaScript appears below, and below that, the resulting task:
With 418 password batches as of Tuesday, Sinegubko has concluded the attackers are trying 41,800 passwords against each targeted site.
Sinegubko wrote:
Attack stages and lifecycle
The attack consists of five key stages that allow a bad actor to leverage already compromised websites to launch distributed brute force attacks against thousands of other potential victim sites.
Stage 1: Obtain URLs of WordPress sites. The attackers either crawl the Internet themselves or use various search engines and databases to obtain lists of target WordPress sites.
Stage 2: Extract author usernames. Attackers then scan the target sites, extracting real usernames of authors that post on those domains.
Stage 3: Inject malicious scripts. Attackers then inject their dynamic-linx[.]com/chx.js script to websites that they have already compromised.
Stage 4: Brute force credentials. As normal site visitors open infected web pages, the malicious script is loaded. Behind the scenes, the visitors’ browsers conduct a distributed brute force attack on thousands of target sites without any active involvement from attackers.
Stage 5: Verify compromised credentials. Bad actors verify brute forced credentials and gain unauthorized access to sites targeted in stage 1.
So, how do attackers actually accomplish a distributed brute force attack from the browsers of completely innocent and unsuspecting website visitors? Let’s take a look at stage 4 in closer detail.
Distributed brute force attack steps:
When a site visitor opens an infected web page, the user’s browser requests a task from the hxxps://dynamic-linx[.]com/getTask.php URL.
If the task exists, it parses the data and obtains the URL of the site to attack along with a valid username and a list of 100 passwords to try.
For every password in the list, the visitor’s browser sends the wp.uploadFile XML-RPC API request to upload a file with encrypted credentials that were used to authenticate this specific request. That’s 100 API requests for each task! If authentication succeeds, a small text file with valid credentials is created in the WordPress uploads directory.
When all the passwords are checked, the script sends a notification to hxxps://dynamic-linx[.]com/completeTask.php that the task with a specific taskId (probably a unique site) and checkId (password batch) has been completed.
Finally, the script requests the next task and processes a new batch of passwords. And so on indefinitely while the infected page is open.
As of Tuesday, the researcher had observed “dozens of thousands of requests” to thousands of unique domains that checked for files uploaded by the visitor browsers. Most files reported 404 web errors, an indication that the login using the guessed password failed. Roughly 0.5 percent of cases returned a 200 response code, leaving open the possibility that password guesses may have been successful. On further inspection, only one of the sites was compromised. The others were using non-standard configurations that returned the 200 response, even for pages that weren’t available.
Over a four-day span ending Tuesday, Sinegubko recorded more than 1,200 unique IP addresses that tried to download the credentials file. Of those, five addresses accounted for over 85 percent of the requests:
IP
%
ASN
146.70.199.169
34.37%
M247, RO
138.199.60.23
28.13%
CDNEXT, GB
138.199.60.32
10.96%
CDNEXT, GB
138.199.60.19
6.54%
CDNEXT, GB
87.121.87.178
5.94%
SOUZA-AS, BR
Last month, the researcher observed one of the addresses—87.121.87.178—hosting a URL used in a cryptojacking attack. One possibility for the change is that the earlier campaign failed because the malicious URL it relied on wasn’t hosted on enough hacked sites and, in response, the same attacker is using the password-cracking script in an attempt to recruit more sites.
As Sinegubko notes, the more recent campaign is significant because it leverages the computers and Internet connections of unwitting visitors who have done nothing wrong. One way end users can stop this is to use NoScript or another tool that blocks JavaScript from running on unknown sites. NoScript breaks enough sites that it’s not suitable for less experienced users, and even those with more experience often find the hassle isn’t worth the benefit. One other possible remedy is to use certain ad blockers.
