Entries Tagged "hacking"

Page 27 of 78

Maliciously Tampering with Medical Imagery

In what I am sure is only a first in many similar demonstrations, researchers are able to add or remove cancer signs from CT scans. The results easily fool radiologists.

I don’t think the medical device industry has thought at all about data integrity and authentication issues. In a world where sensor data of all kinds is undetectably manipulatable, they’re going to have to start.

Research paper. Slashdot thread.

Posted on April 12, 2019 at 11:13 AMView Comments

Unhackable Cryptography?

A recent article overhyped the release of EverCrypt, a cryptography library created using formal methods to prove security against specific attacks.

The Quanta magazine article sets off a series of “snake-oil” alarm bells. The author’s Github README is more measured and accurate, and illustrates what a cool project this really is. But it’s not “hacker-proof cryptographic code.”

Posted on April 5, 2019 at 9:31 AMView Comments

Malware Installed in Asus Computers through Hacked Update Process

Kaspersky Labs is reporting on a new supply chain attack they call “Shadowhammer.”

In January 2019, we discovered a sophisticated supply chain attack involving the ASUS Live Update Utility. The attack took place between June and November 2018 and according to our telemetry, it affected a large number of users.

[…]

The goal of the attack was to surgically target an unknown pool of users, which were identified by their network adapters’ MAC addresses. To achieve this, the attackers had hardcoded a list of MAC addresses in the trojanized samples and this list was used to identify the actual intended targets of this massive operation. We were able to extract more than 600 unique MAC addresses from over 200 samples used in this attack. Of course, there might be other samples out there with different MAC addresses in their list.

We believe this to be a very sophisticated supply chain attack, which matches or even surpasses the Shadowpad and the CCleaner incidents in complexity and techniques. The reason that it stayed undetected for so long is partly due to the fact that the trojanized updaters were signed with legitimate certificates (eg: “ASUSTeK Computer Inc.”). The malicious updaters were hosted on the official liveupdate01s.asus[.]com and liveupdate01.asus[.]com ASUS update servers.

The sophistication of the attack leads to the speculation that a nation-state—and one of the cyber powers—is responsible.

As I have previously written, supply chain security is “an incredibly complex problem.” These attacks co-opt the very mechanisms we need to trust for our security. And the international nature of our industry results in an array of vulnerabilities that are very hard to secure.

Kim Zetter has a really good article on this. Check if your computer is infected here, or use this diagnostic tool from Asus.

Another news article.

Posted on March 28, 2019 at 6:42 AMView Comments

Cybersecurity Insurance Not Paying for NotPetya Losses

This will complicate things:

To complicate matters, having cyber insurance might not cover everyone’s losses. Zurich American Insurance Company refused to pay out a $100 million claim from Mondelez, saying that since the U.S. and other governments labeled the NotPetya attack as an action by the Russian military their claim was excluded under the “hostile or warlike action in time of peace or war” exemption.

I get that $100 million is real money, but the insurance industry needs to figure out how to properly insure commercial networks against this sort of thing.

Posted on March 8, 2019 at 5:57 AMView Comments

Japanese Government Will Hack Citizens' IoT Devices

The Japanese government is going to run penetration tests against all the IoT devices in their country, in an effort to (1) figure out what’s insecure, and (2) help consumers secure them:

The survey is scheduled to kick off next month, when authorities plan to test the password security of over 200 million IoT devices, beginning with routers and web cameras. Devices in people’s homes and on enterprise networks will be tested alike.

[…]

The Japanese government’s decision to log into users’ IoT devices has sparked outrage in Japan. Many have argued that this is an unnecessary step, as the same results could be achieved by just sending a security alert to all users, as there’s no guarantee that the users found to be using default or easy-to-guess passwords would change their passwords after being notified in private.

However, the government’s plan has its technical merits. Many of today’s IoT and router botnets are being built by hackers who take over devices with default or easy-to-guess passwords.

Hackers can also build botnets with the help of exploits and vulnerabilities in router firmware, but the easiest way to assemble a botnet is by collecting the ones that users have failed to secure with custom passwords.

Securing these devices is often a pain, as some expose Telnet or SSH ports online without the users’ knowledge, and for which very few users know how to change passwords. Further, other devices also come with secret backdoor accounts that in some cases can’t be removed without a firmware update.

I am interested in the results of this survey. Japan isn’t very different from other industrialized nations in this regard, so their findings will be general. I am less optimistic about the country’s ability to secure all of this stuff—especially before the 2020 Summer Olympics.

Posted on January 28, 2019 at 1:40 PMView Comments

Hacking the GCHQ Backdoor

Last week, I evaluated the security of a recent GCHQ backdoor proposal for communications systems. Furthering the debate, Nate Cardozo and Seth Schoen of EFF explain how this sort of backdoor can be detected:

In fact, we think when the ghost feature is active­—silently inserting a secret eavesdropping member into an otherwise end-to-end encrypted conversation in the manner described by the GCHQ authors­—it could be detected (by the target as well as certain third parties) with at least four different techniques: binary reverse engineering, cryptographic side channels, network-traffic analysis, and crash log analysis. Further, crash log analysis could lead unrelated third parties to find evidence of the ghost in use, and it’s even possible that binary reverse engineering could lead researchers to find ways to disable the ghost capability on the client side. It should be obvious that none of these possibilities are desirable for law enforcement or society as a whole. And while we’ve theorized some types of mitigations that might make the ghost less detectable by particular techniques, they could also impose considerable costs to the network when deployed at the necessary scale, as well as creating new potential security risks or detection methods.

Other critiques of the system were written by Susan Landau and Matthew Green.

EDITED TO ADD (1/26): Good commentary on how to defeat the backdoor detection.

EDITED TO ADD (3/1): Another good essay on the security risks of this back door.

Posted on January 25, 2019 at 6:08 AMView Comments

Hacking Construction Cranes

Construction cranes are vulnerable to hacking:

In our research and vulnerability discoveries, we found that weaknesses in the controllers can be (easily) taken advantage of to move full-sized machines such as cranes used in construction sites and factories. In the different attack classes that we’ve outlined, we were able to perform the attacks quickly and even switch on the controlled machine despite an operator’s having issued an emergency stop (e-stop).

The core of the problem lies in how, instead of depending on wireless, standard technologies, these industrial remote controllers rely on proprietary RF protocols, which are decades old and are primarily focused on safety at the expense of security. It wasn’t until the arrival of Industry 4.0, as well as the continuing adoption of the industrial internet of things (IIoT), that industries began to acknowledge the pressing need for security.

News article. Report.

Posted on January 22, 2019 at 5:59 AMView Comments

New Attack Against Electrum Bitcoin Wallets

This is clever:

How the attack works:

  • Attacker added tens of malicious servers to the Electrum wallet network.
  • Users of legitimate Electrum wallets initiate a Bitcoin transaction.
  • If the transaction reaches one of the malicious servers, these servers reply with an error message that urges users to download a wallet app update from a malicious website (GitHub repo).
  • User clicks the link and downloads the malicious update.
  • When the user opens the malicious Electrum wallet, the app asks the user for a two-factor authentication (2FA) code. This is a red flag, as these 2FA codes are only requested before sending funds, and not at wallet startup.
  • The malicious Electrum wallet uses the 2FA code to steal the user’s funds and transfer them to the attacker’s Bitcoin addresses.

The problem here is that Electrum servers are allowed to trigger popups with custom text inside users’ wallets.

Posted on January 7, 2019 at 6:13 AMView Comments

1 25 26 27 28 29 78

Sidebar photo of Bruce Schneier by Joe MacInnis.