Apr 11, 2024The Hacker NewsSoftware Security / Programming

GitGuardian is famous for its annual State of Secrets Sprawl report. In their 2023 report, they found over 10 million exposed passwords, API keys, and other credentials exposed in public GitHub commits. The takeaways in their 2024 report did not just highlight 12.8 million new exposed secrets in GitHub, but a number in the popular Python package repository PyPI.

PyPI, short for the Python Package Index, hosts over 20 terabytes of files that are freely available for use in Python projects. If you’ve ever typed pip install [name of package], it likely pulled that package from PyPI. A lot of people use it too. Whether it’s GitHub, PyPI, or others, the report states, “open-source packages make up an estimated 90% of the code run in production today.” It’s easy to see why that is when these packages help developers avoid the reinvention of millions of wheels every day.

In the 2024 report, GitGuardian reported finding over 11,000 exposed unique secrets, with 1,000 of them being added to PyPI in 2023. That’s not much compared to the 12.8 million new secrets added to GitHub in 2023, but GitHub is orders of magnitude larger.

A more distressing fact is that, of the secrets introduced in 2017, nearly 100 were still valid 6-7 years later. They did not have the ability to check all the secrets for validity. Still, over 300 unique and valid secrets were discovered. While this is mildly alarming to the casual observer and not necessarily a threat to random Python developers (as opposed to the 116 malicious packages reported by ESET at the end of 2023), it’s a threat of unknown magnitude to the owners of those packages.

While GitGuardian has hundreds of secrets detectors, it has developed and refined over the years, some of the most common secrets it detected in its overall 2023 study were OpenAI API keys, Google API keys, and Google Cloud keys. It’s not difficult for a competent programmer to write a regular expression to find a single common secret format. And even if it came up with many false positives, automating checks to determine if they were valid could help the developer find a small treasure trove of exploitable secrets.

It is now accepted logic that if a key has been published in a public repository such as GitHub or PyPI, it must be considered compromised. In tests, honeytokens (a kind of “defanged” API key with no access to any resources) have been tested for validity by bots within a minute of being published to GitHub. In fact, honeytokens act as a “canary” for a growing number of developers. Depending on where you’ve placed a specific honeytoken, you can see that someone has been snooping there and get some information about them based on telemetry data collected when the honeytoken is used.

The bigger concern when you accidentally publish a secret is not just that a malicious actor might run up your cloud bill. It’s where they can go from there. If an over-permissioned AWS IAM token were leaked, what might that malicious actor find in the S3 buckets or databases it grants access to? Could that malicious actor gain access to other source code and corrupt something that will be delivered to many others?

Whether you’re committing secrets to GitHub, PyPI, NPM, or any public collection of source code, the best first step when you discover a secret has leaked is to revoke it. Remember that tiny window between publication and exploitation for a honeytoken. Once a secret has been published, it’s likely been copied. Even if you haven’t detected an unauthorized use, you must assume an unauthorized and malicious someone now has it.

Even if your source code is in a private repository, stories abound of malicious actors getting access to private repositories via social engineering, phishing, and of course, leaked secrets. If there’s a lesson to all of this, it’s that plain text secrets in source code eventually get found. Whether they get accidentally published in public or get found by someone with access they shouldn’t have, they get found.

In summary, wherever you’re storing or publishing your source code, be it a private repository or a public registry, you should follow a few simple rules:

1. Don’t store secrets in plain text in source code.
2. Keep those who get hold of a secret from going on an expedition by keeping the privileges those secrets grant strictly scoped.
3. If you discover you leaked a secret, revoke it. You may need to take a little time to ensure your production systems have the new, unleaked secret for business continuity, but revoke it as soon as you possibly can.
4. Implement automations like those offered by GitGuardian to ensure you’re not relying on imperfect humans to perfectly observe best practices around secrets management.

If you follow those, you may not have to learn the lessons 11,000 secrets owners have probably learned the hard way by publishing them to PyPI.

Apr 11, 2024The Hacker NewsSoftware Security / Programming

GitGuardian is famous for its annual State of Secrets Sprawl report. In their 2023 report, they found over 10 million exposed passwords, API keys, and other credentials exposed in public GitHub commits. The takeaways in their 2024 report did not just highlight 12.8 million new exposed secrets in GitHub, but a number in the popular Python package repository PyPI.

PyPI, short for the Python Package Index, hosts over 20 terabytes of files that are freely available for use in Python projects. If you’ve ever typed pip install [name of package], it likely pulled that package from PyPI. A lot of people use it too. Whether it’s GitHub, PyPI, or others, the report states, “open-source packages make up an estimated 90% of the code run in production today.” It’s easy to see why that is when these packages help developers avoid the reinvention of millions of wheels every day.

In the 2024 report, GitGuardian reported finding over 11,000 exposed unique secrets, with 1,000 of them being added to PyPI in 2023. That’s not much compared to the 12.8 million new secrets added to GitHub in 2023, but GitHub is orders of magnitude larger.

A more distressing fact is that, of the secrets introduced in 2017, nearly 100 were still valid 6-7 years later. They did not have the ability to check all the secrets for validity. Still, over 300 unique and valid secrets were discovered. While this is mildly alarming to the casual observer and not necessarily a threat to random Python developers (as opposed to the 116 malicious packages reported by ESET at the end of 2023), it’s a threat of unknown magnitude to the owners of those packages.

While GitGuardian has hundreds of secrets detectors, it has developed and refined over the years, some of the most common secrets it detected in its overall 2023 study were OpenAI API keys, Google API keys, and Google Cloud keys. It’s not difficult for a competent programmer to write a regular expression to find a single common secret format. And even if it came up with many false positives, automating checks to determine if they were valid could help the developer find a small treasure trove of exploitable secrets.

It is now accepted logic that if a key has been published in a public repository such as GitHub or PyPI, it must be considered compromised. In tests, honeytokens (a kind of “defanged” API key with no access to any resources) have been tested for validity by bots within a minute of being published to GitHub. In fact, honeytokens act as a “canary” for a growing number of developers. Depending on where you’ve placed a specific honeytoken, you can see that someone has been snooping there and get some information about them based on telemetry data collected when the honeytoken is used.

The bigger concern when you accidentally publish a secret is not just that a malicious actor might run up your cloud bill. It’s where they can go from there. If an over-permissioned AWS IAM token were leaked, what might that malicious actor find in the S3 buckets or databases it grants access to? Could that malicious actor gain access to other source code and corrupt something that will be delivered to many others?

Whether you’re committing secrets to GitHub, PyPI, NPM, or any public collection of source code, the best first step when you discover a secret has leaked is to revoke it. Remember that tiny window between publication and exploitation for a honeytoken. Once a secret has been published, it’s likely been copied. Even if you haven’t detected an unauthorized use, you must assume an unauthorized and malicious someone now has it.

Even if your source code is in a private repository, stories abound of malicious actors getting access to private repositories via social engineering, phishing, and of course, leaked secrets. If there’s a lesson to all of this, it’s that plain text secrets in source code eventually get found. Whether they get accidentally published in public or get found by someone with access they shouldn’t have, they get found.

In summary, wherever you’re storing or publishing your source code, be it a private repository or a public registry, you should follow a few simple rules:

1. Don’t store secrets in plain text in source code.
2. Keep those who get hold of a secret from going on an expedition by keeping the privileges those secrets grant strictly scoped.
3. If you discover you leaked a secret, revoke it. You may need to take a little time to ensure your production systems have the new, unleaked secret for business continuity, but revoke it as soon as you possibly can.
4. Implement automations like those offered by GitGuardian to ensure you’re not relying on imperfect humans to perfectly observe best practices around secrets management.

If you follow those, you may not have to learn the lessons 11,000 secrets owners have probably learned the hard way by publishing them to PyPI.

Mar 27, 2024The Hacker NewsData Protection / Browser Security

As SaaS applications dominate the business landscape, organizations need optimized network speed and robust security measures. Many of them have been turning to SASE, a product category that offers cloud-based network protection while enhancing network infrastructure performance.

However, a new report: “Better Together: SASE and Enterprise Browser Extension for the SaaS-First Enterprise” (Download here), challenges SASE’s ability to deliver comprehensive security against web-borne cyber threats on its own. From phishing attacks to malicious extensions and account takeovers, traditional network traffic analysis and security falls short. The report sheds light on these limitations and introduces the role of secure browser extensions as an essential component in a comprehensive security strategy.

SASE Advantages and Limitations

SASE takes on a dual role in addressing both infrastructure and security. However, while SASE offers clear advantages in security, it may not entirely cover the expanse of the web-borne threat landscape. SWG, CASB, and NGFW are not a silver bullet to all the security needs of the SaaS-first organization, even when they are packaged as SASE.

The modern threat landscape is shaped by the centrality of the browser as a main working space. These new threats leverage the browser as a bridge between the device and organizational resources and aim to gain malicious access to the organization through phishing, malicious extensions, and account takeover, to name a few. While SASE is designed to protect the perimeter from threats that attempt to enter it, this new threat landscape relies on traffic from the browser to a SaaS app or website, which SASE does not entirely cover.

Bridging the Gap with Secure Browser Extensions

Secure browser extensions complement SASE’s network security measures. Through deep session analysis and proactive threat prevention, these extensions provide granular visibility and real-time protection against sophisticated web-borne threats, effectively addressing the gaps left by SASE.

SASE vs. Secure Browser Extensions: 3 Use Cases

How do the differences between SASE and secure browser extensions play out when it comes to actual threats? The report provides three use cases.

1. Phishing

• SASE limitations: SASE’s NGFW or SWG lacks visibility into the actual session, leaving it to rely on known malicious addresses or emulate the session in a virtual environment. As a result, SASE misses ~60% of malicious web pages. It also is unable to detect pages that disable their phishing activity when executed in a virtual environment.
• The solution: A secure browser extension provides granular visibility into the live session, enabling the tracking of malicious components in the phishing web page and disabling them in real time.

2. Malicious Extensions

• SASE limitations: SASE’s NGFW or SWG lacks the ability to detect and block outbound traffic generated by any malicious extensions.
• The solution: The secure browser extension provides visibility into the browser and detects and disables all extensions that introduce a data exfiltration risk.

3. Account Takeover

• SASE limitations: SASE’s CASB lacks visibility into complex, modern web apps and depends on the app’s API, limiting protection to sanctioned apps.
• The solution: The secure browser extension integrates with the organizational identity provider and acts as an additional authentication factor. Access is possible only from a browser that has the extension.

With SaaS app usage becoming dominant, the more important the role of the browser becomes – and the threat landscape it encounters will increase. Can organizations ignore the risks that derive from the modern browser? According to LayerX, network security is insufficient on its own, and they call for complementary measures that can address SASE’s gaps.

To read more about how to gain real-time protection against this evolving risk with a secure browser extension, read the entire report.

Feb 20, 2024NewsroomHacking / Cyber Espionage

North Korean state-sponsored threat actors have been attributed to a cyber espionage campaign targeting the defense sector across the world.

In a joint advisory published by Germany’s Federal Office for the Protection of the Constitution (BfV) and South Korea’s National Intelligence Service (NIS), the agencies said the goal of the attacks is to plunder advanced defense technologies in a “cost-effective” manner.

“The regime is using the military technologies to modernize and improve the performance of conventional weapons and to develop new strategic weapon systems including ballistic missiles, reconnaissance satellites and submarines,” they noted.

The infamous Lazarus Group has been blamed for one of the two hacking incidents, which involved the use of social engineering to infiltrate the defense sector as part of a long-standing operation called Dream Job. The campaign has been ongoing since August 2020 over several waves.

In these attacks, the threat actors either create a fake profile or leverage legitimate-but-compromised profiles on platforms like LinkedIn to approach prospective targets and build trust with them, before offering lucrative job opportunities and shifting the conversation to a different messaging service like WhatsApp to initiate the recruitment process.

Victims are then sent coding assignments and job offer documents laden with malware that, when launched, activate the infection procedure to compromise their computers.

“Universally, the circumstance that employees usually do not talk to their colleagues or employer about job offers plays into the hands of the attacker,” the agencies said.

“The Lazarus Group changed its tools throughout the campaign and demonstrated more than once that it is capable of developing whatever is necessary to suit the situation.”

The second case concerns an intrusion into a defense research center towards the end of 2022 by executing a software supply chain attack against an unnamed company responsible for maintaining one of the research center’s web servers.

“The cyber actor further infiltrated the research facility by deploying remote-control malware through a patch management system (PMS) of the research center, and stole various account information of business portals and email contents,” the BfV and NIS said.

The breach, which was carried by another North Korea-based threat actor, unfolded over five stages –

• Hack into the web server maintenance company, steal SSH credentials, and gain remote access to the research center’s server
• Download additional malicious tooling using curl commands, including a tunneling software and a Python-based downloader
• Conduct lateral movement and plunder employee account credentials
• Leverage the stolen security manager’s account information to unsuccessfully distribute a trojanized update that comes with capabilities to upload and download files, execute code, and to collect system information
• Persist within target environment by weaponizing a file upload vulnerability in the website to deploy a web shell for remote access and send spear-phishing emails

“The actor avoided carrying out a direct attack against its target, which maintained a high level of security, but rather made an initial attack against its vendor, the maintenance and repair company,” the agencies explained. “This indicates that the actor took advantage of the trustful relationship between the two entities.”

The security bulletin is the second to be published by BfV and NIS in as many years. In March 2023, the agencies warned of Kimsuky actors using rogue browser extensions to steal users’ Gmail inboxes. Kimsuky was sanctioned by the U.S. government in November 2023.

The development comes as blockchain analytics firm Chainalysis revealed that the Lazarus Group has switched to using YoMix bitcoin mixer to launder stolen proceeds following the shutdown of Sinbad late last year, indicating their ability to adapt their modus operandi in response to law enforcement actions.

“Sinbad became a preferred mixer for North Korea-affiliated hackers in 2022, soon after the sanctioning of Tornado Cash, which had previously been the go-to for these sophisticated cybercriminals,” the company said. “With Sinbad out of the picture, Bitcoin-based mixer YoMix has acted as a replacement.”

The malicious activities are the work of a plethora of North Korean hacking units operating under the broad Lazarus umbrella, which are known to engage in an array of hacking operations ranging from cyber espionage to cryptocurrency thefts, ransomware, and supply chain attacks to achieve their strategic goals.