This Week In Security: Mastodon, Fake Software Company, And ShuffleCake

November 18, 2022 by Jonathan Bennett 15 Comments

Due to Twitter’s new policy of testing new features on production, the interest in Mastodon as a potential replacement has skyrocketed. And what’s not to love? You can host it yourself, it’s part of the Fediverse, and you can even run one of the experimental forks for more features. But there’s also the danger of putting a service on the internet, as [Gareth Heyes] illustrates by stealing passwords from, ironically, the infosec.exchange instance.
Continue reading “This Week In Security: Mastodon, Fake Software Company, And ShuffleCake” →

This Week In Security: Microsoft Patches, Typosquatting Continues, And Code Signing For All

November 11, 2022 by Jonathan Bennett 3 Comments

The pair of Outlook vulnerabilities we’ve been tracking have finally been patched, along with another handful of fixes this Patch Tuesday, a total of six being 0-day exploits. The third vulnerability was also a 0-day, discovered by the Google Threat Analysis Group. This one resulted in arbitrary code execution when a Windows client connected to a malicious server.

A pair of escalation of privilege flaws were fixed, one being yet another print spooler issue, and the other part of a key handling service. The final zero-day fixed was a mark-of-the-web bypass, that being the tag that gets added to file metadata to indicate it’s a download from the internet. If you deliver malware inside an ISO or marked read-only in a zip file, it doesn’t show the warning when executing.

Will Typosquat For Bitcoin

A trend that doesn’t show signs of slowing down is Typosquatting, the simple malware distribution strategy of uploading tainted packages using misspelled variations of legitimate package names. The latest such scheme, discovered by researchers at Phylum, delivered a crypto-stealer in Python packages. These packages were hosted on PyPi, under names like baeutifulsoup4 and cryptograpyh. The packages install a JavaScript file that runs in the background of the browser, and monitors for a cryptocurrency address on the clipboard. When detected, the intended address is swapped for an attacker-controlled address. Continue reading “This Week In Security: Microsoft Patches, Typosquatting Continues, And Code Signing For All” →

This Week In Security: OpenSSL Fizzle, Java XML, And Nothing As It Seems

November 4, 2022 by Jonathan Bennett 3 Comments

The security world held our collective breaths early this week for the big OpenSSL vulnerability announcement. Turns out it’s two separate issues, both related to punycode handling, and they’ve been downgraded to high severity instead of critical. Punycode, by the way, is the system for using non-ASCII Unicode characters in domain names. The first vulnerability, CVE-2022-3602, is a buffer overflow that writes four arbitrary bytes to the stack. Notably, the vulnerable code is only run after a certificate’s chain is verified. A malicious certificate would need to be either properly signed by a Certificate Authority, or manually trusted without a valid signature.

A couple sources have worked out the details of this vulnerability. It’s an off-by-one error in a loop, where the buffer length is checked earlier in the loop than the length variable is incremented. Because of the logic slip, the loop can potentially run one too many times. That loop processes the Unicode characters, encoded at the end of the punycode string, and injects them in the proper place, sliding the rest of the string over a byte in memory as a result. If the total output length is 513 characters, that’s a single character overflow. A Unicode character takes up four bytes, so there’s your four-byte overflow. Continue reading “This Week In Security: OpenSSL Fizzle, Java XML, And Nothing As It Seems” →

This Week In Security: IOS, OpenSSL, And SQLite

October 28, 2022 by Jonathan Bennett 13 Comments

Earlier this week, a new release of iOS rolled out, fixing a handful of security issues. One in particular noted it “may have been actively exploited”, and was reported anonymously. This usually means that a vulnerability was discovered in the wild, being used as part of an active campaign. The anonymous credit is interesting, too. An educated guess says that this was a rather targeted attack, and the security company that found it doesn’t want to give away too much information.

Of other interest is the GPU-related fix, credited to [Asahi Lina], the VTuber doing work on porting Linux to the Apple M1/M2 platform, and particularly focusing on GPU drivers. She’s an interesting case, and doing some very impressive work. There does remain the unanswered question of how the Linux Kernel will deal with a pull request coming from a pseudonym. Regardless, get your iOS devices updated.

Continue reading “This Week In Security: IOS, OpenSSL, And SQLite” →

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” →

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: Malwarebytes Goes Nuts, Uber

September 23, 2022 by Jonathan Bennett 12 Comments

I got a rude awakening Wednesday morning this week. HaD writers don’t necessarily keep normal hours — don’t judge. A local client called, complaining that Google Maps was blocking on one of their computers, and the browser stated that it was a malicious site. Well that got my attention. Standard incident response: “Turn off the affected computers, I’m on my way.” Turns out, it was Malwarebytes that was complaining and blocking Google Maps, as well as multiple other Google domains. That particular machine happened to have a fresh install of the program, and was still in the trial period of Malwarebytes premium, which includes the malicious IP and domain blocking feature.

Oof, this could be bad. The first possibility that came to mind was a DNS hijack. The desktop’s DNS was set to the router, and the router’s DNS was set to the ISP’s. Maybe the ISP had their DNS servers compromised? Out came the cell phone, disconnected from the WiFi, for DNS lookups on some Google domains. Because Google operates at such a massive scale, they have multiple IPs serving each domain, but since the two different results were coming from the same subnet, the suspicious DNS server was likely OK. A whois on the blocked IP also confirmed that it was a Google-owned address. We were running out of explanations, and as a certain fictional detective was known for saying, “whatever remains, however improbable, must be the truth.” And, yes, Malwarebytes did indeed accidentally add Google to its bad list. The upside was that my customer wasn’t compromised. The downside? I had to answer a phone call before my first cup of coffee. Blegh.

Continue reading “This Week In Security: Malwarebytes Goes Nuts, Uber” →