This Pico-W IoT Starter Project Gets You Into Home Assistant Quick As A Flash

Many of us hacker types with some hardware knowledge and a smattering of embedded experience would like to get into home automation, but there can be quite a learning curve. If you’re looking for a hackable starting point; something to deploy, learn about and then later expand upon, then look no further than the PicoW Home Assistant Starter project from [Danilo Campos].

The project is based upon the arduino-pico core, which supports a whole pile of RP2040-based boards, so you don’t need to restrict yourself to the “official” Pico-W, so long as you have working networking, Wi-Fi or otherwise. Integration is provided by the arduino-home-assistant library, which acts as the bridge between your sensors and other widgets, MQTT, and thence the network beyond. Events and sensor data on the end-point are packaged up with MQTT and published out to the broker via the network provided, all for minimal initial effort. Once you’ve got the basic connectivity to your Home Assistant instance working, there are many code examples in the arduino-home-assistant GitHub page to give you a helping start to connect whatever tickles your fancy.

It turns out we’ve covered HA quite a bit on these fair pages, like for example, these sweet automated window blinds. Another hack uses load cells under the bed legs to detect if someone is in bed or not, and if this isn’t your thing, maybe your idea of a home assistant is a bit more like this one?

LoRa Air Quality Monitor Raises The Bar On DIY IoT

We’ve seen an incredible number of homebrew environmental monitors here at Hackaday, and on the whole, they tend to follow a pretty predicable pattern. An ESP8266 gets paired with a common temperature and humidity sensor, perhaps a custom PCB gets invited to the party, and the end result are some values getting pushed out via MQTT. It’s a great weekend project to get your feet wet, but not exactly groundbreaking in 2022.

Which is why we find the AERQ project from [Mircea-Iuliu Micle] so refreshing. Not only does this gadget pick up temperature and humidity as you’d expect, but its Bosch BME688 sensor can also sniff out volatile organic compounds (VOCs) and gases such as carbon monoxide and hydrogen. The datasheet actually claims this is the “first gas sensor with Artificial Intelligence (AI)”, and while we’re not sure what exactly that means in this context, it’s a claim that apparently warrants a price tag of $15+ USD a pop in single quantities.

There’s an AI hiding in there someplace.

But the fancy sensor isn’t the only thing that sets AERQ apart from the competition. Instead of a member of the ubiquitous ESP family, it’s using the Wio-E5, a relatively exotic STM32 package that integrates a long-range LoRa radio. [Mircea-Iuliu] has paired that with a Linx USP-410 chip antenna or, depending on which version of the four-layer PCB you want to use, a u.Fl connector for an external antenna. The whole thing is powered by a simple USB connection, and its Mbed OS firmware is setup to dump all of its collected data onto The Things Network.

All told, it’s a very professional build that certainly wouldn’t look out of place if it was nestled into some off-the-shelf air quality monitor. While the high-end detection capabilities might be a bit overkill for home use, [Mircea-Iuliu Micle] points out that AERQ might provide useful insight for those running indoor events as COVID-19 transitions into its endemic stage.

Swarm Vs. Iridium: Which Satellite IoT Service Is Right For You?

In a world where it seems like everyone’s face is glued to a device screen, the idea that wireless service might be anything other than universal seems just plain silly. But it’s not, as witnessed by vast gaps in cell carrier coverage maps, not to mention the 70% of the planet covered by oceans. The lack of universal coverage can be a real pain for IoT applications, which is a gap that satellite-based IoT services aim to fill.

But which service is right for your application? To help answer that question, [Mike Krumpus] has performed the valuable work of comparing the services offered by Swarm and Iridium in a real-world IoT shootout. On the face of it, the match-up seems a little lopsided — Iridium has been around forever and has a constellation of big satellites and an extensive ground-based infrastructure. But as our own [Al Williams] discovered when he tested out Swarm, there’s something to be said for having a lot of 1/4U Cubesats up there.

[Mike] picked up the gauntlet and did head-to-head tests of the two services under real-world conditions. Using the same Swarm development kit that [Al] used for his test, alongside an Iridium dev board of his own design, [Mike] did basic tests on uplink and downlink times for a short message on each service. We couldn’t find specs on the test message length, but Swarm’s FAQ indicates that packets are limited to 192 bytes, so we assume they’re both in that ballpark. Iridium was the clear winner on uplink and downlink times, which makes sense because Swarm’s constellation is much smaller at this point and leaves large gaps in coverage. But when you consider costs, Swarm wins the day; what would cost over $1,500 with Iridium would set you back a mere $60 with Swarm.

The bottom line, as always, depends on your application and budget, but [Mike]’s work makes it easier to do that analysis.

This Week In Security: Symbiote Research And Detection, Routing Hijacks, Bruggling, And More

Last week we covered the Symbiote Rootkit, based on the excellent work by Blackberry, Intezer, and Cyber Geeks. This particular piece of malware takes some particularly clever and devious steps to hide. It uses an LD_PRELOAD to interfere with system libraries on-the-fly, hiding certain files, processes, ports, and even traffic from users and detection tools. Read last week’s column and the source articles linked there for the details.

There is a general technique for detecting rootkits, where a tool creates a file or process that mimics the elements of the rootkit, and then checks whether any of the fakes mysteriously disappear. In reading about Symbiote, I looked for tooling that we could recommend, that uses this technique to check for infections. Coming up short, I dusted my security researcher hat off, and got to work. A very helpful pointer from Intezer led me to MalwareBazaar’s page on Symbiote. Do note, that page hosts live malware samples. Don’t download lightly.

This brings us to the first big problem we need to address. How do you handle malware without getting your machine and wider network infected? Virtualization can be a big part of the answer here. It’s a really big leap for malware to infect a virtual machine, and then jump the gap to infect the host. A bit of careful setup can make that even safer. First, use a different OS or distro for your VM host and research client. Sophisticated malware tends to be very targeted, and it’s unlikely that a given sample will have support for two different distros baked in. The bare-metal host is an up-to-date install for best security, but what about the victim?

While we want a bulletproof foundation, our research VM needs to be vulnerable. If the malware is targeted at a specific kernel version or library, we need that exact version to even get started. Unfortunately the samples at MalwareBazaar don’t include details on the machine where they were found, but they do come with links off to other analysis tools, like Intezer Analyze. One particular embedded string caught my eye: GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-17) That’s likely from the machine where this particular Symbiote sample was compiled, and it seems like a good starting point. GCC 4.4.7-17 shipped with Red Hat Enterprise Linux version 6.8. So we grab a CentOS 6.8 live DVD ISO, and get it booting on our VM host.

The next step is to download the malware samples directly from MalwareBazaar. They come in encrypted zips, just to make it harder to accidentally infect yourself. We don’t want those to land anywhere but the intended target. I went a step further and disconnected both the virtual network adapter and physical network cable, to truly air gap my research environment. I had my malware and likely target, and it was time to test my theory that Symbiote was trying too hard to be sneaky, and would sound the alarm on itself if I poked it just right.

Success! We’re using touch to create a file named java.h, and using ls to verify that it’s really there. Then, add the LD_PRELOAD and run ls again, and java.h is mysteriously missing. A similar trick works for detecting process hiding. We turn java.h into a script by writing while true; do sleep 1; done into it. Run the script in the background, and see if it’s listed in ps -A -caf. For a filename on Symbiote’s hide list, it too disappears. The best part is that we can script this detection. I give you, sym-test.sh. It creates and runs a simple script for each of the known Symbiote files, then uses ls and ps to look for the scripts. A Symbiote variant that works like the samples we’ve seen in the wild will give away its presence and be detected. If you find Symbiote on your machine via this script, be sure to let us know!

BGP Hijack — Maybe

There was a bit of BGP weirdness last week, where the Russian telecom company, Rostelecom, announced routing for 17.70.96.0/19. This block of IPs is owned by Apple, and all signs point to this being an unauthorized announce. BGP, the Border Gateway Protocol, is one of the most important network protocols you may not have heard of, and essentially carries the instructions on how to route internet traffic around the world. It’s also historically not had any security protocols baked-in, simply relying on good behavior from all the players. There is RPKI, a new standard for cryptographic signatures for routing updates, but it’s not a hard requirement and not widely deployed yet.

BGP, without any of the security enhancement schemes, works by honoring the most specific route available. Apple announces routes for 17.0.0.0/9, a network of over 8,000,000 IPs. Rostelecom started announcing 17.70.96.0/19, a much smaller subnet containing just over 8,000 IPs. The more specific route wins, and Rostelecom has a valid ASN, so the Internet made the routing shift. Someone at Apple was paying attention, and pushed a routing update for 17.70.96.0/21, moving what is presumably the most important 2,046 IPs back to their proper destination. After about 12 hours, Rostelecom dropped the bogus routes. Neither Apple nor Rostelecom have released statements about the incident.

Were this the first incident involving Rostelecom, it would be natural to conclude this was an honest mistake. Rostelecom has demonstrated bad behavior in the past, so the element of plausible deniability is waning. Could this have been part of a targeted operation against someone’s iPhone or Apple account? It’s hard to say whether we’ll be privy to the details any time soon. At the very least, you can watch a replay of the network carnage.

Email Routing Hijack

Cloudflare is expanding into email routing, and researcher [Albert Pedersen] was a bit miffed not to get invited into the closed Beta. (The Beta is open now, if you need virtual email addresses for your domains.) Turns out, you can use something like the Burp Suite to “opt in” to the beta on the sly — just intercept the Cloudflare API response on loading the dashboard, and set "beta": true. The backend doesn’t check after the initial dashboard load. While access to a temporarily closed beta isn’t a huge security issue, it suggests that there might be some similar bugs to find. Spoilers: there were.

When setting up a domain on your Cloudflare account, you first add the domain, and then go through the steps to verify ownership. Until that is completed, it is an unverified domain, a limbo state where you shouldn’t be able to do anything other than complete verification or drop the domain. Even if a domain is fully active in an account, you can attempt to add it to a different account, and it will show up as one of these pending domains. Our intrepid hacker had to check, was there a similar missing check here? What happens if you add email routing to an unverified domain? Turns out, at the time, it worked without complaint. A domain had to already be using Cloudflare for email, but this trick allowed intercepting all emails going to such a domain. [Albert] informed Cloudflare via HackerOne, and scored a handy $6,000 for the find. Nice!

Post-Quantum, But Still Busted

The National Institute of Standards and Technology, NIST, is running an ongoing competition to select the next generation of cryptography algorithms, with the goal of a set of standards that are immune to quantum computers. There was recently a rather stark reminder that in addition to resistance to quantum algorithms, a cryptographic scheme needs to be secure against classical attacks as well.

SIKE was one of the algorithms making its way through the selection process, and a paper was just recently published that demonstrated a technique to crack the algorithm in about an hour. The technique used has been known for a while, but is extremely high-level mathematics, which is why it took so long for the exact attack to be demonstrated. While cryptographers are mathematicians, they don’t generally work in the realm of bleeding-edge math, so these unanticipated interactions do show up from time to time. If nothing else, it’s great that the flaw was discovered now, and not after ratification and widespread use of the new technique.

Bits and Bruggling Bytes

A portmanteau of Browser and Smuggling, Bruggling is a new data exfiltration technique that is just silly enough to work. Some corporate networks try very hard to limit the ways users and malicious applications can get data off the network and out to a bad actor over the Internet. This is something of a hopeless quest, and Bruggling is yet another example. So what is it? Bruggling is stuffing data into the names and contents of bookmarks, and letting the browser sync those bookmarks. As this looks like normal traffic, albeit potentially a *lot* of traffic, it generally won’t trigger any IDS systems the way odd DNS requests might. So far Bruggling is just an academic idea, and hasn’t been observed in the wild, but just may be coming to malware near you.

LibreOffice just patched a handful of issues, and two of them are particularly noteworthy. First is CVE-2022-26305, a flaw in how macros are signed and verified. The signature of the macro itself wasn’t properly checked, and by cloning the serial number and issuer string of a trusted macro, a malicious one could bypass the normal filter. And CVE-2022-26306 is a cryptographic weakness in how LibreOffice stores passwords. The Initialization Vector used for encryption was a static value rather than randomly created for each install. This sort of flaw usually allows a pre-computation attack, where a lookup table can be compiled that enables quickly cracking an arbitrary encrypted data set. In up-to-date versions of LibreOffice, if using this feature, the user will be prompted for a new password to re-encrypt their configuration more securely.

Samba has also fixed a handful of problems, one of which sounds like a great plot point for a Hollywood hacking movie. First is CVE-2022-32744, a logic flaw where any valid password is accepted for a password change request, rather than only accepting the valid password for the account being changed. And CVE-2022-32742 is the fun one, where an SMB1 connection can trigger a buffer underflow. Essentially a client tells the server it wants to print 10 megabytes, and sends along the 15 bytes to print (numbers are fabricated for making the point). The server copies the data from the way-too-small buffer, and uses the size value set by the attacker, a la Heartbleed. I want to see the caper movie where data is stolen by using this sort of bug to print it out to the long-forgotten line-feed printer.

And finally, Atlassian Confluence installs are under active attack, as a result of a handful of exploits. There were hard-coded credentials left behind in the on-premise Confluence solution, and those credentials were released online. A pair of critical vulnerabilities in Servlet Filters are exploitable without valid credentials. If you’re still running unpatched, unmitigated Confluence installs, it may be time to jump straight to containment and cleanup. Ouch!

This Week In Security: Symbiote, Smart Locks, And CosmicStrand

Symbiote is a particularly nasty Linux rootkit, and we have the interesting case of two separate analysis releasing this week. Up first is [CyberMasterV] taking apart a very early sample of the malware. The primary purpose of Symbiote seems to be capturing SSH logins, and this version does so by hooking the Pluggable Authentication Modules (PAM) system to capture users logging in to the machine it resides on. It also watches for SSH and SCP binaries, and sniffs the terminal used by those binaries, thereby capturing outgoing credentials.

All this data gets packaged up as DNS queries and shuffled off to the Command and Control server. “Easy”, I hear you say, “just block DNS traffic to everywhere except a trusted DNS provider.” It’s more clever than that. The data is in the form of valid DNS subdomains. In full, it’s a DNS request to PacketNumber.MachineID.Data.px32.nss.atendimento-estilo[.]com, all appropriately encoded to be valid. Every request will be for a unique host name, so every request gets forwarded to the C&C controller, which does double duty as the authoritative DNS resolver for that domain. You might get some mileage out of blocking (or at least logging) very long DNS queries.

Symbiote also replaces the typical files and devices you would look at to find a potential problem. For instance, /proc/net/tcp is where the kernel reports open TCP connections. On an infected machine, a copy of this file is maintained by the malware, conveniently leaving out the connections resulting from the infections. Symbiote has a hook in fopen, so whenever a process tries to read this location, the read is redirected to the cooked version, neatly hiding the rootkit. This stealth feature is apparently also used to hide other malware from the same attackers that may be on the same machine.
Continue reading “This Week In Security: Symbiote, Smart Locks, And CosmicStrand”

IOT Garage Door Opener Makes For Excellent Beginner IOT Project

If you live in a home with a garage door opener, you may have experienced one or more inevitable moments. You pull up to your home, you press the button on the garage door opener, and… nothing. Or you can’t find the garage door opener. Or you have to mash the button repeatedly to get a response. Or… you get the idea. Thanks to [Core Electronics] however, you now have the basis for using a much better device to control your own garage door: Your phone. You can see the tutorial on the web or in video format below the break.

[Michael] at [Core electronics] was tired of dealing with the inconsistencies and inconveniences of a poorly built remote for his garage door opener. When he inspected the controller board on the garage door opener itself, he found that it was already configured to allow three buttons to be connected: Up, Down, and Stop. Continue reading “IOT Garage Door Opener Makes For Excellent Beginner IOT Project”

ESP32 Powers Fresh Take On An IoT Geiger Counter

Over the years we’ve covered many projects aimed at detecting elevated radiation levels, and a fair number of them have been Internet connected in some way. But as they are often built around the Soviet-era SBM-20 Geiger–Müller tube, these devices have generally adhered to a fairly conservative design. With the current situation in Europe heightening concerns over potential radiation exposure, [g3gg0] thought it was a good a time as any to revisit the idea of an Internet-connected Geiger counter using more modern components.

Now to be clear, even this modernized approach still makes use of that same SBM-20 tube. There’s such an incredible wealth of information floating around out there about how to work with them that you’d almost put yourself at a disadvantage to chose something else to base your design on. Put simply, it’s hard to go wrong with a classic.

An unfortunate bug was discovered in the HV circuit.

That said, [g3gg0] decided early on that the design would use as many SMD components as possible, a considerable departure from many of the SBM-20 counters we’ve seen. That meant coming up with a new high-voltage power supply capable of providing the tube with the necessary 400 V, which from the sound of things, took a few attempts to complete. The final result is perhaps the smallest and cleanest looking board we’ve ever seen play host to this particular tube.

To run the show, [g3gg0] selected the ESP32-PICO-D4. You certainly don’t need such a powerful microcontroller to read the impulses from the SBM-20 tube and publish them via MQTT, but to be fair, the chip has a number of other duties. It’s handling the WS2812 RGB LEDs that go off in response to detected particles, running the (apparently optional) 2.9 inch WaveShare electronic paper display, and also pulling data from a BME280 environmental sensor as well as a CCS811 VOC sensor — so it’s keeping fairly busy.

As impressive as this build is, we do hate that it had to be built. From certain world leaders dropping casual comments about the strength of their nuclear arsenal to foolhardy attempts to capture the Chernobyl power station, having access to a reliable Geiger counter isn’t an unreasonable precaution right now. For everyone’s sake, let’s hope the fancy RGB LEDs on this particular build remain as dark as possible.

Continue reading “ESP32 Powers Fresh Take On An IoT Geiger Counter”