Security Hacks

1497 Articles

This Week In Security: Linux WiFi, Fortinet, Text4Shell, And Predictable GUIDs

October 21, 2022 by 18 Comments

Up first this week is a quintet of vulnerabilities in the Linux kernel’s wireless code. It started with [Soenke Huster] from TU Darmstadt, who found a buffer overwrite in mac80211 code. The private disclosure to SUSE kernel engineers led to a security once-over of this wireless framework in the kernel, and some other nasty bugs were found. A couple result in Denial-of-Service (DOS), but CVE-2022-41674, CVE-2022-42719, and CVE-2022-42720 are Remote Code Execution vulnerabilities. The unfortunate bit is that these vulnerabilities are triggered on processing beacon frames — the wireless packets that announce the presence of a wireless network. A machine doesn’t have to be connected or trying to connect to a network, but simply scanning for networks can lead to compromise.

The flaws were announced on the 13th, and were officially fixed in the mainline kernel on the 15th. Many distros shipped updates on the 14th, so the turnaround was quite quick on this one. The flaws were all memory-management problems, which has prompted a few calls for the newly-merged Rust framework to get some real-world use sooner rather than later.

Fortinet

Much of Fortinet’s lineup, most notable their Fortigate firewalls, has a pre-auth authentication bypass on the administrative HTTP/S interface. Or plainly, if you can get to the login page, you can break in without a password. That’s bad, but at this point, you *really* shouldn’t have any administrative interfaces world-accessible on any hardware. Updated firmware is available.

More than just a couple days have passed, so we have some idea of the root problem and how it was fixed. It’s a simple one — the Forwarded HTTP headers on an incoming request are unintentionally trusted. So just send a request with Forwarded:for and Forwarded:by set to 127.0.0.1, and it falls through into code logic intended for internal API calls. Add a trusted SSH key, and pop, you’re in. Whoops. Continue reading “This Week In Security: Linux WiFi, Fortinet, Text4Shell, And Predictable GUIDs” →

Front Door Keys Hidden In Plain Sight

October 18, 2022 by 27 Comments

If there’s one thing about managing a bunch of keys, whether they’re for RSA, SSH, or a car, it’s that large amounts of them can be a hassle. In fact, anything that makes life even a little bit simpler is a concept we often see projects built on to of, and keys are no different. This project, for example, eliminates the need to consciously carry a house key around by hiding it in a piece of jewelry.

This project sprang from [Maxime]’s previous project, which allowed the front door to be unlocked with a smartphone or tablet. This isn’t much better than carrying a key, since the valuable piece of electronics must be toted along in place of one. Instead, this build eschews the smartphone for a ring which can be worn and used to unlock the door with the wave of a hand. The ring contains an RFID which is read by an antenna that’s monitored by a Wemos D1 Mini. When it sees the ring, a set of servos unlocks the door.

The entire device is mounted on the front of the door about where a peephole would normally be, with the mechanical actuators on the inside. It seems just as secure (if not more so) than carrying around a metal key, and we also appreciate the aesthetic of circuit boards shown off in this way, rather than hidden inside an enclosure. It’s an interesting build that reminds us of some other unique ways of unlocking a door.

Continue reading “Front Door Keys Hidden In Plain Sight” →

This Week In Security: Npm Timing Leak, Siemens Universal Key, And PHP In PNG

October 14, 2022 by 12 Comments

First up is some clever wizardry from the [Aqua Nautilus] research team, who discovered a timing attack that leaks information about private npm packages. The setup is this, npm hosts both public and private node.js packages. The public ones are available to everyone, but the private packages are “scoped”, meaning they live within a private namespace, “@owner/packagename” and are inaccessible to the general public. Trying to access the package results in an HTTP 404 error — the same error as trying to pull a package that doesn’t exist.


The clever bit is to keep trying, and really pay attention to the responses. Use npm’s API to request info on your target package, five times in a row. If the package name isn’t in use, all five requests will take the expected amount of time. That request lands at the service’s backend, a lookup is performed, and you get the response. On the flipside if your target package does exist, but is privately scoped, the first request returns with the expected delay, and the other four requests return immediately. It appears that npm has front-end that can cache a 404 response for a private package. That response time discrepancy means you can map out the private package names used by a given organization in their private scope.

Now this is all very interesting, but it turns into a plausible attack when combined with typosquatting and dependency confusion issues. Those attacks are two approaches to the same goal, get a node.js deployment to run a malicious package instead of the legitimate one the developer intended. One depends on typos, but dependency confusion just relies on a developer not explicitly defining the scope of a package.

Continue reading “This Week In Security: Npm Timing Leak, Siemens Universal Key, And PHP In PNG” →

Hacking Google With Plasma

October 10, 2022 by 17 Comments

Google recently made some videos to highlight cybersecurity. The video below is episode three, and it tells an interesting story about the first crash test dummy. However, the really interesting part is the story about a USB plasma globe built to hack into computers. One of the people who built that globe tells the story of its insides in a recent blog post that has a bit more technical detail.

The attack in question was in 2012, when people were starting to get the idea that inserting random USB drives into their computers wasn’t a great idea. However, what harm could there be in a cute little plasma globe that just draws power from the port?

Continue reading “Hacking Google With Plasma” →

This Week In Security: PHP Attack Defused, Scoreboard Manipulation, And Tillitis

October 7, 2022 by 1 Comment

If you use PHP, you likely use the Composer tool for managing dependencies, at least indirectly. And the good folks at SonarSource found a nasty, potential supply chain attack in this tool, when used in the Packagist repository. The problem is the support for arbitrary README filenames. When a package update shows up on Packagist, that service uses a Version Control Service (VCS) like Git or Mercurial to pull the specified readme location. That pull operation is subject to argument injection. Name your branch --help, and Git will happily run the help argument instead of doing the pull intended. In the case of Git commands, our intrepid researchers were unable to weaponize the issue to achieve code execution.

Composer also supports projects that use Mercurial as their VCS, and Mercurial has a --config option that has… interesting potential. It allows redefining a Mecurial command as a script snippet. So a project just has to contain a malicious payload.sh, and the readme set to --config=alias.cat=!hg cat -r : payload.sh|sh;,txt. For those keeping track at home, the vulnerability is that this cursed string of ugly is accepted by Composer as a valid filename. This uses the --config trick to redefine cat as a bit of script that executes the payload. It ends in .txt because that is a requirement of Composer.

So let’s talk about what this little hack could have been used for, or maybe still used for on an unpatched, private install of Packagist. This is an unattended attack that jumps straight to remote script execution — on an official package repository. If discovered and used for evil, this would have been a massive supply chain attack against PHP deployments. Instead, thanks to SonarSource, it was discovered and disclosed privately back in April. The official Packagist repo at packagist.org was fixed the day after disclosure, and a CVE and updated packages went out six days later. Great work all around.
Continue reading “This Week In Security: PHP Attack Defused, Scoreboard Manipulation, And Tillitis” →

This Week In Security: Exchange 0-day, Doppelgangers, And Python Gets Bit In The TAR

September 30, 2022 by 13 Comments

According to researchers at GTSC, there’s an unpatched 0-day being used in-the-wild to exploit fully patched Microsoft Exchange servers. When they found one compromised server, they made the report to Microsoft through ZDI, but upon finding multiple Exchange servers compromised, they’re sounding the alarm for everyone. It looks like it’s an attack similar to ProxyShell, in that it uses the auto-discover endpoint as a starting point. They suspect it’s a Chinese group that’s using the exploit, based on some of the indicators found in the webshell that gets installed.

There is a temporary mitigation, adding a URL-based request block on the string .*autodiscover\.json.*\@.*Powershell.. The exact details are available in the post. If you’re running Exchange with IIS, this should probably get added to your system right now. Next, use either the automated tool, or run the PowerShell one-liner to detect compromise: Get-ChildItem -Recurse -Path -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200. This one has the potential to be another really nasty problem, and may be wormable. As of the time of writing, this is an outstanding, unpatched problem in Microsoft Exchange. Come back and finish the rest of this article after you’ve safed up your systems.

Continue reading “This Week In Security: Exchange 0-day, Doppelgangers, And Python Gets Bit In The TAR” →

So How Do You Make A Self-Destructing Flash Drive?

September 26, 2022 by 57 Comments

A self-destructing storage device that vaporizes its contents at the first sign of trouble would be an invaluable tool for many people, but good luck getting your hands on such a thing if you don’t work for a three-letter agency. Or at least, that’s what we would have said before [Walker] got on the case. He’s working on an open source self-destructing USB flash drive for journalists, security researchers, whistleblowers, or anyone else who really values their privacy.

When we previously covered this project in July, [Walker] had only planned to make the flash drive hide its contents unless you knew to wet your fingers before plugging it in. We admit it sounds a little weird, but as far as clandestine methods of activating something goes, it’s pretty clever. But based on the feedback he received, he decided to go all-in and make the USB drive literally trash itself should it be accessed by somebody who doesn’t know the secret.

An elegant weapon for a more civilized age.

But how exactly do you pull that off? Sure we’d love to see a small thermite charge or vial of acid packed in there, but obviously that’s not very practical. It needs to be safe to carry around, and just as importantly, unlikely to get you into even more trouble with whoever is searching through your belongings. To that end, [Walker] thinks he’s come up with an elegant solution.

The datasheet for his flash memory chip says the maximum voltage it can handle before releasing the Magic Smoke is a meager 4.6 V. So he figures running a voltage doubler on the nominal 5 V coming from a USB port should disable the chip nicely with a minimum of external drama. Will it be enough to prevent the data from being recovered forensically? We don’t know, but we’re eager to find out.

In the write-up, [Walker] takes readers through the circuit designs he’s come up so far, and shows off the source code that will run on the ATtiny25 to determine when it’s time to toast the flash. He says by the next post he should have the entire flash drive built and documented, so stay tuned.