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”

This Week In Security: IoT In The Hot Tub, App Double Fail, And FreeBSD BadBeacon

[Eaton Zveare] purchased a Jacuzzi hot tub, and splurged for the SmartTub add-on, which connects the whirlpool to the internet so you can control temperature, lights, etc from afar. He didn’t realize he was about to discover a nightmare of security problems. Because as we all know, in IoT, the S stands for security. In this case, the registration email came from smarttub.io, so it was natural to pull up that URL in a web browser to see what was there. The page presented a login prompt, so [Eaton] punched in the credentials he had just generated. “Unauthorized” Well that’s not surprising, but what was very odd was the flash of a dashboard that appeared just before the authorization complaint. Could that have been real data that was unintentionally sent? A screen recorder answered that question, revealing that there was indeed a table loaded up with valid-looking data.

Digging around in the page’s JavaScript comes up with the login flow. The page uses the Auth0 service to handle logins, and that service sends back an access token. The page sends that access token right back to the Auth0 service to get user privileges. If the logged in user isn’t an admin, the redirect happens. However, we already know that some real data gets loaded. It appears that the limitations to data is all implemented on the client side, and the backend only requires a valid access token for data requests. What would happen if the response from Auth0 were modified? There are a few approaches to accomplish this, but he opted to use Fiddler. Rewrite the response so the front-end believes you’re an admin, and you’re in.

This approach seems to gain admin access to all of the SmartTub admin controls, though [Eaton] didn’t try actually making changes to see if he had write access, too. This was enough to demonstrate the flaw, and making changes would be flirting with that dangerous line that separates research from computer crime. The real problem started when he tried to disclose the vulnerability. SmartTub didn’t have a security contact, but an email to their support email address did elicit a reply asking for details. And after details were supplied, complete radio silence. Exasperated, he finally turned to Auth0, asking them to intervene. Their solution was to pull the plug on one of the two URL endpoints. Finally, after six months of trying to inform Jacuzzi and SmartTub of their severe security issues, both admin portals were secured.

Continue reading “This Week In Security: IoT In The Hot Tub, App Double Fail, And FreeBSD BadBeacon”

Easy Network Config For IoT Devices With RGBeacon

When you’re hooking up hardware to a network, it can sometimes be a pain to figure out what IP address the device has ended up with. [Bas Pijls] often saw this problem occurring in the classroom, and set about creating a simple method for small devices to communicate their IP address and other data with a minimum of fuss.

[Bas] specifically wanted a way to do this without adding a display to the hardware, as this would add a lot of complexity and expense to simple IoT devices. Instead, RGBeacon was created, wherin a microcontroller flashes out network information with the aid of a single RGB WS2812B LED.

In fact, all three colors of the RGB LED are used to send information to a computer via a webcam. The red channel flashes out a clock signal, the green channel represents the beginning of a byte, and the blue channel flashes to indicate bits that are high. With a little signal processing, a computer running a Javascript app in a web browser can receive information from a microcontroller flashing its LEDs via a webcam.

It’s a neat hack that should make setting up devices in [Bas]’s classes much easier. It needn’t be limited to network info, either; the code could be repurposed to let a microcontroller flash out other messages, too. It’s not dissimilar from the old Timex Datalink watches which used monitor flashes to communicate!

APPLE2IDIOT Expansion Card Lets Your Apple II (Sort Of) Access The Internet

[Nathanial Hendler]’s Apple2Idiot expansion card for the Apple II family of computers is a nifty mix of modern and vintage, and provides a clever means of allowing the host computer to (indirectly) access the internet over WiFi while keeping things simple from the host computer’s perspective.

The PCB has plenty of space on which to silkscreen reference data. Click to enlarge.

It does this by embedding an ESP32 module and a dual-port RAM chip onto an expansion card. The Apple2Idiot, when installed into a host machine, presents as a memory location which the host machine can access. The ESP32 then takes care of all the WiFi communications and tasks requiring internet access, and the host computer directs these tasks (and reads their output) via PEEK and POKE commands.

This means that there are two pieces of software for any given task: one running on the ESP32 doing the actual work, and one running on the Apple II that communicates with the ESP32 on the card by reading and writing to memory. It’s a simple system, and one that [Nathanial] thinks works quite well for specific tasks.

Example programs include things like scanning and selecting a WiFi network, fetching weather data, and sending a message to Slack. Making new applications does mean having to write software on two ends, but the simplicity of the system also means flexibility, because anything the ESP32 does can have its complexity abstracted away by the time its data is presented to the host machine. Not that the Apple II is incapable of dealing with the modern internet more directly; we’ve seen a basic Apple II web server written in BASIC.