Wind turbines are a great source of renewable energy, and a great DIY project, too. They can be built with all kinds of materials and the barrier for entry is low for the beginner. [Fab] has built just such a device, taking advantage of modern construction techniques, and dubbed it the WinDIY.

The WinDIY design is mostly 3D printed, with a familiar three-bladed design. The diameter of the rotor is 1.2 m, meaning that braking and regulating the turbine is required for safety in high winds. [Fab] is aiming to achieve this control with a combination of mechanical and electronic braking, as well as variable-pitch blades. The benefit of 3D printing the design is it allows iterations to be made quickly, particularly of parts with complex geometries that would be too time-consuming or expensive to machine otherwise.

[Fab]’s writeup goes into great detail on topics like the design of the pitch control systems and other minutae, which should serve as a great reference for anyone else working on a similar project. If you’re looking for something with more of a sci-fi future vibe, consider attempting a vertical-axis build instead.

source https://hackaday.com/2020/08/07/hawt-wind-turbine-is-mostly-3d-printed/

This year, at DEF CON 28 DEF CON Safe Mode, security researchers [Jiska Classen] and [Francesco Gringoli] gave a talk about inter-chip privilege escalation using wireless coexistence mechanisms. The title is catchy, sure, but what exactly is this about?

To understand this security flaw, or group of security flaws, we first need to know what wireless coexistence mechanisms are. Modern devices can support cellular and non-cellular wireless communications standards at the same time (LTE, WiFi, Bluetooth). Given the desired miniaturization of our devices, the different subsystems that support these communication technologies must reside in very close physical proximity within the device (in-device coexistence). The resulting high level of reciprocal leakage can at times cause considerable interference.

There are several scenarios where interference can occur, the main ones are:

• Two radio systems occupy neighboring frequencies and carrier leakage occurs
• The harmonics of one transmitter fall on frequencies used by another system
• Two radio systems share the same frequencies

To tackle these kind of problems, manufacturers had to implement strategies so that the devices wireless chips can coexist (sometimes even sharing the same antenna) and reduce interference to a minimum. They are called coexistence mechanisms and enable high-performance communication on intersecting frequency bands and thus, they are essential to any modern mobile device. Despite open solutions exist, such as the Mobile Wireless Standards, the manufacturers usually implement proprietary solutions.

Spectra

Spectra is a new attack class demonstrated in this DEF CON talk, which is focused on Broadcom and Cypress WiFi/Bluetooth combo chips. On a combo chip, WiFi and Bluetooth run on separate processing cores and coexistence information is directly exchanged between cores using the Serial Enhanced Coexistence Interface (SECI) and does not go through the underlying operating system.

Spectra class attacks exploit flaws in the interfaces between wireless cores in which one core can achieve denial of service (DoS), information disclosure and even code execution on another core. The reasoning here is, from an attacker perspective, to leverage a Bluetooth subsystem remote code execution (RCE) to perform WiFi RCE and maybe even LTE RCE. Keep in mind that this remote code execution is happening in these CPU core subsystems, and so can be completely invisible to the main device CPU and OS.

Join me below where the talk is embedded and where I will also dig into the denial of service, information disclosure, and code execution topics of the Spectra attack.

Denial of Service

This happens when one wireless core denies transmission to the other core. DoS attacks are possible if one core is able to claim spectrum resources of the other core. As this is the basic working principle of any coexistence interface, all of them are vulnerable by definition, as long as one core keeps constantly claiming the resource for himself. Other DoS opportunities arise from one wireless core being able to crash another via shared RAM abuse.

Information Disclosure

One wireless core can infer data or actions of the other core. One example is when connecting an HID device like a keyboard. Timings and contents of keypresses can be observed on the host that receives those keystrokes. However, an attacker who has only code execution on a WiFi chip should not be able to make such observations. While the content of the keypresses are missing, it is possible for code running on the WiFi chip to infer timing statistics about the keys pressed in the Bluetooth side. This becomes interesting for inferring passwords and password lengths.

Code Execution

One wireless core can execute code within the other core. The security researchers demonstrate that it is possible to execute an arbitrary WiFi address with controlled contents via Bluetooth. This happens because when both cores are running, they share a RAM region which contain, among other information, a large function table. By overwriting a specific address, it is possible to control the WiFi core program counter. This means that a Bluetooth subsystem exploit can turn into a WiFi exploit. In addition, writing to the WiFi buffer and executing addresses produces various kernel panics on Android and iOS, indicating that further escalations into the host are possible and probably it’s just a matter of time until someone pops calc.

Conclusion

Although the research was centered on Broadcom and Cypress combo chips (which cover, by the way, all iPhones, MacBooks, iMacs, older Apple Watches, Samsung S and Note series, some Google Nexus, Raspberry Pi and so forth…) advisories were sent to Intel, MediaTek, Qualcomm, Texas Instruments, Marvell, NXP and they all mention similar coexistence interfaces in their devices. So, mutatis mutandis, and because of its very nature, some Spectra class vulnerabilities probably exist in other vendors too.

And since [Jiska] has a history breaking wireless stuff, we can probably expect a follow-up on this research and this class of inter-chip privilege escalation vulnerabilities. Can’t wait!

source https://hackaday.com/2020/08/07/separation-between-wifi-and-bluetooth-broken-by-the-spectra-co-existence-attack/

On July 23, multiple services related to Garmin were taken offline, including their call center and aviation related services. Thanks to information leaked by Garmin employees, we know that this multi-day outage was caused by the Wastedlocker ransomware campaign. After four days, Garmin was able to start the process of restoring the services.

It’s reported that the requested ransom was an eye-watering $10 million. It’s suspected that Garmin actually paid the ransom. A leaked decryptor program confirms that they received the decryption key. The attack was apparently very widespread through Garmin’s network, as it seems that both workstations and public facing servers were impacted. Let’s hope Garmin learned their lesson, and are shoring up their security practices.

KeePass

KeePass released an update this week addressing a couple flaws in the KeePassRPC service. The update announcement is light on the details, but thankfully we have the full story directly from [Philipp Danzinger], the student that discovered the vulnerabilities. Both vulnerabilities are in the implementation of the SRP-6(a) key exchange protocol.

The vulnerable component is the RPC. KeyPass is essentially a simple database containing passwords. That database is encrypted using the user’s password, so the contained passwords cannot be retrieved without that master password. When a user launches KeePass, he or she is first prompted for this master password, and the database is decrypted using that password. The KeePassRPC service allows other processes, like a browser plugin, to access the now-decrypted database. The first time a new client attemps to access the RPC service, a keypair is generated, and the user is prompted whether to allow the new connection. The public key is stored and marked as trusted, allowing that client to request passwords again in the future, so long as the database had been unlocked.

The authentication protocol is similar to a DH key exchange. A shared value is raised to the power of the secret key resulting in a value called A. This is sent as part of the key exchange, and the formal specification states that it is never allowed to be 0. The problem is that KeePassRPC doesn’t properly check that A != 0. When A is set to 0, the entire key exchange breaks down, as all the values end up equaling 0, as 0^x is always 0. This means that any client can spoof an already authorized client.

The second vulnerability is a weak random number generator used on the server side to generate the secret key b. That key is based on the current date and time, run through a pseudo-random function. Because that function is known, if an attacker can guess the exact time value used, then the secret key is easily calculated. It’s not quite as simple as it seems, as the time value is measured in “ticks”, each tick being 100 nanoseconds. It would take a bit of guesswork and a few thousand guesses to land on the right value, but without any rate limiting, that process would just take a few seconds.

What makes this attack very serious is the fact that modern web browsers allow Javascript running on a webpage to attempt to connect to localhost. If your KeePass database is unlocked, and you load a page running malicious JS, it could access the RPC port and spoof the authorized KeePass browser plugin and download your entire KeePass database. Thankfully this bug was disclosed privately and KeePassRPC has been updated to 1.12.1, which closes both vulnerabilities. Additionally, 1.13 has since been released with additional safeguards against this and similar attacks.

Twitter

Twitter has started displaying a security warning for some users. The details are extremely scarce, but lets see what details we can tease out. First, the warning specifies that the issue in question was a vulnerability in the Twitter Android app, but that it was related to an Android vulnerability, and then links to the October 2018 Android security update. Looking through the vulnerabilities disclosed, there doesn’t seem to be an obvious candidate for the related vulnerability.

KDE Ark

We’ve seen a very simple technique show up in countless security stories: path transversal. It’s simple, you can include a “..” as part of a file path to move up a directory. Often times this can be included in unexpected places to bypass security restrictions, or do other unintended things. Archive files are no exception, and there is nothing preventing a zip archive from having such paths. Most archive programs catch this behavior and don’t allow the archive to extract as it’s written. The venerable unzip command complains like this:

# unzip relative2.zip 
Archive:  relative2.zip
warning:  skipped "../" path component(s) in tmp/../../moo
 extracting: tmp/moo

KDE Ark, until recently, didn’t treat those paths as special, and would happily extract files to whatever path it was instructed to. The update doesn’t seem to be officially released at the time of writing, so be wary of blindly extracting archives until that update is available. There is a useful repository of archives that can be used to test for various transversal issues, and I’ve confirmed that one in particular (harmless zip file containing tmp/../../moo) does demonstrate the issue in Ark.

And Finally…

Remember Boothole? Multiple vendors pushed fixes to this Linux secure boot vulnerability, and a handful of unbootable systems was the result. For the case of RHEL and CentOS, another round of updated packages have been released, fixing the problem and making for bootable systems again.

And what does a criminal do with a database breach? Apparently after selling them, they release them for free. If it wasn’t stolen data, I’d call it a win. Once a breach has made as much money as the seller thinks it’s likely to make, it’s not uncommon for the data to be released for free. These aren’t very popular sites or services, but it might be worth a check to see if your data was included in the release.

source https://hackaday.com/2020/08/07/this-week-in-security-garmin-ransomware-keepass-and-twitter-warnings/

On July 23, multiple services related to Garmin were taken offline, including their call center and aviation related services. Thanks to information leaked by Garmin employees, we know that this multi-day outage was caused by the Wastedlocker ransomware campaign. After four days, Garmin was able to start the process of restoring the services.

It’s reported that the requested ransom was an eye-watering $10 million. It’s suspected that Garmin actually paid the ransom. A leaked decryptor program confirms that they received the decryption key. The attack was apparently very widespread through Garmin’s network, as it seems that both workstations and public facing servers were impacted. Let’s hope Garmin learned their lesson, and are shoring up their security practices.

KeePass

KeePass released an update this week addressing a couple flaws in the KeePassRPC service. The update announcement is light on the details, but thankfully we have the full story directly from [Philipp Danzinger], the student that discovered the vulnerabilities. Both vulnerabilities are in the implementation of the SRP-6(a) key exchange protocol.

The vulnerable component is the RPC. KeyPass is essentially a simple database containing passwords. That database is encrypted using the user’s password, so the contained passwords cannot be retrieved without that master password. When a user launches KeePass, he or she is first prompted for this master password, and the database is decrypted using that password. The KeePassRPC service allows other processes, like a browser plugin, to access the now-decrypted database. The first time a new client attemps to access the RPC service, a keypair is generated, and the user is prompted whether to allow the new connection. The public key is stored and marked as trusted, allowing that client to request passwords again in the future, so long as the database had been unlocked.

The authentication protocol is similar to a DH key exchange. A shared value is raised to the power of the secret key resulting in a value called A. This is sent as part of the key exchange, and the formal specification states that it is never allowed to be 0. The problem is that KeePassRPC doesn’t properly check that A != 0. When A is set to 0, the entire key exchange breaks down, as all the values end up equaling 0, as 0^x is always 0. This means that any client can spoof an already authorized client.

The second vulnerability is a weak random number generator used on the server side to generate the secret key b. That key is based on the current date and time, run through a pseudo-random function. Because that function is known, if an attacker can guess the exact time value used, then the secret key is easily calculated. It’s not quite as simple as it seems, as the time value is measured in “ticks”, each tick being 100 nanoseconds. It would take a bit of guesswork and a few thousand guesses to land on the right value, but without any rate limiting, that process would just take a few seconds.

What makes this attack very serious is the fact that modern web browsers allow Javascript running on a webpage to attempt to connect to localhost. If your KeePass database is unlocked, and you load a page running malicious JS, it could access the RPC port and spoof the authorized KeePass browser plugin and download your entire KeePass database. Thankfully this bug was disclosed privately and KeePassRPC has been updated to 1.12.1, which closes both vulnerabilities. Additionally, 1.13 has since been released with additional safeguards against this and similar attacks.

Twitter

Twitter has started displaying a security warning for some users. The details are extremely scarce, but lets see what details we can tease out. First, the warning specifies that the issue in question was a vulnerability in the Twitter Android app, but that it was related to an Android vulnerability, and then links to the October 2018 Android security update. Looking through the vulnerabilities disclosed, there doesn’t seem to be an obvious candidate for the related vulnerability.

KDE Ark

We’ve seen a very simple technique show up in countless security stories: path transversal. It’s simple, you can include a “..” as part of a file path to move up a directory. Often times this can be included in unexpected places to bypass security restrictions, or do other unintended things. Archive files are no exception, and there is nothing preventing a zip archive from having such paths. Most archive programs catch this behavior and don’t allow the archive to extract as it’s written. The venerable unzip command complains like this:

# unzip relative2.zip 
Archive:  relative2.zip
warning:  skipped "../" path component(s) in tmp/../../moo
 extracting: tmp/moo

KDE Ark, until recently, didn’t treat those paths as special, and would happily extract files to whatever path it was instructed to. The update doesn’t seem to be officially released at the time of writing, so be wary of blindly extracting archives until that update is available. There is a useful repository of archives that can be used to test for various transversal issues, and I’ve confirmed that one in particular (harmless zip file containing tmp/../../moo) does demonstrate the issue in Ark.

And Finally…

Remember Boothole? Multiple vendors pushed fixes to this Linux secure boot vulnerability, and a handful of unbootable systems was the result. For the case of RHEL and CentOS, another round of updated packages have been released, fixing the problem and making for bootable systems again.

And what does a criminal do with a database breach? Apparently after selling them, they release them for free. If it wasn’t stolen data, I’d call it a win. Once a breach has made as much money as the seller thinks it’s likely to make, it’s not uncommon for the data to be released for free. These aren’t very popular sites or services, but it might be worth a check to see if your data was included in the release.

source https://hackaday.com/2020/08/07/this-week-in-security-garmin-ransomware-keepass-and-twitter-warnings/

We love the simplicity of Arduino for focused tasks, we love how Raspberry Pi GPIO pins open a doorway to a wide world of peripherals, and we love the software ecosystem of Intel’s x86 instruction set. It’s great that some products manage to combine all of them together into a single compact package, and we welcome the recent addition of Seeed Studio’s Odyssey X86J4105.

[Ars Technica] recently looked one over and found it impressive from the perspective of a small networked computer, but they didn’t dig too deeply into the maker-friendly side of the product. We can look at the product documentation to see some interesting details. This board is larger than a Raspberry Pi, but its GPIO pins were laid out in exactly the same order as that on a Pi. Some HATs could plug right in, eliminating all the electrical integration leaving just the software issue of ARM vs x86. Tasks that are not suitable for CPU-controlled GPIO (such as generating reliable PWM) can be offloaded to an on-board Arduino-compatible microcontroller. It is built around the SAMD21 chip, similar to the Arduino MKR and Arduino Zero but the pinout does not appear to match any of the popular Arduino form factors.

The Odyssey is not the first x86 single board computer (SBC) to have GPIO pins and an onboard Arduino assistant. LattePanda for example has been executing that game plan (minus the Raspberry Pi pin layout) for the past few years. We’ve followed them since their Kickstarter origins and we’ve featured creative uses here and there. LattePanda’s current offerings are built around Intel CPUs ranging from Atom to Core m3. The Odyssey’s Celeron is roughly in the middle of that range, and the SAMD21 is more capable than the ATmega32U4 (Arduino Leonardo) on board a LattePanda. We always love seeing more options in a market for us to find the right tradeoff to match a given project, and we look forward to the epic journeys yet to come.

source https://hackaday.com/2020/08/07/odyssey-is-a-x86-computer-packing-an-arduino-along-for-the-trip/

Perhaps it’s just one of those things adults dream up to entertain their children, but were you ever told to count slowly the time between seeing a lightning flash and hearing the rumble of thunder? The idea was that the count would tell you how far away the storm was, but from a grown-up perspective the calibration accuracy of a child saying “one… two…three…” in miles seems highly suspect. It’s a valid technique though, and it can be used to monitor thunderstorms by the radio emissions created through the electrical discharge. It’s an area the SAGE project has been working in, and they’ve posted some details including a fascinating run-down of the software techniques , on how lightning can be detected with an RTL-SDR.

A lightning strike produces a characteristic wideband burst that shows up in the time domain as a maximum point that can easily be detected but could also be confused with radio interference from another source. Thus after identifying maxima they zoom in and perform a Fourier transform to spot the wideband burst. It’s all done in Python, and the pleasant surprise is how straightforward to understand it all is.

SAGE are working on a distributed sensor network, so we hope this work might one day give us real-time open lightning data. The FFT approach should ensure that it won’t be fooled by false positives as a traditional detector might be.

Via RTL-SDR.com.

source https://hackaday.com/2020/08/07/lightning-analysis-with-your-sdr/