Read Time:4 Second
Commander X attacked Santa Cruz County government’s site during no-camping law protest
Monthly Archives: April 2022
Wyze Camera Vulnerability
Read Time:35 Second
Wyze ignored a vulnerability in its home security cameras for three years. Bitdefender, who discovered the vulnerability, let the company get away with it.
In case you’re wondering, no, that is not normal in the security community. While experts tell me that the concept of a “responsible disclosure timeline” is a little outdated and heavily depends on the situation, we’re generally measuring in days, not years. “The majority of researchers have policies where if they make a good faith effort to reach a vendor and don’t get a response, that they publicly disclose in 30 days,” Alex Stamos, director of the Stanford Internet Observatory and former chief security officer at Facebook, tells me.
Post Title
Read Time:28 Second
A vulnerability has been discovered in Trend Micro Apex Central which could allow for arbitrary file upload. Trend Micro Apex Central is a web-based console that provides centralized management for Trend Micro products and services at the gateway, mail server, file server, and corporate desktop levels. Successful exploitation of this vulnerability could result in arbitrary file upload which could allow a remote attacker to execute arbitrary code. Depending on the privileges associated with the application, an attacker could install programs; view, change, or delete data; or create new accounts with full user rights.
Post Title
Read Time:22 Second
A vulnerability has been discovered in versions of Zyxel Firewall’s CGI program which could allow for authentication bypass. Zyxel Firewall is a next generation firewall product which enables users to manage, detect and respond to threats on the network. Successful exploitation of this vulnerability could allow an attacker to bypass authentication and obtain administrative access to the device. Malicious actors with administrative access may be able to view, change, or delete sensitive data.
JavaScript supply chain issues
Read Time:8 Minute, 21 Second
In open source we trust
JavaScript code—used in 98% of all global websites–is a notable contributor to the ongoing software supply chain attack problems. In fact, vulnerable or malicious JavaScript is likely responsible for a sizable portion of the increase in attacks during 2021. With much of the JavaScript code that drives websites originating from open-source libraries, organizations need to understand how open source contributes to the JavaScript supply chain issues, and what they need to do to protect their business and their customers.
What’s going on with the supply chain?
Often called one of the most insidious and dangerous forms of hacking, software supply chain attacks can devastate businesses. In addition to the immediate effects of an attack, such as operational delays, system infiltration, and the theft of sensitive credentials or customer data, the long-term consequences can be significant. Regulatory fines, compliance concerns, reputation damage, attacks on connected businesses, and lost customers are often the consequences of a supply chain attack.
Software supply chain attacks currently dominate the headlines, with recent industry research reporting a 300% increase in 2021. The research found that threat actors tend to focus on open source vulnerabilities and code integrity issues to deliver attacks. In addition, researchers discovered a low level of security across software development environments, with every company examined having vulnerabilities and misconfigurations.
Another industry report discovered a 650% increase over the course of one year in supply chain attacks aimed at upstream public repositories, the objective being to implant malware directly into open source projects to infiltrate the commercial supply chain.
A common thread in all of this is JavaScript—an inherently insecure coding language and one that is often found in open source projects.
Open-source JavaScript: A focal point for attack
Why the software supply chain has become a focal point for threat actors is a question on quite a few minds. The answer comes down to what is easy and most profitable. Software is imperfect. Vulnerabilities and flaws make it ripe for attack. And a connected supply chain ensures a large attack surface. Add to this is the prevalent use of the JavaScript programming language and open-source JavaScript libraries, which often contain flawed and sometimes malicious–third- or fourth-party code, and businesses become ground zero for JavaScript supply chain attacks.
JavaScript serves as one of the core technologies used to build web applications and websites. As mentioned previously, over 98% of websites use it for client-side web page behavioral elements. Additionally, 80% of websites use open-source or a third-party JavaScript library as part of their web application. The Stack Overflow 2021 Developer Survey found that JavaScript remains the most popular programming language with 65% of professional developers using it. Unfortunately, JavaScript wasn’t built with security in mind, making it extremely vulnerable to attack. JavaScript allows threat actors to deliver malicious scripts to run on both the front end and the back end of a system, affecting businesses, employees, and customers alike.
In addition, because there is little to no oversight in open-source libraries, vulnerabilities and malicious scripts can often lay unnoticed for months or even years.
The security firm WhiteSource recently highlighted the problems with open-source libraries and JavaScript, identifying more than 1,300 malicious packages in the most commonly downloaded JavaScript package repository.
What do JavaScript supply chain attacks look like?
As we mentioned earlier, JavaScript was not built with security in mind. Since there are no security permissions built into the JS framework, it is difficult to keep JavaScript code safe from attack. The most common JavaScript security vulnerabilities include:
Source code vulnerabilities
Input validation
Reliance on client-side validation
Unintended script execution
Session data exposure
Unintentional user activity
JavaScript supply chain attacks can take on one of three different forms: attacking the developer directly; embedding the attack on the back end; or embedding the attack on the front end.
Let’s play attack the developer!
The recent news of malicious activity found in npm, the most popular JavaScript package manager, made international headlines. These JavaScript package managers are designed to help developers automate any dependencies associated with a development project. Package managers enable automatic installation of new packages or an update to existing packages with a single command. They’re hugely popular, with new package managers released often, making them difficult to monitor. Since npm is open source, anyone can submit JavaScript packages, even bad actors who intentionally include malicious scripts in their packages.
The thing about package managers is that they install files directly on the developer’s machine, which means threat actors can get almost instant access to a developer’s device and possibly the entire system and network. According to WhiteSource, the organization that discovered the malicious npm packages, much of the malicious activity involved embedding malicious files on developer machines to engage in the ‘reconnaissance’ phase of an attack (based on the MITRE ATT&CK Framework), that is, active or passive information gathering. Researchers also discovered that 14% of the packages were designed to steal sensitive information, such as credentials.
Researchers found that threat actors designed these malicious packages to make them look legitimate, by using the names of well-known and popular npm packages, and then emulating source code. Malicious files observed in the study included obfuscated JavaScript and binaries hidden as JavaScript components.
The researchers in the WhiteSource study also found that in some instances, once the developers downloaded the files, one of the binaries would download a third-party file designed to interact with the Windows Registry to collect system and configuration information. The malicious file would also try to establish a connection with a remote host to enable remote code execution (RCE). The fake JavaScript files also included examples of Cobalt Strike, a tool used during Red Teams and penetration testing to facilitate an attack. According to researchers, the ultimate goal of this malicious software appeared to be cryptocurrency mining directly on the developer machine.
While threat actors did not appear to target specific industries or companies, they did design malicious packages to target certain systems. Researchers also discovered malicious JavaScript packages that used typosquatting, dependency confusion, code obfuscation, and other types of attack techniques.
Back-end JavaScript threats
JavaScript frameworks commonly used for server-side development, or the back end of a web application, are also highly susceptible to attack. As we mentioned earlier, JavaScript wasn’t built with security in mind making it an easy target. Any vulnerabilities in back-end JavaScript source code means threat actors have an easy way to infiltrate systems, install malicious files, and execute attacks. Risks include security misconfigurations, which can enable access to the back end; insecure back-end application design; vulnerable or outdated components; and server-side request forgery (SSRF). Examples of threats include SQL injection for back-end database manipulation, SSRF, and cross-site scripting (XSS).
Front-end JavaScript threats
The front-end, or “client-side” code is executed within the browser which often lacks the same rigorous security controls that protect the back end of web applications. This makes vulnerable code on the client-side even more deadly due to the lack of visibility and control most organizations don’t have in place today. Since many web applications are written in JavaScript and operate on the client side, web users—such as bank or e-commerce customers—become vulnerable to attacks like Magecart, e-skimming, side loading, cross-site scripting (XSS), and formjacking.
Protect the complete attack surface with these three key steps
To fully manage the risk against breaches and attacks, companies must simultaneously protect both the client side and back end of their application portfolios. This includes anything accessed by the developer, anything written in JavaScript on the back end, and web assets that the customer can see (e.g., text and images) and interact with.
One of the most important actions any business can take is protecting their customers from JavaScript threats. Unfortunately, because of the sophisticated and subtle nature of these attacks, they can be hard to detect until it’s too late. To ensure that businesses are offering a safe and secure digital experience, they must be diligent about securing their website and web applications from dangerous client-side JavaScript attacks.
To protect the client-side attack surface, businesses should apply these three best practices:
Review third-party code during software development: Third-party JavaScript is a great way to avoid the time and money associated with developing your own code, but third-party scripts can also contain vulnerabilities or intentional malicious content. Always inspect third- and fourth-party additions for vulnerabilities.
Perform automated client-side attack surface monitoring: Inspection activities are critical, but also time consuming if you don’t have an automated solution to review JavaScript code. A purpose-built solution, like Feroot’s Inspector offered in AT&T Managed Vulnerability Program’s Client-side Security Solution, that automates the process can be a fast and easy way to identify malicious script activity.
Identify software supply chain risks: Assess and know what third-party code is being used across your web application’s client-side.
Improve your JavaScript supply chain security
JavaScript carries risk. The only way to avoid your business and your customers becoming victims of a JavaScript attack is to apply JavaScript security best practices to your website and web application development process.
The services offered by AT&T’s Managed Vulnerability Program (MVP) allow the MVP team to inspect and monitor customer web applications for malicious JavaScript code that could jeopardize customer and organization security.
AT&T is helping customers strengthen their cybersecurity posture and increase their cyber resiliency by enabling organizations to align cyber risks to business goals, meet compliance and regulatory demands, achieve business outcomes, and be prepared to protect an ever-evolving IT ecosystem.
To learn more about JavaScript security, check out Feroot’s comprehensive Education Center to read more on terminologies, technologies, and threats.
New insider threat: Bad business decisions that put IP at risk
Read Time:48 Second
The existence of policies and procedures surrounding the implementation of a business strategy are the hallmarks of maturity within a company’s growth. When insiders make business decisions that violate the law, or those policies, the potential for increased risk to the business is present. We see this most often when individuals in positions of trust violate policy or procedural constraints, whether on purpose (theft) or accidentally (human error) and data goes missing or flies out the door into the public domain.
A recent settlement order, dated March 3, between the Federal Trade Commission (FTC) and Weight Watchers International and its wholly owned subsidiary Kurbo demonstrates what may occur if those insiders evolve a business model that ignores the law. Weight Watchers and Kurbo agreed to pay a fine of $1.5 million, delete information “illegally collected from children under 13,” and “destroy any algorithms derived from the data.”
Keeping secrets in a devsecops cloud-native world
Read Time:34 Second
Devsecops adoption is widely underway, with many organizations looking to break down silos among development, security and operations while leveraging cloud-native architectures to drive secure software outcomes for organizations. That said, one problem is still pervasive throughout this devsecops journey and that’s the case of secrets management.
Secrets consist of information organizations desire to keep private, most notably credentials, access keys or certificates of some form. As evident from previous data breach reports, such as IBM’s, credentials and secrets remain among the top factors involved in incidents and data breaches, often giving malicious actors initial or lateral access in environments.