Search This Blog

Showing posts with label GitHub. Show all posts

GitHub Announced Security Key Support for SSH Git Operations

 

When using Git over SSH, GitHub, the ubiquitous host for software creation and version control (and unfortunate victim of a relentless stream of attacks targeting the same), now supports encryption keys.

GitHub security engineer Kevin Jones said in a blog post on Monday that this is the next step in improving security and usability. These portable FIDO2 fobs are used for SSH authentication to protect Git operations and avoid the havoc that can occur when private keys are misplaced or stolen, or when malware attempts to execute requests without user permission. For instance, in 2019, the TrickBot data-stealing malware was updated to include a password grabber that could attack data from OpenSSH applications. 

These security keys, which include the YubiKey, Thetis Fido U2F Security Key, and Google Titan Security Keys, are easy to carry around in your pocket and attach to computers via USB, NFC, or Bluetooth. They can be used instead of one-time passwords generated by apps or sent via SMS. SMS SSH codes sent via text can currently be intercepted.

Strong passwords are still relevant, but because of the proliferation of data breaches and cyberattacks, they are becoming less useful as a single security mechanism, prompting the development of password managers that often check for credential leakage online, biometrics, and security keys. 

"We recognize that passwords are convenient, but they are a consistent source of account security challenges," Jones commented. "We believe passwords represent the present and past, but not the future. By removing password support for Git, as we already successfully did for our API, we will raise the baseline security hygiene for every user and organization, and for the resulting software supply chain." 

Since keys are one of the variables in multi-factor authentication (MFA), users can treat them with the same care as any other credential. You should have your security key plugged in if you're the only one that has access to it. “When using SSH with a security key, none of the sensitive information ever leaves the physical security key device,” Jones added. “If you’re the only person with physical access to your security key, it’s safe to leave plugged in at all times.” 

When you use a security key, neither ransomware nor unintended private-key leakage will reveal your keys, he said: “As long as you retain access to the security key, you can be confident that it can’t be used by anyone else for any other purpose.”

OpenBullet Exploited for Credential Stuffing

 

Credential stuffing, a form of access-related cybercrime, is on the rise and shows no signs of slowing down. Between January 2018 and December 2019, there were 88 billion credential stuffing attacks, according to an Akamai survey.

Credential stuffing is a form of cyberattack in which compromised account credentials are used to obtain unauthorized access to user accounts through large-scale automatic login requests directed towards a web application, usually consisting of lists of usernames and/or email addresses and the corresponding passwords (often from a data breach). Credential stuffing attacks, unlike credential hacking, do not try to brute force or guess any passwords. Using standard web automation software like Selenium, cURL, PhantomJS, or tools built especially for these types of attacks like Sentry MBA, SNIPR, STORM, Blackbullet, and Openbullet, the intruder easily automates the logins for a significant number (thousands to millions) of previously discovered credential pairs. 

Since many users repeat the same username/password combination across different pages, credential stuffing attacks are likely. According to one poll, 81 percent of users have reused a password across two or more sites, and 25% of users use the same password across a number of their accounts. 

OpenBullet is a free web-testing tool that allows users to make particular requests on specific web pages. The open-source tool is available on GitHub and can be used for a variety of activities, including data scraping and sorting, automatic penetration testing, and Selenium unit testing. 

For legitimate reasons, such as penetration testing, the app allows users to try several "login:password" variations as credential brute-force attacks on various websites. Cybercriminals, on the other hand, will use it to find legitimate passwords on various websites for nefarious purposes.

A user can import prebuilt configuration files or configs into OpenBullet, one for each website to be checked. It also has a modular editor for making changes to configurations as desired. This is a required function since websites also make minor changes to the way users link to them in order to combat automatic tools like OpenBullet. OpenBullet's GitHub profile, for example, has a note that the tool should not be used for credential stuffing on websites that the user does not own. 

The Federal Trade Commission (FTC) released an advisory in 2017 advising businesses about how to combat credential stuffing, including requiring safe passwords and preventing attacks.

Linux, MacOS Malware Hidden in Fake Browserify NPM Package

 

Over the course of the weekend, Sonatype's automated malware detection system spotted a serious exceptional malware sample published to the NPM registry. NodeJS engineers working with Linux and Apple macOS operating systems were targeted by a brand-new malicious package recognized on the NPM (Node Package Manager) registry. The malignant package, named "web-browserify" looks like the well-known Browserify NPM component which has been downloaded in excess of 160 million times all through its lifecycle, with over 1.3 million weekly downloads on NPM alone, being utilized by 356,000 GitHub repositories. 

Evidently, the malignant component has been downloaded around 50 times before it was taken out from the NPM within two days of its publishing. The package, made by a pseudonymous creator portraying themselves to be Steve Jobs, consolidates many approved open-source components and executes extensive surveillance actions on a contaminated system. Besides, up to this point, none of the main antivirus engines had the option to identify the ELF malware contained with the component. The way that it utilizes genuine software applications to perform dubious exercises could be one of the reasons. 

Browserify's fame comes from it being an open-source JavaScript instrument that permits developers to write cross-platform, NodeJS-style modules that gather for use in the browser. The distinction between the authentic Browserify and the phony one is that the latter abuses legitimate NPM components to bundle inside a malicious, hard to notice Linux and Mac executable. 

The malignant bundle incorporates a manifest file, package.json, a postinstall.js script, and an ELF executable called "run" existing in a compressed archive, run.tar.xz inside the npm component. When a developer is installing the package, the scripts pull out and start the "run" Linux binary from the archive, which demands elevated or root permissions from the user. The extracted "run" binary is immense, around 120 MB in size, and bundles inside itself hundreds of legitimate NPM components. The malware is made totally from open source components and uses these genuine components to organize its extensive surveillance activities. 

The cross-platform “sudo-prompt” module is one of these components and is used by "run" to provoke the client into permitting the malware root privileges on both macOS and Linux distributions.

Attackers found abusing GitHub Infrastructure to Mine Cryptocurrency

 

Microsoft-owned GitHub is the new cyberattack victim, with reports of cybercriminals manipulating GitHub's cloud infrastructure to mine cryptocurrency. Code repository hosting service, Github has started an investigation into a series of attacks aimed at abusing its infrastructure to mine cryptocurrency illegally. 

GitHub Actions is a continuous integration (CI) and continuous deployment (CD ) solution that makes it easy to automate all the software workflows and setup periodic tasks. The particular attack adds malicious GitHub Actions code to repositories forked from legitimate ones and further creates a Pull Request for the original repository maintainers to merge the code back, to alter the original code. 

“In a phone call, Dutch security engineer Justin Perdok told The Record that at least one threat actor is targeting GitHub repositories where Actions might be enabled. The attack involves forking a legitimate repository, adding malicious GitHub Actions to the original code, and then filing a Pull Request with the original repository in order to merge the code back into the original.” reported The Record. 

“But the attack doesn’t rely on the original project owner approving the malicious Pull Request. Just filing the Pull Request is enough for the attack, Perdok said.” This is particularly true for GitHub projects that have automated workflows setup to substantiate incoming Pull Requests via Actions. As soon as a Pull Request is created for the original project, GitHub's systems execute the attacker's code which instructs GitHub servers to retrieve and run a crypto miner. 

This isn't the first time an attack leveraging GitHub infrastructure has abused GitHub Actions. An identical attack had previously been identified by another programmer, Yann Esposito, in which an attacker had filed a malicious Pull Request against Esposito's GitHub project. 

Last year, BleepingComputer reported on GitHub being used to host a wormable botnet Gitpaste-12, which reappeared with over 30 exploits the following month. Unlike Gitpaste-12 or the Octopus Scanner malware, which targeted vulnerable projects and computers, this attack appears to be solely abusing on GitHub servers for crypto mining.

In an email, GitHub told The Record that they are “aware of this activity and are actively investigating”. For now, the attack does not appear to damage users’ projects in any way and seems to be solely focused on abusing GitHub infrastructure.

278,000 GitHub Repositories Affected by a Critical Networking Flaw in Netmask

 

Security researchers have unearthed a critical networking flaw CVE-2021-28918 in a popular npm library netmask. Netmask is commonly utilized by tons of thousands of applications to analyze IPv4 addresses and CIDR blocks or compare them. 

Netmask usually gets over 3 million weekly downloads, and as of today, has scored over 238 million complete downloads over its lifetime. Apart from this, nearly 278,000 GitHub repositories depend on the netmask. Due to improper input validation flaw, netmask sees a different IP and this flaw could allow hackers to achieve server-side request forgery (SSRF) in downstream applications.

 Security researchers Victor Viale, Sick Codes, Nick Sahler, Kelly Kaoudis, and John Jackson were responsible for tracking down the vulnerability in the popular netmask library. The flaw was initially detected when security researchers including Codes were designing a patch for a separate, critical, SSRF flaw (CVE-2020-28360) in downstream package Private-IP, which helps in preventing personal IP addresses from communicating with an application’s internal resources.

According to a GitHub advisory published by Sick Codes, “the primary cause of the problem turned out to be Netmask’s incorrect evaluation of individual IPv4 octets that contain octal strings as left-stripped integers, leading to an inordinate attack surface on hundreds of thousands of projects that rely on Netmask to filter or evaluate IPv4 block ranges, both inbound and outbound.”

Security researchers initially discovered the flaw on March 16 and advised node js developers to examine their projects for use of Netmask and upgrade immediately if they identify the package in use. Sick Codes stated that the 30 billion nodejs packages downloaded last week were mostly installed by automated CI/CD pipelines and with no manual runtime inspections.

Olivier Poitrey, netmask developer and director of engineering at Netflix, released a series of patches [1,2,3] for the bug to GitHub, containing test cases validating that IPv4 octets with 0 prefixes are treated as octal and not decimal numbers. Earlier this month, the Perl component Net::Netmask also suffered from this bug.

PHP Git Server Hacked to Plant Malware in Code Base

 

In the most recent software supply chain assault, the official PHP Git repository was hacked and the code base altered. On Sunday, two malevolent commits were pushed to the php-src Git repository kept up by the PHP team on their git.php.net server. The threat actors had signed off on these commits as though these were made by known PHP developers and maintainers, Rasmus Lerdorf and Nikita Popov. 

The incident is disturbing considering PHP stays the server-side programming language to control more than 79% of the sites on the Internet. In the noxious commits [1, 2] seen by BleepingComputer, the assailants published a strange change upstream, "fix typo" under the pretence this was a minor typographical amendment. 

As indicated by Bleeping Computer, the code has all the earmarks of being intended to embed a backdoor and make a situation wherein remote code execution (RCE) might be conceivable. Popov said the development team isn't sure precisely how the assault occurred, however, pieces of information show that the official git.php.net server was likely undermined, instead of individual Git accounts. A remark, "REMOVETHIS: sold to zerodium, mid-2017," was included in the script. There is no sign, nonetheless, that the exploit seller has any inclusion in the cyberattack. 

Zerodium's chief executive Chaouki Bekrar named the culprit as a "troll," remarking that "likely, the researcher who found this bug/exploit tried to sell it to many entities but none wanted to buy this crap, so they burned it for fun." The commits were recognized and returned before they made it downstream or affected clients. An investigation concerning the security incident is currently in progress and the team is scouring the repository for some other indications of malevolent activity. Meanwhile, however, the development team has concluded now is the opportune chance to move permanently to GitHub. 

"We have decided that maintaining our own git infrastructure is an unnecessary security risk, and that we will discontinue the git.php.net server," Popov said. "Instead, the repositories on GitHub, which were previously only mirrors, will become canonical. This means that changes should be pushed directly to GitHub rather than to git.php.net." Developers with past write access to the task's repositories will now have to join the PHP group on GitHub.

GitHub Awards $25,000 Bug Bounty to the Google Employee

 

GitHub awarded $25,000 to the security researcher, Teddy Katz for discovering a bug and patching it. On March 17, bug bounty hunter and Google employee Teddy Katz published a note regarding a GitHub flaw discovered in the communication system between repositories and the organization’s workflow automation software, GitHub actions.

The security flaw was tracked as CVE-2022-22862 and was reported as an improper access control susceptibility that “allowed an authenticated user with the ability to fork a repository to disclose Action secrets for the parent repository of the fork.”

Katz identified the working method of GitHub and how it manages to pull requests. Every single pull request is meant to have a base branch, and this is often the main branch of a repository. Pull request designers can lay the base branch pointer. However, the bug bounty hunter recognized that it was possible to set branches to commits, and while this ended in errors due to merge conflicts, GitHub Actions converted the bug into something more dangerous. 

GitHub executes merge pull request stimulations to stop pull request creators from accessing repository secrets. According to Katz, this “breaks the GitHub actions permission model” and evades Actions secrets restrictions.

“Since the base branch is part of the base repository itself and not part of a fork, workflows triggered by pull_request_target are trusted and run with access to secrets. We just created a pull request where the base branch is a commit hash, not a branch. And anyone can create a new commit hash in the base repository since GitHub shares commits between forks,” Katz explained. 

An attacker could split public repositories that use GitHub Actions, design a pull request, and then set a malicious Actions workflow and separately commit to a fork – gaining access to repository secrets in the process.

“It would be difficult to conceal the malware for long – the malicious package would almost certainly be unpublished in a matter of hours or days depending on how fast the maintainers/npm security team were able to respond. Once it was exploited like this, the underlying GitHub vulnerability would probably have been noticed and fixed as well,” Katz stated.

GitHub Informed Clients of “Potentially Serious” Security Bug

 

GitHub on Monday informed clients that it had found what it described as an “extremely rare, but potentially serious” security bug identified with how some authenticated sessions were handled. On 8th March GitHub signed out all clients that were signed in before March 8th. The precautionary measure was taken seven days after the organization had gotten an underlying report of dubious conduct, from an external party. 

The Microsoft-owned software development platform said the bug was found on March 2 and an underlying patch was carried out on March 5. A subsequent fix was delivered on March 8 and on the evening of that very day the organization chose to invalidate all authenticated sessions to completely eliminate the possibility of exploitation. On Friday, the GitHub team has remediated the security flaw and kept on analyzing the situation over the weekend. The vulnerability being referred to, could be misused in extremely rare circumstances, when a rare condition would happen during the backend request handling process, permitting the session cookie of a logged-in GitHub client to be sent to the software of another client, giving the latter access to the former user’s account.

“It is important to note that this issue was not the result of compromised account passwords, SSH keys, or personal access tokens (PATs) and there is no evidence to suggest that this was the result of a compromise of any other GitHub systems,” says Mike Hanley, GitHub’s recently appointed chief security officer. “Instead, this issue was due to the rare and isolated improper handling of authenticated sessions. Further, this issue could not be intentionally triggered or directed by a malicious user.” 

The organization declared that the bug existed on GitHub.com for less than two weeks and it doesn't resemble some other GitHub.com assets or products were impacted as a result of this bug. "We believe that this session misrouting occurred in less than 0.001% of authenticated sessions on GitHub.com. For the very small population of accounts that we know to be affected by this issue, we’ve reached out with additional information and guidance,” continues Hanley in the announcement. 

The organization is still analyzing if any project repositories or source code were messed with because of this vulnerability as this kind of authentication vulnerabilities could pave the way for software supply-chain attacks.

Python Package Index Removed 3,653 Noxious Packages after a Vulnerability

 


The Python Package Index, otherwise called PyPI, has eliminated 3,653 noxious packages uploaded days after a security vulnerability in the utilization of private and public registries was highlighted. The Python Package Index is the official third-party software repository for Python. It is analogous to CPAN, the repository for Perl. Some package managers, including pip, use PyPI as the default source for packages and their dependencies. More than 235,000 Python packages can be accessed through PyPI. 

Python developers use PyPI to add software libraries composed by different developers in their own ventures. Other programming languages implement similar package management systems, all of which request some degree of trust. Developers are frequently encouraged to audit any code they import from an external library however that advice isn't constantly followed. Package management systems like npm, PyPI, and RubyGems have all had to eliminate sabotaged packages as of recent years. Malware creators have discovered that in the event that they can get their code included in well-known libraries or applications, they get free dissemination and trust they haven't acquired. 

A month ago, security researcher Alex Birsan showed that it is so easy to exploit these systems through a type of typosquatting that misused the interplay between public and private package registries. The downpour of vindictive Python packages over the previous week included unauthorized versions of projects like CuPy, an implementation of NumPy-compatible multi-dimensional array on CUDA, Nvidia's parallel computing platform. 

In a GitHub issued post, Kenichi Maehashi, a project maintainer, relates how cupy-cuda112 (CuPy worked for CUDA 11.2) was uploaded on February 25, 2021, then detected and eliminated a day later. Python has a policy for managing such a thing. On Monday, Ee W. Durbin III, director of infrastructure at the Python Foundation, said the large number of culpable packages had been taken out but expressed hesitance to boycott the account responsible because the account holder could simply register for another account. 

The name utilized by the malware writer, "RemindSupplyChainRisks," gives off an impression of being an attempt to call attention to an aspect of software distribution that most developers already understand is fraught with potential problems.

Github Escapes from Octopus Malware that Affected its 26 Software Projects


Github, a platform where every malicious software report is equally different in its place, manages to escape from a malware threat.  Github, an organization that united the world's largest community of coders and software developers, revealed that hackers exploited an open-source platform on its website to distribute malware. The hackers used a unique hacking tool that enabled backdoors in each software project, which the hackers used to infiltrate the software systems.


"While we have seen many cases where the software supply chain was compromised by hijacking developer credentials or typosquatting popular package names, a malware that abuses the build process and its resulting artifacts to spread is both interesting and concerning for multiple reasons," said Github on its security blog. Fortunately, the hackers attempt to exploit the open-source platform was unsuccessful. Still, if it were, on the contrary, hackers could've secured a position in the softwares, which were to be used later by corporate applications and other websites.

Since recent times, open-source websites have become a primary target for hackers. It is because once the hackers exploit backdoor vulnerabilities on open-source platforms, thousands of apps are exposed to remote code execution. As for Github, the company's website currently has more than 10 Million users. In the Github incident, 26 software projects were infected through malicious codes, which is a severe warning for the potential threat of the open-source compromises. The experts have identified the malware as "Octopus Scanner," which is capable of stealing data by deploying remote access codes.

The malware spread with the help of projects using software called Apache Beans, tells Github. "On March 9, we received a message from a security researcher informing us about a set of GitHub-hosted repositories that were, presumably unintentionally, actively serving malware. After a deep-dive analysis of the malware itself, we uncovered something that we had not seen before on our platform: malware designed to enumerate and backdoor NetBeans projects, and which uses the build process and its resulting artifacts to spread itself," says Github on its blog. These attacks can be highly threatening as the tactics used here gives the hackers access to various systems.

A new zero-day Exploit Leaked to Bypass Already Patched Vulnerability (CVE-2019-0841)



An exploit broker and hacker, SanboxEscaper made a comeback and published the details about a new zero-day which affects the already patched local privilege escalation vulnerability, CVE-2019-0841 on Windows 10 and Windows 9 operating server.

The details of the zero-day have been published on GitHub and the account and repository from which the details were leaked are the same as the ones which attributed to the leaks of 8 other previously released zero-days. 

SandboxEscaper have been actively involved in leaking zero-day exploits since August 2018, some of the previously leaked zero-days are listed below:

LPE in Advanced Local Procedure Call (ALPC)
LPE in Microsoft Data Sharing (dssvc.dll)
LPE in the Windows Error Reporting (WER) system
LPE exploit in the Windows Task Scheduler process
Sandbox escape for Internet Explorer 11
Bypass of the CVE-2019-0841 protections
LPE targeting the Windows Installer folder

The hacker who recently exploited CVE-2019-0841 vulnerability which was patched by Microsoft in April can further install malicious programs, edit and delete data. The vulnerability can be executed by deleting all files, folders, and subfolders in the Edge Browser.

Commenting on the matter, Will Dormann, Vulnerability Analyst at the CERT/CC, says, “I’ve confirmed that this works on a fully-patched (latest May updates) Windows 10 (1809 and 1903) system. This exploit allows a normal desktop user to gain full control of a protected file.”

“Make sure you have multiple cores in your VM (not multiple processors, multiple \b cores\b0 ).\par. It’s going to increase the thread priority to increase our odds of winning the race condition that this exploits”

Basically, it requires the attacker to log in as a local user and then execute this exploit which triggers the vulnerability, which then allows the attacker to access and change system permissions and gain full control of the system making him act as the admin.


Docker Hub hack leaked sensitive data of 190,000 users




An unauthorized access to a database was discovered by the Docker Hub that exposed sensitive data of more than 190,000 account holders. 

The exposed informations include username, hashed passwords, tokens for GitHub and Bitbucket repositories.

The company started emailing its customers about the security breach soon after the breach took place. However, it is unclear how hackers got a hold over a single database.

"On Thursday, April 25th, 2019, we discovered unauthorized access to a single Hub database storing a subset of non-financial user data," said Kent Lamb, Director of Docker Support.

Docker is recommending all  its users to change their password. All the impacted accounts GitHub tokens and access keys, so the user’s with auto builds are impacted.

Docker hub is the cloud repository of images created by users, and it could be downloaded by other users or images created by other communities.

“We are enhancing our overall security processes and reviewing our policies. Additional monitoring tools are now in place. Our investigation is still ongoing, and we will share more information as it becomes available,” reads breach report.