This Week In Security: Y2K22, Accidentally Blocking 911, And Bug Alert

January 7, 2022 by 45 Comments

If you had the misfortune of running a Microsoft Exchange server this past week, then you don’t need me to tell you about the Y2K22 problem. To catch rest of us up, when Exchange tried to download the first malware definitions update of 2022, the version number of the new definitions triggered a crash in the malware detection engine. The date is represented as the string 2201010001, where the first two digits represent the year. This string gets converted to a signed long integer, which maxes out at 2,147,483,647. The integer overflows, and the result is undefined behavior, crashing the engine. The server fails safe, not processing any messages without a working malware engine, which means that no e-mail gets through. Happy new year!
Continue reading “This Week In Security: Y2K22, Accidentally Blocking 911, And Bug Alert” →

British Licence Plate Camera Fooled By Clothing

October 21, 2021 by 43 Comments

It’s a story that has caused consternation and mirth in equal measure amongst Brits, that the owners of a car in Surrey received a fine for driving in a bus lane miles away in Bath, when in fact the camera had been confused by the text on a sweater worn by a pedestrian. It seems the word “knitter” had been interpreted by the reader as “KN19 TER”, which as Brits will tell you follows the standard format for modern UK licence plate.

It gives us all a chance to have a good old laugh at the expense of the UK traffic authorities, but it raises some worthwhile points about the fallacy of relying on automatic cameras to dish out fines without human intervention. Except for the very oldest of cars, the British number plate follows an extremely distinctive high-contrast format of large black letters on a reflective white or yellow background, and since 2001 they have all had to use the same slightly authoritarian-named MANDATORY typeface. They are hardly the most challenging prospect for a number plate recognition system, but even when it makes mistakes the fact that ambiguous results aren’t subjected to a human checking stage before a fine is sent out seems rather chilling.

It also raise the prospect of yet more number-plate-related mischief, aside from SQL injection jokes and adversarial fashion, we can only imagine the havoc that could be caused were a protest group to launch a denial of service attack with activists sporting fake MANDATORY licence plates.

Header image, based on the work of ZElsb, CC BY-SA 4.0.

This Week In Security: The Apache Fix Miss, Github (Malicious) Actions, And Shooting The Messenger

October 15, 2021 by 10 Comments

Apache 2.4.50 included a fix for CVE-2021-41773. It has since been discovered that this fix was incomplete, and this version is vulnerable to a permutation of the same vulnerability. 2.4.51 is now available, and should properly fix the vulnerability.

The original exploit used .%2e/ as the magic payload, which is using URL encoding to sneak the extra dot symbol through as part of the path. The new workaround uses .%%32%65/. This looks a bit weird, but makes sense when you decode it. URL encoding uses UTF-8, and so %32 decodes to 2, and %65 to e. Familiar? Yep, it’s just the original vulnerability with a second layer of URL encoding. This has the same requirements as the first iteration, cgi-bin has to be enabled for code execution, and require all denied has to be disabled in the configuration files. Continue reading “This Week In Security: The Apache Fix Miss, Github (Malicious) Actions, And Shooting The Messenger” →

This Week In Security: Ransomware Decryption, OpenSSL, And USBGadget Spoofing

September 3, 2021 by 8 Comments

We’ve covered a lot of ransomware here, but we haven’t spent a lot of time looking at the decryptor tools available to victims. When ransomware gangs give up, or change names, some of them release a decryption tool for victims who haven’t paid. It’s not really a good idea to run one of those decryptors, though. The publishers don’t have a great track record for taking care of your data, after all. When a decryptor does get released, and is verified to work, security researchers will reverse engineer the tool, and release a known-good decryption program.

The good folks at No More Ransom are leading the charge, building such tools, and hosting a collection of them. They also offer Crypto Sheriff, a tool to identify which ransomware strain got your files. Upload a couple encrypted files, and it will inform you exactly what you’re dealing with, and whether there is a decryptor available. The site is a cooperation between the Dutch police, Interpol, Kaspersky, and McAfee. It may surprise you to know that they recommend reporting every ransomware case to the authorities. I can confirm that at the very least, the FBI in the US are very interested in keeping track of the various ransomware attacks — I’ve fielded a surprise call from an agent following up on an infection.

OpenSSL

The OpenSSL project has fixed a pair of vulnerabilities, CVE-2021-3711 and CVE-2021-3712 with release 1.1.11l. The first is a possible buffer overflow caused by a naive length calculation function. A “fixed” length header is actually dynamic, so a carefully crafted plaintext can overflow the allocated buffer. Continue reading “This Week In Security: Ransomware Decryption, OpenSSL, And USBGadget Spoofing” →

This Week In Security: John Deere, ProxyLogin Detailed, And Pneumatic Tubes

August 13, 2021 by 14 Comments

We’ve covered the right-to-repair saga, and one of the companies that have become rather notorious is John Deere. The other side to the poorly managed interconnected mess is security issues. There’s a certain irony to how this story started: Somebody noticed that John Deere equipment didn’t have any CVEs at all. A normal person might think that this must mean their products are super secure, but a security researcher knows that something more interesting is afoot. Our old friends [Sick Codes], [John Jackson], and a host of others saw this as a sure sign that there were plenty of vulnerabilities to be found, and it seems they were correct.

Remote Access and Code from 2014…

Vulnerabilities included a handful of cross-site scripting attacks, an authentication bypass via request smuggling, misconfigured security, SQL injections, RCEs and more. Put together, these vulnerabilities allowed for full control of the John Deere system, including the ability to manipulate all the equipment connected to the system.

During the Defcon presentation, linked below, [Sick Codes] recalled the moment when they realized they were working on an important problem. Rather than complain about not getting paid for the vulnerabilities found, a contributor simply noted that he valued having food to eat. A coordinated attack on JD equipment could cause big problems for a bunch of farms across a country.

They ended up contacting CISA, due to a lack of serious response from the vendors. CISA took the threat seriously, and the problems starting getting fixed. This isn’t a problem limited to one company. Case had similar issues that have also been fixed, and it was implied that other vendors have similar problems that are still in the process of being addressed. Continue reading “This Week In Security: John Deere, ProxyLogin Detailed, And Pneumatic Tubes” →

This Week In Security: Discord, Chromium, And WordPress Forced Updates

October 30, 2020 by 42 Comments

[Masato Kinugawa] found a series of bugs that, when strung together, allowed remote code execution in the Discord desktop app. Discord’s desktop application is an Electron powered app, meaning it’s a web page rendered on a bundled light-weight browser. Building your desktop apps on JavaScript certainly makes life easier for developers, but it also means that you inherit all the problems from running a browser and JS. There’s a joke in there about finally achieving full-stack JavaScript.

The big security problem with Electron is that a simple Cross Site Scripting (XSS) bug is suddenly running in the context of the desktop, instead of the browser. Yes, there is a sandboxing option, but that has to be manually enabled.

And that brings us to the first bug. Neither the sandbox nor the contextIsolation options were set, and so both defaulted to false. What does this setting allow an attacker to do? Because the front-end and back-end JavaScript runs in the same context, it’s possible for an XSS attack to override JS functions. If those functions are then called by the back-end, they have full access to Node.js functions, including exec(), at which point the escape is complete.

Now that we know how to escape Electron’s web browser, what can we use for an XSS attack? The answer is automatic iframe embeds. For an example, just take a look at the exploit demo below. On the back-end, all I have to do is paste in the YouTube link, and the WordPress editor does its magic, automatically embedding the video in an iframe. Discord does the same thing for a handful of different services, one being Sketchfab.

This brings us to vulnerability #2. Sketchfab embeds have an XSS vulnerability. A specially crafted sketchfab file can run some JS whenever a user interacts with the embedded player, which can be shoehorned into discord. We’re almost there, but there is still a problem remaining. This code is running in the context of an iframe, not the primary thread, so we still can’t override functions for a full escape. To actually get a full RCE, we need to trigger a navigation to a malicious URL in the primary pageview, and not just the iframe. There’s already code to prevent an iframe from redirecting the top page, so this RCE is a bust, right?

Enter bug #3. If the top page and the iframe are on different domains, the code preventing navigation never fires. In this case, JavaScript running in an iframe can redirect the top page to a malicious site, which can then override core JS functions, leading to a full escape to RCE.

It’s a very clever chaining of vulnerabilities, from the Discord app, to an XSS in Sketchfab, to a bug within Electron itself. While this particular example required interacting with the embedded iframe, it’s quite possible that another vulnerable service has an XSS bug that doesn’t require interaction. In any case, if you use Discord on the desktop, make sure the app is up to date. And then, enjoy the demo of the attack, embedded below.

Continue reading “This Week In Security: Discord, Chromium, And WordPress Forced Updates” →

This Week In Security: XCode Infections, Freepik, And Crypto Fails

August 28, 2020 by 8 Comments

There is a scenario that keep security gurus up at night: Malware that can detect software compilation and insert itself into the resulting binary. A new Mac malware, XCSSET (PDF), does just that, running whenever Xcode is used to build an application. Not only is there the danger of compiled apps being malicious, the malware also collects data from the developer’s machine. It seems that the malware spreads through infected Xcode projects.

WordPress Plugins

WordPress has a complicated security track record. The core project has had very few serious vulnerabilities over the years. On the other hand, WordPress sites are routinely compromised. How? Generally through vulnerable plugins. Case in point? Advanced Access Manager. It’s a third party WordPress plugin with an estimate 100,000 installations. The problem is that this plugin requires user levels, a deprecated and removed WordPress feature. The missing feature had some unexpected results, like allowing any user to request administrator privileges.

The issue has been fixed in 6.6.2 of the plugin, so if you happen to run the Advanced Access Manager plugin, make sure to get it updated. Beyond that, maybe it’s time to do an audit on your WordPress site. Uninstall unused plugins, and make sure the rest are up to date, along with the WordPress installation itself. Continue reading “This Week In Security: XCode Infections, Freepik, And Crypto Fails” →