Attacks involving the NetSupport RAT have become increasingly common, The Hacker News reports. More than 15 infections have been observed mostly in organizations in the education, government, and business sectors, in recent weeks, according to a report from VMware Carbon Black researchers. Fraudulent browser updates have been leveraged by threat actors to facilitate the distribution of the SocGholish downloader malware, also known as FakeUpdates, which then uses PowerShell to establish a remote server connection and facilitate the retrieval of a NetSupport RAT-containing ZIP archive file. Researchers also noted that the installation of NetSupport would then enable behavior tracking, file transfers, computer setting alterations, and lateral network movement. “The delivery mechanisms for the NetSupport RAT encompass fraudulent updates, drive-by downloads, utilization of malware loaders (such as GHOSTPULSE), and various forms of phishing campaigns,” said researchers. NetSupport RAT, which was once a remote access tool, was previously reported by Sucuri to have been spread through fake Cloudflare distributed denial-of-service protection pages.
A recently discovered vulnerability in Microsoft Office Word has raised concerns over the security of the popular productivity suite.
This security flaw, classified as a Cross-Site Scripting (XSS) vulnerability, allows attackers to execute arbitrary JavaScript code within a Word document.
The XSS Vulnerability
Various Office products, including Microsoft Word, offer a feature that allows users to insert external videos into documents through the “Online Videos” tab.
The XSS Vulnerability
When a user attempts to play an external video embedded in a document, the Office checks to determine whether the source of the external video is trustworthy.
This check involves applying a regular expression to the video’s URL, which includes trusted sources like YouTube.
If the source is deemed trustworthy, the Office requests to fetch data such as the video’s title or thumbnail. However, the vulnerability arises in how Office handles the video’s title within the HTML iframe tag.
The server responds with information, including the video’s title, description, and the HTML iframe tag.
The issue is that the server adds the video’s title to the “title” attribute of the iframe tag without proper validation.
As a result, attackers can manipulate the iframe tag by adding an “unload” attribute, enabling them to inject arbitrary JavaScript code.
Exploitation
To exploit this vulnerability, an attacker can create a YouTube video with a title that includes a payload for inserting the “onload” attribute, reads the PKsecurity report.
Then, they insert the URL of this malicious video into a Word document using the Online Videos tab. When the video is played, the injected JavaScript code is executed.
Exploitation
Here is a simplified overview of the steps an attacker would take to exploit this flaw:
Create a YouTube video with a payload in the title.
Insert the URL of the malicious video into a Word document.
Set up a web server to serve malicious JavaScript code.
Implications
This vulnerability allows attackers to execute arbitrary JavaScript code when a video embedded in a Word document is played.
While it may not seem immediately alarming, it’s worth noting that past critical exploits in Office applications often began with the execution of arbitrary JavaScript.
Exploiting this vulnerability could potentially lead to a critical Remote Code Execution (RCE) vulnerability if combined with a new vulnerable Uniform Resource Identifier (URI).
This makes it crucial for Microsoft to address and patch this issue promptly. The Microsoft Office XSS flaw underscores the importance of keeping software up to date and being cautious about the content embedded in documents.
Users should be aware of potential security risks associated with video content, especially when it comes from untrusted sources.
Ford recently identified a buffer overflow flaw in the Wi-Fi driver used by it in the SYNC 3 infotainment system. After the discovery, Ford quickly alerted about this flaw and disclosed the vulnerability publicly.
Car hijacking by hackers exploiting various functions of the car is known, but the real-world execution of such attacks remains challenging.
While there are certain vulnerabilities that cause immediate serious consequences, enabling threat actors to open and start the cars by exploiting the vulnerabilities remotely.
Since this system is used in the Ford and Lincoln vehicles, so, the successful exploitation of this flaw could enable threat actors to perform remote code execution.
This vulnerability has been tracked as “CVE-2023-29468,” and it was detected by a researcher who reported this flaw to the Wi-Fi module supplier, Texas Instruments (TI).
Summary: The TI WiLink WL18xx MCP driver does not limit the number of information elements (IEs) of type XCC_EXT_1_IE_ID or XCC_EXT_2_IE_ID that can be parsed in a management frame. Using a specially crafted frame, a buffer overflow can be triggered which can potentially lead to remote code execution.
TI PSIRT ID: TI-PSIRT-2022-120160
CVSS Score: The CVSS base score for this issue can range from 8.8 to 9.6.
Affected Products: WILINK8-WIFI-MCP8 version 8.5_SP3 and earlier
Ford’s Response
The SYNC3 infotainment system offers in-car WiFi, connectivity, voice commands, and third-party apps. The vulnerability concerns Ford customers, but no known exploits were reported.
Moreover, the attackers need physical proximity to an exposed, running engine with Wi-Fi enabled for a successful attack.
Ford’s investigation concludes that this vulnerability won’t impact vehicle safety, as the infotainment system firewall prevents control interference with steering, throttling, and braking.
Besides this, Ford assured that soon it will release the online software patch for USB installation. Meanwhile, customers who are concerned about the flaw can disable the Wi-Fi via SYNC 3’s Settings menu or check the vehicle’s SYNC 3 status online.
JWT is short for JSON Web Token, where JSON itself is short for JavaScript Object Notation.
JSON is a modernish way of representing structured data; its format is a bit like XML, and can often be used instead, but without all the opening-and-closing angle brackets to get in the way of legibility.
For example, data that might be recorded like this in XML…
Whether the JSON really is easier to read than the XML is an open question, but the big idea of JSON is that because the data is encoded as legal JavaScript source, albeit without any directly or indirectly executable code in it, you can parse and process it using your existing JavaScript engine, like this:
The output string undefined above merely reflects the fact that console.log() is a procedure – a function that does some work but doesn’t return a value. The word Sophos is printed out as a side-effect of calling the function, while undefined denotes what the function calculated and sent back: nothing.
The popularity of JavaScript for both in-browser and server-side programming, plus the visual familiarity of JSON to JavaScript coders, means that JSON is widely used these days, especially when exchanging structured data between web clients and servers.
And one popular use of JSON is the JWT system, which isn’t (officially, at any rate) read aloud as juh-witt, as it is written, but peculiarly pronounced jot, an English word that is sometimes used to refer the little dot we write above above an i or j, and that refers to a tiny but potentially important detail.
Authenticate strongly, then get a temporary token
Loosely speaking, a JWT is a blob of encoded data that is used by many cloud servers as a service access token.
The idea is that you start by proving your identity to the service, for example by providing a username, password and 2FA code, and you get back a JWT.
The JWT sent back to you is a blob of base64-encoded (actually, URL64-encoded) data that includes three fields:
Which crytographic algorithm was used in constructing the JWT.
What sort of access the JWT grants, and for how long.
A keyed cryptographic hash of the first two fields, using a secret key known only to your service provider.
Once you’ve authenticated up front, you can make subsequent requests to the online service, for example to check a product price or to look up an email address in a database, simply by including the JWT in each request, using it as a sort-of temporary access card.
Clearly, if someone steals your JWT after it’s been issued, they can play it back to the relevant server, which will typically give them access instead of you…
…but JWTs don’t need to be saved to disk, usually have a limited lifetime, and are sent and received over HTTPS connections, so that they can’t (in theory at least) easily be sniffed out or stolen.
When JWTs expire, or if they are cancelled for security reasons by the server, you need to go through the full-blown authentication process again in order to re-establish your right to access the service.
But for as long they’re valid, JWTs improve performance because they avoid the need to reauthenticate fully for every online request you want to make – rather like session cookies that are set in your browser while you’re logged into a social network or a news site.
Security validation as infiltration
Well, cybersecurity news today is full of a revelation by researchers at Palo Alto that we’ve variously seen described as a “high-severity flaw” or a “critical security flaw” in a popular JWT implementation.
In theory, at least, this bug could be exploited by cybercriminals for attacks ranging from implanting unauthorised files onto a JWT server, thus maliciously modifying its configuration or modifying the code it might later use, to direct and immediate code execution inside a victim’s network.
Simply put, the act of presenting a JWT to a back-end server for validation – something that typically happens at every API call (jargon for making a service request) – could lead malware being implanted.
But here’s the good news:
The flaw isn’t intrinsic to the JWT protocol. It applies to a specific implementation of JWT called jsonwebtoken from a group called Auth0.
The bug was patched three weeks ago. If you’ve updated your version of jsonwebtoken from 8.5.1 or earlier to version 9.0.0, which came out on 2022-12-21, you’re now protected from this particular vulnerability.
Cybercriminals can’t directly exploit the bug simply by logging in and making API calls. As far as we can see, although an attacker could subsequently trigger the vulnerability by making remote API requests, the bug needs to be “primed” first by deliberately writing a booby-trapped secret key into your authentication server’s key-store.
According to the researchers, the bug existed in the part of Auth0’s code that validated incoming JWTs against the secret key stored centrally for that user.
As mentioned above, the JWT itself consists of two fields of data denoting your access privileges, and a third field consisting of the first two fields hashed using a secret key known only to the service you’re calling.
To validate the token, the server needs to recalculate the keyed hash of those first two JWT fields, and to confirm the hash that you presented matches the hash it just calculated.
Given that you don’t know the secret key, but you can present a hash that was computed recently using that key…
…the server can infer that you must have acquired the hash from the authentication server in the first place, by proving your identity up front in some suitable way.
Data type confusion
It turns out that the hash validation code in jsonwebtoken assumes (or, until recently, assumed) that the secret key for your account in the server’s own authentication key-store really was a cryptographic secret key, encoded in a standard text-based format such as PEM (short for privacy enhanced mail, but mainly used for non-email purposes these days).
If you could somehow corrupt a user’s secret key by replacing it with data that wasn’t in PEM format, but that was, in fact, some other more complex sort of JavaScript data object…
…then you could booby-trap the secret-key-based hash validation calculation by tricking the authentication server into running some JavaScript code of your choice from that infiltrated “fake key”.
Simply put, the server would try to decode a secret key that it assumed was in a format it could handle safely, even if the key wasn’t in a safe format and the server couldn’t deal with it securely.
Note, however, that you’d pretty much need to hack into the secret key-store database first, before any sort of truly remote code execution trigger would be possible.
And if attackers are already able to wander around your network to the point that they can not only poke their noses into but also modify your JWT secret-key database, you’ve probably got bigger problems than CVE-2022-23539, as this bug has been designated.
What to do?
If you’re using an affected version of jsonwebtoken, update to version 9.0.0 to leave this bug behind.
However, if you’ve now patched but you think crooks might realistically have been able to pull off this sort of JWT attack on your network, patching alone isn’t enough.
In other words, if you think you might have been at risk here, don’t just patch and move on.
Use threat detection and response techniques to look for holes by which cybercriminals could get far enough to attack your network more generally…
…and make sure you don’t have crooks in your network anyway, even after applying the patch.
The open-source jsonwebtoken (JWT) library is affected by a high-severity security flaw that could lead to remote code execution.
The open-source JsonWebToken (JWT) library is affected by a high-severity security flaw, tracked as CVE-2022-23529 (CVSS score: 7.6), that could lead to remote code execution.
The package is maintained by Auth0, it had over 9 million weekly downloads as of January 2022 and it is used by more than 22.000 projects.
The flaw was discovered by Unit 42 researchers, it can be exploited by threat actors by tricking a server into verifying a maliciously crafted JSON web token (JWT) request.
“By exploiting this vulnerability, attackers could achieve remote code execution (RCE) on a server verifying a maliciously crafted JSON web token (JWT) request.” reads the advisory published by Palo Alto Networks.“With that being said, in order to exploit the vulnerability described in this post and control the secretOrPublicKey value, an attacker will need to exploit a flaw within the secret management process.”
JsonWebToken is an open-source JavaScript package that allows users to verify/sign JSON web tokens (JWT).
The flaw impacts JsonWebToken package version 8.5.1 or an earlier version, the JsonWebToken package version 9.0.0 addressed the issue.
“For versions <=8.5.1 of jsonwebtoken library, if a malicious actor has the ability to modify the key retrieval parameter (referring to the secretOrPublicKey argument from the readme link) of the jwt.verify() function, they can gain remote code execution (RCE).” reads the advisory published on GitHub.“You are affected only if you allow untrusted entities to modify the key retrieval parameter of the jwt.verify() on a host that you control.”
Vulnerabilities in open-source projects are very dangerous, threat actors could exploit them as part of supply chain attacks that can impact any projects relying on them.
“Open source projects are commonly used as the backbone of many services and platforms today. This is also true for the implementation of sensitive security mechanisms such as JWTs, which play a huge role in authentication and authorization processes.” concludes Palo Alto. “Security awareness is crucial when using open source software. Reviewing commonly used security open source implementations is necessary for maintaining their dependability, and it’s something the open source community can take part in.”
Below is the timeline for this vulnerability:
July 13, 2022 – Unit 42 researchers sent a disclosure to the Auth0 team under responsible disclosure procedures
July 27, 2022 – Auth0 team updated that the issue was under review
Aug. 23, 2022 – Unit 42 researchers sent an update request
Aug. 24, 2022 – Auth0 team updated that the engineering team was working on the resolution
Dec. 21, 2022 – A patch was provided by the Auth0 engineering team
There is a new exploit chain dubbed, OWASSRF that threat actors are actively exploiting to gain arbitrary code execution through Outlook Web Access (OWA) on vulnerable servers that bypasses ProxyNotShell URL rewrite mitigations.
A recent investigation by CrowdStrike Services found that Microsoft Exchange ProxyNotShell vulnerabilities are probably enabled the common entry vector for several Play ransomware intrusions:-
The relevant logs were reviewed by CrowdStrike and no evidence of initial access exploiting CVE-2022-41040 was found.
ProxyNotShell and Exchange Architecture Primer
There are two major components that make up a Microsoft Exchange server:-
The frontend
The backend
Exchange Architecture
All client connections are handled by the frontend, which proxies any given request to the backend according to the request. Here in this scenario the specific requests made to the frontend, like URLs, are dealt with by backend services.
Exchange Mailbox Server
A ProxyNotShell attack targets the Remote PowerShell service, which in this case is the backend service that is targeted. It is known this kind of vulnerability is referred to as an SSRF (Server-Side Request Forgery) vulnerability.
The CVE-2022-41082 vulnerability has been exploited by ransomware operators in order to execute arbitrary commands on compromised servers using Remote PowerShell.
OWASSRF PoC exploit leak
POC code for an exploit method based on Play ransomware logging was currently under development by CrowdStrike security researchers.
A recent discovery has shown that an attacker has downloaded all of the tools from an open repository, uploaded them in a MegaUpload link, and made them accessible to the public via the Twitter site.
CrowdStrike researchers replicated the log files generated in recent Play ransomware attacks using a Python script from the leaked toolkit, named poc.py, that was included in the leaked toolkit.
Recommendations from CrowdStrike
Here below we have mentioned all the recommendations offered by CrowdStrike:-
Since the URL rewrite mitigations for ProxyNotShell do not function against this exploit method, organizations should apply the Exchange patches of November 8, 2022.
The KB5019758 patch should be applied as soon as possible, but if this cannot be done, then you should disable OWA until you are able to apply it.
Make sure to disable remote PowerShell for non-administrative users in accordance with Microsoft’s recommendations.
Implement the use of advanced endpoint detection and response (EDR) solutions on each and every endpoint.
Utilize the script developed by CrowdStrike Services to check for signs of exploitation on Exchange servers visible in IIS logs and Remote PowerShell logs.
Take into account application-level controls, such as firewalls for web applications, as well as system-level controls.
Ensure that the X-Forwarded-For header in the HTTP request has been configured to log the true IP address of the external proxy server.
It has recently been discovered by researchers that Windows has a vulnerability that allows code execution that rivals EternalBlue in terms of potential. It is possible for an attacker to execute malicious code without authentication by exploiting this newly-tracked vulnerability CVE-2022-37958.
It is possible to exploit this vulnerability in a wormable way, which can lead to a chain reaction that can impact other systems that are vulnerable, and a new attack can be launched.
A greater range of network protocols is affected by this vulnerability as opposed to the earlier version, which gave attackers more flexibility.
Successful exploitation of this vulnerability allows any Windows application protocol that accesses the NEGOEX protocol may enable an attacker to remotely execute arbitrary code.
Despite the list of protocols that have been identified, there could be other protocols and standards that are affected as well.
On a target system, there is no user input or authentication required by a victim in order for this vulnerability to succeed. This vulnerability has been classified by Microsoft as “Critical,” with a maximum severity for all categories.
As a result, CVSS 3.1 now has an overall score of 8.1 out of 10. It is important to note that systems with unpatched default configurations are vulnerable to this flaw.
The reclassification was performed by X-Force Red in accordance with its responsible disclosure policy with Microsoft.
Recommendations
For the time being, IBM won’t release the full technical details regarding the vulnerabilities and patches until Q2 2023, in order to give defenders a chance and enough time to apply them.
Security Intelligence recommends that users and administrators apply the patch as soon as possible due to the widespread use of SPNEGO, which ensures that they are protected.
All systems running Windows 7 and newer are compatible with this fix, which is part of the security updates for September 2022.
Moreover, X-Force Red recommends the following additional recommendations:-
Identify which services are exposed to the internet, such as SMB and RDP.
You should continuously monitor your attack surface, including Windows Authentication-enabled servers.
In the event that the patch cannot be applied, set Kerberos or Net-NTLM as the default authentication providers on Windows and remove Negotiate as the default authentication provider.
The majority of major automobile manufacturers have addressed vulnerability issues that would have given hackers access to their vehicles to perform the following activities remotely:-
Lock the car
Unlock the car
Start the engine
Press the horn
Flas the headlights
Open the trunk of certain cars made after 2012
Locate the car
Flaw in SiriusXM
SiriusXM, one of the most widely used connected vehicle platforms available on the market, has a critical bug in its platform that affects all major vehicle brands.
There is a particular interest among security researchers in the area of connected cars, like Yuga Labs’ Sam Curry. In fact, he’s the one who was responsible for discovering a security hole in the connected cars of major car manufacturers during his routine research.
More car hacking!
Earlier this year, we were able to remotely unlock, start, locate, flash, and honk any remotely connected Honda, Nissan, Infiniti, and Acura vehicles, completely unauthorized, knowing only the VIN number of the car.
There are a number of car manufacturers who use Sirius XM telematics and infotainment systems as a part of their vehicle technology.
Affected Car Brands
Here below we have mentioned the brands’ names that are affected due to this critical bug in SiriusXM:-
Acura
BMW
Honda
Hyundai
Infiniti
Jaguar
Land Rover
Lexus
Nissan
Subaru
Toyota
Vulnerability Analysis
During the process of analyzing the data, it was found that there is a domain (http://telematics(.)net) that is used during the vehicle enrollment process for the remote management of Sirius XM.
The flaw is associated with the enrollment process for SiriusXM’s remote management functionality which results in the vehicle being tampered with.
There is not yet any technical information available about the findings of the researchers at the present time, since they haven’t shared anything in detail.
Upon further analysis of the domain, it becomes apparent that the Nissan Car Connected App is one of the most plentiful and frequently referenced apps in this domain.
In order for the data exchanged through the telematics platform to be authorized, the vehicle identification number (VIN) only needs to be used. The VIN of the vehicle can therefore be used to carry out a variety of commands by anyone who knows the number.
The next step would be to log in to the application later on, and then the experts examined the HTTPS traffic that came from a Nissan car owner.
Since exploiting this involved many steps, we took all of the requests necessary to exploit this and put it into a python script which only needed the victim's email address. After inputting this, you could then execute all commands on the vehicle and takeover the actual account. pic.twitter.com/Bz5G5ZvHro
Researchers discovered one HTTP request during the scan in which they conducted a deep analysis.
It is possible to obtain a bearer token return and a “200 OK” response by passing a VPN prefixed ID through as a customerID in the following way:-
Using the Authorization bearer in an HTTP request, researchers attempted to obtain information about the user profile of the victim and, as a result, they successfully retrieved the following information:-
Name
Phone number
Address
Car details
In addition to this, the API calls used by SiriusXM for its telematics services worked even if the user did not have an active subscription with SiriusXM.
As long as the developers or owners are not involved in the process of securing a vulnerable app, it is impossible to guarantee the security of that app. This is why they should be the only ones who can issue security updates and patches.
Recommendations
Here below we have mentioned the recommendations made by the security analysts:-
Ensure that you do not share the VIN number of your car with unreliable third parties.
In order to protect your vehicle from thieves, it is imperative to use unique passwords for each app connected to the vehicle.
Keep your passwords up-to-date by changing them on a regular basis.
Keeping your system up-to-date should be a priority for users.
A security flaw in the Galaxy Store allows attackers to trigger remote code execution on affected smartphones.
The now patched vulnerability, which affects Galaxy Store version 4.5.32.4, relates to a cross-site scripting (XSS) bug that occurs when handling certain deep links. An independent security researcher has been credited with reporting the issue.
Vulnerability Details
The now-patched vulnerability is related to a cross-site scripting (XSS) flaw that occurs when handling specific deep links and it affects Galaxy Store version 4.5.32.4. The problem was first reported by an independent security researcher.
Particularly, deeplink can be called from another application or from a browser. The store receives appropriate deeplinks, it will process and show them in a webview.
In this case, by failing to secure the deeplink, the attacker is able to run JS code in the Galaxy Store application’s webview context whenever a user hits a link from a website that contains the deeplink.
The expert focuses on deep links configured for Samsung’s Marketing & Content Service (MCS).
Although the Samsung MCS Direct Page website was extracting the argument from the url and displaying it on the website, it did not encrypt, which resulted in an XSS problem.
“We can see the website is processing the abc, def parameters and displaying as above without encoding, the url is passed directly to href this is very dangerous and will cause XSS.” reads the advisory published by SSD Secure Disclosure.
Experts observed two functions ‘downloadApp’ and ‘openApp’ here these two functions will get the app id and download them from the store or open them.
This indicates that these two functions can be called using JS code. In this case, an attacker has the ability to execute arbitrary code by injecting it into the MCS website.
“To be able to successfully exploit the victim’s server, it is necessary to have HTTPS and CORS bypass of Chrome,” advisory published by SSD Secure Disclosure
Affected Products and Patch Available
The vulnerability impacts Galaxy Store version 4.5.32.4.
Therefore, Samsung has issued patches that are now in wide circulation for all Samsung devices.
Security researchers devised a technique, dubbed GhostTouch, to remotely control touchscreens using electromagnetic signals.
A team of researchers from Zhejiang University and Technical University of Darmstadt devised a technique, dubbed GhostTouch, to remotely control capacitive touchscreens using electromagnetic signals.
According to the experts, GhostTouch is the first active contactless attack against capacitive touchscreens.
GhostTouch uses electromagnetic interference (EMI) to remotely inject fake touch points into a capacitive device. The researchers demonstrated how to inject two types of basic touch events, taps and swipes, into targeted locations of the touchscreen. The events allowed the researchers to control the devices (i.e. answering an eavesdropping phone call, pressing the button, swiping up to unlock), the attack technique was successful on nine smartphone models.
“We can inject targeted taps continuously with a standard deviation of as low as 14.6 x 19.2 pixels from the target area, a delay of less than 0.5s and a distance of up to 40mm. We show the real-world impact of the GhostTouch attacks in a few proof-of-concept scenarios, including answering an eavesdropping phone call, pressing the button, swiping up to unlock, and entering a password.” reads the research paper published by the academics. “Finally, we discuss potential hardware and software countermeasures to mitigate the attack.”
The GhostTouch system consists of two components, a touch injector and a phone locator. The touch injector is used to inject touch events into the touchscreen and includes a signal generator, an amplifier, an on/off switch, and a receiving antenna array. The phone locator is used to identify the position of the touchscreen and consists of a sensing antenna array, a data acquisition device, and a location calculator.
The experimental lab setup up by the researchers is composed of an electrostatic gun used to generate a strong pulse signal which is sent to an antenna to transmit an electromagnetic field to the touchscreen.
The experts tested the technique against nine different smartphone models, including Galaxy A10s, Huawei P30 Lite, Honor View 10, Galaxy S20 FE 5G, Nexus 5X, Redmi Note 9S, Nokia 7.2, Redmi 8, and an iPhone SE (2020).
“We demonstrate the feasibility of this attack in the real world.” concludes the paper. “In places like a cafe, library, meeting room, or conference lobbies, people might place their smartphone face-down on the table2. An attacker may embed the attack equipment under the table and launch attacks remotely. For example, an attacker may impersonate the victim to answer a phone call which would eavesdrop the private conversation, or visit a malicious website.”
The researchers provided a series of countermeasures to neutralize the attack, including adding electromagnetic shielding to block EMI, reinforcing the touchscreen, improving the detection algorithm of the touchscreen, and forcing some form of authentication for the execution of high-risk actions.
Researchers warn of a remote access trojan called DCRat (aka DarkCrystal RAT) that is available for sale on Russian cybercrime forums.
Cybersecurity researchers from BlackBerry are warning of a remote access trojan called DCRat (aka DarkCrystal RAT) that is available for sale on Russian cybercrime forums. The DCRat backdoor is very cheap, it appears to be the work of a lone threat actor that goes online with the monikers of “boldenis44,” “crystalcoder,” and Кодер (“Coder”). Prices for the backdoor start at 500 RUB ($5) for a two-month license, 2,200 RUB ($21) for a year, and 4,200 RUB ($40) for a lifetime subscription.
“Sold predominantly on Russian underground forums, DCRat is one of the cheapest commercial RATs we’ve ever come across. The price for this backdoor starts at 500 RUB (less than 5 GBP/US$6) for a two-month subscription, and occasionally dips even lower during special promotions. No wonder it’s so popular with professional threat actors as well as script kiddies.” reads the report published by BlackBerry.
The author implemented an effective malware and continues to efficiently maintain it. The researchers pointed out that the price for this malware is a fraction of the standard price such RAT on Russian underground forums.
DCRat first appeared in the threat landscape in 2018, but a year later it was redesigned and relaunched.
DCRat is written in .NET and has a modular structure, affiliates could develop their own plugins by using a dedicated integrated development environment (IDE) called DCRat Studio.
The modular architecture of the malware allows to extend its functionalities for multiple malicious purposes, including surveillance, reconnaissance, information theft, DDoS attacks, and arbitrary code execution.
The DCRat consists of three components:
A stealer/client executable
A single PHP page, serving as the command-and-control (C2) endpoint/interface
An administrator tool
“All DCRat marketing and sales operations are done through the popular Russian hacking forum lolz.guru, which also handles some of the DCRat pre-sales queries. DCRat support topics are made available here to the wider public, while the main DCRat offering thread is restricted to registered users only.” continues the report.
The malware is under active development, the author announces any news and updates through a dedicated Telegram channel that had approximately 3k subscribers.
DCRat Telegram announcing discounts and price specials (source BlackBerry)
During recent months, the researchers ofter observed DCRat clients being deployed with the use of Cobalt Strike beacons through the Prometheus TDS (traffic direction system).
DCRat also implements a kill switch, which would render all instances of the DCRat administrator tool unusable, irrespective of subscriber license validity.
The Administrator tool allows subscribers to sign in to an active C2 server, configure (and generate) builds of the DCRat client executable, execute commands on infected systems
Experts concluded that the RAT is maintained daily, which means that the author is working on this project full-time.
“There are certainly programming choices in this threat that point to this being a novice malware author who hasn’t yet figured out an appropriate pricing structure. Choosing to program the threat in JPHP and adding a bizarrely non-functional infection counter certainly point in this direction. It could be that this threat is from an author trying to gain notoriety, doing the best with the knowledge they have to make something popular as quickly as possible.” concludes the report that also includes Indicators of Compromise (IoCs). “While the author’s apparent inexperience might make this malicious tool seem less appealing, some could view it as an opportunity. More experienced threat actors might see this inexperience as a selling point, as the author seems to be putting in a lot of time and effort to please their customers.”
Wyze Cam devices are affected by three security vulnerabilities that can allow attackers to takeover them and access camera feeds.
Bitdefender researchers discovered three security vulnerabilities in the popular Wyze Cam devices that can be exploited by threat actors to execute arbitrary code and access camera feeds.
The three flaws reported by the cybersecurity firm are:
A stack-based buffer overflow, tracked as CVE-2019-12266, which could lead to remote control execution.
An unauthenticated access to contents of the SD card
A remote attacker could exploit the CVE-2019-9564 flaw to take over the device, including turning on/off the camera.
An attacker could chain the above issue with the CVE-2019-12266 flaw to access live audio and video feeds.
The flaws were reported to Wyze in May 2019, the company addressed the CVE-2019-9564 and CVE-2019-12266 flaws in September 2019 and November 2020, respectively.
The vendor addressed the unauthenticated access to the content of the SD card with the release of firmware updates on January 29, 2022.
According to the experts, there are 3 version of Wyze Cam devices on the market and the first one has been discontinued and will not receive security updates to address the flaws.
“The analyzed device comes in several versions: Wyze Cam version 1, Wyze Cam Black version 2, as well as Wyze Cam version 3. We learned that, while versions 2 and 3 have been patched against these vulnerabilities, version 1 has been discontinued and is no longer receiving security fixes.” reads the report published by the security firm. “Customers who keep using Wyze Cam version 1 are no longer protected and risk having their devices exploited.“
Bitdefenders also provided the following recommendations to prevent attacks against IoT devices:
“Home users should keep a close eye on IoT devices and isolate them as much as possible from the local or guest network,” reads the post. “This can be done by setting up a dedicated SSID exclusively for IoT devices, or by moving them to the guest network if the router does not support the creation of additional SSIDs.”
The flaws can allow remote attackers to manipulate the power of millions of enterprise devices carrying out extreme cyber-physical attacks.
Uninterruptible power supply (UPS) devices provide emergency backup power for mission-critical systems.
“If exploited, these vulnerabilities, dubbed TLStorm, allow for complete remote take-over of Smart-UPS devices and the ability to carry out extreme cyber-physical attacks. According to Armis data, almost 8 out of 10 companies are exposed to TLStorm vulnerabilities.” reads the analysis published by Armis.
APC has over 20 million devices worldwide, according to the researchers, almost 8 out of 10 companies are exposed to TLStorm vulnerabilities.
Two of the TLStorm vulnerabilities reside in the TLS implementation used by Cloud-connected Smart-UPS devices, while the third one is a design flaw in the firmware upgrade process of Smart-UPS devices.
The researchers discovered that the firmware upgrades are not properly signed and validated.
This third flaw could be exploited by an attacker to achieve persistence by planting a malicious update on vulnerable UPS devices.
Below is the list of the flaws discovered by the experts:
CVE-2022-22806 – TLS authentication bypass: A state confusion in the TLS handshake leads to authentication bypass, leading to remote code execution (RCE) using a network firmware upgrade.
CVE-2022-22805 – TLS buffer overflow: A memory corruption bug in packet reassembly (RCE).
CVE-2022-0715 – Unsigned firmware upgrade that can be updated over the network (RCE).
An attacker can trigger one of the above issues to gain remote code execution on vulnerable devices and interfere with the operation of the UPS to cause physical damage.
“The fact that UPS devices regulate high voltage power, combined with their Internet connectivity—makes them a high-value cyber-physical target. In the television series Mr. Robot, bad actors cause an explosion using an APC UPS device.” continues Armis. “However, this is no longer a fictional attack. By exploiting these vulnerabilities in the lab, Armis researchers were able to remotely ignite a Smart-UPS device and make it literally go up in smoke.”
Experts pointed out that vulnerabilities in the firmware upgrade process are often abused by sophisticated APT groups.
Armis reported the flaws to Schneider Electric’s APC on October 31, 2021, the vendor addressed them with the release of Patch Tuesday security updates on March 8, 2022.
“UPS devices, like many other digital infrastructure appliances, are often installed and forgotten. Since these devices are connected to the same internal networks as the core business systems, exploitation attempts can have severe implications.” concludes the report. It’s important for security professionals to have complete visibility of all assets, along with the ability to monitor their behavior, in order to identify anomalies and/or exploit attempts. However traditional security solutions do not cover these assets. As a result, they remain “unseen” and therefore expose the organization to significant risk.”
Researchers disclose a now-patched remote code execution (RCE) vulnerability in the Apache Cassandra database software.
JFrog researchers publicly disclosed details of a now-patched high-severity security vulnerability (CVE-2021-44521) in Apache Cassandra database software that could be exploited by remote attackers to achieve code execution on affected installations.
Apache Cassandra is an open-source NoSQL distributed database used by thousands of companies.
“JFrog’s Security Research team recently disclosed an RCE (remote code execution) issue in Apache Cassandra, which has been assigned to
(CVSS 8.4).” reads the analsyis published by JFrog. “This Apache security vulnerability is easy to exploit and has the potential to wreak havoc on systems, but luckily only manifests in non-default configurations of Cassandra.”
Cassandra offers the functionality of creating user-defined-functions (UDFs) that allow to perform custom processing of data in the database.
Admins can use Java and JavaScript to write UDFs. In JavaScript it leverages the Nashorn engine in the Java Runtime Environment (JRE) which is not guaranteed to be secure when accepting untrusted code
JFrog researchers that discovered that when the configuration for user-defined functions (UDFs) are enabled, threat actors could leverage the Nashorn engine to escape the sandbox and achieve remote code execution.
“For example, running the following Nashorn JavaScript code allows execution of an arbitrary shell command –
Cassandra’s development team decided to implement a custom sandbox around the UDF execution which uses two mechanisms to restrict the UDF code” states the report.“
Experts noticed that the exploitation is possible when the cassandra.yaml configuration file contains the following definitions:
enable_user_defined_functions: true
enable_scripted_user_defined_functions: true
enable_user_defined_functions_threads: false
“When the option is set to false, all invoked UDF functions run in the Cassandra daemon thread, which has a security manager with some permissions. We will show how to abuse these permissions to achieve sandbox escape and RCE.” continues the analysis.
Experts shared a PoC to create a new file named “hacked” on the Cassandra server
Apache released versions 3.0.26, 3.11.12, and 4.0.2 to address the vulnerability, it adds a new flag “allow_extra_insecure_udfs” that’s set to false by default, it prevents turning off the security manager and blocks access to java.lang.System..
There’s a remote code execution hole in Adobe e-commerce products – and cybercrooks are already exploiting it.
Using the Adobe Commerce online selling platform?
Using Magento, the free, open-source variant of the same product?
Buying products from online stores that use either of these?
Using online services that themselves use services that (…repeat up the supply chain as needed…) ultimately depend upon Magento or Adobe’s paid version?
If so, make sure that the site where Magento or Adobe Commerce is actually running has downloaded and applied Adobe’s latest patches.
Note that these are so-called out-of-band updates, meaning that they’re new enough not to have made it into last week’s regular Patch Tuesday updates, but critical enough not to be left until next month’s Patch Tuesday comes round.
Adobe has released security updates for Adobe Commerce and Magento Open Source. These updates resolve a vulnerability rated critical. Successful exploitation could lead to arbitrary code execution.
Adobe is aware that CVE-2022-24086
has been exploited in the wild in very limited attacks targeting Adobe Commerce merchants.
Upgrade now
Of course, the words “limited attacks targeting merchants” shown above don’t automatically imply that “minimal damage has been done”.
Also, until we know what the attackers did when they exploited this hole, we can’t tell how much data they made off with, how many users might be affected, or what follow-up crimes – such as identity theft, password recovery and account takeover – the crooks might be able to try next.
According to Adobe, it seems that any Adobe Commerce or Magento installation running a version later than 2.3.3 that hasn’t received the latest patches is vulnerable.
The patches provided are listed as tested for all of these versions: 2.3.3-p1 to 2.3.7-p2, and 2.4.0 to 2.4.3-p1.
Quite what version number will show up after patching we can’t tell you; the patch files themselves are identified as 2.4.3-p1_v1, so our assumption is that’s the version string you’ll see.
