We start this week with a good write-up by [Eugene Lim] on getting started on vulnerability hunting, and news of a problem in OpenOffice’s handling of DBase files. [Lim] decided to concentrate on a file format, and picked the venerable dbase format, .dbf. This database format was eventually used all over the place, and is still supported in Microsoft Office, Libreoffice, and OpenOffice. He put together a fuzzing approach using Peach Fuzzer, and found a handful of possible vulnerabilities in the file format, by testing a very simple file viewer that supported the format. He managed to achieve code execution in dbfview, but that wasn’t enough.
Armed with a vulnerability in one application, [Lim] turned his attention to OpenOffice. He knew exactly what he was looking for, and found vulnerable code right away. A buffer is allocated based on the specified data type, but data is copied into this buffer with a different length, also specified in the dbase file. Simple buffer overflow. Turning this into an actual RCE exploit took a bit of doing, but is possible. The disclosure didn’t include a full PoC, but will likely be reverse engineered shortly.
Normally we’d wrap by telling you to go get the update, but OpenOffice doesn’t have a stable release with this fix in it. There is a release candidate that does contain the fix, but every stable install of OpenOffice in the world is currently vulnerable to this RCE. The vulnerability report was sent way back on May 4th, over 90 days before full disclosure. And what about LibreOffice, the fork of OpenOffice? Surely it is also vulnerable? Nope. LibreOffice fixed this in routine code maintenance back in 2014. The truth of the matter is that when the two projects forked, the programmers who really understood the codebase went to LibreOffice, and OpenOffice has had a severe programmer shortage ever since. I’ve said it before: Use LibreOffice, OpenOffice is known to be unsafe.
iOS Woes
Denis Tokarev, AKA [illusionofchaos], has had it with Apple’s bug bounty program, and disclosed a trio of unfixed iOS bugs, far after 90 days had expired. But first, a vulnerability that was fixed, in release 14.7. Prior to the fix, any app on the device could read the analytics logs unrestricted, a trove of information. This data leak was fixed quietly, with no disclosure or credit from Apple. [Denis] asked, and was told that he would be credited in a later release. Three further security releases have come and gone, and still no disclosure or credit.
Two additional vulns were reported in May, and the third in March of this year. Those are: a permission bypass allowing an app to read wifi information, an unintended method for an app to determine what other apps are installed, and a serious flaw allowing an app access to all sorts of things including a user’s authentication token. After six months sitting on the oldest issue, [Denis] gave Apple a 10 day final deadline, and when that passed, published them all.
The followup post would be interesting on its own, showing some techniques for sneaking malicious code through the App Store’s analysis process. If you expected cutting-edge, advance techniques, prepare to be disappointed. Apple’s analysis will catch NSClassFromString(["GKLocalPlayerInternal"]) as accessing an Apple-only API. The workaround, that really does avoid detection? NSClassFromString(["GKLoc","lPlayerInternal"].joined(separator: "a")) The rest of the post is not security related, but raises some valid points about other failings of the App Store.
Netgear’s Circle
A handful of Netgear routers ship with the Circle Parental Control Service, and while the actual web filtering is off by default, the update service runs automatically anyway. [Adam] discovered a pair of problems with this update process, starting with the use of HTTP for fetching updates. This allows an attacker to perform a man-in-the-middle attack on the check for updates, but the update process checks the update blobs for valid signatures. The second problem is that these Netgear routers use a busybox binary from 2007. Busybox is an all-in-one binary that provides the basic set of Unix tools for embedded devices. One such tool is tar, and in ’07 an important security feature was missing: absolute path blocking.
Remember how the Circle update process checks binaries for a valid signature before updating? Binaries aren’t the only thing that gets updated, there is also a database update, and that is distributed as a tarball and isn’t signed. Because of the insecure tar handling, a malicious database update can overwrite system startup scripts, AKA easy RCE. Patches are available, so check to see if your device is affected.
Outlook Autodiscover
Researchers at Guardicore have discovered a logic flaw in Outlook that turns an old vulnerability into a big problem. The old issue was disclosed in 2016, and boils down to an encryption downgrade attack. If a mail client trying to use Exchange autodiscovery were coerced to connect to an attacker-controlled server, the authorization method can be downgraded to a Base64 encoded username/password. At the time, Microsoft declined to issue any guidance or patches regarding this scenario.
What Guardicore discovered is a flaw in the auto discover URL domain-walking logic. When setting up a new email address, Outlook will attempt to locate an Autodiscover.xml file on the new address domain. So for an address like user@mail.example.com, the first location checked is https://Autodiscover.mail.example.com/Autodiscover/Autodiscover.xml. If the autodiscover file can’t be found at that domain, Outlook will traverse upwards, and check autodiscover.example.com. So far so good. The problem is that the logic doesn’t stop here, but will also check autodiscover.com, which is almost certainly not controlled by the mail provider. This problem exists for every Top Level Domain.
Guardicore researchers purchased 20 autodiscover.X domains, and waited for traffic. During a five day period, they collected almost 100,000 unique requests. Shockingly, these requests included the account credentials sent using Basic Authentication, AKA clear text. (OK, it’s Base64 encoded, but that’s an encoding, so it’s still cleartext.) It seems that they were performing an authorization downgrade attack by accident. The suggested solution for end users? Block the whole list of autodiscover.TLD domains at your DNS provider.
AirTag XSS
In somewhat humorous news, the new AirTag by Apple has a Cross-Site Scripting flaw. The owner of an AirTag can set a custom message and phone number to show to whoever finds the missing device. That phone number field is currently unvalidated, so you can put anything you want there, including code. It’s possible for the finder to scan the AirTag and get redirected to a malicious site as a result. Thankfully, this should be a fairly easy fix, and isn’t actually a hardware problem. Also of note, this is another 0-day, again the result of Apple’s less-than-stellar approach to dealing with researchers.
Oops
Remember back in May, when Apple Shortcuts went belly up for a while? It turns out it was a security researcher, [Frans Rosen], working on a vulnerability in Apple’s CloudKit service, a data storage framework. He discovered that there are multiple APIs supported, and they give slightly different results when accessing or manipulating. He tried a delete request on the default zone for shortcuts, and it worked. It shouldn’t have worked, but it did. And shortcuts were trashed worldwide for Apple users. I am possibly more amused by Apple’s response than I should be.
Thank you for the information. Please stop…
There were eventually three bugs found and fixed. In this case, [Frans] was impressed with the Apple security team. They did pay him bounties for all three problems, even though he deleted the entire world’s shortcuts while finding one of them.
Leftover Bytes
EFF is retiring HTTPS Everywhere because HTTPS is actually everywhere now. The extension will be in maintenance mode for 2022, and likely will be fully retired after that. Not only do many sites automatically redirect users to an HTTPS connection, this feature is also built in to the major browsers now, too.
Not unrelated, Let’s Encrypt is about to make a change to their certificate backing. The IdenTrust certificate is what allowed Let’s Encrypt to initially get off the ground, but enough time has passed, and enough devices now trust the Let’s Encrypt root cert, that the EdenTrust certificate is no longer needed. There is a list of some rather old hardware and software that will have problems as a result, go check it out at the link.
Trend Micro’s ServerProtect product has been updated to fix a 0-click RCE in their security product. While an insecure security product is nothing new, this one is particularly bad, with a CVSS of 9.8.
0 Commentaires