As many as 91,000 LG TVs face the risk of being commandeered unless they receive a just-released security update patching four critical vulnerabilities discovered late last year.
The vulnerabilities are found in four LG TV models that collectively comprise slightly more than 88,000 units around the world, according to results returned by the Shodan search engine for Internet-connected devices. The vast majority of those units are located in South Korea, followed by Hong Kong, the US, Sweden, and Finland. The models are:
Starting Wednesday, updates are available through these devices’ settings menu.
Got root?
According to Bitdefender—the security firm that discovered the vulnerabilities—malicious hackers can exploit them to gain root access to the devices and inject commands that run at the OS level. The vulnerabilities, which affect internal services that allow users to control their sets using their phones, make it possible for attackers to bypass authentication measures designed to ensure only authorized devices can make use of the capabilities.
“These vulnerabilities let us gain root access on the TV after bypassing the authorization mechanism,” Bitdefender researchers wrote Tuesday. “Although the vulnerable service is intended for LAN access only, Shodan, the search engine for Internet-connected devices, identified over 91,000 devices that expose this service to the Internet.”
The key vulnerability making these threats possible resides in a service that allows TVs to be controlled using LG’s ThinkQ smartphone app when it’s connected to the same local network. The service is designed to require the user to enter a PIN code to prove authorization, but an error allows someone to skip this verification step and become a privileged user. This vulnerability is tracked as CVE-2023-6317.
Once attackers have gained this level of control, they can go on to exploit three other vulnerabilities, specifically:
CVE-2023-6318, which allows the attackers to elevate their access to root
CVE-2023-6319, which allows for the injection of OS commands by manipulating a library for showing music lyrics
CVE-2023-6320, which lets an attacker inject authenticated commands by manipulating the com.webos.service.connectionmanager/tv/setVlanStaticAddress application interface.
For the past year, previously unknown self-replicating malware has been compromising Linux devices around the world and installing cryptomining malware that takes unusual steps to conceal its inner workings, researchers said.
The worm is a customized version of Mirai, the botnet malware that infects Linux-based servers, routers, web cameras, and other so-called Internet of Things devices. Mirai came to light in 2016 when it was used to deliver record-setting distributed denial-of-service attacks that paralyzed key parts of the Internet that year. The creators soon released the underlying source code, a move that allowed a wide array of crime groups from around the world to incorporate Mirai into their own attack campaigns. Once taking hold of a Linux device, Mirai uses it as a platform to infect other vulnerable devices, a design that makes it a worm, meaning it self-replicates.
Dime-a-dozen malware with a twist
Traditionally, Mirai and its many variants have spread when one infected device scans the Internet looking for other devices that accept Telnet connections. The infected devices then attempt to crack the telnet password by guessing default and commonly used credential pairs. When successful, the newly infected devices target additional devices using the same technique. Mirai has primarily been used to wage DDoSes. Given the large amounts of bandwidth available to many such devices, the floods of junk traffic are often huge, giving the botnet as a whole tremendous power.
On Wednesday, researchers from network security and reliability firm Akamai revealed that a previously unknown Mirai-based network they dubbed NoaBot has been targeting Linux devices since at least last January. Instead of targeting weak telnet passwords, the NoaBot targets weak passwords connecting SSH connections. Another twist: Rather than performing DDoSes, the new botnet installs cryptocurrency mining software, which allows the attackers to generate digital coins using victims’ computing resources, electricity, and bandwidth. The cryptominer is a modified version of XMRig, another piece of open source malware. More recently, NoaBot has been used to also deliver P2PInfect, a separate worm researchers from Palo Alto Networks revealed last July.
Akamai has been monitoring NoaBot for the past 12 months in a honeypot that mimics real Linux devices to track various attacks circulating in the wild. To date, attacks have originated from 849 distinct IP addresses, almost all of which are likely hosting a device that’s already infected. The following figure tracks the number of attacks delivered to the honeypot over the past year.
“On the surface, NoaBot isn’t a very sophisticated campaign—it’s ‘just’ a Mirai variant and an XMRig cryptominer, and they’re a dime a dozen nowadays,” Akamai Senior Security Researcher Stiv Kupchik wrote in a report Wednesday. “However, the obfuscations added to the malware and the additions to the original source code paint a vastly different picture of the threat actors’ capabilities.”
The most advanced capability is how NoaBot installs the XMRig variant. Typically, when crypto miners are installed, the wallets’ funds are distributed to are specified in configuration settings delivered in a command line issued to the infected device. This approach has long posed a risk to threat actors because it allows researchers to track where the wallets are hosted and how much money has flowed into them.
NoaBot uses a novel technique to prevent such detection. Instead of delivering the configuration settings through a command line, the botnet stores the settings in encrypted or obfuscated form and decrypts them only after XMRig is loaded into memory. The botnet then replaces the internal variable that normally would hold the command line configuration settings and passes control to the XMRig source code.
Kupchik offered a more technical and detailed description:
In the XMRig open source code, miners can accept configurations in one of two ways — either via the command line or via environment variables. In our case, the threat actors chose not to modify the XMRig original code and instead added parts before the main function. To circumvent the need for command line arguments (which can be an indicator of compromise IOC and alert defenders), the threat actors had the miner replace its own command line (in technical terms, replacing argv) with more “meaningful” arguments before passing control to the XMRig code. The botnet runs the miner with (at most) one argument that tells it to print its logs. Before replacing its command line, however, the miner has to build its configuration. First, it copies basic arguments that are stored plaintext— the rig-id flag, which identifies the miner with three random letters, the threads flags, and a placeholder for the pool’s IP address (Figure 7).
Curiously, because the configurations are loaded via the xmm registers, IDA actually misses the first two loaded arguments, which are the binary name and the pool IP placeholder.
Enlarge/ NoaBot code that copies miner configurations
Akamai
Next, the miner decrypts the pool’s domain name. The domain name is stored, encrypted, in a few data blocks that are decrypted via XOR operations. Although XMRig can work with a domain name, the attackers decided to go the extra step, and implemented their own DNS resolution function. They communicate directly with Google’s DNS server (8.8.8.8) and parse its response to resolve the domain name to an IP address.
The last part of the configuration is also encrypted in a similar way, and it is the passkey for the miner to connect to the pool. All in all, the total configuration of the miner looks something like this:
-o --rig-id --threads –pass espana*tea
Notice anything missing? Yep, no wallet address.
We believe that the threat actors chose to run their own private pool instead of a public one, thereby eliminating the need to specify a wallet (their pool, their rules!). However, in our samples, we observed that miner’s domains were not resolving with Google’s DNS, so we can’t really prove our theory or gather more data from the pool, since the domains we have are no longer resolvable. We haven’t seen any recent incident that drops the miner, so it could also be that the threat actors decided to depart for greener pastures
