Unfortunately, the release date is coincide with my qualifying exam =(
Unfortunately, the release date is coincide with my qualifying exam =(
A 14-year-old hacker bricked at least 4,000 Internet of Things devices with a new strain of malware called Silex this week. Threatpost talks to the researcher who discovered the malware. A 14-year-old hacker used a new strain of malware this week to brick up to 4,000 insecure Internet of Things devices – before abruptly shutting down his command and control server.
The malware, dubbed Silex, was first discovered by Larry Cashdollar, senior security intelligence response engineer at Akamai, on his honeypot. The malware, like the BrickerBot malware in 2017, targeted insecure IoT devices and rendered them unusable.
Specifically targeted were Internet of Things (IoT) devices running on the Linux or Unix operating systems, which had known or guessable default passwords. The malware would trash the devices’ storage, remove their firewalls and network configuration, and finally fully halt them.
The hacker, who got in touch with Cashdollar via Twitter, was “trying to take down targets for other script kiddies who might be looking to build botnets and he was just getting sick of it,” said Cashdollar. “So his sole motivation was to remove the vulnerable IoT devices that botnets are built on to stop other script kiddies from building botnets and I guess aggravating him with it.”
Within the first few hours of discovery, the malware had bricked 2,000 devices. Cashdollar told Threatpost that the total number had reached as high as 4,000. Then, he said, the hacker abruptly took the command and control server offline.
“What ended up happening was the person who wrote this [malware] didn’t expect all this attention and didn’t like it and made him nervous so he decided to stop the malware from spreading and decided that he wasn’t going to change it anymore to make it more destructive than it already had been, he’s planning on quitting, I think,” Cashdollar said.
Still, the incident is yet another reminder of the slew of IoT devices that consumers are actively still using, he said: “Vendors are coming to terms with having to build secure devices that can be updated. I just don’t know how many of them have actually gotten on board versus ones that are ignoring it.”
Lindsey O’Donnell: Welcome to the Threatpost podcast. This is Lindsey O’Donnell with Threatpost and I am here today with Larry Cashdollar, the senior Security Intelligence Response engineer at Akamai. Larry, how’s your Thursday going?
Larry Cashdollar: It’s pretty good. I’m excited for some warm weather.
LO: Same here, hopefully some beach days coming up. Today we’re going to talk about a discovery that you made this week about malware that is targeting and bricking IoT devices. But first, just to start out, Larry, do you mind giving a quick introduction of yourself and what you do?
LC: I’ve been doing sysadmin slash security research vulnerability research since the late 90s. I usually do a lot of vulnerability, research and discovery, finding vulnerabilities and writing exploits. But I tend to turn my focus towards phishing campaigns or malware depending on what mood I’m in.
LO: Great. Let’s talk about this new malware called Silex that is targeting and wiping the firmware of IoT devices that you discovered earlier this week. So you spotted this earlier this week attacking devices, can you kind of give some color into how you first stumbled upon this?
LC: So I have a honeypot that I run off my home network since I work at home. And I found that home networks are typically targeted by malware a lot more than say, a virtual private server network is, I suspect that the malware authors know this and specifically highlight user end networks like Comcast or Spectrum you know, those internet service providers, right, so I run my honeypot off of my home Comcast network, and it gets a lot of attack traffic. And I usually check my traps every day, like a lobsterman, and see what I’ve caught overnight, and I’d actually shut down my honeypot in order to rework some of the power consumption in my lab in the basement, it tends to keep my basement at 72 degrees, which is kind of annoying in the summer months. So I, I reshuffled some devices around and then I shut off my lab and I turned it back on. And after a few hours, I noticed that my honeypot was being hit pretty hard. And I started examining some of the binaries that I saw, and noticed that one of them had a particular string, where the malware author was calling out other malware botnet-slash-script kitties, saying that he was sick and tired of them running these botnets and then he was just going to brick all of the devices that were out and vulnerable to default login credentials. So I’m paraphrasing his actual statement, but he pretty much left a message in there. So I thought that was pretty interesting and then looking at the destructive commands in the botnet source code I figured I will just simply tweet it out because I was pretty strapped for time. I’ve been working on other stuff for Akamai, some other research. Normally I write something up in our blog, and I didn’t have time for this, and then tweeted it out. And it got a lot of attention off Twitter. So it ended up making the rounds with the news pretty quickly.
LO: So it was targeting IoT devices with default passwords. So I feel like that’s such a prolific issue, that there must be a lot of open vulnerable devices out there, too.
LC: Yeah, it’s using Telnet, which is an older protocol and that predates the encrypted SSH protocol. And typically IoT devices, the ones that are vulnerable still have that Telnet protocol running. Yeah, it’s typically it’s targeting IoT devices that have known default login passwords and usernames and then literally doing as much destructive damage to the device as possible before the device is rendered unusable.
LO: So did you get a sense of what types of IoT devices were being targeted or was it mostly very vague to that degree?
LC: It was a broad spectrum attack where it was targeting any Linux or Unix-like operating system that had any of the known or guessable default passwords, you know password combinations like “root” and “admin” or “root password.” So at this time it was targeting was targeting your consumer-grade cameras, DVRs, routers, things like that, that have been known in the past to be deployed with known login credentials.
LO: So it’s targeting these IoT devices – from a technical standpoint, how does it then go about bricking the devices? Is that something you were able to get any insight into?
LC: Yeah, first it tries to write a data from /dev/random to all of the disk partitions it discovers. So it looks for any mounted partitions or existing partitions on the storage that it sees. And then it writes over those partitions with contents from /dev/random, which will just be a bunch of garbage. Then it tries to shrink the partition table sizes down to one cylinder … which would probably make the … partitions extremely small and likely, I think, corrupt the partition tables, then it goes ahead and it deletes the network interfaces, it deletes the default route. So it disables the network connectivity of the device. And then it actually, if there’s any IP tables or firewall rules, it deletes the firewall rules and adds firewall rules to reject any outbound traffic or any traffic being forwarded through the device, so it pretty much takes it off the network, even after it’s been rendered a lobotomy for writing over all data on the disk. And then as a final step … it goes ahead and tries to delete any remaining files off of the storage. I’m not exactly sure how far it gets through this because the first couple of things are pretty destructive. I’m not sure if it makes it actually to the removal part, but that that would be the most likely one to succeed first on most operating systems, since that command is pretty generic across Unix so it’s pretty destructive. Right?
LO: Yeah, it sounds like it trashes their storage, their firewall rules, as you said, and stops the device entirely for the victims of this attack. On the user end of things would that just mean that the devices just completely stop? And there’s no way to get them started again? Or what does that mean from the consumers who are actually using these devices?
LC: I think consumers would have to reflash their device, the firmware on it, which for most consumers, this would be a lot more tedious than they’re willing to do when it comes to a $30 Wireless IP camera, they’re more likely going to throw the camera out and buy another one and just assume it just stopped working. That would be the really the only way.
LO: Wow. And you had mentioned in earlier reports this week that the number was at – I think you said 2,000 devices that were wiped – due to the malware in the first few hours of discovery. I mean, has the attack continued, has that number gone up at all?
LC: The number I think peaked at 4,000 and the command and control server was taken offline. And it looks like that pretty much stops the malware, as far as I can tell in its tracks as it, it first tries to reach out to the command and control server. And if it can’t reach it, it just hangs. Because I actually ran the malware on one of my spare Raspberry Pi’s and it hung when it was trying to reach the command control server. What ended up happening was the person who wrote this didn’t expect all this attention and didn’t like it and made him nervous so he decided to stop the malware from spreading and decided that he wasn’t going to change it anymore to make it more destructive than it already had been, he’s planning on quitting, I think.
LO: And we’ve seen something similar to this before. Right, Larry? It’s almost like BrickerBot, which for listeners, was the malware that back in 2017 attempted to permanently destroy insecure IoT devices as well. Did you see any similarities or differences between those two strains of malware?
LC: Yeah, it was. The BrickerBot malware, I think was built as a Python script I thought. This was actually contained different architectures – or binaries of different architectures – But the intent and you know the commands were similar. So it was it was similar to BrickerBot but implemented in a different way.
LO: Right, yeah, I feel like kind of the motive behind both BrickerBot and this malware was clearly to say, look how insecure IoT devices are, we need to destroy them so that they won’t be, at least for BrickerBot so that these devices wouldn’t be infected with Mirai. It’s definitely an interesting motive for sure. And I’m sure there’s a mixed bag of opinions out there in terms of either empathizing with this effort versus thinking that this is just malicious and not the right way to do things.
LO: I’m curious too I did see reports that pointed to a 14-year-old hacker who was behind this, is that something that you were able to get any insight into, or were those more, you know, third party reports?
LC: No he’s 14, he’s from Europe. I talked to him over Twitter, he reached out to me over Twitter over DM, and told me that he was planning on quitting because he didn’t expect this was going to be a big deal. And he got nervous and doesn’t want to get in any trouble. So he decided he was going to stop before things got worse, and then somebody had misattributed him to Iranian hackers, which really got him aggravated and scared, because he’s not Iranian and this had no motivation to do anything between Iran or the United States. It was just him trying to take down targets for other script kiddies who might be looking to build botnets and he was just getting sick of it. So his sole motivation was to remove the vulnerable IoT devices that botnets are built on to stop other script kiddies from building botnets and I guess aggravating him with it. The machine was hosted in Iran, the IP was, but we all know that IPs don’t mean attribution. Because you can easily proxy through IP addresses in any country you want and pretend to come from any country you want. So IPs don’t really mean anything. It’s just interesting to know you know where the IP was.
LC: So, you know, his choice of servers.
LO: I’m curious, taking a step back and looking at the IoT market in general, you know, it’s obviously insecure. And there’s obviously big issues and stemming right down to that default password issue that is really at the heart of all this. I’m curious your thoughts on the IoT security market in general and whether you think that more malware such as Silex, such as BrickerBot will be seen in the future?
LC: Uh, I’m hoping not, I think the IoT manufacturers have made some strides to secure devices. I’m not 100 percent positive that they’ve completely cleaned up the security. But I know that some vendors have removed some vulnerable services on devices and I’ve actually made devices upgradeable where they push new firmware out. I actually have an IoT device in my lab that has been asking me to update its firmware for a year. But I don’t want to because I want to keep it vulnerable for other testing. So I know that you know, vendors are coming to terms with having to build secure devices that can be updated. I just don’t know how many of them have actually gotten on board versus ones that are ignoring it. So I guess the future will tell if there’s still new devices being deployed and rampant botnet activity, we’ll know that they haven’t, they haven’t come full circle on their security standards.
LO: Well, fingers crossed that there’s a little more awareness out there from the vendors and manufacturers part. And then from the actual consumers themselves, I mean, is there any kind of best practices out there as well? In my opinion, it should be more on the vendors’ shoulders, but do you think that the consumers can really do anything?
LC: Generally, you know, if you’re, if you’re buying a device, and you’re buying it off of some third party site, like what’s the big Chinese one, Alibaba is it? You’re sort of taking a risk when you’re putting that device on your network. In regards to security, it’s more likely you might get a better device from something that might be like a Ubiquitirouter would be a better choice than, say, a highway router from China. So that’s my recommendation is to stick to known vendors like Ubiquitithat are known to try and take some pretty serious seriously and patch their devices that they deploy.
LO: Larry, thank you so much for coming on to the Threatpost podcast today and telling us a little bit about your discovery of Silex and the story there. Sure. And once again, this is Lindsey O’Donnell with Threatpost talking to Larry Cashdollar of Akamai about IoT security and the Silex malware. Catch us next week on the Threatpost podcast.
This is why you should not listen and follow blindly successful CEO or businessman. We need to analyse what is the sacrifice of their success – is it more important than the success itself?
Strip-mining the planet to maximize profits isn’t progressive or renewable – it’s just exploitive and destructive.
How do we describe the finding that the planet’s most widely-owned super-corporation is destroying the planet to maximize its smartphone sales and profits? Shall we start with “inconvenient?” Yes, we’re talking about Apple, famous for coercing customers to upgrade their Apple phones and other gadgets if not annually then every couple years, as the most effective way to maximize profits.
Unfortunately, smartphones require stripmining the planet, as described in this report, Smartphones Are Killing The Planet Faster Than Anyone Expected Researchers are sounding the alarm after an analysis showed that buying a new smartphone consumes as much energy as using an existing phone for an entire decade.
Smartphones are particularly insidious for a few reasons. With a two-year average life cycle, they’re more or less disposable. The problem is that building a new smartphone–and specifically, mining the rare materials inside them–represents 85% to 95% of the device’s total CO2 emissions for two years. That means buying one new phone takes as much energy as recharging and operating a smartphone for an entire decade.
despite the recycling programs run by Apple and others, “based on our research and other sources, currently less than 1% of smartphones are being recycled,” Lotfi Belkhir, the study’s lead author, tells me.
The researchers point out that mobile apps actually reinforce our need for these 24/7 servers in a self-perpetuating energy-hogging cycle. More phones require more servers. And with all this wireless information in the cloud, of course we’re going to buy more phones capable of running even better apps.
Google, Facebook, and Apple have all pledged to move to 100% renewable energy in their own operations. In fact, all of Apple’s servers are currently run on renewable power. “It’s encouraging,” says Belkhir of these early corporate efforts. “But I don’t think it’d move the needle at all.”
As consumers, we have more reason than ever to hesitate when it comes to our next shiny tech splurge. The bottom line is that we need to buy less, and engage less, for the health of this entire planet.
This is true not just for Apple, of course, but for Samsung and other manufacturers, but Apple has the rose-tinted “progressive” reputation, and so we should start with Apple, which has always been particularly aggressive in crippling the functionality of older products with a variety of tried and true tricks to force customers to buy a new device (sorry, Bucko, your old phone can’t handle OS X.yz so it’s now a useless brick).
It’s not just CO2–smartphone components demand the expansion of environmentally destructive mining for essentials such as lithium:
Climate Change’s Great Lithium Problem: The future of technology metal mining in South America and elsewhere could look eerily similar to centuries of colonial exploitation, dressed up as environmentalism: American highways could buzz with Teslas traveling between sprawling suburban rooftops and office parks decked out in solar panels, all premised on capitalist profiteering and disregard for indigenous rights.
What would happen to Apple’s gargantuan profits were it to design, build and market smartphones and other devices to last a decade or longer? We all know what would happen: sales and profits would fall off a cliff, and hundreds of billions of dollars in stock market “wealth” would vanish as Apple stock declined to align with much lower profits and the end of the “endless growth” story.
(Apple enthusiasts claim Apple TV and other services will replace profits from phones, but at this point that is speculation without much supporting evidence.)
The disastrous environmental, social and political consequences of maximizing sales and profits regardless of “externalities” is not just Apple’s problem–it’s the entire developed world’s problem. As for Apple’s vaunted “renewable power”–the alternative energy technologies are not actually renewables, they’re actually just “replaceables,” in analyst / author Nate Hagens’ succinct terminology; solar panels and wind turbines must be replaced every 20 years or so, if not earlier, and as a result their lifecycle costs are permanently high.
What looks “paid for” in year 19 suddenly becomes expensive in year 21.
Stripmining the planet to maximize profits isn’t progressive or renewable–it’s just exploitive and destructive. “Renewable power,” blah blah blah– corporate PR is no replacement for making truly durable-for-a-decade products that drastically reduce the disastrous environmental, social and political consequences of ever higher growth chasing ever higher profits.
* * *
Since I am currently doing PhD in IoT security, I am thinking of starting to post more technological posts for myself and our readers.
Interesting article from Threat Post:
Smart voice assistants can be hijacked by attackers using lasers to send them remote, inaudible commands. Researchers have discovered a new way to hack Alexa and Siri smart speakers merely by using a laser light beam. No physical access of the victims’ device, or owner interaction, is needed to launch the hack, which allows attackers to send voice assistants inaudible commands such as unlocking doors.
The attack, dubbed “light commands,” leverages the design of smart assistants’ microphones. These are called microelectro-mechanical systems (MEMS) microphones, which work by converting sound (voice commands) into electrical signals – but in addition to sound, researchers found that MEMS microphones also react to light being aimed directly at them.
Researchers said that they were able to launch inaudible commands by shining lasers – from as far as 110 meters, or 360 feet – at the microphones on various popular voice assistants, including Amazon Alexa, Apple Siri, Facebook Portal, and Google Assistant.
[B]y modulating an electrical signal in the intensity of a light beam, attackers can trick microphones into producing electrical signals as if they are receiving genuine audio,” said researchers with the University of Michigan and the University of Electro-Communications (Tokyo) in a Monday research paper.
MEMS microphones feature a small, built-in plate called the diaphragm, which when hit with sounds or light sends electrical signals that are translated into commands. Instead of voice commands, researchers found that they could “encode” sound using the intensity of a laser light beam, which causes the diaphragm to move and results in electrical signals representing the attacker’s commands.
Daniel Genkin, one of the researchers who discovered the attack, told Threatpost that they were able to specifically encode sound based on the intensity of the light beam – so strong sound implies a lot of light while weak sounds make little light.
To develop such commands using the laser beam, researchers measured light intensity (using a photo-diode power sensor) and tested the impact of various light intensities (or diode currents) on microphone outputs.
“We recorded the diode current and the microphone’s output using a Tektronix MSO5204 oscilloscope,” they said. “The experiments were conducted in a regular office environment, with typical ambient noise from human speech, computer equipment, and air conditioning systems.”
In a real-life attack, an attacker could stand outside a house and potentially shine a laser light onto a voice assistant that is visible through a window. From there, an attacker could command the voice assistant to unlock a door, make online purchases, remotely start vehicles or other malicious actions.
Below is a video demonstration of researchers sending commands to Google Home:
Worse, the attack can be mounted “easily and cheaply, “researchers said. They said that they used a simple laser pointer (available for as little as $14 on Amazon), along with a laser driver (designed to drive a laser diode by providing a current) and a sound amplifier to launch the attack. Researchers for their part used a blue Osram PLT5 450B 450-nm laser diode connected to a Thorlabs LDC205C current driver.
Attackers also may need gear for laser focusing, including a geared tripod head, commercially available telephoto lens or a telescope in order to see microphone ports from long distances.
Researchers tested the attack with a variety of devices that use voice assistants, including the Google NEST Cam IQ, Echo, iPhone XR, Samsung Galaxy S9 and Google Pixel 2. While the paper focused on Alexa, Siri, Portal and Google Assistant, any system that uses MEMS microphones and acts on data without additional user confirmation might be vulnerable, they said.
Researchers said they have not seen any indications that this attack have been maliciously exploited so far. They are currently collaborating with voice assistant vendors to mitigate against the attack.
The good news is that researchers have identified steps that could help protect against the attack, such as further authentication, sensor fusion techniques (such as requiring devices to acquire audio from multiple microphones) or implementing a cover on top of the microphone for attenuating the amount of light hitting the microphone.
“An additional layer of authentication can be effective at somewhat mitigating the attack,” they said. “Alternatively, in case the attacker cannot eavesdrop on the device’s response, having the device ask the user a simple randomized question before command execution can be an effective way at preventing the attacker from obtaining successful command execution.”
Threatpost has reached out to Apple and Facebook for further comment.
“Customer trust is our top priority and we take customer security and the security of our products seriously,” an Amazon spokesperson told Threatpost. “We are reviewing this research and continue to engage with the authors to understand more about their work.”
“We are closely reviewing this research paper,” a Google spokesperson told Threatpost. “Protecting our users is paramount, and we’re always looking at ways to improve the security of our devices.”
Yeah, taxi companies have to count for cost of gasoline, compliance to regulation, maintenance, etc, etc, whereas those ‘startup’ capturing market share by pumping trillions of dollars of investment fund – losing money like crazy – how does it even a business?