This Week In Security: Linux VMs, Real AI CVEs, And Backscatter TOR DoS

November 8, 2024 by Jonathan Bennett 4 Comments

Steve Ballmer famously called Linux “viral”, with some not-entirely coherent complaints about the OS. In a hilarious instance of life imitating art, Windows machines are now getting attacked through malicious Linux VM images distributed through phishing emails.

This approach seems to be intended to fool any anti-malware software that may be running. The VM includes the chisel tool, described as “a fast TCP/UDP tunnel, transported over HTTP, secured via SSH”. Now that’s an interesting protocol stack. It’s an obvious advantage for an attacker to have a Linux VM right on a target network. As this sort of virtualization does require hardware virtualization, it might be worth disabling the virtualization extensions in BIOS if they aren’t needed on a particular machine.

AI Finds Real CVE

We’ve talked about some rather unfortunate use of AI, where aspiring security researchers asked an LLM to find vulnerabilities in a project like curl, and then completely wasted a maintainer’s time on those bogus reports. We happened to interview Daniel Stenberg on FLOSS Weekly this week, and after he recounted this story, we mused that there might be a real opportunity to use LLMs to find vulnerabilities, when used as a way to direct fuzzing, and when combined with a good test suite.

And now, we have Google Project Zero bringing news of their Big Sleep LLM project finding a real-world vulnerability in SQLite. This tool was previously called Project Naptime, and while it’s not strictly a fuzzer, it does share some similarities. The main one being that both tools take their educated guesses and run that data through the real program code, to positively verify that there is a problem. With this proof of concept demonstrated, it’s sure to be replicated. It seems inevitable that someone will next try to get an LLM to not only find the vulnerability, but also find an appropriate fix. Continue reading “This Week In Security: Linux VMs, Real AI CVEs, And Backscatter TOR DoS” →

This Week In Security: One-click, UPnP, Mainframes, And Exploring The Fog

September 9, 2022 by Jonathan Bennett 8 Comments

A couple weeks ago we talked about in-app browsers, and the potential privacy issues when opening content in them. This week Microsoft reveals the other side of that security coin — JavaScript on a visited website may be able to interact with the JS embedded in the app browser. The vulnerability chain starts with a link handler published to Android, where any https://m.tiktok[.]com/redirect links automatically open in the TikTok app. The problem here is that this does trigger a redirect, and app-internal deeplinks aren’t filtered out. One of these internal schemes has the effect of loading an arbitrary page in the app webview, and while there is a filter that should prevent loading untrusted hosts, it can be bypassed with a pair of arguments included in the URI call.

Once an arbitrary page is loaded, the biggest problem shows up. The JavaScript that runs in the app browser exposes 70+ methods to JS running on the page. If this is untrusted code, it gives away the figurative keys to the kingdom, as an auth token can be accessed for the current user. Account modification, private video access, and video upload are all accessible. Thankfully the problem was fixed back in March, less than a month after private disclosure. Still, a one-click account hijack is nothing to sneeze at. Thankfully this one didn’t escape from the lab before it was fixed.

UPnP Strikes Again

It’s not an exaggeration to say that Universal Plug and Play (UPnP) may have been the most dangerous feature to be included in routers with the possible exception of open-by-default WiFi. QNAP has issued yet another advisory of ransomware targeting their devices, and once again UPnP is the culprit. Photo Station is the vulnerable app, and it has to be exposed to the internet to get pwned. And what does UPnP do? Exposes apps to the internet without user interaction. And QNAP, in their efforts to make their NAS products more usable, included UPnP support, maybe by default on some models. If you have a QNAP device (or even if you don’t), make sure UPnP is disabled on your router, turn off all port forwarding unless you’re absolutely sure you know what you’re doing, and use Wireguard for remote access. Continue reading “This Week In Security: One-click, UPnP, Mainframes, And Exploring The Fog” →

Linux For The Paranoid Does The Work For You

December 22, 2021 by Al Williams 42 Comments

We all know that our activity on the Internet is not that hard to track. It just annoys some people more than others. If you are really hardcore, you’ll learn all the ins and outs of networking to help cover your tracks, but what if you don’t want to invest that kind of time? Maybe, as [TechRepublic] suggests, try Kodachi Linux.

You could, of course, start with your own live image. Then when you boot, you could take the following steps:

Randomize your MAC Address
Establish a TOR connection through a VPN
Route all internet traffic through TOR and use DNS encryption
Set up a scheduled task to scramble your MAC address periodically

But that’s what Kodachi does without any real effort on your part.

The distribution is based on Ubuntu, so all the familiar tools are there. There are also a few security and privacy tools included like KeePass, Tox, OnionShare, i2p, and more. The desktop shows a summary of secure network information

Do you need Kodachi? Probably not, if you are a Linux guru. Plus, most people aren’t doing anything that’s that interesting. But if you want to protect your privacy or you are up to something, give Kodachi a try. Then again, if you are that paranoid, maybe that’s just what THEY want you to do. Make your own decisions. You can also check out the video review from [eBuzz Central] below.

Looking for more conventional Linux? Why not Rocky Linux? If you just want a VPN, you can always just use ssh.

Continue reading “Linux For The Paranoid Does The Work For You” →

Free P2P VPN

October 18, 2020 by Al Williams 34 Comments

People use a VPN — virtual private network — for a lot of reasons. However, for many people it is synonymous with hiding your network traffic, one thing that VPN can do. FreePN is a relatively new open source project that aims to build a free peer-to-peer VPN network. Like TOR, it is decentralized.

Right now, you can download for Ubuntu and Gentoo. There is a way to ask for early access for Debian, Fedora, and Arch. Windows, iOS, MacOS, and Android versions are promised for the future.

Continue reading “Free P2P VPN” →

This Week In Security: AD Has Fallen, Two Factor Flaws, And Hacking Politicians

September 18, 2020 by Jonathan Bennett 19 Comments

The big news this week is the huge flaw in Microsoft’s Active Directory, CVE-2020-1472 (whitepaper). Netlogon is a part of the Windows domain scheme, and is used to authenticate users without actually sending passwords over the network. Modern versions of Windows use AES-CFB8 as the cryptographic engine that powers Netlogon authentication. This peculiar mode of AES takes an initialization vector (IV) along with the key and plaintext. The weakness here is that the Microsoft implementation sets the IV to all zeros.

It’s worth taking a moment to cover why IVs exist, and why they are important. The basic AES encryption process has two inputs: a 128 bit (16 byte) plaintext, and a 128, 192, or 256 bit key. The same plaintext and key will result in the same ciphertext output every time. Encrypting more that 128 bits of data with this naive approach will quickly reveal a problem — It’s possible to find patterns in the output. Even worse, a clever examination of the patterns could build a decoding book. Those 16 byte patterns that occur most often would be guessed first. It would be like a giant crossword puzzle, trying to fill in the gaps.

This problem predates AES by many years, and thankfully a good solution has been around for a long time, too. Cipher Block Chaining (CBC) takes the ciphertext output of each block and mixes it (XOR) with the plaintext input of the next block before encrypting. This technique ensures the output blocks don’t correlate even when the plaintext is the same. The downside is that if one block is lost, ~~the entire rest of the data cannot be decrypted~~ Update: [dondarioyucatade] pointed out in the comments that it’s just the next block that is lost, not the entire stream. You may ask, what is mixed with the plaintext for the first block? There is no previous block to pull from, so what data is used to initialize the process? Yes, the name gives it away. This is an initialization vector: data used to build the initial state of a crypto scheme. Generally speaking, an IV is not secret, but it should be randomized. In the case of CBC, a non-random IV value like all zeros doesn’t entirely break the encryption scheme, but could lead to weaknesses. Continue reading “This Week In Security: AD Has Fallen, Two Factor Flaws, And Hacking Politicians” →

This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes

August 21, 2020 by Jonathan Bennett 4 Comments

One of the fun things about vulnerability research is that there are so many places for bugs to hide. Modern devices have multiple processors, bits of radio hardware, and millions of lines of code. When [Veronica Kovah] of Dark Mentor LLC decided to start vulnerability research on the Bluetooth Low Energy protocol, she opted to target the link layer itself, rather than the code stack running as part of the main OS. What’s interesting is that the link layer has to process data before any authentication is performed, so if a vulnerability is found here, it’s guaranteed to be pre-authentication. Also of interest, many different devices are likely to share the same BLE chipset, meaning these vulnerabilities will show up on many different devices. [Veronica] shares some great info on how to get started, as well as the details on the vulnerabilities she found, in the PDF whitepaper. (Just a quick note, this link isn’t to the raw PDF, but pulls up a GitHub PDF viewer.) There is also a video presentation of the findings, if that’s more your speed.

The first vuln we’ll look at is CVE-2019-15948, which affects a handful of Texas Instruments BT/BLE chips. The problem is in how BLE advertisement packets are handled. An advertisement packet should always contain a data length of at least six bytes, which is reserved for the sending device address. Part of the packet parsing process is to subtract six from the packet length and do a memcpy using that value as the length. A malicious packet can have a length of less than six, and the result is that the copy length integer underflows, becoming a large value, and overwriting the current stack. To actually turn this into an exploit, a pair of data packets are sent repeatedly, to put malicious code in the place where program execution will jump to.

The second vulnerability of note, CVE-2020-15531 targets a Silicon Labs BLE chip, and uses malformed extended advertisement packets to trigger a buffer overflow. Specifically, the sent message is longer than the specification says it should be. Rather than drop this malformed message, the chip’s firmware processes it, which triggers a buffer overflow. Going a step further, this chip has non-volatile firmware, and it’s possible to modify that firmware permanently. [Veronica] points out that even embedded chips like these should have some sort of secure boot implementation, to prevent these sort of persistent attacks.
Continue reading “This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes” →

Russian Hackers Domain Fronting

March 28, 2017 by Elliot Williams 51 Comments

FireEye just put out a report on catching the Russian hacker group “Advanced Persistent Threat 29” (APT29, for lack of a better code name) using the meek plugin for TOR to hide their traffic. If you’re using meek with meek-reflect.appspot.com, you’ll find it’s been shut down. If all of this is gibberish to you, read on for a breakdown.

meek is a clever piece of software. Imagine that you wanted to communicate with the Tor anonymizing network, but that you didn’t want anyone to know that you were. Maybe you live in a country where a firewall prevents you from accessing the full Web, and blocks Tor entry nodes as part of their Great Firewall. You’d want to send traffic somewhere innocuous first, and then bounce it over to Tor, in order to communicate freely.

That’s what meek does, but it goes one step further. The reflector server is hosted using the same content-delivery network (CDN) as a popular service, say Google’s search engine. The CDN has an IP address, like every other computer on the Internet, but it delivers content for any of the various services it hosts. Traffic to the CDN, encrypted with TLS, looks the same whether it’s going to the meek reflector or to Google, so nobody on the outside can tell whether it is a search query or packets destined for Tor. Inside the CDN, it’s unencrypted and passed along to the reflector.

Anyway, meek was invented to help bring the uncensored Internet to people who live in oppressive regimes, and now cybersecurity researchers have observed it being used by Russian state hackers to hide their tracks. Sigh. Technology doesn’t know which side it’s on — the same backdoor that the FBI wants to plant in all our communications can be used by the mafia just as easily. Plugins that are meant to bring people freedom of speech can just as easily be used to hide the actions of nation-state hackers.

What a strange world we live in.