Home Pwning a Legacy Enterprise Application Server - Sybase EAServer
Post
Cancel

Pwning a Legacy Enterprise Application Server - Sybase EAServer

image

Introduction

This article explores the process of compromising a legacy enterprise application server, EAServer. We start by gaining access to the web console by leveraging default credentials, specifically using the default user jagadmin with an empty password. Once we have access, we upload a specially crafted web service package that includes a web shell, ensuring compatibility with EAServer through the inclusion of configuration and definition files. This web shell enables command execution, setting the stage for further exploitation of the application server.

Gaining Access to the Management Console

After installing the web server, the user jagadmin is created by default. This user can authenticate for initial server configuration and administration either using the EAServer Manager desktop client or through the WebConsole.

The Web Console can be accessed by browsing http://server.local:8080/WebConsole/, and it requires authentication. If the default password has not been modified by the system administrator, we can easily log in with the jagadmin username and an empty password.

image

Uploading a Custom Web Shell for Code Execution

Now that we have access to the administration console, we can upload new web service applications as WAR (Web Application Archive) packages. The WAR packages typically contain a collection of Java applications, including Java classes, JAR files, JSP, and XML files.

However, this server requires the packages to have a specific format before deployment. In summary, the package should include the web.xml configuration and the wsdd definition file.

The web shell has the following structure. A template can be found at this repository:

image

After packing the web shell application as a WAR file with the command jar -cvf shell.war *, we are ready to upload it by right-clicking on the Web Services Collection menu in the Web Console and then clicking Import Collection.

image

Now we can access the application at http://server.local:8080/webshell/index.jsp and remotely execute commands, reading the output.

image

Bonus: Connecting via RDP & Pivoting

Command execution is already possible through the web shell, but we can escalate further by compromising other servers and using them to pivot within the network. In this LAB, the EAServer is configured to run under a service account that has administrator privileges, allowing us to execute commands as an elevated user, such as adding a new user with a known password using the command net user vrls MyPassword.123 /add and placing it in the Administrators group:

image

An interesting method that we can leverage after compromising an exposed web server is to upload a web application that proxies our traffic to the inside network via HTTP server. There are a few tools to accomplish this, such as reGeorg or Neo-reGeorg. These tools have been used in the past by threat groups such as APT28 and FIN13 during cyberattack campaigns to achieve persistence and perform lateral movement, as documented in MITRE ATT&CK.

This is the JSP code that tunnels SOCKS over HTTP (tunnel.tomcat.5.jsp):

image

By connecting the reGeorg agent to the URL, it begins listening on a port for SOCKS5, which should be used together with proxychains and other tools. For example, we can reach the target’s port 3389 to initiate a Remote Desktop session, and the traffic will be handled by the JSP reGeorg code. Other options include reaching more servers on the network to compromise and escalate privileges, depending on the red team or pentesting objectives.

image

Conclusion and Best Security Practices

  • Upgrade legacy systems and ensure they are kept up to date. Isolate them from other assets while the upgrade is in progress (e.g., using VLANs or island setups).
  • Change default settings, including credentials and passwords, and perform hardening.
  • Adjust user and service account privileges according to the least privilege principle, deny by default, and similar practices.
  • Place internet-exposed servers in a separate network security zone, such as a DMZ.
  • Implement logging, monitoring, and detection solutions across hosts and networks.

References

This post is licensed under CC BY 4.0 by the author.