NVIDIA GeForce software, Studio, RTX/Quadro, NVS, and Tesla running Windows and Linux are all affected by this update, covering driver branches R450, R470, and R510. Here are the lists for Windows and Unix/Linux for reference for driver branch histories.
The latest release also covers updates for already unsupported GTX 600 and GTX Kepler-series cards. This is NVIDIA honoring its promise of continuing to provide support for these cards until September 2024—three years after the October 2021 end-of-support date.
Let’s look at each of the vulnerabilities up-close.
High-severity NVIDIA vulnerabilities
CVE-2022-28181. A malformed executable or shader file (a program that runs on the GPU) exploiting the DCL_INDEXABLE functionality could lead to memory corruption, code execution, data tampering, denial of service, privilege escalation, and information disclosure. Virtual machines and (theoretically) web browsers can trigger this vulnerability. This is exploitable over the network.
CVE-2022-28182. A malformed executable or shader file exploiting the DCL_INDEXRANGE, DCL_RESOURCE_STRUCTURED, and DCL_UNORDERED_ACCESS_VIEW_STRUCTURED functionalities could lead to memory corruption, data tampering, denial of service, information disclosure, and privilege escalation. Virtual machines and (theoretically) web browsers can trigger this vulnerability. This is exploitable over the network.
CVE-2022-28183. An unprivileged user could cause an out-of-bounds read (a flaw that allows parts of the memory, which are allocated to more critical functions, to be manipulated), leading to a denial of service and information disclosure. This is exploited with local access.
CVE-2022-28184. An unprivileged user could access registers available only to administrator accounts, leading to data tampering, denial of service, and information disclosure. This is exploited with local access.
CVE-2022-28186. A validation flaw in the kernel mode layer (nvlddmkm.sys) could lead to data tampering and denial of service.
CVE-2022-28187. A memory management software flaw in the kernel mode layer (nvlddmkm.sys) could lead to denial of service.
CVE-2022-28188. A validation flaw in kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape where input is not correctly validated for being able to process data safely, which could lead to denial of service.
CVE-2022-28189. A NULL pointer dereference in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape could lead to a system crash.
CVE-2022-28190. A validation flaw in kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape where improper input validation could lead to denial of service.
Patch as soon as possible
NVIDIA users are advised to download and apply the patches ASAP. The updates can also be applied via NVIDIA’s GeForce Experience suite.
Chicago Public Schools (CPS) disclosed on Friday that students may have had their data taken in a ransomware incident involving one of its vendors.
The ransomware attack happened last December at Battelle for Kids (BfK), based in Columbus Ohio, which develops services to provide innovation in schools for students and teachers.
Around 490,000 students and 56,000 employees found their data breached by those responsible for the ransomware. The data accessed by criminals, stretching from 2015 to 2019, included a variety of information potentially including:
Employee ID number
Battelle for Kids username
The notification breach says that home addresses, health/financial information, and social security numbers were not exposed.
Chicago Public Schools is offering free credit monitoring for those affected.
A late notification
The breach occurred in December but the notification did not, which raises several questions related to lateness of notification for those impacted. According to Bleeping Computer, the CPS contract with BfK means immediate notification of any data breach.
Despite this, it took no fewer than four months to get word out that something had occurred. Letters pertaining to the breach were sent out towards the end of April. The reason for this is that it took this long to verify the breach had actually taken place. That isn’t all, however. Other breaches related to the compromise of Battelle for Kids suggests private student data was revealed “as far back as 2011”.
According to the Chicago Sun Times, a spokesperson for CPS says the breach was “caused [and] exacerbated by BfK’s failure to follow the information security terms of their contract”. They go on to single out a failure to encrypt data and purge old records. We talk about ransomware breaches often, and frequently mention the benefits of having a sensible back-up plan. This sounds like a case which may well have benefited greatly from this approach.
Schools: a ripe target for ransomware
All forms of education are an increasingly popular place to be for ransomware criminals. Schools, Universities, and (as we see above) third-party organisations are all valid targets. Even if the schools have a watertight security setup, it may not be the case for external suppliers and other entities interacting with the data in some way.
Outbreaks in schools and universities may not be life-threatening in the way attacks on the healthcare sector can be. However, severe delays to applications, operations, and teaching generally can have a big impact on students.
Tips to avoid ransomware
Keep devices updated. Secure your devices with the latest updates and patches. It’s not just the Operating System you have to consider here. Outdated software and applications are frequently the launchpad for exploits leading to ransomware attacks.
Update your security software. Often your first line of defence, help it to help you by automating updates and scans.
Strengthen remote access. A common ransomware pitfall is leaving remote services unsecured. Provide a limit on password guess attempts for remote desktops. You can also combine remote services with multifactor authentication.
Avoid strange attachments. Booby-trapped Word/Excel documents are a big threat in these realms, especially where Macros are concerned.
Encrypt and back it up. Keep your data encrypted whenever possible, and get into the habit of backing up regularly. Store backups externally, away from the main network. Ensure your backups are stored in a logical way and not a confused mess of folders and files, so you can easily find and restore files if you need to.
Depending on where you live, you can ask a company to hand over all the data it has collected about you and, in a matter of weeks as mandated by law, that company has to fork that information over.
Whether the company will abide on time, however, is a different story.
In the European Union, the United Kingdom, and California, consumers have a leg up in understanding what data is collected about them, largely thanks to several laws passed in those regions in the last few years. And at least in California, people can request that a company hand over the data it has collected about them, even if they are not an active user of that company’s product or a customer of that company’s services.
That’s because in today’s world, your data is not collected only by the companies you directly interact with, but also by the companies that your friends and families interact with.
In February of last year, Whitney Merrill proved this was true when she requested her data from the then-popular app Clubhouse. Though Merrill did not have an account with the company and was not a user of the app, she proved that Clubhouse did have her phone number, which had been shared with Clubhouse by Merrill’s contacts who were active users.
Merrill, who has requested her data from several more companies since then, learned more about data privacy compliance than about just what is being collected about her. Each request, Merrill said, can be different from another, and each request is done separately, forcing users who want to learn more about how their data is collected to spend increasingly more of their own time—time which they may not realistically have. The entire model right now, Merrill said, has many flaws.
This week on the Lock and Code podcast with host David Ruiz, we speak with Merrill about the difficulties of requesting your own data from a company and why some companies seem to interpret data privacy laws as mere suggestions. We also touch on proposed solutions to today’s problems with cross-border data transfers and what “data localization” may lead to in the future.
An unknown Advanced Persistent Threat (APT) group has targeted Russian government entities with at least four separate spear phishing campaigns since late February, 2022.
The campaigns, discovered by the Malwarebytes Threat Intelligence team, are designed to implant a Remote Access Trojan (RAT) that can be used to surveil the computers it infects, and run commands on them remotely. The malware uses a number of advanced tricks to hide what it does and how it works, but our analysts have been able to reverse engineer the malware, reveal its inner workings, and uncover some clues about its possible origins.
Attribution is always difficult, and there is no shortage of countries or agencies with an interest in getting covert access to Russian government computers—and the recent invasion of Ukraine has simply increased the stakes. Although our analysis and attribution efforts are ongoing, we have discovered some indicators that suggest the threat actor may be a Chinese group.
The APT group has launched at least four campaigns since late February, using a variety of lures, detailed below.
1. Interactive map of Ukraine
The threat actor started this campaign around February 26, 2022, and distributed its custom malware with the name interactive_map_UA.exe, trying to disguise it as an interactive map of Ukraine. This campaign began a few days after Russia invaded Ukraine, which shows the threat actor was monitoring the situation between Ukraine and Russia and took advantage of it to lure targets in Russia.
2. Log4j patch
In this campaign the threat actor packaged its custom malware in a tar file called Patch_Log4j.tar.gz, a fake fix for December’s high-profile Log4j vulnerability.
This campaign ran in early March and was primarily aimed at RT TV (formerly Russia Today or Rossiya Segodnya, a Russian state-controlled international television network funded by the Russian government). The APT group had access to almost 100 RT TV employees’ email address.
The emails were sent with the subject “Ростех. ФСБ РФ. Роскомнадзор. Срочные сиправления уязвимостей”, which translates into “Rostec. FSB RF. Roskomnadzor. Urgent Vulnerability Fixes”. (Rostec is a Russian state-owned defense conglomerate founded by Putin.)
The emails also come with a number of image files and a PDF attached, perhaps to make the email less suspicious, and to bypass any systems that flag emails by number of attachments.
The PDF attachment—О кибербезопасности 3.1.2022.pdf—pretends to be from the “Ministry of Digital Development, Telecommunications and Mass Communications of the Russian Federation”. It contains instructions about how to execute the fake patch, as well as a bulleted list of security advice such as “Use two-factor authentication”, “Issue separate credit cards for purchases”, and “Use Kaspersky antivirus”.
In a confident demonstration of just how little attention people pay to such lists it ends “Do not open or reply to suspicious emails.”
The list even includes a link to a page on VirusTotal that proclaims in bright green letters that “No security vendors and no sandboxes flagged this file as malicious”. This is just another effort to convince the victims that the attachment is not malicious—the file on VirusTotal has nothing to do with the attachment and appears to be a legitimate OpenVPN file.
In another effort to build trust, the spear phishing email links to the website rostec.digital, a domain registered by the threat actor, hosting a site made look like the official Rostec website.
This email also contains links to fake Instagram and Facebook accounts. Interestingly, the threat actor created the Facebook page in June 2021, nine months before it was used in this campaign. This was probably an attempt to attract followers, to make the page look more legitimate, and it suggests the APT group were planning this campaign long before the invasion of Ukraine.
3. Build Rostec
The Rostec defense conglomerate also appears in the third campaign. This time the threat actor used the file name build_rosteh4.exe for its malware—an apparent attempt to make it look like software from Rostec.
4. Saudi Aramco job
The most recent campaign occured in mid April and used a Word document containing a fake job advert for a “Strategy and Growth Analyst” position at Saudi Aramco as a lure.
(We also discovered a self-extracting archive file that belonged to this campaign—the archive file used a Jitsi video conferencing software icon as decoy, and created a directory named Aramco under C:ProgramData.)
Although the job advert is written in English, it also contains a message in Russian, asking users to enable macros.
The document uses remote template injection to download a macro-embedded template, which executes a macro that drops a VBS script called HelpCenterUpdater.vbs in the %USER%DocumentsAdobeHelpCenter directory.
The template also seems to do a redundant check for the existence of %USER%DocumentsD5yrqBxW.txt and only if it doesn’t exist, will it drop the script and execute it.
The obfuscated HelpCenterUpdater.vbs script drops another obfuscated VBS file named UpdateRunner.vbs and downloads the main payload—a DLL named GE40BRmRLP.dll—from its command and control (C2) server. (Interestingly, some anti-analysis code, and code responsible for persistence, seems to be commented out in UpdateRunner.vbs and isn’t executed.)
In another payload related to this campaign, the script seems to drop an EXE instead of a DLL, but after analyzing both it seems they share the same code.
The job of the UpdateRunner.vbs script is to execute the DLL through rundll32.exe.
The malicious DLL contains the code that communicates with the C2 server and executes the commands it receives from it.
The malware, which is common to all four campaigns, is explained in detail in the next section.
This analysis focuses on the GE40BRmRLP.dll payload from the Saudi Aramco campaign, but the malware used in all four campaigns is essentially the same, with small differences in the code.
The DLL is heavily obfuscated and most of the library functions are statically linked. IDA is barely able to recognize any functions, though it was able to recognize a few that indicate the DLL was most likely compiled with LLVM. The DLL’s original name is supposed to be simpleloader.dll, as we can see after analyzing it a bit.
Before we dive into the functionality and capabilities of this malware, let’s look at various methods it uses to make the analysis difficult for us.
Control Flow Flattening
All of the samples used in these campaigns use control flow flattening heavily, a technique that flattens the nested structure of a program, making analysis very difficult. We used the D810 plugin for IDA which has the capability to deobfuscate flattened code and make the decompilation more readable.
Although there are many tools that can perform control flow flattening, in this case we suspect OLLVM—an obfuscator for LLVM—was used. The different samples had different levels of flattening and OLLVM allows users to specify this. Additionally we also saw what looks like the Bogus Control Flow LLVM pass being used.
The payload’s strings are obfuscated with simple XOR encoding. The decode_string function which is used to decode a string takes 3 arguments: The encoded string, the destination of the decoded string, and the byte that is used while decoding the string.
Each string is decoded every time it’s required by the malware.
Command and control
Before contacting its C2 server the malware derives an ID which is unique to every machine, which could be used to differentiate infections. It uses the data from the following APIs to construct the ID:
GetFileAttributesA on the C:Windows directory
GetVolumeInformationA on the C: drive
It then calculates a hash of this data using the Blake2b-256 algorithm and sends it when it makes the first contact with its C2.
The C2 address is decoded every time the malware sends a request. To communicate with the C2 the malware uses GET requests in the form url/?wSR=data, where data contains the encoded information.
Interestingly Any.run and Fiddler fail to capture the HTTPS requests made by the malware. To make them, the malware doesn’t use any library functions but instead implements everything over raw sockets, and it uses the WolfSSL library to implement SSL itself. Our analysis also uncovered traces of http-parser from ZephyrOS. The certificate used for the SSL communication is stored inside the binary as chunks of encoded strings. Initially the malware decodes this data and stores it. Later, while making the HTTPS request, it loads this data using WolfSSL’s loadX509orX509REQFromBuffer.
After making every request the malware sleeps for a random amount of time.
Based on the response to the above request, the malware decides which of command to execute:
getcomputername. This retrieves the computer name using GetComputerNameA and sends a response to the C2 containing the unique id and the computer name.
upload. This receives a file name and file contents from the C2 which it writes to the local file system.
execute. This receives a command line instruction from the C2 and executes it using CreateProcessA. If the command is successful then the malware sends the UID with the “OK” string to the C2, or the output of GetLastError if it fails.
exit. This is used to terminate the malware process.
ls. This command uses a directory name from the C2, or the name of the current directory if one isn’t provided. It uses the FindFirstFile and FindNextFile function to retrieve a list of all the files under the directory and sends it back to the C2.
Attribution is difficult, and threat actors are known to use indicators from other groups as false flags. The attribution of the APT behind these campaigns is ongoing, but based on the infrastructure used we assess with low confidence that this group is a Chinese actor.
All of the C2s are from BL Networks, which has been used by Chinese APTsin the past. Also, we discovered infrastructure overlap between the malware we analyzed and the Sakula Rat malware used by the Deep Panda APT.
Another interesting indicator we found was that the macro used in the Aramco campaign is almost identical to some macros used by TrickBot and BazarLoader in the past. We think the actor may have used the same macro builder to generate its macro, and they may have used it as a false flag. There are some other weak indicators, such as WolfSSL, which has been used by Lazarus and Tropic Troopers, but they are not enough to help attribute the attack to any specific actor.
Malwarebytes customers were proactively protected against these campaigns thanks to our heuristic detection engines.