Data Continuity

Backup and recovery services are a necessity for todays modern networks. We can help to determine where and when your data needs to live to be sure it's always available

IT Consulting, Service and Management

Our decades of implementation and integration experience allows us to deliver best-of-class IT services to our customers

Cloud Services

With so many options and implementation scenarios available, let us help you determine how best to use new services available from the cloud.

Since 1996, our goal has been to help our clients maximize productivity and efficiency by expertly maintaining existing infrastructures, as well as designing and implementing new technologies, allowing them to continue growing into the future.

...

We focus on business process design and strategize and implement policies for continuous improvement and integration.
  • Knowledgeable and friendly staff
  • Flexible consumption-based pricing models
  • Online strategy and consulting services
  • Decades of experience
Our Services

News, updates, trends and the latest
info you need to know about IT

VU#417980: Implementations of UDP-based application protocols are vulnerable to network loops

Overview
A novel traffic-loop vulnerability has been identified against certain implementations of UDP-based applications protocols. An unauthenticated attacker can use maliciously-crafted packets against a UDP-based vulnerable implementation of application protocols (e.g., DNS, NTP, TFTP) that can lead to Denial-of-Service (DOS) and/or abuse of resources.
Description
The User Datagram Protocol (UDP) is a simple, connectionless protocol that is still commonly used in many internet-based applications. UDP has a limited packet-verification capability and is susceptible to IP spoofing. Security researchers have identified that certain implementations of the UDP protocol in applications can be triggered to create a network-loop of seemingly never-ending packets. Software implementations of UDP-based application protocols DNS, NTP, TFTP, Echo (RFC862), Chargen (RFC864), and QOTD (RFC865) were specifically found to be vulnerable to such network loops.
As an example, if two application servers have a vulnerable implementation of said protocol, an attacker can initiate a communication with the first server, spoofing the network address of the second server (victim). In many cases, the first server will respond with an error message to the victim, which will also trigger a similar behavior of another error message back to the first server. This behavior has been demonstrated to be resource exhausting and can cause services to become either unresponsive or unstable.
Impact
Successful exploitation of this vulnerability could result in the following scenarios:
1. Overload of a vulnerable service, causing it to become unstable or unusable.
2. DOS attack of the network backbone, causing network outage to other services.
3. Amplification attacks that involve network loops causing amplified DOS or DDOS attacks.
Solution
Apply updates
CERT/CC recommends that you apply the latest patch provided by the affected vendor that addresses this vulnerability in the vendor-specific implementations. Review the vendor-specific information below. If the product is end-of-life/unsupported, vendors will be unlikely to release a patch; thus, we recommend replacing the device.
Protect or replace UDP applications
When possible, protect UDP-based applications using network firewall rules and/or other access-control lists to prevent unauthorized access. If the same service can be implemented using a TCP or with any request-validation capability (e.g., Message-Authenticator) available in the UDP-based application protocol, implement such protection to prevent unknown or spoofed requests. It is recommended that you disable unnecessary and unused UDP services that may be enabled as part of your operating system to prevent exposure of these services for abuse.
Deploy anti-spoofing
Network providers should deploy available anti-spoofing techniques (BCP38) such as Unicast Reverse Path Forwarding (uRPF) to prevent IP spoofing in protecting their internet-facing resources against spoofing and abuse.
Enforce network rate-limiting
Service providers should employ network rate-limiting capabilities, such Quality-of-Service (QoS) to protect their network from abuse from network loops and amplifications and to ensure their critical resources/services are protected.
Acknowledgements
Thanks to the reporters Yepeng Pan and Christian Rossow from the CISPA Helmholtz Center for Information Security, Germany. This document was written by Elke Drennan and Vijay Sarvepalli.

VU#488902: CPU hardware utilizing speculative execution may be vulnerable to speculative race conditions

Overview
A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution has been discovered. CPU hardware utilizing speculative execution that are vulnerable to Spectre v1 are likely affected. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths. Security researchers have labeled this variant of the Spectre v1 vulnerability “GhostRace”, for ease of communication.
Description
Speculative execution is an optimization technique where a computer system performs some task preemptively to improve performance and provide additional concurrency as and when extra resources are available. However, these speculative executions leave traces of memory accesses or computations in the CPU’s cache, buffer, and branch predictors. Attackers can take advantage of these and, in some cases, also influence speculative execution paths via malicious software to infer privileged data that is part of a distinct execution. Attackers exploiting Spectre v1 take advantage of the speculative execution of conditional branch instructions used for memory access bounds checks. These are discussed in some amount of detail in the article Spectre Side Channels found at kernel.org. The earlier research did not include any of the speculative execution attacks using race conditions. Race conditions, generally considered part of concurrency bugs, occur when two or more threads attempt to access the same, shared resource without proper synchronization, which can create an opportunity for an attacker to trick a system into carrying out unauthorized actions in addition to its normal processes. This recent research explores a speculative race condition attack against the speculative execution facility of the modern CPUs.
In characteristics and exploitation strategy, an SRC vulnerability is similar to a classic race condition. However, it is different in that the attacker exploits said race condition on a transiently executed path originating from a mis-speculated branch (similar to Spectre v1), targeting a racy code snippet or gadget that ultimately discloses information to the attacker. Another major difference is that while classic race conditions are relatively infrequent in production code bases, speculative race conditions can be pervasive. Common synchronization primitives all exhibit no-op-like behavior on a transiently executed path, essentially causing any of the critical regions in victim software to become vulnerable. In practice, whether a particular critical region is actually exploitable or not depends on the characteristics of the resulting race condition, similar in some ways to the exploitation of the classic race condition.
Impact
An attacker with access to CPU resources may be able to read arbitrary privileged data or system registry values by utilizing the race condition, termed as speculative race condition.
Solution
Please update your software according to the recommendations from respective vendors with the latest mitigations available to address this vulnerability and its variants.
Acknowledgements
Thanks to Hany Ragab and Cristiano Giuffrida from the VUSec group at VU Amsterdam and Andrea Mambretti and Anil
Kurmus from IBM Research Europe, Zurich for discovering and reporting this vulnerability, as well as supporting coordinated disclosure. This document was written by Dr. Elke Drennan, CISSP.

VU#949046: Sceiner firmware locks and associated devices are vulnerable to encryption downgrade and arbitrary file upload attacks

Overview
Sciener is a company that develops software and hardware for electronic locks that are marketed under many different brands. Their hardware works in tandem with an app, called the TTLock app, which is also produced by Sciener. The TTLock app utilizes Bluetooth connections to connect to locks that utilize the Sciener firmware, and allows for manipulation of the lock. Sceiner firmware locks also supports peripherals. The GatewayG2, also produced by Sciener, allows for connection to an appropriate lock through the TTLock app through WiFi. Sciener firmware also allows wireless keypad connection to supported devices.
Analysis has revealed that various locks are vulnerable through the Sciener firmware. Additional vulnerabilities within the TTLock App and GatewayG2 can be further utilized to compromise the associated electronic lock integrity, and affect any locks that utilize them.
A number of these vulnerabilities are facilitated through the unlockKey character. The unlockKey character, when provided to the appropriate lock, can be used to unlock or lock the device.
Description
The vulnerabilities are as follows:
• CVE-2023-7006
The unlockKey character in a lock using Sciener firmware can be brute forced through repeated challenge requests, compromising the locks integrity. Challenge requests take place during the unlocking process, and contain a random integer between 0 and 65535. Challenge requests can be repeatedly prompted and responded to without any limitations, until the correct integer is discovered. Successfully completing the challenge request provides the unlockKey character.
• CVE-2023-7005
A specially crafted message can be sent to the TTLock App that downgrades the encryption protocol used for communication and can be utilized to compromise the lock, such as by providing the unlockKey character. During the challenge request process, if a message is sent to the lock unencrypted, and with a specific set of information, the corresponding message that contains the unlockKey character will be provided unencrypted.
• CVE-2023-7003
The AES key utilized in the pairing process between a lock using Sciener firmware and a wireless keypad is not unique, and can be reused compromise other locks using the Sciener firmware. This AES key can be utilized to connect to any other Sciener lock that supports wireless keypads, without user knowledge or interaction.
• CVE-2023-6960
The TTLock App supports the creation of virtual keys and settings. They virtual keys are intended to be distributed to other individuals through the TTLock app, for unlocking and locking the lock. They can also be set to only be valid for a certain period of time. Deletion of these keys only occurs client side in the TTLock app, with the appropriate key information persisting within the associated lock. If an attacker acquires one of these keys, they can utilize it to unlock the lock after its intended deletion or invalidation.
• CVE-2023-7004
The TTLock App does not employ proper verification procedures to ensure that it is communicating with the expected device. This can be utilized by a threat actor who introduces a device that spoofs the MAC address of the lock, allowing for compromise of the unlockKey value.
• CVE-2023-7007
The Sciener server does not validate connection requests from the GatewayG2, allowing an impersonation attack. An attacker can impersonate the MAC address of a GatewayG2 that has established a connection with a lock, then connect to Sciener servers and receive messages instead of the legitimate GatewayG2. This can facilitate access of the unlockKey character.
• CVE-2023-7009
Some Sciener-based locks support plaintext message processing over Bluetooth Low Energy, allowing unencrypted malicious commands to be passed to the lock. These malicious commands, less then 16 bytes in length, will be processed by the lock as if they were encrypted communications. This can be further exploited by an attacker to compromise the lock’s integrity.
• CVE-2023-7017
Some Sciener locks’ firmware update mechanism does not authenticate or validate firmware updates if passed to the lock through the Bluetooth Low Energy service. A challenge request can be sent to the lock with a command to prepare for an update, rather than an unlock request. This allows an attacker within Bluetooth range to pass an arbitrary malicious firmware to the lock, compromising its integrity.
Impact
These vulnerabilities allow attackers with physical, adjacent, or Bluetooth connection proximity to the lock access of various capabilities to compromise the lock integrity, without victim knowledge or interaction. This results in the locks functionality being null.
Affected versions:

Kontrol Lux lock, firmware versions 6.5.x to 6.5.07
Gateway G2, firmware version 6.0.0
TTLock App, version 6.4.5

Solution
There is no software solution for these vulnerabilities, only a potential work-around. By disabling various functions related to the Bluetooth capability of locks using Sciener firmware, several of the attacks can be prevented. However, as the locks are designed with the intention of utilization with the TTLock App, this may not be a practical solution for most users.
Acknowledgements
Thanks to Lev Aronsky, Idan Strovinsky, and Tomer Telem of Aleph Research by HCL Software for providing the report and information. This document was written by Christopher Cullen.

Visit Our News Page

Contact us today if you'd like to know more
about how we can keep your network working at its best

VistaNet, Inc is a technology consulting and services company, helping enterprises
marry scale with agility to achieve competitive advantage.

We'd love to talk about your technology needs

Our experts would love to contribute their
expertise and insights to your potential projects
  • This field is for validation purposes and should be left unchanged.