GitHub Discloses Enterprise Server Authentication Bypass Vulnerability

Later into May 21, GitHub developers released a note regarding the newly discovered vulnerability in Enterprise Server (GHES). That is a localized development and code managed solution that repeats the functionality of the cloud one. This in fact makes the vulnerability much more dangerous, but more on that later. Searches through ZoomEye search engine reports about over 70 thousand Enterprise Server instances around the world, with most of them being vulnerable.

The new CVE-2024-4985 flaw stems from the weakness in the SAML authentication mechanism, specifically in its optional encrypted assertion feature. It was discovered under GitHub’s Bug Bounty program. By crafting a response message of the SAML system, it is possible to make the system think that the authentication was done successfully, so it lets the adversary get in.

The potential outcomes of a successful attack are rather severe, which definitely makes up for the CVSS score of 10/10. Considering that Enterprise Server suggests a self-hosted instance of a GitHub code repository, getting access to it will also mean getting access to some of the internal network infrastructure. Repository access itself is a perfect ground for a supply chain attack, and by accessing the servers, hackers can deal damage to the company itself.

GitHub Releases Fixes For CVE-2024-4985

One more unfortunate detail about this flaw is that it impacts quite a few versions of GitHub Enterprise Server. The newest 3.13 version of GHES is safe, but all the versions prior to it are vulnerable. The developer released fixes for a selection of versions.

There is also a mitigation option, confirmed by GitHub – disabling the encrypted assertion features. The flawed component is not enabled by default, so the issue is non-existent for those who never enabled it. This mitigation will also be helpful for the users of versions prior to 3.8, which will not receive any updates.

The post GitHub Enterprise Server Auth Bypass Flaw Discovered appeared first on Gridinsoft Blog.

Hackers Abuse GitHub and GitLab Feature to Upload Malware to Legit Repositories

The research regarding the new spreading campaign of RedLine stealer, that McAfee released the week before, revealed a rather unusual tactic. Hackers managed to place the malware file on the GitHub repository of Microsoft, without resorting to compromising one. Instead, threat actors exploited a design flaw of the platform.

In its Issue and Pull Request menus, GitHub offers users to attach a file they need – a neat feature which makes both actions convenient for users and the developers. Thing is – all the attachments are uploaded with the path of this repository, making them look like a thing related to this repo. User does not even need to post the message, as the link will work right away, after the system processes the file. These uploads do not appear anywhere in the repository and are kept only on GitHub’s CDN servers.

This forced analysts to dig further, and they discovered that GitLab, another developer platform, is susceptible to the very same issue. At the moment when a user attaches the file to a comment, the service generates a link to it. It remains active even if the comment was never posted or deleted shortly after publication.

This boils down to a simple conclusion: that feature allows the use of trusted and well-recognized repos as a concealed file sharing service. Repository masters will never know that someone is piggybacking their repo, and will not be able to do anything about it.

How dangerous is this?

In short: this can nullify any cybersecurity features that rely on trust ratings and designed to block access to web pages thas spread malware. Malicious programs rarely arrive “as is”, without loaders or other tricks that help it to examine the environment and run without interruptions. For quite some time now hackers rely on a place where they can upload the payload, so the said loader can pull and run one.

Usually, for this online storage, adversaries use a compromised website or a file sharing service. But modern security tools are aware of it and trigger the alarm when they see this traffic. On the other hand, a link that leads to the Microsoft repository, by the looks of it, will never be a reason for alarm. There is no way to tell whether the link leads to a file that is directly in the repo or just sits on a CDN.

The worst part here is that neither GitHub nor GitLab are able to fix the issue on short notice. Researchers who did the analysis of a GitLab case say they have contacted both companies, but did not receive a response yet. And honestly, I cannot see a quick and painless remedy here. Banning CDN uploads, the most straightforward decision, will disrupt genuine uploads. Integrating a malware scanning mechanism may create issues with educational open-source malicious software, and is also time consuming. That probably explains why the services remain silent on the request from the researchers.

The post GitHub and GitLab CDNs Abused to Spread Malware appeared first on Gridinsoft Blog.

Short About STRRAT and Vcurms

STRRAT is a Java-based RAT, notorious for its ability to steal information. It’s primarily used to gather credentials from browsers and email clients, log keystrokes, and provide backdoor access to infected systems. Same as other remote access trojans, STRRAT also relies on stealthiness of its operations and detection evasion.

Vcurms, is another Java-based RAT, but with distinct operational tactics. It communicates with its command-and-control server via a Proton Mail email address and executes commands received through specific email subject lines. This malware carries the functionality of infostealer, capable of extracting data from various applications like Discord and Steam. Aside from this, it can grab credentials, cookies, and autofill data from multiple web browsers. It shares similarities with another malware known as Rude Stealer.

Attack Overview

ANY.RUN researchers say the attack begins with a phishing email convincing recipients to click a button to verify payment information. This action leads to the download of a malicious JAR file masquerading as a payment receipt. The downloaded file then launches two additional JAR files that activate both Vcurms and STRRAT trojans.

Both malware samples try to remain stealthy, using detection and analysis evasion techniques. Researchers found them using these specific tricks:

• Using legitimate services and tools – when attackers can use legitimate cloud platforms such as AWS and GitHub to store or distribute malware. Such a trick also complicates filtering network requests of malicious origin.
• Code Obfuscation – in which the source code of a program is converted into a form that makes it difficult to read. This is used to hide malicious functions from antivirus scanners and analysts. (By the way, the first JAR file received via email is obfuscated and downloads malware using a PowerShell command).
• Packing – where malicious code is compressed or “packed” together with some type of unpacking mechanism. This makes it difficult to analyze the code without executing the malware.

This is not the first time malware actors abuse GitHub or other developer platforms. Unfortunately, there are not a lot of options to mitigate this proactively: it is easy to masquerade the code and make it look innocent. GitLab administrators reacted to user complaints and removed the malicious repository, but this does not guarantee that there won’t be a comeback.

Sandbox attack analysis

A phishing campaign begins by spreading the initial loader via phishing emails. The goal of these emails is to convince the user to download and run a malicious JAR file. This file acts as a primary loader that initiates a series of malicious actions on the infected machine.

Primary Loader

Once launched, the primary loader downloads a secondary malicious file from the aforementioned repository on GitHub. The file is launched using a command pointing to the Java file execution:

"C:\Program Files\Java\jre1.8.0_271\bin\javaw.exe" -jar "C:\Users\admin\AppData\Local\Temp\64e8cb522a3a4664791c27512d94a911bc2fbcbae09b625976ff8ac6809819d3.jar"

Persistence and disguise

Then, malware creates a copy of itself in the AppData\Roaming directory and registers a task in the Windows scheduler to automatically restart every 30 minutes. Interestingly enough, malware tries to mimic the Skype application, judging by the name of the task it creates. This ensures the permanence of the malware on the system.

cmd /c schtasks /create /sc minute /mo 30 /tn Skype /tr "C:\Users\admin\AppData\Roaming\64e8cb522a3a4664791c27512d94a911bc2fbcbae09b625976ff8ac6809819d3.jar"

Collecting information about the system

Next, the malware gathers information about the system, including a list of disks and the presence of installed security programs, using the following commands:

cmd.exe /c "wmic /node:. /namespace:'\\root\cimv2' path win32_logicaldisk get volumeserialnumber /format:list"
cmd.exe /c "wmic /node:localhost /namespace:'\\root\securitycenter2' path antivirusproduct get displayname /format:list"

One of the malware programs, in this case Vcurms, uses PowerShell command to dump the passwords kept in Windows, rather than in the third party tool. Obviously, it gathers data from browsers, too, but in a different manner – by accessing their data directly.

powershell.exe "[void][Windows.Security.Credentials.PasswordVault,Windows.Security.Credentials,ContentType=WindowsRuntime] $vault = New-Object Windows.Security.Credentials.PasswordVault $vault.RetrieveAll() | % { $_.RetrievePassword();$_ }"

I assume this command is related to Vcurms as STRRAT does not exhibit password stealing functionality.

Strengthening cybersecurity

This case shows vigilance and cooperation in cybersecurity. This phishing attack showed that even trusted platforms like GitHub can be used as a tool to spread malware. Cybersecurity experts offer the following tips to protect against such threats:

• Firstly, always verify the sender and avoid opening attachments or clicking on links in emails that seem suspicious or unexpected. If an email asks you to confirm payment details or personal information, it is better to contact the sender directly through another channel.
• Then, enable spam filters on your email to reduce the number of phishing and junk emails reaching your inbox.
• Make sure your antivirus software and all systems are updated to the latest versions. Regular updates help protect against known threats and vulnerabilities.
• Also, regularly monitor systems for suspicious activity and respond quickly to cybersecurity incidents. Use analytics and intelligent detection tools.
• And last, back up important data regularly and store it in a safe place. This will help you recover information in the event of a successful attack.

The post STRRAT and Vcurms Malware Abuse GitHub for Spreading appeared first on Gridinsoft Blog.

Aqua researchers believe that millions of repositories on GitHub are vulnerable to an attack that allows taking over other people’s repositories and is called RepoJacking. The issue is reportedly affecting the repositories of Google, Lyft, and other major companies.

Let me remind you that we also wrote that Malware in GitHub Repositories Is Spread From Fake Security Company Name, and also that Attackers Can Use GitHub Codespaces to Host and Deliver Malware.

These conclusions were made after analyzing a sample of 1.25 million GitHub repositories, during which experts found that about 2.95% of them are vulnerable to RepoJacking.

Extrapolating this percentage to the entire database of 300 million GitHub repositories, the researchers calculated that the problem affects approximately 9 million projects.

The essence of the RepoJacking attack is simple. The fact is that usernames and repositories change regularly on GitHub (for example, due to the fact that the organization changed the brand name). When this happens, a special redirect is created to avoid breaking dependencies for projects that use code from repositories that have changed their name. However, if someone registers the old name, this redirect becomes invalid.

Thus, RepoJacking is an attack in which an attacker registers a username and creates a repository that was previously used by some organization, but has changed its name. As a result, any project and code that relies on a dependency on the attacked project will interact with a repository that the attacker controls and that may contain malware.

The researchers explain that GitHub is aware of this issue and there are a number of defense mechanisms in place to protect against RepoJacking. However, according to experts, these security solutions are not very reliable and can be easily bypassed.

For example, GitHub only protects very popular projects, however, they may have a dependency on a less popular and vulnerable repository that is not protected by GitHub. As a result, compromise will affect the entire supply chain.

In addition, GitHub protects repositories that had more than 100 clones in the week before the name change (indicative of malicious activity). But such protection does not apply to projects that have become popular after the renaming or after the transfer of ownership.

To demonstrate the danger of this problem, Aqua analysts searched for vulnerable repositories from well-known organizations and found striking examples in repositories operated by Google and Lyft.

In Google’s case, a readme file was found containing instructions for the rather popular Mathsteps project. The file pointed to a repository owned by Socratic, which Google acquired in 2018 and no longer exists. In fact, an attacker can clone this repository, and users, following the instructions in the readme, can download malicious code from the hacker’s repository.

Also, since the instructions include npm install for a dependency, an attacker will be able to execute arbitrary code on unsuspecting users’ devices.

As for Lyft, in this case, the attack may be automated, as the researchers found an installation script in the company’s repository that extracts a ZIP archive from another repository vulnerable to RepoJacking.

So, an attacker who registers a new username and a repository with the correct name (in this case, YesGraph and Dominus) can inject their code to anyone who executes the Lyft install.sh script.

The experts conclude that RepoJacking is unfortunately quite difficult to prevent, and such an attack can have serious consequences for organizations and users. In conclusion, Aqua researchers advise project owners to minimize the resources they pull from external repositories.

The media also reported that GitHub says it takes years to fix vulnerabilities in some ecosystems.

The post RepoJacking Attacks Could Threaten Millions of GitHub Repositories appeared first on Gridinsoft Blog.

What is GitHub?

GitHub is a massive platform for hosting code. Researchers worldwide use it to share PoC exploits with the information security community. This helps others test patches and determine the scale and impact of bugs. Last year, there were 10 million occurrences of secrets being exposed on GitHub, a 67% increase from the previous year.

Fake Security Company Spreads Malware in GitHub

A team of VulnCheck experts is closely monitoring a large number of GitHub repositories as part of an Exploit Intelligence offering. During a routine check in early May, researchers discovered a malicious repository on GitHub that claimed to be Signal 0-day. Then it was removed. The next day, an almost identical repository was discovered under a different account, this time claiming to be WhatsApp Zero Day. But it, too, was deleted by the GitHub team. This process continued for a month.

After that, the attackers created a whole network of accounts, including half a dozen GitHub accounts and several related Twitter accounts. These accounts pretend to be part of a defunct security company called High Sierra Cyber Security. Here is an example of one such account:

According to technical engineers, threat actors now use code repositories to trick unaware developers into doing their work for them. These actors have focused on social engineering tactics to make the repository owner appear legitimate, but their malware on Github is quite easy to identify. Since there’s plenty of room for improvement, these attacks may become much more effective.

All the repositories have a straightforward structure depicted in the image below. Additionally, they use the “hot” CVE tagging to entice potential victims.

How it works?

The code in poc.py downloads a harmful binary and runs it. The Python script will download a particular payload based on the target’s operating system. This Discord “0-day” exploit utilizes the code mentioned above to carry out these tasks.

Afterward, poc.py obtains one of two zip files from GitHub: cveslinux.zip or cveswindows.zip. The program unzips the file, saves it to the computer’s disk, and then runs it. However, the Windows binary has a high detection rate on VirusTotal (43/71). In contrast, the Linux binary has a lower detection rate (3/62) but does contain some strings that suggest its purpose.

Conclusions:

An attacker has put much effort into creating fake identities to spread obvious malware in GitHub. They may have been successful, but since they continue to use this method, they must think it will work. It needs to be clarified if this is an individual with too much free time or a more advanced campaign like the one discovered by Google TAG in January 2021.

Regardless, security researchers should be aware that they are attractive targets for cybercriminals and should exercise caution when downloading code from GitHub. Constantly scrutinize the code you’re about to execute and avoid using anything you don’t understand. Use virtual or dedicated machines on which you do not risk losing your data. There, precautions are never excessive, especially considering the severity of malware on GitHub.

Your security may have been compromised if you’ve interacted with any of the accounts listed:

GitHub Accounts

Malicious Repositories

Twitter Accounts

The post Malware in GitHub Repositories Is Spread From Fake Security Company Name appeared first on Gridinsoft Blog.

Trend Micro reports that the GitHub Codespaces cloud development environment, available to the public use since November 2022, can be used to store and deliver malware, as well as malicious scripts.

Let me remind you that we also talked about Hackers Bypass CAPTCHA on GitHub to Automate Account Creation, and also that Hackers compromised Slack private GitHub repositories.

And also, the media reported that Many Repositories on GitHub Are Cloned and Distribute Malware.

In their report, the researchers demonstrate how easy it is to set up GitHub Codespaces to act as a web server to distribute malicious content while avoiding detection as the traffic originates from Microsoft servers.

The fact is that GitHub Codespaces allows developers to share forwarded ports from a virtual machine both privately and publicly for the purpose of real-time collaboration.

When forwarding ports on a virtual machine, Codespaces will generate a URL to access the application running on that port, which can be configured as private or public. Access to the private port URL will require authentication in the form of a token or cookies. However, the public port will be available to anyone without authentication if they know the URL.

Trend Micro analysts write that attackers can easily use this functionality to place malicious content on the platform. For example, an attacker can run a simple Python web server, upload malicious scripts or malware into their Codespace, open a web server port on a virtual machine and make it public.

The generated URL can then be used to access hosted files that could be used in phishing campaigns or become malicious executables downloaded by other malware. This is how attackers commonly abuse other well-known services, including Google Cloud, Amazon AWS, and Microsoft Azure.

Also, Trend Micro analysts write that an attacker can create a simple script to create a Codespace with a public port and use it to host malicious content, and set it to automatically self-delete after the URL has been accessed.

So far, no cases of abuse of GitHub Codespaces have been found in this way, but analysts are confident that attackers are unlikely to miss this opportunity.

The post Attackers Can Use GitHub Codespaces to Host and Deliver Malware appeared first on Gridinsoft Blog.

The South African hack group Automated Libra is looking for new approaches to use the resources of cloud platforms for cryptocurrency mining: hackers bypass CAPTCHA on GitHub.

Let me remind you that we also wrote that Hackers force users to solve CAPTCHA, and also that New hCaptcha bypass method may not affect Cloudflare’s security.

According to Palo Alto Networks, in recent times, attackers are using a new system to solve CAPTCHAs, abusing CPU resources more aggressively for mining, and also mixing freejacking with Play and Run techniques.

For the first time, Automated Libra operations were discovered by Sysdig analysts last fall. Then the researchers gave a name to the found malware cluster PurpleUrchin and suggested that this group specializes in freejacking, that is, they abuse free or time-limited access to various services (GitHub, Heroku and Buddy) to mine cryptocurrency at their expense.

Now Palo Alto Networks experts have studied the activity of this group in more detail, analyzing more than 250 GB of collected data and collecting more information about the infrastructure and methods of attackers.

According to experts, the automated campaigns of these attackers are abusing CI/CD services, including GitHub, Heroku, Buddy, and Togglebox, to create new accounts and run cryptocurrency miners in containers. But if Sysdig analysts only identified 3,200 malicious accounts belonging to PurpleUrchin, then Palo Alto Networks reports that since August 2019, hackers have created and used more than 130,000 accounts on the mentioned platforms.

In addition, it turned out that the attackers used containers not only for mining itself, but also for trading the mined cryptocurrency on various platforms, including ExchangeMarket, crex24, Luno and CRATEX.

At the same time, the researchers confirm that freejacking is an important aspect of Automated Libra operations, but write that Play and Run tactics are also of great importance. This term usually refers to attackers who use paid resources to make a profit (in this case, using cryptocurrency mining), but refuse to pay bills until their accounts are frozen. Once locked out, they drop the accounts and create new ones.

As a rule, Automated Libra uses stolen personal data and bank card information to create premium accounts on VPS and CSP platforms, leaving a trail of unpaid debts.

In such cases, attackers use as many server resources as possible before losing access. This is in stark contrast to the freejacking tactic, where the miner tries to remain invisible and uses only a tiny fraction of the server’s capacity.

In addition, according to experts, an interesting feature of the Automated Libra attacks is the CAPTCHA solution system, which helps hackers create many accounts on GitHub automatically. To do this, the attackers use ImageMagic and convert the CAPTCHA images to their RGB equivalents and then use “identify” to determine the asymmetry of the red channel.

The values obtained in this way are used to rank the images in ascending order, and the automated tool selects the image that leads the resulting list. Usually, that is exactly what is correct.

The post Hackers Bypass CAPTCHA on GitHub to Automate Account Creation appeared first on Gridinsoft Blog.

On December 31, while everyone was celebrating the New Year, Salesforce, the company behind the development of the corporate Slack messenger, published a message about the incident of compromising Slack repositories on GitHub.

Let me remind you that recently MI also wrote that Slack Is Resetting User Passwords Due to a Bug, and also that Slack Connect DM new feature drew a barrage of criticism.

The attack by unknown attackers affected some of the company’s private GitHub repositories, but it is reported that Slack’s core codebase and customer data were not affected.

Slack representatives write that the stolen tokens have already been invalidated, and the investigation of the “potential impact” of this attack on customers is still ongoing. So far, there has been no indication that hackers have gained access to any sensitive areas or Slack workspaces. However, as a precaution, the company has changed the relevant secrets.

At the same time, journalists drew attention to a number of oddities associated with the disclosure of data about this incident. Thus, Bleeping Computer notes that the message about the attack was published on December 31, when most people are busy celebrating the New Year.

In addition, the report was initially not displayed at all on the international version of the company’s blog, and in some regions (for example, in the UK), the publication was marked noindex, which is used to exclude web pages from search results and make them much more difficult to detect. However, Google successfully indexed a post for the US published without the noindex tag.

As a result, according to ArsTechnica, although the message about the incident appeared on the network as early as December 31, search engines and the Internet Archive practically “did not see” it until January 5-6. It seems that the Slack developers were trying to prevent this newsletter from being indexed by search engines and to limit the publicity of what happened.

Let me remind you that the media also wrote that Facebook incorporates hidden codes in photos for download.

The post Hackers compromised Slack private GitHub repositories appeared first on Gridinsoft Blog.

Fortinet researchers studied the recently appeared open-source cryptor Cryptonite, distributed for free on GitHub.

It turned out that the creator of the malware made a mistake in the code, and the malware did not encrypt, but destroyed the data of the victims.

Let me remind you that we also wrote about FBI Says Cuba Ransomware ‘Made’ $60 Million by Attacking More Than 100 Organizations, as well as Security Experts Secretly Helped Zeppelin Ransomware Victims for Two Years.

Unlike other ransomware, Cryptonite was not sold on the darknet, but was distributed openly: it was published on GitHub by someone under the nickname CYBERDEVILZ (since then, the source code of the malware and its forks have already been removed).

The researchers say that the malware written in Python was extremely simple: it used the Fernet module to encrypt files and replaced their extension with .cryptn8.

The Cryptonite ransomware sample implements only basic ransomware functionality. The operator can set up a few things such as the exclusion list, server URL, email address, and bitcoin wallet. However, encryption and decryption are very simple and unreliable.

It also doesn’t provide any of the typical (but more sophisticated) ransomware features, such as:

1. Removing Windows Shadow Copy
2. Unlock files for more thorough exposure
3. Anti-analysis
4. Defensive evasion (bypass AMSI, disable event logging, etc.)

While this ransomware variant has given newcomers easy access to the cybercriminal business, it is not a serious tool.

However, something went wrong in the latest version of the malware: a sample of Cryptonite studied by experts blocked files beyond recovery, in fact, acting as a wiper.

The researchers say that the destructive behavior of the malware was not intended by its author. Rather, this is due to its low qualification, as errors in the code cause the program to crash when trying to display a ransom note (after the encryption process is completed).

In addition, an error that occurs during the operation of the encryptor leads to the fact that the key used to encrypt files is not transmitted to the malware operator at all. That is, access to the victim’s data is blocked completely and permanently.

The post Open-Source Cryptor Cryptonite Became a Wiper due to a Bug appeared first on Gridinsoft Blog.

It turned out that the probability of infection with malware when downloading PoC can reach 10.3%, even if outright fakes are excluded.

Let me remind you that we also reported that GitHub removed ProxyLogon exploit and has been criticized, and also that Hackers Use CircleCI Fake Notifications to Access GitHub Accounts.

Experts write that GitHub is one of the largest platforms for hosting code, and researchers from all over the world use it to publish PoC exploits so that other members of the information security community can test patches, determine the impact and scale of bugs.

For their study, the experts analyzed more than 47,300 repositories offering exploits for various vulnerabilities discovered between 2017 and 2021. The following methods were used for the analysis.

1. Analysis of IP addresses. Comparison of the IP address of the PoC author with public blacklists, as well as Virus Total and AbuseIPDB.
2. Binary analysis. Checking provided executable files and their hashes via VirusTotal.
3. Hexadecimal and Base64 parsing. Converting obfuscated files before performing binary and IP checks.

As a result, out of 150,734 unique IP addresses, 2864 were blacklisted (1522 were identified as malicious by Virus Total, and another 1069 were present in the AbuseIPDB database).

During binary analysis, a set of 6160 executable files was examined, and 2164 malicious samples were found among them, located in 1398 repositories.

In total, 4,893 out of 47,313 repositories tested were found to be malicious in this review, with most of the dangerous PoCs found to be associated with 2020 vulnerabilities.

After examining some of these bogus exploits, the researchers found many different malware and malicious scripts, ranging from remote access Trojans to Cobalt Strike.

For example, in one example, the fake PoC for CVE-2019-0708, commonly known as BlueKeep, contained an obfuscated base64 Python script that extracted VBScript from Pastebin. This script was Houdini RAT, an old JavaScript Trojan that supports remote command execution through the Windows command line.

In another case, researchers discovered a fake exploit that was an infostealer that collects system information, IP address, and user agent from an infected system. Since this PoC was previously created as an experiment by another researcher, the experts considered that its discovery was confirmation that their approach was working.

Experts concluded that you should not blindly trust GitHub repositories, because the content is not moderated here. According to the authors of the report, all testers should take the following steps before working with exploits:

1. carefully read the code that you plan to run on your network or the client’s network;
2. if the code is seriously obfuscated and takes too long to analyze manually, you should place it in an isolated environment (for example, a virtual machine) and check the network for suspicious traffic;
3. use open-source analysis tools like VirusTotal to check binary files.

The researchers write that they have notified GitHub of all malicious repositories, but it will take some time to check and remove them, so for now, many of them are still available to everyone.

The post Thousands of GitHub Repositories Spread Malware That Is Disguised as Exploits appeared first on Gridinsoft Blog.