“Reversing Shorts” Demystify Phone Security

October 24, 2022 by Elliot Williams 3 Comments

Ever wonder what makes a cellphone’s operating system secure, or what that app you just installed is saying about you behind your back? In a brand new video series, [Jiska] gives us a peek into different topics in smartphone software reverse engineering.

For instance, her latest video, embedded below takes us through some steps to poke at Apple’s RTKit OS, which is the realtime OS that runs inside most of their peripheral devices, including AirPods, but also on their bigger devices too. We don’t know much about RTKit OS, but [Jiska]’s trick in this video is to get a foothold by looking through two different RTKit OS versions and noting which symbols are common — these are probably OS function names. Now you’ve got something to look for.

Each of the videos is short, to the point, and contains nice tips for perhaps the intermediate-to-advanced reverser who is looking to get into phones. Heck, even if you’re not, her demonstrations of the Frida dynamic tracing tool are worth your time.

And if you want a longer introduction into the internals of cellphones, we heartily recommend her talk, “All Wireless Stacks Are Broken“.

Continue reading ““Reversing Shorts” Demystify Phone Security” →

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

October 21, 2022 by Jonathan Bennett 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 Bryan Cockfield 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 Jonathan Bennett 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 Al Williams 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 Jonathan Bennett 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 Jonathan Bennett 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” →