- IoT -

Last update 09.10.2017 13:14:50

Introduction  List  Kategorie  Subcategory 0  1  2  3  4  5


 



California IoT Cybersecurity Bill Signed into Law
2.10.2018 securityweek
IoT

California Governor Jerry Brown last week signed the country’s first Internet of Things (IoT) cybersecurity law, along with a controversial state-level net neutrality law.

The IoT cybersecurity law, SB-327, was introduced in February 2017 by Senator Hannah-Beth Jackson (D-Santa Barbara). SB-327 goes into effect on January 1, 2020, and it requires manufacturers of Internet-connected devices – such as TVs, phones, toys, household appliances and routers – to ensure that their products have “reasonable security features.” These security features should be able to protect sensitive customer information from unauthorized access.

“The lack of basic security features on internet connected devices undermines the privacy and security of California’s consumers, and allows hackers to turn everyday consumer electronics against us,” said Sen. Jackson. “SB 327 ensures that technology serves the people of California, and that security is not an afterthought but rather a key component of the design process.”California governor signs IoT cybersecurity law and net neutrality law

Veteran cybersecurity expert and cryptographer Bruce Schneier, who helped draft the IoT Cybersecurity Improvement Act of 2017, applauded the initiative, telling The Washington Post that it will “help everybody” even if “it probably doesn’t go far enough.” The IoT Cybersecurity Improvement Act of 2017, which could force security into IoT, has not made it past the Senate Committee on Homeland Security and Governmental Affairs.

Others have outright called the new SB 327 law “bad.” One of its biggest critics is Robert Graham of Errata Security, who described it as a “typically bad bill based on a superficial understanding of cybersecurity/hacking that will do little improve security, while doing a lot to impose costs and harm innovation.”

Gov. Brown last week also signed what have been described as the strictest net neutrality protections in the United States. Washington, Vermont and Oregon have also passed their own net neutrality regulations, and others will likely follow.

The Department of Justice claims the law, SB 822, is illegal. U.S. Attorney General Jeff Sessions argued that the Constitution prohibits states from regulating interstate commerce.

“Once again the California legislature has enacted an extreme and illegal state law attempting to frustrate federal policy. The Justice Department should not have to spend valuable time and resources to file this suit today, but we have a duty to defend the prerogatives of the federal government and protect our Constitutional order,” Sessions said.

Unsurprisingly, the representatives of U.S. telecoms companies also oppose the legislation.

“Broadband providers strongly support net neutrality, but SB 822 undercuts California’s long history as a vibrant catalyst for innovation and technology,” said Jonathan Spalter, President and CEO of broadband industry lobbying group USTelecom. “The internet must be governed by a single, uniform and consistent national policy framework, not state-by-state piecemeal approaches. Governor Brown should use his veto pen on this legislation, and Congress should step in to legislate and provide consumer protections that will resolve this issue once and for all.”

On the other hand, many activists and Internet freedom supporters praise California for the law.

“This victory in California is a testament to the power of the free and open Internet to defend itself. And it’s a beacon of hope for Internet users everywhere who are fighting for the basic right to express themselves and access information without cable and phone companies controlling what they can see and do online.” said Evan Greer, deputy director of Fight for the Future, a digital rights group that played an important role in passing SB 822.

“Despite their army of lobbyists and millions spent lining the pockets of legislators, these companies continue to lose ground in the face of overwhelming cross-partisan opposition to their greedy attacks on our Internet freedom. When all is said and done, Comcast, Verizon, and AT&T are going to wish they’d never picked a fight with Internet over net neutrality. Other states should follow California’s lead, and Congress should pass the joint resolution to reverse the FCC’s resoundingly unpopular repeal,” Greer added.


Meet Torii, a Stealthy, Versatile and Highly Persistent IoT Botnet
28.9.2018 securityweek
BotNet  IoT

There’s a new Internet of Things (IoT) botnet lurking around, a stealthy one that attempts to achieve persistence by running six different routines at once, Avast has discovered.

Dubbed Torii, because some of the hits to a honeypot were observed coming from Tor exit nodes, the botnet targets multiple architectures, but doesn’t appear to include the usual set of malicious capabilities that IoT botnets are famous for, such as distributed denial of service (DDoS), spam, or crypto-mining.

It does, however, pack a rich set of information exfiltration features, as well as a modular architecture that allows it to fetch and execute commands and files, all via multiple layers of encrypted communication.

Active since at least December 2017, Torii can infect devices powered by MIPS, ARM, x86, x64, PowerPC, SuperH, Motorola 68k, and others, Avast has discovered. The malware targets weak credentials over the Telnet protocol and, after the initial compromise, it executes a shell script to determine the device’s architecture and download the appropriate payload, either over HTTP or FTP.

The script fetches a binary file that represents a dropper for the second-stage payload, and which attempts to make it persistent using multiple methods. The second-stage is contained within the first ELF file and is installed to a pseudo-random location.

After executing the payload, the dropper executes six different methods for persistence: via injected code into ~\.bashrc, via “@reboot” clause in crontab, as a “System Daemon” service via systemd, via /etc/init and PATH (it calls itself System Daemon), via modification of the SELinux Policy Management, and via /etc/inittab.

A full-fledged bot, the second-stage is capable of executing commands from the command and control (C&C) server. The malware also includes simple anti-debugging techniques, data exfiltration, multi-level encryption of communication, and other capabilities.

With many of the functions in the second stage also found in the dropper, Avast’s security researchers suggest that they were both built by the same developer. However, while the code in the dropper is almost identical for all architectures, the second stage binaries show differences based on the targeted hardware architectures.

The malware uses the simple anti-analysis method of a 60 second sleep after execution and attempts to randomize the process name to avoid detection of blacklisted process names. The author also stripped the symbols from executables to make analysis more difficult.

The C&C address is encrypted using a XOR-based cipher and each Torii variant contains 3 addresses, Avast discovered. Since September 15, the domain names have resolved to IP 66.85.157.90, which also hosts other suspicious domains, the security researchers say. Communication with the C&C server is done via TCP port 443.

When connecting to the server, Torii exfiltrates information such as hostname, process ID, path to second stage executable, all MAC addresses in /sys/class/net/%interface_name%/address and its MD5 hash, data found by uname() call (sysname, version, release, and machine), and the outputs of various commands that gather additional information from the compromised machines.

The malware continuously asks the server if there are any commands it should execute, the security researchers discovered. After receiving a command, the threat replies with the results of the execution.

Another binary found on the attackers’ FTP server, sm_packed_agent, contains functionality that could be used to send any remote command to the target device. Written in the Go language, it could be easily recompiled to run on virtually any architecture and could serve as backdoor or a service to orchestrate multiple machines, the researchers say.

“Even though our investigation is continuing, it is clear that Torii is an example of the evolution of IoT malware, and that its sophistication is a level above anything we have seen before. Once it infects a device, not only does it send quite a lot of information about the machine it resides on to the C&C, but by communicating with the C&C, it allows Torii authors to execute any code or deliver any payload to the infected device. This suggests that Torii could become a modular platform for future use,” Avast concludes.


Hide and Seek (HNS) IoT Botnet targets Android devices with ADB option enabled
27.9.2018 securityaffairs 
BotNet  IoT

The latest samples of the HNS bot were designed to target Android devices having the wireless debugging feature ADB enabled.
The Hide and Seek (HNS) IoT botnet was first spotted early this year, since its discovery the authors continuously evolved its code.

The IoT botnet appeared in the threat landscape in January, when it was first discovered on January 10th by malware researchers from Bitdefender, then it disappeared for a few days, and appeared again a few weeks later infecting in a few days more than 20,000 devices.

The botnet initially spread infecting unsecured IoT devices, mainly IP cameras, in July security experts from Fortinet discovered that the Hide ‘N Seek botnet was improved to target vulnerabilities in home automation systems.

In the same month, experts from Netlab observed the Hide ‘N Seek botnet targeting also cross-platform database solutions. It is currently the first IoT malware that implements a persistence mechanism to keep devices infected after reboots.

The latest samples of the HNS bot were designed to target Android devices having the wireless debugging feature enabled instead of exploiting known vulnerabilities.

By default, Android has Android Debug Bridge (ADB) option disabled, but often vendors enable it to customize the operating system, then ship the devices with the feature turned on.

The authors of the HNS botnet are attempting to compromise new devices by exploiting the features.

“The newly identified samples add functionality by exploiting the Android Debug Bridge (ADB) over Wi-Fi feature in Android devices, which developers normally use for troubleshooting.” reads the analysis published by BitDefender.

“While it’s traditionally disabled by default, some Android devices are shipped with it enabled, practically exposing users to remote connections via the ADB interface that’s accessible using the TCP port 5555. Any remote connection to the device is performed unauthenticated and allows for shell access, practically enabling attackers to perform any task in administrator mode.”

In February 2018, security researchers at Qihoo 360’s Netlab have spotted an Android mining botnet that was targeting devices with ADB interface open.

The recent improvement of the Hide and Seek botnet, allowed its operators to add 40,000 new devices, most of them in Taiwan, Korea, and China.

HnS ADB_exposed_Shodan

Expert pointed out that the HNS bot could infect any device, including smart TVs and DVRs, that has ADB over Wi-Fi enabled could be affected too.

“It’s safe to say that not just Android-running smartphones are affected — smart TVs, DVRs and practically any other device that has ADB over Wi-Fi enabled could be affected too.” concludes Bitdefender.

“Considering the evidence at hand, we speculate the botnet operators are constantly adding new features to “enslave” as many devices as possible, although the true purpose of the botnet remains unknown.”


New trends in the world of IoT threats

24.9.2018 Kaspersky IoT

Cybercriminals’ interest in IoT devices continues to grow: in H1 2018 we picked up three times as many malware samples attacking smart devices as in the whole of 2017. And in 2017 there were ten times more than in 2016. That doesn’t bode well for the years ahead.

We decided to study what attack vectors are deployed by cybercriminals to infect smart devices, what malware is loaded into the system, and what it means for device owners and victims of freshly armed botnets.

Number of malware samples for IoT devices in Kaspersky Lab’s collection, 2016-2018. (download)

One of the most popular attack and infection vectors against devices remains cracking Telnet passwords. In Q2 2018, there were three times as many such attacks against our honeypots than all other types combined.

service % of attacks
Telnet 75.40%
SSH 11.59%
other 13.01%
When it came to downloading malware onto IoT devices, cybercriminals’ preferred option was one of the Mirai family (20.9%).

# downloaded malware % of attacks
1 Backdoor.Linux.Mirai.c 15.97%
2 Trojan-Downloader.Linux.Hajime.a 5.89%
3 Trojan-Downloader.Linux.NyaDrop.b 3.34%
4 Backdoor.Linux.Mirai.b 2.72%
5 Backdoor.Linux.Mirai.ba 1.94%
6 Trojan-Downloader.Shell.Agent.p 0.38%
7 Trojan-Downloader.Shell.Agent.as 0.27%
8 Backdoor.Linux.Mirai.n 0.27%
9 Backdoor.Linux.Gafgyt.ba 0.24%
10 Backdoor.Linux.Gafgyt.af 0.20%
Top 10 malware downloaded onto infected IoT device following a successful Telnet password crack

And here are the Top 10 countries from which our traps were hit by Telnet password attacks:

Geographical distribution of the number of infected devices, Q2 2018. (download)

As we see, in Q2 2018 the leader by number of unique IP addresses from which Telnet password attacks originated was Brazil (23%). Second place went to China (17%). Russia in our list took 4th place (7%). Overall for the period January 1 – July 2018, our Telnet honeypot registered more than 12 million attacks from 86,560 unique IP addresses, and malware was downloaded from 27,693 unique IP addresses.

Since some smart device owners change the default Telnet password to one that is more complex, and many gadgets don’t support this protocol at all, cybercriminals are constantly on the lookout for new ways of infection. This is stimulated by the high competition between virus writers, which has led to password bruteforce attacks becoming less effective: in the event of a successful crack, the device password is changed and access to Telnet is blocked.

An example of the use of “alternative technology” is the Reaper botnet, whose assets at end-2017 numbered about 2 million IoT devices. Instead of bruteforcing Telnet passwords, this botnet exploited known software vulnerabilities:

Vulnerabilities in D-Link 850L router firmware
Vulnerabilities in GoAhead IP cameras
Vulnerabilities in MVPower CCTV cameras
Vulnerability in Netgear ReadyNAS Surveillance
Vulnerability in Vacron NVR
Vulnerability in Netgear DGN devices
Vulnerabilities in Linksys E1500/E2500 routers
Vulnerabilities in D-Link DIR-600 and DIR 300 – HW rev B1 routers
Vulnerabilities in AVTech devices
Advantages of this distribution method over password cracking:

Infection occurs much faster
It is much harder to patch a software vulnerability than change a password or disable/block the service
Although this method is more difficult to implement, it found favor with many virus writers, and it wasn’t long before new Trojans exploiting known vulnerabilities in smart device software started appearing.

New attacks, old malware
To see which vulnerabilities are targeted by malware, we analyzed data on attempts to connect to various ports on our traps. This is the picture that emerged for Q2 2018:

Service Port % of attacks Attack vector Malware families
Telnet 23, 2323 82.26% Bruteforce Mirai, Gafgyt
SSH 22 11.51% Bruteforce Mirai, Gafgyt
Samba 445 2.78% EternalBlue, EternalRed, CVE-2018-7445 –
tr-069 7547 0.77% RCE in TR-069 implementation Mirai, Hajime
HTTP 80 0.76% Attempts to exploit vulnerabilities in a web server or crack an admin console password –
winbox (RouterOS) 8291 0.71% Used for RouterOS (MikroTik) authentication and WinBox-based attacks Hajime
Mikrotik http 8080 0.23% RCE in MikroTik RouterOS < 6.38.5 Chimay-Red Hajime
MSSQL 1433 0.21% Execution of arbitrary code for certain versions (2000, 2005, 2008); changing administrator password; data theft –
GoAhead httpd 81 0.16% RCE in GoAhead IP cameras Persirai, Gafgyt
Mikrotik http 8081 0.15% Chimay-Red Hajime
Etherium JSON-RPC 8545 0.15% Authorization bypass (CVE-2017-12113) –
RDP 3389 0.12% Bruteforce –
XionMai uc-httpd 8000 0.09% Buffer overflow (CVE-2018-10088) in XionMai uc-httpd 1.0.0 (some Chinese-made devices) Satori
MySQL 3306 0.08% Execution of arbitrary code for certain versions (2000, 2005, 2008); changing administrator password; data theft –
The vast majority of attacks still come from Telnet and SSH password bruteforcing. The third most common are attacks against the SMB service, which provides remote access to files. We haven’t seen IoT malware attacking this service yet. However, some versions of it contain serious known vulnerabilities such as EternalBlue (Windows) and EternalRed (Linux), which were used, for instance, to distribute the infamous Trojan ransomware WannaCry and the Monero cryptocurrency miner EternalMiner.

Here’s the breakdown of infected IoT devices that attacked our honeypots in Q2 2018:

Device % of infected devices
MikroTik 37.23%
TP-Link 9.07%
SonicWall 3.74%
AV tech 3.17%
Vigor 3.15%
Ubiquiti 2.80%
D-Link 2.49%
Cisco 1.40%
AirTies 1.25%
Cyberoam 1.13%
HikVision 1.11%
ZTE 0.88%
Miele 0.68%
Unknown DVR 31.91%
As can be seen, MikroTik devices running under RouterOS are way out in front. The reason appears to be the Chimay-Red vulnerability. What’s interesting is that our honeypot attackers included 33 Miele dishwashers (0.68% of the total number of attacks). Most likely they were infected through the known (since March 2017) CVE-2017-7240 vulnerability in PST10 WebServer, which is used in their firmware.

Port 7547
Attacks against remote device management (TR-069 specification) on port 7547 are highly common. According to Shodan, there are more than 40 million devices in the world with this port open. And that’s despite the vulnerability recently causing the infection of a million Deutsche Telekom routers, not to mention helping to spread the Mirai and Hajime malware families.

Another type of attack exploits the Chimay-Red vulnerability in MikroTik routers running under RouterOS versions below 6.38.4. In March 2018, it played an active part in distributing Hajime.

IP cameras
IP cameras are also on the cybercriminal radar. In March 2017, several major vulnerabilities were detected in the software of GoAhead devices, and a month after information about it was published, there appeared new versions of the Gafgyt and Persirai Trojans exploiting these vulnerabilities. Just one week after these malicious programs were actively distributed, the number of infected devices climbed to 57,000.

On June 8, 2018, a proof-of-concept was published for the CVE-2018-10088 vulnerability in the XionMai uc-httpd web server, used in some Chinese-made smart devices (for example, KKMoon DVRs). The next day, the number of logged attempts to locate devices using this web server more than tripled. The culprit for this spike in activity was the Satori Trojan, known for previously attacking GPON routers.

New malware and threats to end users
DDoS attacks
As before, the primary purpose of IoT malware deployment is to perpetrate DDoS attacks. Infected smart devices become part of a botnet that attacks a specific address on command, depriving the host of the ability to correctly handle requests from real users. Such attacks are still deployed by Trojans from the Mirai family and its clones, in particular, Hajime.

This is perhaps the least harmful scenario for the end user. The worst (and very unlikely) thing that can happen to the owner of the infected device is being blocked by their ISP. And the device can often by “cured” with a simple reboot.

Cryptocurrency mining
Another type of payload is linked to cryptocurrencies. For instance, IoT malware can install a miner on an infected device. But given the low processing power of smart devices, the feasibility of such attacks remains in doubt, even despite their potentially large number.

A more devious and doable method of getting a couple of cryptocoins was invented by the creators of the Satori Trojan. Here, the victim IoT device acts as a kind of key that opens access to a high-performance PC:

At the first stage, the attackers try to infect as many routers as possible using known vulnerabilities, in particular:
CVE-2014-8361 – RCE in the miniigd SOAP service in Realtek SDK
CVE 2017-17215 – RCE in the firmware of Huawei HG532 routers
CVE-2018-10561, CVE-2018-10562 – authorization bypass and execution of arbitrary commands on Dasan GPON routers
CVE-2018-10088 – buffer overflow in XiongMai uc-httpd 1.0.0 used in the firmware of some routers and other smart devices made by some Chinese manufacturers
Using compromised routers and the CVE-2018-1000049 vulnerability in the Claymore Etherium miner remote management tool, they substitute the wallet address for their own.
Data theft
The VPNFilter Trojan, detected in May 2018, pursues other goals, above all intercepting infected device traffic, extracting important data from it (user names, passwords, etc.), and sending it to the cybercriminals’ server. Here are the main features of VPNFilter:

Modular architecture. The malware creators can fit it out with new functions on the fly. For instance, in early June 2018 a new module was detected able to inject javascript code into intercepted web pages.
Reboot resistant. The Trojan writes itself to the standard Linux crontab job scheduler, and can also modify the configuration settings in the non-volatile memory (NVRAM) of the device.
Uses TOR for communication with C&C.
Able to self-destruct and disable the device. On receiving the command, the Trojan deletes itself, overwrites the critical part of the firmware with garbage data, and then reboots the device.
The Trojan’s distribution method is still unknown: its code contains no self-propagation mechanisms. However, we are inclined to believe that it exploits known vulnerabilities in device software for infection purposes.

The very first VPNFilter report spoke of around 500,000 infected devices. Since then, even more have appeared, and the list of manufacturers of vulnerable gadgets has expanded considerably. As of mid-June, it included the following brands:

ASUS
D-Link
Huawei
Linksys
MikroTik
Netgear
QNAP
TP-Link
Ubiquiti
Upvel
ZTE
The situation is made worse by the fact that these manufacturers’ devices are used not only in corporate networks, but often as home routers.

Conclusion
Smart devices are on the rise, with some forecasts suggesting that by 2020 their number will exceed the world’s population several times over. Yet manufacturers still don’t prioritize security: there are no reminders to change the default password during initial setup or notifications about the release of new firmware versions, and the updating process itself can be complex for the average user. This makes IoT devices a prime target for cybercriminals. Easier to infect than PCs, they often play an important role in the home infrastructure: some manage Internet traffic, others shoot video footage, still others control domestic devices (for example, air conditioning).

Malware for smart devices is increasing not only in quantity, but also quality. More and more exploits are being weaponized by cybercriminals, and infected devices are used to steal personal data and mine cryptocurrencies, on top of traditional DDoS attacks.

Here are some simple tips to help minimize the risk of smart device infection:

Don’t give access to the device from an external network unless absolutely necessary
Periodic rebooting will help get rid of malware already installed (although in most cases the risk of reinfection will remain)
Regularly check for new firmware versions and update the device
Use complex passwords at least 8 characters long, including upper and lower-case letters, numerals, and special characters
Change the factory passwords at initial setup (even if the device does not prompt you to do so)
Close/block unused ports, if there is such an option. For example, if you don’t connect to the router via Telnet (port TCP:23), it’s a good idea to disable it so as to close off a potential loophole to intruders.


Critical Vulnerability Impacts Hundreds of Thousands of IoT Cameras
20.9.2018 securityweek
IoT

A critical vulnerability in NUUO software could allow attackers to remotely view video feeds and tamper with the recordings of hundreds of thousands of surveillance cameras, Tenable reveals.

The bug, which Tenable researchers called Peekaboo, supposedly impacts over 100 brands and 2,500 different models of cameras that are integrated with NUUO’s software. Providing access to usernames and passwords, the vulnerability could be exploited to manipulate cameras and take them offline.

NUUO’s software and devices are widely used for web-based video monitoring and surveillance in multiple industries, including retail, transportation, education, government, and banking. The vulnerability was discovered in NVRMini 2, a network-attached storage device and network video recorder.

The vulnerability, an unauthenticated stack buffer overflow, could lead to remote code execution. Tracked as CVE-2018-1149, it features a CVSSv2 Base score of 10.0.

“Once exploited, Peekaboo would give cybercriminals access to the control management system (CMS), exposing the credentials for all connected video surveillance cameras. Using root access on the NVRMini2 device, cybercriminals could disconnect the live feeds and tamper with security footage,” Tenable says.

The bug was found in NVRMini 2 firmware versions older than 3.9.0. Despite being publicly revealed, the flaw remains unpatched, though a fix is in the works.

“In the meantime, users are urged to control and restrict access to their NUUO NVRMini2 deployments and limit this to legitimate users from trusted networks only. Owners of devices connected directly to the internet are especially at risk, as potential attackers can target them directly over the internet. Affected end users must disconnect these devices from the internet until a patch is released,” Tenable says.

The issue resides in the use of an open-source web server with support for executable binaries via the common gateway interface (CGI) protocol. One of the CGI binaries, 'cgi_system', handles various commands and actions that require the user be authenticated, but the cookie parameter’s session ID size isn’t checked during authentication, thus allowing for a stack buffer overflow in the sprintf function.

The vulnerability can result in remote code execution with “root” or administrator privileges, Tenable’s security researchers discovered. Proof-of-concept (PoC) code to demonstrate the bug has been published on GitHub.

In addition to this security flaw, Tenable discovered a backdoor in leftover debug code. Tracked as CVE-2018-1150, the vulnerability has a CVSSv2 Base Score of 4.0.

The backdoor is enabled if a file named /tmp/moses exists, the researchers explain. The backdoor can be used to list all user accounts on the system and also allows the change of any account’s password. An attacker abusing the bug could not only view the camera feeds and CCTV recordings, but could also remove a camera from the system entirely.

“This is a very odd artifact. We weren’t able to determine if it’s leftover development code or if it was maliciously added. To be able to activate and utilize the backdoor, an attacker would need to be able to create the file “/tmp/moses,” so the attack would require some form of access or need to be combined with another exploit. Its existence and lack of obfuscation in the code is the real mystery,” Tenable says.


Evolution of threat landscape for IoT devices – H1 2018
19.9.2018 securityaffairs
IoT

Security experts from Kaspersky have published an interesting report on the new trends in the IoT threat landscape. What is infecting IoT devices and how?
The researchers set up a honeypot to collect data on infected IoT devices, the way threat actors infect IoT devices and what families of malware are involved.

The first data that emerged from the study is that threat actors continue to look at the IoT devices with increasing interest. In the first six months of 2018, the experts observed a number of malware samples that was up three times as many samples targeting IoT devices as in the whole of 2017. In 2017 there were ten times more than in 2016.

IoT devices attacks

In the first half of 2018, researchers at Kaspersky Lab said that the most popular attack vector against IoT devices remains cracking Telnet passwords (75,40%), followed by cracking SSH passwords (11,59%).

Mirai dominates the IoT threat landscape, 20.9% of IoT devices were infected by this malicious code, other prominent malware are Hajime (5.89%) and Gafgyt.

Top 10 countries from which Kaspersky traps were hit by Telnet password attacks is led by Brazil, China, and Japan.

“As we see, in Q2 2018 the leader by number of unique IP addresses from which Telnet password attacks originated was Brazil (23%). Second place went to China (17%). Russia in our list took 4th place (7%).” reads the report.

“Overall for the period January 1 – July 2018, our Telnet honeypot registered more than 12 million attacks from 86,560 unique IP addresses, and malware was downloaded from 27,693 unique IP addresses.”

Experts pointed out that infected MikroTik routers made up 37.23 percent of all the data collected, followed by TP-Link that accounted for 9.07%.

MikroTik devices running under RouterOS are targeted by malicious code that includes the exploit for the Chimay-Red vulnerability.

The Chimay Red hacking tool leverages 2 exploits, the Winbox Any Directory File Read (CVE-2018-14847) and Webfig Remote Code Execution Vulnerability.

MikroTik devices were involved in several campaigns in the past months, including the VPNfilter botnet that infected almost a million routers in more than 50 countries

Iot devices

Experts highlighted that IoT malware is increasing both in quantity and quality.

“More and more exploits are being weaponized by cybercriminals, and infected devices are used to steal personal data and mine cryptocurrencies, on top of traditional DDoS attacks.” concludes Kaspersky.

Let me suggest to read to read the report, is full of interesting data.


IoT Botnets Target Apache Struts, SonicWall GMS
10.9.2018 securityweek IoT

The infamous Mirai and Gafgyt Internet of Things (IoT) botnets are targeting vulnerabilities in Apache Struts and the SonicWall Global Management System (GMS), Palo Alto Networks has discovered.

The Mirai variant observed in attacks last week packs exploits for 16 vulnerabilities, including one targeting CVE-2017-5638, the Apache Struts vulnerability that led to the Equifax data breach in 2017.

The domain currently hosting the new Mirai samples was resolving to a different IP address in August, and was seen hosting samples of the Gafgyt botnet (aka BASHLITE) that included an exploit for CVE-2018-9866, a flaw in older versions of SonicWall's Global Management System (GMS).

Another interesting characteristic of the new Mirai samples, Palo Alto Networks’ security researchers say, is that they no longer include the brute-force functionality generally used by the infamous IoT malware.

Ever since its source code was posted online in October 2016, Mirai has been continuously evolving, and the switch towards targeting vulnerabilities rather than brute-forcing credentials has been observed in other botnet samples as well.

Gafgyt’s newly acquired exploit is targeting a vulnerability affecting unsupported versions of SonicWall GMS (8.1 and older), the researchers point out. The first sample to target the flaw emerged on August 5, less than a week after an exploit for it was added to Metasploit.

“The incorporation of exploits targeting Apache Struts and SonicWall by these IoT/Linux botnets could be an indication of a larger movement from consumer device targets to enterprise targets,” Palo Alto Networks notes.

“All organizations should ensure they keep not only their systems up-to-date and patched, but also their IoT devices,” the security firm said.

Capable of launching powerful distributed denial of service (DDoS) attacks, both Mirai and Gafgyt have shown a surge in activity over the past several months. Now capable of infecting more than just IoT devices, these botnets pose increasingly higher risks to consumers and businesses alike.

UPDATE. “The vulnerability disclosed in this post is not an announcement of a new vulnerability in SonicWall Global Management System (GMS). The issue referenced only affects an older version of the GMS software (version 8.1) which was replaced by version 8.2 in December 2016. Customers and partners running GMS version 8.2 and above are protected against this vulnerability,” a SonicWall spokesperson told SecurityWeek in an emailed comment.

“Customers still using GMS version 8.1 should apply a hotfix supplied by SonicWall in August 2018 and plan for an immediate upgrade, as GMS 8.1 went out of support in February 2018. SonicWall and its threat research team continuously updates its products to provide industry-leading protection against the latest security threats, and it is therefore crucial that customers are using the latest versions of our products. We recommend that customers with older versions of GMS, which are long out of support, should upgrade immediately,” the spokesperson continued.


Cross-Platform Mirai Variant Leverages Open-Source Project
24.8.2018 securityweek IoT

A newly discovered Mirai variant has been created using an open-source project that makes the process of cross compilation very easy, Symantec reports.

Mirai, a piece of malware that first emerged in the fall of 2016, targets a broad range of Internet of Things (IoT) devices to ensnare them into botnets capable of launching massive distributed denial of service (DDoS) attacks.

Numerous Mirai variants have emerged since the malware’s source code was leaked in October 2016, targeting a broader range of devices and increasing resilience. Some of the most recent Mirai iterations include Wicked, Satori, Okiru, Masuta, and others.

Now, Symantec says its researchers discovered a Mirai variant compatible with multiple architectures. More robust compared to previously observed iterations, the sample has been built using the open-source project called Aboriginal Linux.

The platform has been designed to make cross compilation a simple task, allowing software authors to create images targeting multiple architectures, including ARM, MIPS, PowerPC, and x86.

Apparently, this is exactly why the developers behind the new Mirai variant chose Aboriginal Linux too. When compiled using the open source project, the malware can be executed on a variety of devices, including routers, IP cameras, other types of connected products, and Android devices.

“Given that the existing code base is combined with an elegant cross compilation framework, the resultant malware variants are more robust and compatible with multiple architectures,” Symantec researcher Dinesh Venkatesan explains.

The observed sample includes functionality consistent with Mirai’s behavior, the security researcher says. The infection starts with a shell script on a vulnerable device, which attempts to download and run individual executables until the binary compliant with the current architecture is found.

When executed on an infected device, the Mirai payload attempts to spread to devices with default credentials or vulnerabilities. The new sample was observed scanning for over 500,000 randomly generated IP addresses and attempting to deliver a raw packet data over port 23.

While the Aboriginal Linux project is not malicious, this is yet another example of how malware authors leverage open-source software for their nefarious purposes, Venkatesan points out.


Smart Irrigation Systems Expose Water Utilities to Attacks
13.8.2018 securityweek IoT

A team of experts has analyzed smart irrigation systems from several vendors and found vulnerabilities that can be exploited to cause potentially serious disruptions to urban water services.

Researchers from the Ben-Gurion University of the Negev in Israel recently published a paper describing what they call a “piping botnet,” a botnet of smart sprinklers that can be used to quickly empty water towers and even anti-flood water reservoirs.

Based on an analysis of popular smart irrigation systems from RainMachine, BlueSpray and GreenIQ, they determined that a bot running on a device in the same local area network (LAN) can detect an irrigation system within 15 minutes by analyzing outgoing traffic. They also showed that the bot can initiate the watering process and cause significant damage.

“While previous attacks against critical infrastructure required the attacker to compromise the systems of critical infrastructure, we present an attack against critical infrastructure that does not necessitate compromising the infrastructure itself and is done indirectly by attacking attacking client infrastructure that is not under the control of the critical infrastructure provider,” the researchers explained in their paper.

Smart irrigation systems rely on sensors and online services for improved efficiency. Users can control the system remotely from a mobile phone or computer, and they can configure it using a dedicated cloud service. These products can also adapt the watering schedule based on data obtained from weather forecast services.

While many smart irrigation systems communicate via Wi-Fi, some also have a GSM component that gives them direct access to the Internet. Researchers conducted an Internet search using Shodan and discovered tens of exposed devices from one of the targeted vendors.

According to the experts, malicious actors can create a botnet of smart irrigation systems by infecting various types of Internet-connected devices with malware (e.g. routers, laptops, smartphones). The malware searches the local network for irrigation systems and takes control of them using various security flaws. The attacker can then manipulate the compromised system via command and control (C&C) servers.

Once in the network, hackers can launch man-in-the-middle (MitM) attacks and spoof the input of the irrigation system. Researchers found that attackers could spoof the system’s configuration, the weather forecast, and various sensors (rain, water flow and soil moisture sensors) to manipulate the sprinklers.

In addition to spoofing attacks, hackers can launch replay attacks, where they send arbitrary instructions to the targeted device in the form of legitimate data. Specially crafted HTTP packets containing watering plan updates are sent to the system so that the sprinklers are activated as specified by the attacker.

Replay attacks can also be used to open the valves of smart irrigation systems and initiate the watering process whenever the hacker wishes. In their experiments, researchers got the master valve of a system to open and close every ten seconds.

Piping botnet targets smart irrigation systems

Launching malicious attacks against irrigation systems can have a significant impact on water utilities and their customers, the researchers warned.

For example, threat actors can activate sprinklers and keep them running until areal reservoirs and water tanks have been emptied, which can result in temporary water outages or at least a reduction of the water flow. This can be particularly problematic in regions where there is a shortage of water.

Based on the calculations performed by the researchers, a botnet of roughly 1,300 irrigation systems can empty a standard water tower in an hour. A larger botnet of nearly 24,000 sprinklers can empty an anti-flood water reservoir overnight.

Increasing the water consumption also leads to financial damage, which can be significant, especially in areas where water is expensive.

Each type of attack was demonstrated against one of the targeted products. All impacted vendors, including one weather forecast service abused in the tests, were notified in June and some of them have started implementing measures to prevent potential attacks.


IBM Opens New Labs for Cracking ATMs, IoT Devices
8.8.2018 securityweek  IoT

IBM’s X-Force Red, a team of veteran hackers focused on finding security vulnerabilities in devices and systems, now has four new labs to work in.

The new network of facilities provides all the toys required for testing the security of consumer and industrial Internet of Things (IoT) technologies, automotive equipment, and Automated Teller Machines (ATMs), both before and after they are deployed to customers.

Referred to as X-Force Red Labs, the new facilities are located in Austin, TX; Hursley, England; Melbourne, Australia; and Atlanta, GA. Additionally, the IBM X-Force Red has launched a dedicated ATM Testing practice.

The IBM X-Force Red team has seen significant growth, experiencing penetration testing client base increase by over 170% in the last year and doubling the number of X-Force Red practitioners across multiple domains.

“IBM X-Force Red has one mission – hack anything to secure everything. Via X-Force Red Labs, we have the ability to do just that, in a secure and controlled environment,” Charles Henderson, Global Managing Partner, IBM X-Force Red, said.

Services provided by IBM X-Force Red through the new four global testing labs include documenting product requirements with product engineers, technical analysis to scope the penetration test, disclosing potential threats and risks to the product and company, creating and implementing a list of security requirements, and actual hacking into products the same as real-world attackers would do.

With over 300 million ATMs globally, finding and addressing vulnerabilities in these systems is one of the key activities the X-Force Red team engages in. According to IBM, it saw a 300% increase in requests for ATM testing, mainly driven by a massive increase in attacks on these devices.

The jackpotting attacks on ATMs, which are performed using both malware and physical access to the machines, have reached the United States as well. With many ATMs running outdated software, cybercriminals attempt to find and exploit vulnerabilities in them for financial gain.

X-Force Red ATM Testing service can help identify and remediate physical, hardware and software vulnerabilities within ATMs before the attackers, IBM says.

The team evaluates the physical, network, application, and computer system security of ATMs, leverages the same tools and methods as criminals do to hack into these machines, helps hardening systems and defenses, and reviews ATM logs to help financial organizations stay in compliance with industry standards.


Security bug in Swann IoT Camera allowed to access video feeds
30.7.2018 securityaffairs IoT

Security experts have discovered a security glitch in Swann IoT camera that could be exploited by attackers to access video feeds.
Security experts from Pen Test Partners (Andrew Tierney, Chris Wade and Ken Munro) along with security researchers Alan Woodward, Scott Helme and Vangelis Stykas have discovered a security glitch in Swann IoT camera that could be exploited to access video feeds.

The experts reported the issue to the vendor that has patched the vulnerability.

The research team developed a proof-of-concept attack exploiting security flaws in the cloud service used by the IoT camera, Safe by Swann, in this way they were able to access the cameras via their mobile devices.

The experts started investigating the issue after reading a BBC article outlining how a BBC employee had accidentally seen someone else’s footage on the mobile app for their home security camera.

The affected camera model it a battery-powered HD camera that implements video streaming feature either directly over the local network or via a cloud service.

Swann IoT camera

Experts noticed that the cloud service is provided by Ozvision, when a user logs into the system through Safe by Swann, a request is made (userListAssets) to the server.

The server, in turn, provides a list containing the devices associated with the account.

The researchers analyzed the requests and attempted to manipulate the serial number parameter.

Swann IoT camera request

The experts explained that it is easy to find a serial number associated with the targeted device via the API endpoint and APK.

“After reviewing the API endpoint and APK, I quickly realised that the serial number (swnxxxxxxxxx) is the primary identifier of the camera on the platform. This is both for the Swann-specific web API and the OzVision peer-to-peer tunnel. The serial is easily found in the mobile app:” states the analysis published by the experts.

“We replace the serial number (deviceid) in the response from the server. At this point the mobile app sees the details of someone else’s camera. We are using Charles here, but Burp or MITMproxy will do it too”

The experts demonstrated that it is possible to access the camera stream for another serial number.

“In the app, one simply presses ‘play’. This made a request to deviceWakeup using the modified serial, then the Ozvision tunnel to the device was established using the modified serial. We could then watch the camera live.” continues the experts.

The experts explained that Swann quickly fixed the issue, but they speculated that the Ozvision was already aware of the issue.

“Ozvision already knew about the vulnerability, as Swann had informed them. The Swann customer camera cloud environment had quickly been fixed. Swann took swift action to fix the flaw and had a constructive dialogue with us.” continues the post.

“We suspect they knew about this issue for about nine months, and only fixed it when pressured by Swann; and we are confident the vulnerability was present in at least one other major camera brand to which they provide a cloud service. Further, they initially deflected direct questions about the issue back to Swann.”

How to discover serial numbers of existing cameras?

The serial number if composed of the string ‘swn’ plus 9 hex chars. The researcher Vangelis (@evstykas of the Tapplock API vulnerability fame) analyzed the API and discovered that it was possible to enumerate them with the following request:

1.1/osn/deviceIsOwned

1.1/osn/AccountAddDevice – this will throw an error if the camera is already paired, this means that using this trick it is possible to enumerate the entire keyspace searching for existing cameras.

“We believe the keyspace could be fully enumerated in as little as 3 days, given a distributed set of concurrent requests to the API.” concluded the researchers.

“So, one could now access arbitrary cameras.”


Tens of flaws in Samsung SmartThings Hub expose smart home to attack
30.7.2018 securityaffairs
Vulnerebility  IoT

Cisco Talos researchers found tens of flaws in Samsung SmartThings Hub controller that potentially expose smart home devices to attack
Cisco Talos researchers have discovered 20 vulnerabilities in Samsung SmartThings Hub controller that potentially expose any supported third-party smart home devices to cyber attack.

“Cisco Talos recently discovered several vulnerabilities present within the firmware of the Samsung SmartThings Hub.” reads the analysis published by Talos.

“These vulnerabilities could allow an attacker to execute OS commands or other arbitrary code on affected devices.”

The Samsung SmartThings Hub is a central controller that could be used to manage a broad range of internet-of-things (IoT) devices in a smart home, including smart plugs, LED light bulbs, thermostats, and cameras.

The access to those IoT devices could allow attackers to gather sensitive information managed by the devices within the home and perform unauthorized activities.

Samsung SmartThings Hub runs a Linux-based firmware and allows for communications with various IoT devices using various wireless standards Zigbee, Z-Wave, and Bluetooth.

Talos researchers explained that in order to exploit the flaws, the attacker needs to chain a number of existing vulnerabilities together.

“It is possible to gather the set of preconditions needed to exploit bugs that would otherwise be unreachable by using multiple vulnerabilities.” researchers said.

“This is commonly referred to as “chaining.” When considering the severity of vulnerabilities, it is essential to keep in mind that they might be used as part of a chain, as this would significantly elevate their severity.”

The experts identified three notable chains, only one of them is a remote code execution (RCE) vulnerability that can be exploited without prior authentication.

RCE Chain – CVE-2018-3911

This RCE chain attack affects the “video core” HTTP server of the hub, it could be exploited by attackers to inject HTTP requests into this process from a network. The flaw is an exploitable HTTP header injection bug that exists within the communications (via Port 39500) between the hub and the remote servers. The flaw could be exploited by sending specially crafted HTTP requests to vulnerable devices.

“This vulnerability is present within the JSON processing performed by the `hubCore` binary present within the SmartThings hub and could be combined with other vulnerabilities present within affected devices to achieve code execution.” states the report.

Samsung SmartThings Hub

Other chains

Other chains identified by the researchers could be exploited only by an authenticated attacker.

The first attack chain is a remote code execution that could be obtained by exploiting the CVE-2018-3879 flaw that allows authorized attackers to execute SQL queries against a database running in the IoT device.

Experts noticed that chaining this flaw, with a string of other memory corruption vulnerabilities (CVE-2018-3880, CVE-2018-3906, CVE-2018-3912 to CVE-2018-3917, and CVE-2018-3919) that affects the Samsung SmartThings Hub it is possible to execute arbitrary code in the network.

Experts highlighted that the CVE-2018-3879 can also be exploited in the final chain attack for remote information leakage. This vulnerability can be used to create an empty file inside the device.

“Remote information leakage: TALOS-2018-0556 can also be used to create an empty file anywhere inside the device. As described in TALOS-2018-0593, the existence of an empty file at path “/hub/data/hubcore/stZigbee” will make the “hubCore” process to crash. Moreover, as described in TALOS-2018-0594, when the “hubCore” process crashes, it triggers an information leak that can be captured from the network.” reads the analysis tublished by Talos.

“By chaining these 3 vulnerabilities in order, an attacker can obtain a memory dump of the `hubCore` process, which contains most of the core logic, and consequent sensitive information, of the Hub.”

Talos experts tested and confirmed that the Samsung SmartThings Hub STH-ETH-250 – Firmware version 0.20.17 is affected by the flaws.

Samsung has addressed the flaw and security updates have been pushed out automatically.

“Talos recommends that these devices are updated as quickly as possible. As Samsung pushes updates out to devices automatically, this should not require manual intervention in most cases. It is important to verify the updated version has actually been applied to devices to ensure that they are no longer vulnerable. Samsung has released a firmware update that resolves these issues. An advisory related to these vulnerabilities can be found here.” concludes Talos.


ZoomEye IoT search engine cached login passwords for tens of thousands of Dahua DVRs
19.7.2018 securityaffairs IoT

A security researcher discovered that the IoT search engine ZoomEye has cached login passwords for tens of thousands of Dahua DVRs.
The IoT search engine ZoomEye has cached login passwords for tens of thousands of Dahua DVRs, the discovery was made by security researcher Ankit Anubhav, Principal Researcher at NewSky Security.

Dahua DVRs

Anubhav explained that the passwords are related to Dahua DVRs running very old firmware that is known to be affected by a five-year-old vulnerability tracked as CVE-2013-6117.

Even if the vulnerability has been patched, many Dahua devices are still running ancient firmware.

The CVE-2013-6117 was discovered by the security expert Jake Reynolds and affects Dahua DVR 2.608.0000.0 and 2.608.GV00.0. The flaw could be exploited by remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

An attacker just needs to initiate a raw TCP connection on a vulnerable Dahua DVR on port 37777 to send the exploit code that triggers the issue.

Once the Dahua device receives this code, it will respond with DDNS credentials for accessing the device, and other data, all in plaintext.

Ankit Anubhav
@ankit_anubhav
Just to make things clear to weaponize the exploit, one needs to connect to port 37777 on raw TCP + send the following message to get the ddns creds

"\xa3\x00\x00\x00\x00\x00\x00\x00\x63\x6f\x6e\x66\x69\x67\x00\x00\x8c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

Ankit Anubhav
@ankit_anubhav
Wow and how did I miss this.
13900+ of these devices have their password as "123456"
Check here https://goo.gl/S5G2Bh #iot #security #fail

This specific case was brought to my attention by another known botnet operator. So again, RIP to these devices. https://twitter.com/ankit_anubhav/status/1017429425602822144 …

11:49 PM - Jul 13, 2018
51
31 people are talking about this
Twitter Ads info and privacy

Ankit Anubhav
@ankit_anubhav
Wow and how did I miss this.
13900+ of these devices have their password as "123456"
Check here https://goo.gl/S5G2Bh #iot #security #fail

This specific case was brought to my attention by another known botnet operator. So again, RIP to these devices.

Ankit Anubhav
@ankit_anubhav
Replying to @ankit_anubhav
And of course, people here too have not failed to put extremely generic passwords.https://www.zoomeye.org/searchResult?q=%2Bport%3A%2237777%22%20%22admin123%22 … 270 devices have password as "admin123" lol.

Brickerbot is known to brick the devices he pwns, so it does not look like a happy ending for these devices. @GDI_FDN <end>

8:21 PM - Jul 13, 2018
16
See Ankit Anubhav's other Tweets
Twitter Ads info and privacy
Anubhav explained that ZoomEye scans port 37777 caching the output in plaintext, this means that everyone that with a ZoomEye account can scrap results to obtain the credentials of tens of thousands

Anubhav notified the issue to ZoomEye asking it to remove the passwords from its cached results, but the expert is still waiting for a reply.

The expert explained that he discovered the issue after reading a post published by the author of the BrickerBot IoT malware that exploited the flaw to hacked hijack and brick Dahua DVRs in the past.


NanoLock Launches Platform to Protect IoT Devices From Production Through End-of-Life
21.6.2018 securityweek IoT 

Cybersecurity start-up NanoLock Security today announced a new lightweight security platform designed to add security into the small connected devices better known as the internet of things, rather than to overlay security around those devices.

This is security designed to safeguard small devices from the production line through to the end of life and beyond; to allow secure updates but to prevent hacking and tampering; and to ensure the integrity of data from the device outwards.

"The challenge for connected devices," co-founder and CEO Eran Fine told SecurityWeek, "is that about 90% have very low computing power -- and they are becoming the most vulnerable part of the ecosystem. How do you protect those low power, and low compute power devices where an attacker may have network or physical access? The attacker may come from the device-side, or the cloud-side, on the production line, or even at the end of life of the device. How do you protect the very low computing power device within a cost and performance structure that satisfies the connected device marketplace?"

He needed a solution or architecture that is CPU agnostic. "CPUs are hackable -- as Intel, ARM and AMD have recently demonstrated," he continued. "So we work on the assumption that CPUs are untrustworthy. Instead of developing security that uses the device's own CPU, we've created something that sits between the bus of the device and the non-volatile memory. This acts as a governing entity, and very aggressively allows or disallows other entities to read from or write to the non-volatile memory that holds the firmware, the boot image, and the critical applications."

This approach works by preventing overwriting, modification, manipulation, erasure and ransomware attacks on firmware, boot images, system parameters and critical applications in connected and IoT devices. Without any possible access to the firmware, hackers cannot gain access to the firmware and cannot, for example, recruit the device into the next big Mirai-style IoT botnet.

Three technologies lie at the heart of the architecture. OREN device-side embedded protection safeguards against attacks from the network and cloud, and even an attacker that has physical access to the device. FOTALock technology ensures the safe and trusted delivery of firmware-over-the-air (FOTA) updates, applications and critical parameters. Management of Things (MoT) controls and manages devices and includes features for monitoring device security, version management, attacks and alerts. MoT is deployed as a stand-alone solution or integrated into a customer's own security management platform.

Since NanoLock sits on the only data route into the device, and is placed there during manufacture or assembly, connected devices cannot be hacked. "Even if you are the device owner, even if you have all the highest privileges, even if you are on the production line and have access to the device -- the security camera or the router, or the ECU in a car -- you cannot write any malicious code into the firmware, into the memory holding the firmware. The only entity that can do this is someone who has created a root of trust and a root of integrity between the protected memory and the entity," explains Fine.

"The protected memory will always continue to protect because it has autonomous decision-making power -- it has its own tiny CPU, its own non-volatile memory, its own cryptographic engine. Even if you are hacking the CPU or hacking the cloud, this device will continue to protect itself and the cloud-to-device integrity." Furthermore, he continued, "Every device, on inception, registers itself, provisions itself, and protects itself in front of the cloud -- and once it does this, it is unbreakable and unclonable."

The result is device security from the production line through distribution, installation and use, to beyond end of life. NanoLock provides physical protection from rogue or corrupt employees on the production line or in the business, and from hackers during use. "I like that NanoLock is combining a cyber and cyber-physical approach to protect and manage devices from the production line through end of life," comments Chris Wilder, senior analyst at Moor Insights & Strategy.

Such an architecture cannot be sold to the end user for installation since it is an integral part of the connected device itself. "We don't sell to device users like Citibank or Bank of America," said Fine; "but we will sell to a car maker or a big manufacturer of security cameras, or very large cloud providers offering management of devices as a service. Our customers are the automotive OEMs, operators and device makers and to some extent the large systems integrators."

It's a top down, not a bottom up approach to distribution. "We have strategic relationships with the memory makers," he said. "We work with one in Taiwan, one in the US and one in Japan. This provides an early access to the device makers who spec us in to the manufacture."

"Connected cars, part of the IoT ecosystem, are an area where security vulnerabilities are life-critical," comments Takayuki Maruhashi, assistant director at Japan-based Techno Systems Research. "A solution like NanoLock's ensures the network of ECUs are fully protected and managed during operation and during the component update process. CPU protection is proven to be vulnerable and NanoLock's approach is the solution to this problem."

And it's not just business to business critical infrastructure scenarios, added Fine. "The unbreakable nature of the system also makes it attractive for military and intelligence purposes where the device needs to be protected even if it falls into the wrong hands."

Based in both Nitzanei Oz, Israel and New York, NanoLock Security was founded in 2016 by Eran Fine, Shlomo Oren and Erez Kreiner; and is another start-up ultimately born from the Israeli intelligence services conveyor belt. Kreiner was director of Israel's National Cyber Security Authority for more five years, and was responsible for preventing cyber-attacks on Israel's critical infrastructures and assets.


IoT Botnets Found Using Default Credentials for C&C Server Databases
8.6.2018 thehackernews  IoT  BotNet

Not following cybersecurity best practices could not only cost online users but also cost cybercriminals. Yes, sometimes hackers don't take best security measures to keep their infrastructure safe.
A variant of IoT botnet, called Owari, that relies on default or weak credentials to hack insecure IoT devices was found itself using default credentials in its MySQL server integrated with command and control (C&C) server, allowing anyone to read/write their database.
Ankit Anubhav, the principal security researcher at IoT security firm NewSky Security, who found the botnets, published a blog post about his findings earlier today, detailing how the botnet authors themselves kept an incredibly week username and password combination for their C&C server's database.


Guess what the credentials could be?
Username: root
Password: root
These login credentials helped Anubhav gain access to the botnet and fetch details about infected devices, the botnet authors who control the botnet and also some of their customers (a.k.a. black box users), who have rented the botnet to launch DDoS attacks.
"Besides credentials, duration limit such as for how much time the user can perform the DDoS, maximum available bots for attack (-1 means the entire botnet army of the botmaster is available) and cooldown time (time interval between the two attack commands) can also be observed," Anubhav wrote.

Besides this, Anubhav was also able to see the duration limit of the attack such as for how long a client can perform the DDoS attack, maximum available bots for an attack, and the list of various IPs targeted by the DDoS attack.
Anubhav also found another botnet, which was also built with a version of Owari and its database was also exposed via weak credentials.
The C&C servers of both the botnets were located at 80.211.232.43 and 80.211.45.89, which are now offline, as "botnet operators are aware that their IPs will be flagged soon due to the bad network traffic," Anubhav wrote. "Hence to stay under the radar, they often voluntarily change attack IPs."


Prowli Malware Targeting Servers, Routers, and IoT Devices
8.6.2018 thehackernews  IoT 
Virus

After the discovery of massive VPNFilter malware botnet, security researchers have now uncovered another giant botnet that has already compromised more than 40,000 servers, modems and internet-connected devices belonging to a wide number of organizations across the world.
Dubbed Operation Prowli, the campaign has been spreading malware and injecting malicious code to take over servers and websites around the world using various attack techniques including use of exploits, password brute-forcing and abusing weak configurations.
Discovered by researchers at the GuardiCore security team, Operation Prowli has already hit more than 40,000 victim machines from over 9,000 businesses in various domains, including finance, education and government organisations.


Here's the list devices and services infected by the Prowli malware:
Drupal and WordPress CMS servers hosting popular websites
Joomla! servers running the K2 extension
Backup servers running HP Data Protector software
DSL modems
Servers with an open SSH port
PhpMyAdmin installations
NFS boxes
Servers with exposed SMB ports
Vulnerable Internet-of-Thing (IoT) devices
All the above targets were infected using either a known vulnerability or credential guessing.
Prowli Malware Injects Cryptocurrency Miner

Since the attackers behind the Prowli attack are abusing the infected devices and websites to mine cryptocurrency or run a script that redirects them to malicious websites, researchers believe they are more focused on making money rather than ideology or espionage.
According to GuardiCore researchers, the compromised devices were found infected with a Monero (XMR) cryptocurrency miner and the "r2r2" worm—a malware written in Golang that executes SSH brute-force attacks from the infected devices, allowing the Prowli malware to take over new devices.


In simple words, "r2r2 randomly generates IP address blocks and iteratively tries to brute force SSH logins with a user and password dictionary. Once it breaks in, it runs a series of commands on the victim," the researchers explain.
These commands are responsible for downloading multiple copies of the worm for different CPU architectures, a cryptocurrency miner and a configuration file from a remote hard-coded server.
Attackers Also Tricks Users Into Installing Malicious Extensions
Besides cryptocurrency miner, attackers are also using a well known open source webshell called "WSO Web Shell" to modify the compromised servers, eventually allowing attackers to redirect visitors of websites to fake sites distributing malicious browser extensions.
The GuardiCore team traced the campaign across several networks around the world and found the Prowli campaign associated with different industries.
"Over a period of 3 weeks, we captured dozens of such attacks per day coming from over 180 IPs from a variety of countries and organizations," the researchers said. "These attacks led us to investigate the attackers' infrastructure and discover a wide-ranging operation attacking multiple services."
How to Protect Your Devices From Prowli-like Malware Attacks
Since the attackers are using a mix of known vulnerabilities and credential guessing to compromise devices, users should make sure their systems are patched and up to date and always use strong passwords for their devices.
Moreover, users should also consider locking down systems and segmenting vulnerable or hard to secure systems, in order to separate them from the rest of their network.
Late last month, a massive botnet, dubbed VPNFilter, was found infecting half a million routers and storage devices from a wide range of manufacturers in 54 countries with a malware that has capabilities to conduct destructive cyber operations, surveillance and man-in-the-middle attacks.


Z-Wave Downgrade Attack Left Over 100 Million IoT Devices Open to Hackers
7.6.2018 thehackernews  IoT

Researchers have found that even after having an advanced encryption scheme in place, more than 100 million Internet-of-Things (IoT) devices from thousands of vendors are vulnerable to a downgrade attack that could allow attackers to gain unauthorized access to your devices.
The issue resides in the implementation of Z-Wave protocol—a wireless, radio frequency (RF) based communications technology that is primarily being used by home automation devices to communicate with each other.
Z-Wave protocol has been designed to offer an easy process to set up pairing and remotely control appliances—such as lighting control, security systems, thermostats, windows, locks, swimming pools and garage door openers—over a distance of up to 100 meters (330 feet).


The latest security standard for Z-Wave, called S2 security framework, uses an advanced key exchange mechanism, i.e., Elliptic-Curve Diffie-Hellman (ECDH) anonymous key agreement protocol, to share unique network keys between the controller and the client device during the pairing process.
Even after Silicon Labs, the company who owns Z-Wave, made it mandatory for certified IoT devices to use the latest S2 security standard, millions of smart devices still support the older insecure version of pairing process, called S0 framework, for compatibility.
S0 standard was found vulnerable to a critical vulnerability in 2013 due to its use of a hardcoded encryption key (i.e. 0000000000000000) to protect the network key, allowing attackers in range of the targeted devices to intercept the communication.

After analyzing Z-Wave, security researchers from UK-based Pen Test Partners discovered that devices which support both versions of key-sharing mechanisms could be forced to downgrade the pairing process from S2 to S0.
Dubbed Z-Shave by the researchers, the downgrade attack makes it easier for an attacker in range during the pairing process to intercept the key exchange, and obtain the network key to command the device remotely.


Researchers found the vulnerability while comparing the process of key exchange using S0 and S2, wherein they noticed that the node info command which contains the security class is being transferred entirely unencrypted and unauthenticated, allowing attackers to intercept or broadcast spoofed node command without setting the security class.

The researchers—Ken Munro and Andrew Tierney—used the Conexis L1 Smart Door Lock, a flagship product of British company Yale that ships for $360, for their exploit, and were able to downgrade its security, and eventually steal the keys and get permanent access to the Yale lock, and therefore the building protected by it, all without the actual user's knowledge.
You can also watch the video of the Z-Shave attack, wherein the researchers demonstrated how an attacker could unlock a door.

The S0 decryption attack was initially revealed by cybersecurity consulting company SensePost back in 2013, but at that time, Silicon Labs didn't see this issue "as a serious threat in the real world" because it was limited to the timeframe of the pairing process.
Silicon Labs published a blog post in response to the Pen Test Partners' findings on Wednesday, saying the company is confident its smart devices are secure and not vulnerable to such threats.
"S2 is the best-in-class standard for security in the smart home today, with no known vulnerabilities, and mandatory for all new Z-Wave products submitted for certification after April 2, 2017," reads the blog post.
However, the company said that since the adoption of S2 framework across the ecosystem could not happen overnight, the issue existed in Z-Wave for providing backward compatibility, so that S2 devices can work in an S0 network (and vice versa).
The company also said there are procedures in place to notify and alert users in times when secure devices connect to networks using downgraded communications, but IoT device manufacturers hardly provide any user interface to show such alerts, leaving users unaware of this attack.


Prowli Operation – Crooks already compromised over 40,000 servers and IoT Devices
7.6.2018 securityaffairs IoT

Crooks have infected over 40,000 web servers, modems, and other IoT devices with the Prowli malware as part of a cryptocurrency mining campaign and to redirect victims to malicious sites.
The Prowli malware was spotted by researchers at GuardiCore, attackers composed the huge botnet by exploiting known vulnerabilities and brute-force attacks.

This campaign, dubbed Operation Prowli, aimed at servers and devices using the following arrack methods, including:

Using a self-propagating worm that targets systems running SSH by brute force credential guessing, then the infected machines download and run a cryptocurrency miner.
Exploiting the CVE-2018-7482 file download vulnerability to compromise Joomla! Servers running the K2 extension
Accessing the internet facing configuration panel of variety of DSL modems by using a URL such as http://:7547/UD/act?1 and passing in parameters exploiting a known vulnerability. The vulnerability affects the processing of SOAP data and allows remote code execution. This vulnerability was previously used by the Mirai worm.
Using several exploits and launching brute-force attacks o admin panel of WordPress sites.
Exploiting a 4-year-old vulnerability, CVE-2014-2623, to execute commands with system privileges on servers running HP Data Protector exposed to the internet (over port 5555).
Targeting Drupal, PhpMyAdmin installations, NFS boxes, and servers with exposed SMB ports via brute-force credentials guessing.
prowli op

Once attackers have compromised a server or an IoT device, they determine if they can use it for cryptocurrency mining operations. Hackers used a Monero miner and the r2r2 worm, a piece of malware used to launch SSH brute-force attacks from the hacked devices.

“The attackers behind Prowli incur no expenses when they use r2r2 to take over computers owned by others and use mining pools to launder their gains. Cryptocurrency is a common payload of modern worms, and in this case as in many others, our attackers prefer to mine Monero, a cryptocurrency focused on privacy and anonymity to a greater degree than Bitcoin.” reads the analysis published by the experts.

“Second source of revenue is traffic monetization fraud. Traffic monetizers, such as roi777, buy traffic from “website operators” such as the Prowli attackers and redirect it to domains on demand. Website “operators” earn money per traffic sent through roi777. The destination domains frequently host different scams, such as fake services, malicious browser extensions and more.”

The hackers also compromised servers with the WSO Web Shell backdoor. Hacked websites were used to host malicious code that redirects visitors to a traffic distribution system (TDS), with such kind of attack scheme crooks monetize their efforts by selling hijacked traffic.

“Traffic monetizers, such as roi777, buy traffic from “website operators” such as the Prowli attackers and redirect it to domains on demand. Website “operators” earn money per traffic sent through roi777. The destination domains frequently host different scams, such as fake services, malicious browser extensions and more.” continues the experts.

Further details on the Prowli campaign, including IoCs are reported in the analysis published by GuardiCore.


Oops! Botnet Operators Use Default Credentials on Command and Control Server
6.6.2018 securityweek BotNet  IoT

Internet of Things (IoT) botnets prey on the use of default or weak credentials to compromise connected devices, but the operators of such a botnet also used default credentials in their operations.

As NewSky Security researchers recently discovered, the operators of the Mirai variant Owari botnet used default credentials on their command and control (C&C) server, thus allowing easy access their database.

First spotted in late 2016, Mirai was designed to target poorly secured devices to ensnare them into large distributed denial of service (DDoS) botnets. Ever since its source code leaked online, Mirai spawned numerous variants, such as Masuta, Satori, and Okiru, as well as the more recent Wicked, Sora, Owari, and Omni iterations.

What most of these variants inherit from Mirai, the security researchers say, is the use of a MySQL database server for C&C. This database, they reveal, contains three tables: users, history, and whitelist.

A recently observed Mirai variant named Owari is using this MySQL server structure, but its operators made the very same mistakes as the owners of the devices they targeted: they failed to properly secure the server.

Thus, NewSky Security stumbled upon an Owari server on IP 80(.)211(.)232(.)43, with port 3306, the default port for MySQL database, open to the Internet.

What’s more, the security researchers discovered that the attackers used the root:root username and password pair, “one of the weakest credentials known to mankind,” to secure the database, and also enabled read/write access to everyone.

As Dr. Vesselin Bontchev points out, it’s not that easy to make a MySQL database accessible from anywhere, nonetheless to secure it so poorly that anyone can connect to it.

Vess
@VessOnSecurity
4 Jun
It's not exactly spelled out in the article, but the perp wasn't just stupid (using weak credentials). He was *creatively* stupid. You have to try hard, in order to make a MySQL database accessible to the whole world. Not something you can do accidentally. https://twitter.com/ankit_anubhav/status/1003741307024625666 …

Vess
@VessOnSecurity
Like, by default, MySQL listens only to localhost. If you really want to shoot yourself in the foot and access it over the Internet, it forces you to define *triplets* of user/password/host from which the database is accessible.

11:08 PM - Jun 4, 2018
See Vess's other Tweets
Twitter Ads info and privacy
Having access to the database, the security researchers glanced through the three tables. The users table contained login credentials (for both malware authors and customers), and information such as attack duration limits, maximum available bots, and cooldown time between commands.

“In the specific Owari case, we observe one user with duration limit of 3600 seconds with permissible bot usage set as -1 (maximum). It is to be noted that the credentials of all these botnet users are also weak,” the security researchers reveal.

The history table revealed details on attacks carried out against various IPs (some were IoT botnet related, suggesting that the attacker might have tried to target rival botnet operators), while the whitelist table was empty, suggesting that the botnet would attack any IP or device.

The security researchers also discovered that this was only one of the two Owari-related MySQL databases exposed to the Internet and secured with root:root, with the second one located at IP 80(.)211(.)45(.)89.

Unfortunately, although they gained write access to the MySQL databases, the researchers couldn’t disrupt the botnet, because C&C-related IPs usually have a short lifespan, as they tend to be flagged fast due to bad network traffic. Thus, they often change the IPs, and the two mentioned above are already offline.

Ankit Anubhav, Principal Researcher, NewSky Security, reveals that they decided to contact an Owari operator to ask about the revenue model, and learned that the cost of hiring the botnet is of $60 per month, which involves “around 600 seconds of bot time.” Because of that, the operator can “guarantee a stable bot count,” and can cover expenses with 10 to 15 customers each month.


More than 100 Million IoT devices potentially exposed to Z-Shave Z-Wave attack
25.5.2018 securityaffairs IoT  

Researchers from Pen Test Partners have conducted an analysis of Z-Wave wireless communications protocol used by millions of IoT devices and discovered that it is vulnerable to cyber attacks.
The Z-Wave protocol is widely adopted for home automation, it leverages low-energy radio waves for wireless communications over distances of up to 100 meters (330 feet).

The protocol is currently used by 700 companies in over 2,400 IoT and smart home products.

Z-Wave uses a shared network key to secure communications among devices, the key is exchanged between the controller and the client devices when the devices are paired.

The earlier pairing process (‘S0’) had a vulnerability – the network key was transmitted between the nodes using a key of all zeroes, and could be sniffed by an attacker within RF range.

Z-wave flaw

The initial version of the pairing process (S0) is known to be vulnerable to MITM attacks since 2013, for this reason, experts introduced a more secure process named S2.

While S0 was using a known encryption key (0000000000000000), S2 leverages stronger encryption, but the experts found a way to force a downgrade of the pairing process from S2 to S0.

The white hat hackers discovered that an attacker in range of the targeted devices during the pairing process (‘S0’) can easily sniff the network key because it was shared between

The experts dubbed the attack “Z-Shave,”

“The earlier pairing process (‘S0’) had a vulnerability – the network key was transmitted between the nodes using a key of all zeroes, and could be sniffed by an attacker within RF range. This issue was documented by Sensepost in 2013. We have shown that the improved, more secure pairing process (‘S2’) can be downgraded back to S0, negating all improvements.” reads the analysis published by the experts.

“Once you’ve got the network key, you have access to control the Z-Wave devices on the network. 2,400 vendors and over 100 million Z-wave chips are out there in smart devices, from door locks to lighting to heating to home alarms.”

The experts published a video PoC of the attack on a Yale smart lock “Z-Shave,” works against any device using Z-Wave.

Researchers at Pen Test Partners explained that an attacker could use a battery-powered hacking device that is left outside the targeted building waiting for the pairing process to be initialized.

“A downgrade to no security may sound like it has more serious impact, but it means that the attacker cannot obtain the S0 network key. This means the only node placed at risk is the one just added. If an S0 network key is obtained, all S0 devices connected in the past and future are placed at risk.” explained the experts.

“The bigger difference is that our attack can be carried out by an active attacker within RF range at the time of pairing. And when we say active attacker – we don’t mean a guy in a hoody sat in a car with a laptop. A battery-powered drop-box could be left outside the property for weeks, waiting for a pairing event to occur.”

It turns out that a variant of this downgrade attack was discovered last year by cybersecurity consulting firm SensePost, but the vendor told experts at the time that this was by design and needed for backwards compatibility.

The experts explained that the Z-Wave Alliance still hasn’t addressed the issue, a delay that could have serious consequences.

“We aren’t certain how backward compatibility with S0 can be supported whilst enforcing stronger S2 security. This underlines the challenge with many protocols: how do you improve security without creating mountains of electronic waste for devices that are no longer supported?” concluded the experts.

“At the very least, the user should be fully alerted to the fallback to weak security.”


100 Million IoT Devices Possibly Exposed to Z-Wave Attack
25.5.2018 securityweek  IoT

Researchers have demonstrated that the Z-Wave wireless communications protocol, which is used by more than 100 million Internet-of-Things (IoT) devices, is vulnerable to security downgrade attacks.

Z-Wave, a protocol primarily used for home automation, uses low-energy radio waves for wireless communications over distances of up to 100 meters (330 feet). Z-Wave was developed by Zensys in 2001 and in 2008 it was acquired by Sigma Designs, which recently sold it to Silicon Labs for $240 million.Z-Wave vulnerable to downgrade attack

According to the Z-Wave Alliance, an organization dedicated to advancing Z-Wave, the protocol is currently used by 700 companies in over 2,400 IoT and smart home products, including thermostats, locks and home monitoring systems.

UK-based Pen Test Partners has conducted an analysis of Z-Wave and discovered that a hacker in range of the targeted devices during the pairing process can launch an attack and crack supposedly secure communications.

Z-Wave vulnerable to downgrade attack

The researchers demonstrated their findings on a Yale smart lock – they showed how an attacker can unlock a door – but the method, which they have dubbed “Z-Shave,” works against any device using Z-Wave.

Z-Wave relies on a shared network key to secure traffic between the controller and the client device when they are paired. The initial version of the pairing process, known as S0, was found to be vulnerable to sniffing attacks back in 2013, which led to the introduction of a more secure process named S2.

The problem with S0 is that it protects the network key with a known encryption key (0000000000000000), allowing an attacker in range of the targeted device to intercept communications. S2 addresses this problem by using stronger encryption, but researchers discovered that an attacker can downgrade the connection from S2 to S0, basically removing the protection.

The hacker needs to be present during the initial pairing process to perform the downgrade, but Pen Test Partners pointed out that the attacker could use a battery-powered hacking device that is left outside the targeted property for an extended period of time, waiting for the pairing process to be initialized.

“The risk is mitigated as one has to be present during the pairing process, but the Z-Wave RF range is significant. We’re investigating whether it might be possible to de-authenticate a Z-Wave client device, but that’s work in progress,” researchers explained.

It turns out that a variant of this downgrade attack was discovered last year by cybersecurity consulting firm SensePost, but the vendor told experts at the time that this was by design and needed for backwards compatibility.

In a blog post published on Wednesday, Silicon Labs assured users that the risk is low and highlighted that it’s not aware of any real-world exploitation.

“While it’s possible that an attacker could intercept the S0 encrypted key exchange frame and decipher it using the hardcoded key, this is only possible during the initial set-up or reinstallation of the device,” Silicon Labs said. “To do this, the attacker would need to be within close proximity of the device during the very moment the device is installed - an extremely small window of opportunity. Furthermore, Z-Wave devices can switch their radio to low power transmission mode during key exchange process to make packet interception attack much more difficult.”

The company added, “It would not be possible to execute an attack without the homeowner becoming aware because they would receive a warning from the S2 controller during the pairing process.”


Google Brings Android to Internet of Things
9.5.2018 securityweek IoT

Less than a month after Microsoft announced an operating system built for Internet of Things (IoT) security, Google is releasing its own platform for IoT: Android Things.

The managed operating system was designed to provide manufacturers with all the ingredients for a winning IoT recipe: certified hardware, rich developer APIs, and secure managed software updates via Google’s infrastructure.

The platform has been in developer preview until this week, and has already registered over 100,000 SDK downloads, Google says. More than 10,000 developers have provided feedback on Android Things, ultimately leading to the platform’s initial release.

Android Things 1.0 was released with support for new System-on-Modules (SoMs) based on the NXP i.MX8M, Qualcomm SDA212, Qualcomm SDA624, and MediaTek MT8516 hardware platforms. Raspberry Pi 3 Model B and NXP i.MX7D devices (but not NXP i.MX6UL) will continue to be supported for development purposes.

“These modules are certified for production use with guaranteed long-term support for three years, making it easier to bring prototypes to market. Development hardware and reference designs for these SoMs will be available in the coming months,” Google says.

More important, however, is Google’s aim to provide devices running Android Things with timely software updates over-the-air (OTA). All devices will have automatic updates on by default, and stability fixes and security patches will arrive on production hardware platforms.

Currently, Google is releasing patches for Android devices on a monthly basis, in an attempt to improve the overall security stance of the platform. The company started delivering these monthly updates in 2015, after the Stagefright flaw was said to impact nearly one billion devices.

Android Things developers looking to ship commercial products running the new platform are required to sign a distribution agreement with Google to be able to deliver software updates to all devices (currently only 100 active devices are supported in the Android Things Console).

“For each long-term support version, Google will offer free stability fixes and security patches for three years, with additional options for extended support. Even after the official support window ends, you will still be able to continue to push app updates to your devices,” the Internet giant explains.

The Android Things Console also provides developers with the possibility to configure hardware peripherals.

Google has already partnered with leading manufacturers for the release of Android Things devices. Thus, Smart Speakers from LG and iHome and Smart Displays from Lenovo, LG, and JBL are expected to arrive on shelves this summer.

Developers interested in building products running Android Things can apply for a special limited program to partner with the Android Things team for technical guidance and support.


Microsoft Unveils New Solution for Securing Critical Infrastructure
1.5.2018 securityweek IoT

Microsoft last week unveiled Trusted Cyber Physical Systems (TCPS), a new solution designed to help protect critical infrastructure against modern cyber threats.

Microsoft provided the recent Triton and NotPetya attacks as examples of significant threats hitting critical infrastructure. Triton was used in a highly targeted campaign aimed at an organization in the Middle East, while NotPetya disrupted the operations of several major companies, with many reporting losses of hundreds of millions of dollars.

Microsoft’s TCPS project aims to address these types of threats by providing end-to-end security through hardware, software and trust mechanisms that should help organizations ensure they don’t lose control over critical systems.

Cyber-physical systems (CPS) are referred to as Internet-of-Things (IoT) in an industrial context. TCPS is based on four main principles: separating critical from non-critical operations through hardware isolation; ensuring that the code responsible for critical operations can be audited; the ability of each component to process data only from trustworthy sources and each component being able to attest its trustworthiness to other components; and reducing the attack surface by reducing the number of trusted entities.

One crucial component in providing end-to-end security involves trusted execution environments (TEE), Microsoft said. TEE includes Secure Elements (e.g. chip on a credit card), Intel’s Software Guard Extensions (SGX), ARM TrustZone, and Trusted Platform Modules (TPMs) and DICE-capable microcontrollers from the Trusted Computing Group.

TEE offers several advantages from a security viewpoint, including the fact that code running in a TEE is small and thus has a minimal attack surface, the code is considered trusted, all the data is encrypted, and the TEE hardware ensures that software running outside the trusted environment cannot break in.

Microsoft has pointed out that organizations can acquire low-cost devices with TEE and deploy them without making major changes to existing systems.

The tech giant’s TCPS solution leverages TEE to protect a wide range of components, including cloud services, human interaction devices, and edge computing devices. For instance, in the case of public and private clouds, a TEE that is protected from hosting providers and OS vendors can be used for various critical operations, including key and certificate management, provisioning, patch management, and logging.

In the case of physical security controls – for example, preventing unauthorized users or malware from tampering with electronically-controlled actuators or sensors – Microsoft says the connection to the system needs to be accessible only from the TEE. In order to avoid replacing existing and potentially expensive equipment, a TEE gateway can be deployed in front of the device.

As for human interfaces, the company points out that there is the risk of a compromised user device or SCADA system sending legitimate-looking arbitrary commands. Microsoft says this can be addressed by using a secure confirmation terminal, a device that displays a message and asks for confirmation if an unusual operation is detected. The TEE can help in this case by ensuring that the display and the input system on the secure confirmation terminal are only accessible from the trusted environment and out of malware’s reach.

Microsoft unveils Trusted Cyber Physical Systems (TCPS)

As an example, Microsoft has described a customer scenario where a utility company in charge of several water plants uses TCPS to ensure that any operation on cyber-physical systems is authorized by the operations center, which has the ability to securely delegate tasks to trusted third-parties. The solution also allows the firm to ensure that all operations are recorded as auditable events stored in tamperproof logs.

Additional information on Microsoft TCPS is available in a whitepaper (PDF) published by the company.


Microsoft built its own custom Linux OS to secure IoT devices
25.4.2018 thehackernews  IoT

Finally, it's happening.
Microsoft has built its own custom Linux kernel to power "Azure Sphere," a newly launched technology that aims to better secure billions of "Internet of things" devices by combining the custom Linux kernel with new chip design, and its cloud security service.
Project Azure Sphere focuses on protecting microcontroller-based IoT devices, including smart appliances, connected toys, and other smart gadgets, Microsoft announced during the security-focused RSA Conference in San Francisco Monday.
It is basically a security package consists of three main components:
Azure Sphere-certified microcontrollers (MCUs)
Azure Sphere OS
Azure Sphere Security Service
"Azure Sphere provides security that starts in the hardware and extends to the cloud, delivering holistic security that protects, detects, and responds to threats—so they're always prepared," Microsoft said.

Internet of Things (IoT) devices are 'ridiculously' vulnerable to remote hacking, because they are not originally manufactured keeping security in mind.
One innocent looking insecure IoT device connected to your 'secured network' would be enough to cause security nightmares. In the past, we have seen how lack of security by design led to massive DDoS attacks powered by Mirai IoT botnet.
To address such issues, Azure Sphere offers a full-fledged solution that provides the best-in-class security and a trustworthy environment for future IoT devices, and at the same time makes the life of IoT device manufactures a lot easier.
Azure Sphere Certified Microcontrollers (MCUs)

Designed by Microsoft Research, the Azure Sphere Certified Microcontrollers is a new cross-over class of fixed-functional microcontroller chips that will be licensed to manufacturing partners for free, which comes with built-in connectivity, networking and Pluton security subsystems to ensure the security of future IoT devices.
These MCUs "combines both real-time and application processors with built-in Microsoft security technology and connectivity," Microsoft explains.
"The Pluton Security Subsystem creates a hardware root of trust, stores private keys, and executes complex cryptographic operations," Microsoft said. "A new crossover MCU combines the versatility and power of a Cortex-A processor with the low overhead and real-time guarantees of a Cortex-M class processor."
"Each chip includes custom silicon security technology from Microsoft, inspired by 15 years of experience and learnings from Xbox, to secure this new class of MCUs and the devices they power," the company adds.
According to Microsoft president Brad Smith, the first Azure Sphere chip, called the "MT3620," will be made by Taiwan-based MediaTek and to be available in stores worldwide by the end of the year.
The Azure Sphere chips will also be compatible with other cloud services like Google Cloud, Amazon Web Services, and Oracle Cloud.
Azure Sphere OS (Linux-based)

The second component of the solution, called Azure Sphere OS, is a "defense-in-depth" operating system that comes with a security monitor and Microsoft's custom Linux kernel to offer multiple layers of security.
"Each Azure Sphere chip will include our Microsoft Pluton security subsystem, run the Azure Sphere OS, and connect to the Azure Sphere Security Service for simple and secure updates, failure reporting, and authentication," Microsoft says.
It is the first time when Microsoft created hardware that is designed to run only Linux, rather than its Windows operating system.
"We are a Windows company, but what we recognized is that the best solution for a computer of this size in a toy is not a full-blown version of Windows," Smith said. "It is a custom Linux Kernel, and it is an important step for us and the industry."
Azure Sphere Security Service (Cloud-based)

On top of everything, Azure Sphere Security Service is a cloud-based service that handles security and management of microcontroller chips.
The service offers device-to-device and device-to-cloud communication through certificate-based authentication to guards every Azure Sphere device.
It detects emerging security threats across the entire Azure Sphere ecosystem and also takes care of software updates.
Azure Sphere is now available in private preview, and the company will distribute software development kits to everyone interested in hacking Azure Sphere by the middle of this year. To find more details about Azure Sphere, you can head on to Microsoft Azure Sphere's blog.


Microsoft Takes Security to the Edge
18.4.2018 securityweek IoT

Microsoft Unveils New Services and Features to Secure Internet of Things (IoT) Devices

At RSA Conference this week in San Francisco, Microsoft announced new tools and technologies aimed at protecting connected devices from security threats.

First on the list is Azure Sphere, what Microsoft describes as a holistic solution built for securing microcontroller unit (MCU)-based devices from the silicon to the cloud. With an estimated 9 billion cloud-connected devices shipping each year with tiny MCU chips inside, there’s clearly a large segment to keep secure, Microsoft says.

Azure Sphere, the software giant claims, is based on a new class of Microsoft-developed MCUs boasting five times the power of legacy MCUs. The company aims at licensing the IP for the MCUs royalty free to silicon manufacturers, and says that MediaTek is already producing Azure Sphere-certified silicon.

With Azure Sphere, these chips run “a new customized operating system built for IoT security,” Microsoft says. Featuring a custom Linux kernel and optimized for IoT, the operating system includes security innovations from Windows, aiming to deliver a highly secured software environment.

Additionally, a cloud security service will guard every Azure Sphere device, allowing for updates and upgrades for a 10-year lifetime of the device. Microsoft also claims that Azure Sphere will work alongside both private and proprietary cloud services, allowing customers to continue using their existing data infrastructure.

“This combined approach to Azure Sphere brings together the best of hardware, software and services innovation. It is open to any MCU chip manufacturer, open to additional software innovation by the open source community and open to work with any cloud. In short, it represents a critical new step for Microsoft by integrating innovation across every aspect of technology and by working with every part of the technology ecosystem, including our competitors,” Microsoft President Brad Smith notes.

Additionally, Microsoft announced new automated threat detection and remediation tools to help simplify and streamline the process of identifying and fixing threats before they spread. These automated investigation and remediation capabilities will arrive on systems as part of Windows Defender Advanced Threat Protection (ATP) in the upcoming Windows 10 update.

Through connecting Conditional Access and Windows Defender ATP, Microsoft is now providing customers with the ability to limit access to mission-critical information when malware is detected on devices.

Microsoft is working to deliver detection and response capabilities to Microsoft Azure customers as well, Rob Lefferts, Director of Enterprise and Security, Windows, says. Customers embracing the cloud can leverage Azure Security Center to stay up to date with threats and to simplify hybrid cloud security.

“Several new capabilities will be available with Security Center this week that help to identify and mitigate vulnerabilities proactively and detect new threats quickly. With the integration of Windows Defender ATP in preview, customers can get all the benefits of advanced threat protection for Windows servers in Azure Security Center,” Lefferts reveals.

For management purposes, the company announced Microsoft Secure Score, which delivers a single dashboard and summary score for organizations to tap into. Not only will organizations easily determine which controls to enable for an effective protection, but they will also be able to compare results with other organizations.

Starting today, a new Microsoft Graph security API is available for preview, enabling customers to connect to Microsoft products powered by the Microsoft Intelligent Security Graph. Through the new API, technology partners and customers should be able to speed up threat investigation and remediation, the tech giant says.

Security firms such as Palo Alto Networks, PwC and Anomali are already exploring the API for their solution, the company says. Through a newly launched Microsoft Intelligent Security Association program, partners can benefit from, and contribute to, the Intelligent Security Graph and Microsoft security products.

Another security improvement coming to Window 10 is support for the FIDO 2.0 standard, which aims at providing users with password-free authentication capabilities. Set to arrive in the next Windows 10 update, FIDO 2.0 support will bring the same experience to all Windows 10 devices managed by an organization.

“All of the advances we’re announcing today reflect another essential fact of life. Security has become a shared responsibility. We believe that Microsoft has an important responsibility and is in a unique position to help address the world’s security issues and contribute to long-term solutions,” Smith also said.

Microsoft also announced the inclusion of an Attack Simulator for Office 365 Threat Intelligence in Microsoft 365, a feature that should make it easier for IT teams to train users to guard against phishing.


Industrial Internet Consortium Develops New IoT Security Maturity Model
12.4.2018 securityweek IoT

The Industrial Internet Consortium (IIC) has developed a new IoT Security Maturity Model (SMM), building on its own security framework and reference architecture. This week it has published the first of two papers: IoT Security Maturity Model: Description and Intended Use. This is primarily a high-level overview aimed at the less technical of IoT stakeholders.

"This is for the businessmen," Ron Zahavi, chief strategist for IoT standards at Microsoft, told SecurityWeek, "to help them understand what is needed of security, and to help them translate that into a required maturity level for their own business." The required maturity level becomes the target maturity level.

A second paper providing a more technical view for the security practitioners will be published in the summer. "The separation of the two," said Zahavi, "allows different groups and verticals to develop specific profiles that can be published with the second technical document."

The purpose of the model is to provide a single IoT SMM for all industry sectors, regardless of individual security requirements; and to be relevant to all IoT implementations, whether home, office or plant. The IIC's guiding principles were to develop a new model suitable for all industries, to cover both process and technology, to leverage existing frameworks such as NIST and ISA-62443 rather than seek to replace them, to be simple and extensible, and to be suitable for use by all existing security assessment firms.

It starts from the basis that maturity is built on three primary dimensions: governance, enablement, and hardening. Each dimension comprises different domains. "Governance covers strategy and the operation and management of practices and process such as threat modeling and risk assessment, and supply chain management," explained Zahavi. "Enablement includes the operation and management of traditional security technology, such as identity and access management, data protection, asset management, physical management, etcetera. Hardening," he added, "is about the operational aspects of vulnerability and patch management, incident response and auditing, and so on." In short, it is process, technology and operation.

IIC Security Maturity Model

Each of the domains and practices is then evaluated on two axes: 'comprehensiveness' and 'scope'. Comprehensiveness, said Zahavi, "is about the degree of depth and consistency that you apply security measures to the dimensions, domains and practices." There are four levels (five, if you include 'nothing'): minimal; ad hoc (where security tends to be reactive to a publicized incident or issue); consistent (using best practices and standards, and possibly centralized rather than spot solutions); and formalized (comprising a well-defined process for managing everything over time and with continuous improvement).

Scope is defined as the degree of fit to the industry or system needs. Here there are three levels: general (where there is no specific assessment of relevance to the specific IoT sector); industry specific (where security is implemented with regard to sector specific requirements – healthcare may be different to manufacturing); and system specific (where security implementation is aligned with the specific needs and risks of a particular system in a particular organization). For the system specific scope, Zahavi commented, "A retail organization might wish to delineate between its PoS sensors and its supply chain sensors."

Combining the comprehensiveness and scope across the different practices allows an organization to define its IoT security maturity at both actual and target levels, and at a very granular level of the security implementation.

The target level of maturity is almost a statement of risk appetite. It is a business function, not a security function. For many years, security teams have operated blindly, with little communication between business and security. This is changing. The digitalization of industry and the merging of operational technology (the primary home of IoT devices) with information technology, and the subsequent exposure of IoT devices to the internet is changing the bottom line of security failures.

While the loss of information can be costly and brand-damaging, the loss of manufacturing can be catastrophic. The growth in ICS attacks and the dramatic effects these can have on profitability has got the attention of the board – and the board is now asking security to explain whether their IoT implementations are secure. Using the IIC SMM can help better align security with business priorities, and can help business and security come together.

The recommended process is for business leaders to specify the maturity level targets, while the security team undertakes a current maturity assessment. The difference between the two levels can be assessed with a gap analysis from which a roadmap for closing any gaps can be developed. The roadmap should lead to any required security enhancements – which should then lead to a reassessment of the maturity level and a repeat of the process.

An aid to this process is a maturity profile template. The IIC hopes that different companies in different sectors will develop and publish high level IIC SMM maturity profiles that can be used by other organizations.

The intention of the IIC with this new IoT security maturity model is to augment, not replace, existing security frameworks. "There already exist accepted frameworks that get down to the control mechanisms for security," explained Zahavi. "But if you look, for example, at the table of controls and the mappings in NIST, they don't get into the level of 'what do I do for my industry and what levels do I need to be in?'.

"What we're doing," he continued, "is we're creating the higher-level maturity aspect of it, which is not met in all of those frameworks -- we're augmenting, we're not replacing. For example, we don't suggest specific required security controls. Instead, we're mapping the SMM – and we'll continue to do this (NIST, for example, is also an IIC member) – mapping practices and the appropriate maturity levels to existing frameworks and controls.

"So," he said, "the intent is, if you have a profile for retail or healthcare or manufacturing, you should be able to look at your industry sector, and go back to those existing frameworks with a much narrower view of which mechanisms and controls you need to then deploy to achieve your target maturity for your own company in your own sector."

The IIC IoT security maturity model is an aid to help companies employ existing favored security frameworks to reach their own defined target level of IoT security maturity.


IoT Security Firm Red Balloon Raises $22 Million
5.4.2018 securityweek IoT

Red Balloon Security, a provider of embedded device security solutions, announced on Wednesday that it has secured $21.9 million through a Series A funding round led by Bain Capital Ventures.

This latest round of funding brings the company’s total funding to $23.5 million.

The company’s flagship Symbiote Defense technology helps customers to detect and defend against emerging threats targeting embedded devices. The technology behind Symbiote was originally developed within Columbia University’s Intrusion Detection Systems Lab, with support of the Defense Advanced Research Projects Agency (DARPA) and the Department of Homeland Security Science and Technology Directorate (DHS S&T).

Symbiote, Red Balloon explains, “defends devices without requiring changes to source code or hardware design, all without impacting the functionality or performance of the device,” adding that the solution has “demonstrated the ability to defend against both n-day and zero-day attacks on embedded devices, even if the attacker has succeeded in bypassing traditional cybersecurity measures.”

Red Balloon claims that Symbiote technology has operated for more than 15 billion continuous hours without a single failure, protecting millions of endpoints around the world.

“Symbiote Defense is a critically important technology for today’s businesses because it is able to prevent malware and other cyber attacks from hijacking, disrupting or corrupting any embedded device,” said Ang Cui, PhD, founder and CEO of Red Balloon Security. “This technology has considerable commercial potential because it is highly effective within any type of embedded device environment, from consumer electronics to factories, connected cars and even power plants. Thanks to the strong support of our investors, we will now be able to make this advanced technology more widely available to commercial users across all major industries.”

Greycroft, American Family Ventures and Abstract Ventures also participated in the funding round.


IIC Publishes Best Practices for Securing Industrial Endpoints
12.3.2018 securityweek IoT

Industrial Internet Consortium Guidance Aims to Improve IIoT Endpoint Security for Manufacturers and Practitioners

The Industrial Internet Consortium (IIC) has published a new paper designed to provide a concise overview of the countermeasures necessary to secure industrial endpoints; that is, the industrial internet of things (IIoT).

The paper (PDF) is not meant to provide a checklist for compliance or certification, but rather a starting point to understand what is necessary to ensure IIoT endpoint security. It is, in fact, a distillation of best practices drawn from existing guidance and compliance frameworks: (IISF [IIC-IISF2016], Industrie 4.0 [Ind4.0-ITSec], IEC 62443 [IEC-62443-11], and NIST SP 800-53 [NIST-800-53r4] [NIST-800-53r5]).

"Although there are existing documents such as the IIC's own Industrial Internet of Things Security Framework (PDF) and other documents from NIST and IEC," comments Dean Weber, CTO at Mocana, "they're complex and abstract; and it's often challenging for practitioners to know how the guidance applies to them in particular."

But however complex the problem, the need to ensure security for the IIoT, both for itself and for the role it plays in the critical infrastructure, is increasing rapidly. The IIoT is an expanding and fundamental part of operational technology, rapidly increasing its attack surface. Criminals are attracted by the possibility of extorting companies that rely on their OT, while nation states are surveilling -- and sometimes employing -- methods to disrupt critical infrastructures.

This paper provides a starting point for improving IIoT endpoint security, such as sensors, actuators, pumps, flow meters, controllers and drives in industrial systems, embedded medical devices, electronic control units, vehicle control systems; and communications infrastructures and gateways.

The authors of the paper -- Steve Hanna (Infineon Technologies), Srinivas Kumar (Mocana), and Dean Weber (Mocana) -- define three levels of endpoint security: basic, enhanced and critical. These correspond to security levels 2, 3, and 4 as defined in IEC 62443 3-3. Neither the levels nor the advice in the paper are geared towards any particular industry sector, but are designed to provide a cross-sector horizontal starting point.

"The purpose of the document," Weber told SecurityWeek, "is to provide some concise recommendations on best practices for securing industrial endpoints. The reason this is so important is because industrial systems are increasingly connected within the system and beyond, including cloud big data. While there are many benefits to having this additional connectivity and bringing crowd intelligence on things like predictive maintenance, customized manufacturing etc, there are also some significant drawbacks if the security is not properly handled."

Basic security is defined as providing protection against "intentional violation using simple means with low resources", such as an ordinary virus. Enhanced security provides protection against attackers using "sophisticated means with moderate resources", such as exploiting known vulnerabilities. Critical security provides protection against attackers with "sophisticated means with extended resources", such as the ability to develop custom zero-day attacks. Risk assessments should determine the correct level of security for each endpoint in different organizations.

Security needs to be interwoven with other requirements such as safety, privacy, reliability and resilience in the face of environmental disruptions, human errors, system faults and attacks in order to provide the overall goal: trustworthiness.

The three security levels are described with the countermeasures required for each level. Basic security requires 'root of trust', 'endpoint identity', 'secure boot', 'cryptographic services', and 'secure communications'. Enhanced security requires the addition of 'endpoint configuration and management'; while critical security further requires 'continuous monitoring' 'security information and event management', and a 'policy and activity dashboard'.

Each of these countermeasures and the rationale for their inclusion in each security level is then further discussed. The detail of some countermeasures changes between the levels. For example, a root of trust is required for all three levels. It is required to provide endpoint identity for all levels; but is further required to provide attestation of software and hardware identity and integrity in the enhanced and critical levels.

"By describing best practices for implementing industrial security that are appropriate for agreed-upon security levels, we’re empowering industrial ecosystem participants to define and request the security they need," said Dean Weber, IIC white paper co-author, and CTO, Mocana. "Integrators can build systems that meet customer security needs and equipment manufacturers can build products that provide necessary security features efficiently."

The difficulty with all best practices is in getting them adopted by relevant parties. Manufacturers are often blamed for developing new product without sufficient regard for building in security. Weber is confident that best practices such as these can reverse things. "Both manufacturers and users cite security as the number one issue for the industrial internet of things," he told SecurityWeek. "But manufacturers don't always know what is required, while users don't always know what to demand.

"These best practices," he continued, "will help solve the industrial endpoint security problem for both the manufacturers and the practitioners. What we've tried to do is provide a summation common to the existing security documents and to do so in short form and easily understood manner; and including footnotes tying it back to the larger documents."


IoT hack: how to break a smart home… again
28.2.2018 Kaspersky  IoT
There can never be too many IoT gadgets – that’s what people usually think when buying yet another connected device with advanced functionality. From our perspective, we also think there can’t be too many IoT investigations. So, we have continued our experiments into checking and uncovering how vulnerable they are, and followed up our research focusing on smart home devices.

Researchers have already been analyzing connected devices for many years, but concerns around cybersecurity in the IoT world are still there, putting users under significant risk. In our previous analysis, possible attack vectors affecting both a device and a network to which it’s connected have been discovered. This time, we’ve chosen a smart hub designed to control sensors and devices installed at home. It can be used for different purposes, such as energy and water management, monitoring and even security systems.

This tiny box receives information from all the devices connected to it, and if something happens or goes wrong, it immediately notifies its user via phone, SMS or email in accordance with its preferences. An interesting thing is that it is also possible to connect the hub to local emergency services, thus alerts will be sent to them accordingly. So, what if someone was able to interrupt this smart home’s system and gain control over home controllers? It could turn life into a nightmare not only for its user, but also for the emergency services. We decided to check a hypothesis and as a result discovered logical vulnerabilities providing cybercriminals with several attack vectors opportunities.

Physical access
First, we decided to check what could be available for exploitation by an attacker being outside of the network. We discovered that the hub’s firmware is available publicly and can be downloaded without any subscription from the vendor’s servers. Therefore, once downloading it, anyone can easily revise the files inside it and analyze them.

We found that the password from the root account in the shadow file is encrypted with the Data Encryption Standard (DES) algorithm. As practice shows, this cryptographic algorithm is not considered to be secure or highly resistant to hacking, and therefore it is possible for an attacker to successfully obtain the hash through brute-force and find out the ‘root’ password.

To access the hub with ‘root’ rights and therefore modify files or execute different commands, physical access is needed. However, we don’t neglect the hardware hacking of devices and not all of them survive afterwards.
 

We explored the device physically, but of course not everyone would be able to do this. However, our further analysis showed there are other options to gain remote access over it.

Remote access
For hub control, users can either use a special mobile application or a web-portal through which they can set up a personal configuration and check all the connected systems.

To implement it, the owner sends a command for synchronization with the hub. At that moment, all settings are packed in the config.jar file, which the hub then downloads and implements.
 

But as we can see, the config.jar file is sent through HTTP and the device’s serial number is used as the device identifier. So, hackers can send the same request with an arbitrary serial number, and download an archive.

Some might think that serial numbers are very unique, but developers prove otherwise: serial numbers are not very well protected and can be brute-forced with a byte selection approach. To check the serial number, remote attackers can send a specially crafted request, and depending on the server’s reply, will receive information if the device is already registered in the system.

Moreover, our initial research has shown that users, without even realizing it, put themselves at risk by publishing their tech reviews online or posting photos of a hub in social networks and openly presenting devices’ serial numbers. And the security consequences will not be long in coming.
 

While analyzing the config.jar file archive, we found that it contains login and password details – all the necessary data to access a user’s account through the web-interface. Although the password is encrypted in the archive, it can be broken by hash decryption with the help of publicly available tools and open-sourced password databases. Importantly, during the initial registration of a user account in the system, there are no password complexity requirements (length, special characters, etc.). This makes password extraction easier.

As a result, we gained access to a user’s smart home with all the settings and sensor information being available for any changes and manipulations. The IP address is also listed there.
 

It is also possible that there might be other personal sensitive information in the archive, given the fact that users often upload their phone numbers into the system to receive alerts and notifications.

Thus, the few steps involved with generating and sending the right requests to the server can provide remote attackers with the possibility of downloading data to access the user’s web interface account, which doesn’t have any additional security layers, such as 2FA (Two Factor Authentication). As a result, attackers can take control over someone’s home and turn off the lights or water, or, even worse, open the doors. So, one day, someone’s smart life could be turned into a complete nightmare. We reported all the information about the discovered vulnerabilities to the vendor, which are now being fixed.

But there is always light at the end of the tunnel…
In addition to smart “boxes”, we had something smaller in our pocket – a smart light bulb, which doesn’t have any critical use, neither for safety or security. However, it also surprised us with a few – but still worrying – security issues.

The smart bulb is connected to a Wi-Fi network and controlled over a mobile application. To set it up a user needs to first download the mobile application (iOS or Android), switch on the bulb, connect to the Wi-Fi access point created by the bulb and provide the bulb with the SSID and password from a local Wi-Fi network.

From the application, users can switch it ON and OFF, set timers and change different aspect of the light, including its density and color. Our goal was to find out if the device might help an attacker in any way to gain access to a local network, from which it would eventually be possible to conduct an attack.

After several attempts, we were lucky to discover a way to get to the device’s firmware through the mobile application. An interesting fact is that the bulb does not interact with the mobile application directly. Instead, both the bulb and the mobile application are connected to a cloud service and communication goes through it. This explains why while sniffing the local network traffic, almost no interaction between the two were found.

We discovered that the bulb requests a firmware update from the server and downloads it through an HTTP protocol that doesn’t secure the communication with servers. If an attacker is in the same network, a man-in-the-middle kind of attack will be an easy task.
 

The hardware reconnaissance with flash dumping led us not only to the firmware, but to user data as well. With a quick look at the information shared with the cloud, no sensitive information seems to have been uploaded from the device or the internal network. But we found all the credentials of the Wi-Fi networks to which the bulb had connected before, which are stored in the device’s flash forever with no encryption – even after a “hard” reset of the device this data was still available. Thus, reselling it on online market places is certainly not a good idea.
 

Get ready
Our latest research has once again confirmed that ‘smart home’ doesn’t mean ‘secure home’. Several logical vulnerabilities (combined with an unconsciously published serial number) can literally open doors to your home and welcome in cybercriminals. Besides this, remote access and control over your smart hub can lead to a wide range of sabotage activities, which could cost you through high electricity bills, a flood or, even more importantly, your mental health.

But even if your smart hub is secure, never forget that the devil is in the details: a tiny thing such as a light bulb could serve as an entry-point for hackers as well, providing them with access to a local network.

That’s why it’s highly important for users to follow these simple cyber hygiene rules:

Always change the default password. Instead use a strict and complex one. Don’t forget to update it regularly.
Don’t share serial numbers, IP addresses and other sensitive information regarding your smart devices on social networks
Be aware and always check the latest information on discovered IoT vulnerabilities.
No less important is that vendors should improve and enhance their security approach to ensure their devices are adequately protected and, as a result, their users. In addition to a cybersecurity check, which is just as vital as testing other features before releasing a product, it is necessary to follow IoT cybersecurity standards. Kaspersky Lab has recently contributed to the ITU-T (International Telecommunication Union — Telecommunication sector) Recommendation, created to help maintain the proper protection of IoT systems, including smart cities, wearable and standalone medical devices and many others.


Mirai Variant Sets Up Proxy Servers on Compromised Devices
22.2.2018 securityweek BotNet IoT

A newly observed variant of the infamous Mirai botnet is capable of setting up proxy servers on the infected Internet of Things (IoT) devices, Fortinet warns.

Mirai is a distributed denial of service (DDoS)-capable malware family that emerged in late 2016. Targeting IoT devices to add them to a botnet and launch powerful attacks, Mirai has been involved on some massive incidents right from the start.

Referred to as OMG because of strings containing "OOMGA" it its configuration table, the malware keeps most of Mirai’s capabilities, but also adds its own features to the mix.

Unlike Mirai, the OMG variant’s configuration includes two strings used to add a firewall rule to ensure traffic on two random ports is allowed, Fortinet discovered.

However, the new malware variation keeps Mirai’s original attack, killer, and scanner modules, which means that it is capable of performing all of the operations that Mirai could, such as killing processes (telnet, ssh, http, and other processes related to other bots), telnet brute-force login, and DDoS attacks.

After initialization, OMG connects to the command and control (C&C) server on port 50023. Once the connection has been established, the malware sends a defined data message to the server to identify itself as a new bot.

The server responds with a 5-byte long data string, where the first byte is a command on how the newly recruited device should be used: 0 if it should be used as a proxy server, 1 for attack, and >1 to terminate the connection.

OMG, the security researchers discovered, uses open source software 3proxy as its proxy server. During setup, it generates two random ports for the http_proxy_port and socks_proxy_port, reports them to the C&C, and adds a firewall rule to allow traffic on these ports.

After enabling the firewall rule, the malware sets up 3proxy with the predefined configuration embedded in its code. The researchers believe the attackers sell access to the IoT proxy server (because the C&C server wasn’t active during investigation, the researchers only performed static analysis).

“This is the first time we have seen a modified Mirai capable of DDOS attacks as well as setting up proxy servers on vulnerable IoT devices. With this development, we believe that more and more Mirai-based bots are going to emerge with new ways of monetization,” Fortinet concludes.


Google to Acquire IoT Management Platform Xively
20.2.2018 securityweek IoT

Google is stepping up its Internet of Things (IoT) game as it has entered into an agreement to acquire Xively, a division of LogMeIn, Inc.

The Xively IoT platform can “help companies in any industry profit from the IoT” and claims to provide “everything needed to build and launch a connected product in months, not years.” It also provides one-click integrations with business tools such as Salesforce.

Formerly known as Cosm and Pachube, LogMeIn acquired Xively in 2011 for approximately $11 million, and will be selling it to Google in a $50 million deal.

Built on LogMeIn’s foundation of security, Xively’s IoT platform is enterprise-ready and is expected to help Google accelerate its customers’ production time when building IoT connected businesses.

“By 2020, it’s estimated that about 20 billion connected things will come online, and analytics and data storage in the cloud are now the cornerstone of any successful IoT solution,” Google says.

The Internet giant is already working on providing a fully managed IoT service via Google Cloud, and the acquisition, which is subject to closing conditions, is expected to complement that.

The resulting product, Google says, would easily and securely connect, manage, and ingest “data from globally dispersed devices.” The platform will pair with the security and scale of Google Cloud, which already provides data analytics and machine learning capabilities to customers.

“Through this acquisition, Cloud IoT Core will gain deep IoT technology and engineering expertise, including Xively’s advanced device management, messaging, and dashboard capabilities. Our customers will benefit from Xively’s extensive feature set and flexible device management platform,” Google says.

While they will continue to invest in their Support-of-Things initiatives, by selling Xively, LogMeIn is exiting the IoT connectivity platform space.

“We believe that Google Cloud, now armed with Xively’s team and great technology – and backed by their platform and developer heritage and reach – are a far better fit for the future of platform leadership,” Bill Wagner, President and CEO, LogMeIn, notes in a blog post.


NIST Working on Global IoT Cybersecurity Standards
20.2.2018 securityweek IoT

NIST is Working Towards International Cybersecurity Standards for the Internet of Things With Draft Interagency Report (NISTIR) 8200

The Internet of Things (IoT) is here and growing. It has the potential to facilitate or obstruct the further evolution of the Fourth Industrial Revolution; largely depending upon whether it is used or abused. Its abusers will be the same criminal and aggressor state actors that currently abuse information systems. But while there are standards and frameworks for defending information networks against aggressors, there are no adequate international standards for securing the internet of things.

In April 2017, the Interagency International Cybersecurity Standardization Working Group (IICS WG) -- established by the National Security Council’s Cyber Interagency Policy Committee (NSC Cyber IPC) -- set up an Internet of Things (IoT) Task Group to determine the current state of international cybersecurity standards development for IoT.

NIST has now published the draft NISTIR document: The Status of International Cybersecurity Standardization for IoT. It is intended to assist the member agencies of the IICS WG Task Group "in their standards planning and to help to coordinate U.S. government participation in international cybersecurity standardization for IoT." NIST is seeking feedback, especially on the information about the state of cybersecurity standardization for IoT, at NISTIR-8200@nist.gov by April 18.

The scope of securing the IoT is a mammoth task. To aid the understanding of this scope, NIST describes the IoT in five separate functional areas: connected vehicles; consumer IoT; health and medical devices; smart buildings, and smart manufacturing (including ICS). There are nuanced differences between securing these functional areas and traditional cyber security. While security has traditionally prioritized confidentiality, integrity and availability (CIA) in that order of priority, for the most part 'availability' is the priority for IoT devices.

Consumer IoT is one area that may be different, with the traditional need for confidentiality (as in privacy) still dominant. Patient privacy is also a consideration for medical devices. But, "In addition to data privacy and patient safety", comments Jun Du, Senior Director and Architect at ZingBox, "we must also put a heavy focus on ensuring uninterrupted service of medical devices. A cyber-attack can bring down the entire hospital by disrupting their service delivery, putting patient lives at risk."

This is the fundamental difference between traditional information security and IoT security -- it is closer to OT than to IT. "The objectives of confidentiality, integrity and availability altogether focus on information security rather than IoT security," adds Du. "When it comes to IoT security, availability of the device is more relevant to business operations than just the security of information. We should focus on availability first, then look at confidentiality and integrity."

Even in consumer IoT, there is an operational element. Many of the threat vectors are similar between IoT and information networks, but the effects of a successful attack could be more dramatic.

The biggest problem for IoT devices, comments Drew Koenig, security solutions architect at Magenic, "are IoT devices that limit or prevent updating and patching. That's the killer; a zero day -- and the only solution is to replace your fridge before someone hacks it and floods your kitchen."

That metaphor traverses NIST's five IoT functional areas: crashed cars, flooded kitchens and locked doors, malfunctioning heart pace makers, stuck elevators and power failures, and failing production lines.

To get the IICS WG Task Group started in its work to discover the current state of international IoT standardization, the NISTIR 8200 compiles a table of potentially relevant existing standards separated into eleven core cybersecurity areas. These areas range from cryptographic techniques and cyber incident management, through IAM and network security, to supply chain risk management to system security engineering.

Each one of these core cybersecurity areas will present its own IoT-specific difficulties. For example, Du comments, "While encryption is a highly recommended security trend, it isn’t without its drawbacks. Encryption can hide valuable details needed by various teams including security researchers, incident response teams, and security vendors in addition to hiding them from hackers. Insider threats may also attempt to leverage end-to-end encryption to evade detection. In order to protect against these risks, IoT vendors should provide limited visibility through exportation of logs, session stats and meta data information."

A wide range of existing and potentially relevant standards are mapped against these core areas, providing links to the standard, the standard developing organization (SDO), and a description of the standard. It becomes the raw material for a gap analysis between existing and necessary standards. Such an analysis is also provided, mapping standards to the core areas across the five functions. Only 'cryptographic techniques' https://www.securityweek.com/review-nist-crypto-standards-and-developmen... and 'IAM' have available standards applicable to four of the five categories; but always with the rider that there is slow uptake of these standards.

The fifth and missing category is medical IoT, which fares worst of all the five categories for existing applicable standards. However, the two core areas of 'IT system security evaluation' and 'network security' have no available standards applicable to any of the five IoT categories. In reality, the entire gap analysis makes depressing viewing: there are no core areas that have standards adequately adopted in any of the five IoT categories. Even where there are standards, uptake is slow.

Missing from this draft document is any standard that requires the ability for firmware updates within the IoT device build. This may be because there is no existing standard that attempts this. Where 'patching' is mentioned in the draft NISTIR document, it is solely for patch management, or remediation where patching is not possible.

"This document is a good start," comments Koenig. The reality, however, is that it will be a long time before any serious benefit comes from the work. He sees two areas of primary concern. The first is a lack of regulation. NIST doesn't regulate the private sector, although its recommendations can be required for the public sector. Even if this work eventually leads to IoT standards recommendations, it will require separate legislation to enforce the recommendations across the private sector. That still won't necessarily address the manufacture of overseas-sourced devices, or the assembly of devices with multiple foreign components.

Without regulation over device manufacture and development, Koenig's second big concern comes into play: "IoT devices that limit or prevent updating and patching. That's the killer," he says.

But even with regulation controlling the manufacture of IoT devices, that still won't necessarily solve the problems. Steve Lentz, CSO and director information security at Samsung Research America has always believed that security teams need to do their own 'due diligence' on products and processes, and not rely on what they are told by vendors. He suspects that standards and regulations "will bring out vendors claiming to provide IoT security. Again, this is where security teams need to do their due diligence and really check/test out these claims," he warns. "IoT is also Wi-Fi which is now everywhere. We need to ensure complete work infrastructure is secure just not the traditional network defenses.

"We need to ensure we thoroughly research solutions that fit our environments," he continued. "The government can give oversight and make recommendations, but we need to find the solution that works best for us."


DoubleDoor, a new IoT Botnet bypasses firewall using two backdoor exploits
14.2.2018 securityaffairs
Exploit  IoT

Security researchers spotted a new IoT botnet dubbed DoubleDoor that is able to bypass firewall as well as modem security using two backdoor exploits.
IoT devices continue to be a privileged target of cyber criminals, cyber attackers against so-called smart objects has seen a rapid evolution. Security researchers at NewSky Security (NewSky Security) have detected a new IoT botnet dubbed DoubleDoor that is able to bypass firewall as well as modem security using two backdoor exploits.

The analysis of the honeypot logs allowed the researchers to detect the new threat, it leverages two known backdoor exploits to manage two levels of authentications.

The first malicious code is the Juniper Networks SmartScreen OS exploit, it triggers the flaw CVE-2015–7755 to bypass the firewall authentication.

CVE-2015–7755 hardcoded backdoor affects the Juniper Networks’ ScreenOS software that powers their Netscreen firewalls.

“Essentially the telnet and SSH daemons of Netscreen firewalls can be accessed by using the hardcoded password <<< %s(un=’%s’) = %u with any username, regardless of it being valid or not.We saw its implementation in the initial attack cycle of DoubleDoor as it attacked our honeypots with username “netscreen” and the backdoor password.” wrote Ankit Anubhav, Principal Researcher, NewSky Security.

Once succeeded, the malicious code uses the CVE-2016–10401 Zyxel modem backdoor exploit to take full control over the IoT device.

The code is a privilege escalation exploit, “which is why the DoubleDoor attackers also performed a password based attack to get a basic privilege account like admin:CenturyL1nk before going for the superuser.”

“This time it was CVE-2016–10401 , a backdoor for ZyXEL PK5001Z devices. This backdoor is straight forward too, with a hardcoded su password as zyad5001.” continues the expert.

DoubleDoor

The experts highlighted that differently from other IoT botnets like Satori or Masuta, the DoubleDoor botnet doesn’t use a unique string in the reconnaissance phase.

“after the threat actors have performed the attack, they want a confirmation whether they were successful of getting control of the IoT device. For this, they try to invoke the shell with invalid commands. If the attacker has succeeded, it will show “{string}: applet not found” where {string} is the invalid command.” observed the research.

“DoubleDoor botnet takes care of this, by using a randomized string in every attack”

The DoubleDoor botnet seems to be in an early stage, most of the attacks are originated from South Korean IPs.

The botnet includes the code to target a limited number of devices, it will succeed only if the victim has a specific unpatched version of Juniper ScreenOS firewall which protects unpatched Zyxel modems.

“Double layer of IoT protection is more common in corporate environments, which don’t rely on built-in IoT authentication and like to protect it with another layer of firewall. Although such corporate devices can be lesser in number, getting control of corporate environment routers can be more valuable for an attacker as it can lead to targeted IoT attacks.” concluded the experts.


"Hide 'N Seek" IoT Botnet Ensnares 20,000 Devices in Days
25.1.2018 securityweek IoT  BotNet

An Internet of Things (IoT) botnet featuring a worm-like spreading mechanism managed to ensnare over 20,000 devices over the course of several days, Bitdefender reports.

Dubbed Hide ‘N Seek, the botnet was first spotted on January 10, when it focused on IP cameras manufactured by a Korean company, but vanished just days after. On January 20, however, the researchers observed a new, improved variant of the malware, which has ensnared more than 20,000 devices worldwide and continues to spread quickly.

The malware was designed to exfiltrate data, execute code, and interfere with the device operation. Employing a complex and decentralized communication technique and multiple anti-tampering methods to prevent hijacking, the botnet uses the same exploit as Reaper (CVE-2016-10401 and other vulnerabilities), Bitdefender says.

The bot’s worm-like spreading mechanism consists of randomly generating a list of IP addresses to target, and then initiating a raw socket SYN connection to each host on specific destination ports (23, 2323, 80, and 8080). After establishing a connection, the bot first looks for a specific banner (“buildroot login:”) and attempts log in via predefined credentials, or launches a dictionary attack if that fails.

Next, the malware attempts to properly identify the target device and select a compromise method, such as setting up a TFTP server if the target is on the same LAN, or a remote payload delivery method if the target is on the Internet.

These pre-configured exploitation techniques are located in a digitally signed memory location to prevent tampering and can be updated remotely and propagated among infected hosts. Targeting IoT devices, the botnet can’t achieve persistence, meaning that a device reboot would clear up the infection.

After Hajime, Hide ‘N Seek becomes the second known IoT botnet to use a decentralized, peer-to-peer architecture. The difference is that, while Hajime used p2p functionality based on the BitTorrent protocol, the new botnet uses a custom-built p2p communication mechanism.

“The bot opens a random port on the victim, and adds firewall rules to allow inbound traffic for the port. It then listens for connections on the open port and only accepts the specific commands described below,” Bitdefender Senior Threat Analyst Bogdan Botezatu explains.

To prevent infiltration or poisoning attempts, the malware uses an elliptic curve key within the file used to authenticate the command for updating the memory zone where configuration settings are stored.

The bot includes support for multiple commands for configuration updates, a data exfiltration mechanism, and a scanning component (which sends to a peer valid credentials found via dictionary attack). It also supports commands to add a new peer to the list and send a peer IP as a response.

“While IoT botnets have been around for years, mainly used for DDoS attacks, the discoveries made during the investigation of the Hide and Seek bot reveal greater levels of complexity and novel capabilities such as information theft – potentially suitable for espionage or extortion. It is also worth noting that the botnet is undergoing constant redesign and rapid expansion,” Botezatu concludes.

A recent NETSCOUT Arbor report on distributed denial of service attacks has revealed that compromised IoT devices can fuel new, complex assaults. The emergence of new IoT botnets such as Masuta or Satori has proved once again the need for improved security for Internet-connected devices.

“As IoT devices become increasing popularity in our modern lives, they also become more attractive to cybercriminals. In fact, in 2017 we recorded a record number of IoT vulnerabilities, with them more than doubling since 2016,” Nadav Avital, security research team leader at Imperva, told SecurityWeek in an emailed statement.

“This [Bitdefender] research also emphasizes the need for an account takeover solution which protects all devices with a network presence. Account takeover is a big problem, however it is not something which IoT vendors provide protection for. It is therefore a good idea for organizations to deploy an external solution for security,” Avital concluded.


New HNS botnet has already compromised more than 20,000 IoT devices
25.1.2018 securityaffairs BotNet  IoT

A new botnet called Hide ‘N Seek (HNS botnet) appeared in the threat landscape, the malware is rapidly spreading infecting unsecured IoT devices, mainly IP cameras.
The HNS botnet was first spotted on January 10th by malware researchers from Bitdefender, then it disappeared for a few days, and it has risen over the weekend.

The number of infected systems grew up from 12 at the time of the discovery up to over 20,000 bots, at the time of writing.

HNS%20botnet

“Bitdefender researchers have uncovered an emerging botnet that uses advanced communication techniques to exploit victims and build its infrastructure. The bot, dubbed HNS, was intercepted by our IoT honeypot system following a credentials dictionary attack on the Telnet service.” states the analysis from Bitdefender.

“The samples identified in our honeypots on Jan. 10 revolved around IP cameras manufactured by a Korean company. These devices seemed to play a major role in the botnet as, out of the 12 IP addresses hardcoded in the sample, 10 used to belong to Focus H&S devices. The new version, observed on Jan. 20, dropped the hardcoded IPs.”

Recently security experts spotted other IoT botnets, most of them linked to the Mirai botnet, such as Satori, Okiru, and Masuta, but the HNS botnet has a different genesis and doesn’t share the source code.

Researchers at Bitdefender found similarities between the HNS and the Hajime botnets, unlike Mirai, Hajime doesn’t use C&C servers, instead, it implements a peer-to-peer network.

Hajime is more sophisticated than Mirai, it implements more mechanisms to hide its activity and running processes and its modular structure allows operators to add new capabilities on the fly.

“It is the second known IoT botnet to date, after the notorious Hajime botnet, that has a decentralized, peer-to-peer architecture,” states Bitdefender. “However, if in the case of Hajime, the P2P functionality was based on the BitTorrent protocol, here we have a custom-built P2P communication mechanism.”

The HNS malware is able to infect a series of IoT devices using the exploit as Reaper, the current version is able to receive and execute several types of commands, such as data exfiltration, code execution and interference with a device’s operation.
HNS%20botnet

According to the experts, the botnet is still under development, it doesn’t include DDoS capabilities, a circumstance that suggests it is intended to be deployed as a proxy network.

“While IoT botnets have been around for years, mainly used for DDoS attacks, the discoveries made during the investigation of the Hide and Seek bot reveal greater levels of complexity and novel capabilities such as information theft – potentially suitable for espionage or extortion.” concluded Bitdefender.

“It is also worth noting that the botnet is undergoing constant redesign and rapid expansion.”

The bot spread by randomly generates a list of IP addresses that could be potentially compromised. It then initiates a raw socket SYN connection to each potential target and continues communication with those devices that answer the request on specific destination ports (23 2323, 80, 8080).

Once the bot has established a connection it will look for a specific banner (“buildroot login:”) presented by the victim. If it gets this login banner, it attempts to log in using a list of default credentials. If the credentials are not correct, the botnet launches a dictionary attack using a hardcoded list.

Once connected to the victim, the malware will run through a “state machine” to determine the type of target device and select the most suitable compromise method. Experts explained that if the device shares the same network with the bot, the bot sets up TFTP server to allow the victim to download the malicious code from the bot. If the victim is located on the internet, the bot will attempt to use a specific remote payload delivery method to get the target device to download and execute the sample.

“These exploitation techniques are preconfigured and are located in a memory location that is digitally signed to prevent tampering. This list can be updated remotely and propagated among infected hosts.” continues the analysis.

Experts observed that the HNS botnet cannot establish persistence on infected devices, once the device restart, the malware will be removed, this means that botnet operators have to continuously manage the HNS botnet.

Let’s monitor the growth of the new-born botnet.


IoT Devices Fuel Complex DDoS Attacks: Report
23.1.2018 securityweek IoT

The continuous use of compromised Internet of Things (IoT) devices to launch distributed denial of service (DDoS) attacks has helped cybercriminals increase the complexity of their assaults, NETSCOUT’s Arbor Networks says.

According to the company’s 13th Annual Worldwide Infrastructure Security Report (WISR), attackers focused on increasing complexity in 2017, and the exploitation of IoT devices helped them achieve this goal. The frequency of attacks has increased as well, following a trend seen for the past several years.

The report is based on 390 responses received from a mix of Tier 1, Tier 2 and Tier 3 service providers, hosting, mobile, enterprise and other types of network operators globally. More than half of respondents are headquartered and operate in North America.

Last year, 57% of enterprise, government and education (EGE) respondents and 45% of data center operators had their network resources depleted due to DDoS attacks. Arbor observed 7.5 million DDoS attacks in 2017.

The largest attack reported by a service provider peaked at 600 Gigabits per second (Gbps), with only one quarter of respondents observing attacks that peaked at over 100Gbps. While the number of very large incidents decreased, however, attackers used more metered attack volumes to achieve their goals, the report reads.

Attack durations surged last year, with 29% of service providers saying they experienced attacks of over 12 hours. 45% of respondents said they experienced more than 21 attacks per month, while 17% were hit more than 500 times per month.

Service providers reported more volumetric attacks, while enterprises noticed a 30% increase in stealthy application-layer attacks. Multi-vector attacks hit 59% of service providers and 48% of enterprises, combining high volume floods, application-layer attacks, and TCP-state exhaustion assaults in a single sustained offensive.

The number of enterprises experiencing stealthy application-layer attacks increased 30% last year. 73% of the attacks targeted HTTP, 69% targeted DNS, and 68% targeted HTTPS. The number of assaults targeting encryption servers went up as well, with 53% of detected attacks aimed at the application layer and 42% of them targeting the SSL/TLS protocol.

Organizations appear to better understand the need for defenses and 77% of responding enterprises said DDoS was either a part of their business or their IT risk assessments in 2017.

DDoS attacks had various but more severe consequences, ranging from reputation/brand damage (57% of respondents) and concerns of customer churn (48% of respondents). The financial impact of DDoS attacks was double compared to 2016, as 56% of respondents admitted to losses of between $10,000 and $100,000.

The increase in threat landscape’s complexity challenged network and security teams. 88% of service providers said they use Intelligent DDoS Mitigation Solutions, while 36% revealed they employ technology that automates DDoS mitigation.

Demand for managed security services is increasing as well, driven by a surge in attack frequency, and 38% of enterprises revealed they rely on third-party and outsourced services (up from 28% the previous year). However, only 50% of respondents said they carried out defensive drills.

Nearly half of respondents have difficulty hiring and retaining skilled personnel. Thus, organizations have less time to conduct incident response training. Fewer organizations and service providers are carrying out defensive drills or plan on doing so, the report reveals.

“Attackers focused on complexity this year, leveraging weaponization of IoT devices while shifting away from reliance on massive attack volume to achieve their goals. Attackers have been effective, and the proportion of enterprises experiencing revenue loss due to DDoS nearly doubled this year, emphasizing the significance of the DDoS threat,” said Darren Anstee, NETSCOUT Arbor Chief Technology Officer.

Ransomware was the most commonly experienced attack last year, with DDoS in second place, but DDoS represented the top threat observed by service providers. Such assaults remain the top concern for 88% of these organizations in 2018 as well, fueled by the weaponized IoT botnets and the attackers’ ability to gain access to sophisticated assault techniques.


Experts discovered a flaw in GoAhead that affects hundreds of thousands IoT devices
26.12.2017 securityaffairs IoT

Experts from Elttam discovered a flaw in GoAhead tiny web server that affects hundreds of thousands IoT devices, it could be exploited to remotely execute malicious code on affected devices.
A vulnerability in the GoAhead tiny web server package, tracked as CVE-2017-17562, affects hundreds of thousands of IoT devices. The GoAhead solution is widely adopted by tech giants, including Comcast, IBM, Boeing, Oracle, D-Link, ZTE, HP, Siemens, and Canon. It is easy to find the tiny web server in almost any IoT device, including printers and routers.

The vulnerability was discovered by experts from the security firm Elttam who devised a method to remotely execute malicious code on devices running the GoAhead web server package. The flaw affects all GoAhead versions before GoAhead 3.6.5.

“This blog post details CVE-2017-17562, a vulnerability which can be exploited to gain reliable remote code execution in all versions of the GoAhead web server < 3.6.5.” reads the analysis published by Elttam.

“The vulnerability is a result of Initialising the environment of forked CGI scripts using untrusted HTTP request parameters, and will affect all user’s who have CGI support enabled with dynamically linked executables (CGI scripts). This behavior, when combined with the glibc dynamic linker, can be abused for remote code execution using special variables such as LD_PRELOAD (commonly used to perform function hooking, see preeny).”

Attackers can exploit the vulnerability if the CGI support is enabled with dynamically linked CGI program. Unfortunately, this configuration is quite common.

Elttam reported the vulnerability to Embedthis, the company who developed the web server, that promptly released an update that addresses the flaw.

Now it is important that hardware manufacturers will include the patch in the instances of the GoAhead running into their products, but this process could take a lot of time.

To have an idea of the impact of such flaw it is possible to query the Shodan search engine, a number of devices between 500,000 and 700,000 could be affected.

GoAhead%20server


❄️🎄3ncr1ptmas🎄❄️
@3ncr1pt3d
CVE-2017-17562: Remote LD_PRELOAD exploitation of GoAhead web server.
So this runs a hell of a lot of things: printers, network gear, CC cameras. Users of telecoms hosting stuff. Convenience without proper configuration.

What I found on Shodan now:

6:07 AM - Dec 19, 2017
13 13 Replies 102 102 Retweets 157 157 likes
Twitter Ads info and privacy
Elttam also released a proof-of-concept code that could be used to test if IoT devices are vulnerable to the CVE-2017-17562 flaw.

Such kind of flaws are exploited by IoT malware like BrickerBot, Mirai, Hajime, and Persirai.

In March, the researcher Pierre Kim revealed that more than 185,000 vulnerable Wi-Fi-connected cameras are exposed to the Internet, due to a flaw in GoAhead server.


Linux.ProxyM IoT Botnet now used to launch hacking attacks against websites
10.12.2017 securityaffairs IoT

A new IoT botnet leveraging the Linux.ProxyM malware is currently being used by crooks in a campaign attempting to hack websites.
Security experts at Doctor Web discovered a new IoT botnet leveraging the Linux.ProxyM malware that is currently being used in a campaign attempting to hack websites.

Experts first analyzed the Linux.ProxyM in July, it was used to create a proxy network through SOCKS proxy server on infected devices that are used to relay malicious traffic, disguising his real source.

The Trojan has been noted since February 2017 but peaked in late May.

According to Dr. Web, the number of devices infected with Linux.ProxyM reached 10,000 units in July since its discovery in February 2017.

The malware is able to target devices based on different architectures including x86, MIPS, MIPSEL, PowerPC, ARM, Superh, Motorola 68000, and SPARC.

“Linux.ProxyM is a malicious program for Linux which launches a SOCKS proxy server on an infected device. Cybercriminals can use it to anonymously perform destructive actions.” wrote Dr Web.

“The known assembly of this Trojan exists for devices possessing the following architectures: x86, MIPS, MIPSEL, PowerPC, ARM, Superh, Motorola 68000, and SPARC. It means Linux.ProxyM can infect almost any Linux device, including routers, set-top boxes, and other similar equipment.”

The campaign observed in September was abusing the botnet to send out spam emails, experts estimated that with each infected device generated around 400 messages per day in September.

Later attacks used the botnet to send out phishing emails, the messages supposedly came from DocuSign, a company that provides electronic signature technology and digital transaction management services for facilitating electronic exchanges of contracts and signed documents.

The phishing messages included a link to a fake DocuSign website that featured an authorization form, the attackers used this schema to trick victims into entering their credentials. Then the victims were being redirected to the real DocuSign authorization page.

Linux.ProxyM docusign bait

In December, crooks started using the Linux.ProxyM’s proxy server to hack websites through various methods, including SQL injections, XSS (Cross-Site Scripting), and Local File Inclusion (LFI).

“[the hacking methods] are SQL injections (an injection of a malicious SQL code into a request to a website database), XSS (Cross-Site Scripting)—an attack method that involves adding a malicious script to a webpage, which is then executed on a computer when this page is opened, and Local File Inclusion (LFI).” continues the analysis.

“This kind of attack allows attackers to remotely read files on an attacked server using specially crafted commands. Among the attacked websites were game severs, forums and resources on other topics, including Russian websites.”

On Dec. 7, researchers at Dr. Web observed 20,000 attacks launched by the Linux.ProxyM botnet. About a month ago, the bots were launching nearly 40,000 attacks per day.

Linux.ProxyM attacks

“Although Linux.ProxyM has only one function—a proxy server—cybercriminals continue finding new opportunities to use it for illegal actions and showing increasing interest in the ‘Internet of things’,” concludes Doctor Web.


IoT Botnet Used in Website Hacking Attacks
9.12.2017 securityweek IoT  BotNet
Embedded Malware Launches SOCKS Proxy Server on Infected IoT Devices

A botnet of Linux-based Internet of Things (IoT) devices is currently being used in a campaign attempting to hack websites, Doctor Web security researchers warn.

Called Linux.ProxyM, the malware has been around since February of this year, and was previously used in spam campaigns. The Trojan was designed to launch a SOCKS proxy server on infected devices and allows attackers to leverage the proxy to perform nefarious operations while hiding their tracks.

To date, the malware has been observed targeting devices with the following architectures: x86, MIPS, MIPSEL, PowerPC, ARM, Superh, Motorola 68000, and SPARC. Basically, it can infect “almost any Linux device, including routers, set-top boxes, and other similar equipment,” the researchers say.

Previous malicious campaigns leveraging the botnet were sending spam emails, with each infected device generating around 400 messages per day in September, Doctor Web says.

Soon after, the bot started sending phishing messages. The emails supposedly came from DocuSign, a service providing users with the possibility to download, view, sign, and track the status of electronic documents.

The phishing messages included a link to a fake DocuSign website that featured an authorization form, in an attempt to trick users into entering their credentials. After that, the victims were being redirected to the real DocuSign authorization page, while their login details had been sent to the attackers.

In December, Linux.ProxyM’s proxy server started being used to hack websites through various methods, including SQL injections, Cross-Site Scripting, and Local File Inclusion (LFI). The actors operating the botnet targeted game severs and forums, and resources on other topics, including Russian websites.

On Dec. 7, the security researchers observed 20,000 attacks launched by the botnet. About a month ago, the bots were launching nearly 40,000 attacks per day.

“Although Linux.ProxyM has only one function—a proxy server—cybercriminals continue finding new opportunities to use it for illegal actions and showing increasing interest in the ‘Internet of things’,” Doctor Web points out.


Corporate IoT Implementation Struggling, Survey Finds
6.12.2017 securityweek IoT   
Security is the Primary Concern for Firms Implementing an IoT Strategy, IT Pros Say

Remaining competitive is the primary motivation for implementing a corporate 'internet of things' (IoT) strategy; but 90% of those doing so admit the implementation is struggling. Security is the primary concern, holding back 59% of organizations with a current IoT project.

Security is followed by the cost of implementation (46%); competing priorities (37%); an intimidatingly complex IT infrastructure (35%); and funding (32%). The figures come from a survey (PDF) published this week by Vanson Bourne, commissioned by the Wi-SUN Alliance, which questioned 350 IT decision makers from firms in the U.S., UK, Sweden and Denmark that are already investing in at least one IoT project.

The purpose of the survey was to help Wi-SUN better understand how it is perceived in the IoT marketplace, and to help plan future operations. Wi-SUN is a non-profit alliance of around 170 major firms throughout the world with a mission to drive interoperable IoT communications based on open global standards in industrial IoT, with particular concern for utilities and smart cities.

Security Concerns Slow Use of IoT in the EnterpriseKey findings from the survey show that the U.S. (65% of respondents) is ahead of the other three countries surveyed with fully implemented IoT strategies. It is 47% in the UK, 44%in Sweden, and 24% in Denmark. The U.S. also leads in prioritizing IoT enablement: U.S. (73%), UK (64%), Sweden (62%) and Denmark (58%).

One clear outcome from the survey is the emphasis on security as the most important characteristic when considering an IoT implementation for both smart cities (84%) and utilities (85%). Second only to security is the preference for industry open standards: again 84% for smart cities, and 81% for utilities.

These two features fit well with the Wi-SUN network design specification. "Wi-SUN is about the communications layer," Phil Beecher, chair of the Wi-SUN Alliance, told SecurityWeek. "We're providing what could be seen as a large scale outdoor IoT wireless mesh that looks like an internet. It has all the resilience and reliability of a decentralized communication network. It doesn't specify any of the applications that run on top of that, so any application that runs over UDP or TCP can be run over Wi-SUN."

That, of course, is only part of a large-scale IoT network. "In a smart city," he continued, "we would provide wireless communication between street lights, or from street lights to traffic signals. But at strategic points there would be a connection to a high speed, probably fiber, connection to transport data to the network's back office." It's not a wifi network because the wifi range is too limiting. Instead Wi-SUN uses stronger radio communications able to cover up to several kilometers.

The security comes in two areas: certificate-based device authentication, and the mesh and wireless topology of the network itself.

"One of our strengths," continued Beecher, "is that we offer bi-directional communications at a fairly high data rate -- so we can do over-the-air upgrades to apply security patches. No device can connect to the network without being 'vetted'. This is based on the use of certificates. Every device has its own certificate burned in during production, and every device needs to have that certificate verified before it can join the network. Once it is verified and on the network, it is possible to download new code into that device."

The process cannot, of course, be retrofitted to old devices that can't be patched. Security here must be applied through traditional network gateways and routers; but in reality organizations with such devices should be considering renewing them with more modern devices -- and taking advantage of security updates and certificate-based security.

"This certificate authentication," said Beecher, "makes it very difficult for a remote attacker to hack any of the devices or a local attacker to tamper with the device. The mesh topology of the network also makes it difficult to deliver an effective DoS attack, whether by jamming or data overload, against the network."

Jamming is difficult because the network uses the military technique of frequency hopping. "You would need a high-power wide-band jammer," he explained. "This is difficult to achieve; although it is possible at, say, military levels. Otherwise Wi-SUN is largely immune to local jamming."