Preface: The researchers found that 91.88 percent of attacks targeting port 445, the most common SMB port, attempted to use the EternalBlue exploit. Even if this is a Linux environment, when the server supports the SMB version of the protocol. It more or less may have the opportunity to integrate with other peer servers, especially Windows servers. Therefore, it must be aware of the potential risks of ransomware.

Background: Common Internet File System (CIFS), an implementation of the Server Message Block (SMB) protocol, is used to share file systems, printers, or serial ports over a network. Notably, CIFS allows sharing files between Linux and Windows platforms regardless of version.

Ref: To mount the CIFS share on Linux for File Viewer, use the command: mount -t cifs // host_name / VIEWER_SHARE -o username= username ,password= password / local_path. CIFS is an unsecure implementation of SMB – its lack of encryption has seen it exploited through malware like NotPetya and the WannaCry ransomware attack, which occurred through a zero-day exploit called EternalBlue.

Vulnerability details: CVE-2022-47939 – An issue was discovered in ksmbd in the Linux kernel before 5.19.2. fs/ksmbd/smb2pdu[.]c has a use-after-free and OOPS for SMB2_TREE_DISCONNECT.

• In computing, an oops is a serious but non-fatal error in the Linux kernel.

Details about this design weakness, see the link – https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf6531d98190fa2cf92a6d8bbc8af0a4740a223c

Merry Christmas and Happy New Year

Preface: Long time ago,  blockchain developers announcement that they have developed a blockchain platform to launch a digital system for international payments capable of replacing the global Swift system. Seems they are not successful.

Background: IBM FTM for swift services is certified real-time SWIFT messaging interface. Ensure faster payments in addition to SWIFT without changing the back office. Lower costs of compliance and get tailored solutions for your organization

About RMA: When RMA was introduced in 2009 as a replacement for the Bilateral Key Exchange (BKE), the spirit of the product was for banks to open the door to as many counterparties and correspondents as possible. Legacy RMAs can also create the opportunity for payments to be sent to destinations which may no longer be wanted or authorised, resulting in fraud risk.

The RMA is a SWIFT-mandated authorisation that enables financial institutions to define which counterparties can send them FIN messages.

Vulnerability details: IBM Financial Transaction Manager SWIFT could allow an authenticated user to lock additional RM authorizations, resulting in a denial of service on displaying or managing these authorizations.

Official announcement: For details, see the link – https://www.ibm.com/support/pages/node/6848881

Some performance problems might seem to be locking problems even though they are really problems somewhere else in the system. For example, a table space scan of a large table can result in timeout situations. Similarly, when tasks are waiting or swapped out, and the unit of work is not committed, the tasks continue to hold locks.

One of the recommendation: Reduce locking contention on the catalog and directory for data definition, bind, and utility operations

You can use the following approaches to reduce this type of contention:

Avoid using LOCK TABLE statements and statements that use RR isolation to query the catalog.

Preface: There are two types of paring base on BLE version:

•  LE Legacy Pairing (supported in Bluetooth 4.0 and 4.1)
• LE Secure Connections (introduced in Bluetooth 4.2)

Background: The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) allows attackers to bypass passkey entry in legacy pairing.

Do you think this is a fundamental problem or flaw in the product itself? I speculate this is not a new finding, maybe we have seen this problem in BLE before (see below):

A BLE device that wants to share secure data with another device must first pair with that device. The Security Manager Protocol (SMP) carries out the pairing.Responder (in the context of BLE Security Manager), who has already sent their commitment Sconfirm,
Sconfirm =presumably c1(TK, Srand, p1, p2) = AESTK[AESTK(Srand ⊕ p1) ⊕ p2], but who has not revealed their Srand, yet. Due to the lack of binding in c1, such a Responder can still arbitrarily change their “committed” passkey TK and labels p1, p2, since – as we have seen above – the correct Srand for any new value of (TK, p1, p2) can be trivially found by Eq. 2 while keeping the former Sconfirm still the same.

rand = AES-1TK [AES-1TK(C) ⊕ p2] ⊕ p1. (Eq. 2)

I speculate that the product is still using LE Legacy Pairing (supporting Bluetooth 4.0 and 4.1), so presumably this is the root cause.

Vulnerability details: CVE-2022-46400 The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) allows attackers to bypass passkey entry in legacy pairing.

Official announcement: For details, see the link – https://nvd.nist.gov/vuln/detail/CVE-2022-46400

Preface: Android 13, released on August 15, 2022, is the latest version, and the recently released Android 12.1/12L includes improvements specific to foldable phones, tablets, desktop-sized screens and Chromebooks.

Background: In Android 11, the Android Common Kernel v5. Before kernel 4.12, opening /dev/ion allocated an Ion client. The IOC_ION_ALLOC ioctl allocated a new buffer and returned it to userspace as an Ion handle (an opaque integer meaningful only to the Ion client that allocated it). To map buffers into userspace or share them with other processes, Ion handles were re-exported as dma-buf fds using the IOC_ION_SHARE ioctl.

My speculation based on the details above: Using ION, each DMA-BUF heap is a separate character device, access to each heap can be controlled separately with sepolicy. This wasn’t possible with ION because allocation from any heap only required access to the /dev/ion device.

Vulnerability details: CVE-2022-42529 – A vulnerability was found in Google Android Smartphone Operating System – Android kernel (Android ID: A-235292841))

Official announcement: For details, see the link – https://source.android.com/docs/security/bulletin/pixel/2022-12-01

Preface: Continuing yesterday’s discussion on CVE-2022-44683. Since cve doesn’t provide technical details. This point piqued my interest.

Background: NTDEF(.)H is among the headers in the Software Development Kit (SDK). It is there in the “shared” subdirectory with many other headers that are intended for use in both kernel-mode and user-mode programming.

Ref: NTDEF(.)H is also a ready illustration of how some, if not many, headers in the WDK and SDK are created from some sort of script or master header that extracts from yet more headers. This applies especially to some of the most prominent headers: WDM(.)H, NTDDK(.)H and NTIFS(.)H for kernel-mode programming and WINNT(.)H for user-mode programming.

Vulnerability details: A vulnerability has been discovered and classified as critical in Microsoft Windows (operating system). It’s about an unknown feature of a kernel component. The exact effect of a successful attack is unknown. Furthermore there is no technical details on this vulnerability.

Since the official details do not have information provided.  Following details is my speculation. If the attacker has a way to use InitializeObjectAttributes copy from ntdef(.)h to initialize an Object pointing to OBJECT_ATTRIBUTES. The consequence will similar description of CVE. It may have the potential risk of causing privilege escalation.

Official announcement: For details, see the link – CVE-2022-44683: Windows Kernel Elevation of Privilege Vulnerability.

Preface: Cybersecurity is always critical. Business operations define cost efficiency. Simply put, reduce costs in cyber defense is not a good idea. Because it might lost your company reputation.

Background: The details in today’s vulnerability bulletin are not detailed. Perhaps the reason for vendor not disclosed details is let their customer have schedule enough time do the patching. Since enterprise firm especially finance industry cannot do the patch immediately. But how to do the defense in this period of time? If you believe your company information security policy is compliance. As a result, Insider threat will be reduced. But in terms of zero-day, Attack vectors enable hackers to exploit system vulnerabilities, including the human element. So, virtual patching is a must in cyber security world today.
An intrusion detection system is a device or software application that monitors a network or systems for malicious activity or policy violations. IDS is one of the key components in virtual patching. Since the cyber defense involves a lot of labor resources and information. So it is recommend to assist by MSSP.

Vulnerability details: Microsoft Patch Tuesday (December 14, 2022), Cisco Talos focuses on 6 important vulnerabilities in the patch.
CVE-2022-41121, CVE-2022-44671, CVE-2022-44673, CVE-2022-44675, CVE-2022-44683 and CVE-2022-44704.

• CVE-2022-41121: Windows Graphics Component Elevation of Privilege Vulnerability
• CVE-2022-44671: Windows Graphics Component Elevation of Privilege Vulnerability
• CVE-2022-44673: Windows Client Server Run-Time Subsystem (CSRSS) Elevation of Privilege Vulnerability
• CVE-2022-44675: Windows Bluetooth Driver Elevation of Privilege Vulnerability
• CVE-2022-44683: Windows Kernel Elevation of Privilege Vulnerability
• CVE-2022-44704: Microsoft Windows Sysmon Elevation of Privilege Vulnerability

Official announcement: For details, see the link – https://msrc.microsoft.com/update-guide/en-us

Preface: Most people will agree that the best eCommerce platforms are BigCommerce and Shopify.
HCL Commerce (formerly known as WebSphere Commerce and WCS (WebSphere Commerce Suite)) is a software platform framework for e-commerce, including marketing, sales, customer and order processing functionality in a tailorable, integrated package. It was formerly product of IBM, the product was sold to HCL Technologies in July 2019.

Background: A Java application, which is running inside Open Liberty/WebSphere Liberty runtime (your application logs to hosted Elasticsearch ). For details, refer to attached diagram

1. My assumption will be happened in below circumstances.
   2.Middleware servers include the following types: WebSphere® Application Server, Liberty servers, Apache Tomcat servers, JBoss servers, BEA WebLogic servers, PHP servers,….
2. Quote for an example:
   Files used to display content on a website, such as HTML, CSS, and Javascript files, contain a lot of text. Due to the nature of these files, the text in these files contains many instances of the same word throughout the document.
3. In order to improve the web server and client response time. Open Liberty able to configure “compress HTTP responses” function.
   Open Liberty is a lightweight open source Java runtime that is built by using modular features. WebSphere Liberty is a commercial version of Open Liberty.
4. The http header compression algorithms use (gzip, brotli or zstd),
   In order for the GZIP compression functionality to work on the XML Firewall, the compressed request/response message will have to include the “Transfer-encoding” header instead of “Content-Encoding: gzip”. Specifically, the header is “Transfer-Encoding: gzip, chunked”. Without the Transfer encoding header, the compressed message will not be decompressed by the XML Firewall.
5. If above settings  install on HCL commerce. It will causes vulnerability happen (CVE-2022-38656). HCL Commerce, when using Elasticsearch, can allow a remote attacker to cause a denial of service attack on the site and make administrative changes.
6. use of such a decompression chain could result in a “malloc bomb”

Vulnerabilities close to this discussion: CVE-2022-38656 – Certain versions of HCL Commerce from HCL Software contain the following vulnerability:
HCL Commerce, when using Elasticsearch, can allow a remote attacker to cause a denial of service attack on the site and make administrative changes.

Official announcement: Please refer to the link for details : https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0101265

Preface: Times have changed, and people’s concerns about data security are compared with the past three decades. it looks important. The basis of the design goals of the http protocol in the 90s was to focus on network connections. Because the computing technology at that time was very simple. It does not have the concepts of virtual machines and cloud computing. As of now, man-in-the-middle attacks are easily triggered by network analysis tools, especially wireshark and open source application penetration testing tools. So the http protocol looks even less secure. Maybe you say, I work on the intranet. Or the data fo through network do not have confidential data. However, for modern technology of virtual machine and container architecture, it will be also influenced by http protocol.

Background: OpenShift Container Platform is a cloud-based Kubernetes container platform. The foundation of OpenShift Container Platform is based on Kubernetes and therefore shares the same technology.
For system management and developments. Developers and admins can through the control plane manages the worker nodes and the pods in your cluster. You can configure nodes with the use of machine config pools (MCPs). MCPs are groups of machines, such as control plane components or user workloads. In normal circumstances, it is hard to avoid the network connectivities consists of insecure practice of redirecting users from http:// to https:// URLs.
HTTP Strict Transport Security (HSTS) is a simple and widely supported standard to protect visitors by ensuring that their browsers always connect to a website over HTTPS. HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs.
The following are common scenarios where a man-in-the-middle attack occurs.

• User bookmarks or manually types http://example.com and is subject to a man-in-the-middle attacker.
• Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP.
• A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate.

Vulnerability details: Openshift 4.9 does not use HTTP Strict Transport Security (HSTS) which may allow man-in-the-middle (MITM) attacks.

Official announcement: Please refer to the link for details : https://nvd.nist.gov/vuln/detail/CVE-2022-3259