Thunderstrike Port | Breaking Cybersecurity News | The Hacker News

If you think Apple's Mac computers are much more secure than Windows-powered systems, you need to think again. This isn't true, and security researchers have finally proved it. Two security researchers have developed a proof-of-concept computer worm for the first time that can spread automatically between MacBooks, without any need for them to be networked. Dubbed Thunderstrike 2 , the new proof-of-concept firmware attack is inspired by previously developed proof-of-concept firmware called Thunderstrike. Thunderstrike Attack , developed by security engineer Trammell Hudson, actually took advantage of a vulnerability in Thunderbolt Option ROM that could be used to infect Apple Extensible Firmware Interface (EFI) by allocating a malicious code into the boot ROM of an Apple computer through infected Thunderbolt devices. Thunderstrike 2 Spreads Remotely Although the original Thunderstrike required an attacker to have physical access to your Mac computer to work, t

Apple is preparing to release the second update to OS X Yosemite in the coming days to its customers. The upcoming beta update OS X Yosemite 10.10.2 contains a patch for the Thunderstrike vulnerability that allows malware to be injected into Macs via the Thunderbolt port. Earlier this month, Reverse engineer Trammell Hudson revealed technical details and proof-of-concept of Thunderstrike attack . Thunderstrike, an undetectable bootkit, works by injecting an Option ROM into a Mac's EFI. It is possible because hardware attached to a system through Thunderbolt port are not as secure as a Mac itself. Once installed using Thunderstrike attack, the malware would be almost impossible to detect and remove. Because the firmware used on Macs doesn't always apply to the security of attached hardware. So "Apple had to change the code to not only prevent the Mac's boot ROM from being replaced, but also to prevent it from being rolled back to a state where the at

Identities now transcend human boundaries. Within each line of code and every API call lies a non-human identity. These entities act as programmatic access keys, enabling authentication and facilitating interactions among systems and services, which are essential for every API call, database query, or storage account access. As we depend on multi-factor authentication and passwords to safeguard human identities, a pressing question arises: How do we guarantee the security and integrity of these non-human counterparts? How do we authenticate, authorize, and regulate access for entities devoid of life but crucial for the functioning of critical systems? Let's break it down. The challenge Imagine a cloud-native application as a bustling metropolis of tiny neighborhoods known as microservices, all neatly packed into containers. These microservices function akin to diligent worker bees, each diligently performing its designated task, be it processing data, verifying credentials, or