Body Heat Sensing PC Security System

April 8, 2011 by 25 Comments

lockifnothot

[Didier Stevens] wrote in to tell us about a little piece of PC security software he put together recently. His application, LockIfNotHot, works in conjunction with your PC as well as an IR temperature sensor in order to lock your computer the moment you step away.

The theory behind the system is pretty simple. Basically, the IR temp sensor monitors when you are at your desk, sensing your presence by the heat your body gives off. As soon as you step away however, it locks the computer since the temperature of the surrounding area immediately drops. It’s pretty simple, but as you can see in the video below, it works quite well.

The software has configurable set points and timeout values, which make it flexible enough to adapt to your specific situation. He happens to use an off-the-shelf IR sensor, but we assume any USB temperature module will do the trick. If you happen to work with sensitive information but often forget to lock your workstation, this is the program for you!

Continue reading to see a quick demonstration of his software in action.

Continue reading “Body Heat Sensing PC Security System” →

Photo of the head unit , with "Hacked by greenluigi1" in the center of the UI

Hacking A Hyundai Ioniq’s Infotainment System Again After Security Fixes

June 8, 2023 by 15 Comments

These days modern cars are nothing if not a grouping of networked software held together by bits of hardware. This is reflected not only in the rapidly increasing number of ECUs, but also infotainment systems and all-glass cockpits. For better or worse, this offers many exciting hacking possibilities, which [greenluigi1] was more than happy to explore with their new 2021 Hyundai Ioniq SEL last year. Naturally, Hyundai then proceeded to ‘fix’ these vulnerabilities, offering the exciting chance to test the Hyundai engineers’ homework, and proceed to bypass it again.

When we last left off in [greenluigi1]’s adventures, the Hyundai D-Audio 2V Linux-based infotainment system (formally called in-vehicle entertainment, or IVI) in question had been convinced to run custom applications after a fair bit of effort to get root access via the Engineering Menu and some firmware image hacking. Joyous hacking and exploration of the car’s CAN network and RPC messaging system ensued. Then Hyundai released a new firmware image, after months of silence and all old firmware images pulled from the download page.

In this new firmware image, big changes were visible right off the bat, with two different ZIP files instead of the single one from before. One of these ZIP files also couldn’t be decrypted any more with the old key. Unfortunately for Hyundai, the curse of backwards compatibility with older IVIs meant that the ZIP targeting headunits running the older firmware also contained the key for the new ZIP file.

Other changes included some further obfuscation to this key and the public key used for firmware hash verification, which also involved using a Micom RPC call via the CAN bus to obtain some vehicle specific information. Unfortunately, this is where Hyundai’s engineers seemed to have stopped copying reference code samples, and used a unique RSA private key to sign firmware images with. Fortunately, they did not bother to check whether the updater actually always verifies the signature, allowing for unsigned code to be installed.

All in all, a fascinating bit of reverse-engineering and sheer stubborn persistence, just so that the IVI that’s in your car can run the applications which you developed. We’re looking forward to the next installments in this series as the ball is once again firmly in Hyundai’s court.

This Week In Security: OpenWrt, ZOOM, And Systemd

April 3, 2020 by 21 Comments

OpenWrt announced a problem in opkg, their super-lightweight package manager. OpenWrt’s target hardware, routers, make for an interesting security challenge. A Linux install that fits in just 4 MB of flash memory is a minor miracle in itself, and many compromises had to be made. In this case, we’re interested in the lack of SSL: a 4 MB install just can’t include SSL support. As a result, the package manager can’t rely on HTTPS for secure downloads. Instead, opkg first downloads a pair of files: A list of packages, which contains a SHA256 of each package, and then a second file containing an Ed25519 signature. When an individual package is installed, the SHA256 hash of the downloaded package can be compared with the hash provided in the list of packages.


It’s a valid approach, but there was a bug, discovered by [Guido Vranken], in how opkg reads the hash values from the package list. The leading space triggers some questionable pointer arithmetic, and as a result, opkg believes the SHA256 hash is simply blank. Rather than fail the install, the hash verification is simply skipped. The result? Opkg is vulnerable to a rather simple man in the middle attack.

OpenWrt doesn’t do any automatic installs or automatic updates, so this vulnerability will likely not be widely abused, but it could be used for a targeted attack. An attacker would need to be in a position to MitM the router’s internet connection while software was being installed. Regardless, make sure you’re running the latest OpenWrt release to mitigate this issue. Via Ars Technica.

Wireguard V1.0

With the Linux Kernel version 5.6 being finally released, Wireguard has finally been christened as a stable release. An interesting aside, Google has enabled Wireguard in their Generic Kernel Image (GKI), which may signal more official support for Wireguard VPNs in Android. I’ve also heard reports that one of the larger Android ROM development communities is looking into better system-level Wireguard support as well.

Javascript in Disguise

Javascript makes the web work — and has been a constant thorn in the side of good security. For just an example, remember Samy, the worm that took over Myspace in ’05. That cross-site scripting (XSS) attack used a series of techniques to embed Javascript code in a user’s profile. Whenever that profile page was viewed, the embedded JS code would run, and then replicate itself on the page of whoever had the misfortune of falling into the trap.

Today we have much better protections against XSS attacks, and something like that could never happen again, right? Here’s the thing, for every mitigation like Content-Security-Policy, there is a guy like [theMiddle] who’s coming up with new ways to break it. In this case, he realized that a less-than-perfect CSP could be defeated by encoding Javascript inside a .png, and decoding it to deliver the payload.

Systemd

Ah, systemd. Nothing seems to bring passionate opinions out of the woodwork like a story about it. In this case, it’s a vulnerability found by [Tavis Ormandy] from Google Project Zero. The bug is a race condition, where a cached data structure can be called after it’s already been freed. It’s interesting, because this vulnerability is accessible using DBus, and could potentially be used to get root level access. It was fixed with systemd v220.

Mac Firmware

For those of you running MacOS on Apple hardware, you might want to check your firmware version. Not because there’s a particularly nasty vulnerability in there, but because firmware updates fail silently during OS updates. What’s worse, Apple isn’t publishing release notes, or even acknowledging the most recent firmware version. A crowd-sourced list of the latest firmware versions is available, and you can try to convince your machine to try again, and hope the firmware update works this time.

Anti-Rubber-Ducky

Google recently announced a new security tool, USB Keystroke Injection Protection. I assume the nickname, UKIP, isn’t an intentional reference to British politics. Regardless, this project is intended to help protect against the infamous USB Rubber Ducky attack, by trying to differentiate a real user’s typing cadence, as opposed to a malicious device that types implausibly quickly.

While the project is interesting, there are already examples of how to defeat it that amount to simply running the scripts with slight pauses between keystrokes. Time will tell if UKIP turns into a useful mitigation tool. (Get it?)

SMBGhost

Remember SMBGhost, the new wormable SMB flaw? Well, there is already a detailed explanation and PoC. This particular PoC is a local-only privilege escalation, but a remote code execution attack is like inevitable, so go make sure you’re patched!

Adding Keypad Security To Your Automobile’s Ignition System

November 17, 2011 by 62 Comments

[BadWolf] managed to make some free time to get back to his own electronic projects. This time around he’s created a security system for his car. It’s patched into the ignition, preventing the engine from starting when the key is turned. A driver must first insert the key, then type the combination on a keypad in the center console before the car will fire up.

While he was working on the project he also decided to add a start button to the dash-board (we think it does make it look like a later model vehicle). The keypad is driven by an Arduino Nano which has the start code stored in it. Power for the system is provided by a USB hub hidden behind the dash which he thinks will also come in handy with future hacks.

When the proper code is entered, you’ll hear a rendition of the Super Mario Bros. theme. The speaker also lends a pleasant beep with each keypress. See the demo clip after the break to hear it for yourself.

Continue reading “Adding Keypad Security To Your Automobile’s Ignition System” →

Modern Car Data Systems Lack Security

May 18, 2010 by 65 Comments

Tomorrow a team of researchers will present their paper on Experimental Security Analysis of a Modern Automobile (PDF) at the IEEE Symposium on Security & Privacy. Much like the racing simulators we’ve seen they’re exploiting the ODB-II port to get at the vehicle’s Controller-area network, or CAN-bus. We’re not surprised at all that they can display custom text on the dashboard display or read sensor data from the car. What does surprise us is their exposé on how truly unsecured the system is. It seems that access to any device on the CAN-bus gives them unobstructed control of the car’s systems. Any device can send commands to any other device. They’ve even found a way to write malicious code to the car’s computer which can be programmed to erase itself in the event of a crash.

Much like RFID the security risks here are basically nill for the vast majority of consumers. We just find it a bit surprising that there’s apparently been little thought put into fortifying the communications between the safety systems such as the brakes on the vehicle. For instance, team experimented with sending random packets over the CAN-bus and stumbled across a way to lock the brake on just one wheel. To us it’s conceivable that a malfunctioning device on the network could start sending out damaged packets and cause a dangerous malfunction like this one.

The 14-page PDF linked above is a page-turner, check it out on your hacked ereader during lunch.

This Week In Security: Malicious Rollback, WHOIS, And More

September 13, 2024 by 4 Comments

It’s time to talk about Microsoft’s patch Tuesday, and the odd vulnerability rollback that happened. CVE-2024-43491 has caught some attention, as it’s a 9.8 on the CVSS scale, is under active exploitation, and results in Remote Code Execution (RCE). Yikes, it sounds terrible!

First off, what actually happened? The official statement is that “build version numbers crossed into a range that triggered a code defect”. We don’t know the exact details, but it’s something like an unsigned integer that was interpreted as a signed integer. A build number could have rolled over 32767, and what was intended to be 32768 or higher suddenly became −32767. Lots of “if greater than or equal” logic breaks down in that situation. Because of a logic flaw like this, certain versions of Windows 10 were unintentionally opting out of some historical security fixes.

And that’s where the high CVSS score and active exploitation descriptor comes from. This is simply the highest score of the resurgent flaws, and an acknowledgement that they have been exploited in the past. The good news is that this only applies to Windows 10 build 1507, so either the original install without any of the major updates installed, or one of the Windows 10 Enterprise Long-Term Servicing Branch (LTSB) versions. It seems that the March 2024 monthly security update introduced the problem, and it wasn’t fixed until this month’s updates. Continue reading “This Week In Security: Malicious Rollback, WHOIS, And More” →

This Week In Security: EUCLEAK, Revival Hijack, And More

September 6, 2024 by 5 Comments

[Thomas Roche] of NinjaLab is out with EUCLEAK, (pdf) a physical attack against Infineon security microcontrollers, and the security tokens that contain them. The name is a portmanteau of Euclidean and leak. And no surprise, it’s a data leak in some implementations of the Extended Euclidean Algorithm (EEA), a component of an Elliptical Curve Digital Signature Algorithm (ECDSA).

OK, time to step back. Infineon microcontrollers are the digital smart parts inside popular security tokens like the Yubikey 5, some Java smart cards, and even the Infineon TPMs. These devices all serve a similar purpose. They store one or more secret keys, and are guaranteed to never disclose those keys. Instead, they use their secret keys to do cryptographic functions, like ECDSA signatures, and output the result. There’s even a special set of tests, the Common Criteria, that are intended to backstop these guarantees. What’s interesting is that an otherwise excellent product like the Yubikey 5, that passes all these auditing and certification processes, is still vulnerable.

The actual attack is to perform ECDSA signatures while monitoring the physical chip with an electromagnetic probe. This tiny directional antenna can pick up on EM noise generated by the microprocessor. That EM noise leaks timing information about the internal state of the cryptography, and the secret key can be derived as a result.

This process does require physical access to the token for several minutes. To get useful readings, the plastic case around the security token does need to be disassembled to get the probe close enough to pick up signals. From there it’s at least an hour of post-processing to actually get the key. And most of these security tokens intentionally make the disassembly process rather difficult. The point isn’t that it’s impossible to open up, but that it’s impossible not to notice that your token has been tampered with. Continue reading “This Week In Security: EUCLEAK, Revival Hijack, And More” →