Search This Blog

Showing posts with label Exploits. Show all posts

Dex: ID Service Patches Bug that Allows Unauthorized Access to Client Applications

 

The renowned OpenID Connect (OIDC) identity service, Dex has detected and patched a critical vulnerability. The bug allows a threat actor access to the victim's ID tokens via intercepted authorization code, potentially accessing clients’ applications without authorization. The vulnerability was patched by Sigstore developers Hayden Blauzvern, Bob Callaway, and ‘joernchen', who initially reported the bug. 

The open-source sandbox project of Cloud Native Computing Foundation, Dex utilizes an identification layer on top of OAuth 2.0, providing authentication to other applications.  

Dex acts as a portal to other identity providers through certain ‘connectors’, ranging from authentication to LDAP servers, SAML providers, or identity providers like GitHub, Google, and Active Directory. As a result, Dex claims 35.6 million downloads to date. As stated in the Developer's notification, the bug affects “Dex instances with the public clients (and by extension, clients accepting tokens issued by those Dex instances.” 

As per the discovery made by security researchers, the threat actor can steal an OAuth authentication code by luring the victim to enter a malicious website and further, leading him into the OIDC flow. Thence the victim is tricked into exchanging the authorization code for a token, which allows access to applications that accept the token. As the exploit can be used multiple times, the threat actor can get a new token every time the old one expires.  

The bug thus comes into existence because the authentication process instigates a persistent “connector state parameter" as the request ID to look up the OAuth code. 

“Once the user has successfully authenticated, if the webserver is able to call /approval before the victim’s browser calls /approval, then an attacker can fetch the Dex OAuth code which can be exchanged for an ID token using the /token endpoint,” the advisory stated. The users are advised to update to version 2.35.0, as the vulnerability, having the CVSS rating of 9.3, affects versions 2.34.0 and older.  

The bug was fixed by introducing a hash-based message authentication (HMAC) code, that utilizes a randomly generated per-request secret, oblivious to the threat actor, and is persisted between the initial login and the approval request, making the server request unpredictable.

CISA: Atlassian Bitbucket Server Flaws added to KEV Catalog List

 

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added three recently disclosed security flaws to its list of Known Exploited Vulnerabilities (KEV ) Catalog, including critical vulnerability in Atlassian’s Bitbucket Server and Data Center, and two Microsoft Exchange zero-days.

At the end of August, Atlassian rectified a security flaw, tracked as CVE-2002-36804 (CVSS score 9.9) in Bitbucket Server and Data Center. The flaw is a critical severity and is related to a command injection vulnerability that enables malicious actors access to arbitrary code execution, by exploiting the flaw through malicious HTTP requests.

"All versions of Bitbucket Server and Datacenter released after 6.10.17 including 7.0.0 and newer are affected, this means that all instances that are running any versions between 7.0.0 and 8.3.0 inclusive are affected by this vulnerability," Atlassain states in an advisory released in late August.

Although CISA did not provide further details on how the security flaw is being exploited or how widespread the exploitation efforts are, researchers at GreyNoise, on September 20 and 23 confirms to have detected evidence of in-the-wild abuse.

The other two KEV flaws, Microsoft Exchange zero-days (tracked as CVE-2022-41040 and CVE-2022-41082) exploited in limited, targeted attacks according to Microsoft.

"Microsoft is also monitoring these already deployed detections for malicious activity and will take necessary response actions to protect customers. [..] We are working on an accelerated timeline to release a fix," states Microsoft.

The Federal Civilian Executive Branch Agencies (FCEB) have applied patches or mitigation measures for these three security vulnerabilities after being added to CISA’s KEV catalog as required by the binding operational directive (BOD 22-01) from November.

Since the directive was issued last year, CISA has added more than 800 security vulnerabilities to its KEV catalog, while requiring federal agencies to direct them on a tighter schedule.

Although BOD 22-01 only applies to U.S. FCEB agencies, CISA has suggested to all the private and public sector organizations worldwide to put forward these security flaws, as applying mitigation measures will assist in containing potential attacks and breach attempts. In the same regard, CISA furthermore stated, “These types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose significant risk to the federal enterprise”

BIND Updates Patch High-Severity Flaws

The Internet Systems Consortium (ISC) announced this week the availability of patches for six remotely exploitable vulnerabilities in the widely used BIND DNS software. 

Four of the fixed security vulnerabilities have a severity rating of 'high.' All four have the potential to cause a denial-of-service (DoS) condition. The first of these is CVE-2022-2906, which affects "key processing when using TKEY records in Diffie-Hellman mode with OpenSSL 3.0.0 and later versions," according to ISC's advisory. 

A remote attacker could use the flaw to gradually deplete available memory, resulting in a crash. Because the attacker could exploit the vulnerability again after restarting, "there is the potential for service denial," according to ISC.

The second flaw, tracked as CVE-2022-3080, may cause the BIND 9 resolver to crash under certain conditions when crafted queries are sent to the resolver. According to ISC, CVE-2022-38177 is a memory leak issue in the DNSSEC verification code for the ECDSA algorithm that can be triggered by a signature length mismatch.

“By spoofing the target resolver with responses that have a malformed ECDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources,” ISC explains.

CVE-2022-38178, a memory leak affecting the DNSSEC verification code for the EdDSA algorithm that can be triggered by malformed ECDSA signatures, is the fourth high-severity bug addressed in BIND 9. BIND 9.18 (stable branch), BIND 9.19 (development version), and BIND 9.16 all received updates (Extended Support Version). As per ISC, no public exploits targeting these vulnerabilities are known.

The US Cybersecurity and Infrastructure Security Agency (CISA) urged users and administrators on Thursday to review ISC's advisories for these four security holes and apply the available patches as soon as possible.

Vulnerability in OCI Could Have Put the Data of Customers Exposed to the Attacker

 

A vulnerability called 'AttatchMe', discovered by a Wiz engineer could have allowed the attackers to access and steal the OCI storage volumes of any user without their permission. 

During an Oracle cloud infrastructure examination in June, Wiz engineers disclosed a cloud isolation security flaw in Oracle Cloud Infrastructure. They found that connecting a disk to a VM in another account can be done without any permissions, which immediately made them realize it could become a path for cyberattacks for threat actors. 

Elad Gabay, the security researcher at Wiz made a public statement regarding the vulnerability on September 20. He mentioned the possible severe outcomes of the exploitation of the vulnerability saying this could have led to “severe sensitive data leakage” for all OCI customers and could even be exploited to gain code execution remotely. 

To exploit this vulnerability, attackers need unique identifiers and the oracle cloud infrastructure's environment ID (OCID) of the victim, which can be obtained either through searching on the web or through low-privileged user permission to get the volume OCID from the victim's environment. 

The vulnerability 'AttachMe' is a critical cloud isolation vulnerability, which affects a specific cloud service. The vulnerability affects user data/files by allowing malicious actors to execute severe threats including removing sensitive data from your volume, searching for cleartext secrets to move toward the victim's environment, and making the volume difficult to access, in addition to partitioning the disk that contains the operating system folder. 

The guidelines of OCI state that volumes are a “virtual disk” that allows enough space for computer instances. They are available in the two following varieties in OCI: 

1. Block volume: it is detachable storage, allowing you to expand the storage capacity if needed. 

2. Boot volume: it is a detachable boot volume device containing the image used to boot a system such as operating systems, and supporting systems. 

As soon as Oracle's partner and customer Wiz announced the vulnerability, Oracle took immediate measures to patch the vulnerability while thanking wiz for disclosing the security flaw and helping them in resolving it in the last update advisory of receiving the patch for the vulnerability.

New vulnerabilities in Dataprobe are Invading The Devices Remotely

 

Researchers from Team82 uncovered critical flaws in Dataprobe’s iBoot power distribution unit. As a result of the flaws, the threat actors were able to control and cut off the electric power to the systems or other connected devices, potentially impacting the targeted firms.
 
Team82 is the research division of Claroty, an industrial cybersecurity firm, that found seven vulnerabilities. One of these vulnerabilities is responsible for granting access to malicious actors invading systems to execute some malicious source codes.
 
The iboot power distribution unit is a cloud service that allows its users real-time control of the outlets from any location through web interfaces, Telnet, and SNMP.
 
According to Census Report 2021, over 2000 power distributing units were connected to the internet, with Dataprobe devices accounting for 31% of the total.
 
The iBoot power distribution unit was mentioned in the report by Team82, which can be managed remotely through web interfaces if the device is not connected directly to the internet, or through a cloud-based infrastructure that allows access to the device's management page if the device is not directly connected to the internet.
 
Cyber attackers exploited this feature and gained access to platforms such as web connections and the cloud to remotely exploit vulnerabilities. Such exploitation of the vulnerabilities also permitted the attackers to bypass Network Address Translation (NAT) and firewalls and invade businesses through smart connectivity channels.
 
The CISA, U.S.-based cybersecurity and infrastructure security agency, circulated an advisory to the organization, which included information about these seven vulnerabilities, such as the deployment of these critical flaws all across the world, including in the manufacturing sector. 
 
The CVE identifier assigned to the seven vulnerabilities is CVE-2022-3183 through CVE-2022-3189. The issue involves OS command injection, path traversal, sensitive information exposure, improper access control, incorrect authorization, and server-side request forgery (SSRF).
 
A new firmware version of the issue has been released by the vendors, 1.42.06162022, to describe the problem. There was a recommendation from Dataprobe for all users to update the firmware to the latest version and also to disable the Simple Network Management Protocol (SNMP), which is used to monitor the network.

CISA’s vulnerabilities in KEV: Federal Agencies Have to Fix Them

 

CISA has included 6 vulnerabilities to its “Known Exploited Vulnerabilities Catalog” and has ordered the federal agencies to patch them with the help of vendor’s instructions. 

The CISA, U.S.-based cybersecurity and infrastructure security agency has given a deadline of 6th October to the government agencies to fix the security flaws that surfaced between 2010 and 2022. CISA has instructed the federal agencies to fix the newly added security vulnerabilities as per the directive. 

Exploiting the majority of the vulnerabilities that have been added to the list, gives cyber attackers local privilege escalation or admin-level access to the system, whereas the two of them permit to execution of a malicious code remotely, known as Remote Code Execution. 

These vulnerabilities that were found between the stretch of 2010 and 2022 comprise the most that were identified in 2013 and were engineered as spyware  especially for getting into the social media accounts of android users by using Tizi malware. 

The list of security flaws discovered in 2013 includes: 

  • CVE-2013-6282: it gives local privilege escalation and is used for rooting android devices.
  • CVE-2013-2597: it gives local privilege escalation and is used for overflow in Code Aurora audio driver.
  • CVE-2013-2596: it gives local privilege escalation and deals with Linux kernel integer overflow.
  • CVE-2013-2094: it gives local privilege escalation and manages Linux kernel privilege escalation. 

The CISA also added the oldest bug in KEV which was disclosed in 2010; this was the bug held responsible for spreading the Stuxnet worm, which caused a slowdown in the country’s development in the field of nuclear weapons by destroying the machines at the Natanz Uranium Enrichment Plant. 

The bug found in 2010 was named CVE-2010-2568,  it allows remote access to inject malicious code into the system. The latest security issue added to the vulnerability list was identified a month ago. It was also the only security flaw found this year. The cyber attackers exploited it and affected Trend Micro Apex One and Apex one as services. The recently identified bug was CVE-2022-40139, it was described as an improper validation issue. 

The list of all of the vulnerabilities is available publically on the official website of known exploited vulnerabilities. The directive from November 2021, “Binding operational directive 22-01”, legally states, that resolving all the vulnerabilities added by CISA and making them 'Known Exploited Vulnerabilities' is the responsibility of all federal civilian agencies to regulate a secure environment.

RTLS Systems Found Vulnerable to MiTM Attacks & Location Manipulation

 

Multiple vulnerabilities in Ultra-wideband (UWB) Real-time Locating Systems (RTLS) have been reported, allowing threat actors to launch adversary-in-the-middle (AitM) attacks and tamper with location information. 

The cybersecurity firm Nozomi Networks disclosed in a technical write-up last week, "The zero-days found specifically pose a security risk for workers in industrial environments. If a threat actor exploits these vulnerabilities, they have the ability to tamper with safety zones designated by RTLS to protect workers in hazardous areas."

RTLS is used for automatically identifying and tracking the location of objects or people in real-time, typically within a confined indoor area. This is accomplished by attaching tags to assets, which broadcast USB signals to fixed reference points known as anchors, which then determine their location. 

However, flaws discovered in RTLS solutions (Sewio Indoor Tracking RTLS UWB Wi-Fi Kit and Avalue Renity Artemis Enterprise Kit) meant they could be weaponized to intercept network packets exchanged between anchors and the central server and stage traffic manipulation attacks.

Simply stated, the concept is to guesstimate the anchor coordinates and use them to manipulate the RTLS system's geofencing rules, effectively tricking the software into allowing access to restricted areas and even disrupting production environments. Even worse, by changing the position of tags and placing them within geofencing zones, an adversary can affect the shutdown of entire production lines by indicating that a worker is nearby even when no one is present. 

In another situation, the location data could be tampered with to place a worker outside of a geofencing zone, causing dangerous machinery to restart while a worker is nearby, posing serious safety risks. However, it is worth noting that doing so requires an attacker to either compromise a computer connected to that network or covertly add a rogue device to gain unauthorised access to the network.

Last but not the least, how to prevent these attacks?

To prevent AitM attacks, it is recommended to enforce network segregation and add a traffic encryption layer on top of existing communications. 

"Weak security requirements in critical software can lead to safety issues that cannot be ignored," researchers Andrea Palanca, Luca Cremona, and Roya Gordon said. "Exploiting secondary communications in UWB RTLS can be challenging, but it is doable."

Nozomi recommends that administrators of RTLS systems use firewalls to restrict access, intrusion detection systems, and SSH tunneling with packet synchronisation counter-values for data encryption.

Secure Boot Vulnerabilities Impact Bootloaders, Systems Compromised


About Secure Boost Bugs

Bootloaders that were in majority of the systems made in the last 10 years have been impacted by Secure Bost bypass vulnerabilities. 

Secure Boot is a mechanism made to prevent a device's boot process from threats, to bypass it will allow an attacker to execute arbitrary code before the operating system can load. 

It allows installation of stealthy and persistent malware. The Secure Boot vulnerabilities were found in the Eurosoft (CVE-2022-34301) CVE-2022-34303, New Horizon Datasys (CVE-2022-34302), and CryptoPro Secure Disk for BitLocker (CVE-2022-34303) bootloaders. 

As per Eclypsium (company) bootloaders are found in almost every device made in the past 10 years, this includes ARM and x86-64 devices.

How does the bugs work?

The CryptoPro Secure Disk and Eurosoft bootloader bugs contain signed UEFI shells, the hackers are able to bypass Secure Boot by exploiting built-in capabilities. For these security loopholes, one can easily exploit automated startup scripts. 

According to Eclypsium the bootloader contains a built-in bypass for Secure Boot that leaves Secure Boot on but disables the Secure Boot checks. This bypass can further enable even more complex evasions such as disabling security handlers. 

In this case, an attacker would not need scripting commands, and could directly run arbitrary unsigned code. To exploit any of these bugs, a hacker must have admin or root privileges on the targeted Linux and Windows system. 

But the company said that there are many ways to get these permissions on a device. The flawed bootloaders are signed by Microsoft. As per an advisory issued by the CERT/CC at Carnegie Mellon University, the tech giant has been working with vendors to address the flaws and it has restricted the certificates linked with the affected bootloaders. 

"In 2020, Eclypsium disclosed the existence of a vulnerability named BootHole, which affected all operating systems that used the GRUB2 bootloader with Secure Boot. Some vendors rushed to release patches in response to BootHole, but they caused many systems," says Security Week. 


Researcher Demonstrated How Tesla Key Card Feature Can be Exploited to Steal Cars

 

A researcher demonstrated how a Tesla key card functionality launched last year might be misused to add an unauthorised key that enables an attacker to access and start a vehicle. 

Martin Herfurt, an Austria-based member of the Trifinite research group that specialises in Bluetooth security, conducted the study. Herfurt's research focused on key card access modifications made by Tesla in August 2021, which removed the necessity for customers to place the key card on the central console after using it to open the vehicle. 

The researcher discovered that when a Tesla is opened through NFC using the key card, there is a 130-second window during which an attacker within the Bluetooth range of the targeted vehicle may add their own key. The attack exploits Tesla's VCSEC protocol, which manages communication between the automobile, the phone app, and the key fob. 

Findings by the researcher: 

During such an assault, the infotainment system makes no attempt to warn the victim that a new key has been inserted. According to the researcher, he tried the attack on the Tesla Model 3 and Model Y, but he believes it should also work on the newer Model S and Model X. At the recent Pwn2Own 2022 hacking competition, hackers won $75,000 for an attack targeting Tesla's infotainment system. Herfurt intended to show off his attack at Pwn2Own, but relay attacks were not permitted. 

In reality, he claimed to have identified the authorisation timer attack vector in September 2021 but had been keeping it for Pwn2Own. The researcher stated that he did not inform Tesla about his recent findings before revealing them since he considered the company needed to be aware of the problem. 
Following his disclosure, he received confirmation from others who reported a very issue to Tesla months ago that Tesla was aware of the vulnerability. 

According to the researcher, Tesla recommends using the PIN2Drive function, which requires customers to input a PIN before driving away, but he produced a video last week demonstrating how an attacker may overcome PIN2Drive. Tesla is yet to react to a comment request.

Herfurt is working on TeslaKee, a new smartphone application that is said to safeguard Tesla vehicles from these sorts of relay attacks. Herfurt demonstrated another approach to stealing a Tesla in May. The attacker utilised two Raspberry Pi devices to relay the radio signal between the Phone Key and an automobile over a considerable distance.

CVE-2021-26084: Critical Atlassian Confluence Flaw Exploited in the Wild

Atlassian has confirmed that malicious actors are actively exploiting a new Atlassian Confluence zero-day vulnerability tracked as CVE-2022-26134, designed to install web shells with no fix available at this time. 

Atlassian released a security advisory in which it has stated that CVE-2022-26134 is a critical unauthenticated, remote code execution vulnerability that is compromising Confluence Server (7.18.0 ) and Data Center(7.4.0). 

It said that all versions of Atlassian's corporate Wiki system, Confluence are hit by a serious bug under active exploitation. Experts indicate a possibility of Chinese threat actors being behind the attack. 

“Atlassian has been made aware of current active exploitation of a critical severity unauthenticated remote code execution vulnerability in Confluence Data Center and Server. Further details about the vulnerability are being withheld until a fix is available.” reads the advisory published by the company. 

As of now, there are no patches available for this vulnerability, thus Atlassian suggested its customers make their servers inaccessible by following these steps  restricting Confluence Server and Data Center instances from the internet and Disabling Confluence Server and Data Center instances.

The attack was reported by security firm Volexity, the company announced the availability of the security fixes for supported versions of Confluence within 24 hours (estimated time, by EOD June 3 PDT). It has been further noted that organizations that are using Atlassian Cloud (accessible via atlassian.net) are safe from this vulnerability. 

“After successfully exploiting the Confluence Server systems, the attacker immediately deployed an in-memory copy of the BEHINDER implant. This is an ever-popular web server implant with source code available on GitHub. BEHINDER provides very powerful capabilities to attackers, including memory-only webshells and built-in support for interaction with Meterpreter and Cobalt Strike…” reads the analysis published by Volexity.

“… As previously noted, this method of deployment has significant advantages by not writing files to disk. At the same time, it does not allow persistence, which means a reboot or service restart will wipe it out. Once BEHINDER was deployed, the attacker used the in-memory webshell to deploy two additional webshells to disk: CHINA CHOPPER and a custom file upload shell.”

Researchers: Tesla Cars, Bluetooth Locks, Vulnerable to Hackers

 

Hackers can remotely unlock millions of digital locks around the world, including those on Tesla cars, due to a flaw in Bluetooth technology, according to a cybersecurity firm. 

NCC Group researcher Sultan Qasim Khan was able to open and then drive a Tesla using a small relay device tied to a laptop, which spanned a wide gap between the Tesla and the Tesla owner's phone, according to a video shared with Reuters.

"This proves that any product relying on a trusted BLE connection is vulnerable to attacks even from the other side of the world," the UK-based firm said in a statement, referring to the Bluetooth Low Energy (BLE) protocol - technology used in millions of cars and smart locks which automatically open when in close proximity to an authorised device. 

Although Khan demonstrated the hack on a Tesla Model Y from 2021, NCC NSE 0.23 percent Group claims that any smart lock that uses BLE technology, including residential smart locks, may be unlocked in the same way. A request for comment from Tesla was not immediately returned. 

"In effect, systems that people rely on to guard their cars, homes, and private data are using Bluetooth proximity authentication mechanisms that can be easily broken with cheap off-the-shelf hardware," the firm stated. "This research illustrates the danger of using technologies for reasons other than their intended purpose, especially when security issues are involved". 

According to the NCC Group, such a vulnerability is not the same as a traditional bug that can be repaired with a software patch, and BLE-based authentication was not intended for usage in locking mechanisms.

SpringShell Attacks Target About One in Six Vulnerable Orgs

 

According to figures from one cybersecurity firm, about one out of every six firms affected by the Spring4Shell zero-day vulnerability has already been targeted by threat actors. 

The exploitation attempts occurred within the first four days of the severe remote code execution (RCE) issue, CVE-2022-22965, and the associated attack code was publicly disclosed. 37,000 Spring4Shell attacks were discovered over the weekend alone, according to Check Point, which generated the statistics based on their telemetry data. Software vendors appear to be the most hit industry, accounting for 28% of the total, possibly due to their high vulnerability to supply chain threats. 

Based on their visibility, Check Point ranks Europe #1 in terms of the most targeted region, with 20%. This suggests that the malicious effort to exploit existing RCE possibilities against vulnerable systems is well underway, and threat actors seem to be turning to Spring4Shell while unpatched systems are still exposed. North America accounts for 11% of Check Point's detected Spring4Shell attacks, while other entities have confirmed active exploitation in the United States. 

Spring4Shell was one of four flaws posted to the US Cybersecurity & Infrastructure Security Agency's (CISA) inventory of vulnerabilities known to be used in actual attacks yesterday. The agency has uncovered evidence of attacks on VMware products, in which the software vendor published security upgrades and alerts. 

Microsoft also released guidelines for detecting and preventing Spring4Shell attacks, as well as a statement that they are already analyzing exploitation attempts. Spring MVC and Spring WebFlux apps operating on JDK 9+ are affected by CVE-2022-22965, hence all Java Spring installations should be considered potential attack vectors. Spring Framework versions 5.3.18 and 5.2.2, as well as Spring Boot 2.5.12, were published by the vendor to address the RCE issue. 

As a result, upgrading to these versions or later is strongly advised. System administrators should also be aware of the remote code execution vulnerabilities in the CVE-2022-22963 and CVE-2022-22947 remote code execution flaws in the Spring Cloud Function and Spring Cloud Gateway. These flaws already have proof-of-concept exploits that are publicly available.

CISA: High-Severity Flaws in Schneider & GE Digital's SCADA Software

 

Schneider Electric's Easergy medium voltage protection relays are vulnerable to several vulnerabilities, according to the advisory by US Cybersecurity and Infrastructure Security Agency (CISA). 

The agency said in a bulletin on February 24, 2022, "Successful exploitation of these vulnerabilities may disclose device credentials, cause a denial-of-service condition, device reboot, or allow an attacker to gain full control of the relay. This could result in loss of protection to your electrical network."

Easergy P3 versions prior to v30.205 and Easergy P5 versions before v01.401.101 are affected by the two high-severity flaws. The following are the weaknesses in detail: 
  • CVE-2022-22722 (CVSS score: 7.5) - Use of hardcoded credentials that could be used to monitor and alter device traffic with the device.
  • CVE-2022-22723 and CVE-2022-22725 (CVSS score: 8.8) – A buffer overflow vulnerability that could lead to programme crashes and execution of arbitrary code by sending specially crafted packets to the relay over the network. 

Schneider Electric patched the weaknesses detected and reported by Red Balloon Security researchers Timothée Chauvin, Paul Noalhyt, and Yuanshe Wu as part of updates released on January 11, 2022. The alert comes less than ten days after CISA released another alert warning of several key vulnerabilities in Schneider Electric's Interactive Graphical SCADA System (IGSS) that, if exploited, could lead to data disclosure and loss of control of the SCADA system with IGSS running in production mode. 
 
In similar news, the US Federal Bureau of Investigation has issued a security alert for General Electric's Proficy CIMPLICITY SCADA software, alerting of two security flaws that might be exploited to expose sensitive information, gain code execution, and escalate local privileges. 

The advisories follow a report from industrial cybersecurity firm Dragos that discovered that 24 per cent of the total 1,703 ICS/OT vulnerabilities reported in 2021 had no fixes available, with 19 per cent having no mitigation, restricting operators from taking any steps to protect their systems from potential threats. 

Dragos also discovered malicious activity from three new groups that were discovered attacking ICS systems last year, including Kostovite, Erythrite, and Petrovite. Each of which targeted the OT environments of renewable energy, electrical utility, and mining and energy firms in Canada, Kazakhstan, and the United States.

SquirrelWaffle Adds a Spin of Fraud to Exchange Server Malspamming

 

Squirrelwaffle, ProxyLogon, and ProxyShell are being utilized against Microsoft Exchange Servers to conduct financial fraud via email hijacking. Sophos researchers revealed that a Microsoft Exchange Server that had not been fixed to safeguard it against a set of serious vulnerabilities identified last year was used to hijack email threads and disseminate malspam. 

On March 2, 2021, Microsoft released emergency updates to address zero-day vulnerabilities that could be exploited to take over servers. At the time, Hafnium, an advanced persistent threat (APT) group, was constantly exploiting the bugs, and other APTs swiftly followed suit. Despite the fact that the ProxyLogon/ProxyShell flaws are now widely known, some servers remain unpatched and vulnerable to assaults. 

Sophos has described an instance that combined Microsoft Exchange Server vulnerabilities with Squirrelwaffle, a malware loader that was first discovered in malicious spam operations last year. Malicious Microsoft Office documents or DocuSign content tacked on to phishing emails are frequently used to spread the loader. Squirrelwaffle is frequently used to fetch and execute CobaltStrike beacons via a VBS script if an intended victim has permitted macros in the compromised documents. 

According to Sophos, the loader was used in the recent campaign once the Microsoft Exchange Server had been compromised. By hijacking existing email threads between employees, the server of an undisclosed organisation was utilised to "mass distribute" Squirrelwaffle to internal and external email addresses. 

Email Hijacking can take a variety of forms. Social engineering and impersonation, such as an attacker posing as an executive to dupe accounting departments into signing off on a fraudulent transaction, or sending email blasts with links to malware payloads, can disrupt communication channels. The spam campaign was utilized to disseminate Squirrelwaffle in this example, but attackers also extracted an email thread and used the internal knowledge contained within to execute financial fraud. Customer information was obtained, and a victim organization was chosen. The attackers generated email accounts using a domain to reply to the email thread outside of the server, using a technique known as typo-squatting to register a domain with a name that was very similar to the victim. 

Sophos explained, "To add further legitimacy to the conversation, the attackers copied additional email addresses to give the impression that they were requesting support from an internal department. In fact, the additional addresses were also created by the attacker under the typo-squatted domain." 

The attackers attempted for six days to divert a legitimate financial transaction to a bank account they owned. The money was about to be processed, and the victim escaped the attack only because a bank involved in the transaction realized the transfer was most likely fake. 

Matthew Everts, Sophos researcher commented, "This is a good reminder that patching alone isn't always enough for protection. In the case of vulnerable Exchange servers, for example, you also need to check the attackers haven't left behind a web shell to maintain access. And when it comes to sophisticated social engineering attacks such as those used in email thread hijacking, educating employees about what to look out for and how to report it is critical for detection."

IP Spoofing Flaw Leaves Django REST Applications Vulnerable to DDoS Attacks

 

Attackers used an IP spoofing flaw in Django REST to bypass the framework's throttling function, which is designed to protect apps from mass requests. 

Mozilla, Red Hat, and Heroku, among others, use Django REST as a toolkit for constructing web APIs. It includes a throttling function that limits the number of API queries a client may make. Bot activity, denial-of-service attacks, and malicious actions such as brute-force attempts on login sites, one-time passwords, and password reset pages are all protected by this feature. 

IP addresses are used by Django REST to recognize clients and implement throttling request restrictions. Clients can, however, deceive the server and hide their IP address, according to security researcher Hosein Vita. 

He told The Daily Swig, “Django use WSGI (web server gateway interface) to communicate with web application and X-Forwarded-For HTTP header and REMOTE_ADDR WSGI variable are used to uniquely identify client IP addresses for throttling.” 

As a result, if the X-Forwarded-For header is included in a web request, the server will interpret it as the client's IP address. Vita was able to submit an endless number of requests with the same client by changing the X-Forwarded-For value. The approach only works for unauthenticated queries, according to Vita's bug report. 

APIs that require user authentication take both the user’s ID and the IP address into account when throttling, so IP spoofing is not enough to circumvent the request limits. According to Vita, the attack requires no specific server access, and an attacker who "can just see the website can abuse this method. 

Its immediate impact could be DDoS attacks caused by fraudulent requests flooding Django servers. However, it can also be used for other objectives, such as bypassing login page defences against brute-force attacks. Vita apparently identified the flaw while pen-testing an app with a one-time password login page. 

He stated, “You could log in [to the application] with OTP but I got blocked after many attempts. After my research, I used X-Forwarded-For header, and again I could send requests but after some attempts, again I got blocked.” 

The researcher added: “From my previous background in Django, I guessed it could get bypassed by changing the value of X-Forwarded-For header, and you could send 30 requests with each IP. Then I checked that in my Django API and it was correct.” 

The Django REST team was contacted by The Daily Swig for comment on the vulnerability. Meanwhile, Vita suggests using complementary strategies to protect applications from brute-force attacks. 

He added, “Always use other aspects of security measures as secondary methods. Use Captcha or other related methods to reduce attacks like this in important endpoints. For OTPs, use a token for each generated OTPs.”

The Log4j Incident Demonstrated Again That Publicly Disclosing 0-day Vulnerabilities Only Aids Intruders

 

On December 9, 2021, a (now-deleted) tweet pointing to a 0-day proof of concept (PoC) exploit for the Log4Shell vulnerability on GitHub set the internet ablaze, sending businesses rushing to mitigate, patch, and patch again as other PoCs surfaced. 

Public vulnerability disclosure – that is, revealing to the world the existence of a bug in a piece of software, a library, an extension, or another piece of software, and releasing a proof-of-concept (PoC) that exploits it – occurs frequently for vulnerabilities in a wide range of software, from the most esoteric to the most mundane (and widely used). 

Threat actors are the only ones who benefit from the public disclosure of 0-day PoCs, as per research and experience, because it puts enterprises in the awkward position of needing to remediate the issue without having anything solid to mitigate it with (i.e., a vendor's patch). 

There are several different types of responsible vulnerability disclosure systems available today. Some companies have an official vulnerability disclosure programme while others arrange and operate it through crowdsourced platforms. Companies typically offer money for information concerning flaws in their products (also known as "bug bounties"). 

Those disclosures usually follow a set of steps, and vendor patches have clearly stated release dates so that users have plenty of time to install them (90 days is the accepted standard for this). 

When the Log4Shell vulnerability was announced publicly, the disclosure procedure was already underway (as evidenced by the pull request on GitHub that appeared on November 30). The following is the timeline of the disclosure, according to information provided by the Apache Software Foundation:
  • November 24: The Log4j maintainers were informed 
  • November 25: The maintainers accepted the report, reserved the CV, and began researching a fix November 26: The maintainers communicated with the vulnerability reporter 
  • November 29: The maintainers communicated with the vulnerability reporter December 4: Changes were committed 
  • December 5: Changes were committed 
  • December 7: First release candidate created 
  • December 8: The maintainers communicated with the vulnerability reporter, made additional fixes, created a second release candidate 
  • December 9: Patch released 
While user comments on the Apache Log4j GitHub project page expressed dissatisfaction with the timeliness of the update, this is to be expected when it comes to patching vulnerabilities - as everyone keeps pointing out, after all, the patch was developed by volunteers. 

Probable reasons for releasing PoC 

There could be valid and logical reasons for releasing a 0-day proof-of-concept. The most prevalent of these is the breakdown of the vulnerability disclosure process: the vendor may not be or cease to be responsive, may judge the vulnerability to be minor enough to warrant a repair, or may take too long to fix it – or any combination of the above. 

In situations like these, security researchers frequently decide to make the PoC public for the "common good," i.e. to force vendors to release a patch quickly. Other factors could include publicity (especially if the researcher is associated with a security vendor) – nothing attracts more press attention than zero-day proof-of-concept exploits for a widely used piece of software, especially if no patch is available. 

However, it should be noted that the evidence against publishing proof-of-concept exploits is now substantial and overwhelming. According to a study conducted by Kenna Security, sharing proof-of-concept attacks mostly assists attackers. A presentation at Black Hat several years ago walked through the lifecycle of zero-days and how they were released and exploited, demonstrating that if proof-of-concept exploits aren't publicly disclosed, the vulnerabilities in question aren't discovered for an average of 7 years by anyone else (threat actors included).

Unfortunately, during the log4j scramble, this was discovered a little too late. Although the initial tweets and disclosures were quickly withdrawn, the harm had already been done. Even the most recent revelation, which resulted in the release of patch 2.17.1, generated so much criticism from the security community that the researcher apologized publicly for the publication's bad timing. 

It's encouraging to see that public disclosure of PoC exploits is becoming more common. Researchers who choose to jump the gun need to be criticized, but all must all work together to ensure that more rigorous disclosure mechanisms are in place for everyone so that the public PoC scenario is avoided the next time a vulnerability like Log4Shell is uncovered.

Telegram Exploited by Attackers to Spread Malware

 

Researchers discovered that cybercriminals are using the Echelon info stealer to attack the crypto-wallets of Telegram users in an attempt to deceive new or naïve members of a cryptocurrency discussion group on the messaging network. 

Researchers from SafeGuard Cyber's Division Seven threat analysis section discovered a sample of Echelon in a cryptocurrency-focused Telegram channel in October, according to an investigation published on Thursday. 

The malware used throughout the campaign is designed to exploit credentials from a variety of messaging and file-sharing channels, such as Discord, Edge, FileZilla, OpenVPN, Outlook, and even Telegram itself, as well as a variety of cryptocurrency wallets, which include AtomicWallet, BitcoinCore, ByteCoin, Exodus, Jaxx, and Monero. 

The campaign was a “spray and pray” effort: “Based on the malware and how it was posted, SafeGuard Cyber believes that it was not part of a coordinated campaign, and was simply targeting new or naïve users of the channel,” according to the report. 

Researchers discovered that attackers had been using the handle "Smokes Night" to disseminate Echelon on the channel, although it's unknown how successful they were. "The post did not appear to be a response to any of the surrounding messages in the channel," they added.

According to the researchers, additional users on the channel didn't even appear to detect anything strange or engage with the post. However, this does not imply that the malware did not reach consumers' devices, according to the experts. 

“We did not see anyone respond to ‘Smokes Night’ or complain about the file, though this does not prove that users of the channel did not get infected,” they wrote. 

The Telegram messaging platform has undoubtedly become a hotspot of activity for hackers, who've already taken advantage of its popularity and large attack surface by distributing malware on the network via bots, rogue accounts, and other methods.

Echelon was delivered to the cryptocurrency channel in the form of a.RAR file called "present).rar," which contained three files: "pass – 123.txt," a benign text document comprising a password; "DotNetZip.dll," a non-malicious class library and toolset for manipulating.ZIP files; and "Present.exe," the malicious executable for the Echelon credential stealer. 

The.NET payload also featured numerous characteristics that made it hard to identify or analyze, such as two anti-debugging capabilities that immediately terminate the process if a debugger or other malware analysis techniques are identified, and obfuscation utilizing the open-source ConfuserEx program. 

According to the researchers, additional characteristics of the malware include computer fingerprinting and the ability to take a screenshot of the victim's workstation. According to the researchers, the Echelon sample taken from the campaign uses a compressed.ZIP file to deliver passwords as well as other stolen data and screenshots back to a command-and-control server.

NSO Zero-Click iPhone Exploit Termed 'Incredible and Terrifying' by Researchers

 

Google has described how the surveillance firm NSO Group created an exploit that would allow the user of their software to acquire entry to an iPhone and install malware – and all without the victim ever clicking on a link. 

The US Department of Commerce put NSO Group on its "entity list" last month, effectively barring it from US marketplaces given the evidence that it provided spyware to other authorities, which used it to attack government officials, journalists, entrepreneurs, activists, academics, and embassy workers. Apple issued a permanent injunction prohibiting NSO from using any of its software, applications, or equipment in late November. 

Google's Project Zero (GPZ) has now assessed a comparatively new NSO 'zero-click' attack for iOS 14.7.1 and older, calling it "one of the most technically sophisticated exploits we've ever seen". 

The NSO's exploit was regarded as "incredible" and "terrifying" by GPZ's Ian Beer and Samuel Groß. The hack generates a "weird" emulated computing atmosphere within an iOS element that manages GIFs but does not ordinarily allow scripting. Nevertheless, this exploit allows the attacker to execute JavaScript-like code in that component to write to arbitrary memory regions - and therefore remotely hack an iPhone. 

Citizen Lab, a Canadian security firm, revealed the problem to Apple as part of its collaborative investigation with Amnesty International into NSO's Pegasus mobile spyware program, which can be loaded after jailbreaking an iPhone via an exploit. 

This September, Apple fixed the memory corruption flaw in the CoreGraphics component, identified as CVE-2021-30860, in iOS 14.8. 

GPZ's Beer and Groß said it showed "the capabilities NSO provides rival those previously thought to be accessible to only a handful of nation-states". 

 iMessage is the first point of contact for Pegasus on the iPhone. According to the research, this means that a person can be targeted simply by providing their phone number or AppleID username. 

The flaw in iMessage is due to the extra functionalities Apple allowed for GIF pictures. In iOS's ImageIO library, Apple employs a "fake gif" method to make standard GIF images loop indefinitely. This method also introduces over 20 more image codecs, providing attackers with a far bigger surface to attack. 

"NSO uses the "fake gif" trick to target a vulnerability in the CoreGraphics PDF parser," Beer and Groß explain. 

NSO discovered that powerful tool in Apple's usage of the JBIG2 standard for image compression and decompression. Originally, the standard was utilized in outdated Xerox scanners to efficiently convert photos from paper into PDF files only a few kilobytes in size. 

The emulated database design, which relied on the JBIG2 part of Apple's CoreGraphics PDF parser, was one of several clever methods NSO devised. Despite JBIG2's lack of scripting features, they were able to write to arbitrary memory addresses using an emulated computer environment and a scripting language similar to JavaScript. 

"JBIG2 doesn't have scripting capabilities, but when combined with a vulnerability, it does have the ability to emulate circuits of arbitrary logic gates operating on arbitrary memory," explains Beer and Groß. 

"The bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream. It's pretty incredible, and at the same time, pretty terrifying."

Magecart Attacks Surge in the Wild

 

According to a Cyberpion study, several of the world's top corporations in retail, finance, healthcare, power, and many other industries, including Fortune 500, Global 500, and governments, are struggling to avoid Magecart assaults. Magecart is a term used to describe a type of cyber attack wherein cybercriminals compromise third-party code (typically Javascript that runs in browsers) to grab, or scrape, details such as credit card information from web applications (e.g., online checkout software) or webpages that incorporate the code. 

Over the previous two years, the researchers examined over 30,000 flaws and discovered huge shortcomings in existing security platforms and mechanisms for detecting and mitigating Magecart assaults. 

There have also been significant gaps in firms revealing to their customers' security vulnerabilities or exploits happening throughout their digital supply chains, putting all linked organizations at risk of a breach. 

“Our conclusion from the analysis is that as of today, organizations fail to face Magecart threats and detect the vulnerabilities and exploits that hackers leverage to conduct these attacks,” said Cyberpion CEO Nethanel Gelernter. 

“Victims are often the last to know as it’s only later that organizations find that their data was sold or exploited, with the problem extending beyond any single vendor or client relationship. For enterprises, in particular, Magecart attacks pose a significant challenge because it is problematic to set up a solution at scale.” 

Alongside Web, skimming has also been on the surge. It is indeed a danger to online businesses and customers, with cyberattacks significantly affecting firms such as British Airways and Ticketmaster in 2018, Forbes in 2019, as well as local US government portals and messaging app Telegram in 2020. 

At least one of the top five firms in a variety of industries – retail, insurance, financial services, pharma, media, security, and others – were discovered to be susceptible or exploited. And over 1000 online stores are exposed, putting their consumers at risk of being skimmed. Many of the most widely circulated worldwide newspapers were discovered to be susceptible, frequently via their main page. 

Some weak or mistreated businesses deploy anti-Magecart solutions, however, they may be circumvented. Vendor architecture exposes numerous other linked businesses to Magecart, but suppliers frequently fail to notify customers early enough so that preventative action may be taken. In one example, a major internet advertising network impacted 15 worldwide insurance firms, as well as hundreds of smaller businesses.

Linux Foundation Patches Critical Critical Code Vulnerability

 

CVE-2021-43267 vulnerability is detailed as a heap overflow Transparent Inter-Process Communication (TIPC) module shipping with Linux kernels to let nodes in a group communicate with each other in a fault-proof way. 'While TIPC itself isn’t loaded automatically by the system and has to be enabled by end users, Van Amerongen said the ability to configure it from an unprivileged local perspective and the possibility of remote exploitation "makes this a dangerous vulnerability" for those that use it in their networks," reports Security Week. 

The flaw can be abused either locally or via remote code execution within a network framework to get kernel privileges, which allows a hacker to exploit an entire system. Experts discovered a bug in most attacks that used Microsoft's CodeQL, an open-source semantic code analysis engine that assists to identify security flaws. As per the experts, the flaw surfaced in the Linux kernel in September last year, after a MSG_CTYPTO (a new message type) was included to let actors distribute cryptographic codes. 

While investigating the code, expert Van Amerongen discovered a “clear-cut kernel heap buffer overflow," along with remote code execution hints. , Vulnerable TIPC module is loaded with main Linux distributions, however, it requires loading in order to trigger the vulnerability and enable the protocol. A patch was shipped by Linux foundation on October 29, confirming the existing vulnerability which affects kernel variants between 5.10 and 5.15. 

As per cybersecurity firm Sentinel One, it hasn't found any proof of vulnerability exploits in the wild. “This vulnerability can be exploited both locally and remotely. While local exploitation is easier due to greater control over the objects allocated in the kernel heap, remote exploitation can be achieved thanks to the structures that TIPC supports. As this vulnerability was discovered within a year of its introduction into the codebase, TIPC users should ensure that their Linux kernel version is not between 5.10-rc1 and 5.15,” says cybersecurity expert Van Amerongen.