A Web Based Controller For Your Garage Door

Garage doors! You could get out of your vehicle and open and close them yourself, but that kinda sucks. It’s much preferable to have them raise and lower courtesy some mechanical contrivance, and even better if that is controlled via the web. [Juan Schiavoni] shows us how to achieve the latter with their latest project.

The web-based controller is based around a Xiao ESP32 microcontroller board, chosen for its baked-in WiFi connectivity. It’s set up to host its own web interface which you can login to with a password via a browser. If you have the correct authorization, you can then hit a button to open or close the garage door.

To interface the ESP32 with the garage door itself, [Juan] went the easy route. To trigger opening or closing the door, the ESP32 merely flicks an IO pin to toggle a transistor, which is hooked up to the button of the original garage door opener. Meanwhile, the ESP32 is also hooked up with a magnetic switch which is activated by a magnet on the garage door itself. This serves as a crude indicator as to the current status of the door—whether currently open or closed. This is crucial to ensure the indicated door status shown in the web app remains synced with the status of the door in reality.

It’s a simple project, and reminds us that we needn’t always do things the hard way. [Juan] could have figured out how to hook the ESP32 up with some radio chips to emulate the original garage door opener, but why bother? hooking it up to the original remote was far easier and more reliable anyway. We’ve seen a good few garage door hacks over the years; if you’ve got your own unique take on this classic, don’t hesitate to notify the tipsline!

[Thanks to Stillman for the tip!]

This Week In Security: The X DDoS, The ESP32 Basementdoor, And The CamelCase RCE

We would be remiss if we didn’t address the X Distributed Denial of Service (DDoS) attack that’s been happening this week. It seems like everyone is is trying to make political hay out of the DDoS, but we’re going to set that aside as much as possible and talk about the technical details. Elon made an early statement that X was down due to a cyberattack, with the source IPs tracing back to “the Ukraine area”.

The latest reporting seems to conclude that this was indeed a DDoS, and a threat group named “Dark Storm” has taken credit for the attack. Dark Storm does not seem to be of Ukrainian origin or affiliation.

We’re going to try to read the tea leaves just a bit, but remember that about the only thing we know for sure is that X was unreachable for many users several times this week. This is completely consistent with the suspected DDoS attack. The quirk of modern DDoS attacks is that the IP addresses on the packets are never trustworthy.

There are two broad tactics used for large-scale DDoS attacks, sometimes used simultaneously. The first is the simple botnet. Computers, routers, servers, and cameras around the world have been infected with malware, and then remote controlled to create massive botnets. Those botnets usually come equipped with a DDoS function, allowing the botnet runner to task all the bots with sending traffic to the DDoS victim IPs. That traffic may be UDP packets with spoofed or legitimate source IPs, or it may be TCP Synchronization requests, with spoofed source IPs.

The other common approach is the reflection or amplification attack. This is where a public server can be manipulated into sending unsolicited traffic to a victim IP. It’s usually DNS, where a short message request can return a much larger response. And because DNS uses UDP, it’s trivial to convince the DNS server to send that larger response to a victim’s address, amplifying the attack.

Put these two techniques together, and you have a botnet sending spoofed requests to servers, that unintentionally send the DDoS traffic on to the target. And suddenly it’s understandable why it’s so difficult to nail down attribution for this sort of attack. It may very well be that a botnet with a heavy Ukrainian presence was involved in the attack, which at the same time doesn’t preclude Dark Storm as the originator. The tea leaves are still murky on this one.

Continue reading “This Week In Security: The X DDoS, The ESP32 Basementdoor, And The CamelCase RCE”

The ESP32 Bluetooth Backdoor That Wasn’t

Recently there was a panicked scrambling after the announcement by [Tarlogic] of a ‘backdoor’ found in Espressif’s popular ESP32 MCUs. Specifically a backdoor on  the Bluetooth side that would give a lot of control over the system to any attacker. As [Xeno Kovah] explains, much about these claims is exaggerated, and calling it a ‘backdoor’ is far beyond the scope of what was actually discovered.

To summarize the original findings, the researchers found a number of vendor-specific commands (VSCs) in the (publicly available) ESP32 ROM that can be sent via the host-controller interface (HCI) between the software and the Bluetooth PHY. They found that these VSCs could do things like writing and reading the firmware in the PHY, as well as send low-level packets.

The thing about VSCs is of course that these are a standard feature with Bluetooth controllers, with each manufacturer implementing a range of these for use with their own software SDK. These VSCs allow for updating firmware, report temperatures and features like debugging, and are generally documented (except for Broadcom).

Effectively, [Xeno] makes the point that VSCs are a standard feature in Bluetooth controllers, which – like most features – can also be abused. [Tarlogic] has since updated their article as well to distance themselves from the ‘backdoor’ term and instead want to call these VSCs a ‘hidden feature’. That said, if these VSCs in ESP32 chips are a security risk, then as [Xeno] duly notes, millions of BT controllers from Texas Instruments, Broadcom and others with similar VSCs would similarly be a security risk.

This Week In Security: Medical Backdoors, Strings, And Changes At Let’s Encrypt

There are some interesting questions afoot, with the news that the Contec CMS8000 medical monitoring system has a backdoor. And this isn’t the normal debug port accidentally left in the firmware. The CISA PDF has all the details, and it’s weird. The device firmware attempts to mount an NFS share from an IP address owned by an undisclosed university. If that mount command succeeds, binary files would be copied to the local filesystem and executed.

Additionally, the firmware sends patient and sensor data to this same hard-coded IP address. This backdoor also includes a system call to enable the eth0 network before attempting to access the hardcoded IP address, meaning that simply disabling the Ethernet connection in the device options is not sufficient to prevent the backdoor from triggering. This is a stark reminder that in the firmware world, workarounds and mitigations are often inadequate. For instance, you could set the gateway address to a bogus value, but a slightly more sophisticated firmware could trivially enable a bridge or alias approach, completely bypassing those settings. There is no fix at this time, and the guidance is pretty straightforward — unplug the affected devices.

Continue reading “This Week In Security: Medical Backdoors, Strings, And Changes At Let’s Encrypt”

This Week In Security: Backdoored Backdoors, Leaking Cameras, And The Safety Label

The mad lads at watchTowr are back with their unique blend of zany humor and impressive security research. And this time, it’s the curious case of backdoors within popular backdoors, and the list of unclaimed domains that malicious software would just love to contact.

OK, that needs some explanation. We’re mainly talking about web shells here. Those are the bits of code that get uploaded to a web server, that provide remote access to the computer. The typical example is a web application that allows unrestricted uploads. If an attacker can upload a PHP file to a folder where .php files are used to serve web pages, accessing that endpoint runs the arbitrary PHP code. Upload a web shell, and accessing that endpoint gives a command line interface into the machine.

The quirk here is that most attackers don’t write their own tools. And often times those tools have special, undocumented features, like loading a zero-size image from a .ru domain. The webshell developer couldn’t be bothered to actually do the legwork of breaking into servers, so instead added this little dial-home feature, to report on where to find all those newly backdoored machines. Yes, many of the popular backdoors are themselves backdoored.

This brings us to what watchTowr researchers discovered — many of those backdoor domains were either never registered, or the registration has been allowed to expire. So they did what any team of researchers would do: Buy up all the available backdoor domains, set up a logging server, and just see what happens. And what happened was thousands of compromised machines checking in at these old domains. Among the 4000+ unique systems, there were a total of 4 .gov. domains from governments in Bangladesh, Nigeria, and China. It’s an interesting romp through old backdoors, and a good look at the state of still-compromised machines.

Continue reading “This Week In Security: Backdoored Backdoors, Leaking Cameras, And The Safety Label”

A Low Effort, Low Energy Doorbell

Bluetooth is a good way to connect devices that are near each other. However, it can drain batteries which is one reason Bluetooth Low Energy — BLE — exists. [Drmph] shows how easy it is to deploy BLE to make, in this case, a doorbell. He even shows how you can refit an existing doorbell to use the newer technology.

Like many projects, this one started out of necessity. The existing wireless doorbell failed, but it was difficult to find a new unit with good review. Cheap doorbells tend to ring spuriously due to interference. BLE, of course, doesn’t have that problem. Common BLE modules make up the bulk of the project. It is easy enough to add your own style to the doorbell like a voice announcement or musical playback. The transmitter is little more than a switch, the module, a coin cell, and an LED.

It is, of course, possible to have a single receiver read multiple doorbells. For example, a front door and back door with different tones. The post shows how to make a remote monitor, too, if you need the bell to ring beyond the range of BLE.

A fun, simple, and useful project. Of course, the cool doorbells now have video. Just be careful not to get carried away.

This Week In Security: National Backdoors, Web3 Backdoors, And Nearest Neighbor WiFi

Maybe those backdoors weren’t such a great idea. Several US Telecom networks have been compromised by a foreign actor, likely China’s Salt Typhoon, and it looks like one of the vectors of compromise is the Communications Assistance for Law Enforcement Act (CALEA) systems that allow for automatic wiretapping at government request.

[Jeff Greene], a government official with the Cybersecurity and Infrastructure Security Agency (CISA), has advised that end-user encryption is the way to maintain safe communications. This moment should forever be the touchstone we call upon when discussing ideas like mandated encryption backdoors and even the entire idea of automated wiretapping systems like CALEA. He went on to make a rather startling statement:

I think it would be impossible for us to predict a time frame on when we’ll have full eviction

There are obviously lots of unanswered questions, but with statements like this from CISA, this seems to be an extremely serious compromise. CALEA has been extended to Internet data, and earlier reports suggest that attackers have access to Internet traffic as a result. This leaves the US telecom infrastructure in a precarious position where any given telephone call, text message, or data packet may be intercepted by an overseas attacker. And the FCC isn’t exactly inspiring us with confidence as to its “decisive steps” to fix things. Continue reading “This Week In Security: National Backdoors, Web3 Backdoors, And Nearest Neighbor WiFi”