This Week In Security: Updates, Leaks, Hacking Old Hardware, And Making New – Hackaday

First off, Apple has issued an update for some very old devices. Well, vintage 2013, but thats a long time in cell-phone years. Fixed are a trio of vulnerabilities, two of which are reported to be exploited in the wild. CVE-2021-30761 and CVE-2021-30762 are both flaws in Webkit, allowing for arbitrary code execution upon visiting a malicious website.

The third bug fixed is a very interesting one, CVE-2021-30737, memory corruption in the ASN.1 decoder. ASN.1 is a serialization format, used in a bunch of different crypto and telecom protocols, like the PKCS key exchange protocols. This bug was reported by [xerub], who showed off an attack against locked iPhone immediately after boot. Need to break into an old iPhone? Looks like theres an exploit for that now.

Or if we were feeling less charitable, wed call them bloatware. Either way, researchers at Oversecured took a look and found some problems. First up is Samsungs Knox Core app, part of their enterprise security system. This core framework file can install other apps, triggered by a world-writable URI. So first problem, anything that can load a file and call a URI can trigger an arbitrary app install. There is a second problem: part of that install process copies the app-to-be-installed to a world-readable location. This means that with a bit of work, any other app can abuse this to read any file this system app can read, and thats all of them.

Up next is the managed provisioning app. This too allows installing apps, but has a built-in verification system, as it was based on Managed Provisioning from the Android Open Source Project (AOSP). Samsung added features, one of which is a flag to disable the verification. Oh, and this one installs apps as system. Please install my rootkit, Samsung. OK

And the last problem well look at is the TelephonyUI app. It exposes a receiver, PhotoringReceiver, which takes two arguments: the URL to download, and the file location to write it to. This function does check that the remote server reports the file to be an image or video, but this is trivial for an attacker to spoof. The result is that an attacker can send an intent, download an arbitrary file, and write it anywhere on the phone as UID 1001, one of the system users.

Volkswagen has just confirmed that someone got access to a database of their potential and actual customers. Their letter states that a vendor left electronic data unsecured. Based on previous breaches, this is probably something like an Elsticsearch instance exposed to the Internet. So theres good and bad news here. The good, if you only made it into their database as a prospective customer, only your name, physical and email addresses, and a phone number are exposed. The bad? If you were an actual customer, that could include drivers license number, date of birth, and SSN. Watch out for targeted fishing using the information, though the more likely scenario is something like unemployment fraud committed using the information.

Though when it comes to source code, its not really theft, just unauthorized copying. Regardless, an unnamed group claims to be in possession of 780 GB of internal data and source code from EA, and is offering access for a mere $28 million. Its unclear how the breach happened, but known bugs have been suggested, like the high-profile Microsoft Exchange bug from a few months back. Regardless, the dump includes the full source to FIFA 21 and FrostBite, EAs engine. The really bad part is the collection of API keys and other secrets that were inevitably a part of the grabbed source.

Researchers from NordLocker discovered a really big database of data, which appear to have been collected by a network of trojans. How did that malware wind up on real machines? Mostly through cracked software, it seems. An illegal Photoshop download, a Windows crack, and a handful of games. So think long and hard before youre tempted to fire up you favorite torrent client, you might just be inviting malware in.

The malware did quite a bit while it was active, too. It took a screenshot, as well as a webcam capture. Uploaded files from the users folders, captured and sent along passwords and cookies, and more. The whole trove of data seems to be 1.2 terabytes worth. Yikes.

If you havent noticed, a growing collection of people, companies, and now nations are taking issue with Apples walled garden approach to smartphone software. The ongoing litigation from Epic over the Fortnight game and the app store has perhaps the highest profile. But the European Union, thanks to their proposed Digital Markets Act (DMA), might soon enter the fray. This legislation aims to limit the power a digital gatekeeper can exercise over a market. Tim Cook recently gave his thoughts on the idea not entirely positive. The biggest issue? The DMA would force Apple to allow app sideloading. The official response is that sideloading would destroy the security of the iPhone.

Now lets chat about that for a moment. Is it a bit iffy to install apps on your device that havent been vetted through the official app store? Sure. If you arent careful, youre likely to install apps with malware, and not have a Google or Apple working to detect and automatically remove the malicious app. On the other hand, it seems just a bit over-the-top to say that this would destroy the iPhones security. There have been plenty of vulnerabilities found in the last couple years that can compromise the device from a simple page visit. Not to mention malicious apps that have made it into the store.

Allowing you to install any application you wanted would break Apples stranglehold on the iOS app store. What this would mean, is that Apple would out on a whole lot of revenue from apps like Fortnight, who would be willing to build their own app store. So what do you think? Is this really the big security problem that Apple says it is, or are they just being protective of their walled garden and the benefits thereof?

Sometimes, exploits arent notable for how serious they are, but for how educational the write-up is. Firmly in that category is this story of getting a remote shell on an ancient Linksys WRT54GL. Quick note, the L there stands for Linux, and this particular router exists because the WRT54G was the grand-daddy of custom router firmware. A request for GPL code for the original router led a few hackers to put together their own firmware images, and DD-WRT and OpenWRT were both born out of the efforts. Router revisions happen rapidly, and soon the WRT54G had switched to VxWorks, and cut the flash in half, making support just about impossible for the custom firmwares. Enough customers complained, that Linksys re-released the older version as the WRT54GL.

History aside, [Elon Gliksberg] had one of the old routers, and decided to try to break in. Scan the ports with nmap, nothing interesting. The web interface? There is a diagnostic page that can send pings, so it probably runs a linux commands on the backend, so its worth trying something like ping 192.168.1.1; echo hello; That endpoint was sufficiently sanitized that it wasnt a viable attack. A bit of decompiling did lead to one call of system() that could be abused, though. That call was in the post-upgrade logic, to restore the user-interface language. Set the language to some shellcode, and you get execution. From there, it was just the task of getting the reverse shell compiled for that specific device, and using the built-in wget to fetch it.

So heres the irony: this vulnerability is launched as part of uploading firmware, and this device is just about the most widely supported target for custom firmware in the world. You can install your own Linux image on it with the same access this hack requires. Irony aside, the value here is waking through the process, which is well written out, and full of tips for trying to find your own exploit.

A couple weeks ago, we covered a nifty new project, the WiFi Wart. Well [Ryan] is still at it, and has an update on his progress. Theres good news, like finishing the design of the first prototype boards, sourcing the components, and actually assembling a trio of the test boards. Then there was some bad news, like discovering the hard way that the Low Dropout Regulator (LDO) he ordered was a 3.3 V component, instead of the needed 2.5 V. Thats one board with dead components, and time spent waiting on the replacement parts. Such is the way of things, when building new hardware. Well keep you up to date with this promising project, as updates are available.

See the rest here:

This Week In Security: Updates, Leaks, Hacking Old Hardware, And Making New - Hackaday