A couple weeks ago we talked about inn-app browsers, and the potential privacy issues when opening content in them. This week Microsoft reveals the other side of that security coin — JavaScript on a visited website may be able to interact with the JS embedded in the app browser. The vulnerability chain starts with a link handler published to Android, where any https://m.tiktok[.]com/redirect links automatically open in the TikTok app. The problem here is that this does trigger a redirect, and app-internal deeplinks aren’t filtered out. One of these internal schemes has the effect of loading an arbitrary page in the app webview, and while there is a filter that should prevent loading untrusted hosts, it can be bypassed with a pair of arguments included in the URI call.
Once an arbitrary page is loaded, the biggest problem shows up. The JavaScript that runs in the app browser exposes 70+ methods to JS running on the page. If this is untrusted code, it gives away the figurative keys to the kingdom, as an auth token can be accessed for the current user. Account modification, private video access, and video upload are all accessible. Thankfully the problem was fixed back in March, less than a month after private disclosure. Still, a one-click account hijack is nothing to sneeze at. Thankfully this one didn’t escape from the lab before it was fixed.
UPnP Strikes Again
It’s not an exaggeration to say that Universal Plug and Play (UPnP) may have been the most dangerous feature to be included in routers with the possible exception of open-by-default WiFi. QNAP has issued yet another advisory of ransomware targeting their devices, and once again UPnP is the culprit. Photo Station is the vulnerable app, and it has to be exposed to the internet to get pwned. And what does UPnP do? Exposes apps to the internet without user interaction. And QNAP, in their efforts to make their NAS products more usable, included UPnP support, maybe by default on some models. If you have a QNAP device (or even if you don’t), make sure UPnP is disabled on your router, turn off all port forwarding unless you’re absolutely sure you know what you’re doing, and use Wireguard for remote access.
Retro Hacking — The IBM AS/400
If you have a craving for some throwback hacking, then [pz] from Silent Signal has you covered. While you don’t see IBM AS/400 front-ends in stores as often as you used to, these venerable machines still run the back-end of plenty of businesses. The IBM AS/400 was the solution to IBM’s problem in the early 80s, of too many similar product lines. It replaced the System/36 and System/38 products, and was based on an effort to port System/36 software to system/38 hardware. The new solution used Technology Independent Machine Interface (TIMI) as an intermediary layer that compiled programs targeted. The actual OS did a run-time translation to the machine code of the physical processor, which is how IBM has managed to keep such old software running for so long. It’s similar to what Sun was trying to do with Java, though with very different modern-day results.
The researchers at Silent Signal see an untapped wealth of research in the IBM AS/400, now officially called IBM i. Lots of code running on these systems was written in the late 80s and 90s, with much of it getting Y2k fixes — and likely untouched since then. The state of computer security research was quite different then, so there are likely to be issues to find. To this end, they’ve set up a dedicated IBM i lab, and have some findings to share. In a penetration test against a live customer, they were given access to an emulated TN5250 terminal, and a limited-privilege account. TN5250 turned out to be the foot in the door, as the IBM-specific terminal protocol supports extended keys like Attn, which works as a system interrupt key. The menu that’s triggered has a nifty feature, opening a shell as the logged-in user. A subtle misconfiguration allows running commands as other users with additional privileges. This exact penetration test didn’t use vulnerabilities in IBM code, just system misconfiguration — but as the pool of system administrators that really understand this legacy tech shrinks, this is likely to become a common issue.
The 8,729 day old CVE
Speaking of legacy code-bases… It’s always a bit startling to see how old some of the code is in our modern machines. Curl had its 4.0 release in 1998, and before that it was called urlget. There’s code written back then that’s still around in the project, and it turns out at least one vulnerability Sort of.
Cookies are little bits of data that web pages can store on you machine, and thanks to an well-intended-but-terrible law, something that bugs you for every new website you visit. The history of cookies is a bit convoluted, as it was always an ad-hoc solution without a formal design or specification. As a result, we see some odd behavior even today, like the fact that a subdomain can set a cookie for the parent domain, and that other subdomains will see that cookie. So http://www.hackaday.com can set a cookie with domain=hackaday.com. Then if you visit someothersubdomain.hackaday.com, that cookie gets sent with the request.
Web servers have been around just as long, but have been forced to ratchet down their security posture. One of those security enhancements is to reject any HTTP requests that contain control codes, like 0x07, the ASCII bell. Cookies have no inherent ban on these values. Put those together, and you get a denial of service vulnerability. A subdomain can set a cookie containing a control code, assigned to the target domain, and that cookie gets sent in any future requests. And those requests get dropped because of the trapped cookie. The cookie-handling code was added in late 1998, and this trick has worked ever since. Except, browsers added the control-code check in 2016. It must be a quantum effect, resulting in a bug that is nearly 24 years old, and merely 6 years old, both at the same time. Either way, 7.85.0 fixes the problem.
Rusty Tor
The Tor project has a shiny rusty new release — Arti, a Tor implementation in Rust. This started as a pet project by [Nick Mathewson], but within a few months he had a code-base that could actually connect to the Tor network, and soon after was actually sending properly anonymized traffic. And a week ago today, version 1.0.0 was released, marking the project ready for prime time.
There are a few things missing, like the censorship avoidance capability — the plugins that disguise Tor traffic as something else. On the other hand, Arti is being used as an opportunity to make some changes and updates to Tor, like the introduction of a proper API. It looks like the eventual plan is to deprecate the C implementation, but there’s quite a bit of work left on Arti before it reaches complete feature parity.
EFF Enters the Fog
The EFF is taking aim at Fog Data Science, a company that purchases “anonymized” location data from mobile app vendors, and then sells a service to law enforcement that allows searching for individuals among that data. Researchers at the EFF pulled off a brilliant bit of detective work, reverse engineering the Fog Reveal search engine, while never actually having access to the interface. The trick is to visit the Fog Reveal web app, and grabbing all the JavaScript libraries that load on site visit. The app requires an account to use, but all the code that runs in the browser is available without that login. EFF took on the non trivial task of reverse engineering the data expected by the front-end, but in the end it gave them a detailed look.
The results are impressive, and worrying. A subscriber can select an area, give a date and time, and get a list of devices that were in that area at the time. The data is anonymized — but you can then select a data stream and follow the user home. Not so anonymous when you can trivially find a home address. On one hand I’m sure this comes in very handy when trying to round up a list of suspects for a crime, but it seems precariously close to what one might consider an unreasonable search or seizure of data.
This Week in Security: One-click, UPnP, Mainframes, and Exploring the Fog
Source: Manila Flash Report
0 Comments