Message-ID: <CAFD2FDNUrF98rgAGwJVY-QG-UcGFP34nhFVHV0QrxpA2Do4GKg@mail.gmail.com>
Date: Fri, 27 Dec 2024 22:21:21 -0500
From: hyp3rlinx <apparitionsec@...il.com>
To: fulldisclosure@...lists.org
Subject: [FD] IBMi Navigator / CVE-2024-51464 / HTTP Security Token Bypass

[+] Credits: John Page (aka hyp3rlinx)		
[+] Website: hyp3rlinx.altervista.org
[+] Source:  https://hyp3rlinx.altervista.org/advisories/IBMi_Navigator_HTTP_Security_Token_Bypass-CVE-2024-51464.txt
[+] x.com/hyp3rlinx
[+] ISR: ApparitionSec

[Vendor]www.ibm.com

[Product]
Navigator for i is a Web console interface where you can perform the
key tasks to administer your IBM i.
IBM Navigator for i supports the vast majority of tasks that were
available in the System i Navigator Windows client application.
This Web application is part of the base IBM i operating system, and
can be easily accessed from your web browser.

[Vulnerability Type]
HTTP Security Token Bypass

[CVE Reference]
CVE-2024-51464

[Security Issue]
IBM i is vulnerable to bypassing Navigator for i interface
restrictions.  By sending a specially crafted request, an
authenticated attacker could exploit this
vulnerability to remotely perform operations that the user is not
allowed to perform when using Navigator for i.

The web application generates an HTTP security token ID called "Mn:"
with a 19 digit value and is set in the HTTP session response header
per user.
Navigator, uses this token for integrity purpose to protect against
arbitrary and or malicious HTTP requests. Therefore, upon receipt of a
bogus
security token in an HTTP request the server will respond with HTTP
403 Forbidden message.

However, attackers can modify existing tokens to bypass the 403
Forbidden directive to achieve their objectives. Problem is Navigator
security token logic
does not properly create or detect if a security token is valid or if
it has been tampered with.

Attackers can manipulate the last eight digits of a token by setting
them to all 0000s (zeroes) and or increment them by one, token length
must be the same.
This can trick the application into processing attacker controlled
security tokens as the server thinks it is valid, this undermines the
security of this protection.

E.g. Valid HTTP header generated by the server.

Mn: 6844795211344371559
Content-Length: 290
Origin: https://10.1.1.4:2003

Example of a bogus but honored MN header token set by an attacker,
padded with zeros and happily accepted by the backend servlet.
Mn: 6844795211300000000

The MN token is generated in the "initProtectionSetting" java method.

public void initProtectionSetting(HttpServletRequest request,
HttpServletResponse response) {
    initEncryption();
    initSession();

   [ REDACTED ]

    setMagicNumber(magicNumber);
    response.setHeader("MN", magicNumber + "");
    setUserAgent(request.getHeader("User-Agent"));
  }


In the (doFilter) Method we see the check for MN header which sends
HTTP 403 on invalid tokens.

     String mnStr = hRequest.getHeader("MN");
        if (mnStr == null)
          mnStr = hRequest.getParameter("MN");
        if (!isMnMatched(mnStr, hSession)) {
          NavLogger.severe("Forbidden. Incorrect HTTP ID");
          NavLogger.info("Request URI: " + requestURI);
          hResponse.sendError(403);
          return;


Invalid token response will return:
Error 403: SRVE38895F: Error reported: 403


Attacker increments MN or pad with zeros and requests are accepted and
the token succeeds.
HTTP 200 OK


[References]
ADV0142855https://www.ibm.com/support/pages/node/7179509

IBM classified as "CWE-644: Improper Neutralization of HTTP Headers
for Scripting Syntax".
To be clear HTTP headers are just the delivery method for sending
attacker controlled tokens to bypass Navigator protection.


[Exploit/POC]
Intercept Navigator HTTP requests and increment the last one or two
digits of the Mn: HTTP
header security token or just pad the last eight digits with all zeroes.


[Network Access]
Remote


[Severity]
Medium
CVSS Base score:  4.3

[Affected versions]
7.5.0,7.4.0, 7.3.0


[Disclosure Timeline]
Vendor Notification:  10/14/2024
Vendor fix and publication: 12/20/2024
12/27/2024 : Public Disclosure



[+] Disclaimer
The information contained within this advisory is supplied "as-is"
with no warranties or guarantees of fitness of use or otherwise.
Permission is hereby granted for the redistribution of this advisory,
provided that it is not altered except by reformatting it, and
that due credit is given. Permission is explicitly given for insertion
in vulnerability databases and similar, provided that due credit
is given to the author. The author is not responsible for any misuse
of the information contained herein and accepts no responsibility
for any damage caused by the use or misuse of this information. The
author prohibits any malicious use of security related information
or exploits by the author or elsewhere. All content (c).

hyp3rlinx
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Powered by blists - more mailing lists